UML – How to Design a UML Class Diagram for Two Subsystems

uml

Currently I am working on a project which has two sub system: a web application and a web API (consumed by android app) and both being developed as separate project since the API system need to deploy on different server but will access same database. After gathering requirements and producing Use cases, I have designed all the system functionalities as a single system (as a single use case diagram and I have not explicitly designed separate diagrams e.g. communication diagram, state diagram etc. for web application and API). So, my problem lies here. For instance, while producing the class diagram, I found the functions getProductDetails() (a function called from android/web api) and addNewProduct() (function called from web application) belongs to same class Product. In this case, how would I transform class diagram into coding considering the fact that function will implemented in two distinct sub-system?

Do I have to produce the same class in both system? In this case, addNewProduct() function for API system would be useless and vice versa.

Or do I have to design separate design for both system?

Any ideas on designing the class diagram would be very appreciated.
PS. I am newbie in system design, so I am eager to have any good guidance from you guys.

Best Answer

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 S1 compared to system S2, 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 S1, 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 *S1 and some methods in system S2 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.

Related Topic