Introduzione ad UML. Perché modelliamo

Transcript

1 Introduzione ad UML Pag. 1 Perché modelliamo Un modello è una semplificazione della realtà I modelli ci aiutano a visualizzare un sistema come è o come vorremmo che fosse ci permettono di specificare la struttura o il comportamento di un sistema ci forniscono un template che ci guida nella costruzione di un sistema documentano le decisioni che abbiamo preso Pag. 2

2 Perché modelliamo Divide et impera: tramite i modelli ci focalizziamo su un solo aspetto alla volta ogni modello può essere espresso a differenti livelli di precisione per un sistema non banale: non un solo modello ma un piccolo insieme di modelli, che possono essere costruiti e studiati separatamente, ma che sono strettamente interrelati Pag. 3 Approcci metodologici Un po di storia. anni 70 Approccio Strutturato anni 80 Information Engineering anni 90 Approccio Object Oriented Non si tratta di vere e proprie metodologie, ma: sono impostazioni globali, che coprono più fasi del ciclo di sviluppo / manutenzione hanno avuto (ed hanno) notevole diffusione hanno ispirato (ed ispirano) le metodologie più diffuse Pag. 4

3 Approccio Strutturato Caratteristiche: (Yourdon - De Marco) primo tentativo di fornire regole per le attività di sviluppo SW il concetto di base è la modularizzazione utilizzo di modelli formali e diagrammatici utilizzo di tecniche specifiche per le diverse fasi di sviluppo l attenzione è rivolta soprattutto alla componente funzionale Pag. 5 Approccio Strutturato Limiti origine anni 70: è fondato sul paradigma funzionale (process driven) caratteristico di sistemi mainframe batch tecniche e modelli diversi per dati e processi, per analisi e disegno difficoltà nel passaggio dall analisi al disegno Che cosa resta attuale dell approccio strutturato? la distinzione ferrea tra analisi (cosa) e disegno (come) l attenzione alle interazioni tra sistema e ambiente esterno alcune tecniche di analisi (DFD, STD), sia pur calate in un diverso contesto metodologico i principi guida del disegno strutturato (coesione, coupling) Pag. 6

4 Information Engineering Inizio anni 80 (Clive Finkelstein, James Martin) Caratteristiche: utilizzo estensivo di modelli formali e diagrammatici automazione della produzione del software (CASE, generatori di codice) attenzione rivolta principalmente ai dati Pag. 7 Limiti Information Engineering origine anni 80: approccio data driven, ma ancora legato alla separazione dati - processi tecniche di analisi e disegno derivate dall approccio strutturato l ambiente target previsto è ancora monopiattaforma Che cosa resta attuale dell Information Engineering? la suddivisione in macrofasi l attenzione all automazione del processo di sviluppo e manutenzione (CASE ) l insistenza sulla partecipazione dell utente a tutte le fasi del ciclo di sviluppo / manutenzione Pag. 8

5 Approccio Object Oriented Inizio anni 70 fine anni 80 Programmazione OO Analisi e Disegno OO Caratteristiche: superamento della distinzione tra dati e funzioni concetti nuovi : ereditarietà, information hiding, forte tendenza al riutilizzo di componenti software già definite Pag. 9 Metodi di analisi e disegno OO Esplosione dei metodi: dal 1989 al 1994 sono passati da 5 a oltre 50, ma con differenze spesso solo superficiali - notazioni, terminologia e poco più La confusione esistente a livello metodologico si ripercuote a livello di strumenti CASE per la progettazione object oriented Convergenza dei metodi: Unified Modeling Language Pag. 10

6 Unified Modeling Language un linguaggio (e notazione) universale, per la creazione di modelli software nel novembre 97 è diventato uno standard approvato dall OMG (Object Management Group) numerosi i co-proponenti: Microsoft, IBM, Oracle, HP, Platinum, Sterling, Unysis.. Pag. 11 Unified Modeling Language è l unificazione dei metodi: Booch-93 di Grady Booch OMT di Jim Rumbaugh OOSE di Ivar Jacobson ha accolto inoltre le idee di numerosi altri metodologi è tuttavia indipendente dai metodi, dalle tecnologie, dai produttori Pag. 12

