1、9 设计模型：创建设计类图（DCD/目标： 创建设计类图(Design Class Diagrams) 识别DCD中的类、方法和关联/设计类图/UML用类图表示类、接口及其关联静态对象建模/常用类图表示法/UML的正式表示法，最上面的格式用来区分包名和类名；第二种非正式格式/三个常见的分栏： 1/类元名称 2/属性 3/操作/用关键字interface表示接口/interface Runnable run(/接口的实现和子类化/依赖/具有多重性的关联/省略号表示这里具有元素，但是没有显示 空分栏的正式含义是“未知”，但也用于表示“没有/设计类图样例/POST enterItem(/Sale D

2、ate isComplete/Boolean time makeLineItem(/1/1/Captures/导航/类的定义的三个区域框/方法，有参数，但没有制定/类型信息/领域模型和设计模型中的类比较/与领域模型不同的是，设计类图显示出了软件实体的定义而不是真实世界中的概念/领域模型 概念***图/设计模型 DCD/软件***图/类元/类元：描述行为和结构特性的模型元素 它们是对众多UML元素的泛化 最常用的两个类元是常规的类和接口/表示UML属性的方式/属性文本，如currentSale/ Sale 关联线 两者兼有/表示UML属性的方式/使用属性文本表示法/使用关联：这种风格从视觉上强调了类

3、之间的关联/指名Register具有对一个Sale实例的引用/完整和明确的风格，两者兼有，但略嫌冗余/表示UML属性的方式/准则：如果没有给出可见性，则通常假设属性为私有 导航线箭头：由源对象指向目标对象，表示Register的一个属性是Sale对象 多重性放置在目标一端(在没有明确指定时为1) 角色名只放置在目标一端，用以表示属性名称/导航线（注/在两个类的导航关系中，如果导航关系的一端有箭头，则箭头代表了导航的方向。 然而，如果有一个”x”出现在导航箭头的起始点上则表明这种导航关系可以不发生。如果既没有箭头，也没有“x”，则表明导航是双向的/UML支持的可见性类型的标志/”代表可导出(de

4、rived)特征/何时使用属性文本（关联线/准则：对数据类型对象使用属性文本表示法，对其他对象使用关联线/应用准则将属性表示为属性文本和关联线/Register具有三个属性： 1/id 2/currentSale 3/location/关联端点的UML表示法/关联端点可以附加导航性箭头，也可以包含可选的角色名（关联端点名）来表示属性名称，也可以附加多重性，如*或0/1 还可以使用特性字符串(是由若干字符串来表述的属性特征) 如： ordered 表示***中的元素是有序的 unique表示一组唯一元素 或ordered/ List，其中list是用户定义的关键字/特性字符串/readOnly ：

5、只读属性/ union ：表明可导出属性是由其他属性联合的结果/ subsets ：表明属性是一个继承得到的属性的子集/ redefines ：改变一个继承得到的属性的名字/ ordered：某类型的一个有序***/***中的元素不能重复； bag：***中的元素可以重复； seq 或 sequence：***元素可以重复，并且有序； composite：组合属性/关联端点的UML表示法/表示***属性的两种方式/注意在关联的末端也可以有特性字符串，例如ordered/list/注释符号：注解、注释、约束和方法体/注解符号：褶角矩形，并使用虚线连接到要注解的元素上 注解符号可以表示： UML注解或注释

6、UML约束： 方法体：UML操作的实现/例/操作和方法/语法： visibility name (parameter-list) property-string 还可以加返回类型或特性字符串，包括异常、操作是否抽象等 如： +getPlayer(name/String)：Playerexception IOException public Player getPlayer(name/String) throws IOException/如何在类图中表示方法/UML方法是操作的实现，如果定义了约束，则方法必须满足这些约束 在交互图中，通过消息的细节和顺序来表示 在类图中，使用构造型为method

7、的UML注解符号/method/DCD中的操作问题/create操作，交互图中对其的解释为：在Java和C#等语言中，对new操作符和 构造器的调用 访问属性的操作，即提取或设置属性的操作，如getPrice和setPrice，通常不包含在类图中/关键字/UML关键字是对模型元素分类的文本修饰/或简化为或的形式/构造型，简档和标记/构造型也使用符号表示，例如authorship 构造型表示对现有建模概念的精华，并且定义在UML简档中 简档是一组相关构造型、标记和约束的***，其目的是使用UML专用于特定领域或平台 标记：如果用构造型标记元素，则所有标记都适用于该元素，并且能够对其赋值/构造型，简

8、档和标记/声明构造型/UML扩展：关系于基本的UML元模型术语 Element/UML扩展：关系于基本的UML元模型术语 Element/使用构造型 一旦元素用Authorship创建构造型后，工具便可能允许弹出（菜单或窗口）以填写标记的值/metaclass Element/stereotype Authorship/Authorship Square/authorship author=“craig” Status=“tested/UML特性和特性字符串/特性：表示元素特征的已命名的值。特性具有语义影响 特性字符串 如：abstract/visibility=public 有些特性没有值，

9、例如abstract，这通常表示布尔类型的特性，是abstract=true的简写/进行类图建模的基本技术和思想/继承技术 关联和依赖技术 聚合和组合技术 为方法建模 为属性建模 在模型中引入接口/类建模继承/1、继承技术 要注意实现继承 即接口继承 应该能用一个子类的实例去替代父类的实例（Liskov替换原理）； 留心多重继承； 父类应该对子类一无所知； 要留心仅以公共数据属性为基础的继承/类建模继承（续/在类层次结构中，要尽量把分解出的公共部分放在最***； 子类应该继承所有内容（纯粹继承），因此也就继承了父类的所有关系。 纯粹继承使得我们不需要关心子类没有继承什么 纯粹继承的优点在于：在纵

10、深的类层次中如果你仅需要了解每个类添加了什么，而不用知道其删除了什么，这会使你轻松得多/泛化、抽象类、抽象操作表示/泛化：用由子类到超类的实线和空心三角箭头表示 抽象类和操作即可以采用abstract标记表示，也可以采用斜体名称来表示 终止类和不能够被子类复写的操作以leaf标记表示/类建模关联和依赖/类之间的关联帮助我们定义对象如何和其他对象交互，使对象之间的协作成为可能。 当两个对象之间不存在持久关联，但是他们又要进行协作时，两者之间可以建立依赖关系； 多重性一定要显示出来； 关联和依赖能够被继承（关联和依赖是通过属性和方法来实现的）； 关联的以上性质同时适用于组成和聚合/依赖/依赖用从客

11、户到提供者的虚线箭头表示 依赖类型： 拥有提供者类型的属性 向提供者发送消息。对提供者的可见性可能是：属性、参数变量、局部变量、全局变量或类的可见性 接受提供者类型的参数 提供者是超类或接口 如果已经存在关联线，则不必添加第二条有虚线箭头的依赖线/依赖/Sale具有对ProductDescription的参数可见性，因此对其也具有某种依赖/依赖/如下代码： public class Foo public void doX() System/runFinalization()//doX方法具有对System类的依赖/依赖标签/为表示依赖的类型，或者为代码生成工具提供帮助，可以给依赖线附加关键字或

12、构造型/依赖于对Clock中的操作的调用/call/create/A对象创建B对象而产生依赖/类建模接口/在模型中引入接口 接口是一个或多个操作特征标记，以及零个或多个属性的定义。在理想状态下，接口定义了一组内聚的行为； 接口由类或组件实现。要实现某个接口，类或组件必须包括一些方法； 使用接口有助于增加设计过程的灵活性、可扩展性和可插拔性（多态，代码只和接口打交道）； 接口是多重继承的一种替代方案/类建模接口（续/插座线表示法 window1使用Timer接口 它持有必要的接口/Window1/Timer/Interface Timer/Clock1实现并提供Timer接口/依赖线表示法 Wi

13、ndow2在于Clock2对象协作时，依赖于Timer接口/Clock1/Clock2/棒棒糖表示法 指明Clock3为客户实现并提供了Timer接口/Clock3/Timer/Window3/Window2/插座线表示法 Window3在于Clock3对象协作时，依赖于Timer接口/类建模聚合和组合/能用单句规则来验证其合理性：“一个对象是另一个对象的一部分”或者“一个对象被另一个对象所包含”； 交互的大部分是从整体到部分的； 在适当的时候要使用组合，但是可以忽略聚合 在某一时刻，部分的实例只属于一个组成实例 部分必须总是属于组成 组成要负责创建和删除其部分（如果组成被销毁，其部分也必须被

14、销毁，或者依附于其他组成/组合表示/组合意味着： 在某一时刻，部分实例(square)只能是一个组合的一部分(Board) 组合必须管理其部分的职责，尤其是创建和删除/在UML中，用带有实心菱形箭头的关联线来表示组合，箭头指向其组成类/约束/UML约束是对UML元素的***或条件。用之间的文本表示/显示UML约束的三种方式/限定关联/限定关联具有限定符，限定符用于从规模较大的相关对象***中，依据限定符的键选择一个或多个对象（暗示基于键对事物进行查找） 要注意多重性的变化（多变1/单实例类/模版类和接口/模版化类型，也称为模版、参数化类型和泛型 如代码： public class Board pr

15、ivate List squares=new ArrayList()//模版类和接口/参数化或模版接口和类 K是模版参数/List/ArrayList/Board/ArrayListSquare/属性类型可以用正式的UML表示，例如使用箭头的模版绑定语法/例如/elements属性是类型为T的数组，在实际使用前要进行参数化和绑定/这里存在某种可能性，即UML2的“箭头”符号可能最终被其它符号代替，例如“/用户自定义的分栏/主动类/主动对象运行于自己控制的执行线程之上/interface Runable/Clock/主动类/类建模为属性建模/把private可见性赋给所有属性； 仅通过set方法

16、更新属性； 仅通过get方法直接访问属性； 始终调用属性的set方法对其进行更新，即使在该属性被定义的类中也是如此； 在属性的set方法中，实现简单的验证有效性的逻辑； 在分离出来的方法中，实现复杂的验证有效性的逻辑； 但是在类图中不描述这些简单的存取方法/类建模为方法建模/指明方法的可见性、名称、参数、返回值及构造型； 为了减少类之间的耦合，要尽可能地***方法可见性。 方法命名方式采用动宾结构： printMailingLabel 静态方法有下划线，实例方法没有； 对于初始化方法（创建和构造函数），在DCD中可以忽略/类建模为方法建模（续/为方法写标题文档 方法做了什么；所有的错误条件和方法

17、抛出的异常；方法适用的前提和后置条件； 为方法写内部文档 控制结构；代码完成的功能、以及为什么要完成这些功能；局部变量说明；比较难或者比较复杂的代码；处理顺序。 注：方法的内部文档是类的详细设计/设计类图包含的内容/1、设计类图：定义了软件类的规格说明和应用程序接口。 1）类、属性和方法 2）接口 3）继承 4）类之间的关联和导航 5）类、接口等元素之间的依赖关系/交互图和类图之间的关系/当我们绘制交互图时，在此动态对象建模的创造性设计过程中会产生一组类及其方法/交互图中的消息表示类图中的操作/交互图中的确定的类要在类图中加以声明/如何建立设计类图/建立设计类图的输入 交互图：识别软件类和类中

18、的方法 概念模型：在类的定义中添加细节（如属性/如何建立设计类图（续/1）、通过分析交互图，识别出所有参与软件解决方案的类； （2）、将他们在一个类图中绘出； （3）、复制概念模型中的相关概念的属性到类图的类中，并为属性建模； （4）、通过分析交互图来为类图中的类添加方法； （5）、为属性和方法添加类型信息； （6）、在类图中添加关联，以支持必要的类之间的可见性； （7）、在关联上添加导航箭头，来指明属性可见性的方向； （8）、添加依赖关系连线，来指明非属性的可见性/1-3步带属性的类图/添加方法/每一个类的方法都可以通过分析交互图得到/添加方法(续/发送给多对象的消息 可以被解释为发送给一个

19、容器/***对象本身的消息/Find消息被发送给容器对象而不是一个ProductSpecification/添加关联和导航/导航是角色的一个属性，表示从一个源对象沿着关联可以单向地到达一个目标类。 导航意指可见性通常是属性可见性/Register currentSale：Sale endSale（） enterItem（） makeNewSale() makePayment(/Sale date isComplete time becomeComplete() makeLineItem() makePayment() getTotal(/1/1/Captures/P219 图19-8/添加关联和导航（续/类图中的关联来自于分析所有交互图的结果 类图中的关联和领域模型中的关联并不确切一致 需要哪些关联来满***互图所示的可见性和不间断的存储需要？ 下面是需要定义从A到B带导航修饰关联的常见情况： A发送一个消息给B A创建一个B的实例 需要维护到B的一个连接/添加关联和导航（POS/Register/事实上，一个对象的创建者要求拥有一个与它所创建对象的不间断连接。暗示的连接将因此被表示成类图中的关联/A创建一个B的实例/Store/Register/ProductCatalog/Pr