Unified Modeling Language Introduzione alla notazione Introduzione al processo di sviluppo

Modeling ? Se si vuole costruire una cuccia al proprio cane: un

martello, dei chiodi, un metro, un po’ di legno …. Se si vuole costruire un grattacielo probabilmente lo

si sta facendo con i soldi di qualcun altro (vorrà mettere bocca sulle dimensioni, le finestre, il numero di ascensori) e non si procederà all’impresa da soli (i ruoli coinvolti potrebbero essere centinaia, le persone fisiche migliaia). E’ NECESSARIO MODELLARE !

Modeling ! Cos’è un modello ? ◦ Un modello è una semplificazione della realtà Le quattro equazioni di Maxwell sintetizzano tutti i

fenomeni elettromagnetici

Perché costruire modelli ? ◦ I modelli rappresentano il linguaggio dei

progettisti I modelli sono un veicolo di comunicazione I modelli descrivono in modo “visuale” il sistema da

costruire I modelli specificano la struttura ed il comportamento di

un sistema, forniscono una guida nella costruzione del sistema e documentano le decisioni prese

Modeling ! Un solo modello non è sufficiente ◦ Ogni sistema non banale deve essere affrontato

con un insieme di modelli quasi indipendenti Nel modello di un grattacielo, si devono modellare gli

ascensori, gli impianti di riscaldamento, l’impianto elettrico…

◦ Uno stesso modello può essere visto secondo diversi livelli di precisione. Modello di un impianto telefonico: connessioni tra

centraline Diramazioni all’interno delle stanze…doppino

I modelli sono uno strumento per gestire la complessità

Modelli Nello sviluppo dei sistemi software esistono due

principali approcci alla definizione di un modello: ◦ Algoritmico: i componenti del sistema sono le

funzioni o le procedure, i progettisti si concentrano sulle problematiche legate alla decomposizione di algoritmi in sottoalgoritmi… ◦ Orientato agli Oggetti: i componenti del sistema

sono gli oggetti che riflettono il dominio del problema, ognuno di essi ha un’identità, uno stato ed un comportamento.

UML pur essendo indipendente dalla metodologia di progetto si presta molto meglio ai modelli OO

Architettura di un Sistema Software

È definita dall’ insieme delle decisioni significative legate: ◦ All’ organizzazione di un sistema SW ◦ Alla selezione degli elementi strutturali che

compongono il sistema e delle relative interfacce, ◦ Al comportamento specificato mediante

collaborazioni tra gli elementi strutturali ◦ Alla composizione di questi elementi strutturali e

comportamentali in sottosistemi ◦ Allo stile architetturale che guida l’organizzazione

Architettura software: 4 + 1 views

P. Kruchten, “The 4+1 View Model of Software Architecture”, IEEE Software 12(6), pages 42-50,November 1995

Viste dell’ Architettura del Sistema… Use Case View

È relativa a come il sistema è visto dagli

utenti, dagli analisti e dai testatori. Essa non specifica, realmente, il modo secondo cui è organizzato il sistema; piuttosto, evidenzia le forze che modellano l’architettura del sistema.

…viste dell’ Architettura del Sistema… Logical View Comprende le classi, le interfacce e le

collaborazioni relative alla realtà di interesse che si sta modellando. Essa è diretta espressione dei requisiti funzionali del sistema, ovvero dei servizi che il sistema offre.

Process View Le attività del sistema (sia quelle visibili

direttamente all’utente che quelle di supporto) prevedono l’organizzazione di thread che potranno andare in concorrenza

…viste dell’ Architettura del Sistema Implementation View Concerne le problematiche di configuration

management relative ai file che ospitano i componenti il cui assemblaggio consente la creazione della release eseguibile

Deployment View Concerne gli elementi hardware che

ospiteranno il sistema, in particolare, cura le problematiche relative alla distribuzione ed all’installazione

Quante viste ?

È necessario definire il modello più semplice per risolvere il problema !

Non tutti i sistemi richiedono tutte le viste

Viste aggiuntive ◦ Dati, sicurezza…

ed UML ? Un LINGUAGGIO, non una semplice

notazione per disegnare diagrammi, attraverso cui è possibile catturare e trasferire la conoscenza relativa ad un soggetto (il sistema software) ed esprimere tale conoscenza a scopi di comunicazione.

Consente di modellare le caratteristiche del soggetto ed è il risultato dell’ unificazione delle migliori e più diffuse metodologie e tecniche usate in ambito industriale

Caratteristiche principali… Si tratta di un linguaggio, non di un metodo, quindi

non indicherà cosa fare per sviluppare un sistema software.

