UML完整复习资料(大学考试专用).doc

第一部分 基本概念
一．UML定义：UML（Unified Modeling Language）统一建模语言，是一种面向对象的建模语言，它的主要作用是帮助用户对软件系统进行面向对象的描述和建模（建模是通过将用户的业务需求映射为代码，保证代码满足这些需求，并能方便地回溯需求的过程），它可以描述这个软件开发过程从需求分析直到实现和测试的全过程。

二．软件工程生命周期：
需求捕获 à 系统分析与设计 à 系统实现 à 测试 à 维护
需求分析步骤：
获取需求---- >>分析需求---- >>描述需求---- >>验证需求

v 三
UML的统一：
根据应用需求à对不同建模语言对比à取其精华去其糟粕à求同存异à统一建模语言UML

四．UML的内容结构 ：
UML中的五种视图：

视图名称
视图内容
静态表现
动态表现
观察角度
1
用户模型视图
（用例视图）
系统行为，动力
用例图
交互图、状态图、活动图
用户、
分析员、
测试员
2
结构模型视图
（设计视图）
问题及解决方案
类图、
对象图
交互图、状态图、活动图
类、
接口、
协作
3
行为模型视图
（进程视图）
性能、可伸缩性，吞吐量
类图、
对象图
交互图、状态图、活动图
线程、
进程
4
实现模型视图

（实现视图）
构件、文件
构件图
交互图、状态图、活动图
配置、
发布
5
环境模型视图
（实施视图）
部件的发布、
交付、安装
配置图
(实施图)
交互图、状态图、活动图
拓扑结构 的节点

五．UML中的关系：
关系
功能
表示法
关联
类实例之间连接的描述

依赖
两个模型元素间的关系,对一个元素提供者）的改变可能影响或提供信息给其他元素

--------------------------à
泛化
更概括的描述和更具体的种类间的关系，适用于继承

实现
说明和实现间的关系

依赖：依赖是指一个类使用了另一个类，它是一种使用关系，描述了一个事物的规格说明的变化可能会影响到使用它的另一个事物（反之不一定）。最常见的依赖关系是一个类的内部使用到了另一个类的定义。
关联：关联关系是一种结构化的关系，指一种对象和另一种对象有联系。给定关联的两个类可以从其中的一个类的对象访问到另一个类的相关对象。
泛化：是一个较广泛的元素和一个较特殊元素之间的类元关系。较特殊的元素完整地包含了较广泛元素，并含有更多的信息。
实现：实现关系将一种模型元素（如类）与另一种模型元素（如接口）连接起来

第二部分 UML的几种基本图
一．类图： （Class Diagram）
类图是描述类、接口、协作以及它们之间的关系的图。用来显示系统中各个类的静态结构。
类包括：类名，属性，方法
类图包括：类，接口，协作（关系）
类图的建模过程：确定对象与类---- >>确定类的属性---- >>确定类的关系

二．对象图：（Object Diagram）
对象图表示在某一时刻一组对象以及他们之间的关系的图。

三．包图：（Package）
由包和包之间的关系构成，它是维护和控制系统总体结构的重要建模工具。
包：是一种分组机制，表示一个类图集合。
四．用例图：（Use Case Diagram）
用例图表述了一组用例、参与者以及他们之间的关系
用例模型包括：用例图和用例规约
用例规约包括：基本流和备选流
用例图包含：用例(Use Case) 参与者(Actor) 参与者之间的关系（泛化、包含、扩展）
参与者：系统外部的一个实体（可以是任何事物或人），它以某种方式参与了用例的执行过程
用例：是对一个系统或一个应用的一种单一的使用方式所做的描述，是关于单个活动者在与系统对话中所执行的处理行为的陈述序列。
用例模型中的关系：
1.包含：表示基础用例会用到被包含的用例
2.扩展：基础用例中定义了一个到多个扩展用例
3.泛化：多个用例共同拥有一种类似的结构和行为时，我们可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。
4.关联

泛化关系
包含关系
扩展关系

三种关系的区别：
ü 泛化侧重表示子用例间的互斥性；
ü 包含侧重表示被包含用例对Actor提供服务的间接性；
ü 扩展侧重表示扩展用例的触发不定性
用例图的建模步骤：
1.寻找参与者2.确定用例 3.分析关系4.细化用例规约 5.精化细化用例模型

