uml统一建模语言05

UML建模语言及工具

第 5 章用例分析技术Use-Case Analysis

Review: Use-Case Modeling

基于用例的需求获取过程

1. 获取原始需求 2. 开发一个可以理解的需求

2.1 识别参与者 2.2 识别用例 2.3 构建用例图进行用例阐述 4.1 识别用例间的关系 4.2 对用例进行组织和分包-3-

3 详细、完整地描述需求

4 重构用例模型

学习线路图OOOOA: :

OOD DP

:

:

:

UML… Case-Study …

…… …… …… ……

学习线路图

-4-

下一步？需求 用例

面向对象 分析设计

结构化 分析设计

其它方法

自己的 土方法

系统

-5-

内容安排

面向对象分析设计过程 面向对象分析基础 面向对象分析原则 开始分析之前 用例分析技术

-6-

IBM RUP

-7-

RUP中的分析和设计工作流软件构架文档 用例实现规约

分析 Analysis

设计 Design-8-

分析阶段主要工件用例视图： 用例模型 用例实现(分析)

逻辑视图： 分析(概念)模型 体系结构包图

:

:

-9-

内容安排

面向对象分析设计过程 面向对象分析基础 面向对象分析原则 开始分析之前 用例分析技术

-10-

OOA目标

开发一系列模型，以描述计算机软件， 从而满足客户定义的需求：分析模型

包括两种图，描述对象及其交互 这些图按照用例模型来组织，每个用例图都 会产生数张图

类图(class diagram):描述了构成一类对象 特征的状态和行为(描述软件架构) 交互图(interaction diagram):描述对象之 间的交互行为(演示用例实现)(描述系统行为)

-11-

从需求到分析Requirement Model Analysis Model

Use Case Realization Anaysis

------------------------------------------------------------------------------Supplementary Specification

------------------------------------------------------------------------------Glossary

Analysis workflow: :

Analysis Class

-12-

OOA与用例模型

分析是建立在需求收集的基础上

分析模型建立在用例模型的基础上 用例模型确定了分析模型的结构(通过用例来组织 分析模型) 用户视角理解用户问题过渡到开发团队视角分析用 户问题

与需求一样，它还是在问题域中 用例分析也是分析的一个阶段，而OOA是分析的后期阶段， 从这个阶段开始，我们从用户域跨入开发团队域

分析与需求捕获在很大程度上重叠，这两个活动常 常相辅相成，为了澄清和找出任何遗漏或歪曲的需 求，常常需要在需求之上作一些分析-13-

分析模型与用例模型用例：外观

类图：内部机理

-14-

如何开始？

从 用 例 开 始！

-15-

从用例开始-1

根据高层用例图和文档来确认需求定义是可靠 的、

一致的

可靠的

每个用例都包含对正常事件流和异常事件流的描述 存在备选事件流、异常事件流的描述如果在分析过程中发现一些新的用例，说明需求是不完备 的，此时应对用例进行重构 在分析过程中，还有可能精化对每一个用例的理解

完备的

-16-

从用例开始-2

根据风险、重要性以及项目组的能力确定用例的优先 级：用例分级

风险 重要性 团队能力以及团队建设

在迭代开发中，通过一次全面的需求收集来获得所有 的用例；之后找出一个用例集，开发一个符合这些需 求的最小系统，完成一次迭代过程；在此基础上，进 行后续的增量开发过程

相对来说，策划一系列的小胜利和接受一些小的 失误总要好一点。策划一个巨大的胜利经常会导 致灾难性的失败！-17-

用例图：考勤卡系统Export Time Entries Billing System Change Password <<include>>

Administrativ e User

Login

Employee

Record Time

Create Charge Code Create Employee

-18-

从用例开始-风险分析-1

项目本身风险(risk):项目的风险清 单

无法接受的系统性能 无法应付新的需求 不确定的进度以及开发周期 无法接受的用户界面 ……

-19-

从用例开始-风险分析-2

团队解决问题的能力：结合团队能力分析用例 风险，即团队是否有能力解决用例中的问题

1-当然可以，我们的项目团队以前解决过这种问题 2-没问题，我们机构以前解决过这种问题 3-可以采用第三方提供的产品、培训、书或者其他 的技术资料，但我们内部没有任何经验 4-可能吧，我们听过类似的可以解决的问题 5-我们希望可以，但我们得作一些开创性的工作

-20-

从用例开始-重要性

对用户以及架构的重要性(significance)

一个重要的用例应该能够体现系统的特性和目标； 如：Record Time、Export Time Entries 其他的用例可能很重要，但只是扮演支持的角色； 如：Change Password 评估用例的重要性

1-用户几乎不注意用例的存在，在没有它的情况下系统不 会有什么影响 2-用户注意用例的存在，但稍加想象，系统仍然可以很好 的使用 3-系统的大部分可以独立于这个用例 4-系统的一部分可以独立于这个用例 5-没有它，就不可能使用这个系统

-21-

本文来源：https://www.bwwdw.com/article/pmc1.html