软件体系结构设计

先思考几个问题？软件设计的基本原则？（回顾）内聚与耦合的区别？（回顾）软件设计的过程模型？（回顾）2026/4/261阅读书的第七章回答下列问题？什么是体系结构？体系结构视图分为？体系结构常用哪几种UML图形机制表示？10分钟2026/4/262第七章软件体系结构设计

7.1软件体系结构的概念

7.2体系结构的表示

包图、构件图、部署图、对象图

7.3体系结构设计的过程7.4体系结构设计模式

7.5概念设计7.6体系结构精化7.7基于构件的体系结构7.8体系结构验证2026/4/263第七章软件体系结构设计

软件体系结构的定义：软件体系结构（architecture，也称“架构”）从高层抽象的角度刻画组成目标软件系统的设计元素（包括子系统、构件及类）以及它们之间的逻辑关联。2026/4/2642026/4/265软件体系结构设计体系结构设计的任务：建立满足软件需求的软件体系结构。体系结构既要明确定义软件各子系统、构件、关键类的职责划分及协作关系，也要描绘它们在物理运行环境下的部署模型；体系结构还必须针对软件系统全局性、基础性的技术问题给出技术解决方案，这种方案构成目标软件系统的技术基础设施。2026/4/2662026/4/267可信计算终端系统平台安全体系结构软件体系结构设计体系结构的重要性：今天软件日益庞大复杂、交付时间日益紧迫、详细设计和软件实现技术日益成熟，体系结构设计已经成为软件质量的瓶颈。与详细设计相比，体系结构设计对性能、灵活性、可修改性、可扩充性等质量需求的影响是全局性的、决定性的。一旦启动基于体系结构的详细设计，对体系结构进行调优的代价将远大于算法调优的代价。2026/4/268软件体系结构设计本章试图回答的问题对系统进行模块划分时，怎样划分才合理？在大型软件项目中，需求如此之多，如何基于需求推导体系结构，如何确保体系结构满足软件需求，尤其是非功能需求？是否存在指导软件体系结构设计的过程及方法学？2026/4/2697.1软件体系结构的概念本节介绍：什么是软件体系结构体系结构与需求体系结构设计与详细设计的关系从多种视角探讨软件体系结构的不同表现形式2026/4/26107.1.1何谓体系结构软件体系结构包括三大要素：

组件(component)

连接件(connector)

约束(constraints)连接件表示组件之间的连接和交互关系约束表示组件中的元素应满足的条件，以及组件经由连接件组装成更大模块时应满足的条件。2026/4/2611图7.12家庭保安系统的体系结构雏形2026/4/2612举例：家庭保安系统软件组件：如，图7.12所示的体系结构将家庭保安系统软件划分为界面、核心和物理设备接口三个层次核心层负责存储所有业务数据并提供业务逻辑处理功能界面层负责向用户呈现家庭保安系统的操作界面，接收用户的界面输入并将其转换为内部事件传递给核心层。物理设备接口层应核心层的要求向传感器、报警器、报警电话等物理设备发送必要的控制指令，也负责接收来自传感器的监测数据。2026/4/2613何谓体系结构图7.12所示的软件体系结构涉及的约束：（1）位于较高层次的软件元素可以向低层元素发出服务请求，低层元素完成计算后向高层元素发送服务应答，反之不行；（2）每个软件元素根据其职责位于最恰当的一个层次当中，不可错置（如，核心层不能包含界面呈现和界面输入接收职责，也不能直接与物理设备交互）；（3）每个层次都可替换，即，一个层次可以被能实现同样对外服务接口的层次所替代。2026/4/2614体系结构与软件需求的关系：体系结构是以软件需求的实现为目标的软件设计蓝图，软件需求是体系结构设计的基础和驱动因素。软件需求，尤其是非功能需求，对软件体系结构具有关键性的塑形作用。体系结构设计与详细设计的关系：详细设计是针对软件体系结构中某个未展开模块的局部设计，必须遵循体系结构中规定的原则、接口及约束详细设计只能实现、不能更改体系结构中规定的模块的对外接口和外部行为；软件体系结构必须为详细设计提供可操作的指导和充分的约束。2026/4/26157.1.2体系结构视图完整的软件体系结构应该包含以下视图：逻辑视图：体系结构中各软件模块的逻辑功能划分（或曰职责分派），以及基于这种划分的协作行为。逻辑视图的示例见图7.12。开发视图：软件源代码的程序分包及目录结构，采用的类库、中间件或框架(framework)，它们与逻辑视图中各模块之间的映射关系。开发视图的示例见图7.19。2026/4/2616体系结构视图物理视图：安装部署的物理机器及其网络连接，逻辑视图及开发视图中模块或程序包的物理部署位置。物理视图的示例见图7.20。运行视图：软件运行时进程、线程的划分，它们之间的并发与同步，瞬时快照——软件运行过程中某个特定时刻活跃的对象及其协作关系，以及它们与逻辑视图和开发视图之间的映射关系。数据视图：持久数据的存储方案，数据传递、备份、恢复、同步方案，与物理视图之间的映射关系。2026/4/26177.2体系结构的表示用于表示体系结构的逻辑视图的UML图形机制主要是包图和构件图，有时还辅以类图；开发视图的表示可能会用到包图；物理视图显然应表示为部署图；因为运行视图涉及到并发、同步以及软件运行过程中的瞬时快照，所以它应表示为活动图与对象图；数据视图一般表示为类图或者实体-关系图，2026/4/26187.2.1包图包图刻画包之间的构成和依赖关系。包是UML模型的一种组织单元，它可以包含一组具有逻辑关联的UML模型元素（例如用例、类等）、模型图（例如用例图、类图、交互图、状态图、活动图等），以及其他的包。包在模型管理过程中是配置管理的基本单元，同时也为访问控制提供基本手段。2026/4/2619包图包图的作用：在整个软件开发过程中，包图用于以结构化、层次化的方式组织、管理大型的软件模型，使得分别处理不同包的开发团队之间的相互干扰程度降至最低；在业务分析和需求定义阶段，包图可用于刻画业务系统和用户需求的结构；在设计和实现阶段，包图可用于描述软件系统的高层结构。2026/4/2620图7.1

