需求分析和用例建模

1、三、需求分析和用例建模3.1 可行性研究与风险分析 n经济可行性1.系统成本费用分析q设备购置费用。q系统开发费用。q系统安装、运行和维护费用。q人员培训费用。2.系统效益分析q经济效益。q社会效益。UML系统建模与分析设计n技术可行性1.风险分析 2.资源分析 3. 技术分析q反映系统动态特性： q综合系统的全部因素： q突出系统的重要因素： q结构简单： n法律可行性分析n开发方案可行性分析研究q提出待选方案q评价待选方案q确定开发方案3.1.5 可行性分析报告文档格式客户需求分析和用例建模客户需求分析和用例建模用例模型用例建模的主要目标是：n将需求规约变为可视化模型，并得到用户确认； n

2、给出清晰、一致的关于系统做什么的描述，确定系统的功能要求； n提供从功能需求到系统分析、设计、实现各阶段的度量标准； n为最终系统测试提供基准，据此验证系统是否达到功能要求； n为项目目标进度管理和风险管理提供依据用例建模的步骤： n确定系统的范围和边界； n确定系统的执行者（actor）和用例； n对用例进行描述； n定义用例之间的关系； n审核用例模型。 3.2.2 用例图执行者与边界nActor，参与者n定义：在系统外部与系统交互的人或其他系统（事物）n系统边界包括：q整个组织：如一个企业； q一个组织的某个部门：如企业的财务处； q计算机系统的硬件/软件边界：如企业的进、销、存计算机管

3、理系统。 参与者与边界参与者和边界n关键词：系统之外n参与者和系统之间有一个明确的边界n参与者只能存在于边界之外n边界之内所有的人和事物都不是参与者n边界一般有显示的绘制出来（显式），有时也不绘制（隐式）n有参与者必然有边界参与者和边界n小王到银行去开户，向大厅经理询问了办理手续，填写了表单，交给了银行柜员，拿到了银行存折，谁，才是参与者？n想要确定参与者，必须先确定边界n回答下面两个问题：q谁对系统有着明确的目标和要求并且主动发出动作？q系统是为谁服务的？n问题一：q小王，有明确目标，开户，并且主动发出了开户请求的动作；q大厅经理和柜台职员，在小王没有发出动作以前，都不会做事情；n问题二：q

4、系统运作的结果，就是给小王提供开户的服务n因此，小王是参与者，同时能够明确系统边界，包括大厅经理和柜台职员之内的其他事物都在边界以内确定参与者n谁使用系统的主要功能？n谁需要维护、管理和维持系统的日常运行？n谁读、写或修改系统中的信息？n哪些人或外部系统对系统产生的结果（值）感兴趣？n系统需要控制那些硬件设备？n系统需要与哪些其他外部系统交互？确认参与者n案例，一个在线机票预定系统，购买者可以通过网站进行登陆，在线购买机票；也可以打服务电话，由工作人员操作购买机票；当人工服务忙碌时，购买者可以通过呼叫中心的自动语音预定情况一情况二情况三整合情况参与者的歧义参与者的歧义n业务主角 (busine

5、ss actor)q主角n业务工人 (business worker)q配角n是否主动向系统发出动作n是否有完整的业务目标n系统是否为他服务参与者与其他角色n系统相关者 (stakeholder) （涉众）q不是所有的系统相关者都是参与者n用户 (user)q用户是系统的使用者，是参与者的实例q例如：局长和秘书n角色 (role)q角色是参与者的职责的抽象q例如：局长和副局长都能审批文件，则审批文件者为一个角色如何检查发现的参与者是否正确n是否已经找到了所有的参与者，即是否对系统环境中的所有角色都进行了说明和建模？n每个参与者是否至少涉及一个用例？删除未在用例说明中提到的所有参与者，或与用例无

6、通信关联关系的所有参与者。n是否能列出至少两名可以作为特定参与者的人员？如果不能，请检查参与者所建模的角色是否是另一个角色的一部分，如果是，合并。如何检查发现的参与者是否正确n是否有两个参与者担任与用例相关的同一个角色？如果有，应该利用参与者泛化关系来为他们的共享行为建立模型。n特定的参与者是否将以几种（完全不同的）方式使用系统，或者使用用例出于几个（完全不同的）目的？如果是，应该有多个参与者。n参与者是否有直观名称和描述性名称？参与者的名称应该与其角色相符。用例用例用例 (use case)n用例，是系统提供的一个功能（或者系统提供的某一特定用法）的描述。n用例俘获某些用户可见的需求，实现一

