[译]OOSE第6章：Architecture 体系结构 6.7 实施模型 & 6.8 测试模型 & 6.9 总结

6.7 The implementation model

6.7 实施模型

The implementation model consists of the annotated source code. The information space is the one that the programming language uses. Note that we do not require an object-oriented programming language; the technique may be used with any programming language to obtain an object-oriented structure of the system. However, an object-oriented programming language is desirable since all fundamental concepts can easily be mapped onto language constructs.

    实施模型包含了那些标记的源代码。信息空间是一个由编程语言使用的对象。注意，在OOSE方法中我们并不需要面向对象的程序设计语言；这种软件工程技术可以应用于任何的程序设计语言来获得一个面向对象的系统结构。然而，使用面向对象的编程语言是非常合适的，因为所有基本概念可以很容易地映射到的语言结构。

The base for the implementation is the design model. Here we have specified the interface of each block and also have described the behavior of what is expected behind this interface. How this description may look will be discussed in the construction chapter.

软件集成实施的基础是设计模型。在这里我们已经为每一个功能块定义了接口，并且也已经描述了在接口背后希望发生的行为。这些关于行为的描述会是什么样子将在后续的构建章节中进行讨论。

We stated earlier that it is strongly desirable to have an easy match between a block and the actual object module (that is, class, package, module or whatever the concept is in the programming language). In many cases we can do a very easy match from one block to one class in the implementation language. When we have a very smooth implementation environment this is typically the case. However in more complex environments this is not always the case. In one project where Objectory was used, an entity block ended up using 17 (!) classes in C++ for the implementation. However, it was a very complex implementation because a relational DBMS was used. The implementation included things like type conversion, keying, error handling, versioning and suchlike. This is not a normal case. Typically, one block will map onto about 1-5 classes. In the example chapters later on, we will illustrate some more complex blocks.

我们前期就提到过能够保持一个功能模块和确切的对象模块的简单匹配关系是非常令人满意的。（也就是说，class, package, module，或者不管是什么对应的概念在编程语言中）.在很多情况下，我们能够非常容易的从一个功能块映射到开发语言中的一个类。当我们拥有一个非常平滑的实施环境时，这就是典型的情况。然而，在很多复杂的环境中，就不是这样的情况。在一个应用Objectory 的项目中，一个实体对象最终是通过C++中多达17个类来实施完成。然而，那是一个非常复杂的实施方案，因为我们使用了关系型数据库。实施工作中包含的内容有类型转换，关键字索引，错误处理，版本控等方面的内容。这就不是一个普通的情况。通常的情况，是一个功能模块将映射为大约1到5个类。在后续章节的案例中，我们将接受一些更加复杂的功能模块。

 

The ability to use components is a very powerful implementation tool. Components are fully implemented parts which enable us to build a system with more powerful concepts (higher abstraction) than the programming language can offer us. Components can be regarded as completed building elements which are already placed in the implementation space and that can be used directly in our system. Components and how to use them will be discussed in more detail in Chapter 11.

应用组件开发的能力是一个非常强有力的实施工具。组件是一个完整集成的部分，他比较于程序设计语言来说，能够允许我们利用更加有力的概念（更高层次的抽象）来构建系统，这种更高层次的抽象能力不是程序设计语言所能够提供的。组件可以被认为是已经放置在实施空间（implementation space）中完整的构建单元，他可以在我们的系统中直接进行试用。关于组件的概念，以及如何使用组件将在11章中进行更加详细的讨论。

 

6.8 Test model

6.8  测试模型

The test model is the last model developed in the system development. It describes, simply stated, the result of the testing. The fundamental concepts in testing are mainly the test specification and the test result.

   测试模型是系统开发阶段开发的最后一个模型。 他负责描述，也可以使简单的陈述测试的结果品。测试中的基本概念主要是测试定义和测试结果。

