Soft Exam-System Architect (Software Architecture Design)

Definition of architecture

     The software architecture is still evolving, and a unified and recognized definition has not yet been formed. Here are just a few more authoritative definitions.

1. The software architecture of a software or computer system is one (or more) structure of the system, and the structure is composed of software elements, the externally visible attributes of the elements, and the relationships between them.

2. The software architecture provides a high-level abstraction of structure, behavior, and attributes for the software system . It is composed of the description of the elements that constitute the system, the interaction of these elements, and the constraints of the mode that guides the integration of the elements.

3. Software architecture refers to the basic knowledge of a system, which is embodied in: the components of the system, the relationship between components, components and the environment, and the principles that guide its design and evolution. (IEEE1471-2000)
   
   
   From a technical point of view, the importance of software architecture :

   1. A platform for communication between project stakeholders

   2. Early design decisions. From the perspective of the software life cycle, the software architecture is the embodiment of the earliest design decisions of the developed system.
      The performance is as follows: (1) The architecture clarifies the constraints on the implementation of the system; (2) The architecture affects the quality attributes of the system; (3) The architecture can be used to predict the quality of the system; (4) The architecture provides a basis for maintenance decisions; (5) Architecture helps prototype development.

   3. Realize software reuse at a higher level

   4. The guidance and normative significance of architecture to development cannot be ignored

     The architecture-based software development model clearly divides the entire software process into six sub-processes: architecture requirements, design, documentation, review (evaluation), implementation, and evolution.

Architectural model

The most commonly used are structural models and dynamic models.

1. Structural model . This is one of the most intuitive and common modeling methods. This method uses architectural components, connectors, and other concepts to describe the structure, and tries to reflect the important semantic content of the system through the structure, including the configuration, constraints, implicit assumptions, style, and nature of the system. The core of the research structure model is the architecture description language .
2. Framework model . The frame model is similar to the structural model, but it focuses less on the details of the structure and more on the overall structure . The framework model mainly aims at some special problems and establishes an organization that only addresses and adapts to the problems.
3. Dynamic model . The dynamic model is a supplement to the structure or frame model and studies the behavioral properties of the "large particles" of the system. For example, describe the reconfiguration and evolution of the system. Dynamic may refer to the configuration of the overall structure of the system, the establishment or detection of communication channels or the process of calculation.
4. Process model . Process model studies the steps and processes of constructing a system. So the structure is the result of following certain process scripts.
5. Functional model . The model believes that the architecture is composed of a set of functional components hierarchically, and the lower layer provides services to the upper layer. It can be regarded as a special framework model.

The "4+1" view model describes the software architecture from five different perspectives, including logical view, process view, physical view, development view, and scene view. Each view only cares about one side of the system, and the combination of the five views can reflect the entire content of the system's software architecture. As shown below:

View name	Features	focus point	Follow people
Logical view	The functional requirements of the main support system	Describe system functions	user
Development view (module view, realization view)	Mainly focus on the organization and management of software modules	Describe system configuration and assembly	Programmer
Process view	Focus on the operating characteristics of the system, some non-functional requirements	Describe system performance and throughput	System integrator
Physical view	Mainly consider how to map software to hardware	Describe system installation, topology, communication, etc.	system engineer
Scene view (use case view)	Connect the four views organically	Describe the system behavior of human-computer interaction	Analysts and testers

Software quality attributes

Case Analysis Frequent Exam

Attributes	Sub-attribute	Function and key points	preventive solution
performance		Efficiency index: the time required to process the task or the amount of processing per unit time	Increase computing resources, reduce computing overhead, introduce concurrency mechanisms, and resource scheduling
reliability	Fault tolerance	After an error occurs, the system can still operate normally, and the error can be corrected by itself	Active redundancy
	Robustness	The error does not affect the system, and the error is ignored according to the established procedure
