Skip to content

MODRISS DSML reference

This is the complete modeler-facing reference for MODRISS's three serverless domain-specific modeling languages. It explains the abstract syntax declared in Emfatic, the role of every declared attribute, accepted value shapes and examples, containment/reference relationships, and the way each level participates in refinement and generation.

The reference is intentionally split into module pages. Use the page for the concern you are modeling, then follow the links in its relationship tables to understand how the element connects to the rest of the model.

The three modeling levels

Level Main question What belongs here Reference
CIM What problem are we solving and what does it mean to the business? Requirements, stakeholders, capabilities, domain language, commands, queries, events, processes, policies, decisions, privacy, security, and compliance CIM DSML
PIM What provider-independent serverless architecture realizes that intent? Services, functions, APIs, contracts, data stores, channels, workflows, policies, identity, configuration, and external adapters PIM DSML
AWS PSM How is that architecture deployed and operated on AWS? SAM stacks, CloudFormation properties, Lambda, API Gateway, EventBridge, SQS/SNS, DynamoDB, S3, Cognito, IAM, KMS, Step Functions, and CloudWatch AWS PSM 
flowchart LR
  CIM["CIM\nBusiness meaning"] -->|ETL refinement| PIM["PIM\nProvider-independent architecture"]
  PIM -->|ETL refinement| PSM["AWS PSM\nDeployable AWS design"]
  PSM -->|EGX/EGL generation| ART["AWS/SAM artifacts\ncode, infrastructure, contracts, tests"]

Start here

How to read an element page

Each class section contains two tables. Declared attributes lists every attribute written directly on that class. The type and multiplicity come from the Emfatic declaration; enum-typed attributes list their complete controlled vocabulary, while primitive and string attributes include a valid shape and representative example. Relationships lists every val containment and ref reference, including multiplicity, opposite role where declared, and whether the relationship is derived or read-only.

Inherited attributes are not copied into every class table because that would obscure the class-specific vocabulary and make the reference difficult to maintain. A class section names all direct supertypes and links to the shared-kernel page; the inherited fields remain part of that class's effective Ecore API.

Source-of-truth boundaries

The reference is derived from the .emf files under mde/metamodels/. The combined .ecore files are the compiled abstract syntax. EVL files add semantic constraints and readiness rules, ETL files refine one model level into the next, and EGX/EGL files generate implementation artifacts. A value being syntactically accepted by the metamodel does not by itself mean it will pass EVL or produce a deployable artifact.

For chatbot assistant apply, repair, and commit paths, generated model output is gated by structural Ecore/EMF conformance through ModelService.validateStructural(...). EVL semantic validation remains part of explicit user/model validation workflows outside that assistant apply boundary.

Coverage

The reference covers the current repository definitions: 56 CIM classes, 110 PIM classes, 214 AWS PSM classes, 76 shared-kernel attributes, and the declared attributes and relationships in every module. Regenerate the pages after a metamodel change with scripts/generate-dsml-reference.py; review the resulting patch together with the .emf change.

Additional resources