第6章 软件体系结构建模

1、5.1 “4+1” 视图模型5.2 软件体系结构的核心模型5.3 软件体系结构的生命周期模型研究软件体系结构的首要问题是：如何表示软件研究软件体系结构的首要问题是：如何表示软件体系结构，即如何对软件体系结构体系结构，即如何对软件体系结构 建模建模 结构模型结构模型：以构件、连接件等概念刻画软件结构：以构件、连接件等概念刻画软件结构 框架模型框架模型：更侧重描述整体结构：更侧重描述整体结构 动态模型动态模型：描述系统的重新配置或演化过程：描述系统的重新配置或演化过程 过程模型过程模型：描述构造软件的步骤和过程：描述构造软件的步骤和过程 功能模型功能模型：描述功能构件的层次组成关系：描述功能构件的

2、层次组成关系23最终用户：功能需求最终用户：功能需求场景视图场景视图编程人员：软件管理编程人员：软件管理系统集成人员：性能系统集成人员：性能可扩充性、吞吐量等可扩充性、吞吐量等系统工程人员：系统系统工程人员：系统拓扑、安装、通信等拓扑、安装、通信等每个视图只关注软件系统的一个侧面每个视图只关注软件系统的一个侧面五个视图结合起来才能反映系统软件体系结构的全部内五个视图结合起来才能反映系统软件体系结构的全部内容容4软件体系架构设计应软件体系架构设计应“将系统划分成不同模块将系统划分成不同模块”但但一旦开始深入实践，就会产生不少疑问：一旦开始深入实践，就会产生不少疑问： 从用户角度而言，组成系统的是

3、各种功能的模块，这属从用户角度而言，组成系统的是各种功能的模块，这属于架构设计的范围吗？于架构设计的范围吗？ 对开发人员来说，他们认为系统是由不同的程序包组成对开发人员来说，他们认为系统是由不同的程序包组成的，架构设计师应不应该把这些都丢给程序员决定呢？的，架构设计师应不应该把这些都丢给程序员决定呢？ 此外，运行时软件系统又是由进程、线程等组成的，这此外，运行时软件系统又是由进程、线程等组成的，这属不属于架构设计的范围呢？属不属于架构设计的范围呢？5软件体系架构设计应软件体系架构设计应“规定系统各模块之间如何规定系统各模块之间如何交互交互”, 但一旦开始深入实践，又困惑于：但一旦开始深入实践，

4、又困惑于： 在用户看来，抽象的功能模块之间可以相互（直接或间在用户看来，抽象的功能模块之间可以相互（直接或间接）调用功能服务，只有这样才能完成最终系统需要的接）调用功能服务，只有这样才能完成最终系统需要的业务功能，这是否属于架构设计的决策范围呢？业务功能，这是否属于架构设计的决策范围呢？ 程序类组成程序包，程序包组成程序系统，这些程序代程序类组成程序包，程序包组成程序系统，这些程序代码之间的调用等交互关系既有局部于包内的，也有跨包码之间的调用等交互关系既有局部于包内的，也有跨包进行的，那么哪些属于架构师应该考虑的呢？进行的，那么哪些属于架构师应该考虑的呢？ 架构可以不关心进程或线程间的通讯和并

5、发等问题吗？架构可以不关心进程或线程间的通讯和并发等问题吗？6由于软件体系结构概念是高度抽象的，所以在软件体系由于软件体系结构概念是高度抽象的，所以在软件体系结构概念与结构设计实践之间，似乎存在某种结构概念与结构设计实践之间，似乎存在某种“鸿沟鸿沟”软件结构视图软件结构视图连接软件体系结构的概念和实际的开连接软件体系结构的概念和实际的开发实践需要发实践需要软件体系结构要涵盖的内容和决策太多了，超过了人脑软件体系结构要涵盖的内容和决策太多了，超过了人脑“一蹴而就一蹴而就”的能力范围，因此采用的能力范围，因此采用“分而治之分而治之”的办法从不的办法从不同视角分别设计同视角分别设计软件体系结构的每个

6、视图分别关注不同的方面，同时也软件体系结构的每个视图分别关注不同的方面，同时也为软件体系结构的理解、交流和归档提供了方便为软件体系结构的理解、交流和归档提供了方便78同一事物的不同视图之间是有联系的。对比上面两幅图，除了南美洲之外基本都是降水量足的地方人口较密集9最终用户：功能需求最终用户：功能需求场景视图场景视图编程人员：软件管理编程人员：软件管理系统集成人员：性能系统集成人员：性能可扩充性、吞吐量等可扩充性、吞吐量等系统工程人员：系统系统工程人员：系统拓扑、安装、通信等拓扑、安装、通信等每个视图只关注软件系统的一个侧面每个视图只关注软件系统的一个侧面五个视图结合起来才能反映系统软件体系结构

