Course-CSDN博客

本文链接：https://blog.csdn.net/CROSS__over/article/details/139552988

Course

1. overview

1.1 history
1.2 definition of software architecture
1.3 related concepts
1.4 influencing factors
1.5 value of 软件架构

2. Data Flow 数据流

2.1 Batch Sequential批处理
2.2 pipe-and-filter
两者比较

3. Event system 事件系统

3.1 关于事件系统

3.2 两种调度机制 dispatch mechanism

3.2.1 EventManager without dispatcher module 无独立调度派遣模块
3.2.2 EventManager with dispatcher module 有独立调度派遣模块

3.3 优缺点

4. Call/Return 调用返回

4.1 定义

4.2 main program & subroutine

4.3 object oriented style

4.4 layered system style

4.5 client/server style

4.5.1 two tier双层C/S架构
4.5.2 three tier三层C/S架构

5. Data Center 数据中心

5.1 repository 仓库风格
5.2 blackboard 黑板风格

6. Virtual Machine 虚拟机

6.1 interpreter解释器
6.2 rule-based system基于规则的系统
6.3 other

7 软件架构描述

7.1 description

7.1.1 function

7.2 modelling

8. availability 可用性

9. modifiability 可修改性

10. performance 性能

11. security 安全性

12. usability 易用性

13. testability 可测试性

14. evaluation 评估

14.1 评估
14.2 ATAM

1. overview

软件体系架构是一种 description 关于 high-level structure of 复杂的软件系统，interrelationship交互关系关于organizational units，以及相关的活动，比如design, evaluation implementation, management

1.1 history

好的架构甚至比算法和数据结构更重要
当今系统开发越来越复杂，需要合理的架构来保证系统的正常运行

1.2 definition of software architecture

由单人建造：minimal建模，simple process，simple tools
团队建造最有效：modeling，well-defined process，power tools

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them

Architecture is the organizational structure of a system. An architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts. Parts that interact through interfaces include classes, components and subsystems.

Software architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

elements
- functions, interfaces, programs, class modules, layers, subsystems, client/server
visible properties
- service, performance characteristics, fault handling, shared resource usage
relations
- composition mechanism and style of these elements.元素之间的组成结构
architecture is the result of a set of business and technical decisions . 是商业和技术结合的结果，因为要牟利

架构包括以下内容

Component组件：这些组件是系统的基本构建块，可以是类、模块、服务或子系统。组成元素。

组件是具有某种功能的可复用的软件结构单元，表示系统中主要的计算元素 和 数据存储。

组件是一个抽象的概念，在程序中可以指程序函数、模块、对象、类

Connector连接件：指组件之间的通信桥梁，负责在组件之间传递数据和控制信息。连接不同软件组件或服务的接口或中间件，例如数据库连接池、消息队列连接器等。组件之间的交互方式，包括调用关系、数据流、控制流等

Constraint约束：在软件设计中可能指代对系统设计或实现的限制条件，这些条件可以是技术限制、业务规则、法规要求等，它们影响着架构和组件的设计决策。

分解和耦合Decomposition/Composition：减少设计和结构的复杂度；降低开发的风险；改进组织和管理的效率

是否划分为更小的组件或子系统取决于如何更有效管理整个系统组织。要确保所有需要的模块都要覆盖。要注意各个块的组成性，是否能统筹管理操作

组件composition成system，system decomposition成组件。就是组件和系统是互相耦合和分解的。架构的设计还需要模板设计和经验

The components comprised in the system, and the relationships or interaction mechanisms of those components.

1.3 related concepts

Component is a logical and functional unit of the system
1. 一个组件也可也以被分为更小的组件，有certain responsibilities去执行一些操作或任务。会指向不同的具体对象modules, subsystems, layers, packages, classes
Connertor represents interaciton rules or mechanisms among components负责组件之间的交互规则和机制
功能属性：满足功能性需求的架构的characters
非功能属性：满足非功能性需求的架构的characters。比如性能，质量，灵活度，可扩展度，安全性，可靠性，可移植性portability
framework框架
1. 是针对某种特定问题的可重用应用程序基础设施
2. 包含specified problem需要的必要组件
3. 包含交互机制和constraints
4. 提供context和environment基于框架开发的app

架构处于high-enough level的abstraction，让system as whole。实现细节是隐藏的。必须满足功能性需求和非功能性需求

1.4 influencing factors

by system stakeholders
1. 客户，PM, 开发者，维护人员，架构师...需要多个视图和蓝图来表示项目的架构和模型
2. 每个人的需求和标准都不一样
developing organization
background and experience of architects
technical environment
开发流程
1. 创建商业样例，理解需求，创建或选择所需架构模式，做出对应的文档，分析评价当前的架构，基于确定好的架构进行开发，保证按照架构模式
为什么架构重要
1. 是vehicle for stakeholder communication, 相关者沟通的载体
2. 体现earliest set of 设计的决定 => 定义了约束和实现，决定组织架构，展示质量，检测质量，保证系统的开发容易管理，Evolutionary Prototyping，预估cost, risk, schedule
3. transferable, re-usable model. Software Product Lines Share a Common Architecture. Systems Can Be Built Using Large, Externally Developed Elements

1.5 value of 软件架构

serves both technical and organizational purposes
1. 组织: 内部，客户，供应商之间的沟通；提供系统的高层信息；cost和risk预估；工作分配和项目进度
2. 技术： 规定详细的设计，结构和测试的约束条件；启用系统distribution；降低维护和开发的cost；增加重用
好的架构的特征
1. Resilient, Simple, Approachable, Clear separation of concerns, Balanced distribution of responsibilities, Balances economic and technology constraints
2. 弹性灵活易实现职责均衡

基础架构模式

After a long period of practice, it has been proven to have good process feasibility, performance, and practicability, and can be directly used to follow and imitate (reuse). 重点在于重用性，很多项目可以根据已经存在的很成熟的风格来快速发展。

一个架构可以使用多个架构风格。描述一类体系结构。是证实过成功的解决方案

The software architectural style describes the idiomatic paradigm 习惯范例 of the organization of software system families in a specific domain, re-flects the structural and semantic characteristics shared by many systems in the domain, and guides how to effectively organize various modules and subsystems into a complete system.
意思就是软件架构风格描述特定领域中组织软件系统家族的习惯范式，反映了许多系统贡献的结构和语义特征，指导如何有效将各模块和子系统组织成完整的系统

