软考学习 | 面向对象分析方法OOA_面向对象分析与设计工具 软考

面向对象的分析：运用OO方法，确定问题域，理解问题。

一、统一建模语言

1、UML的结构

UML的结构包括 构造块、规则、公共机制 三个部分。

（1）构造块。UML有三种基本的构造块：事物、关系、图。

• 事物：UML的重要组成部分，也称为建模元素，包括4种：结构事物、行为事物、分组事物、注释事物；

• 关系：把事物紧密联系在一起，主要有4种关系：依赖、关联、泛化、实现；

• 图：多个相互关联的事物的集合，UML2.0包括14种图；

（2）公共机制。公共机制是指达到特定目标的公共UML方法，主要包括规格说明（详细说明）、修饰、公共分类（通用划分）、扩展机制 4种。

• 1. 规格说明（详细说明）—— 是事物语义的细节描述，它是模型真正的核心；

• 2. 修饰：UML为每一个事物设置了一个简单的记号，可以通过修饰来表达更多的信息；

• 3. 公共分类（通用划分）—— UML包括两组公共分类：

• 类与对象：类表示概念，对象表示具体的实体。

• 接口与实现：接口用来定义契约，实现就是具体的内容。

• 4. 扩展机制 —— 包括：

• 约束：扩展了UML构造块的语义，允许增加新的规则或修改现有的规则；

• 构造型：扩展UML的词汇，用于定义新的构造块；

• 标记值：扩展了UML构造块的特性，允许创建新的特殊信息来扩展事物的规格说明；

（3）规则。规则是构造块如何放在一起的规定，包括：

• 命名：为构造块命名；

• 范围 ： 给一个名字以特定含义的语境；

• 可见性 ： 怎样使用或看见名字；

• 完整性 ： 事物如何正确、一致的相互联系；

• 执行 ：运行或模拟动态模型的含义是什么；

2、UML对系统架构的定义

UML通过5个视图来定义系统架构：

（1）逻辑视图。也称为设计视图，表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包、用例实现的子集。

（2）进程视图。是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。

（3）实现视图。对组成基于系统的物理代码的文件和构件进行建模。

（4）部署视图。把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。

（5）用例视图。最基本的需求分析模型。

3、事物

UML中的事物也称建模元素，包括结构事物、行为事物、分组事物、注释事物。

这些事物是UML模型中最基本的OO构造块。

（1）结构事物。静态部分。在模型中属于最静态的部分，代表概念上或物理上的元素。UML有7种结构事物，分别是：

• 类：描述具有相同属性、方法、关系、语义的对象的集合，一个类实现一个或多个接口；

• 接口：指类或构件提供特定服务的一组操作的集合，接口描述了类或构件的对外的可见的动作；

• 协作：定义了交互的操作，是一些角色和其他事物一起工作，提供一些合作的动作，这些动作比事物的总和要大；

• 用例：描述一系列的动作，产生有价值的结果。在模型中用例通常来组织行为事物，用例是通过协作来实现的；

• 活动类：活动类的对象有一个或多个进程或线程，它的对象代表的事物的行为和其他事物是同时存在的；

• 构件：物理上或可替换的系统部分，实现了一个接口集合；

• 节点：是一个物理元素，它运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力，一个构件集合一般来说位于一个节点，但有可能从一个节点转到另一个节点；

（2）行为事物。动态部分。（动作事物）是UML模型中的动态部分，代表时间和空间上的动作。UML有2种主要的行为事物：

• 交互（内部活动）：交互是由一组对象之间在特定上下文中，为达到特定目的而进行的一系列消息交换而组成的动作。交互中组成动作的每个对象的每个操作都要详细列出，包括*消息、动作次序（消息产生的动作）、连接（对象之间的连接）。在图形上，把一个消息表示为一条有向直线，通常在消息的线段上总有操作名。

• 状态机：状态机由一系列对象的状态组成。描述了一个对象或一个交互在生命周期内响应事件所经历的状态序列。在图形上，把状态表示为一个圆角矩形，通常在圆角矩形中含有状态的名称及其子状态。

补充：活动 描述计算机执行的步骤序列，活动的一个步骤称为一个动作，在图形上，把活动表示为一个圆角矩形。

（3）分组事物。组织部分。是UML模型中组织的部分。UML只有一种分组事物，

包：包是一种将有组织的元素分组的机制。结构事物、行为事物都可以放进包内。

包只存在于开发阶段，而构件可以存在于系统运行阶段。

（4）注释事物。解释部分。（注解事物）是UML模型的解释部分。

4、关系

UML用关系把事物结合在一起，主要有下列4种关系：

（1）依赖：依赖是两个事物之间的语义关系，一个事物发生变化会影响另一个事物的语义。执行有先后顺序，是一种在时间上的依赖关系。在图形上，把依赖画成一条有方向的虚线。包含关系和扩展关系都属于依赖关系。

（2）关联：是一种结构关系。关联描述一组对象之间连接的结构关系。关联体现的是对象实例之间的关系，而不表示两个类之间的关系。在关联上可以标注重复度和角色。关联包括组合和聚合，都是整体与部分的关系，其中组合事物之间关系更强。

组合：整体与部分，生命周期相同；空心菱形

