Use case diagram: Difference between revisions
missing full stop (otherwise know as a "period") |
|||
| Line 6: | Line 6: | ||
== Application == |
== Application == |
||
With regards to use case diagrams, that is exactly what they are meant to do. While a [[Use Case|use case]] itself might drill into a lot of detail about every possibility, a use-case diagram can help provide a higher-level view of the system. It has been said before that "Use case diagrams are the blueprints for your system".<ref>McLaughlin et al, 2006, page 297</ref> They provide the simplified and graphical representation of what the system must actually do |
With regards to use case diagrams, that is exactly what they are meant to do. While a [[Use Case|use case]] itself might drill into a lot of detail about every possibility, a use-case diagram can help provide a higher-level view of the system. It has been said before that "Use case diagrams are the blueprints for your system".<ref>McLaughlin et al, 2006, page 297</ref> They provide the simplified and graphical representation of what the system must actually do. |
||
Due to their simplistic nature, use case diagrams can be a good communication tool for [[Project stakeholder|stakeholders]]. The drawings attempt to mimic the real world and provide a view for the [[Project stakeholder|stakeholder]] to understand how the system is going to be designed. Siau and Lee conducted research to determine if there was a valid situation for use case diagrams at all or if they were unnecessary. What was found was that the use case diagrams conveyed the intent of the system in a more simplified manner to [[Project stakeholder|stakeholders]] and that they were "interpreted more completely than class diagrams".<ref>Siau & Lee, 2004, page 234</ref> The purpose of the use case diagrams is simply to provide the high level view of the system and convey the requirements in layman's terms for the [[Project stakeholder|stakeholders]]. Additional diagrams and documentation can be used to provide a complete functional and technical view of the system. |
Due to their simplistic nature, use case diagrams can be a good communication tool for [[Project stakeholder|stakeholders]]. The drawings attempt to mimic the real world and provide a view for the [[Project stakeholder|stakeholder]] to understand how the system is going to be designed. Siau and Lee conducted research to determine if there was a valid situation for use case diagrams at all or if they were unnecessary. What was found was that the use case diagrams conveyed the intent of the system in a more simplified manner to [[Project stakeholder|stakeholders]] and that they were "interpreted more completely than class diagrams".<ref>Siau & Lee, 2004, page 234</ref> The purpose of the use case diagrams is simply to provide the high level view of the system and convey the requirements in layman's terms for the [[Project stakeholder|stakeholders]]. Additional diagrams and documentation can be used to provide a complete functional and technical view of the system. |
||
Revision as of 13:16, 8 July 2013
A use case diagram at its simplest is a representation of a user's interaction with the system and depicting the specifications of a use case. A use case diagram can portray the different types of users of a system and the various ways that they interact with the system. This type of diagram is typically used in conjunction with the textual use case and will often be accompanied by other types of diagrams as well.
| UML diagram types |
|---|
| Structural UML diagrams |
| Behavioral UML diagrams |
Application
With regards to use case diagrams, that is exactly what they are meant to do. While a use case itself might drill into a lot of detail about every possibility, a use-case diagram can help provide a higher-level view of the system. It has been said before that "Use case diagrams are the blueprints for your system".[1] They provide the simplified and graphical representation of what the system must actually do.
Due to their simplistic nature, use case diagrams can be a good communication tool for stakeholders. The drawings attempt to mimic the real world and provide a view for the stakeholder to understand how the system is going to be designed. Siau and Lee conducted research to determine if there was a valid situation for use case diagrams at all or if they were unnecessary. What was found was that the use case diagrams conveyed the intent of the system in a more simplified manner to stakeholders and that they were "interpreted more completely than class diagrams".[2] The purpose of the use case diagrams is simply to provide the high level view of the system and convey the requirements in layman's terms for the stakeholders. Additional diagrams and documentation can be used to provide a complete functional and technical view of the system.
Tips
- Always structure and organize the use case diagram from the perspective of the actor.[3]
- Use cases should start off simple and at the highest view possible. Only then can they be refined and detailed further.[4]
- Use case diagrams are based upon functionality and thus should focus on the "what" and not the "how".[5]
See also
- Use case
- Unified Modeling Language
- Fundamental modeling concepts
- SysML
- Applications of UML
- Business Case
- User story
- Agile software development
References
Bibliography
- Gemino, A., Parker, D.(2009) "Use case diagrams in support of use case modeling: Deriving understanding from the picture", Journal of Database Management, 20(1), 1-24.
- Jacobson, I., Christerson M., Jonsson P., Övergaard G., (1992). Object-Oriented Software Engineering - A Use Case Driven Approach, Addison-Wesley.
- Kawabata, R., Kasah, K. (2007). "Systems Analysis for Collaborative System by Use Case Diagram", Journal of Integrated Design & Process Science, 11(1), 13-27.
- McLaughlin, B., Pollice, G., West, D. (2006). Head First Object Oriented Analysis and Design, O'Reilly Media, Inc.
- Siau, K., Lee, L. (2004). "Are use case and class diagrams complementary in requirements analysis? An experimental study on use case and class diagrams in UML", Requirements Engineering, 9(4), 229-237.
- Vidgen, R. (2003). "Requirements Analysis and UML: Use Cases and Class Diagrams", Computing & Control Engineering, 14(2), 12.