38
UML Paolo Atzeni marzo 2002 marzo 2002 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

UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

Embed Size (px)

Citation preview

Page 1: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

1

UML

Paolo Atzeni

marzo 2002

marzo 2002 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

Page 2: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

2

marzo 2002 P. Atzeni, UML 3

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]

marzo 2002 P. Atzeni, UML 4

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

Page 3: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

3

marzo 2002 P. Atzeni, UML 5

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 ofprecision

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

marzo 2002 P. Atzeni, UML 6

Costrutti di UML ("building blocks")

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

• Classe, interfaccia, "use case", componente, nodo– comportamentali

• Messaggio, stato– di raggruppamento– per annotazioni

• Relationships: legami, correlazioni fra "things":– dipendenza,associazione, generalizzazione, realizzazione

• Diagrams: raggruppamenti di "things"; molti tipi diversi

Page 4: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

4

marzo 2002 P. Atzeni, UML 7

I diagrammi di UML (!)

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

marzo 2002 P. Atzeni, UML 8

- 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

Page 5: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

5

marzo 2002 P. Atzeni, UML 9

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

:PC chair :Person

Invitation to join PC

answer

[answer=no] <<destroy>>

:PC member

[answer=yes] <<became>>

marzo 2002 P. Atzeni, UML 10

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

Page 6: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

6

marzo 2002 P. Atzeni, UML 11

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

marzo 2002 P. Atzeni, UML 12

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

Page 7: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

7

marzo 2002 P. Atzeni, UML 13

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

marzo 2002 P. Atzeni, UML 14

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: specifica dettagliata di classi, con riferimento anche ad un linguaggio di programmazione

Page 8: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

8

marzo 2002 P. Atzeni, UML 15

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 modificabile o

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

• operazione: 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

marzo 2002 P. Atzeni, UML 16

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à

Page 9: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

9

marzo 2002 P. Atzeni, UML 17

- 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

marzo 2002 P. Atzeni, UML 18

- Class Diagram- Key persons

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

Person

info

General Conference chair

<<responsibilities>>- Has overall responsibilitiesfor all conference matters

Coordinating program chair

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

Program committee chair

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

PC member

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

Web master

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

Prooceeding chair

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

Author

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

Page 10: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

10

marzo 2002 P. Atzeni, UML 19

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

marzo 2002 P. Atzeni, UML 20

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

Page 11: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

11

marzo 2002 P. Atzeni, UML 21

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

marzo 2002 P. Atzeni, UML 22

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

Page 12: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

12

marzo 2002 P. Atzeni, UML 23

Dipendenza, generalizzazione, associazione

Window

open()close()move()

handleEvent()display()

Event

ConsoleWindow DialogBox Control

marzo 2002 P. Atzeni, UML 24

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

Page 13: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

13

marzo 2002 P. Atzeni, UML 25

Dipendente Aziendaimpiegato datore di lavoro

0:* 1:1

Dipendente Aziendalavora per 1*

Dipartimento Azienda* 1

Tecnico GruppoDiLavoro* *

marzo 2002 P. Atzeni, UML 26

Relationship: altri dettagli e varianti

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

frozen– realizzazione

Page 14: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

14

marzo 2002 P. Atzeni, UML 27

Relationships: "hints and tips"

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

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

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

relationships among objects

marzo 2002 P. Atzeni, UML 28

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)

Page 15: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

15

marzo 2002 P. Atzeni, UML 29

- Class Diagram- Committees

Coordinating Programchair : person

Organizing CommitteProgram Committe

Committee

Sub Program CommitteeProgram Committechair : person

Program Committemember : person

nam

es

chairperson

member

has responsibilities for

1

1

1

2..3

11

*

11

*

1

marzo 2002 P. Atzeni, UML 30

- 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

*

Page 16: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

16

marzo 2002 P. Atzeni, UML 31

- Class Diagram- Call for papers tracks

Track

ExhibitsIndustrialPanelTutorialDemonstrationPaper

marzo 2002 P. Atzeni, UML 32

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

Page 17: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

17

marzo 2002 P. Atzeni, UML 33

Specifica e analisi

• Una possibile articolazione– use case– schema concettuale (statico)– modello del comportamento del sistema– [modello degli stati]

marzo 2002 P. Atzeni, UML 34

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

