BPM+ Knowledge Package Model and Notation Avatar
  1. OMG Specification

BPM+ Knowledge Package Model and Notation — Open Issues

  • Acronym: BKPMN
  • Issues Count: 19
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

BKPMN metamodel is not valid MOF

  • Key: BKPMN-21
  • Status: open  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    It has unnamed Associations and Properties which are not permitted

  • Reported: BKPMN 1.0a1 — Mon, 22 Aug 2022 03:48 GMT
  • Updated: Mon, 22 Aug 2022 03:48 GMT

Add Labels for all BHMN Metamodel Relationships

  • Key: BKPMN-19
  • Status: open  
  • Source: BPM Advantage Consulting ( Stephen White)
  • Summary:

    to be MOF compliant

  • Reported: BKPMN 1.0a1 — Mon, 18 Jul 2022 19:48 GMT
  • Updated: Mon, 18 Jul 2022 19:48 GMT

Add Labels for all BKPMN Metamodel Relationships

  • Key: BKPMN-18
  • Status: open  
  • Source: BPM Advantage Consulting ( Stephen White)
  • Summary:

    to be MOF Compliant

  • Reported: BKPMN 1.0a1 — Mon, 18 Jul 2022 19:48 GMT
  • Updated: Mon, 18 Jul 2022 19:48 GMT

Simplify SDMNDI based on SCEDI

  • Key: BKPMN-16
  • Status: open  
  • Source: BPM Advantage Consulting ( Stephen White)
  • Summary:

    Update the spec, metamodels, and xsds.

  • Reported: BKPMN 1.0a1 — Tue, 3 May 2022 20:32 GMT
  • Updated: Tue, 3 May 2022 20:32 GMT

PackageElement over-specified?


Simplify BKPMNDI based on SCEDI

  • Key: BKPMN-15
  • Status: open  
  • Source: BPM Advantage Consulting ( Stephen White)
  • Summary:

    Update the spec, metamodels, and xsds.

  • Reported: BKPMN 1.0a1 — Tue, 3 May 2022 20:27 GMT
  • Updated: Tue, 3 May 2022 20:27 GMT

Editing Error

  • Key: BKPMN-14
  • Status: open  
  • Source: BPM Advantage Consulting ( Stephen White)
  • Summary:

    Text in the description doesn't match the contents of the section. There are too many items referenced.
    The text "BKPMNEdge can be used to represent an Ownership Connector, Parent-Child Connector, Relationship Connector, or a Data Association." includes elements not in the section. Only the Relationship Connector is in the section.

  • Reported: BKPMN 1.0a1 — Mon, 2 May 2022 17:12 GMT
  • Updated: Mon, 2 May 2022 17:12 GMT

Copy/Paste Errors in BKPMNShape Resolution Section

  • Key: BKPMN-13
  • Status: open  
  • Source: BPM Advantage Consulting ( Stephen White)
  • Summary:

    The first sentence in the section lists the SCE Diagram shapes, not the BKPMN Diagram shapes.
    The sentence above Table 67 and the header for Table 67 use the term "Data Items" (from SDMN), but should say "BKPMN Diagram Elements"

  • Reported: BKPMN 1.0a1 — Tue, 26 Apr 2022 17:14 GMT
  • Updated: Tue, 26 Apr 2022 17:14 GMT

classes BKPMNPackageInputs and BKPMNPackageOutputs appropriate at BKPMN level?

  • Key: BKPMN-11
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    I would expect to see formal models of these classes at the BPMN/CMMN levels, and / or SDMN, and for BKPMN possibly to just have the ability to extract a total set of data items from the constituent plans.

  • Reported: BKPMN 1.0a1 — Sun, 24 Apr 2022 16:04 GMT
  • Updated: Mon, 25 Apr 2022 13:34 GMT

Class Applicability - various

  • Key: BKPMN-10
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    The section header is 'Determining Applicability' - is this correct?

    According to the documentation, Applicability appears to be a computational model of entry or pre-conditions to be matched when determining applicable plans at runtime. Such conditions would normally be defined on the plans themselves. I would expect just a documentary description of applicability at the BKPKMN package level.

    I would expect to see a process like that shown in Figure 18 (Process for Determining the Applicability of a BKPMN Package) to be defined in BPMN and CMMN, not BKPMN.

  • Reported: BKPMN 1.0a1 — Sun, 24 Apr 2022 16:02 GMT
  • Updated: Mon, 25 Apr 2022 13:34 GMT

Better name for Measure class?

  • Key: BKPMN-9
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Based on the documentation, 'Metric' would be a more obvious name for this class. The word 'Measure' is usually associated with units of measure.

  • Reported: BKPMN 1.0a1 — Sun, 24 Apr 2022 16:01 GMT
  • Updated: Mon, 25 Apr 2022 13:34 GMT

Class ImpactKind appropriate at BKPMN package level?

  • Key: BKPMN-8
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Similar comment as for Effect - is this really relevant at the BKPMN package level, rather than at the level of constituent plans?

  • Reported: BKPMN 1.0a1 — Sun, 24 Apr 2022 15:59 GMT
  • Updated: Mon, 25 Apr 2022 13:33 GMT

