[译]OOSE第7章：Analysis 分析 7.3 The analysis model 分析模型 & 7.4 Summary

 

7.3 The analysis model

7.3 分析模型

When the requirements model has been developed,and often also signed off by the orderers, we can focus on the structuring ofthe system. This is done initially by developing the analysis model. In theanalysis model we describe the system using three different types of object:interface objects, entity objects and control objects (see Figure 7.12). Eachof these objects has its own purpose and will model one specific aspect of thesystem. We also use subsystems to group these objects into manageable units.

 当需求模型已经完成开发,并且已经被系统订购者签字确认以后,我们可以专注于系统的体系结构.这通常是从开发系统的分析模型开始的.在分析模型中,我们使用几种不同类型的对象:接口对象, 试题对象和控制对象(参考图7.12). 这些对象中的每一个都有他自己特殊的目标,并且将能够对系统一个特殊的方面进行建模.我们也可以使用子系统的概念来组织这些对象成为一个可以管理的单元.

In therequirements model we have specified what is to take place within the system.The analysis model aims at creating a good platform for the system design andwill also form the basis of the design. The requirements model is thus structuredby the analysis model.

Figure7.12 The object types used to structure the system in the analysis model.

   在需求模型中,我们已经定义了应该在系统内部发生的事情.分析模型的目标是在于为系统设计创造一个好的基础平台,同时也希望构成后续设计的基础. 这样一来需求模型将通过分析模型来进行结构设计.

The work in developing the analysis modelreally entails distributing the behavior specified in the use case descriptionsamong the objects in the analysis model (see Figure 7.13). An object can becommon to several different use cases. Thus we should state explicitly whichobject is responsible for which behavior in the use case. This does not meanthat the behavior must be broken down into operations at this stage, althoughthis is possible. A more natural procedure is to write a verbal description ofthe responsibilities of or roles played by each object.

开发分析模型的工作需要将那些在用例模型描述中定义的行为确定的分布到分析模型中不同对象之中(see Figure 7.13).一个对象能够供几个不同的用例模型来公共使用.因此,我们必须清楚的描述每一个对象和用例模型的每一个行为的对应关系.这样做并不是意味着在这个阶段我们必须将用例模型中的行为细分为对象的操作方法,虽然这也是有可能的.一个更加自然的处理过程是写下一个每个对象需要执行规则或者是承担职责的动词列表.

We will now study the different objecttypes more closely and discuss how it is possible to find them from the usecases.

我们将更加深入的研究分析模型中不同类型的对象,同时将讨论如何在用例模型中寻找这些对象模型.

Figure7.13 Use cases and objectsare different views of the same system. An object can therefore typicallyparticipate in several use cases.

 

7.3.1   Interface objects

7.3.1 接口对象

All functionality specified in the use casedescriptions that is directly dependent on the system environment is placed ininterface objects. It is through these objects that the actors communicate withthe system. The task of an interface object is to translate the actor's inputto the system into events in the system, and to translate those events in thesystem that the actor is interested in into something which is presented to theactor. Interface objects can, in other words, describe bidirectionalcommunication between the system and its users.

在用例模型中定义的所有与系统环境直接相关的功能将放置在接口对象中.角色和系统之间的通信需要利用这些接口对象的功能来支持. 接口对象的任务是把用户的输入信息转化为系统内部的事件序列;同时将系统内部那些用户可能感兴趣的事件转化成为一些直接呈现给用户可见的事物.接口对象可以,换句话说, 来描述用户和系统之间的双向通信.

Interface objects are quite simple toidentify. We have at least three strategies. Either they are clearly identifiedfrom the system interface descriptions accompanying the requirements model, orwe can start from the actors, or we can read the use case descriptions andextract the functionality that is interface-specific. Let us initially use thesecond alternative, namely to start from the actors.

接口对象是非常易于被识别的.我们至少拥有3种策略来识别借口对象. 一方面接口对象可以通过伴随着需求模型的接口对象描述来识别, 或者我们可以从角色开始,或者我们可以阅读用例模型描述同时抽取那些和接口特定相关的功能. 让我们最开始使用第二种分支策略, 被称为从角色开始.

Each concrete actor needs its own interfacefor its communication with the system. In many cases an actor may need severalinterface objects. In the example of the recycling machine, each of theconcrete actors, Customer and Operator, needs its own interface object to thesystem. The Customer needs the panel with the push-buttons and the slots inwhich to insert the items and the Operator needs his interface to be able tochange information in the system and to generate daily reports. Furthermore, weneed an interface object to call the Operator when an alarm is issued, as wellas one to print out a receipt. We thus have the interface objects shown inFigure 7.14. Finding an interface object for an abstract actor does not alwaysoccur, as in this case.

每一个具体角色需要他自己特定的接口对象来实现和系统进行通信.在很多情况下,一个角色往往可能需要很多不同的接口对象. 在前面提到废品回收的案例中, 每一个具体角色,顾客和系统管理员都需要各自面向系统的接口对象.角色顾客需要装有”推送 “按钮的操作面板和一些可以用于放入物品的槽位;而角色系统管理员需要他自己的接口对象来实现改变系统内部物品资费,和生成日报.此外,我们还需要一个接口对象,实现每当一个告警发出的情况下能够呼唤系统管理员,以及有人希望打印一个收据.综合上面的分析,我们将拥有一个如图7.14所显示的接口对象模型. 而在这个案例中, 为抽象角色来寻找接口对象的工作则是不太需要的.

Let us now look at the third strategy,namely to identify interface objects from the use case descriptions. We havemarked the places in the use case description below where interfacefunctionality is involved. Note that the use case description has been takendirectly from the requirements model.

让我们现在看看第三种策略,根据用例模型的描述来识别接口对象.我们已经将用例模型“当用户放置一个回收的物品, 这个物品首先要被系统进行测量. 系统使用这种测量过程来决定那一种类型的瓶子,罐子,或是板条箱被回收. 假如系统接收了物品,用户返回的物品总量会增加, 同时在日报中对应物品类型的数量也会同步增加. 假如这个物品不被系统所接收, 屏幕上会高亮:” 无效”.”

的文字段落下方进行了标识.请大家注意一下,这些用例模型描述是直接从需求模型中提取的.

When the customer returns a deposit item,it is measured by the system. The measurements are used to determine what kindof can, bottle or crate has been deposited. If accepted, the customer total isincremented, as is the daily total for that specific item type. If the item isnot accepted, the light for 'NOT VALID' is highlighted on the panel.

When the customer presses the receiptbutton, the printer prints the date. The customer total is calculated and thefollowing information printed on the receipt for      each item type:

name

number returned

Figure 7.14 We have four interface objects in the recyclingmachine: Customer Panel, Operator Panel, Receipt Printer and Alarm Device.

deposit value

total for thistype

Finally the sum that the customer shouldreceive is printed on the receipt.

 

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

 

 

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

 名称

 返回的数量

 收据金额

 这种类型的总数.

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

 

We see that this technique yields the sameinterface objects, namely Customer Panel and Receipt Printer for this use case.

我们可以看到采用第二种技术也产出了相同的接口对象, 被称为客户面板和数据打印机,这两个接口对象将服务于顾客相关的用例模型.

The following is a short description of theinterface objects identified:

Customer panel

The functionalitythat manages the sensors in the deposit slots, start button and receipt button.

Operator panel

Interface forchanging information in the system and for generating daily reports.

Alarm device

Controls a signaldevice and also has a reset button for that device.

Receipt printer

Writes text on apaper roll. After printout the paper is cut off. When the paper roll is almostlinishod the operator should be called through the alarm device.

 

 

下面是关于识别出来的接口对象的一个简短描述:

顾客控制面板

这个接口对象负责管理废品回收槽位的感知器,开始按钮和收据按钮

 

管理员控制面板

接口对象实现改变系统内部的回收废品费率信息, 同时产生日报.

 

告警设备

控制一个信号设备,同时有一个复位按钮,来实现对告警信号设备的复位.

 

收据打印机

他负责在纸卷上打印文本信息.信息打印完毕以后,把收据纸切断.当相关的纸卷几乎打印完的时候, 系统管理员就应当通过相关的告警设备来呼叫.

It is evident that the interface objectsare not entirely independent of each other, but that they must know of eachother to be able to solve certain tasks. For instance, the Receipt Printer mustknow which Alarm Device to sound when the paper roll is finished. This issolved by the introduction of acquaintance associations between the objects. Anacquaintance association is a static association between instances and meansthat an instance knows of the existence of another instance. It does not givethe object the right to exchange information with the other object; for thatpurpose a dynamic association is needed as will be discussed below. Instanceassociations are, as mentioned, drawn with solid, directed lines.

非常明显, 接口对象之间并不是完全相互独立的，然而他们必须能够知道彼此的存在以便能够通过协作解决特定的任务。举个例子来说，收据打印机必须要能够知道通知当打印卷纸用完的时候普通知那一个特定的告警设备。这个问题主要是通过在对象之间引入一个“相识关联”（acquaintance associations）来解决的。一个相识关联描述的是多个实例之间的一种静态关联关系，这也意味着一个实例必须能够了解另外一个实例的存在。“相识关联”并没有赋予对象和其他对象交换数据的权利；要实现交换数据的目的需要引入一个动态的关联关系，这将在下面的内容中进行讨论。实例之间的关联，正如上面提到，在对象图中是通过实线，带箭头的指使线来标识。

 

An object may associate several otherinstances of the same class. Therefore we should also describe how manyinstances can be associated with the acquaintance association. This is done byassigning a cardinality(基数) to each association. This cardinality sayshow many instances can be associated. We also give the acquaintance association(相识关联) a name clarifying what the relationshipentails. The properties of these associations and naming conventions arediscussed in the box on naming associations. A complete view of the interfaceobjects in the example is shown in Figure 7.15. The cardinalities in thisexample are all [1] since the different interface objects can only know of oneobject each. Another example of cardinality is [0..N], which means that wemight associate any number between 0 and N. An acquaintance association is thusa static instanceassociation that is drawn with a solid, directed line having a name and a cardinality.Note that the associations are only unidirectional.

 

Figure 7.15 The interface objects and acquaintance associationsof the recycling machine.

一个对象也有可能与属于另外一个类的其他几个对象发生关联关系。所以我们应当也能够描述具体有多少个实例可以关联到一个相识别关联。这种关联关系的规定是通过为每一个关联指派一个基数（a cardinality）来实现的。我们也会给相识关联一个名字，这个名字将会阐明具体需要什么样的关系。关于这些相识关联应用的策略，以及命名转换的方法将将在下面的补充阅读材料“关于命名关联”中进行讨论， 在案例讨论中涉及到接口对象的完整视图将会图7.15中显示。 在这个案例中所有的基数都是[1]，因为不同的接口对象仅仅了解相互中的一个。另外一个关于基数的案例是[0..N],这就意味着我们可以为这种相识关联指派在0和N之间的任何一个数字。 一个相识关联就是一种实例之间的关联关系，在对象关系图中是通过一个实心的指使线来标识，并伴随一个名字和基数。注意，这种关联关系是单向的。

 

On namingassociations

关于命名关联

(补充阅读材料)

Models including relations often representa model of the real world. It is common to name associations so that thesequence object-relation-object naturally forms a sentence. Consider forinstance the relation shown in Figure 7.16. Here a verb phrase is used and wecan read 'A Car is driven by a Person'. This is very convenient.

