Che materia stai cercando?

Ingegneria della progettazione Appunti scolastici Premium

Appunti di ingegneria del software della professoressa Fasolino sull'ingegneria della progettazione. Il file contiene una lunga trattazione su: il design space (modulo e componenti), il diagramma UML delle parti di un sistema ed i diversi aspetti della progettazione.

Esame di Fondamenti di informatica docente Prof. R. Fassolino

Anteprima

ESTRATTO DOCUMENTO

INGEGNERIA DEL SOFTWARE FranK 11

- Coesione comunicazionale: tutti i moduli che accedono o manipolano certi dati sono tenuti insieme, ad

esempio nella stessa classe e tutto il resto sta fuori. Tutte le operazioni che accedono agli stessi dati vengono

definite all’interno di una classe. In generale, tali classi si concentrano unicamente sui dati in questione,

accedendovi e memorizzandoli. Una classe può avere una buona coesione comunicazionale: se tutte le funzioni

del sistema che memorizzano e manipolano i suoi dati sono contenute esclusivamente in questa classe; oppure

anche se la classe non fa altro che gestire i propri dati

Un modulo che aggiorna un database e un modulo che aggiorna un file di log delle modifiche al database

dovrebbero stare insieme in uno stesso modulo (a coesione comunicazionale). Un modulo a coesione

comunicazionale potrebbe stare in un layer. Il vantaggio si ha quando bisogna modificare i dati, tutto il codice

relativo ai dati si troverà in un solo posto.

- Coesione sequenziale: i componenti e le operazioni vengono raggruppati in modo che il primo fornisca l’input

al successivo e così via. Lo scopo è quello di implementare una sequenza di operazioni. Una serie di procedure

in cui una fornisce input alla successiva sono tenute insieme e tutto il resto sta fuori. L’obiettivo dovrebbe

essere di raggiungere la coesione solo dopo che sono stati raggiunti gli altri livelli.

- Coesione procedurale: i componenti o le operazioni vengono raggruppati in un modo che consenta di

richiamarne uno immediatamente dopo il precedente, anche quando i due componenti non si scambiano dati.

Tenere insieme in un solo modulo varie procedure che sono usate l ’una dopo l ’altra. Le procedure non

forniscono necessariamente input alle successive. Ad esempio, un modulo che svolge in sequenza tutte le

azioni necessarie a registrare uno studente in un corso.É una coesione più debole di quella sequenziale.

- Coesione temporale: vengono svolte delle operazioni che riflettono un determinato comportamento o stato, per

esempio un’operazione svolta all’avvio o tutte le operazioni svolte in caso di errore. Operazioni svolte durante

la stessa fase di esecuzione del programma sono tenute insieme. Ad esempio, tutto il codice usato durante la

fase di avvio del sistema, o di inizializzazione, di terminazione, o in casi particolari. Ovviamente, un modulo

che inizializza variabili non deve farlo direttamente, ma invocando le apposite procedure di inizializzazione di

altri moduli. É più debole della coesione procedurale

- Coesione di Utilità: vengono raggruppati i componenti, le classi o le operazioni che si trovano nella stessa

categoria anche se non correlati. Quando utilità correlate che non possono essere logicamente collocate in altri

moduli coesivi sono contenute nello stesso modulo. Un’ utilità è una procedura o una classe con ampia

applicabilità a vari sottosistemi e che è stata progettata per essere riusabile. Per esempio, la java.lang.Math

class.

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

INGEGNERIA DEL SOFTWARE FranK 12

ACCOPPIAMENTO. L’accoppiamento è una misura qualitativa del grado di connessione fra le classi. A mano a

mano che le classi e i componenti diventano più interdipendenti, aumenta anche l’accoppiamento. Un obiettivo

importante nella progettazione a livello dei componenti consiste nel mantenere l’accoppiamento al livello minimo

possibile. Ecco le seguenti categorie di accoppiamento:

- Accoppiamento dei contenuti: si verifica quando un componente modifica “clandestinamente” i dati interni di

un altro componente, violando l’information hiding. Per ridurre questo accoppiamento si dovrebbero

incapsulare tutte le variabili d’istanza dichiarandole private e fornendo i metodi di get e set. Una peggiore

