CORSO DI INGEGNERIA DEL SOFTWARE. Prof.ssa Mongiello A. A 2013/2014

Transcript

1 POLITECNICO DI BARI CORSO DI INGEGNERIA DEL SOFTWARE Prof.ssa Marina Mongiello A. A 2013/2014 1

2 CORSO DI INGEGNERIA DEL SOFTWARE Prof.ssa Marina Mongiello Telefono: Pagina Web: sisinflab.poliba.it/mongiello Orario di ricevimento: Giovedì mattina II piano del DEI. Ai fini del corso è necessario svolgere un tema d anno il cui intento è quello di essere impegnati costantemente con ciò che si fa in aula. Questo tema d anno dovrà essere consegnato l ultimo giorno di lezione e verrà svolto in gruppo (max 3 persone). IL TEMA D ANNO NON INFLUIRA IN ALCUN MODO SULLA VOTAZIONE. Per quanto concerne l esame, esso è strutturato in : Una prova scritta che prevede un esercizio di progettazione, uno di programmazione(linguaggio C) e una domanda di teoria. I testi di riferimento sono: Sommerville Ingegneria del software Pressman Ingegneria del software Di volta in volta verranno indicati capitoli e libri specifici per ogni argomento. 2

3 INTRODUZIONE AL CORSO Il corso di Ingegneria del software si occupa di capire come si arriva al codice. Viene dedicato un intero corso a ciò poiché si deve entrare nell ottica di sistemi software che non sono più piccoli programmini, ma sistemi di grosse dimensioni che prevedono e necessitano di uno studio preliminare. Oltre a ciò però, il corso si occuperà anche di un approfondita fase di analisi dei costi, analisi del mercato, aspetti temporali, competenze (team) ecc.. Questo viene fatto perché bisogna avere un quadro completo di tutto ciò che compone un sistema software. ARGOMENTI DEL CORSO: PROCESSO SOFTWARE: in informatica il termine processo ha una sua precisa connotazione,esso è un entità dinamica. Il programma è formato da una serie di esecuzioni,infatti quando si manda in esecuzione il programma, istante per istante, si verranno a creare varie configurazioni. La serie di queste configurazioni è il processo, per cui possiamo dire che il processo è il programma in esecuzione. Il processo software è la dinamica secondo cui le varie fasi che concorrono alla realizzazione di un sistema software vengono articolate. Le fasi possono essere articolate secondo vari modelli: Modello a cascata secondo cui le fasi sono strettamente sequenziali e propedeutiche (Se non finisce la prima fase non può partire la seconda). Questo modello ha però subito dimostrato dei limiti e per questo sono stati sviluppati modelli più dinamici. Sviluppo agile secondo cui il codice andava scritto senza alcuna documentazione, in modo da essere più snello. Ma anche ciò dimostrò di avere dei limiti perché poteva andare bene per piccoli programmi. Modello iterativo; Modello incrementale. Ma cosa è un modello? Un modello è un astrazione di una realtà, uno schema. Tutto ciò che noi faremo sarà espresso in termini di modelli. PROGETTO SOFTWARE: inteso come gestione del progetto e non stesura. Si occuperà quindi dello studio delle risorse, della tempistica ecc ecc e per tutto l arco temporale di realizzazione del progetto si controllerà se ci si sta attenendo alle previsione fatte. FASI DEL PROCESSO SOFTWARE: ANALISI DEL DOMINIO: durante questa fase si analizzano e si creano modelli di quel dominio per sapere cosa il sistema deve essere in grado di fare. Dall analisi del dominio si tirano fuori i requisiti. Questi ultimi si possono anche negoziare col cliente. Cosa sono i requisiti? Sono funzionalità, ma anche altre richieste. Perciò si possono distinguere due tipi di requisiti, i requisiti funzionali e i requisiti non funzionali. Alla fine di tutto ciò si potrà estrapolare una modellazione che verrà espressa nel linguaggio che si preferisce. Si utilizzano 3

4 però, linguaggi standardizzati, ossia che utilizzano un certo protocollo. Universalmente è riconosciuto lo standard UML (Unified Modeling Language). Conclusa la fase di analisi si prosegue con: PROGETTAZIONE: In questa fase si sceglie che modello utilizzare, come strutturare il sistema e in particolare si progetta ogni singolo componente. IMPLEMENTAZIONE: alla fine di questa fase si ha il programma. TEST: con il test si può dire se il sistema è funzionante o meno. Ma sulla base di cosa posso stabilire se funziona o meno? Quanto più è ampio il range di dati su cui vado a fare il test tanto migliore sarà la probabilità che il programma sia corretto. LA CERTEZZA NON SI POTRA MAI AVERE! Non si potrà mai stabilire al 100% la funzionalità del sistema semplicemente perché i dati che posso inserire sono infiniti. E stato anche sviluppato un teorema che afferma e dimostra che, il fatto che il programma sia corretto, non è decidibile in maniera algoritmica. Dato questo vincolo, quello che si fa con il test è andare a controllare le situazioni di errore previste durante la fase di analisi. Alla fine verrà valutata la qualità del sistema. QUALITA DEL SISTEMA: come si stabilisce? Il programma per essere di qualità deve rispondere alle funzionalità richieste ma anche ai requisiti non funzionali, i quali a volte possono essere in contrasto tra loro. Si definiscono delle METRICHE DI PRODOTTO grazie alle quali si danno delle misure alla manutenibilità e ai principi che compongono essa. VERIFICA E VALIDAZIONE: se il sistema che si vuole creare è un software che controlla il traffico aereo e lo si vuole testare, ovviamente non avrebbe senso far partire gli aerei e accorgersi dopo che c è qualche errore. Bisogna ricorrere a metodi più affidabili, non ci si può più basare solo sul test ma bisogna procedere o con simulazioni o con metodi più rigorosi che assicurino l assenza di errori. Questi metodi sono detti METODI FORMALI e utilizzano linguaggi formali. Il linguaggio formale è un linguaggio la cui sintassi e il cui vocabolario sono limitati, e utilizza regole molto rigorose. Un esempio noto di linguaggio formale è il linguaggio di programmazione. I metodi formali si usano quindi in sistemi critici ove ad esempio o è a rischio la vita delle persone, o riguardano problemi economici. FUNCTION POINTS: quando ci si addentra in contesti di pubblica amministrazione o azienda bisogna fare un accurato studio dei costi e bisogna valutare quanto vale la retribuzione per quel sistema software. Per fare ciò vi sono dei modelli di stima dei costi. Tra i più famosi troviamo il CO.CO.MO. Negli ultimi anni però si sta utilizzando molto il metodo dei punti funzione, secondo cui non si valuta più il lavoro in base alle ore che l uomo impiega nel svolgere l attività ma in base a ciò che la persona fa. Per far ciò vi sono metriche non banali da cui poi si tira fuori la valutazione. Un altro metodo che si affianca alle metriche punti funzione è quello che utilizza le metriche USE CASE(più in voga negli ultimi anni). 4

5 PROCESSO SOFTWARE Il processo descrive tutta la sequenza delle varie fasi che si susseguono per arrivare allo sviluppo di un sistema software che, essendo un sistema complesso, non può avere sviluppo immediato. E una dinamica temporale che decide in che sequenza far susseguire le diverse fasi. Il processo è talvolta detto ciclo di vita. Ciò che studieremo sono i diversi modelli(schemi) secondo cui le fasi si alternano. Nel corso degli anni sono stati sviluppati vari modelli, ma si può dire che NON c è un modello migliore in senso assoluto rispetto a un altro, poiché va sempre contestualizzato e scelto in base al contesto. In un contesto di non-modello ossia il code- n fix, si colloca lo sviluppo dell ingegneria del software. Il code- nfix era formato da attività casuali, non organizzate, che dava vita a risultati come progetti non gestibili, caotici, difficilmente modificabili. I primi modelli che vennero creati rientrano nella categoria detta PROCESSO PRESCRITTIVO, cioè un processo secondo fasi predefinite. Il primo è il MODELLO A CASCATA, nato nel 1970, secondo cui le fasi si susseguono in maniera sequenziale. La caratteristica ed il grande vincolo di questo modello è il non poter ritornare a fasi precedenti. Ad esempio se si riscontrava un errore in fase di programmazione non si poteva rifare l analisi ma si doveva procedere con il rifare da capo tutto il codice. SCHEMA MODELLO A CASCATA La prima fase è la studio di fattibilità, che non è una fase informatica, ma è una verifica di costi e risorse che mi permette di capire ciò che posso o non posso fare. La fase successiva è quella di analisi e specifica dei requisiti, ossia uno studio del dominio, l individuazione dei requisiti e l imposizione di vincoli. Nella fase di progettazione i requisiti devono essere trasformati in specifiche tecniche. Successivamente si procede con la programmazione e test di unità, dato che siamo in un ottica modulare non ci sarà mai un blocco unico ma tanti blocchi separati per cui si può pensare di testare i 5

