I am making a use-case for Course Registration where students have to choose their programme, then a list of courses for that programme will be shown for student to choose from. After student has chosen their courses, they register for their class schedule (timetable).
I made this use-case diagram and wanted to know if this is a correct method to do so:
The Register new account, Generate report & Confirmation E-letter is asked by the question too.
Thank you for all the help
Basically your UCs look ok. That is your extend/include are connected the right way. Also the naming is fine.
However, I would not overuse the latter relations. The reason is simply that people tend to start functional analysis instead of synthesizing use cases. A use case is about added value a system brings to its actors. And each added value should be at the front, not somewhere hidden behind include/extend.
As always I recommend to read Bittner/Spence about use cases.
Related
I'm trying to define use cases for my project. The problem is I'm not sure how to effectively define a use case, and it looks very messy.
For example like my use case below. I feel like 'View profile', 'View Club' 'View Workshop' is necessary to include because of 'common sense' for user to click on certain profile to view it. So do I really need to define such use cases?
Car Club Use Case
Yes, synthesizing use cases is difficult. And often people try to depict functional parts using lots of include/extend to show the system under consideration. But actually use cases are not about functionality. They are about added value. So if you sit down a moment and think which of those bubbles really represent added value, you will find that Request repair service, Make appointment and Manage club are real candidates while most of the others are just technical paraphernalia. Manage <x> is a bit of a borderline. I'd eventually use CRUD here, that's 4 use cases, since they are used in different contexts and often different actors. When you synthesize use cases just ask yourself: does it add value. Only if the answer is yes, add this as use case. Else you have some technical sequence of actions or even simpler a constraint (like for Login).
You need to define all the cases necessary to achieve your goal. Generally speaking if there is something important in 'View Workshop' to have it on paper or to pass it to someone - you have to write it.
Ihsan Ramli, while your problem is "I'm not sure how to effectively do %something%" and assuming that you can't give the task to someone else - why not to learn more about it? You can start from couple of widely recommended books, for example Writing Effective Use Cases by Alistair Cockburn.
Sentences like "because... for user to click on certain profile to view it" immediately light a red bulb since use cases represent behaviour requirements and are detached from implementation and design (but can and should refer to them when necessary).
Some comments about your diagram:
'Create club' (along with 'Delete club', 'Change club name') would look better as a use case one goal level lower and triggered from summary scenario 'Manage club'.
'Manage workshop' is probably missing for its owner.
Name 'Update item' tells nothing to reader.
'Join club' would probably look more reasonably triggered from 'View club'.
I don't believe that appointments for workshop and repair have a lot in common to be the same scenario.
Craig Larman states that creating an Actor[/User]-Goal list in form of some table/grid is a good technique for finding Use Cases during Requirements Analysis. (Applying UML and Patterns - P. 69 ff)
Some simple two-column table should be enough to provide a good Overview for this example; imagine following Actor-Goal List:
Actor Goal
Admin Create User
" Read User
" .. (full CRUD)
" CRUD Entry
" Assign Entry (to User)
" ..
User Create Entry
" .. (full CRUD)
" CRUD himself?
" ..
Admin can do what User can + more like managing the Users of the System under Development or assigning Entries to them.
Admin and User clearly are sharing some Goals(Can we use the term Use Case yet?).
Im not really sure where to go from here in terms of refining this Actor-Goal list.
My brain tells me that i can spare time and effort by reusing/abstraction here, so I will most likely end up with one common superclass implementing the CRUD Entry behaviour, where Admin is extending the functionality by the Manage Goals(CRUD User, assign, etc.).
But I know that this is rather a question of Design than Analysis.
I also know that I can write the Use Case for this in isolation: I dont have to state who exactly uses it, I just need to know that it's some entity which is adhering to the given contract[/interface].
When is the time to start thinking about abstraction?
Am I overcomplicating things by doing so right now?
Should We leave the Actor-Goal list like above and check it off as a "complete" Artifact?
Since the classical purpose of an Actor-Goal list is to provide some quick overview for our next Artifact - the Use Case Diagram - could we begin the transition right here?:
The Use Case Diagram makes the whole reusing part much more visible (at least to me). Would it be advisable to adopt the redundancy right now and take care of it during later stages (e.g. design)?
Appreciate your input!
EDIT: Also I'm not quite sure about the User CRUDing himself.. But lets keep things simple and stick to the main question.
It's an excellent idea to identify the candidate use cases in an actor-goal list, as you have described.
The issues when identifying use cases
In the real life, you'll quickly encounter consistency issues when elaborating the list during requirement elicitation :
some interviewed users/business experts will describe very detailed step by step goals (corresponding to system functions), whereas other will describe rather high level goals user goals. So you'll need a third column to identify the goal level of each use case.
terminology and user goals will not always be expressed in an homogeneous way. So cross checking, and renaming of use cases might be required. For example, I had a system where:
an admin claimed to manage authorizations, and a business user claimed to manage authorization. Was it the same use case ? No: it appeared that the first maintained assignment of authorizations in the system and the second was empowered to decide on authorizations assignment and request them from the admin.
a purchaser explained that for a purchase order someone has to register a good receipt before the invoice is paid. The warehouse clerk explained that at warehouse they manage stock movement. Latter, though, it appeared, that those movements where good receipts, good issues, and stock transfers.
So a fourth column for comments about main variants could help to keep the overview, and to spot hidden sharing potential.
There is generally a great deal of cross checking and harmonization to be done before sharing/reusing use cases. Reusing too quickly might end up loosing more time than expected.
The use case diagramming
I will now be very provocative: once you have the nice and consistent table with all the actors and use cases, what will be the benefit that you expect from a use case diagram ?
It is generally recommended not to abuse use case diagrams for functional decomposition (see also here). So the use case diagram will add little more to what you already have in the list.
In addition, <<Include>> , <<Extend>> and generalization relations should be used scarcely because they tend to quickly make the diagram difficult to understand.
Finally, does abstraction and reuse really happen at the level of the use case ? Is this relevant to the actors outside of the system ? If not, it's more about design and implementation details. So I'd suggest to consider these more in the class model that you will create (or derive) to implement the use cases.
Suppose we have a simple on-line store. Things that the user would want to achieve with the store would be:
Register (to create an account)
Browse items
Add items to basket
Checkout and pay
View account information
Edit account information
etc
However, there would be functionality that the user could initiate but wouldn't be their main goal of using the system:
Login
Logout
Select 'electronics' department
Select 'vehicles' department
Enter delivery details
etc
I would argue that things like login and logout shouldn't be in the UML use case diagram. The reason being that a user would not want to go to the on-line store just to login; they would always have another aim which would be to view / edit account information or browse and buy stuff.
Likewise, the two select 'statements' are part of the browse items use case. I wouldn't use generalisation because there could be many departments.
Finally, the enter delivery details is part of the 'checkout' or 'edit account information' use case. I would normally lump this in with the 'edit account information' use case otherwise you may as well have use cases for 'edit name', 'edit email' etc.
My main concern is if you have a very complex use case diagram it defeats the purpose of having one as it won't be easy to read.
So, my question is as follows. Is my thinking behind this correct? Is it best to only model 'real' goals in the use case diagrams or everything that the actors can initiate?
Does a UML use can show everything the actor can do (functionality) or
everything the actor wants to do (goals)?
It can be either - the UML spec isn't prescriptive on that front. Alistair Cockburn created a categorisation for Use Cases that indicates what level they focus on.
Having said that:
My main concern is if you have a very complex use case diagram it
defeats the purpose of having one as it won't be easy to read.
That's a very real risk. Personally I find I get most from UCs by focusing on the users and their goals. What value are they looking to get from the system?
Keeping it at that level prevents a "can't see the wood for the trees" situation - and also stops UCs becoming a complete, functional decomposition design.
hth.
It is not wrong to exclude some use cases from your diagram, and indeed it might be a good idea. For instance, if you are going to show your diagram to the business department, you can draw an UML model that describes the operational use cases. If you are going to hand down your diagram to the programmers, you would want to give them a complete description of what they have to implement. These are just models of your system.
When one draws a use case diagram, usually one also writes the behavior of each use case (as free-text description, pseudocode, or by using interaction diagrams).
The UML specification says that:
A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system.
Login and Logout are observable to the user. While the user will not visit your site with the only goal of logging in, such use case certainly has some execution flow that you also want to describe. If you don't allow users to initiate a login by themselves, there will be use cases that include the functionality of login. A user may have also interest on logging out before leaving the site, so that no session data will remain stored in his computer.
Select 'electronics' department, Select 'vehicles' department... Why not just Select department (I suppose that they are not too different).
I would draw this and other use cases, as long as they are relevant to the model.
suppose you have to do a Use Case Diagram for this simple problem (that is part of a much bigger exercise i am doing):
a registered user (of a web application) can search for tourist attractions in two ways: by category (for example: museums, parks, theaters, archaeological sites) or by location (city, county).
How should i model this UCD?
The most simple way would be: the actor (registered user), two use cases (search tourist attraction by category and search by location), the secondary actor (the server of the web application, which would process the query and send back the results).
My concern is that in this way the four categories and the two type of locations would not be present in the use case.
I was thinking of using the "extend" relationship. For example, i would add a use case named "Search parks" that extends the use case "Search by category". The extension point would be the event that the user chooses to search for parks.
Or i could use an inheritance relationship between the "Search by category" and "Search parks"...mmmm...i am a little confused...
How would you model this little problem using USD??
Thank you,
Luca
First of all you have to realize, that Use Case Diagrams aren't substitute for actual (written) Use Cases. Use Case descriptions contain many important details, which are omitted in Use Case diagrams. Use Case diagrams are good for depicting hierarchies of actors, associated use cases and relationships between use cases, but nothing more.
Another important thing is to realize what an use case actually is. Good way to think about them is to find a goal of an actor, which he/she wants to achieve with help from the system. Achieving this goal should give the actor some business value. My point is, that from what you described, registered user might want to search for a sightseeing and/or buy entry tickets. So this is his goal and this should be a an use case, don't confuse use cases with functionality/features like different ways of searching etc.
In your first suggestion you have two use cases, which differ only in data (e.g. it might be just different choice from a combo box in a form). Such differences, if they don't influence the way the system and actors interact, are described separately from the use cases in a data glossary, which you reference in your use case. This way you avoid many unnecessary details in use case descriptions. If on the other hand, the steps in the description change (e.g. when registečred user chooses location system gives him/her an option to select another registered user as a friend and pre-selects favourite locations of both or something like that...), you can capture this by using alternatives/extensions.
You mention the system you are developing as the secondary actor. Don't forget, the system under development is an implicit actor and is not shown diagrams as a separate actor. Use boundary box (rectangle encompassing use cases excluding actors) to depict scope of your system.
Finally to your concern. These are all just details about the data, which are not part of an use case. You can capture those details in text (by namicng all categories etc.) using the data glossary as mentioned above. If you think the structure and relations between data is important and needs to be captured using diagrams, you can use class diagrams to create data/domain models.
Last note about use case relationships - don't use them if you don't have to. They are often hard to understand and vaguely defined. Never ever use them to decompose the functionality, that is up to design, not analysis with use cases.
I hate depicting Search in a use case. There are simply too many variables. It's like trying to write a use case for using a browser.
Search is a good candidate for early prototyping supplemented with business rules.
I am modelling a system and i have the following are some of my use cases{appoint teacher(adimin),record grades(teacher), manage students(admin),record attendance(teacher), manage cocurricular(admin)}
I have some problems with coming up with use case steps and use case scenarios.
i have already drawn my conceptual class diagram.
does any one have an idea on how to go about that?
thanks in advance
You may find an article such as this useful.
My way of thinking. You have general description of the use cases, so you know what the system you're building is supposed to do. But those use cases no doubt have lots of wrinkles and special cases. [In passing "Manage Students" seems at a rather different granularity from "Appoint Teacher" susepect you need "Enrol Student", "Suspend Student", "Graduate Student" or some such.]
So your next step is to capture more of the requirements of the system by giving more detail of the use cases. You express that in terms of actions by people and systems. Do you have a system context diagram or some such? This would show everything your system interacts with. You then express your scenarios as a sequence of actions by actors, your system and other systems.
The Teacher logs on
TheSystem presents a menu
The Teacher selects "record grade"
The System presents a list of classes taught by the teacher
The Teacher selects class
etc.
The wrinkles come from considering the variations that might occur. Any special actions for failing grades? Restrictions on grading for certain types of students? So you create additional scenarios for such "interesting" cases.
In my understanding, at this stage specfic classes and class diagrams are not needed. Later you can consider one step such as "The system presents a list of classes taugh by the teacher" and consider how the system implements that using your class diagram.
Remember the objective here: get the complete picture of the requirements you need to satisfy.
Additionally, although you may not need to do this in class (sounds like a class you're taking), another useful step in requirements gathering is identifying the misuse cases. That is, you want to figure out what bad things could happen in your system. For example, a misuse case could be someone hacking into the system, and then you could write out the steps you would take to correct such a misuse case. Just something to think about.