Skip to content

UML Profile

Package a coherent, additive customization of UML as stereotypes, extensions, properties, constraints, and supporting definitions that apply domain vocabulary to standard UML model elements without replacing their UML identity.

Version
v2 · 2026-09-06 · History
Domain-specific #
3023
Origin domain
software and systems modeling
Subdomain
uml extensibility
Aliases
Profile (UML)

Core Idea

A UML profile is UML's standardized mechanism for packaging a coherent, additive adaptation of an existing metamodel—most often the UML metamodel—for a domain, platform, or method. A profile establishes a namespace, references the metaclasses available for extension, and defines stereotypes whose Extensions attach new terminology, notation, typed properties, and constraints to selected metaclasses. Applying the profile to a model package makes its public stereotypes available for application to eligible UML model elements. The underlying element remains an instance of its UML metaclass: an Interface stereotyped as Home, for example, is still an Interface, now accompanied by an instance of the stereotype and its property values.[1]

The additive boundary is load-bearing. UML 2.5.1 calls a Profile a restricted form of metamodel and explicitly distinguishes it from first-class metamodel extensibility. A profile can add constraints but cannot remove constraints that already apply to UML; it can add terminology, notation, properties, semantic commitments, transformation information, and types usable within the profile's defined limits. It does not create an unconstrained new language whose constructs may discard the base metamodel's identity and rules. First-class metamodel construction and extension belong to MOF-based metamodeling, not to the profile mechanism itself.[1]

The primary unit inside a profile is the stereotype, but the two are not synonyms. A stereotype is a limited metaclass that extends one or more referenced metaclasses through UML Extension associations. It cannot be used by itself: an applied stereotype accompanies an instance of one of its extended metaclasses. A profile is the enclosing, reusable standards package that organizes stereotypes, references, supporting types, imports, constraints, and versioned identity. A stereotype can own typed Properties. Their definitions were traditionally called tag definitions, and the property values on stereotype applications were traditionally called tagged values; modern UML treats them as ordinary typed stereotype properties and their values, not as untyped arbitrary annotations.[1]

Definition and use are also separate. A Profile definition states what extensions exist. A ProfileApplication records that a Profile has been applied to a Package, thereby making applicable public stereotypes available in that package and its relevant namespace. Applying a profile does not rewrite the base model; UML describes ordinary application as defining a view over it. Required Extensions can make particular stereotype applications necessary for well-formedness after application. Strict application additionally activates availability filtering, hiding metaclasses not made accessible by the profile; ordinary application does not silently impose that filtering.[1]

UML Profile is domain-specific because every operative role—metaclass, stereotype, Extension, ProfileApplication, package namespace, stereotype property, OCL-style constraint, and XMI interchange—depends on the UML/MOF modeling architecture. The thinner portable move is formalization: codify a domain's terms and rules into an inspectable extension package. But remove UML's extension contract and the named abstraction dissolves into generic schema design, plug-in configuration, or language extension.

Structural Signature

Sig role-phrases:

  • the reference metamodel — the existing UML or compatible metamodel whose metaclasses supply the base identities that the customization must retain
  • the profile package and namespace — the coherent, identifiable container that groups extension declarations, imports, supporting types, and versioned vocabulary
  • the metaclass references — explicit references or a metamodel reference establishing which base metaclasses are available to the profile's stereotypes
  • the stereotype definitions — limited metaclasses that introduce domain, platform, or method terminology and can own typed properties, constraints, notation, and related definitions
  • the Extension associations — typed links from stereotypes to eligible base metaclasses, including optional or required application multiplicity
  • the stereotype properties and constraints — typed added data and well-formedness rules whose values and obligations become meaningful on applied stereotypes
  • the ProfileApplication — the package-level record that makes the profile's public stereotypes available for use, optionally with strict availability filtering
  • the profiled model elements — ordinary UML elements that retain their metaclass identity while acquiring applicable stereotype instances and property values
  • the conformance and interchange envelope — namespace/version identity, UML constraints, observable semantics, tool support, and XMI representation needed for portable use

