统一建模语言UML3 UML核心元素.pptVIP

统一建模语言UML ——UML核心元素 版型 或称为类型、构造型。 是对一个UML元素基础定义的扩展，在同一个元素基础定义的基础上赋予特别的含义，使得这个元素适用于特定的场合。 是UML的一种扩展手段。 参与者 是在系统之外与系统交互的某人或某事物。 定义参与者是我们进行抽象的第一步。 在建模过程中出于核心地位。 参与者 参与者位于边界之外 场景如下： 小王到银行开户，向大厅经理询问了办理手续，填写了表单，交给柜台职员，拿到了银行存折。 试问在上述场景中谁是参与者？ 确定参与者 要明确参与者，首先要确定系统边界。 谁对系统有着明确的目标和要求并且主动发出动作？ 系统是为谁服务的？ 参与者也叫主角，即主动启动某个业务的。 确定参与者 场景如下： 每天自动统计网页访问量，生成统计报表，并发送至管理员信箱。 试问上述需求的参与者是谁？ 发现参与者 以下问题可以帮助确定参与者： 谁负责提供、使用或删除信息？ 谁将使用此功能？ 谁对某个特定功能感兴趣？ 在组织中的什么地方使用系统？ 谁负责支持和维护系统？ 系统有哪些外部资源？ 其他还有哪些系统将需要与该系统进行交互？ 机票预定系统 情况一：机票购买者通过登录网站购买机票。 情况二： 机票购买者通过呼叫中心，由人工座席操作定机票系统购买机票。 情况三： 机票购买者通过呼叫中心的自动语音预定机票。 情况四： 扩大系统边界，让呼叫中心成为机票预定系统的一个子系统，且机票购买者可以自主选择是通过人工座席，自动语音还是登录网站预定机票。 业务主角 是参与者的一个版型，特别用于定义业务的参与者，在需求阶段使用。 建立业务模型，查找业务用例都必须使用业务主角。 容易犯的错误 喜欢从计算机系统的角度来思考问题， 以计算机如何实现客户需求的方式来向客户确认需求。 这样将导致： 客户不能真正理解建立的系统是什么样子，想象与现实有出入。 需求分析人员将自己的主观判断加入到需求中，没有真正理解客户的实际业务。 建议： 在初始需求阶段，务必使用业务主角， 要完全彻底的搞清楚客户的业务，而不是预先假设已经有一个计算机系统，再让客户想需要计算机系统帮他们做什么。 业务工人 被动参与了业务的，称为业务工人。 业务工人 业务工人起“配角”的作用，他们的工作就是完成主角的业务目标，不需要为他们建立业务模型。 常见于领域模型、用例场景。 如何区分参与者、业务工人？ 判断他是在系统边界之内还是之外。 当边界不清楚时： 他是主动向系统发出动作吗？ 他有完整的业务目标吗？（即结果是否反馈到他手里？） 系统是为他服务的吗？ 以上答案都是否定的，那一定是业务工人。 例如：人工坐席—业务工人 检查点 是否已经找到所有的参与者？ 是否已经对环境中所有的角色都进行了说明和建模？ 每个参与者是否都至少涉及到一个用例？ 删除没有在用例中提及的所有参与者，或与用例无通信关联关系的所有参与者。 能否列出至少两名可以作为特定参与者的人员？ 如不能请检查参与者与所建模的角色是否为另一角色的一部分，并考虑合并这两个参与者。 检查点 是否有参与者担任与系统相关的相似角色？ 如果有，应将他们合并到一个主角色中。 用关联关系说明参与者和系统是如何关联的。 是否有两个参与者担任与用例相关的统一角色？ 如果有，应该用泛化关系来为他们的共享行为建模。 检查点 特定的参与者是否将以几种（完全不同的）方式使用系统？ 如果有，也许应该有多个参与者。 参与者是否有直观的名称和描述性的名称？是否与角色相符？是否易于客户理解？ 用例 Use Case 是一种把现实世界的需求捕获下来的方法。 官方文档的定义： 用例定义了一组实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定的主角可以观测的值。 用例 通俗的说： 用例就是一件事情（或者说是一个目标），要完成这件事情（或这个目标），需要做的一系列活动。 用例场景 做一件事情可以有很多不同办法或步骤，也可能会遇到各种各样的意外情况， 因此，这件事情是由很多不同的情况的集合构成的， 在UML中称之为用例场景。 一个用例场景就是一个用例的实例。 例如 某人要完成“煮饭”和“炒菜”两件事情。 其中用例： 煮饭 用电饭煲 用蒸笼 炒菜 …… 如何启动用例？ 外部驱动力 满足前置条件 用例启动的前提 用例执行的结果 用例执行完了，会有一个结果，这称为用例的后置条件。 用例的构成 小结：用例的作用 系统的功能是由一些对系统有愿望的参与者要做的一些事情（用例）构成的， 事情完成就达成了一个参与者的愿望， 当所有参与者的愿望都能通过用例来达到，那么这个系统就被确定下来了。 捕捉功能性需求——用例的作用。 用例的特征 用例是相对独立的。 不需要与其他用例交互而独自完成参与者的目的。 从功能上是完