Uml (Unified Modeling Language) un linguaggio di modellazione orientato agli oggetti Luigi Lavazza



Scaricare 523 b.
24.01.2018
Dimensione del file523 b.


UML (Unified Modeling Language) un linguaggio di modellazione orientato agli oggetti

  • Luigi Lavazza

  • CEFRIEL

  • lavazza@cefriel.it


Sommario

  • Introduzione ai linguaggi di modellazione

  • Fondamenti del paradigma object-oriented

  • UML: il linguaggio

  • Esempi di modellazione con UML



I modelli

  • Ragionare sui sistemi complessi è difficile.

  • Costruire sistemi complessi è difficile.

  • Come fare a valutare aspetti notevoli dei sistemi, o a valutare l’efficacia di soluzioni costruttive senza affrontare l’intera complessità di un sistema reale?

  • Usando dei modelli.



Modellare: un’idea nuova?

  • Non proprio

  • si pensi al modello di cupola del Brunelleschi



Caratteristiche del modello

  • Astrazione

  • Modularità

  • Viste molteplici



Astrazione

  • Un sistema reale è caratterizzato da un numero impressionante di elementi.

  • Spesso, solo una minima parte di tale elementi risultano “interessanti”

    • NB: cosa sia interessante dipende dal contesto
  • Ne consegue che il modello può trascurare i dettagli irrilevanti.

  • Astrazione = descrizione di un sistema (o di parte di esso) che ne riporta solo le caratteristiche rilevanti.



Astrazione: esempio

  • Caratteristiche di una persone:

    • Nome,
    • Indirizzo
    • Età
    • Numero di scarpe
    • Gruppo sanguigno
    • Codice fiscale
    • Fede calcistica
    • Reddito
  • La stragrande maggioranza dei contesti che possiamo immaginare richiedono la conoscenza di un sottoinsieme di queste caratteristiche



Modularità

  • Divide et impera

  • Un sistema è modulare se è diviso in parti che hanno una sostanziale autonomia individuale ed una ridotta interazione con le altre parti

    • i moduli sono scarsamente connessi e fortemente coesi


Cinque criteri di modularità

  • Scomponibilità modulare

    • scomporre un problema in sottoproblemi di minori dimensioni e quindi più facilmente affrontabili
  • Componibilità modulare

    • ri-aggregare moduli esistenti per risolvere problemi nuovi
    • riusabilità
    • ES: Lego
  • Comprensione modulare

    • capire un modulo osservando solo quello e i "confinanti“
  • Continuità modulare

    • un piccolo cambiamento nelle specifiche comporta cambiamenti in un solo (o pochi) moduli
    • estendibilità
  • Protezione modulare

    • errori in un modulo influenzano solo il modulo stesso (o al massimo si propagano ai confinanti)


Come ottenere la modularità

  • Unità linguistiche modulari

  • Poche interfacce

    • ciascun modulo deve comunicare con il minor numero possibile di altri moduli
    • in un sistema composto da n moduli il numero delle interfacce deve essere quanto più possibile vicino a (n-1) e lontano da n(n-1)/2
  • Interfacce piccole

    • ogni modulo deve scambiare il minor numero possibile di informazioni con gli altri moduli
  • Interfacce esplicite

    • il fatto che due moduli A e B comunichino deve risultare evidente sia dal codice di A che dal codice di B
  • Information hiding

    • il modulo deve distinguere tra informazioni pubbliche ed informazioni private


Molteplici viste

  • Un sistema complesso presenta molteplici “aspetti” che devono essere considerati ed adeguatamente descritti per rappresentare il sistema, ritraendone tutte le caratteristiche.

  • Risulta quindi difficile comprimere in un unico modello informazioni di natura anche molto diversa: si consideri ad esempio il fatto che una rappresentazione adeguata del sistema deve descrivere

    • la struttura statica
    • il comportamento dinamico
    • l’organizzazione logica
    • la distribuzione fisica
    • ecc.
  • Soluzione: non un modello, ma più modelli, ciscuno specializzato per fornire un certo tipo di informazioni



Molteplici viste

  • Un’idea nuova?

  • Non proprio …



Linguaggi di descrizione

  • Le “descrizioni” vengono prodotte in svariate fasi del processo:

    • Descrizione = insieme di affermazioni riguardo una qualche realtà di interesse
    • Problem definition = fra l’altro, descrizione del problema da risolvere
    • Program design = fra l’altro, descrizione del comportamento del sistema da realizzare
  • Linguaggi di descrizione = linguaggi adatti a scrivere “descrizioni”



