[译]OOSE第4章：面向对象系统的研发 4.2 功能/数据方法Function/data methods

4.2 功能/数据方法
The existing methods for system development can basically be divided into function/data methods and object-oriented methods. By function/data methods we mean those methods that treat functions and/or data as being more or less separate. Object-oriented methods view functions and data as highly integrated. These paradigms are shown schematically in Figure 4.5. Most traditional software engineering methods are function/data methods, for example, SADT (Structured Analysis and Design Technique), see Ross (1985), RDD (Requirement Driven Design based on SREM), see Alford (1985), and SA/SD (Structured Analysis and Structured Design), see Yourdon and Constantine (1979) and Yourdon (1989).
现存的IT系统开发的方法可以从本质上来讲划分为两类,一类是功能/数据方法(function/data methods),和面向对象的设计方法.关于功能/数据方法设计的核心思想是把功能和数据或多或少看成两个相对分离的部分.而面向对象的方法把功能和数据看成是一个高度耦合的整体,关于F/D方法和OO方法的变化形式见图4.5所显示,.绝大部分传统的软件工程方法是基于F/D方法的,举个案例来说,SADT方法(结构化的分析和设计方法),RDD方法(基于SREM的需求驱动设计方法),以及SA/SD(结构化分析/结构化设计方法)
Function/data methods thus distinguish between functions and data, where functions, in principle, are active and have behavior, and data is a passive holder of information which is affected by functions. The system is typically broken down into functions, whereas data is sent between those functions.
F/D方法(功能数据方法)需要明确的区分功能和数据,从原理来说,功能这一部分是主动的,并拥有行为特征;而数据这一部分是被动的,他包含特定的信息结构,这些信息结构可以被功能所改变. 基于F/D方法设计的系统,通常会基于典型功能向下划分成不同的模块,而数据则在这些不同的功能块之间中传递.



