Skip to content

Platform-specific model

A system-design model whose structure is expressed for a chosen programming, database, operating-system, or other implementation platform.

Version
v1 · 2026-09-28 · History
Domain-specific #
11356
Domain group
Applied Sciences & Engineering
Origin domain
Computer Science & Software Engineering
Subdomains
Software Architecture, Model Driven Architecture → Computer Science & Software Engineering
Aliases
PSM (model-driven architecture)

Core Idea

A platform-specific model is a design representation connected to a chosen technological environment. It takes a software or business system concept and expresses it using constructs of a database, programming language, operating system, file format, or another intended implementation platform. In model-driven architecture, that target environment is not an afterthought: it guides the model's design choices.

The frozen online-shop example makes the distinction concrete. A generic notion of user information becomes a particular relational representation using an Oracle SQL dialect. The model is not the running shop or simply a platform-independent sketch with a vendor name attached. Its platform detail supports implementation but also limits direct portability when the execution environment changes.

Structural Signature

Sig role-phrases:

  • Target system design — Supplies the business/software concepts that need platform-realizable expression. It is constitutive. Counterfactual: A list of database features with no modeled target system is not a PSM.
  • Chosen platform — Fixes the technological environment whose constructs constrain the model. It is constitutive. Counterfactual: Without a chosen platform the model remains platform-independent or underspecified.
  • Platform mapping — Expresses target concepts in platform-native structures such as tables or dialect-specific constructs. It is constitutive. Counterfactual: A platform name in a caption without changed design choices does not make a model platform-specific.
  • Implementation use — Makes the model usable to guide realization on the intended execution environment. It is purpose. Counterfactual: A diagram with no implementable relation to the platform fails the source's design-use point.
  • Portability boundary — Marks which decisions must change if the technological platform changes. It is boundary. Counterfactual: Treating Oracle-specific SQL as universally portable conceals the platform dependency.

What It Is Not

  • Not a platform-independent model. General concepts alone do not encode the chosen technology's constraints.
  • Not the deployed system. A PSM represents the design rather than being the running software.
  • Not a platform label. Naming Oracle or a language without mapped design choices is insufficient.
  • Not universally portable. Dialect and platform constructs may need remapping elsewhere.
  • Closest near-miss. The source's online-shop user concept becomes a PSM when represented in an Oracle-specific relational/SQL design; merely stating 'use a database' remains too generic.

Scope of Application

  • Database design. Expresses business concepts in a chosen relational/database dialect.
  • Model-driven architecture. Makes execution-platform assumptions explicit in design choices.
  • Implementation handoff. Communicates model structures that can guide realization.
  • Portability audit. Identifies commitments that must change when moving to another platform.

Clarity

Identify the target system, the named platform, and at least one model structure dictated by that platform. Include the Oracle-specific relational design in the source example; exclude a technology-neutral diagram with a vendor sticker. This is a model for implementation, not an assertion that the implementation already exists or is automatically portable.

Manages Complexity

A PSM compresses many implementation constraints into a structured design view, making the target-platform assumptions visible. That reduces ambiguity at handoff but increases coupling to the chosen language, database, or environment; portability must be tested at the construct level, not inferred from the model's name.

Abstract Reasoning

  1. Name the system concept being represented.
  2. Name the execution or storage platform that constrains design.
  3. Find a concrete mapping from concept to platform-native structure.
  4. Check how the model guides implementation without equating it with running code.
  5. Identify which commitments fail or require translation on a different platform.

Knowledge Transfer

The target-to-platform mapping method transfers across chosen databases, languages, and operating environments when each new platform's constructs are specified. An Oracle-oriented relation does not literally become a different database dialect's PSM without remapping; a purely conceptual model lacks the platform-specific differentia.

Examples

Canonical

An online-shop user concept is represented as database relations with decisions tied to a chosen Oracle SQL dialect. The source supplies this mapping example; it illustrates design specificity without claiming an exact production schema or storing real customer data.

Mapped back: Target system design → online-shop user information; Chosen platform → Oracle database dialect; Platform mapping → user concept as relational structures; Implementation use → guides database realization; Portability boundary → dialect choices may not carry unchanged.

Applied / In Practice

The Object Management Group's published MDA walkthrough maps a platform-independent UML application model into a Web Services platform-specific model through a selected UML profile and mapping. It is a documented design/teaching use of PSM artifacts, not a claim that every illustrated server was field-deployed or that naming a platform alone transforms the model.

Mapped back: Target system design → the walkthrough's UML PIM; Chosen platform → Web Services middleware; Platform mapping → UML profile and target-specific mapping; Implementation use → PSM guides generated target artifacts; Portability boundary → a different platform needs a different mapping.

Structural Tensions

T1 — Conceptual Portability versus Implementation Fit. A platform-neutral system idea travels broadly, whereas a PSM commits to constructs needed for a particular realization.

Diagnostic: Which design choice would change on another platform?

T2 — Vendor Detail versus Model Abstraction. The model must include enough platform detail to guide implementation without being the running system itself.

Diagnostic: Is this still a representation of design, or only code/configuration?

Structural–Framed Character

The approved DAG parent is Representation: a PSM maps a target system into a design medium under interpretation and fidelity limits. It adds chosen platform constructs so the design is implementable rather than technology-neutral.

Evaluative weight: Implementability is the purpose, not automatic correctness. Human-practice-bound: High, because architects select platform, dialect, and mappings. Institutional origin: Model-driven engineering supplies conventions; no specific vendor is universal. Vocabulary travels: Different databases or languages can host PSMs after remapping. Import versus recognize: Recognize a PSM by explicit target-to-platform mapping; calling a conceptual model platform-specific imports technology commitments it lacks.

Its character: A software-design representation with portable mapping logic and platform-constrained interpretation.

Structural Core vs. Domain Accent

Skeletal core. Map target concepts into a surrogate medium for a stated use.

Domain-bound accent. A chosen implementation platform supplies database, language, or environment constructs, and the use is implementation.

Why not prime. Representation is broader; without platform commitments this is a generic model, not a PSM.

This entry is a kind of Representation.

  • Strict parent — Representation. The PSM maps a target software/business system into a platform-native design medium under implementation fidelity and interpretation conventions; the chosen platform supplies its strict differentia.

  • Related — platform-independent model and deployed implementation. One omits the platform mapping, while the other is the realized system rather than its design representation.

Relationships to Other Abstractions

Local relationship map for Platform-specific modelParents 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.Platform-specificmodelDOMAINPrime abstraction: Representation — is a kind ofRepresentationPRIME

Current abstraction Platform-specific model Domain-specific

Parents (1) — more general patterns this builds on

  • Platform-specific model is a kind of Representation Prime

    A PSM maps a target system into a platform-constrained design medium for implementation.

Hierarchy path (1) — routes to 1 parentless root

Neighborhood in Abstraction Space

Platform-specific model sits in a crowded region of the domain-specific corpus (35th percentile for distinctiveness): several abstractions share nearly its structure, so a description that fits it tends to fit its neighbors too.

Family — Organizational Patterns & Management Concepts (29 abstractions)

Nearest neighbors

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

Not to Be Confused With

  • Platform-independent model. Tell: Does the design encode target-platform constructs?
  • Implementation. Tell: Is this a representation rather than running software?
  • Vendor label. Tell: Can a specific model choice be traced to the named platform?
  • Portable standard model. Tell: Would the same structures survive a platform change unchanged?

References

  • Frozen Wikipedia discovery revision: https://en.wikipedia.org/wiki/Platform-specific_model (revision 1277055987).
  • Supplemental OMG primary MDA walkthrough with a Web Services PSM: https://www.omg.org/mda/mda_files/developing_in_omg.htm
  • Preserved source candidate: https://www.google.com/books/edition/Software_Architecture/Xi-JoWzVF54C?hl=en&gbpv=1&dq=%22Platform-specific+model%22+-wikipedia&pg=PA76&printsec=frontcover

The frozen Wikipedia revision is discovery provenance. The retained source set was reviewed for identity, formal or operational relation, and scope. The encyclopedia's structural synthesis is bounded to those claims; a thin authority surface is recorded as a nonblocking source-strengthening repair rather than concealed.