|
|
知识路径： > 系统开发和运行维护知识 > 系统分析基础知识 > 面向对象分析方法 >
|
被考次数：5次
被考频率：中频率
总体答错率：53%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：20个
|
|
|
|
|
面向对象分析方法（Object-Oriented Analysis，OOA）的基本任务是运用OO方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和责任，以及它们之间的关联，最终产生一个符合用户需求，并能直接反映问题域和系统功能的OOA模型及其详细说明。
|
|
|
|
|
|
|
|
在面向对象的系统中，对象是基本的运行时的实体，它既包括数据（属性），也包括作用于数据的操作（行为）。所以一个对象把属性和行为封装为一个整体。封装是一种信息隐蔽技术，它的目的是使对象的使用者和生产者分离，使对象的定义和实现分开。从程序设计者来看，对象是一个程序模块；从用户来看，对象为他们提供了所希望的行为。在对象内的操作通常叫作方法。一个对象通常可由对象名、属性和操作三部分组成。
|
|
|
|
|
|
对象之间进行通信的一种构造叫作消息。当一个消息发送给某个对象时，包含要求接收对象去执行某些活动的信息。接收到信息的对象经过解释，然后予以响应。这种通信机制叫作消息传递。发送消息的对象不需要知道接收消息的对象如何对请求予以响应。
|
|
|
|
|
|
一个类定义了一组大体上相似的对象。一个类所包含的方法和数据描述一组对象的共同行为和属性。把一组对象的共同特征加以抽象并存贮在一个类中的能力，是面向对象技术最重要的一点；是否建立了一个丰富的类库，是衡量一个面向对象程序设计语言成熟与否的重要标志。
|
|
|
|
类是在对象之上的抽象，对象是类的具体化，是类的实例（instance）。在分析和设计时，我们通常把注意力集中在类上，而不是具体的对象。我们也不必为每个对象逐个定义，只需对类做出定义，而对类的属性的不同赋值即可得到该类的对象实例。
|
|
|
|
通常把一个类和这个类的所有对象称为“类及对象”或对象类。
|
|
|
|
|
|
继承是父类和子类之间共享数据和方法的机制。这是类之间的一种关系，在定义和实现一个类的时候，可以在一个已经存在的类的基础上来进行，把这个已经存在的类所定义的内容作为自己的内容，并加入若干新的内容。
|
|
|
|
一个父类可以有多个子类，这些子类都是父类的特例，父类描述了这些子类的公共属性和操作。一个子类可以继承它的父类（或祖先类）中的属性和操作，这些属性和操作在子类中不必定义，子类中还可以定义自己的属性和操作。
|
|
|
|
如果只从一个父类A得到继承，叫作单重继承。如果一个子类有两个或更多个父类，则称为多重继承。
|
|
|
|
|
|
在收到消息时，对象要予以响应。不同的对象收到同一消息可以产生完全不同的结果，这一现象叫作多态（polymorphism）。在使用多态的时候，用户可以发送一个通用的消息，而实现的细节则由接收对象自行决定。这样，同一消息就可以调用不同的方法。
|
|
|
|
多态的实现受到继承的支持，利用类的继承的层次关系，把具有通用功能的消息存放在高层次，而不同的实现这一功能的行为放在较低层次，在这些低层次上生成的对象能够给通用消息以不同的响应。
|
|
|
|
多态有几种不同的形式，Cardelli和Wegner把它分为4类，如下图所示。其中，参数多态和包含多态称为通用多态，过载多态和强制多态称为特定多态。
|
|
|
|
|
|
|
|
参数多态是应用比较广泛的多态，被称为最纯的多态。包含多态在许多语言中都存在，最常见的例子就是子类型化，即一个类型是另一个类型的子类型。过载（overloading）多态是同一个变量被用来表示不同的功能而通过上下文以决定一个名所代表的功能。
|
|
|
|
|
|
绑定是一个把过程调用和响应调用所需要执行的代码加以结合的过程。在一般的程序设计语言中，绑定是在编译时进行的，叫作静态绑定。动态绑定则是在运行时进行的，因此，一个给定的过程调用和代码的结合直到调用发生时才进行。
|
|
|
|
动态绑定是和类的继承以及多态相联系的。在继承关系中，子类是父类的一个特例，所以父类对象可以出现的地方，子类对象也可以出现。因此在运行过程中，当一个对象发送消息请求服务时，要根据接收对象的具体情况将请求的操作与实现的方法进行连接，即动态绑定。
|
|
|
|
|
|
统一建模语言（Unified Modeling Language，UML）是面向对象软件的标准化建模语言。由于其简单、统一，又能够表达软件设计中的动态和静态信息，目前已经成为可视化建模语言事实上的工业标准。
|
|
|
|
从企业信息系统到基于Web的分布式应用，甚至严格的实时嵌入式系统都适合用UML来建模。因为UML是一种富有表达力的语言，可以描述开发所需要的各种视图，然后以此为基础装配系统。
|
|
|
|
|
|
|
|
（1）构造块。UML有3种构造块：事物、关系和图。事物是对模型中最具有代表性的成分的抽象；关系把事物结合在一起；图聚集了相关的事物。
|
|
|
|
（2）规则。规则是支配构造块如何放置在一起的规定，包括给构造块命名；给一个名字以特定含义的语境，即范围；怎样使用或看见名字，即可见性；事物如何正确、一致地相互联系，即完整性；运行或模拟动态模型的含义是什么，即执行。
|
|
|
|
（3）公共机制。公共机制是指达到特定目标的公共UML方法，主要包括规格说明（详细说明）、修饰、公共分类（通用划分）和扩展机制4种。规格说明是事物语义的细节描述，它是模型真正的核心；UML为每个事物设置了一个简单的记号，可以通过修饰来表达更多的信息；UML包括两组公共分类：类与对象、接口与实现；扩展机制包括约束、构造型和标记值。
|
|
|
|
UML对系统架构的定义是系统的组织结构，包括系统分解的组成部分，以及它们的关联性、交互机制和指导原则等提供系统设计的信息。具体来说，有以下5种系统视图：
|
|
|
|
（1）逻辑视图。逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。
|
|
|
|
（2）进程视图。进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。
|
|
|
|
（3）实现视图。实现视图对组成基于系统的物理代码的文件和构件进行建模。
|
|
|
|
（4）部署视图。部署视图把构件部署到一组物理节点上，用来表示软件到硬件的映射和分布结构。
|
|
|
|
|
|
|
|
UML中有4种事物：结构事物、行为事物、分组事物和注释事物。
|
|
|
|
（1）结构事物（structural thing）。
|
|
|
|
结构事物是UML模型中的名词。它们通常是模型的静态部分，描述概念或物理元素。UML有7种结构事物：类（class）、接口（interface）、协作（collaboration）、用例（use case）、主动类（active class）、构件（component）和节点（node）。结构事物的图形表示如下图所示。
|
|
|
|
|
|
|
|
类是描述具有相同属性、方法、关系和语义对象的集合，一个类实现一个或多个接口。接口是指类或构件提供特定服务的一组操作的集合，接口描述了类或构件的对外可见的动作。协作定义了交互的操作，使一些角色和其他事物一起工作，提供一些合作的动作。用例是描述一系列的动作，产生有价值的结果。在模型中用例通常用来组织行为事物。用例是通过协作来实现的。主动类的对象有一个或多个进程或线程。构件是物理上或可替换的部分，它实现了一个接口的集合。节点是一个元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。一个构件集合一般来说位于一个节点，但有可能从一个节点转到另一个节点。
|
|
|
|
|
|
行为事物是UML模型的动态部分。它们是模型中的动词，描述了跨越时间和空间的行为。共有两类主要的行为事物：交互（interaction）和状态机（state machine）。
|
|
|
|
交互由在特定语境中共同完成一定任务的一组对象之间交换的消息组成。一个对象群体的行为或单个操作的行为可以用一个交互来描述。交互涉及一些其他元素，包括消息、动作序列（由一个消息所引起的行为）和链（对象间的连接）。在图形上，把一个消息表示为一条有向直线，通常在表示消息的线段上标注操作名，如下图（a）所示。
|
|
|
|
|
|
|
|
状态机描述了一个对象或一个交互在生命期内响应事件所经历的状态序列。单个类或一组类之间协作的行为可以用状态机来描述。一个状态机涉及一些其他元素，包括状态、转换（从一个状态到另一个状态的流）、事件（触发转换的事物）和活动（对一个转换的响应）。在图形上，把状态表示为一个圆角矩形，通常在圆角矩形中含有状态的名称及其子状态，如上图（b）所示。
|
|
|
|
|
|
分组事物是UML模型的组织部分。它们是一些由模型分解成的“盒子”。在所有的分组事物中，最主要的分组事物是包（package）。包是把元素组织成组的机制，这种机制具有多种用图。结构事物、行为事物甚至其他分组事物都可以放进包内。包与构件（仅在运行时存在）不同，它纯粹是概念上的（即它仅在开发时存在）。包的图形化表示如下图所示。
|
|
|
|
|
|
|
|
（4）注释事物（annotational thing）。
|
|
|
|
注释事物是UML模型的解释部分。这些注释事物用来描述、说明和标注模型的任何元素。注解（note）是一种主要的注释事物。注解是一个依附于一个元素或者一组元素之上，对它进行约束或解释的简单符号。注解的图形化表示如下图所示。
|
|
|
|
|
|
|
|
|
|
UML中有四种关系：依赖、关联、泛化和实现。关系的图形表示如下图所示。
|
|
|
|
|
|
|
|
|
|
依赖是两个事物间的语义关系，其中一个事物（独立事物）发生变化会影响另一个事物（依赖事物）的语义。在图形上，把一个依赖画成一条可能有方向的虚线，如上图（a）所示。
|
|
|
|
|
|
关联是一种结构关系，它描述了一组链，链是对象之间的连接，如上图（b）所示。聚集（aggregation）是一种特殊类型的关联，它描述了整体和部分间的结构关系，如上图（c）所示。需要说明的是，在关联上可以标注重复度（multiplicity）和角色（role）。
|
|
|
|
|
|
泛化（generalization）是一种特殊／一般关系，特殊元素（子元素）的对象可替代一般元素（父元素）的对象。用这种方法，子元素共享了父元素的结构和行为。在图形上，把一个泛化关系画成一条带有空心箭头的实线，它指向父元素，如上图（d）所示。
|
|
|
|
|
|
实现是类元之间的语义关系，其中一个类元指定了由另一个类元保证执行的契约。在两种地方要用到实现关系：一种是在接口和实现它们的类或构件之间；另一种是在用例和实现它们的协作之间。在图形上，把一个实现关系画成一条带有空心箭头的虚线，如上图（e）所示。
|
|
|
|
这四种关系是UML模型中可以包含的基本关系事物。它们也有变体，例如，依赖的变体有精化、跟踪、包含和延伸。
|
|
|
|
|
|
图（diagram）是一组元素的图形表示，大多数情况下把图画成顶点（代表事物）和弧（代表关系）的连通图。为了对系统进行可视化，可以从不同的角度画图，这样图是对系统的投影。
|
|
|
|
UML 2.0提供了13种图，它们分别是：类图、对象图、用例图、序列图、通信图、状态图、活动图、构件图、部署图、组合结构图、包图、交互概览图和计时图。下面简单介绍在面向对象方法中较为常用的图。
|
|
|
|
|
|
类图（class diagram）展现了一组对象、接口、协作和它们之间的关系。在面向对象系统的建模中所建立的最常见的图就是类图。类图给出系统的静态设计视图。包含主动类的类图给出了系统的静态进程视图。
|
|
|
|
类图中通常包括下述内容：类；接口；协作；依赖、泛化和关联关系，如下图所示。
|
|
|
|
|
|
|
|
类图中也可以包含注解和约束。类图还可以含有包或子系统，二者都用于把模型元素聚集成更大的组块。
|
|
|
|
类图用于对系统的静态设计视图建模。这种视图主要支持系统的功能需求，即系统要提供给最终用户的服务。当对系统的静态设计视图建模时，通常以下述三种方式之一使用类图。
|
|
|
|
|
|
对系统的词汇建模涉及做出这样的决定：哪些抽象是考虑中的系统的一部分，哪些抽象处于系统边界之外。用类图详细描述这些抽象和它们的职责。
|
|
|
|
|
|
协作是一些共同工作的类、接口和其他元素的群体，该群体提供的一些合作行为强于所有这些元素的行为之和。例如当对分布式系统的事务语义建模时，不能仅仅盯着一个单独的类来推断要发生什么，而要有相互协作的一组类来实现这些语义。用类图对这组类以及它们之间的关系进行可视化和详述。
|
|
|
|
|
|
将模式看作为数据库的概念设计的蓝图。在很多领域中，要在关系数据库或面向对象数据库中存储永久信息。可以用类图对这些数据库的模式建模。
|
|
|
|
|
|
对象图（object diagram）展现了一组对象以及它们之间的关系。对象图描述了在类图中所建立的事物的实例的静态快照。
|
|
|
|
|
|
和类图一样，对象图给出系统的静态设计视图或静态进程视图，但它们是从真实的或原型案例的角度建立的。这种视图主要支持系统的功能需求，即系统应该提供给最终用户的服务。利用对象图可以对静态数据结构建模。
|
|
|
|
当对系统的静态设计视图或静态进程视图建模时，主要是使用对象图对对象结构进行建模。对对象结构建模涉及在给定时刻抓取系统中的对象的快照。对象图表示了交互图表示的动态场景的一个静态画面。可以使用对象图可视化、详述、构造和文档化系统中存在的实例以及它们之间的相互关系。
|
|
|
|
|
|
用例是一种描述系统需求的方法。用例图（use case diagram）展现了一组用例、参与者（Actor）以及它们之间的关系。
|
|
|
|
用例图中通常包含三种元素：用例、参与者、用例之间的关系，如下图所示。
|
|
|
|
|
|
|
|
参与者是指存在于系统外部并与系统进行交互的任何事物，既可以是使用系统的用户，也可以是其他外部系统和设备等外部实体。
|
|
|
|
用例是描述系统的一项功能的一组动作序列，这样的动作序列表示参与者与系统间的交互。
|
|
|
|
用例之间通常存在三种关系：包含（include）、扩展（extend）和泛化（generalization）。
|
|
|
|
（1）包含关系。当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。其中被提取出来的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例。当多个用例需要使用同一段事件流时，抽象成为公共用例，可以避免在多个用例中重复地描述这段事件流，也可以防止这段事件流在不同用例中的描述出现不一致。当需要修改这段公共的需求时，也只要修改一个用例，避免同时修改多个用例而产生的不一致和重复性工作。另外，当某个用例的事件流过于复杂时，为了简化用例的描述，也可以将某一段事件流抽象成为一个被包含的用例。
|
|
|
|
（2）扩展关系。如果一个用例明显地混合了两种或两种以上的场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例。
|
|
|
|
（3）泛化关系。当多个用例共同拥有一种类似的结构和行为时，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。
|
|
|
|
用例图用于对系统的静态用例视图进行建模。这个视图主要支持系统的行为，即该系统在它的周边环境的语境中所提供的外部可见服务。
|
|
|
|
当对系统的静态用例视图建模时，可以用下列两种方式来使用用例图：
|
|
|
|
|
|
对一个系统的语境进行建模，包括围绕整个系统画一条线，并声明有哪些参与者位于系统之外并与系统进行交互。在这里，用例图说明了参与者以及它们所扮演的角色的含义。
|
|
|
|
|
|
对一个系统的需求进行建模，包括说明这个系统应该做什么（从系统外部的一个视点出发），而不考虑系统应该怎样做。在这里，用例图说明了系统想要的行为。通过这种方式，用例图使我们能够把整个系统看作一个黑盒子。你可以观察到系统外部有什么，系统怎样与哪些外部事物相互作用，但却看不到系统内部是如何工作的。
|
|
|
|
|
|
序列图、通信图、交互概览图和计时图均被称为交互图，它们用于对系统的动态方面进行建模。一张交互图显示的是一个交互，由一组对象和它们之间的关系组成。包含它们之间可能传递的消息。序列图是强调消息时间顺序的交互图；通信图则是强调接收和发送消息的对象的结构组织的交互图。
|
|
|
|
交互图用于对一个系统的动态方面建模。在多数情况下，它包括对类、接口、构件和节点的具体的或原型化的实例以及它们之间传递的消息进行建模，所有这些都位于一个表达行为的脚本的语境中。交互图可以单独使用，来可视化、详述、构造和文档化一个特定的对象群体的动态方面，也可以用来对一个用例的特定的控制流进行建模。
|
|
|
|
|
|
|
|
序列图（sequence diagram）是场景（scenario）的图形化表示，描述了以时间顺序组织的对象之间的交互活动。如下图所示，形成序列图时，首先把参加交互的对象放在图的上方，沿X轴方向排列。通常把发起交互的对象放在左边，较下级对象依次放在右边。然后，把这些对象发送和接收的消息沿Y轴方向按时间顺序从上到下放置。这样，就提供了控制流随时间推移的清晰的可视化轨迹。
|
|
|
|
|
|
|
|
|
|
序列图有对象生命线。对象生命线是一条垂直的虚线，表示一个对象在一段时间内存在。在交互图中出现的大多数对象存在于整个交互过程中，所以，这些对象全都排列在图的顶部，其生命线从图的顶部画到图的底部。但对象也可以在交互过程中创建，它们的生命线从接收到构造型为create的消息时开始。对象也可以在交互过程中撤销，它们的生命线在接收到构造型为destroy的消息时结束（并且给出一个大X的标记表明生命的结束）。
|
|
|
|
序列图有控制焦点。控制焦点是一个瘦高的矩形，表示一个对象执行一个动作所经历的时间段，既可以是直接执行，也可以是通过下级过程执行。矩形的顶部表示动作的开始，底部表示动作的结束（可以由一个返回消息来标记）。还可以通过将另一个控制焦点放在它的父控制焦点的右边来显示（由循环、自身操作调用或从另一个对象的回调所引起的）控制焦点的嵌套（其嵌套深度可以任意）。如果想特别精确地表示控制焦点在哪里，也可以在对象的方法被实际执行（并且控制还没传给另一个对象）期间，将那段矩形区域阴影化。
|
|
|
|
|
|
通信图（communication diagram）强调收发消息的对象的结构组织，在早期的版本中也被称作协作图。通信图强调参加交互的对象的组织。产生一张通信图，首先要将参加交互的对象作为图的顶点。然后，把连接这些对象的链表示为图的弧。最后，用对象发送和接收的消息来修饰这些链。这就提供了在协作对象的结构组织的语境中观察控制流的一个清晰的可视化轨迹。
|
|
|
|
|
|
通信图有路径。为了指出一个对象如何与另一个对象链接，你可以在链的末端附上一个路径构造型（如构造型local，表示指定对象对发送者而言是局部的）。通常只需要显式地表示以下几种链的路径：local（局部）、parameter（参数）、global（全局），以及self（自身），但不必表示association（关联）。
|
|
|
|
通信图有顺序号。为表示消息的时间顺序，可以给消息加一个数字前缀（从1号消息开始），在控制流中，每个新消息的顺序号单调增加（如2、3等）。为了显示嵌套，可使用带小数点的号码（1表示第一个消息；1.1表示嵌套在消息1中的第一个消息；1.2表示嵌套在消息1中的第二个消息；等等）。嵌套可为任意深度。还要注意的是，沿同一个链，可以显示许多消息（可能发自不同的方向），并且每个消息都有唯一的一个顺序号。
|
|
|
|
|
|
交互概览图是UML 2.0新增的交互图之一，它描述交互（特别是关注控制流），但是抽象掉了消息和生命线。它使用活动图的表示法。纯粹的交互概览图中所有的活动都是交互发生。另一种新增的、特别适合实时和嵌入式系统建模的交互图称为计时图，计时图关注沿着线性时间轴、生命线内部和生命线之间的条件改变。它描述对象状态随着时间改变的情况，很像示波器，适合分析周期和非周期性任务。
|
|
|
|
|
|
状态图（statechart diagram）展现了一个状态机，它由状态、转换、事件和活动组成。状态图关注系统的动态视图，它对于接口、类和协作的行为建模尤为重要，它强调对象行为的事件顺序。状态图通常包括：简单状态和组合状态、转换（事件和动作）。如下图所示。
|
|
|
|
|
|
|
|
可以用状态图对系统的动态方面建模。这些动态方面可以包括出现在系统体系结构的任何视图中的任何一种对象的按事件排序的行为，这些对象包括类（各主动类）、接口、构件和节点。当对系统、类或用例的动态方面建模时，通常是对反应型对象建模。一个反应型或事件驱动的对象是这样一个对象，其行为通常是由对来自语境外部的事件做出反应来刻画的。反应型对象在接收到一个事件之前通常处于空闲状态。当它接收到一个事件时，它的反应常常依赖于以前的事件。在这个对象对事件做出反应后，它就又变成闲状态，等待下一个事件。对于这种对象，将着眼于对象的稳定状态、能够触发从状态到状态的转换的事件，以及当每个状态改变时所发生的动作。
|
|
|
|
|
|
活动图（activity diagram）是一种特殊的状态图，它展现了在系统内从一个活动到另一个活动的流程。活动图专注于系统的动态视图。它对于系统的功能建模特别重要，并强调对象间的控制流程。
|
|
|
|
|
|
用活动图建模的控制流中，会发生一些事情。你可能要对一个设置属性值或返回一些值的表达式求值。你也可能要调用对象上的操作，发送一个消息给对象，甚至创建或销毁对象，这些可执行的原子计算被称作动作状态，因为它们是该系统的状态，每个原子计算都代表一个动作的执行。动作状态不能被分解。动作状态是原子的，也就是说事件可以发生，但动作状态的工作不能被中断。最后，动作状态的工作所占用的执行时间一般被看作是可忽略的。
|
|
|
|
活动状态能够进一步被分解，它们的活动由其他的活动图表示。活动状态不是原子的，它们可以被中断。并且，一般来说，还要考虑到它需要花费一段时间来完成。可以把一个动作状态看作一个活动状态的特例。类似地，可以把一个活动状态看作一个组合，它的控制流由其他的活动状态和动作状态组成。
|
|
|
|
|
|
当对一个系统的动态方面建模时，通常有两种使用活动图的方式：
|
|
|
|
（1）对工作流建模。此时所关注的是与系统进行协作的参与者所观察到的活动。工作流常常位于软件系统的边缘，用于可视化、详述、构造和文档化开发系统所涉及的业务过程。在活动图的这种用法中，对对象流的建模是特别重要的。
|
|
|
|
（2）对操作建模。此时是把活动图作为流程图使用，对一个计算的细节部分建模。在活动图的这种用法中，对分文、分叉和汇合状态的建模是特别重要的。用于这种方式的活动图语境包括该操作的参数和它的局部对象。
|
|
|
|
|
|
构件图（component diagram）展现了一组构件之间的组织和依赖。构件图专注于系统的静态实现视图。它与类图相关，通常把构件映射为一个或多个类、接口或协作。
|
|
|
|
|
|
部署图（deployment diagram）展现了运行处理节点以及其中的构件的配置。部署图给出了体系结构的静态实施视图。它与构件图相关，通常一个节点包含一个或多个构件。
|
|
|
|
|
|
同其他分析方法一样，面向对象分析（Object-Oriented Analysis，OOA）的目的是获得对应用问题的理解。理解的目的是确定系统的功能、性能要求。面向对象分析法与功能／数据分析法之间的差别是前期的表述含义不同。功能／数据分析法分开考虑系统的功能要求和数据及其结构，面向对象分析方法是将数据和功能结合在一起作为一个综合对象来考虑。面向对象分析技术可以将系统的行为和信息间的关系表示为迭代构造特征。
|
|
|
|
面向对象分析包含5个活动：认定对象、组织对象、描述对象间的相互作用、定义对象的操作、定义对象的内部信息。
|
|
|
|
|
|
在应用领域中，按自然存在的实体确立对象。在定义域中，首先将自然存在的“名词”作为一个对象，这通常是研究问题、定义域实体的良好开始。通过实体间的关系寻找对象常常没有问题，而困难在于寻找（选择）系统关心的实质性对象，实质性对象是系统稳定性的基础。例如在银行应用系统中，实质性对象应包含客户账务、清算等，而门卫值班表不是实质性对象，甚至可不包含在该系统中。
|
|
|
|
|
|
分析对象间的关系，将相关对象抽象成类，其目的是简化关联对象，利用类的继承性建立具有继承性层次的类结构。抽象类时可从对象间的操作或一个对象是另一个对象的一部分来考虑，如房子由门和窗构成，门和窗是房子类的子类。由对象抽象类，通过相关类的继承构造类层次，所以说系统的行为和信息间的分析过程是一种迭代表征过程。
|
|
|
|
|
|
描述出各对象在应用系统中的关系。如一个对象是另一个对象的一部分，一个对象与其他对象间的通信关系等。这样可以完整地描述每个对象的环境，由一个对象解释另一个对象，以及一个对象如何生成另一个对象，最后得到对象的界面描述。
|
|
|
|
|
|
当考虑对象的界面时，自然要考虑对象的操作。其操作有从对象直接标识的简单操作，如创建、增加、删除等；也有更复杂的操作，如将几个对象的信息连接起来。一般而言，避免对象太复杂比较好，当连接的对象太复杂时，可将其标识为新对象。当确定了对象的操作后，再定义对象的内部，对象内部定义包括其内部数据信息、信息存储方法，继承关系以及可能生成的实例数等属性。
|
|
|
|
分析阶段最重要的是理解问题域的概念，其结果将影响整个工作。经验表明，从应用定义域概念标识对象是非常合理的，完成上述工作后写出规范文档，文档确定每个对象的范围。
|
|
|
|
早期面向对象的目标之一是简化模型与问题域之间的语义差距。事实上，面向对象分析的基础是软件系统结构，这依赖于人类看待现实世界的方法。当人们理解求解问题的环境时，常采用对象、分类法和层次性这类术语。面向对象分析与功能／数据分析方法相比，面向对象的结果比较容易理解和管理。面向对象分析方法的另一个优点是便于修改，早期阶段的修改容易提高软件的可靠性。
|
|
|
