UML基础小结

1、开发过程：

（1）到底要解决什么业务问题？－－业务建模

（2）为了解决业务问题，所开发系统应提供什么功能和性能？－－需求

（3）为了提供功能，系统内部应该有什么样的业务核心机制？－－分析

（4）为了满足性能，系统的核心机制如何用选定技术实现？－－设计

2、启动：

（1）愿景

a)愿景：在老大看来，为什么要开发这个系统？

b)愿景必须来自“老大”，老大即是最有权利的涉众

c)必须指出度量指标，度量聚焦于价值

（2）涉众

a)谁关心这个系统？会涉及到他的什么利益？

b)探索系统的需求，就是探索涉众利益之间的最佳平衡点

（3）投入：愿意花多少钱，允许多少时间

（4）风险：客户参与少；没有度量方式；技术风险；重要人物反对；以前曾被取消过……

3、业务建模：

（1）作用：描述现实，帮助发现软件需求

（2）系统需求不断变化的根源：没有把系统放在业务中来看，系统需求不符合业务需求

（3）第一步：选定业务单元

a)愿景波及的需要改进的业务单元

b)使得大多数可能的系统用户成为业务工人

c)涉及多个小单元时应寻找更大的单元

d)用例观点－－把业务看成对外提供价值的价值流

e)以业务用例驱动改进－从外部认识组织的本质价值

（4）第二步：识别业务执行者

a)在业务之外和业务交互的人或组织

b)业务执行者在业务外面，业务工人在业务里面

（5）第三步：识别业务用例

a)关键：业务为业务执行者提供哪些价值？

b)业务流程就是业务用例的实现

c)业务里发生的一切都是为业务执行者提供价值

d)业务用例只针对业务执行者，内部活动不是业务用例

e)别忘了：支撑性业务流程背后的“管理型”业务用例

（6）第四步：详述业务用例

a)描述形式：文字、活动图、序列图

b)活动图往往只表现事件，序列图表现责任和协作，主要采用序列图

c)业务序列图——用面向对象的思想来看业务流程

d)序列图中消息的名字－－代表责任和目的

e)序列图中消息的方向－－代表责任不代表数据

f)寻找改进点：涉及到信息的流动吗？物流能变成信息流吗？包含的业务逻辑能封装到系统里吗？涉及到什么业务对象？需要系统管理起来吗？

g)“阿布”思考法：先假设自己不受任何资源限制来设计系统，然后考虑自己的资源限制来获得折中方案

（7）第五步：建立业务对象模型

a)用类图勾勒出现实中的人、事物、关系

b)从业务模型到系统模型

4、需求：

（1）难点：难捕获、易变

（2）用例：从用户视角看问题；合理的结构。可解决上述问题。

（3）识别系统执行者

a)系统执行者：在系统之外，透过系统边界与系统进行有意义交互的任何事物

b)系统外：交互的功能需求

c)有多少个执行者，代表有多少个接口

d)责任的边界，不是物理的边界

e)直接与系统交互

f)执行者与重要无关

g)有意义的交互

h)任何事物

i)思考：谁使用系统的主要功能？谁改变系统的数据？谁从系统获取信息？谁需要系统的支持以完成日常工作任务？谁负责维护、管理并保持系统正常运行？系统需要应付（处理）哪些硬设备？系统需要和哪些外部系统交互？谁（或什么）对系统运行产生的结果感兴趣？有没有自动发生的事件？

j)区分主执行者与辅执行者，区分系统执行者与业务执行者

（4）识别系统用例

a)用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。通俗一些就是执行者通过系统达到某个目标。

b)用例要点：价值结果——>有意义的目标；系统执行——>价值结果由系统生成；执行者可见——>业务语言，用户观点；一组用例实例——>用例的粒度

c)用例命名：慎用弱动词弱名词

d)只要能写出符合需求标准的路径、步骤，都可以作为用例，用例不存在“粒度问题”

e)最常犯错误－－把步骤当作用例

f)需求是不“复用”的，“复用”的是业务和设计

g)到底哪一种更合适，完全取决于涉众的看法

（5）书写系统用例文档

（6）通过关系整理用例

（7）用例的排序和分包

a)排序：

b)大量用例时的组织：按执行者分包；按主题分包；按开发团队分包；按发布情况分包。

（8）最后总结：用例是否用对了？判断标准：是否加强了和涉众的联系

（9）需求启发:

a)研究文档

b)问卷调查

c)访谈

d)观察

e)研究竞争对手

5、类图:

（1）对象具有状态、行为和标识

a)状态：当前属性值的组合，是行为的累积结果

b)行为：对象根据状态和接收消息作出的反应

c)标识：和其他对象相区分

（2）类：共享一个公用结构和公用行为的对象集合

（3）识别类及其属性：阅读用例文档，抽取对应于业务实体或事件的词汇；将词汇分类、抽取出合适的类和属性

（4）识别类之间的泛化：超类的对象集合包含子类的对象集合

（5）识别类之间的关联：关联的几种表现形式

6、序列图：

（1）通过画序列图完成责任分配

（2）分析工作流时三种版型的类：

a)边界类：用例的每个执行者映射一个边界类。责任：输入、输出、过滤。

b)控制类（可选）：一个用例映射一个控制类。责任：控制事件流，负责为实体类分配责任。

c)实体类：一个用例有多个实体类参与，一个实体类可以参与多个用例。责任：业务行为的主要承载体。

（3）序列图和类图的映射：

a)消息的传入：类对象所具有的操作－－责任

b)消息的传出：类对象完成操作所需合作－－协作

（4）序列图绘制要点：

a)位置：每个用例下面，对应用例的路径

b)基本路径：一张图

c)简单的扩展点：可以合并到基本路径图

d)复杂扩展点：单独一张图，和基本路径图间链接

（5）总的责任分配原则：低耦合，高内聚

a)耦合：描述设计的组成部分之间的相互依赖。没有耦合，无法一起行动；耦合太高，无法转弯类间要保持低耦合。目的：复用。

b)内聚：描述模块内各元素的紧密结合程度。类内各元素要保持高内聚。小类，短方法－－明确责任。

（6）责任分配：

a)专家原则：根据资源分配责任，各尽其才，各施其能

b)老板原则：由老板传递消息。当出现以下情况时，发给A的消息先通过B处理和中转：B聚合A（Aggregation）；B组合A（Composition ）

c)可视原则：两个对象之间有消息传递，相应类应有关联；不要与陌生人说话

7、状态图：

（1）把某对象从所有的序列图中单独拿出来考察

（2）状态－－在系统中表现出相同行为的属性值组合

（3）属性值变化导致行为发生变化－转换

（4）在源状态下，当事件发生时，如果符合警戒条件，则执行活动，进入目标状态

（5）状态图的作用：设计好了状态图之后，可以使用工具进行代码映射，则不需要人工编写复杂的状态判断代码

8、设计：

（1）分析和设计：

a)分析：强调业务概念

b)设计：强调平台实现

（2）代码映射