Arunkumar Khannur's Software Testing Knowledge Center
   
 

11.9. Textual Use Case Modeling

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

11.9.1. Modeling 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

11.9.2. Modeling 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 description 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 will provide functionality to manage 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.
  • 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
  • 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.

11.9.3. Modeling Association Relationships
The Relationships identify other use cases to which the use case is related. The use cases may be interrelated in several ways:
  • Inclusion – one use case is included (by reference) within or used by another use case
  • Variant or Alternative – one use case is a specialized variant of another, more general case
  • Extension – one use case extends another by introducing alternative or exceptional processes
  • In addition, we find other relationships useful on occasion.
  • Similarity – one use case corresponds to or is similar to or resembles another in some unspecified ways
  • Equivalence – one use case is equivalent to another, that is, serves as an alias
  • When modeling associations, we ought to be aware of the following guidelines:
  • An association should be named using a verb phrase.
  • An association should be sufficiently described in terms of the actor and use case it relates. An association should be sufficiently described in terms of its attributes, operations, and associations.
  • An association should be a well-defined abstraction. The actor and use case an association relates and an association's attributes, operations, and associations shall be sufficiently described but not sufficiently defined. To sufficiently define an association, there ought to be sufficiently understandable semantics -- that is, the meaning of the association and its contextual business semantics, rules, and so forth. Such semantics are very context dependent, which makes the semantics even more important in defining and effectively using an association.
  • Role-names, interface specifier, navigation, and multiplicity should be used to better communicate about associations in a specific context. Use role-names to model how a class participates in an association, interface specifier to model the behavior expected of an actor or an use case by other actor and use case that participate in an association, navigation to model that a class is identifiable and reference-able from associated actor and use case, and multiplicity to model how many instances of a class may participate in a relationship when the associated actor and use case are fixed
  • Associations, aggregation associations, and composition associations should be used to better communicate about associations in a specific context. Use associations to model a general relationship between actor and use case, aggregation associations to model whole-part relationships, and composition associations or composite aggregation to model whole-part relationships where the parts must belong only to one whole and the whole is responsible for destroying its parts when it is destroyed. Consider if the phase “has-a” describes aggregation associations and if the phrase “contains-a” describes composition associations
 
 
Khannur's Book
Arunkumar Khannur, Software Testing - Techniques and Applications, Published by Pearson Publications, 2011 (ISBN:978-81-317-5836-6; Pages:341 + xxii)
Follow Khannur
         
Khannur's Company
ISQT Process & Consulting Services Pvt. Ltd., Bangalore, INDIA
Khannur's Software Testing Forum
STEP-AUTO Forum
 Contact Khannur
ISQT Process & Consulting Services Pvt. Ltd.
#732, 1st Floor, 12th Main,
3rd Block, Rajajinagar,
Bangalore - 560010, INDIA
Phone: +91 80 23012511
URL: www.isqtinternational.com
Email: khannur@isqtinternational.com
Skype: arun.isqt