面向对象分析方法

最新推荐文章于 2024-07-10 08:15:00 发布

哈乐

最新推荐文章于 2024-07-10 08:15:00 发布

阅读量1.5k

点赞数 12

文章标签：程序人生

本文链接：https://blog.csdn.net/u011961970/article/details/136797538

版权

概念

OOA的基本任务是运用OO方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系。最终产生一个符合用户需求，并能直接反映问题域和系统功能的 OOA 模型及其详细说明。

OOA模型独立于具体实现，即不考虑与系统具体实现有关的因素。 OOA 的任务是 “ 做什么 ” ， OOD 的任务是 “ 怎么做 ” 。

一、UML

UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言，它融入了软件工程领域的新思想、新方法和新技术，它的作用域不限于支持 OOA 和 OOD，还支持从需求分析开始的软件开发的全过程。

UML 2.0 14种图

（1）类图（Class Diagram）。类图描述一组类、接口、协作和它们之间的关系。在

OO 系统的建模中，最常见的图就是类图。类图给出了系统的静态设计视图，活动类的类

图给出了系统的静态进程视图。

（2 ）对象图（ Object Diagram ）。对象图描述一组对象及它们之间的关系。对象图描

述了在类图中所建立的事物实例的静态快照。和类图一样，这些图给出系统的静态设计视

图或静态进程视图，但它们是从真实案例或原型案例的角度建立的。

（3 ）构件图（ Component Diagram ）。构件图描述一个封装的类和它的接口、端口，

以及由内嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图。

对于由小的部件构建大的系统来说，构件图是很重要的。构件图是类图的变体。

（4 ）组合结构图（ Composite Structure Diagram ）。组合结构图描述结构化类（例

如，构件或类）的内部结构，包括结构化类与系统其余部分的交互点。组合结构图用于画

出结构化类的内部内容。

（5 ）用例图（ Use Case Diagram ）。用例图描述一组用例、参与者及它们之间的关系。用例图给出系统的静态用例视图。这些图在对系统的行为进行组织和建模时是非常重要的。

（6 ）顺序图（ Sequence Diagram，序列图）。顺序图是一种交互图（interaction diagram），交互图展现了一种交互，它由一组对象或参与者以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图。

（7）通信图（Communication Diagram）。通信图也是一种交互图，它强调收发消息的对象或参与者的结构组织。顺序图和通信图表达了类似的基本概念，但它们所强调的概念不同，顺序图强调的是时序，通信图强调的是对象之间的组织结构（关系）。在UML1.X 版本中，通信图称为协作图（ Collaboration Diagram ）。

（8 ）定时图（ Timing Diagram，计时图）。定时图也是一种交互图，它强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序。

（9 ）状态图（State Diagram）。状态图描述一个状态机，它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。它对于接口、类或协作的行为建模尤为重要，而且它强调事件导致的对象行为，这非常有助于对反应式系统建模。

（10 ）活动图（Activity Diagram）。活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模和业务流程建模特别重要，并强调对象间的控制流程。

（11 ）部署图（Deployment Diagram）。部署图描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图。

（12 ）制品图（Artifact Diagram）。制品图描述计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合。制品图通常与部署图一起使用。制品也给出了它们实现的类和构件。

（13）包图（Package Diagram）。包图描述由模型本身分解而成的组织单元，以及它们之间的依赖关系。

（14）交互概览图（Interaction Overview Diagram）。交互概览图是活动图和顺序图的混合物。

二、用例模型

在 OOA 方法中，构建用例模型一般需要经历4个阶段.

阶段一：识别参与者，参与者一定在系统之外，不是系统的一部分。

阶段二：合并需求获得用例，注意区分业务用例和系统用例。

阶段三：细化用例描述，用例建模的主要工作是书写用例规约（use case specification），而不是画图。用例模板为一个给定项目的所有人员定义了用例规约的结果，其内容至少包括用例名、参与者、目标、前置条件、事件流（基本事件流和扩展事件流）和后置条件等，其他的还可以包括

非功能需求和用例优先级等。

阶段四：调整用例模型（可选）【关系包括：包含、扩展、泛化】

1．用例图的元素

在用例图中，主要包括参与者、用例和通信关联三种元素。

（1）参与者。参与者是指存在于系统外部并与系统进行交互的任何事物，既可以是使用系统的用户，也可以是其他外部系统和设备等外部实体。参与者一定在系统之外，不是系统的一部分。

（2）用例。用例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。也就是说，用例表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。

（3）通信关联。通信关联表示的是参与者和用例之间的关系，或用例与用例之间的关系。箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者，箭尾所指方是对话的主动发起者。如果不想强调对话中的主动与被动关系，可以使用不带箭头的关联实线。在用例模型中，信息流不是由通信关联来表示的，该信息流是默认存在的，并且是双向的，它与箭头所指的方向没有关系。

三、分析模型

分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及它们如何保持通信，实现系统行为（动态模型）。

为了使模型独立于具体的开发语言，需要把注 意力集中在概念性问题上而不是软件技术问题上 ，这些技术的起点就是领域模型。领域模型又称为概念模型或简称为域模型，也就是找到那些代表事物与概念的对象，即概念类。 概念类 可以从用例模型中获得灵感，经过完善将形成分析模型中的 分析类 。每一个用例对应一个类图，描述参与这个用例实现的所有概念类，而用例的实现主要通过交互图来表示。例如，用例的事件流会对应产生一个顺序图，描述相关对象如何通过合作来完成整个事件流，复杂的备选事件流也可以产生一个或多个顺序图。所有这些图的集合就构成了系统的分析模型。