History and Overview
CPSOFT30- Software Design
Learning Objective:
• Define what software design is.
• Explain the evolution and major milestones in software design.
• Recognize the importance of software design in the development life
cycle.
• Identify key roles and responsibilities involved in software design.
What is Software Design?
• Software design is the process of envisioning and defining software
solutions to one or more problems.
Role in software engineering
• It is the phase where the system architecture and component-level
design are defined.
• Output: design documents, diagrams, pseudo-code, etc.
Importance of Software Design
• Sets the foundation for coding
• Affects maintainability, scalability, and performance
• Prevents errors and minimizes rework
• Bridges requirements and actual implementation
Evolution of Software Design
• 1950s-60s: Early programming (assembly, structured programming)
• 1970s: Emergence of structured design (Yourdon, DeMarco)
• 1980s: Rise of object-oriented programming (OOP)
• 1990s-2000s: Design patterns, Agile design, UML
• Today: Model-Driven Development (MDD), software architecture, and
DevOps integration
Milestones and Contributors
• Structured Design: Tom DeMarco, Ed Yourdon
• OOP: Grady Booch, Alan Kay
• Design Patterns: Gang of Four (Gamma, Helm, Johnson, Vlissides)
• UML: Object Management Group (OMG)
Software Design in the SDLC
• Design phase bridges the requirements and implementation.
• Produces UML, architecture, and models.
Why the Design Phase Matters?
Good Design Leads To:
• Easier testing and debugging
• Scalability and performance
• Better team collaboration
Poor Design Can Cause:
• High maintenance cost
• Rigid and unscalable systems
• Difficult testing or modification
Key Deliverables in Design
• Use case diagrams / system flow diagrams
• Class diagrams
• Sequence diagrams
• Interface design / mockups
• Pseudo-code / structure charts
Relevance to CpE Practice
• Embedded systems, mobile apps, databases all rely on good design
• Cross-platform integration requires robust architecture
• Design is essential for system reliability, cost-efficiency, and
performance
Summary
• Software design is critical in building reliable, scalable systems
• It has evolved from basic structure to architectural models
• Good design bridges ideas and code
QUESTION?
Tools, Standard, and Engineering
Constraints
CPSOFT30-Software Design
Learning Objective:
• Identify commonly used tools for software design and development.
• Understand the role of software engineering standards.
• Recognize various engineering constraints in software projects.
• Apply appropriate tools and standards to small-scale software design.
Why are Tools, Standards, and Constraints
Crucial?
• They shape design decisions.
• Impact on project success, quality, and efficiency.
• Avoiding "reinventing the wheel" and ensuring consistency.
Software Design Tools
• Software applications and methodologies that aid in the design
process
Introduction to Software Design Tools
• IDEs: Visual Studio Code, PyCharm, NetBeans
• Version Control: Git, GitHub, GitLab
• UML/Modeling Tools: Lucidchart, StarUML, Visual Paradigm
• Project Management: Trello, Jira
• Prototyping/UI/UX Design Tools: Figma, Adobe XD, Sketch,
Balsamiq.
Choosing the Right Tools:
• Project size and complexity.
• Team familiarity and expertise.
• Integration with existing workflows.
• Cost and licensing.
Software Engineering Standards
Agreed-upon rules, guidelines, or characteristics for software design
and development.
Why Standards?
• Consistency: Across projects, teams, and time.
• Quality: Adherence to best practices, reducing defects.
• Maintainability: Easier to understand, modify, and extend.
• Interoperability: Systems can work together.
• Compliance: Meeting regulatory or industry requirements.
Types of Standards:
• IEEE 830: Software Requirements Specification
• IEEE 1016: Software Design Descriptions
• ISO 12207: Software Lifecycle Process
• Why standards matter in collaborative development
• International Organization for Standardization (ISO) 9126
Engineering Constraints
Limitations or boundaries in design requirements
Categorization of Constraints:
• Technical Constraints:
• Hardware Limitations: Processing power, memory, storage, network bandwidth.
• Software Stack: Operating system, programming language, frameworks, libraries.
• Performance Requirements: Response time, throughput, scalability.
• Security Requirements: Encryption, access control, vulnerability mitigation.
• Reliability & Availability: Uptime, fault tolerance, disaster recovery.
• Data Volume: How much data will the system handle?
Business Constraints:
• Budget: Financial resources available for development.
• Timeline/Schedule: Project deadlines.
• Market Demands: Time-to-market, competitive landscape.
• Regulatory Compliance: GDPR, HIPAA, financial regulations.
• Organizational Policies: Internal governance, existing infrastructure.
• User Constraints:
• Usability: User experience, accessibility.
• User Environment: Devices, network conditions, technical proficiency of
users.
• Operational Constraints:
• Maintainability: Ease of fixing bugs and adding new features.
• Deployability: How easily can the software be deployed?
• Supportability: How easy is it to support the system in production?
Impact of Constraints on Design:
• Constraints often force trade-offs (e.g., performance vs. development
time, security vs. usability).
• They define the solution space.
• Crucial to identify and prioritize constraints early in the design phase.
Strategies for Handling Constraints:
• Prioritization: Which constraints are non-negotiable?
• Negotiation: Can some constraints be relaxed?
• Prototyping/Spikes: Experimenting to understand feasibility.
• Architectural Patterns: Choosing patterns that address specific
constraints (e.g., microservices for scalability).
Case Example – Design with Constraints
Scenario: Designing a Smart Home Energy Management System
(SHEMS)
Imagine your team is tasked with designing a Smart Home Energy
Management System (SHEMS). This system will monitor energy
consumption from various appliances, integrate with smart meters, and
allow homeowners to control devices to optimize energy usage and
reduce electricity bills. The core of the system is a central hub device
that communicates with sensors and actuators throughout the home.
Key Engineering Constraints and Their
Design Implications:
1. Cost (Business Constraint):
• Constraint: The SHEMS hub and associated sensors/actuators must be
affordable for the average consumer to ensure market adoption. This
means keeping Bill of Materials (BOM) low.
• Design Implications:
• Hardware Selection: Choose low-cost, readily available microcontrollers (e.g.,
ESP32, Raspberry Pi Zero W), cost-effective wireless modules.
• Software Optimization: Write highly optimized, lean code to run efficiently on
resource-constrained, lower-cost hardware, minimizing the need for more powerful
(and expensive) processors or larger memory.
• Manufacturing Process: Design for ease of manufacturing and assembly to reduce
production costs.
2. Power Consumption (Technical Constraint - Critical for Battery-Powered Sensors):
Constraint: Many sensors (e.g., temperature, occupancy) will be battery-powered and
need to last for months or years without replacement. The central hub also needs to be
energy-efficient.
• Design Implications:
• Low-Power Microcontrollers: Select MCUs with multiple low-power modes (sleep, deep sleep)
and efficient power management units.
• Wireless Protocols: Prioritize low-power wireless communication protocols like Zigbee, Z-Wave, or
Bluetooth Low Energy (BLE) over Wi-Fi for battery-operated devices, as they consume less power
for short bursts of data.
• Event-Driven Architecture: Design sensors to wake up only when an event occurs (e.g.,
temperature change, motion detected), transmit data quickly, and then return to a low-power
state.
• Firmware Optimization: Aggressively optimize firmware to minimize active time and CPU cycles.
3. Real-Time Response & Latency (Technical Constraint):
Constraint: Critical actions (e.g., turning off a device when a peak energy
price alert is received, or responding to a manual command) must happen
with minimal delay (e.g., sub-second response time).
• Design Implications:
• Local Processing (Edge Computing): Perform immediate control logic and data
processing directly on the SHEMS hub (at the "edge" of the network) rather than
relying solely on cloud processing, to minimize network latency.
• Efficient Communication Protocols: Use lightweight, efficient communication
protocols for local device control (e.g., MQTT, CoAP) that are optimized for
constrained networks and devices.
• Real-Time Operating System (RTOS): For the hub, consider using an RTOS to ensure
predictable task scheduling and guaranteed response times for critical operations.
4. Security & Privacy (Technical & Regulatory Constraint):
Constraint: Protect sensitive energy consumption data, prevent unauthorized
access to home controls, and comply with data privacy regulations.
• Design Implications:
• Encryption: Implement strong encryption for all data in transit (e.g., TLS/DTLS for network
communication) and at rest (e.g., encrypted flash memory on the hub).
• Authentication & Authorization: Secure authentication mechanisms for users and devices.
Implement device-level authentication (e.g., mutual TLS) to ensure only trusted devices can
join the network.
• Secure Boot & Firmware Updates: Ensure the hub's firmware can only be updated with
cryptographically signed images to prevent malicious code injection. Implement secure boot
processes.
• Data Minimization: Collect and store only the necessary data, and anonymize or aggregate
data where possible.
5. Interoperability & Ecosystem (Technical & Market Constraint):
Constraint: The SHEMS needs to integrate with a variety of existing smart
home devices (lights, thermostats) and potentially different smart meter
standards.
• Design Implications:
• Standard Protocols: Support widely adopted smart home protocols like Zigbee, Z-
Wave, Wi-Fi, and potentially Matter/Thread for device communication.
• Open APIs: Provide well-documented APIs for third-party integration, allowing other
smart home platforms or services to interact with the SHEMS.
• Modular Design: Design the software architecture with clear interfaces between
modules responsible for different communication protocols or device types, making
it easier to add support for new devices.
Best Practices
• Early Identification: Identify tools, relevant standards, and critical constraints at
the beginning of the design process.
• Documentation: Document design decisions, especially those influenced by
constraints and standards.
• Iterative Approach: Design is rarely a one-shot process; revisit and refine as
understanding evolves.
• Continuous Learning: Stay updated on new tools, evolving standards, and
emerging technologies.
• Communication: Foster clear communication within the team about design
choices and their rationale.
• Balance: Strive for a balance between idealism (perfect design) and pragmatism
(achievable design within constraints).
Relevance to CpE Practice
• CpEs often deal with embedded, IoT, and systems integration
• Standards help maintain cross-team compatibility
• Awareness of hardware/software constraints is essential
Summary
• Tools improve development efficiency
• Standards ensure clarity and quality
• Constraints guide design scope and feasibility
Seatwork
• 221 Thursday
• 222 Friday
QUESTION?
Programming Construct and
Paradigms
CPSOFT30-Software Design
Learning Objective:
• Differentiate various programming paradigms.
• Identify core programming constructs used in software design.
• Apply logic structures in program planning.
• Recognize the benefits and limitations of each paradigm.
Programming Constructs
• A programming construct is a basic building block used to create
computer programs. These constructs define the structure and flow
of a program, helping developers control how code is executed.
What is a Programming Paradigm?
- A style or way of programming
- Affects how problems are analyzed and solutions are structured
Types:
• Procedural
• Structured
• Object-Oriented
• Event-Driven
Structured Programming
• Originated to reduce spaghetti code
• Uses: sequence, selection, and iteration
• Emphasizes clarity, control flow
Example: Pascal, early C
Procedural Programming
• Based on procedures (functions/subroutines)
• Code is organized into reusable blocks
• Encourages modularity and reuse
Languages: C, Python (procedural style)
Object-Oriented Programming (OOP)
• Models real-world entities as objects
• Uses classes, encapsulation, inheritance, polymorphism
• Promotes modularity, reusability, and abstraction
Languages: Java, Python, C++
Key Constructs in All Paradigms
• Sequence: Step-by-step execution
• Selection: if, else, switch
• Iteration: for, while, do-while
• Modularization: functions, methods, procedures
Paradigm Comparison Table
Feature Procedural OOP
Focus Functions Objects
Data Handling Global/Local Private/Public
Reusability Limited High (Inheritance)
Example Lang C Java, Python
Application in Software Design
• Small tools or scripts: often procedural
• Large systems or frameworks: OOP preferred
• CpEs benefit from understanding both (e.g., firmware vs. enterprise
systems)
Design Approaches
➢Top-Down Design (Decomposition)
• Starts with the overall system and breaks it down into smaller, more
manageable sub-systems or modules. Each module is then further
decomposed until the lowest level of detail is reached.
• Process: Define the main function, then identify major sub-functions, and
continue breaking them down.
Benefits:
• Easier to understand the overall system structure.
• Facilitates early identification of major components.
• Good for large, complex systems.
➢Bottom-Up Design (Composition):
• Starts by designing the most basic or atomic components first, and then
integrates these components to build higher-level modules, eventually
forming the complete system.
• Process: Identify fundamental utilities or building blocks, then combine
them to create more complex functionalities.
Benefits:
• Reusable components are identified early.
• Components can be thoroughly tested in isolation.
• Useful when existing libraries or components are available.
➢Object-Oriented Design (OOD)
• Based on the concept of objects (real-world entities with attributes
and behaviors).
• Process:
• Identify the objects (e.g., Customer, BankAccount).
• Define classes with attributes (data) and methods (functions).
• Model relationships between classes using inheritance, encapsulation, and
polymorphism.
• Advantage: Encourages modularity, reusability, and scalability.
➢Structured Design
• Focuses on using structured methods like Data Flow Diagrams (DFDs)
and modular decomposition to design systems.
• Key Features:
• Emphasizes functions and data flow.
• Follows the principle of dividing the system into smaller, well-defined
modules.
• Advantage: Makes the design easy to understand and maintain.
The Problem-Solving Process in Software
Design
Common Problem-Solving Strategies
1. Brute-Force Approach:
• Concept: Systematically check every possible solution until the correct one is found or all
possibilities are exhausted.
• Characteristics: Simple to implement, guarantees a solution if one exists.
2. Divide and Conquer:
Concept: Break a large problem into smaller, independent sub-problems of the same type.
Solve each sub-problem recursively, then combine their solutions to solve the original problem.
Characteristics: Efficient for many problems, often leads to elegant recursive solutions.
3. Greedy Approach:
Concept: Make the locally optimal choice at each step, hoping that these local choices will lead
to a globally optimal solution.
Characteristics: Simple and fast, but doesn't always guarantee the globally optimal solution.
4. Dynamic Programming:
• Concept: Solve complex problems by breaking them down into simpler, overlapping sub-problems. Store the results of these
sub-problems to avoid redundant computations.
• Characteristics: Efficient for problems with optimal substructure and overlapping sub-problems.
5. Backtracking:
• Concept: Explore all possible solutions incrementally. If a partial solution cannot lead to a complete solution, "backtrack" and
try another path.
• Characteristics: Useful for problems that require finding all possible solutions or a specific solution by trial and error.
6. Heuristics:
• Concept: Rule-of-thumb approaches that provide a good-enough solution, especially for complex problems where optimal
solutions are computationally expensive or impossible to find.
• Characteristics: Not guaranteed to be optimal, but often provides practical and efficient solutions.
7. Abstraction:
• Concept: Focus on essential features and hide unnecessary details.
• Design Implication: Creating interfaces, abstract classes, APIs; simplifying complex systems by presenting only relevant
information.
Summary
• Programming paradigms shape how we solve problems
• Structured and procedural are foundational
• OOP supports large, scalable, and maintainable designs
ASSESMENT
• Quiz 1 on next lecture class
• Coverage L1 to L3
• 20 items
QUESTION?
