Architect Learning Notes 9--architecture Design

The knowledge of software architecture is designed to solve the practical problems of software design, reuse, quality and maintenance at a higher level.

I. Overview
(i) The importance of software architecture
1. Platform for the exchange of project-related people

2. Early design decisions
1) Explicit constraints on the implementation of the system
2) predict the quality of the system
3) Maintenance decisions are provided according to
4) Help with prototype development
5) Estimated cost and schedule

3. Implement software reuse at a higher level

4. Guide and standardize development

In the traditional software development model, the software architecture should be in the outline design, after the requirements analysis;
The architecture-based software development model divides the entire software process into 6 parts: architecture requirements, design, documentation, review (evaluation), implementation, evolution, etc.

(ii) architectural model
Software architecture can be summed up as structure model, frame model, dynamic model, process model, function model 5 kinds, but the strengths, the organic unification of them may be more appropriate, so someone proposed the "4+1" View model:

Ii. Architectural requirements and software quality attributes
Software properties include feature properties and mass properties. The software architecture focuses on quality attributes. The architects have to weigh the pros and cons because of the variety of ways to implement the functionality. In the premise of satisfying the function attribute, the software architecture looks for the proper routines to improve the quality of software.
(i) Software quality attributes
1, the availability of
2. Modifiable
3. Performance
4. Security
5. testability
6. Ease of Use

Each quality attribute is constrained or mutually facilitated and needs to be measured.

According to the project stage and can be divided into

Development Period Quality attributes
Run-Time Quality properties

1. Usability and its implementation
Failure disposal.
1) Error detection
Log Heartbeat exception capture
2) Error Recovery
Redundancy, spares, rollback, transaction, demotion
3) Error Prevention
Transactions, etc.

2. Modifiable and its realization
1) Limit the modifications to local
Cohesion low coupling, reduce dependence on other modules, improve the universality of modules, limit the scope of changes, etc.
2) Prevent chain reaction
Open for extensions, close for changes.
3) Delay the binding time between
Configuration file, polymorphism, registration

3, performance and implementation
1) Reduce and control the use of resources
2) Resource Management
Introducing concurrency, caching, adding resources
3) Resource arbitration
Resource Scheduling

4. Security and Implementation
1) Defensive attack
2) Detect attacks
3) Recovery

5. Testability and its realization
1) Input/output
Logging, interface and implementation separation, using implementation alternatives for testing
2) Internal monitoring

6. Ease of use and implementation
1) When using
Record user habits and collect user feedback
2) Design time
User Interface Independent
3) Support User active operation

third, the software style
A core problem of software architecture design is the reuse architecture. Based on this, the problem of style and type of software architecture is brought out.
Software architecture style provides the possibility for large-grained software reuse.
(i) Software architecture style classification
1. Data Flow style
Sequential execution. Includes batch sequences and pipelines/filters.

2. Call/Return style
The system adopts the mechanism of call and return, in essence, it is a strategy of divide and conquer, the main idea is to decompose the complex large system into several subsystems, reduce the complexity and increase the modifiable nature.
Including
1) Main program/Sub-Program
2) object-oriented style
Objects are interacted with by functions and methods.
3) Hierarchical structure style
The upper layer calls the lower layer.
CS, BS, MVC, MVP all belong to the hierarchical structure.

3. Independent component Style
It is emphasized that each component in the system is a relatively independent individual, and they do not communicate directly to reduce the coupling degree and increase the flexibility. Including:
1) Process Communication
Connecting artifacts via message passing
2) Event Subsystem
An implicit invocation style based on events. The system does not directly call the widget, the component's process is registered to the event, and when the event is triggered, all the artifacts registered in it are executed. Viewer mode.

I think the advantage of the main event system is that the invocation is not directly associated with the call and is decoupled.

4. Virtual Machine style
To build a running environment where the system runs, you can parse and run a custom language and increase the flexibility of the architecture. Including
1) Interpreter
2) Rule-centric

5. Warehouse Style
A central database where independent artifacts are executed around them.
1) database
2) Hypertext System
3) blackboard. The blackboard is equivalent to shared data. The knowledge source interacts with the blackboard.

Iv. Service-oriented Architecture (SOA)
All functions are defined as separate services, and the overall logic of the business is accomplished through interaction and coordination between services. All services are connected through a service bus or process manager. Loosely coupled, the services do not need to consider each other's internal implementation details, and on what platform to deploy.

