Unified Modeling Language

Alberto Ferrari - uniPr

UML

  • UML è un linguaggio di progettazione
  • Fornisce una serie di diagrammi per rappresentare ogni tipo di modellazione
  • Alcuni ambienti di programmazione sono in grado di convertire diagrammi UML in codice e viceversa (es plugin Papyrus per Eclipse)

Diagrammi UML

  • casi d’uso (use case)
    • descrive le funzionalità di un software in termini di utenti (attori) e di azioni
  • classi (class)
    • descrive le classi con i relativi attributi e metodi (utilizzato in progettazione ad oggetti)
  • oggetti (object)
    • rappresenta lo stato del software in un istante della sua esecuzione
  • sequenza (sequence)
  • collaborazione (collaboration)
  • stato (statechart)
  • attività (activity)
  • componenti (component)
  • distribuzione (deployment)

Definizione dei requisiti

  • Requisiti:
    • insieme delle funzionalità che il sistema deve rendere disponibili agli utenti (non necessariamente persone)
  • Si definisce
    • “cosa” fa il sistema
    • non “come” lo fa
  • L’insieme dei requisiti descrive il comportamento esterno del sistema (black box)
  • In UML -> diagramma dei casi d’uso
    • attori
    • casi d’uso

Diagramma dei casi d'uso

www.draw.io

Tipi di requisiti

  • Funzionali
    • descrivono le funzionalità che il sistema rende disponibili all’utente (normalmente interazione utente-sistema)
    • sono gli unici che compaiono nei diagramma dei casi d’uso
  • Non funzionali
    • descrivono caratteristiche del sistema (per esempio prestazionali)
  • Tecnologici
    • descrivono aspetti tecnologici (esempio tipo di linguaggio utilizzato)

Priorità dei requisiti

  • Must
    • indispensabile
  • Should
    • desiderabile
  • May
    • opzionale

Elmenti dei diagrammi dei casi d'uso

  • Attori
    • Entità che non fanno parte del sistema ma interagiscono con esso
    • Rappresentati da icone con la denominazione del ruolo
  • Casi d’uso
    • Ovali con all’interno la descrizione (verbo/complemento)
  • Linee
    • di collegamento fra attori e casi d’uso
    • è possibile attribuire un nome per chiarire il ruolo che svolge l’attore

Relazione fra casi d'uso

  • Inclusione (linea tratteggiata)<>
    • Il caso d’uso puntato è necessariamente compreso nel caso d’uso da cui parte la freccia
  • Estensione (linea tratteggiata)<>
    • Il caso d’uso puntato è facoltativamente compreso nel caso d’uso da cui parte la freccia
  • Generalizzazione (linea continua)
    • Il caso d’uso da cui parte la freccia è un caso particolare di quello puntato

Esempio di relazione fra casi d'uso

Indicazioni

  • Individuare gli attori
    • chi usa il sistema?
    • chi ottiene informazioni dal sistema?
    • chi fornisce informazioni al sistema?
    • quali altri sistemi interagiscono con questo?
  • Individuare i casi d’uso
    • per quale scopo gli attori usano il sistema?
    • quali funzioni sono richieste?
    • quali informazioni sono elaborate dal sistema?

Specifica dei casi d'uso

  • Nome del Caso d’Uso
  • Descrizione
  • Precondizioni
  • condizioni che devono essere verificate prima di eseguire il caso d’uso
  • Postcondizioni
  • stato in cui il caso d’uso lascia il sistema

Object-oriented analysis and design

Class Diagram

Diagramma delle classi

  • Rappresenta le classi che compongono il sistema, cioè le collezioni di oggetti, ciascuno con il proprio stato e comportamento (attributi ed operazioni)
  • Specifica, mediante associazioni, le relazioni fra le classi.

Associazioni e relazioni in UML

Dipendenza e associazione

  • Dipendenza: un metodo di una classe ha come argomento, valore di ritorno o var locale un’altra classe (con cui non è associata)
  • Associazione: una classe ha come campo uno o più oggetti di un'altra classe
  • Ognuno dei lati
    • Ha un nome
    • Ha una cardinalità
    • Può o no essere navigabile
  • Un’associazione equivale a codice
    • Solo i lati navigabili implementano l’associazione
    • Memorizzazione in array o altra collezione (se cardinalità > 1)
    • Controllare il vincolo sulla cardinalità
  • Dipendenze e associazioni limitano la riusabilità perchè accoppiano le classi

