[译]OOSE第6章：Architecture 体系结构 6.6 设计模型

 

6.6 The design model

6.6 设计模型

6.6.1   The design model's object

6.6.1 设计模型对象

In theconstruction process, we construct the system using both the analysis model andthe requirements model. First, we create a design model that is a refinementand formalization of the analysis model. The initial work when developing thedesign model is to adapt to the actual implementation environment. The analysismodel was developed assuming ideal conditions. We must now adapt it to reality.As mentioned previously, we have two main reasons for not introducing theimplementation environment earlier. The first is that we do not want it to affectthe basic structuring of the system, since the current circumstances probablywill be changed in one way or another during the system life cycle. The secondreason is that we do not want the problem to be blurred by the complexitytypically introduced when looking at the implementation environment. In thisway we can focus on the essentials when developing the most important aspect ofthe system, namely, the basic structure of it.

   在系统构建的过程中，我们使用分析模型和需求模型来构建系统。我们首先将分析模型进行优化和规范化进而创造一个设计模型。 当我们开始开发设计模型时候，最初始的工作是考虑如何适配真实的项目实施环境。分析模型是在理想环境的假设下进行设计开发的。我们现在比较将分析模型适配到现实环境中。正如前面所提到的，我们是基于2点理由没有提前考虑引入实施环境。首先我们不希望项目的实施环境来影响系统的基本体系结构，因为当前的实施环境可能在系统未来的生命周期内以这样，或者那样的方式发生改变。第二个原因是我们不希望确切的问题变得混淆不清，通常提前考虑实施环境以后会带来的问题的复杂度增加。在这种方式下，我们可以在设计系统最重要的方面时专注于本质问题，也被叫做系统的基础结构。

 

We can thus regard this design model as aformalization of the analysis space, where we adapt the analysis model so thatit fits into our implementation environment. The design space has, relative tothe analysis space, been expanded to include a dimension for the implementationenvironment (see Figure 6.24). This dimension means that further concepts areintroduced, which the analysis model must be adapted to suit.

我们可以这样把设计模型作为分析空间的规范化（a formalization），这样一来分析模型就能够方便的适配到我们的实施环境当中。设计空间和分析空间匹配，并被扩展了一个关于实施环境的维度（请参考图6.24）.这个维度意味着新的概念将被引入，其中分析模型必须进行适配设计以后来进行匹配。

This means that we want to keep and massagethe analysis model to fit the actual implementation environment at the sametime as we refine it. Our goal is to refine it until it is easy to write thesource code from it. Since the analysis model has all the properties we wantfor the system, we want this structure to form the basis of the design model.However, there will be changes to this model when introducing, for instance, arelational DBMS, a distributed environment, performance requirements, aspecific programming language, concurrent processes and so on. This is thereason that we develop a new model.

这就意味着我们希望保持并塑造分析模型来适配确切的实施环境，同时我们尽一步的优化他。我们的目标是持续的优化分析模型直到能够非常容易的根据设计模型来产生源代码。因为分析模型包含了我们期望系统拥有的所有特性，我们也同样希望这个结构能够组成设计模型的基础。然而，这个模型将会被改变，举个例子来说当引入一个关系型的数据库，一个分布方式的计算环境，性能需求，一种特定的编程语言要求，并行处理，等要素。这就是我们开发新模型的原因。

How much should we work with the analysismodel and when should we start the design model? This is the classicalquestion. 'When is analysis ready? '. There is no uniformly applicable answerto this question. On tin- one hand we want to do as much work in the analysismodel as possible, where we can focus on the essentials, but on the other handwe do not want to do so much that we need to change it when adapting to the implementationenvironment. What we really want is a continuum of refinement in the modelswhere the switch of models will occur where we start to see the consequences ofthe implementation environment (see Figure 6.25).

  我们需要将分析模型设计到什么程度，以及我们什么时候应该开始设计模型？这是一个非常经典的问题。‘什么时候已经分析完备’。对于这个问题没有一致的，可以应用的答案。一方面我们希望尽可能详细的进行分析模型的设计，因为我们能够关注系统的本质；另外一方面我们又不希望进行过多的设计，因为在未来我们要根据实施环境适配的需求对分析模型进行改变。What we really want is a continuum of refinement in the models wherethe switch of models will occur where we start to see the consequences of theimplementation environment (see Figure 6.25). 我们真正需要的是对分析模型的持续优化，直到我们决定将分析模型切换到设计模型以前，这种切换取决于我们开始看到实施环境的对设计的重要影响因素。

 

