Lavori in corso LucaMinudel & RiccardoGolia

Il disegno object oriented

Il disegno object oriented di un sistema software viene fatto a partire da:

• una lista di requisiti funzionali che il sistema deve soddisfare
• una lista di requisiti non funzionali che descrivono la qualità attesa del sistema nel suo insieme, suddivisi in cinque categorie principali (ognuna suddivisa in sottoattributi ogniuno dei quali espresso con metriche per le quali va definito un intervallo di accettabilità):
• affidabilità e sicurezza
• usabilità
• efficienza
• Manutenibilità: capacità del software di essere modificato con un impegno contenuto a seguito di correzioni, miglioramenti o adattamenti dovuti a cambiamenti nell’ambiente di impiego o nei requisiti o nelle specifiche funzionali (il software segue l’evoluzione dell’organizzazione); le sottocaratteristiche correlate sono:
• Analizzabilità: impegno richiesto per diagnosticare carenze o cause di malfunzionamento o per identificare le parti da modificare
• Modificabilità: impegno richiesto per effettuare modifiche, rimuovere difetti o sostituire componenti di sistema
• Stabilità: ridotto rischio di effetti inaspettati a seguito di modifiche apportate
• Provabilità: impegno richiesto per validare le modifiche apportate al software
• portabilità, interoperabilità, accessibilità
• vincoli di tempo di realizzazione a cui il sistema deve sottostare (sforzo necessario e data di calendario)
• vincoli di costo
• altri eventuali vincoli
• vincoli legislativi e normativi
• vincoli di interazione con altri sistemi software estenti
• ...

Il disegno viene fatto da una persona con competenze di progettazione software.

L'attività di stendere il disegno di un sistema software consiste nel individuare tra i possibili disegni che realizzano i requisiti funzionali quello che meglio soddisfa la qualità attesa (espressa dai requisiti non funzionali) e meglio rispetta i vari vincoli espressi.

L'attività di disegno produce una descrizione del sistema in sotto-sistemi, componenti e classi per le quali sono definite le relazioni, le interazioni e le responsabilità.

Il risultato prodotto dalla attività di disegno è destinato a guidare le attività di sviluppo, integrazione, test e rilascio del sistema software.

Il disegno non è analisi

L'attività di emersione e raccolta dei requisiti, di analisi dei requisiti e definizione delle specifiche, chiamata genericamente col termine di analisi, differisce dall'attività di disegno.

L'analisi:

• descrive cosa il sistema deve fare
• descrive il comportamento esterno
• usa il linguaggio dell’utente
• partecipano committente e analista
• è destinata alla progettazione (ossia il disegno).

Il disegno:

• descrive come il sistema deve fare
• descrive il comportamento interno
• usa il linguaggio dello sviluppatore
• vi partecipano progettista e sviluppatori
• è destinato allo sviluppo.

Quanto disegno fare

Il disegno è sufficiente quando ha raggiunto i suoi due scopi principali:

• Dominare la complessità
• Permettere l’evoluzione

Inizialmente il sistema da realizzare può sembrare molto complesso e presentare dei punti oscuri. Quando i dubbi e le incertezze e le complessità avvertite nel sistema sono state ridotte e semplificate, il disegno ha raggiunto il suo scopo e non serve farne altro.

Quando il sistema è realizzato e il cliente desidera aggiungere o modificare funzionalità senza rifare tutto o la software house vuole ridurre i costi di manutenzione e adattare il sistema a più clienti, ci si può scontrare con la difficoltà di modificare il software. Se modificando il codice non avvertiamo più "attriti", resistenze che frenano o impediscono la modifica e l'evoluzione, il disegno ha raggiunto il suo scopo e non serve farne altro.

Il disegno e la semplicità

La relazione tra il disegno del software e la complessità è guidato dal PrincipioKiss.

Il buon disegno

Gli attributi del buon disegno

Quando un sistema software è disegnato bene il codice è Flessibile, Robusto e Riusabile, il suo opposto è quando il codice è Rigido, Fragile e Immobile.

In modo equivalente il buon disegno può essere misurato con queste due metriche:

• basso accoppiamento: la dipendenza dei componenti software del sistema da altri componenti software del sistema è bassa,
• alta coesione: i componenti software del sistema possono collaborare tra di loro per ottenere nuove funzionalità in svariate combinazioni.

A questo proposito si vedano anche i PatternGRASP, ovvero i pattern relativi all'assegnazione delle responsabilità nell'ambito di una struttura ad oggetti.

Gli esempi di buon disegno da seguire

• I PatternGRASP
• I DesignPattern
• Due Reference Model attuali
• ISO OSI Reference Model
• TCP/IP Reference Model
• Il protocollo HTTP come esempio di sistema distribuito stateless e asincrono
• stili, paradigmi e principi dell'interazione utente (HCI)

E gli esempi di cattivo disegno da evitare

• Gli AntiPattern

I principi che guidano il buon disegno

http://ootips.org/ood-principles.html

• Nel disegno delle classi:
• LSP Liskov Substitution Principle: PrincipioLSP
• OCP Open Close Principle: PrincipioOCP
• DIP Dependency Inversion Principle: PrincipioDIP
• SRP Single Responsibility Principle: PrincipioSRP
• ISP Interface Segregation Principle

• Nel disegno dei componenti (Assembly in .NET) relativamente alla coesione:
• REP Reuse Release Equivalence Principle
• CCP Common Closure Principle
• CRP Common Reuse Principle

• Nel disegno dei componenti (Assembly in .NET) relativamente all'accoppiamento:
• ADP Acyclic Dependencies Principle
• SDP Stable Dependencies Principle
• SAP Stable Abstractions Principle

• La metrica di Martin

Il disegno up-front e il disegno continuo

Il disegno classico è quello inteso up front ossia la fase completata prima di iniziare la fase di sviluppo. Viene svolto da una figura dedicata detta Progettista con competenze di disegno e nei casi peggiori senza più competenze di sviluppo.

Il disegno continuo o incrementale è detto Refactoring e viene svolto continuamentre mentre si scrive il codice. Viene svolto quindi dagli stessi sviluppatori.

Il disegno up-front e il Refactoring possono coesistere e tipicamente coesistino, il disegno up-front svolge ruolo di indirizzo iniziale, serve a risolvere studi di fattibilità ed avviare lo sviluppo mentre il Refactoring dettaglia ed adatta il disegno alle nuove informazioni che via via emergono e all'esperienza che matura sul sistema e sulle sue esigenze.

i principi del disegno valgono tanto per il disegno up-front che per il Refactoring.

Gli strumenti per fare disegno

• Come si usano le schede CRC?
• In quanti modi/notazioni si può definire il modello di un sistema?
• UML
• i concetti della notazione UML
• che differenza c'è tra una aggregazione ed una composizione?
• ...

• Cos'è la tecnica di disegno per analogia?
• Le DesignReview

Check list di base per la verifica del disegno di una applicazione

• Ecco dei criteri per ValutareIlDisegnoDiUnaApplicazione