OMG System Modeling Language Avatar
  1. OMG Specification

OMG System Modeling Language — Open Issues

  • Acronym: SysML
  • Issues Count: 25
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
SYSML16-84 Property Based Requirements SysML 1.3 open
SYSML16-100 Incorrect constraint [2] on InterfaceBlock SysML 1.3 open
SYSML16-106 Constraint [5] should include specializations of Requirement SysML 1.3 open
SYSML16-110 Ports and Flows SysML 1.3 open
SYSML16-98 Missing ownership constraints SysML 1.3 open
SYSML16-91 Callout notation for port-specific types and initial values SysML 1.3 open
SYSML16-99 Missing type constraints for FullPort SysML 1.3 open
SYSML16-117 Clarification required for Copy relationship SysML 1.3 open
SYSML16-116 Diagram show inconsistent data SysML 1.3 open
SYSML16-115 Don't use the optional notation for Pins with Allocation SysML 1.3 open
SYSML16-111 Figures 15.5 and 15.6 diagram types SysML 1.3 open
SYSML16-105 Figure 15.8 diagram type SysML 1.3 open
SYSML16-95 Contradiction regarding allowed use of the derived indicator for constraint parameters SysML 1.3 open
SYSML16-137 Convention for enumeration not used for ControlValue SysML 1.3 open
SYSML16-136 Update SysML references to UML model library StandardProfileL2 SysML 1.3 open
SYSML16-121 Unclear is StructuredActivityNode owned Actions should be Allocated SysML 1.3 open
SYSML16-114 Libraries package should be named "SysML Model Libraries" SysML 1.3 open
SYSML16-113 Allocated notation on object nodes missing from diagram elements table SysML 1.3 open
SYSML16-112 Allocation tabular notation normative? SysML 1.3 open
SYSML16-107 Inability to specify partial allocation and requriements satisfaction SysML 1.3 open
SYSML16-104 View and Viewpoint Limitations in support of auto-view generation SysML 1.3 open
SYSML16-92 remove figure numbers from diagram frames SysML 1.3 open
SYSML16-78 InstanceSpecification equality SysML 1.3 open
SYSML16-77 InstanceSpecifications for exactly one instance SysML 1.3 open
SYSML16-76 Problems with property-specific types SysML 1.3 open

Issues Descriptions

Property Based Requirements

  • Key: SYSML16-84
  • Legacy Issue Number: 17016
  • Status: open  
  • Source: Lockheed Martin ( John Watson)
  • Summary:

    In SysML today requirements can be represented in a model only in a textual form. Being textually based these requirements often introduce ambiguity, are often redundant with other model element properties, and lack a formally making it difficult to leverage directly in parametric and other analysis efforts.
    This issue suggests an alternative means of representing requirement in the model environment without using a pure text string. The alternative means is referred to as Property Based Requirement (PBR). PBR defines a requirement mathematically and defines a set of requirement properties. The goal is declare other types of model elements as requirements and apply these properties to those model elements.

    A PBR theory is described in a paper called “Toward a Property Based Requirements Theory: System Requirements Structured as a Semilattice” by Patrice Micouin. This technique is further elaborated in a paper called “Requirements Management within a Full Model-Based Engineering Approach” by Yves Bernard

  • Reported: SysML 1.3 — Thu, 19 Jan 2012 05:00 GMT
  • Updated: Thu, 14 Dec 2017 15:23 GMT

Incorrect constraint [2] on InterfaceBlock

  • Legacy Issue Number: 18183
  • Status: open  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Constraint [2] specifies that "Interface blocks cannot have composite properties that are not ports". However, in order to show FlowProperties, typed by ValueTypes and owned by InterfaceBlocks, you need to be able to have composite properties.

    The constraint at the moment is too strict and needs to be changed to allow certain composite properties.

  • Reported: SysML 1.3 — Fri, 19 Oct 2012 04:00 GMT
  • Updated: Thu, 30 Nov 2017 12:41 GMT

Constraint [5] should include specializations of Requirement

  • Legacy Issue Number: 18410
  • Status: open  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Constraint [5] states:

    "A nested classifier of a class stereotyped by «requirement» must also be stereotyped by «requirement»."

    This would seem to stop Requirements from owning Classes stereotyped by specializations of Requirements (for example, ExtendedRequirement from D.2.2 Stereotypes), which seems too limiting. I'd suggest this is reworded to:

    "A nested classifier of a class stereotyped by «requirement» must also be stereotyped by «requirement» or one of its specializations"

  • Reported: SysML 1.3 — Tue, 5 Feb 2013 05:00 GMT
  • Updated: Thu, 16 Nov 2017 16:19 GMT

