UML建模图实战总结_uml建模实例100例

一、背景

UML：Unified Modeling Language（统一建模语言），是一种绘制软件蓝图的标准语言（是一种绘画语言，不是一种编程语言），为面向对象开发系统的产品进行说明、可视化、和编制逻辑文档。我们在面向对象的软件开发项目中，在程序规划、设计阶段，通过过使用 UML 的面向对象图的方式来更明确、清晰的表达项目中的架设思想、项目结构、执行顺序等一些逻辑思维 ，以帮助我们完成应用规划，设计，开发，UML 作为一种模型语言，它使开发人员早期更专注于建立产品的模型和结构，而不是选用什么程序语言和算法实现。UML 统一了Booch（早期面向对象的软件开发方法）、OMT（对象建模技术/方法）、OOSE（面向对象的软件工程）和其他面向对象方法所涉及的基本概念和建模符号。下面，让我们一起看下如何使用UML来建模实践。

UML 的目标：用 UML 作为软件工程中的建模机制，帮助我们按照实际情况或者按照我们需要的样式在项目早期对系统进行可视化，便于开发、用户尽可能清楚了解项目的建设需求，明确建设目标，挖掘真实需求和保证有效沟通；UML提供了一种详细说明系统的结构或行为的方法；给出一个指导系统构造的模板；客对我们所做出的决策进行文档化规范。

UML图是软件工程的重要组成部分，软件工程从宏观的角度保证了软件开发的各个过程的质量。而UML作为一种建模语言，更加有效的实现了软件工程的要求。

二、概述

使用UML进行建模的作用有哪些：

●可以更好的理解问题
●可以及早的发现错误或者被遗漏的点
●可以更加方便的进行组员之间的沟通
●支持面向对象软件开发建模，可以更好的描述显示编程的情景。
●对于复杂的系统来说，如果概要模型做的好，那么整个系统的模型也就很清晰明了。

UML模型主要有三部分构成：

事物(Things)：UML模型中最基本的构成元素，是具有代表性的成分的抽象,事物是实体抽象化的最终结果。UML中的事务也被称之为建模元素，包括：

结构事物：类，接口，协作（定义了交互操作），用例，活动类，构件和节点
行为事物：交互（消息，动作次序，连接），状态机
分组事物：只有包
注释事物

关系(Relationships)：关系把事物紧密联系在一起；

图(Diagrams )：图是事物和关系的可视化表示；UML采用4+1视图来描述软件和软件开发过程：

逻辑视图：以问题域的语汇组成的类和对象的集合
进程视图：逻辑视图的一次执行实例，描述了所设计的并发和同步结构
实现视图：对组成的物理代码文件进行建模
部署视图：把构建部署到一组物理上，可计算的节点上，表示软件和硬件的映射结构
用例视图：最简单需求分析模型

工具软件下载：StarUML，学习：相关资料。

UML 规格定义了两大类UML图：结构图（ structure diagrams ）和行为图（behavior diagrams），UML 图是面向对象的概念的表示。下图为UML2.5官方图，从中我们看下UML图分类：

从另一个角度，UML图又可分为用例视图、设计视图、进程视图、实现视图和拓扑视图，又可以静动分为静态视图和动态视图。静态图分为：类图，对象图，包图，构件图，部署图。动态图分为：用例图，状态图，活动图，协作图，序列图。

2.1、面向对象

1）面向对象基本概念：

对象: 对象代表一个实体的基本构建块.

类: 类是对象的蓝图.

抽象化: 抽象代表现实世界中实体的行为.

封装: 封装是将数据绑定在一起，并隐藏他们外部世界的机制。

继承: 继承是从现有的机制作出新的类。

多态性: 定义的机制来以不同的形式存在。

在UML的通用机制中，包用于将元素组织成组，构件是系统中遵从一组接口规范且付诸实现的物理的，可替换的软件模块。UML用关系把事物结合在一起，主要包括：依赖，关联，泛化， 实现；

2）面向对象的分析与设计可以描述为：

