uml 1.pdf

Ingegneria del Software Modelli di sistema Vita Santa Barletta Danilo Caivano Antonio Piccinno  Software Engineering Research LABoratory Modelli di sistema PERCHÉ MODELLARE? Non è pos...

Ingegneria del Software Modelli di sistema Vita Santa Barletta Danilo Caivano Antonio Piccinno  Software Engineering Research LABoratory Modelli di sistema PERCHÉ MODELLARE? Non è possibile comprendere nessun sistema nella sua totalità 2 2 Ingegneria del Software | Modelli di sistema  Software Engineering Research LABoratory Modelli di sistema La modellazione dei sistemi è il processo che sviluppa modelli astratti di un sistema, dove ogni modello rappresenta una differente vista o prospettiva del sistema I modelli sono utilizzati durante ❑ Il processo di ingegneria dei requisiti per facilitare la deduzione dettagliata dei requisiti per un sistema ❑ Il processo progettazione per descrivere il sistema agli ingegneri che lo devono implementare ❑ Dopo l’implementazione per documentare la struttura e il funzionamento del sistema 3 3 Ingegneria del Software | Modelli di sistema  Software Engineering Research LABoratory Modelli di sistema È possibile sviluppare modelli sia di sistemi esistenti sia di nuovi sistemi ❑ I modelli di un sistema esistente si usano durante l’ingegneria dei requisiti ▪ Servono a chiarire cosa fa il sistema e possono essere utilizzati per focalizzare la discussione degli stakeholder sui punti di forza e di debolezze del sistema ❑ I modelli di un nuovo sistema si usano durante l’ingegneria dei requisiti per descrivere con maggior chiarezza i requisiti proposti ad altri stakeholder del sistema ▪ I modelli vengono utilizzati per discutere le proposte di progettazione e per documentare l’implementazione del sistema 4 4 Ingegneria del Software | Modelli di sistema  Software Engineering Research LABoratory Modelli di sistema Il modello di sistema non è una rappresentazione completa del sistema. Tralascia deliberatamente i dettagli per rendere più comprensibile il sistema Un modello è un’astrazione del sistema che si sta studiando, non un'alternativa del sistema È possibile sviluppare vari modelli per rappresentare il sistema da differenti prospettive ❑ Una prospettiva esterna: viene modellato il contesto o l’ambiente in cui opera il sistema ❑ Una prospettiva di interazioni: vengono modellate le interazioni tra il sistema e il suo ambiente, o tra i componenti del sistema ❑ Una prospettiva strutturale: viene modellata l’organizzazione del sistema o la struttura dei dati elaborati dal sistema ❑ Una prospettiva comportamentale: viene modellato il comportamento dinamico del sistema e le sue risposte agli eventi 5 5 Ingegneria del Software | Modelli di sistema  Software Engineering Research LABoratory UML Unified Modeling Language Grady Booch, Ivar Jacobson, Jim Rumbaugh 6 6 Ingegneria del Software | Modelli di sistema  Software Engineering Research LABoratory Unified Modeling Language UML è un linguaggio grafico per ❑ specificare, ❑ visualizzare, ❑ costruire e ❑ documentare gli artefatti di sistemi software 7 7 Ingegneria del Software | Modelli di sistema  Software Engineering Research LABoratory Unified Modeling Language Agevola la comunicazione tra i diversi stakeholder che partecipano allo sviluppo di un progetto software 8 8 Ingegneria del Software | Modelli di sistema  Software Engineering Research LABoratory Unified Modeling Language La modellazione visuale per mezzo di diagrammi standard permette ad ogni membro del processo di sviluppo di comprendere lo stato di sviluppo del sistema, in maniera chiara ed univoca, riducendo il rischio di interpretazioni non corrette 9 9 Ingegneria del Software | Modelli di sistema  Software Engineering Research LABoratory Unified Modeling Language Fornire la specifica di un modello indipendentemente da particolari linguaggi di programmazione e processi di sviluppo ❑ Definirlo in modo preciso, completo e privo di ambiguità 10 10 Ingegneria del Software | Modelli di sistema  Software Engineering Research LABoratory Unified Modeling Language Supportare i concetti di sviluppo di più alto livello come ❑ Componenti ❑ Comunicazioni ❑ Framework ❑ Pattern 11 11 Ingegneria del Software | Modelli di sistema  Software Engineering Research LABoratory UML: Caratteristiche Non è un linguaggio proprietario ❑ Dal 1997 l’evoluzione è a carico dell’OMG (Object Management Group) ed è soggetta a procedure ben definite per ogni cambiamento ❑ Alla stesura delle specifiche contribuiscono molti metodologi e alcune delle più importanti società mondiali di software ❑ Formalmente definito come standard ▪ ISO/IEC 19505-1:2012 (UML 2.4.1 Infrastructure) ▪ ISO/IEC 19505-2:2012 (UML 2.4.1 Superstructure) 12 12 Ingegneria del Software | Modelli di sistema  Software Engineering Research LABoratory L’UML e gli Oggetti Un modello UML ha due aspetti ❑ Struttura statica: i tipi di oggetto necessari per modellare il sistema e come sono tra loro correlati ❑ Comportamento dinamico: il ciclo di vita di questi oggetti e come collaborano per fornire le funzionalità richieste al sistema Questi due aspetti del modello UML sono complementari Oggetto: rappresentazione di un oggetto fisico o concetto logico esistente nel mondo reale Esempio: sportello Bancomat ❑ Carta Bancomat ❑ Conto corrente ❑ Carta moneta ❑ Scontrino 13 13 Ingegneria del Software | Modelli di sistema  Software Engineering Research LABoratory Tre modi per applicare UML UML come SKETCH: diagrammi informali e incompleti che vengono creati per esplorare parti difficili dello spazio del problema o della soluzione, sfruttando l’espressività dei linguaggi visuali UML come progetto: diagrammi di progetto relativamente dettagliati utilizzati per ❑ Il reverse engineering per visualizzare e comprendere meglio del codice esistente mediante dei diagrammi UML ❑ La generazione del codice (forward engineering) UML come linguaggio di programmazione: il codice viene generato automaticamente. ❑ Si tratta di un approccio ancora in corso di sviluppo, in termini di teoria e di robustezza e usabilità degli strumenti 14 14 Ingegneria del Software | Modelli di sistema  Software Engineering Research LABoratory Struttura dell’UML UML Costituenti Meccanismi Architettura fondamentali comuni 15 15 Ingegneria del Software | Modelli di sistema  Software Engineering Research LABoratory Struttura dell’UML UML Costituenti Meccanismi Architettura fondamentali comuni Entità Specifiche La struttura Relazioni Ornamenti organizzativa di un Diagrammi Distinzioni comuni sistema Meccanismi di estendibilità 16 16 Ingegneria del Software | Modelli di sistema  UML Software Engineering Research LABoratory Entità Costituenti fondamentali Elementi di modellazione e possono essere suddivise in quattro categorie: ❑ Entità strutturali: modellano la struttura statica del sistema ▪ Classe, Interfaccia, Caso d’uso, Componente, Nodo, etc. ❑ Entità comportamentali: modellano la struttura dinamica del sistema ▪ Interazioni, attività, macchine a stati ❑ Entità di raggruppamento: ▪ Il package, che viene utilizzato per raggruppare elementi semanticamente correlati ❑ Entità informative: l’annotazione che può essere aggiunta al modello per fornire informazioni particolari, in modo simile a un post-it 17 17 Ingegneria del Software | Modelli di sistema  UML Software Engineering Research LABoratory Relazioni Costituenti fondamentali In un modello le relazioni ❑ Mostrano come due o più entità sono correlate tra loro ❑ Consentono di fissare i legami significativi (semantici) tra gli elementi Tipo di relazione Sintassi UML Descrizione Dipendenza L’elemento sorgente dipende dall’elemento di destinazione e può essere influenzato dai cambiamenti eseguiti su di esso Associazione La descrizione di un insieme di collegamenti tra oggetti Aggregazione L’elemento di destinazione è parte integrante dell’elemento sorgente Composizione Una forma forte (più vincolata) di aggregazione Contenimento L’elemento sorgente contiene l’elemento destinazione Generalizzazione L’elemento sorgente è una specializzazione dell’elemento di destinazione più generale e può quindi sostituirlo Realizzazione L’elemento sorgente garantisce di eseguire il contratto specificato dall’elemento di destinazione 18 18 Ingegneria del Software | Modelli di sistema  UML Software Engineering Research LABoratory Diagrammi Costituenti fondamentali I diagrammi sono viste o finestre che consentono di vedere il contenuto del modello Il diagramma NON è il modello! 19 19 Ingegneria del Software | Modelli di sistema  UML Software Engineering Research LABoratory Diagrammi Costituenti fondamentali Diagramma Scopo Attività Processi e attività che costituiscono i processi Classi Classi, loro caratteristiche e relazioni Comunicazione Interazione tra oggetti con enfasi sui collegamenti Componenti Struttura dei componenti e loro connessioni Struttura Composita Scomposizione di una classe a runtime Deployment Distribuzioni di elaborati in diversi nodi Interazione Generale Fusione di un diagramma di sequenza con un diagramma delle attività Oggetti Configurazione esemplificativa di istanze Package Struttura del sistema al momento della compilazione Sequenza Interazione tra oggetti, con enfasi sulla sequenza Macchina a stati Come gli eventi cambiano un oggetto durante il suo ciclo di vita Temporizzazione Interazione tra oggetti, con enfasi sul tempo Casi d’uso Come gli utenti interagiscono con un sistema 20 20 Ingegneria del Software | Modelli di sistema  UML Software Engineering Research LABoratory Esempio utilizzo Diagrammi Costituenti fondamentali Analisi dei requisiti Progetto Casi d’uso descrivono le interazioni tra Diagramma delle classi, da una gli attori e il sistema prospettiva software mostrano le classi e Diagramma delle classi, da un punto le loro relazioni di vista concettuale può essere di Diagrammi di sequenza possono grande aiuto nella definizione di un documentare gli scenari più comuni vocabolario rigoroso da usare nella Diagrammi dei package mostrano descrizione del dominio l’organizzazione del software su larga Diagramma delle attività mostra il scala flusso di lavoro nell’organizzazione, Diagrammi di stato per le classi che indicando i punti di interazione tra il hanno un ciclo di vita complesso software e gli esseri umani. Inoltre può Diagrammi di deployment per servire da contesto per i casi d’uso e visualizzare la distribuzione fisica del chiarire il funzionamento di quelli più sistema complessi Diagramma di stato è utile se un’entità ha un ciclo di vita interessante e può assumere più stati diversi, che cambiano al verificarsi di determinati eventi 21 21 Ingegneria del Software | Modelli di sistema  22 Esempio utilizzo Diagrammi per produrre i modelli di cui un processo è composto Ingegneria del Software | Modelli di sistema 22 Software Engineering Research LABoratory  UML Meccanismi comuni: Software Engineering Research LABoratory Meccanismi Specifiche comuni I modelli UML possiedono almeno due dimensioni ❑ Una grafica, che consente di visualizzare il modello utilizzando diagrammi e icone ❑ Una testuale, costituita dalle specifiche dei vari elementi di modellazione Le specifiche sono la descrizione testuale della semantica di un elemento L’insieme delle specifiche costituisce il vero “contenuto” del modello, quel substrato semantico che tiene insieme il modello e lo riempie di significato 23 23 Ingegneria del Software | Modelli di sistema  UML Software Engineering Research LABoratory Specifiche Meccanismi comuni ContoBancario La classe ContoBancario non dà alcuna informazione sul significato funzionale con la sola rappresentazione grafica 24 24 Ingegneria del Software | Modelli di sistema  UML Software Engineering Research LABoratory Specifiche Meccanismi comuni ContoBancario Substrato Semantico numero proprietario specifiche della classe saldo prelievo() calcolaInteressi() deposito() specifiche del caso d’uso Deposito specifiche della dipendenza --------------🡪 25 25 Ingegneria del Software | Modelli di sistema  UML Software Engineering Research LABoratory Ornamenti Meccanismi comuni Ogni elemento di modellazione viene rappresentato da un simbolo a cui è possibile aggiungere degli ornamenti che rendono visibili gli aspetti particolari della specifica dell’elemento Finestra {autore=gianni, stato=testato} +dimensioni: rettangolo = (100, 100) #visibile: Booleano=falso Finestra +dimensioniPredefinite: Rettangolo #dimensioniMassime: Rettangolo -xptr: Xwindow Elemento senza ornamenti (e senza specifiche) +crea() +nascondi() +visualizza(posizione: Punto) -agganciaXWindow(xwin: Xwindow) Elemento con ornamenti 26 26 Ingegneria del Software | Modelli di sistema  UML Software Engineering Research LABoratory Distinzioni comuni Meccanismi comuni Le distinzioni comuni descrivono i diversi modi di ragionare sul mondo che ci circonda. L’UML prevede due distinzioni comuni ❑ Classificatore e istanza. Il classificatore è la nozione astratta di un tipo di elemento (per esempio, un conto bancario) mentre l’istanza è uno specifico elemento concreto di tale tipo (il “mio conto bancario”) ❑ Interfaccia e implementazione. Questa distinzione serve per separare cosa fa un oggetto (la sua interfaccia) da come lo fa (la sua implementazione) ▪ L’interfaccia definisce l’insieme di servizi che l’elemento è in grado di fornire, mentre l’implementazione realizza i servizi 27 27 Ingegneria del Software | Modelli di sistema  UML Software Engineering Research LABoratory Distinzioni comuni Meccanismi comuni Classificatore Descrizione Attore Un ruolo o un insieme di ruoli che qualcuno o qualcosa, esterno al sistema, svolge nell’interagire con il sistema Classe Una descrizione di un insieme di oggetti che condividono le stesse caratteristiche Componente Una parte modulare e sostituibile di un sistema che incapsula i suoi contenuti Interfaccia Un insieme di operazioni che vengono usate per definire il servizio offerto da una classe o da un componente Nodo Un elemento fisico presente a run-time che rappresenta una risorsa computazionale, per esempio, un PC Caso d’uso Una descrizione di una sequenza di azioni che un sistema effettua per fornire ad un utente un valore aggiunto 28 28 Ingegneria del Software | Modelli di sistema  UML Software Engineering Research LABoratory Distinzioni comuni Meccanismi comuni Conto numero: int proprietario: String saldo: double deposito() 🡪 -🡪 Prelievo() -- -- - - - - - -- -- - - -- -- - -- - -- - - contoVita:Conto contoSanta:Conto numero:int=801 numero:int=802 proprietario:String=“Vita Barletta” proprietario:String=“Santa Barletta” saldo:double=300.00 saldo:double=1000.00 29 29 Ingegneria del Software | Modelli di sistema  UML Software Engineering Research LABoratory Meccanismi di estendibilità Meccanismi comuni L’UML incorpora tre meccanismi di estendibilità ❑ Vincoli: definisce una condizione o una regola che riguarda l’elemento di modellazione e che deve risultare sempre vera ❑ Stereotipi: definiscono un nuovo elemento di modellazione UML basandosi su uno esistente ❑ Valori etichettati: permettono di estendere la definizione di un elemento 30 30 Ingegneria del Software | Modelli di sistema  UML Software Engineering Research LABoratory Meccanismi di estendibilità Meccanismi comuni Biglietto Biglietto icona stereotipo Biglietto Biglietto Schedulatore GestoreProcessi -------------------------🡪 31 31 Ingegneria del Software | Modelli di sistema  UML Software Engineering Research LABoratory Architettura Architettura La struttura organizzativa di un sistema, inclusa la sua scomposizione in parti, la loro connettività, l’interazione, i meccanismi e i principi guida che insieme formano il progetto del sistema stesso The UML Reference Manual Esistono molti modi di descrivere un’architettura. Una tecnica molto comune è il modello descritto da Philippe Kruchten, “4+1 Viste” 32 32 Ingegneria del Software | Modelli di sistema  UML Software Engineering Research LABoratory Architettura Architettura Vista logica: come gli oggetti e le classi che compongono il sistema implementano il comportamento richiesto al sistema Vista dei processi: modella i thread e i processi del sistema. Cattura aspetti di design come concorrenza e sincronizzazione Vista di implementazione: illustra il sistema dal punto di vista del programmatore. Descrive le componenti del sistema (ad es., librerie, framework, web services, sottosistemi) e come queste sono connesse tra di loro Vista di deployment: descrive come le componenti del sistema software sono mappate sulla struttura hardware Vista dei casi d’uso: tutte le altre viste derivano dalla vista dei casi d’uso. Questa vista fissa i requisiti funzionali del sistema attraverso un insieme di casi d’uso 33 33 Ingegneria del Software | Modelli di sistema  UML Software Engineering Research LABoratory Architettura Architettura Vista Logica Vista Class Diagrams Object Diagrams dell’Implementazione... Component Diagrams Vista dei Casi d’uso Use Case Diagrams Vista dei Processi Vista di Sequence Diagrams Deployment Collaboration Diagrams Deployment Diagrams Activity Diagrams... 34 34 Ingegneria del Software | Modelli di sistema  Software Engineering Research LABoratory Riferimenti Ian Sommerville “Ingegneria del Software”, 10a ed. Pearson, 2017 ○ Capitolo 5: Modelli di sistema Introduzione Ulteriori testi consigliati Martin Fowler, “UML DISTILLED, 4a edizione” Pearson addison Wesley, 2010 ❑ Capitolo 1: Introduzione 35 35 Ingegneria del Software | Modelli di sistema