UML è un linguaggio per visualizzare, specificare, costruire, documentare gli artefatti di un sistema software è indipendente da qualsiasi linguaggio di programmazione non prescrive una sequenza di processo (non dice “prima bisogna fare questa attività, poi quest’altra, etc.), pur coprendo l’intero processo di produzione, e quindi può essere utilizzato da persone e gruppi che seguono metodi diversi (è “indipendente dai metodi”).

è supportato da più strumenti

…caratteristiche principali… UML è uno standard aperto dell’OMG

(Object Management Group) riunisce molte proposte esistenti è sponsorizzato dalle maggiori industrie produttrici di software

definisce una notazione standard, basata su un metamodello integrato degli elementi che compongono un sistema software.

è un linguaggio non proprietario (i suoi autori non hanno il copyright su UML)

Modello concettuale di UML UML è basato su un meta-modello integrato composto da

numerosi elementi collegati tra loro secondo regole precise, che consentono di creare modelli particolari ◦ Building blocks Elementi (costituiscono le principali astrazioni di un modello) Relazioni (consentono di mettere in relazione le astrazioni) Diagrammi (raggruppano collezioni di interesse di astrazioni)

Regole indicanti come comporre insieme i building blocks Meccanismi che si applicano attraverso tutto lo UML ◦ Specifications (specifiche testuali che accompagnano quelle

grafiche) ◦ Adornments (dettagli grafici o testuali aggiunti ai simboli base) ◦ Common divisions (per distinguere tra astrazioni e loro istanze) ◦ Extensibility mechanisms (Stereoptypes, tagged values,

constraints)

Elementi Elementi strutturali, costituiscono la parte statica di un

modello, rappresentano elementi sia concettuali che fisici: ◦ use case, class, interface, collaboration, component, node

Elementi comportamentali, costituiscono la parte dinamica del modello, rappresentano il comportamento del modello nel tempo e nello spazio: ◦ interaction, state machine

Elementi di raggruppamento, costituiscono la parte organizzazionale del modello, consentono la decomposizione del modello: ◦ Package (subsystem)

Elementi annotazionali, costituiscono la parte ‘esplicativa’ del modello, sono commenti per descrivere, evidenziare, rimarcare qualsiasi elemento del modello: ◦ annotazioni

Elementi strutturali

Elementi comportamentali

Elementi di raggruppamento

Relazioni

Diagrammi UML Viste statiche ◦ Use Case Diagrams ◦ Class Diagrams ◦ Object Diagrams ◦ Component Diagrams ◦ Deployment Diagrams

Viste dinamiche ◦ Sequence Diagrams ◦ Collaboration Diagrams ◦ Statechart Diagrams ◦ Activity Diagrams

Use case diagram Cattura le funzionalità del sistema dal punto di vista degli utenti ◦ Raccoglie un insieme di use case ed attori (un tipo speciale di classi) e le

relazioni tra essi. ◦ Rappresenta le modalità di utilizzo del sistema da parte di uno o più

utilizzatori (attori). ◦ Descrive l’interazione tra attori e sistema, non la “logica interna” della

funzione. ◦ Descrive l’organizzazione ed il modello del comportamento di un

sistema. Costruito nei primi passi dello sviluppo ◦ Ragionare sui casi d’uso aiuta ad individuare i requisiti funzionali.

Scopo ◦ Specificare il contesto di un sistema ◦ Catturare i requisiti di un sistema ◦ Validare l’architettura di un sistema ◦ Guidare la realizzazione ◦ Generare i casi di test

Sviluppato da analisti ed esperti di dominio

Esempio di use case diagram

Class diagram Cattura il vocabolario di un sistema ◦ Un class diagram rappresenta un insieme di classi,

interfacce, collaborazioni e relazioni. ◦ Specifica i vincoli e le relazioni che sussistono tra le

classi. ◦ Forniscono una rappresentazione statica di un

sistema. Costruito e raffinato per tutto lo sviluppo Scopo ◦ Nominare e modellare i concetti nel sistema ◦ Specificare le collaborazioni ◦ Specificare gli schemi logici di database

Sviluppato da analisti, progettisti e realizzatori

Esempio di class diagram

Sequence diagram

Cattura la dinamica del comportamento (time-oriented) ◦ Descrive dinamicamente le caratteristiche di

un sistema software, evidenziando le interazioni dovuto allo scambio di messaggi ed il loro ordinamento temporale

Scopo ◦ Modellare il flusso di controllo ◦ Illustrare scenari tipici

Esempio di sequence diagram

Statechart diagram

