大象Thinking.in.UML第二版读书笔记第3章：UML核心元素_大象:thinking in uml

1、版型（stereoType）（类型，构造型）（各类理解为表现形态）

几乎每一个元模型都有很多版型
用例：对应业务用例、业务用例实现等版型
类：对应接口，边界类，实体类，控制类版型，参与者也是一个特殊类的版型。
自定义版型。包：子系统，组织接口，模块等默认版型

版型只是UML的一种扩展手段，本身并不涉及太多的思想和方法。

2、参与者（主角更贴切）

1、基本概念
参与者（actor）建模中处于核心地位。actor是在系统之外与系统交互的某人或某事物。

参与者与系统有一个明显的边界隔开。参与者位于边界之外。

参与者使用主角的称谓会更适合，而其他角色则被称谓业务工人（business worker）

参与者可以不是一个人（human），也可能是一个计算机系统，如自动启动服务。

2、参与者可能变化的情形


3、业务主角（business actor）
业务主角（business actor）是参与者的一个版型，特别用于定义业务的参与者。针对的事（现实世界）的业务人员，而非计算机用户。查找业务主角时必须抛开计算机

业务主角是与业务系统有着交互的人和事物，他们用来确定业务范围（现实世界的业务范围），业务主角必须遵守参与者的所有定义。

ps：建设一个符合客户需要的计算机系统，首要条件是完全彻底地搞清客户的业务，而不是预先假设已经有了一个计算机系统，再让客户来讲需要计算机系统帮他们做什么。

4、业务工人（business worker）
业务工人是配角，但缺少他们业务模型就不完整。
判断是参与者还是业务工人，就看他们是否在边界之内或者之外

5、参与者与涉众的关系（stackeholder）—也译作：利益相关者
利益相关者（stackeholder）也称为干系人。干系人是与要建设的这个系统有利益相关的一切人和事，干系人的利益要求会影响系统的建设。

6、参与者与用户的关系
用户（user）系统的使用者，系统（软件）的操作员。用户是参与者的代表。并非所有的参与者都是用户。参与者是对现实世界的，用户是针对系统的。

7、参与者与角色的关系
角色（role）是参与者的职责，代表了系统中的一类职责
一个用户可以代理多个参与者，因此一个用户可以拥有多个职责，也就是可以被指定多个角色。

8、参与者的核心地位
不言自明的事情

3、用例

1、用例（use case）
用一个椭圆表示
官方定义：用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值。

几个概念：
用例：一件事情，要完成这件事情，要做一系列活动
用例场景：做一件事情的很多不同的办法和步骤，也可能会遇到各种各样的意外情况，这些情况的集合构成用例场景。一个场景就是一个实例
一个完整的用例定义由参与者，前置条件（前提条件），场景，后置条件（结果）构成

2、用例的特征

• 用例是相对独立的。用例不需要与其他用例交互而独自完成参与者的目的。
• 用例的执行结果对参与者来说是可观测的和有意义的。（可感知，达成目标）
• 这件事必须由一个参与者发起。不存在没有参与者的用例
• 用例必然是以动宾短语形式出现。实际就是要有动作和动作对象。
• 一个用例就是一个需求单元，分析单元、设计单元、开发单元、测试单元、甚至是部署单元
  
  3、用例的粒度
  不同建模阶段对建模的思考角度是不一样的。因此粒度的选择也是不一样的。
  在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。及亿房网用法力可以描述一项完整的业务流程。
  在用例分析阶段（概念建模阶段）。用例的粒度以每个用例能描述一个完整的事件流为宜。可理解为一个用例描述一项完整业务中的一个步骤。
  系统建模阶段，用例视角是针对计算机的，粒度的选择以一个用例能够描述操作者与计算机的一次完整交互为宜。

4、用例的获得
发现用例的前提条件是发现参与者，确定参与者的同时就确定了系统的边界。用例的来源是参与者对系统的期望。

