System Design: Decomposing the System

System design involves transforming an analysis model into a system design model. It focuses
on defining design goals and breaking the system into smaller, manageable subsystems. Key
points include:

●​ Two Approaches to Design (by C.A.R. Hoare):​

○​ Make it simple—no obvious deficiencies.​

○​ Make it complex—no easily found deficiencies.​

●​ System Design Process:​

○​ Define design goals (e.g., performance, security).​

○​ Decompose the system into subsystems using use case and analysis models.​

○​ Refine the decomposition to meet design goals.​

●​ Strategies Considered:​

○​ Hardware/software decisions.​

○​ Persistent data management.​

○​ Global control flow.​

○​ Access control policies.​

○​ Handling boundary conditions.​

●​ Challenges in System Design:​

○​ Requires trade-offs between conflicting goals.​

○​ Cannot predict all future design issues.​

This chapter focuses on identifying design goals and initial subsystem decomposition, with
further refinement in the next chapter through the ARENA case study.

6.1 Introduction: A Floor Plan Example

System design, object design, and implementation bridge the gap between requirements and
the delivered system. System design is the first step, focusing on decomposing the system
into manageable parts by considering processes, data structures, and hardware/software
components.

Key Challenges in System Design:

●​ Balancing conflicting criteria and constraints during system decomposition.​

●​ Delaying detailed decisions to allow flexibility for end-users.​

Floor Plan Analogy for System Design:

Designing a residential house mirrors system design by satisfying functional requirements

while optimizing layout efficiency.

Constraints in the Floor Plan Example:

1.​ The house should have two bedrooms, a study, a kitchen, and a living room.​

2.​ Minimize the walking distance for daily activities (e.g., from the entrance to the kitchen).​

3.​ Maximize the use of natural daylight.​

Design Process (Figure 6-1 Explanation):

1.​ Initial Design: The dining room is too far from the kitchen.​

○​ Solution: Swap the dining room with bedroom 2, improving access and
increasing sunlight in the living room.​

2.​ Second Revision: The kitchen and stairs are too far from the entrance.​

○​ Solution: Move the entrance to the north wall, reorient bedroom 2, and bring
the bathroom closer to both bedrooms.​

✅ Outcome: The revised plan meets all original constraints by improving efficiency and
space utilization.
6.2 An Overview of System Design

System design is the first step in realizing the system by transforming analysis results into a
structured implementation plan.

Products of Analysis:

1.​ Nonfunctional Requirements – Constraints like response time, throughput, reliability,

and platform.​

2.​ Use Case Model – Describes system functionality from the actors' perspective.​

3.​ Object Model – Defines the entities manipulated by the system.​

4.​ Sequence Diagrams – Shows object interactions for each use case.​

✅ Purpose of the Analysis Model:

●​ Communicates the system’s functionality between the client and developers.​

●​ Lacks internal details like hardware and implementation strategies.​

Products of System Design:

1.​ Design Goals – Derived from nonfunctional requirements and guide trade-offs.​

2.​ Software Architecture – Defines:​

○​ Subsystem responsibilities and dependencies.​

○​ Mapping subsystems to hardware.​

○​ Major policies (e.g., control flow, access control, data storage).​

3.​ Boundary Use Cases – Handles system-level operations (e.g., configuration, startup,
shutdown, error handling).​

Subsystem Decomposition:

●​ Divides the system into manageable parts, each assigned to a team for independent
development.​
 ●​ Considers system-wide issues to maintain consistency and integration.​

✅ Next Steps:
●​ This chapter focuses on subsystem decomposition and architectural styles.​

●​ The next chapter refines the system design to meet specific goals.

6.3 System Design Concepts

This section describes the decomposition of a system into subsystems and explains key
concepts like interfaces, coupling and cohesion, layering and partitioning, and common
software architectures.

●​ Subsystem: A part of the system with well-defined boundaries that provides specific
functionality.​
 ●​ Purpose of Decomposition:​

○​ Reduce system complexity.​

○​ Allow concurrent development by different teams.​

○​ Improve maintainability and scalability.​

6.3.1 Subsystems and Classes

●​ Application Domain vs. Solution Domain:​

○​ Application Domain: Real-world concepts and problems.​

○​ Solution Domain: Technical implementation to solve the problem.​

○​ Just as classes represent real-world objects in the application domain,

subsystems organize technical solutions in the solution domain.​

●​ What is a Subsystem?​

○​ A subsystem consists of solution domain classes.​

○​ It is replaceable and has well-defined interfaces.​

○​ Encapsulates the state and behavior of its contained classes.​

●​ Characteristics of Subsystems:​

○​ Each subsystem corresponds to a workload that a single developer or team

can handle.​

○​ Complex subsystems can be recursively decomposed into simpler subsystems.​

●​ Example: Accident Management System​

This system can be divided into the following subsystems:​

○​ DispatcherInterface: Provides a user interface for dispatchers.​

○​ FieldOfficerInterface: Provides a user interface for field officers.​

 ○​ IncidentManagement: Manages creation, modification, and storage of incidents.​

○​ ResourceManagement: Tracks resources (e.g., ambulances, fire trucks).​

○​ MapManagement: Manages maps and locations.​

○​ Notification: Manages communication between field officers and dispatchers.​

●​ UML Representation of Subsystems:​

○​ Subsystems are shown as components (rectangles with a component icon).​

○​ Dashed arrows indicate dependencies among components.​

●​ Logical vs. Physical Components:​

○​ Logical Component: Conceptual group of functionality with no separate runtime

existence (e.g., business logic).​

○​ Physical Component: Actual entities in the running system (e.g., database

servers).​

●​ Subsystems in Programming Languages:​

○​ Explicit Representation: Supported in Java (packages) and Modula-2

(modules).​

○​ Implicit Representation: In C/C++, subsystems are represented through

naming conventions or directories.​

●​ Importance of Subsystem Documentation:​

○​ Documenting subsystem decomposition is critical because different teams

usually work on different subsystems.​

6.3.2 Services and Subsystem Interfaces

●​ Service Definition:​

○​ A service is a collection of related operations that fulfill a common purpose.​

 ○​ Example: A notification service includes operations for:​

■​ Sending notifications.​

■​ Looking up notification channels.​

■​ Subscribing/unsubscribing from channels.​

●​ Subsystem Interface:​

○​ The set of operations a subsystem provides to other subsystems.​

○​ Includes:​

■​ Operation names.​

■​ Parameters and their types.​

■​ Return values.​

●​ Design Phases and Interfaces:​

○​ System Design: Focuses on defining what services subsystems provide.​

○​ Object Design: Refines subsystem interfaces into an Application

Programming Interface (API).​

●​ UML Representation of Interfaces:​

○​ Provided Interface: Shown as a ball (lollipop icon).​

○​ Required Interface: Shown as a socket.​

○​ Dependency is represented by connecting the ball-and-socket.​

●​ Example: Accident Management System Interfaces:​

○​ FieldOfficerInterface:​

■​ Requires ResourceUpdateService to update officer status and

location.​

○​ DispatcherInterface:​
 ■​ Requires ResourceAllocationService to allocate resources for
incidents.​

○​ ResourceManagement:​

■​ Provides both the ResourceUpdateService and

ResourceAllocationService.​

●​ Subsystem Dependency Notation:​

○​ Early Stage: Use dashed arrows (when the subsystem allocation is not fixed).​

○​ Stable Stage: Use ball-and-socket connectors (when services are clearly

defined).​

●​ Design Principle: Minimizing Dependencies​

○​ Subsystem interfaces should avoid exposing implementation details (e.g., data

structures like linked lists or arrays).​

○​ This ensures:​

■​ Easier modification of subsystems without impacting others.​

■​ Greater flexibility and maintainability of the system.​

Coupling and Cohesion: Key Concepts and Examples

1. Coupling:

●​ Definition: Measures the degree of dependency between subsystems.​

●​ Loose Coupling: Subsystems are independent, meaning changes in one subsystem

have minimal impact on others.​

●​ Tight Coupling: Subsystems are interdependent, meaning a change in one affects

others.​

Example (Emergency Response System):

 ●​ Initial Design (High Coupling):​

○​ Subsystems (IncidentManagement, ResourceManagement, and

MapManagement) directly interact with the Database using SQL queries.​

○​ Any database change (e.g., switching database vendors) requires modifications

across all three subsystems.​

●​ Improved Design (Low Coupling):​

○​ Introduces a Storage subsystem between client subsystems and the Database.​

○​ Changes to the database only affect the Storage subsystem, reducing the impact
on other subsystems.​

Trade-off Consideration:

●​ Reduced coupling may increase complexity by adding layers of abstraction.​

●​ High coupling is problematic only if frequent subsystem changes are expected.​

2. Cohesion:

●​ Definition: Describes how closely related the elements within a subsystem are.​

●​ High Cohesion: Subsystems focus on a specific, well-defined task.​

●​ Low Cohesion: Subsystems perform unrelated tasks, reducing clarity and

maintainability.​

Example (Decision Tracking System):

●​ Low Cohesion (Initial Design):​

○​ DecisionSubsystem combines unrelated classes (e.g., Criterion, Option, Task,

ActionItem).​

●​ High Cohesion (Improved Design):​

 ○​ Split into two subsystems:​

1.​ RationaleSubsystem: Manages design exploration (DesignProblem,

Option, Criterion).​

2.​ PlanningSubsystem: Handles task implementation (Task, Subtask,

ActionItem).​

○​ This increases clarity, allows independent maintenance, and simplifies system

management.​

3. Balancing Coupling and Cohesion:

●​ Heuristic:​

○​ Limit subsystems to 7 ± 2 concepts or services for better understanding.​

○​ Avoid excessive layering; three layers often provide an effective design balance.​

●​ Outcome:​

○​ Aim for low coupling and high cohesion to improve system flexibility and
maintainability while minimizing unnecessary complexity.​

Summary of Architectural Styles in System Design

1.​ Repository Architectural Style:​

○​ Structure: Subsystems interact with a central data repository.​

○​ Control Flow: Managed either by the repository (via triggers) or by subsystems

(via locks).​

○​ Examples: Database management systems, compilers.​

○​ Advantages:​

■​ Centralized data management.​

■​ Simplifies concurrency and data integrity.​

 ○​ Disadvantages:​

■​ Performance bottlenecks due to central repository.​

■​ High coupling makes modifications difficult.​

2.​ Model/View/Controller (MVC) Architectural Style:​

○​ Structure: Divides system into:​

■​ Model: Manages data and business logic.​

■​ View: Handles data presentation to users.​

■​ Controller: Manages user input and updates the Model.​

○​ Control Flow:​

■​ User interacts with the Controller.​

■​ Model updates and notifies all Views using a subscribe/notify mechanism

(Observer pattern).​

○​ Examples: Graphical user interfaces (GUIs), web applications.​

○​ Advantages:​

■​ Clear separation of concerns.​

■​ Easy to add new views without changing the model.​

○​ Disadvantages:​

■​ Increased complexity due to multiple components.​

■​ Performance overhead from frequent updates.​

3.​ Client/Server Architectural Style:​

○​ Structure: Clients request services from one or more centralized servers.​

○​ Control Flow: Independent execution in clients and servers, synchronized by

service requests.​
 ○​ Examples: Database systems, web applications.​

○​ Advantages:​

■​ Supports distributed systems and large data management.​

■​ Separation of user interface (client) and data processing (server).​

○​ Disadvantages:​

■​ Network dependency and latency.​

■​ Scalability issues with a single central server.​

4.​ Peer-to-Peer (P2P) Architectural Style:​

○​ Structure: Each subsystem acts as both a client and a server.​

○​ Control Flow: Independent execution with synchronization for requests.​

○​ Examples: File-sharing systems (e.g., BitTorrent), blockchain networks.​

○​ Advantages:​

■​ Greater scalability and fault tolerance.​

■​ No central point of failure.​

○​ Disadvantages:​

■​ Complex management and synchronization.​

■​ Security risks due to decentralized control.​

Summary of System Design Activities for MyTrip: From Objects to

Subsystems

1.​ Starting Point: Analysis Model​

○​ System Overview: MyTrip is a route-planning system for car drivers that allows
planning via a web service and provides directions through an onboard assistant.​
 ○​ Use Cases:​

■​ PlanTrip: Allows drivers to create, modify, and save trips using a

web-based planning service.​

■​ ExecuteTrip: Provides real-time navigation using the onboard assistant

and the saved trip.​

○​ Key Objects: Trip, Destination, Crossing, Segment, Direction, Location,

RouteAssistant, and PlanningService.​

2.​ Nonfunctional Requirements for MyTrip​

○​ Wireless modem for communication with the PlanningService.​

○​ System must function even if connectivity is lost during a trip.​

○​ Minimize connection time to reduce operational costs.​

○​ Replanning is only possible with an active connection.​

○​ Support for at least 50 drivers and 1,000 trips.​

3.​ Identifying Design Goals​

○​ Reliability: Ensure correct operation under normal conditions.​

○​ Fault Tolerance: Continue providing directions despite connectivity issues.​

○​ Security: Protect user data and prevent unauthorized access.​