forma di accoppiamento per contenuto è quella in cui si può modificare una variabile di istanza dichiarata

all’interno di un’altra variabile di istanza.

- Accoppiamento per dati comuni: si verifica quando un certo numero di componenti utilizza una variabile

globale. È tipico dell’uso di variabili globali: tutti i componenti che usano la variabile globale diventano

accoppiati fra loro. Una forma più lieve di accoppiamento comune si ha quando una variabile può essere

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

INGEGNERIA DEL SOFTWARE FranK 13

acceduta solo da un sottoinsieme di classi del sistema (ad esempio un package Java). Può essere accettabile per

creare variabili globali che rappresentano valori di default costanti usati in tutto il sistema. Diversamente, usare

l’incapsulazione!

- Accoppiamento sul controllo: si verifica quando l’operazione A() richiama l’operazione B() inviandole un flag

di controllo. Per fare una modifica, bisogna cambiare sia il chiamante che il chiamato. L’uso di metodi

polimorfici è in genere il modo migliore per evitare questo accoppiamento.

- Accoppiamento di inclusione: si verifica quando la classe B è il tipo di un argomento di un’operazione svolta

nella classe A.

- Stamp Coupling: si ha quando una delle classi è dichiarata come il tipo dell’argomento di un metodo. Il

metodo a cui viene passata l’istanza dell’altra classe può eseguire tutti i metodi pubblici della classe, anche se

non ce ne sarebbe bisogno. Siccome una classe usa l’altra, è più difficile cambiare il sistema (riusare una classe

richiede il riuso anche dell’altra). Un modo per ridurre lo stamp coupling è quello di passare variabili semplici

- Accoppiamento sui dati: si verifica quando le operazioni si passano lunghe stringhe di argomenti, ovvero

quando gli argomenti di un metodo o sono primitivi o semplici classi di libreria. Più argomenti un metodo

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

INGEGNERIA DEL SOFTWARE FranK 14

possiede e maggiore è l’accoppiamento. Tutti i metodi che usano quel metodo gli devono passare tutti gli

argomenti. Si può ridurre questo accoppiamento evitando di definire in ogni metodo argomenti non necessari.

Si ha necessità di un compromesso fra data coupling e stamp coupling, aumentando l’uno in genere diminuisce

l’altro.

- Accoppiamento per chiamate a routine: si verifica quando un’operazione o routine ne richiama un’altra. Le

routine sono accoppiate perché la prima dipende dal comportamento (e dall’interfaccia) dell’altra. È una forma

di accoppiamento inevitabile in ogni sistema. Se viene invocata ripetitivamente una sequenza di due o più

metodi per calcolare qualcosa, si può ridurre questo accoppiamento scrivendo una sola routine che incapsula la

sequenza. Le eventuali modifiche delle routine impatteranno solo sulla routine che incapsula le altre.

- Accoppiamento nell’uso dei tipi: si verifica quando il componente A (o modulo) usa un tipo di dati definito

nel componente B (o altro modulo). Si verifica ogni volta che una classe dichiara una variabile di istanza o una

variabile locale del tipo di un’altra classe. La conseguenza è che se cambia la definizione del tipo, anche gli

utenti del tipo possono dover cambiare. È bene dichiarare il tipo di una variabile della classe più generale

possibile che contiene le operazioni richieste, per poi specializzare la classe, se occorre. Ad esempio usare il

tipo List dell’interfaccia java.util.List e poi istanziare la specifica lista.

- Accoppiamento per inclusione o ’importazione: si verifica quando il componente A importa o include un

package o il contenuto del componente B. Il componente che include o importa componenti dipende da tutto

ciò che si trova nel componente incluso o importato. Se il componente incluso o importato modifica o

aggiunge qualcosa: si può generare un conflitto con qualcosa contenuto nell’includente, obbligando quest’

ultimo a cambiare. Un elemento in un componente importato potrebbe avere lo stesso nome di qualcosa già

definito.

- Accoppiamento esterno: si verifica quando un componente comunica o collabora con i componenti

dell’infrastruttura. Quindi si ha quando un modulo dipende da cose quali il sistema operativo, librerie

