uml - ida > hometddc93/timetable/5uml-1.pdf · 2008. 9. 1. · uml lecture 5 kristian sandahl and...

UML

Lecture 5

Kristian Sandahl and David Broman

Department of Computer and Information Science

Linköping University, Sweden

[email protected]

Software Engineering

TDDC88/TDDC93

Autumn 2008

2

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III

Other useful diagrams

A Software Life-cycle Model

Which part will we talk about today?

Requirements

System Design(Architecture,

High-level Design)

Module Design(Program Design,

Detailed Design)

Implementationof Units (classes, procedures,

functions)

Unit testing

Module Testing(Integration testing of units)

System Testing(Integration testing of modules)

Acceptance Test(Release testing)

Validate Requirements, Verify Specification

Verify System Design

Verify Module Design

Verify Implementation

Project Management, Software Quality Assurance (SQA), Supporting Tools, Education

Maintenance

3

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Agenda - What will you learn today?

Part II

Class Diagrams - Advanced Concepts

Part I

More on use-cases

Part III


CoffeDrinker

TeaDrinker

Service

Porter

Buy a cup of

coffe

Get coin inreturn

Pour hot water

Clean the

Machine

Brew a can of coffee

CoffeeMachine

Add substances

Collect coins

Subject

boundary

4

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Part I

More on use-cases

5

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Goal of Requirements analysis

� Detect and resolve conflicts btwn requirements

� Discover bounds of software

� Define interaction with the environment

� Elaborate high-level requirements to derive detailed

requirements

6

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Use-case in analysis

� Find all actors

� Describe their major use-cases

� Draw a diagram

7

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Use-case diagram for the coffee-machine

CoffeDrinker

TeaDrinker

Service

Porter

Buy a cup of

coffe

Get coin in

return

Pour hot water

Clean the

Machine

Brew a can of

coffee

CoffeeMachine

Add substances

Collect coins

Subject

boundary

Subject Subjectname

8

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III



� Find all actors


� Draw a diagram

� Complete with texts describing the beginning, major

flow of actions and the end – shall be understandable

� Make a noun analysis – create a basic class model

9

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Identifying classes: noun analysis

•machine – real noun handled

by the system

•cup – unit for beverage

•coin – detail of user and machine

•shelf – detail of machine

•pipe – detail of machine

•button– handled by the system

•sugar – detail of coffee

•whitener – detail of coffee

•cup of coffee – handled by the

system

•indicator – not discovered

A CoffeeDrinker approaches the machine

with his cup and a coin of SEK 5. He

places the cup on the shelf just under the

pipe. He then inserts the coin, and press

the button for coffee to get coffee

according to default settings. Optionally

he might use other buttons to adjust the

strength and decide to add sugar and/or

whitener. The machine processes the

coffee and bell when it is ready. The

CoffeeDrinker takes his cup from the shelf.

10

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


The coffee machine class model

CoffeeCustomer

Porter

CupOfCoffee

CanOfCoffee

buys

byus

0..1

0..1

0..*

0..*

makes

makes

machine

11

1 11

1

1

1

0..*

0..*

Interface CoinHandler Brewer

Even small models

take space. You need

good drawing tools

and lagre sheet.

Even small models

take space. You need

good drawing tools

and lagre sheet.

11

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III



� Find all actors


� Draw a diagram

� Complete with texts describing the beginning, major

flow of actions and the end – shall be understandable

� Make a noun analysis – create a basic class model

� Document this in an artifact – Use-case model

12

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Vision of a use-case document

CoffeeCustomer

Porter

CupOfCoffee

CanOfCoffee

buys

byus

0..1

0..1

0..*

0..*

makes

makes

machine

1

1

1

1

1

1

1

1

0..*

0..*

Interface

CoinHandler

Brewer

CoffeDrinker

TeaDrinker

Service

Porter

Buy a cup ofcoffe

Get coin inreturn

Pour hot water

Clean theMachine

Brewa can of coffee

CoffeeMachine

Add substances

Collect coins

Subjectboundary

Use-case texts

Vocabulary:

Classes

Map: Use-cases

Suggestion:

Max 40 pages

Good overview

Understandable

Connects to customer needs

13

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Use-case generalization

Pay coffee

Pay with card

Please, keep as

simple as possible.

Please, keep as

simple as possible.

parent use-case

Pay with coins

child use-case

use-case generalisation“is_a”

14

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Relations between use-cases

Clean the

machine

Collect coins

Open machine

Service

Add change

Stereotype: extended

classification of meaning

”Separating scenarious”

(often conditional)

”Reuse”

Please, keep as

simple as possible.

Please, keep as

simple as possible.

base use-case

extension use-case

inclusion use-case

15

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Open up the use-case Please, keep as simple as possible.

Please, keep as

simple as possible.

Extension point

16

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Specification of requirements

� Continue with a written specification or database

� Link to the use-cases

17

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Alternative1: continue with use-cases

� Get the benefits from modelling

� Less ambiguity

� Possible to generate code

� Better traceability

� Sometimes easier to change

� Sometimes easer to understand

� Textual requirements are few

� Example from OpenUP/Basic:

