UML笔记

uml基础与应用（第0讲） 2

课程内容 2

参考教材 2

uml概述 2

内容提纲 2

面向对象技术（第一部分） 3

模型与可视化建模 4

什么是uml 4

uml发展历史 5

软件过程 6

UML工具（第1讲） 6

UML的构成 7

UML示例(第3讲) 11

UML在软件开发各个阶段的应用 11

面向对象技术（第4讲） 12

内容提纲 12

面向对象技术的基本原则 12

面向对象技术的基本概念 13

举例：订单销售(第6讲) 15

面向对象技术的发生与发展历史 15

面向对象语言的特点 16

uml的各种图 16

用例图(第8讲) 16

类图和包图（第10讲） 19

行为图(活动图和状态图)( 第14讲) 22

Rational rose简介 25

交互图（第18讲） 29

协作图 30

顺序图和协作图举例 30

小结 30

部署图和构件图（第20讲） 30

RUP（Rational Unified Process）(第22讲) 32

内容提纲 32

RUP介绍 33

RUP的思路：implementing Best Practices 33

RUP的基本特征 35

RUP软件开发生命周期 36

RUP带来的观念变化 37

小结 38

设计模式与UML（第24讲） 38

如何成为象棋高手？ 38

如何成为一个软件开发工程师？ 38

什么是模式？ 38

为什么学习模式？ 38

模式和框架的比较 39

设计模式研究的历史 39

关于“Design Pattern” 39

重提：指导模式设计的三个概念 40

如何描述一个模式 40

设计模式分类 40

案例学习（第26讲） 43

autoweight系统 43

案例：图书馆信息系统(第28讲) 45

案例：课程登记(第30讲) 48

uml示例 61

uml基础与应用（第0讲）

课程内容

1。uml概述

2。uml的构成

3。面向对象技术

4。uml的各种图

5。Rup

6。设计模式

7。案例学习

uml在需求、分析、设计、实现、集成、交付、测试、阶段的应用

参考教材

1。张维明主编《信息系统建模》，北京，电子工程出版社，2002

2。Grady Booch;James Rumbaugh ;lvarJacobson编《uml用户指南》，北京机械工业

出版社，2001

3。JLWhiteen等编《系统分析与设计方法》北京；机械工业出版社，2004

4。Blaha&Rumbaugh编《UML面向对象建模与设计》，北京：人民邮电出版社，2006

uml概述

内容提纲

1。面向对象技术

2。模型与可视化建模

3。什么是uml

4。uml发展历史

5。软件过程

6。uml工具

7。uml的构成

8。uml示例

9。uml在软件开发各个阶段的应用

面向对象技术（第一部分）

*面向对象技术

-面向对象技术出现于20世纪70年代末，是软件工程领域的重要技术

-是一种程序设计方法

-是一种对现实世界中问题的抽象方式

-对面向对象建模技术的研究的主要成果就是同意建模语言uml

面向对象技术表

现实世界

由事物组成

事物之间有共性，可以归纳

事物具有静态特性和动态特性

事物存在联系，需要交流

事物是一个独立的实体

客观世界中的事物存在继承关系，用来简化对事物的认识和描述

复杂事物可以看成由多个简单事物组成

不同的事务收到同样的消息时，所产生的行为不同

面向对象技术

用对象来描述事物

类是具有相同共性的抽象描述

用属性和方法描述事物的静态特性和动态特性

消息、方法

封装性

继承性

聚合关系

多态性

软件质量衡量指标

*外部

1。正确性（Correctness）

2。健壮性和可靠性（Robustness and reliability）

3。性能（Performance）

*内部

1。模块性（Modularity）

2。灵活性和可扩展性（Flexibility and Extensibility）

3。可复用性（Reusability）

4。可兼容性（Compatibility，via atandard/uniform interfaces）

面向对象技术意义

*面向对象技术提高了软件质量

图23:59

模型与可视化建模

为什么要建模？

*建立大厦和建立茅草屋的区别在于：建立茅草屋不需要设计。

*要生产合格的软件就要有一套关于体系结构、过程和工具的规范

什么是建模

*模型

-模型是对现实的简化。就是把复杂系统变成小的系统，采用“逐个击破”的原则逐一解决

为什么要可视化建模

-一幅图顶不上千言万语（A Picture is worth a thousand words）

模型的组成

*模型是用来描述现实系统的，一般由下列几个部分组成：

-系统：即描述的对象

-目标：系统的目标

-组分：构成系统的各种组分或子系统

-约束条件：系统所处的环境及约束条件

-变量：表述各组分的量的变化，它分内部变量（系统内部）、外部变量（系统外部和环境）

及状态变量。

-关系：表述不同变量之间的数量关系。

模型的表示

*模型可以用一个6元组表示：

*M=（O、G、T、V、R、S），其中

-O表示模型的对象集；

-G表示模型的目标集

-T表示模型系统所处的环境及约束条件集

-V表示模型的变量集，包括内部变量、外部变量及状态变量；

-R表示模型变量之间的关系集

-S表示模型的状态集，从初态到终态。

建模的原理

*分解

*抽象

*泛化

*投影视图

*构件化

*形式化

什么是uml

*UML（Unified Modeling Language）统一建模语言是用来设计软件蓝图的可视化建模语言。

*它支持面向对象系统的分析、设计、实现和交付等各个环节，可以用于系统的理解、设计、

浏览、维护和信息控制。

*在著名的Booch方法、OMT方法、OOSE方法基础上，广泛民主的反战而成。

*于1997年11月被OMG组织正式采纳。

*uml不是一个程序设计语言

*uml不是一个形式化语言

图36：51

uml发展历史

1.1994年10月，Rational公司的Booch和Rumbaugh决定将其Booch方法和OMT方法综合成

一个新的建模语言，并于1995年10月公布Unified Method 0.8

2.1995年秋季，Jacobson及其OOSE（面向对象软件工程）方法加入Rational公司，决定将

OOSE方法与Unified Method 进行综合，更名为uml，并分别于1996年6月和10月公布了uml

0.9和uml0.91。

3.1996年，DEC、HP、I-Logix、Itellicorp、IBM、ICON、MCI、Microsoft、Oracle、Rational

TI、Unisys发起成立了uml成员协会，于1997年1月推出了uml1.0，并向OMG申请将其作为一种标准语言

4.1997年9月产生了uml1.1,11月被OMG正式采纳。

5.1999年6月OMG发布了uml1.3。

6.1999年7月，uml RealTime 随Rose RealTime推出

7.2001年9月，OMG发布了uml1.4

图40:00

软件危机的主要特征

1。软件开发周期大大超过规定日期；

2。软件开发成本严重超标

3。软件质量难以保证。

*美国国家总申请局，在1993年，对所有交付给政府的项目进行了研究发展，只有3%的项目可以按时交付

，且质量过关，49%项目不可用，48%交付后必须经过重新修改，才能使用。

*在大公司中，IT项目平均成本超支1.78倍，进度超支2.3倍

*项目交付后，平均42%的原始需求能在最后铲平中得以实现。

软件开发面临的问题

1。不能满足用户或商业的要求

2。不能很好的定位需求

3。模块难于集成

4。到最后才发现错误

5。对于终端用户来说质量较差

6。负载时性能差

7。没有协调团队的能力

8。不断地修改-发布问题

软件过程

*uml是一种建模语言，在实际软件项目中，要和具体的软件开发过程结合起来才能更好的发挥作用。

图44:28

*软件过程

-美国CMM TSP PSP

-ISO9000系列

-RUP（统一软件过程）

-XP（极限编程）

统一软件过程RUP

*Rational Unified Process（RUP）是Rational公司开发和维护的过程产品，是目前影响较大