Ports and Flows

  • Legacy Issue Number: 18458
  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

    The title of section 9.4.2 includes the term "Flow Ports", which is deprecated. I think it should be "Flow properties". Maybe an editing instruction for a 1.3 issue exists for this, not sure.

  • Reported: SysML 1.3 — Fri, 15 Feb 2013 05:00 GMT
  • Updated: Mon, 20 Mar 2017 00:28 GMT

Missing ownership constraints

  • Key: SYSML16-98
  • Legacy Issue Number: 18181
  • Status: open  
  • Source: PTC ( Phillip Astle)
  • Summary:

    The FlowProperty stereotype can current be applied to any Property in SysML. However, this leaves it open to applying the stereotype to Ports (inc. extensions of Ports) and Properties owned by non-Blocks. This doesn't seem to match the intent of the specification so constraints need to be added

  • Reported: SysML 1.3 — Fri, 19 Oct 2012 04:00 GMT
  • Updated: Thu, 16 Mar 2017 07:54 GMT

Callout notation for port-specific types and initial values

  • Key: SYSML16-91
  • Legacy Issue Number: 17406
  • Status: open  
  • Source: oose Innovative Informatik eG ( Axel Scheithauer)
  • Summary:

    The specification allows property-specific types and property-specific initial values. Ports are just a special kind of property. Thus it would be possible to model port-specific types and values. The only problem is, that it is not possible to show the specifics of these types or the initial values within an internal block diagram, as would be the case for a property.

    Suggested addition to the spec

    • property-specific types and initial values also apply to ports [would not be forbidden now, but just to clarify this point]
    • A callout notation can be used in an ibd for ports with a port-specific type or initial value. It shows the same information as the compartments for properties.
    • Table 8.3: Example for call-out notation

    Maybe this notation could also be used on block definition diagrams, and in this case for properties as well. Then there should be a sentence in chapter 8.1.1.1 and an example in Table 8.2.

  • Reported: SysML 1.3 — Tue, 5 Jun 2012 04:00 GMT
  • Updated: Thu, 16 Mar 2017 07:51 GMT

Missing type constraints for FullPort

  • Key: SYSML16-99
  • Legacy Issue Number: 18182
  • Status: open  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Ports stereotyped as FullPort can currently be typed by anything a normal Port can be typed by. This isn't the intent of the specification, so constraints should be added.

  • Reported: SysML 1.3 — Fri, 19 Oct 2012 04:00 GMT
  • Updated: Thu, 16 Mar 2017 07:26 GMT

Clarification required for Copy relationship

  • Legacy Issue Number: 18525
  • Status: open  
  • Source: PTC ( Phillip Astle)
  • Summary:

    There's a few issues with the Copy relationship as described in the specification.

    1. It's unclear what constraint 3 means. What are subrequirements (nested or derived)?

    2. How do you match subrequirements in the slave to subrequirements in the master?

    3. There's no constraint on the number of Copy relationships that a slave Requirement can be involved in (e.g. one Requirement could be the slave of two different master Requirements). What happens to the "text" tag if there are multiple masters?

    4. There's no constraint stopping a Requirement from being directly or indirectly a master of itself. Shouldn't there be?

  • Reported: SysML 1.3 — Mon, 4 Mar 2013 05:00 GMT
  • Updated: Sun, 5 Mar 2017 02:51 GMT

Diagram show inconsistent data

  • Legacy Issue Number: 18503
  • Status: open  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Diagrams C.35, C.36 and C.37 show inconsistent allocation between the displayed items, yet the text would seem to imply that they're supposed to show the same relationships.

    In C.35, the allocation is from an ObjectNode symbol called "DriveCurrent" (which I believe equates to an ObjectFlow - name unknown) to an ItemFlow called "i1".

    In C.36, the allocation is from an ObjectNode called "DriveCurrent" to a Connector (name unknown).

    In C.37, the allocation is from an ObjectFlow called "o6" to a Connector called "epc-emg.1".

    There are a number of issues:

    1. ObjectNode is an abstract specialization of ActivityNode and as such you can't have any instances of them in a model. Any reference to an ObjectNode should be removed.

    2. The allocation should consistently be from ObjectFlow "o6" to either ItemFlow "i1" or Connector "epc-emg.1".

    3. In order to make it clear that the same items are being related, the names of the ObjectFlow and the Connector/ItemFlow should be shown on all diagrams. Currently the ObjectFlow and the Connector names are not shown.

  • Reported: SysML 1.3 — Tue, 26 Feb 2013 05:00 GMT
  • Updated: Sun, 5 Mar 2017 02:43 GMT

