====== Adapting SysML to Domains ======

===== Rationale =====

To aid in the efficiency in creating models the modeler may adapt SysML to their particular domain. This can be done using several possibilities allowed in SysML:

  * Use of Profiles and Stereotype to extend the language (which is represented as meta-classes).
  * Use of Model Libraries to have a library of standard elements that the modeler can draw from.

===== Methodology =====

==== Process - Profiles ====

An established process((C.Paredis and T. Johnson, "Using OMG's SysML to support simulation" Proceeding of the 2008 Winter Simulation Conference (2008))) to create profiles is laid out below:
  - Create a metal-model for the specific domain that is being integrated. This could be done with the use of an [[bok:eng:mbse:ontology|ontology]].
  - Create a SysML profile that will map the meta model to SysML stereotypes
  - Create a transformation map between the meta model and SysML profile's entities
  - For each transformation include the corresponding API call to the domain specific tool

For an examination of applying SysML to other languages such as Modelica see [[bok:eng:mbse:sysml:integrate-sysml-other-languages|Integrating SysML with other languages]].

If language modeler wants to make the use of a particular profile mandatory then the relationship between the model and the profile shall be **required**.

==== Process - Model Library ====

Model Libraries are useful if the modeler wants to takes parts 'off-the-shelf' rather than re-create them. Should only be used for parts that will be re-used.

To merge a maintained XMI file (e.g. a standard item type model library) do the following:
  - Select the package that you want the model library to be a child of (e.g. if intended model hierarchy is 'Overview/Standard Item Type', and your XMI package top directly is 'Standard Item Type' then select 'Overview' package in your target model
  - Publish -> Model Exchange -> Import XMI -> Import Package from XML...
  - Select your source XMI -> Import
===== Parts =====

==== Metamodel ====

  * Metamodel is a model of a modelling language
  * It consists of concrete syntax, abstract syntax and semantics.
  * **Concrete syntax**: Facilitates the presentation and construction of models
  * **Abstract syntax**: Vocabulary of concepts provided by the language and how they may be combined to create models. Shown in //italics//. Abstract syntax deals solely with the form and structure of concepts in a language without any consideration given to their presentation or meaning ((Clark, Sammut & Williams, "Applied Metamodeling", Middlesex University London (2008) 2nd edition))
  * **Semantics**: Forms relationships between syntax to give them meaning.
==== Profiles ====

  * Profiles are a specialization of Packages.
  * Profiles may contain sub-packages and/or sub-packages.
    * Advantages of sub-profiles is that the sub-profiles may be applied independently to other sub-profiles
    * If parent profile is applied then by default all stereotypes within sub-packages are applied
  * Leaf nodes of a profile is its stereotypes
  * Serves one of two purposes:
    * Profile defines a set of concepts that support a new domain
    * Profile defines a set of concepts that add value to a model in a domain that is already supported.

==== Stereotypes ====

<WRAP center round info 60%>
Images in this section are copied from T. Weilkiens, "Systems Engineering with SysML/UML" MK Press (2006).
</WRAP>

  * Stereotypes are collected in Profiles (which is a specialization of Package).
  * Stereotype **extends** metaclass (a construct of SysML, e.g. "Block"). This extension relationship is a specialization of the association relationship.

{{:bok:eng:mbse:sysml:adapt:extend.png?300| }}

//Example of extending a metaclass with a Stereotype. Note the black arrow//
  * Stereotypes can also specialize other stereotypes
{{:bok:eng:mbse:sysml:adapt:generalization.png?400 |}}


=== Properties of Stereotypes ===

  * Properties of stereotypes are different to properties of blocks. E.g. a block "Vehicle" may have a property called inspector which records which inspector did the inspector for an instance of Vehicle. However a stereotype "Vehicle" which extends the metaclass "Block" may also have a property called inspector. In this case the property is intended to capture which inspector checked the specification of Vehicle and nothing to do with any particular Vehicle instance.