记录—UML
Written by guppy.version: 0.3
1. 概述
? OOA（面向对象分析）为上世纪七十年代末期面向对象运动兴起所诞生，在最初面向对象进入的领域是编程领域，面向对象语言Smalltalk诞生，但软件分析与设计还是以结构化的面向过程方法为主。后面许多面向对象大师创建了自己的面向对象分析方法，随方法不同但理念相通。
? 有三位面向对象大师决定将其他们各自的方法统一起来，在1995年10月推出了第一个版本，称为“统一方法”（Unified Method 0.8），随后又以“统一建模语言”（Unified Modeling Language）UML 1.0的正式名称提交到OMG（对象管理组织）。
2. 基础元素
2.1 用例
2.1.1 概述
? 用例（Use Case），由参与者（actor）驱动的，并且给参与者提供可供观察的 有意义的结果的一系列活动的集合。它是一种把现实世界的需求捕获下来的方法。
? 官方定义：用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观察的值。
? 换句话说，一个用例就是与参与者（actor）交互的，并且给参与者提供可供观察的有意义的结果的一系列活动的集合。而做一件事可以有很多不同的办法和步骤，也可能会遇到各种各样的意外情况，因此这种事情是由很多不同情况的集合构成的，在UML中称之为用例场景，一个场景就是一个用例的实例。
? 比如说你想做饭，你需要完成煮饭和炒菜两件事情，这两件事情就是两个用例。而煮饭可以有不同的做法，你可以用电饭煲煲饭，也可以用蒸笼做，这就是两个不同的场景，也就是两个实例。而同样用电饭煲做饭，如果是糙米你可能需要先淘米，也是精米你可以省掉淘米的步骤直接下锅，这是用例在不同条件下的不同处理场景。
? 综上，一个完整的用例由参与者、前置条件、场景、后置条件构成。如下图图2-1：
? 本还有两个业务用例的版型，业务用例实现和概念用例，但在EA中没有，就不做绘制了，用处其实都可以用最基本的椭圆来替代，整这么版型倒还需要记概念，不需要这么复杂。
2.1.4 用例粒度
? 用例的粒度是令人困扰的，比如在ATM机取钱的场景下，取钱、读卡、验证账号、打印回执单，都是可能有的用例，但是取钱这一用例明显包含了后续的这些用例，取钱这一用例明显粒度大于后面这些，其它用例要小一些，那到底是一个大的用例好些还是拆解成几个小用例好些呢/p>
? 这里有一些建议，在不同阶段使用不同粒度的用例。
在业务建模阶段，用例以每个用例能够说明一件完整的事情为宜，既一个用例描述一项完整的业务流程。
在用例分析阶段（概念建模阶段），用例的粒度能够完整的描述一件事情为宜。既一个用例描述一项完整业务的一个步骤。
在系统建模阶段，用例视角是面向计算机的，因此用例的粒度以一个用例能够完整描述操作者与计算机的一次完整交互为宜。例如，填写申请单、审核申请单、取消申请单等等。
这些也只是一些建议，可实际根据自身实际情况划分粒度，只要是以该用例是否完成了参与者的某个完整目的为依据的。一切从实际目的（需求）出发。
2.1.5 用例获取
Ⅰ.准备
? 我们知道用例的来源就是[参与者](# 3.1 参与者)对系统的期望。所以发现用例的前提是发现参与者，而确定参与者的同时就确定了系统边界。因此在捕获用例之前，我们需要涉众分析。涉众具体概念在[3.4小节 涉众](# 3.4 涉众)。
? 为了便于理解，强调与[业务工人](# 3.3 业务工人)（business worker）的区别，这里将参与者改称”主角“，主角主要有以下几个要求：
- 主角是位于系统边界之外的。
电影中其它配角是为服务主角的。业务工人处于系统之内，是为主角服务的。
- 主角对系统有明确的期望和明确的回报要求。
需求明确，不要东扯西扯有的没得都加上去，要有核心的需求。
- 主角的期望和回报要求在系统边界之外。
期望及回报要求在系统边界之外，这个就是说，原有系统已经能够完整实现了，不需要多此一举再次获取需求。
接下来就可以进行涉众分析了。
Ⅱ.涉众分析
? 涉众分析大体流程如下图图2-4。
- 参与者
通常是系统的实际使用者，对系统最终成功有比较大的影响力量。
- 环境设定者
很少是系统的直接使用者，受系统影响较小，对系统保持较低关注度，但他们会因为政治、经济或权力等因素而对系统有较大的影响力。如政府力量和管理层是最常见的环境设定者。
- 被影响者
他们有可能是系统的直接使用者，但更有可能是因为系统的出现而被剥夺了部分利益的输家，受系统较大的影响，却没有足够的力量影响系统的决策。
- 观众
不会受系统较大的影响，也没有足够的力量影响系统的决策，所以他们更多以观众的身份参与软件开发。领域砖家和市场力量便是常见的观众。
风险评估：
? 如果有些涉众在项目中的表现和开发者所预期的不太一致，那么就可能会给项目带来风险，进而导致项目失败。所以为了保证项目成功需要在涉众分析时进行风险评估工作，以控制涉众因素给项目带来的风险。
? 风险评估需要先分析涉众的态度，建立如下Power/Attitude分布图 图2-6，处于强反对者区域的涉众是需要进行仔细分析的高风险因素。
共赢评估：
? 软件系统的不同涉众有不同的立场和利益，因此他们之间对系统的期望难免会发生冲突。为了保证软件系统的最终成功，应该尽可能地解决这些冲突，而且最好是在冲突发生之前能够消除于无形，这就是在涉众分析中进行共赢分析工作的主要目的。
? 除了涉众之间的需求冲突之外，还会有涉众自身期望与项目整体目标相存在背离和不一致的现象，所以这也是我们将要解决的问题，如何消除涉众期望与项目业务需求之间的冲突。
? 想要消除冲突，首先就需要找到冲突所在。可以建立Stakeholder/Issue关系图。如下图所示：
? 边界有以下一些特征：
- 边界决定视界
? 边界是可大可小的，由建模者主观决定。比方说我们观察并描述一栋建筑物，在正前方观察到的是大门、招牌、楼层等等事物，而在大楼顶上观察却是围栏、烟道、水管等等，当我们处于大厅之中又会观察到凳子、沙发、吊灯之类的事物。
- 边界决定抽象层次
? 要选择合适的抽象层次来描述事物，比如我们要描述一辆车，一辆车几十万个零部件，如果直接从零件上来描述，那绝对可以把人逼疯的，而如果选择从高抽象层次出发，动力模块、安全模块到方向盘、仪表盘、刹车，再到最后的几十万个零件这样来描述会有一种循序渐进的感觉，也更容易让人接受。因此在合适的地方选择合适的抽象层次，而在UML中，边界控制抽象层次，因此灵活的使用边界对我们理解项目很有帮助。
2.3 包
? 包（Package）是一种容器，如同文件夹一样，它将某些信息分类，形成逻辑单元。使用包的目的主要是为了整合复杂的信息，某些语义上相关或者某方面具有共同点的信息都可以分包。包的形状如下图图2-3-1所示：
? 也可以用于描述软件架构层次，如下图 图2-3-3：
2.5 分析类
? 分析类是从业务需求向系统设计转变过程中最为主要的元素，官方定义为是用于获取系统中主要的“职责簇”，它们代表系统的原型类，是系统必须处理的主要抽象概念的“第一个关口”。常用于时序图，协作图等动态图
2.5.1 边界类
? 边界类是一种用于描述对系统外部环境与其内部运作之间的交互进行建模的类，这种交互包括转换事件，并记录系统表示方式中的变更。
这三种分析类在此处可以简单理解为MVC，model实体类、view边界类、controller控制类。后面动态图再细讲用法。
2.6 设计类
?
3. 名词解释
3.1 参与者
? 参与者（actor）在UML官方文档中对参与者的定义为：actor 是在系统之外与系统交互的某人或某事物。
note：参与者位于系统边界之外，参与者可以非人！
? 参与者这个叫法很可能迎来歧义，会觉得但凡在业务的或者在业务流程中做事情的都叫参与者。这是一个误解，如果换一个叫法“主角”，可能就好很多。电影中的剧情走向都是围绕主角，配角就类似于业务工人，他们的出现就是为了让主角完成业务目标。
3.2 业务主角
? 业务主角（business actor）是参与者的一个版型，特别用于定义业务的参与者，在需求阶段使用。
note：业务主角的特殊性在于，他针对的是业务人员而非计算机用户。在查找业务主角时必须抛开计算机，没有计算机系统这些业务人员也客观存在。
? 其常用于建立业务模型、查找业务用例。很多需求分析人员是由程序员或设计师担任，由于有开发计算机系统的背景，使得他们建立的业务模型时常容易犯一个错误，喜欢从计算机系统的角度来思考问题，在向客户收集需求的时候总第一时间想到如何实现，常常津津乐道与客户谈论计算机系统将如何实现客户的需求，并指望客户能够用这种方式来确定需求。这会导致如下后果：
? 客户不理解将来计算机实现是个什么样子，但出于信任，将信将疑的回答：Yes，就是这样做。而结果在计算机系统真正展现在客户面前时，客户大声说：No，这不是我想的。
? 需求分析人员一开始就加入了自己的主观判断，假设了业务在计算机系统里的实现方式，而没有去理解客户实际业务。其结果是当计算机系统完成之后，客户抱怨：No，流程不对；开发人员：我是按照需求来做的啊。
3.3 业务工人
? 业务工人（business worker），在下图图3-1中，人工坐席处于机票预订系统这个系统边界之内，则此时为业务工人。当然这个没有绝对，当观察视角转换，人工座席处于Web子系统的外面时，人工座席则又可以处于业务主角，这跟你自己设定的抽象层次有关。
3.4 涉众
涉众（stakeholder），也称干系人。涉众是与要建设的这个系统有利益相关的一切人和事，涉众的利益要求会影响系统的建设。比如，投资方，系统使用用户，假如一个系统的建设是由一家风险投资机构投资的，有时系统必须满足投资方的一些特殊要求，作为涉众，投资方的意见或许会构成一些约束。但投资方并不参与系统建设，它只是从资本上拥有这个系统从将来的收入中获得回报。
3.5 用户及角色
用户（user）：是指系统的使用者，俗话说就是系统的操作员。
角色（role）：其是参与者的职责。角色是一个抽象的概念，从众多参与者的指责中抽象出相同的那一部分，将其形成一个叫角色。如商城系统中买家与卖家就属于两个就角色，卖家有相应的上架商品的职责（权限），买家可以购买商品的职责（权限）。
4. 附件
4.1 涉众分析报告
一、业务目标：
本游戏是基于原三国kill单机版所开发的现代网络卡牌游戏，在游戏有着与传统纸牌游戏的基本功能，也有着当代网络游戏的交友，自由交易等功能，是一款极易入手的卡牌网游，当然本游戏旨于为现代社会日益操劳的人们而带来娱乐，而且让人们感受到纸牌游戏无穷魅力。
为了方便游戏活动的开展，吸引玩家消费，对以往游戏流水查阅、分析，由此需要为财务部开发相应的流水查询板块。
为了解答玩家的一系列疑问及查询，由此引入了客服系统，同时相应的玩家享受不同的客服服务。
二、涉众概要
编号 涉众名称 涉众说明 期望 SG001 VIP玩家 普通玩家在充值一定数额CNY后，自动升级为VIP玩家，VIP玩家可以获得普通玩家没有的经验/金币加成及道具奖励 ① 享受专属账号申述服务（每天可免费获取稀有道具，经验/金币加成） ② 体验三国杀的所有游戏功能 SG002 普通玩家 没有对游戏进行充值的玩家 ① 体验三国杀的大部分游戏功能 SG003 运维部门 在游戏发布后，对游戏进行运行维护升级的部门 ① 原软件代码可读性强，易于 ② 软件鲁棒性强，不易出错 ③ SG004 财务部门 设定充值通道，管理资金流水，并对资金进行汇报总结的部门 ① 通过计算机自动统计各类财务并打印财务报表 ② 并有良好的图形界面易于观察盈亏 SG005 客服部门 对玩家的要求、问题及咨询提供解答和解决服务 ① 界面操作简单 ② 有详细的游戏文档给客服了解，以便解决玩家问题 三、涉众简档
涉众 SG001用户 涉众代表 XXX普通中学生用户小明 特点 系统的预期使用者，不可预计计算机应用水平使用者，及使用者的年龄 职责 ① 向游戏运营商注册账号 ② 在游戏中可以选择充值方式并充值虚拟币或购买其它服务 ③ 向游戏运营商申请查询充值记录，业务办理，虚拟币消费情况等要求 成功标准 ① 按要求准确填写注册信息 ② 符合服务要求用户 参与 不参与系统建设 可交付工件 无 意见/问题 ① 充值兑换比例大一些 ② 服务更多一些
涉众 SG003用户 涉众代表 XXX运维组常组长、 特点 系统的预期使用者，可预计计算机应用水平使用者，及使用者的年龄 职责 ① 处理系统运行时发生的错误并记录 ② 更新系统并更改bug 成功标准 ① 按要求完成系统建设任务 ② 系统能完成需求文档的要求 参与 参与系统后期运维 可交付工件 ① 《维护纪录》 ② 《版本更新内容》 ③ 《缺陷报告》 意见/问题 ① 望开发组的程序能具有鲁棒性
涉众 SG004用户 涉众代表 XXX财务处刘处长、 特点 系统的预期使用者，可预计计算机应用水平使用者，及使用者的年龄 职责 ① 负责财务分析及报告 ② 通过财务报告来为运维组提供运营思路 ③ 汇报盈亏 成功标准 ① 按要求使用系统 ② 仔细分析财务 ③ 定期汇报财务 参与 系统使用者；参与运营活动可行性分析 可交付工件 ① 《财务报告》 ② 《财务分析》 意见/问题 望操作界面良好，易于分析
涉众 SG005用户 涉众代表 客服组组长小林 特点 系统的预期使用者，可预计计算机应用水平使用者，及使用者的年龄，可培训 职责 ① 给玩家提供解决问题，同时提供咨询服务 ② 撰写玩家问题总集 成功标准 ① 根据讲解，玩家能清晰了解问题 参与 不参与系统建设 可交付工件 《FAQ》 意见/问题 ① 操作界面待改良 ② 减轻工作量 四、用户概要
编号 用户名称 用户概况和特点 使用系统方式 代表涉众 US001 VIP用户 在游戏中进行充值到相应金额的游戏玩家 在自己的手机上运行三国杀客户端 SG001 US002 VIP用户客服· 在游戏对VIP用户进行对点服务的人员 远行与游戏相应的内部管理版本 SG005 US003 普通玩家 在游戏中进行未充值到相应金额的游戏玩家 在自己的手机上运行三国杀客户端。 SG002 US004 普通玩家客服 在游戏中对不是VIP玩家群体进行·服务的人员 远行与游戏相应的内部管理版本 SG005 US005 财务人员 管理游戏收益的人员 运行相应的游戏充值管理系统 SG004 US006 运维人员 管理游戏系统正常运行与耿欣维护的人员 远行游戏的开发板 SG003 五、用户简档
用户 US001VIP用户 用户代表 大学生皮XX 特点 系统的预期使用者，不参与系统建设 说明 在游戏中进行相应充值的少量游戏玩家 职责 1.注册账号，登录游戏 2.遵守相应的法律法规 成功标准 正确注册账号并登录游戏 参与 需求获取 可交付工件 略· 意见/问题 在游戏中需要有非常大的亮点
用户 US002 VIP用户客服 用户代表 专用客服皮XX 特点 对游戏进行相应金额的充值的玩家进行点对点的游戏服务· 说明 系统的预期使用者，可预计计算机应用水平使用者，及使用者的年龄 职责 1.使游戏中高充值群体享受到高级服务 2…正确维护游戏秩序 成功标准 让VIP玩家获得高级服务 参与 需求获取，需求分析 可交付工件 《工作汇报》 意见/问题 略
用户 US003普通用户 用户代表 大学生皮XX 特点 在游戏未充值到相应金额的玩家，但数量庞大 说明 系统的预期使用者，不参与系统建设 职责 1.注册账号，登录游戏 2.遵守相应的法律法规 成功标准 正确注册账号并登录游戏 参与 需求获取 可交付工件 略· 意见/问题 游戏尽量有比较好玩创新的玩法
用户 US004普通玩家客服 用户代表 客服皮XX 特点 对游戏中充值金额未到一定数量的玩家进行游戏服务 说明 系统的预期使用者，可预计计算机应用水平使用者，及使用者的年龄 职责 1.保证游戏内大多玩家的体验感， 2.及时把大部分玩家对游戏的期待反馈于项目组，并维护游戏秩序 成功标准 使多数玩家感受到游戏的可玩性及对游戏玩家的诚意 参与 需求获取、需求分析 可交付工件 《工作汇报》 意见/问题 略 六、消费者统计
消费者名称 消费者概况和特点 应用环境 使用频率 特殊要求 游戏玩家 游戏面向群体广泛，无法衡量其计算机水平，无法培训，在年龄段15-30之间用户占大部分，且男性玩家多，潜在玩家估计共100万，预计有15万人玩家。 Android手机 iPhone手机 账号注册频率初始预计较高，在用户数量趋于稳定后注册频率显著降低， 登录服务，高峰期按10万用户计算，瞬时在线及登录人数达3万。 由于玩家的消费水平不同，应将不同玩家能体验功能详细描述给玩家， 财务处 面向运营公司的财务人员，应对财务人员进行培训使用该系统 财务处使用该系统时，预计在周一到周五，一般为一周几十次； 若有良好的图形界面供财务分析人员分析，可大幅提高分析效率及准确性 客服 面对玩家的咨询问题，进行相应的解决和讲解 电话及网站 根据以往经验得出，每日咨询人次为200；一般咨询的高峰期为下午，傍晚及中午，瞬时峰值大约15人次，可根据常见问题解答分流出一部分玩家，剩余玩家再让客服介入，其瞬时峰值大约3-5人。 让客服提供优质的服务，所以客服的操作方式应有快捷操作方式，提高客服解决玩家的速率 家估计共100万，预计有15万人玩家。 | Android手机 iPhone手机 | 账号注册频率初始预计较高，在用户数量趋于稳定后注册频率显著降低， 登录服务，高峰期按10万用户计算，瞬时在线及登录人数达3万。 | 由于玩家的消费水平不同，应将不同玩家能体验功能详细描述给玩家， |
| 财务处 | 面向运营公司的财务人员，应对财务人员进行培训使用该系统 | | 财务处使用该系统时，预计在周一到周五，一般为一周几十次； | 若有良好的图形界面供财务分析人员分析，可大幅提高分析效率及准确性 |
| 客服 | 面对玩家的咨询问题，进行相应的解决和讲解 | 电话及网站 | 根据以往经验得出，每日咨询人次为200；一般咨询的高峰期为下午，傍晚及中午，瞬时峰值大约15人次，可根据常见问题解答分流出一部分玩家，剩余玩家再让客服介入，其瞬时峰值大约3-5人。 | 让客服提供优质的服务，所以客服的操作方式应有快捷操作方式，提高客服解决玩家的速率 |来源：GU_PPY
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！