Meta-process modeling focuses on and supports the process of construction Process Models. Its main concern is to improve process models and to make them evolve, which in turn, will support the development of systems . This is important due to the fact that “Processes change with time and so do the Process Models underlying them. Thus, new processes and models may have to be built and existing ones improved” . “The focus has been to increase the level of formality of process models in order to make possible their enactment in process-centred software environments” referring to .
A process meta-model is a meta model, “a description at the type level of a process model. A process model is, thus, an instantiation of a process meta-model. [..] A meta-model can be instantiated several times in order to define various process models. A process meta-model is at the meta-type level with respect to a process.”
There exists standards for several domains:
(Example Plihon 1995 in NATURE and repository of scenario based approaches accessible on Internet in the CREWS project )
“For the assembly technique to be successful, it is necessary that process models are modular. If the assembly technique is combined with the instantiation technique then the meta-model must itself be modular.”
Process models are then derived from the process meta-models through instantiation. Rolland associates a number of advantages with the instantiation approach:
“The instantiation technique has been used, for example, in NATURE , Rolland 1993 , Rolland 1994 , and Rolland 1996 . The process engineer must define the instances of contexts and relationships that comprise the process model of interest.” .
as well as further computational paradigms:
“Languages are typically related to process programs whereas instantiation techniques have been used to construct process scripts.”
Example tools for meta-process modeling are . :
Besides the CREWS-L’Ecritoire approach, the multi-model view has served as a basis for representing : (a) the three other requirements engineering approaches developed within the CREWS project (Real World Scenes approach , SAVRE approach for scenario exceptions discovery , and the scenario animation approach ) (b) for integrating approaches (one with the other and with the OOSE approach )
Furthermore, the CREWS-L’Ecritoire utilizes Process Models and Meta-Process Models in order to achieve flexibility for the situation at hand. The approach is based on the notion of a labelled graph of intentions and strategies called a map as well as its associated guidelines . Together, map (process model) and the guidelines form the method. The main source of this explanation is the elaboration of Colette Rolland in .
The map of the CREWS-L’Ecritoire method looks as follow:
The map consists of goals / intentions (marked with ovals) which are connected by strategies (symbolized through arrows). An intention is a goal, an objective that the application engineer has in mind at a given point of time. A strategy is an approach, a manner to achieve an intention. The connection of two goals with a strategy is also called section.
A map “allows the application engineer to determine a path from Start intention to Stop intention. The map contains a finite number of paths, each of them prescribing a way to develop the product, i.e. each of them is a process model. Therefore the map is a multi-model. It embodies several process models, providing a multi-model view for modelling a class of processes. None of the finite set of models included in the map is recommended ‘a priori’. Instead the approach suggests a dynamic construction of the actual path by navigating in the map. In this sense the approach is sensitive to the specific situations as they arise in the process. The next intention and strategy to achieve it are selected dynamically by the application engineer among the several possible ones offered by the map. Furthermore, the approach is meant to allow the dynamic adjunction of a path in the map, i.e. adding a new strategy or a new section in the actual course of the process. In such a case guidelines that make available all choices open to handle a given situation are of great convenience. The map is associated to such guidelines” .
Three types of guidelines can be distinguished:
In our case, the following guidelines – which correspond with the map displayed above – need to be defined:
Intention Selection Guidelines (ISG)
The following graph displays the details for the Intention Selection Guideline 1 (ISG-1).
The following graph displays the details for the Strategy Selection Guideline 1 (SSG-1).
Intention Achievement Guidelines (IAG)
The following graph displays the details for the Intention Achievement Guideline 8 (IAG-8).
While the meta-process model can be represented in many different ways, a map was chosen again as a means to do so. It is not to be mixed up with the map for the process model as presented above.
Colette Rolland describes the meta-model as follow : (Meta-intentions are in bold, meta-strategies in italic – in green in the map).
“The Start meta-intention starts the construction of a process by selecting a section in the method map which has map intention Start as source. The Choose Section meta-intention results in the selection of a method map section. The Enact Section meta-intention causes the execution of the method map section resulting from Choose Section. Finally, the Stop meta-intention stops the construction of the application process. This happens when the Enact Section meta-intention leads to the enactment of the method map section having Stop as the target.
As already explained in the previous sections, there are two ways in which a section of a method map can be selected, namely by selecting an intention or by selecting a strategy. Therefore, the meta-intention Choose Section has two meta-strategies associated with it, select intention and select strategy respectively. Once a method map section has been selected by Choose Section, the IAG to support its enactment must be retrieved; this is represented in [the graph] by associating the meta-strategy automated support with the meta-intention, Enact Section.”
The following table displays the stepwise trace of the process to elicit requirements for the recycling machine (from ):
|Step||Guideline||Meta-process||Process||Product (Goal = Gxx)|
|1.1||SSG-4||Choose section with select strategy||SSG4 suggests two strategies. The template-driven strategy is chosen because it is the most appropriate way to become familiar with the goal formalisation proposed by the CREWS-L’Ecritoire method|
|1.2||IAG-6||Enact section with automated support||IAG6 displays a goal statement template and explains the meaning of each parameter. The requirement Engineer (RE) chooses a loose statement having only a verb and a target||G1: Provideverb (Recycling Facilities*) target *RF|
|2.1||ISG-1||Choose section with select intention||ISG1 provides RE with arguments to advise him on choosing one of the two possible intentions from Elicit a Goal, namely to Elicit a Goal or to Write a Scenario. The former is selected so as to generate alternative design solutions|
|2.2||IAG-1||Enact section with automated support||IAG1 uses the goal statement structure and parameter values supplied to generate alternative goals. This leads to 21 alternative goals to G1 which are ORed to G1. After discussion with stakeholders, G4 is selected||G2: Provide bottle RF to our customers with a card-based machine; G3: Provide paper RF to our customers with a card-based machine; G4: Provide bottle and box RR to our customers with a card-based machine; . . . G22: Provide bottle RF to all customers with money return machine|
|3.1||SSG-3||Choose section with select strategy||SSG3 offers two strategies from which the template-driven strategy is chosen. This is because there is uncertainty about what a scenerio should be. The templates lead to some certainty|
|3.2||IAG-7||Enact section with automated support||IAG7 proposes a template to be filled in. The template corresponds to a service scenario and contains actions that express services expected from the system||SC4: If the customer gets a card, he recycles objects|
|4.1||SSG-2||Choose section with select strategy||SSG2 offers two strategies to conceptualise a Scenario. Among the two strategies, manual and computer based, the former is chosen since the service scenario (SC4) is very simple and can be handled manually|
|4.2||IAG-10||Enact section with automated support||IAG10 suggests two things: (1) to avoid anaphoric references such as he, she, etc. (2) to express atomic actions in an explicit ordering (3) to avoid ambiguities The scenario is rewritten accordingly||SC4: 1. The customer gets a card; 2. The customer recycles boxes and bottles|
|5.1||SSG-1||Choose section with select strategy||The RE knows that he wants to analyse the scenario SC4 to discover a new goal. Thus, he knows the target intention ‘Elicit a Goal’ and SSG1 is displayed. SSG1 offers three strategies to discover new goals from scenario analysis. The refinement strategy, is chosen because there is a need to discover the functional requirements of recycling machine|
|5.2||IAG-4||Enact section with automated support||IAG4 guides in transforming actions of the service scenario SC4 into goals which express functional requirements. Two goals are generated and related together to G4 with an AND relationship. G24 is selected for further processing||G23: Get card from supermarket; G24: Recycle bottles and boxes from RM|
|6.1||SSG-3||Choose section with select strategy||The RE knows his target intention, namely ‘Write a Scenario’. Thus SSG3 is displayed to help the RE in selecting the right strategy. The free prose strategy is selected because the text is likely to be long and the free prose facilitates this|
|6.2||IAG-8||Enact section with automated support||IAG8 provides style and contents guidelines adapted to the type of scenario at hand, namely system interaction scenario||SC24-1: The customer inserts his card in the RM. The RM checks if the card is valid and then a prompt is given. The customer inputs the bottles and/or boxes in the RM. If the objects are not blocked, the RM ejects the card and prints a receipt|
|7.1||SSG-2||Choose section with select strategy||SSG2 is displayed. The automated support strategy is selected to take advantage of the powerful linguistic devices and obtain a scenario formulation which will be the basis for automated reasoning|
|7.2||IAG-9||Enact section with automated support||IAG9 semi-automatically transforms the initial prose into a structured text whose semantics conform to the scenario model. The transformation includes disambiguation, completion and mapping onto the linguistic structures associated to the concepts of the scenario model. SC24-2 is the result of the transformation of SC24-1. (Underlined statements result of the transformation)||SC24-2: 1. The customer inserts the customer card in the RM, 2. The RM checks if the card is valid, 3. If the card is valid, 4. A prompt is given to the customer, 5. The customer inputs the bottles and the boxes in the RM, 6. The RM checks if the bottles and the boxes are not blocked, 7. If the bottles and the boxes are not blocked, 8. The RM ejects the card to the customer, 9. The RM prints a receipt to the customer|
|8.1||SSG-1||Choose section with select strategy||Of the three strategies proposed by SSG1, the alternative discovery strategy is chosen. This strategy suits the need to investigate variations and exceptions of the normal course of actions described in SC242|
|8.2||IAG-3||Enact section with automated support||IAG3 proposes several tactics to discover alternative goals to G24. The one based on the analysis of conditions in the scenario is selected. This leads to discover G25 and G26||G25: Recycle box and bottles from RM with invalid card; G26: Recycle box and bottles with a deblocking phase|