Caratteristiche dei linguaggi di descrizione

  • Completezza

    • Il linguaggio deve mettere a disposizione strumenti per descrivere tutti gli aspetti di interesse.
  • Accuratezza

    • Deve essere possibile costruire una descrizione precisa.
  • Consistenza

    • Il linguaggio deve aiutare a non esprimere concetti contraddittori in diverse rappresentazione della stessa descrizione.
  • Comprensibilità

    • La descrizione deve essere facilmente comprensibile da parte di chi la deve interpretare.
  • Formalità

    • Rigore con cui sono definite la sintassi e la semantica del linguaggio.
  • Stile

    • Quale aspetto del sistema è più facile descrivere utilizzando il linguaggio (comportamento o proprietà)


Grado di formalità

  • Informale: tipicamente linguaggio corrente (italiano, inglese)

    • Spesso usato perché è usabile con poco sforzo
    • Può dar luogo ad ambiguità
  • Semi-formale (ha sintassi ma poca semantica)

    • Facilmente comprensibile, ma possibile fonte di ambiguità
  • Formale (ha sia sintassi sia semantica rigorosa)

    • Ha fondamenti logico-matematici: elimina ambiguità
    • Consente di ragionare su e verificare proprietà, anche con strumenti (semi)automatici che supportano quel linguaggio
    • N.B. Non tutte le proprietà sono formalmente verificabili


Stile

  • Stile descrittivo: definisce le proprietà desiderate

    • Es. La curva soddisfa l’equazione ax2 + by2 + c = 0.
  • Stile operazionale: definisce il comportamento desiderato (una “macchina”)

    • Es. La curva rappresenta il cammino di un punto che si muove in modo che la somma delle sue distanze da due punti fissati P1 e P2 rimanga costante.


Il paradigma object-oriented



I concetti base del paradigma Object-Oriented

  • Classi

  • Oggetti

  • Generalizzazione/specializzazione

  • Polimorfismo

  • Dynamic binding



Classe

  • Una classe definisce un insieme di possibili oggetti

  • È la descrizione –astratta– di una tipologia di oggetti

  • Automobile, felino, fenomeno atmosferico, copricapo sono possibili classi.

  • NB: la classe è una descrizione

    • Gli oggetti che descrive sono elementi del mondo reale
    • La classe esiste su un piano diverso


Classe: dati e comportamento

  • La classe descrive sia le caratteristiche statiche degli oggetti che il loro comportamento (le operazioni in cui possono essere coinvolti)

  • Attributi: sono i “dati” che caratterizzano la classe

  • Esempio:

    • La classe conto corrente avrà gli attributi: numero, titolare, saldo, ecc.
  • Operazioni (o “metodi”): sono le operazioni che si può chiedere agli oggetti di eseguire

  • Esempio:

    • La classe conto corrente sarà dotata delle operazioni di versamento, prelevamento, bonifico, ecc.


Classi: proprietà pubbliche e private

  • Contenuti privati

    • attributi e metodi accessibili solo dall’interno della classe
  • Contenuti pubblici

    • attributi e metodi accessibili dall’esterno (cioè da altre classi)
  • Servono a realizzare l’information hiding

  • È desiderabile che tutti gli attributi siano privati.

    • Questo rende la classe accessibile solo attraverso le operazioni pubbliche.
    • Conseguenza: la altre classi sanno cosa possono fare con una classe, ma non sanno come la classe funziona internamente
    • Modularità!
    • Concetto nuovo? Non proprio: noi conosciamo solo l’interfaccia pubblica della banca, del videoregistratore, dell’automobile, …


Oggetto

  • Definizione

    • Istanza di una classe
    • Esemplare corrispondente alla descrizione fornita dalla classe
  • Ogni oggetto ha associate le proprietà descritte nella classe di cui è istanza

    • Tutte le istanze della stessa classe si comportano nello stesso modo
    • Ma oggetti diversi che sono istanze della stessa classe avranno valori degli attributi diversi
  • Esempio:

    • La classe Persona prevede l’attributo età
    • Rossi e Bianchi sono istanze di persona
    • Sia Rossi che Bianchi hanno dunque un’età
    • I valori delle età di Rossi e Bianchi possono chiaramente essere diversi


Oggetto

  • Un oggetto incapsula:

    • stato = valore di attributi
    • comportamento = metodi
  • Il comportamento dipende spesso dallo stato

  • Esempi

    • La classe Persona comprende lo stato civile: l’operazione “matrimonio” è disponibile solo se l’oggetto è nello stato “celibe”
    • La classe Motore comprende l’operazione di accensione, che è disponibile solo se gli attributi del motore indicano che non è guasto ed il carburante è presente.


