[译]OOSE第6章：Architecture 体系结构 6.1 Introduction

 

6.1 Introduction

This chapter discusses the architecture of the pyramid (see Figure 6.1). Here, we wish to provide a reason and motivation for the models created and the concepts used when working with Object-Oriented Software Engineering, OOSE. The chapter is relatively abstract, and thus may be skipped on the first reading. It is intended for readers who wish to obtain a deeper understanding of the architecture layer.

6.1介绍

  第6章是用来讨论开发方法金字塔的体系结构(见图6.1).在这一章的介绍中,我们希望能够提供当初OOSE中使用的不同模型创建的原因和动机,以及在软件项目中应用OOSE这种方法的主要理念.这一章的内容相对比较抽象,所以读者在第一次阅读时候可以直接跳过.我们介绍这一章的目的是为了协助那些希望对层次化体系结构(architecture layer)获得更加深刻的理解的读者.

6.1.1   System development

In an organization, work is continually modified. One of the means we use to carry out these modifications is to develop new systems. Here, we use the concept 'system development' to describe the work that occurs when we develop computer support to aid an organization. We wish to emphasize the importance of regarding system development as a means for supporting parts of an organization. Thus the system should be seen from the organization's and user's perspective.

 在一个商业组织机构中,日常工作通常会持续的进行更新.我们用来应对这种变化的手段之一就是开发新的系统. 当我们开发新的计算机系统来支持商业组织机构的正常运转时候,我们使用”系统开发” 'system development'这个概念来描述相关的开发工作.我们希望强调IT系统开发的重要性,因为这是一种支持商业组织机构高效运转的一种手段.这样一来,我们评价IT系统开发不但要站在商业组织的观点,也要站在用户的观点.

When a requirement for a system is identified, system development begins. The requirement and picture of the system

become firmly identified. Eventually, we decide to develop the system and write a requirement specification in some form, describing what we wish to obtain from the system. If the system is to be developed by someone outside the organization, this specification is used as the basis for obtaining quotations and ordering the system; if the system is to be developed internally, the specification is used to plan and control the development process. (Often all of this is actually enterprise modeling, which produces a requirement specification (in one form or another), but since we do not discuss enterprise modeling in this book, this naive view of it will be sufficient.)

当我们明确定义了一个IT系统的需求,系统的开发工作也开始了. 这个IT系统的需求说明和整体蓝图逐渐被明确定义清楚. 最终,我们决定开发这个系统并且通过某种形式写下相关的需求说明文档,需求说明文档是用来说明我们希望从系统中获取的主要功能.假如这个IT系统最终需要委托外部公司的人进行开发,需求定义文档被用作向第三方公司询问报价和订购系统的基础;而假如这个IT系统是通过组织内部开发,需求定义文档则用来制定开发进度和控制开发过程. (通常,上面所涉及到的工作其实就是企业建模enterprise modeling的工作, 企业建模enterprise modeling必须产生一个需求定义文档,), 然而我们不需要深入讨论企业建模的问题, 上面提到基础的看法已经完全足够了.

 

From this requirement specification, we develop the system. Our wish is to deliver a system with the required functionality and quality, and make it as effective as possible. When delivery has been made, the most important period for the system begins, namely its operation. This will comprise a large amount of maintenance and further system development, and may span some decades. This is often the most expensive part of system development, that is, of the system's life-cycle cost.

来源于需求说明文档的定义,我们进行IT系统开发的工作. 我们研发的目标是希望交付一个IT系统,他能够满足要求的功能和质量, 并尽可能多的适应有效的工作场景. 当IT系统已经交付,他最重要的生命周期就开始了,我们称之为运营operation. 系统运营工作主要包括大量的维护工作,以及进一步的系统研发, 系统运营工作有可能会持续10-20年,这一部分通常是在系统生命周期中,最为昂贵的一部分.

