面向对象的设计与技术第四章.ppt

14.1设计工作流 设计工作流是在细化阶段的最后部分和构造阶段的前半部分的主要建模活动，将分析模型转变为设计模型。 分析模型和设计模型间的区别 UP推荐，应该由同一个团队负责在从需求到分析和设计(最终到实现)来获取制品(例如用例)，而不是采用一个分析师团队和一个独立的设计师团队。 UP是围绕可交付的制品和里程碑来组织团队的，而不是围绕特定的任务来组织团队的。 14.2设计工作流焦点 在分析中，焦点是创建系统的逻辑模型，该模型捕获系统为满足用户需求而必须提供的功能－“作什么”。 设计的目的是说明如何才能完全实现这个功能－“如何作”。 在设计中，OO设计师决定战略性设计问题，诸如对象持久性和分布，并且相应地创建设计模型。 项目经理和设计师也应该制定政策以处理战术性设计问题。 14.3设计制品－元模型 接口是设计中很重要的构架角色，需要花很多时间来寻找共建模关键接口。 分析模型和设计模型之间存在简单的《trace》关系。 设计模型建立在分析模型的基础之上，也可以看做是分析模型的精化和细化 例子 需要维护两个模型吗？ 分析视图的价值 分析视图提供系统的“大场景”。分析视图可能只包括在详细设计视图中的1%到10%的类，它的价值在于： 介绍新人加入项目 在交付几个月或几年后重新理解系统。 理解系统是怎样满足客户需求以及提供可跟踪性。 计划维护和增强。 理解系统的逻辑构架。 外包系统的构造。 如果需要做以上的任何一项，那么绝对需要保留分析视图。 采用何种策略？ 是否需要分析视图关键在于项目大小。 如果系统庞大、复杂或是战略性的，或者具有很长项目规划生存期就应该保留分析视图(选择策略3和策略4) 。但需要考虑分析模型和设计模型步调不一致，你的项目真能接受吗？ 如果系统比较小(少于200个设计类)，设计模型本身小得可以理解，如果系统不是战略性的或只有很短的规划生存期，独立的分析模型也就不需要了。因此只能在策略1和策略2之间选择了， 对于中型系统来说，起着决定性因素的是UML的CASE工具的能力。有些CASE工具维护着单一的底层模型，并允许通过过滤和信息隐藏设法重新从设计模型获得“分析”视图。方案需要综合考虑。 14.4设计工作流细节 设计中主要参与者有构架设计师、用例工程师和组件工程师。 14.5制品 设计模型是分析模型的细化，设计模型添加了详细信息和特定技术的解决方案。 所有的属性和操作(包括返回值类型和参数列表)必须完整。 设计模型由下列各项组成： 设计子系统。 设计类。 接口。 用例实现(设计)。 部署图。 接口是在设计中产生的关键制品之一。 14.4设计工作流细节 分析类是系统中类的高级概念视图，可以被分解成一个或多个接口或者设计类。 当进行设计 (物理建模)时，这些概念上的类需要被实现成一个或多个物理的设计类和/或接口。 小结 本讲介绍设计工作流，关于确定分析模型中说明的功能将如何被实现。 设计工作流是在细化阶段最后部分和构造阶段前半部分的主要建模活动。 设计模型包括：一个设计系统和若干设计子系统，用例实现(设计)，接口，设计类，初步的部署图。 相互之间存在跟踪关系的有：设计模型与分析模型，设计系统与分析系统，一个或多个设计子系统与一个分析包。 需要分别维护分析模型和设计模型的系统是：庞大的，复杂的，战略性的，受经常变更所支配的，期望长期运行的和外包的。 15.1什么是设计类 设计类是已经完成了规格说明并且达到能够被实现程度的类。 在分析中，类来源于问题域，是一组描述你试图去解决问题的需求,以作为分析类的来源。 设计类来自两个方面： 通过分析类的精化得到的问题域，这里的精化包括添加实现细节。 解域—它是实用类库和可复用组件的领域。 15.2 设计类 分析是关于建模系统应当做什么，设计就是关于建模那些行为如何被实现。 分析类是非常高级的抽象，操作集合只是捕获了类关键服务的骨干。 在将分析类精化成设计类时就必须全面说明所有的操作和属性，通常会发现类太大了。如果发生这种情况，就应法将它分解成两个或者更多个类。 应当记住，你所要设计的类是一些能真正做好一两件事情的小的、自含的而且内聚的单元。 15.3设计类剖析 在设计中必须准确地说明类是如何履行它们的职责，必须完成以下事情： 完整的属性集合，包括详细说明的名称、类型、可视性和一些默认值(可选的)。 将分析类指定的操作转化成一个或多个方法的完整集合。 15.4形式良好的设计类 一个形式良好的设计类应具备四个基本特征： 完整的和充分的。 原始的。 高内聚。 低耦合。 设计类将会被交给程序员去编写实际的源代码，也可以在CASE工具支持的情况下由模型自身直接生成代码。 设计类需要被完整地说明，规格说明过程部分决定了这个类是不是“形式良好”。 15.4.1完整性和充分性 完整性就是要提供给类客户他们