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.
Related
I have heard conflicting things about this and just wanted to clarify.
I have always thought that when constructing a Use Case Diagram, I only include the activities that will be carried out by the system. For example, if it were a bank atm, "User depositing money" would be included, as it involved the user interacting with the atm. However, "User is paid cash in hand from job" is not included in the diagram, even though it may bear relevance to a scenario or situation.
Thanks all
The fact that the user is paid in cash is in any way related to the information system which is a system involving people. The payment transaction has to be integrated with your project, at least on a conceptual point of view. In other words it should have a relationship of an unspecified kind with a use case, depending on the context.
I recognize my answer is quite messy: if you're already getting bored, jump directly to the solution section...
The use cases diagram
According to The UML User Guide:
A use case is a description of sequences of actions that a system performs that yield observable results to a particular actor.
The point is about modeling what is related to the system: your main problem is to consider the scope of your project.
Depending on the scope you identify, the use case you should consider would be something like Cash withdrawal: consider the observable results from the point of view of the actor. This part is highly subjective whether you consider the operation part of the system or not. I personally disagree with the other answers here.
A few words about being paid cash in hand. On a pure development process point of view, would it be normal to have a sharp idea how a user is being paid while modeling ? Still the scope question here: perhaps is it a strong constraint in your context.
Even when reverse-engineering, a use case is user-oriented, it has nothing to do with how things are done, but what is done: I think nothing to do with especially automating things, even when talking about a system. There is a subtle idea here: I consider an information system, a system involving people in the first place, not a completely automated system. Of course, purely automated systems can be modeled with UML, but most systems involve users.
The relationship between the use case itself and the information how the payment is done has not to be represented on the diagram figure. However, even if this is not in the use cases spirit, the way it is done could be written in a note if it is an important constraint the diagram reader should be informed of.
The solution
In my point of view, the right place to put that information in the use cases is not the diagram figure itself but in a use case description. Martin Fowler gives a few hints about this in UML distilled. You have a simple use case description example here. This is related to the way you are using UML and the way you wish to describe use cases (I personally share Martin Fowler's perception).
Perhaps you would prefer to represent this with a formalism specific to your modeling software, but I think this would not be a traditional way of using UML (appropriate for an Executable UML, not appropriate with blueprint or sketch).
It is not included because the "User is paid cash in hand from job" is outside the scope of a project and would not be needed for what you are trying to create.
Most often use cases are used at the functional/logical level of your model (MDA's PIM level). This means that it only describes those parts of the process that will be automated.
So unless your system has a feature that somehow records the fact that the user is paid in cash, that isn't part of the system under construction.
At the business/conceptual (MDA's CIM level) level however you model the whole processes, regardless of automation. So at this level it "User is paid in cash from job" would certainly be at its place.
How do I determine what should I add to my use case diagrams? 1 for each button/form? Should things like sort and search be included? Or are they under "list items" for example? Though, a list of items seems understood?
The Use Case diagram is intended to help define the high-level business tasks that are important, not a list of functions of the system. For example, a system for use in customer service might involve a research task of looking up information to help someone on a support call.
Most of the literature describes Use Cases as a starting point for defining what the system needs to accomplish. The temptation has always been to be as complete as possible; adding ever more details to define the use case down to a functional (code-wise) level. While it is useful to have a comprehensive understanding of the requirements, the Use Case diagram is not intended to provide that level of documentation.
One thing that makes the issue worse is the syntax which I've never seen used in a working project. It isn't that the terms aren't useful, it's due to the lack of consensus over when to use either term for a given use case. The UML artifacts expect a process that is more focused on the business language instead of the implementation language - and by that I do not mean a computer language. The tendency by some has been to approach the diagrams with a legalistic bent and worry about things like when to use for related use cases or how to express error-handling as exceptions to a defined list of process tasks.
If you have ever tried to work through the Automated Teller Machine (ATM) example, you'll know what I mean. In the solar system of UML learning, the ATM example is a black hole that will suck you into the details. Avoid using it to understand UML or the Object Oriented Analysis and Design. It has many of the problems, typical of real-world domains, that distract from getting an overall understanding even though it would make for a good advanced study.
Yes, code will eventually be produced from the UML artifacts, but that does not mean they have to be debated like a treaty in the Senate.
The OMG UML spec says:
Use cases are a means for specifying required usages of a system. Typically, they are used to capture the requirements of a system, that is, what a system is supposed to do. The key concepts associated with use cases are actors, use cases, and the subject. The subject is the system under consideration to which the use cases apply. The users and any other systems
that may interact with the subject are represented as actors. Actors always model entities that are outside the system.
The required behavior of the subject is specified by one or more use cases, which are defined according to the needs of actors. Strictly speaking, the term “use case” refers to a use case type. An instance of a use case refers to an occurrence of the
emergent behavior that conforms to the corresponding use case type. Such instances are often described by interaction specifications.
An actor specifies a role played by a user or any other system that interacts with the subject. (The term “role” is used
informally here and does not necessarily imply the technical definition of that term found elsewhere in this specification.)
Now most people would agree that business and user level interactions are the sweet spot, but there is no limitation. Think about the actors/roles being outside of the main system/systems you are focusing on. But in one view a system could be an actor, but in another the implementer of other use cases.
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 have to develop a CRUD application, that will be coded in php.
I have 3 main actors (Users, Administrators and Doctors -- this is for an hypothetical
hospital), each one with different Use Cases already defined.
Although I feel the Use Cases are more than enough to successfuly model the Class Diagram, I am being specifically asked to also include DataFlow Diagrams into the project's documentation.
I've been reading about DataFlow diagrams, and it seems you usually have first of all a Level 0 DataFlow Diagram, to which they call Context Diagram.
Being that this is basically a 3-tier application with 3 different Actors, how should I model the Context Diagram?
Being that a Context Diagram is supposed to just tell us what comes in and what comes out of our System, I can't imagine anything more interesting/descriptive than the following diagram:
Is this supposed to be something like this, or am I totally missing the point? This php page will connect to an Oracle database, but I guess that if the idea is to consider the System as a whole in the Context Diagram, I should "hide" that fact in the above diagram.
Where should I go on from here? I know I should "zoom" the System process to something more detailed. Maybe the next step would be to depict each one of the User Cases in a DataFlow diagram? Do I include repositories of data, already? For example, one for Users, other for Doctors and yet another for Administrators?
Thanks
Are you sure there's nothing else the system interacts with? e.g. diagnostics input, etc.?
If not then your context diag is basically ok - although I'd probably show each entity once and use double headed arrows. I'd agree with your reasoning for the db - it's part of the system, not external to it - so don't show it on the CD.
As for next steps, again you're on the right lines. Try modelling the flow for each Use Case as a DFD. DFDs are very useful for illustrating processing-intensive apps. Difficult to know if that's a good match to your problem or not.
You'll find DFDs are also useful for driving out and validating your Class Diagram. In fact, that's one of their strengths: datastores on the DFD should correlate with the contents of your class diagram (not necessarily one datastore to one class though). So do include datastores as you work through the processes. You'll find it drives out more than just the Actors.
hth.
Some remarks:
You DFD does not tell me much, except that Users, Administrators and Doctors use it, but it gives me no clue what they get from the system (except "Output Data"). IOW the context diagram does not give me the slightest idea, what the system does.
Admittedly, if the system is large, then it can be difficult to describe the dataflows in few words, but just about anything is better than "data".
The fact that the system is a 3tier architecture is irrelevant for the DFD. This is an implementation detail. DFDs are an analysis tool. You describe what you want the system to do, not how this is achieved.
I find it particularly useful to focus on the outgoing flows. While Users, Administrators and Doctors provide input to the system, this is most likely nothing they want to do. It is something they have to do in order to get the desired output.
On a Use Case diagram can you show things that an actor cannot do, for example because they won't have permissions to do it?
Or is it just implied due to the fact that they won't have a line joining them to the particular use case?
If the Use Case you are diagramming is the case where an actor attempts to do something that is not permitted and is then denied, then yes, I would show it.
Otherwise, I would stick to only including things that are actually part of the use case.
No. An Actor would be connected to everything that he can do. If the Actor can't do it, then it's not shown.
This is what alternate paths are for. The basic path (a.k.a. happy path) will show what happens when the correct Actor initiates the Use Case. In the alternate paths you can show what happens if the wrong Actor attempts to initiate it.
You might model Role actors that can do the task. You could then have another use case that has the original actor attempting to acquire the given Role.
IMHO this question and most of the answers give a wrong impression about the way use cases should be used.
Use case was intended as a requirements technique that uses natural language. It is most and quite effective that way.
It can be a thoroughly destructive technique when it is combined with too much UML/modeling. Structured modeling of use case texts for example by modeling main and alternative flows using UML Activity Diagrams is a tried and tested way for example to create Use Cases of Mass Destruction.
A use case diagram can be useful but we should remember the purpose of use case as a technique which is first and foremost to identify the user goals a system should support. Subsequently we can capture more details using natural language in use case texts using main flow, alternative flows etc.
Using diagramming tools we can visualize some simple information:
- For each user goal we can create model element type Use Case.
- Show system boundary using a box for the system with use case elements in it.
- Create a relationship between actor and use case to show the actor has a particular goal against the system.
Keeping an up-to-date list of actors mapped to goals is however of secondary importance. Doing a stakeholder analysis, drawing up lists of actors is a means to identify the users goals. After user goals have been identified it is strictly speaking not longer necessary to keep the lists of actors around.
If we are asking questions about how to put user permissions in a use case model we are most likely trying to capture too much information. We should abstract model elements away so that the model does not try to answer/capture these type of detailed design questions.