La metafora di interazione

  • Un metodo si invoca mandando un messaggio all'oggetto

  • In altre parole: per stimolare un certo comportamento da parte di un oggetto, gli mandiamo un messaggio contenente l’invocazione del metodo dell’oggetto corrispondente al comportamento che desideriamo ottenere.

  • Chi manda i messaggi? Un altro oggetto. Nel modello object-oriented qualunque cosa è un oggetto.



Classi: attenzione all’astrazione

  • Lo scopo semantico della classe e l’astrattezza della descrizione possono portare a situazioni apparentemente bizzare, ma perfettamente logiche.

  • Esempio:

    • Scopo semantico = bene materiale, caratterizzato dalla sua descrizione e valore
    • Classe Bene
    • La mia auto e il mio box sono istanze della stessa classe
    • Il cavallo e la stalla del Sig. Rossi sono istanze della stessa classe
  • Esempio:

    • Scopo semantico = gli insegnanti
    • Classe Insegnante
    • Il sig. Mauro Rossi e il suo fratello genello sono istanze di classi diverse (uno è insegnante, l’altro no).


Classi come insiemi

  • Una classe può essere vista come un insieme

  • Le istanze della classe appartengono all’insieme associato alla classe

  • Esempio

    • Classe Libro
    • Le istanze “Pinocchio”, “Tom Sawyer”, “Il nome della rosa” appartengono all’insieme dei libri, così come tutte le altre istanza di Libro.


Oggetti complessi

  • Sono oggetti costruiti a partire da oggetti più semplici.

  • Occorre fornire operatori per gestire gli oggetti complessi.

  • Questo vuol dire che in generale un'operazione effettuata su un oggetto complesso generico (cioé avente qualunque struttura) deve propagare transitivamente i propri effetti ai componenti dell'oggetto operando.

    • Esempio: "deep" e "shallow" copy.


Identità degli oggetti

  • Un oggetto esiste indipendentemente dal suo valore.

  • Esistono due relazioni di equivalenza sugli oggetti:

    • identità (due oggetti sono in realtà il medesimo oggetto)
    • uguaglianza (due oggetti hanno lo stesso valore)
  • Se l'oggetto é complesso l'uguaglianza può essere "deep" o "shallow".



Identità degli oggetti - condivisione

  • Esempio: una persona ha un nome, un età e un insieme di figli.

  • Carlo e Maria hanno entrambi un figlio di 15 anni di nome Luca. Sono possibili due situazioni:

    • Luca é il figlio di Carlo e Maria
    • Ci sono due persone di nome Luca di 15 anni, uno figlio di Carlo e uno di Maria
  • Un sistema basato sull'identità rappresenta in modo naturale entrambe le situazioni:



Identità degli oggetti Aggiornamento di oggetti condivisi

  • Quando un oggetto condiviso viene aggiornato tutti gli oggetti cui appartiene automaticamente ed immediatamente vedono il cambiamento.

    • Es: carlo->figlio->anni += 1
  • Questo meccanismo é al tempo stesso potente e pericoloso (side-effects).



Generalizzazione

  • È una relazione tra classi (cioè tra descrizioni)

  • Rappresenta il ben noto concetto di generalizzazione (o specializzazione se visto nel senso inverso)

  • Una classe A è una generalizzazione di una sottoclasse B se la tipologia rapprersentata da A comprende come caso particolare (specializzazione) la tipologia B.

  • Esempi

    • La classe Studente è una specializzazione della classe Persona
    • La classe Primate è una specializzazione della classe Mammifero, che a sua volta è una specializzazione della classe Animale
  • La relazione di generalizzazione non è limitata alle classi, ma può essere usata anche tra altri tipi di descrizioni



Generalizzazione

  • Generalizzazione = relazione "is-a“ (“è un/una”)

    • Ogni istanza di una classe è anche istanza di tutte le superclassi
    • Fuffy è un felino. Dunque è anche un mammifero e un animale.
  • La generalizzazione forma una gerarchia

    • Non è possibile (neanche indirettamente) che A sia una specializzazione di B e B una specializzazione di A


Generalizzazione

  • Perché usiamo la generalizzazione nei modelli?

    • Condivisione di proprietà
      • Le sottoclassi hanno tutte le proprietà delle super-classi
      • Possono essere descritte incrementalmente
    • Compatibilità
      • Le sottoclassi sono compatibili con le superclassi
      • Ad es. se la maestra chiede di disegnare un animale, va bene sia il disegno di un felino che di un rettile


Condivisione di proprietà



Quando usare la generalizzazione?

  • Quando esistono classi “simili” (cioè che condividono un insieme di proprietà) che –rispetto agli scopi del modello– presentano differenze rilevanti.

  • NB: possono esistere tipologie di modelli molto diverse nel mondo reale, ma che rispetto allo scopo semantico richiesto dal modello possono essere rappresentate mediante un’unica classe (cioè mediante un’unica astrazione).

  • Regola: non creare una specializzazione se non ce n’è bisogno.