包图示例2026/4/2621（一）包及包间依赖可以从四种不同角度来理解包的概念：⑴作为软件模型的组织单元。对于一个大型的软件系统，前述每一种UML模型图都可能非常庞大、复杂。此时，就有必要将系统划分成不同的包，在每个包中构建各类模型图。⑵作为模型管理的基本单元。只要包的分划合理，就可以以包为单位分派软件开发任务、安排计划。与此同时，在配置管理（包括版本控制）活动中，包是天然的基本处理单元。⑶作为系统高层结构中的组成元素。类图适于展示面向对象软件系统的静态结构。但是，对于大型系统而言，类的粒度太小，类图过于细节化，难以宏观地展现系统的高层结构。因此，对于大型软件而言，可以逐级细分的包才是软件高层结构中恰当的组成元素。这一结论可延伸至大型业务系统和软件需求的顶层结构描述。2026/4/2622包及包间依赖⑷作为访问控制的基本手段。可以将包视为名字空间，其中的每个模型元素可以通过在其（简单）名称之前拼接包名，构成全系统范围内的唯一的限定名（qualifiedname）来指称它，正如在文件系统中以文件的全路径名来唯一地指称一个文件。如，包p1的子包p11中的类class1的限定名为p1.p11.class1。2026/4/2623UML中以包为基准的可见性规则：包中可见性定义为public的元素可以在模型的任何地方被引用；包中可见性定义为private的元素仅在该元素所在的（最内层）包中可见，其他地方不能引用。2026/4/2624（二）包图包之间的两种关系：构成和依赖。构成关系用父包图元直接包含子包图元的方式来表示。依赖关系的图元与类间依赖关系相同，见图7.1。如果包图的每个包中仅包含类，则称此种包图为类包图；如果包图的每个包中仅包含用例，则称此种包图为用例包图。2026/4/26257.2.2构件图构件的定义：构件是可执行软件系统中的某个可分离的物理模块，它具有精确定义的对外接口，并且外界只能通过接口来访问它。2026/4/26262026/4/2627构件的特点：构件是可分离的，它通常表现为一个或数个可独立部署的执行码文件；构件是可替换的，嵌于运行系统中的构件实例能够被其他任何实现了相同接口的另一构件实例所替换；构件是可配置的，在构件在部署至运行环境之后，外界仍然可以通过规范化的配置机制修改构件的配置数据，进而影响（或称“定制”）构件的对外服务的功能或行为。构件一般具有较好的可复用潜力，构件可不经源代码修改，也不需要重新编译，即可应用于多个软件项目或软件产品，这部分地归因于构件可通过配置信息的调整来适应不同的应用场景，同时也归因于构件在创立之初即考虑了不同应用场景下的可复用性。2026/4/2628图7.2是表示某个软件系统中主要构件之间关系的构件图图7.3是其中“Customer”构件的内部结构图。2026/4/2629图7.2构件图示例图7.3构件定义图示例2026/4/2630（一）构件及其表示接口：是一组操作和/或属性的说明（不含操作的实现），它用作服务提供方和使用方之间的协议。接口由类或构件实现。构件最关键的特征是它对外提供的供给接口（providedinterface），以及它请求其他类、构件或软件模块提供帮助时使用的需求接口（requiredinterface）。2026/4/2631构件及其表示构件与接口的关系：构件的实现与接口是分离的，也是隐藏的，即，构件的实现者可以自由选择实现方法，只要它完整地实现了供给接口中规定的操作及属性即可，并且它对其他软件模块的访问必须通过需求接口来进行。构件的使用者只需要了解其供给接口，构件的服务提供者只需要了解其需求接口，决不需要了解构件的内部实现。只要构件的两种实现遵循相同的接口定义，那么它们就一定是可自由替换的。构件的表示图元仅示出构件的名字和接口。2026/4/2632构件及其表示端口（port）：针对每个构件还可以定义一些端口，每个端口绑定了一组供给接口和/或需求接口。对于具有端口的构件，它通过端口与外部世界交互。当外部请求到达端口时，构件的端口知道如何将外部请求路由至合适的接口的实现体；当构件通过端口请求外部服务时，端口也知道如何分辨该请求所对应的需求接口。针对构件的每个接口和端口，可以通过自然语言描述、用例图或状态图来定义其使用方法。2026/4/2633图7.4构件的表示图元（a）最简化的三种图元

