i have following Activity Diagram:
I need to solve the upper section of diagram.
The "false" branches of decision and their join before getting to "Show form" action, it my solution ok or should this be solved some other way ( all three arrows to the show form or some diamond join) ??
One glaring problem is that “Show Form” deadlocks. It can never start because all tokens must arrive on all arrows before it can start. The way an activity diagram works is that each action is a step. A completed action offers tokens to outgoing edges. As soon as any action is offered all the tokens it needs to start, it actually starts. I recommend you read the excellent series by Conrad Bock to be sure you understand how activities work.
Related
I'm new to SysML and modeling in general and this is for the purpose of learning.
I have an activity diagram and multiple calls to a "Call behavior" and would like the calling activity diagram to continue from where it left off, after the Call behavior has finished executing.
I tried using guards, even though that is not exactly accurate, but that did not work for me either.
The left part of the diagram shows a merge node with a control flow to "Verify_And_Map_Data", and the intention is for all three operations to repeat the call behavior in sequence.
The sequence intended is :
Initialize_Master_Follow_Data
Verify_And_Map_Data
Initialize_XOR_Data
Verify_And_Map_Data
Initialize_Feedback_Linked_Data
Validate_Motor_Start_Stop
Edit: Thanks qwerty_so . How about this one, it pretty much contains the same elements and control flow, exempt for evStartAnimation,, and organized in a top down way.
Top-Down_Activity Diagram
I have an analysis exam tomorrow and one of my designs is a sequence diagram. I do not know if I have got it right. Its pretty simple, its supposed to illustrate a teacher who creates an assignment and posts it to a schools website, then a student gets a notice and the teacher is able to edit or add more files to the assignment. Repeat
Is it something wrong with this diagram? What could I have changed?
What are some key points about sequence diagram that I could say in my oral exam.
Strictly speaking, what you draw is NOT a sequence diagram in UML spec. There are more than one correct ways to draw a sequence diagram for a given flow.
Here is a sequence diagram I created with ZenUML (I created this tool btw). There are a few key items in a sequence diagram - lifeline, message and fragment.
This answer is certainly late for the exam, but your diagram looks ok. For the sake of completeness, here some minor remarks:
the messages are certainly all asynchronous (i.e. the website will not wait for the student to answer the notification before it continues its job); so the arrows should have an open head
you could consider using a combined fragment (with operator loop) around the interactions related to the addition of a file, to show that this part may be repeated.
all messages in your diagram describe interactions. The wording "web page is updated" suggests a state, whereas a wording "notify student of the update" would be more consistent with the rest.
the first execution occurence ("activation bar" on the lifeline) on the website should start with the incoming message that triggers the related activity. Similarly, for the student I'd put a small activation bar after each notification, instead of a continuous one.
I was reading about statechart diagrams, which are diagrams that model the different states that one or more instances of one or more classes can be.
An object can go from one state to the other through a transition, which is represented using arrow with an event and eventually a action to that event over and respectively below it.
My problem now is that I don't understand exactly what are OR and AND decompositions in a statechart diagram. Could you please give me an explanation (since I've not found around any)?
I would really appreciate a concrete example with the corresponding picture or diagram.
The following picture is an example for an OR. Consider a token traveling from Initial to the Choice (diamond). Here the token travels either to the left or right guided by the constraints which test the condition checked in Choice. From then where they are they next transit through the following unnamed diamond to Continued. You might leave away the joining diamond and draw the transitions directly to Continued.
The AND condition looks like this:
The first Fork(the bar) duplicates the token and sends them to Either and Or. The Join behind these states waits for two tokens to arrive before it sends only one token further to Continued.
Fork and Join use the same symbol. They wait until all incoming tokens arrive and then send as many tokens as there are outgoing transitions. So they are actually some split personality. But mostly they are used the one or the other way.
I would like to represent the following in a UML Activity Diagram
1) User requests a product list from Application
2) Application requests product list from Database
3) Database returns product list to Application
4) Application displays list to User
Originally I thought this would be a simple case of arrows travelling from left to right connecting to each activity boxes then drawing arrows back all the way to the where the request started as follows:
User-->Application-->Database
User<--Application<--Database
But then I noticed I see no examples of UML Activity Diagrams with arrows showing the return of anything back to a requester. They all show a one way path to an end point. Is a return always implied if it started with a request to get something? Are return arrows incorrect to use?
Thanks in advance.
Update ---
After some looking around it appears paths are one way. When you reach the end point that is to provide something like a list instead of drawing arrows all the way back to the requester it looks to me like you just add a phrase to the end node saying something like the following: "Return list".
It seems you may not understand the token semantics in activities. An activity diagram does not represent a call stack where one action returns to the previous action. However, one action calling another Call Behavior Action does work like a call stack.
The way an activity diagram works is that each action is a step. A completed action offers tokens to outgoing edges. As soon as any action is offered all the tokens it needs to start, it actually starts. Data and control both work this way.
You can think of each action like a function call. When all tokens are ready on all incoming edges, the function is invoked. When a function finishes, all the outgoing tokens are offered to all enabled outgoing edges. (Outgoing edges are enabled when an optional guard is not false.)
I recommend you read the excellent series by Conrad Bock to be sure you understand how activities work. Otherwise, you are going to frustrate yourself and others trying to make it fit your preconceptions.
There's nothing stopping you from introducing loops in an activity diagram, although for clarity, whenever you've got two or more possible exits from one activity, you should use guards on your connectors to specify under which condition that connector may be followed (eg [x < 10] on one and [x >= 10] on the other).
You can also use decisions (rhomboid) if you want to make the branching condition explicit (eg a decision named "x < 10 ?"); you'd then draw a single connector from the preceding activity to the decision, and the two guarded connectors from the decision.
But from your example it seems you're not drawing a proper activity diagram at all. In an activity diagram, the nodes must be activities -- not actors. There should always be a verb in the name of every activity. So "User requests a product list from Application" is a good activity, but if you've got an activity named "User" you're doing it wrong.
i am currently doing an dynamic model for my ojt project. but i am stuck on a particular problem, my idea of a solution just seems overly complex.
to explain it in a different context, lets say i have 2 classes: customer and salesperson. the customer is buying something from the customer. but before everything is settled, they have to undergo a series of activities. after each activity, both the customer AND the salesperson have to chance to back out of the transaction. put in a diagram it looks like this:
is this correct? how about when i have like 50 possible activities? then that diagram will become very unreadable. what is a good way to solve this?
If you look at InterruptibleActivityRegion in the UML spec (section 12.3.33 of UML 2.4.1 superstructure ), it gives a similar example of cancelling an order at any point before the transaction is agreed. Within the interruptible region, which is notated as a dashed rounded rectangle with a Z shaped arrow coming out of it, all the activities may be interrupted by the event associated with the arrow - in your case backing out - and end up in the interruption handling activities.
You should use interruptible activity region. For a quick reference, see this sample diagram: