Diagram Visualization

Representation
UML Types
Best Practices
Pros and Cons

Aspect	Unified Modeling Language (UML)	Business Process Model and Notation (BPMN)
Definition	standardized visual language used in software engineering to model and describe software systems through graphical notations, facilitating communication and visualization of system structure, behavior, interactions, and architecture among project stakeholders	standardized graphical notation for modeling business processes and workflows. It provides symbols and conventions to represent tasks, events, gateways, and flows, enabling stakeholders to document, analyze, and improve business processes visually
Purpose	modeling software systems/components	modeling business processes/workflows
Scope	applicable in software engineering across industries	focuses on business process modeling/automation
Diagram Types	Structural Class Diagram Component Diagram Composite Structure Diagram Deployment Diagram Object Diagram Package Diagram Profile Diagram Behavioral Activity Diagrams Interaction Diagram Communication Diagram Interaction Overview Diagram Sequence Diagram Timing Diagram State Diagram Use Case Diagram	process collaboration choreography
audience	software engineers, architects, developers	architects, business analysts, managers
Level of Detail	detailed system modeling	high-level abstraction of business processes

The most commonly used UML diagram, representing classes, attributes, operations, and their relationships within a system.

Basic Components of a Class Diagram:

Upper Section: Contains the class name, always required
Middle Section: Lists class attributes, necessary for specific instances
Bottom Section: Displays class operations (methods) in list format

Member Access Modifiers:

