Understanding Use Case Modeling - Page 3

Sinan Si Alhir, http://sites.google.com/site/salhir/

Use Case Modeling

To successfully apply use case diagrams in use case modeling, we ought to be aware of various guidelines (lessons learned) from applying this technique.

Actors

When modeling actors, we ought to be aware of the following guidelines:

• Actors should be named using noun phrases.
• Actors should be described, indicating what interests an actor has in interacting with the system. For example, the project manager is responsible for ensuring the success of projects, and the project database is responsible for housing project management data.
• Actors define the scope of a system and identify those elements that reside at the periphery of the system and those elements on which the system depends. For example, these use case diagrams indicate that the project management system depends on a project database to provide functionality to a project manager, both residing on the periphery of the system.

Furthermore, other guidelines may be applied in addition to those above.

Use Cases

When modeling use cases, we ought to be aware of the following guidelines:

• Use cases should be named using verb-noun phrases.
• Use cases should be described, indicating how they are started and end, any conditions that must be satisfied before the use case starts (pre-conditions), any conditions that must be satisfied when the use case ends (post-conditions), the sequence of exchanged messages and performed actions, the data exchanged, and any non-functional characteristics (reliability, performance, supportability, etc. constraints). This descriptions may be captured using text and other UML diagrams.
• Use cases define the scope of a system and define the functionality provided by the system and those elements on which the system depends in order to provide the functionality. For example, these use case diagrams indicate that the project management system provides functionality to mange projects to a project manager, and this functionality is implemented using the project database.
• Use cases should facilitate actors in reaching their goals. Use cases are system functionality or responsibilities (requirements) that actors use in order to reach or satisfy their goals. Use cases are not simply actor goals. For example, a project manager is responsible for ensuring the success of projects, and a project database is responsible for housing project management data. The project management system provides functionality to manage projects to a project manager such that the project manger can ensure the success of projects.
• Use cases should facilitate the architecture of a system. Use cases may be organized and partitioned using includes, extends, and generalization relationships to identify, extract, and manage common, optional, and similar functionality. The organization of a set of use cases is not simply the architecture of the system. However, the architecture of a system is based upon the various technology, infrastructure, etc. considerations relevant to satisfying the use cases. For example, the project management system must interface with an e-mail system and a web-site host, thus appropriate subsystem elements must exist within our architecture to facilitate these interfaces.
• Use cases provide flexibility and power throughout the life-cycle process. They provide the freedom to work with a use case as a whole or any subset of a use case via scenarios. The use of includes, extends, and generalization relationships to identify, extract, and manage common, optional, and similar functionality provides further flexibility in working with use cases. Furthermore, use cases may be used to model interactions between actors and systems, subsystems, and classes at various levels of abstraction. This flexibly and power is propagated to every application of use cases. For example, if time, resources, or funding are not sufficient to implement a whole use case, various scenarios may be selected for implementation based upon these factors.
• Use cases may be used as the basis for planning. Time and resource estimates may be associated with use cases. If estimates for a use case cannot be derived, estimates for each scenario of a use case may be derived and used to potentially estimate the overall time and resource estimates for the use case as a whole. This helps ensure that planning is done with the objective of satisfying the requirements.
• Use cases may be used as the basis for analysis, design, and implementation. The sequence of exchanged messages and performed actions within the description of a use case are analyzed and the system is design and implemented to specifically realize use case interactions. This helps ensure that every element of a system is created and used because it contributes to satisfying the requirements.
• Use cases may be used as the basis for testing. The sequence of exchanged messages and performed actions within the description of a use case may be used as test scripts for validating the functionality of a system. This helps ensure that the system is tested and validated against the requirements.
• Use cases may be used as the basis for documentation since use cases capture how users will use the system.

Furthermore, other guidelines may be applied in addition to those above.

Conclusion

As the Unified Modeling Language (UML) is an evolutionary general-purpose, broadly applicable, tool-supported, and industry-standardized modeling language for specifying, visualizing, constructing, and documenting the artifacts of a system-intensive process, by understanding the types of elements used in use case diagrams and being .aware of various guidelines (lessons learned) from applying this technique, we have a sound foundation for successfully applying the technique. Furthermore, it is experience, experimentation, and application of the standard and its various techniques that will enable us to realize its benefits.

Related Unified Modeling Language UML articles

• Understanding the Unified Modeling Language (UML)
• Precise Use Cases
• Estimating With Use Case Points

More Unified Modeling Language UML Knowledge

• UML & Software Architecture Zone
• UML Tools

Page 2   

Click here to view the complete list of archived articles

This article was originally published in the Spring 2000 issue of Methods & Tools