Meta-process modeling: Difference between revisions

Revision as of 01:49, 10 September 2008

Revision as of 21:02, 2 February 2009

Line 1:

[[Image:meta-levels.png|thumb|right|320px|Abstraction level for processes <ref name="Rolland 1993"> C. Rolland. Modeling the Requirements Engineering Process, 3rd European-Japanese Seminar on Information Modelling and Knowledge Bases, Budapest, Hungary, June 1993. </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 some predefined problems.

Meta-process support 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 construction [[Processprocess Modelmodel]]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"> 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. </ref>. This is important due to the fact that “[[Process (general)|Processesprocesses]] 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” <ref name="Rolland 1998" />. “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” <ref name="Rolland 1999"> C. Rolland, N. Prakash, A. Benjamen. A Multi-Model View of Process Modelling. Requirements Engineering. Volume 4, Number 4. Springer-Verlag London Ltd , 1999 </ref> referring to <ref name="Finkelstein 1994"> A. Finkelstein, J. Kramer, B. Nuseibeh (eds). Software process modelling and technology. Wiley, New York, 1994 </ref>.

[[Image:meta-levels.png|thumb|right|350px|Abstraction level for processes <ref name="Rolland 1993"> C. Rolland. Modeling the Requirements Engineering Process, 3rd European-Japanese Seminar on Information Modelling and Knowledge Bases, Budapest, Hungary, June 1993. </ref>.]]

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 <ref name="Rolland 1998"> 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. </ref>. This is important due to the fact that “[[Process (general)|Processes]] 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” <ref name="Rolland 1998" />. “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” <ref name="Rolland 1999"> C. Rolland, N. Prakash, A. Benjamen. A Multi-Model View of Process Modelling. Requirements Engineering. Volume 4, Number 4. Springer-Verlag London Ltd , 1999 </ref> referring to <ref name="Finkelstein 1994"> A. Finkelstein, J. Kramer, B. Nuseibeh (eds). Software process modelling and technology. Wiley, New York, 1994 </ref>.

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.” <ref name="Rolland 1998" />

Line 22 ⟶ 23:

(Example Plihon 1995 <ref name="Plihon 1995">V. Plihon, C. Rolland, Modelling Ways-of-Working, Proc 7th Int. Conf. on Advanced Information Systems Engineering (CAISE), Springer Verlag, 1995</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">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</ref>)

“ForFor 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 ===

Line 36 ⟶ 37:

=== Language ===

Rolland 1998 <ref name="Rolland 1998" /> lists numerous languages for expressing process models used by the software engineering community:

* E3 <ref name="Finkelstein 1994" />

*various Various Prolog dialects for EPOS <ref name="Jacherri 1992">L. Jacherri, J. O. Larseon, R. Conradi, Software Process Modelling and Evolution in EPOS, in Proc. of the 4th Int. Conf. on Software Engineering and Knowledge Engineering (SEKE'92), Capri, Italy, 1992, pp574-589.</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">S. Bandinelli, A. Fugetta, S. Grigoli, Process Modelling in the large with SLANG, Proc. of the 2nd Int. Conf. on Software Process, Berlin, Germany, 1993, pp 75-93.</ref>

*rule 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">K. Benali, N. Boudjlida, F. Charoy, J. C. Derniame, C. Godart, Ph. Griffiths, V. Gruhn, Ph. Jamart, D. Oldfield, F. Oquendo, Presentation of the ALF project, Proc. Int. Conf. on System Development Environments and Factories, 1989.</ref>

* Marvel <ref name="Kaiser 1988">G. E. Kaiser, N. S. Barghouti, P. H. Feiler, R. W. Schwanke, Database Support for Knowledge-Based Engineering Environments, IEEE Expert, 3(2), 1988, pp18-32.</ref>

* EPOS <ref name="Jacherri 1992" />

*triggers Triggers in ADELE <ref name="Belkhatir 1994">N. Belkhatir, W. L. Melo, Supporting Software Development Processes in Adele2, In the Computer Journal, vol 37, N°7, 1994, pp 621-628.</ref> and MVP-L <ref name="Finkelstein 1994" />).

“LanguagesLanguages are typically related to process programs whereas instantiation techniques have been used to construct process scripts.” <ref name="Rolland 1998" />

=== Tool support ===

Line 73 ⟶ 74:

The map of the CREWS-L’Ecritoire method looks as follow:

[[Image:process-model.png|thumb|600px320px|Process model of the CREWS-L’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" />

Line 81 ⟶ 82:

=== Guidelines ===

A guideline “helps in the operationalisation of the selected intention” <ref name="Rolland 1999" />; it is “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’s contextual approach <ref name="NATURE" />, <ref name="Rolland 1995">C. Rolland , C. Souveyet, M. Moreno. An approach for defining ways-of-working. Inform Syst J 1995;20(4)337–359</ref>, <ref name="Grosz 1997">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</ref> and its corresponding enactment mechanism <ref name="Si-Said 1996" /> <ref name="Si-Said 1997">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</ref>.

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).

*' ''Strategy Selection Guidelines (SSG)''' guide the selection of a strategy, thereby leading to the selection of the corresponding IAG.

*' ''Intention Achievement Guidelines (IAG)''' aim at supporting the application engineer in the achievement of an intention according to a strategy, are concerned with the tactics to implement these strategies, might offer several tactics, and thus may contain alternative operational ways to fulfil the intention.

[[Image:ISG1.png|thumb|left|300px320px|Example of an Intention Selection Guideline 1 (ISG-1) <ref name="Rolland 1999" />]]

[[Image:SSG1.png|thumb|left|400px320px|Example of an Strategy Selection Guideline 1 (SSG-1) <ref name="Rolland 1999" />]]

[[Image:IAG8.png|thumb|left|400px320px|Example of an Intention Achievement Guideline 8 (IAG-8) <ref name="Rolland 1999" />]]

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

Line 96 ⟶ 99:

#ISG-4 Progress from Start

''';Strategy Selection Guidelines (SSG)'''

The following graph displays the details for the Intention Selection Guideline 1 (ISG-1).

[[Image:ISG1.png|thumb|left|300px|Example of an Intention Selection Guideline 1 (ISG-1) <ref name="Rolland 1999" />]]

<br style="clear:both" />

'''Strategy Selection Guidelines (SSG)'''

#SSG-1 Progress to Elicit a goal

#SSG-2 Progress to Conceptualize a Scenario

Line 108 ⟶ 106:

#SSG-5 Progress to Stop

''';Intention Achievement Guidelines (IAG)'''

The following graph displays the details for the Strategy Selection Guideline 1 (SSG-1).

[[Image:SSG1.png|thumb|left|400px|Example of an Strategy Selection Guideline 1 (SSG-1) <ref name="Rolland 1999" />]]

<br style="clear:both" />

'''Intention Achievement Guidelines (IAG)'''

#IAG-1 Elicit a goal with case-based strategy

#IAG-2 Elicit a goal with composition strategy

Line 126 ⟶ 119:

#IAG-11 Stop with completeness strategy

The following graph displays the details for the Intention Achievement Guideline 8 (IAG-8).

[[Image:IAG8.png|thumb|left|400px|Example of an Intention Achievement Guideline 8 (IAG-8) <ref name="Rolland 1999" />]]

<br style="clear:both" />

=== 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.” <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.

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.

[[Image:meta-process-model.png|thumb|right|400px320px|Meta-process model of the CREWS-L’Ecritoire method <ref name="Rolland 1999" />]]

Colette Rolland describes the meta-model as follow <ref name="Rolland 1999" />:

Line 290 ⟶ 278:

== See also ==

{{multicol}}

{{col-begin}}{{col-3}}

* [[Class-Responsibility-Collaboration card]] (CRC)

* [[Model Driven Engineering]] (MDE)

* [[Code generation]]

* [[Domain Specific Language]] (DSL)

* [[Data mapping]]

* [[Data transformation]]

* [[Domain Specific Language]] (DSL)

* [[Domain-specific modelling]] (DSM)

* [[Eclipse (software)]]

* [[Generative programming]] (GP)

* [[Glossary of Unified Modeling Language terms]]

* [[Intentional Programming]] (IP)

* [[MetadataKM3]]

* [[Language oriented programming]] (LOP)

{{multicol-break}}

* [[List of UML tools]]

* [[UML toolMetadata]]

* [[Meta-model|Metamodel]]

* [[Meta-modeling|Metamodeling technique]]

* [[Meta-modeling]]

* [[Meta-Object Facility]]

* [[Model Driven Engineering]] (MDE)

* [[Model Transformation Language]] (MTL)

* [[Model-based testing]] (MBT)

* [[Model-driven architecture]] (MDA)

* [[Domain-specific modelling]] (DSM)

* [[Modeling language]]

* [[Data transformation]]

* [[Transformation language]] (TL)

* [[XML transformation language]] (XTL)

* [[Model Transformation Language]] (MTL)

* [[Semantic translation]]

* [[Vocabulary-based transformation]]

* [[Data mapping]]

* [[Metadata]]

* [[Modeling perspectives]]

{{colmulticol-3break}}

* [[Model-basedObject testingConstraint Language]] (MBTOCL)

* [[Object-oriented analysis and design]] (OOAD)

* [[Eclipse (software)|Eclipse]] [http://www.eclipse.org/gmt/ GMT Project]

* [[QVT|MOF Queries/Views/Transformations]] (QVT)

* [[Meta-ObjectSemantic Facility|MOFspectrum]]

* [[KM3Semantic translation]]

* [[Language oriented programming]] (LOP)

* [[Generative programming]] (GP)

* [[Intentional Programming]] (IP)

* [[Code generation]]

* [[Software factory]]

* [[Transformation language]] (TL)

* [[Meta-model|Metamodel]]

* [[UML tool]]

* [[Meta-modeling|Metamodeling]]

* [[Unified Modeling Language|UML]]

* [[Meta-modeling technique|Metamodeling technique]]

* [[Vocabulary-based transformation]]

* [[Domain Specific Language]] (DSL)

{{col-3}}

* [[XMI]]

* [[XML transformation language]] (XTL)

* [[Object-oriented analysis and design]] (OOAD)

{{colmulticol-end}}

* [[Modeling language]]

* [[Semantic spectrum]]

* [[Class-Responsibility-Collaboration card]] (CRC)

* [[Unified Modeling Language|UML]]

* [[UML tool]]

* [[List of UML tools]]

* [[Object Constraint Language]] (OCL)

* [[Glossary of Unified Modeling Language terms]]

{{col-end}}

== References ==