Implementation Pattern Metamodel for Software Systems Avatar
  1. OMG Specification

Implementation Pattern Metamodel for Software Systems — Closed Issues

  • Acronym: IPMSS
  • Issues Count: 18
  • Description: Issues resolved by a task force and approved by Board
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
SPMS12-2 Normative references IPMSS 1.0 SPMS 1.2 Resolved closed
SPMS12-1 Enhance PatternSection body to allow for more than raw strings as content IPMSS 1.0 SPMS 1.2 Resolved closed
SPMSSR-4 Typo on page 18 IPMSS 1.0 SPMS 1.1 Resolved closed
SPMSSR-3 Clarification needed on multiplicity of formalisms IPMSS 1.0 SPMS 1.1 Resolved closed
SPMSSR-2 Clarification needed for multiplicity of Interpattern Relationships IPMSS 1.0 SPMS 1.1 Resolved closed
SPMSSR-5 Enhance PatternSection body to allow for more than raw strings as content IPMSS 1.0 SPMS 1.1 Deferred closed
SPMSSR-1 Request for non-duplication of PINBoxes in cases of multiplicities IPMSS 1.0b1 SPMS 1.1 Resolved closed
IPMFSSF-2 Suggestion to make existing connection bi-directional IPMSS 1.0b1 IPMSS 1.0 Closed; No Change closed
IPMFSSF-1 References to UML 2.4.1 hrefs in IPMSS XMI IPMSS 1.0b1 IPMSS 1.0 Resolved closed
IPMFSSF-3 Needs clarification of formalisms binding features IPMSS 1.0b1 IPMSS 1.0 Resolved closed
IPMFSSF-11 Formalisms need further clarification IPMSS 1.0b1 IPMSS 1.0 Resolved closed
IPMFSSF-8 Bindings multiplicity is inconsistent between sections IPMSS 1.0b1 IPMSS 1.0 Resolved closed
IPMFSSF-7 Inconsistencies between text and figures IPMSS 1.0b1 IPMSS 1.0 Resolved closed
IPMFSSF-6 List machine readable files in specification IPMSS 1.0b1 IPMSS 1.0 Resolved closed
IPMFSSF-10 Clarify MOF Property vs. MOF Type or Class IPMSS 1.0b1 IPMSS 1.0 Resolved closed
IPMFSSF-9 Clarification needed on 'Element' ownership of Property, or 'metaclass of Element' ownership of Property IPMSS 1.0b1 IPMSS 1.0 Resolved closed
IPMFSSF-5 URLs need to be corrected IPMSS 1.0b1 IPMSS 1.0 Resolved closed
IPMFSSF-4 Request for non-duplication of PINBoxes in cases of multiplicities IPMSS 1.0b1 IPMSS 1.0 Deferred closed

Issues Descriptions

Normative references

  • Key: SPMS12-2
  • Legacy Issue Number: 19886
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The normative references include UML 2.5 but MOF 2.4.1: MOF 2.5.1 should be referenced since it’s mutually dependent with UML 2.5.

    There is also now Diagram Definition, 1.1.

  • Reported: IPMSS 1.0 — Thu, 17 Mar 2016 04:00 GMT
  • Disposition: Resolved — SPMS 1.2
  • Disposition Summary:

    Normative references should be updated to most current referred specifications.

    References to UML, MOF, and DD need to be made consistent through prose and XMI files, and should refer to the most current specification available, if the most recent spec does not change backwards compatibility.

  • Updated: Mon, 16 Oct 2017 15:15 GMT

Enhance PatternSection body to allow for more than raw strings as content

  • Key: SPMS12-1
  • Status: closed  
  • Source: Object Management Group ( Dr. Jason McC. Smith)
  • Summary:

    Consumers of SPMS have requested the ability to include diagrams, pointers to existing documents, etc., in the section bodies.

  • Reported: IPMSS 1.0 — Mon, 21 Sep 2015 13:42 GMT
  • Disposition: Resolved — SPMS 1.2
  • Disposition Summary:

    Provide guidance on using PatternSection::body as a URI for external resource tracking.

    A request was made to allow for richer descriptions in PatternSections than simple strings. The simplest, backward compatible patch for this is to provide guidance such that, if a user enters a simple URI into the body property, that URI is expected to point to an external resource that contains the description for that PatternSection.

    Specifically, Word files were requested. As we have no functionality within the OMG specs for directly embedding this data within a model in a meaningful manner, the URI method is workable.

  • Updated: Mon, 16 Oct 2017 15:15 GMT

