Diagrammi_classi2.0
Transcript
Diagrammi_classi2.0
Diagrammi delle classi Tecnica centrale di modellazione OO Descrizione strutturale statica degli oggetti che compongono il sistema (comprensiva di attributi e operazioni) e delle loro relazioni (restrizioni incluse) Descrizione dei vincoli Sono simili ai modelli per i dati è facile basare erroneamente il loro sviluppo sui dati piuttosto che sulle responsabilità Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 1 Concetti essenziali Elementi Sintassi Classe Scatola suddivisa in tre parti orizzontali, contenenti rispettivamente nome, attributi (lo stato) e operazioni (il comportamento); nome è una stringa in grassetto che identifica univocamente la classe e può essere preceduta dal nome del package che contiene la classe (es. java::awt::Rectangle); la sezione del nome è l’unica obbligatoria nome attributi operazioni Semantica Insieme di oggetti che condividono gli stessi attributi, operazioni, relazioni e semantica Shape origin height : Float Is Empty : Boolean = false move ( ) resize ( ) display ( ) Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 2 Concetti essenziali (cont.) Elementi Sintassi Attributo visibilità nome: tipo [molteplicità] = valore-didefault {stringa-elencoproprietà-aggiuntive} dove solo nome, che è una stringa, è obbligatorio Semantica default = valore in un oggetto appena creato, se non specificato diversamente durante la creazione Se la stringa delle proprietà aggiuntive non è presente, generalmente l’attributo è modificabile Es. – titolo: String [1] = “UML distilled” {readOnly} Visibilità (di attributi e operazioni) + (pubblica) - (privata) # (protected) ~ (package) Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi Gli elementi pubblici possono essere usati da un’altra classe, quelli privati invece sono riservati all’uso interno Per la semantica precisa degli identificatori bisogna fare riferimento alle regole del linguaggio di programmazione adottato 3 Associazione associazione molteplicità 1..* Persona dipendente * datore di lavoro Azienda nome del ruolo Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 4 Concetti essenziali (cont.) Elementi Sintassi Associazione Linea continua che unisce (o ruolo) due classi; opzionalmente ciascun capo della linea può terminare con una punta biforcuta, che indica la navigabilità, e può essere etichettato con: molteplicità (es. 1, *, 0..1) nome del ruolo (stringa da specificare solo quando fa aumentare la comprensibilità, altrimenti il nome implicito del ruolo è quello della classe attaccata al capo) Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi Semantica Relazione statica fra le istanze di due classi; la molteplicità è il numero di oggetti che prendono parte a tale relazione; la navigabilità è il verso di percorribilità del collegamento (e non è rilevante nel modello concettuale); l’assenza dell’indicazione di navigabilità si interpreta o come mancanza di info circa la stessa o come associazione bidirezionale, che è difficile da implementare perché richiede che le due proprietà siano sempre “sincronizzate” 5 Proprietà di una classe Proprietà espressa come attributo Ordine + data : Data [0 .. 1] prepagato : Boolean [1] cliente Proprietà espressa come associazione navigabilità Ordine + data : Data [0 .. 1] prepagato : Boolean [1] Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi Cliente * 1 6 Molteplicità delle proprietà Si indicano gli estremi inferiore e superiore di un intervallo, come 2..4, dove * rappresenta un valore illimitato 1 equivale a 1..1 * è un’abbreviazione per 0..* Se una proprietà ha più valori, è preferibile indicare il suo nome in forma plurale Gli elementi di una molteplicità a più valori formano un insieme; se ciò non è accettabile, è necessario dare un’indicazione diversa come {ordered}, {nonunique} o {bag} Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 7 Molteplicità delle proprietà Elementi Sintassi {ordered} Vincoli circa una molteplicità {nonunique} {bag} a più valori {hierarchy} {dag} Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi Semantica Possono coesistere anche più vincoli (purché matematicamente consistenti) {ordered}: esiste un ordinamento fra gli elementi {nonunique}: gli elementi possono comparire più volte {bag}: gli elementi formano un multinsieme {hierarchy}: gli elementi formano una gerarchia {dag}: gli elementi formano un DAG (grafo orientato aciclico) 8 Verbo come nome di associazione Possiede 0..1 Imprenditore Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi * Azienda 9 Diagrammi delle classi: concetti essenziali (cont.) Elementi Sintassi Operazione visibilità nome (lista-parametri): tipo-ritornato {stringaproprietà} dove nome è una stringa, lista-parametri è una serie di parametri, ciascuno specificato mediante un elemento direzione nome: tipo = valore-di-default e separato dal successivo mediante una virgola (la direzione può assumere i valori in, out, inout, se manca si presume sia in), stringa-proprietà indica i valori delle proprietà dell’operazione, cioè query, modificatore, get e set Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi Semantica Azione che una classe sa come eseguire; se un’operazione i) non modifica lo stato del sistema e ii) ritorna dei valori è una query, se un’operazione i) modifica lo stato osservabile del sistema e ii) non ritorna valori è un modificatore; un metodo get è una particolare query che restituisce il valore di un attributo e non fa nient’altro; un metodo set è un particolare modificatore che assegna il valore a esso passato a un attributo e non fa nient’altro Una convenzione comune è cercare di scrivere modificatori che non restituiscano mai valori 10 Operazioni Quelle che manipolano le proprietà della classe di solito si possono dedurre, per cui non sono incluse nel diagramma Nei modelli concettuali, dovrebbero indicare le principali responsabilità della classe, magari facendo riferimento a una carta CRC Corrispondono alla dichiarazione di una procedura e, quindi, si distinguono (sottilmente) dai metodi, che invece corrispondono al corpo della procedura le due cose sono diverse in presenza di polimorfismo Responsabilità di una classe = obbligo che la classe si assume nello svolgere un servizio. Fa parte del contratto che essa stipula con le altre classi Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 11 Concetti essenziali (cont.) Toolbar # currentSelection: Tool # toolCount: Integer + pickItem(i: Integer) + addTool(t: Tool) + removeTool(i: Integer) + getTool(): Tool # checkOrphans() - compact() Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 12 Concetti essenziali (cont.) Elementi Sintassi Generalizzazione Freccia con testa vuota e uno o più capi: la testa termina nella superclasse, i capi si dipartono ciascuno da una sottoclasse Nota Testo che segue due trattini –all'interno di un elemento del diagramma, oppure contenuto in una scatola con “orecchietta”, eventualmente collegata all’elemento a cui si riferisce mediante una linea tratteggiata Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi Semantica Se due o più classi sono diverse ma mostrano anche molte somiglianze, queste si possono raccogliere in una superclasse (relazione IS-A) Commento aggiuntivo Una o più note possono apparire in qualsiasi tipo di diagramma UML Una convenzione comune prevede di mettere un cerchietto vuoto all’estremità della linea tratteggiata, per meglio collegarla all’elemento a cui si riferisce 13 Concetti essenziali (cont.) 1 * Window associazione Shape Ogni forma geometrica visualizzabile in una finestra move ( ) resize ( ) display ( ) generalizzazione Rectangle Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi Circle 14 Prospettive e diagrammi delle classi Prospettiva Concettuale (da adottarsi per realizzare il modello di dominio nella fase di elaborazione del RUP) Interpretazione classe = concetto nella mente del cliente ( il diagramma diventa il linguaggio dell’interlocutore) associazione = relazione fra concetti (la navigabilità non è utile) attributo = proprietà degli oggetti della classe, notazione alternativa rispetto all’associazione operazione = una delle responsabilità principali della classe generalizzazione: qualsiasi cosa si possa dire del supertipo (in termini di associazioni, attributi e operazioni), si può dire anche dei sottotipi N.B. Le responsabilità di una classe possono essere descritte ciascuna mediante una nota inserita entro il riquadro della classe Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 15 Prospettive e diagrammi delle classi (cont.) Prospettiva Interpretazione classe = tipo (un tipo è l’interfaccia – o parte di essa - di una o Specifica più classi “fisiche”, una classe “fisica” può implementare più tipi) associazione = responsabilità (indipendenti dalla struttura dati) ovvero, per ogni relazione R fra due classi C1 e C2 con navigabilità C1C2, esistenza di un’interfaccia (implicita, che, a livello implementativo può essere realizzata in vario modo) che dato un elemento di C1, determina tutti gli elementi di C2 che partecipano a R effettua l’aggiornamento della relazione Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 16 Prospettive e diagrammi delle classi (cont.) Prospettiva Interpretazione attributo = responsabilità: esiste un’interfaccia (implicita) che Specifica (cont.) consente di impostare il valore dell’attributo di un oggetto restituisce il valore dell’attributo operazione = metodo pubblico generalizzazione = creazione di sottotipi (o ereditarietà di interfacce): l’interfaccia del sottotipo deve includere tutti gli elementi dell’interfaccia del supertipo (si dice che deve essere conforme all’interfaccia del supertipo); deve essere possibile sostituire un’istanza della sottoclasse all’interno di qualsiasi pezzo di codice che preveda l’esistenza di un’istanza della superclasse e tutto deve continuare a funzionare N.B. la creazione di sottoclassi “fisiche” è solo uno dei modi per implementare la creazione di sottotipi, un altro è la delega Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 17 Prospettive e diagrammi delle classi (cont.) Prospettiva Interpretazione Implementazione classe = classe “fisica” associazione R (C1C2)= dato un qualsiasi oggetto di C1 esistono specifici meccanismi di collegamento verso gli oggetti corrispondenti di C2 la navigabilità può essere diversa da quella di specifica attributo = campo generalizzazione: la sottoclasse eredita tutti i metodi e i campi della superclasse e può ridefinirne le funzioni (eredità di implementazione) Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 18 Dipendenza Un elemento (detto client) di un diagramma (di qualsiasi tipo) dipende da un altro (detto supplier, cioè fornitore) se la modifica della definizione del secondo può causare un cambiamento del primo Una classe C1 dipende da un classe C2 se invoca operazioni di C2 (anche solo un costruttore), e/o un suo campo è di tipo C2, e/o un parametro di una sua operazione è di tipo C2, e/o accede ai campi di C2 Man mano che il sistema cresce, il problema del controllo delle dipendenze aumenta Specificare le dipendenze rende espliciti gli effetti a catena del cambiamento di un elemento il sistema è più facilmente modificabile Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 19 Concetti essenziali (cont.) Elementi Sintassi Dipendenza Freccia con linea tratteggiata e punta biforcuta Vincolo Semantica La modifica della classe destinazione (fornitore) può causare un cambiamento della classe sorgente (client) Può legare pure una classe e un interface (o una classe astratta), dove se l’interface (o la classe astratta) dovesse cambiare, anche la classe potrebbe cambiare Descrizione in linguaggio OCL (Object Constraint Language) fa naturale racchiusa fra parte di UML ed è basato sul calcolo parentesi graffe, oppure dei predicati descrizione in OCL Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 20 Dipendenza (cont.) In generale non è una relazione transitiva (ad es. se C1 dipende da C2 che dipende da C3, la relazione non è transitiva se il cambiamento di C2 – conseguente a un qualsiasi cambiamento di C3 – riguarda solo il corpo delle operazioni di C2) Molte relazioni UML implicano una dipendenza, ad es. in un’associazione navigabile C1C2, C1 dipende da C2 una sottoclasse dipende dalla superclasse (ma non viceversa) Dato il codice di un sistema, le dipendenze in esso contenute sono rilevabili automaticamente da uno strumento CASE Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 21 Dipendenza e progettazione client fornitore Classe A Finestra -- classe di -- presentazione Impiegato -- classe di dominio Classe B dipendenza Regole di progettazione Separare presentazione (cioè le classi relative all’interfaccia) dalla logica del dominio (cioè le classi che incarnano il comportamento fondamentale del sistema), con la prima dipendente dalla seconda ma non viceversa Minimizzare le dipendenze Evitare i cicli di dipendenze, possibilmente fra classi dello stesso package e assolutamente fra classi di package diversi Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 22 Concetti avanzati Elementi Sintassi Parola Parola racchiusa fra chiave virgolette uncinate Es. «interface» Semantica Rappresenta un costrutto creato dall’utente perché non compreso in UML ma è simile a un altro che vi è compreso Parola chiave stereotipo Stereotipo = meccanismo di estensione di UML che agisce sul metamodello Profilo = estensione di una parte di UML ottenuta per mezzo di un gruppo coerente di stereotipi, adattando così il linguaggio a un particolare dominio (ad es. la modellazione di business) Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 23 Concetti avanzati (cont.) Elementi Operazione e attributo statici Sintassi Semantica Come operazione e Metodi e attributi con campo attributo d’istanza ma d’azione di classe (anziché d’istanza) sottolineati Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 24 Concetti avanzati (cont.) Elementi Sintassi Aggregazione Freccia che termina sulla classe “parte” con una punta biforcuta; all’altra estremità si diparte dalla classe “tutto” con un rombo vuoto; su entrambe le estremità è obbligatoria la molteplicità Composizione Come nell’aggregazione ma il rombo è pieno La molteplicità sul lato della classe composta è necessariamente 0..1 oppure 1 Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi Semantica Generica relazione “parte-di” (o HAS-A), difficilmente distinguibile dall’associazione Inclusa in UML senza definirne la semantica persone diverse la usano con significati diversi Varietà più forte dell’aggregazione: l’oggetto componente può appartenere a un solo oggetto composto (regola di non condivisione) la cancellazione dell’oggetto composto si propaga a tutti gli oggetti componenti 25 Aggregazione e composizione Poligono 1..* Aggregazione Vincolo Composizione 1 1 Riempimento {ordered} 3..* Punto Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi colore tessitura 26 Concetti avanzati (cont.) Elementi Sintassi Proprietà Il nome derivata dell’associazione o dell’attributo è preceduto da una barra (/) Semantica È un attributo/associazione rappresentato esplicitamente anche se può essere derivato a partire da altri attributi/associazioni dal punto di vista concettuale, indica un vincolo tra valori e può essere usato per ricordarsi di chiedere conferma agli esperti circa una presunta derivabilità dal punto di vista della specifica, indica un vincolo tra valori (non cosa viene direttamente memorizzato e cosa viene derivato) dal punto di vista implementativo indica i campi usati come cache per motivi di efficienza Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 27 Concetti avanzati (cont.) Periodo di tempo inizio: Data fine: Data /durata: Quantità daInizioAnno() Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi Attributo derivato Operazione di classe 28 Concetti avanzati (cont.) Elementi Classe e operazione astratti Sintassi Nome in corsivo + eventuale vincolo Semantica Operazione astratta = operazione priva di implementazione {abstract} Classe astratta = classe non istanziabile direttamente Interface Uso della parola chiave Classe priva di implementazione «interface» entro la scatola della classe Realizzazione Freccia con linea Relazione fra una classe (concreta (o tratteggiata e punta o astratta) che implementa implementazione) vuota diretta dalla un’interface e l’interface stessa classe all’interface a livello di specifica, realizzazione e subtyping sono indistinguibili Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 29 Classi astratte e interface Dipendenza (richiede la conoscenza dell’interface) {abstract} InputStream Editor testuale Finestra {abstract} inPrimoPiano() sulloSfondo() Finestra Windows inPrimoPiano() sulloSfondo() «interface» DataInput Generalizzazione DataInputStream Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi Realizzazione (fornisce un’implementazione all’interface) 30 Interface: rappresentazione compatta implementazione List Ordine ElementiDellaLinea [*] ListaConcreta dipendenza Collection interface Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 31 Concetti avanzati (cont.) Elementi Sintassi Associazione Dal riquadro della qualificata classe sorgente fuoriesce un riquadro più piccolo, contenente il nome del qualificatore, da cui si diparte la linea continua che rappresenta l’associazione; tale linea termina con una punta che indica la navigabilità Semantica A ogni istanza della classe sorgente corrispondono gli elementi di un array associativo/tabella hash/mappa/dizionario indicizzati dal valore di una chiave (il qualificatore) La molteplicità dell’associazione qualificata va considerata nel contesto del qualificatore (ovvero indica quante istanze della classe destinazione corrispondono a un singolo valore/istanza del qualificatore) Nella modellazione concettuale rappresenta un vincolo Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 32 Associazione qualificata 0..1 Ordine Prodotto Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi LineaDOrdine Quantita: Numero 33 Classificazione Classificazione = relazione tra un oggetto e il suo tipo; può essere singola: un oggetto appartiene a un solo tipo multipla: un oggetto può essere descritto da più tipi Classificazione multipla ereditarietà multipla Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 34 Concetti avanzati (cont.) Elementi Sintassi Classificazione Come la generalizzazione, ma etichettata multipla con il nome di un insieme di generalizzazione (subtyping) (discriminante), che indica la base della classificazione; il discriminante è accompagnato dal vincolo {complete} se ogni istanza della superclasse deve essere anche un’istanza di uno dei sottotipi del gruppo così contraddistinto; ogni combinazione fra sottotipi aventi discriminante distinto deve essere legale; tutti i sottotipi aventi lo stesso discriminante (gruppo di sottotipi) devono essere disgiunti Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi Semantica Associa a una classe (la superclasse) più sottotipi ortogonali (le sottoclassi) utile a livello di modellazione concettuale 35 Concetti avanzati (cont.) Elementi Sintassi Classificazione Come la classificazione multipla dinamica ma l’insieme di generalizzazione è accompagnato dalla parola chiave «dynamic» Semantica Consente agli oggetti di cambiare tipo all’interno di una struttura di sottotipi utile a livello di modellazione concettuale Suggerimento: usare sempre una classificazione singola e statica (che corrisponde all’uso di un singolo anonimo insieme di generalizzazione) Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 36 Classificazione Insieme di generalizzazione (discriminante) Vincolo Femmina sesso {complete} Programmatore impiego «dynamic» Responsabile di progetto Persona Maschio contratto «dynamic» Dipendente Collaboratore Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi Commerciale Classificazione dinamica 37 Concetti avanzati (cont.) Elementi Sintassi Classe di Classe collegata a una associazione linea di associazione mediante una linea tratteggiata Classe Classe con un riquadro parametrica tratteggiato sull’angolo (o template) superiore destro, contenente i parametri (tipi di dati) della classe, che possono essere più d’uno Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi Semantica Aggiunge un vincolo extra: ci può essere solo un’istanza della classe di associazione tra ogni coppia di oggetti associati Usata per lo più per definire collezioni Raramente utile in fase di modellazione concettuale; da usare in fase di specifica e implementazione solo se effettivamente supportata dal linguaggio di programmazione (è inclusa con il nome di classe generica in Java e C#) 38 Classe di associazione Associazione derivata Azienda 0..1 1 appartiene /impiegato 1..* Datore di lavoro 1..* Dipartimento 0..1 1..* Persona Impiego Una persona può avere un singolo impiego nell’ambito del dipartimento in cui lavora descrizione dataAssunzione salario Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi Classe di associazione 39 Promozione di una classe di associazione Dipartimento 0..* 1..* Persona Impiego Una persona può avere un singolo impiego nell’ambito di ciascun dipartimento descrizione dataAssunzione salario Ma il significato è diverso rispetto a quello del diagramma sottostante, usato soprattutto per rappresentare relazioni temporali (storiche) Impiego Dipartimento 1 1..* descrizione dataAssunzione salario 0..* Persona 1 Una persona può avere più impieghi nell’ambito dello stesso dipartimento Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 40 Concetti avanzati (cont.) Elementi Sintassi Derivazione Dalla classe derivata si diparte una freccia di generalizzazione diretta alla classe template; la freccia è affiancata dalla parola chiave «bind» seguita dall’elenco dei nomi dei tipi usati come parametri fra parentesi angolari (<>), ciascuno preceduto da nome_parametro :: Es. <T::Dipendente>, oppure La classe derivata contiene il nome della classe template, la parola chiave «bind» seguita dall’elenco dei nomi dei tipi usati, nello stesso formato di cui al punto precedente Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi Semantica Una classe derivata rappresenta un uso particolare della classe parametrica, corrispondente a una specifica configurazione dei valori dei parametri La classe derivata non è una sottoclasse: infatti non è lecito aggiungerle caratteristiche rispetto a quelle del template 41 Classi parametriche (template) List Parametro Item Classe parametrica + insert(in i: Item) + first(): Item + next(): Item «bind» <Item::Integer> ListOfInt Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi Elemento legato 42 Diagramma degli oggetti (o delle istanze) È la fotografia degli oggetti che compongono un sistema sw in un dato momento È utile quando le connessioni fra oggetti sono complicate Elementi Oggetto Sintassi Scatola suddivisa in due parti, entrambe dal contenuto opzionale, la prima contenente nome-istanza : nome-classe (può comparire o solo nome-istanza o solo : nome-classe), la seconda zero, uno o più nome-attributo = “valore” (l’elenco degli attributi non deve essere necessariamente esaustivo) Collegamento Linea continua fra due oggetti, eventualmente etichettata con nome-associazione Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi Semantica Istanza di una classe Istanza di relazione fra due classi 43 Diagramma degli oggetti (cont.) Gruppo * luogo 0..1 padre Persona :Organizzazione luogo = “Milano” Organizzazione padre :Organizzazione :Organizzazione luogo = “Roma” luogo = “Genova” :Persona :Persona luogo = “Roma” luogo = “Bologna” Marina Zanella - Ingegneria del Software – UML: Diagrammi delle classi 44