Software Architecture Design: Programmers Transform Prerequisites (second edition) notes to architects

1 from programmer to architect 1

1.1 Software industry talent structure

1.1.1 Pyramid type or olive type? 1

1. Olive type: middle Big two small;

2. Division of Education structure and capacity structure; Academic structure: olive type, capacity structure: pyramid type;

1.1.2 Transformation from programmer to architect 2

1. What should soft enterprises do?

2 Parsing software Architecture Concepts 10

1. The concept of architecture is many, not uniform;

2.1 Classification of software architecture Concepts 11

1. The concept of architecture is difficult to unify;

2. The book divides the concept into two major schools of composition and decision-making to help understand;

2.1.1 Composition Pie 11

1. The architecture of the software system describes the system as the interaction between computing components and components;

2. Two notable features of the composition faction:

A. Focus on the object of architecture practice-software;

B. Analysis of the composition of the software;

2.1.2 Decision-making faction 11

1. rup:rational Unified process,rational unification process;

2. Software architecture is a set of decisions that are made in a number of important ways;

3. Two features:

A. Focus on the subject of architectural practice-people;

B. Summarizes the types of architectural decisions;

2.1.3 Software Architecture Concept Panorama 12

1. A lot of cattle people have different definitions of concepts;

2.2 Analysis of conceptual ideas 13

2.2.1 Software architecture focuses on segmentation and interaction 13

1. Component + interaction can strategically advantageous position and abstract the specific architectural design decisions such as MVC;

2.2.2 Software Architecture is a series of hierarchical decisions 14

1. Architecture is a design, but not all of the design belongs to the architecture;

2. The decisions involved in the architecture often have a significant impact on overall quality, concurrent development, adaptation and change;

A. How the modules are divided;

B. What are the responsibilities of each module;

C. How the interface of each module is defined;

D. What interaction mechanisms are used between modules;

E. How to choose the development technology;

F. How to meet the requirements of constraints and quality attributes;

G. How to adapt to changes that may occur;

3. The design is often carried out in a hierarchical sequence;

4. Example: Design a hardware equipment debugging system;

A. Understanding needs;

B. First-round decision: At this point the software system is segmented by high level;

C. N step, continue the decision--at this time the software system is cut into smaller units;

2.2.3 systems, subsystems, frameworks can have architecture 17

1. The real software is actually "a combination of components recursively";

2. Examples: Systems in the aerospace field, extremely complex, total systems need to be equipped with system architects, and subsystems sometimes need to be equipped with architects alone;

2.3 Practical Applications (1)--How does the team view the architecture? 13

1.

2.3.1 to understand the meaning of architecture by combining practical work on the hand 18

1. There is a failure to follow the architecture of detailed design and programming phenomenon, there are programmers and architects have different understanding of the reasons for the architecture;

2. If an architect thinks that "architecture is a universal module", then he may not care about the design of non-universal units;

3. If an architect thinks that "architecture is a technology selection", then he has no business to do after the "spring+struts" of the version;

4. If an architect thinks that "the architecture of the bid is the whole of the architecture", then he doesn't care if the "three-page slide" does not guide the programmer's actual development (because it is not aware);

5. It is the author's recommendation to understand the meaning of architecture by combining the practical work in hand.

Does 2.3.2 understand the architecture this way? 19

1. The architecture design is meticulous to the class, not very realistic;

2.3.3 work to find the answer: First look at part of the design 19

1. The MVC architecture has nothing to do with the specific technology, and we will continue to refine the schema so that we can provide more guidance and limitations for developers to really reduce the significant technical risks of subsequent development;

2. Short duration, use the third-party SDK package, but do not want to bind dead an SDK package, the adapter mode to add an interface layer;

3 Understanding the Schema Design view

3.1 Design for who software architecture 24

1. Different people have different perspectives on the architecture, and the architecture should be designed for different people;

3.1.1 Designed for users 25

