Ingegneria del software - Informatica per il management

Progettiamo sistemi O-O, quindi dobbiamo identificare correttamente i nostri oggetti e trovare il giusto mix di incapsulamento, ereditarietà e polimorfismo per ottenere software di alta qualità. I principi possono essere utilizzati per garantire la massimizzazione delle qualità del software. Quali possono essere dei buoni principi legali alla programmazione object-oriented? L'idea è quella di definire dei principi la cui adesione da un buon livello di garanzia che la qualità risultante del sistema sia elevata. Ci si fa guidare da dei principi per stabilire e garantire la qualità elevata del software. L'adesione di questi principi massimizza la probabilità che, alla fine, la qualità finale del sistema che ho realizzato sarà elevata.

CONCETTI DI BASE DELL'O-O

• ASTRAZIONE (ABSTRACTION): procedimento mentale che permette di evidenziare alcune proprietà, ritenute significative,
focalizzazione sulle caratteristiche essenziali (rispetto al punto di vista dello spettatore).- INCAPSULAMENTO (ENCAPSULATION): nasconde i dettagli (il tuo stato), mostrando invece le interfacce. Indica la capacità di un oggetto di mantenere al suo interno gli attributi (o proprietà) e i metodi (funzioni) che agiscono su di essi (ossia stato e comportamento). Si crea come una capsula, un contenitore concettuale, che isola l'oggetto dalle cose esterne. Si dice che gli attributi e i metodi sono incapsulati nell'oggetto, e quindi tutte le informazioni utili che riguardano un oggetto sono ben localizzate. Questa metodologia di raccogliere tutto quello che riguarda una singola entità all'interno di un oggetto è uno dei principali vantaggi che viene offerto dalla programmazione orientata agli oggetti. L'incapsulamento è la

Proprietà per cui i dati che definiscono lo stato interno di un oggetto e i metodi che ne definiscono la logica sono accessibili ai metodi dell'oggetto stesso, mentre non sono visibili ai client. Per alterare lo stato interno dell'oggetto, è necessario invocarne i metodi pubblici, ed è questo lo scopo principale dell'incapsulamento.

EREDITARIETÀ (INHERITANCE): il comportamento e lo stato possono essere specializzati. Il meccanismo dell'ereditarietà è utilizzato in fase di strutturazione/definizione/pianificazione del software o in successive estensioni e permette di derivare nuove classi a partire da quelle già definite realizzando una GERARCHIA DI CLASSI. Una classe derivata attraverso l'ereditarietà (sottoclasse o classe figlia) mantiene i metodi e gli attributi delle classi da cui deriva (classi base, superclassi o classi madre), può definire i propri metodi o attributi, e ridefinire il codice di

alcuni dei metodi ereditati tramite un meccanismo chiamato riscrittura di un metodo all'interno di una classe OVERRIDING. Stessa mantenendo intatta la sua segnatura che abbiamo ereditato dalla superclasse. Segnatura significa che in entrambi i metodi sono perfettamente uguali il nome, l'eventuale tipo del valore di ritorno e numero e tipo dei parametri. POLIMORFISMO (POLYMORPHISM): il comportamento dipende da chi sei. È la capacità espressa dai metodi ridefiniti di assumere forme (implementazioni) diverse all'interno di una gerarchia di classi o all'interno di una stessa classe. In altre parole, il polimorfismo indica la possibilità dei metodi di possedere diverse implementazioni. Si indica il fatto che lo stesso codice eseguibile può essere utilizzato con istanze di classi diverse, aventi una superclasse comune. Con il termine si intende la scrittura di più metodi identificati dallo stesso nome che però hanno, iningresso,OVERLOADparametri di tipo e numero diverso.Lo strumento di progettazione fondamentale per lo sviluppo del software è una mente ben istruita sui principi di progettazione[C. Larman] 43DESIGN SMELLSI DESIGN SMELLS sono degli indicatori di possibili problematiche che emergono quando si programma un sistema di bassa qualità indicano che ci potrebbe essere un problema.1. RIGIDITÀ (Rigidity) = tendenza del software a essere difficile da modificare, anche in modo semplice. Un progetto è rigido se una singola modifica provoca una cascata di modifiche successive nei moduli dipendenti. Quanti più moduli devono essere modificati, tanto più rigida sarà la progettazione.2. FRAGILITÀ (Fragility) = tendenza di un programma a rompersi in molti punti quando viene apportata una singola modifica. In questo caso il programma si ROMPE, quindi non è uguale alla rigidità. La rigidità dice che, se viene effettuata una modifica,

