I diagrammi di attività e stato

Transcript

1 I diagrammi di attività e stato Angelo Di Iorio (dal materiale di Gian Piero Favini) A.A Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Tassonomia dei diagrammi UML 2 Ingegneria del Software () I diagrammi di attività e stato A.A / 53

2 Cosa sono e a cosa servono I diagrammi di attività (activity diagram) e stato (state machine diagram) sono diagrammi che descrivono comportamento. Il diagramma di attività modella un comportamento (che riguarda una o più entità) come un insieme di azioni organizzate secondo un flusso. Il diagramma di stato modella il comportamento (generalmente di una sola entità) come variazioni del suo stato interno. Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Un passo indietro: Interazione vs. Macchina a stati Interazione: un insieme di oggetti che si scambiano messaggi per raggiungere un dato obiettivo 1: saluta : Person : Person 2: rispondi Macchina a stati: descrive la sequenza di stati in cui si trova un oggetto durante il suo ciclo di vita e in risposta a eventi Ingegneria del Software () I diagrammi di attività e stato A.A / 53

3 Macchine a stati in UML Qualunque classificatore UML può essere associato a una macchina a stati che descrive il funzionamento delle sue istanze. Uno stato è una condizione o situazione nella vita di un oggetto in cui esso: soddisfa una condizione, esegue un attività o aspetta un evento Ingegneria del Software () I diagrammi di attività e stato A.A / 53

4 Semantica La macchina a stati riceve occorrenze di eventi che vengono salvati su una coda ed estratti uno alla volta. La semantica di questi eventi è di tipo run-to-completion: l occorrenza di un evento viene estratta solo dopo che la macchina a stati ha finito di processare quella precedente. Se ci sono più transizioni eseguibili in un dato momento (es. 2 transizioni dallo stesso stato con lo stesso evento e due condizioni diverse, entrambe vere), solo una viene eseguita. Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Transizioni Ogni transizione, oltre allo stato origine e destinazione, può specificare: Event: un trigger che attiva il passaggio di stato Guard: una condizione che, se vera, permette il passaggio di stato Action: un azione che risulta dal combio di stato Sintassi: event[guard]/action La transizione avviene come risposta a uno degli eventi (quando la guardia è vera), e al momento della transizione il contesto esegue l azione specificata Sono tutti opzionali Ingegneria del Software () I diagrammi di attività e stato A.A / 53

5 Un esempio completo (1) Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Un esempio completo (2) Ingegneria del Software () I diagrammi di attività e stato A.A / 53

6 (pseudo)stati iniziali e finali Gli esempi precedenti mostrano due pseudo-stati, per avviare e bloccare la macchina a stati: Il disco nero marca l inizio dell esecuzione. Non è uno stato vero e proprio ma un marcatore che punta allo stato da cui partire. Il disco nero bordato (nodo finale), indica che l esecuzione è terminata. Possono comparire in qualunque numero all interno di un diagramma (o di uno stato composito, che vedremo in seguito). Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Azioni interne Uno stato può reagire ad eventi (e verificare condizioni) anche senza una transizione ad uno stato diverso Le internal activities sono mostrate nel secondo slot e seguono la stessa sintassi delle transizioni Simile ad una self-transition Esempio: riempimento di un campo di testo in un form Ingegneria del Software () I diagrammi di attività e stato A.A / 53

7 Entry, Exit, Do All interno di uno stato si possono usare alcune azioni speciali, indicate tramite keyword: entry: eseguita quando l oggetto entra nello stato exit: eseguita quando l oggetto esce dallo stato do (do-activity): eseguita mentre l oggetto è nello stato Una self-transition attiva sempre le entry ed exit, le internal activities invece no Una do-activity non è istantanea ma può durare per un intervallo di tempo ed essere interrotta (da altri eventi) Ingegneria del Software () I diagrammi di attività e stato A.A / 53 do-activity: esempio Modelliamo la ricerca di nuovo hardware da installare su un sistema operativo. Ingegneria del Software () I diagrammi di attività e stato A.A / 53

8 Stati compositi Figure Composite state with two states State1 CompositeState State2 HiddenComposite entry / start dial tone exit / stop dial tone Figure Composite State with hidden deco Permettono di suddividere la complessità del modello: dall esterno si vede un macro-stato, al cui interno vi sono altri stati. Si può anche creare uno stato che fa riferimento ad un altro diagramma di macchina a stati (submachine state). Si può usare un icona per rappresentare uno stato composito il cui comportamento interno non è mostrato. Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Stati compositi: esempio UML Superstructure Specification, v2.1 Ingegneria del Software () I diagrammi di attività e stato A.A / 53

9 Stati compositi e transizioni Si possono definire transizioni da uno stato interno verso stati esterni Transizioni in uscita dal bordo dello stato composito e legate ad un evento sono ereditate da tutti gli stati all interno. Ingegneria del Software () I diagrammi di attività e stato A.A / 53 History pseudostate Un history pseudostate indica il più recente stato interno attivo di uno stato composito Utile per ripristinare stati precedenti Esempio: alla ri-accensione di una radio/cd si seleziona radio o CD in base alla scelta attiva allo spegnimento Ingegneria del Software () I diagrammi di attività e stato A.A / 53

