Free tutorials on UML for beginners / PDF

Free tutorials on UML for beginners / PDF

Using Rational Rose in conjunction with the notes on the web server relating to UML, attempt to model the combined light, switch and bulb classes in the following way:-

Ø  In the Use-case view of rational rose, create a new actor called ‘home owner’ and drag this actor from the ‘use-case view’ to the ‘logical view’. (see below)

For the remainder of the points below, assume that they refer to the logical view.

Ø  Create a new ‘use-case diagram’ called ‘Main’, double click on it to open it up and drag the home owner actor onto it.

Ø  Now introduce two ‘use cases’ called ‘Lamp on’ and ‘Lamp off’ and place them on the ‘use-case diagram’ and connect the ‘home owner’ (actor) to the two use-cases via a ‘uni-directional association’ to show that this actor interacts with the them. You should now see something like this which attempt to capture the users two main interactions with the system.

Ø  Double click on each of the two use-cases in turn to open their specification and type in a description of what they do i.e. turn the switch and bulb on (or off) accordingly. See below for a simple example. This description captures the requirements for that particular use-case. Obviously this is a very simple example and hence the description is correspondingly straight forward.

Now we are going to use a class diagram to represent each of the classes that will be needed to model our system. In this class diagram we are attempting to capture the essential relationships that exists between instances or objects of those classes.

Ø  By default rational rose creates a class diagram for us in the logical view called ‘Main’. Double click on this to open it.

Ø  Create new classes called ‘lamp’, ‘bulb’ and ‘switch’ in the logical view browser and drag them onto the ‘Main’ class diagram. (See below)

Using your notes on UML from the web-based server, learn how to add attributes and member functions to your class and also how to set the multiplicity and containment of classes. See if you can replicate the following diagram

This shows that all classes have a single data item or attribute called ‘state’ which is private and which is represented by an ‘int’. Likewise all classes have two member functions called On() and Off() which are public (we’ll ignore constructors and destructors and the other functions you wrote for your classes in C++ until later)

The above diagram also shows that there is a relationship between the Lamp and the Bulb, and between the Lamp and the Switch indicated by the line (known as an association) connecting them. The ‘1’ highlighted at each end is known as the multiplicity and indicates how many instances of a Lamp exists for each instance of a Bulb and Switch. In this case it shows that each Lamp has exactly one bulb and one switch. That is for each instance of a lamp, there will exist one switch and one bulb that belong to it and that each bulb and switch belongs to exactly one Lamp (they cannot be shared between two lamps for example). The arrow at the end of the association indicates that messages may be sent from the lamp to the bulb (but not the other way around). If bidirectional message passing is required (from lamp to bulb and from bulb to lamp) then an association with NO arrows on it is used. This is in fact the default when an association is first created.

Note that there is a filled diamond on the Lamp end of the relationship. This indicates containment by value, i.e. that the Lamp ‘owns’ the switch and bulb in other words the bulb and switch are ‘part-of’ the lamp.

This containment implies that when a lamp is created, a bulb and a switch must also be created and likewise when the lamp is destroyed the bulb and switch and also destroyed. In other words their lives are interconnected and thus a bulb cannot exist without the lamp and vice-versa. We implemented this containment in C++ using aggregation by placing an instance of a bulb and a switch inside a  lamp e.g.

class Lamp      {

private:   Bulb b1 ;                   // C++ containment of a bulb by value

              Switch s1 ;                 // C++ containment of a switch by value

            …

};

If we had drawn the diagram like this with open diamonds representing containment by reference on the end of the relationship, then it would imply that the lives of the Lamp, Bulb and Switch are not interconnected and could lead separate lives and existences, i.e. we could create an instance of a bulb and a switch quite separately without there having to be a Lamp and vice-versa. The lamp could then be given its bulb and switch separately at some point in the future, in fact that could even be replaced or swapped out

Note that when we changed the containment from one of ‘value’ (filled diamond) to one of ‘reference’ (open diamond) we had to change the multiplicity from ‘1’ to ‘zero-or-one’ to indicate that at any point in time a lamp object could actually exist with either no switch/bulb or one switch/bulb since their lives are now independent. In C++ containment by reference is implemented using pointers as shown below.

class Lamp      {

private:   Bulb   *b1 ;                 // C++ containment by reference using a pointer

              Switch *s1 ;                // C++ containment by reference using a pointer

            …

};

Obviously introducing an instance of the lamp will not automatically introduce an instance of the bulb or switch (only a pointer to them). We have two solutions to addressing this. Firstly we could write our lamp constructor to automatically create a bulb and switch object using operator ‘new’ or alternatively we could include a ‘swapbulb()’ or ‘attachbulb()’ function to allow us to swap or attach an existing bulb (and switch) at some point after the creation of the lamp.

The choice of containment type is up to us but it would appear that containment by reference (i.e. using pointers) whilst adding somewhat to the complexity of the code, gives us a degree of flexibility not afforded when using containment by value, that is, it gives us the ability to attach and detach the bulb and switch to/from the lamp and is more realistic in the sense that real bulbs ‘blow’ and will need replacing.

Class Associations: Containment vs. Association

Yet another alternative representation of the above classes is shown below, where containment (either by reference or value) is NOT represented. In essence the classes are linked by associations (i.e. no diamonds on the end). This means that the lamp does not own the bulb or switch and thus they can have quite separate lives but it does rely on their existence and co-operation in order to work. It’s a philosophical debate as too which approach is better, but the question you should ask is which one do you feel comfortable with?.

If in your opinion you see one object as containing or being composed of another then show some form of containment on the class diagram. If you view the classes as just co-operating then just show an association. The implementation of an association is the same as it would be for containment by reference, i.e. the lamp would contain pointers to the bulb and switch....

Free tutorials on UML for beginners / PDF