面向对象与UML学案

面向对象与UML学案在软件分析与设计阶段，建立模型是软件工程中最常用的技术之一。

本章主要学习面向对象的建模方法。

UML是一种图形化的OO建模语言，可以帮助我们进行软件系统的面向对象建模。

第1课时面向对象基本概念2.能说出面向对象的基本特征。

3.能回答面向对象开发的优点。

自学1.面向对象＝对象+类+继承+通信2.对象是客观世界中实体或概念在计算机中的表示。

一个对象是具有唯一对象名和一组属性和操作的集合。

其中属性表示该对象的静态特征，操作描述对象的动态行为。

3.类是一组相似对象的共性抽象，是创建对象的有效模板。

使我们可以把类作为软件中的基本复用单元，提高其内聚度，降低其耠合度。

面向对象中的（）机制是对现实世界中遗传现象的模拟，通过该机制，基类的属性和方法被遗传给派生类。

A 封装B 多态C 继承D 变异2. 判断下列是对象还是类：我的小汽车（）人员（）刘云坤（）交通工具（）教授（）井大计算机科学系（）中国工人（）清华大学（）韩国（）喷气式飞机（）3. 下列属于面向对象的要素的是（）A 分类性B 抽象C 共享D 封装4.对象实现了数据和操作的结合，使数据和操作（）于对象的统一体中。

A 结合B 隐蔽C 封装D 抽象5.面向对象软件技术把类组织成一个层次结构系统，一个类的上层可以有父类，下层可有子类，这种结构的一个重要性质是（），一个类获得其父类的全部描述。

B 继承性Ｃ复用性Ｄ并行性OO开发在支持软件重用上的优势？提示：可从面向对象的基本特点，及软件设计的模块化与模块独立性来分析。

第2课时UML简介1.能说出UML的中英文对应意义及UML与面向对象建模的关系。

2.能说出UML的基本特点。

P833.能说出UML模型中视图和图的关系。

P82重点：视图与图1.UML——unified modeling language,统一建模语言，是一种基于面向对象的可视化的建模语言，其特点有：提供了统一标准的面向对象的模型元素的定义和表示法（ISO/IEC 19501），可视化的表达和语言扩展机制，使它可应用于各种复杂系统的建模。

2.不同的系统建模视角称为视图，视图由一组图构成。

表2-1 UML中的基本图1.模仿表2-1建立UML中视图与图的关系表。

2.补充完整表2-1中内容。

1.用于描述对象模型的工具是（）A 数据流图B 结构图C 状态图D 对象图2.在UML中，描述系统与外部系统及用户之间交互的图是（B ）A 类图B 用例图C 对象图D 协作图第3课时UML静态建模1.能说出UML的静态建模机制2.会运用UML的静态建模图形符号建立简单系统（如学生选课系统，图书管理系统，公司进销存系统）的用例模型。

3.会运用UML的静态建模机制建立上述2中简单系统的类和对象模型。

一. 用例图和用例模型：用例模型反映系统能做什么，描述软件系统和外部参与者（actor）之间的交互，由一组用例图及相应的规约组成。

其中，用例(use-case)代表，参与者表示。

用例图基本符号：边界、用例、参与者和关联。

（P84图4.8）用例间的关联关系：.用例除了与其参与者发生关联外，还可以具有系统中的多个关系，这些关系包括包含关系、扩展关系和泛化关系。

1 包含关系（ Include ）要点：1) 一个用例可以简单地包含其它用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这称作包含关系。

2) 如果两个以上的用例有大量一致的功能，则可以将这个功能分解到另一个用例中（作为包含关系的提供者用例）。

3) 一个用例的功能太多时，可以用包含关系建模两个或多个用例。

表示方法：在 UML中，包含关系表示为带 <<include>>字样虚线箭头，箭头指向被包含的用例。

如如P85图4.11及图1所示。

示例：图1 用例间的包含关系示例2 扩展关系（ Extend ）要点：1) 一个用例（扩展用例）可以被定义为基础用例的增量扩展，这称为扩展关系。

2) 一般基础用例的执行不会设计到扩展用例，只有特定的条件下扩展用例才被执行。

3) 扩展关系为处理异常或构建灵活的系统框架提供了一种十分有效的办法。

表示方法：在 UML中，扩展关系表示为带 <<extend>>字样虚线箭头，箭头指向被扩展的用例（即基础用例）。

如P85图4.10，下图2，注意箭头的方向。

图2 用例间的扩展关系示例Use Case之间的关系，绝大部分书籍一带而过，大概是因为很简单。

但是却是在实际应用中争论和疑惑较多的问题之一。

UML 2.2官方规范说明用例之间有两种关系：包含（ include），扩展（ extend）。

说明：1.在我们的教材上大家看到《使用》关系（ <<uses>>），这见于较早版本的 UML中，以前的 <<uses>>和 <<includes>>被现在的 <<include>>取代，可以将之理解为<<include>>关系。

2. 在实验室的机器上安装的Rose环境下，大家还看到 Generalization（泛化关系），该关系在官方规范中未明确说明，但是偶尔会有人讨论 Use Case之间的 Generalization关系。

有常用面向对象用例建模的人认为：需要在 Use Case间使用 Generalization关系的场景很少。