Hence, when the transition from analysis todesign should be made must be decided for each specific application. If therewill be no adaptation problems with the DBMS, distributed environment,real-time requirements, concurrent processes, hardware adaptations and so on,it is fine to be quite formal in the analysis model. However, if these circumstanceswill strongly affect the system structure, the transition should be made quiteearly. The goal is not to redo any work in a later phase that has been done inan earlier phase. In one project using Objectory, the development team saw thatthe implementation environment would have very little con¬sequence in one partof the application since it would be entirely within one process at one siteand would be affected only slightly by the database technology used. Here theanalysis model was refined significantly to include operations on the objectsand the parameters of these operations. In another part of the application theconsequences were much greater. Here they foresaw consequences from distributedhardware involving different operating systems, a changeable protocol betweenthe different nodes (not yet standardized), hard real-time requirements and soon. This part of the analysis model was developed in a much more shallow way,postponing important decisions until the design model stage.

所以，什么时候开始进行分析模型到设计模型的转换工作需要根据每个项目的应用要求来决定。假如没有关于数据库，分布方式计算环境，实时计算环境需求，并行处理，硬件设计等等方面的考虑要素，那么在分析模型中将设计内容进行正式化和延续到设计模型是非常合适。然而，假如这些环境因素将强烈的影响到系统的体系结构，这种从分析模型到设计模型的转换工作应当尽早开始。在一个使用Objectory方法开发的项目中，研发团队发现实施环境对应用系统中的一部分几乎没有影响，因为这一部分的处理是在一个进程程中，并位于一个站点之内，这一部分仅仅和应用的数据库技术有一点关系。在这种情况下，分析模型被特别的进行优化，包括了对象的操作设计和这些操作携带的参数。而在这个应用系统的另外一部分，实施环境对设计的影响后果非常严重。在这里，他们预见到了来自环境因素的影响，包括源于不同操作系统的硬件结构，不同节点之间可变的接口协议，硬件实现的实时操作需求等因素。这一部分分析模型的设计则是采取的一种非常肤浅的方式，很多重要的决定都是被延迟，直到设计模型阶段。

 

One possibility is to continue working onthe analysis model, and to continue on that model even when incorporating theimplementation environment into it. However, this is not recommended from aproduct-oriented view. When further developing

the product, theanalysis model is needed to reason about when to incorporate the changes, sinceit has far less complexity than the design model. Therefore, it is desirable tokeep the ideal analysis model of the system during the entire system lifecycle. Likewise, many changes of a system come from changes in theimplementation environment. Such changes are then easily incorporated, since itis the same analysis model that will form the basis of the new and modifieddesign model. In this way we may view the design model as a specialization ofthe analysis model for a specific implementation environment. However, the costof keeping the analysis model must be judged for each product.

  一种可行的方式是持续的针对分析模型进行分析设计，并且持续的针对模型进行完善，直到开始将实施环境合并到分析模型当中。然而，从面向产品开发的视图中，这不是一种推荐的方法。当后续进行产品研发的阶段，相关的分析模型还需要进一步针对在什么时间点引入系统设计变化的说明原因，因为分析模型远远比设计模型简单。所以，令人满意的做法是在系统的整个完整的生命周期以内保持理想的分析模型。同样的，系统的很多改变来自系统实施环境的改变。这样的改变能改非常容易的合并到系统当中，因为设计模型的不同版本是来自相同的分析模型，这个分析模型将构成新的变更以后的设计模型的基础。在这种方式下，我们可以把设计模型看作是分析模型针对一个特定实施环境的一个专门版本定义。然而，保持不同分析模型的代价必须根据每个产品来决策。

 

