A “Define” type of use case represents the functionality that manages the maintenance of the properties of a single instance of a business class, without permanantly saving the changes to the system. The persistence of the changes is the resposibility of one of the calling use cases on the call stack. This use case contains additional functionality, such as business rules, comparisons, authorization.
Because this stereotype lacks functionality to retrieve and persist a business object from/to the system, this stereotype is generaly used as a subfunction use case of a
Master Detail use case to manage a detail object. In those cases the
Master Detail use case takes care of retrieval and persisting.
Preconditions
- A single instance of a business class is provided by the calling use case
Steps
A “Define” performs the following basic steps:
- Start. Initiate the use case.
- Present object instance. A single object instance of a business class is presented 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 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 - Cancel:
- The user cancels the use case.
- Finish. Finish the use case without changes to the properties of the object instance.
- Alternative flow - Remove:
- The user indicates the object instance must be removed from the system.
- Validate removal. The system validates it the object instance can be removed from the system, given the context and the current object state.
- Alternative flow - Object removal violates business rules:
- If the removal of the object 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.
- Remove object. The system marks the object instance for removal from the system.
- Finish. Finish the use case and return the object instance with removal mark to the calling use case.
- 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:
- 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).
- 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
- A single instance of a business class is maintained by the user and returned to the caller without permanantly being saved in the system
- A single instance of a business class is returned with a marker for removal
- The use case is canceled by the user
These conditions are XOR
Characteristics
An
Manage follows the following characteristics:
- Form. Form to the display the Object panel. Can be any type of form.
- Object. Panel to display the properties of the business object.
Variations
Extensions to this stereotype can be:
- List Details. The stereotype use case that contains a list of items from a business class and that manages a single instance selected from this 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 (3 - Avarage)
By default, a
Define is estimated at
3.
(this is just an example)