The recognition test is conjunctive. There must be an existing reference metamodel; a UML Profile package must define or import stereotypes; the stereotypes must extend specified metaclasses through UML Extensions; and a profile application must govern their use on model elements. A package containing classes called “stereotypes” but lacking these semantics is merely a modeling convention. A tool palette of labels attached without a conforming profile definition may imitate the surface while failing the standard mechanism.

Three invariants separate the abstraction from nearby constructs. First, extension is anchored: every stereotype application is tied to an instance of an extended metaclass, so added vocabulary does not float free as a new object kind. Second, adaptation is non-subtractive with respect to the base contract: the profile may add restrictions and interpretation but does not cancel UML's existing constraints. Third, profile definition, profile application, and stereotype application remain distinct lifecycle events. Defining a stereotype does not apply the profile; applying a profile does not apply every optional stereotype; applying a stereotype does not replace the base model element.

Not every signature role must be graphically displayed. UML allows profile semantics to be serialized and exchanged independently of a particular diagram presentation, and tools may choose how to show applied stereotypes and property values. A profile diagram or package diagram can expose the definitions, but notation is evidence of the package, not its ontological identity.

What It Is Not

  • Not a new unconstrained metamodel or domain-specific language. A profile adapts a referenced metamodel through restricted extension. A new metamodel can define first-class constructs and relations outside UML's extension limits. The question is not whether both support a domain, but whether the domain constructs remain UML elements with additive stereotype applications.
  • Not a stereotype. A stereotype is one extension classifier. A profile can contain many stereotypes, their Extensions, constraints, types, imports, and namespace/version information. Treating the container as one stereotype erases reuse and application semantics.
  • Not a tagged value. A tagged value is the traditional name for the value of a typed stereotype property on a stereotype application. It is instance data governed by a definition, not the profile, property definition, or stereotype itself.[1]
  • Not a profile diagram. A diagram can show a profile package, stereotypes, metaclass references, Extensions, and applications. The profile remains a semantic package even when no such diagram is displayed, and a diagram-shaped picture does not by itself create conforming profile semantics.
  • Not a model library. A model library supplies reusable model elements such as classes, value types, units, or reference definitions. A profile supplies metamodel extensions. SysML v1 explicitly presents profiles and model libraries as complementary mechanisms: a user model applies a profile but imports a model library.[2]
  • Not an ordinary package or package import. Profile is a specialized Package with profile semantics, and ProfileApplication has a role different from PackageImport. An ordinary import makes package members visible; it does not establish the UML profile-application contract.
  • Not an untyped annotation vocabulary. Stereotype properties have UML types and multiplicities, and constraints can govern them. A free-form key-value tagging system may be useful, but it does not become a UML Profile merely by calling its keys tags.
  • Not a guarantee of tool portability. Conformance creates a shared semantic and interchange target, but practical portability still depends on the same profile version, namespace, machine-readable definition, supported profile features, and compatible interpretation of any added semantics.

Scope of Application

UML Profiles live within UML-based software and systems modeling and adjacent model-driven engineering practices. Their literal scope ends where there is no UML-compatible reference metamodel, stereotype/Extension semantics, and profile application.

Standardized domain modeling languages built on UML. SysML v1 reuses a subset of UML 2 and specifies extensions primarily through the UML profile mechanism; its stereotypes add systems-engineering concepts while its model libraries supply reusable elements. That is a large-scale, standards-governed use of the mechanism, not merely a local tool customization.[2]

Real-time and embedded-system modeling. MARTE 1.3 is an official UML Profile for modeling and analysis of real-time and embedded systems. It adds modeling support for non-functional properties, time, resources, allocation, and quantitative analysis while publishing normative profile and model-library artifacts.[3]

Platform and implementation profiles. A profile can adapt UML vocabulary and notation for a platform, add information used in model-to-model or model-to-code transformation, and restrict how UML constructs are used. The UML specification's own examples include platform terminology and transformation metadata as explicit profile purposes.[1]

