第5章 类图和对象图-4

图5.16 派生属性
图5.17 派生关联
5.4 抽象类和接口
抽象类是不能直接产生实例的类。 因为抽象类中的方法往往只是一些声明， 而没有具体的实现，因此不能对抽象类实 例化。 抽象类可以含有属性，某些方法可以有具 体的实现。
Athlete
斜体
Swimmer
Golfer
5.4 抽象类和接口
图5.18 接口的3种表示方式
5.4 抽象类和接口
Printer CheckStatus
Printer
<<Interface>>
CheckStatus
5.5 版型
版型是UML的3种扩展机制之一(UML中的 另外两种扩展机制是标记值和约束)。 版型是建模人员在UML中已有的基本构造 块(事物、关系、图)上派生出的新构造块。 这些新构造块是和特定问题相关的，是在 已有元素上增加新的语义，而不是增加新 的文法结构。
PurchasedItem
CreateMarketingCampaign
DirectEmail
练习
<<boundary>>
MarketingCampaignForm
<<control>>
CreateMarketingCampaign
<<entity>>
<<entity>>
<<entity>>
PurchasedItem
SavingAccount
练习
□ 在线营销系统中，管理人员可以在系统中 创建营销活动并将活动信息以邮件形式发送 到购买产品的顾客的邮箱中。请标出以下类 的版型（boundary, control, or entity）及类之 间的关联关系。
MarketingCampaignForm
Customer
See p.65
5.8 领域分析
领域特征和 项目规划 1 plan1.1: 1 2 3 ? 1
plan1.1: 1 领域分 析过程 数据收集 2 2 3 数据分析 3 分类
2 3
4
5 ?
4 plan1.4: 1
领域模 型评估 2 3
5
plan1.2: 1
建立数 据目录
文献 检查
2
获取专 业知识
3
建立 分类 方法
1
分类 结果 描述
2
构造 词汇 表
3
领域选择 和描述
1
确定领域范 围和边界
2
风险 分析
3
标识实体、事件、 操作、关系等
1
信息模块化
2
数据的相 似性分析
3
数据的可变 特性分析
4
分析结果 的综合 2
5
plan1.3.2:1 or 2 plan1.3: 功能分 解方法 1 OO分析 方法 2 5 1
3
4
5.9 OO设计的原则
Actor1 Use Case1
Actor2 Boundary Class
图5.23 多个参与者使用同一个边界类
5.6.2 实体类
实体类用于保存要放进持久存储体(如数据库、 文件)的信息。 实体类可以通过事件流和交互图发现，实体类 通常用领域术语命名。 通常每个实体类在数据库中有相应的表，实体 类中的属性对应数据库中表的字段。但实体类 和表不是一一对应的。
5.7.2 构造类图
下面给出建立类图的步骤： （1）研究分析问题领域，确定系统的需求。 （2）确定类，明确类的含义和职责，确定属 性和操作。 （3）确定类之间的关系。把类之间的关系用 关联、泛化、聚集、组合、依赖等关系表达 出来。 （4）调整和细化已得到的类和类之间的关系， 解决诸如命名冲突、功能重复等问题。 （5）绘制类图并增加相应的说明。
5.5 版型
UML中预定义了一些版型，如接口是类的版 型，子系统是包的版型等。 如图5.20所示是带有操作的Actor的例子。
<<Actor>>
Actor2 Actor1 Icon形式 Label形式
Actor3
Decoration形式
图5.19 Actor的3种表示方式
图5.20 Actor及其操作
接口是类的<<interface>>版型。 UML中的接口不包括属性（Java中的接口 可以包含属性），只包含方法的声明并且 声明的所有方法都没有实现部分。
<<Interface>>
Interface2 Interface Icon形式 Label形式
Interface3
Decoration形式
练习
5.8 领域分析
In software engineering, domain analysis is the process of analyzing related software systems in a domain to find their common and variable parts. It is a model of wider business context for the system. 建立类图的过程就是对领域及其解决方案的分析和设 计过程。 类的获取是一个依赖于人的创造力的过程，有时需要 与领域专家合作，对研究领域进行仔细分析，抽象出 领域中的概念，定义其含义及相互关系，分析出系统 类，并用领域中的术语为类命名。
□ 对于OO设计，主要是要求系统的设计结果要能适应系 统新的需求变化，一旦需求发生变化，整个系统不用 做变动或做很少的变动就可以满足新的需求。 下面是OO设计的几条原则： ① 开闭原则（Open/Closed Principle，OCP） ② Liskov替换原则（Liskov Substitution Principle，LSP） ③ 依赖倒置原则（Dependency Inversion Principle，DIP） ④ 接口分离原则（Interface Segregation Principle，ISP）
5.9.1 开闭原则
开闭原则指的是一个模块在扩展性方面应 该是开放的，而在更改性方面应该是封闭 的。 在设计时要有意识地使用接口进行封装， 采用抽象机制，并利用多态技术。
5.9.1 开闭原则
5.9.1 开闭原则
□图5.28的设计：系统运行时，Output类根据当前与系统
相连的是哪种类型的打印机而分别使用不同类的print() 方法。如果增加新的Legend打印机不但要增加新的 Legend类，还有修改Output类的内部结构。
5.6.1 边界类
□ 边界类位于系统与外界的交界处，窗体 （form）、对话框（dialog box）、报表 （report）以及表示通讯协议（如TCP/IP） 的类、直接与外部设备交互的类、直接与外 部系统交互的类等是边界类的例子。
图5.22 边界类的3种表示方式
5.6.1 边界类
通过用例图可以确定 需要的边界类。 每个actor/use case对至 少要有一个边界类， 但并非每个actor/use case对都要生成唯一边 界类。
Customer
DirectEmail
练习
一个牛奶公司想自动化订单和付款. 每个送奶员出发时都有 带着他要送的奶产品和客户的订单。按照他清单上的客户 地址检查需要的产品。客户(customer)都有长期订单（ standing order）。如果客户想临时改订单，则被称为一 个异常订单（exception order），例如 “今天多加1 pint奶”, “周四6个酸奶”. 牛奶公司时常会有一些促 销产品，这些促销产品的订单称为促销订单(promotion order)。所有订单(order)都由每个订购产品(product)对 应的订单行（order line）组成。周五送奶员到每个客户 家里收钱(payment)。 画出类图。尝试使用关联、聚集、泛化、多重性。
5.5 版型
用户可以自定义版型 （e.g. <<include>>）。
比如可以定义<<hardware>><<software>>描述电梯 控制系统的类 图5.21：用<<GUI>>这个版型说明 ManagementWindow是一个专用于图形界面的类。 这样不仅表示这个类是用于处理GUI的，还可以用 Rose的脚本语言做某些操作，如检索出所有版型为 <<GUI>>的类，并输出这些类的类名。
Fra Baidu bibliotek
5.7.2 构造类图
CRC分析法：
5.7.2 构造类图
在构造类图时，不要试图使用所有的符号。UML中大 约20%的建模元素可以满足80%的建模要求。 构造类图时不要过早陷入实现细节： 如果处于分析阶段，应画概念层类图； 当开始着手软件设计时，应画说明层类图； 当考察某个特定的实现技术时，则应画实现层类图。 对于构造好的类图，应考虑该模型和模型中的元素 是否真实地反映了应用领域的实际情况 是否有清楚的目的和职责 大小是否适中，对过于复杂的模型和模型元素应将 其分解成几个相互合作的部分
<<GUI>>
Management Window
图5.21 自定义版型
5.5 版型
Stereotype « button» CancelButton state
Stereotype in form of icon

