Chapter 4: Software Design

Question 1

Are fundamental guidelines and best practices that help architects and developers build robust, scalable, and maintainable software systems.

Answer 1

System Design Principles

Question 2

Key System Design Principles

Answer 2

1. Separation of Concerns (SoC)
2. Single Responsibility Principle (SRP)
3. Open/Closed Principle (OCP)
4. Liskov Substitution Principle (LSP)
5. Interface Segregation Principle (ISP)
6. Dependency Inversion Principle (DIP)
7. Encapsulation
8. Modularity
9. DRY (Don’t Repeat Yourself) Principle
10. KISS (Keep It Simple, Stupid) Principle
11. YAGNI (You Aren’t Gonna Need It) Principle

Question 3

The practice of organizing code and components so that each part addresses a distinct concern or functionality.

Answer 3

Separation of Concerns (SoC)

Question 4

Each class or module in a system should have one, and only one, reason to change. This principle encourages developers to ensure that every class or component has a specific role or responsibility.

Answer 4

Single Responsibility Principle (SRP)

Question 5

Software entities should be open for extension but closed for modification.

Answer 5

Open/Closed Principle (OCP)

Question 6

Subtypes must be substitutable for their base types without altering the correctness of the program.

Answer 6

Liskov Substitution Principle (LSP)

Question 7

Clients should not be forced to implement interfaces they do not use. Instead of creating large, generalized interfaces, divide them into smaller, more specific interfaces tailored to the needs of each client.

Answer 7

Interface Segregation Principle (ISP)

Question 8

High-level modules should not depend on low-level modules/details. Both should depend on abstractions (e.g., interfaces).

Answer 8

Dependency Inversion Principle (DIP)

Question 9

Involves bundling data (attributes) and methods (functions) that operate on the data into a single unit (class) while restricting access to internal implementation details.

Answer 9

Encapsulation

Question 10

Refers to the practice of dividing a system into smaller, self-contained modules, each of which can be developed, tested, and deployed independently.

Answer 10

Modularity

Question 11

The practice of eliminating redundancy by ensuring that code and logic are not duplicated. Instead, shared functionality should be extracted and reused.

Answer 11

DRY (Don’t Repeat Yourself) Principle

Question 12

Systems and code should be kept as simple as possible. Complexity should only be introduced when necessary.

Answer 12

KISS (Keep It Simple, Stupid) Principle

Question 13

Avoid adding features or functionality until it is absolutely necessary. This prevents unnecessary complexity and wasted effort.

Answer 13

YAGNI (You Aren’t Gonna Need It) Principle

Question 14

Is a standardized modeling language used to visualize, specify, construct, and document the structure and behavior of software systems.

Answer 14

Unified Modeling Language (UML)

Question 15

Represents the static structure of a system, showing classes, their attributes, methods, and the relationships between them.

Answer 15

Class Diagrams

Question 16

Focuses on the dynamic behavior of the system, illustrating the flow of messages and interactions between objects over time.

Answer 16

Sequence Diagrams

Question 17

Key Components of Class Diagrams

Answer 17

1. Classes
2. Attributes
3. Operations (Methods)
4. Relationships

Question 18

3 Class Compartments

Answer 18

• Class Name (top compartment)
• Attributes (middle compartment)
• Operations (Methods) (bottom compartment)

Question 19

Types of Relationships

Answer 19

Association: —
Aggregation: —◇
Composition: —◆
Inheritance: —▷
Dependency: —->

Question 20

Key Components of Sequence Diagrams

Answer 20

1. Lifelines (objects)
2. Actors (external entities)
3. Messages (communication between lifelines)
4. Activation Bars
5. Return Messages
6. Combined Fragments (conditional logic, loops, option)

Question 21

Indicate a call that waits for a response

Answer 21

Synchronous Messages

Question 22

Indicate a call that does not wait for a response

Answer 22

Asynchronous Messages

Question 23

Represents multiple conditional paths, like an if-else scenario with more than one outcome.

Answer 23

Alt

Question 24

Represents repetition or iteration, indicating a set of actions that are repeated until a condition is satisfied.

Answer 24

Loop

Question 25

Represents an optional action, where only one outcome is possible, depending on a condition.

Answer 25

Option

Question 26

Provide a structured approach to designing software systems by defining rules, patterns, and best practices for how system components interact with each other.

Answer 26

Architectural Styles

Question 27

A design approach in which the system is divided into layers, each with a specific responsibility.

Answer 27

Layered Architecture

Question 28

Key Components of Layered Architecture

Answer 28

1. Presentation Layer (UI Layer) 2. Application Layer (Business Logic Layer) 3. Data Access Layer 4. Database Layer

Question 29

Benefits of Layered Architecture

Answer 29

1. Separation of Concerns 2. Scalability 3. Reusability 4. Testability

Question 30

Drawbacks of Layered Architecture

Answer 30

1. Performance Overhead 2. Rigid Structure 3. Difficult to Change

Question 31

A distributed system design in which client applications request services or resources from server applications.

Answer 31

Client-Server Architecture

Question 32

Key Components of Client-Server Architecture

Answer 32

1. Client (sends requests) 2. Server (receives and processes requests)

Question 33

Benefits of Client-Server Architecture

Answer 33

1. Centralized Control 2. Scalability 3. Flexibility 4. Modularity

Question 34

Drawbacks of Client-Server Architecture

Answer 34

1. Single Point of Failure 2. Network Dependency 3. Scalability Challenges