Page 18: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

18

marzo 2002 P. Atzeni, UML 35

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 case possono essere correlati (solo) tramite associazioni (l'attore e lo use case comunicano scambiandosi messaggi)

nome UseCase

nome attore

marzo 2002 P. Atzeni, UML 36

Descrizione degli use case

• Attori coinvolti• Obiettivo• 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"

• Gli use case si descrivono a parole più che con diagrammi

Page 19: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

19

marzo 2002 P. Atzeni, UML 37

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

• in un approccio "iterativo" solo pochi scenari sono descritti all'inizio

marzo 2002 P. Atzeni, UML 38

Descrizione di uno use case

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

Flusso (scenario) 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

Page 20: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

20

marzo 2002 P. Atzeni, UML 39

Una descrizione più strutturata

Use case: pagamento alla cassaAttori: cliente, cassiereObiettivo: finalizzare l'acquisto di prodotti da parte di un cliente,

acquisendo il pagamentoDescrizione sommaria: un cliente arriva alla cassa con un

insieme di prodotti, il cassiere li registra e "fa il conto"; il cliente paga e se ne va con i prodotti

Precondizioni: la cassa è aperta (il cassiere si è autenticato)Postcondizioni: la vendita è registrata; il totale è calcolato

correttamente; le autorizzazioni sono registrate; …

marzo 2002 P. Atzeni, UML 40

Una descrizione più strutturata (2)

Risposte del sistema

3. Accetta l'inizializzazione

5. Determina il prezzo del prodotto e registra la vendita

7. Calcola il totale

10…

Scenario principaleAzioni degli attori1. Il cliente arriva alla cassa

con i prodotti 2. Il cassiere inizia una

"vendita"4. inserisce il codice di un

prodotto6. ripete 4 e 5 finché

necessario8. comunica il totale al cliente

e chiede il pagamento9. Il cliente indica il mezzo di

pagamento ...

Page 21: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

21

marzo 2002 P. Atzeni, UML 41

Una descrizione più strutturata (3)

Casi particolari4. Viene inserito un codice di prodotto non valido: segnalare

errore e rifiutare10. Il cliente dichiara di non avere i soldi per pagare né altro

mezzo di pagamento: annullare l'operazione e ottenere la riconsegna dei prodotti

marzo 2002 P. Atzeni, UML 42

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)

Page 22: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

22

marzo 2002 P. Atzeni, UML 43

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)

marzo 2002 P. Atzeni, UML 44

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

Page 23: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

23

marzo 2002 P. Atzeni, UML 45

Identificazione degli use case

• Sulla base degli attori– 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

• Sulla base degli "eventi"– individuare gli eventi esterni cui il sistema deve rispondere– individuare gli attori coinvolti e gli use case

marzo 2002 P. Atzeni, UML 46

Livello di astrazione

• Descrizione astratta– L'utente si identifica– Il sistema riconosce l'utente e procede

• Descrizione concreta– L'utente inserisce la carta– Il sistema domanda il PIN– L'utente digita il PIN– Il sistema riconosce l'utente e procede

Page 24: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

24

marzo 2002 P. Atzeni, UML 47

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

marzo 2002 P. Atzeni, UML 48

- 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

Page 25: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

25

marzo 2002 P. Atzeni, UML 49

- Use Case Diagram- Paper ranking

PC chair

Ranks papers

Insert partialdecision

Insert finaldecision

CoordinatingProgram Chair

marzo 2002 P. Atzeni, UML 50

Specifica e analisi

• Una possibile articolazione– use case– schema concettuale (statico)– modello del comportamento del sistema– modello degli stati

Page 26: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

26

marzo 2002 P. Atzeni, UML 51

Modello del comportamento del sistema

• A livello di specifica considera il sistema come "scatola nera"• Una possibile descrizione

– diagrammi di sequenza di sistema ("system sequence diagrams")

– contratti per le operazioni del sistema• In entrambi i casi l'attenzione è sul rapporto fra l'esterno e il

sistema (visto come scatola nera)

marzo 2002 P. Atzeni, UML 52

Diagrammi di sequenza di sistema

• Descrivono le varie interazioni degli attori con il sistema, nell'ambito di specifici use case (o meglio di scenari): ciascun diagramma dettaglia uno scenarioNota: UML come tale prevede i diagrammi di sequenza, che