Availability		Uptime ratio	Heartbeat, Ping/Echo, active redundancy, passive redundancy, election
safety		The ability of the system to provide services to legitimate users and organize illegal users	Intrusion detection, user authentication, user authorization, tracking audit, restricted access
Modifiable	Maintainability	Minimize the negative impact of local repair failures on the architecture	Generalization of software modules, restriction of communication between modules, use of intermediary and delayed binding, runtime registration, separation of interface realization, information concealment
	Scalability	Due to loose coupling, it is easier to implement new features/functions without affecting the architecture
	Restructuring	Does not affect the flexible configuration of the main body
	portability	Suitable for various environments (hardware platform, language, operating system)
Feature		Satisfaction of needs	Build collaboration
Variability		Variable overall structure	Pre-defined rules as the basis of related products
Interoperability		Provide a better interactive operation experience through visualization or interface	Interaction
Testability		The ability of software to find faults and isolate them, and locate their faults	Record playback

Software architecture style

This part has a lot of content, and I have summarized another article
Soft Exam-System Architect (Software Architecture Style)

Hierarchical system architecture style

Two-tier C/S architecture

Reasons for the proposal : The C/S architecture is based on unequal resources and is proposed for sharing

Structure : The C/S structure divides the application into two, the server (backstage) is responsible for data management, and the client (front stage) completes the interactive tasks with the client.

Advantages : The C/S software architecture has powerful data manipulation and transaction processing capabilities, and the model thinking is simple, easy to understand and accept with people.

Limitations : (1) The second-tier C/S structure is a single server and the local area network is the center, so it is difficult to expand to the WAN or Internet of large enterprises;
            (2) The combination and integration capabilities of software and hardware are limited;
            (3) The server load is too large It is difficult to manage a large number of clients, and the performance of the system is easy to deteriorate;
            (4) Data security is not good.

Three-tier C/S architecture

Structure : divide the application function into three parts: presentation layer, function layer and data layer

• Presentation layer: It is the user interface part of the application, which is responsible for the dialogue function between the user and the application. It is used to check the data input by the user from the keyboard, etc., and display the data output by the application. When changing the user interface, only the display control and data checking procedures need to be modified without affecting the other two layers. The content of the inspection is also limited to the form of the data and the range of values, and does not include the processing logic of the business itself.
• Function layer: equivalent to the ontology of the application, which is to program specific business processing logic. The data needed for processing must be obtained from the presentation layer or the data layer. The data interaction between the presentation layer and the functional layer should be as concise as possible.
• Data layer: It is the database management system, which is responsible for managing the reading and writing of database data. The database management system must be able to quickly update and retrieve large amounts of data. Therefore, most of the requirements transmitted from the functional layer to the data layer use the SQL language.

Solution : Clearly separate these three layers and make them logically independent. The original data layer has been independent as a database management system. Therefore, the key is to separate the presentation layer and the function layer into separate programs, and to make the interface between the two layers concise and clear. Generally speaking, only the presentation layer is configured in the client. If the functional layer is also placed in the client, the maintainability of the program is much better compared with the two-layer C/S structure, but other problems are not has been solved. The client's load is too heavy, and the data required for its business processing has to be transmitted from the server to the client, so the performance of the system is likely to deteriorate. If the functional layer and the data layer are placed in different servers, data transmission between the server and the server must be carried out. However, since the three layers are placed on separate hardware systems in this form, they are highly flexible and can adapt to the increase in the number of clients and changes in processing load.

B/S architecture style

Using technology : The B/S structure mainly uses the increasingly mature WWW browser technology, combined with the browser’s multiple scripting languages, and uses a general-purpose browser to achieve powerful functions that originally required complex special software to achieve, and save development cost.

Advantages : software based on B/S architecture, system installation, modification and maintenance are all solved on the server side (zero client), and it is easy to automatically upgrade during runtime. It can also make full use of various resources on the network, and the workload of application maintenance is also greatly reduced.

