2 Architectural Context [Dido Solutions, Inc Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 2 Architectural Context ======

[[dido:00-sip-ra:start|Return to Structured Information Processing Reference Architecture (SIP-RA) Request for Proposal]]

[[dido:99_annexes:annex-b-terms-and-definitions:m:mda|Model Driven Architecture (MDA)]] provides a set of guidelines for structuring specifications as [[dido:99_annexes:annex-b-terms-and-definitions:m:model|models]] and mappings. The MDA initiative and the standards that support it allow the same model, specifying business-system or application functionality and behavior, to be realized on multiple platforms. MDA enables different applications to be integrated by explicitly relating their models. This facilitates integration and interoperability and supports system evolution and deployment choices as platform technologies change. The three primary goals of MDA are portability, interoperability, and reusability.

Portability of any subsystem is relative to the subsystems on which it depends. The collection of subsystems a given subsystem depends on is often loosely referred to as the platform that supports it. Standardized interfaces, application programming interfaces (APIs), and consistent usage patterns support portability and reusability across dependent subsystems.

MDA provides a pattern comprising a portable subsystem that uses one of multiple specific platform implementations. This pattern is repeatedly usable in the specification of systems. The five important concepts related to this pattern are:

===== Model =====

A [[dido:99_annexes:annex-b-terms-and-definitions:m:model|model]] represents a selected function, [[dido:99_annexes:annex-b-terms-and-definitions:s:structure|structure]], behavior, or meaning of an application or system for a defined purpose. A representation is formal when it is based on a language that has a well-defined form, meaning, or semantics, and possibly rules of analysis, inference, or proof for its constructs. The syntax may be graphical or textual. The semantics might be defined, more or less formally, in terms of things observed in the world being described, such as message sends, and replies, object states, and state changes, or by translating higher-level language constructs into other constructs with well-defined meanings.

The non-mandatory rules of inference specify which unstated properties can be deduced from the explicit statements in the model. In MDA, a representation that is not formal in this sense is not a model. Thus, a diagram with boxes, lines, and arrows that is not supported by definitions of the meanings of boxes, lines, and arrows is not a model. It is an informal diagram.

===== Platform =====

A platform is a set of subsystems or technologies that provide a coherent set of functionality through interfaces and specified usage patterns. A subsystem that depends on the platform uses its functionality without regard to how the platform implements it.

===== Platform Independent Model (PIM) =====

A [[dido:99_annexes:annex-b-terms-and-definitions:p:platform_independent_model|Platform Independent Model (PIM)]] is a model of a subsystem that contains no information specific to the platform or the technology used to realize it.

===== Platform Specific Model (PSM) =====

A [[dido:99_annexes:annex-b-terms-and-definitions:p:platform_specific_model|Platform Specific Model (PSM)]] is a model of a subsystem that includes information about the specific technology used in the realization of that subsystem on a specific platform. A PSM includes platform-specific elements that are necessary to realize the subsystem.

===== Mapping =====

A mapping is a specification of a mechanism for transforming the elements of a model conforming to a particular metamodel into elements of another model that conforms to another, possibly the same, metamodel. Expression forms for a mapping include associations, constraints, rules, templates with parameters assigned during the mapping, and other specified transformation forms.

OMG adopts standard specifications of models that exploit the MDA pattern to facilitate portability, interoperability, and reusability, either through ab initio development of standards or by reference to existing standards. Some examples of OMG adopted specifications are:

===== Languages =====

Examples include [[https://www.omg.org/spec/IDL/|IDL]] for interface specification [IDL], [[https://www.omg.org/spec/UML/|UML]] for model specification [UML], [[https://www.omg.org/bpmn/|BPMN]] for business-process specification [BPMN], and other specification languages.

===== Mappings =====

Examples include mapping of OMG IDL to specific implementation languages, CORBA PIM to implementation-language PSMs, UML Profile for EDOC (PIM) to CCM (CORBA PSM) and EJB (Java PSM), CORBA (PSM) to COM (PSM), and other model mappings.

===== Services =====

Examples include Naming Service [NS], Transaction Service [OTS], Security Service [SEC], Trading Object Service [TOS], and other OMG services.

===== Platforms =====

Examples include [[https://www.omg.org/spec/CORBA/|CORBA]] [CORBA] and [[dido:99_annexes:annex-b-terms-and-definitions:d:dds|DDS]] [DDS].

===== Protocols =====

Examples include GIOP/IIOP [CORBA], both the structure and the exchange protocol, and the DDS Interoperability Protocol [DDSI].

===== Domain Specific Standards =====

Examples include the Model for Performance-Driven Government [MPG], the Single Nucleotide Polymorphisms specification [SNP], the TACSIT Controller Interface specification [TACSIT], and other domain-specific standards.

For an introduction to MDA, see [MDAa]. For a discourse on the details of MDA, see [MDAc]. For an example of MDA's application, see [MDAb]. For general information on MDA, see [MDAd].

----

<WRAP centeralign>
© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.
</WRAP>