I am currently refreshing/altering my knowledge in software development because I will work in this area soon. We have learned a lot about UML diagrams and coding at University, but I have never brought it all together in a real Project. Therefore, I started to create a test web-app in Grails, and I wanted to begin with a requirements analysis and use cases too keep it close to reality.
My web-app should allow users to share recipes, find recipes and review recipes by other users. Every recipe has many ingredients, which are not just strings but rather entities so that calories, fat, protein and carbs can be used to automatically calculate nutrition facts of a certain recipe.
An ingredient can be added to the database by either a consumer or nutrition expert. If it is created by a consumer, it is only a "prospective" ingredient, meaning that it has to be verified by an administrator to become a "proper" ingredient -- otherwise it is marked, e.g. red text color.
This is my current use case diagram:
http://ubuntuone.com/0zDw9kEbj1BwtXjnCtxdwC
My question here is:
As far as I'm concerned, included use cases can be reused, meaning included by other use cases or associated with other actors as well. But is that also possible with extending use cases? Can 'AddProspectiveIngredient' extend 'VerifyIngredient' as well (although it would not make any sense for this system)?
You could have many use cases, extending each other. For extending is a variation. Only that would be excessive. You don't need draw extend connection between A and C, if A-B and B-C are already so connected.
But you can have problems with the tool limitations. VP-UML works with "extend" not so well. Even the usual delete won't work correctly on "extension points"
Yes, you can reference a use case by one or more other use cases (using either one of the include and extend relations) and you can also associate included or extended use cases with your actors.
This discussion is helpful for distinguishing the include and extend relations in a use case diagram.
Related
Imagine that we are building a Library system. Our use cases might be
Borrow book
Look up book
Manage membership
Imagine that we can fulfill these use cases by a librarian person or a machine. We need to realize these use cases.
Should we draw different use case realizations for different flows?
If not, it is very different to borrow a book from a machine and a person. How can we handle it?
Moreover, what if we have updated version of library machines some day? (e.g. one with keyboard and the other is with touch screen) What should we do then? The flow stays the same, however the hardware and the software eventually be different.
What would you use to realize use cases and why?
It might be a basic question, but I failed to find concrete examples on the subject to understand what is right. Thank you all in advance.
There is no single truth or one way you "should" do it. I will give you my approach, based on the Unified Process.
The use case technique is primarily used to describe a dialog between a human user (actor) and an application. It is modeled as an ellipse and further specified as an activity diagram or just a list of steps: 1 The actor does A, 2 The system does B, 3 The actor does C etc. In this approach, the application is regarded as a black box.
A "use case realization" describes how the system performs its steps (white box), e.g. in terms of collaborating components, transparent to the user.
It is possible, but much less common, to have so-called business use cases. In that case, the "system" represents an enterprise or a business unit. In your case, it would be the library. The "actor" represents an external person or organization, e.g. a client or a supplier. In your case, it would be a client. With business use cases, the library is regarded as a black box. The steps are still in format "actor does A; system does B", but here, it is not specified which of the library's actions are performed by humans and which by applications. The system is the organization, interfacing with external actors, regardless of whether this is implemented by employees or by applications.
A "business use case realization" specifies how the system performs its steps (white box) and specifies which parts are done by employees and which parts by machines.
Now, let me answer you questions one by one.
Question 1.
If you have described your use case as a business use case, and it is at such a high level of abstraction that the steps for client-librarian interaction are the same as for client-machine interaction, then you will have one business use case "Borrow book" and two business use case realizations for this business use case.
However, it is more common practice to have only use cases for user-application interaction. If the client interacts with the system in the same way as a librarian would do on behalf of the client, then you will have only one use case "Borrow book", with actor "Person". This actor has two specializations: "Client" and "Librarian". There will be only one use case realization per use case.
Otherwise, you would have one use case "Borrow book online" describing the flow of events when a client interacts directly with the application, connected to actor "Client" and another use case "Borrow book for client" describing the flow of events when a librarian interacts with the application while talking to the client. The latter use case has "Librarian" as its actor. Again, there will be only one use case realization per use case.
You may choose to model the Client-Librarian interaction separately, or not at all, depending on the purpose of your model.
Question 2.
Let's take use case "Borrow book online". You may have two use case realizations for this use case: one for the keyboard machine and one for the touch screen machine. If these use case realizations are very similar, then I would just make only one use case realization and describe the fact that there are two possible input devices inside that single realization.
Question 3.
For a business use case realization, I would use BPMN 2.0 or a UML activity diagram. These are well suited for business workflow specification.
For a normal use case realization, I usually make a sequence diagram, where the lifelines in those diagrams refer to components defined in a common component diagram. In the left margin of the sequence diagrams, I usually write the steps of the use case in UML note symbols. The sequence diagram focuses on the interaction between components, using their interfaces. This gives a nice overview of the collaboration between components in the context of a particular use case.
For more information, please refer to my white paper Which UML models should we make?. The use case realization is described on page 19.
UML is method-agnostic. Even when there are no choices to make, there are different approaches to modeling, fo example:
Have one model and refine it succesfully getting it through the stages requirements, analysis (domain model of the problem), design (abstraction to be implemented), implementation (classes that are really in the code).
Have different models for different stage and keep them all up to date
Have successive models, without updating the previous stages.
keep only a high level design model to get the big picture, but without implementation details that could be found in the code.
Likewise, for your question, you could consider having different alternative models, or one model with different alternatives grouped in different packages (to avoid naming conflicts). Personally, I’d go for the latter, because the different alternatives should NOT be detailed too much. But ultimately, it’s a question of cost and benefits in your context.
By the way, Ivar Jacobson’s book, the Object advantage applies OO modeling techniques to business process design. So UML is perfectly suitable for a human solution. It’s just that the system under consideration is no longer an IT system, but a broader organisational system, in which IT represents some components among others.
UML has collaboration elements to show different implementations. The use cases are anchors since the added value for the actors does not change. However, you can realize these use cases in different ways. And that is where the collaborations come into play. A collaboration looks like a use case but has a dashed border. And you draw a realize relation from one or many collaborations towards a use case. Inside the collaborations you show how the different implementation's classes collaborate (hence the name).
P.213 of UML 2.5 in paragraph 11.7 Collaborations:
The primary purpose of Collaborations is to explain how a system of communicating elements collectively accomplish a specific task or set of tasks without necessarily having to incorporate detail that is irrelevant to the explanation. Collaborations are one way that UML may be used to capture design patterns.
A CollaborationUse represents the application of the pattern described by a Collaboration to a specific situation involving specific elements playing its collaborationRoles.
For my homework, I have to write functional requirement of a game called downfall (see Wikipedia).
We have to make this game, but with not two sides but n (any number of) sides.
In an example solution (another game), the teacher writes the functional requirements, then writes what use case they belong to.
I have created a use case diagram in which I have the player as an actor, and ChooseDial, RotateDial and EndTurn as use cases:
What I dont understand are the following:
Is the number of players functional requirement?
Is the table having two sides a functional requirement?
Is the goal of the game (getting coins from top to bottom) a functional requirement?
Is a rule like coins must reach bottom in order a functional requirement?
If they are, what use case could they belong to? Is my use case diagram wrong?
I have no idea where to put these functional requirements, because I feel like they arent part of any of my use cases.
About requirements
First, let's handle the requirement question:
A functional requirement tells something about what a software shall do. Everything related to goal, the gameplay or the rules of the game, is a functional requirement.
A non functional requirement tells something about how the software shall be, for example how accurate, how performant, how easy to use, how easy to maintain. Your narrative shows no such requirements.
About use-cases
Use case driven software development methods start with the high-level user's goals that are captured in use-cases. Personally, I see only one such goal:
Very rare usage: a multiplicity on the actor side of the use case. This says that 2 or more instances of players are involved in an instance of the use case. Of course, this makes sense only for the game as a whole, not for individual actions (like you have in your diagram).
In your diagram, you have shown 3 use cases:
is EndTurn an independent goal that the user may freely decide to chose ? No ! It's what always follows a player action. So this is definitely not a use case.
you say that RotateDials extends ChooseDials. This means that a player could ChooseDials but not rorate it. Is this a valid scenario ?
if on the other hand you'd say that ChooseDials includes RotateDials, the latter would always happen. But then, wouldn't ChooseDial not be more than just choosing a dial ? Shouldn't it then be called PlayTurn ?
I could understand that for learning purpose, you'd want to decompose the Play game in more detailed use-cases. Typically, once the players try to reach their goal Play game, this might include sub-goals of Play turn. As long as it is goal-oriented, and not too detailed, this is ok. But do avoid simple functional decomposition (it doesn't help for being more user-driven, and use-cases are not functions ). And, above all, do not misuse a use-case diagram for trying to show a sequence of activities.
Requirement traceability
The use cases do not capture the full requirements. It captures the most enssential thing: the purpose of the system and the user goals.
When writing down the requirements, it's then useful to get guided by the use-cases and their narrative, and to trace-back every use-case specific requirement.
But of course, there are some general requirements as well. These are not specific to a particular use-case. Some are even common to all use case. Mark these as general requirements (e.g. use case *).
Requirements management (RM) can be tricky indeed. A requirement like The board must have two sides seems to be more involved in the design, rather than the use case. In such cases you could relate that to the boundary rather than a single use case. That will indicate it's some "global" requirement (similar to a non-functional requirement). Usually in a project you start with a more or less strange mix of requirements mixed in user stories. The business analyst (BA) has to comb that information and come up with decent use cases (synthesize the added values). The system architect (with the BA) will then go through requirements and use cases to come up with a (business) class model.
There are tons of books and procedures describing RM. Lots of seminars too. I think if you grasp the condensed idea above you're ready to start. It's a marathon to start...
Edit:
Final outcome based on suggestion given by #qwerty_so
This is my use case diagram for View Repository in Source Code Management System.
This system is part of Project Management System.
The system is similar to GitHub, user can select project.
And it will display a list of repository for the project.
User can click a repository to view its details such as file tree and repository information.
Finally, user also can click the file in the tree to view its content.
Is my use of use case generalization correct?
Below use case is the previous version, I learnt that using use case diagram to model process is incorrect (Seidl et al., 2015, p. 37).
Seidl, M., Huemer, C., Kappel, G., & Scholz, M. (2015). UML # Classroom: An Introduction to Object-Oriented Modeling. Cham: Springer International Publishing.
Well, let me just ask a question: can you abstract added value? The only case where that is true is called franchise. So what you did is to introduce a new abstract bubble to connected three concrete use cases with your actor rather than connecting the concrete bubbles directly. What for? Where is the added value for "View repository"?
For the abstract actor it's similar. There is no need to make User abstract since it's already abstract. All actors denote roles, not real things. You can just leave that abstract keyword away and it would not change any semantics.
What often happens (and you are on that way) is that people start functional decomposition rather than synthesizing use cases. Use cases are about added value a system under consideration delivers to its actors. That's just it. Just present these added values. I know it's difficult for techies, but stick to that.
As always I recommend to read Bittner/Spence about use cases.
in my opinion, one use case is one scenario. since we have to make a scenario for every use case model drawn in the diagram, so one use case must have specific pre-condition and specific post-condition but only have one main or basic flow. Use case might have few alternative flows, that are illustrated in extends relationship. while include relationship is used to avoid repetition in several scenarios in main/basic flow of several use cases.
This question already has an answer here:
Have I to use the same actors for those extending or included use cases? [closed]
(1 answer)
Closed 6 years ago.
I am currently refreshing/altering my knowledge in software development because I will work in this area soon. We have learned a lot about UML diagrams and coding at University, but I have never brought it all together in a real Project. Therefore, I started to create a test web-app in Grails, and I wanted to begin with a requirements analysis and use cases too keep it close to reality.
My web-app should allow users to share recipes, find recipes and review recipes by other users. Every recipe has many ingredients, which are not just strings but rather entities so that calories, fat, protein and carbs can be used to automatically calculate nutrition facts of a certain recipe.
An ingredient can be added to the database by either a consumer or nutrition expert. If it is created by a consumer, it is only a "prospective" ingredient, meaning that it has to be verified by an administrator to become a "proper" ingredient -- otherwise it is marked, e.g. red text color.
This is my current use case diagram:
http://ubuntuone.com/0zDw9kEbj1BwtXjnCtxdwC
My question here is:
Can extending or included use cases be accessed independently? If I do it as in the screenshot, can AddProspectiveIngredient be used without going through the CreateRecipe use case? Same question for included use cases.
EDIT: I don't think this is a duplicate of this question. In the linked question (1), I ask if I have to use the same actor for extending and included use cases as in the extended or including use case. In this answer (2), however, I merely ask about reuse between use cases.
In (1) it is all about the actor, and I am very satsified with this answer, as I now understand that the primary actor of an extending use case will inevitably be a subclass of the primary actor of the extended use case.
(2) addresses reusability of extending and included use cases, but is not necessarily connected to actors. It is about reusing them in other use cases. So if I have two use case CreateRecipe (a) and AddIngredientToDatabase (b), where (b) extends (a), can I also extend a third use case with (b)? Here I also received my answer, that they can and should be reused.
Maybe the questions seem similar because I created them on the same day with the same example and the answers both mention actors, which make them seem as duplicates. As they are both answered and I am satisfied with both answers, why close the questions as "too broad" or "duplicates"? If it was answered succesfully with different answers, how can it be too broad or a duplicate?
I am also happy to rephrase them slightly to keep them open, if I am told what the core issues. More answers and comments on the topics are still interesting to me.
Can extending or included use cases be accessed independently?
They rather should be. It is a good and correct style. Use case is some activity conducted between one or more actors and system. You should try not to show here some inner operations, that are not connected to users. Nothing invisible to users can be shown here. USER cases, remember?
So, no inner structure here.
You can collect some cases in groups - subsystems. But it is not inner structure, they are not IT systems, they are simply common themes of activities, obvious for users. Such subsystems should get later at least common UI style.
As for logic that could be used by users, it can be shown on other diagrams. Many diagrams can exist on this level - State machines, Activities, Timing. But don't try to show processes on the Use case diagram, too.
So, I don't know how well have you interviewed the client, but you use case diagram looks almost correct. Only the AddProspectiveIngredient Use Case should get its user or more.
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.