1 Tony Busker Object Oriented Software Development 4.

17
1 Tony Busker Object Oriented Software Development 4

Transcript of 1 Tony Busker Object Oriented Software Development 4.

Page 1: 1 Tony Busker Object Oriented Software Development 4.

1

Tony Busker

Object Oriented Software Development 4

Page 2: 1 Tony Busker Object Oriented Software Development 4.

3

Design View

Design View

Process View

Process View

Deployment View

Deployment View

ImplementationView

ImplementationView

Use CaseView

Use CaseView

4+1 View Model of Architecture

Page 3: 1 Tony Busker Object Oriented Software Development 4.

4

Software Architecture (4+1 view)

Design View - vocabulary, functionalitywhich parts belong together?what are the components, and how are they related?

Process View - performance, scalability, throughputwhat threads of control are there?what synchronization must happen?

Implementation View - system assembly, configuration managementwhich parts are developed by the same team?what can be reused?

Deployment View - system topology, distribution, delivery, installationwhich parts will run in the same address space?

Page 4: 1 Tony Busker Object Oriented Software Development 4.

30

A scenario is a particular actor-system interaction corresponding to a use caseA scenario is a particular actor-system interaction corresponding to a use case

Scenario’s

Scenario modeling brings hidden requirements to the surface

Page 5: 1 Tony Busker Object Oriented Software Development 4.

31

Scenarios are message sequences among entities collaborating to produce system

behavior

Scenarios are message sequences among entities collaborating to produce system

behavior

Scenario’s

Collaboration diagrams

focus on relationships

Sequence diagrams

focus on time sequences

Two major scenario representations:

Page 6: 1 Tony Busker Object Oriented Software Development 4.

32

2.invokation

recursivecall lifeline

1: event

name

3: operation

A B

4: reply

Object Object actor

Sequence Diagrambasics

Page 7: 1 Tony Busker Object Oriented Software Development 4.

33

Sequence Diagram

Page 8: 1 Tony Busker Object Oriented Software Development 4.

34

Sequence diagram: example

Page 9: 1 Tony Busker Object Oriented Software Development 4.

35

Sequence diagram: example (2)

Page 10: 1 Tony Busker Object Oriented Software Development 4.

36

Sequence diagram: example (3)

Page 11: 1 Tony Busker Object Oriented Software Development 4.

37

Sequence diagram: example (4)

Page 12: 1 Tony Busker Object Oriented Software Development 4.

38

Sequence diagram: example (5)

Page 13: 1 Tony Busker Object Oriented Software Development 4.

39

2.a: [x>=0] create(x)

2.b: [x<0] callB(x)

recursivecall

entity destroys itself, and

returns to caller

lifeline

state1: event

actor statemarker

3: operation

4: operation

state

descriptivetext

b

a

{ b-a<10 ms }

timingconstraint

remarkscomponent

Periodic

Aperiodic

Synchronous operation call

Asynchronousoperation call

Signal(asynchronous)

Return from asynchronous call

Timed

Message stereotypes

fork

join

object

Sequence Diagram - extensions

Page 14: 1 Tony Busker Object Oriented Software Development 4.

40

Static Model

Dynamic Model

• Package diagram• Component diagram• Class diagram• Deployment diagram

• Sequence diagram• Collaboration diagram• Activity diagram• Statechart Diagram

Static & Dynamic modeling

Page 15: 1 Tony Busker Object Oriented Software Development 4.

41

Static Model

car boat

drive() drive()

person vehiclecolor

drive()

drivesengine

Class Diagram

Page 16: 1 Tony Busker Object Oriented Software Development 4.

42

Sequence Diagram

Dynamic Model

:Computer :PrinterServer :Printer

Print (file)[no queue]print (file)

Print (file)

return

synchronousmessage

guard condition

objects

activation

lifeline

Page 17: 1 Tony Busker Object Oriented Software Development 4.

43

The perfect diagram ?

There is no such thing as a perfect class or a perfect UML diagram

Crafting good abstractions is difficult. Don’t try to find the perfect abstraction. Continually improve your abstractions as you learn more about the problem you are trying to solve.

class