Software Architecture Design-Reading Notes

# Post reading # a very practical architecture entry book. The content is profound and involves a wide range. It helps us establish an architectural design concept.

After reading this book, I put my post feeling at the beginning. Below are detailed reading notes.

 

# Reading Notes # We divide the concept of software architecture into two major schools: composition School and decision School.

# Reading Notes # composition school: the architecture of the software system describes the system as a computing component and interaction between components.

# Reading Notes # decision making school: the software architecture includes important decisions on the following issues: the organization of the software system; the structural elements that make up the system and the interfaces between them, and the behavior embodied when these elements interact with each other; how to combine these elements to gradually synthesize them into larger subsystems; used to guide the architectural style of the system organization: these elements and their interfaces, collaboration, and combinations. -- 1

# Reading Notes # decision making school: the software architecture not only focuses on the structure and behavior of the software, but also on other features: use, functionality, performance, elasticity, reuse, comprehensibility, economic and technical constraints and trade-offs, and aesthetics. -- 2

# Reading Notes # "Architecture decision-making is conducted in different layers" is also manifested in: the order in which decisions are made is usually the process in which technology-independent decisions are made first, and then technology-related decisions are made, the latter is implemented under the guidance of the former.

# Reading Notes # views of the two schools can be summarized as follows: composition School "Architecture = component + interaction", and decision School "Architecture = important decision set ". Although they have different angles, they complement each other.

# Reading Notes # The framework is software, and the architecture is not software. A framework is a semi-finished product of a system or subsystem. Software architecture is not software, but an important decision on how to design software. The software architecture is more specific Code A high-level abstract concept. The architecture is bound to be reflected and followed by the code, but any specific piece of code cannot represent the architecture.

 

# Reading Notes # it makes sense to document the product line architecture.

# Reading Notes # software architects must keep in mind that they focus on "quality attributes during software RunTime" and are designed for developers.

 

# Reading Notes # philpe kruchten wrote in his book "Introduction to the Rational Unified Process" that an architecture view is a simplified description of the system from a certain perspective or point, the description covers a specific aspect of the system, while omitting entities unrelated to this aspect.

 

# Reading Notes # Each view of the software architecture focuses on different aspects for different purposes and purposes.

# Reading Notes # from the conceptual architecture to the actual architecture, first design the conceptual architecture, design the solutions to key problems, and then design the actual architecture, to ensure sufficient guidance and restrictions for development ...... this is in line with the laws that humans solve problems and is therefore widely used.

 

# Reading Notes # ease of use, performance, scalability, continuous availability, robustness, security, scalability, reusability, portability, comprehensibility, and testability may all be software quality requirements. There is a conflict between these quality attributes.

# Reading Notes # develop a software architecture design strategy: Strategy 1: fully understand the requirements; Strategy 2: Determine the architecture based on key requirements; Strategy 3: multi-view architecture exploration; Policy 4: Verify the architecture as soon as possible.

# Reading Notes # High-to-high architecture design has the following three manifestations: Symptom 1: Missing Important architecture view; symptom 2: early adopters, not deep enough; symptom 3, non-real Hierarchical architecture.

 

# Reading Notes # The degree to which the software architecture should be designed can be summarized into two sentences: the degree of design of the software architecture varies depending on different projects and development teams; the software architecture should provide adequate guidance and restrictions for developers.

 

# Reading Notes # It is definitely not enough to think that "demand is the user's requirement.

 

# Reading Notes # requirement analysis focuses on figuring out what the software system wants to do, while System Analysis focuses more on "How to do it.

 

# Reading Notes # functional requirements affect the architecture, and the architecture must adapt to functional requirements. However, the functional requirements cannot determine the architecture, which is obvious.

# Reading Notes # There are three possible impacts of binding requirements: (1) constraints that must be observed during architecture design; (2) as a result, the software system must provide certain functional requirements; (3) As a result, the software system must meet certain binding requirements. (See Figure 10-8)

# Reading Notes # The Name Of The use case should be described from the perspective of the participants and start with a verb, so that the semantics of the use case chart can be clearly obtained through "reading the image.

 

 

 

# Reading Notes # The most important elements of a use case diagram are the actors and use cases ).

# Reading Notes # use case description: describes the function of a use case in a short text. Generally, the use case description should contain a simple description of a successful scenario.

 

