Re: Partial modeling using constraints

>
>1. Partial modeling using constraints.
>
>    The constraints can be pre/post conditions, but also dependencies among
>    actions (temporal, causality, etc.)


I would argue for a very general view of constraints as "anything which 
constrains the performance of the nominated activities". A process model 
would be simple

1.  a set of nominated activities

2. a set of constraints for this et of activities. This would allow for 
great extensibility in future, but also allow us to provide nominated 
sub-classes of constraint which can be handled in simpler models more 
automatically.

3. a set of annotations related to these - to capture rationale and other 
things.


>    The need for modeling using constraints arises in the following two
>    situations (amont others -- please supply):

We can get many requirements from the NIST PSL requirements document
    * Schlenoff, C., Knutilla, A., Ray, S., 
<http://www.nist.gov/msidlibrary/summary/9660.html>Unified Process 
Specification Language: Requirements for Modeling Process, NISTIR 5910, 
National Institute of Standards and Technology, Gaithersburg, MD (1996).
      See http://www.mel.nist.gov/msidlibrary/summary/9660.html

An analysis of candidate representations (valid at the time - 1997) to meet 
these requirements was performed for NIST by us
    * Polyak, S., Tate, A., 
<http://www.nist.gov/psl/pubs/97-nist-psl-phase2.ps>Analysis of Candidate 
PSL Process/Plan Representations, AIAI-PR-66, Artificial Intelligence 
Applications Institute (AIAI), Edinburgh, 1997. (PS file)
      See http://www.nist.gov/psl/pubs/97-nist-psl-phase2.ps

>    Examples of temporal and causality constraints:
>
>         events A and B must both occur.
>         if event A occurs then event B or C must also occur (before or 
> after B).
>         if both A and B occur then A must occur before B.
>
>    The other kind of constraints deal with resource allocation. For
>    instance, one might want to see if a service can execute under certain
>    cost constraints (time is viewed as one kind of a cost).
>    Resource allocation constraints are very different from causality
>    constraints, and the formalisms for handling them are quite different,
>    too.


Our own work identified a taxonomy of constraint types based on the 
following 3 kinds.  The first two are pretty much essential and will be 
present in anything claiming to be an activity/process model.  The rest can 
be treated as optional and only needed as required.  This is vital to 
getting an extendable and engineering approach to being able to maintain 
and extend this - much like the partial shared views in NIST PSL does.

a) object/variable constraints (codesignation and non-codesignation / 
equality and inequality of objects).

b) temporal constraints - on time points - which can be associated with the 
begin and end of any activity as well as with "dummy" nodes put in to ease 
the temporal constraint expression - this is common in process modelling or 
when using a graphical tool.  Simple "before tp1 tp2" constraints are 
always needed and are in NIST PSL Core. Extensions allow for a much wider 
range of James Allen style temporal relations and metric.calendar temporal 
constraints.

c) a range of other constraints that can be extended on need.  This can 
include:

    c.1) world state constraints - this is where input and output 
constraints, (pre-)conditions and effect (post-condition in its simplest 
form) can be stated

    c.2) resource constraints - including an improtant subtype of 
"performer" (i.e. actor) constraints

    c.3) spatial constraints

    c.4) quality constraints

    c.5) etc., etc.

Austin

Received on Wednesday, 30 April 2003 12:29:13 UTC