Here is my personal thought about the key JP comments to MFI-5 CD5. ---Fei He, MFI-5 Team.

1. Here is my personal thought about the key JP comments to MFI-5 CD5. ---Fei He, MFI-5 Team.

2. Key JP Comments for CD5, such as: JP02: Since a process model is a representation of a process, processes does not exist in a process model. JP09: Since Process_Element is a subclass of Model_Element, its instance does not represent a thing that constitutes a process, but an element or a component of a model, in this part, of a process model. JP11: Since Proces is a subclass of Model_Element, its instance does not represent a process (in a real world), but an element or a component of a model, in this part, of a process model. JP30: Process_00 (Annex A) should be removed because it is unclear what Process_00 is and this standard is for process model registration and not for process registration.

3. I mostly agree with Dr. Masao as I mentioned before (in email) about: There shall have difference between a process in the real world and a process as a modelling element,to avoid any possible confusion. A process in the real world (including a computational world) ≒an dynamic aspect of a domain of interest) and its name shall be different with the “process” below A process specified incertain modelling language, working as modelling element Process described_process describing_model containing_model Process_Model These two processes are not the same thing. They shall be renamed. ≠ Process_Element Process contained_process_element

4. If there is no difference, then the process is playing two kinds of roles within the same Figure 2 (The metamodel of MFI PMR): one role, a process in the real world or a process represented in certain modelling language; the other role, a process element. (As to the first role) Normally when people defines or describes a thing, it is not reasonable to let the target thing appeared in the definition or description*. * Note: with this in mind, I also accept JP30 (Annex A, Process_00 should be removed …).

5. So the process (in the real world is described by a certain model in a certain modelling language) shall not be a part of Fig 2. Then what is the process appeared in Fig 2? Yes, a process element.

6. Now the process in Fig 2 is a process element, then is the relationships R1 (<Process, Process_Model>, describe) and R2 (<Process, Process_Element>, decompose) right? R1? R2 ? The above two relationships shall be restricted by the scope of MFI-5 which is: “Metamodel for process model registration” rather than “for process modelling”.

7. When talking about process model registration, we means all the models submitted for registration shall be in their final static states, no further recursive decomposition (for decomposition is a behavior of modelling) shall happen.

8. So it means: when you have something like X (PMn, describing the Process Pi which is a process element of PM) ) for registration, the X shall be registered in either A or B. A X PMm PM A: register the final, static and integrated version of PM and PMn in just one model PMm. Pi PMn

9. Registration in A way: both PM and PMn are already included in one PMm, the process represented by PMm shall not appeared in Fig 2, and no decomposition happened, so neither R1 nor R2 is in need. R1 X R2X

10. According to: In process modelling the decomposition of a process (or activity or task) in one model (or diagram or picture) into another series of processes (or activities or tasks) in another model (or picture or diagram) is very common. (from Mr. Keith) I do not have any objections to that a process model or any other kind of models can be decomposed recursively. (from Mr. Masao) But, at the BRM in Krakow, if I understand correctly, Canada(Ray) claimed that there is a situation that a Process (element) in some Process Model can be further decomposed by another Process Model and that for that purpose, the reference "described process" (and its inverse reference) is necessary. So, I accepted that. (from Mr. Masao) So people could also submit X in B way for registration.

11. B: register PM and PMn separately, according to the definition of process (can not be decomposed by another model) and process model (can also describe a process which is already represented in certain modelling languages), within the administrative information of PMn, people shall declare that PMn is describing Pi of PM, and PMn shall be named after Pi, so double direction searching will be possible. B PMn PM Pi

12. In B way, PMn is independent on PM, and PMn is used to describe the Pi in PM, rather than decomposition of Pi, so only R1 is needed and R2 is not in need. R1 R2X

13. Summary of the way of process model registration (in both A and B): when the process in Fig 2 is restricted to process element, people only need to keep R1 (describe), rather than R2 (decompose, which is a modelling). R1 OK R2X

14. Problem analysis: Process is not Process (real world) but Process(the element), and so usually, a Process is not what a Process Model represents, but a part that constitutes a Process Model. But, the wording "Process" has a connotation that it is represented by a Process Model and is confusing. To avoid the confusing wording, JP08 on CD4 MFI-5 proposed that "Process" should be changed to "Activity", but unfortunately it was not accepted. (Mr. Masao, strictly following the definition) Collection of related, structured activities or tasks that achieve a particular business goal. NOTE: The activities and tasks are represented by the Process metaclass in this part. (Current definition of process in MFI-5) Analysis: the “Note” in the definition of process will definitely make people have decomposition in mind.

15. Problem analysis: In process modelling the decomposition of a process (or activity or task) in one model (or diagram or picture) into another series of processes (or activities or tasks) in another model (or picture or diagram) is very common. So the issue is how to capture this. And, to make matters much, much worse, there is no agreed terminology in the process modelling world. (Mr. Keith, trying to cover pragmatic aspects in real world) Analysis: I think that “carrying on the decomposition of a process in its own model ” is different from “carrying on the decomposition of a process (of a model) in another model”; in the former, the “decomposition” is a precise word; but in the latter, the “decomposition” is not a precise word, “re-modelling” matches the case.

16. Problem analysis: In order to overcome these problems, currently I am considering re-defining the process, adding something like: “process, ranging from conceptual process in real world to process already represented in certain modelling languages”, any suggestion?

17. The new Fig 2 in our consideration:

18. The new Fig 2 in my consideration: Differences from CD5: delete the aggregation relationship from process_element to process; take resource and event as the subclass of process_element; separate original Fig 2 to two parts: Fig 2 (internal relationship) and Fig 3 (external relationship).