大象thinkinginuml读书笔记

1、大象 thinking in uml 读书笔记 宝典 摘自大象 Thinking in UML 谭云杰一、参与者 (Actor 、主角 )( 一) 特点 :1) 业务建模的核心。它是涉众代表，代表涉众对系统的利益要求，并向系统 提出建设要求。系统是以参与者的观点决定的，他对系统的要求，对系统的表述完全决定 了系统的功能性。2) 参与者位于边界之外1. 谁对系统有着明确的目标和要求，并且主动发出动作 ,2. 系统是为谁服务的 ,3) 业务工人 (Business Worker)4) 参与者可以非人5) 涉众是发现参与者的重要来源6) 涉众 (Stakeholder) ，又称干系人，指与建设系统有

2、利益相关的一切人和 事，但涉众不一定是系统的参与者。参与者是涉众代表，他对系统的要求直接影响到系统的 建设，他们的要求就是系统需求的来源。参与者通过对系统提出要求来获得他所代表 的涉众的利益。由此可见，参与者也并不需要询问同一岗位所有人，而是找出可代表 该岗位的代表，与之沟通。7) 用户和参与者，用户是指系统的使用者，系统的操作员，他是参与者的代8) 角色是参与者的职责，是一个抽象的概念，从众多参与者的职责中抽象出 相同的一部分，将其定义一个角色。一般适用于概念阶段的模型，以表达业务的逻辑理 解。一个用户可以代理多个参与者，一个用户可以拥有多份职责，即可被指定多个角 色。( 二 ) 问题1)

3、谁负责提供、使用或删除信息 ,2) 谁将使用此功能 ,3) 谁对某个特定功能感兴趣 ,4) 在组织中的什么地方使用系统 ,5) 谁负责支持和维护系统 ,6) 系统有哪些外部资源 ,7) 其他还有哪些系统将需要与该系统进行交互 ,( 三 ) 版型1) 业务主角 (Business Actor)定义业务的参与者，在需求阶段使用，用来确定业务范围。非常重要，建立业 务模型、查找业务用例都须用业务主角。业务范围和系统范围不同，业务范围指项目涉及的所有客户业务，有些业务内 容没有系统参与也一样客观存在系统范围仅指软件要实现的业务功能。有些系统功能不在业务范围，如操作日业务主角针对业务人员，而非计算机用户

4、，也不应过早引入计算机系统的概 念，以免混淆，导致误导用户。业务主角必须在实际业务里能找到对应的岗位或人员。常用问题 : 业务主角的名称是否是客户的业务术语 , 业务主角的职责是否在客户的岗位手册里有对应的定义 , 业务主角的业务用例是否都是客户的业务术语 , 客户是否对业务主角能顺利理解 ,2) 业务工人 (Business Worker)BW被动参与业务。BW处于系统边界内。不需要为BW建立业务模型，只在主角的业务模型中出现。 虽然不参与业务建模，但他们仍然不可或缺，如领域模型、用例模型。缺少他 们业务模型就不完整，甚至不能运行。判断他是在边界之内和边界之外，常用问题 : 他是主动向系统发

5、出动作的吗 , 他有完整的业务目标吗 ,系统是为他服务的吗 ,是否(四)检查点(RUP官方文档，非常有助于检查发现的参与者是否正确 )1) 您已找到所有的参与者 , 也就是说，是否您已经对系统环境中的所有角色都进行 了说明和建模 , 虽然您应该检查这一点，但是要到您找到并说明了所有用例后 才能将其确定。2) 每个参与者是否至少涉及一个用例 , 删除未在用例说明中提及的所有参与 者，或与用例无通信关联关系的所有参与者。3) 您能否列出至少两名可以作为特定参与者的人员 , 如果不能，请检查参与者 所建模的角色是否为另一角色的一部分。如果是这样，您应该将该参与者与另一参与者 合并。4) 是否有参与者