7、个具体的用户目标。n用例由参与者激活，并且提供确切的值给参与者。n用例必须是对一个具体的用户目标实现的完整描述。n用例，可以使其他“独立”的元素互相发生联系 描述用例描述用例用例名：用例名：简单名：简单名： 路径名路径名： 用例的概念用例的构成用例的文字描述用例的文字描述应包括以下内容:q用例的目的（功能）；q该用例在什么情况下被哪个执行者启动执行；q用例与执行者之间交互哪些消息来通知对方作出决定；q交互的主消息流及因此被使用或修改的实体；q用例中可供选择的异常事件流；q用例结束标志：给执行者返回一个可识别的值。举例：用例名称：学生选课 执行者：学生目的：完成一次学生选课的完整过程。类型：主要

8、的、基本的级别：一级用例的文字描述过程描述：（1）学生输入标识码（ID），系统识别标识码的有效性；（2）对学生进行注册识别；（3）流览本学期预开课程；（4）选择学生自己要上的课程并确认；（5）退出系统，系统给出所选课程列表及相应学分合计。异常事件流处理：（1）标识码有效性检查失败，允许学生重新输入（3次机会）。（2）注册识别失败，没有注册（尙未交学费）的学生不能选课。（3）选择课程确认失败，所选几门课程中在上课时间上发生冲 突时，系统提示重选。 用例的特征n完整性，表示一个完整的功能，必须是一个完整的描述。用例的特征n回执性，用例执行完毕，向参与者提供可以识别的返回值；即用例的执行结果对参与者

9、来说是可以观测和有意义的。用例的特征n响应性，一个用例不会自动执行，总是由参与者启动；即不存在没有参与者的用例，用例不应该自动启动，也不能主动启动另一个用例。用例的特征n用例总是以动宾形式出现n“计算”、“统计”、“报表”、“输出”、“录入”用例的特征用例的粒度n粒度，数据的细化或综合程度的级别n即，一个大的用例合适，还是分解成几个小的用例合适n例如：ATM取钱场景q取钱q读卡q验证账号q打印回执单用例的粒度n业务建模阶段n以每个用例能够说明一件完整的事情为宜，即一个用例可以描述一项完整的业务流程，有助于明确需求范围。n例如：取钱，借书，安装宽带用例的粒度n概念建模阶段n每个用例应该能描述一个

10、完整的事件流n如：安装宽带，可以分解为提供申请资料、受理业务、现场安装等用例的粒度n系统建模阶段n一个用例应该能够描述操作者与计算机的一次完整交互n如：填写表单、审核申请单、派发任务等案例1n某人去图书馆，查询了书目，出示了借书证，管理员查询了该人以前的借阅记录并没有发现没有未归还的图书，最后借到了书。n用例：借书案例2n某人去邮局寄信，为了寄信他需要购买信封；q购买信封是寄信的一个步骤，不能作为一个用例n某人去邮局购买一个信封。q目的就是购买信封，购买信封就是一个用例n因此，寄信和购买信封可以是一个粒度的用例案例3寻找和确定用例n根据产生阶段，用例可以分为n业务用例q在系统开发的开始阶段，在

11、确定客户需求过程中，通过与客户交流建立业务模型来确定的用例n系统用例q在系统构造阶段，根据系统的需要确定的用例业务用例n用户需要系统提供哪些业务功能？n用户最关注系统中哪些事件？从功能观点看，这些事件表示什么？n用户要了解系统在工作中发生了哪些事件及其结果？n用户自己需要做什么？n用户是否需要在系统中创建、删除、读、修改或者存储某些业务数据？n系统的新功能是否能使用户的日常工作被简化或者提高效率？系统用例n系统为了维持正常运转需要增加哪些功能和信息交互？n这些信息从何而来，到哪里去？n实现当前系统的关键问题是什么？用例的获得案例n客户说：我希望这台ATM能支持跨行业务，我插入卡片输入密码后，可

