Programmazione ad Oggetti

Transcript

1 Programmazione ad Oggetti Unified Modeling Language Unified Modeling Language Un linguaggio (e notazione) universale, per rappresentare qualunque tipo di sistema software Uno standard OMG (Object Management Group), dal nov.1997 Le specifiche sono disponibili al sito Gli autori: Grady Booch Ivar Jacobson Jim Rumbaugh Cos è UML (e cosa non è) E un linguaggio di progettazione, non un linguaggio di programmazione (come Java, VisualBasic, C++, ) Serve a progettare un nuovo sistema, o ad apportare modifiche alla progettazione di un sistema esistente, senza perdersi nei dettagli dei linguaggi di programmazione E universale, nel senso che può rappresentare sistemi molto diversi senza differenze legate alla tecnologia: dai sistemi web a quelli più tradizionali, dalle applicazioni Cobol a quelle object oriented e a componenti 1

2 ...cos è UML (e cosa non è)... Non è un metodo (come quelli di Yourdon e DeMarco, o di Rumbaugh o Jacobson) Definisce una notazione standard, basata su un metamodello integrato degli oggetti che compongono un sistema software Non prescrive una sequenza di processo, cioè non dice prima bisogna fare questa attività, poi quest altra Può essere (ed è) utilizzato da persone e gruppi che seguono processi diversi (è indipendente dai Processi )...cos è UML (e cosa non è). E un linguaggio standard, non proprietario I suoi autori (Grady Booch, Jim Rumbaugh e Ivar Jacobson) non hanno il copyright su UML Le versioni standard ricevono i contributi di molti altri metodologi, e delle più importanti società di software mondiali E in continua evoluzione UML: meta-modello e diagrammi UML è basato su un meta-modello integrato, composto da numerosi elementi collegati tra loro, secondo regole precise Grazie a queste regole, utilizzando gli elementi del metamodello è possibile creare modelli particolari per le singole applicazioni da progettare Molti elementi (ad es. l elemento classe ) hanno una icona che li rappresenta graficamente Gli elementi del meta-modello possono comparire in diagrammi di diverso tipo 2

3 E uno standard aperto IL Valore di UML Supporta l intero ciclo di vita dello sviluppo software Supporta diverse aree applicative E basato sull esperienza e sulle esigenze della comunità di utenti E supportato da molti tools Overview di UML UML è un linguaggio per visualizzazione specifica construzione documentazione di artifacts ( pezzo di informazione che è prodotta, modificata o utilizzata da un processo) di un sistema software-intensive Modelli I Modelli sono il linguaggio del progettista, in molte discipline I Modelli sono rappresentazioni di un sistema da costruire o già costruito I Modelli sono veicoli per la comunicazione con vari costruttori I Modelli sono rappresentazioni Visuali I Modelli consento di ragionare su alcune caratteristiche del sistema reale 3

4 Un modello è una descrizione completa del sistema da una prospettiva particolare Modelli, Viste e Diagrammi Use Case Use Case Sequence Use Case Use Case Use Case State State Class State State Object Scenario Scenario Collaboration Models State State Component Scenario Scenario Statechart Activity Component Component Deployment Molti Stakeholders, Molte Viste L Architettura è intesa in modo differente da: end-user customer project manager system engineer sviluppatore architetto manutentore Realtà Multidimensionale Rappresentazione dell Architettura di Sistema Logical View Implementation View End-user Functionality Use Case View Programmers Software management System integrators Performance Scalability Throughput Process View Deployment View System engineering System topology Delivery, installation Communication 4

5 UML Views UML propone 5 viste per la descrizione di un architettura di sistema Use-Case View: mostra le funzionalità del sistema come esse sono percepite da attori esterni Logical View: mostra come una funzionalità e progettata all interno del sistema in termini della struttura statica e del comportamento dinamico UML Views (continua) Implementation View: mostra l organizzazione delle componenti di codice Process View: mostra la concorrenza nel sistema, analizzando i problemi attraverso i meccanismi di comunicazione e sincronizzazione tipici di un sistema concorrente Deployment view: mostra lo sviluppo del sistema nella sua architettura fisica con computer e periferiche (detti NODEs) Archittetura Concettuale (o Logica) Deve consentire una comprensione chiara delle funzionalità e della costruzione di un sistema Risponde a domande quali: quali funzionalità fornisce il sistema? quali sono le classi esistenti, e come sono correlate tra loro? come le classi ed i loro oggetti collaborano per fornire le funzionalità? Quali sono i vincoli temporali sulle funzioni del sistema? 5