6 blocchi uno alla volta e poi unirli e testarli nuovamente nell insieme. Fare quindi un test di unità e un test di integrazione. Infine la manutenzione che si svolge nell arco del tempo. Il sistema deve presentarsi bene ad eventuali interventi dall esterno. Dati i limiti esposti prima, di questo modello si sono proposte due varianti: CASCATA CON PROTOTIPAZIONE, secondo cui si realizza un prototipo, un esempio funzionante dall inizio senza aspettare tutte le fasi. CASCATA CON RITORNI, che consente al termine di ogni fase di ritornare sulle precedenti e apportare modifiche. Dopo lo sviluppo del modello a cascata si trovano il modello incrementale e il modello evolutivo. Nei modelli incrementali è come se si avesse una cascata con ritorno. In quelli evolutivi si fa tutto e però poi si possono aggiungere e avere tante versioni diverse del prototipo fino a quando non si ottiene la versione definitiva. Tra i modelli evolutivi quello di riferimento è il MODELLO A SPIRALE ideato da Boehm. Il processo ritorna sempre su se stesso e ogni volta si pianifica la fase successiva. Ci si affida molto alla dinamicità del sistema. Tra le caratteristiche vi è una forte interazione col committente e uno studio economico molto più approfondito e forte. SCHEMA MODELLO A SPIRALE 6

7 Possiamo ancora trovare altri modelli, i modelli specializzati al processo unificato che non sono a sé stanti ma possono essere integrati con altri modelli. Precisamente lo sviluppo a componenti è una pratica di progettazione che dobbiamo necessariamente utilizzare quando si realizzano sistemi distribuiti, per garantire la modularità. Il PROCESSO UNIFICATO è un modello di processo che definisce le fasi ed è fortemente legato all utilizzo dell UML. Lo SVILUPPO AGILE(2001) è un modello secondo cui è inutile la documentazione e tende a snellire la programmazione. L EXTREME PROGRAMMING(XP), è una programmazione estrema senza alcuna documentazione e con un codice estremamente complesso. 7

8 UML UML = UNIFIED MODELING LANGUAGE. Questo linguaggio di modellazione deriva dall unificazione di tre diversi approcci di modellazione che si sono sviluppati con la programmazione orientata agli oggetti(oop). Quali sono i principi delle OOP? Ereditarietà; Polimorfismo; Incapsulamento. Cosa è l ereditarietà? E una relazione tra classi. Una relazione è una corrispondenza tra due insiemi. Una classe è un tipo di dato astratto che in particolare definisce degli attributi e dei metodi. Parliamo quindi di dati e di funzioni. I dati, ossia le informazioni che vengono gestiti dall algoritmo, sono caratterizzati da un tipo e possono essere costanti o variabili. Il tipo di dato è un insieme di valori che una variabile può assumere e delle operazioni che possono essere eseguite sulla variabile. Le funzioni sono gli algoritmi, ossia sequenze finite di passi che servono a risolvere un determinato problema. Con la programmazione orientata agli oggetti si vuole togliere la separazione tra dati e funzioni per il principio dell Information Hiding (Incapsulamento), ossia per far si che si possa gestire meglio l uso delle variabili limitando l uso solo ad alcune funzioni che hanno bisogno di quelle variabili. L information hiding quindi è un principio insito nella definizione stessa di programmazione orientata agli oggetti. La differenza tra un oggetto e una classe sta nel fatto che l oggetto è un istanza della classe. Cosa è il polimorfismo? Il polimorfismo è quella proprietà grazie alla quale è possibile che funzioni con stesso nome possono svolgere algoritmi diversi a seconda del numero e del tipo di parametri che gli vengono passati. Ad esempio immaginiamo di avere la funzione che calcola l area di un quadrato, di un cerchio, di un triangolo e di un rettangolo. Abbiamo quindi quattro diverse implementazioni di un algoritmo il cui risultato è sempre l area. In un programma strutturata dovrei usare quattro metodi diversi con il vincolo di usare quattro nomi diversi, con la OOP assolutamente no! Avremo una classe padre nominata figura geometrica contenente la funzione che calcola l area e delle classi figlie quali rettangolo, triangolo e quadrato che ereditano attributi e funzioni dalla classe figura geometrica e in ogni classe figlia specificherò come va implementata la funzione del calcolo dell aerea che però avrà sempre lo stesso nome in tutte le classi. Qualunque sia il linguaggio utilizzato il compilatore verifica sempre questi tre livelli: LESSICO, ossia le regole che definiscono il vocabolario. SINTASSI, regole del linguaggio per scomporre le frasi.(il compilatore controlla che la frase si attenga alle regole del linguaggio) SEMANTICA, controllo di corrispondenza tra ciò che è stato dichiarato ed utilizzato, tipo di dati,ecc ecc, dopodiché genera il linguaggio. Abbiamo quindi fatto un quadro degli elementi che ci servono per fare questa modellazione in UML. 8

9 Che cos è un caso d uso? Prendiamo la definizione che risale al 1995 di uno degli autori del linguaggio stesso secondo il quale è una serie di transizioni di un sistema il cui compito è produrre un risultato di valore misurabile per uno o più attori del sistema. Il caso d uso stabilisce cosa accade nel sistema in seguito ad un evento di attivazione. Esattamente un caso d uso è una particolare funzionalità, descritta mediante messaggi scambiati da un entità e gli attori. Cosa è l entità? E un sistema, un sottosistema, una classe ecc. L attore è una qualunque entità esterna. Lo scopo della descrizione dei casi d uso è di rendere comprensibile il funzionamento, o almeno l individuazione delle funzionalità da realizzare, anche a persone che non sono esperte dell informatica. Dove si collocano? Nella prima fase, quindi nella fase di Analisi che risulta essere la fase più astratta, concettuale, quella in cui si fa lo studio del dominio, poi si procede con l individuazione dei requisiti, una volta tirati fuori i requisiti per rendere univoca la comprensione usiamo i casi d uso. L aspetto fondamentale è quello di descrivere il contorno di tutto il sistema. Tra attore e caso d uso c è una qualche relazione di attivazione, per cui quando un attore richiede una funzionalità si deve attivare il caso d uso corrispondente. Generalmente i casi d uso rappresentano solo una porzione dei requisiti ossia quelli funzionali. Tutti i requisiti detti esterni o non-funzionali non vengono rappresentati dai casi d uso. Di un caso d uso dobbiamo quindi definire SINTASSI E SEMANTICA. Non abbiamo un lessico perché come formalismo è elementare. La sintassi è la seguente: Nome caso d uso SEMANTICAMENTE il caso d uso ci rappresenta una funzionalità del sistema e quindi un requisito funzionale. Una volta che ho identificato tutti i requisiti ho trovato tutti i casi d uso e questi casi d uso, gli attori, e le relazioni tra di essi li vado a mettere insieme nel diagramma di casi d uso dove ho lo schema di tutta la funzionalità del sistema che mi farà capire in linea di massima quali saranno i compiti del mio sistema. Altri elementi che trovo sono gli attori, da non confondere con gli utenti perché l attore può anche essere un elemento hardware(es. stampante, tastiera ecc ecc) La sintassi dell attore è la seguente: Studente universitario 9

10 Ogni attore ha un nome identificativo scritto sotto la figura dell omino. Terzo elemento sintattico sono le frecce di collegamento, che rappresentano le relazioni, ossia le corrispondenze tra attore e caso d uso, tra caso d uso e attore, tra attore e attore o infine tra caso d uso e caso d uso. Elementi relati Relazione Funzione Notazione Attori Generalizzazione un attore, specializzato, eredita la partecipazione a tutti i casi d uso con i quali l attore specializzante comunica Attore - caso d uso Associazione Esprime la partecipazione di uno o più attori ad un caso d uso Casi d uso Estensione Il comportamento di un caso d uso base può, opzionalmente, essere esteso dal comportamento definito da un altro caso d uso Inclusione Generalizzazione Il comportamento di un caso d uso di base incorpora, sempre, il comportamento dei casi d uso di inclusione Un caso d uso generale ed uno o più specifici casi d uso che ne ereditano ed aggiungono caratteristiche Tra attore e attore ho una proprietà di generalizzazione, ossia una relazione il cui significato è analogo a quello dell ereditarietà. Ho quindi un attore generico e un attore specializzato,quest ultimo ha tutte le proprietà di quello generico con in più delle proprie. La notazione per questo caso è la seguente : Attore generico attore specializzato Tra attore e caso d uso l unica relazione ammessa è lì associazione con la caratteristica che può essere uni o bidirezionale, dall attore al caso d uso, dal caso d uso all attore o entrambe o non specifico nulla. Ho 4 possibilità diverse rappresentate da 4 frecce di collegamento diverse. 10

11 Qual è il significato? Esprime la partecipazione di uno o più attori al caso d uso. Se per esempio abbiamo il caso in cui bisogna creare una password, il guest richiede l inserimento della password e il caso d uso si attiva. (vedere esempio slide 22 della presentazione Introduzione agli use case ) La cardinalità di una relazione è il numero di entità coinvolte da una parte e dall altra. Se la cardinalità è uno a molti significa che a un entità ne corrisponderanno dall altra parte molte. Esempio: Una persone può acquistare n libri, uno stesso libro può essere acquistato da una sola persona. Per quanto riguarda le relazioni tra i casi d uso ne abbiamo di tre tipi diversi: estensione, inclusione e generalizzazione. Il simbolo della relazione di estensione e di inclusione è la freccia tratteggiata. Prendiamo un esempio di estensione. Ipotizziamo di avere un cliente che deve effettuare un prelievo da un conto corrente, deve essere fatto quindi un controllo sulla presenza minimo di importo disponibile. Per fare ciò possiamo pensare di notificare che l importo residuo vada a zero e attivare un caso d uso di notifica azzeramento credito solo nel caso in cui il credito vada a zero. Per questo si chiama relazione di estensione, poiché è quella parte che viene eseguita solo nel caso in cui si realizzi una condizione bene precisa che viene detta condizione di estensione. 11

