Appunti Ingegneria del software

INGEGNERIA DEL SOFTWARE SLIDE 4

4. UML INTRO

→

Modello rappresentazione astratta della realtà che serve ad individuare le proprietà salienti secondo un

punto di vista. Possono essere utilizzati all’interno di un team di sviluppo per coordinarlo.

I linguaggi servono per convogliare queste istruzioni, per definire quali sono gli elementi che definiscono il

soggetto che voglio modellare, proprietà e le relazioni.

→

Linguaggi di modellazione definiscono entità proprietà relazioni del soggetto modellato.

Object Orientation

UML si basa sull'approccio orientato agli oggetti per l'analisi e la progettazione, in particolare, UML (Unified

Modeling Language) è un linguaggio visuale per la specifica, la costruzione e la documentazione degli

elaborati di un sistema software.

→ Con visuale si intende che UML è per la notazione di diagrammi, per disegnare o rappresentare figure

relative al software e in particolare al software OO.

→ L'analisi si concentra sul dominio del problema.

→ Il design si concentra sul dominio della soluzione

→

Paradigma O-O assumiamo un punto di vista basato sugli oggetti.

→

Oggetti entità autonome contraddistinte da uno stato e da un comportamento. Voglio modelli in cui le

entità sono gli oggetti, cioè modelli Object Oriented (O-O) quindi è importante tener conto delle proprietà,

delle caratteristiche e di come si realizzano.

I principi fondamentali O-O sono:

• →

Astrazione l’oggetto che voglio modellare, corrisponde all’astrazione.

• →

Incapsulamento ogni entità che modelliamo nasconde agli altri il proprio stato, che quindi non

conoscono i dettagli di come è strutturato internamente, ma interagiscono con me solo con i

comportamenti.

Esempio: in Java le variabili di istanza non devono essere pubbliche.

• →

Ereditarietà il comportamento e lo stato possono essere specializzati. A livello più basso,

l’ereditarietà è una maniera per riutilizzare oggetti/classi esistenti (soprattutto nei linguaggi di

programmazione O-O, ma non tutti).

Esempio: Java è class based, quindi dalla classe posso creare delle istanze o delle classi derivate, più

aggiungere altro che specializza.

• →

Polimorfismo il comportamento dipende da chi sei. A partire da una singola classe, che serve per

specificare come sono fatti degli individui, si possono creare tante istanze diverse, ognuna delle quali

avrà lo stesso comportamento (stessa caratteristica) e una propria versione della struttura dello stato

(ogni istanza ha la propria copia). Agli oggetti si può accedere tramite un nome, inoltre essi hanno

dei tipi e delle references che vengono utilizzate l’accesso.

Class animal {

Esempio: //Proprietà che vengono ereditate

int age;

..

String makeVerse() {

return “my verse”;

}

}