Typo on page 18

  • Key: SPMSSR-4
  • Status: closed  
  • Source: Object Management Group ( Dr. Jason McC. Smith)
  • Summary:

    Section 10.1, page 18, paragraph 1:

    "Because we desire multiple definitions of a pattern for a variety os use cases,"

    should be

    "Because we desire multiple definitions of a pattern for a variety of use cases,"

  • Reported: IPMSS 1.0 — Wed, 25 Mar 2015 14:02 GMT
  • Disposition: Resolved — SPMS 1.1
  • Disposition Summary:

    Fix typo

    Section 10.1, page 18, paragraph 1 contains a typo:
    "Because we desire multiple definitions of a pattern for a variety os use cases,"
    should be
    "Because we desire multiple definitions of a pattern for a variety of use cases,"

  • Updated: Tue, 12 Jul 2016 14:46 GMT

Clarification needed on multiplicity of formalisms

  • Key: SPMSSR-3
  • Status: closed  
  • Source: Object Management Group ( Dr. Jason McC. Smith)
  • Summary:

    It is not clear initially how or if a formalism can refer to multiple sub-formalisms. While the model allows for it, the text does not make this explicit. Suggestion to add explanatory text to section 10.1.

  • Reported: IPMSS 1.0 — Wed, 25 Mar 2015 14:00 GMT
  • Disposition: Resolved — SPMS 1.1
  • Disposition Summary:

    Clarify that a FormalizedDefinition can be composed of other FormalizedDefinitions

    Recommend to replace Section 10.1 Paragraph 3 from:
    Because we desire multiple definitions of a pattern for a variety of use cases, many instances of FormalizedDefinition can be referenced by a single PatternDefinition. Each of these FormalizedDefinitions, in turn, can be composed using an extremely lightweight boolean logic mechanism defined here, to allow the composition of model fragments from a number of modeling domains. This satisfies our need for a single pattern formal definition requiring multiple views to properly describe the pattern. Many patterns, for instance, have both unique structural forms and run-time behaviors. It is unlikely that a single OMG model is going to capture all the nuances of each, but a combination of ASTM and OCL models, for instance, or PHORML and KDM, may be sufficient. For this reason, SPMS defines a minimalist composition mechanism for those that wish to have a lightweight yet compliant composition model. For more complex needs, an OCL expression may be used by an instance of DefinitionTerminal referencing an OCL model. This Formalisms package is shown in Figure 5.
    With:
    Because we desire multiple definitions of a pattern for a variety of use cases, many instances of FormalizedDefinition can be referenced by a single PatternDefinition. Each of these FormalizedDefinitions, in turn, can be composed of further instances of FormalizedDefinitions as sub-models, by using an extremely lightweight boolean logic mechanism defined here. This allows the composition of model fragments from a number of modeling domains into a comprehensive whole. This satisfies our need for a single pattern formal definition requiring multiple views to properly describe the pattern. Many patterns, for instance, have both unique structural forms and run-time behaviors. It is unlikely that a single OMG model is going to capture all the nuances of each, but a combination of ASTM and OCL models, for instance, or PHORML and KDM, may be sufficient. For this reason, SPMS defines a minimalist composition mechanism for those that wish to have a lightweight yet compliant composition model. For more complex needs, an OCL expression may be used by an instance of DefinitionTerminal referencing an OCL model. This Formalisms package is shown in Figure 5.

  • Updated: Tue, 12 Jul 2016 14:46 GMT

Clarification needed for multiplicity of Interpattern Relationships

  • Key: SPMSSR-2
  • Status: closed  
  • Source: Object Management Group ( Dr. Jason McC. Smith)
  • Summary:

    When reading the Relationships section (11.1) it appears at first glance that a pattern can only be a member of one category at a time. It only becomes obvious after looking at Figure 1 in the Definitions section (8.1) that the multiplicity of memberships in categories is shown there. The model is correct, but explanatory text should be added to section 11.1 to reiterate that a single PatternDefinition can have any number of Interpattern Relationships.

  • Reported: IPMSS 1.0 — Wed, 25 Mar 2015 13:56 GMT
  • Disposition: Resolved — SPMS 1.1
  • Disposition Summary:

    Clarify that a PatternDefinition can have many InterpatternRelationships

    Proposed to alter Section 11.1, pg 17, paragraph 1 from:
    The Relationships package defines classes to enable rich searching and semantic association in a repository or catalog of PatternDefinitions. The package overview is shown in Figure 6. InterpatternRelationship provides semantic linkages between PatternDefinitions. KnownUse provides specializations of PatternInstances suitable as examples of a PatternDefinition in concrete situations.
    To:
    The Relationships package defines classes to enable rich searching and semantic association in a repository or catalog of PatternDefinitions. The package overview is shown in Figure 6. InterpatternRelationship provides semantic linkages between PatternDefinitions. A PatternDefinition can have multiple InterpatternRelationship connections to allow for a rich connected network. KnownUse provides specializations of PatternInstances suitable as examples of a PatternDefinition in concrete situations.

  • Updated: Tue, 12 Jul 2016 14:46 GMT

