Riassunto Ingegneria del SW

DIAGRAMMA DELLE CLASSI

Grafico che fornisce una vista strutturale del sistema in termini di classi, attributi, operazioni e

relazioni tra classi. Una classe è rappresentata da un rettangolo

con tre settori separati da una linea continua.

Il primo settore, in alto, visualizza il nome

della classe ed eventualmente lo stereotipo, il

secondo, nel mezzo, una lista di attributi (con

l'opzione di indicare una lista di attributi e di

valori), il terzo, in fondo, una lista di

operazioni (per ognuna delle quali è opzionale

indicare i parametri di ingresso i tipi di dati

restituiti).

Un oggetto è rappresentato con lo stesso

simbolo usato per rappresentare le classi con

la precisazione che il nome della classe è

sottolineato ed è preceduto dal simbolo ':' per

indicare che si tratta di un oggetto; è

opzionale indicare il nome dell’oggetto

Le principali relazioni sono:

- Associazione: indica dei legami relazionali tra istanze di classi. E’ sempre bidirezionale e coinvolge

due o più classi.

- Molteplicità: indica quante istanze di una classe possono essere associate con un istanza di

un’altra classe.

NOTAZIONE CON RUOLI

Nelle associazioni molti a molti si fa uso di una classe associativa che contiene un riferimento ad

ognuno degli oggetti in relazione (doppia navigabilità).

- Aggregazione: definisce una relazione tra un “tutto” ed un insieme di parti di cui il “tutto” è

costituito. A run-time un oggetto contenuto sopravvive all’oggetto contenitore. E’ necessario

definire degli attributi privati del tipo delle classi aggregate ed ottenere i riferimenti delle istanze

con costruttori e metodi add.

- Composizione: relazione in cui gli oggetti contenuti non hanno vita propria ma esistono in quanto

parte della classe contenente. E’ necessario definire degli attributi privati del tipo delle classi

componenti ed istanziare le classi componenti mediante costruttori e metodi add.

ESEMPI GENERALIZZAZIONE CLASSI

- Dipendenza: connessione semantica tra due classi in cui una delle due è dipendente dall’altra.

Relazioni di dipendenza per applicazioni web: <<link>>, <<build>>, <<submit>>, <<redirect>>,

<<include>>…

- Classe astratta: rappresenta una classe base in una realizzazione di generalizzazione contenente

uno o più metodi astratti che non può essere istanziata. (in UML disegnata in corsivo).

6. DIAGRAMMI DI SEQUENZA

Grafico che mostra un’insieme di interazioni tra due o più oggetti mediante una sequenza

temporale di azioni. E’ anche la rappresentazione grafica di uno scenario di un caso d’uso. Mostra

la sequenza di instanziazione degli oggetti, l’ordine di invocazione delle operazioni e le relazioni tra

gli oggetti definite a run-time.

 Elementi di un diagramma di sequenza sono: tempo, oggetti, periodo di vita degli oggetti

(lifeline), istanziazione e distruzione dell’oggetto, messaggi (da un oggetto verso un altro o

verso se stesso (auto-delega)), valore restituito, iterazione.

 Frame di interazione: area di un diagramma costituita da un operatore (opt, alt, loop, break),

uno o più operandi e zero o più condizioni di guardia che stabiliscono se i loro operatori

devono essere eseguiti.

 Operatori: opt = if..then; alt = switch..case;

loop = while = for each; break (se condizione di guardia è vera).

MESSAGGIO

AUTO-DELEGA

VALORE RESTITUITO

DISTRUZIONE DI UN OGGETTO

ITERAZIONE

DIAGRAMMA DELLE COMPONENTI

Grafico che mostra le componenti e le relazioni di dipendenza tra esse.

Una componente è una parte del sistema che è sostituibile e modulare, incapsula

l’implementazione ed espone un insieme di interfacce. Solitamente diverse classi costituiscono una

componente.

DIAGRAMMA DI DEPLOYMENT

Grafico che mostra l’hardware fisico su cui sarà eseguito il sistema software.

Formato da nodi che rappresentano una

risorsa computazionale dove i manufatti

possono essere dislocati per l’esecuzione,

ed archi che rappresentano una

comunicazione tra nodi indicando una

relazione di utilizzo.

Stereotipi:

- Periferica: periferica fisica (server, pc…).

- Ambiente esecutivo: tipo di ambiente

software di esecuzione (Apache, EJB…).

Manufatti

Rappresenta un’entità concreta del mondo reale, ad esempio:

 File di codice sorgente

 File eseguibili

 Script

 Tabelle di database

 Documenti

 Output del processo di sviluppo (es. modello UML)

7. SPECIFICHE DEL SOFTWARE

Descrizione rigorosa o formale di un accordo tra Analista e Progettista (Specifica dei Requisiti) o tra

Progettista e Programmatore (Specifica di progetto e dei Moduli).

Esse riguardano vari aspetti (interessi) del sistema (utente, interfacce, tracciabilità, ecc)

Qualità delle specifiche

- Chiarezza: significato privo di ambiguità

- Comprensibilità: esprimere univocamente il comportamento del software.

- Coerenza: due affermazioni non devono essere in contraddizione tra loro.

- Completezza: concetti specificati esaurientemente, devono contenere tutti i concetti necessari.

Stili di specifiche

- Informali: scritti in linguaggio naturale.

