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; for example, 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, which 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, we recommend 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 (.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.
Conversely, the programming language might have some limitations as to what can
be easily represented. The implementation discipline aims at this general
framework for all object-oriented languages. However, you
need to specialize the implementation discipline to really use all the possibilities
and to handle the limitations of each programming language.