![](bg4.png)
descriptions, it is possible to create intermediate
description layers that specialize and simplify the
architecture of CRISTAL, creating domain specific
modelling languages which can flatten the learning
curve for domain users and ease adoption. The
Agilium system mentioned in section 4 is an
example of such a system – it implements BPM as a
set of CRISTAL descriptions, and their clients can
design and develop applications based on this
simpler design language. Writing to the CRISTAL
object model is impossible from a client process
other than through an activity execution, thus
providing full traceability of the system. Ordinary
activities only create Events and Outcomes, and
modify Viewpoints, so when a script needs to
modify some other part of the model it must invoke
special ‘Predefined Steps’ which are activities that
contain additional logic for modifying the Item’s
Properties, Collections or directory entries. These
Predefined Steps are hard-coded and do not often
change, making their presence in an Item’s history
reliably interpretable. The aim of this rigidity of
write control is to require the design of the lifecycle
of each Item type to explicitly define the full
behaviour of that Item. We see this as a return to the
principles of object modelling that many modern
languages and platforms have neglected in the name
of “rapid prototyping”, whereas a properly designed
meta-model should achieve those without sacrificing
the principles of object orientation.
At a low-level, the versioning mechanism that
gives provenance to the Item instance is the same
mechanism that enables concurrent versioning in the
descriptions. This means that any communication
between different CRISTAL servers can transfer
descriptions in exactly the same way as instances.
Also dependencies can be declared as easily between
abstraction layers as within them. All of these
advantages arise because CRISTAL extends the
original object orientation concept ideas, to more of
its data model than other model-driven systems, in
the same way that Java gains similar advantages
from implementing classes as Class objects. This is
the real benefit of the CRISTAL Item-based design.
A disadvantage to the CRISTAL design is that the
definition of ‘Object’ in the CRISTAL system is an
Item which, while adhering to many core concepts
of object orientation, does not follow the classic
Class/Object model. This is because all
Descriptions, and instances of Descriptions, are
defined as Items in the CRISTAL model. This was
necessary to extend the traceability of the system to
its design as well as its operation, and to simplify the
styles of objects for developers to master.
Some developers in practice find the abstraction
concepts of CRISTAL conceptually difficult to
understand. This is due to the large amount of
terminology involved in the design of CRISTAL as
well as the complexity of its concepts. New
personnel faced a steep learning curve before they
could usefully contribute to the code-base, though
this is not a problem for end-users, as complexity
may be hidden in intermediate description layers.
However, we feel that Items represent a return to the
core values of object orientation, at a time when
modern languages are becoming increasingly
profligate in their implementation of them in the
name of efficiency, thereby sacrificing many of the
benefits that object orientation can offer.
Object-orientation encourages the developer to
think about the entities involved in the system and
the operations required to provide the system’s
functionality, along with their context in the data
model, which together provide the methods of
identified data objects, resulting in an object model.
In recent years, newer programming languages have
tended to focus on object orientation as a means of
API specification, increasing the richness of library
specification and maximizing code reuse, but do
little to encourage proper object oriented design
amongst developers. Unfortunately, with the
increasing popularity of test oriented development
methodologies, developers are encouraged to hack
away in a deliver-early-and-often way from which a
well-thought out object model rarely emerges.
In contrast with CRISTAL the object model must
be designed as a set of Items with lifecycles. While
other non-Item oriented software components are
possible, they cannot store state in the system
without interacting with Item activities, and
therefore are encapsulated as Agent
implementations, and considered external to the Item
model, with a strictly designed outcome
specification stating what they must provide to the
system to have successfully completed their
function. The activities of an Item’s lifecycle are
roughly analogous to object oriented methods, since
they define a single action performed on that Item.
However, it is much harder for an Item’s lifecycle
design to grow out of control with many unused
methods since the lifecycle is defined as a workflow;
the activity set must always form a valid graph of
activities from the creation of the Item to its
completion. This clarity of design through
implementation constraints is a return to the
intentions of the early object oriented languages
such as Smalltalk and the initial restrictions of Java,
which discouraged the developer from using
ENASE2014-9thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering
112