SysML 1.0 FTF Avatar
  1. OMG Issue

SYSML — plug a gap wrt how to recognize diagrams that come with a default namespace

  • Key: SYSML-106
  • Legacy Issue Number: 10378
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Am studying the adopted sysml spec ptc/06-05-04, noted the following possible bug.

    IMO, Annex A needs to plug a gap wrt how to recognize diagrams that come with a default namespace. I can see no way to know whether a diagram is designating a default namespace. The <modelElementName> in the header seems to have been intended to do this, but it is not up to the job.

    One way to plug this gap would be to make modelElementName optional in heading, and specify that, if present, the model element instance it names must be an instance of a namespace metaclass, which is the default namespace.

    Another way is to add a mandatory <namespace> field in the header, and specify some concretely recognizable value, such as the string "None" or an equivalent in the local language, as a valid value.

    details:

    Annex A, A.1 Overview, page 167 of the pdf pagination, states: The frame is a rectangle...The frame can designate a model element that is the default namespace for the model elements enclosed in the frame. This means the rectangle is a concrete graphic notation which may, optionally, represent a namespace, with the implication that in that case, whatever is shown inside the contents area of the frame, is (unless explicitly represented otherwise) contained within the represented namespace.

    But how does a user of the diagram know whether this option is being taken? In any particular case, the frame may not designate a model element that is the default namespace, and yet there must be some value present for modelElementName.

    This name could even designate an element of namespace type. How is that case to be recognized?The modelElementType field is optional. Is the intent that, if a value is present for modelElementType, and is a specialization of namespace, that this is the default namespace?

    Was the intent that in that case, the Header would not include a modelElementName? If so, we need a concrete way to show that the modelElementName in the Header is null.

    But what if the modelElementName field in the Header is not null, but the model element it names is not a namespace? A case where one might want to do this is when the focus or point of the diagram revolves around some particular element owned by a namespace. I am not advocating that, but trying to debug the spec.

    I suspect we need one of the following:

    1. either a constraint that requires the value in the <modelElementName> field to refer to a namespace element,
    2. or a way to show that the <modelElementName> is intended to name a namespace which applies by default to any element shown within the contents area.

    It also states: The top level "Model" name is the highest level namespace for the model elements.

    Intuitively the point of this seems to be that what we call "the model" is generally the root of the namespace hierarchy for model elements. . However, the specification of the frame, contents area, heading, and diagram description, nowhere uses the terminology "Model" name . So it seems that this sentence is irrelevant in the present context?

    The text describing the frame says The frame can designate a model element that is the default namespace for the model elements enclosed in the frame. This implies that a model element named in the header may not be the default namespace for the model elements, indeed it may not be a namespace at all. But in that case, what does it signify? It is not mandatory that the frame designate a model element.

    I conclude that the spec needs to allow that the modelElementName is optional, and that, if present, the model element instance it names shall be an instance of a namespace metaclass, and if absent, some concretely recognizable value, such as the string "None" shall be put in that field.

  • Reported: SysML 1.0b1 — Fri, 29 Sep 2006 04:00 GMT
  • Disposition: Resolved — SysML 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT