Components - factoring out common dependencies

[uml.modeller]

Hi,

I'm trying to model an application with a number of subsystem components. Many of the subsystem have dependencies upon a set of common services; for example, a CRUD service and a DeadLetterHandler service for erroneous JMS messages.

Modelling each subsystem's dependency on this set of common services results in a spaghetti of assembly connectors. It would be great if I could factor out these dependencies into an abstract generalisation of the concrete subsystems. However, I'm not sure how I would model the delegation to realising components in the concrete subsystems, or if in fact the semantics of component generalisation permit this kind of refactoring.

Has any adopted this kind of approach?

Regards,

jonathan

[Geert Bellekens]

Jonathan,

There are several approaches to this, depending on your specific situation, and the modelling requirements you have.
On approach I've seen is as follows:
- All your services are represented as operations on an interface.
- The services are logically grouped so one interface is implemented by one (low level) component, and all the operations on the interface are somewhat related.
- To greate a grouping of interfaces you define a new interface. (say groupA). This interface can then expose the operations from interfaces Interface1 and Interface2). The easy (bot not really correct) way of exposing the operations on the GroupA interface is let it realize interface1 and interface2. The correct way would be to copy the operations you are exposing.
- Then you can define a (abstract) component (ComponentA) which exposes this interface as a provided interface. If you have used to realization approach above then you already have a relation between the grouping interface (InterfaceA) and the low level interfaces (Interface1 and Interface2). If not then you will have to define that relation.
- Now you can add the dependencies from your higher level components to InterfaceA (as a "required interface")

But that is just one approach. I'm sure this is one of those cases where there are many "correct" answers and you'll have to find the one that suits best in your specific modelling environment.

Geert

[uml.modeller]

Thanks,

I'll have a detailed look at your suggestions.

Regards,

Jonathan