[译]OOSE第8章：Construction 软件构建 8.2 The design model 设计模型

 

8.2 The design model

8.2 设计模型

8.2.1Traceability

8.2.1 可跟踪性

The design model will further refine theanalysis model in the light of the actual implementation environment. Here wewill explicitly define the interfaces of theobjects and also the semantics of the operations. Additionally, we will decidehow different issues such as DHMSN, programming language features anddistribution will be handled.

设计模型将会进一步的根据确切实施环境的要求对分析模型进行优化和重构. 在设计模型中我们将会清楚的定义对象的接口,以及定义对象操作的语意(semanticsof the operations).此外,我们将决策与关系型数据库,程序设计语言的属性,和分布式环境处理相关的一些问题,

The design model will be composed of blockswhich are the design objects. These will make up the actual structure of thedesign model and show how the system is designed. These blocks will later beimplemented as source code.

设计模型将会由多个软件功能模块(blocks)组成,这些模块是一种经过详细设计的对象. 软件功能模块将组成设计模型的确切结构,也会显示目标IT系统是如何设计的. 这些软件功能模块最终将开发成为详细的源代码.

The blocks will abstract the actual implementation.The implementation of the blocks may be one specific class in the source code,that is, one block is implemented by one class. However, often a block isimplemented by several different classes. The blocks are therefore a way ofabstracting the source code.

软件功能模块是确切系统实现,也就是源代码的一种抽象(abstract). 软件功能模块的实施有可能是在源代码当中的一个特定的类, 也就是说,一个软件功能模块将通过一个类来实施. 因此,软件功能模块也就是源代码的一种抽象方式.

The module level of the programminglanguage we denote by the generic term object module (see Constantine (1990)). In an object-orientedlanguage these modules (that the programmer actually writes) will be the actualclasses. When we use a specific language we have a direct correspondence to alanguage concept and this concept should of course be used, for example classin an OO language or package in Ada.Here we will use the terms 'object module' and 'class'.