（隐藏接口部分）（b）构件及其接口的两种表示方法2026/4/2634（c）构件端口的表示方法（二）构件图构件图的结点：构件、类和包。构件图的边与普通类图的边没有严格区分构件图的关系：构件、类和包之间的依赖关系，偶尔也可以出现继承关系和实现关系。两个构件间的依赖关系可以直接搭建于这两个构件之间，也可以搭建于一个构件与另一构件的供给接口之间，还可以描述成一个构件的需求接口与另一构件的供给接口之间的依赖关系，见图7.2。2026/4/2635（三）构件定义图构件定义图描述一个构件的内部结构。它可以包含多个子构件，每个子构件的需求接口要么由另一子构件的供给接口负责实现，要么经由父构件的需求接口请求外部支援，这样才能构成父构件的完整实现。见图7.3在构件定义图中，一个子构件的供给接口对另一子构件的需求接口的实现通过两种图元之间的衔接来表示。子构件端口与父构件端口之间的有向边称为委托连接器（delegationconnector）。2026/4/26367.2.3部署图部署图表示软件系统的可执行工件（artifact）在运行环境中的分布情况。工件是指软件系统中相对独立的物理实现单元，例如Windows平台下的动态链接库（DLL）文件、Java系统中的类库（jar）文件。部署图的作用：在分布计算环境中，部署图为软件配置管理工程师确定软件发布版本的封包方法提供依据，同时也是软件安装、维护工程师了解系统部署状况的主要信息源。软件设计、实现人员理解软件运行环境、确定软构件划分的重要参考。2026/4/2637部署图两种部署图：逻辑层面的描述性部署图（见图7.5），物理层面的实例性部署图（见图7.6）。描述性部署图描述软件的逻辑布局实例性部署图在描述性部署图的基础上针对具体的运行环境和特定的系统配置描述软件系统的物理部署情况。2026/4/2638举例如机票预订管理系统，设计人员可使用描述性部署图展现待发布的软件系统有哪些工件，各工件在网络环境中计算结点的分布，结点之间的通信连接，工件间的依赖关系等。假设该软件系统在三家机票预订服务商投入应用，那么可以使用三张实例性部署图分别展示它在不同服务商的具体网络环境下不同的部署情况。有可能某个工件部署在一家服务商的应用服务器上，但另一服务商购买的软件版本中却无此工件。各工件的配置信息随使用需求和环境的变化有所差异。2026/4/2639图7.5

描述性部署图示例2026/4/2640图7.6

实例性部署图示例2026/4/2641（一）描述性部署图描述性部署图的四类结点：⑴结点表示软件运行环境中的一组计算资源如，客户端计算机、Web服务器、应用服务器、数据库服务器等软件工件驻留其中，依赖基础服务实现工件的功能。

