Sei sulla pagina 1di 14

Fondamenti di Problem Solving

Paolo Maresca Dipartimento di Informatica e Sistemistica Universit Federico II Napoli Via Claudio, 21 80125 Tel. 081 7683168 Email: paomares@unina.it

1. Introduzione
Inizia con questo lavoro un viaggio nei fondamenti della progettazione. Un viaggio affascinante che parte dalla nostra mente, dal modo con il quale ci predisponiamo per la risoluzione ai problemi, esamina i nostri punti di forza e di debolezza nella risoluzione dei problemi. Definiremo concetti e regole di fondo utili per il cosiddetto problem solving. Alla fine trarremo pochi concetti chiave che servono al progettista, come gli arnesi servono allartigiano, essi saranno strumenti per ben costruire, ma anche per ben pensare.

2. Analisi e Sintesi
Lattivit di disseminazione dei fondamenti di informatica complessa. Gli studenti arrivano ai corsi di informatica con una scarsa conoscenza degli elementi della logica e dei concetti di analisi e sintesi. Si pone dunque il problema di disseminare i concetti fondamentali per la risoluzione dei problemi e della costruzione degli algoritmi abituando gli studenti anche a lavorare in gruppo e a ricercare soluzioni a problemi di complessit via via crescente sviluppando spirito critico. Il modo di approcciare ai problemi per la loro risoluzione non solo quello razionale, ma soprattutto quello creativo. Sviluppare un pensiero creativo significa dare spazio alle forme di espressione che si pensa siano emarginate in alcune discipline come linformatica dominate dalla razionalit e dalla logica. Il pensiero occidentale si basa sullanalisi del ragionamento deduttivo. Allanalisi si attribuisce la stessa importanza connessa alla ricerca della verit [1,2,3]. E naturale essere rivolti allanalisi: Una tradizione culturale decennale ci ha insegnato ad esaminare le informazioni di cui abbiamo percezione prima di dedurne un significato. Ma perch cominciamo dallanalisi ? Perch importante, ed anche facile da insegnare. Ai neofiti si forniscono dei casi da studiare e gli si chiede di analizzare le situazioni che questi casi presentano. E un comportamento usuale. Bach nella sua Ein Musicalishes Opfer (Una Offerta Musicale) [4,7] forniva ai suoi allievi un tema musicale ed alcuni indizi (sempre musicali) e chiedeva loro di analizzare la situazione costruendo (sintetizzando, componendo) un canone1. In questo modo realizz i 10 canoni presenti nellopera dedicata al sovrano Federico I Re di Prussia. Mediante lanalisi scomponiamo situazioni complesse e piene di incognite in elementi riconoscibili ed accessibili. Nellanalisi il nostro interesse rivolto a ci che . Nel progetto linteresse rivolto a ci che potrebbe essere.
1

Il canone un tema contrapposto a se stesso (come ad esempio la filastrocca nota come. Fra Martino Campanaro)

