Business Analysis II - ITECH Engineeringthimoty.it/softeng/Lez03-Disegno.pdf · Business Analysis...

Business Analysis IIBusiness Analysis II

DisegnoProf. Thimoty Barbieri

Università degli Studi di Pavia

2Business Analysis II Thimoty Barbieri

Obiettivi della LezioneObiettivi della Lezione

Alcune strategie di fondoRipasso dei principali concetti OOPAlcuni utili Design Pattern

Alcune strategie di fondoAlcune strategie di fondo


Il Buon SensoIl Buon Senso

Il disegno tecnico richiede di ottenere qualità, flessibilità, rapidità di sviluppo, codice chiaro e manutenibileEsistono tecniche e tecnologie ma…… il buon senso va sempre usato.

I seguenti lucidi offrono alcuni spunti di base, da tenere presente quando si progetta


Design e Debug: Rasoio di OccamDesign e Debug: Rasoio di OccamTale principio, alla base del pensiero scientifico moderno, nella sua forma più semplice suggerisce l'inutilità di formulare più assunzioni di quelle strettamente necessarie per spiegare un dato fenomeno: il rasoio di Ockham impone di scegliere, tra le molteplici cause, quella che spiega in modo più semplice l'evento. « Entia non sunt multiplicanda praeter necessitatem. »« Pluralitas non est ponenda sine necessitate. »« Frustra fit per plura quod fieri potest per pauciora. »In altri termini, non vi è motivo alcuno per complicare ciò che è semplice. All'interno di un ragionamento o di una dimostrazione vanno invece ricercate la semplicità e la sinteticità. Tra le varie spiegazioni possibili di un evento, è quella più semplice che ha maggiori possibilità di essere vera (anche in base a un altro principio, elementare, di economia di pensiero: è ragionevole scegliere, tra varie soluzioni, la più semplice e plausibile).

Source: Wiki


Developing: KISS !Developing: KISS !KEEP IT SIMPLE, STUPID!The term KISS is an acronym of the phrase "Keep It Simple, Stupid", and the KISS principlestates that design simplicity should be a key goal and unnecessary complexity avoided. It serves as a useful and frequent verbal exhortation (or even dedicated policy) in software development, animation, engineering, and in strategic planning (especially military operations). When solving problems, people sometimes tend towards complicated solutions that are harder to deal with than the problem, or ostensibly 'clever' solutions that do not actually work for all possible forms of the problem. Instruction creep and function creep are related phenomena, and the Rube Goldberg machine is an extreme example of this.According to KISS, the method used should be as simple and straightforward as possible. KISS is simply Occam's Razor applied to engineering and other fields involving problem solving.

Source: Wiki

Progettazione ad OggettiProgettazione ad Oggetti


QualitQualitàà del Software: il Nostro Obiettivodel Software: il Nostro ObiettivoIl software è un prodotto, risultato di un processo produttivo. È importante definire quali sono gli aspetti che conferiscono qualità a questo prodotto.Qualità Esterne: percepibili da un osservatore esterno che esamina il prodotto come se fosse una 'scatola nera'. esse sono l'interesse primario e un obiettivo finale.Qualità Interne: possono essere osservate esaminando la struttura interna del prodotto.

rappresentano sostanzialmente modi che facilitano l'ottenimento delle qualità esterne.Generalmente i fattori di qualità sono ancora espressi in modo intuitivo, difficilmente formalizzabile.Affidabilità: un software è affidabile quando 'è possibile fidarsi' ad usarlo, le funzionalità da esso offerte corrispondono alle attese, ed eventuali deviazioni sono comunque tollerabili.Correttezza: un software è corretto se rispetta i requisiti su cui è stato progettato. Ogni difformità dai requisiti specificati, lieve o grave che sia, è una scorrettezza.Robustezza: non sempre le specifiche sono esatte o tengono tutto in conto. Software che si comportano in modo accettabile anche in situazioni non previste dalle specifiche sono detti robusti.Sicurezza (Security): un software è sicuro se non permette accessi o utilizzi non autorizzati.Innocuità (Safety): per software critici alla vita umana, sono innocui software che non entrano mai in stati dannosi o pericolosi. (es. software avionici…)