permettono di descrivere interazioni fra classi; i diagrammi di sequenza di sistema sono un caso particolare, in cui le "classi" coinvolte sono due: un attore e il sistema

• in pratica, si tratta di descrizioni dettagliate e formalizzate degli use case:– eventi generati dall'attore (o dagli attori): "richieste"– ordine– eventi interni al sistema: "risposte", le operazioni sono del

sistema, non dei singoli oggetti

Page 27: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

27

marzo 2002 P. Atzeni, UML 53

Un diagramma di sequenza di sistema

: Cassiere:Sistema

inizioVendita()

acquisizioneProdotto(cod,qtà)desrizione, totale

*[]fineProdotti()

totale

pagamento(importo)

resto, scontrino

marzo 2002 P. Atzeni, UML 54

Diagramma di sequenza di sistema, commenti

• Non abbiamo rappresentato il cliente, perché non interagisce direttamente con il sistema

• La "frontiera" del sistema ci permette di capire quali sono gli eventi di interesse

Page 28: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

28

marzo 2002 P. Atzeni, UML 55

Modello del comportamento del sistema (2)

diagrammi di sequenza di sistema ("system sequence diagrams")

• contratti per le operazioni del sistema

marzo 2002 P. Atzeni, UML 56

Contratti per le operazioni del sistema

• Descrivono (in modo dichiarativo) alcuni dettagli delle operazioni (di sistema)

• Convolgono– precondizioni– postcondizioni, che descrivono le modifiche al modello

concettuale ("alla base di dati"); possibili modifiche:• creazione/distruzione di istanza• inserimento/eliminazione di associazione• modifica di attributo

• Non sempre sono usati: spesso non aggiungono molto agli use case

Page 29: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

29

marzo 2002 P. Atzeni, UML 57

Un contratto

Operazione acquisizioneProdotto(cod: tipoCodice, qtà: integer)Riferimenti Use Case: VenditaPrecondizioni è in corso una vendita Postcondizioniuna istanza di RigaDiVendita è stata creata

