[译]OOSE第6章：Architecture 体系结构 6.4 需求模型

 

6.4 Requirements model

6.4 需求模型

6.4.1   Actorsand use cases

6.4.1 角色和用例

The firsttransformation made is from the requirement specification to the requirementsmodel. The requirements model consists of:

•    A use case model

•    Interface descriptions

•    A problem domain model

在OOSE方法中首先的转换工作是将需求描述文档转换为需求模型. 相关的需求模型包括:

•  一个用例模型

•  接口描述文档

•  一个问题领域模型

 

 The use case model uses actors and use cases(see Figure 6.10). These concepts are simply an aid to defining what existsoutside the system (actors) and what should be performed by the system (usecases).

  用例模型使用角色和用例( 见图6.10).这些概念是简单的一个辅助系统设计者来定义系统外部存在对象(角色actors),以及需要系统执行的操作(用例use cases).

The actors represent what interacts withthe system. They represent everything that needs to exchange information withthe system. Since the actors represent what is outside the system, we do notdescribe them in detail. Actors are not like other objects in the respect thattheir actions are non-deterministic. We differentiate between actors and users.The user is the actual person who uses the system, whereas an actor representsa certain role that a user can play. We regard an actor as a class and users asinstances of this class. These instances exist only when the user doessomething to the system. The same person can thus appear as instances ofseveral different actors. For instance, for a system we may have the actors pilotand clerk. Jim Smith is a user who sometimes acts as a pilot and sometimes actsas a clerk; but he performs different use cases dependent on the roles heplays.

角色代表了和系统进行交互的对象.他们代表了所有需要和系统交换信息的一切对象.既然角色代表了系统外部的对象, 我们不会对他们进行详细的描述. 角色在某些方面和其他的对象不同,因为他们的行为是非确定的. 在这里,我们需要明确的区分角色和用户的概念actorsand users. 用户代表了那些需要使用系统的确切的个人; 而角色则是代表了特定的规则, 这些规则规定可用户可以执行的交互方式.我们可以把角色当成一个类, 而用户可以作为这个类的一个实例.只有当用户利用系统执行工作时, 这些实例才确切的存在.同一个用户可以作为不同角色的实例而出现. 举个例子来说, 一个系统可以同时拥有2个角色飞行员和乘客. Jim Smith是一个用户,他有时候扮演飞行员的角色,有时候扮演乘客的角色; 而他具体执行的用例是取决于他和系统交互执行的规则.

An instance of an actor carries out anumber of different operations on the system. When a user uses the system, sheor he will perform a behaviorally related sequence of transactions in adialogue with the system. We call such a special sequence a use case. Anexample of a use case could be to Acknowledge a flight to be performed by aPilot. Each use case is a specific way of using the system and every executionof the use case may be viewed as an instance of the use case. When a user inputsa stimulus, the use case instance executes and starts a transaction belongingto the use case. This transaction consists of different actions to beperformed. A transaction is finished when the use case instance again awaits aninput stimulus from an actor instance. The use case instance exists as long asthe use case is operating.

一个角色的一个实例将针对系统执行一系列的操作. 当一个用户使用系统的时候, 他或者是她将利用和系统执行一段对话的方式执行一系列的交易行为. 我们把这样一个特殊的行为序列称为一个用例. 我们可以举用例的一个例子是由角色飞行员来确认一次飞行. 每一个用例是使用系统的一种特殊方式,  而关于用例的每一次执行可以看作是用例的一个实例an instance.当用户输入一个激励信号, 相关的用例实例负责执行并开启属于用例规则的一个交易过程.这个交易过程包含了需要执行的不同的动作.  当一个用例实例再次等待一个角色实例输入激励信号, 这一次的交易则执行完成. 在用例存在的时间, 对应的用例实例都会一直存在.

 

These use case instances follow, as do allinstances in an object-oriented system, a specific class. When a use case is performed,we therefore view this as we instantiate the use ease's class. A use case classis a description. This description specifies the transactions of the use case.The set of all use case descriptions specifies the complete functionality ofthe system. See Figure 6.11 for an illustration of a use case model.

这些用例实例, 就类似于面向对象系统中所有的实例一样,遵循于一个特殊的类.当一个用例被执行,我们因此认为用例操作是关于归属用例类的一次实例化.一个用例类是一个描述. 这个描述定义了用例的操作交易过程. 而关于所有用例集合的描述则定义了系统完整的功能模型.请参考图6.1 来查看关于用例模型的解释.

