Porfirio Tramontana » 8.Class diagram – parte terza

Livelli di dettaglio dei Class Diagram

I diagrammi UML possono essere creati in diverse fasi del ciclo di vita, con diversi scopi e livelli di dettaglio.

• System domain model (Modello Concettuale dei dati):
  • Modello del dominio dei dati del problema;
  • Descrive aspetti del dominio del problema che saranno presenti nel sistema (i dati di interesse);
  • A volte si aggiungono a questo modello anche le responsabilità.
• System model:
  • Include anche classi che saranno usate per costruire
    • Le interfacce utente;
    • Le interazioni con altri sistemi, database, etc.;
    • Classi di utilità;
    • …

Un processo di astrazione di un modello di dominio

1. Identifica un primo insieme di classi candidate;
2. Aggiungi associazioni ed attributi a queste classi;
3. Trova le generalizzazioni;
4. Trova le principali responsabilità di ogni classe;
5. In base alle responsabilità decidi sulle operazioni;
6. Itera il processo finchè il modello ottenuto è soddisfacente.

Identificare le classi

Quando si sviluppa un domain model si tende a scoprire classi che fanno parte del dominio.
Nel lavorare all’interfaccia utente o all’architettura, si tende ad inventare classi:

• Necessarie a risolvere un problema di design;
• Si possono inventare classi anche per il domain model!

Ad una classe dovrebbe corrispondere un’entità del dominio del problema…

• In pratica, bisogna applicare i concetti generali di modellazione Object Oriented.

Come è fatta una buona classe di analisi?

Il suo nome ne rispecchia l’intento.

È una astrazione ben definita che modella un elemento del dominio del problema.

Ha un insieme ridotto e ben definito di responsabilità.

Ha una massima coesione interna.

Una classe è tanto più coesa quanto più riesce ad assolvere da sola alle proprie responsabilità.

Analisi dei nomi

Semplice tecnica per scoprire le classi del dominio:

• Analizzare la documentazione di partenza, come la descrizione dei requisiti;
• Estrarre nomi e predicati nominali (aggettivi di nomi);
• Eliminare nomi che:
  • Sono ridondanti (rappresentano la stessa classe)
  • Rappresentano istanze e non classi
  • Sono vaghi, troppo generici
  • Corrispondono a classi che non sono necessarie al livello considerato;
• Fare attenzioni a classi nel domain model che rappresentano tipi di utente o altri attori (servono davvero?).

Identificare associazioni ed attributi

Parti con le classi ritenute centrali ed importanti.

Stabilisci i dati ovvi e chiari che esse contengono e le loro relazioni con altre classi.

Procedi con le classi meno importanti.

Evita di aggiungere troppi attributi ed associazioni ad una classe.

Un sistema è più semplice se manipola meno informazioni.
Le classi devono avere poche dipendenze da altre classi.

Suggerimenti per trovare e specificare associazioni valide

Una associazione dovrebbe esistere se una classe:

• possiede
• controlla
• è collegata a
• si riferisce a
• è parte di
• ha come parti
• è membro di oppure
• ha come membri qualche altra classe del modello

Specificare le molteplicità da entrambi i lati.

Assegnare un nome chiaro all’associazione.

Identificare gli attributi

Cercare le informazioni che devono essere conservate per ciascuna classe;

È possibile che nomi che sono stati scartati come classi, possano ora essere considerati attributi;

Un attributo dovrebbe in genere contenere un solo valore;

• Es. stringa, numerico

Suggerimenti per identificare e specificare attributi validi

È bene non avere molti attributi duplicati. Se un sottoinsieme degli attributi di una classe forma un gruppo coerente, crea una classe distinta per questi attributi.

Identificare generalizzazioni e interfacce

Due modi per trovare le generalizzazioni:

1. bottom-up
   1. Raggruppo classi simili creando una nuova superclasse;
2. top-down
   1. Cerco prima le classi più generali, e poi specializzo.

Crea un interfaccia, invece di una superclasse se:

• Le classi sono molto diverse fra loro, tranne che per poche operazioni in comune;
• Una o più classi hanno già le loro superclassi;
• Potrebbero essere disponibili diverse implementazioni della stessa classe.

Assegnare le Responsabilità alle classi

Una responsabilità è un qualcosa che è richiesto al sistema.

La responsabilità di ogni requisito funzionale deve essere attribuita ad una delle classi, anche se tale requisito potrà essere svolto mediante una collaborazione fra più classi.

Tutte le responsabilità di una classe dovrebbero essere chiaramente correlate.
Se una classe ha troppe responsabilità, valutare l’ipotesi di dividerla in più classi.
Se una classe non ha responsabilità, probabilmente è inutile.
Quando una responsabilità non può essere attribuita a nessuna delle classi. esistenti, dovrebbe essere creata una nuova classe.

