Databases Reference
In-Depth Information
tables), permission management, naming of use cases (verbal
base), etc.
This configuration data is automatically taken into
consideration by the MDM system to generate screens and
adapt the behavior of its programming services.
The approach described here functions if the use cases of
the MDM system respect a generic interaction model. We
call this an “elementary use case”.
We leave room for rare use cases that go beyond the
generic model and name them “extended use cases”. The
following sections return to the definition and realization of
these two types of use cases.
11.3.2. Elementary use case
A use case is elementary when it is executed in the
ergonomic mechanism provided by default by the MDM
system for the creation, reading, modification and deletion.
To achieve this, this use case can call upon elementary
business operations, i.e. those that don't have dependencies
on the business objects' states. It can also execute extended
business operations, but only those that do not modify the
business objects' states. The execution of these operations is
then constrained by the states decision table (see previous
chapter on semantic modeling).
Consequently, the elementary use case can never call
upon a business operation that is susceptible to change the
state of a business object. The impact of a state modification
is of such importance for data integrity that it is important
not to, from an organizational point of view, enable its
execution in such as generic manner as the elementary use
case. It is a reason why we need the extended use case
concept.
Search WWH ::




Custom Search