6 Architettura fisica Descrive la composizione del software e dell hardware Risponde a domande quali: in quali programmi o processi sono fisicamente allocati classi e oggetti? su quali computer i programmi ed i processi sono eseguiti? Quali computer ed altri devices sono presenti nel sistema, e come sono connessi? Quali sono le dipendenze tra i differenti file di codice? Se si cambia un file quali altri file bisogna cambiare? Architettura fisica (continua) I concetti Hardware presenti nell architettura fisica sono: Processori Devices (stampanti, routers, lettori di card, etc) Connessioni (es. fibra ottica, protocollo TCP/IP) Architettura fisica (continua) I concetti Software utilizzati nell architettura fisica sono: component -- parte riusabile che fornisce il packing fisico di una collezione di istanze di model elements (es. un file codice sorgente) processi e threads oggetti Gli oggetti non hanno un loro thread di esecuzione, ma vengono attivati solo quando qualcuno manda loro un messaggio 6

7 Quante viste? Non tutti i sistemi necessitano di tutte le viste: Single processor: si elimina la deployment view Single process: si elimina la process view Programmi molto piccoli: si elimina implementation view Views aggiuntive: Data view, security view Diagrammi UML Use Case Diagram Descrive le funzionalità del sistema così come percepite dall esterno Class Diagram Descrive le classi che compongono il sistema e le loro relazioni Object Diagram Descrive gli oggetti reali del sistema Diagrammi UML (2) Sequence Diagram Descrive le interazioni tra le classi per la realizzazione delle funzionalità Collaboration Diagram Descrive le collaborazioni tra le classi Activity Diagram Descrive le attività che le classi compiono ed il loro grado di parallelismo 7

8 Diagrammi UML (3) State Diagram Descrive gli stati di un oggetto e le possibili transizioni Component Diagram Descrive i componenti del sistema Deployment Diagram Descrive l allocazione dei componenti software rispetto ai nodi hardware Logical View Diagrammi UML Implementation View Class Objects Sequence Collaboration State Use Case View Use Case Component Deployment Static Models Dynamic Models Activity Conceptual Architecture Deployment View Corso di Programmazione Process ad Oggetti View Physical Architecture Modellare con UML Quando si descrive un sistema con UML, non viene costruito un singolo modello. In fase di analisi, lo scopo di un modello è quello di catturare i requisiti del sistema e modellare le classi e le collaborazioni essenziali legate al mondo reale In fase di design, lo scopo del modello è quello di espandere il modello di analisi in soluzioni tecnicamente praticabili tenendo presente l ambiente implementativo 8

9 Modellare con UML (continua) Nella fase di implementazione, il modello rappresenta il codice sorgente che viene successivamente compilato. Nella fase di sviluppo, il modello descrive come il sistema si traduce nell architettura fisica Modellare con UML (continua) UML è phase independent : lo stesso generico linguaggio e gli stessi diagrammi sono utilizzati per modellare code diverse in fasi diverse Meccanismi di Estendibilità di UML Stereotype Tagged value Constraint 9

10 Modellazione Statica Il comportamento statico del sistema viene descritto in UML attraverso i seguenti diagrammi: Use case diagram Class diagram Object diagram Component diagram Use Case Modeling Uno use -case è una tecnica di modellazione utilizzata per descrivere cosa dovrebbe fare un nuovo sistema o cosa fa un sistema esistente Le componenti principali di un modello usecase sono: use-cases actors sistema modellato Use Case Modeling (continua) Gli scopi primari di un modello use-case sono: decidere e descrivere i requisiti fondamentali del sistema fornire una chiara e consistente descrizione di cosa dovrebbe fare il sistema fornire una base di partenza per l effettuazione di test funzionali che verifichino il sistema fornire un supporto alla traduzione dei requisiti funzionali in classi ed operazioni reali del sistema 10

11 Use Case Modeling (continua) Il processo per creare un modello use-case può riassumersi nei seguenti passi: definire gli attori definire gli use-cases e descriverli definire le relazioni tra use-cases validare il modello Use-case diagram: Sistema La definizione dei confini di un sistema cosi come le attività ad esso assegnate non è un lavoro semplice Tipicamente si parte identificando delle funzionalità base e ci si concentra sulla definizione di un architettura stabile, ben definita, e facilmente estendibile in future release Use-case diagram: Sistema Ciò viene essenzialmente fatto attraverso la stesura di un catalogo di concetti chiave espressi in maniera testuale e che descrivono le funzionalità del mondo reale in UML il sistema è indicato con un box System 11

12 Actors (attori) Un attore è qualcuno o qualcosa che interagisce con il sistema Un actor rappresenta un ruolo e non un utente Ad un actor è associato un nome che deve riflettere il ruolo dell attore Actors (continua) L attore interagisce con il sistema spedendo e ricevendo messaggi Un use-case è sempre INIZIATO da un attore Reservation Maker Ricerca degli Attori Un aiuto all identificazione degli attori sta nella risposta alle seguenti domande: Chi utilizza le funzioni principali del sistema? Chi necessita di un supporto dal sistema per il proprio lavoro? Chi deve manutenere, amministrare il sistema? Quali device HW il sistema deve utilizzare? Con quali altri sistemi il sistema in esame deve interagire? Chi o cosa ha interesse nei risultati che il sistema produce? 12