Si sempre pensato che cosa semplicissima e scontata sapere cosa fare una volta che lanalisi di un dato problema ci abbia svelato la verit. E come avere una buona mappa su cui sono indicate tutte le strade: si tratta solo di scegliere la direzione ! Insomma tramite lanalisi scomponiamo una situazione in elementi, che vengono poi, ricombinati mediante la sintesi al fine di avere una risposta o unazione. Accade la stessa cosa con il gioco del Lego. Nellanalisi si smontano i blocchetti di plastica che, nella sintesi, una volta rimontati con determinati criteri, danno luogo ad un nuovo oggetto. Sfortunatamente progettare non significa solo assemblare in forma additiva determinati oggetti ! Occorrono concetti nuovi e questi concetti non derivano semplicemente dalla sintesi di elementi separati. Dunque lanalisi il nostro metodo tradizionale, lasso nella manica, per risolvere i problemi. Ma i problemi hanno una causa ? Quale la causa di un problema ? E cosa un problema ? Cominciamo con un esempio, se inciampiamo per strada ci voltiamo e cerchiamo lostacolo accaduto qualcosa di razionale ci stiamo chiedendo: cosa devo fare perch ci non accada ancora ? Dunque un problema ci che fa da ostacolo tra uno stato attuale ed uno stato desiderato. Una soluzione ad un problema rappresenta la ricerca di elementi innovativi in grado di farci raggiungere lo stato desiderato. Dunque affinch esista un problema deve realmente costituire un ostacolo e spesso riconducibile a cause precise ! Tuttavia, esistono problemi dei quali non sappiamo trovare la causa. Ci sono problemi che hanno talmente tante cause che non si possono eliminare tutte. Ci sono problemi dei quali siamo in grado di trovare la causa ma che non riusciamo a rimuovere (pu darsi che la causa sia di natura umana). Tali problemi non possono essere risolti con lanalisi, perch ? Perch occorre progettare anche un processo, un modo per procedere che serva in questi casi ! Il fatto poi che siamo cos impreparati ed impotenti ad affrontare problemi di questo genere dovuto alla minima importanza attribuita dalla scuola alla progettazione. La progettazione utilizza le informazioni e la logica e ricorre a caratteristiche di creativit che deviano spesso dal nostro scema rigido e schematico di vedere le cose: deviano dal pensiero razionale. Purtroppo pochi conoscono le tecniche del pensiero laterale [8,9,10,11,12] e quasi nessuno le insegna. Dobbiamo allargare laccezione del termine progetto intentendo che non solo ci che potrebbe essere ma che dobbiamo ricorrere ad esso tutte le volte che la routine non sufficiente. Pertanto lanalisi anzicch rivelare la mappa su cui tracciata la strada deve farci partire dallipotesi che la mappa presenti solo landamento del terreno e che noi si deve progettare le strade ! La progettazione alla base dellazione e come tale sempre finalizzata a realizzare qualcosa: creativit allo stato puro ! Purtroppo spesso capita di trovarsi in situazioni di conflitto anche per i progetti. Cosa fare in situazioni conflittuali fra pi progetti? Qui emerge la caratteristica del pensiero occidentale fatta di discussioni, trattative, bracci di ferro, esercizio di forza, etc. Negli Stati Uniti esiste una interessante procedura per la risoluzione di situazioni conflittuali che in alcuni stati prescritta dalla legge ma a cui non si ricorre spesso perch non piace agli avvocati. In situazioni conflittuali normali, entrambe le parti partono da posizioni estreme, sapendo che gradualmente dovranno trattare e lottare per arrivare ad una posizione intermedia di compromesso. Questo modo di progettare la soluzione comporta un enorme perdita di tempo e di denaro. Nella procedura alternativa le due parti non si incontreranno mai. Ciascuna progetta una soluzione ragionevole; queste vengono sottoposte ad un giudice arbitro che deve scegliere quale delle due pi ragionevole nellinteresse delle parti. Questo il motivo per il quale entrambe le parti si sforzeranno ad elaborare una soluzione ragionevole. Tutto limpegno polemico e di discussione adesso viene speso nella progettazione della migliore soluzione. Se entrambe le parti hanno fatto un buon lavoro nella progettazione di una soluzione ragionevole non avr pi importanza quale delle due il giudice sceglier. Non un gioco a 2

somma zero nel quale chi vince porta via la posta e laltro resta senza. I vincitori saranno entrambe le parti ! Ma laspetto interessante che in questa procedura tutta lattenzione rivolta alla progettazione anzicch alla discussione ! Questultima metafora ci fa capire come sia importante enucleare dalla attivit di progettazione i concetti che si pongono alla base di essa cercando di eliminare i fronzoli, le discussioni, che portano via solo le energie ed il tempo ma non forniscono le soluzioni. Inoltre ci deve essere un forte atteggiamento verso il pensiero creativo ed il problem solving che governa il processo di costruzione della soluzione. Ma quali concetti dobbiamo tenere nella nostra borsa degli arnesi ? Essi sono i concetti di : astrazione, modello e decomposizione modulare Astrazione funzionale, astrazione sui dati e modello matematico L' astrazione e' un concetto importante in tutte le attivita' della ingegneria, essa e' il risultato di un processo detto appunto di astrazione secondo il quale assegnato un sistema, complesso quanto si voglia, si possono tenerne nascosti alcuni particolari evidenziando quelli che si ritiene essenziali ai fini della corretta comprensione del sistema stesso. L'astrazione e' dunque un importante strumento di lavoro anche in relazione alla fase di progettazione di un sistema software. In generale esistono tre tipi di astrazione: a) astrazione funzionale, b) astrazione sui dati, c) modello matematico. L' astrazione funzionale e' un processo tramite il quale e' possibile costruire una entita' a partire da componenti (sistemi) gia' esistenti. L'entita' cosi' costruita e' vista come indivisibile ed in tal senso essa gode di proprie proprieta' che non dipendono da come essa e' stata definita. In altre parole la entita' non dipende piu' dalla sua struttura interna. L' astrazione funzionale consente di separare le sue proprieta' che appaiono verso l'esterno (cosa fa) dalla sua struttura interna (come lo fa) che resta nascosta come in una scatola nera. Per spiegare questo concetto prendiamo a prestito un esempio riportato in [1] e riguardante un componente fondamentale dell'elettronica: il flip-flop. L'astrazione funzionale flip-flop puo' essere definita a partire dai suoi componenti (resistenze e transistor). La struttura interna serve solo a costruire le proprieta' del flip-flop che diventa una entita' indivisibile ovvero una scatola nera con un certo numero di morsetti di ingresso e di uscita rispetto ai quali sono verificate le proprieta' dell'entita'. Si noti che il processo inverso della astrazione, quello cioe' che conduce dalla scatola nera ai suoi componenti elementari, e' detto processo di decomposizione molto simile a quello di modularizzazione di cui si dira' in seguito. La stessa astrazione funzionale flip-flop puo'essere ottenuta a partire da componenti logiche anzicche' da resistenze e transistori come mostrato in fig.1

