Basics of modelling

Class diagrams

Use class diagrams to graphically represent objects, and the relationships between objects. The basic element of a class diagram is the class itself; this is used to represent a particular object or, more usually, a type of object. The following diagram shows an example of a class diagram:

Figure 1. Class diagram

Classes have attributes. These are properties that you can use to describe an instance of that class, and to differentiate one instance of the class from another.

Classes can have associations to other classes. You use these associations to represent functional, or otherwise meaningful, relationships between objects. WSRR Studio uses directed associations, to represent relationships between objects. Directed associations are one-way, in that the relationship can be traversed only from its source to the target. For example, in Figure 1, ClassB has a relationship with ClassC, but ClassC does not have a relationship with ClassB because the association is one-way, and directed from ClassB to ClassC.

Classes can be generalizations of other classes. This means that one class can be a subclass of another class, called its superclass; the subclass inherits all of the attributes of the superclass, in addition to its own attributes. For example, in Figure 1, ClassB is a generalisation of ClassA. This means that ClassB inherits all of the attributes of ClassA, so any instance of ClassB has attributes AttributeA1 and AttributeA2, in addition to AttributeB1.

By using these modelling constructs, you can graphically represent many of the concepts and objects that are contained in WSRR.

State machine diagrams

You use state machine diagrams to graphically represent the flow of activity from one state to the next. All state machines have an initial state, from which they begin, with activity flowing through a series of states, usually, but not always, to a final state. The following screen capture shows an example of a state machine diagram:

Figure 2. State machine diagram

Transitions between states can either be automatic or triggered. For example, in Figure 2, the transition Transition1, from InitialState to State1, is automatic. However, there are two possible outcomes of State1; it is the trigger that determines which transition is taken. If TriggerA is used, then Transition2 is taken and the next state moved to is State2. However, if TriggerB is used, then Transition3 is taken and State3 is the next state to be moved to.

After either State2 or State3 is reached, further triggers must occur to move into either State4 or State5. Upon reaching State4, a further trigger must be started to reach the FinalState. However, upon reaching State5, no further trigger is required, and therefore FinalState is entered immediately after State5 is reached.

By using these state machine modelling constructs, you can graphically represent the object and governance life cycles that are used in WSRR.