的、面向对象的软件开发过程。

*RUP的三个特点

-用例驱动

-以架构为中心

-采用迭代和增量

图46:02

*统一软件过程框架

-RUP人为：一个软件产品开发过程应该包括多次循环。每个循环包含四个阶段：

#初始：

#细化：

#构造：

#移交：

-每个阶段又包括多个迭代过程。

*RUP迭代式开发

图48:18

*RUP软件开发生命周期

图48：54

UML工具（第1讲）

*主流UML工具

-Raiional Rose

-Together

-Mircrosoft Visio

什么是Rational Rose

*Rational Rose 是一种工具，它可以在Rose建模中提供建立、视图、修改和操作组件的能力

*Rose运行环境

-WindowsNT，Windows95

-UNIX（Solaris，HP/UX，AIX，DECUnisx）

*Rose支持Unified、Booth、OMT标记法

Rational Rose界面

图00：55

课程登记实例的Use Case图

图03:50

小结

*什么是UML

*UML发展的历史

*RUP

回顾：UML

*UML是一种可视化的面向对象建模语言。

*UML描述了一个系统的静态结构和动态行为。UML用图形方式表现典型的面向对象系统的

整个结构

*UML从不同的角度为系统建模，并形成系统的不同视图。这些图包括：类图（它以继承结构、

关联、组成和聚集为特色）、时序图、协作图和状态图等。

UML的构成

UML的结构（UML概述第二部分）

*UML的基本构造块

-UML中的事务

-UML中的关系

-UML中的图

*UML的规则

*UML中的公共机制

-规格说明

-修饰

-通用划分

-扩展机制

UML的基本构造块

UML的主要包括3种构造块（Building Blocks）

1）事务（Things）：

构成模型图的一些基本图示符号，他们表示一些面向对象的基本概念。

2）关系（Relationships）：

表示基本图示符号之间的关系。

3）图（DLagrams）：

特定的视角对系统所作的抽象描述

事物是对模型中最具有代表性的成分的抽象：关系把事物结合在一起：图聚集了相关的事务

UML中的事务（Things）

结构事物：1。class2。interface3。collaboration4。use Case5。Active Class 6。Components

7。Notes

行为事物：1。Interaction 2。Static Mechanism

分组事务：1。Package

注记事物：1。Notes

结构事务

1）类（class）

-类是对一组具有相同属性、方法、关系和语义的对象的描述，一个类实现一个或多个接口。

图17:10

2）接口（interface）

-接口描述了一个类或构件的一个服务的操作集，忌口仅仅是定义了一组操作的规范，它并没有

给出这组操作的具体实现。

图18:58

3）协作（collaboration）：

-协作定义了一个交互，它是由一组共同工作以提供某协作的角色和其他元素构成的群体，这些协作

行为大于所有元素的各自行为的总和。因此，协作有结构、行为和维度。一个给定的类可以参与几个协作。

图21:55

4）用例（use Case）

-用例是对一组动作序列的描述，系统执行这些动作将产生一个对特定的参与者（actor）有价值且可观察的结果

5）主动类（active class）

-是这样的类，其对象至少拥有一个进程或线程，因此它能启动控制活动

图23:11

6）构件（component）

-构件是系统中物理的、可替代的部件，它遵循且提供一组接口的实现。

图23:34

7）节点（node）

-节点是在运行时存在的物理元素，它表示了一种可计算的资源，它通常至少有一些记忆能力处理能力，一个构件集可以驻留在一个节点内，也可以从一个节点迁移到另一个节点。

图25:13

行为事物：

-行为事物是UML模型的动态部分。他们是模型中的动词，描述了跨越时间和空间的行为。共有两类主要的行为事物。

1）交互（interaction）

-交互这样的一种行为，他由在特定语境中一共同完成一定特定任务的一组对象之间交换的消息组成。一个对象群体的行为或单个操作的行为可用一个交互来描述。

-Interaction涉及一些其他元素，包括消息、动作序列（有一个消息所引起的行为）、links（对象间的连接）

图26:11

2）状态机（State machine）

-状态机是这样一种行为，描述了一个对象或一个交互在生命周期内响应时间所经历的状态序列。单个类或一组类之间协作的行为可以用状态机来描述。一个状态机涉及到一些其他元素。包括状态转换（从一个状态到另一个状态的流）事件（发转换的事物）和活动（对一个转换的响应）。

图26:45

分组事物

-分组事物是UML模型的组织部分，最主要的分组事件是包（package）

-包是把元素组织成组的机制

图28:07

*包是UML中唯一的组织机制

*包可以拥有其他元素，这些元素可以是类、接口、构件、节点、协作、用例和图，甚至可以是其他包

*一个包形成了一个命名空间。在一个包中同一个元素的名称必须是唯一的。不同种类的元素可以有相同

的名称

注释事物

*注释事物是UML模型的解释部分。这些注释事物用来描述、说明和标注模型的任何元素。有一种主要的注释事物，称之为注解（note）

*注解（note）是一个依附于一个元素或一组元素之上，对它进行约束或解释的简单符号。

图31:53

UML中的关系

在UML中有4种关系：

*关联Association

*依赖Dependency

*泛化Generalization

*实现Realization

图32:34

*Association（关联）：描述了两个或多个类之间的结构性关系。

图36:01

*泛化是一种特殊/一般关系，特殊元素（子元素）的对象可替代一般元素（父元素）的对象。用这种方法，子元素共享了父元素的结构和行为。

图38:18

*依赖

图41:55

*实现是类元之间的语义关系，在该关系中一个类元描述了另一个类元保证实现的契约。

图44:24

举例：UML中的关系

图45:44

UML中的图（第2讲）

*UML包括9种图

图50：13

*UML表示机制的层次结构：

1。用例图

2。类图

3。行为图

3.1.状态图

3.2活动图

3.3交互图

3.31序列图

3.32协同图

4。实现图

4.1组件图

4.2部署图

1、用例图

用例图（use case diagrams）：用来描述用户的需求，从用户的角度描述系统的功能，并指出各功能的执行者，强调谁在使用系统，系统为执行者完成哪些功能。

2、静态图

-类图（class diagrams）：用于定义系统中的类，包括描述类的内部结构和类之间的关系。类图主要用于描述系统的静态结构

-对象图（object diagrams）：对象图是类图的一个实例，描述了系统在具体时间上所包含的对象以及各个对象之间的关系。

3、行为图：用来描述系统的动态模型和对象之间的交互关系，包括：

-状态图（statechart diagrams）：用来描述类的对象所有可能的状态以及事件发生的状态转移条件。

-活动图（activity diagrams）：用来描述满足用例要求所要进行的活动以及活动间的约束关系，使用活动图有利于识别系统的并行活动。

-交互图：用来描述对象之间的交互关系，包括：

*序列图（Sequence diagrams）：描述对象之间的交互顺序，着重体香对象间消息传递的时间顺序，强调对象之间消息的发送顺序，同时也显示对象之间的交互过程。

*协作图（collaboration diagrams）：描述对象之间的合作关系，更侧重于说明哪些对象之间有消息的传递

*序列图和协作图可以互相转化。

4、实现图

-构件图（component diagrams）：构件图用来描述代码构件的物理结构以及各构件之间的依赖关系。一个构件可以使一个资源文件、一个二进制文件或者一个可执行文件。

-实例图（deployment diagrams）：部署图定义了系统中硬件的物理体系结构，用来描述实际的物理设备以及它们之间的连接关系。

UML中的规则

不能简单的把UML的构造块按随机的方式放在一起。像任何语言一样，UML有一套规则，这些规则描述了一个结构良好的模型看起来应该像什么。

