Sequenza Schema Per Online Trading System

sequenza di diagrammi UML modello il flusso della logica all'interno del vostro sistema in modo visivo, consentendo sia di documentare e validare la logica, e sono comunemente usati sia per scopi di analisi e progettazione. diagrammi di sequenza sono più popolari manufatto UML per la modellazione dinamica, che si concentra sulla identificazione del comportamento all'interno del vostro sistema. Altre tecniche di modellazione dinamica includono attività di diagrammi. diagrammi di comunicazione. tempi di diagrammi. e una panoramica interazione diagrammi. diagrammi di sequenza, insieme a diagrammi di classe e modelli di dati fisici sono a mio parere i più importanti modelli di progettazione a livello di moderna lo sviluppo di applicazioni di business. diagrammi di sequenza sono tipicamente utilizzati per il modello: scenari di utilizzo. Uno scenario di utilizzo è la descrizione di un potenziale modo il sistema viene utilizzato. La logica di uno scenario di utilizzo può essere parte di un caso d'uso, forse un percorso alternativo. Può anche essere un intero passaggio attraverso un caso d'uso, come la logica descritta dal corso base di azione o una porzione del corso base di azione, più una o più scenari alternativi. La logica di uno scenario di utilizzo può essere anche un passaggio attraverso la logica contenuta in diversi casi di utilizzo. Ad esempio, uno studente si iscrive all'università, e poi si iscrive subito in tre seminari. La logica di metodi. I diagrammi di sequenza possono essere usati per esplorare la logica di una complessa operazione, una funzione o procedura. Un modo di pensare a diagrammi di sequenza, in particolare gli schemi altamente dettagliati, è come codice oggetto visivo. La logica di servizi. Un servizio è efficace un metodo di alto livello, spesso uno che può essere richiamato da una vasta gamma di clienti. Questo include servizi web così come le transazioni commerciali attuate da una varietà di tecnologie, come CICSCOBOL o broker di richiesta oggetto CORBA-compliant (ORB). Consente di iniziare con tre semplici esempi. La figura 1 illustra un diagramma di sequenza UML per l'Iscrizione presso l'Università caso d'uso, adottando un approccio a livello di sistema dove vengono mostrate le interazioni tra gli attori e il sistema. La figura 2 illustra un diagramma di sequenza per la logica dettagliata di un servizio per determinare se il richiedente è già uno studente all'università. La figura 3 mostra la logica per come iscriversi a un seminario. Io spesso sviluppare un diagramma di sequenza a livello di sistema con le mie parti interessate per aiutare a visualizzare e validare sia la logica di uno scenario di utilizzo. Mi aiuta anche a identificare methodsservices significativi, come ad esempio il controllo per vedere se il richiedente è già da studente, che il mio sistema deve supportare. Figura 1. a livello di sistema diagramma di sequenza. Il motivo per cui theyre chiamato diagrammi di sequenza dovrebbe essere ovvio: la natura sequenziale della logica viene visualizzato tramite l'ordinamento dei messaggi (le frecce orizzontali). Il primo messaggio inizia in alto a sinistra, appare il messaggio successivo appena sotto quello, e così via. Le caselle nella parte superiore del diagramma rappresentano classificatori o dei loro casi, utilizzano in genere i casi, oggetti, classi, o attori. Poiché è possibile inviare messaggi a entrambi gli oggetti e le classi, oggetti rispondono ai messaggi attraverso l'invocazione di un'operazione e le classi fanno attraverso l'invocazione delle operazioni statiche, ha senso per includere sia su diagrammi di sequenza. Perché attori avviare e partecipano attivamente in scenari di utilizzo, possono anche essere inclusi in diagrammi di sequenza. Gli oggetti hanno etichette nel nome di formato standard di UML: ClassName, dove nome è facoltativo (oggetti che havent stato dato un nome sul diagramma sono chiamati oggetti anonimi). Le classi hanno etichette in formato ClassName. e gli attori hanno nomi nel nome del formato attore. Si noti come le etichette degli oggetti sono sottolineate, le classi e gli attori non sono. Ad esempio, nella figura 3. si vede l'oggetto Student ha il nome aStudent. questo si chiama un oggetto con nome, mentre l'istanza di seminario è un oggetto anonimo. L'istanza di studenti è stato dato un nome perché è usato in diversi luoghi come parametro nei messaggi, mentre non ha ancora bisogno l'istanza del seminario a cui fare riferimento in qualsiasi altro luogo nel diagramma e quindi potrebbe essere anonimi. Nella figura 2 la classe Student invia messaggi alla classe PersistenceFramework (che avrebbe potuto essere dato il ltltinfrastructuregtgt stereotipo, ma non era di mantenere il semplice diagramma). Qualsiasi messaggio inviato a una classe è implementata come un metodo statico, più in seguito. Le linee tratteggiate che pendono dalle scatole sono chiamati linee di vita degli oggetti, che rappresenta la durata di vita degli oggetti durante lo scenario in corso di modellazione. Le lunghe, scatole sottili sulle linee di vita sono scatole di attivazione, chiamati anche scatole metodo-invocazione, che indicano l'elaborazione viene eseguita dal objectclass obiettivo di realizzare un messaggio. Mi limito a disegnare scatole di attivazione quando Im utilizzando uno strumento che li supporta in modo nativo, come ad esempio uno strumento CASE sofisticato, e quando voglio esplorare i problemi di prestazioni. scatole di attivazione sono troppo scomodo per disegnare su lavagne o con semplici strumenti di disegno in modo che Non li supportano facilmente. La X sul fondo di una scatola di attivazione, un esempio dei quali è illustrato nella Figura 4. è una convenzione UML per indicare un oggetto è stato rimosso dalla memoria. In linguaggi come C in cui è necessario gestire la memoria se stessi è necessario richiamare un distruttore oggetti, tipicamente modellato un messaggio con lo stereotipo del ltltdestroygtgt. In linguaggi come Java o C dove la memoria è gestita per voi e per gli oggetti che non sono più necessari sono rimossi automaticamente dalla memoria, qualcosa spesso definito come la raccolta dei rifiuti, non è necessario per modellare il messaggio. Io generalmente non perdete tempo con la distruzione modellazione degli oggetti a tutti e sarà invece la fiducia che i programmatori, spesso mi, attueranno dettagli di basso livello, come questo in modo appropriato. Figura 4 presenta un diagramma di sequenza UML complesso per il corso base di azione per l'Iscrizione nel caso d'uso Seminario. Questo è un modo alternativo per modellare la logica di un scenario di utilizzo, invece di farlo a livello di sistema, come la Figura 1 è sufficiente immerge direttamente nel modellare la logica dettagliata a livello di oggetto. Ill prendere questo approccio quando sto lavorando con gli sviluppatori che hanno esperienza diagrammers sequenza e ho un grande spazio di lavoro (un enorme lavagna o uno strumento CASE installato su una stazione di lavoro con uno schermo molto grande e buona scheda grafica). Il più delle volte gli schemi a livello di sistema Ill disegnare e poi creare piccole diagrammi sulla falsariga di ciò che viene mostrato nelle figure 2 e 3. Figura 4. Corso base di azione per l'Iscrizione nel caso d'uso Seminario. I messaggi sono indicati sul diagrammi di sequenza UML come frecce etichettate, quando l'origine e la destinazione di un messaggio è un oggetto o di classe l'etichetta è la firma del metodo richiamato in risposta al messaggio. Tuttavia, se di origine o di destinazione è un attore umano, allora il messaggio è etichettato con breve testo che descrive le informazioni che vengono comunicate. Ad esempio, nella figura 4 l'oggetto EnrollInSeminar invia il messaggio isEligibleToEnroll (theStudent) per l'istanza di seminario. Si noti come includo sia il nome metodi e il nome dei parametri, se presenti, passai in esso. L'attore Student fornisce informazioni all'oggetto SecurityLogon tramite i messaggi nome e il numero degli studenti (questi realmente arent messaggi, in realtà sono le interazioni degli utenti) etichettati. I valori restituiti sono opzionalmente indicati con una freccia tratteggiata con un'etichetta che indica il valore di ritorno. Ad esempio, il valore di ritorno theStudent è indicato ritorno dalla classe Student come il risultato di invocare un messaggio, mentre nessun valore di ritorno è indicato come il risultato di invio del messaggio isEligibleToEnroll (theStudent) per un seminario. Il mio stile non è quello di indicare i valori di ritorno quando la sua evidente ciò che viene restituito, così io non ingombrare i miei diagrammi di sequenza (come si può vedere, i diagrammi di sequenza si complicano abbastanza rapidamente). La Figura 5 mostra un modo alternativo per indicare valori restituiti utilizzando il messaggio in formato: returnValue per i messaggi, come si può vedere con isEligibleToEnroll (theStudent): falso. Si noti l'uso di stereotipi in tutto il diagramma. Per le scatole, ho applicato gli stereotipi ltltactorgtgt, ltltcontrollergtgt, e ltltUIgtgt indicando rappresentano un attore, una classe controller, o di una classe di interfaccia utente (UI), rispettivamente. Ive ha anche usato stereotipi visivi su alcuni diagrammi una figura stilizzata per gli attori delle diagramma robustezza stereotipi visivi per controllore, interfaccia, e oggetti entità e di un tamburo per il database. Gli stereotipi sono utilizzati anche sui messaggi. Pratica comune su diagrammi UML è quello di indicare i messaggi di creazione e distruzione con gli stereotipi del ltltcreategtgt e ltltdestroygtgt, rispettivamente. Per esempio, si vede l'oggetto SecurityLogon si crea in questo modo (in realtà, questo messaggio sarebbe probabilmente essere inviato alla classe che avrebbe poi tradursi in un valore di ritorno l'oggetto creato, quindi ho barato un po '). Questo oggetto successivamente si distrugge in modo simile, presumibilmente quando la finestra è chiusa. Ho usato una nota di UML in figura 4 note sono testo sostanzialmente a forma libera che può essere posizionato su qualsiasi diagramma UML, per fornire un colpo di testa per il diagramma, indicando il titolo e identificativo (come avrete notato, io do identificatori univoci a tutti artefatti che intendo mantenere). Le note sono raffigurati come un pezzo di carta con l'angolo in alto a destra ripiegato. Ho anche usato una nota per indicare il lavoro futuro che deve essere fatto, sia durante l'analisi o di design, in questo schema, le qualifiche () messaggio probabilmente rappresenta una serie di messaggi inviati all'oggetto studente. La pratica comune UML è ancorare una nota ad un altro elemento del modello con una linea tratteggiata quando appropriato, in questo caso la nota è allegata al messaggio. Sebbene Figura 4 modelli della logica del corso base di azione per l'Iscrizione nel caso d'uso Seminario come si va sulla modellazione corsi alternativi Il modo più semplice per farlo è quello di creare un unico diagramma di sequenza per ogni corso alternativo, come si vede raffigurato in Figura 5. Questo schema modelli solo la logica del corso alternativo, come si può dire per la numerazione dei passi sul lato sinistro del diagramma, e la nota di testa per il diagramma indica che si tratta di un corso alternativo di azione. si noti inoltre come l'ID di questo diagramma comprende che questo è ovviamente alternativo C, l'ennesima regola modellazione empirica ho trovato utile nel corso degli anni. Consente di considerare altra sequenza di diagrammi di notazione. Figura 5 include un messaggio iniziale, studente sceglie seminario. che è indicato dal pieno in cerchio. Questo avrebbe potuto facilmente essere indicato tramite una chiamata di metodo, forse enrollIn (seminario). La figura 6 mostra un altro modo per indicare creazione dell'oggetto inviare il nuovo messaggio a una classe. Weve effettivamente visto tre modi per raggiungere questo obiettivo, gli altri due sono per inviare un messaggio con il Andor ltltcreategtgt stereotipo per inviare un messaggio nel lato del simbolo classificatore (ad esempio in figura 4 il messaggio di entrare nel lato di EnrollInSeminar o in Figura 6 il messaggio sta nel lato di StudentInfoPage. il mio consiglio è quello di scegliere uno stile e bastone ad esso. figure 6 e 7 ogni raffigurano un modo per indicare loop logica. un modo è quello di mostrare una cornice con il ciclo etichetta e un vincolo che indica ciò che viene in loop attraverso, come ad ogni seminario in Figura 6. un altro approccio è quello di precedere semplicemente un messaggio che verrà richiamato più volte con un asterisco, come si vede in figura 7 con l'inclusione del iscrizione in caso d'uso seminario. Figura 6 include un messaggio asincrono, il messaggio alla stampante sistema che ha la freccia parziale. un messaggio asincrono è quella in cui il mittente doesnt attendere il risultato del messaggio, invece elabora il risultato quando e se mai ritorna. Fino a questo punto tutti gli altri messaggi sono stati sincrona, messaggi in cui il mittente attende il risultato prima di proseguire. E 'comune per inviare messaggi asincroni a dispositivi hardware o servizi software autonomi come gli autobus di messaggi. Il metodo di modellare l'inclusione di casi d'uso che utilizzano in figura 7 è una cosa che ho proposto in The Elements of Style UML, anche se non ho alcun dubbio che altri usano questo approccio pure. Mostro fondamentalmente il caso d'uso come una bolla nella parte superiore del diagramma, proprio come qualsiasi altro classificatore, e mostrare un messaggio inviato ad esso con lo stereotipo ltltincludegtgt. Ciò è coerente con entrambi i casi l'uso di diagrammi e la sequenza di diagrammi pratiche. Figura 7 è interessante anche perché mostra come modellare la logica condizionale. In questo caso, una cornice con l'alt etichetta è usato insieme a una guardia, in questo caso ricorrente in lista ammissibilità. Il telaio è diviso in regioni separate da linee tratteggiate. In questo caso ci sono due regioni, una per ciascuna alternativa, anche se si può avere come molte regioni desiderata (per sostenere l'equivalente visivo di un'istruzione case). Ogni regione richiede una guardia. Visivo codifica Con diagrammi di sequenza precedenza ho affermato che diagrammi di sequenza sono effettivamente una forma di codificazione visiva, o forse un altro modo di pensare di questo è che i diagrammi di sequenza possono essere utilizzati per la progettazione molto dettagliata. Quando ho sviluppato il diagramma di sequenza di figura 4 Ho fatto diverse decisioni che potrebbero intaccare i miei altri modelli. Per esempio, come ho modellato Passo 10, ho preso la decisione di progettazione che il display tassa anche gestito la verifica da parte dello studente che le tasse erano accettabili. Inoltre, come mi è stato di modellazione i punti 2 e 3, sono arrivato alla realizzazione che gli studenti dovrebbero probabilmente password per entrare nel sistema. Quando sei alla luce delle prassi AM di partecipazione attiva dei soggetti interessati e Modello Con altri è facile capire se le idee di questo tipo ha senso, perché tutto quello che dovete fare è chiedere. In questo caso ho scoperto che mi sbagliavo: la combinazione di nome e studente il numero è unico sufficiente per i nostri scopi e non ha ancora all'università vogliono la complessità di gestione delle password. Si tratta di una decisione interessante che potrebbe potenzialmente essere registrato come una regola aziendale, perché è una politica di funzionamento dell'università, che indica la necessità di seguire la Iterate pratica per un altro artefatto e annotare la regola, se sono interessati a mantenere una registrazione permanente di esso . Come disegnare diagrammi di sequenza Ive cercato di spiegare alla gente come disegnare diagrammi di sequenza per anni, e che cosa Ive ha scoperto è che le persone che ottengono lo sono sia molto bravo a pensare in un Andor modo logico che sono bravo a scrivere codice software. Sequenza di diagrammi è davvero codifica visiva, anche quando si sta modellando un scenario di utilizzo tramite un diagramma di sequenza a livello di sistema. Quando sono la creazione di un diagramma di sequenza di avvio Ill individuando la portata di quello che sto cercando di modellare, e perché preferisco seguire la prassi Modello AM in piccoli incrementi Ill tipicamente affrontare scenari di utilizzo di piccole dimensioni a livello di sistema o di un singolo methodservice l'oggetto dettagliata livello. Un diagramma come la figura 4 è troppo complesso per essere utile nella mia esperienza. Ill poi lavorare attraverso la logica con almeno una persona in più, che colloca classificatori attraverso la parte superiore, come ho bisogno di loro. Aggiungo automaticamente le linee di vita degli oggetti, ma come ho detto in precedenza in genere non investire tempo l'aggiunta di caselle di attivazione. Il cuore del diagramma è nei messaggi che aggiungo al diagramma uno alla volta mentre lavoro attraverso la logica. Raramente mi indicano i valori di ritorno, invece Ill dare messaggi nomi intelligenti che spesso rendono chiaro ciò che viene restituito. E 'interessante notare che, come si Sequence Diagram si individuare nuove responsabilità per le classi e gli oggetti, e, talvolta, persino nuove classi. L'implicazione è che si può decidere di aggiornare il modello di classe in modo appropriato, modellatori agili seguiranno la prassi creare diversi modelli in parallelo. qualcosa che gli strumenti CASE farà automaticamente. Ricordate, ogni messaggio inviato a una classe richiama un methodoperation statica su quella classe di ciascun messaggio inviato a un oggetto invoca una operazione su tale oggetto. Per quanto riguarda le questioni di stile per la sequenza di diagrammi, preferisco disegnare i messaggi che vanno da sinistra a destra e restituire valori da destra a sinistra, anche se quello non funziona sempre con objectsclasses complesse. Mi giustifico l'etichetta su messaggi e valori di ritorno, quindi sono più vicino alla punta della freccia. Ho anche preferisco strato i diagrammi di sequenza: da sinistra a destra. Indico gli attori, allora la classe controllore (es), e poi la classe di interfaccia utente (es), e, infine, la classe business (es). Durante la progettazione, è probabilmente necessario aggiungere del sistema e la persistenza classi, che di solito messo sul lato più a destra dei diagrammi di sequenza. Posa i diagrammi di sequenza in questo modo spesso li rende più facili da leggere e rende anche più facile trovare problemi di logica stratificazione, come le classi di interfaccia utente che accede direttamente classi di persistenza. Tenendolo Agile Le cose più importanti che si possono fare è quello di mantenere i diagrammi semplici, sia il contenuto saggio e strumento di saggio. Io schizzo diagrammi di sequenza su lavagne a pensare qualcosa attraverso, sia per verificare la logica in un caso d'uso o per la progettazione di un metodo o un servizio. Raramente mi tengo diagrammi di sequenza come trovo il loro vero valore è nella loro creazione. Un errore comune è quello di cercare di creare un set completo di diagrammi di sequenza per il sistema. Ive team di progetto visto sprecano mesi la creazione di diversi diagrammi di sequenza per ciascuno dei loro casi d'uso, una per il corso base di azione e di uno per ogni corso alternativo. Il mio consiglio è di creare solo un diagramma di sequenza quando si dispone di una logica complessa che si vuole pensare attraverso se la logica è semplice il diagramma di sequenza solito aggiungere qualsiasi valore, si doveva potrebbe anche andare direttamente al codice. La notazione usata in questi diagrammi, in particolare quelli disegnati a mano, potrebbe non essere conforme perfettamente alla versione corrente di UML per uno o più dei motivi: la notazione potrebbe essersi evoluto da quando ho originariamente sviluppato i diagrammi. L'UML evolve nel tempo, e non può aver mantenuto gli schemi fino ad oggi. Forse ho ottenuto sbagliato, in primo luogo. Anche se questi schemi sono stati accuratamente recensione per il libro, e sono stati esaminati da migliaia di persone on-line, da allora, un errore può avere ottenuto passato di noi. Erano solo un essere umano. Forse ho scelto di applicare la notazione in modi quotnon-standardquot. Un modellatore agile è più interessato a modelli creati che comunicano in modo efficace rispetto ai conforme alle regole di notazione stabilite da un comitato. E 'probabile che non importa comunque, perché lo strumento di modellazione (s) che state usando probabilmente abituato completamente sostenere l'attuale versione della notazione UML perfettamente in ogni caso. Linea di fondo è che si sta andando ad essere vincolata dai vostri strumenti in ogni caso. Se tu sei davvero preoccupato per le sfumature di quotofficialquot la notazione UML quindi leggere la versione corrente delle specifiche UML. Condividi con gli amici: Bisogno di aiuto Lavoriamo attivamente con i clienti in tutto il mondo per migliorare la loro tecnologia dell'informazione (IT) pratiche, di solito nel ruolo di mentorcoach, team leader, o formatore. Una descrizione completa di ciò che facciamo, e come contattarci, può essere trovato alla Scott Ambler Associates. Consigliato lettura di questo libro, consegna Agile Disciplined: Una guida ai professionisti di Agile Software Delivery in azienda descrive il quadro decisione (DAD) processo Agile consegna disciplinato. Il quadro DAD è un popolo in primo luogo, l'apprendimento orientata ibrido approccio agile alla soluzione IT consegna. Ha una consegna del ciclo di vita del rischio-valore, è l'obiettivo-driven, è impresa a conoscenza, e fornisce la base per il ridimensionamento agile. Questo libro è particolarmente importante per tutti coloro che vogliono capire come funziona agili da end-to-end all'interno di un ambiente aziendale. professionisti dei dati si trova interessante perché mostra come la modellazione agile e tecniche di database agili inseriscono nel processo globale soluzione di consegna. professionisti Enterprise troveranno interessante beause promuove esplicitamente l'idea che le squadre agili disciplinati dovrebbero essere consapevoli di impresa e, pertanto, lavorare a stretto contatto con i team aziendali. Esistenti sviluppatori agili, la troverà interessante perché mostra come estendere le strategie di Scrum-based e basati su Kanban per fornire un coerente processo di consegna semplificato end-to-end. Il primer oggetto 3rd Edition: Agile Modello Driven Development con UML 2 è un importante libro di riferimento per modellatori agili, che descrivono come sviluppare 35 tipi di modelli agili, tra cui tutti i 13 UML 2 diagrammi. Inoltre, questo libro descrive i fondamentali di programmazione e di prova delle tecniche per il successo di consegna soluzione agile. Il libro mostra anche come muoversi dai vostri modelli agili al codice sorgente, come riuscire a tecniche di implementazione, come il refactoring e sviluppo test-driven (TDD). Il primer oggetto comprende anche un capitolo un panorama delle tecniche di sviluppo di database critici (refactoring del database. Mappatura objectrelational. Analisi eredità. E l'accesso al database di codifica) dal mio premiati Agile Tecniche di database book. ConceptDraw campioni business elabora diagrammi UML campioni Software Development Rapid UML Il processi di business UML 2.4 schemi vengono creati con ConceptDraw PRO di diagrammi e di disegno vettoriale software potenziato con una soluzione rapida UML da ConceptDraw Solution Park. ConceptDraw PRO fornisce esportazione di grafica vettoriale documenti di più pagine in più formati di file: grafica vettoriale (SVG, EMF, EPS), grafica bitmap (PNG, JPEG, GIF, BMP, TIFF), documenti web (HTML, PDF), presentazioni PowerPoint (PPT ), Adobe Flash (SWF). Esercitazioni e soluzioni: campione 1: campione UML Activity Diagram UML Activity Diagram: di versamento Processing. Questo esempio è stato creato utilizzando il software ConceptDraw PRO diagrammi migliorato con una soluzione rapida UML da ConceptDraw Solution Park. Esempio 2: il campione UML comunicazione diagramma UML Comunicazione Diagramma. Questo esempio è stato creato utilizzando il software ConceptDraw PRO diagrammi migliorato con una soluzione rapida UML da ConceptDraw Solution Park. Esempio 3: campione UML Sequence Diagram UML Sequence Diagram. Questo esempio è stato creato utilizzando il software ConceptDraw PRO diagrammi migliorato con una soluzione rapida UML da ConceptDraw Solution Park. Esempio 4: UML Use Case Diagram Trading UML Usa Diagram Case System campione: Trading System. Questo esempio è stato creato utilizzando il software ConceptDraw PRO diagrammi migliorato con una soluzione rapida UML da ConceptDraw Solution Park. Tutti i campioni sono protetti da copyright CS Odessas. L'utilizzo di essi è coperto da licenza Creative Commons Attribuzione-Non commerciale Grafica dell'andamento non Derivati ​​License. The sequenza Questo contenuto è parte della serie: nozioni di base UML Restate sintonizzati per ulteriori contenuti in questa serie. Il suo mese di febbraio, e ormai probabilmente avete letto su, o la gente sentito parlare, fare il cambiamento di UML 2.0 - la nuova specifica per UML che contiene una serie di miglioramenti. Data l'importanza della nuova specifica, stiamo cambiando la base di questa serie di articoli, anche, spostando la nostra attenzione dalla OMGs UML 1.4 Specifiche per OMGs adottati 2.0 Progetto specifica di UML (pseudonimo UML 2). Odio di cambiare l'accento 1,4-2,0 nel bel mezzo di una serie di articoli, ma UML 2.0 Progetto specifica è un importante passo avanti, e mi sento il bisogno di diffondere la parola. C'erano un paio di motivi che la OMG migliorata UML. Il motivo principale era che volevano modelli UML di essere in grado di erogare Model Driven Architecture (MDA), il che significa che la UML ha dovuto funzionare come un modello guidato notazione più. Inoltre, la notazione UML 1.xe set era a volte difficile da applicare alle applicazioni più grandi. Inoltre, gli elementi di notazione necessari per essere migliorati al fine di rendere gli schemi più leggibile. (Per esempio, la modellazione flusso logico in UML 1.xe era complicato e, a volte impossibile. Le modifiche della sequenza di diagrammi di notazione di impostare in UML 2 hanno fatto grandi miglioramenti nella logica di modellazione in sequenze.) Scopri di più. Sviluppare di più. Collegare più. Uno dei vantaggi di developerWorks Premium è l'accesso a più di 500 libri e video conferenza dalla libreria Safari. Alcuni titoli che potrebbero interessarti sono: Patterns of Enterprise Application Architecture Java Application Architecture UML distillati: una breve guida per la standard Object Modeling Language OReilly Software Architecture Conference 2015 completa del video compilazione Scopri tutto quello che developerWorks Premium ha da offrire e diventare un membro oggi. Si noti la formulazione della mia dichiarazione di cui sopra: adottato 2.0 Progetto specifica di UML. E 'vero che la specifica è ancora in stato di bozza, ma la chiave è che il progetto di specifica è stata adottata da OMG, un consorzio che non adottare nuovi standard fino a diventare abbastanza solido. Ci saranno alcune modifiche alla specifica prima UML 2 è completamente adottati, ma questi cambiamenti dovrebbe essere minimo. Le principali modifiche saranno la struttura interna di UML - che coinvolga la tecnologia tipicamente utilizzati dalle aziende di software che implementano strumenti UML. Lo scopo principale di questo articolo è quello di continuare la nostra attenzione sugli schemi essenziali UML questo mese, diamo uno sguardo da vicino al diagramma di sequenza. Si prega di notare, ancora una volta, che gli esempi forniti di seguito sono basati sulla nuova specifica UML 2. Lo scopo diagrammi Il diagramma di sequenza viene utilizzato principalmente per mostrare le interazioni tra gli oggetti in ordine sequenziale che si verificano tali interazioni. Molto simile al diagramma delle classi, gli sviluppatori di solito pensano diagrammi di sequenza sono stati pensati esclusivamente per loro. Tuttavia, uno staff organizzazioni imprenditoriali possono trovare diagrammi di sequenza utile per comunicare come l'azienda attualmente funziona, mostrando come i vari oggetti di business interagiscono. Oltre a documentare una delle organizzazioni di attualità, un diagramma di sequenza-livello di business può essere utilizzato come un documento dei requisiti per comunicare i requisiti per l'implementazione del sistema futuro. Durante i requisiti fase di un progetto, gli analisti possono prendere casi d'uso al livello successivo, fornendo un livello più formale di raffinatezza. Quando ciò si verifica, casi d'uso sono spesso raffinati in uno o più diagrammi di sequenza. Uno staff tecnico organizzazioni possono trovare diagrammi di sequenza utili a documentare come un futuro sistema dovrebbe comportarsi. Durante la fase di progettazione, gli architetti e gli sviluppatori possono utilizzare lo schema per forzare i sistemi oggetto interazioni, scarnatura quindi fuori progettazione del sistema nel suo complesso. Distribuire con fiducia Coerentemente fornire software di alta qualità più velocemente utilizzando i servizi DevOps su IBM bluemix. Iscriviti per una prova gratuita bluemix nuvola. e iniziare. Uno degli usi principali di diagrammi di sequenza è nel passaggio da esigenze espresse come casi d'uso al livello successivo e più formale di raffinatezza. I casi d'uso sono spesso raffinati in uno o più diagrammi di sequenza. Oltre al loro utilizzo nella progettazione di nuovi sistemi, diagrammi di sequenza possono essere usati per documentare come gli oggetti in un sistema esistente (lo chiamano legacy) attualmente interagiscono. Questa documentazione è molto utile durante la transizione di un sistema ad un'altra persona o organizzazione. La notazione Poiché questo è il primo articolo nel mio UML serie diagramma che si basa su UML 2, dobbiamo discutere prima un'aggiunta alla notazione UML 2 diagrammi, vale a dire un elemento notazione detta fotogramma. L'elemento telaio è utilizzato come base per molti altri elementi dei diagrammi in UML 2, ma il primo posto maggior parte delle persone si incontra un elemento telaio è come confine grafica di un diagramma. Una cornice elemento fornisce un posto coerente per un'etichetta diagrammi, mentre fornisce un confine grafica per il diagramma. L'elemento di struttura è opzionale in diagrammi UML come si può vedere nelle figure 1 e 2, l'etichetta diagrammi è posizionato nell'angolo in alto a sinistra in quello che Ill chiamare il namebox fotogrammi, una sorta di rettangolo di cane dalle orecchie, e il diagramma effettivo UML è definita all'interno del corpo del grande rettangolo che racchiude. Figura 1. Un vuoto UML 2 cornice elemento Oltre a fornire un bordo visiva, l'elemento di telaio ha anche un importante uso funzionale nei diagrammi raffiguranti interazioni, come il diagramma di sequenza. Su diagrammi di sequenza messaggi in entrata e in uscita (note anche come le interazioni) per una sequenza può essere modellato collegando i messaggi al confine dell'elemento telaio (come si vede in figura 2). Ciò sarà discusso in maggiore dettaglio nella Beyond sezione di base sottostante. Figura 2. Un diagramma di sequenza che ha messaggi in entrata e in uscita noti che nella figura 2 l'etichetta diagrammi inizia con la sd lettere, per diagramma di sequenza. Quando si utilizza un elemento di cornice per racchiudere un diagramma, l'etichetta diagrammi deve seguire il formato: La specifica UML fornisce valori di testo specifici per i tipi di diagrammi (ad esempio SD Sequence Diagram, attività Attività Diagramma, e l'uso caso d'uso diagramma caso). Le basi Lo scopo principale di un diagramma di sequenza è di definire sequenze di eventi che portano a qualche risultato desiderato. L'attenzione si concentra meno sui messaggi stessi e più l'ordine in cui i messaggi si verificano, tuttavia, la maggior parte dei diagrammi di sequenza comunicheranno quali messaggi inviati tra un sistema di oggetti così come l'ordine in cui si verificano. Il diagramma trasmette queste informazioni lungo le dimensioni orizzontali e verticali: la dimensione verticale mostra, dall'alto verso il basso, la sequenza temporale di messagescalls in cui si verificano, e gli spettacoli dimensione orizzontale, da sinistra a destra, le istanze di oggetti che i messaggi vengono inviati. Quando si disegna un diagramma di sequenza, gli elementi di notazione del cavo di sicurezza sono posizionati nella parte superiore del diagramma. Lifelines rappresentano sia ruoli o istanze di oggetti che partecipano nella sequenza in corso di modellazione. Nota: Nei sistemi completamente modellati saranno modellati gli oggetti (istanze di classi) su un diagramma delle classi di sistemi. Lifelines sono disegnati come una scatola con una linea tratteggiata decrescente dal centro del bordo inferiore (figura 3). Il nome cavi di sicurezza è collocato all'interno della scatola. Figura 3. Un esempio di classe Student utilizzato in un cavo di sicurezza il cui nome dell'istanza è matricola Lo standard UML per la denominazione una linea di vita segue il formato di: Nell'esempio mostrato in figura 3, la linea di vita rappresenta un'istanza della classe di studenti, il cui esempio nome è matricola. Si noti che, qui, il nome ancora di salvezza è sottolineato. Quando si utilizza una sottolineatura, significa che la linea di vita rappresenta una specifica istanza di una classe in un diagramma di sequenza, e non un particolare tipo di istanza (cioè un ruolo). In un prossimo articolo ben guardare la modellazione della struttura. Per ora, basta osservare che i diagrammi di sequenza può includere ruoli (come acquirente e venditore) senza specificare che interpreta quei ruoli (come Bill e Fred). Questo permette schema riutilizzo in differenti contesti. In poche parole, i nomi di istanza in diagrammi di sequenza sono sottolineate nomi ruoli non sono. Il nostro esempio ancora di salvezza in figura 3 è un oggetto di nome, ma non tutte le linee di vita rappresentano oggetti con nome. Invece un cavo di sicurezza può essere utilizzato per rappresentare un'istanza anonima o senza nome. Quando la modellazione un'istanza senza nome su un diagramma di sequenza, il nome draglie segue lo stesso modello come istanza denominata, ma invece di fornire il nome di un'istanza, quella parte del nome draglie viene lasciato vuoto. Anche in questo caso con riferimento alla figura 3, se l'ancora di salvezza è che rappresenta un'istanza anonima della classe Student, l'ancora di salvezza sarebbe: Student. Also, because sequence diagrams are used during the design phase of projects, it is completely legitimate to have an object whose type is unspecified: for example, freshman. The first message of a sequence diagram always starts at the top and is typically located on the left side of the diagram for readability. Subsequent messages are then added to the diagram slightly lower then the previous message. To show an object (i. e. lifeline) sending a message to another object, you draw a line to the receiving object with a solid arrowhead (if a synchronous call operation) or with a stick arrowhead (if an asynchronous signal). The messagemethod name is placed above the arrowed line. The message that is being sent to the receiving object represents an operationmethod that the receiving objects class implements. In the example in Figure 4, the analyst object makes a call to the system object which is an instance of the ReportingSystem class. The analyst object is calling the system objects getAvailableReports method. The system object then calls the getSecurityClearance method with the argument of userId on the secSystem object, which is of the class type SecuritySystem. Note: When reading this sequence diagram, assume that the analyst has already logged into the system. Figure 4. An example of messages being sent between objects Besides just showing message calls on the sequence diagram, the Figure 4 diagram includes return messages. These return messages are optional a return message is drawn as a dotted line with an open arrowhead back to the originating lifeline, and above this dotted line you place the return value from the operation. In Figure 4 the secSystem object returns userClearance to the system object when the getSecurityClearance method is called. The system object returns availableReports when the getAvailableReports method is called. Again, the return messages are an optional part of a sequence diagram. The use of return messages depends on the level of detailabstraction that is being modeled. Return messages are useful if finer detail is required otherwise, the invocation message is sufficient. I personally like to include return messages whenever a value will be returned, because I find the extra details make a sequence diagram easier to read. When modeling a sequence diagram, there will be times that an object will need to send a message to itself. When does an object call itself A purist would argue that an object should never send a message to itself. However, modeling an object sending a message to itself can be useful in some cases. For example, Figure 5 is an improved version of Figure 4. The Figure 5 version shows the system object calling its determineAvailableReports method. By showing the system sending itself the message determineAvailableReports, the model draws attention to the fact that this processing takes place in the system object. To draw an object calling itself, you draw a message as you would normally, but instead of connecting it to another object, you connect the message back to the object itself. Figure 5. The system object calling its determineAvailableReports method The example messages in Figure 5 show synchronous messages however, in sequence diagrams you can model asynchronous messages, too. An asynchronous message is drawn similar to a synchronous one, but the messages line is drawn with a stick arrowhead, as shown in Figure 6. Figure 6. A sequence diagram fragment showing an asynchronous message being sent to instance2 When modeling object interactions, there will be times when a condition must be met for a message to be sent to the object. Guards are used throughout UML diagrams to control flow. Here, I will discuss guards in both UML 1.x as well as UML 2.0. In UML 1.x, a guard could only be assigned to a single message. To draw a guard on a sequence diagram in UML 1.x, you placed the guard element above the message line being guarded and in front of the message name. Figure 7 shows a fragment of a sequence diagram with a guard on the message addStudent method. Figure 7. A segment of a UML 1.x sequence diagram in which the addStudent message has a guard In Figure 7, the guard is the text pastDueBalance 0. By having the guard on this message, the addStudent message will only be sent if the accounts receivable system returns a past due balance of zero. The notation of a guard is very simple the format is: Combined fragments (alternatives, options, and loops) In most sequence diagrams, however, the UML 1.x in-line guard is not sufficient to handle the logic required for a sequence being modeled. This lack of functionality was a problem in UML 1.x. UML 2 has addressed this problem by removing the in-line guard and adding a notation element called a Combined Fragment. A combined fragment is used to group sets of messages together to show conditional flow in a sequence diagram. The UML 2 specification identifies 11 interaction types for combined fragments. Three of the eleven will be covered here in The Basics section, two more types will be covered in the Beyond The Basics section, and the remaining six I will leave to be covered in another article. (Hey, this is an article, not a book. I want you to finish this piece in one day) Alternatives Alternatives are used to designate a mutually exclusive choice between two or more message sequences. Note: It is indeed possible for two or more guard conditions attached to different alternative operands to be true at the same time, but at most only one operand will actually occur at run time (which alternative wins in such cases is not defined by the UML standard). Alternatives allow the modeling of the classic if then else logic (e. g. if I buy three items, then I get 20 off my purchase else I get 10 off my purchase). As you will notice in Figure 8, an alternative combination fragment element is drawn using a frame. The word alt is placed inside the frames namebox. The larger rectangle is then divided into what UML 2 calls operands. Note: Although operands look a lot like lanes on a highway, I specifically did not call them lanes. Swim lanes are a UML notation used on activity diagrams. Please refer to The Rational Edges earlier article about Activity Diagrams . Operands are separated by a dashed line. Each operand is given a guard to test against, and this guard is placed towards the top left section of the operand on top of a lifeline. Note: Usually, the lifeline to which the guard is attached is the lifeline that owns the variable that is included in the guard expression. If an operands guard equates to true, then that operand is the operand to follow. Figure 8. A sequence diagram fragment that contains an alternative combination fragment As an example to show how an alternative combination fragment is read, Figure 8 shows the sequence starting at the top, with the bank object getting the checks amount and the accounts balance. At this point in the sequence the alternative combination fragment takes over. Because of the guard balance gt amount, if the accounts balance is greater than or equal to the amount, then the sequence continues with the bank object sending the addDebitTransaction and storePhotoOfCheck messages to the account object. However, if the balance is not greater than or equal to the amount, then the sequence proceeds with the bank object sending the addInsuffientFundFee and noteReturnedCheck message to the account object and the returnCheck message to itself. The second sequence is called when the balance is not greater than or equal to the amount because of the else guard. In alternative combination fragments, the else guard is not required and if an operand does not have an explicit guard on it, then the else guard is to be assumed. Alternative combination fragments are not limited to simple if then else tests. There can be as many alternative paths as are needed. If more alternatives are needed, all you must do is add an operand to the rectangle with that sequences guard and messages. The option combination fragment is used to model a sequence that, given a certain condition, will occur otherwise, the sequence does not occur. An option is used to model a simple if then statement (i. e. if there are fewer than five donuts on the shelf, then make two dozen more donuts). The option combination fragment notation is similar to the alternation combination fragment, except that it only has one operand and there never can be an else guard (it just does not make sense here). To draw an option combination you draw a frame. The text opt is placed inside the frames namebox, and in the frames content area the options guard is placed towards the top left corner on top of a lifeline. Then the options sequence of messages is placed in the remainder of the frames content area. These elements are illustrated in Figure 9. Figure 9. A sequence diagram fragment that includes an option combination fragment Reading an option combination fragment is easy. Figure 9 is a reworking of the sequence diagram fragment in Figure 7, but this time it uses an option combination fragment because more messages need to be sent if the students past due balance is equal to zero. According to the sequence diagram in Figure 9, if a students past due balance equals zero, then the addStudent, getCostOfClass, and chargeForClass messages are sent. If the students past due balance does not equal zero, then the sequence skips sending any of the messages in the option combination fragment. The example Figure 9 sequence diagram fragment includes a guard for the option however, the guard is not a required element. In high-level, abstract sequence diagrams you might not want to specify the condition of the option. You may simply want to indicate that the fragment is optional. Occasionally you will need to model a repetitive sequence. In UML 2, modeling a repeating sequence has been improved with the addition of the loop combination fragment. The loop combination fragment is very similar in appearance to the option combination fragment. You draw a frame, and in the frames namebox the text loop is placed. Inside the frames content area the loops guard is placed towards the top left corner, on top of a lifeline. Note: As with the option combination fragment, the loop combination fragment does not require that a guard condition be placed on it. Then the loops sequence of messages is placed in the remainder of the frames content area. In a loop, a guard can have two special conditions tested against in addition to the standard Boolean test. The special guard conditions are minimum iterations written as minint the number (e. g. minint 1) and maximum iterations written as maxint the number (e. g. maxint 5). With a minimum iterations guard, the loop must execute at least the number of times indicated, whereas with a maximum iterations guard the number of loop executions cannot exceed the number. Figure 10. An example sequence diagram with a loop combination fragment The loop shown in Figure 10 executes until the reportsEnu objects hasAnotherReport message returns false. The loop in this sequence diagram uses a Boolean test to verify if the loop sequence should be run. To read this diagram, you start at the top, as normal. When you get to the loop combination fragment a test is done to see if the value hasAnotherReport equals true. If the hasAnotherReport value equals true, then the sequence goes into the loop fragment. You can then follow the messages in the loop as you would normally in a sequence diagram Beyond the basics Ive covered the basics of the sequence diagram, which should allow you to model most of the interactions that will take place in a common system. The following section will cover more advanced notation elements that can be used in a sequence diagram. Referencing another sequence diagram When doing sequence diagrams, developers love to reuse existing sequence diagrams in their diagrams sequences. Note: It is possible to reuse a sequence diagram of any type (e. g. programming or business). I just find that developers like to functionally break down their diagrams more. Starting in UML 2, the Interaction Occurrence element was introduced. The addition of interaction occurrences is arguably the most important innovation in UML 2 interactions modeling. Interaction occurrences add the ability to compose primitive sequence diagrams into complex sequence diagrams. With these you can combine (reuse) the simpler sequences to produce more complex sequences. This means that you can abstract out a complete, and possibly complex, sequence as a single conceptual unit. An interaction occurrence element is drawn using a frame. The text ref is placed inside the frames namebox, and the name of the sequence diagram being referenced is placed inside the frames content area along with any parameters to the sequence diagram. The notation of the referenced sequence diagrams name follows the pattern of: 1. Retrieve Borrower Credit Report(ssn). borrowerCreditReport 2. Process Credit Card(name, number, expirationDate, amount. 100) In example 1, the syntax calls the sequence diagram called Retrieve Borrower Credit Report and passes it the parameter ssn. The Retreive Borrower Credit Report sequence returns the variable borrowerCreditReport. In example 2, the syntax calls the sequence diagram called Process Credit Card and passes it the parameters of name, number, expiration date, and amount. However, in example 2 the amount parameter will be a value of 100. And since example 2 does not have a return value labeled, the sequence does not return a value (presumably, the sequence being modeled does not need the return value). Figure 11. A sequence diagram that references two different sequence diagrams Figure 11 shows a sequence diagram that references the sequence diagrams Balance Lookup and Debit Account. The sequence starts at the top left, with the customer sending a message to the teller object. The teller object sends a message to the theirBank object. At that point, the Balance Lookup sequence diagram is called, with the accountNumber passed as a parameter. The Balance Lookup sequence diagram returns the balance variable. Then the option combination fragments guard condition is checked to verify the balance is greater then the amount variable. In cases where the balance is greater than the amount, the Debit Account sequence diagram is called, passing it the accountNumber and the amount as parameters. After that sequence is complete, the withdrawCash message returns cash to the customer. It is important to notice in Figure 11 that the lifeline of theirBank is hidden by the interaction occurrence Balance Lookup. Because the interaction occurrence hides the lifeline, that means that the theirBank lifeline is referenced in the Balance Lookup sequence diagram. In addition to hiding the lifeline in the interaction occurrence, UML 2 also specifies that the lifeline must have the same theirBank in its own Balance Lookup sequence. There will be times when you model sequence diagrams that an interaction occurrence will overlap lifelines that are not referenced in the interaction occurrence. In such cases the lifeline is shown as a normal lifeline and is not hidden by the overlapping interaction occurrence. In Figure 11, the sequence references the Balance Lookup sequence diagram. The Balance Lookup sequence diagram is shown in Figure 12. Because the example sequence has parameters and a return value, its label 8212located in the diagrams namebox8212follows a specific pattern: 1. SD Balance Lookup(Integer. accountNumber). Real 2. SD Available Reports(Financial Analyst. analyst). Reports Figure 12 illustrates example 1, in which the Balance Lookup sequence uses parameter accountNumber as a variable in the sequence, and the sequence diagram shows a Real object being returned. In cases such as this, where the sequence returns an object, the object being returned is given the instance name of the sequence diagram. Figure 12. A sequence diagram that takes the parameter of accountNumber and returns a Real object Figure 13 illustrates example 2, in which a sequence takes a parameter and returns an object. However, in Figure 13 the parameter is used in the sequences interaction. Figure 13. A sequence diagram that uses its parameter in its interaction and returns a Reports object The previous section showed how to reference another sequence diagram by passing information through parameters and return values. However, there is another way to pass information between sequence diagrams. Gates can be an easy way to model the passing of information between a sequence diagram and its context. A gate is merely a message that is illustrated with one end connected to the sequence diagrams frames edge and the other end connected to a lifeline. A reworking of Figures 11 and 12 using gates can be seen in Figures 14 and 15. The example diagram in Figure 15 has an entry gate called getBalance that takes the parameter of accountNumber. The getBalance message is an entry gate, because it is the arrowed line that is connected to the diagrams frame with the arrowhead connected to a lifeline. The sequence diagram also has an exit gate that returns the balance variable. The exit gate is known, because its a return message that is connected from a lifeline to the diagrams frame with the arrowhead connected to the frame. Figure 14. A reworking of Figure 11, using gates this time Figure 15. A reworking of Figure 12, using gates this time Combined fragments (break and parallel) In the basics section presented earlier in this paper, I covered the combined fragments known as alternative, option, and loop. These three combined fragments are the ones most people will use the most. However, there are two other combined fragments that a large share of people will find useful 128147 break and parallel. The break combined fragment is almost identical in every way to the option combined fragment, with two exceptions. First, a breaks frame has a namebox with the text break instead of option. Second, when a break combined fragments message is to be executed, the enclosing interactions remainder messages will not be executed because the sequence breaks out of the enclosing interaction. In this way the break combined fragment is much like the break keyword in a programming language like C or Java. Figure 16. A reworking of the sequence diagram fragment from Figure 8, with the fragment using a break instead of an alternative Breaks are most commonly used to model exception handling. Figure 16 is a reworking of Figure 8, but this time Figure 16 uses a break combination fragment because it treats the balance lt amount condition as an exception instead of as an alternative flow. To read Figure 16, you start at the top left corner of the sequence and read down. When the sequence gets to the return value balance, it checks to see if the balance is less than the amount. If the balance is not less than the amount, the next message sent is the addDebitTransaction message, and the sequence continues as normal. However, in cases where the balance is less than the amount, then the sequence enters the break combination fragment and its messages are sent. Once all the messages in the break combination have been sent, the sequence exits without sending any of the remaining messages (e. g. addDebitTransaction). An important thing to note about breaks is that they only cause the exiting of an enclosing interactions sequence and not necessarily the complete sequence depicted in the diagram. In cases where a break combination is part of an alternative or a loop, then only the alternative or loop is exited. Todays modern computer systems are advancing in complexity and at times perform concurrent tasks. When the processing time required to complete portions of a complex task is longer than desired, some systems handle parts of the processing in parallel. The parallel combination fragment element needs to be used when creating a sequence diagram that shows parallel processing activities. The parallel combination fragment is drawn using a frame, and you place the text par in the frames namebox. You then break up the frames content section into horizontal operands separated by a dashed line. Each operand in the frame represents a thread of execution done in parallel. Figure 17. A microwave is an example of an object that does two tasks in parallel While Figure 17 may not illustrate the best computer system example of an object doing activities in parallel, it offers an easy-to-understand example of a sequence with parallel activities. The sequence goes like this: A hungryPerson sends the cookFood message to the oven object. When the oven object receives that message, it sends two messages to itself at the same time (nukeFood and rotateFood). After both of these messages are done, the hungryPerson object is returned yummyFood from the oven object. Conclusion The sequence diagram is a good diagram to use to document a systems requirements and to flush out a systems design. The reason the sequence diagram is so useful is because it shows the interaction logic between the objects in the system in the time order that the interactions take place. Downloadable resources Related topicsSample UML Sequence Diagram The sequence diagram in figure 1 represents an elaboration for the Student Registers for Class use case in an automated student registration system. (Click here to see the diagram without the horizontal dotted guidelines.) Figure 1 - Automated Registration System sample sequence diagram The boxes at the top of the sequence diagram constitute the diagram header and represent the components or units of the system. Sequence diagram editor supports four types of header elements (see the full list of supported sequence diagram elements ): Actors - Actors represent a person or other external entity that interacts with the system. Objects - Objects are used to represent object instances in an object-oriented programming language such as Java or C. Units - Units are used to represent logical entities in the system such as components, servers, threads and tasks that may or may not be implemented using objects. They can also be used to distinguish objects from classes. Separators - Separators do not interact with the diagram but rather represent a boundary between header elements. Sequence diagram header elements can be grouped together (see group elements ) into components or subsystems to illustrate the logical layering of the system. In Figure 1, the web server components are grouped together into the Web Server group to indicate that these elements are part of the Web Server. Separator elements can be used to show boundaries between the components of the sequence diagram (such as the air interface between cell phone and base station, or the Internet in a distributed or web-based application). The body of the sequence diagram shows the interactions between the various units as they collaborate to accomplish a particular purpose. The dotted horizontal lines are called guidelines, which are typically used with their corresponding line numbers to refer to portions of the diagram in documentation or during design meetings ( Sequence Diagram Editor allows you to configure whether or not to display these guidelines andor line numbers in your sequence diagrams.) Messages are by far the most common elements and are used to model the interactions and interfaces between components. Sequence diagram editor supports six different types of message elements: Simple Messages - Simple messages can be used to represent interactions between components that are not direct method calls (could be IPC, remoting, http or web services) Asynchronous Messages - Asynchronous messages represent stimuli that can occur at any time based on external events (e. g. interruptssensors or user input) Call Messages - Call messages are usually reserved for method calls between objects in the same threadtask where the calling object waits for the return from the recipient before continuing Return Messages - Return messages indicate a response to a call message, although they can also be used with simple messages to represent requestresponse pairs. Create Messages - Create messages are used to represent the dynamic creation of an object instance. They can also be used to represent the creation of a thread or task. Destroy Messages - Destroy messages are used to represent the dynamic destruction of an object instance. They can also be used to represent the shutdown of a thread or task. Action elements can be used to represent an action or processing performed by a single entity without involving other units. In the sequence diagram example above, the Registration Page entity renders the page in line 16 using an action. State elements are useful for units representing a state machine to describe state transitions that occur as a result of sending a messages or some other event. Sates for different header elements can be configured to share the same guideline. Timer elements can be used to show the start, stop or expiration of a timer associated with a particular header element. They are used extensively in state machine design to handle error conditions when communicating with external systems. Diagram links represent a complex action performed by multiple header elements without showing all the details. For example, the quotuser loginquot box (line 7) in the sequence diagram typically involves interactions between the all the components. The details can be elaborated and shown in a separate sequence diagram with a link from the current diagram. Using diagram links to abstract details that are not specific or relevant to the current scenario reduces the size and clutter of the diagrams and enhances maintainability (used like a function call in a programming language.) Blocks are useful for representing simple alternation or looping constructs for a given header element. For example, in the sequence diagram of Figure 1 the student may not have to go through the login process if they are already logged into the system (line 6-7). If there are significant differences between the alternatives in the sequence diagram, using scenario elements like scenario start, scenario case, and scenario end rather than blocks may be more appropriate as illustrated in figure 2 (lines 22-29). You can always use additional sequence diagrams to describe different scenarios if it would be more clear. This sequence diagram shows the two alternative scenarios (course full found line 22, and No Service Found line 26) in the same diagram. Notice also that Sequence Diagram Editor automatically takes care of pagination by repeating the diagram title and header elements for each page. Documentation notes and Flow Notes are used throughout the sequence diagram to add additional descriptive text. These can be selectively hidden or displayed based on the desired detail level. Free Notes can also be used to add detail or annotations. Sequence Diagram Editor can also export diagrams in PDF (click here ) and RTF (click here ) formats. The PDF and RTF exports can optionally include documentation notes for the sequence diagram provided as a separate table at the end of the export. NOTE: while the exported RTF document tends to be large, opening this document with Microsoft Word and saving it as a Word document considerably reduces the size of the files (sometimes by a factor of 20 or more.) Click here for the corresponding Word document.