Architecture

Architecture in TraceUnified is real model-based systems engineering, not a drawing pinned to a ticket. Block, internal-block, and parametric diagrams (and the wider SysML set) are views onto a single model that lives in the same database as your requirements, so model elements trace to the requirements they realize and the tests that verify them.

This section covers what MBSE means here, the diagram types and canvas you’ll work in, the elements and connections that make up the model, and how it all links back to requirements.

Real MBSE, in the same database as your requirements

Architecture in TraceUnified is model-based systems engineering, not a diagram pinned to a ticket. Block, internal-block, and parametric diagrams — and the wider SysML set — are views onto a single underlying model, and that model lives in the same database as your requirements. The consequence is direct: a model element traces to the requirement it realizes and the test that verifies it, so the architecture is part of the thread rather than a picture that describes it from the outside and drifts as the design evolves.

The canvas, elements, and connections

You work the model on a canvas where diagrams are drawn, arranged, and versioned like any other controlled record. Model elements and stereotypes are the building blocks — the blocks, parts, and typed elements that make up the system — and ports and interfaces define how those elements connect. Because these are model constructs rather than free-form shapes, the diagram carries real engineering meaning that the rest of the system can reason about.

Tracing the model to the specification

The reason MBSE belongs inside the ALM rather than in a separate modeling tool is the link back to requirements. When architecture elements trace to the requirements they realize, a change to the design surfaces against the specification it’s meant to satisfy, and coverage can account for realization as well as verification. That closed loop — spec to model to test, all in one record — is what model-based engineering is supposed to deliver and rarely does when the model lives in a different tool.

What’s in this section

• Model-based systems engineering — the model as the source of truth
• Diagram types — BDD, IBD, parametric, and the wider SysML set
• The canvas — drawing, arranging, and versioning the model
• Model elements & stereotypes — the building blocks
• Ports & interfaces — connecting elements
• Linking to requirements — tracing the model to the spec
• Model the system — a step-by-step walkthrough from first element to baseline