Figura 1 - L'astrazione funzionale flip-flop definita in termini di porte logiche.

Le proprieta' del flip-flop di fig. 1 sono dunque relazioni fra le variabili di ingresso e quelle di uscita che sono correnti e tensioni. Tali proprieta' vengono derivate da quelle dei componenti. Tuttavia il procedimento di costruzione delle proprieta' di una astrazione puo' essere piu' o meno complesso in funzione della maggiore o minore adeguatezza della definizione di astrazione usata. Una misura di adeguatezza e' il livello di astrazione dei componenti. Ad esempio, nel caso di un flip-flop, le porte logiche hanno un maggior livello di astrazione dei componenti elettronici e si prestano bene ai fini della caratterizzazione delle proprieta' in quanto non perdono proprieta' nella caratterizzazione del flip-flop rispetto ai componenti elettronici. L'astrazione funzionale e' diffusamente utilizzata nella produzione del software e specificamente nei linguaggi di programmazione attraverso il meccanismo di astrazione procedurale. Infatti il meccanismo di definizione di sottoprogrammi consente di prendere alcuni componenti noti (primitive del linguaggio, altri sottoprogrammi, etc.), di comporli con un insieme di frasi (usando i meccanismi di composizione messi a disposizione dal linguaggio di programmazione) e di rinchiudere il tutto in una scatola nera (il sottoprogramma che si sta definendo) che corrisponde ad una nuova operazione. Le proprieta' della nuova operazione (la sua semantica) dipendono dal modo con cui essa e' stata definita; tuttavia i dettagli della sua definizione non sono visibili da chi, dall'esterno (non avrebbero alcun interesse), voglia usare l'astrazione (sottoprogramma). In tal modo il sottoprogramma si comporta come fosse una operazione primitiva, anzi va' ad arricchire il corredo di operazioni primitive gia' messe a disposizione dal linguaggio (librerie, etc.). Non esiste alcuna differenza sostanziale fra le operazioni definite con il meccanismo di astrazione (sottoprogramma) da quelle preesistenti nel linguaggio. L'unica differenza e' di tipo sintattica. L'astrazione funzionale consente di astrarre solo funzionalita' di livello superiore ma nulla dice su cio' che e' possibile fare sui dati di Ingresso/Uscita (I/O) (i quali non vengono coinvolti in questa operazione). 4

L' astrazione sui dati e' un processo tramite il quale vengono sostituiti ai dati di un sistema altri dati piu' semplici (dati astratti). Tale procedimento causa quasi sempre anche una astrazione funzionale perche' cambiando i dati cambiano anche i componenti che li usano. L'astrazione sui dati e' utile ed importante perche' essa contribuisce a semplificare ulteriormente le proprieta' della entita' che si sta definendo. A tal proposito si faccia riferimento al solito esempio del flip-flop di fig. 1. L'astrazione sui dati si puo' basare sulla seguente considerazione: per i dati di I/O non interessa l'insieme dei possibili valori di tensione ai morsetti di ingresso e di uscita ma solo due classi di valori. Tale informazione puo' essere rappresentata da un solo bit. Inoltre i dati che riguardano l'alimentazione o la terra possono essere trascurati (perdita di alcune caratteristiche dovute al passaggio di livello di astrazione) senza che si leda la generalita' della descrizione del flip-flop. Facendo riferimento al cambiamento dei dati dovuta alla astrazione sui dati deve mutare anche la astrazione funzionale (rispetto alla fig.1) che risulta essere la funzione logica NOR. Tale astrazione e' riportata in fig. 2.

Figura 2 - L'astrazione sui dati per il flip-flop

Con l'astrazione riportata in fig. 2 le proprieta' del flip-flop sono definibili utilizzando l'algebra di Boole (2). In informatica una astrazione sui dati e' realizzata mediante i meccanismi che consentono la definizione dei tipi di dato astratto e disponibili nei linguaggi di programmazione piu' recenti. Il tipo di dato astratto e', sostanzialmente, un costruttore di tipo; cioe' mette a disposizione nuovi tipi a partire da quelli esistenti (primitivi) e le operazioni che si possono effettuare sul tipo di dato astratto. Sicche' i valori del nuovo tipo sono ottenuti da altri tipi gia' noti ed eventualmente da astrazioni operate sui tipi primitivi. Tutti i dettagli relativi alla realizzazione del nuovo tipo vengono tenuti nascosti nella "scatola nera" della astrazione e l'utente conosce solo le proprieta' del nuovo tipo e le operazioni che su di esso si possono compiere. Va' sottolineato come, per l'utente, non esista alcuna differenza fra tipi primitivi e tipi costruiti mediante astrazione. Per chiarire meglio il concetto di tipo di dato astratto si pensi al tipo intero in un qualsiasi linguaggio di programmazione. Esso e' definito per astrazione del tipo bit; cioe' ogni numero intero e' in realta' una sequenza di bit per cui anche le operazioni che

