Bridge

Description

Separates the interface (seen by the client) from the implementation, where there can be more than one implementation.
More info

Profile

Profile download (Rational Rose model)

OCL Constraints

context Abstraction
inv: self.isRoot implies self.isAbstract

inv: self.isAbstract implies (self.specialization->size() > 0 and
self.specialization->forAll (c | c.child.oclIsKindOf (Abstraction)))

context Implementor
inv: self.isRoot implies self.isAbstract

inv: self.isAbstract implies (self.specialization->size() > 0 and
self.specialization->forAll (c | c.child.oclIsKindOf (Implementor)))

context aAbstractionImp
inv: self.aII.isNavigable and not self.aIA.isNavigable and
self.aIA.aggregation = AggregationKind::aggregate
	

Explanation of Profile

1. The abstraction has a unidirectional aggregate association with the implementor.
2. The abstraction hierarchy has an abstract base class with at least one subclass.
3. The implementor hierarchy has an abstract base class with at least one subclass.
4. Each abstraction has some operations that are visible to the client.
5. Each abstraction operation will be implemented using some operations defined in a concrete implementor class.

Correct Instance

Incorrect Instance

The StackHanoi class is not stereotyped with <<Abstraction>>. However, this error is not found because Constraint #2 of Abstraction, which gives this rule, only triggers if the Stack class is abstract, which it is not (thus, another violation). The StackImpl class is also not abstract. The last error is the association between Stack and StackImpl. Notice that the pop() operation in the Stack class has no stereotype. Our profile does not flag that as an error since there is no set rule to say that an abstraction operation must have a corresponding implementor operation and vice versa.

Tool Output