○​ Modifiability: Allow integration with different planning services.​

4.​ Design Criteria Categories​

○​ Performance: Response time, throughput, and memory use.​

○​ Dependability: Robustness, reliability, availability, fault tolerance, and security.​

○​ Cost: Development, deployment, upgrade, maintenance, and administration

costs.​
 ○​ Maintenance: Extensibility, modifiability, adaptability, portability, readability, and
traceability.​

○​ End-User Experience: Usability and ease of learning.​

5.​ Trade-Off Considerations​

○​ Balancing technical goals (e.g., reliability) with managerial goals (e.g., delivery
time).​

○​ Prioritizing essential design goals while managing project constraints.​

This process transforms the analysis model into a detailed design model that aligns with user
needs and nonfunctional requirements.

6-1: Competing Principle in System Decomposition

●​ Principle: Minimizing interdependencies (Coupling)​

●​ While cohesion encourages breaking down a system into smaller, more focused
subsystems, coupling encourages minimizing the number of interfaces and
interdependencies between them to reduce complexity and improve maintainability.
Striking a balance between cohesion and low coupling is crucial to achieving an efficient
system architecture.​

6-2: Classifying Design Goals

1.​ Users must be given feedback within one second after they issue any command:​

○​ Performance (ensuring quick system responses).​

2.​ The TicketDistributor must be able to issue train tickets, even in the event of a
network failure:​

○​ Dependability (ensuring fault tolerance and availability).​

3.​ The housing of the TicketDistributor must allow for new buttons to be installed in
case the number of fares increases:​

○​ Maintenance (allowing future modifications and extensions).​

 4.​ The AutomatedTellerMachine must withstand brute-force attacks:​

○​ Dependability (ensuring system security and resilience).​

6-3: Subsystem Decomposition for Future Porting

●​ Proposal:​

1.​ Create a File System Abstraction Layer (FSAL) to handle all file operations.​

2.​ Implement platform-specific adapters for Unix, Windows, etc.​

3.​ Ensure all data storage operations use the FSAL interface to maintain
portability.​

●​ Rationale: This modular approach separates business logic from platform-specific

implementations, facilitating easier migration across different operating systems.​

6-4: Design Goals Behind the Shift to Repository Architecture

1.​ Efficiency: Shared data allows faster access without repetitive file parsing.​

2.​ Consistency: Centralized data reduces discrepancies between modules.​

3.​ Scalability: Easier to manage large datasets across interconnected tools.​

4.​ Interactivity: Supports real-time updates for modern IDEs and debugging.​

6-5: MVC Architecture Analysis

a. Communication Diagram to Sequence Diagram:

●​ Convert the message flow in Figure 6-17 into a sequential representation, showing
interactions between Model, View, and Controller with lifelines and method calls.​
b. MVC Design Goals Analysis:

1.​ Extensibility:​

○​ Helps: New views can be added without changing the model or controller.​

2.​ Response Time:​

○​ Hurts: Multiple views may require extra time to update simultaneously.​

3.​ Modifiability:​

○​ Helps: Changes to the model propagate automatically to all views.​

4.​ Access Control:​

○​ Hurts: Requires additional mechanisms to restrict unauthorized access to the

model.​

6-6: Challenges in Closed-Layer Architectures

1.​ Performance: Increased latency due to multiple layers of processing.​

2.​ Modifiability: Difficult to introduce changes without altering all layers.​

3.​ Flexibility: Limited ability to bypass layers for optimizations.​

4.​ Access Control: Managing permissions across layers increases complexity.​

6-7: Reasons for a Dedicated Storage Layer

1.​ Data Integrity: Centralized management ensures consistent data handling.​

2.​ Scalability: Facilitates handling large datasets efficiently.​

3.​ Security: Easier to implement and enforce access controls.​

4.​ Maintainability: Isolates data logic, simplifying updates and modifications.​

**************************************************************************************
 System Design: Addressing Design Goals

System design focuses on translating high-level requirements into an architecture that meets
specific design goals. This process involves balancing trade-offs between performance, cost,
and quality while ensuring the system's structure can support future modifications. Key activities
include:

1. Selection of Off-the-Shelf and Legacy Components

●​ Purpose:​

○​ Reduces development time and cost by using pre-existing solutions.​

○​ Adjusts the subsystem decomposition to fit reusable components.​

●​ Trade-offs:​

○​ Pros: Faster implementation, lower cost, proven reliability.​

○​ Cons: Limited customization, potential integration challenges.​

2. Mapping Subsystems to Hardware

●​ Purpose:​

○​ Defines how software components interact with hardware.​

○​ Ensures performance (through parallel processing) and reliability (via

redundancy).​

●​ Considerations:​

○​ Network latency, fault tolerance, and resource utilization.​

○​ Allocate critical subsystems to robust nodes for better fault handling.​

3. Design of a Persistent Data Management Infrastructure

●​ Purpose:​

○​ Manages data that persists beyond system execution.​

○​ Influences system performance and consistency.​

●​ Strategies:​

○​ Use databases for structured data, file systems for large, unstructured data.​

○​ Ensure backup and recovery processes for fault tolerance.​

4. Specification of an Access Control Policy

●​ Purpose:​

○​ Controls user permissions to shared resources.​

○​ Secures sensitive data by defining user roles and access privileges.​

●​ Approaches:​

○​ Implement role-based access control (RBAC).​

○​ Ensure data confidentiality and integrity through secure interfaces.​

5. Design of the Global Control Flow

●​ Purpose:​

○​ Defines the sequence and coordination of system operations.​

○​ Impacts how components communicate and synchronize.​

●​ Models:​

○​ Centralized Control: One subsystem manages all operations.​

 ○​ Event-Driven Control: Reacts to external and internal events asynchronously.​

6. Handling Boundary Conditions

●​ Purpose:​

○​ Manage system start-up, shutdown, and failure recovery.​

○​ Ensures system stability during transitions.​

●​ Challenges:​

○​ Data persistence across restarts.​

○​ Handling errors gracefully to prevent system crashes.​

Management Considerations in System Design

●​ Documentation: Clear records of system architecture and design decisions.​

●​ Responsibilities: Assign ownership of subsystems and processes.​

●​ Communication: Ensure smooth collaboration between teams through regular meetings

and shared documentation.​

Case Study: ARENA System Design

●​ ARENA (a real-time, multi-user online platform) demonstrates practical trade-offs:​

○​ Performance: Optimized for real-time interactions.​

○​ Access Control: Secure data sharing between users.​

○​ Reliability: Backup mechanisms for critical game data.​

