2编写用例叙述1知识课件

《2编写用例叙述1知识课件》由会员分享，可在线阅读，更多相关《2编写用例叙述1知识课件（100页珍藏版）》请在金锄头文库上搜索。

1、第1章 业务建模(续),系统分析师UML用例实战,如何写用例,也称之为用况，是一个描述型文档，用来描述一个参与者（一个外部的主动者）使用系统完成某个过程时的事件发生顺序。 通俗而言，用例就是如何使用系统来达到目标的一组情节，其本质是通过写出多种使用系统的情节来发现和记录功能性需求,简单有效,怎么开始？,讲“故事”高层用例 写出多种使用系统的情节由一两个人写出一个简短而完整的描述，如：,用例：购买商品 参与者：顾客、出纳员 类型：主要的用例（次要的、可任选的） 描述：顾客带着所要购买的商品来到收款处。收银员记录下商品信息并收款。付款结束后，顾客带着所购买的商品离开。,起点。终点,2.1 描述用例

2、,用例描述可能包含大量信息，需要某种系统的方法来记录这些信息 UML没有定义一种描述用例的标准形式 许多开发人员定义了用例描述的模板,归档用例,基本用例 每一个用例必须包含这样一些细节，这些细节告诉人们需要完成哪些步骤才能实现这个用例的功能 基本功能 所有可选方案 异常情况 进入用例之前以及退出用例时必须正确的一切,一个用例格式模版,主要参与者 涉众及其兴趣 前置条件 成功后的保证（后置条件） 主要成功场景（或基本流程） 扩展（或替代流程） 特殊需求 技术与数据的变化列表,参与者与涉众的关系,涉众也称干系人,是与要建设的这个系统有利益相关的一切人和事,涉众的利益要求会影响系统的建设。 涉众不等

3、于用户。 涉众建议并界定了系统必须要做的工作。用例应该满足包含所有涉众关注点的事物。,参与者、涉众、用户和角色的关系,涉众（续）,如系统进行处理销售用例中，主要参与者是收银员，那么涉众有什么呢？,收银员,售货员,顾客,公司,经理,政府税收代理,支付授权服务,前置条件和后置条件,前置和后置条件表示用例开始状态和结束会发生什么 前置：规定了在用例中的一个场景开始之前必须为“真”的条件 后置：规定了在用例中的一个场景成功结束后必须为“真”的条件,这一“保证”应该满足 所有项目涉众的需要,以记录销售为例,前置条件：什么情况下销售员可以记录销售？ 收银员必须已经被识别和授权？ 系统启动？,以记录销售为例

4、,后置条件：记录销售完成后，系统要达到什么状态？ 存储销售信息 生成收据 更新账目和库存 准确计算税金,事件路径,用例描述必须定义在执行用例时用户和系统之间可能的交互 基本事件路径：用例的主要目标可以没有任何问题并且不中断地到达 可选的事件路径：一些可选的功能会被调用 例外的事件路径：发生错误时的处理,主要的成功场景和步骤（基本路径）,它描述了能够满足项目相关人员兴趣的典型的成功路径 参与者与系统的交互 一个验证动作 由系统完成的状态改变 （第一个步骤用来指示一个用来开始场景的触发事件）,Happy Path,“当.时用例开始”,事件路径要记录的重要事情是用户输入到系统的信息，而不是该信息是如

5、何获得的。 包含上下文的交互（情景对话）会降低用例的可复用性,基本事件路径,例，网上订货基本路径,1.当客户选择订购货物时用例开始 2.客户输入他的姓名和地址 3.客户输入产品代码 4.系统记录单件商品，并显示该商品的描述、价格和累加值。价格可以根据一套定价规格来计算 客户重复3-4步，直到结束 5.客户输入支付信息 6.客户确认订购 7.系统检验输入的信息，把该订单作为未完成的交易保存，同时向记账系统提供支付信息 8.支付确认后，订单被标记上已经确认，同时返回给客户一个订单ID，用例结束,参与者与系统相互交互，完成整个用例流程,1.顾客携带购买的商品到达POS机收费口 2.收银员开始一次新的