如，图7.5中驻留在Web服务器上的工件依靠服务器提供的HTTP请求和应答处理能力实现与Web客户端的交互功能⑵工件以构造型<<artifact>>标识。

工件位于结点图元之内，表示该工件部署于相应结点。2026/4/2642描述性部署图⑶构件位于结点内的构件表示该构件部署于相应结点位于结点外的构件用来指明工件与构件之间的依赖关系。不需要将所有的构件引入至部署图，仅显示相关的、重要的构件即可。⑷与用例有关的执行者在部署图中引入执行者意在强调执行者与部署于结点中的工件之间的使用关系及信息交互。2026/4/2643描述性部署图描述性部署图的四种边：⑴结点之间的通信关联表示两个结点间的通信连接

可以在通信关联边上以构造型说明通信协议及其他约束，还可以标注结点之间的数量对应关系如，Web服务器通过HTTP协议与客户端相连，一台Web服务器可对应多台客户端⑵工件之间的依赖关系与类之间的依赖关系的含义类似。

如果工件定义了对外接口，那么软件设计人员应确保工件之间的依赖关系表现为工件接口上的依赖关系，如此可降低工件之间的耦合度2026/4/2644描述性部署图⑶工件与构件之间的依赖关系表示工件具体实现了构件。

在该依赖关系之上需标注构造型<<manifest>>。⑷用例执行者与工件之间的依赖关系表示执行者使用工件提供的服务（依赖关系从执行者指向工件），或工件使用执行者提供的服务（依赖关系从工件指向执行者）。在描述性部署图中对各类依赖关系的建模切忌贪多求全，仅标示重要的依赖关系。2026/4/2645（二）实例性部署图实例性部署图与描述性部署图之间的关系可类比为对象图与类图之间的关系。实例性部署图的结点和边分别视为描述性部署图中结点和边的实例。在实例性部署图中结点的命名方式为“结点名:类型名”其中类型名为描述性部署图中的结点名。如果实例性部署图中的结点包含了描述性部署相应结点中的所有工件，则不必在该结点中再列举这些工件。实例性部署图的结点还可包含对工件的具体配置信息的描述，见图7.6中的结点“customerDeploy.xml”。2026/4/26467.2.4对象图对象图是软件系统中某些对象在运行过程中的瞬时快照结点表示对象，边表示对象之间的链接，见图7.7。图7.7对象图示例2026/4/2647对象图对象图是类图在软件系统的运行过程中某个时刻点上或某一时间段内的实例化样本。类图中的一个类在对象图中可以表现为多个活跃的对象实例，也可以没有任何对象与之对应（因为此类的对象当前尚不存在）。对象图的链接边是类图中关联边的实例化，而类图中的其他边，如继承、依赖等在对象图中则无从表现。与类图不同，对象图不能定义软件系统（或子系统）的结构或行为，它只是采用场景例化的方式解释类图隐含的一种可能。虽然对象图表现了软件系统运行时的一种场景，但由于它是一种静态的瞬时快照，不像交互图、状态图、活动图那样可以表示软件系统（或其子部分）随时间而演化的动作过程，所以对象图仍被归于静态视图的范畴。2026/4/26487.3体系结构设计的过程模型如何展开软件体系结构的设计工作？2026/4/2649体系结构设计的过程模型将体系结构的设计过程划分为两个阶段：初步设计和体系结构精化。在前一阶段，体系结构设计师仅需针对软件需求模型中的部分关键需求项来构思体系结构的雏形。在后一阶段全面地考虑所有的软件需求项、丰富体系结构雏形的细节并且对其进行调优。关键需求项是指对用户满意度及软件结构均有重要影响的需求项。

“20-80规则”：20%的关键需求项决定80%的体系结构形态。2026/4/2650体系结构设计的过程模型本书推荐的体系结构设计过程的主要活动如下：⑴概念设计在深入理解业务领域和软件需求模型的基础上辨识关键需求，研究采用何种体系结构雏形才能以合理的、充分优化的方式实现这些关键需求。⑵体系结构精化对体系结构的概念雏形进行精化，分别从逻辑视图、开发视图、运行视图、物理视图、数据视图等多种视角设计软件的体系结构。

