La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Corso di Laurea Triennale in Ingegneria Informatica Corso di Ingegneria del software A. A. 2004 - 2005 M. Ruta Introduzione ai Sistemi Operativi 1.

Presentazioni simili


Presentazione sul tema: "Corso di Laurea Triennale in Ingegneria Informatica Corso di Ingegneria del software A. A. 2004 - 2005 M. Ruta Introduzione ai Sistemi Operativi 1."— Transcript della presentazione:

1 Corso di Laurea Triennale in Ingegneria Informatica Corso di Ingegneria del software A. A M. Ruta Introduzione ai Sistemi Operativi 1

2 Ingegneria del software DEE - Politecnico di Bari La progettazione È applicata indipendentemente dal modello di processo software utilizzato. Parte dal punto in cui sono stati analizzati e modellati i requisiti del software –È lultima azione di ingegneria del software che rientra nellattività di modellazione, getta le basi per le attività di costruzione Generazione e collaudo del codice M. MongielloIntroduzione2

3 Ingegneria del software DEE - Politecnico di Bari Modello progettuale M. MongielloIntroduzione3 Progettazione a livello dei componenti Modello analitico Testo dei casi duso Diagramma dei casi duso Diagramma di attività Modelli dinamici Diagrammi di classi Modelli strutturali Diagrammi di stato Diagrammi di sequenza Modelli comportamentali Progettazione dellinterfaccia Progettazione dellarchitettura Progettazione dei dati e delle classi Modello progettuale

4 Ingegneria del software DEE - Politecnico di Bari 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. M. MongielloIntroduzione4

5 Ingegneria del software DEE - Politecnico di Bari Il documento di progetto Progetto dei dati Progetto delle classi Progetto dellarchitettura Progetto dellinterfaccia Progetto a livello dei componenti M. MongielloIntroduzione5

6 Ingegneria del software DEE - Politecnico di Bari 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, lestetica 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 –lestendibilità -capacità di estendere il programma- + –la facilità di servizio + –ladattabilità = 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 M. MongielloIntroduzione6

7 Ingegneria del software DEE - Politecnico di Bari 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 M. MongielloIntroduzione7

8 Ingegneria del software DEE - Politecnico di Bari 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 uninterfaccia 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. –Unistruzione 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 unattività 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. M. MongielloIntroduzione8

9 Ingegneria del software DEE - Politecnico di Bari Elementi progettuali Architettura: –Architettura del software: fa riferimento alla struttura generale del software e alle modalità in cui tale struttura fornisce a un sistema unintegrità concettuale –Può essere rappresentata utilizzando uno o più modelli: Modelli strutturali: –Rappresentano larchitettura come una raccolta organizzata di componenti; hanno un elevato livello di astrazione allo scopo di individuare elementi progettuali ripetibili dellarchitettura presenti in applicazioni simili. Modelli dinamici: Riguardano gli aspetti comportamentali dellarchitettura del programma, indicando come la configurazione o la struttura del sistema possono cambiare in funzione degli eventi esterni Modello: –È la descrizione che fornisce lastrazione 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. M. MongielloIntroduzione9

10 Ingegneria del software DEE - Politecnico di Bari 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 allutente. Il modello progettuale definisce un insieme di classi di progettazione che: –Raffinano le classi analitiche fornendo i dettagli progettuali necessari allimplementazione –Completano linsieme di classi analitiche, mediante la definizione di un nuovo insieme che consentano di implementare linfrastruttura software necessarie per supportare la sioluzione operativa individuata. M. MongielloIntroduzione10

11 Ingegneria del software DEE - Politecnico di Bari Le classi progettuali ( 2/2) Classi dellinterfaccia 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 lambiente 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 lesecuzione del software M. MongielloIntroduzione11

12 Ingegneria del software DEE - Politecnico di Bari 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 lesecuzione 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. M. MongielloIntroduzione12

13 Ingegneria del software DEE - Politecnico di Bari Dimensioni del modello progettuale M. MongielloIntroduzione13 Processo Elementi dellarchitettura Elementi dellinterfaccia Elementi a livello dei componenti Elementi a livello di dispiegamento Astrazione Diagrammi delle classi Package analitici Modelli CRC Diagrammi delle collaborazioni Diagrammi flusso dei dati Diagrammi flusso di controllo Descrizione elaborazione Realizzazione delle classi progettuali Sottosistemi Diagrammi delle collaborazioni Realizzazione delle classi progettuali Sottosistemi Diagrammi delle collaborazioni Raffinati in : Casi duso – testi Diagrammi casi duso Diagrammi attività Diagrammi delle collaborazioni Diagrammi di stato Diagrammi sequenze Progettazione interfaccia tecnica Progettazione interfaccia navigazione Progettazione interfaccia grafica (GUI) 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 Diagrammi componenti Classi progettuali Diagrammi delle attività Diagrammi sequenze Diagrammi componenti Classi progettuali Diagrammi delle attività Diagrammi di sequenze Raffinati in : Requisiti: Vincoli Interoperabilità Obiettivi e configurazione Diagrammi di deployment Realizzazione classi progettuali Sottosistemi Diagrammi collaborazioni Diagrammi componenti Classi progettuali Diagrammi delle attività Diagrammi sequenziali Alta Bassa Modello analitico Modello progettuale

14 Ingegneria del software DEE - Politecnico di Bari 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 nellambito del progetto –Vengono forniti maggiori dettagli implementativi e si pone definisce la struttura e lo stile dellarchitettura –Si definiscono i componenti che costituiscono larchitettura –Si definisce linterfaccia fra i componenti e lambiente esterno Gli elementi del modello lungo lasse orizzontale non vengono sviluppati in maniera sequenziale. –Generalmente si definisce per prima larchitettura per identificare linsieme su cui si opererà –La progettazione dellarchitettura è seguita dalla progettazione dellinterfaccia e dalla progettazione dei componenti, che generalmente si svolgono in parallelo. –Il modello di dispiegamento è generalmente completato al termine della realizzazione del progetto. M. MongielloIntroduzione14

15 Ingegneria del software DEE - Politecnico di Bari Elementi del modello progettuale Progettazione dei dati: –Crea il modello dei dati e delle informazioni rappresentate ad un elevato livello di astrazione Progettazione dellarchitettura: –Fornisce una visione globale del sistema software che si sta progettando Progettazione dellinterfaccia: –Mostra lingresso e luscita delle informazioni nel sistema e le comunicazioni che si svolgono fra i componenti definiti dallarchitettura 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 nellambiente di calcolo fisico che supporterà il software. M. MongielloIntroduzione15

16 Ingegneria del software DEE - Politecnico di Bari Fonti bibliografiche R. S. Pressman, Principi di Ingegneria del software, IV edizione, Mcgraw-Hill, G. Myers, Composite Structured Design, Van Nostrand, 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, M. Fowler et al. Refactoring: Improving the design of existing code, Addison-wesley, M. MongielloIntroduzione16


Scaricare ppt "Corso di Laurea Triennale in Ingegneria Informatica Corso di Ingegneria del software A. A. 2004 - 2005 M. Ruta Introduzione ai Sistemi Operativi 1."

Presentazioni simili


Annunci Google