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

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

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

Error in the superset of 'owned behavioral connection'

Missing Comment on Terminate

Missing notation for the 'End' Behavioral Change

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

Wrong SuperType for EmbeddedProcess

ownedInteraction should belong to Interactive Processing Behavior

Statement should be a Packageable Element

Generalization should be in Infrastructure, not CommonAbstraction

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.

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

There is no way to have conditions on Facts

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

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.

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

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

Property should not be navigable

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 »

There is a need to have ends that are logical failure

BPMN Universal Happening should use sub-properties

Useless ownership association between Behavioral Step Group and Processing Behavior

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

BPDM should provide metamodel supports for these new shapes.

Missing notation for the 'Start' Behavioral Change

Time Change should not be abstract

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.

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

CommonAbstractions' should be an independant Package

Typo error in 'conditionning behavioral step'

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

Sub-Properties are not used in the Universal Happening

Statement should belong to the Composition Model

involved interactive part has the same name has its superset

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

p 98 – second paragraph “emdedded”

third paragraph “emdedded”

Missing notation for Interaction Role

specified fact change condition' shouldn't have a superset

Align with Classifier from Infrastructure

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.

This belongs in Course, where the events are course events. In a Course Model library, define specializations for Course Events, with association between Course Occurrence and Course event (induced event occurrence) multiplicity 1 on the Course Event End.
No revised text:
See changes in Course Model Library. You can refer to changes in Issue 12216 (Merge Happening Model with Course Model).

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.

HappeningPart are Typed Course Part are merged
. Happening Succession is merged into succession
. Behavior is merged into Course
. Behavioral Event is renamed Course Event
. Course is made concrete
. Succession is made concrete
. Behavior Succession is merged with Succession
. Immediate Processing Succession is merged with Immediate Succession
. Behavioral Event Condition is renamed Behavior Event Condition
. In the entire document, the term 'processing' is replaced by 'behavior'
. Processing Behavior is renamed into Behavior

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.

Add two associations on Typed Course Part
previous succession condition
next succession condition
. Add an M1 library: 'Common Infrastructure Library'
. Add two 'Conditions' owned by the 'Common Infrastructure Library'.
AllSuccessions : Condition requiring all successions to be satisfied (AllSuccession) before the execution of a Typed Course Part.
OneSuccession: Condition requiring only one succession to be satisfied before the execution of a Typed Course Part.

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.

Rename the 'Common Abstractions' package into 'Common Infrastructure'
. Merge Core:Abstractions and Core:PrimitiveTypes into 'Common Infrastructure'
. Update the 'Namespaces" package with all elements contained Constructs.
. Add a new 'Packages' packages to 'Common Infrastructure:Abstractions'. It includes all elements of Constructs:Package, except 'PackageMerge'.
. Introduce a new class called 'ImportableElement' in Abstractions::Namespaces that takes the place of PackageableElement. It generalizes PackageableElement in Abstractions::Packages.
. Remove the Visibilities package from Core:Abstractions
. Move PackageImport and PackageableElement from Abstraction::Namespaces to Abstraction::Packages.
. PackageableElement generalizes Type in Abstractions.
. Merge the Changeabilities package into the StructuralFeatures package.
. Add a new 'Properties' package in Abstractions that contains Property.
. Add a new 'Datatypes' package in Abstractions that has the content of the Datatype Diagram of Constructs, except the associations with Operations.
. Change the dependencies with 'Common Infrastructure' to take into account the packages.
. Separate the BPDM document in two parts: Common Infrastructure, Process Definitions

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

Resolution:
Solved by resolution of issue 11593 where the 'Happening and Change' package had been renamed into 'Happening Model'.

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.

Resolution:
A new xmi_infra.xsd schema is created to host the XML attributes to provide validation of reference in the context of XML schemas.
The LinkAttribs complex type allows either for id/IDREF references and id/href references.

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
targetNamespace="http://schema.omg.org/spec/XMI/2.1"
>

<xsd:include schemaLocation="../../../XMI/20071213/xmi.xsd"/>