� http://www.ida.liu.se/~TDDC93/timetable/use_case_s

pec_withdraw_cash.pdf

18

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Part II

Class Diagrams - Advanced Concepts

David’s wondeful animations

19

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Class Repetition from last lecture

Class name

attributes

operations

visibility

+ public

- private

# protected

~ package

Multiplicity

1 exactly one

0..1 Zero or one

* Zero or more

(same as 0..*)

2..8 Between 2 and 8

Return typeParameter

20

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Relationships (1/6) - overview and intuition

- Association

Association(with navigability)

21

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III



- Association

attributes Both representations are

almost equivalent

directed association

role name

{ordered} {unordered}

{unique}{nonunique}

Default is unordered,

unique

22

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III



- Association

wheel1

wheel2

wheel3

wheel4mycar

4class

objects

mycar has links to 4

wheels

Navigation - mycar can reach the

wheels, but not the oppositeExplicitly show that navigation

is not allowed

23

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III



- Association

wheel1

mycar1

4

What does it mean to have a * here? What if we have multiplicity 1 instead?

mycar2

wheel2 wheel3 wheel4

mycar3

A wheel can be linked to more

than one car instance wheel1

mycar1


mycar2A wheel can only be liked

to one car instance

"*" "1"

24

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III



- Association

wheel1

mycar1

4


Associations are the "glue" that ties a system together

association instance = link

An association describes a relation between

objects at run-time.

{(mycar1,wheel1),

(mycar1,wheel2),

(mycar1,wheel3),

(mycar1,wheel4)}

25

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III



- Aggregation


"A" has a reference(s) to

instance(s) of "B". Alternative: attributes

Aggregation

26

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III



- Aggregation

4

A major source of confusion

Common vague interpretations: "owns a" or "part of"

What does this mean? What is the

difference to association?

Vague definitions Inconsistency and misunderstandings

Aggregation was added to UML with

little semantics. Why?

Jim Rumbaugh

"Think of it as a modeling placebo"

Recommendation: - Do not use it in your models.

- If you see it in other's models, ask them what they actually mean.

27

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III



- Composition




Aggregation

Composition

Avoid it to avoid misunderstandings

28

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III



- Composition

4

Any difference to association?

Yes! First, multiplicity must be 1 or 0..1. An instance can only have one owner.

1

41

But, isn't this equivalent to what we

showed with associations?

Well, in this case...

wheel1

mycar1


mycar2

29

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III



- Composition

41 2 1

wheel1 wheel2 wheel3 wheel4

mycar1

Using composition...

wheel5 wheel6

mybike1

Ok for wheels to be part of

mycar1 or mybike1

30

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III



- Composition

41 2 1


mycar1

Using composition...

wheel5 wheel6

mybike1

Can mycar1 and mybike1

share the same wheels?

NO!

Not with composition!

Key concepts

• "No sharing" rule

• The owner is responsible for managing

its parts, e.g. allocation and deallocation.

31

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III



- Composition

41 2 1


mycar1

Using associations...

wheel5 wheel6

mybike1

Can mycar1 and mybike1 share

the same wheels this time?

Yes! Associations do not

have a "no sharing"

rule.

(Note the difference. The diamond is removed.)

However, in this case it is a

strange model...

32

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III



- Generalization




Aggregation

Composition


An instance of "B" is part of an instance of "A",

where the former is not allowed to be shared.

Generalization

33

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Relationships - (4/6) overview and intuition

- Generalization

Class with code for

the drive()

operation

Inherits the code for

drive(). New

operation reverse()

+ drive()

MotorCycle

Overrides drive()

1. Inheritance

~ relation implementation

2. Subtyping

~ relation on interfaces

Visible Type: Vehicle.

Instance of: MotorCycle.

Can we drive()? Can we reverse()?

An instance of a class can have many types

= (subtyping) polymorphism

Visible Type: Vehicle.

Instance of: Car


Visible Type: Car.

Instance of: Car


reverse() is not visible!

static typing: safe substitution

34

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III



- Realization




Aggregation

Composition




1) "A" inherits all properties and operations of "B".

2) An instance of "A" can be used where a

instance of "B" is expected.

Generalization

Realization

35

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III



- Realization

Realization

Realization

~ provides a specified interface

Implementation

Specifier

Correct?Must implement

the interface

Interface

(no implementation)

Provides the Door

interface

Can we create an instance of

Vehicle? Yes! It is concrete.

+ drive()

+ open()

AnotherVehicle

Can we create an instance of

AnotherVehicle?

Abstract class (Italic)

Abstract operation

No!

36

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III



- Realization

What is the difference between an

interface and an abstract class?

+ drive()

+ open()

AnotherVehicle

Abstract class

+ open()

Door

Interface

Non of them can be instantiated

Cannot contain implementationCan (but need not to) contain

implementation

An abstract class with only abstract operations is conceptually the same as an interface

37

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III



- Realization




Aggregation

Composition







Generalization

Realization"A" provides an implementation of the interface

specified by "B".

Dependency

38

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III



- Dependency

Dependency

supplierclient

39

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III



- Dependency

