I would like to ask, if a final node in some activity can represent two different outcomes.
For example in use case buy premium account I can have two outcomes: IF I have enough credit then I will end the activity with bought premium account ELSE I end the activity with some error page that the user doesn't have enough credit.
Can I use the same final node in this case?
Yes you can with something like the image
More see the comment about in UML specification: "In Figure 15.44, two ways to reach an ActivityFinalNode exist; but it is the result of exclusive “or” branching, not a “race” situation like the example in Figure 15.43. This example uses two Activity FinalNodes, which has the same semantics as using one with two incoming edges."
It means that a FinalNodes may have two incoming edges, and the norm explains that the first flow which reaches the FinalNode terminates the activity what ever the other flow, and there is something special for output activity parameters.
Related
I am trying to model a situation in which a customer is added by either sales or an administrative assistent. They both have their own lane. I think using an OR or a 'AND' (paralel) gate would not really accurately reflect the situation.
How would you model this?
It would be great if there was an optional (either or) parallel gate but I don;t know if that exists.
I assume that you mean, whoever comes first will work on this activity. Therefore, a gateway cannot be the solution. It would need to have a condition, that is evaluated before one of the two activities get enabled.
This is what I would do: Create a new lane "customer admin" and specify somewhere else, that sales and adminstrative assistants are "customer admins".
If you duplicate "add customer" to show it in both lanes, you also have to model how one activity gets revoked, as soon as the other role starts working on it. If you want to model this, it gets really complicated. Of course, maybe a simple note could be sufficient, but I guess you are looking for a solution in BPMN.
If this activity would be the first in a process with empty start event, there is a simpler solution: Just use two empty start events and let the starter of the process decide, which one is to be used.
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.
I would like to implement CQRS and ES using Axon framework
I've got a pretty complex HTML form which represents recruitment process with six steps.
ES would be helpful to generate historical statistics for selected dates and track changes in form.
Admin can always perform several operations:
assign person responsible for each step
provide notes for each step
accept or reject candidate on every step
turn on/off SMS or email notifications
assign tags
Form update (difference only) is sent from UI application to backend.
Assuming I want to make changes only for servers side application, question is what should be a Command and what should be an Event, I consider three options:
Form patch is a Command which generates Form Update Event
Drawback of this solution is that each event handler needs to check if changes in form refers to this handler ex. if email about rejection should be sent
Form patch is a Command which generates several Events ex:. Interviewer Assigned, Notifications Turned Off, Rejected on technical interview
Drawback of this solution is that some events could be generated and other will not because of breaking constraints ex: Notifications Turned Off will succeed but Interviewer Assigned will fail due to assigning unauthorized user. Maybe I should check all constraints before commands generation ?
Form patch is converted to several Commands ex: Assign Interviewer, Turn Off Notifications and each command generates event ex: Interviewer Assigned, Notifications Turned Off
Drawback of this solution is that some commands can fail ex: Assign Interviewer can fail due to assigning unauthorized user. This will end up with inconsistent state because some events would be stored in repository, some will not. Maybe I should check all constraints before commands generation ?
The question I would call your attention to: are you creating an authority for the information you store, or are you just tracking information from the outside world?
Udi Dahan wrote Race Conditions Don't Exist; raising this interesting point
A microsecond difference in timing shouldn’t make a difference to core business behaviors.
If you have an unauthorized user in your system, is it really critical to the business that they be authorized before they are assigned responsibility for a particular step? Can the system really tell that the "fault" is that the responsibility was assigned to the wrong user, rather than that the user is wrongly not authorized?
Greg Young talks about exception reports in warehouse systems, noting that the responsibility of the model in that case is not to prevent data changes, but to report when a data change has produced an inconsistent state.
What's the cost to the business if you update the data anyway?
If the semantics of the message is that a Decision Has Been Made, or that Something In The Real World Has Changed, then your model shouldn't be trying to block that information from being recorded.
FormUpdated isn't a particularly satisfactory event, for the reason you mention; you have to do a bunch of extra work to cast it in domain specific terms. Given a choice, you'd prefer to do that once. It's reasonable to think in terms of translating events from domain agnostic forms to domain specific forms as you go along.
HttpRequestReceived ->
FormSubmitted ->
InterviewerAssigned
where the intermediate representations are short lived.
I can see one big drawback of the first option. One of the biggest advantage of CQRS/ES with Axon is scalability. We can add new features without worring about regression bugs. Adding new feature is the result of defining new commands, event and handlers for both of them. None of them should not iterfere with ones existing in our system.
FormUpdate as a command require adding extra logic in one of the handler. Adding new attribute to patch and in consequence to command will cause changes in current logic. Scalability is no longer advantage in that case.
VoiceOfUnreason is giving a very good explanation what you should think about when starting with such a system, so definitely take a look at his answer.
The only thing I'd like to add, is that I'd suggest you take the third option.
With the examples you gave, the more generic commands/events don't tell that much about what's happening in your domain. The more granular events far better explain what exactly has happened, as the event message its name already points it out.
Pulling Axon Framework in to the loop, I can also add a couple of pointers.
From a command message perspective, it's safe to just take a route and not over think it to much. The framework quite easily allows you to adjust the command structure later on. In Axon Framework trainings it is typically suggested to let a command message take the form of a specific action you're performing. So 'assigning a person to a step would typically be a AssignPersonToStepCommand, as that is the exact action you'd like the system to perform.
From events it's typically a bit nastier to decide later on that you want fine grained or generic events. This follows from doing Event Sourcing. Since the events are your source of truth, you'll thus be required to deal with all forms of events you've got in your system.
Due to this I'd argue that the weight of your decision should lie with how fine grained your events become. To loop back to your question: in the example you give, I'd say option 3 would fit best.
Scenario: (sort of Call center) (1) Customer Requests technician. (2) Request goes into queue for technicians to see. (2b) Customer gets confirmation email about submitting data (3) Technicians Process request (3b) everyone gets email (4) Request is completed (5) Technician submits data for completed request (6) Closed Request.
So two actors on the left. Not everything has to connect right? So for customer getting emails and submitting data is drawn.
For Technician actor they have processing interaction and submitting data and getting email.
I am reading about UML here: http://www.soberit.hut.fi/T-76.115/01-02/palautukset/groups/Fireball/t2/docs/UseCaseMethod.html
Was wondering if there should be an actor on the right side of the diagram representing the database? Am I missing anything? How do you know you are completed with a use-case diagram?
Actors are not included in the system, they are extern to the system. Usually, the DB is in the system and it is not an actor.
For example, in your case, a secondary actor could be google map if the technician has to know how to go the customer and, for that he has to see a map whith the travel. In this case, during a use case, google map is reached to get the map.
The only way I know to be sure that UCs are completed is to review them and/or to get a list of customers needs and to trace customers needs with UCs.
Hope this help.
More :
The remark of #Kilian about function is a real good one. Usually when we start we thought use case as "workflow to achieve a feature" or as the set of all user interface menus and this is not that.
So #Waren, I could suggest:
First try to define the system with a title and a paragph deifning the main mission of the system. System is not only the code you are going to write but all what will deployed for it (machine, virtual machine, db, bays, swicht, procedures, DDL, configuration files and so on)
Then define the needs, high level needs that the system must fulfilled (iso term is shall see enter link description here )
Then define the actors/stackeholder and the inheritance hierarchy to figure the needed roles and rights. Do not forget all operational needs (monitoring, backup/restore, DRS procedure, reports, deployment and so on)
Then define your use cases thinking features or single added values and check the whole coherency. A good point about UC is to describe "error/exception" scenarios.
Then an interesting point could be to define the mode of system : installation, tests before production live, production, update/patch, maintenance, system stop and removing. Like that you will be sure to cover the whole system lifecycle.
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.