Introduction to UML - imag.frlig-membres.imag.fr/lalanda/files/se/8.UML.pdf · Introduction to UML Philippe Lalanda [email protected] 12/11/13 Philippe Lalanda 2 ... UML OMT

12/11/13 Philippe Lalanda 1

Introduction to Software Engineering

Introduction to UML Philippe Lalanda [email protected]

http://membres-liglab.imag.fr/lalanda/


Development activities -‐ reminder

Requirements Design Implem Validation

Needs Constraint stakeholders Use cases …

modules cohesion coupling Architecture …

Programming languages Design patterns Unit tests …

UML


Outline

q  UML presentation

q  Basic concepts

q  Advanced concepts

q  Conclusion


Uni@ied Modeling Language– from Favre/Parissis

q  UML is a notation for OO analysis and design q  It is complemented by methods

q  The Rational Uni@ied Process q  The Uni@ied Software Development Process

q  … and tools q  Rational Rose, Objecteering, Together J, ArgoUML, Poseidon, …


UML OMT

Merise

SA/RT

ERD

SADT

DFD

etc. JSD

Uni@ied Modeling Language – from Bezivin


Vocabulary uni@ication – from Bezivin

Booch

Coad

Jacobson

Odell

Rumbaugh

Shlaer/Mellor

UML

Class

Class/Object

Object

Object/Type

Class

Object

Class

Uses

Instance connection

Association Acquaintance

Relation

Association

Relation

Association

Inherits

Gen/Spec

Inherits

Sub

Generalization

Sub

Generalization

Contains

Whole/Part

ConsistsIn

Composition

Aggregation

N/D

Aggregation


A B 1

A B +

A B ?

A B *

A B 1

A B 1,m

A B 0,1

A B 0,m

A B A B 1+

A B A B

A B 1

A B 1..*

A B 0..1

A B *

UML

Rumbaugh

Coad

Booch.1

Notation uni@ication – from Bezivin


A major stake – from Favre/Parissis

q  Standardization was needed to stabilize and disseminate OO practices in the industry

q  A dif@icult task q  Many industrial lobbies and pressure groups q  Very important stakes q  Various interests and motivations

q  Tool vendors, consultants, industrial users, ...

q  UML targets consensuality, not innovation


Consensus – from Favre/Parissis

q  A minima q  Intersection q  Leads to simplicity (or impoverishment) q  Good for users, not providers q  Requires maturity

q  A maxima q  Union q  Leads to complexity and instability q  Hard for users q  Allows providers differentiation q  Easy solution when lack of maturity

q  UML relies on a maxima consensus


UML impact – from Favre/Parissis

q  De facto standard in the industry q  Adopted by tool vendors q  Integration in industrial development processes

q  Used in production environment q  Although coherence maintenance is rarely ensured

q  Lots of jobs, required skill q  UML has won the OO modeling battle


UML tools – from Favre/Parissis

q  Hundreds of UML tools q  Modeling tools q  Generation of code, documents, tests, … q  Model transformation

q  An important effort has been made to turn to UML q  Hard (and costly) to go back


UML notation – from Favre/Parissis

q  Many notations, actually q  Graphical and textual

q  Notations are q  precise (in a context) q  Standard (not always respected) q  General (not always appropriate) q  Extension (through low level mechanisms)


UML notation – from Favre/Parissis

q  Use case diagram q  Class diagram q  Object diagram q  Sequence diagram q  Collaboration diagram q  State diagram q  Activity diagram q  Component diagram q  Deployment diagram q  Constraint language q  Action language, …

Client"

1..4" 0..*"

titulaires"

Consortium

Compte"

numéro"solde"..."

1..*"

0..1"

1"

Banque"

numéro"nom"

Distributeur

0..*"

1"

0..*"

1..*"

signataire"

1"

0..*"

CarteBleue"

Code"retraitMax"

1..*"

EstAcceptéPar>"

virementPossible"

0..*"

c1 : Compte"

c2 : Compte"

paul : Client"

