系统分析与设计ch1用例图

浙江大学软件学院程学林1用例图

－－设计者必备开发流程User观点与开发人员观点分析师着重在定义出大小适度的用例，找出用例的参与者，描述参与者与系统之间的互动过程。到此为止，可以说都未涉入开发人员的观点；唯一涉入到开发人员观点的部份是，注意用例除了一般的启动者外，是否有其它在线的、扮演支持角色的系统参与者。从分析到设计设计师直接承接分析师提供的文件，进行下述的加工：用例图—放进开发人员的观点，使用包含关系和扩展关系，罗列出可以共享的部分，并且让用例图更为细致化。类图—分析师所生成的类图（域模型）通常跟实际工作平台有些差别，所以设计师要补上一些实际工作平台的概念。交互图（序列图）—在分析阶段的交互图并没有太重视消息上的参数，在设计阶段，每张交互图都要拿出来再检查一次，加上所需的参数。议程设计师必学元素识别用例关系对用例进行优先级排序估计工时实践与讨论识别用例关系用例关系包含关系扩展关系泛化关系用例间的关系只是简短的组织机制（促进理解和沟通、减少文本重复、改善用例文档的管理）不会对系统需求和行为产生影响但是，不要在分析用例图和用例关系上花太多时间，需求分析的主要工作是写文本识别用例关系通过关系提高用例的复用包含：提取公共交互，提高复用扩展：“冻结”基础用例以保持稳定泛化：同一业务目的的不同技术实现包含关系Anincluderelationshipdefinesthatausecasecontainsthebehaviordefinedinanotherusecase. FromUML2.0Specification包含关系不上厕所，这段路不完整30.1包含关系多个用例具有部分共同的行为非常常见UC1:处理销售…主成功场景:1.顾客到某个POS终端为购买的产品或服务付费…7.顾客支付，系统处理付款。…扩展:7b.用信用卡支付：包含“处理信用卡支付”用例。7c.用支票支付：包含“处理支票支付”用例。UC7:处理租金…扩展:6b.用信用卡支付：包含“处理信用卡支付”用例.UC12:处理信用卡支付…级别:子功能主成功场景:1.客户输入信用卡账户信息。2.系统向外部的支付授权服务系统发送支付授权请求。3.系统接收到同意支付的信息，并通知收银员。4..扩展:2.a系统与外部系统交互时检测到错误：

1.系统通知收银员发生错误。 2.收银员要求客户选择其他支付手段….IntheATMsystem,theusecasesWithdrawCash,DepositCash,andTransferFunds

allincludetheusecaseIdentifyCustomer.包含关系“发送电子邮件通知”用例包含关系Fowler给出了何时使用包含关系的简单且实用的准则：当在两个或多个独立用例中存在重复，而你想避免这种冗余时，可以使用包含关系。将过于冗长的用例简单地分解为子单元可以方便对其的理解。Cockburn建议：

使用包含关系来处理用例之间的关系是首要原则。示例：例如：业务中，总是存在着”维护某信息“的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。在异步事件处理中使用包含关系包含关系的另外一个用途：描述异步事件的处理。UC1:处理FooBars…主成功场景:1.…扩展:a*.任何时候，客户都可以选择编辑个人信息：编辑个人信息。b*.任何时候，客户都可以选择打印帮助：展现打印帮助。2-11.客户取消：取消交易确认。….30.2术语具体用例（ConcreteUseCase）由参与者发起，完成了参与者所期望的完整行为.

如”处理销售“.抽象用例（AbstractUseCase）永远不能被自己实例化如”信用卡支付“，不能独立存在基础用例（BaseUseCase）包含其他用例的用例，或者是被其它用例扩展或者泛化的用例，如”处理销售“.附加用例（AdditionalUseCase）被其他用例包含的用例，或者扩展、泛化其它用例的用例，如”信用卡支付“附加用例通常是抽象用例，基础用例通常是具体用例扩展关系Arelationshipfromanextendingusecasetoanextendedusecasethatspecifieshowandwhenthebehaviordefinedintheextendingusecasecanbeinsertedintothebehaviordefinedintheextendedusecase.