●在面向对象的分析，最重要的目的是确定（识别）对象和以适当的方式描述他们。如果这些对象可有效识别，那么接下来的设计工作是很容易的。对象应确定职责。职责是对象所执行的功能。每一个对象具有某种类型的要执行的责任。当这些责任协作可以完成最终企业/组织的目标，则系统的目的达成。

●第二阶段是面向对象的设计。在这个阶段的重点是满足关系要求及其职责履行情况，确定对象之间的关系，在这一阶段中的对象应根据其预期完成关联协作。

●第三阶段是面向对象的执行。在这个阶段，设计采用面向对象语言，如 Java，C++ 等，将类编译转换为可执行文件。

2.2、UML 10种图

1）用例图（UseCase Diagrams）：

它从用户的角度描述了系统的功能，并指出各个功能的执行者/使用者，强调用户的使用，系统为执行者完成哪些功能。主要回答了两个问题：1、是谁用软件。2、软件的功能。

在软件生命周期的整个过程中，用例图是软件需求分析到软件交付的第一步，用例图的主要目的是说明这个软件的使用者是谁，使用者要使用那些功能，以及使用者需要向软件提供什么功能（外部集成，用户交互输入等）。通过用例视图一来可以让使用者清楚的理解这个软件到底能提供什么功能，是不是满足自己的需求，另外一方面对应开发者来说，可以更好地理解需求，从而能更好的去实现这些需求。

用例图主要有六个元素：参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。

参与者（Actor）：在uml中用下面带有名字的小人图形来标示，主要表示与您的软件系统交互的人，组织或者外部软件系统。

用例(Use Case)：在uml中用使用椭圆标示，主要说明你的软件系统的功能，是使用文字描述的形式说明你的系统的功能。

关联关系(Association)：在uml的用例图中用箭头来标示，主要描述参与者与用例之间的关系。

包含关系（Include）：在uml中包含关系用虚线箭头+<名称>字样表示，有时候一个用例很大，那么我们可以把用例分块，把复杂的用例分解为几个小用例来描述；【箭头指向】：箭头指向被包含的用例，即指向分支。

扩展(Extend)：在uml中扩展关系用虚线箭头+<>字样表示，扩展是指在基础用例功能的基础上插入新的功能点，新的功能点可以看做是对基础用例的扩展。【箭头指向】：箭头指向基础用例，即指向父项。

泛化(Inheritance)：在uml中泛化用一个空心三角箭头从子用例指向父用例，泛化就是继承关系，子用例可以使用父亲用例中的属性，行为和关系。【箭头指向】：箭头指向父用例。

Include、Extend、Inheritance总结对比：

包含关系强调整体与部分之间关系，也就是说整体的功能是由一个个子用例功能叠加起来的，比如上图庭审功能就包含了线上视频庭审，线上语音庭审，线下语音庭审功能，庭审用例本身是对子功能的汇总标示，具体功能点在子用例实现。

扩展关系则强调是在基础功能的基础上添加新的功能，基础功能本身是提供功能的，基础功能和扩展功能直接是不可见的，但是扩展功能是要在基础功能的某一个条件下才会发生，例如上面基础服务视频庭审已经提供了庭审的功能，现在有加了了扩展的语音识别功能来识别用户说的话为文字。之所以说是扩展功能是因为即便没有语音识别功能，视频庭审功能还是照样可以正常运转，之所以说扩展功能是有条件发生是因为只有开通了语音识别的视频庭审才能回有语音识别的扩展功能

泛化关系则强调复用的关系，也就是说子用例基础了父用例的一部分功能并且自己有新增了或者覆盖了父用例的功能，具体说比如上图视频庭审有个记录笔录的功能，这个本身是个独立的功能点，而书记员和法官都可以复用这个功能并对其定制化。

示例：

2）时序图（序列图sequence diagram）：

工具：ZenUML 。

它是一种强调消息时序的交互图（interaction diagram），他由对象（Object）、消息（Message）、生命线（Lifeline）和Combined Fragments组成，它主要描述系统中对象和对象之间的交互，它将这些交互建模成消息交换。

