|
[[File:metaMeta-levels.pngsvg|thumb|right|320px|Abstraction level for processes.<ref name="Rolland 1993">{{cite conference|author=[[Colette Rolland]] |year=1993 |title=Modeling the Requirements Engineering Process |conference= 3rd European-Japanese Seminar on Information Modelling and Knowledge Bases|___location= Budapest, Hungary |date=June 1993 |idciteseerx = {{citeseerx|10.1.1.29.8738}} |author-link=Colette Rolland }}</ref>]]
'''Meta-process modeling''' is a type of [[metamodeling]] used in [[software engineering]] and [[systems engineering]] for the analysis and construction of models applicable and useful to some predefined problems.
Meta-process modeling supports the effort of creating flexible [[process model]]s. The purpose of process models is to document and communicate processes and to enhance the reuse of processes. 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.<ref name="Rolland 1998" />
== Overview ==
Meta-process modeling focuses on and supports the process of constructing [[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.<ref name="Rolland 1998">{{cite book | chapter=A Comprehensive View of Process Engineering | title=Proceedings of the 10th International Conference on Advanced Information Systems Engineering table of contents | pages =1–24 | year= 1998 |isbn=978-3-540-64556-X6 | author= Colette Rolland
|publisher=Springer-Verlag |___location= London }}</ref> This is important due to the fact that “"[[Process (engineering)|processes]] change with time and so do the [[Processprocess Model]]smodels underlying them. Thus, new processes and models may have to be built and existing ones improved”improved".<ref name="Rolland 1998" /> “The"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”environments".<ref name="Rolland 1999">{{cite journal | doi=10.1007/s007660050018 | title=A Multi-Model View of Process Modelling | year=1999 | last1=Rolland | first1=C. | last2=Prakash | first2=N. | last3=Benjamen | first3=A. | journal=Requirements Engineering | volume=4 |issue=4| page=169| s2cid=6988662 | url=https://hal.archives-ouvertes.fr/hal-00707568/file/A_multi_model_view_REJ.pdf }}</ref> referring to:<ref name="Finkelstein 1994">{{cite book | editoreditor1=A. Finkelstein, |editor2=J. Kramer, |editor3=B. Nuseibeh |title=Software process modelling and technology. |publisher=Wiley |___location=New York | year=1994 | isbn=978-0-471-95206-0}}</ref>
A process meta-model is a [[Metamodeling|meta model]], “a"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.” "<ref name="Rolland 1998" />
{{clear}}
<br style="clear:both" /> There exist standards for several domains:
* [[Software Engineering]]
There exist standards for several domains:
* Software Process Engineering Metamodel (SPEM) which is defined as a [[Profile (UML)]] by the [[Object Management Group]].
* [[Software engineering]]
* Software Process Engineering Metamodel (SPEM) which is defined as a [[profile (UML)]] by the [[Object Management Group]].
== Topics in metadata modeling ==
There are different techniques for constructing process models. “Construction"Construction techniques used in the [[Informationinformation Systemssystems]] area have developed independently of those in [[Softwaresoftware Engineeringengineering]]. 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.” "<ref name="Rolland 1998" />
=== Ad- hoc ===
“Traditional"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.” "<ref name="Rolland 1998" />
=== 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:<ref name="Rolland 1998" /> lists two selection strategies:
#Promoting a ''global'' analysis of the project on hand based on contingency criteria (Example Van Slooten 1996<ref name="Van Slooten 1996">{{cite book |authorauthor1=K. Van Slooten, |author2=B. Hodes |chapter= Characterising IS development project |title=[[IFIP WG 8.1]] Conf. on Method Engineering|publisher= Chapman and Hall |pages= 29–44|year= 1996 | ___location=London | isbn=978-0-412-79750-X7 |title-link=IFIP WG 8.1 }}</ref>)
#Using the notion of descriptors <ref name="Antonellis 1991">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., [[C Rolland]] (eds), North Holland, 1991</ref> 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.<ref name="Rolland 1996b">{{cite book |author1=Rolland, Colette |author2=Prakash, Naveen |name-list-style=amp | chapter = A proposal for context-specific method engineering | title = Proceedings of the IFIP TC8, WG8.1/8.2 working conference on method engineering on Method engineering : principles of method construction and tool support | year = 1996 |isbn = 978-0-412-79750-7 |pages = 191–208 | publisher = Chapman & Hall | ___location = London }}</ref> (Example Plihon 1995<ref name="Plihon 1995">{{cite book | author=V. Plihon, [[C. Rolland]] |chapter= Advanced Information Systems Engineering |title= Proc 7th Int. Conf. On Advanced Information Systems Engineering (CAISE) |volume= 932 |publisher= Springer Verlag |year= 1995 |doi=10.1007/3-540-59498-1 | pages=126–139 |series= Lecture Notes in Computer Science |isbn= 978-3-540-59498-7 |s2cid= 35242104 }}</ref> in NATURE<ref name="NATURE" /> and repository of scenario based approaches accessible on Internet in the CREWS project<ref name="CREWS">[http://sunsite.informatik.rwth-aachen.de/CREWS CREWS project homepage (Cooperative Requirements Engineering With Scenarios)]</ref><ref name="Rolland 1998b">{{cite journal| author=[[C. Rolland]], ColetteC. andBen PrakashAchour, NaveenC. Cauvet, J. Ralyté, A. Sutcliffe, N.A.M. Maiden, M. Jarke, P. Haumer, [[Klaus Pohl (computer scientist)|K. Pohl]], Dubois, P. Heymans | title= A proposal for a scenario classification framework | journal=Requirements Engineering Journal| volume= 3 | issue=1| pages=23–47 | year= 1998 | doi=10.1007/BF02802919 |citeseerx = 10.1.1.30.5360 | s2cid= 1889956 }}</ref>)
chapter = A proposal for context-specific method engineering | title = Proceedings of the IFIP TC8, WG8.1/8.2 working conference on method engineering on Method engineering : principles of method construction and tool support | year = 1996 |isbn = 0-412-79750-X |pages = 191–208 | publisher = Chapman & Hall | ___location = London }}</ref>
(Example Plihon 1995<ref name="Plihon 1995">{{cite journal | author=V. Plihon, [[C. Rolland]] |title= Modelling Ways-of-Working |journal= Proc 7th Int. Conf. on Advanced Information Systems Engineering (CAISE) |publisher= Springer Verlag |year= 1995 |doi=10.1007/3-540-59498-1 | pages=126–139 | url= http://www.springerlink.com/content/f62651046x8q0j24/ }}</ref> in NATURE (<ref name="NATURE" />) and repository of scenario based approaches accessible on Internet in the CREWS project <ref name="CREWS">[http://sunsite.informatik.rwth-aachen.de/CREWS CREWS project homepage (Cooperative Requirements Engineering With Scenarios)]</ref><ref name="Rolland 1998b">{{cite journal| author=[[C. Rolland]], C. Ben Achour, C. Cauvet, J. Ralyté, A. Sutcliffe, N.A.M. Maiden, M. Jarke, P. Haumer, K. Pohl, Dubois, P. Heymans | title= A proposal for a scenario classification framework | journal=Requirements Engineering Journal| volume= 3 | issue=1| pages=23 | year= 1998 | doi=10.1007/BF02802919 |id = {{citeseerx|10.1.1.30.5360}} }}</ref>)
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.<ref name="Rolland 1998" />
=== Instantiation ===
For reusing processes a meta-process model identifies “the"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.” "<ref name="Rolland 1998" />
Process models are then derived from the process meta-models through ''instantiation''. Rolland <ref name="Rolland 1998" /> associates a number of advantages with the instantiation approach:<ref name="Rolland 1998" />
#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"The instantiation technique has been used, for example, in NATURE,<ref name="NATURE">[http://www-i5.informatik.rwth-aachen.de/PROJEKTE/NATURE/nature.html NATURE project homepage (Novel Approaches to Theories Underlying Requirements Engineering)]</ref> Rolland 1993,<ref name="Rolland 1993" /> Rolland 1994,<ref name="Rolland 1994">{{cite journal|author=[[C. Rolland]] |title= A Contextual Approach to modeling the Requirements Engineering Process |journal=6th Intl. Conf. onOn Software Engineering and Knowledge Engineering |___location= Jurmala, Latvia |date= June, 1994 | idciteseerx = {{citeseerx|10.1.1.52.9389}} |author-link= C. Rolland }}</ref> and Rolland 1996.<ref name="Rolland 1996">{{cite journalbook | doi = 10.1109/ICRE.1996.491442 | title = Using generic method chunks to generate process models fragments | year = 1996 | last1 = Rolland | first1 = C. | last2 = Plihon | first2 = V. | pagestitle = 173Proceedings |of the journal=Second International Conference on Requirements Engineering (ICRE'96)| chapter = Using generic method chunks to generate process models fragments | pages = 173–180 | isbn = 978-0-8186-7252-1 | s2cid = 2500090 }}</ref> The process engineer must define the instances of contexts and relationships that comprise the process model of interest.”"<ref name="Rolland 1998" />
=== Language ===
Rolland (1998 <ref name="Rolland 1998" />) lists numerous languages for expressing process models used by the software engineering community:<ref name="Rolland 1998" />
* E3 <ref name="Finkelstein 1994" />
* Various Prolog dialects for EPOS,<ref name="Jacherri 1992">{{cite journal| author = Letizia Jaccheri and Jens-otto Larsen and Reidar Conradi | title = Software Process Modeling and Evolution in EPOS |journal = IEEE Transactions on Software Engineering | year = 1992 | volume = 19 | pages = 1145–1156 | url= http://www.idi.ntnu.no/grupper/su/publ/pdf/capri-final.pdf| doi = 10.1109/32.249660| issue = 12| citeseerx = 10.1.1.53.493 }}</ref> Oikos,<ref name="Ambriola 1991">V. Ambriola, M. L. Jaccheri, Definition and Enactment of Oikos software entities, Proc. of the First European Workshop on Software Process Modeling, Milan, Italy, 1991</ref> and PEACE <ref name="Finkelstein 1994" />
* PS-Algol for PWI <ref name="Finkelstein 1994" />
as well as further computational paradigms:
* [[Petri nets]] in EPOS <ref name="Jacherri 1992" /> and SPADE <ref name="Bandinelli 1993">{{cite journalbook | chapter = Process Modeling in-the-large with SLANG (1993) | authorauthor1= S. Bandinelli, |author2=A. Fugetta, |author3=S. Grigoli | title= Proc. of the 2nd Int. Conf. on Software Process | ___location= Berlin |year= 1993 |pages=75–93 | idciteseerx = {{citeseerx|10.1.1.31.9650}} }}</ref>
* Rule based paradigm in MERLIN <ref name="Emmerich 1991">W. Emmerich, G. Junkermann, W Schafer, MERLIN : knowledge-based process modeling, Proc. of the First European Workshop on Software Process Modeling, Milan, Italy, 1991.</ref>
* ALF <ref name="Benali 1989">{{cite journal | id = {{hdl|10068/43710}} |title=Presentation of the ALF project, Proceedings Conference software development environments and factories |___location= Berlin | year=1989 |url=http://opensigle.inist.fr/handle/10068/43710 |author= Derniame, J.C., Benali, K., Charoy, F., Boudjlida, N., Godart, C. |hdl=10068/43710}}</ref>
* Marvel <ref name="Kaiser 1988">{{cite journal | author=G. E. Kaiser, et al. |year=1988 | title=Database Support for Knowledge-Based Engineering Environments | journal=IEEE Expert | volume=3 |issue=2 | pages=18–32 | doi=10.1109/64.2102|s2cid=12499409 |display-authors=etal}}</ref>
* EPOS <ref name="Jacherri 1992" />
* Triggers in ADELE <ref name="Belkhatir 1994">{{cite journal | authorauthor1=N. Belkhatir, |author2=W. L. Melo |year=1994 | title=Supporting Software Development Processes in Adele2 |journal=Computer Journal |volume= 37 |issue=7 | pages=621–628 | doi=10.1093/comjnl/37.7.621|doi-access=free }}</ref> and MVP-L.<ref name="Finkelstein 1994" />
Languages are typically related to process programs whereas instantiation techniques have been used to construct process scripts.<ref name="Rolland 1998" />
=== Tool support ===
The Metameta-modeling process is often supported through software tools, called [[CAME]] tools (Computer Aided Method Engineering) or [[Meta-CASEMetaCASE tool]] toolss (Meta-level Computer Assisted Software Engineering tools on a Meta-level).
Often the instantiation technique “has"has been utilised to build the repository of Computer Aided Method Engineering environments” environments".<ref name="Rolland 1998" /> (referring to <ref name="Kelly 1996">{{cite journalbook | doi = 10.1007/3-540-61292-0 | title=MetaEdit+ A fully configurable multi-user and multi-tool CASE and CAME environment | publisher=Springer |___location=Heidelberg | volume =1080 |year=1996 |pages=1–21 | series=Lecture Notes in Computer Science | isbn=978-3-540-61292-6 | s2cid=27968437 | title=Advanced Information Systems Engineering }}</ref><ref name="Harmsen 1995">{{cite journalbook | doi=10.1109/APSEC.1995.496992 | titlechapter=Design and implementation of a method base management system for a situational CASE environment | year=1995 | last1=Harmsen | first1=F. | title=Proceedings 1995 Asia Pacific Software Engineering Conference | last2=Brinkkemper | first2=S. | pages=430430–438 |chapter-url=http://doc.utwente.nl/19431/ | isbn=978-0-8186-7171-5 | s2cid=16914451 | url=https://research.utwente.nl/en/publications/design-and-implementation-of-a-method-base-management-system-for-a-situational-case-environment(0a0f863d-3ac2-4540-94cf-962270ebdff1).html }}</ref><ref name="Merbeth 1991">G. Merbeth. Maestro II- das intergrierte CASE-system von Softlab, CASE systeme and Werkzeuge (Ed. H. Balzert) BI Wissenschaftsverlag, pp 319-336, 1991</ref><ref name="Si-Said 1997">{{cite journalbook | doi= 10.1007/BFb0022072 | titlechapter= Guidance for requirements engineering processes | year= 1997 | last1= Si-Said | first1= Samira | title= Database and Expert Systems Applications | last2= Rolland | first2= Colette | volume= 1308 | pages= 643–652 |publisher=Springer |___location=Heidelberg | series= Lecture Notes in Computer Science | isbn= 978-3-540-63478-2 | url= https://hal.archives-ouvertes.fr/hal-00707961/file/DEXA97CR.pdf }}</ref>).
Example tools for meta-process modeling are:<ref name="Rolland 1997">{{cite book |author=[[C. Rolland]] |chapter=A Primer for Method Engineering | title= Proceedings of the INFORSID Conference (INFormatique des ORganisations et Systemes d'Information et de Decision), Toulouse, France, |date=June 10–13, 1997 |isbn=978-0-412-79750-X7 |publisher=Chapman & Hall |chapter-url=http://portal.acm.org/citation.cfm?id=278338 |pages=1–7 |author-link=C. Rolland }}</ref>
*Maestro II <ref name="Merbeth 1991" />
*'''[[MetaEdit+]] '''<ref name="Kelly 1996" />
*Mentor <ref name="Si-Said 1997"/>
==Example: “Multi"Multi-model view”view"==
[[Colette Rolland]] (1999)<ref name="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"Multi-model view”view" and was applied on the CREWS-L’EcritoireL'Ecritoire method. The CREWS-L’EcritoireL'Ecritoire method represents a methodical approach for [[Requirements Engineering]], “the"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.”".<ref name="Rolland 1993" /><ref name="Hagelstein 1988">{{cite journal | doi=10.1016/0950-7051(88)90031-7 | title=Declarative approach to information systems requirements | year=1988 | last1=Hagelstein | first1=J | journal=Knowledge-Based Systems | volume=1 | pages=211211–220 | issue=4 }}</ref><ref name="Dubois 1989">{{cite journal | authorauthor1=E. Dubois, |author2=J. Hagelstein, |author3=A. Rifaut | title= Formal Requirements Engineering with ERAE | journal= Philips Journal Research | volume= 43 | issue= 4 | year = 1989}}</ref>
Besides the CREWS-L’EcritoireL'Ecritoire approach, the multi-model view has served as a basis for representing:<ref name="Rolland 1999" />
:(a) the three other requirements engineering approaches developed within the CREWS project, Real World Scenes approach,<ref name="Haumer 1998">{{cite journal | doi=10.1109/32.738338 | title=Requirements elicitation and validation with real world scenes | year=1998 | last1=Haumer | first1=P. | last2=Pohl | first2=K. | last3=Weidenhaupt | first3=K. | journal=IEEE Transactions on Software Engineering | volume=24 | pages=1036 | issue=12}}</ref> SAVRE approach for scenario exceptions discovery,<ref name="Sutcliffe 1998">{{cite journal | doi=10.1109/32.738340 | title=Supporting scenario-based requirements engineering | year=1998 | last1=Sutcliffe | first1=A.G. | last2=Maiden | first2=N.A.M. | last3=Minocha | first3=S. | last4=Manuel | first4=D. | journal=IEEE Transactions on Software Engineering | volume=24 | pages=1072 | issue=12}}</ref> and the scenario animation approach <ref name="Dubois 1998">{{cite journal | author author1= E. Dubois, |author2=P. Heymans | title= Scenario-based techniques for supporting the elaboration and the validation of formal requirements | journal= Requirement Eng J | year= 1998 | volume = 3 | issue = 3–4 | pages=202–218 | doi = 10.1007/s007660050005|citeseerx=10.1.1.45.4151 |s2cid=2471719 }}</ref>
:(b) for integrating approaches<ref name="Ralyté 1999">{{cite book |authorauthor1=J. Ralyté, |author2=C. Rolland, |author3=V. Plihon |chapter= Method enhancement by scenario based techniques | title=Proceedings of the 11th conference on advanced information systems engineering, Heidelberg, Germany |date=June 1999 |isbn=978-3-540-66157-3 |pages=103–118 |publisher=Springer-Verlag |___location=London |chapter-url=http://portal.acm.org/citation.cfm?id=646087.679900#}}</ref> one with the other and with the OOSE approach <ref name="Jacobson 1992">{{cite book|isbn=978-0-201-54435-0 | url=httphttps://books.google.com/books?id=A6lQAAAAMAAJ | title=Object-oriented software engineering: a use case driven approach | first=Ivar | last=Jacobson | year=1992 | publisher=ACM Press}}</ref>
Furthermore, the CREWS-L’EcritoireL'Ecritoire utilizes [[Processprocess Model]]smodels and [[Metameta-Processprocess Model]]smodels 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''.<ref name="Rolland 1999" /> Together, map (process model) and the guidelines form the method.
The main source of this explanation is the elaboration of [[Colette Rolland]] in.<ref name="Rolland 1999" />
===Process model / Mapmap===
The map is “a"a navigational structure which supports the dynamic selection of the intention to be achieved next and the appropriate strategy to achieve it”it"; it is “a"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.” "<ref name="Rolland 1999" />
The map of the CREWS-L’EcritoireL'Ecritoire method looks as follow:
[[File:process-model.png|thumb|320px|Process model of the CREWS-L’EcritoireL'Ecritoire method <ref name="Rolland 1999" />]]
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''.<ref name="Rolland 1999" />
A map “allows"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 modeling a class of processes. None of the finite set of models included in the map is recommended ‘a'a priori’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".<ref name="Rolland 1999" />
=== Guidelines ===
A guideline “helps"helps in the operationalisation of the selected intention”intention";<ref name="Rolland 1999" /> it is “a"a set of indications on how to proceed to achieve an objective or perform an activity.”"<ref name="RobertDict 1995">Le Petit Robert French Dictionary, Dictionnaires Le Robert, France, 1995</ref> The description of the guidelines is based on the NATURE project’sproject's contextual approach <ref name="NATURE" /><ref name="Rolland 1995">{{cite journal | doi=10.1016/0306-4379(95)00018-Y | title=An approach for defining ways-of-working | year=1995 | last1=Rolland | first1=C | journal=Information Systems | volume=20 | pages=337337–359 | issue=4 }}</ref><ref name="Grosz 1997">{{cite journal | author = G. Grosz, [[C. Rolland]], S. Schwer et al.. | title = Modelling and engineering the requirements engineering process: an overview of the NATURE approach | journal = Requirements Eng J | year = 1997 | volume = 2 | pages = 115–131 | doi = 10.1007/BF02802771 | issue = 3| s2cid = 7672233 |display-authors=etal}}</ref> and its corresponding enactment mechanism.<ref name="Si-Said 1997"/>
Three types of guidelines can be distinguished:
* ''Intention Selection Guidelines (ISG)'' identify the set of intentions that can be achieved in the next step and selects the corresponding set of either IAGs (only one choice for an intention) or SSGs (several possible intentions).
[[File:ISG1.png|thumb|320px|Example of an Intention Selection Guideline 1 (ISG-1)<ref name="Rolland 1999" />]]
[[File:SSG1.png|thumb|320px|Example of ana Strategy Selection Guideline 1 (SSG-1)<ref name="Rolland 1999" />]]
[[File:IAG8.png|thumb|320px|Example of an Intention Achievement Guideline 8 (IAG-8)<ref name="Rolland 1999" />]]
=== 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"a process for the generation of a path from the map and its instantaneous enactment for the application at hand.” "<ref name="Rolland 1999" /> 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.
[[File:meta-process-model.png|thumb|right|320px|Meta-process model of the CREWS-L’EcritoireL'Ecritoire method <ref name="Rolland 1999" />]]
[[Colette Rolland]] describes the meta-model as followfollows:<ref name="Rolland 1999" />
(Meta-intentions are in bold, meta-strategies in italic – in green in the map).)
“The"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'''.”"
{{clear}}
<br style="clear:both" />
== Sample process ==
The sample process "Eliciting requirements of a Recycling Machine" 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 thoughthrough 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 <ref name="Rolland 1999" />):
The following table displays the stepwise trace of the process to elicit requirements for the recycling machine (from<ref name="Rolland 1999" /> ):
<table border=0 cellspacing=5 cellpadding=0>
{| class="wikitable"
<tr>
<td|- valign=top> '''Step'''</td>
! Step
<td valign=top> '''Guideline'''</td>
! Guideline
<td valign=top> '''Meta-process'''</td>
! Meta-process
<td valign=top> '''Process'''</td>
! Process
<td valign=top> '''Product (Goal = Gxx)'''</td>
! Product (Goal = Gxx)
</tr>
|- valign=top
<tr>
| 1.1
<td valign=top> 1.1</td>
| SSG-4
<td valign=top> SSG-4</td>
<td valign=top>| 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
</td>
|
<td valign=top> 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</td>
<td|- valign=top> </td>
| 1.2
</tr>
| IAG-6
<tr>
| Enact section with automated support
<td valign=top> 1.2</td>
| 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
<td valign=top> IAG-6</td>
| G1: Provideverb (Recycling Facilities*) target *RF
<td valign=top> Enact section with automated support
|- valign=top
</td>
| 2.1
<td valign=top> 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 </td>
| ISG-1
<td valign=top> G1: Provideverb (Recycling Facilities*) target *RF </td>
| Choose section with select intention
</tr>
| 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
<tr>
|
<td valign=top> 2.1</td>
<td|- valign=top> ISG-1</td>
| 2.2
<td valign=top> Choose section with select intention
| IAG-1
</td>
| Enact section with automated support
<td valign=top> 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 </td>
| 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
<td valign=top> </td>
| 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
</tr>
|- valign=top
<tr>
| 3.1
<td valign=top> 2.2</td>
| SSG-3
<td valign=top> IAG-1</td>
| <td valign=top> EnactChoose section with automated supportselect strategy
| SSG3 offers two strategies from which the template-driven strategy is chosen. This is because there is uncertainty about what a scenario should be. The templates lead to some certainty
</td>
|
<td valign=top> 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 </td>
|- valign=top
<td valign=top> 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 </td>
| 3.2
</tr>
| IAG-7
<tr>
| Enact section with automated support
<td valign=top> 3.1</td>
| 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
<td valign=top> SSG-3</td>
| SC4: If the customer gets a card, he recycles objects
<td valign=top> Choose section with select strategy
|- valign=top
</td>
| 4.1
<td valign=top> SSG3 offers two strategies from which the template-driven strategy is chosen. This is because there is uncertainty about what a scenario should be. The templates lead to some certainty </td>
| SSG-2
<td valign=top> </td>
| Choose section with select strategy
</tr>
| 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
<tr>
|
<td valign=top> 3.2</td>
<td|- valign=top> IAG-7</td>
| 4.2
<td valign=top> Enact section with automated support
| IAG-10
</td>
| Enact section with automated support
<td valign=top> 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 </td>
| 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
<td valign=top> SC4: If the customer gets a card, he recycles objects </td>
| SC4: 1. The customer gets a card; 2. The customer recycles boxes and bottles
</tr>
|- valign=top
<tr>
| 5.1
<td valign=top> 4.1</td>
| SSG-1
<td valign=top> SSG-2</td>
<td valign=top>| 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
</td>
|
<td valign=top> 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</td>
<td|- valign=top> </td>
| 5.2
</tr>
| IAG-4
<tr>
| Enact section with automated support
<td valign=top> 4.2</td>
| 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
<td valign=top> IAG-10</td>
| G23: Get card from supermarket; G24: Recycle bottles and boxes from RM
<td valign=top> Enact section with automated support
|- valign=top
</td>
| 6.1
<td valign=top> 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 </td>
| SSG-3
<td valign=top> SC4: 1. The customer gets a card; 2. The customer recycles boxes and bottles </td>
| Choose section with select strategy
</tr>
| 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
<tr>
|
<td valign=top> 5.1</td>
<td|- valign=top> SSG-1</td>
| 6.2
<td valign=top> Choose section with select strategy
| IAG-8
</td>
| Enact section with automated support
<td valign=top> 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 </td>
| IAG8 provides style and contents guidelines adapted to the type of scenario at hand, namely system interaction scenario
<td valign=top> </td>
| 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
</tr>
|- valign=top
<tr>
| 7.1
<td valign=top> 5.2</td>
| SSG-2
<td valign=top> IAG-4</td>
| <td valign=top> EnactChoose section with automated supportselect 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
</td>
|
<td valign=top> 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 </td>
|- valign=top
<td valign=top> G23: Get card from supermarket; G24: Recycle bottles and boxes from RM </td>
| 7.2
</tr>
| IAG-9
<tr>
| Enact section with automated support
<td valign=top> 6.1</td>
| 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)
<td valign=top> SSG-3</td>
| 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
<td valign=top> Choose section with select strategy
|- valign=top
</td>
| 8.1
<td valign=top> 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 </td>
| SSG-1
<td valign=top> </td>
| Choose section with select strategy
</tr>
| 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
<tr>
|
<td valign=top> 6.2</td>
<td|- valign=top> IAG-8</td>
| 8.2
<td valign=top> Enact section with automated support
| IAG-3
</td>
| Enact section with automated support
<td valign=top> IAG8 provides style and contents guidelines adapted to the type of scenario at hand, namely system interaction scenario </td>
| 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
<td valign=top> 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
| G25: Recycle box and bottles from RM with invalid card; G26: Recycle box and bottles with a deblocking phase
</td>
|}
</tr>
<tr>
<td valign=top> 7.1</td>
<td valign=top> SSG-2</td>
<td valign=top> Choose section with select strategy
</td>
<td valign=top> 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 </td>
<td valign=top> </td>
</tr>
<tr>
<td valign=top> 7.2</td>
<td valign=top> IAG-9</td>
<td valign=top> Enact section with automated support
</td>
<td valign=top> 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) </td>
<td valign=top> 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</td>
</tr>
<tr>
<td valign=top> 8.1</td>
<td valign=top> SSG-1</td>
<td valign=top> Choose section with select strategy
</td>
<td valign=top> 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 </td>
<td valign=top> </td>
</tr>
<tr>
<td valign=top> 8.2</td>
<td valign=top> IAG-3</td>
<td valign=top> Enact section with automated support
</td>
<td valign=top> 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 </td>
<td valign=top> G25: Recycle box and bottles from RM with invalid card; G26: Recycle box and bottles with a deblocking phase </td>
</tr>
</table>
== See also ==
{{div col|colwidth=22em}}
{{multicol}}
* [[Automatic programming]]
* [[Class-Responsibility-Collaboration card]] (CRC)
* [[Generative programming]] (GP)
* [[Glossary of Unified Modeling Language terms]]
* [[Intentional Programming]] (IP)
* [[KM3]]
* [[Language oriented programming]] (LOP)
{{multicol-break}}
* [[List of UML tools]]
* [[Metadata]]
* [[Meta-modeling technique]]
* [[Metamodeling]]
* [[Meta-Object Facility]]
* [[Method engineering]]
* [[Modeling language]]
* [[Modeling perspectives]]
{{multicol-break}}
* [[Object Constraint Language]] (OCL)
* [[Object-oriented analysis and design]] (OOAD)
* [[XML Metadata Interchange|XMI]]
* [[XML transformation language]] (XTL)
{{multicol-div col end}}
== References ==
[[Category:Unified Modeling Language]]
[[Category:Software development process]]
[[Category:SoftwareData engineeringmodeling]]
| 