面向对象分析与设计(5)-设计模型

设计包
一个包中可以包含公有类，也可以包含私有类


公有类可以与任何其他类相关联 私有类只能与其所在包中包含的类相关联
包接口由包的公有类组成，包接口隔离并实施对其他包的依赖关系

包耦合的原则
不应对包进行交叉耦合（即互相依赖），例如两个包不应互相依赖。 较低层中的包不应依赖于较高层中的包，包只应依赖于同一层及下一 层中的包 通常，依赖关系不应跳层，除非依赖行为在所有层之间都是共同的
Biblioteka Baidu

在某些应用程序中，某些特定信息应该只能由少数几个人 访问。子系统使您能够在需要保守秘密的地方保守秘密 子系统用于代表系统所使用的现有产品和服务（例如 COTS 产品和库）
步骤

识别类和子系统
识别子系统接口 识别复用机会 修改设计模型的组织 评审
识别设计类和子系统

这个活动的主要目的还是根据分析类的交互识别出设计 子系统或包；大部分设计类还是在用例设计和子系统设 计中产生的 子系统的类型
Ivar Jacobson 说：“只有在所有的用例为所有 事件进程建立了交互模型之后，才可以确定已 经发现系统所需的每个对象所扮演的角色，以 及它们的责任。”
交互模型表现方式

在UML规范中，交互模型包括两种不同的 表现形式：
一种是强调顺序的顺序图（Sequence diagram），读者可以从中可以很容易地看出 事件发生的次序； 另一种是强调组织的协作图（Collaboration diagram），它通过使用布局图指明了各个对 象之间是如何静态相连的。

选择基础类举例(续)
当我们需要进行网络操作时，我们可以从 MFC中选择一个Socket的实现，也可能是 从SUN提供的网络包中选择相应的类 当我们需要进行用户界面设计时，我们可 能使用MFC 中提供的相关类，也可能使用 Java中的AWT或Swing包来实现。

学习开发知识的要点
应该花足够多的时间来了解各种基础框架、 库函数的功能与特性，以便在设计时做出 最优的选择； 另外，还应该对这些基础框架、库函数的 类结构有一个清晰的了解，这样就可以最 有效地找到基础类，最高效地使用。

识别设计元素

目的
分析分析类的交互以识别设计模型元素 细化构架，可能时结合复用 识别通用设计问题的通用解决方案 把构架相关的设计模型元素放到Logical view部分 补充规约 设计指南 软件构架文档 分析类 设计模型

输入


输出
设计模型元素（设计类、接口、设计包、设计子系统）
分析模型和设计模型

一个项目可以建分析模型和设计模型两个 模型，也可以只建设计模型
如果分析模型和设计模型的差别很大，那就要 建两个模型 如果分析模型和设计模型的差别不大，那就只 建设计模型

如果你只建了一个设计模型，最好能把分 析后的结果作为一个版本保存。
分析与设计
在分析中，焦点是创建系统的逻辑模型， 该模型捕获系统为满足用户需求而必须提 供的功能。 设计的目的是说明如何才能完全实现这一 功能，整合解域的技术解决方案以提供实 际上可实现的系统模型（设计模型）。
设计阶段的工作
将开发出一个基于面向对象的系统逻辑解 决方案。这个解决方案的核心是要建立交 互模型，它能够展示出为了满足系统需求 各个对象相互之间如何进行通信。 在交互图建立之后，接着要建立设计类图， 它对要实现的软件类（和接口）的定义进 行总结。

浅析交互模型


在面向对象的视角里，整个系统是由一系列的对 象，以及对象之间的交互与协作构成的 交互建模，正是要通过寻找对象之间的交互关系， 从而进行“行为分配”

许多子系统共享一组类定义，因此这些子系统将“导入”包含 公共类的包中的内容。这只能用于位于构架低层的包，并且原 因只能是为了确保在子系统之间传递的公共类定义保持一致
划分子系统和包的原因



