Coursify

SOFTWARE ENGINEERING

Data-Oriented, Structured, and Object-Oriented Design

This section covers major design paradigms including data-oriented design, structured design techniques, object-oriented design principles, modular structuring, packaging, and decomposition approaches such as top-down and bottom-up design.

Learning Goals

  • Explain the principles of data-oriented software design and relate data structures to system decomposition decisions.
  • Create and interpret a structure chart that represents module hierarchy, control relationships, and data movement.
  • Measure and classify coupling between modules and recommend design changes to reduce unnecessary interdependence.
  • Measure and classify cohesion within modules and redesign components to improve functional focus.
  • Compare object-oriented design with structured design in terms of abstraction, modularity, reuse, and maintainability.

Software design translates requirements and analysis models into implementable structures: modules, data representations, interfaces, and control relationships. In this section, we compare three influential design viewpoints:

  1. Data-oriented design emphasizes the shape, movement, and locality of data; it is especially relevant when performance, throughput, cache behavior, and batch processing matter.
  2. Structured design transforms analysis artifacts such as data-flow diagrams into a hierarchy of modules, often represented by a structure chart.
  3. Object-oriented design organizes software around objects, classes, encapsulation, inheritance, and polymorphic collaboration, with strong support for abstraction, reuse, and maintainability in complex domains.

A skilled software engineer does not treat these as mutually exclusive ideologies. Instead, design decisions should be justified by the expected change patterns, data access patterns, module responsibilities, and maintainability goals of the system.

Footnotes

  1. Data-Oriented Design - Games from Within - Explains data-oriented design, contiguous data layout, cache utilization, and transformation-focused thinking. ↩

  2. Function-Oriented Software Design - NPTEL - Describes structured design, structure charts, transform analysis, transaction analysis, and mapping DFDs to module structures. ↩

  3. Difference between Structured and Object-Oriented Analysis - GeeksforGeeks - Compares structured and object-oriented approaches, including objects, classes, modularity, reuse, and maintainability. ↩

  4. Cohesion and Coupling in Software with Examples - Provides practical explanations of coupling, cohesion, module boundaries, and change propagation. ↩

Cohesion and Coupling in Software Engineering

1. Data-Oriented Design: Decomposing Around Data

Data-oriented design begins with a practical question: what data does the system transform, how often, and in what order? Unlike designs that begin primarily with nouns or procedures, data-oriented design studies data layout, access patterns, and transformation pipelines.

In performance-sensitive systems, data layout affects memory behavior. Contiguous arrays, reduced indirection, smaller records, and separation of frequently used fields can improve cache locality and reduce unnecessary memory traffic. Research on cache-conscious data structures identifies techniques such as clustering related elements, compressing representations, and separating hot from cold data to improve spatial and temporal locality.

A data-oriented decomposition asks:

Design QuestionData-Oriented InterpretationDesign Consequence
What data changes together?Group fields that are updated in the same processing pass.Create modules around transformation stages.
What data is read frequently?Keep high-frequency fields compact and close.Avoid passing large records when only a few fields are needed.
What data is independent?Separate independent streams.Enable parallelism and simpler testing.
What data must be preserved?Define stable storage boundaries.Isolate persistence from computation.
What data is derived?Treat it as output of a transformation.Avoid redundant mutable state.

A classic example is replacing an array of objects with separate arrays of fields when the computation repeatedly touches only a subset of the fields. This is often called a shift from array-of-structures to structure-of-arrays.

This decomposition is still modular, but the module boundaries follow data movement and transformation stages rather than only user-visible features or real-world entities.

Footnotes

  1. Data-Oriented Design - Games from Within - Explains data-oriented design, contiguous data layout, cache utilization, and transformation-focused thinking. ↩ ↩2 ↩3

  2. Making Pointer-Based Data Structures Cache Conscious - Discusses clustering, coloring, compression, and cache-conscious data-structure design principles. ↩

Design from the Data When Throughput Matters

If a system repeatedly processes large collections, begin by identifying the dominant data paths, access frequency, and transformation stages. This often reveals better module boundaries than starting from class names alone.

Footnotes

  1. Data-Oriented Design - Games from Within - Explains data-oriented design, contiguous data layout, cache utilization, and transformation-focused thinking. ↩

