Objective
Whenever actual objects are represented by a system, changes on their symbolic counterpart must take into account time related constraints.
Objects Synchronization
Objects synchronization deals with time-related dependencies between persistency units, i.e it adds a time dimension to functional dependencies. It can be seen as a dual description of activities synchronization which deals with the timing of execution units. Keeping architectural concerns in mind, those dependencies are described depending on the nature of dependency (symbolic or actual) and the level of control (local or distributed):
- Symbolic synchronization deals with time-related dependencies between symbolic persistency units independently of actual events. Local synchronization can be directly managed at object level, otherwise architecture-based mechanisms are needed if updates are to be propagated across distributed domains and time-dependent links.
- Actual synchronization deals with time-related dependencies between symbolic representations and changes of their actual counterparts as signaled by events from context. Events can remain implicit if synchronization is local, otherwise explicit (symbolic) events are needed if synchronization is to be achieved across distributed systems.
- Local, symbolic: scheduled maintenance and rentals are managed as vehicle features.
- Distributed, symbolic: assignments consistency are managed globally.
- Local, actual: check-ins and checkouts are directly recorded with symbolic representations.
- Distributed, actual: check-ins and checkouts can be done at different depot and actual status cannot therefore be directly recorded with symbolic representations.
Both symbolic and actual synchronization can be defined within or between persistency units but, as far as architecture is concerned, local synchronization can be ignored since it can be managed by persistency units without calling on system resources.
Once again it must be noted that those constraints are set with functional requirements independently of their implementation.
Synchronization Policies
Symbolic synchronizations describe integrity constraints between time-dependent representations. As such they can be seen, and therefore represented, as qualified or weak integrity constraints as they introduce some tolerance regarding enforcement. Depending on the level on tolerance they can be supported by asynchronous communication mechanisms and rely on logical clocks, e.g calendars.
For instance, a repair is assigned to a mechanic and booked on a time slot which is meant to coincide (hence the composition) with a corresponding booking of the selected mechanic. Either the three links are created anew, or a previous mechanic’s booking is selected and the repair is booked accordingly.
Since actual synchronization will usually involve symbolic one as well, requirements should make explicit recommendations regarding synchronization policies: domain based policies are directly enforced at persistency level, use case based ones are managed by applications. Yet, whatever the policy, synchronization rules can be described through integrity constraints (symbolic synchronization) or by state machines (actual or symbolic synchronization).
On a broader perspective, symbolic representations should not be limited to current object states since more than often business objects can only be managed along their life cycle. Audit trail regulations provide an obvious justification but once looked for, time-related dependencies are ubiquitous, from finance to logistics, with planning in between.
Synchronization and Communication Mechanisms
Actual synchronizations constraints dictate how changes in actual contexts are to be mapped into system representations. Since those changes are signaled by external events, their processing must be dealt with through synchronous communication mechanisms and subject to physical clocks, e.g timers.
For instance, business requirements may stipulate that changes to vehicle status be recorded at the end of the day or without delay. While the former requirement sets no explicit bind between objects and representations, that’s not the case with the latter as events signalling actual changes must be processed in “real time“, namely no business should be allowed until the event is properly handled.
From Business Rules to Functional Requirements
If synchronization requirements, actual or symbolic, are to be consolidated, they must be expressed as functional constraints to be supported by system architecture.
To begin with, synchronization requirements must be expressed by rules with explicit targets, whether symbolic or actual. On that basis, it should be possible to derive (or check) requirements about entry points.
Then, one should take into account the distribution of entry points and clarify how changes are to be communicated across locations. That may be done through functional stereotypes for entry points and events associated to the capture, broadcast, and recording of changes across distributed systems
Finally, requirements analysis will have to reconcile all synchronization requirements on persistency and execution units into a functional architecture.