The functions are broken down further and eventually converted into source code. This function/data division originates from von Neumann's hardware architecture, where the separation of program and data is greatly emphasized. The first machine language also had this division in its instruction set-up and it was thereafter logical to give high-level languages a similar structure. This approach has been difficult to escape from, but there have been several different attempts to do so. One such attempt is object-oriented programming, another is functional programming (see Backus (1977) or Bird and Wadler (1988)).
这些功能又进一步细化, 并逐步转化为源代码.这种功能/数据的划分方法分支是来源于冯.罗.依曼的计算机硬件体系结构,在冯.罗.依曼的计算机硬件体系结构中,非常强调程序和数据的有效分离.第一代的机器语言在机器操作码的层面也是采用这种划分方法,这种功能和数据划分方式也进一步影响相关的高级语言采用类似的结构.这种设计方法对后续的软件设计产生了非常深远的影响,以至于非常难以逾越,然后随着计算机硬件的发展,也发展出了一些不同的设计方法.面向对象编程object-oriented programming是其中一种方法,而函数编程(functional programming)是另外一种方法.
A system developed using a function/data method often becomes difficult to maintain. A major problem with function/data methods is that, in principle, all functions must know how the data is stored, that is, its data structure. It is often the case that different types of data have slightly different data formats, which means that we often need condition clauses to verify the data type. The programs, therefore, often need to have either IF-THEN or CASE structures, which really do not have anything to do with the functionality, but relate only to the different data formats. The programs thus become difficult to read, as we are often not interested in data format, but only in the functionality. Furthermore, to change a data structure, we must modify all the functions relating to the structure. Systems developed using such methods often become quite unstable; a slight modification will generate major consequences. In the same way, the instability of the development process, which we discussed earlier in this chapter, will become unnecessarily lasting, as any modifications made will create consequences in other areas.
一个基于F/D方法设计的系统通常在后期会变得非常难以维护. 从原理上来分析, F/D方法设计最主要的一个问题是在于所有的功能模块都必须确切的知道数据的寻址方式,用计算机的术语来说,也就是数据结构. 在实际的程序设计中,我们通常会遇到这样场景,也就是不同类型的数据有完全不同的数据格式,那这句意味着我们必须增加大量条件分支来验证数据类型..相关的程序在编码的时候, 通常需要使用大量的IF-THEN 或者 CASE结构,从本质上来说,这种IF-THEN 或者 CASE结构和程序需要实现的功能没有直接的联系, 而他主要的目的是在于对数据类型进行校验. 这样的程序结构会变得非常难以阅读,因为我们通常关心的是程序实现的功能,而不是程序的数据格式.另外,假如在后续的程序扩展中需要修改一个数据结构,我们就必须修改所有和这个数据结构发生关系的功能模块.基于这种方法设计的系统会变得非常不可靠,一个轻微的变更会产生巨大的影响后果.基于同样的理由,程序开发过程的一致性和稳定性就变得难以维持,因为任何一个小的调整都会引发其他程序功能领域的巨大的影响后果.
Another problem with function/data methods is that people do not naturally think in the terms they structure in. The requirement specification is normally formulated in normal human language. It often describes in 'What-terms' what the system will do, what functionality the system will support and what items should exist in the system. This is often reformulated into 'How-terms' for the functional breakdown when the focus changes. In this way we create a large semantic gap between the external and internal views of the system. Note that nothing in the methods explicitly tells you to change focus to the implementation. We shall see that, with an object-oriented method, the system will even be internally structured from the model taken from the requirement specification.
另外一个关于F/D方法的巨大问题是人们的自然思维和F/D模型有非常大的差异. 在项目的需求定义阶段, 需求规范书通常是通过人们的自然逻辑语言来描述.在需求规范书中,我们通常是从”要做什么”的角度来表达,比如系统需要支持那些功能,系统中必须包含那些项目等信息来界定需求. This is often reformulated into 'How-terms' for the functional breakdown when the focus changes. In this way we create a large semantic gap between the external and internal views of the system. Note that nothing in the methods explicitly tells you to change focus to the implementation. We shall see that, with an object-oriented method, the system will even be internally structured from the model taken from the requirement specification. 而这些原始用户需求往往需要从“如何做的角度”来重新进行定义,这种从“WHAT”到“HOW”转化过程主要是为了适应功能划分的需求,尤其是在功能需求关注点改变的情况下.在这种情况下,由于系统外部的视图是基于“需要做什么”的方式来定义，而系统内部的视图是基于“如何做”的方式来定义，这样一来我们在客观世界和IT系统之间创造了巨大的语义空隙（semantic gap）。注意，在F/D方法中始终没有明确的告诉你如何关注在实现中考虑系统重构的需求，进而预留必要的调整机制。在后面的分析中，我们将发现，通过应用面向对象的方法.系统将根据需求定义文档中定义的模型来进行结构化的聚合。
This is yet another reason that function/data systems become more difficult to modify. Owing to the fact that they are designed around how a certain behavior will be carried out (this being a common area of modification ), modifications often generate major consequences. Object-oriented methods structure the system from the items which exist in the problem domain. This is often a more natural way to describe the system. These items are normally very stable and change very little. The changes which do occur normally affect only one or a few such items, which means that the changes made are usually local in the system. If we wish to have a stable system, we should consider what has a tendency to change, and then design according to this knowledge. Peter Coad and Ed Yourdon (1991) inspired us to propose the following table:
另外还有一个原因导致基于function/data方法设计的系统变得非常难以重构; 因为这一类系统是围绕着一个特定的行为是如何执行的角度来进行设计的(而这也恰巧是后续软件重构时候主要发生的领域),所以对现存软件系统的重构将会带来巨大的后果.面向对象的设计方法是根据来自问题领域的真实项目来进行结构化设计和建模.这种方法是一种更加自然的模式来描述系统. These items are normally very stable and change very little. The changes which do occur normally affect only one or a few such items, which means that the changes made are usually local in the system. If we wish to have a stable system, we should consider what has a tendency to change, and then design according to this knowledge. Peter Coad and Ed Yourdon (1991) inspired us to propose the following table: 这些直接从问题领域提炼的项目通常非常可靠并且很少改变.而那些存在于外部世界中的客观实体时常会改变的部分通常只会对系统中的部分项目产生影响,这种改变通常意味着仅仅需要对系统的局部进行改变.假如我们希望拥有一个非常可靠的系统,我们必须充分考虑那些具有改变倾向的数据和信息结构,并根据这种专门的领域知识进行设计. Peter Coad 和 Ed Yourdon对这个问题进行了分析和提炼,并创造了下面的表格来启发我们这些系统设计人员.

Table 4.1 Tendency for change in various items
Item Probability for change
Object from application Low
Long-lived information structures Low
Passive object's attribute Medium
Sequences of behavior Medium
Interface with outside world High
Functionality High

