Herman Balsters: Python in Processes, data, contracts

See the PyGrunn website for more info about this one-day Python conference in Groningen, The Netherlands.

I am going to talk about modelling. Process modelling and data modelling. My colleague Henk Doornbos will give a more detailed technical talk after this.

Many ICT systems do not work, a lot of projects fail. Dutch government loses about 5 billion euros a year on failed projects. Expected functions are not provided, and offered functionality is not wanted. For example medical patient information systems.

Main cause of failure: the initial design does not match the end-user requirements.

Possible solution: model driven approach (MDA). You can see models as very high level programming constructs. You might think of UML. But let's revisit this.

Wittgenstein: Don't ask for meaning (of data) but of its use.

Our process: start from business process models (our context) and derive data models, mostly automatic.

Validate your models. The only real correctness is end-user correctness. Capture the main requirements from experts. Anyone can write a model, but how do you know it is correct. UML class diagrams are hard to read and write. Instead, we use a structured natural language that is easy to validate by domain experts.

Are the requirements consistent and complete? Go through it in cycles. Do they converge to a stable model? Models are assumptions about how the domain expert would like to do her job. Try to invalidate the model, hunt for false assumptions.

We use business process modeling and notation. Many modeling primitives, of which we have chosen a subset of eight. Process is a collection of pools. Pool has swim lanes for each stakeholder.

Clients learn the notation pretty quickly. We stick as close as possible to the domain expert's language, which may just be Dutch.

High level overview of a process flow:

• You start
• code the input
• process/transform the input
• decode the output
• stop.

Fact-based modeling approach. Get data. We talk about objects and facts. Facts are sentences that are true or false. The European Space Agency uses this approach for their satellites.

Our flavor of that approach is OLE: Object and Logic-based English. Structured natural language. Better suited than graphical models for validation by domain experts. It is very precise and expressive. OLE can be compiled a prototype to pyDatalog for example. From the site: pyDatalog adds the logic programming (think: the prolog language) paradigm to Python's extensive toolbox, in a pythonic way. More about that in the next talk in this room.

An activity may be coded as for example six statements. Activity A is on Date D. Start Event E leads to Statement S. Entity Type T is identified by Number N. Things like that.

We are using this for a contract system. Contracts are built from small initial building blocks. They are combined recursively into a kind of algebra for contracts. That is turned into a pyDatalog program.

The data modeling part is difficult when you are not used to it, but clients can come up with activities themselves and will spot errors in the logic. They may find out that their own process is more difficult than they previously thought. Or they discover that they do it differently than their colleagues.

How good is this when the process later needs to be adapted? We identify which part of the process needs a change. Change the model, compile that part again.