Each class (in design) is implemented by coding it in a programming language, or by using a pre-existing component. Exactly what a class in design corresponds to depends on the programming language. For example, in object-oriented languages such as C++ and Java, a design class corresponds to one or several classes. In Visual Basic a design class corresponds to one component of a specific type, e.g. class module, form, or control. In Ada, a design class corresponds to one or several tagged types defined in an Ada-package.

The design model can be more or less close to the implementation model, depending on how you map its classes to classes or similar constructs in the implementation language. For example, you may give each design class a 1:1 relation to an implementation class. This will lead to a design model with a seamless traceability to the implementation model, and is appropriate in round-trip-engineering environments. Another alternative is to let a design class be an abstraction of several implementation classes. When using this approach, it is recommended that you map each design class to one "head" class that in turn can use several "help" classes to perform its behavior. You can use "help" classes to implement a complex attribute, or to build a data structure that you need for the implementation of an operation. In design, you need not model the "help" classes and you need to model only some of the attributes, relationships, and operations defined by the head class, as long as the model fulfills its purpose and is a good abstraction of the source code. You should decide before the design starts how classes in the design model should relate to implementation classes, and capture that in the Design Guidelines.

In many programming languages it is possible to separate the class interface, from its implementation, and eventually place them in separate files. For example, the common style in C++ is to place the interface of a class in a header file, a .h file, and the implementation of the class in a .cpp file. Ada has the concept of package specification and package body, and of subprogram specification and subprogram body.

Each programming language may offer a number of features that are difficult to "fit" in a general process framework. For example, in C++, concepts such as virtual base classes, "const" attributes and methods, abstract methods, friends, and so on have no direct equivalent in other languages. Or conversely the programming language might have some limitations as to what can be easily represented. The implementation workflow is aiming at this general framework for all object-oriented languages. But, to really utilize all possibilities of each programming language and to handle its limitations, you need to specialize the implementation workflow.

Display Rational Unified Process using frames

 

© Rational Software Corporation 1998 Rational Unified Process 5.1 (build 43)