I have a situation where 3 options are presented to a user by a system:
Open PDF1.
Open PDF2.
Proceed.
The system instructs the user to read the PDFs, but doesn't enforce it.
So they're free to just click the proceed button and move on to the next screen.
I drew the following diagrams, but I feel like I've got it wrong somehow.
That's not correct this way. Your 2nd attempt isn't better at all. The bars will create parallel flows, but since you join them immediately it's actually a no-op in the first case. The bar will not be reached since it waits for 3 tokens where only one can actually arrive. In the 2nd case will never continue after the join since it only gets one token from the Provides... action but need 3 to continue.
Here's a cut part of what you need to do:
There's a merge node at first to capture the tokens coming from either the action on top or from the two left ones. After there there are two decisions going guarded to the actions at the left. The can be continued to the top (guard [read next]) or to the bottom (guard [acknowledge]). That way the user can repeat reading (or skip it completely) until he passes the Acknowledge action. There's a final merge node preceding that action.
Note that the read/ack guards should appear twice for each flow to make it a machine readable model. The texts here are just overlaid but a human can understand it anyway.
Related
I am new in doing an activity and currently, I am trying to draw one based on given description.
I enter into doubt on a particular section as I am unsure if it should be 'split'.
Under the "Employee", the given description is as follows:
Employee enter in details about physical damage and cleanliness on the
machine. For the cleanliness, there must be a statement to indicate
that the problem is no longer an issue.
As such, I use a foreach as a means to describe that there should be 2 checks - physical and cleanliness (see diagram in the link), before it moves on to the next activity under the System - for the system to record the checks.
Thus, am I on the right track? Thank you in advance for any replies.
Your example is no valid UML. In order to make it proper you need to enclose the fork/join in a expansion region like so:
A fork/join does not accept any sematic labels. They just split the control flow into several parallel ones which join at the end.
However, this still seems odd since you would probably have some control for the different inspections being entered. So I'd guess there's a decision which loops through multiple inspection entries. Personally I use regions only for handling interrupts. ADs are nice to a certain level. But sometimes a tabular text (like suggested by Cockburn) is just easier to write and read. Graphical programming is not the ultimate answer (unlike 42).
First, the 'NO' branch of the decision node must lead somewhere (at the end?).
After, It differs if you want to show the process for ONE or MULTIPLE inspections. But the most logical way is to represent the diagram for an inspection, because you wrote inspection without S ! If you want represent more than one inspection, you can use decision and merge node to represent loop that stop when there is no more inspection.
We are using an event store that stores a single aggregate - a user's order (imagine an Amazon order than can be updated at any moment by both a client or someone in the e-commerce company before it actually gets dispatched).
For the first time we're going to allow our company's employees to see the order's history, as until now they could only see its current state.
We are now realizing that the events that form up the aggregate root don't really show the intent or what the user actually did. They only serve to build the current state of the order when applied sequencially to an empty order. The question is: should they?
Imagine a user that initially had one copy of book X and then removed it and added 2 again. Should we consider this as an event "User added 1 book" or events "User removed 1 book" + "User added 2 books" (we seem to have followed this approach)?
In some cases we have one initial event that then is followed by other events. I, developer, know for sure that all these events were triggered by a single command, but it seems incredibly brittle for me to make that kind of assumptions when generating on the fly this "order history" functionality for the user to see. But if I don't treat them, at least in the order history feature as a single action, it will seem like there were lots of order amendments when in fact there was just one, big one.
Should I have "macro" events that contain "micro events" inside? Should I just attach the command's id to the event so I can then easily inferr what event happened at the same and which ones not (an alternative would be relying on timestamps.. but that's disgusting).
What's the standard approch to deal with this kind of situations? I would like to be able to look at any time to the aggregate's history and generate this report (I don't want to build the report incrementally every time the order is updated).
Thanks
Command names should ideally be descriptive of intent. Which should mean it's possible to create event names which make the original intent clear. As a rule of thumb, the events in the event stream should be understandable to the relevant members of the business. It's a good rule of thumb. It should contain stuff like 'cartUpdated' etc.
Given the above, I would have expected that the showing the event stream should be fine. But I totally get why it may not be ideal in some circumstances. I.e. it may be too detailed. In which case maybe create a 'summeriser' read model fed the events.
It is common to include the command’s ID in the resulting events’ metadata, along with an optional correlation ID (useful for long running processes). This then makes it easier to build the order history projection. Alternatively, you could just use the event time stamps to correlate batches in whatever way you want (perhaps you might only want one entry even for multiple commands, if they happened in a short window).
Events (past tense) do not always capture human - or system - user intent. Commands (imperative mood) do. As all command data cannot always be easily retraced from the events it generated, keeping a structured log of commands looks like a good option here.
If I have two frames in my GUI. (Assume 1st frame ="A" and 2nd frame="B").
when clicked on "A", it redirects to "B".
when Clicked on "B", it redirects to "A".
So it is continuously looping.
Is it possible to draw the Activity Diagram without adding the final node?
note: But anyone can click on the cross mark on top right corner and exit from the program. (Is that means I have to add final node to everywhere??)
You would model it with an interrupt flow like this:
The dashed boundary represents an interruptible region from where a flash-formed flow can exit at any time.
The Exit has not outgoing edges and thus ends the control flow. You might optionally add an outgoing flow to a flow final, though.
Alternatively, if there are many exceptions you could use this variant:
I doubt that is is really UML compliant, but as I say: "if it serves communication, it's fine". And from the context this looks rather evident.
Yes. An Activity ends when an Action ends and no other Action has the tokens it needs to start. You can find many fUML test cases that work like this, without explicit start and end nodes.
It is my first time doing a Petri net, and I want to model a washing machine. I have started and it looks like this so far:
Do you have any corrections or help? I obviously know its not correct, but I am a beginner and not aware of the mistakes you guys might see. Thanks in advance.
First comments on your net's way of working:
there is no arrow back to the off state. So once you switch on your washing machine, won't you never be able to switch it off again ?
drain and dry both conduct back to idle. But when idle has a token, it will either go to delicate or to T1. The conditions ("program" chosen by the operator) don't vanish, so they would be triggered again and again.
Considering the last point, I'd suggest to have a different idle for the end of the program to avoid this cycling. If you have to pass several times through the same state but take different actions depending on the progress, you have to work with more tokens.
Some remarks about the net's form:
you don't need to put the 1 on every arc. You could make this more readable by Leaving the 1 out and indicating a number on an arc, only when more than one tokens would be needed.
usually, the transitions are not aligned with the arcs (although nothing forbids is) but rather perpendicular to the flow (here, horizontal)
In principle, "places" (nodes) represent states or resources, and "transitions" (rectangles) represent an event that changes the state (or an action that consumes resources). Your naming convention should better reflect this
Apparently you're missing some condition to stop the process. Now once you start your washing will continue in an endless loop.
I think it would be nice to leave the transition graphics unshaded or unfilled if it is not enabled. Personally I fill it green if it is enabled.
If you want someone to check if you modeled a logic properly in your Petri Net then it would be nice if you include a description of your system logic in prose.
My question actually consists of two questions regarding the same process modelling in an activity diagram.
The process in short:
Joe uploads a file into a portal, this portal transfers the file to our server where it is checked for errors. In case of an error the server sends a message to the portal where Joe can see this (if he is still logged in or on his next visit) and upload his file again (hopefully without the errors this time). In case of success the server will also notify the portal but Joe doesn't have to take any action so we are not interested in the result. As the file is okay the system now wait for Sarah who has to start the processing of the file manually after which the process completes.
In the below diagram I have drawn this, including my two problems.
Am I allowed to let the "Notify User of succes" (I spotted the spelling mistake, thank you) in the Portal swim lane to terminate like this? If I were to put a ActivityFinal behind this that would mean the entire process would end right there which is not what we want.
Am I allowed the to join before the "process file" without a fork or do I need a fork at the very start spanning all across form Joe to Sarah?
The point of this is nothing more than an attempt to find a valid UML solution to solve this, in my own diagrams I would just do it like in the example.
Thanks in advance!
I'm not sure if it forbidden to leave an activity node without outgoing links, but for clarity (since users may think this is a mistake) I would use a flow final node (circle with x inside). This node simply terminates the flow and does not affect other flows in the diagram.
You can use a join node anywhere you want, independent if you previously did a fork or not. So what you did is correct.
I would in that case make a arrow from 'Notify user of success' to the join element, delete the arrow from the fork to the join element, and create an arrow from the fork to 'Start process'.
As far as I know the join element must have a fork at some point before it.
You can have many activity end nodes in the diagram, but I think you can't have more than one start nodes.
You have no activities on the activities diagram, do you think it is OK? No.
When a lane receives something, it should be shown as message (writing on the arrow), not as an action. Sending and receiving are special things, that are shown not as actions, but as arrow ends or if they are important as activities' parameters - border rectangles.
As for fork/join combining, it is absolutely OK.
Here is an example diagram, I have put useful for you elements on it. It doesn't mean you should copy it, only use it as a source.