Fundamentals of UML and Class Diagrams and Sequence and Activity Diagrams

Fundamentals of UML and Class Diagrams and Sequence and Activity Diagrams 

Introduction to UML

The Unified Modeling Language (UML) is a mainly graphical notation for specifying, visualising and constructing the descriptive diagrams and documentation of software system. It is the industry standard for object-oriented modelling, created and maintained by the Object Management Group.

UML1 was adopted in 1997, and combined the best approaches from various diverse modelling languages that had been developed since the introduction of object-oriented programming. UML2, adopted in 2005, provides more diagrams, and significant improvements in usability and consistency.

UML can be used at various different levels.

• The most common and recommended approach is to use it to sketch complex problems in a fairly informal way, to aid understanding. You should be selective, and only draw a diagram if it shows details more clearly than just a text description.
• UML can also be used to create a complete blueprint of the system. This is usually too time-consuming, especially if design changes before the project is complete.
• Finally it could be used as a programming language, where diagrams can be transformed to executable code. This use is not widespread.

UML can be used at the design stage, to determine requirements, classes and the interaction between them. It can also be used for documentation, to record the final requirements, classes and interactions.

There are many good books on UML, such as ML Distilled Third Edition by Martin Fowler : Addison Wesley  ISBN 0-321-19368-7. This book is chatty and compact, drawing on the author’s experience.

There are many tools which can be used to create UML diagrams. The disadvantage of these is that they often offer many facilities which aren’t needed on this module, and so are fairly complex to learn, and may automatically suggest notation which is incorrect for your diagram. The advantages are that the diagrams are probably easy to alter, may generate skeleton code, and you can mention them on your CV.  In the lab, we have ArgoUML and Dia. Asking students in the past what they prefer has never come up with a firm favourite. I mostly draw my diagrams using the Draw option in powerpoint, simply because I know how to do that. Even neat hand-drawn diagrams are acceptable (but scan a copy for yourself before handing anything in).

Class Diagrams

The class diagram shows the state and behaviour of objects of a particular class, by splitting the rectangle into three sections.

An object has a public interface defining the operations it will support.

An object can have private internal operations, for its own use only

An object has private internal data, attributes, which only its own operations can access.

The access modifier specifies whether other classes are permitted to use the attribute or operation. Modifier values are:

+     public           can be accessed by any class

-      private          can be accessed only by this class

#     protected      can be accessed by this class and its subclasses

A line joining the classes represents an association between objects of that class. We optionally attach a label to the association, with a black triangle to indicate direction (e.g. Owner has Dogs).

We can also add multiplicities to show the degree of association - very much like entity-relationship diagrams. Note how they are read

·         An owner has 0 or more dogs.

·         A dog has only one owner.

 

When drawing associations, the attributes and operations are sometimes omitted. This is a good idea when there are a lot of classes – use classnames only and show links between the classes, and show the attributes and operations in a separate diagram.

Open arrow heads on the associations show navigability. This indicates which object needs to know about which other object to make an association work. We try to keep navigability one way to reduce coupling – the number of links between classes.

You may also see diamonds, open or filled, on the association lines. These represent aggregation and composition, and should be used with care. I wasn’t going to cover these in this course, but since you will find them in UML tools, I had better mention them.

Association represents the ability of one instance to send a message to another instance. This is typically implemented with a pointer or reference instance variable, although it might also be implemented as a method argument, or the creation of a local variable.

Aggregation is an association which specifies a whole/part relationship, and is shown with an open diamond. E.g. A Team consists of Employees and subTeams.

Composition is a stronger aggregation, in which the part does not exist without the whole. It is shown with a filled diamond.

So you can see that you should not freely add filled in diamonds to all your associations.

INHERITANCE is covered in the second half of the course. Inheritance between classes is shown with an open triangle. The same symbol is used for superclasses and interfaces, with the tag <> or < included with the classname......

Fundamentals of UML and Class Diagrams and Sequence and Activity Diagrams