Book a Demo

Author Topic: Link Sequence Diagram messages to elements  (Read 2514 times)

Richard Zaat

  • EA Novice
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Link Sequence Diagram messages to elements
« on: September 03, 2009, 01:34:19 am »
Hi,

We use sequence diagrams to model Business Use Case Realizations. The sequence diagram shows how all systems interact to implement a Business process.
This gives us the interfaces that need to be supported by the systems joining in with the business process, defined as operations on the 'target' system.

Now I am looking for a way to connect any of these interfaces / messages / operations from the sequence diagram to packages and classes that will represent the true implementation of the interface. Any ideas how I can do this? Because I cannot find a way to connect for example a class to a operation (of the system).

Regards,
RichardZ

Makulik

  • EA User
  • **
  • Posts: 400
  • Karma: +0/-0
    • View Profile
Re: Link Sequence Diagram messages to elements
« Reply #1 on: September 03, 2009, 02:10:07 am »
Hi,

If you have interfaces containing your operations defined as elements, you can use a realization link from an implementation class to such an interface.
A direct link from a class to an externally defined operation is not available AFAIK.

HTH
Günther

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13523
  • Karma: +574/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Link Sequence Diagram messages to elements
« Reply #2 on: September 03, 2009, 06:29:10 pm »
Actually since 7.? you can link classes with operation or attributes.
Just draw a normal relationship (any), select the end that should be connected to an operation/attribute and select "Link to Element Feature"

But... that is not the way I would model this. Makulik was right in suggesting that you should use the "Realization" link between your classes and your "system interfaces".
I can imagine that one system interface contains far too many operations to be realized by one class. In that case you could think about creating different interfaces for different related groups of operations, and let your system interface realize those.
That would allow you to model messages to the single "system interface" while still having a remaining a decent grouping and size for the interfaces.
Those smaller interfaces can then be realized by your classes.
Another approach you could use (and combine with the previous) is to implement the facade pattern. You let one facade class realize the system interface (or the parts of it as described above) and in the sequence diagrams representing the behaviour of the realized interface operations you delegate to the appropriate internal classes.

Geert