Con le tecniche di analisi viste finora si è in grado:
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.
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:
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:
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.
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.
UML può essere usato:
UML è dotato sia di regole prescrittive che di regole descrittive:
UML ha come scopo principale la descrizione efficace di situazioni reali, cosicchè le regole descrittive sono al momento predominanti.
Regola delle informazioni soppresse:
UML 2 possiede 13 differenti tipi di diagrammi, appartenenti a tre categorie:
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.
1. Introduzione
4. Casi d'uso
6. Class Diagram – parte prima
7. Class diagram – parte seconda
8. Class diagram – parte terza
9. Modellazione architetturale
10. Sequence Diagram
14. Progettazione Architetturale
15. Design Patterns – Parte prima
16. Design Patterns – Parte seconda
17. Progettazione dell'interfaccia utente
Ian Sommerville, Ingegneria del Software, capitoli 8 e 14.
Martin Fowler, UML Distilled, capitolo 1 (introduzione a UML).