Uml Csharp
Uml Csharp
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.
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 :
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.
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.
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:
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