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 11123: BPMN Universal Process is a bad name
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 12177: Happening part multiplicty
Issue 12178: Section: Happening and Change
Issue 12179: Section: Activity
Issue 12180: Section: Simple Interaction
Issue 12181: spec doesn't provide a unified way to specify and represent link references
Issue 12182: reference representation of property
Issue 12183: representation of multiple inheritance
Issue 12199: Section: 6.7
Issue 12205: Universal Behavior should be named Behavior Occurrence.
Issue 12206: Section: Happening and Change
Issue 12207: Common Infrastructure
Issue 12215: Course Part conditions on successions
Issue 12216: Merge Happening Model with Course Model
Issue 12217: Events occur in the context of exactly one Happening Over Time

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

Align with Classifier from Infrastructure

BPMN Universal Happening should use sub-properties

BPMN Universal Process is a bad name

Guidelines for representing the initialization code have to be clarified. Initialization code should be
uniformly represented as BlockUnit elements. Also, the EntryFlow element has to be made more
generic (without affecting existing KDM XMI). Generalize EntryFlow : the new “from” endpoint
should be AbstractCodeElement instead of ControlElement and the “to” endpoint should remain
ActionElement. In this case it can be used for any type of special flows, e.g. entry to a
CodeAssembly to init Block or action, from Module to init block, from callable unit to init block,
from class to init block or from compound action to the first internal action. This is consistent with
the decision to represent initialization code as BlockUnit.
Add the following text to Semantics, section 12.19.2 HasValue class, page 106:
1) represent initialization code as BlockUnit element with special micro action kind “init”
2) initialization code can belong to a ControlElement, CompilationUnit or CodeAssembly
3) The EntryFlow relationship is used in a uniform way for describing entry points to other
KDM code elements. It should be used for any type of special flows, e.g. entry to a
CodeAssembly to init Block or action, from Module to init block, from callable unit to init
block, from class to init block or from compound action to the first internal action.
4) The CodeAssembly should have custom initialization code that consists of an ordered
sequence of EntryFlow relations to the initialization blocks of the owned CompilationUnits
(and other owned elements when appropriate), followed by a call to the logical entry point
(for example, the CallableUnit “main”). Change text for the EntryFlow class (page 134, section 13.5.2):
The EntryFlow is a modeling element that represents an initial flow of control into a KDM
element. The EntryFlow relationship is used in a uniform way for describing entry points to
other KDM code elements. It should be used to represent any type of special entry flows,
such as the entry from a CodeAssembly to the initialization code Block or action, from Module
to initialization block, from a callable unit to the inititialization block, from a class to the
initialization block or from a compound action to the first internal action. Correct the initialization example at pages 116-118 (initialization code in BlockUnit with kind=”Init”
Add micro element to Table A.4 page 296.
Init BlockUnit
that
contains
initialization
action
elements
none none EntryFlow
unconditional
control flow to
the first internal
action

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

Happening part multiplicty. M1 instances of Happening Part should have a multiplicity maximum of 1. The minimum should be one for some of the event parts, such as start and end, and for processing steps. This can be expressed as OCL or with additional parts in the M1 libraries with multiplicies, that are superproperties of user happening parts. 

Constraints on part disjointness. Constraints on part disjointness should be expressed in OCL. For example, abort and finish can't both have values on the same M0 execution. 

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

Simple interaction binding can be replaced with two associations from Simple Interaction to itself, using the style of Processing Succession

The specification doesn't provide a unified way to specify and represent link references. It is currently possible to use either IDREF or href. Furthermore, no standard URI representation is made mandatory. The lack of mandatory reference scheme prevents to ensure interoperability when xmi models are organized in multiple xml files. 

The reference representation of property should not provide the choice between attribute and element. This prevent from using a standard referencing scheme such as XLINK as XLINK cannot be managed as a single attribute. The lack of formal unification of reference representation of properties prevents interoperability between XMI specifications that uses multiple xml documents.

The representation of multiple inheritance prevents from using XSD extension mechanism. As a results, it is impossible to serialize properties which have an abstract type, the sub-type of which having multiple super-type. This is a major issue as it prevents from building a proper, sharable XSD stack.

The chapter called "Simple Interaction Model" is in fact about "Interactive Behavior". It should be renamed as such.

Universal Behavior should be named Behavior Occurrence. The term "behavior" is used in the metamodel to mean a type of M0 behavior. The M1 library elements, including Universal Behavior, are referring to M0 occurrences of behaviors. 

The Happening and Change Model should be called the Behavior and Event Model. The Change element was renamed to Event in FTF 1. 

Common Infrastructure. Abstractions should support serialization by itself and interoperably with serialization of Constructs. In particular: Abstractions should support serialization by itself and interoperably with serialization of Constructs. In particular: Package and Property should be available in Abstractions, to enable Abstractions to be used for serialization of typical models by itself. - There should be no circular dependencies between packages in Abstractions. Constructs should only use imports from Abstractions, to enable models using Constructs to interoperate with models using only Abstractions. Package merge produces noninteroperable XSDs. 

Course Part conditions on successions. The semantics of succession requires all successions coming into a typed course part to satisfied for the course part to start, and satisfies all succession going out of the typed course part when the part is finished. The semantics of courses varies among process languages. The course model should support any condition or combination of incoming successions to start a tyoed course part, and the same for outgoing successions. 

Merge Happening Model with Course Model. The Course Model is not currently a reusable module. It implicitly uses the concepts of start and end, which are introduced in the Happening Model. Merge the Happening Model into the Course Model. 

Events occur in the context of exactly one Happening Over Time. This constraint should be captured in a model library between Event Occurrence and Happening over Time Occurrence.