Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D La Corte in Rete
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Porfirio Tramontana » 5.Modellazione con UML


La modellazione del sistema

Con le tecniche di analisi viste finora si è in grado:

  • Di valutare la fattibilità della realizzazione di un sistema software;
  • Di specificare i requisiti del sistema software da realizzare;
    • Da un punto di vista funzionale
    • Dal punto di vista dei suoi utenti (analisi dei casi d’uso).

Per poter approcciare il problema della progettazione del sistema software è necessario produrre un modello preciso del dominio dei problemi le cui soluzioni il sistema software andrà a supportare.

Modellazione del dominio del problema

Diversi tipi di modelli possono descrivere il dominio del problema. Tali modelli sono detti modelli di dominio oppure modelli concettuali o, talvolta, modelli di business.
Attenzione: non bisogna confondere i modelli di dominio, che descrivono il problema, dai modelli di progetto, che descrivono la soluzione.

Si distingue tra:

  • Modelli statici, che descrivono gli elementi del dominio del problema e le relazioni tra loro;
  • Modelli dinamici, che descrivono i comportamenti riconoscibili nel dominio del problema.

Modellazione di sistema

Per descrivere tali modelli si utilizzano linguaggi di modellazione.
In passato, diversi linguaggi di modellazione erano utilizzati a supporto delle metodologie che si applicavano nelle varie fasi del processo di sviluppo del software.
Ad esempio:

  • Diagrammi di flusso
  • Data Flow Diagrams

Negli ultimi anni il linguaggio UML si sta affermando come linguaggio unificato che possa essere utilizzato in tutte le attività di modellazione, nonchè in molte altre attività del ciclo di vita del software.

Che cosa è UML?

UML (Unified Modelling Language) nasce come linguaggio grafico standard per modellare software object oriented. Tra la fine degli anni ‘80 e gli inizi degli anni ‘90 fecero la comparsa i primi processi di sviluppo object-oriented. La proliferazione di metodi e notazioni diverse creavano confusione.

Due importanti metodologi, Rumbaugh e Booch, decisero di fondere i loro approcci nel 1994.
Cominciarono a lavorare insieme alla Rational Software Corporation.

Nel 1995, un altro metodologo, Jacobson, si unì al gruppo. Il suo lavoro si concentrava sugli use cases.

Nel 1997 l’Object Management Group (OMG) cominciò il processo di standardizzazione di UML.
Nel Luglio 2005 è stata rilasciata la prima release di UML 2.

Su www.omg.org è possibile leggere la storia di tutte le specifiche UML.
Una specifica UML in pratica definisce un metamodello che indica secondo quali regole sia possibile costruire modelli UML.

Uso di UML

UML può essere usato:

  • Come abbozzo, cioè per tracciare un modello di massima di un sistema da realizzare;
  • Come progetto, cioè per realizzare un modello completo della soluzione architetturale del sistema;
  • Come linguaggio di programmazione in grado di modellare in maniera completa e precisa il sistema software
    • L’approccio MDA (Model Driven Architectures) esplora la possibilità di usare UML come linguaggio di programmazione
      • Questa ultima possibilità è al momento soprattutto un obiettivo cui mirare in futuro. Si vorrebbe, in pratica, stabilire una sintassi e una semantica precisi per UML, che portino alla generazione automatica di codice sorgente rappresentativo del modello tracciato.

Regole di UML

UML è dotato sia di regole prescrittive che di regole descrittive:

  • Le regole prescrittive sono regole stabilite da organismi standardizzanti che caratterizzano precisamente lessico, sintassi e semantica;
  • Le regole descrittive, invece, hanno come scopo solo la comunicazione del significato dei diagrammi, con estensioni, libere ma intuitive, delle regole base.

UML ha come scopo principale la descrizione efficace di situazioni reali, cosicchè le regole descrittive sono al momento predominanti.

Regola delle informazioni soppresse:

  • L’assenza di qualche informazione in un diagramma UML non significa, in generale, che tale informazione non esista o sia nulla, ma semplicemente che si tratti di un aspetto del problema non ancora trattato nella fase in cui è stato tracciato il diagramma (o che non si voglia palesare in tale diagramma per poi inserirlo in diagrammi ulteriori.

Tipi di Modelli in UML 2

UML 2 possiede 13 differenti tipi di diagrammi, appartenenti a tre categorie:

  1. Diagrammi Comportamentali, quali use-case diagrams, activity diagrams, state machine diagrams.
  2. Diagrammi di Interazione, per modellare interazioni fra entità del sistema, quali sequence diagrams e communication diagrams.
  3. Diagrammi Strutturali, che modellano l’organizzazione del sistema, quali class diagrams, package diagrams, e deployment diagrams.

Tali diagrammi rappresentano i deliverables di diverse fasi del ciclo di vita del software, tra cui attività di analisi dei requisiti e attività di progettazione, sia di alto che di basso livello.

I materiali di supporto della lezione

Ian Sommerville, Ingegneria del Software, capitoli 8 e 14.

Martin Fowler, UML Distilled, capitolo 1 (introduzione a UML).

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion

Fatal error: Call to undefined function federicaDebug() in /usr/local/apache/htdocs/html/footer.php on line 93