Cattura la dinamica del comportamento (event-oriented) ◦ Descrive il comportamento di un sistema in

termini di stati, transizioni, eventi ed attività, quindi ne evidenziano la dinamica

Scopo ◦ Modellare il ciclo di vita di un oggetto ◦ Modellare oggetti reattivi (interfacce utente,

dispositivi…)

Esempio di statechart diagram

Unified Modeling Language

Use Case Diagram Class Diagram Package Diagram Sequence Diagram

Requisiti e casi d’uso Il primo passo di “qualsiasi” processo di sviluppo è la

definizione dei requisiti ◦ Definizione del Business Model ◦ Solitamente informale e in linguaggio naturale

Jacobson (OOSE) propone una notazione particolare che è confluita in UML: i casi d’uso ◦ Esprime una interazione tipica tra un utente ed il sistema

software. Il punto di vista da adottare nella definizione dei casi d’uso è quello dell’attore, non quello delle funzionalità interne al sistema.

Cattura il comportamento esterno del sistema da sviluppare, senza dover specificare come tale comportamento viene realizzato (sistema = black-box)

Forniscono una descrizione delle “modalità” di utilizzo del sistema da parte di un utilizzatore (attore)

Esempio: gestione ordini

Casi d’uso per descrivere le interazioni utente-sistema I casi d’uso possono essere descritti sotto forma di scenario

di interazione (dialogo) tra gli utilizzatori e il sistema: Caso d’uso: effettuare ordine ◦ il cliente richiede l’elenco dei prodotti ◦ il sistema propone i prodotti disponibili ◦ il cliente sceglie i prodotti che desidera ◦ il sistema fornisce il costo totale dei prodotti selezionati ◦ il cliente conferma l’ordine ◦ il sistema comunica l’accettazione dell’ordine

Un caso d’uso rappresenta una funzionalità dal punto di vista di chi la utilizza ◦ ogni caso d’uso può soddisfare più requisiti funzionali ◦ un requisito funzionale può dare origine a più casi d’uso ◦ a ogni caso d’uso possono venire associati più requisiti non

funzionali

Elementi grafici del modello dei casi d’uso Il modello dei casi d’uso presenta una

vista del sistema con gli attori, i casi d’uso e le loro associazioni

Attore Un ruolo (o un insieme di ruoli) che l’utente del caso d’uso svolge

nell’interagire col sistema ◦ E’ esterno al sistema ◦ Può essere: Una classe di persone fisiche (es. Fornitore) Un altro sistema software (es. Sistema di contabilità)

◦ Un dispositivo hardware esterno (es. Sensore) Controlla le funzionalità Fornisce input o riceve output dal sistema Può partecipare a più use case Uno stesso utente può rivestire più ruoli nel medesimo use case Uno stesso use case può coinvolgere più actor Un actor non necessariamente è un essere umano Un attore sollecita il sistema con un qualche evento e ne riceve un

output.

Relazioni principali

Esempio: centralina telefonica per ufficio

Documentazione: descrizione dei casi d’uso Per ogni use case:

Titolo: Effettua chiamata diretta Autori: Pluto e Topolino Descrizione: L’utente compone il numero

per effettuare una chiamata diretta Attori: Utente Pre-condizioni: Non identificate Post-condizioni: Non identificate Scenari …

Scenari Ogni use case dovrebbe essere corredato da

un insieme di scenari Scenari principali (più possibile) ◦ Tutto funziona correttamente

Scenari secondari (pochi e significativi) ◦ Eccezioni (eventuali problemi o

malfunzionamenti) Si devono definire tanti scenari quanti sono

quelli necessari per capire il corretto funzionamento del sistema e le eccezioni che si ritengono significative durante l’analisi

Effettua chiamata interna Scenario 1: chiamata effettuata con successo L’utente solleva la cornetta Il tono di libero interno suona L’utente compone il numero La chiamata è inoltrata sulla rete telefonica Il telefono chiamato squilla Il tono di attesa suona L’utente chiamato risponde I telefoni sono connessi Il telefono chiamato cessa di squillare Il tono di attesa finisce L’utente chiamato ripone la cornetta sul telefono I telefoni sono disconnessi L’utente ripone la cornetta sul telefono

Effettua chiamata interna Scenario 2: il telefono chiamato è occupato

L’utente solleva la cornetta Il tono di libero interno suona L’utente compone il numero La chiamata è inoltrata sulla rete

telefonica Il telefono chiamato è occupato Il tono di occupato suona L’utente ripone la cornetta sul telefono

Class Diagram

Definisce la visione statica del sistema classi (di oggetti): incapsulamento di struttura dati e funzioni

