软件建模训练(3) 软件设计与软件体系结构 张静 南京理工大学计算机科学与工程学院

软件设计 什么是设计？ 良好的设计（罗马建筑批评家Vitruvius） 设计是你身处两个世界——技术世界和人类的目标世界， 而你尝试将这两个世界结合在一起 良好的设计（罗马建筑批评家Vitruvius） 坚固：程序应该不含任何妨碍其功能的缺陷 适用：程序应该符合开发的目标 愉悦：使用程序的体验是愉快的

从需求分析到软件设计

设计阶段的通用任务 检查信息域模型，并为数据对象及其属性设计恰当的数 据结构 使用分析模型，选择一种适用于软件的体系结构风格 将分析模型分割为若干个设计子系统，并在体系结构内 分配这些子系统：确保每个子系统是功能内聚的。 创建一系列的设计类或构建 设计外部系统或设备所需要的所有接口 设计用户接口 进行构件级设计 开发部署模型

软件设计的概念（关注点） 抽象 体系结构：程序构件（模块）的结构和组织，构件的交 互形式，以及它们所用的数据结构 模式 数据抽象：描述数据对象和数据集合，并冠名 过程抽象：具有明确有限功能的指令序列 体系结构：程序构件（模块）的结构和组织，构件的交 互形式，以及它们所用的数据结构 结构特性：定义了系统的构建、构建的封装方式，以及交互 方式 外部功能特性：性能、能力、可靠性、安全等需求 相关系统族：抽取在一类相似系统中可以复用的模式 模式 特定场景的设计结构

软件设计的概念（关注点） 关注分离点 模块化 信息隐藏 功能独立 重构 运用“分而治之” 一种改变软件系统的过程：不改变代码（设计）的外部 行为而是改进其内部结构

软件设计的概念（关注点） 面向对象的设计 设计类 用户接口类 业务域类 过程类 持久类 系统类 良好类的特性 完整性与充分性 原始性 高内聚 低耦合

设计模型

设计模型 体系结构元素 接口元素 构建级元素 部署级元素

软件体系结构

软件危机 美国IBM公司在1963年至1966年开发的IBM360机的操作系统。这一项目花了5000人一年的工作量，最多时有1000人投入开发工作，写出了近100万行源程序。......据统计，这个操作系统每次发行的新版本都是从前一版本中找出1000个程序错误而修正的结果。...... 这个项目的负责人F. D. Brooks事后总结了他在组织开发过程中的沉痛教训时说：“......正像一只逃亡的野兽落到泥潭中做垂死的挣扎，越是挣扎，陷得越深，最后无法逃脱灭顶的灾难。......程序设计工作正像这样一个泥潭，......一批批程序员被迫在泥潭中拼命挣扎，......谁也没有料到问题竟会陷入这样的困境......”。IBM360操作系统的历史教训成为软件开发项目的典型事例为人们所记取。

软件危机 成本日益增长 进度难以控制 质量差 维护困难 美国空军计算机系统的数据：1955年，软件费用约占总费用的18%， 1970年达到60%，1975年达到72%，1980年达到80%，1985年达到 85%左右 进度难以控制 用户需求变化等各种意想不到的情况层出不穷；随着人员数量的增加， 人员的组织、协调、通信、培训和管理等方面的问题将更为严重 质量差 程序员几乎总是习惯性的以自己的想法去代替用户对软件的需求，软件 设计带有随意性，很多功能只是程序员的一厢情愿而已 维护困难 维护软件支付的费用占全部硬件和软件费用的40-75%

软件体系结构的出现 软件体系结构虽脱胎于软件工程，但其形成同时借鉴了计算机体系结构和网络体系结构中很多宝贵的思想和方法，最近几年软件体系结构研究已完全独立于软件工程的研究，成为计算机科学的一个最新的研究方向和独立学科分支。

对比

温彻斯特神秘之屋（加州，圣何塞） 38 years of construction – 147 builders 0 architects 160 rooms – 40 bedrooms, 6 kitchens, 2 basements, 950 doors 65 doors to blank walls, 13 staircases abandoned, 24 skylights in floors No architectural blueprint exists

什么是软件体系结构？ Software Architecture is the structure or structures of the system, Which comprise software elements, the externally visible properties of these Elements, and the relations among them 软件体系结构是系统的一个或多个结构，它包括：软件 的组成元素（组件），这些（组件）元素的外部可见特 性，以及这些元素（组件）之间的相互关系。

问题 软件的组成元素到底是什么？ 外部可见属性指什么？ 相互关系都有哪些？

