12/11/13 Philippe Lalanda 1
Introduction to Software Engineering
Introduction to UML Philippe Lalanda [email protected]
http://membres-liglab.imag.fr/lalanda/
12/11/13 Philippe Lalanda 2
Development activities -‐ reminder
Requirements Design Implem Validation
Needs Constraint stakeholders Use cases …
modules cohesion coupling Architecture …
Programming languages Design patterns Unit tests …
UML
12/11/13 Philippe Lalanda 3
Outline
q UML presentation
q Basic concepts
q Advanced concepts
q Conclusion
12/11/13 Philippe Lalanda 4
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, …
12/11/13 Philippe Lalanda 5
UML OMT
Merise
SA/RT
ERD
SADT
DFD
etc. JSD
Uni@ied Modeling Language – from Bezivin
12/11/13 Philippe Lalanda 6
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
12/11/13 Philippe Lalanda 7
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
12/11/13 Philippe Lalanda 8
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
12/11/13 Philippe Lalanda 9
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
12/11/13 Philippe Lalanda 10
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
12/11/13 Philippe Lalanda 11
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
12/11/13 Philippe Lalanda 12
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)
12/11/13 Philippe Lalanda 13
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"
12/11/13 Philippe Lalanda 14
Client
DoMaintenance Technician
AddBankNotes BankNotesDelivery
ATM
TranferMoney
GetMoney
CheckCount
Use cases – from Favre/Parissis
12/11/13 Philippe Lalanda 15
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
12/11/13 Philippe Lalanda 16
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
12/11/13 Philippe Lalanda 17
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
12/11/13 Philippe Lalanda 18
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
12/11/13 Philippe Lalanda 19
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
12/11/13 Philippe Lalanda 20
ATM Server
Web server PC
<<SSLT>>
<<https>>
<<tcpip>>
Palm
Deployment diagram – from Favre/Parissis
12/11/13 Philippe Lalanda 21
Outline
q UML presentation
q Basic concepts
q Advanced concepts
q Conclusion
12/11/13 Philippe Lalanda 22
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)
12/11/13 Philippe Lalanda 23
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 }
12/11/13 Philippe Lalanda 24
Simpli@ied notations – from Favre/Parissis
Account
number balance : real MaxOverdraft : integer
checkBalance() : integer credit( amount : integer ) debit(amount : 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
12/11/13 Philippe Lalanda 25
Object notation – from Favre/Parissis
PaulAccount : Account
number = 6688 balance = 5000 MaxOverdraft = -‐100
PaulAccount
: account
PaulAccount : Account
Convention : • object names begin with a lower case and are underlined
M0
12/11/13 Philippe Lalanda 26
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
checkBalance() : integer credit( amount : integer ) debit(amount : integer )
PaulAccount : Account
number = 6688 balance = 5000 MaxOverdraft = -‐100 PaulAccount : Account
number = 6688 balance = 3000 MaxOverdraft = -‐100
12/11/13 Philippe Lalanda 27
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
12/11/13 Philippe Lalanda 28
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
12/11/13 Philippe Lalanda 29
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
12/11/13 Philippe Lalanda 30
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
12/11/13 Philippe Lalanda 31
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"
marie : Client" c3 : Compte"
APourCompte>"
APourCompte>"
APourCompte>"
Client" Compte"
APourCompte>"
association class
objects
M1
M0
12/11/13 Philippe Lalanda 32
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
12/11/13 Philippe Lalanda 33
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"
marie : Client" c3 : Account"
HasAccount>"
HasAccount >"
HasAccount >"
holder"
holder"
account"
account"
account"
holder"
paul.account "pierre.account "marie.account"c1.holder"c2.holder"c3.holder"
M0
M1
12/11/13 Philippe Lalanda 34
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"
marie : Client" c3 : Compte"
APourCompte>"
APourCompte>"
APourCompte>"
12/11/13 Philippe Lalanda 35
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"
12/11/13 Philippe Lalanda 36
Client" 1..4" 0..*"holders"
Consortium
Account"number"balance"..."
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
12/11/13 Philippe Lalanda 37
c1 : Account"
c2 : Account"
paul : Client"
pierre : Client"
marie : Client" c3 : Account"
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
12/11/13 Philippe Lalanda 38
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>"
12/11/13 Philippe Lalanda 39
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"
: Client" :" :" : Consortium"
: Consortium"
: Distributeur"
:"
:"
>"
>"
>"
t1 t2 t3
: Compte"
: Compte"
: Client" : Compte"
titulaires"
:"
titulaires"
:"
: Client"
: Banq
ue"
: Banq
ue"
: Client" :" :" : Consortium"
: Consortium"
: Distributeur"
:"
:"
>"
>"
>"
M1
M0
Class diagram vs. object diagram –Favre/Parissis
Client"1..4" 0..*"
holders"
Consortium
Account"number"balance"..."
1..*"
1
0..*"
1..1"
0..*"
1..*"
signing"1"
0..*"BlueCard"
Code"MaxWithdrawal" ATM
1..*"
IsAcceptedBy>"
1..*" Bank"
number"name"
12/11/13 Philippe Lalanda 40
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"
*"
12/11/13 Philippe Lalanda 41
"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
12/11/13 Philippe Lalanda 42
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)
12/11/13 Philippe Lalanda 43
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
12/11/13 Philippe Lalanda 44
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
12/11/13 Philippe Lalanda 45
Outline
q UML presentation
q Basic concepts
q Advanced concepts
q Conclusion
12/11/13 Philippe Lalanda 46
+ # -‐ 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
12/11/13 Philippe Lalanda 47
[/] [ 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
12/11/13 Philippe Lalanda 48
[/] [ 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
12/11/13 Philippe Lalanda 49
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"
12/11/13 Philippe Lalanda 50
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"
12/11/13 Philippe Lalanda 51
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
12/11/13 Philippe Lalanda 52
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" *"
12/11/13 Philippe Lalanda 53
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" *"*"
12/11/13 Philippe Lalanda 54
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"
12/11/13 Philippe Lalanda 55
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"
12/11/13 Philippe Lalanda 56
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
Associative classes –Favre/Parissis
12/11/13 Philippe Lalanda 57
p1 "Employs>"
s1 "Employs>"
This is still valid for an associative class
p1 " s1 "
: Job"
salary = 1500 "
: Job"
salary = 700 "
Associative classes –Favre/Parissis
Reminder: No more than one link of a given type between two objects
12/11/13 Philippe Lalanda 58
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 "
Associative classes –Favre/Parissis
12/11/13 Philippe Lalanda 59
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"
12/11/13 Philippe Lalanda 60
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
12/11/13 Philippe Lalanda 61
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
12/11/13 Philippe Lalanda 62
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
12/11/13 Philippe Lalanda 63
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)
12/11/13 Philippe Lalanda 64
Outline
q UML presentation
q Basic concepts
q Advanced concepts
q Conclusion
12/11/13 Philippe Lalanda 65
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 …
12/11/13 Philippe Lalanda 66
Reminder
q Requirement document
System models
Natural Language
Use Cases Context Diag. Fonct. Diag Object Diag
q Not enough !!!
12/11/13 Philippe Lalanda 67
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 …
12/11/13 Philippe Lalanda 68
Conclusion
Model based development is immature. It progresses …