Capire le esigenze all interno del sistema

Transcript

1 Analisi di Dominio Domain Analysis Perché? Capire la struttura e le dinamiche di una organizzazione o, meno spesso, comunità viste con un sistema socio-tecnico (persone-regole-tecnologie coinvolte in processi) in cui verrà viene usata una tecnologia informatica in grado di creare knowledge accidents, e far convergere interazioni. Capire le esigenze all interno del sistema Avere un modello che permetta la comunicazione tra utenti, committenti (cioè i decisori, policy- e decision-makers), e fornitori (analisti e sviluppatori). -1 Sistema o dominio? L obiettivo principale dell analisi di sistema è definire i requisiti di un sistema informatico. L obiettivo principale dell analisi di dominio è definire il contesto in cui tale sistema sarà utilizzato. Contribuisce anch esso a comprendere i requisiti, ma da una prospettiva più ampia e astratta. -2 1

2 Analisi di Dominio Cosa?: Un occasione per identicare (e ragionare su) Ruoli (anche sistemi tecnologici) Responsabilità Interazioni tra ruoli Processi (inter-azioni e azioni) Informazioni coinvolte, prodotti Come? Nell ottica di un informatico è il momento in cui si acquisisce background knowledge (anche convenzionale) Interviste (semi-strutturate) Questionari Osservazioni (partecipate) Rapporti aziendali e documentazione (e.g. ISO9000) Quando? è da farsi i) a prescindere, ii) prima o iii) durante lo sviluppo di un applicazione a supporto di una certa organizzazione. Dopo? Cosa serve studiare il latte versato? -3 Analisi di Dominio: termini Actors: clienti, fornitori, sistemi e utenti esterni alla organizzazione (per RUP); per noi, anche utenti interni (i workers della RUP)... Processes: insiemi articolati di interazioni (comunicazioni e scambi di informazione tra attori) e azioni (trasformazione di input, produzione di output, acquisizione informazione/conoscenza) mutuamente e significativamente articolate verso un obiettivo (ad es.: soddisfare un cliente). Li rappresentiamo con business use cases o essential use cases. Entities: tutto ciò che un'organizzazione produce o gestisce + actors. -4 2

3 Essential Use Cases un use case astratto e semplificato che cattura (rappresenta l essenziale) le interazioni intenzionali (task-oriented) degli attori di un sistema sociotecnico, indipendentemente da una particolare tecnologia/implementazione vedi "Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design" ACM Press di Constantine e Lockwood ) simile ai business use case del RUP. ma questi sono più orientati al business. simile ai system use case dell UML ma questi sono più orientati alla funzionalità del sistema che supporta l intenzione dell utente. -5 Use Cases due tipi, la stessa realtà (attenti ai livelli!) Essential Use Cases (EUC) e System Use Cases (SUC), definiscono la stessa realtà a diversi livelli di descrizione, da diverse prospettive. Cloud level: livello filosofico. Interessante ma poco concreto. Kite level: il sistema socio-tecnico in cui interagiscono gli attori per un certo scopo (comune e di alto livello) Sea level: il sistema informativo/informatico con cui interagiscono gli attori per un certo obiettivo (usufruire di una certa funzionalità). Le interazioni che sono possibili col sistema Le funzionalità esposte (o da esporre=requisiti funzionali) Il Fish level rappresenta i dettagli implementativi Clam level: molluschi nella sabbia, dettagli molto di basso livello -6 3

4 Essential Use Cases In genere si pensa alle EUC cards: La card: un artefatto a due colonne: una colonna con le azioni (intensionali) che vengono messe in campo data l intenzione del caso. una colonna in cui ad ogni azione corrisponde una reazione del sistema (socio-tecnico). Si parla di responsabilità del sistema si tratta di una tabella-eventi (stimolo-risposta) E un approccio ancora troppo sistemistico (alla system use case). Un EUC è semplicemente un artefatto di analisi e modellazione. Può essere corredato da Use Case Diagrams, Cards, scenarios, etc. L importante è capire di cosa si ha bisogno per raggiungere gli obiettivi espressi sopra. -7 Analisi di Dominio: artefatti 1 anche visuale visuale Use Case Model (UCM): Identifica gli actors e identifica gli scenari d uso più frequenti in cui sono coinvolti gli actors, cioè i processi e le loro specifiche testuali (e.g., IOPE ). Ricordarsi: ogni attore ha (è mosso da) un interesse, ha intenzioni, tende a qualche obiettivo. Object/Entity Model (OM): Un modello che realizza lo UCM come un entity diagrams, con tutti gli attori e le entità (artefatti) coinvolti nel sistema (organizzazione + ambiente) e le principali relazioni / interazioni tra di essi. Vedi, teorie sociotecniche (e.g., ANT) per relazioni e interazioni significative (ad es.: controlla, finanzia, informa, presta-opera, etc.) Ogni entità sarà supportata/gestita dal sistema informativo informatico. -8 4