<xsd:attribute name="idref" type="xsd:IDREF"/>
<xsd:attribute name="label" type="xsd:string"/>
<xsd:attribute name="referenceTypeID" type="xsd:QName"/>

<xsd:complexType name="LinkAttribs">
<xsd:attribute ref="xmi:label" use="optional"/>
<xsd:attribute ref="xmi:idref" use="optional"/>
<xsd:attribute name="href" type="xsd:string" use="optional"/>
<xsd:attribute ref="xmi:referenceTypeID" use="optional"/>
</xsd:complexType>

</xsd:schema>

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

Resolution:
Associations:
. The "source internal interaction" property is now owned by "simple interaction"
. The "target internal interaction" property is now owned by "simple interaction"
. The "Simple Interaction Binding" metaclass is deleted

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

The 'Simple Interaction' package is renamed into 'Interactive Behavior Model'.

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.

1. Apply org.omg.xmi.useExtension=true to top package
2. Use the folowing multiple inherintance algorithm for XMI serialization

A. The mainSuperType tag is taken into account only at one level.
B. Properties coming from the main super-type and its hierarchy (without distinguishing between main or not main super-types) are not copied.
B. Properties coming from the other super-types and their super-type hierarchy (without distinguishing between main or not main super-types) are copied expect for those properties that comes from classes that are also in the main-super type hierarchy (see previous).

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.

Resolution:
Happening parts in general can potentially value multiple M0 events as values or none. The multiplicity minimum and minimum of start and end event parts should be 1. The minimum multiplicity of the other event parts in the Happening Model library should be zero and the maximum 1. Process steps do not necessarily have a minimum multiplicity of 1. That would require the step to execute at least once, which it might not, depending on the process definition. The default lower and upper multiplicity from Abstractions:MultiplicityElement is 1.
It must be 0..* for BPDM typed parts.

Revised Text:
Revised Class Revised Text
Typed Part Section 6.3.2.19 (Typed Part) of the DTC/07-12-01 document add new subsection Constraints, with the following:[1] The default values for lower and upper (from Abstraction:MultiplicityElement) are 0 and * respectively.context TypedPart::lower: Integerinit: 0context TypedPart::upper: UnlimitedIntegerinit: *

Revised Diagram: BPMN Extensions Library: BPMN Process Occurrence Instance
Section 6.9.2.5 (BPMN Extensions Library) of document DTC/07-12-01, Figure 6.100, add upper properties to the Compensate and Cancel event parts and give them values of 1

Revised Diagram: Common Infrastructure Library: 'Happening Occurrences'
Section 6.5.2.4 (the Happening Model library), Figure 6.22 of the DCT/07-04-01 , add lower and upper properties to the Start and End event parts and give them values of 1.

Resolution Status:
Resolved.

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.

Resolution:
The constraint could be expressed with disjointness between M1 event classes, but Abstraction does not support disjointness, and UML disjointness requires an M1 Behavior Event supertype.
Use OCL constraints on the M1 event parts.

Revised Text:
Revised Instance Revised Text
Behavior Occurrence Section 6.5.2.47 (Instance: Universal Behavior, renamed to Behavior Occurrence in resolution to Issue 12205) of document DCT/07-12-01, add subsection Constraints, with the following:[1] Normal End and Abnormal End cannot have values at the same time. not (self.Normal End->notEmpty() and self.Abnormal End->notEmpty())[2] Failure and Success cannot have values at the same time. not (self.Failure->notEmpty() and self.Success->notEmpty())[3] Abort and Error cannot have values at the same time. not (self.Abort->notEmpty() and self.Error->notEmpty())
Course Occurrence In the new section on 'Course Occurrence add subsection Constraints, with the following:[1] Start and End event parts cannot have the same values. not self.Start = self.End

Resolution Status:
Resolved.

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.

. 'Universal Behavior' is renamed into 'Behavior Occurrence'
. 'BPMN Universal Process' is renamed into 'Process Occurrence'

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.

Resolution:
1. Apply org.omg.xmi.elemt=true to the top package.
2. Use the LinkAttribs complex type as the XML type of elements representing references

BPMN Universal Process is a bad name

No Data Available