Value Delivery Modeling Language Avatar
  1. OMG Specification

Value Delivery Modeling Language — All Issues

  • Acronym: VDML
  • Issues Count: 56
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
VDML11-35 VDML 1.1 should be integrated with SMM 1.2 VDML 1.0 VDML 1.1 Resolved closed
VDML11-33 Consider removing "OutputPort" from caption of Fig. 8.20 VDML 1.0 VDML 1.1 Resolved closed
VDML11-32 Consider removing the sentence "This diagram begins to show integration with SMM..." VDML 1.0 VDML 1.1 Resolved closed
VDML11-31 Element (CMOF) - consistency between SMM 1.1 and VDML 1.0. VDML 1.0 VDML 1.1 Resolved closed
VDML11-30 Consider defining the class Performer VDML 1.0 VDML 1.1 Resolved closed
VDML11-28 Missing constraint on Capability Offer applied by Activity VDML 1.0 VDML 1.1 Resolved closed
VDML11-27 Redundant constraints of Activity, Role and Collaboration VDML 1.0 VDML 1.1 Resolved closed
VDML11-43 Refinement of notation for Deliverable Flow VDML 1.0 VDML 1.1 Resolved closed
VDML11-1 Readability of sub-clause 7.1 could be improved VDML 1.0b1 VDML 1.1 Resolved closed
VDML11-10 Normative reference to CMMN is missing VDML 1.0 VDML 1.1 Resolved closed
VDML11-8 Sentence about Capability is unclear, redundant and also in a wrong place VDML 1.0 VDML 1.1 Resolved closed
VDML11-6 Statement about net economic value is unclear VDML 1.0 VDML 1.1 Resolved closed
VDML11-36 Consider replacing string by String in the diagrams VDML 1.0 VDML 1.1 Resolved closed
VDML11-34 The "other" multiplicity end of association to Characteristic is not shown VDML 1.0 VDML 1.1 Resolved closed
VDML11-15 Imprecise statement about Activity Value contributions VDML 1.0 VDML 1.1 Resolved closed
VDML11-13 Unclear statements on Business Items and Deliverable Flows VDML 1.0 VDML 1.1 Resolved closed
VDML11-21 VDML spec overpromises on modeling of the actual transformation work VDML 1.0 VDML 1.1 Resolved closed
VDML11-19 Confusing statement on Scenarios and context trees VDML 1.0 VDML 1.1 Resolved closed
VDML11-17 Incomplete statement on the use of resources VDML 1.0 VDML 1.1 Resolved closed
VDML11-25 There is no VDML Characteristic VDML 1.0 VDML 1.1 Resolved closed
VDML11-23 Explanation of impact of model integrating on Scenarios is not clear enough VDML 1.0 VDML 1.1 Resolved closed
VDML11-29 Problematic constraint on Role, Participant and Collaboration VDML 1.0 VDML 1.1 Resolved closed
VDML11-26 A Collaboration may contain any number of Activities. VDML 1.0 VDML 1.1 Resolved closed
VDML11-4 Clause 8 not mentioned VDML 1.0 VDML 1.1 Closed; No Change closed
VDML11-2 Add VDML logo VDML 1.0 VDML 1.1 Resolved closed
VF-66 Add example to demonstrate the use of isAtomic property of ValueElement VDML 1.0b1 VDML 1.0 Resolved closed
VF-64 Missing association end names VDML 1.0b1 VDML 1.0 Resolved closed
VF-62 Missing non-normative references about Capabilities VDML 1.0b1 VDML 1.0 Resolved closed
VF-58 Incorrect suggestion of model integration VDML 1.0b1 VDML 1.0 Resolved closed
VF-60 Wrongly worded sentence about delegation VDML 1.0b1 VDML 1.0 Resolved closed
VF-56 Typo: The words "MeasuredCharacteristic" and "Characteristic" are confused twice VDML 1.0b1 VDML 1.0 Resolved closed
VF-54 Declaration of CalendarService Class is missing VDML 1.0b1 VDML 1.0 Resolved closed
VF-50 Optionally constrain value aggregation VDML 1.0b1 VDML 1.0 Resolved closed
VF-1 Cannot aggregate Value Proposition Components VDML 1.0b1 VDML 1.0 Resolved closed
VF-13 Just one Observation (SMM) per Scenario (VDML) is too restrictive. VDML 1.0b1 VDML 1.0 Resolved closed
VF-12 Attribute name "isDefault" is misnomer. VDML 1.0b1 VDML 1.0 Resolved closed
VF-11 Avoid cycles or otherwise meaningless relationships. VDML 1.0b1 VDML 1.0 Resolved closed
VF-4 Conformance Clause needs some improvement VDML 1.0b1 VDML 1.0 Resolved closed
VF-3 Remove redundant association from ValuePropositionComponent VDML 1.0b1 VDML 1.0 Resolved closed
VF-2 Enable aggregation of customer satisfaction as value VDML 1.0b1 VDML 1.0 Resolved closed
VF-10 Improve positioning sentence about VDML VDML 1.0b1 VDML 1.0 Resolved closed
VF-9 Do not use color in normative graphics. VDML 1.0b1 VDML 1.0 Resolved closed
VF-8 Ownership violations in meta-model diagrams specifying libraries. VDML 1.0b1 VDML 1.0 Closed; No Change closed
VF-7 Meta-model diagram(s) in 7.2 should clarify upfront that VdmlElement is the root class. VDML 1.0b1 VDML 1.0 Resolved closed
VF-6 Readability of sub-clause 7.1 could be improved VDML 1.0b1 VDML 1.0 Deferred closed
VF-5 MOF and UML are missing as normative references VDML 1.0b1 VDML 1.0 Resolved closed
VF-19 Missing constraint on DeliverableFlow VDML 1.0b1 VDML 1.0 Resolved closed
VF-18 PortDelegation constraint is too strict VDML 1.0b1 VDML 1.0 Resolved closed
VF-17 Inconsistency between CapabilityLibrary and BusinessItemLibrary VDML 1.0b1 VDML 1.0 Resolved closed
VF-16 Strict containment of ValueProposition in Role complicates re-use in other meta-models VDML 1.0b1 VDML 1.0 Resolved closed
VF-15 Attribute valueMargin is conceptually redundant. VDML 1.0b1 VDML 1.0 Resolved closed
VF-14 Oversight: An attribute is defined which is no longer in the meta-model VDML 1.0b1 VDML 1.0 Duplicate or Merged closed
VF-23 VDML refers to SMM version from before the revision VDML 1.0b1 VDML 1.0 Resolved closed
VF-22 Port shapes are wrongly denoted as "rectangles". VDML 1.0b1 VDML 1.0 Resolved closed
VF-21 OrgUnit constraint is too strict VDML 1.0b1 VDML 1.0 Resolved closed
VF-20 Missing Constraint on InputDelegation and OutputDelegation. VDML 1.0b1 VDML 1.0 Resolved closed

