How are OO interfaces treated in component diagrams?

user_6121044 0
Viewed 41

My component diagram is mostly components, ports, and interfaces. The interfaces have operations and attributes. They do not capture any class based OO at the moment. What's the right way of doing that?

My options as I see them is either:

  • Add the class constructors to the component interfaces, and let the type carry remaining details like class operations.
  • Duplicate class interfaces into the component interfaces, e.g. having the class object as first parameter.

From the two the former is least work obviously. But perhaps there is a better way I've overlooked.

component-diagram components uml interface
2 Answers

Notation

The easiest way to do this is to capture the interfaces in a separate class diagram, with only «interface» classifiers. The advantage is that these classifiers give a (hopefully short) name to an interface, and describe the attributes and operations that are needed, with all required details, including constructors (keep in mind that in UML constructors should be preceded with «Create»)

You can then show for the components in your component diagram the interfaces provided (lollipop) and required (socket) just referring to the named interfaces, without cluttering the diagram with lots of redundant interface specifications.

Design

When you refer to duplicating class interfaces at the component level, I understand that you mean to add attributes (parts?) and operations to the component.

Of course, components implementing the same implicit interface could in principle be interchangeable. However, this approach does not allow to have a clear understanding of the dependencies, and in particular use dependencies, that are practical to decouple components. In other words, your components would be hard-wired.

Adding class constructors at the component level seems cleaner in this regard, since your class constructor would reuse classes that are defined somewhere else. But if you're going into that direction, you could go one step further and consider using a factory class:

  • The factory class constructs objects of a given class or a given interface
  • Your component would be initialized or configured with such factory provided from outside. The factories could be interchanged to construct different kind of objects that meet the requirements. *. If you go that way, I come back to the notational topic: the lolipo/socket notation would then allow to highlight better the decoupling that this design would offer.
user_37234230

I didn't understand the options you describe. Maybe a diagram would help. Here is how I would do it: enter image description here

The specification component has two ports and is indirectly instantiated. For the realization component I select two classes that are realizing the component. Class1 has an operation that uses the service defined by interface I1. Class2 implements the service promised by I2. Since port p2 has a multiplicity of 16, the part typed by Class2 also has at least this multiplicity. The constructors (with the «create» stereotype), don't have parameters, so that the component can be constructed without any additional logic.

If you need additional logic, you can use directly instantiated components. They have constructors that could call the parametrized constructors of realizing classes and also create the wiring.

user_94302500
Related