定义的含义-1 系统由一个或多个结构组成，这些结构可以从不同侧 面进行描述。 例如：功能划分的模块结构，是对开发小组分配任务的 基础；另一种结构是系统运行时的结构，比如：该系统 被构建为一组并行的进程。将在运行时存在的进程、以 前描述的各种实现单元中的程序和进程间的同步关系组 成了另一种通常用来描述系统的结构。

定义的含义-2 每个系统都有一个体系结构 每个系统都有体系结构，但并不意味着任何人都知晓 该体系结构的存在 每个系统都是由元素和元素之间的关系组成。 最简单的例子，一个系统就是由一个元素和它自身的 关系组成 每个系统都有体系结构，但并不意味着任何人都知晓 该体系结构的存在 如果你不明确的开发一个体系结构，你仍然拥有一个- ---只是不是你喜欢或期望的。

定义的含义-3 软件体系结构是系统的抽象 元素外部可见的属性是指元素对其它元素来说 定义中并没有明确说明什么是elements： 体系结构定义了元素以及它们如何交互。体系结构隐瞒了纯粹的属于局部 的信息，元素的细节不属于体系结构。 元素外部可见的属性是指元素对其它元素来说 提供的服务 需要的服务 共享资源的使用等 定义中并没有明确说明什么是elements： 是一个对象？一个实现单元？一段进程？一个函数库？数据库？商业构件？ 以上都有可能，还可能是其它一些事物 各元素间的交互关系也可能有多种 例如：细划分，同步，调用，包含…

总结 软件体系结构包括以下有意义的决策： 软件系统的组织； 对结构元素和它们的接口的选择，通过接口，系统被组织在一 起，它们的行为在这些元素的协作中被指定； 这些元素被逐渐组织成一个更大的子系统； 体系结构风格指导组织，这些元素以及它们的接口，它们之间 的协作，以及它们的组成。

结构与视图 类比于建筑，同一栋大楼，承包 商、设计师、室内设计人员、庭 院设计家、电工等都有不同的理解。 为了有意义的传达构架的信息， 必须说明此刻正在讨论构架的哪 个或哪些结构--------也叫视图

软件架构的结构 模块结构 组件-连接器结构 分配结构 部署 实现 工作分配 进程结构 并发结构 共享数据或存贮库 客户-服务器 分解结构 使用结构 分层结构 类或泛化 组件-连接器结构 进程结构 并发结构 共享数据或存贮库 客户-服务器 分配结构 部署 实现 工作分配

模块结构—分解结构

模块结构—使用结构 是“依赖关系的一种特殊的形式”。如果过程A的运行 必须以过程B的正确运行为前提，则称过程A使用过 程B。

模块结构—使用结构 使用结构能给予开发团队强大的能力：它允许构建整体系统中 的小子集。 使用关系可以使我们快速确定功能子集。如果我们知道过程A在某一子 集中，则我们知道过程A所使用的所有过程也在该子集中。子集由这种 使用关系的传递闭包构成。 在项目之初，凭借这一能力，即可进行增量式的开发。在开发 的每一步骤，系统将实现其整体功能的一部分，并能正确的执 行它，虽然其完整性还远远不够。 完好的整体系统子集通常能作为产品的简化版本进行销售。 使用关系还是一种有用的调试和集成测试工具。 如果发现程序正在产生错误的结果，那么问题要么出现在程序本身，要 么出现在它使用的程序上。使用关系能即刻缩小可疑对象的范围。

模块结构—分层结构 有些分层方案允许某个层使用较低层的公共设施， 而不仅仅是离它最近的较低层的设施。任何正式称 为分层构架的架构都不会毫无约束的允许某个层使 用较高层的基础设施。 层越低，它可以使用的公共设施越少。例如：人们 倾向于使用计算机、通信信道、分布式机制、进程 调度等构筑较低层。这些专业领域大多独立于运行 在其上的应用，这意味着，即使应用出现了变化， 也不必对他们修改。相反，较高层则往往更具有平 台独立性，它们之所以做到这一点，是因为较低层 的存在赋予了它们这种自由。

模块结构—分层结构 元素：层（模块的聚合） 关系：允许使用的关系 每个层就是一个虚拟机，此外，还存在一些对虚拟 机之间关系的约束条件。 虚拟机：虚拟机是一种抽象计算设备；一般说来， 它是一种程序，该程序能充当其他软件和实际硬件 之间的接口。

模块结构—分层结构

“父模块”拥有共性，而“子模块”则表现出差异性 模块结构—类或泛化 “泛化” “特化”： Shape Polygon Circle Spline … “父模块”拥有共性，而“子模块”则表现出差异性 ？分解结构

