Modellare sistemi software con UML

Transcript

1 Modellare sistemi software con UML Andrea Baruzzo Dipartimento di Matematica e Informatica Università degli Studi di Udine Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

2 Agenda Introduzione: approccio e motivazioni Modellare la struttura statica Modellare la struttura dinamica Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

3 Introduzione: l approccio Approccio pratico alla modellazione e alla verifica di sistemi software reali Conseguenza: tecnologie, strumenti e linguaggi largamente utilizzati in ambito industriale Scelte soggettive Sistemi software target: sistemi object-oriented Linguaggi di programmazione target: C++, Java Linguaggio di modellazione: UML Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

4 Linguaggio di programmazione o di modellazione? Perché un linguaggio di modellazione? Spostare discussioni di design dal codice al modello fornisce un più alto livello di astrazione indipendente dalla sintassi e dai dettagli del singolo linguaggio di programmazione Un buon design è caratterizzato da alcuni indici di qualità come la stratificazione, la distribuzione del controllo, l incapsulamento, la coesione Questi indici di qualità si vedono meglio su un modello grafico che sulle righe di codice Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

5 Introduzione: Perché UML per fare verifica? Perché UML? E uno standard de facto a livello industriale per descrivere sistemi software object-oriented Esiste una semantica formale per almeno una parte del linguaggio (classi, stati) Unified Modeling Language: chi, dove, quando Booch, Jacobson e Rumbaugh; (UML 0.9) Standard OMG (Object Management Group) dal 1997 Versione attuale: 2.0 (06/2005) Diagrammi per descrivere diversi aspetti di un sistema software: struttura statica (architettura, sottosistemi, moduli, ) struttura dinamica (scenari d esecuzione, interazioni, stati, ) requisiti funzionali (casi d uso) vincoli (temporali, performance, contratti software) Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

6 UML: Bibliografia ragionata The Unified Modeling Language User Guide 2/E by Grady Booch, James Rumbaugh, Ivar Jacobson - Addison-Wesley Professional, 2005 The Unified Modeling Language Reference Manual 2/E by James Rumbaugh, Ivar Jacobson, Grady Booch - Addison-Wesley Professional, 2004 UML Distilled: A Brief Guide to the Standard Object Modeling Language 2/E by Martin Fowler - Addison-Wesley Professional, 2003 Applying UML and Patterns : An Introduction to Object- Oriented Analysis and Design and Iterative Development 3/E by Craig Larman - Addison-Wesley Professional, 2004 UML 2 and the Unified Process : Practical Object-Oriented Analysis and Design 2/E by Jim Arlow, Ila Neustadt - Addison-Wesley Professional, 2005 UML Bible by Tom Pender - Wiley, 2003 Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

7 Parte I: Modellare sistemi software con UML Introduzione: approccio e motivazioni Modellare la struttura Diagrammi di classe Diagrammi degli oggetti Diagrammi dei componenti Diagrammi di deployment Diagrammi delle strutture composte (composite structure) (UML 2.0) Modellare la dinamica Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

8 Modellare la struttura Struttura come sinonimo di diverse cose architettura (modularità, gestione del controllo, ) organizzazione logica (sottosistemi, interfacce, ) organizzazione fisica (librerie, componenti, ) Descrive una vista (prospettiva) del sistema che pone l accento sulla struttura statica del sistema (classi, relazioni, attributi, operazioni, gerarchie, componenti, ) Quali diagrammi? diagrammi di classe e degli oggetti diagrammi dei componenti diagrammi di deployment diagrammi delle strutture composte (composite structure) Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

9 Diagrammi di classe Classi, attributi, metodi Relazioni fra classi Ereditarietà Contenimento Associazione, dipendenze Classi astratte, interfacce Package Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

10 Classi, attributi, metodi Rettangolo con tre compartimenti: Nome della classe Attributi (nome, tipo) Metodi (nome, args, tipo ritorno) cd Logical Model NomeClasse - attribintprivato: int # attribstringprotetto: string + attribbooleanpubblico: boolean + NomeMetodoPubblico(double) : void - NomeMetodoPrivato() : void + NomeMetodoProtetto(NomeClasse) : NomeClasse Visibilità: + pubblica (il default per i metodi) - privata (tipica per gli attributi) # protetta (ereditarietà protetta, visibilità legata al package in Java) Non è obbligatorio mostrare tutti i compartimenti Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

