From the UML design model to C# code by Pascal Roques (pascal.roques@valtech.

fr)
Introduction
In this article, we'll give you some simple rules to go from a design level UML model to C# code. First, we will describe a use case whose modeling produces some UML diagrams. The starting phase of the modeling is concealed so that we can focus on the C# code generation. That's why you'll directly confronted with the UML diagrams that come from analysis and design phases.

Case study description

A company wishes to improve its information system. In this context, the first step will be to analyse the employees training process, so that some of the tasks can be automated. 1. The training process begins when an employee sends a training request to the training officer. The training officer handles this request and accepts or rejects it. 2. If the request is accepted, the training officer searches for a corresponding course in the catalog of certified trainings. He informs the employee of the training contents and suggests a list of session dates. Once the employee has made his choice, the training officer asks the training provider to register her. 3. If the employee is held up, she must inform the training officer as soon as possible in order to cancel the training registration. 4. At the end of the training session, the employee must deliver a valuation (a reporting sheet) on the training, as well as a presence sheet to the training officer. 5. The training officer checks the invoice the training provider sends back before forwading it to the accountant service. Nota : these examples are taken from the book : UML in practice, P.Roques, Wiley, 2004.

General rules
We'll use the following UML diagrams :

Class diagrams
Class diagrams describe the code skeletton, that is to say all the declarations. As a first approximation, let's say that :

A UML class becomes a C# class UML attributes become C# instance variables UML operations become C# methods

You'll notice that navigable roles are implemented as instance variables, like the attributes, but with a user type instead of a simple type. The default constructor is implicit. Let's take a simple example to illustrate these rules :

Figure A : Skeletton C# code of the Book class

Interaction diagrams
Interaction diagrams (sequence or collaboration) describe the methods body, especially the sequence of method calls on objects which collaborate. The following example illustrates the correspondance between the messages numbers in a collaboration diagram and the associated C# code.

Figure B : The body of the enregistrerEmprunteur (register borrower) method From these simple rules, we are going to give some concrete real examples.

From UML class diagrams to C# skeletton code

Let's consider the figure C, and focus on the DemandeDeFormation (TrainingRequest) class.

Figure C : DemandeDeFormation and its relationships The preceding rules are enough to produce the skeletton of our C# classes. The only thing to keep in mind is that we must add an import statement to enable the establishment of relationships to classes which belong to other packages (be it user packages or standard base classes). The correponding C# code is shown on Figure D.

Figure D : C# skeletton code of the DemandeDeFormation class If we want to provide read and write access to attributes, the encapsulation principle invites us to code C# properties, such as :
public int propDateValidite { get { return DateValidite; } //this is property get for propDateValidite set { DateValidite=value; } //this is property set for propDateValidite }

Now let's have a look at Figure E and focus on the Formation (Training) class.

Figure E : Formation and its relationships Compared to the previous example, some additional problems arise :

the generalization relationship with ElementCatalogue (CatalogElement) multiplicities : 1..* with Theme (Topic) and 0..* {ordered} with Session

The previous rules aren't enough any more. We already had seen how to implement navigable associations having a multiplicity of 1 (or 0..1 ), but how to translate navigable associations of multiplicity * ? The principle is pretty simple : a multiplicity of * will become an attribute of type collection of objects references instead of a reference on a single object. What's difficult here is to choose the right collection among the possibilities offered by the .NET framework. Even though it is possible to create and manager arrays in C#, it is not necessarily the right solution. People generally prefer to use collections, such as the ArrayList or the HashTable in C#

use ArrayList if you want to remember the sequence order between the objects and if you want to use an integer index to retrieve the objects, use HashTable or SortedList if you want to retrieve the objects using an arbitrary key.

Here are some solutions to remember in order to make a relevant choice :

Figure F : Possible translations of UML associations in C# For the Formation class, we are going to use :

an ArrayList to implement the association with Session a HashTable to implement the association with Theme instead of a simple array. We'll use the Theme name as a qualifier.

All those explanations lead us to the following code for the Formation class:

Figure G : C# skeletton code for the Formation class

Conclusion
Producing code from the different UML diagrams is a sensitive process that must be mastered. So, depending

on the target language (Java, C#...), the mapping between the UML elements on one side and the programming languages features on the other side may or may not have a big impact. Code generation tools can automate this process, but they also propose different alternatives (ArrayList or HashTable for example) to the Object Designer / Developper. Author: Pascal Roques Translator (French to English): Thomas Gil Copyright DotNetGuru January 2004