04. SEN418 Software Design.pdf

SEN418 Business Application Design and Development Software Design  Agenda ▪ Introduction ▪ Principles of Good Software Design ▪ Software Design vs System Design ▪ Software Design Principles ▪ Popular Software Design Patterns ▪ Whic...

SEN418 Business Application Design and Development Software Design  Agenda ▪ Introduction ▪ Principles of Good Software Design ▪ Software Design vs System Design ▪ Software Design Principles ▪ Popular Software Design Patterns ▪ Which Pattern Should I Use? ▪ Successful Examples 2/39  Introduction ▪ Software architecture and software design are critical aspects of software engineering. ▪ They involve the high-level design of software systems and their components. ▪ The goal of software architecture and software design is to create systems that are reliable, scalable, maintainable, and performant. ▪ Architects and designers are responsible for creating and maintaining the software architecture and system design. ▪ Good software architecture and software design can have a significant impact on the success of a software project. 3/39  Software Architecture ▪ Software architecture is the high-level structure of a software system. ▪ It describes the system's components, their interactions, and their relationships. ▪ Software architecture provides a roadmap for software development. ▪ It is a blueprint for designing, implementing, and maintaining a software system. ▪ Good software architecture should be flexible, adaptable, and able to accommodate changing requirements. 4/39  Software Architectural Patterns ▪ Software architecture pattern is a reusable solution to a recurring software design problem. ▪ It represents a set of architectural design decisions that provide a solution to a particular problem. ▪ Architecture patterns define the structure of the system, the components, their relationships, and the principles and guidelines governing their interactions. ▪ Patterns promote the principles of good software design, including modularity, scalability, maintainability, and extensibility. ▪ By following a well-known architecture pattern, developers can benefit from the experience of others, reduce development time, and build more robust and reliable software systems. 5/39  Common Architectural Patterns 1. Layered Architecture Pattern 2. Client-Server Architecture Pattern 3. Peer-to-peer (P2P) Architecture Pattern 4. Microservices Architecture Pattern 5. Event-Driven Architecture Pattern 6. Service-Oriented Architecture Pattern 7. Model-View-Controller (MVC) Architecture Pattern 8. Repository Architecture Pattern 9. Publisher-Subscriber Architecture Pattern 10. Pipe and Filter Architecture Pattern 6/39  Software Design ▪ Software design is the process of creating a plan for how to implement a software system's functionality and requirements. ▪ It involves defining the structure, behavior, and interaction of the software components that make up the system. ▪ Software design is typically done at a lower level of abstraction than system design and is focused on the implementation details of the software system. ▪ Software design is a critical step in the software development process and has a significant impact on the overall quality and maintainability of the software system. 7/39  Principles of Good Software Design 1. Simplicity - Simple software designs are easier to understand, maintain, and extend. 2. Modularity - Software should be divided into modules that are self-contained and have well-defined responsibilities. 3. Encapsulation - Information should be hidden from other modules or classes that don't need to know about it. 4. Abstraction - Software design should focus on essential features and ignore implementation details. 5. Cohesion - Modules or classes should be organized around a single, well-defined purpose. 6. Low Coupling - Modules or classes should be loosely coupled, meaning they should depend on each other as little as possible. 7. Flexibility - Software should be easily modified or extended. 8. Reusability - Modules or classes should be designed to be reusable in other parts of the software or in other applications. 9. Maintainability - Software design should be focused on making it easy to maintain and fix bugs. 10. Testability - Software should be designed to be easily testable, so developers can verify its correctness and behavior. 8/39  Before Going to Design… Object Oriented Concepts ▪ Classes: Blueprints for creating objects (specific instances of a class). They define properties and behaviors for objects. ▪ Objects: Instances of classes that represent specific examples of the concept the class describes. They have states and behaviors. ▪ Inheritance: A way to form new classes using classes that have already been defined. The new class inherits the properties and behavior of the existing class. ▪ Encapsulation: Bundling of data (attributes) and methods (functions) that operate on the data into a single unit or class, and restricting access to some of the object's components. ▪ Polymorphism: The ability to use a shared interface for different underlying forms (data types). For example, function or method can pass objects of any of the polymorphic classes as a parameter. ▪ Abstraction: The concept of hiding the complex reality while exposing only the necessary parts. It’s about making a model more understandable by removing unnecessary details. 9/39  Software Design vs System Design ▪ Software design and system design are two related but distinct aspects of the software development process. ▪ Software design focuses on the design of individual software components and modules, such as classes, functions, and algorithms. ▪ System design, on the other hand, is concerned with the design of the entire software system, including its architecture, components, modules, interfaces, and data. ▪ Software design is more concerned with the implementation details of the software system while system design is more concerned with the overall structure and behavior of the software system. 10/39  Software Design Principles ▪ Software design principles are guidelines that help developers create better 1. Single Responsibility Principle (SRP) software designs by promoting desirable 2. Open-Closed Principle (OCP) software qualities such as modularity, reusability, and maintainability. 3. Liskov Substitution Principle (LSP) ▪ These principles are often based on 4. Interface Segregation Principle (ISP) proven practices and observations from 5. Dependency Inversion Principle (DIP) successful software development 6. Composition over Inheritance Principle (CoIP) projects. 7. Don't Repeat Yourself (DRY) Principle ▪ By incorporating software design 8. Separation of Concerns (SoC) Principle principles into the development process, 9. Law of Demeter (LoD) Principle software teams can improve the overall 10. Keep it Simple, Stupid (KISS) Principle quality and longevity of the software they create. ▪ The SOLID principles are a set of five design principles (1-5 above) intended to make software designs more understandable, flexible, and maintainable. ▪ These principles are widely accepted in object- oriented software development. 11/39  Software Design Principles Single Responsibility Principle (SRP) ▪ A class should have only one reason to change. ▪ Promotes separation of concerns. ▪ Helps to make software systems easier to understand and maintain. ▪ Reduces the risk of unintended side effects. ▪ Encourages the creation of smaller, more focused classes. 12/39  Software Design Principles Open-Closed Principle (OCP) ▪ Software entities should be open for extension but closed for modification. ▪ Promotes the use of abstraction and encapsulation. ▪ Encourages the creation of reusable, modular code. ▪ Helps to make software systems more flexible and maintainable. ▪ Reduces the risk of introducing bugs or breaking existing functionality. ▪ Instead of modifying a class that does not quite fit our needs, we can declare a new class that inherits the features of the original class and adds new features. ▪ The new class can even override (redefine) some of the inherited features. 13/39  Software Design Principles Liskov Substitution Principle (LSP) ▪ Subtypes must be substitutable for their base types. ▪ Promotes the use of polymorphism and inheritance. ▪ Helps to ensure the correctness and robustness of software systems. ▪ Encourages the creation of well-defined and consistent interfaces. ▪ Reduces the risk of introducing unexpected behavior or bugs. 14/39  Software Design Principles Interface Segregation Principle (ISP) ▪ A client should not be forced to depend on methods it does not use. ▪ Promotes the use of small, focused interfaces. ▪ Helps to make software systems easier to understand and maintain. ▪ Encourages the creation of more reusable and flexible code. ▪ Reduces the risk of introducing dependencies or breaking existing functionality. 15/39  Software Design Principles Dependency Inversion Principle (DIP) ▪ High-level modules should not depend on low-level modules. Both should depend on abstractions. ▪ Promotes the use of loosely-coupled modules. ▪ Helps to make software systems more flexible and maintainable. ▪ Encourages the creation of code that is easier to test and refactor. ▪ Reduces the risk of introducing dependencies or breaking existing functionality. 16/39  Software Design Principles Composition over Inheritance Principle (CoIP) ▪ Favor composition (containing instances of other classes that implement the desired functionality) over inheritance. ▪ Promotes the use of flexible and reusable code. ▪ Helps to make software systems more modular and maintainable. ▪ Encourages the creation of code that is easier to test and refactor. ▪ Reduces the risk of introducing unexpected behavior or bugs. ▪ Choose inheritance when modeling a "is-a" relationship. A senior citizen is a citizen. A standing desk is a desk. ▪ Choose composition when modeling a "has-a" relationship. A human has a skeletal system, cardiovascular system, etc. A car has an engine, a transmission, gas tank, etc. 17/39  Software Design Principles Don't Repeat Yourself (DRY) Principle ▪ Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. ▪ Promotes the use of code reuse and modularity. ▪ Helps to make software systems more maintainable and scalable. ▪ Encourages the creation of code that is easier to test and refactor. ▪ Reduces the risk of introducing inconsistencies or errors. 18/39  Software Design Principles Separation of Concerns (SoC) Principle ▪ Emphasizes dividing a computer program into distinct sections, such that each section addresses a separate concern. ▪ A module or class should have one and only one reason to change. ▪ Note that, SRP is one of the five SOLID principles of object-oriented design, specifically focusing on the class level. SoC is a broader design principle that can be applied at various levels of software development. ▪ Reduces the risk of introducing dependencies or breaking existing functionality. 19/39  Software Design Principles Law of Demeter (LoD) Principle ▪ A module should not know about the inner workings of the objects it manipulates. ▪ Promotes the use of loose coupling and encapsulation. ▪ Helps to make software systems more maintainable and scalable. ▪ Encourages the creation of code that is easier to test and refactor. ▪ Reduces the risk of introducing dependencies or breaking existing functionality. 20/39  Software Design Principles Keep it Simple, Stupid (KISS) Principle ▪ Simplicity is key to software design. ▪ Promotes the use of clear and concise code. ▪ Helps to make software systems easier to understand and maintain. ▪ Encourages the creation of code. 21/39  Software Design Patterns ▪ Software design patterns are proven solutions to recurring design problems that arise during software development. ▪ They are time-tested, reusable solutions that have been validated through many applications in real-world scenarios. ▪ Using design patterns can help ensure that your software is more maintainable, extensible, and scalable. ▪ There are many different types of design patterns, such as creational, structural, and behavioral patterns, each with its own purpose and benefits. ▪ Familiarizing yourself with common design patterns can help you make better design decisions, improve code quality, and accelerate development. 22/39  Software Design Patterns ▪ Software design patterns are proven solutions to recurring design problems that arise during software development. ▪ They are time-tested, reusable solutions that have been validated through many applications in real-world scenarios. ▪ Using design patterns can help ensure that your software is more maintainable, extensible, and scalable. ▪ There are many different types of design patterns, such as creational, structural, and behavioral patterns, each with its own purpose and benefits. ▪ Familiarizing yourself with common design patterns can help you make better design decisions, improve code quality, and accelerate development. ▪ Categories: 1. Creational 2. Structural 3. Behavioral 23/39  Software Design Patterns Creational Patterns ▪ These patterns deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation. ▪ Singleton: Ensures a class has only one instance and provides a global point of access to it. ▪ Factory Method: Defines an interface for creating an object, but lets subclasses alter the type of objects that will be created. ▪ Abstract Factory: Provides an interface for creating families of related or dependent objects without specifying their concrete classes. ▪ Builder: Separates the construction of a complex object from its representation, allowing the same construction process to create various representations. ▪ Prototype: Creates new objects by copying an existing object, known as the prototype. 24/39  Software Design Patterns Structural Patterns ▪ These patterns concern class and object composition. They help ensure that if one part of a system changes, the entire system doesn't need to do the same. They also help in making sure that parts of a system are decoupled and can therefore be easier to understand and reason about. ▪ Adapter (or Wrapper): Allows objects with incompatible interfaces to collaborate. ▪ Bridge: Separates an object’s abstraction from its implementation so that the two can vary independently. ▪ Composite: Composes objects into tree structures to represent part-whole hierarchies. It lets clients treat individual objects and compositions of objects uniformly. ▪ Decorator: Allows for the dynamic addition of behaviors to objects without affecting the behavior of other objects from the same class. ▪ Facade: Provides a simplified interface to a library, a framework, or any other complex set of classes. ▪ Flyweight: Reduces the cost of creating and manipulating a large number of similar objects. ▪ Proxy: Provides a surrogate or placeholder for another object to control access to it. 25/39  Software Design Patterns Behavioral Patterns ▪ These patterns are all about class's objects communication. They help define how objects interact in a manner that increases flexibility in carrying out communication. ▪ Command: Encapsulates a request as an object, thereby allowing for the parameterization of clients with queues, requests, and operations. ▪ Interpreter: Defines a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language. ▪ Iterator: Provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation. ▪ Observer: Defines a dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. ▪ Strategy: Defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it. ▪ Template Method: Defines the skeleton of an algorithm in the superclass but lets subclasses override specific steps of the algorithm without changing its structure. ▪ Visitor: Lets you define a new operation without changing the classes of the elements on which it operates. 26/39 Popular Software Design Patterns 1. Singleton Pattern 2. Factory Pattern 3. Adapter Pattern 4. Decorator Pattern 5. Observer Pattern 6. Template Method Pattern 7. Strategy Pattern 8. Command Pattern 9. Iterator Pattern 10. Facade Pattern 27/39  Popular Software Design Patterns Singleton Pattern ▪ Ensures that only one instance of a class can exist. ▪ Provides global point of access to that instance. ▪ Useful when only one object is needed to coordinate actions across the system. ▪ Can be implemented as a static member in a class or as a registry of instances. ▪ Care must be taken to ensure thread safety in multi-threaded environments. ▪ Example: A logging service that needs to be accessed by multiple components of an application. Using the Singleton pattern ensures that only one instance of the logging service is created and shared across the application. 28/39  Popular Software Design Patterns Factory Pattern ▪ Used to create objects without specifying the exact class of object that will be created. ▪ Defines an interface for creating objects but leaves the choice of class to be instantiated to the client. ▪ Allows for the client to be decoupled from the implementation details of the created objects. ▪ Commonly used in frameworks where the client code does not know the exact types of objects it needs to create. ▪ Example: A software application that reads data from different file formats (e.g., CSV, JSON, XML) can use the Factory Method pattern to create objects of the appropriate reader class based on the file type. 29/39  Popular Software Design Patterns Adapter Pattern ▪ Used to convert the interface of one class into another interface that clients expect. ▪ Allows classes to work together that could not otherwise because of incompatible interfaces. ▪ Can be implemented as either a class adapter or an object adapter. ▪ Commonly used when integrating with third-party libraries or systems. ▪ Can also be used to refactor legacy code by adapting old interfaces to new ones. ▪ Example: A software application that needs to integrate with a legacy system that uses a different interface can use the Adapter pattern to convert the interface of the legacy system to the interface of the application. 30/39  Popular Software Design Patterns Decorator Pattern ▪ Used to add new behavior to an existing object without modifying its structure. ▪ Allows behavior to be added to individual objects at runtime. ▪ Can be used to add functionality to an object hierarchy dynamically. ▪ Composes objects with other objects to create flexible structures. ▪ Can result in a large number of small classes if not used judiciously. ▪ Example: A text editor that supports different font styles and sizes can use the Decorator pattern to add new features dynamically to the text object without affecting the existing ones. 31/39  Popular Software Design Patterns Observer Pattern ▪ Used to maintain a list of dependents and notify them automatically of any state changes. ▪ Allows for loosely coupled communication between objects. ▪ Useful when an object needs to notify other objects about its state but does not need to know the details of the observers. ▪ Commonly used in GUI programming, event-driven systems, and publish-subscribe systems. ▪ Example: A stock market application that notifies investors about changes in stock prices can use the Observer pattern to maintain a list of subscribers (observers) and notify them when the stock prices change. 32/39  Popular Software Design Patterns Template Method Pattern ▪ Used to define the skeleton of an algorithm in a method but defer some steps to subclasses. ▪ Allows subclasses to redefine certain steps of an algorithm without changing the algorithm's structure. ▪ Encapsulates common behavior in a superclass and allows subclasses to customize behavior. ▪ Commonly used in frameworks where parts of the overall algorithm are common across multiple implementations. ▪ Example: A software application that generates different types of reports (e.g., PDF, HTML, CSV) can use the Template Method pattern to define a common skeleton for report generation and allow subclasses to override specific steps for each report type. 33/39  Popular Software Design Patterns Strategy Pattern ▪ Used to define a family of algorithms, encapsulate each one, and make them interchangeable. ▪ Allows for algorithms to be selected at runtime based on client needs. ▪ Encapsulates each algorithm into a separate class to promote code reuse. ▪ Commonly used in systems where the behavior of an object can vary depending on the context or state. ▪ Can be used in combination with the Template Method Pattern to provide additional flexibility. ▪ Example: A video game that allows players to choose different characters with unique abilities can use the Strategy pattern to encapsulate the behavior of each character in a separate class and allow players to switch between them at runtime. 34/39  Popular Software Design Patterns Command Pattern ▪ Used to encapsulate a request as an object, allowing for the request to be queued or logged. ▪ Decouples the object making the request from the object that receives and executes it. ▪ Provides a way to undo or redo commands. ▪ Commonly used in GUI programming, logging, and transaction processing. ▪ Can be used to implement a simple macro system. ▪ Example: A remote control for a TV that allows users to turn it on/off, change channels, and adjust the volume can use the Command pattern to encapsulate each action in a separate command object and allow users to undo/redo them. 35/39  Popular Software Design Patterns Iterator Pattern ▪ Provides a way to access the elements of an aggregate object sequentially. ▪ Hides the complexity of traversing a collection. ▪ Allows multiple iterations on a collection. ▪ Simplifies client code by providing a uniform way to access different collections of objects. ▪ Example: A software application that needs to iterate over a large collection of objects (e.g., a database query) can use the Iterator pattern to provide a standard interface for accessing the collection elements and allow multiple iteration strategies to be implemented. 36/39  Popular Software Design Patterns Facade Pattern ▪ Provides a simple interface to a complex system of classes, interfaces, and objects. ▪ Reduces the coupling between client code and subsystem classes. ▪ Improves the maintainability and readability of code. ▪ Hides the complexity of a system from the client. ▪ Commonly used in software frameworks such as JavaServer Faces (JSF), which provides a simple interface for web application development. ▪ Example: In a multimedia application, the Facade pattern can be used to provide a simple interface for playing audio and video files, which can involve several subsystem classes such as audio codec, video codec, and media player. 37/39  Which Pattern Should I Use? ▪ Deciding which design pattern to use depends on several factors such as the problem you are trying to solve, the constraints of the project, and the context in which the software is being developed. ▪ Some guidelines that can help you choose the right pattern: Understand the problem domain: Identify the problem you are trying to solve and the requirements of the project. Look for patterns that are commonly used for similar problems or domains. Evaluate the trade-offs: Each pattern has its own strengths and weaknesses. Consider the trade-offs between the benefits and the drawbacks of the pattern you are considering. Consider the context: The choice of pattern depends on the context of the project, such as the programming language, the framework, and the architecture. Some patterns may be more suitable for certain contexts than others. Use established patterns: It is often a good practice to use established patterns that have been proven to work well in practice. Look for patterns that are widely used and have good documentation and examples. Refactor as needed: Design patterns are not silver bullets and should not be applied blindly. Be willing to refactor your code if the pattern is not working or if there is a better alternative. ▪ Ultimately, the choice of pattern depends on the judgment and experience of the software designer. 38/39  Workshop Online Bookstore Inventory Management ▪ Scenario: You are developing an inventory management system for an online bookstore. The system needs to handle a variety of book categories (e.g., fiction, non-fiction, educational, children's books) and should be able to add new categories easily as the store expands. Each category of books has a different way of managing stock levels, pricing strategies, and sales tactics. ▪ Requirement: The system should be designed in a way that adding a new book category or changing the stock management strategy for a category does not require a major overhaul of the inventory system. ▪ Question: Which design pattern is most suitable for developing the online bookstore's inventory management system, given the need for ease of extensibility and the ability to manage different book categories with unique ways? 39/39