Software EngineeringSoftware Engineering

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 %

Il ciclo di vita del softwareIl ciclo di vita del software

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

Paradigma object-orientedParadigma object-oriented

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

Unified Modeling LanguageUnified Modeling Language

MotivazionePerchè una notazione unificata?n Potenza espressivan Completezzan Consistenza

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

Use Case DiagramUse Case Diagram

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: tipin Specifica dei dati (vista statica)n Specifica del comportamento (vista dinamica)

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>>

Class diagramsClass diagrams

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 DiagramsObject Diagrams

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

Oggetti e collegamenti

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

Interazioni tra oggettiInterazioni tra oggetti

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 DiagramsSequence Diagrams

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 DiagramsCollaboration Diagrams

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