Table 4.1 不同项目改变的倾向性
项目 改变的可能性
从应用中提取的对象 Low
长期保存的信息结构 Low
被动改变的对象属性 Medium
行为的顺序 Medium
和外部世界的接口 High
功能 High

However, this topic has not been investigated scientifically. Most object-oriented methods base their structure on the items that have a low probability of change. This can, though, lead to troublesome consequences, as, for example, Constantine (1990) has observed. We have also noted this and the approach we describe later in the book is designed to handle this. The aim of our approach is to manage all changes in a controlled and preferably local way.
然而,这个话题到目前为止也没有给出一个科学的答案. 目前大多数OO方法是基于一些具有稳定特性的项目(改变倾向性很小)来进行结构化设计.这种设计结构有可能带来有问题的结构,相关的问题, Constantine在1990年进行过专题的分析和报道.在OOSE的设计方法中,我们也开始关注这个问题,我们会在后续的章节中描述OOSE方法是如何基于项目的可变性特征来进行设计. OOSE方法的目标是能够管理系统所有的改变,基于一种可控的,推荐的本地方法.
This especially means that the items with a high probability for change must be managed by the method as well.
这一点就特别意味着那些具有不稳定特性的项目必须基于对象的方法来进行管理.
It has been claimed that it is possible to use a function/data method initially and later, usually in the design or programming phase, change to an object-oriented point of view. However, this becomes unnatural as the division of function and data is a central idea all the way down to the programming level. To start joining program and data, at any stage, in order to design your objects and classes becomes awkward, as the method is based on separating them. Thus, before programming commences, a paradigm shift will occur, making it difficult to use all the object-oriented programming qualities in full. Object-oriented programming requires a different approach from that of the function/data development methods.
虽然有理论宣称在有可能在开始和后续的阶段应用function/data方法, 也就是我们通常所说的设计和编程阶段,而在最后的阶段基于OO方法对系统实现进行改造,.然而,这种方式会显得很不自然,因为在F/D方法中,功能和数据的分离是一个核心观念,会从开始设计阶段一直持续到后续的程序编写阶段.在系统构建的任何阶段开始进行程序和数据的关联,来实现设计你自己的对象和类会变得非常别扭,因为这种关联是基于分离的方法为基础的.这样一来在具体的编码以前,一个程序范例的偏移将会发生,导致不能充分的保证OO程序设计的质量.面向对象的程序设计方法需要一个完全不同的方法,区别与那些F/D设计的方法.
The shift in approach means that the decision on which object is fundamental for the system structure is made too late in the development process. A central opinion in connection with object-oriented programming is that important items from the application domain will be represented as objects. If one uses a strict functional analysis method in combination with an object-oriented programming language, the object will not be identified until the design stage, and will be identified by people who have not had contact with either the orderer or the final user. This in turn suggests that the objects will probably not represent all the important items from the application domain. We have to reformulate the items the system will work with into How-terms in order to once again reformulate these 'Hows' as objects.
刚才提到的方法的偏移意味着关于系统结构中的基础对象的选择问题在整个程序设计过程中决策的太晚.在OO编程中有一个核心观念在于在应用领域中的重要项目必须是全部定义成为领域对象,也就是说基于对象的方式来表达和描述. 假如一个系统设计过程混合使用完全的F/D设计方法和面向对象的编程语言,那么直到程序设计阶段才会进行对象的定义工作,显然对象的定义会由编写代码的人员来完成,而这些编写代码的人是不可能和订购系统的负责人,或者将来会应用这套系统的人进行直接的沟通.这样一来,这种混合设计方式就意味着设计的对象不可能完全代表了从领域模型中提炼出来的所有重要的项目条目.对于那些缺失的条目,我们必须再次进行重新构造,以便把那些缺少的功能实体定义为对象.
We shall now discuss, from an object-oriented point of view, the different system development phases. We assume that there is an existing requirement specification in some form. This is analyzed with the aim of finding which objects will exist in the system. The object models obtained are designed when we perform design and implementation. Finally, we will briefly discuss how testing is carried out.
下面,我们将详细讨论一个完全不同的系统设计过程,一种面向对象的观点的方法.我们会假设存在给予特定格式书写的需求规范.基于寻找合适IT系统中合适对象的观点,这些需求规范将被充分的分析;基于需求分析获得的对象将在设计和实现阶段进行详细而充分大设计. 最后,我们将简要的描述如何进行面向对象的测试管理.