pierre : Client"

marie : Client" c3 : Compte"

titulaires"

titulaires"

: CarteBleue"

titulaires"

titulaires"

signataire"

: CarteBleue"

sophie : Client"

: Banque"

: Banque"

fred : Client" c4 : Compte"titulaires"

: Banque"

signataire"

: Consortium"

: Consortium"

: Distributeur"

: CarteBleue"

signataire"

: Distributeur"

EstAcceptéPar>"

EstAcceptéPar>"

EstAcceptéPar>"

le compte de P."le distrib." la banque"paul"

retirer 500 fr"

débiter 500 fr"

la carte de P."

lire n° compte"

la reserve"

retirer de 500 fr sur le compte n"

sortir 5 billets de 100 fr"

prendre la carte"

confirmer"

le compte de paul"

le distributeur" la banque"

la carte de P."

la reserve de billets"

paul"

4 : débiter(500)"1 : retirer 500 fr"

2 : lire n° de compte"

5 : confirmer"

6 : sortir 5 billet de 100 fr"

3 : retirer 500 fr sur compte n"

En attente En attente du code

En vérification

En attente du montant

carte insérée"

code frappé"mauvais code"

En distribution

code bon"

En attente retrait carte

carte retirée"

montant correct"

montant incorrect"

billets retirés"


Client

DoMaintenance Technician

AddBankNotes BankNotesDelivery

ATM

TranferMoney

GetMoney

CheckCount

Use cases – from Favre/Parissis


Client" 1..4" 0..*"titulaires"

Consortium

Account"number"balance"..."

1..*"

0..1"

1

Bank"numéro"nom"

ATM 0..*"

1"

0..*"

1..*"

signataire"1"

0..*" CreditCard"

Code"MaxWIthdrawal"

1..*"AcceptéPar>"

Class diagram – from Favre/Parissis


c1 : Account"

c2 : Account"

paul : Client"

pierre : Client"

marie : Client" c3 : Account"

holder"

holder"

: BlueCard"

holder"

holder"

signing"

: BlueCard"

sophie : Client"

: Bank"

: Bank"

fred : Client" c4 : Account"holder"

: Bank"

signing"

: Consortium"

: Consortium"

: ATM"

: BlueCard"signing"

: ATM"

AcceptedBy >"

AcceptedBy >"

AcceptedBy>"

Object diagram – from Favre/Parissis


Pierre’s account"The ATM" The bank"paul"

withdraw 500"

debit 500"

Pierre’s card"

Read account n°"

The notes"

withdraw 500 on account n"

deliver 5 notes of 100"Release card"

confirm"

Sequence diagram – from Favre/Parissis


Paul’s account"

The ATM" The bank"

Pierre’s card"

The notes"

paul"

4 : debit(500)"1 : withdraw 500"

2 : Read account n°""

5 : confirm"

6 : deliver 5 notes of 100"

3 : withdraw 500 on account n"

Collaboration diagram – from Favre/Parissis


Pending Waiting for code

Verification

Waiting for amount

Inserted card"

code entered"wrong code"

Distribution

right code"

Waiting card release

Card released"

Valid amount"

Incorrect amount"

Notes delivered"

State diagram – from Favre/Parissis


ATM Server

Web server PC

<<SSLT>>

<<https>>

<<tcpip>>

Palm

Deployment diagram – from Favre/Parissis


Outline


q  Basic concepts


q  Conclusion


UML impact – from Favre/Parissis

q  UML is based on OO principles q  Object and class q  Links and association q  Inheritance q  Constraint

q  UML de@ines notations to build diagrams manipulating these concepts q  Class diagrams (model level) q  Object diagrams (instance level)


Account

Class notation – from Favre/Parissis

number : integer balance : real MaxOverdraft : integer

checkBalance() : integer credit( amount : integer ) debit(amount : integer )

Class name

Attributes name type

Operations name parameter Result type

Constraint { inv: balance > MaxOverdraft }


Simpli@ied notations – from Favre/Parissis

