1. OMG Mailing List
  2. Structured Patterns Metamodel Standard (SPMS) 1.2 Revision Task Force

All Issues

  • All Issues
  • Name: spms-rtf
  • Issues Count: 6

Issues Descriptions

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

  • Key: SPMS12-1
  • Status: closed  
  • Source: The Software Revolution ( Jason 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

Normative references

  • Key: SPMS12-2
  • Legacy Issue Number: 19886
  • Status: closed  
  • Source: Adaptive ( 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: SPMSSR-5
  • Status: closed  
  • Source: The Software Revolution ( Jason 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

Typo on page 18

  • Key: SPMSSR-4
  • Status: closed  
  • Source: The Software Revolution ( Jason 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: The Software Revolution ( Jason 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: The Software Revolution ( Jason 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