[jwt-dev] Re: AW: Data element in AgilPro

[Steve.Egbert@xxxxxxxx]

Thank you Florian:

I am going to use the term data item to mean an individual instantiation of
a particular type of data. An individual variable, if you will.

I am going to conceptualize the data area as:
AgilPro:Data is a collection of individual data items, all of a common
type.
AgilPro: Parameter is an individual data item.

This means that if you had an application that had a method call with four
parameters:

AppCall(TypeA p1,TypeA p2, TypeB p3, TypeC p4)

we would need:
one AgilPro:Data of TypeA with two parameters
one AgilPro:Data of TypeB  with one parameter
one AgilPro:Data of TypeC  with one parameter
In order to perform this call.

I would tend to think that we should allow either:
one AgilPro:Data of TypeA with two parameters
or
two AgilProData of TypeA, each with one parameter
for the TypeA parameters,
and, in general, allow multiple parameters of the same type to be assorted
amongst multiple AgilPro:Data elements (all of the same type) as the user
sees fit.

I will proceed with my analysis using this view, assuming you concurr.

Regarding string and integer:
XPDL has 7 BasicType data types:
STRING
FLOAT
INTEGER
REFERENCE
DATETIME
BOOLEAN
PERFORMER
as well as 8 complex datatypes.

I think it would be more coherent to have these basic datatypes be a part
of the data type system, rather than have their own special element.
We could have a string element as it currently appears in AgilPro. To make
sense of this, we would have to consider it the sole parameter of an
implied Data that has a DataType of BasicType.String. I personally think it
is confusing to have a string element at the same level as the data element
but is basically equivalent in function to the data's parameter subelement.

Therefore, we should

Eliminate the string and integer elements at the AgilPro:Data element.
String and integer data items would be represented by parameters of an
AgilPro:Data element that has a DataType of string or integer.

or:

Have the data element represent an individual data item instead of a
collection of them. Each different data item would be a different
AgilPro:Data element, with a type and initial value specific to that data
item. This is essentially merging AgilPro:Data.Parameter into AgilPro:Data.
It would be roughly equivalent to allowing only one Parameter in each
AgilPro:Data element in the current model, and accepting the Data element
wherever you currently accept the Parameter. From your comments, this
appears to be how the AgilPro:Data element is curently being used in
practice. This would, in fact, corespond much more closely to XPDL.
AgilPro:Data would then directly corespond to XPDL:DataFIeld. In this
scheme, one AgilPro:Data element would map directly to one application
calling parameter. It would, however, make the technical diagram more
cluttered, as there woud be a separate Data icon for each individual data
item, or variable, that is used.

With such a modifiction of the model, having BsicType elements, such as
string or integer, at the same level as an AgilPro:Data element would make
some sense as a shortcut to the user. Instead of having to add a Data
element, and then set its DataType to string, the user could just add a
String element, which would be understood to be equivalent to the
aforementioned Data element. You could  even have the String element
actually be a Data element, except with the DataType being read only and
affixed to be string type.

Steve



                                                                           
             "Florian                                                      
             Lautenbacher"                                                 
             <florian.lautenba                                          To 
             cher@informatik.u         <Steve.Egbert@xxxxxxxx>             
             ni-augsburg.de>                                            cc 
                                       <emmanuel.rias@xxxxxxxx>, "'Java    
             04/24/2007 06:02          Workflow Toolbox'"                  
             AM                        <jwt-dev@xxxxxxxxxxx>,              
                                       <miguel.valdes-faura@xxxxxxxx>,     
                                       <Trent.Shue@xxxxxxxx>               
                                                                   Subject 
                                       AW: Data element in AgilPro         
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Hi Steve,

concerning the data element in AgilPro:

yes, currently only a data can have a specified datatype. For the current
execution / simulation of the models (in the integration framework), the
parameters and data mapping are not used right now. Therefore, the data
element also has an attribute 'value' where initial values e.g. are stored.


I agree with you that it would make more sense, if only the parameters and
the values of the parameters would be used. But I don't see many cases
where
the parameters of one data might have different data types. Then they
should
simply be grouped in different data. Therefore one datatype for exactly one
data and all of its parameters does make sense in my eyes.

I must also agree with you that the distinction between Parameter /
InputParameter / OutputParameter does not make too much sense, since an
InputParameter will always be an InputParameter, even if it is also the
output of another action. Henceforth, the InputParameter should only be
used, when this data is created by interaction with the user and is not the
output of another action and OutputParameter is only applicable when the
parameter is not used in any other action anymore.

The problem with this part of the meta-model is that it was designed
different than it was implemented and is now used in the modeller. We
thought that we will have one or more input/output data at one action and
each of these data contains a set of parameters. These parameters all have
the same datatype and are bound to the parameter of the application.

But our student developers simply took the data, gave them a value, did not
regard the parameter or the datamapping and when implementing the
simulation
they looked at the application DTO whether there was a method available
called set*Data.Name* and then invoked this method. So now, in the sample
models we always have data and no parameters. The problem with this
procedure is that when using two data with the same name it is not clear
how
these data should be mapped to the application. Therefore we introduced the
DataMapping in the meta-model for the parameters.

Concerning the AgilPro:StringType and AgilPro:IntegerType: they are
currently modeled as subclasses of PackageableElements, but should of
course
be subclasses of DataType. But since till now nobody used these primitive
datatypes, we will probably remove them from the meta-model (if you don't
need them for XPDL of course! ;-)

Best regards,

Florian