在软件项目中，究竟选取哪些体系结构视图取决于项目的需要，但是逻辑视图对所有项目都是必需的。体系结构的精化过程也是需求导向的：应考虑如何才能以合理的、充分优化的方式完整地实现软件需求模型？2026/4/2651体系结构设计的过程模型⑶体系结构验证基于精化后的软件体系结构，重新审视所有软件需求项的实现方案，研究如何化解迄今标识出来的所有重要的全局风险，在此过程中验证体系结构的合理性和充分优化性。这些活动可按序组织为体系结构设计工作流，见图7.8。2026/4/2652体系结构设计的过程模型图7.8体系结构设计工作流与需求工程的过程模型类似，大中型软件系统的体系结构设计过程同样采用迭代方式。两种迭代方式：

针对体系结构验证过程发现的问题返工至概念设计或精化阶段；

分别针对不同的需求项依次进行概念设计、体系结构精化和验证，然后进行体系结构的集成。后一种迭代方式必须确保重要的需求项优先。2026/4/26537.4体系结构设计模式7.4.1何谓设计模式设计模式：以设计复用为目的，采用一种良好定义的、正规的、一致的方式记录的软件设计经验。每条模式关注在一般或特定设计环境中可能重复出现的设计问题，并给出经过充分实践考验的软件解决方案。2026/4/2654体系结构设计模式一种设计模式包含以下内容：⑴设计模式的名称。

名称应能概观地反映模式蕴含的设计经验，并尽量体现它与业界广泛采用的已有模式之间的关系。⑵问题。

描述模式解决的设计问题，包括问题的背景。⑶施用条件。

描述在何种条件下才推荐使用该模式解决上述问题，以及在使用本模式之前必须考虑的约束条件。⑷解决方案。

这是设计模式的主体部分，描述问题的软件解决方案。2026/4/2655体系结构设计模式⑸效果。

描述上述解决方案导致的正面及负面的设计效果。⑹示例代码。

以特定的程序设计语言或类程序设计语言给出应用本模式的示例代码。⑺关联模式。

说明本模式继承或扩展了哪些模式，与哪些模式关联。2026/4/2656针对具体的设计模式的描述可视情况适当取舍，但名称、解决方案和效果是不可或缺的。体系结构设计模式

设计模式的分类视角：⑴从模式提供的解决方案的抽象程度看，模式自高至低可依次划分为：①体系结构设计模式：面向整个软件系统或规模较大的软件子系统，给出抽象程度较高的结构化组织方式。

2026/4/2657它提供一些预定义的子系统或构件，规定其职责，描述它们之间相互关系、协作方式的规则或指南。体系结构设计模式②软件子系统或构件设计模式：面向中等规模的软件子系统或构件，以独立于程序设计语言的方式，给出内部的软件元素（粒度更小、抽象级别更低的子系统或构件）的结构化组织方式。如果此类设计模式采用面向对象方式给出解决方案，那么，方案中的软件元素往往是类，解决方案除规定每个类的职责外，还会以UML类图表示类之间的关系，以UML交互图表示类之间的协作途径。③面向软件实现的设计模式：针对软件子系统或构件中的某个特定问题，描述如何利用特定的程序设计语言的具体特征来解决此问题。此类模式不影响软件结构。2026/4/2658体系结构设计模式（2）从模式解决的设计问题的类别看，模式可划分为：①创建型模式（工厂方法模式、生成器模式）专门解决复杂对象的创建问题。②结构型模式（adpter适配器模式、Bridge桥接模式）将软件系统、子系统或构件分解为粒度更小的软件元素，规定其职责和协作方式。③行为型模式（Interpreter解释器、Iterator迭代）不仅描述软件系统、子系统或构件的内部结构，更强调位于结构中的软件元素在协同解决问题时的通信及控制流模式。2026/4/2659体系结构设计模式④分布型模式（客户机/服务器构架）为构件分布于网络中不同计算机的软件系统提供系统结构和远程互操作方法。⑤适应性模式（微核模式）专门针对软件系统、子系统或构件的扩展、改进、演进、变更等设计问题提供软件解决方案。⑥访问控制模式（MVC）专门针对构件、软件服务或共享资源的访问控制问题提供软件解决方案。2026/4/2660体系结构设计模式（3）按照模式基于的计算平台类别可划分为：①独立于计算平台的设计模式。②面向特定计算平台（如J2EE、.NET等）的设计模式

