Unified Modeling Language

Slides:



Advertisements
Presentazioni simili
Il paradigma Object Oriented
Advertisements

Programmazione ad oggetti
Progettazione dei Sistemi Interattivi (A.A. 2004/05) - Lezione 2 1 Progettazione e Sviluppo di Software ad Oggetti 4 OBJECT-ORIENTED ANALYSIS Processo.
Introduzione ai Casi dUso (c) TECNET DATI (c) TECNET DATI Pag. 2 Dai requisiti ai casi duso obiettividefinire gli obiettivi –gli obiettivi del committente.
Analisi e progettazione
Unified Modeling Language
Recupero debito quarto anno Primo incontro
Informatica Recupero debito quarto anno Terzo incontro.
Sistemi informativi e Sistemi informatici
PHP.
L’Informatica dal Problema alla Soluzione
Metodologie di Programmazione = decomposizione basata su astrazioni
Principi di Programmazione Object-Oriented
Principi di Programmazione Object-Oriented
4 – Progettazione – Introduzione e Modello E-R
DIAGRAMMI DI FLUSSO DEI DATI
©Carlo Tasso 1999 Object Oriented Programming Slide 1 OO Analysis Vs. OO Design OOA – Object Oriented Analysis. –Specifica COSA, IN QUALE CONTESTO il sistema.
1 9: Progettazione Architetturale Obiettivo: stabilire la struttura globale di un sistema software Descriveremo diversi tipi di modello di architettura,
DIFFICOLTA’ DEL LINGUAGGIO
Sistemi basati su conoscenza Conoscenza e ragionamento Prof. M.T. PAZIENZA a.a
1 Programmazione ad oggetti in Java E.Mumolo, DEEI
Il linguaggio UML Luca Lista. Metodi Object Oriented –Booch Method by Grady Booch –OMT by Jim Rumbaugh –Objectory (Use Cases) by Ivar Jacobson –CRC by.
Struttura dei sistemi operativi (panoramica)
UnitĂ  Didattica 2 I Linguaggi di Programmazione
Modello E-R Generalizzazioni
Progettazione di una base di dati
Modello E-R Generalizzazioni
Daniel Stoilov Tesi di Laurea
A.Natali DL Maggio1999 Oggetti Concetti fondamentali.
Introduzione alla modellazione di sistemi interattivi
INTRODUZIONE l sistema operativo è il primo software che lutente utilizza quando accende il computer; 1)Viene caricato nella memoria RAM con loperazione.
1 Programmazione = decomposizione basata su astrazioni (con riferimento a Java)
L’ingegneria del software
Il modello ER Proposto da Peter Chen nel 1976 rappresenta uno standard per la progettazione concettuale (in particolare per le basi di dati) Ha una rappresentazione.
Introduzione alla programmazione Object Oriented
PROBLEMI E “PAROLACCE” Nucleo: Relazioni e Funzioni
Lo sviluppo del progetto informatico
Il linguaggio UML Luca Lista.
Analisi dei Requisiti (Requirements Engineering) Seminario RE UniversitĂ  degli Studi di Padova, 12 Gennaio 2004.
Programma di Informatica Classi Prime
Scelta di un modello di processo: esempio
Commenti alle AttivitĂ  Generiche. AttivitĂ  Generiche (Pressman) Principali: Comunicazioni; Pianificazione; Modellazione; Costruzione, Dispiegamento Collaterali:
Commenti all’esempio del treno Nell’esempio del treno si è iniziato dalle attività generiche che tipicamente servono per portare a termine i compiti iniziali.
Commenti all’esempio del treno Nell’esempio del treno si è iniziato dalle attività generiche e/o attività operative che tipicamente costituiscono i passi.
Esercitazioni di Ingegneria del Software con UML
Progettazione concettuale di SI basati su Web
I processi.
Diagramma delle Classi
Un Sistema per la Redazione Assistita di Testi Giuridici Tesi di Laurea Specialistica in Informatica di Emiliano Giovannetti Un Sistema per la Redazione.
Analisi dettagliata e design
Commenti all’esempio del treno Nell’esempio del treno si è iniziato dalle attività generiche e/o attività operative che tipicamente costituiscono i passi.
Analisi dei requisiti Il primo passo di “qualsiasi” processo di sviluppo è la definizione dei requisiti  Definizione del Business Model  Solitamente.
Fondamenti di Informatica 2 Ingegneria Informatica Docente: Giovanni Macchia a.a
TW Asp - Active Server Pages Nicola Gessa. TW Nicola Gessa Introduzione n Con l’acronimo ASP (Active Server Pages) si identifica NON un linguaggio di.
Progettazione di una base di dati Ciclo di vita di un sistema informativo Studio di fattibilitĂ  definisce le varie alternative possibili, i relativi costi.
Ingegneria del software Modulo 1 -Introduzione al processo software UnitĂ  didattica 4 -Progettazione del software Ernesto Damiani UniversitĂ  degli Studi.
Corso di Laurea in Informatica
UML: Introduzione Corso IS I /03 Gianna Reggio Versione 0.0.
1 Linguaggi: guardando la semantica §esistono un insieme di concetti semantici e di strutture di implementazione in termini dei quali si descrivono in.
1 Metodologie di Programmazione = decomposizione basata su astrazioni.
Progettazione di basi di dati: metodologie e modelli
Algoritmi e Programmazione (in C) Stefano Cagnoni e Monica Mordonini
Intelligenza Artificiale Metodologie di ragionamento Prof. M.T. PAZIENZA a.a
Cloud informatica V anno.
Le basi di dati.
Unified Modeling Language. –un linguaggio (e notazione) universale, per rappresentare qualunque tipo di sistema software –uno standard OMG (Object Management.
UML Unified Modelling Language Linguaggio per la modellazione unificato.
Dal problema al programma – ciclo di sviluppo del software La scrittura del programma è solo una delle fasi del processo di sviluppo di un'applicazione.
ALGORITMI, LINGUAGGI E PROGRAMMI FacoltĂ  di Lingue e Letterature Straniere Corso di laurea in Relazioni Pubbliche.
Introduzione alle Classi e agli Oggetti in Java 1.
Transcript della presentazione:

Unified Modeling Language Rosario Culmone

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

Programma del corso Ocl Introduzione Storia Constraint Invarianti Precondizioni Postconditioni Vantaggi Bibliografia Meccanismi di Estensione di UML Design Pattern Concetti Cataloghi Esempi Ingegneria del software Introduzione L’Ingegneria del Software Uml Storia Architettura I 9 diagrammi Sintesi UML Bibliografia Indice Provvisorio Rosario Culmone UNICAM

Prerequisiti Aver sostenuto esame di Programmazione e Laboratorio di Programmazione Buono conoscenza del paradigma ad oggetti Rosario Culmone UNICAM

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

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

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

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

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

Metodologia Descrizione Analisi Esempi di uso Confronto Rosario Culmone UNICAM

Ingegneria del Software

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

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

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

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

Introduzione Ingegneria del Software 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

Ingegneria del Software È una tecnologia stratificata per il rispetto della qualità Strumenti Metodi Processo Qualità Rosario Culmone UNICAM

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

Ingegneria del Software Metodi Comprendono una vasta gamma di attivitĂ  Analisi dei requisiti Progettazione Scrittura del Codice Collaudo Manutenzione Rosario Culmone UNICAM

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

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

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

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

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

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

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

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

UML - Storia Grady Booch Jim Rumbaugh Ivar Jacobson Rosario Culmone OOD 91 OOAD94 Rumbaugh OMT 91 Jacobson (Objectory /OOSE) 92 94 RATIONAL Ott. 95 Unified Method Notation (v 0.8) Ott. 95 RATIONAL Lug. 95 Unified Modeling Language (v 0.9) Microsoft, HP, Oracle e altri (consorzio) Gen. 97 UML 1.0 IBM, Platinum e altri (consorzio) Nov. 97 UML 1.1 Dic. 98 UML 1.2 Giu. 99 UML 1.3 Mag. 01 UML 1.4 Rosario Culmone UNICAM

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

UML - Architettura Si basa su una struttura composta da quattro livelli di metamodelli Rosario Culmone UNICAM

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 Rosario Culmone UNICAM

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 Rosario Culmone UNICAM

UML - Architettura Model: Qui si definiscono i domini, i problemi e le soluzioni di sistemi Rosario Culmone UNICAM

UML - Architettura User object: E’ composto da elementi che semplificano i modelli UML Qui si descrivono le specifiche informazioni del dominio Rosario Culmone UNICAM

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

UML - Notazione Vista Strutturale Vista di Implementazione Class diagrams Object diagrams Vista Utente Component diagrams Use case diagrams Vista Comportamentale Vista di Ambiente Sequence diagrams Collaboration diagrams Statechart diagrams Activity diagrams Deployment diagrams Rosario Culmone UNICAM

Vista di Implementazione Vista Comportamentale UML - Notazione Vista di Implementazione Vista Strutturale Class diagrams Object diagrams Vista Utente Component diagrams Use case diagrams Vista Comportamentale Vista di Ambiente Sequence diagrams Collaboration diagrams Statechart diagrams Activity diagrams Deployment diagrams Vista Utente: Descrizione del comportamento del sistema dal punto di vista degli utenti Rosario Culmone UNICAM

Vista di Implementazione Vista Comportamentale UML - Notazione Vista di Implementazione Vista Strutturale Class diagrams Object diagrams Vista Utente Component diagrams Use case diagrams Vista Comportamentale Vista di Ambiente Sequence diagrams Collaboration diagrams Statechart diagrams Activity diagrams Deployment diagrams Vista Strutturale: Requisiti funzionali e servizi che il sistema deve supportare Rosario Culmone UNICAM

Vista di Implementazione Vista Comportamentale UML - Notazione Vista di Implementazione Vista Strutturale Class diagrams Object diagrams Vista Utente Component diagrams Use case diagrams Vista Comportamentale Vista di Ambiente Sequence diagrams Collaboration diagrams Statechart diagrams Activity diagrams Deployment diagrams Vista di Implementazione: Configurazione dei componenti che costituiscono il sistema fisico Rosario Culmone UNICAM

Vista di Implementazione Vista Comportamentale UML - Notazione Vista di Implementazione Vista Strutturale Class diagrams Object diagrams Vista Utente Component diagrams Use case diagrams Vista Comportamentale Vista di Ambiente Sequence diagrams Collaboration diagrams Statechart diagrams Activity diagrams Deployment diagrams Vista Comportamentale: Descrizione del comportamento interno del sistema da un punto di vista strutturale Rosario Culmone UNICAM

Vista di Implementazione Vista Comportamentale UML - Notazione Vista di Implementazione Vista Strutturale Class diagrams Object diagrams Vista Utente Component diagrams Use case diagrams Vista Comportamentale Vista di Ambiente Sequence diagrams Collaboration diagrams Statechart diagrams Activity diagrams Deployment diagrams Vista di Ambiente: Topologia degli host del sistema, la loro interazione su rete e la distribuzione dei processi Rosario Culmone UNICAM

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

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 Rosario Culmone UNICAM

Elementi comuni a tutti i diagrammi Associazione con la Nota Una nota può essere agganciata ad ogni elemento o relazione del diagramma Rosario Culmone UNICAM

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

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

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

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

Use Case Diagrams - Elementi Esempi Casi d’Uso: Rosario Culmone UNICAM

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

Use Case Diagrams - Elementi Esempi Attori: Rosario Culmone UNICAM

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

Use Case Diagrams - Elementi Esempio Sistema: Rosario Culmone UNICAM

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

Use Case Diagrams - Associazioni Esempio associazione Attore - Caso d’Uso: Rosario Culmone UNICAM

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

Use Case Diagrams - Associazioni Esempio associazione Attore - Attore: Rosario Culmone UNICAM

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

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

Use Case Diagrams - Associazioni Esempio associazione di specializzazione Caso d’uso – Caso d’uso: Rosario Culmone UNICAM

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

Use Case Diagrams - Associazioni Esempio associazione <<include>> Caso d’uso – Caso d’uso: Rosario Culmone UNICAM

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

Use Case Diagrams - Associazioni Esempio associazione <<extend>> Caso d’uso – Caso d’uso: Rosario Culmone UNICAM

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

Use Case Diagrams - Sistemi Esempio Sottosistemi: Rosario Culmone UNICAM

Use Case Diagrams Esempio Rosario Culmone UNICAM

Use Case Diagrams Esempio Rosario Culmone UNICAM

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

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

Class Diagram - Elementi Esempio Classe: Rosario Culmone UNICAM

Class Diagram - Elementi Classe - Visibilità Ogni attributo e metodo può avere varie caratteristiche: Pubblico Protetto Privato Rosario Culmone UNICAM

Class Diagram - Elementi Esempio VisibilitĂ : Rosario Culmone UNICAM

Class Diagram - Elementi Classe Astratta E’ una classe che non ha una concreta implementazione ma ha solo la dichiarazione delle operazioni Rosario Culmone UNICAM

Class Diagram - Elementi Esempio Classe astratta: Rosario Culmone UNICAM

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

Class Diagram - Elementi Esempio Classe interfaccia: Rosario Culmone UNICAM

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

Class Diagram - Elementi Esempio Package: Rosario Culmone UNICAM

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

Class Diagram - Associazioni Esempio Associazione: Rosario Culmone UNICAM

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

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

Class Diagram - Associazioni Esempio Associazione con molteplicitĂ : Rosario Culmone UNICAM

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

Class Diagram - Associazioni Esempio Ruolo: Rosario Culmone UNICAM

Class Diagram - Associazioni Classi di associazioni Definiscono delle proprietĂ  che appartengono alla associazione e non alle classi coinvolte Rosario Culmone UNICAM

Class Diagram - Associazioni Esempio Classe di Associazione: Rosario Culmone UNICAM

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

Class Diagram - Associazioni Esempio Aggregazione: Rosario Culmone UNICAM

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

Class Diagram - Associazioni Esempio Composizione: Rosario Culmone UNICAM

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

Class Diagram - Associazioni Esempio Generalizzazione: Rosario Culmone UNICAM

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

Class Diagram - Associazioni Esempio Realizzazione: Rosario Culmone UNICAM

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

Class Diagram - Associazioni Esempio Dipendenza: Rosario Culmone UNICAM

Class Diagram Esempio: Rosario Culmone UNICAM

Class Diagram Esempio: Rosario Culmone UNICAM

Class Diagram Esempio: Rosario Culmone UNICAM

Class Diagram Esercizio: come rappresentare attraverso un class diagram la struttura dati lista Rosario Culmone UNICAM

Class Diagram Esercizio: come rappresentare attraverso un class diagram la struttura dati lista Rosario Culmone UNICAM

Class Diagram Esercizio: si vuole modellare un salotto che ha a disposizione un televisore oppure un impianto stereo, ma non tutti e due Rosario Culmone UNICAM

Class Diagram Esercizio: si vuole modellare un salotto che ha a disposizione un televisore oppure un impianto stereo, ma non tutti e due Rosario Culmone UNICAM

Class Diagram Esercizio: si vuole modellare un salotto che ha a disposizione un televisore oppure un impianto stereo, ma non tutti e due Rosario Culmone UNICAM

Class Diagram Esercizio: si vuole modellare un salotto che ha a disposizione un televisore oppure un impianto stereo, ma non tutti e due Rosario Culmone UNICAM

Class Diagram Esercizio: si vuole modellare un salotto che ha a disposizione un televisore oppure un impianto stereo, ma non tutti e due 1 Rosario Culmone UNICAM

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

Object Diagram - Elementi Rappresenta una singola entità In un ambiente object-oriented rappresenta una istanza Mostra lo stato dell’oggetto in un particolare istante Rosario Culmone UNICAM

Object Diagram - Elementi Esempio Object: Rosario Culmone UNICAM

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

Object Diagram - Relazioni Esempio Link: Rosario Culmone UNICAM

Object Diagram Esempio: Rosario Culmone UNICAM

Object Diagram Esercizio: rappresentare attraverso un’object diagram il seguente class diagram Rosario Culmone UNICAM

Object Diagram Esercizio: rappresentare attraverso un’object diagram il seguente class diagram Rosario Culmone UNICAM

Object Diagram Esercizio: rappresentare attraverso un’object diagram il seguente class diagram Rosario Culmone UNICAM

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

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

Sequence Diagram - Elementi Esempio Object: Rosario Culmone UNICAM

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

Sequence Diagram - Elementi Activation Rappresenta il tempo durante il quale un oggetto esegue un’operazione Rosario Culmone UNICAM

Sequence Diagram - Elementi Esempio Messaggi: Rosario Culmone UNICAM

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

Sequence Diagram - Elementi Esempio Messaggio di Ritorno: Rosario Culmone UNICAM

Sequence Diagram - Elementi Messaggio Ricorsivo Indica un messaggio inviato a se stesso E’ utile quando si voglio rappresentare comportamenti ricorsivi Rosario Culmone UNICAM

Sequence Diagram - Elementi Esempio Messaggio Ricorsivo: Rosario Culmone UNICAM

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

Sequence Diagram - Elementi Esempio Destroy: Rosario Culmone UNICAM

Sequence Diagram - Elementi Esecuzione Concorrente: Indica quando alcune condizioni possono generare cammini diversi Rosario Culmone UNICAM

Sequence Diagram - Elementi Esempio Esecuzione concorrente: Rosario Culmone UNICAM

Sequence Diagram - Esempi Esempio: Rosario Culmone UNICAM

Sequence Diagram - Esempi Esempio: Rosario Culmone UNICAM

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

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

Collaboration Diagram - Elementi Esempio Object: Rosario Culmone UNICAM

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

Collaboration Diagram - Relazioni Esempio Link: Rosario Culmone UNICAM

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

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

Collaboration Diagram - Esempi Esempio Messaggi: Rosario Culmone UNICAM

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

Collaboration Diagram - Elementi Esercizio: Rosario Culmone UNICAM

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

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

Statechart Diagram - Elementi Stato Iniziale Stato Finale: Rappresentano i punti iniziali e finali di uno statechart Rosario Culmone UNICAM

Statechart Diagram - Elementi Esempio Inizio Fine: Rosario Culmone UNICAM

Statechart Diagram - Elementi Stato: Rappresenta la situazione nel tempi di un oggetto che esegue una attivitĂ  o aspetta qualche stimolo esterno Rosario Culmone UNICAM

Statechart Diagram - Elementi Esempio Stato: Rosario Culmone UNICAM

Statechart Diagram - Elementi Transizione: Rappresenta la relazione tra due differenti stati di un oggetto Ogni transizione potrĂ  avere una etichetta Rosario Culmone UNICAM

Statechart Diagram - Elementi Esempio Transizione: Rosario Culmone UNICAM

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

Statechart Diagram - Elementi Esempio Transizione: Rosario Culmone UNICAM

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

Statechart Diagram - Elementi Esempio Stato con Azioni: Rosario Culmone UNICAM

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

Statechart Diagram - Elementi Esempio Macro Stato: Rosario Culmone UNICAM

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

Statechart Diagram - Elementi Esempio Stato Concorrente: Rosario Culmone UNICAM

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

Statechart Diagram - Elementi Esempio Stato con History: Rosario Culmone UNICAM

Statechart Diagram - Esempi Esempio: Rosario Culmone UNICAM

Statechart Diagram - Esempi Esempio: Rosario Culmone UNICAM

Statechart Diagram - Esempi Esempio: Rosario Culmone UNICAM

Statechart Diagram - Esempi Esempio: Rosario Culmone UNICAM

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

Activity Diagram - Elementi Stato Iniziale Stato Finale: Come nel Statechart Diagram rappresentano i punti iniziali e finali di uno statechart Rosario Culmone UNICAM

Activity Diagram - Elementi Esempio Inizio Fine: Rosario Culmone UNICAM

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

Activity Diagram - Elementi Esempio AttivitĂ : Rosario Culmone UNICAM

Activity Diagram - Elementi Action flow: Rappresenta le relazioni tra differenti action state Puo’ avere una label contenente condizioni booleane o descrizioni Rosario Culmone UNICAM

Activity Diagram - Elementi Esempio Action Flow: Rosario Culmone UNICAM

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

Activity Diagram - Elementi Esempio Branch: Rosario Culmone UNICAM

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

Activity Diagram - Elementi Esempio Fork e Join: Rosario Culmone UNICAM

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

Activity Diagram - Elementi Esempio Swimlanes: Rosario Culmone UNICAM

Activity Diagram - Esempi Esempio: Rosario Culmone UNICAM

Activity Diagram - Esempi Esempio: Rosario Culmone UNICAM

Activity Diagram - Esempi Esempio: Rosario Culmone UNICAM

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

Component Diagram - Elementi Componente: Rappresenta un singolo modulo del sistema Spesso un componente rappresenta un package del class diagram Rosario Culmone UNICAM

Component Diagram - Elementi Esempio Componente: Rosario Culmone UNICAM

Component Diagram - Elementi Interfaccia: Rappresenta l’interfaccia di un componente Un componente può avere più interfacce Rosario Culmone UNICAM

Component Diagram - Elementi Esempio Interfacce: Rosario Culmone UNICAM

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 Rosario Culmone UNICAM

Component Diagram - Relazioni Esempio Dipendenze: Rosario Culmone UNICAM

Component Diagram - Esempi Esempio: Rosario Culmone UNICAM

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

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 Rosario Culmone UNICAM

Deployment Diagram - Elementi Esempio Nodo: Rosario Culmone UNICAM

Deployment Diagram - Elementi Istanza di Nodo: Rappresenta un particolare oggetto del sistema In un contesto object-oriented rappresenta l’istanza di una classe Rosario Culmone UNICAM

Deployment Diagram - Elementi Esempio Istanza di Nodo: Rosario Culmone UNICAM

Deployment Diagram - Relazioni Connection: Rappresenta il percorso di comunicazione tra piÚ nodi Può rappresentare il protocollo di comunicazione utilizzato Rosario Culmone UNICAM

Deployment Diagram - Relazioni Esempio Connection: Rosario Culmone UNICAM

Deployment Diagram - Esempi Esempio: Rosario Culmone UNICAM

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

Component e Deployment Diagram Esempio: Rosario Culmone UNICAM

Component e Deployment Diagram Esempio: Rosario Culmone UNICAM

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

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

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

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

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

UML - I tool piĂš famosi Embarcadero Rhapsody Together J Rational Rose MagicDraw UML Suite ArgoUML MetaEdit+ Rosario Culmone UNICAM

UML - Siti Web http://www.cetus-links.org http://www.rational.com http://www.omg.org Rosario Culmone UNICAM

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

OCL Object Constraint Language

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

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

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

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

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

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

OCL – Constraint Esempio: context TypeName inv: expression Context: introduce il contesto dell’espressione TypeName: il nome della classe o l’associazione Inv: il tipo di constraint (invariante preconditione o postconditione) Rosario Culmone UNICAM

OCL – Constraint Expression: 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

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

OCL – Invariante Esempio: Rosario Culmone UNICAM

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

OCL – Invariante Esempio: Rosario Culmone UNICAM

OCL – Invariante Esempio invarianti nelle associazioni: Rosario Culmone UNICAM

OCL – Invariante Esempio invariante nella molteplicità dell’associazione: Rosario Culmone UNICAM

OCL – Invariante Esempio invariante nella molteplicità dell’associazione: Rosario Culmone UNICAM

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

OCL – Pre Postcondition Esempio: Rosario Culmone UNICAM

OCL – Pre Postcondition Esempio: Rosario Culmone UNICAM

OCL – Pre Postcondition Esempio uso di pre e postcondition: Rosario Culmone UNICAM

OCL – Pre Postcondition Esempio uso di result: Rosario Culmone UNICAM

OCL – Pre Postcondition Esempio uso di @pre: Rosario Culmone UNICAM

OCL - Vantaggi Migliore Documentazione i constraints aggiungono al modello grafico maggiori informazioni I constraints possono essere fusi graficamente nella stessa descrizione Rosario Culmone UNICAM

OCL - Vantaggi Migliore Precisione I constraints non possono essere interpretati differentemente da diverse persone Sono non ambigui e consistenti Rosario Culmone UNICAM

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

OCL - Vantaggi 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 Rosario Culmone UNICAM

OCL - Bibliografia Object Constraint Language Specification, version 1.1, OMG document ad970808, 1997 The Object Constraint Language Precise Modeling with UML, Jos Warmer, Anneke Kleppe, Addison-Wesley 2000 Rosario Culmone UNICAM

OCL - Siti Web http://www.klasse.nl/ocl/ http://www.ibm.com/software/ad/library/standards/ocl.html Rosario Culmone UNICAM

Meccanismi di Estensione di UML

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

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

Meccanismi di Estensione di UML UML definisce tre meccanismi di estensione: Tagged Value, Constraint, e Stereotype. Rosario Culmone UNICAM

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

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

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

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

Meccanismi di Estensione di UML Rosario Culmone UNICAM

Meccanismi di Estensione di UML Rosario Culmone UNICAM

Design Pattern

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

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

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

Design Pattern - Introduzione Rosario Culmone UNICAM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Design Pattern – Esempio Viste A B C A B C 60 30 10 50 30 20 80 10 10 A B C A=50% B=30% C=20% Modello Rosario Culmone UNICAM

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

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

Design Pattern – Pattern Observer Rosario Culmone UNICAM

Design Pattern – Pattern Observer Conseguenze Maggiore modularità: Subject e opbservers 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

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

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

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

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

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

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

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

Singleton Rosario Culmone UNICAM

State Rosario Culmone UNICAM

Iterarator Rosario Culmone UNICAM

Observer Rosario Culmone UNICAM

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

Observer public void update( Subject subject ) ; public 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

Adapter Rosario Culmone UNICAM

Composite Rosario Culmone UNICAM

Factory Rosario Culmone UNICAM

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

Factory public AbstractProductA createProductA(); 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 {                    return (AbstractProductA ) new ProductA2();                    return (AbstractProductB ) new ProductB2(); }  Rosario Culmone UNICAM

Flyweight Rosario Culmone UNICAM

Decorator Rosario Culmone UNICAM

Progetto Il documento è composto da: Valutazione 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

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. Rosario Culmone UNICAM