Introduction to the Unified Modelling Language UML

1
Introduction to the Unified Modelling Language
(UML)

• Originally conceived by Rational Software
  Corporation in the mid 90s
• Main players Booch, Rumbaugh, Jacobson
• A unification of Boochs method, OMT (Object
  Modelling Technique) and OOSE (Object Oriented
  Software Engineering)
• Standard maintained by the OMG (Object Management
  Group)
• Now the most widespread notation, supported by
  numerous CASE tools

2
What is the UML?

• A language and a notation
• A set of diagramming techniques which model
• the users view (a user could be human or another
  system)
• structure of a problem or solution
• behaviour of a system
• implementation of a system
• deployment
• A consistent notation which can be used
  throughout
• requirements gathering
• analysis
• design
• implementation
• Unlike the OMT, the UML is not a methodology, but
  it does provide flexible and extensible tools to
  support a process

3
Why bother?

• Documentation of designs for future reference
• The need for clear communication between
• customers
• analysts
• designers
• coders
• testers
• managers
• As systems increase in size and complexity,
  visualisation, specification and communication
  become increasingly difficult and increasingly
  important
• It is a matter of scale
• for small scale systems, you probably dont
  need it
• for medium scale systems you could get away
  with a class diagram, and maybe some use cases
• for large scale systems you may need the full
  range of techniques

4
UML views

• User view
• used to describe the functionality of the system
  that the users expect
• users can be human operators or other systems
• Structural view
• also referred to as the static or logical view
• shows the structure of a problem or solution
• Behavioural view
• presents the dynamics of the system - what
  happens (or might happen) at run-time
• interactions between users and the system, and
  between elements of the system
• Implementation view
• organisation of implementation components
• Environment view
• mapping of implementation components onto
  processing resources

5
Diagram types

• User view
• use case diagram
• Structural view
• class diagram
• object diagram
• Behavioural view
• sequence diagram
• collaboration diagram
• statechart diagram
• activity diagram
• Implementation view
• component diagram
• Environment view
• deployment diagram

6
Diagram types continued...

• Use case diagrams
• describe the system from the perspective of
  external actors
• useful during requirements analysis and
  specification
• Class diagrams
• show the static structure of the system
• how it is declared rather than how it behaves
• shows classes and relationships (associations,
  inheritance, aggregation, etc.)
• Object diagrams
• are an instance of a class diagram
• show the objects and relationships at a specific
  point in time
• in a dynamic system (where objects are
  created/destroyed on-the-fly) there may be many
  possible object diagrams
• used to validate the class diagram

7
Diagram types continued...

• Sequence diagrams
• describe the behaviour of the system to actors
• contain classes that exchange messages
• are time ordered
• Collaboration diagrams
• show how behaviour is realised by parts of the
  system
• classes, associations and message exchange
  sequences that realise a particular behaviour
• Statechart diagrams
• describe the response of a class to external
  stimuli
• show the life-cycle of an object
• Activity diagrams
• describe the behaviour of a class in response to
  internal processing rather than external events

8
Consistency between views

• UML diagrams present different views of a
  problem/solution
• These views must be consistent
• Examine how they reflect related aspects of
  system structure or behaviour
• Some examples
• object diagrams must be consistent with the class
  diagram in terms of multiplicity and
  relationships between objects
• sequence diagrams show the interactions between
  system objects and actors in order to realise
  some required behaviour, and should therefore be
  consistent with the use cases
• diagrams showing interactions between objects
  must be consistent with the relationships
  depicted on the class diagram
• collaboration and sequence diagrams are
  semantically equivalent
• sequence diagrams emphasise the time ordering of
  interactions
• collaboration diagrams emphasise the organisation
  of objects that interact

9
Key points

• UML is the most widespread analysis and design
  notation
• UML can be used to specify and model a problem or
  solution at all stages of development
• UML is not a methodology
• if you want to understand the analysis and design
  process, then a UML text will not help you much
• check out some of the many object oriented
  analysis and design texts
• You need to be familiar with the types of UML
  diagram and what they depict
• so that you can communicate effectively within a
  team
• so that you can specify and model large/complex
  systems
• Think about what you need to communicate
• you dont necessarily need to provide all types
  of diagram to adequately model your system -
  there is considerable overlap between diagram
  types
• UML is not prescriptive - it can be extended to
  fit your purpose