软件工程–面向对象分析用通俗语言20小时爆肝总结！（包含用例图、活动图、类图、时序图……）

本文介绍: 本文用通俗语言详细讲解软件工程面向对象分析建模的知识

面向对象方法分为面向对象分析（OOA）、面向对象设计（OOD）、面向对象编程（OOP），本文详细介绍面向对象分析

本文参考教材：沈备军老师的《软件工程原理》大多图片来源其中

面向对象基础

抽象：将事物的共性特征提取出来形成抽象类或接口，以便让其他类通过继承或实现来共享这些特征

封装：将对象特征的实现方式隐藏在一个公共接口后面的黑盒子中

模块化：将一个大型系统划分为相互独立的小块或模块的过程。每个模块都负责一个明确定义的功能，且与其他模块尽可能独立

层次化：将系统的组成部分按照不同的层次或级别进行组织和划分的过程。通常，一个系统可以分解为若干层，每一层都有特定的责任和功能

对象：是具有相同状态（属性）的一组操作的集合、是对问题域中某个东西的抽象，对象的优点包括以数据为中心、实现了数据封装、具有并行性、模块独立性好

类：类是对具有相同属性和行为的一个或多个对象的描述。类是支持继承的抽象数据类型，而对象就是类的实例

实例：由某个特定的类所描述的一个具体的对象，当使用“对象”这个术语时，既可以指一个具体的对象，也可以泛指一般的对象，但是，当使用“实例”这个术语时，必然是指一个具体的对象

方法：是对象所能执行的操作，也就是类中所定义的服务。方法描述了对象执行操作的算法，响应消息的方法。在C++语言中把方法称为成员函数

属性：是类中所定义的数据，类的每个实例都有自己特有的属性值

继承：能够直接获得已有的性质和特征，而不必重复定义它们。继承是子类自动地共享基类中定义的数据和方法的机制

多态性：子类对象可以像父类对象那样使用，同样的消息既可以发送给父类对象也可以发送给子类对象。根据该对象所属于的类动态选用在该类中定义的实现算法。在C++语言中，多态性是通过虚拟函数或者函数重载来实现的

重载：共有两种，函数重载是指在同一作用域内的若干个参数特征不同的函数可以使用相同的函数名字；运算符重载是指同一个运算符可以施加于不同类型的操作数上面

用例图

UML中的用例图是一种描述待建软件系统的上下文范围以及它提供的功能的概览视图，它从“黑盒”的角度，描述了谁（或什么）与系统交互，外部世界希望系统做些什么，下面描述了4S系统中整车销售的功能

通过这个图看出，用例图的组成要素如下：

执行者：是与系统交互的实体，可以是人、其它外界的硬件设备或系统，执行者应该位于系统外

用例：代表了执行者希望系统为他们做什么，用椭圆表示

关系：包括执行者和用例间的关系、用例和用例间的关系以及执行者和执行者间的关系。执行者和用例的关系叫做关联，用例和用例的关系有三种：包含、扩展、泛化，执行者和执行者的关系也只有一种叫做泛化

活动图

UML中的活动图用于刻画一个系统或子系统的工作流程，也可用于描述用例内部的事件流，提供了活动流程的可视化描述

通过这个图看出，活动图的组成要素如下：

动作：是行为的基本单元，一个活动可包含多个动作，用圆角矩形表示

控制流：用来表示从一个动作到另一个动作的控制，用一条带箭头的直线表示

初始节点：是活动开始的节点，用一个实心圆表示

终止节点：是活动结束的结点，可细分为活动终止和流终止，分别用带十字叉的圆和带边框的实心圆表示

分叉节点、汇合节点：用于表示并发流，用一条水平或垂直粗线来表示，分叉节点表示并发流程的开始，汇合节点表示并发流程的结束，图中“财务经理审批”或者“销售经理审批”是两个并发活动

判断节点：用菱形符号表示，一个判断节点可以有一个进入流和多个离去流

合并节点：用菱形符号表示，一个合并节点可以有多个进入流和一个离去流，如果一个合并节点接收到多个流，它的离去流指向的动作会被执行多次

