UML - Roma Tre University

1

UML

Paolo Atzeni (con utilizzo di materiale

di A. Parente, L. Baresi, B. Pernici e G. Rumolo)maggio 2001

maggio 2001 P. Atzeni, UML 2

UML: Unified Modeling Language

• Un linguaggio "standard" (accettato dall'OMG) per la modellazione di sistemi software

• È un linguaggio e non una metodologia– può essere utilizzato con diverse metodologie– i proponenti di UML hanno definito una metodologia

• UML deriva dalla "integrazione" di modelli preesistenti (proposti nel contesto di metodologie):– Booch et al.– OMT (Rambaugh et al.)– OOSE (Jacobson et al.)

• Gli autori di UML sono Booch, Rumbaugh e Jacobson • È adottato da strumenti di sviluppo: Rational Rose

2


UML: principi ispiratori

• Modellazione (ovviamente non finalizzata a se stessa, ma allo scopo di produrre software migliore)

• La modellazione è essenziale in ogni attività ingegneristica complessa, in quanto permette di astrarre e semplificare: – "we build models so that we can better understand the

system we are developing" [Booch et al: The UML User Guide]

– "we build models of complex systems because we cannot comprehend such a system in its entirety" [ibidem]


Finalità della modellazione

• Visualizzazione un sistema (così com'è o come lo si vorrebbe)• Specifica della struttura e/o del comportamento di un sistema• Definizione delle linee guida per la costruzione di un sistema• Documentazione delle decisioni prese

3


Principi della modellazione

(secondo Booch et al, op. cit.)

• The choice of what models to create has a profound influenceon how a problem is attacked and how a solution is shaped

• Every model may be expressed at different levels of precision• The best models are connected to reality• No single model is sufficient. Every nontrivial system is best

approached through a small set of nearly independent models.


Costrutti di UML ("building blocks")

• Things: elementi di base di un modello (attenzione al termine "modello"); vari tipi:– strutturali– comportamentali– di raggruppamento– per annotazioni

• Relationships: legami, correlazioni fra "things"• Diagrams: raggruppamenti di "things"; molti tipi diversi

4


I diagrammi di UML (!)

• Class diagrams• Object diagrams• Use case diagrams• Sequence diagrams• Collaboration diagrams• Activity diagrams• Statechart diagrams• Component diagrams• Deployment diagrams


UML, questioni generali

• Diagrammi e specifica:– i diagrammi sono una "semplificazione" di una specifica

testuale, che segue una sintassi precisa– ogni diagramma può presentare una vista (parziale) della

specifica• "Adornments":

– per ogni costrutto esiste una notazione grafica base, cui possono essere aggiunti dettagli

• Distinzioni di livello:– classe-oggetto (schema-istanza); notazione:

• classe• istanza:classe :classe istanza

– interfaccia-implementazione

5


UML, questioni generali (2)

• Meccanismi di estensibilità– stereotipo: estensione del vocabolario (introduzione di

nuovi costrutti); ad esempio, la classe eccezione o la classe interfaccia

– "tagged value": estensione delle (meta)-proprietà di un costrutto; ad esempio, un numero di versione ad ogni classe

– vincolo: estende la semantica di un costrutto, aggiungendo o modificando regole


Due costrutti trasversali

• package: meccanismo generale per l'organizzazione di elementi in gruppi (sono solo "concettuali"; a livello realizzativo sono sostituiti dai componenti)

• nota: "spiegazione", commento

6


Class Diagram

• Il diagramma che illustra gli elementi dichiarativi (statici) di un modello (classi e tipi) assieme alle loro proprietà caratteristiche e alle relazioni tra di loro intercorrenti.

• Una classe è la descrizione di un insieme di oggetti che condividono gli stessi attributi, operazioni, metodi, relazioni e semantiche.

• Un oggetto e’ una istanza di una classe• Gli attributi di una classe rappresentano l’astrazione delle

proprietà statiche degli oggetti che la classe rappresenta• I metodi di una classe rappresentano l’astrazione degli aspetti

comportamentali degli oggetti che la classe rappresenta


Classi, dettagli base

• attributo: proprietà con un nome e un tipo (opzionale) – una classe ha zero o più attributi– un attributo può avere valori di default, essere modifcabile o

"frozen", avere una visibilità (pubblica "+", privata "-", protetta"#"), avere una molteplicità ([min .. max]); essere a livello di classe (e non di istanza; cfr static del C++)

• operazione: realizzazione di un servizio che può esser richiesto agli oggetti della classe (ad esempio per modificarne lo stato)– se ne può dare la signature (e info sui parametri: I, O, I/O)– proprietà (visibilità, isQuery, .. concurrent)

• responsabilità:contratto o obbligazione di una classe (la "funzione" o lo scopo)– descritta in linguaggio naturale

7


Classe

• Ogni classe ha un nome, unico nell'ambito del package in cui la classe è definita

• Rappresentazione grafica

package::Nome Nome

Attributi

Nome

AttributiOperazioni

Nome

AttributiOperazioni

Responsabilità


- Class Diagram- Call for papers attributes

Call for papers

conference titleworkshop dateplacecontactsgoalstopics of interest [*]awards [*]important dates [*]attendancerelated conferencesmore information

Important dates are:Deadlines

E-mail / abstract submissionPaper submissionNotification of acceptanceFinal version submission (ready copy)

Event dateWorkshop

8


- Class Diagram- Key persons

other names:PC co-chairPC regional chairPC=Program Committee

Person

info

General Conference chair

<<responsabilities>>- Has overall responsabilitiesfor all conference matters

Coordinating program chair

<<responsabilities>>- Coordinates and controlsthe entire technicalprogram committeess

Program committee chair

<<responsabilities>>-Naming of PC members-Supervision of review andselection process-Coordinates the sub-programcommittee

PC member

<<responsabilities>>-Reviews papers andwritesa report-Partecipates to PCmeeting to discuss papers

Web master

<<responsabilities>>-Dispatch mails-Keeps update informationon the web site

Prooceeding chair

<<responsabilities>>-Verifies the final versionpapers-Gets papers ready to print

Author

<<responsabilities>>-Submits a paper-_Writes the final version-Presents his paper at theWorkshop


- Class Diagram- A program committee member can be author

Author PC member

review (paper)

PC member and author

review (paper)

<<responsabilities>>- PC members submit theirown or co-authored papers totheir own region for review

<<exception>>

can't review my paper

<<send>>

9


Classi, altri dettagli e varianti

• caratteristiche dipendenti dal linguaggio di programmazione (es.: polimorfismo)

• separazione di interfaccia e implementazione• tipi particolari di classi:

– classi attive (per rappresentare processi o thread)– componenti (in una architettura software)– nodi (di una architettura hardware)

• molteplicità (classi singolari, classi con numero fissato di istanze)

• template• stereotipi predefiniti: metaclasse, powertype, utility


Classi: "hints and tips"

• Each class should map to some tangible or conceptual abstraction in the domain of the end user or the implementor. A well structured class:– provides a crisp abstraction of something from the problem

domain or the solution domain– embodies a small, well-defined set of responsibilities and

carries them out all very well– provides a clear separation of the abstraction's specification

and its implementation– is understandable and simple yet extensible and adaptable

10


Classi: "hints and tips" (2)

• Nei diagrammi:– show only those properties that are important to understand

the abstraction in its context– organize long lists of attributes and operations by grouping

them according to their category– show related classes in the same class diagrams


Classi: prospettive

• Concettuale: rappresenta i concetti del dominio di interesse (in modo indipendente da ogni aspetto realizzativo)

• di specifica: concerne il software, a livello delle interfacce, non della realizzazione

• di implementazione

11


Relationships

• Tre tipi fondamentali– dipendenza ("usa": ad esempio come parametro; molti

dettagli, tralasciamo)– generalizzazione (possono essere disgiunte/sovrapposte,

complete/incomplete)– associazione (include aggregazione, composizione)

• Inoltre– realizzazione– raffinamento


Dipendenza, generalizzazione, associazione

Window

open()close()move()

handleEvent()display()

Event

ConsoleWindow DialogBox Control

12


Associazioni

• Possono essere riflessive• Possono essere n-arie (ma "it's not common"!)• Adornments:

– nome: non obbligatorio; può avere un "verso" (di lettura; niente a che vedere con la "navigabilità", che pure esiste in UML)

– ruolo, per ciascuna classe coinvolta– molteplicità (cardinalità): indicate in modo opposto a quello

usato nell'E-R a noi noto• Aggregazione: un tipo particolare di associazione che specifica

un rapporto aggregato-componente• Composizione: aggregazione in cui ogni componente partecipa

ad un solo aggregato


Dipendente Aziendaimpiegato datore di lavoro

0:* 1:1

Dipendente Aziendalavora per 1*

Dipartimento Azienda* 1

Tecnico GruppoDiLavoro* *

13


Relationship: altri dettagli e varianti

• associazioni: – direzione di navigazione– visibilità– qualificazione– specificatore di interfaccia– "association class"– vincoli: implicit (derivata), ordered, changeable, addOnly,

frozen– realizzaizone


Relationships: "hints and tips"

• Use dependencies only when the relationship is not structural• Use generalization only whne you have an "is-a-kind-of"

relationship• Beware of introducing cyclic generalization relationships• Keep you generalization relationships generally balanced;

neither too deep nor too wide• Use associations primarily where there are structural

relationships among objects

14


Relationships: "hints and tips" (2)

• Nei diagrammi:– use either rectilinear or oblique lines consistently– avoid lines that cross– show only the relationships that are necessary (and

nonredundant)


- Class Diagram- Committees

Coordinating Programchair : person

Organizing CommitteProgram Committe

Committee

Sub Program CommitteeProgram Committechair : person

Program Committemember : person

nam

es

chairperson

member

has responsabilities for

1

1

1

2..3

11

*

11

*

1

15


- Class Diagram- Call for papers officials and tracks

Call for Papers

Officier name

role

Person

info

Track

name

Paper

Submission instruction

formatinstructiondeadlines

1

{sub

set}

{sub

set}

{sub

set}

*

*

1..*

0..1

1..*

*

*

*

*

1

1..*

<<incomplete>>

officier

organizingcommittee

PC member

chairperson

*


- Class Diagram- Call for papers tracks

Track

ExhibitsIndustrialPanelTutorialDemonstrationPaper

16


- Class Diagram- A program committee member can be author

Author PC member

review (paper)

PC member and author

review (paper)

<<responsabilities>>- PC members submit theirown or co-authored papers totheir own region for review

<<exception>>

can't review my paper

<<send>>


UML: dinamica

• classi e relationship modellano la struttura di un sistema• gli oggetti (istanze delle classi) interagiscono fra loro secondo

un "comportamento" che è utile modellare– use case – interaction diagram

• sequence• collaboration

– activity diagram– statechart diagram

17


Use case

• Specificano il comportamento del sistema, cioè come il sistema agisce e reagisce, visibile all’esterno (scatola nera)

• Gli use case – descrivono il sistema, l’ambiente e le relazioni fra sistema e

ambiente– coinvolgono gli attori: qualcuno (utente) o qualcosa (sistemi

esterni - hardware) che:• scambia informazioni con il sistema• fornisce input o riceve output dal sistema


Definizioni

• Use case:descrizione di un insieme di sequenze di azioni, che un sistema svolge per fornire un risultato osservabile ad un attore– gli use case hanno nomi unici nell'ambito dei package

• Attore: un insieme coerente di ruoli di un utente (di uno use case)

• Attori e use cose possono essere correlati (solo) tramite associazioni (l'attore e lo use case comunicano scambiandosi messaggi)

nome UseCase

nome attore

18


Descrizione degli use case

• Descrizione sintetica: "enunciato" degli obiettivi; poche frasi• Flusso degli eventi:

– inizio e conclusione dello use case– interazione con gli attori– dati utilizzati– sequenza ordinaria degli eventi– flusso alternativo o "eccezionale"


Descrizione di uno use case

Definizione: Il PC chair distribuisce gli articoli tra i membri del comitato di programma

Flusso principale:• Il sistema propone al PC Chair una lista di coppie di articoli e membri

del comitato di programma ("il membro può recensire l'articolo")• Il PC chair seleziona un insieme di coppie, assegnando tre revisori ad

ogni articolo e carichi uniformi ai PC member • Il sistema manda una mail ad ogni PC member con gli articoli da

giudicareCasi anomali• Un articolo viene ritirato• Le coppie proposte portano ad un assegnazione troppo sbilanciata• Un PC member solleva un conflitto di interessi

19


Use case e scenari

• Scenario: istanza di use case– ci sono molti più scenari che use case– scenari principali (uno o pochi per ogni use case)– scenari secondari, per le alternative e le eccezioni

• gli scenari sono descritti per mezzo dei diagrammi di interazione (di sequenza e di collaborazione)


Use case: organizzazione

• Gli use case possono – essere raggruppati in package– essere correlati tramite

• generalizzazione: come per le classi• include:uno use case ne utilizza un altro (magari

comune a più use case); è una dipendenza (stereotipo predefinito)

• extend:uno use case è basato su un altro, con varianti (estensioni) definibili solo in punti specifici (extension point)

20


Use case e relationship

Place order

Extension pointsset priority

Track order

Validate user

Check smart card

Checkpassword

Place rush order

<<include>>

<<include>>

<<extend>>(set priority)


Utilizzo degli use case

• Modellazione ad alto livello del comportamento di un elemento:– intero sistema o sottosistema

• Strumento di comunicazione fra analisti, utenti, sviluppatori• Base per il test• Un possibile metodo per definire gli use case

– individuare gli attori– organizzare gli attori (casi particolari: generalizzazioni)– per ogni attore, individuare le principali interazioni con il

sistema (casi base e alternative ed eccezioni)– organizzare gli use case

21


Use case diagram

• Permettono di modellare – il contesto di un sistema o sosttosistema (o classe) – i requisiti per il suo comportamento

• Uno use case diagram è un diagramma che include un insieme di use case e di attori e le relationship fra loro


- Use Case Diagram- Conference

CoordinatingProgram Chair

PC chair

PC member

Person

Author

Web master

Ranks papers

SelectsPC members

Dispatchingpapers

E-maildiscussion

Authornotification

Papersubmission

Insert contactinfo

Referee report Receivesan e-mail

Generalconference chair

applicationsetup

22


- Use Case Diagram- Paper ranking

PC chair

Ranks papers

Insert partialdecision

Insert finaldecision

CoordinatingProgram Chair


Diagrammi di interazione

• Descrivono interazioni, cioè insiemi di oggetti e relationship, con i messaggi che vengono scambiati

• Due tipi– sequence diagram: enfatizza l'ordinamento temporale dei

messaggi– collaboration diagram: enfatizza la struttura degli oggetti

che inviano e ricevono messaggi

23


Alcune definizioni

• Interazione: specifica del modo in cui vengono inviati messaggi tra diverse istanze per eseguire un compito specifico.

• Messaggio: specifica di una comunicazione tra istanze, che trasmette informazione nell'aspettativa che ne consegua attività(evento). Tipi:– Call: invoca un'operazione su oggetto (anche se stesso)– Return: restituisce un valore al chiamante– Send: invia un "segnale" ad un oggetto– Create: crea un oggetto– Destroy: distrugge un oggetto (anche se stesso)


Notazione per i messaggi

• Call:

• Return:

• Send:

• Create:

• Destroy:

<<create>>

<<destroy>>

24


Notazione, ancora

• Interazione sincrona:

• risposta:

• Interazione asincrona:

• Interazione non specificata(di solito asincrona)


Sequence diagram

• Asse verticale: tempo, dall'alto verso il basso• Asse orizzontale: oggetti, da sinistra verso destra in ordine

decrescente di importanza; nella prima colonna l'oggetto che avvia la collaborazione

• Due caratteristiche importanti, per ciascun oggetto– la "linea della vita"– il "focus of control": evidenzia il periodo di tempo durante il

quale un oggetto sta eseguendo un'azione, direttamente o utilizzando una procedura subordinata

25


- Sequence Diagram (Interaction Diagram)- Program Committee member selection

:PC chair :Person

Invitation to join PC

answer

[answer=no] <<destroy>>

:PC member

[answer=yes] <<became>>


-Seq

uenc

e D

iagr

am(I

nter

actio

nD

iagr

am)

-Pap

er su

bmis

sion

:Aut

hor

:PC

chai

r

pape

rID

:Pro

ceed

ing

chai

r:W

eb m

aste

r

a :s

ubm

it ab

stra

ct{a

.star

tTim

e<

ABS

TRA

CT_

DA

TE}

b :s

ubm

it pa

per

{b.st

artT

ime

< PA

PER_

DA

TE}

c :n

otifi

catio

n

{c.st

artT

ime

<N

OTI

FIC

ATI

ON

_DA

TE}

d : f

inal

vers

ion

{d.st

artT

ime

< FI

NA

L_D

ATE

}

conf

irm

[AFT

ER A

LL P

APE

RSH

AV

E BE

EN R

ECEI

VED

]

26


-Seq

uenc

e D

iagr

am(I

nter

actio

nD

iagr

am)

-Disp

atch

ing

pap

ers

:PC

chai

r:P

Cm

embe

r

* [1

0~20

times

]req

uest

ing

revi

ewin

gw

ork

(pap

er)

pape

r con

fiden

ce

rl:r

emin

der l

ette

r{r

l.sta

rtTim

e=

REFE

REE_

DA

TE -

15da

ys}

*rr

:ref

eree

repo

rt{r

r.sta

rtTim

e<

REFE

REE_

DA

TE}


Collaboration diagram

• Caratteristiche importanti– stereotipi sui link– numero di sequenza, iterazioni, condizioni

27


- Collaboration Diagram (Interaction Diagram) - Paper flow

:PC member

:Author

:PC chair

Program Committee

* 3 : report

* 2 : paper1

: pap

er

4 : notification


- Collaboration Diagram (Interaction Diagram)- Paper list lifecycle

uno : PC meeting

due : PC meeting

tre : PC meeting

c : Consolidation meeting

p : paper list

accepted : list = emptynotAccepted : list = emptygrayArea : list = empty

addAccepted(p) : listaddNotAccepted(p) : listaddGrayarea(p) : list

p : paper list

accepted [*]notAccepted [*]grayArea [*]

p : paper list

accepted [*]notAccepted [*]grayArea = empty

*[accepted] due1 : addAccepted(p)

*[grayArea] due3 : addGrayArea(p)*[notAccepted] due2 : addNotAccepted(p)

*[accepted] uno1 : addAccepted(p)*[grayArea] uno3 : addGrayArea(p)

*[notAccepted] uno2 : addNotAccepted(p)

*[accepted] tre1 : addAccepted(p)

*[grayArea] tre3 : addGrayArea(p)

*[notAccepted] tre2 : addNotAccepted(p)

1 / c1 : list=readGrayArea()

* c3 : addNotAccepted(p)* c2 : addAccepted(p)

uno3,due3,tre3 / 1 : <<became>>

c3 / 2 : <<became>>

28


- Collaboration Diagram (Interaction Diagram) - Final notification

:Consolidation meeting

:Web master

:Authors * 2 : notification

1 : list of papers results


- Collaboration Diagram (Interaction Diagram) - User-system interaction

System

User

Form

Mail

29


Sequence e collaboration diagram

• Sono semanticamente equivalentI:– si può passare dall'uno all'altro senza perdere informazione– anche se non visualizzano esplicitamente le stesse info

• Scelta fra un tipo e l'altro:– sequence sono preferibili per modellare le interazioni con

enfasi sull'ordinamento temporale– collaboration sono preferibili per porre l'enfasi

sull'organizzazione


Activity diagram

• Attività: esecuzione non atomica (in una macchina a stati); include azioni (esecuzione di operazioni, calcoli, invio di messaggi,…)

• Activity diagram: descrive il flusso fra attività

• gli activity diagram sono quindi più dettagliati degli interactiondiagram

30


Diagrammi di attività: elementi

• Stati: i nodi del diagramma– stati di azioni (action state): atomici– stati di attività: decomponibili– stati particolari: inizio e fine

• Transizioni: archi che descrivono il passaggio da una attività ad un'altra– semplici– diramazioni (branching)– concorrenza: fork e join

• Corsie (swimlanes): descrivono la "competenza" per lo svolgimento delle attività (in termini di soggetti del mondo reale)

• Flusso di oggetti: le attività si possono inviare oggetti, nel cedere il controllo


Utilizzo degli activity diagram

• Modellazione di workflow:– attività a livello abbastanza alto (il flusso di oggetti può

essere importante; le corsie possono essere utili)• Modellazione di operazioni:

– a livello più dettagliato (branch, fork, join sono importanti)

31


Modellazione di workflow con activity diagram

• Individuare il workflow di interesse (non tutto il sistema)• Individuare i componenti dell'organizzazione che hanno

responsabilità nel workflow: corsie• Individuare le precondizioni dello stato iniziale e le

postcondizioni dello stato finale• A partire dallo stato iniziale, specificare le operazioni (per mezzo

di stati del diagramma)• Se le azioni sono complesse, procedere per livelli di

raffinamento• Rappresentare le transizioni (prima semplici, poi branching,

infine fork e join)• Se ci sono oggetti cimportanti, includerli nel diagramma


Con

fere

nce

offic

ials

Aut

hors

Con

fere

nce

setu

p

Pape

rssu

bmis

sion

Pape

rsse

lect

ion

-Act

ivity

Dia

gram

(Wor

kflo

w)

-Con

fere

nce

rele

vant

act

iviti

es

32


Gen

eral

Con

fere

nce

chai

r per

son

Prog

ram

Com

mitt

eech

air p

erso

n

Mai

n of

ficia

lsse

lect

ion

PCm

embe

rse

lect

ion

Writ

esth

eca

ll fo

r pap

ers

-Act

ivity

Dia

gram

(Wor

kflo

w)

-Con

fere

nce

setu

p

Cal

lfor

pape

rs

<<cr

eate

>>


Abs

tract

subm

issi

on

Pape

rsu

bmis

sion

Subm

issi

onre

ject

ed

-Act

ivity

Dia

gram

(Wor

kflo

w)

-Pap

er su

bmis

sion

Subm

issi

onac

cept

ed

[ELS

E][A

CC

EPTA

NC

E RE

QU

IREM

ENTS

FU

LFIL

LED

]

33


Coo

rdin

atin

gpr

ogra

mch

air

PCch

air

Dis

patc

hes

pape

rs a

mon

gPC

mem

bers

Revi

ew p

aper

san

dw

rite

are

port

Prop

oses

ane-

mai

ldis

cuss

ion

onco

ntro

vers

ial p

aper

s

-Act

ivity

Dia

gram

(Wor

kflo

w)

-Pap

ers s

elec

tion

PCm

embe

rs

E-m

aild

iscu

ssio

non

cont

rove

rsia

l pap

ers

and

new

repo

rt

Rank

s pap

ersa

nd P

Cpa

pers

,en

sure

s tha

t eve

ry p

aper

has

atle

ast3

or 4

revi

ews

Det

erm

ines

Ni(

PCde

cisi

on re

spon

sibi

lity)

and

Mi(

gray

area

)fo

r eac

h C

omm

ittee

Show

sthe

PCpa

pers

rank

edlis

t

PC m

eetin

g,ac

cept

Nip

aper

s

*

**


All

PCch

airs

+C

oord

inat

ing

prog

ram

chai

rPC

web

mas

ter

cons

olid

atio

nm

eetin

g,m

ake

final

deci

sion

ongr

ay-a

rea

pape

rs

Not

ifica

tion

ofac

cept

ance

/reje

ctio

n

-Act

ivity

Dia

gram

(Wor

kflo

w)

-Con

solid

atio

nm

eetin

g

*

34



Modellazione di operazioni con activity diagram

• Individuare le astrazioni coinvolte nell'operazione: parametri, attributi della classe, altre classi di interesse

• Individuare le precondizioni dello stato iniziale dell'operazione e le postcondizioni dello stato finale (ed eventuali invarianti)

• A partire dallo stato iniziale, specificare le operazioni (per mezzo di stati del diagramma)

• Utilizzare il branching se necessario per iterazioni e alternative• Se l'operazione appartiene ad una classe attiva, valutare

l'opportunità di introdurre fork e join per specificare flussi di controllo concorrenti

35


-Act

ivity

Dia

gram

(Ope

ratio

n)-P

Cm

embe

rs s

elec

tion

[PO

SITI

VE]

Sele

ctsa

pote

ntia

lPC

mem

bers

list

Send

s inv

itatio

nto

join

the

prog

ram

com

mitt

ee

Cre

ates

a ne

w P

Cm

embe

rslis

t

Add

sthe

pers

onto

the

PCm

embe

rslis

t

[NEG

ATI

VE]

wai

ts fo

r an

answ

er

*

[ELS

E][E

MPT

Y]

n= P

Cm

embe

rsnu

mbe

r+

expe

cted

ans

wer

s

Chec

ks e

xpec

ted

answ

ersl

ist

[ELS

E]

[N<E

XPE

CTE

D P

C M

EMB

ERS

]


The

PCch

air

crea

tesa

list

ofco

uple

s(p

aper

, PC

mem

ber)

Send

sapa

per t

oa

PCm

embe

r for

each

cou

ple

-Act

ivity

Dia

gram

(Ope

ratio

n)-D

ispat

chin

g pa

pers

Cre

ates

a ne

wco

uple

Chec

ksth

eex

pect

ed a

nsw

ers

list

[LO

W C

ON

FID

ENCE

][H

IGH

CO

NFI

DEN

CE]

wai

ts fo

r an

answ

er

*

Each

PCm

embe

rha

s to

revi

ew10

~20

pape

rs,

each

pap

er m

ust h

ave

atle

ast3

or 4

revi

ews

[ELS

E]

[EM

PTY

]

36


Macchine a stati

• Gli activity diagram sono una forma di "macchina a stati", in quanto modellano l'evoluzione di una operazione

• La forma più generale di macchina a stati è descritta con gli statechart diagram, usati soprattutto per descrivere l'evoluzione di oggetti, soprattutto attivi


-Sta

tech

art D

iagr

am-P

aper

life

cycl

e

to r

evie

w

disc

ussio

nfa

se

do /

e-m

ail

disc

ussi

on

revi

ewed

The

pape

r has

atle

ast

3re

port

rank

ed

not a

ccep

ted

gray

area

do /

PCco

-cha

irco

nsol

idat

ion

mee

ting

acce

pted

whe

n(PC

_MEE

TIN

G_D

ATE

) /di

scus

sion

[GO

OD

PA

PER]

[ELS

E]

[CO

NTR

OV

ERSI

AL]

[NO

RMA

L]

37


-Sta

tech

art D

iagr

am-P

rogr

amC

omm

itte

mem

ber p

aper

life

cycl

e

to r

evie

w

disc

ussf

ase

do/e

-mai

ldi

scus

sion

revi

ewed

The

pape

r has

atle

ast

4re

port

rank

ed

not a

ccep

ted

acce

pted

[con

trove

rsia

l][n

orm

al]

whe

nPC

mee

ting

isov

er[p

aper

scor

e <=

scor

e(n)

]

PCch

air e

xam

inat

ion

whe

nPC

mee

ting

isov

er[p

aper

scor

e >

scor

e(n)

]


Modellazione di applicazioni Web con UML

• Estensioni; ricordiamo:– Meccanismi di estensibilità in UML

• stereotipo: estensione del vocabolario (introduzione di nuovi costrutti); ad esempio, la classe eccezione o la classe interfaccia

• "tagged value": estensione delle (meta)-proprietà di un costrutto; ad esempio, un numero di versione ad ogni classe

• vincolo: estende la semantica di un costrutto, aggiungendo o modificando regole

38


Stereotipi per pagine sul client e sul server

<<builds>>

<<submits>>


- Class Diagram (Web extension)- Application setup

setup Form

conference name:textconference date [*] :text

<<builds>>

<<submits>>

Configuration page

Configuration page

39


-Cla

ssD

iagr

am(W

ebex

tens

ion)

-Pro

gram

com

mitt

ee m

embe

r sel

ectio

n

add

pers

onFo

rm

nam

ee-

mai

l

<<bu

ilds>

>

<<su

bmits

>>

PCm

embe

rs s

elec

tion

PCm

embe

rs s

elec

tion

<<in

fo>>

PCm

embe

rs: l

ist

Pers

on: l

ist

<<E-

mai

l>>

Invi

tatio

n to

join

PC

<<se

nd>>

PCm

embe

rpag

e

<<lin

ks>>


- Class Diagram (Web extension)- Abstract submission

Abstract submission

Confirm

<<info>>paper ID : string

Confirm

<<builds>>

Abstract SubmissionForm

abstract : Fileauthor : texte-mail : textco-authors [*] : text

<<submits>>

40


- Class Diagram (Web extension) - Paper submission

Paper submission

Confirm Confirm

<<builds>>

Paper SubmissionForm

paper : Filepaper ID : text

<<submits>>


- Class Diagram (Web extension) - Final version submission

Final versionsubmission

Confirm Confirm

checkAllSubmitted()sendMail()

<<builds>>

Final versionsubmission Form

paper : Filepaper ID : text

<<submits>>

41


-Cla

ssD

iagr

am(W

ebex

tens

ion)

-Disp

atch

ing

pape

rs

Pape

rpag

e

<<bu

ilds>

>PCm

embe

rfor

m

PCm

embe

rs[*]

:ch

eckb

ox

mod

ify()

<<su

bmits

>>Pa

perp

age

<<in

fo>>

pape

r inf

oPC

mem

bers

: lis

tpa

pers

to re

view

:nes

ted

list

Send

allp

aper

s

subm

it()

send

pap

ers

send

Mai

l()<<

subm

its>>


- Class Diagram (Web extension) - E-mail discussion

Papers list

<<info>>papers : listscores : nested list

Papers list

<<builds>>

Discussion Form

papers todiscuss [*] :checkbox

<<submits>>

Start e-maildiscussion

submit()

Papers list

sendMail()

<<submits>>

42


-Cla

ssD

iagr

am(W

ebex

tens

ion)

-Ref

eree

repo

rtan

d co

ntac

tinf

o

PCm

embe

rpag

e

Con

firm

<<bu

ilds>

>

Rep

ortf

orm

pape

rID

:tex

tre

port

: File

ques

tions

[*]pa

per C

onfid

ence

:che

ckbo

x

<<su

bmits

>>

Con

firm

page

Con

tact

sfo

rmco

ntac

ts[*]

:te

xtto

pics

[*] :

chec

kbox

join

PC

mem

ber:

chec

kbox

mod

ify()

PCm

embe

rpag

e

<<bu

ilds>

>

<<su

bmits

>>


-Cla

ssD

iagr

am(W

ebex

tens

ion)

-Ran

king

pape

rs Ran

king

pape

rs

<<in

fo>>

pape

rs: l

ist

Pape

r

<<bu

ilds>

>

Pape

rFor

m

scor

e :t

ext

to re

view

: rad

iore

view

ed: r

adio

rank

ed: r

adio

disc

ussi

onfa

se :

radi

oac

cept

ed: r

adio

gray

area

: ra

dio

reje

cted

: rad

io

<<su

bmits

>>

Sele

ctio

nfo

rm

Pape

r typ

e[*]

:ch

eckb

ox

Pape

r

<<in

fo>>

pape

rsID

:st

ring

refe

ree

repo

rts: l

ist

auth

ors

[*] :

strin

g

<<lin

ks>>

pape

rID

<<su

bmit>

>

Send

not

ifica

tion

subm

it()

<<su

bmit>

>

Send

not

ifica

tion

Send

Mai

l()Se

ndM

ail()

43


Rational Rose

• Uno strumento CASE che supporta UML• Versione demo disponibile sul sito della Rational:

– www.rational.com

UML - Roma Tre University

Documents

Transcript of UML - Roma Tre University