Introduzione ai Sistemi Operativi

Presentazione sul tema: "Introduzione ai Sistemi Operativi"— Transcript della presentazione:

1 Introduzione ai Sistemi Operativi
M. Ruta

2 La progettazione È applicata indipendentemente dal modello di processo software utilizzato. Parte dal punto in cui sono stati analizzati e modellati i requisiti del software È l’ultima azione di ingegneria del software che rientra nell’attività di modellazione, getta le basi per le attività di costruzione Generazione e collaudo del codice Introduzione M. Mongiello

3 Progettazione dell’architettura
Modello progettuale Diagrammi di stato Diagrammi di sequenza Modelli dinamici Progettazione a livello dei componenti Testo dei casi d’uso Diagramma dei casi d’uso Diagramma di attività Modello analitico Progettazione dell’interfaccia Modelli comportamentali Modelli strutturali Progettazione dell’architettura Diagrammi di classi Progettazione dei dati e delle classi Modello progettuale Introduzione M. Mongiello

4 Dal modello analitico al modello progettuale
Ogni elemento del modello analitico fornisce informazioni necessarie per produrre i modelli progettuali necessari per una specifica completa del progetto. Introduzione M. Mongiello

5 Il documento di progetto
Progetto dei dati Progetto delle classi Progetto dell’architettura Progetto dell’interfaccia Progetto a livello dei componenti Introduzione M. Mongiello

6 Qualità della progettazione
Attributi di qualità FURPS: Funzionalità: valutata controllando le capacità del programma, generalità delle funzioni e sicurezza del sistema globale Usabilità: valutata considerando i fattori umani, l’estetica generale, la coerenza e la documentazione Affidabilità: valutata misurando la frequenza e la gravità dei guasti, la precisione dei risultati di output, il tempo Mean time to failure (MMTF), la capacità di recuperare una situazione di guasto e la prevedibilità del programma Prestazioni: misurate in termini di velocità di elaborazione, tempo di risposta, consumo di risorse, produttività ed efficienza Supportabilità: combina l’estendibilità -capacità di estendere il programma- + la facilità di servizio + l’adattabilità = Facilità di manutenzione Con Collaudabilità Compatibilità Configurabilità – capacità di organizzare e controllare gli elementi della configurazione del software Facilità di installazione Facilità di individuazione dei problemi Introduzione M. Mongiello

7 Principi della progettazione (1/2)
Astrazione: nel considerare una soluzione modulare a un problema si esprime la soluzione a grandi linee nel linguaggio del contesto del problema: astrazione elevata, si procede poi via via a livelli di astrazione inferiori adottando descrizioni più dettagliate Modularità: Myers 78.il software viene suddiviso in più componenti chiamati moduli che vengono integrati per soddisfare i requisiti del problema, la modularità rende più gestibile il problema Information hiding: Parnas 72. i moduli devono essere caratterizzati in base alle decisioni progettuali in modo tale che le informazioni (dati e algoritmi) risultino inaccessibili ad altri moduli che non necessitano di tali informazioni. Utile in fase di collaudo e manutenzione: un errore introdotto in fase di modifica si propagherà con minore probabilità alle altre parti del software Introduzione M. Mongiello

8 Principi della progettazione (2/2)
Indipendenza funzionale: Proposta da Wirth 71 e Parnas 72. deriva dai precedenti tre principi. Si vuole progettare software in modo che ciascun modulo svolga una determinata sottofunzione dei requisiti e abbia un’interfaccia semplice, se considerata con le altre parti della struttura del programma Facilita manutenzione e collaudo, poiché sono limitati gli effetti secondari provocati da una modifica al progetto o al codice, si riduce la propagazione degli errori. È valutata mediante criteri qualitativi: Coesione: forza funzionale relativa di un modulo Accoppiamento : interdipendenza relativa fra moduli Raffinamento: stepwise refinement, strategia di progettazione top down (Wirth, 71). Un programma viene sviluppato raffinando successivamente i vari livelli di dettaglio procedurale. Un’istruzione o una astrazione procedurale viene progressivamente decomposta fino a raggiungere le istruzioni del linguaggio di programmazione. È un processo di elaborazione Astrazione e raffinamento sono concetti complementari Rifattorizzazione: Fowler 99. si tratta si tratta di un’attività progettuale introdotto per molti metodi agili È una tecnica di riorganizzazione che semplifica la progettazione o la programmazione di un componente senza modificare la sua funzione o il suo comportamento, migliorando la struttura interna. Esempio: esaminare il progetto alla ricerca di elementi ridondanti, non utilizzati algoritmi inefficienti, strutture dati mal realizzate o inappropriate Esempio individuare un componente con scarsa coesione. Introduzione M. Mongiello