对象节点：是动作处理的数据，用矩形表示

泳道可以看作是活动图的分区，它将活动图分为若干水平的区域，每个区域代表一个参与者、角色或系统部分。泳道的目的是清晰地表示哪些元素由哪些参与者执行，从而更好地理解系统中的活动流程，用泳道实现分组，使得每个参与者都明确了自己的责任

类图

在UML中，类的表示为一个矩形，分为三个区域，从上到下分别是类名、属性和操作，对于一个类的属性和操作有着不同的可见性类型

继承/泛化

在UML中，类之间的泛化关系用带空心三角形的实现来表示，比如下面这个图，Car继承了车Ve h icle为单重继承，RV继承了Ve h icle和House 属于多重继承

关联

两个相对独立的类，当一个类的实例与另外一个类的特定实例存在固定关系时，这两个类之间就存在关联关系，在UML中，类之间的关联关系用实线箭头来表示，比如下图中，车和人之间存在关联，即人是车的主人

关联的两个连接点称为关联端，在关联端可以设置名字、可见性和基数等特性

基数：表明这一段的类最多有几个实例，其中，人针对车的角色名是主人，两端的基数是1对多，这表明：1个人可能有几辆车，也可能没有车，1辆车只能有1个主人

下面是一些基数的表示方法

聚合和组合

聚合和组合是一种特殊的关联，表示部分和整体关系的关联。在UML中，用带有空菱形的实线表示，空菱形要和聚合类相连接。组合类似于聚合，两者区别为：

发生聚合关系的两个类独立存在，组合中，当整体消亡，部分亦消亡

比如上面这个例子，Tr aile r（拖车）和卡车是组合关系，当卡车没有的时候，推车失去了意义。但车和车队是聚合关系，当某辆车离开车队的时候，这辆车依然可以在街上行驶

上述几个关系综合起来：

除此之外，其实还有一些其它关系，如依赖、接口、实现等，但由于不太常用，暂时就不叙述了，如果有机会，以后会直接在这里补充

时序图

时序图又称序列图，它通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作，以二维图的形式刻画，垂直维是时间，水平维是角色，表示参与交互的对象。

每个角色有一个名称和生命线，生命线用垂直虚线表示，表示整个交互过程中对象的声明期，在对象发送或接受消息时，生命线变成粗实线

在传递消息的过程中，消息总共分为三种：同步消息、异步消息和返回消息

同步消息用带实心箭头的实线表示，发出一个同步消息之后就开始等待，直到接收到返回消息，返回消息用带空箭头的虚线表示

异步消息用带空箭头的实线表示，对于异步消息而言发出去之后无需等待

下面是一个例子

我们可以看出，一个个紫框圈住的就是一对对同步消息和返回消息，对哪个角色发送信息就必须从哪个角色中接收到返回的信息

看到上面的图之后，发现了一些奇怪的东西就是一个又一个带标签的方框，像loop、alt、ref这种，这是什么意思呢？

实际上，这叫做序列片段（Frag m ent），可以用来简化时序图，分为四种：

交互使用：用于复用已定义的一个交互场景，它表现为一个带有ref 标签的框，如图，在对象order被创建后就执行在已定义的get e x i s t in g cu s tome r status时序图中定义的消息序列

循环：一个带有loop的框，由条件[get next item]控制执行，依次处理订单中的每一项内容

条件：可以有两个或多个分支，表现为一个带alt的框，如图在发送同步消息re serve后，会根据库存情况返回 a cc ept or rejec t

并发：可以有两个或多个并发执行的序列片段，表现为一个带有p ar 标签的框

通信图

时序图主要用于描述对象之间的交互顺序和时间关系，强调消息的发送时间和接收时间的顺序，而通信图则主要用于描述对象之间的协作关系，强调消息的发送和接收顺序，强调每个参与者间的角色和职责

当两个对象对应的类存在关联关系时，对象之间则存在一条通信路径，称为链接（Lin k），信息的传递必须依附这种链接

上述时序图转换成通信图如下所示：

