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






A Master Detail describes a use case stereotype that handles a single instance of a domain object - say an order - and a list of instances that belong to this single instances - say the order lines with the selected order. The Order object and Order Line objects together form an aggregated business object.

Preconditions

-none-

Steps

Warning: this scenario is work in progress!

An “Master Detail” performs the following basic steps:
  • Start. The system initiates the use case.
  • Get object instance. The system takes the aggregated business object probivided by the calling use case.
    1. Alternative flow - No object instance available:
      • If an object instance is not provided by the calling use case, the system can start a sub-function use case which can provide an instance of an object. The use case stereotypes Simple Select, Select, Search, Extended Search provide this kind of functionality.
      • Get Detail items. The system gets the Detail items for which are part of the selected Master object.
      • Alternative flow - No Master object provided::
        1. The called sub-function use case was canceled and did not provide a Master object to manage.
        2. Finish. The system finishes the use case.
  • Present aggregated object instance. The system presents an object instance of an aggregated business object to the user in a form (any type, such as a web page, a Windows form, a Flash form).
  • Merge node 1. Re-entry point for alternative flows
  • Maintain master object instance. The user maintains the properties of the master object instance by changing its property values.
  • Save Master object. The user selects the action Save to indicate the changed property values of the Master object can be saved into the system.
    • Alternative flow - Cancel:
      1. The user selects the action Cancel.
      2. Finish. The system finishes the use case without persisting the changes to the aggregated object instance.
    • Alternative flow - Remove:
      1. The user selects the action Remove to indicate the aggregated object instance must be removed from the system.
      2. Validate removal. The system validates if the aggregated object instance can be removed from the system, given the context and the current object state. Both master and detail objects are validated.
      3. Alternative flow - Object removal violates business rules:
        • If the removal of the objects violates against the business rules which apply to the business classes 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.
      4. Remove object. The system removes the aggregated object instance from the system. This includes both the master object and the detail objects.
      5. Finish. The system finishes the use case.
  • Validate object instance. The system validates the changes to the aggregated object against the business rules which apply to the business classes in the given context and object state.
    • Alternative flow - Changed object violates business rules:
      1. If the changes to the aggregated object violate against the business rules which apply to the business classes 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.
  • Save changed object. The systems persists the changed aggregated business object. This includes both the master object and the detail objects.
  • Finish. The system finishes the use case.

Postconditions

  1. An aggregated business object is maintained by the user
  2. An aggregated business object is removed by the user
  3. The use case is canceled by the user
These conditions are XOR

Characteristics

Master detail follows the following characteristics:
  • Form. A master detail is oriented towards the user interface. A form represents both master and its details.
  • Master. A single instance of a certain domain object. There are two variations, one where the master is not maintainable, and another where it is.
  • Detail. A list of instances belonging to the master, such as the order lines with an order. New instances can be added, or current instances can be maintained, using a separate smart use case, in general a Manage or a Define.

Variations

Extensions to this stereotype can be:
  • Select or search. The master in a regular Master Detail needs to be selected; we generally use a Select or a Search to facilitate this. For instance, with a smart use case called Register Call, which is a Master Detail for call and activities, a second use case called Search Call is added.
  • Master in a list. A second variation exists where the master is not a single instance, but is represented in a list of masters. In this case, the selected item in the list functions as the master for the details. When another item is selected in the list, the details for this item are presented.
  • Master detail detail. Sometimes the user interface presents three layers in the hierarchy. Here the details to the master function as a master list; selecting an item in this list, presents its details in the second detail list.
In fact, various variations exist on this theme. Consider for example the following form, from an Oracle application. It represents the master in a list view, and has detail with the select item in the master. But with the selected detail a second level of details comes along.

Sander Hoogendoorn

Master in a list, with details and details

Master in a list, with details and details


Estimation (4 - Hard)

By default, a Master Detail is estimated at 4. In case it is a Master Detail Detail, add an additional point per level.
  Name Size