corso di ingegneria del softwareingsoft1/lezioni2008-2009/versionipdf/bl… · ingegneria del...

Corso di Ingegneria del Software

Paolo Bottoni

Blocco 5: Modellazione di sistema e UML

Blocco5ModelingIngegneria del Software 22

Obiettivi

• Introdurre tipi di modelli di sistema

• Descrivere modellazione comportamentale,

di dati, a oggetti

• Introdurre alcune notazioni usate in Unified

Modeling Language (UML)

3

Modellazione di sistema

• Aiuta analista a capire funzionalità sistema e

comunicare con clienti

• Modelli diversi presentano sistema da

prospettive diverse

– esterna mostra contesto o ambiente sistema

– dinamica mostra comportamento sistema

– strutturale mostra architettura sistema o dati

Ingegneria del Software Blocco5Modeling

4

Tipi di modello

• Modello di elaborazione dati: flussi e fonti

• Modello di composizione: struttura entità

• Modello architetturale: sottosistemi principali e

meccanismismi di comunicazione

• Modello di classificazione: caratteristiche comuni entità

• Modello dinamico: comportamenti

– Autonomi

– Reattivi

– Collaborativi


5

Metodi strutturati

• Metodi strutturati incorporano modellazione di

sistema come parte inerente metodo

• Definiscono:

– insieme di modelli

– processo per derivarli

– regole e linee-guida da applicare a modelli

• Strumenti CASE supportano modellazione di

sistema come parte di metodo strutturato


6

Debolezze dei metodi

• Non modellano requisiti di sistema non-funzionali

• Solitamente non includono informazione su

appropriatezza metodo a dato problema

• Possono richiedere troppa documentazione

• Modelli sistema a volte troppo dettagliati e difficili

da capire per utenti


7

Modelli di contesto

• Illustrano contesto operativo sistema

– Cosa si trova fuori confini sistema

• Definizione confini influenzata da aspetti

sociali e organizzativi

• Modelli architetturali mostrano sistema e

relazioni con altri sistemi

• In UML forniti da casi d’uso


88

Contesto di sistema Bancomat

Sistema distributore

automatico

Sistema di

sicurezza

Sistema di

manutenzione

Base dati conti

clienti

Base dati

utilizzo

Sistema tenuta

conti agenzia

Sistema

sportello

agenzia


Diagramma UC per modello di contesto

Ingegneria del Software 9Blocco5Modeling

1010

Modello dei Casi d'Uso

• Modello di sistema con attori, casi d'uso e loro relazioni.• Può utilizzare package.• Utilizzabile anche per descrivere contesto sistema (attori)


1111

Attore (umano, dispositivo, sistema)

• Definisce ruolo

• Cosa farà in processo


1212

Descrizione di Caso d’uso I• Fatta dal punto di vista degli attori

• Specifica di insieme di azioni eseguite da sistema – (o elemento che può avere comportamento, subject)

• Produce risultato osservabile– Tipicamente risultato ha valore per uno o più attori / stakeholder di subject

• Rappresenta dichiarazione di comportamento offerto– Comportamento svolto in collaborazione con uno o più attori

– Può includere varianti, comportamenti eccezionali, gestione errori

– Risultato: cambiamento stato subject e/o comunicazione con ambiente

• Specifica unità di funzionalità utile offerta agli utenti– Iniziata da attore primario

– Deve essere completata• Non ci si aspettano altri ingressi

• Caso d’uso può ricominciare da capo o in stato di errore


Descrizione di Caso d’uso II

• Comportamento

– Solitamente in linguaggio naturale

– Uso di diagrammi statechart, activity, collaboration, sequence

• Descrizione di sequenza di azioni

– Azioni di subject durante esecuzione caso d'uso

– Interazioni con attori

• Comportamento richiede pre-, asserisce post-condizioni.

– Di subject, non di situazione!

• Casi d'uso sono atomici. Non interagiscono.

