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

1、构件与软件复用

1.1 主流构件标准

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

1.2 构件获取与管理

构件的获取

构件的组织

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 层次架构风格

1、两层架构

2、三层C/S架构

3、B/S架构

4、优缺点对比

4.3 富互联网应用-RIA

RIA的概念

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

客户端开发技术

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

5、面向服务的架构

异步JavaScript和XML

AJAX

异步JavaScript和XML 是 Asynchronous JavaScript And XML , AJAX
是由几种蓬勃发展的技术以新的方式组合而成，包括：
1、基于XHTML（可扩展超文本标识语言）和CSS标准的表示
2、使用DOM（Document Object Model，文档对象模型）进行动态显示和交互
3、使用XML和XSLT（用于转换的可扩展样式表语言） 进行数据交互及相关操作
4、使用XMLHttpRequst与服务器进行异步通信
5、使用JavaScript绑定一切

5.1 SOA概述

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

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

服务的基本结构

SOA设计原则

1、明确定义的接口；
2、自包含和模块化；
3、粗粒度；
4、松耦合；
5、互操作性、兼容和策略声明

服务构件与传统构件

5.2 SOA的关键技术

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

1、UDDI

2、WSDL

3、SOAP

4、REST

5.3 SOA的实现方法

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

待丰富

补充：微服务架构

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

微服务架构和SOA对比

补充：模型驱动架构-MDA

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、软件产品线

7.1 产品线的过程模型

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

1、双生命周末模型

2、SEI模型

3、三生命周期模型

7.2 产品线的建立方式