序列图的主要用途是把用例表达的需求，转化为进一步、更加正式层次的精细表达。用例常常被细化为一个或者更多的序列图。同时序列图更有效地描述如何分配各个类的职责以及各类具有相应职责的原因。

时序图将交互关系展示成了一个平面二维图，其中纵向标示时间轴，时间沿竖线从上向下进行。横向轴标示了交互中各各个对象。对象的的用生命线表示。消息从一个对象的生命线到另一个对象生命线的箭头表示，箭头以时间顺序在图中从上到下排列，从左到右排列。

对象（Object）和生命线（Lifeline）：生命线头上那个方正的框里面存放的就是对象，对象有自己的名字，生命线其实就是从上到下的一个虚线。生命线标示一个对象存在的生命周期，两条生命线中间通过消息连接起来：

消息（Message）：用于对象间传递信息，对象之间的信息互通就是通过消息，消息按照分类可分为：同步消息（Synchronous Message），异步消息（Asynchronous Message）和返回消息（Return Message）、 自关联消息（Self-Message）。

同步消息：发送消息的对象在发送消息后会挂起，等消息接受对象接受消息返回后才会解除挂起的状态继续自己的工作。

异步消息：发送消息的对象在发送消息后会继续自己的工作，而不等消息接受对象接受消息返回。

返回消息：标示发送消息后返回的动作；
自关联消息：一个对象内自调用的情况。

另外，如上图示，时序图有控制焦点，控制焦点是一个瘦高的矩形，表示对象执行一个动作所经历的时间段，既可以是直接执行，也可以是通过下级过程执行。矩形顶部表示动作开始，矩形底部表示动作的结束。

区别：通信图（communication diagram）：它是一种强调收发消息的对象或角色的结构组织，强调参加交互的对象。在图形上，通信图是顶点和弧的集合。

构造通信图的第一步就是将参加交互的对象作为图的顶点，然后，把连接这些对象的链表示为图的弧，链上可能有标识这些对象的角色名，最后，用对象发送和接受的消息来修饰这些链。

区别协助图：序列图侧重时间顺序，协作图侧重对象间的关系。共同点：时序图与协作图均显示了对象间的交互。不同点：时序图强调交互的时间次序。协作图强调交互的空间结构。

Combined Fragments: 标示需有一定条件触发的消息发送。有：

Alternative fragment（denoted “alt”） 标示 if…then…else
Option fragment (denoted “opt”) 标示Switch
Parallel fragment (denoted “par”) 标示同时发生
Loop fragment(denoted “loop”) 标示for
Break标示退出循环

1> loop: 当没有指定循环边界默认范围为[0,无穷大]：

如果只指定了一个值，那么默认执行该值次数：

指定了循环边界,则最少执行最小值值，最多执行最大值次数：
实现do……while方式，至少执行一次,如果size<0则退出:

2>alt: 条件判断，如果n>0则执行agree函数，否者执行reject函数：

3>opt: switch，当满足不同条件执行不同方法：

4>break: n=10时候执行save并退出循环

5>par: 同时进行，比如多个线程同时执行任务

示例图1如下：

示例2图：

消息用从一个对象的生命线到另一个对象生命线的箭头表示。箭头以时间顺序在图中从上到下排列。

3）类图

类图是面向对象系统建模中重要的图，是定义其它图的基础。类图主要是用来展现软件系统中的类、接口以及它们之间的静态结构。

在uml类图中，类之间关系有如下: 泛化（Generalization）, 实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)

1> 泛化（Generalization）：

泛化是继承关系的一种，子类继承父类的所有行为和属性，子类可以新增新的功能或者重写父类功能。uml中使用带空心三角箭头的实线标示。【箭头指向】：箭头指向父类。

2> 实现（Realization）:

实现是接口和类的关系，是指类实现了接口中定义的接口，uml中用带空心三角箭头的虚线来标示。【箭头指向】：箭头指向接口类。

3>关联（Association)

在建模过程中必然存在类之间的联系，使类可以感知其他类的行为和属性，关联分为双向和单向关联；

