Help:- Create the SysML

In order to develop the SysML representation of the template, a SysML editor will be used, and so a tool specific development file for this template will need to be generated.

This file will be managed along with the other template specific information in SourceForge.

This development file will have to include sufficient package structure to locate the template within the SysML development environment when it is used in the development of other templates. This basically means that we need to ensure the structure of <<Context>>/Templates/<<Template>> is maintained for all templates in each context.

So as to maintain independance from a particular toolset, XMI is used as the underlying representation for the data. This makes use of xmi:id and xmi:uuid attributes to identify if things are the same or different. In order to keep the structure compatable, we have an index file that holds the upper structure (See Create the SysML index for the Context) which we will use to create our new template package. Once we have created the template package we can save that as a separate file under the source control system.

The basic tool independent procedure is as follows:

1. Generate the seed index file for the tool being used from the master tool independent index file plcslib\data\contexts\<<Context>>\index.xmi
2. Open the seed index file for the tool being used under plcslib\data\contexts\<<Context>>\dvlp\
3. Select the Templates package in the project structure
4. Create a new package called <<Template>> under the Templates package.
5. Under that <<Template>> package, create a new block called <<Template>>
6. Apply the <<Template>> stereotype to the <<Template>> block.
7. Save/export the new <<Template>> package in a way that allows it to be managed separately in the SysML tool being used.
8. Save the updated tool dependent index file for use by others using the same tool.
9. Generate the tool independent index file for all other users.

This basically defines the publicly visible properties of the template and any constraints between those properties. The public properties with lower multiplicities > 0 are the mandatory properties required to instantiate the template.

The public view of the template is given in a SysML Block Definition Diagram called "Template". This should be created using the following generic procedure:

• Open the Template Package project saved/exported from the index file.
• Select package called <<Template>>;
• Create a SysML Block Definition diagram called "Template" within the <<Template>> package;
• Drag the template named <<Template>> onto the diagram.

The properties of a template are either "Reference properties", "Part properties" or "Value properties".

• Reference properties - refer to objects that are not deletion dependent on the template. I.e. objects that may be used by / referenced by other templates. For example, Organization, Classification etc.
• Part properties - refer to objects that are deletion dependent on the template. These are principally Identifications and Descriptions. I.e. objects that are only instantiated/used in the context of the template
• Value properties - refer to simple types such as Strings, Booleans and Numbers.

The properties must have a type specification and a multiplicity defined. To support the type specifications the PLCS PSM must be included into the template development file.

If some of the properties are usages of other templates, defined in either this or another context, then the tool specific template file for those templates should also be included at this stage to allow their use as the types of the public properties.

The main constraints that will be used in developing templates are Uniqueness constraints. These are to be specified in OCL 2.0 as follows:

context <<Template>> inv
        <<UniqueId>>:
        <<Template>>::allInstances()->isUnique(<<propertyName>>
        or Sequence{<<propertyName>>,
        <<propertyName>>})

To ensure some consistency the following presentation guidelines should be followed:

• Position the Template block to minimize white space when exported as an image;
• Use a colour fill on the template block with the following setting RGB [204, 255, 204];
• Ensure only public properties, constraints and ports are shown;
• Group the properties by property classes (i.e. Parts, References and Values).

Save an image of the public view of the Template (SysML Block Definition Diagram) in PNG format to <<Template>>\Template.png

When a template is instantiated a number of internal components are instantiated to support the information requirements. These internal components can either be low level PLCS PSM data elements or other templates defined in this or another context.

These internal components are created as SysML private properties of the template block, i.e. properties as described above, but this time marked as private and not exposed in the public view. The public and private properties are related through assignments defined using a SysML binding connector.

Only part and reference properties can be defined as private within PLCSlib templates, this is to ensure that all public properties are eventually mapped to PLCS PSM data elements and not stored as simple values within a Template.

All public properties shall be connected via a binding connector to one, or more, private properties.

All private properties shall include a type specification and define their multiplicity. The multiplicity defines which of the internal components are created when the template is instantiated.

Occasionally it is not possible to directly assign a public property directly to a private property, this could be because it has to be combined with some other data or otherwise manipulated. To support this functional capability constraint blocks can be used to define the function that has to be performed. In this case binding connectors are attached to the input parameters of the usage of the constraint block within the parametric diagram and the output parameter connected to the relevant private property.

Flow ports are added to the template in order to provide access a subset of the private properties. These SysML Flow ports should be defined with a flow OUT direction and connected to the private properties with binding connectors. The flow ports should be have public visibility, have a meaningful name and include type and multiplicity information.

To ensure some consistency the following presentation guidelines should be followed:

• All public properties are shown on the left side of the SysML parametric diagram;
• All private properties are shown down the middle of the SysML parametric diagram;
• Show mandatory private properties towards the top of the diagram;
• All output ports are attached to the right side of the SysML parametric diagram frame;
• Position the properties to minimize white space when exported as an image;
• Use the following colour scheme to fill the properties:
  • properties that are templates use RGB [204, 255, 204];
  • properties that are PLCS PSM blocks use RGB [255, 240, 180];
  • constraint block usages use RGB [204, 204, 255].
• Use straight binding connectors where possible (avoid corners and do not use diagonal lines).

Save an image of the internal view of the Template (SysML Parametric Diagram) in PNG format to <<Template>>\ <<Template>>.png

Instances may be used for either default values inside the template or to reflect values expected by constraints.

1. Create a package named "Instances" under the <<Template>> package
2. Create SysML Block Definition diagram called "Instances" within the "Instances" package;
3. Add instances as required to the diagram;
4. Save an image of the Instances diagram in PNG format to <<Template>>\Instances.png.

Constraint may be defined for use within the template or to support the usage of the template within other templates.

1. Create a package named "Constraints" under the <<Template>> package
2. Create SysML Block Definition diagram called "Constraints" within the "Constraints" package;
3. Add constraint blocks as required to the diagram;
4. Add Constraint parameters to the constraints;
   NOTE    Output parameters should be marked ReadOnly.
5. Add Constraint specification to the constraints using OCL 2.0 language, functional constraints should be specified as: {output = function of inputs}
   NOTE    A good understanding of OMG OCL 2.0 is required for development of constraints.
6. Save an image of the constraints diagram in PNG format to <<Template>>\Constraints.png.

Once the template is complete, the SysML definition will need to be output as canonical XMI, a tool independent neutral format for the information contained in the SysML model.
As the majority of SysML tools currently do not fully support and export to canonical XMI, a set of ruby scripts are used to convert the specific tool output to the standard form.
These ruby scripts are found in the plcslib\etc\ directory, under a directory named after the tool they are linked with (i.e. Magicdraw).

Detailed instructions on how to produce the canonical XMI are contained in the guidelines section for the specific tool you are using (see Guidelines).

The following links provide detailed information on how to develop and update OASIS PLCS SysML templates using specific tools:

• MagicDraw specific development guidelines;
• Others to be added later.