9 Elementi progettuali Architettura: Modello:
Architettura del software: fa riferimento alla struttura generale del software e alle modalità in cui tale struttura fornisce a un sistema un’integrità concettuale Può essere rappresentata utilizzando uno o più modelli: Modelli strutturali: Rappresentano l’architettura come una raccolta organizzata di componenti; hanno un elevato livello di astrazione allo scopo di individuare elementi progettuali ripetibili dell’architettura presenti in applicazioni simili. Modelli dinamici: Riguardano gli aspetti comportamentali dell’architettura del programma, indicando come la configurazione o la struttura del sistema possono cambiare in funzione degli eventi esterni Modello: È la descrizione che fornisce l’astrazione di una soluzione valida ad un problema ricorrente in un determinato contesto sulla base di determinati vincoli, fornisce pertanto una struttura progettuale valutando le forze che possono avere impatto sul modo in cui tale modello è applicato ed utilizzato. Lo scopo del modello progettuale è quello di fornire una descrizione mediante la quale stabilire se il modello: È applicabile al lavoro corrente Può essere riutilizzato Può fungere da guida per sviluppare un modello simile ma funzionalmente o strutturalmente differente. Introduzione M. Mongiello

10 Le classi progettuali ( ½)
Il modello analitico definisce un insieme di classi analitiche. Ognuna descrive elementi del dominio del problema, evidenziando gli aspetti del problema visibili al cliente o all’utente. Il modello progettuale definisce un insieme di classi di progettazione che: Raffinano le classi analitiche fornendo i dettagli progettuali necessari all’implementazione Completano l’insieme di classi analitiche, mediante la definizione di un nuovo insieme che consentano di implementare l’infrastruttura software necessarie per supportare la sioluzione operativa individuata. Introduzione M. Mongiello

11 Le classi progettuali ( 2/2)
Classi dell’interfaccia utente: Definiscono le astrazioni necessarie per le interazioni utente-macchina Classi del dominio operativo: Sono generalmente raffinamenti delle classi analitiche definite precedentemente: identificano metodi e attributi necessari per implementare gli elementi del dominio operativo Classi di sistema: Implementano le funzioni di gestione del software e di controllo che consentono al sistema di funzionare e di comunicare con l’ambiente di calcolo o con il mondo esterno Classi dei processi: Implementano le astrazioni operative di basso livello necessarie per gestire le classi del dominio operativo Classi persistenti: Rappresentano archivi di dati che persisteranno oltre l’esecuzione del software Introduzione M. Mongiello

12 Qualità delle classi progettuali
Una classe progettuale deve essere: Completa e sufficiente: avere cioè un incapsulamento completo di tutti gli attributi e i metodi necessari alla classe stessa. Avere: Primitività: I metodi associati alla classe devono garantire l’esecuzione di un servizio per la classe, una volta che questo è implementato la classe non deve fornire nessun altro modo per ottenere lo stesso servizio. Elevata coesione: Una classe è coesa se ha responsabilità limitate e specifiche, con metodi e attributi appropriati per implementare tali responsabilità Basso Accoppiamento: È necessario che le classi collaborino tra loro, tuttavia la collaborazione deve essere mantenuta a un livello minimo: Se il modello è molto accoppiato tutte le classi collaborano con le altre, il sistema sarà difficile da implementare, collaudare, manutenere. Introduzione M. Mongiello

