Trascrizione videolezione 23-1 PDF

Preview

Summary

Download Trascrizione videolezione 23-1 PDF

Description

In questa videolezione introdurremo alcuni aspetti della progettazione di sistem (system design), di cui tratta il nucleo tematico #5. Vedremo in particolare le prin attività in cui si articola questa fase dello sviluppo di progetti software, e presenteremo un tipo di diagrammi UML a cui in precedenza avevamo solo accennato, i diagrammi di deployment.

Nella lezione 17 avevamo introdotto questo schema, in cui si vedeva come la fas system design prenda in ingresso i risultati della fase di analisi e produca un mod del sistema arricchito con gli obiettivi del design, la scomposizione in sotto-siste casi d'uso che descrivono le condizioni limite (boundary conditions: inizializzazio spegnimento del sistema, gestione dei casi eccezionali)

Gli obiettivi del design (design goals) guidano le decisioni che gli sviluppatori de prendere, specialmente quando è necessario effettuare dei compromessi. Gli sviluppatori dividono il sistema in parti più facili da gestire per dominare la complessità: ogni sotto-sistema è assegnato a un gruppo di lavoro, e realizzato indipendentemente dagli altri. Questa attività corrisponde alla definizione dell'architettura software, ed è stata descritta nelle precedenti lezioni di questo nucleo tematico. Affinché la decomposizione in sotto-sistemi sia effettuata in modo efficace nell'o di soddisfare i requisiti espressi da committente ed utenti, però, bisogna risolver alcuni problemi a livello di sistema: La mappatura hardware/software La gestione dei dati persistenti Il controllo degli accessi Il flusso del controllo Le condizioni limite

In questa attività si cerca di dare risposta a domande del tipo: qual è la configura hardware del sistema? Quali funzionalità sono attribuite ai vari nodi? Come comunicano tra loro i nodi? Quali servizi sono realizzati riusando componenti software già esistenti? Come vengono incapsulati tali componenti? Per rispondere a queste domande spesso vengono definiti nuovi sotto-sistemi dedicati al trasferimento di dati da un nodo all’altro, alla gestione della concorre della ridondanza ecc. I componenti software commerciali di serie (ad es. un DBMS) permettono di realizzare economicamente servizi complessi, ma devono essere incapsulati per minimizzare le dipendenze e facilitare l’intercambiabilità. Nella seconda parte di questa videolezione introdurremo i diagrammi UML di deployment, uno strumento utile per rappresentare la mappatura tra i sotto-sist software e i dispositivi hardware che li ospitano.

Le domande che vengono poste in questa attività sono del tipo: quali dati devon essere persistenti? Dove dovrebbero essere memorizzati? Come vi si accede? I dati persistenti rappresentano un «collo di bottiglia» del sistema da diversi pun vista: la maggior parte delle funzionalità di un sistema coinvolgono la creazione manipolazione di dati persistenti. Per tali motivi l’accesso ai dati persistenti deve essere veloce e affidabile. Se la le dei dati è lenta, l’intero sistema sarà lento. Se i dati vengono danneggiati o altera probabile che ne consegua un guasto grave del sistema. Questi aspetti devono e affrontati in modo coerente a livello di sistema: non avrebbe senso adottare, in s sistemi diversi, diverse politiche per la gestione della persistenza.. Spesso, ciò conduce alla scelta di un DBMS e di un sotto-sistema aggiuntivo dedicato alla gestione dei dati persistenti.

In questa attività si affrontano problematiche connesse con i diritti d'accesso, da parte dei vari attori, ai dati manipolati dal sistema. Chi può accedere a quali dati Come viene realizzato il controllo dell’accesso? È possibile modificare dinamicam il controllo dell’accesso? Esempio: il sistema di prenotazione degli esami eCampu Ogni studente può visualizzare le date degli appelli degli esami che deve sostene ed eventualmente modificare lo stato della propria iscrizione, ma non può acced agli stessi dai di altri studenti. Ogni docente può visualizzare l'elenco degli iscritt un suo esame, e definire la composizione della commissione di un esame di cui è responsabile, ma non può modificare la data e l'ora dell'appello, né può acceder stesse informazioni relative ad esami di cui non è titolare. Gli operatori della segreteria possono accedere in lettura e modifica ai dati di qualunque esame dell'Ateneo… Anche il controllo dell’accesso e della sicurezza sono problematiche da gestire a livello di sistema. Il controllo dell’accesso deve essere consistente in tutte le parti del sistema: in a parole, le politiche adottate per specificare chi può, e chi non può, accedere a determinati dati devono essere le stesse per tutti i sotto-sistemi.

