An Overview of the UML

Chapter 4
Dr Jibran Mir
UML helps to see different viewpoints
• The first thing to notice about the UML is that there are a lot of
different diagrams (models) to get used to. The reason for this is
that it is possible to look at a system from many different
viewpoints.
• A software development will have many stakeholders playing a
part –for example:
• Analysts
• Designers
• Coders
• Testers
• QA
• The Customer
• Technical Authors
UML helps to see different viewpoints
• All of these people are interested in different aspects of the
system, and each of them require a different level of detail.
• For example, a coder needs to understand the design of the
system and be able to convert the design to a low level code.
• By contrast, a technical writer is interested in the behaviour of
the system as a whole, and needs to understand how the
product functions.
• The UML attempts to provide a language so expressive that all
stakeholders can benefit from at least one UML diagram.
The Use Case Diagram
• A Use Case is a description of the systems behaviour from a users
viewpoint.
• This diagram is a valuable aid during analysis – developing Use
Cases helps us to understand requirements.
• The diagram is deliberately simple to understand. This enables both
developers (analysts, designers, coders, tests) and the customer to
work with the diagram.
• However, do not be tempted to overlook Use Cases as being ““too
simple to bother with””.
• We shall see that Use Cases can drive an entire development
process, from inception through to delivery.
The Class Diagram
• Drawing Class Diagrams is an essential aspect of any Object
Oriented Design method, so it isn't surprising that the UML
provides us with the appropriate syntax.
• We'll see that we can use the Class Diagram at the analysis
stage as well as design – we'll use the Class Diagram syntax to
draw a plan of the major concepts our customer understands
(and we'll call this the Conceptual Model).
• Together with Use Cases, a Conceptual Model is a powerful
technique in requirements analysis
Collaboration Diagrams
• As we are developing object-oriented software, anything our
software needs to do is going to be achieved by objects
collaborating.
• We can draw a collaboration diagram to describe how we
want the objects we build to collaborate.
Sequence Diagram
• The sequence diagram is, in fact, directly related to the
collaboration diagram and displays the same information, but in a
slightly different form.
• The dotted lines down the diagram indicate time, so what we can
see here is a description of how the objects in our system interact
over time.
• Some of the UML modelling tools, such as Rational Rose, can
generate the sequence diagram automatically from the
collaboration diagram, and in fact that is exactly how the diagram
above was drawn –- directly from the diagram in Figure 15.
State Diagrams
• Some objects can, at any particular time, be in a certain state. For
example, a traffic light can be in any one of the following states:
• Off, Red, Amber, Green
• Sometimes, the sequence of transitions between states can be
quite complex – in the above example, we would not want to be
able to go from the “Green” state to the Red” state (we'd cause
accidents!).
• Although the traffic light may seem like a trivial example, being
sloppy with states can cause serious and embarrassing faults to
occur in our software.
State Diagrams
• Take as a case in point –-a gas bill is sent out to a customer
who died four years ago – it really happens and it is because a
programmer somewhere has not taken care with their state
transitions.
• As state transitions can be quite complex, the UML provides a
syntax to allow us model them.
Package Diagrams
• Any non-trivial system needs to be divided up in smaller, easier
to understand "chunks", and the UML Package Diagram
enables us to model this in a simple and effective way.
Component Diagrams
• The Component Diagram is similar to the package diagram - it
allows us to notate how our system is split up, and what the
dependencies between each module is.
• However, the Component Diagram emphasises the physical
software components (files, headers, link libraries, executables,
packages) rather than the logical partitioning of the Package
Diagram.
• Again, we’ll look at this diagram in more detail in the System
Architecture chapter.
Deployment Diagrams
• The UML provides a model to allow us to plan how our software
is going to be deployed. The diagram above shows a simple PC
configuration, for example.
Summary
• The UML provides many different models of a system. The following is a
list of them, with a one sentence summary of the purpose of the model:
• Use Cases - .How will our system interact with the outside world?.
• Class Diagram - .What objects do we need? How will they be related?.
• Collaboration Diagram - .How will the objects interact?.
• Sequence Diagram - .How will the objects interact?.
• State Diagram - .What states should our objects be in?.
• Package Diagram - .How are we going to modularise our development?.
• Component Diagram - .How will our software components be related?.
• Deployment Diagram - .How will the software be deployed?.