e associata con la Vendita in corso e con il prodotto con codice codla quantità (attributo di RigaDiVendita) ha assunto il valore di qtà (parametro dell'operazione)

marzo 2002 P. Atzeni, UML 58

Specifica e analisi

• Una possibile articolazione– use case– schema concettuale (statico)– modello del comportamento del sistema– modello degli stati (statechart diagrams)

Page 30: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

30

marzo 2002 P. Atzeni, UML 59

Modello degli stati

• Permettono di descrivere il "ciclo di vita" di classi, oggetti, use, case o anche dell'intero sistema

• Un oggetto ha una "storia" e il suo comportamento dipende dalla storia (memorizzata nello stato)

• Concetti importanti– evento che richiede una reazione del sistema– stato: condizione di un oggetto in un certo momento– transizione: il passaggio da uno stato ad un altro a seguito di

un evento

marzo 2002 P. Atzeni, UML 60

Lo stato civile di una persona

Libero/a

nascita

Coniugato/a

matrimonio

Separato/aseparazione

divorzio

Vedovo/a

decesso del coniuge

decesso del coniuge

matrimonio

Page 31: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

31

marzo 2002 P. Atzeni, UML 61

Tipi di diagrammi di stato

• Relativi a – classi di oggetti

• hanno senso se gli oggetti rispondono agli eventi non sempre nello stesso modo

• descrivono come (e perché) gli oggetti cambiano sottoclassi

• può essere utile (ma non è necessario) che le sottoclassi compaiano nello schema concettuale

– use case (cioè al sistema nell'ambito di use case)• descrive la sequenza legale di eventi esterni

marzo 2002 P. Atzeni, UML 62

Diagramma di stato per uno use case

In attesa

vendita in corso

iniziovendita

attesapag.to

pagamento

acquisizioneProdottofineProdotti

Page 32: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

32

marzo 2002 P. Atzeni, UML 63

Progettazione

• La vediamo in modo abbastanza superficiale (giustificato dalla relativa semplicità delle applicazioni di interesse)

• Obiettivo è la definizione delle classi del nostro sistema• Possiamo procedere in due passi:

– definizione preliminare delle classi ("analysis classes") e distinzione in classi di interfaccia, di controllo e di entità

– attribuzione delle responsabilità alle classi e raffinamento delle classi (soprattutto a quelle di controllo)

– definizione della tipologia realizzativa delle classi (jsp, servlet, classi di supporto)

marzo 2002 P. Atzeni, UML 64

Architettura a tre livelli

Presentazione

Logica applicativa

Gestione dei dati

BD

Page 33: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

33

marzo 2002 P. Atzeni, UML 65

Classi e architettura a tre livelli

• La progettazione può iniziare con una riflessione sugli use-case, sulle loro operazioni (e sui rispettivi contratti), volta ad individuare le attività necessarie, in termini di– interazione con l'utente (in entrambe le direzioni)– processi da svolgere– dati da gestire (e mantenere)

• Allo scopo, si possono individuare gli "elementi del sistema chepresentano responsabilità e comportamento", detti "analysis classes":– boundary objects– control objects– entity objects

marzo 2002 P. Atzeni, UML 66

Analisys objects

• Boundary objects: interfacce fra attori e sistema (schermate, menu; nel mondo Web: pagine)

• Control objects: i processi del sistema (ad esempio: calcolo degli stipendi; gestione degli ordini)

• Entity objects:oggetti persistenti descritti negli use case

Page 34: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

34

marzo 2002 P. Atzeni, UML 67

Meccanismi di estensibilità in UML

• Estensioni; ricordiamo:– 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

marzo 2002 P. Atzeni, UML 68

Analisys objects

• Boundary objects: interfacce fra attori e sistema (schermate, menu; nel mondo Web: pagine)

• Control objects: i processi del sistema (ad esempio: calcolo degli stipendi; gestione degli ordini)

• Entity objects:oggetti persistenti descritti negli use case

• Regole (vincoli):– gli attori interagiscono solo con boundary objects– gli entity objects interagiscono solo con control objects– i control objects possono interagire con oggetti di ogni tipo

(inclusi altri control objects)

Page 35: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

35

marzo 2002 P. Atzeni, UML 69

Un diagramma con "analysis objects"

Impiegato

PaginaNuoviClienti

InserimentoClienti

Cliente

ClienteVIPInserimentoVIP

marzo 2002 P. Atzeni, UML 70

Raffinamento delle classi

• Per progettare le classi, si debbono attribuire le responsabilità (le operazioni)

• Possiamo partire dai contratti, che dettagliano le responsabilità soprattutto in termini di postcondizioni

• Anche i diagrammi di stato possono essere utili• Per raffinare le classi e attribuire le "responsabilità" (cioè le

operazioni), si definiscono di solito diagrammi di sequenza (piùdettagliati dei diagrammi di sequenza di sistema visti nella fase di analisi)

Page 36: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

36

marzo 2002 P. Atzeni, UML 71

Un diagramma di sequenza di sistema

: Cliente:Sistema

acquisto()

listaEConto

modalitàPagamento()

richiestaConferma

conferma()

esito, ricevuta

marzo 2002 P. Atzeni, UML 72

Un diagramma di sequenza dettagliato (parte)

Clienteacquisto()

PagCarrello Acquisto

acquisto()

Carrello Prodotti

contenuto()

dettaglio()

totale()

CostruiscilConto()

PagConto

listaEConto

Page 37: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

37

marzo 2002 P. Atzeni, UML 73

Stereotipi per pagine sul client e sul server

<<builds>>

<<submits>>

marzo 2002 P. Atzeni, UML 74

"Traduzione"

• Punto di partenza:– Boundary objects: pagine client– Control objects: pagine server (JSP o servlet)– Entity objects:classi per l'accesso alla base di dati

Page 38: UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3 UML: principi ispiratori • Modellazione (ovviamente non finalizzata a se stessa,

38

marzo 2002 P. Atzeni, UML 75

Un diagramma di sequenza "concreto"

Clienteacquisto()

PagCarrello Acquisto

acquisto()

Carrello Prodotti

contenuto()

dettaglio()

totale()

CostruiscilConto()

PagConto

listaEConto

marzo 2002 P. Atzeni, UML 76

Ulteriori diagrammi di interesse

• Diagramma delle classi con associazioni• Diagramma delle pagine dal punto di vista del client

(essenzialmente lo schema ADM)