La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Introduzione a UML (c) TECNET DATI. Pag. 2 Perché modelliamo Un modello è una semplificazione della realtà I modelli ci aiutano a visualizzare un sistema.

Presentazioni simili


Presentazione sul tema: "Introduzione a UML (c) TECNET DATI. Pag. 2 Perché modelliamo Un modello è una semplificazione della realtà I modelli ci aiutano a visualizzare un sistema."— Transcript della presentazione:

1 Introduzione a UML (c) TECNET DATI

2 Pag. 2 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

3 (c) TECNET DATI Pag. 3 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

4 (c) TECNET DATI Pag. 4 Approcci metodologici Un po di storia …. anni 70Approccio Strutturato anni 80Information Engineering anni 90Approccio 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

5 (c) TECNET DATI Pag. 5 Approccio Strutturato (Yourdon - De Marco) Caratteristiche: 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 lattenzione è rivolta soprattutto alla componente funzionale

6 (c) TECNET DATI Pag. 6 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 dallanalisi al disegno Che cosa resta attuale dellapproccio strutturato? la distinzione ferrea tra analisi (cosa) e disegno (come) lattenzione 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)

7 (c) TECNET DATI Pag. 7 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

8 (c) TECNET DATI Pag. 8 Information Engineering Limiti origine anni 80: approccio data driven, ma ancora legato alla separazione dati - processi tecniche di analisi e disegno derivate dallapproccio strutturato lambiente target previsto è ancora monopiattaforma Che cosa resta attuale dellInformation Engineering? la suddivisione in macrofasi lattenzione allautomazione del processo di sviluppo e manutenzione (CASE …) linsistenza sulla partecipazione dellutente a tutte le fasi del ciclo di sviluppo / manutenzione

9 (c) TECNET DATI Pag. 9 Approccio Object Oriented Inizio anni 70Programmazione OO fine anni 80Analisi e Disegno OOCaratteristiche: superamento della distinzione tra dati e funzioni concetti nuovi: ereditarietà, information hiding, … forte tendenza al riutilizzo di componenti software già definite

10 (c) TECNET DATI Pag. 10 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

11 (c) TECNET DATI Pag. 11 Unified Modeling Language un linguaggio (e notazione) universale, per la creazione di modelli software nel novembre 97 è diventato uno standard approvato dallOMG (Object Management Group) numerosi i co-proponenti: Microsoft, IBM, Oracle, HP, Platinum, Sterling, Unysis …..

12 (c) TECNET DATI Pag. 12 Unified Modeling Language è lunificazione dei metodi: Grady Booch –Booch-93 di Grady Booch Jim Rumbaugh –OMT di Jim Rumbaugh Ivar Jacobson –OOSE di Ivar Jacobson ha accolto inoltre le idee di numerosi altri metodologi è tuttavia indipendente dai metodi, dalle tecnologie, dai produttori

13 (c) TECNET DATI Pag. 13 Storia di UML Unified Method 0.8 UML 0.9 UML 1.0 UML 1.1 UML è approvato dallOMG RumbaughBooch Jacobson Microsoft, Oracle, HP e altri IBM, Platinum e altri e altri Nov 97 Set 97 Gen 97 Giu 96 Ott 95

14 (c) TECNET DATI Pag. 14 UML - linguaggio universale linguaggio linguaggio per specificare, costruire, visualizzare e documentare gli artefatti di un sistema universale universale: può rappresentare sistemi molto diversi, da quelli web ai legacy, dalle tradizionali applicazioni Cobol a quelle object oriented e a componenti

15 (c) TECNET DATI Pag. 15 UML non è un metodo linguaggio di modellazioneè 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 questaltra

16 (c) TECNET DATI Pag. 16 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 dUso (use case driven) – incentrato sullarchitettura – 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

17 (c) TECNET DATI Pag. 17 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 limplementazione dellUML da parte dei produttori di strumenti di sviluppo (CASE, ambienti visuali, …) e per linteroperabilità tra i diversi strumenti

18 (c) TECNET DATI Pag. 18 UML: meta-modello modelli diagrammaticiUML 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

19 (c) TECNET DATI Pag. 19 Diagrammi UML livello logico: dei casi duso - 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

20 (c) TECNET DATI Pag. 20 Diagramma dei casi duso Mostra: le modalità di utilizzo del sistema (casi duso) gli utilizzatori e coloro che interagiscono con il sistema (attori) le relazioni tra attori e casi duso caso duso Un caso duso rappresenta un possibile modo di utilizzo del sistema descrive linterazione tra attori e sistema, non la logica interna della funzione una funzionalità dal punto di vista di chi la utilizza

21 (c) TECNET DATI Pag. 21 Diagramma dei casi duso acquistare articoli log in cassiere cliente rimborsare articoli venduti attore: un utilizzatore del sistema caso d'uso: un "modo" di utilizzare il sistema

22 (c) TECNET DATI Pag. 22 Diagramma delle classi è il caposaldo dellobject 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)

