其他面向对象的方法.docx
《其他面向对象的方法.docx》由会员分享，可在线阅读，更多相关《其他面向对象的方法.docx（19页珍藏版）》请在冰豆网上搜索。
其他面向对象的方法
其他面向对象的方法
目录
1、引言1
2、面向对象方法总结3
3、面向对象分析（OOA/Coad-Yourdon）5
3.1架构5
3.2方法6
3.3交付7
3.4讨论7
4、面向对象设计（OOD/Booch）9
4.1架构9
4.2方法10
4.3交付11
4.4讨论12
5、分层面向对象的设计（HOOD）13
5.1架构13
5.2方法14
5.3可交付成果15
5.4讨论16
6、总结17
1、引言
今天用于工业的大部分方法,对于信息技术系统的开发,都是基于功能和/或数据驱动系统的分解。
这些方法和用于数据和功能集成的面向对象的方法在很多方面都不相同。
在第四章我们会用一个函数/数据的方法讨论这个问题。
我们会讨论将功能/数据方法与面向对象方法相结合应用于同一个开发周期；看一下病房的实例（1989）。
在OOPSLA`90上关于这个话题小组讨论会（见OOPSLA（1990））的结论是，应避免任何这样的组合。
在一般情况下，我们同意这个看法。
然而，一些在功能/数据方法中使用的图表技术也可用于面向对象的方法中。
其中的一个例子是可用于模型对象的状态转换图。
正如我们在第4章所讨论的那样，当从一个角度转换成另一种的时候范式就会发生转变。
这样的范式转变是非常复杂的，一般应避免。
在本章中，我们将讨论一些其他面向对象开发方法的概述。
我们不要求完整性。
所有的方法针对建模系统按照对象将形成系统实现的基础。
所有对象建模技术的核心问题是要找到一个合适的对象结构。
很难在一个系统的比较中对所有方法都很公平正义。
有很多方面需要比较，而且真正的比较应该涉及平等成员的并行项目并且在相同的条件下进行。
真正有趣的是该方法的对比研究有助于实现一个从质量,生产力,修改能力等等而言更美好、更有竞争力的产品。
更容易比较的是符号，概念和容易定义的策略；大多数比较都是在这个层面上的，包括这一个。
我们只能提供一些特别的评价方法。
这里讨论的技术都是我们在第2章中定义的方法，他们都是一步一步的过程，虽然我们还没有在这本书中实质的讨论它,但是对象导向法专注于产品生命周期,而不是只在项目。
因此，实际过程的描述方面，我们专注的对象导向法过程如何改变产品在其生命周期的活动连接到这些变化。
因此，必须大规模工业化。
比较方法与过程在我们看来就是比较工业过程与工艺。
例如，汽车制造工业的工匠汽车开发的具有完全不同的方法。
如果我们只把方向盘上，都将在汽车座位比较的事实，我们已经错过了这一点。
然后，我们不明白的汽车在属性上的进程，一方面和其他工匠的区别。
因此，性能以外概念是最重要的。
至于方法，我们在这一章强调,在面向对象软件工程（OOSE）和这些方法有一些基本的差异。
在这里我们强调一些：
1）使用三个对象类型的分析模型,帮助得到一个健壮的结构,这就是我们所说的鲁棒性分析,是独一无二的。
这里讨论的方法都使用不同的对象类型来帮助系统的鲁棒性。
一些方法使用几个对象类型,但它们并不是主要为了找到实际的系统结构。
2）方法的规范化：
在面向对象软件工程（OOSE）里面我们开发的不同模型是相关的。
我们的经验表明,不同的模型都需要不同的目的,不同的模型都需要与客户讨论需求,为了让设计师使用,并且测试。
系统模型也是需要的，为了保持它。
有所有在配置管理和版本控制。
其他的方法在本章中讨论的只有一个模型一起工作,或者在某些情况下,有不同的看法相同的模型。
3）需要一个用例的概念：
用例的概念是OOSE（面线对象软件工程）的核心。
它可用于许多不同的目的。
如果不是更早的，需要这样的概念是当被测试的系统，或当要写入的手册。
这里讨论的一些方法已经开始看到需要一个用例的概念，但都没有像OOSE一样的正式清楚。
4）过程和方法的区别：
适当的方法如何适应一个更大的组织和可伸缩性的方法是重要的。
没有其他的方法描述这里声称有一个支持过程。
5）形式化程度：
软件工程还不是很正规,但有一个清晰的程度的区别,这里讨论的方法形式化。
形式化的概念是必要的,特别是开发案例支持,是一个多文档工具,例如一致性控制、动态和自动关系模型,自动生成信息或“智能”的支持。
大多数比较方法比较只有概念和符号,因此不包括上面的一些点。
有些方法还给出比较实际的建议和规则。
在本章中，我们也限制我们的讨论最简单的水平，即讨论有关如何使用该方法的概念和想法。
在这一章我们也限制我们的讨论到最简单的水平,即一个讨论的概念和想法怎样处理方法。
如上所述,然而,我们认为,“工业性”的方法是最重要的考虑因素在选择方法对于一个工业组织。
用于学术用途,然而,概念方面可能是最有趣的。
首先，我们将给出一个非常简短的介绍一些面向对象的方法，然后我们将专注于他们中的一些。
本概述的基础是公开的。
我们所使用的引用可能延伸的方法可能存在的旧的和新的材料。
此外，还有一些其他的方法确实存在。
2、面向对象方法总结
大约有几种面向对象开发方法。
它们有一些在教科书有大量的关注而其他只是在文章里被描述。
还有一些是内部发展,只有在组织中使用。
我们知道的几个不同的面向对象方法不容易进行公共使用。
它是自然期待这种方法的数量会增加，因为当前大部分兴趣在面向对象技术。
许多早期的尝试是基于对象的方法，也就是支持的对象，但是不支持继承或类。
一个早期的先锋是GradyBooch（1983），其早期方法是基于修道院院长的想法（1983）和经过几个步骤的演变（参见Booch（1986,1987））到他的最后版本,面向对象设计（OOD）（见Booch（1991））。
该方法已经不断发展，并且在最新版本里早期版本会被批评,因为“它肯定不能很好的扩展到任何超出相当琐碎的问题”（见Booch（1991））。
之后我们将更深入地讨论OOD。
其他早期的尝试中，包括Shlaer和Mellor所合著的《面向对象的系统分析（OOSA）》（1988）。
这本质上是基于数据建模的信息分析。
OOSA未能捕获行为和不包含继承或分类。
相反,重点是描述对象之间的关系。
鲁博（Rumbaugh）等人的《对象建模技术（OMT）》（1991）（Loomis,Shah和Rumbaugh（1987）提出的早期草稿）是基于实体/关系模型扩展建模类，继承和行为。
这项技术已经被Blaha,Premerlani和Rumbaugh扩展（1988）,专注于关系数据库的设计,之后我们将会更深入的讨论这个方法。
由彼得·科德和EdYourdon所写的《面向对象分析（OOA）》（1991a）是一种循序渐进的方法,开发面向对象的系统模型。
之后会对面向对象分析有更详细的讨论。
一个设计方法也紧随着分析方法之后公布（见彼得·科德和Yourdon（1991b））。
分层面向对象的设计（HOOD）（见HOOD（1989a,b）），初步发展为欧洲航天局（ESA）的一个财团组成的计算机信息系统集成资质管理ingeniere，CRIA/S公司和马特拉空间。
它得到了引擎盖工作组的进一步开发。
HOOD已选定由欧空局的建筑设计项目，如哥伦布和爱马仕，那就是大型实时系统的设计方法。
HOOD假设该软件将使用Ada编码。
HOOD将在后面更详细讨论。
瑟曼等的《面向对象的结构化设计（OOSD）》（1989,1990）。
其实只是一个符号，是一个扩展为Ada包的结构设计和Booch的符号技术用于结构图。
OOSD不包括它自己的方法，因此设计师们预计开发和利用自己的技术。
夫斯波尔克等的《责任驱动设计》（1990）是一种在类，他们的责任和合作方面的应用程序建模中。
最初识别系统的对象和类。
该系统的责任进行了分析和分配系统类。
最后，类之间的合作对象必须发生在履行职责的定义。
这给出了一个初步设计，这是进一步探索通过层次结构，子系统和协议。
该方法采用CRC（类，职责和协作）卡贝克和坎宁安（1989）所描述的。
我们在后面将更深入讨论这种方法。
Reenskaug等提出的《面向对象的角色分析、合成和构建方法（OORASS）》（夫斯波尔克和约翰逊（1990））所描述的涉及几个步骤，在系统开发周期。
分析侧重于系统中的对象所扮演的不同角色。
合成定义了新的对象，从几个简单的继承行为。
结构采用了元模型指定对象可以绑定到对方在系统实例。
其他，或多或少完全制定出基于面向对象的思想，这些方法包括Embley等介绍的《面向对象的系统分析》（OOSA）（1992），由Goldberg和鲁宾写的《对象行为分析（OBA）》（1992年）与培基-琼斯和Weiss（1989）和布尔（1991）的《合成》。
现在，我们将讨论一些这些方法的细节。
我们将集中讨论的方法是：
●面向对象的分析（OOA），Coad和Yourdon著
●面向对象设计（OOD），Booch著
●分层面向对象的设计（HOOD）
●对象建模技术（OMT）
●责任驱动设计
对于这些方法，我们将讨论的架构、方法和成果，同时我们也以OOSE标准来比较方法。
我们将在OOSE中专注于不同的属性。
需要注意的是比较只是近似的，很多关系不明确。
然后，我们已经选择了接近OOSE的一个概念，它是还用括号的关系不明确的。
在图1中，我们试图比较什么样的阶段相比，这些方法覆盖OOSE。
请注意，这样的比较阶段隐藏了很多重要方面。
例如，在需求分析阶段，讨论的方法，这里只使用域对象模型和没有用例模型，这是中央在OOSE。
一种方法，该深度也相当大的变化。
只提供一些方法描述阶段的工具。
这个方法的野心也很大，我们将一些下面这些问题上发表意见。
图1：
OOSE与本章中讨论的方法有关的活动
3、面向对象分析（OOA/Coad-Yourdon）
3.1架构
在面向对象分析的分析模型来描述该系统的功能。
在表1中我们将面向对象分析相关的一些概念用于面向对象软件工程。
科德和Yourdon的设计理念是扩展这个模型对于进程（任务），人机界面和DBMS问题。
我们不考虑设计技术，在这里是值得进一步讨论。
类和对象术语的引入意味着该类别中的类和对象。
在面线对象软件工程中“对象”这个词有时候用来表示一个类或者一个类的特定实例。
从每次出现的上下文中它的意思应该是显而易见的。
此外，看我们的绘制对象的视图，这通常意味着这个类和它的所有实例都在里面，我们要区分开类的组块（用虚线）和接口组块（用实线）。
这是绘制一个视图而不是三个，否则可以简单的将面向对象的概念映射到面向对象软件工程。
术语学科意思是一个模型中用来帮助和引导读者的一个特定的类和对象的分组。
没有面向对象软件工程直接的对应，相反，我们用不同的视图来达到这个目的。
术语也可以用来作为面线对象软件工程的子系统，但是这是在不正常的情况下，因为术语可能重复，术语不能被视为正式的子系统。
表1：
面向对象分析（OOA）中与面线对象软件工程（OOSE）相关的概念
面向对象分析面线对象软件工程
类类
对象接口
类和对象（对象）
根规格结构继承
整体-部分结构下设
实例连接熟人
信息刺激
信息连接沟通
属性属性
服务操作
主题视图，（子系统）
3.2方法
面向对象分析实验基本结构原理并加入面向对象角度的视图。
该方法由五个步骤组成；建议采用一下顺序来执行：
（1）寻找类和对象
（2）识别结构
（3）定义主题
（4）定义属性
（5）定义服务
寻找类和对象：
指定类和对象如何被发现。
第一种方法是由应用领域的启动给出并确定形成整个应用程序的基础类和对象，在这种情况下，系统在这一领域的责任是分析。
调查系统环境可能产生进一步的系统应该知道的类和对象。
笔记是需要保存的信息关于每个对象,每个对象都必须提供什么行为。
定义结构主要有两个不同的方式完成。
第一，泛化和专门化（创规范）结构，抓住了在确定类的继承层次结构。
其他的结构，如整体-部分结构，是用来模拟一个对象如何成为另一个对象的一部分和对象如何组合成较大类别。
定义主题是通过将类和对象模型分割成较大的单元来完成的。
主题是一组类及对象。
每个科目的大小选择，以帮助读者了解该系统通过模型。
这是适当使用先前定义科目确定的结构。
例如，可以分组为一个主体一个根规格结构。
当指导读者有用时，主题可能会重叠。
定义属性是通过识别信息和协会完成的,还应该与每个实例相关联。
为每一个对象,你确定需要的属性来形容它。
所确定的属性被放置在正确的级别的继承层次结构。
任何实例连接也被检查之前的面向对象分析结果或通过映射问题域的关系。
这个属性指定的名称和描述。
任何特殊限制属性也指定了。
定义服务是指定义类的操作。
这是通过确定对象状态和定义服务，如创建，访问，连接，计算，监控外部系统等。
如何使用消息的连接，这是类似的通信协会OOSE识别的对象进行通信的消息。
这些是用来指定每个操作。
这里的线程的执行，作为一种技术，后续的消息序列。
最后，服务的指定的一个图形化的书写方式的流程图类似。
3.3交付
面向对象分析方法的结果是在一个特殊的图形符号记录（见图2）和特殊的模板文本文档的类和对象。
该模型提出了一种自上而下的方式按下列顺序:
●主题层（唯一主体）。
●类和对象层（类对象和科目）。
●结构层（结构被添加到上一层）。
●属性层（属性被添加到上一层）。
●服务层（服务被添加到上一层）。
3.4讨论
面向对象分析本质上是一种面向对象的方法和概念，如类，实例，继承，封装和对象之间的沟通是必不可少的成分。
类和对象的概念被引入，是为了避免有时会出现的不清楚的类和对象的组合而导致的含糊不清。
图2中OOA的图形符号被应用到前面所说的回收系统而作为其中的一部分。
寻找对象的技术非常启发式。
目前缺乏一个独特的方法，遵循循序渐进，以确定类与对象系统。
OOA是专为小型系统而设计的，即使今天它甚至被大型系统所使用。
发现当使用面线对象软件工程时使用面向对象分析似乎是最初的问题域对象。
在方法中没有解决当系统分析的时候的表示用户界面的接口；这是由设计部分负责的。
也没有任何具体的支持系统捕捉到的所有动态对象（在OOSE中比较使用情况）所扮演的角色的方法。
线程的执行是一种方法，但这样做是对于验证已经确定了正确的操作有些晚了。
在这里，用例和交互图可以作为支持工具。
在较大的系统中需要巨大的努力由一个特设的战略来捕捉对象总界面。
根据我们的经验，很难准确定义哪个对象在一个特定的系统中是必不可少而无需通过的，详细的系统是如何被使用的。
例如，在一个登记系统中，它可能是必要的跟踪航空器驾驶员，但有另一种可能是与这个信息完全无关。
同时，我们认为，确定一个不知道怎么被使用对象应该具有的属性关系是很困难的事情。
因此，在操作被定义之后（或同时）给属性和关系建模是很自然的事情。
否则，结果将是你会发现很多最初的属性因为不会被使用而必须在最后时刻被移除。
主题的概念跟OOSE中使用的视图或者子系统有点类似。
然而，子系统是一个配置单元和一个大型系统的管理方式。
特别是，OOSE中使用的服务包也被用来改变本地系统。
系统中的一个功能的改变只影响一个服务包。
这不是OOA中主题的意图，它们更多的是系统模型读者的一个引导。
此外，主题可能会重叠，而这不是OOSE子系统中的情况。
OOSE中的视图是被用来将模型分割成不同的角度来引导读者。
在表2中，我们将OOSE中的概念关联到OOA。
表2OOSE中与OOA相关的概念
OOSEOOA
类类
对象对象
继承根规格结构
熟知实例连接/整体-部分
交互消息连接
刺激消息
操作服务
属性属性
用户（用户）
用例（执行线程）
子系统（主题）
服务包-
块-
对象模块-
公共对象模块-
4、面向对象设计（OOD/Booch）
4.1架构
虽然OOD/Booch的方法跟OOA/Coad-Yourdon的方法在寻找对象的时候有很多类似之处，但是OOD的目的是为执行建立一个基础。
在表3中我们总结了OOD中与OOSE相对应的概念。
OOD中使用的概念和技术也很多，我们在这里只提到比较重要的方面。
Booch给出了大量的概念，但是建议只有在适当的时候使用其中的一些。
有趣的是要注意关系使用和类之间实例化的绘制，也就是说，这是系统的一个静态视图。
在动态对象直接只有唯一的线，对象之间的信息发送会附加到这些线。
这项使用元类的技术并没有在OOD中被描述出来。
一个元类是一个特定类的类。
在OOSE中，这些只被人们用来定义方法的架构，因此通常不直接提供给从业者方法。
Booch也专注于不同阶段的接口，他使用多种分组概念的不同种类的可见性。
类的分类是以介绍和抽象为目的的一组类，在OOA中与主题非常相似。
在模块中使用到了物理分组。
在OOSE中我们使用块来达到同样的目的和用于引导读者的视图。
机制这个概念的引入是作为“对象集的结构，是协同工作以提供满足问题需求的行为”。
目前尚不清楚这究竟是什么意思，但是这个想法跟用例有一些相似。
然而，似乎更多的是在类可以合作的地方的类的一种框架，类似于为了RDBMS专业化而在本书中提出的骨架。
表3OOSE与OOA中相关的概念
OODOOSE
类类
对象实例/对象
用途（通信）
实例（通信）
继承继承
元类（仅被方法论使用）
类的分类（块）
消息刺激
字段属性
操作操作
机制（用例/框架）
模块块
子系统子系统
进程进程
4.2方法
Booch强烈强调在面向对象设计中迭代过程和开发者的创造力是至关重要的组成部分。
该方法是关于这个创意过程的一组启发式和良好的建议。
没有严格的基线或工作秩序存在，但“OOD的过程一般按照下列事件的顺序进行”：
●在一个给定的抽象层次上识别类和对象。
●识别这些类和对象的语义。
●识别这些类和对象之间的关系。
●实现这些类和对象。
这个过程是递归的，并且Booch还指出：
“面向对象设计的过程从来自于我们问题域词汇表的类和对象开始；当我们发现没有新的原始抽象和机制，或者当我们已经发现的类和对象可以通过从现有的可重用软件组件来组成从而被实施的时候它就会停止。
”（Booch（1991））。
识别类和对象包括寻找在问题空间中关键抽象和提供几个这样的对象的动态行为的重要机制。
这些关键抽象是通过问题域里的术语学习发现的。
这可能经由与领域专家交谈来实现。
识别语义涉及建立先前确定的类和对象的含义。
开发人员应该从外面查看对象和对象定义协议。
要研究如何使每个对象可用于其他对象也是确定其语义的一个重要组成部分。
这被描述为面向对象的坚硬部分，可能最需要的迭代。
识别关系涉及扩展之前的活动,包括类和对象之间的关系,来确定如何相互配合。
不同协会的类型正在被使用,如实例化和类之间的使用。
静态和动态的语义对象之间的机制也要被定义。
类和对象之间的可见性是由以上所决定。
这一步也在设计过程中产生的迭代。
实现类和对象涉及深入的类和对象，并确定如何实现它们。
决定如何使用特定的编程语言来实现的类。
这也是使用组件的步骤。
类和对象被构造在模块里。
这种构造是如何做的在Booch（1991）中不是很清楚。
此步骤可能会导致再次执行的整个过程的地步，但现在只在一个特定的类，并在一个较低的水平。
因此，我们可以类或模块的层次结构。
这似乎导致类似的HOOD（见下文）为每个类或对象的分层结构。
4.3交付
OOD的主要力量或许是提供给开发人员的丰富的图表技术（是不是太丰富了？
）。
通过从不同的角度查看模型，提出了一套丰富的观点，表达了不同的关于这个模型的东西。
这些角度概括于图3。
首先，逻辑和物理视图之间进行了分离。
逻辑视图里包含类结构和对象结构。
物理视图包括系统模型和进程结构。
所有这些图形成了OOD方法里的基本书写方式，这是一个系统的静态描述。
除了这些静态图，Booch还使用两个动态图。
第一个是描述某个类的实例语义的状态转换图。
第二个是描述对象之间如何发生事件的时序图。
图3OOD文档方面视图
4.4讨论
该方法不是真正发展成一个过程,而是一系列技术和启发式方法,可以用于在开发面向对象的系统。
OOD确实提供,不过,一个丰富的图表绘制技术,虽然一个互补的规则之外的文档是必要的;这是一个活动项目或组织可以自行开发。
有一些相似的符号技术被应用在OOSE。
例如,在OOSE中时序图与交互图有一个类似目的,但尚未正式开发。
状态转移图是描述使用传统符号（粉状的图）,而OOSE可能使用不同的符号,在这本书里一个表示法SDL描述相似。
描述的操作在纯文本或在（伪）代码中。
面向对象分析的讨论，在某些部分在这里也适用。
面向对象设计似乎是被视作一个由外到内的方法，从外部开始和精炼，直到它可以实现的组件和代码的每一个类和实例。
因此，它是一种分而治之的方法。
伟大的缺乏，只要我们可以看到，找出每个对象和类的操作技术。
这种实际工作中必须做到的是给开发商。
面向对象分析，使用的情况下的概念可以用面向对象技术一起使用。
在表4中，我们列出了OOSE中与OOD相关的概念。
表4OOSE相关的面向对象设计的概念
OOSEOOD
类类
对象对象
继承继承
熟人（使用关系）
通讯（使用/实例关系）
刺激消息
操作操作
属性字段
用户-
用例（~机制）
子系统类的类别/子系统
服务包-
块模块/类的类别
对象模块类
公共对象模块（类的能见度的类别）
5、分层面向对象的设计（HOOD）
5.1架构
HOOD逐步细化的开发一个模型，然后可以目标语言中直接实现。
在表5中，我们将HOOD中与OOSE相关概念总结出来了。
在HOOD中使用的概念是未来支持一个指向Ada语言的设计和实施的抽象视图。
这也说明了基于对象的方法也就是缺乏继承和纯类。
这些对象会被分类去支持设计者。
活动对象可以并行执行，而被动对象只能在一定的水平按顺序执行。
环境中的对象代表与该特定系统必须与之交互的其他系统。
类对象用于某些类型的不完全描述，即包仿制指定对象。
虚拟模式对象代表在分布式系统中的一个节点。
控制流是用来显示不同的对象，如何在一个特定的水平沟通。
使用不同种类的对象之间的关系。
表5HOOD中与OOSE相关的概念
HOODOOSE
类类
活动对象封装过程块
被动对象不直接封装过程块
环境对象指定接口用户
类对象（同意虚拟对象）
虚拟节点对象-
控制流（用例）
使用关系通信
包含关系下设的
操作操作
5.2方法
HOOD在Ada中是面向编码的，但是也已经被扩展成为支持C++的编码了。
这意味着HOOD里的概念都有了Ada语义，比如，不支持继承。
这种方法是以整个系统的一个对象
升级会员 