Issues Descriptions

VDML 1.1 should be integrated with SMM 1.2

  • Key: VDML11-35
  • Status: closed  
  • Source: DXC Technology ( Pavel Hruby)
  • Summary:

    The VDML 1.0 specification integrates with SMM 1.1. Meanwhile SMM has been upgraded to SMM 1.1.1. But, as VDML needs to be revised, to a new revision VDML 1.1, and meanwhile SMM is revised to SMM 1.2, the integration of VDML 1.1 should be with SMM 1.2

  • Reported: VDML 1.0 — Thu, 16 Nov 2017 20:33 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    *Integrate VDML 1.1 with SMM 1.2 *

    This impacts both the VDML 1.1 xmi and the specification. In the specification, both the reference in the references list is updated and the Package diagram that shows the integration.

  • Updated: Tue, 10 Jul 2018 14:22 GMT
  • Attachments:

Consider removing "OutputPort" from caption of Fig. 8.20

  • Key: VDML11-33
  • Status: closed  
  • Source: DXC Technology ( Pavel Hruby)
  • Summary:

    Sub-clause 8.4 (Activity Network), in the caption of Figure 8.20, page 90, says “Shape of OutputPort, with ValueAdd, on boundary of Activity OutputPort”. It does not seem correct. The word ”OutputPort” at the end should be removed.

  • Reported: VDML 1.0 — Thu, 16 Nov 2017 20:21 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    Remove the wrong word from the Figure's caption

    Remove the wrong word "OutputPort" from the Figure's caption

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Consider removing the sentence "This diagram begins to show integration with SMM..."

  • Key: VDML11-32
  • Status: closed  
  • Source: DXC Technology ( Pavel Hruby)
  • Summary:

    Sub-clause 7.2.4.1, right above Figure 19, on page 59, says: "This diagram begins to show integration with SMM, discussed later.". But already in an earlier sub-clause, about Analysis Context and Scenario, integration with SMM was specified (to Observation). So it is not true that "this diagram (i.e., Figure 19) begins to show integration with SMM". Removing the sentence would be the easiest way to fix this.

  • Reported: VDML 1.0 — Thu, 16 Nov 2017 20:17 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    Remove incorrect statement

    Remove the incorrect statement. It can safely be removed without losing essential information.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Element (CMOF) - consistency between SMM 1.1 and VDML 1.0.

  • Key: VDML11-31
  • Status: closed  
  • Source: DXC Technology ( Pavel Hruby)
  • Summary:

    VDML 1.0 integrates with SMM 1.1. In the SMM specification, in Figure 71, it is demonstrated that Element (CMOF) does not own measurement (the opposite association end, but rather the association owns it. However, when the same association is shown in the VDML 1.0 specification, in Figure 7.19, on page 59 of sub-clause 7.2.4.1, it shows with the measurement owned by Element (CMOF). This does not seem correct. The same problem is there in Figure 7.29, on page 82, in sub-clause 7.2.6.2.

  • Reported: VDML 1.0 — Thu, 16 Nov 2017 20:14 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    Fix SMM association in diagrams in VDML

    Show SMM association correctly in two diagrams in the VDML specification.

  • Updated: Tue, 10 Jul 2018 14:22 GMT
  • Attachments:

Consider defining the class Performer

  • Key: VDML11-30
  • Status: closed  
  • Source: DXC Technology ( Pavel Hruby)
  • Summary:

    Figure 7.16, in sub-clause 7.2.2.4 (Capability Methods), page 51, shows the class “Performer”, but it appears that it is never defined. Consider adding its Class definition to the VDML specification.

  • Reported: VDML 1.0 — Thu, 16 Nov 2017 20:08 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    Define the class Performer

    Add a new Sub-clause to define the class Performer

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Missing constraint on Capability Offer applied by Activity

  • Key: VDML11-28
  • Status: closed  
  • Source: DXC Technology ( Pavel Hruby)
  • Summary:

    There must be consistency between the Capability Method to which an Activity delegates (in a particular Delegation Context) and the Capability Offer that is applied by the Activity. A constraint, to enforce this consistency, is missing in the specification. It should be added.

  • Reported: VDML 1.0 — Thu, 16 Nov 2017 19:54 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    Add missing constraint

    Add the missing constraint.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Redundant constraints of Activity, Role and Collaboration

  • Key: VDML11-27
  • Status: closed  
  • Source: DXC Technology ( Pavel Hruby)
  • Summary:

    Constraint “Activities that are performed by a Role MUST be contained in the same Collaboration that also contains the Role.” in Constraints of sub-clause 7.2.1.1.5 (Role Class), on page 31, is redundant with constraint “The Role that performs an Activity MUST be contained in the Collaboration that also contains the Activity.” in Constraints of sub-clause 7.2.1.2.1 (Activity Class), on page 34

  • Reported: VDML 1.0 — Thu, 16 Nov 2017 19:48 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    Remove redundant constraint from Role

    Remove the redundant constraint from the Role Class.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Refinement of notation for Deliverable Flow

  • Key: VDML11-43
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    The VDML specification specifies that the name of the deliverable on the Deliverable Flow is shown alongside the connector that represents the Deliverable Flow. This is bit limited, and can easily be extended to make it more useful.
    Furthermore, the text that specifies connectors in Activity Network Diagrams contain a few text errors, such as "along the alongside the connector", as well as a redundantly repeated phrase "Also here, the name along the alongside the connector represents the name of the deliverable.". Please fix that also.

  • Reported: VDML 1.0 — Mon, 22 Jan 2018 17:00 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    Extended form of text alongside connector

    Extend text alongside the connector with state of the deliverable.
    Fix the text errors in the text about connectors in Activity Network Diagram.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Readability of sub-clause 7.1 could be improved

  • Key: VDML11-1
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    The explanation of Figure 7.2 (Capability Offers), in last paragraph of sub-clause 7.1.8 (Capability Method), is a bit difficult to read (page 19). Can the readability of it be improved. Similarly, the first paragraph of sub-clause 7.1.9 (Activity) is a bit difficult to read (also on page 19). Can you improve readability there as well.

  • Reported: VDML 1.0b1 — Tue, 18 Nov 2014 14:44 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    Improve readability of sub-clause 7.1

    Update text, so that things are more clearly explained.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Normative reference to CMMN is missing

  • Key: VDML11-10
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    In sub-clause 7.1.8 (Capability Method) the specification talks about CMMN, but it is not listed as reference.
    More-over, BPMN is included as reference twice.

  • Reported: VDML 1.0 — Fri, 14 Oct 2016 13:46 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    Add reference to CMMN

    Add a normative reference to CMMN to sub-clause 3.1, and remove redundant reference to BPMN from sub-clause 3.2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Sentence about Capability is unclear, redundant and also in a wrong place

  • Key: VDML11-8
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Sub-clause 7.1.7 (Organization Unit) says "A Capability may produce value directly for a customer or it may contribute value when it is engaged in a specific Activity of a value stream.".
    It is unclear what the first half of the sentence means. The second part of the sentence talks about concepts that will be dealt with, and will be dealt with more clearly, in later sub-clauses, and are referred to too early here therefore.

  • Reported: VDML 1.0 — Fri, 14 Oct 2016 12:08 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    Remove confusing and redundant sentence

    This sentence will be removed, as it is indeed unclear and redundant.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Statement about net economic value is unclear

  • Key: VDML11-6
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Sub-clause 7.1.6 (Business Networks) talks about the net economic value for a party, and how it can be modeled. This statement is a bit fuzzy and is influenced by some elements in the VDML beta1 meta-model around Value Propositions and Business Networks, that got changed in VDML 1.0.

  • Reported: VDML 1.0 — Fri, 14 Oct 2016 09:49 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    Make statement about net economic value more clear

    Make statement in sub-clause 7.1.6, about net economic value, more clear, and more obvious in the light of the meta-model.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Consider replacing string by String in the diagrams

  • Key: VDML11-36
  • Status: closed  
  • Source: DXC Technology ( Pavel Hruby)
  • Summary:

    In the VDML 1.0 specification, the definition text in the specification assumes the UML predefined type “String” (with capital “S”), however, the meta-model diagrams expose the type “string” (lower case “s”). This means that the meta-model (and so the XMI) actually use the type “string”. This has several problems. Firstly, it is not a predefined UML type, and the VDML specification neither defines it, so, it is basically undefined. Secondly, SMM 1.1 is integrated into VDML 1.0, and SMM 1.1 uses the predefined UML type “String” (with capital “S”). Hence VDML has better also use the UML type “String”.

  • Reported: VDML 1.0 — Mon, 20 Nov 2017 13:19 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    Replacing string by String in diagrams and in the model

    Replacing undefined "string" type by the predefined UML type "String", in the model (and hence in the XMI) and in some diagrams in the specification.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

The "other" multiplicity end of association to Characteristic is not shown

  • Key: VDML11-34
  • Status: closed  
  • Source: DXC Technology ( Pavel Hruby)
  • Summary:

    In sub-clause 7.2.5.1 (BusinessItemLibrary), in Figure 7.23, page 68, the multiplicity on end of BusinessItemLibraryElement (of association to Characteristic) is not shown. It should be shown as (0..*). The same problem also occurs in the following three places:
    1) In sub-clause 7.2.5.2 (ValueLibrary), in Figure 7.24, page 70, the multiplicity on end of ValueDefinition (of association to Characteristic) is not shown. It should be shown as (0..*).
    2) In sub-clause 7.2.5.3 (CapabilityLibrary), in Figure 7.25, page 73, the multiplicity on end of Capability (of association to Characteristic) is not shown. It should be shown as (0..*).
    3) In sub-clause 7.2.5.5 (RoleLibrary), in Figure 7.27, page 79, the multiplicity on end of RoleDefinition (of association to Characteristic) is not shown. It should be shown as (0..*).

  • Reported: VDML 1.0 — Thu, 16 Nov 2017 20:29 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    Show multiplicity on association ends in four places

    Add the missed visualization of multiplicity on the four association ends.

  • Updated: Tue, 10 Jul 2018 14:22 GMT
  • Attachments:

