Use case diagram: Difference between revisions

Content deleted Content added

Inline

Revision as of 15:35, 29 October 2012

A use case diagram at its simplest is a graphical 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.

Construction

Actors are portrayed in a use case diagram as a stick figure and represent external factors that will provide interaction with the system. The term "actors" are frequently interchanged with the term "users"; however an actor does not necessarily have to be a human user. An actor could be other systems or some other form of external input into the system.^[1]
The system delimitation visually defines what components will be part of the system and what factors are external. Actors are portrayed outside of the rectangular box that represents the system boundary. Within that box contains the different functions, or use cases, of the system. The boundary provides a means of segregating internal and external factors and also provides a means of showing the interaction between the two types of factors.^[2]
Use cases are all of the functionality of the system that is contained within the system boundary. The actors will interact in some means with the individual use case and each use case will represent a concise portion of functionality.^[3] The individual use cases will be represented by ovals within the rectangular system boundary. Actors will interact with the use case by means of arrows.
Association refers to how individual use cases can be linked together based upon certain functionality. These are drawn as lines or arrows from the originating item to the appropriate use case.
- Extension is an association between two use cases where the functionality of some use cases is similar but could have some deviations or additions depending on the scenario.^[4] For example: when purchasing concert tickets, there is a standard use case for telephone sales, but some variations could come into play if the performance is completely full.
- Inclusion is an association between use cases where there is a chunk of functionality that is inclusive in multiple cases and can be abstracted into a separate model and essentially "included" in other use cases.^[5] For example: when filling up your car with gasoline, some options include paying at the pump with a credit card or paying inside the convenience store with a credit card (among other options). The use case of "Process credit card payment" would be functionality that could be included in either scenario.
- Generalization is an association between use cases where the basic functionality is the same, but specific implementation details may differ.^[6] For example: the use case of "Purchase a shirt" is a general way to describe a customer making a purchase from a retailer. This purchase could be made in different ways depending on if the user purchases online versus the actual store. While either scenario would have some common "general" characteristics, there will still be some differences as well.

Application

It is a very well known adage that "A picture is worth a thousand words". 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".^[7] 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".^[8] 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.

Limitations

As stated above, a use case diagram is not a standalone model, but one that can be used in conjunction with other models as well. Since the main purpose is to outline general behavior, the use case diagram should "focus on business goals rather than system goals".^[9] A use case diagram is not meant to technically outline the functionality of the system, but to provide the business reasoning and outcomes of the system.

Tips

Always structure and organize the use case diagram from the perspective of the actor.^[10]
Use cases should start off simple and at the highest view possible. Only then can they be refined and detailed further.^[11]
Use case diagrams are based upon functionality and thus should focus on the "what" and not the "how".^[12]

References

^ Jacobsen et al, 1992, page 157
^ Jacobsen et al, 1992, page 158
^ Jacobsen et al, 1992, page 159
^ Vidgen, 2003, page 14
^ Vidgen, 2003, page 14-15
^ Vidgen, 2003, page 15
^ McLaughlin et al, 2006, page 297
^ Siau & Lee, 2004, page 234
^ Vidgen, 2003, page 13
^ Vidgen, 2003, page 14
^ Vidgen, 2003, page 13
^ Siau & Lee, 2004, page 230

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., Kasahara, T., Itoh, 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.

[1] Jacobsen et al, 1992, page 157

[2] Jacobsen et al, 1992, page 158

[3] Jacobsen et al, 1992, page 159

[4] Vidgen, 2003, page 14

[5] Vidgen, 2003, page 14-15

[6] Vidgen, 2003, page 15

[7] McLaughlin et al, 2006, page 297

[8] Siau & Lee, 2004, page 234

[9] Vidgen, 2003, page 13

[10] Vidgen, 2003, page 14

[11] Vidgen, 2003, page 13

[12] Siau & Lee, 2004, page 230

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

@@ Line 6: / Line 6: @@
 == Construction ==
-* [[Actor (UML)|Actors]]is are portrayed in a use case diagram as a stick figure and represent external factors that will provide interaction with the system. The term "[[Actor (UML)|actors]]" are frequently interchanged with the term "users"; however an [[Actor (UML)|actor]] does not necessarily have to be a human user. An [[Actor (UML)|actor]] could be other systems or some other form of external input into the system.<ref>Jacobsen et al, 1992, page 157</ref>
+* [[Actor (UML)|Actors]] are portrayed in a use case diagram as a stick figure and represent external factors that will provide interaction with the system. The term "[[Actor (UML)|actors]]" are frequently interchanged with the term "users"; however an [[Actor (UML)|actor]] does not necessarily have to be a human user. An [[Actor (UML)|actor]] could be other systems or some other form of external input into the system.<ref>Jacobsen et al, 1992, page 157</ref>
 * The system delimitation visually defines what components will be part of the system and what factors are external. [[Actor (UML)|Actors]] are portrayed outside of the rectangular box that represents the system boundary. Within that box contains the different functions, or [[Use Case|use cases]], of the system. The boundary provides a means of segregating internal and external factors and also provides a means of showing the interaction between the two types of factors.<ref>Jacobsen et al, 1992, page 158</ref>
 * [[Use Case|Use cases]] are all of the functionality of the system that is contained within the system boundary. The [[Actor (UML)|actors]] will interact in some means with the individual [[Use Case|use case]] and each [[Use Case|use case]] will represent a concise portion of functionality.<ref>Jacobsen et al, 1992, page 159</ref> The individual [[Use Case|use cases]] will be represented by ovals within the rectangular system boundary. [[Actor (UML)|Actors]] will interact with the [[Use Case|use case]] by means of arrows.