1 / 13

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.

igor-barber
Download Presentation

OO Analysis Vs. OO Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 l’utente • 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. Object(s) Class(es) astrazione Libraries Frameworks 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 (>6) 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 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

  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 dell’oggetto

  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.

More Related