Don't use the optional notation for Pins with Allocation

  • Legacy Issue Number: 18502
  • Status: open  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Figure C.35 uses the optional notation for Pins (i.e. >[]> instead of []->[]). The allocation callout note is anchored to the object node symbol which makes it ambiguous as to which dictionary item(s) are being allocated. It could be one of the following:

    + the origin and destination pins
    + the object flow
    + the common type of the pins

    Since it's unclear what is being allocated, it would make more sense to show the Pins on the diagram and link the callout note to the relevant item(s) (I believe it's supposed to go to the ObjectFlow).

  • Reported: SysML 1.3 — Tue, 26 Feb 2013 05:00 GMT
  • Updated: Sun, 5 Mar 2017 01:53 GMT

Figures 15.5 and 15.6 diagram types

  • Legacy Issue Number: 18459
  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Figures 15.5 (Example of flow allocation from ObjectFlow to Connector) and 15.6 (Example of flow allocation from ObjectFlow to ItemFlow) have ibds on the right, but those ibds have blocks instead of parts in them. Are they supposed to be a bdds? The blocks show parts, but the compartment doesn't say "structured" (same for Figure 15.8).

  • Reported: SysML 1.3 — Fri, 15 Feb 2013 05:00 GMT
  • Updated: Sat, 4 Mar 2017 11:46 GMT

Figure 15.8 diagram type

  • Legacy Issue Number: 18409
  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Figure 15.8 (Example of Structural Allocation) is an ibd, but has blocks instead of parts in it. Is it supposed to be a bdd?

  • Reported: SysML 1.3 — Fri, 27 Jun 2014 11:16 GMT
  • Updated: Sat, 4 Mar 2017 11:32 GMT

Contradiction regarding allowed use of the derived indicator for constraint parameters

  • Key: SYSML16-95
  • Legacy Issue Number: 17546
  • Status: open  
  • Source: Delligatti Associates, LLC ( Lenny Delligatti)
  • Summary:

    There is a contradiction in the SysML spec. regarding whether constraint parameters-as properties of constraint blocks-may use the derived indicator, "/".

    Pg. 84 of the spec. clearly states the original intent of the SysML Development Team with respect to constraint blocks: "The block constraints are non-causal and do not specify the dependent or independent variables. The specific dependent and independent variables are often defined by the initial conditions, and left to the computational engine."

    On pg. 86, however, the spec. states textually that constraint parameters are properties of constraint blocks: "All properties of a constraint block are constraint parameters, with the exception of constraint properties that hold internally nested usages of other constraint blocks."

    There is no metamodel fragment in the spec. that shows that the stereotype SysML::ConstraintParameter extends the metaclass UML4SysML::Property. The text on pg. 86 (quoted above) conveys this.

    As a result of this (implied) extension relationship, we would have to conclude that a constraint parameter could use the derived indicator, "/", to convey that it is a dependent variable in the constraint expression.

    This stands in contradiction, however, to the intended non-causal, non-directional nature of constraint blocks as expressed on pg. 84.

    Proposed Resolutions:

    1) Add a metamodel fragment to the spec. that clearly shows the extension relationship from SysML::ConstraintParameter to UML4SysML::Property.
    2) Add a constraint to the SysML::ConstraintParameter stereotype disallowing the use of the derived indicator, "/", on constraint parameters.

  • Reported: SysML 1.3 — Wed, 8 Aug 2012 04:00 GMT
  • Updated: Sat, 4 Mar 2017 09:19 GMT

Convention for enumeration not used for ControlValue

  • Legacy Issue Number: 19134
  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The convention

    Enumeration types: always end with “Kind” (e.g., “DependencyKind”)

    is not used for the ControlValue enumeration. It should be named ControlValueKind.

  • Reported: SysML 1.3 — Thu, 5 Dec 2013 05:00 GMT
  • Updated: Thu, 23 Feb 2017 13:11 GMT

Update SysML references to UML model library StandardProfileL2

  • Legacy Issue Number: 19123
  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The UML model library "StandardProfileL2" is called "StandardProfile" since UML 2.5. The new library also include the StandardProfileL3 library.

    Update the references in the SysML specification (chapter 4.2, 5.1.1, 17) and check whether SysML should also include the StandardProfileL3 stereotypes that are now part of the StandardProfile library.

  • Reported: SysML 1.3 — Mon, 25 Nov 2013 05:00 GMT
  • Updated: Thu, 23 Feb 2017 13:11 GMT

