Use Case Diagram question

[AZeitler]

Hi,

now i did my first use case diagramm for a usermanagement tool with the following features:

An user may login.
An user may logoff.
An user may change his password.
The Admin may add an user.
The Admin may delete an user.
The Admin may modify an user.
The Admin may lock an user's account
The Admin is an user with special rights, which may not be deleted.
The system logs an user off after a time of being inactive.

Now i wanted to know, if my diagramm shown below, is correct or not.



regards,

Alex

[Javier]

AZeitler,

1. A generic recommendation is to create packages for semantically-related use cases.  For example, session-related use cases (Log In, Log Out) User Maintenance (add/delete/modify/lock account/modify password).  This way it'll be eaiser to read the diagram.

2. Another recommendation is to use verb-noun approach for the use case names.  This would change Login to Log In, Logout to Log Out and Load UserData to Load User Data, Modify UserPassword to Modify User Password, etc.--actually, login and logout, logon and logoff, are nouns, but people mistakenly uses them as verbs ;-)

3. Administrator IS-A User, therefore, it should be a generalization of user, not backwards.  This stems from the fact that most users are not administrators, while all administrators are users.  This would also eliminate the Normal User actor.

4. Given the recommendation above, Delete User could have an extension point when the user is Admin, not when it is not.

5. I do not see how the Login use case includes Save UserData

6. I do not see the reason for existence for Modify UserPassword and Modify UserName.  It seems to me they do not contribute to the model and should be part of Modify User.

Regards,

Javier

[AZeitler]

Hi Javier,

1. A generic recommendation is to create packages for semantically-related use cases.  For example, session-related use cases (Log In, Log Out) User Maintenance (add/delete/modify/lock account/modify password).  This way it'll be eaiser to read the diagram.

uhm... maybe i should read some more chapters in my uml book  

2. Another recommendation is to use verb-noun approach for the use case names.  This would change Login to Log In, Logout to Log Out and Load UserData to Load User Data, Modify UserPassword to Modify User Password, etc.--actually, login and logout, logon and logoff, are nouns, but people mistakenly uses them as verbs ;-)

hmmm.... i read it, but i did it not.

3. Administrator IS-A User, therefore, it should be a generalization of user, not backwards.  This stems from the fact that most users are not administrators, while all administrators are users.  This would also eliminate the Normal User actor.

i did another use case model and uploaded it to
http://www.aspintranet.de/uml/index.htm
(please click on use case view / UserManagement)

4. Given the recommendation above, Delete User could have an extension point when the user is Admin, not when it is not.

i hope, i did the modification well.

5. I do not see how the Login use case includes Save UserData

i wanted to show, that if a user/admin is logged in, he/she may not be able to modify data. Or do you mean, that Save User Data could never be reached, before being logged in and have data loaded?

6. I do not see the reason for existence for Modify UserPassword and Modify UserName.  It seems to me they do not contribute to the model and should be part of Modify User.

i thought, it needs to be shown seperatly depending on the user state (admin/normal user) - seems to be not so  

If the newer version is still not correct, you can also edit the new model at http://www.aspintranet.de/uml/aspintranet.eap

thanks for all your tips on UML  

regards,

Alex

[Javier]

AZeitler,

Almost there.  Invert the generalization between User and Admin.  You can see that most of the use cases will be performed by User but only a few will be performed specifically by Admin.  Admin should "derive" from User.

User
  /\
 ---
  |
  |
  |
Admin


I like the packages.  You can see that they add clarity.  As of the rest, it looks correct to me.  Some people may more demanding, but your model conveys what you mentioned in your original posting.


Regards,

Javier

[AZeitler]

Almost there.  Invert the generalization between User and Admin.  You can see that most of the use cases will be performed by User but only a few will be performed specifically by Admin.  Admin should "derive" from User.

sorry, i misunterstood you AND my book. I fixed it now.

I like the packages.  You can see that they add clarity.  As of the rest, it looks correct to me.  Some people may more demanding, but your model conveys what you mentioned in your original posting.

