| Meta-process Modeling |
Website Links For Modeling |
Information AboutMeta-process Modeling |
| CATEGORIES ABOUT META-PROCESS MODELING | |
| software engineering | |
| systems engineering | |
| unified modeling language | |
|
The term Meta-process modeling as described here belongs to the context of Information System Development , in specific to the discipline of ‘ Method Engineering ’ / ‘ Situational Method Engineering ’, or ‘ Process Engineering ’. Method Engineering “represents the effort to improve the usefulness of systems development methods by creating an adaptation framework whereby methods are created to match specific organisational situations” C. Rolland. A Primer for Method Engineering. Proceedings of the INFORSID Conference (INFormatique des ORganisations et Systemes d'Information et de Decision), Toulouse, France, June 10-13, 1997. . Meta-process models are a means to achieve this goal. They support the effort of creating flexible Process Model s, also known as Situational Method Engineering . Meta-process modeling focuses on and supports the process of construction Process Model s. Its main concern is to improve process models and to make them evolve, which in turn, will support the development of systems C. Rolland. A Comprehensive View of Process Engineering. Proceedings of the 10th International Conference CAiSE'98, B. Lecture Notes in Computer Science 1413, Pernici, C. Thanos (Eds), Springer. Pisa, Italy, June 1998. . This is important due to the fact that “ Process es change with time and so do the Process Model s 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” C. Rolland, N. Prakash, A. Benjamen. A Multi-Model View of Process Modelling. Requirements Engineering. Volume 4, Number 4. Springer-Verlag London Ltd , 1999 referring to A. Finkelstein, J. Kramer, B. Nuseibeh (eds). Software process modelling and technology. Wiley, New York, 1994 . 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. {Link without Title} 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.” PURPOSE The purpose of process models is to
Thus, processes can be better taught and executed. Results of using meta-process models are an increased productivity of process engineers and an improved quality of the models they produce . TECHNIQUES There are different techniques for constructing process models. “Construction techniques used in the Information Systems area have developed independently of those in Software Engineering . In information systems, construction techniques exploit the notion of a meta-model and the two principal techniques used are those of ''instantiation'' and ''assembly''. In software engineering the main construction technique used today is language-based. However, early techniques in both, information systems and software engineering were based on the experience of process engineers and were, therefore, ''ad-hoc'' in nature.” Instantiation For reusing processes a meta-process model identifies “the common, generic features of process models and represents them in a system of concepts. Such a representation has the potential to 'generate' all process models that share these features. This potential is realised when a generation technique is defined whose application results in the desired process model.” Process models are then derived from the process meta-models through ''instantiation''. Rolland associates a number of advantages with the instantiation approach: #The exploitation of the meta-model helps to define a wide range of process models. #It makes the activity of defining process models systematic and versatile. #It forces to look for and introduce, in the process meta-model, generic solutions to problems and this makes the derived process models inherit the solution characteristics. “The instantiation technique has been used, for example, in NATURE NATURE project homepage (Novel Approaches to Theories Underlying Requirements Engineering) , Rolland 1993 , Rolland 1994 C. Rolland, A Contextual Approach to modeling the Requirements Engineering Process 6th Intl. Conf. on Software Engineering and Knowledge Engineering, Jurmala, Latvia, June, 1994, and Rolland 1996 C. Rolland, V. Plihon, Using generic chunks to generate process models fragments in Proc. of 2nd IEEE Int. Conf. on Requirements Engineering, ICRE'96, Colorado Spring, 1996. The process engineer must define the instances of contexts and relationships that comprise the process model of interest.” Assembly The assembly technique is based on the idea of a process repository from which process components can be selected. Rolland 1998 lists two selection strategies: #Promoting a ''global'' analysis of the project on hand based on contingency criteria (Example Van Slooten 1996 K. Van Slooten, B. Hodes, Characterising IS development project, IFIP WG 8.1 Conf. on Method Engineering, Chapman and Hall, pp 29-44, 1996) #Using the notion of descriptors V. De Antonellis, B. Pernici, P. Samarati. F-ORM METHOD: A methodology for reusing specifications. In Object Oriented Approach in Information Systems. Van Assche F., Moulin B., Rolland C. (eds), North Holland, 1991 as a means to describe process chunks. This eases the retrieval of components meeting the requirements of the user / matching with the situation at hand. C. Rolland, N. Prakash, A proposal for context-specific method engineering, IFIP WG 8.1 Conf. on Method Engineering, Chapman and Hall, pp 191-208, 1996 (Example Plihon 1995 V. Plihon, C. Rolland, Modelling Ways-of-Working, Proc 7th Int. Conf. on Advanced Information Systems Engineering (CAISE), Springer Verlag, 1995 in NATURE () and repository of scenario based approaches accessible on Internet in the CREWS project CREWS project homepage (Cooperative Requirements Engineering With Scenarios) C. Rolland, C. Ben Achour, C. Cauvet, J. Ralyté, A. Sutcliffe, N.A.M. Maiden, M. Jarke, P. Haumer, K. Pohl, Dubois, P. Heymans, A proposal for a scenario classification framework. To appear in Requirements Engineering Journal 3:1, 1998) “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.” Language Rolland 1998 lists numerous languages for expressing process models used by the software engineering community:
as well as further computational paradigms:
“Languages are typically related to process programs whereas instantiation techniques have been used to construct process scripts.” Ad-hoc “Traditional process models are expressions of the experiences of their developers. Since this experience is not formalised and is, consequently, not available as a fund of knowledge, it can be said that these process models are the result of an ad-hoc construction technique. This has two major consequences: it is not possible to know how these process models were generated, and they become dependent on the domain of experience. If process models are to be domain independent and if they are to be rapidly generable and modifiable, then we need to go away from experience based process model construction. Clearly, generation and modifiability relate to the process management policy adopted (see Usage World). Instantiation and assembly, by promoting modularization, facilitate the capitalisation of good practice and the improvement of given process models.” TOOL SUPPORT The Meta-modeling process is often supported through software tools, called CAME tools (Computer Aided Method Engineering) or Meta-CASE tools (Computer Assisted Software Engineering tools on a Meta-level). Often the instantiation technique “has been utilised to build the repository of Computer Aided Method Engineering environments” (referring to S. Kelly, K. Lyyttinen, M. Rossi. Meta Edit+: A fully configurable, multi-user and multi-tool CASE and CAME environment, Proc. CAiSE'96 Conf., Springer Verlag, 1996, F. Harmsen, S. Brinkkemper, Design and implementation of a method base management system for situational CASE environment. Proc. 2nd APSEC Conf., IEEE Computer Society Press, pp 430-438, 1995, G. Merbeth. Maestro II- das intergrierte CASE-system von Softlab, CASE systeme and Werkzeuge (Ed. H. Balzert) BI Wissenschaftsverlag, pp 319-336, 1991, S. Si Said. Guidance for requirements engineering processes. In: Proceedings of the 8th international conference and workshop on ‘database and experts system application’, DEXA’97, Toulouse, 1–5 September 1997). Example tools for meta-process modeling are :
EXAMPLE: “MULTI-MODEL VIEW” Colette Rolland (1999 ) provides an example of a meta-process model which utilizes the instantiation and assembly technique. In the paper the approach is called “Multi-model view” and was applied on the CREWS-L’Ecritoire method. The CREWS-L’Ecritoire method represents a methodical approach for Requirements Engineering , “the part of the IS development that involves investigating problems and requirements of the users community and developing a specification of the future system, the so-called conceptual schema.” (, referring to J. Hagelstein. Declarative Approach to Information Systems Requirements. In Knowledge-Based Systems, Vol. & No 4, 1988 and E. Dubois, J. Hagelstein, A. Rifaut. Formal Requirements Engineering with ERAE, Philips Journal Research, Vol. & 43, No 4, 1989). 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 P. Haumer, K. Pohl, K. Weidenhaupt. Requirements elicitation and validation with real world scenes. IEEE Trans Software Eng (Special Issue on Scenario Management) 1998;24(12), SAVRE approach for scenario exceptions discovery A.G. Sutcliffe, N.A.M. Maiden, S. Minocha, D. Manuel. Supporting scenario-based requirements engineering. Trans Software Eng (Special Issue on Scenario Management) 1998, and the scenario animation approach E. Dubois, P. Heymans. Scenario-based techniques for supporting the elaboration and the validation of formal requirements. Requirement Eng J 1998;3(3–4):202–218) (b) for integrating approaches (J. Ralyté, C. Rolland, V. Plihon. Method enhancement by scenario based techniques. In: Proceedings of the 11th conference on advanced information systems engineering, Heidelberg, Germany, June 1999 one with the other and with the OOSE approach I. Jacobson, M. Christerson, P. Jonsson, G. Oevergaard. Object oriented software engineering: a use case driven approach. Addison-Wesley, Reading, MA, 1992) Furthermore, the CREWS-L’Ecritoire utilizes Process Model s and Meta-Process Model s 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 . Process model / Map The map is “a navigational structure which supports the dynamic selection of the intention to be achieved next and the appropriate strategy to achieve it”; it is “a process model in which a nondeterministic ordering of intentions and strategies has been included. It is a labelled directed graph with intentions as nodes and strategies as edges between intentions. The directed nature of the graph shows which intentions can follow which one.” 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” . Guidelines A guideline “helps in the operationalisation of the selected intention” ; it is “a set of indications on how to proceed to achieve an objective or perform an activity” Le Petit Robert French Dictionary, Dictionnaires Le Robert, France, 1995. The description of the guidelines is based on the NATURE project’s contextual approach , C. Rolland , C. Souveyet, M. Moreno. An approach for defining ways-of-working. Inform Syst J 1995;20(4)337–359, G. Grosz, C. Rolland, S. Schwer et al.. Modelling and engineering the requirements engineering process: an overview of the NATURE approach. Requirements Eng J 1997;2:115–131 and its corresponding enactment mechanism S. Si Said. Guidance for requirements engineering processes. In: Proceedings of the 8th international conference and workshop on ‘database and experts system application’, DEXA’97, Toulouse, 1–5 September 1997. 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) #ISG-1 Progress from Elicit a goal #ISG-2 Progress from Conceptualize a Scenario #ISG-3 Progress from Write a scenario #ISG-4 Progress from Start The following graph displays the details for the Intention Selection Guideline 1 (ISG-1). Strategy Selection Guidelines (SSG) #SSG-1 Progress to Elicit a goal #SSG-2 Progress to Conceptualize a Scenario #SSG-3 Progress to Write a scenario #SSG-4 Progress to Elicit a goal #SSG-5 Progress to Stop The following graph displays the details for the Strategy Selection Guideline 1 (SSG-1). Intention Achievement Guidelines (IAG) #IAG-1 Elicit a goal with case-based strategy #IAG-2 Elicit a goal with composition strategy #IAG-3 Elicit a goal with alternative strategy #IAG-4 Elicit a goal with refinement strategy #IAG-5 Elicit a goal with linguistic strategy #IAG-6 Elicit a goal with template-driven strategy #IAG-7 Write a scenario with template-driven strategy #IAG-8 Write a scenario in free prose #IAG-9 Conceptualize a Scenario with computer support strategy #IAG-10 Conceptualize a Scenario manually #IAG-11 Stop with completeness strategy The following graph displays the details for the Intention Achievement Guideline 8 (IAG-8). Meta-process map In the multi-model view as presented in the paper of C. Rolland, the meta-process (the instance of the meta-process model) is “a process for the generation of a path from the map and its instantaneous enactment for the application at hand.” 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 graph by associating the meta-strategy ''automated support'' with the meta-intention, '''Enact Section'''.” Sample process: Eliciting requirements of a Recycling Machine This sample process is about a method for designing the requirements of recycling facilities. The recycling facilities are meant for customers of a supermarket. The adequate method is obtained though instantiation of the meta-process model on the process model. The following table displays the stepwise trace of the process to elicit requirements for the recycling machine (from ):
REFERENCES |
|
|