IntroduzioneAllaGestioneDiUnProgettoSoftwareConUML

Introduzione alla Gestione di un
Progetto Software con UML
Matteo Gentile
gentile.matteo@gmail.com
https://it.linkedin.com/in/gentilematteo

Introduzione alla Gestione di un Progetto Software con UML
Agenda
• Introduzione al progetto informatico
• Il linguaggio UML
• Analisi e progettazione con UML
• Tools, riferimenti e risorse
2

Introduzione al progetto informatico – produzione SW
3
Idea
Algoritmi
Strutture
dati
Sorgente
Tradotta in
Cosa è la realizzazione del software?
Installazione
Compile

Introduzione al progetto informatico
La struttura di base del progetto software comprende
le seguenti fasi:
• Raccolta dei requisiti
• Analisi
• Progettazione
• Implementazione (sviluppo)
• Test
• Installazione (messa in produzione)
• Manutenzione (ordinaria ed evolutiva)
4

• L’obiettivo fondamentale per ottenere applicativi
è scrivere il codice sorgente del software che
comporta:
5
Definizione di cosa fare
Realizzazione (detailed design e coding)
Compilazione / Debugging
Generazione Applicazione
Pacchetizzazione / Installazione
Testing

• Ciclo di vita del SW - Iterativo
6
Idea/Requisiti
Inizio
Definizione
(Analisi)
Progettazione
Implementazione
Test /Accettazione
Avvio
Valutazione

• Ciclo di vita del SW - Waterfall
7
Definizione (Analisi)
Progettazione
Implementazione
Test /Accettazione
Avvio
Idea/
Requisiti

Metodologie vs Modelli
• UML non si occupa di definire la metodologia
adottata, ma di creare modelli per costruire sw e
comunicare il risultato
8

Requisito
Definizione Formale
• Un requisito è una proprietà o una qualità
che un prodotto software deve avere o soddisfare
per soddisfare un contratto, uno standard, una
specifica o altri documenti formali (IEEE 610.12-
1990, IEEE Standard Glossary of Software
Engineering Terminology ).
Definizione Breve
• Una proprietà o una qualità di un sistema
Alan Davis
– E’ una caratteristica osservabile dall’esterno di un
sistema.
9

Feature
• Mostra le soluzioni
tecniche ai requisiti
• Dal punto di vista utente è
una unità testabile di una
funzionalità
• Un requisito può essere
dettagliato da più feature
10

Task
• Il lavoro di una feature si
può spezzare in task per
dettagliare le singole
implementazione di azioni
• Task generalmente
coinvolgono una persona
• Task generalmente sono
stimati dal responsabile della
persona
11

Raccolta requisiti ed analisi
• Il progetto inizia con la fase di raccolta dei
requisiti, realizzata attraverso la cosiddetta
elicitazione dei requisiti (requirement elicitation).
Con questo termine, mutuato dalla psicologia, si
intende un insieme di diverse tecniche,
combinate fra loro, per riuscire ad “estrarre dalla
mente del cliente o committente le idee per
capire cosa il software oggetto del contratto
dovrà fare”.
12

Raccolta requisiti ed Analisi
Le tecniche di elicitazione più usate sono:
• le interviste, durante le quali si pongono alle
persone del cliente domande esplicite;
• l’osservazione, durante la quale si osservano “sul
campo” le funzioni svolte in cui il software dovrà
intervenire;
• il gruppo di lavoro (brainstorming).
• …
13
IIBA, A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide)

Analisi dei requisiti
• Serve per descrivere in modo formale e preciso i
requisiti che dovrà avere il sistema oggetto del
progetto.
14
Propagazione
errori

15

Obiettivo analisi
• Produrre una descrizione completa formalizzata,
con il giusto livello di dettaglio, di :
– tutto ciò che il sistema deve fare (requisiti
funzionali),
– dell’ambiente in cui dovrà operare (requisiti
non funzionali)
– dei vincoli che dovrà rispettare.
• A meno di Agile Methodologies (non ce ne
occupiamo)
16

Documenti di analisi
• I documenti di analisi, talvolta chiamati anche
documenti di specifica o semplicemente
specifiche, sono il prodotto risultante dalla fase di
analisi e devono contenere in modo chiaro le
informazioni sopra definite. La loro forma, i
linguaggi e le simbologie usate sono ovviamente
dipendenti dal tipo di processo di sviluppo
seguito.
• Una possibilità è usare alcuni diagrammi UML
17

Fase di progettazione
• La fase di progettazione deve produrre le istruzioni
operative per la realizzazione effettiva del progetto
informatico (implementazione). Le istruzioni devono avere il
giusto livello di dettaglio ed essere espresse in forma di
documenti strutturati.
• Risultato: la definizione dell’architettura del sistema
– i suoi componenti software
– le proprietà visibili esternamente di ciascuno di essi
(l’interfaccia dei componenti)
– le relazioni fra le parti.
• Per la progettazione si possono usare diagrammi gli UML
Activity Diagram (o BPMN …)
18

Un approccio visuale alla progettazione
• Chi progetta un qualsiasi tipo di costruzione o artefatto
utilizza sempre figure, schemi, diagrammi per svolgere la
propria attività: ingegneri, architetti, ma anche stilisti
utilizzano diagrammi e figure per visualizzare i propri
progetti.
• Anche i progettisti e gli analisti di sistemi informativi
utilizzano figure e diagrammi per visualizzare il risultato del
loro lavoro: il sistema software.
• Ciò avviene anche se il tipo di prodotto finale che risulta
dalla progettazione non è necessariamente visuale.
19

Vantaggi uso diagrammi
• Sia che si progetti un edificio sia che si progetti un sistema
software il progettista ha la necessità di rappresentare i
diversi aspetti del progetto, per fare ciò si utilizzano
diagrammi differenti, ognuno focalizzato su uno o più
aspetti.
• Durante le fasi di analisi e progettazione vengono generati
dei modelli che consentono di identificare e separare le
caratteristiche (utili al progetto) di un sistema reale.
• Il progettista dovrà quindi decidere quali caratteristiche
sono rilevanti per il sistema che sta costruendo, inserirle nel
modello e definire le relazioni tra gli elementi del modello.
20

Fase di implementazione e coding
• L’implementazione del software dovrebbe essere
fatta nel modo migliore possibile e quindi da
persone competenti come gli Ingegneri
dell’Informazione.
• Se in Ingegneria Civile faccio un bel progetto, ma
i pilastri non sono fabbricati bene, se i mattoni
non sono posati con accuratezza o se i materiali
impiegati sono di scarso pregio, verrà un edificio
di pessima qualità.
• E’ la fase principale e può seguire diverse
metodologie (waterfall, scrum, kanban , …)
21

Test e Delivery
Test
• Check del codice con Unit Testing o Automated
Tests (o approccio TDD)
• Verifica conformità a requisiti di analisi
• Test di performance
Delivery
• Sw per mercato pubblico  inizio distribuzione e
vendita
• Sw per un cliente  installazione e collaudo
22

Manutenzione
• Durante la vita operativa possono verificarsi
necessità di :
– Manutenzione ordinaria - interventi correttivi
(bugfix)
– Manutenzione evolutiva - aggiornamento
(upgrade tecnologico o aggiunta funzionalità /
adeguamento normativo), che prevede nuove
fasi di progettazione, implementazione e test.
23

Validazione dei Requisiti vs Verifica dei Requisiti
24
•Prodotto ha le
funzionalità corrette
Validazione
•Le funzionalità sono
fatte nel modo giusto
Verifica

Agenda
25

UML
• UML (Unified Modeling Language) è un
linguaggio standard di modellazione per
– Specificare
– Visualizzare
– Costruire
– Documentare
domini applicativi eterogenei
• Adatto maggiormente a progettare sistemi object
oriented e sistemi component-based.
26

UML
27
“Famiglia di notazioni grafiche che si basano su un
singolo meta-modello e servono a supportare la
descrizione e il progetto dei sistemi software”
Martin Fowler
Pensate su paradigma object oriented

Importanza di una buona notazione
Il matematico Whitehead, circa un secolo fa, osservava
– e in effetti incrementa il nostro “potere mentale”
28
“Liberando il cervello da tutto il lavoro non
necessario, una buona notazione ci lascia liberi di
concentrarci su problemi più avanzati”

