Skip to content

Modelio-R-D/SafeTraffic_DSE_demo

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

5 Commits
 
 
 
 
 
 
 
 
 
 

Repository files navigation

SafeTraffic_DSE_demo

Model-repository for the SafeTraffic design-space exploration demo. The project is stored as a Modelio 5.4 workspace that relies on the ModelerModule 9.4.00 and ToscaDesigner 0.5.01 add-ons to capture a TOSCA-based topology describing Myrtus compute and software components.

Repository layout

  • project.conf — Modelio project descriptor (modules, fragments, audit preferences). Treat as generated.
  • data/fragments/SafeTraffic_DSE_demo/
    • model/ — One .exml per UML/TOSCA element (packages, node types, topology template, diagrams). Never rename or move these manually.
    • blobs/ — Binary payloads referenced by diagrams; always updated by Modelio.
    • .index/ — Lookup tables generated by Modelio. Leave untouched.
    • admin/ — Metamodel descriptors and access-control metadata regenerated by the tool.
  • data/backups/ — Module archives (.jmdac, .ramc). Useful if Modelio prompts for missing components.
  • data/localmodel/ — Local database cache. Do not edit, and avoid committing exploratory changes from here.
  • .github/copilot-instructions.md — Additional agent-facing notes that mirror the guidance below.

Tooling prerequisites

  1. Install Modelio 5.4 (matching minor version) on Windows.
  2. Ensure the following modules are available and activated inside the project:
    • ModelerModule 9.4.00
    • ToscaDesigner 0.5.01
  3. Keep the ToscaDesigner-provided ToscaLibrary 0.0.05 fragment in data/backups/modules/ so Modelio can resolve stereotypes.

Working in Modelio

  1. Launch Modelio and choose Open Workspacec:/Users/jcadavid/modelio/workspace.
  2. Open the SafeTraffic_DSE_demo project; verify the ToscaDesigner module is active (Modules view).
  3. Use the ToscaDesigner palette to manipulate TOSCA constructs. Modelio assigns GUIDs, stereotypes, property tables, and dependencies automatically—hand-editing .exml files is unsafe.
  4. After modeling:
    • Save all inside Modelio.
    • Close the IDE to flush updates to model/, .index/, and localmodel/ before running any Git commands.

Modeling conventions

  • Root package example.eu.myrtus (Standard.Package/8b2e3731-…) carries the ToscaModel stereotype and owns:
    • nodetypes package with every node type (Standard.Class, stereotype TNodeType). Example file: Standard.Class/95b62343-… for myrtus.dpe.compute.
    • TrafficApplication topology template (Standard.Class/50e090a8-…, stereotype TTopologyTemplate) that aggregates TGroup classes (compute_nodes, software_component_nodes, …) and concrete TNodeTemplate classes (FogComputeNode1, etc.).
  • Node type properties:
    • Represented as OwnedAttribute elements stereotyped PropertyDefinitionType and typed by primitives under Standard.DataType.
    • Each node type has a TypedPropertyTable using definition TEntityTypePropertyTable where namespace/description flags live.
  • Node templates:
    • Live under group classes and must keep their TNodeTemplate stereotype.
    • Concrete property values use OwnedAttribute elements stereotyped TPropertyDef, linked via DependsOnDependency named type back to the corresponding node-type attribute GUID.
    • The template-to-type relationship is a DependsOnDependency named nodeType pointing at the proper node type class.
  • Policies, requirements, and capabilities are modeled as nested classes under each template with stereotypes such as TRequirementType and TCapabilityType. Mirror the patterns already present in neighboring .exml files to avoid missing references.

Validation & exports

  • Model validation is disabled at startup (project.conf), so run Analyze ▸ Audit manually before committing.
  • ToscaDesigner offers dedicated validation for TOSCA entities; resolve any warnings/errors there first.
  • For delivering external artifacts, use ToscaDesigner’s export features (Service Template, XMI). Keep exported deliverables outside the repository unless they are part of the planned change.

Version-control workflow

  1. With Modelio closed, inspect changes via git status.
  2. Review diffs by searching for semantic fields (<ATT name="Name">, <ATT name="Value">, property-table Content) rather than GUID-based filenames.
  3. Stage only intentional edits from data/fragments/SafeTraffic_DSE_demo. Avoid staging data/localmodel/* unless you know why.
  4. Commit with a message describing the TOSCA element(s) changed, then push normally (git push origin <branch>).

Troubleshooting tips

  • If Modelio complains about missing fragments, restore them from data/backups/modules/ToscaDesigner/.
  • GUID churn happens when elements are deleted/recreated. Prefer editing existing elements to changing GUIDs, and keep changes small to simplify reviews.
  • When in doubt, consult .github/copilot-instructions.md for agent-focused notes or open the corresponding .exml file to inspect the precise stereotype/property structure before editing.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published