Initially, the lower levels, such as object modules and blocks, are tested. These are tested by the designers. Lower subsystem levels are then tested. The integration test does not come as a 'big bang', but rather these tests are introduced on varying levels when integrating larger and larger parts. One tool for integration testing involves using the use case model to integrate one use case at a time. This is normally performed by an independent testing group. The test is thus performed by starting to test the lower levels, in order later to test the use cases and finally the whole system. The requirements model again forms a powerful tool here; as we test each use case, we check that the objects communicate correctly in that particular use case. Similarly, we check the user interfaces described in the requirements model. We thus see that the requirements model is verified by the testing process.

最开始是在底层进行测试，比如对象模块和功能模块被进行测试。这些部分是由模块的测试者进行测试。底层的子系统也进一步进行测试。最后的集成测试不是作为一个“大爆炸”而到来， 二十载不同的层级上进行集成测试，当越来越大的部分被集成进来。一个用于集成测试的工具涉及到使用用例模型来一次集成一个用例模型测试。这种集成测试通常是由一个独立的小组来实施。测试的过程是首先从底层的测试开始，顺序测试用例模型，直到最后测试整个系统。需求模型在这里再次构成了一个强有力的工具；因为我们会针对每个用例模型进行测试，我们也会检查在特定的用例模型中这些对象是否正确的进行通信。类似的方法，我们将坚持需求模型中描述的用户接口。我们通过这种方式见证了需求模型在测试过程中被有效的验证。

 

We may also view a test as an object just as we view use cases as objects. By doing this we can view the test specification as the test's class, and thus we can also inherit common parts or compose them from several test specifications, which is valuable when writing and thus reusing the specifications. In this way, we view a test execution as an instance of this class. The instance thus, quite clearly, has behavior and also a state. The outcome of such an execution is a test result. We have test results for all different types of test. The testing model will be discussed in more detail in Chapter 12.

就像我们将用例模型看成是对象一样，我们也可以同样将测试看成是一个对象。通过这样分析，我们可以吧测试定义规范看成是一个测试的类，同时这样我们也可以继承其他测试规范的公共部分，或者聚合其他几个测试规范，这种方式在我们写测试规范时将非常有价值，并能够重用以前的测试定义。 通过这种方式，我们可以将一次测试执行看成是这个类的一个实例。非常明显，这个实例就这样拥有了行为和状态。这样一次测试执行的结果就是一次测试结果。我们针对所有类型的测试都将有对应类型的测试结果。我们将在第12章中详细的讨论测试模块更多的细节。

6.9 Summary

6.9  总结

This chapter discussed the underlying architecture of the OOSE method. Here we have defined the concepts and the models that are developed when using OOSE.

  这一个章节讨论了OOSE方法中应用的底层体系结构.在本章中我们定义了在使用OOSE方法时需要开发到的概念和模型.

System development includes many activities during the system life cycle. When developing a product, it is essential to focus on all these activities. When taking a life-cycle view, one of the most important properties of a system is that it is maintainable, that is, changes can be made to the system at a reasonable cost.

系统开发工作包含了在系统生命周期之内的很多活动. 当开发一个产品的时候, 能够关注开发过程中的所有活动是非常基本的. 当我们用一个产品全生命周期的观点来观察, 系统最重要的一个特点是他的可维护性,也就是说,施加到系统上的变更能够以一个合理的开销来完成.

System development is a complex task and by building models at different levels of granularity this complexity can be managed. Five different models are developed for a product in OOSE. The transitions between these models are seamless, which means that the model transformation is repeatable by different developers. Another important property we should have is traceability between the models, that is, we should be able to trace changes from one object in one model to objects in another model. The transitions between these models are handled by processes. These processes manage a product over its life cycle. Four processes are used: analysis, construction, testing and components. In all models, objects are handled.

系统开发是一个非常复杂的工作,OOSE方法通过在不同层级构建模型的方式来保障系统开发复杂性的可管理.在OOSE方法中将为一个产品开发5种不同的模型. 这些模型之间的转换是无缝的, 这也就意味着模型转换是可以通过不同的开发者重复执行的. 模型之间的可追踪性是我们还应当拥有另外一个非常重要的特性,也就是说我们能够跟踪从一个模型中的对象到另外一个模型中对象的改变情况.模型之间的转换是有开发过程来管理. 这些过程将在全生命周期内管理一个产品. OOSE方法使用4种过程,他们是分析,构建,测试,和组件. 在所有的模型中,对象将被分析和应用.

 