7 Storia di UML Nov 97 UML è approvato dall OMG Set 97 Gen 97 UML 1.0 UML 1.1 IBM, Platinum e altri Giu 96 Ott 95 UML 0.9 Unified Method 0.8 Rumbaugh Booch Jacobson Microsoft, Oracle, HP e altri Pag. 13 UML - linguaggio universale linguaggio per specificare, costruire, visualizzare e documentare gli artefatti di un sistema universale: può rappresentare sistemi molto diversi, da quelli web ai legacy, dalle tradizionali applicazioni Cobol a quelle object oriented e a componenti Pag. 14

8 UML non è un metodo è un linguaggio di modellazione, non un metodo, né una metodologia definisce una notazione standard, basata su un meta-modello integrato degli elementi che compongono un sistema software non prescrive una sequenza di processo, cioè non dice prima bisogna fare questa attività, poi quest altra Pag. 15 UML e Processo Software un unico processo universale buono per tutti gli stili dello sviluppo non sembra possibile e tanto meno desiderabile in realtà UML assume un processo: basato sui Casi d Usod (use case driven) incentrato sull architettura iterativo e incrementale i dettagli di questo processo di tipo generale vanno adattati alle peculiarità della cultura dello sviluppo o del dominio applicativo di ciascuna organizzazione Pag. 16

9 UML: meta-modello UML si fonda su un meta-modello integrato, che definisce le caratteristiche e le relazioni esistenti tra i diversi elementi (classi, attributi, moduli, ) Il meta-modello è la base per l implementazione dell UML da parte dei produttori di strumenti di sviluppo (CASE, ambienti visuali, ) e per l interoperabilità tra i diversi strumenti Pag. 17 UML: meta-modello UML prevede una serie di modelli diagrammatici basati sul meta-modello gli elementi del meta-modello possono comparire in diagrammi di diverso tipo alcuni elementi (ad es. la classe ) hanno una icona che li rappresenta graficamente Pag. 18

10 Cos è UML UML è un linguaggio, un insieme di elementi e di regole, di specifica formale Gli elementi sono forme grafiche (linee, rettangoli, ecc.) che rappresentano ciò che si stà modellando Le regole che spiegano come combinare gli elementi sono di tre tipi: sintassi astratta, espressa tramite diagrammi e linguaggio naturale regole sintattiche, espresse tramite Obiect Costraint Language (OCL) e linguaggio naturale semantica, espressa in linguaggio naturale con il supporto di diagrammi Pag. 19 Struttura di UML(1/2) In un approccio top-down all UML si possono distinguere gli elementi fondamentali della sua struttura: Viste, Diagrammi, Elementi del modello Le viste mostrano i differenti aspetti di un sistema attraverso la realizzazione di un certo numero di diagrammi si tratta di astrazioni, ognuna delle quali analizza il sistema da modellare con un ottica diversa (funzionale, non funzionale, organizzativa, ecc.), la somma di queste viste fornisce il quadro d insieme Pag. 20

11 Struttura di UML (2/2) I diagrammi permettono di esprimere le viste logiche per mezzo di grafici vi sono diversi tipi di diagrammi destinati ad essere utilizzati ognuno per una particolare vista Gli elementi del modello sono i concetti che permettono di realizzare i vari diagrammi indicano gli attori, le classi, i packages, gli oggetti, ecc. Pag. 21 Le viste Design View Implementation View Use case View Process View Deployment View Pag. 22

12 Use case View La use case view serve per analizzare i requisiti utente: cosa il sistema dovrà fare Si tratta di una vista ad alto livello di importanza fondamentale guida lo sviluppo delle rimanenti stabilisce le funzionalità che il sistema dovrà realizzare Le funzionalità potranno essere individuate assieme al cliente grazie proprio all ausilio di tale vista che coadiuva il reperimento dei requisiti A questo livello di analisi, è opportuno studiare il sistema considerandolo come una scatola nera, concentrarsi sul cosa fare astraendosi il più possibile dal come verrà fatto Pag. 23 Design View La desing view descrive come le funzioni debbono essere realizzate In questa vista si analizza il sistema dall interno si trova la struttura statica del sistema (diagramma delle classi e diagramma degli oggetti) si trova la collaborazione dinamica dovuta alle interazioni tra gli oggetti del sistema Pag. 24