我们使用通用对象模块来表示编程语言级别的模块层级.(参考Constantine (1990). 在一个面向对象的程序设计语言当中,这些模块(也就是程序员确切编写的源代码) 将对应着具体的类. 当我们使用一种特定的程序设计语言, 我们将在软件功能模块和一个程序语言概念之间建立一个直接的映射关系,同时这种概念是理所当然需要使用的,举个例子来说在一个面向对象语言中使用的类,或者是在ADA这种程序设计语言中使用的包(package)的概念. 这里我们将使用’对象模块’和’类’的概念.

The first attempt at a design model can bemade mechanically, based on the analysis model. Initially each analysis objectbecomes a block. This transformation rule means that we obtain a cleartraceability in the models. We started by modeling the system in the analysis modelin a manner which provides a robust structure for the system. As each analysisobject is traceable to a block, changes introduced in the analysis model willbe local to the corresponding block in the design model and thus also in thesource code. Note that the traceability is bidirectional, that is, it also goesthe other way - we can trace a class in the source code back to the analysisand see what gave rise to it.

建立一个设计模型的首次尝试可以通过一种机械的方式来完成,也就是基于前期设计好的分析模型. 最开始的时候,每一个分析对象将映射成为一个软件功能模块. 这种转换的规则也就意味着我们在设计模型和分析模型之间建立了一种非常清晰的可跟踪性. 我们前期是通过分析模型来对IT系统进行建模型, 而这种建模的出发点是要获得一个健壮和稳定的体系机构. 因为每一个分析模型都可以清楚跟踪到一个确切软件功能模块, 在分析模型中引入的改变也将会被控制在对应的设计模型的软件功能模块局部的范围, 同样也会控制在源代码局部的范围. 注意,在这里可跟踪性是一种双向的要求,也就是说,在相反的方向上也可以清楚的进行跟踪, 我们可以从源代码中的一个类回溯到分析模型, 并观察实施模型对分析模型的影响.

Traceability is a tremendously importantproperty in system development. Each major system will be altered during itslifetime. Whether the changes emanate from changed requirements or responses totroubleshooting, we will always need to know where the changes need to be madein the source code.

可跟踪性是系统研发中一个至关重要的特性. 每一个主要的系统在他的生命周期中都有可能发生改变. 无论这种改变是有需求变更引起,还是由缺陷修复所引起, 我们总是需要知道对应的改变将如何映射到具体的源代码当中.

Here we have the great advantage oftraceability; you can easily find your way in the system even if it has beensubjected to major changes. It is also important to have a high functionallocalization (that is, high cohesion) (see Yourdon and Constantine (1979)) in order to know thatchanges will not influence large parts of the system.

在OOSE方法中,我们将获得系统模型之间可跟踪性方面的巨大优势, 你可以非常容易的在系统中找到你的方向, 即使系统已经经过了重大的变更. 同时保持功能的高度内聚也是非常重要的一点,这样一来对局部功能的改变将不会影响到系统的其他大的方面.

In this chapter we will construct theexample described in the previous chapter. This description will be in overviewform and simplified, but the mode of work should appear clearly enough topermit a complete construction to be done fairly easily. As we go along we willintroduce new terms and concepts that are used in the example.

在本章节中,我们将针对前面章节中讨论的按理进行软件集成. 这种描述将通过一种概况的方式,并对具体的设计过程进行了某种简化, 然而在OOSE过程中工作的模式应该足够清晰的进行展现, 帮助大家来相对容易理解完整的工作过程. 随着我们深入的分析这个案例,我们将会介绍新的术语和概念, 这些术语和概念将会在案例中进行使用.

Our analysis model is as shown in Figure8.3. We will from now on concentrate on the use cases Returning Item and ItemStuck, and consequently we will focus on the objects that participate in theseuse cases.

我们的分析模型将会在图8.3中进行显示. 从现在开始我们将专著于用例模型ReturningItem(回收物品) 和 ItemStuck(物品阻塞), 后续我们将重点关注参与这些用例模型的对象.

Based on this analysis model we can nowmechanically, and seamlessly, find the first attempt at a design model. Thefirst attempt is simply to assign the same model as the analysis model. Todifferentiate between the two models, we use another notation and draw theseblocks as rectangles instead of circles (see Figure 8.4).

基于前期分析模型的设计,我们可以首先通过机械的,无缝的的方式映射出第一个设计模型. 第一次做成的尝试是根据分析模型指派相同的设计模型. 为了清楚的区分这两种模型,我们使用另外一种标识方法,我们使用矩形来代替圆形来在模型图上标识这些功能模块.

The semantics of the design model issomewhat different from that of the analysis model. The analysis model isdeveloped in logical terms and is only a conceptual picture of the system to bebuilt. Therefore it is essential to keep and freeze the analysis model forfuture maintenance even after the design is finished. The design model,however, is an abstraction of how the actual system really is built. The firstattempt at this model is a direct mapping from the analysis model. Its final structure,however, will reflect how the implementation environment has affectedconstruction. The goal is to keep the structure found in the analysis model andnot violate it unnecessarily in the design. We also want the design to have alogical and robust structure.

分析模型的语意在某种程度上和分析模型存在一定的区别. 分析模型是完全从一个逻辑的观点出发来开发的, 他仅仅是将要开发系统的一个概念视图. 所以在后续的维护过程中能够保持和冻结分析模型是非常重要的一点, 即使在设计完成以后. 而设计模型, 毕竟是真实系统的源代码的一种抽象. 虽然我们在最开始获得的设计模型是直接映射自分析模型. 而设计模型的最后结构, 无论如何,需要反映出真实的实施环境是如何影响最后的软件结构. 所以我们的目标是保持在分析模型中建立好模型稳定性, 而不需要在设计阶段影响分析模型. 我们同时也希望设计模型能够拥有一个逻辑和稳定的体系结构.

 

Figure 8.3 Analysis model of the recycling machine.

Figure 8.4  First attempt to design the structure of the recycling machine.

The semantics of the blocks should thusreflect the semantics of the objects existing in the actual system and,likewise, the associations between the objects should also reflect how theobjects in the system are really related. For example, most programminglanguages do not have any way of implementing the extension association. Duringdesign we must decide how this association should be implemented and change thedesign model to reflect this. Similarly, if the programming language does notoffer any technique to support inheritance, we must reflect on how theinheritance in the analysis model is really implemented. We will discuss thesetopics in more detail later.

软件功能模块的上下文语义应该能够反映出存在于目标IT系统中对象的上下文语义，同样的道理，对象之间的关联也应当能够反映出目标IT系统中对象是如何进行关联的。举个例子来说，绝大多数程序设计语言是无论如何无法支持扩展关联这种关系的编程实现。 在设计过程中，我们就必须决定这种扩展关联关系将如何实现，同时针对设计模型进行调整来反映出这种关联关系。同样的道理， 假如程序设计语言不能提供对继承（inheritance）的支持，我们必须在设计模型中反映出分析模型中的继承关系是如何具体实现的。后续章节中，我们将会更加详细的讨论这些细节问题。

 

This is consequently the first idea for asystem architecture. We emphasize that this is the first idea because it may bechanged, since we must consider the implementation environment. We may have tobreak up or divide blocks because we want to distribute them on different nodesin our computer system, or we may even need completely new blocks toencapsulate an existing DBMS. We will discuss how to consider the implementationenvironment shortly.

因此，这个最初的设计模型就是关于系统体系结构的第一个构想。我们在这里强调第一个构想（the firstidea）的原因是因为初始建立的设计模型还有可能发生改变，因为我们还必须考虑实施环境的影响。我们有可能必须将软件功能块进行拆分（break upor divide），因为我们希望把这些软件功能块分布部署到我们计算机系统的不同的节点当中，或者我们甚至需要一个完全全新的软件功能块来实现对一个已经存在的DBMS系统进行封装。我们很快将开始讨论如何考虑实施环境所带来的影响问题。

The design model enables us to reduce thecomplexity of the system. The blocks are actually an abstraction mechanism forthe source code. By speaking in terms of blocks we can discuss the system on anoverview level and understand the architecture of the system.

设计模型将帮助我们降低系统的复杂程度。软件功能模块确切的来说就是针对源代码的一种抽象机制。通过面向软件功能模块开展讨论的方式，我们可以在一个宏观的层面（overviewlevel）对系统进行分析讨论，并且能够全面的理解系统的体系结构。

Through this abstraction mechanism wereduce the complexity radically, which means that it is easier to build acorrect system that will avoid errors caused by complexity. It has been noted,(see Levendel (1990)) that it is qualitatively better to avoid constructionerrors by reducing complexity at an early stage than to search the system forfaults when it is completed and to correct each error. The latter variant is(unfortunately) often typical of today's traditional system development.

     通过设计模型这种抽象机制，我们极大的降低了系统的复杂度， 这也就意味着我们将能够更加容易的构建一个正确的系统，他能够通有效避免因为系统复杂度过高所引发的异常错误。前期Levendel就阐明了一个重要的观点：通过在系统设计初期阶段降低系统复杂度的方式来有效避免系统集成的错误，比起在系统集成完毕以后开始搜索系统错误和纠正这些错误的方式具有极大的优势。现实设计中，系统后期大量的结构变更通常就是遵循传统系统开发方法所带来的不幸结果。

8.2.2   The implementation environment

8.2.2 实施环境

To adapt the design model to the actualimplementation environment, we must first identify the actual technicalconstraints under which the system should be built. This identification may(indeed should) be done early, ideally before the analysis model is developed,since it affects how far the analysis model should be refined.

我们实现将设计模型适配到确切的实施环境当中去，我们首先必须识别出系统构建相关的各种技术性限制条件。这种识别工作应当尽可能早的启动，最理想的情况是能够在分析模型开发之前就完成，因为他将直接决定分析模型的设计和优化的程度。

 

What do we include in the implementationenvironment? The most obvious things are perhaps the target environment (wherethe system should execute during operation), programming language and existingproducts that should be used (for example, DBMSs), but in fact everything thataffects the realization of the system must be included in this concept. We willhere discuss some of these aspects in more detail, but let us first discuss theoverall strategy for handling the implementation environment.

那么在实施环境中包含哪些具体内容呢？其中最重要的因素可能就是目标部署环境（也就是系统将来在操作期间所运行的环境），程序设计语言，和必须使用的现存的软件产品（举例来说，关系型数据库系统），但是实际上所有影响到系统实施的因素都必须在目标部署环境这个因素中进行考虑。我们在这里将会更加深入的其中的一些方面，然为让我们首先来讨论一下处理实施环境相关问题的总体策略（the overall strategy）。

Since one of the more common changes to asystem is a change in the implementation environment, it is preferable tohandle this in the same 'changeable' way used for the rest of the system. Thisimplies that as few objects as possible should be aware of the constraints ofthe actual implementation environment. Therefore, the overall strategy forhandling it should be to have such commitments locally and to encapsulate themas much as possible. In this way any change of environment should be local andnot have an effect on several objects. (This is not unique to object-orientedsoftware engineering, but rather a traditional style of good programming.However, in the light of the design model this will be apparent here, and thuswe will have a controlled way of handling it.)

因为系统的实施环境通常是一个容易改变的因素，进而对系统的设计与实现产生影响，因此最好需要设计一种能够支持应对实施环境各种潜在变化的体系结构，就像在OOSE方法中处理问题领域的设计方式一样。这也就是假设在系统中需要有尽量少的对象需要考虑确切实施环境的限制。所以，处理实施环境设计方面的总体策略就是尽可能的把实施环境的影响承诺控制在局部的方案同时尽可能的封装这些需要和实施环境打交道的对象。通过这种设计方式，实施环境的任何改变都应该被限制在局部的范围，而不会影响到多个不同的对象。（这种设计要求不仅仅是面向对象的软件工程所特有的一种设计思路，同时也是一种传统的好的程序设计模式。然而在OOSE方法的设计模型当中，面向实施环境的这一个设计要求将会体现的非常明显，这样一来我们就能够通过一种受控的方式来处理这个问题。

 

So, what is included in the implementationenvironment? We will here discuss some topics.

那么，哪些要素会包含在实施环境当中呢？我们将在这里讨论其中的一些主题。

If we want to be able to change parts inthe target environment, these parts should be encapsulated in a new block. Youwill thus create new blocks that represent occurrences in the targetenvironment. For example, if your application willhandle files in the operating system, you should create a block that interfacesthe application's file handling and the operating system's file handling asshown in Figure 8.5.

假如我们希望有能力改变目标执行环境的一些部分，这些部分就应当封装在一个新的功能模块当中。你就通过这种方式创建了新的软件功能模块来代表目标执行环境各种事件对象。举个例子来说，假如你的应用需要在目标操作系统中处理文件，那么你就应当创建一个软件功能模块来实现对应用的文件处理接口，同时相关的文件处理功能的封装见图8.5所显示。

In Figure 8.5, the File Manager blockshould offer operations such as Create file to the application objects. Thisblock may then have different implementations for different configurations ofthe system. There are different realizations for this. Either an abstract classthat specifies the interface can be defined, which is implemented in environment-specificdescendants that are instantiated as required by the chosen platform; or theobject can check at run-time which platform it is running on and execute thecorrect statements for this environment. A third way is to decide this when thesystem is delivered for different configurations. In C++ (or C) you would thenhave several .c files (one for each platform) implementing the same .h filewhich specifies the interface to the application. When producing the softwareit would be decided which module should be linked into the final product. Whichway is chosen is dependent above all on the programming environment. The firstis natural for object-oriented programmers, while the second would typicallyyield CASE statements in languages where polymorphism is not present. Thethird, which may very well be combined with the first, is more a choice of howthe production and delivery of the software should take place.

在图8.5中，软件功能块文件管理者（File Manager）应当提供必要的操作，比如为应用对象创造文件的操作。这个软件功能块可能就必须包含面向不同系统配置条件下的不同的实现代码。要实现这种设计目标有几种不同的实现方案。一种可行的方法是为文件操作的接口定义一个抽象类，这个抽象类具有根据不同实施环境所需要的具体后裔类，由后裔类来完成具体环境下的文件操作，根据选择的平台不同需求来实例化不同的后裔类；另外一种可行的方法是由对象负责检查当前的运行环境，并根据具体的环境来来执行对应的声明。第三种方式是在系统交付的时候提供不同的配置选项，根据最后的真实环境来决定选择哪一种配置实现。 在C++（或者是C）中，你将会拥有几个不同的.c 文件（一个文件用于支持一个平台）来实现相同的.h 文件，其中.h 文件负责定义面向应用的接口。当生成软件的时候，最后软件交付人员将决定具体是哪个软件模块将会连接进入最后的软件产品中。具体选择哪一种实现方式，总体上来说和选择的程序设计语言有密切的关系。其中第一种实现方式通常会被面向对象的程序设计者所选择，而第二种实现方式同时会在那些不能有效支持多态的程序语言中使用，并常常是通过case的声明来实现。第三种实现方式，可以非常好的和第一种使用方式联合使用，这种方式更多是在如何生产和交付的软件方式的时候进行选择

 

Likewise it is important to investigatewhether the target environment will execute in a distributed way on differentprocessors or in different processes. We will discuss this in more detail inChapter 9 where we discuss operating systems processes.

同样的道理，提前调查目标部署环境是否会通过一种分布的方式在不同的处理器processors当中或者是在不同的进程processes.中也是非常重要的一点。我们将在第9章中更加深入的讨论这个问题，其中我们将会深入的讨论操作系统系统的进程。

Figure 8.5 Aspecial block should be included to encapsulate the special properties of thetarget environment.

Which programming language is used will affectthe design. We will later discuss how the concepts we use will he translatedinto the programming language, but the more basic properties of the languageand its environment are also fundamental for the design. The existence ofinheritance, multiple inheritance, typing, standards and portability areexamples of such properties. Furthermore, strategies for handling errors duringrun-time must be decided early. Adahas its exception mechanism and Eiffel its assertions. C++ does not have anysuch mechanisms (in Version 2 of the language). It is essential to decide earlyon how this strategy should be incorporated in the design. Likewise the memorymanagement strategy must be chosen early. Some object-oriented languages haveautomatic garbage collection, but in other languages it is up to the programmerto clear away instances that are not used any more. In that case the programmermust keep track of all references to these instances.

项目开发选择哪一种程序设计语言也将影响最后的设计。我们后续将会详细讨论在设计模型中使用的概念将会如何转换成为程序设计语言，然为程序设计语言更加基本的一些属性和他的运行环境对相关的设计模型来说也是同样非常重要的。是否能够支持继承，多重继承，类型typing，开发规范和可移植性都是这些程序语言基本特性的范畴。此外，程序运行时候处理异常和错误的策略也必须尽早决定。其中Ada 有自己独特的异常管理机制，而Eiffel 有自己的断言机制，而C++则不提供任何类似的机制（在编程语言的第二版中）。提前决定这种容错处理策略如何有效的集成在设计当中是非常重要和必须的。同样的道理，内存管理机制也必须尽早提前决定。在一些面向对象的程序设计语言当中，语言本身能够提供自动的垃圾回收机制，可是在另外一些程序设计语言当中，则是由程序设计人员来决定是否清除哪些不再使用的程序实例。在那种情况下，程序设计者就必须持续的跟踪哪些实例的所有参考索引。

 

Closely related to the programming languageis the use of components for programming. The use of component libraries mayalso affect the design. One example is the design of the interface objects.There are components (or tools) for building interfaces, and this will affecthow the design is made. The use of components implies several new questions, whosediscussion we will postpone until Chapter 11.

另外一个和编程语言密切相关的问题是使用组件进行程序设计。对组件库的使用也有可能会影响到设计模型。其中一个例子就是关于接口对象的设计。因为存在现存的组件（或者是工具）来构建接口，这些因素也将影响到如何开展设计工作。关于组件的使用也将意味着几个新的问题，我们将会延迟到第11章来详细的讨论这些问题。

Often existing products are used whendeveloping new systems. Examples of such products are DBMSs, User InterfaceManagement Systems (UIMSs), network facilities and other internally orexternally developed applications that should be incorporated in this newsystem. The normal strategy for handling these products is to introduce newblocks to encapsulate them in the same manner as was described for the targetenvironment. In Chapter 10 we will discuss in more detail blocks thatencapsulate a relational database.

当研发新的系统的时候，通常哪些已经存在的软件产品也将会被使用。这样一些软件产品的例子包括关系型数据库系统，用户接口管理系统(UIMSs)，网络设备，和其他一些内部或者是外部开发的应用系统，这些软件产品都将必须集成到这个新系统当中去。一个传统的处理这些软件产品的策略是引入新的软件功能模块来封装这些产品，就像我们针对目标部署环境一样所采取的封装策略 。在第十章中我们将花更多的功夫来讨论如何设计软件功能模块来封装一个关系型数据库。

Products that are used only during development(mostly development environments) may also affect the design. Such productsinclude compilers, debuggers, preprocessors and other tools. These may affecthow the code is written and configured. Other such implications may come fromstandards and coding rules.

在开发阶段（主要是开发环境）所使用的软件产品也有可能影响设计模型。 这样的软件产品包括编译器， 软件追踪器，预处理器和其他的一些工具。这些将影响源代码是如何编写和配置。其他类似的影响可能来自标准和编码规则。

During construction we must also take intoconsideration any requirements for performance or limitations of memory. Such requirements may also affect thedesign. One common example is when databases are used and frequently usedtransactions are too slow. Then a redesign (or modification) of the databasedesign may be necessary. Access paths to the database may then be changed or wemay have to introduce new index tables in the database, or change existingones, to speed up operations on the database. However, the principal strategyon these topics should be, as previously mentioned to postpone suchoptimizations until they are needed or you are absolutely sure that they willbe needed. It is far too common that a good design is ruined for performanceoptimizations that are only sub-optimizations. Oftenthe real bottlenecks are missed and then new optimizations are necessary.

在系统构建阶段我们也必须考虑任何关于运行性能方面的需求或者是内存方面的限制。这样的一些需求也可能会影响最后的设计。一个很常见的案例就是当数据库系统使用的情况下，哪些频繁使用的交易会非常的缓慢。在这种的一种情况下，关于数据库系统的重新设计（或者是变更）可能就是非常必须的。对数据库系统的接入路径可能需要被改变，或者我们需要在数据库系统中引入新的索引表，或者是改变已有的索引表，来实现对数据库操作的速度。然而，关于上述问题处理的一个原则上的策略，正如前面所提到的，是要能够延迟处理这些优化类的问题，直到我们确实需要处理这些问题，或者是我们已经完全确定这些问题需要被处理。在实际项目中我们常常会发现一个好的系统设计会被性能优化所破坏，而这种优化往往直是一种子项目的优化。 这样一来真正的瓶颈将会被程序设计者所错过和忽视，然后新的优化是必要的。

 

To investigate potential optimizationproblems early, simulation or prototyping may be used before the actual designis done. Then the designers have much a better basis for determining where thereal optimizations should be made. Of course, extensive experience in theapplication area may also help you to judge at an early stage whereoptimizations should be made. The message here is that if you are not sure ofthe correctness of a performance optimization, you should not make it until youare sure of how it should be done.

 为了能够提前调查潜在的性能优化问题, 我们可以在开始系统设计以前进行系统仿真和原型验方面的工作.这样一来,系统设计人员就能够基于原型试验获得一个更好的基础, 以便确切的决定应当在系统总体视图的那一部分真正需要开展优化工作. 这里需要关注的一个重点是假如系统设计者不知道正确的性能优化方案, 那么你就不应当急于做这件事情,直到你已经确定应当如何开展性能优化的工作.

The people and organization involved in thedevelopment could also affect the design. For instance, if the design has to bedone at different sites, a division of the design work is necessary. Thedifferent competence areas of the development staff may imply that the designshould be done in a specific way. We will not discuss these issues in thisbook, but the principal strategy should be that such factors should not affectthe system structure. The reason for this is that the circumstances(organizations, staffing, competence areas) that are in effect today willprobably change during the system's life cycle. To build these circumstancesinto the system will have a bad effect on future maintenance of the system.

参与项目开发的设计师和开发团队也有可能影响设计方案.举个例子来说, 假如系统设计需要在不同地域的办公室内开展, 对系统设计的划分就是必须的. 而系统开发人员的不同的技能区域范围和层次也有可能会对设计方案产生影响,  有可能需要采取一种特殊的方式来适配开发人员的技能现状. 在本书中我们不会讨论这些问题, 可是一个基本的策略是这些因素不应该影响系统的体系结构. 这样决策的原因是因为对系统设计产生影响的环境因素(组织, 成员,和技能范围) 今天可能会有效, 但是在系统的全生命周期中通常会发生改变. 如果把这些环境因素集成到系统当中去将会对未来系统的维护产生很负面的影响.

To achieve maximum robustness these issuesshould affect the design as little as possible. The overall principle is thatchanges can and should occur, but all changes should be justified anddocumented (also for robustness reasons). We may have to change the idealdesign model in various ways:

•    To introduce new blocks in the design modelwhich do not have any representation in the analysis model.

•    To delete blocks from the design model.

•    To change blocks in the design model(splitting and joining existing blocks).

•    To change the associations between theblocks in the design model.

 

 

为了能够获得最为稳定可靠的系统体系结构, 这些和设计环境相关的问题应当尽可能少的影响到设计模型. 关于设计模型变更方面最首要的一个原则就是系统结构的变更能够,并且应当发生, 但是所有的改变都应当是正确的,并且已经被完整的进行了记录(也有可能是出现系统稳定性方面的考虑).我们有可能通过几种不同的方式来改变理想的设计模型:

•    To introduce new blocks in the design modelwhich do not have any representation in the analysis model. 在设计模型中引入新的软件功能块, 这些软件功能块在分析模型中没有任何对应代表关系.

•    To delete blocks from the design model. 在设计模型中删除软件功能块.

•    To change blocks in the design model(splitting and joining existing blocks).在设计模型中对软件功能块进行改变( 拆分或者是合并已经存在的软件功能块.

•    To change the associations between theblocks in the design model. 改变设计模型中软件功能块之间的关联关系.

 

Normally, adding blocks to handle theenvironment is a good change. Adding blocks for other functionality should notnormally be done, since they should be introduced through the analysis model.

一般来说, 增加新的软件功能块来处理环境相关的功能是一种好的设计方式. 而增加新的软件功能模块来处理新的系统功能则不是一种常规的设计方式,因为这些新的软件功能模块首先需要通过鉴定分析模型来引入.

Deleting blocks is more suspicious. Why areyou deleting the block? If you have good reasons for it (often implementationreasons),  it is fine, but if you areactually changing the logical structure of the system, such a change should bemade in the analysis model first. If it is not, you should view such a changewith great reservation.

删除软件功能模块则应当更加慎重. 为什么你要删除这些软件功能模块. 假如你有好的理由( 通常是处于实现方面的原因), 这当然是合适的, 可是假如你确实已经改变了系统的逻辑结构, 那么你就首先应当在分析模型中进行重新设计. 假如不是这样的一种处理方式,你就应当对这种直接的对象删除操作持一种极大的保留态度.

Splitting and joining blocks are alsosuspicious changes. Any such change will often decrease the robustness of thesystem and should be done with great care. For implementation or performancereasons it may be justified, but the designer should devote a great deal ofthought to such changes.

分离与合并软件功能块(blocks)同样也是一个非常显著的改变. 其中任何一种类型的改变都会降低系统的稳定特性,因此系统设计人员应当非常小心的处理这种变化. 假如是出于系统实施,或者是系统性能方面的原因,这种改变就是正确的, 但是系统设计人员需要投入很大的精力来思考如何合适的处理这种软件功能块的改变.

Changes of associations are perhaps themost common change in the design model. These changes often come from the implementationenvironment. Synchronization and communication between processes is one exampleof where the communication between objects may be changed. Another example isthe actual implementation of associations. Additionally, we must decide how toimplement the associations. For instance, the extension association has nodirect implementation technique in the common programming languages. We musttherefore decide how this association should be implemented.

针对软件功能模块之间关联关系的改变通常是在设计模型中最常见的一种改变. 这种关联关系的改变通常是来自设计环境的影响. 其中一个例子就是进程之间的同步和通信方式就有可能改变对象之间的关联关系. 另外一个例子就是关联的真实实现方式也有可能发生改变.此外,我们还必须考虑如何实现不同的关联关系. 举个例子来说, 在普通的程序设计语言中就没有相应的技术来直接实现”扩展关联”这种关联关系. 因此我们就必须决定这种关联关系将需要如何来实现.

What extension actually means is that a behavior,bl, will be inserted into another behavior, b2 (see Figure 8.6). We want the(description of) behavior b2 to be completely independent and have no knowledgeof behavior bl. Ideally we would like bl itself to take the initiative andinsert itself into b2. However, there is no mechanism in some ordinaryprogramming languages by which this can be expressed. One solution to this isto have b2 take the initiative by sending a stimulus to bl. How we do this inthe source code will be described when we implement the blocks. We willtherefore have a communication association from b2 to bl where this stimuluscould be send.

 扩展的含义就是意味着一个行为, b1, 将会被插入到另外一个行为b2当中去. 我们希望行为b2和行为b1是完全独立的,  并且完全不需要感知到行为b1的存在. 理想的实现方式是我们希望行为b1能够主动的发起扩展操作,并且能够直接把自己插入到行为b2当中去. 然而,目前在一些普通的程序设计语言中还没有对应的机制来表现这种扩展关联关系. 一种可行的解决方案就是让行为b2来发起这种扩展关联关系, 具体的实现是由行为b2来向行为b1直接发送一个激励(stimulus).当我们后续实现这个软件功能块的时候,我们将在源代码中描述这种实现方式. 这样一来,在具体的实现中我们建立了一种从行为b2到行为b1的通信关联, 行为之间就可以直接发送激励.

Figure 8.6 Behavior bl extends behavior b2.This will normally be implemented with a stimulus being sent from b2 to bl.

In the example of the recycling machine wehave one extension association. We choose to implement this in the mannerdescribed above. The other associations in the model, however, will not bechanged since they are straightforward to implement.

在前面提到的废品回收机的案例中,我们有一个扩展关联.我们将选择上面描述的实现模式来实现扩展关联. 而在模型中其他的关联关系(相识关联), 将不会改变, 因为这些关联关系可以非常直接的进行实现.

In the analysis model we have a conceptualpicture of the functionality. The extension association has come from the Alarmuse case. When an alarm is detected during insertion of items, the Alarm usecase should be inserted. The detection is done by Customer Panel which sendsthe error stimuli to the system. The receiver is now Deposit Item Receiverextended with Alarmist. It is thus Alarmist that will take part in this usecase. The communication association should thus be between Deposit ItemReceiver and Alarmist since this is the way the stimuli will be sent in thedesign. We now have the design model shown in Figure 8.7.

在分析模型中, 我们拥有了系统功能的一个概念图. 其中扩展关联是来自用例模型告警管理(Alarm). 当用户在废品回收机中放置物品发生堵塞进而产生告警的时候, 用例模型告警管理(Alarm)将需要被插入进来. 这种扩展用例的检测是通过顾客操作面板向系统发送错误激励的方式来实现. 这样一来激励信号接收者现在就是控制对象DepositItem Receiver利用控制对象Alarmist实现了扩展操作. 因此控制对象Alarmist将会参与到新的用例模型的执行当中. 因此对象DepositItem Receiver和对象Alarmist之间建立了一种通信关联关系,因为在这样的一种关联关系下在设计模型中将允许激励的发送和控制. 这样一来我们就拥有了在图8.7中所展示的设计模型.

Any inheritance associations must also bereviewed if we cannot implement them in the programming language. Suchassociations can often be designed with a communication association between theblocks. This should then reflect that a stimulus is sent upwards through the'inheritance hierarchy', so it is called 'call-through'. Another possibility isto delete the abstract block and implement this functionality in the concreteblock instead. In the example we will use C++, which supports inheritance. Wewill come back to implementation of inheritance in languages that do notsupport it directly.

Figure 8.7   Therefined design model for the recycling machine. Note the communicationassociation between Deposit Item Receiver and Alarmist.

假如程序设计语言不能直接实现继承关联, 任何一个继承关联关系都必须被重新分析和审视. 这样一种继承关联关系通常被设计成为一种软件功能模块之间的一种通信关联关系. 这种通信关联关系就可以表现成为一个激励信号根据层次化继承关系的规定来上行传送, 因此这种实现继承关系的激励发送也称为是贯穿调用'call-through'.另外一种可行的实现方式是直接删除抽象软件功能模块,而是通过具体软件功能块来代替实现相关的系统功能.在这个案例中,我们将使用C++这种编程方式, 这样一来可以直接支持继承操作. 我们后续还将回来利用不能直接支持继承关联的程序设计语言来实现继承关联关系.

   

The implementation environment for therecycling machine is made very simple. We will run the application in oneprocess only. (In Chapter 9 we will discuss an implementation using severalprocesses.) Also, we will not have a database for persistent data. (In Chapter10 we will discuss an implementation using a relational DBMS.) The programminglanguage will be C++, and this will not normally introduce any seams from thisrefined design model.

我们描述的废品回收机的实施环境会设置的相对比较简单. 我们将仅仅在一个进程中运行对应的系统应用(而在第9章中我们将会讨论使用一种利用多个进程的实现方式). 同时,我们将不会建立一个数据库来支持数据的持久化管理. ( 在第10章中,我们将会讨论一种使用关系型数据库的实现方式). 相关的程序设计语言还是C++, 这样一来就可以根据重构的设计模型实现无缝的应用集成.

What should be reviewed, however, is howthe hardware interface of the recycling machine should be incorporated in theapplication system. This interface can be viewed as an existing productintroduced into the system. Normally these products would yield new blocks toencapsulate the product as discussed previously, but we could also use theblock implementing interface objects as this encapsulating object. We willassume that a primitive software interface to the hardware panel does exist,and we will develop C++ classes that encapsulate this interface.

 

What should be reviewed, however, is howthe hardware interface of the recycling machine should be incorporated in theapplication system. This interface can be viewed as an existing productintroduced into the system. Normally these products would yield new blocks toencapsulate the product as discussed previously, but we could also use theblock implementing interface objects as this encapsulating object. We willassume that a primitive software interface to the hardware panel does exist,and we will develop C++ classes that encapsulate this interface.

那么还有那些内容应当被重点检查呢? 显然, 就是废品回收机的硬件接口应当如何集成到应用系统当中去. 这些硬件接口可以被看成是一个已经存在的外部产品被引入到系统当中. 通常的情况下,这些外部产品将会产生一个新的软件功能块来封装外部引入的产品, 这就正如前面章节中所讨论的一样; 可是我们还有另外一种实现方法, 也就是使用软件功能块来实现接口对象的功能作为对应的封装对象. 我们将假设有一个原语软件接口来操控硬件面板确实存在, 同时我们会开发C++的类来封装这些硬件接口.

We should also mention something about theuse of components. At an early stage it is essential to decide upon whichcomponent libraries to use. This is to encourage the use of components beforethe actual implementation work is done. When a component library exists,investigations should begin early to find out what functionality it will offer.To use a component library effectively, it is essential to be familiar with thelibrary; this will require some time to be spent studying the classes and theiroperations. The use of, and especially finding where to use, components will bediscussed more in Chapter 11. We will assume here that we have a class libraryin C++ for commmon data structures, for instance the NIH library (see Gorlen etal. (1990)). In Chapter 11 we will give some rules of thumb for finding placeswhere components could be used. One of these rules is to look for acquaintanceassociations with cardinality [0..N]. This will typically yield a list or arrayto hold several references. We have this situation in our example, namelybetween Receipt Basis and Deposit Item. Deposit Item Receiver creates oneinstance of Receipt Basis for every new customer. Receipt Basis then holdsreferences to the different Deposit Items that the customer has deposited andalso to how many of each type. Receipt Basis will thus be implemented usingsuch a component. We now have the first sketch of the implementation of theblock Receipt Basis, shown in Figure 8.8. We will come back to the details ofthis issue when we consider the implementation of this block.

我们同时也将提及在设计模型中对组件的使用. 在设计模型的早期阶段, 决定那些组件库将要被使用是一个非常必要的环节. 这样做的目的是为了鼓励组件的使用,并且要求在确切的开始软件集成以前就考虑组件的应用.  当一个软件组件库事先已经存在, 我们需要提前调查来发现这个组件库将会提供那些软件功能. 为了能够更加充分的使用组件库, 充分的熟悉相关的组件库是非常必要的; 这样就需要组件设计师花费一定的时间来研究组件库当中的类和他们对应的操作.  对组件的使用,尤其是发现在哪里使用组件, 将会在第11章中进行更加充分的讨论. 在这里,我们会假设已经拥有一个在C++中的类库实现支持普通的数据结构, 举例子来说是NIHlibrary (see Gorlen et al. (1990)). 在第11章中,我们将给出一些查阅的技巧来发现在设计模型中的哪些地方可以使用组件. 其中一个组件搜索的技巧是查找设计模型中存在的相识关联和他们的基数cardinality[0..N]. 这些相识关联通常会产生一个列表,或者是一个数组来保持几个不同的索引(references). 在废品回收机的案例中,我们就有一个这样的关联场景, 被称为ReceiptBasis 和Deposit Item 之间的关联.  类DepositItem Receiver负责创造类Receipt Basis的一个实例以便服务于每一个新的顾客. 就这样为每一个不同的顾客回收物品(Deposit Items)创建相关的索引,同时也将保持记录每种物品类型中已经回收的数量. 类Receipt Basis就将利用这样的一个组件来进行实现. 我们就这样获得了软件功能块Receipt Basis实现模式的第一种概要的大纲, 详细的实现方式见图8.8所显示. 我们将会返回来针对这个问题进行更加详细的细节, 当我们考虑这个软件功能块的实现方式

The blocks that we have nowidentified will correspond to the modules in which the source code is included.We will later show the files for the block Receipt Basis. In this way theblocks become a way of grouping the source code. These blocks will contain oursource code and our object modules (classes). Since different customers maywant different configurations, different blocks may be delivered to differentcustomers.

在设计模型中已经识别的软件功能块将会对应后续编码阶段的软件模块modules, 在这些模块中将包含相关的源代码.我们后续将显示用于实现软件功能块Receipt Basis 的代码文件.在这样一种方式下,软件功能模块将成为一种组织源代码的方式. 这些软件功能块将包含我们的源代码和我们的对象模块(classes).因为不同的顾客可能会需要不同的配置方式,这样一来不同的软件功能块将可以被交付给不同的顾客.

Before wecan implement the blocks we must describe in detail how they are to communicatewith one another. This is done by defining the stimuli to be sent between them.When we have described the block interfaces completely, we can implement themseamlessly using the rules that describe how the different terms areimplemented in the relevant programming language, as described later.

在可以实现这些软件功能块之前, 我们必须能够详细的描述这些软件功能块是如何互相通信的. 详细的通信方式的定义是通过规定软件功能块之间发送的激励的方式来实现. 当我们已经完整的描述了模块之间的接口以后, 我们可以使用软件功能模块的关联规则来无缝的实现这些软件功能块, 这些关联规则将描述在选择的程序设计语言中如何实现不同的关系.

 

8.2.3   Interaction diagram

8.2.3  交互图

When we have identified the systemarchitecture we describe how the blocks are to communicate. This is done bydesigning the use cases which were described in the analysis phase. Asmentioned before, the use cases constitute the key to OOSE. They control theanalysis phase and structure the analysis model; they are designed in theconstruction phase and define the external requirements on the blocks; theywill be tested in the testing phase to make sure the system is correctly built;and finally, they will be the basis for preparation of the system manual(s).

当我们已经识别出系统的体系结构,我们将详细的描述不同的软件功能模块之间是如何通信的. 这种软件功能模块之间通信方式的定义主要是通过在分析过程中设计用例模型的方式来完成. 正如前面已经提到的,用例模型组成了OOSE方法的关键核心. 他们将控制着分析过程的进展并且将组成分析模型; 用例模型将会在系统构建阶段进行详细的设计,并且将定义软件功能模块的外部需求; 他们还将在测试过程中被测试,以便能够保障系统被正确的进行构建;同时最后阶段, 用例模型将成为准备系统帮助手册的基础.

For each concrete use case we will draw aninteraction diagram. The interaction diagram describes how each use case isoffered by communicating objects. The diagram shows how the participatingobjects realize the use case through their interaction. The interaction takesplace as the blocks send stimuli between one another. As we draw theinteraction diagrams, we will also define all the stimuli, including theirparameters. The main purpose of the use case design is thus to define theprotocols of the blocks.

针对每一个具体用例模型我们将会绘制一幅交互图. 交互图将用来描述每一个用例模型是如何通过一组互相通信的对象来提供实现的. 交互图将会显示这些参与协作的对象是如何通过他们之间的交互通信来实现特定的用例模型. 当不同的软件功能模块之间互相发送激励的时候, 对象之间的交换就会发生.当我们在绘制交互图的时候,我们将会定义所有的激励,包括他们的参数. 设计用例模型的主要目的是这样科学的定义软件功能模块之间的通信协议.

With the use case model we have describedwhat takes place in each use case. The analysis model describes which objectsoffer this behavior. Now, in the design model we refine the description of theuse cases by showing in the interaction diagram how the objects behave in everyspecific use case.

 前期利用用例模型,我们已经描述了在每一个用例模型中发生的事件流程. 其中分析模型描述了那些对象将负责提供这些行为. 现在,在设计模型中我们会对用例模型的描述进行优化, 这种优化主要是通过绘制每一个特定的用例模型的交互图来显示每一个参与对象的行为.

The work on identifying the blocks in thedesign model is performed rather quickly; at best it is done automatically bymeans of a tool. On the other hand, the design of use cases implies a greatamount of work. Here we must define exactly how the participating objects willcommunicate. The descriptions made in analysis, which are the basis of thiswork, may now have to be changed, which in turn may cause a change in thesystem structure. This may then give rise to proposals for changes in theanalysis model or the requirements model.

在设计模型中识别软件功能块的分析工作会相对迅速的开展, 其中最理想的一种方式是利用专门的工具来自动的实现对象的识别. 在另外一方面, 详细设计用例模型意味着一件巨大的工作. 在设计模型中,我们必须详细的定义参与用例模型实现的对象是如何通信的. 在分析过程中已经完成的用例模型, 也就是设计模型的基础, 目前在设计阶段有可能不得不被调整, 用例模型的调整连锁也会引起系统体系结构的改变. 反过来,这也可能会提出建议来修改分析模型或者是需求模型.

Since the work on designing the use casesis done early in construction, we will discover whether the system architectureis good or whether it should be modified at an early stage, when the inherentresistance against changes is low. This means that the architecture has achance to stabilize to a good architecture. Note that this is actually aconsequence of the work done in the analysis phase.

因为对用例模型的详细设计工作是在系统构建的早期阶段来完成, 我们将根据用例模型的细化来判断系统的体系结构是否是合适的;或者他并不合适需要在系统构建的早期阶段进行调整,因为在早期进行调整仅仅需要花费比较小的代价. 这也意味着,系统体系结构能够拥有一个机会来固化成为一个良好的体系结构. 注意,这其实也是分析阶段用例建模型和体系构建工作的一个必然延续

When we design a use case we start byidentifying the blocks participating in the use case. This is easily done bylooking at which blocks offer the use case in the analysis model; thecorresponding objects will be included in the design. This identification istherefore also a completely mechanical process. Furthermore, there may be newblocks introduced during construction (for example, for the implementationenvironment) that should also participate in the use case.

当我们设计一个用例模型,我们从识别参与用例模型实现的软件功能块开始. 通过查找分析模型中那些软件功能块负责提供用例模型将能够非常轻松的完成; 对应的对象将会被包含在设计模型当中. 这种识别工作因此也是一个完全机械的过程. 另外, 在系统构建的过程中也有可能引入新的软件功能模块(举例来说, 为了能够实现环境因素的封装),这些新软件功能模块也需要参加到用例模型当中.

The interaction diagram is a type ofdiagram used for a long time in the world of telecommunications. There it hasthe same function as we are striving for, namely to describe the communicationbetween different blocks.

交互图是一种在电信科学领域已经长期使用的设计图形. 在电信领域中, 交互图也拥有同样的功能,正如我们在OOSE方法中努力设计的一样, 在电信科学中他的用途是用来描述不同软件功能块之间的通信.

Each participating block is represented bya bar. These bars are drawn as vertical lines in the diagram. The order betweenthe bars is insignificant and should be selected to give the greatest clarity.The aim is to obtain a good overview. The skeleton of an interaction diagram isshown in Figure 8.9.

每一个参与的软件功能块是通过一个条行的线来表示. 这些条形的线在交互图中是通过垂直的线来描绘. 在不同条行的线之间的排练顺序是非常无关紧要,同时需要非常清晰的来标识. 设计的目的是为了获得非常良好的总体视图. 一个交互图的草图在图8.9中显示.

If there will be several instances of ablock's classes, we can draw the instances either as different bars or as oneand the same bar depending on which is most legible. All behavior of an objectwill be attached to the bar representing the actual block.

假如存在一个类的多个实例需要参与交互协作, 我们既可以用多个不同的条行的线来表示这些实例, 也可以用同一个条形的线来标识, 这将取决于那一种方式更加清楚. 一个对象所有相关的行为会被添加到条形的线上面来代表确切的软件功能模块.

Figure 8.9 The skeleton for the interactiondiagram for the use case Returning Item consists of bars for each block thatparticipates, and a bar for the system border.

In the interaction diagram we have drawn abar for the Deposit Item. When the use case is carried out, this object willactually be Can, Bottle or Crate. We have therefore also used polymorphism inthe interaction diagram; this is a very useful technique.

 在交互图中，我们已经为对象DepositItem画了个条形的线。当对应的用例模型被启动执行，这个对象有可可能是罐子，瓶子，或者是板条箱。 我们因此也在交互图中使用了多态的技术，多态是一种非常有用的设计技术。

In almost all the interaction diagrams wealso have a bar for the surrounding world, namely for what is outside thatwhich we want to describe. We usually call this bar the system border. This barrepresents the interface with everything outside the blocks in the diagram,such as external actors, and consequently it can correspond to differentinterfaces outside the system. There may be several such border bars.

在几乎所有的交互图中，我们也有一条条形的线来标识系统外部的世界，也被称为是我们希望描述的系统外部的世界。我们通常也把这一个条形的线称为是系统的边界。这一条条形的线也代表了和交互图中对象外部的所有对象连接的接口，比如外部的角色，因此它可以对应不同的系统外部接口。

The time axis in the interaction diagram isviewed as going downwards. The use case thus starts with the behavior describedat the beginning of the interaction diagram. The time axis of the interactiondiagram is not linear, but should be regarded as event controlled. The distancebetween two events in the diagram has no relation to the real time betweenthese events.

在交互图中有个时间轴，他的方向是从上到下延伸的。因此用例模型是根据交互图时间顺序描述的行为开始执行的。交互图的时间轴并不是线性的，而是应当被认为是事件控制的。交互图上2个事件之间的距离和现实系统中事件之间的距离没有必然联系。

At the left edge of the interactiondiagram, to the left of the system border, we describe the sequences. Thisdescription is textual and consists of structured text or pseudo-code. If weuse pseudo code, constructs that exists in the chosen programming languagecould be used. This is to ease our later migration to the currentimplementation. However, it makes us dependent on the specific language. Thetext describes what is happening in this part of the use case. Such a part wecall an operation. We also mark the bar to which the operation belongs with arectangle representing the operation. The textual description consequentlybelongs to the block where the operation takes place and where it will later beimplemented; its bar is therefore marked at the place of the operation. Betweenoperations we may draw horizontal grid lines for clarification purposes. Thistechnique could also be used for any other partitioning of the use case. Thisis shown in Figure 8.10.

在交互图的左边缘，面向系统的左边界，我们将描述事件的序列。这种时序的描述是基于文本的，同时包含了结构化的文本或者是伪代码。假如我们使用伪代码这种方式，已经存在于特定程序设计语言中的构建（constructs）将可以被使用。这样做也是为了简化我们后续将时序图迁移到当前实现的工作量。然而，这也会导致我们在设计阶段依赖了特定的程序设计语言。这些说明文字描述了在用例模型中对应部分发生的事件内容，这样的一部分我们称为是一个操作。我们也将这个操作所归属对象的条形线添加一个长方形来标记，利用这个长方形来表述对应的操作。这些文字描述因此也归属于相应的软件功能块，其中相应的责任软件功能块将是这个操作发生的位置，同时也是后续需要实现目标操作的位置。在不同的操作之间，我们也可以画水平的格线以便清晰的标示相关的操作。这种技术也可以用来其他任何对用例模型的分割处理。详细的图示见图8.10所显示。

 

Figure 8.10 Interaction diagram of the recyclingmachine with operations in the participating blocks. The item axis pointsstraight down. Only part of the use case has been included.

Parallel sequences, such as when severalprocesses participate in a use case, can also be described in the interactiondiagram. This will be further discussed in Chapter 9.

并行的时序操作，比如当多个进程参与到一个用例模型当中的情况，也可以通过交互图来表示。这个问题将进一步在第9章中进行描述。

8.2.4   Definition of stimuli

8.2.4 定义激励

The interaction diagrams are controlled byevents. A new event gives rise to a new operation. These events are stimulithat are sent from one object to another and initiate an operation.

交互图是通过事件来控制的。一个新的事件将会启动一个新的操作。这些事件就是从一个对象发送到另外一个对象的激励，同时将会激活一个操作。

A stimulus is drawn in the interactiondiagram as a horizontal arrow that starts in the bar corresponding to thesending block and ends in the bar corresponding to the receiving block. Mostinteraction diagrams (and thus use cases) start with a stimulus from theoutside: it is drawn from the system border. From the use case description wecan do a use case design. Here is the decription of the use case ReturningItem:

一个激励在交互图上是通过一个水平的箭头来描绘的，这个箭头开始于对应于发送软件功能块的条形线，结束于代表接收软件功能块的条形线。绝大多数的交互图（同时这也是用例模型）是从一个来自外部世界的激励开始的；他、初始激励是来自系统的边界。根据相关的用例模型描述，我们可以开始一个用例模型的设计工作。这里是用例模型ReturningItem的详细描述：

Whenthe customer retuns a deposit item, it is measured by the system. Themeasurements are used to determine what kind of can, bottle or crate has beendeposited. If accepted, the customer total is incremented, as is the dailytotal for that specific item type. If the item is not accepted, the light for'NOT VALID' is highlighted on the panel.

When the customer presses the receipt button, theprinter prints the date. The customer total is calculated and the followinginformation printed on the receipt for each item type:

name

numberreturned

depositvalue

totalfor this type

Finally the sum that the customer should receive isprinted on the receipt.

当用户放置一个回收的物品, 这个物品首先要被系统进行测量. 系统使用这种测量过程来决定那一种类型的瓶子,罐子,或是板条箱被回收. 假如系统接收了物品, 用户返回的物品总量会增加, 同时在日报中对应物品类型的数量也会同步增加. 假如这个物品不被系统所接收, 屏幕上会高亮:” 无效”.

当用户按下收据按钮的时候,打印机将打印出操作日期. 用户返回物品的总数会被计算,针对每种类型物品的收据信息也会打印出来.

 名称

 返回的数量

 收据金额

 这种类型的总数.

最后,用户应当接收的金额也会在收据上显示.

From this description we can develop aninteraction diagram. In this example the interaction diagram will look as shownin Figure 8.11.

根据上面的详细描述，我们可以开发一个对应的交互图。在这个案例中，相关的交互图将如图8.11所显示的样子。

 

The use case starts as the customer insertsa bottle, can or crate into the system. The block Customer Panel is activatedby the sensors that are external to our system. The customer can then continuefeeding in the return bottles, empty cans and crates. This is solved by aDO...WHILE statement that is ended when the customer requests a receipt. Inthis loop we measure the item and check if it is acceptable. If so, weincrement the attribute that knows how many objects the customer has fed in ofeach type, and how many have been fed in in total today. Note that theincrementation of the daily number is delegated to the block Receipt Basis.

这个用例模型首先是从用户把一个瓶子，罐子，或者是板条箱放入到废品回收机当中开始的。接下来软件功能块Customer Panel将会被我们系统外部的传感器所激活。顾客可以继续放入回收的瓶子，空罐子和板条箱。在系统内部，这个持续放入物品的过程是通过一个DO...WHILE的声明操作来解决，直到顾客按下receipt.按钮以后才会结束。在这个循环操作的过程中，我们会对每一个回收物品的尺寸进行测量来判断他是否可以被接受。假如物品被系统所接受，我们将同步的增加对象的属性，这个属性将会记录当天特定顾客回收的每种类型物品的数量，同时也会记录当天之内，每一种类型物品回收的总量。注意，关于增加系统当天回收的物品的总量的操作是委派给软件功能块ReceiptBasis来完成的。

 

When the customer is ready he or shepresses the button for receipt. Deposit Item Receiver receives a stimulus forprinting the receipt and starts by printing the logo and today's date. Then ithands over a stream to Receipt Basis which puts together the information to beprinted and prints it on the stream. (A stream is a buffer to store charactersto be printed.) Finally, the total sum in favor of the customer is printed. Thestream is sent to Receipt Printer for printing. Receipt Basis is then deletedand the Customer Panel is ready for use again.

当顾客已经准备好所有的物品，他将按下对应于receipt 的按钮。软件功能块Deposit Item Receiver 将接收到一个处理打印的激励，同时将开始打印标签和当天的日期。接着他将移交一个流给软件功能块ReceiptBasis ，由这个功能块负责将需要打印的物品信息聚合在一起，并且打印输出到流之上。（A stream 一个流是一个缓冲区来存储哪些需要打印的字符串）.最后，用户获得的回收废品获得资金的总额也会被打印到这个流当中。这个流最后将发送到软件功能块Receipt Printer实现具体打印的功能。软件功能块ReceiptBasis将会被删除和释放，同时软件功能块Customer Panel将转为就绪状态以便用户再次使用。

 

The interaction diagram for Returning Itemsis only drawn for the basic course. Naturally, you must consider faults thatmay occur, for example you may press the receipt button without previouslysubmitting any returnable items but, for overview purposes, this is notconsidered here.

用例模型ReturningItems所对应的交互图仅仅只是描述了基本事件流程。很自然，你必须考虑哪些有可能发生的潜在错误，举个例子来说顾客有可能在没有放入任何物品的情况下就直接按下了receipt按钮，但是，出于简化分析的目的，这些异常流程就不在这里讨论了。

Figure 8.11  Interaction diagram for the use case Returning Item.

When working on the design of the use casesyou will define the stimuli that each object should be able to receive. Thedefinition comprises the name and parameters of each stimulus. Defining stimuliis one of the more critical parts of a development. Since several persons arenormally involved in the design of the use cases, the stimuli to one and thesame block will be designed by different people. The aim should be to reuseexisting stimuli as much as possible. Then it becomes much easier to design theobjects, since the stimuli define the external requirements on each object.When you define the stimuli you should keep the following in mind:

当我们开始进行用例模型设计的详细设计，你将针对每个对象来详细定义他可以接收的激励。关于激励的定义包括每个记录的名字和参数。在OOSE方法中，定义激励是设计过程中的相对重要部分之一。因为通常有几个设计师将会参与用例模型的设计，这样发往一个，也就是同一个软件功能块的激励有可能被不同的人来负责设计。我们设计的目标是尽可能多的复用已经存在的激励。这样一来后续设计过程中面向对象的设计工作就变得非常容易，因为激励定义了每个对象的外部需求。当你开始定义激励的时候，你必须记住以下的要点:

• Reusabilityincreases if we have only a few parameters. Having only a few parameters willmake the stimulus easier to understand and also increases the probability thatstimuli are similar to one another and therefore resuable. A stimulus with manyparameters should be redefined and possibly divided into several stimuli. Thispoint has also been noticed by Johnson and Foote (1988) who also discuss otherrules for obtaining a reusable design.

   假如我们仅仅定义少量的参数，这样将增加激励的可复用性。如果激励仅仅定义少量的参数，这将使得这些激励更加易于理解，同时也增加了激励的可移植性，当一个激励和其他激励类似的情况下；所以也提供了一种可复用性。一个拥有太多参数的激励必须加以优化，同时也有可能分解成为几个不同的激励。这个观点也被Johnsonand Foote (1988)所注意到，他们也讨论了激励设计的原则，以便获得一个可以复用的设计。

•    Stimuli that invoke similar behavior shouldhave the same name regardless of the parameters they contain or which objectsthey are sent to. Hence there is no conflict between duplicate names. Ifstimuli have the same names it is easier to see clearly the similarity betweentwo stimuli.

    哪些调用相同或者相类似行为的激励应该拥有相同的名字，而不需要考虑这些激励所包含的参数，也不需要考虑这些激励将要发送到的对象。因此，经过优化设计以后就不会存在因为名称重复问题所引起的冲突。假如激励之间拥有相同的名字，我们就可以清楚的发现这两个激励之间的相类性。

•    The naming of stimuli should reflect thedistribution of responsibilities between blocks. To make each object asindependent as possible is one of the basic principles in all softwareengineering contexts.

    激励的命名必须能够反映在不同的软件功能块之间相关系统功能的分布。让每一个对象的功能都尽可能的独立是在所有软件工程的理念中一条最基本的原则。

•    Each stimulus should clearly show theexchange of information, that is, the name must be selected carefully. Naming isone of the most difficult skills in programming and therefore rules for thispurpose often exist. The names indicate an intuitive semantics; consequentlythe name is an extremely important aid to understanding and finding stimulithat can be reused.

  每一个激励都应当清楚的显示信息的交换，也就是说，这些激励的命名必须非常慎重的进行选择。通常对操作的命名是在程序设计当中最困难的技能，因此通常在项目中会存在一些对操作进行命名的规范。操作的名称应当指示了一个非常直观的上下文语义；因此操作的名称是一个非常重要的辅助来理解和发现那些可以被复用的激励。

•    Handling and creation of new instances orinitiation of new processes are performed in the same manner as ordinarystimulus handling.

   处理和创造新的对象实例，或者初始化新的进程也要参考普通的激励收发处理的模式来设计和管理。

The description of a use case is normallydivided into basic courses and alternative courses. The basic course is themost common (important) sequence in the use case. It is always designed first.The alternative courses constitute all other sequences that the use case canfollow, typically fault-handling sequences. When the basic course has beendesigned, you continue with the alternative courses. The aim is to describe asmany alternative sequences as possible. The more alternative sequences wedescribe, the more sequences have been anticipated and hence the more we haveincreased the robustness of the designed system.

对一个用例模型的描述通常会划分为基本的事件流程和可选的事件流程。其中基础事件流程是那些在用例模型当中最常见（重要）的事件序列。他通常是最先开始设计的。而可选的事件流程则包含了所有其他的事件序列，这些事件序列可以供用例模型来执行，通常是异常处理的事件序列。当基础事件流程已经设计完毕，你就需要开始设计可选的事件序列。设计的目标是尽可能多的描述各种可能的可选序列。可选的事件序列描述的越多，那么就可以预计到更多的事件流程，因此我们也就能够有效的提高设计系统的稳健性。

 

A stimulus can have different semantics,for example be either interprocess or intra-process communication. Anintra-process stimulus is a normal call inside one process. We normally callthis kind of stimulus a message. A message corresponds to a message inSmalltalk or invoking an operation in Eiffel or C++. That is, it is the normalmode of communication in object-oriented languages. An interprocess stimulus isa stimulus sent between two processes. We usually call such a stimulus asignal. Signals may be either synchronous or asynchronous (the execution of thesender continues directly alter the signal is sent). In Ada, the rendezvous mechanism

Figure 8.12 Different kinds of stimuli may be used in OOSE.Messages are infra-process and signals are interprocess communication.

for communicationbetween tasks is synchronous; one task must wait for the other task to finish.In, for instance, CHILL (see CC1TT (1984)), a programming language used in theworld of telecommunications, signals are asynchronous; when a signal is sent thesender continues its execution immediately and does not wait for the receiver.The receiver may be active when the signal arrives and therefore the signalmust be queued at the receiver until processed.

  一个激励也可以具有不同的应用上下文语义，举个例子来说，可能是进程间通信，或者是进程内通信。一个进程内的激励通常是进程内部的一个普通调用。我们也常常把这种类型的激励称为是一个消息a message。一个消息对应着Smalltalk 编程语言中的一个消息，或者是在Eiffel 或者 C++中调用一个操作。也就是说进程内的激励是面向对象的程序设计语言中一种正常的调用模式。而一个进程间的激励是一个在两个进程之间发送的一个激励。我们通常把他称为是一个信号a signal。信号的发送可能是同步也可能是异步asynchronous的（信号发送以后，发送者的操作执行会继续进行）。

Figure 8.12 Different kinds of stimuli may be used in OOSE.Messages are infra-process and signals are interprocess communication.

在ADA中，任务间的约会通信机制rendezvous就是同步的，一个任务必须等待另外一个任务执行完毕。而在CHILL当中，CHILL是一种在电信科学领域中广泛使用的程序设计语言，举例来说，信号的发送则是异步的；当一个信号已经发送完毕以后，信号的发送者将立即执行后续的操作，而不需要等待信号接收者的响应。当信号到达以后，信号的接受者将会被唤醒并执行对应的操作，因此信号发送以后会先放置到一个缓存队列当中，直到发送者可以处理这些信号。

Generally, the concepts used in OOSE aregeneric terms. When we specialize OOSE for a specific implementationenvironment we should use the concepts of the implementation environment. Forinstance, when working with Ada,we should talk about rendezvous mechanisms instead of signals.

一般来说，OOSE所用概念是通用的术语. 当我们面向特定的而集成环境适配OOSE方法，我们就应当遵循当前的集成环境中所使用的概念。举个例子来说，假如我们是利用Ada进行程序设计，我们就应当用约会机制rendezvousmechanisms来代替信号的说法。

 

Messages and signals will be used in thisbook and will be drawn differently in the interaction diagram, as shown inFigure 8.12. Messages are drawn with a closed arrow and signals with an openarrow.

消息和信号将会在OOSE这本书中进行使用，并且会直接在交互图中进行描绘，他们的标记方式是不同的，详细的图标见图8.12所显示。消息是通过一个封闭的箭头来描述，而信号时通过一个开放的箭头来描绘。

If necessary, the exact semantics of thestimuli should be specified from project to project. For instance, differentkinds of synchronization or time-out should be specified when necessary. Thenagain, the chosen operating system or the programming language's propertiesshould normally be used. We will discuss the use of signals further in Chapter9. In this chapter we will assume that all stimuli are messages.

    如果需要的话，关于激励的确切的上下文语义应当根据项目的不同来详细的进行定义和制定。举个例子来说，如果需要的话，不同类型的同步机制，或者是超时机制需要被详细的定义。另外，相关选择的操作系统，或者是编程语言的特性也通常需要被使用。我们将在第9章中更加深入的讨论信号的使用。在这一章中，我们将假设所有的激励都是消息。

8.2.5   Structure of interaction diagrams

8.2.5 交互图的结构

Interaction diagrams give the designer aunique ability to see the entire sequence in a use case at an overview level. Thedesigner can therefore quickly get a picture of how the sequence progressesover the objects participating in the use case. We can also quickly see whatthe structure of the use case looks like. This structure often tells us a lotabout the realization characteristics of the use case. Here we can, inprinciple, validate the structure of the use case that was defined in theanalysis model. We will now look at a use case that is designed in twofundamentally different ways.

交互图为系统设计者提供了一种独一无二的能力来观察一个用例模型的完整的事件操作顺序，并且这种观察是在一个总体概貌的层面。因此，系统设计者可以非常迅速的针对一个用例模型中所有参与协助的各个对象操作时序描绘出一幅清晰的图画。 我们也可以非常迅速的发现用例模型的结构是什么样的。这种结构也会向我们揭示很多用例模型的实现特点。在交互图当中，我们可以，从原则上来说，验证在分析模型中定义的用例模型的结构是否正确。我们现在来看看一个用例模型基于两种根本不同的方法设计的差异。

 

The use case is based on a real applicationand is built to handle a warehouse with automatic trucks that move pallets. Atechnician gives an order specifyingonly when the pallet is Located and where it should be moved to. All loadsare placed on pallets that can be movedaround automatically in the warehouse. Since the pallets are movedautomatically, the loads must be checked at intervals, say every tenth move, tomake sure that the loads are still stable on the pallet. We must therefore keepin mind how many times a specific pallet has been moved. We will now design the use case to move a pallet. This is done bydrawing an interaction diagram for it. We will look at two different variantsfor implementing this.

这个用例模型是基于一个真实的应用案例，他是用来处理一个利用自动卡车来管理移动货物托盘的物流仓库。首先技术管理人员会提供一个任务单，这个任务单会定义这个货物托盘放置到仓库中的时间，以及这个货物托盘将要移动去往的位置。所有的货物负载都可以放置在托盘上，这样一来就可以在仓库中自由的进行移动。因为货物托盘一直在仓库中自动的进行移动，托盘上的货物负载就必须定时进行监测，一般来说货物托盘每移动10次就需要检测一次，以保证托盘上的货物还是稳定和可靠的。 因此，我们必须清楚的掌握具体每个托盘已经被移动的次数。我们现在将设计一个用例模型来移动一个货物托盘。相关的用例模型的设计方法是通过一描绘一个交互图来实现。我们将看看两种不同的实现方式。

 

Figure 8.13 shows the first case. The usecase starts as the technician sends a stimulus to Transporter. Transporter then asks Pallet howmany times it has been moved. If it has been moved the maximum number ofpermitted times we must check whether the move is to be made in the warehouseor whether it is to be made to a checking station. If it is to a checkingstation we can make the move, otherwise we must not move the pallet.

 图8.13显示了第一个用例模型。这个用例模型是由技术人员向运输车发送一个激励信号开始的。运输车将询问移动托盘他当前已经移动的次数。假如话务托盘移动的次数已经到达最大的允许门限，我们必须检查托盘的是准备移动到仓库当中，还是准备移动到一个检查工作站当中。假如货物托盘是准备移动到一个检查工作站，我们可以执行相关的移动操作，否则我们就不能移动货物托盘。

 

In this interaction diagram we can see thateverything is handled and controlled by Transporter. This object controls the flowand operates on the other objects, and then it decides what to do. This objectmust therefore contain rules for moving a load. We have a centralizedstructure.

Figure8.13   Transport with the Transporter controlling thedetailed flow.

In this interaction diagram we can see thateverything is handled and controlled by Transporter. This object controls the flowand operates on the other objects, and then it decides what to do. This objectmust therefore contain rules for moving a load. We have a centralizedstructure.

在这幅交互图当中，我们可以发现所有的控制和操作是由对象运输车来管理。这个对象负责控制事件的流程和对其他对象施加操作，同时由运输车来决定后续的操作。、因此这个对象也必须保护用来移动货物负载的规则。我们就这样获得了一个集中化的体系结构。

In the second design, shown in Figure 8.14,we have delegated the decision as to whether the Pallet can be moved or not to Pallet itself.Transporter nowonly asks whether the load can be moved or not. Pallet now checks whether it ispermitted to move the load and whether it will be moved to a checking stationor not. It only replies yes or no to Transporter, and then Transporter movesthe load if this is possible.

 Figure 8.14  Ause case design where the pallet itself knows if it can be moved.

在第二种设计当中，正如图8.14所显示的，我们把货物托盘是否能够接收货物的决定权利授权给了货物托盘自己。对象运输车仅仅需要询问货物托盘是否接收货物。由货物托盘自己负责检查他当前是否允许接收货物，或者他是否需要移动到一个检查工作站当中去。这样货物托盘仅仅需要向运输车回答是或者否的问题，接下来如果可能的化，运输车则负责向移动托盘转移相关的货物负载。

     Here we can see that the decisions aredecentralized and are made by the unit knowing the conditions, in our casePallet. Transporter is only interested in whether the pallet can be moved ornot, and has now been freed of knowing under which conditions the load can bemoved. We have a decentralized structure.

     在第二种方案中我们发现决策判断是分散管理的，也就是哪些了解当前环境的责任单元来负责判断，在这个例子当中就是货物托盘。运输车仅仅需要关心货物托盘是否可以正常移动，因此他不需要关心在什么条件下货物负载可以被转移。我们因此获得了一个分布式的控制结构。

The difference between these use cases isactually fundamental and it has already come about in the analysis phase wherewe have allocated the use cases to the analysis objects. Which of the use casedesigns is actually more sensitive to changes? Let us assume that we want tomove painted bicycles in the warehouse. The bikes must not be moved until theyhave dried, perhaps for six hours. Therefore, we must add a check of attributesthat keep track of whether there is a painted bike on the pallet and how longago it was painted. These attributes belong to the bike, but must be checked byPallet. In the first use case design we must make changes in both Transporter(which must ask Pallet what it contains) and Pallet (where we must add newattributes). In the second design we only have to make changes in Pallet (wherewe add the attributes and the checking required).

这两种不同的用例模型的实现方式的差别是非常根本的，同时这种实现的差别在分析模型阶段已经充分的呈现，在分析模型阶段我们已经将用例模型的功能分布到分型模型相关的对象当中。那么那一种用例模型的实现方案对未来潜在的变化会更加敏感一些呢？让我们假设一种情况，假如我们希望在仓库中移动一些刚刚油漆过的自行车。这些自行车必须先放置到6小时以后，才能够被移动到货架上去。因此，我们必须增加一个对属性的检查，这个属性负责跟踪是否有一个刚刚油漆好的自行车放置在货物托盘上，以及这个自行车当前已经油漆好的时间。这些属性属于对象自行车来管理的，但是同时他又必须被货物托盘所检查。在第一种用例模型的设计方案中，我们必须同时改变运输车（他必须询问货物托盘当前包含的详细货物）和货物托盘（针对这个对象，我们需要增加新的属性）。而在第二种设计方案中，我们仅仅需要改变货物托盘（其中我们增加新的属性和需要的检查操作）

 

In the interaction diagram, we can see thestructure of the use cases very clearly. The interaction diagram helps us toassess how decentralized the system is. We can distinguish two extreme types ofstructure for interaction diagrams (see Figure 8.15).

在交互图当中，我们可以非常清楚的看到用例模型的结构。交互图将帮助我们评估系统是否已经实现了去集中化，也就是功能合理分布化。我们可以清楚的区分交互图当中两种非常极端的类型。（参考图8.15）

The first extreme we call a fork diagram. This type is characterizedby the fact that it is an object acting like a spider in a web and so controlsthe other objects. Much of the behavior is placed in the controlling objectwhich knows all other objects and often uses them for direct questions orcommands.

 第一种极端的情况我们成为是一种分支图a fork diagram. 这种类型的时序图的特点是存在一个核心对象, 这个核心对象的作用就象是一张蛛网中心的那个蜘蛛,同时他负责控制其他的对象. 绝大部分的行为被放置在这个控制对象当中, 而这个控制对象知道其他所有的对象,并常常直接调用其他的对象.

A fork diagram indicates a centralizedstructure. Typically the control sequence is placed in one object, often acontrol object. The other objects are typically used as information carriers oras an interface, to a user. A fork structure often places great responsibilityon the designer of the controlling object, since this often becomes much morecomplex than other objects.

一个分支图a forkdiagram显示了一种集中化的体系结构.一般来说用例执行相关的控制顺序被放置在一个对象中,通常这是一个控制对象. 而其他的对象通常是作为一种信息载体来使用,或者是一个面向最终用户的接口对象.一种分支结构通常会要求设计者花费巨大的精力来详细设计控制对象,因为这个控制对象通常远远比其他的对象要复杂.

The other extreme we call a stair diagram.This type is characterized by delegated responsibility. Each object only knowsa few of the other objects and knows which objects can help with a specificbehavior. Here we have no 'central' object.

另外一种极端情况我们称为是一种阶梯图. 这种时序图的特点是将用例模型相关的功能授权给不同的对象. 每一个对象仅仅了解其他少量的对象,同时他知道针对一个特定的功能可以关联到那一个对象来提供服务.在这种场合下,我们就没有一个’中央’的对象.

Stair diagrams often indicate adecentralized structure. Each object has a separate task and it only knows thesurrounding objects it needs in order to get help in carrying out this task.

阶梯图通常显示了一种非中心化(分布式)的体系结构.每一个对象都负责完成一个分离的任务,同时他仅仅知道和自己相关的周围对象, 借助这些对象的协助就能够完成自己的目标任务.

Which of these two types should be chosen?Which is better? Often it is claimed that the stair structure is moreobject-oriented and thus better. The more the responsibilities have been spreadout, the better. However, this is not always true. What we want is to be ableto introduce changes easily and also to design reusable objects and stimuli.Different kinds of change can of course occur.

那么我们具体应该选择哪一种类型的时序图呢? 那一种类型的时序图更好一些呢? 一般来说这种具有阶梯图特征的体系结构被宣称为具有更多的面向对象的设计特点,所以具有更好的可扩展性.用例模型的功能被更多的授权到不同的对象当中,也就获得了更加易于扩展的结构. 然而,这种理论上的观点也不是在所有的场合中都是正确的. 我们所希望的是能够引入一种容易改变的体系结构,同时也能够设计出可以高度复用的对象和激励. 不同类型的系统功能改变可以理所当然的发生和实施.

 

Figure 8.15 The interaction diagrams show clearly whatthe structure of the use case looks like. The extreme points are the forkstructure and the stair structure.

To handle changes in how a sequence isactually performed, you should encapsulate the actual sequence and thus obtaina decentralized structure. If you want to change the actual order of theoperations, it is better to have a centralized structure, since then suchchanges will be local to one object. We thus see that both structures havetheir benefits. What is crucial is whether the operations have a strongconnection to each other. A strong connection exists if the objects:

如果希望处理好一个用例操作时序过程当中不同步骤的确切执行方法的可变性, 你就应该将确切的操作顺序进行封装同时将会获得一个非集中式的体系结构. 而假如你希望改变用例时序中不同操作的执行顺序, 那么最好能够设计出一种集中式的体系结构, 因为在这种情况下,操作顺序的改变可以局部限制在一个对象当中.我们因此可以发现两种不同的体系结构都有各自的优点. 判断的关键是在于相关对象之间的操作是否具有很强的相关的性. 假如对象之间拥有以下的特点就是存在一种强关联:

•    Form a 'consists-of hierarchy, such ascountry-state-city;

•    Form an information hierarchy, such as document-chapter-section-paragraph-character;

•    Represent a fixed temporal relationship, suchas advertisement-order-invoice-delivery-payment;

•    Form a (conceptual) inheritance hierarchy, suchas animal-mammal-cat.

•    构成一种组成层次关系,比如国家- 省-城市;

•    构成一种层次化信息结构,比如文件-部分-章节-段落-字符;

•    代表了一个固定的短暂存在的关系,比如;广告-订单-进货-交付-付款;

•    构成了一种层次化的继承(概念上的)关系,比如动物-哺乳动物-猫.

 

We have found thefollowing principal rules:

我们也发现了以下的一些时序图设计的原则性规则:

A decentralized(stair) control structure is appropriate when:

-    the operations have a strong connection (seeabove);

-    the operations will always be performed inthe same order.

一种非中心化(阶梯)的控制体系结构在以下的场景中会比较合适:

<!--[if !supportLists]-->-          <!--[endif]-->操作之间具有很强的相关性(参考上面的说明);

<!--[if !supportLists]-->-          <!--[endif]-->相关的操作通常是根据相同的顺序来进行执行.

 

•    A centralized (fork) control structure isappropriate when:

- the operationscan change order;

- new operationscould be inserted.

一种中心化(阶梯)的控制体系结构在以下的场景中会比较合适:

<!--[if !supportLists]-->-          <!--[endif]-->操作的顺序总是会发生改变.

<!--[if !supportLists]-->-          <!--[endif]-->新的操作有可能会被插入.

This also leads to the conclusion thatthese two structures very well may be, and indeed should be, combined to yielda stable and robust structure.

上面的分析也导致了如下的结论: 这两种时序结构有可能,也应该, 联合使用以便获得一个可靠和稳健的体系结构.

We see here that the ordering of operationsis also a potential source of changes. We cannot regard behavior or data from arobustness viewpoint alone, but also need to consider ordering. The naturalsolution for robustness is normally to encapsulate things that can be changed.Hence we should also be able to encapsulate ordering of operations. That isexactly what is done in the centralized approach, where we have the ordering ofoperations defined in only one object.

    在这里我们发现用例模型操作的顺序也是存在一种潜在改变的可能性. 在OOSE的设计方法中,我们不经仅仅考虑对象行为和数据结构的可靠性和稳定性. 出于系统稳健设计角度考虑的一种直观解决方案是将那些存在潜在变化的部分尽可能的进行封装处理. 因此,我们也有可能封装用例相关操作的顺序. 那就是在集中化方案中采用的方案,  在集中化的方案中,我们把操作的顺序仅仅定义在一个对象当中.

8.2.6   Use cases with extensions

8.2.6   具有扩展关系的用例模型

The possibility of using one use case toextend another use case is described by means of an extension associationbetween the two use cases. In the interaction diagram this is described by aprobe position. A probe position indicates a position in the use case to be extendedand is often accompanied by a condition which indicates under whatcircumstances the extension should take place. The probe position is describedin the interaction diagram of the extension use case and it indicates aposition in the interaction diagram of the use case to be extended. The probethus belongs to the extending use case and not to the one to be extended; thisis to avoid changing the original use case when new extensions are added. Theposition indicated by the probe is some point in the description of anoperation in a block (see Figure 8.16).

在用例建模的过程中我们有可能使用一个用例模型来对另外一个用例模型进行扩展，这种扩展的描述方法是通过在2个用例之间建立扩展关联关系来实现。在交互图中，用例之间的扩展是通过一个探针位置来进行描述的。. 一个探针位置指示了一个用例中具体的位置可以实现用例扩展，而在探针位置通常会伴随一个附件的判断条件，这个判断条件将会说明在什么样的条件下用例扩展将会发生。这个探针位置会在扩展用例模型的交互图中进行描述，同时他表明了在交互图中实现用例扩展的一个具体位置。一般来说，探针位置归属于正在进行扩展的用例模型，而不属于哪个被扩展的用例模型；这样做的目的是为了避免对原有用例模型的改变，在有新用例模型扩展的情况下。而通过探针指示的扩展点通常是在一个软件功能块的一个操作描述的一些位置点(see Figure 8.16)。

The semantics of a probe is as follows. Theoriginal use case runs, obeying its description. When the use case reaches theprobe position, it checks whether the extension condition is true. If it is,the use case now starts to follow the extension use case's description. When itreaches the end of that description, it returns to its original description andcontinues where it left off。

关于一个探针的上下文语义通常会描述如下。初始的用例模型首先开始运行，遵照相关的用例模型描述。当这个用例模型运行到相应的探针的位置时，他将检查用例扩展判断条件是否成立。假如扩展判断条件成立；用例模型的执行将进行跳转，并开始根据扩展用例模型的描述来进行执行。直到用例的执行到达扩展用例模型的终点，用例执行序列将会返回到初始的用例模型的挂起位置，并根据初始用例模型的描述继续恢复进行执行。

The description of the Item Stuck use casethus extends the description of Returning Item. The probe position thereforerefers to a place in the description for Returning Item. During execution, theprobe gives the place where the Item Stuck behavior is inserted.

用例模型ItemStuck的详细描述就是通过这种方式对用例模型Returning Item进行了扩展。因此，该探头的位置是指的是在用例模型ReturningItem的详细描述当中。在用例的执行过程中， 相关的探针给出了扩展用例模型ItemStuck的行为插入的具体位置。

The use case Item Stuck will extendReturning Item when an item is stuck. From the description in the interactiondiagram we shall be able to find exactly where the probe is to be inserted. Wedescribe Item Stuck in just the same way as other use cases. The description ofReturning Item has not been affected and hence can be described independentlyof Item Stuck.

当用户回收物品时发生物品堵塞的情况下， 用例模型ItemStuck将会扩展用例模型Returning Item。根据相关时序图的描述，我们可以非常清楚的找到具体用例扩展的探针位置。我们也采用标准的用例描述方法来对用例模型Returning Item进行描述。 而用例模型ReturningItem的描述是没有受到任何影响的，因此可以独立于用例模型Item Stuck来进行描述。

Figure 8.16 Theuse case Item Stuck has a probe position Alarm. The new behavior is inserted alI he probe position.

 

8.2.7 Homogenization

8.2.7 归一化

The use cases are normally designed inparallel and by several designers who can work more or less independently ofone another. This means that stimuli are defined by several differentdesigners. Normally you should agree on the definition rules for stimuli, atleast in the project or for the product, but preferably in the entireorganization. We have discussed earlier how stimuli can be handled uniformly,but despite this there will still be stimuli with the same meaning or purposebut with different definitions. We therefore have to homogenize all stimuliwhen the use cases have been designed. Homogenization can of course also bedone as the work on the design of use cases proceeds.

用例模型通常是由几个设计师并行设计的，而这些设计师的设计工作通常在一定程度上是完全独立进行的。这也就意味着多个对象发送的激励通常是由几个不同的设计师来定义的。通常不同的设计师应该同意并遵守关于对象激励的定义规则，至少在面向一个产品的项目中，然而最好是能够在整个组织当中保持相同的激励定义规则。我们前期已经讨论过如何在面向对象的系统中保持激励应用的一致性, 但是尽管如此还是存在一些具有相同功能或者是相同含义的激励,而这些激励的定义却不完全相同. 因此当所有的用例模型都已经设计完毕以后, 我们需要进一步对所有的激励进行归一化的处理. 激励的归一化设计也可以作为用例模型设计的一个必要环节.

Homogenization means that we try to get asfew stimuli as possible, all of which should be maximally reusable and easy towork with. What we should strive for is a set of powerful stimuli that can bereused. Sometimes it may be sufficient to change the name of a stimulus or tochange the parameters, but we may also have to divide some stimuli or create acompletely new set of stimuli. This new set of stimuli must (of course) havethe same power of expression as the old set, but should consist of as fewstimuli as possible.

激励的归一化处理就意味着我们希望最终获得尽可能少的激励, 这样一来所有的激励都可以最大限度的进行复用, 同时可以非常容易的设计与实现. 在OOSE的设计过程中,我们需要努力争取的目标是获得一套强有力的激励, 可以在系统开发中充分的复用. 在归一化的过程中,有时仅仅需要改变一个激励的名称或者是改变激励的一些参数, 而有些情况下我们不得不对一些激励进行分拆,或者是创建一套全新的激励.这一套新设计的激励必须(也理所当然)和原有激励集合一样表达相同的含义, 但是尽可能的包含了更少的激励数量.

 

For instance, imagine you have thefollowing set of stimuli defined on an object Person by different developers:

举个例子来说, 假设你已经获得了如下面向对象Person所定义的一套激励(操作指令),而这些激励是由不同的设计者所设计的:

 

What_is_your_phone_number?

Where_do_you_live

Get_address

Get_address_and_phone_number

These could behomogenized to:

这些激励可以归一化为如下的激励:

Get address

Get_phone_number

We have reduced the number of stimuli, butwe can get everything that we got with the first set of stimuli. It must bedecided from time to time on which level the stimuli should be defined. It isvery hard to give any strict rules, but reusability and robustness should bethe main criteria.

我们已经尽可能的减少了对象所拥有激励的数量, 可是我们也可以利用最初设计的一组激励实现所有需要的功能. 因此系统设计者必须不断(from time to time)的分析和评估在那一种合适的级别上对激励进行定义. 通常很难给出任何严格的规则, 但是重用性和稳健性是首先需要考虑的主要因素.

You can compare homogenization with homogenizationin mathematics, but you should normally not be as strict as to require allstimuli to be orthogonal in an information space. The reason is that we alsoset the requirement that our stimuli must be efficient. To send a stimulus isperhaps very expensive (in some sense). So it may be preferable to keep a morecomplex stimulus than to divide it into more homogenized stimuli which willalways be used together. An important criterion in homogenization is consequentlyhow the stimuli are to be used. The purpose of homogenization is to prepare fora not-too-complex block design - all operations that the stimuli should triggermust be implemented later.

你可以将面向对象设计中的归一化设计和数学科学中的归一化设计进行比较, 但是你并不需要非常严格的要求在一个信息空间中的所有激励(指令操作)具有完全的正交特性(orthogonal).这种变通设计方法的原因是因为我们也需要激励的功能定义必须是完备的. 通常对象发送一个激励往往会是非常昂贵的(在某种意义上来说). 因此在OOSE的设计方法中推荐设计一个相对复杂结构的激励,他将优于一个复杂激励划分为具有更加正交特性的激励, 这些具有更加正交特性的激励通常需要一起使用. 激励归一化设计以后需要考虑的一个重要因素就是这些激励应当如何使用. 对激励进行归一化设计的目的是为了保持一种相对简单的软件功能块的结构—因为所有需要被激励触发的操作后续都需用被在软件功能块中进行详细实现,

In the same manner as we homogenizestimuli, we should review all the use cases to see whether we can find commonbehaviors that we missed earlier. Subsequences can perhaps be taken out, andmaybe we will find common parts of use cases not discovered during the analysisphase (typical examples are fault handling in different situations).

   基于同样的模式,我们会对系统的所有的激励(指令命令)进行归一化的处理, 我们应当对所有的用例模型进行全面的回顾,以便我们来发现前期是否存在一些忽视的公共行为. 后续有可能会有一些公共子序列被分离出来, 同时我们可能发现在分析阶段中忽略的用例模型的那些公共部分.(典型的例子就是在不同场景下的错误处理功能)