Does the direction of a dependency connector matter in UML? - uml

I have come across several examples of dependencies e.g. include, extend however it is utterly confusing. One example dictates that include should be in the direction of;
user profile --> login
Whilst extends should be in the direction of;
validate credit card <-- print receipt.
Whereas required should in the direction of; For the life of me I don't get why this can't be an include
place order --> create account
Also does it matter how these are constructed i.e.
user profile --> login (include)
**vs**
validate credit card (extend)
^
|
|
|
print receipt

I am not sure I fully understand every part of your questions, but here we go:
An include goes from the including to the included. It denotes a mandatory sub part of the use case :
including -----------> included
<<include>>
Extend is the same than include, but the sub part is not mandatory. And unfortunately, the arrow is the other way around. Which seems to puzzle you a lot.
including <----------- optionnally included
<<extend>>
When you speak about required, I suppose it is an anonymous dashed arrow? In fact, such a dependency can be written for anything, use case or not. It is not that usual for use cases, but it could mean that a use case has another as a prerequisite. Difference with include is that it is not a sub part. In this case, it is drawn this way.
requiring -----------> required
In your example, it seems that to place an order, you must have created an account (logical indeed). But account creation is not a sub part of order placing, so it is not an include.
As for your last question, are you talking about vertical/horizontal? If so, it does not matter in UML. In fact, there is no rule about positioning, the only rule is to remain clear.

Related

Correct use of option in sequence diagram

