Usecase Diagram

Question

I'm new to UML.I have a question.consider we have a user that can change user specification(change user password,Grant Access,...) for Use Case diagram which of these two picture is correct:

1)

2)

if No.1 is correct in what diagram we sould show details?thanks

Answer 1

First case is better, use case should not be used for some functional decompostion, they are just use cases :). If the actions as "change password" can be viewed either as separate use cases or let's say more or less independent parts of other use cases, then you can <<include>> them.

Answer 2

The diagram is just to give you an overview. The heavy-weight of the use case is the text description that goes along with it. There you describe the use case, the involved actors, pre- and postconditions and the actual steps of the use case in a sequence. Take a look at this textual specification and note the section headers. It is a pretty good example of how use cases should be described. Basically you want your descriptions split as in #2, but for an overview "big" picture it may be beneficial to also group them. So that you have e.g. use case "#1 Change User Specification" and then you have "#1a Change User Password", "#1b Grant Access", etc. .

Be cautious with use cases and user stories!

• Use cases are presented in a diagram as you have shown and are described in a rather strict format. They're meant to be a specification of a certain user action and allow you to document and prescribe the feature to a quite detailed level (from a user perspective, but also going into a system perspective sometimes).
• User stories on the other hand come from the agile world and are a much more simplified description of a "feature". It is important to clarify that user stories are not meant as specification! They don't include pre- and post conditions or a detailed basic and alternative flow description! They are meant to be so small to be described with a single sentence.

With user stories the programmer is free/required to solve issues on his own like what to do if there's an error and such. With use cases it's all documented, the error message itself and what should happen.

Answer 3

I tend to say diagram #1 is correct, but this depends on your concrete requirements. Given the sample use cases I'd rather expect something like this:

1. Actor Admin -> Modify User Authorization (matches grant/deny access)
2. Actor Admin -> Change User Password
3. Actor Admin -> Modify User Details (user specification)
4. Actor End User -> Change User Password (variant of #2)
5. Actor End User -> Modify User Details (variant of #3)

For detailing use cases in UML diagrams you have two options, an activity diagram and/or a sequence diagram. Neverthess, I'd be careful going that route, during your project you will have to put a lot of effort into maintaining those diagrams. My experience is that as soon as the first lines of code have been written no one will look at the beautyful diagrams any more. Rule of thumb - formal specification is a function of team complexity. If you have a global team with developers in different timezones it may make sense to put more effort into this kind of specification.

This has worked for me:

1. Create a Use Case overview (either graphical like yours or simply a text document)
2. Document use cases in form of user stories
3. Use activity diagrams for complex processes, maybe spanning more than one use case, e.g. an order process
4. Create a few sequence diagram to document the important technical aspects of your system like authorization, transaction management, end-to-end communication between all the different layers

Edit: The UML offers several types of diagrams to document and model different views on your system. The Use Case Diagram itself is not designed to document detailed, low-level aspects of your system. As per WikiPedia:

Use case diagram: describes the functionality provided by a system in terms of actors, their goals represented as use cases, and any dependencies among those use cases.