11 Alcuni esempi cd Logical Model Studente - cognome: string - nome: string - matricola: int Velivolo - portata: int - velocitàmax: double - annofabbricazione: int FiguraGeometrica - area: int + disegna() : void + getannoiscrizione() : int + decolla() : void + atterra() : void + frena() : void + accelera(double) : void Convenzioni sui nomi Classe: lettera maiuscola iniziale per ogni parola Attributi: lettera minuscola iniziale, maiuscola iniziale per ogni successiva parola Metodi: (C++) maiuscola iniziale per ogni parola (Java) stessa degli attributi Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

12 Relazioni fra classi Relazioni di: Ereditarietà Contenimento Associazione Dipendenze Classi astratte, interfacce Package Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

13 Ereditarietà Classe base, classi derivate La classe base definisce attributi comuni (ereditati) La classe base definisce interfaccia comune (ereditata) Le classi derivate specializzano la classe base aggiungendo attributi e/o comportamenti (metodi) Le classi derivate possono anche ridefinire metodi ereditati Le classi derivate possono invocare i metodi delle classi base, purché definiti pubblici o protetti Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

14 Esempio di gerarchia di classi cd Logical Model Velivolo - portata: int - velocitàmax: double - annofabbricazione: int + decolla() : void + atterra() : void + frena() : void + accelera(double) : void Bimotore - numeromotori: int - numeropasseggeri: int + decolla() : void + atterra() : void + frena() : void + accelera(double) : void Mig - mitragliatrici: int + decolla() : void + spara() : void + atterra() : void + frena() : void + accelera(double) : void UltraLeggeroSenzaMotore - numeroassi: int + decolla() : void + atterra() : void + frena() : void + accelera(double) : void aggiunge il numero di motori, ridefinisce i metodi ereditati aggiunge gli armamenti e il metodo spara, ridefinisce i metodi ereditati aggiunge il numero di assi, ridefinisce i metodi ereditati Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

15 Contenimento Due forme: Forte, detta composizione Debole, detta aggregazione La composizione associa composto e componente per tutta la vita dei due oggetti (è una relazione permanente) La composizione è una relazione esclusiva: uno specifico oggetto componente non può appartenere a due composti contemporaneamente Se questi vincoli non sono soddisfatti, si usa l aggregazione Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

16 Esempi di contenimento (composizione + aggregazione) Composizione (rombo pieno) e aggregazione (rombo vuoto) cd Logical Model Telaio Le cardinalità sono importanti! 1 1 L aggregazione è sinonimo di (possibile) condivisione; semantica del contenimento by reference (puntatori) Velivolo * 1 1 3,* Ruota L aggregazione è una relazione temporanea e non esclusiva 1..* Colore 0..* Passeggero Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

17 Associazione e dipendenze L associazione esprime un legame permanente che vale per tutta la vita degli oggetti coinvolti cd Logical Model Dipendente Associazione +lavora per +assume Azienda 1..* 1 Evidenzia anche i ruoli cd Logical Model File IOException La dipendenza esprime invece un generico legame temporaneo (ad es. una chiamata) Lo «stereotipo» chiarisce la semantica della ipendenza «open» Applicazione «throws» Dipendenza Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

18 Classi astratte e interfacce Una classe astratta ha almeno un metodo virtuale puro (metodo astratto puro) Un interfaccia non ha attributi e ha solo metodi virtuali puri (metodi astratti puri) Eccezione Java: le interfacce possono dichiarare come attributi delle costanti Le classi che estendono (derivano da) una classe base astratta devono fornire un implementazione per tutti i metodi astratti Lo stesso vale nel caso delle interfacce Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

19 Esempio di classe astratta cd Logical Model Metodi e classi astratte sono specificati da un nome in corsivo Velivolo - portata: int - velocitàmax: double - annofabbricazione: int + decolla() : void + atterra() : void + frena() : void + accelera(double) : void Bimotore - numeromotori: int - numeropasseggeri: int + decolla() : void + atterra() : void + frena() : void + accelera(double) : void Mig - mitragliatrici: int + decolla() : void + spara() : void + atterra() : void + frena() : void + accelera(double) : void UltraLeggeroSenzaMotore - numeroassi: int + decolla() : void + atterra() : void + frena() : void + accelera(double) : void aggiunge il numero di motori, ridefinisce i metodi ereditati aggiunge gli armamenti e il metodo spara, ridefinisce i metodi ereditati aggiunge il numero di assi, ridefinisce i metodi ereditati Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

20 Esempio di interfaccia La freccia tratteggiata indica esattamente la realizzazione,ossia l implementazione di un interfaccia cd Logical Model «interface» Driver + Read() + write() Da non confondere con la freccia continua dell ereditarietà Lo stereotipo chiarisce la semantica, ma è opzionale Driv erstampante - portalpt: int + Read() + write() «realize» «realize» Driv erschedavideo - memoriavideo: int + Read() + write() Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