Imprecise statement about Activity Value contributions

  • Key: VDML11-15
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    In sub-clause 7.1.9 (Activity), page 22, it says: "Conversely, all values can be traced back to their contributors. This is possible, because VDML is not representing the actual paths of each unit of production, but rather the statistical use of various Activities that contribute to results achieved over some period of time. That representative set of results includes some Activities that are only active for some units of production due to product features, operating exceptions, defects, repairs, sample testing, machine failures, and so on." The word "includes" (see above in bold) sounds strange to me. Because Activities are not included in a set of results. Is maybe a different verb meant or was it meant to say something different ?

  • Reported: VDML 1.0 — Tue, 14 Nov 2017 16:21 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    Revise imprecise statement

    Imprecise statement about Activity Value contributions revised.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Unclear statements on Business Items and Deliverable Flows

  • Key: VDML11-13
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    In sub-clause 7.1.9 (Activity), page 20, it says: "A BusinessItem (...) may flow through a delegation to a sub-Collaboration, or be the input or output of a Collaboration." How is the following meant: "be the input or output of a Collaboration" ? Is that only saying in other words what is said with "may flow through a delegation to a sub-Collaboration"? Similar doubt regarding the immediate next sentence: "Flow of BusinessItems into and out of Activities as well as Collaborations is depicted by DeliverableFlows." The phrase of "as well as Collaborations" is a bit arguable. As known, DeliverableFlows do not connect Ports of Collaborations directly.

  • Reported: VDML 1.0 — Tue, 14 Nov 2017 15:56 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    Revise unclear statements

    Unclear statements about Business Items and Deliverable Flows revised.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