QualitQualitàà del Software: il Nostro Obiettivodel Software: il Nostro ObiettivoPrestazioni: un software che non risponde in tempi sufficientemente rapidi può essere considerata inutilizzabile. Valutabile attraverso la teoria della complessità (andamento asintotico del tipo O(log(n))…).Usabilità: oltre che da prestazioni, correttezza e robustezza, l'usabilità dipende anche dal far sì che l'utente sia sempre in grado di utilizzare con agio l'applicazione. Tipica qualità esterna. Importanza della GUI, di una corretta comunicazione con l'utente, di messaggi di errore comprensibili…Verificabilità: un software è verificabile se è possibile dimostrare a posteriore (con opportuni altri metodi/software/benchmark) che delle sue proprietà sussistono.Manutenibilità: la manutenzione si riferisce a tutte le fasi successive al rilascio di un software. Un software è manutenibile quanto più sono agevoli la manutenzione correttiva (debug), la manutenzione adattativa (aggiornamento per l'Euro…), la manutenzione perfettiva (rilascio di nuove versioni migliorate).Riusabilità: prevede che i software non vengano sviluppati completamente da zero ogni volta, ma usando eventualmente alcuni componenti già esistenti perché realizzati in precedenza, che vengono riassemblati con eventuali lievi modifiche. (Difficile!)Comprensibilità: L'architettura e la struttura del software/progetto deve essere comprensibile e 'dominabile' perché sia possibile ottenere la qualità. La modularità è di grande aiuto per migliorare la comprensibilità e dominare la complessità. Anche l'astrazione da un dettaglio eccessivo è di grande aiuto nella progettazione modulare. Una documentazione precisa e consistente, sia all'interno del software che in allegato, sia a livello tecnico che utente, aumenta grandemente la comprensibilità. Non sottovalutare mai il valore della carta!


Creare il software nel mondo realeCreare il software nel mondo reale

I. Determinazione obiettivi, alternative e vincoli

II. Valutazione alternative, identificazione e risoluzione rischi

III. Sviluppo e verifica delprossimo livello di prodottoIV. Pianificazione e

fase successiva


ProgettazioneProgettazione

La fase di Progettazione è il cuore del processo produttivo del software, e la chiave per ottenere gli obiettivi di qualità.– Processi e Dati, Moduli, Funzioni e Interfacce

Occorre innanzitutto distinguere chiaramente tra processi e dati. Gli uni costituiscono gli algoritmi, la 'meccanica' dell'applicazione, i secondi seguono un flusso tra processo e processo subendo una trasformazione, fino ad arrivare al risultato finale.

dati

processi


Moduli, Componenti, InterfacceModuli, Componenti, Interfacce

Ciascun processo può essere programmato in un modulo, per cui sono definite sono determinate correlazioni con determinati altri moduli.L'elenco dei servizi o delle funzioni che un modulo mette a disposizione agli altri moduli, e la rigorosa definizione di quali dati il modulo accetta in ingresso, e quali produce in uscita, costituiscono la definizione dell'interfaccia del modulo. Si viene a formare una rete di relazioni tra moduli, spesso diagrammata con un Component Diagram


Il buon ModuloIl buon Modulo

È interessante un modulo che ha al suo ingresso più archi, perché significa che si sono fattorizzate delle risorse.


Coesione e DisaccoppiamentoCoesione e Disaccoppiamento

La definizione di un modulo/componente deve basarsi sulla coesionedel suo contenuto e sul disaccoppiamento con il resto del sistema.Si ha coesione quando tutto ciò che è contenuto in un modulo fa riferimento ad un insieme di caratteristiche comuni: ad es. un modulo tutto dedicato all'I/O. Ciò consente di concentrare lo sviluppo di una determinata funzione in una sola parte dell'architettura del sistema.Il disaccoppiamento è la chiave per dominare la complessità del sistema: i moduli devono essere sufficientemente indipendenti tra loro, in modo da poter essere compresi (e di poter funzionare) da soli, senza ricorrere ad un'approfondita conoscenza degli altri. Moduli ben disaccoppiati hanno pochi mutui collegamenti, semplici e regolari, e quindi sempre controllabili.


Information HidingInformation Hiding

Si sono visti i criteri per 'identificare' i moduli, e per metterli in relazione tra di loro. Bisogna successivamente dettagliare quali siano i servizi che ciascun modulo rende disponibili, e quali di questi sono utilizzati da gli altri moduli.Ai fini del disaccoppiamento è importante che il contenuto di ciascun modulo riguardi solo e solamente il modulo stesso, e che un eventuale cambiamento non si ripercuota sugli altri moduli. I moduli devono essere scatole nere che comunicano tra loro solo nei modi a loro concessi attraverso la definizione della loro interfaccia.È questo il senso dell'information hiding: il modulo va pensato diviso in due parti – una (l'interfaccia) è completamente visibile all'esterno e rappresenta la 'frontiera' del modulo e le 'regole' per comunicare con esso.L'altra (l'implementazione) costituisce il vero 'meccanismo interno' del modulo e va tenuta nascosta all'esterno a tutti i costi.


Vantaggi di Information HidingVantaggi di Information Hiding

La complessità totale di un sistema può essere dominata solo e solamente se i progettisti degli altri moduli non sono costretti a conoscere i dettagli implementativi dei moduli che vogliono utilizzare. Essi sono solo tenuti a conoscere le modalità con cui i servizi sono utilizzabili e il risultato che si devono attendere.OOP Nasce per consentire a grandi gruppi di progettare il lavoro in modo indipendente ma integrabile.


RiusabilitRiusabilitàà

Tutto questo consente di pensare a realizzare moduli che possanoessere 'riusati', vale a dire utilizzati anche in altri progetti che richiedono le stesse funzioni fornite da quel modulo.Tanto più un modulo è disaccoppiato, tanto più la sua implementazione è nascosta, tanto meglio esso si adatta ad essere riusato in altri sistemi.Design for change (Parnas): progettate pensando già ai cambiamenti. Fate in modo che eventuali cambiamenti al modulo impattino il meno possibile sul resto del sistema. Questa regola è vitale in situazioni di alta turbolenza.Design for reuse: progettate con lungimiranza, cercando di creare moduli 'utili' facili da 'riciclare' in progetti futuri. Abbiate sempre coscienza di quali moduli possono entrare di fatto nella vostra 'libreria' a cui attingere liberamente, e quali moduli possono solo essere 'specifici' del progetto a cui lavorate. Più ampia è la vostra libreria, più sembrerete produttivi e meno testing dovrete fare in seguito.


LL’’approccio generale: ADTapproccio generale: ADT

Il principio di information hiding va esteso anche ai dati, e non solo agli algoritmi di un modulo.Si può dunque pensare ad un'entità chiamata oggetto che consente di incapsulare una struttura dati in un modulo, regolamentandone l'accesso attraverso opportune operazioni astratte che costituiscono l'interfaccia dell'oggetto.Un oggetto di questo tipo è caratterizzato da un proprio stato interno, che influisce sui risultati dell'attivazione di un'operazione su di esso.Così come normali variabili hanno un tipo, e le operazioni che si possono eseguire su queste variabili sono vincolate dal loro tipo, si può introdurre il concetto di tipo di oggetto, detto comunemente tipo di dato astratto (ADT).


Esempio di ADTEsempio di ADT

Un tipo di dato astratto è un modulo che incapsula sia la definizione di un tipo la cui struttura risulta invisibile all'esterno, sia l'insieme delle operazioni che permettono di manipolare gli oggetti di quel tipo.Un esempio di ADT scritto in C++:– class point {– public:– point(int a, int b) { x=a; x=b;}– void x_move(int a) { x+=a; }– void y_move(int b) { x+=b; }– void reset() { x = 0; y = 0; }– private:– int x,y;– };


Esempio di ADTEsempio di ADT

– point p1(1,3);– p1.x_move(3);– p1.reset();

'punto' viene trattato come un 'nuovo' tipo, un tipo di dato astratto. Esso è composto da due int, x e y e dai metodi per accedervi. Non è possibile modificare direttamente i valori di queste due variabili, che sono nascoste all'esterno. L'unico modo è utilizzare le member functions o metodi messi a disposizione.Il punto p1 dopo essere stato creato, dispone di uno stato (le sue coordinate correnti). Usando il metodo x_move si modifica lo stato senza che sia noto dall'esterno quale e di che tipo sia la variabile che rappresenta la posizione orizzontale.


Terminologia OOPTerminologia OOP

Nella Programmazione ad Oggetti (OOP), i Tipi di Dati Astratti si identificano nelle Classi (e negli Oggetti, che sonole loro istanze). Nel paradigma ad oggetti l'unità modulo è la classe.Una classe rappresenta un'entità generica, da cui si genera un particolare oggetto mediante istanziazione.Ogni oggetto dispone dunque di variabili istanza e di metodi, e ciascun oggetto (istanza di una classe), a partire dalla propria creazione matura indipendentemente dalle altre istanze della medesima classe un proprio stato.È possibile definire campi e metodi validi a livello di classe e non di istanza (identificativi static). Essi vengono 'messi a comune' tra le istanze.


Caratteristiche del Paradigma OOPCaratteristiche del Paradigma OOP

Interessanti caratteristiche dell'OOP sono le seguenti:EreditarietàPolimorfismoDynamic BindingEreditarietà MultiplaEreditarietà– Si tratta di un meccanismo del linguaggio che consente di definire

sottoclassi che specializzano altre classi. La specializzazione consente alla sottoclasse di avere tutti i campi e i metodi della classe parent, piùeventualmente altri campi e metodi.

– In altre parole, la sottoclasse eredita dalla superclasse campi e metodi.– La sottoclasse può anche eventualmente ridefinire un metodo ereditato

dalla superclasse, a patto di manterne identica l'interfaccia. Questa tecnica è detta overriding.


Esempio di EreditarietEsempio di EreditarietààUn esempio in C++[1]:– Si immagini di voler creare una classe per incapsulare il tipo Stack.– Uno Stack è una particolare struttura dati tipica degli algoritmi

programmativi le cui caratteristiche sono:– È una lista di valori – È possibile aggiungere valori solo sulla cima dello Stack– Quando viene aggiunto un nuovo valore, i valori precedenti 'rimangono

sotto' nella pila (push)– È possibile prelevare dalla lista solo il valore che rimane in cima nella pila

(pop)– Quando valore viene prelevato, esso viene tolto dalla cima della pila e

'consumato'.– Nota: Questo tipo di struttura dati è preziosissima per supportare una

tecnica di programmazione detta ricorsiva.[1] L'esempio presciede da alcuni particolari tecnici riguardanti l'accessibilità dell'identificatore top che andrebbe dichiarato in altro modo. Concentratevi per il momento sull'idea di ereditarietà.


La pilaLa pila

class stack {public:

void push(int i){elements[top++] = i;};int pop(){return elements[--top];};

private:int elements[100];int top=0;

};


Estendere e NascondereEstendere e Nascondere

Si supponga ora di voler disporre di un nuovo tipo di pila, che oltre a mettere a disposizione la possibilità di fare push e pop, consenta all'utilizzatore di conoscere il numero di elementi della pila.Anziché riscrivere una nuova classe pila, ereditiamo dalla classe pila già disponibile metodi e campi, specializzandolacon un nuovo metodo per fornire questa informazione.Ricordare il principio dell'information hiding! Non si può concedere a classi esterne di leggere direttamente la variabile top!


UnUn’’altra pilaaltra pila

– class counting_stack: public stack {– public:– int size();– // returns the number of elements– }


PolimorfismoPolimorfismo

PolimorfismoI linguaggi ad oggetti consentono l'uso di variabili polimorfiche, che anziché riferirsi ad oggetti sempre e solamente di un'unica classe, possono riferirsi ad oggetti di classi diverse.Il polimorfismo si presenta in forme diverse, più o meno marcato. Linguaggi che prevedono una tipizzazione forte degli identificatori solitamente utilizzano questa regola di polimorfismo: una variabile di classe T può riferirsi solo e solamente ad oggetti di tipo T o a qualsiasi classe che erediti da T.


PolimorfismoPolimorfismoAd esempio:– stack* b = new stack: // classe base– counting_stack* d = new counting_stack; //derivata– b = d; // ok– d = b; // no! Cosa succede se faccio d->size()?

Senza il polimorfismo, b = d non sarebbe concesso perché di tipo diverso. Con il polimorfismo del tipo qui concesso, invece è possibile perché d si riferisce ad una classe derivata di b.Un tipo diverso di polimorfismo (detto coercitivo) si ha se non si passa per i puntatori:– stack b;– counting_stack d;– b = d; // l'oggetto viene 'costretto' al tipo stack– // e 'perde' l'operazione size()

L'argomento è molto complesso e esistono diversi tipi di polimorfismo. Ciò che si può e non si può fare, e il risultato nei vari casi dipende grandemente dal tipo di linguaggio ad oggetti che si utilizza.


Polimorfismo, o Polimorfismo, o ““Le mele con le pereLe mele con le pere””

Sconfiggiamo il paradigma della “maestra delle elementari”: “non sommare le mele con le pere!”Risposta polimorfica alla maestra:– La mela è un frutto– La pera è un frutto– Polimorficamente 2 mele + 3 pere = 5 frutti


Dynamic BindingDynamic Binding

Nelle classi derivate è possibile ridefinire i metodi che vengono ereditati, per specializzarli ulteriormente (overriding).Ad es. si può pensare di aggiungere una nuova implementazione del metodo push() in counting_stack.Ma se si considera il polimorfismo, quale dei due metodi viene utilizzato, quello della classe base o quello della derivata?– stack* b = new stack;– counting_stack* d = new counting_stack;– b->push(); // stack::push()– d->push(); // counting_stack::push()– b=d; // com'e' bello il polimorfismo– b->push(); // quale push?!?


Seguire il bindingSeguire il binding

In un binding statico la chiamata va al metodo appartenente al tipo della classe. (stack::push)In un binding dinamico la chiamata si basa sul tipo dell'oggetto. (counting_stack::push)In linguaggi ad oggetti puri (SmallTalk, Eiffel, Java) il binding avviene sempre in modo dinamico.Il C++ non è classificato come linguaggio ad oggetti puro, e consente di fare il binding sia in modo statico che dinamico.

Alcuni utili Design PatternAlcuni utili Design Pattern


Concetto di Design PatternConcetto di Design Pattern

Nell'ingegneria del software, un design pattern può essere definito "una soluzione progettuale generale a un problema ricorrente". Esso non è una libreria o un componente di software riusabile, quanto una descrizione o un modello da applicare per risolvere un problema che può presentarsi in diverse situazioni durante la progettazione e lo sviluppo del software.La differenza tra un algoritmo e un design pattern è che il primo risolve problemi computazionali, mentre il secondo èlegato agli aspetti progettuali del software.

Source: Wiki


Definizione di Design PatternDefinizione di Design Pattern

Un design pattern è costituito da:– il nome, costituito da una o due parole che siano il più possibile

rappresentative del pattern stesso; – il problema, ovvero la descrizione della situazione alla quale si può

applicare il pattern. Può comprendere la descrizione di classi o di problemi di progettazione specifici, come anche una lista di condizioni perché sia necessario l'utilizzo del pattern;

– la soluzione, che descrive gli elementi costitutivi del progetto con le relazioni e relative implicazioni, senza però addentrarsi in una specificaimplementazione. Il concetto è di presentare un problema astratto e la relativa configurazione di elementi adatta a risolverlo;

– le conseguenze, i risultati e i vincoli che derivano dall'applicazione del pattern. Sono fondamentali in quanto possono essere l'ago della bilancia nella scelta dei pattern: le conseguenze comprendono considerazioni di tempo e di spazio, possono descrivere implicazioni del pattern con alcuni linguaggi di programmazione e l'impatto con il resto del progetto.

Source: Wiki


Tipi di Design PatternTipi di Design Pattern

I design pattern possono essere classificati con diversi criteri, i più comuni dei quali sono quelli che evidenziano il tipo di problema che si cerca di risolvere. Il tipo di problema può essere legato ad uno specifico dominio progettuale (telecomunicazioni, reti, software...) oppure, piùcomunemente, al problema progettuale in senso più ampio (nell'ingegneria del software, ad esempio, si può parlare di creazione, comportamento, navigazione di oggetti o strutture dati).Nel loro libro la "banda dei quattro" identificò 23 tipi di design pattern, suddivisi in 3 categorie: strutturali, creazionali e comportamentali.

Source: Wiki


Pattern piPattern piùù usati / usabiliusati / usabiliI pattern creazionali nascondono i costruttori delle classi e mettono dei metodi al loro posto creando un'interfaccia. In questo modo si possono utilizzare oggetti senza sapere come sono implementati.– L'Abstract factory fornisce un'interfaccia per creare famiglie di oggetti connessi o

dipendenti tra loro, in modo che non ci sia necessità da parte degli utilizzatori di specificare i nomi delle classi concrete all'interno del proprio codice.

– Singleton, il cui scopo è assicurare che di una classe possa essere creata una sola istanza.

I pattern strutturali consentono di riutilizzare degli oggetti esistenti fornendo agli utilizzatori un'interfaccia più adatta alle loro esigenze.– L'Adapter converte l'interfaccia di una classe in una interfaccia diversa– Il Façade permette, attraverso un'interfaccia più semplice, l'accesso a sottosistemi

che espongono interfaccie complesse e diverse tra loro. I pattern comportamentali forniscono soluzione alle più comuni tipologie di interazione tra gli oggetti.– L'Observer definisce una dipendenza uno a molti fra oggetti diversi, in maniera tale

che se un oggetto cambia il suo stato, tutti gli oggetti dipendenti vengono notificati del cambiamento avvenuto e possono aggiornarsi.

Source: Wiki


Abstract FactoryAbstract FactoryProvides a way to encapsulate a group of individual factories that have a common theme. In normal usage, the client software would create a concrete implementation of the abstract factory and then use the generic interfaces to create the concrete objects that are part of the theme. The clientdoes not know (nor care) about which concrete objects it gets from each of these internal factories since it uses only the generic interfaces of their products. This pattern separates the details of implementation of a set of objects from its general usage. The factory determines the actual concrete type of object to be created, and it is here that the object is actually created.

Source: Wiki


SingletonSingletonThe singleton pattern is implemented by creating a class with a method that creates a new instance of the class if one does not exist. If an instance already exists, it simply returns a reference to that object. To make sure that the object cannot be instantiated any other way, the constructor is made either private or protected.

Applications:– State objects are often Singletons. – Singletons are often preferred to global variables because: – They don't pollute the global namespace (or, in languages with

namespaces, their containing namespace) with unnecessary variables.

– They permit lazy allocation and initialization, where global variables in many languages will always consume resources.

Source: Wiki


AdapterAdapter

‘Adapts' one interface for a class into one that a client expects. An adapter allows classes to work together that normally could not because of incompatible interfaces by wrapping its own interface around that of an already existing class. The adapter is also responsible for handling any logic necessary to transform data into a form that is useful for the consumer.

Source: Wiki


FacadeFacade

Provides a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. This can be used to simplify a number of complicated object interactions into a single interface.

Source: Wiki


ObserverObserver

The essence of this pattern is that one or more objects (called observers or listeners) are registered (or register themselves) to observe an event that may be raised by the observed object (the subject). (The object that may raise an event generally maintains a collection of the observers.) The typical usages of the observer pattern:– Listening for an external event (such as a user action). (Event-driven programming). – Listening for changes of the value of an object property. – In a mailing list, where every time an event happens (a new product, a gathering, etc.)

a message is sent to the people subscribed to the list.

Source: Wiki


I Pattern sono belli maI Pattern sono belli ma……

Tipica Nota:– >

– Considerare sempre se il problema che si vuole risolvere non siameno complessa della soluzione che si sta seguendo.

– Non barattare la (presunta) eleganza con la semplicità e l’immediatezza


Conclusione: Non Irritate Occam!Conclusione: Non Irritate Occam!

Business Analysis II - ITECH Engineeringthimoty.it/softeng/Lez03-Disegno.pdf · Business Analysis...

Documents

Transcript of Business Analysis II - ITECH Engineeringthimoty.it/softeng/Lez03-Disegno.pdf · Business Analysis...