12 Il punto di estensione è il dato su cui vado a fare il controllo della condizione che mi potrebbe portare nel caso d uso estendente che in questo caso è l importo prelevato. Quando l importo prelevato fa si che si azzeri il credito passo al caso d uso estendente. L altro tipo di relazione è graficamente simile all estensione ma concettualmente è la duale. Il caso d inclusione prevede una parte di codice che viene eseguito sempre, tutte le volte che si esegue il caso d uso includente. Lo porto fuori quindi per una questione di visibilità e per garantire la modularità. Graficamente è rappresentato così: Se devo effettuare un prelievo o se voglio richiedere un mutuo, in entrambi i casi, devo controllare se sul conto c è un certo importo. E dato che devo controllare la stessa cosa in entrambi i casi, invece di ripetere la procedura due volte, la porto fuori e ho un caso d uso che è incluso in entrambi. Qui il verso della freccia è verso il caso d uso incluso. L ultima relazione è quella di generalizzazione, in cui ho un caso d uso più ampio e un caso d uso figlio che specializza quello più ampio. Ad esempio in termini di metodi è il calcolo dell area del cerchio o del rettangolo rispetto al calcolo dell area della figura geometrica. E quindi un esempio di polimorfismo, di over-riding tra classi diverse. Abbiamo quindi ora un quadro completo per realizzare il modello dei casi d uso. Attraverso tutte queste relazioni possiamo esprimere tutto il funzionamento di un intero sistema software a livello astratto, al termine dell analisi dei requisiti. I vari casi d uso, presi singolarmente, possono essere descritti in maniera più precisa perché bisogna formalizzare per bene tutta la sequenza di passi che vogliamo realizzare per avere quella funzionalità. E quindi oltre la rappresentazione grafica possiamo descrivere testualmente ciascun caso d uso. Si 12

13 utilizzano altre informazioni che l UML consiglia come ad esempio quali sono gli attori, se ci sono delle precondizioni o postcondizioni, e ci permette anche di distinguere lo scenario di base da scenari alternativi che possono essere gli insuccessi dello scenario base. 13

14 DIAGRAMMA DELLE CLASSI Il diagramma delle classi serve ad illustrare come è strutturato il sistema. Esso contiene le classi e le relazioni che sussistono tra di esse. Le classi sono formate da attributi e metodi. Il diagramma delle classi non è altro che un modello di dati oltre che un modello del sistema software che si vuole realizzare. Non ci dà un modello dinamico sulle specifiche, non vi è nessun algoritmo masolo una dichiarazione di metodi. Le principali relazioni fra classi sono associazione, generalizzazione e dipendenza. Studieremo in modo più specifico la relazione di associazione e quella di generalizzazione. La relazione di associazione è una relazione semantica tra due o più classi, questa relazione semantica viene in realtà trasferita tra le istanze delle classi, ossia gli oggetti, e quindi quando si implementerà quella relazione graficamente tracciata nel diagramma delle classi diventerà a livello di codice qualcosa che permetterà di legare due o più oggetti, ed è sempre bidirezionale. L associazione può essere individuata o assegnando un nome alla relazione o individuando i ruoli per le entità che sono coinvolte. Vediamo un esempio: Azienda 0..1 DatoreLavoro 1..* Impiegato Persona In questo caso abbiamo un azienda e una persona, due classi con propri attributi e metodi. La relazione che posso avere tra queste due classi, rappresentata graficamente dalla linea che le congiunge, è che la persona lavora nell azienda e l azienda dà lavoro alla persona. Oppure posso leggere la relazione in termini di ruoli e quindi la persona è un impiegato o dipendente(ruolo) mentre l azienda è il datore di lavoro. La differenza sta nel fatto che la relazione esprime un azione che collega le due classi mentre il ruolo caratterizza la classe relativamente all altra. Inoltre le relazioni hanno una molteplicità che si esprime sulla linea in prossimità di una o dell altra classe. Esempio: L azienda dà lavoro a una o più persone, la persona è impiegata in 0 o 1 aziende. Per implementare alcune relazioni, non tutti i linguaggi di programmazione hanno dei costrutti ben precisi. Per realizzare l associazione tra due classe devo realizzare un mapping, usando in una e nell altra classe un attributo dell altra classe. Ad esempio in azienda metterò un attributo di Persona e in persona metto un attributo di Azienda. Se la relazione è uno a molti metterò una lista di attributi dell altra classe. Ovviamente l associazione si realizza a run-time. A livello statico non avrò mai un collegamento tra classi! 14

15 Ecco un esempio: IMPLEMENTAZIONE UNO A UNO (C++) USO DELL ASSOCIAZIONE UNO A UNO IMPLEMENTAZIONE ASSOCIAZIONE UNO A MOLTI 15

16 USO DELL ASSOCIAZIONE UNO A MOLTI(C++) L aggregazione come la composizione è un esempio particolare di relazione di associazione, in cui sostanzialmente abbiamo diverse parti che messe insieme ci danno una classe aggregata. Una classe contenitore e classi contenute all interno. Per l aggregazione valgono le proprietà transitiva ( se A è parte di B, e B è parte di C, allora A è parte di C) e antisimmetrica ( se A è parte di B, allora B non è parte di A). La caratteristica della proprietà è che a run-time l oggetto contenuto sopravvive all oggetto contenitore. Un esempio classico è quello dell automobile che può essere considerata una classe aggregata di carrozzeria e motore, posso avere il motore costruito da un azienda e la carrozzeria da un altra azienda, esse unite danno vita all automobile. Come capisco che si tratta di aggregazione? Dal fatto che entrambe le parti hanno vita propria anche separate. Se ad esempio durante un incidente la carrozzeria si distrugge e il motore rimane intatto, il motore potrà essere riutilizzato e viceversa. Parti distinte con vita propria che messe insieme danno vita a una classe con proprie caratteristiche. Come si crea l aggregazione? Devo definire dei riferimenti alle istanze aggregate nella parte privata della classe aggregante. Definire riferimenti significa sostanzialmente definire dei puntatori o un qualcosa che mi possa far ricollegare alla parte aggregata. Bisogna poi definire delle operazioni per creare il collegamento tra le diverse classi. Prendiamo l esempio dell automobile, abbiamo detto che essa deriva dall aggregazione tra carrozzeria e motore, per cui immaginiamo di avere tre classi: automobile, carrozzeria e motore e di avere nella parte privata della classe automobile i riferimenti alle classi carrozzeria e motore, e poi un metodo che permetterà di mettere in relazione tra loro le parti provenienti dalle altre classi. Bisogna poi definire motore e carrozzeria, si definisce il puntatore e si richiama il metodo che crea,attraverso i puntatori di carrozzeria e motore, l automobile. 16

17 La differenza sostanziale tra l aggregazione e la composizione sta nel fatto che le classi componenti non hanno vita propria al di fuori della classe composta. La classe componente è responsabile della creazione e della distruzione degli oggetti componenti, e le classi componenti sono ad uso esclusivo della classe composta. L ultima relazione è quella di generalizzazione che rappresenta una relazione gerarchica. Quindi avremo una superclasse con delle classi figlie poste a un livello inferiore che però ereditano le proprietà delle classi superiori. Queste classi figlie però, oltre ad ereditare le proprietà della superclasse, hanno delle loro proprietà specifiche che le specializzano. La relazione si legge come è un tipo di (leggendo dal basso verso l alto) o Può essere un (leggendo dall alto verso il basso). Ad esempio, tra gli animali, ho i vertebrati, gli invertebrati e così via. La classe animali è la classe superclasse, mentre vertebrati, invertebrati e così via sono tutte sottoclassi con una propria peculiarità. Le classi specializzate ereditano attributi e metodi. La sottoclasse può contenere nuovi attributi e può ridefinire gli attributi della superclasse. Possiamo pensare alle figure geometriche, per tutte si calcola l area o il perimetro ma in ogni figura geometrica(triangolo, quadrato ecc) cambiano le variabili e i calcoli, per cui esso va ridefinito di classe in classe. La sintassi per la relazione di generalizzazione prevede l uso della parola chiave <<extends>>. Esempio: class Cerchio extends FormaGeometrica. La classe Cerchio estende la classe FormaGeometrica. 17

18 DIAGRAMMA DI STATO Il diagramma di stato è la rappresentazione grafica di un grafo. Cos è un grafo? E una coppia ordinata di insiemi, l insieme di nodi e l insieme di archi. E una funzione che ci permette di creare dei collegamenti tra i nodi mediante delle transizioni. Il diagramma di stato quindi è una formalizzazione grafica di quelle situazioni in cui l oggetto che sto considerando, assume dei comportamenti diversi a seconda degli stati in cui si trova. Per effetto di vari eventi si passa da uno stato a un altro e quindi il comportamento dell oggetto di studio varia. Lo stato è la condizione che un oggetto ha nel corso della sua vita. Nello stato l oggetto soddisfa determinate condizioni ed è in attesa di eventi che fanno mutare il suo stato e il suo comportamento. Finché non si verifica nessun evento, l oggetto persiste nello stesso stato. Supponiamo di essere nel contesto di un sistema che gestisce l ingresso e l uscita di libri in una biblioteca. Il libro può quindi essere disponibile, può essere stato prestato o può essere stato smarrito. Possiamo rappresentare graficamente la variazione di stati del libro, in seguito ad eventi innescanti, tramite il seguente diagramma. Caso 1) Il libro si trova nello stato di disponibilità(acquisto), viene prestato e passa nello stato di Prestito, cambia quindi il suo stato a seguito dell evento innescante del prestito. Supponendo che entro la data utile per la restituzione, l utente restituisca il libro alla biblioteca, si ha un altra transizione che fa sì che il libro ritorni nello stato di disponibilità (Acquisto). Dopo ciò vado verso lo stato finale solo quando finisce la vita del libro, se ad esempio è ormai troppo rovinato, altrimenti il libro sarà sempre nello stato disponibile. 18