Method and governance profiles. Modeling organizations can package method-specific stereotypes, properties, and constraints—for example, review status, ownership, assurance level, or modeling rules—when those additions apply consistently to declared UML metaclasses. A folder of naming guidelines is not enough; the rules must be encoded through the profile architecture.

Domain analysis and engineering profiles. Standardized profiles such as MARTE allow one UML toolchain to carry domain analysis annotations while preserving a common UML base. Domain semantics may be rich, but the mechanism remains lightweight relative to constructing a new metamodel.

Profile families and reuse. Profiles may import or reuse stereotypes from other profiles, define stereotype generalizations, and be applied together when their constraints and accessible-metaclass selections are compatible. This supports layered extension, but it also introduces namespace, version, and conflict-management obligations.[1]

Tool interchange and conformance. Profiles and applied stereotype instances can be represented for XMI exchange under the UML profile-to-MOF mapping. This makes profile identity, namespace, version, and machine-readable artifacts operational concerns rather than documentation trivia.[1]

The boundary case is SysML v2. SysML v1 belongs in this scope because its language architecture is a UML subset plus profile-based extensions. SysML v2 does not: its metamodel extends the Kernel Modeling Language (KerML) metamodel and has its own abstract and concrete syntax. The fact that both languages are named SysML and both support systems engineering does not make their extension architectures the same.[4]

Clarity

UML Profile clarifies modeling decisions by forcing four levels that diagrams often blur to be named separately.

First identify the language level. Is the team extending UML through a profile, designing a new metamodel, or merely creating reusable user-model elements? If a proposed domain concept must be a genuinely new modeling element with semantics that cannot remain a Class, Activity, Component, Dependency, or other UML metaclass instance, a profile may be the wrong mechanism. If the concept is a role or annotation carried by existing UML elements, a stereotype is plausible.

Second identify the definition level. Which profile owns the stereotype? Which metaclass does its Extension target? Which properties, types, constraints, and notational rules belong to the stereotype? A box marked «SafetyCritical» is not self-explanatory: the definition determines whether it may apply to a Component, Class, Activity, or several bases, and what its added values mean.

Third identify the application level. Has the model package applied the profile? Is the application strict or ordinary? Is a particular stereotype optional or required? These questions predict whether the model is well formed and which elements tools should make available. They also prevent “the profile is imported” from standing in for the distinct ProfileApplication relation.

Fourth identify the instance-data level. Which model element carries which applied stereotype, and what values have been supplied for its stereotype properties? This is where the colloquial phrase “tagged value” belongs. The value integrityLevel = SIL3 is neither the stereotype definition nor the profile; it is one value on one application.

A compact diagnostic is therefore: name the reference metamodel; point to the Profile definition and namespace; trace a stereotype through its Extension to a metaclass; list its typed properties and constraints; identify the applying package and application mode; and finally inspect an actual stereotype application. If any link is absent, the customization may still be useful, but the label UML Profile is not yet earned.

Manages Complexity

The profile mechanism manages the tension between domain expressiveness and ecosystem reuse. A team that models real-time analysis, systems requirements, enterprise architecture, or a platform directly in unextended UML must repeatedly explain how generic Classes, Activities, Components, and Dependencies should be interpreted. A team that builds a wholly new metamodel must supply editors, validation, interchange, transformation, training, and governance for a separate language. A UML Profile occupies the middle: it packages the domain delta while retaining a UML base that tools and practitioners already understand.

The package boundary compresses recurring decisions. Instead of each modeler inventing labels and keys, the profile states which metaclasses can carry each domain role, which properties are legal and typed, which constraints apply, what notation is recommended, and how the vocabulary is named and versioned. Profile application then activates that contract for a package. Reviewers can inspect the shared definition rather than reverse-engineer conventions from every diagram.