VDML spec overpromises on modeling of the actual transformation work

  • Key: VDML11-21
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    The second and third paragraph of sub-clause 7.1.14 (Staff Collaborations), on page 26, are suggesting that VDML can be used to model transformation work, involved in transformation of the business that is also modeled. This is bit misleading and tends to overpromise.

  • Reported: VDML 1.0 — Wed, 15 Nov 2017 16:22 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    Remove false expectations about modeling of actual transformation work

    Rewrite sentences to remove false expectations about modeling of the actual transformation work

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Confusing statement on Scenarios and context trees

  • Key: VDML11-19
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    In sub-clause 7.1.13 (Scenarios and Contexts), page 25, right above Figure 7.5, it says: "Since Assignments can also be context dependent, the delegations of one Scenario can differ from those of another Scenario thus forming a different tree." But the phrase "Since Assignments can also be context dependent" is irrelevant here, because: delegations of one Scenario (i.e., sub-Collaborations in DelegationContext nodes in the Scenario tree) can be different from those of another Scenario anyway.

  • Reported: VDML 1.0 — Tue, 14 Nov 2017 16:48 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    Give statement on Scenarios and context trees better meaning

    Give statement on Scenarios and context trees better meaning, by removing some words.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Incomplete statement on the use of resources

  • Key: VDML11-17
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    In sub-clause 7.1.11 (Resources and Stores), page 22, it says: “The cumulative duration of these uses will determine the consumption of available resource time. This, along with the rate of production, will determine if the Pool of resources will always have resources available or will introduce some additional wait-time for assignment of a resource.”. This only talks about assigning a resource. But before it can be assigned, one may need to wait till it gets released. Can this be worked into the sentence, to make it better reflecting that also.

  • Reported: VDML 1.0 — Tue, 14 Nov 2017 16:34 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    Make statement about resources complete

    Make statement about the use of resources more complete, referring also to the concept of releasing of a resource.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

There is no VDML Characteristic

  • Key: VDML11-25
  • Status: closed  
  • Source: DXC Technology ( Pavel Hruby)
  • Summary:

    Sub-clause 7.1.12 (Measures), page 22, says: “A Measure is applied to a Characteristic, such as weight of a part, to determine a Measurement that expresses the value of the Characteristic for a particular VDML model element.” And a bit further, on the same page: “VDML Characteristics reflect statistical Measurements per unit of production.”. In the light of Figure 7, this does not seem correct. Because VDML has MeasuredCharacterstic, referring to Characteristic in SMM. Strictly spoken there is no "VDML Characteristic".

  • Reported: VDML 1.0 — Thu, 16 Nov 2017 19:43 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    Use MeasuredCharacteristic instead of Characterstic in two sentences

    Fix two sentences, by referring to MeasuredCharacteristic, instead of Characteristic.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Explanation of impact of model integrating on Scenarios is not clear enough

  • Key: VDML11-23
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Point 3 in sub-clause 7.1.15 (Model Integration), and the last paragraph of that sub-clause, both on page 27, contain incorrect and confusing statements. It talks about "direct and indirect delegations" and "non-delegation inputs and outputs". In the context of the meta-model, it is unclear what these mean. It also says: "A branch of a delegation tree in one Scenario may then be assigned as a delegation from an Activity in the other Scenario.” The word “assigned” is mis-used here, as, in the VDML specification this term is reserved for assignment of a role. It is also unclear, with the actual meta-model in mind, what the sentence actually means.

  • Reported: VDML 1.0 — Wed, 15 Nov 2017 16:40 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    Making explanation more clear and consistent with the meta-model

    Making explanation more clear and consistent with the meta-model.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Problematic constraint on Role, Participant and Collaboration

  • Key: VDML11-29
  • Status: closed  
  • Source: DXC Technology ( Pavel Hruby)
  • Summary:

    Sub-clause 7.2.1.2.3 (Assignment Class), page 36, has a constraint that says, page 37: “A Role MUST NOT be assigned to more than one Participant that is a Collaboration, unless the additional Assignments are context-based, i.e., contained by DelegationContext”. This constraint has several problems. It ignores the fact that participations can be indirect, through a chain of assignments (“roles of roles”). It also ignores the fact that context-based assignments are not only possible with delegation contexts (i.e., children in the context tree), but also with scenarios (the top of context tree). Furthermore, this constraint was written with Position roles in mind, but leaves too much room for invalid situations for other types of roles.

  • Reported: VDML 1.0 — Thu, 16 Nov 2017 20:01 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    Replace constraint

    Replace the problematic constraint by three other constraints.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

A Collaboration may contain any number of Activities.

  • Key: VDML11-26
  • Status: closed  
  • Source: DXC Technology ( Pavel Hruby)
  • Summary:

    Sub-clause 7.1.13 (Scenarios and Contexts), page 23, says: “When the Activity of a Collaboration delegates to another Collaboration in order to engage a shared Capability, that particular use of the sub-Collaboration may be one of many.” It is confusing to talk about “the” Activity of a Collaboration. A Collaboration may contain any number of Activities.

  • Reported: VDML 1.0 — Thu, 16 Nov 2017 19:46 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    Withdraw false suggestion from the text about Activities

    Fix the text, so that it no longer attaches false connotation to Activities.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Clause 8 not mentioned

  • Key: VDML11-4
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Clause 8 (Notation) is not mentioned in sub-clause 6.3 (Guide to the Specification).

  • Reported: VDML 1.0 — Fri, 14 Oct 2016 08:39 GMT
  • Disposition: Closed; No Change — VDML 1.1
  • Disposition Summary:

    No change needed

    This missing information was actually added in the formal VDML 1.0 specifiation, though it was missing in the Word version that was delivered by the submission team and that was the basis for adoption. We just overlooked that. So this issue is actually no issue.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Add VDML logo

  • Key: VDML11-2
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Add VDML logo to the VDML specification

  • Reported: VDML 1.0 — Fri, 14 Oct 2016 08:18 GMT
  • Disposition: Resolved — VDML 1.1
  • Disposition Summary:

    Add VDML logo

    The VDML logo is added to the front page of the VDML specification.

  • Updated: Tue, 10 Jul 2018 14:22 GMT
  • Attachments:

