Issues for 2nd BPDM Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 11121: Align with Classifier from Infrastructure
Issue 11122: BPMN Universal Happening should use sub-properties
Issue 11124: Cancel shouldn't be in the 'Happening and Change' library
Issue 11125: CommonAbstractions' should be an independant Package
Issue 11126: Error in the superset of 'owned behavioral connection'
Issue 11127: Generalization should be in Infrastructure, not CommonAbstraction
Issue 11128: involved interactive part has the same name has its superset
Issue 11129: involving interaction-involved interactive part' should be a derived union
Issue 11130: Missing Comment on Terminate
Issue 11131: Missing notation for Interaction Role
Issue 11132: Missing notation for the 'End' Behavioral Change
Issue 11133: Missing notation for the 'Start' Behavioral Change
Issue 11134: monitored change condition' should be owned by 'Change Condition Step'
Issue 11135: ownedInteraction should belong to Interactive Processing Behavior
Issue 11136: Property should not be navigable
Issue 11137: specified fact change condition' shouldn't have a superset
Issue 11138: Statement should be a Packageable Element
Issue 11139: Statement should belong to the Composition Model
Issue 11140: Sub-Properties are not used in the Universal Happening
Issue 11141: Processing Behavior Package and Simple Interaction Package
Issue 11142: There is a need to have ends that are logical failure
Issue 11143: There is no way to have conditions on Facts
Issue 11144: Time Change should not be abstract
Issue 11145: Typed Part' should be a sub-type of 'Property'
Issue 11146: Typo error in 'conditionning behavioral step'
Issue 11147: Useless ownership association
Issue 11148: Wrong SuperType for EmbeddedProcess
Issue 11149: There is a need to have 'ends' that are logical success
Issue 11235: Section: 4.4.2.5
Issue 11236: Section: 4.4.2.11
Issue 11305: BPDM Beta 1 document dtc/07-07-01, in Section 6.3.2.6, page 35
Issue 11335: Parallel Join
Issue 11336: Description of succession
Issue 11592: BPDM XML Namespace
Issue 11593: BPDM FTF - Alignment with BPMN 1.1
Issue 11603: Spelling error in Activity Model description
Issue 11821: BPDM RTF Issue: Explicit modeling of decisions vs BPDM
Issue 12179: Section: Activity

Issue 11121: Align with Classifier from Infrastructure (bpdm-ftf)

Align with Classifier from Infrastructure

BPMN Universal Happening should use sub-properties

Cancel shouldn't be in the 'Happening and Change' library

CommonAbstractions' should be an independant Package

Error in the superset of 'owned behavioral connection'

Generalization should be in Infrastructure, not CommonAbstraction

involved interactive part has the same name has its superset

involving interaction-involved interactive part' should be a derived union

Missing Comment on Terminate

Missing notation for Interaction Role

Missing notation for the 'End' Behavioral Change

Missing notation for the 'Start' Behavioral Change

monitored change condition' should be owned by 'Change Condition Step'

ownedInteraction should belong to Interactive Processing Behavior

Property should not be navigable

specified fact change condition' shouldn't have a superset

Statement should be a Packageable Element

Statement should belong to the Composition Model

Sub-Properties are not used in the Universal Happening

The Processing Behavior Package and Simple Interaction Package have a circular dependency

There is a need to have ends that are logical failure

There is no way to have conditions on Facts

Time Change should not be abstract

Typed Part' should be a sub-type of 'Property' instead of 'MultiplicityElement'

Typo error in 'conditionning behavioral step'

Useless ownership association between Behavioral Step Group and Processing Behavior

Wrong SuperType for EmbeddedProcess

There is a need to have 'ends' that are logical success

The association end name "specified happening condition" for the association between Change and Change Condition must be replaced by "specified change condition".

In Figure 27, the text below the circle must be "End" instead of "Finish"

In the BPDM Beta 1 document dtc/07-07-01, in Section 6.3.2.6, page 35, the document reads


