【系统分析师】软件架构设计

此章节，非《系统分析师》的重点章节，仅做衔接。

1、构件与软件复用

1.1 主流构件标准

# 主流的构件标准有：对象管理集团 Object Management Group - OMG 的
1、CORBA
2、COM - Mircrosoft的构件对象模型
3、DCOM - 分布式构件对象模型
4、EJB - Sun的Java企业Bean

1.2 构件获取与管理

构件的获取

1.从现有构件中获得符合要求的构件，直接使用或做适用性修改，得到可复用的构件
2.通过遗留工程，将有价值的构件提取出来，得到
3.从市场上购买现成的商用构件
4.开发新的符合要求的构件
具体选用哪种，考虑，一次性成本和维护成本

构件的组织

1.3 构件复用的方法

1、检索与提取构件
2、理解和评价构件
3、修改构件
4、构件组装：（基于功能的组装技术、基于数据的组装技术、面向对象组装技术）

2、软件架构概述

什么是架构？

1、组成派：站在目标系统的角度看，架构是名词，是目标系统
2、决策派：站在需求者的角度看，架构是动词，是愿景，是实现后的样子。
3、程序员：站在程序员的角度看，架构是名词，是实现后的u用哪个子

组成派

这个派别的思想源于物理世界的建筑行业的架构，也源于架构这个单词本身，
该派别认为：软件是一个系统，任何系统都是由组件、子系统、模块等组成的
通过分解还原一个软件系统，通过划分组件、子系统、模块来构建一个新的系统。

组成派是站在目标系统的角度，为外部提供服务的角度，以目标系统为目标和中心，而不是以用户为中心。
结构化分析与设计方法---就是组成派的杰出代码

决策派

核心思想：软件架构是在一些重要方面所作出的决策的集合。
软件架构并不仅仅注重软件本身的结构和行为，还注重其他特性，如：使用、功能性、性能、弹性、重用、可理解性，经济和技术的限制及权衡，以及美学等

决策派站在人的角度看目标系统，ta们认为 目标系统是人意愿的体现，是人决策的体现，展现的是一种 人对目标系统的一个愿景和规划。除了看得见的功能性需求，还包括看不见的非功能性需求。

面向对象分析与设计方法---属于决策派
用例图和用例就是需求，用需求衍生出各种视图

架构的种类？
单是IT行业，就有多种架构和架构师，下面列出几个最普遍的回答：

1、软件
2、硬件
3、基础设施
4、网络
5、数据
6、数据库
7、应用程序
8、安全
9、系统
......

可以看出，架构无处不在~

架构属于设计，但并非所有的设计都属于架构。

架构设计的决策，往往对整体质量、并行开发、适应变化等方面有着重大影响（否则就放到 详细设计环节 了）
 · 模块如何划分
 · 每个模块的职责是什么
 · 每个模块的接口如何定义
 · 模块间采用何种交互方式
 · 开发技术如何选型
 · 如何满足约束和质量属性的需求
 · 如何适应可能发生的变化
 ......

---

软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用、指导构件集成的模式 以及 这些模式的约束 组成。

软件架构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构件之间的对应关系，提供了一些设计决策的基本原理。

软件架构研究的主要内容涉及：软件架构描述、软件架构风格、软件架构评估和软件架构的形式化方法等。

解决好软件的复用、质量和维护问题，是研究软件架构的根本目的。

1. 架构是项目干系人进行交流的手段；
2. 架构是早期设计决策的体现；
3. 架构明确了 对系统实现的约束条件；
4. 架构决定了开发和维护人员的组织结构；
5. 架构制约着系统的质量属性；
6. 架构使推理和控制更改更简单；
7. 架构有助于循序渐进的原型设计；
8. 架构可以作为培训的基础；
9. 架构是可传递和可复用的模型。

软件架构技术发展过程
1、无架构设计阶段；
2、萌芽阶段：出现了程序结构设计主题，以控制流图和数据流图构成软件结构为特征；
3、初级阶段：出现了从不同侧面描述系统的结构模型，以UML为典型代表；
4、高级阶段：以描述系统的高级抽象结构为中心，不关心具体的建模细节，以"4+1"模型为标志

---

# 核心思想
1、关注软件系统的组成部分的分割与交互
软件系统的架构将系统描述为计算机 组件 及 组件之间的交互。
架构=组件+交互

任何系统，都由各个子系统组成，子系统和子系统之间，子系统与外界之间 一定存在一定的交互，没有交互的子系统是孤岛，注定没有存在的价值。

组件的本质就是子系统。