what might they demand more?

thanks again for your help.

regards,

Alex

[Fintan]

If the newer version is still not correct, you can also edit the new model at http://www.aspintranet.de/uml/aspintranet.eap

Hi Alex,

Here are some of the changes that I would make (does not necessarily mean that there is something wrong with what you have done)
(i) Put arrows on associations from the actors to the use cases.  This implies that the actor starts the use case, but there is no transfer from the use case back to the actor.

(ii)  Although it is correct UML to use <<include>> to link the use cases for "Save user data" and "Load user data".  I do not see that these Use Cases add anything to the diagram.  These use cases will end up as a single line the the Use Case text.  I would tend to leave them out if they do not add anything to the diagram.  If you need to emphasise which use cases save to and load from the database you could List these in a Note on the diagram instead.  If the purpose of the diagram is to practise UML and the correct use of <<include>> relationships, then it is correct to leave them in.  If the purpose is to show this diagram to a customer as the requirements of their system then it may be overkill.

(iii)  As a rule I tend to avoid using the name "User" as an actor if I can - and try to use a more specific name.  Again if this is an exercise, then it is OK.  For a customer's system use a name appropriate to what they do (Accountant, Secretary, etc.)

Hope this is useful,

Fintan

[AZeitler]

(i) Put arrows on associations from the actors to the use cases.  This implies that the actor starts the use case, but there is no transfer from the use case back to the actor.

if the actor gets information back from the use case, then i will need arrows on each side?

(ii)  Although it is correct UML to use <<include>> to link the use cases for "Save user data" and "Load user data".  I do not see that these Use Cases add anything to the diagram.  These use cases will end up as a single line the the Use Case text.  I would tend to leave them out if they do not add anything to the diagram.  If you need to emphasise which use cases save to and load from the database you could List these in a Note on the diagram instead.  If the purpose of the diagram is to practise UML and the correct use of <<include>> relationships, then it is correct to leave them in.  If the purpose is to show this diagram to a customer as the requirements of their system then it may be overkill.

The use case diagramm is for our own use. The application being developed is for our own use.

(iii)  As a rule I tend to avoid using the name "User" as an actor if I can - and try to use a more specific name.  Again if this is an exercise, then it is OK.  For a customer's system use a name appropriate to what they do (Accountant, Secretary, etc.)

the user is not bound to any department. it may only be attached to one or more user groups, managed through the GroupMaintenance, which i added in the meantime.

Hope this is useful,

of course, thank you.

regards

Alex

[Fintan]

if the actor gets information back from the use case, then i will need arrows on each side?

If the use case displays information on a computer screen then I would not consider this as the actor physically receiving information back from the system, and would leave the arrow pointing from the actor to the use case.

If however the system sends an email to an actor this I would consider the actor receiving information back from the use case.

Rather than draw arrow heads on each side of the association line - the standard is that for bi-directional communication a line with NO arrow heads is used.  This is what your diagram suggests.

The use case diagramm is for our own use. The application being developed is for our own use.

Whatever works for you is fine, as long as whoever is reading the diagram can understand it.  If an application you are developing gets more complicated, all the additional <<include>> lines may end up confusing the diagram, making it harder to read.

Regards,

Fintan

[mbc]

I have a little comment for the diagrams too.
"Load user data" and "Save user data" is (as far as I can tell) not actually something that the user does but rather the internal workings of the program. It seems to me that you are describing implementation in your use case diagram, which should be avoided.
Also, I don't see any text at all, no scenarios, in the model that you linked to. The use case diagram itself is not really important. It just serves to give an overview of your use cases. The really useful part of a use case is in its textual description or scenarios. Try not to get lost in include and extend relationships. Most of the time it is better to just describe it in the use case text.

Mikkel

[AZeitler]

Thanks for your hints,

now i also added a diagramm for GroupMaintenance to the
Use Case Model:


is this correct? (apart from missing text/scenarios)

regards

Alex