13 Implementation View La implementation view descrive come il codice contenuto nelle classi viene aggregato in moduli (package) e le relative interdipendenze Pag. 25 Process View La process view serve per analizzare gli aspetti non funzionali del sistema, e consiste nell individuare i processi Lo scopo è un utilizzo efficiente delle risorse poter stabilire l esecuzione parallela di determinati oggetti poter gestire correttamente eventuali eventi asincroni Pag. 26

14 Deployment View La deployment view mostra l architettura fisica del sistema e l ubicazione delle componenti software all interno della struttura stessa Pag. 27 Diagrammi UML I diagrammi di UML sono dei grafici che visualizzano una particolare proiezione del sistema analizzato da una specifica prospettiva Pag. 28

15 Diagrammi UML livello logico : dei casi d uso - Use Case Diagram delle classi - Class Diagram di sequenza - Sequence Diagram di collaborazione - Collaboration Diagram di transizione di stato - Statechart Diagram delle attività - Activity Diagram livello fisico : dei componenti - Component Diagram di distribuzione dei componenti - Deployment Diagram Pag. 29 Diagramma dei casi d uso Mostra: le modalità di utilizzo del sistema (casi d uso) gli utilizzatori e coloro che interagiscono con il sistema (attori) le relazioni tra attori e casi d uso Un caso d usod rappresenta un possibile modo di utilizzo del sistema descrive l interazione tra attori e sistema, non la logica interna della funzione una funzionalità dal punto di vista di chi la utilizza Pag. 30

16 Diagramma dei casi d uso attore: un utilizzatore del sistema acquistare articoli cliente log in cassiere rimborsare articoli venduti caso d'uso: un "modo" di utilizzare il sistema Pag. 31 Diagramma delle classi è il caposaldo dell object oriented rappresenta le classi di oggetti del sistema con i loro attributi e operazioni mostra le relazioni tra le classi (associazioni, aggregazioni e gerarchie di specializzazione/generalizzazione) può essere utilizzato a diversi livelli di dettaglio (in analisi e in disegno) Pag. 32

17 Diagramma delle classi Pag. Contanti Prodotto Pagamento importo aggregazione 1 descrive 1 riferito a Pag. Carta Credito 0..* Riga vendita ha 1..* 1 1 Vendita data ora specializzazione / generalizzazione crea_vendita() Cassiere utilizzato da 1 * POST associazione 1 1 avviato da * 1..* 1 Negozio nome 1 indirizzo Amministratore Pag. 33 Diagramma di sequenza è utilizzato per definire la logica di uno scenario (specifica sequenza di eventi) di un caso d uso (in analisi e poi ad un maggior livello di dettaglio in disegno) è uno dei principali input per l implementazione dello scenario mostra gli oggetti coinvolti specificando la sequenza temporale dei messaggi che gli oggetti si scambiano è un diagramma di interazione: evidenzia come un caso d uso è realizzato tramite la collaborazione di un insieme di oggetti Pag. 34

18 Diagramma di sequenza oggetto : POST : Vendita : Riga vendita : Prodotto : cassiere registra_articolo (prodotto_id, qta) [nuova vendita] crea vendita ( ) porzione del caso d'uso "Acquistare articoli" relativa alla registrazione articoli [vendita in corso] aggiungi riga vendita ( ) crea riga vendita (prodotto_id, qta) get_prezzo (prodotto_id) messaggio Pag. 35 Diagramma di collaborazione è un diagramma di interazione: rappresenta un insieme di oggetti che collaborano per realizzare il comportamento di uno scenario di un caso d uso a differenza del diagramma di sequenza, mostra i link (legami) tra gli oggetti che si scambiano messaggi, mentre la sequenza di tali messaggi è meno evidente può essere utilizzato in fasi diverse (analisi, disegno di dettaglio) Pag. 36

