Business Process Definition Metamodel Avatar
  1. OMG Specification

Business Process Definition Metamodel — All Issues

  • Acronym: BPDM
  • Issues Count: 14
  • Description: All Issues
Closed All
All Issues

Issues Descriptions

Events occur in the context of exactly one Happening Over Time

  • Key: BPDMF2-51
  • Legacy Issue Number: 12217
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    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.

  • Reported: BPDM 1.0b2 — Sat, 9 Feb 2008 05:00 GMT
  • Disposition: Resolved — BPDM 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Merge Happening Model with Course Model

  • Key: BPDMF2-50
  • Legacy Issue Number: 12216
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    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.

  • Reported: BPDM 1.0b2 — Sat, 9 Feb 2008 05:00 GMT
  • Disposition: Resolved — BPDM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Course Part conditions on successions

  • Key: BPDMF2-49
  • Legacy Issue Number: 12215
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    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.

  • Reported: BPDM 1.0b2 — Fri, 8 Feb 2008 05:00 GMT
  • Disposition: Resolved — BPDM 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Common Infrastructure

  • Key: BPDMF2-48
  • Legacy Issue Number: 12207
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    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.

  • Reported: BPDM 1.0b2 — Sat, 2 Feb 2008 05:00 GMT
  • Disposition: Resolved — BPDM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Happening and Change

  • Key: BPDMF2-47
  • Legacy Issue Number: 12206
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

  • Reported: BPDM 1.0b2 — Fri, 1 Feb 2008 05:00 GMT
  • Disposition: Resolved — BPDM 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

spec doesn't provide a unified way to specify and represent link references

  • Key: BPDMF2-42
  • Legacy Issue Number: 12181
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    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.

  • Reported: BPDM 1.0b2 — Wed, 16 Jan 2008 05:00 GMT
  • Disposition: Resolved — BPDM 1.0
  • Disposition Summary:

    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>

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Simple Interaction

  • Key: BPDMF2-41
  • Legacy Issue Number: 12180
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

  • Reported: BPDM 1.0b2 — Wed, 16 Jan 2008 05:00 GMT
  • Disposition: Resolved — BPDM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 6.7

  • Key: BPDMF2-45
  • Legacy Issue Number: 12199
  • Status: closed  
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

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

  • Reported: BPDM 1.0b2 — Fri, 25 Jan 2008 05:00 GMT
  • Disposition: Resolved — BPDM 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

representation of multiple inheritance

  • Key: BPDMF2-44
  • Legacy Issue Number: 12183
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    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.

  • Reported: BPDM 1.0b2 — Wed, 16 Jan 2008 05:00 GMT
  • Disposition: Resolved — BPDM 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Happening part multiplicty

  • Key: BPDMF2-39
  • Legacy Issue Number: 12177
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    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.

  • Reported: BPDM 1.0b2 — Wed, 16 Jan 2008 05:00 GMT
  • Disposition: Resolved — BPDM 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Happening and Change

  • Key: BPDMF2-40
  • Legacy Issue Number: 12178
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    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.

  • Reported: BPDM 1.0b2 — Wed, 16 Jan 2008 05:00 GMT
  • Disposition: Resolved — BPDM 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Universal Behavior should be named Behavior Occurrence.

  • Key: BPDMF2-46
  • Legacy Issue Number: 12205
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    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.

  • Reported: BPDM 1.0b2 — Fri, 1 Feb 2008 05:00 GMT
  • Disposition: Resolved — BPDM 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

reference representation of property

  • Key: BPDMF2-43
  • Legacy Issue Number: 12182
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    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.

  • Reported: BPDM 1.0b2 — Wed, 16 Jan 2008 05:00 GMT
  • Disposition: Resolved — BPDM 1.0
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT

BPMN Universal Process is a bad name

  • Key: BPDM-39
  • Legacy Issue Number: 11123
  • Status: closed  
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

    BPMN Universal Process is a bad name

  • Reported: BPDM 1.0b1 — Tue, 10 Jul 2007 04:00 GMT
  • Disposition: Resolved — BPDM 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT