Principi di Progettazione del Software a.a

Transcript

1 Principi di Progettazione del Software a.a UML: approfondimenti sui diagrammi delle classi e di sequenza. Diagrammi di package e di deployment Prof. Università del Salento

2 Obiettivi della lezione Approfondire alcuni concetti relativi ai diagrammi delle classi e ai diagrammi di sequenza Introdurre i diagrammi dei package e di deployment Comprendere come utilizzare i diagrammi sopra elencati per progettare/documentare l architettura software delle applicazioni di interesse per il corso di Principi di Progettazione del Software 2

3 Diagramma delle classi E la tipologia di diagramma più ricorrente (e forse più utile) di UML Un diagramma delle classi può essere utilizzato per modellare concetti oppure per modellare software Nel secondo caso, descrive il tipo degli oggetti (classi) che fanno parte di un sistema software e le relazioni che li legano Per ogni classe, il diagramma descrive le corrispondenti caratteristiche (feature), cioè le proprietà e le operazioni che la compongono 3

4 Un esempio di diagramma delle classi Ordine -data: Data [0..1] -prepagato: Boolean [1] -numero: String [1] -prezzo: Denaro +spedisci() +chiudi() * 1 Cliente -nome [1] -indirizzo [0..1] +getilivellocredito() : String 1 {ordered} * LineaOrdine -quantita: integer -prezzo: Denaro {if Ordine.cliente.getLivelloCredito() == "basso" then Ordine.prepagato = true} -elementilinea AziendaCliente -nomecontatto -livellocredito -limitecredito +contomensile(in c : Integer) +sollecito() * ClientePrivato -numerocartacredito {getlivellocredito() == "basso"} * rappresentante Prodotto Impiegato 4

5 Proprietà Le proprietà di una classe ne definiscono la struttura In prima approssimazione corrispondono ai campi della classe Le proprietà possono essere rappresentate con due notazioni differenti Attributi Tipicamente utilizzati per rappresentare dati semplici Associazioni Tipicamente utilizzati per rappresentare dati complessi (altre classi) 5

