Ingegneria del software versione 1.0.5

Transcript

1 Ingegneria del software versione Appunti 19 luglio 2006 Indice 1 Ciclo di vita del software Processo di sviluppo del software Modelli Agile Dierenze con altri modelli Quando usarlo Iterativo - Incrementale RAD Vantaggi Svantaggi Extreme Programming Planning Game Small Relesases Customers on-site Test First Refactoring Simplicity System Metaphor Pair Programming Collective Code Ownership Continous Integration Standards Overtime: 40 hour week JUnit RUP RUP best practices Ciclo di vita del Progetto Il modello a Cascata - WaterFall Il modello a Spirale Il modello a Release UXF 13 3 Metriche codice sorgente LOC eloc lloc DLOC SLOC Vantaggi Svantaggi UMM 15 5 XMI 15 6 COTS 16 7 SCM Goal FPA 17 9 COCOMO Basic COCOMO COCOMO II CORBA DFD Linguaggio Z Esempio - Denizione sistema Esempio - Add

2 2 Indice 14 Diagrammi UML Diagramma casi d'uso Diagramma delle classi Diagramma delle sequenze Diagramma delle collaborazioni Diagramma di stato Diagramma delle attività Diagramma dei componenti Diagramma di distribuzione dei componenti (deployment) 24 Bibliograa 25

3 1 Ciclo di vita del software 3 1 Ciclo di vita del software L'espressione ciclo di vita del software si riferisce al modo in cui una metodologia di sviluppo o un modello di processo scompongono l'attività di realizzazione di prodotti software in sottoattività fra loro coordinate, il cui risultato nale è il prodotto stesso e tutta la documentazione a esso associato[1]. Esistono varie fasi: 1. Analisi: ovvero l'indagine preliminare sul contesto in cui il prodotto software deve inserirsi, sulle caratteristiche che deve esibire, ed eventualmente su costi e aspetti logistici della sua realizzazione; questa fase può essere scomposta in sottoattività quali: (a) analisi di fattibilità, (b) analisi e modellazione del dominio applicativo, (c) analisi dei requisiti. 2. Progetto: in cui si deniscono le linee essenziali della struttura del sistema da realizzare, in funzione dei requisiti evidenziati dall'analisi e dal documento nale da essa creato. Anche questa fase può essere scomposta in sottoattività: (a) progetto architetturale, (b) al progetto dettagliato. In questa fase verrà sviluppando un documento che permetterà di avere una denizione della struttura di massima (architettura di alto livello) e una denizione delle caratteristiche dei singoli componenti (moduli) 3. Implementazione 4. Testing (a) testing dei singoli moduli, (b) testing del sistema integrato, (c) test funzionali, (d) test di performance, (e) test di accettazione, (f) test d'installazione. 5. Manutenzione

4 4 1 Ciclo di vita del software 1.1 Processo di sviluppo del software L'UML (Unied Modelling Language), ad esempio, è un linguaggio di modellazione, utilizzato dai processi per realizzare, organizzare, documentare i prodotti realizzati dalle fasi di cui il processo si compone. Coloro che, individualmente o in gruppo, lavorano allo sviluppo o alla modica di un software, adottano necessariamente un certo approccio nel modo di relazionarsi con i propri clienti/utenti, nell'organizzare il proprio lavoro, nella scelta delle tecniche da utilizzare. Adottano un processo [1]. Il ciclo di sviluppo del software, nella maggior parte dei casi, è iterativo, e ogni iterazione produce una sua release. Elenchiamo di seguito le fasi principali che possono far parte di ogni singola iterazione: 1. Specica dei requisiti: ciò che viene richiesto dal committente 2. Analisi e Design dove per analisi si intende lo studio di cosa deve fare il sistema (punto di vista logico) e per design lo studio di come il sistema deve venire implementato (punto di vista tecnico). Negli ultimi anni, la distinzione tradizionale tra analisi e design è entrata in crisi. 3. Implementazione 4. Integrazione e test 1.2 Modelli Esistono molti modelli per lo sviluppo del software: iterativo ( ), Waterfall (a cascata) (1970), RAD ( ), spirale (1985), RUP (1998), Extreme Programming (XP) (1999). Agile (2001),