To view use cases as objects, classes andinstances is often unnatural to people used to OOP; but let us refer to thedefinitions in Chapter 3. There we stated that an object should have behaviorand a state. A use case is a complete flow in the system. Apparently such aflow does have a state (how far it has reached, what the state of the systemis). It also has behavior. We may view every interaction between an actor andthe system as the actor invoking new operations on a specific use case (forexample, 'start use case'). Thus a use case may be viewed as an object. Let usinvestigate the class and instance concepts. We see that many flows invoked byan actor have similar behavior (the same use case). In this way we can describethis use case and view this description as the use case's class. Likewise, whenwe start a use case we may view this as we create instances of this class. Wesee that use cases fit into all these definitions. The purpose of this is thatwe can use all the benefits of object-orientation when working with theseconcepts. Another possible way of looking at the use case is to view the systemas an object and the use cases as operations that are invoked in the system,but this is not the way we have chosen. If the reader has a hard time viewinguse cases as objects, it is actually not very crucial when reading this book.However, the reason we do it is to make it easier to work with architecturematters. We may thus view use cases as transactions with internal states,having something that represents the course which we can manipulate.

 

在OOSE方法中将用例当作是对象, 类和实例的这种分析方法常常会让熟悉面向对象程序设计的人感到不习惯; 但是让我们回过来参考第三章的定义. 在第三章中我们曾经声明过一个对象应该有行为和一个状态. 而一个用例是系统中一个完整的流程((a complete flow).显然这样一个流程的确拥有一个状态( 比如这个流程已经执行的步长, 当前系统的具体状态. 同时他有拥有行为. 我们可以把一个角色和系统之间的每一次操作看成是这个角色针对一个特殊的用例调用了一个新的操作.(举个例子来说, '开始用例')..这样一来一个用例可以被当作是一个对象. 让我们再次回顾类和实例的概念.  我们会发现一个用户调用的很多个流程都拥有类似的行为特征( 相同的用例). 在这种模式下, 我们可以描述这个用例, 并且把相关的描述当作是用例归属的类. 基于同样的原理, 当我们开始执行一个用例, 我们可以把这种操作看成是我们创建了这个用例类的多个实例. 我们看到用例完全符合上面的定义. 把用例当作是对象的目的是在于当我们利用这些概念来进行建模工作时, 我们可以复用面向对象的各种优点. 另外一种理解用例的方式是把系统当作是一个对象, 而把用例则当作是调用系统的操作, 但这不是我们OOSE方法选择的观点.  假如有些读者还是很难做到理解用例就是对象,  这对阅读本书也不会造成很大的影响. 然而,我们这样分析的原因是希望能够帮助大家更容易的理解应用体系结构的方法进行设计工作.我们可以这样认为用例是一些交易序列, 他们拥有内部的状态, 并拥有一些参数来代表这些进程, 而这些状态和参数是我们可以操控和处理的.

 

Hence the use casemodel is described by a number of actors and use cases. For the use cases, wemake detailed descriptions. When the system is in operation, instances arecreated from the descriptions in this model. We will later see that thesedescriptions are crucial to the identification of the actual objects in the system.

因此,用例模型是通过一系列的角色和用例来进行描述. 我们将针对每一个用例进行详细的描述. 当IT系统投入运营以后, 来源于用例模型规范描述的实例将被创建.在后面的分析中我们会发现关于用例模型的描述对于系统中真实对象的识别起到至关重要的影响.

6.4.2   Use case driven design

As we design inthis way, the system model will be use case driven. When we wish to change thesystem behavior, we remodel the appropriate actor and use case. The wholesystem architecture will be controlled by what the users wish to do with thesystem. As we have traceability through all models, we will be able to modifythe system from new requirements. We ask the users what they want to change(which use case) and see directly where these changes should be made in theother models.

因为我们能够遵循这种方式进行系统设计， 我们将获得一个基于用例驱动的系统模型。当我们希望改变系统的行为的时候，我们需要针对合适的角色和用例进行重新建模。整个系统的体系结构将根据用户期望利用系统执行的功能来决定和控制。因为我们具有在 OOSE的不同的模型之间进行跟踪的能力（traceability），我们就能够根据新需求模型要求来对系统进行变更管理。我们将询问具体哪一个用例用户希望进行变更，并且根据需要调整的用例模型，能够直接发现其他的模型中需要同步修改的部分。

Another importantcharacteristic of the requirements model is that we can discuss it with theusers and find out their requirements and preferences. This model is easy tounderstand and formulate from the user perspective, so we can easily talk tothe users and see if we are building the correct system according to theirrequirements. Since this is the first model to be developed, we can evaluatewhether the users are pleased with what we are about to design, before we startto build the actual system (see the operational paradigm of Agresti (1986)).

需求模型另外一个非常重大的特点是我们可以直接利用需求模型和用户进行需求沟通，并发现(find out)用户真实的需求和用户的偏好。需求模型是非常容量理解的，并且因为它是来源用户的视图来系统化的阐述，所以我们可以非常容易的基于需求模型和用户进行讨论，并且能够了解我们是否正在根据用户的需求构建合适的系统。因为这是软件过程中开发的第一个模型，，我们可以在开始建造真实的系统以前，提前评估用户是否对我们计划设计的系统感到满意。(see the操作范例 operational paradigm of Agresti(1986)).

To support the use case model it is oftenappropriate to develop the interfaces of the use cases as well. Here aprototype of the user interface is a perfect tool. In this way we can simulatethe use cases for the users by showing the user the views that she or he willsee when executing the use case in the system to be built. Additionally, tocommunicate with the potential users, it is often appropriate to sketch alogical and surveyable domain object model of the system. Such an object modelshould consist of problem domain objects, that is, objects that have a directcounterpart in the problem domain under consideration, and serve to support forthe development of the requirements model. This approach will be further discussedin Chapter 7.

为了更好的支持用例模型的描述，我们通常也需要根据用例模型来同步开发用户人机交互接口。这里提供用户界面原型是一个非常完美的工具.通过这种方式我们可以在用户面前模拟用例模型， 具体的做法是向用户显示详细的界面操作轨迹当我们面向未来目标系统执行各个不同的用例。另外，为了更好的和系统的潜在用户进行沟通，针对系统的领域对象模型进行逻辑上的，概略的描述是一种非常合适的做法。这样的领域对象模型应当包含了问题领域中存在的对象，也就是说，领域模型中的对象和问题领域的对象存在直接的映射关系， 并可以足够支持需求模型的开发。

 

The requirementsmodel can thus be regarded as formulating the functional requirementspecification based on the needs of the system users. In reality, arequirements model would be acceptable as a part of the requirementspecification, and we may perhaps use this for system tendering.

需求模型可以这样被认为是功能需求规范的系统阐述formulating，相关的需求规范是以系统用户的真实需求为基础的。在真实的项目管理中，把一个需求模型当成是需求规范的一部分的做法往往更加容被人接受，同时我们可以使用需求模型作为项目投标的材料。

The use case modelwill control the formation of all other models (see Figure 6.12). It isdeveloped in cooperation with the

 

domain objectmodel and it may, in cases where the domain object model is worked into adetailed object model, be expressed in terms of domain objects. Thefunctionality specified by the use cases is then structured into a logical,robust but implementation-environment-independent model - the analysis model -that is stable to changes. This model is adapted to the actual implementationenvironment and further refined in the design model, using the use cases todescribe how the use cases flow over the design objects. The use cases willthen be implemented by the source code in the implementation model. Finally theuse cases will give us a tool when testing the system, mainly duringintegration testing. The use case model will also give us support when writingmanuals and other operational instructions.

 

用例模型将控制其他所有模型的组成（见图6.12）

 

首先用例模型需要和领域模型联合进行协作开发；同时在领域模型进一步加工成为详细的对象模型的情况下，他可以依据领域模型的内容来表达。用例模型定义的功能需求将会进一步构造成为分析模型, 这是一个逻辑的，鲁棒性的，与具体开发环境无关的模型，在需求变化的情况下能够相对保持稳定。后续分析模型将适配目标集成环境并进一步精细化为设计模型，设计模型需要使用用例模型来描述用例规定的流程是如何在多个对象之间协作处理。用例模型还将通过源代码的方式在实施模型中被完成。 最后，用例模型在系统测试的时候将为我们提供一个测试工具，主要是在集成测试的场景下。用例模型在后续编写用户手册和操作指南的时候，也可以提供完备的支持。