Effective system design involves balancing conflicting goals while maintaining
clarity and future scalability.
Key Points from System Design Activities

1.​ Design Goals and Trade-offs:​

○​ Design decisions are guided by goals like performance, reliability, and cost.​

○​ Trade-offs are often required (e.g., balancing redundancy with budget).​

2.​ Hardware/Software Mapping:​

○​ Identifies which system functionalities are handled by hardware vs. software.​

○​ Defines communication between nodes and integration of off-the-shelf

components.​

○​ Ensures encapsulation to allow future component changes.​

3.​ Data Management:​

○​ Determines which data is persistent and where it is stored.​

○​ Focuses on fast, reliable access to avoid performance bottlenecks and data

corruption.​

○​ Often requires choosing a database management system.​

4.​ Access Control:​

○​ Specifies who can access which data and whether access control changes
dynamically.​

○​ Ensures a consistent security policy across all subsystems.​

5.​ Control Flow:​

○​ Defines how the system sequences operations (e.g., event-driven or

thread-based).​

○​ Impacts subsystem interfaces and requires managing concurrent access.​

6.​ Boundary Conditions:​

○​ Deals with system initialization, shutdown, and exception handling.​

 ○​ Ensures smooth handling of special cases, especially in distributed systems.​

7.​ Iterative Process:​

○​ System design is an ongoing, iterative activity that evolves with new

requirements and issues.​

Key Points from UML Deployment Diagrams

1.​ Purpose of UML Deployment Diagrams:​

○​ Depict relationships between run-time components and nodes.​

○​ Visualize how system components interact and are distributed across physical
devices.​

2.​ Key Elements in Deployment Diagrams:​

 ○​ Components: Self-contained entities providing services (e.g., Web server,
database).​

○​ Nodes: Physical devices or execution environments where components run

(e.g., PC, Unix host).​

○​ Communication Paths: Solid lines represent communication between nodes,

with optional protocol stereotypes (e.g., «http», «jdbc»).​

3.​ Diagram Example Explanation (Figure 7-2):​

○​ Two web browsers (Safari on Mac and Internet Explorer on PC) access a web
server.​

○​ The web server interacts with a database hosted on a Unix machine.​

○​ Web browsers never directly access the database.​

4.​ Component Refinement:​

○​ Components (e.g., the Web server) can be expanded to show their internal
structure, including:​

■​ Interfaces: Services they offer.​

■​ Classes: Internal implementation details.​

5.​ Applications of UML Deployment Diagrams:​

○​ Understand system architecture and component allocation.​

○​ Identify dependencies and communication protocols.​

○​ Useful for performance analysis and system design validation.​

7.4 System Design Activities: Addressing Design Goals – Summary

This section describes the activities required to ensure subsystem decomposition meets
nonfunctional requirements and implementation constraints. Key steps in refining subsystem
decomposition include:

1.​ Mapping Subsystems to Processors and Components (7.4.1)​

 ○​ Hardware Configuration: Select hardware and platforms (e.g., multiple
computers for performance and distribution).​

○​ Virtual Machines: Choose virtual machines (OS, DBMS, etc.), considering

performance, cost, and client constraints.​

○​ Example (MyTrip):​

■​ PlanningSubsystem runs on a Unix-based web server (:WebHost).​

■​ RoutingSubsystem runs on an onboard computer (:OnBoardComputer).​

■​ A new CommunicationSubsystem manages data transfer between these

nodes.​

■​ SegmentProxy and TripProxy classes act as proxies to facilitate

cross-node communication.​

2.​ Identifying and Storing Persistent Data (7.4.2)​

○​ Persistent Data: Data that outlives system execution (e.g., files, databases).​

○​ MyTrip Strategy:​

■​ RoutingSubsystem stores trips in flat files for quick recovery after

shutdown.​

■​ PlanningSubsystem uses a relational database to store multiple drivers’

trips and maps.​

■​ Introduced TripFileStoreSubsystem and MapDBStoreSubsystem for

efficient data handling.​

○​ Storage Options:​

■​ Flat Files: Fast and customizable but requires manual handling of

concurrency and crashes.​

■​ Relational Databases: Allows complex queries and structured storage.​

These design activities ensure efficient system performance, data integrity, and effective
communication across distributed environments.

### **7.4.3 Providing Access Control**

In multi-user systems, different actors (e.g., users, administrators) have varying levels of access
to functionality and data. During analysis, access distinctions are modeled by associating
different use cases with different actors. In system design, access control is implemented by
determining shared objects and defining how actors control access. Security requirements may
also involve authentication (verifying identity) and data encryption.

**Example (MyTrip):**

- Only the driver who created a **Trip** should access it.

- The **PlanningSubsystem** authenticates **Drivers** before sending **Trips**.

- Communication between **RoutingSubsystem** and **PlanningSubsystem** is encrypted via

the **CommunicationSubsystem**.

#### **Access Control Models**

For complex systems, access rights are defined per actor per shared object (e.g., bank tellers
can post small transactions, managers approve large ones). This is modeled using an **access
matrix**:

- **Rows:** Actors

- **Columns:** Classes with controlled access

- **Entries (Access Rights):** Allowed operations (e.g., `postSmallDebit()`, `examineStats()`)

**Representation Approaches:**

1. **Global Access Table:** Explicitly lists all `(actor, class, operation)` tuples.

2. **Access Control List (ACL):** Each class has a list of `(actor, operation)` pairs (e.g., a party
guest list).

3. **Capabilities:** Each actor holds `(class, operation)` permissions (e.g., an invitation card).

**Trade-offs:**

- **Global tables** use more space.

- **ACLs** answer *"Who can access this object?"* efficiently.

- **Capabilities** answer *"What can this actor access?"* efficiently.

#### **Dynamic Access Control**

When access rights change dynamically (e.g., brokers managing portfolios), the **Protection
Proxy** pattern can enforce checks before delegating operations.

#### **Authentication & Encryption**

- **Authentication:** Verifies identity (e.g., passwords, smart cards, biometrics).

- **Encryption:** Secures data in transit (e.g., encrypted network traffic).

- **Best Practice:** Use established security standards rather than custom solutions.

---

### **7.4.4 Designing the Global Control Flow**

Control flow determines the sequencing of system actions. Three mechanisms exist:

1. **Procedure-Driven Control:** Operations wait for input (common in legacy systems).

2. **Event-Driven Control:** A central loop dispatches events to appropriate objects (simpler but
harder for multi-step sequences).

3. **Threads:** Concurrent execution (intuitive but harder to debug due to nondeterminism).

**Recommendation:** Prefer event-driven control for stability, but threads may become more
viable with better tooling.

