Software Engineering 4. Introduction to UML Review of UML Diagrams

1
Software Engineering4. Introduction to
UMLReview of UML Diagrams

• Leszek J Chmielewski
• Faculty of Applied Informatics and Mathematics
  (WZIM)
• Warsaw University of Life Sciences (SGGW)
• lchmiel.pl

2
Bibliography and sources

• Sources prepared by dr Waldemar Karwowski
• Smialek M. Zrozumiec UML 2.0 - rozdzial 3
• Wrycza S. Marcinkowski B. Wyrzykowski K. Jezyk
  UML 2.0 w modelowaniu systemów informatycznych -
  rozdzial 2
• Górski J. (Red.) Inzynieria oprogramowania w
  projekcie informatycznym - rozdzial 4
• Jaszkiewicz A. Inzynieria oprogramowania
  rozdzial 5 i 6
• There is an abundance of sources in EN.
• Two good sources are shown in the www page.

3
Unified Modeling Language (UML)

• January 1995 September 1996
• January 1997 sent to OMG
• end 1997 component of the UMG standard
• March 2000
• September 2001
• March 2003
• July 2004 (January 2005 ISO/IEC 19051 standard)
• July 2005
• August 2007
• November 2007
• February 2009 UML 2.4.1
  August 2011

4
Sources of UML
5
History of object notations
6
UML Short characteristics

• Present UML is very popular in analysis and
  design
• This state will probably persist for many years
• The UML notation is founded upon the basic
  notions of object-oriented modelling
• The notions used in UML are designed to cover the
  majority of significant aspects of the modelled
  systems
• UML can be used in any methodology

OMG (Object Management Group www.omg.org) The
Unified Modeling Language (UML) is a graphical
language for visualizing specifying constructing
and documenting the artifacts of distributed
object systems.
Wikipedia The Unified Modeling Language (UML) is
an open method used to specify visualise
construct and document the artifacts of an
object-oriented software-intensive system under
development.
7
Critical remarks to UML

• Some consider UML to be overpublicized
• unstable too heavy badly defined
• Competitors
• DSL (Domain Specific Languages) IDF4 Design by
  Contracts (Java Modelling Language) and many
  others

8
Critical remarks Microsoft

• Visual Studio 2005 Team System Modeling Strategy
  and FAQ May 2005

Does Microsoft continue to believe in the value
of UML modeling tools? If so why isn't Microsoft
supporting UML 2.0? Yes absolutely. We believe
that UML continues to have its place in the early
stages of the software development life cycle and
we are continuing to support a number of partners
who will deliver UML 2.0 tools for Visual Studio
2005. Our own domain-specific designers will also
support UML notational conventions where they
make sense. From Microsoft you will see a number
of new designers that treat models as first-class
citizens and that can be used to truly drive
development not just to create documentation. The
Distributed System Designers in Visual Studio
2005 Team Edition for Software Architects are the
first example of this type of tool. Is Microsoft
trying to ignore the UML standard and lock
customers into their own modeling language? No.
The UML standard is a weak one and for this
reason most UML tools are unable to seamlessly
interoperate. While we recognize the value of UML
for documentation and for understanding software
design domain specific languages will enable you
to work at higher levels of abstraction and to
focus with precision on issues relevant to
specific domains. Over time Microsoft will
provide additional domain-specific modeling tools
and we will continue to work with our partners to
bring UML tools to Visual Studio 2005 that are
built on top of our modeling framework.
9
Critical remarks but
Report of Forrester October 8 2008 OMG! Microsoft
Move Boosts Modeling. Rapprochement With Object
Management Group Sets The Stage For Progress by
Jeffrey S. Hammond Diego Lo Giudice with Mike
Gilpin Henry Peyret David D'Silva
With Microsoft's recent announcement that it is
rejoining the Object Management Group (OMG) the
industry can finally put to rest a protracted
debate about the relative value of Unified
Modeling Language (UML) and model-driven
architectures (MDAs) versus domain-specific
languages (DSLs) and begin to once more focus on
the value of modeling. Microsoft has much to
offer the OMG and assuming that it intends to
take strategic advantage of full member status is
well positioned to help the OMG make significant
progress in resolving a number of challenges that
have bedeviled the modeling community for example
the lack of a standard industry metamodel and a
robust way to exchange application metadata.
Reconciliation among the UML/MDA/DSL opponents
introduces a real opportunity for progress and
calls for a new model of the software modeling
space delimited by different modeling archetypes
instead of competing approaches to the "one true
path" to modeling righteousness.
10
Critical remarks but (continued)
Microsoft autumn 2008
Microsoft established its modeling strategy and
joined the Object Management Group (OMG). With
this move the company also is more explicitly
supporting the Unified Modeling Language
(UML). Once again Microsoft has proclaimed its
support for software modeling this time joining
the premier organization backing the adoption of
modeling in the enterprise the Object Management
Group OMG and pledging to support the OMG's
primary modeling standard the Unified Modeling
Language.
Visual Studio 2010 Ultimate
The Architecture Explorer in Visual Studio 2010
Ultimate helps you understand your existing code
assets and their interdependencies. Layer
diagramming helps ensure architectural compliance
and allows you to validate code artifacts against
the diagram. Plus Visual Studio 2010 Ultimate
supports the five most common UML diagrams that
live alongside your code.
11
Diagrams defined in UML 2