19 Caso 2) Il libro viene prestato, ma non vengono rispettati i termini di consegna. Se l utente riconsegna il libro con qualche giorno di ritardo, il libro ritornerà ad essere disponibile. Se invece, il libro non viene restituito poiché è stato ad esempio smarrito o danneggiato, e quindi non ritornerà più nella biblioteca, il libro passerà nello stato finale e verrà cancellato dalla biblioteca. DIAGRAMMA DI INTERAZIONE Il diagramma UML che ci permette di rappresentare le interazioni è il diagramma di sequenza. Esso è la notazione più leggibile delle interazioni tra più oggetti, e rappresenta la sequenza temporale delle azioni da eseguire. I diagrammi di sequenza derivano dai casi d uso, per cui per ogni caso d uso abbiamo un diagramma di sequenza. E caratterizzato da vari oggetti, i quali sono: Tempo Oggetti La linea della vita (LIFELINE) I messaggi Eventuali valori di ritorno dei messaggi Iterazioni Il tempo riferito all interazione tra i diversi oggetti è rappresentato orizzontalmente. L oggetto è in alto al diagramma rappresentato con un rettangolo contenente il nome. In verticale abbiamo un rettangolo che rappresenta la LIFELINE dell oggetto, e si estende dal punto in cui l oggetto viene istanziato fino a quando viene distrutto. La linea tratteggiata verticalmente rappresenta il tempo riferito al singolo oggetto. Ecco un semplice esempio grafico: : Cliente Istanziazione dell'oggetto Tempo Distruzione dell'oggetto Oggetto 19

20 Un esempio grafico dei messaggi scambiati tra i vari oggetti è il seguente: C è inoltre la possibilità di descrivere il valore di ritorno di un messaggio. Se ad esempio un cliente invia la richiesta di disponibilità di un prodotto, ci si aspetta un valore di ritorno che quantifica i prodotti disponibili e viene rappresentato nella maniera seguente: : Cliente : Stampante disponibilita( ) quantità disponibile È possibile indicare il valore restituito da un messaggio (mostrato da una linea tratteggiata) Si possono rappresentare messaggi di auto delega e di iterazione. Esempi: : CorsodiLaurea : Studente * [per tutti gli studenti iscritti ] getinfo( ) L'iterazione è indicata dal simbolo * La condizione di iterazione è indicata tra parentesi quadre Ritorniamo ora all esempio del libro di cui si è parlato nei diagrammi di stato. 20

21 Nell esempio le classi sono stereotipate, ossia non viene usato il rettangolo con il nome come rappresentazione, ma un simbolo diverso per dare un significato a ciascuna classe relativamente al livello a cui si trova nell architettura. Abbiamo un esempio di uno scenario in cui avviene la richiesta di prestito di un libro. L ultimo diagramma UML che studiamo è il diagramma implementativo delle componenti. Cosa sono le componenti? Possono essere porzioni di sistema che scriviamo, parti riusabili rese già sostituibili, altri sistemi, sottosistemi esterni o parti di software. Per esempio in un applicazione client-server le componenti sono proprio il client e il server, ossia parti distinte che interagiscono tra di loro. Poiché il sistema è complesso, bisogna quindi tracciare un modello che faccia capire quali siano le componenti, in che relazione sono e come interagiscono, e ciò viene fatto dal DIAGRAMMA DELLE COMPONENTI. I Componenti del nostro sistema sono solo entità logiche, ossia che non sono mappabili sulla macchina direttamente. Il diagramma delle componenti è perciò solo a livello logico. Vediamo un esempio: 21

22 L altro tipo di diagramma che rappresentiamo per modellare l architettura è il diagramma di configurazione, che raffigura gli elementi così come sono a run-time, ossia in esecuzione. Esso rappresenterà quindi, non solo le componenti, ma anche i processi. Non vengono rappresentate le componenti che non esistono a run-time, ad esempio quelle compilate separatamente. Graficamente la simboleggiatura è la seguente: 22 Client-server a tre livelli.

23 SISTEMI DISTRIBUITI Cosa è un sistema distribuito? Sono dei sistemi per i quali l elaborazione è distribuita. Non è detto che essa debba essere distribuita fisicamente, ma la cosa fondamentale è che i componenti di elaborazione siano distribuiti e quindi non uniti in un unico blocco. Che vantaggi offre? Condivisione delle risorse, che comporta maggiore efficienza, riduzione dei costi, riduzione di ridondanza, distribuzione del carico. Scalabilità, ossia possibilità di variare struttura del sistema senza stravolgere ciò che si ha già ed è vantaggioso dal punto di vista di manutenibilità. Fault tolerance,collegato all affidabilità, perchè viene garantito che, nel caso in cui un componente venga meno, gli altri riescano comunque a lavorare. Per quanto riguarda gli svantaggi abbiamo: Maggiore complessità sia a livello di struttura sia a livello di gestione Poca protezione, poiché è un sistema aperto e bisogna lavorare per capire e progettare la sicurezza, la protezione, la riservatezza dei dati e dell applicazione stessa; Non prevedibile, perché ho tante entità che interagiscono quindi è più facile che si inneschi un meccanismo non previsto dal sistema. Partiamo con l analisi delle ARCHITETTURE MULTI-PROCESSORE. Un architettura multiprocessore è fondamentalmente una struttura hardware. Questo implica che,a differenza del modello classico, ossia a processore singolo, si hanno più processori e la possibilità di eseguire più processi sui singoli processori. L utilizzo di tali architetture è molto comune nei sistemi REAL TIME, ossia quei sistemi in cui l aspetto temporale è determinante, sistemi critici dal punto di vista del tempo. In un architettura multi processore i processi possono essere eseguiti su unico processore, ma ovviamente è necessario l uso di uno scheduler, un particolare processo che pianifica l esecuzione dei diversi processi su un processore in base ad algoritmi classici. Se si utilizzano processori multipli ovviamente l efficienza migliora ma aumenta anche la complessità e si utilizza un dispatcher, un processo che effettua il controllo del traffico e delle allocazioni tra processi e processori. Che differenza c è tra scheduler e dispatcher? Lo scheduler è la componente del SO che si occupa di allocare il processo al processore, dare l ordine. Mentre il dispatcher si occupa solo di controllare il traffico, di gestire le diverse allocazioni tra processo e processori distinti. Se abbiamo un sistema formato da processi multipli non è detto che sia un sistema distribuito, come ad esempio i sistemi operativi. Nei sistemi distribuiti abbiamo componenti distribuite che interagiscono sfruttando le risorse della rete. Le architetture multiprocessore sono una prima categoria dei sistemi distribuiti. Consideriamo ora il secondo tipo di architettura distribuita,ossia il Client-Server, che è più semplice da comprendere sia per la modellazione sia per il funzionamento. Esamineremo in maniera panoramica questi 4 tipi di architetture: 23

24 1. Client-Server; 2. A oggetti distribuiti;. 3. Peer-to-peer; 4. A sistemi distribuiti. In tutti e quattro questi modelli è fondamentale il ruolo del MIDDLEWARE, che è una componente software finalizzata a gestire la comunicazione delle diverse componenti del sistema stesso. Le componenti infatti, possono essere scritte con linguaggi diversi, o possono funzionare su piattaforme diverse, perciò tutte queste incompatibilità vengono gestite dal middleware. E standardizzato e quindi a seconda della tecnologia scelta si sceglierà un middleware piuttosto che un altro. Che cos è una architettura Client-Server? La caratteristica di una architettura Client-Server è quella di avere appunto un Server che fornisce dei servizi e un insieme di Client che usufruirà di quei servizi. Bisogna fare attenzione però alla differenza fra aspetto logico e fisico, perché quando si parla di Client - Server ci si può riferire sia alla macchina sia al processo, ossia programma in funzione su quella macchina. Dal nostro punto di vista ci si riferisce ai processi, quindi parleremo di Client- Server sotto l aspetto logico. La caratteristica dei Client è che non percepiscono l esistenza di altri Client mentre conoscono il Server poiché con esso interagiscono. Diversi processi server possono essere eseguiti su uno stesso processore, infatti se più client si collegano e chiedono diversi funzionalità, di quel server vengono eseguiti processi diversi ma su una stessa macchina ed è qui che sta la difficoltà di gestione. Sappiamo che una qualunque applicazione deve essere in qualche modo strutturata, bisogna dare un impostazione al codice in modo che sia leggibile. In generale un applicazione è organizzata in tre livelli: Presentazione; Elaborazione;. Parte dati. Dati questi tre livelli vediamo come un architettura Client-Server si presta bene a implementare questo tipo di strutture. Se stiamo realizzando un sistema distribuito, ogni strato dell applicazione deve avere una strutturazione in tre livelli dell applicazione che andiamo a realizzare. Le architetture Client-server possono essere a vari livelli. Posso avere un solo livello Client e un livello server, o tre livelli: client, server e terzo livello, oppure livelli multipli: Il client ed N livelli con caratteristiche affini ai Server. Se si ha un architettura a due livelli essa può essere di due tipi: Thin Client ( A Client leggero) Fat Client (A Client Pesante) Se si ha un architettura a Client leggero, il server sarà ovviamente pesante poiché su di esso cadrà tutta l elaborazione mentre il Client svolgerà solo l azione di Interfaccia e di invio dei comandi. Lo svantaggio è ovviamente l appesantimento del server e il forte utilizzo della rete che verrà richiamato ogni qual volta verrà fatta una richiesta dal Client ed inoltre la potenza del Client non verrà sfruttata al massimo. Se invece ho un architettura a Client pesante, l elaborazione è svolta in parte dal Client oltre al lavoro di presentazione. Il server oltre al lavoro di elaborazione gestisce le transizioni sul 24