*UML有用于描述如下事物的语义规则

#命名为事物、关系和图起名

#范围给一个名称以特定含义的语境

#可见性怎样让其他人使用或者看见名称

#完整性事物如何正确、一致地相互联系

#执行运行或模拟动态模型的含义是什么

UML的公共机制

UML中有4种贯穿整个语言且一致应用的公共机制：

#规格说明

#修饰

#通用划分

#扩展机制

规格说明

*UML不只是一种图形语言。实际上，在它的图形表示法的每部分背后都有一个规格说明，这个规格说明提供了对构造块的语法和语义的文字叙述。

*UML的图形表示法用来对系统进行可视化：UML的规格说明用来描述系统的细节。

*UML的规格说明提供了一个语义底版，它包含了一个系统的各模型的所有部分，并且各部分相互联系，并保障一致。因此，UML图只不过是对底版的简单视觉投影，每一个图展现了系统的一个特定的方面。

修饰

*UML表示法中的每一个元素都有一个基本符号，可以把各种修饰细节加到这个符号上

例子：图40:35

通用划分

*类/对象二分法（class/object dichotomy）

-类是一个抽象：对象是这种抽象的一个具体形式。

-UML的每一个构造块几乎都存在像类/对象这样的二分法。例如：用例和用例实例（场景），构件和构件实例，节点和节点实例等。

*接口/实现二分法（interface/realization dichotomy）

-接口声明了一个契约，而实现则表示了对该契约的具体实施，它负责如实的实现接口的完整语义

-几乎每一个UML的构造块都有像接口/实现这样的二分法。

例如：用例和实现它们的协作，操作和实现它们的方法。

扩展机制：对UML图示符号的扩展。包括：

-构造型Stereotype-标注值Tagged value-约束Constraint

图43:01

UML示例(第3讲)

显示“Hello world”的简单java applet程序

——代码图（00:35）

*类

图07:04

*类的关系

图09:42

*继承层次

图18:22

*包

图20:54

*序列图

图25:18

*构件图

图27:07

UML在软件开发各个阶段的应用

*在软件开发各个阶段，使用不同的UML图对系统进行描述

*采用面向对象技术设计软件时，使用用例图来描述用户需求：使用类图、对象图、包图、构件图和部署图这5种静态突来描述系统的静态结构：使用顺序图、合作图、活动图和状态图这4种图描述系统动态行为。

*需求

-采用用例图来描述需求（角色、功能、外部交互）。

*分析：明确解决问题的细节

-采用类图来描述静态结构

-采用顺序图、合作图、活动图、状态图来描述动态行为

*设计：给出解决方案

-采用类图、包，对类的接口进行设计

*实现：

-将类用某面向对象语言实现

*集成与交付：

-构件图、包、部署图

*测试

-单元测试使用类图和类的规格说明书

-集成测试使用类图、包、构件图和合作图

-系统测试使用用例图来测试系统功能

小结

*UML的结构

*UML在各个阶段的应用

面向对象技术（第4讲）

内容提纲

1。面向对象技术的基本原则

2。面向对象技术的基本概念

3。举例

4。面向对象技术的发展历史

5。面向对象程序设计语言

面向对象技术的基本原则

*抽象（Abstraction）

*封装（Encapsulation）

*模块性（Modularity）

*层次性（Hierarchy）

什么是抽象

*一个购买商品应用情景的抽象

图06:39

什么是封装

*对客户隐藏实现

-客户仅仅看到接口

图07:43

什么是模块化

图11:56

什么是层次

图12:53

面向对象技术的基本概念

*对象-object

*类-class

*属性-attributes

*操作-operation

*接口-interface（polymorphism）

*组件-components

*包-package

*子系统-subsystem

*关系-relationships

什么是对象

*范畴广泛，例如：

#物理实体

#概念实体

#软件实体

*对象描述一个事物，它具有：

-状态

-行为

-标识

对象的状态

*对象的状态可改变

图20:12

对象的行为

*行为反映了一个对象将如何响应其他对象

图21:58

对象的标识

图23:30

对象的表示

图24:33

什么是类

*类是对一组具有相同属性、行为、关系和语义的对象的描述

*一个对象是一个类的实例

类的举例

图28:36

类的表示

图32:04图33:40

对象的种类

*多少种对象

类和对象的关系

*类是对象的抽象定义

-它定义了属性和方法

-它提供了一个创建对象的模板

图36:52

类的实例

图38:42

什么是属性

图40:25

什么是操作

图42:18

什么是多态(第5讲)

图00:00

什么是接口

图02:30

什么是组件

一个组件可以是以下之一

1。源程序

2。运行时动态库

3。可执行程序

图11:00

组件图示例

*可视化源代码之间的依赖关系

图12:22

什么是包

图15:42

什么是子系统

图19:04

对象间的关系

1。john是mary的爸爸

2。Mary是tom的姐姐

3。Bob是mary的狗

4。mary是Bob的主人

5。ann是john的雇员

6。john是ann的雇主

7……

*关联

#聚合

#组合

*依赖

*泛化

*实现

关联关系

图21:56

整体-部分关系

图26:00

举例（窗口）

图26:42

举例（菜单）

图27:16图27:50

聚合

图28:15

组合

图31:22

比较

图32:30

依赖关系

*using

图39:18

泛化关系

Is-a-kind of

图39:47

泛化关系举例图40:21图41:13

单重继承图42:18

多重继承

图43:44

继承到了什么

图45:02

举例：订单销售(第6讲)

图03：40图09:33

当应用需求发生改变？

图17:38

面向对象技术的发生与发展历史

图18:21

面向对象技术的产生与发展

*object-oriented languages and coding1956~1983

*object-oriented design methods1989

*Frameworks and design patterns1994

*Unified modeling language（UML）1995

*communication and Middleware1996

*Software Components 1997

*Aspect Oriented Programming1999

*Role Oriented Programming1999

*Real-Time and OO1999

*Agent and Moblie Agents2000

面向对象语言的特点

*继承性

*封装性

*多态性

C++相关知识点图37:39(第7讲)

例子

java相关知识点图03：12

例子

uml的各种图

用例图(第8讲)

内容提纲

*什么是用例图

*用例图的基本元素

-角色

-用例

-关系

*用例图的图符

*用例图的主要属性

*用例图的粒度与范围

*举例

UML视图

4+1视图

UML中用5个互联的视图来描述系统的体系结构

图47:06

用例模型

*用例模型用于需求分析阶段，表明开发者和用户需求规格达成共识。

-用例模型描述了待开发系统的功能需求

-用例模型将系统看成黑盒子，仅从外部执行者的角度来理解系统

-用例模型驱动了需求分析之后各个阶段的开发工作。

什么是用例图

*用例图（use-case diagrams）

-用来描述用户需求，从用户的角度描述系统的功能，并指出各功能的执行者，强调谁在使用系统，系统为执行者完成哪些功能。

*用lvar jacobosn在开发AXE系统中首先使用。

用例图的构成

*用例

*角色

*关系：执行者与用例之间的关系，包括：

-依赖

-泛化

-关联

图54:26

什么是Actor？

*Actor是一些人或事：

-可以激活系统交互信息

-可以对系统进行输入

-可以从系统被动的接受信息

*通过调查发现Actor

-直接使用系统的人

-系统的维护人员

-系统使用的外设

-需要与此系统相连的其他系统

图57:17

角色

*寻找执行者的几个原则

-谁使用系统的功能？

-谁需要系统支持日常工作？

-谁来维护关系系统？

-系统需要操纵哪些硬件？

-需要与系统交互的其他系统?

-对系统产生的结果感兴趣的人或物。

