introduction to uml, the introduction: modeling and oo...
TRANSCRIPT
© 2004 Jean-Paul Rigault 13/10/2014 09:49 1
Introduction to UML, the
Unified Modeling Language
Jean-Paul Rigault School of Computing (ESSI)
University of Nice Sophia Antipolis
Email: [email protected]
© 2004 Jean-Paul Rigault 13/10/2014 09:49 2
Outline
! Introduction: modeling and OO modeling
! Application modeling with Use Cases
! Class and object modeling
! State modeling
© 2004 Jean-Paul Rigault 13/10/2014 09:49 3
Introduction to UML
Introduction: Modeling and
Object-Oriented Modeling
© 2004 Jean-Paul Rigault 13/10/2014 09:49 4
Introduction
! What is modeling?
! What is object-oriented modeling?
! What is UML?
! Technical activities in OO modeling
© 2004 Jean-Paul Rigault 13/10/2014 09:49 5
What is Modeling?
! Modeling is customary in
engineering disciplines
! A model is a simplification
of reality
! Handling the real world complexity
! The four aims of modelling
! Visualize the system ! Specify its structure and
behavior ! Provide a template to help us
build the system ! Document decisions made
Examples of models
! Textual description ! Catalogue, Data book… ! Blueprint ! Scale model ! Formal descriptions
! Equations ! Finite state machines ! Set theoretic descriptions…
! etc.
© 2004 Jean-Paul Rigault 13/10/2014 09:49 6
What is Modeling?
Principles of Modeling
! The choice of a way of
modelling influences
! how a problem is tackled
! how a solution is elaborated
! No single model is
sufficient
! Different levels of abstraction (refinement)
! Different points of view
! Example: models of a
house
! Different levels of refinement
! 3D view
! rough floor plan
! floor plan with room dimensions
! Different points of view
! architect�’s view
! mason�’s view
! plumber�’s view
! electrician�’s view
© 2004 Jean-Paul Rigault 13/10/2014 09:49 7
What is Object-Oriented Modeling?
Technical activities in OO modeling
Business modeling
Object modeling
Analysis and Design
Code and
unit testing
Application modeling (Product definition
Requirement Analysis) Integration,
validation,
maintenance,
management,
etc.
Domain analysis
© 2004 Jean-Paul Rigault 13/10/2014 09:50 8
What is Object-Oriented Modeling?
Vehicle
Car Van Aircraft
Boat
Basic Concepts
Abstraction
Test Verif Valid
Exec Simulation
Real World
Vehicle
Plane Boat Car
Abstraction
Model
Realization Code
Domain
analysis Modeling
© 2004 Jean-Paul Rigault 13/10/2014 09:50 9
Overview of UML
A Brief History
Many OOAD methods (> 50)
Coad-Yourdon
Shlaer-Mellor
Fusion
etc.
1991 1992 1993 1994 1995 1996 1997 1998 … 2004
Booch (Rose)
Good for design and construction
Rumbaugh (OMT)
Good for analysis and data-intensive systems
Jacobson (OOSE)
Good for the capture of requirements
U M L
0.8 U M L
0.9
Rational
U M L
1.0
U M L
1.1
OMG request
UML consortium
U M L
1.2
U M L
1.3
U M L
2.0
OMG
OMG vote
© 2004 Jean-Paul Rigault 13/10/2014 09:50 10
Overview of UML
What is UML and what is it for?
UML is a language for
! Visualizing
! Specifying
! Constructing
! Documenting
the artifacts of a software-intensive system
Syntax, Semantics (verification) Graphics Architecture and behavior Allow code generation
Textual and graphic descriptions
© 2004 Jean-Paul Rigault 13/10/2014 09:50 11
Overview of UML
What is UML and what is it for?
! Software intensive systems…
! Enterprise information systems; Banking and financial services ! Telecommunications ! Transportation; Defense; Aerospace ! Medical electronics ! Scientific applications ! Distributed Web-based services ! etc.
! But also non-software systems
! Workflow ! Patient healthcare systems ! Hardware design…
© 2004 Jean-Paul Rigault 13/10/2014 09:50 12
Overview of UML
What is a UML Model?
! A Use Case view
! Functional requirements
! Several object views
! Different concerns (architecture, behaviour…)
! Different levels of description (analysis, design, implementation…)
State
Diagrams Use Case
Diagrams Use Case
Diagrams Use Case
Diagrams
Scenario
Diagrams Scenario
Diagrams Collaboration
Diagrams
State
Diagrams State
Diagrams Component
Diagrams
Component
Diagrams Component
Diagrams Deployment
Diagrams
State
Diagrams State
Diagrams Object
Diagrams
Scenario
Diagrams Scenario
Diagrams Statechart
Diagrams
Use Case
Diagrams Use Case
Diagrams Sequence
Diagrams
State
Diagrams Class
Diagrams
Activity
Diagrams
Model
Elements
© 2004 Jean-Paul Rigault 13/10/2014 09:50 13
Overview of UML
UML and Software Methodologies
! The UML is methodology independent
! However it is better suited to a development
process that is
! Use case driven
! Architecture centric ! Iterative and incremental
© 2004 Jean-Paul Rigault 13/10/2014 09:50 14
Technical activities in OO modeling
UML Views for Technical Activities
Business modeling
USE CASES, ACTIVITY
CLASSES Object modeling
CLASSES SEQUENCES STATES
Analysis and Design
CLASSES SEQUENCES STATES
Code and
unit testing
Application modeling
USE CASES, ACTIVITY Integration,
validation,
maintenance,
management,
etc.
© 2004 Jean-Paul Rigault 13/10/2014 09:50 15
Introduction to UML
Application Modeling
(Product Definition/Requirement Analysis)
with Use Cases
© 2004 Jean-Paul Rigault 13/10/2014 09:50 16
Modeling Requirements in UML
! Functional requirements
! Modeled as Use Cases
! Non-functional requirements
! Some are specific to one use case
! Some relate to technical issues addressed by implementation diagrams and models
! Other in some supplementary documents, out of the UML scope…
© 2004 Jean-Paul Rigault 13/10/2014 09:50 17
The Use Case Approach
What is a Use Case?
! Set of sequences of actions that a system
performs and that yields an observable
result
! A set of related services provided by the
system, together with scenarios of use ! Examples
! Place an order, Subscribe to a service
! Land an aircraft, Pilot a car…
© 2004 Jean-Paul Rigault 13/10/2014 09:50 18
The Use Case Approach
What is an Actor? (1)
! Actors are anything which interface with the
system
! People, other systems, hardware, software, networks… ! They are roles, not necessarily full-fledged objects
! Actors are usually named by nouns corresponding to roles
! Actors participate or are interested in the result of Use Cases
! Actors are not part of the system
! They are just at the boundary; They won’t produce code!
© 2004 Jean-Paul Rigault 13/10/2014 09:50 19
The Use Case Approach
What is an Actor? (2)
! Several sorts of Actors
! Humans, systems…; Primary and secondary
! Primary actor
! Triggers actions in the system
! At least one per use case
! Secondary actors
! Support the activity, do not initiate it
! Stakeholders
! Interested in the actions, but not necessarily participating
© 2004 Jean-Paul Rigault 13/10/2014 09:50 20
The Use Case Approach
A Simplified ATM (1)
! The ATM is associated with only one
bank
! It gives access to all the accounts the customer owns in the bank
! Several types of transactions can be
chained in a single session
! Withdrawal, deposit, transfer between the customer’s own accounts, consulting an account
! The customer may obtain a printed receipt for each transaction
© 2004 Jean-Paul Rigault 13/10/2014 09:50 21
The Use Case Approach
A Simplified ATM (2)
! The card contains
! an ID number ! an expiration date ! a secret code
! The card must be verified by the ATM
! The customer cannot make more than 3 attempts to enter the correct code, otherwise the card is swallowed
! Interface
! Keyboard and screen, with menus ! The customer may cancel the current
transaction at meaningful points © 2004 Jean-Paul Rigault 13/10/2014 09:50 22
The Use Case Approach
A Simplified ATM (3)
! Minimal connection with the bank
! When a session is opened, a connection makes it possible to known all the accounts the customer owns
! Every night, the information about the current day transactions are transferred to the bank
! Manual interventions: an employee
! empties the machine and/or fills it with bank notes
! supplies consumables and does any maintenance that may be needed
© 2004 Jean-Paul Rigault 13/10/2014 09:50 23
The Use Case Approach
Modeling Use Cases
! Informal descriptions (non UML)
! Describing scenarios
! Just prose
! More formal description (UML models)
! Use Case diagrams ! Activity diagrams
! (Sequence and Collaboration diagrams)
© 2004 Jean-Paul Rigault 13/10/2014 09:50 24
Informal UC Description
Actors
! Identifying actors
! Who uses, installs, starts up, shuts down, maintains the system?
! Who provides (gets) information to (from) the system?
! What other systems use the system?
! Who has non-functional needs with respect to the system?
! ATM example
! Customer
! Bank (computer system)
! Technician
! What about the card?
© 2004 Jean-Paul Rigault 13/10/2014 09:50 25
Informal UC Description
Top Level Use Cases
! A full set of related system
functionalities
! Identifying use cases
! Actors expectations ! Creating, consulting,
updating or deleting system information?
! Notification of an actor state change or of an external event
! Start to end
! a complete use of the system
! ATM example
! Handle Session: Run a customer complete session from start (card insertion) to end (card retrievial or swallowing)
! Transfer Daily: Nightly retrieval of information by the Bank computer system
! Maintain: Run a maintenance session
© 2004 Jean-Paul Rigault 13/10/2014 09:50 26
Informal UC Description
Use Cases and Scenarios (1)
! Use cases classify the ways of using the system
! To each use case correspond many possible usage
scenarios
! A scenario is a sequence of interaction between the system and one or several actors
! It expresses a particular path to traverse its use case
! Thus scenarios
! are instances of use cases
! specify use cases
© 2004 Jean-Paul Rigault 13/10/2014 09:50 27
Informal UC Description
Use Cases and Scenarios (2)
! Each use case has generally
! a primary scenario: typical usage
! several secondary (more exceptional) scenarios
! A scenario involves one or several actors
! Usually one primary actor, and possibly supporting ones ! It may have an initiator actor (often, the primary one)
! A scenario may be of interest to stakeholders, which are not always participating actors
! Example: regulation policy, board of directors, share owners…
© 2004 Jean-Paul Rigault 13/10/2014 09:50 28
Informal UC Description
Alistair Cockburn’s Style (1)
! Describe a full Use Case
! with a primary (typical) scenario ! and possible variants
! Involve
! a primary actor, a possible initiator actor (may be the primary) and possible supporting actors
! the interest of some stakeholders ! Several possible patterns
! Brief (a simple sentence/paragraph) ! Informal text, yet obeying simple writing rules… ! Highly structured text (fully-dressed)
© 2004 Jean-Paul Rigault 13/10/2014 09:50 29
Informal UC Description
A. Cockburn’s Style: Brief
Handle Session Use Case
The Customer inserts the card into the ATM. After verification and authentication, the customer may perform one or several transactions. When done, the customer gets the card back and leaves.
© 2004 Jean-Paul Rigault 13/10/2014 09:50 30
Informal UC Description
A. Cockburn’s Style: Informal
Use Case: Handle Session Primary actor (and initiator): Customer Supporting actor: Bank
The customer inserts the card into the ATM. The ATM verifies the card and authenticates the customer. The ATM retrieves customer information from the Bank. The customer selects a transaction among withdrawal, deposit, transfer, and consult. After completion of the transaction, the Customer may decide to select an other transaction or to quit (in which case, he/she gets the card back). If the card is invalid or the customer fails to authenticate, the card is swallowed.
© 2004 Jean-Paul Rigault 13/10/2014 09:50 31
Informal UC Description
A. Cockburn’s Style: Fully-dressed (1)
! For each use case
! Actors and stakeholders: as for informal ! Pre- and post-conditions
! Pre-condition:: must be true before starting (intiating) the UC
! Post-condition: guaranteed to be true after UC completion ! One primary scenario (composed of 2-8/10 steps) ! Several variants associated with the (primary) scenario
steps ! Other information: Exceptions and errors (specific
variants), Data needed, Constraints…
© 2004 Jean-Paul Rigault 13/10/2014 09:50 32
Informal UC Description
A. Cockburn’s Style: Fully-dressed (2)
! Primary scenario steps and variants are numbered
! 1,2,3… in primary ! 2a for first variant, expressed in informal style, of step 2 ! 2b1,2b2,2b3… for variant b , expressed in fully-dressed,
form, of step 2
! For each step
! Express a functionality in a simple sentence ! The subject of the sentence is one of the actors or the
system ! Use positive verbs in active form
© 2004 Jean-Paul Rigault 13/10/2014 09:50 33
Informal UC Description
A. Cockburn’s Style: Fully-dressed (3)
Use Case: Handle Session Primary actor (initiator): Customer Supporting actor: Bank Precondition: ATM is free Primary Scenario
1. Customer inserts the card into ATM. 2. ATM asserts card validity. 3. Customer authenticates with ATM. 4. ATM gets Customer information from
Bank. 5. Customer performs a transaction. 6. Customer quits. 7. ATM ejects card , Customer takes it Postcondition: ATM is free and all
transactions have been recorded
© 2004 Jean-Paul Rigault 13/10/2014 09:50 34
Informal UC Description
A. Cockburn’s Style: Fully-dressed (4)
Use Case: Handle Session Primary actor (initiator): Customer Supporting actor: Bank Precondition: ATM is free Primary Scenario
1. Customer inserts the card into ATM. 2. ATM asserts card validity. 3. Customer authenticates with ATM. 4. ATM gets Customer information from
Bank. 5. Customer performs a transaction. 6. Customer quits. 7. ATM ejects card , Customer takes it Postcondition: ATM is free and all
transactions have been recorded
Variants
2a Card is invalid: ATM swallows it; this ends the session.
3a Customer fails to authenticate: ATM swallows card; this ends the session.
4a The connection with Bank is impossible or interrupted: ATM ejects the card; this ends the session.
5a Customer quits immediately. 6a Customer chooses to perform
another transaction: go to step 5. 7a Customer does not get card back
quickly enough: ATM beeps * Customer may cancel session: ATM
ejects the card.
© 2004 Jean-Paul Rigault 13/10/2014 09:50 35
Informal UC Description
Best Practices
! Give a meaningful name to
each use case
! Usually an active verbal form ! The name should correspond
to the objective of the expected (business) service
! Do not model outside the
system!
! Bad Customer use cases ! choosing a particular
ATM machine ! deciding how much
money to withdraw
! Do not model at too low
level!
! Bad Customer top level use cases
! insert the card ! enter secret code, get
ticket ! select transaction type,
select accounts, select amount…
! Even worse ! push the Enter button on
the keyboard…
© 2004 Jean-Paul Rigault 13/10/2014 09:50 36
Formal UC Description
Top Level UC Diagram
Handle Session
Transfer Daily
Maintain
Bank
Technician
Customer
association
initiator
supporting
system limit
© 2004 Jean-Paul Rigault 13/10/2014 09:50 37
Formal UC Description
UC Decomposition (1)
! The realization of each top level use case requires
sub-functionalities
! Lower level Use Cases, UC fragments… ! … which are not real (“start-to-end”) use cases
! Functional-like decomposition, not really object-
oriented!
! Hierarchical decomposition: relationships
between use cases
! Inclusion ! Generalization ! (Extension)
© 2004 Jean-Paul Rigault 13/10/2014 09:50 38
Formal UC Description
UC Decomposition: Inclusion
! «�include�» stereotype
! The included use case is a mandatory part of the including one
! The including UC depends on the included one
Handle
Session
«�include�»
Verify
Card
«�include�»
Authenticate
Customer
«�include�»
Get Customer
Information
Handle
Transaction
«�include�»
Including
«�include�»
Included
© 2004 Jean-Paul Rigault 13/10/2014 09:50 39
Formal UC Description
UC Decomposition: Extension (1)
! «�extend�» stereotype
! The extending use case augments the functionality of the extended one,
! The extending UC depends on the extended one
Deliver
Receipt
«�extend�»
Extended
«�extend�»
Extending
Handle
Session
«�include�»
Verify
Card
«�include�»
Authenticate
Customer
«�include�»
Get Customer
Information
Handle
Transaction
«�include�»
© 2004 Jean-Paul Rigault 13/10/2014 09:50 40
Formal UC Description
UC Decomposition: Extension (2)
! The interpretation of «�extend�» varies
! The UML standard does not specify the nature of the condition at the “extension point”
! Corporate policies may apply!
! Note the direction of the dependency arrow
! The lower level (extending) use case depends on the higher one
! The higher level one may not depend on the extension ! This remark helps to distinguish «�extend�» from
«�include�»
© 2004 Jean-Paul Rigault 13/10/2014 09:50 41
Formal UC Description
UC Decomposition: Generalization
! The specialized and
generalized use cases are
in a “sort of” relationship
Handle
Transaction
Handle
Deposit
Handle
Withdrawal
Handle
Consult
Handle
Transfer
Generalized
Specialized
© 2004 Jean-Paul Rigault 13/10/2014 09:50 42
Formal UC Description
Remark on Actors: Generalization
! It may be convenient to
apply generalization to
actors
! A frequent flyer and a
regular passenger are both
passengers
! Each of them may play the (general) role of Passenger in a use case
! However, e.g., a frequent flyer may interact with specific use cases
Passenger
Frequent
Flyer Regular
© 2004 Jean-Paul Rigault 13/10/2014 09:50 43
Formal UC Description
UC Decomposition: Cockburn's Style
Use Case: Handle Session Primary actor (initiator): Customer Supporting actor: Bank Precondition: ATM is free Primary Scenario
1. Customer inserts the card into ATM. 2. ATM asserts card validity. 3. Customer authenticates with ATM. 4. ATM gets Customer information from
Bank. 5. Customer performs a transaction. 6. Customer quits. 7. ATM ejects card , Customer takes it Postcondition: ATM is free and all
transactions have been recorded
Handle
Session
«�include�»
Verify
Card
«�include�»
Authenticate
Customer
«�include�»
Get Customer
Information
Handle
Transaction
«�include�»
© 2004 Jean-Paul Rigault 13/10/2014 09:50 44
Formal UC Description
UC Decomposition: Best Practices
! Avoid «�extend�»
! unless specific corporate policy!
! Usually actors are not repeated on decomposed
diagrams
! unless this can bring some added information… ! Interaction of an actor with a specific sub-UC ! Interaction of a specialized actor with a sub-UC
! or specific corporate policy! ! Do not over-decompose
! Sub-UC should have “functional substance” (that is, in general, several significant sub-scenarios)
© 2004 Jean-Paul Rigault 13/10/2014 09:50 45
Formal UC Description
UC Scenarios (1)
! Scenarios are instances of use cases
! Natural language for expressing scenarios
! has a strong power of expression
" lacks precision
" makes it difficult to express information like timing and concurrency
! Need for formal (UML) expression of scenarios
and use cases
© 2004 Jean-Paul Rigault 13/10/2014 09:50 46
Formal UC Description
UC Scenarios (2)
! Sequence diagrams
! Only one scenario per diagram ! Accent on the time flow ! At the Use Case level, express scenarios involving the
system and some of its actors
! May be used also as a mean to model business activity (inter-actor scenarios)
! Activity diagrams
! Several scenarios (even a full use case) at once
! Sort of (concurrent) flow charts…
© 2004 Jean-Paul Rigault 13/10/2014 09:50 47
Formal UC Description
UC Scenarios: Sequence Diagrams
: Customer : ATM : Bank
prompt for selection
select transaction
produce result
quit
insert card
get customer info
eject card time © 2004 Jean-Paul Rigault 13/10/2014 09:50 48
Formal UC Description
UC Scenarios: Activity Diagrams (1)
! Express a flow of control
! Composed of Action States (or Activities)
connected by Transitions ! Transitions may be conditional
! A Transition is fired if its origin Activity has
completed its action and if its (optional) condition
is true
Verify Date [date OK]
Verify Code
condition
transition
action state
© 2004 Jean-Paul Rigault 13/10/2014 09:50 49
Formal UC Description
UC Scenarios: Activity Diagrams (2)
Verify Card
Authenticate Customer
Get Customer Info
Handle Transaction
Eject Swallow
[ not Card_OK ]
[ Card_OK ]
[ not Passed ]
[ Passed ]
[ not Quit ]
[ Quit ]
Handle Session UC
© 2004 Jean-Paul Rigault 13/10/2014 09:50 50
Formal UC Description
UC Scenarios: Activity Diagrams (3)
! Fork and join bars
! Express concurrency ! Fork spawns several
concurrent activities ! Join waits for all incoming
activities to complete
! Logical concurrency
! Avoid enforcing non relevant sequencing
! The designer will have the freedom to choose how to implement (even in non-concurrent ways)
Process
Order
UC Receive Order
Establish Invoice
Deliver
Prepare Delivery
© 2004 Jean-Paul Rigault 13/10/2014 09:50 51
Formal UC Description
UC Scenarios: Activity Diagrams (4)
Receive
Order
Establish Invoice
Prepare Delivery
Deliver
Delivery Dept Accounting Dept User Interface
Process
Order
UC
© 2004 Jean-Paul Rigault 13/10/2014 09:50 52
Formal UC Description
UC Scenarios: Activity Diagrams (5)
Receive
Order
Establish Invoice
Prepare Delivery
Deliver
Delivery Dept Accounting Dept User Interface
Process
Order
UC
Order
Invoice
© 2004 Jean-Paul Rigault 13/10/2014 09:50 53
Formal UC Description
UC Scenarios: Activity Diagrams (6)
! Accent is on the flow of control
! Describe at once a full set of scenarios
! Describe concurrent operations
! Created objects and responsibilities of objects may
be represented
" They may become too complex
" Risk to do functional analysis
© 2004 Jean-Paul Rigault 13/10/2014 09:50 54
Practice of Use Case Models
Organizing the Model Use Case
Model
UC 1
UC 2
UC n
Top level UC diagram
Sub UC diagrams
W Scenario files
Activity diagrams
UC 1
UC 2
W
Use Case
Model
Sub
Model 1
Sub
Model 2
Package hierarchy
© 2004 Jean-Paul Rigault 13/10/2014 09:50 55
Use Case Model
Conclusion: Difficulty and Drawbacks
! Use Case modeling is difficult
! Homogeneity, completeness, consistency…
! UML “formalism” is simple, even simplistic
! No real semantics
! No formal description of textual scenarios ! Need for predefined interpretations, corporate policies
! Textual scenarios awkwardly express complex
control
! Loops, conditionals…
© 2004 Jean-Paul Rigault 13/10/2014 09:50 56
Use Case Model
Conclusion: Advantages
! Simple to elaborate, understand, and
communicate
! Even to non-computer scientists
! Focus on user needs, not on solution or
architecture
! Avoid architectural drift in object-orientation
! Ease traceability from functional needs to implementation
! Facilitate setting up integration tests
! From use cases, one can derive test cases
© 2004 Jean-Paul Rigault 13/10/2014 09:50 57
Introduction to UML
Class and Object Modeling
(Object-Oriented Analysis)
© 2004 Jean-Paul Rigault 13/10/2014 09:50 58
Analysis Model
# Object-orientation overview
! The elements of analysis models
! Class diagrams
! Realizing use cases and scenarios
! Practice of analysis models
© 2004 Jean-Paul Rigault 13/10/2014 09:50 59
Object-Orientation Overview
A World of Objects
! The (application) world is composed of objects
! These objects are linked together
! Static relationships (links)
! These objects react to stimuli (messages)
! Either internal or external ! Originating from other objects or from outside the system
! These objects have an internal state
! Internal data (attributes) and status of the links with other objects
! The state may change when the objects are stimulated
© 2004 Jean-Paul Rigault 13/10/2014 09:50 60
Object = Identity + State + Behaviour
Objects should be
distinguishable The identity is independent from the state
Operations,
events, messages…
Public interface
Internal data values
Status of links with other
objects
Object-Orientation Overview
What's in an Object? (1)
Objects have “crisp” conceptual boundaries (Booch, 1994)
© 2004 Jean-Paul Rigault 13/10/2014 09:50 61
Object-Orientation Overview
What is an Object? (2)
! Static information: architectural aspect
! List of operations (interface) ! The messages the object can accept and react to
! State values ! Possible values of internal data (attributes)
! Possible links with other objects, that are message transport media
! Dynamic behaviour: control aspect
! State evolution and messages sent to other objects ! Triggered by message flows
© 2004 Jean-Paul Rigault 13/10/2014 09:50 62
Object-Orientation Overview
Candidates for Objects
! Material (tangible) things
! Cars, planes, devices, people…
! Invoices, documents…
! More abstract things
! Flights, transactions…
! People roles
! Client, server, customer…
! Functions, processes
! Reifying, objectifying…
! And many other things
! Identity, state, behaviour depend on the application domain
! Thus, object identification is relative to the application domain
© 2004 Jean-Paul Rigault 13/10/2014 09:50 63
Object-Orientation Overview
Abstraction: Points of View
! The system analyst should
capture the view(s) of an
object that is/are appropriate
for the application and model
them in a coherent way.
© 2004 Jean-Paul Rigault 13/10/2014 09:50 64
Object-Orientation Overview
What's in a Class? (1)
! A group of objects sharing common properties:
! common structure: ! same attributes ! same possible relations with other objects
! common behaviour: same operations
! An abstract data type
! A model to instantiate objects
! A class defines the possible behaviours and the information structure of all its instances
© 2004 Jean-Paul Rigault 13/10/2014 09:50 65
Object-Orientation Overview
What's in a Class? (2)
! Different instances may
have their operations
activated in different ways,
different sequences…
Hence, they may be in
different states
! Different instances, even if
they have the same
attribute values, have
different identities
Instance = a particular object belonging to a class
Class Car
© 2004 Jean-Paul Rigault 13/10/2014 09:50 66
Object-Orientation Overview
What's in a Class? (3)
! Class = Abstract Data Type
(ADT)
! ADT= value set +
operations
! Built-in types (integer, real, boolean)
! User defined types
! User defined types are
treated as “first class
citizen”
! Copying objects,
! Passing objects as parameters or return value,
! Using operators on objects
© 2004 Jean-Paul Rigault 13/10/2014 09:50 67
Object-Orientation Overview
Links between Objects
! The architecture of the object system
! Permanent (or semi-permanent) links ! Examples
! A travel agency is connected to an airline consortium ! A car has wheels, engine, body… ! A PC is part of the Internet ! An invoice refers to a Customer ! John owns a Rolls Royce car ! John�s car is on the road to London ! Mary is employed by Amadeus ! Jacques married Bernadette
© 2004 Jean-Paul Rigault 13/10/2014 09:50 68
Object-Orientation Overview
Object States
! A car may be running, parked, or broken down
! An order may be emitted, shipping, cancelled,
completed, archived…
! A flight may be on-time, delayed, cancelled,
hijacked…
! Jacques married Bernadette
! The existence of the wedding link induces a particular state for both participants (each of them is married)
© 2004 Jean-Paul Rigault 13/10/2014 09:50 69
Object-Orientation Overview
Communication by Messages (1)
anOtherObject
Internal
data
(attributes)
anObject
Internal
data
(attributes)
message(parameters)
(static) link op1
op2
© 2004 Jean-Paul Rigault 13/10/2014 09:50 70
Object-Orientation Overview
Communication by Messages (2)
! Usually asymmetric
! The emitter knows (designates) the receiver
! The receiver does not know the emitter
! A message triggers an operation of the object
! The object may change state as a consequence of the operation
! Usually a message and its associated operation bear the same name
! Message may carry values (parameters)
© 2004 Jean-Paul Rigault 13/10/2014 09:50 71
Object-Orientation Overview
Communication by Messages (3)
! Example:
! A travel agency reserves seat 3A for Mr Smith on flight BA349 next monday
A Travel Agency reserve(“3A”, “Mr. Smith”) Flight BA349
Monday xxx
reserve(seatid, name)
After reservation, the state of the flight has changed (may be it became full?)
© 2004 Jean-Paul Rigault 13/10/2014 09:50 72
The Elements of Analysis Models
Use Case Model and Analysis Model
! Use case model
! Language of the customer ! External view of the system ! Structured by use cases
! Contract between customer
and developer
! May be (slightly) redundant or inconsistent
! Describes the functionality
! Defines use cases
! Analysis model
! Language of the developer ! Internal view of the system ! Structured by stereotyped
classes and packages ! Used primarily by developers,
designers, programmers ! Should not be redundant or
inconsistent ! Outlines a realization of the
functionality ! Defines use cases realization
© 2004 Jean-Paul Rigault 13/10/2014 09:50 73
The Elements of Analysis Models
Use Case Realization
! Realizing a use case
! Finding classes collaborating for realizing the use case ! Finding their attributes and operations ! Finding relationships between these classes ! Refining the use case and scenarios description to take
the new classes into account
! A group of classes collaborating for realizing a use
case is called a Collaboration
collaboration use case
Class1
Class2
© 2004 Jean-Paul Rigault 13/10/2014 09:50 74
The Elements of Analysis Models
Dependency (1)
! A semantic relationship
between two things
! When the target changes,
the source might have to
change
! Generally unidirectional
! Does not imply a static
(permanent) kind of
relationship
Product
Definition
Model
Analysis
Model
Person Document
«create»
© 2004 Jean-Paul Rigault 13/10/2014 09:50 75
The Elements of Analysis Models
Dependency (2)
! Realization ! Semantic relationship
between classifiers
wherein one component
specifies a contract that
the other guarantees to
carry out
! Usually relationship
between some interface
and its implementation (in
a broad sense)
collaboration use case
Product
Definition
Model
Analysis
Model
«realize»
© 2004 Jean-Paul Rigault 13/10/2014 09:50 76
Analysis Model
! Object-orientation overview
! The elements of analysis models
# Class diagrams
! Realizing use cases and scenarios
! Practice of analysis models
© 2004 Jean-Paul Rigault 13/10/2014 09:50 77
Class Diagrams
! Associations
! Generalization
! Generalization and aggregation
! Abstract classes and operations
! Stereotypical classes
! Constraints
! Best practices
© 2004 Jean-Paul Rigault 13/10/2014 09:50 78
Class Diagrams
Classes for the ATM
Card ATM interface
Session
Transaction Transaction
Record
Customer
Information
© 2004 Jean-Paul Rigault 13/10/2014 09:50 79
Class Diagrams
Class, Attribute, and Operation
Person
name address
move() marry()
attributes
operations
name Data carried by each instance of the class
Object behavior Operations that can be applied to each instance
© 2004 Jean-Paul Rigault 13/10/2014 09:50 80
Class Diagrams
Association and Link
! Association
! Link
! Instance of an association
Man Woman wedlock
bill : Man
hilary : Woman
! A structural relationship
describing a set of links
! Some special cases
(aggregation, composition)
! Generally implies mutual
knowledge
! Corresponds to stable or
(semi-)permanent
relationship
© 2004 Jean-Paul Rigault 13/10/2014 09:50 81
Class Diagrams
Attribute, Operation, Association
Person
name : string
address: string
Company
name
location
hire(Person)
dismiss(Person)
Operations may have typed arguments; they can be inferred from scenarios
Default values of attributes are possible
= mainpremisse
works in
Associations have a name
Attributes have a name (and a type)
© 2004 Jean-Paul Rigault 13/10/2014 09:50 82
Class Diagrams
Instance of a Class (Object)
! Object (Instance)
bill : Person
name = “Bill Gates” address = “Redmond, WA”
Person
«instanceOf»
Jane : Person
name = “Jane B.” address = “Paris, FR”
«instanceOf»
© 2004 Jean-Paul Rigault 13/10/2014 09:50 83
Class Diagrams
Associations: Names and Roles
Company employs
Person
Person parent
child
employer employee
role role
© 2004 Jean-Paul Rigault 13/10/2014 09:50 84
Class Diagrams
Associations: Multiplicity (1)
Company employs
Person 0..1 0..*
Man wedlock
Woman 0..1 0..1
Person parent
child 2
*
© 2004 Jean-Paul Rigault 13/10/2014 09:50 85
Class Diagrams
Associations: Multiplicity (2)
from 1 to 4
C 2
exactly 2
C 1..4
C 1..* at least 1
C * 0 or more (0..*)
C 2, 4..7, 10..* 2, 4 to 7, 10 or more
C default is (exactly) 1 © 2004 Jean-Paul Rigault 13/10/2014 09:50 86
Class Diagrams
Associations: Association as Class
! Exactly one instance of class Job per link ! The life time of the association object is the same as
the one of the link
Company employs
Person 0..1 0..*
Job
salary function
promote()
© 2004 Jean-Paul Rigault 13/10/2014 09:50 87
Class Diagrams
Associations: Aggregation
! Whole/Parts relationships
! "is part of", "is composed of"
! Antisymetric
! Two forms
! Weak aggregation (simply Aggregation) ! Strong aggregation (Composition)
© 2004 Jean-Paul Rigault 13/10/2014 09:50 88
Company employs
Person *
Family
*
*
*
Class Diagrams
Associations: (Weak) Aggregation
! Weak coupling
! Sharing is possible ! Lifetime of component is not dependent of composite
An instance of Person may be part of several families
An instance of Person may be employed by several companies
An instance of Person may be both an employee and a family member
© 2004 Jean-Paul Rigault 13/10/2014 09:50 89
! Strong coupling
! No sharing ! Life-time of component usually starts and ends with
composite
Class Diagrams
Associations: Composition
Car
Wheel Engine Body
4 1 1
Stock
*
0..1 0..1 here, cardinality is at most 1
© 2004 Jean-Paul Rigault 13/10/2014 09:50 90
Class Diagrams
Class Diagram for the ATM
Card
is inserted into ATM interface
Session
Transaction
0..1 0..1
* Transaction
Record
0..1 1
Customer
Information
0..1 1
{ordered} *
© 2004 Jean-Paul Rigault 13/10/2014 09:50 91
Class Diagrams
Generalization (1)
Transaction
Deposit Transfer
Withdrawal Consult
© 2004 Jean-Paul Rigault 13/10/2014 09:50 92
Class Diagrams
Generalization (2)
! Relationship
! Between classes ! No cardinality ! Anti-symmetric and transitive
! "Is A", "Is A Sort Of"
! Substitutability principle ! The sub-class depends on its base class(es)
! Support of generalization in UML
! Multiple inheritance is supported ! Multiple classification indirectly & partially supported ! Dynamic classification is almost not supported
© 2004 Jean-Paul Rigault 13/10/2014 09:50 93
Class Diagrams
Generalization: Substitutability
! B derives from A
! Any instance of B is also an instance of A for any purpose of an A
! Any instance of B may be substituted to an instance of A
! B may
! Add new properties to the ones inherited from A
! Redefine operations inherited from A
! B cannot get rid of properties inherited from A
© 2004 Jean-Paul Rigault 13/10/2014 09:50 94
Class Diagrams
Generalization: Polymorphism
Drawing
draw()
Figure
Circle Square
draw()
Ellipse
draw()
Rectangle
draw()
* components
for all fig in components { fig.draw()
}
© 2004 Jean-Paul Rigault 13/10/2014 09:50 95
Class Diagrams
Generalization: Multiple Inheritance
Triangle
Figure
Ellipse Rectangle
Circle Square Isosceles Tr RightAngled Tr
RightAngled Isosceles Tr
{overlapping}
© 2004 Jean-Paul Rigault 13/10/2014 09:50 96
Class Diagrams
Abstract Classes and Operations (1)
! Abstract class
! Class with no instances ! Usually at the top of a class
hierarchy ! Abstract operation
! An operation without implementation (i.e., realization)
! An abstract operation makes the whole class abstract
! If derived classes do not define the operation implementation, they are also abstract
«�abstract�» Figure
«�abstract�» draw()
Figure
draw()
© 2004 Jean-Paul Rigault 13/10/2014 09:50 97
Class Diagrams
Abstract Classes and Operations (2)
Figure
Circle Square
draw()
Ellipse
draw()
Rectangle
draw()
Abstract class (top of hierarchy)
Concrete classes
© 2004 Jean-Paul Rigault 13/10/2014 09:50 98
Class Diagrams
Stereotypical Classes (1)
! Entity class
! Long-lived (persistent) information
! Control class
! Coordination, sequencing, control…
! Boundary class
! Interaction between the system and its actors
«entity»
«control»
«boundary»
© 2004 Jean-Paul Rigault 13/10/2014 09:50 99
Class Diagrams
Stereotypical Classes (2)
Card
is inserted into
ATM interface
Session
Transaction
0..1 0..1
* Transaction
Record
0..1 1
Customer
Information
0..1 1
{ordered} *
© 2004 Jean-Paul Rigault 13/10/2014 09:50 100
Class Diagrams
Constraints
! Restrict, clarify, or specify the semantics of model
elements
! Can be applied to any kind of model element ! Constraints may be expressed by
! Free text ! Special constraint language (OCL) ! Constraints are enclosed within braces {}
! Predefined constraints
! Type of constraints (stereotype, pre- and post conditions…)
! Individual constraints
© 2004 Jean-Paul Rigault 13/10/2014 09:50 101
Class Diagrams
Constraints: Class Invariant
! A condition that must be
verified by any instance at
any time
Adult
age: Integer
is_emancipated(): Boolean
«invariant» { age >= 18 or is_emancipated() }
Class atribute Class operation
(without side-effects)
Constraint stereotype
© 2004 Jean-Paul Rigault 13/10/2014 09:50 102
Class Diagrams
Constraints: Pre- and Post-Conditions
! The operation contract
! The pre-condition must be
guaranteed by the client of the class
! The post-condition is guaranteed by
the class itself (provided that the
pre-condition holds)
Man
marry(Person p)
Person
married: Boolean gender: enum {M, F} marry(Person)
{ pre: not married and p.gender != #M post: married }
© 2004 Jean-Paul Rigault 13/10/2014 09:50 103
Class Diagrams
Constraints: Class Contract (1)
! Before an operation
! Invariants and pre-condition must be true ! After an operation
! Invariant and post-condition should be true ! Generalization and constraints (substitutability)
! Ideally, a sub-class should also verify its base classes invariants
! Ideally an operation overridden in a sub-class may weaken the pre-condition and strengthen the post-condition of its base classe(s) (“Demand less, promise more” principle)
! UML does not really enforce these rules
© 2004 Jean-Paul Rigault 13/10/2014 09:50 104
Class Diagrams
Constraints: Class Contract (2)
CarDealer
sell_with_trade_in()
DiscountCarDealer
sell_with_trade_in()
{ pre: old car less than 5 years old post: discount 10 % }
{ pre: old car less than 8 years old post: discount 15 % }
© 2004 Jean-Paul Rigault 13/10/2014 09:50 105
Company employs
Person 0..1 *
manages *
Class Diagrams
Constraints: Predefined Constraints
Company employs
Person 0..1 *
Unemployment
Agency
0..1
* { xor }
{ subset } 0..1
© 2004 Jean-Paul Rigault 13/10/2014 09:50 106
Class Diagrams
Best Practices (1)
! Avoid meaningless classes
! No attributes nor operations
! No significance with respect to the problem…
! At the analysis level, classes represent abstraction of the application, they are not a programming hack to reuse code
RoundObject
Balloon
Ball
Wheel
Egg
SeaUrchin
© 2004 Jean-Paul Rigault 13/10/2014 09:50 107
Class Diagrams
Best Practices (2)
! Avoid too big
classes
! Many attributes, many operations, not all of them are needed at a given time
! Too many responsibilities, represent several abstractions…
! Use inheritance, aggregation, association instead
Restaurant
tables card dishes waiters patrons
seat(patron, table) add_dish(menu, dish) serve(waiter, table) numberOfMeals()
Restaurant
Table Waiter
Patron
numberOfMeals()
serve
Dish
Card
add(dish)
seat(table)
*
*
*
© 2004 Jean-Paul Rigault 13/10/2014 09:50 108
Class Diagrams
Best Practices (3)
! Avoid explicit special operations
! Set, get, constructors, destructors, assignments….
! Attribute versus association
! Use attribute notation for primitive (non-object) types ! For objects prefer aggregation or even regular
association, with roles
Car
color: String power: Integer …
Person owner
Engine
© 2004 Jean-Paul Rigault 13/10/2014 09:50 109
Vehicle Engine
Class Diagrams
Best Practices (4)
! Avoid explicit circular
dependency
! In particular a base class should not depend on its sub-classes
! Beware of the “fragile
base” class problem
Base
Deriv
«friend»
Base
Deriv
Bicycle
© 2004 Jean-Paul Rigault 13/10/2014 09:50 110
Class Diagrams
Best Practices (5)
! Do not confuse dependency and association
! An association describes a relationship between instances ! An association usually implies mutual dependency
Form
FormWindow
0..1
1 Form
FormWindow
? indeed, but better …
This implies the diagram on the left, but adds information related to instances
© 2004 Jean-Paul Rigault 13/10/2014 09:50 111
Class Diagrams
Best Practices (6)
! Avoid redundancies
! Do not represent the same information with two different ways
! Attribute and association ! Redundant attributes
Man
my_wife: Woman Woman
wife
Person
birthday: Date age: Integer
© 2004 Jean-Paul Rigault 13/10/2014 09:50 112
Class Diagrams
Best Practices (7)
! At analysis level, avoid programming artifacts
Company Person * 0..1
ListOfEmployees
Company Person * 0..1
* Company
listOfEmployees
Person
Also violate previous slide advice
*
© 2004 Jean-Paul Rigault 13/10/2014 09:50 113
Analysis Model
! Object-orientation overview
! The elements ot analysis models
! Class diagrams
# Realizing use cases and scenarios
! Practice of analysis models
© 2004 Jean-Paul Rigault 13/10/2014 09:50 114
Realizing Use Cases and Scenarios
! Use Case realization as a Collaboration
! Realizing scenarios
! Sequence diagrams
! Collaboration diagrams
! Interaction diagrams: comparison
! Activity diagrams and objects
! Best practices
© 2004 Jean-Paul Rigault 13/10/2014 09:50 115
Handle Session
Realizing UC and Scenarios
UC Realization as Collaboration (1)
! List all the classes (or roles) that together realize a
given use case
! Allow traceability from Use Case Model to Class
Model
Session Transaction
Customer
Information
ATM interface
© 2004 Jean-Paul Rigault 13/10/2014 09:50 116
Realizing UC and Scenarios
UC Realization as Collaboration (2)
MVC pattern
Model
Controler
View
! Collaboration
! Defines an interaction
! A society of roles, objects, or other elements to provide some cooperative and synergic behavior
! Possibly structural as well as behavioral
! Used to model Patterns
(design or analysis patterns)
© 2004 Jean-Paul Rigault 13/10/2014 09:50 117
Realizing UC and Scenarios
Realizing Scenarios (1)
! The requirement scenarios do not involve objects
(and classes)
! Except for actors ! There is a need to revisit the scenarios in the light of the
analysis classes
! The refined scenarios are part of the use case realizations (collaborations)
! Using formalisms will
! make descriptions more precise
! help the analysis work © 2004 Jean-Paul Rigault 13/10/2014 09:50 118
Realizing UC and Scenarios
Realizing Scenarios (2)
“Scenario diagrams”
! Interaction diagrams: one scenario at a time
! Sequence diagrams
! Collaboration diagrams
! Activity diagrams: several scenarios (a full use
case?)
© 2004 Jean-Paul Rigault 13/10/2014 09:50 119
Realizing UC and Scenarios
Sequence Diagrams (1)
! Describe one scenario
! Involve objects and messages (stimuli) ! Messages exchanged between instances are called stimuli ! A stimulus can be calling an operation (with possible
parameters) ! An operation is attached to a particular class ! An operation call is a synchronous communication
! A stimulus can be sending a signal ! A signal is itself a classifier, a priori independent of classes ! Roughly speaking, the instances of a signal are its
occurrences ! Sending a signal is an asynchronous communication
! Accent is on the time flow of events
© 2004 Jean-Paul Rigault 13/10/2014 09:50 120
Realizing UC and Scenarios
Sequence Diagrams (2)
time
get_Customer_Information()
select_transaction(sel)
display_menu()
: Customer : Bank
quit eject_card
insert_card
: ATMInterface
: Session «�create�»
: Transaction «�create�»
display_menu()
ask_PIN()
enter_PIN(pin)
© 2004 Jean-Paul Rigault 13/10/2014 09:50 121
Realizing UC and Scenarios
Sequence Diagrams (3)
: Customer
insert_card
: ATMInterface
: Session «�create�»
actor (optional)
stimulus (signal kind)
life line
transient object
permanent object
© 2004 Jean-Paul Rigault 13/10/2014 09:50 122
Realizing UC and Scenarios
Sequence Diagrams (4)
get_Customer_Information()
select_transaction(sel)
display_menu()
: Customer : Bank : ATMInterface
: Session
: Transaction «�create�»
signal sent out of the system
function call
end of object life
stimulus (operation call with parameter)
begin of object life
© 2004 Jean-Paul Rigault 13/10/2014 09:50 123
Realizing UC and Scenarios
Collaboration Diagrams (1)
! Describe one scenario
! Involve objects and messages (stimuli)
! Accent is on messages exchanged and links
between objects
! Do not confuse ! Collaboration: the realization of a use case, which usually
appears in a Use Case diagram ! Collaboration diagram: a form of interaction diagram
expressing a scenario
© 2004 Jean-Paul Rigault 13/10/2014 09:50 124
Realizing UC and Scenarios
Collaboration Diagrams (2)
: Customer
: ATMInterface
: Session
: Transaction
: Bank
4: 8: 13: 16:
5: enter_PIN(pin) 9: select_transaction( sel)
14: quit( ) 2: <<create>>
3: ask_PIN( ) 7: display_menu( ) 12: display_menu( )
15: eject_card( )
6: get_Customer_Information( )
10: <<create>>
11:
© 2004 Jean-Paul Rigault 13/10/2014 09:50 125
Realizing UC and Scenarios
Interaction diagrams: Comparison (1)
Sequence and collaboration diagrams
! Common properties
! For expressing scenarios in the analysis model, both forms are almost equivalent, although the focus is different
! Only one scenario at a time ! Help to define necessary operations of classes " The number of diagrams may become huge " Risk of redundancy in the diagrams for scenarios with
only little variations (difficult to maintain) " Some useful features are awkwardly represented (e.g.,
loops and conditionals) © 2004 Jean-Paul Rigault 13/10/2014 09:50 126
Realizing UC and Scenarios
Interaction diagrams: Comparison (2)
! Differences
! Sequence: temporal aspect (stress on message/signal sequencing)
! Collaboration: architectural aspect (objects and links, roles of objects…)
! For the design model, collaboration diagrams may be richer
! Roles of objects
! Some form of concurrency
! Sequence nesting…
© 2004 Jean-Paul Rigault 13/10/2014 09:50 127
Realizing UC and Scenarios
Best Practices
! Expressing use case and scenarios in the
customer’s language (usually natural) remains
mandatory
! Do not use too much formalism!
! Avoid redundant scenario descriptions ! For instance, remember that sequence and collaboration
diagrams are equivalent and that is generally useless to use both to describe the same scenario
! Also recall that activity diagrams contain several scenarios
! Limit the number of objects, swimlanes, and
interactions in diagrams © 2004 Jean-Paul Rigault 13/10/2014 09:50 128
Analysis Model
! Object-orientation overview
! The elements ot analysis models
! Class diagrams
! Realizing use cases and scenarios
# Practice of analysis models
© 2004 Jean-Paul Rigault 13/10/2014 09:50 129
Practice of Analysis Models
Organizing the Model
UC 1
UC 2
TheSystem
UC Model
…
Class diagrams
UC diagrams showing Collaborations
Collaboration UC 1
UC 2
…
Interaction diagrams
Collaboration
…
Class
Class
Analysis
Model
© 2004 Jean-Paul Rigault 13/10/2014 09:50 130
Practice of Analysis Models
Model Global Properties
! Scenarios (and activity diagrams) should be
attached to Use Case realizations (i.e.,
Collaborations)
! All scenarios of interest should be represented in a
“scenario diagram”
! It is almost impossible (not suitable?) to describe all scenarios
! Completeness of the Analysis Model
! Every Use Case should have its own realization (Collaboration) listing the classes that “implement” it
! A class should be part of at least one UC realization (Collaboration)
© 2004 Jean-Paul Rigault 13/10/2014 09:50 131
Practice of Analysis Models
Scenarios-Collaboration Completeness
! A class contributing to a UC realization
(Collaboration) should appear in at least one
“scenario diagram”
! If an instance appears in a “scenario diagram”, its
class should be associated with the corresponding
UC realization (Collaboration)
© 2004 Jean-Paul Rigault 13/10/2014 09:50 132
Practice of Analysis Models
Interaction-Class Completeness
! A stimulus received by an object should be part of
the interface of its class (it is usually one of its
operations)
! Ideally, public operations should appear in some
“scenario diagram”
© 2004 Jean-Paul Rigault 13/10/2014 09:50 133
Introduction to UML
State Modeling
(Object-Oriented Analysis)
© 2004 Jean-Paul Rigault 13/10/2014 09:50 134
State-Transition Diagrams
! Attached to a class (with a reactive behaviour)
! Describe the dynamic behaviour of any instance
when receiving events
! Relationships between events and states
! Deterministic finite state machines ! Define the object states, their sequences, and the
corresponding transitions ! Express the control behaviour of an instance in any
scenario where it may appear ! Model borrowed from Harel’s StateCharts
© 2004 Jean-Paul Rigault 13/10/2014 09:50 135
State and Events
Events
! Trigger state transitions
! An event can be
! A stimulus: operation call or signal ! A stimulus originates from some object (possibly the
receiving one) ! An operation call requires some processing from the
receiving object ! A signal notifies some information; it is an object
! A condition changing its truth value ! A watch dog elapsing
! Events may carry value (parameters)
! Events have no duration
© 2004 Jean-Paul Rigault 13/10/2014 09:50 136
State and Events
States
! Abstraction of attribute values and link status
! The state of an object specifies
! The way it reacts to received events ! A state specifies the events to which it is sensitive ! Some events may be ignored when in a state
! The activities the object performs while in this state
! State duration is not null
! Two predefined sorts of states
! Initial state: corresponds to an instance “creation” ! Final state: corresponds to an instance “destruction”
© 2004 Jean-Paul Rigault 13/10/2014 09:50 137
State and Events
States and Events Separation
! Events separate states
! States separate events
state 2 state 4 state 1 state 3 state 5
events
© 2004 Jean-Paul Rigault 13/10/2014 09:50 138
State-Transition Diagrams
States
initial state
final state
do: activity() entry/action()
exit/action() event/action()
State name
action(): some processing, with an ideally null duration; usually corresponds to a (private) operation of the class
activity(): as action() except that it may have non-null duration
Activity to perform while in the state
Action to perform when leaving the state
Action to perform when entering the state
Action to perform in response to an event without leaving the state
© 2004 Jean-Paul Rigault 13/10/2014 09:50 139
State-Transition Diagrams
States and Transitions (1)
event(parameters)[guard] / action()^sends
State1
State2
transition
Boolean condition
Action performed while traversing the transition Signals sent to other objects
while traversing the transition
As usual in UML all items are optional: If no label, normal termination transition
Trigger part Action part
© 2004 Jean-Paul Rigault 13/10/2014 09:50 140
State-Transition Diagrams
States and Transitions (2)
! State entry
! The entry actions are performed
! The do activity is started ! While in state, wait for
! Either the termination of the do activity (normal termination)
! Or an event listed in a event/action clause
! Or an event in the trigger part of an outgoing transition (preemption)
! Normal termination
! If there exists a normal termination transition the condition of which holds (or is absent), execute the exit actions and traverse transition
! Otherwise keep waiting ! Event/action clause
! Suspend the do activity, execute the action, and resume the do activity
! Preemption
! Abort the do activity, perform the exit actions, and take the transition
© 2004 Jean-Paul Rigault 13/10/2014 09:50 141
State-Transition Diagrams
States and Transitions (3)
! ST diagrams represent deterministic finite state
machines
! For a given state, its outgoing transitions must be
exclusive
! If two outgoing transitions are triggered by the same event (or no event at all), their guards must be exclusive
! UML state-machine model does not cope with the
problem of simultaneous events
! Events are supposed to be serialised prior to be delivered ! Hence two events cannot be simultaneous
© 2004 Jean-Paul Rigault 13/10/2014 09:50 142
State-Transition Diagrams
Simple ST Diagrams (1)
This diagram omits details of states and transitions: this does not mean they do not exist; this simply means they are not shown!
At gate
Taxiing
Taking off
Landing
Flying
© 2004 Jean-Paul Rigault 13/10/2014 09:50 143
State-Transition Diagrams
Simple ST Diagrams (2)
At gate
do: boarding()
Taxiing
do: reach_runway()
Taking off
do: take_off()
Landing
do: land()
Flying
do: flollow_flight_plan()
go [boarding terminated]
clear_for_take_off [runway lined up]
airborne
/^ATC.request_for_landing
[speed < SLimit]
[gate free]
© 2004 Jean-Paul Rigault 13/10/2014 09:50 144
State-Transition Diagrams
Simple ST Diagrams (3)
White move Black move
Start
Time over Time over
Black win
stalemate
Null
checkmate stalemate
White win
checkmate
© 2004 Jean-Paul Rigault 13/10/2014 09:50 145
State-Transition Diagrams
Simple ST Diagrams (4)
Idle Visible
do: execute() cursor_move /mark_selection()
Spontaneous transition (termination of do:)
button_down/display_menu()
button_up /erase_menu()
© 2004 Jean-Paul Rigault 13/10/2014 09:50 146
State-Transition Diagrams
Hierarchical ST Diagrams (1)
Neutral Backward B
N
F N
Forward
1st 2nd 3rd
up up
stop down down
© 2004 Jean-Paul Rigault 13/10/2014 09:50 147
State-Transition Diagrams
Hierarchical ST Diagrams (2)
The history pseudo-state memorises the current sub-state and forces its re-entry when re-entering the macro-state
Neutral Backward N
N
Forward
F
H
1st 2nd 3rd
up up
stop down down
B
© 2004 Jean-Paul Rigault 13/10/2014 09:50 148
State-Transition Diagrams
ST Diagrams with Swimlanes
do: refuel()
do: catering()
Wait for crew do: boarding()
do: check_aircraft() [crew arrived]
At terminal
© 2004 Jean-Paul Rigault 13/10/2014 09:50 149
Introduction to UML
Annex 1
A Brief Object-Oriented Glossary
© 2004 Jean-Paul Rigault 13/10/2014 09:50 150
Object-Oriented Glossary (1)
! Link
! Static relationship between objects
! Provide infrastructure for exchanging messages
! Object
! Abstraction of a concept in the application world
! Has crisp boundaries ! Owns a state, a behaviour,
and an identity ! Has links with other objects ! Exchanges messages with
them
! Abstraction
! Separate usage information from implementation details
! Modularity
! Group semantically related things together
! Encapsulation
! Hide unnecessary information
! Message
! Dynamic flow of information between objects
! Need links to travel
© 2004 Jean-Paul Rigault 13/10/2014 09:50 151
Object-Oriented Glossary (2)
! Association
! Relationship between classes, modelling links that the instances of the classes may have together
! Model of the links between instances of classes
! Links are instances of associations
! Class
! Group of objects with identical structure and behaviour
! Model for a group of objects ! Defines a type
! Type
! Set of values together with legal operations on these values
! Instance of a class
! Object following the model provided by the class
© 2004 Jean-Paul Rigault 13/10/2014 09:50 152
Object-Oriented Glossary (3)
! Derived class
! Inherits from all members (attributes and operations) of its super class
! Can only add new members or redefine some operations
! Abstract operation
! Only defines the signature of an operation, not its implementation
! Abstract class
! Has no instance
! Defines common attributes and operations of a set of classes
! Polymorphism
! Ability of related objects to answer to the same message, while in different ways, depending on their class
© 2004 Jean-Paul Rigault 13/10/2014 09:50 153
Introduction to UML
Annex 2
Synopsis of UML Model Elements
© 2004 Jean-Paul Rigault 13/10/2014 09:50 154
A Conceptual View of UML
! Model elements
! Rules
! Common mechanisms
! A UML model
© 2004 Jean-Paul Rigault 13/10/2014 09:50 155
Model Elements
ModelElement
Diagram
“Thing”
Relation
Abstractions, first-class citizen in the model
Tie "things" together
Group interesting collections of things and express (some of) their relationships
© 2004 Jean-Paul Rigault 13/10/2014 09:50 156
Model Elements
Summary
ModelElement
Diagram
“Thing”
Use Case
Class
Interface
Collaboration
Active Class
Component
Node
Relation
Realization
Dependency Association Generalization
Class
Use Case
Collaboration
Deployment
Object
Sequence
State-Transition
Component Activity
Structural
Behavioural
Organizational
Annotational
Interaction State Machine
Package
Note
© 2004 Jean-Paul Rigault 13/10/2014 09:50 157
Model Elements
Examples of “things” (1)
! “Classifiers”: elements that may have instances
Place an order A use case
Person
name address move() marry()
A class
person.cpp A component
FileServer
A node
© 2004 Jean-Paul Rigault 13/10/2014 09:50 158
Model Elements
Examples of “things” (2)
! Packages
! The only organisational
element
! Represent (a form of) sub-model
! Hierarchical organisation
! Interpackage dependencies
! Multiple meanings
! Represent phases/activities of the development process
! Analysis model, design model, test model…
! Represent parts of the system
! User interface, data base access, librairies…
! Mere storage for related model elements…
aPackage
© 2004 Jean-Paul Rigault 13/10/2014 09:50 159
Model Elements
Examples of “things” (3)
! Notes
! Explanatory parts, comments
! May be attached to any modeling element ! Complement the model
! Free format, pseudo-code, constraint language, formal notations…
Product
Definition
Model
This is a package
© 2004 Jean-Paul Rigault 13/10/2014 09:50 160
Model Elements
Relationships
! Dependency
! A semantic relationship between two things ! When the target changes, the source might have to change
! Realisation
! Semantic relationship between classifiers wherein one thing specifies a contract that the other guarantees to carry out
! Association
! A structural relationship describing a set of links ! Some special cases (aggregation, composition)
! Generalisation
! Objects of the specialised thing are substitutable for objects of the more general one
© 2004 Jean-Paul Rigault 13/10/2014 09:50 161
! A semantic relationship
between two things
! When the target changes,
the source might have to
change
! Generally unidirectional
! Does not imply a static (permanent) kind of relationship
Model Elements
Relationships: Dependency
Flight
Simulation
Engine
User
Interface
Tom
«instanceOf» Person
© 2004 Jean-Paul Rigault 13/10/2014 09:50 162
Dynamic diagrams
Model Elements
Diagrams
Class diagram
Object diagram
Use case diagram
Sequence diagram
Collaboration diagram
Statechart diagram
Activity diagram
Component diagram
Deployment diagram
Static diagrams
Static (implementation) diagrams
Interaction diagrams
State-transition diagrams
© 2004 Jean-Paul Rigault 13/10/2014 09:50 163
Rules
! Well-formed model
! Rules for
! Names
! Scopes ! Visibility
! Integrity
! Execution
! Badly-formed models
! Elided
! Incomplete
! Inconsistent
! Badly-formed models
cannot be avoided during
the project life-cycle
© 2004 Jean-Paul Rigault 13/10/2014 09:50 164
Common Mechanisms
! Specifications
! (Usually textual-like) representations stating the exact details of a model element (its properties)
! Adornments
! Graphic or textual adornments supplying extra semantics
! Extensibility mechanisms
! Stereotypes ! Tagged values
! Constraints
© 2004 Jean-Paul Rigault 13/10/2014 09:50 165
Common Mechanisms
Specifications
Specification of a class
© 2004 Jean-Paul Rigault 13/10/2014 09:50 166
! A stereotype can be
attached to any model
element
! UML1.*: No more than one stereotype per element
! It qualifies (particularises)
a model element
semantics
! Predefined and user-
defined stereotypes
Common Mechanisms
Stereotypes
Flight
Simulation
Engine
User
Interface
«access»
«vendor library» MFC
© 2004 Jean-Paul Rigault 13/10/2014 09:50 167
Common Mechanisms
Stereotypes & Adornments
«�subsystem�» Billing
Billing
«�model�» Design Model
Design Model
Stereotype
Graphic adornment
«�abstract�»
Person Person
Textual (font) adornment
© 2004 Jean-Paul Rigault 13/10/2014 09:50 168
Common Mechanisms
Tagged Values & Constraints
! Tagged values and
properties
Person
{version = 1.0 author = jpr}
name {frozen} address age
move() marry() single()
{pre: age > 18 and single()}
! Constraints
© 2004 Jean-Paul Rigault 13/10/2014 09:50 169
A UML Model
! A set of Model Elements
! Hierarchical organisation owing to packages
! (Partially) visible through diagrams ! Consistent and complete
! Manipulable by tools, verifiable, modifable… ! Exchangeable (XML)
! A UML model is not reducible to a set of diagrams
© 2004 Jean-Paul Rigault 13/10/2014 09:50 170
A UML Model
Rational Rose Representation
Model representation and browser
Diagram editors
Documentation of current model element
© 2004 Jean-Paul Rigault 13/10/2014 09:50 171
Introduction to UML
Annex 3
Diagram Notations
© 2004 Jean-Paul Rigault 13/10/2014 09:50 172
UML Diagrams
Requirement modeling, Design…
Design, Test, Configuration Management
Requirement modeling, Design
Design, Test, Simulation
Requirement modeling, Design, Test
Requirement modeling, Design, Test
Requirement modeling
Analysis, Design, Test…
Analysis and Design
Run-time organization, distribution…
Deployment
Software resource organization Component
Business procedures Activity
Dynamic behavior Statechart
Cooperation between objects, Design Patterns
Collaboration
Scenario of use, exchange of messages between objects
Sequence
Application needs Use Case
Architecture of a particular instance of the model
Object
Architecture, structure Class
© 2004 Jean-Paul Rigault 13/10/2014 09:50 173
Synopsis of Notations
Use Case Diagrams
© 2004 Jean-Paul Rigault 13/10/2014 09:50 174
Synopsis of Notations
Class Diagrams
© 2004 Jean-Paul Rigault 13/10/2014 09:50 175
Synopsis of Notations
Object Diagrams
© 2004 Jean-Paul Rigault 13/10/2014 09:50 176
Synopsis of Notations
Sequence Diagrams
time
© 2004 Jean-Paul Rigault 13/10/2014 09:50 177
Synopsis of Notations
Activity Diagrams
© 2004 Jean-Paul Rigault 13/10/2014 09:50 178
Synopsis of Notations
State-Transition Diagrams
© 2004 Jean-Paul Rigault 13/10/2014 09:50 179
Synopsis of Notations
Component Diagrams
© 2004 Jean-Paul Rigault 13/10/2014 09:50 180
Synopsis of Notations
Deployment Diagrams
© 2004 Jean-Paul Rigault 13/10/2014 09:50 181
Introduction to UML
References
© 2004 Jean-Paul Rigault 13/10/2014 09:50 182
The Object-Oriented Approach
Generality
! Object-Oriented Software Engineering Ivar Jacobson Addison Wesley, 1993
! Object Oriented Analysis and Design Grady Booch 2nd Edition, Addison Wesley, 1994
! Object-Oriented Solutions Grady Booch Addison Wesley, 1996
! Object-Oriented Software Construction Bertrand Meyer 3rd Edition, Prentice Hall, 2000
© 2004 Jean-Paul Rigault 13/10/2014 09:50 183
The Object-Oriented Approach
Methodology
! The Unified Software Development Process Ivar Jacobson, Grady Booch, James Rumbaugh Addison Wesley, 1999
! Object Solutions: Managing the Object-oriented Project Grady Booch Addison Wesley, 1996
! Surviving Object-oriented Projects Alistair Cockburn Addison Wesley, 1997
© 2004 Jean-Paul Rigault 13/10/2014 09:50 184
The Unified Modeling Language
Tutorial Books
! The Unified Modeling Language User Guide Grady Booch, James Rumbaugh, Ivar Jacobson Addison Wesley, 1999.
! The Unified Modeling Language Reference Guide James Rumbaugh, Grady Booch, Ivar Jacobson Addison Wesley, 1999
! UML in a Nutshell Sinan Si Alhir O’Reilly, 1998
© 2004 Jean-Paul Rigault 13/10/2014 09:50 185
The Unified Modeling Language Using the UML
! Visual Modeling with Rational Rose 2000 and UML Terry Quatrani, Addison Wesley, 2000
! Writing Efficient Use Cases
Alistair Cockburn, Addison Wesley, 2001
! Applying Use Cases: A Practical Guide Geri Schneider, Jason P. Winters Addison Wesley, 1998
! UML Distilled Martin Fowler (with Kendall Scott) Addison Wesley, 1997
© 2004 Jean-Paul Rigault 13/10/2014 09:50 186
Object-Oriented Approach & UML
Miscellaneous
! The Object Constraint Language
Jos Warmer, Anneke Kleppe Addison Wesley, 1999
! Design Patterns: Elements of Reusable Object-oriented Software Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides Addison Wesley, 1995
! Applying UML and Patterns, Craig Larman 2nd Edition, Prentice Hall, 2002
! Model Driven Architecture
! David S. Frankel Wiley, 2003
© 2004 Jean-Paul Rigault 13/10/2014 09:50 187
The Unified Modeling Language
Official References
! OMG Unified Modeling Language Specification Object Management Group, Inc. Version 1.5, 2003
! URL's:
! http://www.omg.com
! http://www.rational.com/uml