OOPortal OOPortal


Project Life Cycle  «Prev  Next»
Lesson 9

Use Case Model Conclusion

User Requirements use cases

This module discussed the purpose and scope, elements of, and notation used with the use case model.
  1. The purpose and scope of the use case model: to model the user expectations for the system
  2. The elements of a use case model: the use case diagram and use case narratives
  3. The notation of the use case diagram: the system, actors, use cases, and associations
  4. How to construct a use case diagram from a problem statement
  5. How to document a use case using a narrative of the dialog between an actor and a use case
  6. How to refine the use case diagram using UML extensions called stereotypes
  7. How to use the Includes stereotype (<<includes>>)
  8. How to use the Extends stereotype and generalization (<<extends>>).



Glossary terms

  1. Actor:A person, system, or device that interacts with a system in a use case diagram.
  2. Association:A relationship between classes that specifies the type of links that may be created between objects of the associated classes.
  3. Assumptions:Behaviors that must be handled by another use case prior to allowing anyone access to the use case in question.
  4. Encapsulation:The ability to provide users with a well-defined interface to a set of functions in a way which hides their internal workings. In object-oriented programming, the technique of keeping together data structures and the methods (procedures) which act on them.
  5. Exceptional flow of events:A condition that changes the normal flow of control in a system.
  6. Main flow of events: The normal flow of control in a system.
  7. Model element:The smallest unit of semantic definition in a model. The same model element may appear in multiple diagrams. For example, an event appears in sequence diagrams, collaboration diagrams and statechart diagrams. In all three contexts it provides the same semantic information.
  8. Pre-condition: A condition that must test true before execution of the owning task.
  9. Post-condition:A condition that must test true at completion of the owning task.
  10. Triggering event:Event that initiates the use case. The event could be a point in time (for example, month's end), a condition in the system (for example, account is overdrawn), or a request by an actor (for example, selecting an option).
  11. Use case:A use case is a goal that a system must achieve to be considered successful.