元过程建模以及一种元过程建模工具MetaEdit+的介绍

 

Meta-Process Modeling

http://www.answers.com/topic/meta-process-modeling

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 (as a component of case tools architecture) “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” ^[1]. Meta-process models are a means to achieve this goal. They support the effort of creating flexible Process Models, also known as Situational Method Engineering.

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 ^[2]. 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” ^[2]. “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” ^[3] referring to ^[4].

Abstraction level for processes ^[5].

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.” ^[2]

Purpose

The purpose of process models is to

• Document and communicate processes
• 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 ^[2].

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.” ^[2]

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.” ^[2]

Process models are then derived from the process meta-models through instantiation. Rolland ^[2] associates a number of advantages with the instantiation approach:

1. The exploitation of the meta-model helps to define a wide range of process models.
2. It makes the activity of defining process models systematic and versatile.
3. 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 ^[6], Rolland 1993 ^[5], Rolland 1994 ^[7], and Rolland 1996 ^[8]. The process engineer must define the instances of contexts and relationships that comprise the process model of interest.” ^[2]

Assembly

The assembly technique is based on the idea of a process repository from which process components can be selected. Rolland 1998 ^[2] lists two selection strategies:

1. Promoting a global analysis of the project on hand based on contingency criteria (Example Van Slooten 1996 ^[9])
2. Using the notion of descriptors ^[10] 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. ^[11]

(Example Plihon 1995 ^[12] in NATURE (^[6]) and repository of scenario based approaches accessible on Internet in the CREWS project ^{[13] [14]})

“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.” ^[2]

Language

Rolland 1998 ^[2] lists numerous languages for expressing process models used by the software engineering community:

• E3 ^[4]
• various Prolog dialects for EPOS ^[15], Oikos ^[16], and PEACE ^[4]
• PS-Algol for PWI ^[4])

as well as further computational paradigms:

• Petri nets in EPOS ^[15] and SPADE ^[17]
• rule based paradigm in MERLIN ^[18]
• ALF ^[19]
• Marvel ^[20]
• EPOS ^[15]
• triggers in ADELE ^[21] and MVP-L ^[4]).

“Languages are typically related to process programs whereas instantiation techniques have been used to construct process scripts.” ^[2]

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.” ^[2]

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” ^[2] (referring to ^[22], ^[23], ^[24], ^[25]).

Example tools for meta-process modeling are ^[1]:

• Maestro II ^[24]
• [[MetaEdit+]] ^[22]
• Mentor ^[25]

Example: “Multi-model view”

Colette Rolland (1999 ^[3]) 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.” (^[5], referring to ^[26] and ^[27]).

Besides the CREWS-L’Ecritoire approach, the multi-model view has served as a basis for representing ^[3]: (a) the three other requirements engineering approaches developed within the CREWS project (Real World Scenes approach ^[28], SAVRE approach for scenario exceptions discovery ^[29], and the scenario animation approach ^[30]) (b) for integrating approaches (^[31] one with the other and with the OOSE approach ^[32])

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 ^[3]. Together, map (process model) and the guidelines form the method. The main source of this explanation is the elaboration of Colette Rolland in ^[3].

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.” ^[3]

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

Process model of the CREWS-L’Ecritoire method ^[3]

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. ^[3]

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” ^[3].

Guidelines

A guideline “helps in the operationalisation of the selected intention” ^[3]; it is “a set of indications on how to proceed to achieve an objective or perform an activity” ^[33]. The description of the guidelines is based on the NATURE project’s contextual approach ^[6], ^[34], ^[35] and its corresponding enactment mechanism ^{[25] [36]}.

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.

In our case, the following guidelines – which correspond with the map displayed above – need to be defined:

Intention Selection Guidelines (ISG)

1. ISG-1 Progress from Elicit a goal
2. ISG-2 Progress from Conceptualize a Scenario
3. ISG-3 Progress from Write a scenario
4. ISG-4 Progress from Start

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

Example of an Intention Selection Guideline 1 (ISG-1) ^[3]

Strategy Selection Guidelines (SSG)