One can, of course, debate whether all these activities belong to the same system development or are actually several different ones, but this is not of interest to our discussion here. What is of interest is that this process goes on for a long time and that maintenance and further development form a major part of this process. This is not unique to the development of software systems, but is true for all manufacturing industries. What is unique, though, is that development of software systems is extremely complex, and that we handle this complexity poorly (see Brooks (1987)).

 

.有人也许会质疑是否上面涉及到的所有的工作是否应该归属于一个软件开发的过程,还是多个不同的软件开发过程, 然而这不是本文讨论的重点. 我们需要关心的重点是在于软件运营这个过程会持续很长一段时间,同时软件维护和进一步的软件开发构成了这个过程的主要部分.这种开发与运营的客观规律不仅仅适用于IT软件系统的开发过程,也同样适用于所有其他的制造工业. 然而软件开发的过程是非常的复杂,这一点是软件系统开发区别于其他工业系统开发的地方,而且我们目前还缺乏好的方法来管理软件系统的开发过程. (see Brooks (1987))

OOSE may be used from the time that the requirement specification exists in some form, and all through the system's lifetime until it is replaced by another system; that is, we include new development, further development and maintenance of the system in the period of OOSE use. We have even gone so far as to say that the main case is further development of a system and that new development is only a special case of this, even though it is a very important case.

OOSE这种软件工程方法可以用来在项目初始的时候通过一些特定的形式对需求模型进行定义,并在软件系统的生命周期中持续的进行应用,直到这个系统被其他的系统所置换.换句话说,OOSE这种软件开发过程包括了初始研发, 增量开发,以及软件系统全生命周期的应用. 我们的软件开发观点是如此的前卫, 我们认为后续的软件增量开发是软件研发的主要过程(main case),而软件初始开发仅仅是一个特殊的过程,虽然这是一个非常重要的过程.

 

6.1.2   Object-orientation, conceptual modeling and block design

As mentioned in Chapter 2, the basis of our approach originates from three totally different techniques which have all been used for a long time. These are object-oriented programming, conceptual modeling and block design.

正如前面第二章所提到的, 我们应用的OOSE这种方法的基础是起源于三种完全不同的技术,而这三种技术各自都已经在工业界长时间的进行了广泛的应用. 他们是面向对象的程序设计,概念建模conceptual modeling,和模块化设计block design.

 

Object-oriented programming started with Simula, which was developed at the Norwegian Computing Center during the 1960s. It was developed initially as an extension of ALGOL to handle simulation applieatons (see Dahl and Nygaard (1966)), but it was soon discovered by a few groups that it was usable for many other application areas too. However, it was not until the 1980s that object-oriented programming established itself widely. The real breakthrough was due to object-oriented programming being very suitable for developing Graphical User Interfaces (GUIs). Such systems are difficult to describe with traditional programming languages. It is actually only during recent years that it has been widely noticed that object-orientation is usable in most application areas. So object-oriented programming has had quite a difficult childhood, often being rejected. The concepts we have borrowed from object-oriented programming are mainly those of encapsulation, inheritance and the relationship between classes and instances.

面向对象的程序设计是从Simula这种编程语言开始的, Simula是由挪威国家计算中心Norwegian Computing Center在1960年发明的. 开始研发Simula的目标是对ALGOL这种编程语言进行扩展以便处理applieatons仿真方面的工作(see Dahl and Nygaard (1966)),而后来部分研究人员发现Simula这种编程语言在其他很多应用领域也具有应用价值. 然而,直到1980年以后,面向对象的程序设计应用范围才开始在工业界建立了广泛的应用.真正的突破要归功于面向对象的程序设计非常适合与图形化用户界面Graphical User Interfaces (GUIs).的开发;因为基于图形化界面开发的系统很难用传统的程序设计语言进行描述. 所以确切的说,直到最近一些年工业界才发现面向对象的程序设计可以适合在大多数应用领域..这样看来,面向对象的程序设计其实是有一个非常困难的童年时期, 当时是很难以被工业界所认可的.我们从面向对象程序设计中所借用的概念主要包括封装,继承,以及类和实例之间的相互关系.

 

