《编写用例叙述.ppt》由会员分享，可在线阅读，更多相关《编写用例叙述.ppt（100页珍藏版）》请在三一办公上搜索。
1、第1章 业务建模(续),系统分析师UML用例实战,如何写用例,也称之为用况，是一个描述型文档，用来描述一个参与者（一个外部的主动者）使用系统完成某个过程时的事件发生顺序。通俗而言，用例就是如何使用系统来达到目标的一组情节，其本质是通过写出多种使用系统的情节来发现和记录功能性需求,简单有效,怎么开始？,讲“故事”高层用例写出多种使用系统的情节由一两个人写出一个简短而完整的描述，如：,用例：购买商品参与者：顾客、出纳员类型：主要的用例（次要的、可任选的）描述：顾客带着所要购买的商品来到收款处。收银员记录下商品信息并收款。付款结束后，顾客带着所购买的商品离开。,起点。终点,2.1 描述用例,用例描述
2、了系统和它的用户之间在一定层次上的完整的交互在用例的不同实例中将发生什么样的细节，会在很多方面有所不同一个用例实例中可能会出现差错，将不能达到原来的目的一个用例的完整描述必须指明，在用例所有可能的实例中可能发生什么,2.1 描述用例,用例描述可能包含大量信息，需要某种系统的方法来记录这些信息UML没有定义一种描述用例的标准形式许多开发人员定义了用例描述的模板,归档用例,基本用例每一个用例必须包含这样一些细节，这些细节告诉人们需要完成哪些步骤才能实现这个用例的功能基本功能所有可选方案异常情况进入用例之前以及退出用例时必须正确的一切,一个用例格式模版,主要参与者涉众及其兴趣前置条件成功后的保证（后
3、置条件）主要成功场景（或基本流程）扩展（或替代流程）特殊需求技术与数据的变化列表,参与者与涉众的关系,涉众也称干系人,是与要建设的这个系统有利益相关的一切人和事,涉众的利益要求会影响系统的建设。涉众不等于用户。涉众建议并界定了系统必须要做的工作。用例应该满足包含所有涉众关注点的事物。,参与者、涉众、用户和角色的关系,涉众（续）,如系统进行处理销售用例中，主要参与者是收银员，那么涉众有什么呢？,收银员,售货员,顾客,公司,经理,政府税收代理,支付授权服务,前置条件和后置条件,前置和后置条件表示用例开始状态和结束会发生什么前置：规定了在用例中的一个场景开始之前必须为“真”的条件后置：规定了在用例中
4、的一个场景成功结束后必须为“真”的条件,这一“保证”应该满足所有项目涉众的需要,以记录销售为例,前置条件：什么情况下销售员可以记录销售？收银员必须已经被识别和授权？系统启动？,以记录销售为例,后置条件：记录销售完成后，系统要达到什么状态？存储销售信息生成收据更新账目和库存准确计算税金,事件路径,用例描述必须定义在执行用例时用户和系统之间可能的交互基本事件路径：用例的主要目标可以没有任何问题并且不中断地到达可选的事件路径：一些可选的功能会被调用例外的事件路径：发生错误时的处理,主要的成功场景和步骤（基本路径）,它描述了能够满足项目相关人员兴趣的典型的成功路径参与者与系统的交互一个验证动作由系统完
5、成的状态改变（第一个步骤用来指示一个用来开始场景的触发事件）,Happy Path,“当.时用例开始”,事件路径要记录的重要事情是用户输入到系统的信息，而不是该信息是如何获得的。包含上下文的交互（情景对话）会降低用例的可复用性,基本事件路径,例，网上订货基本路径,1.当客户选择订购货物时用例开始2.客户输入他的姓名和地址3.客户输入产品代码4.系统记录单件商品，并显示该商品的描述、价格和累加值。价格可以根据一套定价规格来计算客户重复3-4步，直到结束5.客户输入支付信息6.客户确认订购7.系统检验输入的信息，把该订单作为未完成的交易保存，同时向记账系统提供支付信息8.支付确认后，订单被标记上已
6、经确认，同时返回给客户一个订单ID，用例结束,参与者与系统相互交互，完成整个用例流程,1.顾客携带购买的商品到达POS机收费口2.收银员开始一次新的销售3.收银员输入商品标识4.系统记录单件商品，并显示该商品的描述、价格和累加值。价格可以根据一套定价规格来计算收银员重复3-4步，直到结束5.系统显示总值并计算税金6.收银员请顾客付款7.顾客支付，系统处理支付8.系统记录完整的销售信息，并将销售和付款信息发送到外部的记账系统（进行记账）和库存系统9.系统打印收据10.顾客带着商品和收据离开,处理销售基本路径,可选事件路径描述的情况，可以作为营业的一个正常部分出现，它们并没有指出产生了误解，或者发
7、生了错误因为一个错误和用户的疏忽而不可能完成基本事件路径，这些情况将由例外事件路径描述,可选事件路径,不同类型的事件路径之间区分是非正式的，它可以使用例的总体描述组织得更容易理解不值得花过多时间去决定一个特定的情况是可选的还是例外的，更重要的是一定要确认给出了必须行为的详细描述,例外事件路径（续）,扩展,扩展（替代/可选流程）,扩展场景是从主要成功场景中分支出来的，因此应该遵从主要成功场景的标记方式,3.收银员输入商品标识,3a.非法的标识 1.系统指示错误并拒绝输入,3b.有多个具有相同商品类别的信息（如5条A式毛巾），不需要跟踪每个商品的唯一身份 1.收银员可以输入商品类别的标识和数量,扩
8、展,一个扩展以两个部分组成：条件和处理,寻找扩展路径的方法P73,方法一：沿着基本路径一条一条地找，并且考虑：在这个点上还可以执行别的活动吗？在这个点上有没有什么可能出错的？有什么随时可能发生的行为吗？,寻找扩展路径的方法P73,方法二：用以下大类去发现可选路径,如何描述扩展？,描述指导原则：以系统或参与者能够监测到的某事物作为条件,系统检测到与外部的税金计算系统的通信故障,外部的税金计算系统工作不正常,扩展处理也可以包含一系列步骤：,3.收银员输入商品标识4.系统记录单件商品，并显示该商品的描述、价格和累加值。价格可以根据一套定价规格来计算收银员重复3-4步，直到结束5.系统显示总值并计算税
9、金6.收银员请顾客付款,3-6,角色与头衔？,说法一：参与者用角色命名比用职务头衔命名更好。不同职务的用户，都具有可以启动相同用例的权限，因此形成多个参与者关联到相同用例的情况，造成用例图标上的混乱。P51,角色与头衔？,说法二：职务头衔对用户而言，直接且总所周知。即使用了角色，也需要说明哪些职务头衔可以扮演哪些角色P51,角色与头衔？,折中办法：P52使用职务头衔，不过在用例图标上仅留下最重要的参与者，但在用例描述中列出哪些参与者可以启动该用例,多个参与者指向同一个用例？,指的是这几个参与者同时参与到一个用例中。P53,用例和参与者之间的连线,表示通讯关系，即参与者和系统的相互通信不表示信息
10、或数据流向。,用例易学难精,十项需避免的错误P100,包含为了避免重复，把重复的行为放在一个用例中，原有的用例再引入该用例，这样，就在用例间建立了包含关系。非EBP级别的用例抽象用例,登录,？,用例包含P111,用例包含,注意：因为子用例被抽出，基用例并非一个完整的用例，所以include关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行。include关系在用例图中使用带箭头的虚线表示(在线上标注)，箭头从基用例指向子用例。,用例包含,P111,查询订购交易,取消订购,include,查询订购交易,取消订购,include,退货,用例包含,不用把用例关系搞得太复杂，也别把用例叙述
11、分割得太零散，以免失去了用例叙述清晰明确且易读的特点与目标,泛化,泛化是一个“种属”关系，其中一个元素是其他元素的一种。执行者之间的泛化意味着一个执行者可以完成另一个执行者的同样的任务，他也可能补充额外的角色，他以同样的方式与相同的用例进行交互用例之间的泛化意味着一个用例是另一个用例的特殊的版本。这个特殊的用例从一个通用用例中继承行为或者增加行为。,一个简单的订购泛化实例,订购货物,网上订购,电话订购,获得订单的状态,运行销售报表,会员,经理,复杂扩展使用一个单独的用例来表达这个扩展，,基用例,用例扩展P114,extend关系是对基用例的扩展，基用例是一个完整的用例，即使没有子用例的参与，也
12、可以完成一个完整的功能。extend的基用例中将存在一个扩展点，只有当扩展点被激活时，子用例才会被执行。extend关系在用例图中使用带箭头的虚线表示(在线上标注)，箭头从子用例指向基用例。,用例扩展,例：“信用卡支付”,信用卡支付,extend,P116,extend,extend,订购书籍,贵宾折扣,特价折扣,高级登录问题P155,在用例中归档登录的四种方法登录包含其他用例其他用例包含登录其他用例扩展登录登录独立于其他用例,登录包含其他用例,1.销售员启动应用程序时用例开始。2.系统提示销售员输入用户名和密码3.销售员输入用户名和密码4.系统验证销售员有效5.销售员不选择退出时，以任意顺序
13、执行以下几点 5.1选择处理销售 5.2选择处理租贷6.用例结束,登录包含其他用例,优点：销售登录后，可以访问所有允许访问的系统功能缺点：假如你想向系统增加一些新的用例，你必须改变这一用例，从维护的角度看，容易忘记对登录进行更改；另外，如果采用这种方式，登录必须了解系统所有其他模块的知识。,其他用例包含登录,1.当销售员登录系统时，用例开始（包含登录）2.,其他用例包含登录,优点：登录的用例只描述了登录，别无其他内容。缺点：客户每次做不同的动作之前都必须登录，时间长了这会是一个很烦人的问题。,其他用例扩展登录,1.当销售员启动应用时用例开始2.系统提示销售员输入用户名和密码3.系统验证其是否是
14、有效用户4.销售员不选择退出时5.扩展点：6.循环结束7.用例结束,其他用例扩展登录,优点：客户登录一次后，就获得了对系统其他部分的访问。当你需要添加一个新的用例时，在登录添加一个扩展点就够了，你不需要对它作任何改变。缺点：需要评审文档的人员描述清楚，别人很难清楚他们的关系，尤其是那些非开发人员,登录作为一个独立的用例,1.当销售员启动应用时用例开始2.系统提示客户输入用户名和密码3.销售员输入用户名和密码4.系统验证用户有效性5.用例结束,登录作为一个独立的用例,如果要使用该用例，则只要在其他用例中包含一个前置条件，在用户登录有效后才能执行。优点：登录的用例只描述了登录，别无其他内容。图标文
15、本清晰、简单易懂，系统灵活性得到提高。现在订购货物不需要登录去执行，只需要是有效用户即可。执行登录是获得有效用户的一种方法，但是也有其他验证方法,思考：如何处理时间？,在一些系统中，某些活动发生在特定的时间。如每天晚上10：00打印一个系统报告，或者每周末进行一次自动数据转移。那么在用例中怎么来处理时间呢？,方法：把时间当作一个执行者，然后，时间执行者可以启动用例。,数据转移,晚上10：00,特殊要求,特殊要求：如果有一些与此用例有关的非功能需求（象质量属性或约束条件），那么将它们和用例记录在一起。,在大型平板显示器上的触摸屏界面。文本信息要能够在1米之外看清90%的信用卡授权机构的响应应该在
16、30秒收到,技术和数据的变化列表,技术和数据的变化列表：系统通常有一些技术上的变化是关于“应该怎么做”，而不是“应该做什么”，需要在用例中将这种变化记录下来。,“预约日期可以选择”“顾客姓名可以选择”“可以用条码扫描器或键盘输入商品id”,建立一个领域模型领域模型添加关联领域模型添加属性,4.6 领域建模（概念模型）,领域模型：显示最重要的业务概念和它们之间的关系的类图领域模型用关联和泛化显示了这些概念之间的关系。领域模型通常不包含操作,简介,它是真实世界中各个事物的表示，而不是软件中各构件的表示。,领域模型是现实世界的一个可视化抽象字典它可视化了领域中的单词或概念类，并为这些单词或概念类建立
17、了关联领域模型是没有方法的类图的集合，并且在领域模型中不会出现软件工件,关键思想,怎样识别概念类？,识别概念的实用指导原则 最好是能够尽量充分地用细粒度地概念来描述模型，而避免粗略描述。识别概念的方法 a、使用概念类分类列表来找出概念；b、根据名词性短语识别出概念类；,识别与当前设计场景相关的概念类,领域模型中的概念类越多越好,从用例中识别概念1、用例描述中出现了哪些实体？2、用例执行过程中会产生并存储哪些信息？3、用例要求与之关联的每个角色的输入是什么？输入可能是角色的属性，也有可能是单独的一个类。4、用例反馈与之关联的每个角色的输出是什么？首先确定该输出的责任实体，然后进一步确认输出是否需
18、要识别为类。5、用例需要操作哪些设备？,使用概念类分类列表来找出概念,有时很难决定是应该将一个特殊的信息作为一个类还是作为一个属性包含在领域模型中属性应该是简单的数据类型。复杂的问题域概念应该被识别为概念。,属性还是概念？,以“记录预约”为例,(1)接待员输入要预约的日期；(2)系统显示该日的预约；(3)接待员输入顾客的姓名和电话号码、预约的时间、用餐人数和餐桌号；(4)系统记录并显示该预约。,候选概念类：,接待员,预约,顾客,顾客,餐桌,概念类图描述了系统中的概念类及其相互之间的各种关系。概念类之间的关系表示了对象之间的通信能力。类之间有三种关系：关联（包括聚合和组合）继承依赖,关联,定义关
19、联是类（确切的说是类的实例）之间用来指示有意义或者值得关注的一种关系,UML定义：两个或多个类元之间有关其实例当中连接的语义关系,关联,有用的关联对象之间的关系要保存一段时间的关联（“需要记住”型关联）。,找出关联的方法关联列表,关联的UML表示法,用一条写着关联名称的线段来表示两个类之间的关联.关联自然具有双向性,这意味着从关联两端的任何一个类的实例出发在逻辑上都是可以达到另一端.关联的每一端都可以包含一个多重性的表达式,它表示两个类的实例之间的数量关系.,规定关联的重数，每个预定是由一个顾客进行的，这个人的姓名和电话由系统记录，但是每个顾客可以进行多个预定,Customer,Reserva
20、tion,Makes,1,*,name,phoneNumber,顾客和预定建模,导读箭头,关联名,多重性,角色和多重性,关联所联系的每一端叫做一个角色。角色可以可选的具有：名称多重性表达式导航,Register,sale,1,1,Records-current,角色,person,1,*,角色,manager,woker,Manage,角色和多重性,多重性定义了一个类型A的实例在特定时刻（而不是在某个时间跨度内）能够合多少个类型B的实例发生关联。如：Store的一个实例可以和Item的多个实例发生关联,Sale,Item,Stocks,1,*,建立关联的原则,a、注意力集中在那些需要将概念之间
21、的关系信息记忆一段时间的关联上（“需要记住”型关联）。b、识别出概念类比识别出关联更为重要。c、关联太多不仅不能有效展示概念模型，反而会使概念模型变得混乱。d、要避免关联之间的信息冗余以及减少派生关联。,建立关联的原则,e、概念模型概念间的关联是从纯分析角度声明有意义的概念间的联系，不需要考虑如何实现关联。f、分析阶段得到的关联可能在设计阶段发现是无用的；设计阶段有可能发现分析阶段遗漏了有些概念间的关联。,花费在领域模型创建的大部分时间应该被用于识别概念类，而非关联,关联限定关联、约束,在关联中加入限定成分，通过这个限定成分可以唯一识别多样性为多端的所有对象，使得对对象的定位容易和有效。,销售
22、,销售项,产品,1,对一次销售的每一项产品，在另一端可能有一个销售项与其对应，或可能没有订单行与其对应。如果没有这个限定符，给定一份订单，对应的某一项产品可能有多行销售项,关联关联之间的约束,“或”限定：表示两个关联不能同时存在,关联反身关联,如何表示？,关联关联类,二元关联不属于其两端的任一类，而是两个类共有的关系Rumbaugh,1991。关联本身也有其属性和操作，因此可以用一个类来模拟关联类。,关联关联类,关联类和其他类相似。只不过一般类描述的是实体，而关联类描述的是关系。当你见到多对多关联，则需要考虑使用关联类,关联关联类,职务,除了二元关联，还有三元关联、多元关联,多重性0.2表明，
23、每一个人在指定年度最多只可以参与两个委员会。而多重性3.5则说，每个年度的委员会，要由35个人当委员。多重性1.4表明，同一委员会中，每个人任职不能超过4年。,继承,继承,Disjoint：一个Employee不可能既是Manager又不是Manager。Complete：一个Employee要么是一个Manager，要么是一个NonManager。Dynamic：一个Employee可能会从Manager变成非Manager，反之亦然。,子类的划分,属性,属性及其UML表示（1）定义：属性是某个对象的逻辑数据值。（2）在一个概念模型中包括如下属性：在需求说明（例如用例）中提示或暗示我们要记住
24、的那些信息。（3）属性的UML表示,SaleDatetime,属性表示法,属性的完整语法是：可见性 属性名：类型 多重性=默认值特性表,SaleDatetime/total:Money,属性的识别,1）首先从类的语义完整性角度列举出类的候选属性；2）针对系统目标和类在系统中的作用以及问题域相关特性对类的候选属性进行一次筛选；属性的识别要根据具体的问题域，同一实体在不同的系统中识别出来的属性会不一样图书馆系统：不关注头发颜色、眼睛颜色；公安局侦察管理系统：头发颜色、眼睛颜色、指纹等,导出属性,在属性名称前加以”/”符号,SaleLineItem,Item,Records-sale-of,0.1,
25、1,SaleLineItem的quantity信息可以 从多重性的实际值导出,又如Sale类的total属性可以由SaleLineItem和ProductDescription的信息导出,从多重性值导出的属性,选择有效的属性类型,属性应该是简单的数据类型。复杂的问题域概念应该被识别为概念。,收银员姓名收银台,非“简单”属性,收银员姓名,收银台编号,Uses,1,1,更好,选择有效的属性类型,保持简单的数据类型,属性常见的简单数据类型包括：布尔、日期、数字、字符串或文本、时间 其他如：地址、颜色、几何元素、电话号码、身份证号、通用商品代码、邮政编码等,较差,较好,定义新的数据类型,数据类型原始数
26、据类型：数字、字符串、布尔、日期或时间把它当作属性来看待非原始的数据类型:把它表示成一个单独的概念类,Product SpecificationId：ItemID,Storeaddress:Address,对数据类型建模的准则,由不同的小节组成具有与之相关的操作，例如解析或校验具有其他属性单位的数量,如电话号码，人名,如身份证号,如促销价格可能要记录起止日期,如支付金额,避免设计潜行：任何属性都不表示外健,在领域模型里,不应该使用属性来联系概念类.这个原则最常见的反例是添加一种外键属性(foreign key attribute),这是关系数据库设计中为了连接两种类型的典型做法.,Cashie
27、rnamecurrentRegisterNumber,1,1,Cashiername,Registernumber,Uses,应该使用关联而不是属性来将类型关联起来,为属性和单位建模,对属性的数量和单位建模：将数量和数量的单位分开，以提供设计灵活性。,Customer,Reservation,Makes,1,*,name,phoneNumber,covers,date,time,Table,places,1,*,Reservations for the same,table must not overlap.,包含预定特性的领域模型,包含未预约的领域模型,4.6.1 领域模型的正确性,要证明一
28、个模型的正确性或者即使是一个模型优于另一个模型，要更困难一些建立领域模型的目的是确定一组对象，他们能够以有效地支持整个系统必须交付的功能的方式进行交互。因此，要评价领域模型中可供选择的方式，可以从实现这一点的程度来进行而且不能通过孤立地检查领域模型而简单地评定，还必须通过观察领域模型中类的实例之间的交互实际上是如何支持需要的功能，考虑模型实际上表达了什么,4.7 术语表,预约(Booking)：分配一张餐桌给一行用餐者进餐用餐人数(Covers)：预定将来用餐的人数顾客(Customer)：进行预定的人用餐者(Diner)：在餐馆用餐的人位子(Places)：在一张特定餐桌能够就座的用餐者人数
29、预定(Reservation)：提前预约一个特定时间的餐桌未预约(Walk-in)：没有提前进行的预约,4.8 本章小结,在业务建模活动结束时，系统文档包含一个用例模型、对各个用例的文字描述、一个关键术语的术语表以及一个领域模型用例图描述了参与者和用例以及他们之间的各种关系用例表示了一类用户可以利用系统完成的典型任务,4.8 本章小结（续）,参与者表示了用户在与系统交互时可以充当的角色。参与者和用例的关联，表示以给定角色工作的用户能够执行哪些任务。参与者可以通过泛化相关，以明确地表示它们共享的能力一个用例可以包含另一个用例：意思是被包含用例规定的交互构成包含用例每次执行的一部分,一个用例可以扩展另一个用例：意思是扩展用例规定的交互构成被扩展用例一次执行的一个可选部分用例描述是文字形式的文档，详细描述在执行用例时在用户和系统之间可以发生的交互每个用例描述包含一个基本事件路径，描述用例的“正常”进行，以及一组可选和例外事件路径,4.8 本章小结（续）,领域模型显示重要的业务概念、它们之间的关系和由系统维护的业务数据。领域模型表示为类图，一般只显示类、属性、关联以及泛化术语表定义业务领域中的重要术语，为每个术语提供一个一致同意的定义，定义了应该在用例描述中使用的特定业务的词汇,4.8 本章小结（续）,