**Control Objects:** Centralize sequencing logic for a use case to improve maintainability.
---

### **7.4.5 Identifying Services**

Refine subsystems by defining their **services** (interfaces) and reviewing dependencies:

- Example: **CommunicationSubsystem** in MyTrip provides:

- **ConnectionManager** (register, authenticate).

- **TripRequester** (request/download trips).

- **TripProvider** (upload trips).

- Naming conventions: Services (noun phrases, e.g., `TripRequester`), operations (verb

phrases, e.g., `requestTrip()`).

**Benefits:**

- Clarifies subsystem responsibilities.

- Helps identify missing functionality (e.g., real-time data feedback).

---

### **7.4.6 Identifying Boundary Conditions**

Address system startup, shutdown, and failure handling via **boundary use cases**:

1. **Configuration:** Manage persistent objects (e.g., `ManageMaps` in MyTrip).

2. **Startup/Shutdown:** Initialize and terminate subsystems (e.g., `StartServer`).

3. **Exception Handling:** Define responses to failures (e.g., network outages).

**Example (MyTrip):**

- Added `ManageDrivers`, `ManageMaps`, and `ManageServer` use cases.

- **MapDBStoreSubsystem** now checks data consistency on startup after crashes.

**Exception Sources:**

- Hardware failures (e.g., disk crashes).

- Environmental changes (e.g., power outages).

- Software faults (e.g., design errors).

**Handling:** Either tolerate failures (e.g., retry network requests) or notify users.

---

### **7.4.7 Reviewing System Design**

Ensure the model is:

- **Correct:** Maps to analysis model (e.g., subsystems trace to use cases).

- **Complete:** Covers all design goals and boundary cases.

- **Consistent:** No conflicting decisions.

- **Realistic:** Feasible to implement.

- **Readable:** Clear documentation.

**Review Methods:**

- Peer reviews by uninvolved developers.

- Cross-project evaluations.

**Key Questions:**
- Can every subsystem be traced to a use case or nonfunctional requirement?

- Are all design goals addressed?

This structured approach ensures a robust and maintainable system design.

UNIT 2

Object Design Overview:

Object design is the phase where the abstract concepts from system design are translated into
a more detailed and practical form by defining and refining objects. It bridges the gap between
application-specific needs and existing reusable components.

Key Activities in Object Design:

1.​ Reuse:​

○​ Identify and integrate off-the-shelf components and design patterns to leverage

existing solutions.​

○​ Reduces development time and increases system reliability by using tested

components.​

2.​ Service Specification:​

○​ Precisely define the interfaces for each class.​

○​ Ensures clear communication between system components.​

3.​ Object Model Restructuring:​

○​ Refine the object design model to improve clarity and maintainability.​

○​ Simplify relationships and enhance the model’s extensibility.​

4.​ Object Model Optimization:​

○​ Modify the object design model to meet performance goals such as response
time and memory utilization.​
 ○​ Balances system efficiency with scalability.​

Reusing Patterns and Solutions:

●​ Design Patterns: Standardized solutions to recurring problems (e.g., Singleton, Factory,

Observer).​

●​ Off-the-Shelf Components: Pre-existing software modules (e.g., libraries, APIs) to

avoid reinventing the wheel.​

Importance of Reuse in Object Design:

●​ Efficiency: Reduces development time by using pre-tested solutions.​

●​ Quality: Enhances system reliability through established components.​

●​ Consistency: Provides uniform solutions across different system parts.​

By focusing on reuse, object design ensures faster, more reliable, and more maintainable
software development.

8.1 Introduction: Bloopers

Understanding Mistakes in Complex Systems:​

Both movies and software systems are highly complex, and errors (or "bloopers") can emerge
due to the intricacies involved in their production and integration processes. Despite significant
resources and rigorous processes, mistakes can still slip through due to various challenges.

Why Do Mistakes Happen?

1.​ Complexity of Collaboration:​

○​ Both industries require cooperation among many individuals working on different

tasks simultaneously.​

2.​ Out-of-Sequence Production:​

○​ Movie scenes are filmed non-linearly; software modules are developed

independently and integrated later.​
 3.​ Frequent Changes:​

○​ Props, costumes, or code may change mid-process, leading to inconsistencies.​

4.​ Time Pressure:​

○​ Deadlines for movie releases or software launches create pressure during the
final editing and integration phases.​

Movie Examples of Bloopers:

1.​ Speed (1994):​

○​ Harry is shot in the right leg but limps on the left throughout the film.​

2.​ Star Wars Trilogy:​

○​ Han Solo is frozen in carbonite wearing a jacket but is thawed in a white shirt.​

3.​ Titanic (1997):​

○​ Jack has no spit on his face when turning to meet Rose’s mother, but it suddenly
appears mid-turn.​

Parallels with Software Development:

1.​ Inconsistent State Management:​

○​ Just as actors' positions and props must align across scenes, object states must
remain consistent across modules.​

2.​ Informal Specifications:​

○​ Developers often work with incomplete descriptions, leading to mismatched or

missing behavior.​

3.​ Iterative Changes:​

 ○​ Similar to film reshoots, software objects undergo multiple revisions before final
integration.​

How Object Design Addresses These Issues:

1.​ Precise Specifications:​

○​ Detailed class interfaces and object behaviors ensure consistent implementation.​

2.​ Reuse of Components:​

○​ Leveraging annotated off-the-shelf components reduces errors and speeds up

development.​

3.​ Restructuring and Optimization:​

○​ Refining the object model enhances maintainability, extensibility, and

performance.​

In the following sections, object design concepts, processes, and management practices are
explored to minimize inconsistencies and enhance system reliability.

Key Points from Section 8.2: An Overview of Object Design

1.​ System Development Process​

○​ Software system development bridges the gap between a problem and an

existing machine.​

○​ This process involves three key phases:​

■​ Analysis: Identifying objects and external behavior (use case model,

object model, dynamic model).​

■​ System Design: Selecting off-the-shelf components and building a virtual

machine for higher abstraction.​

■​ Object Design: Filling the gaps by creating new solution objects,

adjusting components, and defining precise specifications.​
2.​ Object Design Activities​
Object design consists of four major activities:​

○​ Reuse:​

■​ Incorporating off-the-shelf components and design patterns.​

■​ Adapting components via custom wrappers or inheritance.​

■​ Balancing the "buy vs. build" trade-off.​

○​ Interface Specification:​

■​ Defining subsystem services through APIs (Application Programmer

Interfaces).​

■​ Specifying operations, arguments, types, and exceptions.​

○​ Restructuring:​

■​ Improving system models for better code reuse and maintainability.​

■​ Examples: Transforming associations, merging or splitting classes, and