*按照角色寻找

用例

*用例表示：

图1:07:09

用例图的泛化关系

图01:09:45

用例图图符

*系统

*用例

*执行者

*关联

*包含

*扩展

*注释

*注释连接

图01:09:55

用例图的主要属性（第9讲）

*事件流

*前置条件

*后置条件

*特殊要求

*扩展点

*问题说明

*事件流

-描述一个用例在执行时执行者与系统之间的交互过程。这个过程包含多个分支

#基本流

-对用例中常规和预期路径的描述

#备选流

-由于受到其他因素的影响，用例执行了其他的路径。

*前置条件

-是该用例执行的前提条件，用来描述在什么条件下可以开始执行一个事件流。

*后置条件

-说明用例结束时系统的状态

*前置条件和后置条件可以用于用例的验证和评审

用例图的粒度与范围

*概述级

*用户目标

*子功能级

图05:30图11:03图12:07图15:15

一个高层用例图举例（1/2）

图19:38图22:53

举例

*参看教材第27也学生选课系统

-图2.20用户需求描述

-图2.21学生选课系统的执行者

-图2.22学生选课系统

-图2.23系统用图

-图2.24学生选课系统用例图

-图2.25“选择课程”用例描述文档

-图2.26学生选课系统非功能性需求

用例注意点

*应该清晰的定义系统边界

*防止用例过多

*应该从执行者的角度来命名用例

*用例描述正规程度

*避免执行者的名字不一致

*避免执行者和用例之间的关系太复杂

*注意用例的大小是否恰当

*避免用例描述混乱

*区分用例分解和功能分解

*避免客户不能理解用例的情况发生

*有些场合，用用例图描述需求是不合适的

小结

*用例图的基本组成

*用例图的作用

-重在应用

-重在交流

-重在事件流的描述

类图和包图（第10讲）

内容提纲

1。类

2。类的关系

3。类图的构成

4。类图深入讨论

5。类图的应用

类

图03:20

*属性

图08:49

*操作

图10:33

类的表示

图12:01图15:40

类图的关系

1。关联

#普通关联

#聚合

#组合

2。依赖

3。泛化

4。实现

关联

*普通关联

#关联名

图24:03

应用于关联的修饰

1）名称（Association name）：用以描述该关系的性质。

2）角色（Role）：当一个类处于关联的某一端时，该类就在这个关系中扮演了一个特定的角色；角色是关联中靠近它的一端的类对另外一端的类呈现的职责。

图27:26

3）多重性（Multiplicity）：关联角色的多重性是说明一个关联的实例中有多少个相互连接的对象。

图30:09

关联举例

图32:58

关联

-单项关联（导航关联）

-双向关联

图37:24

-两个类之间可以有多种关联

-一个类可以和多个类关联

图40:22

自身关联

图40:45

*聚合

-“整体/部分”

-空心菱形

图42:25

图46:16

*组合（第11讲）

图00:44图02:38

比较

图05:22

关联类

*两个对象之间的连接（Link）本身可以拥有自己的属性和行为，如果把连接看作是一个类的实例，则该类称为关联类

图11:38图13:38

自身关联

*一个对象可以与另一个同类的对象有连接（Link），即类可以与自身有关联。

图14:45

依赖关系

*依赖是一种使用关系。它说明一个事物规格说明的变化可能影响到使用它的另一个事物。但反之未必。

图16:05

-使用

图19:43图21:22图23:30

泛化

*is-a-kind-of

图25:40

泛化关系

图28:37图32:40图32:50

单重继承

图35:11

多重继承

图38:17

实现关系

*实现是类元之间的语义关系，在该关系中一个类元描述了另一个类元保证实现的契约

图42:24

实现

图43:45

例子图45:11图45：20

类图的构成（第12讲）

*用来描述系统的静态部分

*类图的构成

图01:44

例子图03:45

类图深入讨论

*可见性（visibility）

*范围（scope）

*操作（operations）

*模板类（template classes）

实用类（utility classes）

可见性

图25:10

*public：+

*protected：#

*private :-

*package:~

图31:52

范围

*每个实例自己拥有自己的属性和方法

*静态成员：对一个类的所有实例共享一个成员

图33:44图37:23图41:50

抽象类(第13讲)

*不能实例化

图00:27

root，leaf类

图03:41

多重性

图06:15

例子图10:12

属性

图11:00

操作

图16:09

类图的应用

举例图19:04

包图

*包的作用

-逻辑上把一个复杂的图模块化

-组织源代码

*包的图符

图40:50

*包中的元素

-类、接口、构件、用例、其他包等

-若包被撤销，则其中的元素也被撤销了。

包与包之间的关系

*泛化

*细化

*依赖（常用）

-如果两个包中的任意两个类之间有依赖关系，则这两个包之间有依赖关系

图42：32

包的常见问题

1。一定要避免循环依赖产生

2。测试时可以以包为测试单位

3。应该尽量把概念和语义上相接近的的元素包含在同一个包中。

4。对于一个包，找出那些包内的元素是可以在包外访问的，把这些元素标记为共有的，其他所有元素都标记为受保护的或者私有的。

对象图

*对象图描述一个系统在某个具体时刻的静态结构。而类图描述所有可能的情况。

对象图构成

*对象图包含以下元素：

-对象

-连接

-包

图44:00

对象图44:54

行为图(活动图和状态图)( 第14讲)

内容提纲

-什么是活动图

-活动图的几个基本要素

-泳道Swimlanes

-活动图的主要作用

行为模型

*系统建模，需要从系统结构和行为两个方面来描述，其中系统的行为是通过状态图、活动图、序列图和协作图来描述的。

*本次课介绍状态图和活动图

活动图

*流程图常被用来建立算法模型，使用流程图可以表示一个算法的执行序列、过程、判定点分支和循环。

*活动图与流程图十分类似，不同之处在于它支持并行活动。

*活动图的缺点：很难清除的描述动作与对象之间的关系，没有交互图直接。

活动图作用

*活动图的作用

-描述一个操作的执行过程中所完成的工作或者动作。

-描述对象内部的工作

-显示如何执行一组相关的动作，以及这些动作如何影响周围对象。

-描述用例的执行

-处理多线程应用

*以下场合不使用活动图

-显示对象这样的合作

-显示对象在其生命周期内的运转情况。

活动图04:36

活动图的基本要素

*活动状态Action State

*活动状态之间的转移transitions

*判断decisions

-一种表示判断决策的特殊活动

*保证条件guard conditions

-只有保证条件为真时转移才发生

*同步条synchronization bar

-一种表示活动之间的同步的特殊活动。

*起点和终点

-起点有且只有一个，终点可有一个或多个。

活动图的图符

*起始状态

图12:00

*终止状态

图12:30

*状态迁移

图12:52

*决策点

图13:12

*同步条：表示活动之间的同步

图14:23

*泳道：用于活动图中的活动进行分组，用于描述对象之间的合作关系。

图15:26

-所谓泳道技术，是将活动用线分成一些纵向区域，这些纵向区域称为泳道。每个区域代表一个特定类，或者人，或者部门的责任区。泳道技术是活动图中引入的一种面向对象机制。可为提取类及分析各个对象之间的交互提供方便。

图19:46

活动图举例23:24

状态图

内容提纲（第15讲）

*状态图

-状态机State machine

-状态State

-转换transition

-子状态substate

-状态图

-状态图的例子

状态图

*状态图用来描述一个特定对象的所有可能状态以及由各种事件的发生而引起的状态之间的转移。

状态图的图符

*状态图的图符

-状态

-转移

-起点

-终点

图03:48

05:15

状态机

