Menu
Sequence diagrams are typically associated with use case realizations in the Logical View of the system under development. Sequence diagrams are sometimes called event diagrams or event scenarios. A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects that live simultaneously, and, as horizontal arrows.
UML 2 Sequence Diagrams: An Agile IntroductionUML 2 Sequence Diagrams: An Agile Introduction.UML sequence diagrams model theflow of logic within your system in a visual manner,enabling you both to document and validate your logic,and are commonly used for both analysis and designpurposes. Sequence diagrams are the most popular UMLartifact for dynamic modeling, which focuses onidentifying the behavior within your system. Otherdynamic modeling techniques include,.
Sequence diagrams,along withandare in my opinion the mostimportant design-level models for modern businessapplication development.Sequence diagrams are typicallyused to model:.Usage scenarios. A usagescenario is a description of a potential way yoursystem is used. The logic of a usage scenario may bepart of a use case, perhaps an alternate course. Itmay also be one entire pass through a use case, suchas the logic described by the basic course of actionor a portion of the basic course of action, plus oneor more alternate scenarios.
The logic of a usagescenario may also be a pass through the logiccontained in several use cases. For example, a studentenrolls in the university, and then immediatelyenrolls in three seminars.The logic of methods.Sequence diagrams can be used to explore the logic ofa complex operation, function, or procedure.
Oneway to think of sequence diagrams, particularly highlydetailed diagrams, is as.The logic of services. Aservice is effectively a high-level method, often onethat can be invoked by a wide variety of clients.This includes web-services as well as businesstransactions implemented by a variety of technologiessuch as CICS/COBOL or CORBA-compliant object requestbrokers (ORBs).Let's start with three simpleexamples. Depicts a UMLsequence diagram for theuse case, taking asystem-level approach where the interactions between theactors and the system are shown.depicts asequence diagram for the detailed logic of a service todetermine if an applicant is already a student at theuniversity.
Shows the logic for how to enroll in aseminar. I will often develop a system-level sequencediagram with my stakeholders to help to both visualizeand validate the logic of a usage scenario. It alsohelps me to identify significant methods/services, suchas checking to see if the applicant already exists as astudent, which my system must support. System-levelsequence diagram.The reason why they're calledsequence diagrams should be obvious: the sequentialnature of the logic is shown via the ordering of themessages (the horizontal arrows). The first messagestarts in the top left corner, the next message appearsjust below that one, and so on.sequence diagram.The boxes across the top of thediagram represent classifiers or their instances,typically use cases, objects, classes, or actors.Because you can send messages to both objects andclasses, objects respond to messages through theinvocation of an operation and classes do so through theinvocation of static operations, it makes sense toinclude both on sequence diagrams. Because actorsinitiate and take an active part in usage scenarios,they can also be included in sequence diagrams. Objectshave labels in the standard UML format name:ClassName, where “name” is optional(objects that haven't been given a name on the diagramare called anonymous objects).
Classes have labels inthe format ClassName, and actors have names inthe format Actor Name. Notice how object labelsare underlined, classes and actors are not.
Forexample, in, you see the Student object has the nameaStudent, this is called a named object, whereas theinstance of Seminar is an anonymous object. Theinstance of Student was given a name because itis used in several places as a parameter in messages,whereas the instance of the Seminar didn't needto be referenced anywhere else in the diagram and thuscould be anonymous. In the Student class sends messages tothe PersistenceFramework class (which could havebeen given the stereotype but wasn'tto keep the diagram simple). Any message sent to aclass is implemented as a static method, more on thislater.(method).The dashed lines hanging from theboxes are called object lifelines, representing the lifespan of the object during the scenario being modeled.The long, thin boxes on the lifelines are activationboxes, also called method-invocation boxes, whichindicate processing is being performed by the targetobject/class to fulfill a message. I will onlydraw activation boxes when I'm using a tool thatnatively supports them, such as a sophisticated CASEtool, and when I want to explore performance issues.Activation boxes are too awkward to draw on whiteboardsor with simple drawing tools such that don't easilysupport them.The X at the bottom of anactivation box, an example of which is presented in, is a UMLconvention to indicate an object has been removed frommemory. In languages such as C where you need tomanage memory yourself you need to invoke an object'sdestructor, typically modeled a message with thestereotype of.
In languages such as Java orC# where memory is managed for you and objects that areno longer needed are automatically removed from memory,something often referred to as garbage collection, youdo not need to model the message. I generally don'tbother with modeling object destruction at all and willinstead trust that the programmers, often myself, willimplement low-level details such as this appropriately.presents a complex UML sequence diagram forthe basic course of action for the Enroll in Seminaruse case. This is an alternative way for modeling thelogic of a usage scenario, instead of doing it at thesystem-level such as yousimply dive straight into modeling the detailed logic atthe object-level. I'll take this approach when I'mworking with developers who are experienced sequencediagrammers and I have a large working space (either ahuge whiteboard or a CASE tool installed on aworkstation with a very large screen and good graphiccard). Most of the time I'll draw system-level diagramsfirst and then create small diagrams along the lines ofwhat is shown in Figures and.of action for the Enroll in Seminar use case.Messages are indicated on UMLsequence diagrams as labeled arrows, when the source andtarget of a message is an object or class the label isthe signature of the method invoked in response to themessage. However, if either the source or target is ahuman actor, then the message is labeled with brief textdescribing the information being communicated.
Forexample, inthe EnrollInSeminar object sends themessage isEligibleToEnroll(theStudent) to theinstance of Seminar. Notice how I include boththe method's name and the name of the parameters, ifany, passed into it. The Student actor providesinformation to the SecurityLogon objectvia the messages labeled name and studentnumber (these really aren't messages, they areactually user interactions).Return values are optionallyindicated using a dashed arrow with a label indicatingthe return value. For example, the return valuetheStudent is indicated coming back from theStudent class as the result of invoking a message,whereas no return value is indicated as the result ofsending the message isEligibleToEnroll(theStudent)to Seminar. My style is not to indicate thereturn values when it's obvious what is being returned,so I don't clutter my sequence diagrams (as you can see,sequence diagrams get complicated fairly quickly).shows analternate way to indicate return values using the formatmessage: returnValue for messages, as you can see withisEligibleToEnroll(theStudent): false.Notice the use of stereotypesthroughout the diagram. For the boxes, I applied thestereotypes , , and indicating they represent an actor, a controller class,or a user interface (UI) class, respectively.
I've alsoused visual stereotypes on some diagrams – a stickfigure for actors; the robustness diagram visualstereotypes for controller, interface, and entityobjects; and a drum for the database. Stereotypes arealso used on messages.
Common practice on UML diagramsis to indicate creation and destruction messages withthe stereotypes of and ,respectively. For example, you see the SecurityLogonobject is created in this manner (actually, this messagewould likely be sent to the class that would then resultin a return value of the created object, so I cheated abit). This object later destroys itself in a similarmanner, presumably when the window is closed.I used a UML note in; notes arebasically free-form text that can be placed on any UMLdiagram, to provide a header for the diagram,indicatingits title and identifier (as you may have noticed, Igive unique identifiers to all artifacts that I intendto keep). Notes are depicted as a piece of paper withthe top-right corner folded over. I also used a note toindicate future work that needs to be done, eitherduring analysis or design, in this diagram-thequalifications message likely represents aseries of messages sent to the student object. CommonUML practice is to anchor a note to another modelelement with a dashed line when appropriate, in thiscase the note is attached to the message.Althoughmodels thelogic of the basic course of action for the Enroll inSeminar use case how would you go about modelingalternate courses? The easiest way to do so is to createa single sequence diagram for each alternate course, asyou see depicted in.
This diagram models only the logicof the alternate course, as you can tell by thenumbering of the steps on the left-hand side of thediagram, and the header note for the diagram indicatesit is an alternate course of action. Also notice how theID of this diagram includes that this is alternatecourse C, yet another modeling rule of thumb Ihave found useful over the years.of action for the Enroll in Seminaruse case.Let's consider other sequencediagramming notation.
Includes an initial message, Studentchooses seminar, which is indicated by the filled incircle. This could easily have been indicated via amethod invocation, perhaps enrollIn(seminar).shows another way to indicate object creation – sendingthe new message to a class. We've actually seenthree ways to achieve this, the other two being to senda message with the stereotype and/or to senda message into the side of the classifier symbol (forexample inthe message going into the side of EnrollInSeminaror inthe message going into the side of StudentInfoPage.My advice is to choose one style and stick to it.Figuresandeach depicta way to indicate looping logic. One way is to show aframe with the label loop and a constraint indicatingwhat is being looped through, such as for eachseminar in. Another approach is to simplyprecede a message that will be invoked several timeswith an asterisk, as you see inwiththe inclusion of the Enroll in Seminar use case.includes an asynchronous message, the message to thesystem printer which has the partial arrowhead. Anasynchronous message is one where the sender doesn'twait for the result of the message, instead it processesthe result when and if it ever comes back.
Up untilthis point all other messages have been synchronous,messages where the sender waits for the result beforecontinuing on. It is common to send asynchronousmessages to hardware devices or autonomous softwareservices such as message buses.The method of modeling the inclusion of use casesusing inis something that I first proposed in although I have nodoubt that others use this approach as well. Ibasically show the use case as a bubble across the topof the diagram, just like any other classifier, and showa message sent to it with the stereotype.This is consistent with both use case diagramming andsequence diagramming practices.isalso interesting because it shows how to modelconditional logic. In this case a frame with the labelalt is used along with a guard, in this caseapplicant on eligibility list. The frame isseparated into regions separated by dashed lines. Inthis case there are two regions, one for eachalternative, although you can have as many regions asyou require (to support the visual equivalent of a casestatement). Each region requires a guard.WithSequence DiagramsEarlier I stated that sequencediagrams are effectively a form of visual coding, orperhaps another way to think of it is that sequencediagrams can be used for very detailed design.
When Ideveloped the sequence diagram ofI madeseveral decisions that could potentially affect my othermodels. For example, as I modeled Step 10, I made thedesign decision that the fee display screen also handledthe verification by the student that the fees wereacceptable.Also, as I was modeling Steps 2 and3, I came to the realization that students shouldprobably have passwords to get into the system. Whenyou're following the AM practices of and it's easy to find out if ideassuch as this make sense because all you need to do isask. In this case I discovered I was wrong: thecombination of name and student number is unique enoughfor our purposes and the university didn't want theadded complexity of password management.
This is aninteresting decision that would potentially be recordedas a business rule because it is an operating policy ofthe university, indicating the need to follow thepractice and jot down therule if we're interested in keeping a permanent recordof it.How to Draw Sequence DiagramsI've been trying to explain topeople how to draw sequence diagrams for years, and whatI've discovered is that the people who get it are eithervery good at thinking in a logical manner and/or theyare good at writing software code. Sequence diagrammingreally is visual coding, even when you are modeling ausage scenario via a system-level sequence diagram.When I'm creating a sequencediagram I'll start by identifying the scope of what I'mtrying to model, and because I prefer to follow the AMpractice Model in Small Increments I'll typicallytackle small usage scenarios at the system level or asingle method/service at the detailed object level. Adiagram such asis too complex to be useful in my experience.I'll then work through the logicwith at least one more person, laying out classifiersacross the top as I need them. I automatically add theobject lifelines but as I indicated earlier willtypically not invest time adding activation boxes. Theheart of the diagram is in the messages, which I add tothe diagram one at a time as I work through the logic.I rarely indicate return values, instead I'll givemessages intelligent names which often make it clearwhat is being returned.It is interesting to note that asyou sequence diagram you will identify newresponsibilities for classes and objects, and,sometimes, even new classes.
The implication is thatyou may want to update your class model appropriately,agile modelers will follow the practice CreateSeveral Models in Parallel, something that CASEtools will do automatically. Remember, each messagesent to a class invokes a static method/operation onthat class each message sent to an object invokes anoperation on that object.Regarding style issues for sequencediagramming, I prefer to draw messages going fromleft-to-right and return values from right-to-left,although that doesn't always work with complexobjects/classes.
I justify the label on messages andreturn values, so they are closest to the arrowhead. Ialso prefer to layer the sequence diagrams: fromleft-to-right. I indicate the actors, then thecontroller class(es), and then the user interfaceclass(es), and, finally, the business class(es). Duringdesign, you probably need to add system and persistenceclasses, which I usually put on the right-most side ofsequence diagrams. Laying your sequence diagrams in thismanner often makes them easier to read and also makes iteasier to find layering logic problems, such as userinterface classes directly accessing persistenceclasses.Keeping it AgileThe most important things that youcan do is to keep your diagrams simple, both contentwise and tool wise. I will sketch sequence diagrams onwhiteboards to think something through, either to verifythe logic in a use case or to design a method orservice. I rarely keep sequence diagrams as I findtheir true value is in their creation.A common mistake is to try tocreate a complete set of sequence diagrams for yoursystem.
I've seen project teams waste months creatingseveral sequence diagrams for each of their use cases,one for the basic course of action and one for eachalternate course. My advice is to only create asequence diagram when you have complex logic that youwant to think through – if the logic is straightforwardthe sequence diagram won't add any value, you had mightas well go straight to code.This artifact description is excerpted from Chapter 11 of.The notation used in these diagrams, particularly thehand drawn ones, may not conform perfectly to thecurrent version of the UML for one or more of reasons:. The notation may have evolved from when Ioriginally developed the diagrams. The UMLevolves over time, and I may not have kept thediagrams up to date. I may have gotten it wrong in the first place.Although these diagrams were thoroughly reviewed forthe book, and have been reviewed by thousands ofpeople online since then, an error may have gottenpast of us. We're only human.
I may have chosen to apply the notation in'non-standard' ways. An agile modeler is moreinterested in created models which communicateeffectively than in conforming to notation rules setby a committee.
It likely doesn't matter anyway, because thethat you're using likely won'tfully support the current version of the UMLnotation perfectly anyway. Bottom line is thatyou're going to be constrained by your tools anyway.If you're really concerned about the nuances of'official' UML notation then read the current version ofthe.Share with friends:Recommended ReadingThis book,is an indispensable guide for agile coaches and practitioners to identify what techniques- including practices, strategies, and lifecycles - are effective in certain situationsand not as effective in others. This advice is based on proven experience from hundredsof organizations facing similar situations to yours. Every team is unique and faces aunique situation, therefore they must choose and evolve a way of working (WoW) that is effective forthem. Describes how to do this effectively, whether they are just starting with agile/leanor if they're already following Scrum, Kanban, SAFe, LeSS, Nexus, or other methods.is an important reference book for agile modelers,describing how to develop 35 including all 13.Furthermore, this book describes the fundamental programming and testing techniquesfor successful agile solution delivery.
The book also shows how to move from youragile models to source code, how to succeed at implementation techniques such as and.The Object Primer also includes a chapter overviewing the critical database development techniques (, anddatabase access coding) from my award-winning book.2003-2018This site owned.