Millenium Rules!

Richard T. Dué, Thomsen Dué and Associates Limited, Alberta, Canada

Comment by Michael Gorman, Whitemarsh Information Systems, MD, USA

Abstract. Most Year 2000 system failures will be hidden from view. No one will want to air their dirty laundry. Corrupt databases, failed production runs, interface and network problems, and embedded systems malfunctions will all be handled in the same way errors have been handled for the past 50 years Š dig into the code, come up with some sort of solution that appears to work, and then go on to the next problem. However, because of the unprecedented scope and systemic nature of the Year 2000 problem, some failures will be very public. Failures in the so-called iron triangle infrastructure of telecommunications, utilities, and transportation will most likely occur in Europe, South America, and Asia. The cascading effects of these failures will spread throughout the entire world. Application system failures will most likely occur in the health care field and in smaller business and regional and local government organizations worldwide.

Full text in PDF format:


Dué, Richard T. Millenium Rules! Cutter IT Journal 12:8:14-18, August 1999.



From: Richard T. Due' []

Sent: Tuesday, August 31, 1999 5:06 PM

To: 'Jeff Sutherland'
Subject: RE: OOPSLA Position Paper

Hi    Jeff:I    just did a short position paper for Haim Kilov [OOPSLA’99 Semantics Workshop].    
I thought that you might be interested as well.
Richard    T. Dué    

Viewpoints, Invariants, And Epochs

Richard T. Dué, August 30, 1999

"There are no whole truths; all truths are half-truths. It is trying to treat them as whole truths that plays the devil." Alfred North Whitehead

  "The truth has never been of any real value to any human being-it is a symbol for mathematicians and philosophers to pursue. In human relations kindness and lies are worth a thousand truths". Graham Greene

The Problem

Truth, like beauty, is in the eye of the beholder. Unfortunately, none of today's Object-Oriented systems development methods recognizes the importance of the viewpoint of different observer of truth and beauty. Worse, all of today's methods suffer from the carry-over of the data-centric modeling approach of attempting to capture the semantics of a domain in a static representation of entities and relationships devoid of the perspective of the viewer. The class diagram, for example, displays static relationships among classes. These relationships equate to many of the invariants, or business rules of the domain (e.g., one customer can have many orders, but one order can only have one customer). Yet, there is no indication in this diagram of who establishes, owns, validates, or maintains these relationships. Neither is there any indication of the epoch, or period of time for which these relationships hold true. None of this mattered much during the past thirty years of independent, "green fields", custom application development. The invariants and epochs of these systems were typically small enough in scope to be assumed as common knowledge. Over time, however, emerging large-scale, enterprise-wide data modeling projects were delayed by weeks and even months in furious if fruitless debates over the semantics and business rules of what constituted a customer or an employee, or a sale. Instead of recognizing alternative viewpoints, data modelers attempted to resolve multiple viewpoints into a single version of the truth. There was simply no understanding that conflicting and even irrational viewpoints are unavoidable and often necessary within any organization.

The advent of reuse-in-the-very-large of common components or business objects requires that the invariants of the domain and their associated epochs be precisely specified in order to facilitate the reuse of appropriate components. This precise specification, however, will be complicated by the existence of multiple and often conflicting viewpoints, each of which have their own invariants and epochs. For example, in a business domain there may be several viewpoints that interpret the behavior of each object or collection of objects. A financial accounting viewpoint may have significant differences in its invariants from a management accounting or a taxation accounting viewpoint. Each of these viewpoints may be associated with different epochs or time-related versions of these invariants. One way of dealing with this situation that will hopefully eliminate the reenactment of the furious but futile debates of the data modelers in their search for the truth in their models is to "Allow for Many Truths.”

Allow For Many Truths

"If it swims like a duck, and quacks like a duck, and walks like a duck, it doesn't have to know that it is a duck."

The duck entity just needs to behave. Ornithologists, biologists, and little children will determine what is a duck from there own perspective. Indeed, the ornithologist parent of a little child may opt for kindness instead of truth by agreeing with his child that the duck is a "duckie" or even a swan. Invariants that describe or define relationships among components and objects should be categorized according to viewpoint. The same observer may have different viewpoints according the role they are currently playing as in the ornithologist parent above. There should be no attempt to reconcile different viewpoint interpretations of behaviour. There should be no futile quest to ultimately define the concept or Platonic form of "duck". Instead, the invariants of a particular viewpoint must be encapsulated within that viewpoint. Further, these viewpoints must be arranged into the versions or the epoch of each viewpoint. Perhaps as the little child grows up and becomes an ornithologist, he or she may have a new version of observation invariants.

 Model and Design with Interfaces

Domain modeling and application design should only be done in terms of interfaces. Design is too early in the process to begin working with components. The actual arrangement of components and objects that support these interfaces will be a run-time decision guided by design patterns and the design by contract approach. For example, in many business applications there is the need to schedule or allocate resources. Following today's Object-Oriented analysis and design methods, the scheduling behaviour could have been assigned to a "dispatcher" component, or the information model of the resource could have been programmed to schedule itself. The "Allow for Many Truths" approach describe here, however, means that scheduling is really the function of one or more viewpoints (e.g., schedule for maximum short term profit, schedule for emergencies, etc.). The domain model or application design, however, should not attempt to assign viewpoints to components. Instead, the contracts of each viewpoint should be developed and assigned to viewpoint interfaces. The actual assembly or construction of the components and objects that support these interfaces should be left to a particular run-time implementation. Perhaps the scheduling interface will be implemented by a façade or bridge or some other pattern of objects, but the actual implementation is no the concern of the modeler or designer. Indeed, the use of networked brokers and object transaction managers will not allow the a priori knowledge of which set of components will be used to implement the interface at run time.


The consequences of "Allow for Many Truths" and "Model and Design with Interfaces" are:

1. Elimination of the Class or Object Diagram from domain and design models. The static, one view of the truth presentation is not meaningful.

2. Conversion of the Object Interaction Diagram to the Interface Interaction Diagram. The designer is only concerned with the contracted interfaces of the system, not the components that may be subsequently involved in the interface's implementation.

3. Conversion of the CRC card technique to the IR card technique. The designer is now only interested in the responsibilities of the interface, not the underlying classes or components. There is no longer any need to show collaborators since this would require a single static view of the truth of the invariants of the underlying components. The responsibilities of the interface, however, should now be specified in formalized contracts.