10 Stati compositi e concorrenza Gli stati compositi sono utili per modellare la concorrenza. Si divide lo stato composito in (sotto-)diagrammi ortogonali eseguiti in mutua esclusione Il diagramma sarebbe molto meno chiaro senza questo approccio (bisogna considerare tutte le possibilità) Esempio: una radiosveglia che o mostra l orario o fa ascoltare musica Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Stati compositi e sincronizzazione Gli stati compositi sono inoltre utili per modellare la sincronizzazione. Si divide lo stato composito in (sotto-)diagrammi e si usano gli operatori di fork e join (che vedremo tra poco) Esempio: le attività e prove che uno studente deve superare per concludere un corso Ingegneria del Software () I diagrammi di attività e stato A.A / 53

11 Transizioni di completamento Si tratta di transizioni che non hanno un evento associato (ma possono avere una guardia). Nel caso di uno stato semplice, una transizione di completamento è eseguita al termine dell attività di quello stato (fine azioni do). Nel caso di uno stato composito o submachine state una transizione di completamento è eseguita quando si giunge in uno stato finale oppure un exit point. Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Examples Issue replace sub state machine with submachine state Completamento ed entry/exit points The diagram in Figure shows a fragment from a state machine diagram in which a submachine state (the FailureSubmachine) is referenced. The actual sub state machine is defined in some enclosing or imported name space. HandleFailure: FailureSubmachine error1/ sub1 error3/ subend /fixed1 Figure Submachine State L evento error3in fa the above partire example, the l esecuzione transition triggered by event error1 dallowill stato terminate on iniziale entry point sub1 of the FailureSubmachine state machine. The error3 transition implies taking of the default transition of the FailureSubmachine. dello stato composito. L evento error1 fa partire l esecuzione dall entry point sub1. Se l esecuzione termina nell exit point subend si esegue la transizione di completamento che genera il comportamento fixed1. Se l esecuzione termina nello stato finale si segue la transizione sulla destra. The transition emanating from the subend exit point of the submachine will execute the fixed1 behavior in addition to what is executed within the HandleFailure state machine. This transition must have been triggered within the HandleFailure state machine. Finally, the transition emanating from the edge of the submachine state is taken as a result of the completion event generated when the FailureSubmachine reaches its final state. Note that the same notation would apply to composite states with the exception that there would be no reference to a state machine in the state name. Ingegneria del Software () I diagrammi di attività e stato A.A / 53 UML Superstructure Specification, v

12 Entry/exit points (2) Inizializzazione entry Connessione connesso Autenticazione ok tuttook errore nonriconosciuto erroreconnessione nonautenticato Esempio entry Inizializzazione tuttook Funzionante erroreconnessione nonautenticato dopo(60 secondi) Forniscono un modo per entrare ed uscire dalle macchine a stati in diversi punti (simili a entry/exit points interni) Si possono usare in combinazione con i nodi iniziali e finali. Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Examples Figure is an example statemachine diagram for the state machine for simple telephone object. In addition to the initial state, the state machine has an entry point called activeentry, and in addition to the final state, it has an exit point called aborted. Un esempio completo activeentry lift receiver /get dial tone Idle Active DialTone do/ play dial tone Time-out do/ play message dial digit(n) after (15 sec.) [incomplete] after (15 sec.) dial digit(n) Dialing dial digit(n)[invalid] dial digit(n)[valid] Invalid /connect do/ play message Connecting Pinned Busy busy connected caller hangs up /disconnect callee answers Talking callee hangs up do/ play busy tone callee answers /enable speech Ringing do/ play ringing tone abort terminate aborted Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Figure State machine diagram representing a state machine

13 Comportamento vs. Protocollo Una macchina a stati può essere o del comportamento o di protocollo (la distinzione è sottile). Una macchina a stati del comportamento specifica un comportamento del contesto che va modellato: il modo in cui reagisce agli eventi. Una macchina a stati di protocollo specifica quali operazioni possono essere eseguite sul contesto in ogni momento, e può essere associata ad oggetti senza comportamento e perfino non istanziabili (es. interfacce). Un classificatore può avere al massimo una m.s. di comportamento e un qualunque numero di m.s. di protocollo. Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Esempio: m.s. di comportamento Examples Dialing Start digit(n) Partial Dial [number.isvalid()] entry/ start dial tone exit/ stop dial tone entry/number.append(n) digit(n) Figure Composite state with two states In una m.s. di comportamento, gli stati possono contenere azioni intraprese all entrata (entry), all interno (do) e HiddenComposite all uscita (exit) dello stato. entry / start dial tone exit / stop dial tone Finora abbiamo visto soprattutto questo tipo di diagramma, che è il più comune Figure Composite State with hidden decomposition indicator icon Ingegneria del Software () I diagrammi di attività e stato A.A / 53

