[译]OOSE第4章：面向对象系统的研发 4.1 Introduction

4.1 Introduction

In order to design large systems, a systematic approach should be adopted. There is an abundance of such approaches and all of them are aimed at producing a good system. But what is a good system? This question can be answered partly from an external viewpoint and partly from an internal viewpoint of the system. The external viewpoint is that of all those who in some way use the system. They want the system to give correct results quickly, to be reliable, easy to learn and use, effective and so on. The internal viewpoint is that of the system developers and those who have to maintain the system. They want the system to be easy to modify and extend, easy to understand, to contain reusable parts, to be easy to test, compatible with other systems, portable, powerful and easy to manufacture.

为了保障合理的设计一个大型的IT系统, 我们必需应用系统化的设计方法(a systematic approach.) 经过多年的发展,目前已经有大量的设计方法, 所有这些方法都是专著于设计高质量的IT系统.可是到底什么是出色的系统呢, 这个问题可以部分的从两个方面来回答,一个是来自系统外部的视角,一个是来自系统内部的视角. 从外部的视角来说,所有系统外部的用户,也就是那些可能应用use系统的用户负责进行评价. 外部用户希望系统能够尽可能快的反馈正确的结果, 同时系统必须非常可靠,并且从用户界面的角度对用户非常友好,容易学习和使用,还有非常有效,等诸如此类的特性.而从系统内部的视角来说,则是那些研发系统的人,和那些后期负责对系统进行维护的人. 他们希望系统非常容易更新和扩展,容易理解,并包含一些容易复用的部分,容易测试,并和其他的系统具有良好的互操作性,可迁移性,强大,并且非常容易集成.

The definition of a good system varies in certain respects between different applications. In some, it is performance that is important and in others perhaps user-friendliness. It can, in fact, depend on the structure of the system, for instance, whether it is distributed or centralized. What is common to all (larger) systems is that they will need to be modified.

在不同应用场景下,针对完美系统的评价标准在一些特定的方面会有区别. 在有些情况下,系统的性能特性会显得非常重要,而在其他的一些情况下,系统的用户友好性则非常重要.有的时候,评价的标准可能和系统的结构有关系,比如分布式系统和集中式的系统. 然而有一点评价标准,对所有的系统(尤其是大型系统)都是适用的,因为他们后期通常需要被修改,所以系统的可重构性的好坏就显得非常重要.

In order to design a good system ,different system development methods have been proposed to describe either a project for development of a first product version or a global view of the entire system life cycle. Traditionally, the work is structured and described using different types of waterfall model(See figure 4.2). These water flow describe the flow of development process. The work begins by creating a requirement specification for the system. This is normally performed by the person who ordered the system or those developing it in cooperation with the orders. From the requirement specifications, an analysis and logical description of the system is made. Alternatively, this can be produced together with the requirement specifications. The design of the system is then completed and followed by implementation in smaller modules. These modules are first tested individually and then together. When the last integration test has been completed, the entire system can be testd and delivered and the maintenance phase begins. Initially, the idea was that one should complete one phase before the next one is stated. This principle, though, was abolished relatively quickly and thus a phase was allowed to be started before the previous one was totally complete. The waterfall model has had a tremendous effect on software engineering methods, although it was never intended to be taken so literally when first introduced. 

