It’s called a found message.įor another approach to this scenario, take a look at Figure 4.2. The first message doesn’t have a participant that sent it, as it comes from an undetermined source. Use returns for all calls, but I prefer to use them only where they add information otherwise, they simply clutter things.Įven in this case, you could probably leave the return out without confusing your reader. Note that I’ve used a return arrow for only this call I did that to show the correspondance. The call getProduct is shown returning aProduct, which is the same name, and therefore the same participant, as the aProduct that the getPricingDetails call is sent to. Naming often is useful to correlate participants on the diagram. My one exception is when exploring a design during a design session, because they are awkward to Activation bars are optional in UML, but I find them extremely valuable inĬlarifying the behavior. Of the participant’s methods being on the stack. ( Figure 4.4, shown on page 58, uses this style.)Įach lifeline has an activation bar that shows when the participant is active in the interaction. A fuller syntax is name : Class, where both the name and the class are optional, but you must keep the colon if you use the class. In these diagrams, I’ve named the participants using the style anOrder. In UML 1, participants were objects and so their names were underlined,īut in UML 2, they should be shown without the underline, as I’ve done here. So I use the term participants, a word that isn’t used formally in the UML spec. In UML 2, their roles are much more complicated, and to explain it all fully is beyond this book. Most of the time, you can think of the participants in an interaction diagram as objects, as indeed they were in UML 1. You can’t tell that from this diagram, although I’ll introduce some more notation to handle that later. The sequence of messages getQuantity, getProduct, getPricingDetails, and calculateBasePrice needs to be done for each order line on the order, while calculateDiscounts is invoked just once. The diagram, however, doesn’t show everything very well. GetDiscountInfo to an instance of customer. You can also see how we show the order invoking a method on itself and how that method sends Of order sends getQuantity and getProduct messages to the order line. One of the nice things about a sequence diagram is that I almost don’t have to explain the notation. A sequence diagram for centralized control Participant with a lifeline that runs vertically down the page and the ordering of messages by reading down the page.įigure 4.1. Sequence diagrams show the interaction by showing each Having done that for all the line items, the order then needs to computeĪn overall discount, which is based on rules tied to the customer.įigure 4.1 is a sequence diagram that shows one implementation of that scenario. On the pricing rules of the order line’s products. To do that, the order needs to look at all the line items on the order and determine their prices, which are based We have an order and are going to invoke a command on it to calculate To begin the discussion, I’ll consider a simple scenario. The messages that are passed between these objects within the use case. The diagram shows a number of example objects and Typically, a sequence diagram captures the behavior of a single scenario. The UML defines several forms of interaction diagram, of which Interaction diagrams describe how groups of objects collaborate in some behavior.

UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd Edition

Yuml sequence diagram if else