2011-09-08

1、OOA和OOD

OOA：分析阶段所作的主要工作是理解问题和需求建模，将现实世界中的问题映射到问题域。在该阶段，要明确用户提出了哪些功能需求，为完成这些需求，系统应该有哪些构件（Component），采用什么样的结构（Structure），并写出详细的需求规约。OOA中引入了许多面向对象的概念和原则，如，对象、属性、服务、继承、封装等，并利用这些概念和原则来分析、认识和理解客观世界，将客观世界中的实体抽象为问题中的对象，即问题对象，分析客观世界中问题的结构（issue structure），明确为完成系统功能，对象间应具有的联系和相互作用。因此下面的问题是OOA阶段必须回答的：

1）为完成用户要求，系统应提供哪些功能？

2）系统应有哪些对象构成？

3）每个对象应有哪些属性和服务？

4｝对象间应有怎样的联系？

要回答这些问题，就需要从静态和动态两方面来认识、分析现实世界对象。具体来说，要进行：

1）个体特征分析：标识对象及其属性和服务。有的方法在标识特征时对属性的要求可能弱一些，这是因为对象是属性和操作的封装体，对象的访问可以通过接口——操作来实现。这样在标识对象时对象内部特征可暂时不考虑，仅考察外部行为。每种分析方法在完成这些工作时各具特色，如R.Abbott认为，可以通过分析非形式化英语的问题描述，将名词标识作为对象，将形容词标识为属性，将动词标识为服务；也可以采用结构化与面向对象技术相结合的方法。

2）静态分析：分析和描述系统的静态结构。一般的（In general），对象系统中的类或对象之间存在两种关系：一般——特殊关系（继承）和整体——部分关系（关联）。系统静态分析主要是分析、识别对象或超类间的一般——特殊结构，并添加一些必要的类，构造继承关系。

3）动态分析：分析对象及对象之间的行为及控制关系，建立系统的动态模型。多数分析方法要求进行这方面的工作，有的则将它放到设计阶段去完成，这主要由OOA、OOD阶段划分的不同所造成的。动态模型一般由一组状态转化图构成，从这组状态状态转换图可以映射到对象模型。系统的动态模型从对象行为的角度规划了系统的功能，方便从OOA到OOD的过渡。有的方法虽然未提供动态模型，但也提供了表示对象行为的类似方法。早期的OOA方法对建立系统动态模块认识不足，这主要是因为当时许多方法是受数据模型的启发而产生的。现在越来越多的人认识到了系统动态分析工作的重要性，并在分析方法中引入了相应的概念。除此之外，许多OOA方法还引入了问题复杂性控制机制。如Coad&Yourdon在其方法中引入了主题的概念；Wirfs&Brock在其方法中引入了子系统的概念。问题复杂性控制机制主要针对大型复杂系统，它将一组对象或类抽象成新的系统构件，以达到简化问题空间的目的。这样，分析和设计人员就可以从宏观与微观、整体与局部等不同角度分析问题，便于透彻地认识和理解问题。

OOD方法；

分析阶段主要是明确用户的功能需求，及满足用户所需的系统部件及其结构。设计阶段则主要是确定实现用户需求的方法，即怎样做才能满足用户的需求，并构造出系统的实现蓝图。OO设计也是如此，只不过引入了一些面向对象的概念和原则，用以指导设计工作。OOD首先从OOA的结果开始，并将其从问题域映射到实现域；为满足实现的需求，还要增加一些类、结构及属性和服务，并对原有类及属性进行调整。此外，还要完成应用控制、人机交互界面的设计等。在现有的方法中，Coad等人的OOD就是比较全面的设计方法。OOD主要工作有：

1）问题域部分的设计：

问题域部分的设计是任何OOD方法都必须完成的工作，它主要是对OOA结果进行改进和精化，并将其由问题域转化到解域，具体来说有以下几个方面：

a.属性：有些属性在分析阶段有助于问题的理解，而到了设计阶段则可以由其他属性导出或根本没有必要保留。因此，应将它们去掉。相反的，为了实现服务算法还需要增加相应的一些属性（优化解）；

b.服务：OOA只给出了服务的接口，其具体实现算法要在OOD阶段完成；

c.类及对象：在OOA阶段有助于问题理解的一些类在OOD阶段成为冗余，需要删除，而为了优化调整继承关系还需要增加一些类。所有的类都确定以后还要明确哪些类的对象会引发哪些类创建新对象（关联、依赖）；