This also prompts the question of whenchanges in the analysis model should be made when working with the designmodel. If a change of the design model comes from a logical change in thesystem, such as that two objects should be logically related, then such changesshould also be made in the analysis model. However, if the change is aconsequence of the implementation environment, for instance that two objectsshould not communicate directly owing to the process structure chosen, thensuch changes should not be incorporated in the analysis model.

这也会很快带来另外一个问题，在具体进行设计模型设计的时候，什么时候应该改变分析模型。假如设计模型的改变是来自系统的逻辑变化，比如两个对象应当建立逻辑上的关联关系，这样的改变也需要同步到分析模型当中。然而，假如这种改变是因为实施环境改变带来的影响，举个例子来说，两个对象因为处理进程模式选择的问题不允许直接进行通讯，那么这样的改变就不应该合并到分析模型当中。

The structures which we mainly work withare thus basically the same as for the analysis model. However, now the viewhas changed since this is a step towards implementation. We therefore use theconcept of a block to describe the intention of how the code should beproduced. The blocks are the design objects and they are drawn as rectangles,as shown in Figure 6.26. One block normally aims to implement one analysisobject. Here it could be possible to use different types of block, ifpreferable, for instance interface blocks, entity blocks and control blocks, tohighlight the traceability.

 我们工作聚焦的结构就通过合适的变更管理和分析模型保持基本一致。然而，现在系统观察的视图已经发生了改变，因为我们向系统的代码实施又迈进了一步。我们因此使用功能模块a block的概念来描述程序代码如何产生的方法倾向。功能模块blocks其实是设计对象design objects，通常是用矩形框来表示，显示方法见图6.26所显示。一个功能模块的通常是目标在于实现一个分析对象。在这里，是有可能使用不同类型的功能模块；加入更好的做法，是功能模块，实体功能模块，控制功能模块，这样可以分析显示的实现不同模型之间的可跟踪性。

It is important to understand, though, thatthe blocks are not the same objects as the analysis objects. We have brieflytouched on this before as we mentioned that it is desirable to keep the idealanalysis model. Changes will be introduced in the design model, for example tosplit one block into two owing to the need to handle, for instance, looselycoupled process communication. Such a split should not affect the analysismodel since we do not want changes due to design decisions to be illustrated inthe analysis model. To highlight the difference we use the term 'block' insteadof 'object'.

有一点非常重要，大家要理解，功能模块block和分析模型中的对象是不完全相同的。我们前期简单的接触过这样一个观点，保持一个理想的分析模型是令人满意的。在设计模型阶段，会引入一些改变，举个例子来说将一个功能模块block划分为2个，因为需要处理一些特殊的实现，比如松耦合的进程通信。这样的功能块划分不应该影响分析模型，既然我们不想引入改变，因为在分析模型中已经表明了设计的决定。为了突出这种区别，我们使用名词'block'来代替‘对象’'object'。

Another difference between the analysis anddesign models is that the analysis model should be viewed as a conceptual andlogical model of the system, whereas the design model should take us closer to theactual source code. We can view it as a drawing or map of the code to bedeveloped. This means that we change the view of the design model into anabstraction of the source code to be written later on.

关于分析模型和设计模型的另外一个区别是分析模型应当被看作是系统的概念和逻辑模型，然而设计模型将帮助我们更加接近确切的源代码。我们可以吧设计模型当中是即将开发源代码的一个映射，或者是一副图画。这就意味着，我们将改变设计模型成为后续将要书写源代码的一种抽象。

Hence the designmodel should be a drawing of how the source code should be structured, managedand written. Since we want a strong and easy-to-maintain traceability from theanalysis model through the design model to the implementation model (sourcecode), we will try to map the design objects (blocks) to the module conceptused in the programming language we are implementing in. We will discuss thistopic in greater depth later.

   所以，设计模型应当是一些关于源代码如何组织，管理和书写的图画。既然我们需要也紧密联系的，容易维护的可跟踪性来管理分析模型，设计模型和实施模型（源代码）；我们也需要努力的将涉及对象（功能块）映射到我们在程序开发时编程语言使用的模块概念。后面我们将非常深入的讨论这个问题。

