DIAGRAMMI DEI PACKAGE

Transcript

1 ESERCITAZIONE ERRORI COMUNI REV. DI PROGETTAZIONE INGEGNERIA DEL SOFTWARE Università degli Studi di Padova Dipartimento di Matematica Corso di Laurea in Informatica, A.A UML Versione di UML? È importante specificare la versione di UML utilizzata Influisce sulle regole di composizione dei diagrammi In UML 2.0.x le interfacce possono avere attributi 2 rcardin@math.unipd.it UML Un diagramma è conforme a UML 2.0.x? DIAGRAMMI DEI PACKAGE Relazioni fra i package Definiscono le dipendenze fra componenti del sistema Non è un diagramma UML compliant! Non utilizzare i package solo come raggruppamenti di classi 3 4

2 DIAGRAMMI DEI PACKAGE Relazioni fra i package Dipendenza DIAGRAMMI DEI PACKAGE Implementazione di package Un che package contiene solo interfacce e tipi astratti viene realizzato dalla classi di un altro package Questo tipo di dipendenza fra i package non è prevista in UML Definisce una dipendenza tra quelle possibili («call», «create»,...) 5 La relazione prevede la linea tratteggiata in UML 2, come nella realizzazione di interfacce 6 Utilizzare i corretti tipi di relazione fra componenti Non è una relazione di dipendenza, ma di proprietà Utilizzare solo notazione standard 7 8

3 Utilizzare descrizioni opportune Giustificare sempre le interfacce utilizzate soprattutto se hanno nomi molto generici 9 10 Utilizzare i colori per identificare gruppi di classi omogenei Ad esempio le librerie esterne Classi senza relazioni sono spesso superflue 11 Il persistence manager non ha relazioni con gli oggetti che persiste 12

4 Interfacce e attributi Possibili in UML 2.x Definiscono vincoli sulle operazioni esposte Realizzazione ed estensione interfacce Realizzazione Fra interfaccia e classe (anche astratta) UML 2.x UML 1.x Estensione In questo caso la relazione individuata è di composizione, non possibile. Utilizzare una classe astratta 13 Fra interfacce Ogni altro tipo di relazione non è prevista e quindi non è corretta! 14 Focalizzarsi su casi d uso contenuti Facilita la comprensione e aiuta a gestire la complessità Decisioni Utilizzare sempre un attività di scelta che introduce alla decisione Complesso da seguire e comprendere Difficile da governare Fork Merge Invio msg 15 16

5 Decisioni Ad ogni merge deve avere associata una condizione che determini il ramo del flusso da intraprendere Attenzione all utilizzo delle entità atomiche Deve essere un azione Deve rappresentare un oggetto con il proprio tipo Quale ramo intraprende il flusso? Si voleva utilizzare un fork? Effettuare sempre le dovute considerazioni sui flussi in un diagramma Effettuare sempre le dovute considerazioni sui flussi in un diagramma Due branch senza una decisione prima o senza un fork Serve un merge o una join per far entrare due flussi in un azione 19 20

6 Fork e join Primitive per descrivere il parallelismo Invio e ricezione messaggi Solitamente ad un invio messaggio corrisponde l attesa di una sua ricezione. Sia fork che join! Dove finiscono i flussi di queste azioni? La decisione viene presa sulla base della risposta fornita con il messaggio, non presente DIAGRAMMI DI SEQUENZA Individuare gli attori corretti Contestualizzare SEMPRE i pattern utilizzati Non è sufficiente descriverli in modo astratto come fatto a lezione Indicare i ruoli delle classi del prodotto nel pattern Solitamente è più indicato descrivere i pattern dopo aver presentato l architettura logica La componente di view non può richiamare un metodo sull utente 23 24

7 MVC Pattern originale Con implementazione attraverso Observer MVP Due tipologie di implementazioni possibili Pattern con Front controller Implementato dal framework Spring MVC MVC La view NON DEVE avere riferimenti al controller Singleton Garantisce l esistenza di un unica istanza per un tipo...e ne specifica il punto di accesso per il recupero Una classe di vista non può essere un Singleton 27 28

8 Singleton Prestare attenzione al diagramma delle classi L istanza è di classe, e non un attributo di un oggetto. Observer Permette di implementare il meccanismo di push/notify Definisce getinstance che permette l accesso all unica istanza. È responsabile della creazione dell unica istanza NO I soggetti possiedono una lista dei propri osservatori Gli osservatori possiedono un riferimento all oggetto osservato Se l istanza private non è di classe, il metodo di accesso non può accedervi ARCHITETTURA ARCHITETTURA Three-tier Client server È uno stile architetturale I livelli devono avere un divisione totale. Aumento delle dipendenze e scarsa riutilizzabilità Utilizzato in diversi contesti Non solo UI 31 Attribuire le corrette responsabilità La componente di presentazione non può esporre WS, ma può avere dei client ai WS (REST) 32

9 LAYOUT DOCUMENTO Capitoli, sezioni, paragrafi Non utilizzare troppa gerarchizzazione LAYOUT DOCUMENTO Didascalie Utilizzare didascalie parlanti e descrittive Non ripetere la medesima didascalia fra diverse figure Sezione distinta per figura e sua descrizione LAYOUT DOCUMENTO LAYOUT DOCUMENTO Attenzione all ordine di presentazione Prima il diagramma, poi la descrizione del diagramma Il tracciamento dei requisiti è l ultima informazione da presentare Le figure devono essere leggibili Soprattutto se si tratta di un diagramma UML Nel documento di ST ogni package deve essere descritto a livello di componenti logiche...e di loro relazioni/interfacce 35 Troppo sgranata l immagine, utilizzare una risoluzione maggiore 36