5 Analisi di Dominio: artefatti 2 testuale Altri artefatti: Rules/Convention List (RL): Un documento in cui vengono esplicitate le politiche (policies), le norme, le regole, le convenzioni, le euristiche che devono valere/valgono durante le interazioni tra attori del sistema sotto analisi Glossary (G): un documento che riporta e definisce i termini importanti che caratterizzano il dominio. Svolgere tutti gli acronimi testuale Attenzione a omonimi con senso comune o altre discipline Capire bene differenze (se ci sono) tra sinonimi Attenzione a sineddochi e metonimie. -9 Analisi di Dominio: simboli -10 5

6 Prima l uovo o la gallina Varie metodologie di analisi (e sviluppo). per alcune è meglio partire dal modello dei casi d uso (che a sua volta parte dall identificazione degli eventi significativi). E solo dopo produrre un modello delle entità. per altre è semplicemente vice-versa. Noi adottiamo un approccio misto. Capiamo da noi cosa sia meglio fare prima. -11 Il OM è come un diagramma delle entità (ED) Quello che cambia è il grado di dettaglio e due o tre simboli. Il OM è più astratto di un ED (cloud level vs sea level) L ED di solito si usa per descrivere i sistemi informatici (sea level). Gli ED sono anche noti col termine Class Diagrams (v.1.4) o Static Structure Diagram (v.2). Un ED rappresenta: le entità (classi, tipi di oggetti), ciò che le compongono (le loro parti) e le relazioni, i rapporti tra le istanze di classi diverse (gli oggetti). Le classi sono caratterizzate da attributi (proprietà che descrivono vari aspetti delle loro istanze) operazioni (ciò che permettono di fare o fanno le loro istanze) associazioni (rapporti che intercorrono tra istanze di classi diverse) -12 6

7 Come disegnare ED e BOM I passi sono comuni: 1. Identificare le classi/entità del sistema informatico/sociotecnico. 2. Identificare le associazioni tra coppie di classi/entità e per ciascuna di esse: 1. identificarne le caratteristiche, la natura chiedersi: è riflessiva, è un aggregazione, è una composizione? 2. disegnare una linea e darle un nome sensato es.: un azione, un ruolo, un verbo, il sostantivo corrispondente 3. segnare il verso (non è importante), dipende dal punto 2 es.: chi fa l azione, chi la subisce 4. segnare le molteplicità (o cardinalità) affianco alle classi/entità es.: quanti fanno quell azione e quanti ne sono oggetto? Attenzione: per le molteplicità bisogna segnare sia il min (0, 1) che il max (*), oppure i valori esatti (n, m). -13 Un esempio di ED -14 7

8 Un esempio di OM? Medico Dipartimento di Radiologia Essere Umano Cura Ortopedico Operatore di Radiologia Paziente Richiede Consulenza Radiologo responsabile di Referto responsabile di Immagine Tecnico -15 Use Cases per il UCM -16 8

9 Use Cases Cosa servono Servono per definire gli obiettivi (goals) e le intenzioni (compito-task) degli attori da supportare all interno di un dominio. Gli ha definiti Jacobson nel 1992 all interno di una famosa e diffusissima metodologia per definire i processi, o meglio i task (che hanno obiettivi) per catturare i comportamenti rilevanti, le interazioni significative, in maniera comprensibile non solo agli specialisti. -17 Use Cases - Componenti Un obiettivo, una descrizione del sistema e delle interazioni per raggiungere l obiettivo, un insieme specifico di percorsi. La descrizione può essere: narrativa strutturata I percorsi sono descritti mediante Scenari Strutturati Il tutto è sinteticamente rappresentato da un diagramma use case diagrams (attenzione alla sineddoche!) Dovrebbero esserci tutte queste quattro cose