Polimorfismo

  • Conseguenza dell’esistenza di generalizzazione e della compatibilità delle sottoclassi rispetto alle superclassi



Polimorfismo

  • Un riferimento polimorfico:

    • ha un tipo statico
      • Nell’esempio precedente, il disegno è composto di oggetti di tipo Figura
    • ha un tipo dinamico: può riferirsi, nel corso dell'esecuzione del programma, a istanze di più di una classe;
      • Nell’esempio precedente, il disegno a un certo punto potrebbe comprendere solo un ellisse, più tardi solo due rettangoli


Dynamic binding

  • Binding:

    • Il collegamento tra il nome di una operazione e la sua implementazione
  • Dynamic binding:

    • Un oggetto invia un messaggio a un altro oggetto, di cui ignora il tipo dinamico
    • L’operazione eseguita dipende dal tipo effettivo dell’oggetto ricevente


Dynamic binding: esempio



Unified Modeling Language



Unified Modeling Language

  • È un insieme di linguaggi che, utilizzati congiuntamente, consentono di descrivere/modellare tutti (o quasi) gli aspetti rilevanti di un sistema, secondo con un approccio object-oriented

  • Notazione grafica

  • Linguaggio semi-formale

  • Stile misto

    • parzialmente dichiarativo, parzialmente operazionale
  • Standard OMG per la modellizzazione di sistemi Object-Oriented sin dal 1997



Situazione

  • Dove trovare informazioni costantemente aggiornate:

    • http://www.rational.com
    • http://www.omg.org
    • internet newsgroup comp.object


Indice

  • Diagrammi UML

    • Class e Object Diagram
    • Use Case Diagram
    • Interaction Diagram
      • Sequence Diagram
      • Collaboration Diagram
    • Composite structure Diagram
    • Statechart Diagram
    • Activity Diagram
    • Component Diagram
    • Deployment Diagram


I class diagram

  • Forniscono una vista strutturale (statica) del sistema in termini di

    • classi
      • attributi
      • operazioni
    • relazioni tra classi (associazioni, generalizzazioni, ...)
  • Un class diagram rappresenta uno schema concettuale

    • se una classe A è in relazione con una classe B, allora ogni istanza di A sarà in relazione con un’istanza di B


Classi

  • Una classe descrive un gruppo di oggetti con caratteristiche comuni

    • attributi
    • comportamento
  • Gli oggetti (istanze) di una stessa classe differiscono tra loro per i valori degli attributi e per le relazioni che li legano ad altri oggetti.



Notazione generale per le classi

  • Nel caso più generale la notazione è la seguente.



Operazioni

  • Un operazione è una funzione o una trasformazione applicabile ad un’istanza di una classe (ogni operazione ha come argomento implicito un oggetto obiettivo)

    • La stessa operazione può essere definita in classi diverse
    • Il comportamento dipende dalla classe a cui appartiene l'oggetto obiettivo


Relazioni in UML

  • In un Class Diagram vengono rappresentate relazioni oltre alle classi:

    • Associazioni (semplici, aggregazioni, composizioni)
    • Relazioni di generalizzazione
    • Relazioni di dipendenza
    • Relazioni di raffinamento


Associazioni

  • Una Associazione individua una “connessione” logica tra classi

    • Il significato della relazione è specificato solo attraverso l’etichetta dell’associazione
    • si traduce in una connessione fra oggetti istanze delle classi coinvolte nell’associazione


Cardinalità nelle associazioni

  • Indica il numero di istanze di una classe che possono essere associate ad una singola istanza dell’altra classe

  • Può non essere specificata ad uno degli estremi (“association-end”) o a entrambi

    • E in questo caso non significa cardinalità pari a 1!


Cardinalità delle associazioni



Notazione per la cardinalità

  • Nota: Il class diagram indica che una persona può possedere un numero qualsiasi di auto

  • Quanti sono i proprietari di una singola auto?

    • Il diagramma non fornisce questa informazione, dato che la cardinalità della partecipazione di Persona all’associazione risulta non specificata!
    • Inoltre, dato che l’associazione è navigabile in una sola direzione, data un’auto non è mai possibile risalire ai suoi (o al suo) proprietario


Ruoli nelle associazioni

  • Una classe può partecipare ad un’associazione con un ruolo specifico, che può essere indicato



Attributi delle associazioni (Association Class)

  • In molti casi alcune proprietà sono proprie dell'associazione piuttosto che delle classi coinvolte.



