Many Architecture Definition Languages have been created that can be used to formally define the architecture of a system. For some, however, getting started in a good way while strictly following a modeling language is a bigger challenge than expected for those with little or no experience with modeling. There are many reasons for this, ranging from typical real-world time and budget pressures to a lack of perceived benefit from creating a formal description of a system that isn’t necessarily reflective of, or connected to, the source code.
Known notations like UML, SysML or ArchiMate present a similar challenge. They are powerful and fulfill all relevant aspects of Software, Systems or IT Infrastructure, but teams often don't know these notations well enough and, as a result, perceive them to be too complicated or incompatible with agile approaches…and they may not have the required tooling.
The C4 model
The C4 model is a lightweight approach created by Simon Brown to help software development teams describe and communicate software architecture, both during up-front design sessions and when retrospectively documenting an existing code-base. It's a way to create maps of your code, at various levels of detail, in the same way you would use something like Google Maps to zoom in and out of an area you are interested in.
In order to create these maps of your code, we first need a common set of abstractions to create a language that we can use to describe the static structure of a software system.
The C4 model considers the static structures of a software system in terms of containers, components and classes (or code). Visualizing this hierarchy of abstractions is then done by creating a collection of core diagrams namely Context, Container, Component and optionally Class. This is where the C4 model gets its name from. Furthermore, you can supplement the core C4 diagrams with other diagrams to show other aspects as well.
LieberLieber approach combines the benefits of modeling in Enterprise Architect and the simply elegant concept of C4 model. The power of having a model starts to come into play when you need to rename that software system. All you do is rename it in the model and all occurrences of the software system across all diagrams are renamed too.
- Predefined model structure
- Simple notation
- C4 Diagrams with respective toolboxes
- Various approaches for traceability dependencies
LieberLieber MDG Technology for C4 is based on C4 providing predefined model structure together with core and supplementary C4 diagrams and relevant elements, enabling you to draw diagrams at varying levels of abstraction to visualize the static structure and behavior of your system.
C4 and other models
Good news for those who would like to combine their C4 model with modeling standards such as UML. By enabling a particular MDG Technology in Enterprise architect it is possible to create cross-link various types of models, providing comprehensive traceability that enables you to trace the relationships and dependencies between C4 model and other modeling languages.
In case you do not see the Video please use this Link.
When adding diagrams to your models in the project using the "New Diagram" toolbar button or the "Add -> Add Diagram ..." context menu item you will get to the "New Diagram" dialog box which now includes a new "C4" type.
- A context diagram helps you to answer the following questions. What is the software system that we are building (or have built)? Who is using it? How does it fit in with the existing environment?
- A container diagram shows the high-level shape of the software architecture and how responsibilities are distributed across it. It also shows the major technology choices, how they are used and how containers communicate with each other.
- A component diagram shows the components that reside inside each of the containers defined by container diagram.
- A class diagram shows the internals of an individual component defined by component diagram.
The C4 model is compatible with the arc42 documentation template as follows.
• Context and Scope => System Context diagram
• Building Block View (level 1) => Container diagram
• Building Block View (level 2) => Component diagram
• Building Block View (level 3) => Class diagram