UML as sketch

UML as blueprint

UML as programming language

� Help to communicate some important aspect of system

� Common media: whiteboard

� In documents: focus on communication compared to

completeness

UML

model

Programming

Code

Forward engineering

Reverse engineering

Round-trip engineering

UML

modelCompile Executable

Code

Reverse engineering can be very

useful to see dependencies

between classes and modules!

40

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Relationships - overview and intuition




Aggregation

Composition







Generalization

Realization"A" provides an implementation of the interface

specified by "B".

"A" is dependent on "B" if changes in the

definition of "B" causes changes of "A".Dependency

41

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Part III


42

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Interfaces

PrinterServer

required interfaceprovided interface

TransmittDataSubmitJob

CheckStatus

43

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Component diagram with interfaces

Dictionary

spell-check

supplement

Older notation:

Alternative notation:

44

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Artifacts

� Components describe modular parts of the system

with well-defined interfaces

� Artifacts are the pieces of information produced by

software development

PurchaseOrder

PurchaseOrder.jar

45

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Collaboration

� Provides a focused view of how instances of classes

may collaborate to achieve something, for example, a

use-case

buyer: Company seller: Companygoods: Goods

Goods salerole name

type connector

46

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Structured classifier

Car

left: Wheel [2] right: Wheel [2]axle

1 1

part name class name

connector

multiplicity

47

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Structured classifier with port

Car

electronics receiver

mechanics

Signal

Signal

Open the door with remote control

port

Antenna

48

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Deployment diagram

august: Workstation lotta: PC

hardware

49

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


State machine diagram

checking idlefalseCoin()/returnCoin(self)

insertCoin()/checkCoin(self)

For class

CoinHandler: start state marker

state trigger event,

causing transitionaction, reaction

to the event

transitonthis object

50

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Orthogonal, composite state

Lab 1 Lab 2lab1 done

Project

lab2 done

project done

Final exampass

studying

Failed Passedfail

course attempt state machine

orthogonal state

orthogonal region

51

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Explicit exit points

Lab 1 Lab 2lab1 done

Project

lab2 done

project done

Final exampass

studying

failed passed

fail

course attempt

52

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Interaction view

Interaction diagram

Communication

diagramSequence diagram

53

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Sequence diagram

: CoffeeCustomer

: Interface

insertCoin

machineReady

pressButton(b1)

pourCoffeetime

Life line

of object

Message

role

Procedure

is active

The second alternative

to proceed from use-case

analysis

54

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Sequence diagram

with several objects

: CoffeeCustomer

: Interface : CoinHandler : Brewer

insertCoin transportA

C

{C-A < 5s}coinAccepted warmUp

litIndicators

pressButton(b1)makeOrder(o1)

pourCoffeepourCoffee

55

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Communication diagram

: CoffeeCustomer

: Interface

: CoinHandler : Brewer

1: insertCoin

2: transport4: coinAccepted

3: warmUp

5: litIndicators

6: pressButton(b1)

7: makeOrder(o1) 8: pourCoffee9: pourCoffee

Sequence nr Message flow

Role

56

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Combining fragments of interaction diagrams

:Order :TicketDB :Account

SD processOrder

create

Get existing customer dataref

loop

[get next item]

reserve(date,no)

add(seats)

destruction

answer

loop condition

loop

57

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


More fragments of interaction diagrams

:Order :TicketDB

loop

[get next item]

reserve(date,no)

add(seats)

reject

alt [available]

[unavailable]

nested conditional

alternate branches

guard condition

58

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Activity diagram

insert coin

brew coffeeadd hot water

to adjust strength

pour coffee

coin accepted? [no]decision

fork

add sugar/whitener

join

Initial node

final

node

[yes]

59

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Partitions and object flows

Customer Sales Stockroom

Request service Order [placed]

Take orderOrder [entered]

Fill orderOrder [filled]

Deliver order

Order [delivered]

Collect Order

Pay

Partition (swimline)

Object flow

Classstate

60

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


Other features…

� Comments

� Constraints in OCL (Object Constraint Language)

� Profiles: Collections of stereotypes for specific domains, e.g.

Realtime-profile for UML

� Customize (specialize) UML elements, e.g. associations

� Can introduce own symbols

� MOF (Meta-Object Facility):

� UML is specified in UML

� Powerful mechanism for extending UML by adding new language

elements

61

Part I

More on use-cases

Kristian Sandahl

[email protected]

Part II

Class Diagrams -

Advanced Concepts

Part III


UML Summary

� UML – the standard for modeling software

� Modeling before/during design, precedes coding

� Different diagrams for different views

� Model a software system only partially,focus on a certain aspect and/or part at a time

� Problem: Maintaining consistency across diagrams

� Tools

� Trend towards more detailed modeling

� Stepwise refinement

� ”executable UML”: UML 2 is almost a programming language…

� UML is customizable and extendible: Profiles, MOF

� Trend towards automatized partial generation of models and code from models(MDA – model-driven architecture)

uml - ida > hometddc93/timetable/5uml-1.pdf · 2008. 9. 1. · uml lecture 5 kristian sandahl and...

Documents