设计模式的意义和价值：以标准并且规范的方式记录软件设计经验，支持软件设计级复用。2026/4/26617.4.2通用的体系结构模式体系结构模式是专门针对体系结构设计问题的设计模式，是软件体系结构设计的经验结晶。本节内容：分层模式管道与过滤器模式黑板模式2026/4/2662（一）分层模式该模式将软件系统按照抽象级别逐次递增或递减的顺序划分为若干层次，每层由一些抽象级别相同的构件组成，见图7.9。在严格的分层体系结构中，每层的构件仅为紧邻其上的抽象级别更高的层次提供服务，并且它们仅使用紧邻下层提供的服务；在稍松散的分层体系结构中，服务提供者和接受者可以跨越中间层，但前者一定位于比后者更高的抽象层次。一般而言，顶层直接面向用户提供软件系统的交互界面，底层则负责提供基础性、公共性的技术服务，它比较接近于硬件计算环境、操作系统或数据库管理系统，中间层的抽象级别介乎二者之间。2026/4/2663图7.9分层体系结构模式示意图2026/4/2664（一）分层模式层次之间的连接有两种形态：高层构件向低层构件发出服务请求，低层构件在计算完成后向请求者发送服务应答。在此过程中，低层构件可能向更低层构件发送抽象级别更低、粒度更细的服务请求。低层构件在主动探测或被动获知计算环境的变化事件后通知高层构件，这种通知链可能一直延伸到最高层以便软件系统向用户报告，也可能中止于某个中间层次。2026/4/2665分层模式每个层次对上层服务接口的两种组织方式

⑴层次中的每个提供服务的构件公开其接口

⑵将这些接口封装于层次的内部，每个层次提供统一的、整合的服务接口前一种方式对上层服务请求者更直接，服务提供者所在层次的透明度也较高后一种方式降低了两个层次之间的耦合度。合理地确立一系列抽象级别是采用分层模式进行体系结构设计的关键。2026/4/2666分层模式分层体系结构模式具有以下正面效应：⑴松耦合通过软件层次的划分和层间接口的规整有效降低整个软件系统的耦合度，强化软件系统各构件之间依赖关系的局部化程度。⑵可替换性一个层次可以被实现了同样的对外服务接口的层次所替换；

接口变化给层次替换带来的影响仅限于直接使用该层服务的上层构件。2026/4/2667分层模式⑶可复用性具有良好定义的抽象级别和对外服务接口的层次可以在不同的上下文环境中实现复用。⑷标准化定义清晰、广为接受的抽象级别可促进标准化构件和标准化接口的开发

如，ISO七层网络协议模型、POSIX接口标准、Java虚拟机（JVM）标准

在各自领域的标准化进程中发挥了关键性作用。2026/4/2668分层模式分层体系结构在性能开销方面的负面效应：⑴高层功能可能需要逐层调用下层服务，返回值、报错信息又需逐级上传，这种过程一般会比直接实现高层功能更耗时。⑵如果低层服务还完成了最初的服务请求者所不需要的冗余功能，那么性能损耗就会更严重。2026/4/2669（二）管道与过滤器模式管道与过滤器模式将软件系统的功能实现为一系列处理步骤，每个步骤封装在一个过滤器构件中，见图7.10。相邻过滤器之间以管道连接，一个过滤器的输出数据借助管道流向后续过滤器，作为其输入数据。整个软件系统的输入由数据源（datasource）提供，它通过管道与过滤器相连。软件系统的最终输出由源自某个过滤器的管道流向数据汇（datasink）。典型的数据源和数据汇包括数据库、文件、其他软件系统、物理设备等。一个软件系统可以有多个数据源、多个数据汇。2026/4/2670图7.10管道与过滤器模式示意图2026/4/2671管道与过滤器模式过滤器、数据源、数据汇与管道之间的协作方式有以下几种：⑴过滤器以循环方式工作，不断从管道中提取输入数据，并将输出数据压入管道。

