[译]OOSE第7章：Analysis 分析 7.2 The requirements model 需求模型

 

7.2 The requirements model

7.2  需求模型

 

7.2.1   System development based on userrequirements

7.2.1   系统开发基于用户的需求

   Therequirements model aims to delimit the system and define the functionality thatthe system should offer. This model could function as a contract between thedeveloper and the orderer of the system and thus forms the developer's view ofwhat the customer wants. Therefore it is essential that non-OOSE practitionersshould also be able to read this model.

   需求模型的目标是划分系统的边界，并且能够定义系统必须提供的功能。这个模型的功能可以被当作为系统开发者和系统订购者之间的合同，同时他是构成了开发者的视图来理解客户希望的实现的功能。因此对于哪些没有OOSE实践经验的人也必须能够理解需求模型是非常基本的要求。

The requirement model will govern thedevelopment of all the other models, so the model is central throughout thewhole system development. The requirements model will be structured by theanalysis model, realized by the design model, implemented by the implementationmodel and tested by the testing model. Not only will the other models beverified against the requirements model, but the other models will actually bedeveloped directly from it. The requirements model will also function as abasis for the development of operational instructions and manuals, sinceanything that the system should do is described here from a user's perspective.The requirements model, and especially the use cases, will be the unifyingthread running through the whole of OOSE.

需求模型将领导和管理其他所有模型的开发工作，因此用例模型是贯穿于整个系统开发过程中最核心的模型。The requirements model will be structuredby the analysis model, realized by the design model, implemented by theimplementation model and tested by the testing model. 需求模型将会由分析模型来组织基本框架，由设计模型来描述具体的组成构件，由实施模型来最终完成实现，并由测试模型来验证功能是否到达。所有其他的模型不但需要根据需求模型来进行模型校验，而且其他所有模型需要直接根据需求模型来确定的进行开发。需求模型的功能同时也将作为系统操作指南和说明手册编写开发的基础， 因为系统应当执行的任何事情都是基于一个用户的观点来进行描述的。需求模型，尤其是用例模型，将是在整个OOSE设计过程中运行的一条主线。

Since the whole system development startsfrom what the users wish to be able to do with the system, we build the systemfrom the users' point of view. In this way, it will be easy to discuss therequirements model with the users, and changes to the model will be simple tomake.

因为整个系统的开发工作的起点是所有用户希望能够利用系统执行的工作；我们是围绕用户的观点来构建目标系统。通过这种方式，系统开发人员同用户讨论系统的需求模型将非常简单，同时对这些模型的改变也将非常易于实施。

The requirements model consists of threeparts: the use case model, the problem domain object model and user interfacedescriptions. The use case model specifies the functionality the system has tooffer from a user's perspective and we define what should take place inside thesystem. This model uses actors to represent roles the users can play, and usecases to represent what the users should be able to do with the system. Eachuse case is a complete course of events in the system, seen from a user'sperspective. If appropriate, interface descriptions may also be developed.These will specify in detail what the user interface will look like when theuse cases are performed. To give a conceptual picture and a betterunderstanding of the system, we use objects that represent occurrences in theproblem domain. This model will serve as a common foundation for all the peopleinvolved in the requirements analysis, developers as well as orderers.

 

需求模型包含3部分，他们是用例模型，问题领域对象模型和用户接口描述。The use case model specifies thefunctionality the system has to offer from a user's perspective and we definewhat should take place inside the system. 用例模型规范了那些IT系统从用户的观点出发必须提供的功能,同时我们定义在系统内部应该发生的事件。This model uses actors to represent rolesthe users can play, and use cases to represent what the users should be able todo with the system. 用例模型使用角色actors这个对象来代表用户可以执行的规则，而使用用例use cases这个对象来代表用户能够使用系统来做的事情。每一个用例都是在系统内部发生的一个完整的事件轨迹（过程），他是从用户的观点来看观察的。假如更加合适的方式，用户接口描述也可以同步开发。这些用户接口描述将指定当用例模型被执行的时候，用户接口的外观和界面布局。另外我们使用哪些代表了问题领域发生事件的对象进行对象建模，这样能够为系统给出一个概念图，并且能够更好的理解系统。领域对象模型将作为一个公共的基础服务于所有参与系统开发的人，包括需求分析，开发者，和订购者。

 

7.2.2 Actors

7.2.2 角色

In order to identify the use cases to beperformed in the system, we will identify the users of the system. This is doneby means of actors. Actors model the prospective users; the actor is a usertype or category, and when a user does something he or she acts as anoccurrence of this type. One person can instantiate (play the roles of) severaldifferent actors. Actors thus define roles that users can play.

为了能够有效识别哪些用例将在系统中执行，我们将首先识别系统的用户。对用户的识别主要是借助于角色来完成。角色Actors是对系统潜在用户归纳出对应的模型；角色是一种用户类型或者是分类；当用户在利用系统做一些事情，他或者是她是作为这位类型的一个发生对象。一个用户可以实例化（执行相关的规则）多个不同的角色。角色就这样定义了用户可以执行的规则。

The actors model anything that needs toexchange information with the system. Actors can model human users, but theycan also model other systems communicating with our system. The essential thingis that actors constitute anything that is external to the system we are todevelop.

角色可以针对任何需要和系统进行信息交换的对象进行建模。角色既可以针对人类用户进行建模， 同时也可以针对其他需要和我们系统进行通信的其他系统进行建模。关于角色最基本的一点是他构成了我们需要开发系统外部的任何事物对象。

Thus we will have to make a systemdelimitation to define where the boundary is between actors and use cases.

 这样，我们将不得不做出系统的边界划分，来定义角色和用例模型之间清晰的边界。

In our example of the recycling machine wecan see from the problem description that we have two actors, namely Customerand Operator. These are the only ones who should interact with the system. Theyinteract with the system in different ways: the Customer puts in bottles andsuchlike and receives a receipt from the machine, while the Operator maintainsthe machine and gets daily reports (see Figure 7.3).

在我们关于废品回收机的案例中，我们能够从问题描述中发现我们有两个角色，他们被称为顾客和管理员。这些是两个唯一的角色，能够和系统进行交互。他们是通过不同的方式来和系统进行交互：其中顾客是把瓶子，等废品放入到机器中，同时从废品回收机中接受一个收据；而系统管理员则维护机器，并获取日报（见图7.3）.

To stress the difference between actor anduser, we think of an actor as a class, that is, a description of a behavior. Auser, on the other hand, can play several roles, that is, serve as many actors.For instance, think of Brian. He is the operator of the machine, so he normallyacts as an instance of the Operator actor. However, sometimes he deposits hisown bottles and cans, and then he acts as an instance of Customer.

为了突出角色和用例的区别，我们可以把一个角色当作室一个类，也就是说，一个关于行为的描述。而一个用户，在另外一方面，可以执行几个不同的规则，换句话说，作为很多个不同的角色来伺服。举个例子来说，考虑用户Brian。他是废品回收机的系统管理员，所以他通常是作为角色系统管理员的一个实例。然为，有些时候，他也放置他个人的瓶子和罐子，那么在这种情况下，他是作为角色顾客的一个实例。

Finding actors can entail some work, andall the actors are seldom found at once. A good starting point is often tocheck why the system is to be designed. Who are the actors that the system issupposed to help? The actors who are going to use the system directly (maybe intheir daily work) we call primary actors. Each one of these actors will performone or some of the main tasks of the system. In our example, Customer is aprimary actor, as it is for the customers that the system is built.

寻找角色意味着一些工作，同时很难通过一次工作找全所有的角色。一个很好的出发点是经常检查一下为什么要设计这个目标IT系统。 谁是对应的角色应该由系统来提供帮助。哪些将要直接使用系统的用户（可能会是在每天的工作当中）被我们称为主要角色。每个这些角色之一将执行一个或者几个系统的主要任务。在我们的案例中，顾客是主要角色，因为是出于顾客应用的目的我们构建了废品回收机这个系统。

As all the important functions of thesystem are investigated, more and more primary actors are identified. Besidesthese primary actors there are actors supervising and maintaining the system.We call them secondary actors. Thesecondary actors exist only so that the primary actors can use the system. Inour example, Operator is a secondary actor, for we would not need an operatorif there were no customers

