[译]OOSE第7章：Analysis 分析 7.1 Introduction

 

7.1 Introduction

7.1 介绍

7.1.1   Why an analysis process?

7.1.1  为什么需要分析过程？

The aim of the analysis phase is to analyze, specify and define the system to be built. The models developed will describe what the system is to do. The basis of this modeling is basically the requirements (expressed in some form) of the system. It is important to carry on a dialogue with the prospective orderers and users, so that the system that is built is really what is wanted. In the analysis phase, it will then be possible to build models that will make it easier for us to understand the system.

系统分析阶段的目的是分析，具体说明并定义将要建立目标系统的结构和规格。项目团队开发的多个模型将描述系统能够执行的功能。系统建模的基础是基于系统的需求说明（通过某种形式来表达的）。能够和系统预期的订购者和使用者开展有效的对话是非常重要的一点，这样一来系统是基于用户期望的方式来构建的。在分析过程阶段，通过构建相关的模型将帮助我们更加容易的理解未来计划构建的目标系统。

The models that are developed during analysis are fully application-oriented, and no consideration is paid to the real imple¬mentation environment where the system is to be realized, for instance the programming language, DBMS, distribution or hardware configuration that should be used. This will be our definition of analysis: modeling the system with no regard to the actual implementation environment (see McMenamin and Palmer (1984)). The purpose is to formulate the problem and to build models able to solve the problem under ideal conditions. As the models are entirely problem-oriented, and no attention is paid to the real implementation environment, they are fairly straightforward to develop from a functionality viewpoint. The models can be discussed from the application's perspective, with application-oriented concepts. Thus it will be possible to discuss the models with the users of the system without using implementation terms.

在分析阶段开发的系统模型是完全面向应用的，而不需要考虑未来系统部署所处于的真实的实施环境；举个例子来说系统开发的编程语言，数据库系统，是否需要进行分布方式运算，以及将要使用的硬件。下面这句话就是我们关于分析过程的定义：“在完全不考虑系统确切实施环境的情况下对系统进行建模。(see McMenamin and Palmer (1984)). ”采用这种设计方法的目的是能够规定问题的性质，实现在理想条件下构建可以解决问题的系统模型。因为这些模型是完全面向问题的（problem-oriented），他们没有考虑真实实施环境的影响，所以这些模型是基于功能实现（a functionality viewpoint）观点非常直接开发的。另外这些模型可以从应用的视野来进行讨论，完全是面向应用概念的；因此项目开发团队将有可能和用户一起讨论系统模型，并且这种讨论是可以不借助系统实施专业术语条款的。

 

Sooner or later the system will have to be adapted to the prevailing conditions, ol course. This is done in construction, when all those considerations that have been neglected in analysis are taken into account. The fact that little heed is paid to the implementation environment will guarantee that the ensuing system architecture will be based on the problem and not on the conditions prevailing during the implementation. It will, of course, be impossible to develop the models entirely without consideration of their realization; the models and their architecture must be built so that everything in them can b? realized. Another great advantage with this procedure is that our analysis models will remain intact, if and when the implementation conditions change. Hence we can use the same models without changing them even if the implementation environment changes.

 

当然，或迟或早系统都将必须适配到当时的集成环境中。这个工作将在集成过程中实施，那时所有在分析阶段被忽视的因素都将被进行考虑。事实上，对系统实施环境投入非常少的关注将能够保障系统的体系结构是基于需要解决的问题来设计，而不是基于实施过程当时的条件。当然在现实的开发过程中，也不可能完全不考虑模型的实施要求来开发系统模型；这些模型和他们的体系结构必须能够合理的构建以便其中所有的部分都能够最终实现。使用分析模型另外一个巨大的好处是，假如当实施环境发生改变的时候， 我们的分析模型还能够保持完整intact。这样即便在实施环境发生变化的情况下，我们可以使用相同的模型。而不必要改变他们。

 

7.1.2   What is done in analysis?

7.1.2  在分析模型中做什么

Two different models are developed in analysis, the requirements model and the analysis model. The real base is the requirements specification and discussions with the prospective users (see Figure 7.1). The first model, the requirements model, should above all make it possible to delimit the system and to define its functionality. For this purpose we develop a conceptual picture of the system using problem domain objects and also specific interface descriptions of the system if they are meaningful for this system. We also describe the system as a number of use cases that are performed by a number of actors. The actors constitute the environment of the system, and the use cases are what takes place within the system. The use case concept is one of the unique concepts of OOSE.

在分析过程中将开发两个不同的模型，他们是需求模型和分析模型。分析过程真实的基础是需求规范文档和系统预期的用户进行讨论。（参考图7.1）.第一个模型，需要模型最重要的一点功能是能够划分系统的边界（什么是系统需要做的，什么是系统不需要做的），同时能够定义他的功能。为了这个目的，我们使用领域对象模型来开发系统的一幅整体概念图，同时也对系统的接口进行描述， 假如这些接口对系统的功能描述有意义的化。同时我们也把系统描述成为一系列的用例模型，这些用例模型是由多个不同角色来执行的。这些角色组成了系统应用的环境；而这些用例模型是在系统内部发生的事件。用例模型概念是OOSE方法中独有的一个概念。

 

 

Figure 7.1 On the basis of the requirements specification, both the require ments model and the analysis model are developed in the analysis process.

 