模块结构—类或泛化 泛化风格支持面向对象的设计：它是基于继承性 的面向对象的系统设计的主要方法。类图。 扩展和演化： 局部更改或变化：构架的用途之一是提供稳定的 结构，以便允许局部更改或变化。泛化是一种 在较高层定义共性和将差异性定义为子模块的 方法。 重用：适当的抽象可以只在接口层重用，抽象 模块的定义能为重用创造机会。

组件和连接器结构—概述 组件：（Component）是软件系统的结构块单元，是软 件功能设计和实现的承载体，因此，每个软件组件都承 担着一定的功能并发挥着一定的作用，如，中断程序、 设备驱动程序、过程、各种功能库、文件等。 组件可以看做是模块、类、对象等一个相关功能的集合。 组件大都作为一个分状的实体，其内部结构和信息隐藏 起来。每个组件至少有一个接口。接口是组件与外界发 生交互的窗口。其他组件与其交互时，只需了解此组件 对外的接口和提供的操作服务。

组件和连接器结构—概述 连接：（Connect）是组件间建立和维护行为关联及信息传递的途径。 连接需要两方面的支持：一是连接发生和维持的机制，这是实现连 接的物质基础；二是连接能够正确地、无二义、无冲突地进行信息 交换的保证，这就是连接进行有效信息交换的规则，称为连接的“协 议”。 连接的本质是实现连接机制和信息交换协议，简称机制和协议。 连接器：（Connector）当组件间联系关系复杂时，需要建立专门的 连接组件以调度和协调组件间的关联关系，实现组件间联系的特殊 组件称为连接器。 组件间的联系有：消息和信号的传递，功能和方法的请求或调用， 数据的传送和转换，组件间特定关系的协调和维持等，所有涉及组 件间信息、行为、特性的联系和依赖。

组件-连接器结构—进程结构 进程结构由软件中的一组进程构成。该结构 包含的关系是：“与之同步”或“互斥” 要包含“调度机制”，调度工作中包含死锁避 免机制。 进程结构收集两类信息：第一类信息说明在 每个进程中用到哪些过程；第二类信息哪些 进程不能同时进行（互斥）。

组件-连接器结构—并发结构 组件-连接器中的单一组件可以执行由许多模块定义的代码。 Main Split To-lower To-upper Merge Config Stdio Split To-upper To-lower Merge

组件-连接器结构—客户-服务器结构 组件是“客户机-服务器” 连接件：可以是多种形式

分配结构——概述 硬件、团队结构、文件系统都会与软件构架 进行交互，所以必须考虑这一类结构。 通过将软件构架映射到硬件即可对系统性能 进行分析；通过将软件构架映射到团队结构， 项目管理活动才得以展开；通过将软件构架 映射到文件结构，系统开发管理才得以进行。

分配结构 元素：软件和环境元素(环境元素如：处理器，特大 容量磁盘，；配置条目或开发团队。) 关系：“分配到”

任何一个视图只能表示体系结构的部分内容， 候选视图的集合不是固定的也不是规定的，选 软件系统的视图 任何一个视图只能表示体系结构的部分内容， 候选视图的集合不是固定的也不是规定的，选 择一组来支持分析、交流或理解体系结构。

软件系统的视图 Philippe Kruchten IEEE Software 12(6):42-50,1995 Rational统一过程的概念基础

4+1体系结构视图

4+1体系结构视图—逻辑视图 Logical View 支持主要的功能需求---系统应当向用户 提供什么样的服务。 我们能利用“模块结构” 和“组件-连接器”结构来编档 “逻辑视图”。（将模块分解风格、使用风格、 泛化风 格结合起来后，即可利用子系统和类等元素表示逻辑 视图的结构部分；而组件-连接器视图类型则允许我们 利用组件和端口表示运行时特征）

4+1体系结构视图—过程视图 Process View 主要考虑的是系统的非功能属性： 如性能、可用性等。它所面对的问题有并发、 分布，系统的完整性、容错能力等。

4+1体系结构视图—开发视图 Development View 关注的是在软件开发环境中软件 模块的实际组织，软件被打包成可由单个或少量程 序员开发的各种小的部分：程序库或子系统。一般 来说子系统被组织为层次化的体系，每一层为上一 层提供一个严密的、明确的接口。

4+1体系结构视图—部署和用例视图 Deployment View 描述将软件系统映射到各个 物理节点上。 Use Case View（场景视图）：利用用例来验证和描 述其它的视图。