1EmployeeRecord[] employees
2  employee.name
3  employee.department
4  employee.salary
5  employee.taxCode
6  employee.benefitsPlan

Useful when operations need whole employee objects and behavior is naturally attached to each entity.

Footnotes

  1. Difference between Structured and Object-Oriented Analysis - GeeksforGeeks - Compares structured and object-oriented approaches, including objects, classes, modularity, reuse, and maintainability. ↩

2. Structured Design and Structure Charts

Structured design is a function-oriented approach that commonly transforms a data-flow representation into a module hierarchy. Its central artifact is the structure chart, which represents software architecture by showing:

  • modules and submodules;
  • which module calls which other module;
  • data passed between modules;
  • control information passed between modules;
  • selection, repetition, and storage relationships where relevant.2

A structure chart is not the same as a flowchart. A flowchart emphasizes execution sequence inside an algorithm, while a structure chart emphasizes program organization, decomposition, and intermodule relationships.

In a full structure chart, arrows may distinguish data couples from control couples. Many notations show data flow with an open circle and control flow with a filled circle.

Footnotes

  1. Function-Oriented Software Design - NPTEL - Describes structured design, structure charts, transform analysis, transaction analysis, and mapping DFDs to module structures. ↩ ↩2 ↩3

  2. Structure Charts - Software Engineering - GeeksforGeeks - Defines structure charts and common symbols for modules, conditional calls, loops, data flow, and control flow. ↩ ↩2

Creating a Structure Chart from an Analysis Model

  1. 1
    Step 1

    Define the major input data, output data, external actors, files, and devices. This establishes what the design must transform or coordinate.

    Footnotes

    1. Function-Oriented Software Design - NPTEL - Describes structured design, structure charts, transform analysis, transaction analysis, and mapping DFDs to module structures. ↩

  2. 2
    Step 2

    Determine whether the system resembles transform flow, where inputs are converted into outputs through a central transform, or transaction flow, where an input transaction selects one of several action paths.

    Footnotes

    1. Function-Oriented Software Design - NPTEL - Describes structured design, structure charts, transform analysis, transaction analysis, and mapping DFDs to module structures. ↩

  3. 3
    Step 3

    For transform flow, separate afferent input processing, central transformation, and efferent output processing. This helps derive the first-level module hierarchy.

    Footnotes

    1. Function-Oriented Software Design - NPTEL - Describes structured design, structure charts, transform analysis, transaction analysis, and mapping DFDs to module structures. ↩

  4. 4
    Step 4

    Draw a root module that coordinates the major subordinate modules. The root should manage sequencing and delegation, not contain detailed business rules.

    Footnotes

    1. Function-Oriented Software Design - NPTEL - Describes structured design, structure charts, transform analysis, transaction analysis, and mapping DFDs to module structures. ↩

  5. 5
    Step 5

    Create lower-level modules for reading, validating, transforming, storing, and reporting. Use factoring to avoid large modules with excessive responsibilities.

    Footnotes

    1. Function-Oriented Software Design - NPTEL - Describes structured design, structure charts, transform analysis, transaction analysis, and mapping DFDs to module structures. ↩

  6. 6
    Step 6

    Annotate what data moves between modules and which control flags influence decisions. Data movement should be explicit enough to evaluate coupling.

    Footnotes

    1. Structure Charts - Software Engineering - GeeksforGeeks - Defines structure charts and common symbols for modules, conditional calls, loops, data flow, and control flow. ↩

  7. 7
    Step 7

    Split modules with unrelated responsibilities, merge modules that communicate excessively, replace control flags with clearer interfaces, and remove unnecessary global data.

    Footnotes

    1. Cohesion and Coupling in Software with Examples - Provides practical explanations of coupling, cohesion, module boundaries, and change propagation. ↩

Do Not Confuse Control Hierarchy with Runtime Sequence

A structure chart shows which modules call or control other modules. It is primarily an architectural decomposition view, not a detailed statement-by-statement execution flowchart.

Footnotes

  1. Function-Oriented Software Design - NPTEL - Describes structured design, structure charts, transform analysis, transaction analysis, and mapping DFDs to module structures. ↩

3. Interpreting a Structure Chart