1. SSG-1 Progress to Elicit a goal
2. SSG-2 Progress to Conceptualize a Scenario
3. SSG-3 Progress to Write a scenario
4. SSG-4 Progress to Elicit a goal
5. SSG-5 Progress to Stop

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

Example of an Strategy Selection Guideline 1 (SSG-1) ^[3]

Intention Achievement Guidelines (IAG)

1. IAG-1 Elicit a goal with case-based strategy
2. IAG-2 Elicit a goal with composition strategy
3. IAG-3 Elicit a goal with alternative strategy
4. IAG-4 Elicit a goal with refinement strategy
5. IAG-5 Elicit a goal with linguistic strategy
6. IAG-6 Elicit a goal with template-driven strategy
7. IAG-7 Write a scenario with template-driven strategy
8. IAG-8 Write a scenario in free prose
9. IAG-9 Conceptualize a Scenario with computer support strategy
10. IAG-10 Conceptualize a Scenario manually
11. IAG-11 Stop with completeness strategy

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

Example of an Intention Achievement Guideline 8 (IAG-8) ^[3]

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.” ^[3]

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.

Meta-process model of the CREWS-L’Ecritoire method ^[3]

Colette Rolland describes the meta-model as follow ^[3]: (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.”

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 ^[3]):

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 (Recylcing 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

References

1. ^ ^{a b} 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.
2. ^ ^{a b c d e f g h i j k l m n} 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.
3. ^ ^{a b c d e f g h i j k l m n o p q} C. Rolland, N. Prakash, A. Benjamen. A Multi-Model View of Process Modelling. Requirements Engineering. Volume 4, Number 4. Springer-Verlag London Ltd , 1999
4. ^ ^{a b c d e} A. Finkelstein, J. Kramer, B. Nuseibeh (eds). Software process modelling and technology. Wiley, New York, 1994
5. ^ ^{a b c} C. Rolland. Modeling the Requirements Engineering Process, 3rd European-Japanese Seminar on Information Modelling and Knowledge Bases, Budapest, Hungary, June 1993.
6. ^ ^{a b c} NATURE project homepage (Novel Approaches to Theories Underlying Requirements Engineering)
7. ^ C. Rolland, A Contextual Approach to modeling the Requirements Engineering Process 6th Intl. Conf. on Software Engineering and Knowledge Engineering, Jurmala, Latvia, June, 1994
8. ^ 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
9. ^ K. Van Slooten, B. Hodes, Characterising IS development project, IFIP WG 8.1 Conf. on Method Engineering, Chapman and Hall, pp 29-44, 1996
10. ^ 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
11. ^ 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
12. ^ V. Plihon, C. Rolland, Modelling Ways-of-Working, Proc 7th Int. Conf. on Advanced Information Systems Engineering (CAISE), Springer Verlag, 1995
13. ^ CREWS project homepage (Cooperative Requirements Engineering With Scenarios)
14. ^ 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
15. ^ ^{a b c} L. Jacherri, J. O. Larseon, R. Conradi, Sotware 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.
16. ^ 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
17. ^ 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.
18. ^ W. Emmerich, G. Junkermann, W Schafer, MERLIN : knowledge-based process modeling, Proc. of the First European Workshop on Software Process Modeling, Milan, Italy, 1991.
19. ^ 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.
20. ^ 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.
21. ^ N. Belkhatir, W. L. Melo, Supporting Software Development Processes in Adele2, In the Computer Journal, vol 37, N°7, 1994, pp 621-628.
22. ^ ^{a b} 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
23. ^ 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
24. ^ ^{a b} G. Merbeth. Maestro II- das intergrierte CASE-system von Softlab, CASE systeme and Werkzeuge (Ed. H. Balzert) BI Wissenschaftsverlag, pp 319-336, 1991
25. ^ ^{a b c} 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
26. ^ J. Hagelstein. Declarative Approach to Information Systems Requirements. In Knowledge-Based Systems, Vol. & No 4, 1988
27. ^ E. Dubois, J. Hagelstein, A. Rifaut. Formal Requirements Engineering with ERAE, Philips Journal Research, Vol. & 43, No 4, 1989
28. ^ 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)
29. ^ 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
30. ^ 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
31. ^ 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
32. ^ I. Jacobson, M. Christerson, P. Jonsson, G. Oevergaard. Object oriented software engineering: a use case driven approach. Addison-Wesley, Reading, MA, 1992
33. ^ Le Petit Robert French Dictionary, Dictionnaires Le Robert, France, 1995
34. ^ C. Rolland , C. Souveyet, M. Moreno. An approach for defining ways-of-working. Inform Syst J 1995;20(4)337–359
35. ^ 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
36. ^ 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

