Book a Demo

Author Topic: Is a dependency arrow drawn from a port to an <<interface>> legal UML?  (Read 4321 times)

mse

  • EA User
  • **
  • Posts: 308
  • Karma: +1/-0
    • View Profile
Take a look at page 40/58, figure 2.20 of the following document https://www.autosar.org/fileadmin/user_upload/standards/classic/21-11/AUTOSAR_TR_BSWUMLModelModelingGuide.pdf. There is a component (module) with a port (providing port) that has a dependency arrow with the stereotype <<abswRequires>> connected to an interface ClientServerInterface.

According to the guidelines below the diagram, the following is said about that dependency arrow:

Quote
[TR_BSWMG_00101] MoS Port The port interface, that the port implements, shall be
modeled as a dependency of stereotype «abswRequires» to a ClientServerInterface,
a SenderReceiverInterface or a ModeSwitchInterface.

My question here is, what is that depenency arrow saying in UML? Why not use a realization arrow? Is that even legal UML?
« Last Edit: August 10, 2022, 06:54:26 pm by mse »

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +397/-301
  • I'm no guru at all
    • View Profile
Re: Is a dependency arrow drawn from a port to an <<interface>> legal UML?
« Reply #1 on: August 10, 2022, 07:12:35 pm »
A dependency is the weakest relation in UML. And you can draw it between anything that "might be related". A realization in constrast makes sense only for classes realizing an interface, where class can also be a port.

q.

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8110
  • Karma: +119/-20
    • View Profile
Re: Is a dependency arrow drawn from a port to an <<interface>> legal UML?
« Reply #2 on: August 15, 2022, 08:55:47 am »
Why not use a realization arrow? Is that even legal UML?
Unfortunately, it's unlikely that the authors of the specification you are reading have provided the rationale for why they have specified particular metaclasses.

A realization in constrast makes sense only for classes realizing an interface, where class can also be a port.
What you are describing there is an InterfaceRealization. Which is a specialized version of Realization.

Quote
7.8.14.1 Description
Realization is a specialized Abstraction relationship between two sets of model Elements, one representing a specification (the supplier) and the other represents an implementation of the latter (the client). Realization can be used to model stepwise refinement, optimizations, transformations, templates, model synthesis, framework composition, etc.
The Realization metaclass describes that one element is the implementation of another, but it doesn't specify the mechanism involved.