[译]OOSE第8章：Construction 软件构建 8.1 Introduction

 

8.1 Introduction

8.1 介绍

8.1.1   Why do we have a construction process?

8.1.1   为什么我们需要一个软件构建过程

We build our system in the construction phase, based on the analysis model and the requirements model created during analysis. The construction process lasts until the coding is completed and the code units have been tested. Construction consists of design and implementation.

 我们在软件构建阶段开发我们的目标系统, 基于前期在分析阶段创造的分析模型和需求模型. 软件构建过程将一直持续到源代码编写完成,同时所有的代码单元都已经完成了相关的测试.软件构建工作包括了设计design和开发实现implementation.

Following the construction process we have the testing process in which the use cases and the entire system are tested and certified. This does not mean that you must wait until all parts have been constructed before starting the verification of the system; instead we try to do as much as possible in parallel. Also, verification involves a lot more than just testing code. If possible we also try to start construction before analysis has been completed.

跟随着构建过程以后,我们将进行测试过程,在测试过程阶段所有的用例模型和整个系统都将被测试和验证.当然这并不意味着你需要等到系统的所有组件都构建完成以后才开始进行系统的验证工作; 恰恰相反我们尽可能的平行处理系统构建和系统测试的工作. 同时,软件验证工作包含很多的方面,而不仅仅是测试源代码, 在可能的情况下,我们也会在分析阶段结束以前开始部分系统构建的工作.

What, then, is the purpose of the construction phase? Could we not write the source code directly from the analysis model? There we described the 'objects' in the system and how they are related.

那么,系统构建阶段的主要目标是什么呢? 为什么我们不能直接根据分析模型来编写源代码呢? 在分析模型中我们也已经描述了系统中需要的对象,以及他们之间的相互关系.

There are three main reasons for having a construction phase:

有三点主要的原因来说明在系统开发过程中需要一个软件构建过程.

(1) The analysis model is not sufficiently formal. In order to move seamlessly to the source code we must refine the objects; which operations should be offered, exactly what should the communication between the different objects look like, which stimuli are sent, and so on?

(1)首先,分析模型并不是足够的正式.为了能够实现从模型到源代码的无缝迁移,我们还需要对对象进行重新优化; 并明确每个对象具体需要提供那些操作,以及不同对象之间的通信看起来的模样,那些激励需要发送, 诸如此类的信息.

(2) The actual system must be adapted to the implementation environment. In analysis we assumed an ideal world for our system. Alas, there is no ideal world, so in reality we must make adaptations to the environment in which the system is to be implemented. This means  that we must initially transform the analysis model from the analysis space to a space with still more dimensions (see Figure 8.1). We must for example consider performance requirements, real-time requirements and concurrency, system software, the properties of the programming language, the database management system to be used, and so on.

 (2)  确定的IT系统都必须最终适配到一个特定的实施环境当中. 在分析阶段我们假设目标系统是在一个理想的环境中进行运行. 可是, 事实上没有系统会在理想的环境中运行, 所以在现实情况中我们需要将系统适配到他需要部署的环境当中去. 这也意味着我们首先需要把来自问题领域信息空间的分析模型转换成为一个具有更多维度的空间当中的新模型(参考 Figure 8.1). 举例来说,我们需要考虑性能的需求,实时操作和并发性的需求,底层系统软件,程序设计语言的特性,将会使用的数据库管理系统, 诸如此类的更多维度的考虑.

(3) We want to validate the analysis results. As our system grown and becomes more formalized, we will see how well the analysis model and the requirements model describe the system. During construction, we can see at an early stage whether the result of the analysis will be appropriate for construction. If we discover points which are unclear in the analysis model or the requirements model, we must clarify them, perhaps by returning to the analysis process.

(3) 我们希望确认分析模型结果的有效性.随着我们系统的不断成长,并且变得更加正式化, 我们将会看到分析模型和需求模型能否很好的描述目标系统. 在系统构建阶段,我们可以在前期发现分析过程产生的分析模型是否可以正确的指导系统集成. 假如我们发现分析模型或者在需求模型中有不明确的地方, 我们就必须澄清这些细节, 必要的时候我们需要重新返回开展分析过程.