1.

3.1.2 Design for customers 26

3.1.3 Designed for Developers 26

3.1.4 Designed for Managers 26

3.2 Understanding Schema Design views 28

3.2.1 Schema View

3.3 Designing schemas using logical and physical views 30

3.4 How developers grow fast

3.4.1 developers should try to design 33 more

3.4.2 Example: Mail generation system 34

Divide-and-conquer, iterative development;

You should not design a logical view and then design a physical view, but iterate to verify each other;

4 Architecture Design Process

4.1 Architectural Design Practice Context 41

Rhythm: See Through the requirements, the architecture is in the right direction, design all aspects of the architecture;

Architecture early focus on identification: 1, Major needs, 2, characteristics of demand, 3, high-risk demand;

6 Big steps:

1, demand analysis;

2, domain modeling;

3, determine the key needs;

4, conceptual framework design;

5, refinement of the architecture design;

6, architecture verification;

4.2 Architecture Design Quick Reference Manual 45

Demand communication, non-functional requirements determination, demand analysis of the main line;

5 Demand Analysis

5.1 Vision Analysis 54

The vision document is important;

Different types of companies have different document names;

A context diagram (a top-level view of a PPT or use case diagram); Describe the boundaries and linkages between the system and the surrounding things;

Vision Analysis is demand research,

Vision = Business Goal + scope +feature+ context diagram;

Output "vision and scope document"

5.2 Demand Analysis 61

Demand capture, demand analysis, system analysis;

to accompany each other;

Demand capture output demand acquisition card;

Requirements Analysis Delivery "Software Requirements Specification";

5.3 The need to master is not all 65

Software requirement = function + quality + constraint;

Any function is a responsibility chain, and the structure is the discovery of responsibilities, and the distribution of functions to each subsystem;

Quality is the driving force to perfect the architecture design;

5.5 Actual Case 78

Key steps: Three horizontal two longitudinal, horizontal means sequential execution, vertical means at any time;

Three transverse: Determine the system target, study the high-level demand, establish the use case model;

Two vertical: Demand communication, demand inspiration, demand verification, determine non-functional requirements;

The method of determining the scope of high-level demand;

6 Use cases and requirements

6.1 Use case technical family 89

Several different techniques: Use case diagram, use case brief (user story), use case specification, use case implementation (robust diagram);

6.2 Application Scenarios 94

7 Domain Modeling

7.1 What is Domain modeling 106

Domain model commonly used: Class diagram, State diagram;

7.2 Demand staff perspective-Promote user communication, resolve analysis paralysis 108

7.3 Developer Perspective 113

8 Identifying critical requirements

8.1 What determines the architecture 129

Use case driven theory: Many requirements and quality can not be described by use cases;

8.2 Critical requirements determine the architecture 132

8.3 How to identify critical needs 133

8.4 Case-Architecture watershed for small systems and large systems 137

Architecture design only appropriate, no best;

9 Conceptual Architecture Design

What is 9.1 144

Focus only on the high-level components, give the relationship between the high-level components, should not involve interface details;

is to aim at the design idea, the important choice;

9.2 Overview 151

The key requirements, the conceptual framework of the process;

9.3 Left hand function 153

Left hand function, right hand quality;

3 Elements of a robust graph: Boundary object, control object, entity object;

9.4 Right Hand mass 159

10 Refinement Architecture Design

10.1 from 2 views to 5 views 175

2 Views: Physical view + logical view;

5 views: Logical view, Development view, run view, physical view, Data view;

10.2 Learning System Thinking 177

11 Schema validation

11.1 Prototype Design 194

Try to be interested in the problem, deliberately ignoring other aspects of the requirements;

11.2 Schema Validation 198

Two kinds of verification methods: Frame method and prototype method.

12 coarse-Grained functional module Division

Software Architecture Design: Programmers Transform Prerequisites (second edition) notes to architects