Multiple and Hierarchical Refinement in OPM

Authors

NataliaKwasnikowska and JanVanDenBussche, August 14, 2009

Subject

Refinement relation proposed in OPM V1.01.

Background

The refinement relation introduced in OPM V1.01 allows the declaration of pairs of accounts, where one account provides a more detailed view of execution than the other one.

Problem addressed

Current specification does not however provide a methodology for structuring accounts so that multiple refinements, about different parts of a past execution, can be independently included or excluded in a view. Such a methodology should also accommodate hierarchical refinement, in which a refinement can have itself certain parts that can be further refined.

Proposed solution

Please see the attached document.

Rationale for the solution

Hierarchical refinements are particularly useful for providing different levels of detail for execution of nested processes or generation of artifacts. Our methodology provides a solution for modeling multiple hierarchical refinements and an easy way of identifying which configurations of those refinement accounts can be simultaneously presented in a view.

Comments

Community is invited to provide comments on proposals.

comment 1

-- JimMyers - 17 Sep 2009

I'm not sure I understand in a concrete way what is being proposed in terms of the OPM spec. Refines is already defined as is overlaps - seems like I could implement the hierachy proposed using just those constructs. Granted this is a useful use case that shows why one witness might want to provide multiple levels of refinement (we usually discuss refinement and overlap from the prspective of multiple who saw different parts or different granularities), but I'm not sure what has to change in OPM to accomodate this use.

comment 2 by Luc Moreau

No doubt that more work needs to be done on accounts, and their relationships (e.g. overlaps, refines). I think this proposal is interesting. For completeness, I would have liked to see the two examples spelled out in full, with the set RefAcc of accounts specified fully, and the various relations defined in full also.

I think that there may be some unnecessary restrictions:

why is there a bijection from refinee to refiner? One of the key motivations of accounts is to allow for alternative descriptions. In Fig 1, alpha Q- seems to be allowed to be refined in one and only one way. Why?
The latter point seems to indicate that we want to be able to combine alternate and refine relationships. e.g. alpha1 < (alpha2 or alpha3)
I am not sure of this notion of switching on/off refinements. How does it relate to union of accounts?
Why do we have a notion of upward-closed sets? Imagine we have three levels of accounts: end-user, functional, operational, providing three different levels of abstraction about a given execution. I think it's fine to combine end-user and operational without having to consider functional.
What's the meaning of erasing accounts? Removing all elements member of this account?

comment 3 by Luc Moreau

This proposals was put under the heading "profile" though it does not mention the word "profile". I think this is currently not a profile since it does not offer a translation of OPM with hierarchical refinements into OPM without hierarchical refinements.

Comment 4 by Simon Miles

My main concern for this document is that I can't see under what circumstances someone would apply it. It needs to be clarified who is to read it and when. Is it clarifying the semantics of OPM or aiding a designer deciding what to record from their application?

Specific technical questions

The root account graphs appear to be disconnected. For example, in the root account for Figure 1, there is no connection between B2 and the other nodes, because we cannot infer any connection to B1 (ChangeProposalWasDerivedCannotBeInferred). Is a disconnected graph really a coherent view?
Why is it reasonable to assume there will only be one refinement of each account?
What is the type or meaning of the relationships in H (section 1)? They do not appear to be refinements, as the RHS does not describe all the same process in the LHS of each relation (-A does not refine root).
Why must H form a hierarchy?
It would be helpful to use different symbols in the two examples, as I got confused in the discrepancy between Figures 1 and 2.
In Figure 2's example, you refine artifact A into sequence A1 - Q - A2, and say that the latter "gives more detail about artifact A". What does this mean? Artifacts are constant in OPM, so what more detail is there to give?
In Section 3, you say that Refinee account is "not containing the root". This does not seem to match the prior examples, where nodes in root are also nodes in the refinee and refiner accounts.

comment 5 by Luc Moreau (to comment 4)

Simon wrote "gives more detail about artifact A". What does this mean? Artifacts are constant in OPM, so what more detail is there to give? Paul and I in our translation of pasao to opm and versa came across this requierement. For instance, a given artifact seen at given level of abstraction is in fact a sent artifact and a received artifact in a refinement making communications explicit.

comment 6 by Luc Moreau

Can you illustrate how your approach deals with the following example:

P is refined into P1 -> P23
P is refined into P12 -> P3
P23 is refined into P2 -> P3
P12 is refined into P1 -> P2

The fully refined process P1 -> P2 -> P3 seems to have two ancestors here. Do you support it? Thanks,

comment 7 by Jan & Natalia

At the workshop in Amsterdam June 2009 several people asked for more guidance on how to model refinements using OPM. Our purpose here is to make a proposal for this. Whether this counts as a "profile" is not so important. If people prefer to classify this elsewhere we are fine with that. At any rate, in the end, we do use only core features of OPM, notably, accounts, refinement pairs, and union of OPM graphs, and the notion of legality in that any artifact can have at most one generated-by edge, albeit applied to a union of accounts. But we do add one extra piece of information, namely, a hierarchy H on refinement accounts. Such information is not present in OPM.

The criticisms concerning only one refiner per refinee, and concerning the restriction that H must be a hierarchy, are valid, and we think the methodology can and should be extended to allow for a DAG rather than a tree structure, and to allow for alternative refiners. This needs further research and we will update our proposal to accommodate these criticisms.

What means switch on or off simply means that we do, or do not, give the additional detail provided by the refiner. Indeed this is all implemented using union of views.

Regarding Luc's question (comment 2) on a non-upward-closed set of accounts; can you give a concrete example?

Simon Miles comment 3: yes a root account in itself may well be a disconnected graph, but it is never taken by itself, at the least it is taken together (union) with the refinee accounts of its children in the hierarchy.

Simon Miles comment 3: the hierarchy H is something added by our methodology, it is not intended to be implemented using an existing feature of OPM.

Comment 8 by PaoloMissier

This is interesting and I appreciate the effort out so far in this work. To address specifically the question on whether this should be further developed, I'd say certainly yes.

One the other hand, I am not expressing a vote as I am not sure what is there to approve at this stage: this reads more like a recommendation for a specific refinement pattern, than something that extends OPM, or should otherwise be prescribed. Is this meant to be a pattern whose adoption we encourage?