Applicare UML
29
•Comprendere (non
documentare)
Scopo
Primario
•Discussione durante
la modellazione
Valore
Primario

UML
UML è un linguaggio pertanto costituito da sintassi
e semantica
• Sintassi (UML Notation Guide): regole
attraverso le quali gli elementi del linguaggio
(parole) sono assemblate in espressioni (frasi).
• Semantica (UML Semantics): regole attraverso
le quali alle espressioni sintattiche viene
assegnato un significato.
30

UML
31
• UML è uno standard
– Object Management Group (OMG)
• CORBA (Common Object Request Broker Architecture)
• BPMN (Business Process Modelling and Notation)
– Relativamente giovane: 1997
• Prima esistevano una miriade di linguaggi grafici di
modellazione, ognuno con le proprie regole
– Anni ’80 e ’90
– Perché?
• Il linguaggio naturale è troppo astratto e dispersivo
– È ambiguo e non formale
• I linguaggi di programmazione sono troppo concreti

UML – i tre “amigos”
• Grady Booch: Object Oriented Design – OOD
• Jim Rumbaugh: Object Modeling Technique -
OMT
• Ivar Jacobson: Object-Oriented Software
Engineering - OOSE
32

UML - origini
• Booch e Rumbaugh lavoravano alla Rational e nel
1994 Unified Object Notation v0.8
• Jacobson capo di Objectory che nel 1995 fu
acquistata dalla Rational e nel 1995 definì Unified
Modeling Language v0.9
• Booch e Rumbaugh e Jacobson crearono
consorzio “UML Partners” e redassero UML v1.0
• Microsoft, HP, Oracle, Rational ed altri crearono
consorzio “OMG”
33

UML - versioni
34
Version Release Date URL
2.4.1 August 2011 http://www.omg.org/spec/UML/2.4.1
2.4 March 2011 http://www.omg.org/spec/UML/2.4
2.3 May 2010 http://www.omg.org/spec/UML/2.3
2.2 February 2009 http://www.omg.org/spec/UML/2.2
2.1.2 November 2007 http://www.omg.org/spec/UML/2.1.2
2.1.1 August 2007 http://www.omg.org/spec/UML/2.1.1
Please note that version 2.1 was never released as a formal specification.
2.0 July 2005 http://www.omg.org/spec/UML/2.0
1.5
combines v1.4
and action
semantics
March 2003 http://www.omg.org/spec/UML/1.5
1.4 September 2001 http://www.omg.org/spec/UML/1.4
1.3 March 2000 http://www.omg.org/spec/UML/1.3
La 2.5 è in Beta 2

UML – ISO Release
35
ISO Release
Information
UML
Version
URL
This version (2.4.1) has
been formally published
by ISO as the 2012
edition standard:
ISO/IEC 19505-1 and
19505-2.
2.4.1
http://www.omg.org/spec/UML/ISO/19
505-1/PDF
505-2/PDF
This version (1.4.2) has
been formally published
by ISO as the 2005
edition standard:
ISO/IEC 19501
1.4.2
501/PDF

Qualità di un modello
• Accuratezza: deve descrivere il sistema
correttamente, completamente e senza
ambiguità;
• Consistenza: le diverse viste devono
completarsi vicendevolmente per formare un
insieme coerente
• Semplicità: deve poter essere compreso, senza
troppi problemi, da persone estranee al processo
di modellazione;
• Manutenibilità: la variazione dello stesso deve
essere la più semplice possibile.
36

Approccio ad UML
Steve Mellon e Martin Fowler prevedono tre modi
diversi di utilizzo:
• Abbozzo (sketch)
• Progetto (blueprint)
• Linguaggio di programmazione
37

UML come abbozzo (Sketch)
• Informale
• Documentazione, discussione e condivisione delle idee
• Basso rigore formale
• Selettività: focalizzazione solo su alcuni aspetti
dell’applicazione
• Bassa, se non nulla dipendenza dal tool di modellazione
38

UML come progetto (Blueprint)
• Alto rigore formale
• Completezza
• Forward e reverse engineering
• Forte dipendenza dal tool di modellazione
39

UML come linguaggio di programmazione
• Utilizzare diagrammi per generare codice
• Fortissima dipendenza dal tool di modellazione
40

Uso di UML
• Esiste UML “legale”?
– Non possiede regole prescrittive
• Definiscono cosa è legale e cosa non lo è
– Necessita di un ente ufficiale di controllo
– Precise regole descrittive
• … per imparare conviene partire dal suo utilizzo concreto …
– Il grado di dettaglio può variare
• Ogni elemento UML può essere soppresso, ottenendo
ancora un diagramma legale
• E’ la sensibilità dell’autore a determinare le informazioni da
esporre nel diagramma
41

Diagrammi UML
42
Come è composto il sistema Come interagisce il sistema

Diagrammi UML
43
UML 1.x
• Class diagram
• Object diagram
• Deployment diagram
• Component diagram
• Package diagram
• Activity diagram
• Use case diagram
• Sequence diagram
• Communication diagram
• State Chart diagram
UML 2.x
• Class diagram
• Object diagram
• Deployment diagram
• Component diagram
• Package diagram
• Activity diagram
• Use case diagram
• Sequence diagram
• Collaboration diagram
• State Machine diagram
• Interaction Overview diagram
• Composite Structure
• Timing diagram

Structural Modeling
• Individuare e modellare gli elementi da mettere insieme per
costruire il software necessario per risolvere il problema in
esame
• E’ la parte “statica”
• Diagrammi:
– Class (vocabolario delle cose che costruiamo)
– Component (organizzazione logica delle parti del sistema)
– Package (organizzazione fisica delle parti del sistema)
– Deployment (mappatura delle componenti del sistema con
quello che viene rilasciato)
– …
44

Behavioral Modeling
• Orientato alle funzionalità del sistema (processi, interazioni,
azioni)
• E’ la parte “dinamica”
• Diagrammi
– Use Case (funzionalità sistema e attori)
– Sequence (sequenza temporale delle operazioni)
– State (stati degli oggetti e loro cambiamenti)
– Activity (flowcharts, funzionalità)
– …
45

Ogni fase ha il suo diagramma
46
Analisi
Requisiti
(no OO)
Analisi
(OOA)
Progettazione
(OOD)
Implementaz
ione (OOP)
• Use Case Diagram
• Activity Diagram
• Package Diagram
• Class Diagram
• Object Diagram
• Sequence Diagram
• Communication Diagram
• Class Diagram
• Sequence Diagram
• Communication Diagram

Object Oriented Phases
47

UML descrive un sistema con tre modelli
• Modello funzionale (punto di vista utente,
comportamento visto da fuori)  Analisi dei
requisiti  Use Case Diagram
• Modello ad oggetti (struttura sistema)  Analisi
del dominio  Class Diagram, Object Diagram,
Deployment Diagram
• Modello dinamico (comportamento oggetti del
sistema)  Sequence Diagram, Activity Diagram,
Statechart Diagram
48

Esempi di uso
• Use Case Diagram: per capire nei dettagli “cosa” il sistema deve
fare
• Activity/Statechart Diagram: per definire i processi
fondamentali, ovvero mettere in ordine cronologico i casi d’uso
definiti dagli Use Case Diagram
• Class/Object Diagram: per definire le entità fondamentali
coinvolte nel funzionamento del sistema
• Communication (Collaboration) Diagram: per definire le
interazioni fra le entità fondamentali
• Sequence Diagram: per definire la sequenza temporale delle
interazioni fra entità
• Component Diagram: per definire nei dettagli quali parti
compongono il sistema/prodotto software finito e le loro relazioni
• Deployment Diagram: per definire dove le varie parti di un
programma devono essere poste in un’architettura distribuita (es.
client-server)
49

Use Case Diagram
50

Use Case Diagram
51
Business
Analyst
Product
Owner
System
Architect
Software
Engineers
Quali
funzionalità
e attori
Quali
funzionalità e
attori (più
tecnico)
Valida Use
Case vs
Architettura
Hanno foto del
sistema e
funzionalità
(riuso)
Quality
Assurance
Creano test
case