Add example to demonstrate the use of isAtomic property of ValueElement

  • Key: VF-66
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Via issue VF-50 the property isAtomic was introduced. It is desirable to add a small example to further explain its use.

  • Reported: VDML 1.0b1 — Wed, 4 Feb 2015 16:39 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Add example to the definition of property isAtomic of ValueElement class

    Add a small example to the definition of property isAtomic of the ValueElement class. Note that this property was introduced via the already approved issue VF-50 in the now closed Ballot#1.

  • Updated: Wed, 8 Jul 2015 11:44 GMT

Missing association end names

  • Key: VF-64
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Some association ends do not have a name in the meta-model. These are:

    • Opposite end of roleDefinition (in the association between Role and RoleDefinition)
    • Opposite end of capability (in the association between CababilityMethod and Capability
    • Opposite end of roleDefinition (in the association between RoleLibrary and RoleDefinition)
    • Opposite end of roleCategory (in the association between RoleLibrary and RoleCategory)
    • Opposite end of roleLibrary (in the association between ValueDeliveryModel and RoleLibrary)

    These omissions are in XMI only, as these ends (as association-owned ends) are not specified in the specification document itself.

  • Reported: VDML 1.0b1 — Mon, 19 Jan 2015 10:49 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Specify missing association ends

    Specify the missing association ends in the XMI file.

  • Updated: Wed, 8 Jul 2015 11:44 GMT

Missing non-normative references about Capabilities

  • Key: VF-62
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Capability theory of authors like Hamel, Prahalad and others, served as one of the inputs into VDML. It was forgotten so-far to include non-normative references related publications.

  • Reported: VDML 1.0b1 — Sat, 10 Jan 2015 15:44 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Add non-normative references to Capability theory publications

    Include references to the following related publications:

    • Grant, R. M.,The Resource-Based Theory of Competitive Advantage: Implications for Strategy Formulation. California Management Review, March 1991.
    • Prahalad, C.K and Hamel, G., The Core Competence of the Corporation. Harvard Business Review, May/June 1990.
    • Teece, D. J., Pisano, G. and Shuen, A., Dynamic Capabilities and Strategic Management. Strategic Management Journal, August 1997.
    • Zollo, M. and Winter, S. G., Deliberate Learning and the Evolution of Dynamic Capabilities. Organization Science, 2002, Vol. 13, No. 3.
  • Updated: Wed, 8 Jul 2015 11:44 GMT

Incorrect suggestion of model integration

  • Key: VF-58
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Sub-clause 7.1.15 says: "This integration might be viewed as providing a super-Scenario with a Collaboration that engages each Scenario from one of the line-of-business models with a Scenario of the other line-of-business model, so the line-of-business Scenarios essentially become AnalysisContexts of the “super” Scenario."

    This is incorrect, and inconsistent with the meta-model, as an AnalysisContext is exclusively owned by the context tree of a single Scenario, and is not shared across multiple Scenarios (as node their context tree).

  • Reported: VDML 1.0b1 — Fri, 9 Jan 2015 16:14 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Revise integration suggestion to make it compliant to the meta-model

    Revise the following sentence in sub-clause 7.1.15, to make it compliant to the meta-model: "This integration might be viewed as providing a super-Scenario with a Collaboration that engages each Scenario from one of the line-of-business models with a Scenario of the other line-of-business model, so the line-of-business Scenarios essentially become AnalysisContexts of the “super” Scenario."

  • Updated: Wed, 8 Jul 2015 11:44 GMT

Wrongly worded sentence about delegation

  • Key: VF-60
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    The word "calling" in the following sentence in sub-clause 7.1.13 is wrong: "A DelegationContext defines aspects of the particular delegation to the sub-Collaboration referenced as the calling Collaboration.". Because the calling Collaboration is not the sub-Collaboration, but the parent one.

  • Reported: VDML 1.0b1 — Sat, 10 Jan 2015 15:19 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Correct wrongly worded sentence about delegation

    Replace the words "calling Collaboration" with "contextCollaboration" in the erroneous sentence. This will make the sentence correct.

  • Updated: Wed, 8 Jul 2015 11:44 GMT

Typo: The words "MeasuredCharacteristic" and "Characteristic" are confused twice

  • Key: VF-56
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Sub-clause 7.1.9 says "ValueDefinitions are captured in a ValueLibrary, as are MeasuredCharacteristics (SMM Library)." This is wrong. SMM Library does not contain MeasuredCharacteristics, but Characteristics. MeasuredCharacteristics are in VDML itself.

    Sub-clause 7.1.12 says "Thus a VDML element may have different Measurements for the same Characteristic in different AnalysisContexts". This is wrong also. Measurements are linked to MeasuredCharacteristics (VDML). Not to Characteristics (SMM) directly.

  • Reported: VDML 1.0b1 — Thu, 8 Jan 2015 09:39 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Correct typos in 7.1.9 and 7.1.12

    Replace "MeasuredCharacteristics" with "Characteristics" in the sentence "ValueDefinitions are captured in a ValueLibrary, as are MeasuredCharacteristics (SMM Library)." in sub-clause 7.1.9.

    Also, replace "Characteristic" with "MeasuredCharacteristic" in the following sentence in sub-clause 7.1.12: "Thus a VDML element may have different Measurements for the same Characteristic in different AnalysisContexts".

  • Updated: Wed, 8 Jul 2015 11:44 GMT

Declaration of CalendarService Class is missing

  • Key: VF-54
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Figure 6 and Figure 11 show the class CalendarService. Participant and Pool are associated with CalendarService. But CalendarService itself is not defined.

  • Reported: VDML 1.0b1 — Sat, 27 Dec 2014 15:42 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Add sub-clause to define CalendarService class

    A sub-clause has to be added to define the CalendarService class.

  • Updated: Wed, 8 Jul 2015 11:44 GMT

Optionally constrain value aggregation

  • Key: VF-50
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    A ValueElement can be "typed" by reference to ValueDefinition. ValueElements can be aggregated flexibly, whereby a ValueElement can be aggregated from ValueElements of the same "type", as well as of different "types". It would be better to have an option to enforce whether or not a ValueElement can be aggregated from ValueElements of the same "type".

  • Reported: VDML 1.0b1 — Mon, 24 Nov 2014 09:12 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Add optional attribute to ValueElement, to help constraining value aggregation

    Add attribute "isAtomic: Boolean [0..1] = true" to ValueElement.
    Semantics: "When a ValueElement isAtomic, this means that it is a leaf in the structure of aggregation of ValueElements of the same type of value (i.e. of ValueElements that refer to the same ValueDefinition in the ValueLibrary). When a ValueElement is not atomic (i.e. isAtomic equals "false"), this means that it is an internal node in the structure of aggregation of ValueElements of the same type of value."
    Add three constraints also:
    1) "When valueDefinition of a ValueElement is empty, isAtomic MUST be empty also".
    2) "The valueDefinition of a ValueElement that isAtomic MUST be different from the valueDefinition of aggregatedFrom of the ValueElement".
    3) “At least one of the ValueDefinition-referring aggregatedFrom of a non-atomic (i.e., for which isAtomic equals “false”) ValueElement MUST refer to the same ValueDefinition as that non-atomic ValueElement refers to.”

    Note: Though the system would be able to show this distinction for complete models, even without this attribute, it would not be able to do so during the development of models. Hence the attribute is introduced to ensure consistency.

  • Updated: Wed, 8 Jul 2015 11:44 GMT

