Unit 5: Software Design Process

Understanding the software design process, cohesion, coupling, DFD, data dictionary, and UI design.

5.1 Software Design Process

Software design is a crucial phase in the software development life cycle (SDLC) where requirements are translated into a blueprint for constructing the software. It bridges the gap between what the system needs to do (requirements) and how it will do it (implementation).

Design Activities

The software design process typically involves several key activities:

  1. Architectural Design: This is the highest level of design where the overall structure of the system is defined. It identifies the major components (subsystems) and their interactions.
  2. High-Level Design (System Design): This refines the architecture by breaking down components into modules. It defines the interfaces between these modules and the data structures they share.
  3. Detailed Design (Low-Level Design): This specifies the internal workings of each module. It involves designing algorithms, detailed data structures, and the logic required to implement the module's functionality.
  4. Database Design: If the system involves persistent data, this activity focuses on designing the database schema, including tables, relationships, and constraints.
  5. Interface Design: This involves designing the interactions between the software and its users (User Interface) as well as interactions with other systems or hardware (System Interfaces).

Design Methodologies

Various methodologies guide the software design process:

  • Structured Design: A top-down approach that focuses on decomposing a system into manageable, functional modules. It heavily utilizes tools like Data Flow Diagrams (DFDs) and Structure Charts.
  • Object-Oriented Design (OOD): A methodology based on the concept of "objects," which encapsulate both data (attributes) and behavior (methods). It emphasizes concepts like inheritance, polymorphism, and encapsulation to create modular and reusable designs.
  • Agile Design: In agile development, design is continuous and iterative rather than a massive upfront phase. The architecture emerges and evolves as the system is built, with a focus on simplicity and refactoring.

5.2 Introduction to Cohesion

Cohesion refers to the degree to which the elements within a single module belong together. It is a measure of the internal strength or single-mindedness of a module.

  • High Cohesion: A highly cohesive module performs a single, well-defined task. All elements within the module are closely related and contribute to that specific task. High cohesion is desirable because it makes modules easier to understand, maintain, and reuse.
  • Low Cohesion: A module with low cohesion performs multiple, unrelated tasks. This makes the module complex, difficult to test, and hard to maintain, as changes to one part might unexpectedly affect others.

Types of Cohesion (from worst to best):

  1. Coincidental: Parts are grouped together randomly.
  2. Logical: Parts are logically related (e.g., all input routines).
  3. Temporal: Parts are grouped by when they are executed (e.g., initialization routines).
  4. Procedural: Parts execute in a specific sequence.
  5. Communicational: Parts operate on the same data.
  6. Sequential: Output of one part is input to the next.
  7. Functional: Every part contributes to a single, specific function (Ideal).

5.3 Introduction to Coupling

Coupling refers to the degree of interdependence between different modules in a software system. It measures how closely connected two modules are.

  • Low Coupling (Loose Coupling): Modules are highly independent and have minimal reliance on each other. They communicate through clear, simple interfaces. Low coupling is desirable because changes in one module are less likely to impact others, making the system easier to modify, test, and maintain.
  • High Coupling (Tight Coupling): Modules are strongly interconnected, heavily relying on each other's internal workings or shared data. High coupling makes the system rigid and difficult to change, as a modification in one module can ripple through the entire system.

Types of Coupling (from worst to best):

  1. Content Coupling: One module directly modifies or relies on the internal workings of another.
  2. Common Coupling: Multiple modules share access to global data.
  3. Control Coupling: One module passes control information (e.g., flags) to dictate the execution of another.
  4. Stamp Coupling: Modules share complex data structures, but only use parts of them.
  5. Data Coupling: Modules share only simple, necessary data through parameters (Ideal).

Goal of Software Design: Aim for High Cohesion within modules and Low Coupling between modules.

5.4 Data Flow Diagram (DFD) Model

A Data Flow Diagram (DFD) is a graphical representation of the flow of data through an information system. It models its process aspects, showing where data comes from, where it goes, how it gets stored, and how it is transformed. DFDs are widely used in structured analysis and design.

Primitive Symbols of DFD

DFDs typically use four basic symbols (often based on Gane & Sarson or Yourdon & DeMarco notations):

  1. External Entity (Source/Sink): Represents an outside entity that interacts with the system, providing data (source) or receiving data (sink). Examples: User, Customer, Another System. Usually represented by a square or rectangle.
  2. Process: Represents a function or activity that transforms data inputs into data outputs. Examples: Calculate Tax, Validate User, Generate Report. Usually represented by a circle or a rectangle with rounded corners.
  3. Data Store: Represents a repository where data is held for later use. Examples: Database table, file cabinet. Usually represented by an open-ended rectangle or two parallel lines.
  4. Data Flow: Represents the movement of data between entities, processes, and data stores. Usually represented by an arrow showing the direction of flow, labeled with the name of the data being moved.

Levels of DFD