14 machines can always be found by having one protocol state machine, with sub state machines in concurrent regions Notation The notation for protocol state machine is very similar to the one of behavioral state machines. The keyword {proto placed close to the name of the state machine differentiates graphically protocol state machine diagrams. Esempio: m.s. di protocollo Door {protocol} [doorw ay -> isem pty] C lose/ opened closed create/ open/ lock/ locked unlock/ Figure Protocol state machine ProtocolTransition (from ProtocolStateMachines) In una m.s. di protocollo, gli eventi nelle transizioni sono generalmente Generalizations operazioni del classificatore di contesto (in questo caso Door) Transition (from BehaviorStateMachines) on page 594 Il diagramma Descriptionmostra le operazioni legali in ogni momento A protocol transition (transition as specialized in the ProtocolStateMachines package) specifies a legal transition for del suo ciclo di vita. operation. Transitions of protocol state machines have the following information: a pre condition (guard), on trigger, a post condition. Every protocol transition is associated to zero or one operation (referred BehavioralFeature) that bel L ordineto èthe particolarmente context classifier of the protocol importante state machine. Ingegneria del Software () I diagrammi di attività e stato A.A / 53 UML Superstructure Specification, v2.1 m.s. di protocollo: DBConnector Ingegneria del Software () I diagrammi di attività e stato A.A / 53

15 Il diagramma di attività Modella un attività relativa ad un qualsiasi oggetto, ad esempio: classi casi d uso interfacce componenti interfacce operazioni di classe Alcuni usi dei diagrammi di attività: modellare il flusso di un caso d uso (analisi) modellare il funzionamento di un operazione di classe (progettazione) modellare un algoritmo (progettazione) Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Notation Attività: ingredienti The notations for activity nodes are illustrated below. There are three kinds of nodes: action node, ob control node. See these classes for more information. Action node Object node Control nodes Nodi azione: specificano unità di comportamento. Figure Activity node notation Nodi oggetto: specificano oggetti usati come input e output di azioni. Examples This figure illustrates the following kinds of activity node: action nodes (e.g., Receive Order, Fill Or (Invoice), Nodi and controllo: nodes specificano (the initial node il before flussoreceive dell attività. Order, the decision node after Receive O node and Join node around Ship Order, merge node before Close Order, and activity final after Close [order rejected] Ingegneria del Software () I diagrammi di attività e stato A.A / 53

16 Figure Examples Local of actions preare and illustrated postconditions below. These perform behaviors called Send Payment a Nodi azione Examples Send Accept Examples of Payment actions are illustrated Paymentbelow. These perform behaviors called Send Payme Figure Examples of actions Below Send is an example Accept of an action expressed in an application-dependent action language: Payment Payment Figure Examples of actions FOR every Employee calculate salary Below is an print example check of an action expressed in an application-dependent action langua ENDFOR Figure Example of action with tool-dependent action language FOR every Employee calculate Package salary CompleteActivities print The check example below illustrates local pre- and postconditions for the action of a drink-dispe ENDFOR considered local because a drink-dispensing machine is constrained to operate under thes action. For a machine technician scenario, the situation would be different. Here, a machin Figure to open up - Example the machine, of action and therefore with tool-dependent no money need be action inserted language to dispense the drink, nor a situation, the global pre- and postconditions would be all that is required. (Global condit Package specification, CompleteActivities in the next subsection.) For example, a global precondition for a Dispense Dr is selected that the vending machine dispenses. The postcondition, then, would be The v The example drink that below was selected. illustrates In local other pre- words, and there postconditions is no global requirement for the action for money of a drink-d and cor considered local because a drink-dispensing machine is constrained to operate under action. 326 For a machine technician scenario, the situation would be different. Here, UML a mac S to open up the machine, and therefore no money need be inserted to dispense the drink, a situation, the global pre- and postconditions would be all that is required. (Global co specification, in the next subsection.) For example, a global precondition for a Dispens is selected that the vending machine dispenses. The postcondition, then, would be T drink that was selected. In other words, there is no global requirement for money and Un azione può invocare un attività, un comportamento o un operazione. Come gli altri elementi di UML, anche le azioni accettano livelli di dettaglio e linguaggi differenti. Al contrario dei messaggi nei diagrammi di interazione, le azioni non costringono il modellatore a definire tutte le entità in gioco. Le transizioni (frecce) tra azioni possono avere una guardia. Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Transizioni e token 326 UM Per capire la semantica dei diagrammi di attività, bisogna immaginare delle entità, dette token, che viaggiano lungo il diagramma. Il flusso dei token definisce il flusso dell attività. I token possono rimanere fermi in un nodo azione/oggetto in attesa che si avveri una condizione su una freccia, oppure una precondizione o postcondizione su un nodo. Il movimento di un token è atomico. Un nodo azione viene eseguito quando sono presenti token su tutti gli archi in entrata, e tutte le precondizioni sono soddisfatte. Al termine di un azione, sono generati control token su tutti gli archi in uscita. Ingegneria del Software () I diagrammi di attività e stato A.A / 53

17 Local pre- and postconditions are shown as notes attache «localpostcondition», respectively. Precondizioni e postcondizioni «localprecondition» constraint name «localpostcondition» constraint Si tratta di condizioni, Figure espresse Local in qualunque pre- and modo, postconditions che devono essere soddisfatte per far iniziare o terminare l azione (permettere a unexamples token di entrare o uscire). Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Examples of actions are illustrated below. These perform Nodi iniziali e finali Send Payment Accept Payment Realizza progetto Supera scritto Figure Examples of actions Below is an example of an action expressed in an applica Il disco nero marca l inizio dell attività (genera token). Quando un token raggiunge un disco nero bordato (nodo finale), l attività ha FOR termine. every Employee Possono comparire calculate in qualunque salary numero all interno di un attività (ogni nodo print check iniziale fa partire un flusso di esecuzione, il primo ENDFOR nodo finale raggiunto ferma tutti i flussi). Figure Example of action with tool-dependent ac Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Package CompleteActivities

18 Nodi decisione e fusione [x<0] Action1 [x=0] Action2 [x>0] Action3 I nodi decisione hanno un input e vari output mutuamente esclusivi: copiano i token in entrata su uno degli output. I nodi fusione hanno vari input e un solo output, sul quale vengono indirizzati tutti i token in ingresso. Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Nodi fork/join Action1 Action2 I nodi fork hanno un ingresso e varie uscite: i token in ingresso sono duplicati su tutte le uscite. I nodi join hanno vari ingressi e una sola uscita: quando sono presenti token su tutti gli ingressi, viene prodotto almeno un token in uscita. I nodi fork dividono un esecuzione in più flussi concorrenti, i nodi join sincronizzano e riuniscono i flussi. Ingegneria del Software () I diagrammi di attività e stato A.A / 53

19 Nodi finali di flusso Action1 Action2 Action3 Quando raggiunti da un token, causano la terminazione solo del flusso che li ha toccati. Il raggiungimento di un nodo finale di attività causa comunque la terminazione di tutti i flussi. Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Un esempio completo Ingegneria del Software () I diagrammi di attività e stato A.A / 53

20 Nodi oggetto Crea progetto Progetto Sostieni scritto Studia Servono per modellare gli oggetti in input e output delle azioni I token in uscita da questi nodi sono object token, e sono diversi dai control token prodotti dai nodi azione: rappresentano veri e propri oggetti. Gli archi in entrata e uscita dai nodi oggetto sono object flow anziché control flow, e ci sono regole che limitano il loro uso (es: gli archi che entrano ed escono dai nodi decisione e fusione devono essere o tutti object o tutti control) Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Pin Crea progetto progetto Consegna progetto Si agganciano ai nodi azione per definire un input oppure un output di quell azione. Questa notazione è equivalente a quella di un nodo oggetto tra i due nodi azione. I pin aiutano a mostrare i parametri e valori di ritorno di un azione. Ingegneria del Software () I diagrammi di attività e stato A.A / 53

21 Stato degli oggetti Crea progetto Progetto [valutato] Progetto [finito] Consegna progetto Spesso risulta conveniente aggiungere lo stato di un oggetto per mostrarne l evoluzione durante l attività. Gli stati devono essere coerenti con la macchina a stati associata all oggetto. Questo è l anello di congiunzione tra diagrammi di attività e stato. Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Segnali ed eventi (1) Manda segnale Accetta evento Accetta evento temporale Ci sono alcuni nodi azione specializzati che gestiscono l invio e la ricezione di segnali. L invio di segnali è asincrono e non blocca l attività. Ingegneria del Software () I diagrammi di attività e stato A.A / 53

22 Segnali ed eventi (2) Segui lezioni Inizio corso Studia Data scritto Sostieni scritto Ricevi specifiche Ricevi valutazione Crea progetto Notifica consegna I nodi ricezione sono attivi quando hanno token su tutti gli archi in entrata (se ne hanno) oppure durante l intera vita dell attività (se non ne hanno); generano token alla ricezione. La ricezione di eventi temporali funziona nello stesso modo, i token sono generati in base ad un espressione temporale. Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Issue add explanatory paragraph Attività: esempio Figure 12.37shows another example activity for a process to resolve a trouble ticket. Trouble Ticket [problem statement rectified] [recorded] Record Problem [not recorded] Reproduce Problem [can reproduce problem] ID Problem and Resolution [cannot reproduce problem] Correct Problem [duplication of another problem] Verify Resolution [problem not solved] [known problem and solution] [else] Communicate Results Audit and Record Un attività è costituita da un flusso di azioni che ne sono i mattoni. In effetti un azione può invocare un altra attività. Figure Workflow example Below is an example of using class notation to show the class features of an activity. Associations and state machines can also be shown. Ingegneria del Software () I diagrammi di attività e stato A.A / 53 «activity» Fill Order

23 Attività: esempio (2) Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Attività: parametri e valori di ritorno Production Materials Produce Printed-Circuit Boards Printed- Circuit Boards Assemble Computers Assembled Computers Test Computers Rejected Computers Accepted Computers Figure Example of activity parameters.nodes Parametri e valori di ritorno, se esistono, si rappresentano come nodi oggetto sul bordo dell attività. In the example below, production materials are streaming in to feed the ongoing printed circuit board fabrication. At the end of the activity, computers are quality checked. Computers that do not pass the test are exceptions. See Parameter for semantics of streaming and exception parameters. {stream} Rejected Ingegneria del Software () I diagrammi di attività e stato A.A. Computers / 53 Produce Production Assemble Test Printed-Circuit Materials Computers Computers Boards

24 Partizioni (swimlanes) Studente Docente Crea progetto Progetto Progetto [finito] Valuta progetto Supera scritto Progetto Progetto [valutato] (Order Department) Receive Order [order Close Order Suddividono il flusso dell attività, ma non ne modificano il accepted] significato. (Accounting «external» (Accounting La suddivisione Department) può(customer) essere orizzontale, verticale o Department) Send Invoice Make Accept multidimensionale. Payment Payment Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Figure Activity partition using annotation example The example below depicts multidimensional swim lanes. The Receive Order and Fill Order behaviors are performed by an instance of the Order Processor class, situated in Seattle, but not necessarily the same instance for both behaviors. Even though the Make Payment is contained within the Seattle/Accounting Clerk swim cell, its performer and location are not specified by the containing partition, because it has an overriding partition. Partizioni (2) Invoice Seattle (Order Department) Fill Order (Order Department) Ship Order «attribute» performinglocation:location Reno (Order Department) «class» Order Processor Receive Order [order accepted] Fill Order Ship Order Close Order «class» Accounting Clerk Send Invoice Invoice «external» (Customer) Make Payment Accept Payment Figure Activity partition using multidimensional swimlane example Le partizioni sono generalmente suddivise secondo uno di questi criteri: classificatori le cui istanze eseguono le varie parti istanze che eseguono le varie parti ruoli/parti del sistema che eseguono le varie parti attributi o valori relativi alle varie parti UML Superstructure Specification, v Ingegneria del Software () I diagrammi di attività e stato A.A / 53

25 Interruptible regions in activity modeling are new to UML 2.0. Regioni interrompibili (1) Si usano per specificare una reazione che può avvenire in qualunque momento e comporta l interruzione dell attività. Esempi: eccezioni, interrupt, segnali, situazioni di errore dall esterno. La notazione impiegata è quella di un attività con i bordi tratteggiati. Uno o più archi di interrupt (a zigzag) partono da nodi interni e puntano verso nodi esterni. L interrupt è generato quando un arco di interrupt è attraversato da un token: tutti gli altri token e comportamenti nella regione sono terminati. La ricezione di eventi all interno della regione funziona solo se ci sono token al suo interno. Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Examples The first figure below illustrates that when an order cancellation request is made only while receiving, filling, o shipping) orders the Cancel Order behavior is invoked. Regioni interrompibili (2) [order rejected] Order cancel request Cancel Order Receive Order Fill Order [order accepted] Ship Order Close Order Send Invoice Make Payment Accept Payment Invoice Figure InterruptibleActivityRegion example L ordine è cancellato solo se un token si trova all interno della Rationale regione al momento della ricezione del segnale. Interruptible regions are introduced to support more flexible non-local termination of flow. Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Changes from previous UML

26 Attività vs. Stato In UML 1.x, i due diagrammi sono in pratica la stessa cosa, ma usata in due modi diversi (i diagrammi di attività sono diagrammi di stato in cui gli stati sono azioni). UML 2 (qui utilizzato) ridefinisce e separa la semantica dei due diagrammi: quelli di attività si basano sulle reti di Petri, quelli di stato sulla ricerca di Harel. Dal punto di vista del modellatore, in UML 1.x entrambi i diagrammi sono diagrammi di stato privi di alcune funzionalità introdotte con UML 2. Ingegneria del Software () I diagrammi di attività e stato A.A / 53 Attività vs. Stato (2) Uno stato al contrario di un azione dei diagrammi di attività è solitamente rappresentato con aggettivi e nomi piuttosto che verbi. Nei diagrammi di stato non si usano token; le transizioni sono effettuate quando avviene l evento corrispondente. Lo stato iniziale e quello finale si rappresentano allo stesso modo in entrambi i diagrammi (cerchio nero e cerchio bordato). Altri elementi di notazione in comune con i diagrammi di attività sono i nodi decisione (decidono lo stato di destinazione in base a una guardia) e i nodi fork/join, che permettono al sistema di trovarsi in vari stati ortogonali (paralleli) allo stesso tempo. Ingegneria del Software () I diagrammi di attività e stato A.A / 53

27 Conclusioni I diagrammi di attività descrivono un flusso di azioni che realizzano un certo comportamento specifico. L enfasi non è sullo scambio di messaggi ma sui blocchi di comportamento. I diagrammi di macchina a stati si concentrano su un solo classificatore di contesto e modellano il suo stato interno in relazione al suo comportamento o alle operazioni che possono eseguite sulle sue istanze. Come tutti i diagrammi UML, possono essere usati sia a livello di analisi che di progettazione. Ingegneria del Software () I diagrammi di attività e stato A.A / 53 I diagrammi di interazione Angelo Di Iorio (dal materiale di Gian Piero Favini e Sara Zuppiroli) A.A Ingegneria del Software () I diagrammi di interazione A.A / 47

28 Tassonomia dei diagrammi UML 2 Structure diagrams show the static structure of the objects in a system. That is, they depict those elements in a specification that are irrespective of time. The elements in a structure diagram represent the meaningful concepts of an application, and may include abstract, real-world and implementation concepts. For example, a structure diagram for an airline reservation system might include classifiers that represent seat assignment algorithms, tickets, and a credit Ingegneria authorization del service. Software Structure () diagrams do not I show diagrammi the details di interazione of dynamic behavior, which are illustrated A.A by behavioral 2 / 47 diagrams. However, they may show relationships to the behaviors of the classifiers exhibited in the structure diagrams. Behavior diagrams show the dynamic behavior of the objects in a system, including their methods, collaborations, activities, and state histories. The dynamic behavior of a system can be described as a series of changes to the system over time. Behavior diagrams can be further classified into several other kinds as illustrated in Figure A.5. Cosa sono e a cosa servono Please note that this taxonomy provides a logical organization for the various major kinds of diagrams. However, it does not preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioral elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the various kinds of diagram types are not strictly enforced. The constructs contained in each of the thirteen UML diagrams is described in the Superstructure chapters as indicated below. Sono diagrammi di comportamento che modellano le interazioni Activity Diagram - tra Activities varie on page entità 307 di un sistema. Class Diagram - Classes on page 21 Visualizzano Communication Diagramlo- Interactions scambio on page 477 di messaggi tra entità nel tempo. Component Diagram - Components on page 147 Il loro Composite scopo Structure Diagram è mostrare - Composite Structures come on page un 167certo comportamento Deployment diagram - Deployments on page 201 viene realizzato dalla collaborazione delle entità in gioco. La parola chiave è realizzare: questi diagrammi mostrano la realizzazione di un comportamento offerto. In altri termini: il comportamento del sistema da una prospettiva interna Come gli altri diagrammi, possono avere diversi livelli di astrazione. Ingegneria del Software () I diagrammi di interazione A.A / 47

29 Come procedere Un diagramma di interazione necessita di due cose: Un comportamento da realizzare tratto da un classificatore (classificatore di contesto), ad esempio... un caso d uso un operazione di classe Una serie di elementi che realizzano il comportamento, ad esempio... attori istanze di classe Questi ingredienti provengono da diagrammi creati precedentemente. Ingegneria del Software () I diagrammi di interazione A.A / 47 I diagrammi Ci sono 4 tipi di diagrammi di interazione, noi ci concentreremo sui primi 2. Diagramma di sequenza: adatto a mostrare la sequenza temporale degli avvenimenti per ogni entità nel diagramma. Diagramma di comunicazione: adatto a mostrare le relazioni strutturali e i collegamenti tra le entità e i messaggi che vi transitano. Diagramma di interazione generale: adatto a mostrare la costruzione di interazioni complesse a partire da interazioni più semplici. Diagramma di temporizzazione: adatto a mostrare l evoluzione dell interazione in tempo reale. Ingegneria del Software () I diagrammi di interazione A.A / 47

30 Elementi dei diagrammi d interazione Nei diagrammi di interazione generalmente non compaiono direttamente classificatori come le classi: al loro posto ci sono Istanze di classificatori (oggetti, istanze di attori, etc.) Linee di vita (lifeline) di classificatori (esprimono ruoli, non specifici oggetti) La differenza tra istanze e linee di vita è sottile, ma in generale è preferibile usare le linee di vita. Questi diagrammi includono anche (anzi, ne sono gli elementi principali) i messaggi, ossia i segnali che si scambiano le istanze di classificatori e/o le linee di vita Ingegneria del Software () I diagrammi di interazione A.A / 47 Istanze vs. linee di vita Un istanza: rappresenta uno specifico oggetto, e solo quello Una linea di vita: è più generale rappresenta un istanza arbitraria di un classificatore fornisce modi per specificare come quest istanza viene scelta esprime il ruolo giocato da un istanza senza preoccuparsi della sua identità Ingegneria del Software () I diagrammi di interazione A.A / 47

31 Istanze e linee di vita in UML Jim : Person buyer : Person Entrambe usano la notazione del loro classificatore, ma le linee di vita non sono sottolineate. La notazione completa per una linea di vita è: nome [selettore] : tipo Il selettore è un espressione booleana opzionale che permette di scegliere un particolare rappresentante del classificatore, ad es. [id= 1234 ]. Senza selettore la linea di vita rappresenta un arbitraria istanza. Ingegneria del Software () I diagrammi di interazione A.A / 47 I diagrammi di sequenza Evidenziano l ordine temporale delle invocazioni dei metodi Una linea verticale tratteggiata indica una sequenza temporale. Gli eventi hanno luogo nel loro ordine sulla linea; le distanze sono irrilevanti. Più linee di vita interagiscono per realizzare il comportamento offerto, scambiandosi messaggi buyer : Person Ingegneria del Software () I diagrammi di interazione A.A / 47

32 Messaggi Rappresentano comunicazioni tra linee di vita: segnali, chiamate di operazioni, creazione e distruzione di oggetti. Sette tipi definiti: chiamata sincrona chiamata asincrona ritorno da chiamata creazione distruzione messaggio trovato messaggio perso Ingegneria del Software () I diagrammi di interazione A.A / 47 Tipi di messaggi: chiamata (1) lifeline1 lifeline2 Asincrono message(param) Sincrono message2(p1,p2) Ritorno Comunicazione sincrona vs. comunicazione asincrona. I rettangoli di attivazione (indicano un focus di controllo) sono opzionali. Ingegneria del Software () I diagrammi di interazione A.A / 47

33 Tipi di messaggi: chiamata (2) I messaggi sincroni fanno bloccare chi li manda fino al messaggio di ritorno del destinatario. Nei messaggi asincroni il mittente non si aspetta un messaggio di ritorno e prosegue immediatamente. I messaggi di ritorno sono opzionali e in generale inclusi solo quando non ostacolano la leggibilità del diagramma oppure per segnalare valori di ritorno. La distinzione tra messaggi sincroni e asincroni in genere emerge in fase di progettazione. In fase di analisi, conviene indicare tutti i messaggi come sincroni (è il caso più vincolante). Ingegneria del Software () I diagrammi di interazione A.A / 47 Sintassi messaggi In fase di analisi generalmente basta includere il nome del messaggio. Se si desidera maggiore dettaglio, si include una lista di parametri tra parentesi. Si possono anche usare guardie per verificare condizioni Si possono indicare i parametri formali, quelli attuali, o entrambi (in quest ordine: getarea(shape=g)). Ingegneria del Software () I diagrammi di interazione A.A / 47

34 Attivazioni annidate (1) a : A b : B Le linee di vita possono mandare messaggi a se stesse. Si tratta di un caso frequente (es. invocazione di operazioni private). Ingegneria del Software () I diagrammi di interazione A.A / 47 Attivazioni annidate (2) sd overlap cc:c aa:a oper1() callback() Figure Overlapping execution occurrences Le attivazioni possono generare altre attivazioni sulla linea di vita chiamante (es. callback) Gate (from Fragments) Generalizations Ingegneria del Software () I diagrammi di interazione A.A / 47

35 Esempio completo: ATM machine Ingegneria del Software () I diagrammi di interazione A.A / 47 Tipi di messaggi: creazione/distruzione (1) a : A <<create>> b : B <<destroy>> Ingegneria del Software () I diagrammi di interazione A.A / 47

36 Tipi di messaggi: creazione/distruzione (2) Nel messaggio di creazione lo stereotipo può essere seguito dal nome di un operazione e relativi parametri (costruttore). Questo si rende necessario nel caso si lavori con linguaggi di programmazione senza costruttori espliciti. Differenti linguaggi di programmazione OO gestiscono la distruzione in modi diversi (esplicita, garbage collector). In fase di analisi, basta immaginare che dopo la distruzione, l oggetto non è più accessibile Ingegneria del Software () I diagrammi di interazione A.A / 47 Tipi di messaggi: trovati/persi (1) a : A b : B foundmsg senddata senddata senddata Ingegneria del Software () I diagrammi di interazione A.A / 47

37 Tipi di messaggi: trovati/persi (2) Raramente usati in fase di analisi. I messaggi trovati indicano situazioni in cui il mittente è sconosciuto al momento della ricezione, proviene dall esterno del diagramma o i dettagli della provenienza non interessano. I messaggi persi permettono di visualizzare il comportamento nel caso un messaggio non giunga a destinazione (situazione di errore). Ingegneria del Software () I diagrammi di interazione A.A / 47 Stati (1) Uno stato è definito come una condizione o situazione durante la vita di un oggetto in cui esso soddisfa una condizione, esegue un attività o aspetta un evento. Ogni oggetto in UML può avere una macchina a stati associata che ne descrive gli stati possibili. I diagrammi di stato (state machine diagram) sono i più adatti a rappresentare gli stati e loro transizioni, ma può essere conveniente mostrare alcuni cambiamenti di stato nei diagrammi di sequenza. Generalmente, ci si limita agli stati principali all oggetto, mettendo in risalto i messaggi che provocano un cambiamento di stato. Ingegneria del Software () I diagrammi di interazione A.A / 47

38 Stati (2) : Lamp : User Off switch() On In UML, gli stati si rappresentano con rettangoli arrotondati. I cambiamenti di stato sono generalmente la conseguenza di uno o più messaggi. Ingegneria del Software () I diagrammi di interazione A.A / 47 Realizzare i casi d uso Le primitive introdotte fin qui permettono di rappresentare sequenze di eventi senza ramificazioni; tuttavia, per realizzare i casi d uso è necessario poter descrivere sequenze più complesse. Le sequenze degli eventi in un caso d uso contengono parole chiave come if, then, else, for e while. I diagrammi di sequenza permettono di tradurre questi costrutti ed inserirli nel diagramma. Si ricorre ai frammenti combinati. Ingegneria del Software () I diagrammi di interazione A.A / 47

39 Frammenti combinati (1) Un frammento combinato è una sottoarea di un diagramma di sequenza che racchiude una parte dell interazione e le modalità della sua esecuzione. Gli elementi di un frammento combinato sono: un operatore, che specifica come il frammento viene eseguito uno o più operandi, sottoaree del diagramma di sequenza che possono essere eseguite zero o più condizioni di guardia, espressioni che determinano quali operandi sono eseguiti. Ingegneria del Software () I diagrammi di interazione A.A / 47 Frammenti combinati (2) La sintassi UML per un frammento combinato è la seguente: un rettangolo con il nome dell operatore in alto a sinistra racchiuso nel simbolo di diagramma (rettangolo con angolo tagliato ) gli operandi seguono come strisce orizzontali in sequenza, separati da linee tratteggiate la guardia, se presente, compare dopo l operatore oppure nella parte alta di un operando tra parentesi quadre Il rettangolo del frammento combinato si estende orizzontalmente per includere le linee di vita interessate dall interazione. La guardia può includere qualunque tipo di condizione booleana, incluso OCL. Ingegneria del Software () I diagrammi di interazione A.A / 47

40 Frammenti combinati: esempio buyer seller lawyer pay giveitem alt [buyersatisfied] handshake [buyernotsatisfied] sue(seller) Ingegneria del Software () I diagrammi di interazione A.A / 47 Operatori L operatore determina la semantica dell esecuzione del frammento. UML specifica parecchi tipi di operatori, ma solo alcuni sono usati frequentemente (quelli che corrispondono alle primitive di controllo del flusso definite dai linguaggi di programmazione). I più usati: opt corrisponde a if/then alt corrisponde a case/select loop corrisponde a for/while break corrisponde a break Ingegneria del Software () I diagrammi di interazione A.A / 47

41 Operatori: opt e alt opt accetta solo un operando, che viene eseguito se e solo se la guardia è valutata true. alt accetta un qualunque numero di operandi e ne esegue al più uno. esamina la lista a partire dal primo operando, valuta le guardie ed esegue solo il primo operando la cui guardia è vera l operando opzionale [else] è eseguito se nessuna delle guardie è vera le condizioni di guardia devono essere mutualmente esclusive; al massimo una può essere vera nello stesso istante, altrimenti il modello non è corretto Ingegneria del Software () I diagrammi di interazione A.A / 47 Esempio opt L operatore opt può anche essere omesso per questioni di leggibilità Ingegneria del Software () I diagrammi di interazione A.A / 47

42 Operatori: loop Un solo operando, sintassi speciale: loop min,max [condizione] Esegue l operando min volte, e poi al massimo altre (max - min) volte mentre la condizione è vera. Si possono omettere min e max. La condizione è molto flessibile (può essere espressa in linguaggio naturale), e permette di ciclare su un insieme di oggetti (es. condizione [foreach oggetto in lista]). Ingegneria del Software () I diagrammi di interazione A.A / 47 Esempio loop Ingegneria del Software () I diagrammi di interazione A.A / 47

43 Operatori: break Operando singolo, si usa per terminare l esecuzione del frammento di interazione corrente (spesso si tratta di un operatore loop). Se break ha una condizione di guardia ed è vera, viene eseguito l operando ma non il resto dell interazione dopo il frammento break. Se la condizione di guardia esiste ed è falsa, non viene eseguito l operando e si continua normalmente. Se non c è una guardia, la scelta tra continuare e saltare è non-deterministica. Il frammento break deve essere globale rispetto a quello che interrompe: nella notazione UML, lo interseca ma si trova ad un livello di nesting superiore. Ingegneria del Software () I diagrammi di interazione A.A / 47 Esempio: loop e break buyer seller lawyer loop 10,10 pay giveitem break [buyernotsatisfied] sue(seller) Vengono completate al massimo 10 transazioni, se si passa a vie legali le transazioni finiscono. Ingegneria del Software () I diagrammi di interazione A.A / 47

44 Altri operatori Per rendere i diagrammi di sequenza modulari: ref: l operando contiene il nome di un altra interazione che viene eseguita qui. Altri molto meno usati: par: gli operandi sono eseguiti in parallelo, senza vincoli sull ordinamento dei messaggi appartenenti a operandi diversi. critical: sezione critica, l operando è eseguito in maniera atomica e senza interruzioni dalle linee di vita interessate, anche se all interno di par o altri frammenti. neg: l operando rappresenta un interazione che non deve accadere. assert: l operando rappresenta l unica interazione ammissibile in quel momento. Ingegneria del Software () I diagrammi di interazione A.A / 47 Usare ref sd authentication : User : ATM : User : ATM insertpin ref authentication alt allowuser opt withdraw yes no A destra, l interazione di sinistra inclusa in un altra interazione. Si tratta del modo più semplice di usare ref. sd vuol dire sequence diagram, ma vale per tutti i diagrammi di interazione. Ingegneria del Software () I diagrammi di interazione A.A / 47

45 Gate Si tratta di un qualunque punto sulla cornice esterna del diagramma, che può essere la fonte o la destinazione di una freccia. Usati per modellare la comunicazione delle linee di vita del diagramma con l esterno. I gate possono avere un nome e comparire qualunque numero di volte nello stesso diagramma o in diagrammi diversi. Possono essere usati in combinazione con ref, forniscono l interfaccia di collegamento tra l interazione chiamante e quella chiamata (il frammento combinato può avere gli stessi gate a cui agganciare messaggi). Ingegneria del Software () I diagrammi di interazione A.A / 47 Gate: esempio sd example a : A in <<create>> b : B <<destroy>> out Vengono definiti due gate, in e out. Ingegneria del Software () I diagrammi di interazione A.A / 47

46 Diagrammi di comunicazione Chiamati diagrammi di collaborazione in UML 1.x. In UML 1.x erano semanticamente equivalenti ai diagrammi di sequenza, in UML 2 non sono altrettanto espressivi. Si tratta comunque di diagrammi utili a visualizzare i canali di comunicazione tra le entità. Sono simili ai diagrammi degli oggetti, ma i link tra gli oggetti trasportano messaggi come nei diagrammi di sequenza. Ingegneria del Software () I diagrammi di interazione A.A / 47 Sequenza vs. comunicazione sd sequence a : A b : B msg1 sd communication a : A 1: msg1 2: msg2 b : B msg2 Questi diagrammi sono equivalenti. I messaggi e le loro frecce seguono le stesse regole nei diagrammi di comunicazione. Ingegneria del Software () I diagrammi di interazione A.A / 47

47 Numerazione messaggi sd sequence a : A b : B c : C sd communication 1: msg1 msg1 msg2 a : A b : B 2: msg3 1.1: msg2 msg3 c : C Nei diagrammi di comunicazione è necessario numerare i messaggi. Poiché msg2 si trova nel focus di controllo di msg1 (viene generato come parte dell esecuzione di msg1), il suo numero di sequenza è quello di msg1 seguito da. e un numero di sottosequenza. Ingegneria del Software () I diagrammi di interazione A.A / 47 Ancora sulla numerazione Il numero di sequenza ha tanti componenti quanti sono i livelli di profondità delle attivazioni: es I numeri di sequenza possono velocemente diventare complessi e danneggiare la leggibilità del diagramma. Per questo motivo, da un lato si cerca di limitare la complessità dei diagrammi di comunicazione e dall altro è consentito raggruppare vari messaggi correlati in uno solo per ridurne il numero (specialmente in fase di analisi). Ingegneria del Software () I diagrammi di interazione A.A / 47

48 Ramificazione Si può rappresentare una condizione if/then nei diagrammi di comunicazione. Il numero di sequenza è seguito da una guardia tra parentesi quadre, ad esempio [!error]: msg(param1,param2) Il messaggio è inviato solo se la guardia è vera. Questo costrutto può complicare il diagramma molto in fretta, e dovrebbe essere usato solo in casi semplici. Ingegneria del Software () I diagrammi di interazione A.A / 47 Iterazione (1) L operatore di iterazione nei diagrammi di comunicazione è *. Per esempio * [for i=1 to n]: msg(param1,param2) Si può sostituire * con * che significa invio parallelo dei messaggi. La guardia può essere scritta in qualunque linguaggio o pseudocodice, compresa la notazione [loop min, max [condizione]] dei diagrammi di sequenza. Come mandare lo stesso messaggio ad una collezione di istanze con l iterazione? Due modi: con indici o con molteplicità. Ingegneria del Software () I diagrammi di interazione A.A / 47

49 Iterazione (2) 1 * [for i=1 to n]: sendmessageto(i) a : A a : A [i] : B 1.1: message() * b : B 1 *: message() Nel primo caso [i] è una sola istanza, rappresentata tramite un indice. Nel secondo caso a è collegato a molti b, e l operatore * manda il messaggio a tutti. Ingegneria del Software () I diagrammi di interazione A.A / 47 Esempio completo: ATM Machine (Pin Error) Ingegneria del Software () I diagrammi di interazione A.A / 47