fromUML2.0Specification扩展关系不上厕所，也能赶路扩展关系“播放介绍影片”用例“缴纳罚金”用例示例：系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述图30-2扩展关系何时使用扩展用例增加扩展用例和扩展关系的最现实动机（或者可以说是最好的动机）就是：由于某种原因实在不能在基础用例上进行修改了。扩展路径步骤多扩展路径容易变化－－分离以“冻结”基用例扩展关系事实上，直接更新基础用例的扩展部分是推荐的方法，这样避免了创建复杂的用例关系扩展关系vs.包含关系扩展VS.包含的可见性扩展关系vs.包含关系包含关系扩展关系标示<<include>>的带箭头虚线标示<<extend>>的带箭头虚线基础用例指向被包含的小用例小用例指向被扩充的基础用例一定要执行小用例条件成立（扩展点）才执行小用例泛化关系泛化关系执行子用例的用例实例将遵循父用例的事件流，同时插入附加行为或修改在子用例事件流中定义的行为。示例：业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示。泛化关系识别用例关系除此之外，不能有别的关系30.5用例图图30-1用例模型中的用例包含关系：优先使用包含关系识别用例关系：讨论和练习在ATM机中，有查询、取现、转帐和打印回执等用例，他们之间的关系是。对于电话业务系统，包括基本通话(Call)、呼叫等待(CallWaiting)和呼叫转移(CallTransfer)等用例。识别用例关系：讨论和练习ATM机中…识别用例关系：讨论和练习电话业务系统…用例描述重点加工用例之间的关系—如果有使用包含关系和扩展关系的话，在用例描述处，就要记得说明。边界对象的沟通接口—参与者对象与边界对象之间的沟通接口，必须描述的更明确些。加入伪界面—如果分析师在项目一开始未绘制出伪界面的话，在设计师开始为分析文件细部加工的时候，最好已经绘制出伪界面了，这样就可以搭配用例描述把边界对象说得更详细些。更新BCE类—前面我们已经更新过实体类了，所以此时更新的重点会摆在边界类与控制类。对用例进行优先级排序-排序原则以下情况的用例优先级别最高A、对类图有重要影响B、包含丰富的业务过程信息和线索C、有开发风险、时间紧迫或功能复杂D、涉及到重要核心技术和新技术E、能直接产生经济效益或降低成本F、代表本系统的核心流程排序方法大量用例时的组织按参与者分包按主题分包按开发团队分包按发布情况分包可以先按主题分包，主题内再按开发团队和发布情况分包项目工时工时估算用例点计算公式用例点计算公式-Gustavkarner先生所提出的用例点公式，用来估算工时未经调整的用例点=参与者总权重+用例总权重技术复杂系数=0.6+(0.01*技术总权重)环境系数=1.4+(-0.03*环境总权重)用例点=未经调整的用例点*技术复杂系统*环境系数工时=用例点*20人时(或28人时)工时估算参与者权重值简单型参与者-这种类型的参与者通常是其他系统，采用程序接口与我们所开发的系统交互。加权值是1。一般型参与者-这种类型的参与者有两种：第一种是采用特殊协议交互的其他系统；第二种是采用文本模式交互的人类用户。加权值是2。复杂型的参与者就是我们常见的人类用户，采用丰富且亲和力高的图形界面。加权值是3。工时估算用例加权值（根据事务）事务：是指一组不可分割的活动，这些活动用么全部执行，要不就全部不执行。可理解为用例实例或场景简单型用例-这种类型的用例拥有至少3个的事务，它的权重值是5。一般型用例-这种类型的用例拥有4-7个的事务，它的加权值是10。复杂型用例-这种类型的用例拥有多于7个的事务，它的加权值是15。工时估算用例加权值（根据对象）简单型用例-这种类型使用了不少于5种分析对象，它的权重值是5。一般型用例-这种类型使用了5-10种分析对象，它的加权值是10。复杂型用例-这种类型使用了多于10种分析对象，它的加权值是15。工时估算——技术系统和加权值系数说明加权值T1分布式系统2T2响应时间（联网）1T3终端用户效能1T4复杂的内部处理1T5程序代码可重用程度1T6容易安装0.5T7容易使用0.5T8便于携带2T9容易更改1T10同步性1T11包含特殊的安全机制1T12提供直接访问给第三方1T13特殊的用户培训设施要求1强度等级评分：0是最弱的，3是中等强度，5是最强的等级工时估算环境系数和加权值系数说明加权值E1熟悉迭代式开发方法1.5E2应用领域的经验0.5E3面向对象的经验1E4分析师的能力0.5E5干劲1E6稳定的需求2E7兼职的工作人力-1E8困难的程序语言-1强度等级评分：0是最弱的，3是中等强度，5是最强的等级工时估算负面系数<=2项目的总负面系数个数少于或等于2时，可以采用20人时来估算。3~4可以采用28人时来估算。>=5项目失败的可能性非常高，最好可以调整项目，直到项目的负面系统个数降到5以下为止。E1~E6，强度等级低于３的个数；Ｅ７～Ｅ８，强度高于３的个数；两个数字相加，即为负面系数个数参与者权重工时估算例子－酒店订房系统酒店订房系统种类细项参与者人公司外部的人公司内部的人系统其他系统（内部）其他系统（外部）数据库事件硬件设备潜在会员、会员酒店经营者、系统管理员财务、人事系统银行系统、地图系统未知，有待整理时间未知，有待整理复杂参与者权重3（会员、酒店经营者、系统管理员）*3（加权值）＝9一般参与者权重3（银行系统、财务系统、人事系统）*2（加权值）＝6普通参与者权重3（潜在会员、地图系统、时间）*1（加权值）＝3参与者总权重=9+6+3=18用例总权重工时估算例子－酒店订房系统酒店订房系统酒店订房系统用例总权重=1（订房）*15+4（更改会员资料、通知已付定金、加入会员、订阅电子报）*10+4(登录、取消预定、查询空房、取消电子报)*5