12、以让我选择取钱还是存钱；为了方便，可以设置一些默认的存取金额按钮；我可以修改密码，也可以挂失；还有我希望可以交纳电话费、水费、电费等；为了安全，ATM上应该有小心骗子的提示条，还有摄像头；如果输入三次密码错误，卡片应该被自动吞没。n首先明确：q参与者位于系统边界外q参与者对系统有明确的期望和明确的回报要求q参与者的期望和回报要求在系统边界外n然后，回答问题：q你对系统的期望是什么？q你打算在这个系统里做些什么事情？q你做这件事的目的是什么？q你做完这件事希望有一个什么样的结果？判断下列那些是有效用例n支持跨行业务n插入卡片n输入密码n选择服务n取钱n存钱n挂失卡片n交纳费用n警示骗子n三次错误

13、吞卡n支持跨行业务？ 业务规则，限定业务的范围n插入卡片？ 过程步骤，不是完整目标n输入密码？ 过程步骤，不是完整目标n选择服务？ 过程步骤，不是完整目标n警示骗子？ 超出边界n三次错误吞卡？ 业务规则，限定业务的条件n取钱？ 有效的完整目标n存钱？ 有效的完整目标n挂失卡片？ 有效的完整目标n交纳费用？ 有效的完整目标用例和功能的误区n用例是用来获取功能性的需求的，但前提是这个功能性需求是从参与者的角度出发的。n功能是计算机术语，是用来描述计算机的，不是定义需求的。n功能，即输入+计算+输入用例和功能的误区n从以下三个观点描述事物：q这个事物是什么？q这个事物能做什么？q人们能够用这个事物做

14、什么？n描述一，结构性观点，描述事物的客观存在，无法说明事物的作用n描述二，功能性观点，说明事物可以利用的价值，需要人去使用n描述三，使用者的观点，说明事物对于使用者的意义，以及使用者可以怎样去使用它，得到什么样的利益。不能说明事物的本质，只能揭示表面作用。n功能是脱离使用者愿望而存在的，用例是描述使用者愿望的。n功能是孤立的，有输入就有一个输出，用例描述的是一个系统性的工作。目标和步骤的误区3.2.6 用例之间的关联n继承关系2 扩展关联 3 包含关联4 使用关联 5 泛化关联UML系统建模与分析设计3.2.7 用例图实例活动图活动图 概述n活动是某件事情正在进行的状态。n活动图是一种描述系

15、统行为的图，它用于展现参与行为的对象所进行的各种活动的顺序关系。n活动图着重表现从一个活动到另一个活动的控制流，是内部处理驱动的流程。活动图的图形表示n在UML中，活动表示成圆角矩形。n如果一个活动引发下一个活动，两个活动的图标之间用带箭头的直线连接。n活动图有起点和终点。n活动图中还包括分支与合并、分叉与汇合等模型元素。分支与合并的图标和状态图中的判定的图标相同，而分叉与汇合则用一条加粗的线段表示。活动n业务流程中的一个执行单元n特定事件：nentry，进入活动时要执行的动作nDo，活动执行过程中要进行的动作（方法）nEvent，执行中接收到某个事件时执行的动作nExit，退出活动时要进行的

16、动作迁徙（流）n所有动作状态之间的转换流称之为动作流。 n与状态图的转换相同，活动图的转换也用带箭头的直线表示，箭头的方向指向转入的方向。 条件判定（决策）同步n显示业务用例的工作流程中的并行线程； n分叉用于将动作流分为两个或者多个并发运行的分支；n汇合则用于同步这些并发分支，以达到共同完成一项事务的目的；n理解：q汇合代表两个或多个并发控制流同步发生，当所有的控制流都达到汇合点后，控制才能继续往下进行。每个汇合可以有两个或多个输入转换和一个输出转换；q分叉可以用来描述并发线程，每个分叉可以有一个输入转换和两个或多个输出转换，每个转换都可以是独立的控制流；同步组合活动活动图的问题：谁在执行？泳道（swimlane）n对活动图中的活动分组，并把每一组指定给负责这组活动的业务组织即对象；n泳道区分了负责活动的对象，明确地表示了哪些活动是由哪些对象进行的；n每个活动只能明确地属于一个泳道；n泳道没有顺序，不同泳道中的活动既可以顺序进行也可以并发进行，动作流和对象流允许穿越分隔线。 泳道（swimlane）泳道图活动图n存款带角色职责的活动图活动图与流程图的区别n流程图着重描述处理过程，它的主要控制结构是顺序、分支和循环，各个处理之间有严格的顺序和时间关系；而活动图描述的则是对象活动的顺序关系所遵