UML核心元素.ppt

UML核心元素 版型(stereotype) 有些书也称类型、构造型——对UML中元素基础定义的扩展 UML中每一种元模型很多版型 如，用例有“业务用例”、“业务用例实现”等 类，“接口”、“边界类”、“实体类” 参与者 以人为本 基本概念 参与者——在建模过程中处于核心地位 UML官方文档的定义：actor是在系统之外与系统交互的某人或事物 参与者 系统有一个边界，参与者在边界外，边界内的都不是参与者 问题：谁是参与者 例如：小王去银行开户，向大堂经理询问如何办理手续，填写表但，参给柜台职员，拿存折 通过回答以下两个问题来确定 谁对系统有明确目标和要求并且主动发出动作 系统为谁服务 参与者 官方文档，参与者有另一种叫法：主角 主动启动了业务的，才是参与者 那么刚才问题中的经理和职员呢？——业务工人 参与者可以非人 定时器 发现参与者 情况1：机票购买者通过登陆网站购买机票 情况2：机票购买者通过呼叫中心购买机票 发现参与者 情况3：购买者通过呼叫中心自动语音预定机票 情况4：扩大系统边界 业务主角 软件项目中，业务范围和系统范围不同 业务范围 指这个项目所涉及的所有客户业务，这些业务没有计算机参与都可观存在 系统范围 指软件要实现的那些对应业务功能的系统功能，从功能性需求看，是业务范围的一个子集 有些系统功能可以超出业务范围 业务主角 业务主角(business actor)是参与者的一个版型，用于定义业务的参与者 状对的业务人员，非计算机用户 在初始需求阶段，需要获得客户的业务模型，根据业务模型建立计算机模型，此时如何引入计算机系统的概念，就会混淆 要建立一个符合客户需要的计算机系统，首要条件是完全彻底搞清楚客户的业务，而不是预先假设已有一个计算机系统，再让客户假象计算机系统帮他们做什么 业务主角 业务主角的重要性 建立业务模型，查找业务用例都必须使用业务主角，而不是普通参与者 初始需求阶段 业务主角是客户实际业务里的参与者 没有计算机，没有抽象的计算机角色 业务主角是在实际业务里能找到对应的岗位或人员 业务工人 参与者 位于系统边界外，如果把边界内和外的参与业务的人都作为参与者建模，会混乱 主角和配角 参与者——主角 业务工人——配角 如何区分 是否主动向系统发出工作 是否有完整的业务目标 系统是否为他服务 参与者与用户 参与者与用户的关系 用户 系统的使用者——系统的操作员 用户——参与者的代表 问题 是否所有的参与者都是用户？ 参与者与角色的关系 角色 参与者的职责 是一个抽象的概念 一个角色代表了系统中的一类职责 问题 参与者、用户、角色什么关系 用例 UML建模中最最重要的一个元素 除了用例之外，其他所有元素都是“封装”的，“独立”的 那些元素在没有“外力”的情况下，“老死不相往来” 用例就是施加这一“外力”的元素 用例 用例概述 1987年才有了一个正式的名字：Use Case 一种把现实世界的需求捕获下来的方法 一个系统是由各种各样的愿望组成的，各种各样的人为了各自的目的作各种各样的事情，组成了一个系统 如果需要描述一个系统的功能性需求，就要找对这个系统有愿望的人，说明会在这个系统作什么，想要什么。所有想做的事情都找全了，系统的功能性就确定下来了 用例 概述 所谓用例，就是一件事情，要完成这件事情，需要一系列活动 做一件事情可以有很多不同的方法和步骤，也可能会有各种各样的意外情况，因此这件事情由很多不同情况的集合构成，在UML中称为场景 一个场景就是一个用例的实例 例子：做一顿饭 用例 做一顿饭 需要完成什么主要事情 需要什么原材料才能做 成果是什么 用例 做一顿饭 煮饭 电饭锅 蒸笼 炒菜 启动用例需要条件 米 水 结果 生米——〉熟饭 一个完整的用例：参与者、前置条件、场景、后放条件 用例特征 特征1：用例相对独立 不意味不与其他用例交互而独立完成参与者目的，从“功能”上是完备的 体现系统参与者的愿望 例如：取钱——有效用例；填写取款单——非有效用例 特征2：用例的执行结果对参与者来说可观测和有意义 后台进程监控：在需求阶段不应该作为用例出现，应该作为系统需求在补充规约中定义 例如：登陆系统——有效用例 输入密码——非有效用例 用例特征 用例特征 特征3：这件事由一个参与者发起。 特征4：用例必然是以动宾形式出现 用例特征 特征4：一个用例就是需求单元、分析单元、设计单元、开发单元、测试单元，甚至部署单元 用例的粒度 规则 业务建模阶段 一个用例描述一项完整的业务流程 例如：取钱，报装电话，借书 而不是填写申请单、查找书目 概念建模阶段 用例能描述一个完整的事件流 可以理解为一个用例描述一项完整业务中的一个步骤 需要归纳和抽象出业务用例中的关键概念模型并为之建模 如：宽带业务中