23 (c) TECNET DATI Pag. 23 Diagramma delle classi Amministratore Cassiere Negozio nome indirizzo Prodotto POST * 1 * 1 avviato da 1111 utilizzato da 1..* 1 1 Riga vendita 0..* 1 1 descrive Vendita data ora crea_vendita() 11 * 1..*1 1 ha Pagamento importo 11 1 riferito a Pag. Contanti Pag. Carta Credito associazione aggregazione specializzazione / generalizzazione

24 (c) TECNET DATI Pag. 24 Diagramma di sequenza è utilizzato per definire la logica di uno scenario (specifica sequenza di eventi) di un caso duso (in analisi e poi ad un maggior livello di dettaglio in disegno) è uno dei principali input per limplementazione 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 duso è realizzato tramite la collaborazione di un insieme di oggetti

25 (c) TECNET DATI Pag. 25 Diagramma di sequenza : cassiere : POST : Vendita : Riga vendita : Prodotto porzione del caso d'uso "Acquistare articoli" relativa alla registrazione articoli registra_articolo (prodotto_id, qta) [nuova vendita] crea vendita ( ) crea riga vendita (prodotto_id, qta) get_prezzo (prodotto_id) [ vendita in corso] aggiungi riga vendita ( ) oggetto messaggio

26 (c) TECNET DATI Pag. 26 Diagramma di collaborazione è un diagramma di interazione: rappresenta un insieme di oggetti che collaborano per realizzare il comportamento di uno scenario di un caso duso 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)

27 (c) TECNET DATI Pag. 27 Diagramma di collaborazione : cassiere : POST : Vendita : Riga vendita : Prodotto oggetto link 1: registra_articolo (prodotto_id, qta) 2: [nuova vendita] crea vendita ( ) 3: [vendita in corso] aggiungi riga vendita ( ) 4: crea riga vendita (prodotto_id, qta) 5: get_prezzo (prodotto_id)

28 (c) TECNET DATI Pag. 28 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 allaltro, 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

29 (c) TECNET DATI Pag. 29 Diagramma transizioni di stato acquisito pagato spedito annullato acquisisci ordine aggiungi riga ordine verificato e completato spedizione al cliente pagamento ricevuto scadenza termini di pagamento verifica ordine dopo un anno stato Transizione di stato stato iniziale stato finale

30 (c) TECNET DATI Pag. 30 Diagramma di attività rappresenta sistemi di workflow, oppure la logica interna di un processo (processo di business o processo di dettaglio), di un caso duso 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à

31 (c) TECNET DATI Pag. 31 richiedi servizio ricevi ordine paga completa ordine ricevi merce spedisci merce ClienteVenditeMagazzino Diagramma di attività

32 (c) TECNET DATI Pag. 32 Diagramma dei componenti evidenzia l'organizzazione e le dipendenze tra i componenti software i componenti (come a livello logico i casi duso o le classi) possono essere raggruppati in package componenteun componente è una qualunque porzione fisica riutilizzabile con unidentità e uninterfaccia (dichiarazione di servizi offerti) ben definite un componente può essere costituito dallaggregazione di altri componenti

33 (c) TECNET DATI Pag. 33 Diagramma dei componenti componente relationship di dependency Vendita.exeVendita.javaProdotto.javaPOST.javaJava.awt

34 (c) TECNET DATI Pag. 34 Diagramma di distribuzione è utilizzato per mostrare come sono configurate e allocate le unità hardware e software per unapplicazione evidenzia la configurazione dei nodi elaborativi in ambiente di esecuzione (run-time), e dei componenti, processi ed oggetti allocati su questi nodi

35 (c) TECNET DATI Pag. 35 Diagramma di distribuzione Server Application TCP/IP Client Data Server nodo Connessione tra nodi

36 (c) TECNET DATI Pag. 36 Package consente di partizionare il sistema in sottosistemi costituiti da elementi omogenei di: logica – natura logica (classi, casi duso, …) fisica – 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

37 (c) TECNET DATI Pag. 37 Package Servizi di base Oracle Java Virtual Machine Java.applet Negozio POSTManager 11..*1* Package

38 (c) TECNET DATI Pag. 38 UML - considerazioni finali UML rappresenta unevoluzione 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 allallocazione dei componenti software nei diversi processori in unarchitettura distribuita

39 (c) TECNET DATI Pag. 39 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!

40 (c) TECNET DATI Pag. 40 Le relazioni tra i modelli di UML Le tecniche di modellazione UML da un punto di vista iterativo

41 (c) TECNET DATI Pag. 41 I modelli di UML e le fasi del processo Le tecniche di modellazione UML da un punto di vista periodico


Scaricare ppt "Introduzione a UML (c) TECNET DATI. Pag. 2 Perché modelliamo Un modello è una semplificazione della realtà I modelli ci aiutano a visualizzare un sistema."

Presentazioni simili


Annunci Google