第7讲-软件体系结构设计课件

软件体系结构设计软件体系结构设计教材教材P175 第第7章章先思考几个问题？先思考几个问题？软件设计的基本原则？（软件设计的基本原则？（回顾回顾）内聚与耦合的区别？（内聚与耦合的区别？（回顾回顾）软件设计的过程模型？（软件设计的过程模型？（回顾回顾）2024/7/122阅读书的第七章回答下列问题？阅读书的第七章回答下列问题？什么是体系结构？什么是体系结构？体系结构视图分为？体系结构视图分为？体系结构常用哪几种体系结构常用哪几种UMLUML图形图形机制表示？机制表示？1010分钟分钟2024/7/123第七章第七章 软件体系结构设计软件体系结构设计7.1 软件体系件体系结构的概念构的概念7.2 体系体系结构的表示构的表示 包包图、构件、构件图、部署、部署图、对象象图7.3 体系体系结构构设计的的过程程7.4 体系体系结构构设计模式模式7.5 概念概念设计7.6 体系体系结构精化构精化7.7 基于构件的体系基于构件的体系结构构7.8 体系体系结构构验证2024/7/124第七章第七章 软件体系结构设计软件体系结构设计软件体系结构的定义：软件体系结构的定义：软件软件体系结构体系结构（architecturearchitecture，也称，也称“架构架构”）从高层抽象的角度刻画组成目标软件系统的从高层抽象的角度刻画组成目标软件系统的设计设计元素元素（包括子系统、构件及类）以及它们之间的（包括子系统、构件及类）以及它们之间的逻辑关联。逻辑关联。2024/7/1252024/7/126软件体系结构设计软件体系结构设计体系结构设计的任务：体系结构设计的任务：建立满足软件需求的建立满足软件需求的软件体系结构。软件体系结构。u体系结构既要明确定义软件各子系统、构件、体系结构既要明确定义软件各子系统、构件、关键类的关键类的职责划分及协作关系职责划分及协作关系，也要描绘它们，也要描绘它们在物理运行环境下的在物理运行环境下的部署模型部署模型；u体系结构还必须针对软件系统全局性、基础性体系结构还必须针对软件系统全局性、基础性的技术问题给出技术解决方案，这种方案构成的技术问题给出技术解决方案，这种方案构成目标软件系统的目标软件系统的技术基础设施技术基础设施。2024/7/1272024/7/128可信计算终端系统平台安全体系结构可信计算终端系统平台安全体系结构软件体系结构设计软件体系结构设计体系结构的重要性：体系结构的重要性：u今天软件日益庞大复杂、交付时间日益紧迫、今天软件日益庞大复杂、交付时间日益紧迫、详细设计和软件实现技术日益成熟，详细设计和软件实现技术日益成熟，体系结构体系结构设计已经成为软件质量的瓶颈。设计已经成为软件质量的瓶颈。u与详细设计相比，体系结构设计对性能、灵活与详细设计相比，体系结构设计对性能、灵活性、可修改性、可扩充性等质量需求的影响是性、可修改性、可扩充性等质量需求的影响是全局性的、决定性的全局性的、决定性的。u一旦启动基于体系结构的详细设计，对体系结一旦启动基于体系结构的详细设计，对体系结构进行调优的代价将远大于算法调优的代价。构进行调优的代价将远大于算法调优的代价。2024/7/129软件体系结构设计软件体系结构设计本章试图本章试图回答的问题回答的问题对对系统进行模块划分时，怎样划分才合理？系统进行模块划分时，怎样划分才合理？在大型软件项目中，需求如此之多，如何基于需在大型软件项目中，需求如此之多，如何基于需求推导体系结构，如何确保体系结构满足软件需求推导体系结构，如何确保体系结构满足软件需求，尤其是非功能需求？求，尤其是非功能需求？是否存在指导软件体系结构设计的过程及方法学是否存在指导软件体系结构设计的过程及方法学？2024/7/12107.1 7.1 软件体系结构的概念软件体系结构的概念本节介绍：本节介绍：什么是软件体系结构什么是软件体系结构体系结构与需求体系结构与需求体系结构设计与详细设计的关系体系结构设计与详细设计的关系从多种视角探讨软件体系结构的不同表现形式从多种视角探讨软件体系结构的不同表现形式2024/7/12117.1.1 7.1.1 何谓体系结构何谓体系结构软件体系结构包括三大要素：软件体系结构包括三大要素：u 组件组件(component)(component)u 连接件连接件(connector)(connector)u 约束约束(constraints)(constraints)连接件表示组件之间的连接和交互关系连接件表示组件之间的连接和交互关系约束表示组件中的元素应满足的条件，以及组件经由连接约束表示组件中的元素应满足的条件，以及组件经由连接件组装成更大模块时应满足的条件。件组装成更大模块时应满足的条件。2024/7/1212图图7.12 7.12 家庭保安系统的体系结构雏形家庭保安系统的体系结构雏形2024/7/1213举例：举例：家庭保安系统家庭保安系统软件软件组件：组件：u如如，图图7.127.12所示的体系结构将家庭保安系统软件划所示的体系结构将家庭保安系统软件划分为界面、核心和物理设备接口三个层次分为界面、核心和物理设备接口三个层次u核心层负责存储所有业务数据并提供业务逻辑处理核心层负责存储所有业务数据并提供业务逻辑处理功能功能u界面层负责向用户呈现家庭保安系统的操作界面，界面层负责向用户呈现家庭保安系统的操作界面，接收用户的界面输入并将其转换为内部事件传递给接收用户的界面输入并将其转换为内部事件传递给核心层核心层。u物理设备接口层应核心层的要求向传感器、报警器、物理设备接口层应核心层的要求向传感器、报警器、报警电话等物理设备发送必要的控制指令，也负责报警电话等物理设备发送必要的控制指令，也负责接收来自传感器的监测数据。接收来自传感器的监测数据。2024/7/1214何谓体系结构何谓体系结构图图7.127.12所示的软件体系结构涉及的所示的软件体系结构涉及的约束约束：（1 1）位于较高层次的软件元素可以向低层元素发出）位于较高层次的软件元素可以向低层元素发出服务请求，低层元素完成计算后向高层元素发送服务请求，低层元素完成计算后向高层元素发送服务应答，反之不行；服务应答，反之不行；（2 2）每个软件元素根据其）每个软件元素根据其职责职责位于最恰当的一个层位于最恰当的一个层次当中，不可错置（如，核心层不能包含界面呈次当中，不可错置（如，核心层不能包含界面呈现和界面输入接收职责，也不能直接与物理设备现和界面输入接收职责，也不能直接与物理设备交互）；交互）；（3 3）每个层次都可替换，即，一个层次可以被能实）每个层次都可替换，即，一个层次可以被能实现同样现同样对外服务接口对外服务接口的层次所替代。的层次所替代。2024/7/1215体系结构体系结构与软件需求的与软件需求的关系：关系：u体系结构体系结构是以软件需求的实现为目标的软件设是以软件需求的实现为目标的软件设计蓝图，计蓝图，软件需求是体系结构设计的基础和驱软件需求是体系结构设计的基础和驱动因素。动因素。u软件需求，尤其是非功能需求，对软件体系结软件需求，尤其是非功能需求，对软件体系结构具有关键性的塑形作用构具有关键性的塑形作用。体系结构设计与详细设计的体系结构设计与详细设计的关系：关系：u详细设计是针对软件体系结构中某个详细设计是针对软件体系结构中某个未展开模块的未展开模块的局部设计局部设计，必须遵循体系结构中规定的原则、接口，必须遵循体系结构中规定的原则、接口及约束及约束u详细设计详细设计只能实现、不能更改体系结构中规定的模只能实现、不能更改体系结构中规定的模块的对外接口和外部行为块的对外接口和外部行为；u软件体系结构必须为详细设计提供软件体系结构必须为详细设计提供可操作的指可操作的指导和充分的约束导和充分的约束。2024/7/12167.1.2 7.1.2 体系结构视图体系结构视图完整完整的软件体系结构应该包含以下的软件体系结构应该包含以下视图：视图：逻辑视图：逻辑视图：体系结构中各软件模块的逻辑功体系结构中各软件模块的逻辑功能划分（或曰职责分派），以及基于这种能划分（或曰职责分派），以及基于这种划分的协作行为。逻辑视图的示例见划分的协作行为。逻辑视图的示例见图图7.127.12。开发视图：开发视图：软件源代码的程序分包及目录结软件源代码的程序分包及目录结构，采用的类库、中间构，采用的类库、中间件或件或框架框架(framework(framework)，它们与逻辑视图中各模块之它们与逻辑视图中各模块之间的映射关系。开发视图的示例见间的映射关系。开发视图的示例见图图7.197.19。2024/7/1217体系结构视图体系结构视图物理视图：物理视图：安装部署的物理机器及其网络连接，安装部署的物理机器及其网络连接，逻辑视图及开发视图中逻辑视图及开发视图中模块或程序包的物理部模块或程序包的物理部署位置署位置。物理视图的示例见。物理视图的示例见图图7.207.20。运行视图：运行视图：软件运行时进程、线程的划分，它软件运行时进程、线程的划分，它们之间的并发与同步，瞬时快照们之间的并发与同步，瞬时快照软件运行软件运行过程中某个特定时刻活跃的对象及其协作关系过程中某个特定时刻活跃的对象及其协作关系，以及它们与逻辑视图和开发视图之间的映射关以及它们与逻辑视图和开发视图之间的映射关系。系。数据视图：数据视图：持久数据的存储方案，数据传递、持久数据的存储方案，数据传递、备份、恢复、同步方案，与物理视图之间的映备份、恢复、同步方案，与物理视图之间的映射关系。射关系。2024/7/12187.2 7.2 体系结构的表示体系结构的表示用于表示体系结构的逻辑视图的用于表示体系结构的逻辑视图的UMLUML图形机图形机制主要是包图和构件图，有时还辅以类图；制主要是包图和构件图，有时还辅以类图；u开发视图开发视图的表示可能会用到的表示可能会用到包图包图；u物理视图物理视图显然应表示为显然应表示为部署图部署图；u因为因为运行视图运行视图涉及到并发、同步以及软件运行涉及到并发、同步以及软件运行过程中的瞬时快照，所以它应表示为过程中的瞬时快照，所以它应表示为活动图活动图与与对象图对象图；u数据视图数据视图一般表示为一般表示为类图类图或者或者实体实体-关系图关系图，2024/7/12197.2.1 7.2.1 包图包图包图包图刻画包之间的构成和依赖关系。刻画包之间的构成和依赖关系。u包是包是UMLUML模型的一种组织单元，它可以包含一组具有逻模型的一种组织单元，它可以包含一组具有逻辑关联的辑关联的UMLUML模型元素（例如用例、类等）、模型图模型元素（例如用例、类等）、模型图（例如用例图、类图、交互图、状态图、活动图等），（例如用例图、类图、交互图、状态图、活动图等），以及其他的包。以及其他的包。u包在模型管理过程中是包在模型管理过程中是配置管理配置管理的基本单元，同时也的基本单元，同时也为为访问控制访问控制提供基本手段。提供基本手段。2024/7/1220包图包图包图的作用：包图的作用：在在整个软件开发过程整个软件开发过程中，包图用于以结构化、中，包图用于以结构化、层次化的方式组织、管理大型的软件模型，层次化的方式组织、管理大型的软件模型，使得分别处理不同包的开发团队之间的相使得分别处理不同包的开发团队之间的相互干扰程度降至最低互干扰程度降至最低；u在在业务分析和需求定义阶段业务分析和需求定义阶段，包图可用于刻画，包图可用于刻画业务系统和用户需求的结构；业务系统和用户需求的结构；u在设计和实现阶段在设计和实现阶段，包图可用于描述软件系统，包图可用于描述软件系统的高层结构。的高层结构。2024/7/1221图图7.17.1 包包图图示示例例2024/7/1222（一）（一）包及包间依赖包及包间依赖可以从四种不同角度来理解包的概念：可以从四种不同角度来理解包的概念：作为软件模型的组织单元。作为软件模型的组织单元。对于一个大型的软件系统，对于一个大型的软件系统，前述每一种前述每一种UMLUML模型图都可能非常庞大、复杂。此时，模型图都可能非常庞大、复杂。此时，就有必要将系统划分成不同的包，在每个包中构建各类就有必要将系统划分成不同的包，在每个包中构建各类模型图。模型图。作为模型管理的基本单元。作为模型管理的基本单元。只要包的分划合理，就可只要包的分划合理，就可以以包为单位分派软件开发任务、安排计划。与此同时，以以包为单位分派软件开发任务、安排计划。与此同时，在配置管理（包括版本控制）活动中，包是天然的基本在配置管理（包括版本控制）活动中，包是天然的基本处理单元。处理单元。作为系统高层结构中的组成元素作为系统高层结构中的组成元素。类类图适于展示面向图适于展示面向对象软件系统的静态结构。但是，对于大型系统而言，对象软件系统的静态结构。但是，对于大型系统而言，类的粒度太小，类图过于细节化，难以宏观地展现系统类的粒度太小，类图过于细节化，难以宏观地展现系统的高层结构。因此，对于大型软件而言，可以逐级细分的高层结构。因此，对于大型软件而言，可以逐级细分的包才是软件高层结构中恰当的组成元素。这一结论可的包才是软件高层结构中恰当的组成元素。这一结论可延伸至大型业务系统和软件需求的顶层结构描述。延伸至大型业务系统和软件需求的顶层结构描述。2024/7/1223包及包间依赖包及包间依赖作为访问控制的基本手段作为访问控制的基本手段。可以将包视为名字空间，其中的每个模型元素可可以将包视为名字空间，其中的每个模型元素可以通过在其（简单）名称之前拼接包名，构成全以通过在其（简单）名称之前拼接包名，构成全系统范围内的唯一的限定名（系统范围内的唯一的限定名（qualified namequalified name）来指称它，正如在文件系统中以文件的全路径名来指称它，正如在文件系统中以文件的全路径名来唯一地指称一个文件。来唯一地指称一个文件。如，包如，包p1p1的子包的子包p11p11中的类中的类class1class1的限定名的限定名为为p1.p11.class1p1.p11.class1。2024/7/1224UMLUML中以中以包为包为基准的可见性基准的可见性规则：规则：包中可见性定义为包中可见性定义为publicpublic的元素可以在模型的元素可以在模型的任何地方被引用；的任何地方被引用；包中可见性定义为包中可见性定义为privateprivate的元素仅在该元素的元素仅在该元素所在的（最内层）包中可见，其他地方不能所在的（最内层）包中可见，其他地方不能引用引用。2024/7/1225（二）（二）包图包图包之间的两种关系：包之间的两种关系：构成和依赖构成和依赖。u构成关系构成关系用父包图元直接包含子包图元的方式用父包图元直接包含子包图元的方式来表示。来表示。u依赖关系依赖关系的图元与类间依赖关系相同，见的图元与类间依赖关系相同，见图图7.17.1。如果包图的每个包中仅包含类，则称此种包如果包图的每个包中仅包含类，则称此种包图为图为类包图类包图；如果包图的每个包中仅包含用例，则称此种如果包图的每个包中仅包含用例，则称此种包图为包图为用例包图用例包图。2024/7/12267.2.2 7.2.2 构件图构件图构件的定义：构件的定义：构件是可执行软件系统中的某个可分离的物理模块，构件是可执行软件系统中的某个可分离的物理模块，它具有精确定义的对外接口，并且外界只能通过接它具有精确定义的对外接口，并且外界只能通过接口来访问它。口来访问它。2024/7/12272024/7/1228构件的特点：构件的特点：构件是构件是可分离的可分离的，它通常表现为一个或数个可独立，它通常表现为一个或数个可独立部署的执行码文件；部署的执行码文件；构件是构件是可替换的可替换的，嵌于运行系统中的构件实例能够，嵌于运行系统中的构件实例能够被其他任何实现了相同接口的另一构件实例所替换；被其他任何实现了相同接口的另一构件实例所替换；构件是构件是可配置的可配置的，在构件在部署至运行环境之后，在构件在部署至运行环境之后，外界仍然可以通过规范化的配置机制修改构件的配外界仍然可以通过规范化的配置机制修改构件的配置数据，进而影响（或称置数据，进而影响（或称“定制定制”）构件的对外服）构件的对外服务的功能或行为。务的功能或行为。构件一般具有较好的构件一般具有较好的可复用可复用潜力，构件可不经源代潜力，构件可不经源代码修改，也不需要重新编译，即可应用于多个软件码修改，也不需要重新编译，即可应用于多个软件项目或软件产品，这部分地归因于构件可通过配置项目或软件产品，这部分地归因于构件可通过配置信息的调整来适应不同的应用场景，同时也归因于信息的调整来适应不同的应用场景，同时也归因于构件在创立之初即考虑了不同应用场景下的可复用构件在创立之初即考虑了不同应用场景下的可复用性。性。2024/7/1229图图7.27.2是表示某个软件系统中主要构件之间是表示某个软件系统中主要构件之间关系的构件图关系的构件图图图7.37.3是其中是其中“Customer”“Customer”构件的内部结构构件的内部结构图。图。2024/7/1230图图7.2 7.2 构件图示例构件图示例 图图7.3 7.3 构件定义图示构件定义图示例例2024/7/1231（一）（一）构件及其表示构件及其表示接口：接口：是一组操作是一组操作 和和/或或 属性的说明（不属性的说明（不含操作的实现），它用作服务提供方和使含操作的实现），它用作服务提供方和使用方之间的协议。接口由类或构件实现。用方之间的协议。接口由类或构件实现。构件最关键的特征是它构件最关键的特征是它对外提供的对外提供的供给接口供给接口（provided interfaceprovided interface），以及它请求其），以及它请求其他类、构件或软件模块提供帮助时他类、构件或软件模块提供帮助时使用的使用的需求接口需求接口（required interfacerequired interface）。）。2024/7/1232构件及其表示构件及其表示构件与接口的关系：构件与接口的关系：构件的实现与接口是分离的，也是隐藏的，构件的实现与接口是分离的，也是隐藏的，即，即，构件的实现者可以自由选择实现方法，只要它完构件的实现者可以自由选择实现方法，只要它完整地实现了供给接口中规定的操作及属性即可，整地实现了供给接口中规定的操作及属性即可，并且它对其他软件模块的访问必须通过需求接口并且它对其他软件模块的访问必须通过需求接口来进行来进行。构件构件的使用者只需要了解其供给接口，构件的服的使用者只需要了解其供给接口，构件的服务提供者只需要了解其需求接口，决不需要了解务提供者只需要了解其需求接口，决不需要了解构件的内部实现。构件的内部实现。只要构件的两种实现遵循相同的接口定义，那么只要构件的两种实现遵循相同的接口定义，那么它们就一定是可自由替换的。它们就一定是可自由替换的。构件的表示图元仅示出构件的名字和接口。构件的表示图元仅示出构件的名字和接口。2024/7/1233构件及其表示构件及其表示端口（端口（portport）：）：针对每个构件还可以定义一些端针对每个构件还可以定义一些端口，每个端口绑定了一组供给接口和口，每个端口绑定了一组供给接口和/或需求接口。或需求接口。u对于具有端口的构件，它通过端口与外部世界交互。对于具有端口的构件，它通过端口与外部世界交互。当外部请求到达端口时，构件的端口知道如何将外部当外部请求到达端口时，构件的端口知道如何将外部请求路由至合适的接口的实现体；请求路由至合适的接口的实现体；u当构件通过端口请求外部服务时，端口也知道如何分当构件通过端口请求外部服务时，端口也知道如何分辨该请求所对应的需求接口。辨该请求所对应的需求接口。针对构件的每个接口和端口，可以通过自然语言针对构件的每个接口和端口，可以通过自然语言描述、用例图或状态图来定义其使用方法。描述、用例图或状态图来定义其使用方法。2024/7/1234图图7.4 7.4 构件的表示图元构件的表示图元（a a）最简化的三种图元）最简化的三种图元 （隐藏接口部（隐藏接口部分）分）（b b）构件及其接口的两种表示方法）构件及其接口的两种表示方法2024/7/1235（c）构件端口的表示方法（二）构件图（二）构件图构件图的结点：构件图的结点：构件、类和包。构件、类和包。构件图的边构件图的边与普通类图的边没有严格区分与普通类图的边没有严格区分构件图的关系：构件图的关系：构件、类和包之间的构件、类和包之间的依赖关系依赖关系，偶尔也可以出现偶尔也可以出现继承关系继承关系和和实现关系实现关系。u两个构件间的依赖关系可以直接搭建于这两个构件两个构件间的依赖关系可以直接搭建于这两个构件之间，也可以搭建于一个构件与另一构件的供给接之间，也可以搭建于一个构件与另一构件的供给接口之间，还可以描述成一个构件的需求接口与另一口之间，还可以描述成一个构件的需求接口与另一构件的供给接口之间的依赖关系，见构件的供给接口之间的依赖关系，见图图7.7.2 2。2024/7/1236（三）（三）构件定义图构件定义图构件构件定义图定义图描述一个构件的内部结构。它可以描述一个构件的内部结构。它可以包含多个子构件，每个子构件的需求接口要么包含多个子构件，每个子构件的需求接口要么由另一子构件的供给接口负责实现，要么经由由另一子构件的供给接口负责实现，要么经由父构件的需求接口请求外部支援，这样才能构父构件的需求接口请求外部支援，这样才能构成父构件的完整实现成父构件的完整实现。见。见图图7.37.3在构件定义图中，一个子构件的供给接口对另在构件定义图中，一个子构件的供给接口对另一子构件的需求接口的实现通过两种图元之间一子构件的需求接口的实现通过两种图元之间的衔接来表示。的衔接来表示。子构件端口与父构件端口之间的有向边称为子构件端口与父构件端口之间的有向边称为委委托连接器托连接器（delegation connectordelegation connector）。2024/7/12377.2.3 7.2.3 部署图部署图部署图部署图表示软件系统的表示软件系统的可执行工件可执行工件（artifactartifact）在运行环境中的分布情况在运行环境中的分布情况。u工件工件是指软件系统中相对独立的物理实现单元，例如是指软件系统中相对独立的物理实现单元，例如WindowsWindows平台下的动态链接库（平台下的动态链接库（DLLDLL）文件、）文件、JavaJava系统系统中的类库（中的类库（jarjar）文件）文件。部署部署图的作用：图的作用：u在在分布计算环境中，部署图为软件配置管理工程师确分布计算环境中，部署图为软件配置管理工程师确定软件发布版本的封包方法提供依据，同时也是软件定软件发布版本的封包方法提供依据，同时也是软件安装、维护工程师了解系统部署状况的主要信息源安装、维护工程师了解系统部署状况的主要信息源。u软件软件设计、实现人员理解软件运行环境、确定软构件设计、实现人员理解软件运行环境、确定软构件划分的重要参考。划分的重要参考。2024/7/1238部署图部署图两种部署图：两种部署图：逻辑层面的逻辑层面的描述性部署图描述性部署图（见图见图7.57.5），物理层面的），物理层面的实例性部署图实例性部署图（见（见图图7.67.6）。）。u描述性部署图描述性部署图描述软件的逻辑布局描述软件的逻辑布局u实例性部署图实例性部署图在描述性部署图的基础上针对具在描述性部署图的基础上针对具体的运行环境和特定的系统配置描述软件系统体的运行环境和特定的系统配置描述软件系统的物理部署情况。的物理部署情况。2024/7/1239举例举例如机票预订管理系统，设计人员可使用如机票预订管理系统，设计人员可使用描述性描述性部署图部署图展现待发布的软件系统有哪些工件，各展现待发布的软件系统有哪些工件，各工件在网络环境中计算结点的分布，结点之间工件在网络环境中计算结点的分布，结点之间的通信连接，工件间的依赖关系等。的通信连接，工件间的依赖关系等。假设该软件系统在三家机票预订服务商投入应假设该软件系统在三家机票预订服务商投入应用，那么可以使用三张用，那么可以使用三张实例性部署图实例性部署图分别展示分别展示它在不同服务商的具体网络环境下不同的部署它在不同服务商的具体网络环境下不同的部署情况。情况。有可能某个工件部署在一家服务商的应用服务有可能某个工件部署在一家服务商的应用服务器上，但另一服务商购买的软件版本中却无此器上，但另一服务商购买的软件版本中却无此工件。工件。各工件的配置信息随使用需求和环境的变化有各工件的配置信息随使用需求和环境的变化有所差异。所差异。2024/7/1240图图7.5 7.5 描述性部署图示例描述性部署图示例2024/7/1241图图7.6 7.6 实例性部署图示例实例性部署图示例2024/7/1242（一）（一）描述性部署图描述性部署图描述性部署图的四类结点：描述性部署图的四类结点：结点结点 表示软件运行环境中的一组计算资源表示软件运行环境中的一组计算资源 如，客户端计算机、如，客户端计算机、WebWeb服务器、应用服务器、数据库服服务器、应用服务器、数据库服务器等务器等 软件工件驻留其中，依赖基础服务实现工件的功能。软件工件驻留其中，依赖基础服务实现工件的功能。如，如，图图7.57.5中驻留在中驻留在WebWeb服务器上的工件依靠服务器提供的服务器上的工件依靠服务器提供的HTTPHTTP请求和应答处理能力实现与请求和应答处理能力实现与WebWeb客户端的交互功能客户端的交互功能工件工件 以构造型以构造型标识。标识。工件位于结点图元之内，表示该工件部署于相应结点。工件位于结点图元之内，表示该工件部署于相应结点。2024/7/1243描述性部署图描述性部署图构件构件 位于结点内的构件表示该构件部署于相应结点位于结点内的构件表示该构件部署于相应结点 位于结点外的构件用来指明工件与构件之间的依赖关位于结点外的构件用来指明工件与构件之间的依赖关系。系。不需要将所有的构件引入至部署图，仅显示相关的、不需要将所有的构件引入至部署图，仅显示相关的、重要的构件即可。重要的构件即可。与用例有关的执行者与用例有关的执行者 在部署图中引入执行者意在强调执行者与部署于结点在部署图中引入执行者意在强调执行者与部署于结点中的工件之间的使用关系及信息交互。中的工件之间的使用关系及信息交互。2024/7/1244描述性部署图描述性部署图描述性部署图的四种边：描述性部署图的四种边：结点之间的通信关联结点之间的通信关联 表示两个结点间的通信连接表示两个结点间的通信连接 可以在通信关联边上以构造型说明通信协议及其他约束，可以在通信关联边上以构造型说明通信协议及其他约束，还可以标注结点之间的数量对应关系还可以标注结点之间的数量对应关系 如，如，WebWeb服务器通过服务器通过HTTPHTTP协议与客户端相连，一台协议与客户端相连，一台WebWeb服务服务器可对应多台客户端器可对应多台客户端工件之间的依赖关系工件之间的依赖关系 与类之间的依赖关系的含义类似。与类之间的依赖关系的含义类似。如果工件定义了对外接口，那么软件设计人员应确保工如果工件定义了对外接口，那么软件设计人员应确保工件之间的依赖关系表现为工件接口上的依赖关系，如此可件之间的依赖关系表现为工件接口上的依赖关系，如此可降低工件之间的耦合度降低工件之间的耦合度2024/7/1245描述性部署图描述性部署图工件与构件之间的依赖关系工件与构件之间的依赖关系 表示工件具体实现了构件。表示工件具体实现了构件。在该依赖关系之上需标注构造型在该依赖关系之上需标注构造型。用例执行者与工件之间的依赖关系用例执行者与工件之间的依赖关系 表示执行者使用工件提供的服务（依赖关系从执行者指表示执行者使用工件提供的服务（依赖关系从执行者指向工件），或工件使用执行者提供的服务（依赖关系从工向工件），或工件使用执行者提供的服务（依赖关系从工件指向执行者）。件指向执行者）。l在描述性部署图中对各类依赖关系的建模切忌贪多求全，在描述性部署图中对各类依赖关系的建模切忌贪多求全，仅标示重要的依赖关系。仅标示重要的依赖关系。2024/7/1246（二）（二）实例性部署图实例性部署图实例性部署图与描述性部署图之间的关系可实例性部署图与描述性部署图之间的关系可类比为对象图类比为对象图与类图之间的关系与类图之间的关系。实例性部署图实例性部署图的结点和边分别视为描述性部署图中结点和的结点和边分别视为描述性部署图中结点和边的边的实例实例。在实例性部署图中结点的命名方式为在实例性部署图中结点的命名方式为 “结点名结点名:类型名类型名”其中类型名为描述性部署图中的结点名。其中类型名为描述性部署图中的结点名。如果实例性部署图中的结点包含了描述性部署相应结点中如果实例性部署图中的结点包含了描述性部署相应结点中的所有工件，则不必在该结点中再列举这些工件。的所有工件，则不必在该结点中再列举这些工件。实例性部署图的结点还可实例性部署图的结点还可包含对工件的具体配置信息包含对工件的具体配置信息的描的描述，见述，见图图7.67.6中的结点中的结点“customerDeploy.xml”“customerDeploy.xml”。2024/7/12477.2.4 7.2.4 对象图对象图对象象图是是软件系件系统中某些中某些对象在运行象在运行过程中的瞬程中的瞬时快照快照结点表示点表示对象，象，边表示表示对象之象之间的的链接，接，见图7.7。图图7.7 7.7 对象图示例对象图示例2024/7/1248对象图对象图对象图对象图是是类类图图在软件系统的运行过程中某个时刻点在软件系统的运行过程中某个时刻点上或某一时间段内的上或某一时间段内的实例化样本实例化样本。u类图中的一个类在对象图中可以表现为多个活跃的对类图中的一个类在对象图中可以表现为多个活跃的对象实例，也可以没有任何对象与之对应（因为此类的象实例，也可以没有任何对象与之对应（因为此类的对象当前尚不存在）。对象当前尚不存在）。u对象图的链接边是类图中关联边的实例化，而类图中对象图的链接边是类图中关联边的实例化，而类图中的其他边，如继承、依赖等在对象图中则无从表现。的其他边，如继承、依赖等在对象图中则无从表现。u与类图不同，对象图不能定义软件系统（或子系统）与类图不同，对象图不能定义软件系统（或子系统）的结构或行为，它只是采用场景例化的方式解释类图的结构或行为，它只是采用场景例化的方式解释类图隐含的一种可能。隐含的一种可能。u虽然对象图表现了软件系统运行时的一种场景，但由虽然对象图表现了软件系统运行时的一种场景，但由于它是一种静态的瞬时快照，不像交互图、状态图、于它是一种静态的瞬时快照，不像交互图、状态图、活动图那样可以表示软件系统（或其子部分）随时间活动图那样可以表示软件系统（或其子部分）随时间而演化的动作过程，所以而演化的动作过程，所以对象图仍被归于静态视图的对象图仍被归于静态视图的范畴范畴。2024/7/12497.37.3体系结构设计的过程模型体系结构设计的过程模型如何如何展开软件体系结构的设计工作展开软件体系结构的设计工作？2024/7/1250体系结构设计的过程模型体系结构设计的过程模型将将体系结构的设计过程划分为两个阶段：体系结构的设计过程划分为两个阶段：初初步设计和体系结构精化步设计和体系结构精化。u在在前一阶段，体系结构设计师仅需针对软件需前一阶段，体系结构设计师仅需针对软件需求模型中的部分关键需求项来构思体系结构的求模型中的部分关键需求项来构思体系结构的雏形。雏形。u在在后一阶段全面地考虑所有的软件需求项、丰后一阶段全面地考虑所有的软件需求项、丰富体系结构雏形的细节并且对其进行调优。富体系结构雏形的细节并且对其进行调优。关键需求项关键需求项是指对用户满意度及软件结构均是指对用户满意度及软件结构均有重要影响的需求项有重要影响的需求项。“20-8020-80规则规则”：20%20%的关键需求项决定的关键需求项决定80%80%的体系结构形态。的体系结构形态。2024/7/1251体系结构设计的过程模型体系结构设计的过程模型本书推荐的体系结构设计过程的主要活动如下：本书推荐的体系结构设计过程的主要活动如下：概念设计概念设计 在深入理解业务领域和软件需求模型的基础上辨识关键需在深入理解业务领域和软件需求模型的基础上辨识关键需求，研究采用何种体系结构雏形才能以合理的、充分优化求，研究采用何种体系结构雏形才能以合理的、充分优化的方式实现这些关键需求。的方式实现这些关键需求。体系结构精化体系结构精化 对体系结构的概念雏形进行精化，分别从逻辑视图、开发对体系结构的概念雏形进行精化，分别从逻辑视图、开发视图、运行视图、物理视图、数据视图等多种视角设计软视图、运行视图、物理视图、数据视图等多种视角设计软件的体系结构。件的体系结构。在软件项目中，究竟选取哪些体系结构视图取决于项目的在软件项目中，究竟选取哪些体系结构视图取决于项目的需要，但是逻辑视图对所有项目都是必需的。需要，但是逻辑视图对所有项目都是必需的。体系结构的精化过程也是需求导向的：应考虑如何才能以体系结构的精化过程也是需求导向的：应考虑如何才能以合理的、充分优化的方式完整地实现软件需求模型？合理的、充分优化的方式完整地实现软件需求模型？2024/7/1252体系结构设计的过程模型体系结构设计的过程模型体系结构验证体系结构验证 基于精化后的软件体系结构，重新审视所有软件基于精化后的软件体系结构，重新审视所有软件需求项的实现方案，研究如何化解迄今标识出来需求项的实现方案，研究如何化解迄今标识出来的所有重要的全局风险，在此过程中验证体系结的所有重要的全局风险，在此过程中验证体系结构的合理性和充分优化性。构的合理性和充分优化性。这些活动可按序组织为体系结构设计工作流，见这些活动可按序组织为体系结构设计工作流，见图图7.87.8。2024/7/1253体系结构设计的过程模型体系结构设计的过程模型 图图7.8 7.8 体系结构设计体系结构设计工作流工作流与需求工程的与需求工程的过程模型程模型类似，大中型似，大中型软件系件系统的体系的体系结构构设计过程同程同样采用采用迭代方式迭代方式。两种迭代方式：两种迭代方式：u 针对体系体系结构构验证过程程发现的的问题返工至概念返工至概念设计或精化或精化阶段段；u 分分别针对不同的需求不同的需求项依次依次进行概念行概念设计、体系、体系结构精化构精化和和验证，然后，然后进行体系行体系结构的集成。构的集成。后一种迭代方式必后一种迭代方式必须确保重要的需求确保重要的需求项优先。先。2024/7/12547.4 7.4 体系结构设计模式体系结构设计模式7.4.1 7.4.1 何谓设计模式何谓设计模式设计模式设计模式：以设计复用为目的，采用一种良好定以设计复用为目的，采用一种良好定义的、正规的、一致的方式记录的软件设计经验。义的、正规的、一致的方式记录的软件设计经验。每条模式关注在一般或特定设计环境中可能重复每条模式关注在一般或特定设计环境中可能重复出现的设计问题，并给出经过充分实践考验的软出现的设计问题，并给出经过充分实践考验的软件解决方案。件解决方案。2024/7/1255体系结构设计模式体系结构设计模式一种设计模式包含以下内容：一种设计模式包含以下内容：设计模式的名称。设计模式的名称。名称应能概观地反映模式蕴含的设计经验，并尽量名称应能概观地反映模式蕴含的设计经验，并尽量体现它与业界广泛采用的已有模式之间的关系。体现它与业界广泛采用的已有模式之间的关系。问题。问题。描述模式解决的设计问题，包括问题的背景。描述模式解决的设计问题，包括问题的背景。施用条件。施用条件。描述在何种条件下才推荐使用该模式解决上述问题，描述在何种条件下才推荐使用该模式解决上述问题，以及在使用本模式之前必须考虑的约束条件。以及在使用本模式之前必须考虑的约束条件。解决方案。解决方案。这是设计模式的主体部分，描述问题的软件解决方这是设计模式的主体部分，描述问题的软件解决方案。案。2024/7/1256体系结构设计模式体系结构设计模式效果。效果。描述上述解决方案导致的正面及负面的设计效果。描述上述解决方案导致的正面及负面的设计效果。示例代码。示例代码。以特定的程序设计语言或类程序设计语言给出应以特定的程序设计语言或类程序设计语言给出应用本模式的示例代码。用本模式的示例代码。关联模式。关联模式。说明本模式继承或扩展了哪些模式，与哪些模式说明本模式继承或扩展了哪些模式，与哪些模式关联。关联。2024/7/1257针对具体的设计模式的描述可视情况适当针对具体的设计模式的描述可视情况适当取舍，但取舍，但名称、解决方案名称、解决方案和和效果效果是不可或是不可或缺的。缺的。体系结构设计模式体系结构设计模式设计模式的分类视角：设计模式的分类视角：从模式提供的从模式提供的解决方案的抽象程度解决方案的抽象程度看，模式自看，模式自高至低可依次划分为：高至低可依次划分为：体系结构设计模式：体系结构设计模式：面向整个软件系统或面向整个软件系统或规规模较大的软件子系统模较大的软件子系统，给出抽象程度较高的结，给出抽象程度较高的结构化组织方式。构化组织方式。2024/7/1258它提供一些预定义的子系统或构件，它提供一些预定义的子系统或构件，规定其职责，描述它们之间相互关系、规定其职责，描述它们之间相互关系、协作方式的规则或指南。协作方式的规则或指南。体系结构设计模式体系结构设计模式软件子系统或构件设计模式：软件子系统或构件设计模式：u面向面向中等规模中等规模的软件子系统或构件，以独立于程序的软件子系统或构件，以独立于程序设计语言的方式，给出内部的软件元素（粒度更小、设计语言的方式，给出内部的软件元素（粒度更小、抽象级别更低的子系统或构件）的结构化组织方式。抽象级别更低的子系统或构件）的结构化组织方式。u如果此类设计模式采用面向对象方式给出解决方案，如果此类设计模式采用面向对象方式给出解决方案，那么，方案中的软件元素往往是类，解决方案除规那么，方案中的软件元素往往是类，解决方案除规定每个类的职责外，还会以定每个类的职责外，还会以UMLUML类图表示类之间的类图表示类之间的关系，以关系，以UMLUML交互图表示类之间的协作途径。交互图表示类之间的协作途径。面向软件实现的设计模式：面向软件实现的设计模式：u针对针对软件子系统或构件中的某个特定问题软件子系统或构件中的某个特定问题，描述如，描述如何利用特定的程序设计语言的具体特征来解决此问何利用特定的程序设计语言的具体特征来解决此问题。题。u此类模式不影响软件结构。此类模式不影响软件结构。2024/7/1259体系结构设计模式体系结构设计模式（2 2）从模式）从模式解决的设计问题解决的设计问题的类别看，模式可划分为：的类别看，模式可划分为：创建型模式（工厂方法模式、生成器模式）创建型模式（工厂方法模式、生成器模式）专门解决复杂对象的创建问题。专门解决复杂对象的创建问题。结构型模式（结构型模式（adpteradpter适配器模式、适配器模式、BridgeBridge桥接模式）桥接模式）将软件系统、子系统或构件分解为粒度更小的软件元将软件系统、子系统或构件分解为粒度更小的软件元素，规定其职责和协作方式。素，规定其职责和协作方式。行为型模式（行为型模式（InterpreterInterpreter解释器、解释器、IteratorIterator迭代）迭代）不仅描述软件系统、子系统或构件的内部结构，更强不仅描述软件系统、子系统或构件的内部结构，更强调位于结构中的软件元素在协同解决问题时的通信及调位于结构中的软件元素在协同解决问题时的通信及控制流模式。控制流模式。2024/7/1260体系结构设计模式体系结构设计模式分布型模式（客户机分布型模式（客户机/服务器构架）服务器构架）为构件分布于网络中不同计算机的软件系统提供为构件分布于网络中不同计算机的软件系统提供系统结构和远程互操作方法。系统结构和远程互操作方法。适应性模式（微核模式）适应性模式（微核模式）专门针对软件系统、子系统或构件的扩展、改进、专门针对软件系统、子系统或构件的扩展、改进、演进、变更等设计问题提供软件解决方案。演进、变更等设计问题提供软件解决方案。访问控制模式（访问控制模式（MVCMVC）专门针对构件、软件服务或共享资源的访问控制专门针对构件、软件服务或共享资源的访问控制问题提供软件解决方案。问题提供软件解决方案。2024/7/1261体系结构设计模式体系结构设计模式（3 3）按照模式）按照模式基于的计算平台基于的计算平台类别可划分为：类别可划分为：独立于计算平台的设计模式。独立于计算平台的设计模式。面向特定计算平台（如面向特定计算平台（如J2EEJ2EE、.NET.NET等）的设计等）的设计模式模式设计模式的意义和价值设计模式的意义和价值：以标准并且规范的方式以标准并且规范的方式记录软件设计经验，支持软件设计级复用。记录软件设计经验，支持软件设计级复用。2024/7/12627.4.2 7.4.2 通用的体系结构模式通用的体系结构模式体系结构模式是专门针对体系结构设计问题的设体系结构模式是专门针对体系结构设计问题的设计模式，是软件体系结构设计的经验结晶。计模式，是软件体系结构设计的经验结晶。本节内容：本节内容：u分层模式分层模式u管道与过滤器模式管道与过滤器模式u黑板模式黑板模式2024/7/1263（一）分层模式（一）分层模式该模式将软件系统按照抽象级别逐次递增或该模式将软件系统按照抽象级别逐次递增或递减的顺序划分为若干层次，每层由一些递减的顺序划分为若干层次，每层由一些抽象级别相同的构件组成，见抽象级别相同的构件组成，见图图7.97.9。u在在严格的分层体系结构中严格的分层体系结构中，每层的构件仅为，每层的构件仅为紧邻其上紧邻其上的抽象级别更高的层次提供服务，并且它们仅使用紧的抽象级别更高的层次提供服务，并且它们仅使用紧邻下层提供的服务；邻下层提供的服务；u在在稍松散的分层体系结构中稍松散的分层体系结构中，服务提供者和接受者，服务提供者和接受者可可以跨越中间层以跨越中间层，但前者一定位于比后者更高的抽象层，但前者一定位于比后者更高的抽象层次。次。u一般而言，顶层直接面向用户提供软件系统的交互界一般而言，顶层直接面向用户提供软件系统的交互界面，底层则负责提供基础性、公共性的技术服务，它面，底层则负责提供基础性、公共性的技术服务，它比较接近于硬件计算环境、操作系统或数据库管理系比较接近于硬件计算环境、操作系统或数据库管理系统，中间层的抽象级别介乎二者之间。统，中间层的抽象级别介乎二者之间。2024/7/1264图图7.9 7.9 分层体系结构模式示意图分层体系结构模式示意图2024/7/1265（一）分层模式（一）分层模式层次之间的连接有两种形态：层次之间的连接有两种形态：高层构件向低层构件高层构件向低层构件发出服务请求，低层构件在发出服务请求，低层构件在计算完成后向请求者发送服务应答。计算完成后向请求者发送服务应答。在此过程中，在此过程中，低层构件可能向更低层构件发送抽象级别更低、低层构件可能向更低层构件发送抽象级别更低、粒度更细的服务请求。粒度更细的服务请求。低层构件在主动探测或被动获知低层构件在主动探测或被动获知计算环境的变化计算环境的变化事件后通知高层构件，事件后通知高层构件，这种通知链可能一直延伸这种通知链可能一直延伸到最高层以便软件系统向用户报告，也可能中止到最高层以便软件系统向用户报告，也可能中止于某个中间层次。于某个中间层次。2024/7/1266分层模式分层模式每个层次对上层服务接口的两种组织方式每个层次对上层服务接口的两种组织方式 层次中的每个提供服务的构件公开其接口层次中的每个提供服务的构件公开其接口 将这些接口封装于层次的内部，每个层次提供统将这些接口封装于层次的内部，每个层次提供统一的、整合的服务接口一的、整合的服务接口前一种方式对上层服务请求者更直接，服务提供前一种方式对上层服务请求者更直接，服务提供者所在层次的透明度也较高者所在层次的透明度也较高后一种方式降低了两个层次之间的耦合度。后一种方式降低了两个层次之间的耦合度。G合理地确立一系列抽象级别是采用分层模式进行合理地确立一系列抽象级别是采用分层模式进行体系结构设计的关键。体系结构设计的关键。2024/7/1267分层模式分层模式分层体系结构模式具有以下正面效应：分层体系结构模式具有以下正面效应：松耦合松耦合 通过软件层次的划分和层间接口的规整有效降低通过软件层次的划分和层间接口的规整有效降低整个软件系统的耦合度，强化软件系统各构件之整个软件系统的耦合度，强化软件系统各构件之间依赖关系的局部化程度。间依赖关系的局部化程度。可替换性可替换性 一个层次可以被实现了同样的对外服务接口的层一个层次可以被实现了同样的对外服务接口的层次所替换；次所替换；接口变化给层次替换带来的影响仅限于直接使用接口变化给层次替换带来的影响仅限于直接使用该层服务的上层构件。该层服务的上层构件。2024/7/1268分层模式分层模式可复用性可复用性 具有良好定义的抽象级别和对外服务接口的层次具有良好定义的抽象级别和对外服务接口的层次可以在不同的上下文环境中实现复用。可以在不同的上下文环境中实现复用。标准化标准化 定义清晰、广为接受的抽象级别可促进标准化构定义清晰、广为接受的抽象级别可促进标准化构件和标准化接口的开发件和标准化接口的开发 如，如，ISOISO七层网络协议模型、七层网络协议模型、POSIXPOSIX接口标准、接口标准、Java Java虚拟机（虚拟机（JVMJVM）标准）标准 在各自领域的标准化进程中发挥了关键性作用。在各自领域的标准化进程中发挥了关键性作用。2024/7/1269分层模式分层模式分层体系结构在性能开销方面的负面效应：分层体系结构在性能开销方面的负面效应：高层功能可能需要逐层调用下层服务，返回值、高层功能可能需要逐层调用下层服务，返回值、报错信息又需逐级上传，这种过程一般会比直接报错信息又需逐级上传，这种过程一般会比直接实现高层功能更耗时。实现高层功能更耗时。如果低层服务还完成了最初的服务请求者所不如果低层服务还完成了最初的服务请求者所不需要的冗余功能，那么性能损耗就会更严重。需要的冗余功能，那么性能损耗就会更严重。2024/7/1270（二）管道与过滤器模式（二）管道与过滤器模式管道与过滤器模式将软件系统的功能实现为一管道与过滤器模式将软件系统的功能实现为一系列处理步骤，每个步骤封装在一个过滤器构系列处理步骤，每个步骤封装在一个过滤器构件中，见件中，见图图7.107.10。u相邻过滤器之间以管道连接，一个过滤器的输出数相邻过滤器之间以管道连接，一个过滤器的输出数据借助管道流向后续过滤器，作为其输入数据。据借助管道流向后续过滤器，作为其输入数据。u整个软件系统的输入由数据源（整个软件系统的输入由数据源（data sourcedata source）提）提供，它通过管道与过滤器相连。供，它通过管道与过滤器相连。u软件系统的最终输出由源自某个过滤器的管道流向软件系统的最终输出由源自某个过滤器的管道流向数据汇（数据汇（data sinkdata sink）。）。u典型的数据源和数据汇包括数据库、文件、其他软典型的数据源和数据汇包括数据库、文件、其他软件系统、物理设备等。件系统、物理设备等。u一个软件系统可以有多个数据源、多个数据汇。一个软件系统可以有多个数据源、多个数据汇。2024/7/1271图图7.10 7.10 管道与过滤器模式示意图管道与过滤器模式示意图2024/7/1272管道与过滤器模式管道与过滤器模式过滤器、数据源、数据汇与管道之间的协作方式有过滤器、数据源、数据汇与管道之间的协作方式有以下几种：以下几种：过滤器以循环方式工作，不断从管道中提取输过滤器以循环方式工作，不断从管道中提取输入数据，并将输出数据压入管道。入数据，并将输出数据压入管道。此种过滤器称为此种过滤器称为主动过滤器主动过滤器。管道将输入数据压入位于其目标端的过滤器，管道将输入数据压入位于其目标端的过滤器，过滤器被动地等待输入数据。过滤器被动地等待输入数据。管道负责提取位