Elenco di controllo: Classe di progettazione |
|
 |
Questo elenco di controllo assiste nel verificare che la Classe di progettazione sia modellata correttamente. |
|
Relazioni
Descrizione principale
Voci elenchi di operazioni
Generale
-
Il nome della classe riflette chiaramente il ruolo assunto.
-
La descrizione della classe esprime chiaramente lo scopo della classe.
-
La classe rappresenta una singola astrazione chiaramente definita.
-
Gli attributi e le operazioni della classe sono tutte essenziali per l'adempimento delle responsabilità della
classe.
-
Ogni classe rappresenta un piccolo insieme coerente e univoco di responsabilità.
-
Le responsabilità della classe sono state chiaramente definite, dichiarate e correlate allo scopo della classe.
-
Ogni classe è relativamente autonoma e accoppiata liberamente ad altre classi.
-
Le responsabilità della classe sono a un livello costante di astrazione, ad es., le responsabilità ad alto
livello (livello applicazione) e a basso livello (livello implementazione) non sono miste.
-
Classi nella stessa gerarchia di ereditarietà possiedono attributi di classe, operazioni e relazioni univoci
(ad es., ereditano tutti gli attributi, le operazioni e le relazioni comuni.
-
Il ciclo di vita completo di un'istanza della classe è stato giustificato. Ogni oggetto viene creato,
utilizzato o rimosso da uno o più realizzazioni di casi d'uso.
-
La classe soddisfa i requisiti comportamentali stabiliti dalle realizzazioni del caso d'uso.
-
Tutti i requisiti della classe nelle specifiche sono soddisfatti.
-
Le richieste nella classe, come riportate nella descrizione della classe e dagli oggetti nei diagrammi
sequenza, sono coerenti con la macchina a stati della classe stessa.
-
Tutte le responsabilità della classe sono correlate, in modo che non sia possibile per la classe di esistere in
un sistema dove solo parte delle sue responsabilità vengono utilizzate.
-
Non esistono due classi cui è stato assegnato essenzialmente lo stesso scopo.
|
Generalizzazione/Specializzazione
-
La gerarchia della generalizzazione è equilibrata, in modo che non siano presenti classi per cui la gerarchia
sia insolitamente piatta o profonda.
-
Comunalità ovvie sono riportate nella gerarchia di ereditarietà.
-
Non esistono superclassi che siano il risultato di unioni di attributi di sottoclassi.
-
Non esistono classi astratte intermedie nella gerarchia di ereditarietà con proprietà ortogonali, esempi
includono sottoclassi duplicate su entrambi i lati della struttura ad albero dell'ereditarietà.
-
L'ereditarietà viene utilizzata per catturare astrazioni di progettazione comuni, non per valutazione su
implementazioni, ad esempio per riutilizzare frammenti di codice o la struttura della classe.
|
Convenzioni sui nomi
-
I nomi delle classi indicano lo scopo.
-
I nomi delle classi seguono le convenzioni sui nomi specificate nelle linee guida del progetto.
|
Operazioni
-
Il nome di ciascuna operazione è descrittivo e comprensibile.
-
La macchina a stati e le operazioni sono coerenti.
-
La macchina a stati e le operazioni descrivono completamente la funzionalità della classe.
-
I parametri di ciascuna operazione sono corretti in termini di numero, nome e tipo.
-
Le specifiche dell'implementazione per ciascuna operazione, ove definite, sono corrette.
-
La firma dell'operazione è conforme con gli standard del linguaggio di programmazione di destinazione.
-
Ciascuna operazione viene utilizzata da almeno una realizzazione caso d'uso.
|
Attributi
-
Tutte le relazioni della classe sono richieste per supportare alcune operazioni della classe.
-
Ogni attributo rappresenta un elemento concettuale unico.
-
Il nome di ogni attributo è descrittivo ed esprime le informazioni che memorizza.
|
Relazioni
-
I nomi del ruolo di aggregazioni e associazioni descrive la relazione tra le classi associanti e associate.
-
Le molteplicità delle relazioni sono corrette.
|
Macchine a stati
-
La macchina a stati è la più semplice possibile pur esprimendo la funzionalità richiesta.
-
La macchina a stati non contiene stati superflui o transizioni.
-
La macchina a stati ha un contesto chiaro.
-
Tutti gli oggetti di riferimento sono visibili per l'oggetto di inclusione.
-
La macchina a stati è efficiente, la cui funzionalità viene eseguita in equilibrio perfetto di tempo e risorse,
in conformità a quanto definito dalle azioni che trasmette.
-
La macchina a stati è comprensibile.
-
-
I nomi dello stato e della transizione sono comprensibili nel contesto del dominio del sistema.
-
I nomi dello stato indicano ciò che si attende e ciò che accade, invece di ciò che è accaduto.
-
I nomi dello stato e della transizione univoci all'interno della macchina a stati, sebbene ciò non sia
un requisito rigoroso, l'assegnazione di nomi univoci aiuta nel debbuging.
-
Raggruppamenti logici di stati sono contenuti in stati compositi.
-
Gli stati compositi sono stati utilizzati con efficacia per ridurre la complessità?
-
Le etichette di transizione riflettono la causa sottostante della transizione.
-
Non esistono frammenti di codice nelle transizioni di stato superiori a 25 righe di dettaglio; invece,
le funzioni sono state utilizzate con efficacia per ridurre la complessità del codice di transizione.
-
La nidificazione della macchina a stati è stata esaminata per garantire che la nidificazione profonda
non ha raggiunge una profondità tale da renderla incomprensibile; uno o due livelli di sottstati sono
in genere sufficienti per comportamenti complessi.
-
Sono state utilizzate classi attive invece dei sottostati concorrenti; le classi attive sono quasi sempre
un'alternativa migliore e più comprensibile dei sottostati concorrenti.
-
Sono state utilizzate capsule per rappresentare i thread logici per il controllo nei sistemi real-time.
-
Gli stati di errore o di manutenzione sono stati giustificati.
-
Sono stati utilizzati sottostati invece di variabili di stato estese; nulla prova che la verifica della
condizione di riferimento della transizione possa determinare quale stato della stessa debba verificarsi.
-
La macchina a stati non assomiglia a un diagramma di flusso.
-
La macchina a stati non è stata troppo scomposta, includendo macchine a stati con un singolo sottostato. Nei
casi in cui il sottostato nidificato è un segnaposto per un progetto o sottoclassificazione futura, può essere
utilizzato temporaneamente, purché la scelta sia consapevole.
|
|
© Copyright IBM Corp. 1987, 2006. Tutti i diritti riservati.
|
|