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.
Related
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
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}).
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've created my own solution with a custom entity of type activity. I'd like to show a message whenever a new instance of it is created using an existing contact but not allow the user to create one, if only attempting to do that without going via contact.
Basically, my aim is that it won't be impossible to just create that activity (the form will be hidden directly at any attempt except for one way only). The user will have to go to contacts (or leads etc.) and in there add and create an instance of the custom activity entity. That way, I can assure that the field "regarding" will be filled out already.
I'm guessing that I need to detect somehow that the opening of the form is a creation attempt. How can I do that?
Also, as it is now, the user can't create a contact-less activity of the custom type because it doesn't appear on the menu with other activities. I must have disabled it somehow but I have no idea how. Anybody who has one?
You could do this a bunch of ways but the easiest would probably be to:
Make the regarding field read only.
Make the regarding field mandatory.
That way if a user opens a create new form they wont be able to set the regarding and because its mandatory they wont be able to save the record. When they open via an existing contact the regarding field will be mapped automatically. That said in this case just making it mandatory my be enough.
(As a side JavaScript can be used to identify the current form state, but I'm not sure how useful that is here).
In terms of where custom activities appear, by default mine show in a number of locations, for example:
CRM > Workplace > Activities > Ribbon > Other Activities > XXX.
CRM > Workplace > Activities > View Selector > XXX.
They don't show under the left hand navigation of the workplace because they are grouped under 'Activities'. I'm pretty sure these are all the default settings.
You can exercise greater control by editing the sitemap, where you can put pretty much anything, anywhere.
In addition to Mr Wood, I'd like to show you some code. It works as supposed to but I'm not sure if it's optimal.
var foo = function () {
var whatIsGoingOn = Xrm.Page.ui.getFormType();
if (whatIsGoingOn === 1)
alert("Let there be an entity!");
else
alert("Not a creation...");
}
The other states' (deletion, update etc.) numeric values are listed here.
Answering the second part of your question:
When you create a custom activity you can choose whether to have it appear in 'normal' Activity menus or not by checking the box at the top right of the entity form. This is a once-only choice as far as I know and can't be changed later.
For your setup, I would suggest NOT checking this box, so it does not appear in the activity menus to avoid users even being tempted to do it that way.
Instead, add an explicit relationship to the activity N:1 to Contact, and another N:1 to Lead. Use this relationship to add your activity to the left navigation of Contact and Lead forms, or add a grid for them (depends on how you want to use this and if you need to filter the view to something other than the default "Associated View").
When a user navigates to this section they will see if any previous activities of this type exist, and be able to add a new one. BUT this means that the child record is a child via this relationship, not using "regarding", so use a script on the form for the activity so that if Contact is filled in, it is copied to Regarding, and if Lead is filled in then that is copied. If neither, then use an alert or other means to warn the use that something is wrong (see comment earlier). If you want Regarding to be read-only but filled in by script, you will need to make sure to use the force the value to be saved:
Xrm.Page.getAttribute("regardingobjectid").setSubmitMode("always");
You must have the lookups for Contact and Lead on the form to be able to use them in your scripts, but you can make them not "visible by default" so they are there but not seen by the user (and taking up no space).
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)