*状态机是这样一种行为，它描述了一个对象或一个交互在生命期内响应时间所经历的状态序列。

*单个类或一组类之间协作的行为可以用状态机来描述。

*一个状态机涉及到一些其他元素，包括状态、转换（从一个状态到另一个状态的流）、事件（触发转换的事物）和活动（对一个转换的响应）。

图05:33

状态

*状态是指在对象的生命期中满足某些条件、执行某些活动或等待某些事件时的一个条件或状态。

*一个状态有以下几个部分：

1）名称name

2）进入协作和退出动作 entry action或exit action

3）内部转换internal transition

4）延迟事件deferred event

图07:01

*特殊状态

-初始状态

-终止状态

图09:19

转换

*一个转换是两个状态之间的一种关系，表示对象将在第一个状态中执行一定的动作，并在某个特定事件发生而某个特定的条件满足时进入第二个状态。

*一个状态由5部分组成。

#原状态source state

#事件触发event trigger

#监护条件guard condition

#动作action

#目标状态 targetstate

图09:37

电话机状态图11:02

活动图和状态图区别

*状态图侧重从行为的结果来描述（状态）

*活动图侧重从行为的动作来描述（活动）

图13:46图15:10

小结

*状态图

*活动图

*在实际项目中，活动图并不是必须的。一般在以下情况需要使用活动图：

-描述一个并行的过程或者行为

-描述一个算法

-描述一个跨域多个用例的活动

*状态图描述了一个具体对象的可能状态以及它们之间的转换。

活动图例子18:32

状态图例子21:42

Rational rose简介

提纲

-讨论rose支持的不同视图

-列出每一种视图案的图形

-配置rose用户界面

什么是Rational rose

*Rational rose是一种工具，它可以在rose建模中提供建立、视图、修改和操作组件的能力

*rose运行环境

-Windows NT ，window95

-Unix（Solaris，HP或UX，AIX，DEC Unix）

*rose支持Unified、Booch、OMT标记法

什么是rose建模

*rose“建模”代表问题域和系统软件

-每一种模型都包含在建模中提供可视化组件和操作组件的视图、图形和规格说明书

*每一种基础元素有多种视图

-在rose“建模”中，每一个对象都被描述

-rose在“建模”中保证了一致的语义描述

Rational rose中的视图

*在rose中有四种视图

-use case视图

*包、Actor、use case、对象、消息和关系

-逻辑视图

*包、类、状态和关系

-组件视图

*包、组件和依附关系

-拓扑视图

*节点和关系

Use case视图（第16讲）

*在use case中的元素可以在多个图形中被浏览

*在use case视图中可以包含以下的图形

-use case图

*包、actors、use case和关系

-相互作用图（序列图或协同图）

*对象和消息

Use case图形

*use case图形描述了一个系统应该执行的什么或应该有什么外部系统

-它描述了存在的actors（外部系统）、use case（该系统应该执行什么）以及它们的关系

-use case图形可以描述该系统中部分或全部的use case

交互图

*交互图描述了系统在逻辑设计中存在的对象及其间的关系

-它可以代表系统中对象的结构

*rose中包含两种交互图，它们对同一交互操作提供了不同的浏览视角

-序列图

*按时间顺序排列对象交互操作

-协同图

*围绕对象及其间的链接关系组织对象的交互操作

逻辑视图

*在逻辑视图中的元素可以有一种或多种图形来表示

*逻辑视图可以包含以下的图形

-类图

*包、类和类的关系

-状态图

*状态、事件和转换关系

类图

*类图描绘的系统的静态视图

-它描述了系统逻辑设计中存在的包、类以及它们间的关系

-类图可以代表该系统中部分或全部的类结构

*在模型中有一些经典的类图

状态图

*状态图描述了：

-给定类的状态转换空间

-导致状态转换的事件

-导致状态改变的动作

*为类的重要动态行为建立状态转移图

组件视图

*组件视图中的元素可以在一个或多个组件图形中被浏览

*组件图形描述了在系统物理设计中组件中类和对象的分配情况

-组件图可以代表系统中部分或全部的组件结构

*组件图形描述了

-包

-组件

-依赖关系

拓扑视图

*在拓扑视图中的元素可以在拓扑图形中被浏览

-拓扑视图只能包含一个拓扑图形

*拓扑视图描述了一个系统在物理设计阶段进程处理的分配情况

*进程图描述了

-节点

-连接

Rose用户界面

*rose的组成

-标准工具条

-图形工具条

-浏览区

-文档窗口

-图形窗口

-规格说明窗口

-状态条

Rose标准工具条

*rose的工具条独立于当前打开的图形窗口界面

rose的浏览区

*rose的浏览区描述了原本的视图模型，并且提供了在每一种视图的组件间进行访问的功能

-“+”表示该图标为折叠图

-“-”表示该图标已被完全扩展开

*该浏览区可以

-可见或不可见

#位置有边界范围

-浮动

#可移动到任何位置

浏览区图25:00

固定浏览区26:00

文档窗口

*文档窗口为所选择的项和图形提供建立、浏览或修改文档的能力

*当不同的选项和图形被选择时，即允许一个文档窗口被更新

*文档窗口

-可视或被隐藏

-固定或浮动

可固定的文档窗口图27:05

配置用户界面

*rose用户界面可以被定制

-显示或不显示工具条

-从工具条上添加或删除按钮

-显示或不显示浏览窗口

-显示或不显示文档窗口

-使工具条、浏览窗口或文档窗口固定或浮动

rose选项

*一般选项

-字体、备份文件的使用、储存命令

*图形

-显示属性、操作、可视化、控制焦点、交互图序列号、未定义的注释、自动重设大小

*注释

-定义注释-UML，Booch，OMT

*工具条

-工具条显示与定制

*代码产生

-建立、修改、删除代码产生的性质设定

*数据定义语言

-建立、修改、删除数据定义语言产生的性质设定

练习：定制用户界面

*设置用户界面

-显示工具条

-显示浏览窗口和文档窗口

-显示状态条

-将图形和文档窗口字体设置为10号

-设置统一的缺省注释

-显示操作符号

-不显示属性

-不显示操作

-关闭控制焦点

-存储改变并且退出

举例（第17讲）

交互图（第18讲）

*交互图用来描述系统中的对象是如何进行相互作用的。即一组对象是如何进行消息传递的。

*交互主要用于描述协作的动态行为方面

*当对交互建模时，通常既包括对象（每个对象都扮演某一特定的角色），又包括消息（每个消息都代表对象之间的通信活动，并导致一定的动作发生）。

*可用两种方式描述：

-强调消息的时间顺序

-强调发送和接收消息的对象的结构组织

*交互图包括

-顺序图：强调消息的事件顺序

-合作图：强调对象之间的交互关系

交互（举例）

*一个程序片段

图04:16

*合作图

图07:04

顺序图

*顺序图

-顺序图描述按照时间的先后顺序对象之间交互动作过程。

*顺序图的构成

-对象

-消息：是对象之间的通信，可以是信号或者操作调用。

-生命线（激活）：表示在某段时间内对象是存在的。

消息

*几种消息形式

-call

-return

-send

-create

-destroy

图12:07

消息

*简单消息：表示简单的控制流

*同步消息：表示嵌套的控制流

*异步消息：表示异步控制流

*可以将一个简单消息和一个同步消息合并成一个消息。

图16:05

顺序图

*顺序图强调消息的时间顺序

图21:39

协作图

*协作图强调参加交互的对象的组织

图27:50

顺序图和协作图举例

例子

Create schedule的协作图（第19讲）

图00:32

Create course的协作图

图07:33

Creat course的顺序图

图13:00

Creat catalogue协作图

