Even without explicitly showing integrations between systems, we have more useful information about the context of the new solution. In the expanded diagram, we can see other systems that are involved, and what use cases each system supports.
This is where an expanded use case diagram comes in handy. What happens with the orders that are ready for delivery? How are the deliveries scheduled? Who ensures that all required ingredients are purchased? Now, do you understand how the order will be processed end-to-end? Not really, as the new system clearly deals with only subset of use cases. The boundary of the new system has been defined, and use cases in scope have been captured: Simple use case diagram – one system boundary The project is going to build a new Online Ordering System. Adding more to the model can save you a lot of explaining and additional narrative. In these circumstances, a use case diagram that includes several systems can help understand who does what and where.
Many organizations manage complex landscapes of legacy systems, and new applications and COTS implementations with various degrees of interconnectedness.
What about other use cases that are not in the diagram? How will those be accomplished? And the context usually involves other systems.Ī use case diagram that focuses on one system only will leave some questions unanswered. In real life, however, whenever we capture the scope of a solution or a system, we need to keep the context in mind. It may be sufficient for discussing the system itself. Without getting into specifics of relationships such as extended and included use cases, a high-level use case diagram is perfect for depicting a scope of a solution for all audiences.Ī classic use case diagram has a single system boundary. It has three self-explanatory elements – the boundary, the actors and the use cases. It’s simple, clear and business-friendly.
0 kommentar(er)
