Software Design: Coupling and Cohesion

Coupling and Cohesion

• Fundamental concepts measuring the quality of a software system's design.

Coupling

• Measures how much software modules depend on each other.
• High coupling implies modules are tightly linked.
• Changes in one module often force changes in others with high coupling.
• High coupling increases complexity and reduces flexibility and modularity.
• Low coupling means modules are relatively independent.
• Changes in a module have minimal impact on others with low coupling.
• Low coupling aids in maintenance, updates, modularity, and scalability.

Types of Coupling (Best to Worst)

• Data Coupling: Modules communicate via simple data like numbers and strings.
• Stamp Coupling: Modules pass entire data structures, even if only part is needed.
• Control Coupling: One module tells another what to do using control information.
• External Coupling: Modules depend on external elements like hardware or libraries.
• Common Coupling: Multiple modules share global data, which is risky.
• Content Coupling: One module directly modifies another's internal workings, breaking encapsulation.
• Functional, Data-Structured, Temporal, and Sequential coupling types often overlap.

Cohesion

• Measures how well elements within a single module work together toward a single, well-defined purpose.
• High cohesion means all elements inside a module are closely related and contribute to one main task.
• High cohesion leads to easier understanding, error isolation, reliability, and reuse.
• Low cohesion describes elements within a module unrelated or performing multiple tasks, lacking focus.
• Low cohesion makes the module harder to understand, maintain, and reuse and can lead to duplication.

Types of Cohesion (Best to Worst)

• Functional Cohesion: All elements perform exactly one task.
• Sequential Cohesion: Output from one element is the input for the next.
• Communicational Cohesion: Elements operate on the same input data.
• Procedural Cohesion: Elements are grouped because they execute in a sequence.
• Temporal Cohesion: Elements are grouped because they execute within the same time frame.
• Logical Cohesion: Elements are grouped because they are logically related, operations might be different involving control flags.
• Coincidental Cohesion: Elements have no meaningful relationship.

Goal of Coupling and Cohesion

• Aim for Low Coupling and High Cohesion for a well-structured system.

Modular Programming

• A design approach dividing a program into smaller, independent, reusable modules.
• Each module performs a specific function and interacts through defined interfaces.
• Modular programming encourages high cohesion and low coupling.
• It allows parallel development, makes debugging easier,
• It introduces communication overhead, and complex interactions between modules can be challenging.
• Achieving the balance of cohesion/coupling can be hard, and it requiring careful dependency management.

Software Design Strategies

Structured Design

• Breaks down a system into a hierarchy of well-organized modules.
• Aims for high cohesion and low coupling through a top-down approach.
• The Waterfall Model is an example.
• It has a potential for lower reusability compared to Object-Oriented design.

Function-Oriented Design

• Composes the System of smaller functions, each performing a task through divide and conquer.
• It shares information (passing data or using global data) and focuses on processing steps.
• State changes caused by functions might be less central with top-down decomposition.
• It leads to Moderate reusability requiring a process of creating Data Flow Diagrams (DFDs).

Object-Oriented Design (OOD)

• Revolves around entities (objects) and their characteristics/behaviors using Abstraction, Encapsulation, Polymorphism, and Inheritance.
• Objects are instances of classes (generalized descriptions are stored as variables, functionalities, behavior).
• It uses a bottom-up approach with High reusability.
• It involves Modeling requirements, identifying objects, relationships, behaviors, and then designing class hierarchy and testing.

Software User Interface (UI) Design

• The front-end view is the interaction between the user and the computer.
• It should be attractive, simple, responsive, clear, and consistent.

Types of UI

• Command Line Interface (CLI) is text-based, uses fewer resources, but harder for beginners.
• Graphical User Interface (GUI) uses graphical elements, is more intuitive, and uses more resources.

Software Design Approaches

Top-Down Design (Stepwise Refinement)

• Starts with a high-level overview and breaks it down into detailed components through a hierarchical structure.
• It emphasizes algorithms/processing steps, system-level organization.

Bottom-Up Design

• Begins with low-level components/modules integrated into larger subsystems.
• It creates reusable components that enables early testing, while integration can be challenging.
• It emphasizes on data structures.

Hybrid Design

• Combines aspects of both top-down and bottom-up.
• Begins with high-level design while developing and testing low-level modules and balances system structure.

Software Reliability vs. Hardware Reliability

• Software Reliability is the probability that a software system will perform its functions correctly, depending on design faults.
• Fixing bugs increases reliability.
• Hardware Reliability is the probability that a hardware component will perform without failure, affected by manufacturing defects and wear.

