走上高级的路径（二）----UML中的核心建模元素

参考自《大象UML》

UML中建模元素包含三种

1、事物（4种）：结构事物、行为事物、分组事物、注释事物

2、关系（4种）：泛化关系、实现关系、依赖关系、关联关系

3、图（10种）：用例图、对象图、状态图、活动图、序列图、类图、包图、组件图、部署图、协作图

事物是对模型中最具代表性的成分的抽象；关系是把事物结合在一起；图聚集并展示了事物如何相关。

1、核心元素---参与者/主角actor

,actor是在系统之外与系统交互的某人或某事物，在系统之外说明参与者与系统之间是有一个明确的边界的，actor只可能存在边界之外，边界之内的所有人和事物都不是参与者。

小王去银行开户，银行里面有大厅经理、柜台职员以及其他人员帮助他开了户拿到存折，请问谁是actor，小王才是actor，其他都不是，大厅经理、柜台职员可以称之为business worker

怎么寻找actor，按照定义，问两个问题，

1、谁对系统有着明确的目标和要求并且主动发出动作？（小王主动要求开户）

2、系统是为谁服务的？（系统为用户提供服务）

actor一定得是人吗？不是的，在不同的边界里面actor可以是人、计算机系统、一个JMS消息，并且是主动发出动作。

下面买个机票，说明一下如何寻找actor

情形一：购票人，登录机场的机票预订系统进行订票。按照actor的定义，购票人有购票的目标，并且主动发起购票行为。这个里面购票人就是actor。

情形二，购票人通过人工坐席订票，注意，以机场为边界人工电话坐席、购票预订系统都是在机场边界内的，这个时候购票人是actor，人工电话坐席是business worker，但是在机场的内部，以购票预订系统为边界，人工电话坐席是acotr，或者称之为business actor。

情形三，购票人通过自助呼叫中心购票，注意，以机场为边界自助呼叫中心、购票预订系统都是在机场边界内的，这个时候购票人是actor，自助呼叫中心是business worker，但是在机场的内部，以购票预订系统为边界，自助呼叫中心是acotr，或者称之为business actor，这里actor就不是人。

情形四，购票人通过电话购票，可以选择人工坐席还是自助语音，注意，以机场为边界人工坐席、自助语音、购票预订系统都是在机场边界内的，这个时候购票人是actor，呼叫中心、自助语音是business worker，但是在机场的内部，以购票预订系统为边界，人工坐席和自助语音都是acotr，或者称之为business actor。

总结：在寻找actor时，一定要与边界结合在一起，边界的不同决定了actor的选择不同，同一个人员，在不同的边界情况下，会是actor、business actor、business worker等等，这在不同的边界下都是相对的。

2、核心元素--business actor

business actor是actor的一个类型，actor是一个普适性叫法，business actor更加具有针对性，也可以说business actor是actor的一个实例。

business actor是与业务系统有着交互的人和事物，他们用来确定业务范围，business actor 遵循actor的定义。

注意，业务范围和系统范围是不相同的，业务范围指这个项目所涉及的所有客户业务，这些业务在没有计算机系统参与时都是客观存在的。系统范围是指软件将要实现的那些对应于业务功能的系统功能，从功能性需求来说系统范围是业务范围的一个子集，但是一些系统范围则会超出业务范围，例如操作日志，没有日志的情况下不影响业务目标的达成，客户也不一定会提出这个要求，但从系统角度出发，操作日志会使得系统更加健壮。

business actor是客户业务范围里面的业务人员，并不是普通的actor，这些business actor不管有没有计算机的存在都是客观存在的，例如在订票系统的情形二，以机票预订系统为边界，人工坐席是business actor，以机场为边界，购票人是actor，人工坐席是business worker。

business actor在客户的业务体系里面都是有明确的岗位名称和职责说明的，并且他们掌握着业务用例。

3、核心元素--business worker

business worker比较特殊，它是帮助actor达成目标过程中里面的被动执行者，actor是主动发起者，business worker根据actor的意愿执行操作，是在用例场景中出现的，business worker在边界不同下相对变化的。可使用actor的定义来甄别它，因为actor的定义要求actor主动发起动作，有完整的业务目标，并且系统是为actor服务的。

 

核心元素----用例 use case

use case是UML中的最核心元素，use case 是actor驱动的，不论actor是否是人，不存在没有actor的用例。use case代表了actor的业务目标，也就是actor想做什么并且得到什么，这个目标就是现实世界中的事，而这个事怎么做，依据什么规则，UML通过业务场景business scenario和用例场景 use case scenario的视图来描述，而场景中牵扯到的物，则通过业务对象模型business object model的视图来说明。

用例是一种将现实世界的功能性需求捕获下来的方法。功能性需求体现在世界上的人的愿望，愿望驱使人做事情，达成目标。为达成目标所做的事情构成了一个系统的功能性需求。