10 Use Cases: Scenari Uno scenario è un singolo tentativo di portare a termine un caso d uso. Quindi è un percorso (non una istanza di percorso) Uno scenario descrive in dettaglio una possibile sequenza di (inter)azioni verso l obiettivo: è un elenco di passi. Un UC dice cosa può succedere, uno scenario invece dice cosa succede se certe condizioni sussistono. Quindi un UC è un insieme di possibili scenari (legati insieme da un obiettivo). Lo potete vedere anche come un possibile percorso (da start a end) di un Business Process Diagram / Activity Diagram (vedi oltre). -19 Use Cases - Componenti Un insieme specifico di percorsi è un insieme di insiemi di passi necessari a raggiungere un obiettivo. Altro modo di vedere insieme di percorsi: insieme di comportamenti funzionalità interazioni servizi 2) La descrizione narrativa deve anche caratterizzare il contesto, cioè: il business, l ambiente (BUC, EUC) dove il sistema si colloca e vive. (SUC)

11 Use Cases - Actors Dalla descrizione narrativa si evincono gli attori. Sono persone, unità organizzative, altri sistemi, device. Ogni attore indica un (insieme coerente di) ruolo che una entità può avere quando interagisce e comunica nel/con il sistema, qualcuno che ha un interesse (stake-holder) BUC qualcuno che ha un interesse (e contribuisce) perché le cose funzionino. SUC Un attore può interagire in più casi, con un ruolo diverso in ciascuno di essi. Se non umano, è cmq qualcosa il cui comportamento è autonomo, non controllabile. Nei SUC, invece, il sistema è controllabile per definizione! -21 Use Cases Actors e System Un actor è particolarmente importante primary: detiene l obiettivo principale, la motivazione scatenante (BUC) initiator: inizia il caso d uso, mosso da una intenzione compie la prima interazione. (SUC) Gli altri reagiscono all iniziativa del primary/initiator (e.g., il receiver) Nei SUC c è anche il sistema: un raggruppamento di funzioni, come le vedono e ne usufruiscono gli utenti

12 Use Cases I casi I casi descrivono dei macro-comportamenti, della macro-funzionalità, finalizzate al raggiungimento dell obiettivo. Chiedersi: come gli attori producono valore? BUC come ottengono ciò che vogliono/devono fare? SUC cosa produce il sistema per gli attori? SUC come l attore supporta il sistema (input) SUC come il sistema supporta l attore (output) SUC Assegnare loro un nome, un verbo che indica una intenzione, un (sotto)obiettivo. -23 Use Cases le associazioni Le associazioni definiscono delle relazioni tra Attori e Attori: generalizzazioni Attori e UC: interazioni (partecipazioni in un UC) UC e UC: generalizzazioni e dipendenze dipendenza includes qualcosa che viene sempre fatto quando si fa il principale. E un comportamento notevole compreso in quello più generale. dipendenza extends qualcosa che si può fare sotto determinate condizioni (da specificare) e che particolareggia, estende un certo UC. Attori, casi e associazioni si possono rappresentare graficamente: diagrammi UC

13 Use Case Diagrams - Simboli dipendenza extends attore interazione associazione generalizzazione caso d uso dipendenza includes -25 The «includes» association always occurs when the use case which includes it occurs. FIGURE

14 The occurrence of an «extends» association depends on a true condition in the use case which it extends. FIGURE Esempi di (S)UC Diagrams

15 Corso d Azione = Scenario Base (di successo): happy flow, basic path, etc. Es: Acquisto iniziato e concluso con successo Alternativo: Di solito eccezioni, errori, imprevisti. Più in generale, estensioni (cf. la relazione extend) Esempi: Disponibilità di un prodotto terminata Carta di credito non accettata Collegamento con i servizi interbancari interrotto alternative flows -29 Descrizioni strutturate 1 Per scrivere la descrizione strutturata di uno Use Case è necessario riportare: Un Obiettivo: una frase che identifichi l obiettivo del caso nel suo contesto. Es.: Il cliente vuole ottenere un bene, per far ciò chiama direttamente la nostra compagnia e si aspetta di ricevere i beni ordinati e che questi gli vengano fatturati correttamente. Un Identificatore: un identificatore univoco all interno della documentazione di analisi per facilitare riferimenti e discussioni. Es.: /MED-008, con la semantica che si desidera