Use Case
52
• Tecniche per individuare requisiti
funzionali
• Descrive cosa fa il sistema per
raggiungere obiettivo utente
• Descrive le funzionalità necessarie a
raggiungere requisito
• Indipendente dall’implementazione
• Tratta il sistema come una black-box
(cosa espone, non come sono fatte
le cose !)
• Livello di dettaglio può dipendere
dallo stato di avanzamento o dalle
necessità espositive

Requisiti “testuali”
• Descrizione testuale
• Principalmente usato
quando Use Case non ha
senso come formato
descrittivo
– Requisiti non chiari
– Requisiti non funzionali
53
Requisiti  sempre espressi come Use Case quando possibile
• Aiutano a capire meglio i requisiti
• Aiutano sviluppatori a capire cosa implementare

Use Cases vs User Stories
• In generale, per le interviste a utente spesso si usano gli Use
Case, poi i requisiti posso renderli come sequenza di epiche e
quindi come sequenza di User Story.
http://www.batimes.com/articles/user-stories-and-use-cases-dont-use-both.html
55
Solution Requirements Stakeholder Requirements
International Institute of Business Analysis - BABOK® Guide v3

Use Cases vs User Stories
• Nel Waterfall troveremo spesso solo Use Case
(sono una vista complessiva delle iterazioni
utenti/sistema, che includono i dati, flussi
alternativi, eccezioni, regole di business, …)
• Nell’Agile spesso useremo solo User Stories
(richiedono scenario e criteri di accettazione,
sono molto orientate all’utente, se mancano
informazioni possono essere aggiunte in sprint
successivi o si può cambiare la priorità, …)
56

Use Cases nel processo di analisi
57
http://www.iiba.org/Learning-Development/Vendor-Showcase/2012/Use-Case-and-User-Stories.aspx

Scenari
• Sequenza di passi che descrivono interazioni
– Attori (utenti) e il sistema
• Rappresentazione di una possibilità
– Scenari alternativi
• Esempio: la carta di credito non è accettata, il cliente è
abituale e il suo profilo è già presente nel sistema, …
• Tutti gli scenari (principale e alternativo,
Extensions e Exceptions) condividono uno scopo
– Esempio: l’acquisto di almeno un prodotto
58

Attori
• Ruolo dell’ utente nell’interazione con il sistema
– Utente: persona, altro sistema esterno
– Utente “fisico”  più ruoli (attori)
– Più utente  medesimo ruolo (attore)
• Svolgono il caso d’uso per raggiungere l’obiettivo
– Stesso attore  più casi d’uso
– Un caso d’uso  più attori
• Buon mezzo di individuazione dei casi d’uso
1. Individuare la lista degli attori
2. Comprendere i loro obiettivi e come interagiscono con il
sistema (quale ruolo a quale funzionalità)
• Nessun dettaglio implementativo sui modi di interazione!
59

Cosa sono gli Use Case
• Informale
– Un caso d’uso è una situazione nella quale il sistema viene
utilizzato per soddisfare uno o più bisogni dell’utente.
60
Un caso d’uso è un insieme di scenari (sequenze di
azioni) che hanno in comune uno scopo finale
(obiettivo) per un utente (attore).

A cosa servono
Nelle fasi iniziali della progettazione
• Chiariscono cosa dovrà fare il sistema
• Stabiliscono una base comune per la discussione con il
committente
• Fine  individuare ed analizzare i requisisti del sistema
A regime
• Guidano l’intero processo di sviluppo
• Rappresentano il punto di partenza per la progettazione del
sistema (definizione dell’architettura, creazione dei modelli
di analisi e design, implementazione del codice)
• Costituiscono il riferimento primario per dei test per la
verifica di quanto prodotto
61

Da cosa sono composti
La Documentazione
• Descrive, in modo testuale, il Caso d’Uso
• Costituisce l’elemento centrale di comunicazione tra tutte le
parti in causa
– Committente, Management, Gruppo di progetto
• Guida la progettazione e la definizione dei Test Case
I Diagrammi
• Ruolo complementare ma secondario
• Forniscono una “mappa visuale”, molto sintetica, delle
modalità di uso del sistema
62

Casi d’uso - testuali
• Sono puro testo
63
Caso d’uso: UC1 - Registrazione
Attore primario: Utente
Precondizioni: L’utente non è ancora autenticato presso il sistema
Postcondizioni: L’utente possiede un’account presso il sistema,
contraddistinto da una username e da una password
Scenario principale:
1. L’utente accede al sistema
2. L’utente seleziona la funzionalità "Registrati"
3. L’utente inserisce una username univoca nel sistema
4. L’utente inserisce una password che rispetta i vincoli imposti
Estensioni:
a. Nel caso in cui l’utente inserisca una username già censita a sistema:
1. L’utente non viene registrato presso il sistema
2. Viene visualizzato un errore esplicativo
3. Viene fornita all’utente la possibilità di scegliere un’altra password

Casi d’uso - testuali
Il valore aggiunto è nel contenuto testuale
• Nome/Identificatore
• Scenario principale
• Scenari alternativi
– D’eccezione o errore
• Pre-condizioni
• Effetti / Garanzia (post-condizioni)
• Trigger
– Evento scatenante del caso d’uso
• Attori principali
• Attori secondari
64

Granularità
• Soddisfa lo scopo di un attore (fare un ordine, …)
– Più piccolo di un Business Process
• Non fornisce dettagli significativi, non individua le
funzionalità del sistema
– Più grande di una singola operazione su un componente
• Dettaglio eccessivo allontana il focus dall’obiettivo
65

Diagramma dei casi d’uso
• Mette in evidenza attori e servizi del sistema (come lo si
usa, non come è fatto)
• Grafo i cui nodi sono
– Attori (esseri umani, sistemi HW o SW, organizzazioni, …)
– Use case
• Archi del grafo rappresentano
– La comunicazione tra gli attori e gli use case
– I legami tra gli use case
• Relazione di estensione (specializzazione)
• Relazione di inclusione
• Relazione di generalizzazione
• Il diagramma individua i confini del sistema nello scenario
66

Esempio
67
attore
soggetto
caso d’uso
generalizzazione

Esempio Website Administration
• Requisiti di sicurezza per i siti web richiedono la separazione
delle interfacce amministrative dalle funzionalità degli user
comuni (raccomandato da ISO/IEC 17799:2005 ).
68
• Sistema web ha due
attori che usano le
interfacce amministrative,
i Website Admin e gli
operatori di Help Desk
(che usano un
sottoinsieme delle viste
amministrative)

Associazione tra attori
• Unica ammessa è estensione - specializzazione (casi d’uso
ereditati)
69
• Non è ammessa una associazione
di comunicazione tra i casi d’uso
(un caso d’uso descrive un utilizzo
completo del sistema)
• Non è ammessa la suddivisione di
una funzionalità completa in
casi d’uso distinti

Relazioni
70

Esempio di relazioni tra casi d’uso
71
Inclusione
Estensione
Specializzazione
Associazione

Esempio e-shop
72

Use Case Diagram – Livello di dettaglio
73
Manager
Developer
User

Consigli
• Le buone pratiche prevedono di usare per un
caso d’uso un sostantivo descrivente una macro-
azione “riassumente” il caso d’uso, come negli
esempi riportati, oppure direttamente un verbo
all’infinito, relativo alla macro azione compiuta
(ad esempio, “acquisto prodotto” o “acquistare
prodotto”).
74

Activity Diagram
75

Activity Diagram
76
Business
Analyst
Product
Owner
System
Architect
Software
Engineers
Usa
modello
per capire
mondo
reale
Assicura
comunicazione
chiara
business-
technical
teams
Associa
Business e
Technical
Requirements
Aiuta a capire
classi e
operazioni da
implementare

Activity Diagram
• Rappresenta sistemi di Workflow
• Meno “potenti” di BPMN (ma più semplici), ma più “potenti”
dei Flow Chart
• Facilmente comprensibili da “business people” e
“technological people”
• Un processo è formato da sottoprocessi o fasi, formate da
attività, a loro volta formate da azioni od operazioni
• Evidenzia le componenti del processo o dell’attività sotto
forma di successione logico-temporale di azioni,
eventualmente riportando entità usate o modificate nelle
azioni stesse, ma sempre da un punto di vista di
successione di azioni. Le azioni sono viste in primo piano
come componenti del processo, senza evidenziare chi le
compie o come vengono compiute.
77