These three reasons may look as though there are deficiencies in the result of the analysis phase that we must clarify here. This is an incorrect view since the purpose of analysis is to understand the system and to give it a good structure. It is consequently important to understand that the considerations taken into account during construction should influence our system structure as little as possible; we want to keep the good properties in the system that the analysis model focused on. It is the application itself that mainly controls the structure, not the circumstances when implementing it. We therefore made an informal and comprehension-oriented analysis where these considerations did not disturb the work.

上面的3点理由有可能揭示了分析阶段的结果还存在着一些欠缺,这样一来我们必须在系统构建阶段来澄清这些内容. 其实这是一种错误的观点,因为分析阶段的目标是更好的理解目标系统,并且设计出一种更加健壮和易于扩展的体系结构. 应用OOSE方法很重要的一点是必须理解在系统构建阶段研究出来的结论要尽可能小的影响前期确定的系统结构; 因为我们希望保持系统的各种良好的特性, 而这些良好的特性是分析模型关注的重点. 应该主要是来自问题领域的应用本身控制着系统的体系结构, 而不是具体实施时候的部署环境. 因此在分析阶段我们进行的是非正式的和面向理解的分析工作comprehension-oriented analysis, 分析阶段产生的分析结果将不会影响到开发工作.

Changes in the system architecture to improve performance should as a rule be postponed until the system is being (partly) built. Experience shows that one frequently makes the wrong guesses, at least in large and complex systems, when it comes to the location of

Figure 8.1 Construction initially transforms a model in the analysis space into a model in the design space. This is mainly done in the design part of construction.

the bottlenecks critical to performance. To make correct assessments regarding necessary performance optimization, in most cases, we need smelting to measure. Otherwise we will only make guesses which may or may not be appropriate. Since we have nothing to measure until the system has been built, we cannot make these optimizations at an early stage. One way of avoiding this dilemma is to simulate the critical parts of the system. Another way is to perform prototyping to get an early opinion of what the system will look like, but this is a risky method since you can easily make unrealistic simplifications. A prototype always aims to highlight particular issues. General conclusions on other issues therefore cannot be drawn from a prototype that does not highlight these issues. However, if you know for sure where the performance-critical parts are, for instance because you have a very good knowledge of the application, optimizations could be done at an early stage. For a similar discussion, see Barry (1989).

针对系统体系结构改变来提升系统性能的工作应该作为一条规则延迟到系统已经开始进行构建或者是部分的开始构建以后再开展. 经验显示这一条原则常常会带来错误的理解,至少在大型的复杂项目中,当我们需要开始定位对性能影响严重的设计瓶颈. 考虑到必要系统性能优化,为了给出系统性能状态相关的正确结论, 在大多数情况下,我们需要采用一些特殊的手段.否则我们只能猜测哪些设计可能会,也可能不会是对系统性能提升有帮助. 因为我们在系统构建完成以前没有采取任何特殊手段,我们也无法在软件构建的早期阶段开展这些性能优化工作. 一种避免这种进退两难情况的方法是对系统的关键部分进行仿真. 另外一种方法是通过原型验证来对系统的运行性能获得一个早期的印象, 可是这是一个存在一定风险的方法,因为你很容易做出一些不现实的简化. 原型设计的目标通常是为了突出一些特定的问题. 这样一来关于其他特定问题的一般性结论就无法从一个并不关注这些问题的原型中得出. 然而,假如你提前很确定具体那一部分会对系统的整体性能产生严重的影响, 因为你对特定应用有很好的背景知识, 那么就可以在早期开展性能优化的工作. 在Barry (1989)的论述中,我们可以看见一个类似的讨论.

 

8.1.2   What is done in the construction phase?

8.1. 2  在系统集成阶段的开展的工作

Construction activity produces two models, the design model and the implementation model. Construction is thus divided into two phases, design and implementation, each of which develops a model (see Figure 8.2). The design model is a further refinement and formalization of the analysis model where consequences of the implementation environment are taken into account. The implementation model is the actual implementation (code) of the system.

