${taskforce.name} Avatar
  1. OMG Task Force

VDML 1.0 FTF — Closed Issues

  • Key: VF
  • Issues Count: 31
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
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

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