5 1 Ciclo di vita del software Agile Agile è una metodologia di sviluppo del software, un framework. Ci sono più tipi di agile software per sviluppare questo metodo, questi possono essere trovati nell'organizzazione no-prot The Agile Alliance. Questo metodo tenta di minimizzare i rischi dello sviluppo con piccole timeboxes, chiamate iterazioni, da una a quattro settimane. Ogni iterazione include delle fasi: planning, requirements analysis, design, coding, testing e documentation. Mentre una iterazione non garantisce il rilascio di un prodotto, l'agile software project, si propone di riuscire a rilasciare un nuovo software ad ogni iterazione. Alla ne di ogni iterazione, il tema ssa le priorità del progetto Dierenze con altri modelli <Agile> <Iterative> <Waterfall> <-*-**> Adaptive...Predictive Adaptive methods: si concentra sull'adattarsi velocemente ai cambiamenti. Predictive methods: si concentra sulla pianicazione dettagliata e futura del progetto Quando usarlo Più di 20 sviluppatori, distanza tra glil sviluppatori, mission- and life-critical eorts, command-and-control company cultures. 1.4 Iterativo - Incrementale Il modello iterativo, e incrementale, risponde alle debolezze dei modelli watefall. I due modelli di sviluppo iterativo più conosciuti sono RUP (Rational Unied Process), e DSDM (Dynamic Systems Development Method). Questo modello è una parte essenziale dell'xp (Extreme Programming) e tutti gli altri agile software frameworks.

6 6 1 Ciclo di vita del software 1.5 RAD (Rapid Application Development) RAD nato come risposta al metodologia non-agile, come il modello waterfall. Il problema con i precedenti modelli era quello che i requisiti cambiassero prima della conclusione del progetto, con il risultato di creare sistemi non utilizzabili Vantaggi Svantaggi accresce la velocità e qualità di sviluppo Questa velocità è dovuta all'uso di tool quali CASE 1 Per qualità nel modello RAD si intende il grado con il quale l'applicazione nita si riscontra con le aspettative del cliente, ed i costi di manutenzione bassi. Come svantaggi, riduce la scalabilità e le features. La scalabilità è ridotta perché questo modello parte da un prototipo e si evolve no alla applicazione nita; mentre riduce le features questo è dovuto al time boxing, le features vengono inserite tardi nelle versioni nali della release. 1.6 Extreme Programming L'extreme programming XP, è un modo di programmare che segue determinate regole, per cercare di ottimizzare il più possibile lavoro fatto dai programmatori [2]. Alcune di queste regole sono di seguito riportate: 1. Planning Game 2. Small Releases (Piccole release) 3. Customers on-site (Cliente sul posto) 4. Test First 5. Refactorig 6. Simplicity 7. System Metaphor 8. Pair Programming 9. Collective Code Ownership 10. Continous Integration 11. Code Standards 12. Overtime: 40 hour week L'obiettivo di questo tool è quello di catturare i requisiti e descriverli come codice nel modo più veloce possibile.

7 1 Ciclo di vita del software Planning Game Come Pianicare: Creare delle priorità (con il cliente) Stimare la dicoltà dei lavori (Lo sviluppatore) Lavorare in task paralleli, si è più veloci (Lo sviluppatore) Pianicare insieme i lavori ed i vari task all'inizio (Sviluppatore-Cliente) Small Relesases Signica piccole release frequenti, in genere prima dell'xp, si faceva il software per intero e poi si dava al committente validato; mentre ora si cerca di dare subito qualcosa al cliente, in modo che capisca subito se il software è corretto secondo le sue speciche; questo evita di fare lavoro inutile. In genere per il cliente viene sviluppato subito il 10% del programma in modo tale che sia veloce il riscontro in caso di problemi. Questa tecnica, evita la nascita e la morte poi di determinati software, con la perdita quindi di tempo e denaro, inoltre fa subito vedere se ci sono errori 2 o difetti 3 nei software prodotti Customers on-site Il committente deve essere tenuto sempre in stretto contatto con gli sviluppatori. In genere succede che dopo aver ottenuto l'ordine di progettare un software, il programmatore ed il cliente non si sentono quasi più no a software terminato: questo non deve succedere. Con l'xp, lo sviluppatore chiede subito al committente cosa sono le sue priorità, i moduli che devono essere sviluppati prima, e come devono essere sviluppati. Coinvolgere il cliente nei test per sapere se il software per lui è corretto, mostrare se il programma per lui è user-friendly Test First In genere i test vengono eseguiti dopo lo sviluppo della applicazione. Mentre in XP, il development è guidato dai test, questa può sembrare una perdita di 2 Per errore si intende una dimenticanza del programmatore Es.: un errore di battitura... 3 Per difetto si intende un problema nei risultati ottenuti dal software, risultati inattesi. (Altrimenti detto bug, Fault.)