• Ogni caso d’uso descrive uso completo subject

13Ingegneria del Software Blocco5Modeling

14

Specifica comportamento in caso d’uso

• Diagrammi di interazione

• Diagrammi di attività

• Diagrammi di stato

• Pre e post-condizioni

• Testo in linguaggio naturale (strutturato)

• Descrizione indiretta tramite collaborazioni

• Descrizioni possono essere combinate

– Non necessarie tutte

– Non necessariamente alternative


1515

Cosa includere in una descrizione

• Stato di partenza come precondizione

– Precondizioni per esecuzione

– Precondizioni per successo

• Come e quando parte (trigger)

• Ordine di esecuzione azioni

• Come e quando finisce

• Possibili stati finali come postcondizioni

• Cammini di esecuzione non permessi

• Flussi alternativi inlined in flusso base

• Flussi alternativi estratti

• Interazioni con attori e messaggi scambiati

• Uso di oggetti, valori e risorse in sistema

• Separare responsabilità fra sistema e attore


Espressione requisiti a livello utente

• Pre-condizioni: stato che permette attivazione

• Asserzioni: stato che garantisce successo

– Possono essere verificate durante esecuzione

• Post-condizioni: stato a termine flusso

• Flussi alternativi: quando rilevanti

• Descrizione obiettivo caso d’uso


Espressione requisiti a livello sistema

• Raffinare pre-, post-condizioni e asserzioni

in relazione a sistema

• Descrivere completamente flusso eventi

• Indicare origine eventi e dati

• Completare descrizione flussi alternativi


Specifica testuale del flusso


Pre e post-condizioni

Ingegneria del Software 19

NON: L’utente vuole leggere un’area

NON: L’utente ha

letto l’area

Assunzione verificabile SOLO durante il corso del flusso

Blocco5Modeling

2020

Relazioni fra attori e casi d’uso


Raffinamento: include

• Caso d’uso includente contiene comportamento

definito in caso d’uso di addizione

• Usata quando ci sono parti comuni a due o più casi

d’uso. Parte comune estratta e riutilizzabile

• Caso d’uso includente incompleto senza addizione

• Comportamento addizione eseguito in locazione

caso d’uso includente

– Terminata addizione riprende esecuzione includente


Raffinamento: extend

• Specifica condizione per inserimento

comportamento che estende in caso d’uso esteso

• Estensione avviene in specifici punti di estensione

definiti in caso d’uso esteso

• Caso d’uso esteso indipendente da estensioni

• Caso che estende definisce comportamento

modulare eseguito in specifiche condizioni

• Comportamento può estendere più casi d’uso

• Può essere esteso a sua volta


2323

Differenza fra include e extend

• include indica frammento sempre eseguito

durante esecuzione caso d’uso principale

• extend indica frammento eseguito in

determinate circostanze


24

Distribuzione casi d’uso in package


Casi d'uso essenziali

• Formato a due colonne

– Intenzione attore

– Responsabilità sistema

• Indipendenti da tecnologia

• Nessun riferimento a interfaccia utente


Esempio di caso d'uso essenziale


Esempio di caso d'uso di sistema


Processi

• Casi d’uso rilevanti per processi

– Scenari, user stories

– Processi svolti da attori e elementi di sistema

• Processi + dati sistema

Ingegneria del Software I 28

29

Modelli dei dati semantici

• Struttura logica dati elaborati

• Modello a entità-relazioni-attributi

• Usato in progetto basi dati

– Implementato rapidamente con basi di dati relazionali

• Esprimibili in UML con diagrammi di classi


30

Dizionari di dati

• Liste nomi usati in modelli sistema

– Includono descrizioni entità, relazioni, attributi

• Vantaggi

– Supporta gestione nomi ed evita duplicati

– Memorizza conoscenza organizzazione per

collegare analisi, progetto e implementazione

• Molti strumenti CASE supportano dizionari