See also

• Model Driven Engineering (MDE)
• Domain Specific Language (DSL)
• 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

• Model-based testing (MBT)
• Eclipse GMT Project
• MOF Queries/Views/Transformations (QVT)
• MOF
• KM3
• Language oriented programming (LOP)
• Generative programming (GP)
• Intentional Programming (IP)
• Code generation
• Software factory
• Metamodel
• Metamodeling
• Metamodeling technique
• Domain Specific Language (DSL)

• XMI
• Object-oriented analysis and design (OOAD)
• Modeling language
• Semantic spectrum
• Class-Responsibility-Collaboration card (CRC)
• UML
• UML tool
• List of UML tools
• Object Constraint Language (OCL)
• Glossary of Unified Modeling Language terms

 

This entry is from Wikipedia, the leading user-contributed encyclopedia. It may not have been reviewed by professional editors (see full disclaimer)

 

 

 

 

 

元过程建模Meta-process modeling

http://www.answers.com/topic/meta-process-modeling

 

    元过程是信息系统开发information system development中的概念，特别是method engineering, situational method engineering, process engineering.

    Method engineering描述的是为了改进系统开发方法的有用性所做的努力。Method engineering创建一个具有适应性的框架，并且创造一些方法以适应特定的组织结构。Method engineering是case工具体系结构的一部分。元过程是为了达到这种目标一种方法。元过程对建立灵活的过程模型process models提供支持，这也被称为situational method engineering。

    元过程建模关注的是过程模型的结构的建立过程，并对此提供支持。元过程主要关注于过程模型的改善。通过对过程模型的改进反过来又支持系统的开发。这一点很重要，因为过程总是在变，而过程模型是其基础。新的过程和模型被建立起来，已存在的则得到改进。因此，我们的关注就是要提高过程模型的形式化程度。这样，在以过程为中心的软件环境中，过程模型的制定就成为了可能。

    过程的元模型就是对过程模型在类型层次上的描述。过程模型就是过程元模型的实例化。

一个元模型可以多次实例化以创建不同的过程模型。过程元模型对一个过程而言是它的元类型层次。（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.”）

Purpose目标

    过程模型的目标：

l         将过程文档化，并且在过程之间进行交流，通信。

l         增强过程的重用。

    因此，过程模型应该是易于讲解和执行的。元过程模型的使用能提供过程建模者的效率，以及模型的质量。

技术

    有很多技术可以建立过程模型，信息系统的中构造技术的发展是独立于软件工程的构造技术的。信息系统中的构造技术采用了元模型的概念，并且有两个原则性技术：元模型的实例化和元模型的组装。软件工程被广泛使用的构造技术是基于语言的。但是，在软件工程和信息系统的早期使用的技术都是基于过程创建者的经验，这种技术是一般中的特殊。

实例化

    为了重用过程，元过程模型标识了过程模型中一般的，通用的特征，并表述为一个概念系统。因此，元过程模型具有表达所有具有相同特性的过程模型的能力。当定义了额一个创建技术，并且其应用产生了需要的过程模型，那么元过程模型的这种能力就被实现了。

    过程模型通过实例化继承了元过程模型。Rolland指出了这种实例化的一些优点：

1.      这种元模型的开发可以帮助定义广大范围内的过程模型。

2.      使得过程模型的定义活动变得系统化，通用化。

3.      这使得人们从过程元模型中去寻找问题通用的解决方案，这样从元过程模型继承的过程模型也可以获得与方案一样的特性。

实例化的技术已经在一个名为NATURE的项目中使用。过程创建者必须定义构成过程模型关系的上下文以及关系的实例。

组装

    组合技术是来源于过程库的想法。Rolland列出了两种可选的策略：

1.      对已有的项目，基于偶然性原则（contingency criteria？），进行全局性的分析。

