-1

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.

Community
  • 1
  • 1
nst1nctz
  • 333
  • 3
  • 23

1 Answers1

0

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.

Gangnus
  • 24,044
  • 16
  • 90
  • 149
  • Thanks a lot for your help. So, do I understand you right that I should create an association between `consumer` and `AddProspectiveIngredient`? Doesn't the <> already imply that `consumer` is the primary actor? And, using the diagram as it is, a consumer could create a prospective ingredient without starting to create a recipe? This was my main concern. – nst1nctz Feb 23 '14 at 22:29
  • No, Extend means merely that one behaviour is a variation of another one. You are using VP UML - hover the mouse pointer over Extend arrow in palette and read the hint. – Gangnus Feb 23 '14 at 22:32
  • Ok, I start to understand better. A use case that extends another use case must also have an association to an actor? If that is right I got it. It is confusing that most online use case tutorials have different approaches and, apparently, play after different rules. – nst1nctz Feb 23 '14 at 23:21
  • @user3025256 could you put here some links, please? – Gangnus Feb 24 '14 at 09:56
  • Just general contradictions from online tutorials to each other. Some use nouns for use cases (http://www.tutorialspoint.com/uml/uml_use_case_diagram.htm); others connect actors with use cases if they do not represent the actors goal (http://www.agilemodeling.com/artifacts/useCaseDiagram.htm - "perform security check"). That is why I ask here, because I do not know which source to trust. If you know any good sources for use case guidelines, and other UML Modeling, I would be glad to know it. – nst1nctz Feb 25 '14 at 17:11