| Both sides previous revision Previous revision Next revision | Previous revision |
| public:00-sip-ra:02-architectural-context:start [2026/09/12 18:33] – removed - external edit (Unknown date) 127.0.0.1 | public:00-sip-ra:02-architectural-context:start [2026/09/13 17:40] (current) – nick_dido |
|---|
| | ====== 2 Architectural Context ====== |
| |
| | [[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 [[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. |
| | |
| | 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 when specifying systems. The five important concepts related to this pattern are: |
| | |
| | ===== 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 [[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. |
| | |
| | ===== Platform ===== |
| | |
| | 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) ===== |
| | |
| | A [[public: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 [[public: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. 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 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 ===== |
| | |
| | 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 ===== |
| | |
| | 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/|Common Object Request Broker Architecture (CORBA)]] [CORBA] and [[public:99_annexes:annex-b-terms-and-definitions:d:dds|Data Distribution Service (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 [[public:99_annexes:annex-b-terms-and-definitions:d:domain|Domain]]-specific standards. |
| | |
| | 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]. |
| | |
| | ---- |
| | |
| | <WRAP centeralign> |
| | © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc. |
| | </WRAP> |