2、架构是自顶向下 逐步分层的 树型决策 ===》 分解过程也是决策过程 ===》 决策树
	而实际的设计，往往是分层次 依次展开的---无论是决策如何分系统 还是决策技术选型都是如此

3、架构无处不在

架构设计就是需求分配，即将满足需求的职责分配到组件上。

可复用、可传递

3、软件架构建模

# 根据建模的侧重点不同，可以将软件架构的模型分为五种
1、结构模型
2、框架模型
3、动态模型
4、过程模型
5、功能模型：一种特殊的框架模型

4、软件架构风格

软件架构设计的一个核心问题是能否达到架构级的软件复用，
也就是说，能否在不同的系统中，使用同一个软件架构。

软件架构风格是描述一种特定应用领域中 系统组织方式的惯用模式。

架构风格定义了一个系统“家族”，即一个架构定义、一个词汇表和一组约束。
词汇表：中包含一些构件和连接件类型，
约束：指出系统是如何将这些构件和连接件组合起来使用

架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个构件有效的组成一个完整的系统。

4.1 经典架构风格

# 5种
1、数据流风格
2、调用/返回风格
3、独立构件风格
4、虚拟机风格
5、仓库风格

1、数据流风格

2、调用\返回风格

补充：MVC架构-Model View Controller

将系统分为模型（Model）、视图（View）和控制器（Controller）三个部分，
1.模型负责处理数据;
	[应用问题域中包含的抽象领域知识]
2.视图负责展示数据;
	[将应用问题域中包含的抽象领域知识呈现给用户的方法；一个模型可以用于多个视图]
3.控制器负责协调模型和视图之间的交互，以实现系统的灵活性和可扩展性。
	[用户界面对用户输入的相应方式]

3、独立构件风格

4、虚拟机风格

解释器

在虚拟机风格中，解释器是一种将源代码逐条解释并执行的软件程序。
它将高级语言或特定领域语言的代码逐条翻译成虚拟机能够执行的指令，并逐步执行这些指令来实现代码的功能。

解释器的工作方式是逐条读取源代码，将每条代码转化为一系列虚拟机指令，并按顺序执行这些指令。
解释器会逐条解释指令中的操作，根据需要读取和修改虚拟机的状态（例如变量的值、函数的调用栈等），并根据指令的规定执行相应的操作。
这种逐条解释和执行的过程使得解释器的执行速度相对较慢，但具有一定的灵活性和跨平台性。

基于规则的系统

基于规则的系统是一种在虚拟机风格中 应用 规则引擎的软件系统。
这种系统使用规则引擎来推理、匹配和处理规则，从而实现特定的功能和逻辑。

基于规则的系统的核心是：规则引擎，它负责解析、匹配和执行规则。

5、仓库风格

数据库系统

仓库风格的数据库系统是一种将数据存储在中央仓库中的系统。
这种系统结构常见于传统的数据仓库和商业智能系统，
用于集中存储和管理大量的结构化和非结构化数据，并支持数据的分析和报告。

在仓库风格的数据库系统中，数据仓库可以被看作是一个中央化的数据存储和管理机构，用于集中存储来自多个源系统的数据，并按照一致的数据模型进行组织和管理。
数据可以从各种数据源（例如生产系统、事务性数据库、外部数据源等）中提取、清洗和转换，然后装载到数据仓库中

黑板系统

仓库风格的黑板系统（Warehouse-style Blackboard System）是一种基于分布式计算的问题解决框架，用于处理大规模、复杂和动态的问题。

黑板系统的核心思想是将问题分解成多个子问题，
并通过共享数据和知识来实现分布式的问题求解。

超文本系统

仓库风格的超文本系统（Warehouse-style Hypertext System）
是一种将超文本内容存储在多个服务器上，
并在需要时 透明地将其组合到单个网页中的系统。

4.2 层次架构风格

4.2.1 两层架构

4.2.2 三层C/S架构

4.3.3 B/S架构

B/S架构是三层C/S架构的一种实现方式。

浏览器   web服务器   数据库服务器
表示层   功能层      数据层

• 应用程序以网页的形式存放在 Web服务器 上；
• 客户运行某个应用程序，只需再客户端的浏览器中键入相应的网址，调用Web服务器上的应用程序，对数据库进行操作，完成相应的数据处理工作，最终通过浏览器显示给客户。
• 真正达到了“零客户端”

缺点

1. 缺乏对动态页面的支持能力，没有集成有效的数据库处理功能；
2. 安全性难以控制；
3. 数据查询等响应速度远远低于C/S架构；
4. B/S架构的数据提交一般以 页面 为单位，数据的动态交互性不强，不利用OLTP应用。

4.3.4 优缺点对比

4.3 富互联网应用-RIA