8 8 1 Ciclo di vita del software tempo ma poi alla ne: si ha si, una perdita di tempo iniziale, ma si recupera sulla ne del progetto; mentre con l'approccio tradizionale si ha una velocità maggiore all'inizio per poi decelerare alla ne nella fase di Testing Refactoring Con questo termine, si intende modicare il codice, modicarne la struttura, il usso di controllo ma non il risultato. Ad esempio rinominare un metodo, aggiungere metodi a delle classi(ma senza cambiare il risultato del modulo). Il refactoring serve in generale per migliorare la qualità del codice. Divisione di un grande metodo in più parti Simplicity Cercare di tenere il progetto più semplice possibile System Metaphor Usare metafore vicine al dominio del committente. Se il cliente è un produttore di automobili, cercare di parlare dello sviluppo del software in termini di produzione di automobili, questo è una forma per cercare di capire nel miglior cosa deve fare il software prodotto Pair Programming Con il termine pair programming si intende, la programmazione in gruppo, per esempio in due, questa viene richiesta quando il compito è particolarmente dicile; su lavori critici si lavora insieme Collective Code Ownership Il codice scritto è di tutti gli sviluppatori; se si trova un errore nel programma la colpa è dell'intero team. Bisogna dire che essendo il codice di tutti, chi vuole può fare tutte le modiche, se secondo lui un modulo non è corretto lo può modicare, a patto che usi i CVS (Concurrent Version System,controllo di versione); inoltre al termine della modica il modulo modicato devo dare lo stesso risultato nei test del modulo vecchio; in altre parole non devo alterare i risultati che il modulo vecchio dava. Se non è così, allora in quel caso, la colpa è del programmatore che ha svolto la modica, il quale non si è preoccupato di vedere se i test erano ancora corretti; in conclusione, più libertà ma anche più responsabilità.

9 1 Ciclo di vita del software Continous Integration In genere il test di integrità viene fatto alla ne dello sviluppo dei singoli moduli con una frequenza molto alta di errori. L'XP dice che questo test deve essere fatto in modo più frequente proprio per evitare problemi di integrazione alla ne del progetto, molto più dicili da trovare e sistemare Standards Cercare di scrivere codice il più possibile in modo standard: es in java, i nomi delle classi iniziano con la lettera maiuscola, mentre per i nomi dei metodi si usano dei verbi Overtime: 40 hour week Per uno sviluppatore, le ore di straordinario, (overtime), sono permesse solo per una settimana, altrimenti c'è il rischio di commettere errori, mentre l'orario lavorativo normale non deve superare le 40 ore settimanali JUnit E' uno strumento che serve per eseguire Test di unità in Java. Utilizza la libreria Java riessione (per gestire le classi). Terminologia: Unit Test: una classe che testa un'altra classe Caso di Test: chiama un metodo con un input particolare e si osserva se il risultato è corretto Test Suite: una serie di casi di test Test Runner: serve per far partire i test Junit, introduce una nuova classe: nomeclassetest. Inoltre introduce due classi con nomi ssi: setup: inizializza la classe per eseguire i test teardown: libera la classe Junit utilizza le asserzioni per produrre il risultato dei test e vedere se sono corretti. Esempio in Java1:

