BACKGROUND
An UML sequence diagram is commonly used to create a representation of messages sent between actors of a system, and thus clarifying the information flow. In general, messages are displayed between the communicating actors, which is a good practice and obviously appropriate for handling "messages".
MY APPLICATION
Now, I want to (mis)use sequence diagrams rather for clarifying which activity is performed on which actor, rather than which messages are sent between actors. Thus, I can e.g. describe the activity distribution within my system. I want to place text describing activities on the right of actors.
MY PROBLEM
When handling "Notes" in activity diagrams, PlantUML provides the possibility to freely place them around (left, right or in the center) of an actor, but I haven't figured out if this freedom was granted to messages as well.
Here is an example PlantUML sequence:
#startuml
' two activities executed on actor1
activate "actor1" #Olive
"actor1" -> "actor1": actor1 activity1\nactor1 summary1
' two sub-activities executed on actor1
activate "actor1" #OliveDrab
"actor1" -> "actor2": actor1 sub-activity1\nactor1 sub-activity2
' then comes a transition from actor1 to actor2
' and two activities executed on actor2
activate "actor2" #Olive
"actor2" -> "actor1": actor2 func activity1\nactor2 func activity2
' two sub-activities executed on actor2
activate "actor2" #OliveDrab
"actor2" -> "actor2": actor2 func sub-activity1
#enduml
Which creates this result:
Currently, the diagram has some other problems as well, but that shouldn't be an issue, here. I would just like to be able to place the "messages", which should be thought of "activities" in my case, on the right of each of the actors where they are created / initiated.
Here a principle picture how I could imagine the output:
I could try to use messages going from e.g. "actor2" to "actor2", but this always creates these reflexive arrows, which I don't really want to be seen in the diagram. And, I would like to stick to PlantUML for these kind of diagrams. Don't know if there was another kind of diagram to display "actors" and their "activities" in relation to each other.
Would this be possible?
You can always hide the arrows using white transparent color and create some "fake activations" It is a bit of a hack but I guess this would suite your request:
#startuml
A1 -[#ffffff00]> A1:
activate A1
A1 -[#ffffff00]> A1: first activity of A1
A2 -[#ffffff00]> A2:
activate A2
A2 -[#ffffff00]> A2: first activity of A2
A1 -[#ffffff00]> A1:
activate A1 #blue
A1 -[#ffffff00]> A1: 2nd activity of A1
#enduml
Related
There is an exercise that requires us to draw a usecase diagram for a bank,
description says that a customer can make deposits and withdraw money. for that usecase scenario do i just draw
"make deposit" and "withdraw money" ? or should I <<'include'>> "update balance" function for both of them as well ?
There is a rule of gold that help me solve similar situations, hope it helps for you.
Use case definition: Series of interaction between an actor and the system to obtain added value.
So, as you can see there are interactions, basically a use case is a series of interactions.
Which interactions are for update balance? None, is just a calculation the system (as opposed to the actor) does.
Let's specify that use case under the assumption is a business use case and is a ATM.
1) Actor1 press 'start button'
2) The system show present card screen
3) Actor1 present card
4) System present menu with options...
5) Actor1 select withdraw .... ...
6) System present screen with updated
balance
7) Actor1 select ....
So this is quite visual, is not a Use case in the first place, becouse there are no interactions involved. So there is no need to check if bring added value or not. Is just an important part of one of the many interactions involved.
There are exceptions in which you may take that shortcut, such as if you want be more clear in the model or if you what to divide work based on Use cases. But IMHO that's not use case at all.
You may have 'Show balance', but it would be only one interaction, with the exception if you have options like "show on screen" or "paper-print on a ATM"
Hope it helps.
Is Update Balance a use case? Is there any added value for the actor? I guess not. It's a simple function which is performed as part of the other 2 use cases. You are trying (like most people) to perform functional decomposition. Just that two use cases share a common function does not make the function a use case. A use case is about added value which the system under consideration delivers to its actor(s). When you describe the scenario inside the use case, you might well refer to scenarios is other use cases. Each scenario step will end in an action. And you could simply refer to the action Update balance described in Make deposit when you describe Withdraw money. But the, Update balance is the result from a simple add operation. So why referring to that as a common function at all?
If an actor communicates with use case A, does he automatically communicate with an extending use case B or do I have to draw a second association beetween the actor and use case B - if my intention is to have the actor execute both A and B? What if, instead of <<extends>>, the the association between A and B was <<includes>>? Would a line between the actor and use case A also imply that the actor can execute the included use case (B)? Or do I have to draw a second line from the actor to use case b?
EDIT: I'm afraid I did not make myself clear. My doubt is not about the semantics of includes and extends or when use them, but rather their correct representation on a diagram. If I was asked to draw an ATM use case diagram, I'd probably would come up with the same diagram #RedBeard presented. However, in the site [http://elearning.uml.ac.at/], they assert that, acording to them UML2 standard, for the diagram to be complete, one should also draw two more associations, connecting the actor directly to the included and extending use cases, that is, one line from the actor to Card Identification and one more from the actor to Online Help, otherwise these use cases would never be executed. Since I found this explanation nowhere in the UML Super Strucure book, I decided to post this question here.
I add an example coming (more or less) from UML2.5 Specifiation. As you can see when a "Customer" want to "Withdraw" he must "Card Identication" because you have an Include from "Withdraw" to "Card Identication" so a "Card Identication" is always included when a "Customer" want to "Withdraw".
At the same time when a "Customer" want to "Perform ATM Transaction" (which can be a "Withdraw", a "Transfer", or a "Deposit"), he may, or not select a "On line Help". Thsi is due to the Extend link between "Perform ATM Transaction" and "On line Help" which means that a "Perform ATM Transaction" can be extended by "On line Help".
So if you want to model the fact that a actor have to do always both A and B an Include link would work. An Include link model a possible extension which is not mandatory. Hoping it is clear.
Is there any "switch case" in use-case specification?
In the requirements:
When user select "contract" in combobox, a "contract" tab appears, then user will interact with the "contract" tab.
When user select "Independently funded", a "Funding" tab appears, then user will interact with the "funding" tab.
How can I specify this use-case in my use-case specification?
Those two "case" will be in basic flow, won't they? Then how can I specify the "switch-case"?
Edit: (Because many mistakes what I'm doing, I will make it clear)
I'm not in progress of drawing use-case or drawing activity diagram, I'm in the between. I'm writing use-case specification (which is used to describe a use-case, and will be used later to draw activity diagram).
For more detail: https://www.google.com.vn/search?q=use-case+specification&biw=1280&bih=683&source=lnms&tbm=isch&sa=X&ved=0CAYQ_AUoAWoVChMIn6ujsMDRxwIVC5COCh3aNQGY#
If you are describing the use case in the notes then write something like
Step m: User selects ?? from combobox. If selection is "contract" resume at Step n. If selection is "Funding" resume at Step o. ...
...
Step n: Resume at Step p.
Step o: Resume at Step p.
Step p: ...
where m, n, o and p are subsequent step numbers in your scenario.
If you are using Activities with Actions you can use a Decision node from where you have multiple outgoing transitions. Each transition then has a guard describing the switch (kind of a multi-if).
PlantUML suggests elseif-chains which gives also a nice graph.
I think this one fulfill the purpose of the cases and follows the UML decision object rules.
Considering this situation:
...when an order is placed there is a check for availability, if is passed the preparation will start else the order is refused.
If the customer decides to pay with a credit card before starting the preparation the price of the order is locked on the credit card.
When the preparation is completed the order is delivered and if more than 30 minutes from the placement of the order have passed there is a discount of 50%.
My doubt is how to model the if condition in a state machine diagram, I would model it in the following way but I'm not sure it's the right way:
How should I model if conditions in a state machine diagram?
On a UML state machine diagram, conditionals are associated with transitions. The transition has a 3-part label in the form of "trigger-signature [guard]/activity". Guard is the conditional and must evaluate to true in order for the transition to be taken. All 3 parts of the transition label are optional.
From your problem description, I might define 3 states named "Waiting for Order", "Preparing Order", and "Delivering Order". There is a transition from "Waiting for Order" to "Preparing Order" and that transition could be labeled "order placed [order is available] /". I opted to leave off the activity because, from the problem description, I don't see any activity associated with this transition. You could maybe draw another transition labeled "order placed [order is unavailable] / refuse order". However, this transition would start from "Waiting for Order" and return to "Waiting for Order" because we don't change states when the order is refused. In this transition I included the refuse order activity because I assume there is some actual activity associated with refusing an order.
Alternately, I have seen transitions drawn which include a decision diamond where the arrow leading into the diamond is labeled with the trigger, one arrow out of the diamond is labeled with [guard] / activity and the other arrow out of the diamond is labeled with [else] / activity. I'm not sure whether this is technically correct UML though.
I think that the conditionals that you put in the entry activities for your Preparation and Delivery states are pretty good the way they are. Because those conditionals seem like they are associated with the activity that occurs upon entry into those states rather than any state transition.
In an UML state diagram, an if-condition should be modeled as a choice element, represented by a diamond-shaped symbol. The outgoing transitions must be marked with the corresponding conditions ("guards" in UML terminology) in square brackets. A trigger (event) and a behaviour (action) may be additionally given as described by kkrambo.
Example:
This and this gives some good advice on choices (and state diagrams in general).
This diagram (taken from here) might help:
So to answer your question, you didn't do it wrong, it's just a matter of style and readability. As far as I know, UML doesn't really define a standard way to represent conditionals. So just go with what looks best and makes sense.
It is not possible to define conditions inside of state element of state machine. Review you diagram. I think , you should some information put on diagram. For example, use choice element to define alternative transition paths. Or draw detailed diagram for "prepare order" and "payment" behaviors from Preparation and Delivery states.
It is not always possible to put all information on the exactly one diagram.
in an activity dgm .. if an activity involves two sub activities..
should i make separate ending nodes for sub activities?
Should I make one ending node for main activity only ?
This is what i wants to say
Well, I would say that setting one ending node for your main activity can be enough. The ending node represent the termination of the whole activity you depict in your diagram. Thus the ending nodes as you put them are clearly invalid.
You can however describe ViewDetails and EditDetails with sub-activities. It that case, you can also terminate them with an ending point. In that case the ending is in the context of your activity. See here.
Personally I would create distinct diagrams for such a purpose but it seems that it is possible to represent this inside an action.
The diagram You have drawn so far is wrong. Activity diagrams represent the flow of control from activity to activity in the system.In your diagram "My profile" should not be an activity.And you need to represent activities in rounded rectangles.You can make decision point to separate the "view details" activity from the "Edit details" activity. Typically there is one starting point for the workflow and there may be more than one ending point. (one for each alternate flow in the workflow)