可以更容易地了解模型的整体结构 可以在完成系统后将包和子系统用作订购、配置或交付单 元 由于资源分配以及不同开发团队的能力不同，可能要求将 该项目划分给处于不同位置的不同组。通过带有明确定义 的接口的子系统，可以在各团队之间以有控制、有协调的 方式划分工作，从而使设计和实施能够平行地进行 子系统可用于按照用户类型来建立设计模型的结构。许多 变更需求都来自于用户；子系统可确保来自特定用户类型 的变更需求只影响系统中与该用户类型对应的部分
控制子系统 协调子系统 数据采集子系统：从外部环境采集数据 数据分析子系统：分析数据并负责报告和/或显示其他子系统采 集的数据 Server子系统：其它子系统提供服务 用户界面子系统

提供用户界面，并且作为client向用户提供对一个或多个server提 供的服务的访问 对于不同类型的用户，可能会有不同的用户界面子系统 通常是由多个简单用户界面对象组成的组合对象
交互模型的步骤

引入实体对象
实体对象就是域模型（类图）中的某个分析类 的一个实例
引入边界对象和参与者 引入控制对象

构建交互模型-新增书籍信息

基本事件流
1）图书管理员向系统发出“新增书籍信息”请求； 2）系统要求图书管理员选择要新增的书籍是计算机类还是非计算 机类； 3）图书管理员做出选择后，显示相应界面，让图书管理员输入信 息，并自动根据书号规则生成书号； 4）图书管理员输入书籍的相关信息，包括：书名、作者、出版社、 ISBN 号、开本、页数、定价、是否有CDROM； 5）系统确认输入的信息中书名未有重名； 6）系统将所输入的信息存储建档。
确定基础类的原则
首先要根据应用的需要选择相应的框架 然后再根据具体的局部需要还选择相应的 库函数。

选择基础类举例
如果我们需要进行数据库操作，我们将可 能使用ODBC、JDBC、ADO、BDE 等数 据库访问引擎中的一种. 如果我们需要分布式地处理，就可能要从 DCOM、CORBA、EJB、WebServices 中选择一种合适的技术

扩展事件流
5a）如果输入的书名有重名现象，则显示出重名的书籍，并要求图 书管理员选择修改书名或取消输入； 5a1）图书管理员选择取消输入，则结束用例，不做存储建档工作； 5a2）图书管理员选择修改书名后，转到5）
构建设计模型

在构建交互模型时，将会发现类应该具有 的方法，也会在设计时找到一些新的属性， 而这些东西将进一步地完善我们的静态模 型(概念模型)。

映射到设计元素的途径
一个分析类成为设计模型中的一组功能相 关的类（设计包） 一个分析类成为设计模型中的一个子系统 一个分析类成为设计模型中的一个关系 一个分析类的组成部分可以被硬件实现， 而根本不在设计模型中出现 任何上述方式的组合

设计类图应完成的工作

在设计中，必须准确地说明类是如何履行 它们的职责。必须完成以下事情：
介绍新人加入项目 在交付几个月或几年后重新理解系统 理解系统是怎样满足客户需求以及提供可 跟踪性 计划维护和增强 理解系统的逻辑构架 外包系统的构造

设计模型

设计模型内容:
交互模型 设计类图 部署图
设计工作流
设计师
构架设计
用例工程师
设计用例
组件工程师 设计类 设计子系统

具体开发流程
应该由同一个团队负责需求和设计，而不 是采用一个分析师团队和一个独立的设计 师团队。 设计模型建立在分析模型的基础之上，也 可以看作是分析模型的精化和细化。

什么时候需要维护两套模型？
庞大的 复杂的 战略性的 受经常变更所支配的 期望长期运行的 外包的

分析模型的价值
设计元素——设计子系统

设计子系统
设计子系统是一种模型元素，它具有包（其中可包含 其他模型元素）和类（其具有行为）的语义 子系统的行为由它实现的一个或多个接口来定义 子系统的行为由它所包含的类或其他子系统提供 子系统内部的元素对外不可见

子系统的特点
可以独立预定、配置或交付 可以独立开发（只要接口保持不变） 可以在一组分布式计算节点上独立部署 可以在不破坏系统其他部分的情况下独立地进行更改 可以将系统分为若干单元，以提供对关键资源的有限 安全保护 可以在设计中代表现有产品或外部系统
设计类图的步骤

