Structured Chart

Understanding
Structured charts

Definition:

A structured chart is a diagram that visually represents the hierarchy and organization of modules or
components within a system. It is used in system analysis and design to break down complex processes
into smaller, manageable modules, illustrating the relationships and flow between them.

Purpose of structured charts:

Organize Complex Systems: Simplifies complex processes by dividing them into smaller, logical modules.

Clarify Hierarchies: Establishes a clear top-down hierarchy, making it easier to understand dependencies
and roles of each component.
Enhance Design Efficiency: Aids in planning, troubleshooting, and optimizing the system's structure
before implementation.
Application of structured chart:

Software Development: Used to plan and design software systems by showing module
functions and their relationships.

Business Process Modeling: Helps visualize workflows and improve efficiency in business
processes.

System Documentation: Acts as a reference for developers, project managers, and

stakeholders throughout the lifecycle of a project.

Education and Training: Assists in explaining complex systems to new team members or
students.
 Importance of structured
chart
SIMPLIFIES COMPLEX SYSTEMS:
BREAKS DOWN LARGE SYSTEMS INTO MANAGEABLE MODULES, MAKING COMPLEX SYSTEMS EASIER TO UNDERSTAND AND
ANALYZE.

ENHANCES SYSTEM ORGANIZATION:

CLEARLY DEFINES HIERARCHICAL RELATIONSHIPS, SHOWING HOW MODULES INTERACT AND DEPEND ON ONE ANOTHER.

IMPROVES COMMUNICATION AND COLLABORATION:

PROVIDES A SHARED VISUAL REFERENCE THAT HELPS TEAM MEMBERS AND STAKEHOLDERS UNDERSTAND SYSTEM
STRUCTURE AND WORKFLOW.

FACILITATES EFFICIENT DEVELOPMENT AND MAINTENANCE:

IDENTIFIES DEPENDENCIES AND POTENTIAL ISSUES EARLY, SUPPORTING SMOOTHER DEVELOPMENT, TROUBLESHOOTING, AND
FUTURE UPDATES.

SUPPORTS EFFECTIVE DOCUMENTATION:

SERVES AS A USEFUL DOCUMENT THAT OUTLINES THE STRUCTURE, FUNCTION, AND ORGANIZATION OF A SYSTEM, AIDING IN
TRAINING AND FUTURE REFERENCE.
 key componet of structural chart
• MODULES:
THESE ARE THE SMALL PARTS OF THE SYSTEM. EACH MODULE HAS A SPECIFIC JOB, MAKING IT
EASIER TO MANAGE AND UNDERSTAND THE WHOLE SYSTEM. THINK OF MODULES LIKE TEAM
MEMBERS, EACH WITH THEIR OWN ROLE.
• HIERARCHY:
THIS SHOWS THE STRUCTURE OF THE MODULES, ARRANGED IN LEVELS LIKE A FAMILY TREE.
HIGHER-LEVEL MODULES (PARENT MODULES) CONTROL OR DIRECT LOWER-LEVEL ONES (CHILD
MODULES), WHICH HELPS ORGANIZE THE WORKFLOW AND KEEPS THINGS CLEAR.
• CONTROL FLOW:
CONTROL FLOW USES ARROWS TO SHOW THE SEQUENCE OF OPERATIONS BETWEEN MODULES,
INDICATING WHICH PART OF THE SYSTEM RUNS FIRST, SECOND, AND SO ON. THIS HELPS TO
UNDERSTAND THE OVERALL PROCESS AND ORDER OF TASKS IN THE SYSTEM.
• DATA FLOW:
DATA FLOW LINES SHOW HOW INFORMATION MOVES BETWEEN MODULES, DISPLAYING WHAT
DATA IS PASSED, RECEIVED, OR SHARED. THIS MAKES IT CLEAR HOW EACH PART
COMMUNICATES AND WHAT DATA IT NEEDS TO DO ITS JOB.
• COUPLING:
COUPLING SHOWS THE LEVEL OF DEPENDENCY BETWEEN MODULES. LOWER
COUPLING MEANS THE MODULES ARE MORE INDEPENDENT OF EACH OTHER, WHICH
IS USUALLY BETTER, AS IT ALLOWS FOR EASIER CHANGES OR UPDATES IN ONE PART
WITHOUT AFFECTING OTHERS.
• COHESION:
COHESION MEASURES HOW FOCUSED EACH MODULE IS ON ITS ASSIGNED TASK. HIGH
COHESION MEANS THE MODULE HAS A SINGLE, CLEAR PURPOSE, WHICH MAKES THE
SYSTEM EASIER TO MAINTAIN AND UNDERSTAND BECAUSE EACH PART HAS ITS OWN
WELL-DEFINED ROLE.
 Types of module in structural chart