2.      以过程的介绍信息为标准来描述过程。这可以减轻获取符合用户或条件要求的组件所需要做的工作。

为了让组装技术能够成功，将过程模型模块化是有必要的。如果组装技术与实例化技术一起使用，那么元模型本身应该是模块化的。

语言

    Rolland列举了很多在软件工程中用来描述过程模型的语言。

l         E3

l         各种Prolog dialects for EPOS ^[15], Oikos ^[16], and PEACE ^[4]

l         PS-Algol for PWI ^[4])

以及一些可计算的：

l         Petri nets in EPOS [15] and SPADE [17]

l         rule based paradigm in MERLIN [18]

l         ALF [19]

l         Marvel [20]

l         EPOS [15]

l         triggers in ADELE [21] and MVP-L [4]).

语言与过程编程密切相关，同时实例化技术已经被用来生成过程脚本。

 

传统的过程模型被用来表达开发者的经验。因为经验不是形式化的，并且不能做为知识的基础，所以这些过程模型都是特定的构造技术。这样造成两个结果：无法知道这些模型是怎样被构造出来的；模型是依赖于领域经验的。如果过程模型是领域无关，并且可以快速生成和修改，那我们就可以从基于经验的过程模型构造中脱离出来。很明显，模型的创建和修改与采用的过程管理策略是相关联的。通过提高模块化程度，实例化和组装就可以让良好的经验得到更好的利用，加快过程模型的改善。

工具支持

    元建模有软件工具支持，CAME（Computer Aided Method Engineering）工具或元CASE工具。实例化技术已经被用来建立CAME环境的库。

    工具举例：

l         Maestro II [24]

l         [[MetaEdit+]] [22] http://www.metacase.com/

l         Mentor [25]

 

例子：多模型视图Multi-model view

   

 

 

关于CAME工具MetaEdit+工具的介绍：

主页：http://www.metacase.com/

    MetaEdit+首先是一个可以自己创建领域相关的建模语言的工具，其次是支持该自建建模语言的工具。

 

从一个例子来讲：有一个家谱如下，为了描述家谱，现在创建一个家谱建模语言。

MetaEdit+使用的方式称为GOPPRRGraph,分别代表的是Object, Property, Port, Relationship and Role。Objec是其核心。

对本例来说，首先利用提供的工具要创建一个代表人的object，比如person，并且定义person的属性。

第二步，创建表示person的图符。

第三步，创建person与person之间可能存在的关系，比如父子。注意到存在于一个关系中的两者是有角色这个问题的。比如在父子关系中，一边是父亲的角色，一边是子的角色。所以，同时还要创建角色。

这样，我们就有了为家谱建模所需的元模型的片断了。想象一下，为家谱建模的这个语言应该是什么样子的？一个图符式的表达方式是比较自然的方式了。那么就要将家谱建模语言定义下来。

GOPPRR中用graph来对应建模语言的类型（家谱建模语言）。

第四步，根据MetaEdit+的向导，将前面定义过的家谱建模语言的片断编译成一个完整的建模语言。编译之后，可能就是一个graph。假设将家谱建模语言定义为Family Tree。

第五步，如果还要定义更复杂的问题，会用到port的概念。

下面来使用定义的家谱建模语言Family Tree：

第一步，选择已定义的家谱建模语言Family Tree。

第二步，建立一个实例。

第三步，在MetaEdit+提供的可视化环境中定义一个具体的家谱。

定义的过程包括：

（1）      加入object。

（2）      加入关系

（3）      产生一个关于该家谱实例的html报告（还有其他形式可选），可以看到。

上面这个html报告是用预定义的生成器generator来生成的。当然，定义自己的生成器是很有必要的。

比如，进入生成器定义界面可以做如下定义：

Report 'My HTML report'

 

foreach .()

{

   id

   newline

}

 

endreport

       这样，生成的输出就是：

   

    由此，我们定义一个家谱建模语言，并且生成了一个家谱实例，并且以某种方式将其输出了。这些介绍只是简单的入门，根据其宣传词，MetaEdit+具有如下强大的功能：

    your domain --> your model --> your code

 见http://www.metacase.com/flash/flash.swf