模型和他包含的关联关系常常代表了现实世界的一个模型。对针对不同对象之间的关联进行命名是一个常见的做法，这样一来序列“对象-关系-对象”就很自然的构成了一个句子。例如考虑图7.16所显示的管理关系。在这里使用了一个动词短语，同时我们可以这样来阅读：“一辆汽车是由一名司机来驾驶”。这样的组织是非常方便的。

Figure 7.16 An example of how an association could be named usinga verb phrase.

 

However, another way of expressing the samerelation is to express what role another object plays in relation to the firstobject. Then a noun phrase should be used as shown in Figure 7.17. Here it isharder to read directly a complete sentence, but instead we can use the roleplayed to express the relation 'The object person plays the role of a driver toCar.'

然而，另外一种表达同一个关联关系的方式是阐明另外一个对象将要施加到第一个对象之上的关联规则。这样就需要使用一个名词短语来表达这种关系，正如图7.17所显示的样子。在这里使用名词短语的情况下，就很难直接读出一个完整的句子，可以代替的方法是我们可以使用“施加的规则”来表达这种关联关系：“对象”人“面向对象汽车执行了一个司机的规则。

We see that both of these strategies willbe appropriate in this example. In the literature, the verb phrase strategy isoften chosen, and it is also often used as an argument to show how usefulobject orientation is; you can directly read sentences from the model.Actually, this is not unique to object orientation. The same technique is very oftenused in data modeling (see Barker (1989)).

我们可以看到上述命名关联的2种描述策略在这个案例中都是合适的。在这个文献中，基于动词短语的表达方式常常被选择使用，它也经常被用来作为一个论点来说明面向对象是非常有用的；因为你可以直接从模型从读出对应的句子。事实上，这并不是面向对象技术所独有的技术。相同的技术也常常在数据建模当中使用。(see Barker (1989)).

However, we would like to promote thesecond solution instead: the noun phrase. The reasons for this are as follows:

然而，我们更加愿意促进第二种解决方案的应用：基于名词短语的方式。这样选择的原因描述如下：

(1) There is a large and fundamentaldifference between data modeling and object orientation. In data modeling youthink of the model as a flat structure viewed from above. In this way it isnatural to see the relationship as a binding between two objects. Therelationship here is often bidirectional. In object orientation however, theview is instead taken from an object. When you look at this model, you placeyourself at an object and then see what references you have to other objects.That is, you want to see what roles exist around you. Here the relationship isunidirectional. This fundamental difference is often hard to get used to forpeople used to data modeling. But object orientation often models reality, sothink about how the world around you looks. One Objectory user, experienced indata modeling, stated: 'If I'm married to my wife, I want my wife to be marriedto me.

Figure 7.16 An example of how an association could be named usinga verb phrase.

Figure 7.17 An example of how an association could be named usinga noun phrase.

So why aren't the relations bidirectional?'True, but what if you know about the king of Sweden? Does that mean that heknows about you? Normally not. Relations in the real world may be bothbidirectional and unidirectional. However, the relations always start from theobjects. In the married example, the wife knows about her husband and thehusband knows about his wife. To treat the associations as unidirectional isthus the more general case.

(1)在数据建模和面向对象建模之间存在巨大的和本质上的区别。在数据建模中，你可以把模型考虑成为一个在上面看到的扁平化结构。在这种方式下，我们会很自然的把关联关系看成是两个对象之间的绑定关系。在这里描述的绑定关系通常是一种双向关系。然而在面向对象的建模中，需要从一个对象的角度来提炼相关的视图。当你观察这个对象模型的时候，你需要换位思考，假设你也是一个对象，你应该如何引用其他的对象（寻找合适索引来定位其他的对象）。也就是说，你希望发现围绕在你周围的规则。这里的关系是一种单向关系。对于两者本质上的区别，哪些已经习惯使用数据建模的工程师是非常难以理解的。然为，面向对象的建模型通常是对客观世界来建模，所以考虑一下围绕在你周围的世界看起来的样子。一个Objectory 的用户，他是一个有经验的数据建模专家，曾经说过：“假如我被嫁给我的夫人，我更加希望我的夫人嫁给我”。 'If I'm married to my wife, I want my wife to be married to me.

Figure 7.16 An example of how an association could be named usinga verb phrase.

Figure 7.17 An example of how an association could be named usinga noun phrase.

'那么，为什么这种关系不是双向的呢？' ，的确是这样，考虑一下，一般人都认识瑞典的国王，那这是否就意味着瑞典的国王就认识你呢？，通常答案是否定的。在现实世界的关联关系即有可能是双向的，又有可能是单向的。然而，这种关联关系总是从对象开始的。在这个结婚的案例中，妻子知道她的丈夫，而丈夫也知道他的妻子。 把这种关联关系当作是单向关联关系来处理是一种比较通常的做法。

 

 

           (2) Datamodeling is often used in combination with relational databases. Here therelationship between objects will not be explicit, but rather it will beimplicitly expressed as foreign keys and JOINs between tables. In an object-orientedimplementation, however, the relationship will be made much more explicit. Herethe relationship will exist in some way, normally as an instance variableimplemented in a class.

    数据建模通常会和一个关系型数据库结合使用。在这里对象之间的关系将不会被明确，甚至是是将被隐式地表示为外键foreign keys 和表之间的关联JOINs。而在一个面向对象的实施方案中，相应的关联关系将会被表达的非常清晰明确。在面向对象的方案中，这种关联关系将会以几种不同的方式而存在，最常见的做法是设计一个类当中一个实例的变量来实现这种关联关系。

If the name of such a variable weredriven-by, or even worse, has-a, it would be almost impossible to understandthe implementation. It is better to have names like driver or engine instead.In this way we increase the traceability between the models and the actualcode. (This argument is strongly related to the first, being actually a specialcase of it.)

加入这样的变量名称如果是“被驾驶”，或者更糟糕的情况是“拥有，所有”，这样的一种实施方式将很难被大家所理解。更好的做法是赋予一个名字来代替，比如“司机”或者是“机车”。通过这种方式，我们增加了模型和确切代码之间的可追踪性。（这个观点和第一个观点是强相关的，他也是第一个观点的一种特例）

(3)     Thisnaming principle will normally give better names, avoiding names like has-a,consists-of or operated-by. Instead, the roles an object plays are expressedexplicitly. These role definitions may sometimes give rise to subtypes ofreferred objects. Refer to the example above; the driver may need someadditional information in addition to being a person. The driver will thennaturally form a subtype of person, since we need to add attributes andoperations to those of person in order to cope with its new role of being adriver as well. This technique will thus help us to formulate properinheritance relations as discussed in Chapter 3.

.关于对象之间关联关系命名的原则是尽量提供一些容易理解的名字，避免使用那些“拥有” has-a, “包含”consists-of 或者是“被操作”operated-by这样的名字.Instead, the roles an object plays are expressed explicitly. 代替的做法是需要清晰的表达一个对象将要施加的规则。这种关联规则定义的方法有时候可能需要使用到参考对象的子类型(give rise to subtypes of referred objects).参考上面提到的案例,司机可能需要一些附加的信息以便能够定义成为一个对象人.这样司机就很自然的成为对象”人”的一个子类型,因为我们也需要为同步对象”人”增加一些属性和操作以便实现满足一个人来适应成为一个司机的一些特定规则的要求.这种技术也会帮助我们制定出合适的继承关系,这正如第3章所讨论的一样.

As a consequence of the noun-phrasestrategy we will sometimes end up having the same name for the association asfor the referred object. This should not be viewed as something wrong, butquite the opposite; it is good. This is because you have made a proper use ofthe object, using it as a role for what it was intended for in the first place.We thus name the association as a role of the object associated.

作为应用名词策略的一个优点,我们最后有时能够保持关联关系和参考对象一致的名字。这一点不应当被认为是不合适,恰恰相反;这一点是非常合适的。这是因为你已经针对对象进行了一种正确的使用,将对象作为一种规则来使用,而这种规则就是我们在最初的地方希望使用的。我们就这样将关联关系的命名等效成为约束对象之间关联关系的规则，

To avoid confusion between objects and relationships, we normallywrite object names with a capital first letter and relationships with alower-case first letter.

为了能够避免对象和关系之间的混淆，我们通常将对象名字的第一个字母进行大写，而将关联关系的第一个字母以小写的方式来表达。

(补充阅读材料)

A special type of acquaintance associationis the consists-of 组成关系association, which is used to state that anobject is composed of other objects. Such a structure, where a uniting objecthas associations with participating parts, is sometimes called an aggregate聚合, as discussed in Chapter 3. This is common withinterface objects. In a window system, for instance, we want to state that awindow can consist of buttons, menus and scroll bars. Each such unit can thenbe modeled by an interface object of its own. The result will be an interfacestructure forming a tree. In Customer Panel the buttons and the sensors canbecome interface objects in their own right, depending on how we wish to modelthe customer panel. This is illustrated in Figure 7.18. We call the interfaceobject Customer Panel the central interface object. This is also often called acontainment hierarchy （包容式层次结构）or a partition hierarchy（划分式层次结构） as discussed in Chapter 3.

关于相识关联（acquaintanceassociation）有一种特殊的类型是组成关联（consists-of），组成关联可以用来描述一个对象可以由其他的对象来组成。这样的一个关联结构，当中一个聚合的对象和几个参与对象产生关联关系，这张关联关系有时候也被称为聚合（aggregate）关系，正如第三章中的所描述的一样。这种关联关系在接口对象中是非常普通和常见的.在一个应用程序的视窗系统中, 举个例子来说,我们希望来表达一个窗口实例可以包含多个按钮,菜单和滚动条.其中的每一个单元可以被建模成为一个面向他自己的接口对象.这样对象建模的结果是构成了一个树形的接口对象集合. 在接口面板中,对应的按钮和感知器也可以成为独立的接口对象, 这种建模方式取决于我们希望设计的客户控制面板建模型方式.详细的对象关系图参考图7.18的说明.我们把接口对象顾客面板称为是中央接口对象.这种对象之间的关联关系也常常被称为包容式层次结构（a containmenthierarchy ）或者是划分式层次结构（a partition hierarchy）,正如第三章中所描述的一样.

 

Having identified the interface objects, itwill be easy to modify an interface in the system. If, for instance, we wish toexchange the receipt printer in the recycling machine system for another one,the changes will concern only this interface object. By having everything thatconcerns a specific interface in one object, every change to that interfacewill be local to this object. Since changes to interfaces are very common, itis vital that these be manageable.

在分析模型中已经正确的识别接口对象以后,后续针对系统接口的修改将会变得非常容易. 假如,举个例子来说,我们希望把废品回收系统中的票据打印机更换成另外一个品牌的,相关的变更将仅仅集中于对应的接口对象上.如果能够将与一个特定接口相关的所有数据和方法集中在一个对象当中,后续针对这个接口的每一次改变将会局限在对应的接口对象当中.因为在实际的系统中对接口的改变将会非常频繁,对接口对象的集中管理将是非常有价值的.

Figure 7.18 An example of an interface structure using acontainment hierarchy.

It soon becomes obvious that there are twodifferent types of interface to model. There are those that are interfaces toother systems and those that are interfaces to a human user.

存在两种类型的接口对象需要被建模型,这一点是非常明显的.这两个种类型的接口对象分别是和其他系统交互的接口,以及那些和个人用户交互的接口.

