I'm in the process of designing an activity diagram for a real-life card game and would like to know whether or not the use of a synchronization bar in the image attached is correct.
From my understanding, a synchronization bar can be used to separate flow into two or more activities. In my diagram, I've tried to illustrate two teams picking up a card from the set of cards they've been given. Team B's flow ends after picking up a card, this is because Team A must ask a question (found on the card) first.
Basically your diagram is correct. Drawing of cards happens concurrently. However, there is an improvement you can do. I don't know out of which reason one of the players will ask a question and the other won't. So here I assume the fastest one will start (remembering a card game from Africa where both players draw cards as fast as possible with one hand and put them somewhere; no idea of the name and rules but it was fun to play). Anyhow, here's my suggestion:
Just put the drawing in an Interruptible Region and name it after whet ever causes the one player to be the first to ask. The flow final is not necessary as to UML rules (the token is swallowed since player B's action has no outgoing flow).
I want to offer some improvements based on your explanation. (However as #ThomasKilian said, it is not so clear why one of the players will ask a question )
Case 1:
If both (TeamA and TeamB) should pick up the card and after that, you check the existence of question in selected cards: Your systems should wait for two players to pick up the card. So in this case, you should use Join Node after two pick a cards. (see my previous post about Join)
Case 2:
If the fastest Team should ask the question and there is no need to other team pick the card, there is an other improvement here:
You should use a Merge node with Decision after two pick a cards (see Merge with Decision explanation in this reference). (You can use a Merge node and after that a Decision Node too.)
So your decision is based on fastest team that pick the card. Then you should complete the model with following statement. If TeamA is fastest then TeamA should ask the question and TeamB should answer and if TeamB is fastest then TeamB should ask the question and so on.)
You can use this improvement in case 1 too (after the Join Node, you need a Decision to find the team that select the card and add above statement to your model).
Finally, If TeamA always ask the question after pick up the card and there is no need to picking the card from TeamB, there is only one improvement to use a Merge Node after two pick a cards. Consider that Merge Node input flows are alternate flows to accept single outgoing flow.
Related
I'm modelling an activity diagram for a project. Directly after initial node is it okay to use a decision node. I just google for it. But I fail to find similar examples even.
Eg:- imagine a person can Search for a dog name or Select the category animal, then dog likewise at the very beginning.......
One of my team mates mention that according to above example those are two different activities and we should create two activity diagrams for it.
This is allowed under condition.
The rules concerning the input flow(s) of a decision node are (formal 2017 § 15.3.3.6 Decision Nodes page 390) :
A DecisionNode shall have at least one and at
most two incoming ActivityEdges, and at least one outgoing ActivityEdge. ... If the DecisionNode has only one
incoming edge, then it is the primary incoming edge. If the primary incoming edge of a DecisionNode is a ControlFlow,
then all outgoing edges shall be ControlFlows and, if the primary incoming edge is an ObjectFlow, then all outgoing edges
shall be ObjectFlows.
Also knowing (§ 15.3.3.1 Initial Node page 387) :
The outgoing ActivityEdges of an InitialNode must all be ControlFlows.
that means in your case, and supposing there is no other input edge to the DecisionNode, all outgoing edges of the DecisionNode shall be ControlFlows, else this is not allowed
Your team mate isn't wrong. This is a design question which should have been clarified beforehand. Activities are functional parts inside of use cases. They represent scenarios like "sunny day", various error scenarios, etc. And again one step back the use cases represent the added value the system under consideration represents for its primary actor.
Now from your examples it's hard to tell what that system should be. Search for dog name could be a use case, but in which context? Is it to name a new dog or to search for an existing dog in a database? Same for Select animal category(and then dog?). Both do not make much sense as use cases. Once you come up with meaningful use cases you can tell exactly which steps the activities should have as actions. Only then you can have the need to decide. The decision which use case to actually use it outside the system and you wont see the steps done for it.
As a recommendation: Bittner/Spence have an excellent book about use cases which (unlike the UML specification) makes a lot of sense. There are also other well known authors teaching the same school (along Ivar Jacobson).
I am new to business analyst. Currently I have a project that needs to communicate between systems. Based on my use case, I have 2 systems and 1 data centre.
Client A can use System1 and System2. If client A makes a withdraw through System1, System 1 needs to send the details to the Data Centre.
Client A also can make a withdraw through System2 and System2 needs to send the details to the Data Centre. The Data Centre is basically the place where System1 and System2 submit their details to. Of course, it has a rule that System1 and System2 can't send and receive the details directly without the Data Centre. Can I draw it out like this?
Your use case diagram is invalid, a use case diagram doesn't show exchanges, for that use a deployment diagram for instance :
The Data Center is a secondary actor if is not part of your global system (contrarily to System1 and System2) :
If Data Center is part of your global system it doesn't not appear in the diagram because this is part of the implementation. The use cases show what must be done rather than how it is done.
If you are after showing use cases, then there is only one you named Withdraw.
Use Cases show a single added value for an actor which is dealing with the system under consideration (SUC). From a business perspective you don't care about technical details. You will put that into requirements like { ATM must be used } etc. But you're actually only after the goal behind the UC in the first place. Next would be to describe scenarios how that goal could be achieved. Only then you care about (program) technic. Please also note that verb-only use cases are not a good choice. Use a predicate-subject(-object) form, so in your case Withdraw money.
That being said (I recommend reading Bitter/Spence about use cases as always) it rather looks like you are doing a technical documentation of an existing system. You can do that by showing devices
Note the multiplicity that says there's one data center and any number of ATMs. Now what actually happens between the components can be detailed by using sequence diagrams, using interfaces and things like that. Details are too many to be shown/explained here.
For example, the user can perform action A, action B or action C in a tool. Whether they choose A, B or C, the order of these actions and how many times they are repeated is up to the user and the reason why they choose A,B or C and why they are chosen in a particular order isn't clear. Also any action can be repeated again after another action has been done by the user.
EDIT: A more concrete example would be the creation of an image. The user can draw a shape, choose a new shape, choose a new colour and save the image. While drawing these 4 actions can be performed intertwined in any random order and in any random quantity, only guided by the whims of the user.
There is also the choice of creating a new image from scratch or editing an existing image to create a new image.
Very simple solution to you question is below.
Please do not omit the guards after decision node if you don't want to have an undeterministic behaviour of your activity. Decision node offers a token to the first flow that have true guard whereas the order of evaluating of the guards is not defined.
When modelling anything using any notation, it is important to remember what the purpose of is in creating the model, and who is going to use it.
If you simply omit the guards on arcs, then the model has no information describing how the system behaves. It cannot guide another developer to create the software, it does not record the intent of the designer.
The user is outside the system boundary, so the decision as to what action to perform is elsewhere. The system behaviour should be modelled as a condition of its state, inputs or events - these are what the system can operate on, and what developers expect to find in the UML model to guide them.
The exact UML construct used will depend on how that choice is communicated across the system boundary - an activity diagram may well not be the best way of communicating that, or you might use multiple diagrams for each interaction
The software being modelled does not make an unconditional choice, and the information in the model should reflect that with enough detail to be useful to the next person viewing it.
Normally a loop node should help you to solve your problem. If the flag isTestedFirst, the loop node is a while-do loop.
However this is not the easiest node of activity diagram.
It has three part : the setup part, the test part which is test at each iteration and the body part.
Maybe this image extracted from sparx documentation may help you :
Hope this help and maybe someone else may provide more details.
Well, you just leave away the guard:
Now the path can take any way. However, since there is a choice, it's the user taking the action and choosing the path he likes.
Edit Thinking a bit about the "natural" control flow it seems obvious, that preceding the ConditionalNode you find an action like Offer choice (e.g. in the concrete example of the OP: "draw", "choose shape", "choose color", etc.). So the outcome of the ConditionalNode is one of the users choices which in turn should have an appropriate guard. So the above is merely a sketch and can be regarded as incomplete. However, presenting this sketch to a reader would either make him "aha" or ask the question that came up my mind after thinking a while. Regardless of this, there will be just one path been taken after the ConditionalNode.
I have a scenario where a customer calls and gets an appointment at a garage. When drawing a UML Use Case Diagram, is the actor who is connected to placing this appointment inside the system (a) the customer, or (b) the employee?
The person that has their fingers on the keyboard and mouse is the actor. The person calling in is important from a business perspective, but not as important as the customer service rep that is interacting with the system.
Knowing that the actor is a CSR helps the screen designer and even the developer, because they will work from that perspective, ask for requirements or design clarifications from that perspective, and the system will be better as a result.
The reason the conflict exisits is because of the point of the project when you start drawing these use cases.
In your example, you already know that there is a CSR using 'a system' to make the booking.
However the design could have started from scractch. If this had happened the initial broad use case would have been 'a customer wishes to make a booking'. This could have lead to a number of differenc cases i.e. a customer will call a telephone number and an automated service will make the booking, a customer arrives at the garage and uses a terminal to make a booking or (as in your case) talks to a CSR (however that is i.e. phone or face2face) and they make the booking.
In many examples the customer would be the main actor in the system. However in your design the CSR is the one holding the mouse/keyboard/phone/pen or whatever and you don't need to design the iteraction between the customer and the CSR! Most societies did that years ago :)
It can be both. It depends. There is no single good way to model this. I would personally opt for the customer.
It is btw perfectly alright to include the phone as part of your system. So the boundary of a system does not have to be a defined by screen, mouse, keyboard. A printer might be included too as part of the system. I have written use case where it was quite essential that users printed some information and file that.
Who is the important actor here? The customer right? It is interesting to note here that Alistair Cockburn extended the actor and goals model of Ivar Jacobson with the actors and 'interests' model. His advice is to also think about who cares (or gets hurt) if user goal fails.
Is it important to get the actor just right? It is useful to brainstorm actors to find all user goals against the system. When you are confident you have found all goals, the actor is not so important anymore. Would you 'write' a completely different use case depending on this decision? Would a different system be build based on the outcome of this decision?
Who initiates the interaction? What is the event initiates it? This event is the decision of customer to call to make an appointment.
You could model customer as primary and employee as secondary actor helping customer to reach user goal. Both use phone and system to reach the goal, customer helped by employee. How they do that exactly is design?
Another consideration is that the 'actor' is a role. So you could use a role Appointment Maker. Some people care a lot about keeping job titles separate from roles as there typically some flexibility in roles that job titles perform.
There are also people who are of opinion that use of 'system' in describing use case is undesirable. They feel that it is a design/implementation decision and so they prefer more neutral 'Performer'. The Performer could be a system but also a human. In use case texts they use 'Initiator' and 'Performer' and in introduction of the use case text they explain that the 'Initiator' is in use case the Appointment Maker.
I personally think it would be fine and better if the use case was described as if customer was the one operating the system. The employee is just passing along information from system to customer and vice versa.
The book by Alistair Cockburn is a recommended read. His insights really helped me with questions like this one. It also helps to make sense of UML in relation to use case
A group diary and time management system is intended to support the timetabling of
meetings and appointments across a group of coworkers. When an appointment is to be
made that involves a number of people, the system finds a common slot in each of their
diaries and arranges the appointment for that time. If no common slots are available, it
interacts with the user to rearrange his or her personal diary to make room for the
appointment.
First step is to think about what objects you have in the system. Make a list of candidates.
Now think about how does this scenario get initiated. Where does the message come from? Draw that incoming message.
The next step is to think about which object is going to receive that message. Now in order to do the work that object will probably need to talk to other objects. Sketch out the other object with an arrow and a message name.
Keep thinking about the sequence of messages and the objects to which the messages go - and try sketching them out one at a time.
Don't expect to get it right first time. Try sketching out several approaches.
A sequence diagram describes interactions between objects that achieve some goal.
So your first step needs to be to identify some objects (and actors). If you start with that step, show us your attempt, then we have something to discuss further.
"You should identify possible objects in the following systems and develop an object-oriented design for them. You may make any reasonable assumptions about the systems when deriving the design."
From Chapter 14 Exercise 14.7