【OAA 】面向对象分析：从概念到实践

🔥个人主页：中草药

🔥专栏：【Java】登神长阶史诗般的Java成神之路

我们都知道Java是一门面向对象的开发语言，在软件开发的广袤天地中，面向对象分析（Object-Oriented Analysis，简称 OOA）宛如一座明亮的灯塔，为构建复杂软件系统指引着方向。它是一种强大的软件工程方法，致力于将现实世界的问题域转化为软件系统的分析模型，为后续的设计、开发与维护奠定坚实基石。

OAA的基本任务运用面向对象的方法，对各种问题域，用户需求，进行拆分和理解，正确认识事务之间的关系，找出描述问题域和系统功能的类和对象，定义他们的属性和职责（类中的属性和方法），以及他们之间形成的各种联系（对象与对象之间的依赖）。

一、UML

概念

UML（Unified Modeling Language），即统一建模语言，是一种用于软件系统可视化、详述、构造和文档化的标准建模语言。它在软件工程领域扮演着极为关键的角色，为软件开发过程中的不同阶段提供了丰富多样的模型表示方法，有效促进了软件开发团队成员之间的沟通与协作，极大地提高了软件开发的效率和质量。

组成部分

事物：也称为建模元素，包括结构事物，行为事物，分级事物和注释事物，这些事物是 UML 模型之中最基本的OO构造块。

关系：UML用关系把各个事物结合在一起，主要的关系有：依赖(dependency)、关联(association)、泛化(generalization)、实现（realization）

图：主要包括类图、对象图、构件图、组合结构图、用例图、顺序图、通信图、定时图、状态图、活动图、部署图、制品图、包图、交互概览图等

主要图

类图（Class Diagram）

类图是 UML 中最为核心的图之一，主要用于描述系统中的类结构、类之间的关系以及类的属性和操作。在面向对象的软件开发过程中，类图能够清晰地展示系统中的对象模型，帮助开发人员理解系统的静态结构。

例如，在一个图书馆管理系统中，通过类图可以定义 “图书” 类、“读者” 类、“借阅记录” 类等，以及它们之间的关联关系（如读者与借阅记录之间的一对多关系、图书与借阅记录之间的一对多关系等）、继承关系（如有不同类型的图书可能继承自 “图书” 类）和聚合关系（如借阅记录聚合了图书和读者的相关信息）。

开发人员可以依据类图进行代码的编写和数据库的设计，确保系统的结构合理、稳定。（后面进行详细介绍）

用例图（Use Case Diagram）--详细介绍

用例图从用户的角度出发，描述了系统的功能需求和用户与系统之间的交互场景。它主要包含参与者（Actor）和用例（Use Case）两个关键元素。参与者代表了与系统进行交互的外部实体，可以是人员、其他系统或外部设备（扫码枪）等；用例则是系统为满足参与者的需求而提供的功能单元。

以电商系统为例，用例图中可能会有 “消费者”“商家”“管理员” 等参与者，“消费者” 的用例可能包括 “注册”“登录”“浏览商品”“购买商品”“支付订单” 等，“商家” 的用例可能有 “商品上架”“管理库存”“处理订单” 等，“管理员” 的用例则可能涉及 “用户信息管理”“商品信息审核”“订单数据统计” 等。用

例图能够帮助项目团队明确系统的边界和功能范围，为后续的需求分析和系统设计提供重要的依据。

活动图（Activity Diagram）

活动图主要用于描述系统中的业务流程和对象的行为流程，它能够展示系统中各个活动之间的顺序、并发、分支和循环等关系。

在一个订单处理系统中，活动图可以详细地描绘从用户下单开始，经过订单审核、库存检查、支付处理、发货安排等一系列活动，直到订单完成的整个流程。

通过活动图，开发人员可以清晰地了解系统的动态运行机制，发现业务流程中的潜在问题和优化点，同时也有助于测试人员设计测试用例，确保系统的功能能够正确实现。

序列图（Sequence Diagram）

序列图着重展示对象之间的交互顺序和消息传递过程，它按照时间顺序详细描述了对象之间的协作关系。

例如，在一个在线聊天系统中，序列图可以展示用户发送消息、消息经过服务器转发、接收方接收消息等一系列操作的时间顺序和消息流向。

序列图能够帮助开发人员深入理解系统中对象之间的交互细节，确保在实现过程中各个对象之间的通信和协作正确无误，对于复杂系统的开发和调试具有重要的指导意义。

状态图（State Diagram）

状态图用于描述对象在其生命周期内的状态变化以及触发这些状态变化的事件。

以一个订单对象为例，它可能具有 “已创建”“已支付”“已发货”“已完成” 等不同的状态，当发生 “用户支付成功”“商家发货” 等事件时，订单对象会从一个状态转换到另一个状态。

状态图可以帮助开发人员全面了解对象的行为特性，在设计和实现过程中更好地处理对象的状态转换逻辑，提高系统的稳定性和可靠性。

二、用例模型