在OOSE方法中,系统集成工作将会产生两个模型, 设计模型和实施模型. 系统构建工作因此也划分为两个子过程, 每一个子进程将各自开发一个模型(见图8.2) . 设计模型是针对分析模型进一步的优化refinement和规范化formalization, 其中设计模型将充分考虑部署环境所带来的影响后果. 而实施模型则是真实的系统实施源(源代码).

  To develop the design model we perform three main steps:

  为了开发设计模型,我们将分3步进行执行:

(1) Identify the implementation environment. This step includes identifying and investigating the consequences that the implementation environment will have on the design. Here all

 Figure 8.2 The input and output models of construction.

strategic implementation decisions should be made. How will the DBMS be incorporated into the system? What component libraries will be used and how? How should processes and process communication be handled? What about error handling and garbage collection? The list goes on. This work aims nl drawing conclusions about how these circumstances should be handled in the system. This step can (and should) be done in parallel with the analysis work so that it is ready when l ha actual design starts.

 

(1)识别实施环境. 这一步的工作主要包括识别和调查具体部署环境对设计模型所带来的影响后果.在这个环节中所有关于系统实施方面全局性的策略都需要做出决策.具体包括DBMS 系统将如何集成到系统当中? 那些组件库将在项目中使用,以及如何使用?不同的进程之间如何进行通讯? 系统中如何进行异常错误处理和垃圾收集? 诸如此类的问题清单. 这些工作的目标是针对具体实施环境将如何影响系统设计的方式给出确切结论. 这一步可以(应当)和系统分析工作并行开展, 这样就能够在确切的设计工作开始时, 相关的环境分析工作已经就绪.

 

(2) Incorporate these conclusions and develop a first approach to a design model. Here we use the analysis model as a base and translate the analysis objects into design objects in the design model that fit the current implementation environment. From a project perspective this could be directly incorporated in the analysis model, but for maintenance purposes and understandability this is not recommended. When doing further development, the analysis model forms a logical basis for understanding the system and thus is an essential model to keep during the entire system life cycle.

(2) 综合这些结论,并对设计模型给出第一步的解决方案. 在这里我们将使用分析模型作为一个基础,并把分析模型中的对象转换成为设计模型中的对象, 以便能够适应当下的实施环境. 从一个项目快速开发的观点, 设计模型可以直接加入到分析模型当中, 但是出于后续维护和理解的目的,这种设计方式并不推荐. 当进行进一步的系统开发工作, 分析模型将构成一个逻辑的基础来实现对系统的理解, 因此也需要作为一个必须的模型, 这个模型将在系统的全生命周期内保持稳定.

(3) Describe how the objects interact in each specific use case. Here the design model is formalized to describe all stimuli sent between the objects and also to define what each operation will do to each object. The use case model will be of great help during this work as it will help us to specify each specific flow in the system in detail. This step gives us the object interfaces.

3) 描述这些对象在每一个特定用例模型中的交互方式. 这里设计模型将规范的描述对象之间传送的所有激励(stimuli),以及每一个对象将会执行的操作(operation).在这一步的工作当中,用例模型将发挥重大的作用, 他将帮助我们定义在系统内部发生的每一个特定事件流程的详细细节. 这一步将为我们提供对象之间的接口.

The implementation activity then implements each specific object. From the design model we get very detailed specifications of all objects, including their operations and attributes. Various techniques may be used here and we will discuss some of them later. The programming language and the component library used will of course be fundamental tools for implementation.

系统实施活动将具体实现出每一个具体的. 根据设计模型,我们将获得关于所有对象非常细节的描述, 包括每个对象的操作和属性. 这个阶段将会使用不同的技术,我们后续也会详细的讨论其中的一部分. 程序设计语言和组件库也理所当然成为系统集成阶段的基本工具(fundamental tools).

We will now discuss these steps in more detail and make some comments on the various techniques used. The recycling example analyzed in the previous chapter will be used and design and implementation models will be made for it.

   我们现在将更加深入的讨论系统集成阶段的这些步骤, 并对需要应用的不同技术给出评论与建议. 在前面章节中分析过的废品回收机的案例将会被继续分析, 并给出对应的实施模型.