21 Package Un package è un elemento di raggruppamento Serve per organizzare elementi UML correlati Si applica sia ai diagrammi, sia alle classi e ad altri elementi UML (ad es. i casi d uso) Simbolo: cd Class Model Package Package + Class1 + Class2 Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

22 Esempi di package Diagramma di package poco informativo. Elenca una serie di package, ma non esplicita relazioni tra i package È utile esplicitare le relazioni tra i package, in particolare dipendenze e i livelli d astrazione Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

23 Esempi di package Ispirato da: 3D Game Engine Design : A Practical Approach to Real-Time Computer Graphics by David H. Eberly - Morgan Kaufmann, September 2000 Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

24 Parte I: Modellare sistemi software con UML Introduzione: approccio e motivazioni Modellare la struttura Diagrammi di classe Diagrammi degli oggetti Diagrammi dei componenti Diagrammi di deployment Diagrammi delle strutture composte (composite structure) - (UML 2.0) Modellare la dinamica Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

25 Diagrammi degli oggetti E un istanza specifica di un diagramma di classe Modella fatti ed esempi: parla di oggetti specifici Le cardinalità nel diagramma di classe vengono sostituite da relazioni esplicite Il nome della classe viene preceduto dal nome dell istanza (oggetto): nomeoggetto : nomeclasse cd Class Model Student - averagemark: int - name: string - phonenumber: int - studentnumber: int - address: string + iseligible(int, string) : boolean + getseminarstaken() : List<Seminar> classe Student Andrea Baruzzo : Student Oggetto di tipo Student in cui: name = "Andrea Baruzzo" Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

26 Istanziare un diagramma di classe mediante un. cd Class Model Student SeminarEnrollment - averagemark: int - name: string - phonenumber: int - studentnumber: int - address: string 1 enrolledin 1..* - markasreceived: boolean + GetAverageToDate() + GetFinalMark() 1..* enrolledin + iseligible(int, string) : boolean + getseminarstaken() : List<Seminar> 1 +livesat * Seminar - seminarnumber: int - waitinglist: List<Seminar> + AddStudent(Student) : void + DropStudent(Student) : void 0..* 1 +instructs 0..1 offeringof Address - city: string - street: string - postalcode: string - state: stri ng - country: string + validate() : void 1 +livesat 0..1 Teacher - name: string - address: string - phonenumber: int - salary: double + GetInformations() : string +associ ate 0..* +advisor 0..1 Course - name: string - coursenumber: int - fees: double + GetFullName() : string 1 mentors Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

27 Diagramma degli oggetti cd Class Model +livesat Andrea Baruzzo : Student Christian Giusti : Student enrolledin enrolledin WCP enrollment : SeminarEnrollment enrolledin AB Address : Address +livesat General Relativity : Seminar CGAddress : Address +instructs Albert Einstein : Teacher +livesat :Address Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

28 Parte I: Modellare sistemi software con UML Introduzione: approccio e motivazioni Modellare la struttura Diagrammi di classe Diagrammi degli oggetti Diagrammi dei componenti Diagrammi di deployment Diagrammi delle strutture composte (composite structure) (UML 2.0) Modellare la dinamica Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

29 Diagrammi dei componenti Descrive le parti fisiche del software (componenti) che costituiscono il sistema nella sua implementazione Esempi tipici di componenti: librerie, componenti EJB, form HTML, JSP, browser Web, Evidenzia anche le relazioni tra i componenti e la loro interfaccia Simbolo del componente: id Components ProvidedInterface1 Component1 id Components «library» Cometa RequiredInterface Component2 Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

30 Esempio di diagramma dei componenti Diagramma dei componenti che descrive la struttura interna del componente cd Internal Structures Component1 ProvidedInterface1 «delegate» Part1 This illustrates how the services offered by this component are internally delegated to a specific object. Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

31 Esempio di diagramma dei componenti id Monitor-Actuator Actuation channel Actuation Data Source IProcessInput Sensor Input Processing ITransformInputData ITransformValidationData Data Transformation IOutput Output Processing control signal Actuator IValidate Data Integrity Checks ^measures Shutdown signal Monitoring channel IMonitor Set Point Source Monitor IMonitor Monitoring Input Processing monitored actuation signal IMonitorActuation Actuator Monitor Sensor Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

32 Parte I: Modellare sistemi software con UML Introduzione: approccio e motivazioni Modellare la struttura Diagrammi di classe Diagrammi degli oggetti Diagrammi dei componenti Diagrammi di deployment Diagrammi delle strutture composte (composite structure) (UML 2.0) Modellare la dinamica Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