双向关联（标准）：对于双向关联来说被关联的两个类可以感知对方的存在。

如上图所示，在线每端放置一个角色和多重值，对于Route来说我们应该看在bike端的角色和多重值，对于Route来说每个骑行路线对应0个或者多个自行车，0个是因为可能先制定了骑行路线但是还没有找到自行车，多个是因为可以有多个人骑行同一个路线。对于bike来说我们应该看route端的角色和多重值，对于一个bike来说每个自行车对于0个或者多个骑行路线，0个是因为虽然有一个自行车但是我可以不骑行，不指定骑行路线那，多个是因为我一个自行车可以指定多个骑行路线。

上面多重值为0…*,其实还有其他多重值如下表：

**单向关联:**对于一个单向关联来说也是两个类是相关的，但是只有一个类知道这种联系的存在。

如上图所示，对于单向关联表示为一条带有指向已知类的开放箭头实线，单向关联只包含一个角色名和多重值，一个人可以有0个或者多个账户，人可以感知到账户的存在，但是账户却感知不到人的存在。

4>聚合（Aggregation）

聚合是关联关系的一种，聚合主要描述整体与部分直接的关系，聚合有分为基本聚合和组合聚合。

基本聚合：部分类的生命周期独立于 整体类 的生命周期，uml中使用一条从整体类到部分类的实线，并在整体类的关联末端画一个未填充棱形标示，比如：一个汽车有4个轮子组成，轮子的生命周期不依赖与车的，因为车轮可以独立于车独立存在。如下：

组合聚合: 不同在于部分类的生命周期依赖整体类，uml中使用一条从整体类到部分类的实线，并在整体类的关联末端画一个填充棱形标示；如：一个公司有至少一个部门组成，部门要依赖于公司的存在而存在，不会存在一个部门而它不属于某一个公司。图示如下：

自身关联：自身关联涉及到一个类，是类自己关联自己的情况。比如：一个雇员可以有0个或者多个管理者，而管理者本身也是雇员的一种。图示如下：

5>组合(Composition)，

组合是聚合的变体，它具有强拥有关系，而且整体与部分的生命周期是一致的。在组合式聚合中，一个对象在某一个时间内只能是一个组合的一部分。 相对于聚合而言，在聚合中一个部分可以由几个整体共享。

6>依赖(Dependency)

依赖即一个类的实现需要其他类的协助，通常代码表现为方法参数，局部变量，静态方法调用，util类调用，uml中使用一条箭头的虚线，从依赖方指向被依赖的类。

示例图1：

说明：

先围绕类Library类分析下上面这个图，首先library通过组合方式关联到了Catalog目录类，这说明目录类不能独立存在要依赖图书馆存在，所以这里没有使用聚合而使用了组合。另外library通过聚合关联到了Book Item 类和Account账号类，这说明图书馆是有0个或者多个图书和账户组成，这里使用聚合而不是用组合是因为书和账号可以独立于图书馆存在，比如我有学号账号，但是图书馆里面不是必然有你的账号。

下面围绕Catalog分析，类目通过双向关联关联到bookitem，说明一个类目里面可能会有0个或者多个书籍，一个书籍对应着一个类目。另外类目有通过realization实现了search类和manage类的接口，让类目有搜索和管理功能。Search类搜索时候会依赖Patron类图书捐赠人的姓名地址或者Libraian类图书管理员的姓名地址，职位。 图书管理类时候会依赖图书管理员类的信息。

而Patron图书捐赠人有可能是一个学生，学生有自己的账号，所以patron类会聚合到Account；bookItem类通过泛化继承Book中书的共性部分信息。有通过关联关联到了account,说明一个账户只能接到0本和最多12本书，最多可以预定3本书。

最后Book类双向关联到Author类，数目一个作者至少写了1本书（严格说应该是0），一本书至少有一个作者编写，Account账户类有依赖一个AccountState的枚举值的类用来存放账号状态。

示例图2：

4）活动图（Activity Diagrams）

活动图是UML中一种行为图，它展示了控制流和对象流，并且强调它们的顺序和条件控制流。