一个系统的功能性是由一些对系统有愿望的参与者要做的一些事情构成的，事情完成后就达成了参与者的一个愿望，当全部参与者的所有愿望都能够通过用例来达到，那么这个系统就被确定下来了。捕获功能性需求，这就是用例的作用

用例，就是一件事情，要完成这个事情，需要一系列的活动；而做一件事情可以有很多的办法和步骤，也可能会有各种各样的情况，这些方法、步骤、情况集合在一起就是这个事情，UML中称完成这个事情所需要的方法、步骤为用例场景，一个用例场景就是一个用例的实例。

一个完整的用例有参与者、前置条件、用例场景（可以是多个）、后置条件构成。例如做米饭，做米饭前提就是得有米和水，用例执行完了，米变成了饭，这就是后置条件。

 

用例都是从actor中获取的。细一点的解释是

1、actor的有效目标才是一个用例的来源

2、一个真实的目标应当完备的表达主角的愿望

3、一个有效的目标应当在系统边界内，由actor启动目标，并且有明确的结果

 

更细一点的解释呢，什么样的用例才是有效的用例？、

1、用例都是相对独立的

这意味着用例不需要与其他用例交互而能够独自的完成actor的目标，不能完整的达到actor的目标的不能称之为用例。例如去取钱，取钱你会填写取款单，那么这个里面取钱是用例，是你的目标；填写取款单就不是用例。

2、用例的执行结果对actor都是可观测和有意义的

机场系统数据定期自动备份，这个就不是购票人的目标，购票人看不到也对他没意义，系统备份应该系统需求中出现，而不是一个actor用例，而是系统用例。

3、用例必须是actor发起的，不存在没有actor的用例，用例不应该自启动，也不应该去启动另外一个用例。

actor去ATM机取钱是一个用例；ATM吐钞票就不是，这是一个糟糕的错误。

4、用例的命名都是动宾短语的形式。

用例的名称都是一个动作加上一个动作的受体。取钱、喝水、购票。

5、一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元、部署单元。

 

用例的误区

用例与功能的误区

用例虽然是用来捕获功能性需求的，但用例并不是功能。用例是从参与者角度出发获取功能性需求，但功能是从工具的角度来说的，或者说功能是计算机术语。

前面说过，在没有计算机系统的时候，客户的业务都是客观存在的。是经过一步一步达成业务目标的时候，我们需要功能来支撑

这每一步，并不是功能去达成业务目标，我们根据用户的业务目标将功能组织起来达成目标。

用例可以解释为一系列完成特定目标的功能的组合，针对不同的应用场景，功能将有不同的组合方式，并不是先有了功能，而是先有了用例的场景，才能从场景里面分解出功能。

用例与步骤的误区

一个用例是actor对目标系统的一个愿望，一个完整的事件。为了完成这个事件需要经由很多步骤，但中间的这些步骤不能够完整的反映参与者的目标，中间的步骤不能作为用例。

比如去邮局寄信，这是一个准确有效的用例。但是去邮局你要买信封、买邮票、付钱、填写寄信人信息、收信人信息，这些步骤就不是用例。

买信封、等等这些可不可以是用例？可以的，但这个时候用例的边界是发生了变化的，并不是原来actor寄信这个用例的边界了，而是进到边界里面，在另外一个层次上的用例了。

用例粒度的误区？

 

3、核心元素  业务用例 business use case

业务用例是用例的一个实例，专门用于业务建模，也就是脱离计算机的情况下客户的现有业务下进行建模，通过业务建模是可以得到业务范围

4、核心元素  业务用例实现 business use case realiztion

业务用例实现是业务用例的一种实现方式。比如交话费，可以到营业厅缴费、银行缴费、线上缴费

5、核心元素 系统用例

系统用例是定义系统范围、获取功能性需求的。系统用例使我们得到的最终的针对计算机的需求

6、核心元素 概念用例 conception use case

 

-----------对象间的关系

类之间的关系

 泛化Generalization、实现Realization、关联Association、聚合Aggregation、组合Composition、依赖Dependency

泛化关系，

关联关系，，关联关系是一种强关联关系，它描述不同类对象之间的结构关系，关联关系是一种静态关系，通常与运行状态无关，而是由“常识、规则、法律”等因素决定的。例如乘车人与车票之间、公民与身份证之间。关联关系用来定义对象之间静态的、天然的结构。与依赖关系不同的是，依赖关系表达的是对象之间临时性的、动态的关系，在最终的代码里面关联关系通常是以实例变量的形式存在。关联关系的对象之间不会直接使用，尽管他们相互知道的存在，但一般都是通过外部对象来访问的，比如一个外部访问者可以通过员工获得公司对象。在代码里面A对象保存了B对象，A对象对B对象没有操作，这时A仅仅知道B对象，并且B修改了自身的方法等，A也不会受影响。

关联关系有一对一、一对多。

关联关系不强调关联方向，但在用例模型中，单向关联关系用于连接参与者与用例，箭头由参与者指向用例，表明actor知道用例的存在。

 

