I personally see a process as a sequence of activities, so I go for the imperative paradigm. But in the last 5 years, I have come across a lot of work on declarative processes. I am still not convinced that declarative processes are intuitive. Can anyone please explain if I am wrong?
Are processes imperative or declarative? Interesting question, which I didn't ask myself until now. Aside from that, why is this important, or does the answer has any aftereffects?
In my opinion it depends on the specific process. Sottware process, biotechnological process, business process, legal process ... and also how detailed you look into it. For example: Bioprocess control -> process controller sets temperature declarative (to some value). On a more detailed level the signal processing becomes imperative (I would think): Cooling system ON or OFF. Isn't that the same as for programming languages? Ultimately, any language will be translated in machine language for the CPU to understand, which can only compute imperatives.
But your question was: Are declarative process intuitive? In my opinion YES (and NO). The explanation is the same as above, it depends on the person and the process. I am teaching students how to program. At first they do it in a declarative manner only, because they know what they want to achieve, but not exactly how. While learning more about programming languages or how to solve a specific problem with an algorithm their activities become more and more imperatively.
That is an interesting perspective, whether being declarative depends on the kind of process or not? Even though my focus is more towards business processes and software development processes, I guess all the processes are some how imperative in nature.
When we look to the objectives and goals of a process, they specify what is to be achieved and have no indication to the "how" aspect. A process in my opinion is specified to show this "how". That is the reasons we talk about flows, milestones, etc.
On the other hand, some recent works on declarative process modeling suggest that it adds flexibility to the process model. I argue that this flexibility compromises the "how" aspect, which is the main objective to specifying a process.
That is a very interesting question, which we investigate for a while! In order to create a more clear terminology, we name two paradigms: 1) activity-based and 2) artifact-based processes (explanation in short words follows).
In the activity-based paradigm (this is what you call imperative), the focus of the process is the activities (the methods) to carry out certain tasks. A process is then defined by a sequence of activities (a workflow). Artifacts, which represent any piece of produced/consumed data in a project, are the inputs and outputs of activities. Dependencies between artifacts are expressed by the combination of activities in the workflow.
In the artifact-based paradigm (this is what you call declarative), the focus is the artifacts. Artifacts have type, structure, content, responsibilities, and dependencies among each other. For every artifact, there are several methods that can be used to create the artifact, e.g., a requirements spec can be created using plain text, structured text, diagrams and models, and so forth. That is, a process is defined by a set of artifacts to be created, and a context-specific selection of appropriate methods.
What we learned so far:
- There is no absolute distinction between these paradigms; you always have a mixture.
- Activity-based processes better reflect the way of work.
- Artifact-based processes provide better means to assess project outcomes.
- Artifact-based processes are more flexible, as one can select different methods to create an artifact.
However, in an experiment, we learned that artifact-based approaches are easier to analyze, design, and implement processes (which means: this paradigm seems to better support SPI projects), while process users do not care, and prefer more detailed guidance. Experience from practice also shows that artifact-based processes are more difficult to teach, as they require a certain level of abstract thinking.
So, are declarative more intuitive? It depends. For just enacting a process in a project, the imperative process is more intuitive as it contains more guidance. If you have to analyze and design processes, then the declarative approach is more intuitive as you can talk about process artifacts, their properties, and so on. In the end, neither is simple. It always depends on the users and their intention.
Conference Paper Who Cares About Software Process Modelling? A First Investig...
I like this categorization of process models as activity based and artifact based. But my argument is that in both these categorizations we follow the sequence either for control-flow or data-flow. If we are following the sequence in either of these approaches, then it is somehow impertive process modeling. Artifact based process modeling is more constraint-based where we can choose amongst multiple (implementations of an) activity. But we can not alter the natural sequence of the activities.
In my point of view, declarative process modeling on the other hand decides the sequence of the activities on runtime rather than choosing between multiple activities to do the job (produce the artifact)).
And it is in this perspective, that I find declarative processes less intuitive.
- Badges
- Science topic
- Similar topics
- Engineering
- Petroleum Engineering
- Oil