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 11123: BPMN Universal Process is a bad name
Issue 12177: Happening part multiplicty
Issue 12178: Section: Happening and Change
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 11123: BPMN Universal Process is a bad name (bpdm-ftf)

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

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. 

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.