25 DATABASE. Un esempio classico è quello del Bancomat, per un motivo di sicurezza e perché c è una continua interazione. Lo svantaggio ovviamente sta proprio nella complessità, infatti una modifica comporterà un notevole lavoro di adeguamento. In generale un organizzazione a due livelli avrà svantaggi a livello di scalabilità, prestazioni, e complessità. L altro tipo di architettura client-server è quella a tre livelli che si mappa perfettamente sulla struttura logica dell applicazione: la presentazione sarà su client, l elaborazione sarà sul livello centrale e la gestione dei dati su un terzo strato. I processi possono essere eseguiti su macchine distinte, ed alcuni livelli possono essere sulla stessa macchina ma il fatto che si abbia una maggiore strutturazione fa sì che le prestazioni aumentino. Ad esempio se ci si trova davanti a un sistema di internet banking,si avrà il database dei clienti e quindi un mainframe che si occuperà solo della gestione dei dati, poi si avrà un server web che fornisce i servizi applicativi( login, transazioni, gestione conto ecc) e infine il client dell utente finale che grazie al browser interagisce con il resto del sistema. Vantaggi: Separando il database dal server si possono usare protocolli più veloci, si ha migliore gestione dei dati soprattutto dal punto di vista della sicurezza e della protezione dei dati perché il server in tal modo non ha accesso ai dati. Miglior bilanciamento del carico. Estendendo il modello a tre livelli posso ottenere un architettura a n livelli, quando ad esempio le applicazioni devono accedere a dati di database diversi o se si struttura il server in più livelli server. E necessario nel caso in cui si abbiano più database server, un server applicativo che lavori per l integrazione dei dati, in modo da unirli in un solo formato da inviare al resto dell applicazione. Confrontiamo quindi ora le architetture a tre livelli con quelle a due, analizzando i vantaggi e gli svantaggi dell una e dell altra. Abbiamo già notato come le architetture a tre livelli garantiscano una maggiore scalabilità rispetto a quelle a due, e un maggiore bilanciamento del carico. Si ha un minore traffico di rete, infatti quelle a due livelli intasano la rete perché c è una continua richiesta al server, invece se il server è su più livelli il traffico è più distribuito. Più la struttura è a livelli, migliore sarà la manutenibilità, la facilità di aggiornamento e la modificabilità. La latenza è minore in una struttura a tre livelli, perché essendoci una divisione dei compiti la risposta arriva più rapidamente, a differenza di quella a due livelli in cui fa tutto il server. Quando è preferibile usare l architettura a due livelli a client leggero, a due livelli a client pesante, o l architettura a tre livelli? Per quanto riguarda le architetture a Client leggero, esse si usano preferibilmente in sistemi ereditati, di vecchio stampo,realizzati con linguaggi obsoleti. Non avendo strumenti per modificarli, si usa un interfaccia di connessione per renderli accessibili in rete, senza stravolgere tutto il funzionamento. Il server è quella che era prima l applicazione e si pone solo un interfaccia di connessione. Oppure in applicazioni a calcolo intensivo,come i compilatori, in cui nel client ho solo l interfaccia, e l elaborazione, che essendo complessa è difficile da rendere distribuita, in unico server. Oppure ancora applicazioni in generale che hanno intensa elaborazione sui dati. E preferibile il Client pesante in applicazioni di calcolo grafico, matematico o in ambienti in cui è necessario che l utente abbia interazione maggiore con il sistema. A tre livelli invece quando si hanno dati memorizzati in database o elaborazione intensiva di dati. Oppure quando bisogna integrare dati provenienti da fonti diversi. Il modello Client-Server ha però dei suoi svantaggi. Infatti esso è scarsamente flessibile,e la scalabilità e il bilanciamento del carico non sono impliciti. 25

26 Per questo esistono altre architetture, sempre basate su componenti, in cui però il vincolo che ci sia un componente che fornisce servizi e un componente che richiede servizi, decade. Si avranno più componenti in grado sia di richiedere che fornire servizi agli altri componenti. Una struttura abbastanza complessa, con tecnologie di implementazione altrettanto complesse. La caratteristica è che anche qui è presente un middleware, più complesso di quello presente su un Client-Server, che in architetture di questo tipo viene chiamato ORB, Object Request Broker. Si tratta di un architettura aperta, molto scalabile, flessibile. Il sistema può essere riconfigurato dinamicamente. L aspetto progettuale importante è il fatto che le decisioni su dove devono essere collocati i diversi servizi, non devono essere stabilite a priori come nel Client-Server. Si può in corso d opera aggiungere o modificare le funzionalità. Studiamo per esempio un applicazione di vendita al dettaglio. Essa può essere strutturata in base a diversi approcci: Modello logico di un architettura a oggetti distribuiti, in cui le funzionalità sono i servizi o la combinazione di servizi (controllo merci, ordinazione, ecc). Modello Client-Server, in cui tutto va sul server e il client si occupa solo dell interfaccia nei singoli punti vendita. Esempi in cui è preferibile usare architetture a oggetti distribuiti: catena di negozi o sistemi data mining, ossia sistemi in cui a partire da diversi insieme di dati si vogliono ricavare informazioni su particolari aspetti. Vantaggi e svantaggi: Maggiore complessità rispetto al Client-Server. Più efficiente, prestazioni migliori in determinati applicativi Una caratteristica importante dal punto di vista implementativo è data dalle tecnologie che devono essere utilizzate. Nell architettura a oggetti distribuiti possono essere integrate componenti con linguaggi diversi. Il compito del middleware o il broker ha il compito di integrare queste differenze ed è proprio un pattern architetturale. In generale il Middleware deve garantire la comunicazione a livello logico e a livello di componenti. Passiamo ora ai modelli di calcolo distribuito inter-organizzativo, considerando i due seguenti modelli di calcolo: Peer-to-peer; Architettura orientata a servizi; Si chiama inter-organizzativo perché, a differenza delle architetture a oggetti distribuiti che solitamente vengono utilizzate per realizzare applicativi nel contesto aziendale, dove tutti i nodi è come se fossero circoscritti a livello organizzativo enon c è un accessibilità dall esterno, questi due modelli sono i modelli più aperti sulla rete, come ad esempio i sistemi che permettono la prenotazione di un viaggio, in cui servizi diversi, forniti da applicativi diversi che non hanno nessuna affinità tra di loro, vengono collegati dinamicamente quando l utente fa la sua richiesta. Non c è uno schema predefinito dell architettura, ma c è il vincolo che ogni servizio deve trascrivere le proprie funzionalità in un formato dati conosciuto anche dagli altri, essere recuperabile da un elenco di tutti i servizi possibili ed esporre un interfaccia facilmente integrabile negli applicativi che si dovranno ad esso connettere. Queste sono le differenze sostanziali tra un architettura a oggetti distribuiti e un architettura a servizi distribuiti. 26

27 Vantaggi: I servizi possono essere forniti da fornitori che sono sia dentro che fuori del sistema. Esiste una sorta di catalogo pubblico di servizi. Ciò comporta un elevata affidabilità,perché se in quel momento richiedo un servizio da un applicativo che non è in funzione posso immediatamente rimpiazzarlo con un altro, e quindi risulterà sempre minore la situazione in cui una funzionalità non posso essere fornita, perché il sistema è in grado di individuare subito un altro applicativo che fornisce la stessa funzionalità. Il fornitore può riconoscere nuovi servizi, quindi alta adattabilità, scalabilità, riconfigurabilità. Vincolo del pagamento, talvolta i servizi sono a pagamento Le applicazioni sono reattive, quindi si adattano al contesto. Nel peer-to-peer abbiamo invece una struttura decentralizzata, dove tutte le elaborazioni possono essere svolte dai singoli nodi della rete, e lo scopo è quello di condividere le risorse di calcolo tra diversi computer presenti su una rete anche di dimensioni notevolmente ampie. I sistemi p2p sono utilizzati principalmente per sistemi personali, in cui si vogliono condividere file, messaggeria istantanea o comunicazione diretta con gli utenti. L architettura logica della rete è la stessa del sistema. L applicazione in genere è comunque basata su componenti che possono essere distribuiti sui singoli elementi dell architettura hardware sottostante. L architettura logica(software) può essere decentralizzata o semi-centralizzata. Nell architettura decentralizzata ogni nodo può essere a conoscenza degli altri nodi e scambiare direttamente informazioni, i nodi sono organizzati in località e pertanto alcuni nodi fungono da ponte tra un nodo e un altro. Non solo perciò dei singoli elementi funzionanti ma sono anche dei commutatori nella comunicazione. Ovviamente si ha ridondanza, che può essere sia un vantaggio che uno svantaggio, poiché essa protegge il sistema dal verificarsi degli errori, e over-head del sistema perché la stessa ricerca può essere elaborata da diversi nodi e quindi si ha maggiore comunicazione e sovraccarico del sistema(svantaggio). Nell architettura semi-centralizzata invece, uno o più nodi svolgono funzioni tipo Server, che indirizzano la comunicazione verso altri nodi, quindi si ha un minimo di gerarchia ma l applicazione funge sempre come se non ci fosse un server. Rispetto all architettura a servizi distribuiti il P2P è più efficiente, però essendo in connessione 1 a 1 si ha una maggiore esposizione ai rischi di protezione. E preferibile non utilizzarli in ambienti lavorativi. Abbiamo quindi categorizzato i sistemi distribuiti da un punto di vista software con questi quattro modelli, che ci definiscono le caratteristiche generali secondo cui i componenti dell architettura del sistema interagiscono. Conoscere questi quattro modelli però non ci basta perché le architetture e i sistemi software da realizzare sono molto complessi e quindi ci occorre fornire ulteriori linee guida per integrare i diversi componenti. Per questo passiamo ai Pattern architetturali. Sappiamo che ci sono dei modelli architetturali e a seconda di questi modelli posso scegliere quali pattern architetturali utilizzare. Un pattern software è la descrizione strutturata di una soluzione a un problema software ricorrente. Ad esempio se ho un architettura a servizi, so che ci sono tante componenti distinti che comunicano, che ci deve essere un interfaccia,che ci deve essere un catalogo con relativi servizi 27