Associazioni esclusive

  • Talvolta un’associazione può esistere verso una classe o verso un’altra (non verso entrambe)



Diagrammi delle Istanze (Object Diagram)

  • Descrivono singole istanze di classi (oggetti) e associazioni (links) rappresentate in un particolare class diagram

  • Adatti a descrivere esempi o situazioni specifiche (punti di vista o “fotografie” delle istanze esistenti in un certo istante di tempo)



Oggetti: Notazione grafica

  • Scopo delle istanze è solitamente di fornire degli esempi di oggetti, oppure evidenziare oggetti di particolare rilevanza.



Link e Object Diagram

  • Un legame (link) è una connessione fisica o concettuale fra due istanze.

  • Mentre un'associazione connette due classi, un link connette due oggetti.

  • I link sono istanze delle associazioni.



Object diagram: Esempio



Aggregazione

  • È un caso particolare di associazione molto comune che significa: “è un insieme di".



Composizione

  • È un caso particolare di aggregazione che significa: “è composto da".

    • i componenti non possono esistere senza il contenitore
    • la proprietà da parte del contenente è esclusiva
      • Quindi la molteplicità dal lato dell’aggregato non può essere >1
      • Può essere qualsiasi per gli elementi componenti


Relazioni di aggregazione: Semantica

  • Varianti

      • esclusiva, dipendente, ma assenza di propagazione delle operazioni


Associazioni riflessive

  • Una associazione o aggregazione si dice riflessiva ( o ricorsiva) se coinvolge oggetti della stessa classe

    • una associazione ricorsiva indica che più oggetti della stessa classe interagiscono e collaborano in qualche modo


Generalizzazione



Generalizzazione ed ereditarietà: Esempi (2)

  • La classe Studente eredita dal padre:

    • attributi
    • metodi
  • Un oggetto Studente può essere trattato esattamente come un oggetto Persona

  • In cosa solitamente può differenziarsi la classe erede

    • aggiunta di attributi e metodi
    • i metodi possono essere ridefiniti


Generalizzazione: Esempi (3)



Significati della generalizzazione

  • Una sottoclasse può ridefinire alcune proprietà della superclasse

  • Una sottoclasse può anche ridefinire il protocollo delle operazioni

    • Cioè in una sottoclasse si può ridefinire un’operazione ereditata dalla superclasse, cambiandone anche parametri e tipo restituito


Uso della delega (delegation)

  • Devo definire la classe pila (col solito significato)

  • Dispongo di una classe Sequenza, che vorrei riutilizzare



Classi astratte

  • Una classe astratta è una classe che non può essere direttamente istanziata

  • Può (anzi deve) avere delle sottoclassi concrete

    • e queste possono essere istanziate (se non sono astratte a loro volta)


Classi astratte (2)

  • Il termine “astratto” viene anche utilizzato per per descrivere una operazione per la quale non è stata definita una implementazione

    • Le operazioni astratte di una classe si rappresentano scrivendo il nome in corsivo
  • Una classe astratta può avere operazioni concrete

    • Almeno una operazione deve essere astratta
  • Tipicamente vengono usate

    • per mettere a fattor comune un'astrazione di un certo tipo
    • per favorire il riuso


Classi astratte: Esempio

  • Il disegno è composto di figure. Non importa come sono fatte. Il disegno sa solo che per disegnare (draw) se stesso può chiamare il metodo draw delle figure.

    • Aggiungendo una sottoclasse a figura il codice di gestione dei disegni non cambia!


Eredità multipla



La delega

  • La delega consiste nel "delegare" una entità apposita (es. RapportoDiLavoro) a svolgere particolari operazioni.



Vincoli relativi sulle associazioni



Dipendenza

  • Relazione che indica una dipendenza di varia natura tra elementi di un modello UML

    • Si può avere dipendenza tra classi, packages, use cases, etc.
  • Individua una connessione “semantica” tra due elementi, uno dei quali è dipendente dall’altro

    • Una modifica nell’elemento indipendente ha effetti su quello dipendente


Dipendenza: Esempio



Costrutti di raggruppamento

  • Modulo: raggruppa classi, associazioni e generalizzazioni

    • fornisce una vista del problema
    • diminuisce la complessità del problema
  • La suddivisione in moduli può essere fatta in diversi modi.

    • Criterio: forte coesione, scarse connessioni


Packages

  • Forniscono un costrutto di raggruppamento per gli elementi definiti in un modello UML

  • A volte si utilizza il termine subsystem per indicare un package

  • È possibile definire delle relazioni (tipicamente di dipendenza, raffinamento, generalizzazione) tra packages diversi



