software requirements = functional requirements + quality attributes + constraints
Constraints are the context of the problem to be solved by the architecture design
Different requirements affect the different principles of the architecture, and are the basis of architectural design thinking
Five-dimensional three-level requirements method - business analysis, scope negotiation Process:
Software architecture refers to matching and arranging the various parts of the system from different angles on the basis of certain design principles to form multiple structures of the system to form an architecture, which includes each component of the system, and the components are visible from the outside. The relationship between properties and components. Externally visible properties of a component are the assumptions other components make about that component.
Software architecture design is to describe the composition and characteristics of a software system from a macro perspective.
ADMEMS is the abbreviation of Architecture Design Method has been Extended to Method System. ADMEMS covers the complete work content of the architecture design of "requirements in, architecture out" through three stages and one through link. Among them, "3 phases" refer to the preliminary architecture phase (PA phase), the conceptual architecture phase (CA phase), and the detailed architecture phase (RA phase), and "1 through-link" refers to the consideration of non-functional goals.
The architectural design method should be multi-stage first, and then multi-view; the stage is a sequential relationship, and the view is a parallel relationship.
The task of the PA phase is to fully understand the requirements, so as to grasp the characteristics of the requirements, and then determine the driving force of the architecture design; the
CA phase must consider all aspects of requirements including functions, quality, and constraints;
The overall method of the RA phase is a 5-view method, involving Logical Architecture, Physical Architecture, Development Architecture, Operational Architecture and Data Architecture.
PA stage: ADMEMS matrix method
CA stage: major requirements shaping conceptual architecture
Conceptual architecture satisfies the basic definition of "architecture = component + interaction", but conceptual architecture only focuses on high-level components
Conceptual architecture defines the "responsibilities" of high-level components in a general way, and gives the interrelationships between high-level components
Conceptual
architecture
should
not involve interface details The key point is to consider the functional requirements of the software:
the development architecture focuses on the development and coding implementation issues: the
data architecture should not only consider the database and entity model involved in the development, but also consider the design of the data storage in the physical architecture:
running The focus of the architecture is no longer the global but the local, focusing on those key points and difficulties, often requiring technical research and pre-research. Mainly consider control flow, communication mechanism, resource contention, lock mechanism, synchronous asynchronous, concurrent, serial, and also consider quality attributes:
physical architecture mainly considers hardware selection and topology, software-to-hardware mapping, and software-hardware interaction Impact:
The overall idea of question-driven logical architecture design:
10 lessons from logical architecture design:
Dividing subsystems Principle:
In order to get regular feedback from customers, rapid iteration has a basic premise: development should be "depth first", not "" Breadth first".
The breadth-first extreme case means defining each feature, then designing each feature, then coding each feature, and finally testing all features together. In the extreme, depth-first means that each function is fully defined, designed, coded, and tested, and only after this function is completed, you can move on to the next function. Of course, both extremes are bad, but depth-first is much better. For most teams, you should do a high-level breadth design and then immediately move on to a depth-first low-level design and implementation.
How to achieve the goal of "changes in one part of the system will not affect other parts" through separation of concerns?
First, the separation of concerns can be achieved by segregation of responsibilities. The key to object-oriented design is the identification and assignment of responsibilities. The completion of each function is completed through a "cooperation chain" composed of a series of responsibilities; when different responsibilities are reasonably separated, in order to realize new functions, only a new "cooperation chain" needs to be constructed, and requirements changes are often only Affects the definition and implementation of a few responsibilities.
Second, the different commonality of each part of the software system can be used to separate concerns. Different degrees of generality mean different possibilities of change. Separating the parts with different generalities is conducive to the reuse of the general part and the modification of the special part.
Alternatively, consider large-grained subsystems first, while ignoring for the moment how subsystems are composed of smaller-grained modules and classes.
"Dividing" is the means, and "combining" is the purpose.
Collaboration determines the interface