28 forniti però l architettura non mi dice altro e ho bisogno di scegliere pattern architetturali per capire come integrare questi servizi soprattutto perché l integrazione avviene dinamicamente. I pattern possono essere classificati in : Pattern architetturali (livello più astratto), che modellano lo schema organizzativo di una struttura nell ambito di un architettura software. Mi fa capire come i vari componenti possono interagire tra loro, come far avvenire la comunicazione con il database ecc. Pattern di design: prendo ogni componente, in ogni componente abbiamo i package in cui vi sono le singole classi. Anziché modellarle in maniera empirica posso raggrupparle utilizzando degli schemi predefiniti(design pattern) che rendono più elegante lo schema delle classe e che risolvono una determinata problematica. Pattern di implementazione(frame work), livello di minore astrazione perché siamo nella fase di scrittura del codice. Partiamo dai pattern architetturali. Ipotizziamo di modellare un sistema software, ipotizzando di utilizzare il processo unificato, abbiamo concluso la fase di ideazione e quindi abbiamo individuato i requisiti funzionali e non, che ci permettono di capire che architettura utilizzare e come organizzare i componenti. In questo ci possiamo avvalere dei pattern architetturali. I pattern non sono tutti uguali ma possono essere raggruppati a seconda dei problemi che risolvono, ad esempio abbiamo famiglia di pattern che risolvono i problemi di come il sistema si deve interfacciare al database. Oppure abbiamo l insieme dei pattern che gestiscono la comunicazione dei componenti nel sistema distribuito, ed è l insieme più ampio ed importante dato che la comunicazione è un aspetto molto importante nei sistemi a oggetti distribuiti. Poi abbiamo tutti i pattern che si occupano dell interfaccia. O ancora i pattern che si occupano di come modellare i componenti sul livello client, sul livello server, e sull application server. Altri pattern importanti sono quelli che gestiscono l application e l extend. E poi abbiamo i pattern che gestiscono i problemi di sincronizzazione, ossia quando si hanno delle risorse condivise bisogna sincronizzare l accesso alla risorsa. Pattern per problemi di concorrenza,secondo cui diversi processi richiedono l uso di un determinato processo e pertanto bisogna schedulare l accesso alle risorse nonché la concorrenza,e poi problemi di gestione delle risorse. I pattern relativi alla decomposizione del sistemi in sottosistemi sono i più numerosi, partendo dai requisiti vedo come posso organizzare il sistema avvalendomi di alcuni pattern come ad esempio il Layer ( modello a strati, esempio: sistema operativo),domain Model, Domain object. Abbiamo poi una seria di pattern che modellano la comunicazione nei sistemi distribuiti, il più importante è il PATTERN BROKER. Sul modello Broker è strutturato il middleware. L altro gruppo importante è quello dei pattern che supportano l interazione uomo macchina, e i più importanti sono il Model View Controller e il Presentation abstraction Control. I pattern non sono indipendenti, alcuni sono in alternativa, altri lavorano in sinergia, in più si possono mettere insieme per risolvere problemi più grandi. Se si rappresentano tutti otteniamo un enorme struttura che collega tutti i pattern in maniera diretta. Analizziamo quindi in dettaglio alcuni di essi: LAYERS E il modello che separa le funzionalità dei singoli componenti. Ogni livello fornisce funzionalità a livelli superiori, ma i livelli superiori sono trasparenti pertanto funziona come una macchina virtuale. Posso modificare un livello senza modificare gli altri. 28

29 DOMAIN MODEL Modello concettuale. La prima fase che si realizza è l analisi del modello di dominio. Lavora nell ottica della modularità DOMAIN OBJECT Permette di strutturare un modello di dominio in componenti più specifiche. MODEL VIEW CONTROL Separa l interfaccia dall applicazione. Ci permette di rappresentare il contenuto del Client, del Server, e dell application Server. Quindi rappresenta delle Classi di interfaccia, delle classi di controllo che elaborano la logica di business delle applicazioni, e delle classi entity, che si definiscono nella prima fase di analisi e restano il nucleo di modellazione dei dati. Il controllore conterrà dei package delle classi di controllo, il modello sarà costituito dalle classi individuate in fase di analisi, in vista ci saranno le classi che si occuperanno dell interfaccia. PIPE AND FILTER E generalmente utilizzato nel contesto dei sistemi operativi, nei sistemi real-time e in particolare per sistemi che devono elaborare flussi di dati. L elaborazione viene scomposta in passi di decomposizione e ogni passo viene incapsulato in un filtro, un oggetto software, i dati poi sono trasferiti in filtri adiacenti detti Pipe, che sono immaginabili come tubi, dei canali virtuali dove 29

30 passano flussi di dati. E possibile mettere in relazione famiglie di dati correlati, collegando in maniera adeguata i filtri e i Pipe, creando cosi delle PipeLine. SHARED REPOSITOR Utilizzato per applicazioni a intensa elaborazione dati, in cui ci sono interazioni tra i componenti che non siano guidate da specifici processi, che però possono essere coordinate in base a un set di dati condivisi, un repository. Ho un repository e tutti i processi che lavorano su quel repository.il repository è condiviso, ed è come se fosse a partire dal repository che avviene il coordinamento dei vari componenti e dei vari processi di elaborazione. L accesso ai dati deve essere sincronizzato. DATABASE ACCESS LAYER (DAL) Serve per separare la logica dell applicazione dal modello dei dati. Si ha uno strato di interfaccia tra il sistema e il database management system. Questo strato si occupa delle transazioni di Query. BLACKBOARD E REFLECTION Sono due pattern che permettono la modifica dei requisiti a run time. Il blackboard è utilizzato in sistemi di intelligenza artificiale, per creare una sorta di Lavagna comune su cui tutte l applicazioni possono comunicare. Il reflection consente i cambiare la struttura di un sistema in modo dinamico, strutture dati meccanismi di comunicazione, dividendo l architettura in due livelli, ossia da una parte i Metadati e poi un livello base che contiene la logica applicativa stessa del meta livello BROKER E il pattern principale per la comunicazione nei sistemi distribuiti. Serve per strutturare sistemi distribuiti con componenti disaccoppiate che devono interagire. Rende possibile l invocazione di servizi remoti tra i vari componenti, coordina la comunicazione, gestisce le richieste e le risposte tra i vari componenti di un sistema distribuito e pertanto è particolarmente utilizzato. 30

31 MICROKERNEL Consente di sviluppare un insieme di applicazione che siano l una la variazione dell altra. Il nucleo centrale è sempre lo stesso però possono variare dinamicamente a seconda dei requisiti dell utente o in base al contesto di utilizzo di funzionamento di quell applicazione. Si possono differenziare per l interfaccia utente a seconda ad esempio del Profilo utente esistente. Vediamo ora un aspetto un po più tecnico che riguarda le tecnologie di implementazione. TECNOLOGIE DI IMPLEMENTAZIONE Per tecnologia intendiamo non solo il linguaggio di programmazione ma anche tutti i requisiti ad esso legati. Se si sceglie di usare un particolare linguaggio, si dovrà adattare la struttura del sistema, le specifiche nel codice, le piattaforme da utilizzare e tutto il contesto che c è dietro le tecnologie di implementazione. Prima di parlare di tecnologie diamo una definizione di componente. Cosa è un componente? Per dare questa definizione,entriamo nel merito del modello di processo Component Based, che non è solo un modello di processo perché può essere usato trasversalmente agli altri.e un processo di definizione, implementazione o integrazione di componenti debolmente accoppiati, ossia che abbiano lasca connessione tra loro. Il Component Based Software Engineering nasce dal concetto di modularità e riutilizzo, e si basa su componenti indipendenti e standardizzate, sul middleware e sul processo di sviluppo. Secondo l OMG un componente è una parte modulare, utilizzabile e sostituibile di un sistema che comprende l implementazione ed espone una serie di interfacce. Sostanzialmente un componente è un elemento costitutivo del software. Un componente deve essere standardizzato, indipendente, componibile (si deve poter integrare nelle interfacce pubbliche del sistema), consegnabile e documentato. Se abbiamo un sistema basato su componenti abbiamo un middleware, che è lo strato che troviamo tra il software applicativo e il sistema operativo, e implementa un meccanismo di comunicazione tra processi. La comunicazione tra processi è generalmente nota come IPC (Inter Processing Communication). Essa avviene mediante diversi meccanismi e schemi a diversi livelli. Può avvenire o a basso livello, o a livello di linguaggio di implementazione, o a livello applicativo o mediante software. A seconda di dove avviene la comunicazione, cambieranno le primitive e i meccanismi di comunicazione. A diversi livelli possiamo utilizzare il meccanismo di Pipe (Pipe and Filter), o il socket, che è un canale di comunicazione a livello più basso di quello applicativo, oppure mediante il memory mapped file,quindi a livello hardware, oppure mediante chiamata a procedura remota (RPC), a livello applicativo e sempre a questo livello può essere utilizzato il meccanismo di scambio di messaggio. In base alla modalità secondo cui avviene IPC possiamo caratterizzare il middleware secondo tipologie diverse: Remote Procedure Control, quando abbiamo architetture Client- Server; Remote data access, simili a RPC, tipicamente utilizzate per accedere a basi di dati; Message Oriented middleware; Transaction processing monitor; 31