To interpret a structure chart, read it from top to bottom:

  1. The root module represents the system or subsystem controller.
  2. Children represent subordinate modules called by the parent.
  3. Sibling modules often represent alternative or sequential responsibilities.
  4. Data arrows indicate information passed through interfaces.
  5. Control arrows indicate flags, status values, or commands that affect another module’s internal path.

Consider this simplified textual structure chart for a student grading subsystem:

Interpretation:

Chart ElementMeaningDesign Concern
Grade Submission ControllerCoordinates the workflow.Should avoid detailed grade calculations.
Validate Grade EntriesGroups validation responsibilities.Should be cohesive around validation.
Calculate Final GradesPerforms core transformation.Should receive only required grade data.
Publish ResultsHandles output and side effects.Should isolate storage and notification concerns.

A structure chart is useful because it exposes fan-out, fan-in, and interface complexity. Excessive fan-out can indicate an overloaded controller, while high fan-in may indicate a reusable service or, if poorly designed, a hidden dependency hotspot.

Footnotes

  1. Structure Charts - Software Engineering - GeeksforGeeks - Defines structure charts and common symbols for modules, conditional calls, loops, data flow, and control flow. ↩

  2. Function-Oriented Software Design - NPTEL - Describes structured design, structure charts, transform analysis, transaction analysis, and mapping DFDs to module structures. ↩

Relative Coupling Risk by Coupling Type

Higher values indicate stronger interdependence and greater expected change ripple risk, based on common software engineering classifications of coupling.2

Footnotes

  1. Cohesion and Coupling in Software with Examples - Provides practical explanations of coupling, cohesion, module boundaries, and change propagation. ↩

  2. Coupling and Cohesion - Software Engineering - GeeksforGeeks - Summarizes coupling and cohesion classifications and their role in modular software design. ↩

4. Measuring and Classifying Coupling

Coupling measures how strongly one module depends on another. Good design generally seeks low coupling, because changes in one module are less likely to force changes elsewhere. Coupling is not always bad; modules must collaborate. The design goal is to make collaboration explicit, minimal, stable, and semantically meaningful.

A practical coupling metric can be expressed as:

C=en(n−1)C = \frac{e}{n(n-1)}

where ee is the number of directed intermodule dependencies and nn is the number of modules. This simple density measure does not capture semantic quality, but it helps identify designs with excessive dependency edges.

Common coupling categories include:2

Coupling TypeDescriptionExampleDesign Recommendation
Data couplingModules exchange only needed data values.computeTax(salary, taxCode)Usually acceptable. Keep interfaces small.
Stamp couplingA module receives a whole record but uses only part.Passing Employee when only salary is needed.Pass only required fields or introduce a smaller DTO.
Control couplingOne module passes a flag controlling another module’s logic.printReport(mode = "summary")Replace flags with separate operations or strategy objects.
External couplingModules depend on a shared external format, protocol, or device.Two modules depend on the same file schema.Encapsulate external details behind adapters.
Common couplingModules share global data.Multiple modules mutate globalConfig.Replace globals with dependency injection or immutable configuration.
Content couplingOne module directly accesses another’s internals.Module A modifies Module B’s private data.Eliminate; enforce interfaces and encapsulation.

The strongest warning signs are hidden dependencies: shared mutable global state, direct access to another module’s internals, and large structures passed casually across boundaries.

Footnotes

  1. Cohesion and Coupling in Software with Examples - Provides practical explanations of coupling, cohesion, module boundaries, and change propagation. ↩ ↩2 ↩3

  2. Coupling and Cohesion - Software Engineering - GeeksforGeeks - Summarizes coupling and cohesion classifications and their role in modular software design. ↩