# Reading Notes # Use Case conventions are detailed descriptions of use cases, including brief descriptions, main event streams, alternative event streams, preconditions, post conditions, and priorities. The main purpose of the use case specification is to define the behavior requirements of the software system.

# Reading Notes # the use case diagram reflects user requirements in general. the use case description and Use Case specification are simplified and detailed descriptions of behavior requirements. As for case implementation, it is already in the design scope.

# Reading Notes # the rule that demand changes affect different requirements: The Use Case chart is a general but not in-depth description of functional requirements, which is relatively stable. The use case description does not involve details, therefore, it is relatively stable. The Use Case specification describes functional requirements through interactive sequences, which is greatly affected by changes in requirements.

# Reading Notes # You must be smart enough to cope with demand changes: use cases should be refined to stimulate demand changes.

# Reading Notes # The first step for architects is to analyze requirements. The documents or methods involved are as follows: requirement acquisition card, vision and scope documentation, feature list, use case diagram, use case description, use case specification, prototype inspiration requirements, requirement verification, Software Requirement Specification (including non-functional requirements ).

# Reading Notes # The Role Of The domain model on the software architecture and the entire software system development work can be summarized into three points: Exploring complex problems and consolidating domain knowledge; determining the function scope and affecting scalability; provide the communication basis and promote effective communication.

# Reading Notes # The key first step is to narrow down the scope.

# Reading Notes # Do you have to fight?

# Reading Notes # the key requirements determine the architecture, and the other requirements verify the architecture.

Types of software requirements

 

 

 

Classification of software quality attributes

 

 

 

Quality attribute relational matrix

 

 

Adjusted quality attribute relational matrix

 

 

Steps for determining critical software architecture requirements

 

 

 

 

The conceptual architecture design can be roughly divided into the following three steps:
Step 1: Robustness analysis.
Step 2: Introduce the architecture model.
Step 3: quality attribute analysis.

 

Architecture Model: A typical modern classification book "model-oriented software architecture", published in 1996.

One-way dependency between layers can be divided into two types: strict layered architecture requires that layer n can only be called by layer n + 1, which is not strictly hierarchical, layer N can be called by any layer on its upper layer.

In conceptual architecture design, functional requirements are the primary input for robustness analysis, while quality attribute requirements are the primary input for quality attribute analysis.

The "Attribute-scenario-decision" table method advocates refining the quality attribute requirements to be achieved through a set of specific scenarios, and then formulating architecture decisions based on these real scenarios.

The "Attribute-scenario-decision" table method changes the decision-making process of software architecture design from "black box" to "gray box". The following benefits are provided:
1. strong operability.
2. Avoid excessive design.
3. Easy to refer to during system upgrade.

In general, the design of the logical architecture should complete the following tasks:

• Refined functional units;
• General mechanism of discovery;
• Refine the domain model;
• Determine the subsystem interface and interaction mechanism.

The Mechanism is an instance of the mode. The mechanism must be further refined to become a collaboration in a specific model. Therefore, the Mechanism is a specific solution for repeated problems in a unique context.

A process is called a "heavyweight control flow" because it is both a unit for allocating processor resources and a unit for allocating other computer resources. A thread is called a lightweight control flow. It is only the Unit for allocating processing resources. A process can contain multiple threads that share the resources of the process.

 

 

The prototype method can be divided into two categories based on whether the purpose of the development prototype is to simulate the overview of the system runtime or to verify a specific technical problem in depth: Horizontal prototype And Vertical prototype .

Some prototypes are doomed to be abandoned after they are used, while some prototypes are expected to be retained as the basis for formal development. We can also divide the original method into two types:Discard prototypeAndEvolution prototype.

There are two ways to verify the architecture -- Original Method And Framework.

Architecture prototypes have very limited implementation requirements for functionality, so what should we verify for "Architecture Verification? The answer is yes.Verify the architecture's support for quality attributes.

The limited functional requirements of architecture prototypes should be carefully selected. These functions are either "most concerned" by the user or "most worried" by the architect ".

"See inheritance is not inheritance", At this stage, the brain points are" design ",Responsibility Assignment, interface design, reusability, scalability, Coupling Degree, degree of polymerization, etc.These design layer concepts.

 

Coupling is a synonym of dependency. It is defined as a relationship between two elements. One element changes, resulting in another element ".

 