32 Distributed object, in cui l invocazione dell oggetto avviene tramite il broker. I modelli di componenti possono essere standardizzati, infatti a parte i nostri componenti, ci sono componenti standard che vengono acquistati, integrati nell applicazione e che sono ad esempio quelli del formato Microft.net, nel formato Corba, o nel formato Java beans. Tra i componenti Microsoft troviamo i seguenti: Com, Component Object Model; Dcom, Distributed Component Object Model; Com+, Soap, protocollo a livello ancora più alto nella comunicazione tra applicazioni ed è basato su XML, ossia un linguaggio che ci permette di formattare dei dati, e creare dele strutture nell ambito dei dati. Linguaggi di mark-up..net, componente più standardizzato e moderno per eterogeneità di linguaggio. L OMG (Object management group) definisce lo standard di oggetti per esempio CORBA per oggetti distribuiti. Corba è la tecnologia per implementare architetture a oggetti distribuiti più diffusa,si basa sul broker e garantisce eterogeneità di linguaggi e di piattaforme, ossia posso realizzare applicazione in cui i vari oggetti sono realizzati con linguaggi diversi e funzionano su piattaforme diverse, il middleware Corba permette la comunicazione tra questi oggetti eterogenei e realizzare l applicazione distribuita in cui i componenti sono tutti allo stesso livello. L altro standard é SUN, infatti se standardizziamo i componenti secondo questo meccanismo, la comunicazione avviene tramite RMI( Remote method information), ossia gli oggetti possono essere eseguiti su macchine virtuali diverse e comunicare mediante chiamate a metodi remoti. Gli oggetti si chiamano Java beans, o enterprise java beans se rientrano in una fascia di componenti più complessi. Se invece siamo in un contesto Web e vogliamo realizzare applicazioni Client- server, dobbiamo partire dalla definizione di applicazione web, ossia un sistema che permette ai propri utenti di eseguire la logica di business con un browser (Conallen, 2000). In un applicazione web troviamo una logica di business che può risiedere o sul client o sul server, un browser che è indispensabile per interpretare parte della logica che verrà eseguita sul Client, e pagine web che possono essere statiche o dinamiche. L application server è il server applicativo che monitora lo stato dell applicazione, importante per tenere traccia delle operazioni effettuate, dello stato degli utenti e così via. Ad esempio come monitorare mediante i cookie, rappresenta lo stato dell utente collegato, e ci permette di avere traccia delle operazioni svolte dai diversi Client. Questo è molto utile soprattutto se il numero di utenti è molto elevato. Possiamo rendere dinamica una pagina web tramite uno script, ossia un programma interpretato dal browser. L interprete interpreta ed esegue direttamente istruzione per istruzione, invece il compilatore è un traduttore che dato un programma sorgente genera un programma eseguibile. Sono due fasi distinte, solo che in determinati casi, come in Java, si ha un linguaggio che per metà è interpretato e per metà viene compilato. Quando invece abbiamo la pagina server, possiamo utilizzare diverse tecnologie come le java server pages o le servlet se utilizziamo una tecnologia Java. Abbiamo visto che a livello progettuale il modello logico di un applicazione su un architettura client server, si realizza con il pattern MVC (Model view Control), simile a questo pattern è il 32

33 pattern BCE, Boundary control entità, e trova anche riferimento nell UML. Lo scopo è individuare i confini del sistema, caratterizzare i dati, progettare e implementare la logica di controllo dell applicazione stessa. Il pattern trova una sua diretta configurazione nell UML perché è possibile utilizzare gli stereotipi delle classi stesse: <<Boundary>>. Le classi Boundary sono classi di interfaccia tra l attore e il sistema, e lo scopo è quello di isolare il sistema dai cambiamenti che avvengono nell ambiente esterno e di interfacciare le classi con altri sistemi. Le classi Control sono quelle che si collocano al centro del modello, e quindi nel lato server e gestiscono tutte le operazioni di elaborazione e implementano la logica di controllo delle applicazioni (ad esempio le servlet delle applicazioni Java).sono indipendenti dall ambiene esterno e non sopravvivono all interazione. Infine le classi entità definiscono il modello dei dati, e nascono già in fase di analisi, sono le prime che derivano direttamente dai requisiti. Nelle fasi successive saranno sempre presenti ma saranno affiancate da altre classi (Boundary e Control). A causa del gap esistente tra il modello dei dati relazionali e il modello dei dati ad oggetto, le classi entità rappresentano la modellazione dei dati nell ambito però del nostro sistema, e tramite esse avverrà l accesso dai dati da elaborare che saranno presenti nel database, mediante l utilizzo dell ibms o mediante il DAL che implementerà la logica di accesso al database. Eventualmente si può pensare di inglobare parte di questa elaborazione nel livello entità oppure di aggiungere un ulteriore livello che nella formalizzazione del modello BCE si formalizza con una D per cui diventa BCDE, Boundary Control Entity Database ed è l applicazione di un modello DAL che realizza solo l implementazione delle transazione e delle query. Lo schema grafico è il seguente: Estendendo l architettura a tre livelli a una a N-livelli vengono introdotti un livello USER e uno INTEGRATOR, il primo è molto vicino al livello di presentazione, mentre nel secondo si può prevedere l introduzione di un broker in modo che si integrino dati provenienti da database diversi, e quindi un ulteriore livello in modo da rendere l applicazione mappabile sull architettura a tre livelli. Le applicazioni ENTERPRISE, sono una categoria di applicazioni il cui nome si riferisce sia alle applicazioni che le tecnologie, e sono riferite ad applicativi in un contesto ampio di grossa organizzazione, utilizzate per fornire delle funzionalità di supporto alla logica di business anche per una grossa impresa, al di là del semplice portale che si realizza si può immaginare la stessa struttura però proiettata in un contesto molto più grande e quindi si parlerà di applicazione enterprise. Il meccanismo è lo stesso ma cambia la granuralità e l ampiezza del contesto, cambiano le tecnologie e anche i modelli architetturali. Facciamo ora un piccolo riepilogo di tutto ciò che abbiamo fatto. Ci stiamo occupando di come ingegnerizzare un processo di sviluppo di software e per fare ciò bisogna sia rendere ingegneristico il processo, ossia la sequenza delle fasi necessarie per portare a termine il prodotto, sia definire i criteri secondo cui quel prodotto deve essere realizzato. Per quanto riguarda il processo vi sono vari modelli che si possono seguire, di cui il più moderno è l UP (Processo Unificato) che si modella bene in relazione al linguaggio di modellazione che è l UML. Per quanto riguarda il software da realizzare, lo sviluppo non è d impatto, ma è frutto di un lavoro più o meno approfondito che 33

34 parte dall analizzare il dominio e il contesto di utilizzo e passo dopo passo arriva ad analizzare le funzionalità che occorre fornire, tutte quelle che possono essere realizzate, come strutturare il sistema in un modello component-based e definendo un architettura di massima, cioè come i vari componenti devono interagire. L aspetto più complesso è quello di definire l architettura, sia perché esistono vari modelli che dipendono dal tipo di sistema che vogliamo realizzare, infatti se ad esempio l applicazione è orientata al web si preferisce un modello ad un altro, e poi perchè dopo aver scelto l architettura è necessario scegliere delle tecnologie di implementazione. Dopo ciò va progettato ogni componente, quali sono i package, le classi, e va visto come il sistema deve funzionare, e quindi la sua dinamicità che deriva in parte dalla prima fase di analisi in cui vengono individuati i requisiti funzionali, che, di volta in volta, devono essere specificati nel dettaglio e faranno da tramite per scrivere il codice del sistema in maniera più agile. Una parte molto importante è tutta la fase di test, in cui il sistema che è stato realizzato, deve essere valutato per capire se è un sistema di qualità, se risponde a dei requisiti non funzionali,evidenziati nella fase di analisi, che specificano come il sistema deve realizzare quelle funzionalità, quindi se deve garantire affidabilità anziché scalabilità e cosi via. DESIGN PATTERN Si tratta di soluzioni già pronte, che permettono di realizzare il principio del riuso, uno dei principi base dell ingegneria del software, non solo a livello di codice (librerie di classi) ma anche a livello di progettazione, perché abbiamo dei pattern(schemi vuoti) che possono essere adattati allo schema delle classi che vogliamo realizzare. Attraverso questa tabella possiamo classificare i pattern secondo lo scopo (Creazionali, Strutturali o comportamentali) e il raggio d azione (per Classi o per Oggetti). Questi qui sotto elencati sono i più noti e più utilizzati. Scopo Creazionale Strutturale Comportamentale Raggio d azione Classi Factory method Adapter Interpreter Template Method Oggetti Abstarct factory Builder Prototype Singleton Adapter Bridge Composite Decorator Facade Flyweight Proxy Chain of responsibility Command Iterator Mediator Memento Observer State Strategy Visitor 34