I am trying to use the option condition to show that by pressing [edit, view & delete] UI Buttons, the admin can execute admin privileges. I am not sure if this is the correct way of implementing it. Currently, my thought process is that, if a button is pressed, the button being pressed becomes the opt fragment condition and then I show what happens if it's pressed within the optional fragment. I have nested an alt fragment within the opt fragment to handle errors that can occur. From what I have read and seen, I feel this is a suitable implementation, but any feedback to improve and make this diagram clearer is more than welcome. Thanks in advance
The question is, what do you mean with [click edit user]? As modeled it is a flag, that determins what option is happening if it is set. Now the first message in this fragment comes from the Admin. That means it is a flag in his or her head. Do you really want to model the brain here?
I rather think, what you want to model is, that there are two possible sequences, either the admin will send the edit user message or the delete user message. Depending on what he or she does, different things will happen next. This can be expressed by an alternative fragment without guards. Guards are optional and are only misleading when you are dealing with human actors, whose actions are often unpredictable.
Maybe you omitted a select option message (that's perfectly legal), whose result could be the flag. But then I don't understand, why the admin will send edit user, after she has already selected an option.
In your nested alternative fragment (shown overlapping in your diagram, but I assume that is just a rendering problem), you have the guard [user found]. This would probably be a local flag of the verify username operation. While it is very much possible, that such a flag exists, it is unnecessary to show it here. The two fragments are distinguishable by their respective first messages username valid and username invalid. So I recommend to omit the guard.
As a sidenote: The operator for the alternative fragment is abreviated alt

UML use case diagram check user rights

I'm currently writing an use case diagram for a module project for work. Basically, the project has one actor (the user, which is an employee). An example of one use case without anything special would be Add slide to slideshow. However, the slideshow has an website ID. So in order to be able to add a slide to the slideshow, the user has to have rights to that website.
I don't quite remember how I should add that to my diagram. I thought of this first:
But I'm not sure if this is done correctly. If not, how would I add the check that in order to Add item, your rights have to be checked first?
No, that's not correct. Authorization is no use case since it adds no value to what the actor is doing. It's a simple constraint and can be attached to either the actor ({must logged on for Add Item}) the UC ({User must be logged on}) or the association ({login required}).

Event Storming | Command | Validation | Rules | Make it visible

I'm practicing event-storming, with sticky notes and stuffs.
But one thing is missing: command validation (rules to be satisfied for a command to be accepted / succeed).
How to make it visible in the whiteboard? (not just as comments sprinkled here and there). Event-storming only mentions "events" (yellow), "command" (blue), "aggregate" (pale yellow), etc. I don't see "command validation" as first-class citizen.
Any thoughts?
I would consider command validation as policies in event storming. Those are business rules that must be satisfied for a command to be accepted.
They will go on pink "policy" sticky note - https://eventnotes.io/pdf/cheatsheet-big-picture-exploration.pdf
I consider policies as:
Control how the action plays out
Business rules
Decisions
When an event occurs, you apply policy and decide what the next action is
Reactive logic
External decision
Time based
Trigger based
Reacts on events
Triggers commands
Often at domain boundary
I had this same trouble and worked through it like this....
First understand there are different types of validation. What is the type of validation you want to do?
Do you want to validate a model to ensure the order address is correctly formatted? This would only extend to "schematic" validation and could be done synchronously as part of your command, and would be what I would call Command Validation. I would make a note somewhere with the language as this will be taken through to build the contract.
Do you want to validate that "if there isn't enough stock to complete the order the order should fail"? It is not the commands responsibility to validate business logic, it is the aggregate; and I would call this Domain Validation. I use negative events to indicate some form of validation has taken place in the aggregate.
I hope this helps

How to implement 'if' in Gherkin

I am trying to convert Selenium test to Gherkin. Is there way to implement if statements in Gherkin?
Example : assume the code is written in the below format. I am just writing description as below. Please understand the part after double slash is the actual Selenium code:
// launch the application
// login to application
// navigate to page
String str;
if(str== "XYZ")
{
// verify title
}
//verify text field 1
//verify test field 2
//verify select box
For this I am trying to write code in Gherkin as follows
Given user launches the application
When user login with valid credentials
and navigate to required page
When String str is "XYZ"
Then verify title
And verify text field 1
And verify test field 2
And verify select box
but this code is incorrect because if the str is not equal to "XYZ" we want that title should not be verified but other verification like text field1,2 and select box should be verified.
You don't implement if in Gherkin.
Gherkin is about communication and those you want to communicate with, non coders, don't know what an if statement is. They don't care either.
The solution? Two scenarios to cover both cases.
Ideally, this level of detail would not be in your Gherkin scenario. The best approach is describe business use cases, not low level details. This is what Gherkin is designed for: communicating with non-technical stakeholders so that you can work out if you are building the right thing in the first place. Here is what I would write:
Given the user is logged in
And the user is on the required page
When they enter data that requires the optional fields to be validated
And they enter invalid data in the optional fields
Then the form shows an error on the optional fields
The low level details don't matter (that the string is specifically "XYZ" or that it is the title field is not important), so these should be hidden in the step definition and/or unit tests.
In order to continue to check the other fields, you can just add another step after this:
When they enter invalid data in all of the other fields
Then each other field has an error message attached to it.
Again, there is no need to specify the actual fields, or separate them into their own steps. The idea is to express the high level business value of the scenario, i.e. that the form is validated when it should be.
The advantage to keeping things high level is that when the form changes (as it eventually probably will), then this scenario can remain untouched. Which is correct as the business case is the same: it should validate when it's supposed to. All the changes will be in the step definitions. This means that there is no reason to have another discussion with your stakeholders about whether your scenarios are still testing the right thing.
You can write the scenario, somewhat like this:
Given the user launches the application
When user login with valid credentials
And navigates to required page
Then he should see the page datails
Inside the Then step you manage all the logic.
Then(/^he should see the page details$/) do
if condition
...
else
...
end
end
Gherkin is not a programming language to use if or else conditions. It is a part of BDD framework, that is implemented, to make the stakeholders and other non technical resources understand what the test process is about. Hence, it is always recommended, you keep the gherkin as simple and as generic as possible.
Strictly speaking you should create an alternative statement along the lines of:
Given user launches the application
When user login with valid credentials
and navigate to required page
When String str is NOT "XYZ"

UML Activity Diagram for android project

I have created the below diagram and I wanted to know if the diagram that I have done is correct.
The below diagram is based on an android application. When the application loads the user is given 3 button to select add, update and help. On click on add button the user is given an option to add a new user or add a new item. When he select either of the options he enters the required data once the data is entered the system check if all the values are entered correctly and then finally saved. The same process is applied for update.
Your diagram misses an entry point. Though it's rather obvious that the top action is the start, only the entry point is the one indicating the beginning.
You can omit most of the diamonds and directly transfer via a guard from actions. So your conditions should be guards and written as [Yes] or [No]. The top most action (and quite some others) is(/are) indeed what should be written inside (or aside) the diamond below.
An excerpt for an update could look like this:
Finally Values added does not look like an action but rather as state. It should be omitted. Alternatively use differently named end flows.
So far for the formal points. But as #eyp said: it's a good one and one can understand what you tried to express. The above is just for the picky teachers.
It's a good one but it lacks some detail in the diamonds. You should write besides the diamon the question before choosing the next setp to do.
For example in the diamond after Check update value you may write is valid? or another question that clarifies more the business logic.

Resources