Conceptual modeling has been used in several different contexts since it appeared in the 1970s; examples are analysis of information management systems and organization theory. The aim is to create models of the system or organization to be analyzed. Depending on which system and which aspects one wishes to model, different conceptual models are created. As one normally models a system where information handling is central, the concept of conceptual modeling is often used as a synonym for data modeling and is often discussed with structuring and the use of databases. For more information on conceptual modeling, see Hull and King (1987), Tsichritzis and Lochovsky (1982) or Brodie el al. (1984). In OOSE, we have expanded the technique with object-oriented concepts and the ability to express dynamic behavior. The models we develop are used mainly to understand the system and to obtain a good system architecture. These models form the basis for the actual system design.

概念建模(Conceptual modeling )自从1970年创建以来已经在多个不同的应用上下文中进行广泛使用,关于信息管理系统和组织理论的分析都是这样的案例.概念建模的目标是在于能够对系统或者组织进行模型创建以便进一步的分析. 基于那些系统和系统的那些方面我们希望构建模型, 可以创建不同的概念模型(conceptual models ).由于我们在对一个系统进行建模时往往是以信息处理为中心, 概念建模的概念通常是作为数据建模data modeling 的代明词,因此也常常和数据库系统的构建和应用一起讨论. 如果大家想更多的了解概念建模型,请参考Hull and King (1987), Tsichritzis and Lochovsky (1982) or Brodie el al. (1984)的论文. 在OOSE设计方法中,我们对基于面向对象的概念对这种技术进行了扩展,以便获得对动态行为的确表达能力. 我们设计的模型主要是用来更加方便的理解系统,并获得一个良好的系统结构. 这些模型构成了真实系统设计的基础.

 

The method of block design originates from Ericsson, a Swedish telecommunications company, and was developed from the 1960s onwards. It is now in widespread use over the whole telecommunications area, but has also been used in totally different application areas. The ideas were developed from considering how hardware was designed. A number of modules, each providing a specific functionality, were connected together with well-defined interfaces. One should be able to do the same thing with software: collect together programs and data into modules (blocks) and describe their mutual communication through interfaces. A new software approach was required in an attempt to avoid the problems that a program error could create; an error could shut down the whole system. By encapsulating program and data, these program errors would have less effect. By working with blocks, it was easier to change and introduce new functionality during operation; a new block is loaded and only one pointer is changed to point to the new block. Additionally, whether certain parts of a system would be developed in software or hardware was not clear. It was thus desirable to be able to change the implementation easily. Now the technique has been generalized and simplified to be usable in several different application areas. It is mainly used during construction. Most of the fundamental concepts were already present in the late 1960s and early 1970s. Furthermore, the early modeling concepts were proposed as contributions to the development of the CCITT standard, the Specification and Description Language (SDL). Concepts like blocks with encapsulation of data and behavior, signals between these blocks, and what we now call service packages were present, as well as the interaction diagram technique, in those early days.