The default succession is represented by a default Marker that MUST be a backslash near the beginning of the line representing the Succession.


However, the diagram accompanying the statement shows a *FORWARD* slash. *twice*, in fact.

From Sylvain:

p 46 – Parallel Join : in the sentence « Parallel Join is a Course Control Part Indication that the parts (in the sense of individuals) following it happen after the parts preceding them »

 Is the word « individuals » really appropriated ? We are positioning M0 elements (individuals) in perspective of M1 elements (Course Control Part) which have no M0 enactment...

ð       Antoine

The parts mentioned in the description are the “following” parts (successor parts) of the course control part. These successors are usually a “typed course part” that represents.

We could do two things to clarify the sentence:

1.      Verify that the term (individual) is explicity used other the specification as referencing M0 elements

2.      Change the sentence to mention “typed course part”

« Parallel Join is a Course Control Part Indication that the typed course parts (in the sense of individuals) following it happen after the typed course parts preceding them »

From Sylvain:

p 47 – Succession : in the sentence “ A Succession indicates that that one Course Part ‘follows’ another in time ”

        Is  this really true ? After all if we have:

 Task A -à Task B


        With an immediate succession between Task A and Task B, then Task A and B will be enacted at the same time, and Task A might actually last longer than Task B effectively contradicting the above statement since an ‘Immediate Succession’ is a kind of ‘Succession’.



ð       Antoine

“Follows” include the fact that it  could start at the same time. It says nothing about the duration (or the end) of task A versus task B

I think Conrad had a better explanation in the discussion he had with Steve White. 

Conrad, could you please help clarify the sentence.

BPDM and BPMN are shortly going to merge in the next BPMN2 RFC. 

In order to ensure continuity between these various RFC, BPDM should use “bpmn” as its XML Namespace.

BPDM 1.1 has added some new shapes to the initial BPDM 1.0 specification.

BPDM should provide metamodel supports for these new shapes.

p 98 – second paragraph “emdedded”

        third paragraph “emdedded”

At the BMI meeting on 10Dec07/Burlingame, there was a discussion on decision modeling and its relationship to existing modeling needs and standards. An action from the meeting was to raise the question of whether decision modeling was explicitly, or could explicitly, be “handled” within BPDM (and consequently, whether BPDM should model decisions more explicitly). 

 

{This was considered a possible issue for the BPDM(BPMN)2 RFP, but I am raising it with the FTF on the basis that it is up to the FTF to determine whether any “issue” is for a future version or not.}

 

Comments:

From my understanding of BPDM, a decision activity can simply be a BPDM activity, and modelled via Behavioral Step / Change Condition Step, which is probably too low level to be useful for talking about decisions in processes, but may be necessary for mapping decisions into processes. 


This is going to be difficult to answer without a formal definition of a decision model. And I am not going to define one at this stage of discussions! J However, it is probably safe to assume that a Decision Table is an instance of a Decision Model. And that invoking decision tables (and services) in BPM activities is pretty common. So hopefully the concept is not too alien to the BPM community. Disclaimer: of course issue may be revised as the terminology is refined. 


Personally, I think the answer is “yes” in that decision processes in BPDM (1/2) can accommodate decision services and processes (eg as custom external activities prior to a BPMN gateway), but BPDM (1/2) does not include business-level decision modeling, and that decisions and process are probably orthogonal, and that BPDM should simply reference any future decision model as a special activity as required.


Related to this is some of the BPDM positioning I have seen which implies a (SBVR-type) business rule is also embedded in processes. It is far more likely that SBVR type business rules dictate and direct the development of processes, and impact their behaviour, rather than are directly included in processes. At best there is traceability from process definition to SBVR business rule and BMM constructs. Much more likely is the idea that processes embed decisions and “operational business rules” (rules with behaviour, IMHO) (which typically are represented as production rules in automated processes). 

first iteration guard. The "first iteration" guard on successions from IterationEnd should have OCL specified.