Software Architecture Chapter 2 Software Architecture Modeling
foreword
This article is based on the bloggers during the XJU undergraduate period"Software Architecture Principles, Methods and Practice" Second EditionThe summary of the final test points, because it is a key summary of the classroom, so please forgive me for not covering some important knowledge points. The final course requirements of each school are different. If you want to learn the software architecture completely, please read Mr. Zhang Yousheng "Software Architecture Principles, Methods and Practice".
Table of contents
Readers can jump to the test summary of any chapter through the content link, or search through the [Software Architecture] column on my homepage. Welcome everyone to follow me or subscribe to the column you are interested in, and I will update the corresponding content regularly. If the summary of the test points in this series is helpful to you, please like it at the bottom of the page or leave a message in the comment area.
Summary
1. Five models of software architecture (the most commonly used models are structural model and dynamic model):
- structural model
- frame model
- dynamic model
- process model
- Functional model
2. "4+1" view model:
The "4+1" view model proposed by Kruchyen in 1995, "4+1" view model from 5 different perspectives (logic view, process view, physical view, development view and scene view) to describe the software architecture. Each view only cares about one aspect of the system, and the combination of five views can reflect the entire content of the system's software architecture.
logical view
The logical view mainly supports the functional requirements of the system, that is, the services provided by the system to end users.
Features:
- In the logical view, the system is decomposed into a series of functional abstractions mainly drawn from the problem domain.
- In object-oriented technology, through abstraction, encapsulation and inheritance, object models can be used to replace logical views, and class diagrams can be used to describe logical views.
development view
The development view, also known as the module view, mainly focuses on the organization and management of software modules.
Features:
- The development view is described by the model diagram and subsystem diagram of the system input-output relationship.
- The style used to develop views is usually the hierarchical style.
process view
The process view, also known as the concurrent view, focuses on the operating characteristics of the system, mainly focusing on some non-functional requirements, such as system performance and availability.
Features:
- The process view emphasizes concurrency, distribution, system integration, and fault tolerance, and how the main abstractions from the logical view fit into the process structure.
- The process view can be described as multiple layers of abstraction, with each level focusing on a different aspect.
- There are many styles suitable for process view, such as pipe and filter style, client-server style, etc.
physical view
The physical view mainly considers how to map software to hardware, and it usually takes system performance, scale, reliability, etc. into consideration. Solve problems such as system topology, system installation, and communication.
Features:
- The physical view of a large system can get quite confusing, so it can appear in multiple forms along with the mapping of the process view, or by itself.
Scenario View (Use Case View)
Scene can be regarded as the abstraction of those important system activities, which organically links the four views. In a sense, scene is the most important requirement abstraction.
Features:
- Scenes can be represented textually or graphically
- Scene views can be used to help designers find architectural components and their functional relationships.
- You can use the scene view to analyze a particular view, or to describe how different view components interact.
3. Connections between "4+1" views
- Logical view and development view describe the static structure of the system, while process view and physical view describe the dynamic structure of the system.
- For different software systems, the angle of emphasis is also different.
4. The core model of software architecture
The core model of the architecture consists of five elements: components, connectors, configurations, ports, and roles. Among them, components, connectors and configurations are the most basic elements.
- A component is a reusable software template unit with a certain function, representing the main computing elements and data storage in the system. There are two types of components: composite components and atomic components. Composite components are connected by other composite components and atomic components. Atomic components are components that cannot be subdivided.
- Connectors represent the interaction between components, simple connectors such as pipelines, procedure calls, time broadcasting, etc., complex interactions include client-server communication protocols, SQL connections between databases and applications, etc.
- Configurations represent the topological logic and constraints of components and connectors.
- (This sentence can be understood) As an encapsulated entity, a component can only interact with the external environment through its interface. The interface of the component consists of a set of ports, and each port represents the interaction point between the component and the external environment. A component can provide multiple interfaces through different port types. A port can be as simple as a procedure call, or it can represent a more complex interface such as a set of procedure calls that must be invoked in some order.
5. The life cycle of software architecture
- Informal description of software architecture
- Specification description and analysis of software architecture
- Refinement and Verification of Software Architecture
- Implementation of software architecture
- Evolution and extension of software architecture
- Presentation, evaluation and measurement of software architecture
- The end of software architecture
conclusion
The above is the content of the second chapter of the test points summarized by the blogger. It is being updated continuously. Welcome everyone to pay attention to me. If you make any mistakes, please point them out in the comment area. Finally, I wish all the friends who are going to take the exam will pass every exam!