4.3.1 RIA的概念

针对B/S架构所存在的缺点，如果一味的提升服务器和网络的速度，既不现实又不经济，一种可行的技术方案是 采用高度互动性和局部智能性的客户端程序，这样，就可以在无需刷新全页或增加带宽的情况下，迅速响应用户的输入并作出相应的处理。这种技术就是RIA。

"富"的含义

• 丰富的数据模型
• 丰富的用户界面

传统的C/S架构是 线性设计方式，用户唯一的选择就是用 批处理方式 提交页面到服务器。
连续处理服务器请求和页面更新存在许多阻碍，如：页面响应时间，网络带宽，以及满足 会话或状态交叉连接 而不断增长的日常开销。

从早期的服务器响应整个界面的运作模式，迁移到只对发出请求的特定区域进行改变的模式上来。

4.3.2 客户端开发技术

# 支持RIA的平台或工具主要有以下几个
1、Flex
2、Bindows
3、Java
4、Laszlo
5、XUL
6、Avalon

4.3.3 异步JavaScript 和 XML - AJAX

异步JavaScript 和 XML （Asynchronous JavaScript And XML，AJAX）
由几种技术组合而成

1. 使用XHTML和CSS标准的表示
2. 使用DOM进行动态显示和交互
3. 使用XML和XSLT进行数据交换及相关操作
4. 使用XMLHttpRequest与服务器进行异步通信
5. 使用Javascript绑定一切

使用AJAX，可以在用户单击按钮时，使用JavaScript和DHTML立即更新用户界面，并向服务器发送异步请求，以执行更新或查询数据库。当请求返回时，可以使用JavaScript和CSS来相应的更新用户界面，而不是刷新整个界面。

最重要的是，用户甚至不知道浏览器正在和服务器通信，web站点看起来是即时响应的。

使用AJAX的最大优点，就是能在不更新整个页面的前提下维护数据，使得web系统更为迅捷的回应用户动作，并避免了在网络上发送那些没有改变过的信息。

使用AJAX的最大缺点，它可能破坏浏览器"后退"按钮的正常行为，在动态更新页面的情况下，用户无法回到前一个页面状态。

# 如何解决
在用户单击 后退 按钮，访问历史记录的时候，
通过建立或使用一个隐藏的 IFRAME 来重现页面的变更

XHTML	可扩展超文本标识语言
CSS	层叠样式表
DOM	文档对象模型
XSLT	用于转换的可扩展样式表语言

XML

只需要将XML格式的数据发送给客户端，客户端就可以自行对其进行编辑和处理，而不仅仅是显示

XHTML

是一个基于XML的标记语言，是一个扮演着类似HTML角色的XML，结合了部分XML的强大功能和大多数的HTML的简单特性。建立XHTML的目的就是实现HTML向XML的过渡。

JavaScript

JavaScript是一种粘合剂，使AJAX应用 的各部分集成在一起。在AJAX中，JavaScript主要用来传递用户界面上的数据到服务端并返回结果。

XMLHttpRequest

XMLHttpRequest对象 用来响应通过HTTP传输的数据，一旦数据返回到客户端，就可以立刻使用DOM将数据显示在网页上。

DOM

DOM为XML文档的已解析版本 定义了一组接口，解析器读入整个文档，构件一个驻留内存的树结构，然后代码就可以使用DOM接口来操作这个树结构。

XSLT

将XML文档转换为XHTML文档或者其他XML文档的语言，可以用在客户端和服务端，它能减少大量的使用JavaScript编写的应用逻辑。

CSS

理解为一组样式即可

补充：模型驱动架构-MDA

5、面向服务的架构

了解

5.1 SOA概述

• SOA 并不是新鲜事物，是面向对象模型的一种替代。
• 虽然基于SOA的系统并不排除适用OOD来构建单个服务，但是其整体设计却是面向服务的。
• SOA 的一个典型例子是：CORBA
• SOA建立在XML等新技术的基础上，通过使用基于XML的语言来描述接口，服务已经转到更灵活的接口系统中。

SOA模型示例

• 在SOA模型中，所有的功能都定义成独立的服务。
• 服务之间通过交互和协调完成业务的整体逻辑。
• 所有的服务通过服务总线或流程管理器来连接。

5.1.1 服务的基本结构

5.1.2 SOA设计原则

1. 明确定义的接口；
2. 自包含和模块化；
3. 粗粒度：服务的数量不应该太多，依靠消息交互而不是远程过程调用。通常消息量比较大，但是服务之间的交互频度较低。；
4. 松耦合：服务请求着可见的是服务的接口。服务的位置、实现技术、当前状态和私有数据等，对服务请求者来说，是不可见的；
5. 互操作性、兼容和策略声明