Cannot aggregate Value Proposition Components

  • Key: VF-1
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    AggregatedFrom / AggregatedTo is related to ValueAdd. This prohibits aggregation of ValuePropositionComponents.

  • Reported: VDML 1.0b1 — Tue, 18 Nov 2014 14:12 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Move aggregatedFrom / aggregatedTo association from ValueAdd to ValueElement

    Move aggregatedFrom / aggregatedTo association from ValueAdd to ValueElement, so that value aggregation applies to both ValueAdds and ValuePropositionComponents, in any combination). The articulatedValue association becomes then redundant and can be removed. This more flexible aggregation of value also makes ValueImpactForProvider of ValuePropositionComponent redundant, so that it can be removed also. Value aggregation to a ValueProposition to the provider (the business) can be used instead.

  • Updated: Wed, 8 Jul 2015 11:44 GMT
  • Attachments:

Just one Observation (SMM) per Scenario (VDML) is too restrictive.

  • Key: VF-13
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Currently a Scenario (VDML) can only have one Observation (SMM). This blocks the possibility to e.g. periodically monitor based on the same Scenario. It should be possible that a Scenario (actually AnalysisContext) links to multiple Observations. 

  • Reported: VDML 1.0b1 — Tue, 18 Nov 2014 15:05 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Change multiplicity of the Observation end of the association between AnalysisContext (VDML) and Observation (SMM)

    Multiplicity of the Observation end of the association between AnalysisContext (VDML) and Observation (SMM) should change from 0..1 to 0..*.  

  • Updated: Wed, 8 Jul 2015 11:44 GMT

Attribute name "isDefault" is misnomer.

  • Key: VF-12
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    The isDefault attribute means to express that the Measurements in the Observation of the Scenario are "common" across all Scenarios in the model (i.e., they are incorporated by reference unless modified for a specific Scenario). It is then better to rename the attribute into "isCommon".

  • Reported: VDML 1.0b1 — Tue, 18 Nov 2014 15:00 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Rename attribute isDefault of Scenario into isCommon.

    Rename attribute isDefault of Scenario into isCommon. And revise text and figures (diagrams) accordingly.

  • Updated: Wed, 8 Jul 2015 11:44 GMT

Avoid cycles or otherwise meaningless relationships.

  • Key: VF-11
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    It is currently possible that cyclical patterns occur in Role Assignments. These should be avoided. It should also be avoided that a Role provides a Value Proposition to itself, as this has no real meaning.

  • Reported: VDML 1.0b1 — Tue, 18 Nov 2014 14:59 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Include meta-model constraints in relation to Assignment, Collaboration, ValueProposition and ValueElement

    Include the following meta-model constraints: 1) A Role MUST NOT be assigned itself (directly, or indirectly via other Assignments). 2) A Role MUST not be assigned its containing Collaboration. 3) The provider of a ValueProposition MUST NOT be the recipient of that ValueProposition..

  • Updated: Wed, 8 Jul 2015 11:44 GMT

Conformance Clause needs some improvement

  • Key: VF-4
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Sub-clause 2.1 is clear and understandable, but 2.2 and 2.3 are too vague. It is for example not clear if compliance to 2.2 includes 2.3 or not, and 2.3 need to provide a better definition of collaboration.

  • Reported: VDML 1.0b1 — Tue, 18 Nov 2014 14:36 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Make levels of conformance more explicit

    Add clause numbers to references.
    2.1 remove exception that "optional" elements need not be included.
    2.2 clarify that conformance with notation is not required and that this is a subset of 2.1
    2.3 clarify that this is a subset of 2.2 and name the specific classes that must be included for conformance.

  • Updated: Wed, 8 Jul 2015 11:44 GMT