(i), the key technology of SOA
The key technologies of SOA are UDDI, WSDL, soap, and Rest, all developed on the basis of XML.
1) UDDI Services Publishing, locating, and locating
2) WSDL Service description
3) message transfer specification between SOAP services
4) REST

(ii), the implementation of the SOA approach
SOA is just a concept and idea that needs to be implemented concretely.
1, WebService
The reality is often to confuse webservice with SOA. But WebService is just a concrete implementation of SOA. Or it can be said that it is with the Webservice,soa to the landing and promotion.

2. Enterprise Service Bus (ESB)
A unified communications environment that supports SOA. All services can access the ESB to each other. The service leverages the ESB rather than directly accessing each other, so it should be a mediator pattern.

An ESB has service capabilities, such as being responsible for translating business logic and data formats between many services. In this case, it is also the adapter mode. An ESB can also allow an existing system to have a new external service interface without changing the code. The ESB also provides security mechanisms. In addition, the ESB seems to provide a workflow.

It sounds like an ESB is an adhesive between services, balm. But I can't figure out what a ghost it is.

(iii) micro-services
MicroServices also belong to a concept of SOA. SOA in the traditional sense, is cross-system, different systems into different services, coarse granularity, and micro-service is a program is subdivided into a number of micro-services, fine-grained.

The advantage is that it can be divided into different micro-services for different functions, so as to choose different technologies and products, such as using document database to store post content, using graph data to store friends circle, or to test new technology, etc. Other things like system resiliency, scaling, simplified deployment, composition, etc. have advantages.

The disadvantages are mainly increased complexity, and system instability. This is a result of a comprehensive measure. On the one hand, divided into different micro-services, may be conducive to clear business logic, reduce the coupling degree of the whole system, and become simple; but a system, now a few small systems, the system is more, and complex; Originally a single system, there is a place error, it is likely that the entire system has collapsed, but divided into micro-service, Single fault, others can be used, enhance the usability of the system, but because the communication between the multiple microservices, it is likely to be distributed, but it brings more uncertainties.

Five, architecture design
Architectural styles are architectural patterns. All of these patterns have their own routines, and they have universal practicality and reusability at the high level of abstraction. Through architectural patterns, architects can draw on and reuse the experience of others to see how similar problems others have solved, but this is only a way to solve the problem, not a rigid rule.

The architecture design model typically has an evolutionary delivery life cycle model. In this model, the architecture design has a small number of key requirements can begin to start, the framework as a skeleton, on the skeleton loop iteration, gradually grow a body of flesh and blood system. The attribute-driven design method is a method of defining the schema. Divide the module according to the mass attribute.

Once the module has been decomposed, it can be assigned to the development teams. This predicate organizes development teams by architecture.

Vi. documentation of software architectures
Documenting the software architecture is writing the schema document. On the one hand, the writing process prompts architects to think further, the process of document writing is the process of organizing ideas, on the other hand, the document is the result of architectural development for project stakeholders to use:
The programmer wants to get the limits and the scope of the license, and the test and integration team gets the test black box, and the project manager gets the task, sets up the development team, plans and allocates resources.
UML is the de facto standard notation for writing schema documents.

vii. evaluation of software architecture
(i) Assessment methodology
1. Survey Questionnaire
2. Scenario-based
The level of support for the scenario is analyzed by analyzing the software architecture to determine the level of satisfaction with the quality requirements of the architecture. Yes

Architectural Tradeoff Analysis method
Software Architecture Analysis Method

3, based on measurement

(ii) Structural trade-offs analysis Method
Evaluate the software architecture from a technical perspective, anticipate the quality of the software through analysis, and create, select, evaluate and compare different architectures.

(iii) Cost-benefit analysis Method
The cost-benefit analysis method is built on the basis of architectural tradeoff analysis, which is used to model the cost and revenue of architecture design decision, and is a means to optimize such decision-making. The idea is that the architecture strategy affects the quality attributes of the system, which in turn results in the benefit of these quality attributes.

Viii. components and their reuse
component is the basis of reuse.

Ix. product line and system Evolution
Using architecture technology to build product line, and on this basis through the continuous evolution of reuse technology, and constantly introduce new products to meet the needs of product upgrading.