Unit2 - Subjective Questions

Basic Principles of Software Design

Software design is the process of defining the architecture, components, interfaces, and other characteristics of a system or component. The fundamental principles include:

1. Abstraction: It permits one to concentrate on a problem at some level of generalization without regard to irrelevant low-level details.
   • Procedural Abstraction: A sequence of instructions that have a specific and limited function.
   • Data Abstraction: A named collection of data that describes a data object.
2. Refinement: This is the process of elaboration. It begins with a statement of function (high abstraction) and decomposes it into detailed commands (low abstraction).
3. Modularity: The software is divided into separately named and addressable components, called modules, that are integrated to satisfy problem requirements.
4. Information Hiding: This principle suggests that modules should be specified and designed so that information (algorithms and data) contained within a module is inaccessible to other modules that have no need for such information.

Contribution to Robust Design:

• Abstraction reduces complexity by allowing designers to focus on high-level logic.
• Information Hiding ensures that changes in one module (e.g., changing an internal algorithm) do not propagate errors to other parts of the software, thereby improving maintainability.

Modularity

Modularity is a design concept that separates the functionality of a program into independent, interchangeable methods or distinct elements called modules. A modular system consists of discrete components that work together.

Benefits of Modular Design

1. Manageability: Complex software becomes easier to manage when broken down into smaller pieces.
2. Parallel Development: Different modules can be developed by different teams simultaneously.
3. Reusability: A module designed for one system can often be reused in another (e.g., a math library).
4. Testability: Modules can be tested independently (Unit Testing) before integration.
5. Maintainability: Errors are localized to specific modules, making debugging and fixing easier without affecting the entire system.

Difference between Cohesion and Coupling

Why High Cohesion and Low Coupling?

• High Cohesion ensures that a module performs a single, well-defined task. This makes the module easier to understand and robust.
• Low Coupling minimizes the 'ripple effect'. If two modules are loosely coupled, a change in one is less likely to break the other. This significantly reduces maintenance costs and facilitates software evolution.

The types of cohesion, ordered from lowest (worst) to highest (best), are:

1. Coincidental Cohesion (Lowest): Parts of a module are grouped arbitrarily; the only relationship is that they reside in the same file.
2. Logical Cohesion: Elements are logically related (e.g., a module performing all input operations), but the specific activity is selected by control parameters.
3. Temporal Cohesion: Elements are grouped because they are processed at the same time (e.g., initialization routines).
4. Procedural Cohesion: Elements are grouped because they must be executed in a specific order.
5. Communicational Cohesion: Elements are grouped because they operate on the same external data (e.g., print and save the same record).
6. Sequential Cohesion: The output of one part of a module serves as the input to the next part.
7. Functional Cohesion (Highest): All elements of the module contribute to the execution of a single, specific task. This is the ideal level of cohesion.

Types of Coupling (Low/Good to High/Bad)

1. Data Coupling: Modules communicate by passing only necessary data items (parameters). This is the best form.
2. Stamp Coupling: Modules share a composite data structure (like a record or object), but may only use parts of it.
3. Control Coupling: One module controls the flow of another by passing control information (e.g., flags or switches).
4. Common Coupling: Multiple modules share global data areas. A change in the global data structure requires changes in all modules accessing it.
5. Content Coupling: One module directly modifies or accesses the internal data or code of another module.

Worst Type: Content Coupling

Content Coupling is the worst because it violates the principle of information hiding completely. If Module A changes Module B's internal data or jumps into the middle of Module B's code, any change in Module B implies a necessary change in Module A. This makes the system extremely difficult to maintain and debug.

Measuring Module Independence

Module independence is a key indicator of good design. It is achieved by developing modules with a "single-minded" function and an aversion to excessive interaction with other modules.

It is measured qualitatively using two criteria:

1. Cohesion: The degree to which a module performs one and only one function.
2. Coupling: The degree to which a module is connected to other modules.

The Relationship

The relationship can be conceptually represented as:

• Numerator (Cohesion): We want this to be high. When internal elements are strongly related, the module is self-contained.
• Denominator (Coupling): We want this to be low. When connections to the outside world are minimized, the module is not dependent on the implementation details of others.

Therefore, maximizing cohesion and minimizing coupling maximizes Module Independence.

Data Flow Diagram (DFD)

A DFD is a graphical representation that depicts the flow of data through an information system. It models the functions (processes) that the system performs and the data transformations.

DFD Symbols (Yourdon/DeMarco Notation)

1. Process (Circle/Bubble):

   • Represents a function or transformation that changes input data into output data.
   • Label: Verb-Object phrase (e.g., "Calculate Tax").

