【系统分析师之路】第二十三章 软件架构体系(视频笔记)
软件架构的概念
需求做好以后，需要将需求转换成详细设计，这两个阶段会有脱节的情况，有鸿沟的情况，这个时候就需要一个老师傅，他知道如何应对需求并做成方案，来衔接需求和设计这两部分。
将识别到的软件需求分配到各个部分就是架构做的事情。
架构设计的一个核心问题就是能够达到架构级别的复用。 架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。
| UML的4+1视图 | 结构类型 | 对应关系 | 4+1视图特征说明 |
|---|---|---|---|
| UML逻辑视图 | 静态结构 | 对应最终用户 | 功能需求 |
| UML实现视图 | 静态结构 | 对应开发人员 | 也叫模块视图，侧重软件模块的组织和管理 |
| UML进程视图 | 动态结构 | 对应进程视图 | 性能，吞吐量，侧重于系统的运行特征 |
| UML部署视图 | 动态结构 | 对应物理视图 | 系统拓扑，安装通信，主要考虑如何把软件映射到硬件上 |
| UML用例视图 | – | 对应场景 | 重要系统活动的抽象 |
软件架构风格
架构风格反映了领域中众多系统所共有的结构和语义特征，并指导如何将各个构件有效的组织成一个完整的系统。
软件架构领域很多思想借鉴了建筑领域的内容。 通过对架构风格的定义，在项目中可以更好的实现技术的沟通。
目前主流的一共有五种架构风格，现在的软件开发过程中，往往会使用这其中的一种或多种风格的组合情况。
数据流风格
典型代表就是批处理和管道过滤器风格。它的思想就是整个架构是以数据为导向的。
批处理风格有一个特点就是在整个流程当中是没有和用户交互的。 批处理风格中数据必须是完整的。而管道过滤器是支持流式的数据处理。如果部分处理完的话，那么先处理完的那部分就进入第二阶段进行处理，它不必等着一批处理完再走下一批，这就是管道过滤器和批处理最大的不一样的地方。
在DOS系统中，如果需要执行多个命令，一个命令的输出就是另一个命令的输入。这就是管道过滤器风格的显著特征。 编译器先做词法分析再做语法分析，它也用到了管道过滤器风格。
独立构件风格
进程通信和事件驱动风格。
进程通信：属于独立构件中的一种。构件是独立的过程，连接件是消息传递，构件通常是命名过程，消息传递的方式可以是点对点，异步或者同步的方式，以及远程过程方法调用等。
隐式调用：事件所产生的效果是不清楚的。建立一种关系，然后通过查找这种关系来建立对应的过程。它主要的优点就是软件复用性高，为构件的维护和演化带来了方便，其缺点是构件放弃了对系统计算的控制。
调用返回风格
面向对象，层次架构和主程序子程序都是属于该风格。它是所有的架构风格当中用得最多的风格。主程序子程序是把问题划分为若干个处理步骤，一般为单线程。 对象和对象之间调用方法来完成功能，我们称之为显式调用。
七层网络模型就是层次结构，B/S架构，C/S架构也是层次结构的一个应用。分层次架构后，问题的复杂度就降低了。而且耦合度也会得到降低。
分层结构的缺点：如果分层多了，自然效率就会低下了，层次划少了很多东西理不清楚。
虚拟机风格
解释器和基于规则的系统属于该风格。虚拟机屏蔽了操作系统层面不同的内容，从而实现跨平台。 基于规则的系统：包括规则集，规则解释器，规则/数据选择器和工作内存，一般用在人工智能领域和DSS中。 解释器通常包含一个完成解释工作的解释引擎，一个包含将被解释的代码的存储区，一个记录解释引擎当前工作状态的数据结构，以及一个源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和关键应用，其缺点是执行效率比较低。
仓库风格
它是以数据为中心的风格，其他都是围绕数据来展开的。它包括黑板系统，数据库系统，超文本系统。
黑板系统：包括知识源，黑板和控制三个部分组成。黑板系统很多地方和数据库系统是类似的。所有的操作都是根据黑板上知识源的变化来进行控制，也是和数据库系统唯一不同的地方。黑板系统通常应用在对于解决问题没有确定性算法的软件中（信号处理，编译器优化，问题规划）
数据共享：构件主要有两大类，一类是中央共享数据源，保存当前系统的数据状态；另一类是多个独立的单元，处理单元对数据元素进行操作。
构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想方式任意跳转到相关构件。超文本是一种非线性的网状信息组织方法，它以节点为基本单位，链作为节点之间的联想方式关联。超文本系统通常应用在互联网领域。
黑板系统
- 黑板：是一个全局数据库，包含问题域解的全部状态，是知识源相互作用的唯一媒介
- 知识源：包括若干独立计算的不同单元。提供解决问题的知识。知识源响应黑板的变化，也只修改黑板。
- 控制：知识源的响应是通过黑板状态的变化来控制的。
三层B/S架构
B/S架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。 B/S架构的安全性难以控制 B/S架构在数据查询等响应速度上，要远远低于C/S架构。 B/S架构数据提交一般以页为单位，数据的动态交互性不强，不利于OLTP应用。
三层C/S架构
各层在逻辑上保持相对独立，整个系统的逻辑结构更为清晰，能提高系统或软件的可维护性和可扩展性。 允许灵活有效的选用相应的平台和硬件系统，具有良好的可升级性和开放性。 各层可以并行开发，各层也可以选择各自最合适的开发语言。 功能层有效地隔离表示层和数据层，为严格的安全管理奠定了坚实的基础，整个系统的管理层次也更加合理和可控制。
富互联网
RIA结合了C/S架构反应速度快，交互性强的优点，以及B/S架构传播范围广及易于传播的特点。 数据能够被缓存在客户端，从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面。 解决了B/S架构交互力不强的问题。传统的BS架构以文字居多并加一点图片，提交以页面为单位，这样如果表单中某一项有问题而无法提交成功的话，表单中其他输入信息就会丢失，这样用户体验感就不好了，所以就有了AJAX技术。
AJAX是富互联网技术的一个典型应用。 FLEX也是富互联网的一个经典应用，网游的精美的画面就是用到了FLEX这项技术。富互联网技术使得界面的交互能力得到了加强，同时数据还可以缓存到客户端，所以比传统的B/S架构更加的快。
AJAX是异步的JavaScript和XML。它有以下五个特点：
- 使用DOM进行动态显示和交互
- 使用XML和XLST进行数据交换及相关操作
- 使用XMLHttpRequest与服务器进行异步通信
- 使用JavaScript绑定一切
- 基于XHTML和CSS标准的表示
MushUp技术是一种信息的杂凑技术。手机浏览Web的信息，局限性比较大。它可以聚合信息然后以统一的格式：HTML的格式推送给手机相应的客户端，这样一来就可以把复杂的问题简单化了。让手机也可以浏览和处理原来难以处理的数据格式。
| MushUp技术 | 说明 |
|---|---|
| RSS | 一种用于对网站内容描述和同步的格式，是目前最广泛的Web资源发布方式 |
| REST | 从资源的角度看待这个网络，各处的资源由URI确定，客户端的应用通过URI获取资源的表示 |
| SOAP | 一种基于XML的数据格式定义，用来进行Web服务调用过程中的参数调用和返回 |
| ATOM | 一种基于XML的文档格式，和基于HTTP的协议，用来聚合网络内容 |
质量属性
| No | 质量属性 | 说明 |
|---|---|---|
| 01 | 性能Performance | 是指系统的影响能力，即要经过多长时间才能对某个事件作出响应，或者在某段时间内系统所能处理的事件的个数。通常用单位时间内所处理事务的数量或系统完成某个事务处理所需来对性能进行定量的表示。性能测试经常要使用基准测试程序（用以测量性能指标的特定事务集或工作量环境） |
| 02 | 可靠性 | 软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特征的基本能力。可靠性通常用平均失效等待时间MTTF和平均失效间隔时间MTBF来衡量，在失效率为常数和修复时间很短的情况下，MTTF和MTBF几乎相等 |
| 03 | 可用性 | 系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示 |
| 04 | 安全性 | 是指系统在向合法用户提供服务的同时能够阻止非授权用户的使用的企图或拒绝服务的能力。安全性是系统可能受到的安全威胁的类型来分类的。安全性又可以划分为机密性，完整性，不可否认性和可控性等特征 |
| 05 | 可修改性 | 是指能够快速的以较高的性能价格比对系统进行变更的能力，通常以这些具体的变更为基准，通过考察这些变更的代价来衡量可修改性 |
| 06 | 功能性 | 是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多多大多数构件的相互协作 |
| 07 | 可变性 | 系统结构经过扩充和变更而成为新体系结构的能力，这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品的基础时，可变性是很重要的 |
| 08 | 互操作性 | 作为系统组成部分的软件不是独立存在的，经常需要与其他系统或自身环境相互作用。软件体系结构必须为外部可视的功能特征和数据结构提供精心设计的软件入口。程序和用其他语言编写的软件系统的交互作用就是互操作性的问题，这种互操作性也影响应用的软件体系结构 |
※1：可靠性和可用性的区别：一个是可运行的时长的角度，另一个是从失效的概率的角度来考虑的。架构领域往往是可用性而非可靠性。
※2：互操作性：强调软件往往无法独善其身。
中间件
中间件是一种独立的系统软件，或服务程序，可以帮助分布式应用软件在不同的技术之间共享资源。 它把几个不能互联互通的系统连接起来，比如遗留系统难以互联互通的问题就可以用中间件来解决。 中间件主要做信息的扭转和转化的问题。
中间件的分类：消息中间件，数据库中间件，业务中间件。
业务中间件：负载均衡，业务分配 主要的中间件：远程过程调用，对象请求代理，远程方法调用，面向消息的中间件，事务处理监控器。
Cobra：客户端有桩，服务器端有框架。这样就可以使客户机和服务器类似在本地一样操作。
- 负责客户机和服务器之间的连接和通信，以及客户机和应用层之间的高效率通信机制
- 提供应用层不同服务之间的互操作机制，以及应用层与数据库之间的连接和控制机制
- 提供多种架构的应用开发和运行的平台，以及应用开发框架，支持模块化的应用开发
- 屏蔽硬件，操作系统，网络和数据库的差异
- 提供应用负载均衡和高可用性，安全机制与管理功能，以及交易管理机制保证交易的一致性
- 提供一种通用的服务去执行不同的功能，避免重复的工作和使应用之间可以协作
典型的应用架构-J2EE和NET
- J2EE：是分布式多层应用程序。分为客户机（客户层），J2EE服务器（Web层，业务层），数据存储服务器（企业信息系统层）
J2EE业务层企业Bean：会话Bean用来短暂会话；实体Bean实体化数据；消息驱动Bean：会话Bean+JMS。
二层C/S三层C/S都可以用J2EE来作相应的开发。它可以用来做混合式的开发的。 - NET：最底层是通用语言运行环境，它借鉴与J2EE框架，它就是Java体系中的虚拟机。NET不同于J2EE，它是支持多语言的，这些语言都会被翻译成通用语言规范。通用语言运行规范转化的语言需要运行在通用语言运行环境上。
基础类库：是一种复用的机制。是一些常用的职能类。
★J2EE和NET之争
1.JVM与CLR：这两个是同样思路下的产物
2.对于多层分布式应用的支持：两个体系没有太大的差异。
3.安全性 4.应用程序部署 5.外部支持 ：两个体系没有太大的差异。
6.可移植性：J2EE跨平台性要比NET来得好。NET依赖微软的操作系统平台。但是语言方面NET支持语言更多。
MVC模式
它既是架构模式也是设计模式。在NET框架中就把它放到V这个层次用来解决视图这个层次的问题。 它其实也是分层模型，使得利于解耦。
MVC分为主动和被动两种MVC模型。主动MVC有对模型的观察机制，会把数据主动返回到View。主动MVC能推送数据给视图，但被动模型是没有的。主动MVC就是引入了观察者模式来实现了向视图的推送信息。
- struts：是一个基于J2EE平台的MVC框架，主要采用Servlet和JSP技术来实现。在Struts中，M由实现业务逻辑的JavaBean构成，C由ActionServlet和Action实现，V由一组JSP文件构成。
- Spring：通过RMI或WebService远程访问业务逻辑，允许自由选择和组装各部分功能，还提供其他软件集成的接口。它本身就是一个容器，管理构件的生命周期，构件的组态，依赖注入等，并可以控制构件在创建时是以原型或单例模式来创建。
- Hibernate：是一个对象关系映射框架，提供了Java对象到数据库表之间的直接映射，它对JDBC进行了非常轻量级的对象封装，使得Java程序员可以使用面向对象思维来操作数据库。ORM机制的核心是一个XML文件，该文件描述了数据库模式是怎么与一组Java类绑定在一起的。
典型的应用架构-MVP设计模式
它所有的操作都要经过Presenter。MVC中的C主要做事件的分发，并不做事件业务的处理。而P层可以处理业务逻辑。MVP比MVC更加容易进行工程化测试。
MVC和MVP的一个最大的区别就是View和Model是否有交互。所以MVP在耦合程度上是更加有优势的。
- MVP是MVC的变种
- MVP实现了V与M之间的解耦，（V不直接使用M，修改V不会影响M）
- MVP更好的支持单元测试（业务逻辑在P中，可以脱离V来测试这些逻辑，可以将一个P用于多个V，而不需要改变P的逻辑）
- .MVP中V要处理界面事件，业务逻辑在P中，MVC中界面事件由C处理
基于服务的架构
服务是一种为了满足某项业务需求的操作，规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持。
SOA 基于服务的架构它的标准是高度的统一的。
基于服务的架构统一标准下产生的构件是可以通用的。服务接口：共同的封装，共同的语言格式，共同的安全和容错处理
其标准高度的统一。统一标准下产生的构件是可以通用的。服务相关的协议都是基于XML发展而来的。 遗留系统的集成，信息孤岛的联通这些问题都可以使用SOA来应用。比如可以把遗留系统作为一个个的服务挂接到总线，这样就可以重复利用起来了。 松散耦合，粗粒度和标准化的接口都是服务的特点。
粒度大小：对象 < 构件＜服务。
在可视化的开发过程中会有很多组件，这些组件其实就是构件。
| 服务特征 | 特征说明 |
|---|---|
| 松散耦合 | 将服务提供者和服务使用者在服务实现和客户如何使用服务方面隔离开来 |
| 粗粒度服务 | 服务所公开功能的范围，粗粒度服务是指那些能够提供高层商业逻辑的可用性服务 |
| 标准化接口 | SOA通过服务接口的标准化描述，使得该服务可以提供给在任何异构平台和任何用户接口中使用 |
- 服务构件粗粒度，传统构件细粒度居多
- 服务构件的接口是标准的，主要是WSDL接口，传统构件常以具体API形式出现
- 服务构件的实现于语言无关，传统构件绑定某种特定语言
- 服务构件可以通过构件容器提供QoS的服务，传统构件完全由程序代码直接控制
企业服务总线ESB和WebServers
- WebServers把响应的功能部件封装成响应的Web服务。
- WebService 通过注册中心查找到资源属于动态绑定。 不通过注册中心直接把服务请求者和服务提供者绑定在一起就是静态绑定。
- 企业资源总线不光在软件领域，在硬件领域在网络领域都有这样的提法。我们在使用服务的时候是不需要知道它的位置的。你只要在总线上提出请求，相应的服务会给你回应。
- 企业服务总线和WebService不同的是WebService强调对各种服务的封装，而ESB强调提供一条总线，把遗留系统封装成一个一个的服务给连接起来。它是一种为进行连接服务提供的标准化的通信基础结构。
- ESB在总线上面可以传递的消息服务类型是很多的。 SOAP：是进行消息的通信的协议。
软件产品线技术
- 是一个相对比较复杂的技术，是多种技术的综合体。它包括软件架构，领域过程，DSSA。软件产品线就用了这几个大方面的技术。
- 在软件产品线中一般会构建核心的资源，会有产品的集合。
- 产品线的过程模型：双生命周期模型，三生命周期模型，SEI模型。
- 双生命周期模型分为领域工程（领域分析，领域设计，领域实现）和应用工程（需求分析，系统设计，系统实现），领域工程研究的是各个厂商的共性的部分，所以需求分析中既有领域分析后共同的部分，也有个性化需求的部分。这样就可以利用领域的共性来指导应用的开发。它很好的诠释了领域过程如何介入的问题。
过程模型—SEI模型
它分为核心资源开发，产品开发和管理三个
软件产品线的组织结构
- 设立独立的核心资源小组
- 不设立独立的核心资源小组
- 动态的组织结构
1.对该领域具备长期和深厚的经验
2.一个用于构建产品的好的核心资源库
3.好的产品线架构
4.好的管理支持（软件资源，人员组织，过程）
软件产品线的建立方式
| 演化方式 | 革命方式 | |
|---|---|---|
| 基于现有产品 | 基于现有产品架构设计产品线的架构，经演化现有构件，开发产品线构件 | 核心资源的开发基于现有产品集的需求和可预测的，将来需求的超集 |
| 全新产品线 | 产品线核心资源随产品新成员的需求而演化 | 开发满足所有预期产品线成员的需求的核心资源 |
- 将现有产品演化为产品线
- 用软件产品线替代现有产品集
- 全新软件产品线的演化
- 全新软件产品线的开发
软件体系结构评估
软件主要的评估方式：基于调查问卷或检查表的方式；基于场景的方式；基于度量的方式。在体系结构评估过程中，评估人员所关注的是系统的质量属性。
场景就是系统基于刺激的一种响应。
| 评估方式 | 调查问卷 | 检查表 | 场景 | 度量 |
|---|---|---|---|---|
| 通用性 | 通用 | 特定领域 | 特定系统 | 通用或特定领域 |
| 评估者对架构的了解程度 | 粗略了解 | 无限制 | 中等了解 | 精确了解 |
| 实施阶段 | 早 | 中 | 中 | 中 |
| 客观性 | 主观 | 主观 | 较主观 | 较客观 |
| 架构评估点 | 软件架构评估的特征 |
|---|---|
| 敏感点 | 输入或变化点很小，但对结果的影响很大的地方 |
| 权衡点 | 影响多个质量属性的特征。是多个质量属性的敏感点 |
| 风险点 | 架构设计中潜在的存在问题的一种风险隐患 |
| 非风险点 | 就是没有风险的位置 |
软件架构评估可以分为：架构权衡分析法ATAM，软件架构分析法SAAM，成本效益分析法CBAM 三种。
软件架构评估-SAAM 软件架构分析法
整个过程比ATAM要简单的多。单个评估就是架构和场景的匹配度如何的一种评估。 场景和场景之间也可能存在冲突，所以只满足一个场景是不够用的。这个思路和测试的思路接近，先测试单个模块，再测试多个模块之间的关系。
- 形成场景
- 描述架构
- 对场景的分类和确定优先级
- 对场景进行单个评估
- 评估场景但是相互作用
- 形成总体评估
软件架构评估-架构权衡分析法ATAM
| 步骤 | 步骤名称 | 步骤说明 |
|---|---|---|
| 1 | 描述ATAM方法 | 评估小组的负责人对评估方法进行说明，哪些阶段需要谁配合做什么事情 |
| 2 | 描述业务动机 | 由项目决策者从业务的角度进行描述。比如想要通过这一个项目解决什么样的问题，为什么要做这个项目 |
| 3 | 描述架构 | 由首席设计师来进行架构方面的描述 |
| 4 | 确定架构方法 | 这个是由架构师来完成，可以使用的架构有多种，但决定使用的架构只有一种 |
| 5 | 质量属性效用树 | 它是用树表达出来的质量属性，在树的旁边写上重要度和优先级如何。由评估小组，设计小组，管理人员，客户代表共同去决定来权衡 |
| 6 | 分析架构方法 | 对架构进行评析，这个是由评估小组来进行 |
| 7 | 讨论场景和对场景进行分级 | 各个干系人都有一定的票数，票数和场景不对等。比如有15票可以投你认为重要的15个场景，也可以15票都投票给一个场景 |
| 8 | 分析架构方法 | 由首席架构师再调整配比 |
| 9 | 描述评估结果 | 评估小组负责人来评估方法 |
