OCSMP Model Builder Advanced cheat sheet
OCSMP Model Builder Advanced · Keep the key ideas within reach.
Concepts for adapting SysML (metamodeling, profiles, model libraries, viewpoints)
A SysML profile is a UML Profile that extends UML metaclasses via «stereotype» definitions; each stereotype may add properties (tagged values) and constrain the base metaclass with OCL.
Stereotype extension uses Extension associations with multiplicity 0..1 on the stereotype end and 1 on the metaclass end; isRequired=true forces the stereotype on every instance of the base metaclass.
A model library is a package stereotyped «modelLibrary»; it contains reusable model elements and is not instantiated in the user model - elements are referenced, not copied.
SysML viewpoints are defined by a «viewpoint» stereotype (a kind of Requirement) that specifies stakeholders, concerns, and allowed diagram types; a «view» conforms to exactly one viewpoint.
The SysML metamodel is defined as a UML profile (SysML 1.x) or as a MOF-based metamodel with profile-equivalent constructs; profile conformance is checked by validating stereotype application against metaclass constraints.
A «block» is a stereotype on UML Class; its properties include isEncapsulated, and it may own value properties, parts, ports, and operations. A «valueType» stereotypes DataType for quantities with units.
Profile application is transitive: if Profile A imports Profile B, applying A to a package also makes B's stereotypes available, but B is not automatically applied to the model.
Viewpoint conformance is a dependency from «view» to «viewpoint»; a view's diagram must use only the notation permitted by its viewpoint's concerns and stakeholder needs.
Approaches to integrating SysML with other modeling languages (UML, MARTE, UPDM, Modelica)
SysML is a UML profile; a SysML model is a valid UML model. Mapping SysML to UML: Block→Class, ValueType→DataType, ItemFlow→InformationFlow with ItemProperty, Allocate→Abstraction with «allocate».
MARTE extends UML for real-time/embedded systems; integration with SysML typically uses MARTE's «Resource» and «SchedulableResource» stereotypes alongside SysML blocks, with unit consistency via SysML ValueTypes and MARTE's NFP types.
UPDM (now UAF) is a UML/SysML profile for DoDAF/MODAF; integration means mapping SysML internal block diagrams to UPDM operational/resource views and using «Capability» from UPDM with SysML requirements.
Modelica is a non-causal equation-based language; SysML-to-Modelica integration maps blocks to Modelica models, value properties to Modelica variables with units, and constraints to equations. Ports map to Modelica connectors.
A common integration pattern is model transformation (QVT or ATL) from a SysML profile to a target metamodel; transformation rules must preserve units, types, and interface directionality.
Co-simulation integration uses an FMI/FMU wrapper: the SysML block's behavior is exported as an FMU, and its ports are mapped to FMU input/output variables for execution with other tools.
When integrating SysML and Simulink, use a profile that stereotypes blocks as «SimulinkBlock» and maps value properties to Simulink signals; algebraic loops must be resolved before transformation.
Semantic alignment across languages requires a mapping table: SysML ItemFlow ↔ Modelica connector flow, SysML «Allocate» ↔ UPDM «Implements», SysML «Requirement» ↔ UPDM «Capability».
Approaches to integrating SysML modeling tools with requirements management and configuration management tools
Requirements tool integration is normally via OSLC (Open Services for Lifecycle Collaboration) Requirements Management or ReqIF (Requirements Interchange Format); ReqIF is a file-based exchange, OSLC is REST-based linked data.
A SysML «Requirement» can be linked to an external requirement by a «satisfy» or «deriveRequisite» dependency whose supplier is a proxy element carrying the external ID; the ID must be stable across imports.
Round-trip synchronization requires an identity mapping (external ID ↔ model element GUID); without it, re-import creates duplicates.
Configuration management integration uses a model repository with baselines and change sets; SysML model elements are versioned as a whole, and cross-model references must be resolved by version-qualified IDs.
A common pattern is a CM tool (e.g., Git, SVN, or a model repository) storing the model as XMI; diffs are computed on XMI, and merge conflicts are resolved at the element level, not the diagram level.
For traceability, an «Allocate» or «satisfy» matrix is exported to the RM tool; the export must include source and target IDs and the model baseline identifier.
Access control and locking: CM tools provide pessimistic locking for model files, while RM tools provide role-based access; integration must define which system is authoritative for each attribute.
Validation of integration: after each sync, run a consistency check that every external requirement has at least one «satisfy» link and every «satisfy» link resolves to an existing external ID.
Methodology-related concepts and practices (assessment of model quality)
Model quality dimensions: syntactic (well-formedness against metamodel), semantic (consistency, completeness, correctness), and pragmatic (usefulness for stakeholders); assessment must state which dimension is measured.
Well-formedness rules come from the metamodel and profiles; OCL constraints and validation rules (e.g., no cyclic generalization, ports typed) are checked automatically by the tool.
Completeness metrics include requirement coverage (percentage of requirements with a «satisfy» link), interface completeness (every port has a type and direction), and allocation completeness (every logical element allocated to at least one physical element).
Consistency checks: no orphan elements, no unresolved proxies, no duplicate names in the same namespace, and every «deriveRequisite» chain terminates in a stakeholder requirement.
A model review checklist should include: stereotypes applied correctly, units on all value properties, and diagrams conforming to their viewpoints.
Methodology frameworks (e.g., OOSEM, Harmony, MagicGrid) prescribe model organization; quality assessment should verify that the model follows the chosen framework's package structure and artifact set.
Traceability quality is measured by link density and link correctness; a common target is 100% of requirements traced to design elements and 100% of design elements traced to requirements.
Model quality assessment should be repeatable: define metrics, thresholds, and a review process, and record results per baseline so trends can be compared.