19 Diagramma di collaborazione 2: [nuova vendita] crea vendita ( ) 3: [vendita in corso] aggiungi riga vendita ( ) 1: registra_articolo (prodotto_id, qta) : POST : Vendita : cassiere 4: crea riga vendita (prodotto_id, qta) : Riga vendita 5: get_prezzo (prodotto_id) : Prodotto link oggetto Pag. 37 Diagramma transizioni di stato è normalmente utilizzato per modellare il ciclo di vita degli oggetti di una singola classe mostra gli eventi che causano la transizione da uno stato all altro, le azioni eseguite a fronte di un determinato evento quando un oggetto si trova in un certo stato può essere interessato da determinati eventi (e non da altri) è opportuno utilizzarlo solo per le classi che presentano un ciclo di vita complesso e segnato da una successione ben definita di eventi Pag. 38

20 Diagramma transizioni di stato aggiungi riga ordine stato iniziale acquisisci ordine acquisito stato Transizione di stato verifica ordine annullato verificato e completato scadenza termini di pagamento dopo un anno pagamento ricevuto pagato spedizione al cliente spedito stato finale dopo un anno Pag. 39 Diagramma di attività rappresenta sistemi di workflow, oppure la logica interna di un processo (processo di business o processo di dettaglio), di un caso d uso o di una specifica operazione di una classe permette di modellare processi paralleli e la loro sincronizzazione è un caso particolare di diagrammi di stato, in cui ogni stato è uno stato di attività Pag. 40

21 Diagramma di attività Cliente Vendite Magazzino richiedi servizio paga ricevi ordine completa ordine ricevi merce spedisci merce Pag. 41 Diagramma dei componenti evidenzia l'organizzazione e le dipendenze tra i componenti software i componenti (come a livello logico i casi d uso o le classi) possono essere raggruppati in package un componente è una qualunque porzione fisica riutilizzabile con un identità e un interfaccia (dichiarazione di servizi offerti) ben definite un componente può essere costituito dall aggregazione di altri componenti Pag. 42

22 Diagramma dei componenti Vendita.java Java.awt Prodotto.java componente POST.java Vendita.exe relationship di dependency Pag. 43 Diagramma di distribuzione è utilizzato per mostrare come sono configurate e allocate le unità hardware e software per un applicazione evidenzia la configurazione dei nodi elaborativi in ambiente di esecuzione (run-time), e dei componenti, processi ed oggetti allocati su questi nodi Pag. 44

23 Diagramma di distribuzione Client Application Server Data Server TCP/IP TCP/IP Connessione tra nodi nodo Pag. 45 Package consente di partizionare il sistema in sottosistemi costituiti da elementi omogenei di: natura logica (classi, casi d uso, ) natura fisica (moduli, tabelle, ) altra natura (processori, risorse di rete, ) ogni elemento appartiene ad un solo package un package può referenziare elementi appartenenti ad altri package Pag. 46

24 Package Negozio Negozio 1 1..* POST * 1 Manager Package Servizi di base Oracle Java Virtual Machine Java.applet Pag. 47 UML - considerazioni finali UML rappresenta un evoluzione dei modelli preesistenti, più che una rivoluzione è adatto a esprimere modelli di varia tipologia, creati per obiettivi diversi può descrivere un sistema software a diversi livelli di astrazione, dal piano più svincolato dalle caratteristiche tecnologiche fino all allocazione dei componenti software nei diversi processori in un architettura distribuita Pag. 48

25 UML - considerazioni finali UML è sufficientemente complesso per rispondere a tutte le necessità di modellazione, ma è opportuno ritagliarlo in base alle specifiche esigenze dei progettisti e dei progetti, utilizzando solo ciò che serve nello specifico contesto keep the process as simple as possible! Pag. 49 Le relazioni tra i modelli di UML Le tecniche di modellazione UML da un punto di vista iterativo Pag. 50

26 I modelli di UML e le fasi del processo Le tecniche di modellazione UML da un punto di vista periodico Pag. 51