UML – Transitioning from Use Case to Class Diagram

An association links one class to another to indicate a relation between them. For example, you have an association between Customer and Order which (with no further information) indicates that:

1. A customer can have an order or maybe several orders,

2. An order can belong to a customer or maybe shared by several customers.

The diagram in your question gives an additional info: there is one and only one customer by order, and zero or more orders by customer, so the rules become:

1. A customer have zero or more orders,

2. An order belongs to one and one only customer.

While aggregation is used in the association between Order and OrderDetail, it's not used in the association between Customer and Order. This is done to indicate the life cycle dependency. If an instance of the Order is destroyed, all instances of OrderDetail inside it would be destroyed too; on the other hand, the instances of Order are independent of the life cycle of the Customer instance, thus no aggregation here.

This doesn't mean that an order can exist without a customer: the 1 ↔ 0..* association explicitly forbids the orders which have no customers. The difference between a 1 ↔ 0..* association and the aggregation really happens on life cycle level.

There are several possibilities to visualise the two subsystems.

Considerations beforehand

But the fact that it is difficult to model the two interwoven systems in UML may indicate that there some problems with your solution. Therefore, you should first ask yourself the question whether it really are two systems. There are several possible alternative answers:

• your two systems are a single system that has two interfaces^*;
• one of your two systems is built on top of the other;
• your two systems are in fact three systems with the two systems you recognised using common functionality of a third system;
• the two systems are a number of cooperating micro services (i.e. systems in their own right); or,
• it really are two (interwoven) systems.

A second question you can ask yourself is "if a class C has completely different responsibilities in system S₁ compared to system S₂, is it the same class or should it be two distinct classes^**.

To answer the question.

To visualise two interwoven systems you can use colour.

I've used greyed classes to indicate things like "existing classes in an other system that this system uses" and "possibilities for future extension that exist but that we will not implement at first". You could, for example, colour classes or methods blue for system S₁, yellow for system S, and green for shared between both systems. With some explanation human readers will understand it and can see the big picture and how the systems relate; automated tools on the other hand will not be able to understand the semantics you attach to colour.

Or, you can use UML packages

Each system can refer to the other sysem as a package. You can make a diagram for each system. Include the other system as a package in the current system's diagram. And draw classes from the other system, that are relevant for the current system, inside the other system's package.

UML tools do understand packages. The circular dependency may cause a problem. And when using packages you really have to decide to with system a class belongs. You cannot represent a class with some method in system *S₁ and some methods in system S₂ with UML packages.

^{[*]: Perhaps with one or both of the system's interfaces not providing access the full functionality of the system.}

^{[**]: Perhaps the two classes can share the same name but be in different packages (in UML terms) and in different namespaces in your implementation language.}