Activity Diagram e Use Case Diagram
• A livello macroscopico gli Activity Diagram
possono individuare i processi e la scomposizione
delle singole attività può dare origine a insiemi di
Use Case.
• A livello più dettagliato invece si passa da uno
Use Case Diagram al corrispondente Activity per
mettere in evidenza la successione cronologica
delle attività corrispondenti ai singoli casi d’uso.
78

Elementi Base
79

Swimlanes
• Sono regioni (aperte e di lunghezza infinita) che
rappresentano l’attore responsabile degli action state che
contiene
80
Oggetti (Entità)
Attività
Swimlanes
Attori
Inizio
Fine

Flussi degli oggetti
• Le linee tratteggiate mostrano
l’utilizzo di specifici oggetti
nelle activity.
• La linea che parte da una
action indica l’oggetto in essa
utilizzato.
• La linea che parte da un
oggetto e va verso un’azione
indica che quell’oggetto è
ricevuto in input dalla activity.
81

Branch
• Rappresenta la selezione di una fra più transizioni sulla
base di una condizione di controllo
• Ha un solo punto di ingresso e molti di output
• Solo un cammino di uscita può essere preso
• Può essere usato come un “if then else”
82

Fork e Join
• Rappresentano l’evoluzione
parallela del sistema
• Ad una fork l’esecuzione prosegue
parallelamente su due o più flussi
figli
• Ad una join i flussi figli si
ricongiungono al flusso padre
• L’esecuzione del flusso padre
riprende solo quando l’ultimo dei
flussi figli ha terminato
• Fork ha un solo ingresso e più
uscite
• Join più ingressi ed una sola uscita
83
Fork
JoinMerge

Esempio – Ordine on line
84

Esempio emissione prestito
85

Class Diagram
86

Class Diagram
87
Business
Analyst
Product
Owner
System
Architect
Software
Engineers
Aiutano a
definire
vocabolario
“Consumer”,
intermediario
tra tecnici e PO
Creatore,
conosce
sistema
“Consumer”,
implementa C.D.

Class Diagram
• Identificare oggetti del dominio (osservando
mondo reale)
• Identificare i loro attributi e le operazioni
• Modellare tipi - eventualmente Value Types o
Enumerations, o Variable list (es: valori letti da
tabella decodifica su DB)
• Identificare le associazioni (relazioni)
• Identificare attributi/operazioni mandatorie
(molteplicità)
• Identificare eventuali business rules (validazione)
88
https://www.capgemini.com/blog/capping-it-off/2011/05/modeling-your-domain-models-in-uml

Class diagram - Oggetti
89
Nome Classe -
obbligatoria
Stereotype (interface,
entity, enumeration,
message, business
class, …)
Attributes
Operations
Responsibilities
Properties ,
optional
• Descrizione del tipo degli oggetti che fa parte di un sistema
e delle relazioni statiche fra i tipi degli oggetti.
• Oggetto = NomeClasse + Attributi (stato) + Operazioni
(comportamento)

Visibilità
90

Attributi (Proprietà)
• Membri di classe
• Modella una proprietà della classe ed è valido per
tutte le istanze
• Proprietà aggiuntive
• Se ordered: array, vettori, liste, …
• Se unordered: insiemi
• Convenzioni dei gruppi di programmazione
• Esempio: getter e setter per ogni attributo
91
Visibilità nome : tipo [molteplicità] = default {proprietà aggiuntive}
+ myStringArrayVar : string [1..1] = “” {array}
[0..1] , [1..1], …

Attributi in classi e istanze (oggetti)
92
Gli attributi di una classe determinano gli attributi delle sue
istanze (oggetti)
Regole importanti
• Se una classe Libro ha un attributo Titolo di tipo stringa,
ogni oggetto che è istanza di Libro ha l’attributo Titolo, con
un valore associato di tipo stringa
• Un oggetto X non può avere un valore per un attributo che
non è definito nella classe di cui X è istanza
Sottolineato con :

Importanza identificativo
• Oggetti con identificativi diversi sono distinti (anche se
stessi valori di attributi)
• Due oggetti devono avere identificativi diversi
• Un oggetto ha vita propria
93

Operazioni
• Le azioni che la classe “sa eseguire”
– Aspetto comportamentale
– Servizio che può essere richiesto ad ogni istanza della classe
• Direzione: in, out, inout (default in)
• Visibilità: + pubblica, - privata, # protetta , ~ package
– Query
– Modificatori
– Operazione ≠ metodo
• Concetti differenti in presenza di polimorfismo
94
Visibilità nome (lista-parametri) : tipo-ritorno {proprietà aggiuntive}
Lista-parametri := direzione nome : tipo = default
#Operation(i: int, s: bool): bool

Classe Astratta
• E’ una classe che non ha una concreta
implementazione ma ha solo la dichiarazione
delle operazioni
• Non può essere istanziata, ma può avere
costruttori.
• Può contenere sia dei metodi astratti (statici e di
istanza) sia dei metodi concreti
• Se un metodo è definito astratto, anche la classe
deve essere astratta,
• Se nessun metodo è astratto la classe può
comunque essere astratta.
95

Classe Astratta
• Il nome della classe astratta è in corsivo
• E’ possibile inserire il costruttore (non astratto)
• I metodi statici sono sottolineati
• Il metodi astratti sono in corsivo
• E’ possibile indicare metodi “concreti”
96

Classe Astratta
97

Interfacce
Una interfaccia (“interface”) ha una struttura simile a una
classe, ma può contenere solo:
• costanti
• metodi d'istanza astratti
• metodi e proprietà “public”
quindi non può contenere:
– né costruttori
– né variabili statiche
– né variabili di istanza
– né metodi statici
– metodi e proprietà diversi da “public”
98
Occhio al linguaggio !
Occhio al linguaggio !