聚合：整体与部分，生命周期不同；实心菱形

（3）泛化：一般/特殊关系，描述特殊元素（子元素）的对象可替换一般元素（父元素）的对象。子类和父类之间的关系，子类继承父类，父类是子类的泛化，在图形上表示为带空心箭头的实线，指向父元素。

（4）实现：接口与类之间的关系，是类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。在两种情况下会使用实现关系：

• 在接口和实现它们的类或构件之间；

• 在用例和实现它们的协作之间；

在图形上，实现关系是一条带有空心箭头的虚线。

几种关系所表现的 强弱 程度依次为：泛化 = 实现 >组合>聚合>关联>依赖

5、图

UML2.0包括14种图，2种类型。

1、结构图（静态视图）

（1）类图：一组类、接口、协作和它们之间的关系。

（2）对象图：展现了某一时刻一组对象以及它们之间的关系，描述了在类图中所建立的事物的实例的静态快照。

（3）构件图（组件图）：一个封装的类和它的接口、端口。是类图的变体。

（4）组合结构图：结构化类的内部结构。

（5）用例图：一组用例、参与者及它们之间的关系(包含、扩展、泛化)，对系统的行为进行组织和建模，是系统与外部参与者的交互。强调这个系统是什么，而不是这个系统怎么工作的。

（6）部署图：软硬件之间映射，描述对运行时的处理节点及在其中生存的构件的配置。

（7）制品图：系统的物理结构，包括文件、数据库、类似的物理比特集合。

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

2、行为图（动态视图）

2.1 交互图

（1）顺序图（序列图、时序图）：强调消息的时间次序的交互图，描述了以时间顺序组织对象之间的交互活动，顺序图的基本元素有：对象、参与者、生命线、激活框、消息、消息路线。其中消息是顺序图的灵魂。

（2）通信图（协作图）：强调收发消息的对象之间的结构组织（关系），每一个消息都有唯一的一个顺序号。

（3）定时图（计时图）：强调消息跨越不同对象的实际时间，而不仅仅只关心消息的相对顺序，特别适合实时和嵌入式系统建模，描述对象状态随着时间改变的情况，很像示波器。

（4）交互概览图：活动图+顺序图

2.2 其他动态视图

（4）状态图：描述一个状态机，由状态、转移、事件、活动组成，强调事件导致的对象行为，强调对象行为的事件顺序。显示出对象可能的状态，以及由状态改变而导致的转移。当某个事件发生 并且 满足监护条件时，对象的状态将发生改变。

（5）活动图：适合于描述复杂算法的执行流程，描述一个业务流程，说明活动之间的依赖关系。强调对象间的控制流程。将进程或其它计算结构展示为计算内部一步步的控制流和数据流。通常有2种方式使用活动图：

• 对工作流建模 — 常采用泳道将活动图中的活动状态分组；

• 对操作建模 — 把活动图作为程序流程图使用；

二、用例模型

从用户的角度看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，这是用例方法的基本思想。用例是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。

1、构建用例模型的4个阶段

（1）识别参与者

（2）合并需求获得用例

（3）细化用例描述

（4）调整用例模型

其中前三个阶段是必需的。

2、用例的元素

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

（1）参与者：外部实体，存在于系统外部，与系统进行交互的任何事物，可以是用户，也可以是其它外部系统和设备。参与者一定在系统外，不是系统的一部分；执行系统某项功能的参与者可能有多个。

（2）用例：是在系统中执行的一系列动作，它定义了系统是如何被参与者所使用的。

（3）通信关联：表示参与者和用例之间的关系，或用例与用例之间的关系；

通信关联箭头所指方是对话的被动接受者，箭尾所指方是对话的主动发起者；

信息流不是由通信关联来表示的，该信息流是默认存在的，并且是双向的，它与箭头所指的方向没有关系。

3、合并需求获得用例

在确定用例的过程中，需要注意以下问题：

（1）用例的命名采用“动词+名词”的形式。

（2）不能混淆用例和用例所包含的步骤。

（3）注意区分业务用例和系统用例。

4、细化用例描述

用例建模的主要工作是书写用例规约，而不是画图。

用例模板定义了用例规约，内容至少包括：

• 用例名

• 参与者

• 目标

• 前置条件

• 事件流

• 后置条件

5、调整用例模型

用例之间的关系主要包括包含、扩展、泛化。

（1）包含关系：当可以从两个或两个以上的用例中提取公共行为时，这个提取出来的公共用例称为抽象用例，而把原始用例称为基本用例，<<include>>是包含关系的构造型，箭头指向抽象用例。

（2）扩展关系：如果一个用例明显混合了2种或2种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和多个扩展用例，<<extend>>是扩展关系的构造型，箭头指向基本用例。

（3）泛化关系：当多个用例共同拥有一种类似的结构和行为时，可以将他们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例，子用例继承了父用例的所有结构、行为和关系。（箭头指向父用例）

从UML事物关系的本质上来看，包含关系和扩展关系都属于依赖关系。

三、分析模型

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

1、建立分析模型的过程

（1）定义概念类

（2）确定类之间的关系：关联、依赖、泛化、聚合、组合、实现

（3）为类添加职责

（4）建立交互图

前三个步骤称为CRC建模（类 — 责任 — 协作者）。