因为系统所有的重要功能都已经被调查，越来越多的主要角色被确定出来。除了这些主要角色，还有其他的角色来监控和维护这个系统。我们把他们称为次要角色。这些次要角色存在的目的在于主要角色能够更好的使用系统。在我们的案例中，系统管理员是一个次要角色，因为假如在没有顾客的情况下，我们也不需要操作员。

Figure 7.3 Therecycling machine has two actors: the Customer and the Operator.

We make the division into primary andsecondary actors because we want the system structure to be decided in terms ofthe main functionality. The primary actors will govern the system structure.Thus, when identifying use cases, we will start with the primary actors. Inthis way, we can guarantee that the architecture of the system will be adaptedto the most important users. Changes to the system will mainly come from theseactors.

我们将角色划分为主要角色和次要角色,这是因为我们希望系统结构是根据角色需要的主要功能来决定. 主要角色将决定系统的体系结构. 这样当我们识别用例模型的时候, 我们将从系统的主要角色开始. 通过这种方式,我们可以保障系统体系结构能够适应最重要用户的需求. 而对系统主要的改变也将主要来自这些主要用户.

It is often simple to find actors thatmodel people. It is more difficult to identify those which are machines, but asthe use cases are specified, it will become clearer that they are necessary.These actors can of course be both primary and secondary actors.

 通常我们很容易找到角色来对个人用户来建模. 可是要想识别那些是机器类型的角色, 然而当对应的用例模型被确定和定义, 我们会非常清楚的发现这些角色是非常必须的. 这些类型的角色也可以毫无疑问可以成为主要角色和次要角色.

Normally, we do not view the functionalityof the underlying system (for example, the operating system) as an actor. Forinstance, a system clock is not normally modeled as an actor. However, nothingstops us from modeling it as an actor. In some cases, for instance where theunderlying system has an active role with respect to the application, it isvery meaningful to model it as an actor.

通常,我们不会把底层的系统功能(举个例子来说操作系统)看成是一个角色. 举个例子来说,一个系统时钟通常不会被建模为一个角色. 然而,这一点也不是绝对的. 在一些特殊的场合下, 当底层的系统具有一个动态的规则和应用相关联, 那么将系统时钟建模为一个角色则是非常有现实意义的.

 

7.2.3   Use cases

7.2.3 用例模型

After we have defined what is outside oursystem we can define the functionality inside it. We do this by specifying usecases. A use case is a specific way of using the system by performing some partof the functionality. Each use case constitutes a complete course of eventsinitiated by an actor and it specifies the interaction that takes place betweenan actor and the system. A use case is thus a special sequence of relatedtransactions performed by an actor and the system in a dialogue. The collecteduse cases specify all the existing ways of using the system.

当我们已经定义了系统外部的对象和环境,我们可以定义系统内部的功能. 我们通过详细说明用例模型的方式来定义系统内部的功能.一个用例模型是一个种使用系统的特殊方式,具体来说是需要运行系统的一部分功能. 每个用例模型构成一个完整系列的事件,这一系列的事件是由一个角色来发起, 同时这个用例模型也定义可角色和系统之间的一种特定的交互规则. 一个用例模型是一种特殊序列的关联事务交易,这些交易由一个用户与系统通过交互式对话的模式来完成的. 用例模型的集合确切定义了能够使用系统的所有可能方式.

 

To understand usecases we can view their descriptions as state transition graphs. Each stimulussent between an actor and the system performs a state change in this graph. Wecan thus view a use case as existing in different states. The relatedtransactions mentioned above are thus the transitions in this graph.

  

为了更好的理解用例模型, 我们可以把用例模型的描述当作是一幅状态转移图. 在角色和系统之间发送的每一个激励完成了这幅状态转移图的一次状态变更. 我们可以这样把一个用例模型看成是一种存在, 这种存在有多个不同的状态.前面提到的关联事务交易是这幅状态转移图的变换与过渡.

 

The reason that we have identified actorsinitially is that they will be the major tool for finding the use cases. Each actorwill perform a number of use cases in the system. By going through all theactors and defining everything they will be able to do with the system, we willdefine the complete functionality of the system.

我们在用例建模过程中首先识别角色的原因是在于角色是用来发现用例的主要工具. 每个角色将在系统中完成一系列的用例模型.通过遍历目标系统的所有角色并且定义他们能够通过系统执行的每一件事情, 我们将能够定义系统完整的功能.

Like actors, use eases can be instantiatedand this is done every time a user performs a use case in the system. Thusthere is also a relationship between class and instance. This topic was discussedin greater depth in Chapter 6.

类似于角色, 用例模型可以能够被实例化, 并且这种实例化是由用户执行系统的一个用例模型来触发的. 这样我们也可以用类和实例的关系来描述用例的特点. 这个主题在第6章中已经经过了深入的讨论.

As several use cases can begin in a similarway, it is not always possible to decide what use case has been instantiated untilit is completed. Consider for instance a telephone exchange system. One actorhere is a subscriber, and a typical use case is to make a local telephone call.This use case starts when the subscriber lifts his telephone. Another use caseis to order a wake-up call. Both use cases start when the subscriber lifts histelephone. But when a subscriber lifts his telephone we do not know which usecase he wants to perform. Thus use cases may begin in a similar manner and wemay not know which use case was carried out until it is over. In other words,the actor does not demand that a use case should be performed; he onlyinitiates a course of events that will finally result in a complete use case.

因为多个用例模型开始的方式可能是类似的, 所以我们不可能在开始阶段判断具体是哪个用例在执行, 直到一个用例模型已经执行完毕才能得出结论. 我们可以假设考虑一个程控电话机的案例. 这里存在一个角色是一个电信用户,而一个典型的用例模型是电信用户能够呼叫一个本地电话通话. 当用户摘机以后,这个用例模型就开始了. 另外一个用例模型是用户订购了一个闹钟服务. 两个用例模型都是通过用户摘机来开始的. 可是当用户摘机以后,我们不知道他到底希望执行那一个具体的用例模型. 所以不同的用例模型都可以通过类似的方式开始, 而也许我们永远无法知道哪一个用例模型已经被启动直到相关的动作全部执行完毕. 换句话说, 一个角色不会要求那一个用例模型应当被执行; 他仅仅是执行了一系列的事件, 当这些事件全部执行完毕以后将决定一个完整的用例模型.

 

The use cases are identified through theactors. For every complete course of events initiated by an actor we identifyone use case. By considering each actor, we decide which use cases this actoris supposed to perform. To identify the use cases, we can read the requirementsspecification from an actor's perspective and carry on discussions with thosewho will act as actors. It will help to ask a number of questions, such as:

 我们已经说过用例模型是通过角色来识别的. 针对每一个由用户发起完整的序列事件,我们可以识别一个用例模型. 通过分析每一个角色的应用场景, 我们可以决定这个角色被期望来执行的所有用例模型. 为了能够有效的识别用例模型, 我们可以从一个角色的视角来阅读需求规范, 同时可以和那些将作为系统潜在角色来工作的用户开展需求讨论交流. 这将帮助我们咨询一系列的问题,比如:

•    What are the main tasks of each actor?

•    Will the actor have to read/write/change anyof the system information?

•    Will the actor have to inform the systemabout outside changes?

•    Does the actor wish to be informed aboutunexpected changes?

 

•    每一个角色的主要任务是什么?

•    对应的角色将需要读/写/改变系统的任何信息吗.

•    角色需要通知系统关于外部世界的任何变化吗?

•    角色希望被通知系统不希望的变化吗?

 

In the recycling system we can identify anumber of use cases. Let us use the actors as a starting point. The Customer isthe primary actor so let us start with her. She should of course be able toreturn deposit items. This forms one use case, Returning Item. This use caseshould include everything until a receipt is received, if it is to be complete.Are there any more use cases for Customer? The situation where an item is stuckis an alternative for this use case and we will discuss later how to handlealternatives. Otherwise, any more use cases are not obvious at the moment, solet us continue to the Operator. The Operator is a secondary actor. He shouldbe able to get a daily report of what items have been deposited today. Thiswill be one use case, Generate Daily Report. He should also be able to modifyinformation in the system, such as each item's deposit value. Let us call thisuse case Change Item. A use case is drawn as an ellipse with its name beneaththe ellipse (see also the box on notation). We now have the use case model asillustrated in Figure 7.4.

 

