Object-Oriented Modelling Basics

Introduction to Object-Oriented Modelling

• The paradox of simple rules and complex outcomes: simple computational rules can lead to complex software behavior, similar to a game of chess.
• Software development involves managing complexity and changing requirements, which requires design principles and techniques.

Software Engineering

• Goal: to produce reliable, efficient, maintainable, and usable software.
• Software engineering involves:
  • Understanding user needs and translating them into software solutions (Requirements Engineering).
  • Designing systems that are robust, scalable, and secure (Quality Attributes).
  • Managing the software development process efficiently.

Software Development Lifecycle

• The waterfall model is a sequential software development process with 6 phases:
  1. Requirements
  2. Design
  3. Implementation
  4. Verification
  5. Deployment
  6. Maintenance

Requirements Phase

• Provides a clear, detailed foundation for the project.
• Involves:
  • Identifying stakeholders.
  • Gathering requirements.
  • Analyzing requirements.
  • Creating a requirements specification.
  • Validating requirements.

Design Phase

• Outlines how the app will look and function.
• Involves:
  • Creating detailed designs for the app's interface and system architecture.
  • Developing a design document.

Implementation Phase

• Turns design documents into a working application.
• Involves:
  • Writing and compiling code based on the design documents.

Verification Phase

• Confirms that the app is built correctly and is ready for deployment.
• Involves:
  • Testing to ensure the app meets all requirements and design specifications.

Deployment Phase

• The phase where the software becomes available to end-users.
• Involves:
  • Releasing the app on various platforms.
  • Monitoring initial performance.

Maintenance Phase

• Ensures the app remains functional and up-to-date over time.
• Involves:
  • Providing ongoing support.
  • Fixing bugs.
  • Implementing updates.

Introduction to Object-Oriented Analysis and Design (OOA/OOD)

• OOA: identifies the objects and interactions between them.
• OOD: creates a conceptual solution that meets the requirements.
• Unified Modeling Language (UML) is a graphical language used for specifying, visualizing, constructing, and documenting software systems.

Design Patterns

• Reusable solutions to common software design problems.
• Characteristics of design patterns:
  • Defines a language for discussing and documenting design.
  • Not specific to a particular problem.
  • Encourages best practices like modularity and separation of concerns.

Code Smells

• Patterns in software that indicate potential flaws.
• Examples of code smells:
  • Long Method.
  • Large Class.
  • Duplicate Code.

Code Refactoring

• The process of restructuring existing computer code without changing its external behavior.
• Goals of refactoring:
  • Enhance code readability and maintainability.
  • Reduce complexity and improve code performance.
• Principles of code refactoring:
  • Keep changes small and incremental.
  • Ensure each refactoring step preserves the software's functionality.
  • Test continuously to ensure no new bugs are introduced.

Object-Oriented Analysis and Design

• OOA: analyzes the system, models it, and designs the software.
• OOD: takes the analysis results and molds them into a design that can be implemented in a specific programming language.
• Benefits of OOA&D:
  • Modularity.
  • Reusability.
  • Flexibility.

Gathering Requirements

• Requirements: descriptions of the system's features and constraints.
• Types of software requirements:
  • Functional.
  • Non-functional.
  • Domain.

Use Cases

• Detailed descriptions of how users perform tasks, outlining a system's behavior from a user's perspective.
• Elements of a use case:
  • Actor.
  • Stakeholder.
  • Preconditions.
  • Triggers.
  • Main Success Scenarios (Basic Flow).
  • Alternative Paths (Alternative Flows).

Requirements Prioritization

• MoSCoW technique: prioritization tool used to reach a common understanding on the importance of various requirements.
• Components of MoSCoW technique:
  • Must have (M).
  • Should have (S).
  • Could have (C).
  • Won't have this time (W).

Object-Oriented Analysis

• OOA: a methodical approach to understanding a system by viewing it through the lens of the 'objects' it involves.
• Key aspects:
  • Understanding the Domain.
  • Capturing Requirements.
  • Defining the System.

Object Interaction Analysis

• A technique used to understand how objects in the system will communicate and collaborate.
• Interaction diagrams are used to visualize these interactions.
• Assigning responsibilities with CRC Cards.

Designing Good Software