optimizing inheritance.​

○​ Optimization:​

■​ Enhancing system performance through algorithm changes and improving

object access time.​

■​ Includes reducing query time, adding derived attributes, and reordering

execution.​

3.​ Iterative Nature of Object Design​

○​ Object design is not sequential—activities are interdependent and occur

concurrently.​

○​ Order of Focus: Start with interfaces, components, and patterns for flexibility,
and tackle optimizations later to avoid creating rigid models.​

4.​ Chapter Structure​

 ○​ Chapter 8: Focuses on reuse, components, and design patterns.​

○​ Chapter 9: Covers interface specifications (UML’s Object Constraint Language).​

○​ Chapter 10: Explores model-to-code mapping, restructuring, and optimization.​

Hhh
Summary of Key Concepts in Object Design: Reuse through Solution
Objects, Inheritance, and Design Patterns
 1. Application Objects and Solution Objects (Section 8.3.1)

●​ Application Objects (Domain Objects): Represent real-world concepts relevant to the

system (e.g., "Incident" in an emergency system).​

●​ Solution Objects: Components not present in the real world but essential for system
function (e.g., user interfaces, databases).​

●​ Process:​

○​ During analysis, identify application objects (entities) and user-visible solution

objects (boundaries, controls).​

○​ During system design, identify platform-specific solution objects.​

○​ During object design, refine and add new solution objects to bridge design gaps.​

2. Specification and Implementation Inheritance (Section 8.3.2)

●​ Specification Inheritance (Interface Inheritance):​

○​ Classify objects into taxonomies (e.g., "Image" as a superclass for "GIFImage"

and "JPEGImage").​

○​ Promotes extensibility through abstract classes and interfaces.​

○​ Example: Implementing multiple image formats using a common interface.​

●​ Implementation Inheritance:​

○​ Reuses code by inheriting from existing classes (e.g., implementing "MySet" by

inheriting from Hashtable).​

○​ Risks tight coupling and unexpected behavior if concepts are unrelated.​

○​ Example Issue: MySet inheriting from Hashtable introduces unnecessary

methods like containsValue() causing inconsistencies.​
 3. Delegation (Section 8.3.3)

●​ Delegation as an Alternative to Inheritance:​

○​ Instead of subclassing, a class delegates specific tasks to another object (e.g.,

MySet using a Hashtable internally).​

○​ Benefits:​

■​ Extensibility: Can switch to other implementations (e.g., a List instead

of a Hashtable).​

■​ Decoupling: Avoids subclassing, ensuring the new class is independent

of the original class.​

○​ Example: MySet uses an internal Hashtable instead of inheriting from it.​

4. The Liskov Substitution Principle (Section 8.3.4)

●​ Definition: If a program works with a superclass, it should also work with its subclasses
without modification.​

●​ Application: Ensures objects of a subclass can be substituted for the superclass without
breaking the system.​

●​ Example: If MySet is a subclass of Hashtable, all operations should behave

consistently to avoid errors.​

5. Delegation vs. Inheritance in Design Patterns (Section 8.3.5)

●​ Use inheritance for:​

○​ Modeling taxonomies (e.g., animal classification).​

○​ Specification inheritance for extending behavior via interfaces.​

●​ Use delegation for:​

 ○​ Reusing code between unrelated concepts.​

○​ Providing flexible and extensible designs without tight coupling.

Key Concepts from "Reuse Activities: Selecting Design Patterns and

Components":

1.​ Design Paradox:​

○​ System design emphasizes stability by dividing a system into independent

subsystems.​

○​ Object design emphasizes flexibility to accommodate future changes.​

○​ This paradox is solved by anticipating changes and designing for them.​

2.​ Common Sources of Change:​

○​ New Vendor/Technology: Replacing commercial components or adapting to

new technologies.​

○​ New Implementation: Improving performance with efficient algorithms after

system testing.​

○​ New Views: Addressing usability issues by creating new ways to present data.​

○​ New Complexity: Expanding the system to handle more complex business logic.​

○​ Errors: Correcting mistakes identified during real-world use.​

3.​ Design Patterns to Handle Changes (Table 8-1):​

 ○​ Bridge Pattern: Decouples abstraction from implementation, allowing multiple
implementations (e.g., for new technologies).​

○​ Adapter Pattern: Converts an existing interface to a new one, enabling reuse of

legacy code.​

○​ Strategy Pattern: Encapsulates algorithms to swap them without altering the

client.​

○​ Abstract Factory Pattern: Manages object creation to maintain compatibility

across object families.​

○​ Command Pattern: Decouples commands from execution, allowing easy

extension of new operations.​

○​ Composite Pattern: Manages hierarchical structures, allowing new elements

without major code changes.​

4.​ Bridge Pattern (Section 8.4.1):​

○​ Purpose: Supports dynamic switching between different implementations.​

○​ Example: In the ARENA system, League data can be stored using stubs, XML
files, or relational databases.​

○​ Structure:​

■​ Abstraction: High-level interface (e.g., LeagueStore).​

■​ Implementor: Abstract interface for concrete implementations.​

■​ ConcreteImplementors: Specific storage types (e.g., XML, JDBC,

stubs).​

○​ Key Benefits:​

■​ Allows early testing with stubs.​

■​ Easily switch storage methods without major code changes.​

5.​ Adapter Pattern (Section 8.4.2):​

 ○​ Purpose: Enables compatibility between incompatible interfaces by acting as a
bridge.​

○​ Example: Adapting a custom MyString class to be compatible with Java’s

sort() method.​

○​ Structure:​

■​ Client: System expecting a specific interface.​

■​ Adapter: Converts the legacy interface to the client’s interface.​

■​ Adaptee: The existing, incompatible component.​

○​ Key Benefits:​

■​ Facilitates reuse of legacy code.​

■​ Minimizes impact on existing code while integrating new components.​

Summary of the Strategy Pattern Implementation:

The Strategy pattern is used to dynamically switch between different network protocols in a
mobile application running on a wearable computer. This design approach separates the logic
for handling various network types and allows future protocol updates without recompiling the
application.

Key Components:

1.​ Client (Mobile Application):​

○​ The wearable computer application that requires network connectivity.​

2.​ Strategy (NetworkInterface):​

○​ Defines a common interface for all network protocols (e.g., local wireless, UMTS,
Ethernet).​

3.​ Context (NetworkConnection):​

○​ Manages the active network connection and delegates network-specific behavior

to the selected NetworkInterface.​
 4.​ Policy (LocationManager):​

○​ Monitors the user's location and available networks.​

○​ Dynamically switches network protocols using setNetworkInterface().​

Workflow:

