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

完整的属性集合，包括详细说明的名称、类型、 可视性和一些默认值（可选的） 将分析类指定的操作转化成一个或多个方法的 完整集合。
设计类图-引入基础类

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

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

如果你只建了一个设计模型，最好能把分 析后的结果作为一个版本保存。
分析与设计
在分析中，焦点是创建系统的逻辑模型， 该模型捕获系统为满足用户需求而必须提 供的功能。 设计的目的是说明如何才能完全实现这一 功能，整合解域的技术解决方案以提供实 际上可实现的系统模型（设计模型）。

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

设计类图应完成的工作

在设计中，必须准确地说明类是如何履行 它们的职责。必须完成以下事情：
设计元素

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

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


子系统依赖关系
子系统不应暴露自己的任何内容；子系统外部的元素都 不应依赖于子系统内部特定元素的存在 子系统只应依赖于其他模型元素的接口，因此它不直接 依赖于子系统外部的任何特定模型元素 。 例外情况
设计阶段的工作
将开发出一个基于面向对象的系统逻辑解 决方案。这个解决方案的核心是要建立交 互模型，它能够展示出为了满足系统需求 各个对象相互之间如何进行通信。 在交互图建立之后，接着要建立设计类图， 它对要实现的软件类（和接口）的定义进 行总结。

浅析交互模型



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


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

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

这个活动的主要目的还是根据分析类的交互识别出设计 子系统或包；大部分设计类还是在用例设计和子系统设 计中产生的 子系统的类型

识别设计元素

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

输入


输出
设计模型元素（设计类、接口、设计包、设计子系统）
交互模型的步骤

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

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

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

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

接口
接口是定义行为集（即操作集）的模型元素 该行为集由classifier模型元素（即类、子系统或component）提供 classifier可以实现一个或多个接口；一个接口可由一个或多个 classifier实现 实现相同接口的那些classifier在系统中可以互换 每个接口应该是唯一且明确定义的操作集
控制子系统 协调子系统 数据采集子系统：从外部环境采集数据 数据分析子系统：分析数据并负责报告和/或显示其他子系统采 集的数据 Server子系统：其它子系统提供服务 用户界面子系统

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

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

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

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

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

分析模型的价值
Ivar Jacobson 说：“只有在所有的用例为所有 事件进程建立了交互模型之后，才可以确定已 经发现系统所需的每个对象所扮演的角色，以 及它们的责任。”
交互模型表现方式

在UML规范中，交互模型包括两种不同的 表现形式：
一种是强调顺序的顺序图（Sequence diagram），读者可以从中可以很容易地看出 事件发生的次序； 另一种是强调组织的协作图（Collaboration diagram），它通过使用布局图指明了各个对 象之间是如何静态相连的。
确定基础类的原则
首先要根据应用的需要选择相应的框架 然后再根据具体的局部需要还选择相应的 库函数。

选择基础类举例
如果我们需要进行数据库操作，我们将可 能使用ODBC、JDBC、ADO、BDE 等数 据库访问引擎中的一种. 如果我们需要分布式地处理，就可能要从 DCOM、CORBA、EJB、WebServices 中选择一种合适的技术
<<system>> CruiseControl&Monitoring System
<<subsystem>> CruiseControlSu bsytem
<<subsystem>> Monitoring
协调子系统




协调子系统负责协调控制子系统的动作 如果这些控制子系统之间完全独立的话，就不需要协调子系 统 如果控制子系统相对来说比较简单，控制子系统可以自行协 调动作 如果协调的工作相对复杂时，使用一个独立的协调子系统通 常更好些 例如：电梯控制系统中的调度子系统。在这个系统中，所有 的电梯内乘客的服务请求都是由该电梯处理的。但是，在电 梯外某楼层的乘客发出服务请求时，必须要决定由哪部电梯 来对应这个请求，这个决定由调度子系统来做。当调度子系 统从楼层子系统接到服务请求时，它决定是否需要分配一部 电梯到那个楼层；如果需要的话，它对选定的电梯子系统发 出调度请求。

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


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

包耦合的原则
不应对包进行交叉耦合（即互相依赖），例如两个包不应互相依赖。 较低层中的包不应依赖于较高层中的包，包只应依赖于同一层及下一 层中的包 通常，依赖关系不应跳层，除非依赖行为在所有层之间都是共同的
面向对象分析与设计
设计模型
分析和设计
分析 侧重于理解问题 功能需求 系统结构 行为(behavior) 小模型 设计 侧重于解决问题 非功能性需求 操作和属性 对象的生命周期 大模型
实现系统行为
分析行为 用例分析活动把系统的 行为分配给分析类，让 分析类交互来完成系统 的行为 设计构件 用例设计活动把系统的行 为分配给设计元素（子系 统、类） 子系统设计活动把子系统 的行为分配给内部的设计 元素 类设计活动完成分配给每 个类的行为

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

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

从分析类到设计元素