ingegneria del software e uml -...
TRANSCRIPT
Introduzionen I processi di sviluppo del software sono molto
complessin Un approccio a fasi è necessario per
controllarlin I possibili modelli in letteratura possono
esseren Modelli tradizionali, document-driven: nuovi
documenti prodotti al termine di ogni fasen Modelli evoluzionari, basati su un prototipo
che si adatta alle esigenze dell’utente e sievolve con esse
Perchè usare i cicli di vitan Fornire un framework per standardizzare la
terminologia, le attività e i prodotti(deliverables)
n Aumentare la visibilità del progresso del progetto per tutte le parti coinvolte
n Fornire le basi per il piano di progetto e lo scheduling delle attività
n Fornire meccanismi per controllarel’avanzamento e lo stato del progetto
Il giusto ciclo di vita
n Maggiore velocità di sviluppon Maggiore produttivitàn Maggiore tracciamento e controllon Maggiori relazioni con il clienten Minori rischi di progetton Minori overhead di progetto
Distribuzione dei costi100
80
60
40
20
0
1955 1970 1985
Hardware
Software
Development
Maintenance
Year
Per
cen
t o
f to
tal c
ost
B.W. Boehm, “Software Engineering”,IEEE Trans. On Computers, 1976.
Cosa è l’ingegneria del software?[First NATO Conference, 1968]“Software engineering is the establishment and use of sound principles in order to obtain economically software that is reliable and works efficiently on real machines”
[IEEE Std Glossary of Software Eng. Terminology]“Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software; that is the application of engineering to software”
Un semplice ciclo di vitaproblem
Requirements
Specification
Design
Program
Working Program
requirements engineering
design
implementation
testing
maintenance
Requirements Engineeringn Descrivere
n Il problema da risolvere,n E in quali condizioni
n Requisitin Funzionalin Non-funzionali (HW, SW esterno, numero
degli utenti, …)n La descrizione comprende: funzionalità,
estensioni future, quantità/tipo delladocumentazione richiesta, prestazioni e tempo di risposta
n Può comprendere uno studio di fattibilità
Designn Modellare il sistema da svilupparen Moduli, componenti e interfacce
n Prendere delle decisioni da includere nellaArchitettura del Software
n Utile per n Valutaren Utilizzare come template per una famiglia
di prodottin Scheletro per componenti riutilizzabili
Implementationn Concentrarsi nei singoli modulin Restare coerenti alla architettura software
n Non sempre possibile nei linguaggitradizionali
n Attuata dai nuovi linguaggi diprogrammazione
n Spesso facilitata dall’uso di pseudocodicedurante la fase di design
Testingn Trasversale e non successivo
all’implementazionen Soltanto a diversi livelli di astrazione
n Ai confini delle fasin Verifican Validazione
MaintenanceGestire i cambiamenti dopo la consegnan Migliorativa(cambiamenti nei requisiti utente)n Adattiva (cambiamenti nell’ambiente)n Correttiva (eliminazione degli errori)n Preventiva (per una migliore mantenibilità
futura del sistema)
Distribuzione delle risorse
45%
20%
15%
10%10%
specification
requirementsengineeringdesign
coding
testing
Distribuzione delle attività dimaintenance
n Migliorativa 50%n Adattiva 25 %n Correttiva 21%n Preventiva 4 %
Semplice Ciclo di vitaproblem
Requirements
Specification
Design
Program
Working Program
Req. engineering
Design
Implementation
Testing
Maintenance
Semplice Ciclo di vitan Basato sui documenti
n Gli obiettivi sono raggiunti se i relatividocumenti sono stati prodotti
n Per esempio: specifica dei requisiti, specificadi progetto, programma, documenti di test, …
n Problemin I commenti alla fine di ogni fase non sono
presi in considerazionen La maintenance non implica evoluzione
n Si corregge il prodotto, ma non si tornaindietro nelle fasi
Waterfall Model
Req. engineering
Design
Implementation
Testing
MaintenanceV & V
V & V
V & V
V & V
V & V
Pure waterfall
Modified waterfall
Waterfall Model (cont.)n Include iterazioni e feedbacksn V&V alla fine di ogni fase
n Verifica (stiamo costruendo il sistema correttamente?)n Garantire la corrispondenza tra un prodotto
software e le sue specifiche)n Validazione (stiamo costruendo il prodotto corretto?)
n Garantire la correttezza del prodotto rispetto aisuoi obiettivi
n I requisiti utente devono essere stabiliti il prima possibile
n Problemin Troppo rigidon Gli sviluppatori non si possono muovere tra i diversi
livelli di astrazione
PrototypingMotivazionen La raccolta dei requisiti è un’operazione molto difficile
n Il Software è sviluppato perché la situazione correnteè insoddisfacente
n Tuttavia la situazione desiderata è ancorasconosciuta
Caratteristichen Il Prototyping è usato per ottenere i requisiti di alcuni
aspetti del sisteman Il Prototyping dovrebbe essere un processo
relativamente economicon Utilizzare strumenti di sviluppo rapidi (Integrated
Development Environment)n Non tutte le funzionalità devono essere implementaten I controlli di qualità non sono richiesti
Prototyping: uno strumento per la raccolta dei requisiti
Req. engineering
DesignDesign
ImplementationImplementation
TestingTesting
MaintenancereadyNot ready
Tipi di Prototyping
n Throwaway prototyping: l’ennesimo prototipoè seguito da un processo di sviluppowaterfall-like
n Evolutionary prototyping: l’ennesimoprototipo rappresenta il prodotto finito
Vantaggi del Prototyping
n Il sistema risultante è di facile uson I bisogni dell’utente sono coperti meglion Il sistema risultante ha meno funzionalitàn I problemi sono rilevati priman Il design è di migliore qualitàn Il sistema risultante è di più facile
mantenimenton Lo sviluppo richiede meno risorse
Svantaggi del Prototyping
n Il sistema risultante ha meno funzionalitàn Le prestazioni del sistema finale sono
peggiorin Il design è di qualità inferioren Il sistema finale è più difficile da manteneren L’approccio basato sul prototyping richiede
un team con maggiore esperienza
Raccomandazioni sul Prototyping
n Gli utenti e i progettisti devono essereconsapevoli dei problemi e dei possibili rischi
n Utilizzare il prototyping quando i requisiti non sono chiari
n Il prototyping deve essere pianificato e controllato
Una “fabbrica” del Software
n Gli sviluppatori non sono propensi a realizzare del software facile da mantenere e da riutilizzare, comporta costi addizionali
n Il punto di vista cambia se l’obiettivo è la realizzazione di una famiglia di prodotti e non soltanto la versione iniziale di un prodotto
n I mezzi di un’azienda che sviluppa software sono:n La conoscenza condivisa da tutti gli impiegatin L’insieme dei prodotti parzialmente sviluppati
presenti nell’azienda
Una “fabbrica” del Software (cont.)
Il riuso diventa importanten Quindi si parla di Component-Based Software
Engineering (CBSE)Sono stati fatti progressi nell’area deln Design per il riuso (per esempio, architetture
software e modelli di progetto)n Componenti software
L’idea di una fabbrica del softwaren Condividere la conoscenzan Condividere prodotti e/o componenti
riutilizzabili
Procedural approachOO approach
Replaced by
Datahierarchy
Hierarchy of functions
Class hierarchy
Dati & Comportamenton Implementazione trasparente dei servizin Facile mantenimenton Omogeneità nella gerarchia dati-funzioni
Cosa sono gli oggetti?Il mondo può essere percepiton Punto di vista filosofico
n Oggetto = astrazione di un’entità realen Il mondo è fatto di oggetti
n Gli oggetti interni nascono e muoionon Gli oggetti esterni sono eterni
n Punto di vista di un modellon Oggetto = Identificatore + Stato + Comportamento
n Stato → attributi → variabilin Comportamento → operazioni
n Punto di vista dell’ingegneria del Softwaren Oggetto = astrazione di un’entità che contiene i dati e
le operazionin Costruttore e distruttore
Archiettura Object-orientedOrganizzazione di un sistema software in termini di una collezione strutturata di oggettin Strutturata = include associazioni di
n Utilizzon Aggregazione (“parte di” o “contiene un”)n Ereditarietà (“è un”)
n Collezione = Gli oggetti sono indipendenti dalsistema cui appartengono, perchén Sono significativi e utili individualmenten Riutilizzabili per sistemi differenti
Classi e OggettiClasse = descrizione di un dato astratton Offre
n Nomen Definizione della sua struttura datin Servizi per accedere alla sua struttura dati
n Elemento staticoOggetto = istanza di una classen Offre
n Identitàn Stato, accessibile attraverso i servizi definiti
dalla classen Elemento run time
Classi e Oggetti (cont.)n A run time
n Esistono solo oggettin Nel codice sorgente
n Esistono solo classi
InstanziazioneProcesso per la creazione di un oggetton Gli attributi sono inizializzatin L’istanza è assegnata ad una variabilen Operatori per l’instanziazione
n Costruttoren Distruttore
Dictionarylanguage
create_dictionary()insert_word()search_word()give_next_word()
D1: Dictionarylanguage = “German”
Associazionin Relazioni tra classi e tra oggettin Cardinalità delle associazioni
n Numero degli oggetti partecipantin 1, 0..1, M..N, *, 0..*, 1..*
n Tipo di associazionen Numero di classi che partecipano
all’associazionen Binaria, ternaria, N-aria
Aggregazionen Associazione asimmetrican Criteri che implicano
l’aggregazionen Una classe rappresenta
una parte di un’altraclasse
n Gli attributi di una classesono propagati ad un’altra classe
n Un’azione di una classeimplica un’azione diun’altra classe
n Le istanze di una classesono subordinate alleistanze di un’altra classe
Person Building
1..* 0..*
+owner
1..* 0..*
co-owner
EngineCar
1 1
aggregate class
1 1
EreditarietàPermette chen L’evoluzione del Software sia comparabile con
le precedenti versionin … ma non è sufficiente per garantire il riuso e
l’estendibilità
Si realizza attraverso i meccanismi din Estensione delle classin Specializzazione delle classin Combinazione delle classi
Ereditarietà (cont.)
Un ereden Offre i servizi dell’antenato
Del quale rappresenta un estensionen Offrendo nuovi servizi
E/O una specializzazionen Sfruttando le potenzialità definite dai servizi degli antenati e
ridefinendoli per il loro caso specifico (polimorfismo)
Object
PolygonPoint
RectangleTriangle
heir
superclass
subclass
Il valore dell’UMLn È uno standard aperton Supporta l’intero ciclo di sviluppo del
softwaren Supporta diverse aree di applicazionen É basato sull’esperienza e le necessità degli
utentin È supportato da molte applicazioni
Motivazione (cont.)Perchè una notazione con diagrammi multipli?n Obiettivo
n Coprire più aspetti di un sistema complesson Complessità
n Necessario per un’analisi e un design dettagliato
UML Modelli, Viste e DiagrammiUn diagramma è una vista in un modellon Rappresenta il sistema da una certa
prospettivan Fornisce una parziale rappresentazione del
sisteman É semanticamente consistente con le altre
viste
Una vista architetturaleUna vista architetturale è una descrizionesemplificata (un’astrazione) di un sisteman Da una particolare prospettivan Copre alcuni aspetti n Omette quelle entità che non sono rilevanti
per questa prospettiva
Conceptual Physical
Logical View
End-userFunctionality
Implementation View
ProgrammersSoftware management
Process View
PerformanceScalabilityThroughput
System integratorsDeployment View
System topologyDelivery, installation
Communication
System engineering
Use Case View
La visione del Software Architect
P. Kruchten, Nov. 1995The 4+1 View Model of ArchitectureIEEE Software
Quante viste?Le viste dovrebbero riguardare lo specificoconteston Non tutti i sistemi richiedono tutte le visten Un sistema può avere bisogno di viste
addizionalin Data view, security view, …
Use CaseDiagrams
CollaborationDiagrams
ComponentDiagrams
DeploymentDiagrams
ObjectDiagrams
StatechartDiagrams
SequenceDiagrams
ClassDiagrams
ActivityDiagrams
Models
Dynamic views
Static views
Modelli, Viste e Diagrammi
Diagrammi principali n Per la struttura
n Class diagramn Object diagram
n Per le interazionin Sequence diagramn Collaboration diagram
n Per gli Aspetti dinamicin State diagram
n Per gli Aspetti fisicin Component diagramn Deployment diagram
Alcuni Riferimentin Fowler, M., Scott, K., “UML distilled Second Edition –
a brief guide to the standard object modelinglanguage”, Addison-Wesley, 2000
n Stevens P., Pooley, R., “Using UML – Software Engineering with Objects and Components”, Addison-Wesley, 2001 (Updated Edition to UML 1.4)
n The Object Management Group UML Web page, on-line at http://www.omg.org/uml
n OMG, “OMG Unified Modeling Language Specification”, Version 1.4, Sep. 2001, on-line at http://www.omg.org/uml
n Jacobson, I., Booch, G., Rumbaugh, J., “The Unified Software Development Process”, Addison-Wesley, 1999.
n …
Classi e Instanze di classi
association instances(or links)
Student
IDName
matriculate()
Faculty
NameAthenaeum
open()11..n1..n 1
enrol
Class level
Instance level
association
Engineering
Architecture
Computer Science
Economics
X
X
Arts
XGalileo Galilei
Albert Einstein
Martin L. King
…
…
…
A quale livello appartengono i diagrammi
n Strutturan Class diagramn Object diagram
n Interazionin Sequence diagramn Collaboration diagram
n Aspetti dinamicin State diagram
n Aspetti fisicin Component diagramn Deployment diagram Class diagram Object diagram
State diagramComponent diagram
Deployment diagram
Sequence diagram
Collaboration diagram
Class level Instance level
Analisi e Specifica dei Requisitin Attività per l’analisi e la raccolta dei requisiti
n Studiare l’ambito di un’applicazionen Identificare i confini e le interazioni tra
l’applicazione e il mondo esternon Identificazione e comprensione dei requisiti
n Attività per la specifica dei requisitin Specifica dei requisiti (basati su cosa e non su
come)n Validazione/Verifica dei requisiti specificati
Analisi: Metodologien Nessun metodo scientificon Linee guida, principi generali e tecniche
empirichen Troppi
n Fattori soggettivi,n Fattori umani, en Problemi di comunicazione
Analisi: Linee Guidan L’analisi dovrebbe identificare
n Una rappresentazione delle informazioni piùsignificative
n Un modello del comportamento del softwaren L’analisi dovrebbe considerare come il
sisteman Sarà strutturato (dalla prospettiva utente)n Fornirà le funzionalità
n I sistemi complessi devono essere suddivisiin modo gerarchico:n L’analisi è eseguita separatamente sulle
differenti parti
Specifica: levelli di formalismoSpecifica Informalen Basata sul linguaggio naturale (ambiguo)
Specifica Formalen Basata sul linguaggio matematico
Specifica mista (Semi-formale)n Composta da una parte formale e una
informale
Specifica: stili per il comportamentoOperazionalen Specifica le proceduren Esempio: La lista B è ottenuta dalla lista A
muovendo il più piccolo elemento di A nellaprima posizione di B, il nuovo più piccolo elemento di A nella seconda posizione di B, e procedendo in questo modo finché la lista A è vuota.
Descrittivon Specifica le proprietàn Esempio: la lista B è una permutazione
ordinata della lista A
Use Case Diagramn Notazione semi-formalen Specifica le interazioni tra il sistema e il
mondo esternon Utile per
n Obbligare l’analista ad esprimere dei confiniben definiti tra il sistema e il mondo esterno
n Organizzare le funzioni del sistema in elementi (use cases) sui quali focalizzarel’attenzione
n Fornire una prima base per la specifica dellastruttura del sistema dal punto di vista dell’utente
Elementi di un Use Case Diagramn Qualcuno (utente) o qualcosa (sistema
esterno, hardware) chen Scambia informazioni con il sisteman Fornisce input al sistema, o riceve output
dal sistema
n Un’unità funzionale (funzionalità) parte del sistema
Actor
Use Case
Relazioni tra Use Cases
Usage. Modella il fatto che unafunzionalità selezionata è usata nelcontesto di un’altra funzionalità (unaè la fase dell’altra)
Generalization. Definisce una funzionalità come un’estensione diun’altra già esistente (special case)
Interaction. Determina:– Quali attori participano in un use
case– Dove l’esecuzione inizia
<<include>>
ActorUse Case
ActorUse Case
Use Case B
Use Case B
Use Case A
Use Case A
Esempio: Corsi on linen All’inzio del semestre la segreteria deve fornire agli studenti la
lista dei corsi disponibili attraverso un sistema di registrazioneon line.
n Ogni studente deve selezionare 4 corsi disponibili ed esprimeredue possibili alternative.
n Ogni corso deve avere tra 3 e 20 studenti: corsi con meno di 3 studenti sono cancellati, e quelli con più di 20 sono suddivisi.
n All’inzio i professori accedono al sistema per inserire i loro corsinella lista, in seguito alle selezioni degli studenti loro accedonoper controllare lo stato degli studenti.
n Dopo il periodo di selezione, il sistema crea le liste definitive, risolvendo tutte le anomalie e le manda all’ufficio amministrativoche procede alla tassazione di ogni studente.
n Gli studenti accedono al sistema per vedere la lista dei loro corsin Tutte le interazioni utente sono autenticate
Esempio: Corsi on line
Administrative Office
Students
Request Course List
Course Selection Request Students List
User Authentication<<include>>
Professor
Insert Course
<<include>>
<<include>><<include>>
Altro esempio
Customer
Check availability
Hotel Booking
Acquire Customer data
Hotel Booking guaranteed by Credit Card
Acquire Credit Card data
<<include>>
<<include>>
<<include>>
Cosa è un Class DiagramUn Class Diagram descriven I tipi degli oggetti nel sisteman I tipi di relazioni statiche tra di loro
Disegniamo i Class Diagrams sotto tre diverse prospettiven Concettuale
n Indipendente dal softwaren Indipendente dal linguaggio
n Specificazionen Focalizzati sull’interfacce del software
n Implementazionen Focalizzati sull’implementazione del software
Class …
Window
- visible- position- size
+ resize()+ display()+ hide()+ move()
Class Name
Attributes
Operations
private
public
ClassNamepublicState : UserDef = testedprivateAuthor : UserDef = pam
ProtectedOp(argname) : return
<<stereotype>>
ClassInterface A<<Interface>>
ClassInterface B<<Interface>>
Class ...n Sintassi degli attributiattrName : attrType = initialValue
n Sintassi delle operazioniVisibility opName (argName:argType=DefaultValue,
…):returnType
Associazionin Relazioni strutturali tra classi di oggettin Cardinalità delle associazioni
n 1, 0..1, M..N, *, 0..*, 1..*n Tipo di relazione
n binaria, ternaria, N-aria
Notazione per la cardinalità
nEsattamente n
*Zero o più
0..1Zero o uno (opzionale)
m..nTra m e n (inclusi)
m..* Da m in su
Associazioni binarie
Appello
-data-materia-elencoStudenti
+stampa()+prenotaStudente()
+stampa()
-nome-cognome-matricola
DataAppello
+stampa()
-giorno-mese-anno
Studente Corso
+stampa()
-materia-docentefrequenta 43..10 *
Nomedella relazione
Si-svolge-il 4* 1
Molteplicità
+frequentante +frequentato
Ruoli
“Use” Association …n Due classi sono in USE association (B usa A)
se le istanze di B possono mandare messaggialle istanze di A
n Un oggetto usa un altro oggetto se è capacedi mandargli dei messaggi
Company Personhiring
+Candidate+Employer
+apply() +interview()0..1 1..*
+seekJob()-planInterviews()
Nomi nelle associazioni
Subscription
User Profile
Terminal-Address+Type
Service Profile+userPreferences
Service
+startService()1..*1..*
supportsdefault
1
0..*
1
0..*
constraints
User
1..*
0..*
1..*
registration
0..*
1
0..*
1
user service information
1
1
1
1
userInformation
0..*
0..*
0..*
0..*
subscription
AggregationModellare il sistema di prenotazione agli appelli dei corsi.n Ogni appello include una data composta da
giorno, mese, anno, ed è associato ad un corso.
n Dietro richiesta, si può iscrivere all’appello uno studente.
n Il sistema permette inoltre din Spostare la data dell’appellon Stampare le informazioni di ogni oggetto
Aggregation
Appello
+stampa()+gestionePrenotaz()+sposta()
+stampa()+iscrivi()
-nome-cognome-matricola
Data Appello
+stampa()+cambiaStato()
-giorno-mese-anno
Studente
Corso
+stampa()
-materia-docente
* 1
*
*
1
*
- listaPrenotati- aula
Generalizationn Relazione di classificazione tra un elemento
generale e un elemento più specificon Ereditarietà nella programmazione ad oggetti
n Construire una classe da un’altran Codividere attributi, operazioni e vincoli
Specializzazione pura
+refresh()
-image
Image Window
+resize()+move()+close()
-title-position-size
Window
+replaceText()+deleteText()
Text Window
Generalizationassociation
Base class(superclass)
Derived classes(subclasses)
-text
“inherits from”“derives from”
“is a”
Esempio: Gerarchia di classiCostruire le associazioni di ereditarietà tra i seguentioggetti:n Esseri Viventin Esseri Umanin Fiorin Animalin Vegetalin Commercianten Fioraion Cliente
Suggerimenton Raggruppare gli elementi in insiemi di classificazione
e in seguito costruire la gerarchia di“generalizzazione”
Esempio: Gerarchia di classi
Animale
Commerciante
Essere Vivente
Vegetale
Fiore
Essere Umano
Fioraio
Cliente
Specializzazione inpuraVogliamo definire eccezioni al meccanismo dellaspecializzazionen Overriding
n Modificare proprietà ereditaten Di solito per l’implementazione di operazioni
(metodi)
Overriding
+print()
-ID
Student
+print()
-name-surname
Person
+print()
-qualification-salary
Employee
Ereditarietà multiplan Una classe deriva da una serie di superclassin Non tutti i linguaggi di programmazione la
supportano
Quando si usano i Class Diagrams
n Si usano sempren Sono alla base di tutti i metodi Object
Oriented n Sono alla base per i generatori di codice
n La prospettiva di riferimento èn Modello concettuale durante la raccolta dei
requisitin Modello di specifica durante il designn Modelli di implementazioni per linguaggi
specifici
Quando si usano i Class Diagrams(cont.)
n Non disegnare modelli per qualsiasi cosan Focalizzarsi sugli aspetti principali
n Non specificare troppi dettagli in una faseprematura
Object Diagramsn Un object diagram mostra le istanze delle
classi e i collegamenti tra di loron Un object diagram è un’istantanea degli
oggetti nel sisteman In uno specifico momenton Con uno specifico obiettivo
n Interazioni – Sequence Diagramn Scambio di messaggi – Collaboration
diagramn Operazioni – Deployment diagram
Un Oggetto …
M1: Menu window
visible=trueposition=(10,23)size=160
ID label : Class Name
Attribute values
Interazioni tra oggettin Un oggetto interagisce con un altro oggetto
inviando un messaggio: per esempio, unarichiesta per eseguire un’operazione + unaserie di parametri
n La ricezione del messaggio causa la selezionee l’esecuzione dell’operazione
n Regola basen Delegare ad altri oggetti le operazioni che essi
sono capaci di compieren Risultati
n Buon disaccoppiamento tra oggettin Semplicitàn Riutilizzo
Esempio: registrazione per un esame
Jan: Appello
datamateriaelencoStudenti
nomecognomematricola
D1:DataAppello
giornomeseanno
SoftEng: Corso
nomecodice
1: Studente
nomecognomematricola
N-1:Studente
nomecognomematricola
N Studente
stampa
stampa
stampa
stampa
Specifica del comportamento1)Si analizzano e descrivono gli scenari principalidelle operazioni del sisteman Sequence diagramsn Viste parziali
2)Ci si concentra in ogni classe e si specifica ilsuo comportamenton Tutti i coportamenti previsti e quelli critici
Diagrammi di interazioneSono diagrammi semi-formali che descrivonoscenari di esempio per le operazioni del sistema, in termini din Oggetti e attorin Messaggi scambiati e in quale ordine
temporale (sequenza)Si suddividono in n Sequence Diagramsn Collaboration Diagrams
Non sono sempre sufficienti per tenere in considerazione tutti i possibili comportamenti
Sequence Diagram
: Professor:course options
form:course form :course co1:course offering
1: add a course
2: display
3: select course offering
4: add professor (professor id)
5: get professor (professor id)
6: add professor (professor)
Object
lifeline
Instantiated class Actor(*)
(*) Dagli Use Case Diagrams per modellare le entità esterne
Sequencenumber
Sequence Diagram (cont.)Modi di utilizzon Documentazione degli use casesn Più vicini all’utente
n Non molto dettagliatin Frecce: eventi che possono accaderen Nessuna differenza tra flusso di controllo e flusso dati
n Strumento di sviluppon Rappresentazione accurata delle interazioni tra gli
oggettin Frecce: messaggi trasmessi
n Chiamate di procedure, eventi discreti, segnalin Sincroni o asincroni
•Cancella•Ritorno
•implicito•esplicito
•Ricorsione
•Vincoli temporali
•Pseudo-codice
•Condizioni di iterazione (direttamente nel messaggio)
X
{t’-t < 2s}
while x loop
*[X]
Formato dei messaggi
:A :B :C
1: Sync
3: Asynch
4: Reflexive
2: Activate
Esempio: generatore di allarmiSpecificare il comportamento a livello classe, per il seguente sisteman Un sistema di allarme basato su un sensore
genera eventin Mostra l’allarme sul pannello di controllo
(visibile all’utente) n Attiva un trasmettitore acusticon Manda un segnale al servizio di monitoraggio
Soluzione
: Sensor : Event : User : Acoustic Transmitter
: Monitoring Service
: Control Panel
display display
ring
signal
Esempio: configurazionedell’utente
: User : Control Panel : System : Sensordefine password
"Type password now"
[password]
"Retype password"
[password]
set password
configure Sensors (N)get Next Sensor
[ref]set Data
[sensor ID, Tel. Number]
set Data
while N loop
Collaboration DiagramsDescrive le interazioni tra oggetti, vengonoespressin Il contesto per un gruppo di oggetti (oggetti e
collegamenti)n L’interazione tra gli oggetti
2 : Elevator
: Cabin : Door
: Light
1: Go up
3: Close
2: Turn on
: Sensor
: Event
: User
: Acoustic Transmitter
: Monitoring Service
: Control Panel
1:
9:
2: display
4:
5: ring
6:
7: signal8:
3: display
Esempio: generatore di allarmi
ConfrontoSequence diagramsn Enfasi sulla sequenza
Collaboration diagramsn Enfasi sui collegamenti
statici tra gli oggetti
Entrambin Semplicità e Comunicazionen Non adatti a modellare le possibili scelte alternative
Quando usare i diagrammi diinterazione
Sin Per analizzare il comportamento di oggetti multipli in
un use case comunen Per mostrare la collaborazione tra oggetti
Non Per fornire un’esatta descrizione delle interazionin Per analizzare il comportamento di un singolo oggetto
in use cases multiplin State diagram
n Per analizzare il comportamento su use case o flussidi esecuzione multiplin Activity diagram