33 Diagrammi di deployment Descrive le parti fisiche dell hardware che costituiscono il sistema nella sua implementazione I diversi tipi di hardware (dispositivi) vengono rappresentati mediante nodi Le relazioni tra i dispositivi vengono rappresentate mediante associazioni dette connessioni Esempi di dispositivi: dd Topology «Bus» «Display» «Processor» «Device» «device» USB Cable Monitor Server Robot Printer Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

34 Esempio di diagramma di deployment dd Netw ork «Display» Monitor «Device» WirelessTower «USB cable» «VGA cable» «Processor» Server RCX opcode protocol «wireless channel» Console RoboLib «Device» Robot Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

35 Parte I: Modellare sistemi software con UML Introduzione: approccio e motivazioni Modellare la struttura Diagrammi di classe Diagrammi degli oggetti Diagrammi dei componenti Diagrammi di deployment Diagrammi delle strutture composite (composite structure) (UML 2.0) Modellare la dinamica Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

36 Diagrammi delle strutture composite Descrive le classi, le sue parti (aggregati) e il modo in cui tali elementi sono collegati Le parti sono collegate mediante connettori e porte cd Class Model - composite structure Car Port1 FuelPump Port2 Engine Transmission Port3 Port4 Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

37 Diagrammi delle strutture composite Descrive anche le collaborazioni tra più elementi Utile per evidenziare quali classi collaborano assieme per realizzare una particolare interazione (ad es. implementare un design pattern) cd Class Model - composite structure «component» Shape 2..* Line Circle Rectangle CustomShape 0..* Composite Pattern «leaf» «leaf» «leaf» «composite» Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

38 Parte I: Modellare sistemi software con UML Introduzione: approccio e motivazioni Modellare la struttura Modellare la dinamica Diagrammi di sequenza Diagrammi di stato Diagrammi di attività Diagrammi dei casi d uso Diagrammi delle collaborazioni Timing diagram Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

39 Diagrammi di sequenza I diagrammi di sequenza descrivono le interazioni tra oggetti che collaborano per svolgere un compito Sono utili per evidenziare la distribuzione del controllo nel sistema ( chi fa che cosa ) Gli oggetti collaborano scambiandosi messaggi Lo scambio di un messaggio in OOP equivale all invocazione di un metodo Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

40 Gli oggetti Asse x (asse degli oggetti): Gli oggetti sono disposti orizzontalmente Un oggetto è un istanza di una classe Sintassi: nomeoggetto : NomeClasse Asse t (asse del tempo): Il flusso del tempo è descritto verticalmente sd Diagramma di Sequenza - Gli oggetti an Order Entry Window :Window an Order :Order an Order Line :OrderLine a Stock Item :StockItem Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

41 Scambio di messaggi sincroni 1/2 Si disegna con una freccia chiusa da chiamante a chiamato. La freccia è etichettata col nome del metodo invocato e, opzionalmente, con i suoi parametri e il suo valore di ritorno sd Dynamic Model :Chiamante messaggiosincrono() :Chiamato Il chiamante attende la terminazione del metodo del chiamato prima di proseguire Il life-time (durata, vita) di un metodo è rappresentato da un rettangolino che collega la freccia di invocazione con la freccia di ritorno Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

42 Scambio di messaggi sincroni 2/2 Life-time corrisponde ad avere un record di attivazione di quel metodo sullo stack di attivazione Il ritorno è rappresentato con una freccia tratteggiata Il ritorno è sempre opzionale. Se si omette, la fine del metodo è decretata dalla fine del life-time Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

43 Scambio di messaggi sincroni - un esempio sd Diagrammi di Sequenza - Scambio Messaggi Sincroni an Order Entry Window :Window an Order :Order prepare() oggetto Messaggio asincrono (invocazione di un metodo) messaggio di ritorno (opzionale se void) return done life-line dell'oggetto an Order Entry Window life-time di prepare() Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

44 Scambio di messaggi asincroni 1/2 Si usano per descrivere interazioni concorrenti sd Dynamic Model 2 :Chiamante Si disegna con una freccia aperta da chiamante a chiamato. La freccia è etichettata col nome del metodo invocato e, opzionalmente, con i suoi parametri e il suo valore di ritorno messaggioasincrono :Chiamato Il chiamante non attende la terminazione del metodo del chiamato, ma prosegue subito dopo l invocazione Il ritorno non segue quasi mai la chiamata Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

45 Scambio di messaggi asincroni - un esempio sd Diagramma di Sequenza - Scambio Messaggi Asincroni an Order Entry Window :Window an Order :Order prepare() oggetto Messaggio asincrono (invocazione di un metodo) Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

