[译]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 of the system. This is done initially by developing the analysis model. In the analysis model we describe the system using three different types of object: interface objects, entity objects and control objects (see Figure 7.12). Each of these objects has its own purpose and will model one specific aspect of the system. We also use subsystems to group these objects into manageable units.

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

In the requirements 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 and will also form the basis of the design. The requirements model is thus structured by the analysis model.

Figure 7.12 The object types used to structure the system in the analysis model.

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

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

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

We will now study the different object types more closely and discuss how it is possible to find them from the use cases.

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

Figure 7.13 Use cases and objects are different views of the same system. An object can therefore typically participate in several use cases.

 

7.3.1   Interface objects

7.3.1 接口对象

All functionality specified in the use case descriptions that is directly dependent on the system environment is placed in interface objects. It is through these objects that the actors communicate with the system. The task of an interface object is to translate the actor's input to the system into events in the system, and to translate those events in the system that the actor is interested in into something which is presented to the actor. Interface objects can, in other words, describe bidirectional communication between the system and its users.

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

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

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

Each concrete actor needs its own interface for its communication with the system. In many cases an actor may need several interface objects. In the example of the recycling machine, each of the concrete actors, Customer and Operator, needs its own interface object to the system. The Customer needs the panel with the push-buttons and the slots in which to insert the items and the Operator needs his interface to be able to change information in the system and to generate daily reports. Furthermore, we need an interface object to call the Operator when an alarm is issued, as well as one to print out a receipt. We thus have the interface objects shown in Figure 7.14. Finding an interface object for an abstract actor does not always occur, 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 have marked the places in the use case description below where interface functionality is involved. Note that the use case description has been taken directly from the requirements model.

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

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

When the customer returns a deposit item, it is measured by the system. The measurements are used to determine what kind of can, bottle or crate has been deposited. If accepted, the customer total is incremented, as is the daily total 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, the printer prints the date. The customer total is calculated and the following information printed on the receipt for      each item type:

name

number returned

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

deposit value

total for this type

Finally the sum that the customer should receive is printed on the receipt.

 

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

 

 

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

 名称

 返回的数量

 收据金额

 这种类型的总数.

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

 

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

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

The following is a short description of the interface objects identified:

Customer panel

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

Operator panel

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

Alarm device

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

Receipt printer

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

 

 

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

顾客控制面板

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

 

管理员控制面板

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

 

告警设备

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

 

收据打印机

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

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

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

 

An object may associate several other instances of the same class. Therefore we should also describe how many instances can be associated with the acquaintance association. This is done by assigning a cardinality(基数) to each association. This cardinality says how many instances can be associated. We also give the acquaintance association(相识关联) a name clarifying what the relationship entails. The properties of these associations and naming conventions are discussed in the box on naming associations. A complete view of the interface objects in the example is shown in Figure 7.15. The cardinalities in this example are all [1] since the different interface objects can only know of one object each. Another example of cardinality is [0..N], which means that we might associate any number between 0 and N. An acquaintance association is thus a static instance association 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 associations of the recycling machine.

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

 

On naming associations

关于命名关联

(补充阅读材料)

Models including relations often represent a model of the real world. It is common to name associations so that the sequence object-relation-object naturally forms a sentence. Consider for instance the relation shown in Figure 7.16. Here a verb phrase is used and we can 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 using a verb phrase.

 

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

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

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

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

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

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

(1) There is a large and fundamental difference between data modeling and object orientation. In data modeling you think of the model as a flat structure viewed from above. In this way it is natural to see the relationship as a binding between two objects. The relationship here is often bidirectional. In object orientation however, the view is instead taken from an object. When you look at this model, you place yourself 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 is unidirectional. This fundamental difference is often hard to get used to for people used to data modeling. But object orientation often models reality, so think about how the world around you looks. One Objectory user, experienced in data modeling, stated: '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 using a verb phrase.

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

So why aren't the relations bidirectional?' True, but what if you know about the king of Sweden? Does that mean that he knows about you? Normally not. Relations in the real world may be both bidirectional and unidirectional. However, the relations always start from the objects. In the married example, the wife knows about her husband and the husband knows about his wife. To treat the associations as unidirectional is thus 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 using a verb phrase.

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

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

 

 

           (2) Data modeling is often used in combination with relational databases. Here the relationship between objects will not be explicit, but rather it will be implicitly expressed as foreign keys and JOINs between tables. In an object-oriented implementation, however, the relationship will be made much more explicit. Here the relationship will exist in some way, normally as an instance variable implemented in a class.