State Recovery

It is a very concrete type of Dependency. However this type is quite frequent and semantically strong that can be considered as a pattern per se. State Recovery occurs in the context of a Service Interaction Unit when some properties take value when an object is selected to show the current value for such object.

State Recovery Sample 1
Figure 1. Before selecting a customer.

State Recovery Sample 2
Figure 2. After selection, fields are recovered.


When editing the properties of an existing object or data, users expects to see the current values. Then after recognizing the actual state, they will edit the properties needed and confirm the changes.


Information Consistence, Guiding users, Minimal effort.



When the object to be edited is selected, properties should immediately be updated to synchronize its view. Otherwise, user will be confused.


Figure 1. Shows a Service Interaction Unit designed to edit the properties of a customer. The user is going to select a given Customer by its name.

After the selection (Figure 2) all the fields related to the Customer State are recovered to match with the current user.

In terms of Dependency, we can say that all fields are dependent from the identification field: whenever it takes a value to a valid customer, the rest synchronize, if the customer is not valid or empty, the fields are cleaned.


State recovery can be applied to apply to direct-edit services. These services allows to update the properties of an object in a very direct way: each field or parameter is directly binded with a property (or more precisely an attribute in an OO-world).

Next to the fields related to each property, there is also a special one: the identifier of the object. This is an important one: it will receive the consequences of executing the action of the service, and therefore in the State Recovery Pattern is vital to identify this role because the rest of the fields will be dependent on this one.

Root CUIP Metalevel

Valid XHTML 1.0 Strict Valid CSS