(3) I understand that sequence diagrams are based on UML, but in what way is UML a "language"? There's no text representation of it, right? It seems more a way of diagramming something, like a flowchart. (2) When a flow has different logic paths that result in different web service calls, should I represent these by if/then/else in a single sequence diagram, or create a different sequence diagram for each possibility? (1) Can someone show me some particularly good/useful examples of a sequence diagram for web service calls, so I can see how this is done right? But I see how popular sequence diagrams are, so I think I'm not 'getting' them. I find it a lot easier to document stuff like this in a text file or on a wiki. For example, if I want to show that my app makes a call to a specific service, passing a set of data and getting back a different set of data, there's hardly enough room on the line out and the line back to show all this data and to point out that it's a GET or a POST, and without this information, the diagram is minimalistic to the point of not being very useful. They're difficult to read - lots of lines, not a lot of text. I don't really understand sequence diagrams. The best way to understand sequence diagrams is to look at some examples of sequence diagrams.I've been asked to make a sequence diagram to document the web service calls made by my application. Sequence Diagram and Other UML Diagram Examples It's shown by an arrow going from a lifeline to an endpoint, a filled circle or an x. It can be shown by an arrow with an x at the end.Ī message sent from an unknown recipient, shown by an arrow from an endpoint to a lifeline.Ī message sent to an unknown recipient. This is a message that destroys an object. Similar to a return message, it's depicted with a dashed line and an open arrowhead that points to the rectangle representing the object created. This is a message that creates a new object. Like synchronous messages, they are drawn with an arrow connecting two lifelines however, the arrowhead is usually open and there's no return message depicted.Ī reply message is drawn with a dotted line and an open arrowhead pointing back to the original lifeline.Ī message an object sends to itself, usually shown as a U shaped arrow pointing back to itself. It's usually drawn using a line with a solid arrowhead pointing from one object to another.Īsynchronous messages don't need a reply for interaction to continue. Ī synchronous message requires a response before the interaction can continue. Place the condition for exiting the loop at the bottom left corner in square brackets. When that object's lifeline ends, you can place an X at the end of its lifeline to denote a destruction occurrence.Ī repetition or loop within a sequence diagram is depicted as a rectangle. Objects can be terminated early using an arrow labeled ">" that points to an X. Lifelines are vertical dashed lines that indicate the object's presence over time. Asynchronous messages are sent from an object that will not wait for a response from the receiver before continuing its tasks. Use half-arrowed lines to represent asynchronous messages. Messages are arrows that represent communication between objects. When an object is busy executing a process or waiting for a reply message, use a thin gray rectangle placed vertically on its lifeline. Use the UML object symbol to illustrate class roles, but don't list object attributes.Īctivation boxes represent the time an object needs to complete a task. Start Now Basic Sequence Diagram NotationsĬlass roles describe the way an object will behave in context.
0 kommentar(er)