This compression also enables validation and automation. Once domain meaning is attached through named stereotypes and typed properties, transformations and analysis tools can select elements by metaclass and stereotype rather than by visual convention or naming heuristic. MARTE's profile architecture, for example, supports domain annotations intended for model analysis and transformations while preserving UML modeling elements.[3]

Profiles create their own complexity when allowed to sprawl. Too many stereotypes can fragment the vocabulary; overly broad Extensions can make a label applicable where it has no stable meaning; property duplication can create conflicting sources of truth; and multiple applied profiles can collide in constraints or names. Tool-specific features may outstrip the portable subset. The remedy is not “more profile” but stronger governance: minimal metaclass targets, typed definitions, explicit constraints, namespace/version discipline, machine-readable artifacts, compatibility tests, and a stated migration policy.

The intervention test is economic as well as semantic. Use a profile when domain additions are predominantly annotations, roles, restrictions, and interpretations over stable UML constructs and when UML tool reuse matters. Prefer a new metamodel when first-class language constructs, relations, or semantics cannot be expressed faithfully without distorting UML. Prefer a model library when reusable model elements—not metamodel extensions—are the thing being shared.

Abstract Reasoning

The signature licenses predictions about a proposed or existing customization.

Base-identity prediction. If a stereotype extends Component, every valid application must accompany a model element that is an instance of that metaclass or a permitted specialization under UML's rules. If users need the domain object to exist independently of any such element, the profile formulation is probably forcing a new language concept into an unsuitable base.

Additivity prediction. If a proposed constraint tries to license something UML already forbids, calling it a profile cannot make the underlying model conforming. A profile can narrow the allowed set by adding constraints; it cannot widen the set by removing UML's existing obligations. This predicts when a customization request must move to metamodel engineering rather than profile design.[1]

Application prediction. Defining a profile does not alter every UML model. The profile's stereotypes become usable in packages with the appropriate ProfileApplication. Removing an applied profile removes the profile-defined stereotype instances while leaving referenced-metamodel instances intact, so the base model has a meaningful UML projection even if domain annotations are lost.[1]

Typing prediction. If two tools agree only on the display text of a “tag” but not its stereotype owner, property type, multiplicity, or namespace, exchange is fragile. If they share the same versioned profile and machine-readable definition, a conformance test can inspect the stereotype application structurally rather than guess from text.

Conflict prediction. Applying multiple profiles can be coherent when they address complementary concerns. Conflicting constraints, overlapping unqualified stereotype names, incompatible strict availability selections, or inconsistent versions predict integration failure. Qualifying names and testing profile combinations are therefore part of deployment, not cleanup after deployment.

Evolution prediction. Changing a stereotype's property type, Extension base, constraint, or namespace can invalidate existing applications even when diagrams appear unchanged. Versioning must cover semantic compatibility and migration, not just the profile document's filename.

Mechanism-choice prediction. If a requirement is to share instances such as unit definitions or reusable components, a model library will likely fit better. If the requirement is to change which modeling concepts exist independently of UML, a new metamodel will likely fit better. If the requirement is to classify, annotate, restrict, or add domain interpretation to UML elements, a profile is the natural candidate.

Knowledge Transfer

Within UML-centered modeling, profile knowledge transfers literally across domains by role. A real-time profile, a systems-engineering profile, a platform profile, and an organization-specific governance profile can differ completely in vocabulary while sharing the same architecture: reference metamodel, Profile namespace, stereotypes, Extensions, properties, constraints, ProfileApplication, and profiled elements. A practitioner can transfer the construction and audit procedure without pretending that GaStep, Requirement, or a platform-specific stereotype has the same domain meaning elsewhere.

The most useful in-domain transfer is a checklist. Start with domain concepts; decide which are roles over existing UML elements and which require first-class types; choose the narrowest correct base metaclass for each stereotype; model typed properties and constraints; package them under a stable namespace; publish a machine-readable profile; apply it to controlled example models; and test interchange. That method transfers from SysML v1's systems-engineering vocabulary to MARTE's real-time and embedded-analysis vocabulary even though the actual stereotypes and analysis semantics do not.[2][3]