在废品回收机这个系统中,我们可以识别出多个用例模型. 让我们把角色作为一个开始的起点来分析用例模型. 其中角色顾客是主要角色,所以让我们从主要角色开始. 这将构成一个用例模型,  回收废品.  这个用例模型将包括连续接收多个不同类型的废品直到用户接收到一个收据, 假如这一次回收废品的用例将要结束. 针对角色顾客还存在更多的用例模型吗? 假如用户投递废品时卡住了机器这种情景则是这个用例的一种分支情况, 后续我们将讨论如何处理这种分支. 在别的方面没有明显发现角色顾客的其他更多用例,所以让我们继续针对角色管理员进行分析.  系统管理员是一个次要角色.他应当能够获取一个日报, 这个日报将汇总当天所有回收的废品详细清单. 这将成为另外一个用例, 生成日报.  他也应当能够变更系统内部的信息结构, 比如每一个物品的回收费用. 我们把这个用例称为改变物品费率. 一个用例是用一个椭圆来表示,在椭圆的下方标识了用例的名称(也可以查看框图下方的标识). 我们关于废品回收机的用例模型图见图7.4所显示.

 

Figure 7.4 The first attempt at the use case for the recyclingmachine.

The use cases can be summarized as follows:

这些用例模型可以通过下面的方式来总结:

Returning Item is started by Customer whenshe wants to return cans, bottles or crates. With each item that Customerplaces in the recycling machine, the system will increase the received numberof items from Customer as well as the daily total of this particular type. WhenCustomer has deposited all her items, she will press the receipt button to geta receipt on which the returned items have been printed as well as the totalreturn sum.

Generate Daily Report is started byOperator when he wants to print out information about the deposit itemsreturned during the day. The system will print out how many of each deposititem type have been received, as well as the overall total for the day. Thetotal number will be reset to zero to start a new daily report.

Change Item is used by Operator to changeinformation in the system. The return value as well as the size of eachreturnable item can be changed, and new types of item can be added.

  当用户希望回收瓶子,罐子,或者板条箱等废品时, 角色”顾客”将开始执行用例”回收费品”的操作. 当用户在废品回收机中每放置一个废品, 系统将把用户提交废品类型计数增加1个,同时在日报中这种特定类型物品的数量也会增加一个.当用户已经提交了所有的物品, 用户将会按下”收据”按钮来获取一个收据, 收据上将会打印本次用户提交的废品详情和返回的费用清单.

   当系统管理员希望打印出当天用户回收的废品总数时, 他将执行生成日报这个用例. 系统将会打印出当天每种类型废品的回收数量, 除此之外,当天所有物品的总数也会打印出来.

   系统管理员使用”改变物品费率”这个用例来改变系统内部的信息. 物品回收价格, 以及每一个可回收物品的规格都可以被改变,另外新类型的回收物品也可以增加..

 

On the notationconvention

  关于注释惯例 (补充阅读材料)

The notation used in figures has theconvention of one standard-sized symbol for each object type and the name ofthe object beneath the symbol. Additionally, relations are expressed in thefigure. However, no other information is normally introduced. Some othermethods introduce much more information in a figure, such as having informationinside the symbols.

在用例图中使用的注释拥有一种规范的惯例,包括用于表示不同类型对象的标准尺寸符号,以及在符号下方的对象名称. 另外对象的关系也在这张图中进行表达. 当然,通常不会在引入其他更多类型的的信息. 其他有一些建模方法会在用例图中增加更多的信息,比如在符号内部增加信息说明.

We have chosen this notation in order tohave a changeable and surveyable picture. If we had information inside the symbols,these they would need to be extended in size when we add more information. Thisextension affects the picture and may force us to move the other objects aswell. Hence the picture then depends on how far the details of the model haveevolved. Additionally, as we add more and more information it is very easy tolose the surveyability of the model.

 

在OOSE方法中选择这样的标注习惯是为了获得一个可以改变的模型图,同时方便设计者观察模型概况. 假如我们在图例符号内部添加信息, 设想当我们增加更多的信息时, 我们将不得不扩展图例符号的尺寸. 这种图例符号的尺寸扩展将影响模型图的布局,同时这有可能强迫我们也移动其他的对象. 这样,模型图的尺寸将会依赖模型中引伸出来细节的多少. 此外,当我们在模型图中增加更多的细节, 模型图的将会失去方便观察概况的优势.

 

Instead we think of the figure as a graphicview of information concerning the model in some information bank (database).We therefore assume a CASE tool will be used to handle this information bank.To add information to the model, we would just like to point at a specificobject and retrieve some information aspect of this object, such as a usecase's detailed description or operations on an object. In this way there is noneed to have different sizes of object, but rather we can preserve a view thatdoes not change when we change some information from another view and thatinformation is also shown in the first view.

Instead we think of the figure as a graphicview of information concerning the model in some information bank (database).We therefore assume a CASE tool will be used to handle this information bank.To add information to the model, we would just like to point at a specificobject and retrieve some information aspect of this object, such as a usecase's detailed description or operations on an object. In this way there is noneed to have different sizes of object, but rather we can preserve a view thatdoes not change when we change some information from another view and thatinformation is also shown in the first view.

另外当我们考虑模型图当作是描述信息银行(数据库)系统中信息模型的图形化视图. 我们因此假设需要使用一种建模工具来管理这个数据库系统.  为了增加模型的信息, 我们将希望直接选择一个特定的对象,同时获取这个对象一些方面的信息,比如用例模型的详细描述,或者是一个对象的操作接口说明.在这种方式下, 就没有需要让不同的对象保持不同的符号尺寸大小, 同时当我们改变另外一个模型视图的一些信息结构时候, 我们可以保持原有一个模型视图外观,同时在另外一个模型视图中改变的信息也会反映到第一个模型视图当中.

(补充阅读材料)

It is not always obvious what functionalityshould be placed in separate use cases, and what is only a variant of one andthe same use case. The complexity of the use cases is important in thiscontext. We have a number of different ways of expressing variants. If thedifferences are small, they can be described as variants of the same use case,either as just a selection within a use case or as separate variants of a usecase. If the differences are large they should be described as separate usecases. For instance, remember the telephone call use case. If the person beingcalled does not answer, is that a different use case from the one where heanswers? It will surely be different behavior. However, we would regard them asvariations of the same use case since they are logically highly correlated.

在进行用例建模时候, 通常不是很明显那一些系统功能应当放置在一个独立的用例模型中, 同时那些系统功能可能仅仅是同一个用例模型的一个变形情况. 关于用例模型的合成分析需要重点依赖应用上下文的考虑.我们有一系列的不同的方法来表达用例各种各样的变形. 假如用例的多个变形之间的差异很小, 他们可以描述为同一个用例的衍生, 既可以仅仅作为一个用例内部的分支选择, 又可以作为用例的一个单独衍生.假如这些差异很大的话, 他们应当通过不同的用例来描述. 举个例子来说, 记得我们前面提到的电话呼叫的用例. 假如用户在呼叫电话的时候被叫用户没有应答, 这种情况和被叫用户应答的情况是不同的用例模型吗? 显然这两种情况是具有不同的行为特点.然而,我们将会把他们当作是同一个用例的不同衍生,因为这两个情况在逻辑上是高度相关的.

We have as yet only discussed theidentification of use cases. This is often a very iterative process whereseveral attempts are made. When the picture stabilizes, each use case should bedescribed in more detail. First we describe the basic course, which is the mostimportant course of events giving the best understanding of the use case.Variants of the basic course of events, and errors that can occur are describedin alternative courses. Normally a use case has only one basic course, butseveral alternative courses. The descriptions could be made earlier, but sincethe requirements model will undergo several changes initially, too much workshould not be done early on, as it will be thrown away.