为了能够设计一个好的系统, 业界已经提出了很多系统化集成方法来描述一个系统的开发过程,这其中既包括了对一个产品的第一版本的原型的研发, 又包括了针对整个系统生命线的全局视图.在传统的方法中,这种类型的工作通常是利用不同类型的瀑布模型来组织和描述. 这些瀑布模型用来描述软件开发的流程和过程. 通过相关的工作是从创建系统的需求定义开始. 通常是订购系统的人,或者是那些和订购者有协作关系的开发人员来完成这个工作, 通常在需求定义文档资料中,关于系统的分析模型和逻辑结构也会同步定义.在瀑布模型中,我们也会有其他一种选择,就是利用其他的文档资料来和需求定义文档资料同步提供. 这样系统设计过程就已经完成,后续就开始项目的实施过程,后续会开始一些小型模块的开发工作.这些不同的小模块首先是各自独立测试,然后在一起集成测试. 当最后的集成测试完成,整个系统可以进行整体测试,并交付到客户;后续将会开始维护阶段.从瀑布模型的设计本源思想来看,通常要求不同的环节是顺序的完成,也就是前一个环节结束以后,后一个环节才会开始. 在实际的设计过程中,这种原则很快被废除,这样一来某一个阶段可以提前开始,无论前一个阶段是否已经完全结束.这种瀑布模型已经对软件工程方法产生了非常深远的影响,虽然这种方法在开始引入时候并非考虑到潜在的影响.

Not long after, it was discovered that water must fall upwards, so to speak, in order to fully describe the development cycle. The major problem, though, in more and more cases, was the maintenance phase, which in reality contained a new requirement specification, analysis, design and so on. Various other models were developed in order to describe these new facts; one of the more popular is the spiral model (see Boehm (1986)), shown in Figure 4.3. The spiral model can describe how a product develops to form new versions, and how a version can be incrementally developed from prototype to completed product.

  在瀑布模型被应用不久,很快大家需要发现为了能够完整的描述开发过程的循环,这个瀑布模型必须被回溯,换句话说就是”水必须从下往上流” . 这种特殊的问题发生的场景主要出现在系统维护阶段,在现实的开发过程中,涉及到新的需求分析定义,分析工作,和设计工作这一系列的工作.一些其他的开发模型被引入到软件界来描述这种新的任务场景;其中有一个非常流行的模型就是螺旋模型spiral model,图4.3可见.利用螺旋模型,我们可以描述一个产品如何基于已经完成的版本产生新的版本,以及一个版本如何基于模型prototype进行增量的开发过程进而产生一个完整的产品.

System development usually contains all of these phases (even if they are given different names in different methods), and development always occurs incrementally over them. This development scenario is true irrespective of the method used. We can characterize system development as being initially rather turbulent, but stabilizing subsequently. The development method used should therefore help to make the development process stable as soon as possible. The idea is that we should work on analysis long enough to understand the system totally, but not so long as to consider details which will be modified during design. This often means that a relatively large part of the work performed is carried out during the analysis phase. 

  软件系统的集成过程通常会包含上述所有的阶段(尽管这些阶段在不同的方法中有不同的命名),而真实的开发过程通常是基于这些阶段进行增量的开发. 这种软件集成的阶段划分顺序适用于所有开发方法.在真实的软件开发过程中,开始的阶段通常会非常混乱,多变不稳定,后续逐渐变化得稳定和可靠.那么在软件开发过程中应用好的方法的目的在于尽可能快的将软件开发过程从混乱转化为稳定和可以信赖.要做到这一点,有一个核心理念在于:系统的设计者必须专注系统分析工作持续足够长的时间,只到能够理解整个系统,并能够描绘出系统的全貌;但这并不意味着在分析阶段需要搞清楚所有的细节,通常这些细节会在设计阶段进行变更.应用这种设计方法就意味着在分析阶段,系统集成工作相当大部分的工作需要完成.

A typical time division for the projects we have been involved in is shown in Figure 4.4. Initially, a small group of people performs analysis and subsequently design. These activities are worked on iteratively. As the system structure stabilizes, more people are involved in implementation and testing. However, analysis and design activities may also be done even when testing is started. At this stage it is mainly changes in the analysis or design models that are incorporated.

结合我们前期参与的项目的经验,一个典型项目阶段的时间划分规律见图4.4所见. 在开始阶段, 由一小部分人员开始进行分析工作,后续会进行设计工作,这两个过程会反复的执行. 一旦系统的架构稳定下来,更多的项目人员会加入进来,开始实施和测试的工作.然而,分析和设计的工作会持续的进行,即便是在测试已经开始的情况下.在这个阶段,主要的工作是针对分析模型和设计模型中不合理的部分进行调整.