Class Dog extends Animal {

…

//Faccio l’override del metodo

String makeVerse() {

return “bau bau”;

}

Dog spike = new Dog();

Animal spike = new Dog();

spike makeVerse;

//ne ho due versioni, ma viene chiamata quella di dog per il

polimorfismo.

//Perciò anche se la reference è di tipo Animal, l’oggetto è di tipo

Dog quindi stampa bau bau.

→ La reference può essere associata a oggetti di tipi diverso. Il comportamento però non è quello

→

del tipo della reference questo prende il nome di dynamic dispatching.

Storia di UML

Negli anni ’80 l’adozione di metodi di analisi e progettazione orientata agli oggetti, portò allo sviluppo di

→

diversi linguaggi di modellazione. Fra il 1989 e il 1994 il numero di metodi O-O passò da 10 ad oltre 100, i

metodi più promettenti erano quello di Booch, OOSE (Object-Oriented Software Engineering) di Jacobson e

OMT (Object-Modeling Technique) di Rumbaugh.

Nel 1994 il metodo di Booch e OMT iniziarono ad unificarsi, l’anno successivo si unì anche Jacobson e nel

1996 venne realizzata la prima versione di UML. Ci fu un importante aggiornamento qualche anno dopo, e

nel 2005 venne realizzata l’ultima versione che è quella tutt’ora in uso.

UML

UML nasce come linguaggio di programmazione software intensive, che parte dall’idea che si possa

modellare sia nel dominio del problema che nel dominio della produzione e in ogni caso si assume una

produzione O-O.

→ →

È un linguaggio visuale (grafico), che si esprime quindi attraverso diagrammi linguaggio semi-formale,

che quindi ha regole sintattiche e semantiche, per disegnare diagrammi validi e significativi.

→ NON è un software per lo sviluppo di progetti!

3 modi per applicare UML: →

1. UML come abbozzo diagrammi informali e incompleti, per esplorare parti difficili dello spazio del

problema o della soluzione

→

2. UML come progetto diagrammi di progetto relativamente dettagliati utilizzati per il reverse

engineering oppure per la generazione del codice.

3. UML come linguaggio di programmazione

→ La modellazione agile enfatizza l’uso di UML come abbozzo, è il metodo più comune per applicarlo spesso

con un elevato ritorno in termini di tempo.

UML è definito da uno standard di modellazione OMG chiamato MOF (Meta Object Facility) che è strutturato

→

in 4 livelli: M0, M1, M2, M3. I linguaggi basati su MOF, come UML, possono essere serializzati come

definito dallo standard XMI. →

M1 e M2 in un diagramma UML

Il modello UML include:

• →

Classifiers insieme di cose

• →

Events serie di occorrenze

• →

Behaviors serie di esecuzioni

• + Elementi che distinguono i diversi tipi di diagrammi

Elementi strutturali:

• →

Classi un classificatore che raggruppa oggetti con gli stessi attributi, operazioni, relazioni e

semantica.

• →

Casi d’uso un classificatore che raggruppa interazioni con risultati osservabili.

• →

Collaborazioni insieme di ruoli con un comportamento cooperativo in grado di realizzare

operazioni o casi d’uso.

• →

Interfacce insieme di operazioni che possono essere offerte o richieste da altri elementi.

• →

Pacchetti usati per raggruppare elementi e dare loro un namespace.

Entità di comportamento:

• Interazioni: unione di comportamenti basati su messaggi

• Annotazioni: migliorano la leggibilità del diagramma

→

Relazioni collegano 2 o più elementi, sono rappresentate da linee e sono di 4 tipi:

→

1. Associazione dato un elemento, possiamo risalire ad un altro

elemento che è legato concettualmente e possiamo risalire a

delle informazioni su di esso. In genere non si usa nella

modellazione concettuale.

→ Linea continua (e freccia aperta nell’end point).

→

2. Generalizzazione Indica che un elemento è la specializzazione

di uno più generale, cioè un certo elemento è un tipo di un altro

elemento.

→ Linea continua con freccia verso l’elemento più generale.

→

3. Dipendenza fra gli elementi c’è una relazione di tipo

“utilizzatore-fornitore” cioè un elemento ha bisogno delle

funzionalità di un’altra classe, quindi cambiamenti in un elemento

del modello può causare cambiamenti in altri elementi.

→ Linea tratteggiata con freccia aperta.

→

4. Realizzazione si ha fra due elementi del modello quando uno

dei due realizza, o implementa, un comportamento che l’altro

specifica. Il caso più comune è quando ci sono le classi che

realizzano un’interfaccia.

→ Come una dipendenza ma con la freccia a triangolo.

OCL

Nel metamodello di UML, un’operazione ha una firma, con nome e parametri, ed è associata ad un insieme

di oggetti UML di tipo Constraint, cioè vincoli classificati come “pre-condizioni” e “post-condizioni”OCL

(Object Constraint Language) è un linguaggio formale e rigoroso che può essere utilizzato in UML per

esprimere i vincoli delle operazioni. OCL definisce un formato ufficiale per specificare le pre-condizioni e le

post-condizioni per le operazioni.

System: makeNewSale()

Esempio:

pre: <dichiarazioni in OCL>

post: …

OCL comprende:

• →

Inv invariant

• →

Pre pre-condiction

• →

Post post-condiction

• →

Init valore iniziale in un contesto

• →

Derive definizione di un attributo derivato in un contesto

INGEGNERIA DEL SOFTWARE SLIDE 5

5. UML: USE CASE

I casi d’uso sono storie scritte, ampiamente utilizzati per scoprire e registrare i requisiti. Essi influenzano molti

aspetti di un progetto, compresa l’analisi e la progettazione orientata agli oggetti. →

I diagrammi dei casi d’uso e le relazioni tra casi d’uso sono secondari al lavoro che riguarda i casi d’uso.

Un semplice diagramma dei casi d’uso fornisce un diagramma di contesto per il sistema, visuale e conciso,

che illustra gli attori esterni e il modo in cui utilizzano il sistema.

I diagrammi dei casi d’uso sono dei diagrammi di comportamento, usati per descrivere le azioni svolte da uno

o più sistemi, o per descrivere collaborazioni con soggetti esterni al sistema.

→ Ogni caso d’uso dovrebbe dare risultati osservabili e di valore per uno specifico attore.

I diagrammi dei casi d’uso sono usati per specificare:

• I confini deli sistema, ciò che giace al suo esterno e come esso viene utilizzato;

• Il comportamento di un sistema esterno e i suoi attori;

• →

Ciò che un sistema dovrebbe fare requisiti dei soggetti e di chi usa il sistema

• →

Ciò che il sistema può fare funzionalità

• →

Requisiti che il soggetto pone nel suo ambiente, ma anche che il sistema pone sul suo ambiente

definendo le “regole” di interazione

→ Un errore comune è concentrarsi sui diagrammi di UML dei casi d’uso, anziché sul testo dei casi d’uso

che è molto più importante.

UC elements Ci sono 3 tipi di elementi:

• →

Attore qualcosa o qualcuno dotato di

comportamento (una persona, un sistema

informatico o un’organizzazione);

• →

Sistema oggetto in analisi all’interno del

quale vengono applicati i casi d’uso;

• →

Caso d’uso collezione di scenari correlati,

di successo e fallimento, che descrivono un attore

che usa un sistema per raggiungere un obiettivo.

Attore