Are indirectly inherited methods supposed to be accessed from a class that does not directly realize the containing interfaces

I have the below component diagram where a component's interface SWC1_Interface is decomposed into multiple interfaces (only one shown here) that break down the functionality provided by the main component interface, just to group the APIs into logical groups. Class1 realizes the SWC1_Interface_SubGrouping.

Then I draw a sequence diagram and try to specify a message requested from the instance of Class1. In the dropdown I can see the api1() which is a method of Class1 and is expected there, but I can also see all the indirect inherited methods from the realization sequence in the component diagram.

My questions are:

1. Is my component diagram respecting the UML standard and what could I do to improve it?
2. Does it make sense to "decompose" interfaces like this?
3. Is EA's behaviour, in the way that it shows the indirectly inherited messages as options in the message, "normal" and sensible?
4. Is there a way to change this behaviour in EA, to block indirectly inherited operations from showing up as options for messages in a sequence diagram?

1. Respect of UML

From the point of vie of the syntax, it looks almost correct. But unfortunately, it doesn't mean what you think:

• If SWC1_Interface is an interface provided by the component, the notation would either be a lollipop or the interface realization arrow (component at the tail, interface at the head) instead of the association (which means the component is associated with a classifier implementing the interface)
• Very probably, the interface SWC1_Interface_subgrouping should not realise the interface SWC1_Interface, but inherit from it (plain line instead of dashed).
• Even more probably, the decomposition should be in the other direction. Indeed, if SWC1_Interface_subgrouping would inherit from SWC1_Interface, it would have all the features of SWC1_Interface and more. What you want is to say that in fact SWC1_Interface realises one or several other interfaces, thus adding up the features of each.

2. Does it make sense to decompose the interfaces

It can make sense. For example, you could imagine that a component provides the interface PrintableAndSortable that is a combination of two distinct interfaces Printable and Sortable.

However, the interface segregation principle suggests that in many cases, this might not be a good idea, from a design point of view.

3. Indirectly inherited messages

It is normal that the public feature of all the indirect parents are also features of the inheriting class: Suppose A inherits from B which inherits from C. The inheritance tells us that B is a C and A is a B and therefore also a C.

For the realisation it's less obvious, because the realisation theoretically only says that the class realising the interface should provide on its own the different properties and operations. However, it's common accepted to assume that the class will comply and therefore consider this properties and operations will also be available. ,

EA behaviour

I don't know, but I don't think so.