经验，共用，可复用，doc

benefits

promote reusability 提高重用性 design，code，documentation reuse
Improves development efficiency and productivity 提高效率和生产力
Provide a starting point for additional and new design ideas 提供新想法
Promotes communications among the designers 优化交流
Quickly find an applicable SA design solution for a software system 快速找到合适的方案
Make trade-offs and pre-evaluate the SA of the system 权衡评估系统
Diminish the risks of SA design 降低risk

content 都要记住

name：每个体系风格都有唯一的简短的描述性名称
problem：都有对自己可以解决的问题的描述
context：上下文环境。是当前必须满足的条件，是一些需求
modules：描述当前风格内容
consequences：描述优缺点
implementation：实现建议
known uses：已知应用

2. Data Flow 数据流

无数据不工作

定义

数据的可用性决定computation计算单元是否执行
系统结构由数据在process和process之间的orderly motion决定
pure data flow中，处理之间除了数据的交换没有其他交换

Kimi: 数据流架构（Data Flow Architecture）是一种软件架构模式，它特别适用于处理数据流和数据转换。在这种架构中，数据通过一系列阶段或处理步骤流动，每个步骤可以对数据进行某种形式的处理或转换。数据流架构通常用于数据密集型应用，如数据管道（data pipelines）、实时分析系统、ETL（提取、转换、加载）过程和流处理系统。

数据流架构的关键特点包括：

数据流：数据在系统中以流的形式存在，可以是实时的或批量的。
处理阶段：数据流通过一系列处理阶段，每个阶段负责执行特定的数据处理任务。
解耦合：各个处理阶段通常是解耦的，这意味着它们可以独立于其他阶段运行，从而提高了系统的灵活性和可维护性。
可扩展性：系统可以通过添加更多的处理阶段或并行处理相同阶段来扩展。
容错性：数据流架构通常设计有容错机制，以确保在某个处理阶段失败时，整个系统仍然可以继续运行。
数据转换：数据在流经各个阶段时可能经历格式转换、清洗、聚合等操作。
异步处理：数据的处理通常是异步的，这意味着数据的产生和消费不需要同步进行。
缓冲：在处理阶段之间可能存在缓冲区，用于存储临时数据，以处理数据速率不匹配的问题。
监控和日志记录：数据流架构通常包括监控数据处理的机制，以及记录数据流动和处理状态的日志系统。
数据源和数据汇：数据流架构通常从一个或多个数据源开始，流向一个或多个数据汇（或称为数据池），数据汇可以是数据库、文件系统或其他形式的存储。

数据流架构在现代软件开发中非常重要，尤其是在需要处理大量数据流的系统中。例如，在构建实时推荐系统、日志分析系统、金融交易处理系统或任何需要实时数据处理和分析的应用时，数据流架构都是一个关键的组成部分。

components: data processing components
1. 接口是input ports和output ports 一个读取数据一个写出数据
connectors：data flow stream
1. unidirectional，asynchronous，buffered。单向，异步，缓冲
2. 接口是reader和writer

Kimi: 数据流架构通常指的是一种高层次的架构模式，它强调数据在系统中的流动和处理。然而，数据流架构可以进一步细化为两种常见的子模式：批处理架构和管道-过滤器架构。这两种子模式都是数据流架构的具体实现方式，它们各自有特定的应用场景和特点。

批处理架构（Batch Processing Architecture） ：

批处理架构处理的是大量数据的集合，这些数据通常事先已知并存储在数据库或文件系统中。
数据以批量的形式进行处理，而不是实时处理。
批处理系统通常在预定的时间运行，如每天、每周或每月。
批处理架构适用于不需要即时响应的场景，如生成报告、数据分析和数据仓库的更新。

管道-过滤器架构（Pipe-and-Filter Architecture） ：

管道-过滤器架构由一系列过滤器组成，每个过滤器对数据执行特定的处理或转换。
数据通过管道在过滤器之间流动，每个过滤器的输出成为下一个过滤器的输入。
这种架构允许独立开发和组合不同的过滤器，以构建灵活的数据处理流程。
管道-过滤器架构适用于需要逐步处理数据的场景，如文本处理、图像处理或数据转换。

这两种架构都是数据流架构的实现方式，但它们在数据处理的实时性、数据的组织方式和系统的可扩展性等方面有所不同。在实际应用中，根据系统的具体需求和数据的特点，可以选择适当的架构模式。

批处理架构更适合于处理大量已知数据，它通常用于不需要即时响应的任务。
管道-过滤器架构则更灵活，适用于逐步处理数据，可以更容易地扩展和组合不同的数据处理组件。

在某些情况下，这两种架构也可以结合使用。例如，在处理实时数据流的同时，可能需要定期对累积的数据进行批处理分析。在这种情况下，系统可以同时采用批处理和管道-过滤器架构，以满足不同的数据处理需求。

2.1 Batch Sequential批处理

每个处理步骤都是独立的，每一步必须在前一步结束后才执行
数据必须完整，以整体形式传递，意思就是当前数据全处理完毕才可以通向下一个连接器处理

2.2 pipe-and-filter

增量风格，异步，可以一点点往后传数据。实时性好
数据通过一系列过滤器管道流动，每个过滤器对数据进行处理
Incrementally transform data from the source to the sink (递增的读取和消费数据流)，数据到来时便被处理，不是收集然后处理，即在输入被完全消费之前，输出便产生了。
是chain of processing elements. 连续元素之间有buffering缓冲
p74
filter封装continuously generated data，system需要对这些data进行处理
将system分为多个连续的处理步骤，这些步骤通过数据流连接起来，处理步骤由filter实现，pipe处理步骤之间的data processing(filter 就是step)
每个filter内部都有一组输入和输出，filter从pipe里读取，处理完之后生成data stream再写入pipeline
filter
- 每个过滤器都是独立的，互不影响
  - no context in processing streams, no state preservation, no knowledge of other filters
pipe
- 移动data，从一个filter的输出到一个filter的输入
  - 不同的数据形式可能会在pipe里统一格式
  - 单向，有buffer，管道中形成传输图。不同pipe内的data stream可能有不同data formats