Reducing Unnecessary Coupling

  1. 1
    Step 1

    List which modules call, read, write, instantiate, or configure other modules. Include shared data stores and external files because coupling can be indirect.

    Footnotes

    1. Cohesion and Coupling in Software with Examples - Provides practical explanations of coupling, cohesion, module boundaries, and change propagation. ↩

  2. 2
    Step 2

    Label each dependency as data, stamp, control, external, common, or content coupling. Prioritize common and content coupling because they create strong ripple effects.2

    Footnotes

    1. Cohesion and Coupling in Software with Examples - Provides practical explanations of coupling, cohesion, module boundaries, and change propagation. ↩

    2. Coupling and Cohesion - Software Engineering - GeeksforGeeks - Summarizes coupling and cohesion classifications and their role in modular software design. ↩

  3. 3
    Step 3

    Replace large record parameters with the specific values required. This converts stamp coupling into simpler data coupling.

    Footnotes

    1. Cohesion and Coupling in Software with Examples - Provides practical explanations of coupling, cohesion, module boundaries, and change propagation. ↩

  4. 4
    Step 4

    Split flag-driven procedures into separate operations, or use polymorphism, callbacks, command objects, or strategy objects when variation is intentional.2

    Footnotes

    1. Difference between Structured and Object-Oriented Analysis - GeeksforGeeks - Compares structured and object-oriented approaches, including objects, classes, modularity, reuse, and maintainability. ↩

    2. Cohesion and Coupling in Software with Examples - Provides practical explanations of coupling, cohesion, module boundaries, and change propagation. ↩

  5. 5
    Step 5

    Wrap files, databases, devices, and global state behind stable interfaces. This localizes external coupling and improves testability.

    Footnotes

    1. Cohesion and Coupling in Software with Examples - Provides practical explanations of coupling, cohesion, module boundaries, and change propagation. ↩

  6. 6
    Step 6

    Ask which modules must change if a data format, business rule, or output channel changes. A good redesign reduces the number of affected modules.

    Footnotes

    1. Cohesion and Coupling in Software with Examples - Provides practical explanations of coupling, cohesion, module boundaries, and change propagation. ↩

Content Coupling Is a Design Smell

If one module directly modifies another module’s internal data or branches into its internal logic, the modules are no longer independently understandable. Replace this with a stable interface.

Footnotes

  1. Cohesion and Coupling in Software with Examples - Provides practical explanations of coupling, cohesion, module boundaries, and change propagation. ↩

5. Measuring and Classifying Cohesion

Cohesion measures how tightly the responsibilities inside a module relate to one another. Good software design generally seeks high cohesion, because a cohesive module is easier to understand, test, reuse, and change.2

A practical cohesion review asks:

  • Does the module have one clear purpose?
  • Do all operations contribute to the same responsibility?
  • Do its internal data and functions change for the same reason?
  • Can the module be named precisely without using “and”?
  • Are unrelated temporal or technical tasks grouped together?

Common cohesion categories include:

Cohesion TypeRelative QualityDescriptionExample
Functional cohesionHighestAll elements contribute to one well-defined function.CalculateFinalGrade
Sequential cohesionHighOutput from one part becomes input to the next.Parse -> Validate -> Normalize
Communicational cohesionHighOperations use the same input or produce the same output.Build several views from one report dataset.
Procedural cohesionMediumElements are grouped because they occur in a sequence.Open file, read header, print banner.
Temporal cohesionLow-mediumElements are grouped because they occur at the same time.InitializeEverything
Logical cohesionLowSimilar category of operations selected by a flag.HandleInput(type)
Coincidental cohesionLowestUnrelated tasks grouped arbitrarily.UtilityMisc

A simple review metric is the responsibility count RR:

R=number of distinct reasons the module may changeR = \text{number of distinct reasons the module may change}

A module with R=1R = 1 is more cohesive than a module with R=5R = 5. Although this is qualitative, it encourages design around stable responsibilities and change reasons.

Footnotes

  1. Cohesion and Coupling in Software with Examples - Provides practical explanations of coupling, cohesion, module boundaries, and change propagation. ↩

  2. Coupling and Cohesion - Software Engineering - GeeksforGeeks - Summarizes coupling and cohesion classifications and their role in modular software design. ↩ ↩2

