Model configuration

Model configuration governs the architecture modeling language available to your projects — the building blocks, the labels you put on them, and the diagrams you can draw. It’s the architecture counterpart to item types: where item types structure requirements and tests, model configuration structures the system model.

Setting the modeling language centrally is the architecture equivalent of governing item types: it keeps the vocabulary consistent everywhere models are built. If each project invented its own stereotypes and diagram conventions, models couldn’t be compared, reviewed, or reused across the organization, and a reviewer moving between projects would face a different dialect each time. Configuring metaclasses, profiles, and diagram types once means every modeler works in the same well-formed language, which is what makes the models trustworthy inputs to the traceability thread.

Metaclasses and stereotypes

Metaclasses are the fundamental kinds of model element — Block, Port, Activity, State, and so on. Stereotypes extend those base kinds with domain-specific meaning, so a generic Block can be marked as, say, a particular kind of component your discipline recognizes. Stereotypes are grouped into profiles, which let you enable a coherent set of extensions together rather than one at a time.

Diagram and interface types

You also configure the diagram types available — the SysML diagrams your projects can create — and the port and interface types that define how elements connect. Together these determine what a modeler can draw and how the pieces of a model relate.

Organization-level

Model configuration is set at the organization level, so the modeling language is consistent everywhere it’s used rather than diverging project by project. The user-facing side — actually building models with these elements — is covered in the Architecture section.