Book a Demo

Author Topic: Component Diagrams weak in uses modelling?  (Read 2900 times)

angel-o-sphere

  • EA User
  • **
  • Posts: 112
  • Karma: +0/-0
    • View Profile
Component Diagrams weak in uses modelling?
« on: August 22, 2006, 06:02:05 am »
I'm trying to model with components the following:

a) I create a component, e.g. ContactAdaptor (it should transform external contacts in a way that my system can use them)
b) I add an interface to that component, with a realize relation: ContactAdaptorIF, indicating that the component ContactAdaptor is implementng this interface
c) now I create an ContactManager component.

I'm unable to link with a use relation from ContactManager to ContactAdaptorIF. (I can use a dependency with <<use>> ofc)

I only can draw either a "Assembly" or an "Expose Interface", both are not what I want!!!

Do I do something wrong or is that "style" not supported?

Regards,

angel'o'sphere

P.S. I can post an image somewhere if you want

sargasso

  • EA Practitioner
  • ***
  • Posts: 1406
  • Karma: +1/-2
  • 10 COMFROM 30; 20 HALT; 30 ONSUB(50,90,10)
    • View Profile
Re: Component Diagrams weak in uses modelling?
« Reply #1 on: August 22, 2006, 06:46:13 am »
Hi  angel'o'sphere

I think maybe you are trying to get "too much" out of a component diagram.

IMO they are better suited to a higher level of modelling than you are trying to get.  THink about it this way.  You have bunch of components that you can build your system out of.  Some of them are interchangeable - as long as they expose the same interfaces.  For example, you may have YourContactManager, MyContactManager or even TheirContactManager.  Each of these could be employed in the solution as long as each provides the same services exposed to the client components through interfaces with the same characteristics.  This is one view of all a component model provides.

A second view is that certain components offer services to many clients via certain exposed interfaces.  For example, a component X might offer a set of common services through a public interface and another set through a privileged interface (say one unathenticated and another authenticated).

Having decided on a design that includes a component that provides the interfaces that the rest of your system needs, you can then start drilling down and desinging the interior of that component (if necessary).  But a component model involving the rest of the system is not a place for that.

So the way I see that they are intended to be used means that assemblies and exposed interfaces are sufficient and exactly sufficient for the task.  The exact composition of a components internals and the formal names of its interfaces is a matter for a composite structure diagram.

However, see my and Paolo's other discussions on the exactitudes of component linkages for further opinions.

hth
bruce
"It is not so expressed, but what of that?
'Twere good you do so much for charity."

Oh I forgot, we aren't doing him are we.