The function of mixed classes is: it not only improves the reusability of functions, but also reduces code redundancy. It also enables the related "behaviors" to be concentrated in a class, instead of being distributed to multiple classes, this avoids the so-called"Scattered codeAndCode intertwined"Problem, improvedMaintainability.

Dependencies that do not cause harm in reality are benign dependencies. The "theoretical harm" of dependencies does not necessarily mean "actual harm", and vice versa. This is the benign dependency principle.

The "Five Principles of object-oriented design" and the principles of good dependence play a role in coping with changes:
Single-Responsibility Principle) . "For a class, there should be only one reason for its change ". This principle is an extension of the "high cohesion principle" that we are very familiar with. However, by creatively defining "Responsibilities" as "reasons for changes", this principle is highly operable, show the master style. At the same time, this principle also reveals that cohesion and coupling are "Two Things". To reduce coupling, the basic way is to improve cohesion. If a class has too many responsibilities, these responsibilities will be mutually dependent, and the change of one responsibility may affect the performance of another responsibility. In fact, the essence of OOD is to rationally allocate class responsibilities.

Open-closed Principle). "Software entities should be extensible, but cannot be modified ". This principle is closely centered on changes, and changes are temporary.Source codeTo expand its behavior, the design of this software entity is to meet the principle of open and closed. If we predict a change, or a change, we should create an abstraction to isolate similar changes that will happen later. In Java, this abstraction refers to an abstract base class or interface. In C ++, this abstraction refers to an abstract base class or a pure abstract base class. Of course, there is no appropriate model for all situations, and we must make a choice for the changes that the software entity should face.

Liskov replacement principle (liskov-substitution principle). "Child types must be able to replace their base types ". This principle is closely related to the open and closed principle. It is the replacement of child types that can be expanded without modifying the basic type of modules. The liskov replacement principle evolved from contract-based design. A contract declares a "prior condition" and a "posterior condition" for each method. when defining a subclass, these "prior conditions" and "posterior conditions" must be observed ". At present, the contract-based design is gaining momentum, and it is a strong support for realizing the "assembly production" Dream of "software factory.

Dependency-inversion principle). "Abstraction should not depend on details, but on abstraction ". This principle is almost the original source of software design. Because the process of thinking about solving problems is first abstract and then specific, from general to detailed, so what we produce is the entity with a relatively high degree of abstraction, and then the entity with more details. As a result, "details depend on abstraction" means that later depends on the previous, which is a natural way to reuse. Moreover, abstract entities represent a cage-based understanding. People are always more likely to understand them correctly, and they are also not easy to change, depending on which they are secure. The principle of dependency inversion adapts to the laws of human cognitive processes and marks the object-oriented design.

Interface-segregation principle). "Multiple dedicated interfaces are better than a single universal interface ". This principle is the natural result of a single responsibility principle for interface design. An interface should ensure that the Instance Object implementing this interface can only be displayed as a single role. In this way, when a customerProgramWhen the requirements change, and the interface is forced to change, the possibility of affecting other customer programs is minimized.

Benign dependency Principle. "Dependencies that do not actually cause harm are benign dependencies ". Through analysis, it is not difficult to find that the core idea of this principle is "pragmatic", which reveals the theoretical basis of "simple design" and "reconstruction" in extreme programming. This principle can help us to resist the temptation of the "Five Principles of object-oriented design" and the design pattern, so as to avoid the embarrassing situation of over-engineering and unnecessary complexity.

If one of two or more things changes, it will not affect other things. These things are orthogonal. Orthogonal thinking is one of the most useful uses for classification.

According to this model, it should be promoted or avoided. It can also be divided into two categories: "Mode" and "anti-mode. Experience is not necessarily correct. The anti-pattern is an archive of "Don't Do That.

Recommended books for UML:

• The book UML style brings together a lot of expert suggestions for drawing UML diagrams.
• The color modeling method described in Peter Coad's book "Java Modeling in color with UML: enterprise components and process" is an excellent technology in Domain Modeling.

The timing of making decisions based on continuous feedback is called milestone ). There are two types of milestones: major milestone, and minor milestone ).

 

Software engineering concept model

 

The CMM is positioned as "process development and improvement requirements and testing solutions ".

There are a lot of discussions about the release of the RUP program. Interested readers can read the document "updated as needed" in the reference document of this book.

 

After reading the book, the update is complete.