我们仅仅讨论了用例模型的识别. 这通常是一个非常反复(iterative)的过程, 需要尝试几种不同的设计. 当用例图最终固定下来, 每一个用例模型需要以更加详细的细节来描述.. 首先我们描述用例的基本流程, 这是最重要的事件流程,用来帮助用户以最好的方式理解用例模型.事件基本流程的衍生,以及可能发生的错误将在分支流程中描述. 通常一个用例模型仅仅有一个基本流程, 但是多个分支流程. 虽然用例模型的描述应当早点开始, 但是在开始的时候用例模型会经过好几次改变, 过多的用例描述是不需要的, 因为他们有可能被丢弃.

 

Thus we describe each use case in moredetail. Below is the flow description of the use case Returning Item:

 这样我们针对每一个用例模型描述了更多的细节. 下面是关于用例”回收废品”的流程描述:

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 cusomer total isincremented, as is the daily total for that specific item type. If the item isnot accepted, '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 thereceipt 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.

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

 名称

 返回的数量

 收据金额

 这种类型的总数.

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

When analyzing and describing the use casesin detail, the system is studied very closely. It is not surprising then thatpoints which are unclear in the requirements specification are revealed duringthis process. Vagueness in the requirements specification thus becomes obviousat a very early stage.

当我们对用例模型进行更加细节的分析和描述, 系统将会被非常的进行分析. 这一点并不惊奇, 在需求规范文档中不确定的问题点将通过这一过程真相大白. 在需求规范文档资料中不确定的地方就这样在项目分析的前期变得非常明显.

Since the use cases often focus on aparticular functionality of the system, it is possible to analyze the totalfunctionality of the system in an incremental way. In this manner we candevelop use cases for different functionality areas independently and laterjoin these use cases together to form the complete requirements model. We canthus focus on one problem at a time. This ability to take one part at a timealso opens the way to parallel development.

 因为用例模型通常是聚焦在系统的一个特定功能点, 这样我们有可能通过一种增量的方式来分析系统的整体功能.通过这种方法我们可以为不同的功能域, 独立进行用例模型设计; 后续将把这些用例模型聚合在一起来构成完整的需求模型. 这样一来我们可以在同一时间集中关注一个问题. 在同一时间处理一部分的能力也开启了后续并行开发的项目模式.

 

Extension

扩展

A powerful concept that is used tostructure and relate use case descriptions is the extension association.Extension specifies how one use case description may be inserted into, and thusextend, another use case description. Extensions to use cases can be describedin a very simple way and, in particular, changes and additions to functionalityare more easily made.

 扩展关联是一个非常有效的概念方法用于组织和关联用例模型描述. 扩展能够描述一个用例模型描述如何以一种可能的方式插入另外一个用例模型描述, 并且通过这种方式对他扩展. 针对已知用例模型进行扩展可以通过一种非常简单的方式进行描述, 尤其特别的是在改变,或者是增加功能点的场景下,用例建模型将会变得更加容易.

The use case where the new functionality isto be inserted must be a complete course in itself. Hence this description isentirely independent of the inserted course. In this way, the description paysno attention to any courses that might be inserted, and this additional degreeof complexity is thus avoided. So, we describe the first basic use cases totallyindependently of any extended functionality. Similarly, we can add newextensions without changing the original descriptions.

被用来插入新功能的用例模型本身必须要是一个完整的事件流程. 所以这个用例模型的描述是完全独立与后续插入的事件流程. 在这种方式下, 相关的描述完全不需要考虑后续可能要插入的任何事件流程; 因此集成插入用例的复杂程度能够有效避免. 这样一来, 我们可以独立的描述第一个基本用例模型, 而不必考虑任何后续的扩展功能. 同样的道理, 我们可以增加新的扩展用例,而不需要改变初始的描述.

In our example we can see one use of theextension concept. When an item is stuck the system should issue an alarm. Wecan describe this alarm .is a use case description that extends the ReturningItem use case description. This new use case we call Item Stuck (see Figure7.5). The extension association is drawn with a dashed arrow since it is aclass association (concerns the descriptions). Instance associations, asmentioned, are drawn with full lines. We have actually already seen suchassociations in the use case model, namely in the figure where actorscommunicated with use cases. This is an instance association since it is alwaysan instance of an actor that will communicate with an instance of a use case.

在我们的案例中,我们将会看到一个使用扩展概念的案例. 当一个物品在回收时候被卡住, 系统将会发出一个告警. 我们可以把这个系统告警描述为一个用例模型描述来扩展”回收废品”这个用例描述. 这个新用例模型我们称为”物品堵塞” (see Figure 7.5). 扩展关联在用例图上是用一个短划线箭头来描绘,因为扩展关联也是一种类的关联(涉及到对象关系描述). 而实例之间的关联系, 正如前面提到的, 是通过实线来描述. 我们已经在用例模型中确切的看见过这样的关联关系; 在用例图中角色和用例模型之间的通讯. 这是一种实例之间的关联关系, 因为通常是一个角色的实例将会和一个用例的实例进行通讯.

Thus Returning Item is described entirelyindependently of this new flow, which makes the description simple. The usecase Item Stuck can be described as follows.

这样用例回收废品可以完全独立于这个新的事件流程, 这样用例的描述就非常简单. 用例”物品堵塞”能够通过下面的方式进行描述:

When an item gets stuck the alarm isactivated to call the operator.

When the Operatorhas removed the stuck item he resets the alarm and the Customer can continue toreturn items. The Customer's total so far is still valid. The Customer does notget credit for the stuck item.

    当一个物品被堵塞在废品回收机中, 一个告警将会被激活来呼叫系统管理员. 当系统管理员已经清除了堵塞的物品, 他将复位告警,同时顾客可以继续回收废品. 而顾客回收的物品总量还是有效的. 而客户也不会因为堵塞的物品而获得收益.

What we see here is another use caseproperty: they can communicate with several different actors. Customer willstart the use case, but Operator will also communicate with it.

我们在这里看到的是另外一个性质的用例模型: 这个用例模型能够和几个不同的角色进行通讯. 角色顾客将开始这非用例模型, 而系统管理远也会和他进行通讯.

By means of the extension association thesystem will be given a good and modifiable structure, as we shall see later. Asit is possible to describe several use cases independently of each other, theirdescriptions will be simple. To understand extension better we can view atypical situation where we have a simple use case Login/Logout, and describeall use cases that may be done when a user is logged in by means of extensionsto the use case Login/Logout. It will then be simple to add new options withouthaving to make changes in the old use cases; new use cases are simply definedand used as extensions to Login/Logout (see Figure 7.6). (This situation is socommon that models often assume this functionality without specifying it.)

 

通过应用扩展关联这种方式,系统将会获得一个良好的,可以变更的结构, 这一点我们在后面将会看到.因为我们可以相互独立的描述几个不同的用例模型,这些用例模型的描述将会非常简单. 为了能够更好的理解扩展这个概念,我们可以考虑一个典型的场景,其中我们有一个简单的用例模型登陆/登出;同时我们可以通过扩展用例”登陆/登出”的方式来描述用户登陆系统以后所有可能的用例模型.这样将能够非常简单的增加新的可用例方案,而不必改变原有的用例方案; 新的用例能够非常简单的进行定义,同时作为”登陆/登出”的扩展来使用.参考图7.6. ( 这种场景是非常普通多见的,所以在用例建模中通常直接采用这些功能而不必要详细的定义他)

 

 

Figure7.5 Item Stuck is inserted into Returning Item when a deposit item gets stuck.

Figure 7.6 A common situation is having a use case Login/Logout into which severalother use cases can be inserted.

 

Another example of use of the extensionassociation is when you want to collect statistics in a specific use case. Say,for instance, that you have a use case that controls an industrial process.Every time you execute this use case, you also want to measure and collect somestatistics in this process. You can describe this by having a use case CollectStatistics as an extension use case to the control use case.

另外一个使用扩展关联的案例是假如你希望从一个特定的用例模型中收集统计报告. 举例来说, 假如你有一个用例模型是控制一个独立的进程. 每一次当你执行这个用例模型, 捏也希望测量和收集这个进程中的一些统计报告. 你可以把这个新用例”收集统计报告” 描述成为用例模型”控制进程”的一个扩展用例.