Per stabilire le responsabilità:

• Svolgere l’analisi dei casi d’uso;
• Cercare verbi e nomi che descrivono azioni nella descrizione del sistema.

Categorie di responsabilità

• Set e get dei valori degli attributi;
• Creare ed inizializzare nuove istanze;
• Prelevare da o memorizzare dati in una memoria persistente;
• Distruggere istanze;
• Aggiungere e cancellare istanze di associazioni;
• Copiare, convertire, trasformare, trasmettere o fornire in output dati;
• Calcolare risultati numerici;
• Navigare e cercare dati di particolari istanze;
• Altro lavoro specifico
  • Alcune di queste responsabilità sono considerate predefinite nei diagrammi di più alto livello e, pertanto, non sono indicate.

CRC cards

CRC sta per Class Responsibility Collaboration.
Per ogni classe identificata, porre il nome della classe su una scheda (Card). Man mano che vengono individuati attributi e responsabilità, elencarli sulle Card.
Sistemare le card su una lavagna per creare il Class diagram. Disegnare le linee corrispondenti ad associazioni e generalizzazioni.

• L’utilizzo delle card serve per imporre, quanto meno psicologicamente, all’analista di non realizzare classi con un numero troppo elevato di attributi e metodi → Se la card è piena allora probabilmente bisogna dividere la classe in due o più classi più semplici.

Identificare le operazioni

Le operazioni saranno necessarie a realizzare le responsabilità di ciascuna classe.

Ci saranno in genere diverse operazioni per realizzare ogni responsabilità, ma una in particolare avrà l’impegno della responsabilità.

Le principali operazioni che implementano una responsabilità sono normalmente dichiarate public.

Altri metodi che collaborano a realizzare una responsabilità devono essere dichiarate private se possibile.

Esempio: azienda alimentare

Una azienda produttrice di prodotti alimentari, vuole organizzare un sistema informativo aziendale. Tutti gli utenti dell’applicazione devono essere in grado di visualizzare informazioni relative al catalogo dei prodotti. Inoltre i dipendenti devono essere in grado di accedere ad informazioni relative alle loro mansioni.

I prodotti sono organizzati in linee di prodotto che accomunano prodotti dello stesso tipo: ad esempio, due linee possono essere pasta e sughi. I prodotti possono essere confezionati in diversi stabilimenti. I dipendenti si suddividono in diverse categorie: i manager, che sono responsabili di una o più linee di produzione (ogni linea é però gestita esattamente da tre manager, per assicurare una gestione equa), i supervisori della produzione che sono responsabili di tutti i prodotti di una specifica linea in uno specifico stabilimento, e gli operai che lavorano su uno specifico prodotto in un determinato stabilimento.

L’applicazione deve consentire ai manager di accedere alle informazioni relative ai dipendenti di cui sono responsabili, e a tutti di accedere alle informazioni sui prodotti.

Ricerca classi

In chiaro: Ricerca classi

Ricerca associazioni ed attributi

In verde: Ricerca associazioni ed attributi

Ricerca generalizzazioni

In blu: Ricerca generalizzazioni

Ricerca e assegnazione di responsabilità

In grigio: Ricerca e assegnazione di responsabilità

System Domain Model

Esempio videogioco

Ricerca classi

In celeste "ricerca e assegnazioni di responsabilità"

Ricerca associazioni ed attributi

In verde "ricerca associazioni e attributi"

Ricerca generalizzazioni

In blu "ricerca generalizzazioni"

Ricerca e assegnazione di responsabilità

In grigio "ricerca e assegnazione di responsabilità"

Soluzioni alternative

Per poter vendere anche azioni separatamente dagli stock (ad esempio rivendere una per una le azioni comprate in stock) è necessario mettere una nuova classe associativa Vendita, tra Giocatore e SocietàQuotata, con attributo QuantitàVenduta.

Una soluzione equivalente a quella proposta la si poteva ottenere considerando una classe SocietàMonitorata come specializzazione di SocietàQuotata, associata quindi soltanto a Giocatore e a GiornoMonitorato.

MonitoraggioAzione poteva fondersi con GiornoMonitorato, dato che non ci sono specifici attributi/associazioni/responsabilità che rendano necessaria MonitoraggioAzione (in questo caso la responsabilità Monitora viene risolta completamente da Giocatore.

Il Bilancio per giocatore e per squadra non è riportato come attributo perchè è calcolabile (e deve sicuramente essere calcolato nell’ambito di Premio.Assegna. In fase di raffinamento, si può inserire un’operazione CalcolaBilancio in Squadra e in Giocatore.