例子：编译器，图像处理，信号处理，声音处理
优点：高内聚，低耦合 high cohesive，low coupling，可重用，应用并发和时序简单，扩展性高:添加新filter，灵活性高：重定向，修改定义和目的等
缺点：不适合处理交互的数据；系统性能不好：因为数据的传输格式并不统一，每个filter还要先分析data再处理，格式转换耗时，不适合shared data

两者比较

3. Event system 事件系统

3.1 关于事件系统

什么是事件
1. events是actions，用来激活对象的功能。要执行的时候，对应的message会被发送给相关对象，对象会执行corresponding function
2. 对象会自动找到相应的程序来处理事件
3. 特征是Implicit invocation隐式调用
  1. 事件触发器不会知道哪些components会受影响，remains independent of each other
  2. 不能假设处理顺序或者会调用啥没独立
  3. 每个组件之间没有连接关系，association通过publishing和registering events实现
5. one event source 可以Broadcast多个事件，就是说事件源可以发布多种不同的事件
6. 事件处理器可以注册自己感兴趣的事件，然后关联
7. 一个事件发布的时候，事件管理器自动调用注册的所有过程
8. 事件系统的组件充当过程或函数，作为事件源，会展示一系列事件
9. 事件系统的连接器是事件过程绑定，比如event handler，注册事件的过程是隐式调用，调用的次序未知。事件的触发可能是一个接一个触发的，形成事件链

3.2 两种调度机制 dispatch mechanism

3.2.1 EventManager without dispatcher module 无独立调度派遣模块

模块通常分为 Observable/Observer 观察者和被观察者。应该每一个module既是观察者也是被观察者。根据不同的事件互相发送信息
每一个module会允许其他module向自己发送的信息表示兴趣，应该就是表示兴趣就会记住，然后之后就给他们做信息传递
某一module发出事件时，会自动将这些事件发给其他的注册过此事件的module

3.2.2 EventManager with dispatcher module 有独立调度派遣模块

dispatcher module负责接受所有传入的事件，然后分派给其他模块。和上面对比应该就是中间多了一层管理者dispatcher

分为两种

all broadcasting：向所有模块广播事件，但是只有感兴趣的模块才会获取事件
selected broadcasting：针对注册不同事件的module，发送不同的信息，反正就是有目的了

针对选择广播有两种策略

当一个消费者从队列中取出并处理了消息后，该消息就从队列中移除，不会被其他消费者再次消费。
如果有多个消费者监听同一个队列，通常只有一个消费者能够消费消息，其他消费者则需要等待下一条消息的到来。
这种模式适用于需要确保消息被精确处理一次的场景。

每个订阅者都会收到消息的副本，因此同一条消息可以被多个订阅者独立消费。
这种模式适用于需要广播消息给多个接收者的场景，每个订阅者都可以独立地处理消息。

3.3 优缺点

event manager和event handler分开，解耦，有独立功能，易维护
事件或处理器的替换和添加是独立的，容易执行
某个module出问题不会影响其他module
high reuse potential
dispatcher很难对多个或同时的input作出反应
dispatcher坏了整个system就坏了
dispatcher需要很高的性能
事件出了问题不保证能恢复，此事件可能就丢失了或传递错误信息

4. Call/Return 调用返回

4.1 定义

它基于程序设计中的函数调用和返回机制。这种风格强调了组件之间的交互是通过直接的函数调用来实现的

明确的调用和返回：在这种风格中，组件之间的交互是通过函数调用实现的，每个调用都有一个返回点，调用者在调用函数后会等待返回结果。
同步执行：调用者在调用函数时会阻塞，直到被调用的函数执行完毕并返回结果。
控制流清晰：由于调用和返回的顺序性，程序的控制流通常比较清晰和易于理解。

4.2 main program & subroutine

经典编程，功能分解

单线程控制，功能可以分为多步
有不少function modules

问题：这种模式适用于哪种应用？

适用于计算可以通过过程定义的层次结构适当定义的应用。

上下文：

许多编程语言为定义嵌套的过程集合和层次结构调用提供了自然支持。
这些语言通常允许将过程集合分组为模块，引入了名称空间的局部性。
执行环境通常在单个名称空间中提供一个单一的控制流。执行环境中通常在单个命名空间里提供一个线程进行处理

解决方案：

系统模型：调用和定义层次结构，子系统通常通过模块化定义。
组件：过程和显式可见的数据。
连接器：过程调用和显式数据共享。
控制结构：单一线程。

‍

隐藏秘密，比如数据的表示，折本信息
局部化未来的改变，隐藏系统细节，暴露接口
允许改变

单线程控制，分为多个进程步骤
将步骤整合到模块中
适用于计算可以通过过程定义的层次结构适当定义的应用

应该就是有一个大的统筹管理，各个小的分别控制一些功能

简单区分

模块化：程序被分解为独立的模块，每个模块负责特定的功能。
主程序：主程序是程序的入口点，负责控制程序的执行流程。
子程序：子程序是主程序调用的独立模块，执行特定的任务。

操作系统启动程序：主程序可能负责初始化硬件和加载系统服务，子程序可能负责具体的硬件检测或配置。
文本编辑器：主程序提供用户界面和基本流程，子程序可能包括文件打开、保存、搜索替换等功能。

4.3 object oriented style

信息隐藏，只能通过函数或接口来使用相关内容，对于如何做如何实现是封装好的
secret就是没必要让用户知道的信息，比如设备基础data，设备属性，策略机制啥的。需要隐藏独立的可更改的细节

隐藏信息（表示、功能）。复用性，接口
方法（动态绑定）、多态性（通过子类化）、重用（继承）。Methods (dynamic binding), polymorphism (subclassing), reuse (in-heritance).
对象在不同进程/线程中活跃（分布式对象）。

问题：这种模式适用于哪种应用？

适用于需要识别和保护相关信息体，特别是表示信息的应用。

解决方案：

系统模型：本地化状态维护。
组件：管理器（例如，服务器、对象、抽象数据类型）。
连接器：过程调用。
控制结构：分散的，通常是单线程。

简单区分

封装：将数据（属性）和操作这些数据的方法结合在一起，形成一个对象。
继承：允许新创建的类（子类）继承现有类（父类）的属性和方法。
多态：允许不同类的对象对同一消息做出响应，但具体的行为会根据对象的实际类型而有所不同。

图形用户界面（GUI）应用程序：窗口、按钮、文本框等都可以是对象，它们封装了各自的属性和行为。
电子商务平台：用户、产品、订单等可以作为对象，它们之间通过继承和多态性实现复杂的业务逻辑。