A cascata poi accadono altri cambiamenti. La fragilità, invece, dice che quando viene modificato qualcosa, il programma non funziona più, nel senso che, il programma compila, ma non funziona più una parte logica del programma. Spesso i nuovi problemi si trovano in aree che non hanno alcuna relazione concettuale con l'area che è stata modificata. Risolvere questi problemi porta a problemi ancora maggiori.

3. IMMOBILITÀ (Immobility) progetto è immobile quando contiene parti che potrebbero essere utili in altri sistemi, ma lo sforzo e il rischio connessi alla separazione di tali parti dal sistema originale sono troppo grandi. Diventa difficile prendere un pezzo di codice della soluzione e inserirlo in un sistema diverso difficile effettuare un "trapianto" di software. Questo è un evento sfortunato ma molto comune.

4. VISCOSITÀ (Viscosity) può essere di 2 tipi:

• VISCOSITÀ DEL SOFTWARE: un

Il software si dice viscoso quando le modifiche che vengono effettuate compromettono la buona struttura del sistema. Ogni volta che si apportano delle modifiche al sistema, si degrada la qualità. Alcune opzioni per apportare modifiche a un sistema software preservano il design, altri no. Quando i metodi di preservazione del design sono più difficili da usare rispetto agli hack, la viscosità del design è elevata.

VISCOSITÀ DELL'AMBIENTE: quando l'ambiente di sviluppo è lento e inefficiente.

COMPLESSITÀ INUTILE (Needless complexity) di un progetto: quando contiene elementi che al momento non sono utili. Ciò accade spesso quando gli sviluppatori anticipano le modifiche ai requisiti e inseriscono nel software funzionalità per gestire tali potenziali modifiche. Per cercare di creare delle soluzioni che abbattano il costo di cambiamento, anche a fronte di cambiamenti poco probabili, si rischia di creare dei sistemi che

sono inutilmente complessi.

6. RIPETIZIONE INUTILE (Needless repetition) → nello sviluppo software, le opzioni "Copia, Taglia ed Incolla" dovrebbero essere eliminate. Se si utilizzano, significa che il software è stato progettato male: quando lo stesso codice appare più e più volte, in forme leggermente diverse, agli sviluppatori manca un'astrazione.

7. OPACITÀ (Opacity) = tendenza di un codice/software ad essere difficile da comprendere. Il codice può essere scritto in modo chiaro ed espressivo oppure può essere scritto in modo opaco e contorto. Il codice che si evolve nel tempo tende a diventare sempre più opaco con l'età. È necessario uno sforzo costante per mantenere il codice chiaro ed espressivo al fine di ridurre al minimo l'opacità.

DIPENDENZE

I problemi elencati sopra hanno a che fare, sia in maniera diretta che indiretta, con la gestione delle dipendenze → Ovvero: la causa

principale della maggior parte degli smells può essere fatta risalire alla gestione delle dipendenze. Le dipendenze sono potenziali percorsi di diffusione dei cambiamenti e sono un problema fondamentale dello sviluppo software a tutti i livelli (all'interno del codice, all'interno della progettazione delle classi). Dalla definizione di dipendenza di UML: "Indica che le modifiche a un elemento del modello [...] possono causare modifiche in un altro elemento del modello". SOLID è un acronimo riferito a 5 principi dello sviluppo del software orientato agli oggetti, detti SOLID PRINCIPLES (PRINCIPI SOLIDI) che sono intesi come linee guida per lo sviluppo di software leggibile, estendibile e manutenibile, in particolare nel contesto di pratiche di sviluppo agili e fondate sull'identificazione di code smell e sul refactoring. - UNA CLASSE DOVREBBE AVERE SINGLE RESPONSIBILITY PRINCIPLE (Principio di responsabilità)

SRP→UNA, E UNA SOLA, RAGIONE PER CAMBIARE. Una ragione intesa come, non una singola ragione, ma come un insieme di ragioni che sono tutte raggruppate dal fatto di essere relative ad un aspetto comune.

ASSE DI CAMBIAMENTO = insieme di responsabilità

L'idea che una classe abbia una sola responsabilità è legata al fatto che le diverse responsabilità, e quindi i diversi gruppi di funzionalità che sono supportate da una classe, in qualche maniera identificano degli assi di cambiamento diversi.

OGNI RESPONSABILITÀ DIVERSO ASSE DI CAMBIAMENTO

Il problema che emerge da uno scenario del genere è che questi diversi assi di cambiamento inevitabilmente finiscono per interferire uno con l'altro. Se una classe ha più di una responsabilità, le responsabilità vengono accoppiate. I cambiamenti ad una responsabilità possono compromettere o inibire la capacità della classe.

di soddisfare le altre. Ci si ritrova nella situazione in cui si