11.4 Rules about Data Access


Because many procedures can execute simultaneously, it is possible for them to access the same object memory at the same time, causing subtle and potentially fatal errors.

Definition: The data access set is the set of all data items read, written, or referenced by a single activation.

When the data access sets of several activations intersect, and there is at least one writer, there is the possibility of data access conflict. It is the responsibility of the developer to avoid data access conflict. Consequently, there is no substitute for disciplined data access strategies, described below.

Single writers of independent attributes.

Good practice generally assures that data access conflict cannot occur or is not relevant. Consider, for example, an object that is the sole writer of its own attributes. The writer updates independent attributes in certain states, and those attributes can then be read consistently by multiple readers.

Dependent attributes.

If the attributes are dependent on one another in some way, care must be taken to ensure that data is read consistently. Consider an account that requires the address of a customer expressed as multiple attributes: street and city. It is possible for the street to be read just before the customer updates the address but after the city is updated. This will send mail to the new street address in the old city.

Information Hiding, Encapsulation, Readers, and Writers

Encapsulation is an implementation mechanism used by object-oriented designers and object-oriented model compilers to protect clients from changes in data structure. When we say "multiple readers," this is shorthand for "multiple clients invoking encapsulating functions." We do not mean to violate encapsulation, though the model compiler could choose to do so and we'd never know it!

Encapsulation does not prevent data access conflict, as multiple things are happening at once. An object can be writing its own data at the same time as another object (a client) is re-entrantly invoking the encapsulating function. This is the normal situation in multithreaded environments, and Executable UML is multithreaded in the sense that each object executes concurrently.

Similarly, if there are several writers, they are just clients invoking encapsulating functions, and encapsulation at the level of information hiding is not violated. However, encapsulation also covers behavior, and in this case it is fair to say encapsulation has at least been compromised. Hence, it is good practice to localize behavior in a single class, preferably the class that creates the instance.

It can be difficult to achieve data consistency for this case in a general way, but it is often easy to do if you are willing to impose some rules on the modeler or on the model compiler. For example, you could require the two attributes to be modeled as one, address, and carry out operations requiring the city or street in a separate domain. Alternatively, you could require the model compiler to impose a transaction over the affected attributes or to lock them. In some cases, the model could guarantee account statements will never be issued at the same time customers' addresses are updated.

This kind of assumption must be documented in the assumptions for the domain, and if necessary, as a requirement on the model compiler.

graphics/exclamation.gif

Do not put a transition on every state in the target state machine to handle an event for reading the dependent attributes; for example, a readAddress event on the Customer.

Do not send signals from one state machine to another to indicate locking of the data. The number of signals can quickly explode and become unmanageable.

A model compiler can easily implement a data locking or transaction strategy uniformly, once you've modeled the required data accesses properly.

Multiple Writers.

Similarly, it is the responsibility of the modeler to ensure there is no data access conflict if there are multiple writers; for example, if an order and a credit card charge can both write the total amount of the order. Obviously, this is bad practice, and the model should be changed to ensure a single writer in almost all cases.



Executable UML. A Foundation for Model-Driven Architecture
Executable UML: A Foundation for Model-Driven Architecture
ISBN: 0201748045
EAN: 2147483647
Year: 2001
Pages: 161

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net