4.4 layered system style

将系统分解为几个逻辑层，每一层完成特定的功能，并且只有相邻层之间可以进行直接的调用。通常用于具有不同服务类别的应用程序，可以层次化排列。
分层管理对象分类
C/S和B/S是他的子分类好像

问题：这种风格适用于哪种应用？

适用于涉及可以层次化排列的不同类别服务的应用。相似的解决类似功能的模块方同一层次

解决方案：

系统模型：不透明的层次结构。
组件：通常是复合体；复合体通常是过程的集合。
连接器：取决于组件的结构；通常是受限可见性下的过程调用，也可能是客户端/服务器。
控制结构：单一线程。

高内聚，层次之间低耦合，好reuse，管理方便。每层都会对其他层隐藏信息

分层太多会影响性能，层与层之间的组织困难。层数越多性能越差

Strict layered是只是用below layer，Relaxed layerd是使用下面任何的layer，就是紧挨着和全部的区别

‍

4.5 client/server style

系统分为客户端和服务端两部分，客户端发起请求，服务端处理请求并返回结果。

组件：

客户端：提出请求并处理与系统环境的输入/输出的应用程序。
服务器：响应客户端请求的应用程序。

连接器：

基于RPC的网络交互协议。Remote Procedure Call远程过程调用

原因：

C/S软件架构基于不平等资源并提出共享。它在1990年代成熟。
多用户希望共享交换数据

特点：

依赖性：客户端依赖服务器。
拓扑：一个或多个客户端可以连接到服务器。客户端之间没有连接。
移动性：容易支持客户端移动。
安全性：通常在服务器上控制，也可以在应用/业务层控制。

优缺点

有效利用网络，易扩展，共享数据。服务器易升级或添加，客户端也易添加
server需要redundant管理，很难更改已有逻辑，因为改一个server的之后，附属这个server的client可能就需要各种奇奇怪怪的新功能。受带宽流量限制。需要精确的ip或命名才能找到对应的C/S

4.5.1 two tier双层C/S架构

处理分为user system interface environment, database management server environment.tier1在user环境，tier2在server。server负责数据管理，client负责和user完成交互。thick client，thin server

client的硬件配置需求高，client的程序设计复杂，数据安全性不好，信息单一，user界面风格不统一，软件难以维护

4.5.2 three tier三层C/S架构

和2 tier相比多了一层application server作为逻辑层。应用程序的逻辑都在application server中，client保留presentation layer，变成thin client。=> presentation, application(logic), data tier。就是典型的MVC结构

三层互相独立。application tier实现specific business processing logic

B/S浏览器服务器架构是三层的特例。client持有http browser。使用统一协议。只能pull，不能push。client之间的通信只能通过server实现。资源利用率差，SQL攻击，运行速度差，服务器loader严重，client资源被浪费

5. Data Center 数据中心

应该就是把所有的数据统一存起来，避免查找麻烦，方便管理

例子：注册表管理，剪切板 => 用于短期数据存储，数据传输交换的软件，存储和交换的信息会形成公共区域，通过这个区域会交换格式化后的信息

Data-centered architecture involves a shared data source approach for information delivery.

5.1 repository 仓库风格

A repository is a central place where data is stored and maintained. (仓库是存储和维护数据的中心场所)

有两种组件，中心的是存储当前数据，掌握被动权，周围的是独立构件，掌握主动权，对数据进行操作。总而言之就是中心是用来存储贡献数据的，周围是不断与数据进行交互

此模式适用于中心问题是建立、增加和维护复杂的中心信息主体的应用程序。

连接器指的是中心仓库和外部组件的交互。有数据库机制，和黑板机制

适用于central issue是establishing，augmenting，maintaining一个complex central body of information。对于数据之间需要一些driven(驱动)才能使用

典型应用

数据处理(数据处理)，主要由需要从传统数据库构建业务决策系统驱动。
软件开发环境(软件开发环境)，主要由表示和操作程序和设计的需要驱动

数据库，语义分析

5.2 blackboard 黑板风格

没有直接的固定算法解决问题
找不到明确的策略，有多个解决方案，需要多个领域的expertise解决问题
适用于NLP，语音处理，图像处理等

一个大问题可以分为多个子问题，每个子问题的解决是需要不同的问题表达式和解决模型的。
可以分为多个特定的知识领域解决问题的某个方面
程序之间是独立的，没有直接的相互调用，没有明确的先后顺序
在解决问题的过程中动态确定程序的先后顺序，从而协同工作完成任务
需要多个knowledge source知识源

和仓库相反，中心的共享数据是占据主动权的，可以不断调用周围的知识源解决问题。ks彼此独立，分别是处理不同的方案，通过黑板进行交流合作。是condition-action的结构方式。会实时更新黑板上的数据，从而解决问题，像老师讲课一样在黑板上写出步骤

控制器会随时监控黑板的状态，当状态满足某个ks执行条件的时候会计算数据更新到黑板上。然后根据黑板的新数据再反过来查看其他ks的情况，然后不断循环

当前步骤的结果依赖上一步骤的结果

6. Virtual Machine 虚拟机

定义：虚拟机架构通过解释器（Interpreters）来模拟硬件上非原生的功能。

组成部分：

解释器：模拟非硬件原生功能。simulate functionality which is not native to the hardware
规则系统（Rule-based systems）：解释器的特化形式。specialization of interpreter

解释器风格（Interpreter Style） ：

解释器模式适用于执行解决方案的最适当语言或机器不可直接使用的情况。
解释器通常设计为在所需的机器或语言与执行环境已支持的（可能是虚拟的）机器或语言之间架起桥梁。

解决方案：

系统模型：虚拟机。
组件：一个状态机（执行引擎）和三个存储器（执行引擎的当前状态，被解释的程序，被解释程序的当前状态）。
连接器：数据访问和过程调用。
控制结构：通常为执行引擎的状态转换；输入驱动的解释选择。

规则系统特点：

知识库（规则集合）。
解释引擎（规则解释器）。
解释器的控制状态（规则/数据选择）。
代码的当前状态（工作内存）。

应用场景：

人工智能领域，例如自然语言处理、图像处理、模式识别等。
Drools是一个用于处理规则的专家系统，用于大型系统和复杂业务，支持频繁变化的业务规则和24小时服务。

