Software visualization is essential in the software development lifecycle to realize how the software will be conceptualized, visualized, structured, understood, and implemented. Software visualization can be defined as the art and science of generating visual representations for the various aspects of the software.

The purpose of the visualization is setting a common understanding of the system for all stakeholders, for example, business users, development team, architects, designers, …etc.

It is a part of Software architecture and design which usually needs problem-solving and planning. This may include both a low-level component, algorithm design, and a high-level architecture design. The image below can summarize the types of visualization in the software architecture, for example, if we would like to present a system of two components, it can be visualized by text visualization or graphical visualization. I think all of us can conclude that the software requirements specifications document can be a textual visualization of the system. I think yes but not only as part of this textual presentation should include the design decisions and may have pseudo code in some parts.

In this article, we will discuss different types of graphical visualization for the software that are commonly used in the software development lifecycle. Therefore, We will discuss the following diagrams and their usage:

• Context Diagram
• Use Case Diagram
• Activity Diagram
• Class Diagram
• Entity-Relationship Model

However, this article will not discuss how to draw these diagrams and each diagram modeling language as there are a lot of resources available online for describing the modeling and notation standards.

Context Diagram

Description

The main purpose of the context diagram is to show the relation between the system and the surrounding environment. The surrounding environment can be other systems, stakeholders, data, services. In short, it defines the system boundaries and helps us knowing who use the system and which other components are critical for system operation.

It is masking and hiding the information of the detailed functions and features of the system in one component that presents the system in focus, which enables the stakeholders to focus on the system behavior and interaction with the surrounding environment without distracting them in the details of the system and its internal structure and behavior.

The Usage

It can be called the 0 level diagram which is mainly used in:

• Business analyst to understand the scope of the system and how it interacts with the environment.
• It can be used as a high-level overview diagram for the different stakeholders to understand who will use the system in terms of stakeholders and what other systems will be integrated with this system or part of it.
• It is used to scope the system operations from business perspectives.
• It can help in planning the organization’s changes, for example, we may need to have a new type of users who do not exist today, or we may need changes in other systems to be able to interact with.

In the most of the developed system, there is at least one interaction point with the surrounding environment, even if this system is an embedded board to move a car, or a sensor to read and send data. I think any system simple or complicated will need this context diagram as a high-level visualization to describe the behavior of this system and its interaction.

Example Diagram

This diagram shows the shopping system that can be an eCommerce web portal, as we can see there are two main stakeholders we have; customers and managers, also we have two systems that our system will integrate with to get and send information.

Use Case Diagram

Description

The Use Case Diagram is a representation of users’ interactions with the system and it is considered one of the behavioral diagrams. It identifies the different types of users and their related use cases. Use case Diagram is mainly used and created by the analyst to present how the different stakeholders will benefit from the system and as a method of communicating the requirements as well and description of these use cases scenarios and steps.

The Usage

The Use Case Diagram can be used for:

• Identify the stakeholders
• Illustrate the use case, in terms of its conditions, triggers, steps, flows, …etc.
• Capture the main requirements especially which performed by the stakeholders.
• It can be used to generate test cases
• Prioritize the requirements, for example, implementing the most use case first.

Use Case diagram should be used when the system has high interactions with other actors, for example, when the requirement is complex enough in a way that cannot be understood without using the use case model. So, this diagram is used to simplify the requirements and make it more understandable for business users and also for the project team across the life cycle.

Example Diagram

If we used the same example for the shopping system, we can list the different use cases that can be done for each stakeholder. This can help in scoping the functional requirements and also understand how each user will use the system, and their level of authorizations for example. It also helps the quality assurance team generating different test cases for each use case.

Moreover, we can notice some common use cases, for example, sign in use case can be consumed by different users.

Activity Diagram

Description

The main purpose of the activity diagram as one of the behavioral system diagrams to show and model business process or workflow to visualize the steps of one activity and show who are the users involved at this process and also the alternative flows. You can look at it as a flowchart of actions and decisions to show the responsible actor for each action.

In some sophisticated process and systems, we may need to use business process modeling tools using the business process model and notation language which is a powerful alternative to draw the business process.

Usually, the business analyst also draws the business process with the collaboration of the business stakeholders, the architects, and designers.

The Usage

Activity diagrams can be used to:

• Describe the steps performed in the use case model.
• Validate the business process understanding.
• Scoping the use case and illustrating the actors required to perform it.
• Illustrate the systems that will be consumed during the process execution.
• Shows the different validation should exist during the process execution.
• Process reengineering.

As we can see that activity diagrams will be very helpful in the system that automates business processes.

Example Diagram

Continuing the previous case, we can draw the shopping activity when the customer needs to purchase some items. So, we can see a scenario when the customer does not exist and that we can direct him to register. Also, this scenario can be a subject for discussion with business stakeholders, they do not prefer to make a sign in or registration a mandatory step for the customers to be able to search and select the items, then it can be the last step while they perform payment. These types of scenarios and re-engineering of the process can be easily done using process modeling tools. Moreover, it can show us the related functions or operations that will be done through the activity.

Class Diagram

Description

Class Diagram is a type of static structure diagram that describes the system structure by visualizing the system’s classes, their attributes, methods, and the relation between these classes.

The Usage

Class diagrams can be used for:

• Show the static structure of the system objects.
• A base for data models.
• Understand the overview of an application schematics.
• It can be translated to the actual classes and programming code to be implemented.
• It can be used for design validation among team members.
• It is useful for other diagrams, for example, a deployment diagram, and component diagram.

Example Diagram

This is a simple class diagram for the shopping system, it presents some of the classes in the system and each class relation with other classes. Also, it shows each class attributes and operations.

Entity-Relationship Model

Description

An entity-relationship model which is also called an entity-relationship (ER) diagram, is a representation of data entities and their relationships to each other, typically used in visualizing the data structure within the systems. The data model can be presented at various levels; Conceptual, logical, and physical model. The ERD can be used mainly to show the 3 levels while it is mostly used to visualize the physical level.

The Usage

The ERD can be useful especially that the data is the core asset of any informational system:

• It is used and essential for database design.
• It Illustrates the Data entities and its structure from attributes and its types, and how it is connected to each other
• It can easily detect the missing data that should exist to satisfy business needs and especially in reports and analytics.
• It is important for some projects if you would like to migrate data from one system to another and if you would like to do process re-engineering.
• It shows the important data elements and assets for the organization which is highly used now for different types of statistics and reports, without data we cannot measure the performance of the operation or cannot predict any abnormal activity for example.
• It obvious that ERD used only for the relational and structured data.

Example Diagram

I used one of the online available diagrams, which can fit as well in our example that we used on the shopping website. We can see some data entities and their internal structure, from a diagram like this we can also take some decision regarding the data, for example, adding a separate entity for address, or we missed the invoices entity.

Conclusion

In this article, we discussed various diagrams to visualize the software and help the different stakeholders during the software development lifecycle to have a better understanding of the system from its structural and behavioral perspectives. There are a lot of other diagrams that can be used as well during the life cycle, for example, the Sequence Diagram, Deployment Diagram, Decomposition Diagram, …etc. I think the good business analyst and architect should select the appropriate diagrams which meet the stakeholders’ concerns and show how their concerns have been fulfilled in the system.

Finally, we can visualize the system by building prototypes or demos which facilitate validating the requirements and show a concept or a process with the stakeholders.

---

Also published on Medium.