Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Ing. R. Turco
1
Copyright 2003 – R. Turco
Introduzione
Gli esempi che esamineremo saranno organizzati nel seguente modo:
Titolo del sistema
Descrizione del problema
Requirements Model
Il Requirements Model descrive che cosa fa il sistema. I requisiti funzionali vengono
espressi attraverso gli use case e gli attori. Possono essere espressi anche i requisiti
non funzionali. Con gli use case si ha una vista comportamentale, mentre con le
relazioni tra use case si ha una vista strutturale.
o Use case
o Descrizione testuale degli use case
La descrizione testuale è efficace quando sono molti i dettagli in gioco in un use
case. La scrittura testuale di uno use case con molti dettagli permette una
riduzione del rischio di incomprensione o di omissione di informazioni. Può essere
omessa solo nel caso di problemi semplici. La descrizione testuale di uno use
case aiuta a capire ed organizzare bene lo scenario d’uso.
Analysis Model
L’Analysis Model tende a comprendere il sistema, identifica gli oggetti del dominio, le
informazioni passate.
o Static Modeling
Diagramma delle classi
Il Diagramma delle classi può essere studiato usando una miscela di
metodi diversi:
Use Case Driven;
Schede CRC;
Metodo del linguaggio verbale, individuando nomi concreti, nomi
astratti, verbi, specializzazioni (“E’ un”), contenimenti o
aggregazioni (“Ha un” etc);
Metodo dei colori di Coad;
o Object Strutturing
Determina gli oggetti in ogni use case e la loro organizzazione strutturale
(package e dipendenze);
L’Object Structuring identifica e categorizza gli oggetti software.
L’identificazione avviene da use case e dal modello delle classi; mentre la
categorizzazione si basa su:
Oggetti d’interfaccia o di confine (boundary): device, user, system;
Entità Object: oggetti che memorizzano informazioni;
Control Object: oggetti che fanno coordinamento (coordinatori, timer,
state-dependent);
Application logic objects: oggetti algoritmici, busines logic object.
o Dynamic modeling:
Gli use case sono raffinati per mostrare l’interazione tra oggetti per ogni use
case (diagramma delle sequenze, diagramma delle attività, diagramma degli
stati).
o Customizing, Collapsing, Design Refactoring, Riuso
In ogni caso, grazie all’astrazione, dal modello del dominio del problema di partenza si arriva al
modello del dominio della soluzione.
2
Copyright 2003 – R. Turco
Se gli use case sono molti una strategia è quella di riportarli su più “fogli”, cercando di mettere
sullo stesso foglio gli use case e gli attori correlati da <<include>> ed <<extend>>. Questa
strategia permette anche una parallelizzazione di analisi con più persone.
Inoltre per gli use case testuali il consiglio è di compilare i template degli use case e di quelli
che da cui i primi hanno una dipendenza dovuta agli <<include>> e <<extend>>.
La suddivisione del lavoro per il modello delle classi, i diagrammi delle attività, i diagrammi
degli stati e delle sequenze segue la strategia adottata per gli use case: ogni persona modella
la parte che gli discende dagli use case fatti.
Sistema bancomat
Esaminiamo il problema di gestione di un sistema ATM (bancomat) di una banca.
Sistema:
Valida la carta bancomat: controlla se scaduto, controlla il PIN, controlla se la carta
è stata persa o rubata
Permette tre tentativi d’inserimento PIN: al terzo fallimento ritira la carta
Per semplicità si suppone che presenta un menù solo tre scelte: prelievo, estratto
conto, trasferimento fondi.
Prelievo:
Controlla se esistono sufficienti fondi sul conto, se esistono contanti nell’ATM
Controlla se esiste sufficiente contante nell’ATM
Controlla se esiste carta per la stampa delle ricevute
Termina fornendo i soldi, la carta e la ricevuta della situazione dell’account
Trasferimento fondi:
Verifica se nel primo account esistono sufficienti fondi
Controlla se esiste sufficiente contante nell’ATM
Controlla se esiste carta per la stampa delle ricevute
Effettua il trasferimento dei fondi
Fornisce la ricevuta della situazione del primo account
Restituisce la carta bancomat
Estratto conto:
Controlla se esiste carta per la stampa delle ricevute;
Stampa il bilancio dell’account richiesto
Fornisce la ricevuta della situazione dell’account
Restituisce la carta bancomat
Cliente:
Cancella una transazione per volta;
La transazione termina e ritira la carta
Il cliente ha un account (conto deposito) su cui ha dei soldi;
Server:
dati cliente, dati account, registrazione addebito sulla carta
Operatore ATM:
3
Copyright 2003 – R. Turco
attiva/disattiva l’ATM per rifornirlo di contanti e per manutenzione.
Figura 1
4
Copyright 2003 – R. Turco
In figura 1 le generalizzazioni sono dovute alle alternative di comportamento rispetto allo
use case base. Ad esempio ValidaPIN ha tre alternative, mentre VerificaSoldiAccount ne ha
due.
Riportiamo solo gli use case di maggior interesse. Gli altri dovrebbero essere riportati in
analogo modo.
6
Copyright 2003 – R. Turco
Diagramma delle classi
Vediamo una prima versione del modello.
Inoltre si è già guardato ad un’estensione dei comandi dell’ATM con il Pattern Command per gli
eventuali ed ulteriori comandi necessari: ricarica telefonino, pagamento bollette, etc.
[DR6][DR7].
Il modello delle classi di fig. 2 non è ancora soddisfacente, almeno in termini di contesto e di
Collapsing e di individuazione di archetipi [DR4].
Occorre eliminare ciò che non interessa al dominio del problema e stare attenti alla differenza
tra classe ed attributo.
Nel nostro caso è inutile tener conto che l’ATM abbia una stampante e un dispositivo per
inserire contante.
7
Copyright 2003 – R. Turco
Nel caso reale, invece, sarebbe utile considerarlo e far uso anche di classi astratte in modo da
scrivere driver sostituibili.
Il metodo getAtm() restituisce un boolean. Esso indica se lo sportello ATM è Busy (false) o
disponibile (true).
Lo sportello ATM può essere busy per uno di due motivi: in manutenzione o c’è già un cliente
con carta bancomat che lo sta usando.
Per cui setAtm(false) va usato sia nel caso di ATM in manutenzione per inserimento contante,
sia per cliente che lo sta utilizzando. Mentre setAtm(true) fa sì che lo sportello ATM presenti il
messaggio di benvenuto.
Sono state fatte delle assunzioni: il contante presente sull’ATM iniziale è di 1.000.000 di euro e
che il limite di prelievo di una carta è di 1.000 euro.
Per il contesto ha poco interesse la Banca come Party, viste le assunzioni iniziali del problema;
difatti la Banca entrerebbe in gioco nel momento che maturasse interessi sugli scoperti,
incassasse soldi sul numero di transazioni maggiori di 12 sull’account.
Nel modello sono stati poi introdotti dei metodi assegnando le giuste responsabilità (Pattern
GRASP) [DR7].
Bisogna anche ricordare di introdurre un Pattern Singleton sul bilancio (soldi sull’account del
cliente) per gestire la concorrenza di accessi ad esso.
La concorrenza sullo stesso account è possibile metterla in evidenza con un diagramma delle
attività.
8
Copyright 2003 – R. Turco
Figura 3 – Il raffinamento del primo modello
Object Structuring
Il package complessivo sarà ATM. Al suo interno avrà i package: Boundary, Control, Entity,
DatabaseDAO, DataBaseInterf.
Nel Package Boundary vanno messe tutte le classi che stanno a cavallo del confine tra attore e
sistema. Per cui è facile immaginare che nel Boundary vadano Cliente e Operatore che
serviranno da GUI. Nel Boundary rientrerebbe anche la Banca eventualmente se non
esistessero le assunzioni iniziali fatte.
Nel Package Control vanno le classi di controllo come ATMCommand e le sue derivate.
Nel Package Entity andranno tutte le altri classi che hanno necessità di persistenza sul DB.
Nel Package DataBaseDAO le classi che permettono una separazione (Pattern DAO) tra Entità e
Database e il Package DataBaseInterf che effettua il collegamento, le chiamate SQL verso il
DB.
9
Copyright 2003 – R. Turco
Figura 4 – Struttura organizzativa
Dynamic Modeling
Oltre ai diagrammi visti conviene almeno vedere dei sequence diagram. Col Sequenze Diagram
si ha anche un ritorno sulla sufficienza dei metodi in gioco.
10
Copyright 2003 – R. Turco
Sistema controllo ascensori
Deve essere installato un prodotto software per il controllo delle ascensori in un edificio.
Ogni ascensore ha m pulsanti interni, uno per ogni piano. Questi s’illuminano se
premuti e provocano che l’ascensore vada al piano corrispondente ed apre le porte.
L’illuminazione del bottone interno si spegne all’arrivo dell’ascensore al piano
corrispondente.
Ogni piano, eccetto il primo e l’ultimo piano, hanno due bottoni esterni: uno per salire
ed un altro per scendere. Quando questi pulsanti sono premuti si accendono per
prenotare l’ascensore. L’illuminazione si spegne quando l’ascensore arriva al piano, apre
le porte, e muove nella stessa direzione del pulsante.
Quando un’ascensore non viene prenotato rimane al piano con le porte chiuse.
Figura 6
Lo scenario è del tipo:
Un passeggero preme un pulsante di piano che si accende;
Il sistema rileva che un pulsante di piano è stato premuto;
L’ascensore viene spostato verso il piano;
Le porte dell’ascensore vengono aperte;
Il passeggero entra e prema i bottoni dell’ascensore;
L’ascensore si muove al piano richiesto;
L’ascensore apre le porte;
11
Copyright 2003 – R. Turco
Il passeggero esce;
L’ascensore chiude le porte.
Figura 7
12
Copyright 2003 – R. Turco
Dynamic Modeling
Figura 8
13
Copyright 2003 – R. Turco
RIFERIMENTI
[DR1] Martin Fowler – UML Distilled – Prima edizione italiana
[DR2] Leszeck A. Maciaszek - Sviluppo di sistemi informativi con UML
[DR3] Rosario Turco – Usabilità e ripetibilità dei processi produttivi software
[DR4] Rosario Turco – Modellare con l’UML ed i colori
[DR5] Robert C. Martin – Design Principles and Design Patterns
[DR6] Gamma, Helm, Johnson,Vlissides – Design Patterns – Elementi per il riuso di software a
oggetti – Prima edizione italiana
[DR7] Rosario Turco - Pattern e la “GRASP Oriented Analysis”
14
Copyright 2003 – R. Turco
INDICE
RISOLUZIONE PROBLEMI CON UML ............................................................................ 1
INTRODUZIONE .......................................................................................................... 2
STRATEGIA PER IL MODELING............................................................................................................ 2
SISTEMA BANCOMAT .................................................................................................. 3
DESCRIZIONE DEL PROBLEMA ........................................................................................................... 3
REQUIREMENTS AND ANALYSIS MODEL ..................................................................... 4
USE CASE.......................................................................................................................................... 4
DESCRIZIONE TESTUALE DEGLI USE CASE ........................................................................................ 5
DIAGRAMMA DELLE CLASSI ........................................................................................ 7
CUSTOMIZING, COLLAPSING, DESIGN REFACTORING E RIUSO .......................................................... 7
OBJECT STRUCTURING ............................................................................................... 9
DYNAMIC MODELING ................................................................................................ 10
SISTEMA CONTROLLO ASCENSORI ........................................................................... 11
DESCRIZIONE DEL PROBLEMA ......................................................................................................... 11
REQUIREMENTS AND ANALYSIS MODEL ................................................................... 11
USE CASE........................................................................................................................................ 11
DIAGRAMMA DELLE CLASSI ...................................................................................... 12
DYNAMIC MODELING ................................................................................................ 13
RIFERIMENTI ........................................................................................................... 14
15
Copyright 2003 – R. Turco