Account

number balance : real MaxOverdraft : integer


Account number balance ... credit() debit() ...

Account number balance ...

Account credit() debit() ...

Account

Style note: •  class names begin with a upper case •  attributes and method names begin with a lower case

Account

M1


Object notation – from Favre/Parissis

PaulAccount : Account

number = 6688 balance = 5000 MaxOverdraft = -‐100

PaulAccount

: account


Convention : •  object names begin with a lower case and are underlined

M0


Class vs. Object – from Favre/Parissis

A class speci@ies the structure and the behavior of a set of objects (of the same nature)

Class diagram   A class structure is constant over time

Object diagram

  Objects can be created and deleted at run time

  Attributes values can be changed

M0 M1

Account

number balance : real MaxOverdraft : integer



number = 6688 balance = 5000 MaxOverdraft = -‐100 PaulAccount : Account

number = 6688 balance = 3000 MaxOverdraft = -‐100


Links – from Favre/Parissis

c1 : Account

c2 : Account

paul : Client

pierre : Client

marie : Client c3 : Account

HasAccount

HasAccount

HasAccount

A link speci@ies a connection between two objects

Style note: •  links names are verbal forms and begin with an uppercase •  arrow indicates how to read


Constraint about links – from Favre/Parissis

q  No more than one link of a given type between two objects

marie : Person joseph : Person

IsMarriedTo

IsMarriedTo

josé : Person

IsChildOf

madeleine : Person IsChildOf

IsLookedAfterBy

OK


Role – from Favre/Parissis

q  Linked objects play a different role

c1 : Account pierre : Client HasAccount

holder account

•  pierre owns account c1 •  c1 plays the account role for pierre •  pierre plays the holder role for c1

Style note: •  a role is expressed as a name •  by default, the role is the name of the class


Associations – from Favre/Parissis

c1 : Account

c2 : Account

paul : Client

pierre : Client

marie : Client c3 : Account

HasAccount>

HasAccount >

HasAccount >

Client Compte HasAccount

An association describes a set of links having a same « semantic »

account holder

Object diagram (exemple)

Class diagram (model)

M0 M1


Association vs. links – from Favre/Parissis

q  A link relates two objects q  An association relates two classes

q  A link is an association instance q  An association describes a set of links

q  Links can be created and deleted at runtime, not associations

q  Note: the term “relation” is not part of UML

c1 : Compte"

c2 : Compte"

paul : Client"

pierre : Client"


APourCompte>"

APourCompte>"

APourCompte>"

Client" Compte"

APourCompte>"

association class

objects

M1

M0


Associations naming – from Favre/Parissis

Account" Bank"

Account" Bank"IsManagedBy"

managingBank"managedAccounts"

Account" Bank"account"Gérés"

Account" Bank"managingBank"

Account" Bank"Manages"

There are several ways to name an association, but it has

to remain coherent


Roles and navigation – from Favre/Parissis

Client" Account"HasAccount"

holder" account"

= {c1}"= {c2,c3}"= { }"= paul"= pierre"= pierre"

Name roles in priority : careful name selection ! (code generation)

c1 : Account"

c2 : Account"

paul : Client"

pierre : Client"


HasAccount>"

HasAccount >"

HasAccount >"

holder"

holder"

account"

account"

account"

holder"

paul.account "pierre.account "marie.account"c1.holder"c2.holder"c3.holder"

M0

M1


Cardinality – from Favre/Parissis

q  Specify how many objects can be linked to a source object q  Max and min cardinalities (Cmin, Cmax) q  Use of constants

Client" Account"1" HasAccount" 0..*"

holder" account"

« A client has 0 or several accounts » « An account has always one and only one client »

c1 : Compte"

c2 : Compte"

paul : Client"

pierre : Client"


APourCompte>"

APourCompte>"

APourCompte>"


Constraints between associations –Favre/Parissis

Client"Compte"

number"balance"..."

1 0..*"PrincipalHolder"

co-holders"0..*" 0..*"

