-
Notifications
You must be signed in to change notification settings - Fork 5
Introduction
The idea of Description-Driven Framework was originated from the system called Cristal which was developed at CERN to manage the construction of the CMS/ECAL detector. Due to the scientific nature and the extended time-scale of the construction (10+ years), the users (physicists/engineers) wanted to gradually define and evolve detector elements, their data structures, construction steps and scientific calculations in order to produce the best possible device. In order to meet these requirements the team had to develop a system which could cope with change by design. Such unique constraint has inspired the research and development teams at UWE/CERN to design and develop a so-called Description-Driven System in which all logic and data structures have “descriptions” which can be modified and versioned to reflect changes required by physicists.
The original Cristal software was a fully functional Description-Driven System, it had to be configured and installed so it could be used like a CRM or WFM system. On the other hand the current version of cristalise-kernel offers building blocks to build fully functional description-driven system hence the name Description-Driven Framework (DDF).
The cristalise-kernel has packages to implement the description-aware functionalities common to many software systems. This list of packages is the result of careful and gradual re-factoring and abstraction of the original Cristal software elements.
Entity implements the fundamental building-blocks of DDF, like Object in an OO language.
-
Item is the heart of cristalise-kernel as it abstracts business objects and their logic into process-driven, version-controlled and document-oriented data that are managed on-the-fly for specific user domains. Item is fully audited as it stores all Events generated during the execution of its LifeCycle. Items are also communication end-points (CORBA) and have unique ids to lookup them in a distributed environment.
-
Agent is an Item with Roles to authorise it to execute the Steps defined in the LifeCycle of a given Item.
-
Property is a name and string value pair associated with Item or Agent. They are used for identification and typing, and for domain specific naming.
LifeCycle implements the process-driven aspect of Item. It holds the domain specific logic required by the business object. Currently it is implemented as a extremely flexible Workflow.
-
Composite Activity contains complete layout for all Activities (Elementary or Composite), connected in a directed graph that enforces the execution order of the constituent Activities.
-
Workflow, the top-level Composite Activity, is the container for all Activities in an Item. It resolves all activity paths from execution requests to individual Activities, and passes requests to them. Its also contains a list of non-persistent of PredefinedSteps (see next section).
-
Elementary Activity captures the parameters of each atomic execution step, defining what data is to be supplied and by whom. The execution is performed by Agents.
-
State Machine defines the
Outcome implements the document-oriented persistency aspect of Item.
Collection declares relationships between Items. Each collection has a name, and holds properties. Each Item is referenced by a Slot object, which holds additional properties about the link.
-
Aggregation
-
Dependency
The most important functionality of cristalise-kernel is the ability to read descriptions to initialise Item objects together with their constituting objects. In other words Item objects are instantiated from the Item class and are initialised from 'Description' objects. You may have noticed that in the section before there was no separate Description package because Description objects are Item objects as well.
----- notes bellow
PredefinedSteps to create create Items ...
Each Item is instantiated with a set of Properties created from the PropertyDescription outcome of its Description Item.
On creation, an Item contains no Events, Outcomes or Viewpoints. These are explicitly generated later during execution of its workflow processes. Initially an Item contains Properties to identify it, its Workflow and any Collections it may need, with all slots empty. The initial set of Properties are created in the process of rendering a property input form (which is user editable) by exploiting the Property Description (itself an Outcome stored in the Item Description), and submitting it as an Activity Outcome of the description Item. It is this standardised and managed treatment of the workflow-driven, version controlled 'Items’ that is novel in a description-driven system and enables the flexibility of such systems.
How Roles are defined and used to create an Agent???
Instantiated from a self-contained CompositeActivity Description Item.
The following paper explains the full concept of description-driven approach in great details:
- Getting started
- Key features
- Documentation
- Tutorials
- Basic: Create Patient
- Adv: Patient Tracking
- Selected papers
- Maven Deploy Travis
- Maven-Deploy-Travis-GPG2