46 Esecuzione condizionata di un messaggio L esecuzione di un metodo può essere assoggettata ad una condizione. Il metodo viene invocato solo se la condizione risulta verificata a run-time Se la condizione non è verificata, il diagramma non dice cosa succede (a meno che non venga esplicitamente modellato ciascun caso) La condizione si rappresenta sulla freccia di invocazione del metodo, racchiusa tra parentesi quadre Sintassi: [cond] : nomemetodo() Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

47 Messaggi condizionati un esempio sd Diagrammi di Sequenza - Esecuzione Condizionata an Order Line :OrderLine a Stock Item :StockItem hasstock:= check() [hasstock]: remove() Il metodo remove() viene eseguito solo se il metodo check assegna "true" alla variabile hasstock (soddisfa la condizione hasstock=true) Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

48 Messaggi condizionati un esempio (alternativa) sd Diagrammi di Sequenza - Esecuzione Condizionata (Alternativ a) an Order Line :OrderLine a Stock Item :StockItem check() hasstock [hasstock]: remove() Il metodo remove() viene eseguito solo se il metodo check assegna "true" alla variabile hasstock (soddisfa la condizione hasstock=true) Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

49 Messaggi condizionati modellare il caso alternativo sd Diagrammi di Sequenza - Esecuzione Condizionata (Alternativ a) an Order Line :OrderLine a Stock Item :StockItem check() hasstock [hasstock]: remove() Il metodo remove() viene eseguito solo se il metodo check assegna "true" alla variabile hasstock (soddisfa la condizione hasstock=true) [not hasstock]: actionforitemnotinstock() il metodo actionforitemnotinstock() viene eseguito in alternativa al metodo remove(), se la condizione hasstock ha valore false Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

50 Iterazione di un messaggio Rappresenta l esecuzione ciclica di messaggi Si disegna aggiungendo un * (asterisco) prima del metodo su cui si vuole iterare Si può aggiungere la condizione che definisce l iterazione, combinando messaggi condizionati e cicli Sintassi (completa di condizione di iterazione): [cond] : * nomemetodo() Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

51 Iterazione di un messaggio un esempio sd Diagramma di Sequenza - Iterazione di un Messaggio an Order :Order an Order Line :OrderLine [for each oreder line]: *prepare() Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

52 Iterazione di un blocco di messaggi Rappresenta l esecuzione ciclica di più messaggi Si disegna raggruppando con un blocco (riquadro, box) i messaggi (metodi) su cui si vuole iterare Si può aggiungere la condizione che definisce l iterazione sull angolo in alto a sinistra del blocco La condizione si rappresenta al solito tra parentesi quadre Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

53 Iterazione di un blocco di messaggi un esempio sd Diagrammi di Sequenza - Iterazione di più Messaggi :Order :OrderLine loop Prepare&Deliver [for each order line] prepare() done deliver() successful Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

54 Auto-chiamata (self-call) Descrive un oggetto che invoca un proprio metodo Chiamante e chiamato in questo caso coincidono Si rappresenta con una freccia circolare che rimane all interno del life time di uno stesso metodo Viene usata anche per rappresentare la ricorsione Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

55 Auto-chiamata (self-call) un esempio sd Diagrammi di Sequenza - Self-Call an Order Line :OrderLine a Stock Item :StockItem remove() needstoreorder() All'interno del metodo remove(), l'oggetto "a Stock Item" chiama il proprio metodo needstoreorder() Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

56 Costruzione di un nuovo oggetto Rappresenta la costruzione di un nuovo oggetto non presente nel sistema fino a quel momento Corrisponde all allocazione dinamica (allocazione nello heap di sistema, istruzione new) Messaggio etichettato new, create, L oggetto viene collocato nell asse temporale in corrispondenza dell invocazione nel metodo new (o create ) Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

57 Costruzione di un nuovo oggetto un esempio sd Diagramma di Sequenza - Creazione di un Oggetto an Order Line :OrderLine a Stock Item :StockItem remove() done new :DeliveryItem "an Order Line" crea un istanza di DeliveryItem. Prima (o durante) l'esecuzione di remove() l'istanza di DeliveryItem non esisteva! Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

58 Distruzione di un oggetto (preesistente) Rappresenta la distruzione di un oggetto presente nel sistema fino a quel momento Corrisponde alla deallocazione dinamica (deallocazione dallo heap di sistema, istruzione delete/dispose/ ) Si rappresenta con una X posta in corrispondenza della life-line dell oggetto Da quel momento in poi non è legale invocare alcun metodo dell oggetto distrutto Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