16 Descrizioni strutturate 2 Un nome: un verbo, una parola, un sostantivo predicativo o poco più: deve essere breve! Es.: Aquisto di beni. Elenco (principali) Assunzioni e Precondizioni: ciò che assumiamo e/o verifichiamo sia lo stato del mondo prima che il caso possa iniziare. Es.: 1) Si conoscono le generalità dell acquirente, 2) l azienda ha un call center, 3) etc -31 Descrizioni strutturate 3 Elenco (principali) Effetti: gli effetti che prevediamo si verifichino dopo che il caso si è concluso. Sia nel caso il caso sia andato a buon fine, che nel caso ci sia stato qualche problema. Sia gli effetti di valore, che gli effetti collaterali, sia sugli attori che sull ambiente esterno. Es.: 1) Il cliente riceve i beni acquistati. 2) Noi abbiamo incassato i soldi. Elenco principali attori: solo i nomi (ruoli) degli attori, sia quelli primari, che quelli secondari. Es.: Il cliente (acquirente); l agente, la banca intermediaria etc. Un trigger: la condizione che fa iniziare il caso: Es.: il cliente chiama l azienda per inoltrare una richiesta di beni

17 Descrizioni strutturate 4 Descrizione passo-passo dello scenario di successo: l'elenco numerato delle azioni che caratterizzano la sequenza più probabile e virtuosa dall'evento di trigger al raggiungimento dell'obiettivo/i. Es.: 1. Il cliente chiama l'azienda per inoltrare la richiesta di acquisto 2. L'azienda (un suo agente) prende nota del nome del cliente, dell'indirizzo, dei beni desiderati, etc. 3. L'azienda (un suo agente) fornisce al cliente informazioni sui beni, disponibilità, prezzi, modalità e tempi di consegna, etc. 4. Il cliente autorizza l'acquisto con pagamento a 30 gg. 5. L'azienda inizia la pratica di fatturazione, e spedisce i beni ordinati al cliente. 6. L'azienda spedisce la fattura al cliente. 7. Il cliente riceve i beni acquistati. 8. Il cliente paga la fattura -33 Descrizioni strutturate 5 Principali estensioni e alternative (eccezioni/errori) allo scenario di successo: l'elenco numerato con riferimento allo scenario di successo delle principali deviazioni dallo stesso. Es.: 3a. L'azienda ha esaurito la disponibilità dei beni scelti 3a1. L'acquirente sceglie un bene alternativo. 4a. L'acquirente paga direttamente con carta di credito all'operatore. 4a1. L'azienda gestisce il pagamento con carta di credito (rif. use case 44) 8a. L'acquirente ritorna i beni acquistati perché insoddisfatto. 8a1. L'azienda gestisce il reso (rif. use case 105)

18 Descrizioni strutturate 6 Altre informazioni: indicare la priorità, la frequenza, il tempo medio di esecuzione, i principali problemi noti, le dipendenze con altri use case noti. Es.: Priorità: massima (media bassa) Esecuzione: 5 minuti per l'ordine, 30 gg per il pagamento Frequenza: circa 200 al giorno Problemi: 1) Solo parte dei beni è disponibile subito 2) carta di credito clonata o rubata. Use case: specializzazione della gestione dei clienti (use case 2) -35 Per evitare gli errori più comuni sui UC. I nomi: Per i casi: verbi (eventualmente con oggetto) o sostantivi predicativi (es.: accettare paziente, accettazione paziente ). Per gli attori: termini singolari, che indicano ruoli, non posizioni. Ogni attore deve interagire in almeno un caso. Non usare mai più di due livelli di descrizione dei casi. Suggerire un ordine temporale tra casi solo per impilazione (no flusso!). Usare poche generalizzazioni tra gli attori. Usare poco l <<extend>> e solo se il caso estende un altro in più scenari (l estendente metterlo sotto l esteso). Usare l <<include>> solo se un caso include sempre l incluso, e questo è abbastanza articolato al suo interno (l incluso metterlo a destra dell includente)

