Model elements & stereotypes

The model is made of typed elements. Each kind of element means something specific in SysML, and stereotypes let you extend those kinds with the vocabulary of your own domain.

Element kinds

When you create an element you choose what kind it is. The model supports the standard SysML element kinds, including:

• Block — the fundamental building block: a system, subsystem, component, or part
• Value Type — a typed quantity, with units, used for properties and parameters
• Constraint — an engineering rule or equation, used on parametric diagrams
• Port — a connection point on a block (covered in Ports & interfaces)
• Actor — an external person or system that interacts with yours
• Activity and Action — behavior and the steps within it
• State — a condition a part can be in
• Signal and Enumeration — events and fixed sets of values
• Package — a container for organizing the model

Because every element is a real model object, it carries properties, can be shown on multiple diagrams, and participates in the thread.

Properties

Elements have properties beyond their name — typed values that capture the engineering detail that matters for your work. Custom properties let a block or value type hold exactly the attributes your process needs, keeping the model informative rather than merely pictorial.

Stereotypes

A stereotype extends a base element kind with domain-specific meaning. Where SysML gives you “Block,” your organization might define «Subsystem», «Sensor», or «ECU» as stereotypes of Block — adding the classification and any extra properties those concepts require. Applying a stereotype to an element tags it as that kind of thing and brings along whatever the stereotype defines.

Profiles

Stereotypes are organized into profiles — coherent sets of stereotypes for a domain or standard. A profile is the package of modeling vocabulary you work with, so a team modeling automotive systems and one modeling medical devices can each use the stereotypes that fit. Profiles and stereotypes are defined centrally as part of organization-level Model Configuration, covered in the Administration section, so the modeling language stays consistent across projects.