1> 活动图构成元素

开始(inital)：

结束状态(final)：

活动(action)：标示动作

控制流(control flow)：链接活动，用带箭头的折现标识数据流流向；

决策(decison):条件判断

合并（merge）:任意一个节点到达该点都继续往下走，不管其他分支

游泳道（swimlanes）：模型中存在多个对象时候使用比较适合；分为水平和垂直：

分岔汇合（join）：所有分支都到该点时候才继续往下走，类似CountDownLatch.await后在继续往下走

分流（fork）：类似fork多个线程执行放入线程池执行

接受信号（acceptsignal）

2> 图例

示例1：下图为uml官方online shopping网上购物例子

说明：
上图，左上角黑色圆为活动开始，首先通过decision的条件判断是进行搜索还是浏览，如果是搜索则通过merge节点后搜索商品，然后通过decision节点判断搜到商品则进入在做决定是浏览商品信息还是加入购物车。加入购物车后可以选择进入B继续
搜索其他商品，或者查看购物车内容，然后购物完后，进入C进行付款，然后流程结束。

另外可以随时接受信号去查看，进入A查看购物车信息，也可以随时收到信号去checkout商品。

示例2：uml官方Activation of Trial Product激活试用产品例子

说明：
首先这个活动图里面由于模型涉及到了Order Management, Customer Service, Customer三个对象，所以使用了垂直的swimlanes。

首先customer请求激活自己正在使用的试用期产品（估计试用期过了，不能使用了），然后顾客服务对象通过fork开启两个流程，一个流程是让Order Management创建产品订单，一个是让用户产生C2V文件。然后Customer Service在 join 处等待两者完成，这里都完成在拿着产品秘钥和C2v文件去激活产品，通过email等把文件传递给用户，用户拿到文件既可以激活，至此活动结束。

5）组(构)件图（component diagram）

UML 组件图（Component Diagram）又称为构件图，组件图是为了表示组元（components），组元提供的接口（provided inerfaces）和需要调用的接口(required interfaces)，端口（ports）之间关系的一种图，展现了一个封装的类和它的接口，端口以及内嵌的构件和连接件构成的内部结构，展示系统中构件与构件之间，类或接口与构件之间的关系；用于表示系统的静态设计实现视图。它描述的是在软件系统中遵从并实现一组接口的物理的、可替换的软件模块。组件图是主要被用于基于组件开发时候用来描述SOA系统。构件之间的关系表现为依赖关系，定义的类或接口与类之间的关系表现为依赖关系或实现关系。

组件图 = 构件（Component）+接口（Interface）+关系（Relationship）+端口（Port）+连接器（Connector）。UML 构件图给提供了将要建立的系统的高层次的架构视图，这将帮助开发者开始建立实现的路标，并决定关于任务分配及（或）增进需求技能。

1> 组元（Component）

组元是代表一个系统中一个模块的类，并且组元的表现（比如实现）在其所在的环境上下文中是可被替换的，组元有自己的行为，比如对外提供接口和使用其他组件接口，这些接口潜在的是通过端口（ports）暴露或者使用。

如图语音识别服务组元对外提供getPort接口供其他组元调用，网上法庭说明自己需要使用getPort接口来实现自己的功能。

端口（port）：端口表述了一个一个类与它所在的环境或者其他类的一个交互点。

如图Accounting组元内部的Customers提供Account服务，而Orders组元则使用Account服务。

连接线（Connector）: 连接线是用来连接两个或者多个实例使他们直接能够进行交流协作。主要用来连接两个端口直接的交流.

示例1：

说明：

如图在网上商城系统有三个子系统组成：webstore,accounting,warehouses;WebStore子系统包含三个组员，搜索引擎，购物车，认证系统。搜索引擎组元通过对外提供了一个ProductSearch接口运行其他组件搜索和查看商品，另外这接口是搜索引擎组件使用库存组件提供的Search Inventory接口来实现。购物车组元则把调用订单组元的的Manage Orders接口的功能封装下自己对外提供了onllineShopping接口，认证组元则允许用户创建账号，登陆或者退出，并且绑定订单到具体用户。

