Chapter 6: Software Design Quiz

Software design transforms the analysis model (requirements) into a design model that serves as a blueprint for constructing the software. It bridges the gap between what needs to be done and how it will be done.

The fundamental design concepts include: Abstraction, Architecture, Patterns, Refinement, Modularity, and Information Hiding. Compilation is a programming/build process, not a design concept.

Abstraction means describing design at different levels of detail. You start with high-level abstractions (conceptual) and progressively add more detail through refinement until you reach implementation-level specifications.

Stepwise refinement is a top-down design strategy. You begin with a high-level statement of function and progressively add detail with each refinement until you reach programming language statements. Example: "open door" → "walk to door; reach for knob; turn knob; pull door"

The four design models are:
1. Data/Class Design - transforms analysis classes into design classes and data structures
2. Architectural Design - defines relationships between major structural elements
3. Interface Design - defines communication between software elements, hardware, and users
4. Component-level Design - transforms structural elements into procedural descriptions

Functional independence means developing modules with "single-minded" function and minimized interaction with other modules. It's achieved through high cohesion (single task focus) and low coupling (minimal dependencies).

Information hiding involves controlled interfaces that hide internal details (algorithms, data structures, resource allocation policies). It discourages global data, reduces side effects, limits global impact of local changes, and leads to encapsulation - all attributes of high-quality design.

Modularity involves grouping highly coupled data and functions into modules (packages, libraries). This is different from separation of concerns (subdividing problems) and hiding (controlled interfaces).

Quality designs aim for LOW coupling (not maximum). The quality guidelines state designs should: use recognizable patterns, be modular, have distinct representations, lead to appropriate data structures, and be implementable in an evolutionary fashion.

The design process starts with examining the information domain model and designing appropriate data structures for data objects and their attributes. Then you select architectural styles, partition into subsystems, and proceed with other design activities.

Cohesion is an INTRA-module concept - it measures the relative functional strength within a single module. A cohesive module performs a single task (ideally does just one thing). Coupling, in contrast, is an INTER-module concept measuring interdependence between modules.

Coupling indicates relative interdependence among modules. It depends on interface complexity, entry/reference points, and data passing across interfaces. Low coupling is desirable.

High cohesion = single-minded modules that focus on one task
Low coupling = minimal interaction between modules
This combination makes software easier to understand and less prone to ripple effects when errors occur.

The ripple effect occurs when errors or changes at one location propagate throughout the system due to high coupling. Low coupling reduces this effect, making systems more maintainable.

A module performing multiple unrelated tasks has LOW cohesion because it lacks single-mindedness. High cohesion means a module should ideally do just one thing. Low cohesion makes modules harder to understand, maintain, and reuse.

This design has:
• High coupling: Modules depend on shared global state
• Violation of information hiding: The global object is accessible everywhere
Problems: Changes to the global object can cause ripple effects; difficult to track which module modified what; prone to side effects. Better design: Use controlled interfaces and pass only necessary data.

Functional independence requires single-minded function with MINIMIZED (not maximized) interaction with other modules. It's the key to good design and achieved through high cohesion and low coupling.

Cohesion is a natural extension of information hiding. A cohesive module performs a single task requiring little interaction with other components - this aligns with hiding internal details and providing controlled interfaces.

Architectural patterns are stylized descriptions of good design practice that have been tried and tested in different environments. They're a means of representing, sharing, and reusing design knowledge. They should include information about when they are and are not useful.

MVC separates presentation and interaction from system data:
• Model: Manages system data and operations
• View: Defines how data is presented to the user
• Controller: Manages user interaction (key presses, mouse clicks) and passes them to View and Model

MVC is used when:
• There are multiple ways to view and interact with data
• Future requirements for interaction and presentation are unknown
Advantages: Data can change independently of representation; supports presentation of same data in different ways; changes in one representation shown in all of them.