13 Dimensioni del modello progettuale
Alta Diagrammi delle classi Package analitici Modelli CRC Diagrammi delle collaborazioni Diagrammi flusso dei dati Diagrammi flusso di controllo Descrizione elaborazione Diagrammi delle classi Package analitici Modelli CRC Diagrammi delle collaborazioni Diagrammi flusso dei dati Diagrammi flusso di controllo Descrizione elaborazione Diagrammi di stato Diagrammi di sequenze Modello analitico Casi d’uso – testi Diagrammi casi d’uso Diagrammi attività Diagrammi delle collaborazioni Diagrammi di stato Diagrammi sequenze Requisiti: Vincoli Interoperabilità Obiettivi e configurazione Astrazione Realizzazione delle classi progettuali Sottosistemi Diagrammi delle collaborazioni Diagrammi componenti Classi progettuali Diagrammi delle attività Diagrammi sequenze Realizzazione classi progettuali Sottosistemi Diagrammi collaborazioni Diagrammi componenti Classi progettuali Diagrammi delle attività Diagrammi sequenziali Progettazione interfaccia tecnica Progettazione interfaccia navigazione Progettazione interfaccia grafica (GUI) Modello progettuale Raffinati in : Raffinati in : Realizzazione delle classi progettuali Sottosistemi Diagrammi delle collaborazioni Diagrammi componenti Classi progettuali Diagrammi delle attività Diagrammi di sequenze Bassa Diagrammi di deployment Elementi dell’architettura Elementi dell’interfaccia Elementi a livello dei componenti Elementi a livello di dispiegamento Processo Introduzione M. Mongiello

14 Le dimensioni della progettazione
Differenze tra modello analitico e modello progettuale: Gli elementi del modello progettuale usano più o meno gli stessi diagrammi UML impiegati nel modello analitico: I diagrammi del modello analitico vengono raffinati ed elaborati nell’ambito del progetto Vengono forniti maggiori dettagli implementativi e si pone definisce la struttura e lo stile dell’architettura Si definiscono i componenti che costituiscono l’architettura Si definisce l’interfaccia fra i componenti e l’ambiente esterno Gli elementi del modello lungo l’asse orizzontale non vengono sviluppati in maniera sequenziale. Generalmente si definisce per prima l’architettura per identificare l’insieme su cui si opererà La progettazione dell’architettura è seguita dalla progettazione dell’interfaccia e dalla progettazione dei componenti, che generalmente si svolgono in parallelo. Il modello di dispiegamento è generalmente completato al termine della realizzazione del progetto. Introduzione M. Mongiello

15 Elementi del modello progettuale
Progettazione dei dati: Crea il modello dei dati e delle informazioni rappresentate ad un elevato livello di astrazione Progettazione dell’architettura: Fornisce una visione globale del sistema software che si sta progettando Progettazione dell‘interfaccia: Mostra l’ingresso e l’uscita delle informazioni nel sistema e le comunicazioni che si svolgono fra i componenti definiti dall’architettura Progettazione a livello dei componenti: Descrive tutti i dettagli di ciascun componente software Progettazione a livello di dispiegamento: Descrive in che modo la funzionalità del software e dei sottosistemi verrà allocata nell’ambiente di calcolo fisico che supporterà il software. Introduzione M. Mongiello

16 G. Myers, “ Composite Structured Design”, Van Nostrand, 1978.
Fonti bibliografiche R. S. Pressman, “Principi di Ingegneria del software”, IV edizione, Mcgraw-Hill, 2004. G. Myers, “ Composite Structured Design”, Van Nostrand, 1978. D.L. Parnas, “ On criteria to be used in Decomposing systems into modules”,, CACM, vol.14, no.1 April 1972, pp N. Wirth,” Program Development by stepwise refinement”, CACM, vol.14, no.1, 1971. M. Fowler et al. “ Refactoring: Improving the design of existing code”, Addison-wesley”, 2000. Introduzione M. Mongiello