Contenimento

  • Associazione che esprime un contenimento fisico, o in generale un legame di tipo has-a
  • Può essere composizione o aggregazione
    • Composizione: ciclo di vita dell'oggetto contenuto determinato dal contenitore (legame whole-part, owns-a)
    • Aggregazione: oggetto contenuto non rigidamente legato al contenitore
  • Spesso nel codice non è chiara la differenza tra contenimento ed un più generica associazione

Composizione

  • Idealmente, un oggetto (creato e testato) rappresenta una unità di codice, che altri oggetti possono usare
    • Il riuso in progetti diversi non è semplice da ottenere…
  • Inserire un oggetto (member object) dentro un’altro
    • Il nuovo oggetto può contenere un certo numero di oggetti di tipo diverso, per realizzare le funzionalità desiderate
    • Relazione whole-part o owns-a
  • Grado elevato di flessibilità
    • Gli oggetti membri sono di solito nascosti
    • Inaccessibili ai programmatori che usano l’oggetto
    • Possono essere cambiati senza disturbare il codice esterno

Associazioni e attributi

  • Associazioni e attributi del modello generano codice
  • Le associazioni vengono usate per collegare tra loro le classi del modello
  • Gli attributi sono tipi di base (o primitivi)
    • Come int, float o string
    • Classi di base, usate pervasivamente
    • Classi di altre librerie, non evidenziate nel modello

Classe derivata

  • Specializzazione: relazione is-a tra classe derivata e classe base
  • Principio di sostituibilità tra classi
    • È sempre possibile usare una classe derivata al posto di una classe base
  • La classe derivata
    • Eredita tutte le caratteristiche public della classe base
    • Non può accedere alle caratteristiche private della classe base
    • Può dichiarare nuove caratteristiche che non sono visibili dalle classi base (Eckel: is-like-a)
  • La classe base
    • Può definire delle caratteristiche protected a cui solo lei e le classi derivate possono accedere

Classe astratta

  • Contiene metodi che possono essere implementati solo dalle sue classi derivate
    • Informazioni non sufficienti nella classe base
    • Meccanismi specifici per implementare un metodo
    • …
  • Una classe astratta non può essere istanziata

Figure geometriche

Ereditarità e riusabilità

  • Strutture dati ed algoritmi possono essere implementati in funzione della classe Shape
    • Anzichè di una specifica classe derivata, come Rectangle
    • Ad esempio, l'ordinamento può sfruttare il fatto che tutte le figure hanno un area
  • Massimizzazione di riuso e flessibilità
    • Dipendenza dalla classe più alta nella gerarchia...
    • Che offre le caratteristiche richieste

A cosa serve l’ereditarità?

  • Due utilizzi principali
    • Modellare il problema (o la soluzione), molto importante nella fase di analisi
    • Massimizzare il riuso, molto importante nella fase di progettazione
  • I due utilizzi sono legati perchè la prima bozza di un progetto è il modello che analizza il dominio del problema (o della soluzione)
  • Eckel: ereditarietà o composizione?
    • “Do I need to upcast?”

Ereditarietà multipla

  • Un quadrato è contemporaneamente…
    • Un rettangolo
    • Un poligono regolare
  • La classe Square dovrebbe estendere sia RegularPolygon che Rectangle
    • Quale stato usare?
    • Quale metodi eseguire?
  • A volte ereditarietà multipla non ammessa o non conveniente
    • No ambiguità, no “diamond problem”

Interfaccia

  • Interfaccia di un oggetto: descrizione dei suoi metodi pubblici
    • Modo che ha per interagire con il mondo
    • Servizi che offre agli altri oggetti
  • I corpi dei metodi, cioè come i servizi vengono implementati, non sono parte dell’interfaccia
    • L’interfaccia indica cosa un oggetto sa fare e non come lo fa
  • Interfaccia di un rettangolo
    • float area()
    • float perimeter()

Classe astratta pura

  • Una interfaccia è una classe astratta pura
    • Tutti i metodi sono astratti
    • Implementazione in classe concreta
    • Libertà su come memorizzare stato ed implementare metodi
  • Usando le interfacce
    • Migliore pulizia del modello ed aderenza alla realtà modellata
    • Possibilità di migliorare la riusabilità

Implementazioni di Shape

Sequence Diagram

Diagramma di sequenza

Alberto Ferrari
Universita' degli Studi di Parma