13 Actors in UML Gli actors in UML sono CLASSI con lo stereotype <<actor>> Il nome della classe è il nome dell actor Gli actor possono avere una relazione di generalizzazione: ciò accade quando un actor specializzato eredita (ed estende) il comportamento di un altro attore Reservation Maker Reservation System Administrator Use-Case Un use-case rappresenta una funzionalità completa così come percepita da un attore In UML è definito come un set di sequenze di azioni eseguite dal sistema e che produce un risultato (o un valore) per un particolare actor Le caratteristiche di uno use-case sono: è sempre iniziato da un attore fornisce un valore ad un attore è completo, nel senso che descrive completamente una funzionalità Individuazione degli use-case Un notevole aiuto all identificazione degli usecase viene dalle risposte (per ogni attore individuato) alle seguenti domande : Quali funzioni l attore richiede al sistema? Cosa deve fare l attore? L attore ha necessità di leggere,creare,modificare,distruggere, memorizzare qualche tipo di informazione del sistema? 13

14 Individuazione degli use-case (segue) L attore deve essere informato su alcuni eventi del sistema o deve notificare al sistema l avvenimento di qualcosa? Può il lavoro dell attore essere semplificato o reso più efficiente aggiungendo nuove funzionalità al sistema? Individuazione degli use-case (segue) Altre domande che non coinvolgono attori sono: di quali input/output necessita il sistema? Da dove provengono tali input/output? Quali sono i maggiori problemi relativi all attuale implementazione del sistema? Use-case in UML Uno use-case è rappresentato da un ellisse contenente il nome dello use-case, o con il nome sotto l ellisse Make a Reservation Reservation Maker 14

15 Descrizione dello use case La descrizione testuale di uno use case contiene Nome, Iniziatore, Obiettivo, Sequenza di passi che descrive lo scenario di successo Nome: Make a Reservation Iniziatore: Reservation Maker Obiettivo: Prenotare una stanza in albergo Reservation Maker Make a Reservation Scenario principale 1. Il reservation maker fa una richiesta di prenotazione 2. Il reservation maker seleziona l hotel 3. Il sistema fornisce la disponibilità ed il prezzo 4. Il reservation maker concorda con l offerta 5. Il reservation maker fornisce le informazioni personali 6. Il reservation maker fornisce i dettagli di pagamento 7... Relazioni tra Use-case - Extend Extend Scenario in cui il caso d uso non va a buon fine Nome: Make a Reservation Iniziatore: Reservation Maker Obiettivo: Prenotare una stanza in albergo Reservation Maker Make a Reservation <<extend>> Reservation not Available Scenario principale 1. Il reservation maker fa una richiesta di prenotazione 2. Il reservation maker seleziona l hotel 3. Il sistema fornisce la disponibilità ed il prezzo 4. Il reservation maker concorda con l offerta 5... Extension 3 Camera non disponibile 3.a Il sistema offre una data o un tipo di camera alternativa Ing. 3.bAntonio Il reservation Coronato maker sceglie una alternativa Relazioni tra Use-case - Include include Inclusione di un caso d uso <<incl ude>> Verify Identity Reservation Maker Make a Reservation 15

16 Class Diagram E un modello statico Descrive una vista statica del sistema in termini di classi e relazioni Un esempio Persona Genere Nome_Genere Nome Cognome 1 0..n Libro Autore Codice_Autore Bibliotecaio Matricola Titolo 1..n concede_prestito() 0..n 1..n Utente richiede_prestito() 0..n Prestito Data_Inizio Data_Fine Classe Elementi di un Class Diagram Bibliotecaio Matricola concede_prestito() Poligono calcola_area() calcola_perimetro() Relazioni Associazione Aggregazione Autore Libro Codice_Autore Veicolo Gen-Spec Persona Nome Titolo 0..n 1..n Cognome Composizione Torta Carrozzeria Motore Autore Codice_Autore Zucchero Farina Elementi di un Class Diagram (2) Note Questa classe non è istanziabile Poligono calcola_area() calcola_perimetro() Navigabilità Associazione Navigabile Libro Titolo 0..n Referim enti 0..n Titolo Autore 16

17 Individuazione delle classi Un aiuto alla individuazione delle classi ci può essere dato rispondendo alle seguenti domande: Ci sono informazioni da memorizzare o analizzare? Ci sono sistemi esterni da utilizzare o con i quali interagire? Ci sono librerie,componenti, etc da utilizzare? Ci sono device che il sistema deve utilizzare? Che ruolo giocano gli attori nel sistema? Component Diagram Evidenzia l'organizzazione e le dipendenze esistenti tra componenti I componenti sono moduli software eseguibili, dotati di identità e con un'interfaccia ben specificata I componenti (come a livello logico le classi) possono essere raggruppati in package Component Diagram Un componente software può essere di tipo: source, ed ha significato solo a compile time binary (codice oggetto, libreria, dll, etc), ed ha significato a link time (tranne le dll ) executable, che rappresenta l unità eseguibile si di un processore 17

18 Component Diagram database server ordine cliente form inserimento ordine l'esistenza dell'ordine dipende da quella del cliente package dipendenza componente 18