When you have a generalized Use Case that includes the CRUD use cases (create, read, update, delete), i know that all these included use cases have their respective Sequence Diagram. But, when you generate the sequence diagram to the generalized use case… how you represent the messages for the inclusion to the CRUD use cases?
first, i tried to include all sequences of the includes use cases, but this is not only redundant, also enlarges the lifeline of the system class. The system would wait messages from the user like readData() or updateData(), but maybe the user will send only a deleteData() message…
I thought to use frames, but i have understand that this is for extensions, not for inclusions. If you can give me that information, i will appreciate your help in this matter.
Best regards
GMH
First, let me make sure my understanding to your use case is correct first. Please see image “Your design”, which shows my understand to your current design.
If my understanding is correct, the diagram is actually meaning that when performing the use case “Visible Goal”, all the CRUD use cases will be performed in NORMAL scenario. But in the second paragraph of your message, it seems that not all of the CRUD use cases may be invoked. Therefore, I doubt whether this design is correct or not. The case is like the ATM machine, withdraw and deposit money are always 2 ‘standalone’ use cases since they serve 2 distinct goals. One may argue that the user could first withdraw money and then deposit the money, which seems to be your design, which shows a main use case including the CRUD use cases. But if we really are going to present those possible combinations, there will have many alternatives:
Take the ATM machine as example, in modeling we would present by showing three distinct interactions between the actor and the 3 use cases, which are:
Actor – Withdraw money
Actor – Deposit money
Actor – Check balance
Include use cases are usually common behaviors factored out from two or more use cases. I suggest you to treat each of the CRUD use case as one standalone use case that the actor will interact with. By doing this you will not have the problem in sequence diagram since the flows are distinct for the CRUD use cases.
Since I am unclear about your problem domain, if you really have the need to present by showing the CRUD use cases as included use case, then I suggest you to write only the entering and the returning message of the CRUD use cases in the main use cases, like this:
…
Actor: Create something
System: Show something created
…
…
…
Actor: Update something
System: Show something updated
and leave the complex flow to be written in the CRUD use cases. This will reduce the complexity of the main use case.
Excuse me, thanks for your answer and for your attention. Unfortunately, i can’t see the attachments, maybe they wasn’t uploaded. Can you try again, please?
I will work in the traslation of my diagram to show you images, because now its in spanish.
I’m the thesis project partner of GMH and I think that what GMH wanted to ask was about modelling the CRUD functions, is modelling a main use case (let’s say manage “X”), and the functions CRUD “X” are included cases from the main use case.
So I feel that there is a discussion about how is the correct interpretation for including the use cases like CRUD in a main use case, which in this case are kinf of “optional”. Or it is just a semantic problem. We have been discussing this interpration for days.
I think I can help , actually when you make a use case that handle CRUD operation you have to think more visually and consider the GUI of your application otherwise you have to consider a main coarse of action in your flow
For Example a Use Case for CRUD operation on users will become Manage Users with the following Sequence Diagram
Where the List is your main action and all other action a driven from the list, for example if you want to delete user you delete it after you list this users, and so if you want to update another user , and create a new one could be your extension point
So you could either make one user case that have a 4 other use cases extending from it, by this you will be using MVC pattern
Thanks MOhammed!
actually, we are considering it, but for now we have it in the documentation of the sequence diagrams, because that’s what the software developper who’ll build the system say us.
I think I can help , actually when you make a use case that handle CRUD operation you have to think more visually and consider the GUI of your application otherwise you have to consider a main coarse of action in your flow
For Example a Use Case for CRUD operation on users will become Manage Users with the following Sequence Diagram
Where the List is your main action and all other action a driven from the list, for example if you want to delete user you delete it after you list this users, and so if you want to update another user , and create a new one could be your extension point
So you could either make one user case that have a 4 other use cases extending from it, by this you will be using MVC pattern
I think I can help , actually when you make a use case that handle CRUD operation you have to think more visually and consider the GUI of your application otherwise you have to consider a main coarse of action in your flow
For Example a Use Case for CRUD operation on users will become Manage Users with the following Sequence Diagram
Where the List is your main action and all other action a driven from the list, for example if you want to delete user you delete it after you list this users, and so if you want to update another user , and create a new one could be your extension point
So you could either make one user case that have a 4 other use cases extending from it, by this you will be using MVC pattern
