UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3...
Transcript of UML - dia.uniroma3.itatzeni/didattica/SD/materiale/uml2002.pdf · 2 marzo 2002 P. Atzeni, UML 3...
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
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
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
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
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
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
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
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à
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
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
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
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
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
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)
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
*
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>>
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
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
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
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 ...
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)
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
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
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
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
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
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
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
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)
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
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
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
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
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)
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)
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
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
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)