Extension is thus used to model extensionsof other, complete use cases. Here are some examples of when to use extend:

•    To model optional parts of use cases.

•    To model complex and alternative courseswhich seldom occur, for instance Item Stuck in our example.

•    To model separate sub-courses which areexecuted only in certain cases.

•    To model the situation where severaldifferent use cases can be inserted into a special use case, such asLogin/Logout mentioned above or a menu system with options.

 扩展关联是用来进行建模其他用例模型的扩展, 被扩展的用例必须是一个完整的用例. 这里有一些关于适合使用扩展的场景

••   来建模用例模型的可选择部分.

••      对那些复杂的分支流程进行建模, 这种分支流程通常很少发生, 举例来说是我们案例中的用例模型”物品堵塞”.

• •   对独立的子流程(sub-courses)进行建模, 这种子流程仅仅在特定的子流程下进行执行.

• •    针对多个不同的用例模型可以插入到一个特殊的用例模型这种情况进行建模, 比如前面提到的”登入/登出”用例, 或者是有很多可选择的菜单系统.

We might view the extension association asan interrupt in the original use case which occurs when the new use case is tobe inserted. The original use case does not know whether an interrupt willhappen or not.

我们可以把扩展关联看成是当有一个新的用例模型既将被插入的时候, 在开始的用例模型中的发生的一个中断.然而开始的用例模型将不知道是否有一个中断会发生.

For each use case that is to be insertedinto another use case, we state the position in the original use case where theextension use case is to be inserted. This position is stated as exactly aspossible, and is described in the extension use case (not in the original usecase). The position is expressed as a reference to a place in the original usecase's description.