此种过滤器称为主动过滤器。⑵管道将输入数据压入位于其目标端的过滤器，过滤器被动地等待输入数据。⑶管道负责提取位于其源端的过滤器的输出数据。2026/4/2672（三）黑板模式黑板模式将软件系统划分为黑板、知识源和控制器三类构件，见图7.11。黑板负责保存问题求解过程中的状态数据，并提供这些数据的读写服务；知识源负责根据黑板中存储的问题求解状态评价其自身的可应用性，进行部分问题求解工作，并将此工作的结果数据写入黑板；控制器负责监视黑板中不断更新的状态数据，安排（多个）知识源的活动。2026/4/2673图7.11黑板模式示意图2026/4/26747.5概念设计主要目标：根据关键需求确定初始的软件体系结构雏形。甄别出关键的软件需求项体系结构雏形2026/4/26757.5.1关键需求辨识关键需求包括关键的功能需求项和关键的非功能需求项。辨识关键功能需求项的主要方法：⑴确定核心或基础性功能。⑵确定为实现对外接口所必需的支持功能。⑶标识实现难度较大、实现风险较高的功能。⑷确定最能体现待开发软件特色的功能需求。⑸确定前述类别没有覆盖，但对用户满意度影响甚巨的功能需求。⑹剔除对体系结构塑形无贡献的功能需求项。2026/4/2676关键需求辨识辨识关键的质量需求项的主要方法如下：⑴区分影响用户认可、接受本软件系统的质量需求与

