Usage of UML

As UML is just a notation, there are many possibilities how to use it. Some of them are part of a sophisticated methodology, some are just simple and pragmatic. We're trying to give a nice inspiring overview on these pages:


 * Analysis and Design of Software Systems (still empty)
 * Documenting/Understanding Software Systems
 * Implementation Modeling for Software Systems
 * Model Driven Architecture (still empty)
 * Model Driven Development (still empty)
 * Process Modeling (still empty)

You can find a more notational (diagram oriented) perspective on how to use UML below.

= Structure Diagrams =

The following diagram types belong to the group of structure diagrams:


 * Class diagram
 * Object Diagram
 * Component Diagram
 * Composite Structure Diagram (UML2)
 * Package Diagram
 * Deployment Diagram

Class Diagram
Class diagrams are the most commonly used diagram type in UML. They give an overwiew of the system (or a part of it) that is modeled. In fact, in many cases usage of UML is restricted to just using class diagrams. Class diagrams give answer to the following question: What are the entities of my system, and how are they related?

The great thing about class diagrams is, that they are useful on every abtraction level: from system analysis down to the implementation level. In the system analysis phase, the focus is more on the relations of (nontechical) real world entities. In the implementation phase, the class diagrams show only entities that exist in the software system, but in great implementation detail; these diagrams sometimes are produced using reverse engineering of source code and used for code generation (or full roundtrip engineering).

The main entities of a class diagram are: classes, interfaces, types (enumerations etc.), relations (associations, generalizations etc.).

Example: an analysis class diagram
Let's describe the structure of a ... (whatever)

Example: an implementation class diagram
Here's an example of the maximum detailed model of a piece of source code, taken from the ArgoUML sources (it's only a very small example, implementation class diagrams can be much more complicated):



Object Diagram
Objects are instances of classes. Showing them on a diagram serves as a sample instantiation of a class diagram and can help to imagine possible configurations allowed by the class diagram. An example: while the class diagram for a tree might consist of only one class (named "Node") with self associations ("parent" with multiplicity 0..1, "children" with multiplicity 0..*), which makes it hard to see the tree structure, a corresponding object diagram can easily show the tree structure.

Component Diagram
t.b.d.

Composite Structure Diagram (UML2)
t.b.d.

Package Diagram
Packages are a grouping mechanism for classes, and when one class "inside" one package references another class in another package, then it is said that the first package depends on the other package. Of course another class of the second package could also reference a class in the first package, which makes the second package also depending on the first package. This is called a cyclic dependency (in a cycle there could be involved more than 2 packages). In a good design of a system, you try to avoid such cyclic package dependencies by an intelligent grouping in packages. If this is done, then a package diagram is a good way to document the package dependency tree (yes tree, if there are no cycles). Additionally to dependencies, the package hierarchy can be expressed by drawing include and merge relations.

Deployment Diagram
t.b.d.

= Behavior diagrams =

The following diagram types belong to the group of structure diagrams:
 * Use Case Diagram
 * Activity Diagram
 * State Machine Diagram
 * Sequence Diagram
 * Collaboration Diagram
 * Interaction Overview Diagram (UML2)
 * Timing Diagram (UML2)

Use Case Diagram
Use case diagrams present on a high level what a system can do and which persons/systems interact with the system: What functionality does my system have, and who interacts with it?. They are often an entry point to the model of the system (but sometimes one starts with a class diagram on analysis level).

Since use case diagrams either has not much more expressivenes than a few presentation slides or become too complex on a more technical level, some people don't use them. Also, if you started the analysis phase with another methodology, use case diagrams might be of no use to you. Some like them, because they allow to partition the different behavioral aspects of a system under different use cases (assign each behavioral diagram to one use case).

Example: a use case diagram
We use the same example as for the analysis class diagram, which is... (whatever)

Activity Diagram
t.b.d.

State Machine Diagram
t.b.d.

Sequence Diagram
t.b.d.

Collaboration Diagram
t.b.d.

Interaction Overview Diagram (UML2)
t.b.d.

Timing Diagram (UML2)
t.b.d.