Vous êtes sur la page 1sur 32

Collaboration Diagrams

CollaborationDiagrams
Dumitru Radoiu
DumitruRadoiu
Spring2009
PETRU MAIOR UNIVERSITY

Object-Oriented World

time

OO Analysis

Create the
vocabulary

Requirements

OO Design

Give
vocabulary
ocabu a y
behavior
(model the
system)

OO Programming

Program the
model
ode

Deliverables

Activity

UMLDiagram

Understand SystemUsage

UseCaseDiagram

Identify Classes
IdentifyClasses

High Level Class Diagram 9


HighLevelClassDiagram

DefineWorkflows

ActivityDiagram

Use Case Model

diagnose car

Mechanic

fix car

drive car

Car owner

Use case

di
diagnose
car
Mechanic

High Level Class Diagram

[talk]

Car

Diagnosis
Mechanic

0..1
uses>
1

:Diagnosis

1
diagnosis>
0..1

:Mechanic
1

:Car

fixes>
0..1

Activity Diagram
Start

Turn
Offof
Diagnosis
Name
State
Diagnosis
equipment
problem
[error]
Display
Name ofError
State

Turn
NameOn
of Diagnosis
State
[valid]

Car electronic
problem
[error]

Turn On
Name
of Car
State
[valid]

Turn
OffofCar
Name
State

Fix Problem

Name of State

Diagnose

Name of State

Object-Oriented World

time

OO Design

OO Analysis

Create the
vocabulary

Requirements

Give
vocabulary
ocabu a y
behavior
(model the
system)

OO Programming

Program the
model
ode

Deliverables

A ti it
Activity

UML Di
UMLDiagram

Identifyinteractions
amongobjects

9
Sequenceand
CollaborationDiagrams9

Analyzestatechanges
l
h

SateDiagrams

Refineclassdiagrams

ClassDiagrams

Sequence Diagram
[talk]

Car

Diagnosis
Mechanic

Car

Diagnosis
Mechanic

Turn On

Turn On

Set to check

Diagnose

Fix the problem


Turn Off
Turn Off

Agenda

WhyWeModelCollaborationDiagrams
Why
We Model Collaboration Diagrams
Notation
DifferentTypesofMessages
ModelaCollaborationDiagram:CaseStudy

High Level Class Diagram

0..1

:Diagnosis

1
diagnosis>

uses>
0..1

:Car

:Mechanic
1

fixes>

0..1

Sequence Diagram

Car

Diagnosis
Mechanic

Turn On

Turn On

Set to check

Diagnose

Fix the problem


Turn Off
Turn Off

Collaboration Diagram

:Diagnosis

4: Diagnose()

:Mechanic

:Car

Agenda

WhyWeModelCollaborationDiagrams
Why
We Model Collaboration Diagrams
Notation
DifferentTypesofMessages
ModelaCollaborationDiagram:CaseStudy

Notation

Object

Object : Class

:Class

Notation: Associations
can be carried from
class diagrams as
association roles

Role

Parent

Child
ObjectB

ObjectA

Association

Parent

Child
ObjectB

ObjectA
Message flow;
communication
must originate
from the Parent

to depict relationships between objects

:InventoryApp

location:Location

<<parameter>>
<<local>>
con:DatabaseConnection

InventoryApp has a <<local>> variable which accepts a


<<parameter>>, a location instance

Agenda

WhyWeModelCollaborationDiagrams
Why
We Model Collaboration Diagrams
Notation
DifferentTypesofMessages
ModelaCollaborationDiagram:CaseStudy

Message types

Load(File)

Synchronous
(wait)

:FileSystem

:Compiler
Link(ProgramName,Options)

Asynchronous
y
(continue)

:Compiler

:Linker

:DialogOne
g

Flat
(unimportant)

:Mechanic

:DialogTwo

Message Sequencing

1:Message1
:FileSystem

4:M
Message4

2:Messag
ge2

:Compiler

3:Message3
:Compiler

:Linker

Multiple Messages

2:AddStudent(Name)
:Student

1:LoadClass((name)

:Teacher

1.1:LoadStudents()
1 2:LoadClassInfo()
1.2:LoadClassInfo()
1.3:LoadRoom()

:Class

: FileSystem
y

Guard Conditions

1:Compile(Project)
3a:NotifyOfSuccess

:FileSystem

[Project Loaded]
:Editor

:Compiler

:ErrorDialog

Creating Instances
<<create>>
Constructor
:ObjectB<<new>>

:ObjectA

<<create>>
1:CreateStudent (Name)
:GradingSystem
G di S

: Student<<new>>

Iterations (repeating processes)

1.* Message

:ObjectB

:ObjectA
*

1.* Message

:ObjectB

:Student
*

Iterations (repeating processes)

Loop through
each grade
Calculate GPA

1.* [[1..N]:
] GPA+=Grade
2: GPA=GPA/Count(Grades)

:Grade

:Student
*

Agenda

WhyWeModelCollaborationDiagrams
Why
We Model Collaboration Diagrams
Notation
DifferentTypesofMessages
ModelaCollaborationDiagram:CaseStudy

Model a Collaboration Diagram: Case Study


1. Identifytheelementsthatbelonginyourdiagram
2. Modeltherelationshipsbetweentheseelements
3. Modeltheinstanceleveldiagram

Use Case Model


distribute
electronically
record g
grades

<<include>>
save grades

Teacher

upgrade
pg
g
grades

<<include>>

<<include>>

load grades

logon
<<include>>
view
i
grades
d

Administrator

generate
report cards

Student

Class Diagram

maintains >

< contains
ReportCard
p

Grades

Teacher

^ displays
^ generates
WebSite
uses >
^ grants access to
Administrator
Securityy

Student
uses >

< uses

Identify the elements

Domain Classes

:Teacher

:Grades

:Student

Control Classes

:Securityy

:Database

Interface Class

:WebSite

2. Model the Relationships Between these Elements

:Teacher

:Security
uses >

:WebSite

<<local>>

uses >

<<local>>

uses >
:Student

:Database

<<parameter>>

uses >

:Grades

3. Model an Instance-Level Diagram


1.1:Validate(UID,PWD)
12 [
1.2a:[pass]
] DisplayMenu()
Di l M
()
1.2b:[fail] Logout()

1:Logon(UID PWD)
1:Logon(UID,PWD)
2:[menu displayed] LoadStudent(Name)
:Teacher

WebSite

:Security

2.2:LoadStudentInfo(Name)
:Database

: Student<<new>>

:Grade

Vous aimerez peut-être aussi