vengono adoperate sui numeri interi sono delle astrazioni funzionali (sottoprogrammi) che realizzano invece tediose operazioni su stringhe di bit ! Si capisce come sia importante la definizione del dato astratto. Il modello matematico, in quanto astrazione, differisce da quelle descritte sinora in quanto tramite esso non viene costruito nulla di nuovo a partire degli oggetti esistenti. In altre parole gli elementi che compaiono nel modello matematico non hanno alcun legame con gli oggetti che costituiranno una possibile realizzazione. Tali oggetti sono invece di natura matematica (funzioni, variabili, insiemi, etc) e tramite essi si esprime il fatto che le proprieta' che l'utente osserva dall'esterno del modello sono le stesse del sistema che si intende modellare. Come esempio semplice consideriamo il seguente: Si abbia una leva di bracci b1 e b2, con il fulcro posto fra la forza F e la resistenza R. Quale rapporto deve esistere fra la forza e la resistenza affinche' la leva resti in equilibrio ?

Figura 3 - Esempio di modello matematico: la Leva

Naturalmente il modello che ci viene in aiuto e' quello simbolico-matematico per cui F= (b1/b2)*R. Per tornare all'esempio del flip-flop SR, il suo modello matematico e' mostrato in fig. 4

s 0 0 1 0 0

r 0 0 0 1 0

q 1 0 X X X
Figura 4 - Il modello matematico del flip-flop

q* 1 0 1 0 ?

I Modelli La definizione di modelli matematici e' chiaramente una astrazione molto piu' potente nel senso che consente di caratterizzare le proprieta' del sistema in maniera indipendente dalle sue possibili realizzazioni. La definizione di un modello riveste, nel campo del software, una attivita' importante che va' sotto il nome di definizione delle specifiche funzionali di un sistema software. Tale attivita' oltre ad essere una fase importante molto creativa, e' preliminare alla risoluzione di un problema nel senso che e' sicuramente il punto di partenza per una qualsiasi metodologia. In altre parole, non e' possibile risolvere un problema se prima non lo si rappresenta in una qualche forma astratta ! Pensate solo che gli antichi babilonesi non possedevono nessun sistema formale per la rappresentazione dei problemi (non possedevano le formule) ma ci non gli ha impedito di costruire complicati algoritmi per la risoluzione di problemi (lo vedremo nella parte dedicata agli algoritmi di questo tutorial). Non obiettivo ora addentrarsi nei modelli ma ne vorrei descrivere i tratti generali quasi come se non dovessimo usarli per nulla per applicazioni nel campo software (o hardware). Allora possiamo fare le seguenti riflessioni: a) la struttura e la complessita' del modello dipendono dallo scopo per cui esso viene costruito, b) Il modello deve contenere tutti gli elementi significativi per chi lo usera', c) Il modello e' sempre una semplificazione ed un'astrazione della realta', d) Il modello e' uno strumento di comunicazione d'informazioni per altri o per se stessi. Da ci segue che i modelli possono essere classificati rispetto all'uso al seguente modo: 1) predittivo, 2) descrittivo, 3) prescrittivo. I modelli utilizzati in informatica sono del secondo tipo. In particolare un esempio di modello descrittivo potrebbe essere quello di fig.5.

Figura 5 - Modello descrittivo di un frammento di programma