relazioni tra classi ◦ associazione (uso) ◦ generalizzazione (ereditarietà) ◦ aggregazione (contenimento)

È forse il modello più importante perché definisce gli elementi base del sistema

Classi in UML

In UML una classe è composta da tre parti ◦ nome ◦ attributi (lo stato) ◦ metodi o operazioni (il comportamento)

Class - names

attributi

Per ciascun attributo si può specificare il tipo ed un eventuale valore iniziale

Tipicamente il nome di un attributo è composto da una parola o più parole ◦ usare il maiuscolo per la prima lettera di

ciascuna parola lasciando minuscola la lettera iniziale del nome

Operazioni

Per ciascuna operazione si può specificare il solo nome o la sua signature, indicando il nome, il tipo, parametri e, in caso di funzione, il tipo ritornato

Valgono le stesse convenzioni dette per gli attributi per l’uso di minuscolo e maiuscolo per i nomi delle operazioni

Molteplicità delle associazioni

La molteplicità dice ◦ Se l’associazione è obbligatoria oppure no ◦ Il numero minimo e massimo di oggetti di una

classe associati con un singolo oggetto di un’altra classe ◦ Il simbolo di molteplicità adiacente alla classe

B indica quante istanze della classe B possono avere legami con una singola istanza della classe A

Package diagrams Una delle soluzioni utilizzate per

rappresentare i sistemi object oriented è basata sull’idea di package.

Un package raccoglie un insieme di classi la cui interazione è funzionale all’assolvimento di una certa responsabilità da parte del sistema.

A parte il livello di astrazione non ci sono differenze tra un Class Diagram ed un Package Diagram.

Package Diagrams - Dipendenze Una dipendenza tra due package sussiste

se esiste una dipendenza tra almeno due classi appartenenti a ciascuno dei package in questione.

Se qualche classe in Orders cambia è opportuno verificare se qualche classe di Order Capture Application deve essere a sua volta modificata.

Teoricamente solo delle modifiche all’interfaccia di una classe dovrebbe interessare (in modifica) altre classi

Modelli dinamici I modelli dinamici descrivono il comportamento

del sistema in funzione del tempo ◦ I modelli dinamici sono un tipo di modello

operazionale (modello che descrive il comportamento desiderato) ◦ Utili soprattutto per sistemi orientati al controllo

(embedded systems, sistemi interattivi, traduttori, sistemi operativi, software di comunicazione)

Modelli dinamici in UML ◦ Diagrammi di interazione Diagrammi di sequenza Diagrammi di collaborazione

◦ Diagrammi di stato ◦ Diagrammi di attività

Interaction Diagrams

Un Interaction Diagram modella le interazioni che sussistono tra un certo numero di oggetti che interagiscono per risolvere un problema

Una interazione è un comportamento che comprende un insieme di messaggi scambiati tra un insieme di oggetti nell’ambito di un contesto per raggiungere uno scopo

Interaction

Una interaction, tipicamente, avviene tra oggetti tra cui esiste un link (esiste un’istanza di una association)

Un message è una specificazione di una comunicazione tra oggetti che trasmette informazione con l’aspettativa che ne conseguirà una attività. La ricezione di un message può essere considerata una

istanza di un evento.

Sequence diagram Evidenziano la sequenza temporale delle

azioni Non si vedono le associazioni tra oggetti Le attività svolte dagli oggetti sono mostrate

su linee verticali La sequenza dei messaggi scambiati tra gli

oggetti è mostrata su linee orizzontali Possono corrispondere a uno scenario

specifico o a un intero caso d’uso (aggiungendo salti e iterazioni)

Si possono annotare con vincoli temporali

Messaggi ed azioni Ad un message possono corrispondere diversi tipi di azioni;

in UML sono previste le seguenti azioni di base: ◦ Call : invoca una operation di un object; un oggetto può inviare

un messaggio a se stesso, invocando una propria operation ◦ Return : restituisce un valore al chiamante ◦ Send : invia un signal ad un oggetto ◦ Create : crea un object ◦ Destroy : distrugge un oggetto; un oggetto può distruggere se

stesso I message scambiati tra due o più oggetti possono formare

una sequenza; una sequenza di message deve avere un punto di inizio

Per meglio visualizzare l’ordine sequenziale dello scambio dei message è possibile ‘numerare’ i message anteponendo al loro nome un numero che indica l’ordine nella sequenza.

Tipi di messaggi

Sequence diagram: scenario “chiamata effettuata con successo” del caso d’uso “effettua chiamata interna”

Domande ?