- To develop sofwtare, a software development process is needed.
- A process is described by a process model.
- A process model is defined with a process modeling language.
What elements should a process have?
I don't know if you think that this is obvious or not, but I have known process models in which artifacts wheren't represented. Their templates (Word or Excel templates) were modeled instead, but not all the workproducts are Office documents (for example, an incidence registration is a workproduct without a document tempate), so they were forgiven in the model since they don't have a template. It's very important to represent the artifacts and give them a name beacuse all the stakeholders should know the more relevant workproducts in the process (documents or other kind of results). How do you define quality controls over artifacts if you don't represent them? (You can't).
How are process modeling languages categorized?
The paper explains the one process modeling language can be categorized into one or mor lingguistic paradigms. It alto describes them and gives some interesting examples on languages based on each of them (I recomend you to take a look). This linguistic paradigms are:
- Rule-Based Paradigm: do you know CLIPS (I'm preparing an entry related to this...) or PROLOG? These are rule-based programming languages. There are many process modeling languages based on this paradigm: roles are associated with rules; these are compound by a an action (what the activity does) and a precondition and a postcondition (the specification of the activity). Real world problems can be resolved by planning. Not good for expressing process topology.
- State-Based Paradigm: this is good for expresing process topology beacuse it's visual.. Many complex constraints can be represented (nondeterminism, concurrency...).
- Functional-Paradigm: complexity can be controled by hierarchical process decomposition. The paper mentions a example language, HFSP, which uses grammar rules to decompose activities; a very interesting approach.
- Procedural Paradigm: the control flow is specified like in common programming languages.
- Object-Oriented Paradigm: a process is a net of interacting objects. A language called UML is an example mentioned in the article... Object-Orientation is more appropiate for modeling artifacts.
According to the paper, two words would summarize this: Evolution Support. This is essential; think about a static Business Process Model (BPM) of an Organization. The Organization will always stay the same? I think it won't... So a Process should evolve, allowing Business Process Reengineering (BPR). But, how can a process support its own evolution? There are four mechanisms:
Genericity
It should be easy to change a process in the future. A process is really a family of processes that must be refined or instantiated in order to evolve to an actual process. Functional paradigm gives genericity easily.
The paper propose a research about higher-order functions as the mechanism to allow modeling languages to support genericity. I would like to think a little about this... Think about a process called approve_requisites_document(reqDoc:Document); if we could use higher-order functions in the modeling language, we would be able to define this function instead: approve_document(doc:Document,approveFunc:Function), and this way it would be very easy to add or change documents and/or their associated approvements.
Reflection
The process may be able to change on the fly, to change itself by means of a built process or meta-process and meta-elements; the process should be self-adaptable. Think about using languages based on rule-based or functional paradigms to define a process with reflection support.
Take a look at the picture on the left. The process should contain a process that would transform the whole process; we could call it the "Process Transformation" process. So it's a meta-process (a process that knows, works with and operates with the Process). As we mentioned before, a process built artifacts; both process and its artifacts are supported by a set of process assets (procedures or document templates, for example) called a Process Assets Library (PAL). The "Process Transformation" process' artifacts may be a process or a process asset, so that's why we are talking about a meta-process. This way, the Transformation Process uses feedback from the whole process in order to adapt it.Exception handling
Don't make the process so complex, define exceptions to handle abnormal cases that you can predict during process modeling. Exception handling mechanisms, as mentioned in the paper, can be block-oriented (frequently in languages based on procedural and object-oriented paradigms) and rule based (guess it...).
Deviation (first) and inconsistency (later) support
What about unexpected situations? The observed process should be able to diverge. Some inconsistencies may be created, so the process should allow to resolve this incosistencies and return to an adecuate state. The paper explains how an example modeling language does this. Languages based on the rule-based paradigm are more suitable for supporting this feature.
That's all for today
I think we've talk about many interesting things about modeling languages... Before start modeling the process, we should think about what features should the process model have according to the business domain. So, first of all, we should define or choose a process modeling language that allows us to build a process with such features. It's important to support Process Evolution by means of its genericity, reflection and exception handling, deviation and inconsistency support, so it's a good idea to choose the more suitable paradigms in order to provide this mechanisms.
Today's questions
What's your opinion? Do you think that it's important to care about modeling languages?
I'd also like to ask you about your experiences in process modeling. What languages / paradigms have you used? What tools for defining the process? What Process flow engine?