从用户的角度来看，他们并不想了解系统的内部结构和设计，他们关心的是系统所能提供的服务，把从用户那里获取的需求记录下来,进行合成与提炼，从而建立用例模型。在O0A方法中，构建用例模型一般需要经历以下阶段分别的，识别参与者、合并需求获得用例、细化用例描述和调整用例模型，其中前三个阶段是必需的，第四个阶段更像是对前几个阶段的补充。

用例图的元素

参与者：是指存在于系统外部与系统进行交互的任何事物，即可以使系统的用户，也可以是其他外部系统和设备等；

用例：指在系统中执行的动作，这些动作将生成参与者可见的结果，也就是说用例表示系统所提供的服务，它定义了系统是如何被参与者所使用的，描述的参与者为了使用系统的服务与使用发生的一段对话；

通信关联：表示的是参与者和用例之间的关系，或者用例与用例之间的关系。箭头所指方是对话的被动接受者，箭尾所指方是对话的主动发起者，如果不想强调对话中的主动与被动关系，可以使用不带箭头的关系实线。

识别参与者

参与者是与系统进行交互的外部实体，可以是人员、其他系统或外部设备等。识别参与者的关键在于全面梳理系统的边界，明确哪些实体在系统的运行过程中起到了直接的作用。参与者一定在系统之外，不是系统的一部分。

用户角色分析：在一个论坛系统中，常见的用户角色如普通用户，他们会进行注册、登录、浏览帖子，发布帖子，修改自己发布的帖子等操作；管理员则负责板块管理、帖子管理等；通过对不同用户角色的分析，能够清晰地界定系统的主要使用者及其在系统中的功能职责。

因此根据以上分析，明显的参与者有：管理员和普通用户

合并需求获得用例

在识别出参与者后，需要收集和整理他们对系统的各种需求，并将相关需求合并为用例，以清晰地描述系统的功能。

需求收集与整理：通过与不同参与者进行沟通、问卷调查、查阅相关文档等方式收集需求。对于消费者，他们可能提出希望能够快速浏览到相关帖子、查看帖子详情、与帖子发布者交流等需求；将这些零散的需求进行分类和归纳，为后续合并为用例做准备。

用例合并原则：按照功能的相关性和完整性进行合并。例如，消费者的注册、登录、找回密码等功能可以合并为 “用户账户管理” 用例；帖子的浏览、搜索、筛选等操作可合并为 “帖子查询与展示” 用例。在合并过程中，要确保每个用例都具有明确的目标和完整的功能流程，避免功能的遗漏或重复。

用例优先级确定：并非所有用例都具有同等的重要性，需要根据业务需求和用户的关键程度确定用例的优先级。在论坛系统中，“浏览”“搜索” 等用例通常具有较高的优先级，因为它们直接关系到系统的核心业务流程；而一些辅助性的用例，如 “用户设置个性化头像” 等可能优先级相对较低。确定优先级有助于在项目开发过程中合理安排资源和时间。

细化用例描述

细化用例描述是为了更深入、准确地阐述每个用例的具体行为和流程，以便开发团队能够清晰地理解和实现系统功能。

事件流描述：以 “发布帖子” 用例为例，其基本流程可能包括用户相系统发出发布新帖的请求，展示帖子编辑页面，用户选择发布的类别，用户输入帖子内容等步骤。在描述过程中，要详细说明每个步骤的操作对象、数据流向和系统的响应。

扩展流程与异常处理：考虑可能出现的扩展情况和异常情况。通过对这些扩展和异常流程的描述，能够增强系统的健壮性和用户体验。

前置条件与后置条件：明确每个用例的前置条件和后置条件。对于 “登录” 用例，前置条件可能是用户已注册且输入的用户名和密码格式正确；后置条件则是用户成功登录系统，系统为用户创建会话并记录登录状态。这些条件的明确有助于开发人员准确把握用例的执行环境和结果，确保系统的正确性和稳定性。

针对以上的用例描述可知，用户发贴前要对登录状态进行检查，发贴操作中包含身份检验，身份检查在其他操作中也都会涉及,所以我们抽象出一个身份检验的用例，使用用例图描述用例之间的关系如下所示:

至此完成关于用例的描述

三、分析模型

分析模型是对软件系统需求的一种结构化、抽象化的描述，它聚焦于系统的功能、数据以及它们之间的相互关系，而不涉及具体的实现细节。其核心作用在于帮助软件开发团队清晰地理解问题域，准确地把握系统的需求，确保开发的软件系统能够满足用户的期望。

定义概念类

OOA的主要任务就是找到系统中的对象和类，这些类将反映到00D中的软件类和00P中具体的实现类发现类的方式有很多种，其中应用最广泛的是名词短语法，具体步如下:

阅读和理解需求文档或用例描述
筛选出名词或名词短语，建立初始类清单(候选类)
将候选类分为三类:分别是显而易见的类，无意义的类和不确定类别的类
舍弃明显无意义类别的类
综合讨论不确定类别的类，直到把他们合并或调整到其他两个类别。

如该用例描述

我们可以得到

经过简单分析:“版块类别”和“版块帖子数量”都可以归结到“版块”类，做为“版块”类的属性;"帖子标题”和“帖子正文”都可以归结到"帖子“类，做为“帖子”类的属性;"权限”可以归结到“用户“类，做为“用户"类的属性。至此，针对发布帖子这个用例，就确定了三个类，分别是:用户、版块、帖子。