Remove redundant association from ValuePropositionComponent

  • Key: VF-3
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    ValueImpactForRecipient of ValuePropositionComponent is conceptually redundant with satisfactionLevel.

  • Reported: VDML 1.0b1 — Tue, 18 Nov 2014 14:28 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Remove valueImpactForRecipient from ValuePropositionComponent.

    Remove valueImpactForRecipient from ValuePropositionComponent.

  • Updated: Wed, 8 Jul 2015 11:44 GMT

Enable aggregation of customer satisfaction as value

  • Key: VF-2
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Customer satisfaction is important business value. Hence it is essential that satisfaction of recipients (typically customers) in relation to a ValueProposition that they receive, is aggregated to business value, as part of a ValueProposition to the business (the provider of the ValueProposition). VDML does already support measurement of satisfaction (satisfactionLevel) of a recipient with a value (ValuePropositionComponent). It is also possible to define the relative weight (percentageWeight) of a value for the recipient. There is, however, no straightforward support, based on the meta-model, to e.g. aggregate the "overall satisfaction" (typically the weighted average satisfaction of the ValuePropositionComponents) to business value (value as embodied in a ValueProposition to the provider of the ValueProposition). Resolution of this issue will depend on resolution of issue VF-1.

  • Reported: VDML 1.0b1 — Tue, 18 Nov 2014 14:22 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Handle ValueProposition related (satisfaction) measurement via an additional ValuePropositionComponent

    Resolution has the following elements: 1) Add optional (0..1) association between ValueProposition and ValuePropositionComponent (called “overallSatisfaction" on the ValuePropositionComponent end). 2) Add a constraint to it: The overallSatisfaction of a ValueProposition MUST be a ValuePropositionComponent of the ValueProposition. 3) And also this constraint: The overallSatisfaction of a ValueProposition MUST not itself have percentageWeight. 4) As the overallSatisfaction component makes value measurement at ValueProposition header level redundant, the following associations can be removed from ValueProposition: propositionValue, satisfactionLevel, valueImpactForProvider and valueImpactForRecipient.

  • Updated: Wed, 8 Jul 2015 11:44 GMT

Improve positioning sentence about VDML

  • Key: VF-10
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Page 15, last paragraph says: “but it provides a more abstract view than BPMN “ . It should say “ different “ . Rather than “ more abstract”.

  • Reported: VDML 1.0b1 — Tue, 18 Nov 2014 14:54 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Change the wording according to the suggestion in the Description

    Change the wording according to the suggestion in the Description

  • Updated: Wed, 8 Jul 2015 11:44 GMT

Do not use color in normative graphics.


Ownership violations in meta-model diagrams specifying libraries.

  • Key: VF-8
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    You have ownership violations in your diagrams specifying libraries. You need to have multiplicity [0..1] at the black diamond ends of the associations between the library class and the contained elements, or else these element could not legally exist outside the library. This pattern repeats for all library specifications.

  • Reported: VDML 1.0b1 — Tue, 18 Nov 2014 14:49 GMT
  • Disposition: Closed; No Change — VDML 1.0
  • Disposition Summary:

    No need to change meta-model and specification.

    No need to change meta-model and specification. Library elements do not need to live outside the library. They are only referenced from other elements that comprise the actual design of the business.

  • Updated: Wed, 8 Jul 2015 11:44 GMT

Meta-model diagram(s) in 7.2 should clarify upfront that VdmlElement is the root class.

  • Key: VF-7
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    VdmElement is the root of the VDML metamodel. However, In the first diagram in Figure 6, VdmElement is shown parallel to MeasurableElement (which is actually a subclass of VdmElement). Over the course of the following diagrams, the reader gets the feeling that VdmElement must be the true root, but it takes until figure 19 that you let the cat out of the bag... While Figure 6 is syntactical legal UML, I suggest to show MeasurableElement as a subclass of VdmElement in Figure 6 to establish clarity about root position of VdmElement from the very beginning.

  • Reported: VDML 1.0b1 — Tue, 18 Nov 2014 14:46 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Show MeasurableElement as a subclass of VdmElement in Figure 6

    Show MeasurableElement as a subclass of VdmElement in Figure 6 to establish clarity about root position of VdmElement from the very beginning

  • Updated: Wed, 8 Jul 2015 11:44 GMT
  • Attachments:

Readability of sub-clause 7.1 could be improved

  • Key: VF-6
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Sub-clause 7.1 reads a bit dry, until you hit the first UML diagram. There is nothing technically wrong, but the FTF could improve the text.

  • Reported: VDML 1.0b1 — Tue, 18 Nov 2014 14:44 GMT
  • Disposition: Deferred — VDML 1.0
  • Disposition Summary:

    Requirements to resolve "dryness" are not clear and are subject to further discussion

    The sub-clause is accurate and provides useful understanding of how the elements of VDML work together. Thus there is not a technical need for change, but the issue should be deferred for further discussion in the RTF.

  • Updated: Wed, 8 Jul 2015 11:44 GMT

MOF and UML are missing as normative references

  • Key: VF-5
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Your specification is a MOF metamodel and uses UML notation to specify the metamodel, therefore you need to add MOF and UML to your list of normative references.

  • Reported: VDML 1.0b1 — Tue, 18 Nov 2014 14:38 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Add MOF and UML to your list of normative references.

    Add MOF and UML to your list of normative references.

  • Updated: Wed, 8 Jul 2015 11:44 GMT

Missing constraint on DeliverableFlow

  • Key: VF-19
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    It should not be possible that Ports of Activities of different Collaborations are directly connected via DeliverableFLows. That should not be allowed. Because flow of deliverables across Collaborations should go either via delegation from parent activities or via stores.

  • Reported: VDML 1.0b1 — Tue, 18 Nov 2014 15:21 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Add constraint to DeliverableFlow

    Add the following constraint to 7.2.1.2.4 (DeliverableFlow class): "A DeliverableFlow MUST NOT connect Ports of Activities that are contained in different Collaborations.".

  • Updated: Wed, 8 Jul 2015 11:44 GMT

PortDelegation constraint is too strict

  • Key: VF-18
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    In 7.2.1.1.3, the following constraint on the Collaboration class is too strict: "All Ports of a Collaboration MUST be mapped to Ports of Activities that are contained in the Collaboration, via internalPortDelegations".

  • Reported: VDML 1.0b1 — Tue, 18 Nov 2014 15:19 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Remove constraint from Collaboration

    Remove the following constraint from 7.2.1.1.3 (Collaboration class): "All Ports of a Collaboration MUST be mapped to Ports of Activities that are contained in the Collaboration, via internalPortDelegations".

  • Updated: Wed, 8 Jul 2015 11:44 GMT

Inconsistency between CapabilityLibrary and BusinessItemLibrary

  • Key: VF-17
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    In CapabilityLibrary, Characteristic (SMM) can be linked to both CapabilityDefinition and CapabilityCategory, and hence to the parent abstract class of both. In BusinessItemLibrary however, though there is a parent abstract class for both BusinessItemDefinition and BusinessItemCategory, Characteristic (SMM) can only be linked to BusinessItemDefinition. This is inconsistent.

  • Reported: VDML 1.0b1 — Tue, 18 Nov 2014 15:16 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Move association to Characteristic (SMM) to other class.

    Move association to Characteristic (SMM) from BusinessItemDefinition to BusinessItemLibraryElement.

  • Updated: Wed, 8 Jul 2015 11:44 GMT
  • Attachments:

Strict containment of ValueProposition in Role complicates re-use in other meta-models

  • Key: VF-16
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    ValueProposition is mandatorily contained in Role. This makes re-use of VDML ValueProposition in other meta-models hard. Containment of ValueProposition in Role should rather be optional ("0..1" instead of "1").

  • Reported: VDML 1.0b1 — Tue, 18 Nov 2014 15:13 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Make ValueProposition - in - Role containment optional

    Change multiplicity of the end of provider in the association between provider and providedProposition from "1" into "0..1".

  • Updated: Wed, 8 Jul 2015 11:44 GMT

Attribute valueMargin is conceptually redundant.

  • Key: VF-15
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Attribute valueMargin is conceptually redundant. ValueProposition (with ValuePropositionComponents) provides a generic structure that can express such values as margin and profit also.

  • Reported: VDML 1.0b1 — Tue, 18 Nov 2014 15:08 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Remove attribute valueMargin from the Party class

    Remove attribute valueMargin from the Party class in sub-clause 7.2.2.1.2, as well as references from the text in other (sub-)clauses.

  • Updated: Wed, 8 Jul 2015 11:44 GMT
  • Attachments:

Oversight: An attribute is defined which is no longer in the meta-model

  • Key: VF-14
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    The text in the sub-clause that defines the ValuePropositionClass (7.2.1.3.1) refers to the attribute "componentValue" that does no longer exist in the meta-model.

  • Reported: VDML 1.0b1 — Tue, 18 Nov 2014 15:06 GMT
  • Disposition: Duplicate or Merged — VDML 1.0
  • Disposition Summary:

    Remove reference to obsolete attribute

    As the text in sub-clause 7.2.1.3.1, that references the obsolete attribute "componentValue", is removed per resolution of issue VF-2, no further revision is required for this issue.

  • Updated: Wed, 8 Jul 2015 11:44 GMT

VDML refers to SMM version from before the revision

  • Key: VF-23
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    VDML beta1 refers to SMM 1.0. The SMM revision (SMM 1.1 RTF) enables for better integration and improves SMM on aspects relevant to VDML. Hence VDML 1.0 (FTF result) should refer to SMM 1.1 instead. This will impact the VDML 1.0 XMI also.

  • Reported: VDML 1.0b1 — Tue, 18 Nov 2014 16:04 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Refer to SMM 1.1 from Normative References and from VDML 1.0 XMI

    Refer to SMM 1.1 from Normative References and from XMI. The Package diagram (Figure 28) has to be updated also.

  • Updated: Wed, 8 Jul 2015 11:44 GMT
  • Attachments:

Port shapes are wrongly denoted as "rectangles".

  • Key: VF-22
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    In the table in sub-clause 8.4, port shapes are denoted as "rectangle". They are "squares" however.

  • Reported: VDML 1.0b1 — Tue, 18 Nov 2014 15:38 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Use the right word to denote the shape of a Port

    Replace the word "rectangle" with "square" in the table in sub-clause 8.4 (it is used six times there to denote the shape of a Port).

  • Updated: Wed, 8 Jul 2015 11:44 GMT

OrgUnit constraint is too strict

  • Key: VF-21
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    In 7.2.2.3.1 (OrgUnit class), the following constraint is too strict: "When an OrgUnit provides more than one CapabilityOffer, these CapabilityOffers MUST provide different Capabilities".

  • Reported: VDML 1.0b1 — Tue, 18 Nov 2014 15:36 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Remove constraint from OrgUnit class

    Remove the following constraint from 7.2.2.3.1 (OrgUnit class): "When an OrgUnit provides more than one CapabilityOffer, these CapabilityOffers MUST provide different Capabilities".

  • Updated: Wed, 8 Jul 2015 11:44 GMT

Missing Constraint on InputDelegation and OutputDelegation.

  • Key: VF-20
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    It is currently allowed that a Port of an Activity that is contained in a Collaboration, can be connected to multiple Ports of the containing Collaboration. That should not be allowed.

  • Reported: VDML 1.0b1 — Tue, 18 Nov 2014 15:30 GMT
  • Disposition: Resolved — VDML 1.0
  • Disposition Summary:

    Add constraint to InputDelegation and OutputDelegation Classes

    Add the following constraint to 7.2.4.4.2 (InputDelegation Class): "An InputPort of an Activity that is contained in a Collaboration MUST NOT be mapped, via InputDelegation, to more than one InputPort of the containing Collaboration", and add the following constraint to 7.2.4.4.3 (OutputDelegation Class): "An OutputPort of an Activity that is contained in a Collaboration MUST NOT be mapped, via OutputDelegation, to more than one OutputPort of the containing Collaboration".

  • Updated: Wed, 8 Jul 2015 11:44 GMT