NextGenSysML Part 15 – SysML API & Services: Service Requirements

NextGenSysML Part 15 – SysML API & Services: Service Requirements

SysML v2 Logo

This blog post presents the service requirements of the SysML v2 API & Services RFP. It is the final part of a blog post series about the upcoming new SysML v2 and SysML API & Services standard. The blog posts present the requirements for the standard stated in the request for proposals (RFP) published by the OMG. See the end of this post for a list of all posts of this series, including a link to the first post of the series that provides an overall introduction.

The RFP contains a list of mandatory and non-mandatory requirements for services. Non-mandatory means that the team developing the SysML v2 API & Services can determine which requirements to include in the specification; see also blogpost NextGenSysML Part 1 about the meaning of mandatory and non-mandatory requirements in an OMG RFP. Let us start with mandatory service requirements. I only provide a brief list of the services to give you an overview. You find more details in the SysML v2 API & Services RFP.

With an implementation that satisfies the mandatory service requirements you

  • you can specify the model and its version for a request.
  • you can specify pre- and postconditions of a service.
  • you get a standard response structure for all services.
  • you can navigate a SysML model, i.e., define a starting point for navigation a retrieve model elements by a given query.
  • you can create model elements.
  • you can update model elements.
  • you can delete model elements according to deletion semantics that, for example, deletes additional dependent model elements.
  • you can get all external relationships for a given SysML element. An external relationship is a relationship from a SysML model element to an element outside of the SysML model in another SysML or non-SysML model.
  • you can create an external relationship.
  • you can update an external relationship.
  • you can specify the types and semantics of external relationships, which includes at least: traceability, version tracking, executable model wrapping, surrogate, model generation.

With an implementation that satisfies the non-mandatory service requirements

  • you get a standard query model, i.e., a language and platform-independent interface.
  • you can execute queries specified using the standard query model.
  • you can create multiple model elements in bulk.
  • you can update multiple model elements in bulk.
  • you can delete multiple model elements in bulk.
  • you can create multiple external relationships in bulk.
  • you can update multiple external relationships in bulk.
  • you can delete multiple external relationships in bulk.
  • you can use the CRUD operations on viewpoint-related model elements.
  • you can create, update, delete, and query views.
  • you can use the CRUD operations on analysis-related model elements.
  • you can specify a service to execute analysis models.
  • you can define the rules which model elements are model configuration items (MCI), and types of changes in an MCI that creates a version update.
  • you can create and delete versions of an MCI.
  • you can get the version history of an MCI.
  • you can create baseline configurations, create branch configurations, and merge branches.
  • you can create, read, update, and delete data protection control markings (see also blogpost NextGenSysML Part 4 about data protection in SysML v2).
  • you can create, read, update, delete, and execute model transformations.
  • you can transform a SysML v1 model to a SysML v2 model.
  • you can generate the textual representation of a SysML v2 model (see also blogpost NextGenSysML Part 3 about the concrete textual syntax of a SysML v2 model).
  • you can generate a SysML v2 model from a textual representation conforming to the concrete textual syntax.
  • you can read timestamps on existing model elements.
  • you can generate a universally unique identifies (UUID).
  • you can create and remove callbacks.

This was the final blog post of the series. In the meantime, the SysML Submission Team (SST), who develops the SysML v2, made significant progress. Following posts in the MBSE4U blog will have a look at the new features of the SysML v2 and how to use them.

Previous blog posts of this series:

Leave a Reply

Your email address will not be published. Required fields are marked *