Comments
Description
Transcript
Real World UML
Real World UML Omid Ehsani Senior Consultant and Trainer [email protected] Sponsor Parliamo di… • • • • • L’importanza della modellazione UML in 21 minuti… Design Pattern e UML Un’applicazione reale “Agile” UML! L’importanza della modellazione L’importanza della modellazione • Spesso i team di sviluppo non fanno progettazione • Molti sviluppano applicazioni come costruirebbero la “cuccia del cane” – Manca la definizione di un’architettura – Dai requisiti si passa subito alla codifica – Si lavora più tempo e si scrive più codice Software is often treated as a SOFT science Modeling helps make it a HARD science L’importanza della modellazione • Costruiamo modelli (o blueprints) per comprendere meglio il sistema che stiamo sviluppando • La modellazione: – Ci aiuta a visualizzare il sistema come dovrebbe essere – Ci permette di specificare la struttura e il comportamento del sistema. – Ci fornisce una linea guida nella costruzione del sistema – Documenta le decisioni che prendiamo – Scompone il problema – Controlla la complessità – E’ un punto di partenza • Costruiamo modelli dei sistemi complessi perchè non siamo in grado di comprendere tali sistemi nella loro interezza Cosa è UML? • UML è un linguaggio per ... – Visualizzare – Specificare – Costruire – Documentare ... gli artefatti di un sistema software UML è il “blueprint” per la costruzione del software Cosa è UML? • UML è “Il Linguaggio” per l’analisi e la progettazione Object Oriented Contributi all’UML Booch Rumbaugh Jacobson Meyer Fusion Operation descriptions, Message numbering Before and after conditions Embley Harel Singleton classes, High-level view State charts Gamma, et.al Wirfs-Brock Frameworks, patterns, notes Shlaer - Mellor Object Lifecycles Odell Classification Responsibilities Breve storia di UML • Inizio progetto: ottobre 1994 • Proposta a OMG (Object Management Group): gennaio 1997 • Accettazione, da parte di OMG, della versione 1.1: novembre 1997 • Attualmente: UML versione 1.5 • Alle porte: UML 2.0 Panoramica su UML • UML è un linguaggio – Un linguaggio fornisce un vocabolario e le regole per combinare le parole allo scopo di comunicare – Non è una metodologia, ma è utilizzato da molti processi di sviluppo del software Panoramica su UML • UML è un linguaggio per visualizzare – La visualizzazione facilita la comunicazione e favorisce un adeguato livello di astrazione – Un’immagine vale mille parole Panoramica su UML • UML è un linguaggio per stendere specifiche – Stendere specifiche significa costruire modelli che siano precisi, non ambigui e completi – I simboli UML hanno una sintassi e una semantica ben definite Panoramica su UML • UML è un linguaggio per costruire – UML non è un ambiente di programmazione visuale ma i suoi modelli sono nati per essere tradotti in linguaggi Object Oriented Panoramica su UML • UML è un linguaggio per documentare – le specifiche funzionali – l’architettura generale – la scomposizione strutturale del sistema – le interazioni tra i componenti – la distribuzione e il deployment UML in 21 minuti... • I modelli di UML sono espressi attraverso una serie di diagrammi • Esistono diverse tipologie di diagrammi • Ogni tipologia coglie un aspetto diverso del sistema I Diagrammi di UML • • • • • • • • Use Case Diagram Sequence Diagram Collaboration Diagram Statechart (STD) Diagram Activity Diagram Component Diagram Deployment Diagram Class Diagram Use Cases Diagram • • • • Un sistema risponde ai bisogni dei suoi utenti Questi bisogni sono catturati come Use Cases Uno Use Case è un modo di usare il sistema Uno Use Case è uno schema di comportamento esibito dal sistema • La collezione degli Use Cases specifica tutti i modi di usare il sistema Actors • Un Actor è qualcuno o qualcosa che deve interagire con il sistema • Gli Actors rappresentano qualunque cosa che deve scambiare informazioni con il sistema Actors e Use Cases Perform Card Transaction Process Customer Bill Retail Institution Customer Reconcile Transactions Manage Customer Account Sponsoring Financial Institution Actors e Use Cases Perform Card Transaction Process Customer Bill Retail Institution Customer Reconcile Transactions Manage Customer Account Sponsoring Financial Institution Realizziamo gli Use Cases • Gli Interaction Diagrams permettono di ottenere il modello di come interagiscono Actors e oggetti per realizzare uno Use Case • Sono realizzati tramite due diverse, e complementari, modalità: – i Collaboration Diagrams – i Sequence Diagrams Sequence Diagrams • Un Sequence Diagram mette in evidenza: – la sequenza temporale dei messaggi – la lifetime degli oggetti – il focus of control Sequence Diagrams s:Caller :Switch r:Caller liftReceiver setDialTone() {dialing.executionTime<30 sec} *dialDigit(d) routeCall(s,n) dialing c:Conversation «create» ring() liftReceiver connect(r) connect(r,s) connect(s) Collaboration Diagrams • Un Collaboration Diagram mette in evidenza: • l’organizzazione degli oggetti che partecipano in una interazione • la lifetime degli oggetti • il focus of control Collaboration Diagrams routeCall(s,n) 1: liftReceiver 3:*dialDigit(d) :Switch s:Caller 2: setDialTone() 10: connect(r) 8: connect(r,s) 5: «create» 6: ring() 9: connect(s) r:Caller c:Conversation 7: liftReceiver Statechart (STD) Diagram • Una macchina a stati è usata per ottenere il modello di un singolo oggetto • Una macchina a stati descrive la sequenza degli stati attraverso i quali transita un oggetto durante il suo ciclo di vita in risposta a eventi, assieme alle sue risposte a tali eventi • Il diagramma che descrive la macchina a stati è detto State Transition Diagram (STD) Statechart (STD) Diagram • Uno stato è una condizione o situazione durante la vita di un oggetto nella quale l’oggetto soddisfa qualche condizione, esegue qualche attività, o aspetta per qualche evento • Un evento è la specifica di un “qualcosa” la cui durata è trascurabile rispetto alla durata del ciclo di vita dell’oggetto • Una transizione è una relazione fra due stati che indica che un oggetto passerà dall’uno all’altro come effetto di un evento o quando una specifica condizione è verificata • Una azione è una operazione atomica il cui effetto è o un cambiamento di stato o il ritorno di un valore STD per una Linea Telefonica Idle on-hook off-hook Dial Tone do: sound dial tone STD per una Linea Telefonica Idle off-hook Dial Tone do: sound dial tone digit(n) Dialing valid number digit(n) Connecting do: find connection routed Ringing do: ring bell called phone answers on-hook Connected called phone hangs up Disconnected STD per una Linea Telefonica Idle on-hook off-hook Dial Tone do: sound dial tone time-out Timed-out do: sound loud beep STD per una Linea Telefonica Idle off-hook Dial Tone do: sound dial tone digit(n) Dialing invalid number digit(n) on-hook Receiving Recorded Message do: play message message done on-hook Disconnected STD per una Linea Telefonica Idle off-hook Dial Tone do: sound dial tone on-hook Busy do: sound busy tone digit(n) Dialing valid number number busy Connecting do: find connection digit(n) STD per una Linea Telefonica Idle Dial Tone do: sound dial tone on-hook Busy do: sound busy tone digit(n) Dialing on-hook on hook/disconnect line on-hook Connecting do: find connection Timed-out do: sound loud beep time-out invalid number valid number number busy on-hook off-hook on-hook digit(n) on-hook Receiving Recorded Message do: play message message done routed Ringing do: ring bell called phone answers Connected called phone hangs up Disconnected STD per la partita degli Scacchi White’s turn do: think black moves checkmate stalemate white moves Black’s turn do: think stalemate checkmate Black wins Draw White wins Component Diagram • Un Component Diagram mostra un insieme di componenti e le loro relazioni • Un Component Diagram comunemente contiene: – Componenti – Interfacce – Relazioni di dipendenza, generalizzazione, associazione e realizzazione Un Component Diagram find.html index.html __________ __________ __________ «hyperlink» ____ __________ __________ __________ __________ ____ __________ dbacs.dll find.exe nateng.dll Deployment Diagram • Un deployment diagram è un diagramma che documenta la configurazione al run time dei nodi che partecipano al processo e i componenti che vivono in essi • Tipicamente un deployment diagram è usato per avere il modello di – Sistemi embedded – Client/server – Sistemi distribuiti Il Modello di un Sistema Client/Server servers clients 2..* «processor» caching server console Deploys http.exe rting.exe 4..* «processor» server Deploys dbadmin.exe tktmstr.exe logexec.exe Il Modello di un Sistema Distribuito Note: country servers are reachable to one another via the company’s private network :console :console :console :Internet :regional server :country server :regional server :regional server :logging server Class Diagrams • Un Class Diagram è un diagramma che mostra un insieme di classi, interfacce, e collaborazioni e le loro dipendenze • Un Class Diagram è un modello statico del sistema utilizzato per – ottenere un dizionario del sistema – avere un modello di collaborazione fra gli oggetti (p.e. per specificare quali oggetti partecipano a una transazione) – avere un modello logico dello schema del database Class Diagram multiplicity Company 1..* Department 1 aggregation 1..* Office generalization Headquarters * Location * constraint class association role member {subset} manager 1..* 1 PersonelRecord Person ContactInformation (class) name dependency interface 0..1 ISecureInformation Class Diagram Company 1..* 0..1 1 Department * Location name: Name member {subset} manager 1..* 1 Person name: Name employeeID: Integer title: String getPhoto(p: Photo) getSoundByte() getContactInformation() getPersonalRecords() 1..* Office * address: String voice: Number attributes ContactInformation address: String Headquarters PersonelRecord taxID employmentHistory PersonelRecord operations ISecureInformation Packages • Un Package è un meccanismo di uso generale per – organizzare in gruppi gli elementi che sono semanticamente simili o funzionalmente correlati – I package possono essere utilizzati oer creare gerarchie di contenitori (come i folder per il file-system) Packages e Servizi User Services Business Services Data Services Design Pattern e UML • Impariamo a leggere i Design Pattern – Per capire meglio i Pattern li “visualizziamo” con diagrammi UML – Anche quando conosciamo un Pattern non sempre ne ricordiamo la struttura, un colpo d’occhio al Class Diagram ci rinfresca la memoria • I Pattern costituiscono un vocabolario comune per la comunicazione dei concetti – Anche l’UML è un vocabolario comune, ma è “disegnato” invece che scritto o parlato Esempi di Design Pattern Factory Esempi di Design Pattern Adapter Esempi di Design Pattern Observer Un’applicazione reale • Utilizziamo l’UML per documentare l’applicazione Northwind • Manutenere i diagrammi UML in sincronia con il codice sorgente non è una sfida da poco – Molti tool di modellazione UML fanno il Reverse-Engineering, il Forward-Engineering e il Round-Trip modeling DEMO • Reverse Engineering di Northwind • Individuazione dei pattern sui diagrammi UML • Progettazione e realizzazione di un DataProvider aggiuntivo “Agile” UML! • Non correte il rischio di “over-designing” – Utilizzate UML con dosi sostenibili – Trovate il giusto livello di dettaglio da applicare ai diagrammi • Dal punto di vista di artefatti UML=Documentazione • Ricordatevi del manifesto: “Software funzionante invece che documentazione esaustiva” “Agile” UML! • Non diventate schiavi dei vostri diagrammi – Molti diagrammi possono servire per “pensare” prima di scrivere, poi possono essere gettati via! – L’obiettivo finale non è costruire modelli, ma sistemi software – Se decidete di mantenere i diagrammi dotatevi di un tool che li sincronizzi al meglio con il codice – I diagrammi di più alto livello (architetturali o concettuali) hanno un valore che giustifica la loro manutenzione nel tempo “Agile” UML! • Non ve la sentite di fare pair-programming? Provate il pair-designing! Il rendimento è garantito • La condivisione delle conoscenze è più immediata sui diagrammi che sul codice • La memoria visiva è più duratura nel tempo, le righe di codice si dimenticano Questions & Answers Sito ufficiale: http://www.uml.org/ Libri: • UML Distilled (Martin Fowler, Kendall Scott) – Addison Wesley • The Unified Modeling Language Reference (James Rambaugh, Ivar Jacobson, Grady Booch) - Addison Wesley • Writing Effective Use Cases (Alistair Cockburn) - Addison Wesley Omid Ehsani Senior Consultant and Trainer [email protected]