/holders"1..*" 0..*"

(1) A client cannot be both principal holder and co-holder of a same account"(2) Holders of an account include the principal holder and, possibly, co-holders"

Cardinality are not enough to express all the constraints à additional constraints are described in Natural Language (or OCL)

Account"


Client" 1..4" 0..*"holders"

Consortium


1..*"

1

0..*"

1..1"

0..*"

1..*"

signing"1"

0..*" BlueCard"

Code"MaxWithdrawal"

ATM 1..*"

IsAcceptedBy>"

1..*" Bank"number"name"

Example of Class diagram – from Favre/Parissis


c1 : Account"

c2 : Account"

paul : Client"

pierre : Client"


holders"

holders"

: BlueCard"

holders"

holders"

signing"

: BlueCard"

sophie : Client"

: Bank"

: Bank"

fred : Client" c4 : Account"holders"

: Bank"

signing"

: Consortium"

: Consortium"

: ATM"

: BlueCard"signing"

: ATM"

IsAcceptedBy >"

IsAcceptedBy>"

IsAcceptedBy >"

M0

Example of object diagram – from Favre/Parissis


Class diagram / object diagram –Favre/Parissis

q  A class diagram q  De@ines all the possible states q  Constraints must be always met

q  An object diagram q  De@ines a possible state at a given time q  Must be conformed to the class diagram

q  Object diagrams can be used to q  Exemplify a class diagram (explanation) q  Validate a class diagram (“test” it)

Client"

1..4" 0..*

titulaires"

Consortium

Compte"

numéro"solde"..."

*

1"

0..*"

1"

0..*

1..*

signataire"1"

0..*

CarteBleue"

Code"retraitMax"

Distributeur

1..*"

EstAcceptéPar>"

1..*

Banque"

numéro"nom"

c1 : Compt

e"

c2 : Compt

e"

paul : Client"

pierre :

Client"

marie :

Client"

c3 : Compt

e"

titulaires"

titulaires"

: CarteB

leue"

titulaires"

titulaires"

signataire"

: CarteBleue"

sophie :

Client"

: Banque"

: Banque"

signataire"

: Consortium"

: Distributeur"

EstAcceptéPar>"

EstAcceptéPar>"

c1 : Compt

e"

c2 : Compt

e"

paul : Client"

pierre :

Client"

marie :

Client"

c3 : Compt

e"

titulaires"

titulaires"

: CarteB

leue"

titulaires"

titulaires"

signataire"

: CarteBleue"

sophie :

Client"

: Banque"

: Banque"

signataire"

: Consortium"

: Distributeur"

EstAcceptéPar>"

EstAcceptéPar>"


titulaires"

titulaires"

: Banq

ue"

signataire"

: Distributeur"

: Compte"

: Compte": Client"

: Client" : Compte"

titulaires"

:"

titulaires"

:"

: Client"

: Banq

ue"

: Banq

ue"

: Client" :" :" : Consortium"

: Consortium"

: Distributeur"

:"

:"

>"

>"

>"

... : Compte"

: Compte": Client"

: Client" : Compte"

titulaires"

:"

titulaires"

:"

: Client"

: Banq

ue"

: Banq

ue"


: Consortium"

: Distributeur"

:"

:"

>"

>"

>"

t1 t2 t3

: Compte"

: Compte"

: Client" : Compte"

titulaires"

:"

titulaires"

:"

: Client"

: Banq

ue"

: Banq

ue"


: Consortium"

: Distributeur"

:"

:"

>"

>"

>"

M1

M0

Class diagram vs. object diagram –Favre/Parissis

Client"1..4" 0..*"

holders"

Consortium


1..*"

1

0..*"

1..1"

0..*"

1..*"

signing"1"

0..*"BlueCard"

Code"MaxWithdrawal" ATM

1..*"

IsAcceptedBy>"

1..*" Bank"

number"name"


Navigation

If the association is unidirectional the navigation is only one way

A priori useful only during design or implementation If in doubt, don’t put any direction !!!

