Book a Demo

Author Topic: show which class calls which operations on another  (Read 2743 times)

Paul Lotz

  • EA User
  • **
  • Posts: 248
  • Karma: +1/-0
    • View Profile
show which class calls which operations on another
« on: June 05, 2008, 10:54:24 am »
This conundrum keeps recurring in my design work.  Perhaps I don't understand interfaces and ports sufficiently.

Goal: Depict overall architecture of system indicating which classes (or components) interact with each other and, if so, how.

This sounds simple enough (and essential!), but I haven't found a UML-compliant method (or example) to do this effectively.  Here are some methods I have tried and some shortcomings (real or imagined) I see.

1) Draw dependency relationships between classes/components.
Good: This shows which classes relate to which others and in which direction.
Bad: The relationships do not show the details of the dependencies (which operations the one calls on the other, for example).  It is conceivably possible to add this information in pure text or as part of the link name but then this information is not tied to the model in any way.  This is still one of the better methods I have found.

2) Draw information flow relationships between classes/components.
Good: This shows which classes relate to which others and in which direction.  In addition EA allows the selection of types to indicate specific object flow.
Bad: Not all interactions involve object flow.  A signal/command may not have a parameter and therefore there is no object flow.  How does one represent this?  (I would argue operations are more fundamental here in any case.)

3) Sequence diagrams
Good: These are designed to show who calls what operations on whom.  They do exactly what I need on the small scale.
Bad: These are not appropriate to show the large-scale (and static) system architecture.

4) Add ports and interfaces to the classes/components and relationships between the interfaces.
Good: This is a good method in some respects.  We can indicate directional relationships.  The interface definitions can show the details.
Bad: At least in EA I don't see how to indicate which operations are implemented on the interface relationship.  Shouldn't it be possible to implement a subset of the operations?  Example: Suppose I have a device (e.g., an actuator) that has an operation to initialize and another to move to a position.  The initialize command may be implemented by a local UI and by a containing subsystem.  The move to position command may be implemented only by the local UI.  If I create a single device controller interface how do I indicate that the subsystem calls one operation and the UI can call either operation?  (One answer is to create two child interfaces that inherit from the top-level interface, and have each child interface inherit only the appropriate operation subset.  This works in principle but I suggest gets absurdly complex quite fast even for a relatively simple system and, moreover, it may be nontrivial to make changes later.)

I'm thinking method 1 may in fact be the most appropriate for my current task since I may not want to show all the relevant operations anyway at the top level, but it seems to me that there is a frequent need to show the details in a model-consistent view.

Is there a way to do this meaningfully in UML?

Paul
« Last Edit: June 05, 2008, 01:57:36 pm by pauljlotz »

Paul Lotz

  • EA User
  • **
  • Posts: 248
  • Karma: +1/-0
    • View Profile
Re: show which class calls which operations on ano
« Reply #1 on: June 05, 2008, 01:54:39 pm »
I realized I should clarify an issue with method 2.  A UML Signal element is a type and therefore is available to add to the Information Items Conveyed by the information flow.  I am, however, using operations to which I have added the stereotype 'signal' and these are not in the list, unfortunately (since EA doesn't actually interpret the stereotype, I presume).  I have adopted the latter method because of its use in UML elsewhere and for several quite essential reasons: it allows a more compact representation of signals, allows descendant interfaces to inherit signals/operations or for classes to inherit these signals/operations (kind of critical for modeling!), and allows representation of signals on interfaces more cleanly.