2. External Entity (Rectangle/Square):

   • Represents a source (producer) or destination (consumer) of data outside the system boundaries.
   • Label: Noun (e.g., "Customer", "Bank").

3. Data Store (Parallel Lines or Open-ended Rectangle):

   • Represents data at rest or a repository where data is saved for later use.
   • Label: Noun (e.g., "Inventory Database").

4. Data Flow (Arrow):

   • Represents the movement of data between processes, entities, and stores.
   • Label: Name of the data packet (e.g., "Order Details").

Leveling in DFDs

DFDs are hierarchical. Since complex systems cannot be represented in a single diagram, DFDs are decomposed into levels to represent increasing amounts of detail. This is known as leveling or "partitioning."

• Context Diagram (Level 0): The highest level view.
• Level 1 DFD: Explodes the main process from Level 0 into major sub-processes.
• Level 2 DFD: Explodes processes from Level 1 into detailed sub-processes.

Context Diagram (Level 0)

• It represents the entire software system as a single process (one bubble).
• It shows the interaction between the system and external entities (sources and sinks).
• It defines the scope and boundary of the system.
• It does not show data stores (unless they are external to the system) or internal logic.

Rules for Constructing DFDs

1. Process Inputs/Outputs: Every process must have at least one input and at least one output.
2. Data Store Interactions: Data cannot move directly from one data store to another; it must be moved by a process.
3. Entity Interactions: Data cannot move directly from an external entity to a data store (must go through a process).
4. Entity-to-Entity: Data cannot move directly between two external entities.
5. Conservation of Data: The outputs from a process must be derivable from its inputs.

Common Errors to Avoid

1. Black Hole: A process has inputs but no outputs.
2. Miracle: A process has outputs but no inputs (generates data from nothing).
3. Grey Hole: The inputs to a process are insufficient to produce the output (e.g., Input: Date of Birth, Output: Address).
4. Unlabeled Flows: Leaving data flow arrows without names.
5. Crossing Lines: While sometimes unavoidable, excessive crossing makes the DFD unreadable.

Structure Charts

A Structure Chart is a hierarchical diagram used in structured design to show the relationship between modules in a computer program. It depicts the modular structure and the call hierarchy.

Components and Notation

1. Module (Rectangle): Represents a named process or subroutine.
   • Root Module: The top-most module calling others.
   • Leaf Module: A module that does not call others.
2. Connection (Line/Arrow): An arrow connecting two modules indicates that one calls the other.
3. Data Couple (Arrow with empty circle ):
   • Represents data being passed between modules.
   • The arrow points in the direction of the data flow.
4. Control Couple (Arrow with filled circle ):
   • Represents control information (flags, status codes) being passed.
   • E.g., "End of File" flag.
5. Loop (Curved arrow crossing lines): Indicates that the subordinate modules are called iteratively.
6. Selection (Diamond): Indicates that a call to a subordinate module is conditional (If-Then-Else).

These are two strategies for converting a DFD into a Structure Chart.

Transform Analysis

• Usage: Used when the system's primary function is to transform input data into output data through a sequence of processing steps.
• Structure: Typically results in a structure with "Input", "Process" (Transform), and "Output" branches.
• Focus: It identifies the central transform (the heart of the processing) and structures the design around it.

Transaction Analysis

• Usage: Used when the system processes a single input item (a transaction) that triggers one of many possible distinct action paths.
• Structure: Results in a structure with a "Dispatcher" module that evaluates the transaction type and routes it to the specific worker module.
• Focus: It focuses on the "Transaction Center" where the path of execution splits based on the input type (e.g., a menu selection in an ATM system).

Steps for Transform Analysis

1. Review the Fundamental System Model: Understand the Level 0 (Context) diagram and Level 1 DFD.
2. Identify Incoming and Outgoing Flows: Trace the data flow from the external entities until the data is fully "internalized" (logical form) and identify where data begins to be formatted for output.
3. Identify the Center of Transform: The processes located between the incoming and outgoing boundaries constitute the "Central Transform" or "Main Processing."
4. Create the Structure Chart (First Level):
   • Create a root module (Controller).
   • Create three branches: Input leg (Afferent), Transform leg, and Output leg (Efferent).
5. Factor the Branches:
   • Afferent Branch: Map the input processes of the DFD to modules that "get" data.
   • Efferent Branch: Map the output processes to modules that "put" or "display" data.
   • Transform Branch: Map the central processing bubbles to modules.
6. Refine the Structure: Add Data Couples and Control Couples. Apply design heuristics (coupling/cohesion checks) to optimize.

Fan-in and Fan-out

