统一建模语言UML(Unified Modeling Language)——学习笔记

面向对象分析设计(OOA/D)

• 课程目标：

  介绍如何将UML应用于UP过程

  介绍如何应用UML进行OOA/D

• UML不是OOA/D，也不是方法，它仅仅是一种图形表示法

• 如果不掌握对象思想，那么UML或任何case工具(Rose)将毫无意义

• 需要一种用于OOA/D的语言，这既是一种思考的工具，也是一种沟通的形式，因此，在OOA/D中应用UML

• 分析(analysis)——对问题和需求的调查研究

• 设计(design)——满足需求的概念上的解决方案

• 面向对象分析(object-oriented analysis)——在问题域内发现和描述对象

• 面向对象设计(object-oriented design)——如何定义软件对象以及它们之前如何协作以实现需求

快速开始的示例

• 骰子游戏：软件模拟游戏者投掷两个骰子，如果总点数是7则赢得比赛，否则为输。

• 过程：定义用例->定义领域模型->定义交互图->定义设计类图

• 定义用例(用例需求分析的一种工具，它是一些情节的描述)

  • 骰子游戏

    • 1、游戏者先请求骰子

    • 2、系统展示结果：如果骰子的总点数是7，则游戏者赢，否则游戏者输

• 定义领域模型(OOA)-识别问题中的概念，它是对真实世界领域中的概念和想像可视化，与现实的软件技术无关(比如java和c#)

  • 游戏者

  • 骰子

  • 骰子游戏

骰子游戏的领域模型

分配对象职责并绘制交互图(动态建模)

• OOD关注的是：软件对象的定义——职责与协作

定义设计类图(静态建模)

• 从领域模型以及交互图中获得启示，定义软件类，包括属性、方法等等

• 骰子游戏的局部设计类图实例如下：

什么是UML

• 标准定义：统一建模语言(Unified Modeling Language,UML)是描述、构造和文档化系统制品的可视化语言。

• UML是一个庞大的图形化表示法体系

• 应用UML的三种方式

  • 草图

  • 蓝图

  • 编程语言

• 学习UML要素

  • 表示法——图形

  • 过程——(UML与过程无关，但最好用于RUP)

  • 工具——(比如：Rational Rose)

UP过程与“瀑布”模型

UP与瀑布模型

• 什么是UP？

  • 软件开发过程(software development process)描述构造、部署以及维护软件的方式。统一过程(The Unified Software Development Process)是一种流行的构造面向对象系统的迭代软件开发过程。特别是，Rational统一过程(Rational Unified Process, RUP)是对统一化的详细精化，并且已经被广泛采纳。

• UP也可以引进其它方法中的有用的实践，比如极限编程(Extreme Programming, XP)。XP中的测试驱动开发(test-driven development)、重构(refactoring)和持续集成(continuous integration)。

迭代和增量式开发

什么是瀑布生命周期

• 试图在编程之前(详细)定义所有或大部分需求。

• 而且通常于编程之前创建出完整的设计

• 试图在开始前定义“可靠的”计划或时间表

UML概述

• UML包括：

  • 事物

  • 关系

  • 图

  • 扩展机制

• 事物

  • 结构：类、接口、构件、节点等等

  • 行为：交互(消息)、状态等等

  • 分组：包，子系统等等

  • 注释：注释

• 关系

  • 依赖、关联(聚合、组合)、泛化、实现

• 图

  • 用例图、交互图(顺序图、协作图)、类图、活动图、状态图等等

• 扩展机制：Stereotype、Tagged Value、Constraint

图的分类

• 静态建模

  • 类图

• 动态建模

  • 顺序表(协作图)

  • 用例图

  • 活动图

  • 状态图

• 学习的顺序是：

  • 从最重要的部分开始！

  • 类图->顺序图->用例图->活动图->状态图

重要的概念及图形表示法初步接触(1)

重要的概念及图形表示法初步接触(2)

Rational Rose

• Rational Rose是一种建模工具

• 用例视图

  • 需求分析阶段的利器

• 逻辑视图

  • 设计阶段、用例的实现

• 组件(构件)视图

  • 构件表示封装了其内容的系统模块；构件是相对独立的模块

• 部署视图

  • 表示软件元素在物理架构上的部署，以及物理元素之间的通信

需求分析与用例(用例图)

• 需求：就是系统(或者说项目)必须提供的能力和必须遵从的条件

• 需求分析的一种重要手段是：确定和编写用例

• 用例定义：

  • 用例是文本形式的情节描述，用于需求的发现和记录，用例会影响后续的OOA/D工作。

• 简单示例

  • 登录系统：管理员向系统提交用户名和密码，系统进行认证，系统向管理员显示成功登录信息。

• 参与者(actor)

  • 某些具有行为的事物，可以是人(由角色标识)、计算机系统或组织。例如收银员。

• 场景(scenario)是参与者和系统之间的一系列特定的活动和交互

  • 主成功场景和交替场景(或主路径和扩展路径)

• 用例(use case)就是一组相关的成功和失败场景的集合

• 系统边界

用例的目的与形式

• 用例，强调用户的目标和观点。

• 谁使用系统？它们使用的典型场景是什么？它们的目的是什么？

• 用例编写的形式：

  • 摘要——需求分析早期使用，通常用于主成功场景

  • 非正式——需求分析早期使用，可覆盖不同的场景

  • 详述——详细编写所有步骤各种变化

• 用例的名称应使用动词开头

• 编写用例的时候尽量使用行业的专业名称，而不是计算机专业术语

用例的编写

• 用例编号

• 用例名

• 用例描述

• 参与者

• 前置条件

• 后置条件

• 基本路径

• 扩展点

  2_1.
  2_1_1

• 补充说明

• 请参考文档示例的编写方法(大量用例实例)

如何发现用例

• 1、选择系统边界

• 2、确定主要参与者

• 3、确定每个主要参与者的目标

• 4、定义满足用户目标的用例，根据其目标对用例命名

• 这是的项目中如何发现用例

• 请遵循如下思维习惯：

• 调研需求是最先弄清楚有多少部门，多少岗位(参与者)，然后找到每一个岗位的业务代表，问他们类似的问题：你平时都做什么？(参与者目标)这件事是谁交办的？做完了你需要通知或传达给谁？做这件事你都需要填写些什么表格吗(用例)

用例关联及一些术语

• 用例彼此之间可能具有联系，比如：处理信用卡支付用例可作为处理销售，处理租金等常见用例的一部分、

• 注意：避免陷入用例关系的陷阱

  • 别花太多时间争论在用例图中如何关联用例，而不关注更重要的工作：编写用例文本。

• 包含关系——主要目的是避免用例文本的重复编写

  • 比如上面所说的：处理销售、处理租金等用例包含处理信用卡支付用例

• 扩展关系——可以将可选路径中的场景抽象为扩展关系(但通常都是不必要的)

• 泛化关系——两个或更多用例在行为、结构、目的等方面存在共性时，可使用泛化关系

销售经理能做收银员的所有事情(泛化)

• 1.财务管理系统

• 2.使用企业管理系统的人员

• 3.顾客，会计系统

• 商品搜索——搜索商品

• 进行商品搜索——搜索商品

• 进货管理——管理进货

• 结账功能——结账

• 2.会员输入用户名密码并向系统提交

• 3.系统验证用户名密码信息

类图

• 类图允许我们去标记静态内容及类之间的关系

  • 类的基本表示法

    • 名称

    • 属性(类型，可见性)

    • 方法(参数，返回值)

  • 接口的基本表示法

    • 圆形表示法

    • 构造性表示法

  • 包

  • 关系

    • 依赖(一个事物的变化影响另一个事物)

    • 关联(关联名、导航、角色、多重性、聚合、组合)

    • 泛化(extends)

    • 实现(implements)

类图的基本表示法

• 创建类图

• 创建类

• 添加属性和方法

类中方法的参数和返回值

• 类在类图中的的显示

• 类图中删除类

类图中删除类，类还存在，只是在当前这个类图中不存在，不显示

将类拖入类图继续使用

接口的基本表示法

• 创建接口
  
• 接口的基本表示法

图标表示法

装饰表示法

标签表示法

包

• 包可以用来表示层次结构(子系统)

• 包可以用来组织各种内容

• 创建包

• Stereotype

• 文档

依赖关系

用到什么就会依赖于什么

UserAction依赖于UserManager

除了类和类之间的依赖，还有包和包之间的依赖等。

必要性是画图的重要原则，虽然有依赖关系，但不一定要画出来，如果非要画出来，则应考虑不要影响图形的美观。

低耦合高内聚原则

低耦合：表示要降低和不稳定的其它对象之间的依赖关系

关联关系

• 关联名

• 导航性：从一个对象可以访问另一个对象

单向关联

双向关联

• 关联的角色名称

User的角色名称：是Document中的一个属性

• 关联的多重性

Student和Classess是多对一的关系

一个学生属于一个班级，不能判断学生和班级之间的关系

关联是双方的，一个学生属于一个班级，一个班级有多个学生，所以学生和班级是多对一的关系

1个Entity1和5个Entity2建立关联关系

Message和User建立receiver和send两个关系

Student创建类时，不需要在属性列表中将关联的Classes属性再列出来。

• 练习

建立一个树形结构的类图，要求从任意一个结点，既可以导航到它的父亲结点，也可以导航到它的孩子结点。

• 聚合与组合

聚合也是一种关联，表示一种从整体与部分的关系

组合是一种强聚合，表示整体和部分的生命周期是一致的

组合

by value相当于值，表示关系非常紧密，例如，建立窗口类必须建立title属性；by reference相当于引用，例如Student对象引用Class对象，删掉Studnet对象Classes对象还可以存在。

• 泛化与实现

泛化(extends)

实现(implements)

正向工程、逆向工程与MDA

• 正向工程：从UML图形生成JAVA代码

• 逆向工程：从JAVA代码生成UML图形

• 不要依赖于正向或逆向工程！仅是一种辅助手段。

• 画图的目的不是为了生成代码！

• 写代码的目的也不是为了生成图像！

• MDA

什么时候使用类图？

• 任何时候

• 类图是UML中最重要的图形

• 不要尝试使用类图描述的所有细节

• 保持类图的简单！

• 对概念建模(领域建模)

• 分析(分析类图)

  • 实体类(entity)(领域模型)：User

  • 控制类(control)：UserManager

  • 边界类(boundary)：UserAction

领域模型(分析模型)

• 领域模型是OO分析中最重要的和最经典的模型

• 领域模型(domain model)，也称为概念模型、领域对象模型、分析对象模型，我们在对项目进行分析的时候，往往会创建相应的领域模型。

• 领域模型包括：概念，关联，属性

JAVA项目开发三件宝：框架、模式(首先理解问题，其次是方案)、领域模型

• 为什么需要领域模型？

  • 理解关键概念和词汇

  • 逐步进入设计阶段(为进入设计阶段得到一些启示)

  • 现实世界与软件实现之间的过渡

• 如何创建领域模型？

  • 寻找概念类(名词短语、分析模式)

  • 绘制类图

  • 添加关联和属性

  • 属性的表示法

    • 普通数据类型表示为属性

    • 不要把复杂的领域概念建模为属性

请根据以下描述，画出相应的UML图：

神州六号飞船是神州飞船系列的一种(泛化)，它由轨道舱、返回舱、推进舱和逃逸救生塔等组成(聚合)；航天员可以在返回舱内驾驶飞船(依赖)，轨道仓则是航天员工作和休息的场所(依赖)。在紧急情况下，可以利用逃逸救生塔逃生(依赖)。在飞船两侧有多个太阳能电池翼(关联)，可以为飞船提供电能(方法)。

交互图(顺序图和协作图)

顺序图(sequence diagram)

• 顺序表是交互图的一种

  • 交互图还包括协作图

• 顺序图是强调消息时间顺序的交互图

• 协作图则是强调接收和发送消息的对象的结构组织的交互图

• 如何对动态方面建模

  • 所谓动态方面，即随时间的推移，一些对象被创建，属性值的改变，以及其中一些对象的销毁，对象之间的互相调用！

  • 对象

  • 对象生命线

  • 消息(实际上就是方法调用)

  • 对象的创建与销毁

UML活动图

什么是活动图

活动图(activity diagram)是UML的动态视图之一，用来描述事物活动对象的活动变化流程。

活动图的要素

UML状态图

什么是状态图

状态图的概念：状态图(statechart diagram)：用来描述一个特定对象所有可能的状态，以及由于各种事件的发生而引起状态之间的转移和变化。

一个机器的状态图

一个发货单的状态图

状态图的要素

智能卡的状态图

历史状态

电话机工作的状态图

GRASP与GOF(设计模型)