condivise o dall’harware. È bene ridurre il numero di punti nel codice in cui esistono queste dipendenze.

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

INGEGNERIA DEL SOFTWARE FranK 15

LA PROGETTAZIONE DELL’ARCHITETTURA

L’Architettura Software stabilisce l’organizzazione globale di un sistema software, definendo: la divisione del software

in sottosistemi, la decisione di come queste parti interagiranno, le interfacce delle varie parti. Definire l’architettura è il

cuore della fase di progettazione: è fondamentale per ogni ingegnere software. L’architettura spesso vincolerà

l’efficienza complessiva la riusabilità e la manutenibilità del sistema.

La progettazione è stata descritta come un progetto a più fasi nel quale, a partire dai requisiti, si producono

rappresentazioni della struttura dei dati e della struttura del programma, delle caratteristica dell’interfaccia e degli

aspetti procedurali. I domini dei dati, funzionale e comportamentale servono da guida per la creazione del progetto. La

progettazione dell’architettura rappresenta la struttura dei dati e i componenti del programma che sono necessari per

realizzare un sistema. La progettazione dell’architettura considera lo stile dell’architettura che verrà assunto dal sistema,

la struttura e le proprietà dei componenti che costituiscono il sistema e le relazioni che si stabiliscono fra tutti i

componenti dell’architettura di un sistema. Il progetto dell’architettura inizia con il progetto dei dati e poi procede con

la determinazione di una o più rappresentazioni della struttura di architettura del sistema. Per determinare la struttura

più adatta per i requisiti del cliente e poi gli attributi di qualità vengono analizzati più stili e modelli di architettura.

Dopo aver selezionato una delle alternative, l’architettura viene elaborata utilizzando un determinato metodo di

progettazione. Un modello dell’architettura comprende i dati dell’architettura e la struttura del programma. Inoltre

vengono descritte le proprietà e le relazioni fra i componenti.

L’architettura di un sistema descrive la forma, la struttura del sistema: quali sono i suoi componenti e il modo in cui

essi operano.

L’architettura del software di un programma o di un sistema di calcolo è costituita dalle strutture del sistema, che

comprendono i componenti software, le loro proprietà visibili e le relazioni fra di essi. L’architettura non è un software

operativo. Piuttosto è la rappresentazione che consente a un ingegnere del software di 1) analizzare l’efficacia del

progetto nel rispondere ai requisiti stabiliti, 2) considerare le alternative di architettura in una fase in cui ogni

cambiamento è ancora relativamente semplice, 3) ridurre i rischi associati alla costruzione del software.

Inoltre, è importante costruire un modello dell’architettura:

- per consentire una migliore comprensione del sistema;

- per permettere a persone diverse di lavorare su parti diverse del sistema;

- prepararsi per l’estensione del sistema;

- per facilitare il riuso e la riusabilità.

L’architettura del software consta di due livelli: progettazione dei dati e progettazione dell’architettura.

La progettazione dei dati consente di rappresentare i dati che compongono l’architettura. La progettazione

dell’architettura si concentra sulla rappresentazione della struttura dei componenti software e delle loro proprietà e

interazioni.

L’architettura costituisce un modello relativamente compatto e afferrabile del modo in cui il sistema è strutturato e di

come i suoi componenti collaborano tra loro.

Stile e modelli dell’architettura. Lo stile dell’architettura è un modello di costruzione. Ogni stile descrive una

categoria di sistemi che comprendono 1) un insieme di componenti (database, moduli computazionali) che svolgono

una funzionalità richiesta dal sistema, 2) un insieme di connettori che consentono la comunicazione, il coordinamento e

la cooperazione fra i componenti, 3) i vincoli che definiscono il modo in cui i componenti possono essere intergrati per

costituire il sistema e 4) dei modelli semantici che consentano al progettista di comprendere le proprietà globali di un

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

INGEGNERIA DEL SOFTWARE FranK 16

sistema, analizzando le proprietà note delle parti che lo compongono. Lo scopo è quello di stabilire una struttura per

tutti i componenti del sistema. Un modello di architettura, come uno stile dell’architettura, impone una trasformazione