Dipendenze tra Packages

  • Descrivono, ad un livello di astrazione più alto, dipendenze esistenti tra elementi contenuti nei singoli packages

    • dipendenze multiple dello stesso tipo tra singoli elementi (ad es. Classi) appartenenti a packages diversi vengono “riassunte” in una singola dipendenza tra i packages contenenti i diversi elementi
  • Tipologie di relazioni tra packages

    • Generalizzazione
      • Esiste almeno una relazione di generalizzazione tra elementi appartenenti a package diversi
    • Dipendenza
      • Esiste almeno una relazione di dipendenza tra elementi appartenenti a package diversi


Dipendenze tra Packages (2)

  • In generale, se non si esplicita una relazione di dipendenza, un package non può accedere agli elementi contenuti in un altro package

    • Le relazioni di dipendenza definiscono delle “permission” per l’accesso al contenuto di altri packages (limitatamente agli elementi con visibilità public o protected presenti nel package target)
  • Le relazioni di dipendenza tra packages non sono transitive

    • Se il package A può vedere B e B può vedere C, non è detto che A possa vedere C


<> e <>

  • Dipendenza con stereotipo <>

    • Gli elementi contenuti nel package target possono essere referenziati dagli elementi contenuti nel package client (o dai sub-package in esso contenuti)
    • Una dipendenza di tipo <> non modifica il namespace del client e non crea riferimenti di alcun tipo
      • Garantisce solo la possibilità di creare refrences
  • Dipendenza con stereotipo <>

    • I nomi degli elementi presenti nel namespace del package target vengono aggiunti al namespace del package client (con le stesse regole di visibilità valide per <>)
    • Se ci sono conflitti fra i nomi importati e nomi già presenti nel namespace del client, il modello è mal formato (ill formed)


Dipendenze tra packages: Esempio



Use Case Diagram

  • È una tipica interazione tra l’utente e il sistema informatico.

    • Esempi per un word processor:
      • sottolinea una parte di testo
      • crea un indice
  • Quindi, uno use case

    • rappresenta una funzione visibile dall’utente
    • rappresenta un obiettivo specifico (atomico) per l’utente
    • può essere di “dimensioni” diverse
    • Descrive
      • Il sistema
      • L’ambiente
      • Le relazioni fra sistema e ambiente
  • Ogni caso di utilizzo identificato

    • È etichettato con un nome
    • Viene descritto graficamente
    • Viene descritto con del testo (la notazione grafica non basta)


Use Case: Elementi caratteristici

  • Uno Use case consente di individuare il comportamento (in termini di funzionalità offerte) di un sistema o di una qualsiasi altra entità definita nel sistema senza entrare nel dettaglio della struttura interna dell’entità

  • Uno Use Case individua una tipologia di possibili utilizzi del sistema (descritti testualmente)



Use case diagram



Use case diagram

  • Esempio: Sistema per la gestione delle vendite dei prodotti di una azienda

    • Si vuole descrivere la possibilità da parte del venditore di effettuare l’evasione di un ordine


Actor (attori)

  • Attore = Entità esterna al sistema che interagisce con il sistema assumendo un particolare ruolo

    • non c’è necessariamente corrispondenza tra attori e individui precisi
    • possono esserci diversi utenti con lo stesso ruolo, e diversi ruoli possono essere ricoperti dallo stesso utente
    • possono esserci diversi attori che esercitano lo stesso use case, e diversi use case possono essere esercitati dallo stesso attore
    • non è detto che un attore corrisponda a uno o più persone: può essere un sistema esterno
      • nonostante l’icona standard utilizzata per la rappresentazione


Relazioni tra attori e use case



Use case diagram: esempio



Use Case, Use Case Instances e Scenari

  • Uno Use Case individua una tipologia di “storie” d’uso del sistema

  • Una istanza dello Use Case individua una specifica storia d’uso

    • Specifica una delle possibili sequenze di azioni che possono avvenire durante lo svolgimento dello use case
  • Scenario: È una istanza di use case corredata da una descrizione esplicita

    • Il termine “scenario” non è usato in modo sempre consistente.


Scenari

  • Uno “scenario” individua e descrive esplicitamente una particolare istanza di uno use case, ovvero una delle possibili varianti

    • Ad es. un ordine può essere elaborato regolarmente, o può mancare la merce ordinata o può mancare il credito nei confronti dell’ordinante, … Ciascuno di questi casi è uno scenario specifico dello use case “gestione ordini”.
  • Ogni Use Case è caratterizzato da uno scenario base (sequenza tipica di eventi) e da un numero, imprecisato a priori, di varianti

  • Le varianti possono essere aggiunte nei successivi raffinamenti dello use case



