If an agent can do A and B, or A or B, or A and after that B, is irrelevant for the use case diagram. Disconnect them.Īnd remember, the only if that can work in use case is "if A IS B, then it does this and that" Play Quiz should be connected to registered user and to guest.Ĭonnection login-play belongs to state or sequence diagram, not to use case. Create use case diagrams easily with the drag and drop editor, design with the rich set of UML symbols, keep your design in a cloud workspace and work collaboratively with your team. There will be no separate components for login user and login guest. The UML software provided by VP Online lets you create beautiful use case diagrams in a snap. Updating the quiz comes after questions generation? I bet not. Request subject is not extended by Play Quiz, but included.Ĭheck Login is excessive.
Rate and both checks do not belong to Play Quiz. ( you can leave it if you want - I see your reasons - but normally you should escape using parts of your system as agents - it does not belong to the standard use case language) He has no his own acts, no initiative, he only reacts to actions of users. On the other hand, your web-server is not an agent. Most people don't bother but doing a good job requires to think over basics and not adopt bad habits.You should distinct registered users and guests. This is quite challenging and I confess that sometimes I also fall back to Manage. So instead the reason why you manage something is the real use case (e.g. In many cases the focus on the real business was lost. Usually the "managing" itself is not directly business related. So when looking from a business perspective, a Login is not a use case, but a simple constraint (you can do the business relevant things only when you are logged in).
You can constrain maintenance operations to certain actors separately.Įdit Regarding Login (one of my favorites): Use cases are most commonly used to describe business context (exactly as you are doing).
This use case diagram tutorial will cover the following topics and help you create use cases better. They enable you to visualize the different types of roles in a system and how those roles interact with the system. Also with CRUD use cases I would not separate them but have a Maintain instead (which itself is some borderline use case since maintaining something is not directly business relevant). Use case diagram is a behavioral UML diagram type and frequently used to analyze various systems. But I guess one can understand what you are trying to communicate.Īs a side note: Login is not a business use case.
0 kommentar(er)