五．时序图Sequence Diagram）
时序图包括：对象（Object）生命线 （Lifeline） 激活（Activation）消息（Message）
对象：对象代表时序图中的对象在交互中所扮演的角色
生命线：一条垂直的虚线，代表时序图中的对象在一段时期内的存在
激活：生命线拓宽成为矩形，代表时序图中的对象执行一项操作的时期
消息：定义交互和协作中交换信息的类，信息用于在实体间传递信息
时序图的建模步骤：
① 设置交互的语境。
② 通过识别对象在交互中扮演的角色，设置交互的场景。
③ 为每个对象设置生命线。
④ 从引发某个消息的信息开始，在生命线之间画出从顶到底依次展开的消息，显示每个消息的特性（如参数）。
⑤ 如果需要可视化消息的嵌套或实际计算发生时的时间点，可以用激活修饰每个对象的生命期。
⑥ 如果需要说明时间或空间的约束，可以用时间标记修饰每个消息，并附上合适的时间和空间约束。
⑦ 如果需要更形式化的说明某控制流，可以为每个消息附上前置和后置条件。

六．协作图：（Collaboration Diagram）
协作图包括：对象（Object）链（Link）消息（Message）
协作图的建模步骤：
① 设置交互的语境。
② 通过识别对象在交互中扮演的角色，设置交互的场景。
③ 对每个对象设置初始特性。
④ 描述对象之间可能有信息沿着它传递的链。
⑤ 从引起交互的消息开始，适当地设置其顺序号，然后将随后的每个消息附到适当的链上。
⑥ 如果需要说明时间或空间约束，可以用时间标记修饰这个消息，并附上合适的时间和空间约束。
⑦ 如果需要更形式化地说明这个控制流，可以为每个消息附上前置和后置条件。
时序图与协作图的比较：
1. 相同点：规定责任，支持消息，衡量工具
2. 不同点：时序图描述了交互过程中的时间顺序，但没有明确地表达对象之间的关系。
协作图描述了对象之间的关系，但时间顺序必须从顺序号获得。

七．状态图：（State Diagram）
1.状态图包括：状态（State） 转换（Transtition）
2.状态机：展示状态与状态转换的图，包含了一个类的对象在其生命期间所有状态的序列以及对象对接受到的事件所产生的反应。
3.一个状态图表示一个状态机，表现从一个状态到另一个状态的控制流。
4.状态图由表示状态的节点和表示状态之间转换的带箭头的直线组成。
5.状态图中的状态一般是给定类对象中的一组属性值，这组属性值是对象所有属性的子集。
6.状态图的建模步骤：
① 找出适合用模型描述其行为的类。
② 确定对象可能存在的状态。
③ 确定引起状态转换的事件。
④ 确定转换进行时对象执行的相应动作。
⑤ 对建模的结果进行相应的精化和细化。

八．活动图（Activity Diagram）
活动图是一种描述系统行为的图，它用于展现参与行为的类所进行的各种活动的顺序关系。
活动图包括：动作状态（Action State）、 活动状态（Activity State）、动作流（Action Flow）分支（Branch）与合并（Merge）、分叉（Fork）与汇合（Join）、泳道（Swimlane）、对象流（Object Flow）
活动图建模步骤：
① 识别要对其工作流描述的类或对象。
② 确定工作流的初始状态和终止状态，明确工作流的边界。
③ 对动作状态或活动状态建模。
④ 对动作流建模。
⑤ 对对象流建模。
⑥ 对建立的模型进行精化和细化。
活动图与状态图的区别：
活动图着重表现从一个活动到另一个活动的控制流，是内部处理驱动的流程。
状态图着重描述从一个状态到另一个状态的流程，主要有外部事件的参与。

九．组件图：
组件图描述了软件的各种组件和他们之间的依赖关系
组件图包括：组件（Component）、接口（Interface）、依赖关系（Dependency）
组件图的建模步骤：
n 对系统中的组件建模。
n 对相应组件提供的接口建模。
n 对组件之间的依赖关系建模。
n 将逻辑设计映射成物理实现。
n 对建模的结果进行精化和细化。

十．配置图：
配置图描述了运行软件的系统中硬件和软件的物理结构
配置图包括：节点（Node） 关联关系（Association）
配置图的建模步骤：
① 对系统中的节点建模。
② 对节点之间的关联关系建模。
③ 对驻留在节点上的组件建模。
④ 对驻留在节点上的组件之间的依赖关系建模。
⑤ 对建模的结果进行精化和细化。