31

Elementi nel dizionario dei dati

Name Description Type Date

ArticleDetails of the published article that may be ordered bypeople using LIBSYS.

Entity 30.12.2002

authorsThe names of the authors of the article who may be duea share of the fee.

Attribute 30.12.2002

BuyerThe person or organisation that orders a co py of thearticle.

Entity 30.12.2002

fee-payable-to

A 1:1 relationship between Article and the Copyright

Agency who should be paid the copyright fee.Relation 29.12.2002

Address(Buyer)

The address of the buyer. This is used to any paperbilling information that is required.

Attribute 31.12.2002


32

Elementi di modellazione delle classi

• Classi definiscono modello per costruzione istanze

– Struttura

– Interfaccia

– Vincoli su implementazione

• Diagramma classi definisce famiglia di modelli

– Relazioni fra classi

• Associazioni, dipendenze, generalizzazioni

– Vincoli su realizzazioni

• Molteplicità

• Vincoli da metamodello

• Vincoli specifici


33

Classe

• Descrive insieme di oggetti con stessa specifica

di caratteristiche, vincoli e semantica

• Ogni oggetto deve contenere valore per ogni

attributo classe, in accordo con tipo e molteplicità

• Se attributo ha default, se istanza non riceve

valore iniziale per attributo, inizializzato a default

• Operazioni classe invocabili su oggetto, insieme

di sostituzioni per parametri

• Caratteristiche sono di istanza o di classe


34

Associazioni

• Dichiara possibile presenza collegamenti fra

istanze tipi in associazione

• Relazione semantica possibile tra istanze tipate

• Almeno due capi, rappresentati da proprietà,

ognuna connessa a tipo

• Possibili più capi con stesso tipo

– Capi possono essere dichiarati unici e ordinati

• Capi posseduti da associazione o classificatore.

– Se posseduto da classificatore, navigabile


3535

Diagrammi di classi

Ingegneria del Software

Diagramma rappresenta vista su modello

AccountPerson owner

Blocco5Modeling

36

Specifica di istanza

• Rappresentazione entità a un istante (snapshot)

– Specificare esistenza di entità in sistema

– Esempio di possibile entità in sistema

• Entità conforme a specifica di classificatore

– Attributi in classificatori rappresentati da slot in istanza

• Dettagli specifica possono essere incompleti

Parti trascurate non di interesse in modello

• Modello cambiamenti:specifica per ogni snapshot

• Istanze hanno:

– identità e stato

– comportamento vincolato da appartenenza a classeIngegneria del Software Blocco5Modeling

37

Collegamenti (link)

• Specifica di istanza di associazione

• Tupla con valore per capo associazione

– Ogni valore istanza tipo per capo

• Possono rappresentare valori di attributi,

navigabili da istanza che possiede attributo

a istanza che rappresenta valore

– Decorati con nome attributo

• Connessione semantica fra due oggetti che

permette accesso efficiente


38

Diagrammi di istanza validi e non validi


Assunzione che diagramma classi

precedente sia unica specifica

39

Diagrammi di istanza validi e non validi

jim : Person

name = ’’Jim Arlow’’

age = 23


4040

Decorazioni su associazioni

Orientamento: semantica per utente, opzionaleNavigabilità: semantica per sistema, obbligatoria o implicitaMolteplicità: forma di vincolo, non implicita


Classi d'associazione

• Elemento con proprietà di classe e di associazione

– Relazione semantica fra classificatori

– Caratteristiche proprie relazione, non di classificatori

• Insieme di oggetti implicati da classe e corrispondenti

a unico link con tipo associazione

– Corrispondenza 1-1con relazione semantica fra istanze

• Semantica statica/dinamica di associazione e classe


42

Istanze di classe di associazione


43

Associazioni riflessive


44

Relazione di generalizzazione

• Relazione tassonomica fra classificatori

– Classificatore più generale e classificatore più specifico