图18:14

改进的creat catalogue的协作图

图21:20

用例“借出书目”的序列图（没有预定的情况）

图26:16

小结

*顺序图

*协作图

*顺序图和协作图的关系

-二者在语义上等价

-二者可以互相转化

-二者侧重点不同

#顺序图侧重时间顺序

#合作图侧重对象之间的关系

部署图和构件图（第20讲）

实现图

*UML中大部分模型描述了逻辑和设计方面的信息

*实现图用来描述实现方面的信息

*它从系统的层次来描述：

-硬件的组成和布局

-软件系统划分和功能实现

*实现图包括：

-构件图

用来显示一组构件之间的组织与依赖关系

-部署图

用来描述系统硬件的物理拓扑结构以及在此结构上执行的软件

构件图

*构件图从软件构架的角度来描述一个系统的主要功能，如子系统、类、包、构件等。

*使用构件最重要的是复用

构件

*构件（component）是系统中遵从同一组接口且提供其实现的物理的、可替换的部分。

*每个构件能实现一定的功能，为其他构件提供使用接口，方便软件的复用

*构件举例：

-对象库、可执行体、com+、企业级java Bean

构件的类型

*构件是定义良好的接口实现单元，它可以是以下几种类型：

-源代码构件

源代码文件

-二进制构件

目标码文件、静态链接库、动态链接库

-可执行构件

可执行程序

-数据文件或文档

构件和类

*类表示逻辑抽象，而构件表示物理抽象。

*构件是其他元素的物理实现

*类可以直接拥有属性和操作，一般情况下，构件一般只拥有只能通过其他接口访问的操作

构件的特点

*构件的特点

-构件是物理的

-构件是可替换的

-构件是系统的一部分

-构件遵从一组接口并提供对一组接口的实现

构件图的构成

*构件图18:50

*接口

*关系

构件与接口

*构件与其对应接口之间的关系：实现（realization）

*构件与其他构件之间的关系：依赖（dependency）

*示出接口（exportinterface）：构件实现的接口

*引入接口（importinterface）：构件使用的接口

图至尾

部署图(第21讲)

*节点（Node）是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。一个构件集合一般来说位于一个节点，但有可能从一个节点转到另一个节点。

部署图07:00

系统和子系统

图22:30

小结

*实现图

-构件图

-部署图

RUP（Rational Unified Process）(第22讲)

内容提纲

*软件面临的危机

*RUP介绍

*RUP的思路：Implementing Best Practices

*RUP的基本特征

*RUP软件开发生命周期

*RUP带来的观念变化

*小结

软件危机的主要特征

*软件开发周期大大超过规定日期：

*软件开发成本严重超标

*软件质量难于保证

软件开发面临的问题

*不能满足用户或商业的要求

*不能很好的定位需求

*模块难于集成

*到最后才发现错误

*对于终端用户来说质量较差

*负载时性能差

*没有协调团队的努力

*不断地修改-发布问题

Rational统一过程（RUP）

*一个过程是指想要达到一个目标而采取的一组有序的步骤

*在软件工程中，目标是高效、准时地提交一个满足你的业务需求的软件产品

图12:44

RUP介绍

*RUP是Rational公司开发和维护的过程产品，是目前影响较大的、面向对象的软件开发过程。

*RUP提供了在开发机构中分派任务和责任的纪律化方法

*RUP的目标是能够在预定的进度和预算中，提供高质量的、满足最终用户需求的软件

*UML很大程度上是过程独立的，你可以将它运用于许多软件过程。

*RUP是一种特别适应于UML的生命周期方法

*RUP提供了一整套以UML为基础的开发准则，用以指导软件开发人员以UML为基础进行软件开发。

*RUP所提供的问题：

-有缺陷、无法预见结果的、高度依赖于个别“英雄”程序员、不可重复的开发过程：

-开发的软件难以适应用户的要求：

-在应对需求的变更方面无能为力：

-需要单调乏味和昂贵的测试流程

-项目中出现的严重缺陷发现的太迟

-开发的软件难以维护和扩充

*RUP使得开发团队成员将共享：

-同一个知识库

-同一个开发过程

-同一个开发视图

-同一种建模语言

图19:37

RUP的思路：implementing Best Practices

*RUP达到最佳实践的几种措施：

#迭代式开发

#管理需求

#使用构件架构

#可视化建模

#检验质量

#控制变更

图21:20

迭代式开发

Waterfall Development：Risk vs. Time

*延迟关键风险解决

*延迟和集中系统的集成和测试

*排除了早期部署

*经常导致较大的无计划的反复

图22:49

*迭代式开发的优点

#降低风险

#得到早期用户反馈

#持续的测试和集成

#适应变更

#提高复用性

图25:33

*迭代式开发示意图28:45

*迭代式开发详述

-迭代是一种技术，用来把功能传递到一系列连续的增量的完整版本

-每个版本都在一个特定固定的时间段被开发，该时间段称之为迭代

-迭代的成果是一个可执行产品的一个版本，是最终系统产品的一个子集

-通过多次迭代连续增加和精化系统，在每个迭代过程中逐步增加信息、进行细化。

-每次迭代都选择目前对风险影响最大的使用实例进行，以分解和降低风险。

*迭代开发特征：

-在进行大规模的投资之前就解决了关键的风险问题

-使得早期的用户反馈在初始迭代中就能出现

-连续进行测试和集成

-各个目标里程碑提供了短期的焦点（阶段性的中心）

-对过程的测量是通过对实现的评定（而不是仅仅是文档）来进行的

-可以对局部的实现进行部署

*风险分析

图37:42

*需求管理

图40:00

-需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法。

-确保能够：解决正确的问题，建立正确的系统。

-需求管理包括：

#提取、组织系统的功能和约束，并将它们写成文档：

#估计需求的变化并评估它们会产生的影响：

#跟踪需求的实现

-RUP的开发活动是用例驱动的（use case-driven）。它强调要在透彻理解提交的系统将如何被使用的基础上建造系统。用例和脚本的表示法用于编排从需求捕获到测试的过程流。并提供从开发到提交系统的可跟踪的线索。

图47:29

使用构架结构

*采用构件架构的优势：（第23讲）

-对体系结构进行自下而上的设计、实现和测试。

-用一种系统化的做法来定义好的体系结构

-采用定义明确的接口来使得变更有弹性

-采用现成的和通过逆向工程得到的构件。

-由高级别的用例来驱动

-易于直观上的理解

*采用构件架构

图02:08

可视化建模

-描述体系结构点和结构

-描述系统里的各个元素如何组合在一起

-保证设计和实现上的一致性

-保证没有歧义的沟通

图03:15

*质量检验：

*质量检验图05:07

-为每个关键模块创建测试用例并测试，从而保证所有的需求被正确的实现

-不可接受的应用性能和不能接受的可靠性对一个软件系统的影响同等重要

-验证软件可靠性，例如：内存泄露、性能瓶颈。

-对每一次迭代进行测试

控制变更

*管理哪些变更？

-控制、追踪和监控项目的所有变更，从而启动每次迭代。

-为每个开发者建立安全的工作空间

-对不同工作空间的改动提供隔离机制

-控制所有的软件制品：模型、代码、文档等。

*变更管理

图11:00

RUP的基本特征

*迭代式增量开发

*用例（Usecase-driven）驱动

*以软件体系结构为中心

*受控的迭代式增量开发：

-将软件卡发分为一系列小的迭代过程，在每个迭代过程中逐步增加信息、进行细化；

-根据具体情况决定迭代的次数、每次迭代延续的时间以及迭代工作流：

-每次迭代都选择目前对风险影响最大的用例进行，以分解和降低风险。