19 (S)UC Una sintesi Attraverso gli Use Case Diagrams (UD) si rappresentano 1. un sistema in un contesto cioè un raggruppamento di funzioni come le vedono gli utenti (il backend è meno importante). 2. gli attori cioè i ruoli a cui interessa che il sistema esegua bene il suo compito o quelli che contribuiscono a che questo accada (una persona -l utente- o un altro sistema - una macchina). 3. le funzionalità / casi sono le feature, i casi d uso (cioè i tipi di uso), gli obiettivi degli attori, il fine che il sistema deve raggiungere per soddisfare le aspettative degli attori coinvolti. 4. le associazioni relazioni tra attori, tra funzionalità diverse e tra attori e funzionalità (queste si chiamano interazioni o comunicazioni ) 5. le dipendenze tra funzionalità e casi d uso diversi Questa è anche una checklist per disegnarne uno -37 (S)UC Una sintesi 2 Gli Use-case diagram dovrebbero essere i primi ad essere disegnati (insieme ad un primo abbozzato ED). Infatti possono essere il punto di partenza per raccogliere i requisiti funzionali di un sistema informatico, per inserirli in un contesto e per associarli a dei task aziendali. Una volta elencate le funzionalità, è possibile rappresentare come queste possono essere realizzate e quali sono i possibili scenari che il sistema deve permettere di fronteggiare adeguatamente. Gli scenari si danno in maniera narrativa (si chiamano anche use case narratives ) e dovrebbero contenere Assumptions e Business rules/policies/conventions (se allora) Pre-conditions tra cui quella di trigger, che causa la Use Case initiation Input: le informazioni usate, date dall actor initiator (e gli artefatti associati) Process / Interaction / dialog Basic Course of Action (se tutto fila liscio) le alternative più ricorrenti/critiche/prevedibili Use Case termination, condizione/criterio di uscita Output: le informazioni prodotte (che prima non c erano), date all actor initiator. Post-conditions (o effetti, i prodotti (materiali/informativi) + side effects) Una volta narrati, gli scenari possono poi essere rappresentati come un possibile percorso nel diagramma delle attività che deriva dalle funzionalità del UD

20 Use Cases Sintesi 3 In genere paga: specificare Nome, ID, Autore, Data creazione e Data ultima modifica. Assunzioni: precondizioni che devono valere perché il caso si abbia, ma non sono verificate da nessuno (attore/sistema) Precondizioni: condizioni verificate sullo stato del sistema, verificate da qualcuno nello UC. Sono regole di accesso: se allora può (non deve) partire il caso. Condizioni necessarie, non sufficienti Trigger: una particolare pre-condizione, che fa partire il caso (necessariamente). Condizione sufficiente (se le altre pre sono vere). Di solito tutto parte da un attore che vuole qualcosa. Ma anche il tempo può fare da trigger, o qualsiasi evento significativo (e.g., un incendio). -39 Use Cases Sintesi 4 Dialogo/Interazione/Corso d azione Principale (basic): descrizione step-by-step. Soggetto-Predicato verbale-(oggetto) Alternativa(e): I flussi alternativi più frequenti, critici, prevedibili. Terminazione: la/e condizione/i (evento/i) che fa/nno terminare il caso. Post-condizioni: condizioni che valgono (devono valere) dopo che il caso è terminato. Anche detti effetti: e.g., il prodotto realizzato + i side-effects. Ogni scenario può avere le sue post-condizioni. Input: le risorse informative (preesistenti al caso) usate nel caso. Output: le risorse informative (non preesistenti) prodotte nel/dal caso. (Business) Rules, Policies, Conventions: regole che valgono durante il caso d uso e ne condizionano lo svolgimento (anche in maniera non determinante)

21 Modellazione di processo -41 BPMN: i simboli Attività - Task Eventi Instradatore, Gateway Connettore, transizione

22 BPMN: Le attività 1 Una attività (o task) è un qualche passo di un processo in cui viene svolto un lavoro (da uno o più persone/sistemi). La potete vedere come uno stato in cui il sistema (socio-tecnico) fa qualcosa. Quando un attività è stata completata si passa alla successiva attività, tramite una transizione. -43 BPMN: Le attività 2 Attività Atomica (per il livello di dettaglio della nostra modello): eseguita una volta sola in un processo. + Attività Composta: al suo interno c è un sotto-processo (eventualmente esplicitato a parte) Attività che cicla: può essere eseguita più volte durante lo stesso processo

23 BPMN: gli eventi 1 Un evento è semplicemente qualcosa che accade durante l'esecuzione di un processo. Gli eventi influenzano il flusso delle attività. Gli eventi possono iniziare, interrompere o far terminare un flusso di lavoro, accadere all inizio, durante e alla fine di un processo. iniziali intermedi finali -45 BPMN: gli eventi iniziali Indicano le condizioni scatenanti il particolare evento il processo inizia! Time: E ora!, è passato quanto doveva passare! Multiple: Qualcosa di complesso si è appena verificato Rule: Si è verificata una certa condizione, quindi (secondo una regola ben precisa) Start: Inizia il processo! (senza troppi motivi) Message: E arrivato un messaggio!, un dato è disponibile!

