Antipatterns for Architectural Knowledge Management

Abstract

Recent research on Software Architecture has recovered its original emphasis on keeping track of design decisions and their rationales during software development, compiling them under the name of architectural knowledge (AK). This knowledge is composed of decision assets, which relate to each other creating a decision network structure. We argue that relationships in these networks of AK contain valuable information, in particular when they describe negative semantics. We use antipatterns to exploit and manage these negative relationships systematically. After examining and classifying the kinds of AK relationships, we describe a method that enriches this network by means of antipattern structures. To show the feasibility and suitability of this approach, we provide a proof-of-concept by applying it to an existing process, ATRIUM, with a concrete example, the Gas Station metaphor. Results of the use of the presented approach into three different projects with different complexities show both its feasibility and applicability.

Analysis of design meetings for understanding software architecture decisions

“…-Data Validation. Data was collected using the video and audio recording for six (6) participants that conform one architectural team. For each participant was given separate responsibilities during the project.…”

“…An architectural decision is motivated by a concern, issue or problem that the architect resolves by analyzing and evaluating a set of possible solutions which prioritizes and selects the most appropriate [5]. In addition, each decision can motivate other decisions in the same or lower level of abstraction, starting an interlaced decision network [6] which is developed evolutionarily. Unfortunately architectural documentation usually does not fully describe the decisions, only shows the final version of each of the elements defined in the architecture (in some cases limited to a set of models and views of architecture [7]) but does not include considerations, reasons and previous decisions to elements specification.…”

Evolution styles: using architectural knowledge as an evolution driver

“…Sometimes, this process can even be partially supported by automatic tools. For instance, part of our previous work in the Morpheus toolkit adds the capability to assist in the detection of anti‐patterns (like the one mentioned earlier) by checking the network of relationships in the AK. In terms of our proposal, this means to decide upon the evolution condition .…”

“…Future work in this context includes the full integration of this (generic) proposal into a specific approach. At present, we are already including these notions in ATRIUM , a process that defines and manages SAs from the requirements phase. Incorporating evolution styles into ATRIUM (and its associated toolset) will be just a matter of extending the AK network to include the new kinds of relationships (those related to evolution) and to provide an additional cycle in its model‐driven development process, which would apply evolution styles on top of the current architecture and its associated knowledge.…”