• Istanza di specifico istanza indiretta di generale

• Specifico eredita caratteristiche di generale

– Vincoli e associazioni

• Proprietà di sostituibilità

• Classificatore può partecipare a più relazioni sia

come sorgente sia come bersaglio


45

Relazione di Generalizzazione


46

Ereditarietà multipla

• Caratteristica può essere ripetuta in diversi

classificatori da cui si eredita

– Stessa proprietà statica o di istanza

• Per ogni slot in istanza deve esistere classificatore

con attributo corrispondente

• Per ogni attributo di classificatore (eventualmente

ripetuto), al più uno slot definito da esso in istanza


4747

Dipendenze

• Relazione fra elementi.

– Semantica, non strutturale.

• Elemento (cliente) ha bisogno di altri elementi

(fornitore) per specifica o implementazione

• Semantica clienti dipende da definizione fornitori

• Non ha conseguenze su semantica a run-time


4848

Tipi di dipendenza

• Usage:

– Definizione o implementazione cliente usa fornitore

• Abstraction:

– Fornitore più astratto di cliente

• Permission:

– Forme di accesso a contenuto fornitore

• Binding:

– Specializzazioni di template


4949

Dipendenze Usage

• <<use>>

– Operazione client usa parametro fornitore

– Operazione client restituisce tipo fornitore

– Operazione client usa tipo fornitore per implementazione• non come attributo

• <<call>>

– Client e fornitore sono operazioni. Prima invoca seconda

• <<send>>

– Fornitore di tipo signal, spedito da client

• <<create>>– Client è operazione che crea istanze fornitore

• <<instantiate>>

– Client è classificatore, contiene operazione che istanzia fornitore


5050

Dipendenze Abstraction

• <<trace>>

– Fornitore e client in modelli in fasi o flussi di lavoro diversi

• <<refine>>

– Tra elementi di stesso modello, non storica

• <<derive>>

– Informazione cliente derivabile da informazione fornitore


5151

Dipendenze Permission

• <<access>>

– Package client vede elementi pubblici package fornitore

– Namespace restano separati

• <<import>>

– Namespace fornitore fuso in namespace cliente

• <<friend>>

– Accesso a elemento fornitore, indipendentemente da visibilità


5252

Notazione


53

Aggregazione

• Relazione parte_di

• Intero domina.

• Se navigabilità unidirezionale, parte può non conoscere intero

• Aggregato può esistere indipendentemente da parti

• Parti possono esistere indipendentemente da aggregato

• Aggregato incompleto se parti mancanti

• Parti possono essere condivise fra aggregati


54

Vincoli su aggregazione

• Transitività

• Asimmetria (oggetto non può essere parte

di sé stesso, neanche indirettamente)


55

Gestione di aggregazioni riflessive

Product

*

*

a:Product

b:Product c:Product

d:Product

Product

*

*

a:Product

b:Product c:Product

d:Product

Trasformare in associazione


56

Composizione

• Analogo ad aggregazione, ma più vincolato

• Parti non hanno vita indipendente

• In ogni momento parte appartiene esattamente a un composto

• Composto ha responsabilità per creazione / distruzione parti

• Creazione composto comporta creazione parti

• Parti possono essere rilasciate solo verso altro composto

• Se composto è distrutto, deve distruggere sue parti, o cederne responsabilità ad altro composto


5757

Diagrammi di interazione

• Descrivono collaborazioni necessarie a

realizzare caso d’uso

• Descrivono ordine invio messaggi in scenario

• Rappresentano specifico insieme di messaggi

e interazioni tra oggetti


58

Modelli comportamentali

• Descrivono comportamento generale sistema

• Due tipi:

– Elaborazione dati.

• Mostrano come dati sono elaborati e fluiscono in sistema

• Per estensione anche flusso di controllo

– Macchine a stati. Mostrano risposte sistema ad eventi

• Prospettive diverse, necessarie entrambe