虚拟机架构通过解释器来模拟和执行非硬件原生的功能，适用于需要动态解释和执行代码的场景，特别是在规则系统和人工智能应用中。

6.1 interpreter解释器

总结来说就是对多数编程语言的套壳翻译，变成可执行的程序，比如java的编译器啥的。为程序和语言和机器之间架起沟通的桥梁。

Solution

System model: virtual machine
Components: one state machine (the execution engine) and three memories (current state of execution engine, program being interpreted, current state of program being interpreted)
Connectors: data access and procedure call
Control structure: usually state-transition for execution engine; input driven for selection of what to interpret
Expert systems are often implemented as interpreters for the collections of rules, or productions, that represent the expertise
用于模拟为主，易测试，flexibility
但是效率慢，而且testing层需要写更多的方法和函数
灵活性：可以轻松地修改和扩展解释执行的语言或规则。
跨平台：由于解释器与平台无关，因此可以在不同的系统上运行相同的代码。
性能：解释执行通常比编译执行慢，因为每次执行都需要解释指令。
交互性：解释器可以提供交互式环境，允许即时执行和测试代码。

模拟非本地内容，安全性测试
编译慢，需要额外软件层

6.2 rule-based system基于规则的系统

基于规则的系统架构：

核心组成：基于规则的系统通常由知识库（存储规则）、推理引擎（解释和应用规则）和工作内存（存储当前状态和数据）组成。
规则处理：系统专注于处理规则，即一系列条件和对应的动作。当推理引擎找到匹配的规则时，会触发相应的动作。
推理机制：使用前向链接或后向链接的推理机制来确定哪些规则被激活，并执行相应的操作。
应用场景：适用于需要处理复杂业务逻辑、决策支持系统、专家系统等场景，其中规则经常变化，需要灵活性和可维护性。
规则独立性：业务规则与应用程序的其他部分分离，便于管理和更新。
用户交互：可以提供良好的用户交互界面，允许用户定义、修改和管理规则。

解释器风格：

核心组成：解释器通常包括一个执行引擎（状态机），以及用于存储当前执行状态、正在解释的程序和程序的当前状态的内存。
语言处理：解释器用于解释和执行特定语言编写的程序，这些程序可能是脚本、配置文件或其他形式的源代码。
执行模式：解释器通常在运行时逐条读取和执行指令，不需要预先编译。
应用场景：适用于需要动态执行代码、快速原型开发、脚本执行等场景。
语言无关性：解释器可以设计成与特定语言无关，能够处理多种语言编写的代码。
性能考虑：解释执行通常比编译执行慢，因为每次执行都需要进行解释。

区别：

处理内容：基于规则的系统专注于处理条件和动作对，而解释器处理的是按照特定语言编写的程序或脚本。就是一个是基于设定好的一些操作，一个是有一个脚本在背后
架构重点：基于规则的系统强调规则的管理和推理，解释器风格强调语言的解释和执行。
性能优化：基于规则的系统可能不涉及即时编译，而某些解释器（如JVM）可以使用即时编译技术来提高性能。
应用范围：基于规则的系统通常用于业务逻辑和决策支持，而解释器风格可以更广泛地应用于任何需要动态执行代码的场景。

尽管它们有这些区别，但在某些情况下，基于规则的系统也可以使用解释器来处理规则。例如，Drools是一个基于规则的系统，它使用解释器来执行业务规则。在这种情况下，解释器风格被集成到基于规则的系统架构中，以提供灵活性和动态执行能力。

声明式编程，会告诉你该做啥不该做啥，逻辑强，快速灵活，知识中心化，解释机制良好，规则易理解
Drools是一个开源的制定规则的原则，反正就是帮助规范，没啥用
1. 声明式编程-规则引擎允许你说“做什么”而不是“怎么做”•基于规则的系统能够解决非常困难的难题•逻辑和数据分离•快速灵活•知识集中•工具集成•良好的解释机制•易于理解的规则

6.3 other

Syntactic shells; Command language processors

7 软件架构描述

7.1 description

软件架构由处理组件（processing components）、数据组件（data components）和连接组件（connection components）组成。这些是组成软件体系架构的结构元素

分别负责处理数据，处理后的信息，连接不同组件的媒介

软件架构是开发一个系统的blueprint包括工作分配、质量属性承载、早期分析工具以及后期维护和挖掘的关键。

7.1.1 function

Describing software architecture is the basis for understanding architecture design ideas and communicating how to use architecture to guide system construction. 架构描述有助于理解架构设计思想，指导如何使用架构，并作为系统构建的依据。目的是便于stakeholders之间的communication.会需要一些document方便理解

7.2 modelling

视图是针对特定利益相关者所关心的软件架构元素和它们之间关系的表示。

视图有助于记录相关观点，添加适用于多个视图的信息，从而将思想联系起来。

每种视图的目的都不一样，重点也不一样

包括展开视图（Exploded View）、使用视图（Usage View）、层次视图（Hierarchical View）、类/泛化视图（Class/Generalization View）、进程视图（Process View）、并发视图（Concurrency View）、共享数据（Repository）视图、客户端-服务器视图（Client-Server View）、部署视图（Deployment View）、实现视图（Implementation View）和工作分配视图（Work Distribution View）

描述软件应用架构的规范称为架构描述（architectural description），采用一种或多个视点，每个视点包含一个或多个相关视图，每个视图由一个或多个模型组成，并关注单一视点。

4+1视图：逻辑视图（Logical View）、进程视图（Process View）、开发视图（Development View）、物理视图（Physical View), user case view(scenarios)

‍

用例图，没啥好说的
逻辑图，包括class，object(instance)，state(重点在于生命周期)，communicaiton(collaboration),sequenece
1. 序列图重点在于一个操作的整体流程，交流图更加看重链接上的东西
进程图，描述进程，包括活动图，活动图更侧重于描述操作的流程
发展图，就是看系统各个部分如何组成块的。包图和组件图
物理图，就是部署图，真正的样式，硬件软件中间件这种

uml

