大象Thinking+in+UML读书笔记.docVIP

摘自《大象——Thinking in UML》 谭云杰 参与者（Actor、主角） 特点： 业务建模的核心。它是涉众代表，代表涉众对系统的利益要求，并向系统提出建设要求。系统是以参与者的观点决定的，他对系统的要求，对系统的表述完全决定了系统的功能性。 参与者位于边界之外 谁对系统有着明确的目标和要求，并且主动发出动作？ 系统是为谁服务的？ 业务工人（Business Worker） 参与者可以非人 涉众是发现参与者的重要来源 涉众（Stakeholder），又称干系人，指与建设系统有利益相关的一切人和事，但涉众不一定是系统的参与者。参与者是涉众代表，他对系统的要求直接影响到系统的建设，他们的要求就是系统需求的来源。参与者通过对系统提出要求来获得他所代表的涉众的利益。由此可见，参与者也并不需要询问同一岗位所有人，而是找出可代表该岗位的代表，与之沟通。 用户和参与者，用户是指系统的使用者，系统的操作员，他是参与者的代表。 角色是参与者的职责，是一个抽象的概念，从众多参与者的职责中抽象出相同的一部分，将其定义一个角色。一般适用于概念阶段的模型，以表达业务的逻辑理解。一个用户可以代理多个参与者，一个用户可以拥有多份职责，即可被指定多个角色。 问题 谁负责提供、使用或删除信息？ 谁将使用此功能？ 谁对某个特定功能感兴趣？ 在组织中的什么地方使用系统？ 谁负责支持和维护系统？ 系统有哪些外部资源？ 其他还有哪些系统将需要与该系统进行交互？ 版型 业务主角（Business Actor） 定义业务的参与者，在需求阶段使用，用来确定业务范围。非常重要，建立业务模型、查找业务用例都须用业务主角。 业务范围和系统范围不同，业务范围指项目涉及的所有客户业务，有些业务内容没有系统参与也一样客观存在。 系统范围仅指软件要实现的业务功能。有些系统功能不在业务范围，如操作日志。 业务主角针对业务人员，而非计算机用户，也不应过早引入计算机系统的概念，以免混淆，导致误导用户。 业务主角必须在实际业务里能找到对应的岗位或人员。 常用问题： 业务主角的名称是否是客户的业务术语？ 业务主角的职责是否在客户的岗位手册里有对应的定义？ 业务主角的业务用例是否都是客户的业务术语？ 客户是否对业务主角能顺利理解？ 业务工人（Business Worker） BW被动参与业务。 BW处于系统边界内。 不需要为BW建立业务模型，只在主角的业务模型中出现。 虽然不参与业务建模，但他们仍然不可或缺，如领域模型、用例模型。缺少他们业务模型就不完整，甚至不能运行。 判断他是在边界之内和边界之外，常用问题： 他是主动向系统发出动作的吗？ 他有完整的业务目标吗？ 系统是为他服务的吗？ 检查点（RUP官方文档，非常有助于检查发现的参与者是否正确） 是否您已找到所有的参与者？也就是说，是否您已经对系统环境中的所有角色都进行了说明和建模？虽然您应该检查这一点，但是要到您找到并说明了所有用例后才能将其确定。 每个参与者是否至少涉及一个用例？删除未在用例说明中提及的所有参与者，或与用例无通信关联关系的所有参与者。 您能否列出至少两名可以作为特定参与者的人员？如果不能，请检查参与者所建模的角色是否为另一角色的一部分。如果是这样，您应该将该参与者与另一参与者合并。 是否有参与者担任与系统相关的相似角色？如果有，您应该将他们合并到一个主角中。通信关联关系和用例说明表明参与者和系统是如何相互关联关系的。 是否有两个参与者担任与用例相关的同一角色？如果有，您应该利用参与者泛化关系来为他们的共享行为建立模型。 特定的参与者是否将以几种（完全不同的）方式使用系统？或者，他使用用例是否出于几个（完全不同的）目的？如果是这样，您也许应该有多几个参与者。 参与者是否有直观名称和描述性名称？用户和客户是否都能理解这些名称？参与者的名称务必要与其角色相符。否则，应对其进行更改。 用例（Use Case） 用例是UML建模中最重要的元素。除了用例外，所有其他元素都是“封装”、“独立”的。这些元素在没有外力作用时，是“老死不相往来”的。用例正是施加这一“外力”的元素，它使得其他各自独立的元素能共同组成一篇有意义的文字。 用例是一种把现实世界的需求捕获下来的方法。首先有某人的一个愿望，这个愿望驱使人去做事并获得一个确定的结果。一个系统就是由各种各样的愿望组成的。如果所有对系统有愿望的人要做的所有事情都找全了，那这个系统的功能性就被确定下来了。 官方定义：用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值。 本书定义：一个用例就是与参与者交互的，并且给参与者提供可观测的有意义的结果的一系列活动的集合。 一个用例场景