sul progetto di un’architettura. Tuttavia, un modello differisce da uno stile per vari aspetti: 1) l’ampiezza di un modello

è minore e si concentra su un unico aspetto dell’architettura e non sull’architettura nella sua interezza, 2) un modello

impone una regola sull’architettura descrivendo il modo in cui il software gestirà alcuni aspetti delle sue funzionalità a

livello dell’infrastruttura; 3) i modelli architettonici tendono a risolvere specifici comportamenti nel contesto

dell’architettura, ovvero il modo in cui l’applicazione gestisce in tempo reale la sincronizzazione o gli interrupt. I

modelli possono essere utilizzati in congiunzione con uno stile di architettura per stabilire la forma della struttura

generale del sistema.

Contenuti di un buon modello architetturale. Una buona architettura potrà essere espressa da diversi punti di vista:

La scomposizione logica in sottosistemi (Vista Strutturale) e le interfacce fra sottosistemi:Package Diagrams;

lla dinamica dell’interazione fra componenti (Vista Comportamentale): Diagrammi di Interazione e di Attività

I dati che saranno condivisi fra sottosistemi (Vista sui dati persistenti): Class diagrams

I componenti che esisteranno a run time, e le macchine ed i dispositivi su cui saranno dislocati (Vista di tipo logistico):

Component e Deployment diagrams.

Vista strutturale. Elementi: modulo (unità software che realizza un insieme coerente di responsabilità), ad esempio

Classe, insieme di classi, un layer…

Proprietà: responsabilità, visibilità, autore…

Relazioni: parte di, eredita da, dipende da

Stili strutturali. Relazione di Decomposizione: moduli e sottomoduli, definiti tramite il principio del “divide et impera”

Relazione di Usa: un modulo A uso il modulo B se dipende dal funzionamento di B per realizzare i suoi requisiti;

Strati (o Layer): un insieme coeso di moduli che offre un’interfaccia per i suoi servizi.

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

INGEGNERIA DEL SOFTWARE FranK 17

Occorre progettare architettura stabili. Per garantire manutenibilità ed affidabilità di un sistema, u n modello

architetturale deve essere stabile. Stabile vuol dire che nuove caratteristiche potranno essere aggiunte facilmente con

poche modifiche all’architettura.

Sviluppare un modello architetturale: partire con una prima definizione di massima dell’architettura, basandosi sui

principale requisiti e use cases; determinare i principali componenti richiesti dal sistema (databse, particolari dispositivi

hardware, e sottosistemi software). Si può scegliere tra vari pattern architetturali, può essere utile lavorare più team su

una prima bozza dell’architettura per poi fondere le migliori idee.

Raffinare l’architettura:

- Identificare i modi in cui i componenti interagiscono e le rispettive interfacce;

- Decidere come i dati e le funzionalità saranno distribuiti tra i vari componenti;

- Stabilire se si può riusare un framework già esistente, o se si vuole costruire un framework

Consederare ogni use case e modificare l’architettura per renderlo realizzabile;

definire l’architettura finale, quando di saranno ottenuti class diagrams e interaction diagrams finali.

Descrivere una architettura usando UML. Tutti I diagrammi UML possono essere utili a descrivere gli aspetti di un

modello architetturale. Quattro diagrammi UML sono specifici per definire l’architettura:

- Package diagrams

- Subsystem diagrams

- Component diagrams

- Deployment diagrams

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

INGEGNERIA DEL SOFTWARE FranK 18

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

INGEGNERIA DEL SOFTWARE FranK 19

PATTERNS ARCHITETTURALI. Il concetto di pattern può essere applicato alle architetture software. Si parla di

architectural patterns o stili/ modelli architetturali. Permettono di progettare sistemi flessibili usando componenti

quanto più indipendenti è possibile.

Ecco alcuni patterns architetturali: Multi-Layer, Client -Sever, Three-tier, Broker, Transaction-Processing, Pipe-&-

Filter, Model View Controller.

Il pattern architetturale Multi-Layer. In un sistema a livelli (a layers), ciascun livello comunica solo con i livelli

sottostanti. Ogni livello offre un’interfacci ben definita al livello immediatamente sovrastante. Il livello pi ù alto vede