Enhance PatternSection body to allow for more than raw strings as content

  • Key: SPMSSR-5
  • Status: closed  
  • Source: Object Management Group ( Dr. Jason McC. Smith)
  • Summary:

    Consumers of SPMS have requested the ability to include diagrams, pointers to existing documents, etc., in the section bodies.

  • Reported: IPMSS 1.0 — Mon, 21 Sep 2015 13:42 GMT
  • Disposition: Deferred — SPMS 1.1
  • Disposition Summary:

    Allow PatternSection to contain richer content than a simple string.

    Sec 8.1, final paragraph, page 9:

    Change from:
    Each PatternDefinition contains a list of these Roles, and a list of PatternSections. These PatternSections are prose entries that describe for a human reader the definition of the pattern as defined according to appropriate patterns communities that adopt SPMS.

    Change to:
    Each PatternDefinition contains a list of these Roles, and a list of PatternSections. These PatternSections entries contain prose, diagrams, or other necessary structured document contents to describe for a human reader the definition of the pattern as defined according to appropriate patterns communities that adopt SPMS.

    Sec 8.1 Figure 3, page 10:
    Replace with new Figure3.pdf (attached)

    Sec 8.5, paragraph 1, first sentence, page 11:
    Change from:
    A PatternSection is a free-form prose textual description of a portion of a PatternDefinition.

    Change to:
    A PatternSection is a description of a portion of a PatternDefinition. The description may be free-form prose, diagrams, models, or a structured combination thereof. The body attribute of the PatternSection is a generalized MOF::Element to allow for a multitude of formats and data, although the most common is expected to be simple text.

    Section 8.5, Attributes, page 12:
    Change from:
    body : String The contents of the PatternSection.

    Change to:
    body : MOF::Element The contents of the PatternSection.

    Modification to SPMS1.1.xmi: Convert body element type from PrimitiveTypes.xmi#String to UML.xmi#Element

  • Updated: Tue, 12 Jul 2016 14:46 GMT

Request for non-duplication of PINBoxes in cases of multiplicities

  • Key: SPMSSR-1
  • Legacy Issue Number: 19555
  • Status: closed  
  • Source: Object Management Group ( Dr. Jason McC. Smith)
  • Summary:

    On behalf of Gilles Malfreyt, Thales Group:

    p.25: section 12.5 Multiplicities: it seems that what is proposed leads to duplicate pattern instances each time a role is multiple.
    Maybe it would be interesting to also have the case where roles are multiple without duplicating pattern instances.

  • Reported: IPMSS 1.0b1 — Thu, 31 Jul 2014 04:00 GMT
  • Disposition: Resolved — SPMS 1.1
  • Disposition Summary:

    Clarify that MultiBranched Annotations can be used for multiple roles as well as multiple pattern instances

    Submitter of issue requested change to add multiplicity annotation for roles, but the capability was already extant in the specification and figures. Explanatory text needed to be added to make this explicitly clear on reading.

    Section 12.6.2, pg 30, paragraph 1 needs to be expanded. It currently reads as:

    The MultiBranch annotation can also be used within an Expanded PINbox, as shown in Figure 23. Now, we are showing both instances of the Decorator pattern, unlike in Figure 17 where we showed only one.

  • Updated: Tue, 12 Jul 2016 14:46 GMT

Suggestion to make existing connection bi-directional

  • Key: IPMFSSF-2
  • Legacy Issue Number: 19553
  • Status: closed  
  • Source: Object Management Group ( Dr. Jason McC. Smith)
  • Summary:

    On behalf of Gilles Malfreyt, Thales Group:

    p.15: Associations "members" from Perspective and from Category to PatternDefinition seem redundant with the fact that InterpatternRelationship already has an association with PatternDefinition [p.6]: wouldn't it be better to make this existing association bi-navigable?

  • Reported: IPMSS 1.0b1 — Thu, 31 Jul 2014 04:00 GMT
  • Disposition: Closed; No Change — IPMSS 1.0
  • Disposition Summary:

    The bi-navigable relationship would lose an important aspect of Perspectives and Categories as independent views into a repository of IPMSS definitions. A Category is a 'kind of' grouping for PatternDefinitions. A Perspective is a 'stakeholder view' grouping for PatternDefinitions. The MITRE folks asked for this distinction to allow for a more flexible way of presenting patterns catalogs to stakeholders who may have vastly different expectations of how to 'slice' Categories.

  • Updated: Wed, 8 Jul 2015 12:06 GMT