7、的全部内五个视图结合起来才能反映系统软件体系结构的全部内容容10逻辑架构关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的“辅助功能模块”；它们可能是逻辑层、功能模块、类等开发架构关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件运行架构关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。开发架构一般偏重程序包在编译时期的静态依赖关系，而运行架构比较关注的是这些运行时单元的交互问题物理架构关注“目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器，以及如何部署机器和网络来

8、配合软件系统的可靠性、可伸缩性等要求1112面向对象：类图等面向对象：类图等场景视图场景视图层次结构框架：层次越低，通用性越强层次结构框架：层次越低，通用性越强基于层次的基于层次的C/SC/S结构及扩展结构及扩展系统工程人员：系统系统工程人员：系统场景可以看作是那些重要系统活动的抽象，它可以帮助设计者找到场景可以看作是那些重要系统活动的抽象，它可以帮助设计者找到体系结构的构件和它们之间的作用关系。同时，也可以用场景来分体系结构的构件和它们之间的作用关系。同时，也可以用场景来分析一个特定的视图，或描述不同视图构件间是如何相互作用的析一个特定的视图，或描述不同视图构件间是如何相互作用的显示及用户接

9、口机械服务基本元素航空信息空中交通管理飞行管理外部接口网关仿真和培训会话终端控制器转换服务连接服务编号计划13公用构件1低层服务支撑机制：通信、时间、储存、资源管理等2航空类、空中交通管制类3空中交通管制功能区：飞行管理、雷达管理等4人机接口外部系统5离线工具测试工具各种各样的空中交通管制系统特定的空中交通管制系统构件空中交通管制系统框架分布式虚拟机基本元素硬件、操作系统、数据库领域特定领域无关通用空中交通管制代码客户定制14控 制 器 进 程慢 周 期 控制 器 任 务快 周 期 控制 器 任 务主 控 制器 任 务终 端 进 程15C主KKKKKKKKF备份F主F备份F主C备份16（1）摘

10、机小王:控制器编号计划小王:终端小王:会话（2）拨号音（3）号码（4）号码（5）打开会话17逻辑视图和开发视图描述系统的静态结构逻辑视图和开发视图描述系统的静态结构运行视图和部署视图描述系统的动态结构运行视图和部署视图描述系统的动态结构场景视图对于所有的情况均适用场景视图对于所有的情况均适用并不是所有的软件架构都需要并不是所有的软件架构都需要“41”视图：视图： 只有一个处理器，则可以省略部署视图只有一个处理器，则可以省略部署视图 如果仅有一个进程或程序，则可以省略运行视图如果仅有一个进程或程序，则可以省略运行视图 对于小型系统，可能逻辑视图与开发视图非常相似，而对于小型系统，可能逻辑视图与开

11、发视图非常相似，而不需要分开的描述不需要分开的描述181920设备调试员通过使用该系统，可以察看设备状态，设备设备调试员通过使用该系统，可以察看设备状态，设备的状态信息由专用的数据采集器实时采集、发送调试命的状态信息由专用的数据采集器实时采集、发送调试命令令 约束性需求：企业级的商业考虑（如：项目预算有限）, 最终用户级的实际情况（如：用户的平均电脑操作水平偏低）, 具体技术的明确要求（如：能在Linux上运行）, 考虑开发团队的真实状况（如：开发人员分散在不同地点）运行期质量属性：主要指软件系统在运行期间表运行期质量属性：主要指软件系统在运行期间表现出的质量水平，例如：软件系统的易用性、性现

12、出的质量水平，例如：软件系统的易用性、性能、持续可用性、安全性等能、持续可用性、安全性等此类属性非常关键，因为它们直接影响着客户对此类属性非常关键，因为它们直接影响着客户对软件系统的满意度，大多数客户也不会接受运行软件系统的满意度，大多数客户也不会接受运行期质量属性拙劣的软件系统期质量属性拙劣的软件系统 应用层负责设备状态的显示，并提供模拟控应用层负责设备状态的显示，并提供模拟控制台供用户发送调试命令制台供用户发送调试命令 嵌入层负责对调试设备的具体控制，以及高嵌入层负责对调试设备的具体控制，以及高频度地从数据采集器读取设备状态数据频度地从数据采集器读取设备状态数据 应用层通过通讯层与嵌入层交

13、互，通讯层负应用层通过通讯层与嵌入层交互，通讯层负责在责在RS232协议之上实现一套专用的协议之上实现一套专用的“应用应用协议协议“：当应用层发送来包含调试指令的协：当应用层发送来包含调试指令的协议包，由通讯层负责将之传递给嵌入层，当议包，由通讯层负责将之传递给嵌入层，当嵌入层发送来原始数据，由通讯层将之解释嵌入层发送来原始数据，由通讯层将之解释成应用协议包发送给应用层成应用协议包发送给应用层考虑到“一部分开发人员没有嵌入式开发经验”, 架构师有必要明确说明系统的目标程序是如何编译而来的：(1) 应用层目标程序 pc-moduel.exe (2) 嵌入式模块rom-module.hex多线程异