35 Partiamo dai pattern Strutturali, i quali si occupano del problema di come comporre le classi e gli oggetti per formare delle strutture più complesse. Abbiamo sia pattern basati su classi che basati su oggetti. La differenza sta nel fatto che quelli basati su classi le interfacce e le implementazioni vengono composto mediante l ereditarietà, quelli basati su oggetti descrivono la modalità secondo cui comporre gli oggetti per realizzare nuove funzionalità, ovviamente in questo modo è possibile fornire maggiore flessibilità. L Adapter è quello più utilizzato in assoluto poiché fornisce la funzionalità di convertire l interfaccia di una classe nell interfaccia di un'altra classe. Supponiamo di avere un editor grafico in grado di comporre disegni ma anche testo. L incompatibilità sta nel fatto che testo e linee e poligoni sono classi con interfacce diverse e quindi per rendere simili uso l adapter. Vediamo un esempio grafico: Supponiamo di avere un editor grafico in grado di disegnare sia grafici sia testo. E evidente dove è l incompatibilità,infatti essa sta nel fatto che testo e poligoni sono classi con interfacce diverse ma non del tutto incompatibili. Pertanto bisogna trovare un modo per renderle compatibili. Supponiamo di avere una Shape astratta, quindi una classe che definisca le caratteristiche degli oggetti grafici, e l applicazione definisca una sotto classe di shape per ogni oggetto specifico. Se volessi implementare una Text shape essa non può essere messa direttamente come sottoclasse di Shape (ossia della forma geometrica) poiché il testo ha caratteristiche ben diverse. Vorrei quindi riutilizzare un classe (text view) per visualizzare e modificare il testo. La tentazione sarebbe quella di modificare la classe, ma ciò è totalmente sbagliato!! E sbagliato concettualmente perché si sta venendo meno al principio della riusabilità,poiché se si ha qualcosa di rigidamente già definito si può utilizzare in vari contesti, adattandolo ma mai stravolgendolo! Se non è riusabile direttamente non si deve modificare, ma si deve fare in modo che essa possa essere utilizzata, adattata. Per cui bisogna utilizzare una nuova classe Text shape che vada ad adattare la text view e permetta di rendere compatibili la shape e la text view senza modificarle. L editor grafico può utilizzare la classe text view come se fosse un figlio della classe shape. 35

36 Quali sono i vantaggi dell adapter? Esso fornisce delle funzionalità che la classe adattata in caso contrario, non avrebbe. Quando utilizzarlo? La difficoltà dei pattern sta proprio nel capire come e quale pattern utilizzare. In linea di massima usiamo l adapter quando abbiamo una classe esistente con interfaccia diversa con un'altra e vogliamo che esse interagiscono. Oppure quando si vuole creare una classe riusabile che si possa correlare con classi con interfacce diverse. La struttura di un adapter in sintesi è di questo tipo: Nell Adapter abbiamo una classe Target che definisce l interfaccia specifica del dominio utilizzato dal client, che è il resto del sistema. L adaptee è l interfaccia che deve essere adattata e l adapter è la classe che si occupa appunto di rendere le due interfacce compatibili. Simili all adapter vi sono il Bridge,il Proxy e il decorator. Il Bridge ha come obiettivo quello di separare l interfaccia dall implementazione. Disaccoppia l astrazione dalla sua implementazione. Esso si usa quando non si vuole un legame permanente tra astrazione e implementazione. Se ad esempio voglio poter variare dinamicamente l implementazione di una classe. Oppure quando voglio estendere sia l implementazione che l astrazione usando il meccanismo delle sottoclassi. Per quanto riguarda la struttura si ha una classe astratta con diverse implementazioni di essa, e la classe astrazione che non ha nessuna relazione di ereditarietà con le classi concrete implemenction. 36

37 L abstraction è l interfaccia dell astrazione che ha un riferimento all implementor che è il vero e proprio bridge, e definisce le interfacce per le classi implementatrici e non corrisponde totalmente all interfaccia dell abstraction perchè deve permettere di eseguire una piuttosto dell altra tra le implementazioni esistenti.il concrete implementor definisce le varie implementazioni con la realizzazione completa di un algoritmo piuttosto che un altro. Esempio: Supponiamo di implementare un toolkit per interfacce utente in ambiente Windows che permetta di scrivere applicazioni che siano eseguite su piattaforme X o IBM. Se usassimo l ereditarietà dovremmo stabilire staticamente una sottoclasse per ogni tipo di finestra, e quindi sarebbe piu difficile seguire le applicazioni su piattaforme distinte mentre con l implementor scelgo se seguire l implementazione su piattaforma X o IBM. Si spezza la gerarchia dell ereditarietà, L aspetto di implementazione è distinto e gestito da un ulteriore classe. Il DECORATOR permette di aggiungere dinamicamente responsabilità ad un oggetto, cioè invece di definire delle sottoclassi per estendere delle funzionalità si aggiunge un decorator che aggiunge queste funzionalità. Per aggiungere funzionalità a singoli oggetti e non all intera classe, e ciò fa capire che si sta parlando di qualcosa che succede a run-time, modifica dell oggetto dinamicamente. In caso contrario bisognerebbe creare una sottoclasse staticamente appesantendo una struttura di ereditarietà con qualcosa che non sempre sarebbe strettamente necessario. Il decorator ha interfaccia conforme a quella dell oggetto da estendere in modo di renderlo trasparente al client (ossia a tutto il resto del sistema, le richieste vengono trasferite al componente decorato, l altra caratteristica è che consente l aggiunta di un numero illimitato di funzionalità e non compromette altre classi. La struttura ricorda un po quella del bridge poiché il decorator fa da tramite tra il componente e la sottoclasse di esso. Fa da tramite per poi selezionare una funzionalità piuttosto che un'altra, dinamicamente. 37

38 La struttura è la seguente: Il Component definisce l interfaccia comune per gli oggetti ai quali possono essere aggiunte responsabilità dinamicamente, Il concrete Component definisce un oggetto al quale possono essere aggiunte responsabilità ulteriori, il decorator è la sottoclasse che mantiene il riferimento al component e definisce l interfaccia conforme a quella di component che però faccia da tramite con il concrete decorator, il concrete decorator sono quelle funzionalità che posso aggiungere all oggetto. IL Proxy ha lo scopo di fornire il surrogato o un segnaposto di un altro oggetto per controllare l accesso a tale oggetto. Quando per esempio in documenti di testo inserisco l immagine in realtà inserisco un proxy. La motivazione per cui utilizzare il Proxy è quello di controllare l accesso a un oggetto. Lo si applica quando si necessita avere riferimento a un oggetto che sia più versatile e raffinato di un semplice puntatore. Il proxy è un oggetto vero e proprio che ha una sua caratterizzazione. Esso può essere remoto,quando fornisce rappresentazione locale di un oggetto in diverso spazio di indirizzamento, virtuale, quando si vuole risparmiare in termini di memoria e di tempo di esecuzione, o un proxy di protezione se voglio controllare l accesso a un oggetto, quando ad esempio si hanno dei diritti di accesso su un oggetto. ll Subject è l interfaccia comune mentre il real subject è l elemento duplicato dal Proxy. 38

39 Possiamo quindi arrivare a commentare i pattern strutturali. Essi si basano su un insieme di meccanismi messi a disposizione da linguaggi di programmazione che possono risolvere problemi di implementazione di aggiunta di funzionalità e cosi via, a run time. Solo nel caso dell adapter il problema viene risolto staticamente. I meccanismi sono quelli di composizione tra gli oggetti. La seconda categoria di pattern sono quelli COMPORTAMENTALI di cui studieremo l Observer e lo Strategy. Essi in generale si occupano di come attribuire le responsabilità ad oggetti che comunicano tra loro, a run time, problemi simili a quelli del Bridge. Quando si hanno flussi di informazioni difficili da seguire, e quando vogliamo studiare le relazioni dinamiche tra oggetti. Quei pochi pattern basati su classi utilizzano l ereditarietà, mentre quelli su oggetti utilizzano la composizione. Con l uso dei pattern si riesce a comunicare, modificare e uant altro mantenendo molto basso il livello di accoppiamento. L OBSERVER E un pattern di collaborazione tra oggetti, di design. Lo scopo è quello di definire una dipendenza uno a molti tra oggetti in modo tale che se un oggetto cambia il suo stato, tutti gli oggetti ad esso legati siano avvisati di questo cambiamento e aggiornati. La finalità è quella di mantenere un buon grado di affidabilità del progetto. Può essere usato in un astrazione, una classe che presenta due aspetti tra loro vincolati. Vado a incapsulare gli aspetti in due oggetti distinti che potranno essere usati indipendentemente. Una modifica a un oggetto comporta la modifica di altri oggetti e quindi un elevato accoppiamento. Posso risolvere questo problema con l Observer, svincolando i vari oggetti in modo tale che gli altri non debbano essere modificati. Oppure quando un oggetto deve notificare agli altri determinate situazionio senza conoscere l identità precisa degli altri oggetti. La struttura è la seguente: 39