The analysis model gives a conceptual configuration of the system, consisting ol control objects, entity objects and interface objects. The purpose of this model is to develop a robust and extensible structure as a base for construction. Each of the object types has its own special contribution to make to this robustness, and together they will offer the total functionality that was specified in the requirements model. The analysis model does not have any counterpart in other methods, but is unique to OOSE, although, since the techniques that we use are orthogonal to the rest of the development, it is possible to add this model to other approaches as well. To manage the development, the analysis model may group objects in subsystems.

分析模型为系统提供了概念上的配置定义，包括控制对象，实体对象和接口对象。设计分析模型的目的是开发一个稳健的和具有可扩展性的结构作为系统集成的基础。每一种对象类型都也有他自己独特的贡献来实现系统的稳定性，同时这三种对象作为一个整体将提供在需求模型中详细定义的完整系统功能（total functionality）。分析模型没有任何核其他软件工程方法中的对应的部分， 分析模型是在OOSE方法中独一无二的一种模型，然而，因为分析模型这种技术和我们在后续开发过程中使用的技术具有某种正交特性， 我们也有可能在其他的软件工程开发方法中也添加这种模型。为了实现有效的管理开发， 分析模型将有可能对对象进行分组，通过子系统的方式来管理。

 

The analysis model comprises a total functional specification of the system we wish to develop, without any reference to the implementation environment. In the construction process we will construct the system from the analysis model. This is when adaptations are made to cater for the implementation language, the database management system, the architecture of the computer system and so on. Thus the design model and the analysis model are both models of the system we wish to build, but with different purposes. An object in one model can be directly traced an object in the other model, and vice versa. We call this traceability.

    分析模型包括了我们期望开发系统的完整的功能规范定义，而这种功能规范是不需要参考关于未来集成环境的要求。在系统的集成过程中，我们将根据分析模型来构建系统。在构建阶段，我们将照顾到实施语言，数据库管理系统，计算机体系结构等方面的要求来对分析模型进行适配开发。这样一来，分析模型和设计模型都是我们期待构建系统的的抽象模型，但是这两种模型是出于不同的设计目标。一种模型中的一个对象能够直接映射到另外一种模型中的另外的一个对象，等等。 我们把这种模型之间对象的映射关系，称为为可追踪性。

 

7.1.3   An example system

7.1.3   一个案例系统

Throughout the discussion of the analysis and the construction activities, we will show how the different concepts are used in practice, by developing a system. The system controls a recycling machine for returnable bottles, cans and crates (used in Europe to hold several bottles). The machine can be used by several customers at the same time and each customer can return all three types of item on the same occasion (see Figure 7.2).

贯穿于OOSE方法中分析和构建活动的讨论过程，我们将通过研发一个系统的方式来揭示如何在实践中应用这些不同的概念。这个案例系统将控制一个废品回收机，废品回收机的作用是回收瓶子，罐子和包装箱（包装箱在欧洲应用来把包多个瓶子）。这种废品回收机能够供几个顾客同时使用，而每一个用户可以在相同的场合下回收三种类型的物品。

Since there may be different types and sizes of bottle and can, the system has to check, for each item, what type has been returned. The system will register how many items each customer returns and, when the customer asks for a receipt, the system will print out what he or she deposited, the value of the returned items and the total return sum that will be paid to the customer.

因为市场上有不同类型和尺寸的瓶子和罐子，废品回收系统必须面向每一件物品执行检查，顾客回收的物品是什么类型。系统将记录每个用户提交了多少件物品，当用户要求提供收据的时候，系统将提供客户已经提交的物品清单，同时根据所有回收物品类型与数量的回收金额也将付给客户。

The system is also used by an operator. The operator wants to know how many items of each type have been returned during the day. At the end of the day, the operator asks for a printout of the total number of items that have been deposited in the machine on that particular day.  The operator should also be able to change information in the system, such as the deposit values of the items. If there is something amiss, for instance if a can gets stuck or if the receipt roll is finished, the operator will be called by a special alarm signal.

  这个系统也同时可供系统管理员来使用。系统管理员希望知道一天当中有每种类型的物品有多少件被回收。在一天结束的时候，系统管理员将申请打印在特定的当天系统已经回收不同类型物品的总数量。系统管理员也应该能够改变系统内部的信息，比如不同物体的回收价格。假如系统有一些部分不妥，比如一个罐子被卡住了，或者是收据卷轴用完了，系统管理员将被一种特殊的告警信号来通知。

Figure 7.2 The recycling machine can receive several different types of returnable item from several customers at the same time.

This example system is chosen as a case study that is easy to describe and to understand; it is not intended as an example of a good recycling machine. The system should be viewed as a toy example and should not be used as a basis for real system modeling. The descriptions that we give are too simple to be used in system design; nor should they be used as templates. The system is small, so the models will be small; consequently, all the properties of OOSE will not be fully obvious in this example. Later chapters of the book contain examples of OOSE used in larger systems, and they will give a clearer picture of how OOSE is used in larger developments.

 这个实验系统被选择作为一个案例学习，这样能够非常容易的描述和理解；他并不试图成为一个理想非常回收机的例子。 这个系统可以被看成是一个玩具级别的例子，同时不应该作为真实系统建模的基础。由于我们给出的描述过于简单，以至于无法在真实系统设计中使用，也无法作为一个设计模板来使用。由于案例系统是小型的，所以设计的模型也是小型的。因此，所有OOSE中应用的属性将不能完全在这个例子显示。本书后续的章节中间包含在大型系统中应用OOSE的例子，后续例子将给出在项目中应用OOSE方法的一幅清楚的图画。