accounting子系统对外提供了Manage Orders 和 Manage Customers接口，并且通过代理连接到子系统内部的Orders和customers组元，。Orders组元调用了Customers组元的Manager customers接口，Customers调用了Accounts组元的Manager Accounts模块。

Warehouses子系统提了Search Inventory and Manage Inventory组件，并且通过依赖方式是要了Accounting子系统的接口服务。

6）状态图

状态机图是一种行为图，它通过使用有限的状态转移展示了一个系统中一个模块的一些离散的行为，在UML2.4里面有两种状态机图：行为状态机（behavioral state machine），协议状态机（protocol state machine）。

1）行为状态（Behavioral State）

简单状态（Simple State）：简单状态没有子状态机和域，UML中使用带拐点的矩形标示简单状态，并且状态名字写在矩形内部。

组合状态（Composite State）：组合状态被定义为子状态或者嵌套状态的状态行为，子状态可以是顺序发生的也可以是并发发生，组合状态里至少有一个域，如下图含有一个域

*__ 起始状态（Initial Pseudostate），终止状态（Final State），（行为转移）Behavioral Transition

如图黑色实心为起始状态，末端双环圆为终止状态，中间连接线为行为转移，其中isAuthed为一个guard说明满足该条件才会进行状态转移，然后执行函数auidt。

2）行为状态机（behavioral state machine）

使用有限状态转移，表示一个系统中的离散行为的变换，行为被建模为通过一系列转移线连接起来的状态。一个简单的行为状态机：

3）协议状态机（Protocol State Machine）

协议状态机是行为状态机的一个子类，是行为状态的扩展，用来描述一个类的生命周期和协议，他描述一个类的哪一个动作可以被哪一个状态下的规定条件下被调用。

示例1：下图是一个Java线程状态机图（协议状态机图）

说明：如图 New状态是一个线程被创建但是没有执行start()方法时候状态。
在JVM看来当一个线程在Runnable时候它是在运行，但是在os看来却未必，因为线程可能没有获取到处理器。所以可以考虑把Runnable看为一个内部有两个子状态的组合状态，当一个线程状态进入Runnable时候，首先进入Ready状态（其他资源已经就绪，就差cpu），由线程调度策略决定何时把这个线程从Ready转变为running状态，函数Thread.yield() 则知识线程调度暂定当前线程执行，把线程从running状态转变为Ready状态…

区分：状态图和活动图都是行为图。状态图侧重从行为的结果来描述，活动图侧重从行为的动作来描述。状态图描述了一个具体对象的可能状态以及他们之间的转换。

在实际的项目中，活动图并不是必须的，需要满足以下条件：
1、出现并行过程&行为；
2、描述算法；
3、跨越多个用例的活动图。

区分：活动图VS交互图

二者都涉及到对象和他们之间传递的关系。区别在于交互图观察的是传送消息的对象，而活动图观察的是对象之间传递的消息。看似语义相同，但是他们是从不同的角度来观察整个系统的。

7）部署图（Deployment Diagrams）：

描述了系统运行时进行处理的结点以及在结点上活动的构件的配置。强调了物理设备以及之间的连接关系。

部署模型的目的：描述一个具体应用的主要部署结构，通过对各种硬件，在硬件中的软件以及各种连接协议的显示，可以很好的描述系统是如何部署的；平衡系统运行时的计算资源分布；可以通过连接描述组织的硬件网络结构或者是嵌入式系统等具有多种硬件和软件相关的系统运行模型。

8）包图（package diagram）

包图展现了由模型本身分解而成的组织单元以及它们的依赖关系。

9）定时图（timing diagram）

定时图是一种交互图，它展现了消息跨越不同对象或角色的实际，而不仅仅是关心消息的相对顺序。

10）交互概念图：

它是活动图和顺序图的混合物。

三、工具使用及实践

工具这里使用StarUML，使用参考地址参看。官网：https://staruml.io/

