L'ideazione è un piccolo passo verso la fase di elaborazione.
In questa fase viene fatta una visione approssimativa del progetto, uno studio economico, la portata, stime approssimative dei costi e dei tempi
L'ideazione è una fase breve.
In questa fase vengono iniziati una serie di elaborati che sono incompleti e che verranno arricchiti nel corso delle iterazioni successive, tra questi abbiamo:
Il modello dei casi d'uso può elencare gran parte dei nomi inclusi nei casi d'uso e degli attori previsti, ma dettaglia solo il 5-10% di essi (espressi in forma testuale).
Distinguiamo:
In questa fase buona parte dei requisiti sono scritti in formato breve, solo circa il 5-10% in formato dettagliato nel corso delle iterazioni successive anche gli altri saranno scritti in formato dettagliato.
L'ideazione è un piccolo passo iniziale verso la fase di elaborazione
Non sfrutta un approccio a cascata che prevede di definire prima tutti i requisiti per poi passare alla progettazione completa
In generale, gli elaborati di UP, non servono solo per produrre documentazione, ma per comprendere il progetto in maniera più approfondita. Il contenuto dei documenti inizialmente è approssimativo, nel corso del tempo e iterativamente essi diventano più precisi.
In questa fase viene avviene un'analisi più approfondita del progetto, si implementa iterativamente il nucleo dell'architettura, avviene la risoluzione dei rischi maggiori, identificazione della maggior parte dei requisiti e della portata, si hanno stime più realistiche riguardo tempo e costi
L'elaborazione è la serie iniziale di iterazioni durante le quali:
Elaborati dell'elaborazione:
Gli SSD sono un input per i contratti delle operazioni.
Le operazioni di sistema indicati negli SSD con le frecce verso il sistema, non sono metodi.
Un'operazione è una trasformazione o interrogazione che un elemento può essere chiamato a svolgere, un'operazione di sistema è una trasformazione o interrogazione che il sistema è chiamato a svolgere.
Gli eventi che solleciteranno il sistema sono:
Il modello di dominio e gli SSD sono input per i contratti delle operazioni.
I contratti non mostrano come viene raggiunto un risultato (post-condizione), ma mostrano semplicemente i cambiamenti di stato relativamente a oggetti concettuali: creazione di questi, formazione o rottura di collegamenti (rispetto al modello di dominio) e attributi modificati.
Si implementano iterativamente gli elementi rimanenti, a questo punto essi sono quelli più facili e a rischio minore. Ci si prepara al rilascio.
Beta test e rilascio.
XP ha promosso la pratica dei test: scrivere i test per primi. Tale pratica è applicabile a UP. Lo sviluppo è guidato dai test (Test Drive Development - TDD): si scrivono i test come se il codice da testare fosse già stato scritto. Il TDD prevede l'uso di diversi tipi di test:
I test unitari sono composti da quattro parti:
XP ha promosso inoltre il refactoring continuo del codice per migliorare la qualità: meno duplicazione, maggiore sicurezza, ecc..
Dopo ciascuna trasformazione, dovuta a refactoring, i test unitari vengono nuovamente eseguiti, per verificare che la modifica non abbia avuto alcun impatto sul sistema.
Ereditarietà:
Composizione di oggetti:
L'ereditarietà può creare specializzazione (la classe figlia guadagna elementi e proprietà rispetto la classe base): è sconsigliata dai GoF.
I GoF utilizzano l'ereditarietà per creare polimorfismo e non specializzazione.