10 10 1 Ciclo di vita del software 1 public class ES { 3 int mcd ( int x, int y) { 5... } 7 } 9 /* C r e o un ' a l t r a c l a s s e */ 11 public class ES TEST { 13 void testmcd () { 15 mcd (10,2) ; // Mi a s p e t t o c h e r e s t i t u i s c a 2 } 17 asserttrue ( mcd (10,2) ==2) ; asserttrue ( mcd (6,12) ==6) ; 19 } 21 /* * * * T i p i di A s s e r z i o n i * * * */ 23 static void asserttrue ( boolean test ) static void asserttrue ( String message, boolean test ) 25 static void assertfalse ( boolean test ) 27 static void assertfalse ( String message, boolean test ) 29 static void assertequals ( expected, actual ) static void assertequals ( String message, expected, actual ) Codice 1: Esempio in pseudolinguaggio Java Limiti e problemi del Testing con JUnit È una buona idea scrivere metodi che controllano lo stato di un oggetto Non è facile testare il codice delle GUI Con questo metodo si controlla l'output ma ha volte non è facile scrivere codice per questo controllo Non è facile testare svariati metodi che lavorano in parallelo per dare un risultato

11 1 Ciclo di vita del software 11 Sono comunque state proposte possibili soluzioni 1.7 RUP RUP (Rational Unied Process) è un software molto noto di sviluppo iterativo. RUP deve essere visto non come attraverso una singola prospettiva di lavoro, ma piuttosto un framework operativo adattabile alle esigenze RUP best practices 1. Sviluppo del software in modo iterativo, 2. gestione dei requisiti, 3. verica della qualità del codice, 4. CVS controllo dei cambiamenti apportati al software. RUP usa il modello iterativo per le seguenti ragioni: Il processo di integrazione viene fatto passo dopo passo durante lo sviluppo del software, limitandosi a farlo per pochi elementi alla volta, l'implementazione viene fatta per moduli, facilitando il riuso del software, se i requisiti cambiano è possibile adattarsi, l'architettura del software viene migliorata ad ogni release Ciclo di vita del Progetto È formato da quattro fasi vedi Figura 1 a Pagina 12: 1. Inception Phase (a) Stakeholder denizione, stima dei costi, tempi, (b) comprensione dei requisiti, (c) priorità costi/tempi, rischio, sviluppo del processo, (d) studio del prototipo architetturale che si è studiato, (e) spese attuali vs spese pianicate. 2. Elaboration Phase

12 12 1 Ciclo di vita del software (a) Generazione casi d'uso i casi d'uso completati all'80% (b) descrizione dell'architettura software, (c) piano di sviluppo per coprire tutto il progetto. 3. Construction Phase, 4. Transition Phase. Figura 1: Ciclo di vita del progetto Il modello a Cascata - WaterFall Figura 2: Modello WaterFall L'output di ogni fase è l'input della successiva; il principale limite di questo modello, è il fatto di non poter tornare indietro; se c'è un problema nel software che viene scoperto tardi bisogna ricominciare Il modello a Spirale In questo modello vedi Figura 3 a pagina 13, si crea un prototipo, attraverso le varie fasi: analisi dei requisiti, specica... e poi si fa l'analisi dei rischi

13 2 UXF 13 Figura 3: Modello a Spirale anche con il cliente per vedere se si può proseguire. Il principale vantaggio dei modelli a spirale e Release e che il software è in continua evoluzione [3] Il modello a Release In questo modello, si crea una prima release da sottoporre al cliente per ottenere un primo feedback; per poi correggerla o svilupparla ancora. Alla ne di tutte le release si ottiene il prodotto nale. 2 UXF UXF (UML exchange Format) è un modello di interscambio di formati per UML(Unied Modeling Language) basato su XML. Permette una alta inter operabilità; il team che sviluppa codice tramite questo modello, può riutilizzare e scambiare le informazioni tramite lo standard XML. XML è un sosticato sottoinsieme dell'sgml (Standard Generalized Markup Language: ISO 8879) i principali vantaggi sono: Indipendenza dal vendor (vender independence), Estensibilità, Possibilità di rappresentare delle informazioni complesse,

14 14 3 Metriche codice sorgente Leggibilità umana (Human readability), Interoperabilità tra i tools di sviluppo. 3 Metriche codice sorgente 3.1 LOC Line of code (LOC). LOC sono usate per stimare i tempi ed i costi. 3.2 eloc Eective line of code (ELOC), è la misura di tutte le line di codice che non sono commenti, spazi bianchi, e parentesi. Questa metrica rappresenta la quantità del lavoro. 3.3 lloc Logical lines of code (ILOC) rappresenta una metrica per gli statements; es.: for. Esempio: Source code line LOC eloc lloc Comment Blank if (x<10) // test range x x x { x // update y coordinate x x y = x + 1; x x x } x DLOC Developed line of code (DLOC). Include tutto il programma ed gli statement. Esiste anche il Kilo line of code (KLOC). 3.5 SLOC SLOC (Source lines of code) è una metrica usata per misurare il codice di un certo programma. SLOC viene usato per stimare lo sforzo richiesto per sviluppare un certo software.

15 5 XMI Vantaggi Automatizzare il conteggi delle linee di codice tramite tools Una metrica intuitiva: le righe di un software possono essere visionate Svantaggi 1. Non si può quanticare il costo, di un software contando le linee di codice, in altre parole contando solo la fase di codica la quale occupa solo il 33% - 35% di tutti il processo, 2. non ci permette di catturare questa diversità: un programmatore può scrivere poche righe di codice ma molto signicative, mentre un secondo programmatore ne scrive molte ma meno signicative e con più errori, 3. linguaggi dierenti, 4. GUI, tramite queste interfacce, il programmatore può fare copia ed incolla del codice già scritto in precedenza. 4 UMM UMM (UN/CEFACT's 4 Modeling Methodology), è una metodologia di modellazione la quale si sviluppa tramite UN/CEFACT. 5 XMI XMI (XML Metadata Interchange) è uno standard OMG per lo scambio di metadati tramite il linguaggio XML. Può essere usato per qualsiasi metadato purché questo possa essere espresso tramite MOF (Meta-Object Facility). L'uso più comune di XMI è per l'interscambio di modelli UML, i quali possono essere usati anche per altri linguaggi. XML - extensible Markup Language, W3C standard. UML - Unied Modeling Language, OMG modeling standard. 4 (The United Nations Centre for Trade facilitation and Electronic Business) UN/CE- FACT ha come scopo migliorare il business, e l'organizzazione amministrativa, sviluppo e transazioni economiche, scambio di prodotti e servizi; contribuisce allo sviluppo del commercio globale.

16 16 7 SCM MOF - Meta Object Facility, OMG DSL per la specica di metamodelli. MOF Mapping a XMI 6 COTS (Commercial o-the-shelf); COTS è un termine applicato nell'ambito sia dei prodotti software che hardware, il quale dice quando questo prodotto è pronto e disponibile alla vendita al pubblico. GOTS: government o-the-shelf, MOTS: modiable o-the-shelf, oppure military o-the-shelf. La motivazione che spinge ad utilizzare dei componenti COTS, è che riduce il tempo ed i costi di sviluppo del software; perché i componenti possono comprati e non progettati da zero. A volte tuttavia i costi di integrazione e la dipendenza da terze parti possono accrescere i costi. 7 SCM SCM (Software Conguration Management) è una parte del CM (Conguration Management). Risponde a queste domande: 1. Qualcuno fa qualcosa, come possiamo riprodurla? Spesso il problema si evolve e non è possibile riprodurlo in modo identico, ma servono dei cambiamenti incrementali. Tradizionalmente CM si è concentrato sul controllo e la creazione di prodotti semplici. Ai nostri giorni, la sda è quella fare il minor numero di incrementi; valutando la complessità del sistema che si sta sviluppando. 7.1 Goal Conguration Identication- Con quale codice noi lavoriamo? Conguration Control- Controllo delle release e eventuali cambiamenti. Status Accounting- Registrazione e report dei componenti.

17 8 FPA 17 Review- Assicurarsi della completezza dei vari componenti. Build Management- Gestione dei processi e dei tool utilizzati nel progetto FPA FPA (Function Point Analysis) è un metodo che misura la dimensione funzionale di un sistema informativo. Questo viene fatto osservando le transazioni funzionali e logiche del les rilevanti per gli utenti nel loro business [5]. Necessità di alcuni passi: 1. Identicare le funzioni del sistema che sono rilevanti per gli utenti 2. Determinare la complessità di ogni funzione 3. Contare le funzioni di tipo di dati per determinare il loro contributi al numero dei function point non pesati 4. Contare le funzioni di tipo transazionale per determinare il loro contributi al numero dei function point non pesati 5. Determinare il fattore di aggiustamento del valore 6. Calcolare il numero di function point pesati. Step 1 - FPA distingue tra cinque tipi di funzioni utente: 1. Internal Logical File (ILF) 2. External Interface File (EIF) 3. External Input (EI) 4. External Output (EO) 5. External Inquiry (EQ) Step 2 - FPA distingue tra tre tipi di complessità: 1. Low 2. Average 3. High

18 18 9 COCOMO 9 COCOMO COCOMO (COnstructive COst MOdel) è un modello progettato da Barry Boehm, per dare una stima del numero di uomini-mese che prenderanno parte allo sviluppo di un software. COCOMO consiste in una gerarchia di tre crescenti livelli di dettaglio: 1. Basic COCOMO: è statico, sforzo e costo dello sviluppo di un software come funzione della dimensione di un programma espressa nella sua stima delle linee di codice. 2. Intermediate COCOMO: sforzo come funzione della dimensione del programma e i cost drivers che includono subjective assessment of product, hardware, personale e project attributes. 3. Detailed COCOMO: incorpora tutte le caratteristiche della versione intermedia con un impatto dei cost driver ad ogni passo (analisi, progetto, codica... ), del processo di produzione del software. 9.1 Basic COCOMO Può essere applicato a tre tipologie di progetto: 1. Organic projects: sono relativamente piccoli, semplici progetti, 2. Semi-detached projects: sono una via di mezzo in termini di dimensione e complessità, 3. Embedded projects: sono progetti che devono essere sviluppati con hardware, software. L'equazione del basic COCOMO: E = a b (KLOC) b b D = c b (E) d b P = E/D dove E è lo sforzo (persone-mese), D è il tempo di sviluppo in un mese, KLOC è la stima del numero di line di codice per i progetto (espresse in migliaia), P è il numero di persone richieste. I coecienti a b, b b, c b, d b sono dati Tabella 1 a Pagina 19.

19 10 COCOMO II COCOMO II Software Project a b b b c b d b Organic Semi-detached Embedded Tabella 1: Coecienti Basic COCOMO Nel COCOMO II vengono apportate modiche al COCOMO I. Vengono deniti tre livelli di COCOMO, che corrispondono a tre classi di applicazioni e utilizzano informazioni reperibili in tre diversi momenti del ciclo di vita: 1. Application Composition: è il settore di chi utilizza primitive di alto livello per programmare (ad esempio GUI, spreadsheet) o si riferisce alla fase in cui viene generalmente eettuata una prototipazione per risolvere problemi ad alto rischio (interfacce utente, interazione software/sistema, prestazioni, maturità della tecnologia); vengono utilizzati gli Object Points, in quanto si ritiene che siano disponibili in maniera adabile in questa fase 2. Early Design: si passa alla fase di progetto, con l'esplorazione di alternative per le architetture; vengono usati i Function Points, il linguaggio e alcuni driver di costo in numero limitato, poiché in questa fase non è ancora noto molto a riguardo del progetto 3. Post-Architecture: si giunge alla fase di sviluppo tradizionale; si ottiene la stessa precisione di COCOMO 1; vengono usati LOC, Function Points e linguaggio con 17 cost drivers e 5 fattori di scala, che sostituiscono i fattori del modello precedente e i modelli Organic, Semidetachede Embedded Inoltre, il modello COCOMO II utilizza modelli non lineari per riuso e reingegnerizzazione permette il trattamento delle economie di scala apporta modiche ai moltiplicatori originari si avvale di un modello Bayesiano per i parametri del modello valutati da esperti

20 20 13 Linguaggio Z 11 CORBA L'OMG (Object Management Group), decise di promuovere il CORBA (Common Object Request Broker Architecture) una architettura distribuita orientata algi oggetti. Usando CORBA, un client può in modo trasparente (es.: senza conoscere l'implementazione del server in dettaglio) invocare un metodo su un server in due modi: in modo statico oppure tramite una invocazione dinamica. 12 DFD Un DFD (data ow diagram) è una rappresentazione graca di un usso di dati attraverso un sistema. Un diagramma di usso può essere utilizzato per visualizzare il data processing. 13 Linguaggio Z È un linguaggio per la specica formale, il quale usa la notazione matematica per descrivere in un modo preciso le proprietà e le informazioni che un sistema deve avere, senza conoscere in che modo queste proprietà vengono archiviate [7]; descrive che cosa il sistema deve fare senza sapere come [4]. Una importante caratteristica del linguaggio Z è quella di decomporre la specica in piccole parti chiamati schemas. Gli schema sono usati per descrivere aspetti statici e dinamici. Gli aspetti statici includono: lo stato che può essere occupato, le relazioni tra invarianti che sono mantenute quando un sistema si muove da uno stato all'altro. Gli aspetti dinamici includono: le operazioni possibili, le relazioni tra i loro input e output, i cambiamenti di stato.

21 13 Linguaggio Z Esempio - Denizione sistema Denire formalmente tramite il linguaggio Z un software che gestisce il nome e la data di compleanno di un database di persone. BirthdayBook known: P NAME birthday: NAME DATE known: dom Birthday known è il set dei record nomi con il compleanno birthday è la funzione la quale applicata ad un nome restituisce il compleanno L'ultima riga, è l'invariante in quanto è una relazione vera in ogni stato del sistema. Un possibile stato del sistema è dato da: known = { Primo, Michele, Claudia } birthday = { Primo 25Mar, Michele 20Dec, Claudia 20Dec }. L'invariate è rispettato in quanto il dominio dei birthday record è esattamente uguale a quello di known cioè Esempio - Add Aggiungiamo al sistema la possibilità di inserire nuovi dati. Lo schema è AddBirthday. AddBirthday BirthdayBook name?: NAME date?: DATE name? / known Birthday' =Birthday {name? date? } known è il set dei record nomi con il compleanno birthday è la funzione la quale applicata ad un nome restituisce il compleanno

22 22 14 Diagrammi UML 14 Diagrammi UML UML è un linguaggio di progettazione; UML è una evoluzione di modelli già esistenti, forti anità con ER (Entity - Relationship), FC (Flow Chart), modelli object oriented. Diagrammi UML: Livello logico: diagramma dei casi d'uso (use case) diagramma delle classi (class) diagramma di sequenza (sequence) diagramma di collaborazione (collaboration) diagramma di transizione di stato (state) diagramma delle attività (activity) Livello sico: diagramma dei componenti (component) diagramma di distribuzione dei componenti (deployment) 14.1 Diagramma casi d'uso Questi descrivono l'interazione tra attori e sistema, non la logica interna della funzione; sono infatti espressi in forma testuale, comprensibile anche per i non addetti ai lavori e possono essere deniti a livelli diversi (sistema o parti del sistema). Ragionare sui casi d'uso aiuta a scoprire i requisiti funzionali Diagramma delle classi Il diagramma delle classi, rappresenta le classi e gli oggetti che compongono il sistema, ed i relativi attributi ed operazioni [6, 1]. Specica, mediante le associazioni, i vincoli che legano tra loro le classi; può essere denito in fasi diverse (analisi, disegno di dettaglio) ed inoltre può rappresentare diverse tipologie di oggetti (oggetti business, oggetti di interfaccia,... ).

23 14 Diagrammi UML Diagramma delle sequenze Il diagramma delle sequenze, serve ad evidenziare il modo in cui uno scenario (uno specico percorso in un caso d'uso) viene risolto dalla collaborazione tra un insieme di oggetti; specica la sequenza dei messaggi che gli oggetti si scambiano inoltre può specicare nodi decisionali e iterazioni. Diagrammi di sequenza e diagrammi di collaborazione esprimono informazioni simili, ma le evidenziano in modo diverso Diagramma delle collaborazioni Il diagramma delle collaborazioni, specica gli oggetti che collaborano tra loro in un dato scenario, ed i messaggi che si indirizzano. La sequenza dei messaggi è meno evidente che nel diagramma di sequenza, mentre sono più evidenti i legami tra gli oggetti; può essere utilizzato in fasi diverse (analisi, disegno di dettaglio), e rappresentare diverse tipologie di oggetti Diagramma di stato Specica il ciclo di vita degli oggetti di una classe, denendo le regole che lo governano; quando un oggetto si trova in un certo stato può essere interessato da determinati eventi (e non da altri). Come risultato di un evento l'oggetto può passare ad un nuovo stato (transizione) Diagramma delle attività Serve a rappresentare sistemi di workow, oppure la logica interna di un processo (di qualunque livello, dai business process ai processi di dettaglio). Permette di rappresentare processi paralleli e la loro sincronizzazione; è un caso particolare di diagrammi di stato, in cui ogni stato è uno stato di attività Diagramma dei componenti Evidenzia l'organizzazione e le dipendenze esistenti tra componenti; i componenti sono moduli software eseguibili, dotati di identità e con un'interfaccia ben specicata, inoltre i componenti (come a livello logico le classi) possono essere raggruppati in package.