基于域模型的基础，结合分析、交互模型 构建时所引入的分析/设计类，画出相应的 设计类图，并且将这里所找到的属性、方 法补充在类图中去，这样我们将获得一个 较完整的类模型。
分析类到设计类转换
分析中的操作:是类所提供的一小部分功能 的高级逻辑规格说明 设计中的方法:是一个被完整地说明的可以 用源代码实现的功能. 高级的操作实际上可以被分解成一个或多 个可实现的方法.

角色
构架设计师
设计元素——接口和包

接口
接口是定义行为集（即操作集）的模型元素 该行为集由classifier模型元素（即类、子系统或component）提供 classifier可以实现一个或多个接口；一个接口可由一个或多个 classifier实现 实现相同接口的那些classifier在系统中可以互换 每个接口应该是唯一且明确定义的操作集

从分析类到设计元素

在设计活动中，分析类将细化为同样也是 行为承担者的设计元素；通常两者间是多 对多的影射关系
映射到设计元素的途径
一个分析类成为设计模型中的一个类 一个分析类成为设计模型中一个类的组成 部分 一个分析类成为设计模型中的一个聚集类 （意味着聚集中的成员可能不在分析模型 中显式地出现） 一个分析类成为设计模型中的一个继承树 一个分析类之间的关系成为设计模型中的 一个类
设计元素

子系统和包的区别
子系统比包封装性好
子系统有接口，外部只能通过子系统接口访问子系统内部 包没有接口，外部可以直接访问包中公共的类

子系统具有行为，而包没有
子系统是一种通过一个或多个它所实现的接口来提供行为的包 而包并不提供行为它们只是用来容纳对象的容器


子系统依赖关系
子系统不应暴露自己的任何内容；子系统外部的元素都 不应依赖于子系统内部特定元素的存在 子系统只应依赖于其他模型元素的接口，因此它不直接 依赖于子系统外部的任何特定模型元素 。 例外情况
<<system>> CruiseControl&Monitoring System
<<subsystem>> CruiseControlSu bsytem
<<subsystem>> Monitoring
协调子系统




协调子系统负责协调控制子系统的动作 如果这些控制子系统之间完全独立的话，就不需要协调子系 统 如果控制子系统相对来说比较简单，控制子系统可以自行协 调动作 如果协调的工作相对复杂时，使用一个独立的协调子系统通 常更好些 例如：电梯控制系统中的调度子系统。在这个系统中，所有 的电梯内乘客的服务请求都是由该电梯处理的。但是，在电 梯外某楼层的乘客发出服务请求时，必须要决定由哪部电梯 来对应这个请求，这个决定由调度子系统来做。当调度子系 统从楼层子系统接到服务请求时，它决定是否需要分配一部 电梯到那个楼层；如果需要的话，它对选定的电梯子系统发 出调度请求。
面向对象分析与设计
设计模型
分析和设计
分析 侧重于理解问题 功能需求 系统结构 行为(behavior) 小模型 设计 侧重于解决问题 非功能性需求 操作和属性 对象的生命周期 大模型
实现系统行为
分析行为 用例分析活动把系统的 行为分配给分析类，让 分析类交互来完成系统 的行为 设计构件 用例设计活动把系统的行 为分配给设计元素（子系 统、类） 子系统设计活动把子系统 的行为分配给内部的设计 元素 类设计活动完成分配给每 个类的行为
完整的属性集合，包括详细说明的名称、类型、 可视性和一些默认值（可选的） 将分析类指定的操作转化成一个或多个方法的 完整集合。
设计类图-引入基础类

在着手开发之前，还有一件很重要的事要 去完成，那就是引入基础类。
不管使用什么开发工具进行代码编写，都将以 各种库函数、框架作为开发基础。例 如，.NET、J2EE 、CORBA等框架，MFC、 OWL、BDE、Swing、JDBC 等库函数。
I/O子系统 系统服务
控制子系统



控制子系统控制系统的特定方面 控制子系统从外部环境接收输入并向外部环境提供输出， 通常不需要人类干预 控制子系统经常是依赖于状态的，这种情况下它至少含 有一个依赖于状态的控制对象 例如，Cruise Control子系统。该子系统从巡航控制杆、 刹车和引擎接收输入。它的输出控制节流阀。对于节流 阀要进行什么样的调整是依赖于状态的，并且在没有人 类干预的情况下进行。