确定类之间的关系

类之间存在多种重要的关系，这些关系对于构建复杂的软件系统架构起着关键作用。主要包括关联关系、聚合关系、组合关系、继承关系和依赖关系。

关系类别

关联关系

关联关系是类之间最常见的一种关系，表示两个或多个类之间存在某种语义上的联系。这种联系通常通过对象之间的引用或指针来实现。

例如，在一个图书馆管理系统中，“图书” 类和 “读者” 类之间存在关联关系。读者可以借阅图书，因此 “读者” 类可能会有一个属性用于存储该读者所借阅的图书列表，而 “图书” 类也可能有一个属性记录借阅过该图书的读者信息。

这种关联关系的强度可以是一对一、一对多或多对多。一对一关联如一个人对应一个身份证号码；一对多关联如一个部门有多个员工；多对多关联如一个学生可以选修多门课程，一门课程也可以有多个学生选修。在代码实现中，通常会在关联的类中定义相应的属性来表示这种关系。

聚合关系

聚合关系是一种特殊的关联关系，它体现了整体与部分的概念，其中部分可以独立于整体存在。

比如，在一个汽车制造系统中，“汽车” 类和 “轮胎” 类之间是聚合关系。一辆汽车由多个轮胎组成，但轮胎在未安装到汽车上时仍然具有独立的存在意义，可以单独生产、销售和存储。

在代码中，聚合关系通常通过在整体类中包含对部分类的引用集合来表示。例如，“汽车” 类可能有一个属性是 “轮胎列表”，用于存储该车所装配的轮胎对象。聚合关系的生命周期管理相对较为松散，整体对象的销毁并不一定会导致部分对象的立即销毁。

组合关系

组合关系也是整体与部分的关系，但与聚合关系不同的是，组合关系中的部分不能脱离整体而单独存在，它们的生命周期紧密相连。

例如，在一个人体系统中，“人” 类和 “心脏” 类之间是组合关系。心脏是人体的重要组成部分，一旦人死亡，心脏也就失去了其原有的功能和意义，不能再独立存在。

在代码实现上，组合关系通常在整体类的构造函数中创建部分类的对象，并在整体类的析构函数中负责销毁部分类的对象。例如，“人” 类的构造函数可能会初始化一个 “心脏” 类的对象，当 “人” 类的对象被销毁时，其内部的 “心脏” 对象也会随之被销毁。

泛化关系

泛化关系也叫继承关系，允许一个类（子类）继承另一个类（父类）的属性和方法，从而实现代码的复用和层次化的类结构。子类可以在继承父类的基础上，添加自己特有的属性和方法，或者重写父类的某些方法以满足特定的需求。

例如，在一个图形绘制系统中，“图形” 类可以作为父类，它具有一些通用的属性如颜色、位置等和方法如绘制方法。然后 “圆形”“矩形”“三角形” 等类可以继承自 “图形” 类，它们继承了父类的通用属性和方法，并分别定义自己独特的属性（如圆形的半径、矩形的长和宽等）和重写绘制方法以实现各自的绘制逻辑。

继承关系形成了一种类的层次结构，使得代码的组织更加清晰和易于维护。

依赖关系

依赖关系是一种相对较弱的关系，表示一个类在其实现过程中使用了另一个类的某些功能，但并不像关联关系那样在类中持有另一个类的对象引用。

例如，在一个文件读取系统中，“文件读取器” 类可能依赖于 “文件系统” 类来获取文件的相关信息和进行文件操作。但 “文件读取器” 类并不直接持有 “文件系统” 类的对象，而是在需要进行文件操作时通过方法调用的方式与 “文件系统” 类进行交互。

Controller 依赖 Service 依赖 DAO

依赖关系通常在代码中表现为一个类的方法参数、局部变量或静态方法调用中使用了另一个类。这种关系使得类之间的耦合度相对较低，有利于系统的灵活性和可维护性。

实现关系

实现关系是一种重要的类之间的关联方式，主要体现在接口（Interface）与实现类（Implementing Class）之间。

接口定义了一组抽象的方法签名，但不包含方法的具体实现。它规定了实现类必须遵循的契约，描述了类应该具备的行为能力，但不涉及具体的实现细节。

实现类则负责具体实现接口中定义的方法，以满足接口所规定的行为要求。比如 “Circle” 类、“Rectangle” 类等都可以实现 “Shape” 接口。“Circle” 类实现 “draw” 方法时会根据圆的半径等属性绘制圆形图案，实现 “getArea” 方法时会根据圆的面积公式计算并返回面积；“Rectangle” 类实现这些方法时则会依据自身的长和宽属性进行相应的绘制和面积计算操作。

从代码层面来看，在 Java 语言中，实现类使用 “implements” 关键字来表明其与接口的实现关系。

因此由用户发布帖子的用例，在确定类与类之间的关系之后，可以用UML的类图把这些关系记录下来--用户发布帖子,帖子聚合成板块，板块组成了论坛