Skip to content

CS612 – Design of Software Systems

Instructor: Nilotpal Chakraborty
Program: M.Tech in Computer Science & Engineering (CSE) – IIIT Guwahati
Semester: I

This course, primarily known as Software Design, falls under the fundamentals of software engineering. The objective is to be able to talk to employers about the problems and issues involved in building large and complex software systems.

📚 Syllabus Overview

1. What is a System?

A set of interacting or interdependent components forming an integrated whole.

2. What is Software?

Instructions (programs) that tell a computer what to do, along with associated documentation and configuration data.

3. Designing Software

The process of defining the architecture, components, interfaces, and other characteristics of a system.

4. Importance of Software Design

  • Bridges the gap between requirements and implementation.
  • Reduces complexity.
  • Enables quality attributes (performance, security, maintainability).

5. Is Developing Software different from Programming?

Programming is the implementation of a specific solution.
Software Development is the entire process – from understanding requirements to deployment and maintenance.

6. SDLC (Software Development Life Cycle) – 🔑 IMP

Click to expand - **6.1 Requirement Phase** – Gathering and analysing what the system should do. - **6.2 Design Phase** – Creating the blueprint for the system. - **6.3 Implementation/Development Phase** – Writing the actual code. - **6.4 Testing Phase** – Verifying that the system works as intended. - **6.5 Deployment Phase** – Releasing the system to production. - **6.6 Maintenance Phase** – Ongoing support, bug fixes, and updates.

7. Software Design Process – System Design

High-level design – defining the system architecture, modules, and their interactions.

8. Software Design Process – Detailed Design

Low-level design – specifying the internal details of each module (data structures, algorithms, interfaces).

9. Principles of Software Design – 🔑 IMP

Click to expand – Fundamental vs Design Principles #### 9.1 Modularity Breaking a system into smaller, independent, reusable modules. #### 9.2 Encapsulation Hiding internal details and exposing only what is necessary. #### 9.3 Abstraction Simplifying complex reality by modelling classes appropriate to the problem. #### 9.4 Cohesion How closely the elements of a module belong together. High cohesion = good. #### 9.5 Coupling How much one module depends on another. Low coupling = good. #### 9.6 DRY – Don't Repeat Yourself Every piece of knowledge must have a single, unambiguous representation. #### 9.7 YAGNI – You Ain't Gonna Need It Don't implement functionality until it is actually needed. #### 9.8 Separation of Concerns Breaking a program into distinct sections that address separate concerns. #### 9.9 KISS – Keep It Simple, Stupid! Simplicity should be a key goal. #### 9.10 Law of Demeter A module should not know about the internal details of other modules.

10. Software Design Paradigms

| Paradigm | Key Principle | Modularity | Abstraction | Flexibility | Common Use Cases | |----------|---------------|------------|-------------|-------------|------------------| | **Procedural** | Sequence of steps | Low | Low | Rigid | Simple apps, scripting | | **Object Oriented** | Objects & classes | Medium-High | Medium | High | Complex, large systems | | **Component-Based** | Reusable modules | High | Medium | Very high | Enterprise, distributed | | **Model Driven** | Abstract modeling | Very high | Very high | High | Platform-neutral, automated |
Summary 1. **Procedural** – Best for smaller, well‑defined tasks with straightforward data flow, but lacks modularity for scaling. 2. **Object‑Oriented** – Excels in modelling complex scenarios, offering better abstraction and reusability. 3. **Component‑Based** – Favoured for large‑scale, modular, enterprise systems where plug‑and‑play components are desired. 4. **Model‑Driven** – Advances abstraction further, enabling automation and flexibility across platforms and technologies.

11. Software Architecture – Why Importance and Stakeholders

Click to expand #### 11.1 Kruchten's 4+1 View Model – 🔑 IMP | View | Description | UML Diagram | |------|-------------|-------------| | **Logical** | User's perspective – functional requirements | Class Diagram | | **Process** | Dynamic behaviour – non‑functional requirements | Activity/Sequence Diagram | | **Development** | Developer's perspective – modules & structures | Component/Package Diagram | | **Physical** | Deployment – hardware & network mapping | Deployment Diagram | | **Scenario** | Validation – use cases | Use Case Diagram | #### 11.2 Structures - **Module** – code organisation - **Component‑and‑Connector** – runtime interactions - **Allocation** – mapping software to hardware #### 11.3 Elements - Components + Connectors + Interfaces + Nodes #### 11.4 Relationships - Dependency + Communication + Containment + Inheritance

