| Both sides previous revision Previous revision Next revision | Previous revision |
| public:00-sip-ra:02-architectural-context:start [2026/09/12 18:33] – ↷ Page moved from dido:00-sip-ra:02-architectural-context:start to public:00-sip-ra:02-architectural-context:start nick_dido | public:00-sip-ra:02-architectural-context:start [2026/09/13 17:40] (current) – nick_dido |
|---|
| ====== 2 Architectural Context ====== | ====== 2 Architectural Context ====== |
| |
| [[dido:00-sip-ra:start|Return to Structured Information Processing Reference Architecture (SIP-RA) Request for Proposal]] | [[public:00-sip-ra:start|Go to Structured Information Processing Reference Architecture (SIP-RA) Request for Proposal]] |
| |
| [[public:99_annexes:annex-b-terms-and-definitions:m:mda|Model Driven Architecture (MDA)]] provides a set of guidelines for structuring specifications as [[public: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. | [[public:99_annexes:annex-b-terms-and-definitions:m:mda|Model Driven Architecture (MDA)]] provides a set of guidelines for structuring specifications as [[public: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 [[public:99_annexes:annex-b-terms-and-definitions:a:application|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 [[public:99_annexes:annex-b-terms-and-definitions:i:interoperability|interoperability]] and supports system evolution and deployment choices as platform technologies change. The three primary goals of MDA are [[public:99_annexes:annex-b-terms-and-definitions:p:portability|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. | A subsystem's portability depends on the subsystems it depends on. The collection of subsystems a given subsystem depends on is often loosely referred to as the [[public:99_annexes:annex-b-terms-and-definitions:p:platform|platform]] that supports it. Standardized interfaces, [[public:99_annexes:annex-b-terms-and-definitions:a:api|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: | MDA provides a pattern comprising a portable subsystem that uses one of multiple specific platform implementations. This pattern is repeatedly usable when specifying systems. The five important concepts related to this pattern are: |
| |
| ===== Model ===== | ===== Model ===== |
| |
| A [[public:99_annexes:annex-b-terms-and-definitions:m:model|model]] represents a selected function, [[public: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. | A [[public:99_annexes:annex-b-terms-and-definitions:m:model|model]] represents a selected function, [[public: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 [[public:99_annexes:annex-b-terms-and-definitions:s:semantic|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. | 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 ===== | ===== 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. | A [[public:99_annexes:annex-b-terms-and-definitions:p:platform|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) ===== | ===== Platform Independent Model (PIM) ===== |
| ===== Mapping ===== | ===== 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. | 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. Mapping expression forms include associations, [[public:99_annexes:annex-b-terms-and-definitions:c:constraint|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: | OMG adopts standard model specifications 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 ===== | ===== 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. | Examples include [[public:99_annexes:annex-b-terms-and-definitions:i:idl|Interface Definition Language (IDL)]] for interface specification [IDL], [[public:99_annexes:annex-b-terms-and-definitions:u:uml|Unified Modeling Language (UML)]] for model specification [UML], [[https://www.omg.org/bpmn/|Business Process Model and Notation (BPMN)]] for business-process specification [BPMN], and other specification languages. |
| |
| ===== Mappings ===== | ===== Mappings ===== |
| ===== Platforms ===== | ===== Platforms ===== |
| |
| Examples include [[https://www.omg.org/spec/CORBA/|CORBA]] [CORBA] and [[public:99_annexes:annex-b-terms-and-definitions:d:dds|DDS]] [DDS]. | Examples include [[https://www.omg.org/spec/CORBA/|Common Object Request Broker Architecture (CORBA)]] [CORBA] and [[public:99_annexes:annex-b-terms-and-definitions:d:dds|Data Distribution Service (DDS)]] [DDS]. |
| |
| ===== Protocols ===== | ===== Protocols ===== |
| Examples include GIOP/IIOP [CORBA], both the structure and the exchange protocol, and the DDS Interoperability Protocol [DDSI]. | Examples include GIOP/IIOP [CORBA], both the structure and the exchange protocol, and the DDS Interoperability Protocol [DDSI]. |
| |
| ===== Domain Specific Standards ===== | ===== 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. | Examples include the Model for Performance-Driven Government [MPG], the Single Nucleotide Polymorphisms specification [SNP], the TACSIT Controller Interface specification [TACSIT], and other [[public:99_annexes:annex-b-terms-and-definitions:d:domain|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]. | For an introduction to MDA, see [MDAa]. For details on MDA, see [MDAc]. For an example of MDA in practice, see [MDAb]. For general information on MDA, see [MDAd]. |
| |
| ---- | ---- |
| © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc. | © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc. |
| </WRAP> | </WRAP> |
| |