DFDs are often created in levels to provide increasing detail, starting from a high-level overview down to granular processes.

  • Level 0 DFD (Context Diagram): The highest level. It represents the entire system as a single process interacting with external entities. It shows the system's boundaries and major data flows in and out, but no internal details or data stores.
  • Level 1 DFD: Decomposes the single process from the Level 0 diagram into its major sub-processes. It introduces data stores and the data flows between these internal sub-processes and external entities.
  • Level 2 DFD (and below): Further decomposes the processes from the Level 1 diagram into more detailed sub-processes. This decomposition continues until the processes are simple enough to be understood without further breakdown (primitive processes).

Design DFD Model of System

Designing a DFD model involves the following steps:

  1. Identify External Entities: Determine who or what interacts with the system.
  2. Identify Data Flows: Determine the information moving between the entities and the system.
  3. Draw Context Diagram (Level 0): Create the high-level view showing the system as one process.
  4. Identify Major Processes: Break down the system into its primary functions.
  5. Identify Data Stores: Determine where data needs to be saved.
  6. Draw Level 1 DFD: Connect processes, external entities, and data stores with data flows.
  7. Decompose and Refine: Continue breaking down complex processes into Level 2 or Level 3 diagrams as necessary. Ensure consistency between levels (balancing).

Shortcomings of DFD Model

While useful, DFDs have limitations:

  • Lack of Control Flow: DFDs show the flow of data, not the sequence of execution, loops, or decision logic (like 'if-then-else' conditions).
  • Not Object-Oriented: They are designed for structured methodologies and don't map well to object-oriented concepts like classes, inheritance, or encapsulation.
  • Complexity: Large systems can lead to overly complex and cluttered DFDs, making them difficult to read and maintain.
  • No Physical Implementation Details: They represent the logical flow, providing no information about how the system will be physically implemented (hardware, network, specific database).

5.5 Introduction of Data Dictionary

A Data Dictionary is a centralized repository of information about data such as meaning, relationships to other data, origin, usage, and format. It is often considered the "metadata" or "data about data."

In software design, especially alongside DFDs, a data dictionary is crucial for maintaining consistency and clarity.

Key functions of a Data Dictionary:

  • Defines Terminology: Provides a standard definition for all data elements (e.g., what exactly constitutes a "Customer ID").
  • Details Data Structures: Describes complex data flows or data stores by breaking them down into their component elements.
  • Specifies Constraints: Lists rules or validations for data elements (e.g., "Age must be an integer between 18 and 100").
  • Tracks Relationships: Shows where data elements are used across different processes or modules.

A data dictionary ensures that all stakeholders (analysts, designers, developers, users) have a shared and unambiguous understanding of the system's data.

5.6 User Interface Design

User Interface (UI) design is the process of creating interfaces in software with a focus on looks or style. It is the point of human-computer interaction and communication in a device. A well-designed UI is critical for the success of any software application, as it directly impacts usability and user satisfaction.

Characteristics of Good UI

A successful user interface should possess several key characteristics:

  1. Clarity: The interface should be visually clear, making it easy for users to understand what actions are available and what different elements mean. Avoid ambiguity.
  2. Consistency: Elements like buttons, typography, colors, and layouts should remain consistent throughout the application. Consistent behavior across different screens reduces the learning curve.
  3. Responsiveness: The UI should react quickly to user inputs. Even if a process takes time, the interface should provide feedback (like a loading spinner) to let the user know the system is working.
  4. Familiarity: Utilize design patterns and concepts that users are already familiar with from other applications (e.g., a magnifying glass icon for search).
  5. Efficiency: The design should allow users to complete their tasks with minimal effort and steps. Frequent actions should be easily accessible.
  6. Forgiveness: Users will make mistakes. A good UI should allow them to easily undo actions and provide clear, helpful error messages that explain how to recover.
  7. Aesthetics: A visually pleasing interface can enhance the user experience, making the application more enjoyable to use.

Types of UI: Command-Based, Menu-Based

User interfaces can be broadly categorized into several types based on how the user interacts with them. Two primary historical and functional types are:

Command-Based Interface (Command Line Interface - CLI)

In a command-based interface, the user interacts with the system by typing specific text commands into a prompt.

  • Characteristics:
    • Relies entirely on text input and output.
    • Requires the user to memorize commands, syntax, and parameters.
    • Highly efficient and powerful for experienced users.
    • Allows for easy automation through scripting.
  • Pros: Fast execution, low resource consumption, powerful control.
  • Cons: Steep learning curve, not intuitive for beginners, unforgiving of typos.
  • Examples: MS-DOS, Linux Terminal (Bash), Windows Command Prompt, PowerShell.

Menu-Based Interface

A menu-based interface presents the user with lists of options (menus) from which they can choose to perform actions.

  • Characteristics:
    • Users navigate through hierarchical menus using a keyboard (arrows, shortcuts) or a mouse.
    • Options are visible, reducing the need to memorize commands.
    • Often the precursor to fully Graphical User Interfaces (GUIs).
  • Pros: Easier to learn than command-line interfaces, intuitive structure, reduces memory load on the user.
  • Cons: Can be slow to navigate deep menu structures, less efficient for power users compared to direct commands.
  • Examples: ATM interfaces, older mobile phone interfaces, many basic embedded system screens, restaurant point-of-sale systems.