模块化设计的方法起源于爱立信,一家瑞典的通信制造公司,这种方法自1960年以来一直在爱立信公司广泛的使用. 模块化设计方法目前不但在整个通信制造业中广泛的应用, 同时也在很多完全不同的应用领域中广泛的使用.模块化的设计方法是起源与硬件hardware设计的方法演进. 硬件系统通常由一系列的模块组成, 每个模块提供一个特殊的功能, 而不同的模块通过合理设计的接口进行互联互通. 软件设计者也必须面向软件进行模块化的设计方法, 具体来说需要把程序和数据聚合放置在一些模块中(blocks),并且通过接口的方式来描述模块间相互通信的方式.  为了试图避免程序潜在错误可能引发的质量问题,我们需要采用一种新的软件设计方法;因为程序潜在错误引发的质量问题有可能导致整个系统停机. 通过将程序和数据进行封装encapsulating的方式, 程序引发的错误可能带来范围更小的影响. 通过基于模块化的集成方法, 这使得程序开发者可以更加方便的在IT系统运营期间修改功能或者增加新的功能,一个新的模块被装载以后,我们仅仅需要调整一个指针来索引到新的模块. 此外, 在IT系统的前期设计阶段, 系统的特定子系统部分是通过纯软件方式,还是通过硬件方式来集成方式是不确定的. 基于这种模块化的弹性设计方式,系统集成人员在后期可以非常方便调整实现不同模块的实现方式。目前这种模块化的设计方法已经被广义化和简单化，以便在多个不同的应用领域使用。模块化的设计方法主要是用于系统构建阶段。关于模块化开发方法的基础概念在十九世纪60年代晚期和70年代的早期已经被广泛的介绍。此外，早期的模型概念为后续CCITT标准化组织发展的“定义和描述语言”（Specification and Description Language SDL）语言的做出了很大的贡献。SDL语言中广泛使用的概念比如将数据和行为封装在一起的功能块，这些模块间通信的信号，以及我们今天提到的服务包service packages的概念都被在模块化设计技术中明确的提出，就象SDL技术借鉴早期提出的交互图的技术一样。

 

These three techniques, which have all been used for a long time, have thus been background technologies for OOSE as described in this book. Note that this approach was developed long before many of the widespread methods used today in object-oriented development; see Coad and Yourdon (1991) or Booch (1991). Thus these methods could not have been background technologies for OOSE. The ideas and working methods have been put together and the concepts made unambiguous and related to each other. The result has shown itself to be a powerful and flexible development method. The technique should not be seen as being fully developed, as further development occurs continuously. We have also started to generalize the method, so that it can be used in even more areas. The latest domain in which we have started to work is enterprise modeling. Just for interest, we can mention here that we use the method, to a large extent, to develop the method itself (see further details in Appendix A). We thus regard Objectory as a system to be developed further in new versions.

这三种已经在工业界广泛应用的技术，就是在这本书中描述的OOSE技术的背景技术。请大家注意OOSE这种方法已经在面向对象技术领域的很多方法发布之前长时间进行演进和发展。see Coad and Yourdon (1991) or Booch (1991). 这样一来面向对象领域中提出的一些通行方法还不可能成为OOSE的背景技术。这些思路和工作方法已经被聚合在一起，同时这些概念被明确的定义和相互关联。这样一来，OOSE发展成为一种强有力和灵活的IT系统研发方法。OOSE这种技术目前还没有发展到终点，因为进一步的开发方法还在持续的研发中。我们还在进一步对这种方法进行一般化，这样一来OOSE可以在更多的领域中进行应用。目前我们已经开始在企业建模领域中应用OOSE的方法。.而作为开发兴趣，我们已经将OOSE方法自身也进行了极大的扩展 ，详细的内容见附件A。我们因此可以认为Objectory作为一个OOSE进一步研发演进的新版本。

 

We shall discuss first in this chapter what we wish to obtain from an architecture for a system development method, process and tools, and what problems we really want to solve. Common characteristics within all the models are then discussed. Each model is thereafter covered in an individual section, where the model's object types are briefly presented. The discussion in these sections is informal and aims to give an intuitive understanding of the architecture.

 首先在这一章中将讨论我们希望获得的IT系统开发相关的一个体系架构，基于这个体系架构可以用于支持一个IT系统研发需要的方法，过程和工具，以及我们真正希望解决的问题。在这一章节中，我们主要针对OOSE方法中采用的多个模型内部的公共特征进行深入讨论。每一个模型将在后续对应的章节中分别进行描述，其中模型的对象类型也会简要的介绍。在这些章节中的讨论将会是非正式的，并借助案例进行分析，讨论目标在于帮助读者对OOSE开发方法体系结构的直观理解。