Rosario Culmone UNICAM 2
Obiettivi del corso
• Acquisire competenze sulla modellazione di sistemi informatici• Acquisire competenze sull’uso di strumenti per la progettazione
(UML)• Acquisire competenze sulla modellazione mediante l’uso di
strumenti automatici CASE (ArgoUML)
Rosario Culmone UNICAM 3
Programma del corso
• Ingegneria del software• Introduzione• L’Ingegneria del Software
• Uml• Introduzione• Storia• Architettura• I 9 diagrammi• Sintesi UML• Bibliografia
• Ocl• Introduzione• Storia• Constraint
• Invarianti• Precondizioni• Postconditioni
• Vantaggi• Bibliografia
• Meccanismi di Estensione di UML• Design Pattern
• Introduzione• Concetti• Cataloghi• Esempi• Bibliografia
Rosario Culmone UNICAM 4
Prerequisiti
• Aver sostenuto esame di Programmazione e Laboratorio di Programmazione
• Buono conoscenza del paradigma ad oggetti
Rosario Culmone UNICAM 5
Strumenti
• ArgoUML (http://argouml.tigris.org/)• Compilatore OCL (http://dresden-ocl.sourceforge.net/)• Compilatore Java (http://java.sun.com/)• Editore di testi
Rosario Culmone UNICAM 6
Metodologia
• Ogni argomento trattato viene seguito da esercizi• Vengono proposti esercizi che lo studente dovrà svolgere in
gruppo o singolarmente• Le esercitazioni sono svolte in laboratorio• La frequenza non è obbligatorio ma consigliata
Rosario Culmone UNICAM 7
Esame
• Progetto proposto dal docente o studenti assegnato a metà corso
• Sviluppo del progetto anche in gruppo (max 3 componenti)• Esame orale sostenuto da tutti i componenti del gruppo che
consiste nella discussione del progetto
Rosario Culmone UNICAM 8
Progetto
• Ha validità annuale (da inizio corso a inizio corso successivo)• Consiste nella realizzazione di un documento con determinate
caratteristiche• Mette in evidenza le capacità di utilizzare le conoscenze e le
competenze acquisiste durante il corso• Ha una struttura predefinita• Ha un complessità predefinita• La produzione del codice è facoltativa
Rosario Culmone UNICAM 9
Testi
• “Introduzione a UML”, Simon Bennett, John Skelton, Ken Lunn, McGraw-Hill, pagine 355, Euro 24,50
• “Fondamenti di UML”, Roff Jason T, McGraw-Hill, pagine 295, Euro 23,50
• “UML Distilled Guida rapida al linguaggio di modellazione standard”, Fowler Martin, Pearson Education Italia, pagine 162, Euro 25,00
Rosario Culmone UNICAM 12
Introduzione
• La progettazione dei sistemi software è una disciplina giovane ed immatura
• Una indagine della Standish Group, basata su un campione di 28.000 progetti e pubblicata da Computer Weekly il 9 luglio 1998, fornisce questi risultati: • progetti riusciti: 26%• progetti chiusi con notevole ritardo sui tempi, e/o costi
imprevisti, e/o funzionalità inadeguate: 46%• progetti falliti: 28%
Rosario Culmone UNICAM 13
Introduzione
Esempio di produzione del software:• Il programmatore ascolta le esigenze del cliente• Il programmatore scrive il codice che soddisferà le varie esigenze
Rosario Culmone UNICAM 14
Introduzione
Questo metodo di produzione del software è valido se:• Il problema è molto semplice• Il cliente formuli il problema in modo chiaro• Il programmatore capisca esattamente cosa il cliente si aspetta• Il programmatore lavora senza la collaborazione di altri colleghi
Rosario Culmone UNICAM 15
Introduzione
Questo metodo è diventato inadatto quando:• Le esigenze dei clienti sono aumentate• La complessità del problema è aumentata• Un unico programmatore non era sufficiente per la completa
produzione del software
Rosario Culmone UNICAM 16
Introduzione
La produzione del software quindi deve:• Supportare un processo industriale• Rispettare i requisiti e le aspettative richieste dal committente• Evitare ambiguità ed inconsistenze• Offrire un valido metodo per la corretta comunicazione delle intuizioni• Fornite validi metodi per la riusabilità del codice• Dare un supporto veloce e sicuro per le attività di manutenzione del
codice
Ingegneria del Software
Rosario Culmone UNICAM 17
Ingegneria del Software
• È una tecnologia stratificata per il rispetto della qualità
Strumenti
Metodi
Processo
Qualità
Rosario Culmone UNICAM 18
Ingegneria del Software
Processo• Lo strato fondamentale dell’ingegneria del software• Forma la base del controllo gestionale dei progetti software• Stabilisce il contesto in cui si applicano i livelli tecnologici
(metodi e strumenti)• Si creano prodotti intermedi• Si stabiliscono punti di controllo• Si controlla la qualità• Si gestiscono le modifiche
Rosario Culmone UNICAM 19
Ingegneria del Software
Metodi• Comprendono una vasta gamma di attività
• Analisi dei requisiti• Progettazione• Scrittura del Codice• Collaudo• Manutenzione
Rosario Culmone UNICAM 20
Ingegneria del Software
Analisi dei requisiti• Si definiscono i domini delle informazioni• le varie funzionalità• i comportamenti• le prestazioni• le interfacce richieste
Rosario Culmone UNICAM 21
Ingegneria del Software
Progettazione• Si definiscono le strutture dati• Le funzioni ed i comportamenti in modo da rispettare i requisiti
ed i vincolo richiesti• Si definiscono i protocolli di comunicazione tra le parti che
compongono il software
Rosario Culmone UNICAM 22
Ingegneria del Software
Scrittura del Codice• Si costruisce il codice pensando ad un suo successivo riuso• Si adeguano parti riutilizzabili per il nuovo uso• Si integrano tutti gli elementi
Rosario Culmone UNICAM 23
Ingegneria del Software
Collaudo• Si esegue il test del comportamento del software• Si verifica il rispetto di tutto i requisiti richiesti• Si verifica il raggiungimento di tutti i vincoli• Si controlla l’integrazioni dei vari componenti nuovi e riutilizzati
Rosario Culmone UNICAM 24
Ingegneria del Software
Manutenzione• Si modifica il software allo scopo di eliminare i difetti• Si adatta il software per un nuovo ambiente (diverso sistema
operativo, cambiamenti esterni al prodotto, adattamento a nuove regole)
• Si introducono nuove funzionalità oltre i requisiti originari• Si modifica il software per rendere più semplici le correzioni, gli
adattamenti e le migliorie
Rosario Culmone UNICAM 25
Ingegneria del Software
Strumenti• Forniscono al processo e ai metodi un supporto semi-automatico
o automatico• Vari strumenti possono essere combinati per integrare i risultati
(sistema di supporto allo sviluppo di software CASE)• CASE è costituito da:
• Software• Hardware• Database (archivio di informazioni relative ad analisi,
progettazione, costruzione e collaudo dei programmi)
Rosario Culmone UNICAM 26
UML – Unified Modeling Language
• E’ un linguaggio (standard OGM tra poco ISO) formale per specificare, visualizzare, costruire e documentare astrazioni
• E’ applicabile a differenti tipi di sistema, di domini e di modelli di processo
• E’ uno strumento basato sulla descrizione di architetture per sistemi component-oriented e object-oriented
• Definisce una notazione prevalentemente grafica contenente simboli e concetti (sintassi e semantica)
Rosario Culmone UNICAM 27
UML
• E’ indipendente da qualsiasi linguaggio di programmazione• E’ applicabile a qualsiasi livello di astrazione• Può coprire l’intero processo di produzione del software• E’ altamente estendibile per modellare meglio le diverse realtà
Rosario Culmone UNICAM 28
UML - StoriaBoochOOD 91OOAD94
RumbaughOMT 91
Jacobson(Objectory/OOSE) 92
94 RATIONAL
Ott. 95Unified Method Notation (v 0.8)
Ott. 95RATIONAL
Lug. 95Unified Modeling Language (v 0.9)
Microsoft, HP,Oracle e altri(consorzio)
Gen. 97UML 1.0
IBM, Platinum e altri (consorzio)
Nov. 97UML 1.1 Dic. 98
UML 1.2
Giu. 99UML 1.3
Mag. 01UML 1.4
Grady Booch
Jim Rumbaugh
Ivar Jacobson
Rosario Culmone UNICAM 29
UML - Utilizzo
• Per visualizzare un sistema• Per specificare la struttura ed il comportamento di un sistema• Per definire le linee guida per la costruzione di un sistema• Per documentare le decisioni prese
Rosario Culmone UNICAM 30
UML - Architettura
• Si basa su una struttura composta da quattro livelli di metamodelli
M e t a - m e t a m o d e l
M e t a m o d e l
M o d e l
U s e r o b j e c t
Rosario Culmone UNICAM 31
UML - Architettura
• Meta-Metamodel:• E’ il padre di tutti gli elementi• Viene usato per formalizzare la
notazione e definire le specifiche di linguaggio per il metamodel
M e t a - m e t a m o d e l
M e t a m o d e l
M o d e l
U s e r o b j e c t
Rosario Culmone UNICAM 32
UML - Architettura
• Metamodel:• Ogni oggetto del metamodel è una
istanza dei concetti del meta-metamodel• Qui si descrivono astrazioni di modelli
object-oriented e component-oriented• Si definiscono linguaggi per definire
domini e modelli
M e t a - m e t a m o d e l
M e t a m o d e l
M o d e l
U s e r o b j e c t
Rosario Culmone UNICAM 33
UML - Architettura
• Model:• Qui si definiscono i domini, i problemi e
le soluzioni di sistemi
M e t a - m e t a m o d e l
M e t a m o d e l
M o d e l
U s e r o b j e c t
Rosario Culmone UNICAM 34
UML - Architettura
• User object:• E’ composto da elementi che
semplificano i modelli UML• Qui si descrivono le specifiche
informazioni del dominio
M e t a - m e t a m o d e l
M e t a m o d e l
M o d e l
U s e r o b j e c t
Rosario Culmone UNICAM 35
UML - Notazione
• La notazione grafica rappresenta i diversi aspetti del proprio sistemi attraverso le cosiddette “viste”
• Esistono nove tipi di diagrammi, alcuni rivolti all’aspetto statico del sistema (che non evolve nel tempi), altri a quello dinamico.
Rosario Culmone UNICAM 36
UML - NotazioneVista Strutturale Vista di
Implementazione
Vista Comportamentale
Vista di Ambiente
Vista UtenteClass diagramsObject diagrams
Sequence diagramsCollaboration diagramsStatechart diagramsActivity diagrams Deployment diagrams
Component diagramsUse case diagrams
Rosario Culmone UNICAM 37
UML - Notazione
Vista Strutturale Vista di Implementazione
Vista Comportamentale Vista di Ambiente
Vista Utente
Class diagramsObject diagrams
Sequence diagramsCollaboration diagramsStatechart diagramsActivity diagrams
Deployment diagrams
Component diagrams
Use case diagrams
Vista Utente:Descrizione del comportamento del sistema dal punto di vista degli utenti
Rosario Culmone UNICAM 38
UML - Notazione
Vista Strutturale Vista di Implementazione
Vista Comportamentale Vista di Ambiente
Vista Utente
Class diagramsObject diagrams
Sequence diagramsCollaboration diagramsStatechart diagramsActivity diagrams
Deployment diagrams
Component diagrams
Use case diagrams
Vista Strutturale:Requisiti funzionali e servizi che il sistema deve supportare
Rosario Culmone UNICAM 39
UML - Notazione
Vista Strutturale Vista di Implementazione
Vista Comportamentale Vista di Ambiente
Vista Utente
Class diagramsObject diagrams
Sequence diagramsCollaboration diagramsStatechart diagramsActivity diagrams
Deployment diagrams
Component diagrams
Use case diagrams
Vista di Implementazione:Configurazione dei componenti che costituisconoil sistema fisico
Rosario Culmone UNICAM 40
UML - Notazione
Vista Strutturale Vista di Implementazione
Vista Comportamentale Vista di Ambiente
Vista Utente
Class diagramsObject diagrams
Sequence diagramsCollaboration diagramsStatechart diagramsActivity diagrams
Deployment diagrams
Component diagrams
Use case diagrams
Vista Comportamentale:Descrizione del comportamento interno del sistema da un punto di vista strutturale
Rosario Culmone UNICAM 41
UML - Notazione
Vista Strutturale Vista di Implementazione
Vista Comportamentale Vista di Ambiente
Vista Utente
Class diagramsObject diagrams
Sequence diagramsCollaboration diagramsStatechart diagramsActivity diagrams
Deployment diagrams
Component diagrams
Use case diagrams
Vista di Ambiente:Topologia degli host del sistema, la loro interazionesu rete e la distribuzione dei processi
Rosario Culmone UNICAM 42
UML - Notazione
• Viste Statiche• Use Case Diagrams• Class Diagrams• Object Diagrams• Component Diagrams• Deployment Diagrams
• Viste Dinamiche• Sequence Diagrams• Collaboration Diagrams• Statechart Diagrams• Activity Diagrams
Rosario Culmone UNICAM 43
Elementi comuni a tutti i diagrammi
• Nota• E’ un commento espresso attraverso il linguaggio naturale• E’ molto utile per integrare e aumentare la comprensione della
notazione
Nota
Rosario Culmone UNICAM 44
Elementi comuni a tutti i diagrammi
• Associazione con la Nota• Una nota può essere agganciata ad ogni elemento
o relazione del diagramma
Nota
Rosario Culmone UNICAM 45
Use Case Diagrams
• Rappresentano le modalità di utilizzo del sistema da parte di uno o più utilizzatori (attori)
• Descrivono l’interazione tra attori e sistema, senza rivelare l’organizzazione interna del sistema
• Sono espressi in forma testuale, comprensibile anche per i non “addetti ai lavori”
• Possono essere definiti a livelli diversi (sistema o parti del sistema)
Rosario Culmone UNICAM 46
Use Case Diagrams
• Servono, nelle fasi iniziali di progettazione, per chiarire cosa dovrà fare il sistema
• Servono per colloquiare con il cliente e per scoprire ed analizzare i requisiti del sistema
• Una volta definiti guidano l’intero sviluppo del progetto• Sono il riferimento primario per la definizione, la progettazione,
l’esecuzione dei test per la verifica dei requisiti
Rosario Culmone UNICAM 47
Use Case Diagrams
• Esempio: Un videoregistratore• Vista del progettista:
• All’interno vi sono dei componenti• Ogni componente svolge funzioni particolari• Ogni componente deve essere utilizzato correttamente e
rispettare dei requisiti• Vista dell’utente
• Nel manuale c’e’ la descrizione di come può essere utilizzato• Come si inserisce una cassetta• Come si effettua il fermo immagine• Ecc…ecc..
Rosario Culmone UNICAM 48
Use Case Diagrams - Elementi
• Casi d’uso• Sono le funzionalità che il sistema mette a disposizione dei suoi
utilizzatori• Descrivono il sistema da un punto di vista esterno (black box)• E’ rappresentato con un’icona a forma di ellisse
Rosario Culmone UNICAM 50
Use Case Diagrams - Elementi
• Attori• Sono i soggetti (esterni) che interagiscono con il sistema• Possono rappresentare: esseri umani, sistemi HW o SW• Ogni attore corrisponde ad un insieme coerente di ruoli che i
soggetti possono assumere interagendo con il sistema
Rosario Culmone UNICAM 52
Use Case Diagrams - Elementi
• Sistema• Contiene un insieme di casi d’uso riguardanti un particolare
sistema• Descrive in modo completo gli utilizzi del sistema dall’esterno• Non rileva la struttura interna del sistema• Gli attori sono esterni al sistema
Rosario Culmone UNICAM 54
Use Case Diagrams - Associazioni
• Attori e casi d’uso• Ha il significato di comunicazione• Ogni caso d’uso è collegato agli attori (uno o più)• Per evidenziare la direzione della comunicazione l’associazione
può essere orientata
Rosario Culmone UNICAM 55
Use Case Diagrams - Associazioni
• Esempio associazione Attore - Caso d’Uso:
Rosario Culmone UNICAM 56
Use Case Diagrams - Associazioni
• Associazioni tra Attori• L’unica associazione ammessa tra attori è la specializzazione• L’attore specializzato eredita la partecipazione a tutti i casi
d’uso con i quali comunica l’attore generico• L’attore specializzato può partecipare ad ulteriori casi d’uso ai
quali l’attore generico non e’ collegato
Rosario Culmone UNICAM 58
Use Case Diagrams - Associazioni
• Tra Casi d’Uso• Non è ammessa in UML una associazione di comunicazione tra
i casi d’uso (un caso d’uso descrive un utilizzo completo del sistema)
• Non è ammessa la suddivisione di una funzionalità completa in casi d’uso distinti
Rosario Culmone UNICAM 59
Use Case Diagrams - Associazioni
• Tra Casi d’Uso - Specializzazione• Ogni caso d’uso specializzato eredita le caratteristiche, i passi, i
punti di estensione e le associazioni del caso d’uso generale• Il caso d’uso specializzato può aggiungere nuovi passi o
ridefinire i passi ereditati da quello generale• Ogni caso d’uso generale può avere più figli• Ogni caso d’uso specializzato può avere più padri
Rosario Culmone UNICAM 60
Use Case Diagrams - Associazioni
• Esempio associazione di specializzazione Caso d’uso – Caso d’uso:
Richiesta estratto contodallo sportello
Richiesta estratto contodal bancomat
Richiesta estratto conto
Rosario Culmone UNICAM 61
Use Case Diagrams - Associazioni
• Tra Casi d’Uso - <<include>>• Casi d’uso diversi possono avere in comune una sequenza di
passi da svolgere• La sequenza comune può essere esportata e definita come un
caso d’uso a sè stante• Il caso d’uso che si ripete verrà poi incluso in altri casi d’uso• In questo modo si evidenziano le parti in comune
Rosario Culmone UNICAM 62
Use Case Diagrams - Associazioni
• Esempio associazione <<include>> Caso d’uso – Caso d’uso:
Rosario Culmone UNICAM 63
Use Case Diagrams - Associazioni
• Tra Casi d’Uso - <<extend>>• Permette di definire che un caso d’uso “base” può venire
“esteso” con il comportamento definito da un altro caso d’uso• L’estensione riguarda un comportamento opzionale del caso
d’uso base (l’estensione e’ soggetta ad una condizione di attivazione)
• La direzione dell’associazione di estensione va dal caso d’uso “di estensione” al caso d’uso “base”
Rosario Culmone UNICAM 64
Use Case Diagrams - Associazioni
• Esempio associazione <<extend>> Caso d’uso – Caso d’uso:
Rosario Culmone UNICAM 65
Use Case Diagrams - Sistemi
• Sottosistemi• Ogni sistema può essere strutturato in parti distinte• Ogni parte distinta interagisce con l’altra per fornire le
funzionalità complessive di tutto il sistema
Rosario Culmone UNICAM 71
Class Diagram
• Rappresenta il sistema attraverso una visione statica• E’ il modello più importante in UML perché definisce gli elementi
base del sistema• Rappresenta gli oggetti che compongono il sistema, ed i relativi
attributi e comportamenti• Specifica, mediante le associazioni, i vincoli che legano tra loro le
classi
Rosario Culmone UNICAM 72
Class Diagram - Elementi
• Classe• Una classe modella un insieme di oggetti omogenei ai quali sono associate
proprietà statiche e dinamiche• Ogni classe è descritta da:
• Nome• Attributi (lo stato)• Metodi (il comportamento)
Rosario Culmone UNICAM 74
Class Diagram - Elementi
• Classe - Visibilità• Ogni attributo e metodo può avere varie caratteristiche:
• Pubblico• Protetto• Privato
Rosario Culmone UNICAM 76
Class Diagram - Elementi
• Classe Astratta• E’ una classe che non ha una concreta implementazione ma
ha solo la dichiarazione delle operazioni
Rosario Culmone UNICAM 78
Class Diagram - Elementi
• Classe Interfaccia• E’ una classe solitamente implementata come astratta• Una classe provvede una particolare implementazione ma le
altre classi potranno interagire con essa usando una interfaccia• Si aumenta notevolmente l’indipendenza tra le classi
Rosario Culmone UNICAM 80
Class Diagram - Elementi
• Package• I package sono contenitori di classi• Aiutano a modellare sistemi complessi• Possono esistere Package e sottopackage• Si tende ad inserire nel package classi che hanno un comportamento e
scopo comune nel sistema• E’ possibile definire relazioni tra package
Rosario Culmone UNICAM 82
Class Diagram - Associazioni
• Associazione• Una associazione definisce un canale di comunicazione tra due classi• Definisce una relazione tra classi• Una associazione può avere un nome• Il nome è solitamente un verbo• Può avere una direzione per distinguere meglio in verso della
comunicazione
Rosario Culmone UNICAM 84
Class Diagram - Associazioni
• Associazione con Molteplicità• Definisce il numero di istanze che prendono parte alla
relazione• Definisce se la relazione è obbligatoria o no• Definisce il numero minimo e massimo di oggetti che
possono essere relazionati ad un altro oggetto
Rosario Culmone UNICAM 85
Class Diagram - Associazioni
• Associazione con Molteplicità• La molteplicità può essere:
• 1 : esattamente uno• 0..1 : zero o uno• 0..* : zero a molti• 1..* : uno a molti• 7 : un numero specifico• 2..4 : un intervallo specifico• 1..3, 5..* : una lista di intervalli
Rosario Culmone UNICAM 87
Class Diagram - Associazioni
• Ruolo• Definisce un nome specifico per ogni ruolo che ha
l’associazione con la classe• E’ utile per auto associazioni• E’ utile per associazioni multiple tra due classi
Rosario Culmone UNICAM 89
Class Diagram - Associazioni
• Classi di associazioni• Definiscono delle proprietà che appartengono alla
associazione e non alle classi coinvolte
Rosario Culmone UNICAM 91
Class Diagram - Associazioni
• Aggregazione• Le aggregazioni sono una forma particolare di associazione• Definisce una associazione del tipo “parte di”• E’ una associazione asimmetrica
Rosario Culmone UNICAM 93
Class Diagram - Associazioni
• Composizione• E’ una forma di associazione più stringente di aggregazione• La loro esistenza ha senso solo in relazione al contenitore• Se si cancella il contenitore si cancellano anche le parti
Rosario Culmone UNICAM 95
Class Diagram - Associazioni
• Generalizzazione• Esplicita particolari comportamenti comuni• E’ una associazione tra una “superclasse” ed una o più
versioni più rifinite• Le sottoclassi ereditano gli attributi e le operazioni della
superclasse• Una sottoclasse può ridefinire operazioni
Rosario Culmone UNICAM 97
Class Diagram - Associazioni
• Realizzazione• E’ una particolare associazione tra due descrizioni dello stesso
elemento ma con un livello differente di astrazione• E’ una associazione tra una interfaccia e la sua
implementazione• Indica che una classe implementa il comportamento
specificato da un’altra
Rosario Culmone UNICAM 99
Class Diagram - Associazioni
• Dipendenza• L’associazione dipendenza indica che il cambiamento della
classe “master” implica un cambiamento nella classe “slave”• E’ importante ridurre al minimo le dipendenza per supportare
al meglio i cambiamenti
Rosario Culmone UNICAM 101
Libro
-cod_libro-data acquisizione-data_edizione-ISBM-titolo
+create()+restituzione()+richiesta()
Lettore
-Cognome-Indirizzo-Nome-Telefono
+variazione dati anagrafica()
Editore
-indirizzo-nome-ragione_sociale-telefono
+variazione dati editore()
Autore
-anno morte-anno nascita-cognome-nome
+variazione anagrafica()
Libro Prezioso
-valore
+valorizza()Prestito
-data
1..* 1..*
scritto
0..1
0..1
0..*
1
pubblicatoClass Diagram
• Esempio:
Rosario Culmone UNICAM 105
• Esercizio: come rappresentare attraverso un class diagram la struttura dati lista
Class Diagram
Rosario Culmone UNICAM 106
• Esercizio: come rappresentare attraverso un class diagram la struttura dati lista
Elemento
-Padre 1
-Figlio0..1
Class Diagram
Rosario Culmone UNICAM 107
• Esercizio: si vuole modellare un salotto che ha a disposizione un televisore oppure un impianto stereo, ma non tutti e due
Class Diagram
Rosario Culmone UNICAM 108
• Esercizio: si vuole modellare un salotto che ha a disposizione un televisore oppure un impianto stereo, ma non tutti e due
Salotto
StereoTV
0..1 0..1
Class Diagram
Rosario Culmone UNICAM 109
• Esercizio: si vuole modellare un salotto che ha a disposizione un televisore oppure un impianto stereo, ma non tutti e due
Solo una associazione � valida in ogni istante
TV Stereo
Salotto
0..1 0..1
Class Diagram
Rosario Culmone UNICAM 110
• Esercizio: si vuole modellare un salotto che ha a disposizione un televisore oppure un impianto stereo, ma non tutti e due
{XOR}
Salotto
StereoTV
0..1 0..1
Class Diagram
Rosario Culmone UNICAM 111
Class Diagram
• Esercizio: si vuole modellare un salotto che ha a disposizione un televisore oppure un impianto stereo, ma non tutti e due
Device
Stereo
Salotto
TV
1
Rosario Culmone UNICAM 112
Object Diagram
• Rappresenta una particolare configurazione del sistema• E’ composto da un insieme di oggetti (istanze) e le rispettive
relazioni in un preciso istante di tempo• Viene usato per rappresentare una particolare vista del sistema a
run-time• Può essere anche visto come un collaboration diagram senza
l’utilizzo di messaggi
Rosario Culmone UNICAM 113
Object Diagram - Elementi
• Object• Rappresenta una singola entità• In un ambiente object-oriented rappresenta una istanza• Mostra lo stato dell’oggetto in un particolare istante
Rosario Culmone UNICAM 115
Object Diagram - Relazioni
• Link• Rappresenta la relazione tra gli oggetti in un particolare istante
di tempo• E’ una particola istanza delle associazioni del class diagram
Rosario Culmone UNICAM 118
Object Diagram
• Esercizio: rappresentare attraverso un’object diagram il seguente class diagram
D
CB
A
1
0..*
1
1
1
0..*
1
1
Rosario Culmone UNICAM 119
Object Diagram
• Esercizio: rappresentare attraverso un’object diagram il seguente class diagram
b2: B c2: Cb1: B
a1: A a2: A
c1: C
d1: D
Rosario Culmone UNICAM 120
Object Diagram
• Esercizio: rappresentare attraverso un’object diagram il seguente class diagram
a'2: A a2: A
b1: B
a1: A
c2: C
a'1: A
c1: C
d1: D
b2: B
Rosario Culmone UNICAM 121
Sequence Diagram
• Descrive il comportamento dinamico di un gruppo di oggetti • Evidenzia il modo in cui uno scenario (uno specifico percorso in
un caso d’uso) viene risolto dalla collaborazione tra un insieme di oggetti
• Non vengono rappresentate le relazioni ed associazioni tra gli oggetti
Rosario Culmone UNICAM 122
Sequence Diagram - Elementi
• Object• Rappresenta una singola
entità• In un ambiente object-
oriented rappresenta una istanza
• Può rappresentare una particolare istanza di un oggetto o di un attore
Rosario Culmone UNICAM 124
Sequence Diagram - Elementi
• Messaggio• Rappresenta la comunicazione tra due
oggetti• La comunicazione può essere:
• Sincrona• Asincrona
• I messaggi vengono spesso numerati per meglio mostrare la sequenza temporale delle azioni
Rosario Culmone UNICAM 125
Sequence Diagram - Elementi
• Activation• Rappresenta il tempo
durante il quale un oggetto esegue un’operazione
Rosario Culmone UNICAM 127
Sequence Diagram - Elementi
• Messaggio di Ritorno• Indica uno stimolo di ritorno dopo l’invio di un messaggio• Non rappresenta un nuovo messaggio• Si commette l’errore di utilizzarlo ogni volta che si invia un
nuovo messaggio• Deve essere utilizzato solamente per aggiungere informazioni
e per aumentare la comprensione del sistema
Rosario Culmone UNICAM 129
Sequence Diagram - Elementi
• Messaggio Ricorsivo• Indica un messaggio inviato a se stesso• E’ utile quando si voglio rappresentare comportamenti ricorsivi
Rosario Culmone UNICAM 131
Sequence Diagram - Elementi
• Create e Destroy:• Indica quando una
particolare istanza cessa di esistere
• Un oggetto può morire da solo o grazie all’invio di un messaggio da parte di un altro oggetto
• E’ utile quando si rappresentano contesti multithread
Rosario Culmone UNICAM 133
Sequence Diagram - Elementi
• Esecuzione Concorrente:• Indica quando alcune condizioni possono generare cammini diversi
Rosario Culmone UNICAM 137
Collaboration Diagram
• E’ simile al sequence diagram ma:• Evidenzia le interazione tra le parti• Rivolge maggiore attenzione allo scambio dei messaggi
• Non vi è una particolare dimensione per rappresentare il tempo• La sequenza temporale viene rappresentata dalla sola rappresentazione numerica• La sequenza dei messaggi è meno evidente che nel Sequence Diagram, mentre sono più
evidenti i legami tra gli oggetti
Rosario Culmone UNICAM 138
Collaboration Diagram - Elementi
• Object:• Rappresenta una singola entità• In un ambiente object-oriented rappresenta
una istanza• Può rappresentare una particolare istanza di
un oggetto o di un attore
Rosario Culmone UNICAM 140
Collaboration Diagram - Relazioni
• Link:• Rappresenta la relazione tra gli oggetti in un particolare istante di tempo• E’ una particola istanza delle associazioni del class diagram
Rosario Culmone UNICAM 142
Collaboration Diagram - Relazioni
• Link a se stesso:• Rappresenta una particolare istanza di associazione• Inizia e finisce nello stesso oggetti• Rappresenta una interazione con se stesso
Rosario Culmone UNICAM 143
Collaboration Diagram - Elementi
• Messaggio:• Rappresenta la comunicazione tra due oggetti• La comunicazione puo’ essere:
• Sincrona• Asincrona
• I messaggi vengono numerati per mostrare la sequenza temporale delle azioni• I messaggi si applicano ai link tra i diversi oggetti
Rosario Culmone UNICAM 145
Collaboration Diagram - Elementi
• Esercizio: implementare un collaboration diagram per la descrizione delle dipendenze e dei messaggi scambiati durante la cancellazione di un progetto
Rosario Culmone UNICAM 147
Sequence Diagram e Collaboration Diagram
• Esprimono informazioni simili ma le evidenziano in modo differente• Spesso non e’ necessario descrivere il sistema utilizzando entrambi i
diagrammi
Rosario Culmone UNICAM 148
Statechart Diagram
• Rappresenta il comportamento dei singoli oggetti di una classe in termini di• Eventi a cui gli oggetti sono sensibili• Azioni prodotte• Transizioni di stato
• E’ possibile grazie a questo diagramma descrivere evoluzioni parallele• In particolare descrivono il ciclo di vita degli oggetti di una classe, attraverso
modifiche causate da eventi che li interessano
Rosario Culmone UNICAM 149
Statechart Diagram - Elementi
• Stato Iniziale Stato Finale:• Rappresentano i punti iniziali e finali di uno statechart
Rosario Culmone UNICAM 151
Statechart Diagram - Elementi
• Stato:• Rappresenta la situazione nel tempi di un oggetto che esegue una attività o aspetta
qualche stimolo esterno
Rosario Culmone UNICAM 153
Statechart Diagram - Elementi
• Transizione:• Rappresenta la relazione tra due differenti stati di un oggetto• Ogni transizione potrà avere una etichetta
Rosario Culmone UNICAM 155
Statechart Diagram - Elementi
• Sintassi transizione:• Una transizione può essere associata a funzioni booleane su valori degli oggetti• Sono utili quando non basta l’evento, ma si vuole aggiungere un predicato
Rosario Culmone UNICAM 157
Statechart Diagram - Elementi
• Stato con Azione:• È spesso chiamato “attività”• E’ uno stato che ha azioni di entrata e di uscita• E’ usato per rappresentare uno stato che produce risultati• E’ utile per descrivere l’implementazione di una operazione
Rosario Culmone UNICAM 159
Statechart Diagram - Elementi
• Macro stato:• Un Macro stato aiuta a comprendere meglio azioni comuni di tutti i sotto stati• Separa le transizioni comuni
Rosario Culmone UNICAM 161
Statechart Diagram - Elementi
• Stato concorrente:• E’ utile quando un oggetto ha diversi ed indipendenti comportamenti• Non bisogna esagerare con gli stati concorrenti• Se sono presenti numerosi stati concorrenti è utile dividere l’oggetto in parti più semplici• In breve e’ una decomposizione AND
Rosario Culmone UNICAM 163
Statechart Diagram - Elementi
• History:• History può essere associato solo a stati non foglia• Quando l’esecuzione lascia uno stato con history viene salvato l’ultimo stato• Quando l’esecuzione ritorna in uno stato con history si riparte dallo stato salvato
Rosario Culmone UNICAM 168
Invalid number me ssage
Time -Out To ne
Fas t Bus y To ne
Dis co nnec ted
Id le
Dial To ne
Dialing
Co nne c te d
Co nne c ting
Ringing
Busy To ne
Phone state example
on hook
on hook
on hook
message done
on hook
on hook
on hook
on hook
timeout complete
on hook
on hook
timeout
inval id number
timeout
off hook
number busy
digit
phone answered
routed
val id number
zdigi t
TimerTick
phone cal led hangs up
busy trunk
Statechart Diagram - Esempi
• Esempio:
Rosario Culmone UNICAM 169
Activity Diagram
• Rappresenta sistemi di Workflow o la logica interna di un processo• Può essere usato in livelli di astrazione molto differenti• E’ un caso particolare di Statechart Diagram• Permette di rappresentare processi paralleli e la loro sincronizzazione• E’ molto utile quando è importante definire il comportamento dinamico degli
oggetti
Rosario Culmone UNICAM 170
Activity Diagram - Elementi
• Stato Iniziale Stato Finale:• Come nel Statechart Diagram rappresentano i punti iniziali e finali di uno statechart
Rosario Culmone UNICAM 172
Activity Diagram - Elementi
• Attività:• Una attività è uno stato in cui è in corso una specifica azione • Esempio:
• Digitare un tasto• Eseguire una routine• O un metodo di una classe
Rosario Culmone UNICAM 174
Activity Diagram - Elementi
• Action flow:• Rappresenta le relazioni tra differenti action state• Puo’ avere una label contenente condizioni booleane o descrizioni
Rosario Culmone UNICAM 176
Activity Diagram - Elementi
• Branch:• Ha un solo punto di ingresso e molti di output• Solo un cammino di uscita può essere preso• Può essere usato come un “if then else”
Rosario Culmone UNICAM 178
Activity Diagram - Elementi
• Fork e Join:• Fork ha un solo ingresso e più uscite• Join più ingressi ed una sola uscita• Rappresentano l’evoluzione parallela del sistema
Rosario Culmone UNICAM 180
Activity Diagram - Elementi
• Swimlanes:• Indicano chi sta eseguendo quella attività• Rappresenta attraverso zone verticali la responsabilità di una particolare classe o di
un particolare sottosistema
Rosario Culmone UNICAM 182
Pe rson
Drink Beverage
Find Beverage
Coffe e Making Machine
Pour Coffee
Brew Coffee
Turn On Machine
Put Filter in Machine
Put Coffee in Filter Add Water to Reservoir Get Cups
Person
[no coffee]
light goes out
coffeePot TurnOn
[found coffee]
Activity Diagram - Esempi
• Esempio:
Rosario Culmone UNICAM 183
Activity Diagram - Esempi
• Esempio:
System Internals
Go to Next Record
Go to PreviousRecord
Erase Record inPhone Memory/SIM
User Interface
Confirm Erase
Display "Erased"Message
Display Current Record
[Next is selected]
[Previous is selected]
[Not Confirmed]
[Erase Confirmed]
[Erase is selected]
Rosario Culmone UNICAM 184
System Internals
Check Whether SuchName Already Exists
Replace Entryin the Book
Insert NameInto the Book
Display Message"Saved"
Display Message"Replaced"
User Interface
Enter New Name
Ask For replacingExisting Record
Edit Name
Edit Number
Enter New Number
[Replace confirmed]
[New name is unique][Name exists]
[Replace Rejected]
Activity Diagram - Esempi
• Esempio:
Rosario Culmone UNICAM 185
Component Diagram
• Rappresenta l’organizzazione dei vari componenti del sistema• Può rappresentare unità fisiche, codici sorgenti, librerie, file, etc…etc• Rappresenta le varie dipendenze tra i componenti
Rosario Culmone UNICAM 186
Component Diagram - Elementi
• Componente:• Rappresenta un singolo modulo del sistema• Spesso un componente rappresenta un package del class diagram
Componente
Rosario Culmone UNICAM 187
Component Diagram - Elementi
• Esempio Componente:
animlogo.java
Scheduler
GUI
Rosario Culmone UNICAM 188
Component Diagram - Elementi
• Interfaccia:• Rappresenta l’interfaccia di un componente• Un componente può avere più interfacce
ComponenteInterfaccia
Rosario Culmone UNICAM 189
Component Diagram - Elementi
• Esempio Interfacce:
Unit Server Applic atio n
Co nfiguratio n
Applic atio n
Rosario Culmone UNICAM 190
Component Diagram - Relazioni
• Dipendenze:• Mostra come il cambiamento di un compomente causa il cambiamento di altri• E’ utile per mostrare quali sono i componenti che comunicano con un altro
Componente Master Componente Slave
Rosario Culmone UNICAM 191
Component Diagram - Relazioni
• Esempio Dipendenze:
animlo go .java
animator.java
animlogo .do c
animato r.d o c
home .html
Rosario Culmone UNICAM 192
Component Diagram - Esempi
• Esempio:
Database Server
Tabella Ordini
Tabella Clienti
Form Inserimento Ordini
Rosario Culmone UNICAM 193
Deployment Diagram
• Rappresenta la relazione fisica tra i componenti software e quelli hardware• E’ utile quando si ha la necessità di mostrare componenti e oggetti in un
sistema distribuito
Rosario Culmone UNICAM 194
Deployment Diagram - Elementi
• Nodo:• Ogni nodo rappresenta una unità computazionale• Mote volte viene usato per rappresentare un componente hardware
• Es:• Un semplice device• Un sensore• Un server• Un mainframe
Nodo
Rosario Culmone UNICAM 195
Deployment Diagram - Elementi
• Esempio Nodo:
Input Device
Server Printer
Rosario Culmone UNICAM 196
Deployment Diagram - Elementi
• Istanza di Nodo:• Rappresenta un particolare oggetto del sistema• In un contesto object-oriented rappresenta l’istanza di una classe
Nodo
Rosario Culmone UNICAM 197
Deployment Diagram - Elementi
• Esempio Istanza di Nodo:
Windows 2000 Server
Reception Computer
Epson Laser
Rosario Culmone UNICAM 198
Deployment Diagram - Relazioni
• Connection:• Rappresenta il percorso di comunicazione tra più nodi• Può rappresentare il protocollo di comunicazione utilizzato
NodoA NodoB
Rosario Culmone UNICAM 199
Deployment Diagram - Relazioni
• Esempio Connection:
Windows 2000 Server Epson Laser
Server
Parallela
TCP/IP
Rosario Culmone UNICAM 200
Deployment Diagram - Esempi
• Esempio:
Pilo t
Printe r
Serve r XDBMS
Gate
Cons o le
<<TCT/IP>> 1
Master
1
10
<<IPX>>
1
*
Rosario Culmone UNICAM 201
Component e Deployment Diagram
• Spesso è utile integrare i due diagrammi• L’integrazione rappresenta la distribuzione dei vari componenti nei
nodi del sistema
Rosario Culmone UNICAM 202
Component e Deployment Diagram
• Esempio:
Bill's Mac h ine : De ll Pentium MMX PC
Trans ac tio n\Clie nt
Lib rary
Client Pro gram
Rosario Culmone UNICAM 203
Liver Unit Server
<<object database>>J asmin
Healthc are Domain
Live r Unit Configuration
Liver Unit Se rve r Applic atio n
Applic atio n
Co nfiguratio n
Wind o ws Co mpatib le PC
Liver Unit Client Fac ade
<<user interface>>Liver Unit UI
Diab etes Unit Server
<<object database>>J asmin
Healthcare Do main
<<communication>>
<<TCT/IP>>
<<TCT/IP>>
Component e Deployment Diagram
• Esempio:
Rosario Culmone UNICAM 204
Benefici portati da UML
• Superamento della guerra dei metodi• Prima di UML vi erano decine di metodi di analisi e disegno object-oriented • Oggi, UML ha standardizzato la notazione e la semantica a livello internazionale
• Risponde le aspettative degli sviluppatori• Possibilità di descrivere sistemi molto complessi• Maggiore attenzione alla modellazione degli aspetti architetturali del sistema• Maggiore facilità di utilizzo e comprensione • L’architettura a meta-modello favorisce l’integrazione dei vari strumenti di supporto allo
sviluppo utilizzati dai progettisti
Rosario Culmone UNICAM 205
UML
• Intende rappresentare qualsiasi tipo di sistema software e non, a livelli di astrazione differenziati
• Il numero di elementi elevato e la possibilità di rappresentarli in modi diversi rende lo strumento molto flessibile ma anche complesso
• UML non suggerisce una sequenza prestabilita di realizzazione dei propri sistemi
• UML offre un’ampia gamma di possibilità e modalità di utilizzo, i progettisti sono liberi di scegliere
Rosario Culmone UNICAM 206
UML va adattato alle proprie esigenze
• Tra i fattori da considerare:• Tipologia di progetto
• Complessità• Rischio
• Esigenze di conformità a norme e standard• Comunicazione con i committenti• Comunicazione con i fornitori• Composizione, distribuzione e organizzazione dei gruppi di lavoro
E’ importante capire che non ha senso che tutti utilizzino UML nello stesso modo
Rosario Culmone UNICAM 207
UML in breve
• E’ uno standard: uniformità nei concetti e nelle notazioni utilizzate, interoperabilità tra strumenti di sviluppo, indipendenza dai produttori, dalle tecnologie
• E’ articolato: può rappresentare qualunque sistema software a diversi livelli di astrazione
• E’ complesso: va adattato e ritagliato in base alle specifiche esigenze dei progettisti e progetti, utilizzando solo ciò che serve nello specifico contesto
Rosario Culmone UNICAM 208
UML - Bibliografia
• Jonathan P.Browen e Michael G. Hinchey, Ten Commandments of Formal Methods. Oxford Univeristy, Cambridge
• Booch, Jacobson e Rumbaught, The Unifed Modeling Language for Object Oriented Development. Rational Software Corp.1999
• Booch,Rumbaugh e Jacobson,The Unified Modeling Language User Guide Addison Wesley, 1998
• Rumbaugh,Jacobson e Booch, The Modeling Language Reference Manual, Addison Wesley, 1999
• M. Fowler e K. Scott, UML Distilled, Addison Wesley, 1999• J. Warmer e A. Kleppe,The Object Constraint Language, Addison Wesley, 1999
Rosario Culmone UNICAM 209
UML - I tool più famosi
• Embarcadero• Rhapsody• Together J• Rational Rose• MagicDraw• UML Suite• ArgoUML• MetaEdit+
Rosario Culmone UNICAM 210
UML - Siti Web
• http://www.cetus-links.org• http://www.rational.com• http://www.omg.org
Rosario Culmone UNICAM 211
Esercizio
• Progettare attraverso i vari diagrammi UML un sistema informatico per l’apertura di un cancello tramite una tessera magnetica
• 1:Introduco la tessera magnetica• 2:Il sistema riconosce la presenza della tessera• 3:Il sistema accede all’archivio informatico• 4:Il sistema confronta i dati presenti sulla tessera con quelli presenti in archivio• 5:Il sistema riconosce la validità della tessera• 5 a:Il sistema non riconosce la validità della tessera• 6: Il sistema fa aprire il cancello• 6 a :Il sistema lascia il cancello chiuso
Rosario Culmone UNICAM 213
OCL - Introduzione
• I modelli grafici talvolta non sono sufficienti per una precisa e non ambigua specificazione
• Si ha la necessità di aggiungere nuove regole a quelle grafiche• Queste regole vengono solitamente descritte attraverso linguaggi
naturali (inadatti, ambigui e inconsistenti)
Rosario Culmone UNICAM 214
OCL - Storia
• I linguaggi formali basati su regole matematiche per molto tempo furono impiegati per la descrizione formale di modelli
• OCL nasce nel 1995 da Jos Warmer (IBM) sotto l’influenza di Syntropy (basato su Z)
• Nel 1996 OCL diviene uno standard e parte vitale di UML
Rosario Culmone UNICAM 215
OCL
• E’ un linguaggio formale di facile lettura e scrittura• E’ stato pensato per eliminare le difficoltà dei linguaggi formali
basati su modelli matematici• E’ basato sulle espressioni, ognuna delle quali è no side-effect• Le sue espressioni sono atomiche• Si ispira alla programmazione per contratto di Meyer (Eiffel)
Rosario Culmone UNICAM 216
OCL e UML
• Può arricchire l’espressività di UML• Può definire attraverso una sintassi chiara e non ambigua dei
vincoli• Può utilizzare gli elementi definiti all’interno dei diagrammi UML
(classi, associazioni..)
Rosario Culmone UNICAM 217
OCL - Sintassi
• OCL utilizza la dot notation comune hai linguaggi object-oriented• Ha un operatore freccia (->) per far riferimento a collezione di
oggetti
Rosario Culmone UNICAM 218
OCL – Constraint
• E’ una restrizione di uno o più valori di un modello• Vengono applicati alle relazioni o ai singoli elementi del modello
per restringere il loro uso• Le espressioni definite all’interno di un Constraint devono essere
vere per poter utilizzare l’elemento• Un contraint è composto da:
• Invariante• Preconditione• Postconditione
Rosario Culmone UNICAM 219
OCL – Constraint
• Esempio:context TypeName inv:
expressionContext: introduce il contesto dell’espressioneTypeName: il nome della classe o l’associazioneInv: il tipo di constraint (invariante preconditione o postconditione)
Rosario Culmone UNICAM 220
OCL – ConstraintExpression:
si possono utilizzare varie parole chiave• self : è usata per definire l’istanza del contesto• --commento : per i commenti• self.property : è il valore della proprietà di nome property di self• self.attribute : è il valore dell’attributo atribute di una particolare
istanza identificata da self.• self.operation(argument,..) : per riferire un’operazione di un
contesto• object.rolename : partendo da uno specifico oggetto di potrà
navigare attraverso le associazioni (se la molteplicità dell’associazione è “0..1” o “1” il valore dell’espressione è un oggetto altrimenti un insieme
Rosario Culmone UNICAM 221
OCL – Invariante
• È sempre accoppiata ad una classe o interfaccia• Un’invariante è un vincolo che definisce una condizione che deve
sempre risultare vera• E’ composta da espressioni che controllano l’esatto uso
dell’oggetto
Rosario Culmone UNICAM 222
OCL – Invariante
• Esempio:
Persona
-DataDiNascita : date-nome : string-titolo : string
+anni() : int
Persona{context Persona inv:
self.anni() > 0}
-DataDiNascita : date-nome : string-titolo : string
+anni() : int
Rosario Culmone UNICAM 223
OCL – Invariante
• Tramite l’OCL è possibile navigare attraverso i rolename• Se l’associazione ha molteplicità “0..*”..”*” il risultato sara un
insieme:• Set: un insieme non ordinato privo di duplicati• Bag: un insieme non ordinato con duplicati• Sequence: un insieme ordinato con duplicati
• Se non è specificata una particolare situazione per default l’insieme è un Set
Rosario Culmone UNICAM 224
OCL – Invariante
• Esempio:
Persona
-DataDiNascita : date-disoccupato : boolean-nome : string-titolo : string
+anni() : int
Compagnia
-nome : string-numeroImpiegati : int
-impiegato -datore
Rosario Culmone UNICAM 225
OCL – Invariante
• Esempio invarianti nelle associazioni:
Compagnia{context Compagnia inv:
self.impiegato->forAll(Persona.disoccupato=falseself.impiegato->notEmpty}
-nome : string-numeroImpiegati : int
Persona
-DataDiNascita : date-disoccupato : boolean-nome : string-titolo : string
+anni() : int
-impiegato -datore
Rosario Culmone UNICAM 226
OCL – Invariante
• Esempio invariante nella molteplicità dell’associazione:
Persona{context Persona inv:self.datore->size=1}
-DataDiNascita : date-disoccupato : boolean-nome : string-titolo : string
+anni() : int
Compagnia{context Compagnia inv:self.impiegato->size=1}
-nome : string-numeroImpiegati : int
-impiegato -datore
Rosario Culmone UNICAM 227
OCL – Invariante• Esempio invariante nella molteplicità dell’associazione:
Persona{context Persona inv:
self.moglie->notEmpty imples self.moglie.anni()>=18 andself.marito->notEmpty imples self.marito.anni()>=18
self.moglie->notEmpty imples self.moglie.sesso="F" andself.marito->notEMpty imples self.marito.sesso="M"}
-DataDiNascita : date-disoccupato : boolean-nome : string-sesso : char-titolo : string
+anni() : int
-moglie
0..1
-marito 0..1
Rosario Culmone UNICAM 228
OCL – Pre Postcondition
• Vengono associati ad operazioni e metodi del modello object-oriented• Preconditione: è un constraint che deve essere validato
all’inizio dell’esecuzione dell’operazione• Postconditione: è un constraint che deve essere validato al
termine dell’operazione
Rosario Culmone UNICAM 229
OCL – Pre Postcondition
• Esempio:
Microonde
-stato : boolean-temperatura : int
+accendere()+spegnere()
Rosario Culmone UNICAM 230
OCL – Pre Postcondition
• Esempio:
Microonde{context Microonde inv:
self.temperatura>0, context Microonde::spegnere() post:
stato=false, context Microonde::accendere() post:
stato=true}
-stato : boolean-temperatura : int
+accendere()+spegnere()
Rosario Culmone UNICAM 231
OCL – Pre Postcondition
• Esempio uso di pre e postcondition:
Compagnia{context Compagnia::assumere(p:Persona)
pre: not self.impiegato->includes(p)post: selft.impiegato->includes(p)}
-nome : string-numeroImpiegati : int
+assumere( p : Persona )
Persona
-DataDiNascita : date-disoccupato : boolean-nome : string-sesso : char-titolo : string
+anni() : int
-impiegato -datore
Rosario Culmone UNICAM 232
OCL – Pre Postcondition
• Esempio uso di result:
Persona{context Persona::reddito(a:int) : double post:
result > 500}
-DataDiNascita : date-disoccupato : boolean-nome : string-sesso : char-titolo : string
+anni() : int+reddito( anno : int ) : double
Compagnia{context Compagnia::assumere(p:Persona)
pre: not self.impiegato->includes(p)post: selft.impiegato->includes(p)}
-nome : string-numeroImpiegati : int
+assumere( p : Persona )
-impiegato -datore
Rosario Culmone UNICAM 233
OCL – Pre Postcondition
• Esempio uso di @pre:
Persona{context Persona::compleanno() post:
self.et�=self.et�@pre + 1}
-DataDiNascita : date-disoccupato : boolean-et� : int-nome : string-sesso : char-titolo : string
+anni() : int+compleanno()+reddito( anno : int ) : double
Rosario Culmone UNICAM 234
OCL - Vantaggi
• Migliore Documentazione• i constraints aggiungono al modello grafico maggiori
informazioni• I constraints possono essere fusi graficamente nella stessa
descrizione
Rosario Culmone UNICAM 235
OCL - Vantaggi
• Migliore Precisione• I constraints non possono essere interpretati differentemente
da diverse persone• Sono non ambigui e consistenti
Rosario Culmone UNICAM 236
OCL - Vantaggi
• Migliore Comunicazione• La comunicazione attraverso linguaggi naturali è spesso
responsabile di fallimenti o aumenti di budget• Con OCL la comunicazione delle intuizioni avviene in modo
non ambiguo e preciso• Attraverso l’OCL i fraintendimenti nasceranno nelle prime
fasi del ciclo di vita dell’applicazione con risparmio di soldi e tempo
Rosario Culmone UNICAM 237
• Generazione automatica del codice• Alcuni CASE generano automaticamente controlli da
espressioni OCL• E’ possibile controllare la consistenza delle componenti del
sistema in modo automatico• Maggiori vincoli implicano minori errori di progettazione
OCL - Vantaggi
Rosario Culmone UNICAM 238
OCL - Bibliografia
• Object Constraint Language Specification, version 1.1, OMG documentad970808, 1997
• The Object Constraint Language Precise Modeling with UML, Jos Warmer, Anneke Kleppe, Addison-Wesley 2000
Rosario Culmone UNICAM 239
OCL - Siti Web
• http://www.klasse.nl/ocl/• http://www.ibm.com/software/ad/library/standards/ocl.html
Rosario Culmone UNICAM 241
Meccanismi di Estensione di UML
• UML con l’attuale notazione prevede elementi per la modellazione di classi, associazioni, collaborazioni, task, stati…
• Qualche estensione è già definita come ad esempio gli attori.• La modellazione di applicazioni in certi particolari domini richiede
elementi basati su concetti specializzati
Rosario Culmone UNICAM 242
Meccanismi di Estensione di UML
• UML di per sé offre strumenti molto generali e completi.• UML viene spesso scelto come base per modellare elementi specifici
perché è altamente estendibile.• Usando questi meccanismi il livello metamodel dell’UML può essere
facilmente esteso, perfezionato e adattato per uno specifico dominio o processo.
Rosario Culmone UNICAM 243
Meccanismi di Estensione di UML
• UML definisce tre meccanismi di estensione: Tagged Value, Constraint, e Stereotype.
Rosario Culmone UNICAM 244
Meccanismi di Estensione di UML
• Tagged Value:• Aggiunge informazioni ad un elemento già esistente.• Queste nuove informazioni sono secondarie rispetto alle regole
semantiche dell’elemento.
Rosario Culmone UNICAM 245
Meccanismi di Estensione di UML
• Constraint:• Aggiunge regole semantiche o condizioni che devono essere mantenute
vere per forzare e restringere il corretto uso dell’elemento.• Hanno una priorità maggiore rispetto ad i Tagged Value
Rosario Culmone UNICAM 246
Meccanismi di Estensione di UML
• Stereotype:• È il metodo più flessibile per estendere UML.• È un meccanismo che definisce un nuovo e più specializzato elemento basato su
uno già esistente.• Uno Stereotype può essere estensione di tutti i tipi di elementi inclusi classes,
packages, components e notes.• Può anche basarsi su relazioni come associations, generalizations, e dependencies.
Rosario Culmone UNICAM 247
Meccanismi di Estensione di UML
• Stereotype:• Uno Stereotype eredita tutte le proprietà base di un elemento generico
aggiungendo e perfezionando la semantica per il suo corretto utilizzo.
Rosario Culmone UNICAM 248
Meccanismi di Estensione di UML
<<form>>
+QueryString : string
<<form_element>>
<<password>>
<<select>>
<<button>>
<<text>>
<<option>>
1
1
0..*
+tf0..*
1
1
0..*
1
0..*1..* 1
Rosario Culmone UNICAM 249
Meccanismi di Estensione di UML
<<servlet>>in
{context inv:self.parameter->forAll(c , t:self.read.tf.type | c.parameter.name=t.name implies
t.oclAsType(c.parameter.type) <> Undefined ),
context inv:self.read->notEmpty
}
<<servlet>>out
{context inv:self.parameter->forAll(p1, p2 | p1.name = p2.name implies p1 = p2)
, context inv:
uguali( b: in) : booleanuguali(b)= (self.parameter->size = b.parameter->size) and
self.parameter->forAll (i : Integer |
b.parameter.type = self.parameter->at(i).type) and b.parameter.name = self.parameter->at(i).name))
, context inv:
action.value=self.make.send.name}
+action : string
<<form>>
+QueryString : string
<<servlet>>
#doGet()#doPost()
+make
+made
+read
+send
Rosario Culmone UNICAM 251
Design Pattern - Introduzione
• E’ una nuova tecnica per lo sviluppo di applicazioni riusabili orientate agli oggetti
• Viene impiegata per la realizzazione di componenti e per la definizione del loro corretto uso
• E’ comunemente integrato all’interno dei tool di supporto allo sviluppo
Rosario Culmone UNICAM 252
Design Pattern - Introduzione
• Perché?• In un contesto ottimale uno sviluppatore non dovrà mai
affrontare un nuovo problema dall’inizio• Si devono cercare soluzioni valide già applicate con successo• Soluzioni già testate aumentano la robustezza del software e
velocizzano le fasi di testing
Rosario Culmone UNICAM 253
Design Pattern - Indroduzione
• Un pattern è• l’astrazione di una soluzione riusabile in contesti eterogenei
Anche basando il proprio processo di produzione del software nella realizzazione di componenti integrabili bisogna trovare il giusto equilibrio:
Rosario Culmone UNICAM 255
Design Pattern - Introduzione
• I vantaggi• Notevole aumento della capacità di produrre software
riutilizzabile• Si danno allo sviluppatore strumenti utili per la modellazione
di nuovi sistemi• Si aumenta la documentazione e la chiarezza• Si aumenta la velocità di sviluppo• Si aumenta la robustezza del software• Si aumenta la flessibilità e l’eleganza del software
Rosario Culmone UNICAM 256
Design Pattern - Storia
• Il termine “pattern” fu introdotto dall’architetto austriaco Christopher Alexander negli anni ’70 (per la pianificazione di costruzioni in ambienti urbani)
• Nel 1987 Cunningham e Beck adattarono l’idea di Alexander per guidare programmatori inesperti in Smalltalk
Rosario Culmone UNICAM 257
Design Pattern - Storia
• Dal 1990 al 1992 la famosa Gang of Four (Gamma, Helm, Johnson e Vlissides) incominciarono la stesura di un catalogo di pattern
• Nel 1995 la Gang of Four pubblicarono Design Pattern, elements of reusable object-oriented software
Rosario Culmone UNICAM 258
Design Pattern – Cos’è un Pattern
• Un pattern è l’astrazione di un problema che si verifica nel nostro dominio, rappresentandone la soluzione in modo che sia possibile riutilizzarla per numerosi altri contesti (Christofer Alexander)
Rosario Culmone UNICAM 259
Design Pattern – Composizione
• Nome• Il nome del pattern è molto utile per descrivere il problema, la
sua soluzione ed il suo uso• Composto da una o due parole• Cercare di omogeneizzare i vocabolari personali di tutti i
colleghi
Rosario Culmone UNICAM 260
Design Pattern – Composizione
• Problema• Descrive quando applicare un pattern definendo il contesto ed
il dominio di appartenenza• In generale include la lista di condizioni che devono essere
valide per poter giustificare l’uso di un determinato pattern
Rosario Culmone UNICAM 261
Design Pattern – Composizione
• Soluzione• Descrive gli elementi che verranno usato durante la
modellazione• Descrive le relazioni e le responsabilità degli elementi• E’ importante capire che la soluzione non rappresenta una
specifica implementazione o caso d’uso ma un modello che si applica a differenti situazioni
Rosario Culmone UNICAM 262
Design Pattern – Composizione
• Conseguenze• Raccoglie l’elenco dei tempi e dei risultati• E’ importante quando si devono prendere decisioni di
modellazione• Descrive varie metriche, i costi ed i tempi in relazione ai
benefici che il pattern introdurrebbe
Rosario Culmone UNICAM 263
Design Pattern – La scelta
• Esistono numerosi cataloghi di pattern• Solitamente sono descritti attraverso una notazione comune
“Design Language”• E’ importante reperire il pattern adeguato per il proprio specifico
dominio
Rosario Culmone UNICAM 264
Design Pattern – La scelta
• Considerare come un pattern risolve il problema:• È utile considerare l’astrazione, le interfacce, gli oggetti che
vengono utilizzati per raggiungere la soluzione
Rosario Culmone UNICAM 265
Design Pattern – La scelta
• Considerare il suo intento:• Capire lo scopo di ogni pattern è fondamentale per rilevare
quelli adatti per lo specifico problema
Rosario Culmone UNICAM 266
Design Pattern – La scelta
• Studiare le interazioni tra pattern:• Conoscere le relazioni tra i pattern (grazie anche a notazioni
grafiche come l’UML) aiuta senz’altro a scegliere quello corretto
Rosario Culmone UNICAM 267
Design Pattern – La scelta
• Studiare le varie famiglie di pattern:• I pattern vengono solitamente divisi in famiglie• Per aumentare la velocità di ricerca è utile conoscere lo scopo
di ogni famiglia
Rosario Culmone UNICAM 268
Design Pattern – La scelta
• Considerare come deve variare il progetto:• Valutare quali elementi del problema hanno la possibilità di
cambiare durante lo sviluppo• E’ bene cercare di incapsulare questi elementi così da
aumentare la generale indipendenza, allontanando la necessità di un ridisegno della struttura
Rosario Culmone UNICAM 269
Design Pattern – Esempio
A=50%B=30%C=20%
A B C
60 30 10
50 30 20
80 10 10 A B C
A
B C
Modello
Viste
Rosario Culmone UNICAM 270
Design Pattern – Pattern Observer
• Intento• Definire una dipendenza uno-a-molti tra oggetti, in questo
modo quando un oggetto cambia stato tutti gli ascoltatori collegati sono notificati ed aggiornati
Rosario Culmone UNICAM 271
Design Pattern – Pattern Observer
• Applicabilità• Quando l’astrazione è composta da due aspetti, uno
dipendente dall’altro• Quando il cambiamento di un oggetto richiede il
cambiamento di altri• Quando non si conosce a priori il numero degli oggetti
dipendenti• Quando un oggetto deve notificare ad altri un cambiamento
senza conoscere la struttura degli oggetti dipendenti
Rosario Culmone UNICAM 272
Design Pattern – Pattern Observer
Subject
+attach( observer : Observer )+detach( observer : Observer )+notify()
ConcreteObserverConcreteSubject
Observer
+update()
-observers
0..*
Rosario Culmone UNICAM 273
Design Pattern – Pattern Observer
• Conseguenze• Maggiore modularità: Subject e observers possono cambiare• Maggiore elasticità: posso definire e aggiungere diversi
observers• Maggiore flessibilità: posso agganciare diversi observers
ognuno dei quali può implementare una differente vista
Rosario Culmone UNICAM 274
Design Pattern – Definizione
• La descrizione di un pattern viene effettuata grazie ad uno sche ma introdotto dalla Gang of Four
• Oltre ad una notazione grafica è utile allegare anche una documentazione
Rosario Culmone UNICAM 275
Design Pattern – Definizione
• Nome: la scelta del nome è vitale• Intento: una breve descrizione che risponde alle domande “cosa
fa il pattern?” “a quale problema è rivolto?”• Motivazione: uno scenario che illustra il problema e come le
classi e gli oggetto sono strutturati nel pattern
Rosario Culmone UNICAM 276
Design Pattern – Definizione
• Applicabilità: una descrizione dei domini dove può essere applicato il pattern
• Struttura: una notazione grafica (UML)• Partecipanti: l’elenco e le responsabilità delle classi
Rosario Culmone UNICAM 277
Design Pattern – Definizione
• Collaborazioni: una descrizione di come i partecipanti collaborino per svolgere le proprie responsabilità
• Conseguenze: i risultati che l’uso del pattern genera• Implementazione: una descrizione delle tecniche di
programmazione e le specifiche del linguaggio che devono essere usate per l’implementazione del pattern
Rosario Culmone UNICAM 278
Design Pattern – Definizione
• Esempio: un breve esempio (C++ o Java) che illustra la corretta implementazione del pattern
• Pattern collegati: l’elenco dei pattern che devono essere affiancati a quello descritto, le differenze ed i possibili legami
Rosario Culmone UNICAM 279
Design Pattern – Trovare e Scrivere Pattern
• I pattern non devono assolutamente essere soluzioni a problemi nuovi
• Un pattern non deve mostrare una soluzione ma deve raccontare l’esperienza catturata durante la sua individuazione
• Una singola soluzione ad un problema non costituisce un pattern• Inizialmente un pattern è una soluzione che si verifica in
situazioni multiple
Rosario Culmone UNICAM 280
Design Pattern – In sintesi
• Un pattern aumenta la comunicazione tra team• L’uso dei pattern aumenta l’astrazione e l’eleganza della
modellazione• “L’ingegneria del software senza la conoscenza dei pattern è
programmazione tradizionale”
Rosario Culmone UNICAM 285
Observer
• Il pattern observer risolve un comune problema: cosa fare se un gruppo di oggetti necessitano di essere aggiornati quando altri oggetti cambiano stato?
• Il cambiamento di un oggetto provoca dinamicamente il cambiamento di altri oggetti.
• Un oggetto dovrebbe poter notificare ad altri oggetti il cambiamento del proprio stato senza conoscere nulla sulla loro identità.
• Il meccanismo ad eventi di AWT e’ implementato addottando il pattern
Rosario Culmone UNICAM 286
Observerpublic interface Observer { public void update( Subject subject ) ; } public class Subject { protected Vector observers = new Vector() ; public void addObserver( Observer o ) { observers.addElement( o ) ; } public void removeObserver( Observer o ) { observers.removeElement( o ) ; } public void notify() { Enumeration e = observers.getElements() ; while ( e.hasMoreElements() ) { ((Observer)e.nextElement()).update( this ) ; } }}
Rosario Culmone UNICAM 290
Factory
• Il pattern Factory definisce una interfaccia per la creazione di un oggetto, ma lascia alle sottoclassi la decisione su che classe istanziare.
• Fornisce un’interfaccia per la creazione di oggetti senza specificare la loro classe.
• Il pattern Factory e’ applicabile in tutti quei casi in cui si vuole centralizzare la decisione di quale classe istanziare.
Rosario Culmone UNICAM 291
Factory public interface AbstractFactory { public AbstractProductA createProductA(); public AbstractProductB createProductB();}public class ConcreteFactory1 implements AbstractFactory { public AbstractProductA createProductA() { return (AbstractProductA ) new ProductA1(); } public AbstractProductB createProductB() { return (AbstractProductB ) new ProductB1(); }public class ConcreteFactory2 implements AbstractFactory { public AbstractProductA createProductA() { return (AbstractProductA ) new ProductA2(); } public AbstractProductB createProductB() { return (AbstractProductB ) new ProductB2(); }}
Rosario Culmone UNICAM 294
Progetto
• Il documento è composto da:• Titolo del progetto, componenti del gruppo• Descrizione (max una pagina)• Dizionario dei termini (max due pagine)• Elenco dei diagrammi (max 20). Almeno un diagramma per tipo
• Valutazione• Maggiore valutazione per uso estensivo di OCL• Maggiore valutazione per migliore descrizione di componenti complessi• Maggiore valutazione per descrizione chiara
Rosario Culmone UNICAM 295
Bibliografia
• Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King, Shlomo Angel, A Pattern Language. Oxford University Press, New York, 1977.
• Ward Cunningham, Kent Beck, Using Pattern Languages for Object-Oriented Programs, OOPSLA Orlando, 1987.
• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissedes, Design Patterns Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.