本着“简单”和“沟通”的原则，忘记它吧！包含（ include ）关系为用例建模提供了从两个或更多的 Use Case的描述中抽取通用部分的能力。

所以，在描述 Use Case之前就开始抽取包含用例是不可取的；再有，如果没有两个以上的 Use Case来包含这个 Use Case，那么这个抽取是毫无意义的。

扩展（ extend ）关系提供了使用另外的可选流程来补充或插入到一个已存在的 Use Case中的能力。

因此，这是一种能够扩展原 Use Case却不用对原来的 Use Case进行重新描述的方法。

这两种关系在实际应用中究竟应如何区别有时会很难把握，建议可以根据如下特征来区分。

包含关系：1. 对基用例来说，如果缺少了被包含用例则是不完整的。

即，被包含用例是基用例不可缺少的一部分。

2. 被包含用例对基用例是可见的，即基用例知道被包含用例的存在。

3. 被包含的用例通常应被两个以上的其他用例所包含，否则应该考虑一下是否应该使用包含。

例子：校内网（ ）中，“查找好友”可能为“发送消息”和“删除好友”所包含。

扩展关系：1. 如果去掉扩展关系，基用例仍然完整。

2. 扩展用例本身具有独立的功能，而非从其他用例抽取出来的。

3. 基用例对扩展用例是可见的，而扩展用例对基用例不可见。

也即，基用例不知道有扩展用例的存在。

Kurt Bittner 等在《 Use Case Modeling》给出了可能需要使用扩展用例的几种情况：l 描述一些对系统的基本功能来说是可选的特性。

例如，可能是一些由系统提供甚至可从第三方购买的一些可选的系统特性。

l 描述一些可能使主流程变得很晦涩难懂的、十分复杂的错误或异常处理过程。

例如，有些分支流程巨长，尤其是比主流程还长。

l 为一些特殊顾客定制的需求。

l 由于范围管理和发布管理的需要。

例如，有些系统特性或行为在后来的发布中才会包括，那么在后来的项目中可以用扩展用例来对系统功能进行扩展。

例子：收邮件时，忘记密码了，需要找回密码。

“找回密码”对“收邮件”来说是个扩展用例。

注意：如果在有些情况下你仍然觉得很难决定应该使用<<include>>还是<<extend>>，那么停止纠结，就用<<include>>吧（因为包含比扩展更容易让人懂，而扩展比包含更容易让人懵，:-)）！“错”就“错”了，总比无谓的浪费时间好。

最后， Use Case之间不要随便搞“关系”。

很多人喜欢把 Use Case图画得很玄乎，关系搞得很复杂！很不幸，方向错了。

Kurt Bittner 等的《 Use Case Modeling 》中说：If there is one thing that sets teams down the wrong path, it is the misuse of the use-case relationships include ,extend and generalization . Alistair 在《编写有效用例》中也十分强调， Use Case 真正有价值的是 Use Case 描述，所谓的用例间的关系往往价值不大还会适得其反。

1.画出简化的文本编辑程序的用例图，该编辑程序的主要功能有：建立文件、打开文件、插入文本、修改文本和保存文件。

2.超市进销存系统的需求描述如下：（1）销售①售货员接收顾客订购，输入顾客购买的商品，计算总价；②顾客付款并接收清单；③售货员保存顾客购买商品的记录清单。

（2）库存①库存管理员每天进行盘点一次；②库存管理员当发现库存商品有损坏时，及时到相关部门报损；③在供应商的商品到货时，库存管理员首先检查商品是否合格，并将合格的商品入库处理；当商品进入卖场时，进行商品出库处理；④经理、订货员根据需要进行库存商品的模糊查询或详细查询。

（3）订货①订货员用新商品供应商信息更新供应商数据库的信息；②订货员统计库存商品是否低于库存下限，然后制作订货单。

（4）统计①经理能够使用系统的统计功能，了解商品销售情况、库存情况、供应商情况，以便进行合理的营销策略。

②经理按市场情况适时变动商品价格。

试建立超市进销存系统的用例模型。

3.（）是从用户使用的角度来描述系统功能的图形化表示方法。

A 类图B 对象图C 序列图D 用例图并没有展示出如何提供服务，如服务的具体功能、处理流程、场景、出错情况以及异常情况等信息，如何能知道前述信息？同组同学讨论与评价各自的能力测试结果。

二、类/对象图与类和对象模型1.类图▪类图是描述类、接口、协作及它们之间关系的图。

▪显示系统中各个类的静态结构。

基本符号如图3：图3 类图的基本符号由图3可知，类属性语法：可见性(+,-,#)属性名：类型=默认值{约束特性}其中，可见性有public(+),private(-),protected(#)，类型表示该属性的数据类型。

操作(方法)语法：可见性操作名 (参数表)：返回类型{约束特性}2. 类图中可能的元素有：①类（Class）②接口（Interface）---操作③协作（Collaboration）④依赖关系（Dependency）⑤泛化关系（Generalization）⑥关联关系（Association）⑦实现关系（Realization）3．类间特殊关系（除关联关系外）：泛化（“is a kind of” ）关系及主要用途：图4 泛化关系示例■聚焦（“has a”）关系■组合关系4.对象图可以被看作是类图在某一时刻的实例，描述参与一个交互的各个对象在交互过程中某一时刻的状态。