Imagine you have one use case "register contract" and one extension "attach document". The two actors are not related at all (I mean, one of them do not extend the other one); both can register a contract but only the "client" can also attach documents.
How do you represent that? Is my example right or should I trace a line from the client to the "register contract" use case too?
In this case I would use two diagrams, one per actor
Create two different use cases, one for the employee ("register contract") and one for the client, and in the client ("extended register contact" or something like that). If you want to show that both use cases are related you can add use inheritance between them.
Another option is to add a parent to both client and employee inherit from a common parent which activates the use case, and add a comment to the <<extends>> link stating that the extension can only be called if the caller is a client (see the example shown here)
Related
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}).
In one of step definitions I have created a function say “someFunction” that takes a DataTable, which has been defined in my feature file Feature1.
Feature1.feature
Given: User enters the following data
Varibale1|Variable2|Variable3
Value1|Value2|Value3
StpeDef.java
#Given(“^User enters the following data$”)
public void someFunction(DataTable input){
}
Now in another feature file “Feature2.feature”, one of my scenario needs to use same step i.e. call someFunction. I know I can use the same step definition but does that mean that I would have to redefine same DataTable input in Feature2 file.
If not, how would I do it?
Please note that I understand the Backgound keyword and its use, but if I say I need to keep these scenarios in different feature files, how should this be done?
You'll have to duplicate the common background. Since duplication is unwanted, you should consider giving a name/title to the resulting state that is represented by that common background and create a single given step that can be re-used. Something like "Given: the user has entered valid contact data" or "Given: the shopping cart has 3 items" (where any 3 will do).
When creating a use case diagram, I want to show that a user can submit a form or empty all fields (or cancel the action)
Since both submitting the form (let's call it add user) and empty fields are related, how can I show this in a use-case diagram?
I was thinking of extending add user with empty fields, but as the extended use-case depends on the base use-case, is it correct to show something like this?
Don't make atomic actions use cases. The use case has to provide some business value.
What you're describing is a flow of a use case. Use case diagram documents list of use cases and relationship between them (and to actors), but not flows of the use cases.
To show show the action flow inside a UC you should create activity diagram. It'll show a possibility of clearing or submitting the form.
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.
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.