Unclear is StructuredActivityNode owned Actions should be Allocated

  • Legacy Issue Number: 18678
  • Status: open  
  • Source: PTC ( Phillip Astle)
  • Summary:

    In the Constraints section the specification states the following:

    'An Action appearing in an “AllocateActivityPartition” will be the /client (from) end of an “allocate” dependency. The element that represents the “AllocateActivityPartition” will be the /supplier (to) end of the same “allocate” dependency.'

    For Actions owned by an Activity and shown inside the partition, this constraint is clear. However, if you have a StructuredActivityNode inside a partition and that StructuredActivityNode owns an Action, how many Allocate dependencies should there be? Should there be:

    a) One allocate from the StructuredActivityNode only?
    b) One allocate dependency from the StructuredActivityNode and one from the Action inside the StructuredActivityNode?

    To make things clearer, instead of the constraints section saying:

    'An Action appearing IN an "An Action appearing in an “AllocateActivityPartition”'

    It should say something along the lines of:

    'An Action referenced in the "node" role of an “AllocateActivityPartition”'

    This would remove the ambiguity of what "in" means and allow users to decide when Allocate dependencies are created.

  • Reported: SysML 1.3 — Fri, 19 Apr 2013 04:00 GMT
  • Updated: Thu, 23 Feb 2017 13:06 GMT

Libraries package should be named "SysML Model Libraries"

  • Legacy Issue Number: 18462
  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

    The spec headings refer to model libraries using the adjective "model", so the package name should include it also. The name should start with "SysML" since it is separate from the SysML package.

  • Reported: SysML 1.3 — Sun, 17 Feb 2013 05:00 GMT
  • Updated: Thu, 23 Feb 2017 13:04 GMT

Allocated notation on object nodes missing from diagram elements table

  • Legacy Issue Number: 18461
  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

    In Allocations, the Diagram Element table is missing the notation for allocated object nodes shown in Figure 15.7 (Example of flow allocation from ObjectNode to FlowProperty).

  • Reported: SysML 1.3 — Fri, 15 Feb 2013 05:00 GMT
  • Updated: Thu, 23 Feb 2017 13:03 GMT

Allocation tabular notation normative?

  • Legacy Issue Number: 18460
  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

    The clause Allocations, Usage Example, Tabular Representation is in the normative part of the spec, but refers to a tabular notation in Annex C, which isn't normative. Is the tabular notation normative?

  • Reported: SysML 1.3 — Fri, 15 Feb 2013 05:00 GMT
  • Updated: Thu, 23 Feb 2017 13:03 GMT

Inability to specify partial allocation and requriements satisfaction

  • Legacy Issue Number: 18434
  • Status: open  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    The allocate and requirements relationships (e.g., satisfy, verify, derive) do not explicitly state the degree to which these relationships apply. For example, a satisfy relationship may imply a model element may fully satisfy, partially satisfy, or not satisfy at all a particular requirement at a point in the design process. However, there is no standard way to refer to this partial vs complete satisfaction. A similar issue applies to the verify and derive relationships.

    Note: Similar issues apply to allocate relationships where the allocate may indicate that the element is fully or partially allocated to another element.

    The SysML spec should consider incorporating a tagged value to indicate 0, partial or complete on these relationships.

  • Reported: SysML 1.3 — Fri, 8 Feb 2013 05:00 GMT
  • Updated: Thu, 23 Feb 2017 13:02 GMT