需求获取访谈中应当清楚地了解如下问题：

• 主角是位于系统边界之外的
• 主角对系统有着明确的期望和明确的汇报要求
• 主角的期望和汇报要求在系统边界之内
  
  有时两个主角所做的事某个完整目标的一个部分，需要合并成一个用例。有时两个主角做的事情有交叉，但的确是两个不同的目标，就应当当作两个不同的用例

5、用例和功能的误区
用例虽然是捕获功能性需求的，但用例并不是功能

使用者观点就是用例的观点。一个用例是一个参与者如何使用系统，获得什么结果的一个集合，通过分析用例，得出结构性和功能性的内容，最终实现用例，也就实现了使用者的观点。

一些关于功能的结论：
功能是脱离使用者的愿望而存在的。
功能是孤立的，是一个点
用例是一系列功能的集合，针对不同的应用场景，这些“功能体现不同的组合方式”。

6、目标和步骤的误区
随着抽象层次的不同，或者在建模阶段的不同，步骤也可以转化为用例，但是这个时候，进入用例（直面步骤）意味着边界已经改变，而边界的改变必然导致参与者也在边，因此参与者的完整目的也就改变了。如寄信是一个用例，而买信封，贴邮票是一个步骤，但是进入用例后，你的目的是买信封的时候，则买信封是一个完整用例，而不是步骤。

7、用例粒度的误区（实际是因为抽象层次的不同导致对粒度的不一致）
差生粒度错误的原因首先是分不清楚目标和步骤。并导致另一个后果是用例的粒度过于细小。粒度过小，系统分析没有抽象的余地。

在同一个需求阶段中用例粒度大小不一，原因是建模者心目中没有清楚的边界，应该时时检查现阶段处于哪个抽象层次而造成的。
边界决定了当前分析阶段的抽象层次，一个抽象层次决定了那些信息该暴露，那些不该暴露。

8、业务用例（business use case）
是专门用于需求阶段的业务建模，是普通用例的一个版型。她是现实世界业务领域的一个模型。是业务领域的一个模型，通过业务模型可以得到业务范围。业务范围不等于需求，软件需求真正的来源是系统范围，也就是系统模型。业务模型是系统模型的嘴重要输入。

9、业务用例实现（business use case realization）
也是用例版型中的一种，专门用于需求阶段的业务建模。她表达了同一项业务的不同实现方式
一个业务用例可以 有很多种实现方式，他们的关系可以类比编程上的接口和实现类的关系，同一个接口可以有多个实现类。

10、概念用例（business use case realization）
……
不知所云，但后面会重点介绍

11、系统用例
就是平时说的用例，体型用例就是用来定义系统范围，获取功能性需求的。是软件系统开发的全部范围，系统用例是我们得到的最终需求。

12、用例实现
用例的具体实现方式。
用例实现也是实现对象追溯到需求的一个重要环节。用例实现是连接用例模型和系统实现之间的桥梁。

4、边界

与封装概念类似，面向对象里，任何一个对象都有一个边界，外界只能通过边界来认识对象，与对象打交道，而对象内部则是一个禁区。

在需求出来之前，我们必须先设想一个边界，这个便捷的大小是不确定的。随着需求的明确，边界也逐步变得明朗。

1、边界决定视界

2、边界决定抽象层次

实际是个抽象层次的问题

3、灵活使用边界

实际上是平和实现需求，保证性能，方便扩展，友好易用之间的平衡。
因此：

• 将实现需求交给分析模型，考虑需求实现
• 将扩展能力交给框架设计
• 在框架的约束下吧分析模型转化为设计模型。

5、业务实体

业务实体是类（calss）的一种版型，用在业务建模阶段建立领域模型。为问题领域中的关键概念建立概念化的理解。（实际上就是一个类包含了那些属性和方法）。

业务实体描述了我们使用什么来达到业务目标及通过什么来记录这个业务目标。业务实体抽象出来问题领域内核心和关键的概念。