• Use Case diagrams
• Class diagrams
• Object diagrams
• State machine diagrams
• Activity diagrams
• Sequence diagrams
• Comunication diagrams
• Timing diagrams
• Interaction overview diagrams
• Component diagrams
• Deployment diagrams
• Composite structure diagrams
• Package diagrams
• Profile diagrams (starting from v. 2.2)

12
Diagrams defined in UML 2
13
Diagrams in UML 2.2 versus UML 1.4
UML 2.2 UML 1.4
Use Case diagram (diagram przypadków uzycia) yes
Class diagram (diagram klas) yes
Package diagram (diagram pakietów) used unofficially
Object diagram (diagram obiektów) used unofficially
Composite Structure diagram (diagram strukturalny, skladowych) brak
Component diagram (diagram komponentów) yes
Deployment diagram (diagram wdrozenia) yes
Activity diagram (diagram akywnosci, inaczej czynnosci) yes
State Machine diagram (diagram maszyny stanowej) Statechart diagram (diagram stanów)
Sequence diagram (diagram przebiegu, inaczej sekwencji) yes
Communication diagram (diagram komunikacji) Collaboration diagram (diagram wspólpracy)
Timing diagram (diagram przebiegów czasowych, nastepstwa) no
Interaction Overview diagram (diagram opisu interakcji) no
Profile diagram (starting from v. 2.2) (diagram profili) no
14
Object modelling

• Object, in object-oriented modelling, makes it
  possible to reconcile the laguages of the user,
  the designer and the programmer.
• It makes it possible to overcome the problem of
  system complexity.
• The objects
• Correspond to the notions of the problem domain
• Serve as a basis for implementation of the system
• Realize the abstraction principle hiding
  insignificant data
• Models are formed on the basis of objects
• Models are abstractions of the designed system
• Viewed from a specified perspective
• At a specified level of detail

15
Object modelling (continued)

• Model abstraction of the designed system, from
  a specified perspective, at a specified level of
  detail
• Diagram a means of description of the model
• A model can be described with many diagrams. An
  element can appear in numerous diagrams of a
  model.
• Object modelling consists in
• Finding the models in the envirionment
• Describing the structure and dynamics of the
  objects
• Classification of objects
• Structuring the classes of the objects
• Describing the dynamics of cooperation of the
  objects
• UML modelling is drawing the diagrams which
  describe the structure and dynamics of the system
  built from objects.

16
Modelling of the structure

• Each model should represent the structure of the
  modelled fragment of the reality or the system
• The way in which the elements of the model are
  related should be shown
• Classes as well as objects can be displayed
• In stucture diagrams the following elements
  should be represented
• Set of all states of the objects of the classes
• Set of all services offered by the classes
• Set of all relationships of the objects
• Set of all possible paths of communication
  between objects

17
Modelling of the structure (cont.)

• In UML
• Objects and their relationships are shown in
• object diagrams
• Classes and their relationships are shown in
• class diagrams
• package diagrams
• component diagrams
• Classes with their inner structure and
  properties
• composite structure diagrams
• Physical level of the system architecture is
  shown in
• deployment diagram

18
Modelling of the dynamics

• A model should present the system at work
• quality of the system and satisfying the user
  requirements depends from a good specification
  and a good implementation of the dynamics
• Showing the time sequence is basic for dynamics
• sequence of the activities of the system
• Sequence of the interactions with the users
• The model of dynamics has to be compatible with
  the structural model
• names, relationships, etc.

19
Modelling of the dynamics (cont.)

• Funtionality of the system from the point of view
  of the users is described with
• use case diagram
• Sequence of interactions between the objects is
  shown in
• sequence diagrams
• communication diagrams
• A graph of activities undertaken depending on the
  outside conditions or the state of the system are
  displayed in
• activity diagrams
• Interactions are shown in
• interaction diagrams
• Protocols as sequences of time-dependent messages
  are represented in
• sequence diagrams

20
Review of UML diagrams

• Construction industry analogy
• Architect, designer or programmer use the UML
  diagrams in a similar way as a bricklayer,
  pipefitter or electrician use a design of a
  building.
• an abstract, paper design makes it possible to
  underline the siginficant elements of the
  functioning of the software (building)
• The effect is that there are many UML diagrams
• Similarly as there are many ways in which a
  bricklayer, pipefitter, electrician, painter or
  owner look at the building, there are also many
  ways in which an analyst, designer, programmer,
  quality manager, author of the documentation or
  customer buyer of the software.
• The review was based on
• http//www.erudis.pl/
• http//www.sparxsystems.com/uml-tutorial.html
• http//www.tutorialspoint.com/uml/
• You can see also
• http//www.agilemodeling.com/