• In UML elaborazione dati come conseguenza

scambio messaggi, in diagrammi di interazione


Interazioni

• Unità di comportamento

– Focalizzata su scambio osservabile informazione

– Informazione scambiata fra elementi

• Composte di frammenti di interazione

• Semantica data da coppia di insiemi di tracce

– Sequenza di occorrenze di eventi

– Tracce valide e non valide

• Rappresentazioni: comunicazione e sequenza


• Mettono in luce scambio di messaggi su linee di vita

• Specifiche di esecuzione ordinate su linee di vita

• Pieno uso di costrutti composti

Diagrammi di sequenza


Esempio: visualizza info paziente Mentcare


Esempio:

trasferimento

dati


Sintassi

63

Notazione alternativa per frammento

parallelo se ordine occorrenze irrilevante

Comunicazione

tramite gate


Definizione di interazione


Usi di interazione


Costrutti temporali


• Durata messaggio Code misurata

• Vincolo su ricezione OK dipendente da osservazione

• Vincolo su durata emissione carta

• Vincolo su completamento emissione

• Primitiva now fornisce osservazione temporale

Occorrenze annotate con vincoli


Regioni critiche

68

r100 s100

r101 s101

r911 s911

r100 r911

s911 r101

s101 s100

r100 r911

s100 s911


• Vincolo su tracce

– Non si ammettono altre occorrenze

– Regione trattata atomicamente da frammento includente

• Limita effetto parallelismo

Regione critica


Iterazioni

70

Annidamento di loop

Regione interna iterata a

ogni iterazione regione includente


71

Modelli di elaborazione dati

• Diagrammi di flusso di dati modellano

elaborazione dati in sistema

• Mostrano passi di elaborazione mentre dati

fluiscono in sistema

• Parte intrinseca di molti metodi di analisi

• Notazione semplice e intuitiva per clienti

• Mostra elaborazione dati da inizio a fine


72

Diagrammi di flusso dei dati

• Prospettiva funzionale

• Tracciano associazione dati/processi

• Sviluppano comprensione generale sistema

• DFD anche usati per mostrare scambio di dati

fra sistema e altri sistemi in contesto

• Notazione ausiliaria in UML

– Rappresentazione flusso informazione fra elementi


73

DFD per pompa a insulina

Calcolo richiesta

insulina

Analisi zucchero

in sangue

Sensore zucchero

in sangue

Controllore

rilascio insulina

SangueParametri

sangue

Livello zucchero in

sangue

Insulina

Comandi

controllo

pompa Richiesta insulina

Ingegneria del Software

Pompa insulina

Blocco5Modeling

74

Modelli di macchine a stati

• Comportamento sistema in risposta a eventi

– Eventi esterni o interni

– Spesso usati per sistemi a tempo reale

• Stati nodi, transizioni su eventi archi fra nodi

– Quando evento accade, sistema transisce di stato

• Statecharts parte integrale di UML

– Rappresentano modelli di macchina a stato

– Condizioni associabili a transizioni


• Modelli di comportamento discreto con stati finiti

• Behavioral state machines: variante Statecharts

– Associate a elementi di modello

• Comportamenti di classi attive, oparazioni, processi

• Protocol state machines: transizioni di stato

– Associabili a classificatori, interfacce porte

– Definisce aspetti comportamentali invocabili in stato

• Comportamento modellato come attraversamento di

grafo di nodi stato interconnessi da archi di

transizione, attivati da occorrenze di eventi

Macchine a stati


• Può essere posseduta da BehavioredClassifier

• Definisce trigger e attributi e operazioni disponibili

– Trigger dipendono da operazioni e ricezioni in contesto

• Può essere associata a BehavioralFeature

– Rappresenta metodo

– Parametri macchina corrispondono a parametri feature

• Se manca classificatore contesto, trigger indipendenti

– Può definire template per macchine a stati

• Punti di connessione solo a stati iniziali o di uscita