*用例驱动

-采用用例来捕获对目标系统的功能需求：

-采用用例来驱动软件的整个开发过程，保证需求的可跟踪性，确保系统所有功能均被实现：

-将用户关心的软件系统的业务功能模型和开发人员关心的目标软件系统的功能实体模型结合起来，提供一种贯穿整个软件生存周期的开发方式，使得软件开发的各个阶段的工作自然、一致地协调起来。

*以软件体系结构为中心；

-强调在开发过程的早期，识别出与软件体系结构紧密相关的用例，并通过对这些用例的分析、设计、实现和测试、形成体系结构框架；

-在后续阶段中对已形成的体系结构框架进行不断细化，最终实现整个系统

-在开发过程的早期形成良好的软件体系结构，有利于对系统的理解、支持重用和有效的组织软件开发

RUP软件开发生命周期

图17:02

*时间（Time）

-周期（Cycles）：一个RUP可以分为若干个周期

#阶段（Phases）：起始、演化、构造、提交

-迭代（lterations）：每个阶段进行若干次

*核心工作流（Core Workflow）

-工作流（Workflow）：对应特定的迭代的连续活动

#活动（Activites）：需求定义、分析、设计、实现和测试

-中间制品（Artifacts）：活动的结果

*RUP将一个周期的开发过程分为四个阶段：

-inception（起始阶段）-为项目建立一个业务案例。

-elaboration（细化阶段）-建立工程计划和合理的体系结构

-construction（构件阶段）-建造系统

-transition（提交阶段）-把系统提供给最终用户。

*在每个阶段中都有很多迭代。迭代代表一个完整的开发周期，从在分析中捕获的需求到实现和测试，产生一个可执行的项目发布版本。

*每个阶段和迭代都有一些风险缓解焦点，并以一个定义良好的里程碑结束。里程碑复审及时的提供一个评价点，评价关键目标是否得到满足，项目是否需要以任何方式被重新构造。

*起始阶段：

-意图：

#建立业务模型用例

#明确项目的范围

-结果：

#项目的实际要求

-初始用例模型和领域模型（10-20%完成）

#初始的业务案例，包括：

-成功准则

-风险评估

-所需资源评估

-显示主要里程碑进度表的阶段计划

-在初始阶段的最后，检查项目的生命周期目标，决定是否继续进行全范围的开发

*细化阶段：

-意图：

#分析问题域

#建立一个健全的，合理的体系结构基础

#明确搞项目中风险的元素。

#指定一个合理的项目开发计划

-结果

#用例图和领域模型（80%完成）

#一个可执行的体系结构和文档

#一个修订的用例图和风险评估

#一个针对整个项目的开发计划

*在这个阶段的最后，检查已经细化的系统目标和范围，体系统结构的选择以及主要风险的解决办法，并决定是否需要进行构造。

*构件阶段

-意图：

#迭代增量的开发一个完整的软件系统，该产品是准备提交给用户使用的。

-产品：

#完整的用例图和设计模型

#用户手册

#可执行代码

#开发文档

#每次迭代的评测标准

#改进的开发计划

*提交阶段

-意图：

#为用户安装部署软件

-产品

#可执行的程序

#改进的系统模型

#每次迭代的评测标准

#发出程序的描述和评测指标描述

#改进的用户文档

#改进的开发文档

*迭代和阶段之间的关系：

-每个阶段可以分解成多个迭代

-一个迭代是一个完整的开发循环，它将产生一个可执行产品的发布版本，这个版本构成最终产品的一个子集，然后迭代的得到最终系统

图28:50

模型与工作之间的关系

图30:41图31:44

RUP带来的观念变化

*更强的计划性：迭代开发意味着要有更强的预见性和计划性，阶段的划分、阶段内的迭代都需要仔细规划。这要求项目管理者承担更大的责任，而所换来的则是开发任务的具体化和可预见性。

*坦然面对迭代过程中一部分中间制品的推倒重来：不要恐惧这样的显示，由于迭代过程的细化和相应工具的支持，其影响是可以控制的。

*把软件放在首位：过分强调规格说明（问题空间的描述）的作用是不恰当的，因为用户所购买的是软件（解空间）而不是规格说明。在开发过程中，需求和规格说明都是允许变化的

*尽早进行困难的工作：强调与实现的关系密切，而将困难工作放在开发后期进行是十分有害的，会使开发后期突然遇到“集成地狱”而使开发过程失去控制。

*坦然面对中间制品的“不美观”：在一些迭代中产生的中间制品，虽然外观上不能令用户和投资者满意，但其作用和价值是完美的。这时，项目管理者要充当一个“意见缓冲区”，对外树立可信赖和讲信用的形象。

*加强开发过程监控与量化管理：项目管理者要注重对各种变化与扰动的测量与监控，应先示范，后发布文档，以使得开发人员信服。

小结

*RUP带来的观念变化，有可能影响到软件工程的许多基本概念，但还有待遇观察

*对软件开发过程的管理是为了更好地支持和促进软件开发，而不是制约软件开发。

*软件开发成功与否的标志，不只是开发出实现了用户需求的产品，而且还包含了时间、成本、对维护与扩充的支持等重要因素，因此需要开发过程的有效支持。

图43:07

设计模式与UML（第24讲）

如何成为象棋高手？

*第一步：学习基础的象棋知识

-棋盘布局，棋子名称等等

*第二步：学习简单规则

-攻击力度、走棋规则等

*然而，学习象棋还需要研究已有的棋局

-这些棋局包含一些模式，需要理解、记忆并运用这些模式。

*有成百中这样的经典棋局供学习

如何成为一个软件开发工程师？

*第一步：学习规则

-学习算法、数据结构、程序设计语言等等。

*第二步：学习原理

-学习结构化编程，模块化编程、面向对象编程等。

*然而，为了成为一个软件设计高手，你还需要学习一些经典的软件设计模式，理解、记忆并在实际项目中反复运用他们。

*有大量的软件设计模式供学习

什么是模式？

每个模式描述了一个问题，该问题反复在我们的周围出现，每个模式给出了对该问题的核心解决方法，因此，人们可以反复使用给解决方法解决类似问题

为什么学习模式？

模式帮助你学习他们成功的经验，从而避免失误。

模式和框架的比较

*模式（Patterns）支持软件结构和设计的重用

-抓住了特定领域中问题的成功解决方案中的静态、动态结构和相互之间的协作关系

-patterns与开发语言无关，但是建立在一定的环境基础上

-例如：经典MVC，Factory Method

*框架（Framework）支持细节设计和代码的重用

-framework是一组组件的综合，这些组件相互协作，为一类相关应用提供了一个可重用的框架结构

*两点结合起来，设计模式和框架有助于提高软件的质量

-比如：重用性，扩展性，性能，可维护性

*框架的Hollywood principle

-（“Don't call us ，we'll call you”）

*模式和框架的比较：

-设计模式比框架更抽象。

-和框架相比，设计模式是更小单元的架构元素

-从使用的广度来说，设计模式比框架更广，它与应用的相关性更小

设计模式研究的历史

*关于patten研究的历史

-A pattern language ，Christopher Alexander，1977

-“Advanced C++；programming styles and ldioms”，James copline，1992

-“design pattern ：elements of reusable object-oriented software”，GOF，1995

-“Pattern-Oriented Software Architecture：A System of patterns”（简称为“POSA”），GoV，1996

Gang of Four（GoF）

图26:45

关于“Design Pattern”

*对已有模式的整理、分类

*一套描述模式的词汇，可用于交流和文档化

*为软件设计总结了宝贵的经验，这些设计经验可以被重用，但不是简单的代码重用

*分类