CancelButton
5.6 边界类、控制类和实体类
UML中有3种主要的类的版型，即边界类、 控制类和实体类。 在进行OO分析和设计时，如何确定系统中 的类是一个比较困难的工作，引入边界类、 控制类和实体类的概念有助于分析和设计 人员确定系统中的类。
图5.29 打印输出设计2
5.9.2 Liskov替换原则
□ Liskov替换原则指的是子类可以替换父类出现 在父类能出现的任何地方。
图5.30：类A要使用类B，运行时，用类C代替类B，则类A 仍可以使用原来类B的方法。设计时可以把ClassB设计 为抽象类（或接口），让ClassC继承抽象类，而ClassA 只与ClassB交互，运行时ClassC会替换ClassB,这样可以
练习
画出类图，表示出电视机类(TV)和频道类 (Channel)之间的关系。 提示：电视机（TV）类有打开（turnon)、关闭 （turnoff）、换频道（change）等操作。
练习
画出类图，表示出账户类、支票账户类、 储蓄账户类之间的关系。请将账户类表示 为抽象类。
Account
CheckingAccount
5.2.4 依赖关系
假设有两个元素X、Y，如果修改元素X的定义 可能会导致对另一个元素Y的定义修改，则称 元素Y依赖于元素X。 如一个类向另一个类发送消息，或者一个类是 另一个类的数据成员类型，或者一个类是另一 个类的操作的参数类型
图5.15 依赖关系
5.3 派生属性和派生关联
派生属性 可以从其他属性推演得到的属性。 派生关联 可以从其他关联推演得到的关联。 指明某些属性和关联是派生属性和派生关联 有助于保持数据的一致性。
图5.24 实体类的3种表示方式
5.6.3 控制类
控制类是负责其他类工作的类。 每个用例通常有一个控制类，控制用例中的 事件顺序，控制类也可在多个用例间共用。 其他类并不向控制类发送很多消息，而是由 控制类发出很多消息。
图5.25 控制类的3种表示方式
5.7 类图
在软件开发的不同阶段使用的类图具有不同的抽象层次。 概念层类图描述应用领域中的概念。画概念层类图时， 很少考虑或不考虑实现问题。 说明层类图描述软件的接口部分。这个接口可能因为 实现环境、运行特性或者开发商的不同而有多种不同 的实现。 实现层类图才真正考虑类的实现问题，提供类的实现 细节。
Circle
概念层 说明层 实现层
5.7.2 构造类图
□ 寻找类的一些技巧包括：
根据用例描述中的名词确定类的候选者。 使用CRC分析法寻找类。CRC是类（class）、职责 （responsibility）和协作（collaboration）的简称， CRC分析法根据类所要扮演的职责来确定类。 根据边界类、控制类和实体类的划分来帮助发现系统 中的类。 对领域进行分析，或利用已有的领域分析结果得到类。 参考设计模式来确定类。 根据某些软件开发过程（如RUP）提供的指导原则进 行寻找类的工作。
图5.28 打印输出设计1
5.9.1 开闭原则
图5.29的改进设计：Output中有类型为Printer的变量p.不 管与哪种打印机相连，输出都调用p.print()。P的具体 类型在运行时由系统决定。 如果增加Legend打印机只 需增加Legend类，并让Legend类实现Printer接口即可， 不需改动Output类内部。