Context

POETS is a new architecture for ERP systems developed in the 3gERP project (3gerp.org) which is radically different from current state-of-the-art ERP systems. Two central parts of POETS are events and contracts. Contracts model “real” legally binding contracts. A contract stipulates what obligations and permissions the parties who have entered into the contract have. To state that a obligation has been fulfilled or a permission exercised, events are registered and checked against the relevant contract to see whether the event happened according to what is written in the contract. If the event was as expected by the contract, the system can continue while if the event was not as expected, the contract is said to have been breached.

Problem

In order to register an event with the POETS system, one basically need to fill out a form. A form contains a number of fields depending on the kind of event to be registered. For example a ‘Payment’ event has amongst others a field called ‘amount’ while a ‘Delivery’ event has a field called ‘goods’.

It is of crucial importance that the fields are filled out according to what is expected by the contract. In fact, even a small typo in a ‘name of customer’ field would cause the contract to become breached.

Cases

In many cases, however, the values to be filled out in an event-form are uniquely determined by the contract with which the event will be registered. I.e. the amount to be payed (as registered by a Payment event) has already been agreed upon, so the system could pre-fill the corresponding field in the payment-form.

In other cases, the values to be filled in are not uniquely determined but simply constrained by some ‘predicate’ in the contract. I.e. a sales contract may allow the buyer to pay the total amount over multiple events and thus, during any payment-event she should not fill in the ‘amount’ fill to more than what is remaining to be payed and never less than 0. In such cases, the system could restrain the possible inputs the user can make.

Finally, there are cases where the value of a field is neither uniquely determined nor constrained, but rather it is the case that a set of values are likely to be the ones that the user desires. Consider the example where the user is asked to fill out her contact information; the user might be asked to fill out fields such as ‘name’, ‘address’, ‘phone-number’. It is somewhat likely that the user has filled out those values before and therefore the system could do well to simply remember those values and allow the user to opt for allowing the system ‘auto-refill’ the fields.

Aim

In all of the three cases mentioned, the context of the form can be used to extract information about what information the system is expecting or allowing to receive via the form. Ultimately, the user should never be required to fill out fields, but merely act as a verification that the fields of the event-form correspond to what has actually occurred in the real world.

Student contribution

As a minimum, at the end of this project students should have done the following:

• Performed a study of what methods other people have applied in the context of helping users fill out forms
• Implemented a constraint solving program that can be used to pre-fill values for fields that are uniquely determined; the program should not be tied to a particular GUI framework.

Misc

The project can be scoped as a bachelor project and will be supervised by Jesper Andersen (jespera@diku.dk).