Relazioni tra Use Cases

  • Esistono tre tipi di relazioni possibili tra use cases:

    • Generalizzazione
      • Simile alla generalizzazione tra classi
    • Inclusione
      • Il comportamento individuato dallo use case target viene incluso nella sequenza di azioni svolta dalle istanze dello use case base
    • Estensione
      • Le funzionalità individuate da uno use case base vengono estese, al verificarsi di opportune condizioni, con funzionalità definite in un altro use case


Esempio



I requisiti non funzionali

  • Gli use case non sono adatti a specificare i requisiti non funzionali.

  • Poiché tali requisiti sono di importanza fondamentale occorre inventarsi un modo per descriverli comunque.

  • UML non fornisce alcuna soluzione. Quindi solitamente si ricorre ad una specifica testuale che viene allegata agli use case diagrams.



Interaction diagram e comportamento dinamico del sistema

  • Sono diagrammi che descrivono come gruppi di oggetti collaborano nel mostrare un certo comportamento.

  • Tipicamente rappresentano il comportamento di uno specifico use case

    • in termini di specifici oggetti e messaggi scambiati
  • Ci sono due tipi di interaction diagram:

    • Sequence diagram
    • Collaboration diagram


Sequence diagram

  • Mostra una interazione tra oggetti come sequenza temporale di azioni.

    • oggetti partecipanti
    • sequenze (temporali) di messaggi scambiati
    • non si vedono le associazioni tra oggetti


Sequence diagram: notazione

  • Oggetti



Esempio: sequence diagram



Notazione estesa: terminologia



Processi concorrenti e attivazioni



Notazione estesa: terminologia



Collaboration diagram

  • Collaboration: interazione tra parti di un sistema per un certo scopo

    • si isolano parti di sistema e si trascurano le interazioni non essenziali allo scopo
  • L’interazione è descritta in rapporto agli oggetti e alle relazioni che li legano.

  • Non c’è una dimensione precisa per il tempo

    • le sequenze temporali sono descrivibili numerando i messaggi in modo progressivo


Esempio di interazione



State diagram

  • Rappresentano il comportamento di una classe di oggetti, descrivendone i possibili stati e la reazione ad eventi esterni, in termini di cambiamenti di stato e/o azioni svolte.

  • I diagrammi di stato danno un'astrazione di stati, eventi e transizioni

  • Gli stati dei diversi oggetti evolvono concettualmente in parallelo (sincronizzati dagli eventi comuni).



Concetti fondamentali: stati

  • È l'insieme dei valori degli attributi e dei link posseduti da un oggetto in un certo istante

  • Ci interessa lo stato astratto

    • esempio: motore acceso/spento (non ci interessa il numero di giri/min.)
    • può corrispondere a diverse - anche infinite - combinazioni di valori degli attributi
  • Lo stato influenza il comportamento

    • L'oggetto reagisce in modo qualitativamente diverso agli eventi esterni, in funzione dello stato in cui si trova.
    • Esempio: prelievo da un conto corrente con saldo negativo


Concetti fondamentali: stati

  • Il comportamento quantitativo è influenzato dal valore degli attributi, dei link e dei parametri delle operazioni

  • Uno stato perdura nel tempo

    • finché un evento non fa cambiare stato all’oggetto (es. un versamento fa passare un conto corrente da saldo negativo a saldo positivo)


Concetti fondamentali: eventi

  • Evento = stimolo esterno

    • E' istantaneo
      • il tempo è un attributo implicito
    • Se due eventi sono legati da relazione causa/effetto sono ordinati nel tempo.
    • Può causare nell'oggetto destinatario un cambio di valore, di stato o la produzione di ulteriori eventi.
    • Si intende che un evento ha una individualità ben definita
      • raggruppabili in classi di eventi (con attributi caratterizzanti)
    • La risposta ad uno stimolo dipende dallo stato, e può implicare una transizione di stato
      • esempio del versamento su CC


Diagramma degli stati: Esempio



Stati iniziali e finali

  • Alcuni oggetti hanno diagrammi degli stati ciclici, altri possono avere stati iniziali e/o finali.



