UML modelling. This article gives a short overview of UML2.
1. UML
1.1. Overview
Eclipse supports the creation of UML2 diagrams via UML2 Tools project. UML2 Tools is a set of GMF-based editors for viewing and editing UML models.
1.2. Definition
The Unified Modeling Language (UML) is a visual language for capturing software designs and patterns. The first version of UML was defined 1994 and released by the Object Management Group (OMG) in 1997 as UML v.1.1. The syntax and a semantic of UML is defined by the OMG.
The basic building block for UML is a diagram. UML
divides diagrams
into
structural diagrams
and
behavioral diagrams
The latest version UML 2 has the target to add the ability for modelers to capture more system behavior. UML 2 has the target to support model driving architectures (MDA). MDA has the target to create automatically a software program from several models.
1.3. UML Profiles
UML is intended to be extended. The formal way to extending a UML model is via a UML profile. A UML profile a collection of UML stereotypes and constraints on elements that map the generic UML to a specific problem domain or implementation. For example a UML profile can be used to support the modeling of J2EE software components.
2. Appendix: Class diagrams
2.1. Overview
A class diagram captures the static relationships of your software.
2.2. Classes
A class is represented by a rectangular box divided into
compartments.
A Compartment is an area in the box to write
information. The first
compartment holds the
name, the second holds the
attributes
and the third is used for the
operations.
Any compartment can be hidden to improve readability of the diagram.
UML suggests that a class name:
-
Starts with a capital letter
-
is centered in the top compartment
-
is written in a boldface font
-
is written in italics if the class is abstract
2.3. Attributes
Attributes specifies details of a class and can be simple types or objects.
Attributes can be defined inlined (as part second compartment of the diagram of the class) or as relationship.
2.4. Inlined Attributes
Inlined attributes are placed in the second compartment of the class.
The notation for inline attribute is:
visibility name: type {multiplicity} {=default}
| Element | Values | Description |
|---|---|---|
visibility |
+ - # ~ |
public Attribute private Attribute protected Attribute package Attribute |
name |
myName |
Name of the attribute following the camelCase notation |
type |
Class name, interface or primitive types, e.g. int |
|
multiplicity |
Optional, if not specified then it is assumed to be 1, * for any value, 1,..,* for ranges. |
|
default |
Optional, default value of the attribute |
2.5. Attributes by Relationship
To model attributes by relationship you use an association relationship between the class which represents the attribute and the class containing the attribute.
2.6. Static Attributes
Static attributes (attributes that are part of the class and not part of the instance of the class) are displayed via underlining the name of the relationship.
2.7. Interfaces
Interfaces are indicated via the stereotype interface.
Relationships can be expressed via the ball-and-socket notation.
2.8. Relationships
UML defines several ways of representing relationships between classes.
2.9. Association
Read as "..has a.." association between classes. Drawn as a straight line between the two classes. Does not mean that the classes are owned by one, other classes may use the connected class too.
2.11. Composition
Strong relationship between classes to the point of containment. Read as "..is part of..". If the owning instance is destroyed then normally (not necessarily) the linked object is destroyed too.
2.12. Generalisation
Read as ".. is a..". Use to express inheritance. Represented by a solid line and a hollow triangular arrow. For example the following code could be expressed with the following diagram.
package animals;
public abstract class Animal {
}package animals;
public class Frog extends Animal {
}
2.13. Export your class diagram as image
To export your diagram as image / graphic, right-click on your diagram and select .
3. Appendix: Model-Driven Architecture (MDA)
3.1. Overview
MDA is the approach in which models are automatically translated into complete, deployable, running applications.
MDA defines several levels for these models, Platform independent models, platform specific models and code models.
3.2. Platform Independent Model (PIM)
Represents the business model to be implemented and can be described via UML. The PIM describes the processes of the business model and the structure of the system. The PIM does not specific operating system, programming language and hardware.
3.3. Platform Specific Model (PSM)
The PSM is responsible to specify the technical details to implement the PIM, e.g. the operating system, the programming language. In case several realizations / implementations for a PIM are possible then several PSM are formulated.
3.4. Code Mode
Represents the deployable code. In an ideal MDA scenario this code could be directly compiled and deployed without human interaction.
4. Tooling
The Eclipse Modeling Framework
See EMF tutorial to learn how the Eclipse IDE provides support for getting logical models and UML representations of it.
5. Links and Literature
5.1. vogella Java example code
If you need more assistance we offer Online Training and Onsite training as well as consulting