We view the blocks as an abstraction of theactual implementation of the system. The blocks will group the source code. Toknow how to implement the blocks, we need to refine the design model further.We do this by describing how the blocks will communicate during execution. Todescribe the communication between the blocks we use stimuli. The concept ofstimuli was introduced in Chapter 3. A stimulus is sent from one block toanother to trigger an execution in that block. This execution may send newstimuli to other blocks.

我们把功能模块（block）看成是系统真实开发源代码的一种抽象。这些功能模块（block）将完成源代码的组织和管理。如果想知道如何实现这些功能模块（block），我们需要进一步优化设计模型。我们通过进一步描述这些功能块在执行的时候如何互相通信的方式来细化设计模型。为了描述不同模块之间的通信，我们使用激励stimuli的方式。在第三章中介绍了激励的概念。一个激励是从一个功能模块发送到另外一个模块，来实现触发其他模块的功能执行。而这个新的操作也可能向其他功能模块发送新的激励。

To describe a sequence of stimuli, we useinteraction diagrams. In these, we can describe how several blocks communicateby sending stimuli to each other. As a base for these interaction diagrams weuse the use case model again. Thus we describe in detail, for each use case,how and which stimuli will be sent and in what order. We thus describe the usecase as a sequence of stimuli sent between the blocks. An interaction diagramis shown schematically in Figure 6.27.

为了描述激励发送和接收的时序，我们使用交互图的方式。在交互图中，我们可以描述几个功能模块通过互相发送激励信号来交互。作为这些交互图的基础，我们将再次使用用例模型。这样我们针对每一个用例，进行更加详细的描述，在一个用例的执行过程中哪些激励应该发送，如何发送，以及发送的顺序。我们通过这种方式把用例描述为不同功能模块之间顺序发送的一组激励信号。图6.27概要的显示了一幅交互图的形态。

When we have described all sequences, thatis, all use cases, including any alternative flows and error flows, we havedescribed all external communications between the blocks. From this we havealso gained a complete interface description of each block. The notation todescribe stimuli should therefore be the one used in the chosen programminglanguage. The design model thus consists of a complete description of theblocks with their interfaces.

当我们已经针对所有的用例模型描述了对应的时序关系，包括任何的分支流程和错误流程，我们就已经完成了系统功能模块之间所有的外部通信的详细描述。根据这个交互图的集合，我们也获得了针对每个功能模块完整的接口描述。用于描述激励的注释也因此也要成为后续编程语言注释的一部分。设计模型这样就包含了关于功能模块和对应接口的完整描述。

We mentioned that the blocks should beviewed as abstractions of the code to be written and that it is desirable thattraceability between blocks and the code is easy. In, for instance, C++, atypical block will be mapped to one file (actually two: .h and .c files)  including one or several classes. In Ada it is natural to map ablock to a package. We denote this module concept by the generic term objectmodule; that is, in C++ an object module is the class, in Ada it is a package. The interfaces of theblocks will be mapped onto the object module of the particular language, soserving as the interfaces of these modules (the .h file in C++ and thespecification part of the Adapackage).

We mentioned that the blocks should beviewed as abstractions of the code to be written and that it is desirable thattraceability between blocks and the code is easy.  我们已经提到过功能模块应当被看作是后续编写源代码的一种抽象，因此能够保持源代码和功能模块之间的易追踪性是最理想的。In, for instance, C++, a typical block willbe mapped to one file (actually two: .h and .c files)  including one or several classes. 举个例子来说，在c++中，一个典型的功能模块将映射为一个文件（确切的说是两个文件，.h and .c 文件） ，这个文件包括一个或者几个类。In Adait is natural to map a block to a package. We denote指示 this module concept by the generic term objectmodule; that is, in C++ an object module is the class, in Ada it is a package. 而在Ada 中，很自然的做法是把一个功能模块映射为一个包。我们利用一般长期对象模块的概念来表示模块的概念；也就是说在C++中一个对象模块是一个类，而在ADA中则是一个包。The interfaces of the blocks will be mapped onto theobject module of the particular language, so serving as the interfaces of thesemodules (the .h file in C++ and the specification part of the Ada package). 而模块的接口将映射到特定编程语言的对象模块，作为这些模块的接口来提供服务（c++中的.h文件，和Ada 包中的接口定义部分）。