5.1.3 服务构件与传统构件

• 服务构件往往是粗粒度的，传统构件以细粒度居多；
• 服务构件的接口是标准的，主要是服务描述语言接口。而传统构件常以具体的API形式出现；
• 服务构件的实现 与语言无关，而传统构件常绑定某种特定的语言；
• 服务构件可以通过 构件容器 提供 QoS服务，而传统构件完全由程序代码直接控制。

5.2 SOA的关键技术

1、UDDI：统一描述、发现和集成
2、WSDL：web服务描述语言
3、SOAP：简单对象访问协议
4、REST：表述性状态转移
...

5.2.1 UDDI

统一描述、发现、集成 Universal Description Discovery and Integration

• 是服务的信息注册规范。
• UDDI规范 描述了服务的概念，同时也定义了一种编程接口。
• 通过UDDI提供的标准接口，企业可以发布自己服务 供其他企业查询和调用，也可以查询特定服务的描述信息，并动态绑定到该服务上。

在UDDI技术规范中，主要包含以下三部分的内容：

1. 数据模型
2. API
3. 注册服务

5.2.2 WSDL

WSDL - Web Service Descriotion Language，web服务描述语言

• 是对服务进行描述的语言
• 它有一套基于XML的语法定义
• WSDL描述的重点是服务，它包含服务实现定义和服务接口定义。

5.2.3 SOAP

SOAP - Simple Object Access Protocal 简单对象访问协议

• 定义了服务请求者和服务提供者之间的消息传输规范。
• SOAP使用XML来格式化消息，用HTTP来承载消息。
• 通过SOAP，应用程序可以在网络中进行数据交换和远程过程调用[Remote Procedure Call - RPC]

SOAP主要包括以下四部分：

1. 封装
2. 编码规则
3. RPC表示
4. 绑定

SOAP消息基本上是发送端到接收端的单向传输，但它们常常结合起来执行类似于 请求/应答 的模型。
所有的SOAP消息都是用XML进行编码。
SOAP消息包括以下三个部分

1. 封装（信封）：元素名是envelop
2. SOAP头：元素名是header
3. SOAP体：元素名是body

5.2.4 REST

表述性状态转移

• 是一种只使用HTTP和XML进行基于web通信的技术，可以降低开发的复杂性，提高系统的可扩展性。
• 简单性和缺少严格配置文件，使它与SOAP很好的隔离开来。
• REST从根本上只支持几个操作：POST GET PUT DELET

5.3 SOA的实现方法

# 比较主流的有：
1、Web Service
2、企业服务总线
3、服务注册表

待丰富

5.4 补充：微服务架构

将系统分为若干个独立的小型服务，每个微服务负责一部分功能，
以实现系统的可伸缩性和自治性。

微服务架构和SOA对比

6、软件架构评估

6.1 架构评估概述

软件架构评估，可以只针对一个架构，也可以针对一组架构。
在架构评估过程中，评估人员所关注的是：系统的质量属性。

# 先介绍两个概念 敏感点和权衡点
敏感点：是一个或多个构件（和/或之间之间的关系）的特性
权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。

# 从目前已有的软件架构评估技术来看，可以归纳为三类主要的评估方式
1、基于调查问卷（或检查表）的方式
2、基于场景的方式
3、基于度量的方式

1、基于调查问卷（或检查表）的方式

2、基于场景的方式

3、基于度量的方式

6.2 ATAM评估方法

1、评估参与者
2、评估活动
（1）描述ATAM方法
（2）描述业务动机
（3）描述架构
（4）确定架构方法
（5）生成质量属性效用树
（6）分析架构方法
（7）讨论场景和对场景分级
（8）分析架构方法
（9）描述评估结果
3、CBAM 评估方法

1、评估参与者

2、评估活动

3、CBMA评估方法

6.3 SAAM评估方法

7、软件产品线

• 软件产品线是一个产品集合。
• 软件产品线主要由两部分组成
  （1）核心资源：是产品线中产品构造的基础。必定包含 a.产品线中所有产品共享的产品线架构，b.新设计开发的或通过对现有系统再工程得到的、需要在整个产品线中系统化复用的构件 c.与构件相关的测试计划、测试实例以及所有设计文档 d.需求说明书 e.领域模型 f.领域范围的定义 g.采用COTS的构件
  （2）产品集合

7.1 产品线的过程模型

软件产品线的过程模型主要有：双生命周期模型、SEI模型和三生命周期模型

1、双生命周末模型

2、SEI模型

3、三生命周期模型

7.2 产品线的建立方式