面向对象的分析与设计课件-分析篇

面向对象的分析与设计

第二部分：分析篇主讲教师：刘 杰

第5 章

建立需求模型——用况图

5.1 需求分析和系统分析需求分析的确切含义是对用户需求进行分析，旨在产生一份 明确、规范的需求定义。OOA的主要内容是研究问题域中与需求有关的事物，把它们 抽象为系统中的对象，建立类图。确切地讲，这些工作应该 叫做系统分析，而不是严格意义上的需求分析。 早期的OOA缺乏一个良好的基础——对需求的规范描述。 Jacobson方法(OOSE)提出用况(use case)概念， 解决了对需求的描述问题，其分析过程如下：需求说明 分析过程 需求分析

健壮分析分析模型2 2

需求模型

OOA是将问题域中的事物抽象为系统中的对象抽象的目标是系统责任——需求 用况的概念解决了对需求的描述问题

系统责任(抽象的目标)

需求模型 (用况图)

OOA模型 (类图)

问题域(抽象的来源)

3 3

5.2 基本思路问题的提出：在系统尚未存在时，如何描绘用户需要一 个什么样的系统？如何规范地定义用户需求？ 考虑问题的思路：把系统看作一个黑箱，看它对外部的 客观世界发挥什么作用，描述其外部可见的行为。系统边界以外 是与系统进行 交互的参与者

系统是由一条 边界包围起来 的未知空间

只通过有限 的几个接口 与外部交互

把内外交互情况描 述清楚，就确切地 定义了系统的需求4 4

5.3 系统边界与参与者系统边界：一个系统所包含的所有系统成分与系统以外 各种事物的分界线。 系统：被开发的计算机软硬件系统，不是指现实系统。 系统成分：在OOA和OOD中定义并且在编程时加以实 现的系统元素——对象系统边界 对象 参与者(人员)

参与者：在系 统边界以外， 与系统进行交 互的事物—— 人员、设备、 外系统

对 象

对象 对象 对象 对象

参与者(外系统) 参与者(设备)

5 5

现实世界中的事物与系统之间的关系——分四种情况(1)被抽象为系统中的对象 (2)只作为系统外部的参与者与系统交互 (3)既是系统中的对象，本身又作为参与者与系统交互 (4)与系统无关

汽车 钟表 起重机

奖杯

职员楼房 飞机

操作员天平

6 6

如何发现参与者 ——考虑人员、设备、外系统人员—— 系统的直接使用者 直接为系统服务的人员 设备—— 与系统直接相联的设备 为系统提供信息 在系统控制下运行 不与系统相连的设备 × 计算机设备 × 外系统—— 上级系统 子系统 其它系统7 7

5.4 用况(use case)什么是用况I. Jacobson:用况是通过使用系统功能的某些部分而使用系统的一种具体方式。每个 用况包括一个由参与者发动的完整的事件过程。它

详细说明了参与者和 系统之间发生的交互。因此，一个用况是一个由参与者和系统在一次对 话中执行的特定的相关事务序列。全部用况的集合则说明了所有可能存 在的系统使用方式。

?

《对象技术词典》:UML: ?

?

1.对一个系统或者一个应用的一种单一的使用方式所进行的描述。 2.关于单个参与者在与系统的对话中所执行的处理的行为陈述序列。

对系统在与它的参与者交互时所能执行的一组动作序列(包括其变体) 的描述。

本书的定义： 用况是对参与者使用系统的一项功能时所进行的交互过程 的描述，其中包含由双方交替执行的一系列动作。8 8

术语“use case”的准确含义——使用情况 是对一项系统功能使用情况的一般描述，它对于每一次使 用都普遍适应，既不是应用实例，也不是举例说明。 ——因此译为“用况”,而不是“用例”。几点说明：(1)一个用况只描述参与者对单独一项系统功能的使用情况；

(2)通常是平铺直叙的文字描述，UML也允许其他描述方式；(3)陈述参与者和系统在交互过程中双方所做的事； (4)所描述的交互既可能由参与者发起也可能由系统发起 ； (5)描述彼此为对方直接地做什么事，不描述怎么做； (6)描述应力求准确，允许概括，但不要把双方的行为混在一起； (7)一个用况可以由多种参与者分别参与或共同参与。

9 9

内容与书写格式 ：名称 行为陈述(分左右栏) 调用语句 控制语句 括号或标号

收款 输入开始本次收款的命令； 作好收款准备，应收款总 数置为0,输出提示信息； for 顾客选购的每种商品 do 输入商品编号； if 此种商品多于一件 then 输入商品数量 end if; 检索商品名称及单价； 货架商品数减去售出数； if 货架商品数低于下限 then call 通知上货 end if; 计算本种商品总价并打印编号、 名称、数量、单价、总价； 总价累加到应收款总数； end for; 打印应收款总数； 输入顾客付款数； 计算应找回款数， 打印付款数及找回款， 应收款数计入账册。

例

10 10

如何定义用况针对单个用况的描述策略： 把自己当作参与者，与设想中的系统进行交互。考虑： 交互的目的是什么？需要向系统输入什么信息？希望由 系统进行什么处理并从它得到何种结果？把上述交互过 程描述出来 。定义系统中所有的用况： (1)全面地了解和收集用户所要求的各项系统功能，找 出所有的参与者，了解与各项功能相关的业务流程； (2)把用户提出的功能组织成适当的单位，每一项功能 完成一项完整而相对独立的工作； (3)穷举每一类参与者所使用的每一项系统功能，定义 相应

的用况； (4)检查用户对系统的各项功能需求是否都通过相应的 用况做了描述。11 11

5.5 用况图

用况

参与者 基用况 « include» « include» 基用况

参与者

模型元素：被包含用况 用况 « extend» 参与者 基用况

参与者 用况 延伸 包含 泛化12 12

延伸用况

用况之间的关系——包含、延伸、泛化Perform ATM Transaction

Withdraw

包含

Transfe r Funds

Deposit Funds

泛化

问题：延伸与包含的相似性 延伸的方向问题 “条件”和“延伸点” 问题 “泛化”问题 系统边界问题13 13

延伸

用况的两种复杂情况1、两个(或多个)参与者共享一个用况 不同种类的参与者可能都要使用某一项系统功能，因 此它们可能共享同一个用况 例：系统管理员

系统维护

普通用户

登录

14 14

2、一个用况的执行，可能需要两个(甚至多个)参与者同时 与系统交互。例：网上购物

客户

供货商 网上购物

15 15

5.6 开发过程与建议用况图的开发过程确定系统边界 发现参与者 定义用况 建立用况之间的关系 确定参与者和用况之间的关系 绘制用况图

使用用况图的几条建议最重要的工作是对用况的描述 不要过分深入地描述系统内部的行为细节 运用最主要概念，加强用况内容的描述不要陷入延伸与包含、延伸点、泛化等问题的争论和辨别

了解用况的局限性——主要作用是描述功能需求16 16