• 业务实体来自现实世界。
• 业务实体一定是在分析业务流程的过程中发现的。业务流程实际上就是业务用例场景。
• 业务实体作为类的一个版型，具有对象的说有性质，包括属性和方法，同时也具有对象的独立性。即业务实体只应当包含她本身固有的特性，而不能包含外界是如何使用她的信息。

1、业务实体的属性

属性时用来保存业务实体特征的一个记录，业务实体的属性集合决定了他的唯一性。（其实直接类比类的属性就行）

属性如果很复杂，是作为一个属性还是单独作为实体来使用呢？
如果只有一个对象可以直接使用这个属性，或者只能通过对象才能访问到这个属性，她就应当作为一个属性存在，否则就应当把他单独建模成一个业务实体。
这也是面向对象方法中封装原则的应用，不能因为一个对象内部很复杂，就将其拆分为多个对象展现给外部。

2、业务实体的方法

方法是方位一个业务实体的句柄，固定了外部可以怎样来使用它（类比于类的方法就好）

3、获取业务实体

业务实体代表业务角色执行业务用例时锁处理货使用的“事物”。一个业务实体经常代表某个对多个业务用例或用例实例有价值的事物，实际上这个定义就是我们获取业务实体的方法。

具体获取业务实体的步骤

• 1、首先建立业务用例场景。业务用例场景是参与者实现其业务目标的过程描述。（实际就是做一件事情的具体步骤的集合）
• 2、从业务用例场景中逐个分析动词后面的名词，他们就是业务实体的备选对象。根据对象对业务目标是否用贡献这一筛选条件从备选列表中挑选符合的对象。
• 3、最后分析这些业务实体之间的关系，并决定哪些应当单独建模，哪些应当作为属性。
• 4、经过以上三步，就获得了业务用例场景中的业务实体，这些业务实体代表了寄信这个业务目标中的关键概念。

6、包

包是一种容器，如同文件夹一样，将某些信息分类，形成逻辑单元。使用包的目的是为了整合复杂的信息，某些语言上相关或者某方面具有共同点的信息都可以分包。

UML对分包有着一些指导性原则，分包的好坏由包的依赖关系来评判，好的分包，具有高内聚，低耦合的性质

1、分包的指导性原则：

• 包内元素紧密联系不可分割。但包可以抽象出一些借口来代表包内事物与包外事物的交互，以避免包外的事务频繁地直接访问保内元素。这时，包内元素高内聚。
• 包的理想状态是修改不同包内的元素，其他包的内容不受影响，包与包之间无依赖关系或松耦合关系，他们之间可以保持消息通信
• 如果实际情况难以做到完全解除依赖关系，至少应当保证包之间的依赖关系不会被传递。即，两两影响，而不能影响到其他更多的包
• 包的依赖关系应当是单相的，应当尽量避免双向依赖和循环依赖。

2、包的一些版型
领域包（Domain Package）
领域包用于分类业务领域内的业务单元，每个包代表业务的一个领域，领域包视图可用于展示这些业务领域的高层次关系。

子系统（SubSystem）
用于分类系统内的逻辑对象并形成子系统，子系统包视图可用于展示系统的高层次逻辑结构关系

组织结构（Organinzation unit）
组织结构包用于分类业务领域中的组织结构，它可以直接用来表示企业的组织结构

层（Layer）
层包用于分类软件中的层次，层可以用于展示软件的架构信息。如mvc架构

7、分析类

官方定义：分析类用于获取系统中的主要“职责簇。”他们代表系统的原型类，是系统必须处理的主要抽象概念的“第一个关口”。如果希望获得系统的高级概念性件数，则可对分析类本身进行维护。分析类还可产生系统设计的主要抽象——系统的设计类和子系统。

两点特性：

