Two functioning modes are available with Modelio C# Designer:
The C# functioning mode is configured through the standard Modelio configuration interface, which is launched using the “Set module parameters” command. The generation mode is selected in the “Generation mode” field (as shown in the figure below).
Model-driven engineering is the default Modelio functioning mode and is based on complete generation of declarative code from the UML model.
Marked zones are inserted into the generated C# code, with each of these zones corresponding to a note which can be added to the model (see figure below). Application code (virtually reduced to the programming of operations) is written in these marked zones (using with the aid of an external editor or an IDE).
Once the zones have been completed, their contents can be transferred back into the model in the form of corresponding notes. This operation can be carried out as many times as necessary.
The model-driven engineering mode does not, therefore, involve reverse engineering. All “declarative” modifications, such as, for example, the addition of a new attribute, are in fact model modifications and as such must be carried out within Modelio before subsequently regenerating the code.
Certain mechanisms exist to guarantee that the regenerated code does not overwrite any modifications made outside Modelio. Thus, the entire application can be fine-tuned outside Modelio, as long as the model itself is not modified.
Principles of model-driven engineering.
The main advantage of the model-driven functioning mode is that the code always corresponds to the model. In fact, it is only possible to modify declarations by modifying the model itself. Other advantages are:
a relatively small modification to the model can lead to significant modifications at declarative code level. These code modifications are automatically taken into account by Modelio C# Designer.
total model/code consistency leads to up-to-date documentation, as well as other generation work products (metrics, SQL, …), which are consistent with the code at no additional cost.
The obvious drawback of the model-driven functioning mode is that you are obliged to come back to Modelio after every modification made to the model, in order to regenerate the code.
Round trip engineering is a functioning mode that combines code generation and reverse engineering. Code is generated in exactly the same way as with model- driven engineering. Markers, which are used during the reverse engineering phase to differentiate between code written by you and code generated by Modelio, are also generated.
Application code (virtually reduced to programming operations if the model is complete) is written in these marked zone (using an external editor or an IDE).
Unlike model-driven mode, the round trip model allows the model to be directly modified at code level. The code is then fully reversed, in order to update the model.
In the example shown in the figure below, the String type attribute appears in the model.
Principles of round trip engineering.
The main advantage of the round trip mode is that modifications can be carried out within the code itself, with the model only being updated periodically.
The main disadvantages are:
either that the code will very rapidly differ from the model
or that the model returned will be physical and will lose its “overview”
or a mix of these two disadvantages
The problem of n-ary associations.
Starting with a 0..* association called “theBars” from the “Foo” class to the “Bar” class, after the round trip we have a 1..1 association, still called “theBars” but this time going from the “Foo” class to the “Vector” class. The semantics of this association have therefore been lost. The model has regressed from its logical level to its physical level.
Certain mechanisms exist to get round these problems. Thus, if the “theBars” association has a “public Bar getTheBars (int idx);” form accessor, which is normally the case where you have requested that Objecteering automatically generate accessors, the reverse engineering tool will find the correct association again.
The problem of renaming a class.
We start with a 1..1 association called “theBar” going from the “Foo” class to the “Bar” class. After carrying out a round trip operation and renaming the “Foo” class “Foo2”, we have a 1..1 association going from the “Foo2” class to the “Vector” class, but at the same time the “Foo” class with its association has been retained. In this case, the model is no longer valid, and differs from the code.
The problem of generation divergence.
Starting with a 1..1 association called “theBar” from the “Foo” class to the “Bar” class, default generation creates a Vector. If this Vector is changed into another collection type in the C# code, two case scenarios are possible:
Reverse engineering recognizes the new type and transfers it in the form of the {type=…} tagged value. During the next generation, if Modelio C# Designer recognizes the type, all is well.
Reverse engineering does not recognize the new typr (as illustrated in the figure above). Generation is stopped and the round trip cycle is interrupted.
To avoid this problem, try to choose a type known to Modelio C# Designer (for details on known types, please see “Tagged value types”).
Compilation consists of producing assembly files (executable or library files) from C# source files previously generated, through the production of a makefile file.
Compilation is run on a component stereotyped <<C# Library>>, << C# Executable>> or << C# Windows Executable>>.To create such a component, simply use the ‘Create C# Designer element’ contextual menu on a package.
The C# component creation menu.
This C# component must be linked to C# packages by a package import link.
C# component with package import link to a C# package.
Compilation can be run:
For a component, the generated makefile recursively compiles all the referenced package’s files.
In Modelio, C# components provide the commands used to:
C# component C# property view.
The NDoc tool, which can be downloaded at http//sourceforge.net/projects/ndoc/, can be launched on any component for which code has been generated and compiled.
This feature uses the “CsCummary” and “CsRemarks” type notes which exist on the model’s classes, attributes, associations and operations. You can choose via a parameter whether “description” type notes should be processed in the same way as “csDoc” notes or not.
Generating C# documentation.
Steps:
The window shown below then appears.
Window used to define the documentation you are about to generate.
After generation, C# documentation is immediately opened.
C# documentation generated on the “BankAccount” class.
C# documentation generation consists of producing XML files from generated “.cs” files using the SDK documentation tool.
The documentation produced can then be visualized using an HTML explorer.
NDoc is an extendable documentation generation tool for .NET developers.
NDoc merges the assemblies and XML documentation files produced by csc.exe and creates a compiled HTML help file, enabling you to browse your own libraries just like the .NET Framework Class Library.
The documentation generator uses XSLT to produce the HTML. Future versions will make it possible to customize the XSLT to produce documentation with any desired look and feel.
The NDoc source code is freely available under a certified Open Source license, and can be downloaded at http://sourceforge.net/projects/ndoc/.
C# class libraries are essential elements in C# programming. The reverse tool allows the integration of libraries and source files into Modelio models.
When reversed classes are integrated into the repository, you can do:
The reverse process allows existing library classes to be used during the modeling phase. This process enables the generalization of these classes, as well as their implementation or their use in modeling.
To reverse a class, you must have an .exe or .dll file of a C# project that includes this class. If you also have the .cs source code, a complete reverse of the code and C# documentation comments can be carried out. If this is not the case, only a structural reverse will be carried out.
The two reverse commands provided by Modelio C# Designer are run from the root package via the C# Designer module contextual menu or via the C# Designer property view buttons.
The "Reverse C# sources" icon opens the following window, used to select the directory containing the elements to reverse into the project.
Selecting the directory containing the files to be reversed.
After selecting the directory containing the C# files you want to reverse and choosing the desired reverse option (full, mixed or simple), click on the “Next” button to continue.
After clicking on the “Next” button, the following window appears. This window is used to select the elements to reverse into the project.
Selecting the files to be reversed.
Select the elements you wish to reverse simply by checking the corresponding tickbox, and click on “Reverse” to launch the reverse operation.
The "Reverse C# assembly" icon opens the following window, used to select the assembly which you wish to reverse into the project.
Selecting the assembly to be reversed.
After selecting the assembly and choosing the desired introspection option (whether or not only public elements will be included) and reverse option (full, mixed or simple), click on the “Next” button to continue.
After clicking on the “Next” button, the following window appears. This window is used to select the components to reverse into the project.
Selecting the components to be reversed.
Select the components you wish to reverse simply by checking the corresponding tickbox, and click on “Next” to launch the reverse operation.
The constructors of a C# class are created using the “create” stereotype in Modelio.
Since the passing mode of the parameters in C# is through reference, all the parameters of an operation, except the return parameter, are of In/Out type.
When you import an attribute or a parameter with a primitive C# type, equivalence is established with Modelio’s predefined types. Certain C# types require the addition of a tagged value.
Primitive C# type | Type in the repository | Tagged value |
---|---|---|
bool | boolean | N/A |
char | char | N/A |
int | integer | N/A |
uint | integer | CsUnsignedInt |
short | short | N/A |
ushort | short | CsUnsignedShort |
long | long | N/A |
ulong | long | CsUnsignedLong |
sbyte | byte | CsSignedByte |
byte | byte | N/A |
float | float | N/A |
double | double | N/A |
decimal | double | CsDecimal |
When a type declaration cannot be expressed in Modelio, it is encapsulated in a {CsTypeExpr} tagged value, and the attribute, association or parameter type gets the “undefined” value.
This {CsTypeExpr} tagged value is not included in the signature of a method. Therefore, if an “m1” method is defined containing the only parameter which has a type that cannot be expressed (a CsTypeExpr), the creation of a second “m1” method with only one CsTypeExpr parameter will not be accepted by Modelio. This situation, however, is very rare.
In “roundtrip” mode and for C# 2.0 generation, the “objingid” C# attribute is generated for classes, interfaces, enumerations, attributes, associations and operations. This annotation contains the identifier of the modeling element that has been generated.
1 [objingid("13636872:26967")]
2 public class Class
3 {
4
5 //code ...
6
7 }
The “objingid” C# attribute is used to find the modeling element in the Modelio project when it is reversed. Without it, the element is searched for by name. This makes it indispensable to update an element when it has been renamed or moved in the C# sources. For example, operations that have changed signature will be updated and not deleted, and then recreated.
When copying code in C# sources, the “objingid” C# attribute must never be copied, in order not to lose information when reversing or updating a modeling element that does not correspond to the C# code.
In order to be able to compile C# sources with this new C# attribute, an “using” is generated to the file containing the declaration of the C# attribute:
1 using Softeam.CSharp;
A “objingid.dll” archive is provided with C# module, containing the declaration of the C# attribute. To be able to compile outside Modelio, you must add this library. If you generate a MakeFile from Modelio, the library is added automatically.
For each attribute or association in a class, a number of access methods to this data member can be automatically managed in the model. There are two groups of access methods, one for reading (“getX()” or “isX()”) and the other for modification (“setX()”, and so on).
When creating an attribute, the default choice is “Read”, and an accessor is created. Therefore, according to the element access mode, the following cases are available:
No access | Read | Write | Read-write | |
---|---|---|---|---|
Attributes | No accessor generated | get<AttributeName> | set<AttributeName> | get<AttributeName> set<AttributeName> |
Associations | No accessor generated | get<AssociationRole> | set<AssociationRole> | get<AssociationRole> set<AssociationRole> |
The “Automation” group of Modelio C# Designer parameters contains the default visibility value for all created access methods, according to the attribute or association visibility. It is also possible to disable the access method management in your model.
This feature maintains consistency for operations in interfaces and their implementing classes. Operations can be automatically created when a class implements a new interface, including a redefinition link visible in the fast link editor.
When the name of a method in the interface changes, all the redefined methods in its child classes are updated. If you decide to create a new operation in your interface, the same operation can be created in the child classes.
The “Automation” group of Modelio C# Designer parameters contains the different behaviors for the automatic update of classes implementing an interface:
If you choose “Yes”, the modifications made to the implementing classes will be propagated, whereas if you choose “No”, the model will remain unmodified.
Automatic interface implementation can also be launched manually on model elements.
On an interface:
On a class implementing an interface:
Modelio C# Designer uses a specific XML file to define the mapping of base types and containers.
These packages are found in the “CsCustomizationFile” XML file, located in the module’s installation directory (<Project_Path>/mda/CsDesigner/res/custom/).
You can modify basic type mapping in order to generate your own custom type. The following is an example of type definition from the customization file:
1 <ModelType name="boolean">
2 <CsType name="bool">
3 <wrapper name="Boolean"/>
4 </ModelType>
In the same part of the customization file, default container can also be specified, for multiple cardinalities. These containers are automatically generated if no container is defined on an element, such as an Attribute, an AssociationEnd or a Parameter. For example:
1 <AssociationEnd card="MandatoryMultiple">
2 <defaultInterfaceContainer name="List">
3 <import name="System.Collections.Generic"/>
4 </defaultInterfaceContainer>
5 <defaultImplementationContainer name="List">
6 <import name="System.Collections.Generic "/>
7 </defaultImplementationContainer>
This definition contains two parts: * The default interface container for an AssociationEnd with a n.. multiplicity is List, with a specific import. * The default implementation container for an AssociationEnd with a n.. multiplicity is List, with a specific import.
Note: You can use “Array” if you do not want specific collections to be generated.
Modelio C# Designer provides several modes of customization, addressed to different categories of users. This complete C# generation customization allows you to generate the exact programming form desired, by adapting Modelio C# Designer to your own needs.
For example, it is possible to change the mapping of types and the generation of accessors used by default, to create specific generations or to respect forms of imposed programming.
Depending on the level of detail of desired parameterization, you can: * modify parameters and simply change the general Modelio C# Designer options
The Modelio C# Designer parameter configuration window can be used to modify the behavior of the module.
To access the window used to configure Modelio C# Designer parameters, simply run the “Options/Set module parameters” command from the Modelio toolbar.
Generation Mode: the mode selected for generation:
Default behavior for file retrieving: what to do during generation if the file on disk has been modified since last generation:
Path to .NET Framework: The root directory of the .NET Framework. You must have it in order to develop a new program (compilation…). Ex: “C:\Windows\Microsoft.NET\Framework\v3.5”
SDK Version: Version of the Software Development Kit (SDK) to use for compatibility.
Command for invoking Visual Studio: The Visual Studio “devenv.exe” application.
Note: For further information on the model-driven generation mode and the round-trip generation mode, please see Model-driven mode and Round-trip mode.
Code generation path: the path of the .cs files to generate.
Customization file: Where the default behaviour can be found in the “CsCustomizationFile” XML file, located in the module’s installation directory, into the workspace.
Modelio C# Designer uses a specific XML file to define the mapping of base types, containers and the default creation of accessors.
Treat warnings as errors: If the specific C# consistency controls during generation is active. When active, the generation is stopped for each file containing a warning, rather than ignoring it. Ex: generate a class containing an attribute without type.
Use Cs naming rules: that during generation, the names of packages, classes, methods, attributes and parameters will be generated, according to C# recommendations concerning the case (upper or lower) of the first letter.
Prefix for fields: the prefix added for all property default implementation.
Generate full name for used classes: that the fully qualified name should be used for used classes.
Authorize auto-implemented properties: that whether properties should be generated with simplified syntax. Only available with C# 3.
Update classes implementing an interface: define the behaviour of the automatic model update after a modification on an interface. With the Ask value, a dialog box is opened each time to propagate the update.
Accessor generation: define the global running of accessor generation in the model. This can be activated, deactivated, or smart. For the latter, accessors are only created for attributes that are not public.
Visibility for getters generated from “Public” elements: declare the visibility of “get” type accessors for all public attributes.
Visibility for setters generated from “Public” elements: declare the visibility of “set” type accessors for all public attributes.
Visibility for getters generated from “Protected” elements: declare the visibility of “get” type accessors for all protected attributes.
Visibility for setters generated from “Protected” elements: declare the visibility of “set” type accessors for all protected attributes.
Visibility for getters generated from “Package” elements: declare the visibility of “get” type accessors for all package attributes.
Visibility for setters generated from “Package” elements: declare the visibility of “set” type accessors for all package attributes.
Visibility for getters generated from “Private” elements: declare the visibility of “get” type accessors for all private attributes.
Visibility for setters generated from “Private” elements: declare the visibility of “set” type accessors for all private attributes.
Note: By default, attributes are created with a public accessor.
Generate pre/post-conditions: That pre/post-conditions should be generated.
Generate invariants: That invariants should be generated.
Note: By default, invariants and conditions are not generated.
Use external edition: whether or not an external editor should be used instead of the internal Modelio editor.
Command for invoking external editor: the command used to launch an editor to modify the generated code. Ignored if the external edition is deactivated.
Compiled files path: The root directory for compiled files.
Command for launching makefiles: The command used to activate makefile files. This is usually the path to nmake.exe.
Compiler: The C# compiler.
Compilation options: The options for the compilation.
Libraries: The path to additional libraries.
Debug: whether or not to add debug info to the compilation target.
Unsafe: that pointer passing is authorized during compilation.
Application’s parameters: the parameters to give to the application when the run command is launched.
NDoc path: The path to the NDoc tool, used to generate the C# documentation.
Documentation generation: Whether or not to generate the documentation.
Generate “description” as “Csdoc”: Wheter or not to activate the processing of “description” type notes as “Csdoc” type notes. If checked, during reverse operations, the file’s documentation is incorporated into the model in the form of a “description” note.
Note: For further details on documentation generation, please see Overview of C# documentation generation.
Add C# source files in model component: that you wish to include C# source files in a model component that you are packaging.
Add Jar files in model component: that you wish to include C# libraries (dll) in a model component that you are packaging.
The Introduction topic of the Modelio C# Designer user guide is where you’ll find general information on everything you need to know about the main features of this module.
The Introduction topic contains the following sections:
The Functionalities topic of the Modelio C# Designer user guide takes you on a detailed tour of all the features of this module.
From choosing your functional mode to generation C# code, from documentation generation to compilation, from the C# reverse and automation features to how to manage a Visual Studio project, this chapter has all the information you need.
The Functionalities topic contains the following chapters and sections:
The Choosing Your Functional Mode topic of the Modelio C# Designer user guide explains the two functioning modes supported by this module (model-driven and roundtrip) and presents the main advantages and disadvantages of each.
The Choosing Your Functional Mode topic contains the following sections:
The Generating C# Code topic of the Modelio C# Designer user guide is where you will find everything you need to know about the generation of C# code using the Modelio C# Designer module.
Each code generation feature is explained, and the tagged values, notes and stereotypes used in C# generation are presented. There is also a section which presents the correspondence between what is modeled and what is generated in the C# code.
The Generating C# Code topic contains the following sections:
The C# Documentation Generation topic of the Modelio C# Designer user guide presents the C# documentation generation feature provided by the module, and explains the different documentation generation functions.
The C# Documentation Generation topic contains the following sections:
The Compilation topic of the Modelio C# Designer user guide explains how to generate and build a C# assembly file.
The Compilation topic contains the following sections:
The C# Reverse topic of the Modelio C# Designer user guide presents and explains the C# reverse feature of the C# Designer module, including its functioning and how to launch the reverse and model update commands.
The C# Reverse topic contains the following sections:
The C# Automation topic of the Modelio C# Designer user guide presents the access methods used to automate C# generation operations, and explains how to automate interface implementation.
The C# Automation topic contains the following sections:
The Managing A Visual Studio Project topic of the Modelio C# Designer user guide describes the different operations involved in the management of a Visual Studio project, including creating, importing, opening, updating and building it.
The Managing A Visual Studio Project topic contains the following sections:
The Customizing C# Generation topic of the Modelio C# Designer user guide describes the different ways in which you can configure this module to meet your own particular C#-specific needs.
The Customizing C# Generation topic contains the following sections:
The generation of C# code is based on a UML model extended by notes and tagged values specific to C#, in order to generate all the code for C# classes.
Code generation can be customized using the following mechanisms:
Modelio C# Designer generation provides several features related to generation.
Commands available from a C# class.
List of commands:
C# attributes are defined through the C# property view of a Class, by choosing ‘C# Attribute’ value in the C# element field.
C# attribute property view.
This view defines all options available on the C# Attribute definition.
Indexers are modeled through a UML class with two operations, “get” and “set”, to which the <<CsIndexer>> stereotype is added. A class stereotyped <<CsIndexer>> will not be generated. It will simply be used to generate C# indexer get and set signatures and bodies.
To create an indexer, simply use the ‘Create C# Designer element’ contextual menu on a class:
Create C# Indexer command.
The following is a description of indexer accessors:
These functions help to resolve the indexer signature. Indexer signatures are as follows:
Indexer-visibilityindexer-returnType this[indexer-parameters] { ... }
C# events are modeled throught a UML signal to which the “CsEvent” stereotype is added. This signal must be a part of a class. Once a signal is stereotyped as an event, you can manage new values such as visibility (using the C# property view) and delegate association (using Signal UML properties tab’s Base field). An event must refer to a model’s delegate.
To create a C# event, simply use the ‘Create C# Designer element’ contextual menu on a class:
Create C# Event command.
Delegates can be operations issued from C# delegate containers (classes stereotyped “CsDelegateContainer”) or C# delegates (operations stereotyped “CsDelegate”). The related reference can be created through a drag and drop operation.
C# delegate containers (classes stereotyped “CsDelegateContainer”) are used as containers of C# delegate types (operations stereotyped “CsDelegate”). The generated delegates belong to the current parent element.
Stereotyping an operation “CsDelegate” will enable delegate signature and skip generation of all code notes attached to the operation.
To obtain the property declaration with simplified syntax, you must not define any associated code notes (CsGetCode/CsSetCode), as if you do, a normal property will be generated.
The generator will automatically apply the “private” modifier (by default) to the get or set accessor according to which access mode has been selected, as shown in the table below.
Access mode / Modifiers | None | Read | Write | ReadWrite |
---|---|---|---|---|
get | Error | Warning | CsPropertyVisibilityGet or private | Warning or Error |
set | Error | CsPropertyVisibilitySet or private | Warning | Warning or Error |
Example of automatically implemented properties
UML Model
C# Generated
1 using System;
2 using System.Diagnostics;
3 namespace ExtensionMethods
4 {
5 public class LightweightCustomer
6 {
7 #region TotalPurchases
8 public int TotalPurchases { get; set; }
9 #endregion
10
11 #region Name
12 public string Name { get; private set; } // read-only
13 #endregion
14
15 #region CustomerID
16 public int CustomerID { private get; set; } // write-only
17 #endregion
18 }
19 }
To define a method as being a partial method, simply check the “Partial” tick box in the C# property view. Modelio C# Designer will then position the new “partial” modifier just before the void keyword during code generation.
The generator will ignore the {CsPartial} tagged value if the method has a return parameter, one or more “out” parameters, or a virtual, abstract, override, new or sealed modifier. Furthermore, the visibility of the method must be private or default (implicitly private).
Example of using partial types and methods
UML model
C# generated
1 // Definition in file1.cs
2 using System;
3 using System.Diagnostics;
4
5 namespace Project.Definition
6 {
7 public partial class PartialClass
8 {
9 partial void PartialMethod();
10 }
11 }
12
13
14 // Implementation in file2.cs
15 using System;
16 using System.Diagnostics;
17 namespace Project.Implementation
18 {
19 public partial class PartialClass
20 {
21 public void PartialMethod()
22 {
23 // implementation code
24 }
25 }
26 }
27
Note 1: A partial method containing a “CsCode” or “CsReturned” note will generate the implementation part. The definition part will be produced if the partial method does not have these notes.
Note 2: A partial method declaration is made up of two parts: the definition and the implementation. It is up to the user to only create a single definition/implementation couple.
Be careful, Modelio C# Designer runs no tests on this.
Listed below are common concepts used in C# development, together with the way they can be expressed in Modelio.
Generics are a new functionality provided by version 2.0 of the C# language and the common language runtime (CLR). Generics introduce the concept of type parameters into the .NET Framework, making it possible to receive classes and methods whose specification of one or several types differs until the class or method is declared and instanciated by client code.
The “SDK Version” tickbox (contained in the “General” parameter set, as shown in the screenshot below) tells Modelio C# Designer whether or not this new functionality (and the other .NET Framework evolutions) is available during code generation.
The “SDK Version ” field.
Note: Do not modify the .NET Framework directory containing the version number during .NET installation.
An additional namespace, “System.Collections.Generic”, has been added to the Framework 2.0. This namespace contains the interfaces and classes that define the generic collections used to create strongly typed collections.
Modelio C# Designer provides and uses these new collections instead of the earlier ones, as they provide better security and performance than non-generic strongly typed collections (see below).
The dropdown list in the “Collection to sue” field in the C#“ property view.
Note: The “List” generic collection is used by default.
UML model | Generated C# |
---|---|
![]() |
![]() |
![]() |
![]() |
If Modelio C# Designer uses the .NET Framework 2.0, then associations and attributes whose multiplicity is greater than one will be generated using generic collections, as far as possible (see the table above).
To make your class, method or delegate generic, add a template parameter in the explorer.
The following table shows an example of a generic class and the generated C# code.
UML model | Generated C# |
---|---|
![]() |
![]() |
The following table shows an example of a generic method and the generated C# code.
UML model | Generated C# |
---|---|
![]() |
![]() |
The following table shows an example of a generic delegate and the generated C# code.
UML model | Generated C# |
---|---|
![]() |
![]() |
When you are defining a generic class, you can apply certain restrictions to the kinds of types that the client code can use as type arguments when it instantiates your class. These restrictions are called constraints. The following table presents the six types of constraint that exist:
List of constraint:
Note: Only the “BaseClass” constraint (base class name) must be indicated in the template parameter UML properties view (see the “Generic classes, methods and delegates” paragraph above). All the other are added using a tagged value (see “Tagged values types”).
The table below shows the intercompatibility of constraints:
struct | class | new() | <baseclass> | <interface> | U | |
---|---|---|---|---|---|---|
struct | No[1] | No[2] | No[2] | No[2] | Yes | Yes |
class | No[1] | Yes | No[3] | Yes | Yes | |
new() | No[1] | Yes | Yes | Yes | ||
<baseclass> | No[1] | Yes | Yes | |||
<interface> | Yes | Yes | ||||
U | Yes |
The following table shows an example of a generic class with a “BaseClass” type constraint.
UML model | Generated C# |
---|---|
![]() |
![]() |
The following table shows an example of a generic method with an “Interface” type constraint.
UML model | Generated C# |
---|---|
![]() |
![]() |
To specify a type argument, a concrete (or generic) type must be associated to: the attribute, parameter, role or inheritance link. In the explorer, select the element in question and then in the MDA annotations view, associate the {Bind} tagged value, with a types list as parameter (see the screenshot below).
The {Bind} tagged value in the MDA annotation view.
The following table shows an example of the association of a generic class with a parameter left unspecified (“T”).
UML model | Generated C# |
---|---|
![]() |
![]() |
The following table shows an example of an inheritance link: closed constructed type.
UML model | Generated C# |
---|---|
![]() |
![]() |
The following table shows an example of an inheritance link: open constructed type.
UML model | Generated C# |
---|---|
![]() |
![]() |
The following table shows an example of a generic parameter of a method left unspecified (“T”).
UML model | Generated C# |
---|---|
![]() |
![]() |
Modelio notes are used to complete the UML model with texts expressed in C# syntax. Usually, the internal processing of a UML method is entered in C# in a “CsCode” type note associated to a method’s implementation.
Note: Notes can be added to model elements directly through the “MDA Annotations” view.
The list of types of note:
The list of types of note:
The list of types of note:
The list of types of note:
The list of types of note:
The list of types of note:
The list of types of note:
Modelio defines stereotypes which are used to designate certain objects as being concerned by the generation of C# code.
Note: Certain stereotypes can be added to certain model elements directly through the “C#” property view. For more information, please see “Modelio C# Designer property view”.
The list of stereotypes:
The tagged values provided by Modelio are used to adapt C# semantics to a UML model, in order to generate all C# notions accurately. For example, the notion of extern method in C# does not exist in UML. An {Extern} tagged value on a UML operation allows you to specify this characteristic on a model.
Note: Tagged values can be added to specific model elements directly through the “MDA Annotations” view.
Name | Parameters | Role |
---|---|---|
Bind | List of generic type parameters | Associates one or several template parameters to the attribute's reference type. |
Const | N/A | Adds the "const" keyword to the attribute's modifiers. |
C# Name | Name | During the generation phase, the parameter of this tagged value takes precedence over the model name. |
Full Name | N/A | Specifies that the type must be generated with its namespace. |
Implementation Type | Collection | Defines the type of the collection that must be generated to instanciate the current attribute. |
New | N/A | Adds the "new" keyword to the declaration. |
No Code | N/A | Prevents this element from being generated. |
No initial value | N/A | Indicates that this element shouldn’t be instanciated. |
Nullable Type | N/A | Allows a variable to contain a value that is not defined. |
Override | N/A | Adds the "override" keyword to the modifier's declaration. |
Pointer | N/A | Declares the attribute as being a pointer (for example, "int*myInteger;"). |
Read Only | N/A | Adds the "readonly" keyword to the attribute's modifiers. |
Sealed | N/A | Adds the "sealed" keyword to the modifiers. |
Type | Array, ArrayList, Hashtable, Queue, SortedList or Stack | Defines the type of the collection that must be generated for the current attribute. |
Type Expr | Text for specifying the attribute's C# type | Generates the types that cannot be represented in Modelio (ex : int [ ] [ ]). |
Unsafe | N/A | Adds the "unsafe" keyword. |
Virtual | N/A | Declares the element as being virtual. |
Visibility | The type of visibility (internal, protected internal, ...) | Defines custom visibility. |
Volatile | N/A | Adds the "volatile" keyword to the attribute's modifiers. |
Name | Parameters | Role |
---|---|---|
Array Dimension | Integer | Specifies the number of dimensions of an array. |
Bind | List of generic type parameters | Associates one or several template parameters to the attribute's reference type. |
Const | N/A | Adds the "const" keyword to the association's modifiers. |
C# Name | Name | During the generation phase, the parameter of this tagged value takes precedence over the model name. |
Full Name | N/A | Specifies that the type must be generated with its namespace. |
Implementation Type | Collection | Defines the type of the collection that must be generated to instanciate the current attribute. |
Initial Value | Value | Specifies the initialization code for the association. |
New | N/A | Adds the "new" keyword to the declaration. |
No Code | N/A | Prevents this element from being generated. |
No initial value | N/A | Indicates that this element shouldn’t be instanciated. |
Override | N/A | Adds the "override" keyword to the modifier's declaration. |
Read Only | N/A | Adds the "readonly" keyword to the association's modifiers. |
Sealed | N/A | Adds the "sealed" keyword to the modifiers. |
Type | Array, ArrayList, Hashtable, Queue, SortedList or Stack | Defines the type of the collection that must be generated for the current attribute. |
Type Expr | Text specifying the attribute's type | Generates types that cannot be represented in Modelio (ex : int [] []). |
Unsafe | N/A | Adds the "unsafe" keyword. |
Virtual | N/A | Declares the element as being virtual. |
Visibility | The type of visibility (internal, protected internal, ...) | Defines custom visibility. |
Volatile | N/A | Represents the C# keyword "volatile". |
Name | Parameters | Role |
---|---|---|
Extends | Name of the mother class | Forces class inheritance. |
Implements | Name of the interface to implement | Forces the implementation of an interface. |
C# Name | Name | During the generation phase, the parameter of this tagged value takes precedence over the model name. |
New | N/A | Declares the class with the "new" keyword. |
No Code | N/A | Prevents this element from being generated. |
No Invariants | N/A | Prevents the generation of invariants for the class. |
Partial | N/A | Authorizes the split into several files of one type. |
Sealed | N/A | Adds the "sealed" keyword to the class. |
Static | N/A | Indicates the class is static. |
Struct | N/A | Defines the class as being structure. |
Use | Names of the imported classes and packages | Imports non-modeled packages and classes. |
Visibility | The type of visibility (internal, protected internal, ...) | Defines the visibility of the class. |
Name | Parameters | Role |
---|---|---|
Allow Multiple | N/A | Allows multiple C# attributes on a field. |
Inherited | N/A | Adds the C# attribute inheritance. |
Target | The targets of the C# attribute | Adds an attribute target to the class if the class is stereotyped "CsAttribute" |
Name | Parameters | Role |
---|---|---|
Enumeration Type | Type | Specifies the enumeration type. |
Use | Names of the imported classes and packages | Imports non-modeled packages and classes. |
Visibility | The type of visibility (internal, protected internal, ...) | Defines the visibility of the enumeration. |
Name | Parameters | Role |
---|---|---|
Expression | Value | Specifies the enumeration literal value. |
Name | Parameters | Role |
---|---|---|
Bind | List of generic type parameters | Associates the template parameter(s) to the parent class' template parameter(s). |
Full Name | N/A | Specifies that the generalization must be generated with the namespaced name of the super class. |
Name | Parameters | Role |
---|---|---|
Extends | Name of the mother interface | Forces interface inheritance. |
C# Name | Name | During the generation phase, the parameter of this tagged value takes precedence over the model name. |
New | N/A | Declares the class with the "new" keyword. |
No Code | N/A | Prevents this element from being generated. |
No Invariants | N/A | Prevents the generation of invariants for the interface. |
Partial | N/A | Authorizes the split into several files of one type. |
Use | Names of the imported classes and packages | Imports non-modeled packages and classes. |
Visibility | The type of visibility (internal, protected internal, ...) | Defines the visibility of the interface. |
Name | Parameters | Role |
---|---|---|
Extension | Extension | Defines the method as being an extension of an existing type. |
Extern | N/A | Declares the extern operation. |
C# Name | Name | During the generation phase, the parameter of this tagged value takes precedence over the model name. |
Getter Visibility | The type of visibility (internal, protected internal, ...) | Specifies the getter visibility. |
New | N/A | Adds the "new" keyword to the declaration. |
No Code | N/A | Prevents this element from being generated. |
No Invariants | N/A | Prevents the generation of invariants for the operation. |
Override | N/A | Adds the "override" keyword to the modifier's declaration. |
Partial | N/A | Authorizes the breakdown of a method into two parts: the definition and the implementation. |
Setter Visibility | The type of visibility (internal, protected internal, ...) | Specifies the setter visibility. |
Thrown Exceptions | Exception names | Defines the method thrown types. |
Unsafe | N/A | Adds the "unsafe" keyword. |
Virtual | N/A | Declares the element as being virtual. |
Visibility | The type of visibility (internal, protected internal, ...) | Defines custom visibility. |
Name | Parameters | Role |
---|---|---|
Directory Name | Name of the directory | During the generation phase, the parameter of this tagged value takes precedence over the modeling name for the generated directory. |
C# Name | Name | During the generation phase, the parameter of this tagged value takes precedence over the model name. |
Extern | N/A | Indicates this element represents an external package, preventing it from being generated. |
No Code | N/A | Prevents this element from being generated. |
No Directory | N/A | Prevents the generation of a directory for the package. |
No Namespace | N/A | Prevents generation of the name of the namespace for the annotated package. |
Root | N/A | Indicates that the annotated package is the root generation node for your project. |
Use | Names of the imported namespace | Forces a package dependency. |
Name | Parameters | Role |
---|---|---|
Bind | Bound types on the parameter | Specifies the types bound by a generic parameter. |
C# Name | Name | During the generation phase, the parameter of this tagged value takes precedence over the model name. |
Full Name | N/A | Specifies that the type must be generated with its namespace. |
Nullable Type | N/A | Allows a variable to contain a value that is not defined. |
Params | N/A | Supports the "params" parameter passing modes (variable number of arguments). |
Pointer | N/A | Declares the parameter as being a pointer (for example, "int *myInteger"). |
Type Expr | Text specifying the parameter's type | Generates the types that cannot be represented in Modelio (ex : int [] []). |
Name | Parameters | Role |
---|---|---|
Bind | List of generic type parameters | Associates the template parameter(s) to the parent class' template parameter(s). |
Full Name | N/A | Specifies that the realization must be generated with the namespaced name of the interface. |
Name | Parameters | Role |
---|---|---|
Bind | Bound types on the signal | Specifies the types bound by a generic signal. |
C# Name | Name | During the generation phase, the parameter of this tagged value takes precedence over the model name. |
No Code | N/A | Prevents this element from being generated. |
Static | N/A | Adds the static keyword. |
Type Expr | Text for specifying the Signal’s C# type | Generates the types that cannot be represented in Modelio. |
Virtual | N/A | Declares the element as being virtual. |
Visibility | The type of visibility (internal, protected internal, ...) | Defines the visibility of the signal. |
Name | Parameters | Role |
---|---|---|
Class Constraint | N/A | Forces the type argument to be a reference type. |
Implement Constraint | Name(s) of the interface(s) to implement | Forces the type argument to implement the specified interface. |
Naked Constraint | Name(s) of the template parameter(s) | Forces the type argument to be the delivered argument or a derivative. |
New Constraint | N/A | Forces the type argument to have a public constructor with no parameters. |
Struct Constraint | N/A | Forces the type argument to be a value type. |
A FrameworkClassLibrary.ramc containing the .NET Framework 3.5 class library is delivered with C# designer, allowing you to deploy the System and Microsoft.Csharp namespaces in your model using the model components feature.
Many of the features provided by the C# Designer module use one or several outside tools in conjunction with Modelio. The fact that some of these tools are not currently available in a Linux distribution means that the related C# Designer features are therefore not available in Modelio.
Among the limitations of this type are the following:
C# code generation consists of producing C# files for a model’s classes using the correspondence between C# notions and modeling notions. Before actually proceeding with generation, it may be necessary to specify that classes or packages are C# elements using stereotypes and to annotate the model using tagged values, and to further define the model using notes.
Modelio C# Designer has a default strategy for generating parameter and attribute declarations. It converts UML types into C# types, ensuring modern code generation, based on the C# collections framework. Other translations can be implemented easily, using the Modelio C# Designer customization file.
Compilation consists of producing EXE or DLL files from generated C# files.
Compilation can be run from components modeled in Modelio.
This operation uses the documentation option (/doc) of the compiler tool to produce HTML files from the generated C# files, and is, therefore, related to the generated C# files. Special notes, inserted during the modeling phase and taken into account by the code generation process, are then used.
Reverse engineering consists of incorporating classes belonging to existing libraries or source code into a model. This allows you, during the modeling phase, to:
This feature allows Visual Studio project files (.csproj) to be created, edited, updated and built from Modelio.
Welcome to the Modelio C# Designer user guide!
Modelio C# Designer is used to generate and compile a C# application from a Modelio model, and to generate its associated documentation.
During the modeling phase, a reverse feature is provided, to enable you to use classes in existing libraries.
Modelio C# Designer provides five main features:
Modelio C# Designer also provides you with powerful parameterization features, including:
The consistency of the model built in Modelio and the code produced by Modelio C# Designer is maintained at all times, through the model-driven mode. This mode allows the generation of the entire C# application from the model, as well as the retrieval of the code inserted using dedicated markers. This means that code/model consistency is ensured, whilst maintaining the independence of the design model and the implemented code.
The C# property view is used to enter or modify certain information relevant to C# generation on the element selected in Modelio, such as tagged values or stereotypes.
The icons at the top of the window are used as follows:
The icons at the top of the window are used as follows:
The icons at the top of the window are used as follows:
The icons at the top of the window are used as follows:
The icons at the top of the window are used as follows:
The icons at the top of the window are used as follows:
The icons at the top of the window are used as follows:
The icons at the top of the window are used as follows:
The icons at the top of the window are used as follows:
The icons at the top of the window are used as follows:
This feature is used to synchronize source files. The list of source files (.cs) belonging the project file (.csproj)is updated according to the additions made from Modelio.
To actualize the source files managed by a project, simply select the model
element in the explorer and then click on the
icon in the C# property view.
Actualizing source files.
Note 1: Source file synchronization is secure, since it only allows the addition of new source files, in one direction or the other. To delete source files, you must delete them in the Modelio explorer and in the Visual Studio “Solution Explorer”.
Note 2: In order to avoid losing data between sources added from Modelio and those added from Visual Studio, files with the same names are marked as being conflicting files.
Actualizing sources from Modelio to Visual Studio.
In the example above, the “NewAccount” class has been added to the “Bank” package, which is the root namespace of the project [ 1 ]. After actualization, if the focus is positioned on the “Bank” project previously opened in Visual Studion a window opens informing us that the project file (.csproj) sources have been modified [ 2 ]. After confirming the addition (using the “Reload” button), the Visual Studio explorer displays the same source tree.
Warning: Classes, interfaces and enumerations added in Modelio will not be taken into account unless they are generated previously.
You can also compile your project from Modelio using the project model element. Modelio C# Designer provides two shortcuts for building “Debug” and “Release” solutions via Visual Studio.
To build a “Debug” or “Release” solution of your Visual Studio project, simply
select the project model element in the explorer, and then click respectively
on the icon or the
icon in the C# property view.
The icons used to build debug or release solutions.
To create a new VS project, simply select the package that will represent the root of your project in the explorer and use the ‘Create C# Designer element’ contextual menu.
Creating a new Visual Studio project
A new model element represented by the
icon (“Console Application” by default) is created and linked to the
previously selected package. The name of this project element is by default
the name of the root package (suffixed by a number if this name is already
present in the explorer).
The creation of a project model element can lead to the automatic generation of an empty project file (.csproj) of the same name. This associated file situated in the project root package’s generation directory corresponds to the version of your Visual Studio IDE.
Note : This new project model element can subsequently be moved as you wish, without affecting its associated features and data.
Visualizing information on your Visual Studio project.
When you select the project element in the explorer, the C# property view displays the essential information relative to your Visual Studio project (Application Properties).
The project model element enables you to quickly edit an entire project in Visual Studio from your C# Designer module, using the “Open in Visual Studio” command.
To open a project in Visual Studio, simply select your project model element
in the explorer, and then click on the icon in
the C# property view.
Opening a Visual Studio project from Modelio.
Note 1: It is only possible to open a Visual Studio project from the C# Designer module if you have already set the “Command to launch Visual Studio” parameter in the “General” parameter set.
Note 2: In order to avoid any possible desynchronization, only open the same project once in Visual Studio.
The Visual Studio IDE window.
This command launches the Visual Studio IDE (3) specified at module parameter level (using the “Command to launch Visual Studio” parameter).
The Visual Studio “Solution Explorer” presents all the sources associated with the project (5), as well as the “assemblies” (4) used by the project. The “System.Core” assembly is automatically added to the project if you are using the 2008 version of Visual Studio, while the “System” assembly is always present, whatever your version of Visual Studio.
As shown in the table below, a project can only be opened if the version of your Visual Studio IDE is greater than or equel to the version of your project file (.csproj).
Visual Studio version / Project file version | < | = | > |
---|---|---|---|
Effect | Error | Project file is opened | Warning. Project file migration is suggested. |
Modelio C# Designer provides a shortcut for launching the application from Modelio via the project model element. Where necessary, this command first compiles the solution corresponding to your configuration.
To run the assembly of your Visual Studio project, simply select the project
model element in the explorer, and then click on the icon in the C# property view.
Running the application.
Note : The
icon is associated with Console and Windows applications, and is not therefore visible for the “Class Library” (DLL) output type.
“Assembly” execution takes place in a command prompt window for a Console application or via Visual Studio for a Windows application.
Execution example in a command prompt.
Note: A Visual Studio process is run in the background throughout the duration of the application execution.