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
*质