59 Distruzione di un oggetto preesistente un esempio sd Diagrammi di sequenza - Eliminazione di un Oggetto an Order Entry Window :Window an Order :Order prepare() done l'oggetto "an Order Entry Window" da qui in poi non è più accessibile L'oggetto "an Order" vive ancora Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

60 Mettiamo tutto insieme un esempio completo Costruiamo un diagramma di sequenza per il seguente scenario [1] Una finestra di tipo Order Entry invia il messaggio prepare ad un Ordine (Order) L ordine invia il messaggio prepare ad ogni sua linea (Order Line) Ogni linea verifica gli elementi in stock (Stock Item) (continua ) [1] UML Distilled 3/E, Martin Fawler, Addson Wesley, 2003 Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

61 Mettiamo tutto insieme un esempio completo ( continua) Se il controllo ha esito positivo, la linea rimuove l appropriata quantità di elementi in stock e crea un unità di delivery (DeliveryItem) Se gli elementi in stock rimanenti scendono al di sotto di una soglia di riordino, viene richiesto un riordino (ReorderItem) Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

62 Mettiamo tutto insieme il diagramma completo sd Diagrammi di Sequenza - La Sintassi an Order Entry Window :Window an Order :Order an Order Line :OrderLine a Stock Item :StockItem prepare() [for each order line]: *prepare() hasstock:= check() [hasstock]: remove() needsreorder:= needstoreorder() [needsreorder]: new :ReorderItem [hasstock]: new :DeliveryItem Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

63 Alcuni suggerimenti finali 1/2 Assicurarsi che i metodi rappresentati nel diagramma siano gli stessi definiti nelle corrispondenti classi (con lo stesso numero e lo stesso tipo di parametri) Documentare ogni assunzione nella dinamica con note o condizioni (ad es. il ritorno di un determinato valore al termine di un metodo, il verificarsi di una condizione all uscita da un loop, ecc.) Mettere un titolo per ogni diagramma (ad es. sd Diagrammi di Sequenza Eliminazione di un Oggetto ) Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

64 Alcuni suggerimenti finali 2/2 Scegliere nomi espressivi per le condizioni e per i valori di ritorno Non inserire troppi dettagli in un unico diagramma (flussi condizionati, condizioni, logica di controllo) Non bisogna rappresentare tutto quello che si rappresenta nel codice Se il diagramma è complesso, scomporlo in più diagrammi semplici (ad es. uno per il ramo if, un altro per il ramo else, ecc.) Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

65 Parte I: Modellare sistemi software con UML Introduzione: approccio e motivazioni Modellare la struttura Modellare la dinamica Diagrammi di sequenza Diagrammi di stato (statechart) Diagrammi di attività Diagrammi dei casi d uso Diagrammi delle collaborazioni Timing diagram Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

66 Diagrammi di stato - Definizioni Un diagramma di stato rappresenta il ciclo di vita degli oggetti di una classe Il ciclo di vita è descritto in termini di Eventi Stati Transizioni di stato Gli eventi possono attivare delle transizioni di stato Un evento in uno statechart corrisponde ad un messaggio in un sequence diagram Uno stato è costituito da un insieme di valori significativi assunti dagli attributi dell oggetto che ne influenzano il comportamento Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

67 Diagrammi di stato Stati iniziale e finale Esistono due stati speciali, detti pseudostati: Lo stato iniziale Lo stato finale Un oggetto può non avere uno stato finale! (non viene mai distrutto) sm Initial and final states rappresentazione grafica (minimale) di uno stato State1 Enabled remove stato finale stato iniziale Allocated Disabled Removed remove Initial trigger: un evento che attiva la transizione (può essere un veneto esterno o una chiamata di metodo) Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

68 Diagrammi di stato Modellare gli eventi Un evento può essere: L invocazione sincrona di un metodo (una call ) La ricezione di una chiamata asincrona ( signal ) ad esempio la notifica di un eccezione lanciata Una condizione predefinita che diventa vera (si parla in questo caso di change event ) La fine di un periodo di tempo come quello impostato da un timer ( elapsed-time event ) Un evento si può rappresentare graficamente con una freccia (transizione) etichettata con il nome del metodo o della condizione associata all evento stesso sm events Allocated enable() Enabled Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

69 Diagrammi di stato Modellare gli eventi Un evento può essere rappresentato anche mediante un espressione testuale avente la seguente sintassi: event-name ( [comma-separated-parameter-list] ) [ [ guard-condition ] ] / [action-expression] dove: event-name identifica l evento parameter-list definisce i valori dei dati che possono essere passati come parametro con l evento guard-condition determina se l oggetto che riceve l evento deve rispondere ad esso (ossia eseguire il metodo associato) action-expression definisce come l oggetto ricevente deve rispondere all evento Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