Tale modello (fig. 5 parte destra) in realta' consiste nella descrizione delle informazioni di ingresso e di uscita che entrano a far parte del sistema stesso. I modelli predittivi sono, ad esempi,o quelli che vengono usati per le previsioni metereologiche. Di quelli prescrittivi ne abbiamo una chiara percezione e sono leben note: ricette del medico. Lo studio dei modelli davvero una delle sfide intellettuali molto stimolanti della ingegneria del software potremmo dedicarci veramente molto tempo purtroppo lo scopo di questo articolo ci impedisce di scendere a fondo su tale tema. I Principi dei Metodi di Progettazione Il metodo normalmente seguito per progettare consiste nello stabilire le specifiche di progetto che determinano una specie di forma da riempire con determinati contenuti. Ad esempio se stiamo progettando unautomobile potremmo porci le seguenti specifiche: linea attraente, capacit di trasporto passeggeri adeguata, stile aereodinamico, motore ad alto rendimento, impiego di componenti standard, buona manegevolezza, facilit costruttiva, buon livello degli optional, etc. Il progettista dovrebbe attenersi a queste specifiche ed il risultato che si otterrebbe sarebbe adeguato. Una specie di ottimizzazione conseguita ricombinando concetti noti in modo da raggiungere leffetto desiderato ! Il secondo metodo consite nello sviluppare nuovi concetti creativi ed originali e poi vedere come dare loro forma in modo da adattarli alle specifiche. In questo caso le specifiche servono per dare forma ai concetti. Questa seconda impostazione presenta un grado di rischio pi grande, ma ha maggiore probabilit di dare luogo a qualcosa di veramente nuovo. Un architetto pu proporsi di soddisfare tutte le specifiche di un progetto di un nuovo edificio: spazio, illuminazione, facilit di comunicazione, efficienza energetica, aspetto attraente, servizi generali computerizzati, etc. Un altro architetto pu scegliere una specifica fondamentale (che potrebbe essere limponenza estetica o lo spazio ambiente di lavoro) e poi sviluppare concetti che permettano di soddisfare in maniera originale questa specifica. Una volta raggiunto questo risultato, il progettista cerca poi di rispettare le specifiche. In termini di strategia militare la differenza fra questi due metodi di progettazione analoga a quella che esiste tra una avanzata metodica su tutto il fronte e lo sfondamento del fronte nemico con la creazione di una testa di ponte (3). Il lettore avr gi identificato le due scuole di pensiero per la progettazione messe a confronto ed avr attribuito ad esse la giusta importanza, collegandole allarticolo precedente ! Nel primo caso uno sforzo a tutto campo con dispiego di energie, nel secondo caso lapproccio degli antichi romani: divide et impera. Di seguito vedremo come tale strategia pu essere condotta per risolvere i problemi di varia natura allo scopo di pervenire ad una metodica utile per la programmazione.

Lutilit di un approccio sistematico ai problemi


Per risolvere problemi occorre saper sfruttare le conoscenze acquisite, lesperienza accumulata e possedere una certa abilit, tutto questo sovente non sufficiente a garantire il raggiungimento dello scopo. E necessario disporre di un approccio sistematico che, anche se non garantisce il raggiungimento della soluzione, permette di sfruttare al meglio le capacit di un risolutore, di individuare di volta in volta i nodi di difficolt e di garantire quantomeno lavanzamento dei lavori.

Quando si affronta un problema semplice spesso non ci si accorge dellimportanza di un approccio sistematico in quanto le prime fasi dellanalisi vengono svolte in modo quasi inconscio ed automatico, se invece il problema presenta un certo grado di complessit risulta quasi naturale affrontarlo con metodo. In questo caso un buon lavoro di preparazione risulta essenziale in quanto sottili sfumature, quasi irrilevanti allinizio, possono in seguito diventare nodi critici di difficolt. Naturalmente un metodo sistematico di analisi non deve essere considerato una camicia di forza in cui imbrigliare intuito e fantasia, ma come valido strumento da affiancare ad essi. Ad esempio cambiare la ruota bucata ad unautomobile o cuocere un uovo potrebbero essere problemi di una certa complessit specie se eseguiti per la prima volta questo perch i neofiti non hanno a disposizione una procedura di esecuzione gi pronta !

Strategie per la risoluzione dei problemi


I problemi vengono spesso presentati in maniera confusa. Il fatto pu essere intenzionale, come in una rivista di enigmi, dove la soluzione di un problema crea maggiore difficolt e giustifica lesistenza del ruolo interpretato dalla persona capace di risolverli. La confusione pu essere accidentale e pi spesso la osserviamo nella vita quotidiana. Un modulo da compilare, una richiesta inviataci da un ente pubblico, un estratto conto bancario, possono diventare dei veri e propri rompicapi se non sono stati pensati in maniera da dare adito ad interpretazioni di natura personale. La confusione infine pu essere emozionale. Il caso di una incidente, di un pronto soccorso etc possono essere problemi che lesecutore non riesce a risolvere in quanto non riesce a trovare la serenit e la limpidezza giusta per farlo. La cattiva formulazione di un problema un fatto dannoso quando, muovendoci verso la ricerca della soluzione, approdiamo a risultati che ci paiono corretti ma che non sono corrispondenti ai desideri del committente. Pertanto prima di ricercare le soluzioni occorre tentare di riformulare il problema proposto in modo da eliminare ogni tipo di ambiguit presente nel testo originale. Per fare questo proponiamo di seguito una serie di regole, dettate dal buon senso e dalla pratica. Prima regola Evidenziare i reali obiettivi del problema Paolo riuscito finalmente a convincere Francesca a uscire con lui stasera: Come comportarsi? Questo per Paolo un problema ? Solo dopo essersi interrogato sui propri reali sentimenti egli in grado di riformulare il problema originale in modo da esplicitare gli obiettivi che prima erano sottintesi o poco chiari. Come comportarsi con Francesca stasera in modo da creare i presupposti per una amicizia duratura ? Oppure Paolo vuole cucinarsi un uovo Solo dopo essersi interrogato su quali sono i suoi reali desideri, anche verificando lesistenza degli ingredienti e la modalit con al quale intende preparare il lauto pasto, egli pu riformulare gli obiettivi in Paolo vuole cucinarsi un uovo al tegamino Quindi abbiamo imparato che i problemi sono pressocch irresolubili (aperti) quando non siamo capaci di evidenziare, avendo effettuato una analisi della situazione, i reali obiettivi. 9

