OO Analysis Vs. OO Design

OO Analysis Vs. OO Design • OOA – Object Oriented Analysis. • Specifica “COSA”, “IN QUALE CONTESTO” il sistema soddisfa REQs e SPECs. • OOD – Object Oriented design. • Specifica “COME” il sistema soddisfa REQs e SPECs. • OOD estende e modifica classi ed oggetti identificati con OOA.

OOD, approfondimento • “COME” significa: • Aggiungere aspetti tecnici relativi a: • Interazione con l’utente • Rappresentazione ed elaborazione dei dati • Gestione dei task • Si tiene conto di: • T, S, organizzazione sviluppo e codifica, riuso…

Identificazione di classi ed oggetti • Dove guardare: • Osservare, ascoltare attivamente, verificare altri progetti OO, altri sistemi, leggere docs, prototipare • Cosa guardare: • Strutture, sistemi, dispositivi, cose, eventi, ruoli, procedure, attività, processi, luoghi, sedi, unità organizzative

Identificazione di classi ed oggetti • Cosa considerare • Necessità di persistenza, di comportamento, attributi multipli, la presenza di più di un oggetto in una classe, attributi e servizi dei membri, requisiti particolari

Object(s) Class(es) astrazione Libraries Frameworks Astrazione su classi ed oggetti

Requisiti generali per la riutilizzabilità delle classi • Generalità • Semplicità • Indipendenza tra classi • Facilità di specializzazione • Progettazione con un ottica generale • Classi ottenute con raffinamenti successivi

Standardizzazione delle classi • Omogeneità nei nomi e nei comportamenti dei metodi • Operazioni simili  metodi simili  nomi uguali • Rivedere i casi in cui 1 metodo verifica a che classe appartiene • Metodi con troppi (>6) argomenti • Più metodi più piccoli • Nuove classi per alcuni argomenti • Ridurre la dimensione dei metodi (al max 30 linee)

Astrazione delle classi • Aspetti comuni  “migrati verso l’alto” • Eliminare i metodi che siano overriden, piuttosto che ereditati • Accedere alle VAR solo attraverso i metodi ( minor dipendenza dalla rappresentazione) • Sottoclassi siano specializzazioni

…e ancora • Classi  entità naturali • Più istanze di un oggetto  classe • Narrow & deep, rather then wide & shallow • Riconsidera sottoclassi che implementano lo stesso metodo in un modo diverso • Se alcuni metodi accedono a sole certe VAR, e altri analogamente, dividi la classe in più (sotto)classi • Verifica oggetti/classi preesistenti, eventualmente rendili più robusti e generali

Aggregazione (part of) • Considera varianti: • Parte - Assemblato • Contenitore - Contenuto • … • Se la parte è solo uno stato SI/NO, includila come attributo dell’oggetto

Identificazione della struttura • Generalizzazione/Specializzazione • Considera una classe come generalizzazione e per ognuna delle sue specializzazioni verifica: • E’ del dominio, è pertinente al sistema, ci sarà ereditarietà, è un oggetto/classe secondo i relativi canoni • Analogamente ciascuna classe come specializzazione… • Scegli la gerarchia più semplice • Verifica se conviene avere un reticolo (eredità multipla), in tal caso, gestisci i conflitti

OODesign: vantaggi • Meno codice • Maggior riusabilità • Maggior resistenza al cambiamento (i dati sono la parte più stabile) • Adatto a modularizzare lo sviluppo • Naturale ed intuitivo per tecnici e utenti •  OOPL!!

Bibliografia • Peter Coad / Edward Yourdon Odject Oriented Analysis - 2nd EditionYourdon press computing SeriesPRENTICE HALL, Englewood Cliffs, NJ 1991.

OO Analysis Vs. OO Design