Click to enter the series of articles directory
现在的一切都是为将来的梦想编织翅膀，让梦想在现实中展翅高飞。
Now everything is for the future of dream weaving wings, let the dream fly in reality.
System Architecture Design · Basics (1) [System Architecture Designer]
- 1. The concept of software architecture★★★
- 2. Software architecture style★★★★★
- 3. Architecture-based software development method (ABSD)★★★★
- 4. Domain-Specific Software Architecture (DSSA)★★★
- 5. Reuse of software architecture★★★
1. The concept of software architecture★★★
1.1 Definition of software architecture
software architecture concepts
Software Architecture = Software architecture
refers to one or more structures of the system. The structure includes:
(1) Structure - the components of the software (which may be program modules, classes, or middleware)
(2) Attributes - components Externally visible properties
(3) Interaction - the relationship between components
The nature of software architecture
Software architecture provides a high-level abstraction of the structure, behavior, and properties of a software system . A software architectural style is an idiomatic pattern
for a specific application domain . The architecture defines a vocabulary and a set of constraints .
The role of software architecture
Software architecture is the means by which project stakeholders communicate .
Software architecture is a transferable and reusable model , and it is possible to predict the quality of software by studying software architecture.
Software architecture makes reasoning and controlling changes simpler, facilitates step-by-step prototyping , and can serve as the basis for training.
Requirements analysis → Architecture (bridging the gap from requirements to design) → Software design
Architecture design is the allocation of requirements, which allocates the responsibility for meeting the requirements to components .
Software architecture design is comprehensively described through multiple views - 4 + 1 view .
1.2 Software architecture design 4 + 1 view
Perspectives and Views:
Examine from different perspectives, so there will be different views.
Kruchten proposed a "4+1" view model in 1995. The "4+1" view model describes the software architecture from 5 different perspectives including logical view, process view, physical view, development view and scene view. Each view only cares about one aspect of the system. Only the combination of five views can reflect the entire content of the system's software architecture.
Logical view : Mainly supports the functional requirements of the system, that is, the services provided by the system to end users. The main issue to pay attention to in logical view design is to maintain a single, cohesive object model throughout the entire system and describe the relationship between the object model and objects.
Development view : Also known as module view, it mainly focuses on the organization and management of software modules. The development view is described through model diagrams and subsystem diagrams of system input and output relationships. You can describe the complete development perspective after identifying all the elements that the software contains, or you can list the development view principles before identifying each element.
Process view : Also known as process view. Focus on the operating characteristics of the system, mainly focusing on some non-functional requirements, such as system performance and availability. The process view emphasizes concurrency, distribution, system integration and fault tolerance, as well as the process structure as the main abstraction in the logical view. The process view can be described as multiple levels of abstraction, with each level focusing on different aspects.
Physical view : Mainly considers how to map software to hardware. It usually takes into account solving problems such as system topology, system installation, and communication.
Scenario : can be seen as an abstraction of those important system activities, which organically connects the four views. In a sense, the scenario is the most important abstraction of requirements. When developing an architecture, it helps designers find the components of the architecture and the relationships between them. Scenarios can also be used to analyze a specific view, or to describe how different view components interact with each other. Scenes can be represented textually or graphically.
The logical view and development view describe the static structure of the system , while the process view and physical view describe the dynamic structure of the system . For different software systems, the focus angles are also different. For example, for management information systems, more emphasis is placed on describing the system from the logical view and development view, while for real-time control systems, more emphasis is placed on describing the system from the process view and physical view.
1.3 Software architecture design and life cycle
Software architecture runs through the entire life cycle, and different stages have different functions and meanings . The architecture work performance table of each stage:
| stage | Function and significance |
|---|---|
| requirements analysis stage | It is conducive to communication among participants at each stage, and it is also easy to maintain the traceability of each stage. The conversion of software requirements model to software architecture model focuses on two issues: 1) How to build a software architecture model based on the requirements model 2) How to ensure the traceability of model conversion |
| design phase | Focus on the earliest and most numerous stages. The research at this stage mainly includes: 1) Description of software architecture model 2) Design and analysis methods of software architecture model 3) Summary of software architecture design experience and description of reuse architecture model Research includes: ① Composition of SA (software architecture) Model - modeling of components and connections ② Architecture Description Language (ADL) ③ Multi-view - 4 + 1 view Three basic elements of ADL: 1) Component: computing or data storage unit, including components and corresponding component interfaces 2) Connectors: architectural building blocks for modeling interactions between components and the rules that govern these interactions 3) Architecture configuration: connection diagrams describing the components and connectors of the architecture ADL is used for modeling and is some pseudocode |
| implementation stage | Effectively realize the transformation from software architecture design to implementation. Architecture research at this stage includes: 1) Support based on the architecture development process 2) Seeking ways to transition from architecture to implementation 3) Research on architecture-based testing technology |
| component assembly stage | The design of reusable component assembly can improve the efficiency of system implementation. The research contents at this stage include: 1) How to support the interconnection of reusable components, that is, to provide support for the implementation of connectors specified in the architectural design model 2) How to detect and eliminate architectural mismatch problems and adaptation problems during the assembly process Mainly include: ① Adaptation of the component itself ② Mismatch of connectors (interconnection mechanism) ③ Mismatch between parts and the whole |
| Deployment phase | Organize and present the software and hardware architecture during the deployment phase, and evaluate and analyze deployment plans. The role of software architecture in the deployment stage on software deployment: 1) Provide a high-level architectural view to describe the software and hardware model in the deployment stage 2) Based on the software architecture model, the quality attributes of the deployment plan can be analyzed to select a reasonable deployment plan |
| post development stage | Mainly around maintenance, evolution, and reuse. System architecture research directions after deployment and installation (post-development stage) include: 1) Dynamic software architecture 2) Architecture recovery and reconstruction |
1.4 The Importance of Software Architecture
Software architecture design is a key factor in reducing costs, improving quality, and delivering products on time and on demand.
2. Software architecture style★★★★★
- An architectural style defines a glossary of terms used to describe a system and a set of rules to guide building it.
- Architectural style reflects the structural and semantic characteristics shared by many systems in the field, and guides how to effectively organize various components into a complete system.
- A software architectural style is an idiomatic pattern for a specific application domain. The architecture defines a vocabulary and a set of constraints.
2.1 Five classic styles of software architecture
| Five architectural styles | sub style |
|---|---|
| data flow style | batch, pipeline-filter |
| call/return style | Program/Subroutine, Object Orientation, Hierarchy |
| data-centric style | Database system, blackboard system, hypertext system |
| Virtual machine style | Interpreter, rule system |
| independent component style | Process communication, event-driven system (implicit call) |
2.1.1 Data flow architectural style
| advantage | shortcoming | Typical examples |
|---|---|---|
| 1、松耦合【高内聚-低耦合】 2、良好的重用性/可维护性 3、可扩展性【标准接口适配】 4、良好的隐蔽性 5、支持并行 |
1、交互性较差 2、复杂性高 3、性能较差（每个过滤器都需要解析与合成数据） |
传统编译器 网络报文处理 |
2.1.1.1 批处理风格
批处理风格的每一步处理都是独立的，并且每一步是顺序执行的。数据必须是完整的，以整体的方式传递。
2.1.1.2 管道/过滤器风格
在管道/过滤器风格的软件架构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。
2.1.2 调用/返回系结构风格
2.1.2.1 主程序/子程序风格
主程序/子程序风格是结构化开发时期的经典架构风格。这种风格一般采用单线程控制，把问题划分为若干处理步骤，构件即为主程序和子程序。子程序通常可合成为模块。过程调用作为交互机制，即充当连接件。
2.1.2.2 面向对象风格
这种风格的构件是对象，或者说是抽象数据类型的实例。对象是一种被称作管理者的构件，它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。
2.1.2.3 层次结构风格
层次系统组织成一个层次结构，每一层为上层服务，并作为下层客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层只对相邻的层可见
2.1.3 以数据为中心系结构风格
2.1.3.1 仓库结构风格
数据库系统是仓库风格最常见的形式。在数据库系统中，构件主要有两大类，一类是中央共享数据源，保存当前系统的数据状态；另一类是多个独立处理单元，处理单元对数据元素进行操作。
2.1.3.2 黑板结构风格
黑板系统包括知识源、黑板和控制三个部分。知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板；黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯一媒介；知识源响应是通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中，例如，信号处理、问题规划和编译器优化等。语音识别、知识推理。
2.1.3.3 超文本系统风格
超文本系统中出现的构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。超文本是一种非线性的网状信息组织方法，它以结点为基本单位，链作为结点之间的联想式关联。超文本系统通常应用在互联网领域。
2.1.4 虚拟机体系结构风格
2.1.4.1 解释器风格
解释器通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，其缺点是执行效率比较低。
2.1.4.2 规则系统风格
基于规则的系统包括规则集、规则解释器、规则/数据选择器和工作内存，一般用在人工智能领域和DSS中。
2.1.5 独立构件体系结构风格
2.1.5.1 进程间通信风格
构件是独立的过程，连接件是消息传递，构件通常是命名过程，消息传递的方式可以是点对点，异步或者同步的方式，以及远程过程方法调用等。
2.1.5.2 事件驱动系统风格（隐式调用）
构件不直接调用一个过程，而是触发或广播一个或多个事件。这种风格中的构件是匿名的过程，它们之间交互的连接件往往是以过程之间的隐式调用（implicit invocation）来实现的。基于事件的隐式调用风格的主要优点是为软件复用提供了强大的支持，为构件的维护和演化带来了方便，其缺点是构件放弃了对系统计算的控制。
2.2 C2风格
C2风格通过连接件连接构件或某个构件组，构件与构件之间无连接。
软件体系结构设计的一个核心问题就是能否使用重复的体系结构模式，即能否达到体系结构级的软件重用。
C2 = EBI（基于事件的集成）+ LCS（分层客户端服务器）
C2是一种基于构件和消息的架构风格，可用于创建灵活的，可伸缩的软件系统。可以将架构看作是按照一定规则由连接件如消息路由设备连接的许多构件组成的层次网络系统中的构件和连接件都有一个“顶部”和“底部”;一个构件的“顶部”或“底部”可以连接到一个连接件的“底部”或“顶部”;对于一个连接件，和其相连的构件或连接件的数量没有限制，但是构件和构件之间不能直接相连。
C2架构的基本规则：
- 构件和连接件都有一个顶部和一个底部。
- 构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部，构件之间不允许直连。
- 一个连接件可以和任意数目的其他构件和连接件连接。
- 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。
2.3 闭环风格
- 适用于嵌入式系统，用于解决简单闭环控制问题。
- 经典应用：空调温控，定速巡航。
三、基于架构的软件开发方法（ABSD）★★★★
3.1 体系机构设计的方法概述
基于架构的软件设计（ABSD，Architecture-Based Software Design）是一种架构驱动方法，架构驱动也就是说架构先行，需求获取和分析还没有完成就开始架构设计，需求获取和分析与架构设计并行，例如产品线系统和长期运行的系统，我们不可能开始就能决定所有的需求。
ABSD强调由业务、质量和功能需求的组合驱动架构设计 ，强调采用 视角和视图 来 描述软件架构 ，采用 用例（功能需求）和质量场景（质量需求） 来 描述需求 。
ABSD方法有三个基础：
- 第一个基础是功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术。
- 第二个基础是通过选择架构风格来实现质量和业务需求。
- 第三个基础是软件模板的使用。
3.2 基于架构的开发模型（ABSD）
传统的软件开发过程是问题定义，需求分析，软件设计，实现，测试。ABSD把整个软件过程分成六个部分，架构需求，设计，文档化，复审，实现，演化六个步骤。
四、特定领域的软件架构（DSSA）★★★
DSSA（Domain Specific Software Architecture）特定领域软件架构，可以看做开发产品线的一个方法或理论，目标就是支持一个特定领域中多应用的生成。
4.1 特定领域的软件架构 - 基本活动
（1）建立领域模型，一个严格定义的问题域或解决域。其中，垂直域是在相同领域中深入；水平域是在不同领域中平移。
（2）具有普遍性，使其可以用于领域中某个特定应用的开发。
（3）对整个领域的合适程序的抽象。
（4）具备该领域固定的、典型的在开发过程中的。可复用元素。
4.2 特定领域的软件架构 - 领域分析机制
4.3 特定领域的软件架构 - 建立过程
五、软件架构的复用★★★
-
Definition and classification of software architecture reuse Software architecture
reuse is a systematic software development process: developing a set of basic software component modules to cover similarities between different requirements/architectures and improve the efficiency and quality of system development and performance. -
The reasons for software architecture reuse are
to reduce development work, reduce development time, reduce development costs, increase productivity, improve product quality, and achieve better interoperability. -
Objects and forms of software architecture reuse Reusable
assets include: requirements, architectural design, elements, modeling analysis, testing, project planning, process + methods + tools, personnel, sample systems, and defect elimination.
General forms of reuse include: reuse of functions, reuse of libraries, and reuse of classes, interfaces, and packages in object-oriented development. -
The basic process of software architecture reuse
(1) First build/obtain reusable software assets (prerequisite for reuse);
(2) Manage reusable assets;
(3) Use reusable assets.