this is a
non-commercial
private Website
If you have any questions or remarks, please
This document describes the dynamical part of the IMA Model, specifically how an Engine processes (that is, is “programmed”) when performing a given Task. To view the scheme belonging to this document, please click on the above picture.
Original document by Fredrik D. Alink (1-10-2004)
Document revised on 1-9-2005
Task Processing
As stated before, the Model “runs” by processing Tasks on Engines. Tasks are organized into Work Orders. Work Orders can be scheduled in many ways by means of the Workflow Management facilities of the Scheduling Control Business Aspect.
Examples of IMA Work Order types:
  • Start: jumping from one Task to the other, facilitating all sorts of interrupts;
  • Any “normal” Work Order type to do things;
  • Mailing: mail messages are handled as a kind of Work Order with their own Scheduling facilities;
  • Data recording: this is done by sending specific Work Order types to a Computer Resource (not yet implemented in PROTO610);
  • Archiving: any Work Order to be archived is kept using a specific Scheduling facility.
Engines are “run” with an “actor” Resource responsible. Therefore, the User Type of the Resource defines to which Tasks the Resource is authorised. This authorisation is handled by the User Control Business Aspect.
To “run”, Work Order Tasks have to be “programmed”. That is, the Processes of all Tasks in the Work Order have to be defined. The definition of Work Orders is handled by the Process Control Business Aspect. Process Control has a Business Service to provide the Engine with an empty Work Order for the Task to be performed. If not defined othewise, the Work Order will start performing its own “start” Process.
Work Orders are used like a “normal” work order (the “work order” paradigm is one of the basics behind IMA), their objects, status, information and decisions kept into a file. In IMA these are called Work Order objects. As soon as a Task is started, the Work Order file is opened, that is, it's objects are made available to the Task's Process.
To be able to perform a Task, the Task's Process knows it's specific Services , Supports and Generic Model Elements (and related Business Functions) to be available.
Services are Task Process dependent and provided through the Task Process itself. They can be seen as sort of Desktop facilities. Examples are:
  • process manipulations;
  • object manipulations;
  • Business Server services.
An eventual result of a Service is reported back to the Process.
Supports are Process independent (backbone) services, provided by the Engine. Examples are:
  • interface manipulations;
  • clock tick generation;
  • generic defaults.
An eventual result of a Support is reported back to the Process.
Only the Business Aspects defined for the Task Process are activated (available as GMEs) during the performance of a Task and only the Business Functions defined for the Task Process can be used to address these GMEs.
For each event in the Process, an Action is defined. Events come to the Engine through the Engine's Interface or through any external Task Processes addressed to the Engine. Events trigger the Engine by the Action name to be performed.
An eventual result of an Action is reported back to the Process.
Any Action consists of a sequence of one or more Activities. An Activity normally points to a Support and through this to a backbone service. An Action can be conditional or not. In the first case, a condition has to be set first.
An eventual result of an Activity is reported back to the Action and through this to the Process.
Actions can be preceded by a sequence of one ore more Presteps and followed by a sequence of one ore more Poststeps. Both Presteps and Poststeps if present point to a Service and through this to a Process service.
Eventual results of Presteps and Poststeps are reported back to the Activity and through this to the Action and the Process.
line