For interface objects which communicatewith other systems, the communication is usually described in terms ofcommunication protocols. These interface objects can be of a type thattranslates to a standardized protocol, or may be of a type that just sends outstimuli that are produced internally without any complex conversions. Thisconstitutes another advantage: if the protocol is changed, these changes willbe local to this interface object. Actually, in one project where we knew thatthe protocol was to be changed, we modularized the interface object so thatchanges (in this case climbing the OSI layers) would be very easy toincorporate. A significant problem arises when there are continuous signalsfrom the outside world, such as in measurement and/or control systems. Then ourinterface object must either sample the input signal or trigger when certainvalues are passed, since internally in the system there is only discretecommunication via stimuli. The interface objects must then translate fromcontinous information to discrete information. Quantification problems may thenarise and should be resolved.

针对那些负责和其他系统通信的接口对象, 系统之间的通信方式常常是利用通信协议的方式来描述. 这些接口对象既可以是基于一种标准通信协议的一种转换类型;或者也可以是基于激励(stimuli)的形式,这种私有协议负责发送一些简单的激励(stimuli),而不需要任何复杂的协议转换. 这种系统间接口对象的设计方法构成了另外一种优势:假如接口协议发生了改变, 这些协议改变将会局限在一个接口对象的局部范围.实际上,在前期处理的一个项目中, 我们提前了解到接口协议将会发生改变,所以采用了模块化的方式对接口进行了集成,这样一来后续对于接口的变更(OSI分层接口会话层次的提升)管理将变得更加容易合并与集成. 假如外部世界中有连续不断的信号注入到系统内部将会产生一个严重的问题,通常在那些测量或者是控制系统中容易产生这一类问题。那么我们的接口对象必须负责针对输入信号或者是触发信号进行抽样处理,而抽样处理需要根据一定的取值门限来过滤信号,这是因为系统内部的通信是一种基于消息通知的离散通信模式. 接口对象因此必须能够实现从连续信息到离散信息的转换.输入信号量化的问题就可能会出现，并且应该得到解决。