Failure Rate Curves

• Hardware follows a Bathtub Curve (Burn-in -> Useful Life -> Wear out).
• Software is often depicted as decreasing over time. It is dependent on the life cycle of Testing, Useful Life and Obsolescence.

Failures and Faults

• A Fault (Bug/Defect) is a static error in code or design.
• A Failure is the dynamic, observable incorrect behavior when running, triggered under specific conditions.
• A fault exists which gets triggered, leading to a failure.
• Failures tracked by time of failure, time between failures, cumulative failures, and failures within a time interval.

Capability Maturity Model (CMM)

• Developed by the Software Engineering Institute (SEI) at Carnegie Mellon University.
• It enhances the organization's software development through improvement efforts, assessment and maturity of processes.
• Maturity is the degree of formality, optimization, and predictability of processes.

Levels of Maturity (Lowest to Highest)

• Initial (Ad-hoc): Processes are unpredictable.
• Repeatable (Basic Project Management): Processes track cost, schedule, and functionality based on past experience.
• Defined (Process Definition): Software processes documented, standardized, and integrated with training.
• Managed (Process Measurement): Organization sets quantitative quality goals; process is predictable.
• Optimizing (Process Control): Continuous process improvement; proactive defect prevention

Common Features Across Levels

• Commitment to perform, ability to perform, activities performed, measurement, analysis, and verifying implementation.

ISO 9001

• An international standard for a Quality Management System (QMS), applicable to many industries.
• ISO 9001 focuses on customer and regulatory requirements, consistency, satisfaction, and risk-based thinking.
• Its key aspects are a Process-based approach, Customer focus, Risk-based thinking, and Evidence-based decision making.
• It requires documentation, testing, and leadership commitment for software organizations.
• CMM is considered more detailed for software process improvement compared to ISO 9001.

Code Inspection and Walkthrough

• Methods of static software review (reviewing code/documents without executing them).

Walkthrough

• Informal, initiated by the author to get feedback.

Inspection

• Formal, rigorous, led by the project team/moderator.

Walkthrough vs Inspections

• Inspections use checklists, defined roles, and follow a stricter process.

Software Testing

• Executing a program to find errors, verifying and validating the software.
• Verification checks if the software meets specifications defined at the start of development.
• Validation checks if the software meets overall user requirements at the end of development.
• Testing shows the presence of defects and saves time and money.
• Defects cluster together (Pareto Principle: ~80% of errors come from ~20% of the code).
• Plan tests before starting and testing should be done by an independent party.

Types of Software Testing

Manual vs. Automation

• Manual tests are human-executed, good for exploratory testing and are less expensive.
• Automation tests are executed by software tools, faster and repeatable.

Testing Levels

• Unit Testing: Testing individual components in isolation (White-box).
• Integration Testing: Testing the interaction between integrated modules (White-box, Black-box, Gray-box).
• Incremental: Modules added one by one (Top-down, Bottom-up).
• Non-incremental (Big Bang): All modules integrated at once.
• System Testing: Testing the entire system against requirements (Black-box).
• Acceptance Testing: Testing by users to determine if the system meets their needs (Black-box).

Testing Approaches (Based on Code Visibility)

• White-Box Testing tests the internal structures using code paths and is thorough.
• Black-Box Testing tests functionality based on inputs against requirements using tests from a user perspective.
• Gray-Box Testing has partial knowledge of internal structure and combines white-box and black-box.

Why 100% Testing Isn't Possible (Exhaustive Testing)

• Vast number of possible inputs and paths, complex logical conditions, hidden bugs, and resource limitations.

Black-Box Testing Strategies

• Techniques to design test cases without knowing the internal code.

Boundary Value Analysis (BVA)

• Focuses on testing values at the boundaries of valid and invalid input ranges. Includes minimum, nominal, and maximum values.
• Best-Case: Tests boundaries and one nominal value per variable.
• Worst-Case: Tests all combinations of boundary values for all variables.
• Robust-Case: Includes values just outside the valid boundaries.
• Equivalence Class Partitioning (ECP): divides input data into partitions (classes). It makes the test cases cover representative values from each class.

Decision Table-Based Testing

• A table lists conditions and the corresponding actions, for systems with complex conditions.
• It helps ensure all combinations of conditions are considered.
• Cause-Effect Graphing is a graphical technique to represent the relationship between the causes and outputs.
• It uses logical operators to link causes and effects and derive test cases that are converted to decision tables.