12. Software Architecture Styles

A set of rules for organising the structure of a system.

13. Software Architecture Patterns – 🔑 IMP

Click to expand - **13.1 Layered** – Separation into layers (Presentation, Business, Data). - **13.2 Monolithic** – Single deployable unit. - **13.3 SOA – Service Oriented Architecture** – Services communicating over a network. - **13.4 Microservice** – Independent, loosely coupled services. - [E‑Commerce Microservices Architecture](https://medium.com/design-microservices-architecture-with-patterns/microservices-architecture-2bec9da7d42a) - [UML Deployment Diagram](https://www.softwareideas.net/a/1580/ecommerce-microservices-uml-deployment-diagram-) - [Hygraph Blog](https://hygraph.com/blog/ecommerce-microservices-architecture) - **13.5 Client‑Server** – Clients request services from a server. - **13.6 Master‑Slave** – One master controls multiple slaves. - **13.7 Peer‑to‑Peer** – Distributed architecture without central control. - **13.8 MVC – Model View Controller** – Separation of data, UI, and control logic. #### 13.9 Other Architectural Styles - **Event‑Bus** – Components communicate via events. - **Pipe‑Filter** – Data flows through a chain of processing stages. - **Space‑Based** – Distributed shared memory. - **Blackboard** – Shared knowledge base with multiple problem solvers. - **Broker** – Mediation between service providers and consumers. - **Microkernel** – Minimal core with plug‑in extensions. - **Hybrid** – Combination of multiple styles.

14. Software Architecture Decisions – Key Factors + Trade‑Offs

Balancing quality attributes (performance vs security, scalability vs maintainability, etc.).

15. Software Design Patterns

Creational Patterns – Click to expand - **Factory Method** – Creates objects without specifying the exact class. - **Abstract Factory** – Creates families of related objects. - **Builder** – Constructs complex objects step by step. - **Prototype** – Clones existing objects. - **Singleton** – Ensures a class has only one instance.
Structural Patterns – Click to expand - **Adapter** – Converts one interface to another. - **Bridge** – Separates abstraction from implementation. - **Composite** – Treats individual objects and compositions uniformly. - **Proxy** – Provides a surrogate or placeholder for another object. - **Decorator** – Adds behaviour dynamically. - **Facade** – Provides a simplified interface to a complex system. - **Flyweight** – Shares fine‑grained objects efficiently.
Behavioural Patterns – Click to expand - **Chain of Responsibility** – Passes requests along a chain of handlers. - **Command** – Encapsulates a request as an object. - **Iterator** – Traverses a collection sequentially. - **Mediator** – Centralises communication between objects. - **Memento** – Captures and restores an object's state. - **Observer** – Notifies dependents of state changes. - **State** – Allows behaviour to change when state changes. - **Strategy** – Encapsulates interchangeable algorithms. - **Template Method** – Defines a skeleton algorithm. - **Visitor** – Adds operations to objects without modifying them.

16. Software Design Anti‑Patterns

Click to expand - **16.1.1 The God Class/Object** – Knows too much, controls too many aspects → hard to maintain. - **16.1.2 Spaghetti Code** – Disorganised, unstructured code → difficult to extend. - **16.1.3 Golden Hammer** – Cognitive bias – unwilling to learn better technologies. - **16.1.4 Dead Code** – No longer executed (unreachable, redundant, obsolete, unused). - **16.1.5 Lava Flow** – Accumulation of dead/obsolete code – fear of deletion. - **16.1.6 Boat Anchor** – Kept for future needs that never materialise. - **16.1.7 Copy‑Paste Programming** – Repeated similar code segments.

17. Bad Code Smell

Click to expand - **17.1 Bloaters** – Too much code, methods, classes → hard to work with. - **17.2 Object‑Orientation Abusers** – Incomplete/incorrect OOP implementation. - **17.3 Change Preventers** – A change in one place requires changes in many others. - **17.4 Dispensables** – Unnecessary comments/items that clutter the code. - **17.5 Couplers** – Excessive coupling between classes.

18. Clean Code

Characteristics - Obvious to other programmers. - Doesn't contain duplication. - Contains a minimal number of classes and moving parts. - Passes all test cases. - Easier and cheaper to maintain.

19. Code Refactoring

Techniques – Click to expand - **19.1.1 Composite Method** – Composing multiple methods (long methods are root of many problems). - **19.1.2 Moving Features Between Objects** – Safely move functionality, create new classes, hide implementation. - **19.1.3 Organising Data** – Replace primitives with rich classes, reduce coupling. - **19.1.4 Simplifying Conditional Expressions** - **19.1.5 Simplifying Method Calls** - **19.1.6 Dealing with Generalisation** – Abstraction methods.

20. Object Oriented Design – Classes + Objects

Principles of OOD:

  • Encapsulation (How) – Data hiding + methods via access modifiers (Public/Private/Protected).
  • Abstraction (What) – Simplified representation (methods).
  • Inheritance – Reusability (subclasses with shared traits but unique behaviours).
  • Polymorphism – Method overriding and overloading – multiple forms of behaviour.

21. SOLID Principles – 🔑 MOST IMP

Click to expand – One BTech girl got placed at Amazon due to this! - **21.1 SRP – Single Responsibility Principle** A class should have only one reason to change – one responsibility/functionality. - **21.2 OCP – Open/Closed Principle** Open for extension, closed for modification – add new functionality without changing existing code. - **21.3 LSP – Liskov Substitution Principle** – 🔑 IMP Derived classes should be substitutable for their base classes. Subclasses should remain compatible with the behaviour of the superclass. When overriding a method, extend the base class behaviour rather than replacing it entirely. - **21.4 ISP – Interface Segregation Principle** Interfaces should be specific rather than general – avoid forcing clients to depend on unused methods. - **21.5 DIP – Dependency Inversion Principle** High‑level and low‑level modules should depend on abstractions, not details.

22. Real‑World Deployments of Object Oriented Design

  • Facebook · Uber's Mobile App · WordPress · Tesla

23. Component Based Design

  • Emphasises Separation of Concerns.
  • Characteristics: Reusability · Modularity · SoC · Scalability · Maintainability

24. Real‑World Deployments of CBD

  • Microservices – Netflix, E‑commerce platforms (Shopify)
  • Enterprise JavaBeans (EJB) – Enterprise apps
  • Component‑Based UI – React
  • SOA – Government services (SOAP‑based)

25. Component Models and Frameworks

Defines rules and guidelines for creating and managing components.

Characteristics: Interface · Behaviour · Composition

  • Object‑Oriented: CORBA, EJB
  • Service‑Oriented: SOA
  • UI Development: Web Components, React Components

27. Frameworks for Component Based Design

  • Spring Framework (Java) · .NET Component Model

28. Principles of Designing Components for Modularity

  • SRP · Loose Coupling · High Cohesion · Separation of Interface and Implementation

29. Best Practices for Modular Design

  • Well‑defined interfaces.
  • Design components to be stateless when possible.
  • Follow SOLID principles.

30. Integration of Components

  • Synchronous – Real‑time (method calls, RPC).
  • Asynchronous – Messages/events (decoupled).

31. Inter‑Component Communication

  • Direct Method Invocation · Middleware (Message Brokers) · Event Bus · RESTful APIs · Microservices

32. Model‑Driven Design

  • Platform‑Independent Models (PIM) – Technology‑agnostic.
  • Platform‑Specific Models (PSM) – Refined for a specific platform.

33. Modelling Languages: UML & DSL

  • DSL – HTML/CSS, SQL.
  • Benefits: SoC · Standardisation · Expressive · High‑Level Abstraction · Widely Supported

34. Model Transformations

  • Model‑to‑Model: PIM → PSM
  • Model‑to‑Text: Code generation

35. Code Generation (from PSM)

Benefits: Reduces manual coding · Ensures consistency · Speeds up development

36. Quality Attributes – Non‑Functional Requirements

37. Importance of Quality Attributes

  • User Satisfaction · System Longevity · Business Success

38. Types of Quality Attributes

Click to expand - **A. System Quality Attributes** (SSMRP) – Performance · Scalability · Reliability · Maintainability · Security - **B. User Quality Attributes** (UUX) – Usability · User Experience (UX) - **C. Operational Quality Attributes** (AI) – Availability · Interoperability

39. Trade‑Offs between Quality Attributes

  • Performance vs Security · Usability vs Security · Scalability vs Maintainability

40. Designing for Scalability

  • Types: Horizontal (Scale Out) · Vertical (Scale Up)
  • Techniques: Load Balancing (Round‑Robin, Least Connections, Geo‑based) · Database Scalability (Replication, Sharding) · Partitioning · Caching

41. Designing for Performance

  • Metrics: Latency · Throughput · Resource Utilisation
  • Techniques: Performance Profiling · Benchmarking · Database Optimisation · Efficient Algorithms · Data Compression · Queuing · Throttling

42. Security Design Principles

Click to expand – CIA Triad 1. **Confidentiality** – Sensitive to authorised users. 2. **Integrity** – Protection from tampering. 3. **Availability** – Accessible when needed. 4. **Least Privilege** 5. **Authentication** 6. **Authorization** 7. **Encryption** – At Rest / In Transit 8. **Input Validation & Sanitisation** 9. **IDS / IPS** 10. **Security Auditing & Logging**

43. Designing for Usability

  • Key Aspects: Learnability · Efficiency · Memorability · Error Management · Satisfaction
  • Techniques: User‑Centred Design · Consistency · Standards · Responsive Design · Adaptive Design · Immediate Feedback · Error Prevention · Accessibility

44. Designing for Reliability

  • Metrics: MTBF · MTTR · Availability (99.999%)
  • Techniques: Redundancy · Failover · Fault Tolerance · Proactive Monitoring · Automated Recovery · Graceful Degradation

45. Designing for Maintainability

Click to expand **Key Aspects**: Modifiability · Readability · Testability · Extensibility · Supportability **Techniques**: - Modular Design - Clean Code Practices - Comprehensive Documentation - Design Patterns - SoC - Consistent Coding Standards - Version Control - Continuous Integration - **Refactoring** – Extract Method, Rename Variables, Remove Dead Code - Backward Compatibility (Deprecation Warnings, Versioned APIs) **Challenges**: Balancing Short‑term vs Long‑term · Managing Complexity · Dealing with Legacy Code **Benefits**: Reduced Maintenance Costs · Faster Bug Fixes · Improved Productivity · Increased Longevity

46. Design Validation

Click to expand **Objective**: Validate that the design aligns with intended functionality, performance, and quality attributes. **Key Aspects**: - All components interact as intended. - Detects flaws early. - Validates architecture against requirements. **Importance** (EER): Early Detection · Ensuring Alignment · Risk Mitigation **Testing Strategies** (UUISPF): - Unit Testing - Integration Testing - System Testing - Functional Testing - Performance Testing - Usability Testing **Popular Tools** (MCAR): - Model‑Based Testing Tools - Code Analysis Tools - Automated Test Generation from Models - Regression Testing Automation

47. Distributed Systems

Click to expand – Overview **Characteristics** of Distributed Systems. **Architecture Models**. **Middleware**. **Communication** in DS. **Data Serialisation**. **Challenges**. **Design Patterns** for DS.

48. SDLC Models

Click to expand - **Waterfall Model** – Sequential phases. - **Iterative Waterfall Model** – Repeated refinement. - **Traditional SDLC** – Conventional approach. - **Agile Software Development** – Iterative, incremental. #### Agile Methodology **Benefits**: 1. Improved Quality 2. Faster Time‑to‑Market 3. Increased Customer Satisfaction 4. Enhanced Team Collaboration **Agile Manifesto's 4 Core Values**: 1. **Individuals and interactions** over processes and tools. 2. **Working software** over comprehensive documentation. 3. **Customer collaboration** over contract negotiation. 4. **Responding to change** over following a plan. **The 12 Agile Principles**: 1. Satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. 3. Deliver working software frequently (weeks rather than months). 4. Business people and developers work together daily. 5. Build projects around motivated individuals. 6. Face‑to‑face conversation is the most efficient way to convey information. 7. Working software is the primary measure of progress. 8. Maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design. 10. Simplicity – maximising the amount of work not done – is essential. 11. Self‑organising teams produce the best architectures. 12. Regular reflection and adjustment. **Agile Frameworks**: - **Scrum** – Roles (Product Owner, Scrum Master, Dev Team) · Artifacts (Product Backlog, Sprint Backlog, Increment) · Events (Sprint Planning, Daily Standup, Sprint Review, Sprint Retrospective) - **Kanban** – Visualise Workflow · Limit WIP · Manage Flow · Continuous Improvement - **XP (Extreme Programming)** – TDD · Pair Programming · CI · Refactoring · Simple Design **Agile Metrics** (BPQWT): - Productivity: Velocity, Cycle Time, Lead Time - Quality: Defect Density, Escaped Defects, Code Coverage - Workflow: WIP, Cumulative Flow Diagram - Team Health: Team Happiness, Sprint Predictability - Business Value: Delivered Value, CSAT, NPS **Challenges in Agile Implementation**: 1. Organisational Resistance 2. Inconsistent Understanding of Agile 3. Scaling Agile 4. Technical Challenges 5. Managing Stakeholder Expectations 6. Challenges with Agile Roles

📖 References

Last updated: May 2026