6、销售 3.收银员输入商品标识 4.系统记录单件商品，并显示该商品的描述、价格和累加值。价格可以根据一套定价规格来计算 收银员重复3-4步，直到结束 5.系统显示总值并计算税金 6.收银员请顾客付款 7.顾客支付，系统处理支付 8.系统记录完整的销售信息，并将销售和付款信息发送到外部的记账系统（进行记账）和库存系统 9.系统打印收据 10.顾客带着商品和收据离开,处理销售基本路径,可选事件路径描述的情况，可以作为营业的一个正常部分出现，它们并没有指出产生了误解，或者发生了错误 因为一个错误和用户的疏忽而不可能完成基本事件路径，这些情况将由例外事件路径描述,可选事件路径,不同类型的事件路径之间区分

7、是非正式的，它可以使用例的总体描述组织得更容易理解 不值得花过多时间去决定一个特定的情况是可选的还是例外的，更重要的是一定要确认给出了必须行为的详细描述,例外事件路径（续）,扩展,扩展（替代/可选流程）,扩展场景是从主要成功场景中分支出来的，因此应该遵从主要成功场景的标记方式,3.收银员输入商品标识,3a.非法的标识 1.系统指示错误并拒绝输入,3b.有多个具有相同商品类别的信息（如5条A式毛巾），不需要跟踪每个商品的唯一身份 1.收银员可以输入商品类别的标识和数量,扩展,一个扩展以两个部分组成：条件和处理,寻找扩展路径的方法P73,方法一：沿着基本路径一条一条地找，并且考虑： 在这个点上还可

8、以执行别的活动吗？ 在这个点上有没有什么可能出错的？ 有什么随时可能发生的行为吗？,寻找扩展路径的方法P73,方法二：用以下大类去发现可选路径,如何描述扩展？,描述指导原则：以系统或参与者能够监测到的某事物作为条件,系统检测到与外部的税金计算系统的通信故障,外部的税金计算系统工作不正常,扩展处理也可以包含一系列步骤：,3.收银员输入商品标识 4.系统记录单件商品，并显示该商品的描述、价格和累加值。价格可以根据一套定价规格来计算 收银员重复3-4步，直到结束 5.系统显示总值并计算税金 6.收银员请顾客付款,3-6,角色与头衔？,说法一：参与者用角色命名比用职务头衔命名更好。 不同职务的用户，都

9、具有可以启动相同用例的权限，因此形成多个参与者关联到相同用例的情况，造成用例图标上的混乱。 P51,角色与头衔？,说法二：职务头衔对用户而言，直接且总所周知。即使用了角色，也需要说明哪些职务头衔可以扮演哪些角色P51,角色与头衔？,折中办法：P52 使用职务头衔，不过在用例图标上仅留下最重要的参与者，但在用例描述中列出哪些参与者可以启动该用例,多个参与者指向同一个用例？,指的是这几个参与者同时参与到一个用例中。P53,用例和参与者之间的连线,表示通讯关系，即参与者和系统的相互通信 不表示信息或数据流向。,用例易学难精,十项需避免的错误P100,包含 为了避免重复，把重复的行为放在一个用例中，原

10、有的用例再引入该用例，这样，就在用例间建立了包含关系。 非EBP级别的用例 抽象用例,登录,？,用例包含P111,用例包含,注意：因为子用例被抽出，基用例并非一个完整的用例，所以include关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行。include关系在用例图中使用带箭头的虚线表示(在线上标注)，箭头从基用例指向子用例。,用例包含,P111,查询订购交易,取消订购,include,查询订购交易,取消订购,include,退货,用例包含,不用把用例关系搞得太复杂，也别把用例叙述分割得太零散，以免失去了用例叙述清晰明确且易读的特点与目标,泛化,泛化是一个“种属”关系，其中一个

11、元素是其他元素的一种。 执行者之间的泛化意味着一个执行者可以完成另一个执行者的同样的任务，他也可能补充额外的角色，他以同样的方式与相同的用例进行交互 用例之间的泛化意味着一个用例是另一个用例的特殊的版本。这个特殊的用例从一个通用用例中继承行为或者增加行为。,一个简单的订购泛化实例,订购货物,网上订购,电话订购,获得订单 的状态,运行销售 报表,会员,经理,复杂扩展 使用一个单独的用例来表达这个扩展，,基用例,用例扩展P114,extend关系是对基用例的扩展，基用例是一个完整的用例，即使没有子用例的参与，也可以完成一个完整的功能。 extend的基用例中将存在一个扩展点，只有当扩展点被激活时，