The other kind of interface objectcommunicates with human users. Today, we often request Graphical UserInterfaces (GUIs) between the system and the user. Such interface objects canbe complex to model; but they can be modeled as whole structures of theinterface objects as previously shown. Several different techniques exist forgood interface design. It is fundamental that the user has a logical andcoherent picture of the system. This can be accomplished by using the problemdomain objects as discussed earlier. By doing interface design at that earlystage and having the prospective users take an active part, we also guaranteethat the interfaces will satisfy the user needs. In interface-intensiveapplications it is not abnormal for the user interface to be the major part (upto 80%) of the entire application. When developing interface- intensiveapplications, supporting tools should be used. Such tools include differentkinds of User Interface Management Systems (UIMSs) (see Hix (1990)), as well asdifferent kinds of windowing systems, frameworks and development environmentswith predefined parts (such as X-Windows, NeWS, MacApp, NewWave, Smalltalk,NeXTStep's Interface Builder, Windows and Presentation Manager). Additionally,there are several different kinds of class library, for example, C++, that also support thedevelopment of GUIs like Interview or CommonView. Note, however, that the useof class libraries is often redundant when UIMS systems are used.

 

另外一种类型的接口对象是负责和个人用户进行通信。今天，我们通常会在系统和个人用户之间提供图形化的用户接口(GUIs)。这种形式的接口对象建模分析将会非常困难；然而他们可以类似于以前案例中显示的那样，被作为接口对象的整体结构来进行建模分析。目前有一些好的技术来支持良好的人机接口设计。那么 GUI界面帮助用户拥有一个逻辑和连贯的系统视图是最根本的要求。这个问题可以通过应用前面讨论的领域对象模型来解决。通过在这个早期的需求分析阶段进行人机接口设计工作，并提前邀请系统潜在的用户积极的参与设计讨论， 我们也能够有效保障IT系统的人机接口界面能够更好的满足未来用户的需求。对于一个接口密集型的应用项目来说，用户接口设计和开发将成为整个应用项目最主要的工作（接近80%的工作），这完全不会让人感到异常。当需要开发人机界面接口密集型的应用项目的时候，我们必须采用合适的支持工具。相关的界面开发支持工具集合包括不同的用户接口管理系统（User Interface Management Systems (UIMSs)(see Hix (1990))；以及不同类型的视窗系统，开发框架，和具有预先定义部分内容的开发环境(such as X-Windows, NeWS, MacApp, NewWave,Smalltalk, NeXTStep's Interface Builder, Windows and Presentation Manager).。此外，还需要一些不同类型的类库来支持图形界面的开发，举个例子来说，在C++中，有用于支持人机界面开发的Interview or CommonView等类库。但是请注意，当UIMS系统在使用的情况，使用界面开发的类库通常会是多余的。

The purpose of each separate object wasdiscussed in Chapter 6. It became evident that interface objects are suited forpresentation, but that they can also handle information and have behavior.How-much information and behavior should be tied to an interface object must bedecided from case to case. At one extreme, the interface object just passes onthe stimuli it receives from the actor to other objects in the system, withoutactively participating itself in the course of events. At the other extreme,the behavior of the interface object is very complex; complex information istied to the interface object and it can function almost independently of otherobjects.

分析模型中设计不同类型对象的目的已经在第6章中进行了讨论。很明显接口对象适合于呈现的功能，但是他们也能够处理信息和具有行为。针对一个接口对象应当绑定多少信息和行为必须一个案例，一个案例的进行分析和决策。在一种极端的情况下，接口对象仅仅负责把他接收到的来自外部角色发送到的激励（stimuli）透明的传输到系统内部的其他对象，在事件传输期间不会主动的参与用例的处理。在另外一种极端的情况下，接口对象的行为将会变得非常复杂，复杂的信息结构将会绑定到接口对象上，同时接口对象几乎可以不依赖系统内部其他的对象而独立的对外提供功能。

 

How is it possible to decide what behaviorin the use case should be tied to a particular interface object? Generally, thepotential for change should decide this. Any change of functionality directlycoupled to the interface should be local to the interface object. Other changesshould not affect the interface object. Experienced users are very ingeniouswhen inventing potential changes. This is a skill that should be learned andapplied in all modeling activities. Every approach to a model should be viewedin the light of possible changes to the system.

怎么可能决定在什么情况下用例模型的行为应该放置到一个特定的接口的对象上呢？一般来说，系统功能潜在改变的可能性将决定接口对象上的功能分布。和接口对象归属功能相关的任何改变应当能够控制在这个接口对象局部的范围。而其他的功能变更将不应该影响这个接口对象。当发现和识别系统功能潜在变化的时候，有经验的用户总是能非常巧妙的考虑这种因素的影响。因此这是一种非常重要的技能，他需要系统设计师系统的学习，并在所有的建模活动中全面进行应用。用于系统建模的每一种方法都应当本着系统潜在变化的角度去观察和考虑。

 

Thus, to identify which part of the flow ina use case should be allocated to interface objects, we focus on theinteractions between the actors and the use cases. This means that we shouldlook for units displaying one or more of the following characteristics:

•    They present information to the actor orrequest information from him.

•    Their functionality is changed if theactor's behavior is changed.

•    Their course is dependent on a particularinterface type.

 

这样，为了能够识别一个用例模型中包含事件流的哪一部分应当指派到接口对象中，我们需要重点关注角色和用例模型的相互作用。这意味着，我们应该寻找那些单元显示一个或多个以下特点:

•    他们向外部角色请求输入信息，并向角色显示信息。

•    .假如角色的行为发生改变，他们的功能也将发生改变。

•    .他们的事件流程是依赖于一个特定的接口类型

 

We can differentiate between severaldifferent strategies for allocating the functionality (see Hartson and Hix(1989)):

我们可以区分用于分配接口对象功能的几种不同的策略(see Hartson and Hix (1989))

(1) Computationdominant control or embedded controlis

where we place thecontrolling functionality inside the system, that is, in the control objectsand the entity objects. Here the interface objects do not have very muchfunctionality. This structuring can be efficient in execution but hard toprototype from, since not much functionality is introduced in the interfaceobject. As we will see later, we can place the overall system sequencinglocally anyway, in the control objects, for ease of modification.

计算主导控制或嵌入式控制Computation dominant control orembedded control，这种方式是我们将界面的控制功能内置到系统内部，也就是说，控制功能主要放置在控制对象中，以及实体对象中。在这里接口对象不需要过多功能。采用这种结构适合非常高效的执行，但是却很难进行原型分析，这是因为在接口对象中并没有引入太多的功能。正如在后面我们将会看到，我们可以把整个系统的控制顺序放置在任何局部的地方，比如放置在控制对象中，为了实现容易变更的目的。

 

(2) Dialoguedominant control is where we place much control functionality in theinterface objects and these objects model much of the functionality of thesystem. In this case we do not have many control objects in the model. Thisstrategy is easy to prototype from, but Increases the complexity of the interfacessince different abstraction levels are mixed, for example, mixing of eventdetection and global control.

 

对话主导控制Dialoguedominant control是我们把很多控制功能放置在接口对象当中，这些接口对象负责建模型系统内部的大部分功能。在这种情况下我们在分析模型中不需要设计太多控制对象。这种策略的优点是方便建立原型，但是增加了接口对象设计的复杂性，因为混合了不同的抽象层，举个例子来说，对事件检测和全局控制功能的混合。

(3) Mixedcontrol places the control on both sides allowing invocation of dialoguefrom the computational side and vice versa. This offers more flexibility, butrequires programmers to be more disciplined in order to maintain dialogueindependence.

混合控制   Mixed control则是在两侧都能够进行控制，既允许从计算那一侧发起调用会话控制，反之也是一样。这种方式产生了更高的灵活性和扩展性，但是这种模式要求程序设计人员必须进行更加规范的程序设计，以便能够保持会话的独立性。

 

(4) Balancedcontrol is where we separate the control from both the dialogue and thecomputation. The global control component, which typically is a control object,governs sequencing among invocations of dialogue and computational functions.

平衡控制Balancedcontrol则是我们将控制功能从会话和系统计算中进行分离。全局控制组件，他通常是一个控制对象，负责控制对话调用和计算功能之间的执行顺序，

Which type of control to choose must be decided on from

application to application. OOSE allows modeling ofall four types, and actually highlights which strategy was chosen since theanalysis models will look different for each strategy. In most cases, however,OOSE promotes alternative (4): the separation of control from other types offunctionality. The reason for this is to have high localization in futurechanges to the functionality.

具体应该选择那一种控制类型应该根据不同的应用项目来决定。OOSE方法支持对以上4种类型进行建模型，同时能够显著的体现选择的是那一种策略，因为在分析模型中会清楚的体现不同策略的区别。在绝大多数情况下，OOSE方法推荐策略4，把接口控制功能从其他的系统功能中分离出来。这样做的理由是能够将系统未来潜在的变化高度的局限在一个本地的对象范围内部。

 

7.3.2   Entity objects

7.3.2  实体对象

To model the information that the systemwill handle over a longer period of time we use entity objects. Typically suchinformation survives use cases, so the information should be kept even if theuse case has been completed. Besides the information to be handled, we alsoallocate the behavior that naturally belongs to this information to the entityobject.

我们使用实体对象来面向那些系统需要长期处理的信息结构进行建模。通常这些信息模型伴随着用例模型的存在，所以这些信息结构应当进行保存，即便这些用例模型已经执行完毕。除了那些需要处理的信息结构，我们也把那些和实体对象的信息结构自然相关的行为指派到实体对象当中。

The entity objects are identified from theuse cases, just as the interface objects are. Most entity objects are foundearly and are obvious. These 'obvious' entity objects are often identified inthe problem domain object model. Others can be harder to find. Entities usuallycorrespond to some concept in real life, outside the system, although this isnot always the case. It is very easy to model too many entity objects, in thebelief that more information is necessary than is really called for. The hardthing is to model only the entity objects actually needed. It is thereforeessential to work in a structured way when modeling the entity objects. Theneeds of the use cases should be the guidelines and only such entity objects ascan be justified from the use case descriptions should be included.

正如接口对象一样，实体对象也是从用例模型中进行识别的。绝大部分实体对象能够在早期被发现，并且他们是非常明显的。这些“明显”的实体对象通常是从问题领域对象模型中识别的。而其他剩余实体对象的识别存在一定的困难。实体对象通常是对应着现实生活中的一些概念模型，他们存在于系统的外部，虽然这并非总是如此。我们通常很容易归纳太多的领域对象模型，这是因为大家相信比起实际需要调用的对象，我们需要更多的信息结构。所以能够准确的确定需要的实体对象模型是一件困难的事情。当我们进行实体对象建模的时候，遵循一种结构化的工作方法是一种必要的要求。用例模型应该是实体对象建模的指导，仅仅是那些和用例模型相关联的实体兑现应该被包含进来。

 

In the example of the recycling machine, we look at the informationthat must be kept for a longer time. Below is the use case description, withitalics to show where we mention some information functionality:

在废品回收机的案例中, 我们来看看那些需要长时间保存的信息结构.下面是相关的用例模型描述,其中用例模型描述的斜体文字部分是用来显示我们叙述的一些信息结构功能.

When the customer returns a deposit item,it is measured by the system. The measurements are used to determine what kindof can, bottle or crate has been deposited. If accepted, the customer total isincremented, as is the daily total for that specific item type. If the item isnot accepted, the light for 'NOT VALID' is highlighted on the panel.

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

 

When the customer presses the receiptbutton, the printer prints the date. The customer total is calculated and thefollowing information printed on the receipt for each item type:

name

number returned

deposit value

total for this type

Finally the sumthat the customer should receive is printed on the receipt.

 

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

 名称

 返回的数量

 收据金额

 这种类型的总数.

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

 

From this text we can reason as follows.Since we must remember how many cans, bottles and crates of each type have beendeposited during the day, we need something that handles this information. Wethus identify the entity objects Can, Bottle and Crate. These entity objectscan also handle their size, deposit values and other information that can betied to these objects. These entities have common properties and thus couldactually be modeled as instances of the same class. However, we want to handlethe sizes of the objects a little differently. Cans have a width and a height,bottles have a neck width and a bottom width and crates have height, length andwidth. Nevertheless, some properties can be extracted (for example, depositvalue, day total) and placed in an abstract entity object. We place thesecommon properties which the other entity objects will inherit in Deposit Item(see Figure 7.19).

根据上面的文本描述,我们可以做出如下的解释和推断.因为系统必须记住一天之内每种类型罐子,瓶子和板条箱的回收数量,我们需要一些对象来处理这个信息结构. 我们就通过这种方式识别出来实体对象罐子,瓶子和板条箱.这些实体兑现也能够处理这些回收物品的尺寸,废品回收费率,以及其他的一些可以和这些对象绑定的信息结构.These entities have common properties andthus could actually be modeled as instances of the same class. 这些实体具有一些公共的属性,并且实际上可以建模成为相同类的不同实例.However, we want to handle the sizes ofthe objects a little differently. Cans have a width and a height, bottles havea neck width and a bottom width and crates have height, length and width.Nevertheless, some properties can be extracted (for example, deposit value, daytotal) and placed in an abstract entity object. We place these commonproperties which the other entity objects will inherit in Deposit Item (seeFigure 7.19). 然而,我们希望对这些对象的尺寸处理方式上有一定的区别.罐子有高度和宽度;瓶子则有颈部的宽度和底部的宽度;而板条箱则有高度,宽度和长度.然后,还是有一些公共属性可以被提取(举例来说废品回收费率,每天的总数),并且能够放置在一个抽象的实体对象中.我们将这些公共属性放置在对象”回收物品”中,这样其他的实体对象可以直接进行继承.

To store information, objects useattributes. To each entity object we can thus tie several attributes. Eachattribute has a type, which can be either a primitive data type, such asinteger or string, or a composite data type which is more complex and which isspecially defined. An attribute is described as an association with a name andcardinality indicating the attribute's type (see Figure 7.20). Note the similaritiesbetween this and the acquaintance association. Actually, attributes and entityobjects have many properties in common and it can sometimes be hard to knowwhen to use an entity object and when to use an attribute. This will bediscussed further soon. Attributes can be used in all object types to describethe information to be stored.

Figure7.19 Can, Bottle and Cratehave common properties inherited from Deposit Item.

Figure 7.20 An attribute of an object.

对象需要使用属性(attributes)来存储信息结构.这样一来,我们可以针对每一个实体对象绑定几个属性.每一个属性都有一个类型(type),这种类型既可能是一个原始数据类型, 比如一个整数,或者是一个字符串;也有可能是一个复合的数据类型,这种数据类型通常是更加复杂,并且需要通过专门的定义. 一个属性被描述为一个有名字的关联，同时还定义了一个规定关联属性的类型基数.(参考图7.20). 注意对象属性关联和相识关联(acquaintance association)之间的相似性. 事实上，属性和实体对象有许多共同的特性,并且有时候设计师很难知道何时应当使用一个实体对象，何时应当使用一个属性。这个问题我们很快将在后续的内容中讨论.属性可以用于支持所有对象类型来描述所要存储的信息.朗读

显示对应的拉丁字符的拼音

 

The attributes of an entity object developas the use cases are analyzed. We have already mentioned some of the attributesof the entity object in the recycling example. These are shown in Figure 7.21.

一个实体对象的属性将成为用例的一部分而进行分析.我们已经提到了在废品回收机的案例中相关实体对象的一些属性.这些实体对象的属性在图7.21中进行显示.

Figure 7.21 Attributes of some of recycling machineentity objects.

Let us continue analyzing the recyclingsystem. We now have the means to handle the information about the items andalso their daily number. To be able to print out the receipt for a specificcustomer when she has finished depositing items, we will need something to keeptrack of all the items which should be printed on the receipt. This is not actuallyinformation that will survive the use case, but since it is very essentialinformation for the system, we model it with an entity object anyway. Wetherefore identify an entity object Receipt Basis. Since a specific customermay insert several different kinds of item, we must keep the information on howmany of each type she has deposited. We have here two alternatives. The firstis that Receipt Basis handles only one specific type of item and, when severaldifferent types are deposited, we create new instances of Receipt Basis. Thesecond alternative is to have only one instance of Receipt Basis handling allitems, and if several different types of item are inserted this will be handledinternally to Receipt Basis. Since we want 'to encapsulate as much as possible,to decrease dependency between the objects, we choose the second alternative,namely to have only one Receipt Basis for each customer. Receipt Basis thuskeeps track of all items the customer deposits. Since we need to know whichtype of item we are counting we will need an aquaintance association betweenReceipt Basis and Deposit Item. Note that we will actually never countinstances of Deposit Item, but here we use the polymorphic property that isfundamental to all object-oriented systems. We thus do not need to know exactlyto which class the instances we are counting belong. By the association we havelimited the polymorphism to being a descendant of Deposit Item. We will set thecardinality to [0..N] since we may count several different instances withReceipt Basis. We thus have the picture shown in Figure 7.22.

让我们一起继续分析废品回收机系统. 我们现在有能力处理有关回收物品的信息结构和各种物品每天回收的总数量. 当一个用户已经放置完所有回收的物品,为了能够针对一个特定的顾客打印相关的物品收据,我们还需要有一些信息结构来跟踪那些应该在客户收据上打印的所有物品情况.这一类信息结构并非是和用例模型直接相关的内容,可是因为他们是系统运行需要的核心内容,我们也使用一个实体对象了对他进行建模.我们因此也识别出一个实体对象为收据基础. 由于一个特定的客户可以在废品回收机中放入多个不同类型的物品，我们必须详细记录用户已经回收的每种物品的信息。这里我们有两种可能的实现方式. 第一种方式是由实体对象”收据基础”仅仅处理一种类型的物品,假如一个用户放置了多种不同类型的物品,我们将创建类”收据基础”的多个实例.第二种方式实现方式是仅仅使用类”收据基础”的1个实例来处理所有的物品,假如有多个不同类型的物品被放置到废品回收机中,这种情况将由类”收据基础”的内部逻辑进行处理. 因为我们希望尽可能的将对象的功能进行封装,以便降低对象之间的依赖关系,我们选择第二种实现方式具体的方法是为每个顾客仅仅分配一个”收据基础”的实例. 实体对象”收据基础”就通过这种方式实现了对顾客所有回收物品的跟踪处理.因为我们需要详细知道哪些类型的物品需要被计数,我们也需要在类”收据基础”和类”回收物品”之间建立一个相识关联.请注意，我们从不会确切统计过实体类”回收物品”激活的实例数量,可是在这里我们使用了多态的特性,这也是所有面向对象系统最基本的特性. We thus donot need to know exactly to which class the instances we are counting belong.By the association we have limited the polymorphism to being a descendant ofDeposit Item.We will set the cardinality to [0..N] since we may count several differentinstances with Receipt Basis. We thus have the picture shown in Figure 7.22. 因此，我们并不需要确切知道那些被我们用来统计数量的实例所确切归属的类。通过这种相识关联,我们已经限制了这种多态特性成为类”回收物品”的后裔类.我们将把相关的基数设置为[0..N],因为我们可以针对实体类”票价基础”的多个不同的实例进行计数操作.详细的对象关系见图7.22.

 

 

Figure 7.22 The entity objects that are necessary to deposit itemsin the recycling machine.

 

Receipt Basis keeps track of how much a specificcustomer returns and of which type. In the entity object will be an attributestoring the number received for each type The number information that theOperator wants at the end of the day will he placed in the entity object forthe items. We must therefore create an instance of each type of item that thesystem is able to receive at system start-up. In them we will store informationabout the deposit value, the size of the items and the number of items thathave been returned that day. Receipt Basis will have acquaintance associationswith these instances, and in an instance of Receipt Basis we will storeinformation about the number of each particular item type that the customer hasreturned. Hence, for each specific association, we assign a number. This can bedone by just noting this attribute of the relation or by adding a new entityobject to hold this information.

类”接收基础”负责记录每一个顾客放置在废品回收机中的物品的数量和类型.在这个实体对象中,将有一个属性用来存储每种类型物品所接收的数量.而系统管理员需要统计的每天回收物品的总数将放置在每个物品对应的实体对象中. 因此我们必须针对系统启动以后可以接收的每一种类型的物品所对应的实体类创造一个对应实例在这些实例中,我们将保存那些关于物品回收费率,接收物品尺寸,以及当天接收该类型物品的总数. 类”接收基础”将和这些实例建立相识关联关系,而在类”接收基础”的一个实例中我们将存储一个特定用户放置在废品回收机当中每种类型物品的总量.所以,针对每个特定的关联,我们将指派一个数字.这可以通过对这一关系的属性进行标注或添加一个新的实体对象来保存这些信息。

It is not always easy to decide whether acertain piece of information should be modeled as an entity object or as anattribute. To be able to decide, we must see how the information will be used.Information that is handled separately should be modeled as an entity object,whereas information that is strongly coupled to some other information andnever used by itself should be made into an attribute of an entity object. Inother words, what is decisive is how the use cases handle the information.Certain information can become an entity object in one system, while it mayvery well become an attribute in another system. If it is used from twodifferent directions and for different reasons, it should form a separateentity object.

要决定一条特定的信息结构是通过一个实体对象,或者是一个属性来建模表达是一件困难的工作.为了能够决定是哪一种建模的方法,我们将需要判断这些信息结构将如何使用.那些需要单独使用的信息结构应当建模为一个实体对象,然而那些和其他一些信息结构有很强的关联关系信息结构,并且从不会单独使用的,就应该建模为一个实体对象的一个属性.换句话说,用例模型将如何使用这些信息结构将最终决定合适的建模方式.特定的信息可以在一个系统中成为一个实体对象,然而他们也可以非常合适的在另外一个系统中成为一个对象的一个属性.假如一个信息对象结构将从两个不同的方向和不同的原因来使用,那么他就应当构成一个单独的实体对象.

 

Let us look at an example. Say we need tomodel a car and its owner. Will this be two entity objects? Well, we don'tknow. In one system we could very well end up with two entity objects, if bothare needed for performing the use cases. In another system we could very wellhave just one entity object Car with an attribute Owner. In yet another systemwe could end up with an entity object Person with an attribute Car. Hence,there is no need to model the reality as such, but only to model it as neededby the use cases. In the first case, two use cases could use Owner and Carindependently of each other, in the second case we always use the Owner incombination with its owned car and in the third case we only use Car inassociation with a specific owner or Person.

让我们一起来看一个案例.假如我们需要对一个汽车和他对应的主人进行建模.这将成为两个实体对象吗?事实上,我们并不知道答案.在一个系统中,我们很可能最终需要有2个实体对象,假如两者都需要在用例模型中需要被使用.而在另外一个系统中,我们可以仅仅拥有一个实体对象汽车,并伴随着一个属性”所有者”.此外在另外一个系统中,我们最终需要一个实体对象”人”和他拥有的一个属性汽车. 因此,我们没有必要严格的按照现实世界的情况进行实体对象建模,而是需要根据用例模型的要求来进行建模.在第一种情况下,两个用例模型将单独的使用信息结构”所有者”和”汽车”;而在第二种情况下,我们总是使是把所有者和他所拥有的汽车一起关联使用;而在第三种情况下,我们仅仅把汽车和他的一个特定的所有者”人”进行关联使用.

It is usually easy to find the necessaryentity objects, but it is much more difficult to identify what operations andwhich attributes these entity objects are to offer. The only way to manipulatean entity object is via the operations. Therefore the identified operationsmust be sufficient for all those who wish to use the entity object. Thedetailed description of the use cases is an extremely valuable means of findingthe desired operations. By following them, we will naturally come up with thenecessary operations. The whole course of events is described in the use cases,and by extracting those parts that i 'Mi. ei N inn entity object, theoperations will appear. In Chapter 8 we will describe the technique used inOOSE for doing this in a structured way. The technique mainly uses interactiondiagrams. Although these are described in the construction chapter, they mayvery well be used here to identify operations. We will later discuss the pitfalls andbenefits of identifying operations in the analysis model relative to the designmodel. The normal case is not to identify operations in the analysis model,since these often change in the design. The normal case is therefore topostpone the identification until construction, but we will discuss someaspects of operations here anyway.

寻找必要的实体对象通常是很容易的,然而合理的识别出这些实体对象需要提供的属性和操作则是一件非常困难的工作. 操控一个实体对象的唯一方式是通过他对外提供的操作.所以一个实体对象提供的操作集合必须能够满足那些希望使用这个实体对象的全部对象的需求.分析用例模型的详细描述是一种非常有价值方式来找到期待的操作.按照用例模型描述的指导,我们将很自然的筛选出必须的操作.完整的事件流程描述将在用例模型中进行描述, 通过抽取那些和我们的实体对象有关联的部分, 相关的操作将会出现.在第8章中,我们将会描述在OOSE 中使用的技术:通过一个结构化的方法来识别需要的操作.这种技术主要会使用交互图.虽然这些内容将在系统集成的章节中进行描述,他们可以非常好的用在这里来识别需要的操作.我们后续将讨论在分析模型和在设计模型中识别需要操作的好处和坏处.正常的情况下是不需要在分析模型中识别需要的操作,因为这一部分通常会在设计阶段进行变动.正常情况下识别操作的工作将会延迟到系统集成阶段,可是在这里我们会从操作的某些方面来讨论这一问题.

 

Operations can be more or less complex. Oneextreme case is where an entity object comprises only reading and writingoperations; the other extreme is having whole courses of events included in theoperations. As always, the right thing is a middle course between theseextremes. The same basic rules apply to entity objects as to other objects,that is, everything (behavior and information) that is naturally connected withthe entity object should be placed in it. In the same way it is important tosee what consequences any changes will have. The aim is that any type of changeshould be as local as possible. Beginners sometimes only use entity objects asdata carriers and place all dynamic behavior in control objects (as will bediscussed later). This should, however, be avoided. Using this extreme, we willend up with a function/data structure: we have earlier discussed the problemswith such a structure. Instead, quite a lot of behavior should be placed in theentity objects. Often an appropriate way of realizing how behavior should beplaced is to model initially without using control objects at all, that is,just using interface objects and entity objects. In fact, we can build anysystem with just these two object types. However, when such a model has beendeveloped, you will notice that there are certain behaviors that are notnaturally placed, from a maintainability view, in either entity objects orinterface objects; or even worse, they are spread over several objects. Thesebehaviors should be placed in the control objects. When continuing with therecycling example and allocating behavior in more detail, as we will do in theconstruction chapter, please feel free to eliminate the control objects fromthe model and think of how you would place behavior without them.

 

实体对象的操作(Operations)定义可以简单,也可以复杂.一种极端的方式是一个实体对象仅仅包含读和写操作; 而另外一种极端方式是在操作中包含完整的事件经过以便实现相关的操作定义.正如OOSE方法中所提到的,正确的方法是在这这些极端之间找到一种平衡的方案.这个同样的基本规则也对适用于实体对象建模,如同起他类型对象的建模原则一样,也就是说所有(行为和信息结构)和实体对象自然关联的行为和信息结构都应当放置在其中.基于同样的分析方法,重要的是要看看对系统功能的任何改变将会对实体对象模型带来什么样的后果.这样做的目的是系统功能任何类型的改变应当尽可能控制在局部的范围. 一些OOSE方法的初学者有时仅仅把实体对象当作是数据载体,并且把所有动态的行为放置在控制对象中(正如后面将要讨论的).这些,很显然这种建模方法是需要避免的.假如使用这种极端的建模方式,我们最终将产生一个功能/数据方法的体系结构:我们前期已经讨论过使用功能/数据方法可能会带来的潜在的问题.恰恰相反,相当多的行为(behavior)应当放置在实体对象当中. 一种合适的方法用来识别行为应当如何放置在对象模型当中通常是在初始建模的时候完全不考虑控制对象的因素,也就是说仅仅使用接口对象和实体对象. 事实上,我们可以仅仅使用这两种类型的对象来构建任何系统. 然而当这样的模型已经建模完成以后,你将发现有一些系统行为无法自然合适的进行放置,这主要是从系统维护的观点出发,既不适合放置在接口对象中,也不适合放置在实体对象当中, 甚至是更糟糕的情况,他们会分布在几个不同的对象当中.这样的一些行为就应当放置在控制对象当中.当我们继续进行废品回收机的对象模型分析,并且更加详细的把系统行为分配到不同的对象当中去,正如我们在系统构建章节中将要讨论的一样,请先轻松的从系统模型中删除控制对象;同时考虑在没有控制对象的情况下,你应当如何分配系统的功能.

 

The following is a list of typicaloperations that must be offered by an entity object:

•    Storing and fetching information

•    Behavior that must be changed if the entityobject is changed

•    Creating and removing the entity object

 Figure7.23 Receipt Basis increments Deposit Item number when a new item has beenreceived.

 

下面是一个必须由一个实体对象提供的典型操作列表:

•    保存和读取信息结构

•    假如实体对象发生变化以后,必须改变的行为.

•    创造和删除实体对象

 

An operation on an entity object may meanthat the entity object contacts another entity object and asks for informationabout something (see Figure 7.23). This communication takes place through communication associations. Acommunication association models communication between two objects. Throughthese associations, an object sends and receives stimuli. The associationstarts from the object that is to perform the manipulation (that is, sends theinitiating stimuli), and is directed to the object where the manipulation is totake place. Since it is an instance association, it is solid; and since it isdynamic, we will not name the association.

 Figure7.23 Receipt Basis increments Deposit Item number when a new item has beenreceived.

施加到一个实体对象上的操作也可能意味着一个实体对象主动和另外一个实体对象进行联系,同时询问某些事情的信息参考图 7.23)..This communicationtakes place through communication associations.这种对象之间的通信要通过通信关联(communicationassociations.)来发生.一个通信关联可以实现两个对象之间的信息通信.通过这些关联,一个对象可以发送和接收激励(stimuli).这种通信关联是从负责执行操控请求的对象开始(也就是负责发送开始的激励stimuli),并直接连接到那个负责执行具体维护的对象.因为着是一个实例之间的关联,在对象图上用实线来表示;同时因为这种通信关系是动态的,我们将不会为这种关系进行命名.

As the entity objects are modeled, it willbe found that similar entity objects occur in several use cases. It must thenbe decided whether there should be separate entity objects. Even if the usecases do not make exactly the same demands on them, the entity object may offeroperations so that the use cases may use them in the way that they wish. Thebasic rule to follow when deciding if two entity objects are actually are oneand the same is to see what occurrences they represent. If it is the sameoccurrence, there should be only one entity object; otherwise the two objectsshould remain separate. When it is decided that entity objects should bemerged, operations, associations and attributes should also be integrated intothe new entity object. The same functionality that existed in the separateentity objects should be found in the new entity object. Though it is possibleto create operations on entity objects, this possibility should not beoverused. The operations are, after all, going to be designed and implementedlater.

 

伴随着实体对象完成建模的工作,我们将会发现发生在几个不同用例模型中存在类似的实体对象.下一步就必须决定在这些类似的对象中是否应当有独立的实体对象.即便是用例模型不需要对这些实体对象做出完全相关的调用请求,而实体对象可以提供合适的操作,这样一来用例模型可以根据他们期望的方式对用例模型进行使用.用来判断两个实体对象是否可以合并需要遵循的一条基本原则是:判断他们代表了什么事件现象(occurrences).假如是代表了相同的现象,那么就应该仅仅存在一个实体对象;否则这两个实体对象就应该保持分离.假如最后决定两个实体对象应该合并,对象相关的操作,关联系和属性都需要集成到这个新的实体对象当中去. 在那些独立存在的实体对象中相类似的功能应该能够在这个新的实体对象中可以找到. 虽然我们也有可能在实体对象上创建操作,但即使有这种可能性也最好能够避免过度设计. 这些操作,最后将要在设计和实施阶段中完成.

 

7.3.3   Control objects

7.3.3 控制对象

We have now partitioned the flow of the usecase into interface objects and entity objects. In some cases everything in ause case has been placed in objects of these two types, in which case nocontrol objects are needed for that use case. However, in more complex use cases, thereoften remains behavior that is not naturally placed in either of these two objecttypes. Such behavior is placed in control objects. The reason thatsuch behavior is hard to place in either of the other object types is that itis behavior that does not really belong to the interface ol the system or tohow the information is handled. One possibility is to spread the behavior overthese object types anyway, as suggested by some methods, but that solution isnot ideal from a changeability perspective. A change in such behavior (oftenfunctionality) could then affect several objects and thus be hard (expensive)to incorporate; see the discussion on control objects in Chapter 6.

我们现在已经把用例模型对应的事件流程分配到不同的接口对象和实体对象当中.在一些情况下,用例模型的所有内容都已经分配到这两种类型的接口对象当中,这样一来在这些用例模型就不再需要控制对象.然而,在一些更加复杂用例模型中, 通常还会存在一些行为(behavior)无法自然合适地放置在这两种类型的对象当中.这样的一些行为就需要放置在控制对象当中. 这种系统行为难以放置在其他两种类型的对象任何一种当中, 究其原因要么是它的行为不属于真正的系统接口或者与信息是如何处理没有关联。一种可能的方式是把这些行为扩散(spread)到不同类型的对象当中去,就象其他一些面向对象分析方法所建议的一样,可是这样的一种解决方案从有效支持系统潜在变化的观点看来不理想的. 针对这样的行为的一个改变将会影响多个对象,这样一来就很难(昂贵)进行功能集成;详细的讨论可以见第6章中关于控制对象的讨论.

The control objects typically act as gluewhich unites the other objects so that they form one use case. They aretypically the most ephemeral of all the object types and usually last only aslong as the performance of one use case lasts. It is, however, difficult tostrike a balance between what is placed in entity objects, control objects andinterface objects. We will here give some heuristics as to how to find andspecify them.

控制对象的功能通常是作为对象之间的粘合剂,以便把其他的对象联结在一起,这样一来这些对象可以构成一个用例模型.控制对象通常是在所有的对象中持续时间最短暂的,并且他通常仅仅在用例模型执行期间激活.然而,如何把复杂的系统功能放置在实体对象,控制对象和接口对象之间是很难平衡与取舍的.我们在这里将提供一些启发式的原则来说明如何发现和识别这些控制对象.

Control objects are normally found directlyfrom the use cases. In a preliminary draft we will assign one control objectfor each concrete and abstract use case. Each use case normally involvesinterface objects and entity objects. Thus behavior that remains after theinterface objects and entity objects have been assigned their behavior will beplaced in the control objects.

控制对象通常是直接从用例模型中识别出来.在初步的分析模型草案中,我们将为每一个具体和抽象用例指派一个控制对象.没一个用例模型通常会包括接口对象和实体对象.这样那些不能划分到接口对象和控制对象当中的行为(behavior)将会被放置在控制对象当中.

Deviations from this initial approach canbe made for several reasons. The first is the extreme case where there is nobehavior in the use case left to model. A control object is not, of course,needed then. If, on the other hand, there remains behavior of a verycomplicated type (after the distribution of relevant behavior among interfacesand entity objects), the functionality may be divided into several controlobjects. They should then have limited tasks and will thus be simpler tounderstand and describe. If a control object is coupled to several differentactors this might indicate that the behavior is different for the differentactors and that it should therefore be split across several control objects.The aim should be to tie only one actor to each control object. The reason forthis is that system changes often originate from actors and, if each controlobject is dependent on only one actor, then changes in the system can beisolated.

偏离最初的分析模型方案可能是基于以下的几个理由.首先是一种极端的情况,假如所有的功能都合适的分配到接口对象和实体对象当中,这样用例模型中就没有功能留下来需要进行分配.一个控制对象当然也就不再需要了.然而在另外一方面,假如最后还留下一些非常复杂的行为类型(在已经完成了用例模型相关的功能行为已经在接口对象和实体对象之间进行了分配以后),这些功能就需要分配到几个不同的控制对象当中.他们应当仅仅负责完成有限的任务,同时这些任务必须是容易理解和描述的.假如一个控制对象和几个角色发生了耦合关联,这就意味着这个行为可能面向不同的角色提供不同的功能,因此他需要被分离为几个不同的控制对象.相关的设计目标是要保证每个控制对象仅仅为一个角色的用例模型而服务.这样做的原因是因为系统的功能变更通常是因为角色的需求所引起的,假如每一个控制对象仅仅依靠一个系统角色,这样一来系统功能引起的对象改变可以隔离在局部的范围内.

 

Typical types of functionality placed inthe control objects are transaction-related behavior, or control sequencesspecific to one or a few use cases, or functionality thats separates the entityobjects from the interface objects. The control objects tie together courses ofevents and thus carry on communication with other objects.

放置在控制对象的典型的功能包括和面向交易有关的行为,以及仅仅和一个或者少数几个特定用例模型相关的控制序列,或者是那些用来把实体对象和控制对象进行隔离的功能.控制对象负责把用例模型相关的事件流程进行粘合,并且和不同的对象进行全面的沟通

Let us again look at the use casedescription from the recycling model to see if we have any functionalitytypical of control objects. We have marked those parts of the use descriptioncase in italic.

   让我们再次回顾一下和废品回收机有关的用例模型描述,以便检查一下是否还有一些典型功能可以放置在控制对象当中.我们已经用斜体字符标记了在用例模型中相关的文字

When the customer returns a deposit item, itis measured by the system. The measurements are used to determine what kind ofcan, bottle or crate has been deposited. If accepted, the customer total isincremented, as is the daily total for that specific item type. If the item isnot accepted, the light for 'NOT VALID' is highlighted on the panel.

When the customer presses the receiptbutton, the printer prints the date. The customer total is calculated and thefollowing information printed on the receipt for each item type:

name

number returned

deposit value

total for this type

Finally the sum that the customer shouldreceive is printed on the receipt.

 

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

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

 名称

 返回的数量

 收据金额

 这种类型的总数.

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

 

This is a concrete use case that inheritsan abstract use case Print. The first option, namely one control object foreach (abstract and concrete) use case, would have given us two control objectshere. Returning Item is a use case that involves coupling the interface objectsand the entity objects together. This behavior is a good candidate for acontrol object. The Print use case, however, involves the behavior of printingon the line printer, but this behavior should be tied to the interface objectReceipt Printer. We thus do not assign a control object for this abstract usecase. We have not described the other use cases in detail here yet, so it isharder to tell whether or not a control object is needed for them. However, asa first approach, we could assign control objects for these use cases as well.Whether this is correct or not will be seen at the latest during construction,when explicitly defining the courses and the stimuli sent between the objects.The control objects will thus be as shown in Figure 7.24.

这是一个具体用例模型,他继承自一个抽象用例模型打印.第一种选择, 换句话说为每个用例模型(抽象用例和具体用例)分配一个控制对象,这种方式将会产生两个控制对象.在”回收物品”这个用例模型当中,包含一些将接口对象和实体对象进行耦合在一起的功能.这些行为都是作为控制对象的一个合适的候选.在”打印”这个用例模型当中,虽然也包括了在行式打印机上打印的功能,然而这个功能应该和接口对象Receipt Printer 绑定在一起.这样一来我们就不需要为这个抽象用例模型分配一个控制对象. 我们在这里还没有详细的描述其他的用例模型,所以很难决定这些用例模型是否需要各自的控制对象.然而,作为第一种解决方案,我们也将为这些剩余的用例模型分配对应的控制对象. 这种分析模型(系统功能在接口对象,控制对象和实体对象之间的分配)正确与否将会在最后的系统集成阶段进行判断,当已经明确了定义了用例模型中事件处理流程和对象之间发送的激励信号.相关的控制对象设计在图7.24中可以体现.

The description of a control object isfound indirectly from the use cases by checking how the use case runs over theother object types. In those places where a control object needs to beinvolved, the role the control object will take and what that role involves arestated.

 通过检查用例模型是如何在其他两种类型的对象之上运行的方法,一个控制对象的详细描述可以直接从用例模型中进行提取. 在那些需要包含一个控制对象的地方,控制对象将会执行用例模型需要的规则,并且规则中包含的详细内容将会被陈述.

Uses between use cases are often mapped tocommunication associations between the corresponding objects. If use cases havean extension association, this association can normally be transferred directlyinto an extension association between objects.

用例之间的使用Uses关系也常常会映射成为相应对象之间的通信关联关系.假如用例模型之间有一种扩展关系,这种用例之间的扩展关系extension通常会被直接转换成为对象之间的扩展关联.

To model the extensions in the recyclingexample we choose to use extensions between the control objects. The reason forthis is that we do not want to blur the specification of the Deposit ItemReceiver object. Instead we describe the Alarmist as something that will beinjected when an alarm occurs. We thus have the picture shown in

Figure 7.24 Controllers in the recyling machine.

Figure 7.25 Notethat in this example there are no communication associations between thecontrol objects.

为了对废品回收机案例当中用例之间的扩展关系进行建模,我们选择使用扩展关联来描述控制对象之间的关系. 这样建模的原因是因为我们不希望模糊控制对象”废品接收者”的功能定义.而代替的做法是我们把控制对象”告警者”描述为一种当告警发生以后需要插入的一种事物(控制对象).我们这样就获得了图7.25所描述的控制对象列表.注意在这个案例中,控制对象之间不存在通信关联的关系.

Figure 7.25 The complete view of the control objects in therecycling example.

 

7.3.4   Working with the analysis objects

7.3.4  基于分析对象开展工作

When working onthe development of the analysis model, normally we are working with one usecase at a time. Thus, for one specific use case, we identify interface objects,entity objects and control objects before continuing with the next use case.However, since the analysis objects are orthogonal to the use cases, in thesense that one object may participate in several use cases, this process isiterative. This means that when a set of objects already exists, these may bemodified to fit also the new use case. The goal is to form as stable astructure as possible, reusing as many objects as possible.

当进行分析模型的开发工作的时候,通常我们一次仅仅分析一个用例模型.这样针对一个特定的用例模型,我们将完整的识别出对应的接口对象,实体对象和控制对象,当前用例模型的分析工作不完成,就不会继续进行下一个用例模型的分析.然而,因为分析模型中的对象和用例模型之间是正交的关系,在这种意义下一个对象可以参与多个不同的用例模型,这种分析处理过程是迭代的.这也意味着当有一组对象已经存在着,这些对象可能需要被修改以便适配新的用例模型. 这种对象变更的目标是为了尽可能的构成一个稳定的体系结构,并且尽可能多的重用已有的对象.

 

Figure 7.25 The complete view of the control objects in therecycling example.

The specification of the objects should bewritten in a text form. The simplest way of doing this is just to copy the textfrom the use cases and paste it into the object descriptions. However, this isnot recommended as the text will then be out of context and thus can be hard tocomprehend. It is better to describe each object's role and responsibilitiesbearing in mind those of the other objects.

关于对象的定义应该是以一种文本的形式来记录. 将对象描述文本化最简单的方法就是将用例模型中的文本描述直接粘贴到对象的描述文档当中。然而,这种做法是不推荐的,因为这样的对象描述方式将缺乏上下文的参考,因此也将变得难以理解. 更加合适的做法是单独描述每个对象的规则和作用,并清楚的了解这个对象和其他对象之间的关联关系.

We have mentioned the use of operations tospecify the objects. This is possible, but it introduces a formalism that themodel may not be sufficiently stable to handle yet. Changes would then haveserious consequences. Even if operations are used, a formal syntax shoulddefinitely be avoided. When specifying an operation, it is tempting to usealmost pseudo-code to do the specification, but this should be avoided. Anychanges (and there will be changes!) will be very hard to introduce when thespecifications are rewritten. When describing behavior, concentrate on whatwill happen, not how it will happen. Generally, in system development theformalism should come creeping in when the structures grow stable and it shouldbe introduced incrementally.

我们已经提到过使用操作来定义对象的方式.这种定义方式是有可能的,但是这种方式引入了一种对象建模的规范形式,最后获得的对象模型将不能保持足够稳定来应对系统潜在功能变化.对象模型的改变将会带来非常严重的后果.即便使用了操作的方式,正式的语法定义必须要避免.当定义一个操作的时候,他试图使用伪代码来完成操作的规范工作,但是这一点是应该避免的.设想规范需要改写时,对象模型的任何改变(事实上也必然会存在改变)将会变得难以引入.当描述系统的行为的时候,重点关注什么(what)将会发生,而不是关注他如何(how)发生.一般来说,在系统的开发过程中,对象的规范化定义工作应当等到系统体系结构变得稳定以后再开始进行,并且是必须基于一种增量的方式来引入.

A technique for finding operations on theobjects from the use cases will be described in the next chapter. Thistechnique could very well be used, as previously mentioned, in the analysismodel. In our experience, however, it is too much work to use it in bothanalysis and design. If it is used in the analysis model, then the operationsshould as far as possible be kept the same in the design model to reduce the amountof redundant work. Thus, if you realize that the implementation environmentwill have very little effect on your analysis model, you can define operationsduring analysis; otherwise we recommend doing it during design.

在下一个章节中,我们将讨论如何从用例模型中识别对象需要操作的技巧. 这种技巧将能够非常合适的使用,正如前面在分析模型章节中提到的. 根据OOSE建模的经验, 实际上在分析模型和设计模型中都会花费大量的工作. 假如这种识别操作的方法已经在分析模型中使用,那么前期识别出来的这些操作应当尽可能长久的保持到设计模型当中,以便减少重复的工作.也就是说,假如你已经认识到后续的实施环境不会对你的分析模型产生很大的影响,那可以在分析阶段定义对象的操作,否则我们建议你在设计阶段完成相关的工作.

When the objects have been identified anddescribed, though, we may describe how the objects offer the use case; not asformally as specifying what stimuli will be sent between the objects, but in amore prose-like form. Initially, then, we often create a use case view of theobjects showing how they will be used in the use case. Let us look at the usecase Returning Item. Its view is shown in Figure 7.26.

当全部对象都已经被识别和描述,虽然,我们可以描述这些对象如何提供对用例模型的支持;我们不会正式的描述对象之间发送和接收的激励,而是使用一种类似散文的描述方法.最初的情况下,然后,我们会从用例模型的视图出发创造一幅描述对象协作关系图,这种协作关系图将说明对象如何在用例模型中使用.让我们来看看用例模型回收废品,他对应的视图将在图7.26中显示.

We may also describe the use case in termsof these objects to show how they will provide the use case. This descriptionwill help you to understand the use case and how it has been distributed overthe objects. Here is such a description for the use case Returning Item.

我们也可以基于这些对象来描述用例模型, 以便说明这些对象是如何提供用例模型的支持.这样的描述将会帮助你理解用例模型,以及他是如何分布到不同的对象当中.下面就是这样的一个关于用例模型回收废品的描述.

When the customer returns a deposit item the Customer Panel'ssensors measure its dimensions. These measurements are sent to the controlobject Deposit Item Receiver which checks via Deposit Item whether it isacceptable. If so, Receipt Basis increments the customer total and the dailytotal is also incremented. If it is not accepted, Deposit Item Receiver signalsthis back to Customer Panel which signals NOT VALID.

当顾客在废品回收机中放置了一个物品,顾客操作面板上的传感器先测量物品的尺寸.这些测量数据被发送到控制对象”Deposit Item Receiver “,他负责调用实体对象”DepositItem”来检查相关的物品是否可以接收.假如这个物品可以被系统接收,实体对象Receipt Basis 负责把客户回收物品的总数和当天回收物品的总数分别增加1个. 假如这个物品无法被系统所接收,控制对象”Deposit Item Receiver “则把拒绝信号回送给接口对象”CustomerPanel” 并会高亮显示” NOT VALID”.

 

Figure 7.26 The objects supporting the use caseReturning Item.

When the customer presses the receiptbutton, Customer Panel detects this and sends this message to Deposit ItemReceiver. Deposit Item Receiver first prints the date via Receipt Printer andthen asks Receipt Basis to go through the customer's returned items and sumthem. This information is sent back to Deposit Item Receiver which asks ReceiptPrinter to print it.

当顾客最后按下receipt按钮, 接口对象Customer Panel会检测到这个信号并把这个信号发送到控制对象”DepositItem Receiver”首先会通过接口对象Receipt Printer打印出当天的日期,接下来会询问实体对象Receipt Basis来核对顾客返回的物品情况并计算他们的数量.这些信息就会回送到控制对象Deposit Item Receiver,并由控制对象请求接口对象Receipt Printer来打印相关的控制信息.

 

We have seen here that the analysis modelwill not be a reflection of what the problem domain looks like. This isimportant to understand. The reason is simply to get a more maintainablestructure where changes will be local and thus manageable. We thus do not modelreality as it is, as object orientation is often said to do, but we model thereality as we want to see it and to highlight what is important in ourapplication.

我们在这里已经看到分析模型将不会直接反射出问题领域看起来的样子. 理解这一点是非常重要的.这样设计的目的简单来说是为了获得一个更加易于维护的体系结构,这样一来潜在的改变将会控制在局部的范围,所以更加易于维护.在OOSE方法中我们不会根据现实世界的情况直接进行建模,虽然这是很多面向对象方法所宣称的一种原则;但是我们根据我们期望的方式对现实世界进行建模型,并且会突出那些在我们应用系统中最重要一部分的内容.

 

7.3.5Subsystems

7.3.5 子系统

When the analysis objects have beenidentified, the system will contain a large number of objects. For amedium-sized project, typically between 30 and 100 objects will be specified.It is seldom possible to get a clear overview of this number of objects, so theobjects need to be placed in groups. This can be done at one or several levelsdepending on the size of the system. Such groups of objects are calledsubsystems. The system thus consists of a number of subsystems which canthemselves contain subsystems. At the bottom of such a hierarchy are theanalysis objects. Subsystems are thus a way of structuring the system forfurther development and maintenance.

当分析模型中所有的对象都已经被识别出来，系统中将包含大量的对象。针对一个中等规模的项目，通常会定义30-100个对象。针对如此数量规模的对象很难建立一个清晰的全局视图，因此这些对象需要分组放置。这种对象分组可以根据系统的规模进行一级或者是多级别的分组。这样的对象集合被称为子系统。系统就这样包含了一系列的子系统，而这些子系统本身也可以嵌套包含子系统。在这种层次化集合的底部就是分析对象。子系统就是一种对系统进行结构化管理的方式，以便更好的实现进一步的开发和维护工作。

The task of the subsystems is to packagethe objects so that complexity is reduced. The subsystems also work as handlingunits in the organization, for example for development, marketing, sales anddelivery. A subsystem can be a compulsory system unit, but it can also be anoptional unit.

建立子系统的目标是对对象进行分包管理，这样就可以降低系统的复杂性。子系统也是项目管理中的基本处理单元（handling units），举例来说系统开发，市场开发，销售和交付。一个子系统可以成为一个必须的系统单元，他同时也可以成为一个可选的单元。

The lowest level of subsystem is to beviewed as a change unit. We call these units service packages. These should be viewed as atomic; if the customerwants it, he will have the whole of it, otherwise he will get nothing. When thesystem is to undergo a minor change, this change should concern no more thanone such subsystem, or rather the objects contained in this subsystem. Thismeans that the most important criterion for this subsystem division ispredicting what the system changes will look like and then making the divisionon the basis of this assumption. One subsystem should therefore preferably becoupled to only one actor, since changes are usually caused by actors.

最低层的子系统可以被看成是一个可以变更的单元。我们把这些单元成为是服务包（service packages）。他们应当被看成是原子服务包，假如客户需要这个服务包，他将完整的获得这个包，否则他将一无所获。当系统将接受一个很小的变化，这种变化应当局限在这样的一个子系统当中，或者说被限制在这个子系统的对象当中。这就意味着对子系统划分最重要的原则是能够预见系统潜在改变的形态，同时基于这种系统的可变性假设来进行子系统的划分。一个子系统最好能够仅仅和一个角色来耦合，因为系统改变通常是由特定的角色来引起的。

The division into subsystems should also bebased on the functionality of the system. All objects which have a strongmutual functional coupling will be placed in the same subsystem (see Embley andWoodfield (1988) or Yourdon and Constantine(1979)). To identify objects with a strong mutual coupling, we can start withone object and study its environment. Another criterion for the division isthat there should be as little communication between different subsystems aspossible.

对子系统的划分工作也应当基于系统的功能需求。具有强相互耦合性的所有对象都应当放置在同一个子系统当中。(参考 Embley 和 Woodfield(1988) 或者Yourdon 和Constantine (1979)).为了识别具有强相互耦合性的对象，我们可以从一个对象开始分析，并研究他的运行环境。另外一个子系统划分的原则是尽可能的减少子系统之间的通信数量。

What is most convenient is to start lookingfor optional subsystems. Optional subsystems are not only those that areoptional for a specific delivery; anything that could be optional should beconsidered.

开始寻找可选的子系统是最方便的。可选子系统不仅仅是那些针对一个特定的项目交付而言是可选的部分，任何有可能成为可选部分的对象集合都应当予以考虑。

In the recycling example we can view allobjects handling the alarm as optional (the machine would work without analarm) and also functionally related. We thus may have one subsystem Alarm thatincludes the control object Alarmist and the interface object Alarm Device.

在废品回收机的案例中，我们可以把所以负责处理告警的那些对象看成是可选的（废品回收机在没有告警功能的情况下也能够运作），但同时也是功能相关的。我们就这样可以获得一个告警子系统，他包含了控制对象Alarmist和接口对象Alarm Device。

After the optional subsystems have beenidentified, what remains is often those objects that are central to the systemand therefore always have to be delivered. To distribute these among differentsubsystems, wewill need to look at the functionality of the system. All the objects involvedin a particular part of the functionality will be placed in the same subsystem.To identify functionality parts, we can look at each object. Whatwill happen if we remove this object? Objects that then become superfluous inone way or another, and are connected to the removed object, should thereforebe part of the same subsystem. There are several similar criteria which can beused to decide whether two objects are strongly functionally related. Therefollows a list of a few of them:

•    Will changes in one object lead to changesin the other object?

•    Do they communicate with the same actor?

•    Are both of them dependent on a thirdobject, such as an interface object or an entity object?

•    Does one object perform several operationson the other?

在那些可选的子系统都已经识别出来以后，剩下的那些对象通常对系统来说是非常核心，因此是必须提供交付的。为了在不同的子系统之间分配这些对象，我们需要分析系统提供的功能。包含在系统功能一个特定部分的所有对象都应当放置相同的子系统当中。为了识别不同的功能划分，我们可以分析每一个对象。设想假如我们删除这个对象将会发生什么样的情况？剩下的对象就有可能以一种方式或者是另外一种方式成为多余的；而有些对象有可能和删除的对象发生连接关系，因此就应该成为相同子系统的一部分。下面是一些类似的准则可以用来判断是否两个对象之间存在强关联关系。下面是这些规则列表中的一部分描述:

•    针对一个对象的改变是否会导致其他对象的改变？

•    这些对象是否和同一个角色进行通信？

•    他们是否都依赖另外一个第三方的对象，比如一个接口对象或者是一个实体对象？

•    一个对象是否对另外的对象执行几个操作？

 

The aim is to have strong functionalcoupling within a subsystem and a weak coupling between subsystems. A goodstart is to place the control object in a subsystem and then place stronglycoupled entity objects and interface objects in the same subsystem.

子系统划分的最终目标是获得子系统内部的对象强耦合关系，而子系统间是弱耦合关系。一个好的分析方法是开始把一个控制对象放置在一个子系统中，接着把哪些和他强相关的实体对象和接口对象也放置在相同的子系统当中。

If it seems very difficult to place aparticular object in a subsystem, it can be placed outside all subsystems. Thismay be because it is completely separate from other subsystems, or because ithas the same functional coupling to two or more subsystems so that it isdifficult to choose which one to place it in.

假如有一个特定的对象看起来很难放置到一个子系统当中。那么这个对象可以放置在所有子系统的外部。这种情况发生的原因是因为这个特定对象和其他的子系统都是完全分离的，或者是因为这个对象和其他两个及以上的子系统提供相同的功能耦合，这样一来就很难决定选择哪一个子系统来放置。

Let us apply these criteria to therecycling example. We have already identified the Alarm subsystem. Thefunctionality to handle all depositing is functionally strongly coupled andthus could be placed in one subsystem, Deposit. All objects involved in themanagement of the system could be placed in one subsystem, Administration. Theinterface object Receipt Printer could be placed in either of these twosubsystems since it is used in both places, so we choose to place it outsidethe subsystems. We thus have the picture in Figure 7.27. Further levels ofsubsystem are not needed here; the next level would be the system itself.

让我们针对废品回收机的案例来应用这些子系统划分的准则。我们已经识别出告警子系统。所有哪些负责处理物品存放功能的对象在功能上是强耦合的，因此也放置在一个子系统，Deposit当中。包含在系统管理功能的所有对象可以被放置在一个子系统，Administration当中。而接口对象Receipt Printer 可以放置在上述两个系统中的任何一个当中，因为他在两个地方都使用到了接口打印的功能，所以我们选择把他放置在所有子系统之外。我们最终获得了如图7.27所显示的子系统划分布局。在这里不需要进一步的子系统划分；上一层级就是整个系统本身。

 

We can test some criteria on this division,for instance, the number of actors dependent on a certain subsystem. Deposit isonly dependent on Customer; Administration is only dependent on Operator. Alarmis not related directly to one actor, but is used indirectly by both actors.The reason why it was placed as a separate subsystem was that it constituted acertain part of the functionality of the system.

我们可以针对上面的划分方式来测试这些准则，举例来说一个特定子系统依赖的角色数量。子系统Deposit仅仅依赖角色Customer，Administration 仅仅依赖角色 Operator。子系统Alarm不是直接和任何一个角色相关联，但是可以直接被这两个角色所使用。他被作为一个单独的子系统划分的原因是在于它构成了系统功能的特定部分。

When the division into subsystems is made,in some cases it may also be desirable to modify the analysis objects. This maybe the case, for instance, when an entity object has separate behavior that isfunctionally related to more than one subsystem. If this behavior is extracted,it may be easier to place the entity object in a subsystem.

当全部的子系统都已经划分完毕，在有些情况下也可能需要重新调整分析模型对象的设计。这可能是基于以下的个案，举个例子来说，假如一个实体具有分离的行为在功能上和多个子系统具有功能耦合关系。如果这种行为被提取，我们可能会更容易地把这个实体对象放置在一个子系统当中。

Figure 7.27   Subsystems inthe recycling machine.

To express how subsystems are related wecan assign a dependsOn relationbetween subsystems. This relation means that objects in one subsystem will use,in some way, objects in another subsystem. In the example above we see that theAdministration subsystem depends on the Deposit subsystem since ReportGenerator uses Deposit Item. Hence, if we deliver one subsystem, we must alsodeliver any subsystem that this subsystem depends on.

为了表达子系统之间是如何关联的，我们可以在子系统之间指定一种依赖关系dependsOn relation。这种依赖关系意味着在一个子系统中的一些对象将会以某种方式，使用其他子系统中的一些对象。在上面的案例中，我们看到Administration 子系统会依赖 Deposit 子系统，因为对象Report Generator会使用Deposit Item，因此，假如我们交付一个子系统，我们也必须交付供他依赖的所有子系统。

The subsystem division in small projects isnormally made at the end of the analysis, when the architecture is clear. Inlarger projects, however, it often must be done much earlier (in many cases,even before the analysis model has been developed). For large projects theremay thus be other criteria for subsystem division, for example:

在一些小型项目中通常是在分析模型的最后进行子系统的划分工作，此时系统的体系结构都已经非常清楚了。然而，在一些大型的项目中，则需要尽早的划分子系统（在很多情况下，甚至需要在分析模型开发之前确定子系统）。针对大型的项目，还有其他的一些因素会影响子系统的划分，举例来说：

• Differentdevelopment groups have different competence or resources and it may bedesirable to distribute the development work accordingly (the groups may alsobe geographically separated).

•    In a distributed environment, a subsystemmay be required at each logical node.

•    If an existing product can be used in thissystem, this product may be regarded as a subsystem.

•    不同的开发团队拥有不同的开发技能和开发资源，因此可以需要根据这些因素相应的分配开发工作。（这些开发团队有可能是在地理上分离的）

•    在一个分布式的计算环境中，一个子系统可能会在每一个逻辑节点之中存在。

•    如果有一个现存的产品在系统中使用，这个产品可以被看成是一个子系统。

In large systems it is often essential todevelop the system in layers. In that case a subsystem for base functionalityis developed on which applications are built; the applications then use thisbase functionality.

在一些大型系统的开发中，通常需要进行分层开发工作。在这样一种情况下会有一个底层的子系统来支持所有的基本功能，具体的应用将会基于这个基本层来开发；高层的应用层就可以使用这些基本的功能。

Figure 7.28 Anexample of structuring the system into one subsystem for base functionalitywhich is used by all application programmers and separate subsystems for eachapplication.

 

7.4Summary

7.4 总结

   The analysis process aims to define andspecify the system to be built. Two models are developed, the requirementsmodel and the analysis model. Both of these models are logical in the sensethat they do not incorporate any requirements from the actual implementationenvironment.

    分析过程的目标是定义和规范需要构建的系统。在分析过程阶段需要开发两个模型，需求模型和分析模型。这两个模型都是在逻辑上构建的，也就是说模型设计不会考虑来自实际集成环境的任何需求。

The requirements model uses actors and usecases to describe in detail each and every way of using the system from auser's perspective. Actors model external factors such as people or machinesthat interact with the system. Use cases are the flows that these actors willperform on the system. Use cases can be understood intuitively by non-technicalpersonnel and thus can form a basis for communication and definition of thefunctional requirements of the system, in collaboration with the potentialusers. As a support for defining the requirements model, a problem domainobject model is a strong tool, as it will form a common platform determiningwhat the system will handle. To attain a high degree of maintainability, theseproblem domain objects will not form a base for the realization of the system.As a complement to the use cases and the problem domain objects, it is alsoappropriate that the requirements model be accompanied by descriptions of thesystem interfaces.

需求模型使用角色和用例来详细描述使用系统的每一种和所有的方式，并且这种描述是从用户的观点出发。角色是对系统外部的要素进行建模型，例如人和那些和系统打交道的机器。而用例则是那些角色将要针对系统执行的事件流。用例可以被那些非专业人士直观的理解，因此可以构成双方沟通和系统性需求定义的基础，并且能够非常有效的和系统潜在的用户进行协作。作为需求模型的一个有效支撑，问题领域对象模型是一个强有力的工具，因为他构成了一个公共的平台来确定系统将要处理的内容。为了达到一个高度的可维护性，这些领域对象模型将不会直接构成系统实现的基础。作为用例模型和领域对象模型的一种补充，伴随需求模型附带提供系统接口描述也是一种很合适的建模方法。

 

The use case model will form a threadrunning through all development work in OOSE, from structuring the system todefining operations on the objects, and, not least, as a tool for doingintegration testing. We thus have a high degree of reusability for this model.

在OOSE方法中，用例模型将构成一个贯穿于所有开发工作的一条主线，从建立系统体系结构，到定义对象的操作，以及作为一个系统集成测试的工具。我们因此获得了一个可以高度重用的模型。

The analysis model is the second modeldeveloped in the analysis process. This model aims to form a logical andmaintainable structure in the system. It is logical in the sense that theactual implementation environment is not taken into account. The reason forthis is mainly to focus on the essential system functionality. Three objecttypes are used to structure the system: interface objects, entity objects andcontrol objects. The interface objects model all functionality that concernsthe system interfaces, the entity objects model all functionality that handlesthe actual information kept in the system for longer periods and the controlobjects model such functionality as is not naturally tied to any of the otherobjects (often mainly behavior). These object types are identified when the usecases are analyzed and broken down. The objects should provide the completefunctionality of the use cases. Subsystems are used to structure the system inlarger units. Subsystems group the objects in the analysis model.

分析模型是我们在分析过程中开发的第二个模型。开发这个模型的目标是构成一个逻辑的和可维护性结构的系统。 这其中逻辑性的含义指的是不会考虑具体实施环境的影响。这样做的主要原因主要是为了更好的聚焦在系统的必要功能设计。我们使用3种类型的对象来对构建系统体系结构: 接口对象，实体对象和控制对象。其中接口对象负责对所有那些处理系统接口的功能进行建模型；实体对象负责对所有需要在系统中长期保存的确定信息结构进行建模；而控制对象则负责对那些不会和接口对象和实体对象自然绑定的功能进行建模（通常主要是行为）。当用例模型被分析和分解，这些不同类型的对象将会被识别出来。这些对象将能够为用例模型提供完整的功能支持。子系统被用来把系统构建成一些大型的单元。子系统在分析模型中完成对象的组织。

The development of these models forms aniterative process, as they will undergo many changes before they become stable.Therefore not too much detail should be put into these models before they havereached a mature state. However, even if it is often wise to sketch subsequentmodels when developing the earlier ones, the early models must be stable beforework starts on the subsequent models.

 对于这些模型的开发构成了一个迭代的过程，因为分析过程中这些模型将会经历很多变化直到最后趋于稳定。因此，在这些模型到达一个成熟的状态以前，不要针对这些模型内部提供太多的细节描述。虽然在开发前期的模型的时候，最好能够对随后开发模型的概况有所了解，并给出设计草图；请记住在开始开发后续模型以前，一定要保证前期开发的模型保持稳定。