70 Diagrammi di stato Esempi Event + state = response sm events Off Lo stesso evento causa diversi comportamenti in base allo stato in cui l oggetto che riceve l evento si trova Click() On Click() Elapsed-time Events sm events Sold after(3 days) Unsold predefined event "after" Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

71 Diagrammi di stato Esempi Change event sm events ActiveRegularCustomer when (30 days past due) Delinquent when (purchases > $1000 in past 6 years) ActivePreferredCustomer when (60 days past due) predefined event "when" Guarded event sm events TentativeOrder receivepaymnt() [amount=totalprice] PlacedOrder Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

72 Diagrammi di stato Entry/Exit Actions Entry/exit action: azione che viene eseguita per ogni evento che causa una transizione entrante/uscente nello/dallo stato entry action: azione che viene eseguita in una transizione entrante nello stato exit action: azione che viene eseguita in una transizione uscente dallo stato PlacedOrder issueconf() issuecustomerstatement() sm events Final receivepaymnt() /issueconf() order is filled /issuecustomerstatement() FilledOrder TentativeOrder PlacedOrder Initial authorizeoverride() /issueconf() cancel /issuecustomerstatement() CancelledOrder Final Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

73 Diagrammi di stato Modellare attività All interno degli stati posso essere eseguite delle attività Negli statechart distinguiamo tra Azioni: operazioni atomiche Attività: operazioni generalmente non atomiche Le azioni provocano un cambiamento di stato (entry/exit) e quindi non possono essere interrotte Le attività non alterano lo stato dell oggetto Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

74 Diagrammi di stato Ordine di esecuzione degli eventi Quando si verifica un evento associato ad una transizione, l ordine di esecuzione è il seguente: 1. Se è in esecuzione un attività, questa viene interrotta ( gracefully se possibile) 2. Si esegue l exit action 3. Si esegue l azione associata all evento 4. Si esegue l entry action del nuovo stato 5. Si inizia l esecuzione delle eventuali attività del nuovo stato Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

75 Relazione tra diagrammi di stato e diagrammi di sequenza 1/4 Due scenari (sequence diagram): successo e fallimento di una transazione (Successo) (Fallimento) sd Dynamic model 3 - transaction success sd Dynamic model 3 - transaction failure :Customer :ShowSeat :Customer :ShowSeat select() select() purchase() cancel() Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

76 Relazione tra diagrammi di stato e diagrammi di sequenza 2/4 Scenario di successo e relativo (parziale) diagramma a stati (Successo) sd Dynamic model 3 - transaction success (diagramma a stati parziale) sm ev ents2 Priced - Not Selected - Not Sold :Customer :ShowSeat se l e ct select() Priced - Selected - Not Sold purchase() purchase P ric e d - Not Selected - Sold Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

77 Relazione tra diagrammi di stato e diagrammi di sequenza 3/4 Scenario di fallimento e relativo (parziale) diagramma a stati (Fallimento) sd Dynamic model 3 - transaction failure (diagramma a stati parziale) sm ev ents3 P ric e d - N o t S e le c te d - Not S old :Customer :ShowSeat select select() P ric e d - S e le c te d - Not Sold cancel() cancel P ric e d - N o t S e le c te d - Not S old Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

78 Relazione tra diagrammi di stato e diagrammi di sequenza 4/4 Il diagramma a stati completo (relativo ai due scenari discussi) sm events Priced - Selected - Not Sold select cancel() Priced - Not Selected - Not Sold purchase Priced - Not Selected - Sold Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

79 Diagrammi di stato compositi 1/2 Uno stato può contenere al suo interno più sottostati mutuamente esclusivi sm MovingForward sm events3 Moving in 1st gear MovingForward Initial upshift downshift Moving in 2nd gear Indica stato composito sotto-stati mutuamente esclusivi upshift downshift Moving in 3rd gear Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

80 Diagrammi di stato compositi 2/2 Uno stato può contenere al suo interno sottostati concorrenti sm events3 sm events3 FinalizingSale FinalizingSale [printing] printing concurrent region Initial Printing Ticket Final reserving concurrent region [reserving] Initial ReservingShowSeat Final Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

81 Parte I: Modellare sistemi software con UML Introduzione: approccio e motivazioni Modellare la struttura Modellare la dinamica Diagrammi di sequenza Diagrammi di stato (statechart) Diagrammi di attività Diagrammi dei casi d uso Diagrammi delle collaborazioni Timing diagram Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