Effect semantics unclear

  • Key: BKPMN-7
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    It is not clear why a BKPMN package would need 'Effect' elements - are they meant to document post-conditions of the execution of a BPMN plan? If so, they should be built into the plan definition, not into the containing package. A containing package could have more than one plan...

    Description says: An Effect is some change to the environment or data that may occur when the behaviors of BPM+ Knowledge Package is performed. The bold part implies that a change in pretty much anything can be an 'effect'. Possibly something like 'change to a state variable within the case (entity or system) on which a workflow is executing' might be better.

    Attributes like eventRef, impactKindRef etc would seem to be replicating what are likely to be goals or post-conditions stated within BPMN or CMMN plans contained within a BKPMN package. Is this the intention? If multiple plans are grouped together in one BKPMN package, is the set of events/milestones, impacts etc obtained by summing all such elements from the constituent plans?

  • Reported: BKPMN 1.0a1 — Sun, 24 Apr 2022 15:58 GMT
  • Updated: Mon, 25 Apr 2022 13:33 GMT

KnowledgeElement subclassing approach fragile?

  • Key: BKPMN-6
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    The approach to defining kinds of knowledge element using subclassing seems likely to be fragile in the longer term - each time a new subtype is needed, the standard has to be re-issued. I don't see any obvious logic or theoretical basis for the collections of types Applicability, Effect, LifecycleEvent, Measure, RiskFactor, and Recommendation.

    It seems to me that Applicability, Effect, Impact, etc should just be kinds of documentation rather than structurally modelled items. And they probably should not be fixed either - different BPMN / CMMN plans will have different ways of documeting things.

  • Reported: BKPMN 1.0a1 — Sun, 24 Apr 2022 15:56 GMT
  • Updated: Mon, 25 Apr 2022 13:33 GMT

BKPMNInstances semantics

  • Key: BKPMN-5
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    It is not clear from the description of this class what the purpose of 'instances' in a BKPMN package is. If the model were a BPM+ workflow + DMN logic, are the instances example (or real) runs?

  • Reported: BKPMN 1.0a1 — Sun, 24 Apr 2022 15:55 GMT
  • Updated: Mon, 25 Apr 2022 13:33 GMT

BKPMNModel attributes - various.

  • Key: BKPMN-4
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Class BKPMNModel attributes:

    purpose: has its own type Purpose. Couldn't the purpose be included in inherited documentation? I would have expected that there could have been an attribute SCEElement.purpose: Documentation might have been just as good, and one less class.
    manifest: is the manifest not generatable from the structure? Maintaining a separate documentary manifest is likely to duplicate and become inconsistent w.r.t. the Model structure.

  • Reported: BKPMN 1.0a1 — Sun, 24 Apr 2022 15:36 GMT
  • Updated: Mon, 25 Apr 2022 13:32 GMT

BKPMNModelPackage attributes may be difficult to maintain and understand in data and software.

  • Key: BKPMN-3
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Class BKPMNModelPackage has 6 attributes in addition to those inherited from SCEModelPackage. Is it clear that these attributes are not more generally applicable, and could be included at the SCE level?

    Attributes:

    completed: might not be easy to maintain; the approach we use is semver.org, and sub-v1.0.0 versions for drafts, and for later major versions, v2.0.0-rc17 versoin strings.
    published: attribute likely to be difficult to maintain. The rules for maintaining this attribute value in sync with the version and versionDate attributes are somewhat arcane.
    jursidiction: This attribute defines the countries or other areas (such as states) where the BKPMNModelPackage is in effect.
    likely to be problematic to keep up to date. Attributes to do with use of models should not normally be in said models
    effectivePeriodStard, effectivePeriodEnd: for similar reasons, likely to be difficult to establish values and difficult to maintain over time.

    It would appear from the documentation that the completed, published, version and versionDate attributes are really trying to express phases of an artefact lifecycle, but in a complex way. It would be much better to create a lifecycleState attribute and define its state machine. A model for doing this can be found at https://specifications.openehr.org/releases/AM/latest/Identification.html#_lifecycle_model (openEHR Archetype Identification specification).

    With respect to the effectivePeriodxx attributes, what does 'in effect' mean? For whom? Org A may stop using a particular package, while Org B uses it for another 2 years. Or is the idea that the dates are set centrally? By whom?

    Generally speaking, an approach that explicitly models lifecycleState, and incorporates release management (i.e. the idea of target publishable versions), plus a disciplined version naming scheme based on semver.org will probably work better than trying to maintain the above attributes within instance data.

  • Reported: BKPMN 1.0a1 — Sun, 24 Apr 2022 15:34 GMT
  • Updated: Mon, 25 Apr 2022 13:32 GMT

Some BKPMN classes over-specified?

  • Key: BKPMN-2
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Fig 5 UML - classes like OrderSetHandlerRef, QuestionnaireHandlerRef, DevelopmentMethod seem very specific and possibly project / context specific. Is the BKPMN model reaching a bit too far in its early stages?

  • Reported: BKPMN 1.0a1 — Sun, 24 Apr 2022 15:30 GMT
  • Updated: Mon, 25 Apr 2022 13:32 GMT

Fig 1 does not render properly in PDF

  • Key: BKPMN-1
  • Status: open  
  • Source: Cognitive Medical Systems ( Thomas Beale)
  • Summary:

    Both background and some arrows (e.g. BPMN -> DMN) are black or near black.

  • Reported: BKPMN 1.0a1 — Sun, 24 Apr 2022 15:27 GMT
  • Updated: Mon, 25 Apr 2022 13:32 GMT