• Fan-out: The number of modules directly controlled (called) by a specific module.

  • High Fan-out: Means a module controls many others. This can make the logic complex and difficult to maintain.
  • Low Fan-out: Generally preferred, but too low suggests inefficient delegation.
  • Recommendation: A Fan-out of 3 to 7 is generally considered optimal (similar to the "span of control" in management).

• Fan-in: The number of modules that call a specific module.

  • High Fan-in: Indicates that a module is reused by many other parts of the system (e.g., a utility function like calculateTax). This is generally good as it indicates code reuse.
  • Recommendation: High fan-in is desirable for utility modules, provided they have high cohesion.

Design Trade-offs

Design trade-offs occur when improving one quality attribute of a system degrades another. A designer must balance these conflicting requirements based on the project priorities.

Common Examples

1. Space vs. Time:
   • Scenario: Using a compression algorithm saves disk space (Space efficient) but requires CPU cycles to compress/decompress (Time inefficient).
2. Maintainability vs. Efficiency:
   • Scenario: Writing highly modular, abstract code makes it easy to maintain but might introduce slight performance overheads due to function calls and layers.
3. Security vs. Usability:
   • Scenario: Implementing Multi-Factor Authentication (MFA) increases security but adds friction for the user (lowers usability).
4. Reliability vs. Cost:
   • Scenario: Adding redundant servers increases reliability (fault tolerance) but significantly increases hardware costs.

Comparison: Function-Oriented vs. Object-Oriented Design

Software Design Document (SDD)

The SDD, also known as the Technical Design Document, is a representation of the software created to facilitate analysis, planning, implementation, and decision-making. It serves as the blueprint for the coding phase.

Key Components of SDD (IEEE Std 1016)

1. Introduction: Scope, purpose, and references.
2. System Overview: High-level architecture, design constraints, and trade-offs.
3. Data Design: Database structures, file formats, and data dictionary.
4. Architectural Design: Program structure, module hierarchy (Structure Charts), and interfaces.
5. Interface Design:
   • User Interface: Screen layouts.
   • External Interface: Interaction with other systems.
6. Procedural Design: Algorithms, logic for critical modules (often using pseudo-code or flowcharts).
7. Requirements Matrix: A trace matrix mapping design components back to SRS requirements to ensure coverage.

Design Review Techniques

Design reviews are quality assurance mechanisms to identify errors in the design phase before coding begins. Detecting errors here is significantly cheaper than in testing.

Walkthroughs vs. Inspections

Data Dictionary

A Data Dictionary is a centralized repository that provides detailed definitions of all data elements, data flows, and data stores represented in the Data Flow Diagrams (DFD).

Content

For a specific data item (e.g., "Customer Name"), it records:

• Name: The label used in the DFD.
• Alias: Other names for the same data.
• Type: Integer, String, Date, etc.
• Length/Format: e.g., 20 characters.
• Description: What the data represents.

Importance

1. Ambiguity Removal: DFD labels are short; the dictionary explains exactly what "Valid Order" means.
2. Consistency: Ensures all developers use the same data types and formats.
3. Synchronization: If the database design changes, the dictionary acts as the single source of truth.
4. Completeness: It is impossible to build a working system from bubbles and arrows alone; the dictionary provides the necessary detail for implementation.

Physical vs. Logical DFD

1. Logical DFD:

• Focus: Focuses on what the system does (business activities) rather than how it does it.
• Implementation Independent: Does not specify technology, hardware, or people.
• Example: A process might be named "Generate Invoice" (the business requirement).
• Data: Shows business data (e.g., "Invoice Details").

2. Physical DFD:

• Focus: Focuses on how the system will be implemented.
• Implementation Specific: Specifies hardware, software, files, and people involved.
• Example: The same process might be named "Run Java Class InvoiceGen" or "Clerk stamps paper".
• Data: Shows implementation specifics (e.g., "Table Row", "Form 104").

Transition: typically, designers start with a Logical DFD to understand requirements and then refine it into a Physical DFD for implementation.

Information Hiding

Information hiding is a design principle proposed by David Parnas. It states that modules should be designed so that information (procedure and data) contained within a module is inaccessible to other modules that have no need for such information.

Key Aspects:

1. Encapsulation: Internal data structures and algorithms are hidden behind a public interface.
2. Interface: Modules communicate only through well-defined interfaces.

Relation to Scope of Control

• Scope of Control: The set of modules that are subordinate to a specific module (its children, grandchildren, etc.).
• Scope of Effect: The set of modules that are affected by a decision made in a specific module.

Information hiding enforces that the Scope of Effect should be within the Scope of Control. If a module makes a decision (hides a piece of logic), the results of that decision should not impact modules outside its hierarchy (e.g., via global variables). This isolation ensures that if the hidden information changes, the impact is contained.