Client" Account"1"holder"

*"


"Super class"

« Sub class"

Person"

Woman"Man"

Account"

BlueAccount"

General case

Specific case

Two interpretations (in UML) : •  inheritance relation •  sub-type relation

Generalization / Specialization –Favre/Parissis

q  A class can be the generalisation of other classes q  These classes are specialisation of this class


Account"

balance"

credit()"debit()"

BlueAccount"

InterestRates"

AddInterests ()"

Bank"*"BlueAccount"

balance"InterestRate""credit()"debit()"AddInterests()"

*"

{inv: balance > -5000 and InterestRate < 100}"

Bank"{inv: balance > -5000}"

{inv: InterestRate < 100}"

Inheritance –Favre/Parissis

q  Sub-‐classes inherit properties of super classes (attributes, methods, associations, constraints)


Account"balance"credit()"debit()"

BlueAccount"

credit()"debit()"AddInterests ()"

PEL"

credit()"debit()"AddInterests()"

PEC"

debit()"

PET"

debit()"

An opération can be redefined in sub classes

Allows the definition of specific methods to realize a same operation

Inheritance and rede@inition –Favre/Parissis


q  Class q  attribute q  method

q  Association q  role q  cardinality

o1

o2

o1

o2

o3

o4

o5

o1

o2

o3

  Object   Link   Inclusion

  Inheritance

M1

M0

Synthesis about base concepts –Favre/Parissis


Outline


q  Basic concepts


q  Conclusion


+ # -‐ Visibility –Favre/Parissis

q  Restrain the access to model elements q  Control and avoid dependencies between classes

and packages q  + public visible q  # protected visible in class / sub-‐classes q  -‐ private visible in class q  ~ package visible in package

q  Useful at design and implementation times q  Meaningless in an abstract model q  To be used only when necessary q  Semantics depends on the programming

language


[/] [ visibility ] name [ : type ] [card order] [ = initial-‐value ] [ { props... } ]

age"+age"/age"- balance : Integer = 0"# age : Integer [0..1]"# numsecu : Integer {frozen}"# keyWords : String [*] {addOnly}"nbPerson : Integer""

  Detail level should be adapted to the level of abstraction

Attribute declaration – Favre/Parissis


[/] [ visibility ] name [ ( params ) ] [ : type ] [ { props... } ] params := [ in | out| inout ] nom [ : type] [ =defaut ]

[{ props... } ] /getAge()"+ getAge() : Integer"- updateAge( in date : Date ) : Boolean"# getName() : String [0..1]"+getAge() : Integer {isQuery}"+addProject() : { concurrency = sequential }"+addProject() : { concurrency = concurrent }"+main( in args : String [*] {ordered} )"

Operation declaration – Favre/Parissis

  Detail level should be adapted to the level of abstraction


Composition –Favre/Parissis

q  Intuitively: component/composite relationship q  A speci@ic association providing constraints related to

the notion de component

Car" Wheel"4" Tire"

Rim"

1"

1"


Composition –Favre/Parissis

q  Constraints q  A component can only be in a single composite q  A component cannot exist without its composite q  When a composite is destroyed, its components are

destroyed too

q  Really depends on the situation (system) to be modeled q  Car dealer vs. reseller parts

Car" Wheel"4" Tire"

Rim"

1"

1"


Composition – other example

51

Document" Chapter" Section"

Figure"

1..*" 1..*"1"

0..*"

1..*"

: document"

: chapter"

: chapter"

: section"

: section"

: figure"

: figure"

: section"

Constraint : the components make up a tree


Composition – other notations

52

Car"

steeringWheel :"SteeringWheel"

wheels : Wheel [4] "seats : Seat [*] "

Car"

SteeringWheel"

Wheel"

1"

4"

Seat"*"

seats" Car"

SteeringWheel"1"

Wheel" 4"

seats : Seat" *"


Aggregation –Favre/Parissis

q  An association q  With constraints characterizing the notion of

membership