A generic layered architecture has multiple layers such as:
1. User interface (top)
2. User interface management / Authentication and authorization
3. Core business logic / Application functionality / System utilities
4. System support (OS, database, etc.) (bottom)
Modern example: Presentation Layer (HTML/CSS/JS), Application Layer (Java/Python/C#), Data Layer (MySQL/Oracle)

Repository architecture characteristics:
• Goal: Integrating the data
• Clients are relatively independent of each other
• Data store is independent of clients
• Best when storage, representation, management, and retrieval of large amounts of persistent data is central
Note: Becomes client/server if clients are modeled as independent processes

While MVC has many advantages (data independence, multiple views, etc.), its disadvantage is that it can involve additional code and code complexity when the data model and interactions are simple. For simple applications, MVC might be overkill.

MVC is ideal here because:
• Multiple ways to view data (list, calendar, reports in different formats)
• Different user interactions (students view, professors update, admins report)
• Unknown future requirements (mobile app)
• Allows same data to be presented differently
• Changes in one view automatically reflected in others
Note: Could also use layered architecture in combination with MVC

Patterns should include information about BOTH when they are useful AND when they are not useful. This helps developers make informed decisions about pattern selection and avoid misusing patterns in inappropriate contexts.

When clients in a Repository architecture are modeled as independent processes, the style becomes client/server. The repository (data store) acts as the server, and the clients access it as independent processes.

The system support layer (bottom layer) contains the OS, database, and other system-level support. The layers from top to bottom are: User Interface → Authentication/Authorization → Business Logic → System Support.

Step-by-step reasoning:
1. MVC needed because: Multiple views (grid/list/comparison/cart), different interactions (customer vs admin), unknown future interfaces (voice, VR)
2. Repository needed because: Large inventory database, frequent updates, need for data integration and management
3. Layered architecture for: Separation of presentation (HTML/JS), business logic (pricing/inventory), and data access

Benefits:
• MVC: Same product data shown in multiple views automatically
• Repository: Centralized data management, clients (views) independent
• Layers: Clear separation of concerns, easier maintenance
• High cohesion: Each layer/component has focused responsibility
• Low coupling: Changes in one layer don't ripple everywhere

Violations identified:
1. LOW COHESION: Module mixes user management, email, reporting, shipping, and inventory - these are unrelated concerns
2. Lacks functional independence: Not single-minded
3. Violates separation of concerns

Better design: Now each module has high cohesion (single purpose) and low coupling (independent).

Design A problems:
✗ LOW cohesion - does too many things
✗ HIGH coupling - everything depends on everything
✗ Hard to test - can't test components independently
✗ Prone to ripple effects - changes cascade
✗ Difficult maintenance - 5000 lines to understand
✗ No reusability - can't use parts independently

Design B advantages:
✓ HIGH cohesion - each class has single responsibility
✓ LOW coupling - defined interfaces only
✓ Modularity - clear separation
✓ Information hiding - internal details hidden
✓ Functional independence achieved
✓ Easy testing - test each component separately
✓ Reusability - NotificationService could be used elsewhere
✓ Maintainability - change PatientValidator without affecting DB code
✓ Follows separation of concerns

Example change scenario:
If validation rules change: Design A requires changes in 5000-line class; Design B only changes PatientValidator.

Information hiding means internal details (algorithms, data structures, external interface details, resource allocation policies) are hidden behind controlled interfaces. This reduces side effects, limits global impact of local decisions, and leads to encapsulation.

Refactoring is a reorganization technique that simplifies the design without changing external behavior. It improves code structure, readability, and maintainability. Often used to improve cohesion and reduce coupling.

System 1 → MVC:
• Multiple views of same data (charts, tables, mobile, AR)
• Real-time updates need to reflect in all views
• Different interaction methods
• Unknown future interfaces (AR)

System 2 → Repository:
• Central issue: storage/management of 2M+ items
• Clients (students/faculty/public) are independent
• Need for data integration
• Centralized cataloging system

System 3 → Layered:
• Clear hierarchical separation
• Each layer builds on layer below
• Applications → Services → Kernel → Hardware
• Natural abstraction levels

Note: Real systems often combine patterns (e.g., System 1 could also use Repository for price data storage).

Violations Identified:

1. LOW COHESION:
PostManager does 8 unrelated things (posts, validation, notifications, feeds, UI, images, comments). Violates single responsibility.

2. HIGH COUPLING:
• Global "currentUser" creates dependencies everywhere
• UI directly accessing database creates tight coupling
• Changes ripple through entire system

3. POOR INFORMATION HIDING:
• Feed algorithm exposed publicly (should be internal)
• Database structure exposed to UI
• No controlled interfaces

4. LACKS SEPARATION OF CONCERNS

5. NO MODULARITY

Improved Design: Benefits:
✓ Each module focused on single task
✓ Changes isolated - modify FeedGenerator without affecting PostRepository
✓ Testable independently
✓ Reusable components
✓ No ripple effects
✓ Clear interfaces
✓ Maintainable long-term