软件地址：https://d1ker3k6xq78py.cloudfront.net/current/us/v9.89.467.60.31
官方文档：https://docs.staruml.io/

3.1、过程示例

1）当我们接到一个开发需求时，首先需要用【用例图】描述用户的需求实现及对应的功能满足，这是---->软件需求分析的第一步。

用例图：用来描述系统与外部系统用户之间的交互视图；

用例模型中主要有包含关系，扩展关系，和泛化关系,下图中对其分别作了示例。

用例图中有三种元素，分别是参与者，用例和通信关联（图中普通黑线），参与者可以是人，也可以是其他系统，硬件设备，时钟等，对于用例的命名，最好采取动词短语和名词短语相连

2）完成初步需求分析后，使用【类图】分析系统的数据模型，确定需要包含的类及类间的关系，设计出了各类的属性和方法。软件设计经典的思想：类图和时序图。类图确定了软件数据模型的静态关型，【时序图】则是数据模型的动态关系。

类图用来描述系统的静态对象结构，反映了软件的数据模型。首先应该定义概念类的选取，然后确定类和类之间的关系。类之间的关系主要有关联关系，依赖关系，泛化关系，聚合关系，组合关系，实现关系等等。

面向对象的分析方法一般在软件需求工程中完成，面向对象分析中类分为三种类：

边界类：对外部系统环境和内部交互进行建模
控制类：对控制行为进行建模，多用来实现业务逻辑
实体类：存储信息和对相关行为进行建模

1>泛化关系：

2>依赖关系:这是一种比较弱的依赖关系，反映在代码中，比如说一个类向另一个类发送消息，一个类是另一个类的数据来源，一个类是另一个类中某个方法的操作参数等

3>关联关系：这是一种强依赖关系，反映在代码中，比如说类B的对象是类A的数据输入。或者类A中的方法中使用了作为全局变量的类B的对象

4>聚合关系：是关联关系的特例，体现整体与部分的关系

5>组合关系：是关联关系的特例，是一种更强聚合关系，两者是不可分割的

6>实现关系：就是类实现接口

3）确定类，也就确定了软件设计的数据模型，然后就可以使用【时序图】来确认【类图】中各类的交互关系，【用例图】中各功能的实现方案；

4）之后就可以用程序编写代码实现类了。

3.2、面向对象开发方法

1）面向对象的系统分析：

面向对象的系统分析（OOA）对问题进行功能分析，提出待解决的问题。对于管理生活费统来说，在这一阶段要深入了公司的工作习惯，业务范围及业务流程，并建立相应的概念模型，面向对象的分析结果直接约束设计过程及产品功能。此阶段的主要工作是给出系统层次结构：主题层、结构层、类和对象层、属性层、服务层；系统模型：对象模型、动态模型、功能模型。

2）面向对象系统设计：

面向对象系统设计（OOD)的任务，是在OOA的基础上，根据用户对系统功能和操作使用方面的需求及技术，经济和运行环境等方面的条件，继续运用面向对象的基本思想与概念，进一步细化、改进和扩展通过系统分析得到的系统逻辑模型，确立系统物理实现的技术方案，即：建立系统物理模型。这一阶段包括：一是从整体的角度对应用程序的框架进行设计，在明确了要解决的问题后对将要开发的软件进行类的划分，确定所需要的各个类模块。二是具体到每一个类，应用程序的设计主要就是类的设计，这个阶段贯穿于整个类的生存期。

3）系统实现“

实例建立：这一阶段是对问题的最后解决，在建立了类的基础上用代码实现对象实例。

组装测试：本阶段把系统组装成一个完整的应用进行测试。

应用维护：面向对象的继承机制使得维护工作相对容易，如果结构设计合理，对于大部分的工作维护一般都发生在类级。

几种典型的面向对象开发方法总结。

附录：文献参考

http://ifeve.com/uml-intro/
https://www.cnblogs.com/jiangds/p/6596595.html
w3cschool.cn/uml_tutorial/uml_tutorial-5y1i28pl.html
http://www.uml-diagrams.org/

未完待续……