AddArchitecture Design Method
Version 1.0:
2008-12-10
This article is a learning note for the book "software architecture practice.
Add(Attribute-Driven Architecture Design) is a framework design method with the implementation of quality attributes as the main driving force, which places the function implementation to a secondary position.
AddThe overall process: select the target object (system, subsystem, or module), determine the functions to be implemented and the quality attributes to be met, and select the architecture and tactics to implement these quality attributes, according to the tactical design architecture, obtain the sub-module, assign features to the sub-module and the part of the overall tactics that should be undertaken, and finally check whether the functions and quality attributes are met. At this point, the functions and tactics required by the sub-module have been determined, and then the sub-module is selected for the same processing to form a recursive decomposition process.
AddStarting from: the architecture driving factors are generally determined. The architecture driving factors refer to the requirements that have the greatest impact on the architecture-quality attributes or functions; the document does not mention the feedback process of the later-confirmed architecture drivers on the existing architecture design part;
AddInput: functional requirements and restrictions, quality attribute requirements described in scenarios;
AddOutput: the module decomposition view and the first several layers of other view as needed;
AddPosition: can be combined with other development methods to replace the architectural design of those methods;
Add Process
1, select the module, system, or subsystem to be decomposed and determine its limiting factors, functions, quality attributes, and design constraints
2, determine the architecture driver, Add give priority to important requirements;
3, select tactics that can realize quality attributes, select the architecture mode based on tactics (the "Mode" here is different from the pattern we often call to solve repeated problems in specific application scenarios), and determine the sub-module, the goal is to establish an overall architecture model composed of "module types", which is constructed by the selected tactics and meets the driving factors.
4, instantiate a module and assign functions based on the Use Case. instantiate the module type as a module, for example, if "Key Performance Computing" is instantiated as "obstacle detection", each use case of the parent module is divided into a series of responsibilities of the sub-module, and information exchange is recorded. A view is used to represent the architecture, generally, the module breakdown view is used as the main view, and other views are introduced as needed.
5, Define sub-module interfaces, including services and interaction modes;
6, Verify whether the use cases and quality scenarios have been met and prepare for the decomposition of sub-modules. There are several situations where quality attributes are affected:
A)
the quality attribute is decomposed to meet the requirements, for example, the Server Load balancer solution composed of a distributor and a processor meets the large capacity requirement.
B)
each module meets a part of the quality attribute.
C)
the decomposition does not affect the quality attribute and is assigned to a submodule, for example, the ease of use is assigned to the UI module;
d)
If the decomposition conflicts with the quality attribute, you may need to rethink the decomposition.
7, select a submodule and repeat the preceding process. Results of each loop: Each submodule has a set of use cases, interfaces, sets of quality scenarios and restrictions, and carries out the next round of Design Based on these.