Back to all threads

How to best describe dependencies between application interfaces

Post reply

Adrian  Dumitrescu
(1 posts)

03 Jun 2013, 12:34

Hi all,

What is a proper way to model dependencies between application interfaces in an interface model?
I am thinking of an interface that controls the operational state of a system (like IPowerSwitch or IConnectionControl) and another interface that provides the services. In the simplest case, IPowerSwitch would have an TurnOn() and a TurnOff() but you can easily imagine a more involved interface. The IProvidedServices may only be used after a successful IPowerSwitch.TurnOn().

What it comes down to is that the states of the two interfaces are "largely" orthogonal except for some dependencies. To describe all possible combinations quickly becomes unfeasible, so is there a more practical way to do it at this level? Or is there another way to tackle this? 

Thanks for any tips.



Peter van de  Velde
(12 posts)

04 Jun 2013, 14:21

Hi Adrian,

If there are indeed dependencies between multiple application interfaces you should make one interface model in ASD, in which you describe the events on each application interface individually and the semantics between all the events of all interfaces together (all interleaving) in the Sequence Based Specification.

The implementation (design model) wil then be based on one interface model taking into account all events on all interfaces.

If there are no dependencies between these application interfaces you should make a separate interface model for each interface. And for each interface model you can have a separate implementation (design model).

In your case you could have an implemented by and a implemented by

If the service can only be used if the operational state is ON, you will need to bind the OperationalState component to the Service component. The best way to do that depends on how the service interface looks like.

If it is just about switching one service on or off, you could bind the Service component as used component to the OperationalState component; when the OperationalState is going on it can call TurnOn() on the service interface. This is a straight forward but not a very flexible solution.

For smarter solutions you can use component injection or write your own factory component allowing you, for instance, to instantiate a service when the operational state is ON. This gives you an enormous flexibility in possible design solutions.

Hope this helps you moving forward.

Regards, Peter


Post reply