6 Attributi Sintassi completa visibilità nome: tipo molteplicità = default {stringa-di-proprietà} Esempio - titolo: String [1] = UML distilled {readonly} Elementi visibilità: (-) private, (#) protected, (+) public nome: nome dell attributo tipo: tipo di dato di un campo di programmazione molteplicità: numero di valori ammessi per le istanze default: valore di default in un oggetto appena creato {stringa-di-proprietà}: alcune caratteristiche aggiuntive 6

7 Associazioni Un associazione è una linea continua che collega due classi E orientata dalla classe sorgente a quella destinazione La classe destinazione corrisponde al tipo della proprietà La rappresentazione con associazioni descrive in modo più intuitivo l architettura Dal punto di vista implementativo la rappresentazione con associazioni è equivalente alla rappresentazione con attributi -data: Data [0..1] -prepagato: Boolean [1] -elementilinea: LineaOrdine [*] {ordered} Data -data 0..1 * Ordine Ordine 1 * LineaOrdine -prepagato 1 -elementilinea {ordered} Boolean 7

8 Molteplicità La molteplicità indica quanti oggetti possono entrare a far parte di una proprietà (attributo o associazione) Sintassi [min..max] Esempi Opzionale: [0] Obbligatorio: [1..1], [1] Singolo: [0..1] Multiplo: [0..*], [1..*], [*] Se una proprietà ha più valori si possono specificare proprietà aggiuntive come {ordered}, {unordered} La molteplicità di default di un attributo è [1] 8

9 Proprietà e codice Java Non vi è una diretta corrispondenza tra UML e codice, ma una analogia Ad esempio, le proprietà possono essere implementate come campi privati (a) o come operazioni (b) public class LineaOrdine private int quantita; private Denaro prezzo; private Ordine ordine; private Prodotto prodotto; (a) public class LineaOrdine private int quantita; private Prodotto prodotto; public int getquantita(){ } return quantita; public int setquantita(int q){ } this.quantita = q; public Money getprezzo(){ } return prodotto. getprezzo(). multiply(quantita); (b) 9

10 Operazioni Sintassi completa visibilità nome (lista-parametri): tipo-di-ritorno {stringa-di-proprietà} Esempio + saldo (data: Data): Denaro Elementi visibilità: (-) private, (#) protected, (+) public nome: nome dell operazione lista-parametri: direzione nome: tipo = default nome, tipo, valore di default sono analoghi a quelli degli attributi direzione: in, out, inout tipo-di-ritorno: è il tipo del valore restituito {stringa-di-proprietà}: alcune caratteristiche aggiuntive 10

11 Generalizzazione La generalizzazione modella il concetto di supertipo/sottotipo Ad esempio: Cliente/AziendaCliente AziendaCliente è un sottotipo di Cliente se tutte le istanze della prima classe sono anche istanze della seconda Dal punto di vista software La generalizzazione modella l ereditarietà per molti linguaggi a oggetti Un concetto di base per l ereditarietà è il principio di sostituibilità di Liskov: dovrebbe essere sempre possibile sostituire AziendaCliente in tutti i punti in cui il codice richiede Cliente e tutto dovrebbe continuare a funzionare Per ottenere sottoclassi sostituibili è bene fare riferimento al concetto di ereditarietà di interfaccia oppure a design patterns piuttosto che all ereditarietà di classe (Gamma, Helm, Johnson, Vlissides Design patterns Addison-Wesley 2002) 11

12 Dipendenza La classe A (client) dipende dalla classe B (supplier) se ogni modifica a B può implicare una modifica ad A A chiama metodi di B A usa B come tipo di un suo attributo A usa B come tipo in una sua operazione E importante minimizzare le dipendenze E fondamentale evitare dipendenze cicliche Molte relazioni UML implicano una dipendenza Un associazione navigabile (es: Ordine dipende da Cliente) Una generalizzazione (es: AziendaCliente dipende da Cliente) Gateway dei dati Offerte UI Prodotto Prodotto Gateway dei dati Prodotto 12

13 Tipologie di dipendenze UML <<call>> <<create>> <<derive>> <<instantiate>> <<permit>> <<realize>> <<refine>> <<substitute>> <<trace>> <<use>> La sorgente invoca un operazione della destinazione La sorgente crea un istanza della destinazione La sorgente è derivata dalla destinazione La sorgente è un istanza della destinazione. Poiché la sorgente è una classe, la destinazione deve essere una meta-classe La destinazione permette alla sorgente di accedere ai suoi campi privati La sorgente è un implementazione di un interfaccia della destinazione Raffinamento tra livelli semantici, ad esempio tra analisi e progettazione La sorgente è sostituibile alla destinazione Usata per tenere traccia di cose come i requisiti La sorgente richiede la destinazione per la sua implementazione 13

14 Vincoli Quando si definiscono diagrammi delle classi, di fatto si definiscono dei vincoli Ad esempio, un Ordine può essere creato solamente da un singolo Cliente I costrutti UML come attributi, associazioni, generalizzazioni permettono di catturare i vincoli più importanti Altri vincoli possono essere espressi in vari modi (tra parentesi graffe e all interno di note) In linguaggio naturale In qualche pseudo linguaggio In OCL (Object Constraint Language), che è basato sul calcolo dei predicati 14

15 Come usare i diagrammi delle classi Stabilire il livello di modellazione Concettuale (modellazione di concetti) Logica (modellazione dei software) Stabilire l interpretazione da dare alle classi UML Classi di analisi (modello nello spazio dei requisiti) Classi del software (modello nello spazio della soluzione) Procedimento Non utilizzare subito tutti i costrutti disponibili, ma concentrarsi in prima istanza su classi, associazioni, attributi, generalizzazioni, dipendenze, vincoli Fare diagrammi delle classi solamente per le cose rilevanti Non concentrarsi solamente sulla struttura, ma sviluppare in parallelo diagrammi delle classi e diagrammi comportamentali (diagrammi di sequenza) 15

16 Profili Un profilo è una personalizzazione del meta-modello UML E conveniente definire dei profili quando è rilevante introdurre concetti specifici di alcuni domini Tecnicamente un profilo UML è Un insieme di stereotipi Un insieme di vincoli Un insieme di tagged value (coppia attributo valore) Tipicamente i profili vengono utilizzati per creare nuovi linguaggi a partire da UML La WAE (Web Application Extension) è una personalizzazione di UML per la progettazione di applicazioni web 16

17 Visualizzare le responsabilità delle classi Vista -- visualizza i dati del modello Modello -- gestisce la logica del dominio e lo stato Controllore -- gestisce l'interazione col sistema 17

18 Aggregazione e composizione E importante comprendere la differenza tra aggregazione e composizione Nella composizione vale la regola della non condivisione Benché una classe possa essere componente di molte altre classi, ogni sua istanza può essere componente di un solo oggetto Inoltre nella composizione, se il tutto viene eliminato, anche i componenti devono essere eliminati Ad esempio, se si cancella un poligono, anche tutti i suoi punti devono essere eliminati -membri Club Persona * * {ordered} 1 1 Poligono Punto Cerchio 1 3..* -centro 18

19 Proprietà derivate Sono calcolate a partire da altri valori La sintassi prevede di anteporre al nome delle proprietà derivate il simbolo / Con un vincolo possiamo descrivere la semantica di derivazione PeriodoDiTempo -inizio: Data -fine: Data -/durata: Integer {durata = fine inizio} 19

20 Interfacce e classi astratte Una classe astratta è una classe che non può essere istanziata. Solo le sue sottoclassi concrete lo possono essere «interfaccia» Collection +equals() +add() Una classe astratta ha operazioni pubbliche astratte, cioè operazioni con la sola dichiarazione e senza implementazione Una classe astratta è indicata con il nome in corsivo o con l etichetta {abstract} Ordine -items [*] «interfaccia» List +get() AstractList +equals() +get() +add() Un interfaccia è una classe priva di implementazione, cioè tutte le sue caratteristiche sono astratte Le dipendenze dovrebbero sempre sussistere tra classe e interfacce e non direttamente tra classi Dipendenza (richiede l interfaccia) Implementazione (fornisce l interfaccia) ArrayList +get() +add() 20

21 Interfacce e classi astratte (cont) Le classi possono richiedere oppure fornire interfacce Una classe richiede un interfaccia se ha bisogno di una sua istanza per funzionare Una classe implementa un interfaccia se è sostituibile ad essa Ordine -items [*] List Collection ArrayList In UML2 ci sono due notazioni alternative come mostra l esempio a fianco Ordine -items [*] List ArrayList Collection 21

22 Principi di Progettazione del Software a.a Diagrammi di sequenza, package, deployment Prof. Università del Salento

23 Diagramma di sequenza Un diagramma di sequenza rappresenta il comportamento di un insieme di oggetti coinvolti in un singolo caso d uso Sono da utilizzare principalmente per rappresentare decisioni già prese sull implementazione di singoli casi d uso Non spiegano i dettagli degli algoritmi (meglio per questo utilizzare i diagrammi di attività) Se invece si è in fase di scelta e si vogliono vagliare differenti possibilità d interazione, è meglio utilizzare le schede CRC Prendiamo ad esempio lo scenario di calcolo del prezzo totale di un ordine commerciale 23

24 Implementazione scenario calcolo prezzo ordine: controllo centralizzato unordine unalineaordine unprodotto uncliente Utente calcolaprezzo getquantita getprodotto unprodotto getdettagliprezzo calcolaprezzobase calcolasconti getinfosconto 24

25 Implementazione scenario calcolo prezzo ordine: controllo distribuito unordine unalineaordine unprodotto uncliente Utente calcolaprezzo calcolaprezzo getprezzo(quantita) getvaloresconto(unordine) getvalorebase valorescontato 25

26 Creare e distruggere partecipanti unhandler interrogadatabase new unaquery new uncomandodb esegui risultati chiudi risultati 26

27 Cicli e condizioni Utente calcolaprezzo unordine unalineaordine unprodotto loop alt opt loop getquantita getprodotto unprodotto getdettagliprezzo Frame d interazione calcolaprezzobase 27

28 Messaggi sincroni e asincroni unoggetto unaltrooggetto Messaggio sincrono Messaggio asincrono 28

29 Diagramma di comunicazione E un particolare tipo di diagramma d interazione che mette in enfasi lo scambio di dati tra gli oggetti partecipanti In UML 1 era chiamato diagramma di collaborazione E equivalente a un diagramma di sequenza L ordine temporale viene specificato dalla numerazione dei messaggi E più comodo del diagramma di sequenza durante le riunioni informali (da disegnare alla lavagna) Il diagramma di comunicazione a lato è equivalente al diagramma di sequenza presentato precedentemente per la specifica dello scenario di calcolo del prezzo di un ordine, con controllo centralizzato 1.4: calcolaprezzobase 1.5: calcolasconti 1.1: getquantita 1.2: getprodotto unordine unalineaordine 1: calcolaprezzo 1.5.1: getinfosconti 1.3: getdettagliprezzo uncliente unprodotto 29

30 Diagramma di package Un package è un contenitore di elementi UML Tipicamente usiamo i package per illustrare sottosistemi In tal senso un package contiene sotto-package e classi Un package definisce un namespace e rappresenta i package Java o i namespace C++ e C# Una classe ha un solo package di appartenenza e deve avere un nome univoco in tale package Un package è denotato con un box con linguetta util util Data java util Data java::util::data 30

31 Diagramma di package (cont.) Le classi di un package possono essere pubbliche o private Una classe pubblica fa parte dell interfaccia del package Può essere usata dalle classi al di fuori del package Come si fa a stabilire quali classi devono appartenere al medesimo package? Classi coese Classi che condividono le medesime cause di cambiamento Classi che dovrebbero essere riusate insieme 31

32 Package e dipendenze Soprattutto se il sistema è complesso, è molto utile un diagramma dei package che documenta i package del sistema e le dipendenze tra di essi Presentazione conti correnti Interfaccia utente Presentazione fondi Tali dipendenze sono desunte dalle dipendenze tra le corrispettive classi Dominio conti correnti Dominio fondi Un package con tante dipendenze entranti deve necessariamente avere un interfaccia stabile Mapper dati conti correnti Mapper dati fondi Le dipendenze non sono transitive (fortunatamente) Database 32

33 Implementare package Può essere utile definire interfaccia e implementazione di una classe in package separati Nell esempio accanto la realizzazione indica che Gateway del database definisce un interfaccia implementata dagli altri gateway Applicazione Gateway del database Gateway Oracle Gateway MySQL Gateway SQLServer 33

34 Diagramma di deployment I diagrammi di deployment specificano il rilascio del sistema a livello fisico Il sistema è fatto di nodi, cioè di elementi che possono eseguire software Un dispositivo hardware (ad esempio un PC) è un nodo Un ambiente software (ad esempio un sistema operativo) è un nodo I nodi contengono artefatti e componenti (file eseguibili, file di dati, configurazioni, documenti HTML, XML, ecc.) Client con browser http Web server {OS = Linux} {web server = Apache} Application.war Client dedicato {OS = Windows} Java RMI Application server {OS = Linux} {EJB container= JBoss} {DBMS = Oracle} DCOM 34