d.结构：对类同结构进行优化调整；

e.对象行为：明确对象间消息传递的实现算法，依据动态模型确定对象间消息间发送的先后顺序，并设计相应的算法，协调对象行为。

2）人机交互与应用控制部分的设计：

有些设计方法并没有提到交互界面的设计，一方面是因为这些系统中交互界面不十分重要；另一方面是因为这部分的设计很有规律，设计方法也比较成熟。。。主要工作包括：

a.交互界面子系统的设计：与界面有关的类及类间结构的设计，以及有关算法的设计；

b.交互界面子系统和应用之间的接口设计；

c.应用控制部分的设计：这部分对象主要完成应用的驱动工作。这部分对象不同于从现实世界中抽象出来的时候，在现实世界和问题域中没有原型，它们同界面子系统中的对象及问题对象发生作用，控制系统的运行。

区别：

1）OOA将现实世界中的实体抽象为问题对象，并构造问题域中的系统需求模型；OOD将问题对象转化为解域中的类并在解域中构造出问题的解；

2）OOA侧重于用户需求的分析和对问题域的理解，分析人员关心的是系统结构及对象间的关系；OOD则侧重于系统的实现，设计人员关心的是对象的行为及其实现；

3）OOA标识了一组对象，并通过其相互作用来刻画系统，该阶段的工作与程序设计语言无关；OOD定义了一组类，并设计出系统的实现蓝图，概要设计与程序设计语言无关，但详细设计则与之有比较密切的联系；

4）OOA识别的对象是对客观世界实体的抽象，标识对象的准则是：该对象的引入是否有助于对问题域的理解；OOD中构造类的准则是：该类的构造是否可行，是否有效地实现了抽象数据类型，是否有助于系统的实现和提高软件质量；

5）两个阶段都没有提及系统对象，但原因不同。在OOA阶段，分析与实现无关，分析所涉及的范围与解域无关，系统对象自然不用考虑。OOD建立的对象模型本身就是要设计的软件系统，对系统对象的考虑是隐含的；

6）组装结构和分类结构在两个阶段所起的作用不同。在OOA阶段，它们的引入主要是为了理解问题；而在OOD阶段，它们的引入则主要是针对软件的构造和实现。分类结构通过继承机制来实现，因而代码得到了有效地复用；组装结构则将一些类组合在一起构成较大的软件构件（Component）；

7）OOA并没有考虑对象产生的问题，当其对应的实体在现实世界中出现时，它也就在问题域中产生了。OOA也不考虑对象属性的取值和服务算法的实现。而在OOD阶段这些问题都必须详细考虑；

8）OOD涉及到重载问题；而OOA没有考虑，因为考虑过多的实现细节对理解问题和分析用户需求没有多大帮助。

OOA：侧重点是业务领域分析，与软件所要应用的行业领域相关，而与软件技术关系不大，需要由领域专家进行。即所谓的“需求分析”。

OOA成果：

1）业务领域用例图

2）活动图

3）协作图

4）大量的业务文档资料

OOD：用面向对象的方法为真实世界建立一个计算机中的虚拟模型

OOD的地位：

1）OOD的主要任务是跨越业务领域模型与可实际运行的软件系统之间的鸿沟；

2）OOD的难度是非常大的，负责OOD工作的人被称为系统架构设计师；

系统架构设计师的任务

1）确定系统的总体框架——大多采用已有的领域框架；

2）正确理解需求分析得出的领域模型，用面向对象的思想设计出软件体系结构——系统概要设计

3）分析现实的可获取的技术资源，分解出软件的各个组件，安排好开发任务流程——系统详细设计

OOD的成果：

1）系统中有多少个类？

2）系统中这些类间有什么关系（系统静态特性）？

3）系统中这些类生成的对象如何协作来完成工作（系统动态特性）？

4）系统中如何管理这些类和对象？

 

2、类图（Class Diagram）与对象图（Object Diagram）

1）类图：描述类、接口、协作以及它们之间关系的图，用来显示系统中各个类的静态结构。

a.类图是定义其他图的基础，在此基础上，可以使用状态图，协作图、组件图和配置图等进一步描述系统其他方面的特性；

b.类图包括7个元素：类、接口、协作、依赖关系、泛化关系、关联关系以及实现关系。

2）对象图：描述参与交互的各个对象在交互过程中某一时刻的状态。对象图可以被看作是UML类图在某一时刻的实例；在UML中，对象图使用的是与UML类图相同的符号和关系，因为对象就是类的实例。