Improving Module Cohesion

  1. 1
    Step 1

    If the best name contains vague terms such as manager, helper, utility, or processor, inspect whether the module hides multiple responsibilities.

    Footnotes

    1. Cohesion and Coupling in Software with Examples - Provides practical explanations of coupling, cohesion, module boundaries, and change propagation. ↩

  2. 2
    Step 2

    Write each reason the module might change. Multiple unrelated reasons indicate weak cohesion and suggest decomposition.

    Footnotes

    1. Cohesion and Coupling in Software with Examples - Provides practical explanations of coupling, cohesion, module boundaries, and change propagation. ↩

  3. 3
    Step 3

    Keep functions together when they operate on the same essential data for the same business purpose. Separate functions that merely happen at the same time.2

    Footnotes

    1. Cohesion and Coupling in Software with Examples - Provides practical explanations of coupling, cohesion, module boundaries, and change propagation. ↩

    2. Coupling and Cohesion - Software Engineering - GeeksforGeeks - Summarizes coupling and cohesion classifications and their role in modular software design. ↩

  4. 4
    Step 4

    If a module selects unrelated behavior using type codes or mode flags, split the alternatives into distinct modules or polymorphic operations.2

    Footnotes

    1. Difference between Structured and Object-Oriented Analysis - GeeksforGeeks - Compares structured and object-oriented approaches, including objects, classes, modularity, reuse, and maintainability. ↩

    2. Coupling and Cohesion - Software Engineering - GeeksforGeeks - Summarizes coupling and cohesion classifications and their role in modular software design. ↩

  5. 5
    Step 5

    Sequential cohesion can be acceptable when each step transforms data for the next step, such as parse, validate, normalize, and store.

    Footnotes

    1. Coupling and Cohesion - Software Engineering - GeeksforGeeks - Summarizes coupling and cohesion classifications and their role in modular software design. ↩

  6. 6
    Step 6

    After splitting modules, ensure the new design does not introduce excessive coupling. Cohesion and coupling must be balanced.

    Footnotes

    1. Cohesion and Coupling in Software with Examples - Provides practical explanations of coupling, cohesion, module boundaries, and change propagation. ↩

Design Diagnosis: Coupling and Cohesion Cases

Design Review Roadmap for This Module

Analyze Data Movement

Stage 1

Identify core data structures, access frequency, transformations, and storage boundaries. Use data-oriented thinking where data volume or performance dominates.2"

Footnotes

  1. Data-Oriented Design - Games from Within - Explains data-oriented design, contiguous data layout, cache utilization, and transformation-focused thinking. ↩

  2. Making Pointer-Based Data Structures Cache Conscious - Discusses clustering, coloring, compression, and cache-conscious data-structure design principles. ↩

Derive Structured Decomposition

Stage 2

Map analysis flows into a structure chart showing module hierarchy, calls, and data/control couples.2"

Footnotes

  1. Function-Oriented Software Design - NPTEL - Describes structured design, structure charts, transform analysis, transaction analysis, and mapping DFDs to module structures. ↩

  2. Structure Charts - Software Engineering - GeeksforGeeks - Defines structure charts and common symbols for modules, conditional calls, loops, data flow, and control flow. ↩

Classify Coupling

Stage 3

Label dependencies as data, stamp, control, external, common, or content coupling. Prioritize removal of common and content coupling.2"

Footnotes

  1. Cohesion and Coupling in Software with Examples - Provides practical explanations of coupling, cohesion, module boundaries, and change propagation. ↩

  2. Coupling and Cohesion - Software Engineering - GeeksforGeeks - Summarizes coupling and cohesion classifications and their role in modular software design. ↩

Classify Cohesion

Stage 4

Evaluate whether each module has functional, sequential, communicational, procedural, temporal, logical, or coincidental cohesion."

Footnotes

  1. Coupling and Cohesion - Software Engineering - GeeksforGeeks - Summarizes coupling and cohesion classifications and their role in modular software design. ↩

Select Design Paradigm Mix

Stage 5

Use structured decomposition for clear workflows, object-oriented design for domain abstraction and reuse, and data-oriented design for transformation-heavy or performance-sensitive parts.2"

Footnotes

  1. Data-Oriented Design - Games from Within - Explains data-oriented design, contiguous data layout, cache utilization, and transformation-focused thinking. ↩

  2. Difference between Structured and Object-Oriented Analysis - GeeksforGeeks - Compares structured and object-oriented approaches, including objects, classes, modularity, reuse, and maintainability. ↩

6. Object-Oriented Design Compared with Structured Design

Object-oriented design and structured design both support modularity, but they choose different primary abstractions. Structured design decomposes a system into functions and module hierarchies; object-oriented design decomposes a system into interacting objects and classes that encapsulate state and behavior.2