The first model, the requirements model, consists of actors and use cases supported by an intuitive domain object model and interface descriptions. The actors model something that will interact with the system and a use case specifies a flow that a specific actor invokes in the system. The object model gives a conceptual, easy-to-understand picture of the system and the interface descriptions describe the system interfaces in detail. The requirements model will thus completely define the functional requirements of the system from a user's perspective. Since the model has a user perspective, it is easy to communicate with potential users in terms of this model.

第一个模型, 需求模型包含了角色和用例, 用例是由一个直观的领域对象模型和接口描述来支撑.角色是针对将要和系统进行交互的外部事物进行建模, 而用例则定义了一个特定角色调用系统的事件流. 对象模型为系统提供了一个概念化的,容易理解的视图,而接口描述则更加详细的描述了系统接口.需求模型就这样从一个用户的视角出发,完整的定义了系统的功能性需求. 因为需求模型是具有用户的观点,, 使用这个模型和潜在的用户进行沟通是非常容易的.

 

The analysis model is developed from the requirements model. The aim is to get a logical and robust structure that will be maintainable during the system life cycle. Three object types are used. Interface objects are used to model functionality that is directly dependent on the system interfaces. The entity objects model information that the system should manage for a longer time, and behavior tied to this information. Entity Objects typically survive a specific use case. The control objects should model functionality that is transaction oriented for a specific use case and that should be kept together for maintainability purposes. Typically, they do not survive a use case. The reason for having these three object types is that a change should preferably be local to one object only.

分析模型是根据需求模型来开发的. 设计分析模型的目标是 获得一个逻辑的,稳健的体系结构, 这个体系结构能够在系统的全生命周期内可维护.三种对象类型被使用. 接口对象被用来针对直接依赖系统接口的功能进行建模.实体对象是针对系统需要长期管理的信息结构进行建模, 同时还需要针对绑定到信息结构上的对行为来建模.实体对象通常是保存一个特定的用例模型. 控制对象应当针对一个特定用例模型的面向交易功能进行建模, 同时需要考虑系统可维护性的目的.通常,他们不负责保存一个特定的用例模型. 在分析模型中使用3种模型的原因是系统的改变应当最好控制在仅仅一个对象局部的范围.

The design model refines the analysis models further and takes into consideration the current implementation environment. The blocks describe how the system will be implemented. The ideal analysis model must often be changed owing to a complex implementation environment, even if this is not desirable. However, the basic system structuring should be kept as far as possible as defined in the analysis model. In the design model, the blocks are further specified using the use case model to explicitly specify the interfaces and the communication between the blocks.

设计模型针对分析模型进一步的优化,并将当前的实施环境纳入考虑. 功能模块描述系统应当如何实施.理想的分析模型必须被频繁的改变,归因于一个复杂的实施环境,即便这不是我们所不希望的.  然而,最基本的体系结构应当尽可能长久的保留, 就象他在分析模型中定义的一样.在设计模型中,功能模块又进一步的使用用例模型来清楚的定义功能模块的接口,和功能模块之间的通信.

The implementation model consists mainly of the source code written to implement the blocks. Here common and sound implementation techniques should be used. OOSE does not require an object-oriented language for implementation, although this is preferable since all the essential concepts exist in these languages.

实现模型主要包括了源代码, 通过写好的源代码来实现功能模块的功能. 在实现模型中,通用的,优质的实现技术应当被使用.OOSE方法本身并不要求使用面向对象的编程语言来实现功能,虽然使用面向对象的方法是可取的,因为所有面向对象的概念存在于这些编程语言中.

The testing model is developed when testing the system. Testing is done on several different levels of granularity. The lower-level objects are tested initially when performing unit testing. The use case model is used as the primary tool when doing integration testing.

测试模型是在对系统进行测试的时候进行开发的. 测试是通过在几个不同的的层级上来进行质量保证.低级别的对象是最先在单元测试阶段进行测试的.当执行集成测试的时候,用例模型是作为最重要的工具来使用.