|
|
(C) 1997 Lorrie Boyd, AMS Inc. Presented with kind permission.
Problem
In business systems, many of the necessary objects are easily
identified because they represent tangible things in the real
world. These are the static objects. At the same time, the associations
between these objects have information and behavior of their own.
How can the associations and movements between these static objects
be identified?
Context
Many business systems are about changes or movements of tangible
items over time. Some examples are: scheduling systems, assignment
systems, and inventory tracking systems. The events in such systems
cause associations between static objects to be created, modified
or destroyed. An association may change from describing future
plans to describing current state or history. The association
may behave consistently whether future, current or historical.
Consider the analysis phase in a system to assign rooms within
a large facility. We need to assign rooms to departments. The
computer system centers around managing the change of assignments.
When a room is assigned, does the user need to know the previous
assignments? Are assignments planned, and how does a planned assignment
become the current one? What changes about the room when it is
assigned to a department? What changes about the department when
it is assigned to a room? How often does an assignment happen?
Understanding the assignment is key to developing a solid design.
Forces
- If we only examine the current state of an association, the
relationship between two related objects is often simple. For
example, today a room 'has a' department. But when we add history
or planning, the nature of the relationship changes. Over time,
a room 'has many' departments. All three states may have similar
behavior and data which are of interest to the business.
- The current state, which is merely a 'has a' relationship,
may be all the business needs to know. Planning may be done very
vaguely, and history may simply be reported.
- Integrating history, planning and current all in one approach
will increase quantities of information stored and accessed.
This may have a significant negative performance impact.
- Separating history, planning and current associations may
increase the amount of code needed and introduce artificial differences.
Solution
Define an association object capturing the date and time of
the association. Examine the lifecycle of the association. What
changes during its lifecycle? What kinds of events trigger the
changes? An association object is needed if the association has
behavior of it's own over time.
Determine attributes and responsibilities unique to the association.
For example, costs for one object may be allocated among the set
of associated objects.
Determine if there is a performance impact by capturing details
of each association and whether different users of the association
access it in the same way.
A key point is that association objects capture the changing
states of associations, not just the changes in associations.
That is, when a room is re-assigned, the old association becomes
a former one (i.e., history) and the new one becomes current (it
was a future assignment). This allows the system to act as a 'time
machine' because it can answer queries relative to any point in
time, not just the current one. This integration of planning,
current state and history within a single object, can eliminate
the need for wholly separate systems.
Illustration of solution:
In this class diagram, there can be many instances of the association
class for each unique combination of STATIC 1 and STATIC
2. When the association Begin_Date and End_Date are
both in the past, the association represents history. When
the association Begin_Date is in the past, but the End_Date
is in the future, the association represents current state.
When the association Begin_Date and End_Date are both in
the future, the association represents planning. Thus the
association integrates history, current and planning in
one object. All three states share the same responsibilities and
attributes.
Example
This illustrates a room assignment functional model. There
can be many ROOM_DEPT_ASSIGNMENT instances for each combination
of ROOM and DEPARTMENT. Historical assignment instances have both
dates in the past, current ones have a Begin_Date in the past
and an End_Date in the future, and planned ones have both dates
in the future.
Analysis which verifies the need for this use of an association
object includes:
- The maintenance staff cares about the current assignment.
They use it to contact the owner before fixing the room. The
accountants, however, care about the history of assignments.
They use assignment history to calculate indirect costs.
- A new assignment is created whenever a room is re-assigned,
whether the assignment is planned for the future or is effective
immediately. The planned assignment becomes the current one.
The current assignment becomes history.
- Costs for a room are allocated among its assigned departments
according to a percentage. That is, a room may be used by several
departments concurrently with each department charged a percent
of the room costs.
Known uses
Peter Coad named this a 'timed association pattern' (ref 1).
In addition, Martin Fowler (ref 2) describes these as objects
representing 'actions' which can be 'scheduled, resourced, peopled,
started and completed' in discussing planning. He also describes
the associative type, when relationships themselves acquire attributes
and behavior; and historic mapping, in which the objects capture
history. Each of these are examples of the association object.
[ Previous | Up
| Next ]
|
|
|