Seconda regola

Evidenziare regole e dati impliciti


Un gruppo di amici ritrovandosi in un bar vuole giocare un sistema al totocalcio Bisogna dividere il costo totale delle schedine in parti uguali fra i partecipanti Apparentemente il problema sembra essere semplice ma: 1. non si tiene conto che esso deve essere risolto nellambito dei numeri reali 2. i tagli delle monete sono fissi e le quote da versare devono essere compatibili con essi. La prima e la seconda condizione impongono alcune condizioni. Intanto che le divisioni devono essere fatte in maniera da approssimare alla seconda cifra significativa in quanto bisogna contemperarsi al taglio delle monete disponibili (0.05, 0.10, 0.20, 0.50, 1,0, 2,0 ) ed effettuare un arrotondamento in modo che la distribuzione sia giusta. Allora i l problema riformulato potrebbe essere: Bisogna dividere il costo totale della schedina tra i partecipanti in modo che, tenendo conto dei valori delle monete a disposizione, le eventuali differenze tra le singole quote risultino minime Osserviamo che, esplicitando dati e regole, si reso necessario modificare lobiettivo. Terza regola

Eliminare i dettagli inutili e le ambiguit nelle ipotesi


Individuare linsieme delle operazioni che deve svolgere un cuoco professionista per cucinare un uovo Il problema molto semplice nella sua essenza ma formulato in maniera ambigua. Intanto non si dice come luovo debba essere cucinato e poi non ha alcuna importanza il fatto che il cuoco sia professionista o sia lo stesso lettore stesso! Quindi prestare la massima attenzione ai dettagli inutili.

Ricerca della Soluzione


Una volta formulato correttamente il problema bisogna pervenire alla sua soluzione. Lattivit sarebbe troppo faticosa se tutte le volte dovremmo muoverci come se ogni problema costituisse un caso isolato. Per fortuna molti problemi si somigliano e sono spesso correlati fra loro. Una regola del tutto generale quella di individuare eventuali similarit con altri problemi. Nel mondo degli algoritmi ad esempio gli algoritmi di ordinamento hanno molte cose in comune. Dunque se noi riusciamo a trovare un problema simile a quello che dobbiamo risolvere (e del quale conosciamo il procedimento) possiamo sfruttarlo per dare risposta al quesito iniziale. Un esempio se vogliamo cucinare un uovo sodo invece che quello al tegamino abbiamo un problema pi semplice da risolvere, possiamo lavorare su questultima (ricetta) e poi trasferire il procedimento risolutivo su quello pi complicato (uovo al tegamino) costruendone la ricetta per differenza e riusando le azioni comuni. In questo caso si potrebbe parlare di parziale isomorfismo. Lisomorfismo diffuso nei giochi (es. filetto e scarabeo numerico) 10