• 分析类代表系统中的主要“职责簇”，意味着分析类是从功能性需求想计算机实现转化过程的“第一个关口”
• 分析类可以产生系统的设计类和子系统。意味着计算机实现是可以通过某种途径“产生”出来的

分析类是需求实现的第一步，分析类在整个生命周期中都一直进行着维护。分析类正好位于需求和实现的中间地带。

分析类的三个具体类
1、边界类
边界类是一种对系统外部环境与其内部运作之间的交互建模的类。这种交互包括转换时间，并记录系统表示方法（例如接口）中的变更。
在从需求向现实转换的过程中，任何两个有交互的关键对象之间都应当考虑建立边界类。

现实世界中：边界类可以是窗口（view），通信协议，打印机接口，
计算机世界：边界类可以是一个消息中间件，一个驱动程序，一组对象接口甚至任意的一个类。

当期望A、B两个对象之间的交互进行建模是，边界类，都可以充当这个载体。

常见的边界类

• 参与者与用例之间应当建立边界类
• 用例与用例之间如果有交互，应当为其建立边界类
• 如果用例与系统边界之外的非人对象（第三方系统），应当为其建立边界类
• 在相关联的业务对象有明显的独立性要求，即他们可能在各自的领域内发展和变化，但又希望互补影响时，也应当为之建立边界类。

2、控制类
控制类用于对一个或几个用例所特有的控制行为进行建模。控制对象（控制类的实例）通常控制其他对象，因此他们的行为具有协调性质。控制类将用例的特有行为进行封装。

控制类主要祈祷协调对象的作用，例如从边界类通过控制类方访问实体类，或者实体类通过控制类访问另一个实体类。

但是并不强制使用控制类，例如边界类也可以直接访问实体类。

3、实体类
实体类是用于对必须存储的信息和相关行为建模的类。实体对象（实体类的实例）用于保存和更新一些现象的有关信息。实体类通常是永久的，其属性和关系是长期需要甚至是在系统的整个生命周期都需要。

实体类主要位于数据持久层，实体类的获取对架构设计中的数据层有着重要的指导意义。

分析类（边界、控制、实体）的三高
高于设计实现：为需求考虑系统实现的时候，可以不理会复杂的设计要求。
高于语言实现：无需考虑是哪种语言
高于实现方式

8、设计类

设计类是系统实施中一个或多个对象的抽象，设计类锁对应的独享取决于实施语言。使用与编程语言相同的语言来描述

这个阶段设计类已经直接映射到实现代码了。
设计类来源于前期的系统分析。

设计类由类型、属性和方法构成，对应着编程语言中的class（类），property（属性），method（方法）

1、类

类说明了对象是什么，同时也决定了对象拥有什么属性，具有什么方法。

2、属性

属性时对象特征，同时表明了对象的唯一性。也是一个名词，描述与对象有关属性的角色。

3、方法

原则上，访问对象或者影响其他对象的属性或关系的唯一途径就是方法，直接访问和修改对象的属性时不提倡的。

4、可见性

公有：public
保护：protect
私有：private
实施：属性和方法只在类本身的内容时可视的

9、关系

1、关联关系（association）

使用一条直线表示，如A------------B，描述不同类的对象之间的结构关系，在一段时间内将多个类的实例连接在一起。

关联关系是一种静态、天然关系，与运行状态无关，所以关联关系是 一种“强关联”关系。

关联关系具有多重性，常见为一对一，一对多，多堆垛关联等，也可以是任意多重性关联。

关联关系一般不强调关联的方向。

2、依赖关系（dependency）

带箭头的虚线表示A------->B（A依赖B）。
描述一个对象在运行期会使用到另一个对象的关系，依赖关系是 一个临时性的关系，在运行期产生，并随着运行场景的不同，依赖关系可能发生变化。

依赖关系是一种“弱”关系，不是天然存在的，会随场景变化而变化。