82 Diagrammi di attività Un diagramma di attività mostra il flusso di azioni relativo ad un attività Un attività è un esecuzione non atomica di operazioni all interno di una macchina a stati L esecuzione di un attività viene decomposta in azioni atomiche Ogni azione può o meno cambiare lo stato del sistema I diagrammi di attività sono spesso usati per descrivere la logica di un algoritmo (sono l equivalente UML dei diagrammi di flusso) Graficamente un diagramma di attività è un insieme di archi e nodi Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

83 Diagramma di attività azioni e nodi attività ad Activity Model Azioni (atomiche) Valutazione di espressioni Assegnamenti / Ritorno di un valore Invocazione di un operazione su un oggetto Creazione/distruzione di un oggetto azione index:= lookup(e) + 7 nodo attività DoConstruction() CompositeActivity Attività composita Nodi Attività Raggruppamento di azioni atomiche o di altri nodi attività Un azione può essere vista come un attività che non può essere ulteriormente decomposta Espandendo un nodo attività si ottiene un altro diagramma di attività (attività composita) A parte questa differenza, i due concetti sono rappresentati mediante lo stesso simbolo grafico Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

84 Diagramma di attività Flusso di controllo Quando un azione o un attività viene completata, il flusso di controllo passa al nodo azione (attività) immediatamente successivo ad Activity Model Initialization Select site Il flusso di controllo viene specificato mediante frecce che collegano due nodi (attività o azione) Commission architect Il flusso mostrato in figura è quello più semplice: il flusso sequenziale completion Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

85 Diagramma di attività Branch e merge Un altro tipo di flusso possibile è il branch Un branch è rappresentanto da un diamante Ogni branch ha: Un flusso entrante Due o più flussi uscenti Una condizione logica (talvolta implicita) che determina quale dei flussi uscenti verrà eseguito da una particolare esecuzione Quando due flussi si riuniscono, è possibile usare ancora il simbolo di diamante; in questo caso viene detto merge Ogni merge ha almeno due flussi entranti e un flusso uscente Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

86 Diagramma di attività Branch e merge ad Activ ity M odel Release w ork order branch Reschedule [m aterials not ready] guard expression [materials ready] Assign tasks merge Get next order Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

87 Diagramma di attività Fork e Join Alcuni flussi possono essere concorrenti In UML vengono usate delle barre di sincronizzazione per specificare fork e join di flussi di controllo paralleli Un join rappresenta la sincronizzazione di due o più flussi di controllo concorrenti Un join ha due o più flussi entranti e un flusso uscente LA sincronizzazione sul join attende che tutte le attività nei flussi entranti abbiamo terminato la loro esecuzione, prima di procedere Join e fork si devono bilanciare Le attività in un flusso di controllo parallelo comunicano tra loro spedendosi segnali (stile di comunicazione detto coroutine) Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

88 Diagramma di attività Fork e Join ad Activ ity Model Prepare for speech fork Gesture Decompress Synch mouth Stream audio Cleanup join Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

89 Diagramma di attività Swimlane A volte è utile partizionare le attività in base alle entità coinvolte che le devono svolgere In UML si usano a tale scopo le cosiddette swimlane Una swimlane è un raggruppamento (verticale oppure orizzontale) di attività eseguite da una stessa entità (ad esempio, una classe) Ogni swimlane deve avere un nome univoco nel diagramma Le swimlane rappresentano responsabilità specifiche nel contesto di un attività generale Le attività sono associate univacamente ad un unica swimlane Solo le transizioni (flussi) possono attraversare due o più swimlane Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

90 Diagramma di attività Swimlanes a d Ac tiv ity M ode l Customer Sales Wharehouse sta rt Request product Process order Pull materials Ship order Receive order Bill customer Pay bill Close order Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

91 Diagramma di attività Flusso di oggetti A volte è utile evidenziare non solo il flusso di controllo, ma anche gli oggetti coinvolti Un attività può creare un oggetto Un altra attività può contenere azioni che modificano lo stato interno di un oggetto Il flusso del valore (stato) di un oggetto tra due azioni è detto flusso dell oggetto Lo stato viene rappresentato tra parentesi quadre all interno dell oggetto, oppure come constraint in una nota associata all oggetto stesso Parte I - Modellare sistemi software con UML - Andrea Baruzzo,

92 Diagramma di attività Flusso di oggetti ad Activ ity M odel Customer Sales Wharehouse start Request product {in progress} Process order o :Order Pull materials Ship order o :Order Bill customer {filled} Receive order Pay bill Close order Parte I - Modellare sistemi software con UML - Andrea Baruzzo, end