《UML需求建模1》由会员分享，可在线阅读，更多相关《UML需求建模1（38页珍藏版）》请在金锄头文库上搜索。
1、面向对象分析需求建模1提纲oUse Caseo示例2一、 Use CaseUse CaselDescribe or capture functional requirements;lRepresent the desired behavior of system;lIdentify users (actors) of the system and associated processes3一、 Use CaseUse CaselIs a collection of task-related activities describing a discrete chunk of a system;l
2、Describes a set of actions sequences that a system performs to present observable result to an actor;lDescribe a system from an external usage viewpoint;4一、 Use CaseKey attributes of a use caseldescription;lAction sequence;lIncludes variants;lProduces observable results;A use case does not describe:
3、lNon-functional requirement;lUser interfaces;lPerformance goal;5一、 Use Caseuse case relationshipslgeneralization;lInclude;lExtend;67Identifying Use CaseUse Cases describe:lThe functions that user wants a system to accomplish;lThe operations that create ,read, update, delete information;lHow actors a
4、re notified of the changes to the internal state and how they notify the system about external events8Identifying ActorsTo determine who are the actors ,we try to answer the following questions:lWho use the system;lWho gets information from the system;lWho provides information to the system;lWho ins
5、talls, start up or maintains the system;9Use Case Template10二、 示例（ATM）建立用例模型 使用用例的方法来描述系统的功能需求的过程就是用例建模，用例模型主要包括以下两部分内容：l用例图(Use Case Diagram) 确定系统中所包含的参与者、用例和两者之间的对应关系，用例图描述的是关于系统功能的一个概述。 l用例规约(Use Case Specification) 针对每一个用例都应该有一个用例规约文档与之相对应，该文档描述用例的细节内容。 11二、 示例（ATM）建立用例模型 在用例建模的过程中，我们建议的步聚是先找出参与
6、者，再根据参与者确定每个参与者相关的用例，最后再细化每一个用例的用例规约。12二、 示例（ATM）寻找参与者寻找参与者 13二、 示例（ATM）系统边界决定了参与者系统边界决定了参与者 如果我们所要定义的系统边界仅限于ATM机本身，那么后台服务器就是一个外部的系统，可以抽象为一个参与者。 14二、 示例（ATM）系统边界决定了参与者系统边界决定了参与者 如果我们所要定义的系统边界扩大至整个银行系统，ATM机和后台服务器都是整个银行系统的一部分，这时候后台服务器就不再被抽象成为一个参与者。 15二、 示例（ATM）特殊的参与者特殊的参与者 l系统时钟l硬件中断.16二、 示例（ATM）确定用例确
7、定用例 回答前面所提问题，可以帮助用例的确定！17二、 示例（ATM）确定用例确定用例 注意事项注意事项：l用例必须是由某一个主角触发而产生的活动，即每个用例至少应该涉及一个主角 ；反之，每个参与者也必须至少涉及到一个用例 ；l用例模型必须是易于理解的 （参与者的名称一般都是名词，用例名称一般都是动宾词组 ）（命名问题）。 18二、 示例（ATM）确定用例确定用例 注意事项注意事项：l对于同一个系统，不同的人对于参与者和用例都可能有不同的抽象结果，因而得到不同的用例模型 ，一个好的用例模型应该能够容易被不同的涉众所理解，并且不同的涉众对于同一用例模型的理解应该是一致的。 19二、 示例（ATM
8、）用例规约用例规约 一个用例的用例规约包含以下内容：一个用例的用例规约包含以下内容：l简要说明 (Brief Description) 简要介绍该用例的作用和目的 l事件流 (Flow of Event) 包括基本流和备选流，事件流应该表示出所有的场景。 l用例场景 (Use-Case Scenario) 括成功场景和失败场景，场景主要是由基本流和备选流组合而成的 20二、 示例（ATM）用例规约用例规约 一个用例的用例规约包含以下内容：一个用例的用例规约包含以下内容：l特殊需求 (Special Requirement) 描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）
9、和设计约束（所使用的操作系统、开发工具等）l前置条件 (Pre-Condition) 执行用例之前系统必须所处的状态 l后置条件 (Post-Condition) 用例执行完毕后系统可能处于的一组状态 21二、 示例（ATM）用例规约用例规约 用例规约基本上是用文本方式来表述的，为了更加清晰地描述事件流，也可以选择使用状态图、活动图或序列图来辅助说明。只要有助于表达的简洁明了，就可以在用例中任意粘贴用户界面和流程的图形化显示方式，或是其他图形。如活动图有助于描述复杂的决策流程，状态转移图有助于描述与状态相关的系统行为，序列图适合于描述基于时间顺序的消息传递。22二、 示例（ATM） 用例图使我
10、们对系统的功能有了一个整体的认知，我们可以知道有哪些参与者会与系统发生交互，每一个参与者需要系统为它提供什么样的服务。用例描述的是参与者与系统之间的对话，但是这个对话的细节并没有在用例图中表述出来，针对每一个用例我们可以用事件流（交互流程）来描述这一对话的细节内容23二、 示例（ATM）基本流基本流 基本流描述的是该用例最正常的一种场景，在基本流中系统执行一系列活动步骤来响应参与者提出的服务请求。 在ATM系统中的提款用例可以用事件流表述如下： 提款提款-基本事件流基本事件流(交互流程交互流程) 1. 用户插入信用卡 2. 输入密码 3. 输入提款金额 4. 提取现金 5. 退出系统，取回信用
11、卡24二、 示例（ATM）备选流备选流 备选流负责描述用例执行过程中异常的或偶尔发生的一些情况，备选流和基本流的组合应该能够覆盖该用例所有可能发生的场景 。 在描述备选流时，应该包括以下几个要素在描述备选流时，应该包括以下几个要素： 1) 起点：该备选流从事件流的哪一步开始； 2) 条件：在什么条件下会触发该备选流； 3) 动作：系统在该备选流下会采取哪些动作； 4) 恢复：该备选流结束之后，该用例应如何继续执行25二、 示例（ATM）用例场景用例场景 用例在实际执行的时候会有很多的不同情况发生，称之为用例场景；也可以说场景是用例的实例。l用例的时候要覆盖所有的用例场景，否则就有可能导致需求的
12、遗漏；l在用例规约中，场景的描述可以由基本流和备选流的组合来表示；l场景既可以帮助我们防止需求的遗漏，同时也可以对后续的开发工作起到很大的帮助：开发人员必须实现所有的场景、测试人员可以根据用例场景来设计测试用例。26二、 示例（ATM）用例关系用例关系包含（包含（include） 在ATM机中，如果查询、取现、转帐这三个用例都需要打印一个回执给客户，我们就可以把打印回执这一部分内容提取出来，抽象成为一个单独的用例打印回执，而原有的查询、取现、转帐三个例都会包含这个用例。每当以后要对打印回执部分的需求进行修改时，就只需要改动一个用例，而不用在每一个用例都作相应修改，这样就提高了用例模型的可维护性
13、27二、 示例（ATM）用例关系用例关系包含（包含（include）28二、 示例（ATM）用例关系用例关系包含（包含（include） 在基础用例的事件流中，我们只需要引用被包含用例即可。 查询查询-基本事件流基本事件流 1. 用户插入信用卡 2. 输入密码 3. 选择查询 4. 查看帐号余额 5. 包含用例打印回执 6. 退出系统，取回信用卡29二、 示例用例关系用例关系扩展扩展(extend) 扩展关系是指将扩展用例(Extension)的事件流在一定的条件下按照相应的扩展点插入到基础用例(Base)中。对于包含关系而言，子用例中的事件流是一定插入到基础用例中去的，并且插入点只有一个。而
14、扩展关系可以根据一定的条件来决定是否将扩展用例的事件流插入基础用例事件流，并且插入点可以有多个。30二、 示例用例关系用例关系包含（包含（include） 对于电话业务，可以在基本通话(Call)业务上扩展出一些增值业务如：呼叫等待(Call Waiting)和呼叫转移(Call Transfer)。我们可以用扩展关系将这些业务的用例模型描述如下：31二、 示例用例关系用例关系包含（包含（include）32二、 示例用例关系用例关系泛化泛化(generalization) 当多个用例共同拥有一种类似的结构和行为的时候，我们可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用
15、例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。33二、 示例用例关系用例关系泛化泛化(generalization) 34二、 示例用例的粒度问题用例的粒度问题 一个系统需要有多少个用例？这是很多人在用例建模时会产生的疑惑。描述同一个系统，不同的人会产生不同的用例模型。例如对于各种系统中常见的维护用户用例，它里面包含了添加用户、修改用户信息、删除用户等操作，这些操作在该用例的事件流可以表述成为基本流的子事件流(subflow)。35二、 示例用例的粒度问题用例的粒度问题36二、 示例用例的粒度问题用例的粒度问题 在一次技术研讨会上，有人问起在一次技术研讨会上，有人问起Ivar Jacoboson博士，一个系统需要有多少个用例？大师的回答是博士，一个系统需要有多少个用例？大师的回答是20个，当然他的意思是最好将用例模型的规模控制个，当然他的意思是最好将用例模型的规模控制在几十个用例左右，这样比较容易来管理用例模型的在几十个用例左右，这样比较容易来管理用例模型的复杂度复杂度 37The End 38