- Semiformali: scritti in forma testuale rispettando una sintassi formale.

(Textual Design Notation e Graphical Design Notation).

- Formali: scritti utilizzando formalismi.

- Comportamentali: descrivono il sistema dal punto di vista del comportamento. (UML, Data Flow

Diagrams e Reti di Petri).

- Descrittive: descrivono il sistema dal punto di vista delle proprietà desiderate. (Entità Relazioni,

Teoria del primo ordine).

Verifica delle specifiche

- Ispezione: condotta da uomini con procedure predefinite.

- Prototipi e osservazioni: prototipi funzionanti utilizzati per verificare se il comportamento del

sistema è quello desiderato.

- Prototipi e simulazioni: prototipi funzionanti sottoposti a verifiche automatiche.

8. PROGETTO SOFTWARE

Il progetto software comprende la progettazione e il prodotto della progettazione.

Pratiche della progettazione

- Modularità: decomporre il sistema in moduli indipendenti tra loro.

- Generalità: risolvere il problema più generale in modo da rendere il modulo riusabile grazie alla

parametrizzazione.

- Incapsulamento ed information hiding: raccogliere in un’unica componente decisioni e dettagli di

un’astrazione in maniera tale da poter cambiare il comportamento di una componente senza

modificarne altre.

- Sufficienza, completezza e ricerca di primitive. Assicurare che un modulo software catturi tutte e

sole le caratteristiche primitive di un’astrazione.

Strategia dell’information Hiding

Rendere possibile il cambiamento del comportamento di una componente senza conoscere il

comportamento delle altre componenti e senza modificarlo.

- Le decisioni vengono suddivise tra le varie componenti, cercando di avere meno relazioni possibili

tra loro, soprattutto quelle contenenti dettagli instabili.

- I dettagli indipendenti tra loro devono essere nascosti in componenti separate.

- Le interfacce tra le componenti devono essere stabili anche quando cambiano le implementazioni

dei moduli.

Linee guida per l’Information Hiding

- Componente HW/SW Hiding: devono essere modificate quando e solo quando è cambiata la

macchina virtuale (tratta accesso ai dati, dispositivi I/O, sottosistema di comunicazione )

- Componente Behavior Hiding: devono essere cambiate quando si modificano le specifiche del

sistema (interfaccia uomo-macchina, regole di produzione dei dati)

- Componente Decision Hiding: devono essere modificate quando cambiano le decisioni sulle

tecniche utilizzate e sulle caratteristiche SW richieste (politiche di implementazione, funzioni di

base, parametri del sistema)

Manufatti Principali

 Architettura: descrive come il sistema è decomposto ed organizzato in componenti

 Progetto Dettagliato: descrive il comportamento delle componenti e come realizzano la

collaborazione tra esse

Strategie

 Generali: dividi-e-conquista; raffinamento per passi; topdown vs bottom-up; astrazione;

information hiding; euristiche, pattern; incrementi successivi

 Funzionali: basato sulla individuazione delle funzioni principali. Progettazione strutturata

(Structure Chart)

 Orientata agli Oggetti: basato sui dati ed i metodi che ne sono proprietari. Ereditarietà;

Polimorfismo; Metadati e Riflessione.

ARCHITETTURA

Il progetto di un sistema si esprime attraverso l’architettura software che comprende le

componenti e le loro proprietà e relazioni tra loro.

Per produrre l’architettura si:

divide il problema → individuano le componenti che risolvono i problemi → decide la soluzione.

Il sistema è rappresentato come un insieme di componenti (oggetti) ognuna contenente dati e

metodi per operare.

Stile Object Oriented

Una connessione tra due componenti deve utilizzare un’interfaccia I, prodotta da una delle

componenti ed usata dall’altra. Ad ogni interfaccia è associata un insieme di metodi messi a

disposizione dalla componente che la produce e utilizzati da altre componenti. Così facendo ogni

componente nasconde la propria implementazione agli altri (favorisce incapsulamento e

modularità).

9. STEREOTIPI UML

Uno stereotipo estende un elemento UML esistente

Approccio BCE: modellazione a oggetti basata sulla ripartizione delle classi in 3 categorie

(boundary-control-entity).

- Classi Boundary: descrivono gli oggetti che rappresentano l’interfaccia tra attore e sistema.

Isolano il sistema dai cambiamenti dell’ambiente esterno. Mettono in comunicazione Attori con

Control.

- Classi Control: descrivono gli oggetti che percepiscono gli eventi generati dall’utente, coordinano

il comportamento delle classi entity e ne usano i contenuti. Mettono in comunicazione le Boundary

con Entity. Sono indipendenti dall’ambiente esterno.

- Classi Entity: descrivono gli oggetti che rappresentano l’entità del dominio applicativo.

Sono classi passive. Mettono in comunicazione Control con Database.

Approccio BCDE: Per migliorare l’information Hiding delle classi Entity si utilizzano le Classi

DBInterface che fungono da interfaccia tra le Entity e il Database. Esempi sono la Classi CRUD,

Connection, Schema.

Stereotipi & Architettura a 3 Livelli

 Presentazione

o Classi Boundary

o Classi Control (per la gestione della logica di presentazione)

 Dominio

o Classi Entity

o Classi Control (per la gestione della logica di business)

 Sorgente Dati

o Classi DBInterface

10. PROGETTAZIONE DEL DATABASE

Normalizzazione: è un processo di progettazione di un database