=15+40+20=75未经调整的用例点=参与者总权重+用例总权重=

18+75=93工时估算例子－酒店订房系统技术复杂系数=0.6+(0.01*技术总权重)技术总权重=(2*4)+(1*4)+(1*5)+(1*3)+(1*4)+(0.5*5)+(0.5*5)+(2*1)+(1*4)+(1*3)+(1*3)+(1*4)+(1*0)=45技术复杂系数=0.6+(0.01*45)=1.05系数说明加权值/强度等级T1分布式系统2/4T2响应时间（联网）1/4T3终端用户效能1/5T4复杂的内部处理1/3T5程序代码可重用程度1/4T6容易安装0.5/5T7容易使用0.5/5T8便于携带2/1T9容易更改1/4T10同步性1/3T11包含特殊的安全机制1/3T12提供直接访问给第三方1/4T13特殊的用户培训设施要求1/0强度等级评分：0是最弱的，3是中等强度，5是最强的等级工时估算例子－酒店订房系统环境系数=1.4+(-0.03*环境总权重)环境总权重=(1.5*3)+(0.5*4)+(1*3)+(0.5*4)+(1*5)+(2*4)+(-1*4)+(-2*2)=18.5环境系数=1.4+(-0.03*18.5)=0.845系数说明加权值/强度等级E1熟悉迭代式开发方法1.5/3E2应用领域的经验0.5/4E3面向对象的经验1/3E4分析师的能力0.5/4E5干劲1/5E6稳定的需求2/4E7兼职的工作人力-1/4E8困难的程序语言-1/2强度等级评分：0是最弱的，3是中等强度，5是最强的等级工时估算例子－酒店订房系统<=2项目的总负面系数个数少于或等于