Introduzione. Modellazione visuale. Perché UML. cont.) Perché UML (cont( Contributi principali

Transcript

1 Unified Modeling Language Introduzione Davide Frey Corso di Ingegneria del Software Tratto dal materiale di Luciano aresi Politecnico di Milano Modellazione visuale Perché UML richiesta ordine consegna usiness Process Un modello cattura le parti essenziali di un sistema Dr. James Rumbaugh Computer System UML è il linguaggio visuale standard (OMG) per definire, progettare, realizzare e documentare i sistemi software ad oggetti UML riunisce molte proposte esistenti (ooch, Rumbough e Jacobson) UML copre l intero processo di produzione UML è sponsorizzato dalle maggiori industrie produttrici di software 3 4 Perché UML (cont( cont.) Contributi principali UML riunisce aspetti dell ingegneria del software, delle basi di dati e della progettazione di sistemi UML è indipendente da qualsiasi linguaggio di programmazione UML è utilizzabile in domini applicativi diversi e per progetti di diverse dimensioni UML è estendibile per modellare meglio le diverse realtà ooch ooch method Rumbaugh OMT Meyer efore and after conditions Jacobson OOSE Harel Statecharts Shaler - Mellor Object lifecycles Gamma, et al Frameworks and patterns, HP Fusion Operation descriptions and message numbering Odell Classification Embley Singleton classes and high-level view Wirfs-rock Responsibilities 5 6 1

2 Model-based 4+1 Views I modelli rappresentano il linguaggio dei progettisti I modelli rappresentano il sistema da costruire o costruito I modelli sono un veicolo di comunicazione I modelli descrivono in modo visuale il sistema da costruire I modelli sono uno strumento per gestire la complessità I modelli consentono di analizzare caratteristiche particolari del sistema Design View Process View Logical Use Case View Implementation View Deployment View Physical P. Kruchten, The 4+1 View Model of Software rchitecture. IEEE Software 12 (6), pages 42-50, november Diagrammi UML Registrazione corsi Viste statiche Use Case Diagrams Class Diagrams Object Diagrams Component Diagrams Deployment Diagrams Viste dinamiche Sequence Diagrams Collaboration Diagrams Statechart Diagrams ctivity Diagrams ll inizio dell anno accademico, l ufficio amministrativo dell università fornisce agli studenti la lista di corsi disponibili, attraverso un sistema di registrazione. Il sistema deve consentire agli studenti di selezionare quattro corsi fra quelli disponibili. In aggiunta ogni studente deve indicare due alternative. Nessun corso può avere più di 10 studenti. Corsi con meno di 3 studenti vengono cancellati automaticamente Registrazione corsi (cont( cont.) I professori devono poter accedere al sistema per indicare i corsi in cui vorrebbero insegnare e per vedere gli studenti iscritti ai loro corsi. Il processo di registrazione dura 3 giorni. Il primo giorno è riservato agli studenti del primo anno. Il secondo giorno è riservato agli altri studenti. Durante il terzo giorno si risolvono eventuali conflitti. Finito il processo di registrazione, le informazioni relative ad un studente sono inviate all ufficio contabile per determinare le tasse da pagare. Use case diagram 11 2

3 Requisiti Il primo passo di qualsiasi processo di sviluppo è la definizione dei requisiti Definizione del usiness Model Solitamente informale e in linguaggio naturale Jacobson (OOSE) propone una notazione particolare che è confluita in UML Use Case Diagram Use case Definiscono il comportamento del sistema Le funzionalità (processi) principali Come il sistema agisce e reagisce Descrivono Il sistema L ambiente Le relazioni fra sistema e ambiente Diversi livelli di dettaglio Elementi grafici Relazioni principali ctor: è qualcuno (utente) o qualcosa (sistemi esterni - hardware) che: Controlla le funzionalità Fornisce input o riceve output dal sistema Use Case: è un unità funzionale parte del sistema <<extend>> <<communicate>> ssociations identificano relazioni semplici tra attori e casi Include fattorizza proprietà comuni. È simile all innesto di procedure alla Pascal. includes Communicate indica scambio dati tra due use case Extend identifica comportamenti simili (varianti).. può essere visto come una variante di Generalization si applica sia ad attori che a use case.. eredita il comportamento di. può essere sostituito ad ogni occorrenza di (Registrazione corsi) Contesto (Ufficio postale) mministrazione Studente Cambio organizzazione corso Scelta corsi Richiesta studenti registrati Cambio corsi Selezione corso Richiesta corsi Gestione studenti Professore Postino Cliente Distr. posta Sportello Il primo Use Case diagram definisce il contesto del modello Scelte diverse possono imporre ttori diversi Use case diversi Gestione corsi Gestione professori Impiegato rchivio globale

4 Extend/generalization Generalization indica che uno use case è simile a un altro ma è più specifico. Si descrive lo use case più specifico per differenze rispetto a quello più generale Extend e generalization sono leggermente differenti Esempi Pagamento prodotto e pagamento con carta di credito Stampa catalogo prodotti e pubblicazione catalogo su Internet Calcola prezzo prodotto e calcola prezzo scontato Include Include fattorizza attività ricorrenti e condivise nalogie con Chiamata a sottoprocedura in un linguaggio di programmazione Scomposizione gerarchica in DFD (Si perde la condivisione) Esempi La richiesta del numero di CC per ogni operazione bancaria La consultazione del catalogo di una biblioteca Le funzioni matematiche più complesse (sin, cos, log, ecc.) Use case (Processo) Utente Gestione prestito Ordine <<extend>> Impiegato Ordine Internet Gestione pagamento Gestione disponibilità Gestione dati Il processo di definizione degli use case è iterativo Si inizia identificando il comportamento più semplici Si descrivono i comportamenti alternativi e più complessi Quando smettere? Un buon livello di dettaglio facilità tutte le attività successive Troppi dettagli Complicherebbero inutilmente la descrizione Introdurrebbero prematuramente scelte progettuali Precluderebbero la visione d insieme Documentazione Oltre l analisi dei requisiti Per ogni use case: Titolo: : Computo tasse utori: Pluto e Topolino Descrizione: : Quando le iscrizioni di uno studente sono state accettate si inviano le informazioni all ufficio contabile ttori: : Ufficio contabile Pre-condizioni condizioni: : Studente registrato Post-condizioni condizioni: : Non identificate Scenari:... Convalida del sistema Gli use case possono essere utilizzati per ricavare i dati di test con cui convalidare il sistema Ogni use case rappresenta una funzionalità che andrebbe verificata Gestione del progetto Gli use case propongono una nuova unità di misura Gli use case potrebbero essere utili per Organizzare il progetto Stimare la complessità (sorta di function point)

5 Esercizio Scenari Si definisca un semplice Use Case Diagram per modellare il sistema informativo di una impresa edile. Il sistema deve gestire gli operai, i cantieri, il parco mezzi e i clienti 25 Uno scenario è un istanza di uno use case È una esecuzione particolare dello use case Rappresenta il comportamento (le azioni e gli eventi) del sistema nel caso particolare considerato Gli scenari definiscono requisiti di più basso livello rispetto agli use case Gli scenari sono solitamente definiti in linguaggio naturale UML propone una notazione particolare Interaction Diagram 26 Scenari (cont( cont.) (Selezione corsi) Ogni use case dovrebbe essere corredato da un insieme di scenari Scenari principali (più possibile) Tutto funziona correttamente Scenari secondari (pochi e significativi) Eccezioni (eventuali problemi o malfunzionamenti) Quanti scenari si devono definire? Servono tanti scenari quanti sono quelli necessari per capire il corretto funzionamento del sistema e le eccezioni che si ritengono significative in durante l analisi Pippo sceglie i corsi: informatica, fisica, analisi e disegno Come corsi alternativi sceglie: fotografia e giornalismo I corsi scelti sono immessi nel sistema di registrazione Lo studente viene aggiunto ai primi 3 corsi principali Il quarto corso non è disponibile IF la prima alternativa è disponibile THEN Lo studente viene aggiunto al corso ELSIF la seconda alternativa è disponible THEN Lo studente viene aggiunto al corso ELSE notifica allo studente IF not notifica THEN Si crea la cartella corsi dello studente Si mandano le informazioni all ufficio contabile Interaction diagram Interaction diagram Descrivono il comportamento dinamico di un gruppo di oggetti che interagiscono per risolvere un problema Sono utilizzati per formalizzare gli scenari in termini Entità (oggetti) Messaggi scambiati (metodi) UML propone due diversi tipi di Interaction Diagram Sequence Diagram Collaboration Diagram 30 5

6 Sequence diagram Evidenziano la sequenza temporale delle azioni Non si vedono le associazioni tra oggetti Usabili in due forme diverse La forma generica: tutte le sequenze (esecuzioni) possibili La forma d istanza: una sequenza particolare (consistente con quella generica) (Caso specifico) Potrebbe Potrebbe essere essere diventare diventare un un attore attore Pippo Selettore Scegli informatica Candidati Candidati per per diventare diventare metodi metodi Conferma registrazione Candidati Candidati per per diventare diventare classi classi Informatica Disponibile? ggiungi Pippo Le risposte restano implicite Oggetti luciano: Persona nome = Paperon cognome = De Paperoni datanascita = 1/01/50 luogonascita = Italia Paperon Paperon :Persona Paperon :Persona [ricco] : Persona (Raffinamento diagramma precedente) {transient} :Selettore Informatica: Corso Pippo seleziona(informatica) disponibile() aggiungi(pippo) conferma(informatica) Paperon (Chiamata telefonica) Sequence diagram (lternative e creazione oggetti) Chiamante Mezzo Chiamato Obj3:C3 Obj4:C4 {b-a < 1 sec.} {c-b < 10 sec.} a b c inizio disponibile digita n.... op() Obj1:C1 [x>=0] foo(x) Obj2:C2 [x<0] bar(x) doit(w) doit(z) Il ritardo è dato dal mezzo di comunicazione {d -d < 5 sec.} d d aspetta instrada suona risposta more() La conversazione inizia fine attesa fine attesa

7 Messaggi gi Esercizio Sincroni Il sorgente deve aspettare il destinatario Chiamate di procedure o chiamate innestate Flusso di controllo piatto sincroni Il sorgente continua senza aspettare il destinatario Utile per sistemi concorrenti (con oggetti attivi) Condizioni [x>0] foo() Iterazioni * foo() Risposte (return) Send Create Destroy Si definisca un semplice Sequence Diagram per modellare il prelievo di denaro, supponiamo 200 Euro, da uno sportello ancomat