Object-Oriented Modelling Basics
24 Questions
0 Views

Choose a study mode

Play Quiz
Study Flashcards
Spaced Repetition
Chat to lesson

Podcast

Play an AI-generated podcast conversation about this lesson

Questions and Answers

What is the goal of Software Engineering?

  • To make the software aesthetically pleasing
  • To develop software without any flaws
  • To produce reliable, efficient, maintainable, and usable software (correct)
  • To design software for specific hardware only

    • Object-Oriented Analysis (OOA) is the phase where a software system is designed.

    False

    What does OOD stand for?

    Object-Oriented Design

    ______ are reusable solutions to common software design problems.

    <p>Design Patterns</p> Signup and view all the answers

    Match the following software quality attributes with their definitions:

    <p>Functionality = The degree to which a product provides functions that meet user needs under specified conditions Reliability = The software's ability to maintain performance under stated conditions for a specified period Usability = How well a product can be used to achieve specified goals effectively and efficiently Maintainability = The ease with which the software can be modified to correct faults or improve performance</p> Signup and view all the answers

    What is the purpose of a Controller in software design?

    <p>Centralizes control logic, decouples UI from business logic, simplifies maintenance and enhances scalability.</p> Signup and view all the answers

    Define Low Coupling in software design.

    <p>Low coupling means minimizing dependencies between classes, reducing the impact of changes and improving reusability.</p> Signup and view all the answers

    Explain the concept of High Cohesion.

    <p>High cohesion refers to elements of a module or class belonging together, performing tasks related to a specific purpose.</p> Signup and view all the answers

    Which principle in object-oriented programming promotes having classes with a single reason to change?

    <p>Single Responsibility Principle</p> Signup and view all the answers

    Encapsulation is achieved by using polymorphism to handle object type alternatives.

    <p>False</p> Signup and view all the answers

    What is the main purpose of a Protection Proxy?

    <p>Control access to an object based on access rights.</p> Signup and view all the answers

    Which scenarios does the Proxy Pattern apply to? (Select all that apply)

    <p>Remote object access (Remote Proxy)</p> Signup and view all the answers

    Composition is preferred over Inheritance in the Strategy Pattern.

    <p>True</p> Signup and view all the answers

    The __________ Pattern focuses on effective communication and the assignment of responsibilities among objects.

    <p>Observer</p> Signup and view all the answers

    What is the primary focus of the Factory Method Pattern?

    <p>Object creation mechanisms</p> Signup and view all the answers

    What is a key intent of the Factory Method Pattern?

    <p>Provide an interface for object creation in a superclass</p> Signup and view all the answers

    Simple Factory is considered a true design pattern.

    <p>False</p> Signup and view all the answers

    Abstract Factory Pattern allows you to produce families of related objects without specifying their concrete __________.

    <p>classes</p> Signup and view all the answers

    Match the following patterns with their descriptions:

    <p>Decorator Pattern = Dynamically extends the functionality of objects by wrapping additional behaviors around them Adapter Pattern = Makes two incompatible interfaces compatible by acting as a bridge between them Facade Pattern = Provides a unified interface to a set of interfaces in a subsystem to simplify interactions Proxy Pattern = Acts as a surrogate for another object and controls access to it</p> Signup and view all the answers

    What are the key elements of a use case?

    <p>Actor, Stakeholder, Preconditions, Triggers, Main Success Scenarios, Alternative Paths</p> Signup and view all the answers

    What are the components of the MoSCoW prioritization technique?

    <p>Must have (M)</p> Signup and view all the answers

    The DRY principle stands for 'Do Repeat Yourself'.

    <p>False</p> Signup and view all the answers

    ____ assigns responsibility to the class that has the necessary information to fulfill it.

    <p>Information Expert</p> Signup and view all the answers

    Match the characteristic with the software design principle: Simplicity, Consistency, Modularity, Usability, Maintainability, Robustness

    <p>Simplicity = Focus on essential elements Consistency = Uniformity in visual elements and behavior Modularity = Designing interchangeable components Usability = Intuitive and accessible based on user needs Maintainability = Allows for easy understanding, correction, and adaptation Robustness = Ability to handle errors gracefully</p> Signup and view all the answers

    Study Notes

    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.

    Studying That Suits You

    Use AI to generate personalized quizzes and flashcards to suit your learning preferences.

    Quiz Team

    Related Documents

    Object-Oriented Modelling - PDF

    Description

    Learn about the fundamentals of object-oriented modelling, including the paradox of simple rules leading to complex outcomes and the challenges of evolving software requirements.

    More Like This

    Use Quizgecko on...
    Browser
    Open
    Browser
    Browser