Design Principles & Concepts
Core guidelines and fundamental ideas for structuring software design
Software Design is the process of planning and converting user requirements into actionable steps to develop a complete software system.
To ensure a high-quality product, software engineers rely on a specific set of principles to arrange the structural components of the design. Applying these principles early significantly impacts the content and the overall working process of the software from the very beginning.
10 The Principles of Software Design
01. Avoid "Tunnel Vision"
The design process should not focus blindly on just completing the immediate aim. It must consider the broader effects and impacts of the design choices on the whole system.
02. Traceable to Analysis Model
Every part of the design must directly connect back to the original analysis model. This ensures the design strictly satisfies all the requirements needed to develop a high-quality product.
03. Don't "Reinvent the Wheel"
Designers should not waste time or effort recreating solutions that already exist. Utilizing existing, proven methods increases the overall speed of development.
04. Minimize Intellectual Distance
The software solution should closely mirror the real-world problem it is trying to solve. The design must reduce the gap between the physical problem and the digital solution.
05. Exhibit Uniformity & Integration
The design must display uniformity, meaning it stays consistent throughout the entire process without random style changes. Integration ensures that all separate subsystems successfully mix and combine into one unified system.
06. Accommodate Change
Software should be designed with flexibility in mind. It must easily adjust and accommodate modifications that arise from changing user needs.
07. Degrade Gently
The software should be robust enough to degrade gracefully. If an error occurs during execution, the system should continue to work properly without crashing entirely.
08. Assess for Quality
The design must be continuously evaluated during its creation. This evaluation specifically checks and focuses on ensuring high quality in the architecture.
09. Review to Discover Errors
Comprehensive reviews must be conducted on the design to discover hidden errors. The goal of this evaluation is to minimize or entirely remove mistakes before coding begins.
10. Design & Coding are Distinct
Design is the process of describing the underlying logic required to solve a problem. Coding is simply using a programming language to physically implement that design. They are completely different activities.
4 The Four Core Design Tasks
1. Data Design
Transforms the initial information requirements into actual data structures (like databases or Entity-Relationship diagrams) that the software will use.
2. Architectural Design
Creates the overall framework of the system. It defines how the major structural elements and subsystems relate and connect to each other.
3. Interface Design
Describes how the software communicates. This includes how internal parts talk to each other, how it connects with external systems, and how humans interact with it.
4. Component-level Design
Zooms in on the architecture to create detailed, step-by-step procedural descriptions (algorithms and logic) for each individual software component.
Software Design Concepts
A design concept is the principal idea or logic behind how a software engineer plans to solve a problem. The main goal of this phase is to transform the customer's requirements (the SRS document) into a concrete design document for programmers to follow.
A good design must be Correct (works properly), Efficient (saves resources and time), Understandable (modular and layered), Complete (missing no parts), and Maintainable (easy to adapt to change requests).
Abstraction (Hide the Clutter)
Hiding irrelevant background details so you can focus on the big picture. It reduces complexity by explaining things broadly at higher levels, and saving the complex details for lower levels.
Modularity (Divide & Conquer)
Subdividing a massive, complicated system into smaller, independent parts (modules). This makes the software much easier to build, understand, and reuse, lowering the overall cost and effort.
Architecture (The Blueprint)
The technique used to design the overall structure of the software. It focuses on what the main elements are and how they interact and share data with one another.
Refinement (Add Detail to Fix Errors)
The process of slowly elaborating on a design to remove impurities. By presenting the system in a more detailed manner step-by-step, you can easily spot and fix errors.
Pattern (Reuse Proven Solutions)
A repeating, proven design form used to solve a common, recurring problem. Instead of inventing a new solution, you apply a standard pattern.
Information Hiding (Keep Secrets)
Designing modules so that their internal information is hidden and cannot be accessed by unwanted parties or other modules. This prevents accidental tampering.
Refactoring (Clean Up the Mess)
Reconstructing or cleaning up the design to reduce complexity, without actually changing how the software behaves or functions. It makes the code cleaner and simpler to read.
Effective Modular Design
Breaking down massive systems into smart, independent pieces
Why do we need Modularity?
Designing a complete software system in one giant piece is incredibly hectic and leads to a massive amount of errors because of its vast size.
To solve this, development teams break the software down into smaller, manageable chunks called modules. The actual process of dividing the software into these independent pieces is called Modularization.
What is a Module?
A module is a unique, addressable component of the software.
An effective module must be separately solvable, modifiable, and compilable. This means you should be able to make changes to one module without needing to recompile the entire software system.
Functional Independence (The Golden Rule)
To build great modular software, you need "Functional Independence".
This means a function should be atomic—it performs exactly one single task, and it does so with the absolute least amount of interaction with other modules. The more independent your functions are, the higher the quality of your software design.
Benefits of Independent Modules
Clearer Focus
Because functionalities are broken down to an atomic level, developers have a crystal-clear understanding of what each specific function needs to do. This makes designing much easier and error-free.
Safe Modifications
Independent modules have almost zero dependency on other parts of the system. You can safely make changes or upgrades to one module without accidentally breaking the entire software.
Error Isolation (Quarantine)
If a bug occurs, it stays trapped inside its specific module instead of propagating and infecting the whole system. This saves a massive amount of time during testing and debugging.
Cohesion & Coupling
Measuring the independence and quality of software modules
To figure out if our modular design is actually "effective" and functionally independent, we measure it using two core criteria: Cohesion and Coupling.
The Golden Rule of Software Design: A good software design ALWAYS requires HIGH Cohesion and LOW Coupling.
1. Cohesion (Intra-Module)
Cohesion measures the degree to which components inside a single module are related to each other. It is an "intra-module" concept that indicates the relative functional strength of a module. A highly cohesive module performs a single task and requires very little interaction with other parts of the program.
Types of Cohesion (From Worst to Best)
1. Coincidental Cohesion (Lowest / Worst)
A random collection of unrelated functions grouped purely by accident or location. Example: A module that prints the next line AND reverses a string.
2. Logical Cohesion
Elements perform similar logical operations (like "input" or "error handling"), but aren't functionally related. Example: One component reads inputs from a tape, a disk, and a network.
3. Temporal Cohesion
Functions are grouped together because they must be executed in the exact same time span. Example: A startup module that handles initialization and boot-up routines.
4. Procedural Cohesion
Functions are grouped because they follow a specific sequence of steps in an algorithm or procedure. Example: Calculate student GPA, then print student record.
5. Communicational Cohesion
Functions are grouped because they all refer to, update, or operate on the exact same input/output data structure. Example: Update a database record and send that same record to a printer.
6. Sequential Cohesion
Elements form a chain where the output data from one function instantly becomes the input data for the next. Example: get-input → validate-input → sort-input.
7. Functional Cohesion (Highest / Best / Ideal)
Every single element in the module cooperates strictly to achieve one single, specific function. Example: A module containing only the functions required to manage an employee's payroll.
Advantages of High Cohesion
- Results in much better overall program design.
- Highly cohesive components can be easily reused in other projects.
- Components are significantly more reliable.
Disadvantages of Low Cohesion
- Difficult to maintain, understand, and read.
- Cannot be easily reused.
- Less reliable and more prone to logical errors.
2. Coupling (Inter-Module)
Coupling is the measure of the strength of the relationship between different modules. It is an "inter-module" concept indicating how dependent modules are on one another. The complexity depends on how much data passes across their interfaces.
Types of Coupling (From Best to Worst)
1. Data Coupling (Lowest / Best)
Modules only communicate by passing basic, elementary data parameters (like an integer or a float) through an argument list. It is highly maintainable.
2. Stamp Coupling
Modules communicate by passing an entire composite data structure (like a Record in Pascal, a Struct in C, or an Object in C++) rather than just basic variables.
3. Control Coupling
Data passed from one module is explicitly used to direct or change the order of execution inside another module. Example: Passing a "flag" variable that triggers an if/else block.
4. Common Coupling
Multiple modules share and have read/write access to the exact same global data space. Disadvantage: A change in global data forces you to trace back and update every single module that accesses it.
5. Content Coupling (Highest / Worst)
One module directly modifies the data or shares the internal code of another module. Example: A "goto" branch statement jumping from inside one module into the middle of another.
Additional Coupling Types:
External Coupling: Modules depend on external tools, hardware, device formats, or communication protocols outside the software itself.
Message Coupling: Independent components communicate exclusively via message passing.
Advantages of Low Coupling
- Prevents the "ripple effect" where one change breaks other components.
- Low coupled components are easily reused.
- Systems can be built and tested much faster.
Disadvantages of High Coupling
- Extremely difficult to understand and track.
- Changing one component forces you to change many others.
- Slows down the overall development process.
Direct Comparison: Cohesion vs. Coupling
| Cohesion | Coupling |
|---|---|
| Concept of Intra-module (inside the module). | Concept of Inter-module (between modules). |
| Indicates the relationship within the module itself. | Indicates the relationship between different modules. |
| Represents the functional strength of a module. | Represents the relative independence among modules. |
| High cohesion is GOOD for software. | High coupling is BAD (avoided) for software. |
| A cohesive module focuses on a single thing (single-mindedness). | In coupling, modules are explicitly connected to other modules. |
| Design Goal: Strive for high cohesion (focus on a single task with little interaction with other modules). | Design Goal: Strive for low coupling (dependency between modules should be as little as possible). |
| Data Hiding: Cohesion is a natural extension of data hiding (e.g., a class having all members visible within a package with default visibility). | Data Hiding: Making fields private, methods private, and using non-public classes directly provides loose coupling. |
Architectural Design
The blueprint and structural styles of a software system
What is Software Architecture?
Architectural design represents the structure of data and program components that are required to build a computer-based system. It considers the architectural style, the structure/properties of the components, and the interrelationships among all architectural components.
Specifically, a software architecture comprises the software components, the externally visible properties of those components, and the relationships among them.
Why is Architecture Important?
The architecture is not the operational software itself, but a representation that allows engineers to analyze design effectiveness, consider alternatives early on, and reduce construction risks.
- It enables communication between all stakeholders and the developer.
- It highlights early design decisions that have a massive impact on all following software engineering work and the ultimate success of the system.
- It constitutes a relatively small, intellectually graspable model of how the system is structured.
- It helps integrate the components and defines how they work together.
Architectural Styles
Every computer-based system exhibits one of many architectural styles. Each style encompasses:
- A set of components (e.g., a database, computational modules) performing required functions.
- A set of connectors enabling communication, coordination, and cooperation among components.
- Constraints defining how components can be integrated.
- Semantic models helping designers understand overall properties by analyzing its parts.
1. Data-Centered Architectural Style
In this style, a data store (like a file or database) resides at the exact center of the architecture and is accessed frequently by other components that update, add, delete, or modify that data. Client software accesses this central repository.
- Passive Repository: The client accesses the data independent of any changes or actions from other clients.
- Blackboard Mechanism: The central store notifies client software when data of interest changes.
- Two Types of Components: A central data repository (providing permanent storage/current state) and data accessors (independent components computing and interacting with the store).
Advantages
- Data repository is independent of the clients.
- Promotes integrability (new clients can be added easily without asking permission from others).
- Provides data integrity, backup, and restore features.
Disadvantages
- Vulnerable to total failure (single point of failure) and data replication issues.
- High dependency on the structure of the data store; changes in data structure highly affect all clients.
- Evolution of data is difficult and expensive.
2. Data Flow Architectural Style
This architecture is applied when input data needs to be transformed through a series of computational or manipulative components into output data.
Pipe and Filter Pattern
Batch Sequential (Linear)
- Pipe and Filter Pattern: A set of components (filters) are connected by pipes that transmit data from one to the next. Each filter works independently and does not require knowledge of its neighboring filters.
- Batch Sequential: If the data flow degenerates into a single, straight line of transforms, it is called batch sequential. It accepts a batch of data and applies sequential components to transform it.
Advantages
- Provides concurrency and high throughput for excessive data processing.
- Provides reusability, modifiability, and low coupling between filters.
- Flexible, supporting both sequential and parallel execution.
Disadvantages
- Not suitable for dynamic interactions.
- Requires a low common denominator for transmission (like ASCII), adding data transformation overhead.
- Does not allow filters to cooperatively interact to solve problems dynamically.
3. Distributed (Client-Server) Architectural Style
This model partitions tasks and workloads between resource providers (Servers) and service requesters (Clients). Clients request data over a network, and the server accepts the request and delivers the data packets back. Examples include Email and the World Wide Web.
The Client
A computer (host), person, or organization requesting information or a particular service from a provider. Clients do not share their own resources with others.
The Server
A remote computer that provides the information, data, or access to the services that the client requested.
Basic Client-Server Architecture
How a Browser Interacts with a Server:
- User enters URL. The browser requests the domain's IP from the DNS (Domain Name System) server.
- DNS Server responds with the specific IP address of the Web Server.
- Browser sends an HTTP/HTTPS request directly to that Web Server's IP.
- Server sends back the necessary website data files.
- Browser renders the files using DOM, CSS interpreters, and JS Engines (JIT Compilers).
Advantages
- Centralized system with all data safely in a single place.
- Cost-efficient, requires less maintenance, and allows for easy data recovery.
- Capacity of clients and servers can be scaled independently.
Disadvantages
- Servers are highly prone to Denial of Service (DOS) attacks.
- Clients can easily catch viruses, Trojans, and worms if they are uploaded to the server.
- Vulnerable to MITM (Man in the Middle) attacks, data spoofing, and phishing.
4. Peer-to-Peer (P2P) Architecture
In a P2P architecture, there is no central server. Instead, all nodes (computers) are completely equal participants in sharing data, and all tasks are equally divided among them. Nodes act as both clients (using resources) and servers (providing resources).
Peer-to-Peer Network
- Usually formed by small groups of a dozen or fewer computers.
- Computers use individual security to store data, but share it with all other nodes.
- Unlike Client-Server models (where servers crash under pressure), adding more nodes to a P2P network actually increases its overall resource sharing capacity.
Advantages
- Very easy to set up and maintain because each computer manages itself.
- Saves money because there is no need to purchase an expensive central server.
- Highly scalable; adding nodes increases data capacity, and no node is entirely dependent on another.
Disadvantages
- Difficult to back up data since it is scattered across different independent computer systems.
- Extremely difficult to provide overall adequate security (nodes act as both clients and servers, easily leading to DOS attacks).
5. Call and Return Architecture
This style breaks down a program into a structured hierarchy, making it relatively easy to modify and scale. It is heavily associated with traditional programming languages like C, Pascal, and BASIC.
Main Program / Sub-Program Hierarchy
Two Main Sub-Styles:
- Main Program/Sub-Program: A classic structure where a "main" top-level program invokes various sub-program components, which in turn invoke their own sub-components (creating a control hierarchy).
- Remote Procedure Call (RPC): Similar to the main/sub-program model, but the components are physically distributed across multiple different computers on a network to increase performance.
Advantages
- Provides good modularity.
- Subroutines can be easily replaced or swapped as long as their interface semantics remain unaffected.
Disadvantages
- Usually fails to scale well for massive systems.
- Pays inadequate attention to underlying data structures.
- The effort required to accommodate new requirements is often unpredictable.
6. Object-Oriented Architecture
Considered the latest evolution of the call-and-return architecture. Instead of viewing a system as a set of procedural routines, this architecture views the system as a series of cooperating objects. These components encapsulate both the data and the specific operations (methods) needed to manipulate that data. Objects coordinate and communicate entirely via message passing.
Advantages
- Maps directly to real-world objects, making it much easier to understand.
- Easy to maintain and improves quality through program reuse.
- Provides extensive reusability via polymorphism and abstraction.
- Highly robust (manages errors well during execution).
- Extensible; you can add new functionality without affecting the whole system.
- Reduces overall development time and cost, while improving testability through encapsulation.
Disadvantages
- It can be difficult to determine all the necessary classes and objects required upfront.
- Because it requires a different kind of project management, it can be hard to finish within estimated time and budget constraints.
- Does not magically lead to large-scale reuse unless a strict, explicit reuse procedure is enforced.
7. Layered Architecture
In this style, the system is organized into a number of different layers, with each layer performing a well-defined set of operations. As you move deeper into the layers, the operations become progressively closer to the machine's core instruction set.
Concentric Layered Model
- Outer Layer: Receives all user interface operations.
- Intermediate Layers: Provide utility services and core application software functions.
- Inner (Core) Layer: Communicates and coordinates directly with the Operating System.
Advantages
- Provides excellent modularity and clear interfaces.
- Highly maintainable, flexible, scalable, and simple to implement.
- Preserves stability, provides robustness, and supports portability.
- It is a highly time-tested approach.
Disadvantages
- Data overhead and processing problems due to duplication of functionality across layers.
- More layers mean more risks of system breakdown or data loss.
- Can result in sluggish operation modes, especially for user-intensive applications.
- Issues often arise regarding communication between higher vs. lower layers.
Data & Component-Level Design
Bridging the gap between high-level architecture and detailed procedural logic
1. Data Design
Data design transforms the information domain into the actual data structures required to implement the software. It is considered at two distinct levels of the software engineering process: the architectural level and the component level.
At the Architectural Level
The main challenge is extracting useful information from a cross-functional data environment.
- Data Mining (KDD): Knowledge Discovery in Databases (KDD) techniques navigate through existing databases to extract business-level info.
- Data Warehouse: Because multiple databases with different structures make mining difficult, businesses add a "Data Warehouse"—an independent data environment that encompasses all business data without interfering with day-to-day applications.
At the Component Level
Focuses on the specific data structures required to manipulate data objects within a single component.
- Refines data objects and develops data abstractions.
- Implements data object attributes as specific data structures.
- Reviews structures to ensure appropriate relationships are established.
Key Principles for Data Specification
- All data structures and their operations must be identified early.
- A Data Dictionary should be established to define both data and program design.
- Low-level design decisions should be deferred until late in the design process.
- Data structure representations should be hidden, known only to the modules that directly use them (Information Hiding).
2. Component-Level Design
Also known as procedural design, this occurs after data, architectural, and interface designs are established. Its intent is to translate the high-level design model into a low-level, operational software abstraction. A component is a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.
There are two primary approaches to Component-Level Design:
Function-Oriented Approach
The system is viewed as something that performs a set of functions. Starting from a high-level view, functions are successively refined into detailed sub-functions.
Centralized State:
The system state (memory/data) is centralized and shared among different functions. E.g., global data like employee records are modified by separate update or delete functions.
How it groups:
Groups functions together if they constitute a higher-level overarching function.
Object-Oriented Approach
The system is viewed as a collection of interacting real-world entities (objects) like "employee", "machine", or "picture".
Decentralized State:
State information is distributed among the objects. Each object strictly manages its own internal data/state. Functions in one object cannot directly change the data of another object.
How it groups:
Groups functions together based strictly on the data they operate on. Objects communicate conceptually via message passing.
User Interface (UI) Design
Creating an effective communication medium between a human and a computer
The goal of UI design is to identify interface objects and actions, and then create a screen layout that forms the basis for a user interface prototype.
The 3 Design Rules for User Interfaces
1. Place the User in Control
- Flexible Interaction: Do not force a user into undesired actions. Provide choices like keyboard, mouse, touch, or voice controls.
- Interruptible: Users should be able to interrupt a sequence to do something else or undo their actions.
- Hide Internals: The user should not be aware of the underlying operating system or file management.
- Direct Interaction: Let users manipulate on-screen objects just like they would physical things.
2. Reduce the User's Memory Load
The more a user has to remember, the more error-prone the interaction will be.
- Reduce Short-term Demand: The interface should not require users to remember past actions or inputs.
- Meaningful Defaults: Provide sensible starting defaults, but always include a 'reset' option.
- Intuitive Shortcuts: Tie mnemonics (keyboard shortcuts) to actions in a way that is easy to remember.
- Progressive Disclosure: Organize information hierarchically, showing high-level information first before diving into details.
3. Make the Interface Consistent
- Provide Context: Always provide indicators so the user knows exactly where they are within the complex layers of the application.
- Family Consistency: A set of applications should all implement the exact same design rules.
- Respect Expectations: Do not change standard interactive models unless there is a highly compelling reason to do so.
The 4 User Interface Design Models
The role of the interface designer is to merge these four different models into one consistent interface.
1. User Profile Model
Created by: Human Engineer / Software Engineer
Establishes the profile of the end-users based on age, gender, education, and skills. Users are categorized into three levels:
- Novices: Little semantic knowledge of the application.
- Knowledgeable Intermittent: Reasonable knowledge but low recall of exact syntax.
- Knowledgeable Frequent: "Power users" who look for shortcuts.
2. Design Model
Created by: Software Engineer
Derived from the initial analysis model. It incorporates the data, architectural, interface, and procedural representations of the software.
3. Implementation Model
Created by: Software Implementers
Consists of the actual "look and feel" of the interface combined with supporting info (books, videos, help files). It strives to perfectly agree with the user's mental model.
4. User's Mental Model
Created by: The End User
Often called the "user's system perception". This is the image of the system that users naturally carry in their heads, based on their profile and overall familiarity with similar software.
Unified Modeling Language (UML)
The standard language for drawing the blueprints of software before you write the code.
Introduction: What is UML?
UML is not a programming language. It is a visual language made of standard shapes and arrows used to map out how a software system will work. You wouldn't build a skyscraper without architectural blueprints; you shouldn't build complex software without UML diagrams.
There are 14 types of UML diagrams, but they all fall into two main buckets:
- Structural Diagrams (The Skeleton): Show the static parts of the system. What things exist and how they are related. (Examples: Class, Component, Deployment diagrams).
- Behavioral Diagrams (The Muscle): Show the dynamic parts of the system. What happens over time and how things move. (Examples: Use Case, Sequence, Activity diagrams).
Use Case Diagram (Behavioral)
A Use Case Diagram is usually the very first diagram drawn in a project. It treats the entire system as a "black box" and only cares about Who is using it, and What they can do with it.
The 4 Core Components:Anyone (or any external system) that interacts with your software. (e.g., Customer, Admin, Bank API). Drawn as a stick figure.
A specific feature or action the Actor can perform. (e.g., "Login", "Checkout"). Drawn as a horizontal oval.
A large box drawn around all the Use Cases. Actors stay completely outside the box. It defines the scope of what you are actually building.
A solid straight line connecting an Actor to a Use Case, showing they participate in that action.
The Trickiest Part: <<include>> vs <<extend>>
Sometimes Use Cases relate to each other using dashed arrows. This confuses everyone, but it's actually very simple:
Used when a Use Case must execute another Use Case to finish its job. It is a required sub-task.
"Checkout" - - - <<include>> - - > "Process Payment"
💡 You literally cannot checkout without processing a payment.
Used when a Use Case might trigger another Use Case under specific conditions. It is optional or conditional.
"Login" < - - - <<extend>> - - - "Show Error Message"
💡 You only show an error message IF they type the wrong password. Notice the arrow points backwards to the base use case!
Class Diagram (Structural)
If the Use Case diagram shows what the system does, the Class Diagram shows what the system is made of. It is the most important structural diagram in UML, serving as the actual dictionary and blueprint that programmers use to write object-oriented code (like Java, C++, or Python).
The Anatomy of a Class Box
A class is always drawn as a rectangle divided into three horizontal compartments:
- email: String
# password: Hash
+ logout()
- resetPassword()
User, BankAccount).
visibility name: type.
().
Notice the +, -, and # symbols in the box above? They tell the programmer who is allowed to access that data:
Class Relationships (The Arrows)
Classes don't exist in isolation. They interact. The type of line connecting them defines their relationship. This is highly tested in exams.
An "Is-a" relationship. A child class inherits everything from a parent class. Drawn as a solid line with a hollow triangle pointing to the parent.
💡 Example: A Car (child) ────▷ Vehicle (parent).
A basic "Knows-a" or "Uses-a" relationship. Two classes communicate, but neither owns the other. Drawn as a simple solid line.
💡 Example: A Patient ──────── a Doctor. They interact, but exist independently.
A "whole-part" relationship, but the parts can exist on their own if the whole is destroyed. Drawn with a hollow diamond pointing to the "whole".
💡 Example: A University ◇───── Professor. If the university closes, the professors still exist and can get jobs elsewhere.
A strict "whole-part" relationship. If the whole is destroyed, the parts are destroyed with it. Drawn with a solid black diamond.
💡 Example: A House ◆───── Room. If you demolish the house, the rooms instantly cease to exist.
Sequence Diagram (Behavioral)
While a Class diagram shows the static structure, a Sequence Diagram shows how objects talk to each other over time. It reads like a script for a play.
A dashed vertical line dropping down from an object. It represents the lifespan of that object during the process.
A thin rectangle drawn on the lifeline. It shows exactly when the object is busy processing something.
A solid line with a solid arrow. The sender stops and waits for a response (e.g., calling a normal function).
A dashed line pointing backward. Shows the answer or data being sent back to the original caller.
Activity Diagram (Behavioral)
Think of this as an advanced flowchart on steroids. It models the flow of control from one activity to another, and unlike basic flowcharts, it is specifically designed to handle parallel (concurrent) processes.
A solid black circle marks the start. A bullseye marks the end.
A rounded rectangle representing a single step or task.
Splits the flow based on a condition (e.g., [Valid] or [Invalid]).
The superpower of Activity Diagrams is showing things happening at the same time. This is done using a heavy black line (Synchronization Bar).
Splits a single process into two or more concurrent processes. (e.g., An order is placed: one thread charges the card, while a parallel thread starts packing the box).
Waits for all parallel processes to finish before moving forward. (e.g., Wait for both payment AND packing to finish before shipping the box).
Study Guide Complete! 🚀
You have successfully mapped out the Data Warehouse & Mining syllabus (Clustering) and the core Software Engineering UML module. Good luck on the exam!