The C# profile contains several stereotypes that you can
use to mark up your UML model and to control how the transformation
transforms each model element into C# code. The stereotypes of the
profile become available when you apply the profile to your source
model.
You can apply the stereotypes of the C# profile to model elements
in your source model to specify how the transformation generates C#
code. For example, when you apply the «CSharp Method» stereotype to
an operation in the model and set the virtual stereotype property
to true, the transformation generates a virtual operation.
Guidelines for modeling .NET applications using the
C# profile
Use the following guidelines when you create
UML models that represent C# applications:
- Microsoft Visual Studio 2005 or Visual
Studio 2008, Standard or Professional Edition must be
open whenever your IBM® Rational® modeling
product with Rational Modeling Extension
for Microsoft .NET is
opened.
- While naming packages in the model, do not use a period (.) in
the package names. For example, if you need to nest packages "xtools"
within "ibm" within "com" instead of naming a single package "com.ibm.xtools,"
use a hierarchical package structure and create a package, "com,"
nesting package "ibm" and nesting "xtools." This notation always has
a unique representation and will help reduce false messages in the
fuse window while transforming code to model.
- Apply C# stereotypes only when you need to set some C#-specific
values through the stereotype properties. Otherwise, if the identical
code will be generated without applying the stereotype, the C#-to-UML
transform assumes that no stereotype was used during the prior UML-to-C#
transformation, and the Reconcile window opens showing a delta suggesting
that the stereotype should be removed from the UML model.
- Invalid combinations of applied stereotypes are not detected.
Avoid invalid use of profile stereotypes. For example, applying both
«CSharpClass» and «CSharpInterface» is invalid, and this will result
in unpredictable transformation behavior.
- While modeling partial types, use one empty type as a partial
type on which each part is shown as a dependent part. Include the
modeled empty partial type (the source) and the defined partial types
(with dependency relations to the source) in a single package in the
model. In this way, all parts of the partial type are defined in one
package in the model. The name of the source will be used as the type
name and the name of the other part will not be used as the name of
the type. Using a mapping model, each partial part can be directed
to a different file. While transforming from code to model, the names
that were used by the user for each of the parts is not known and
hence the transformation generates the names as [typename]_[filename],
which will appear as a difference in the fuse window.
- In C#, generic types can only be used if the values for type parameters
are specified. Construct a new type for a generic type by binding
its type parameters. So, a List class with parameter T can be used
by using List[string]. In UML, such constructed types are represented
as template bindings and the names of the types are not used while
transforming code to UML to generate the temporary model. The constructed
types are displayed as anonymous type names that will be shown as
a difference in the merge window, and you must then map the types
to the actual template binding in the target model.