-Creational Patterns

-Structural Patterns

-Behavioral Patterns

*在软件设计模式领域，起到先驱的作用

重提：指导模式设计的三个概念

*重用（reuse）：是目标

-两种重要的重用手段

#inheritance&composition

*接口与实现分离

-接口保持不变，分离带来灵活

-多态性（polymorphism）

*Decouple

-降低复杂性

如何描述一个模式

*关键要素

-模式名称

-问题，动机

-约束

-上下文

-解决方案

#结构（structure）

#参与者（Participate）

#协作（collaboration）

#实现（implementation）

-评测

-相关模式

-举例

设计模式分类

图42:06

创建型模式（creational patters）（第25讲）

*factory method

-本质：用一个virtual method 完成创建过程

*abstract factory

-一个product族的factory method 构成了一个factory接口

*prototype

-通过product原型来构造product，clone+prototype manager

*builder

-通过一个构造算法和builder接口把构造过程与客户隔离开

*singleton

-单实例类型，如何构造这个单个实例？如何访问这单个实例？

*finder

-把对象的获取过程与客户隔离开

*singleton模式为提供对象的单一入口提供了帮助。

*abstractFactory和FactoryMethod模式在功能上比较类似，都是用来处理对象的创建的，但应用在不同的层面上。

*Builder模式用来处理对象创建的细节，在两个工厂模式中都没有涉及到对象创键的具体细节，都是通过接口来返回一个给定类型的对象，而Builder模式则需要对创建一个给定类型对象的过程进行建模。这对创建复杂对象很有用，使得创建对象的算法独立于对象各个组成部分的创建。

*prototype模式使用原理机制，通过创建简单原型的拷贝来创建对象

结构型模式（structural Patterns）

*Adapter 、bridge、facade

-adapter用于两个不兼容接口之间的转接

-bridge用于将一个抽象与多个可能的实现连接起来

-facade用于为复杂的子系统定义一个新的简单易用的接口

*composite、decorator和proxy

-composite用于构造对象组合结构

-decorator用于为对象增加新的职责

-proxy为目标对象提供一个替代者

*flyweight

-针对细粒度对象的一种全局控制手段

行为型模式（behavioral Patterns）

*command

-用对象封装命令、使得命令可以被传递、记录、排队等

*lterator

-把对聚合体对象的访问封装起来

*observer

-建立起一对多的通信类型，特别适合于更新通知和事件模型

*strategy

-把一个对象或者类的某些行为封装到另一个单独的对象中

*visitor

-把对一个结构模型的操作单独组织到一个类中

*chain of responsibility

-请求的处理过程，沿着链传递，decouple发送方和接收方

*interpreter

-在类层次结构中，在特定环境的“interpret”过程

*mediator

-用一个mediator来decouple各同等单元

*memento

-在对象之外保存对象的内部状态

*state

-把一个对象的状态对立出来，动态可变换状态对象的类型

*template method

-在某类中定义算法的骨架，把某些细节延迟到了类中

*strategy、lterator、mediator、state、command

-用一个对象来封装某些特性、比如变化、交互、状态、行为、命令

*mediator、observer

-observer建立起subject和observer之间的松耦合连接

-mediator把约束限制集中起来-》中心控制

*command、chain of responsibility、interpreter

-command模式侧重于命令的总体管理

-chain of responsibility侧重于命令被正确处理

-interpreter用于复合结构中操作的执行过程

举例

命令模式

The command Pattern

Encapsulating invocation

将调用操作的对象与知道如何实现该操作的对象解耦

命令模式（command Pattern）

图12:44

*例1:

-玉皇大帝宣孙悟空上天

图19:23

*例2：

-假设要实现这样的一个任务：task schedule，也就是说，我想对多个任务进行安排，比如扫描磁盘，我希望他每个小时进行一次，而备份数据，我希望他半个小时进行一次，等等

-不希望作为taskschedule的类知道各个任务的细节内容，taskschedule应该只是知道task本身，而对具体的实现任务的西甲并不理会，因而在这儿，我们就需要对taskschedule和task进行解耦，将任务和具体的实现分离出来，这不正是command模式的用武之地吗？

图24:21

*例3

-在设计一般用途的软件的时候，在C或者C++语言中，用的很多的一个技巧就是回调函数（Callback）

-所谓的回调函数，意指先在系统的某个地方对函数进行注册，让系统知道这个函数的存在，然后在以后，当某个时间发生时，再调用这个函数对事件进行响应

-在C或者C++中，实现的回调函数方法是使用函数指针。

-但是在java中，并不支持指针，因而就有了command模式，这一回调机制的面向对象版本。

*例4

对象村小酒店订餐图29:35

适配器模式

*现实世界中充满适配器

*面向对象适配器

图32:35

Object and class adapters

图33:57

案例学习（第26讲）

autoweight系统

功能需求

*结合一个具体的实例来介绍在软件开发各个阶段中如何应用UML

*实施方法：

-实例：autoweight系统

-UML在软件开发的需求分析、设计、实现以及测试等各个阶段的应用

AutoWeight系统简介

*AutoWeight系统是一个自动称重系统的软件部分。该系统能够对移动天车运送的物料进行称重，然后把称量的重量和物料的编号等信息传送给计算机，并由相应的AutoWeight系统进行必要的计算、统计和报表打印。

autoweight系统设备连接示意图

04:09

天车的工作过程

图04:26

人员分类

*操作工人：负责操作天车的技术工人。主要工作为操作天车，包括吊运物料，使用仪表输入编号等与物料相关的数据。这些数据与重量数据一起通过称重仪表发送给系统。

*车间主任：一个车间生产负责人。负责查看与系统相关的工作，如负责查看当日的称重记录，查看统计报表等。

*操作员：负责使用计算机、打印机和AutoWeight系统，并负责软件系统的运行和维护以及打印报表。

*系统开发人员：负责开发AutoWeight软件系统的项目组成员。

用户需求

具体功能需求：

*操作工人

-输入数据的过程尽量简洁，按键次数越少越好，最好是自动实现或“一键”完成。

-能够处理吊运过程中的暂停情况。

-输入数据错误，可以进行修改。

*车间主任

-记录每次称量物料的重量和时间。

-记录每次称量物料的名称和操作工人。

-按月统计每种物料的重量

-按月统计每个操作工人吊运货物的重量

-称量数据能够上传到数据库服务器中

-系统能长期可靠运行

-称重数据能长期保存

*操作员

-显示每次称量物料的记录，不能出现数据阐述错误或丢失数据情况。

-打印各种统计报表

-系统能够方便的启动和运行

*系统开发人员

-系统扩展性良好。

-提供模拟仪表，能生产数据，方便系统开发、调试、安装。

用户需求分析

图22:06图27:50

用例模型

图36:16图39:11

用例描述（第27讲）

*“记录称重数据”用例描述

*AutoWeight系统非功能性需求

初步分析

*需求过程中的名词组

图02:00

*候选概念类

图04:33

*候选类

图07:24

*经过泛化处理得到的类

图09:16

详细分析

*仔细分析“发送”关系，可以发现，它与三个类AutoalMeter，WeightData、System都有关联，这种关联称之为三元关联。

图21:00

*WeightData类的关联

图23:30

*两个类的类图

图24:13

*autoweight系统的领域模型，模型中只给出了主要的类间关联，类的主要属性和方法。

图31:31

称重数据过程活动图

图32:57

顺序图

*前面讲述autoweight系统的用例模型，在这个模型中最主要的一个用例就是“记录称重数据”用例，下图描述这个用例的顺序图

图33:50

数据保存类图37:00

界面图

37:45

界面类图

图38:21

完整类图