Ctrl+K

Types and applications

Types and applications#

Choosing the right type of diagram to communicate an idea first requires identifying and thoroughly understanding the idea itself. It is often difficult to communicate the entirety of a software architecture in a single diagram, so an effective practice is to separate the concepts into well scoped areas and choose appropriate methods to communicate each concept. The diagrams described here are not mutually exclusive, and a combination of these should be employed in the overall description of a software.

The list of diagrams relevant to software design is extensive, and the practicality of each type varies with the situation and communication intent. This list is a subset of common, approachable, and practical diagram types. All of these are supported by at least one of the diagramming tools described in Generators.

Relational Diagrams#

These are the most common and often most practical types of diagrams used in software design. They allow designers to communicate how various components of a software system interact with each other at varying levels of fidelity. In general, blocks representing entities are connected to other blocks with lines that can contain additional metadata.

Entity-Relationship Diagram#

An entity–relationship diagram (ERD, entity-relationship model, or ERM) describes interrelated things of interest within a domain. This type of model captures limited low-level details of a system but can describe extensively the interaction of low-level components. ERD’s are traditionally used to communicate the architecture of relational databases, but they are also useful to describe the architecture of object oriented software and are closely related to the Class Diagram. and object oriented software systems. For reference, a simple ERD is shown below.

erDiagram CAR ||--o{ NAMED-DRIVER : allows CAR { string registrationNumber string make string model } PERSON ||--o{ NAMED-DRIVER : is PERSON { string firstName string lastName int age }

Fig. 1 A basic entity-relationship diagram.#

Each entity is depicted as a rectangular box, must have a name, and can optionally be given attributes. Entities are typically nouns, and they should correspond to elements of the system that store data.

erDiagram PERSON "PERSON with attributes" { string firstName string lastName }

Fig. 2 An entity-relationship diagram with attributes.#

Relationships between entities are typically verbs that connect or operate on entities. The relationships also contain cardinality information. A one-to-one relationship means that each entity is tied directly to one other entity. A one-to-many relationship means that each entity is tied to one or more other entities. Many-to-many relationships mean that a group of entities are tied to a group of other entities. There are a few conventions for indicating relationships in ERDs, and one popular notation is the crow’s foot notation. When using the Mermaid text-based generator, the text-based symbols map to the meaning as given in the following table. The rendered symbols are also shown in the diagram below.

Symbol (Left)

Symbol (Right)

Meaning

|o

o|

Zero or one

||

||

Exactly one

}o

o{}

Zero or many

}|

|{

One or many
erDiagram ZeroOrMany }o--|o ZeroOrOne : "" ZeroOrOne o|--|| ExactlyOne : "" ExactlyOne ||--|{ OneOrMany : ""

Fig. 3 An entity-relationship diagram with cardinality.#

References:

Class Diagram#

Class diagrams are used to express the relationship of various organizational components in a software system. They are primarily used in the context of object oriented programming (OOP) to communicate both the internal structure of classes and their relationship to other classes, and they are related to the Entity-Relationship Diagram. The Unified Modeling Language (UML) notation system is very closely tied to class diagrams, and UML provides a powerful ontology for creating them.

Class diagrams contain the following information:

Flow Charts#

https://dev.to/angelotheman/flowchart-wizardry-master-the-art-of-visualizing-algorithms-4e4j

Data Flow Diagram#

https://en.wikipedia.org/wiki/Data-flow_diagram

Activity Diagram#

https://en.wikipedia.org/wiki/Activity_diagram Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency. In the Unified Modeling Language, activity diagrams are intended to model both computational and organizational processes (i.e., workflows), as well as the data flows intersecting with the related activities. Although activity diagrams primarily show the overall flow of control, they can also include elements showing the flow of data between activities through one or more data stores.

https://drawio-app.com/create-uml-activity-diagrams-in-draw-io/

State Diagram#

https://drawio-app.com/blog/uml-state-diagrams-with-draw-io/

Sequence Diagrams#

https://mermaid.js.org/syntax/sequenceDiagram.html https://drawio-app.com/create-uml-sequence-diagrams-in-draw-io/

Deployment Diagrams#

Describe the infrastructure used to distribute and deploy a software. AWS and GCP have their own symbols, and UML has a generic symbol set.

https://en.wikipedia.org/wiki/Deployment_diagram https://www.lucidchart.com/pages/uml-deployment-diagram https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-deployment-diagram/

Applications of diagrams#

Elements of software design#

  • High-level design principles and overarching themes (parti)

  • Architecture at various levels of fidelity: top-level (library), mid (integration, function to function), low (within a function)

  • Data structures and flow

  • Kernel or compute code

  • Algorithms; may span various levels of fidelity

  • Developer and user workflows; i/o file structures

  • Scope of new work within existing projects

Parti and design abstractions#

These diagrams are not fixed. It can be anything that enables communicating the idea that you want to communication. Be creative!

Organizational hierarchies#

High-level object diagrams for OOP

  • Class diagrams Function flow for Functional Programming Module-module interactions

  • Component diagrams Library-library interactions

Algorithms#

Logical steps in words or pseudo code

Computational cost#

Memory access diagrams CPU/ GPU usage

Infrastructure processes#

Thing like automated testing, release pipelines, and collaborative workflows

  • Sequence diagrams

  • Deployment diagrams including symbols from AWS and GCP

User flows#

Pipelines for pre and post processing data Where your software fits into a larger context for a particular topic

Contents