Wiki
This website is a wiki. If you like and use our processes, techniques and tools, please add your experience and best practices. Just register and share.

Contents


User


Smart


Community

Forum






Stereotypes. List Detail (4 - Hard)

RSS
Modified on Monday, 12 January 2009 12:11 by mdriesse Categorized as Uncategorized
A “List Detail” type of use case represents the functionality presents a list of instances of a single business class, combined with the capability to hat manages the maintenance of the properties of the selected single instance of a business class from the list.

Preconditions

  • -none-

Steps

A “List Detail” performs the following basic steps:
  • Start. Initiate the use case.
  • Present list of objects. A list of all instances of a business class is presented to the user in a list. The first business object in the list is selected by default.
  • Merge node 0. Re-entry point for alternative flows.
  • Present object instance. The object instance which is selected in the list, is presented to the user in a form (on the same page as the list of objects).
  • Merge node 1. Re-entry point for alternative flows
  • Maintain object instance. The user maintains the properties of the object instance by changing its property values.
  • Save object instance. The user indicates the changed property values can be saved into the system.
    • Alternative flow - Back:
      1. The user cancels the use case.
      2. Finish. Finish the use case without saving pending changes to the properties of the object instance.
    • Alternative flow - Remove:
      1. Remove. The user indicates the object instance must be removed from the system.
      2. Confirm removal. The system requests the user to confirm the removal of the selected object instance.
        • Alternative flow - User cancels removal
          1. Cancel. The system cancels the removal of the object.
          2. Continue at Merge node 1.
        • Alternative flow - User confirms removal
          1. Validate removal. The system validates it the object instance can be removed from the system, given the context and the current object state.
          2. Alternative flow - Object removal violates business rules:
            • Business rule violation.If the removal of the objects violates against the business rules which apply to the business class in the given context and object state appropriate message(s) are presented to the user which should be helpful to fix the problem(s).
            • Continue at Merge node 1.
          3. Remove object. The system removes the object instance from the system.
          4. Select next object in list. The system selects the object instance which is next in the list.
          5. Continue at Merge node 0.
    • Alternative flow - New.
      1. New. The user indicates he wants to create a new instance of the business class, which is beeing managed by the use case.
      2. Create object. The systems creates a new instance of the business class with default property values.
      3. Select object. The systems selects the new object instance.
      4. Continue at Merge node 0.
  • Validate object instance. The system validates the changes to the object against the business rules which apply to the business class in the given context and object state.
    • Alternative flow - Changed object violates business rules:
      1. If the changes to the object state violate against the business rules which apply to the business class in the given context and state appropriate message(s) are presented to the user which should be helpful to fix the problem(s).
      2. Continue at Merge node 1.
  • Return changed object. The systems returns the changed business object to the calling use case.
  • Finish. Finish the use case.

Postconditions

  1. Instances of a business class might be changed by the user and these changes are permanantly saved in the system.
  2. Instances of a business class might be removed from the system.
  3. The use case is canceled by the user
These conditions are OR and thus might coexist!

Characteristics

An Manage follows the following characteristics:
  • List. Panel to display the List of items to select from.
  • Form. Form to the display the properties of the selected object.

Variations

Extensions to this stereotype can be:
  • Filtered List Detail. This stereotypes adds a filter to the use case with which the user can filter object instances which are to be presented in the list.
  • Master Detail. The stereotype use case that manages a single item from a business class and a list of items from an associated business class, such as order-orderline.
  • Manage. Simular to a Define use case, but with, selection extension & persistence.

Estimation (4 - Hard)

By default, a ListDetail is estimated at 4. If a filter is added to the use case choose 5.
  Name Size