UML connector Direction

Question

When modelling an architecture in UML component diagrams, how do you show various attributes of connectors simultaneously? Like

• business object information flow (A->B, B->A, A<->B)
• request/response direction
• synchronous/asynchronous behaviour

I am aware of other diagram types like sequence diagrams. However, having this information visible in component diagrams would have value.

What is possible beyond associations (merely showing that components are connected) or "lollipops" (request/response)?

Answer 1

You might want to use sequence diagrams instead of class (i.e, component) diagrams.

If you want to stick to a static diagram, you may also want to consider adding << sterotypes>> to various connectors, or even use association classes.

If possible, you can use connectors from sequence diagrams to connect classifiers in component diagrams (e.g., synchronous/asynchronous message-passing arrows).

Answer 2

For a start, don't try to explain these dynamic collaborations using the connectors on your class diagram.

The direction of the arrow connectors on the class diagram just specifies the who knows who. That means, the dependencies between classes. With those arrows you can communicate which classes need what other classes, but you don't have to explain there how are the dynamics of the collaboration between those clases. That's what UML dynamic diagrams are for.

Start with your class diagram, which is the static view of the system, and then add some dynamic diagrams.

As dynamic diagrams, together with sequence diagrams that are the most common, you can also use:

• Activity diagrams
• State diagrams
• Collaboration diagrams

Each has its own point of interest, and the main strategy is that you reuse some of the objects defined in your class diagram in order to describe specific scenarios.

For each one of the 'interesting' scenarios on your system, you should make one of these dynamic diagrams to describe what happens between the objects that you specified on your class diagram.

Typically, each use case will be described by one class diagram and one or more dynamic diagrams. All these design information together is called the use case realization, because they describe the design that will make your use case real when the code is built.

Check out Fowler's UML Distilled for a concise but excellent explanation of this design workflow using UML.

Answer 3

You can use the InformationFlow relationship, as described in section 17.2 of the UML Superstructure:

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.