View and Viewpoint Limitations in support of auto-view generation

  • Legacy Issue Number: 18391
  • Status: open  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    An important capability of a model based approach is the ability to automatically generate Views of the information from the model to support specific stakeholder Viewpoints. These Views may include the presentation of the modeling information in multiple forms such as diagrams, tables, or entire documents captured in different formats (e.g., MS Word, html, ppt, video). The View and Viewpoint constructs in SysML were included to aid in the automatic generation of Views, by enabling the specification of the View information and its presentation to address the stakeholder concerns. The View generation is generally implemented by other rendering applications.

    At the SE DSIG meeting on June 18, 2012 in Cambridge, several individuals presented and demonstrated common practices for View generation from a model that are providing value to end users. The presentations are available from the Cambridge SE DSIG meeting page. The practices required the users and vendors to further extend View and Viewpoint in different ways to overcome inherent limitations in order to leverage their respective View generation capabilities. The lack of a standard approach limits interchange and requires that each user and vendor include their unique extensions.
    The specific limitations of View and Viewpoint are described below. For background, the Viewpoint and View descriptions in the SysML specification v1.3 currently read as follows:
    Viewpoint: A Viewpoint is a specification of the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder concerns. The languages and methods for specifying a view may reference languages and methods in another viewpoint. They specify the elements expected to be represented in the view, and may be formally or informally defined. For example, the security viewpoint may require the security requirements, security functional and physical architecture, and security test cases.
    View: A View is a representation of a whole system or subsystem from the perspective of a single viewpoint. Views are allowed to import other elements including other packages and other views that conform to the viewpoint.
    Based on the above descriptions, the Viewpoint specifies how to construct a View, and the View is a representation that conforms to this specification.
    Some of the limitations that have been identified include the following:
    a) Viewpoint method limitations. The current Viewpoint contains a property called method that is typed by a text string (methods:String[*]). In order to auto-generate Views, the Viewpoint should include provisions to more formally specify ‘the conventions and rules for constructing and using a view’. This may include specifying executable methods to query the model that extract the desired information from the model, and present the information to the stakeholders. Viewpoint methods must be capable of specifying the scope of the information to be rendered, how the information should be rendered, as well as other methods related to checking, validating, or otherwise analyzing the information. The scope of the information may include information from other data sources not contained directly in the model. (Note: Standard methods may be captured in a method library that specify how to query, transform, analyze, present, and render data.)
    The viewpoint method does not include provisions for specifying the language for the methods. Adding the ability to designate the language would clarify viewpoint.
    b) Viewpoint description limitations. The current viewpoint description should be clarified to note that it should specify the presentation of the information as well as the information itself. This may require additional viewpoint properties to enable the specification of the form and format of the information. The form of the data in this context refers to how the information is presented such as data values that are in tabular form or a plot. The format of the data in this context refers to the file format that is used for the rendering application.
    c) View import limitations. The current View description says “Views are allowed to import other elements including other packages and other Views that conform to the Viewpoint”. View also includes a constraint that ‘A view can only own element import, package import, comment and constraint elements’. This concept of importing model elements into a package is not a sufficient means for constructing Views. The relationship between the view and the model elements should reflect the concept that the View can be constructed by defining operations to query models and other sources of data, and perform other operations on the information to present it in a form that is useful to the stakeholders.
    d) Other view construction limitations. A View conforming to a Viewpoint may be constructed from different sets of information that may be rendered as an entire document, a part of a document, a set of powerpoint slides or an individual slide, a video or series of videos, or other form. A typical example may be a security View that represents security requirements, design, and verification information. This requires the View to be constructed from sub-views, and that these sub-views must be ordered in a particular way to present to the user. An example would be the ordering of sections in a document, where each section represents a subview which in-turn represents selected information.
    A current limitation is the inability to express the ordering and general organization of the View and corresponding subviews that comprise the View (Note: this is a structural ordering and not a temporal ordering). Some of the current approaches have addressed this limitation by including a dependency relationship between the subviews. The relationships can express a precedence relationship (i.e.., next) and a decomposition relationship (i.e., first). A simple example of how these relationships are used to construct a View that is presented to the stakeholder as a document is described below.
    In a simple example, different subviews may correspond to different sections of a document that comprise the View. For example, some text with a table of information from one part of the model may appear in Section 1, and some other text with a diagram that represents other model information may appear in Section 2. Each section of the document may require different viewpoints to specify the query and presentation. There is currently no way to describe that a View that conforms to a Viewpoint contains multiple subviews with the relationships as indicated in the figure. There is a need to create a View that contains subviews that are related to one another with the types of relationships indicated (e.g., first, next). (Note: It is anticipated that the View and subviews should be reusable, and may require additional metadata ).
    In this example, each section of the document corresponds to a particular subview. However, we do not want to restrict a subview so that the information cannot be distributed across multiple sections of a document, or across multiple documents.
    e) Reuse of view and viewpoint. There needs to be sufficient expression to construct reusable definitions of view and viewpoint. These mechanisms may include composition, specialization, model libraries, and others.
    f) Viewpoint property limitations. Some of the Viewpoint properties, such as stakeholder, concern, and modeling language are currently typed as text strings, and may be better represented by other types. For cases where these elements are common among different viewpoints, there is no way to model these elements or the relationships between them. In a large-scale model, this becomes very difficult to scale. In particular, it is difficult to reuse the model elements such as stakeholder across different viewpoints, and it is difficult to perform automated checking of the viewpoints based on these viewpoint properties. The viewpoint properties should be typed by model elements that enable this reuse and checking.
    g) Other View and Viewpoint Mechanisms. There may be additional ways to create views more directly in the model. For example, a view may correspond to a filtered subset of a set of parts on an ibd corresponding that are based on some criteria (e.g., all electrical parts). This is similar to issue 13928 called the partition construct (later referred to as element group).

  • Reported: SysML 1.3 — Mon, 28 Jan 2013 05:00 GMT
  • Updated: Thu, 23 Feb 2017 13:01 GMT