quello più basso come un insieme di servizi.

Un sistema complesso può essere costruito stratificando layers aventi via via crescenti livelli di astrazione.

É importante avere un layer separato per l’Interfaccia Utente (UI). I livelli sotto il livello UI forniscono le funzioni

applicative corrispondenti ai casi d’ uso. I livelli più bassi forniscono servizi generici. Ad esempio, comunicazione su

rete, accesso a database.

L’architettura multi-layer e i principi di progetto.

1) dividere e impadronirsi: i layer possono essere progettati indipendentemente.

2) Aumentare la coesione: layers bene progettati hanno coesione di livello.

3) ridurre l’accoppiamento

4) Aumentare l’astrazione

5) aumentare la riusabilità

6) Aumentare il riuso

7) Incrementare la flessibilità

8) Prevedere le obsolescenze

9) Progettare per la portabilità

10) Progettare per la testabilità

11) Progettare per la sicurezza

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

INGEGNERIA DEL SOFTWARE FranK 20

Il pattern Client-Server e altri pattern architetturali distribuiti. C’è almeno un componente col ruolo di server, che

attende e gestisce connessioni. C’è almeno un componente col ruolo di client, che inizia la connessione richiedendo

qualche servizio. Altro esempio è l’architettura three-tier con livello Client, Business Logic server, e Database server.

Un’ulteriore estensione è il pattern Peer -to-Peer, che è un sistema composto da vari componenti software distribuiti su

sistemi host diversi.

I principi di progetto per il pattern client-server sono i medesimi del pattern multi-layer

Il pattern architetturale Broker. Distribuisce in maniera trasparente vari aspetti del sistema software su nodi diversi

Un oggetto può chiamare metodi di un altro oggetto senza sapere che l’oggetto è localizzato su una sede remota.

CORBA è un open standard che consente di costruire questo tipo di architettura.

Il pattern architetturale Transaction-Processing. Un processo legge una serie di input. Ogni input descrive una

transazione (un comando che esegue una modifica ai dati gestiti dal sistema). C’è un componente dispatcher di

transazioni che decide cosa fare per ogni transazione. Questo componente esegue una chiamata a procedura o invia un

messaggio ad una serie di componenti che gestiranno la transazione.

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

INGEGNERIA DEL SOFTWARE FranK 21

Il pattern archietturale Pipe-and-Filter. Uno stream di dati, in un formato relativamente semplice, viene sottoposto

ad una serie di processi elaborativi (la pipeline). Ogni processo trasforma lo stream, i dati vengono continuamente

inseriti nella pipeline, i processi lavorano concorrentemente, mantenendo costante il flusso nella pipeline. L’architettura

è molto flessibile: si possono rimuovere quasi tutti i componenti e i componenti possono essere sostituiti; nuovi

componenti possono essere inseriti e alcuni componenti si possono riordinare.

Il pattern Model-View-Controller (MVC). Un pattern che aiuta a separare il livello dell’interfaccia utente da altre

parti del sistema. Il model contiene le classi le cui istanze rappresentano i dati da visualizzare e manipolare. La view

contiene oggetti usati per rendere in output, nella UI, i dati contenuti nel model. Il controller contiene gli oggetti che

controlleranno e gestiranno l’interazione dell’utente sia con il livello view che il model

Il modello non sa nulla della view, nè del livello controller

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli


PAGINE

25

PESO

366.07 KB

PUBBLICATO

+1 anno fa


DETTAGLI
Corso di laurea: Corso di laurea in ingegneria informatica
SSD:
A.A.: 2013-2014

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher cecilialll di informazioni apprese con la frequenza delle lezioni di Fondamenti di informatica e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Napoli Federico II - Unina o del prof Fassolino Rita.

Acquista con carta o conto PayPal

Scarica il file tutte le volte che vuoi

Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato

Recensioni
Ti è piaciuto questo appunto? Valutalo!

Altri appunti di Fondamenti di informatica

Fondamenti di Informatica - von neumann e processore
Dispensa
Fondamenti di Informatica – Dispensa
Dispensa
Appunti di Fondamenti di Informatica
Appunto
Fondamenti di informatica - Esercitazioni
Esercitazione