包括结构元素（如类、接口、协作、用例、组件、节点）、行为元素（如交互、状态机）、分组元素（如包、子系统）和其他元素（如注释）
静态视图（Static Views）:
1. 用例图（Use Case Diagram） ：展示系统的功能以及与外部参与者（Actors）的交互。
2. 类图（Class Diagram） ：描述系统中类的属性、操作以及类之间的关系，如继承、关联和依赖。
3. 对象图（Object Diagram） ：展示类实例（对象）以及它们之间的关系的静态视图，通常用于示例或特定的场景。
4. 组件图（Component Diagram） ：描述系统的物理结构，展示软件组件、它们的接口和它们之间的关系。
5. 部署图（Deployment Diagram） ：展示系统的物理部署，包括硬件、节点以及它们上运行的软件组件。
6. 包图（Package Diagram） ：展示模型元素的组织结构，通常用于展示包（Package）和它们的依赖关系。
7. 复合结构图（Composite Structure Diagram） ：展示类的内部结构，如何由其他类或对象组成。
动态视图（Dynamic Views）:
1. 序列图（Sequence Diagram） ：展示对象间的交互，特别是消息传递的顺序和对象间的协作。
2. 通信图（Communication Diagram） ：与序列图类似，但更强调对象间的组织结构而不是消息传递的时间顺序。
3. 状态图（Statechart Diagram） ：展示对象所有可能的状态以及事件发生时状态之间的转换。
4. 活动图（Activity Diagram） ：展示业务流程或操作的工作流，包括决策点、并行处理、循环等。
5. 时间图（Timing Diagram） ：展示不同对象状态变化的时间约束和时序关系。
6. 交互概览图（Interaction Overview Diagram） ：结合活动图和序列图的特点，用于展示更高层次的交互概览。
其他视图：
- 组件图（Component Diagram） ：虽然组件图主要用于描述系统的物理结构，但它也可以展示组件之间的交互，因此有时也被视为动态视图的一部分。

质量属性是非功能性需求，目的是为了保证实现的功能有良好的体验，每个模块必须有正确的responsibility，正确的资源，正确的scheduling sequence。不同的软件项目会关注不同的质量属性，这些属性会影响架构风格选择。

不同的软件需要重点强调的功能性需求不一样，而且各个需求可能互相制约，优先保证高level的质量。必须结合design，implementation和deployment去实现

Quality Attribute Scenario -> 描述了客户对系统性能的具体期望，例如系统运行速度和安全性，describe how the system responds to stimuli

六个场景重要组成部分

source of stinulus: 刺激源，刺激的发起者
stimulus：刺激，影响系统的condition
artifact：制品，系统中受影响的部分
environment：环境，刺激发生时系统的状态
response：刺激的结果
response measure：评估刺激的方法响应衡量指标
简单来说就是需要描述出来有印象的具体化的需求，有点像用户故事的感觉

策略定义：特定设计手段以满足特定的质量属性，是架构风格的基本单位。Tactics

8. availability 可用性

定义：用户使用系统时系统可用的概率，不包括提前确定的停机维护时间。
关注点：有俩，一个是是否发生故障被外界发现，一个是故障的后果
从99.9变成99.999带来的提高也是非常大的
指标metrics：可用时间百分比，修复failure花费的时间，mean time between failures

刺激源：失败的迹象
刺激：系统错误，系统崩溃，超时，没结果，返回错误结果
工件：计算或存储或网络运输
环境：正常或者sub-healthy
响应：record logs，通知admin或其他系统，维护系统，关闭系统
响应测量：发生故障时间的百分比，修复的时间

保持可用性的策略：

Fault detection 错误检测 -> 尽快早的发现错误
1. ping/echo。利用ping不断发出信息监视组件，根据返回的echo信息判断有没有出错
2. heartbeat。被监控组件定时向监控组件发出心跳信息，节点间的信号是周期性的，如果未能连续收到信息或者信息有误，就说明错了
3. exceptions。就和java，python的那种一样，运行代码的时候写出异常检测
Fault recovery 错误恢复 -> 如何恢复
1. vote投票。多个冗余组件使用相同或不同的算法完成同样的任务，结果不同的话少数服从多数，意思就是尽可能保证大部分结果是正确的，然后就直接应用对应的结果了呗。不同团队在不同软硬件平台开发对应的组件
2. active redundancy主动冗余。服务器A,B始终保持一致，一般使用A的结果。但是A一旦出错就使用B的
3. passive redundancy被动冗余。A完成操作之后会延时通知B自己的情况，B更新成A的，这样保证至少有一个一直是正确的(虽然会落后一个版本)
4. 重新上线的修复后的系统需要进行resynchronize the status同步状态
5. 内部测试
6. rollback回滚到正确的版本。比如github，比如word自动保存。定期存储，checkpoint
Fault avoidance 错误避免 -> 如何主动减少错误的发生
1. service offline主动下线自己的服务，虽然自己暂时不会提供服务了，但是保证不会被攻击
2. transaction事务。对于一个行为实际上把过程中的步骤拆分开，其中一个步骤出错了，整体的行为就取消掉，比如网购的时候是付钱，商家收钱，如果商家收钱失败，我们的钱实际上是会原路返回的
3. process monitoring。任务管理器监控。windows task manager

9. modifiability 可修改性

修改的cost；哪部分需要被修改；什么时候修改；谁来修改.Cost, which, when, who
metrics：time token to complete modification, human resource cost, economic cost

刺激源：想修改的user
刺激：specific modification to made
工件：被修改的系统功能、用户界面或其他交互系统
环境：修改发生的时机，是在设计的时候还是开发的时候还是使用的时候。越晚修改cost越大
响应：操作人员必须了解如何修改，执行修改操作，如何测试和部署
响应测量：time & cost

保持可修改性的策略：

目标是为了减少修改花费的time和cost
方向1 limit the scope of modification
1. 使受修改影响的软件的范围尽可能小
2. 在模块里high cohesion，low coupling。利用中间件和框架，尽量保证修改单个组件内的程序
3. consider potential modifications。帮助划分每个模块的责任，从而好判断分配哪里需要修改，确保修改是对于一个module的某个point来的，而不是在同一个module里同时修改好几处要点
5. make module generic。变成泛型就相当于成为一个大父类，降低耦合了。比如Interpreter风格的使用
6. 隐藏信息。oop中设置public private
7. maintain consistent interface。接口一致的话会允许不修改接口只修改两头
8. 限制communication path。避免过多复杂的通道，从而可能得改好多地方
9. use intermediaries，使用中介。就是统一通过中间层管理->service中介，比如中间件，工厂模式，bridge。比如data中介，为了共享data
10. name server. 使用名称服务器，方便查询所需资源和对象的位置，resolve位置的依赖关系
11. create instances on demand按需创建实例。
方向2 delay binding time
1. 延迟绑定时间，允许软件在运行期间灵活修改
2. configuration files。使用配置文件，无需修改代码即可进行修改
3. Publish-subscribe style。发布-订阅风格。->观察者模式。大概的意思就是对于每个event的发生都进行统筹管理，这样如何处理信息实际上并不是糅合在一起的，所以可以看作延迟绑定时间
4. Polymorphism多态。就是生成子类，和上面的generic异曲同工之妙