Disadvantages : (1) The B/S architecture lacks the ability to support dynamic pages and does not integrate effective database processing functions;
           (2) The application architecture of the B/S architecture requires a far slower response speed for data queries, etc. In the C/S architecture;
           (3) The data submission of the B/S architecture is generally based on the page unit, and the dynamic interactivity of the data does not grab, which is not conducive to the online transaction processing (OnLine Transaction Processing, referred to as OLTP) application.

MVC architectural style

Definition : The full name is Model ViewController, which is an abbreviation of model-view-controller, a type of hierarchical architecture.

Division of labor and cooperation :

• Model is an encapsulation of application status and business functions. The Model accepts the Controller's request and completes the business processing of the response, and sends a corresponding notification to the View when the state changes.
• View realizes the presentation of the visual interface and captures the interactive operations of the end user (such as mouse and keyboard operations).
• The Controller will control the original View or create a new View as needed to respond to user interaction. The View captures the user interaction and forwards it directly to the Controller, which completes the corresponding UI logic. If there is a need to call a business function, the Controller will directly call the Model.

MVP architectural style

Definition : The full name is Model-View-Presenter. MVP evolved from MVC.

Similarities with MVC : The basic ideas have similarities: Model provides data, View is responsible for display, and Controller/Presenter is responsible for logic processing.

Difference from MVC : The "chaotic" interaction between elements in the MVC pattern is mainly reflected in allowing the View and Model to directly "communication", which is not allowed in MVP. View does not directly use Model in MVP. The communication between them is carried out through Presenter (Controller in MVC). All interactions occur inside Presenter. In MVC, View directly reads data from Model. Instead of going through the Controller.

Disadvantages : Since the rendering of the view is placed in the Presenter, the interaction between the view and the Presenter will be too frequent. One more thing to understand is that if the Presenter renders the view too much, it will often make it too closely related to the specific view. Once the view needs to be changed, then the Presenter also needs to be changed.

Advantages : (1) The model is completely separated from the view, and we can modify the view without affecting the model;
           (2) The model can be used more efficiently, because all interactions occur in one place-inside the Presenter.
           (3) We can use one Presenter for multiple views without changing the logic of Presenter. This feature is very useful, because the view changes more frequently than the model changes;
           (4) If we put the logic in the Presenter, then we can test the logic without the user interface (unit testing).

Service Oriented Architecture (SOA)

Typical definitions: (1) W3C definition: SOA is an application-level architecture. In this architecture, all functions are defined as independent services. These services have well-defined callable interfaces that can be Call these services sequentially to form a business process.
                      (2) The definition of Service-architecture.com: A service is a function that is precisely defined, encapsulated, and independent of the environment and status of other services. SOA is essentially a collection of services. Services communicate with each other. This communication may be a simple data transfer, or two or more services coordinate to perform certain activities. Some methods are needed to connect between services.
                      (3) Gartner's definition: SOA is a C/S architecture software design method. The application is composed of services and service users. SOA is different from most common C/S architecture models in that it emphasizes component Loosely coupled and use independent standard interfaces.

**Overview: **SOA is a method of designing, developing, deploying, and managing discrete logical unit (service) models in a computing environment. Because SOA considers the objects in the system, although SOA is object-based, it is not object-oriented as a whole.

The basic structure of the service:

SOA design principles:

1. Well-defined interface
2. Self-contained and modular
3. Coarse-grained
4. Loosely coupled
5. Interoperability, compatibility and policy statement

The difference between SCA service components and traditional components : service components are often coarse-grained, while traditional components are mostly fine-grained; the interface of the service architecture is standard, mainly the service description language interface, while traditional components often appear in the form of specific APIs; The realization of service components has nothing to do with language, and traditional components are often bound to a specific language; service components can provide QoS services through component containers, while traditional components are completely controlled by program code.

The key technology of SOA: These technologies are developed based on XML.