Public (+)
Private (-)
Protected (#)
Package (~)
Derived (/)
Static (underlined)

Member Scopes:

Classifiers: Static members
Instances: Specific class instances

Additional Class Diagram Components:

Classes: Templates for object creation and behavior implementation
Name, Attributes, Methods: Key components of a class shape
Signals, Data Types, Packages, Interfaces, Enumerations, Objects, Artifacts: Various elements to represent system entities

Interactions:

Inheritance: Child classes inheriting functionality from parent classes
Bidirectional Association: Mutual awareness between classes
Unidirectional Association: One-way interaction between classes

Relationship Type	Visualization	Definition
Inheritance (Generalization)	A inherits properties and behavior from B	Represents "is-a" relationship. Parent-child relationship where the child class is based on the parent class, but with more specific functionality
Composition	A owns and manages the lifecycle of B (B cannot exist without A)	strong type of aggregation where the whole and part have a strong life cycle dependency. The part cannot exist without the whole
Aggregation	A owns and manages the lifecycle of B (B can exist independently)	special form of association where the whole and part have a relationship. The part can exist independently of the whole. It is also called a "has-a" relationship
Association	A and B can access each other's methods and properties	relationship between two classes where one class uses the functionality of another class. It is usually bi-directional with a multiplicity of one or many
Dependency	A depends on B to function properly	relationship between two classes when changes to one class may cause changes to the other
Realization	A implements the behavior of B	relationship between two classes where one class implements the behavior specified by another. It is typically used in the context of interfaces

Displays structural relationships of software system elements, particularly useful for complex systems with multiple components communicating via interfaces

Type	Visualization	Definition
Component		represents a modular, reusable, and replaceable part of a system that encapsulates its behavior and data
Node		represents hardware or software objects, which are of a higher level than components. It defines a boundary through which entities communicate with each other, facilitating interaction between different parts of a system
Interface		represents a contract specifying a set of operations or behaviors that a class or component must implement
Port		represents a point of interaction between a component and its environment or between different components within a system. Ports facilitate communication by providing access to services, data, or behavior offered by a component or required by another component. They serve as connection points through which messages can be sent and received, enabling the exchange of information and control between various parts of the system
Package		represents a namespace for organizing and grouping elements, such as classes, components, and diagrams, into a cohesive unit. It serves as a container for organizing and managing the elements of a model, providing a way to structure and modularize complex systems
Notes		annotations or comments that provide additional information about elements within a diagram. They are used to convey explanations, descriptions, constraints, or other important details that may not be readily apparent from the diagram itself
Dependency		relationship between two elements in which a change in one element may affect the other element. It signifies that one element, called the client, relies on another element, called the supplier, in some way. Dependencies can be used to represent various types of relationships, such as the usage of one element by another, the inclusion of one element within another, or the reliance of one element on the services provided by another
Provided Interface		offered or implemented by a component, class, or other architectural element. It specifies a set of operations or services that the element makes available for use by other elements in the system. Provided interfaces define the contract or protocol that clients can use to interact with the element, specifying the methods or behaviors that clients can invoke
Required Interface		interface that a component, class, or other architectural element needs in order to function properly. It specifies a set of operations or services that the element expects to be provided by other elements in the system. Required interfaces define the dependencies or collaborations that the element relies on to fulfill its responsibilities or perform its tasks

Shows the internal structure of a class

Type	Visualization	Definition
Terminator		indicates start and end points
Node		represents events or milestones and contain numbers
Actor		interacts with the system from outside of the system (person, equipment, etc.)
Class		groups objects with common properties or behaviors (common operations, parameters, attributes, etc.)
Part		acts as a runtime instance of classes or interfaces
Port		acts as an interaction point between a classifier instance (or its behavior) and its environment
Interface		specifies behavior that the implementor agrees to meet

Illustrates system hardware and software deployment across multiple machines with unique configurations

Type	Visualization	Definition
Package		organizes elements, such as components or nodes, into logical groups to manage complexity and enhance clarity in system design
Object		represents an instance of a class or entity in a system, displaying its state and behavior
Node		physical or virtual computing resource in a system, such as a server, workstation, or device
Component		modular, reusable, and replaceable part of a system that encapsulates its behavior and data
Interface		defines a contract for communication or interaction between components, nodes, or systems

Illustrates object relationships using real-world examples, depicting the system's state at a given time

Type	Visualization	Definition
Object		represents an instance of a class or entity in a system, displaying its state and behavior

Represents package dependencies and system architecture levels using package import and merge mechanisms

Type	Visualization	Definition
Package		organizes elements, such as components or nodes, into logical groups to manage complexity and enhance clarity in system design

Graphical representation of business or operational workflows, an alternative to State Machine diagrams

Key aspects

Action: A step in the activity wherein the users or software perform a given task
Decision node: A conditional branch in the flow that is represented by a diamond. It includes a single input and two or more outputs
Control flows: Another name for the connectors that show the flow between steps in the diagram
Start node: Symbolizes the beginning of the activity. The start node is represented by a black circle
End node: Represents the final step in the activity. The end node is represented by an outlined black circle

Type	Visualization	Definition
Start		Represents the beginning of a process or workflow in an activity diagram. It can be used by itself or with a note symbol that explains the starting point
Activity		Indicates the activities that make up a modeled process. These symbols, which include short descriptions within the shape, are the main building blocks of an activity diagram
Connector		Shows the directional flow, or control flow, of the activity. An incoming arrow starts a step of an activity; once the step is completed, the flow continues with the outgoing arrow
Joint symbol/ Synchronization bar		Combines two concurrent activities and re-introduces them to a flow where only one activity occurs at a time
Fork		Splits a single activity flow into two concurrent activities
Decision		Represents a decision and always has at least two paths branching out with condition text to allow users to view options. This symbol represents the branching or merging of various flows with the symbol acting as a frame or container
Note		Allows the diagram creators or collaborators to communicate additional messages that don't fit within the diagram itself. Leave notes for added clarity and specification
Send signal		Indicates that a signal is being sent to a receiving activity
Receive signal		Demonstrates the acceptance of an event. After the event is received, the flow that comes from this action is completed
Shallow history pseudostate		Represents a transition that invokes the last active state
Option loop		Allows the creator to model a repetitive sequence within the option loop
Flow final		Represents the end of a specific process flow. This symbol shouldn't represent the end of all flows in an activity; in that instance, you would use the end symbol. The flow final symbol should be placed at the end of a process in a single activity flow
Condition text		Placed next to a decision marker to let you know under what condition an activity flow should split off in that direction
End		Marks the end state of an activity and represents the completion of all flows of a process

Represents object interactions and their order of occurrence for a particular scenario

Type	Visualization	Definition
Object		Represents a class or object in UML. The object symbol demonstrates how an object will behave in the context of the system. Class attributes should not be listed in this shape
Activation		Represents the time needed for an object to complete a task. The longer the task will take, the longer the activation box becomes
Actor		Shows entities that interact with or are external to the system
Package		Used to contain interactive elements of the diagram. Also known as a frame
Lifeline		Represents the passage of time as it extends downward. This dashed vertical line shows the sequential events that occur to an object during the charted process. Lifelines may begin with a labeled rectangle shape or an actor symbol
Option loop		Used to model if/then scenarios, i.e., a circumstance that will only occur under certain conditions
Alternative		Symbolizes a choice (that is usually mutually exclusive) between two or more message sequences
Synchronous message		Used when a sender must wait for a response to a message before it continues. The diagram should show both the call and the reply
Asynchronous message		Asynchronous messages don't require a response before the sender continues. Only the call should be included in the diagram
Asynchronous return message		Represented by a dashed line with a lined arrowhead
Asynchronous create message		This message creates a new object
Delete message		This message destroys an object

Use Consistent Naming Conventions: Always use standard naming conventions for your UML diagrams. This will ensure that all stakeholders understand the diagrams without any confusion
Avoid Using Excessive Details: UML diagrams should be simple and not cluttered with unnecessary information. If the diagram becomes too complex, it will be difficult to understand
Use Correct Symbols and Notations: UML has a set of standard symbols and notations. Make sure you use the correct ones for the appropriate elements in your diagrams
Keep Diagrams Small: Large diagrams can be difficult to read and understand. Break down complex processes into smaller, manageable diagrams
Use Color Coding: Color coding can be used to highlight different elements or differentiate between different types of information
Use Notes and Comments: Use notes and comments to explain complex parts of the diagrams or to provide additional information
Use Layers: If your diagram is complex, use layers to separate different parts of the diagram. This makes it easier to understand the diagram
Use Diagrams to Complement Text: Diagrams should not replace text, but complement it. Use diagrams to illustrate complex processes or structures that are difficult to explain in words
Use Real-world Examples: Whenever possible, use real-world examples in your diagrams. This makes the diagrams more relatable and easier to understand
Validate Your Diagrams: Always validate your diagrams to ensure that they accurately represent the system or process you are modeling
Use the Right Type of Diagram: UML has several types of diagrams. Make sure you use the right type for the task at hand
Use a Standardized Layout: Use a standardized layout for your diagrams. This makes it easier for others to understand your diagrams
Collaborate with Others: Collaborate with other stakeholders when creating your diagrams. This ensures that all perspectives are considered and that the diagrams are understood by all
Use Version Control: As your system evolves, so too will your diagrams. Use version control to keep track of changes and maintain a history of your diagrams
Regularly Review and Update Your Diagrams: Regularly review and update your diagrams to ensure they accurately represent the current state of your system or process
Use Abstraction and Generalization: Use abstraction and generalization to simplify complex systems and make them easier to understand
Avoid Redundancy: Do not duplicate elements or information in your diagrams
Use Association, Aggregation, and Composition Wisely: Understand and use these relationships appropriately in your diagrams
Make Effective Use of Stereotypes: Stereotypes can help to clarify the meaning of elements in your diagrams. Use them effectively