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.

  • 2
    UML was invented by the devil in order to trick well intentioned people into wasting hours of their time in a vain attempt to communicate clearly.
    – MetaFight
    Oct 11, 2015 at 9:24

3 Answers 3


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.

  • thank you very much!! for your great explanation. Now my all confusions are gone. I think, its a good idea of coloring the class that belongs to respective sub-system. In addition, using package is also great idea.
    – Ra Ka
    Oct 11, 2015 at 15:13

In a system-level design, drawing classes is too much detail. The system design should contain only the sub-systems and possibly the components that are present in the system and how they are connected.
In your case, the system design would describe the two sub-systems and that they only communicate through the shared database.

When designing the sub-systems, you describe the classes that each sub-system has and which methods each class has. With two sub-systems, you would also create two sub-system designs.

  • Thank you for your answer. BTW, do I have to create all the other designs (usecase, communication, sequence etc.) separately for each system or its just a class diagram to create separately? As I mentioned to my question, I have produces all the other diagrams as a single system.
    – Ra Ka
    Oct 11, 2015 at 15:20
  • 1
    You should make your design diagrams on the level where they make sense (high-level overview at system level, details at sub-system level) and as many as you need to get your ideas across. I am currently working on a sub-system where we have half a dozen class diagrams and a dozen sequence diagrams. Oct 11, 2015 at 17:18

I like SysML (a profile for UML) better than UML for doing this sort of "System of Systems" design. The block layout is a little more intuitive. Also, the SysML working group has put a lot of effort into creating nice modeling constructs for interfaces.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.