1、第2章软件体系结构建模2 2内容概要n2.1 软件体系结构建模概述 n2.2“4+1”视图模型 n2.3“4+1”视图模型案例分析n2.4“4+1”视图模型补充知识n2.5 软件体系结构核心模型n2.6 软件体系结构生命周期模型 研究软件体系结构的首要问题是如何表示软件研究软件体系结构的首要问题是如何表示软件体系结构，即如何对软件体系结构建模。根据建模体系结构，即如何对软件体系结构建模。根据建模的侧重点不同，可以将软件体系结构的模型分为的侧重点不同，可以将软件体系结构的模型分为5种：种：第第2章章 软件体系结构建模软件体系结构建模2.1 软件体系结构建模概述软件体系结构建模概述 结构模型结构模
2、型 框架模型框架模型 动态模型动态模型 过程模型过程模型 功能模型功能模型 3 32022-12-12 软件体系结构建模的种类软件体系结构建模的种类 第第2章章 软件体系结构建模软件体系结构建模2.1 软件体系结构建模概述软件体系结构建模概述 结构模型结构模型 这是一个最直观、最普遍的建模方法。这种方法以这是一个最直观、最普遍的建模方法。这种方法以体系结构的构件、连接件和其他概念来刻画结构，并体系结构的构件、连接件和其他概念来刻画结构，并力图通过结构来反映系统的重要语义内容，包括系统力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格、性质等。的配置、约束、隐含的假
3、设条件、风格、性质等。研究结构模型的核心是体系结构描述语言。研究结构模型的核心是体系结构描述语言。4 42022-12-12 软件体系结构建模的种类软件体系结构建模的种类 第第2章章 软件体系结构建模软件体系结构建模2.1 软件体系结构建模概述软件体系结构建模概述 框架模型框架模型 框架模型与结构模型类似，但它不太侧重描述结构框架模型与结构模型类似，但它不太侧重描述结构的细节而更侧重于整体的结构。的细节而更侧重于整体的结构。框架模型主要以一些特殊的问题为目标建立只针对框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。和适应该问题的结构。5 52022-12-12 软件体系结构建模
4、的种类软件体系结构建模的种类 第第2章章 软件体系结构建模软件体系结构建模2.1 软件体系结构建模概述软件体系结构建模概述 动态模型动态模型 动态模型是对结构或框架模型的补充，研究系统的动态模型是对结构或框架模型的补充，研究系统的“大颗粒大颗粒”的行为性质。例如，描述系统的重新配置的行为性质。例如，描述系统的重新配置或演化。动态可以指系统总体结构的配置、建立或拆或演化。动态可以指系统总体结构的配置、建立或拆除通信通道或计算的过程。除通信通道或计算的过程。6 62022-12-12 软件体系结构建模的种类软件体系结构建模的种类 第第2章章 软件体系结构建模软件体系结构建模2.1 软件体系结构建模
5、概述软件体系结构建模概述 过程模型过程模型 过程模型研究构造系统的步骤和过程。过程模型研究构造系统的步骤和过程。结构是遵循某些过程脚本的结果。结构是遵循某些过程脚本的结果。7 72022-12-12 软件体系结构建模的种类软件体系结构建模的种类 第第2章章 软件体系结构建模软件体系结构建模2.1 软件体系结构建模概述软件体系结构建模概述 功能模型功能模型 功能模型认为体系结构是由一组功能构件按层次功能模型认为体系结构是由一组功能构件按层次组成，下层向上层提供服务。组成，下层向上层提供服务。功能模型可以看作是一种特殊的框架模型。功能模型可以看作是一种特殊的框架模型。8 82022-12-12 “
6、4+1”模型概述模型概述 第第2章章 软件体系结构建模软件体系结构建模2.2“4+1”视图模型视图模型 以上五种模型各有所长，将五种模型有机的统一在一起，以上五种模型各有所长，将五种模型有机的统一在一起，形成一个完整的模型来刻画软件体系结构更加合适。形成一个完整的模型来刻画软件体系结构更加合适。9 9 WHY：1、每个视图模型可看成对系统不同方面一个投影，一个、每个视图模型可看成对系统不同方面一个投影，一个构架的不同视图其实反映的是同一个系统。构架的不同视图其实反映的是同一个系统。2、各个不同的视图是可以融合在一起的，而且也只有将、各个不同的视图是可以融合在一起的，而且也只有将不同的视图融合在
7、一起才能获得关于一个系统构架的全面信息不同的视图融合在一起才能获得关于一个系统构架的全面信息。“4+1”视图视图模型概述模型概述 第第2章章 软件体系结构建模软件体系结构建模2.2“4+1”视图模型视图模型 10102022-12-12 逻辑视图逻辑视图进程视图进程视图开发视图开发视图物理视图物理视图最终用户：功能需求最终用户：功能需求场景场景编程人员：软件管理编程人员：软件管理系统集成人员：性能系统集成人员：性能可扩充性、吞吐量等可扩充性、吞吐量等系统工程人员：系统系统工程人员：系统拓扑、安装、通信等拓扑、安装、通信等1111 软件架构视图软件架构视图Kruchten在其著作在其著作Rati
8、onal统一过程引论统一过程引论中写道：中写道：一个架构视图是对于从一个架构视图是对于从某一视角或某一点某一视角或某一点上看到的系上看到的系统所做的简化描述，描述中涵盖了系统的统所做的简化描述，描述中涵盖了系统的某一特定方面某一特定方面，而省略了与此方面无关的实体。而省略了与此方面无关的实体。软件架构的每个视图分别关注不同的方面，针对不同软件架构的每个视图分别关注不同的方面，针对不同的目标和用途。的目标和用途。第第2章章 软件体系结构建模软件体系结构建模2.2“4+1”视图模型视图模型 1212 关于视图关于视图气候学家关心的气候学家关心的社会学家关心的社会学家关心的引入视图的作用：引入视图的
9、作用：世界地图的绘制者很难将不同的信息都绘制到同一幅图中；而看地图的人也希望有一幅地图是专门针对他的需要的。同一事物的不同视图之间是有联系的。同一事物的不同视图之间是有联系的。对比上面两幅图，除了南美洲之外基本都是降水量足的地方人口较密集。n“4+1”视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件体系结构。每一个视图只关心系统的一个侧面，5个视图结合在一起才能。n“4+1”视图模型的不同视图之间也存在相互影响。13132022-12-12逻辑视图逻辑视图进程视图进程视图开发视图开发视图物理视图物理视图最终用户：功能需求最终用户：功能需求场景场景编程人员：
10、软件管理编程人员：软件管理系统集成人员：性能系统集成人员：性能可扩充性、吞吐量等可扩充性、吞吐量等系统工程人员：系统系统工程人员：系统拓扑、安装、通信等拓扑、安装、通信等 14142022-12-12逻辑视图逻辑视图进程视图进程视图开发视图开发视图物理视图物理视图最终用户：功能需求最终用户：功能需求场景场景编程人员：软件管理编程人员：软件管理系统集成人员：性能系统集成人员：性能可扩充性、吞吐量等可扩充性、吞吐量等系统工程人员：系统系统工程人员：系统拓扑、安装、通信等拓扑、安装、通信等 1515 “4+1”的由来的由来：四个视图反映的是同一个系统，之所以用了：四个视图反映的是同一个系统，之所以用
11、了第五个视图，第五个视图，“+1”视图，因为它是由一系列重要的案例组视图，因为它是由一系列重要的案例组成。用这些重要的案例将前面的四个视图联系到一起，从而成。用这些重要的案例将前面的四个视图联系到一起，从而组成第五个视图。组成第五个视图。逻辑视图逻辑视图进程视图进程视图开发视图开发视图物理视图物理视图最终用户：功能需求最终用户：功能需求场景场景编程人员：软件管理编程人员：软件管理系统集成人员：性能系统集成人员：性能可扩充性、吞吐量等可扩充性、吞吐量等系统工程人员：系统系统工程人员：系统拓扑、安装、通信等拓扑、安装、通信等 16162022-12-12 逻辑视图逻辑视图进程视图进程视图开发视图开
12、发视图物理视图物理视图最终用户：功能需求最终用户：功能需求场景场景编程人员：软件管理编程人员：软件管理系统集成人员：性能系统集成人员：性能可扩充性、吞吐量等可扩充性、吞吐量等系统工程人员：系统系统工程人员：系统拓扑、安装、通信等拓扑、安装、通信等 1717 逻辑视图逻辑视图进程视图进程视图开发视图开发视图物理视图物理视图最终用户：功能需求最终用户：功能需求场景场景编程人员：软件管理编程人员：软件管理系统集成人员：性能系统集成人员：性能可扩充性、吞吐量等可扩充性、吞吐量等系统工程人员：系统系统工程人员：系统拓扑、安装、通信等拓扑、安装、通信等 1818 逻辑视图逻辑视图进程视图进程视图开发视图开
13、发视图物理视图物理视图最终用户：功能需求最终用户：功能需求场景场景编程人员：软件管理编程人员：软件管理系统集成人员：性能系统集成人员：性能可扩充性、吞吐量等可扩充性、吞吐量等系统工程人员：系统系统工程人员：系统拓扑、安装、通信等拓扑、安装、通信等 1919逻辑视图逻辑视图进程视图进程视图开发视图开发视图物理视图物理视图最终用户：功能需求最终用户：功能需求场景场景编程人员：软件管理编程人员：软件管理系统集成人员：性能系统集成人员：性能可扩充性、吞吐量等可扩充性、吞吐量等系统工程人员：系统系统工程人员：系统拓扑、安装、通信等拓扑、安装、通信等2022-12-122.2.1 逻辑视图：面向对象的分解
14、 n逻辑视图主要支持系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。这种分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。n在面向对象技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。20202022-12-122.2.1 逻辑视图的符号表示法可以从Booch标记法中导出逻辑视图的标记法，只是从体系结构级的范畴来考虑这些符号，用Rational Rose进行体系结构设计。21212022-12-12关联：表示两个类之间存在某种语关联：表示两个类之间存在某种语义
15、上的联系，真正含义由附加在横义上的联系，真正含义由附加在横线上的短语说明。线上的短语说明。包含：实心圆一端表示整体，另一包含：实心圆一端表示整体，另一端表示部分。端表示部分。使用：空心圆一端连接在请求服务使用：空心圆一端连接在请求服务的类，另一端连接在提供服务的类。的类，另一端连接在提供服务的类。继承：箭头由子类指向基类。继承：箭头由子类指向基类。2.2.1 逻辑视图的风格 22222022-12-12会话终端控制器转换服务连接服务编号计划 23232022-12-122.2.1 逻辑视图的例子逻辑视图的例子 24242022-12-12 对于规模更大的系统来说，对于规模更大的系统来说，体系结
16、构级中包含数十甚至体系结构级中包含数十甚至数百个类数百个类。左图是空中交通。左图是空中交通管制系统的顶级类图，该图管制系统的顶级类图，该图包含了包含了8个类种属（即类的分个类种属（即类的分组）。组）。显示及用户接口机械服务基本元素航空信息空中交通管理飞行管理外部接口网关仿真和培训2.2.1 逻辑视图的例子逻辑视图的例子 2.2.2 进程视图：过程分解 n进程视图（process view,也称过程视图）侧重于系统的运行特性，主要考虑的是一些非功能性的需求，诸如性能、可用性等。n它所要面对的问题有并发，分布，系统的完整性，容错能力等。它还要考虑怎样把进程体系结构与逻辑视图体系结构的要点相适应对某
17、个对象的某个操作实际上是在哪个控制线程上发生的。25252022-12-122.2.2 进程视图：过程分解 n可以把进程体系结构分为几个抽象层次来描述，每个层次关注不同的方面。n在最高层次上，进程体系结构可以看做是构成一个执行单元的一组任务n通过进程视图可以估计出消息流和过程负荷，也可以从过程测量一个目标系统最终执行情况。26262022-12-122.2.2 进程视图的符号表示法 构 件事 件 广 播双 向 消 息远 程 过 程 调 用消 息未 指 定连 接 件循 环 进 程简 化 进 程进 程 通过扩展通过扩展Booch对对Ada任务的表示法，来表任务的表示法，来表示进程视图。示进程视图。
18、2.2.2进程视图的风格 有多种风格适合进程视图。例如管道和过滤器、客户服务器及其变体(多客户单服务器，多客户多服务器)等。2.2.2 进程视图的例子（ACS系统局部进程视图）28282022-12-12控 制 器 进 程慢 周 期 控制 器 任 务快 周 期 控制 器 任 务主 控 制器 任 务终 端 进 程（1）在图中，所有终端均由同一个终端进程进行处理，由其输入队列中的消息驱动。（2）控制器对象在组成控制器进程的3个任务之一中执行。29292022-12-12控 制 器 进 程慢 周 期 控制 器 任 务快 周 期 控制 器 任 务主 控 制器 任 务终 端 进 程（3）慢循环周期(20
19、0ms)任务扫描所有挂起的终端，把任何一个活动的终端置入快循环周期(10ms)任务的扫描列表。（4）快循环周期任务检测任何显著的状态改变，并把改变的状态传递给主控制器任务。30302022-12-12控 制 器 进 程慢 周 期 控制 器 任 务快 周 期 控制 器 任 务主 控 制器 任 务终 端 进 程（5）主控制器任务解释改变，通过消息与相应的终端进行通信。（6）通过共享内存来实现在控制器进程中传递的消息。31312022-12-12控 制 器 进 程慢 周 期 控制 器 任 务快 周 期 控制 器 任 务主 控 制器 任 务终 端 进 程2.2.3 开发视图：子系统分解 3232202
20、2-12-122.2.3 开发视图：子系统分解（3）开发视图要考虑软件内部的需求，如软件开发的容易性、软件的重用和软件的通用性，要充分考虑由于具体开发工具的不同而带来的局限性。33332022-12-122.2.3 开发视图的符号表示法 34342022-12-12构件参照相关性模块连接件子系统层2.2.3 开发视图的风格 35352022-12-122.2.3 开发视图的例子 36362022-12-12公用构件1低层服务支撑机制：通信、时间、储存、资源管理等2航空类、空中交通管制类3空中交通管制功能区：飞行管理、雷达管理等4人机接口外部系统5离线工具测试工具各种各样的空中交通管制系统特定的
21、空中交通管制系统构件空中交通管制系统框架分布式虚拟机基本元素硬件、操作系统、数据库领域特定领域无关通用空中交通管制代码客户定制2.2.3 开发视图的例子 37372022-12-12公用构件1低层服务支撑机制：通信、时间、储存、资源管理等2航空类、空中交通管制类3空中交通管制功能区：飞行管理、雷达管理等4人机接口外部系统5离线工具测试工具各种各样的空中交通管制系统特定的空中交通管制系统构件空中交通管制系统框架分布式虚拟机基本元素硬件、操作系统、数据库领域特定领域无关通用空中交通管制代码客户定制2.2.3 开发视图的例子 38382022-12-12公用构件1低层服务支撑机制：通信、时间、储存、
22、资源管理等2航空类、空中交通管制类3空中交通管制功能区：飞行管理、雷达管理等4人机接口外部系统5离线工具测试工具各种各样的空中交通管制系统特定的空中交通管制系统构件空中交通管制系统框架分布式虚拟机基本元素硬件、操作系统、数据库领域特定领域无关通用空中交通管制代码客户定制2.2.3 开发视图的例子 39392022-12-12公用构件1低层服务支撑机制：通信、时间、储存、资源管理等2航空类、空中交通管制类3空中交通管制功能区：飞行管理、雷达管理等4人机接口外部系统5离线工具测试工具各种各样的空中交通管制系统特定的空中交通管制系统构件空中交通管制系统框架分布式虚拟机基本元素硬件、操作系统、数据库领
23、域特定领域无关通用空中交通管制代码客户定制2.2.4 物理视图：从软件到硬件的映射 非功能性的需求。如：40402022-12-122.2.4 物理视图：从软件到硬件的映射 处理需要被映射至不同的节点我们希望使用不同的物理配置：一些用于开发和测试，另外一些则用于不同地点和不同客户的部署n 大型系统的物理视图可能会变得十分混乱，因此可以与进程视图的映射一起，以多种形式出现，也可单独出现。41412022-12-122.2.4 物理视图的符号表示法 42422022-12-12构件宽带或总线双向通信单向通信临时通信通信其他设备处理器连接件43432022-12-12 ACS系统的物理视图 C主KK
24、KKKKKKF备份F主F备份F主C备份2.2.4 物理视图的符号表示法物理视图的符号表示法 上图显示了大型专用自动交换机（上图显示了大型专用自动交换机（ACS）的一种可能的硬件配置。其中，）的一种可能的硬件配置。其中，C、F、K是是3个不同容量的计算机类型，支持个不同容量的计算机类型，支持3个不同的可执行文件。个不同的可执行文件。下面是进程视图的两个不同的物理映射，分别对应一个小下面是进程视图的两个不同的物理映射，分别对应一个小型的型的ACS和大型的和大型的ACS。具有进程分配的小型ACS系统的物理视图 K会话进程F终端进程控制器进程具有进程分配的大型ACS系统的物理视图 C中心进程备份节点伪
25、中心进程F会话进程终端进程伪中心进程F会话进程终端进程K控制器进程K控制器进程K控制器进程更多的K类处理器线路接口卡线路接口卡线路接口卡2.2.5 场景视图：汇总 45452022-12-122.2.5 场景视图的符号表示法 场景可以用文本表示，也可以用符号表示。场景视图的符号表示法中，构件的表示与逻辑视图非常相似，但是连接件的表示使用进程视图中的方法。注意，对象的实例用细实线表示。在工具的使用方面，和逻辑视图类似，可以使用Rational Rose绘制和管理对象场景图。46462022-12-12 47472022-12-122.2.5 场景视图的例子场景视图的例子 小王的电话的控制器检测到
26、并证实了从挂起到取下的小王的电话的控制器检测到并证实了从挂起到取下的状态转变，并且发送了消息来唤醒相关的终端对象。状态转变，并且发送了消息来唤醒相关的终端对象。终端分配一定的资源，并告诉控制器发出拨号音。终端分配一定的资源，并告诉控制器发出拨号音。控制器收到数字并将它们发送给终端。控制器收到数字并将它们发送给终端。终端使用编号计划来分析号码。终端使用编号计划来分析号码。当一个有效序列的输入完成，终端打开一个对话。当一个有效序列的输入完成，终端打开一个对话。图 场景的雏形本地呼叫选择阶段（1）摘机小王:控制器编号计划小王:终端小王:会话（2）拨号音（3）号码（4）号码（5）打开会话4848202
27、2-12-12 小结小结 逻辑视图和开发视图描述系统的静态结构，而进程逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。视图和物理视图描述系统的动态结构。对于不同的软件系统来说，侧重的角度也有所不同。对于不同的软件系统来说，侧重的角度也有所不同。例如，对于管理信息系统来说，比较侧重于从逻辑视图例如，对于管理信息系统来说，比较侧重于从逻辑视图和开发视图来描述系统，而对于实时控制系统来说，则和开发视图来描述系统，而对于实时控制系统来说，则比较注重于从进程视图和物理视图来描述系统。比较注重于从进程视图和物理视图来描述系统。案例分析：案例分析：NAS网络终端通讯服务系统网络
28、终端通讯服务系统 第第2章章 软件体系结构建模软件体系结构建模2.3“4+1”视图模型案例分析视图模型案例分析 49492022-12-12 需求描述：需求描述：NAS可运行于网络中任一台终端上，可为终端用户之间提供短信通信服务；可运行于网络中任一台终端上，可为终端用户之间提供短信通信服务；NAS在传输信息之前要求先进行加密处理，然后再以密文的形式发送；在传输信息之前要求先进行加密处理，然后再以密文的形式发送；NAS接收到传输的密文后，要求再以明文方式显示给终端用户；接收到传输的密文后，要求再以明文方式显示给终端用户；逻辑视图逻辑视图线框图表示法线框图表示法第第3章章 软件体系结构建模软件体系
29、结构建模3.3“4+1”视图模型案例分析视图模型案例分析 50502022-12-12 逻辑视图逻辑视图表示法表示法第第3章章 软件体系结构建模软件体系结构建模3.3“4+1”视图模型案例分析视图模型案例分析 51512022-12-12 逻辑视图逻辑视图UML表示的表示的NAS系统逻辑图系统逻辑图第第3章章 软件体系结构建模软件体系结构建模3.3“4+1”视图模型案例分析视图模型案例分析 52522022-12-12 逻辑视图逻辑视图UML表示的表示的NASNetService构构件的逻辑视图件的逻辑视图第第3章章 软件体系结构建模软件体系结构建模3.3“4+1”视图模型案例分析视图模型案例
30、分析 53532022-12-12 开发视图开发视图UML表示法表示法第第3章章 软件体系结构建模软件体系结构建模3.3“4+1”视图模型案例分析视图模型案例分析 54542022-12-12 开发视图开发视图UML表示法表示法第第3章章 软件体系结构建模软件体系结构建模3.3“4+1”视图模型案例分析视图模型案例分析 55552022-12-12 进程视图进程视图UML表示法表示法第第3章章 软件体系结构建模软件体系结构建模3.3“4+1”视图模型案例分析视图模型案例分析 56562022-12-12 物理视图物理视图UML表示法表示法第第2章章 软件体系结构建模软件体系结构建模2.3“4+
31、1”视图模型案例分析视图模型案例分析 57572022-12-12 2.6.3 视图间的交流 不同视图之间并不是互相独立或互相正交的。视图中的元素遵循一定的规则和经验法则与其他视图中的元素形成联系。1.从逻辑视图（最终用户）到进程视图（系统集成人员）n逻辑视图中认为每个对象都是主动的、并发的。n 定义进程体系结构时，将每个对象实现为独立的控制线程是不实际的（将导致巨大的开销）n 另一方面，多控制线程也是需要的 58582022-12-12在确定并发程度及过程数目时，必须以潜在的物理目标体系结构集合为前提，可以参照以下两种策略。n自内向外：从逻辑视图开始的策略n自外向内：从物理体系结构开始的策略
32、结果：类及其对象到进程体系结构的任务和过程集合的映射为达到可接受的设计结果，需要进行迭代 59592022-12-122.从逻辑视图（最终用户）到开发视图（编程人员）n一个类通常被实现为一个模块n较大的类被分解为多个包n一组相互联系紧密的类的集合，或称为类种属，构成子系统n定义子系统时，必须考虑附加约束n项目越大，逻辑视图和开发视图之间的距离越远2.从进程视图（系统集成人员）到物理视图（系统工程人员）n为了测试和部署，过程和过程组以各种配置映射到可用的物理硬件上。60602022-12-12n模型的迭代过程和软件过程1.迭代过程：场景驱动的方法 采用“4+1”模型进行软件体系结构设计的一种推荐
33、方法是：n在完成原型、测试、度量、分析等步骤后，重新进入下一轮这样的步骤，构成迭代的过程n系统最关键的功能以场景的形式得到。关键是指，功能上最重要，或是用频度上最高，又或存在必须克服的技术风险。初始的体系结构演化为最终的真实系统。在23次迭代后，体系结构本身有希望稳定下来。接下来就可以进行软件设计领域的工作了。61612022-12-122.软件文档体系结构设计阶段所形成的文档主要有：软件体系结构文档：基本按照4+1视图组织软件设计指导：描述为了维护系统的体系结构的一致性所必须遵守的重要设计决定。62622022-12-126363 综合软件体系结构的概念，体系结构的核心模型由综合软件体系结构
34、的概念，体系结构的核心模型由5中中元素组成：元素组成：构件构件 连接件连接件 配置配置 端口端口 角色角色其中，构件、连接件和配置是最基本的元素。其中，构件、连接件和配置是最基本的元素。2.3 体系结构的核心模型体系结构的核心模型 软件体系结构软件体系结构配置配置连接件连接件构件构件端口端口角色角色1:N1:N1:N1:N1:N1:N原子构件原子构件复合构件复合构件：表示软件之间的交互：表示软件之间的交互表示构件和连接件的表示构件和连接件的拓扑结构和约束：拓扑结构和约束：表示构件和外部环境表示构件和外部环境的交互点：的交互点：定义了该连接件表示的：定义了该连接件表示的 交互的参与者交互的参与者
35、2.3 体系结构的核心模型体系结构的核心模型 2.3 体系结构的核心模型体系结构的核心模型 软件体系结构配置连接件构件端口角色1:N1:N1:N65652022-12-12 软件体系结构的核心模型由五种元素组成：构软件体系结构的核心模型由五种元素组成：构件、连接件、配置、端口和角色。其中构件、件、连接件、配置、端口和角色。其中构件、连接件、配置是最基本的元素。连接件、配置是最基本的元素。构件构件是具有某种功能的可重用的软件模板单元，是具有某种功能的可重用的软件模板单元，表示了系统中主要的计算元素和数据存储。复表示了系统中主要的计算元素和数据存储。复合构件由其他复合构件和原子构件通过连接而合构件
36、由其他复合构件和原子构件通过连接而成。原子构件是不可再分的构件。构件只能通成。原子构件是不可再分的构件。构件只能通过其接口与外部环境交互，构件的接口由一组过其接口与外部环境交互，构件的接口由一组端口端口组成，每个端口表示了构件和外部环境的组成，每个端口表示了构件和外部环境的交互点。通过不同的端口类型，一个构件可以交互点。通过不同的端口类型，一个构件可以提供多重接口。提供多重接口。连接件连接件表示了构件间的交互。连接件也有接口，表示了构件间的交互。连接件也有接口，其接口由一组其接口由一组角色角色组成，连接件的每一个角色组成，连接件的每一个角色定义了该连接件表示的交互的参与者，二元连定义了该连接件
37、表示的交互的参与者，二元连接件有两个角色。接件有两个角色。配置配置表示了构件和连接件的拓扑逻辑和约束。表示了构件和连接件的拓扑逻辑和约束。需求分析需求分析 建立体系结构建立体系结构 测试测试 实现实现 设计设计 66662022-12-12 2.4 体系结构的生命周期模型体系结构的生命周期模型 软件开发过程软件开发过程2.4 体系结构的生命周期模型体系结构的生命周期模型 体系结构的非形式化描述体系结构的形式化基础（数学模型）体系结构的规范描述体系结构演化体系结构提供、评价和度量体系结构的终结体系结构实施体系结构求精的验证体系结构求精体系结构的性质分析需要演化或扩展否否是需要求精否是否67672
38、022-12-12 1.SA的非形式化的非形式化描述描述 一种一种SA在其产在其产生时，其思想生时，其思想通常是简单的，通常是简单的，并常常是由软并常常是由软件设计师用非件设计师用非形式化的自然形式化的自然语言表示概念、语言表示概念、原则。原则。2.4 体系结构的生命周期模型体系结构的生命周期模型 体系结构的非形式化描述体系结构的形式化基础（数学模型）体系结构的规范描述体系结构演化体系结构提供、评价和度量体系结构的终结体系结构实施体系结构求精的验证体系结构求精体系结构的性质分析需要演化或扩展否否是需要求精否是否68682022-12-12 2.SA的规范描述和的规范描述和分析分析该阶段通过运用
39、合该阶段通过运用合适的形式化数学理适的形式化数学理论模型对第论模型对第1阶段阶段的体系结构的非形的体系结构的非形式化描述进行规范式化描述进行规范定义，从而得到定义，从而得到SA的形式化规范描述，的形式化规范描述，以使以使SA的描述精确、的描述精确、无歧义；并进而分无歧义；并进而分析析SA的性质，如无的性质，如无死锁、安全性、活死锁、安全性、活性等。性等。2.4 体系结构的生命周期模型体系结构的生命周期模型 体系结构的非形式化描述体系结构的形式化基础（数学模型）体系结构的规范描述体系结构演化体系结构提供、评价和度量体系结构的终结体系结构实施体系结构求精的验证体系结构求精体系结构的性质分析需要演化
40、或扩展否否是需要求精否是否69692022-12-12 3.SA的求精及其验的求精及其验证证该阶段完成对已设该阶段完成对已设计好的计好的SA进行求证进行求证和求精。在每一步和求精。在每一步求精过程中，需要求精过程中，需要对不同抽象层次的对不同抽象层次的SA进行验证，以判进行验证，以判断较具体的断较具体的SA是否是否与较抽象的与较抽象的SA语义语义一致，并能实现抽一致，并能实现抽象的象的SA。2.4 体系结构的生命周期模型体系结构的生命周期模型 体系结构的非形式化描述体系结构的形式化基础（数学模型）体系结构的规范描述体系结构演化体系结构提供、评价和度量体系结构的终结体系结构实施体系结构求精的验证
41、体系结构求精体系结构的性质分析需要演化或扩展否否是需要求精否是否70702022-12-12 4.SA的实施的实施该阶段将求精后的该阶段将求精后的SA实施于系统的实施于系统的设计中，并将设计中，并将SA的构件和连接件等的构件和连接件等有机的组织在一起，有机的组织在一起，形成系统设计框架，形成系统设计框架，以便实施于软件设以便实施于软件设计和构造中。计和构造中。2.4 体系结构的生命周期模型体系结构的生命周期模型 体系结构的非形式化描述体系结构的形式化基础（数学模型）体系结构的规范描述体系结构演化体系结构提供、评价和度量体系结构的终结体系结构实施体系结构求精的验证体系结构求精体系结构的性质分析需
42、要演化或扩展否否是需要求精否是否71712022-12-12 5.SA的演化和扩的演化和扩展展由于对由于对SA的演化的演化常由非功能性质的常由非功能性质的非形式化需求描述非形式化需求描述引起，因而需要重引起，因而需要重复第复第1步，如果由步，如果由于功能和非功能性于功能和非功能性质对以前的质对以前的SA进进行演化，就要涉及行演化，就要涉及SA的理解，需要的理解，需要进行进行SA的逆向工的逆向工程和再造工程。程和再造工程。2.4 体系结构的生命周期模型体系结构的生命周期模型 体系结构的非形式化描述体系结构的形式化基础（数学模型）体系结构的规范描述体系结构演化体系结构提供、评价和度量体系结构的终结
43、体系结构实施体系结构求精的验证体系结构求精体系结构的性质分析需要演化或扩展否否是需要求精否是否72722022-12-12 6.SA的提供、评价的提供、评价和度量和度量该阶段通过将该阶段通过将SA实实施于系统设计后，施于系统设计后，系统实际运行情况，系统实际运行情况，对对SA进行定性评价进行定性评价和度量，以利于和度量，以利于SA的重用，并取得经的重用，并取得经验教训。验教训。2.4 体系结构的生命周期模型体系结构的生命周期模型 体系结构的非形式化描述体系结构的形式化基础（数学模型）体系结构的规范描述体系结构演化体系结构提供、评价和度量体系结构的终结体系结构实施体系结构求精的验证体系结构求精体
44、系结构的性质分析需要演化或扩展否否是需要求精否是否73732022-12-12 7.SA终结终结如果一个软件系统如果一个软件系统的的SA进行多次演化进行多次演化和修改，和修改，SA变得难变得难以理解，更重要的以理解，更重要的是不能达到系统设是不能达到系统设计的要求，不能适计的要求，不能适应系统的发展。这应系统的发展。这时应该摒弃，以全时应该摒弃，以全新的满足系统设计新的满足系统设计要求的要求的SA取而代之。取而代之。2.5软件体系结构抽象模型软件体系结构抽象模型 使用抽象代数理论，对构件、连接件和软件体系结使用抽象代数理论，对构件、连接件和软件体系结构的定义以及它们的属性和动态行为进行讨论，建
45、立软构的定义以及它们的属性和动态行为进行讨论，建立软件体系结构的数学理论体系，讨论不同类型软件体系结件体系结构的数学理论体系，讨论不同类型软件体系结构的相互关系给出软件体系结构范式的方法。构的相互关系给出软件体系结构范式的方法。74742022-12-12 本章作业与思考题本章作业与思考题 1、选择一个规模合适的系统，为其建立、选择一个规模合适的系统，为其建立“4+1”模型。模型。3、引入了软件体系结构以后，传统软件过程发生了哪、引入了软件体系结构以后，传统软件过程发生了哪些变化？这种变化有什么好处？些变化？这种变化有什么好处？3、软件体系结构的生命周期模型与软件生命周期模型、软件体系结构的生命周期模型与软件生命周期模型有什么关系？有什么关系？75752022-12-12
