A common multi-threaded implementation is to have some class where Method_A() is running in a thread and sits blocked waiting for some signal/event member variable (e.g. WaitForSingleObject).
Interacting classes running in different thread will then call Method_B() which does some work, sets the signal/event variable, perhaps does some more work, then returns.
How do I represent this interaction on a Sequence Diagram?
Should I have two lifelines, one for each thread, even though they are operating on the same instance of the class? My modelling tool (Enterprise Architect 12) doesn't allow the same class to appear twice on a Sequence Diagram, so seems to discourage this.
Edit: Geert has noted that the Sequence Diagram should use instances, not classes, which is a fair comment. However the problem is the same: multiple lifelines would imply multiple instances, but in the question Method_A() and Method_B() are operating on the same instance, just from different threads. How can that be represented?
The approach I have decided to take is to add two lifelines for the same instance, then label one lifeline with the <<thread>> stereotype and add the thread it runs in to the name:
I realise this is probably not standard UML, but it seems to get across all the information I want to express in a clear manner, which is the most important thing, right?
Martin Fowler does mention a few times in his book that sometimes a non-normative diagram is actually clearer. So that's my excuse. :)
(Edit You can solve it by just using asynchronous messages as #sim points out. That will just do. The answer below is showing what is going on under the hood. So if you don't care about the details, go with that answer.)
You are asking more a design than an UML question. Namely, how do concurrent instances talk to each other. You said first
Method_A() is running in a thread and sits blocked waiting
which simply means that it can not accept anything since it is blocked. Now, guessing from the context of your question, I assume that you still want to communicate with that instance since
in different thread will then call Method_B()
So, in order to be able to accept a message the instance must be in an appropriate state. There are a couple of ways to achieve that. One simple is, if the according OS has support for that, to return to the scheduler and tell him that it's waiting for some message.
Now when method_b is being called you know inside Object1 that you are in some kind of idle state inside method_a and do appropriate (return-) action.
Another way would be to poll the scheduler for incoming messages and handle them.
You need to keep in mind that sending a message usually not directly deals with the instance but tells the system scheduler to interact with the appropriate instance (at least in most OSs).
I just remember from the Modula2 compiler I once wrote that it has a concept of coroutines which allows a concurrent thread to run within the compiled code. But basically that is just mapped to two independent threads running under the hood of a semi-single one and you'd depict that with two life-lines when going into detail.
N.B.: Rather than method it should be operation (since that is was is invoked by a message; while the method is what is implemented inside the operation). And as per common convention they should start with a lower case char.
And also: do NOT use classes in a SD. Unfortunately EA still allows that (why? Ask them!). Somewhere hidden in their docs there is a sentence that you must use instances. Else the model will break. A SD is always (!) a sample sequence of instances talking to each other. Classes do not talk, they are just blueprints for the instances.
You should never use classes in sequence diagrams, but instead use instances/lifelines that have your class as classifier.
If you hold the control down when dragging a class to a sequence diagram you can choose to drop is as instance instead of as class.
This way you can add as many as you want for the same class.
The notation you are looking for is an asynchronous message. You could theoretically express this using a single lifeline. But this wouldn't be readable. So a possibility would be having two instances of a threadclass in your class and show the interaction between the instances. But never show classes in a sequence diagram.
But why are you using a sequence diagram at all? For such internal behavour an activity diagram is most likely more appropriate. There you can use send and receive messages elements to express such a behavour per thread. Or if it shall be shown in one diagram, you can use fork.
Related
Why DOESN'T this Star UML Sequence Diagram have the activation "rectangle" in the Control object? Am I doing something wrong? Should I set something in Star UML?
How can I add the activation "rectangle" in the Control object?
The simple answer is: because that's how the designers of Star UML designed it to be.
In Star UML if nothing initiates (triggers) the Execution Occurrence (that's the formal name of that rectangle) then... there is no Execution Occurrence. If you want to have it, you need to trigger it somehow (e.g. by self-referencing Initiation message).
I didn't find any option to change that behaviour. I haven't been using the Star UML for quite some time but since the free version has been abandoned earlier than I've started using it, I believe nothing has changed since.
If you're using the newer, proprietary version, you can send a request to the dev team of Star UML to add it as a functionality.
Well, this is because no tool I know of implemented sequence diagrams correctly. According to UML it should be possible to define ExecutionSpecifications (aka activations) independent of any Messages.
However, many tool vendors seem to assume, that an ExecutionSpecification must be started by a message. I can see, where they come from, since every execution has a cause. The problem is that sequence diagrams are not about causality, but about possibly occurring sequences of events. Sequence diagrams don’t mean, that this is the only possible sequence.
If we accept that the tool wants to start an ExecutionSpecification with a Message, the behavior of Star UML is consistent. Please note that a create message (i.e. messageSort=createMessage) does not call the constructor:
UML: A CreateObjectAction is an Action that creates a direct instance of a
given Classifier and places the new instance on its result OutputPin.
The Action has no other effect. In particular, no Behaviors are
executed
I know, this is about Actions, but why should a create message be different? Also, there is a constraint that stops create messages from having a signature:
signature_refer_to
The signature must either refer an Operation (in which case messageSort is either synchCall or asynchCall or reply) or a Signal (in which case messageSort is asynchSignal).
That means, you cannot reference a constructor in the create message. You will need to call the constructor explicitly. The sender of this message is the same Lifeline that created the new object. It should not be a self message, since this is not what is happening in reality and is therefore a workaround.
There is another option. You can make the class an active class.
An active object is an object that, as a direct consequence of its creation, commences to execute its classifierBehavior
Many tools show an ExecutionSpecification covering the whole lifeline for an active Class. Maybe your Class is meant to be active?
PS: Of course, this is not completely correct, since the classifier behavior also needs to be started explicitly:
A StartObjectBehaviorAction is a CallAction that starts the execution […] of the classifierBehavior of an object
That means, it doesn’t start automatically. We need an ActionExecutionSpecification to start it. Very few tools support this :-(
I would like to to create a sequence diagram to show some interaction, and then use that sequence diagram as an interaction occurrence (sub-sequence) on other sequence diagrams. The point is I would like to apply the sub-sequence each time to a different object instance that is involved in the interaction in the sub-sequence. In my case the instances are simply various file artifacts. Is there any legitimate way of doing this prescribed by UML?
EDIT: some more clarification of my context:
I have 2 main sequence diagrams where I want to reuse the sub-sequence as an interaction occurrence
on the 1st main sequence there is one file for which the sub-sequence has to be applied 3 times
on the 2nd main sequence there are 3 different files for which the sub-sequence has to be applied 3 times
the files are read by the same object instance
I model reading from a file by a call arrow stereotyped as <<read>> to a on object instance which represents the file.
I need to reference the file somehow in the sub-sequence, but I haven't found a good and simple way of doing this.
Complicated, but formally (almost) correct solution with Collaborations
Just using InteractionUses is not enough, because this doesn't allow you to assign the actual roles in the main interaction to the generic roles of your used interaction.
Collaborations, CollaborationUses and Role Bindings can be used for this.
See my example here:
This defines a Collaboration with generic roles sender, relay and receiver and shows the interaction between them.
You can now use this collaboration in a concrete situation:
Class S uses the Collaboration two times with different role bindings to its parts (A, B and C are assumed to be able to send and receive Sig1).
With these definitions you can now create your main sequence diagram:
Unfortunately, this is not correct UML, even though there is an example in the specification (I filed an Issue https://issues.omg.org/browse/UMLR-768). You will have to fake this notation until the taskforce comes up with a fix. How to fake it, depends on how strict your tool implements the specification.
Advantage: formally correct and versatile solution, backed by an example in the specification
Disadvantage: complicated and difficult to explain, not completely usable, because of a bug in the specification
Basically there are three different ways to specify such situations.
Using a gate. Whith gates you specify the sequence with messages that start or end at a gate that is defined and in most tools (if usable at all) not shown explicitly. Instead it is modelled with messages starting or ending at the interaction border.
Similar as gates are lost and found messages. These are special messages that pass out the control to another sequence or returns from one. Such as in the case before you can define a set of further diagrams specifying the interaction in more details.
Using abstraction, which is my favorit for most of the cases. This means you extract the common interface from the classes and specify the interaction against the interface instead of the concrete classes.
Use an Interaction with Parameters:
Now we would like to reference the Lifelines of the main Interaction in the arguments of the InteractionUse. Unfortunately, in UML this is not possible, since arguments are ValueSpecifications and they cannot reference another modelelement.
However, NoMagic suggested and implemented an additional ValueSpecification, called ElementValue, that does exactly this. I think this would be a valuable addition to UML and hopefully it will be added some day. Up to then, only MagicDraw users can use this solution (as far as I know).
With this non standard element, we can model this:
The connection between the lifelines is now via the arguments for the parameters of the generic interaction. Technically the lifelines would not need to be explicitely covered by the Interaction Use, but I think that it makes sense to do it (shown in my tool with a non standard circle on the border of the Interaction Use).
Advantage:
compact and versatile solution, almost conformant to the standard
Disadvantage:
uses a non standard model element, currently only available to MagicDraw users.
pragmatic non conformant solution with covered lifelines:
The collaboration and parameter solutions allow to specify it (almost) formally correct. However, in many cases, a simplified model would be sufficient. In your case, for example, you only have two participants and they have different types. So, even though there is no formal connection between the lifelines of the used interaction, and those of the main interaction, there would be no ambiguity. You could use the covered attribute of the InteractionUse to specify, which of the lifelines (files) you are targeting at a specific InteractionUse. Could that be the pragmatic solution, you are looking for?
Advantage:
compact solution
Disadvantage:
not conformant to UML, ambiguous in more complicated situations
I have a equipment which I am representing with a class and there are two actors a remote and local operator who can put the equipment on or off. Both actors will use the functionality of the equipment. But How do I now represent them using sequence diagram, since if I draw an event from both local and remote its going to show at the equipment the one happened after the other but in reality two actors are using the same function and can invoke it any time. So how do I represent the two actors in the below sequence diagram.
P.S. The RAN40L is the equipment and CMS is remote operator and Simulator Operator is the local operator.
As it happens I have extensive experience from the defence industry, including naval CMS, so I am familiar with the domain.
The crucial question is, as always with UML, what you want to show in the diagram, which of course ties in with what you are showing in other diagrams. No diagram is ever read in isolation and you will never capture the entire radar functionality in a single sequence diagram.
Remember that a sequence diagram is intended to show things happening in a strict sequence. It is possible to show some rudimentary concurrency using the appropriate fragment, but if you want to show that the two actors do exactly the same thing, that the sequence is in fact one and the same in both cases, then the sequence diagram is the wrong place to show that.
Assuming that this sequence is intended as an elaboration of a use case, then the solution is to replace the two actors with a single actor, eg "Radar Controller". This actor can then be specialized into CMS and Simulator, which makes sense if the radar is unaware of, or unconcerned with, who is interacting with it in some (use) cases but not in others.
If the radar never makes the distinction, there shouldn't be two actors at all. The actors must make sense to the system they're interacting with, otherwise there's something wrong with your actor model.
So one solution is to structure the use cases as below.
http://sdedit.sourceforge.net/images/webserver.png
This is a good example where two actors are used. It is default to put one actor to the opposite the other (this is not done in the example).
Actor is considered to be just another object in the sequence diagram. You can plase arbitrarily many actors and use them just like any other object, no restrictions in this sense.
There are some stylistic guidelines though, most of all regarding Actors positioning on the diagram. It is a common practice to show the actores on the border of the diagram, keeping internal system objects inside. Moreover, human actors are typically shown on the left side, while system actors are kept on the right. Actors should not be "mixed" with system objects. Here is a simple example:
Everything in behavioral diagram is executed after behavior defined by diagram started.
If actors interacts individually, and their interaction are not moxed in single execution, you must draw diagram for each case.
I would say you need two diagrams, each for one actor.
When should the Actor Model be used?
It certainly doesn't guarantee deadlock-free environment.
Actor A can wait for a message from B while B waits for A.
Also, if an actor has to make sure its message was processed before moving on to its next task, it will have to send a message and wait for a "your message was processed" message instead of the straightforward blocking.
What's the power of the model?
Given some concurrency problem, what would you look for to decide whether to use actors or not?
First I would look to define the problem... is the primary motivation a speedup of a nested for loop or recursion? If so a simple task based approach or parallel loop approach will likely work well for you (rather than actors).
However if you have a more complex system that involves dependencies and coordinating shared state, then an actor approach can help. Specifically through use of actors and message passing semantics you can often avoid using explicit locks to protect shared state by actually making copies of that state (messages) and reacting to them.
You can do this quite easily with the classic synchronization problems like dining philosophers and the sleeping barbers problem. But you can also use the 'actor' to help with more modern patterns, i.e. your facade could be an actor, your model view and controller could also be actors that communicate with each other.
Another thing that I've observed is that actor semantics are learnable by most developers and 'safer' than their locked counterparts. This is because they raise the abstraction level and allow you to focus on coordinating access to that data rather than protecting all accesses to the data with locks. As an example, imagine that you have a simple class with a data member. If you choose to place a lock in that class to protect access to that data member then any methods on that class will need to ensure that they are accessing that data member under the lock. This becomes particularly problematic when others (or you) modify the class at a later date, they have to remember to use that lock.
On the other hand if that class becomes an actor and the data member becomes a buffer or port you communicate with via messages, you don't have to remember to take the lock because the semantics are built into the buffer and you will very explicitly know whether you are going to block on that based on the type of the buffer.
-Rick
The usage of Actor is "natural" in at least two cases:
When you can decompose your problem in a set of independent tasks.
When you can decompose your problem in a set of tasks linked by a clear workflow (ie. dataflow programming).
For instance, if you process complex data using a series of filters, it is easy to use a pipeline of actors where each actor receives data from an upstream actor and sets data to a downstream actor.
Of course, this data-flow must not be linear and if a step is slow in your pipeline, instead you can use a pool of actors doing the same job. Another way of solving the load balancing problems would be to use instead a demand-driven approach organized with a kind of virtual Kanban system.
Of course, you will need synchronization between actors in almost all interesting cases, but contrary to the classic multi-thread approach, this synchronization is really "concrete". You can imagine guys in a factory, imagine possible problems (workers run out of the job to do, upstream operations is too fast and intermediate products need a huge storage place, etc.) By analogy, you can then find a solution more easily.
I am not an actor expert but here is my 2 cents when to use actor model:
Actor model is not suited for every concurrent application, for instance if you are creating an application which is multi threaded and works in high concurrency actor model is not made to solve the concurrency issue.
Where actors really comes into play is when you are creating an event driven application. For instance you have an application and you are tracking what are users clicking in your application realtime. You can use actors to do activities realtime segregated by user, device or anything of your business requirement as actors are stateful. So, for example if some users lies in actors which clicked on shirts you can send them notification of some coupon.
Also some applications where actors comes handy are : Finance (Pricing, fraud detection), multiplayer gaming.
Actors are asynchronous and concurrent but does not guarantee message order or time limit as to when the message may be acted upon. Hence atomic transactions cannot be split into Actors.
If the application/task involves no mutable state then Actors are overkill as Actor frameworks go to great lengths to avoid race conditions.
Is This use case is correct/proper according to UML? if not please give some input to improve it..
The ways we can look on it as the boundary value "Use Cases" can be described something as "Release Phase 1"?
Writer Module/Reader Module should be proper Ator?
alt text http://img190.imageshack.us/img190/6708/usecaseh.jpg
This diagram is telling me that there is something external to the system you are developing called a "Writer Module". The Writer needs three Use Cases, for example Initialization.
Similarly another actor needs Check Status and StackUp.
If that is what you intended to say, then this diagram works. Do you really mean it? Does only the Writer module Initialise the system? Or does the system initialise itself? Can the Reader check whether the system has been initialised, before it has been initialised? Is there another Use Case?
Small improvement: make the Use Case names match in their parts of speech. Initialisation is a "Thing", Check Status is an "Action". Perhaps Initialize System might be better? "Stack Up" not "StackUp", be consistent.
Normally the reason you group the use cases using a box is to show what system is helping meet or realize the use case. It is formally known as a system boundry ("The system you are building". Normally the systems, modules, etc that are actors are more black box, existing, or use only. If there are many new or modified systems this definition gets confusing.
The other comments are semantics of what you are showing, but are not sytax, still important.
Page 103 of Martin Fowler has a diagram and discription that uses the system boundry concept and system actors.
To pick on an example: this diagram says that Check Status is a scenario with two participants, a Writer and a Reader. Is that what you want to say?
Also, I don't remember seeing boxes around (sets of) Use Cases in general.
Use cases are meant to show how someone uses a system to get something of value. Actors always represent persons, in the sense of an independent being who has goals and is capable of seeking something of value.
Actors are represented in one of several ways, either directly by name, or by inclusion through a role, or by proxy in the form of an agent acting on behalf of a person or role (the "system" actor). Regardless of the form, the actor is always independent, and always capable of "acting" upon the system to achieve its own ends.
The diagram you have here is NOT a use case diagram. "Modules" are not independent, goal-seeking entities, they appear to be simply components of some system. They are not capable of "seeking" anything, they are just implementation details.
The diagram you are probably looking for is the Deployment diagram (if you want to model how specific components are wired together), the Activity diagram (if you want to model application logic), or the Class diagram (if you want to model the formal relationships between components).