|
|
Aim
To provide user configurable modelling tools. I-AKT
is intended as a general purpose multi-method, multi-view, multi-modeller
system. A process and activity domain modelling variant of this
called
I-PE
is being developed under the I-X research programme.
Introduction
AIAI has been performing modelling using multiple tools and
techinques for some time. The aim being to create a unified model from
the varous inputs. The model is anchored in one or more ontologies
which mighte be generic in nature as well as other ontologies relevant
to the application domain. Terminology appropriate for use in
the model is used. This approach is referred to as multi-perspective
modeling. It is an approach which is neutral to any specific
methodology or tool and can be used as a simple integrating framework.
It allows for knowledge sharing between models, and encourages
knowledge re-use by abstrating the model created away from any
specific methodologies or tools used in the model creation or
maintenance. The various methods and tools can be seen as providing
limited views or perspectives onto the shared model.
AIAI has done practical modelling work using such a multi-perspective modelling approach. For example, on the DARPA/Rome Laboratory Planning Initiative (ARPI) in modelling the US Air Campaign Planning Process and with DARPA on the creation of an Air Operations Enterprise Model. It has also used Multi-Perspective Approaches to generate and reason about plans in the O-Plan work under ARPI. Typical multiple perspective modelling approaches have created a single ontologically underpinned model using AIAI's work on ontologies for processes or for enterprises and have utilised several modelling methods from Europe (such as CommonKADS - itself combining a number of perspectives), the UK (such as Role/Activity Diagrams), and the USA (e.g., IDEF-3).
We are promoting a knowledge modelling approach in AKT which is thought of as a synthesis of the model from multiple human and system sources using any modelling methods and approaches or tools. This would build "nodes" in the model as appropriate to the domain, and build constraints on those nodes. It would maintain a set of outstanding modelling issues. It would use terminology in a domain ontology that was being concurrently defined alongside the modelling, so it itself would be a result of the modelling. It would allow a wide range of reasoning approaches and sub-solvers to be employed as appropriate to the tasks being conducted being found through the use of a capability description that allowed access to the library of capabilities (e.g, agent capabilities or problem-solving method libraries).
Multiple-view or multiple perspective modelling is viewed in the software engineering, data base and requirements capture communities as a valuable technique.
I-AKT - Modelling Support in the I-X Framework
AIAI has been moving towards an approach to supporting the modelling
process involving one or more modellers based on its I-X systems
ingtegration architecture (details at http://www.aiai.ed.ac.uk/project/ix/architecture.html)
which is designed for synthesis task support. It views modelling as
the task of synthesising one or more models. The models are viewed as
having "nodes" (the principal entities in the model), constraint on
and between these nodes, and a set of outstanding issues in the
model. A system implemented in this framework would use a range of
methods or tools, and create a (normally, but not necessarily, single)
shared model based on one or more generic ontologies or conceptual
models. The terminology in the model is anchored in one or more
lexicons. The ontologies and lexicons can be developed during
modelling - but this is normally done on a longer timescale revision
process which itself can be supported by the same I-X approach.
The modelling process and colaboration support is provided by the creation of an agenda of outstanding modelling issues. These could have come from the modellers noting such issues as they progress in their process of creating the models, or they could have been raised (perhaps by automated tools) as a result of model analysis and critiquing. These could be handled manually, or may eventually be able to be handled by seeking issue handlers which will select appropriate methods or tools to help the modeller(s) address the outstanding issues. Domain constraints can be established that apply to the models being created during the modelling process itself, and they can be utilised to guide the process and constrain the legitimate models which can be built.
Sample methods AIAI has used in a multi-persective modeling framework are:
Lexicons that are being used to anchor models have come from:
The <I-N-CA> constraints model is a means to represent synthesised or designed artifacts as a set of constraints on the space of possible designs. By having a clear description of the different components within a synthesised artifact, the model allows for them to be manipulated and used separately from the environments in which they are generated.
The constraints which add a node (these are in the form ``include node'') in the <I-N-CA> model set the space within which the description of the artifact may be further constrained.
The I (issues) state the outstanding items to be handled and can represent unsatisfied objectives, problems which analysis has shown need to be addressed, etc. The I constraints can be thought of as implying further constraints which may have to be added into the design in future in order to address the outstanding issues.
The CA constraints restrict the relationships between the nodes to describe only those artifacts within the design space which meet the requirements. The constraints are split into "critical constraints" and "auxiliary constraints" depending on whether some constraint managers (solvers) can return them as "maybe" answers to indicate that the constraint being added to the model is okay so long as other critical constraints are imposed. The maybe answer is returned as a disjunction of conjunctions of critical constraints.
The use of "maybe", delayed and/or conditional constraint results from problem solvers is common in AI planning where one of the main world state condition/effect solvers many of us use is the modal truth criterion (MTC) based on Tate's work on the Nonlin "QA Algorithm" in the mid 1970s. This established whether some condition was satisfied at some point in a partial ordering of activities in a plan. In later Edinburgh planning work, the same interface is used a general model for constraint solvers being plugged into a planner - or indeed any synthesis system.
For example, if the product or artifact is an activity plan, some types of ordering (temporal) and variable (object) constraints are distinguished from all other auxiliary constraints since these act as critical constraints or cross constraints, usually being involved in describing the others -- such as in a resource constraint which will often refer to objects/variables and to time points or intervals.
Issues can be categorised as to whether they will, may or will never add a "node". The I constraints which can lead to the inclusion of new nodes are of a different nature in the synthesis process to those which cannot.
The choice of which constraints are considered critical is itself a decision for an application of I-X and I-Core. It is not pre-determined for all applications. A temporal activity-based planner would normally have objects/variable constraints (equality and inequality of objects) and some temporal constraints (maybe just the simple before(time-point1, time-point-2) constraint) as the critical constraints. But, in a 3D design or a configuration application object/variable and some other critical constraints (possibly spatial constraints) might be chosen. It depends on the nature of what is communicated between constraint managers in the application of the architecture.
The types of constraints in an <I-N-CA> model is shown below:
A number of concepts are being used as the basis for exploring task orientated multi-agent and mixed-initiative work involving users and systems. Together these provide for a shared model of what each agent can and is authorised to do and what those agents can act upon.
I-PE - Process Modelling Support
The initial focus of AIAI's activities is in the creation of a process
editor for a number of on-going projects.
Initial work is focussed on the creation of shared Java code that can be used as the heart of a simple process editor and that can take input from a range of sources and produce output in the <I-N-CA> ontology as a set of constraints on a synthesised artifact. This should establish a number of assets that will be useful in building the more general I-AKT multi-perspective modelling support environment:
I-AKT Multi-Perspective Modelling Framework
The aim is to move on to create a general purpose modelling support
environment that can incorporate a wide variety of different methods,
tools, representations, repositories and user interfaces. The I-X
framework would be used to provide an outer shell or approach into
which various experimental and mature system and methods from the AKT
consortium could be fitted as needed, while retaining a simple overall
approach. The environment would start with support to a single
modeller, but eventually grow to allow for multiple modellers working
collaboratively to create and maintain shared models.
It should be noted that the I-AKT framework could in fact be used purely manually and not be the subject of computer support at all. It provides a very lightweight approach to model creation in this respect.
| AIAI | AKT | AKT Edinburgh | I-X |
Page maintained by a.tate@ed.ac.uk,
Last updated: Tue May 1 09:57:46 2001