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.