Due problemi infatti si dicono isomorfi quando durante il processo risolutivo gli stati (insieme delle variabili del processo risolutivo in un certo istante e le azioni delluno possono essere messi in corrispondenza biunivoca (uno a uno) con quelli dellaltro. Il lettore provi a trovare quali sono le azioni isomorfe nelle due ricette (cottura delluovo al tegamino) e cottura delluovo sodo. Siccome in generale difficile trovare relazioni di isomorfismo spesso possibile trovare solo relazioni di somiglianza (similitudine fra problemi) ed anche in questo caso possiamo tentare di estrarre dalla condotta risolutiva nota dei buoni suggerimenti per il nostro problema (es . ordinamento selection sort e ordinamento bubble sort).

Scomposizione di problemi
Non realistico pensare di risolvere un problema in un solo colpo. Spesso nella ricerca di soluzioni si pu articolare un problema in sottoproblemi in modo tale che, risolvendo questi ultimi indipendentemente, si possa giungere alla soluzione del problema originale. Questa operazione viene compiuta: fissando, durante il processo risolutivo, una serie di sottobiettivi, ciascuno dei quali individua sottoproblemi su cui puntare lattenzione; procedendo in una scomposizione attraverso raffinamenti successivi che deve essere spinta a definire uno o pi sottoproblemi facilmente risolvibili (problemi primitivi). E chiaro quindi che la definizione di problema primitivo non assoluta ma dipende dalle conoscenze e capacit del risolutore. Formuliamo un semplice esempio per meglio chiarire quanto detto: Supponiamo che il problema sia Individuare linsieme delle operazioni che deve svolgere un cuoco per cucinare un uovo al burro Problema cucinare un uovo al tegamino Sottoproblema 1 procurarsi gli ingredienti Sottobiettivo 30g. di burro (azione elementare) Sottobiettivo 10g. di sale (azione elementare) Sottobiettivo 1 uovo (azione elementare) Sottobiettivo 1 fornello (azione elementare) Sottobiettivo 1 tegamino (azione elementare) Sottoproblema 2 cuocere luovo Sottobiettivo Apri il frigorifero (azione elementare) Sottobiettivo Prendi burro (azione elementare) Sottobiettivo Prendi uovo (azione elementare) Sottobiettivo Prendi un tegamino (azione elementare) Sottobiettivo Accendi il fornello (azione elementare) Sottobiettivo Metti il tegamino sul fornello (azione elementare) Sottobiettivo Versa il burro nel tegamino (azione elementare) Sottoproblema Quando il burro assume un colore dorato, rompi il guscio delluovo e fai scivolare albume e tuorlo nel tegame (azione non elementare) Sottobiettivo Far cuocere finch lalbume sar rappreso ed il tuorlo morbido (azione non elementare) Sottobiettivo salare (azione elementare) Sottoproblema 3 servire luovo 11

Sottobiettivo servire nel tegamino (azione elementare) Come si pu notare abbiamo suddiviso il problema in sottoproblemi ciascuno dei quali ha pi sottobiettivi. Quando abbiamo stabilito dei sottoproblemi, sospendiamo il lavoro sul problema e poniamo la nostra attenzione al sottoproblema e quindi ai sottobiettivi relativi (azioni elementari o non elementari). Quando tutti i sottobiettivi sono stati raggiunti possiamo riprendere il lavoro sul problema originale. I sottoproblemi possono, a loro volta, contenere altri sottoproblemi come visto nellesempio precedente. La regola principale che non esistono regole fisse per la ricerca di appropriati sottoproblemi: creativit, intuizione, esperienza devono guidarvi in questo lavoro. Inoltre evidente che, nella risoluzione di un problema, la sequenza di esecuzione delle azioni non risulta prefissata apriori; mentre invece sono possibili un insieme possibile di sequenze di esecuzione. Il lettore provi, nel caso della cottura delluovo al tegamino, ad ipotizzarne almeno tre.

Riferimenti

5. Riflessioni e Conclusioni
L' astrazione e' un concetto importante in tutte le attivita' della ingegneria, essa e' il risultato di un processo detto appunto di astrazione secondo il quale assegnato un sistema, complesso quanto si voglia, si possono tenerne nascosti alcuni particolari evidenziando quelli che si ritiene essenziali ai fini della corretta comprensione del sistema stesso. L'astrazione e' dunque un importante strumento di lavoro anche in relazione alla fase di progettazione di un sistema software e, nella fattispecie di un algoritmo. Il concetto di astrazione rappresenta uno dei fondamenti per la progettazione dei sistemi comunque complessi esso conduce alla modularit ed al divide et impera ma ha molto a che vedere con la osservazione del mondo circostante in termini di oggetti e classi. E una formidabile caratteristica della mente umana che consente di vedere loceano anzicch la singola goccia dacqua, il tutto anzicch la parte senza curarsi molto dei dettagli. I modelli rappresentano lo strumento attraverso il quale viene concretizzata una astrazione (pu essere un disegno di un edificio per larchitetto). I metodi di progettazione rappresentano una sfida creativa-intellettuale e servono a dare vita alle specifiche funzionali del progetto.

12

Il problem solving realmente uno strumento potente per la risoluzione dei problemi. Gli studenti sono inizialmente molto diffidenti perch credono nel culto della complessit: anni ed anni di insegnamenti in questo senso hanno fatto il danno! Quando inizialmente gli si dice:dovete pensare in maniera semplice spesso mi chiedono: perch ? da subito non apprezzano che la semplicit una virt anzi pensano che il modo pi facile per sentirsi superiori quello di fingere di capire ci che gli altri non sono in grado di capire. Invero ci non accade solo fra gli studenti ! Ma la questione si chiarisce subito appena si mettono allopera perch capiscono ben presto che si originano fra loro due tipologie di gruppi: i doers ed i describers. I primi, i doers, hanno la necessit di agire e quindi amano la semplicit che vuol dire anche efficienza. I secondi, i describers, hanno orrore della semplicit sembra sentirli esclamare una cosa che pu essere capita da tutti come pu essere seria ?. Tuttavia anche questi ultimi dovendosi scontrare realmente con i problemi capiscono che sono sulla cattiva strada.

Bibliografia
[1] H. Wang, Dalla Matematica alla Filosofia, Boringhieri, 1974. [2] Z. Manna, Teoria Matematica della Computazione, Boringhieri 1978. [3] B. Russel, I Principi della Matematica, Longanesi & C, 1980. [4] Goedel Esher, Bach, Uneterna ghirlanda brillante [5] M. Eigen, R. Winkler, Il Gioco: le leggi naturali che governano il caso, Adelphi, 1986. [6] D. R. Hofstadter, D.C. Dennet, L IO della mente, Adelphi, 1985. [7] H.T. David, A. Mendel, Bach Reader, New York, New York, W.W. Norton, 1966 [8] Watzawick, Pragmatica della comunicazione umana. [9] Ed. De Bono, Creativit e pensiero laterale, Rizzoli editore, 1998. [10] Ed. De Bono, Essere Creativi, Il Sole 24 Ore, 1998. [11] Ed. De Bono, Sei Cappelli per Pensare, Rizzoli editore , 1996. [12] Alex Osborn, Applied Imagination, 1935 (metodo del brainstorming) [13] Ed. De Bono, Il meccanismo della mente, BUR editore, 2002. [14] L.A. Maciaszek, Sviluppo di sistemi informative con UML, Addison-Wesley, 2002. [15] S. Bennet, J. Skelton, K. Lunn, Introduzione a UML, McGraw-Hill, 2002. [16] I. Jacobson, G. Booch, J. Rambaugh, The Unified Modeling Language, user Guide, 1999 [17] P. Krutchen, Rational Unified Process, Addison Wesley, 2000. [18] I. Jacobson, G. Booch, J. Rambaugh, The Unified Software Development Process, 1999. [19] S. K. Chang, E. Hassanein and C. Y. Hsieh, A Multimedia Micro-University, IEEE Multimedia Magazine, Vol. 5, No. 3, July-September 1998, 60-68. [20] Illinois Virtual Campus, see http://www.ivc.illinois.edu (1999). [21] A. Calvani, M. Riotta, Fare Formazione in Internet, Manuale di didattica on line, Erickson, 2001 [22] G. Trentin, Dalla formazione a distanza allapprendimento in rete, Franco Angeli, 2001 [23] T. K. Shih, et altri, A survey of Distance Education Challenges and Technologies, International Journal of Distance Education Technologies, vol. 1(1), January-March 2003, Idea Group Publishing, pp. 1-21. [24] Von Clausewitz, Pensieri sulla guerra,BiT, 1995 [25] H. D. Rombach, V. Basili, Quantitative Assessment of Maintenance: An Industrial Case Study, 1987, IEEE. [26] R. S. Pressman, Principi di Ingegneria del Software, Mc Graw Hill, 1999. [27] J. Conallen, Build Web Application with UML, Addison Wesley, 2000. [28] P. Maresca, Collaboration environment: le nuove tecnologie multimediali per la didattica, Atti del congresso Didamatica 2000 sezione lavori scientifici, Cesena , 4-6 Maggio 2000, pp. 258-266. [29] P. Maresca, Apprendimento personalizzabile in un ambiente collaborativo per la didattica universitaria di primo livello , Atti del congresso Didamatica 2001 - sezione lavori scientifici, Bari, 35 Maggio 2001, pp. 284-292. [30] F. Numaker, Collaborative Computing: The next Millennium, Cover Feature, Computer (32), 9 September 1999, pp. 66-71.

13

[31] R.T. Kouzes, J.D. Myers, and W.A. Wulf, Collaboratories: Doing Science on the Internet, Computer, vol. 29, n. 8 pp. 40-46, August, 1996 [32] M. Page-Jones, Progettazione ad Oggetti con UML, Apogeo, 2002 [33] M. Maiocchi , Ipertesti, Franco Angeli, 2000 [34] B. Fadini, P. Maresca, S. Russo, Un approccio alla valutazione di piattaforme per le-learning basate su standard di qualit ISO, Didamatica 2002 - sezione lavori scientifici, Napoli, 14-15 Febbraio 2002. [35] P. Maresca, T. Arndt, A. Guercio, Unifying Distance Learning Resources: The Metadata Approach, Journal of Computers, vol. 13(2), June 2001, Computer Society of the Republic of China, pp. 60-76. [36] T. Arndt, S. K. Chang, A. Guercio, P. Maresca, An XML-Based Approach to Multimedia Software Engineering for distance learning, International Journal of Distance Education Technologies, vol. 1(1), January-March 2003, Idea Group Publishing, pp. 1-21. [37] J. Ma, and R. Huang, Towards an Integrated Educational System for Global Teaching and Learning, The International Conference on Distributed Multimedia System (DMS'99). [38] W.N. Holmes, The myth of the Educational Computer, Computer (32),9 September 1999, pp. 36-42. [39] L. Harasim, A Framework for Online Learning: The Virtual U, Computer (32),9 September 1999, pp. 44-49. R. Barbuti, M. Bellia, P. Degano, G. Levi, Principi e Tecniche di Progettazione del Software, F. Angeli, 1987 B. Fadini, C. Savy, Elementi di Informatica, Liguori, 1998 Von Clausevitz, Pensieri Sulla Guerra, Editoriale Opportunity Book, 1995

14