One problem in the construction process isthat complexity increases enormously. To master the system development, it isessential to be able to manage this complexity. Therefore it is important tohave concepts in the information space which allow us to manage the complexsystems that we build.

在系统构建阶段的一个问题是模型的复杂度明显增加了不少。为了能够掌握系统的开发过程，能够管理系统的复杂度是非常必要的。所以，清晰的掌握信息空间的概念是非常重要，这样就能够允许我们方便的管理我们构建的系统。

To manage the system more abstractly, weuse the concept of the subsystem. A subsystem groups several objects.Subsystems may be used in both the analysis model and the design model.Subsystems may also include other subsystems; the concept is recursive. In thisway we may have a hierarchical structuring of the system to manage itscomplexity. The highest level we use is the system level. The system is theactual application we are working with. The system also defines the borders ofthe application. We will discuss the subsystem concept in more depth laterand we shall also see that subsystems may be used as an aid to managing productdevelopment.

为了能够更加抽象的管理系统，我们使用子系统的概念。一个子系统负责组织多个对象。子系统的概念可以在分析模型和设计模型中使用。子系统也可以包含其他的子系统，这是一种递归的概念。通过这张能够方式，我们可以拥有一种层次化的系统结构，来管理它的复杂性。我们使用的最高层面是系统级。系统就是我们实际工作的应用系统。系统同时也定义了应用的边界。我们后续会更加深入的讨论子系统的概念，同时我们将发现子系统可以被用来作为一个援助手段来管理产品开发。

 

6.6.2   Working with the design model

6.6.2  围绕设计模型开展工作

During the construction work, we proceedfrom the analysis model. For each object in the analysis model, we assign ablock in the design model. This transformation occurs totally mechanically andcan be performed by a tool. The transformation is seamless. Depending on, mostimportantly, the implementation environment, we may need to make a deviation sothat this one-to-one relationship may be modified. In the design model we thusformalize the analysis model and adapt it so that it fits into the requiredimplementation environment.

   在系统构建工作的过程中，我们要从分析模型开始。针对分析模型中的每一个对象，我们在设计模型中将分配一个功能模块。这种转换过程通常是机械的发生，并可以通过特定的工具来完成。这种转换工作基本上时无缝的。主要是依赖实施环境的要求，我们可能需要对设计模型做出偏差性的调整，这样一来这种1对1的关联关系可能会被调整。在设计模型中，我们通过这种方式将分析模型进行正式化，并进行适配处理，这样设计模型能够适配到需要的执行环境的需求。

When we have created the block structure,we draw interaction diagrams to show how these blocks communicate. Normally, wedraw an interaction diagram for every use case. In reality, the use case modelwill also henceforth form the basis of the construction process, and we therebyguarantee that the system we construct is exactly what the users want.

当我们已经创建了功能模块的结构，我们将画出交互图来显示不同的功能模块是如何交互的。通常，我们为每一个用例模型都画一幅交互图。从此以后在现实中，用例模型也将构成系统构建过程的基础，同时我们利用这种方式保证了我们构建的系统确实是用户需要的系统。

In the first part of the constructionprocess we work mainly with the blocks. This is often an appropriately detailedlevel to work with. However, when maintaining and developing new versions ofthe product, it is often appropriate to extract the interfaces to a subsystemlevel; in this way, we only specify the interfaces between subsystems early onwhereas, inside each subsystem, the development team can work with the blocks.So, it is unnecessary for all the teams to know the internal structure of eachsubsystem. In Chapter 8 we discuss different techniques to manage this.

    在系统构建过程的第一部分，我们主要是围绕功能模块开展工作。这通常是一个适当的软件抽象详细级别来实施工作。然为，假如是维护或者是开发软件产品的新版本。通常在子系统的级别提取接口的方法和定义一个合适的方法；利用这种方式，我们仅仅提前定义不同子系统之间的接口，而不急于定义系统内部的结构；而开发团队能够针对各自的功能块开展工作。因此，项目团队的成员了解每个子系统的内部结构师是不必要的。在第8章中，我们将讨论不同的技术来管理这种开发过程。