Transfer between tools is conditional rather than automatic. The same profile version, namespace, referenced metamodel version, supported features, and application mode must travel with the model. A screenshot or exported diagram cannot carry the full contract. The portable unit is the profile definition plus model applications and their interchange semantics.

Outside UML-based modeling, reuse becomes parent-level mechanism or analogy. Database schema extensions, annotation systems, plug-ins, language macros, and ontology modules may all “profile” or extend a base vocabulary, but they do not instantiate UML Profile unless they implement its metaclass/Stereotype/Extension/ProfileApplication semantics. What genuinely travels is prime:formalization: rendering a domain's vocabulary and rules into an explicit, checkable, reusable artifact. Generic extension, modularization, and constraint also illuminate pieces of the design, but exporting the UML term would conceal different lifecycle and conformance rules.

The SysML version boundary demonstrates the discipline. Knowledge about systems engineering transfers from SysML v1 to SysML v2, but the specific profile mechanism does not. SysML v2's KerML-based metamodel means the correct translation target is the new language architecture, not a search for one-to-one UML stereotype applications.[4]

Examples

Canonical

UML 2.5.1 illustrates a Profile containing a stereotype Home that extends the UML metaclass Interface and owns a magic : String property. The Extension licenses an instance of Home to accompany an Interface model element. After the containing profile is applied to a model package, an eligible Interface can display «Home» and a value for magic. The example is deliberately small but complete: it shows why the added value is not an untyped note and why the profiled element has not become a new non-UML class. Under the specification's MOF-equivalent account, the stereotype instance is associated with the underlying Interface element; removing the profile application removes the profile-defined instance while retaining the base model element.[1]

Mapped back: the reference metamodel supplies Interface; the profile package and namespace owns Home; the stereotype definition owns magic : String; the Extension association selects eligible Interface elements; the ProfileApplication enables use; the profiled model element retains Interface identity; and the conformance and interchange envelope governs representation of the application.

Applied / In Practice

The current OMG MARTE 1.3 specification uses the profile mechanism to add modeling and analysis capabilities for real-time and embedded systems. Its architecture groups subprofiles for concerns including non-functional properties, time, resources, allocation, and generic or specialized quantitative analysis. The NFP framework attaches typed qualitative or quantitative information and constraints to UML model elements; accompanying model-library definitions provide reusable value types and quantities. That separation is practical: MARTE stereotypes classify and annotate UML elements for domain analysis, while the library supplies reusable definitions. Normative PDF and machine-readable Profile XMI are published as versioned OMG artifacts, allowing tools to exchange more than a diagram's visible labels.[3]

Mapped back: UML is the reference metamodel; MARTE and its subprofiles are the profile package and namespace; its domain classifiers are stereotype definitions connected by Extensions; non-functional and analysis data use stereotype properties and constraints; applying MARTE activates those roles on profiled model elements; and the normative PDF, XMI profile, library, version, and tool conformance form the interchange envelope.

Structural Tensions

T1: Lightweight extension versus semantic ambition. Profiles gain leverage by retaining UML identities and tool infrastructure. A domain whose concepts fit poorly into available metaclasses can end up expressing a new language indirectly through stereotypes, constraints, and tool conventions. The mechanism stays “lightweight” while the interpretation becomes heavy and fragile. Diagnostic: Can every central domain concept be stated as an additive role or restriction over a stable UML base, or are stereotypes being used to simulate first-class constructs that need their own metamodel?

T2: Additive compatibility versus meaningful restriction. A profile may add constraints that make UML more precise for a domain, but every added restriction excludes models and can reduce composability with other profiles. Too few constraints yield decorative labels; too many create a narrow dialect that shares syntax with UML but little practical substitutability. Diagnostic: Which constraints are necessary to preserve domain meaning, and which merely encode one organization's preferred modeling style?