14、步交互数据缓冲中断应用层中的线程代表主程序的运行，它直接利用了应用层中的线程代表主程序的运行，它直接利用了MFC的主窗口线程。无论是用户交互，还是串口的数据到达的主窗口线程。无论是用户交互，还是串口的数据到达，均采取异步事件的方式处理，杜绝了任何，均采取异步事件的方式处理，杜绝了任何忙等待忙等待无无谓的耗时，也缩短了系统响应时间谓的耗时，也缩短了系统响应时间通讯层有独立的线程控制着通讯层有独立的线程控制着上上下下上上下下的数据，并设置的数据，并设置了数据缓冲区，使数据的接收和数据的处理相对独立，了数据缓冲区，使数据的接收和数据的处理相对独立，从而数据接收不会因暂时的处理忙碌而停滞，增加了系从而

15、数据接收不会因暂时的处理忙碌而停滞，增加了系统吞吐量统吞吐量嵌入层的设计中，分别通过时钟中断和嵌入层的设计中，分别通过时钟中断和RS232口中断来口中断来激发相应的处理逻辑，达到轮询和收发数据的目的激发相应的处理逻辑，达到轮询和收发数据的目的 描述了设备调试系统软件和硬件的映射关系: 嵌入部分驻留在调试机中（调试机是专用单板机），而PC机上是常见的桌面可执行程序的形式 32构件构件：具有某种功能的可重用：具有某种功能的可重用的软件单元，可分为原子构件的软件单元，可分为原子构件及复合构件及复合构件连接件连接件：构件之间的交互，如：构件之间的交互，如过程调用、协议、过程调用、协议、SQL链接链接配

16、置配置：构件和连接件的拓扑逻：构件和连接件的拓扑逻辑和约束辑和约束端口端口：构件和外部环境交互点：构件和外部环境交互点角色角色：连接件接口由一组角色：连接件接口由一组角色组成，每一个角色定义了该连组成，每一个角色定义了该连接件表示的交互的参与者接件表示的交互的参与者软件体系结构配置连接件构件端口角色1:N1:N1:N34在软件开发引入了软件体系结构之后，软件应用系统的在软件开发引入了软件体系结构之后，软件应用系统的构造过程变为：构造过程变为： 问题定义问题定义 需求分析需求分析 软件体系结构设计软件体系结构设计 软件系统软件系统设计设计 软件实现软件实现 软件测试与维护软件测试与维护在建立软件

17、体系结构时：设计师主要是从结构的角度对在建立软件体系结构时：设计师主要是从结构的角度对整个系统进行分析，选择恰当的构件，构件间的相互作整个系统进行分析，选择恰当的构件，构件间的相互作用关系以及对它们的约束，最后形成一个系统框架以满用关系以及对它们的约束，最后形成一个系统框架以满足用户需求，为后续的软件设计奠定基础足用户需求，为后续的软件设计奠定基础需求分析需求分析：获取用户需求，确定系统所要用到的构件。：获取用户需求，确定系统所要用到的构件。包括：明确软件功能及满足质量属性的非功能需求；生包括：明确软件功能及满足质量属性的非功能需求；生成类图并完善及分组；把类打包成构件；需求评审（构成类图并完

18、善及分组；把类打包成构件；需求评审（构件是否合理）等阶段件是否合理）等阶段建立体系结构建立体系结构：选择合适的体系结构风格，将构件集成：选择合适的体系结构风格，将构件集成其中，并细化构件间的交互关系其中，并细化构件间的交互关系设计、实现及测试设计、实现及测试：设计构件间的详细接口；实现构件：设计构件间的详细接口；实现构件并组装构件，完成整个软件的合成；测试单个构件的功并组装构件，完成整个软件的合成；测试单个构件的功能，并测试组装后整体软件的功能及性能等能，并测试组装后整体软件的功能及性能等体系结构的非形式化描述体系结构的形式化基础（数学模型）体系结构的规范描述体系结构演化体系结构提供、评价和度量体系结构的终结体系结构实施体系结构求精的验证体系结构求精体系结构的性质分析需要演化或扩展否否是需要求精否是否为什么需要多视图模型为什么需要多视图模型4+1 视图模型的内容视图模型的内容软件体系结构的核心模型软件体系结构的核心模型软件体系结构的生命周期模型软件体系结构的生命周期模型381、阅读英文文章：、阅读英文文章： Architectural BlueprintsThe “4+1” View Model of Software Architecture - Kruchten （1995）2、 “4+1” 视图建模实践：视