DimensionStructured DesignObject-Oriented Design
Primary abstractionFunction, process, moduleObject, class, responsibility
Decomposition basisData flow, control hierarchy, transformationsDomain entities, collaborations, behavior ownership
Typical diagramStructure chart, data-flow diagramClass diagram, sequence diagram, object collaboration diagram
Encapsulation styleInterfaces between functional modulesData and behavior hidden behind object interfaces
Reuse mechanismReusable procedures and modulesClasses, interfaces, inheritance, composition, design patterns
Maintainability strengthClear procedural workflows and traceable transformationsLocalized domain behavior and extensible abstractions
RiskOverly procedural modules, global data, control flagsOvergeneralized class hierarchies, excessive indirection
Best fitBatch processing, transaction processing, well-defined transformationsComplex domains with evolving entities, rules, and collaborations

Object-oriented design supports abstraction by hiding implementation details behind classes and interfaces. Design pattern literature argues that recurring object-oriented structures can capture proven collaborations, improve documentation, and support reuse of successful designs. However, object-oriented designs can still suffer from low cohesion and high coupling if classes become “god objects,” inheritance is misused, or data movement is obscured by excessive indirection.2

Structured design remains valuable because many systems are naturally pipelines or transaction processors. A payroll batch, compiler phase, ETL workflow, or reporting subsystem may be clearer as a structured transformation. Conversely, an interactive domain such as hospital scheduling, banking accounts, or inventory management may benefit from object-oriented models that represent long-lived entities and business rules.

Footnotes

  1. Function-Oriented Software Design - NPTEL - Describes structured design, structure charts, transform analysis, transaction analysis, and mapping DFDs to module structures. ↩

  2. Difference between Structured and Object-Oriented Analysis - GeeksforGeeks - Compares structured and object-oriented approaches, including objects, classes, modularity, reuse, and maintainability. ↩ ↩2 ↩3

  3. Design Patterns: Abstraction and Reuse of Object-Oriented Design - Classic paper on design patterns as reusable object-oriented design structures that aid abstraction, documentation, and maintenance. ↩

  4. Cohesion and Coupling in Software with Examples - Provides practical explanations of coupling, cohesion, module boundaries, and change propagation. ↩

Use Paradigms as Design Lenses, Not Camps

A maintainable system may use object-oriented domain models, structured workflow controllers, and data-oriented internal representations in performance-critical loops. The best design is justified by change, data, and collaboration patterns.3

Footnotes

  1. Data-Oriented Design - Games from Within - Explains data-oriented design, contiguous data layout, cache utilization, and transformation-focused thinking. ↩

  2. Difference between Structured and Object-Oriented Analysis - GeeksforGeeks - Compares structured and object-oriented approaches, including objects, classes, modularity, reuse, and maintainability. ↩

  3. Cohesion and Coupling in Software with Examples - Provides practical explanations of coupling, cohesion, module boundaries, and change propagation. ↩

Comparative Strengths of Design Approaches

Illustrative comparison of typical strengths. Actual scores depend on domain, team skill, and implementation discipline.3

Footnotes

  1. Data-Oriented Design - Games from Within - Explains data-oriented design, contiguous data layout, cache utilization, and transformation-focused thinking. ↩

  2. Function-Oriented Software Design - NPTEL - Describes structured design, structure charts, transform analysis, transaction analysis, and mapping DFDs to module structures. ↩

  3. Difference between Structured and Object-Oriented Analysis - GeeksforGeeks - Compares structured and object-oriented approaches, including objects, classes, modularity, reuse, and maintainability. ↩

7. Integrated Example: Course Registration Subsystem

Suppose we are designing a course registration subsystem. A structured view might decompose the workflow into input validation, eligibility checking, seat assignment, fee calculation, and confirmation. An object-oriented view might model Student, CourseSection, Enrollment, PrerequisiteRule, and BillingAccount. A data-oriented view might optimize the seat-search operation by storing section capacities, enrolled counts, waitlist sizes, and time slots in compact arrays for fast filtering.3

