Labs
13 Components & Models

Components and Models

Behavioral

Structural

Objective

  1. Design components and interfaces.
  2. Organize into packages
  3. Create deployments.
  4. Apply the C4 model.

Components

Component diagrams illustrate how executable elements of a system interact through well-defined interfaces. Components are like building blocks that provide specific functionality and can be assembled to create a complete application. They represent concrete parts of the system that work together at runtime. For instance, in an e-commerce system, a shopping cart component might interact with an inventory component through defined interfaces to check stock levels and update quantities. Component diagrams help teams understand the runtime behavior and interactions between different parts of the system.

Exercise 1

Design a component diagram in models.vpp based on your class diagrams.

Packages

Package diagrams take a step back to show how the system is organized into logical groupings called packages. While components show runtime elements, packages are more about code organization—think of them as boxes that contain related code elements like classes, interfaces, and even other packages. For example, those shopping cart and inventory components might belong to different packages based on their role in the system—perhaps a “commerce” package and an “inventory-management” package. Package diagrams help architects and developers understand the system’s overall structure and dependencies.

Exercise 2

Design a package diagram in models.vpp that shows how components are organized into packages.

Deployments

Deployment diagrams shift focus to show the physical architecture—how and where the software actually runs. They illustrate the hardware nodes, like servers, devices, or cloud instances, and how software artifacts are distributed across them. For instance, your shopping cart component might need to run on both the user’s web browser and a backend server, while the inventory component might run exclusively on backend services. Deployment diagrams help teams understand the infrastructure needed to run the system.

Exercise 3

Design a deployment diagram in models.vpp that shows how the components are deployed across different hardware nodes.

These three diagram types complement each other by describing different aspects of the system. Component diagrams show runtime behavior and interactions, package diagrams show the logical organization of code, and deployment diagrams show the physical infrastructure. Together, they help teams understand both how the software is built and how it operates in the real world.

C4 Model

“Simplicity is the ultimate sophistication.” —Leonardo da Vinci

The C4 model (opens in a new tab) (Context, Containers, Components, Code) builds upon and adapts traditional UML concepts to provide a hierarchical way of mapping software architecture. It uses a progressive zoom approach that aligns with these diagrams but adds important context and structure:

  1. Level 1 (Context) operates above traditional UML diagrams, showing the whole system as a box and focusing on how it interacts with users and other systems. This provides crucial business context that traditional UML diagrams sometimes miss.

  2. Level 2 (Containers) is similar to deployment diagrams, but with a more modern take. Instead of just showing physical hardware, it shows high-level “containers” like web applications, mobile apps, databases, or microservices. This better reflects how modern software is deployed across different technologies and platforms.

  3. Level 3 (Components) aligns closely with component diagrams, but the C4 model emphasizes showing the key structural building blocks within each container. This helps bridge the gap between high-level architecture and implementation details. While UML component diagrams might show all components, C4 encourages focusing on the major structural elements.

  4. Level 4 (Code) is where C4 directly incorporates UML class diagrams and package diagrams, but only when necessary for specific details. The C4 model suggests using these detailed diagrams sparingly and only for the most important parts of the system.

The key innovation of C4 is how it provides a clear narrative path from high-level context down to implementation details, while traditional UML diagrams are often used more independently. C4 also emphasizes accessibility and clarity for stakeholders at different levels, whereas UML can sometimes be too technical for non-technical stakeholders.

Exercise 4

Design a C4 model of the system that shows the context, containers, components, and code levels, then export it to c4.svg.

Structure

      • c4.svg
      • models.vpp

    • Resources

    12 Behavioral Patterns14 Boards & Charts