针对每一个将要插入到另外用例模型中的扩展用例模型, 我们要声明在原始的用例模型中具体的位置, 在这个位置上扩展的用例模型将能够被插入.这个具体的插入点应该尽可能的描述的确定, 同时这种关于扩展点的描述是在扩展用例中进行描述( 而不是在开始的用例中. 这个扩展点将表示为原有用例模型描述中一个参考的位置点.

What happens when a course is inserted inthis way is as follows. The original use case runs as usual up to the pointwhere the new use case is to be inserted. At this point, the new course ininserted. After the extension has finished, the original course continues as ifnothing had happened. When we described Item Stuck we were somewhat inaccurate:the use case is not inserted only when an item gets stuck, but instead alwaystakes place. Actually, when an item has got stuck is always checked. If it has,the whole course is initiated; otherwise the original course Returning Itemcontinues directly.

  当一个事件流程按照如下这种方式插入到原有的用例中,会发生什么样的事情呢? 初始的用例模型将按照平时的方式运行直到这个有新用例模型插入的扩展点, 在这个扩展点上,新的用例模型将会被插入执行.当扩展用例模型执行完毕以后, 原有的用例模型将会被继续执行, 就象是扩展的用例模型没有发生一样.当我们描述用例”物品堵塞”的时候, 其实我们在某种程度上描述的并不准确: 这个用例模型不仅仅是当有物品被堵塞的情况下才会被插入,而是持续的发生. 确切的说, 是否有一个物品被堵塞是持续的进行检查. 假如有一个物品被堵塞, 扩展用例的整个事件流程将被初始化执行;否则,原来的事件流程回收废品会直接继续.

7.2.4   Interface descriptions

7.2.4   接口描述

When describing the use cases andcommunicating them to potential users, it is often appropriate to describe theinterfaces in more detail. If it is a Man-Machine Interface (MMI) we can usesketches of what the user will see on the screen when performing the use caseor provide more sophisticated simulations using a User Interface ManagementSystem (UIMS). In this way we can simulate the use cases as they will appear tothe users before even thinking about how to realize them. We can thus liven upthe use case descriptions with real computer interaction by the potentialusers. Such a technique will eliminate several possibilities formisunderstandings. If the interfaces are hardware protocols, we can refer tothe various standards. These interface descriptions are thus an essential partof the use case descriptions and should accompany them.

当我们对用例模型进行描述,同时和潜在的用户进行沟通用例模型的设计, 假如能够把用户接口描述更多的细节会比较可取.  假如IT系统是一个人机交互接口Man-Machine Interface (MMI) , 我们可以用设计图来描述当用户执行特定的用例模型的时候,用户将在屏幕上看到的界面, 或者使用一个人机交互系统来提供更加复杂的界面仿真. 通过这种方式, 我们可以提前模拟用例模型,仿佛就是他们正在用户面前发生一样, 此时我们甚至不需要考虑如何却实现这些用户界面. 这样我们可以面向系统的潜在用户通过真实的计算机交互方式非常生动地进行用例模型描述. 采用这种人机界面模拟技术将会有效的消除错误理解用例的各种可能性.假如接口是硬件协议, 我们可以参考不同的标准. 这些接口描述就是用例模型描述的基础部分,并且长期伴随用例模型描述而分析.

When designing user interfaces, it isessential to have the users involved. By doing a user interface design at thisearly stage, this can be guaranteed. It is also essential that the interfacereflects the user's logical view of the system. The problem domain model(discussed next) is exactly such a perspective. By using this model as aconceptual base to define the concepts and semantics of the system, we canguarantee that the user interface will be consistent with the user's logicalsystem perspective. This is actually one of the most fundamental principles ofhuman-interface design: the consistency between the user's conceptual pictureof the system and the system's actual behavior.

当需要进行用户界面接口设计的时候, 邀请用户参与设计和评审是非常基本的要求.通过在用例建模阶段进行用户界面接口设计, 这个基本的要求将能够被有效保障. 用户界面接口能够有效放映用户关于系统的逻辑视图也是另外一个基本的要求.问题领域对象模型(接下来将讨论的)就是这样的一个透视图. 通过使用问题领域对象模型作为一个概念基础来定义系统的概念和语意,我们可以保证用户界面接口能够和用户的逻辑系统视图保持一致. 这实际上是对人机界面设计的最根本原则之一:保持用户实际系统概念视图和系统确切行为的一致性.

It is not only user interfaces that areinteresting to specify in detail at this early stage. Since the requirementsmodel may be used as a functional requirements specification, it may at thisstage also be interesting to define other system interfaces such as communicationprotocols that should be standardized. These interface descriptions may alsotake the form of protocols to other systems.

在用例建模型这个早期阶段, 不仅仅需要非常详细的定义用户界面借口. 因为需求模型也将作为一个功能性需求规范, 在这个阶段能够详细定义系统和其他系统的接口也将非常有意义, 比如那些需要标准化的通讯接口.这些接口描述也可以采用和其他系统接口协议的形式.

The recycling machine has different kindsof interface. There is the customer panel which we mentioned earlier, includingbuttons, holes and alarm devices. There is also the receipt layout. Theseinterfaces are for the customer. The operator also needs an interface forchanging information, resetting alarms, requesting day summaries and so on.

这个废品回收机也有几种不同类型的接口.首先是我们前期提到的用户操作面板,包括按钮,孔,和告警设备,另外是收据的页面布局. 这些是提供给用户的接口. 系统管理员也需要一个接口来实现改变物品费率信息, 复位告警, 申请当天汇总报告,等等功能性要求.

 

7.2.5   Problemdomain objects

7.2.5   问题领域对象

When working with the requirements model itcan sometimes be difficult to define the task of the system and especially thesystem boundaries. This is typically the case when the requirementsspecification exists only in a very vague form. Then, a very good tool is tostart to develop a logical view of the system using problem domain objects,that is, objects that have a direct counterpart in the application environmentand that the system must know about.

当我们针对用例模型进行分析的时候, 用例分析师有时很难定义系统的任务, 尤其是定义系统的边界.尤其是当需求规范书描述的非常模糊的情况下, 这是一个非常典型的情况.这时,着手开始利用问题领域对象模型来开发系统的一个逻辑视图是一个非常好的工具,也就是说,寻找那些和应用环境有直接对应匹配关系的对象,同时IT系统也必须知道这些对象.

Such a problem domain model will help usdevelop a noun list which will be a strong support when we specify the usecases. From this model it is possible to define the concepts that the systemshould be working with. In this way we will have a glossary that can be used toformulate the functionality of the use cases. In the recycling system we seethat we have used the words 'returnable item', 'can', 'bottle' and 'crate'quite extensively without really defining them. When several people areinvolved in the specification of use cases, such a noun list derived from aproblem domain model can be of great value.

这样的一个问题领域对象模型将帮助我们开发一个名词列表;当我们开始定义用例模型的时候, 他将我们提供强有力的支持.  根据问题领域对象模型, 我们非常有可能定义相关的概念, 而系统应当以这些概念为工作对象. 在这种方式下,我们将获得一个词汇表, 他将可以被用于系统阐述每个用例模型的功能. 在前面介绍的废品回收机的案例中, 我们可以看到已经很广泛地使用了这些单词,比如: ‘可回收的废品’,’瓶子’,’罐子’和’板条箱’,但是我们并没有真正定义这些名词.当几个人一起来进行用例模型的分析和讨论, 这样一个从问题领域中派生出来的名词列表将产生巨大的价值.

The major benefit of such a model, though,is that it is a very good tool with which to communicate about the system.Since the users and orderers will recognize all the concepts, the model can beused when defining what the system will do. A technique we have used whenworking with such a model is to give the customer a pen and paper and ask himto draw a picture of his view of the system. By discussing it with him, a quiteextensive problem domain model will evolve. In this way we can also develop, asdescribed above, a common terminology when reasoning about the use cases, andso lessen the probability of misunderstandings between the developer and thepotential user.

归纳这种模型的主要好处，虽然,是在于他一个很好的工具可以用于和系统进行沟通。因为系统的使用者和订购者都将承认所有这些概念,当开始定义系统将要执行功能的时候,这些模型都能够使用. 当以问题领域对象模型为工作对象的时候,我们曾经使用的一种技巧是为用户提供一支笔和一张纸, 并请用户根据他对系统理解的视图画一幅概念图. 通过和用户讨论这一幅概念图, 一个非常广泛的问题领域对象模型将衍变出来.通过如前面所说的这种方式,当我们对用例模型进行分析的时候, 也同步开发了一个公共术语集合, 这样就减少了系统开发者和系统潜在用户之间误解的可能性.

 

Many otherobject-oriented methods, such as those of Coad and Yourdon (1991) and Booch(1991), focus entirely on such models, and the heuristics in these methods canvery well be used for the identification of these objects. In these methods, thismodel will also form a base for the actual implementation, that is, the objectsare directly mapped onto classes during implementation. However, this is notthe case in OOSE, as discussed in the previous chapter. Our experience withsuch an approach tells us differently. Instead we develop an analysis modelthat is more robust and maintainable in the face of future changes, rather thanusing a problem domain model to serve as the base for design andimplementation.

 

很多其他的面向对象的方法,比如那些Coad and Yourdon (1991) and Booch (1991)的方法,完全仅仅关注于这些领域对象模型,同时这些方法的启发方式可以非常方便的用于问题领域对象的识别.在这些方法中,相关的问题领域对象模型也将构成实际系统实现的基础, 也就是说,这些对象在实现过程中直接映射为类. 然而,正如前面的章节所提到的, 这不是在OOSE中应用的情况.在OOSE中应用的经验告诉我们不同的设计方法.替代的做法是,我们先开发义一个分析模型,这个分析模型在面对未来可能发生的潜在变化的时候, 可以更加稳定,并具有更好的可维护性;而不是直接使用领域对象模型作为设计和实现的基础.

 

How extensive should a problem domain modelactually be? In Figure 7.7 we have illustrated different possible degrees of refinement.

一个领域对象模型到底需要宽泛到什么程度呢? 在图7.7中,我们用图解的方式说明了领域模型优化的不同的可能程度.

Since the main purpose is to form a commonbase of understanding for developing the requirements model, and not to definethe system entirely, we believe that the object name and possibly also thelogical attributes and the static instance associations (that is, the staticreferences between these objects) are an appropriate level to stay at. However,it is of course possible to further refine these objects if it helpsunderstanding and thus specify the functionality of the system completely usingthese objects. It is fully possible to express the entire functionality asbehavior associated with these objects, but this will not yield the most robustand extensible structure for the system. Keep in mind that too much work heremay result in it being hard to free yourself from this structure whendeveloping the more stable and maintainable analysis model. Experience showsthat many (if not all) of these domain objects will

Figure7.7 Suggested possibilities to refine the problem domain objects. By staticinstance associations we mean associations that are used when an object shouldstatically know of another object, namely a static reference to an object.Dynamic instance associations indicate such associations where one object cansend stimuli to another object, which implies a dependence on the otherobject's protocol.

show up as entity objects in the analysismodel. However, it is dangerous lo do (his mapping mechanically, since theremay very well be changes (for example, if it is obvious that information on anobject is not actually needed in the system). Additionally, often there will beeven more entity objects in the analysis model than objects in the problemdomain model.

因为开发领域对象模型的主要目标是构成一个公共理解的基础来开发需求模型,而不是完整的定义系统,我们相信定义对象名称, 对象的逻辑属性和静态实例之间的关联关系(对象之间的静态参考关系)是一个合适的设计程度.当然, 假如深入的定义领域对象模型能够帮助理解系统的需求, 深入的优化定义对象也是完全有可能的;并且能够利用这些对象来定义系统完整的功能. 进一步通过定义这些对象之间动态的行为关联关系的方式来表达系统完整的功能也是完全有可能的; 但是采用这样的一种设计方式将无法产生一个稳健和扩展性的体系结构.请大家记住在这里开展过多的工作,详细的领域对象设计有可能会束缚设计者的思路, 导致他无法设计一个更加稳定和可以维护的分析模型. 经验显示很多(假如不是全部的话)领域对象将出现在分析模型中的实体模型中. 然而,直接机械的进行领域对象模型和实体对象模型之间的映射是非常危险的一种做法, 因为其中很多对象将会发生改变(举个例子来说, 比如一些领域对象的信息结构有可能是系统完全不需要的).此外, 经验告诉我们在分析模型中的实体对象通常会比问题领域模型中的对象要多.

 

In the recycling system, a problem domainmodel would be quite small since it is such a trivial system. The main conceptsused are Can, Bottle and Crate. These will all be handled in the same mannerand we can thus identify an abstract class Deposit Item. Since the customerwill have a receipt printed when all items have been returned, we may also needto be able to manage the objects Receipt and Customer. We will now have thedomain model shown in Figure 7.8.

  在废品回收机系统当中, 对应的问题领域模型将是一个非常小型的模型,因为这仅仅是一个实验性的系统.其中主要使用的概念包括瓶子,罐子和板条箱. 这些都将在相同的方式处理,所以我们可以通过这种方式识别出一个抽象类”回收物品”.因为当所有的物品都已经被回收,顾客将会接收到一个打印的收据,我们因此也可能需要管理对象收据和顾客. 现在我们将拥有一个领域对象模型,具体的图形见图7.8所显示.

 Figure 7.8 A problem domain model of the recycling machine.

In larger systems the use of the domainmodel becomes more obvious. In the example chapters later, we illustrate theuse of a problem domain model as a support for understanding a system in moredetail.

在大型IT系统的设计过程中, 借助领域对象模型辅助分析将会变得更加明显.在后续的案例章节中,我们将举例说明通过使用领域对象模型作为一个支持工具来更加详细的理解一个系统.

The problem domain model can be used forseveral different purposes. We have discussed above its supporting role in theformulation of use case descriptions and also in MMI design. We can alsoelaborate this model to gain a better understanding of the system. In this waywe can focus more on the problem domain objects. We can then specify thefunctionality of the system fully by using such a model and including formaloperations on objects, in which case we can also use it as a requirements modelexpressed without use cases. However, when continuing the development with themethod presented here, the use cases will be of much more help in theforthcoming work, and therefore we recommend elaborating these instead.

当我们进行企业建模的时候,问题领域对象模型也可以进行复用. 因此能够在一个模型中捕获所有重要的和基本的概念是非常必要的要求.实际上,通过对OOSE方法的扩展来包含企业建模将会最终交付一个问题领域模型作为输出,也就是说,领域对象模型将作为系统开发过程的输入.伴随着问题领域对象模型的定义, 他将成为企业系统信息化建模工作相关需求模型的第一个版本.通过这样的一种方式,企业建模和系统开发模型之间的转换可以通过一种无法缝的方式来执行.

Figure 7.8 A problem domain model of the recycling machine.

This means that a problem domain model,developed with some kind of technique, will serve as a very solid input tosystem development. In some projects we have been involved in, such a problemdomain model already existed. Then the idea of the system to be developed wasquite mature, and the development of the requirements model and the analysismodel could be done in a quite straightforward manner without too manyiterations.

   这同时意味着利用一些建模技术开发完成好的一个问题领域模型, 将作为系统开发非常确定的一个输入条件.在我们已经参与的一些项目中,客户已经直接为我们提供了这样一个领域对象模型. 因此关于系统将要开发的样式的思路是非常自然的,同时需求模型和分析模型可以通过一种非常直接的方式来开展,而不需要过多的迭代的过程.

 

7.2.6   Further refinement of the requirements model

7.2.6  针对需求模型的进一步精化

The requirements model as described thusfar will be sufficient to specify the functionality of the system. However, wecan elaborate this model further not only to enhance reuse, but also to preparefor the transition to the analysis model. This work is not really veryinteresting to the orderer of the system since it is moving into areas which donot concern him.

这里已经描述好的需求模型已经足够的充分来定义系统的整体功能.然而,我们可以进一步深入的阐述这些用例模型, 不仅仅考虑到对用例模型重用的增强,而且为用例模型向后续向分析模型的转换做好准备.这一部分的工作实际上对系统的订购者关系并不大,因为用例模型的精化不是客户感兴趣的领域.

This refinement is mainly done byidentifying similar parts of the use cases and extracting these similar parts.In this way we only have to describe the similar part once instead of in alluse cases showing this behavior. Any changes to this part will thusautomatically affect all use cases that share this part. We call the use casesthat we extract abstract use cases since they will not be instantiated on theirown, but are only meaningful to describe parts which are common to other usecases. We call the use cases that really will be instantiated concrete usecases.

关于用例模型的精化主要是通过识别这些用例模型的相似的部分,同时抽取这些相似的部分.通过这种方式,我们仅仅需要一次性的描述这些类似的部分,而不需要在所有用例模型中描述这些相似的行为.针对这些公共部分的任何改变能够自动的修改所有需要分享这个公共部分的用例模型.我们把这些在后期抽取的用例模型称为抽象用例子,因为他们不会通过自己来实例化,而是仅仅针对其他的一些用例模型的公共部分描述有含义.我们把那些确实会被用户实例化的用例模型称为具体用例模型.

The descriptions of the abstract use casesare thus used in the descriptions of the concrete use cases. This means that,when an instance of a use case follows the description of a concrete use case,at a certain point it continues by following the description of the abstractuse case instead. This relationship is thus some kind of inheritance. However,it does not have exactly the same semantics as inheritance has in anobject-oriented programming language. Therefore we give it a different name. Wecall this relation a uses relation. Intuitively, this is also easier tounderstand than inheritance as used in an OO language, since it is not discreteoperations that are used, but rather sequences. Therefore these sequences mayhave to be explicitly interleaved in the concrete use cases. Since it is aclass association it is drawn as a dashed arrow from the concrete towards theabstract use case that is to be used.

关于抽象用例的描述就以这种方式在具体用例的描述中进行应用. 这也意味着,当一个用例模型的实例将根据一个具体用例模型的流程描述来执行, 当用例执行到一个特定的断点的时候, 他将进行跳转,转为根据抽象用例的描述(具体用例所使用的抽象用例)进行执行. 这种具体模型和抽象模型之间的关联关系在某种意义上是是一种继承.然而这种关联关系和面向对象编程语言中定义的继承关联关系的语意有比较明显的区别.所以,我们为用例之间的这种关联关系赋予一种不同的名字.我们把这种关系称为一种使用关系.直观的来说,这种使用关系,比面向对象方法中的继承关系更加容易理解一些, 因为抽象用例不是一种离散的操作,而是一种序列化的操作,因为这是一种类之间的关联关系, 在用例图上”使用关系”是通过一根虚线箭头来表示, 箭头的方向是从具体用例指向对应的将要使用的抽象用例.

Normally, similar behavior between usecases is identified after the use cases have been described. However, in somecases it is possible to identify them earlier. In the recycling example we seethat the two use cases Returning Item and Generate Daily Report will both printout a receipt. We can thus identify an abstract use case Print that performsthis printing (see Figure 7.9).

通常,在所有的用例模型已经完成描述以后, 需求分析师将识别出不同用例之间的类似的行为. 然而,走某些情况下, 我们是有可能提前识别出这些共性的用例. 在上面提到的废品回收机的案例中,我们看到用例”回收废品”和用例”创建日报”都将打印出一个收据.这样我们可以识别出一个抽象用例模型”打印”来执行这个打印操作. (seeFigure 7.9).

Reuse between use cases is not limited toone abstract use case. Several parts that are common to other use cases may beextracted from a use case. One specific use case can then use all theseabstract use cases.

用例模型之间的重用不仅仅限制在一个抽象用例模型以内. 一组用例模型之间的几个不同的公共部分也有可能从一个用例模型中进行抽象. 这样一个特定用例可以就这样使用其他所有的抽象用例.

In use case decomposition, the entirecourse is always used. The course need not be an atomic sequence, although thisis often the case. However, we may have a situation where the abstract usecases can be used through interleaving them into the concrete use case (seeFigure 7.10). In the left-hand side abstract use case we have a sequence thatconsists of the subsequences A and B. These sequences should be integrated withsubsequences C and D as illustrated in Figure 7.10.

在用例模型的分解过程中, 通常需要使用完整的事件流程分析. 这个事件流程不一定需要是一个原子序列,虽然通常的用例模型会是这种情况. 然而我们可能会有一些地方, 可以通过对抽象用例的交织组合来描述一个具体的用例.(参见图7.10).从图的左边我们可以看见抽象用例使用了两个子序列A和B; 而这些子序列需要和子序列C和D进行集成,详细的描述见图7.10

Abstract use cases can also be used byother abstract use cases. It is difficult to state exactly when there is nopoint in extracting more abstract use cases. A good rule of thumb is that whenthe level of separate operations on objects has been reached, you ought tostop. The effort to find common sequences has then been carried too far. Withsome experience, it will soon become easy to discern where the limit should bedrawn.

理论上说,抽象用例也可以使用其他的抽象用例. 有时候,我们很难判定从抽象用例中已经不存在断点可以抽取新的抽象用例.一个好的经验法则是当抽象用例的抽取已经到达对象的独立操作的层面, 用例分析师就应该停下来.这也意味着关于抽象用例的抽取而提取的公共序列分析工作已经进行了过度的设计.这样很快就容易辨别,在合适的边界停止这项工作.

A technique to extract abstract use casesis to identify abstract actors. An abstract actor typically describes a rolethat should be

Figure 7.9 An abstract use case Print has been identified todescribe common parts between two other use cases.

Figure 7.10 A concrete uses case uses the two abstract use cases decides explicitlyhow the interleaving is to take place.

played against thesystem. When different actors play similar roles         they may inherit a common abstractactor. The advantage of abstract actor modeling is that it expressessimilarities in use cases. If the same part of a) use case may be performed byseveral different actors, the use cases need be specified only with respect toone actor instead to several.

一种用来提炼抽象用例的技术是先识别抽象角色.一个抽象角色同时描述了一种面向系统执行的规则. 假如不同的角色都执行类似的规则,他们就有可能来继承一个公共的抽象角色. 关于抽象角色建模的好处是在于他能够表达用例模型之间类似的地方.假如同一个用例的有可能被几个不同的角色来执行, 那么这个用例应当能够被一个角色来指动,而不是被多个角色来指定.

 

In the recycling system the actors actuallyhave one common behavior: they can receive a receipt. It is therefore possibleto identify one abstract actor, Receipt Receiver, which both Customer and Operatiorinherit (see Figure 7.11). Now both our concrete actors can receive a receiptand this needs to be specified only once.

 

在废品回收机的案例中, 角色顾客和角色系统管理员确实都拥有一个公共的行为: 他们可以接收一个收据. 因此,我们有可能识别出一个抽象角色, 收据收集者, 这个角色可以被角色顾客,和角色管理员来进行继承. 现在我们的两个具体角色都可以接收一个收据,而这种行为仅仅只需要定义一次.

 

Figure 7.11 Receipt Receiver is an abstract actor which isinherited by In Customer and Operator.

Abstract actors can also be used to specify different privileges ina system. An example of this will be shown in Chapter 13.

抽象角色也可以用于在系统中赋予不同的权限. 在第13章中,我们将显示一个这样的案例.

The uses association is thus used when twoor more use cases have common behavior. Normally, there is no reason to createabstract use cases that are used only by one use case. However, in fact, we hadthis situation with the extension association. An extension use case may beviewed as an abstract use case since it is seldom meaningful on its own.

当两个或者多个用例模型拥有公共的行为, “使用”这种关联关系就可以被应用.通常,假如一个抽象用例模型仅仅被一个用例模型来使用, 那么就不必要创建这样一来的抽象用例模型. 一个扩展用例模型也可以被看成是一个抽象模型,因为扩展用例模型本省通常很少对他自己具备意义的(扩展用例很少直接由角色启动).

Since the extension and uses associationsbetween use cases are both class associations, you may ask when should uses bechosen rather than extensions and vice versa? In fact, in most cases the choiceis quite obvious, and causes no problems. An important criterion is howstrongly functionally coupled the use cases are. If the course to be extendedis meaningful in its own right, the addition could be described usingextension. The extension then only needs access to the flow of control of theuse case being extended. If the courses are strongly functionally coupled, andthe insertion must take place in order to obtain a complete course, uses shouldbe chosen. There is also a difference in how they are found; uses are foundthrough extraction of common sequences from several different use cases,whereas extensions are found when new courses are introduced, or when there areextensions to an existing use case that the user wishes to perform in somespecific cases. You can be deceived by this rule, since extension use cases canalso be common to several use cases.

  既然用例模型之间的扩展关联和使用关联都是类之间的关联关系,你可能会问什么场合下应该应用”扩展关联”或者”使用关联”,诸如此类的问题?事实上, 在绝大多数的场景下用例之间关联关系的选择是非常明显的. 其中一个非常重要的因素是系统功能和用例模型的耦合程度.假如需要扩展的事件流程自身是有含义的,这些增加的部分可以通过扩展来描述. 扩展用例仅仅需要接入到那些被扩展用例模型的事件流程控制中.假如这些事件流程(抽象用例模型和具体用例模型)在功能上是紧密耦合的, 事件流程的插入必须执行以便来实现一个完整的用例模型, 那么在这种情况下就应该使用”使用关联”.另外,这两种关联关系的识别和发现方法也有一定的区别; “使用”关联主要是通过抽取几个不同用例模型的公共事件序列来完成; 而”扩展”用例主要是在需要引入新的事件流程的情况下进行识别,或者是一个已经知道的用例模型需要进行扩展,因为用户在一些特殊的场合下希望执行这个新加入的事件流程.你也可能回对这个规则感到疑惑, 因为扩展用例模型就这样也有可能被几个用例模型来公共使用.

7.2.7Discussion

7.2.7 讨论

As has been pointed out several times, theuse case is the core running through all OOSE activities when developing allmodels. Our experience with use cases is that they help us to focus on theproblem, as they constitute a strong tool for defining the systemfunctionality. Additionally, since they are logical and straightforward tofind, they force the development forward as the use cases are identified andspecified. They will also be a strong support when developing the subsequentmodels, since these models are based upon the use cases. So, a disciplined wayof working is natural as you control the work through the use cases. It is alsopossible to estimate the amount of work in subsequent models since you know howmany use cases you have and you can predict the time needed to handle one usecase. This topic is discussed further in Chapter 15.

正如前面已经多次指出的观点, 用例模型是贯穿于OOSE所有开发环节中最核心的模型, 他用于指导开发其他所有的模型. 我们应用用例模型的经验是他们帮助我们集中精力关注需要解决的问题, 因为他们构成了一个强大的工具来定义系统的功能. 此外,因为用例模型能够非常直接和科学的被发现与识别, 他能够直接控制开发工作的进程,当用例模型被识别和定义以后.用例模型也将成为一个强有力的支撑模型用于开发后续其他的模型,因为其他的模型都必须基于用例模型来开发.假如你能够利用用例模型来控制开发工作, 那么你就很自然的建立了一个非常科学严格的开发管理模式.同时利用用例模型也有可能来估计后续模型的开发工作, 因为你可以明确有多少个用例模型需要开发,同时你可以预言开发一个用例模型所需要花费的时间.这个主题后续还将在第15章中进行讨论.

When working with use cases, a commonquestion concerns how complete the use cases should be. For instance, in therecycling example, we could have viewed the sequence when the customer pushesthe start button and inserts the items as one use Case and the sequence when heor she pushes the receipt button as another use case. But we chose to have themas one complete use case instead. Generally, it is better to have longer andmore extensive use case* than several smaller ones. We want complete and realcourses and not several sub-courses. Otherwise there will be very many useeasel that are hard to keep track of and it will be harder to see how they arrrelated, in time, for instance. The arguments in favor of having the sequenceas one complete use case are:

当围绕用例模型开展工作的时候,一个共性的问题是关于一个用例模型到底需要多么完整呢. 举个例子来说, 在前面提到的废品回收机的例子, 我们可以把下面的序列流程: “当用户按下开始按钮, 放入一些回收物品”作为一个用例模型, 同时把另外一个序列流程”用户按下收据回收按钮”作为另外一个用例模型.可是我们选择把这两个序列合并成一个完整的序列流程. 一般来说,最好能够选择一个更加完整和有更加扩展性的用例模型比几个更小的用例模型要更加合适.我们需要的是完整的和真实的事件流程,而不需要几个子流程.否则将会出现很多用例模型,这样一来就很难及时的跟踪这些用例模型的实现,以及从整体上分析这些用例模型的关联关系,举例来说.关于赞成将这些事件序列作为一个完整用例模型的理由说明如下:

•    When specifying the use case, we may followa complete flow through the entire system.

•    From the orderer's point of view it is alogical cohesive flow of events in the system.

•    It may be more effective when testing theuse case since It covers more logical cohesive events in the system andfailure* can be found more easily.

•    It is easier to synchronize the use casesince it is one sequence that starts different events in chronological order.

•    当定义用例模型的时候,我们可能需要执行的是一个贯穿整个系统的完整事件流程.

•    从系统订购者的观点来看,用例模型应该是一个在逻辑上紧密结合的事件流程

•    . 这种方式会更加有利于对用例模型进行测试,因为他覆盖了系统中在逻辑上紧密结合的事件流程,所以更加容易发现错误.

•    对用例模型的同步将更加容易,因为他是一个事件序列, 其中各个事件是根据时间顺序来开始的.

 

The arguments in favor of separating theuse case into several different use cases are:

•    It may be troublesome to find the rightinstance of a use case that is of large extent since the use case may very welllast for several days.

•    From a potential actor's view it is morelogical to have use cases that the actor starts.

•    It may be easier to test the use case sinceevery use case starts from external events and not from internal system events.

关于赞成将这些事件序列作为分离为几个一个用例模型的理由说明如下:

•    聚合用例模型有可能会导致难以找到一个用例模型正确的实例,因为一些包含多个事件序列的情况下,用例模型有可能会持续好几天.

•    从一个系统潜在角色的观点, 用例模型由真实角色来启动会更加具有逻辑性.

•    这将更加优有利于对用例模型进行测试,因为每个用例模型都是从外部事件开始,而不时从内部系统事件开始.