Dopo aver identificato i requisiti e aver creato un Modello di dominio, si aggiungano i metodi alle classi appropriate, e si definiscano i messaggi tra gli oggetti per soddisfare i requisiti.
Con OO intenderemo: Object Oriented (orientato agli oggetti).
Il decidere quali metodi appartengono a chi e come devono interagire gli oggetti ha delle conseguenze, e pertanto queste scelte vanno fatte con serietà.
I pattern sono delle situazioni che si verificano spesso e a cui può essere dato un nome, ed essi possono essere spiegati e appresi.
UML non insegna a pensare a oggetti...
Conoscere UML, la sua sintassi e il modo di utilizzarlo non insegna a pensare a oggetti. UML è talvolta descritto come "uno strumento di progettazione". ma questo non è del tutto corretto.
Lo strumento critico della progettazione per lo sviluppo software è una mente ben istruita sui principi della progettazione.
Progettazione a oggetti: esempi di input, attività e output...
Questo paragrafo riassume un quadro generale di esempio per la progettazione in un metodo iterativo (UP).
- Che cosa è stato fatto? Attività precedenti (workshop) e relativi elaborati.
- Come sono correlate le cose? Influenza degli elaborati precedenti (per esempio i casi d'uso) sulla progettazione OO.
- Quanta modellazione fare per la progettazione, e come?
- Qual è l'output?
Input della progettazione...
Si supponga di essere sviluppatori del team che lavora al POS NextGen e che il seguente scenario sia vero.
| Attività | Descrizione |
|---|---|
| Il primo workshop dei requisiti della durata di due giorni è finito. | Il chief architect e il responsabile dell'organizzazione concordano di implementare e testare alcuni scenari del caso d'uso Elabora Vendita nella prima iterazione timeboxed di tre settimane. |
| Tre dei venti casi d'uso, quelli più significativi (rischio architettura e elevato business) sono stati analizzati nel dettaglio, compreso, ovviamente, Elabora Vendita | Altri elaborati sono stati iniziati: Specifiche supplementari, Glossario,, Modello di dominio. |
| Esperimenti di programmazione hanno risolto le domande tecniche più eclatanti (per i monitor touch screen va bene Java Swing?) | Il chief architect ha disegnato alcune idee per l'architettura logica su larga scala, utilizzando i diagrammi dei package di UML. Ciò fa parte del Modello di progetto di UP. |
| Il testo dei casi d'uso definisce il comportamento visibile che gli oggetti software devono in definitiva supportare; gli oggetti vengono progettati per "realizzare" (implementare) i casi d'uso. In UP, questa progettazione OO è chiamata proprio realizzazione dei casi d'uso. | Le specifiche supplementari definiscono gli obiettivi non funzionali, che gli oggetti devono soddisfare, per esempio le prestazioni. |
| I diagrammi di sequenza di sistema identificano i messaggi per le operazioni di sistema. | Il glossario chiarisce i dettagli dei parametri o dei dati che vengono dallo strato UI, i dati che vengono passati alla base di dati, e la logica specifica per ciascun elemento e i requisiti di validazione, come i formati legali e la validazione per i codici UPC dei prodotti. |
| I contratti delle operazioni possono essere complementari al testo dei casi d'uso per chiarire che cosa devono compiere gli oggetti software in un'operazione di sistema. Le post-condizioni definiscono in modo dettagliato i risultati da ottenere. | Il Modello di dominio suggerisce alcuni nomi e attributi degli oggetti software di dominio nello strato del dominio dell'architettura software. |
Quali sono le attività della progettazione a oggetti...
Siamo pronti a toglierci il cappello da analista e indossare quello quello da progettista-modellatore.
Dato uno o più di questi input (tabella sopra), gli sviluppatori possono:
- iniziare immediatamente a codificare,
- iniziare con un po' di modellazione UML per la progettazione a oggetti,
- iniziare con un'altra tecnica di modellazione (schede CRC).
Nel caso di UML, il punto cruciale non è UML in sé, ma la modellazione visuale, ovvero usare un linguaggio che consente di esaminare le scelte di progetto in modo più visuale di quanto non si possa fare con il solo testo. Quindi si disegnano sia i diagrammi di interazione che i diagrammi delle classi, tra loro complementari, durante un solo giorno di modellazione. La cosa più importante è che, durante le attività di disegno (e codifica), vengano applicati i vari principi di progettazione OO, come i pattern GRASP e i design pattern Gang-of-Four (GoF). L'approccio complessi al fare la modellazione per la progettazione OO si baserà su una metafora: la progettazione è guidata dalle responsabilità (RDD) delle classi.
Durante il disegno di UML si disegnano i modelli soprattutto allo scopo di comprendere e comunicare, non di documentare. Naturalmente ci si aspetta che alcuni diagrammi UML costituiscano un input utile per la definizione del codice.
Il martedì della prima settimana (delle tre settimane timeboxed), cioè ancora presto, i membri del team interrompono la modellazione e indossano il cappello da programmatore per evitare una mentalità a cascata e perdere troppo tempo nella modellazione.
Output della progettazione ad oggetti...
L'immagine sopra mostra alcuni input e le rispettive relazioni con l'output, costituito da diagrammi di interazione e diagrammi delle classi UML. Si noti che durante la progettazione è possibile fare riferimento a questi input, prodotti dall'analisi; per esempio, rileggere il testo dei casi d'uso o i contratti delle operazioni, guardare il modello di dominio e rivedere le Specifiche Supplementari.
Cosa viene creato nel corso della giornata dedicata alla modellazione?
- Specificatamente per le progettazione ad oggetti: diagrammi UML di interazione, diagrammi delle classi e dei package, per le parti difficili che è opportuno esaminare prima delle codifica.
- Abbozzi e prototipi dell'interfaccia utente.
- Modelli della base di dati.
Progettazione guidata dalla responsabilità...
Un modo comune di pensare alla progettazione di oggetti software è in termini di responsabilità, ruoli e collaborazioni. Questi aspetti fanno parte di un approccio più ampio chiamato progettazione guidata dalle responsabilità (RDD: Responsability-Driven Development).
Nella RDD gli oggetti software sono pensati come dotati di responsabilità: abbiamo due tipi di responsabilità.
| Responsabilità di fare | Responsabilità di conoscere |
|---|---|
| un oggetto fa qualcosa come creare un oggetto o eseguire un calcolo | un oggetto conosce i propri dati privati incapsulati |
| un oggetto chiede ad altri oggetti di eseguire azioni | un oggetto conosce gli oggetti correlati |
| un oggetto controlla e coordina le attività di altri oggetti | un oggetto conosce cose che può derivare |
Le responsabilità sono assegnate alle classi durante la progettazione a oggetti. Per esempio, si può dichiarare che una Sale è responsabile della creazione di oggetti SaleLineItem (fare) o che una Sale è responsabile di conoscere il suo totale (conoscere).
Il modello di dominio spesso ispira le responsabilità più importanti relative al "conoscere", grazie agli attributi e alle associazioni che mostra. Per esempio, se la classe Sale del modello di dominio ha un attributo time, è naturale che una classe software Sale conosca la propria ora. Si pensi agli oggetti software come simili a persone che hanno delle responsabilità e che collaborano con altre persone per svolgere un lavoro. La RDD porta a considerare un progetto OO come una comunità di oggetti con responsabilità che collaborano.
La traduzione delle responsabilità in classi e metodi è influenzata dalla granularità della responsabilità. Le responsabilità più grandi coinvolgono centinaia di classi e metodi, mentre le responsabilità minori possono coinvolgere un solo metodo. Per esempio, la responsabilità di "fornire accesso alle basi di dati relazionali" può coinvolgere duecento classi e migliaia di metodi organizzati in un sotto sistema. Al contrario, la responsabilità di "creare una Sale" può coinvolgere un solo metodo in una sola classe. L'idea di responsabilità è solo un'astrazione.
Un'altra idea della RDD è la collaborazione. Le responsabilità sono implementate per mezzo di oggetti e metodi che agiscono da soli oppure che collaborano con altri oggetti e metodi. Per esempio, la classe Sale potrebbe definire uno o più metodi per conoscere il suo totale, si supponga un metodo chiamato getTotal. Per soddisfare questa responsabilità, la Sale può collaborare con altri oggetti, per esempio inviando un messaggio getSubtotal a ciascuno oggetto SalesLineItem per chiedere il rispettivo totale parziale.
La RDD viene fatta iterativamente come segue:
- identifica le responsabilità e considerale una alla volta
- chiediti a quale oggetto software assegnare tale responsabilità; potrebbe essere un oggetto tra quelli già identificati, oppure un nuovo oggetto
- chiediti come l'oggetto scelto a soddisfare tale responsabilità; potrebbe fare tutto da solo, oppure collaborare con altri oggetti.
Questo procedimento va basato su opportuni criteri per l'assegnazione di responsabilità, come i pattern GRASP.