q  Notes q  Sharing is authorized q  To use with cautious – suppressed in UML2.0

Point"x"y"

Figure" *"*"


Prede@ined association constraints –Favre/Parissis q  For instance

q  { ordered } : collection elements are ordered q  { nonUnique } : possible repetition (UML2.0) q  { frozen } : @ixed at creation, cannot be changed q  { addOnly } : no element can be deleted

q  More constraints can be de@ined

Account"statement"

Operation Line"*"

{ordered,addOnly}"

lines"


Associative classes –Favre/Parissis

q  To associate attributes/methods to associations

q  The name of the class is the name of the association

Person" Company"employees"

*" 0..2"

Job"salary"rise()"

companies"


jean"

marie"

salaire = 1500 "

xerox"

employé"

e1"

ujf"employé"

e2"

salary = 700 "

employé"

e3"

salary = 1000"

Salary does not relate •  to a person, •  to a company,

But to a job (<person, company> couple).

Person" Company"employees"

*" 0..2"

Job"salary"rise()"

companies"

M1

M0



p1 "Employs>"

s1 "Employs>"

This is still valid for an associative class

p1 " s1 "

: Job"

salary = 1500 "

: Job"

salary = 700 "


Reminder: No more than one link of a given type between two objects


Job"salary"

Person" Company"employee"

1" 1"

0..2" company"*"

Here, a person may have two jobs in the same company

e2 "p1 " s1 "

e1 "

Person" Company"employee"

*" 0..2"Job"

salary"

companies"

Here, a person may have two jobs, but not in the same company

p1 " s1 "

e1 "



Quali@ied associations

Directory" File"

A qualifier is an attribute or a set of attributes whose value is used to determine what are the instances associated with a given instance via an association.

The attributes of the qualifier are attributes of the association. The qualification reduces the multiplicity, usually to 1 (notion of key)

name"1"

contains"

Directory"File"

1..*"1"contains"

name"


Synthesis on association

<AssociationX"

Cardinality

ClasseA ClasseB"roleA" 0..*"

attributeZ"

{frozen}"

Name of role

direction of reading

AssociationX"

Constraint

Navigation

Associative class

Composition

(or aggregation )

Name of association

x : string


An abstract class •  cannot be instantiated •  allows the definition of an abstract behavior •  can contain abstract methods

An abstract method •  must be defined in a sub-class •  belongs to an abstract class

Figure"

surface()!move()"

Circle"

surface()"

Polygone!

surface()"

Square"

surface()"

Figure!{abstract}"

surface() {abstract}"move()"

Figure!

surface() move()"

Equivalente notions

Triangle"

surface()"

Abstract classes and methods –Favre/Parissis


A class can inherit from several super classes

Not allowed in some languages (for instance Java et C#)

Heating" Electrical device "

Electrical heating "Stove"

Device"

MicroWave"

Device"

Electrical heating"

Heating"Electrical

device"Stove"

Micro wave"

M0 M1

Multiple inheritance –Favre/Parissis


UML inheritance – from Favre/Parissis

q  Default hypothesis q  A class can inherit from several super classes q  An object is an instance of a single class q  An object cannot change its class (from which it has been created)


Outline


q  Basic concepts


q  Conclusion


Conclusion – from Favre/Parissis

q  UML is standard, popular but complex q  UML can be used during analysis and design q  Several extensions have been proposed

q  Specialization q  UML is here to last …


Reminder

q  Requirement document

System models

Natural Language

Use Cases Context Diag. Fonct. Diag Object Diag

q  Not enough !!!


Conclusion

q  UML is standard, popular but complex q  UML can be used during analysis and design q  Several extensions have been proposed

q  Specialization q  UML is here to last …


Conclusion

Model based development is immature. It progresses …

Documents

Introduction to UML - imag.frlig-membres.imag.fr/lalanda/files/se/8.UML.pdf · Introduction to UML Philippe Lalanda [email protected] 12/11/13 Philippe Lalanda 2 ... UML OMT