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