Designing the Graphical User Interface › Graphical Design Standards › Standardize the Unit of Work

Standardize the Unit of Work

This standards committee topic requires the analysis of a business scenario to determine the unit of work before windows are designed to support it.

A unit of work is the set of data necessary to complete a transaction.

A unit of work is usually a commit point, since it is the point where committing the data to the database completes the transaction. Since a commit occurs at the end of a unit of work, the unit of work must not violate any business rules.

For example, to add entity A, which has a mandatory relationship with entity B, the unit of work may include adding attributes of entity A and either associating it to an existing entity B or allowing the creation of entity B at the same time as entity A.

A unit of work may require more than one window to capture all necessary data.

Some transactions consist of a defined set of data while others consist of a minimum set of data. The unit of work for adding a customer, for example, might require that the customer's name, address and phone number be entered. This type of unit of work is typically applied to entity type maintenance.

As a minimum, taking an order may require the order header information, one customer, and one product. However, a customer may order several products at once. Therefore, the unit of work for taking an order requires the order header, one customer, and one or more products. This type of unit of work is typically applied to one-to-many relationship and many-to-many relationship maintenance.

Another example of the minimum set of data concept is when two entities exist and all a user needs to do is associate the two. This type of unit of work is typically applied to many-to-many relationship maintenance.

Window design standards should define the presentation and processing method for each type of unit of work-a defined set of data or minimum set of data.

The processing methods consider when the commit occurs. For entity type maintenance, whatever is on the window is applied to the database.

For the minimum set of data scenario, the user may visit many windows adding, updating, and removing entities or associating and disassociating entities. This brings up several questions such as listed next:

• Does the commit occur after each add, update, remove, associate, or disassociate?
• Is the data collected until the user is finished and then applied to the database?

If the answer is yes, these questions need answers:

• Is all the old data removed and the new data added?
• Are just the user's changes recorded and applied to the database?

You should also consider network traffic, view size, and processing complexity.