6、担任与系统相关的相似角色 , 如果有，您应该将他们合并到一 个主角中。通信关联关系和用例说明表明参与者和系统是如何相互关联关系的。5) 是否有两个参与者担任与用例相关的同一角色 , 如果有，您应该利用参与者 泛化关系来为他们的共享行为建立模型。6) 特定的参与者是否将以几种 (完全不同的)方式使用系统 ,或者，他使用用例 是否出于几个(完全不同的 )目的,如果是这样，您也许应该有多几个参与者。7) 参与者是否有直观名称和描述性名称 , 用户和客户是否都能理解这些名称 , 参与者的名称务必要与其角色相符。否则，应对其进行更改。二、用例 (Use Case)用例是UML建模中最重要的元素。除了用例

7、外，所有其他元素都是“封装”、 “独立”的。这些元素在没有外力作用时，是“老死不相往来”的。用例正是施加这一“外 力”的元素，它使得其他各自独立的元素能共同组成一篇有意义的文字。用例是一种把现实世界的需求捕获下来的方法。首先有某人的一个愿望，这个 愿望驱使人去做事并获得一个确定的结果。一个系统就是由各种各样的愿望组成 的。如果所有对系统有愿望的人要做的所有事情都找全了，那这个系统的功能性就 被确定下来了。官方定义：用例定义了一组用例实例，其中每个实例都是系统所执行的一系列 操作，这些操作生成特定主角可以观测的值。本书定义：一个用例就是与参与者交互的，并且给参与者提供可观测的有意义 的结果的一系

8、列活动的集合。一个用例场景就是一个用例的实例。一个完整的用例定义由参与者、前置条件、场景、后置条件构成。1 -前*針1°jT*買Pjjr用测（一）用例特征a）用例是相对独立的。不需要与其他用例交互而独自完成参与者的目的。如取钱是一个用例，而填写取款单却不是。没人会只为了填写取款单跑一趟银行。b）用例的执行结果对参与者来说是可观测的和有意义的例如，一个后台进程监控参与者在系统里的操作，在参与者删除数据之前执行备份。 虽然它是系统的一个必需组成部分，但它在需求阶段却不应该作为用例出现。因为这 是一个后台进程，对参与者来说是不可观测的，它应作为系统需求在补充规约 中定义。又比如，登录系统是

9、一个用例，但输入密码不是。因为登录系统对参与者是有 意义的，这样他可以获得身份认证和授权，但单纯输入密码却是没有意义的。c) 这件事必须由一个参与者发起。不存在没有参与者的用例，用例不应该自 动启动，也不应该主动启动另一个用例。如从ATM取钱是一个用例，ATM吐钞却不是。d) 用例必然是以动宾短语形式出现的 如喝水是一个有效的用例，而“喝”和“水”却不是。很多用例中以“计算”、“统计”、“报表”、“输出”、“录入”之类命名的并不在少数。e) 一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单 元，甚至部署单元。( 二 ) 用例粒度粒度是令人困惑的。比如在 ATM取钱的场景中，取钱、

10、读卡、验证账号、打印回执单等都是可能的用例。取钱粒度更大一些，其他则要小一些作者经验在项目过程中根据阶段不同，使用不同的粒度。在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。即一 个用例可以描述一项完整的业务流程。例如取钱、报装电话、借书等表达完整业务 的用例，而不要细到验证密码、填写申请单、查找书目等业务中的一个步骤。在用例分析阶段，即概念建模阶段，用例的粒度以每个用例能描述一个完整的 事件流为宜。可理解为一个用例描述一项完整业务中的一个步骤。这个阶段需要采 用一些面对对象的方法，归纳和抽象出业务用例中的关键概念模型并为之建模。例 如，宽带业务需求中有申报报装和申请迁移地址用例，在用例分析时，可归纳和分 解为提供申请资料、受理业务、现场安装等多个业务流程中都会使用的概念用例。在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够 描述操作者与计算机的一次完整交互为宜。例如，填写申请单、审核申请单、派发 任务单等。可理解为一个操作界面或一个页面流。在