依赖关系在最终的代码里体现为类的构造方法，类方法等待的传入参数，与关联关系相比，依赖关系出来临时“知道”对方外，还会“使用对方的方法或实行”(如传参)，这就导致了被依赖的对象改变会导致依赖对象的修改。

依赖分单向依赖和双向依赖，双向依赖不好。

3、扩展关系（extends）

一条带箭头的虚线加版型《extends》来表示，
表示A扩展出B

显式地表示一个复杂业务用例的各个分支

扩展表示的是“可选”，而不是“必需”，意味着及时没有扩展用例，基本用例也是完整的。如果没有基本用例，扩展用例是不能单独存在的。

4、包含关系（include）

一条带箭头的虚线加版型《inclue》来表示，

表示A包含B

基本用例和包含用例都不能访问对方的属性。因此包含用例是被封装的。代表可在各种不同基本用例中复用的的行为。用在概念模型中。

5、实现关系（realize）

一条带空心箭头的虚线表示，
表示A实现B，用于在用例模型中连接用例 和 用例实现，说明基本用例的一个实现方法。（时间一个事情的多种途径）

6、精华关系（refine）

一条带箭头的虚线加版型《refine》来表示，
表示A精化了B
一个基本用例可以分解出许多更小的关键精华用例，这些更小的精华用例更细致地展现了基本用例的核心业务。

精化关系也可以用于模型与模型之间，表示摸个模型是通过精化另一个模型而 得来。

精化关系精化出来的子对象没有增加，减少、改变基本对象的行为和属性。仅仅是更加细致和明确化了。

而泛华关系基本对象被泛华成子对象后，子对象继承了基本对象的虽有特征，并且子对象可以增加、改变基本对象的行为和属性。

泛华等同于实现语言的继承

7、泛华关系（generalization）

一条带空心箭头的直线表示，
表示A继承自B
泛化关系表示一个类对另一个类的继承，继承意味着祖先的定义对于后代的对象也是有效的。

8、聚合关系（aggregation）

一条带空心菱形箭头的直线表示，
A聚合到B上，或者说B由A组成
聚合表达整体由部分构成的语义，整体和部分不是强依赖的，即使整体不存在了，部分仍然存在。

9、组合关系（compostion）

一条带实心菱形箭头的直线表示，
A组合成B，或者说B由A构成。表达整体拥有部分的语义。
组合关系是一种强依赖的特殊聚合关系，整体消亡，这部分也消亡

10、组件

组件是系统中实际存在的可更换部分，她实现特定的功能，符合一套接口标准并实现一组接口。

组件代表系统中的一部分物理事实，包括软件代码或其他等价物（脚本或命令文件）

把那些紧密结合的类和接口组合起来实现一组特定的功能，形成一个组件。
一个类可能被分派给多个组件以完成该组件的功能，当组件被编译或打包成一个屋里文件是，每个组件都拥有这个累的一个拷贝或者引用该类的途径。

组件之间仅仅应当保持关联关系，甚至连关联关系都没有，他们之间是通过架构来沟通的，即松耦合

组件的特性：

1、完备性

包含一些类和接口，一个组件应当能够完成一项或一组特定的业务目标（功能）

2、独立性

组件可以独立部署，与其他组件物依赖关系，最多仅仅保持关联关系。组件与组件之间是松耦合关系

3、逻辑性

组件的定义时为了规划系统结构，将复杂系统分解为一个个具有完备功能的，可独立部署的小模块

4、透明性

组件的修改应当只涉及组件的定义及组件锁包含的类的重新制定，而不引导导致类的修改

5、使用组件

在以下情形中，使用组件比较有用

• 分布式应用
• 应用继承
• 第三方系统
• SOA（Service Oriented Architecture）服务:
  
  
  

11、节点

节点是带有至少一个处理器，内存等设备的处理元素。（物理机）

1、分布式应用环境

应用程序部署到不同的服务器或处理节点上

1、多设备应用环境

没什么好说的，没看懂，篇幅也小