17

As in many types of UML diagrams, you can use guards to denote a condition. A guard is a boolean expression that you can write over a transition. Here's a picture with an example: Notice the "[pastDueBalance = 0]" condition. You can also use combined fragments for more complicated conditional logic. See this nice msdn article for further information.


13

The more appropriate UML diagram to depict a platform's architecture is a component diagram. If you want to go a level lower, then you'd also need to draw one or more package diagrams, and perhaps even a deployment diagram. The diagram you linked to is not a UML diagram, it's a "marchitecture / marketecture" diagram. It's not really supposed to be ...


8

In UML, an Actor is always something (a system or person) that is outside the scope of the system/software that you are building. It would be completely wrong to equate an actor with an instance/object of a class that happens to model certain aspects of the actor in your system. In the shown UML diagrams, the actor "User" (with it's stick-figure icon) ...


7

As the queue is an important component in the sequence you are presenting, it should most definitely be present with a lifeline. As the consumer explicitly listens for events from the queue, I would start the diagram with the listen call from the consumer to the queue. After that, the producer can insert its event into the queue (possibly with an indication ...


7

Implementing Bart's answer in the wonderful PlantUML could look like this, (ab)using an entity to distinguish the queue from the participating threads: The corresponding source code: participant Producer entity Queue Consumer->Queue : dequeue activate Consumer ... Producer->Queue : enqueue activate Producer Queue-->Consumer deactivate Consumer ...


7

One way is to use Fragments like this: But honestly: code is much clearer for such purposes. Avoid using a graphical representation where a few lines of (pseudo) code can clarify what a 1000 pictures obfuscate. Once (in the 80s) I also though that programming graphically would be an advantage. But now I'm old an wise and know that this was wishful thinking. ...


6

At a very high level, sequence diagrams can represent high-level interactions between systems or sub-systems at a high level. If they represent interactions between actual classes (or interfaces) they're nice because each message in the diagram corresponds directly to a method that class must have. You can almost write your code from the sequence diagrams by ...


5

I would say go as high level as you can while still including all the necessary method calls, etc for your topic. My reasoning for this is that if you're including every single interaction then you might as well just write the code yourself. Personally, I have always viewed sequence diagrams more or less as "guidance" for the implementer. I've never viewed ...


5

Keep in mind that you are just drawing diagrams. This is not coding in some graphic language. If you use the timer-mechanism in all your communication with the device, just model it once (a suggestion for this can be found at the end of this answer). Leave out the timer in most diagrams. You should model at a specific level of abstraction. Don't leave this ...


5

There are two questions here: 1. The slanting of the arrow(s) and 2. what to do with the activation. The arrows should be slanted if you want to represent in your diagram that it takes time for the message to travel from A to B or vice-versa. If you just want to indicate that the message is processed a-synchronously, it is enough to use an open arrow-head ...


4

There are four possibilities I know of (with increasing power): The easiest is just using guards, which are simple, side-effect free boolean expressions. With combined fragments (see e.g. page 54), you can group sets of messages together to show conditional flow in a sequence diagram (alternatives, options, loops) Much more powerful is the Object ...


4

Aside: Contrary to popular belief, long names are not always a bad thing. Used in moderation, they can be helpful. For example, if a method returns a boolean value that indicates that the application startup should be aborted if the execution fails while the application is starting up then one of these is more clear than the other: getTerminateDuringStartup ...


4

Sequence diagrams have fragments. These are represented by a box around the operations and a label. Two labels are "alt" and "loop". The box for "alt" form can be divided into multiple sections for different flows while the "loop" fragment can include the notation for the guard condition. I would represent this as a loop fragment around steps 3-5, with a ...


4

If that's a good idea or not depends on the detail level you want to show in your your diagram and what the reader expects. Also whether you do MDD or not. Most UML Tools like Magic Draw or Enterprise Architect allow you to define an abstract (displayed) condition and to enter the actual condition in form of code snippets or pseudo code in some usual not ...


3

Is A calling its method doSomething which in turn uses B in its implementation? Or is A sending a message to B and B is the actual object that invokes the doSomething method? A is calling doSomething on B. How that happens is an implementation detail. It could be a direct function call, where A is calling the method on B, or it could be a message, e.g. ...


3

Description of lifeline from UML 2.4.1 standard: A Lifeline is shown using a symbol that consists of a rectangle forming its “head” followed by a vertical line (which may be dashed) that represents the lifetime of the participant. Information identifying the lifeline is displayed inside the rectangle in the following format: <lifelineident> ::= ...


3

Since you already have code and you are reverse engineering it into a UML model, I would highly recommend keeping the method and attribute names as they are in the code. This will make it easier for someone to go between the code and the model. However, using exact function names aren't required in a sequence diagram. Typically, I've seen this earlier on in ...


3

They seem to be correct enough to understand what is going on, which in my opinion is all you need for UML. However if you want to be more technically correct: Request membership card appears to be a return when it should presumably be a message with provide membership card as a return? confirm membership may not need to go back to the person, but a ...


3

UML allows to you to place an actor in a sequence diagram. The actor ("user") has a lifeline like any object instance. I'd say that "checking the check box" is the message, that the user sends to your check box instance. Alternatively you can take the IBM approach and let the initial event be an incoming message to your first instance.


3

Web pages are part of the visual presentation of your final implementation, and are not part of any UML Sequence Diagram language construct. Webpages would serve no purpose that is not alredy addressed within the current UML Sequence Diagram language and definition. Additionally, by including a web page into any design document, you are presupposing a ...


3

Diagrams should help understand things. If they don't, they fail. Sequence diagrams are very good at explaining protocols over network and single interactions in a API, in any non-trivial API you're gonna have an hard time describing all interactions. (i.e. you can't) You obviously have to make multiple diagrams, one for each interaction scenario, making a ...


3

See this page for how you can model delays between messages in general. If you want to create a sequence diagram that covers only the positive case, then that's all you need. If you want to cover both possibilities in one diagram, you need to use an alternatives box, where you have one delay that is larger than 250ms and one that is smaller, and then of ...


3

I have seen colleges try to cover every single possible exception and error condition in every use case and sequence diagram. The result has always been late delivery, hours spent in review and in the end very little benefit to the project. One way of thinking about it ala "Black Swan" by N. Taleb is that there are just too many possible disasters waiting ...


3

It's probably going to look similar to this: See how the breaks in the loops are indicated by a dotted line pointing back to the original call location (the ones marked "unfulfilled")? There is also an "Opt" box that handles the "unfulfilled" condition.


3

There are three (edit: four) reasons I would not go for this. You are reliant upon the third party API to do additional integration with your API, to return a token, and then provide a response from a token not an uploaded image. So you'd need to know they would provide that integration and maintain it You're getting your clients (the app) to make two API ...


3

The UML sequence diagram is well adapted to represent an interaction between several objects (or components or, why not,systems). It has semantic to make the difference between synchronous and asynchronous communication. You may even show delay in message passing (but don't abuse of it). However for a more complex interactions between systems, you should ...


3

I typically handle things like this with a simple note It makes the point and doesn't require any fancy symbols. See also how to show event in a sequence diagram


3

I assume that the part follow the alt frame imply that "good" case is verified? No, that assumption is incorrect. The part following the alt frame will be done when either part of the alt frame completes. Or I need to put all of the sequence of "good case" in the "good case alternative section"? Yes, all the steps that belong to the "valid card" ...


2

It should contain the objects of interest in the interaction. Like any type of documentation, it should focus on what you are trying to document. If you are documenting the DB interaction, you should have the DB classes involved. If not, you shouldn't.


2

It depends entirely on what you want to communicate. In my experience sequence diagrams work great for both very high level through to very low level systems. For example, we use a sequence diagram showing the event level flow of an SSL handshake to help explain some security related issues to users. Very low level, and very concrete. We also use a ...


Only top voted, non community-wiki answers of a minimum length are eligible