Millenium Rules!
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' [rtdue@ccinet.ab.ca]
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é
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
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.”
"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.
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.