Macchina a stati


• Eventi presenti in pool

– Legata a istanza di classificatore o a classificatore che

possiede la BehavioralFeature

• Occorrenze eventi gestite una alla volta

• Elaborazione run-to-completion

– Evento gestito solo se gestione precedente completata

– Stato stabile: reazione a eventi completata

– Se invocazione sincrona, completamento a fine esecuzione

• Evento estratto scartato se transizioni non abilitate

– Possibilità di eventi differiti

Semantica


• Trigger: occorrenza evento interno o esterno

• Guard: condizione booleana valutata prima

• Effect: comportamento associato

• Sequenza di esecuzione

– Uscita da stato sorgente principale

– Esecuzione ordinata comportamenti associati a transizioni

– Se si incontra decisione, selezione dinamica cammino

– Entrata in stato bersaglio principale

• Tipi di transizione

– local: parte da punto di ingresso o stato composto e resta

– external: originabile a qualunque vertice, uscirà da vertice

– internal: origine e bersaglio nello stesso stato

Transizioni


• Parte ortogonale di stato composto o statemachine

– Possesso esclusivo stato o macchina a stati

• Contiene stati e transizioni

• Può avere al più un vertice iniziale

• Contiene vertici e transizioni fra vertici

– Transizioni composte per risposte complete a eventi

• Possono attraversare fork, join, choice, merge o junction

– Hanno trigger, guardia e comportamento associato

– Transizione abilitata se:

• Tutti stati sorgente in configurazione di stato attiva

• Uno dei trigger è soddisfatto da tipo occorrenza evento corrente

• Esiste almeno un cammino da configurazione sorgente a bersaglio

Regioni


• entry: eseguita a ogni ingresso in stato– Atomica. Nessun altro comportamento eseguibile prima

• exit: eseguita ad ogni uscita da stato– Solo dopo ogni transizione in stato completata

• do: iniziata eseguita fino a che si permane in stato, o fino a completamento, primo dei due. – Produce evento di completamento

• Trigger differiti. Mantenuti da macchina se non attivano transizione esterna, fino a che non si raggiunge configurazione in cui non più differito

Comportamenti


Sintassi grafica


8282

Segnali

• Pacchetto di informazione comunicato

asincronamente fra due oggetti

• Evento di segnale avviene quando oggetto

riceve segnale

• Invio

• Ricezione

oggetto:Bersaglio


• Modellano situazioni in cui vale invariante

– Statica: es. attesa di evento.

– Dinamica: es. esecuzione di processo

• Stato semplice non ha regioni

• Stato composto: una o più regioni (ortogonali)

– Regioni hanno insiemi di vertici mutuamente esclusivi

– Ogni regione può avere stato finale e pseudostato iniziale

– Transizione a stato esterno è verso pseudostato iniziale

– Ogni sottostato eredita transizioni stato genitore

• Se conflitto, priorità transizione da stato annidato.

Stati


Diagramma di stato per operazioni forno

Blocco5ModelingIngegneria del Software 84

Stati composti

85Blocco5ModelingIngegneria del Software

Transizioni locali e esterne

86

Non provocano azioni di ingresso /

uscita per stato composto

Provocano azioni di ingresso / uscita


Stati composti concorrenti

(from [3])87Ingegneria del Software Blocco5Modeling

• Inserimento specifica di macchina a stati

• Permette fattorizzazione e riuso di

comportamenti comuni

• Stessa sottomacchina può occorrere più volte

• Equivalente a stato composto

Stati di sottomacchina


Sottomacchine


Riferimento a sottomacchine


• initial - transizione a stato default per regione

– Può avere effetto, ma non trigger o guard

• deepHistory - configurazione più recente composto

• shallowHistory - sottostato attivo più recente

• join – fonde transizioni da vertici ortogonali

• fork – divide transizione per vertici ortogonali

• junction – concatena transizioni multiple

