Upload
cooper-goodyear
View
216
Download
1
Embed Size (px)
Citation preview
1CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Object georiënteerd Ontwerpen met UML
Saxion Hogeschool Enschede, januari 2005
UML Overview 2
UML Overview
3CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
UML
• This is how the UML developers see their brain child:
"The Unified Modeling LanguageUnified Modeling Language (UML) provides system architects working on object analysis and design with one consistent language for specifyingspecifying, , visualizingvisualizing,, constructing constructing, and documentingdocumenting the artifacts of software systemssoftware systems, as well as for business modeling."
4CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
UML : What It Is ….A language for modeling systems :
• Mechanical systems, electronic systems
• Software systems
• A combination
• But also business processesA language that helps to cope with complexity of systems :
• Abstracts from uninteresting details
• Provides different, but related views
• Reveals large scale structure (architecture)A language that helps to develop software systems :
• Modeling the problem domain
• Specifying desired system behavior
• Describe implementation
5CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
UML … What It Isn’t
A description of a software development process ((R)UP is the “corresponding” process)
A programming language (models are not always executable)
6CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
The number of OO methods increased from 10 10 in 1989 …… … to more than 5050 in 1994
The most notable (say popular) methods were :
•Booch's OOD
• Jacobson's OOSE
•Rumbaugh's OMT
•Fusion
•Shlaer-Mellor
•Coad and Yourdon
No modeling language filled all needs completely
UML History
7CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
UML HistoryBabylonian confusion:
• Everybody invents and speaks his own modeling language
• Everybody has a different understanding of modeling concepts
• Tools all use a different language or dialect
• Interchange of models is not possibleOne popular language (and process) emerged: OMT OMT (2)
• Grady Booch observed the need for an object esperanto!
A comedy acted out in real life: the three amigosthe three amigos• Around 1994 BoochBooch convinced the other two famous
methodologists to join him at rational : JacobsonJacobson, , RumbaughRumbaugh
8CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
History UML
Booch method OMT
Unified Method 0.8OOPSLA ´95
OOSEOther Methods
UML 0.9Web - June ´96
publicfeedback
UML 1.5
UML 1.0
UML 2.02005?
2003
UML approved UML approved
by the OMGby the OMG
Nov ‘97Nov ‘97
9CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
OMGOMG stands for object management group, inc.
(1989)International industrial consortium with over 800
members The OMG promotes object-oriented technology
•E.G. CORBA and UMLThe OMG wants to provide a framework for
software development•Stimulate growth of object technology
• Increase interoperability of software of different vendors
•Reducing confusion by setting standards
10CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Meyer
Before and after conditions
Harel
StatechartsGamma, et al
Frameworks en patterns,
HP Fusion
Operation descriptions enmessage numbering
Embley
Singleton classes enhigh-level view
Wirfs-Brock
Responsibilities
Odell
Classification
Shlaer - Mellor
Object lifecycles
Rumbaugh
OMT
Booch
Booch methode
Jacobson
OOSE
Contributions to UML
11CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
UML and other OMG technologies
OMG UMLUM L XM I
Docum ent TypeDefinition
XM L M etadataInterchange
(XM I) Facility
UM L Profile forCO RBA
UM L Profiles forBusinessDom ains
M eta ObjectFacility
Specification Layer
M etadata Layer
Custom ization Layer
PlatformTechnologyprofiles***
DomainTechnologyprofiles***
*** In process, not yet adopted
12CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
UML DiagramsThe UML is constructed specifically to enable modeling of
objects, their structure, behavior and interaction.With the UML it is possible to :
• Display the boundary of a system & its major modes of use as observed by external actors using Use Case DiagramsUse Case Diagrams .
• Illustrate how particular use cases are realized through the interactions between objects in Interaction DiagramsInteraction Diagrams::
• Sequence DiagramsSequence Diagrams;• Communication DiagramsCommunication Diagrams.
• Model the structure of objects with Class DiagramsClass Diagrams.
• Model individual object behavior with State machine State machine Diagrams.Diagrams.
• Describe the physical implementation architecture with ComponentComponent & Deployment DiagramsDeployment Diagrams..
13CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
UML Diagrams
Static ViewDynamic View
Implementationstructure
Object interaction
Logical structure
Use CaseDiagramsUse Case
DiagramsUse CaseDiagrams
Use CaseDiagramsUse Case
DiagramsUse CaseDiagrams
ScenarioDiagramsScenario
DiagramsDiagrams
ScenarioDiagramsScenario
DiagramsCommunicationDiagrams
StateDiagramsState
DiagramsComponentDiagrams
StateDiagramsState
DiagramsComponentDiagrams
ComponentDiagramsComponent
DiagramsDeploymentDiagrams
ComponentDiagramsComponent
DiagramsDeploymentDiagrams
StateDiagramsState
DiagramsCollaborationDiagrams
StateDiagramsState
DiagramsCollaborationDiagrams
ScenarioDiagramsScenario
DiagramsActivityDiagrams
ScenarioDiagramsScenario
DiagramsActivityDiagrams
Use CaseDiagramsUse Case
DiagramsSequenceDiagrams
Use CaseDiagramsUse Case
DiagramsSequenceDiagrams
StateDiagramsState
DiagramsClassDiagrams
StateDiagramsState
DiagramsClassDiagrams
State machineDiagrams
Models
14CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
ViewsUse Case View :
• Use Cases capture a mode of use of the system as observed by an external actor. The Use Case view is a visual representation of such modes of use.
Static View :
• captures static relationships between conceptual entities in a domain, abstracting from their physical representation or implementation.
Design View :
• models the structure of the application itself (structured classifiers, collaborations, components and interfaces).
State Machine View :
• Models the possible life histories of an object of a class.
15CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
ViewsActivity View :
• Shows the flow of control among the computational activities involved in performing a calculation or a workflow.
Interaction View :• Describes sequences of message exchanges among the
parts of a system.Model Management View :
• Models the organization of the model itself. A model comprises a set of packages that hold model elements (classes, state machines, use cases) or other packages.
Deployment View :• A description of the allocation of components to execution
resources.
16CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Views
Major Area View Diagram
structural static view class diagram
design view internal structure
collaboration diagram
component diagram
use case view
use case diagram
17CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Views
Major Area View Diagram
dynamic state machine view
state machine diagram
activity view activity diagram
interaction view sequence diagram
communication diagram
physical deployment view deployment diagram
model management
model management view
package diagram
18CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Use-Case ViewUse-Case Diagrams Use-Case Diagrams model modes of use of a
system :•Use Cases
•Actors
Visitor
Staff
Patient
Person NormalUse
<<include>>
PressStopButton
<<extend>>
EnterLiftCage
ExitLiftCage
Normal use of a hospital liftVisitor
Staff
Patient
Person NormalUse
PressStopButton
<<extend>>
EnterLiftCage
ExitLiftCage
Visitor
Staff
Patient
Person NormalUse
<<include>>
PressStopButton
<<extend>>
EnterLiftCage
ExitLiftCage
19CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Static ViewClass Diagrams Class Diagrams model structure of objects and their
relationships
•Classes
•Objects
•Packages
Lift system
DoorButton Chime
sound()
Door
FloorRequestButton
Shaft
LiftCage
22 111010
11
Lift model (structure)
DoorButton Chime
sound()
Door
FloorRequestButton
Shaft
LiftCage
22 111010
11
DoorButton Chime
sound()
Door
FloorRequestButton
Shaft
LiftCage
22 111010
11
Lift model (structure)
20CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
: Person
upButton : LiftCagefloorRequestButton: Door
press( )
doorIsClosed ()
press()visit(j)
close()
pass
pass
visit(i)
open( )atFloor(i)
atFloor(j)open( )
Lift model (behavior)
: Person
upButton : LiftCagefloorRequestButton: Door
press( )
doorIsClosed ()
press()visit(j)
close()
pass
pass
visit(i)
open( )atFloor(i)
atFloor(j)open( )
: Person
upButton : LiftCagefloorRequestButton: Door
press( )
doorIsClosed ()
press()visit(j)
close()
pass
pass
visit(i)
open( )atFloor(i)
atFloor(j)open( )
Lift model (behavior)
Interaction diagramsInteraction diagramsModel interactions between
objects
•Objects
•Messages
Interaction View
DoorButton Chime
sound()
Door
FloorRequestButton
Shaft
LiftCage
22 111010
11
DoorButton Chime
sound()
Door
FloorRequestButton
Shaft
LiftCage
22 111010
11
21CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
State machineView
State machine Diagrams model behavior of individual State machine Diagrams model behavior of individual objectsobjects
•States
•Transitions
•Events (messages)
Door
Opening
do: opening()
Closing
do: closing()entry: detector.enable()exit: detector.disable()
Closed
open()
stopClosing()
Open
close()
after( closureTimeOut )
Door model(behavior)
Opening
do: opening()
Closing
do: closing()entry: detector.enable()exit: detector.disable()
Closed
open()
stopClosing()
Open
close()
after( closureTimeOut )
Opening
do: opening()
Closing
do: closing()entry: detector.enable()exit: detector.disable()
Closed
open()
stopClosing()
Open
close()
after( closureTimeOut )
Door model(behavior)
DoorButton Chime
sound()
Door
FloorRequestButton
Shaft
LiftCage
22 111010
11
DoorButton Chime
sound()
Door
FloorRequestButton
Shaft
LiftCage
22 111010
11
22CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Component ViewComponent Diagrams
•Typical components:• Executables• DLL’s• Packages• Database tables
•Show the component dependencies
Building.java
java.awt
Building.html background.gif
Building.class Lift
JavaDevices Devices
appletviewer.exe
23CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Deployment ViewDeployment Diagrams show the physical distribution of components over processors
Location of componentson nodes
server: BankServer
<<artifact>>Transaction.jar
<<database>>accountDB
update
client:ATMKiosk
<<artifact>>ATM-GUI.jar
Transaction
<<manifest>>
Use Case s Essentials 24
Use CasesThe Essentials
25CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
RequirementsRequirements specification :
•High-level description of what should be implemented
Importance of requirements :
•25% of the projects fail due to problems with requirements
Find out about requirements :
•Interview stakeholders to find out what they need system to do
A requirement may be a description of :
•What behaviour the system should offer
•A specific property of the system
•A constraint on the system
26CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Functional and Non-functional RequirementsFunctional Requirements :
•What the system should do
•“The ATM system shall provide a facility for authenticating the identity of a system user”
Non-functional Requirements :
•A constraint on how the functional requirements are implemented
•“The ATM system shall authenticate a customer in four seconds or less”
27CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
The glossaryThere is always a certain jargon in a business domain Project glossary captures the language of the domainThe aim of the glossary is :
•Define key terms
•Resolve synonyms and homonyms
Project Glossary Term1 Definition
Term2 Definition Term3 Definition
…
28CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
The system boundaryBefore we can build anything, we need to know :
•Where the boundary of the system lies
•Who or what uses the system
•What functions the system should offer
System boundary is identified in UML by a Use Case modelThe Use Case model contains :
•Actors – who or what uses the system
•Use Cases – things actors do with the system
•Relationships - between actors and use cases
29CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Use Case Diagram
30CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Characteristics Use Case Modeling
Use Case Modeling is OO-independent
There is no UML standard way of writing requirements!
31CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
ActorsAn actor is anything that interacts directly with the systemActors identify who or what uses the system Actors indicate where the system boundary liesActors are external to the systemAn Actor specifies a role that some external entity adopts when interfacing with the system
32CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Identifying ActorsWhen identifying actors ask :
•Who or what uses the system?
•What roles do they play in the interaction?
•What other systems use this system?
•Who gets and provides information to the system?
•Is there a dedicated time at which the system has to do something?
Actor symbol :
Visitor
33CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Use CasesA use case is something an actor wants to do with the system. It is a “case of use” of the system by a specific actorUse cases are always started by an actorUse cases are always written from the point of view of an actor
Use Case symbol :
Place order
34CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Steps in Use Case ModelingFind actors and use casesDetail a use case :•Specify the flow of events or scenario’s
•Specify pre- and postconditions
Structure the use case model : •Find relationships between use cases
•include•extend•generalization
35CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Use case specificationDeposit VAT
Preconditions :1. It is the end of a business quarter
Flow of events :1. The use case starts when it is the end of the business quarter.2. The system determines the amount of VAT owed to the government.
3. The system sends an electronic payment to the government.
Postconditions :1. The government receives the correct amount of VAT
Uses case name
System state before
the use case can begin
Actual steps of the use case
System state when the
use case is over
36CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Pre and postconditionsPreconditions and postconditions are constraintsPreconditions :
•Constrain the state of the system before the use case can start
Postconditions :
•Constrain the state of the system after the use case has executed
Place OrderPreconditions:1. A valid user has logged on to the system
Postconditions:1. The order has been markedconfirmed and is saved by the system
37CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
When to use use cases ?Use cases describe system behaviour from the point of
view of one or more actors. Use cases are the best choice when :
•System is dominated by functional requirements
•System has many types of users to which it delivers different functionality
Use cases are designed to capture functional requirements
Uses cases are a poor choice when :•The system is dominated by non-functional requirements
•The system has few users
•The system has few interfaces
Develop test plan using use cases
38CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Questions
Use Cases Advanced Concepts 39
Use Cases
Advanced concepts
40CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Use case specificationDeposit VAT
Preconditions :1. It is the end of a business quarter
Flow of events :1. The use case starts when it is the end of the business quarter.2. The system determines the amount of VAT owed to the government.
3. The system sends an electronic payment to the government.
Postconditions :1. The government receives the correct amount of VAT
Uses case name
System state before
the use case can begin
Actual steps of the use case
System state when the
use case is over
41CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Pre and postconditionsPreconditions and postconditions are constraintsPreconditions :•Constrain the state of the system before the use case
can startPostconditions :•Constrain the state of the system after the use case has
executed
Place OrderPreconditions:1. A valid user has logged on to thesystemPostconditions:1. The order has been markedconfirmed and is saved by the system
42CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Flow of eventsThe flow of events lists the steps in a use caseIt always begins by an actor doing somethingA good way to start a flow of events is :
•“1) The use case starts when an <actor> <function>”
Flow of events should be a sequence of short steps which are:
•Declarative, numbered, time ordered
Alternatives can be shown by branching or by listing under “Alternative paths”A good format for steps is :
•<number> The <something> <some action>
43CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Branching within a flow: IfUse the keyword if to indicate alternatives within the flow of eventsUse indentation and numbering to indicate the conditional part of the flow
View BasketFlow of Events:1. The use case starts when the customer selects “view basket”.2. The customer selects an item.3. The customer may delete an item from the basket, change the quantity of an item, exit “view basket” or proceed to checkout.4. If the user selects “delete item” 4.1. The item is removed from the basket5. If the customer types in a new quantity 5.1. The quantity of the item is updated6. If the customer selects…
44CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Alternative Paths are for things that can happen at any timeSection in use case specification for each alternative path with : •The flow of events for the alternative path
•postconditions for the alternative path (optional)
Flow of Events:Basic Path1. The use case starts when the customer selects “go to checkout”.2. The system displays the customer order.3. …Alternative Path 11. At any time the customer can select “cancel order” and the order is deleted from the system.Alternative Path 21. At any time, the customer can go back to shopping.
Branching: Alternative paths
Checkout
45CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Repetition within a flow: For
Use the keyword “For” to indicate the start of a repetition within the flow of eventsExpression immediately after “For” indicates the number of repetitions of the indented text beneath the “For” statement
Find a Product
Flow of Events:
1. The use case starts when the customer selects “find product”.
2. The customer enters a keyword and selects “find”.
3. For each product found
3.1. The system displays a thumbnail sketch of the product and the
customer selects one of the products.
4. The system displays full product details and a larger picture.
5. …
Find a Product
Flow of Events:
1. The use case starts when the customer selects “find product”.
2. The customer enters a keyword and selects “find”.
3. For each product found
3.1. The system displays a thumbnail sketch of the product and the
customer selects one of the products.
4. The system displays full product details and a larger picture.
5. …
46CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Repetition within flow: While
Use the keyword “While” to indicate that something repeats while some Boolean condition is true
Show Company Details
Flow of Events:
1. The use case starts when the customer selects “show company
details”.
2. While the customer is browsing the company details
2.1. The system plays some background music.
2.2. The system displays special offers in a banner at the top of
the page.
3. …
47CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Complex use casesTechniques up to now are fine for modeling average use casesHowever, when use cases are complex, and there are many branches within the flow of events, there is a better approach Scenarios
48CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
ScenariosOne specific path through a use case with no branchingEach use case has one primary scenario :•This is the “happy day” or “perfect world” path through the
flow
•Everything goes as expected and desired
•No errors, interrupts or branches
Each use case has many secondary scenarios :•Alternate paths through the flow
•Errors (exception scenarios)
•Interrupts to the main flow
49CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Primary scenarioUse the Primary Scenario as the use case flow of eventsList the Secondary Scenarios under a new sectionProvide a separate document for each secondary scenario
Checkout
Flow of Events:
Primary Scenario
1. The use case starts when the customer selects “go to checkout”.
2. The system displays the customer order.
3. The customer enters a valid customer number.
4. The system retrieves and displays customer information.
…
Secondary Scenarios
Invalid Customer Number.
Invalid Credit Card Details.
Credit Card Expired.
50CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Secondary scenariosOne specific path through flow of events with no branchingAlways state how the scenario begins
Checkout Secondary Scenario:
Invalid Customer Number
Flow of Events :
1. The scenario begins in step 3 of the use case “Checkout” when the customer enters an invalid customer number.
2. For three invalid entries
2.1. Prompt the customer to enter their customer number again
3. The system asks the customer to enter new customer details
4. The customer enters new customer details.
5. The system generates a new customer number
6. …
51CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Finding Secondary Scenarios
Identify the Primary ScenariosExamine each step in the Primary Scenario and look for :•Alternative flows
•Errors (exception scenarios)
•Interrupts – something that could happen at any time
52CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
How many scenarios?There is one Primary Scenario per use caseThere may be many secondary scenarios per use case It would take far too long to document them all :
•Pick the most important ones to document
Often there are groups of similar secondary scenarios :
•Document one of these as an exemplar
•Add notes to this explaining how the others differ from it
53CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Structuring the Use Case Model
Structure the Use Case Model by exploring relationships :
•Actor generalisation
•Use case generalisation
•«include» – between use cases
•«extend» – between use cases
54CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Actor Generalisation
Sales agentCustomer
Order productsPurchaser
Sales system
Calculate commission
Accept payment
List products
55CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Actor generalisation semanticsActors communicate with same set of use cases in same way :
•Express this as generalisation to another (possibly abstract) actor
Descendent actors inherit from ancestor actor :
•Roles and relationships to use cases held by the ancestor actor
Substitutability principle :
•We can substitute a descendent actor anywhere the ancestor actor is expected
56CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Use Case Generalisation
Verify User
User Check BiometricsCheck Password
Security System
57CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Use case generalisation semanticsChild use cases represent more specific forms of the parentThe children inherit from their parent :
•Preconditions, Flow of Events, Postconditions
•Relationships
The children may add new features :
•New steps in the flow of events
•New preconditions and postconditions
•New relationships
58CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
<<include>>
Manager
Find Employee
Details
Personnel System
Change Employee
Details
View Employee
Details
Delete Employee
Details
<<include>>
<<include>>
<<include>>
59CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Clients include supplier behaviourChange employee details
Preconditions:
1. A valid manager is
logged on to the system
Flow of events:
1. The manager enters the
employee’s ID number.
2. include (Find Employee
Details).
3. The manager selects
part of the employee
details to change.
4. …
View employee details
Preconditions:
1. A valid manager is
logged on to the system
Flow of events:
1. The manager enters the
employee’s ID number.
2. include (Find Employee
Details).
3. The system displays the
employee details.
4. …
Delete employee details
Preconditions:
1. A valid manager is
logged on to the system
Flow of events:
1. The manager enters the
employee’s ID number.
2. include (Find Employee
Details).
3. The system displays the
employee details.
4. The manager deletes the
employee details.
5.
60CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
«include» semantics«include» works as follows :
•The client use case executes until the point of inclusion include(X)
•Control passes to the supplier use case which executes
•When the supplier is finished, control passes back to the client use case which finishes execution
Client use cases are incomplete without the included supplier use casesSupplier use cases may be complete use cases, or they may just specify a fragment of behaviour for inclusion elsewhere
61CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
<<extend>>
62CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
«extend» semantics«extend» is a way of adding new behaviour to base use case by inserting behaviour from one or more extension use casesBase use case specifies extension points in its flow of events :
•Base use case does not know about the extension use cases
•Remains unchanged as new extension use cases are added
Extension use case may contain several insertion segmentsThe «extend» relationship specifies which of the base use case extension points it is extending
63CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Base use case
Return bookPreconditions:
1. A valid librarian is logged on to the system
Flow of events:
1. The librarian enters the borrowers ID number
2. The system displays the borrower details including the list of borrowed books
3. The librarian finds the book to be returned in the list.
<borrow date determined>
4. The librarian returns the book.
5. …
64CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
«include» and «extend»«include» is used where we want to reuse the same behaviour again and again in many different use cases«extend» is used when we want to modify an existing use case by inserting some new behaviour at named extension pointsExtend also allows us to reuse behaviour fragments, but in a more flexible way
Interaction Diagram 65
Class Diagrams
The Essentials
66CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Class diagramsModels the static design view of the system :•Involves modelling vocabulary of the system•Involves modelling collaborations in the system
Class diagrams show :•Classes•Interfaces•Relationships between classes•Constraints
Adorned by navigational and multiplicity information
•Further described by the rules on the classes and associations
The class diagram shows the first formal definition of a class
•Leads to specification of abstract data types, that can be used by the software engineer.
67CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Class diagram
Floor
floorNumber : int
LiftCage
*RequestToServiceFloor
0..1 IsAt
*
*
68CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Classes and objects in UML
simple name
path name
An object icon has the object name underlined
A class icon has compartments for attributes and operations
Customer
java::awt::Circle
splashScreen: Window
+open()+close()+move()+display()
-origin-size
Window
69CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Attributes
An attribute is a property of a classAt a given moment an object of a class will have specific values for every one of its class’s attributesIn the attribute compartment attributes can
•Be of different types
•Have different visibility : + for public, - for private, underlined for class
scope (static)
70CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
OperationsAn operation is the implementation of a service.Invoking an operation can change the data and the state of the objectIn the operation compartment operations can•Be described with return type and parameters, signature
•+ for public, - for private
•underlined for class scope (static operation)
•Operations are applied to objects of a class
•Operations are also called functions
•Operations describe what service a class offersFormat for operations name (parameter-list) : return-type-expr
Each parameter is specified with : name : type-expr = value
Specifying value is optional
71CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Attributes and operations example
72CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Class relationshipsClasses will in general have relations with other classes•Objects may have other objects as parts
•Objects may be associated to other objectsThree different kinds of relationships are the most important•Generalization
•Specialized classes inherit from more generalized classes in a subclass/superclass or parent/child relationship
•Association•A structural relationship between instances of classes
•Dependency•Using relationship, one instance of a class depends on an instance of another class
There may be constraints on class relations :•Multiplicities are constraints
•A LiftCage may have 12 FloorRequestButtons
73CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Types of class relationshipsAssociation
•Is a connection between classes
•An instantiation of association is a link (between objects)
Generalization
•A specialised subclass is derived from a superclass
•Shows that a subclass shares the structure and/or behavior defined in the superclass
Dependency
•The client class depends on the supplier class to provide services
•Services include accessing attributes, operations or using types
Realization
•A relationship between classes or components and interfaces
•An interface is a set of well-defined functions and their signatures
•Shows how a class realizes operations offered by the interface
74CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
relationshipsAssociation
Adornments
Navigable association
Aggregation
Composition
Generalization
Dependency
Realization
75CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Association, role, multiplicity
CompanyPerson Works for
association name
employee employer
1..* *
role name
multiplicity
76CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Multiplicity
Multiplicity is defined as•Specification of a range of allowable cardinalities that a set
may assume
Multiplicity has meaning for associations•It indicates how may objects relate to how many other objects
Multiplicity info is indicated ‘at the end’ of an association.single integer : 1 [exactly one]range : 0 .. 1 [zero or one]
: 2 .. 4 [two, three or four]range : 1 .. * / 1..n [one or more]single star : * (= 0 .. *) [zero or more]
77CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Navigation
User Password
navigable association
*
78CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Generalization/specializationGeneralization is a special kind of relationship
• The ‘is-a’ or ‘is a kind of’ relationshipGeneralization is called generalization/specialization An example is the relationship between a car and a
truck :•A car is a specialization of a vehicle
•A vehicle is a generalization of of a carIn the design phase it is also called inheritance
relationship •A car has all properties of a vehicle and possibly
more
•A car inherits from a vehicle
79CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Generalization/specialization example Vehicle
Truck Car
Driver
RacingCar Taxi
Trailer
80CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Multiple inheritance
Classes may have more then one base class
Avoid multiple inheritance in the analysis :•May introduce problems in the design or programming
phase
If necessary use interfaces
81CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
AggregationA special kind of association is a “has a” (containment) relationship•Models the whole-part relation
•Object of the whole has objects of the part
Simple (weak) aggregation•Whole ‘controls’ parts
Composition (strong aggregation)•Whole consists of parts
82CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Aggregation examples
83CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
When to use class diagrams?
Always
To model static structure of system
There is one class diagram describing the structure
Don’t go to implementation details too early.
Interaction Diagrams 84
Interaction Diagrams
85CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Object Interaction Diagrams
An object interaction diagram shows two aspects •Which objects and messages are involved in the
interaction
•How objects and messages are involved in the interaction
A Use Case is realised through a pattern of interactions Interaction models show how a Use Case (or part of it) is realisedUsually one interaction diagram for each scenario in the Use Case
86CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Sequence diagram
Illustrates how objects interact with each other•The focus is on message sequences
Reveals an interaction for a specific scenario•It shows specific interaction between objects at some
point in time Two axes present in sequence diagram•The vertical axis shows time
•The horizontal axis shows a set of objectsThe objects are represented by•An object rectangle
•A dashed line representing the object lifelineShows communication between objects•As horizontal message lines between object’s lifelines
87CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Sequence diagram
Object and timeline :
88CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Sequence diagram sample
89CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Analyze flows of control and time ordering
To further model a flow of control and time ordering on a sequence diagram:•Set the context of interaction
•Identify the objects which play a role in the interaction
•Set the lifeline for each object
•Lay out the messages showing their properties (parameters)
•Adorn each object’s lifeline with its focus of control (optional)
•Adorn each message with a timing mark and attach time or space constraints (optional)
•Attach pre- and post-conditions to each message (optional)
90CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Frames
•new since UML 2.0
•graphical boundary of a diagram
•basis for many diagram elements
91CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Sequence Diagram References
reference to sequence digram
92CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Sequence Diagram References
93CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Alternative (no messages)
optional element (‘if without else’)
94CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Loops / conditionals
loop
loop condition
nested conditional
alternate branches
guard conditon
95CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Order and timing constraints on sequence diagrams
caller: Phone exchange: PBX
lift receiver
dial tone
dial digit
route
ringing tone
stop tone
a
b
c
d
d’
{7 am< a < 7 pm}
{< 1 sec}
{< 10 sec}
{d - d’ < 5 sec}
...
duration constraint
message with duration
duration constraint expression
96CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
When to use sequence diagrams?For each use case
They show interaction between objects to realize use case.
Alternative: communication diagram
97CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Interaction overview diagram
decisioninteractionuse
fork
join
refaccept admission
refdecline admission
register
student registrar
sd
apply
student housing
sd
pay
student cashier
sd
exclude
student registrar
sd
intover
98CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Communication Diagram
A communication diagram basically only shows relations between objects that are involved in the realisation of a Use-case.
If needed the sequence of messages can be specified using sequence number, but information about parallelism, timing and timing requirements are not shown as a specific dimension
Useful when the emphasis is more on the static structure, which objects are involved in this interaction
99CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Communication diagram
100CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
When to use communication diagram?
For each use case
Shows interaction between objects to realize use case.
Alternative: sequence diagram
101
Class Diagrams
Advanced Concepts
102CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Recursive Association
103CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Association Class
104CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Examples aggregation and association
OpenableCouple
Floor
floorNumber : int
2
LiftRequestButton
FloorDoor CageDoor
0..10..1
8
Floor
floorNumber : int
2
LiftRequestButton
FloorDoor CageDoor
0..10..1
8
105CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Examples aggregation and association
106CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Composition
Strong form of aggregation is called composition in UML Composition characteristics :•Part lives only and as long as the whole lives
•Lifetimes of of whole and part are the same
•Part is owned by exactly one whole
•Multiplicity is one on the whole side
Example of simple aggregation versus composition :•School has teachers is aggregation
•School has classrooms is composition
107CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Qualified Associations
target class
association relation without qualification
qualified classqualifier
Multiplicity after
qualification
108CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Parameterised classesGeneric class of which actual class not known until runtime:
•Generic class has one or more formal parameters
•Actual class is parameter when generic class is instantiated
•Synonym: template class
Typical use of parameterized classes are containers
Generic container class Set with formal class T as argument:
•Actual class Car can be bound to T at run time by Set <Car>
•Each of the Set<Car> objects will represent set of cars
109CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Parameterised class example
explicit binding
implicit bindingclass with an anonymous name
110CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Interfaces
Interface described by set of abstract operations Class, package or component connected to interface :
• Implements or supports specific interface
Interface represents contract that is implemented by object:
Programming equivalents are COM en java interfacesComponent can choose to implement interface
111CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Interfaces: representation
supplier and client
full interface
required interface
provided interface
112CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
RealizationSemantic relationship between classifiers :
•One classifier specifies a contract
•Another classifier guarantees to carry it out
Relationship often used in combination with interfaces :
•Interfaces specify a contract for a class
•Interfaces do not dictate any implementation
Class may realize many interfaces :
•Class provides methods of the interface with implementation
113CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Realization example
114CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Constraints
Restrictions on usage or semantics of element
Example is association between Person and Group :
•Limit membership group on age attribute
Number of pre-described constraints available
115CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Constraints
{ordered}
Constraint ordered means that the links ({LiftCage, FloorRequestButton} instances) are ordered. The FloorRequestButtons are positioned in order in the LiftCage
Example: Ordered association
116CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
ConstraintsSpecify conditions that must be true for a well formed model :
•Value constraints on class attributes
•Pre-postconditions and invariants
Constraint modeling in UML :
•Free-form text between brackets
•More formally described by OCL (object constraint language)
A number of constraints are predefined in UML
117CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
DependenciesA modelelement A is dependant of modelelement B means that, when the interface of B changes, also A has to change.
Most common dependency.•One class uses another class as a parameter for an
operation.
•Modeled by drawing a dependency to the class used as parameter.
•It is also possible to use a class as return type of an operation.
118CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Dependency example
119CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede
Dependency stereotypes
Classes and objects •access•bind•call•create•derive•instantiate•permit•realize•refine•send•substitute•trace•use
Packages•access•import
Use Cases•extend•include