“锦上添花”型的质量需求，将前者纳入关键集。⑵标识实现难度较大、实现风险较高的质量需求。⑶针对所有可能冲突的质量需求项对，确定并明示权衡决策，然后决定采纳以下三种选项之一：仅将优先支持的质量需求项纳入关键集，将二者均纳入或均不纳入关键集。2026/4/2677关键需求辨识注意：高优先级并不完全等同于高关键性。关键质量需求项所占比例应远大于关键功能占比只要某项约束对软件体系结构有影响，就必须纳入关键集。那些与软件体系结构无关的约束，例如编程语言限制等，不应进入关键集。2026/4/2678例7.1辨识关键需求项根据例4-9，家庭保安系统的功能性需求项有“开关机及复位处理”、“日志查询”、“配置管理”和“传感器监测”。除“日志查询”外，其他用例均属核心基础性功能，所以我们将它们全部纳入关键需求集。由于家庭保安系统的规模很小，所以关键的功能需求项所占比例很高是可以理解的。根据例4-6，家庭保安系统的质量需求项如表4-1（见p104）所示。基于该系统的市场定位和竞争力要求，我们将安全性、可靠性、性能和可配置性纳入关键需求集。(见P136）2026/4/26797.5.2体系结构初创体系结构初创的任务：建立初始的软件体系结构雏形，它属于软件体系结构的逻辑视图，与具体的软件实现技术无关。建立体系结构雏形的依据：主要是前述的关键需求集；鉴于目标软件的运行环境对体系结构的影响很大，建立雏形时还必须考虑运行环境。如，集中式的单机软件、运行于局域网内部的客户/服务端软件与运行于Internet之上的Web软件的体系结构大不相同。2026/4/2680体系结构初创1、确定了采纳何种体系结构模式（分层、管道与过滤器、黑板模式）2、将分析模型中分析类所承担的职责注入到模式中合适的模块3、根据职责协作关系建立体系结构中这些模块之间的逻辑关系4、软件体系结构的雏形。如，如果选定分层模式，就必须说明每层负责完成分析模型中哪些分析类所承担的哪些职责，及层次之间的协作关系。2026/4/2681图7.12家庭保安系统的体系结构雏形2026/4/26827.6体系结构精化体系结构精化的主要目标：将概念体系结构精化成为全面的、设计适度的软件体系结构。本阶段的体系结构精化工作主要围绕逻辑、运行、数据、物理、开发五种体系结构视图的精化或创立展开重点是逻辑视图的精化2026/4/26837.6.1逻辑视图体系结构的精化推荐采用以下设计过程精化逻辑体系结构。⑴搜索并选取可用的设计资产；⑵设计技术支撑设施；⑶确立设计元素；⑷整合设计元素。以上设计活动应该依序而行动。2026/4/2684（一）搜索并选取可用的设计资产“可用”的设计资产：指在当前项目中直接可供复用或借鉴的设计资产。包括：现成的软件系统或子系统，开发机构自身积累的构件库、服务库，业界广泛采用的类库、中间件或框架，以及Internet上开源的软件资产。2026/4/2685图7.13可复用的设计资产与

软件体系结构的整合2026/4/2686（二）设计技术支撑设施体系结构师必须研究公共的基础性软件技术问题，设计技术支撑设施。如，对企业应用软件（包括电子商务应用、企业管理信息系统等），需要数据持久存储服务、安全控制服务等。2026/4/2687（1）数据持久存储服务数据持久存储：是指在目标软件系统结束一次运行之后，其产生的部分数据能够留存于系统的存储介质中，以供本软件下次运行时使用，或者供其他软件系统使用。数据持久存储服务的功能包括数据的持久存储、查询（选择性读取）、更新、删除等。设置数据持久存储服务的目的：将目标软件系统中依赖于系统运行环境的数据存取部分与其他部分相分离。2026/4/2688数据持久存储服务通常将数据持久存储服务作为一个子系统，该子系统通常包含一个通用构件，利用它为若干面向不同业务数据的持久存储服务构件提供基础性的数据持久服务。图7.14数据持久存储服务子系统的结构2026/4/2689图7.15

数据持久存

储服务及其

与软件体系

结构的整合2026/4/2690（2）安全控制服务设置安全控制服务的目的：是将目标软件系统中有关安全控制的功能集中起来，以便统一管理安全策略，提高安全策略的可配置性。安全控制服务包含用户身份认证和授权控制两种功能，前者验证用户是否具有合法身份，后者判断用户在请求某种类型的服务时是否具有相应的权限。2026/4/2691图7.16

安全控制服务

及其与

软件体系结构

的整合2026/4/2692（三）确立设计元素设计元素包括子系统、构件、设计类。目的：本活动以概念体系结构中的模块（职责）为基础，以软件需求的实现为目标，探索如何将概念模块组织为设计元素。进一步研究这些设计元素的职责划分和协同工作。注意：确定设计元素的接口和相互协作关系，不需要给出设计元素的内部结构和实现途径，此项工作留给子系统设计、构件设计和类设计再进行。2026/4/2693图7.17子系统设置、子系统接口设计及其与软件体系结构的整合2026/4/2694例7.7确定关键设计类及其接口基于家庭保安系统的用例模型（见例4-9）和分析模型（见例5-10），经过例7.6和例7.13所述的设计，尚未纳入传感器监测子系统、配置管理子系统和日志管理构件的分析类只有“输入键盘接口”和“显示面板接口”两个边界类。本例认为它们并不关键，可以在体系结构设计阶段暂且忽略，待详细设计时再予考虑。2026/4/2695（五）整合设计元素迄今为止已经获得的设计素材包括：可供复用的既有设计元素，技术支撑设施中的设计元素，以及从概念体系结构和需求模型推导出来的设计元素（子系统、构件和关键设计类）。现在需要将它们整合起来以协同完成所有的软件需求项，最终给出软件体系结构的完整逻辑视图。2026/4/2696图7.18家庭保安系统的逻辑体系结构2026/4/26977.6.2开发视图体系结构的设计开发视图体系结构主要关注软件源代码文件（含配置文件）的程序分包及目录结构，编译后生成的目标文件分包，它们之间的关系以及它们与逻辑视图中各模块之间的映射关系。设计开发视图体系结构的原因：

因为适当的开发视图体系结构是体系结构设计充分性的主要指标之一，它可以为详细设计和软件实现人员提供具体可操作的行动指南。从这个意义上说，开发视图体系结构应该细化至可以支持详细设计和软件实现的并行展开。2026/4/2698例7.9设计开发视图体系结构假设采用Java和Eclipse来开发家庭保安系统软件开发机构的简称为“seBook”。设定传感器监测子系统、配置管理子系统、日志管理构件、数据持久存储服务构件和安全控制服务构件对应的源代码程序包依次为com.seBook.safeHome.monitor、com.seBook.safeHome.configManager、com.seBponents.logManager、com.seBponents.dataService、和com.seBponents.securityService。2026/4/2699例7.9设计开发视图体系结构（续1）基于体系结构中顶层设计元素的划分，建议将传感器监测子系统、配置管理子系统、日志管理构件、数据持久存储服务构件和安全控制服务构件的目标代码分别封包为safeHomeMonitor.jar、safeHomeConfigManager.jar、logManager.jar、dataService.jar、securityService.jar。这样，家庭保安系统的目标代码共包含5个jar文件，它们与源代码程序包之间的对应关系是显而易见的。最后得到家庭保安系统的开发视图体系结构如图7.19所示。2026/4/26100图7.19家庭保安系统的开发视图体系结构2026/4/261017.6.3物理视图体系结构的设计软件体系结构的物理视图的作用：负责展示软件中各子系统、构件部署到哪些计算结点上运行，以及这些结点之间的网络连接方式。它反映了软件系统的网络运行环境和物理分布状况。UML部署图是表示物理视图体系结构的合适工具，见图7.20。2026/4/26102图7.20

课程注册管理系统的

物理视图体系结构2026/4/261037.6.4运行视图体系结构