第三部分 应用
一． 传统的软件开发模型
瀑布模型（Waterfall Model）
• 瀑布模型是一种线性模型。
• 瀑布模型将软件生存周期划分为7个阶段：
① 问题定义
② 可行性研究
③ 需求分析
④ 设计
⑤ 实现
⑥ 测试
⑦ 运行和维护
• 瀑布模型最为突出的缺点是缺乏灵活性。
螺旋模型
• 螺旋模型使用原型作为降低风险的机制。
• 螺旋模型使开发者在产品演化的任意阶段均可使用原型方法。
• 螺旋模型体现了RUP中迭代的思想。
• 一个螺旋的周期一般包括四个阶段：
① 确定目标，选择方案，选定完成目标的策略。
② 风险分析。
③ 启动开发阶段。
④ 评审前一阶段的工作，计划下一阶段工作。

二．软件项目失败的原因：
① 混乱的需求管理。
② 开发者之间以及开发者和用户不清晰的交流。
③ 架构不够坚固。
④ 没有发现需求、设计和实现中的不一致。
⑤ 缺少有效的测试。
⑥ 对项目状态的主观估计。
⑦ 没有正确地处理项目开发过程中的风险。
⑧ 没有对项目变更进行控制。

三．RUP二维软件开发模型
Rational Unified Process（RUP，统一开发过程）是一套面向对象的软件工程过程。

四．RUP开发过程中各阶段的核心工作流：
1.初始阶段：需求和分析
2.细化阶段：需求、分析和设计
3.构造阶段：实现
4.交付阶段：实现和测试
五．RUP的迭代开发模型

六．Rose双向工程
类的关系决定生成什么代码

第四部分 档案管理系统
软件需求的层次：业务需求、用户需求、功能需求
需求分析步骤：
获取需求---- >>分析需求---- >>描述需求 >>验证需求
一．分析需求：

二．创建用例图：
过程：1.寻找参与者2.确定用例 3.分析关系4.细化用例规约 5.精化细化用例模型
寻找参与者：一般人员、档案室人员、借阅管理员、系统管理员
确定用例：一般人员用例、档案室人员用例、借阅管理员用例、系统管理员用例
分析：一般人员活动：登录系统、查找档案、网上借阅、借阅档案、归还档案
档案室人员活动：系统参数设置、数据信息录入、数据查询、操作并查看日志
借阅管理员活动：借阅查询、处理网上借阅、借阅登记
系统管理员活动：登录系统、用户管理、权限管理、日志管理、数据管理、参数设置、报表打印、网上借阅管理
关系：

确定用例图：

其他用例图参照上图

三．创建类图：
过程：确定对象与类---- >>确定类的属性---- >>确定类的关系
类与对象：
用户、用户角色、权限、用户权限关系、参数表、档案案卷信息、档案文件信息、借阅关系、日志

四．创建时序图：
步骤：确定对象---- >>确定交互流程---- >>分析消息
1.系统管理员添加用户 2. 档案管理员录入数据

其他时序图参照上图

五．创建协作图：
1.系统管理员添加用户 2. 档案管理员录入数据

其他协作图参照上图

六．创建状态图：
步骤：标识建模实体---- >>标识实体的各种状态---->>标识相关事件---->>对所建模型精化和细化
实体：档案、用户账户（借阅者）
档案状态和事件：新建档案、可借阅、借出
借阅者状态和事件：新建借阅者、可用、不可用、已删除
档案状态图： 借阅者状态图：

七．创建活动图：一般人员活动图： 借阅管理员活动图：

档案室人员录入档案活动图： 系统管理员维护系统数据活动图：

系统管理员维护用户活动图： 系统管理员设置系统参数活动图：

类图、组件图、配置图见课本

第五部分 BBS论坛系统
一．分析需求：

二．用例图：
参与者：游客、注册用户、版主、系统管理员
游客用例：注册、登陆系统、查询帖子
注册用户用例：登陆系统、发表帖子、查询帖子、回复帖子
版主用例：登陆系统、帖子管理（增、删、改、查） 、加精贴、置顶帖
系统管理员用例：登录系统、帖子管理（增、删、改、查） 、会员管理、论坛分类管理、加精贴、置顶贴
确定用例图：

三．时序图： 会员发帖/回帖时序图： 论坛管理员管理会员时序图：

论坛管理员管理论坛分类时序图： 论坛管理员管理帖子时序图：

四．协作图： 会员发帖/回帖时序图： 论坛管理员管理会员时序图：

论坛管理员管理论坛分类时序图： 论坛管理员管理帖子时序图：

其他用例图、时序图、协作图、活动图、状态图见课本