24 BPMN: gli eventi intermedi Message: E arrivato un messaggio!, un dato è disponibile! Compensation: C è bisogno di annullare quanto fatto e ripristinare una situazione accettabile. Time: E ora!, è passato quanto doveva passare! Multiple: Qualcosa di complesso si è appena verificato Error: E stato compiuto un errore. Operazione annullata Rule: Si è verificata una certa condizione, quindi (secondo una regola ben precisa) -47 BPMN: eventi intermedi Rappresentano ciò che può succedere durante la normale esecuzione di un processo. Richiedere Cartella Clinica Arrivo da altro ospedale Esegui Anamnesi Possono rappresentare la risposta ad un evento ( ad es.: l arrivo di un messaggio, come sopra). Oppure la creazione di un evento (l invio di un messaggio)

25 BPMN: eventi intermedi Quando un evento intermedio è collocato sul bordo di una attività, significa che l attività stessa dovrebbe essere interrotta qualora l evento accada. Attesa di miglioramento dopo 24 ore Aumentare antibiotici Possono essere usati per gestire le eccezioni e per tener conto delle emergenze. -49 BPMN: gli eventi finali Indicano i risultati del particolare evento il processo è terminato. Multiple: Alla fine del processo, si avranno molti effetti. Compensation: Alla fine del processo si dovrà aggiustare un po le cose. Error Il processo è terminato perché è stato compiuto un errore. Message: Alla fine del processo sarà disponibile un messaggio. End: Termina il processo! (senza troppe spiegazioni)

26 BPMN: i gateway I gateway sono elementi che usiamo per instradare il flusso delle attività. Solitamente sono posti al bivio tra due (o più alternative) Possono sia dividere che unire diverse strade di attività. Si usano quando il flusso deve essere controllato, cioè quando più cose possono essere fatte in parallelo alcune strade sono alternative ad altre. -51 BPMN: i gateway I gateway possono essere di 4 tipi: Esclusivi X basati su dati basati su eventi Inclusivi Complessi Paralleli + questo può essere usato per unire due percorsi uguali da un certo punto in avanti

27 BPMN: i gateway esclusivi I gateway esclusivi rappresentano punti in cui il processo può prendere una sola di due o più strade alternative, in base: ad una certa condizione (guard condition) vera sui dati presenti nel sistema. Esame TC all occorrenza di un certo evento. Proporre Alternativa Donna Incinta? X S N Proporre Alternativa Eseguire TC OK Eseguire Alternativa Annullare Esame -53 BPMN: i gateway inclusivi I gateway inclusivi rappresentano punti in cui il processo prende due o più strade eventualmente in parallelo. Stampa Digitale sincronizzazione Esecuzione Esame Scrittura + + Referto Inviare Referto Creazione scheda

28 BPMN: i gateway paralleli I gateway inclusivi rappresentano punti in cui il processo può prendere una o più strade. Richiesto Modo A Eseguire Modo A Richiesta Referto Rich. B Eseguire Modo B Inviare Referto Richiesto Modo C Eseguire Modo C -55 Scenari A questo punto possiamo vedere gli scenari come una particolare sequenza di attività da uno stato iniziale ad uno stato finale. un processo rappresenta più scenari, cioè più modi di arrivare al traguardo a partire dallo start! X X scenario 1 scenario 2 scenario

29 Diagrammi di collaborazione I diagrammi di collaborazione e di sequenza mostrano come le entità interagiscono per raggiungere un certo obiettivo. Per questo possono rappresentare molto bene l esploso di una singola attività. L idea è rappresentare gli scambi di dati (messaggi) tra le entità coinvolte, mostrando i flussi e dando delle indicazioni di ordine cronologico (si enumerano i messaggi nell ordine in cui accadono). 1: detta il referto 2: consegna il referto 3: consegna il referto firmato 4: pubblica il referto -57 Diagrammi di collaborazione Non ci possono essere flussi di dati dove non c è anche una associazione quindi un diagramma di collaborazione è un buon modo per validare (verificare) un diagramma delle entità. Anche in questo diagramma ci sono le [guard condition] (sul flusso dei dati) I messaggi possono essere sincroni cioè richiedono un riscontro o una risposta (una freccia tratteggiata in verso contrario) asincrono (non si richiede riscontro, nessuna freccia di ritorno)