2004计算机软件工程考研串讲之三

作者名：不详　来源：网友提供 06年6月8日

活动定义了工作人员所执行的工作。有 3 类步骤：
思考步骤
执行步骤
评审步骤
制品是过程生产、修改或使用的一种信息。RUP 的制品分为 5 个信息集。
管理集：计划制品、操作制品
需求集：构想文档、项目相关人员需求、用例模型和业务模型

业务建模工作流：描述业务过程的本质和执行情形。
需求工作流：定义系统构想，使用用例模型和补充规格说明定义系统软件需求，管理系统范围和需求变更。
分析和设计工作流：研究实现环境和系统构件的效用，定义软件的组织结构，把需求获取结果转化为实现规格。
实现工作流: 建立代码的分层结构，实现类和对象，进行单元测试和系统集成。

测试工作流：根据事先定义的度量和准则检查产品，确认产品是否满足或者超出事先定义并被一致接受的需求。
实施工作流：在实际使用环境中测试软件、包装要交付的软件、发布软件产品、培训最终用户及销售人员。

初始阶段：确定最终产品的构想及其用例，定义项目范围。
细化阶段：计划需完成活动和资源，详细说明产品特性并设计软件体系结构。
构造阶段：构造整个产品，逐步完善软件体系结构和计划，直到产品（完整的构想）已完全准备好交付给用户。
移交阶段：移交产品给用户，包括制造，交付，培训，支持及维护产品。

Rational统一过程的特点：
用例驱动的、以体系结构（架构）为中心的、迭代和增量的过程。
用例建模技术可以用为大多数项目相关人员理解的形式来表述问题。
参与者（Actor）
用例（Use Case）
场景（scenario）
事件流（event flow）

用例和参与者的事例
银行储户通过自动取款机（自动柜员机）提款，转账或检查账户余额。用一组用例表达如下：

用例模型
将整个系统或子系统的所有用例，以及与之交互的参与者集合起来构成系统的用例模型。
用例模型给出系统预期功能模型和系统上下文环境模型，它成为开发人员和用户之间的契约。
用例模型的目的是确保系统能处理所有的功能性需求。

用例驱动的过程
“用例驱动” 指开发过程是基于用例，从一个工作流向下一个工作流，逐步前进的。
开发初期，开发人员使用用例获取用户需求，建立用例模型，描述系统的全部功能。
基于用例模型，开发人员创建一系列实现这些用例的分析模型、设计模型和实现模型。
测试人员测试实现确保系统正确实现了用例。

面向对象分析与设计的建模
软件开发需要把问题解决模型化。
模型化是理解一个复杂系统的工具；
模型是系统早期抽象的重要结构；
常用的面向对象分析与设计模型
Rumbaugh 等人的 OMT 模型
Coad 和 Yourdon 的模型
Booch 开发模型
UML 统一建模语言
Rumbaugh的对象模型化技术OMT (object modeling technique)
对象模型化技术的三类模型：对象模型、动态模型和功能模型。

这个模型化的过程是一个迭代过程通过不断更新、细化，直到切合系统真正需求为止。。
1. 对象模型
是三个模型中最关键的一个模型，它的作用是描述系统的静态结构，包括构成系统的类和对象，它们的属性和操作，及它们之间的关系。
在OMT中，类与类之间的关系叫做关联。关联代表一组存在于两个或多个对象之间的,具有相同结构和含义的具体连接。关联可以是物理的，也可以是逻辑的。

聚合，代表整体与部分的关系，这是一种特殊形式的关联。
菱形框 表示整体侧对象
限定，用以对关联的含义做某种约束。
角色，用来说明关联的一端。由于多数关联具有两个端点，因而涉及到两个角色。
附加的说明对象之间的连接连接属性。

泛化关联

2. 动态模型

事件追踪图
事件追踪图侧重于说明发生于系统执行过程中的一个特定“场景”。
场景也叫做脚本，是完成系统某个功能的一个事件序列。
场景通常起始于一个系统外部的输入事件，结束于一个系统外部的输出事件，它可以包括发生在这个期间的系统所有的内部事件。

3. 功能模型
功能模型由数据流图组成，指明从外部输入到外部输出，数据在系统中传递和变换的情况。

Coad 与 Yourdon 的分析与设计

2. Coad 与 Yourdon 的设计模型
设计模型被划分成了 4 个组成部分，这些组成部分把实现技术隐藏起来，使之与系统的基本问题领域行为分离开来。
从分析转到设计需要在分析模型的基础上加入实现方面的限制。
设计模型类似于构造蓝图，设计模型全面地定义了如何用特定的实现技术建立起一个目标系统。

