OO Analysis Vs. OO Design

1
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.

2
OOD, approfondimento

• COME significa
• Aggiungere aspetti tecnici relativi a
• Interazione con lutente
• Rappresentazione ed elaborazione dei dati
• Gestione dei task
• Si tiene conto di
• T, S, organizzazione sviluppo e codifica, riuso

3
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

4
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

5
Astrazione su classi ed oggetti
6
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

7
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 (gt6) argomenti
• Più metodi più piccoli
• Nuove classi per alcuni argomenti
• Ridurre la dimensione dei metodi (al max 30 linee)

8
Astrazione delle classi

• Aspetti comuni ? migrati verso lalto
• Eliminare i metodi che siano overriden, piuttosto
  che ereditati
• Accedere alle VAR solo attraverso i metodi (?
  minor dipendenza dalla rappresentazione)
• Sottoclassi siano specializzazioni

9
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

10
Aggregazione (part of)

• Considera varianti
• Parte - Assemblato
• Contenitore - Contenuto
• Se la parte è solo uno stato SI/NO, includila
  come attributo delloggetto

11
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

12
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!!

13
Bibliografia

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