10. performance 性能

关注点：系统对事件的响应速度，与事件的数量和到达模式有关。
事件来源：可以是用户请求、系统内部或外部事件。
事件到达模式（Arrival Patterns of Events: random ; 或者在特定的时间尺度上呈现规律性（如每日、每月、每学期、每年）。就比如说618的时候就希望网购app性能更好

刺激源：系统内部或外部
刺激：event arrival，需要相应
工件：系统提供的服务
环境：系统处于不同模式，比如normal，emergency，overload
响应：系统处理传入事件
响应测量：处理事件的时间，单位时间内处理的事件数量，error rate/loss rate

保持性能的策略：

目标：limited time内相应事件，需要资源和用户资源.排队优先
Direction1 resource requirements 资源需求
1. 保证data完整性的同时improve computational efficieny。使用更高效的算法，减少资源占据
2. 减少处理数据的总量。控制event arrival的速率，只处理一个subset
3. 限制执行时间，得到approximate solution即可
4. 限制事件队列的长度，放弃一些不重要的事件的处理
Direction2 resource management 资源管理
1. utilize concurrency mechanisms使用并发机制，多核多线程等
2. increase available resources增加可用资源的数量，比如计算核心，数据库，带宽等
Direction3 resource arbitration 资源仲裁
1. 先来先服务 first-come，first-served
2. fixed priority scheduling固定优先级调度，比如军人优先这种
3. dynamic priority动态优先级。比如急诊，截止时间优先

11. security 安全性

关注点：在确保合法用户能够使用系统的同时抵抗对系统的攻击。
攻击（威胁） ：试图突破系统安全保护的行为

安全性的不同方面（Different Aspects of Security）

不可否认性（Non-repudiation） ：确保行为者不能否认其行为。
保密性（Confidentiality） ：保护信息不被未授权披露。
完整性（Integrity） ：确保信息的准确性和完整性。
保护性（Assurance）
可用性（Availability） ：确保系统和信息在需要时可用。
审计（Auditing） ：为重建目的进行审计。

刺激源：攻击可能由外部系统或peopel发起
刺激：对系统的攻击。比如获取更高权限
工件：系统提供的服务和内部数据
环境：系统处于不同situations，比如联网/未联网，在线/离线，防火墙内外
响应：允许合法用户使用，拒绝非法用户。对抗攻击
响应测量：1发起攻击的难度，2从攻击中恢复的难度

保持安全性的策略：

Direction1 resisting attacks 抵抗攻击
1. user authentication：用户认证，什么验证码了，密码了，指纹，人脸
2. user authorization: 用户授权。确保用户权限
3. maintaining data confidentiality：维护数据保密性。加密数据和传输过程，https，hash
4. maintaining data integrity：维护数据完整性。MD5验证，也是运用hash
5. reducing exposure：减少暴露。关闭ports，自动服务
6. access control：访问控制。白名单黑名单
Direction2 detecting attacks 检测攻击
1. combination of software and humans：软件与人员结合。安全专家，入侵检测sys
Direction3 recovering from attacks 从攻击恢复
1. restoring state：恢复状态。采用availability的策略
2. identification of attackers：识别攻击者，阻止潜在攻击者

12. usability 易用性

关注点：减少用户使用软件的难度。

各个方面：

促进用户上手。
提高用户使用软件的效率。
减少用户错误的负面影响。
使软件适应用户需求。
增强用户信心和舒适度。

刺激源：最终用户
刺激：最终用户希望学习如何使用系统，提高使用效率，减少错误。
工件：整个系统
环境：系统处于运行或configuration状态
响应：系统响应用户请求
响应测量：用户完成任务所需时间、用户犯错数量、用户满意度、用户操作成功率。

保持易用性的策略：

目标：使用户容易使用
Direction1 Runtime Tactics：运行时策略
1. System Anticipates User Tasks，系统预测用户的行为。比如搜索引擎自动补全，输入建议
2. System Provides Appropriate Feedback to Users，系统提供反馈。网页加载进度，文件上传下载的百分比
3. System Provides Consistent Experience to Users，系统提供一致性体验。比如分辨率适配等
Direction2 Design-time Tactics：设计策略
1. Support Undo Operations，支持撤销，ctrl z
2. Isolate the User Interface from Other Parts of the System 分离用户界面和系统功能。就是MVC，自定义样式，设置主题等

13. testability 可测试性

关注点：

使软件的错误容易被测试发现。
验证软件产品是否符合其需求规格（任何差异或遗漏）。
以最低的成本和努力验证软件的质量。

软件测试的目的是发现缺陷。

软件项目的大约40%成本花费在测试上。

大型软件项目的失败可能导致严重后果。

如果能在架构层面增强可测试性，好处是巨大的。

刺激源：由stakeholders发起测试
刺激：系统达到了milestone，需要查看当前开发是否完善
工件：设计，code，whole system
环境：系统处于设计，开发，部署，运行等阶段
响应：理想的响应是能够测试并观察结果。
响应测量：
1. 白盒测试的覆盖率：
  - 语句覆盖。
  - 判定覆盖/分支覆盖（一个判定可能包含多个条件）。
  - 条件覆盖：覆盖一个判定中的每个条件。
  - 路径覆盖、判定条件覆盖、条件组合覆盖等。
2. 未来继续发现缺陷的可能性。

保持测试的策略：

定义：黑盒测试是一种测试方法，测试者不需要了解程序内部的逻辑或结构，只关注程序的输入和输出。测试用例基于需求规格说明，不考虑内部实现。

特点：

从用户的角度出发，模拟用户操作来测试软件界面和功能。
强调功能测试，检查软件是否按照需求执行。
测试者不需要编程知识或对软件内部结构有深入了解。
常用于集成测试和系统测试阶段。

