面向对象的分析与设计课件-分析篇详解.ppt

第二部分：分析篇 面向对象的分析与设计 主讲教师：刘 杰 第5章 建立需求模型——用况图 5.1 需求分析和系统分析 需求分析的确切含义是对用户需求进行分析，旨在产生一份明确、规范的需求定义。 OOA的主要内容是研究问题域中与需求有关的事物，把它们抽象为系统中的对象，建立类图。确切地讲，这些工作应该叫做系统分析，而不是严格意义上的需求分析。 早期的OOA缺乏一个良好的基础——对需求的规范描述。 问题域 （抽象的来源） OOA模型 （类图） 抽象 OOA是将问题域中的事物抽象为系统中的对象 5.2 基本思路 问题的提出：在系统尚未存在时，如何描绘用户需要一个什么样的系统？如何规范地定义用户需求？ 考虑问题的思路：把系统看作一个黑箱，看它对外部的客观世界发挥什么作用，描述其外部可见的行为。 把内外交互情况描述清楚，就确切地定义了系统的需求 系统边界 系统边界：一个系统所包含的所有系统成分与系统以外各种事物的分界线。 系统：被开发的计算机软硬件系统，不是指现实系统。 系统成分：在OOA和OOD中定义并且在编程时加以实现的系统元素——对象 对 象 对象 对象 对象 对象 对象 5.3 系统边界与参与者 现实世界中的事物与系统之间的关系——分四种情况 人员—— 系统的直接使用者 直接为系统服务的人员 设备—— 与系统直接相联的设备 为系统提供信息 在系统控制下运行 不与系统相连的设备 × 计算机设备 × 外系统—— 上级系统 子系统 其它系统 如何发现参与者 ——考虑人员、设备、外系统 什么是用况 I. Jacobson： 用况是通过使用系统功能的某些部分而使用系统的一种具体方式。每个用况包括一个由参与者发动的完整的事件过程。它详细说明了参与者和系统之间发生的交互。因此，一个用况是一个由参与者和系统在一次对话中执行的特定的相关事务序列。全部用况的集合则说明了所有可能存在的系统使用方式。 《对象技术词典》： 1．对一个系统或者一个应用的一种单一的使用方式所进行的描述。 2．关于单个参与者在与系统的对话中所执行的处理的行为陈述序列。 UML： 对系统在与它的参与者交互时所能执行的一组动作序列（包括其变体）的描述。 本书的定义： 用况是对参与者使用系统的一项功能时所进行的交互过程的描述，其中包含由双方交替执行的一系列动作。 5.4 用况（use case） 术语“use case”的准确含义——使用情况 是对一项系统功能使用情况的一般描述，它对于每一次使用都普遍适应，既不是应用实例，也不是举例说明。 ——因此译为“用况”，而不是“用例”。 几点说明： （1）一个用况只描述参与者对单独一项系统功能的使用情况； （2）通常是平铺直叙的文字描述，UML也允许其他描述方式； （3）陈述参与者和系统在交互过程中双方所做的事； （4）所描述的交互既可能由参与者发起也可能由系统发起 ； （5）描述彼此为对方直接地做什么事，不描述怎么做； （6）描述应力求准确，允许概括，但不要把双方的行为混在一起； （7）一个用况可以由多种参与者分别参与或共同参与。 内容与书写格式 ： 名称 行为陈述（分左右栏） 调用语句 控制语句 括号或标号 如何定义用况 针对单个用况的描述策略： 把自己当作参与者，与设想中的系统进行交互。考虑：交互的目的是什么？需要向系统输入什么信息？希望由系统进行什么处理并从它得到何种结果？把上述交互过程描述出来 。 定义系统中所有的用况： （1）全面地了解和收集用户所要求的各项系统功能，找出所有的参与者，了解与各项功能相关的业务流程； （2）把用户提出的功能组织成适当的单位，每一项功能完成一项完整而相对独立的工作； （3）穷举每一类参与者所使用的每一项系统功能，定义相应的用况； （4）检查用户对系统的各项功能需求是否都通过相应的用况做了描述。 参与者 基用况 ?include? ?extend? ?include? 用况 基用况 基用况 被包含用况 延伸用况 用况 5.5 用况图 参与者 参与者 模型元素： 参与者 用况 延伸 包含 泛化 5.5 用况图 用况之间的关系 ——包含、延伸、泛化 延伸 包含 问题： 延伸与包含的相似性 延伸的方向问题 “条件”和“延伸点”问题 “泛化”问题 系统边界问题 用况的两种复杂情况 1、两个（或多个）参与者共享一个用况 不同种类的参与者可能都要使用某一项系统功能，因此它们可能共享同一个用况 2、一个用况的执行，可能需要两个（甚至多个）参与者同时与系统交互。 用况图的开发过程 确定系统边界 发现参与者 定义用况 建立用况之间的关系 确定参与者和用况之间的关系 绘制用况图 使用用况图的几条建议 最重要的工作是对用况的描述 不要过分深入地描述系统内