1.​ The LocationManager detects the current location and identifies the best available
network.​

2.​ It updates the NetworkConnection by invoking setNetworkInterface() to switch to

the appropriate NetworkInterface (e.g., local wireless in the shop, UMTS on the
roadside, or Ethernet for configuration).​

3.​ The NetworkConnection object seamlessly shuts down the current network and
initializes the new one without affecting the main application.​

Advantages of Using the Strategy Pattern:

●​ Dynamic Adaptability: Automatically switches between networks based on location and

cost.​

●​ Extensibility: Easily supports new network protocols by adding new

NetworkInterface implementations.​

●​ Decoupling: Isolates network logic from the main application for better maintainability
and testing.
●​ ********************************************************************************

Object Design: Specifying Interfaces

During object design, the focus shifts from broad system-level tasks to refining individual
objects and their interactions. This stage emphasizes clarity, precision, and
communication to prevent errors while multiple developers work on different parts of the
system simultaneously.

Key Objectives of Interface Specification:

1.​ Identifying Missing Attributes and Operations:​

 ○​ Ensure all necessary data (attributes) and actions (methods) required for the
object’s functionality are defined.​

2.​ Specifying Type Signatures and Visibility:​

○​ Define method parameters, return types, and access control (public, private,
protected) to enforce encapsulation.​

3.​ Specifying Invariants:​

○​ Define conditions that must always hold true for the object throughout its lifecycle
(e.g., "Account balance cannot be negative").​

4.​ Specifying Preconditions and Postconditions:​

○​ Preconditions: Conditions that must be true before a method is called.​

○​ Postconditions: Conditions that must be true after a method completes.​

Object Constraint Language (OCL):

●​ OCL is a formal language used to define invariants, preconditions, and

postconditions in a clear and readable way.​

●​ It complements UML by providing precise, machine-readable specifications.​

Example (Using OCL Notation):

For a BankAccount class:

1.​ Invariant:​
context BankAccount inv: balance >= 0​
(Balance cannot be negative)​

2.​ Precondition (withdraw operation):​

context BankAccount::withdraw(amount: Double) pre: amount > 0​
(Amount to withdraw must be positive)​

3.​ Postcondition (deposit operation):​

context BankAccount::deposit(amount: Double) post: balance =
balance@pre + amount​
 (After deposit, balance increases by the given amount)​

Heuristics for Clear Interface Specification:

●​ Minimalism: Keep interfaces small and focused to avoid complexity.​

●​ Consistency: Follow a uniform style for method names and access levels.​

●​ Completeness: Ensure all required methods and attributes are defined.​

●​ Readability: Use clear, self-documenting names and comments.​

Challenges in Managing Interface Specifications:

●​ Version Control: Track interface changes over time.​

●​ Consistency: Ensure interfaces across subsystems remain compatible.​

●​ Communication: Document interfaces clearly for collaborating teams.​

Would you like a sample C++ implementation showcasing these concepts?

9.1 Introduction: A Railroad Example

The Stuttgart light rail system transition highlights the challenges of evolving infrastructure,
similar to how software interfaces evolve. By drawing parallels between railroads and object
interfaces, we understand how changes in an interface impact the entire system.

Stuttgart's Streetcar to Light Rail Transition (1976-2007)

●​ Reason for Change:​

1.​ Streetcars were slow, shared streets with cars, and had limited passenger
capacity.​

2.​ Light rail offered faster, larger cars on dedicated tracks, providing increased
capacity and predictable schedules.​

●​ Challenges During Transition:​

 1.​ Gauge Compatibility:​

■​ Streetcar: 1000 mm (meter gauge)​

■​ Light Rail: 1450 mm (standard gauge)​

■​ Solution: Installed three rails to accommodate both systems, increasing

switch complexity.​

2.​ Station Platforms:​

■​ Streetcar: Low-entry platforms (street-level access).​

■​ Light Rail: High-entry platforms.​

■​ Solution: Platforms were raised on one end and kept low on the other,
resulting in longer platforms.​

3.​ Signaling System:​

■​ Streetcar: Simple traffic-light signals, independent of train position.​

■​ Light Rail: Centralized train dispatch with track monitoring.​

■​ Solution: Made the new signaling compatible with both systems during
the transition.​

Outcome: The dual-gauge system allowed uninterrupted public transport during the 31-year
conversion, completing in December 2007.

Software Object Interfaces and the Railroad Analogy

Like rail systems, software objects interact through well-defined interfaces. Changes in these
interfaces disrupt services unless the connected systems adapt.

1.​ Wheel Gauge → Object Data Types:​

○​ Mismatch in data types prevents smooth object communication.​

2.​ Platform Height → Method Parameters:​

 ○​ Objects require correctly formatted inputs to function.​

3.​ Signaling System → Object Behavior:​

○​ Changes in expected behavior require retraining or redesign.​

Key Takeaways for Interface Specification:

1.​ Define Clear Boundaries: Ensure each object clearly specifies its services (methods)
and assumptions (preconditions).​

2.​ Plan for Evolution: Like Stuttgart’s dual-compatibility approach, design flexible
interfaces that support future growth.​

3.​ Maintain Consistency: Keep all interacting systems synchronized when interfaces
change.​

Would you like a deeper dive into UML Object Constraint Language (OCL) or how this applies
to modern software design?

9.2 An Overview of Interface Specification

At this stage in system development, various models guide the structure and behavior of the
system. However, these models only provide partial views—object design integrates them into
a coherent and precise framework. The primary objective of interface specification is to
clearly define how objects interact to ensure seamless integration among developers.

Key Models Developed Before Interface Specification

1.​ Analysis Object Model​

○​ Describes entity, boundary, and control objects visible to users.​

○​ Includes object attributes and operations.​

2.​ Subsystem Decomposition​

 ○​ Partitions objects into cohesive subsystems managed by different developer
teams.​

○​ Describes high-level services each subsystem provides.​

3.​ Hardware/Software Mapping​

○​ Identifies system components forming the virtual machine (e.g., classes and
APIs).​

4.​ Boundary Use Cases​

○​ Describes user-centered interactions, including administrative and exceptional

cases.​

5.​ Design Patterns​

○​ Provides reusable object design models addressing specific design issues.​

Core Activities in Interface Specification

1.​ Identify Missing Attributes and Operations​

○​ Analyze each subsystem and object for missing elements.​

○​ Enhance the object design model by adding these attributes and operations.​

2.​ Specify Visibility and Signatures​

○​ Define which operations are accessible to other objects (public) and which are
internal (private).​

○​ Specify the return type, parameters, and input/output behavior of each

operation.​