• Good software design is about crafting solutions that are effective, efficient, and maintainable.
• Core principles:
  • Simplicity.
  • Consistency.
  • Modularity.
  • Usability.
  • Maintainability.
  • Robustness (SCMUMR).### Fundamentals of Software Development
• Robustness: The ability of a system to handle errors and unexpected situations gracefully.
• Principles of Software Development:
  • DRY (Don't Repeat Yourself): Avoid duplication in code.
  • KISS (Keep it Simple, Stupid): Keep design simple and straightforward.
  • YAGNI (You Aren't Gonna Need It): Don't implement something until it's necessary.

Object-Oriented Design Principles

• Separation of Concerns: Divide a program into distinct sections, each handling a specific aspect of the application's functionality.
• Principle of Least Astonishment: Software should behave as users expect it to.
• Law of Demeter: Object should assume as little as possible about the structure or properties of anything else.

GRASP Principles

• Information Expert: Assign responsibilities to the class with the most related information.
• Creator: Assign class B to create an instance of class A if B closely uses A or holds the data to initialize A.
• Controller: Assign the responsibility of handling a system event to a class representing the overall system.
• Low Coupling: Design to minimize dependencies between classes.
• High Cohesion: Keep related functions together in a class.
• Polymorphism: Handle alternatives based on object types dynamically.
• Pure Fabrication: Create classes for better design, even if they don't represent real-world entities.

SOLID Principles

• Single Responsibility Principle (SRP): A class should have one reason to change.
• Open/Closed Principle (OCP): Software entities should be open for extension but closed for modification.
• Liskov Substitution Principle (LSP): Subclasses should be substitutable for their base classes.
• Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they don't use.
• Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules; both should depend on abstractions.

Refactoring and Code Smells

• Refactoring: The process of improving internal structure of code without changing the external behavior.
• Code Smells: Indicators of potential issues in the code that may require refactoring.
• Types of Code Smells:
  • Bloaters: Oversized constructs that complicate code management.
  • Object-Orientation Abusers: Poor OOP design choices.
  • Change Preventers: Structures that make changes difficult and widespread.
  • Dispensables: Redundant elements that reduce clarity and efficiency.
  • Couplers: Excessive class coupling or delegation issues.

Design Patterns

• Overview: Proven solutions to common problems, improving problem-solving skills.

• Classification:

  • By complexity and detail: Idioms, architectural patterns.
  • By purpose: Creational, structural, behavioral patterns.

• Creational Design Patterns:

  • Factory Method Pattern: Provides an interface for creating objects in a superclass.
  • Abstract Factory Pattern: Lets you produce families of related objects without specifying their concrete classes.
  • Simple Factory Pattern: A creation method within a class is responsible for creating instances.### Creation Patterns

• Static Creation Method: allows calling a method on the class itself to create an instance, providing clarity and control over the instantiation process.

• Simple Factory: encapsulates object creation for a specific type, often based on given parameters, centralizing and simplifying object creation.

Singleton Pattern

• Purpose: ensures a class has only one instance and provides a global point of access to that instance.
• Use cases: coordinating actions across a system, controlling access to shared resources, and preventing inconsistencies in the application state.
• Implementation: making the constructor private and providing a static method that returns the same instance.
• Steps:
  • Private instance: add a private static field to store the singleton instance.
  • Public creation method: implement a public static method for retrieving the singleton instance.
  • Lazy initialization: initialize the singleton lazily to ensure it's created only when needed.
• Pros: global access point, lazy initialization.
• Cons: SRP violation, can mask bad design, requires special handling in multithread scenarios.

Structural Design Patterns

• Decorator Pattern: dynamically adds behaviors to objects without modifying their structure.
• Key Concept: wraps additional behaviors around objects to enhance or modify their functionality.
• Intent: attach new behaviors to objects dynamically, providing a flexible alternative to subclassing for extending functionality.
• Issues with Subclassing: explosion of subclasses, inflexibility to combine multiple behaviors dynamically.
• How it works: wraps the original object inside objects containing new behaviors; each wrapper (decorator) adds its behavior either before or after delegating to the wrapped object.
• Pattern Structure:
  • Component: common interface for both wrappers and wrapped objects.
  • Concrete component: the object being wrapped.
  • Decorator: base class for all decorators with a reference to a component.
  • Concrete decorators: classes that add new behaviors.
• Implementing Decorator:
  • Define the component interface.
  • Create a concrete component class.
  • Develop a base decorator class.
  • Implement concrete decorators.
• Key Considerations:
  • Ensure all components and decorators implement the component interface.
  • Decorators should delegate to the wrapped object and add their behavior.
• Benefits: flexibility in adding new functionality, avoids class explosion by using composition over inheritance, easier to maintain and extend.
• Limitations: can lead to complex code structures, difficulty in debugging, potential performance issues due to increased object creation.

Adapter Design Pattern

• Purpose: makes two incompatible interfaces compatible, also known as wrapper, connecting new code to legacy code or third-party libraries.
• Intent: allows objects with incompatible interfaces to work together, acts as a bridge between two incompatible interfaces, effectively allowing them to communicate.
• Example: stock market monitoring app downloads data in XML, needs integration with a third-party analytics library requiring JSON, but incompatibility between data formats (XML vs JSON).
• Solution: adapter pattern enables collaboration by converting XML interface for Analytics Library compatibility.
• Pros: separates the interface conversion code from the primary business logic, allows introducing new types of adapters without breaking existing client code.
• Cons: increases overall complexity due to the introduction of new interfaces and classes.

Facade Pattern

• Purpose: simplifies complex system interactions, providing a unified interface to a set of interfaces in a subsystem.
• Advantages: simplicity, decoupling, maintainability.
• Relations with other patterns: adapter vs facade, facade and singleton.

Proxy Pattern

• Purpose: provides a surrogate or placeholder for another object, controls access to the original object.
• Intent: acts as a substitute to control access to another object, use cases: security, remote object access.
• Types of Proxy Patterns:
  • Remote proxy: access to objects located in different address spaces.
  • Virtual proxy: delays the creation and initialization of expensive objects until needed.
  • Protection proxy: controls access to an object based on access rights.
• Applicability: it is highly versatile, apply in situations requiring access control, lazy initialization, remote object access, or other use cases like logging, caching, or auditing access.
• Pros: control the service object indirectly, manage the lifecycle and initialization of the service, introduce new proxies without changing the service or clients.
• Cons: can complicate the code structure with additional classes, may introduce latency in the response from the service.

Behavioral Design Patterns

• Strategy Pattern: defines a family of algorithms, encapsulates each algorithm, and makes them interchangeable.
• Intent: define a set of interchangeable algorithms or strategies that can be selected at runtime according to the needs of the context or client.
• Problem: need for a flexible way to incorporate different behaviors or algorithms within a class and the ability to change them at runtime.
• Solution: separating the behavior into different strategy classes and using a reference to these strategies in the context class.
• Advantages: promotes flexible code structure, allows behaviors to change dynamically, reduces dependency on inheritance.
• Structure:
  • Context: maintains a reference to a Strategy object and delegates it the algorithm execution.
  • Strategy: common interface for all strategies defining the algorithm execution method.
  • ConcreteStrategy: implements the algorithm using the Strategy Interface.
• Use Strategy when: different variations of an algorithm and want to switch between them at runtime, avoid exposing complex, alg-specific data structures, replace inheritance with composition for behavioral variations.
• Pros and Cons:
  • Pros: Open/Closed Principle by allowing the introduction of new strategies without changing the context, simplifies unit testing by isolating algorithms.
  • Cons: increases the number of objects in the application, clients must be aware of the differences.

Observer Pattern

• Definition: a design pattern where an object, known as the subject, notifies a list of observers about its state changes.
• Intent: establishment of a subscription mechanism to notify multiple objects about any events that happen to the object they're observing.
• Problem: managing knowledge about changes in a system's state can be complex when multiple entities need updates.
• Solution: this pattern offers a subscription model where subjects notify observers about changes, promoting decoupling and efficient data distribution.
• Example: weather station, observable: weather station measuring and updating weather data, observers: displays showing updated weather.
• Advantages: reduces coupling, real-time update.
• Push vs Pull notification:
  • Push model: subject sends detailed data to observers.
  • Pull model: observers request data from the subject.
• Registering Observers: observers must register themselves to the subject, allows dynamic addition and removal of observers.
• Benefits: scalability, flexibility, supports both push and pull data models.
• Limitations: potential for memory leaks, unexpected updates.