[读书笔记]-Thinking in UML-1-核心元素

 

目录

一、参与者

1.1 参与者

1.2 业务主角

1.3 业务工人

1.4 一个例子

二、用例

 2.1 用例的定义

2.1.1 用例的特征

2.1.2 用例的粒度

2.2 业务用例

 2.3 概念用例

2.4 系统用例

三、边界

四、包

五、分析类

5.1 边界类

5.2 控制类

5.3 实体类

5.4 分析类的三高

六、设计类

6.1 类

6.2 属性

6.3 方法

 6.4 可见性

 七、关系

7.1 关联关系

7.2 依赖关系

7.3 扩展关系

7.4 包含关系

7.5 实现关系

7.6 精化关系

7.7 泛华关系

7.8 聚合关系

7.9 组合关系

八、组件

---

面向过程：如果你的习惯还是先分析多少业务流程，顺腾摸瓜找出这一步中参与者做的事情，对不起，你还是面向过程

面向对象：如果你的习惯是弄清楚有多少部门，多少岗位，然后找打每个岗位的业务代表，那么恭喜你，你已经面向对象了。

这是大象书里的话，搞了半天，我还是面向过程。但是我觉得这种思路没啥问题，不先面向过程，怎么知道有多少对象呢？

难道我要为了面向对象而面向对象吗？

一、参与者

先看定义，再看如何在业务中找到这些角色

1.1 参与者

uml官方文档中这样定义：参与者 是 在系统之外 与 系统交互 的某人或某物

1.2 业务主角

业务主角是参与者的一个版型。

版型：UML中一个常用的词，如何理解？

个人就把参与者当成一个类，业务主角就是他的一个实例

1.3 业务工人

业务的执行者，被动参与业务的人

1.4 一个例子

机票购买者-业务主角，人工座席-业务工人

二、用例

除用例之外，所有的其他元素都是“封装的”，“独立的”。用例正式这一“外力”驱动那些“老死不相往来”的UML元素共同组成了这个业务模型。

 2.1 用例的定义

记住下面这些 图块，画图的时候会用到

 用例就是一件事情，要完成这件事情，需要做一系列活动

2.1.1 用例的特征

• 用例是相对独立的
• 用例的执行结果对参与者来说是可观测的和有意义的
• 这件事必须由一个参与者发起
• 用例必然是已动宾短语形式出现的（比如，喝水，而喝不是）
• 一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元2.

2.1.2 用例的粒度

粒度问题的引入：

比如在ATM取钱的场景中，取钱，读卡，验证帐号，打印都是可能的用例。根据日常生活中的了解，取钱包含更多的后续用例。这个就叫做粒度，取钱的粒度更大一些，其他的粒度更小一些。

那么取钱这个粒度就比较大，那么要不要分成更多的用例做呢？——这就是我们需要思考的问题

2.2 业务用例

业务用例 是用例版型的一种，用于业务建模。

业务用例实现，业务用例的一个实例

业务用例实现可能有多个，就如同接口和实现类的关系。

看起来，实现的