21
Use case diagram

• Shows the system from the point of view of a user
• Shows what, not how, the system does
• It does not contain too much knowledge in itself,
  so a documentation in the form of use cases
  (scenarios) is necessary
• Use cases are an important tool for collecting
  requirements
• Use case diagrams, despite their simplicity, are
  a very useful tool as a kind of contents list for
  the requirements of the modelled system

22
Use case diagram
23
Use case diagram
24
Use case diagram

• A figure represents an actor if it is not a
  human, it can be represented as a rectangle
• An ellipse represent a use case it contains a
  short description
• Lines and arrows (to be presented further)
  represent various types of relationships
• Relationships can be described by descriptors in
  ltltdelimitersgtgt (for example ltltincludegtgt,
  ltltextendsgtgt)

25
Class diagram

• Strictly related to the object-oriented
  modelling, even with the programming language
• Classes are represented by rectangles
• Fields and methods can be represented

26
Class diagram
27
Class diagram

• Relationships between classes are denoted by
  lines optionally arrows
• Multiplicities can be shown (0...)

28
Communication diagram

• System dynamics influences between classes and
  messages sent

29
Communication diagram

• Lines represent relationships
• Arrows represent directions in which messages are
  sent
• Numbers represent their sequence

30
Sequence diagram
31
Sequence diagram

• Now the subject of the diagram is the sequence of
  the events, not only the communication
• Time passes downward

32
State machine diagram

• Shows the states in which the objects can be
• States are shown with rounded rectangles
• Arrows show the transitons between the states
• Alternative ways of transition can exist
  splitting and merging are shown with thick lines

33
State machine diagram
34
Activity diagram

• A process is described
• Many objects participate
• A very good tool to show the responsibilities of
  the objects

35
Activity diagram
36
Activity diagram

• Rounded rectangles denote the tasks to be done
• Rhombuses denote decisions
• Thick lines show where activities take place in
  parallel
• A ractangle with a bended corner is a note
• notes can appear anywhere
• they explain what is necessary concerning an
  artefact linked to the note with a dotted lne

37
Package diagram

• Packages are collections of other entities which
  perform a well specified task together (classes,
  other packages)
• This diagram serves to show complex systems form
  a general perspective
• The impact is laid upon the logical structure

38
Package diagram
39
Component diagram

• The rationale is similar to that for a package
  diagram
• Now, the impact is laid upon the physical
  structure, like files, libraries, executables etc.

40
Component diagram

• Interfaces provided are shown with circles
• Interfaces needed are shown with arcs

41
Composite structure diagram

• For modelling the cooperation of classes,
  interfaces, components engaged in a task
• Similar to the class diagram, but it does not
  show the static structure (like the class diagram
  does), but the execution of a trask, typical ways
  of using the elements of a system, relationships
  between them, which would be difficult to show in
  other diagrams

42
Composite structure diagram - Intro

• In this class diagram a typical way of showing
  the invoice and its parts is shown.
• Lines with full rhombuses denote the composition.
  This means that when the total disappears, the
  parts disappear also. This is different with
  respect to the aggregation, where the parts do
  not disappear when the total does.

Relationship of three classes
Invoice
Header
Data

• We may not wish to form separte classes for the
  header and the data in the invoice when showing
  its inner structure.
• In such a case, the composite structure diagram
  is useful.

43
Composite structure diagram

• The class Invoice is represented by two parts
  now, connected by a connector with multiplicities

Composite structure
Invoice
Header
Data
44
Composite structure diagram

• The diagram can be used together with a use case
  diagram realised by it
• Such a version can be more readable

Subscriptionsystem
Subscribingto a course
Subscription
Course
Student
45
Interaction overview diagram

• This is a linked activity diagram and sequence
  diagram (or other system dynamics diagram) and it
  visualizes the cooperation of interactions
• Similar to the activity diagram, but here there
  are straight-edged rectangles (not rounded) which
  can contain one of these
• An interaction diagram communication, sequence,
  time sequence etc.
• A refgerence to an external interation diagram
  a word ref in the left upper corner denotes this

46
Interaction overview diagram
47
Time sequence diagram

• Where accurate timing is important
• Like in real-time applications

48
Time sequence diagram

• Two notations are available
• time
• task

49
Deployment diagram

• The deployment and software is shown

50
The analysis stage of the UML models

• Two models most important for the analysis are
• Use case model
• use case diagram
• important from the user perspective
• Object model
• class diagram
• object diagram
• Important to analyse the static structure of the
  sysytem
• The dynamical model is used to fill-in the class
  diagram with methods known thanks to the
  execution of the use cases or scenarios related
  to specific use cases
• The diagrams used to this end are
• activity diagrams
• sequence diagrams
• state diagrams
• interaction diagrams

51
Lines and arrows
52
Final remarks

• At present, UML is the most important
  object-oriented notation for specifying,
  designing, visualising and documenting the
  systems
• In practice, not all the diagram types should be
  used, but only those which are really necessary
  to describe the model