面向对象方法分为面向对象分析（OOA）、面向对象设计（OOD）、面向对象编程（OOP），本文详细介绍面向对象分析
本文参考教材：沈备军老师的《软件工程原理》大多图片来源其中
目录
面向对象基础
用例图
活动图
类图
时序图
通信图
包图
分析建模五大步骤
用例建模
执行者的识别
用例的识别
用例图设计
用例规约的设计
活动图的设计
建立概念模型
用例实现的识别
分析类的识别
识别边界类
识别控制类
识别实体类
用例分析
面向对象基础
抽象：将事物的共性特征提取出来形成抽象类或接口，以便让其他类通过继承或实现来共享这些特征
封装：将对象特征的实现方式隐藏在一个公共接口后面的黑盒子中
模块化：将一个大型系统划分为相互独立的小块或模块的过程。每个模块都负责一个明确定义的功能，且与其他模块尽可能独立
层次化：将系统的组成部分按照不同的层次或级别进行组织和划分的过程。通常，一个系统可以分解为若干层，每一层都有特定的责任和功能
对象：是具有相同状态（属性）的一组操作的集合、是对问题域中某个东西的抽象，对象的优点包括以数据为中心、实现了数据封装、具有并行性、模块独立性好
类：类是对具有相同属性和行为的一个或多个对象的描述。类是支持继承的抽象数据类型，而对象就是类的实例
实例：由某个特定的类所描述的一个具体的对象，当使用“对象”这个术语时，既可以指一个具体的对象，也可以泛指一般的对象，但是，当使用“实例”这个术语时，必然是指一个具体的对象
方法：是对象所能执行的操作，也就是类中所定义的服务。方法描述了对象执行操作的算法，响应消息的方法。在C++语言中把方法称为成员函数
属性：是类中所定义的数据，类的每个实例都有自己特有的属性值
继承：能够直接获得已有的性质和特征，而不必重复定义它们。继承是子类自动地共享基类中定义的数据和方法的机制
多态性：子类对象可以像父类对象那样使用，同样的消息既可以发送给父类对象也可以发送给子类对象。根据该对象所属于的类动态选用在该类中定义的实现算法。在C++语言中，多态性是通过虚拟函数或者函数重载来实现的
重载：共有两种，函数重载是指在同一作用域内的若干个参数特征不同的函数可以使用相同的函数名字；运算符重载是指同一个运算符可以施加于不同类型的操作数上面
用例图
UML中的用例图是一种描述待建软件系统的上下文范围以及它提供的功能的概览视图，它从“黑盒”的角度，描述了谁（或什么）与系统交互，外部世界希望系统做些什么，下面描述了4S系统中整车销售的功能
通过这个图看出，用例图的组成要素如下：
执行者：是与系统交互的实体，可以是人、其它外界的硬件设备或系统，执行者应该位于系统外
用例：代表了执行者希望系统为他们做什么，用椭圆表示
关系：包括执行者和用例间的关系、用例和用例间的关系以及执行者和执行者间的关系。执行者和用例的关系叫做关联，用例和用例的关系有三种：包含、扩展、泛化，执行者和执行者的关系也只有一种叫做泛化
活动图
UML中的活动图用于刻画一个系统或子系统的工作流程，也可用于描述用例内部的事件流，提供了活动流程的可视化描述
通过这个图看出，活动图的组成要素如下：
动作：是行为的基本单元，一个活动可包含多个动作，用圆角矩形表示
控制流：用来表示从一个动作到另一个动作的控制，用一条带箭头的直线表示
初始节点：是活动开始的节点，用一个实心圆表示
终止节点：是活动结束的结点，可细分为活动终止和流终止，分别用带十字叉的圆和带边框的实心圆表示
分叉节点、汇合节点：用于表示并发流，用一条水平或垂直粗线来表示，分叉节点表示并发流程的开始，汇合节点表示并发流程的结束，图中“财务经理审批”或者“销售经理审批”是两个并发活动
判断节点：用菱形符号表示，一个判断节点可以有一个进入流和多个离去流
合并节点：用菱形符号表示，一个合并节点可以有多个进入流和一个离去流，如果一个合并节点接收到多个流，它的离去流指向的动作会被执行多次
对象节点：是动作处理的数据，用矩形表示
泳道可以看作是活动图的分区，它将活动图分为若干水平的区域，每个区域代表一个参与者、角色或系统部分。泳道的目的是清晰地表示哪些元素由哪些参与者执行，从而更好地理解系统中的活动流程，用泳道实现分组，使得每个参与者都明确了自己的责任
类图
在UML中，类的表示为一个矩形，分为三个区域，从上到下分别是类名、属性和操作，对于一个类的属性和操作有着不同的可见性类型
继承/泛化
在UML中，类之间的泛化关系用带空心三角形的实现来表示，比如下面这个图，Car继承了车Vehicle为单重继承，RV继承了Vehicle和House属于多重继承
关联
两个相对独立的类，当一个类的实例与另外一个类的特定实例存在固定关系时，这两个类之间就存在关联关系，在UML中，类之间的关联关系用实线箭头来表示，比如下图中，车和人之间存在关联，即人是车的主人
关联的两个连接点称为关联端，在关联端可以设置名字、可见性和基数等特性
基数：表明这一段的类最多有几个实例，其中，人针对车的角色名是主人，两端的基数是1对多，这表明：1个人可能有几辆车，也可能没有车，1辆车只能有1个主人
下面是一些基数的表示方法
聚合和组合
聚合和组合是一种特殊的关联，表示部分和整体关系的关联。在UML中，用带有空菱形的实线表示，空菱形要和聚合类相连接。组合类似于聚合，两者区别为：
发生聚合关系的两个类独立存在，组合中，当整体消亡，部分亦消亡
比如上面这个例子，Trailer（拖车）和卡车是组合关系，当卡车没有的时候，推车失去了意义。但车和车队是聚合关系，当某辆车离开车队的时候，这辆车依然可以在街上行驶
上述几个关系综合起来：
除此之外，其实还有一些其它关系，如依赖、接口、实现等，但由于不太常用，暂时就不叙述了，如果有机会，以后会直接在这里补充
时序图
时序图又称序列图，它通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作，以二维图的形式刻画，垂直维是时间，水平维是角色，表示参与交互的对象。
每个角色有一个名称和生命线，生命线用垂直虚线表示，表示整个交互过程中对象的声明期，在对象发送或接受消息时，生命线变成粗实线
在传递消息的过程中，消息总共分为三种：同步消息、异步消息和返回消息
同步消息用带实心箭头的实线表示，发出一个同步消息之后就开始等待，直到接收到返回消息，返回消息用带空箭头的虚线表示
异步消息用带空箭头的实线表示，对于异步消息而言发出去之后无需等待
下面是一个例子
我们可以看出，一个个紫框圈住的就是一对对同步消息和返回消息，对哪个角色发送信息就必须从哪个角色中接收到返回的信息
看到上面的图之后，发现了一些奇怪的东西就是一个又一个带标签的方框，像loop、alt、ref这种，这是什么意思呢？
实际上，这叫做序列片段（Fragment），可以用来简化时序图，分为四种：
交互使用：用于复用已定义的一个交互场景，它表现为一个带有ref标签的框，如图，在对象order被创建后就执行在已定义的get existing customer status时序图中定义的消息序列
循环：一个带有loop的框，由条件[get next item]控制执行，依次处理订单中的每一项内容
条件：可以有两个或多个分支，表现为一个带alt的框，如图在发送同步消息reserve后，会根据库存情况返回accept or reject
并发：可以有两个或多个并发执行的序列片段，表现为一个带有par标签的框
通信图
时序图主要用于描述对象之间的交互顺序和时间关系，强调消息的发送时间和接收时间的顺序，而通信图则主要用于描述对象之间的协作关系，强调消息的发送和接收顺序，强调每个参与者间的角色和职责
当两个对象对应的类存在关联关系时，对象之间则存在一条通信路径，称为链接（Link），信息的传递必须依附这种链接
上述时序图转换成通信图如下所示：
这个内容，暂时就说这么多，如果想要扩充对于通信图的知识，可以传送到下面这个大佬的文章
UML回顾-通信图（csdn作者：zhuojialin）
包图
当一个软件系统的规模过大，需要使用到一个叫做“包图”的东西
想象你在电脑上有一堆文件，这些文件按照功能和类型分门别类放在不同的文件夹里。UML 包图就是用来展示软件系统中类似文件夹结构的设计。每个“包”就像一个文件夹，里面装着相关联的软件元素。
这些包之间可以有不同的关系：
依赖关系： 一个包可以依赖于另一个包，表示它需要使用那个包里的内容。
关联关系： 两个包之间可能有关联，意味着它们之间有某种连接或者合作关系。
包含关系： 一个包可以包含其他包，就像一个文件夹里可以有另一个文件夹一样。
以下是4S系统的包图
分析建模五大步骤
上面讲解的是面向对象分析建模的预备知识，下面开始从前到后地讲解建模的每个步骤
注意：第四步和第五步是需要针对每个用例循环实现
用例建模
分析建模的第一步是建立系统的用例模型，其关键是通过对项目干系人需求的详细分析，识别出待开发软件系统的执行者和用例，画出用例图，并针对每个用例写出详细的用例规约
执行者的识别
所谓执行者，是为了完成一个事件而与系统交互的外部事物
识别执行者可以向自己提问以下问题：
谁需要在系统的帮助下完成自己的任务？
需要谁去执行系统的核心功能？
需要谁去完成系统的管理和维护？
系统是否需要和外界的硬件或软件系统进行交互？
比如说，对于4S系统，通过上述方法可以识别的执行者如下：总经理、店长、系统管理员、财务人员、销售经理、销售员、维修经理、维修员、采购经理、采购员、仓库管理员、运输员、质检员、人事管理系统
用例的识别
所谓用例，是系统执行的一个动作序列，这些动作必须对某个特定的执行者产生可观测的、有价值的结果
识别用例可以向自己提问以下问题：
actor希望系统提供什么功能？
actor 将创建、存取、修改和删除数据吗？
actor是否要告诉系统外界的事件？
actor 需要被告知系统中的发生事件吗?
例如，4S系统的用例可能包括以下内容
用例图设计
用于4S系统的规模很大，我们使用“包”来管理用例，将用例分组到不同的包中，画出包图如下
然后，我们以“整车销售”这个包为例，设计用例图如下：
下面是我们用visio设计的“小米便签”系统的用例图：
用例规约的设计
用例规约是一种文档，它描述了系统中一个或多个用例（用户场景或功能需求）的详细行为和交互。它为开发团队提供了有关系统如何响应各种输入和情境的具体指导。
它主要由以下元素构成：用例编号、用例名称、描述、执行者、前置条件、后置条件、基本流、备选流、扩展点、非功能需求、业务规划
下面对上面部分元素做出解释
前置条件：在执行某个特定操作或场景之前，系统或用户必须满足的条件或状态。
例子： 在登录系统之前，用户必须输入正确的用户名和密码。
后置条件：在执行操作或场景后，系统或用户可以期望的状态或结果。
例子： 在成功提交订单后，用户应该收到一份确认电子邮件。
基本流：描述了正常情况下系统或用户如何执行特定用例的步骤。
例子： 用户登录系统，浏览产品，将产品添加到购物车，进行结账。
备选流： 描述了在执行用例时可能发生的非正常或例外情况下的步骤。
例子： 用户尝试登录时输入了错误的密码，系统显示错误消息。
扩展点： 描述了在执行用例时可能触发的其他功能或场景。
例子： 在购物车中，用户可以选择使用优惠券，触发了一个扩展点。
非功能需求：不涉及具体功能，而是描述系统性能、安全性、可用性等方面的需求。
例子： 系统应该能够处理每秒1000个并发用户请求。
业务规划：描述了与用例相关的业务目标、战略或计划。
例子： 提供在线客户支持是公司业务规划的一部分，因此相关用例规约可能包括与在线聊天相关的行为。
下面是“提交购物订单”的用例规约
活动图的设计
“提交购物订单”的活动图设计如下
建立概念模型
分析建模的第二步是确定拟建系统必须处理的核心概念类，并识别这些类之间的关系，画出类图
概念类是那些能够始终贯穿分析和设计过程的类，往往对应重要的实体信息，识别概念类通常采用的方法是对相关的用例规约进行名词提取和过滤法，对其事件流进行分析
比如对于上述那个用例规约的基本流：
删除冗余名词、删除执行者和系统本身、删除属于边界类和界面的元素、删除类的属性，最后得到六个概念类——订单（Order）、购车订单（CarOrder）、顾客（Customer）、订单（CarOrderItem）、品牌（Brand）、型号（Model）
找到上面概念类之间的关系，画出类图
用例实现的识别
分析建模的第三步是识别“用例实现（Use Case Realization）”，它有助于将系统的用例（Use Cases）转化为更具体的设计和实现。这一步骤主要集中在如何实现用例中定义的功能，将用例转换为类、对象以及它们之间的关系
一个具体的“用例实现”提供了一个场所，主要包括以用例事件为线索的动态视图和静态视图
动态视图是直接对应用例事件流的动态交互图：通信图和时序图
静态视图是类图
用例与“用例实现”间的关系是实现（Realize），即依赖关系，在4S系统的分析建模过程中，采用一对一的用例实现识别策略，即一个用例对应一个用例实现
在识别用例实现之后，就要进入最后两步，对于最后两步，是对每个用例循环实现的
分析类的识别
作为分析建模的第四步，分析类的识别是系统从纯粹说明所需行为向具体描述系统工作方式转换的过程中的关键一步
对分析类进行设计，可以使用MVC设计模式，分别对应了系统的3个维度：
M（Model）：系统要记录和维护的信息，对应实体类
V（View）：系统和外部环境之间交互的边界，对应边界类
C（Control）：系统在运行中的控制逻辑，对应控制类
识别边界类
一个系统主要有三种边界类：用户界面类、系统接口类（比如ATM和银行会计系统的接口）、设备接口类（比如打印机接口、传感器接口）
识别规则是：执行者和用例之间的一条通信关联对应的一个边界类
若执行者是用户，则所识别的边界类是用户界面类
若执行者是外界系统，则所识别的边界类是系统接口类
若执行者是硬件设备，则边界类是设备接口类
对于4S系统的“提交购车订单UCR”，从用例图可以识别出一个用户界面类“CreateCarOrderForm”
还比如，在图书馆管理系统中，UIController（用户界面控制器）类可能是一个边界类，处理用户输入和显示输出
识别控制类
控制类负责协调系统中的各个部分，通常包含系统中的业务逻辑或流程控制，不直接处理数据，而是调度实体类和边界类之间的交互
例子：在图书馆管理系统中，LoanManager（借书管理器）类可能是一个控制类，负责协调借书和还书的流程
对于4S系统的“提交购车订单UCR”，从用例图可以识别出一个控制类“CreateCarOrderController”
识别实体类
实体类代表系统中的数据或信息，通常与问题领域中的实际概念相对应，包含属性，这些属性描述了实体的特征，实体类的对象通常具有唯一的标识符
通常可以从概念模型、术语表、业务领域模型、用例的文字描述中可以找到实体类
例如：在图书馆管理系统中，Book（书籍）类就是一个实体类，它可能有属性如书名、作者、出版日期等
对于4S系统的“提交购车订单UCR”，从用例图可以识别出6个实体类：订单（Order）、购车订单（CarOrder）、顾客（Customer）、订单项（CarOrderItem）、品牌（Brand）、型号（Model）
找到上面三种分析类之后，设计出分析类图如下：
用例分析
分析建模的第五步，是对拟建系统进行用例分析，针对每个用例实现，以用例作为研究对象，用分析类的实例作为载体，通过消息传递的方式实现对用例场景的分析，构建出相应的时序图、通信图和类图
用例的事件流中包含多个事件序列，其中有一个基本事件序列和若干备选事件序列，通常先绘制时序图，在对象之间用消息传递的方式把事件序列的内容复述出来。描述分析类实例之间的消息传递过程就是将职责分配到分析类的过程
通信图和时序图在本质内容上是等价的，可以利用建模工具从时序图自动生成相应的通信图
交互图（时序图、通信图）表达了“用例实现”的动态行为，而类图刻画了用例实现的静态特性。用例实现中的类图又称为VOPC类图，即参与协作完成该用例实现的分析类所组成的视图，根据用例实现中的时序图或通信图，就可以获得全部或大部分VOPC的类
一个典型的动态向静态映射的过程可以通过通信图中对象间的连接关系向分析类之间的关联关系的映射实现
依然是在4S系统的“提交购车订单UCR”用例实现中，根据其通信图，对先前的分析类图进行完善，建立分析类间的关联关系，形成VOPC类图如下
最后的最后就是分别确定上述每个分析类的职责和属性，其实就是一个类中的“函数”和“变量”，比如CarOrder这个分析类，完善之后的分析类如下所示