remove figure numbers from diagram frames

  • Key: SYSML16-92
  • Legacy Issue Number: 17423
  • Status: open  
  • Source: Deere & Company ( Roger Burkhart)
  • Summary:

    Remove figure numbers where they still exist within the SysML diagram frame tab. As content is reshuffled in the document, figure numbers inside the diagrams can become out-of-sync with the figure numbers in the document, as is currently the case for figures C.35 and C.37. Maintain the figure number only in the figure caption, not redundantly within the diagram itself.

    Diagrams that include figure numbers in the diagram frame tab include 4.2, 4.3, 17.5, C.35, C.36, and C.37.

  • Reported: SysML 1.3 — Tue, 12 Jun 2012 04:00 GMT
  • Updated: Thu, 23 Feb 2017 12:57 GMT

InstanceSpecification equality

  • Key: SYSML16-78
  • Legacy Issue Number: 16653
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Multiple InstanceSpecifications can describe overlapping sets of instances, and some application need to specify whether the sets overlap. For InstanceSpecifications that specify exactly one instance, this indicates whether they describe the same instance, like the sameAs stereotype in the Ontology Definition Metamodel.

  • Reported: SysML 1.3 — Mon, 7 Nov 2011 05:00 GMT
  • Updated: Thu, 23 Feb 2017 12:52 GMT

InstanceSpecifications for exactly one instance

  • Key: SYSML16-77
  • Legacy Issue Number: 16652
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    InstanceSpecifications describe sets of instances, including the empty set, but some applications need to describe exactly one instance. SysML should have InstanceSpecifications that are constrained to describe exactly one instance, like the owlIndividual stereotype in the Ontology Definition Metamodel.

  • Reported: SysML 1.3 — Mon, 7 Nov 2011 05:00 GMT
  • Updated: Tue, 21 Feb 2017 16:33 GMT

Problems with property-specific types

  • Key: SYSML16-76
  • Legacy Issue Number: 16636
  • Status: open  
  • Source: Deere & Company ( Roger Burkhart)
  • Summary:

    Definition of a property-specific type cannot be shown on a bdd. This would require, at least, a defined name for the block or value type that types the property, such as one based on the property name.

    No runtime semantics is given. Presumably all instances of a property-specific type are values of the property it types, but this isn't said anywhere. It the property it types is an end of an association, this could be expressed by a lower multiplicity greater than zero on opposite end.

    No examples of property specific types are given.

    The requirements for property-specific types to be anonymous, singly generalized, and owned by the owner of the property they type don't appear to be necessary. Naming is useful for managing PSTs, multiple generalization is useful for reusing property defaults and other characteristics on multiple PSTs, and package ownership enables the same PST to be used on multiple properties that have the same type.

    The description of the property-specific types refers to:

    "local specializations of referenced typed" (Section 8.3.1.1 Block Definition Diagram) and

    "starting classifier of the property-specific type." (Section 8.3.2.7 PropertySpecificType)

    The terms "local", "referenced type", "starting classifier nof the property specific type" are undefined and not deducible from other text.

    The following sentence is a tautology (ie, adds nothing to the spec):

    "The PropertySpecificType stereotype is automatically applied to the "classifier that types a property with a propertyspecific type. (Section "8.3.2.7 PropertySpecificType)"

    because a property with a property specific type is one where the property type has the PropertySpecificType applied.

    Section 8.3.1.1 (Block Definition Diagram) at the end says the name of the property specific type can be included in brackets, but constraint [2] of PropertySpecificType says they are anonymous.

    The discussion of compartments on internal properties in Section 8.3.1.2 (Internal Block Diagram) can be simplified by removing the discussion of property-specific types.

  • Reported: SysML 1.3 — Thu, 27 Oct 2011 04:00 GMT
  • Updated: Tue, 21 Feb 2017 16:19 GMT