NextGenSysML Part 14 – SysML API & Services: Architecture and Conformance Requirements
This blog post presents the architecture and conformance requirements of the SysML v2 API & Services RFP. It is 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 SysML v2 API & Services standard is a game-changer. It enables standard service requests to access, navigate, and operate on SysML v2 models, and facilitates interoperability between modeling environments.
The architecture of the SysML v2 API & Services shall include a platform-independent model (PIM), platform-specific models (PSM), and the mapping between the PIM and PSMs.
The concept of PIM and PSM is based on the Model-Driven Architecture (MDA).
The following figure from the RFP document illustrates the architecture approach:
The PIM specifies the services, i.e., collection of operations, independent of specific implementations like OSLC, REST, Java, and so on. The input and output objects of the operations depend on the SysML v2 metamodel and the SysML v2 profile.
The primary goal is to provide services for creating, reading, updating, deleting, and managing all types of SysML v2 model elements, independent of the specific SysML v2 modeling environment. The secondary goal is to provide those services for relationships between SysML v2 model elements and external elements like requirements in a requirements management tool, parts in a CAD model, or model elements in another SysML v2 model.
The RFP requires a PSM as a binding of the PIM to OSLC 3.0, and one or more commonly used technology platforms.
The SysML v2 API standard should also provide infrastructure services to get all available services and to get the handle of a service.
Besides the standardized services, it should be possible to provide extensions of the PIM and PSMs.
A standard API is useless if an implementation does not conform to the specification. Therefore, the SysML v2 API shall provide conformance criteria, evaluation methods, and test cases.
The next blog post covers the service requirements of the SysML API & Services RFP. Stay tuned!
Previous blog posts of this series:
- NextGenSysML Part 0 – Next Generation Modeling: SysML v2 and SysML API & Services – Introduction
- NextGenSysML Part 1 – Overview SysML v2 and SysML API & Services RFP’s
- NextGenSysML Part 2 – The General OMG Requirements
- NextGenSysML Part 3 – Language Architecture and Formalism Requirements
- NextGenSysML Part 4 – Cross-cutting Requirements
- NextGenSysML Part 5 – Properties, Values & Expressions Requirements
- NextGenSysML Part 6 – Structure Requirements
- NextGenSysML Part 7 – Interface Requirements
- NextGenSysML Part 8 – Behavior Requirements
- NextGenSysML Part 9 – Requirements Requirements
- NextGenSysML Part 10 – Verification Requirements
- NextGenSysML Part 11 – Analysis Requirements
- NextGenSysML Part 12 – Example Model, Model Libraries, and Conformance Requirements
- NextGenSysML Part 13 – SysML API & Services Overview
Planned future blogs posts:
above you mention “The RFP requires a PSM as a binding of the PIM to OSLC 3.0”.
I guess OSLC 3.0 refers to OSLC Core 3.0
Did you consider to provide a binding to OSLC Configuration Management ?
Correct. OSLC 3.0 menas, the PSM being compliant to the OSLC Core 3.0 specification.
The PSM for OSLC is intended to offer a Vocabulary, Service Provider, Ressource Shapes, etc. for reading, writing, querying SysML 2.0 models and it´s elements.
I guess there will be tools in future, which will implement additional OSLC specifications like ‘Tracked Ressource Set’ or ‘Change Management’. But this is nothing, the language specification and its´ API spec should care about. (The OSLC Configuration Management Spec – to my knowledge – is marked obsolete for OSLC 3.0.)