T3: Shared vocabulary versus local tailoring. Standardized stereotypes and typed properties make models legible across teams. Local extensions can capture necessary organizational or platform detail, yet each extension weakens the common semantic surface and complicates interchange. Diagnostic: Is a local stereotype expressing a genuinely new invariant, or renaming an existing standard concept because the local term feels more familiar?

T4: Multiple-profile modularity versus combination conflict. Applying several profiles lets concerns remain modular—systems engineering, analysis, safety, and governance can be packaged separately. Their constraints, namespaces, Extension targets, versions, and strict availability rules can nevertheless interact in ways no profile considered alone. Diagnostic: Has the actual profile combination been validated on representative models, including name qualification and constraint consistency, or has each profile only been tested in isolation?

T5: Rich tooling versus portable semantics. Tool vendors can make stereotype authoring, validation, notation, and code generation highly productive. Vendor-specific property types, scripts, displays, or execution hooks may exceed the shared standard and trap models in one environment. Diagnostic: Which behaviors survive exchange using the normative profile and XMI artifacts, and which depend on undocumented tool extensions?

T6: Stable contract versus evolving domain. A versioned profile gives projects a fixed vocabulary and validation target. Domain practice, the UML version, and analysis tools continue to change, so revising the profile can invalidate old stereotype applications or leave multiple incompatible versions in circulation. Diagnostic: Does the release define semantic compatibility, namespace/version policy, deprecation, and model migration, or only publish a new file?

T7: Visible notation versus hidden semantics. Stereotype guillemets, icons, and property compartments make domain roles visible, but diagrams can omit applied stereotypes or values, and viewers may treat visual similarity as semantic equivalence. Conversely, a semantically rich profile can overload a diagram with labels. Diagnostic: Can the model's profile meaning be recovered and validated from its structured representation even when a particular diagram suppresses the notation?

T8: Autonomy versus reduction. UML Profile has an autonomous recognition test inside software and systems modeling: Profile, Stereotype, Extension, ProfileApplication, and base-metaclass preservation jointly produce diagnostics that generic formalization does not. Yet its cross-domain reach belongs to the parent mechanism of codifying a domain vocabulary and rules, not to the UML-specific terms. Diagnostic: Do UML metaclasses, stereotype applications, profile namespaces, and UML conformance remain load-bearing? If yes, retain the domain-specific node; if they disappear, reduce the case to formalization or another applicable prime rather than exporting “UML Profile” metaphorically.

Structural–Framed Character

UML Profile is mixed-structural. Its evaluative weight is neutral: a profile can be coherent or incoherent, portable or tool-locked, but the mechanism itself does not carry praise or blame. Its structural signature is unusually crisp for a domain-specific abstraction because the OMG metamodel defines Profile, Stereotype, Extension, and ProfileApplication as explicit roles with machine-readable semantics.

It is nevertheless human-practice-bound and institutionally framed. UML, MOF, XMI, their versioned specifications, and profile conformance exist because standards bodies, tool vendors, and modeling communities maintain them. The structure does not occur observer-free in physical or biological systems. The vocabulary travels literally across software and systems modeling practices that share UML, but not beyond that engineered standards family.

On the vocabulary criterion, Profile, Stereotype, Extension, metaclassReference, and ProfileApplication are technical terms pinned to UML. On import versus recognition, a modeler can recognize the same mechanism in SysML v1, MARTE, and a local governance profile without analogy because the same metamodel roles operate. Calling a browser plug-in or a user preference set a “profile” imports a homonym rather than recognizing the UML structure.

The portable skeleton is prime:formalization: domain vocabulary and rules are made explicit, typed, checkable, reusable, and maintainable. That skeleton explains why profile construction exposes ambiguity and creates versioning costs. It does not eliminate the named child, because it lacks the reference-metamodel, stereotype-application, and base-identity obligations needed to diagnose a UML customization.

