Bridge
A Bridge is a layering dependency between Domains. One Domain makes the assumptions, and other Domains take those assumptions as requirements. [MB]
There are a few ideas associated with the Bridge concept. From an analysis perspective, a dependency is established in the context of a project such that a Domain playing the role of client requires the capabilities of a Domain playing the role of service. In fact, a Domain may play a different role on each Bridge, so the same Domain may be a client on one Bridge and a service on another.
The capabilities supplied by the service may be bound at any time such as compile, initialization or runtime. It is a common mistake to think only in terms of runtime binding.
A runtime binding might be implemented by remote procedure calls (assuming the two domains are implemented as separate tasks which is only one possible deployment). Other dynamic interactions are possible such as function calls, messages, events, etc. depending on the platform.
An initialization binding might involve the population and configuration of instance data in the service based on M0 (objects/links/attribute values) and M1 (classes, attributes, associations, etc.) from the client. During runtime, this data may be consulted without the need, or a minimal need, to interact with the client.
A compilation binding would be similar to initialization except that the population/configuration would result in the generation of header files and other code to implement the service. Again, the service would run without the need, or only a minimal need, to interact with the client.
To get any of these three scenarios to work, however, it will be necessary for the analyst/modeler to define mappings between elements of the client Domain and elements of the service Domain. Ideally, these mappings should be among metamodel elements. In practice, a mechanism for specifying these mappings is imperfectly provided and varies from one platform architecture to another, depending on the nature of both the application and platform. This mechanism usually consists of some combination of marking models and explicit bridging actions which are encoded directly in Executable UML action language. That is because a universal, platform independent metamodel mapping system is yet to be defined. This is a future, and extremely important, Shlaer-Mellor project. For now, only the overall dependency from one Domain to another is modeled without any exposure of how the Bridge mechanics are defined.
- Client domain + Service domain
No non-referential attributes.