12、子用例才会被执行。 extend关系在用例图中使用带箭头的虚线表示(在线上标注)，箭头从子用例指向基用例。,用例扩展,例： “信用卡支付”,信用卡支付,extend,P116,extend,extend,订购书籍,贵宾折扣,特价折扣,高级登录问题P155,在用例中归档登录的四种方法 登录包含其他用例 其他用例包含登录 其他用例扩展登录 登录独立于其他用例,登录包含其他用例,1.销售员启动应用程序时用例开始。 2.系统提示销售员输入用户名和密码 3.销售员输入用户名和密码 4.系统验证销售员有效 5.销售员不选择退出时，以任意顺序执行以下几点 5.1选择处理销售 5.2选择处理租贷 6.用例结束

13、,登录包含其他用例,优点：销售登录后，可以访问所有允许访问的系统功能 缺点：假如你想向系统增加一些新的用例，你必须改变这一用例，从维护的角度看，容易忘记对登录进行更改；另外，如果采用这种方式，登录必须了解系统所有其他模块的知识。,其他用例包含登录,1.当销售员登录系统时，用例开始（包含登录） 2.,其他用例包含登录,优点：登录的用例只描述了登录，别无其他内容。 缺点：客户每次做不同的动作之前都必须登录，时间长了这会是一个很烦人的问题。,其他用例扩展登录,1.当销售员启动应用时用例开始 2.系统提示销售员输入用户名和密码 3.系统验证其是否是有效用户 4.销售员不选择退出时 5.扩展点： 6.循

14、环结束 7.用例结束,其他用例扩展登录,优点：客户登录一次后，就获得了对系统其他部分的访问。当你需要添加一个新的用例时，在登录添加一个扩展点就够了，你不需要对它作任何改变。 缺点：需要评审文档的人员描述清楚，别人很难清楚他们的关系，尤其是那些非开发人员,登录作为一个独立的用例,1.当销售员启动应用时用例开始 2.系统提示客户输入用户名和密码 3.销售员输入用户名和密码 4.系统验证用户有效性 5.用例结束,登录作为一个独立的用例,如果要使用该用例，则只要在其他用例中包含一个前置条件，在用户登录有效后才能执行。 优点：登录的用例只描述了登录，别无其他内容。图标文本清晰、简单易懂，系统灵活性得到提

15、高。现在订购货物不需要登录去执行，只需要是有效用户即可。执行登录是获得有效用户的一种方法，但是也有其他验证方法,思考：如何处理时间？,在一些系统中，某些活动发生在特定的时间。如每天晚上10：00打印一个系统报告，或者每周末进行一次自动数据转移。那么在用例中怎么来处理时间呢？,方法：把时间当作一个执行者，然后，时间执行者可以启动用例。,数据转移,晚上10：00,特殊要求,特殊要求：如果有一些与此用例有关的非功能需求（象质量属性或约束条件），那么将它们和用例记录在一起。,在大型平板显示器上的触摸屏界面。文本信息要能够在1米之外看清 90%的信用卡授权机构的响应应该在30秒收到 ,技术和数据的变化列

16、表,技术和数据的变化列表：系统通常有一些技术上的变化是关于“应该怎么做”，而不是“应该做什么”，需要在用例中将这种变化记录下来。,“预约日期可以选择” “顾客姓名可以选择” “可以用条码扫描器或键盘输入商品id”,建立一个领域模型 领域模型添加关联 领域模型添加属性,4.6 领域建模（概念模型）,领域模型：显示最重要的业务概念和它们之间的关系的类图 领域模型用关联和泛化显示了这些概念之间的关系。领域模型通常不包含操作,简介,它是真实世界中各个事物的表示，而不是软件中各构件的表示。,领域模型是现实世界的一个可视化抽象字典 它可视化了领域中的单词或概念类，并为这些单词或概念类建立了关联 领域模型是没有方法的类图的集合，并且在领域模型中不会出现软件工件,关键思想,怎样识别概念类？,识别概念的实用指导原则 最好是能够尽量充分地用细粒度地概念来描述模型，而避免粗略描述。 识别概念的方法 a、使用概念类分类列表来找出概念； b、根据名词性短语识别出概念类；,识别与当前设计场景相关的概念类,领域模型中的概念类越多越好,