定义：白盒测试又称为结构测试或透明盒测试，测试者需要了解程序内部的逻辑和结构，测试用例基于程序内部的代码结构。

特点：

从开发人员的角度出发，检查程序内部的逻辑路径和分支。
强调代码覆盖，如语句覆盖、分支覆盖、条件覆盖等。
测试者通常需要具备编程知识和对软件内部结构的深入了解。
常用于单元测试和集成测试阶段。

目标：使测试更简单
黑盒测试（Black-box testing）:提供输入,捕获输出
1. record/replay: 记录,回放.自动化或半自动化测试
2. Separate interfaces from implementations.接口分离.对于不同的算法使用相同的接口
3. Provide specific test paths,提供测试路径
白盒测试（White-box testing）
1. Internal monitoring内部监控.比如断点工具,就是看某一步的值

14. evaluation 评估

意义:

及早发现现有架构中的问题，因为问题越早被发现，修复成本越低。
验证validation需求，架构评估揭示冲突和权衡，并为它们的协商解决提供论坛。
为审查review做准备，许多系统没有所有开发者都能理解的架构。准备评估过程将揭示这些问题。
改进架构。

14.1 评估

一些方法

场景基础架构分析方法（Scenario-based Architecture Analysis Method, SAAM） ：最初用于分析架构的可修改性，但适用于分析架构的任何非功能性方面。
架构权衡分析法（Architecture Trade-off Analysis Method, ATAM） ：SAAM的继承者，也广泛使用，考虑了质量属性效用树quality attribute utility trees和质量属性类别competing quality attributes.。ATAM是SAAM的专业化
SAAM的复杂场景基础（SAAM Founded on Complex Scenarios, SAAMCS） ：考虑评估场景的复杂性作为最重要的风险评估因素。
通过领域集成扩展SAAM（Extending SAAM by Integration in the Domain, ESAAMI） ：将SAAM与特定领域和重用基础的软件开发过程集成。
软件架构分析方法用于演化和重用（Software Architecture Analysis Method for Evolution and Reusability, SAAMER） ：专注于演化和重用的质量属性。
基于场景的架构重构（Scenario-Based Architecture Reengineering, SBAR） ：使用场景、仿真、数学建模和基于经验的推理来评估质量属性。
软件维护的架构级别预测（Architecture Level Prediction of Software Maintenance, ALPSM） ：使用变更场景来分析可维护性。
软件架构评估模型（Software Architecture Evaluation Model, SAEM） ：基于正式和严格的质量要求。

14.2 ATAM

介绍 Architecture Trade-off Analysis Method

ATAM帮助利益相关者提出正确的问题，发现潜在有问题的架构决策。

可以明确识别和记录权衡。Trade-off

在不同的质量属性之间做出平衡的过程。由于不同的质量属性可能相互冲突，提高一个属性可能会牺牲另一个属性，因此在设计软件架构时，需要在这些属性之间做出权衡。

发现的风险可以成为缓解活动的重点，例如进一步设计、分析或原型制作。

例如：

性能与资源使用：为了提高系统性能，可能需要增加更多的计算资源，这可能导致成本增加或资源使用效率降低。
安全性与性能：增强安全措施（如加密）可能会对系统性能产生影响，因为加密和解密过程需要额外的处理时间。
可维护性与开发速度：编写易于维护和理解的代码可能会减慢开发速度，因为可能需要更多的时间来设计和实现一个清晰和灵活的架构。

在ATAM（架构权衡分析法）中，折衷分析的目的是识别和记录这些权衡点，以便利益相关者可以明确了解不同架构决策的潜在影响，并做出有根据的决策。通过评估折衷，团队可以更好地理解架构设计选择的后果，并为可能需要的缓解措施提供信息。

target:

ATAM的目的不是提供精确分析，而是发现由架构决策创造的风险。
目的是找到趋势trends：架构决策与系统属性预测之间的相关性。

benefits:

执行ATAM评估的好处包括识别风险、明确质量属性需求、改进架构文档、记录架构决策的基础、增加利益相关者之间的沟通
最终的目的是改进了架构

teams

evaluation teams由领导者和至少三名其他成员组成，必须是经验丰富的架构师。
project decision maker可以控制程序开发过程并授权变更。比如项目经理,用户,架构师
Architecture Stakeholders.所有相关的人和事.

phases

阶段0：技术评估前的准备阶段，客户和评估团队的子集就方法和待评估的系统架构达成理解。达成执行评估的共识,核心评估小组会建造好
阶段1：专注于获取详细的架构信息并进行分析，涉及技术导向的利益相关者小组。以体系结构为中心,top down的方向进行分析
1. The evaluation team presents an overview of the ATAM.通过效用树的构建,架构的分析,会得出当前的场景,一些预测的risk,还有敏感点、权衡点
  1. A sensitivity point is a property of one or more components (and/or component relationships) that is critical for achieving a particular quality attribute response. 比如小数点后几位
  2. 权衡点就是影响多个属性的属性的需求，牵一发而动全身
2. The customer describes business drivers of the system. 提出需求context，提出高级功能需求，质量属性
3. Designer presents an overview of the architecture design。技术限制，技术需求，与之交互的系统，合适的体系方法
4. Identify core architectural approaches.确定核心的架构模式。The evaluators begin to identify places in the architecture that are key to realizing quality attribute goals.
5. Identify, prioritize, and refine the most important quality attribute goals by building a utility tree。确定优先级，细化重要的属性。
  1. utility tree是top-down的工具，输出a characterization and a prioritization
    of specific quality attribute
  2. 场景是叶子，驱动质量属性是节点。通常是性能，可修改性，安全性，可用性
6. Evaluation team probes architectural approaches from the point of view of specific quality attributes to identify risks. 确定体系结构，针对优先级高的场景先设计对应的方案
阶段2：涉及更大的利益相关者群体，专注于收集不同利益相关者的观点，并对阶段1的结果进行验证。
1. Stakeholders generate scenarios using a facilitated brainstorming process.
2. Identify the architectural approaches impacted by the scenarios generated in the previous step.
3. Recapitulate（概括） all the steps of the ATAM and present the ATAM outputs.
  1. architectural approaches -> utility tree -> Scenarios -> risks and non-risks -> sensitivity points and tradeoffs -> risk themes
阶段3：主要涉及为客户制作最终报告，并反思评估和ATAM材料的质量