Interfacce
Possiamo rappresentare lo
scenario di un’interfaccia in 3
modi diversi:
1) Uguale alla classe ma con indicato
lo stereotipo <<interface>>
2) Con una icona a forma di pallina
(lollipop -> “leccalecca”)
3) Con una icona a forma di pallina
agganciata da una icona a forma di
semicerchio (socket -> “presa”)
introdotta con UML 2
99
1
2
3
Incapsulamento  private List list = new ArrayList();
public class ArrayList implements List {

Interfacce
100
IPagamento

Enumerations
• Sono liste fisse di valori
• “enumeration” è 1 stereotipo
• Sono riportati i possibili valori (senza visibilità)
101

Dipendenze - Relazioni
102

Dipendenza - Dependency
103
• Si ha dipendenza (Uses) tra due elementi di un diagramma
se la variazione dello stato di un’istanza della classe
indipendente implica un cambiamento di stato nell’istanza
della classe dipendente
• Da inserire solo quando danno valore aggiunto
– Troppe dipendenze creano confusione nel diagramma
Un cambiamento di stato
dell’oggetto “Channel” genera un
aggiornamento dell’oggetto
“FilmClip” che lo usa.
Non è vero l’inverso.
Tipico: oggetto è il tipo del
parametro di un metodo

Dipendenze UML
104
Parola chiave Significato
«call» La sorgente invoca un’operazione della classe destinazione.
«create» La sorgente crea istanze della classe destinazione.
«derive» La sorgente è derivata dalla classe destinazione
«instantiate» La sorgente è una istanza della classe destinazione (meta-classe)
«permit» La classe destinazione permette alla sorgente di accedere ai suoi campi
privati.
«realize» La sorgente è un’implementazione di una specifica o di una interfaccia
definita dalla sorgente
«refine» Raffinamento tra differenti livelli semantici.
«substitute» La sorgente è sostituibile alla destinazione.
«trace» Tiene traccia dei requisiti o di come i cambiamenti di una parte di modello
si colleghino ad altre
«use» La sorgente richiede la destinazione per la sua implementazione.

Esempio: Dipendenza <<create>>
105

Associazione - Association
• Indica il significato per cui un oggetto di una classe è
connesso ad un altro oggetto (Has a)
• Una associazione può avere un nome
• Una associazione può avere una /due direzione/i (anche
con nomi diversi) e rappresentare il ruolo che ha con la
classe
106

Associazione riflessiva
• È riflessiva se coinvolge oggetti della stessa classe
• Indica oggetti multipli della stessa classe che sono in
relazione fra loro in cui l’oggetto è istanza della stessa
classe (self-association)
• Se ruolo insiste più volte devo esprimere il ruolo più volte
107

Molteplicità associazione
108
1 se non specificata

Istanza di associazione
• Se “autore” è una associazione tra le classi “Libro” e
“Persona”, una istanza di “autore” è un link tra due oggetti,
uno della classe Libro e l’altro della classe Persona
109

Relazione di aggregazione - Aggregation
• Le aggregazioni sono una forma particolare di associazione
• Definisce una associazione del tipo “parte di” (Whole-Part)
– Relazioni tra classi in cui: una rappresenta un oggetto (Whole)
e l’altra una sua componente (Part)
– È detta anche Whole-Part
• E’ una associazione asimmetrica
• Graficamente
– Linea piena con rompo rivolto verso la classe più generale
110

Relazione di aggregazione
111

Composizione - Composition
Simile ad Aggregazione ma:
• E’ una forma di aggregazione di tipo forte (Ownership)
• La loro esistenza ha senso solo in relazione al contenitore
• Creazione e distruzione avvengono nel contenitore
• I componenti non sono parti di altri oggetti
• Se si cancella il contenitore si cancellano anche le parti
• Le parti componenti non esistono senza il contenitore
• Ad esempio le “Inner class”
112

Generalizzazione - Inheritance
• Indica un legame tra una classe generale, denominata
super-class o parent, ed una sua versione più specifica,
denominata sub-class o childclass
113
Un qualsiasi oggetto, istanza di
una classe specializzata, può
essere sempre utilizzato
ovunque compaia la classe
“base”
Shape s = new Square();

Principio di sostituzione di Barbara Liskov
• Questa nozione di sottotipo è quindi basata sulla nozione di
sostituibilità secondo cui, se S è un sottotipo di T, allora
oggetti dichiarati in un programma di tipo T possono essere
sostituiti con oggetti di tipo S senza alterare la correttezza
dei risultati del programma.
114
"Se q(x) è una proprietà che si può dimostrare essere valida per
oggetti x di tipo T, allora q(y) deve essere valida per oggetti di tipo S
dove S è un sottotipo di T."
Quando un metodo di una classe figlio
possiede la stessa “signature” (nome,
parametri formali e parametri di ritorno)
di una classe padre, si dice che ne effettua
la sovrascrittura (override)

Specializzazione di un attributo
• Se una classe C1 ha un attributo A di tipoT1, e se
C2 è una sottoclasse di C1, specializzare A in C2
significa definire A anche in C2 ed assegnargli un
tipo T2 i cui valori sono un sotto insieme dei
valori di T.
115

Specializzazione di una operazione
• Un’ operazione si specializza specializzando i parametri e/o
il tipo di ritorno.
116

Specializzazione di una associazione
• Se una classe C1 partecipa ad una associazione R1 con
un’altra classe C3, e se C2 è una sottoclasse di C1,
specializzare R1 in C2 significa:
– Definire una nuova associazione R2 tra la classe C2 e la
classeC3 (o una classe C4 che è sottoclasse di C3)
– Stabilire una dipendenza di tipo {subset} da R2 a R1
117
C1 C3
C2
C4
R1
R2

Regole di generalizzazione
• Il grafo delle generalizzazioni non
può contenere cicli !
• Molti linguaggi non supportano
ereditarietà multipla (usare
delegation)
118

Eccezioni e Responsabilità
119
Sono opzionali

Packages
I package sono contenitori di classi
• Aiutano a modellare sistemi complessi
• Possono esistere package e sottopackage
• Si tende ad inserire nel package classi che hanno un
comportamento e scopo comune nel sistema
• E’ possibile definire relazioni tra package
120

Class diagram - consigli
121
• Diagrammi sono molto ricchi di concetti (ne abbiamo visto
una parte dei possibili)
– Non cercare di utilizzare tutte le notazioni disponibili
• Cominciare dapprima con i concetti semplici
– Una prospettiva concettuale permette di esplorare il linguaggio di
un particolare business
• Mantenere la notazione semplice e non introdurre concetti
legati al software
– Concentrarsi nel disegno dei diagrammi delle parti più importanti
• Disegnare ogni cosa è sinonimo di diagrammi non
fondamentali che diventano obsoleti molto presto!

Class diagram - legenda
• Consiglio di inserire nei documenti insieme ai class diagram
una mini legenda.
• Può aiutare ad evitare di sbagliare
122

Class diagram - esempio
123
Una istanza di un Commento può
essere presente solo in un post

Class diagram - Esempio
124
(Mobile)
(Divano)
Composta
da mobili Composta da
strutture
Una stanza contiene
0..* mobili
Un mobile sta in 1 stanza sola
Dipendenza
Struttura è
astratta

Object Diagram
125

Object Diagram
126
Business
Analyst
Product
Owner
System
Architect
Software
Engineers
Aiutano a
definire
vocabolario
“Consumer”,
intermediario
tra tecnici e PO
Creatore,
conosce
oggetti
sistema
“Consumer”,
implementa O.D.

Object Diagram
• Consentono di descrivere un sistema in termini di
oggetti e relative relazioni.
– Fotografia degli oggetti che compongono un
sistema in un determinato tempo
– Non ci sono parti obbligatorie
– Specifica di istanza
• Anche di classi astratte, omissione dei metodi, ecc…
127

Object Diagram
128
nome dell’istanza : nome della classe

State Machine Diagram
129

State Machine Diagram
130
Business
Analyst
System
Architect
Software
Engineers
Definiscono
stati e
transizioni
possibili
Definiscono
eventi che
scatenano
transizioni
Implementano la
State Machine

State Machine Diagrams
• State Machine Diagrams o Statechart diagrams
sono diagrammi usati per rappresentare il
comportamento di una classe (o di un intero
sistema) descrivendone i possibili stati raggiunti
durante il ciclo di vita della classe, e la reazione
ad eventi esterni, in termini di cambiamenti di
stato e/o azioni svolte.
• Mostrano una macchina a stati enfatizzando il
flusso di controllo da stato a stato
• Specificano le sequenze di stati che ha un
oggetto durante il suo ciclo di vita in risposta ad
eventi.
131

State Machine Diagrams
• Descrivono il ciclo di vita degli oggetti di una
classe, attraverso modifiche causate da eventi
che li interessano
• E’ composto da:
– Stato
– Attività/Azioni
– Eventi
– Transizioni
132

Esempio
133
Le transizioni non
ammesse sono bloccate

Stati iniziale e finale
Stato iniziale - Stato finale
• Rappresentano i punti iniziali e finali
• Non rappresentano stati veri e propri perché non
hanno tutte le caratteristiche degli altri stati –
pseudo stati
134
Stato Iniziale Stato Finale

Stato Intermedio
• Rappresentato con un rettangolo con gli angoli smussati
• E’ composto da 2 compartimenti:
– Nome
• Una stringa testuale che distingue uno stato da un altro;
se non ha nome è considerato anonimo
– Transizioni interne
• Contiene una lista di attività o azioni interne che sono
eseguite mentre l’elemento è all’interno dello stato. Quindi
tali attività o azioni non comportano il cambiamento di
stato
135
Sintassi: [label] ‘/’ action - expression

Stato Intermedio
Alcune label sono riservate:
• Entry/Action: eseguita nel momento in cui si entra in uno
stato
• Exit/Action: eseguita nel momento in cui si esce da uno
stato
• Do/Activities: identifica un’attività in esecuzione mentre
l’oggetto è nello stato della transizione
• Include/nomeSubMachine : invocazione a una sub-
machine. L’azione contiene il nome della sub-machine
invocata.
136

Stato con azioni
137

Action - Expression
• Rappresentano operazioni interne (eseguite mentre
l’oggetto è in uno stato) che possono richiedere tempo e
sono interrompibili
• Action:
• Sono delle attività che vengono subito eseguite
• Comportano un cambiamento di stato dell’oggetto
• Non possono essere interrotte per non produrre stato
inconsistente
• Activity:
• Attività eseguite dopo altre (entry, exit)
• Non comportano un cambiamento di stato dell’oggetto
• Possono essere interrotte perchè non producono stato
inconsistente
138

Pseudo stati
• Sono degli stati di astrazione che permettono di definire
uno stato caratterizzato da un determinato comportamento
• I tipi di pseudoStati sono i seguenti:
– initial
– deepHistory
– shallowHistory
– join
– fork
– junction
– choice
– entryPoint
– exitPoint
– terminate
139

Pseudo stati
140
FORK
JOIN
JUNCTION

Stati composti
• Uno stato che ha sotto-stati viene detto stato composto
• Può essere decomposto in
– Sottostati sequenziali
– Due o più sottostati concorrenti (dette regioni)
• Ogni sottostato può essere a sua volta uno stato composto
141

Transizioni
• Rappresenta una relazione tra due stati
• Non avviene spontaneamente ma al verificarsi di
un evento
142

Esempio
143
Può rimanere in
stato Faulted

Sequence Diagram
144

Sequence Diagram
145
Business
Analyst
System
Architect
Software
Engineers
Sanno cosa
accade (step)
Assicurano
correttezza
diagrammi
Implementano le
operazioni (gap
analysis)

Sequence Diagram
• Descrivono la collaborazione di un gruppo di oggetti che
interagiscono mostrando il loro comportamento dinamico.
• Un limite dei Class e Object Diagram è quello di esprimere
solo legami “statici” fra entità.
• Gli Use Case Diagram descrivono interazioni solo ad un
livello molto elevato di astrazione, trascurando volutamente
molte caratteristiche interne dei sistemi.
• Per questo servono diagrammi di iterazione come i
Sequence Diagram.
• Sono usati per “formalizzare” gli scenari, in termini di:
– Entità / Partecipanti (oggetti)
– Messaggi scambiati (metodi)
146

Sequence Diagram
147
Builder Pattern
Scorreredeltempo
Partecipante
Linea della vita

Sequence Diagram
148
Oggetto di riferimento
(istanza di un oggetto)
Messaggio di partenza sincrono
Messaggio di risposta asincrono
Blocco opzionale
Durata temporale azione
Messaggio asincrono
Terminazione

Partecipanti
Entità che detengono il flusso del caso d’uso
• UML 1.x  Istanze di classi (oggetti)
• UML 2.x  Concetto più lato
– Eliminata la sottolineatura
• Barra di attivazione
– Indica in quale momento
un partecipante è attivo
• Opzionale, ma molto utile
149
Oggetto1: Classe1
Barra di
attivazione
Linea della vita

Partecipanti
150
Istanza generica di oggetto Classe1 (tutti gli oggetti
della classe)
Oggetto di riferimento con nome Obj1
Istanza specifica di oggetto Classe1

Messaggi (Segnali)
151
• Rappresentano la comunicazione tra due oggetti (dati e
operazioni scambiati tra i partecipanti)
– Chiamata a metodi degli oggetti
Chiamata Asincrona (freccia aperta)
Chiamata che istanzia un oggetto
Chiamata Sincrona (freccia chiusa, può anche
essere piena)
Ritorno (metodo sincrono termina) – usare solo
se aggiunge informazioni o aiuta a capire
<<create>>
Chiamata che distrugge un oggetto

Messaggi
• Se hanno un testo indica in genere il metodo invocato, a
volte comprendendo anche parametri (se aiuta
comprensione)
152
Restituisce un utente

Interation Frame
• Utili per modellare cicli e condizioni
153
Pseudocodice procedura spedizione
foreach (lineItem)
{
if (product.value> 10K)
careful.dispatch
else
regular.dispatch
end if
}
if (needsConfirmation)
messenger.confirm
Opzionale

Interation Frame
• O chiamate parallele
154
Eseguiti in
parallelo

Esempio
155
Messaggio trovato
Messaggio
Chiamata interna
Ritorno

Esempio - Macchina self-service
Interfaccia è costituita da 3 oggetti:
• Pannello frontale: per il cliente
• Registro del denaro: raccoglie le monete
• Dispencer : dove viene erogato il prodotto al cliente
Funzionamento tipico della macchina:
• Il cliente inserisce le monete nello slot
• Il cliente fa la selezione
• Le monete arrivano al registro
• Il sistema controlla se il prodotto selezionato è nel
dispenser
• Il registro incrementa la sua riserva di cash
• Il registro rilascia il prodotto nel dispenser
156

Esempio - Macchina self-service
157

Communication Diagram (Collaboration)
158

Communication Diagram
159
Business
Analyst
System
Architect
Software
Engineers
Sanno cosa
accade (step)
Assicurano
correttezza
diagrammi
Implementano le
operazioni (gap
analysis)

E' simile al Sequence Diagram:
• Sono semanticamente equivalenti in quanto mostrano
stesso tipo di informazioni
• Evidenziano le interazioni tra le parti
• Rivolgono maggiore attenzione allo scambio dei messaggi
Ma è diverso dal Sequence Diagram :
• Organizzato in funzione dello spazio e non del tempo
• Non vi è una particolare dimensione per rappresentare il
tempo a parte la numerazione.
• Sono più evidenti i legami tra gli oggetti rispetto alla
sequenza dei messaggi
160

• Grafo in cui i nodi sono gli oggetti (istanze) e gli archi sono
i link
161
• I messaggi sono
numerati per mostrare la
sequenza temporale
delle operazioni

Communication vs Sequence Diagram
• Esprimono informazioni simili ma le evidenziano
in modo differente
• Spesso non è necessario descrivere il sistema
utilizzando entrambi i diagrammi
• E’ generalmente possibile passare da un
diagramma all’altro
• Un Communication Diagram, in UML 2.0 (in 1.0 lo
era), non e’ più totalmente equivalente ad un
Sequence Diagram (contengono alcuni elementi
particolari in più).
162

Component Diagram
163

Component Diagram
164
Business
Analyst
System
Architect
Software
Engineers
Capiscono
bisogni del
business
Costruiscono
i diagrammi,
identificano
componenti
Creano
componenti
“pluggabili”
Configurano
sistema e
monitorano
Delivery &
Operations

Component Diagram
• Rappresentano l’architettura SW del sistema,
ovvero la suddivisione di esso in varie
componenti (classi, librerie, DB, eseguibili, etc.) e
le dipendenze tra questi
• Consentono di descrivere l'organizzazione e le
dipendenze tra componenti software.
• Concetti di: componente, interfaccia.
165

Componente
• I componenti sono moduli software (eseguibili o
meno), dotati di identità e con un'interfaccia ben
specificata
• Non esiste un metodo unico per l’individuazione
dei componenti
• Spesso un componente rappresenta una classe o
un package del class diagram
166

Componente
Abbiamo due tipi di componenti
• Componenti Logici : ad es business components, process
components, …
• Componenti Fisici: componenti COM+ e dll .NET ,
componenti EJB, componenti WSDL, componenti CORBA,
porte, …
Che si differenziano dagli artifacts usati per rappresentarli e
dai nodi in cui vengono deployati ed eseguiti.
• Ad esempio in un component diagram troviamo:
componenti, interfacce (fornite/richieste), classi, porte,
connettori, dipendenze, utilizzi, …
167

Interfaccia
• Rappresenta l’interfaccia di un componente
• Un componente può avere più interfacce
168
Implementa
Payment (è fornita
da Online Bill Player)
Richiede Payee e
Account

Dipendenze
• Tra due componenti esiste una dipendenza
quando modificando la definizione di uno (il
supplier) può doversi modificare la definizione
dell’altro (il client).
169

Dipendenze
170

Component Diagram
171
Loosely
Connected
Component
Tightly Connected
Input
Interface
Output Interface

Component Diagram – Data Source Concept
• Un client usa una Interface
<I> che espone un contratto
di accesso ad una funzionalità.
• Il client quindi istanzia un
oggetto DataSource<I,A> per
usare una API<S> esposta dal
servizio Service<S>.
• Data sources per diversi
target systems consentono
alle applicazioni di accedere a
diverse piattaforme e sistemi
172

Es DataSource Concept
173
Operazione di Find
eseguita su 2
DataSource differenti, di
Polizze e Anagrafica

Deployment Diagram
174

Deployment Diagram
175
System
Architect
Definiscono
ambiente
Come fare
deploy
(sicurezza, …)
Separano sistema
su più server,
assicurano up &
running
Delivery &
Operations
Product
Owner

Deployment Diagram
• Rappresenta la relazione fisica tra i componenti
SW e HW
• E’ utile quando si ha la necessità di mostrare in
quale componente HW di un sistema viene
eseguito o risiede ciascun componente SW.
176

Nodi
• In generale rappresenta una classe di risorse omogenee
• Per rappresentare una specifica risorsa del sistema si usano
le istanze di nodo
• Una istanza di nodo e’ rappresentata come un nodo, ma il
nome e’ del tipo nome:classe
177

Connessioni
• Rappresentano la comunicazione tra due o più nodi
• Possono rappresentare il protocollo di comunicazione usato
178

Artifact
• Dentro nodi posso rappresentare gli artifact, che sono la
manifestazione fisica del SW
• Tipicamente sono file (eseguibili, dati, pagine web, …)
• Se un artifact è posto all’interno di un nodo il file sarà
memorizzato nel nodo
• Un artifact può essere indicato all’interno del nodo come
class box, indicando però l’icona documento o la parola
<<artifact>>
• È possibile etichettare con label tra {} sia i nodi che gli
artifact per specificare svariate informazioni (produttore,
S.O. , …)
179

Deployment Diagram - Esempio
180

Deployment e Component Diagram
• A volte appaiono in un unico diagramma per mostrare la
distribuzione dei vari componenti nei nodi del sistema
181

Deployment e Component Diagram
182

Package Diagram
183

Package Diagram
184
Business
Analyst
System
Architect
Software
Engineers
Devono
interpretare
cosa è un
package
Definiscono
packages
Implementano
componenti del
package

Package Diagram
• Consentono di mostrare l'organizzazione dei packages di un
sistema e dei loro elementi e relazioni.
• Concetti di: package, merge, use, import, nested.
185

Package Diagram
186

Package Diagram – Es. Multi layered web architecture
187

Agenda
188

Il Progetto Software con UML
• Vediamo un modello semplificato, tratto del ciclo
fondamentale del Rational Unified Process di IBM
• I passi dell’ analisi e della progettazione non
devono mai essere vissuti come imposizioni, ma
come un ausilio al mantenimento della precisione
e, conseguentemente, di un migliore controllo
sull’andamento dei lavori e del progetto
• Ci concentreremo sui passi che possono
richiedere uso di UML
189

Fasi che Compongono il Progetto
• Raccolta informale dei requisiti, comprensiva di tutti i
requisiti funzionali e non
• Definizione dei criteri di accettazione
• Stesura del Glossario (dizionario dei termini specifici del
dominio del problema cui il progetto deve fornire una
soluzione software)
• Stesura dell’ analisi funzionale formalizzata con gli Use Case
• Definizione della cronologia delle interazioni (Activity
Diagram), design delle interfacce utente e Diagramma di
Navigazione (Mock-up)
• Definizione delle entità, delle relazioni che tra esse
intercorrono e formalizzazione con il Class Diagram di
analisi e la sua descrizione
• Design della base di dati e sua costruzione (e generazione
degli script di creazione tabelle)
190

Fasi che Compongono il Progetto
• Design architetturale del sistema
• Progettazione software e Class Diagram di Progetto
• Pianificazione delle attività ed assegnamento degli incarichi,
fatta attraverso strumenti di project management
• Sviluppo del software, seguendo le regole di stesura del
codice definite a livello aziendale o di gruppo di sviluppo o
uno degli standard presenti in letteratura
• Debug del software stendendo tracciando bachi sui problemi
incontrati, in modo tale che possano servire d’aiuto in
situazioni analoghe successive
• Documentazione
• Definizione delle procedure per l’installazione del software
stesso (release notes).
191

Raccolta dei Requisiti
• Ha in genere lo scopo di produrre un documento informale,
scritto in linguaggio naturale, che spieghi molto brevemente gli
obiettivi del cliente.
• Questo documento dovrebbe avere le seguenti caratteristiche:
– Indicare chi è il cliente finale;
– Indicare i requisiti che il cliente richiede (situazione attuale e
obiettivo atteso);
– Definire di che tipo di lavoro si tratta;
– Indicare (se esistono) vincoli imposti da altri software o sistemi o
ambienti esistenti con cui si debba interoperare;
– Indicare requisiti non funzionali (es. numero di accessi simultanei,
dimensioni della base dati, prestazioni attese, ...);
– Descrivere “informalmente” e a grandi linee il lavoro da svolgere.
– Riportare le fonti informative
192

Raccolta dei Requisiti - Esempio
Cliente : MioCliente S.r.l. con sede in Via Pinco Pallo …
Descrizione Del Contesto del Sistema
Situazione Aziendale Attuale:
• La MioCliente S.r.l. è una società fondata nel 2001 con 30
dipendenti e si occupa di …
• L'azienda al momento non presenta un sistema informativo
in grado di raccogliere gli ordini in modo automatico, ma
bensì al momento gli ordini vengono inviati o tramite
telefono o tramite fax.
193

Raccolta dei Requisiti - Esempio
Obiettivo:
• Realizzare un sistema gestionale Web per l'invio e la
ricezione degli ordini che permetta ad ogni utente del
servizio di accedere al sistema, previa autenticazione, e gli
consenta di controllare i prodotti che il magazzino ha a
disposizione o che, in caso di momentanea indisponibilità, è
in grado di avere nell'arco di pochi giorni.
• Gestire anagrafica magazzino e anagrafica fornitori …
Vincoli:
• Il sistema deve supportare i browser IE 10 e successivo e
Chrome 40.0 e successivi
• Il sistema deve essere di facile comprensione vista
l'avversità di molti utenti alla tecnologia informatica.
Fonti Informative: Amministratore Delegato Pinco Pallo, …
194

Requisiti non funzionali - Vincoli
• Sono tutti quei requisiti che non riguardano le
funzionalità del sistema, ma ne permettono o
caratterizzano il funzionamento:
– Scalabilità
– Performance
– Supporto di Sistemi Operativi
– Supporto di browser (se necessario)
– Localizzazione
– Usabilità
– Standard usati, ad es. ISO 8601 per date, ISO/IEC
10646 (Unicode) per codifica testo, …
– Supporto al cliente
– …
195

Definizione dei criteri di accettazione
Criteri di Accettazione
• I tempi di attesa di ogni pagina web non devono
superare i 3 secondi per un utente collegato con
un collegamento T1
• Il sistema deve supportare almeno 50 utenti
loggati in contemporanea
…
196

Stesura del Glossario
• Definire la terminologia del progetto, identificando con
precisione le entità (persone, ruoli, luoghi, oggetti
materiali, eventi, strutturazioni ecc...) coinvolte nel sistema
del mondo reale (ovvero del dominio di business) che
hanno importanza per il sistema informativo obiettivo del
progetto.
• Il documento Glossario definisce con precisione tutti i
termini corrispondenti alle entità coinvolte, evitando
ambiguità.
• Identificare le entità serve per poter definire Use Case
Diagrams e individuare le classi per i Class Diagrams
197

Analisi Funzionale con i Casi d’Uso
• Individuare con precisione gli scenari d’uso del sistema,
cioè gli scenari di interazione fra il sistema e gli attori,
ovvero le entità esterne al sistema con cui esso interagisce
e comunica.
198
Definizione “boundary” del sistema
Identificazione Attori / Ruoli
Individuazione Use Case
Definizione iterazioni entro Use Case
Checkraggruppamento diagrammi e loro descrizioni
Tramite <<extend>>
e <<include>>

• Il risultato è l’insieme completo degli Use Case presenti in
uno o più Use Case Diagram, ognuno corredato di adeguata
descrizione, strutturata chiaramente in forma di request-
response e considerando sia il percorso principale di
interazione (basic course) sia gli eventuali percorsi
alternativi (alternative courses), come quelli che si
verificano in presenza di errori nei dati inseriti ecc...
• A volte possibile inserire degli Activity Diagrams (per
definire le attività associate ai singoli use case) o dei
diagrammi di navigazione fra le finestre o maschere che
costituiscono l’interfaccia utente dell’applicazione
• I diagrammi da soli non sono sufficienti e si devono
aggiungere ulteriori descrizioni, che rendano più preciso il
tutto.
199

Esempio Gestione Anagrafica Clienti
200

Esempio Gestione Anagrafica Clienti
201

• E’ possibile inserire nella descrizione di uno Use
Case anche:
– i possibili eventi che fanno iniziare/scatenano lo use case
– eventuali prerequisiti
– Input e Output
– Tecniche usate / normative / linee guida / buone
pratiche
202

Stesura del Diagramma di Navigazione
• Il risultato di questa fase è espresso attraverso un Activity
Diagram che definisce la successione cronologica di attività,
ciascuna delle quali corrisponde ad un tipo particolare di
interazione tra gli attori ed il sistema.
• Non è detto che le singole attività abbiano sempre una
corrispondenza uno a uno con i singoli casi d’uso: in alcuni
casi è opportuno suddividere un singolo Use Case in più di
un’attività o, viceversa, accorpare in una sola attività più di
un caso d’uso.
• Nel diagramma di navigazione ciascuna attività è derivata
una interfaccia utente (maschera Form o Web) e definisce
con precisione la navigazione fra le maschere utente.
• I diagrammi vanno ovviamente corredati di descrizione di
ciascuna delle interfacce utente.
• A volte si usano tool di Mock-up
203

Esempio
204

Esempio - descrizione
Schermata Principale
• La schermata principale è la finestra che viene presentata
all'avvio dell'applicazione e deve fornire all'utente una
scelta ...
Aggiornamento delle fatture
• La finestra di aggiornamento delle fatture si apre in seguito
all'azione sul pulsante corrispondente nella schermata
principale …
Creazione delle rimesse
• La finestra di creazione della rimessa si apre in
corrispondenza dell'azione sul pulsante della schermata
principale …
205

Definizione delle entità attraverso il Class Diagram di Analisi
• Questo diagramma deve indicare chiaramente
tutte le classi entità, ossia le classi definibili come
“proiezioni” nel dominio della applicazione
software delle entità del dominio del problema
dove la applicazione software andrà ad operare.
• Questo diagramma è l’equivalente da un punto di
vista del ruolo ai diagrammi Entità-Relazioni (ER)
usato nelle metodologie di sviluppo più
tradizionali.
206

Componenti del Class Diagram di Analisi
• Entità del dominio
• Attributi caratteristici delle entità
• Associazioni tra entità (legami logici)  influenzeranno la
visibilità di classi, metodi, proprietà
• I versi delle associazioni
• La molteplicità delle associazioni
• Eventuali rapporti di inclusione (aggregazione/composizione)
• Eventuali rapporti di ereditarietà
• I metodi delle classi si possono definire in seguito
• Da questo diagramma dipenderà (se necessaria)
modellazione della base dati
• Itero il processo fino a quando tutte le relazioni tra classi
sono individuate e inserite le descrizioni
207

Design della base di dati e sua costruzione
• L’obiettivo deve essere la costruzione degli script per la
generazione della base dati entro un DBMS relazionale, che
dovranno essere salvati a parte.
• Si parte dal modello del dominio di business formalizzato
attraverso il Class Diagram di Analisi, per giungere al
modello di tabelle della base di dati. Si può eventualmente
tradurre il Class Diagram in un diagramma Entità-Relazione
(ER), oppure giungere per passaggi successivi alla forma
finale.
• L’insieme delle tabelle nella base dati può essere anche
molto diverso dallo schema delle classi iniziale.
208

Design architetturale del sistema
• Ovviamente molto dipende dall’argomento del progetto.
• Si possono usare ad esempio alcuni pattern architetturali
(MVC, MVP, MVVM, paradigma Client-Server, …)
• La scelta dell’architettura deve anche segnalare limiti e
criticità nel sistema che sarà realizzato.
• L’output di questa fase sono documenti tecnici
architetturali, che saranno poi corredati da eventuali
Component Diagram e Deployment Diagram solo al termine
della fase di progetto vera e propria.
209

Progettazione software e Class Diagram di Progetto
• Definire chiaramente tutte le classi che fanno parte
dell’applicazione SW da implementare.
• Il Class Diagram di Progetto è l’elenco completo delle classi,
con tutte le loro relazioni e su di esso si basa anche il
dimensionamento della fase di sviluppo (ovvero scrittura
vera e propria del codice).
• Si parte dal diagramma delle classi di analisi e si aggiungono
tutte le classi di servizio, ossia le classi infrastrutturali, non
necessariamente derivate dalla fase di analisi, che
permettono al programma nel suo insieme di operare in
modo corretto ed efficiente (dipendono da framework e
linguaggio usato)
210

• E’ possibile inserire anche Sequence Diagrams (enfasi sulla
sequenza temporale delle interazioni) e Collaboration
Diagrams (enfasi sulla dipendenza fra le classi) per aiutare
la definizione dei metodi che le classi offrono le une alle
altre (e dei loro argomenti e valori di ritorno) e per
l’individuazione di eventuali “colli di bottiglia” che vengono
risolti con l’inserimento di nuove classi.
• In teoria ad ogni Use Case corrisponde almeno un
Sequence o Collaboration Diagram (ogni corso di eventi
individuato nell’analisi con gli Use Case dovrebbe produrre
una precisa sequenza temporale di invocazione di metodi
all’interno dell’insieme delle classi costituenti il sistema)
211

• Gli State Diagrams sono molto importanti per valutare
l’evoluzione temporale delle singole classi (o meglio degli
oggetti da esse istanziati) o di sottosistemi che esse vanno
a costituire, aiutando ad individuare eventuali condizioni
critiche o colli di bottiglia.
• Spesso per motivi di chiarezza (specialmente in progetti
grandi dove le classi sono molto numerose) il diagramma
viene diviso in package (associazioni di classi corrispondenti
ad unità funzionali) indicando esternamente ad essi solo i
legami che fra i singoli package intercorrono.
• Ciascun package viene poi rappresentato completamente
entro un diagramma di secondo livello.
212

Agenda
213

Certificazioni
• OCUP 2 – OMG’s UML 2.5 Certification
http://www.omg.org/ocup-2/index.htm
• Tre livelli (Foundation, Intermediate, Advanced)
214

Tools
• Elenco completo su www.uml.org
Freeware / Open Source
ArgoUML, plugin di Eclipse, NetBeans, StarUML, UMLet, UML Pad,
…
Strumenti Commerciali
Altova, Borland Together, Microsoft Visio, Rational Rose e Rational
Software Architect, Visual Paradigm, Sparx Enterprise Architect,
NoMagic MagicDraw, Poseidon for UML, MS VS Ultimate
(Activity, Class, Component, Sequence, e Use Case), …
On line
https://www.draw.io/ , https://www.gliffy.com , …
Fatevi il vostro !!! Con http://www.jointjs.com/
215

Tools - Esempi
• Eclipse: MDT/UML2 (è solo metamodel) + MDT/Papyrus
(per diagrammi visuali) o in alternativa Apollo di
Gentleware, ma a pagamento
• MS Visio Professional: comprende Activity, State,
Sequence, Class, Use Case. Meglio inserire Visio Stencil and
Template for UML 2.5
• UMLet: solo subset di diagrammi, non tutti
• Visual Paradigm: community edition free per usi non
commerciali
• Enterprise Architect
• Esiste una Google App ? Si, Lucidchart (diagrammi online)
• …
216

Interactive Session
217

Riferimenti e risorse
• Introduzione alla gestione del progetto software con UML
(Giulio Destri)
• IIBA, A Guide to the Business Analysis Body of Knowledge®
(BABOK® Guide)
• UML Distilled - Guida rapida al linguaggio di modellazione
standard, Martin Fowler, 2004, Pearson (Addison Wesley)
• www.uml.org e www.omg.org
• http://www.uml-diagrams.org/
• “Corso UML” di Giuseppe dell’Abbate su Slideshare
• Learning UML 2.0, Kim Hamilton e Russell Miles, O’Reilly,
2006
218
• Applicare UML e i pattern – Analisi e progettazione
orientata agli oggetti, 2005, Craig Larman

219

IntroduzioneAllaGestioneDiUnProgettoSoftwareConUML

Recomendados

Recomendados

Más contenido relacionado

Similar a IntroduzioneAllaGestioneDiUnProgettoSoftwareConUML

Similar a IntroduzioneAllaGestioneDiUnProgettoSoftwareConUML (20)

IntroduzioneAllaGestioneDiUnProgettoSoftwareConUML