Oo analysis vs oo design
Sponsored Links
This presentation is the property of its rightful owner.
1 / 13

OO Analysis Vs. OO Design PowerPoint PPT Presentation


  • 63 Views
  • Uploaded on
  • Presentation posted in: General

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.

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


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.


  • Login