CII Saxion Hogeschool Enschede 1 Object georiënteerd Ontwerpen met UML Saxion Hogeschool Enschede,...

1CII Saxion Hogeschool EnschedeCII Saxion Hogeschool Enschede

Object georiënteerd Ontwerpen met UML

Saxion Hogeschool Enschede, januari 2005

UML Overview 2

UML Overview


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."


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


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)


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


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


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


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


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


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


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..


UML Diagrams

Static ViewDynamic View

Implementationstructure

Object interaction

Logical structure

Use CaseDiagramsUse Case

DiagramsUse CaseDiagrams


DiagramsUse CaseDiagrams

ScenarioDiagramsScenario

DiagramsDiagrams


DiagramsCommunicationDiagrams

StateDiagramsState

DiagramsComponentDiagrams

StateDiagramsState

DiagramsComponentDiagrams

ComponentDiagramsComponent

DiagramsDeploymentDiagrams

ComponentDiagramsComponent

DiagramsDeploymentDiagrams

StateDiagramsState

DiagramsCollaborationDiagrams

StateDiagramsState

DiagramsCollaborationDiagrams


DiagramsActivityDiagrams


DiagramsActivityDiagrams


DiagramsSequenceDiagrams


DiagramsSequenceDiagrams

StateDiagramsState

DiagramsClassDiagrams

StateDiagramsState

DiagramsClassDiagrams

State machineDiagrams

Models


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.


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.


Views

Major Area View Diagram

structural static view class diagram

design view internal structure

collaboration diagram

component diagram

use case view

use case diagram


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


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


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)


: Person

upButton : LiftCagefloorRequestButton: Door

press( )

doorIsClosed ()

press()visit(j)

close()

pass

pass

visit(i)

open( )atFloor(i)

atFloor(j)open( )

Lift model (behavior)

: Person


press( )

doorIsClosed ()

press()visit(j)

close()

pass

pass

visit(i)

open( )atFloor(i)

atFloor(j)open( )

: Person


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


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


Closed

open()

stopClosing()

Open

close()


Opening

do: opening()

Closing


Closed

open()

stopClosing()

Open

close()


Door model(behavior)

DoorButton Chime

sound()

Door

FloorRequestButton

Shaft

LiftCage

22 111010

11

DoorButton Chime

sound()

Door

FloorRequestButton

Shaft

LiftCage

22 111010

11


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


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


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


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”


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

…


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


Use Case Diagram


Characteristics Use Case Modeling

Use Case Modeling is OO-independent

There is no UML standard way of writing requirements!


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


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


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


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


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


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


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


Questions

Use Cases Advanced Concepts 39

Use Cases

Advanced concepts


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


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


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>


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…


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


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. …


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. …


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


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


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.


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. …


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


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


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


Actor Generalisation

Sales agentCustomer

Order productsPurchaser

Sales system

Calculate commission

Accept payment

List products


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


Use Case Generalisation

Verify User

User Check BiometricsCheck Password

Security System


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


<<include>>

Manager

Find Employee

Details

Personnel System

Change Employee

Details

View Employee

Details

Delete Employee

Details

<<include>>

<<include>>

<<include>>


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:



Flow of events:




Details).

3. The system displays the

employee details.

4. …

Delete employee details

Preconditions:



Flow of events:




Details).

3. The system displays the

employee details.

4. The manager deletes the

employee details.

5.


«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


<<extend>>


«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


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. …


«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


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.


Class diagram

Floor

floorNumber : int

LiftCage

*RequestToServiceFloor

0..1 IsAt

*

*


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


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)


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


Attributes and operations example


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


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


relationshipsAssociation

Adornments

Navigable association

Aggregation

Composition

Generalization

Dependency

Realization


Association, role, multiplicity

CompanyPerson Works for

association name

employee employer

1..* *

role name

multiplicity


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]


Navigation

User Password

navigable association

*


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


Generalization/specialization example Vehicle

Truck Car

Driver

RacingCar Taxi

Trailer


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


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


Aggregation examples


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


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


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


Sequence diagram

Object and timeline :


Sequence diagram sample


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)


Frames

•new since UML 2.0

•graphical boundary of a diagram

•basis for many diagram elements


Sequence Diagram References

reference to sequence digram


Sequence Diagram References


Alternative (no messages)

optional element (‘if without else’)


Loops / conditionals

loop

loop condition

nested conditional

alternate branches

guard conditon


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


When to use sequence diagrams?For each use case

They show interaction between objects to realize use case.

Alternative: communication diagram


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


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


Communication diagram


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


Recursive Association


Association Class


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


Examples aggregation and association


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


Qualified Associations

target class

association relation without qualification

qualified classqualifier

Multiplicity after

qualification


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


Parameterised class example

explicit binding

implicit bindingclass with an anonymous name


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


Interfaces: representation

supplier and client

full interface

required interface

provided interface


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


Realization example


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


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


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


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.


Dependency example


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

CII Saxion Hogeschool Enschede 1 Object georiënteerd Ontwerpen met UML Saxion Hogeschool Enschede,...

Documents

Transcript of CII Saxion Hogeschool Enschede 1 Object georiënteerd Ontwerpen met UML Saxion Hogeschool Enschede,...