Use Case Diagrams show how Actors interact (or communicate) with the system via Use Cases they also also show how the Use Cases interact with each other. (.) there’s little chance of getting the requirements wrong.Use Case Diagrams can be effectively used to communicate the high level functionality of the system to the stakeholders in a concise and easy-to-understand visual format. Use cases for simple CRUD behavior don’t add much value to ensuring that the system is doing the right thing. They clarify why it is not worth the effort: We summarize this guideline as “use cases should contain more than CRUD.” Their main argument is not that CRUD cases are wrong, but that they are time consuming and provide little value for the modeling:Īlthough it is technically appropriate to employ use cases to describe this kind of behavior, it’s probably not a great use of time to describe this behavior in terms of use cases. Kurt Bitter and Ian Spence in their excellent book Use Case Modeling discourage the use of CRUD use cases. This technique corresponds very much to generalization/specialization, to which he also refers in an annex about the UML notation. However they clutter up the use-case set and can triple the number of items to track.Īs Cockburn focuses on describing use cases more than the UML models, he then describes what he calls "parameterized use cases", with a general use case with some scenario actions that would be more specific for the specific use cases. In principle they are separate because each is a separate goal, carried out by a different person with different security level. The question is, are they all part of one bigger use case, Manage xxx, or are they separate? What do authors say?Īlistair Cockburn dedicates in his excellent book Writing effective use-cases a full chapter on CRUD use-cases: The version with the generalization, could perfectly correspond to proper use cases, with a general goal, that are specified in more specific goals, each making sense on its own. Let's avoid this kind of functional decomposition. But this is not the case, since you claim that " at least one of three use cases happen". This would make sense only if the left Update movie would make sense for an actor without considering any of its extensions. Looking at the left, the relation to the use-cases on the right, with «extends» suggests that you are in fact modeling a user interface or a feature where for example a window Update movie could lead to the different other functions or features, each on the right being optional.So a renaming is required to avoid ambiguity. It is not clear how Update movie is different from Modify movie, looking at the usual understanding of CRUD.The right could be sub-goals that matter to the user (ok for a use case) or functional decomposition of how to achieve the goal (not ok for a use case). Use-cases are in principle for actor goals.The use-cases in that specific diagram are ambiguous: However, consider renaming the general use case. If keeping only the left use-case is not an option, then prefer the second version based on generalization, as it better conveys a goal-oriented use-cases.
0 Comments
Leave a Reply. |