软件需求工程2013-06-16.pptVIP

抽象层次 抽象层次是面向对象方法中极其重要且非常难以把握的技巧； 要想建立好模型，就需学会站在不同的抽象层次考虑问题。 抽象层次越高，被屏蔽（或者说封装）的信息也就越多，信息量越少也就越容易理解和处理。 统一过程一般抽象层次 抽象层次相关的问题 什么时候选择什么样的层次以及总共抽象多少层？------用例粒度 抽象层次与边界的选择总是相生相伴------边界 对象分析方法 一切都是对象； 对象都是独立的； 对象都具有原子性； 对象都是可抽象的； 对象都有层次性。 UML核心元素 2. 参与者（actor）: 定义：actor是在系统之外与系统交互的某人或某事物。如图所示： UML核心元素 发现参与者：参与者的一个重要来源是涉众，从涉众中找出那些直接对系统发出动作，或直接从系统中接收反馈的涉众。在查找参与者的过程中，可以询问以下问题以帮助确定参与者： 谁负责提供、使用或删除信息？ 谁将使用此功能？ 谁对某个特定功能感兴趣？ 在组织中的什么地方使用系统？ 谁负责支持和维护系统？ 系统有哪些外部资源？ 其他还有哪些系统将需要与该系统进行交互？ UML核心元素 参与者一定是直接并且主动地向系统发出动作并获得反馈的，否则就不是参与者。 UML核心元素 业务主角（busuness actor）：是参与者的一个构造类型，特别用于定义业务的参与者，在需求阶段使用。业务主角是与业务系统有着交互的人和事物，他们用来确定业务范围。业务主角的特殊性在于它针对的是业务人员而非计算机用户。 业务工人（business worker）：处于系统边界内，被动地参与了业务的执行过程。业务工人不是参与者。 UML核心元素 参与者与其他成员的关系 参与者与涉众（项目干系人、相关方）：参与者是涉众代表，他们的要求就是系统需求的来源； 参与者与用户（user）：用户是系统的使用者。用户是参与者的代表，或者说是参与者的实例或代理。并非所有的参与者都是用户。 参与者与角色（role）：角色是参与者的职责，角色是一个抽象的概念，从众多参与者的职责中抽象出相同的那一部分，将其命名形成一个角色。一个角色代表了系统的一类职责。由于一个用户可以代理多个参与者，因此一个用户可以拥有多个职责，也就是可以被指定多个角色。 UML核心元素 参与者、涉众、和角色的关系 UML核心元素 3. 用例（Use Case） 基本概念：官方文档对用例是这样定义的：用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值。 一个完整的用例定义由参与者、前置条件、场景、后置条件构成。如图所示： UML核心元素 用例的特征： 用例是相对独立的。 UML核心元素 用例的特征： 用例的执行结果对参与者来说是可观测的和有意义的。 UML核心元素 用例的特征： 这件事必须由一个参与者发起。不存在没有参与者的用例，用例不应该自动启动。 UML核心元素 用例的特征： 用例必然是以动宾短语形式出现的。 UML核心元素 用例的特征： 一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元。下图展示了用例如何驱动软件开发活动。 UML核心元素 一个大系统和一个很小的系统用例粒度会有较大差别。 不论粒度如何选择，必须把握的原则是在同一个需求阶段，所有用例的粒度应该是同一个量级的。 用例粒度的大小不是从用例包含的步骤的多少来判断的，粒度与边界有关。 UML核心元素 用例的获得：发现用例的前提条件是发现参与者。获取用例的准备工作： UML核心元素 用例的获得：可以通过以下问题引导业务代表： 您对系统有什么期望？ 您打算在这个系统里做些什么事情？ 您做这件事的目的是什么？ 您做完这件事情有一个什么样的结果？ 在此过程中需要确保： 一个明确的有效的目标才是一个用例的来源。 一个真实的目标应当完备地表达主角的期望。 一个有效的目标应当在系统边界内，由主角发动，并具有明确的后果。 用例与功能 用例与功能 这个事物是什么？ 这个事物能做什么？ 人们能够用这个事物做什么？ 理解用例与功能练习 请分别从功能角度和用例角度出发描述我们所熟悉的电视。 从功能角度出发，对电视的描述是能开关，能显示节目，可以调频道，可以调声音，以上四者是独立的； 从用例角度出发，对电视的描述是有一个人要观看电视节目的用例，要完成这个用例，第一步需要先打开开关，调到自己喜欢的频道，如果声音不合适，可以调节一下，以上三者是因人的需求而相关起来的。 UML核心元素———用例 如何理解目标与步骤的误区？假设邮局是一个目标系统，作为寄信人这样一个参与者，对邮局有着寄信的愿望。以完整目标作为用例： UML核心元素———用例 如何理解目标与步骤的误区？假设邮局是一个目标系统，作为寄信人这样一个参与者，对邮局有着寄