I have a sequence diagram in Enterprise Architect.
In it is a process which can be initiated by one of two sources: either a timer process or a manual one (a user hitting a button on a GUI screen).
How do I show this on the diagram, please?
A sequence diagram does not allow you to show two alternative invocations of the same operation. You could achieve this in an activity diagram using two different receive events leading to the same activity, but in a sequence diagram you can't draw two messages to the same sequence.
What you can do is call other sequences from within a sequence.
You do this by first drawing the sequence for the process, not showing how it is initiated or by whom but only what happens within the process.
You then draw two separate sequence diagrams for the two different cases, and into each you drag the first sequence diagram and drop it as an "Interaction Occurrence."
Finally, you draw a message from the actor to the interaction occurrence. The occurrence can be double-clicked in the diagram, which opens up the sequence diagram describing the process.
A related problem is, of course, that there is no standard way of showing spontaneous occurrences (timeouts) in sequence diagrams, since they focus on interaction between a caller and a callee (often in a cascade). The simplest way of dealing with this is to create an actor "Clock" or similar, and have it initiate the process.
You might want to introduce an interface (or a superclass) that is common to the timer process and the manual invocation and set that as the user, as the calls (I assume) are likely to call the same basic method anyway.
If they behave quite differently, I'd go with Uffe's advice and create 2 diagrams.
Some tools also allow for using fragments in sequence diagrams (see corresponding help text for Enterprise architect).
Then you may use e.g. the "alt" fragment. Note the advice in the given link, though: "sequence diagrams are not intended for showing complex procedural logic".
Related
I am trying to model a certain behaviour, where couple of activities in differents swimlanes supposed to be processed in a loop. Now BPMN uses tokens to ilustrate the flow and paths taken. I wonder how such tokens work in case of loops. Does every activity iteration creates a token which consequently travel through the connected activities?
E.g. Let's say Activity1 will be performed in a loop 10 times. Will that create 10 tokens where each will travel through the remaining activities of the process? Such behaviour would be undesirable, however if I am not mistaken multi-instance activities work that way.
The only solution on my mind which would comply with BPMN specification would be to create a Call activity for the whole block of activities and then run the Call activity in a loop.
Can anyone clarify for me the use of loops and multi-instances in BPMN from the view of tokens?
Thank you in advance!
Based upon my reading of the documentation: https://www.omg.org/spec/BPMN/2.0/PDF The answer from #qwerty_so does not seem to conform to the standard, although in part this seems to be because the question also seems imprecise or at least underspecified.
A token (see glossary) is simply an imaginary object that represents the flow unit in the process diagram. There are at least three different types of loops specified in the standard, which suggest different implications for the flow unit.
Sections 13.2.6 and 12.2.7 describe Loop Activity and Multiple Instance Activities respectively. While the latter, on its face, might not seem like a loop, the standard defines attributes of the activity that suggest otherwise including: MultipleInstanceLoopCharacteristics and ExpressionloopCardinality.
In the former case, it seems that the operational semantics suggest a single flow unit that repeats multiple times according to some policy or even unbounded.
In the latter case, the activity has "multiple instances spawned," including a parallel variant.
That multiple instances can flow forward in parallel, on its face, suggests that the system must at least allow for the possibility of spawning multiple tokens (or conceptually splitting the original token) to support multiple threads proceeding simultaneously along different paths.
That said, the Loop Activity (13.2.6) appears to support the OP's desired semantics.
Let's say I have a collaboration diagram that models a process named CheckMessage which is quite complex and spans over few lanes and pools. Now I would like to model another process, e.g. CreateMessage which would make use of the previous process to check first if message doesn't exist already or if all its fields are valid, etc.
The thing is, that both processes make use of the same swimlanes and pools. What is the proper way to model such interactions? I was thinking to model CheckMessage as a sub-process of CreateMessage, however sub-processes can't be attached to pools or lanes - if I understand it correctly they just stay within a lane of activity which invoked them. Can a Call Activity encapsulate such beahviour (cross pools and lanes)? Or can I somehow reference the CheckMessage diagram as a whole?
Thanks in advance.
I could think of the following approaches:
Using Diagram Reference: This is used quite often when you want to switch easily to the more complex part. The disadvantage is that, unlike Fragments in SDs, you do not have ways to really connect flows in and out of referenced diagrams.
Repeating parts of the process: here you just pick those actions from the complex process which ought to interact with the other process. You can highlight that by putting a boundary around these and adding a diagram reference as described above.
Call Activity: This is another valid way. Here you have an activity which you instantiate as action. The advantage here is that you can add pins for input and output parameters.
I guess there is no silver bullet and you have to choose what is appropriate in each case.
Edit Regarding #3 it looks like that:
(this is an example and not to be used in practice)
The Action to the right is an instance of the Activity as you can see by Ctrl-L (show parent).
Let's say I have an Android app that communicates with a desktop program via Bluetooth sockets.
Pseudo code on Android:
class sendToDesktop{
sendMsg(String msg){
socket.send(uuid, msg)
}
}
On desktop:
class Read{
getMsg(){
return socket.read(uuid, msg)
}
}
So how do I represent the relationship between these separate programs in UML? Can I use Component diagrams, or are they only meant to illustrate separate components of a single program?
As #Gangnus points out there are quite many options and none is the one and only.
For example this websequencediagrams.com script depicts your scenario:
The required level of detail (intermediate classes, method names, argument lists...) depends on who will read it and why.
For example this websequencediagrams.com script shows also additional internal worker classes:
See also:
uml-diagrams.org: UML Sequence Diagrams
That depends on the level of abstraction. You can use:
Composite structure diagram (if you want to notice what exactly instances call different services of other applications),
maybe Timing diagram,
Sequence diagram(if you are interested in the sequences of mutual calling),
Interaction overview diagram (messages and timelines are hidden),
Activity diagram (for analysis of business rules),
Communication diagram (for naming the pieces of translated information and their addresses),
and even State or Use Case diagrams.
Try to start from below and continue up to the level where you will have one A4-size diagram.
If using UML is imperative, then you may want to consider using a communication diagram as shown here. While a communication diagram is ideally suited for elements of a single application, you can adapt the diagram to show communication from one application to another.
If you are not tied down to UML, I have found data flow diagrams to be very helpful to demonstrate the information that is flowing from one information source/consumer to another (via an intermediary process--in your case the intermediary process might be your methods that contain the Bluetooth logic).
In answer to the original question: no, component diagrams are not restricted to parts of a single program so yes, you can use them.
UML diagrams are not tailored to any specific level of abstraction or scope of work. If your "system under consideration" contains two programs, then that's what you should show in the diagram.
Just for my personal wiki, I want to draw a diagram that shows how a message is processed via a couple of Message Queues.
(Like, xml message comes from source1 to the Queue1, then it is passed to a system where the message is converted into another format and...)
What kind of UML diagram should I need here?
And additionally, how do I show a Queue in UML?
Order and time are best seen in an Sequence diagram. Also the communication between the different parts (source, queues) and parameters will be visible.
A queue is just an object (the squares at the top of the diagram).
Sequence Diagrams are a good choice but they have limitations when used for interactions with a large number of steps. They excel at describing the steps to a single operation, such that the actors are related to the behavior required. I try not to left any single sequence diagram take up more than one page. If I need more, I break it up into two serarate diagrams because I'm usually wasting whitespace due to the calling depth and the interacting quickly becomes harder to understand instead of easier.
You might use two types of diagrams. On a system-level diagram, show the interaction between the queues (or their hosts), and on a Sequence Diagram show the steps taken within a single host.
I think that the best good is an activity diagram. In my view it is the best way too show process flow. Sequence diagrams are harder to understand and also has a lot of clutter (the lifelines) which just bother the reader. And having two diagrams just makes things complicated
I understand the difference between commands and events but in a lot of cases you end up with redundancy and mapping between 2 classes that are essentially the same (ThingNameUpdateCommand, ThingNameUpdatedEvent). For these simple cases can you / do you use the event also as a command? Do people serialise to a store all commands as well as all events? Just seems to be a little redundant to me.
All lot of this redundancy is for a reason in general and you want to avoid using the same message for two different purposes for a number of reasons:
Sourced events must be versioned when they change since they are stored and re-used (deserialized) when you hydrate an aggregate root. It will make things a bit awkward if the class is also being used as a message.
Coupling is increased, the same class is now being used by command handlers, the domain model and event handlers now. De-coupling the command side from the event can simplify life for you down the road.
Finally clarity. Commands are issued in a language that asks something to be done (imperative generally). Events are representations of what has happened (past-tense generally). This language gets muddled if you use the same class for both.
In the end these are just data classes, it isn't like this is "hard" code. There are ways to actually avoid some of the typing for simple scenarios like code-gen. For example, I know Greg has used XML and XSD transforms to create all the classes needed for a given domain in the past.
I'd say for a lot of simple cases you may want to question if this is really domain (i.e. modeling behavior) or just data. If it is just data consider not using event sourcing here. Below is a link to a talk by Udi Dahan about breaking up your domain model so that not all of it requires event-sourcing. I'm kind of in line with this way of thinking now myself.
http://skillsmatter.com/podcast/design-architecture/talk-from-udi-dahan
After working through some examples and especially the Greg Young presentation (http://www.youtube.com/watch?v=JHGkaShoyNs) I've come to the conclusion that commands are redundant. They are simply events from your user, they did press that button. You should store these in exactly the same way as other events because it is data you don't know if you will want to use it in a future view. Your user did add and then later remove that item from the basket or at least attempt to. You may later want to use this information to remind the user of this at later date.