Its character: a formally specified and mechanically recognizable standards mechanism within UML-based modeling, with strong internal structure but a vocabulary and conformance regime inseparable from its engineered institutional substrate.

Structural Core vs. Domain Accent

What is skeletal. A community begins with a stable base representation, identifies a domain delta, codifies that delta as named types, properties, and restrictions, and activates the package in selected contexts while preserving the base. The transferable reasoning is that explicit extension packages reduce repeated interpretation, enable validation, and expose hidden assumptions, but also create maintenance and compatibility costs. This is principally a formalization pattern, with supporting ideas from representation, constraint, and modular extension.

What is domain-bound. The defining machinery is entirely UML-specific: MOF-aligned metaclasses; Profile as a restricted metamodel and specialized Package; Stereotype as a limited metaclass; Extension and ExtensionEnd; metaclassReference and metamodelReference; ProfileApplication and its strict mode; stereotype properties and traditionally named tagged values; guillemet notation; and profile-to-MOF/XMI interchange. Remove those roles and a coherent extension package may remain, but it is no longer a UML Profile. The sharpest test is whether an added domain role must accompany an instance of an eligible UML metaclass and whether removing the profile application leaves that base instance intact.

Why this does not clear the prime bar. The mechanism recurs across systems engineering, real-time analysis, platforms, modeling methods, and organizational UML governance, but these are subdomains of an interconnected modeling ecosystem using the same standard. Outside it, the word profile has unrelated meanings, and similar schema-extension mechanisms use different type, lifecycle, and conformance rules. Transfer to database schemas, ontology modules, annotation systems, or programming-language extensions requires translation and loses the stereotype/ProfileApplication contract. The prime-level reach therefore belongs to formalization and representation; the named entry's autonomous value is the UML-specific diagnostic closure.

This is not a mere bundle of formalization + constraint + package. Those primes do not predict that stereotypes extend metaclasses through associations rather than replace them, that profile application is distinct from definition, that tagged values are typed stereotype-property values, that strict application filters available metaclasses, or that base elements survive removal of profile-defined instances. Those emergent obligations justify a separate domain-specific node.

Presupposes prime:formalization. A UML Profile exists as the explicit result of deliberately rendering a domain's modeling vocabulary into a typed, rule-governed artifact that can be applied, checked, exchanged, and versioned. This is the most coherent direct parent relation, but it is compositional rather than taxonomic: the live Formalization prime is the process of deliberate codification, whereas a UML Profile is the domain-specific mechanism and artifact produced through that process. A prospective composition / presupposes / strict edge matches the live DAG's treatment of formal artifacts without falsely calling every formalization a profile or every profile merely a process.

Related to prime:representation, but no direct edge is needed. A profile presupposes UML as a representational medium and changes which domain features the model can carry. The live Formalization node already points upward to Representation, so adding the same parent directly would be redundant rather than minimal.

Related to prime:constraint, but does not require it as a direct parent. Profiles often add constraints, and constraints are central to meaningful domain conformance. UML nevertheless permits a profile whose main contribution is stereotypes, notation, and properties. Constraint is an optional profile member and explanatory neighbor, not the genus of Profile.

Declines prime:schema as a parent. The live catalog node is specifically a generalized cognitive structure with slots and defaults, not generic machine-readable schema. Lexical similarity does not create a safe genus relation.

Declines prime:specialization. The live node concerns functional narrowing and division of labor among interdependent components, not the model-theoretic “more specific than” relation. Even in UML terms, Stereotype Extension is an Association rather than generalization/specialization.[1]

Declines prime:inheritance. Stereotypes may generalize other stereotypes and thereby inherit properties, but this is an optional technique inside a profile. The constitutive stereotype-to-metaclass relation is Extension, not inheritance, and a profile with no stereotype hierarchy remains a profile.

Relationships to Other Abstractions

Local relationship map for UML ProfileParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.UML ProfileDOMAINPrime abstraction: Formalization — presupposesFormalizationPRIME

Current abstraction UML Profile Domain-specific

