Diagram: Layering Software-Centric Systems (an example for a Layer Diagram)


Read this article if you want to learn how to layer software centric server-based system. This article is not geared towards a specific technology and the concepts presented can be applied to any type of server-centric architectures, such as J2EE or .NET It does – however – have a focus on server-side processing such as web-based, rich-client or service-oriented architectures.

A more complex layer diagram
Figure 1 - A more complex layer diagram (click to see in full size)

1.      Introduction

The layer diagram is a diagram also commonly found in IT Architectures. It has uses in many IT domains, not just Software Architecture. This article will – however –primarily focus on the Software Architecture view, and not consider others.

The layer diagram is a particularly popular diagram for a number of reasons. Two important ones for me are:

  • It provides an easy to read logical view of the software architecture to be put into place, and
  • It can be used to show how the technical components (layers, tiers and data) are tied together with the functional (functions and business objects) components of a software system.

In this article I am going to outline the notation I have come to use in software development projects of that kind. It may be mixture of a number of notations but it assists well in describing the logical view of a software system.

Diagrams of this kind can be drawn with any tool. Often I simply use paper, flipcharts or white-boards to develop layer diagrams and usually only document the final view with a tool.

2.      Typical Use

This diagram is typically used to develop the high-level design for a software-centric system to demonstrate

  • how an application is structured into logical (technical) components
  • where major technical subsystems are placed in the architecture
  • how functional components of the system are tied with the technical components
  • how the data is dealt with by the software system

3.      Notation used in Layer Diagrams

While I tried to outline the steps in a serial manner, the development or a layer diagram will always be iterative where you will most likely iterate through the outlined steps a number of times.

Step 1 – Identify and Define Tiers
Layer Diagram - Starting with Tiers
Figure 2 - Starting with Tiers (click to see in full size)

As a first step identify the tiers of the system. This primarily depends on the non-functional requirements. In addition it will – however – also be influenced by the functional requirements. Therefore it is important not to leave them out in the thought process.

Briefly identify and describe the responsibilities each tier has.

Step 2 – Identify and define layers and place technical components
Layer Diagram - Adding Layers and Respnsibilities
Figure 3 - Adding Layers and Responsibilities (click to see in full size)

In a second step identify the layers. This process is mainly driven by non-functional requirements and best practices. Briefly define and describe the responsibilities each layer has.

Once the layers have been placed, identify important technical (framework) components and place them into the appropriate layer of your architecture. Examples are: asynchronous processes, caches, security, and others.

Step 3 – Place functional components and Data
Layer Diagram - Adding Functions and Data
Figure 3 - Adding Functions and Data (click to see in full size)

Always keep in mind how the technical platform created will cater to the needs of the functional requirements. While large parts of the technical architecture can be developed based on best practices, you will always need to make minor adjustments based on functional needs.

What I have found most useful it to finally place functions into the layer diagram. This helps to:

  • Identify technical components required to bridge between the technical layering and the functional aspects. Specifically, how responsibilities need to be placed into the layers so that the functional needs can be catered to appropriately.
  • Identify how data is dealt with in the architecture. Typically each layer will deal with the same data differently in each layer.

Notes on developing responsibilities for layers

I will start at side of the client request and define what type of service the server needs to provide to the client. From there on I will move to the data layer on a layer by layer basis and define which service the next layer needs to provide to the previous layer.

Looking at the figure above, this could be something line: the web layer uses Services in the service layer, the service layer uses business logic and/or business rules in the logic layer, the logic layer uses data access objects in the data access layer which read and persist data.

Notes on placing the data

Do not forget about placing data and that data is not equal to data. It is important to note that different layers will operate on the same data but will often require the data to be in a different format. For example:

  • The data in the data layer is stored in a relational database schema (if you are using a relational database).
  • The data access layer will operate on an object representation of that data layer often with the help of a object-relational-mapping component such as Hibernate. Therefore the data objects need to be a much closer representation of the database schema itself. I often call them data access layer POJOs.
  • The other layers will in most cases operate on an object representation that more closely reflects the reality of the domain the software is developed for. This is what I usually call Business Objects (BOs).

References

[Pic2010] Pichler, M. 2010, “Diagram: A more complex Layer Diagram (example)”, A Practical Guide to Software Architecture [online] available at https://applicationarchitecture.wordpress.com/

[Pic2010] Pichler, M. 2010, “Diagram: A more complex Network Diagram (example)”, A Practical Guide to Software Architecture [online] available at https://applicationarchitecture.wordpress.com/

[Pic2010] Pichler, M. 2010, “Diagram: The Network Diagram”, A Practical Guide to Software Architecture [online] available at https://applicationarchitecture.wordpress.com/

[Pic2010] Pichler, M. 2010, “Knowledge Nugget: What is a Layer in Software Architecture?”, A Practical Guide to Software Architecture [online] available at https://applicationarchitecture.wordpress.com/

[Pic2010] Pichler, M. 2010, “Knowledge Nugget: What is a Tier in Software Architecture?”, A Practical Guide to Software Architecture [online] available at https://applicationarchitecture.wordpress.com/

[Pic2010] Pichler, M. 2010, “On documenting Software Architecture (for Business Applications)”, A Practical Guide to Software Architecture [online] available at https://applicationarchitecture.wordpress.com/

Copyright © 2010 Michael Pichler

Advertisements

3 thoughts on “Diagram: Layering Software-Centric Systems (an example for a Layer Diagram)

  1. Really enjoyed reading your articles. Great stuff. Can you let me know which tool did you use to create the Figure 1? If it is visio, can you please share it in visio format?

    1. Hi there. Thank you for letting me know! I apologize for my late response. It may sound funny, but I am using MS PowerPoint for drawing those diagrams. I use it most of the times when I need something nice-looking, rather than a model.

      Regards, Michael

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s