Condizioni

  • Sono funzioni booleane sui valori degli oggetti.

  • Sono valide in un intervallo di tempo

  • Sono utili come guardie delle transizioni di stato (non basta l'evento, deve essere verificata la condizione).



Operazioni

  • Durante la loro vita gli oggetti eseguono operazioni.

    • associate allo stato (attività)
    • associate alle alle transizioni (azioni)
  • Le attività hanno una durata

    • continue
    • sequenziali
  • Le azioni sono istantanee



Operazioni

  • Azioni

    • Sono operazioni che hanno durata istantanea (rispetto alla granularità del tempo). Tipicamente produzione di eventi.
    • Sono associate alle transizioni di stato oppure all'ingresso o all'uscita da uno stato.
  • Attività

    • Sono operazioni con durata significativa.
    • Sono associate ad uno stato
      • Continue o sequenziali
  • Transizioni automatiche

    • Se uno stato ha una attività associata e una freccia senza eventi esce da questo, la freccia indica la transizione svolta automaticamente al completamento della attività.


Notazione generale



Azioni consistenti nell'invio di eventi

  • Molto spesso le azioni consistono nell'inviare un evento ad un altro oggetto.

    • esempio: transazione tra stati di un oggetto Window


Invio di eventi

  • Gli eventi possono avere attributi

  • Il destinatario può essere unico o un intero set di oggetti.

  • Tutti gli oggetti riceventi che riconoscono l'evento possono accettarlo e reagire in parallelo.

  • Attenzione alle corse critiche



Invio di eventi: notazione grafica



Problemi dei diagrammi a stati piatti

  • Diventano poco espressivi e troppo ingarbugliati al crescere delle dimensioni del problema.

    • Ad esempio, il numero di collegamenti possibili tra stati è quadratico nel numero di stati.
  • Soluzione: diagrammi strutturati

    • la strutturazione favorisce la descrizione sintetica di sistemi complessi
      • L'attività corrispondente ad uno stato può essere espansa in un diagramma a stati di più basso livello, dove ogni stato rappresenta una fase dell'attività.
      • Generalizzazione (specializzazione delle attività, gerarchie di ereditarietà, ...)
    • Aggregazione (stati concorrenti)


Diagrammi a stati strutturati

  • Uno stato strutturato equivale ad una scomposizione OR degli stati: l'oggetto si trova, all'interno di uno stato più generale, in un qualunque sotto-stato.

  • I sottostati ereditano le transizioni dei loro superstati (a meno di overriding)



Diagramma di stato: esempio (1)



Sottostati concorrenti



Concorrenza di due attività



Activity Graph e Activity Diagram

  • Sono dei casi speciali di macchine a stati, in cui

    • tutti gli stati (o quasi) contengono un’azione o una attività
    • tutte le transizioni (o quasi) sono causate dal completamento delle azioni/attività negli stati
  • Un activity graph è associato ad una classe, o all'implementazione di un’operazione, o ad uno use case.

  • Un Activity Diagram è un diagramma contenente un activity graph

  • Lo scopo deglio activity graph è di evidenziare l’evoluzione guidata dall’elaborazione interna, in contrapposizione agli eventi esterni (meglio trattati negli state diagram).



Un Activity Graph



Swimlanes (corsie)



Implementation diagram



Component diagram

  • Mostra le dipendenze tra componenti software

    • sorgenti, binari, eseguibili
    • esistenti a compile-time, a link-time, a run-time
  • I moduli sono rappresentati come tipi di componenti

    • le istanze si vedono nei deployment diagram
  • I diversi componenti offrono e usano interfacce specifiche

    • Primo passo verso Component Programming


Componenti



Component diagram

  • Un’architettura a “layer”:



Component diagram con icone ad-hoc



Deployment diagram

  • Mostrano la configurazione a run-time degli elementi attivi a run-time (e dei componenti, processi e oggetti che vi “vivono”).

    • processi e/o processori
  • Istanze di componenti software rappresentano le manifestazioni run-time delle unità di codice.

  • Componenti che non esistono a run-time non appaiono in questi diagrammi.

  • I legami fra processi possono essere

    • Connettori passivi
      • Generici
      • Specializzati con opportuni commenti
    • Connettori attivi
      • Modellati con opportuni processi


Associazioni

  • Rappresentano le connessioni fisiche tra i nodi



Nodi e componenti

  • Un grafo

    • nodi = risorsa computazionale
      • possono contenere istanze di componenti e/o oggetti
    • archi = comunicazione
      • tipicamente indicano una relazione di utilizzo


Nodi e componenti



Dove trovare altre informazioni

  • Esistono diverse collezioni di link a siti web contenenti informazioni su strumenti e prodotti vari.

  • www.cetus-links.org

    • una collezione estesa di riferimenti a siti sull’analisi e progettazione OO (non necessariamente UML).


Bibliografia: Libri

  • Terry Quatrani, Visual Modeling with Rational Rose and UML, Addison-Wesley

  • Unified Modeling Language User Guide

  • Unified Modeling Language Reference Manual

  • H. Eriksson, M. Penker, UML Toolkit, J. Wiley

  • M. Fowler, UML distilled, Addison-Wesley



Bibliografia: URL

  • Rational/IBM

    • http://www-306.ibm.com/software/rational/
  • Object Management Group

    • http://www.omg.org






©astratto.info 2017
invia messaggio

    Pagina principale