Home/ Questions/Q 567037
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T13:02:26+00:00

UML component diagrams are good at showing technical client-server-like inteface relationships between components, using

  • 0

UML component diagrams are good at showing technical client-server-like inteface relationships between components, using the “lollipop” notation or dependency arrows.

Is there a notation in component diagrams for showing in which direction information flows through interfaces on business process level? Like a client can connect to a server and

  • put/push information,
  • get/pull information or
  • the interface is used bidirectionally.

How can that be depicted in component diagrams?

UML activity diagrams allow for in-flow and out-flow pins, however ommitting the bidirectional case. Would it be sane to use the pin notation on component ports?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Sure can, a high level conceptual line was added to UML at some point. They are called information flows. The direction of the arrow makes sense to business users as well. The OMG spec covers this pretty well. For the push, pull, etc meta data I would use keywords or stereotypes to convey this. Interfaces, Classes, Data Types can all be referenced by the Information flow as what is traveling between the two classifiers (Components, Classes, etc). Many tools have implemented this construct because of it’s usefulness despite in being and auxiliary construct.

    Link to OMG spec and location: Section 17.2 on printed page 609. Superstructure, ie what you use (http://www.omg.org/cgi-bin/doc?formal/09-02-02)

    17.2 InformationFlows

    The InformationFlows package provides mechanisms for specifying the exchange of information between entities of a
    system at a high level of abstraction. Information flows describe circulation of information in a system in a general
    manner. They do not specify the nature of the information (type, initial value), nor the mechanisms by which this
    information is conveyed (message passing, signal, common data store, parameter of operation, etc.). They also do not
    specify sequences or any control conditions. It is intended that, while modeling in detail, representation and realization
    links will be able to specify which model element implements the specified information flow, and how the information
    will be conveyed.

    The contents of the InformationFlows package is shown in Figure 17.2. The InformationFlows package is one of the
    packages of the AuxiliaryConstructs package.

    • 0