Skip to content

General-Purpose Modeling

Represent multiple kinds of system structure and behavior through a reusable modeling language whose metamodel is intentionally broader than any one application domain.

Version
v2 · 2026-09-06 · History
Domain-specific #
1920
Origin domain
computer science
Subdomain
model driven engineering
Aliases
GPM, General-purpose modelling, General-purpose systems modeling

Core Idea

General-purpose modeling uses a broadly reusable modeling language to represent several facets and many classes of systems instead of baking one application domain's concepts into the language. A general-purpose language supplies generic constructs—class, component, activity, state, relationship, constraint—and expects a modeler to configure, profile, or combine them for the subject at hand.

UML is explicitly standardized as a general-purpose visual modeling language for specifying and documenting systems.[1] EXPRESS provides a standardized information-modeling language used across product-data domains.[2]

Structural Signature

  • A target system or object with multiple relevant facets.
  • A general-purpose modeling language and normative metamodel.
  • Generic constructs not tied to one domain ontology.
  • Multiple diagram, view, or schema forms.
  • Syntax and semantics shared across applications.
  • Rules for well-formed models and cross-view consistency.
  • Tooling for authoring, exchange, validation, or transformation.
  • Profiles, stereotypes, libraries, or conventions for specialization.
  • Explicit modeling purpose and stakeholder viewpoint.
  • A tradeoff between reuse breadth and domain semantic precision.

What It Is Not

It is not modeling without a purpose, a universal language for every phenomenon, or any use of a general-purpose programming language. It is not a domain-specific modeling language whose primitives directly name one field's entities and rules. A general-purpose notation does not guarantee that independently created models are mutually interpretable.

Scope of Application

The practice appears in software and systems architecture, product-data exchange, enterprise modeling, business processes, and model-driven engineering. ISO/IEC/IEEE 42010 makes architecture description explicitly viewpoint- and concern-relative, preventing one general notation from being mistaken for one complete model.[3] Fowler contrasts general-purpose host languages with domain-specific languages optimized for narrower expressive tasks.[4]

Clarity

Name the modeling language and version, metamodel, viewpoints, intended analyses, semantic interpretation, conformance level, profiles, exchange format, and consistency obligations. State which target properties are deliberately omitted.

Manages Complexity

One shared language reduces the number of notations a team must integrate and lets tools reuse parsers, repositories, transformations, and interchange formats. The cost is semantic distance: generic constructs often require conventions or profiles before domain experts can read them reliably.

Abstract Reasoning

  1. Identify stakeholders, questions, and system boundary.
  2. Select a general-purpose language with adequate construct coverage.
  3. Choose viewpoints and model kinds for each concern.
  4. Bind target entities to generic metamodel elements.
  5. Add profiles or constraints only where semantics remain unambiguous.
  6. Maintain traceability and consistency across views.
  7. Run analyses supported by the declared semantics.
  8. Reassess whether repeated specialization warrants a domain-specific language.

Knowledge Transfer

The portable pattern is reuse a broad representational grammar across domains, then make each specialization and semantic loss explicit. It transfers to general-purpose data schemas. The proposed immediate parent is Representation.

Examples

A team can use UML class, sequence, state-machine, and deployment views for one system while using the same language family for a different sector. EXPRESS schemas can model different product-data domains through a common language and exchange infrastructure.

If nearly every generic element requires a sector-specific stereotype and custom validation, a domain-specific language may yield a clearer, safer model.

Structural Tensions

  • Cross-domain reuse versus domain fidelity.
  • Shared tooling versus semantic ambiguity.
  • Flexible profiles versus profile fragmentation.
  • Multiple views versus cross-view consistency.
  • Modeling breadth versus analyzability.

Structural–Framed Character

Broad grammar reuse and explicit specialization are structural. Metamodels, diagrams, profiles, model exchange, and model-driven toolchains are constitutive. The identity is domain-specific.

Structural Core vs. Domain Accent

The structural core is generic grammar -> multiple views -> domain binding -> consistency audit. The domain accent is software and systems modeling languages.

Representation is the proposed immediate parent. Abstraction, Standardization, Viewpoint, and Mapping are related primes. Specification Language and UML diagram types are domain-specific neighbors.

The prospective queue contains one strict edge to prime:representation. No live DAG mutation is authorized.

Relationships to Other Abstractions

Local relationship map for General-Purpose ModelingParents 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.General-PurposeModelingDOMAINPrime abstraction: Representation — is a kind ofRepresentationPRIME

Current abstraction General-Purpose Modeling Domain-specific

Parents (1) — more general patterns this builds on

  • General-Purpose Modeling is a kind of Representation Prime

    Representation is the proposed immediate parent.

Hierarchy path (1) — routes to 1 parentless root

Neighborhood in Abstraction Space

General-Purpose Modeling sits in a sparse region of the domain-specific corpus (93rd percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (1565 abstractions)

Nearest neighbors

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

Not to Be Confused With

  • General-purpose programming language.
  • Domain-specific modeling language.
  • Specification language in every use.
  • Model-driven engineering as the wider toolchain.
  • One diagram treated as the whole system.
  • A claim of domain-neutral semantics.

References

[1] Object Management Group, OMG Unified Modeling Language, Version 2.5.1, formal/2017-12-05 (2017). registry ↩

[2] ISO, ISO 10303-11:2004, Industrial Automation Systems and Integration—Product Data Representation and Exchange—Part 11: EXPRESS Language Reference Manual. registry ↩

[3] ISO/IEC/IEEE, 42010:2011, Systems and Software Engineering—Architecture Description. registry ↩

[4] Martin Fowler, Domain-Specific Languages (Addison-Wesley, 2010). registry ↩