– Merge - fonde transizioni che convergono su un cammino

– Branch - divide transizione in casi (statico)

• choice – valutazione dinamica, un solo selezionato

Pseudostati I


• entry point – punto di ingresso a stato composto.

Indica transizione a un vertice

• exit point – fa uscire da macchina o stato

composto. Attiva azione di exit

• terminate – esecuzione da parte di oggetto

contesto terminata. Non si compiono altre azioni

Pseudostati II


93

Modelli di processo

• Mostrano processo generale e processi

supportati da sistema

• Modelli flusso dati usati per mostrare

processi e flussi di informazione.

• In UML supportati da modelli di attività


94

Processo di acquisizione equipaggiamento

Get cost

estimates

Accept

delivery of

equipment

Check

delivered

items

Validate

specification

Specify

equipment

required

Choose

supplier

Place

equipment

order

Install

equipment

Find

suppliersSupplier

database

Accept

delivered

equipment

Equipment

database

Equipment

spec.

Checked

spec.

Delivery

note

Delivery

note

Order

notification

Installation

instructions

Installation

acceptance

Equipment

details

Checked and

signed order form

Order

details plus

blank order

form

Spec. +

supplier +

estimate

Supplier list

Equipment

spec.


Diagrammi di attività

• Modellano processo come collezione di attività e

transizioni fra attività.

• Enfasi su sequenza e condizioni coordinamento

comportamenti di basso livello, non su classificatori.• Flusso di controllo e flusso di oggetti

• In ultima analisi definita da azioni

– Azioni e attività vengono eseguite

• Condizioni di coordinamento per inizio azioni

– Completamento esecuzione azioni

– Disponibilità di oggetti e dati

– Eventi esterni


Livelli di complessità

• Attività fondamentali definite come sequenze

• Costrutti per parallelismo e scelte alternative

• Strutture di controllo iterative

• Costrutti per flussi di dati, eccezioni, etc.


Relazioni fra attività e azioni• Attività con nodi di attività e flussi di controllo e di dati

• Nodi di attività

– Nodi oggetto

– Nodi di esecuzione

– Nodi di controllo

• Attività possono formare gerarchie di attivazioni

• In modelli OO invocate indirettamente come metodi

legate a operazioni invocate direttamente

• Possono descrivere computazioni procedurali

• Attività non può essere autonoma

– Contesto: classificatore o feature comportamentale


Semantica attività

• Basata su flusso di token

• Dipendenza fra esecuzioni di nodi rappresentata da

archi fra nodi.

• Token contiene un oggetto, dato, o luogo di

controllo, presente in diagramma a nodo particolare

• Tutti token distinti fra loro, anche se stesso valore

• Nodo comincia esecuzione quando condizioni su

token di input soddisfatte


Flusso token

• Quando nodo inizia esecuzione, token accettati da

sottoinsieme ingressi e un token piazzato su nodo

• Quando nodo completa esecuzione, token rimosso

da nodo e token offerti su sottoinsieme archi uscita.

• Offerta: token possono essere rifiutati

– Regole per offrire e accettare token su archi


Concorrenza

• Vincoli su ordine esecuzione di due o più azioni

esplicitate fra relazioni di flusso

• Se azioni non ordinate direttamente o

indirettamente da relazioni di flusso, possono

eseguire concorrentemente

– Esecuzione parallela, non richiesta ma possibile


Relazione con contesto

• Activity in contesto classificatore:

– se metodo di behavioral feature

• invocata quando feature invocata

– se non metodo di behavioral feature

• invocabile dopo istanziazione classificatore

• Ovverriding di attività usate come metodi ereditati

• Invocabile anche direttamente da altre attività

– Non solo tramite chiamata a behavioral feature

– Possibilità ottimizzazione indipendente da classificatore


Flussi

• Realizzati mediante edge

– source e target in stessa attività

• Permettono passaggio di token

• Specifica weight per minimo numero di token su arco