UML面向对象分析与设计
UML把Booch, Rumbaugh和Jacobson等各自独立的OOA和OOD方法中最优秀的特色组合成一个统一的方法。
UML的特点：
统一标准
面向对象
可视化，表示能力强大
独立于过程
容易掌握使用
UML的定义
UML定义有两个主要组成部分：
语义：用自然语言描述
表示法：定义UML的可视化标准表示符号
使用 UML 时，要从不同的角度观察系统，为此定义了概念 “视图”。视图是对系统的模型在某方面的投影，注重于系统的某个方面。

UML的构成

接口 — 描述一个类或构件的服务（操作）。

协作 — 描述合作完成某个特定任务的一组类及其关联的集合，用于对使用情形的实现建模。
用例 — 表示系统想要实现的行为，不关心这些行为是怎样实现的。

构件 — 系统中物理
的、可替代的部件。

节点 — 系统在运行
时存在的物理元素。

UML 事物—行为事物
交互 — 由在特定环境中共同完成一定任务的一组对象之间交换的消息组成。

状态机 — 描述了一个对象或一个交互在生存周期内响应事件所经历的状态序列。
UML 事物—分组事物
包
UML 事物—注释事物
注释 — 依附于一个元素或一组元素之上，对其进行约束或解释的简单符号。
UML 关系
依赖 — 两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。

关联 — 一种描述一组对象之间连接的结构关系。
聚合是一种特殊类型的关联，描述了整体和部分间的结构关系。

泛化 — 一种一般化—特殊化的关系。

实现 — 类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。
两种情况出现实现关系：
在接口和实现它们的类或构件之间；
用例和它们的协作之间。
模型中主要的图形元素
UML 模型的图形
1. 用例图
用例图展现了一组用例、参与者以及它们间的关系。
可以用用例图描述系统的静态使用情况，它定义了系统的功能需求，但这是从系统的外部观看系统功能，并不描述系统内部对功能的具体实现。
在对系统行为组织和建模方面，用例图的是相当重要的。

2. 类图
类图展示了一组类、接口和协作及它们间的关系。
类图没有时间概念，是概念数据模型（如E-R 图）的一种延伸。
用类图说明系统的静态结构视图，包含主动类的类图—专注于系统的静态处理视图。
系统可有多个类图，单个类图仅表达了系统的一个方面，要在高层给出类的主要职责，在低层给出类的属性和操作。

类图是从系统构成角度来描述系统。
类的表示：
限定关联
关联类
泛化关系

3. 对象图
对象图展示了一组对象及它们间的关系。
用对象图说明类图中类的对象实例的数据结构和静态快照，即在某一时刻，一组对象的状态及其关系。
对象图表达了系统的静态设计视图或静态过程视图，除了现实和原型的方面因素外，它与类图作用是相同的。

4. 包图
包图表明包及其之间的依赖类图。
包是对模型中涉及的元素分组所得的结果，是具有特定语义的一个子集，必须保证低耦合、高内聚。
广义地讲，包可以包含类、接口、构件、节点、协作、用例等，还可以内嵌其他子包。
包之间的访问权限通过输出（输出品）和导入（进口货）设置，虚箭头 从源包到目标包。

5. 构件图
构件图展现了一组构件之间的组织和依赖，用于对源代码、可执行的发布、物理数据库等的系统建模。
构件图表示系统的静态实现视图。

6. 部署图
部署图展现了对运行时处理节点以及其中构件的配置每一节点代表一个计算单元。。
它描述系统硬件的物理拓扑结构 ( 包括网络布局和构件在网络上的位置) ，以及在此结构上执行的软件（即运行时软构件在节点中的分布情况）。
用部署图说明系统结构的静态环境视图，即说明分布、交付和安装的物理系统。

8. 活动图
活动图是一种特殊的状态图，描述要做的活动、执行这些活动的顺序以及工作流。它对于系统的功能建模特别重要，强调对象间的控制流程。
高层活动图用于表示任务。即用于分析用例，理解涉及多个用例的工作流、多线程及并行，显示相互联系的行为整体，还可用于业务过程建模，对系统的功能建模。低层活动图用于表示类的方法。

9. 状态图
状态图展示了一个特定对象的所有可能状态以及由于各种事件的发生而引起的状态间的转移。
一个状态图描述了一个状态机，用状态图说明系统的动态视图。
状态图对于接口、类或协作的行为建模尤为重要，可用它描述用例实例的生存周期。
Project对象的状态图
10. 交互图
交互图展现了按一定的目的进行一种交互，它由在一个上下文中的一组对象及它们之间交互的信息组成。
交互图可用于描述一个用例的行为。顺序图和协作图都是交互图，它们可以相互转换。
如果希望查看单个对象跨用例的行为, 要使用状态图。
如果希望查看跨用例跨线程的行为，要使用活动图。