References to UML 2.4.1 hrefs in IPMSS XMI


Needs clarification of formalisms binding features

  • Key: IPMFSSF-3
  • Legacy Issue Number: 19554
  • Status: closed  
  • Source: Object Management Group ( Dr. Jason McC. Smith)
  • Summary:

    On behalf of Gilles Malfreyt, Thales Group:

    [following the fact that we don't understand the use of the boolean expressions (are they used for pattern conformance ? as set-like operations for combination of patterns ??...)]:

    p.11: We don't understand at all the usage of VariableToRole, PropertyToVar, PropertyToRole.

  • Reported: IPMSS 1.0b1 — Thu, 31 Jul 2014 04:00 GMT
  • Disposition: Resolved — IPMSS 1.0
  • Disposition Summary:

    Clarify FormalBinding

    FormalBinding was causing confusion, add explanatory text to provide guidance.

  • Updated: Wed, 8 Jul 2015 12:06 GMT

Formalisms need further clarification

  • Key: IPMFSSF-11
  • Legacy Issue Number: 19562
  • Status: closed  
  • Source: THALES ( Olivier Constant)
  • Summary:

    On behalf of Olivier Constant, Thales Group:

    My main concern is about the "formalism" concepts from Section 10, which are central in the specification. There seems to be a Boolean interpretation for FormalDefinition and all its subclasses, but this interpretation is not explicitly explained. What does it represent? Is it related to pattern conformance? It seems to me that this is a major issue.

  • Reported: IPMSS 1.0b1 — Thu, 31 Jul 2014 04:00 GMT
  • Disposition: Resolved — IPMSS 1.0
  • Disposition Summary:

    Add explanatory text to Formalisms package to clarify intentions and applicability

    The Formalisms package was lacking sufficient explanatory text to allow for implementation solely on the basis of the specification. This is now fixed. No changes made to metamodel or semantics, this is strictly explanatory text, but a significant amount of it.

  • Updated: Wed, 8 Jul 2015 12:06 GMT

Bindings multiplicity is inconsistent between sections

  • Key: IPMFSSF-8
  • Legacy Issue Number: 19559
  • Status: closed  
  • Source: THALES ( Olivier Constant)
  • Summary:

    On behalf of Olivier Constant, Thales Group:

    p.9. Section 9.2 states that "At least two Bindings will be associated with each PatternInstance, one for each Role in the matching PatternDefinition". However, Figure 4 and the description of role "fulfillments" in section 9.2 only specify a multiplicity with a lower bound of 1. Furthermore, section 8.2 and Figure 3 specify that a PatternDefinition may have a unique Role, which contradicts the sentence.

  • Reported: IPMSS 1.0b1 — Thu, 31 Jul 2014 04:00 GMT
  • Disposition: Resolved — IPMSS 1.0
  • Disposition Summary:

    One sentence in 9.3 (previously 9.2) mismatches the multiplicity stated in the remainder of the text. Fix to bring in line.

  • Updated: Wed, 8 Jul 2015 12:06 GMT

Inconsistencies between text and figures

  • Key: IPMFSSF-7
  • Legacy Issue Number: 19558
  • Status: closed  
  • Source: THALES ( Olivier Constant)
  • Summary:

    On behalf of Olivier Constant, Thales Group:

    p.6. Role PatternDefinition::relatedPatts in Figure 3 is named "relatedPatterns" in section 8.2.

    p.9-10. Role PatternInstance::instanceOf in Figure 4 is named "instantiates" in section 9.2.

    p.9-10. The multiplicity of role PatternObservation::foundVia is inconsistent: [*] in Figure 4, [0..1] in 9.3.

  • Reported: IPMSS 1.0b1 — Thu, 31 Jul 2014 04:00 GMT
  • Disposition: Resolved — IPMSS 1.0
  • Disposition Summary:

    Confirmed that XMI and Figures in question are correct, the text is incorrect.

    Editorial comment from Manfred Koethe, 88 Solutions, that Figure 3 needed a non-content-altering tweak of the position of some text. Updated Figure 3 is attached.

  • Updated: Wed, 8 Jul 2015 12:06 GMT
  • Attachments:

List machine readable files in specification

  • Key: IPMFSSF-6
  • Legacy Issue Number: 19557
  • Status: closed  
  • Source: Thematix Partners LLC ( Dr. Doug Tolbert)
  • Summary:

    The specification does not (or I missed where) list the accompanying machine readable files listed in the inventory. Seems to me it ought to do so. The FTF can certainly fix this one.

  • Reported: IPMSS 1.0b1 — Thu, 31 Jul 2014 04:00 GMT
  • Disposition: Resolved — IPMSS 1.0
  • Disposition Summary:

    List the machine readable files on the specification cover under "Normative Machine Consumable Files" using document URIs as reported by Juergen.

  • Updated: Wed, 8 Jul 2015 12:06 GMT

Clarify MOF Property vs. MOF Type or Class

  • Key: IPMFSSF-10
  • Legacy Issue Number: 19561
  • Status: closed  
  • Source: THALES ( Olivier Constant)
  • Summary:

    On behalf of Olivier Constant, Thales Group:

    p.14, section 10.11: "an MOF::Property, such as an MOF::Class or MOF::Type". In MOF, a Class or a Type is not a Property.

  • Reported: IPMSS 1.0b1 — Thu, 31 Jul 2014 04:00 GMT
  • Disposition: Resolved — IPMSS 1.0
  • Disposition Summary:

    MOF::Class and MOF::Type were incorrectly stated to be subclasses of MOF::Property. Text is corrected to no longer make this statement.

  • Updated: Wed, 8 Jul 2015 12:06 GMT

Clarification needed on 'Element' ownership of Property, or 'metaclass of Element' ownership of Property

  • Key: IPMFSSF-9
  • Legacy Issue Number: 19560
  • Status: closed  
  • Source: THALES ( Olivier Constant)
  • Summary:

    On behalf of Olivier Constant, Thales Group:

    p.11. Figure 5, a note states "Element must own Property". This implies that the Element be a MOF::Class/DataType/Association/Extension. What is really meant, according to my understanding, is "Metaclass of Element must own Property". A similar issue arises in section 10.11 in the description of PropertyToRole::from.

  • Reported: IPMSS 1.0b1 — Thu, 31 Jul 2014 04:00 GMT
  • Disposition: Resolved — IPMSS 1.0
  • Disposition Summary:

    MOF hierarchy false implication needs to be clarified. The intent was not that a MOF::Element contain a MOF::Property, as that limits the relationship to a certain subset of MOF classes. Instead, a metaclass was intended. The text in Figure 5, Sections 10.11 and 10.2 needs to be changed to reflect this.

  • Updated: Wed, 8 Jul 2015 12:06 GMT
  • Attachments:

URLs need to be corrected

  • Key: IPMFSSF-5
  • Legacy Issue Number: 19556
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    On behalf of Elisa Kendall, Thematix:

    A couple of nits – on the cover and in the inventory I noticed you included /PDF/ in the URI for the specification. While in practice that's where the pdf version of the specification might be posted, there might also be a PS version for postscript, etc, and I don't think you want the URI with /PDF/ in it to be the definitive URI for the spec on its cover. Linda would likely catch this in document production, but it's one of the first things I'd fix in FTF. Similarly in the inventory, URLs for the specification don't look right to me, for example, I would think that "http://www.omg.org/spec/IPMSS/PDF/IPMSS1.0.pdf" should be something closer to "http://www.omg.org/spec/IPMSS/1.0/IPMSS.pdf", and similarly with the changebarred version.

  • Reported: IPMSS 1.0b1 — Thu, 31 Jul 2014 04:00 GMT
  • Disposition: Resolved — IPMSS 1.0
  • Disposition Summary:

    Adopt Elisa's suggestions to remove '/PDF' from URIs, confirm document numbers/URIs w/ Juergen prior to submission.

  • Updated: Wed, 8 Jul 2015 12:06 GMT

Request for non-duplication of PINBoxes in cases of multiplicities

  • Key: IPMFSSF-4
  • Legacy Issue Number: 19555
  • Status: closed  
  • Source: Object Management Group ( Dr. Jason McC. Smith)
  • Summary:

    On behalf of Gilles Malfreyt, Thales Group:

    p.25: section 12.5 Multiplicities: it seems that what is proposed leads to duplicate pattern instances each time a role is multiple.
    Maybe it would be interesting to also have the case where roles are multiple without duplicating pattern instances.

  • Reported: IPMSS 1.0b1 — Thu, 31 Jul 2014 04:00 GMT
  • Disposition: Deferred — IPMSS 1.0
  • Disposition Summary:

    Stacked PINboxes (12.5.1) and the MultiBranch annotation (12.5.2) are designed to handle precisely this case, as shown in Figure 19 and 20 on page 26. If this is not clear, then we can clarify.

  • Updated: Wed, 8 Jul 2015 12:06 GMT