这个内容，暂时就说这么多，如果想要扩充对于通信图的知识，可以传送到下面这个大佬的文章

UML回顾-通信图（csdn作者：zhuojialin）

包图

当一个软件系统的规模过大，需要使用到一个叫做“包图”的东西

想象你在电脑上有一堆文件，这些文件按照功能和类型分门别类放在不同的文件夹里。UML 包图就是用来展示软件系统中类似文件夹结构的设计。每个“包”就像一个文件夹，里面装着相关联的软件元素。

这些包之间可以有不同的关系：

依赖关系：一个包可以依赖于另一个包，表示它需要使用那个包里的内容。
关联关系：两个包之间可能有关联，意味着它们之间有某种连接或者合作关系。
包含关系：一个包可以包含其他包，就像一个文件夹里可以有另一个文件夹一样。

以下是4S系统的包图

分析 建模五大步骤

上面讲解的是面向对象分析建模的预备知识，下面开始从前到后地讲解建模的每个步骤

注意：第四步和第五步是需要针对每个用例循环实现

用例建模

分析建模的第一步是建立系统的用例模型，其关键是通过对项目干系人需求的详细分析，识别出待开发软件系统的执行者和用例，画出用例图，并针对每个用例写出详细的用例规约

执行者的识别

所谓执行者，是为了完成一个事件而与系统交互的外部事物

识别执行者可以向自己提问以下问题：

谁需要在系统的帮助下完成自己的任务？
需要谁去执行系统的核心功能？
需要谁去完成系统的管理和维护？
系统是否需要和外界的硬件或软件系统进行交互？

比如说，对于4S系统，通过上述方法可以识别的执行者如下：总经理、店长、系统管理员、财务人员、销售经理、销售员、维修经理、维修员、采购经理、采购员、仓库管理员、运输员、质检员、人事管理系统

用例的识别

所谓用例，是系统执行的一个动作序列，这些动作必须对某个特定的执行者产生可观测的、有价值的结果

识别用例可以向自己提问以下问题：

actor希望系统提供什么功能？
actor 将创建、存取、修改和删除数据吗？
actor 是否要告诉系统外界的事件？
ac tor 需要被告知系统中的发生事件吗?

例如，4S系统的用例可能包括以下内容

用例图设计

用于4S系统的规模很大，我们使用“包”来管理用例，将用例分组到不同的包中，画出包图如下

然后，我们以“整车销售”这个包为例，设计用例图如下：

下面是我们用visio 设计的“小米便签”系统的用例图：

用例规约的设计

用例规约是一种文档，它描述了系统中一个或多个用例（用户场景或功能需求）的详细行为和交互。它为开发团队提供了有关系统如何响应各种输入和情境的具体指导。

它主要由以下元素构成：用例编号、用例名称、描述、执行者、前置条件、后置条件、基本流、备选流、扩展点、非功能需求、业务规划

下面对上面部分元素做出解释

前置条件：在执行某个特定操作或场景之前，系统或用户必须满足的条件或状态。
例子：在登录系统之前，用户必须输入正确的用户名和密码。
后置条件：在执行操作或场景后，系统或用户可以期望的状态或结果。
例子：在成功提交订单后，用户应该收到一份确认电子邮件。
基本流：描述了正常情况下系统或用户如何执行特定用例的步骤。
例子：用户登录系统，浏览产品，将产品添加到购物车，进行结账。
备选流：描述了在执行用例时可能发生的非正常或例外情况下的步骤。
例子：用户尝试登录时输入了错误的密码，系统显示错误消息。
扩展点：描述了在执行用例时可能触发的其他功能或场景。
例子：在购物车中，用户可以选择使用优惠券，触发了一个扩展点。
非功能需求：不涉及具体功能，而是描述系统性能、安全性、可用性等方面的需求。
例子：系统应该能够处理每秒1000个并发用户请求。
业务规划：描述了与用例相关的业务目标、战略或计划。
例子：提供在线客户支持是公司业务规划的一部分，因此相关用例规约可能包括与在线聊天相关的行为。