PRIMITIVE MODULES
THESE ARE THE BASIC, FOUNDATIONAL MODULES THAT DO NOT BREAK DOWN INTO SMALLER COMPONENTS. THEY PERFORM SIMPLE,
WELL-DEFINED TASKS (E.G., CALCULATIONS, SIMPLE INPUT/OUTPUT OPERATIONS).
EXAMPLE: A MODULE THAT PERFORMS ADDITION.
• COMPOSITE MODULES
THESE MODULES ARE MADE UP OF MULTIPLE SMALLER SUB-MODULES OR PRIMITIVE MODULES. THEY HANDLE MORE COMPLEX TASKS
BY COMBINING SIMPLER OPERATIONS.
EXAMPLE: A MODULE THAT HANDLES DATA INPUT, VALIDATION, AND STORAGE.
• CONTROL MODULES
THESE MODULES CONTROL THE FLOW OF THE SYSTEM, SUCH AS DECISION-MAKING OR CONTROLLING THE EXECUTION OF OTHER
MODULES. THEY DON'T DIRECTLY PERFORM OPERATIONS BUT MANAGE HOW THE SYSTEM WORKS.
EXAMPLE: A MODULE THAT CHECKS CONDITIONS AND DECIDES WHETHER TO CONTINUE PROCESSING OR EXIT.
• INTEGRATION MODULES
THESE MODULES HELP CONNECT DIFFERENT MODULES OR PARTS OF THE SYSTEM, MAKING SURE THEY WORK TOGETHER. THEY MANAGE
COMMUNICATION BETWEEN OTHER MODULES.
EXAMPLE: A MODULE THAT INTEGRATES THE INPUT MODULE WITH A PROCESSING MODULE, PASSING DATA BETWEEN THEM.
• INTERFACE MODULES
THESE MODULES HANDLE THE INTERACTION BETWEEN THE SYSTEM AND EXTERNAL SYSTEMS OR USERS. THEY ACT AS THE "INTERFACE"
FOR COMMUNICATION.
EXAMPLE: A USER INTERFACE (UI) MODULE THAT COLLECTS USER INPUT AND DISPLAYS RESULTS.
 Steps in Designing a Structure Chart

Define the System Requirements: Identify what the system needs to

achieve, its major functionalities, and how users will interact with it.
Identify Major Modules: Based on system functions, break down the
requirements into high-level modules. Each module should represent a
major function or component of the system.
Decompose Each Module into Submodules: Further break down each
major module into submodules, representing specific tasks or sub-
functions within that module.
Determine Data Flow and Control Flow: Identify the flow of data
between modules and the control signals that will trigger actions or
coordinate modules.
Create the Hierarchical Layout: Arrange the modules in a top-down
hierarchy, connecting modules with arrows for data flow and dashed
lines for control flow.
 Example of structure chart
Case Study: Online Movie Booking System
Modules:
1. User Management
2. Movie Catalog
3. Booking System
4. Payment Gateway
Control Flow:
The main module controls the user interactions.
Data is passed to submodules for booking, payments, and notifications.
Data Flow:
Data coupling between modules ensures secure transaction information
and booking details transfer.
Loops and Conditions:
Loops for checking seat availability.
Conditions for payment success/failure and booking confirmation.
 benefit of structural charts
in software development
CLEAR VISUALIZATION OF SYSTEM ARTITECTURE:
A STRUCTURAL CHART PROVIDES A VISUAL REPRESENTATION OF THE SYSTEM’S COMPONENTS AND THEIR RELATIONSHIPS,
MAKING IT EASIER TO UNDERSTAND COMPLEX SOFTWARE STRUCTURES.

IMPROVED COMMUNICATION:
IT SERVES AS A COMMON REFERENCE FOR TEAM MEMBERS, STAKEHOLDERS, AND NEW DEVELOPERS, IMPROVING
COLLABORATION AND REDUCING MISUNDERSTANDINGS.

ENHANCED MAINTENANCE AND SCALABILITY:

BY OUTLINING THE ORGANIZATION OF CODE AND MODULES, IT HELPS IN IDENTIFYING DEPENDENCIES, FACILITATING EASIER
UPDATES, AND ENSURING BETTER SCALABILITY OF THE SOFTWARE.

BETTER RISK MANAGEMENT:

EARLY IDENTIFICATION OF CRITICAL COMPONENTS OR POTENTIAL BOTTLENECKS ALLOWS FOR PROACTIVE RISK MITIGATION
IN THE DEVELOPMENT PROCESS.
 limitations of structural chart

•LACKS DETAILED BEHAVIOR REPRESENTATION :

STRUCTURAL CHARTS FOCUS ON THE SYSTEM'S ARCHITECTURE BUT DO NOT SHOW HOW COMPONENTS INTERACT OR
THE FLOW OF DATA AND PROCESSES, LIMITING INSIGHTS INTO SYSTEM BEHAVIOR.

•CAN BECOME COMPLEX :

FOR LARGE SYSTEMS, STRUCTURAL CHARTS CAN BECOME OVERLY COMPLEX AND HARD TO READ, MAKING IT DIFFICULT
TO TRACK ALL COMPONENTS AND RELATIONSHIPS.

•STATIC VIEW :
THEY TYPICALLY REPRESENT A STATIC VIEW OF THE SYSTEM, FAILING TO CAPTURE DYNAMIC CHANGES SUCH AS
RUNTIME INTERACTIONS OR EVOLVING SYSTEM STATES.

•DOESN’T ADDRESS NON-FUNCTIONAL ASPECTS :

STRUCTURAL CHARTS DO NOT HIGHLIGHT IMPORTANT NON-FUNCTIONAL REQUIREMENTS LIKE PERFORMANCE,
SECURITY, OR SCALABILITY CONCERNS.
thank you for your
attention!