Parents (1) — more general patterns this builds on

  • UML Profile presupposes Formalization Prime

    Presupposes prime:formalization. A UML Profile exists as the explicit result of deliberately rendering a domain's modeling vocabulary into a typed, rule-governed artifact that can be applied, checked, exchanged, and versioned.

Hierarchy paths (2) — routes to 2 parentless roots

Neighborhood in Abstraction Space

UML Profile sits in a sparse region of the domain-specific corpus (82nd percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Document Models, Mapping & Maintenance (20 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-09-08

Not to Be Confused With

  • UML metamodel. The metamodel defines UML's first-class modeling elements and relations. A profile references and restrictively extends those metaclasses. Tell: can the construct exist as a new metaclass independent of a stereotype application, or must it accompany an existing UML element?
  • A new domain-specific language or metamodel. A new language may define syntax and semantics unconstrained by UML's profile rules. Tell: does removal of the extension leave a valid base UML element, or was the domain construct first-class in a separate metamodel?
  • Stereotype. A stereotype is one limited metaclass that extends eligible bases. A profile packages a coherent namespace of stereotypes and supporting definitions. Tell: is the item applied to a model element, or applied to a package so that many stereotype definitions become available?
  • Tagged value or stereotype property value. This is typed data on one stereotype application, not the extension vocabulary itself. Tell: are you looking at the property definition, its value on a profiled element, or the profile that owns the stereotype?
  • Profile diagram. The diagram is a notation for showing definitions and extensions. Tell: would the semantic profile still exist and be exchangeable if this view were omitted?
  • Model library. A model library offers reusable model elements and types; it is imported and its elements are used or specialized. A profile extends metaclasses and is applied. Tell: does the client import reusable model instances/types, or apply metamodel extension definitions?
  • Ordinary UML package. Package is the general namespace/container. Profile specializes Package and participates in ProfileApplication semantics. Tell: does the package merely organize/import elements, or does it define a profile whose stereotypes can be enabled on a model package?
  • ProfileApplication. This is the relation recording use of a Profile by a Package, not the Profile definition. Tell: is the artifact defining extensions or recording that a particular model package has made them available?
  • UML Extension. Extension is the association connecting a stereotype to a metaclass. Tell: is the object one typed link inside a profile, or the whole reusable customization package?
  • SysML v1 and SysML v2 as one extension architecture. SysML v1 is UML-based and uses the profile mechanism; SysML v2's metamodel extends KerML. Tell: is the language defined through UML stereotype applications or through the SysML/KerML v2 metamodel and syntax?
  • User profile, configuration profile, or plug-in. These homonyms package preferences, identity data, or executable extensions but lack UML metaclass/Stereotype/ProfileApplication semantics. Tell: can you identify the referenced metamodel, stereotype Extensions, and applying UML package?

References

[1] Object Management Group. OMG Unified Modeling Language (UML), Version 2.5.1, especially Clause 12.3, “Profiles.” Normative definition of Profile, Stereotype, Extension, ProfileApplication, strict application, stereotype properties/tagged values, additivity limits, notation, and profile-to-MOF/XMI semantics. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l

[2] Object Management Group. OMG Systems Modeling Language, Version 1.7, especially Clauses 4 and 17. Defines SysML v1 as reuse plus extension of UML, describes the UML profile mechanism as primary, and distinguishes profile application from model-library import. registry ↩a ↩b ↩c

[3] Object Management Group. UML Profile for MARTE: Modeling and Analysis of Real-Time Embedded Systems, Version 1.3, with official version and machine-readable artifact index. Normative current example of a substantial UML Profile and accompanying model libraries for real-time and embedded-system modeling and analysis. registry ↩a ↩b ↩c ↩d

[4] Object Management Group. Systems Modeling Language, Version 2.0, Part 1: Language, especially Clause 8. Specifies a SysML metamodel that extends the KerML metamodel, establishing the architectural boundary from profile-based SysML v1. registry ↩a ↩b