In che modo il sistema mette in sequenza le operazioni? Il sistema è guidato dag eventi (event driven)? Può gestire più di un’interazione utente in ogni dato istan La scelta del flusso del controllo ha effetti sulle interfacce dei sotto-sistemi. Se si sceglie un flusso del controllo guidato dagli eventi, i sotto-sistemi devono rende disponibili degli event handlers, procedure di callback cui il controllo viene pass verificarsi dell’evento competente. Se si sceglie un meccanismo di concorrenza b sui threads, i sotto-sistemi devono garantire la mutua esclusione nelle sezioni cr del codice (ad es. un servizio di prenotazione dei posti in aereo deve garantire ch due utenti non possano prenotare contemporaneamente e concorrentemente lo stesso posto; viceversa, due studenti eCampus che accedono concorrentemente prenotazione di uno stesso esame possono farlo, ma il sistema deve gestire correttamente entrambe le richieste, serializzando le transazioni)

Le boundary conditions hanno a che fare con le fasi di accensione e spegnimento sistema, e con la gestione delle eccezioni (errori, mancanza di risorse ecc.) Quind questo ambito le domande che ci poniamo sono del tipo: come viene inizializzat spento il sistema? Come vengono gestiti i casi eccezionali? L’inizializzazione e lo spegnimento (shutdown) del sistema spesso sono operazio assai complesse, specialmente in un ambiente distribuito. L’inizializzazione, lo spegnimento e la gestione delle eccezioni hanno effetti sulle interfacce di tutti i sotto-sistemi, e le relative problematiche devono pertanto es risolte a livello di system design.

Il diagramma mostra le attività del system design. Ogni attività progettuale affro una delle problematiche viste prima, può in linea di principio causare modifiche decomposizione in sotto-sistemi, e può sollevare ulteriori problematiche. Le atti progettuali non vengono effettuate in una sequenza precisa: il system design è un’attività altamente iterativa in cui spesso emerge la necessità di rivedere decis prese in precedenza, introdurre nuovi sotto-sistemi o modificare quelli che già ci sono. I processi di revisione del sistema in genere interessano tutti i sotto-sistem

Il termine Inglese deployment significa «messa in funzione», «messa in atto». N seguito useremo sempre il termine in Inglese. I diagrammi di deployment UML sono usati per rappresentare le relazioni tra i componenti e i nodi di run-time. Un componente è un’entità autosufficiente che offre servizi ad altri componenti attori. Ad es. un Web server offre servizi a dei Web browser; un Web browser of servizi ad un utente ecc. Un sistema è composto di componenti di run-time che interagiscono tra loro e possono essere distribuiti su più nodi. In un diagramma di deployment ogni nodo rappresenta un dispositivo fisico («device») oppure un ambiente software (una macchina virtuale, un interprete, che ospita l'esecuzione du uno o più componenti. Un nodo può contenerne altri: es. un PC può ospitare un ambiente di esecuzione. I nodi sono rappresentati come scatole che contengono i componenti, identificat icone (v. slide). Un nodo può evidenziare uno stereotipo che indica se il nodo è di tipo «device» oppure «execution environment». I percorsi di comunicazione tra nodi sono rappresentati da linee continue, eventualmente dotate di stereotipo, che indica il protocollo di comunicazione. L’esempio mostra un diagramma di deployment con due browser Web che acced ad un Web server . Questo a sua volta accede ad un back-end server, che fornisc servizi di DBMS. Dal diagramma è evidente che i due browser non accedono mai direttamente al database server. Nell'esempio il diagramma rappresenta l’allocazione di diversi componenti ai va

Il diagramma di deployment esemplificato nella slide precedente mostra l’alloca dei componenti ai nodi, e offre una prospettiva di alto livello di ogni componente Alla descrizione di un componente possono essere aggiunti dettagli per includer informazioni sulle interfacce che il componente espone, e le classi che esso cont Ecco in maggior dettaglio il componente WebServer, le classi che esso contiene, interfacce che espone (http) e richiede (jdbc). L’interfaccia http è realizzata dalla classe HttpService....