依赖关系是一种弱关系，，它不是天然存在的，是根据运行场景随时变化的，比如做饭用的菜刀，脱离了做饭场景，人依赖于菜刀这个关系就不存在了；在代码里，体现在构造方法、类方法中的传入参数，与关联关系相比，依赖关系除了临时知道对方，还会使用对方的方法和属性，对方的方法和属性变化，会对依赖方产生影响。

使用单向依赖，不要使用双方依赖

聚合关系

，A聚合到B上，或者说B由A组成，聚合关系特别用于表示实体对象之间的关系，表达整体由部分组成的语义，例如一个部门由多个人员组成。

与组合关系不同的是，整体和部分不是强依赖的，即使整体不存在了，部分依然可独立存在，部门解散了，不存在了，人员还是存在的

组合关系

，A组合成B，或者说B由A构成。特别用于表示实体对象关系，表达整体拥有部分的语义，例如母公司拥有很多子公司，组合是一种强依赖的特殊聚合关系，如果整体不存在，部分也不存在，母公司解散了，子公司也不存在了。

对于继承、实现这两种关系体现的是一种类与类、类与接口间的纵向关系，这个没什么疑问。

其他门的组合、聚合、关联、依赖体现的是类与类、类与接口的间的横向关系，比较难以区分，但这四种关系都是语义级别的，从代码层面不能完全区分各种关系，但总的来说四种关系语义上的强弱为组合>聚合>关联>依赖

用例之间的关系

关联、

泛化(作者不推荐在用例之间使用泛化)、

扩展extends、

扩展关系特别用于在用例模型中说明向基本用例中的某个扩展点插入扩展用例。是从用例中的可选项抽象提取出来的

扩展用例表示了用例场景中的某个支流，由特定的扩展点触发而被启动，严格的说扩展用例应当用在概念用例买模型中，通过分析业务用例场景抽象出关键的可选核心业务而形成扩展用例，不过在业务模型中使用也是可以接受的，它可以更现实的表示出一个复杂业务用例的各个分支。

与包含关系不同的是，扩展关系是可选的，不是必需的，这意味着即便没有扩展用例，基本用例也是完整的；如果没有基本用例，扩展用例是不能单独存在的，如果有多个扩展用例，同时间用例实例也只会使用其中一个。

可以使用打电话时的接听保留来解释。打电话时，如果另外一个电话进来，actor可以选择保留通话或者不保留，完全取决于actor，但不管保留或不保留，都没有影响到基本的通话用例，不影响打电话的完整性。但保留通话用例在没有之前的打电话用例是不可能单独启动保留通话用例。

包含include、

包含关系，说明在执行基本用例的用例过程中插入的行为段。

包含用例是抽象出来的。基本用例可控制包含用例的关系，并依赖包含用例的结果。包含用例是被封装的，它代表可在各种不同基本用例中复用的行为，与扩展用例一样，包含用例也应当用在概念用例模型中，通过业务用例场景而抽象出关键的必选的核心业务而形成包含用例。同样，在业务模型中使用也是可以接受的，它可以显示的表示出那些可复用的业务过程。

与扩展用例不同的是，包含用例是必需而不是可选的，缺少了包含用例，基本用例是不完整，同时没有基本用例，包含用例是不能单独存在的。

使用包含用例基于以下情况：

1、从基本用例中分解出这样的行为：这个行为对于了解基本用例的主要目的不是必需的，但是这个行为的结果是重要的

2、分解出两个或多个用例所共有的行为

例如：去银行办理取钱、转账都要核对账户和密码，因为核对账户是一个包含用例，它可为多个基本用例使用，但没有基本用例这个包含用例是没有意义的，我只是去核对账户吗？核对账户后干什么呢？

实现realize

，说明基本用例的多个实现方式，基本用例描述了一个业务目标，但达成该目标有多种可能的实现途径。每一种实现途径可以用用例实现来表示，而用例实现与基本用例之间就构成了实现关系，每个实现途径都实现了基本用例的业务目标。

 

精化关系refine

一个基本用例可以分解出许多更小的关键精化用例，这些更小的精化用例更细致的展示了基本用例的核心业务。精化关心也可以用于模型与模型之间，表示某个模型是通过精化另一个模型而得来的。比如说设计类是通过精化分析类而得来的。

精化关系表示由基本对象可以分解出更明确、精细的子对象，这些子对象并没有增加、减少、改变基本对象的行为和属性，仅仅是更加细致和明确化了。在泛化关系中，基本对象被泛化为子对象后，子对象继承了基本对象的所有特征，并且子对象可以增加、改变基本对象的行为和属性。

精化关系仅仅用于建模阶段，在实现语言中并没有精化这一语义，泛化则等同于实现语言中的继承语义。

之前讨论过概念模型是用于获取业务模型中的关键概念的。这些关键概念共同组成一个易于理解的业务框架。这些关键概念是对业务用例的精化，它们表示为概念用例到业务用例的精化关系。