UDDI	Unified description, discovery and integration	Data model; API; registration service
WSDL	Web service description language	Service implementation definition includes: service, port; service interface definition includes: binding, port type, message, type
SOAP	Simple Object Access Protocol	Defines the message transmission specifications between service requests and service providers. SOAP includes: encapsulation, encoding rules, RPC representation, and binding. The SOAP message contains: encapsulation (envelope), SOAP header, and SOAP body.
REST	Representational state transition	It is a technology that only uses HTTP and XML for Web-based communication, which can reduce the complexity of development and improve the scalability of the system.

SOA implementation method:

1. Web Service

2. Service registry

(1) Service registration
(2) Service location
(3) Service binding

3. Enterprise Service Bus (ESB)

Content: ESB provides an infrastructure that eliminates the direct connection between service requesters and service providers, and further decouples service requesters and service providers. EJB is a set of infrastructure that is implemented by middleware technology and supports SOA. It is a product of the combination of traditional middleware technology with technologies such as XML and Web Service. It is a service-oriented enterprise application integration mechanism under the entire enterprise integration architecture.

Functions: (1) Support services, messages, and event-based interactions in a heterogeneous environment, and have appropriate service levels and manageability; (2) By using ESB, it is possible to achieve one-to-one performance with almost no code changes. A seamless and non-intrusive way makes the existing system have a brand-new service interface, and can support any standard in the deployment environment; (3) The ESB that acts as a buffer is separated from the service logic, so that different systems can use the same at the same time Service, there is no need to change the service code when the system or data changes; (4) At a higher level, ESB also provides functions such as service agent and protocol conversion; (5) Head attack configurable message conversion and translation mechanism and based on Message routing service for message content, transmitting messages to different destinations.

Advantages: (1) Extended, standards-based connection; (2) Flexible and service-oriented application portfolio; (3) Increased reuse rate and reduced costs; (4) Reduced market response time and increased productivity.

Microservice

Advantages: (1) technology heterogeneity; (2) flexibility; (3) expansion; (4) simplified deployment; (5) matching with organizational structure; (6) combinable type; (7) compatibility with substitutability optimization

Challenges: (1) complexity of distributed systems; (2) operation and maintenance costs; (3) deployment automation; (4) DevOps and organizational structure; (5) inter-service dependency testing; (6) inter-service dependency management

Microservices and SOA:

Architecture design

Software architecture documentation

Content : The first is the process. The documentation process can prompt the architect to think further and make the architecture more perfect; the second is the result. The document describing the architecture will be used by the project stakeholders as the success of the architecture development.

The user of the architecture document: the project stakeholders of the architecture. One of the most basic principles of writing technical documents is to write from the reader's point of view.

Filing rules:

1. Write the document from the reader's point of view
2. Avoid unnecessary repetition
3. Avoid ambiguity
4. Use standard structure
5. Basic Principles of Recording
6. Keep the document up to date, but not too frequently
7. Review the documentation for the suitability of the target

View file:

Software architecture evaluation

method:

1. Based on questionnaires or checklists (depending on the subjective inference of the evaluator)
2. Scenario-based approach: applied in the Architecture Tradeoff Analysis Method (ATAM) and Software Architecture Analysis Method (SAAM). It analyzes the extent to which the software architecture supports the scene to determine the extent to which the architecture satisfies the quality requirements represented by the scene.
3. Measurement-based approach: based on software architecture measurement

Architecture Tradeoff Analysis Method (ATAM)

step:

• Expression of the ATAM method: the person in charge of the assessment introduces ATAM to the project representatives attending the meeting
• Expression of business motivation
• Representation of the structure
• Categorize architectural methods
• Generate quality attribute utility tree
• Analyze the architecture method
• Brainstorm and prioritize scenarios
• Analyze the architecture method
• Presentation of results

Information obtained by analysis:

• Documented architectural approach
• The set of scenes and their priorities after discussion
• Utility tree
• Risky decision
• Documented risk-free decisions
• Sensitive points and trade-offs found