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