○​ Goal: Minimize coupling between subsystems while ensuring a simple, clear

interface.​

3.​ Specify Contracts​

 ○​ Define the behavior of operations using constraints (preconditions and
postconditions).​

■​ Preconditions: Conditions before operation execution.​

■​ Postconditions: Expected results after execution.​

○​ Helps ensure correct object interaction and reduces ambiguity.​

Challenges in Object Design

●​ Complexity: More objects, faster changes, and concurrent decision-making increase

complexity.​

●​ Communication Gaps: Independent decisions can cause inconsistencies if not

shared.​

●​ Management Challenge: Consistent and updated information is critical for team-wide

alignment.​

Solution – The Object Design Document

●​ A live document that records the specifications of each object.​

●​ Facilitates knowledge sharing among developers and maintains design consistency.​

Would you like a breakdown of UML Object Constraint Language (OCL) or real-world
examples of interface design?

Key Concepts of Interface Specification (Section 9.3)

1.​ Class Implementor, Class Extender, and Class User (9.3.1)​

○​ Class Implementor: Designs and implements the internal structure and methods
of the class.​

○​ Class User: Invokes public methods of a class while developing another class
(client class).​
 ○​ Class Extender: Creates specialized versions of the class while accessing
protected methods and attributes.​

○​ Example: In an ARENA Game system:​

■​ Game → Implementor (creates the base game class)​

■​ League/Tournament → Users (utilize the Game interface)​

■​ TicTacToe/Chess → Extenders (specialize the Game class).​

2.​ Types, Signatures, and Visibility (9.3.2)​

○​ Types: Define the data type (e.g., int, Player, List).​

○​ Signatures: Tuple of parameter types and return type. Example:​

■​ acceptPlayer(Player): void (takes a Player object, returns

nothing).​

○​ Visibility: Determines access levels:​

■​ - Private: Accessible only within the class (for implementors).​

■​ # Protected: Accessible within the class and subclasses (for extenders).​

■​ + Public: Accessible by all (for users).​

■​ ~ Package: Accessible by classes in the same package.​

3.​ Contracts: Invariants, Preconditions, and Postconditions (9.3.3)​

○​ Invariant: Always true for a class (e.g., maxNumPlayers > 0 in Tournament).​

○​ Precondition: Must be true before method execution (e.g., a player must not be
already accepted).​

○​ Postcondition: Must be true after method execution (e.g., number of players

increases by 1 after adding a player).​

These concepts ensure clarity and consistency in class design across different developer roles.
Here’s a more detailed version of the 15 versatile terms and definitions, giving you deeper
insights and flexibility to use them across technical, academic, and professional settings:

1.​ Algorithm:​
A finite, well-defined sequence of instructions designed to perform a specific task or
solve a problem. Algorithms are the building blocks of computer programs and can
range from simple (sorting) to complex (machine learning models). They focus on
efficiency, accuracy, and scalability.​

✅ Use it when: Talking about any process, logic, or systematic solution.

2.​ Scalability:​
The ability of a system to handle growth efficiently—whether it's an increase in data
volume, user traffic, or complexity. A scalable system performs consistently under
varying loads without major architectural changes.​

✅ Use it when: Discussing growth, performance over time, or expanding capabilities.

3.​ Optimization:​
The process of improving a system or solution to make it faster, smarter, and more
efficient. It applies to code (reducing time complexity), systems (resource allocation), or
processes (workflow improvement).​

✅ Use it when: Describing how to enhance performance, reduce waste, or improve results.
4.​ Abstraction:​
A conceptual model that hides unnecessary complexity and exposes only the
essential features. In coding, it refers to simplifying implementation by focusing on
what a system does rather than how it works.​

✅ Use it when: Explaining simplified processes, user interfaces, or generalized systems.

 5.​ Modularity:​
A design approach where a system is broken down into independent,
interchangeable modules. Each module handles a specific function, allowing easier
debugging, scalability, and reuse.​

✅ Use it when: Discussing system design, maintainability, or component-based

approaches.

6.​ Interoperability:​
The ability of different systems, devices, or platforms to communicate, exchange,
and use information seamlessly. It’s vital in complex ecosystems like IoT, healthcare,
and software integrations.​

✅ Use it when: Talking about compatibility, data sharing, or system communication.

7.​ Data Integrity:​
The accuracy, consistency, and reliability of data throughout its lifecycle. This
involves preventing corruption, ensuring traceability, and maintaining data even after
transfers or modifications.​

✅ Use it when: Discussing database reliability, data protection, or error prevention.

8.​ Latency:​
The time delay between input and output in a system. It affects the responsiveness of
applications—lower latency means faster performance. Common in networks,
databases, and real-time systems.​

✅ Use it when: Explaining delays, system performance, or responsiveness.

9.​ Fault Tolerance:​
The ability of a system to continue functioning despite errors, failures, or
malfunctions. This involves implementing backups, redundancies, and error
handling for reliable operations.​
✅ Use it when: Describing error resilience, disaster recovery, or system stability.
10.​Dynamic Allocation:​
Allocating resources (like memory) at runtime instead of compile time, allowing
systems to adapt to changing demands. It’s essential for managing variable data and
scalability.​

✅ Use it when: Talking about memory management, resource flexibility, or adaptive

systems.

11.​Normalization:​
A process in database management that organizes data to reduce redundancy and
inconsistency by breaking data into smaller tables and establishing relationships.​

✅ Use it when: Explaining data organization, database design, or efficiency

improvements.

12.​Encapsulation:​
A fundamental concept in object-oriented programming where data and methods are
bundled together. It protects internal object details and restricts direct access, enhancing
security and modularity.​

✅ Use it when: Discussing data protection, object-oriented principles, or system design.

13.​Machine Learning:​
A subset of Artificial Intelligence that enables systems to learn from data patterns
and improve their performance without explicit programming. It’s used in predictions,
recommendations, and automation.​

✅ Use it when: Describing data-driven learning, pattern recognition, or automated

decision-making.
 14.​Concurrency:​
The ability of a system to perform multiple tasks simultaneously. This is achieved
through threading, parallelism, and asynchronous operations, improving efficiency in
multitasking environments.​

✅ Use it when: Explaining multitasking, parallel processes, or asynchronous execution.

15.​Compliance:​
The practice of adhering to legal, ethical, or technical standards and regulations. In
tech, it ensures data security, privacy, and system integrity under frameworks like
GDPR or ISO standards.​

✅ Use it when: Talking about legal adherence, ethical practices, or standardized

processes.

✅ Bonus Tip: If you’re ever stuck, start by defining one of these terms and then relate it to the
context of your question. Most technical concepts fit into at least one of these categories!