Design interpretation:

  • Check Course Eligibility should be cohesive around academic rules.
  • Reserve Seat should not calculate tuition; otherwise cohesion weakens.
  • Passing an entire StudentProfile to Check Schedule Conflict may be stamp coupling if only enrolled time slots are needed.
  • A global currentRegistrationMode variable used by many modules would create common coupling.
  • An object-oriented PrerequisiteRule hierarchy may reduce control coupling by replacing rule-type flags with polymorphic behavior.2
  • A data-oriented section index may improve performance when thousands of sections are filtered repeatedly by capacity, time, campus, and program constraints.

A balanced design may therefore combine paradigms:

SubproblemRecommended LensRationale
Registration workflowStructured designThe process has clear ordered steps.
Academic rulesObject-oriented designRules vary and can be encapsulated.
Seat search and filteringData-oriented designEfficient access over many records matters.
ReportingStructured plus data-orientedReports often transform large datasets.
External payment gatewayObject-oriented adapterEncapsulates protocol and reduces external coupling.

Footnotes

  1. Data-Oriented Design - Games from Within - Explains data-oriented design, contiguous data layout, cache utilization, and transformation-focused thinking. ↩ ↩2

  2. Function-Oriented Software Design - NPTEL - Describes structured design, structure charts, transform analysis, transaction analysis, and mapping DFDs to module structures. ↩

  3. Difference between Structured and Object-Oriented Analysis - GeeksforGeeks - Compares structured and object-oriented approaches, including objects, classes, modularity, reuse, and maintainability. ↩ ↩2

  4. Cohesion and Coupling in Software with Examples - Provides practical explanations of coupling, cohesion, module boundaries, and change propagation. ↩

Common Misconceptions

8. Design Heuristics for Examinations and Practice

Use the following heuristics when answering software engineering design questions:

  1. Prefer high cohesion and low coupling. A module should have one strong reason to exist and minimal knowledge of other modules.
  2. Pass only necessary data. This reduces stamp coupling and keeps interfaces explicit.
  3. Avoid global mutable state. Shared globals create common coupling and unpredictable change ripple.2
  4. Replace control flags with clearer abstractions. Separate functions or polymorphic strategies usually improve cohesion and reduce control coupling.2
  5. Use structure charts for module hierarchy. Show controllers, subordinate modules, data movement, and control movement.2
  6. Let data structures influence decomposition. When data access dominates cost or complexity, organize modules around transformations and storage boundaries.2
  7. Choose OOD when domain behavior evolves. Encapsulated objects and design patterns can improve abstraction, reuse, documentation, and maintainability.2

A concise design evaluation checklist:

QuestionGood SignWarning Sign
What is the module’s purpose?One precise responsibilityVague “manager” or “utility”
What data crosses the boundary?Small, necessary parametersLarge records used partially
Who owns state?Encapsulated ownerShared mutable global state
How is variation handled?Polymorphism or separate operationsMode flags and switch logic
How are modules visualized?Structure chart with data/control couplesUnclear calls and hidden dependencies
How will change propagate?Localized changesRipple across many modules

Footnotes

  1. Cohesion and Coupling in Software with Examples - Provides practical explanations of coupling, cohesion, module boundaries, and change propagation. ↩ ↩2 ↩3

  2. Coupling and Cohesion - Software Engineering - GeeksforGeeks - Summarizes coupling and cohesion classifications and their role in modular software design. ↩ ↩2

  3. Difference between Structured and Object-Oriented Analysis - GeeksforGeeks - Compares structured and object-oriented approaches, including objects, classes, modularity, reuse, and maintainability. ↩ ↩2

  4. Function-Oriented Software Design - NPTEL - Describes structured design, structure charts, transform analysis, transaction analysis, and mapping DFDs to module structures. ↩

  5. Structure Charts - Software Engineering - GeeksforGeeks - Defines structure charts and common symbols for modules, conditional calls, loops, data flow, and control flow. ↩

  6. Data-Oriented Design - Games from Within - Explains data-oriented design, contiguous data layout, cache utilization, and transformation-focused thinking. ↩

  7. Making Pointer-Based Data Structures Cache Conscious - Discusses clustering, coloring, compression, and cache-conscious data-structure design principles. ↩

  8. Design Patterns: Abstraction and Reuse of Object-Oriented Design - Classic paper on design patterns as reusable object-oriented design structures that aid abstraction, documentation, and maintenance. ↩

Knowledge Check

Question 1 of 5
Q1Single choice

Which statement best describes data-oriented design?

Previous

Next