Site overview
For intra component modeling, i.e. the fine grained static structure, it is common to use UML class diagrams. There are several levels of abstraction a class diagram can be utilized [Fowler03] for this purpose:
- Conceptual Level
Used for modeling concepts/“things”/roles of a domain. This is how class diagrams should be initially used in the analysis phase of a project to gain a deeper understanding of the area of application. - Specification Level
Used for modeling interfaces between software components, independently of implementation specifics. - Implementation Level
Modeling of software classes which correspond directly to programming language code (like C# or Java).
 |
To model the static structure of the inner workings of a system, the “ActiveCharts (Statics)”-stencil shown in the left figure is used. It consists of the following elements:
|
The next sections describe how to model these elements in detail. For more convenient modelling ensure that spell checking and “AutoCorrect” options are turned off in Visio 2003.
 |
After dragging the class shape from the “ActiveChart (Statics)” stencil, you can name it by double-clicking the shape. |
 |
All class names are converted to uppercase by ActiveCharts, since this is the C# naming convention. |
 |
To add attributes, first single-click the shape, drag the yellow spot marked in the left figure upwards ... |
 |
…then click on the attributes compartment (the rectangle below the class name) and either start typing (e.g. “ active : bool ”) or press F2 to get a text cursor to modify the text. Add additional attributes in the same compartment – by using F2 to enter the editing mode. |
|
Our Visio stencils do not check syntax or semantics of what you type for your attributes. Errors will arise later when trying to generate code from your models. |
 |
You can add relationships by dragging either the “Straight Relationship” or “Routable Relationship” shape to your classes. Notice that only ends marked red are successfully connected to the respective class. |
 |
You specify multiplicities and role names by adding text at the positions marked by a yellow spot (see figure on the left). Click on the desired spot to enter text. To edit text already typed, single click the spot and press F2. |
|
If no multiplicities are defined, “0..1” is used as a default. If no roles are specified, the respective class name with a lowercase first letter is used. All association ends are public. |
 |
The figure on the left shows how multiplicities, role- and association-names are used. |
 |
You can also add aggregation or composition symbols to express whole-part-relationships, although our generator does not treat them in a special way at the moment. To specify the type of relationship (aggregation, composition, …), right-click the association and choose the appropriate type from the popup-menu. |
 |
To provide navigation directions, you also use the popup-menu (“Navigable Forward” and “Navigable Backward” types). These directions define visibilities within the modeled classes. In our example in the left figure, the AlarmDevice class can see Sensor instances but not the other way round. |
 |
Generalizations can also be modeled by right-clicking the association and choosing the “Generalization”-type. |
|
Note that only single inheritance is allowed in our class diagrams, since the target language does not support multiple inheritance. |
 |
Association classes add additional information to associations. See the example in figure on the left, where position information (x- and y-coordinates) is associated with an AlarmDevice -Sensor-pair. |
Code generated for association classes consists of “Pair<B,C>”-ends, where B is the opposite end class and C the association class.
 |
Notes add comments to shapes. They currently have no meaning for code generation. |