– quando raggiunto, tutti token presenti offerti a bersaglio

– condizioni valutate e minimo numero deve superarle

– se weight illimitato tutti i token offerti devono superarle

• Flussi di controllo e di oggetti stessa notazione


Flussi di oggetti

• Flussi oggetti offrono token di tipo dato o oggetti

• Possibilità di avere pin per indicare cosa passato

• Offerti a target stesso ordine in cui presi da source

– anche in caso di offerta simultanea di più token

– se associato con selezione, trascura ordine

• Flussi da stesso nodo oggetto competono

– Duplicazione possibile tramite fork

• Associabile con trasformazione prima di dare a target

– trasformazione non può avere effetti collaterali


Gestione pesi


Nodi di controllo• Vincoli su flussi entranti o uscenti

• DecisionNode ha flussi dello stesso tipo

– Comportamento di decisione non ha effetti collaterali

– Ogni token entrante attraversa un solo arco uscente

• ForkNode divide flusso in vari flussi concorrenti

– Se almeno un token accettato, tutti token offerti rimossi da

source e copia su ogni flusso accettante

– Token non accettato causa fallimento bersaglio: pendente

• JoinNode emette token se condizione su entranti

– Se entranti sia dati sia controllo, solo dati offerti

• MergeNode non sincronizza, ma propaga


Coordinamento di attività


Comportamenti su scelte


Specifiche di join


Terminazione attività

• Token che raggiunge nodo finale fa cessare intera

attività ( o nodo strutturato)

– Fa terminare ogni azione in esecuzione

– Distrugge tutti i token in nodi oggetto, tranne quelli in

nodi parametro di output dell’attività

• Se termina azione invocazione sincrona, terminano

anche comportamenti in attesa ritorno da azione.

• Possibili più nodi finali per ogni attività

– Primo nodo con token fa terminare tutto


Terminazione flussi

• Nodi per finale di flusso.

• Se si usa singola esecuzione per ogni invocazione,

si distruggono token solo su flusso che ha

raggiunto nodo

• Se si usano esecuzioni separate, token per una

invocazione non influenzano altre.


Uso di terminazioni


• Modo per raggruppare nodi con aspetti comuni

– es. unità organizzative in modelli di business

• Mostrano vista nodi contenuti

• Possono condividere contenuto

• Permettono allocare risorse fra nodi di una attività

Partizioni


Gestione ordine con partizioni


Dimensioni multiple


• Scelta esclusiva fra alternative

– Un body eseguito fra tutti quelli con test positivi

• isAssured: almeno un test ha successo

• isDeterminate: al più un test ha successo

– Scelta non deterministica se ordine non definito tramite

successor e predecessor

– Se produce valori in uscita, ogni body deve produrli

Strutture di controllo: Condizionale


• Sezioni di inizializzazione, test e corpo

• Ogni sezione regione annidata.

• Nodi loop seguono ogni predecessore del loop e

precedono ogni successore

• Test può precedere o seguire corpo.

– Risultato su pin raggiunto con decider

• Inizializzazione eseguita una volta prima di corpo

• Test e corpo eseguiti ripetutamente fino a test falso

• Risultati ultima esecuzione test o corpo disponibili

Strutture di controllo: Loop


• Nodi eseguiti nell’ordine specificato.

• Se combinate in flussi, azioni devono anche

soddisfare ingressi di controllo e dati

Strutture di controllo: Sequenza


• Tipo di gruppo di attività

• Archi che lasciano regione designati interrompibili

• Se token lascia regione su arco interrompibile,

ogni flusso in regione viene terminato

• Token uscito da regione non viene terminato

• Atomicità: se token lascia regione su arco non

interrompibile, completa trasferimento

Regioni interrompibili


Cancellazione di ordini


corso di ingegneria del softwareingsoft1/lezioni2008-2009/versionipdf/bl… · ingegneria del...

Documents