CS 427 Lectures 6-13 | Spring 2025, Complete Solutions Design Pattern A design pattern is the description of communicating objects and classes that are customized to solve a general design problem in a particular cont
...
CS 427 Lectures 6-13 | Spring 2025, Complete Solutions Design Pattern A design pattern is the description of communicating objects and classes that are customized to solve a general design problem in a particular context, identifying the participating classes and objects, their roles and collaborations, and the distribution of responsibilities. Gang of Four (GoF) Book Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson, Vlissides, 1994. Creational patterns A category of design patterns that includes 5 patterns: Abstract factory, Builder, Factory method, Prototype, Singleton. Structural patterns A category of design patterns that includes 7 patterns: Adapter, Bridge, Composite, Decorator, Façade, Flyweight, Proxy. Behavioral patterns A category of design patterns that includes 11 patterns: Observer, State, Strategy, Template method, Visitor, Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento. Observer Pattern Intent: define a 1-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.. Observer - interface An interface that defines the methods for observers to implement. Observable - class A class that maintains a list of observers and notifies them of state changes. Subject <> that defines methods for attaching, detaching, and notifying observers. ConcreteObserver A specific implementation of the Observer interface that defines how to update when notified. ConcreteSubject A specific implementation of the Observable class that notifies observers of state changes. notify() A method that subjects must call when they change state to inform observers. update() A method that observers must define to update themselves when notified by the subject. Patterns Recurring arrangements of elements that document experience/expertise and serve as a vocabulary for communication. Key elements of a design pattern Name, Problem, Solution, and Consequences. OO Design Patterns Object-oriented programming techniques that involve a small group of classes and objects, leading to reusable design. Learning Objectives By the end of this video, you will be able to list the three categories of design patterns and classify into one of the three pattern categories given a design pattern. Change notification The process by which observers are informed of changes in the state of the subject. Multiple Displays of Same Application Data A scenario where different observers display the same data from the subject. Relative Percentages A method of representing data in terms of proportions, such as A=10%, B=40%, C=30%, D=20%. Application data The data that is requested and modified by the observers. Observable Class Observer Interface Subject Has a list of observers and methods for attaching/detaching an observer observers A collection of Observer instances ConcreteSubject Implements Subject and manages state and observers ConcreteObserver Implements updating interface for objects that get notified of changes in a subject StateInfo Holds the state information relevant to observers Observer Pattern A design pattern that defines a one-to-many dependency between objects attach(Observer) Method to add an observer to the subject detach(Observer) Method to remove an observer from the subject notify() Method to notify all attached observers of a state change update(Subject, StateInfo) Method called by the subject to update observers with new state information Cycles of Dependence A situation where package A cannot function without package B Eliminating Dependence Using the Observer pattern to reduce direct dependencies between classes Loose coupling A design principle that allows for less interdependence between components broadcast communication A method where all observers are notified of changes Composite Pattern A design pattern used to treat individual objects and compositions uniformly Component An abstract class that defines a part of a composite structure children A set of child components in a composite structure Book An example of a composite that can contain chapters and paragraphs Paragraph A component that can exist within a chapter in a book Chapter A component that can contain paragraphs and is part of a book Composite Pattern (Gamma et al., 1994) A design pattern that allows you to compose objects into tree structures to represent part-whole hierarchies. Composite Only Composite can store and enumerate children (aggregation) and add or remove children. Leaf A component that does not have any children. Part-Of Rule A is a part of B if, and only if, B is the composite of A. Ensuring Consistency The public operations on a composite and its components ensure that pointers from components to composite and composite to components are consistent. addChild() in Composite The addChild operation of Composite updates the container of the component. Book Example An example of a composite structure where a Book contains Chapters, Sections, and Paragraphs. Interpreter Pattern A design pattern that defines a representation for a language's grammar along with an interpreter that uses the representation to interpret sentences in the language. Context The environment in which the interpreter operates, providing necessary information for interpretation. AbstractExpression An abstract class defining the interface for interpreting expressions. NonterminalExpression An expression that can have one or more children and represents a rule in the grammar. TerminalExpression An expression that represents a terminal symbol in the grammar. Spreadsheet Rules Rules of the form D3 + D4 or Subtotal(D2:D8) that define operations on spreadsheet data. Grammar A set of rules that defines the structure of valid expressions in the language. PlusExpression An expression that represents the addition of two expressions. CellExpression An expression that retrieves the value of a cell in the spreadsheet. value(Spreadsheet) A method that evaluates the expression in the context of a given spreadsheet. Expression Tree A tree structure representing expressions where each node is an expression. BinaryExpression An expression that has two operands. ConstantExpression An expression that represents a constant value. SubtotalExpression An expression that calculates the subtotal of a range of cells. Steps for Applying the Interpreter Pattern 1. Make a subclass of Expression for each rule in grammar. 2. Define a value(Spreadsheet) method for each subclass of Expression. 3. Define constructors for making expression tree. Visitor Pattern Applied on a structure with many elements with operations varying depending on elements. Interpreter Pattern Distributes an algorithm (a set of methods) over a class hierarchy. Visitor Defines a visit method for each class of node. ConcreteVisitor A specific implementation of the Visitor that can operate on elements. accept method A method in parse tree nodes that calls the visit method on the Visitor. Centralized Algorithm Change entire algorithm at once and look at entire algorithm at once. Distributed Implementation Writing a new interpret method requires adding a method to every class. Class Diagram A visual representation of the classes and their relationships in a design pattern. Refactor To restructure existing computer code without changing its external behavior. Template Method Pattern Defines the skeleton of an algorithm in a method, deferring some steps to subclasses. Learning Objectives By the end of this video, you will be able to explain the intent of the design pattern. Stable set of elements Elements that do not change but have evolving operations. ConcreteElem An instance of an element that can be visited by a Visitor. PlusExpression A class that represents a binary expression for addition. value method A method that computes the value of an expression. Child Value Refers to the value computed by child nodes in a parse tree. Visitor vs. Interpreter Patterns Visitor is easier to add new operations, while Interpreter is easier to add new elements. Gamma et al. (1994) Authors of the book 'Design patterns: Elements of reusable object-oriented software.' Client The entity that uses the Visitor to perform operations on elements. Node Visitor A class that implements the visiting logic for parse tree nodes. Method accept A method that allows a visitor to visit the node. Visitor Class A class that contains methods to visit different types of nodes. R value The return type of the visit method in the Visitor class. A, B parameters Parameters used in the visit method to pass data. Template Method Pattern Defines the skeleton of an algorithm in a superclass, deferring some steps to subclasses. AbstractClass Contains the templateMethod() and abstract methods primOperation1() and primOperation2(). ConcreteClass Implements the abstract methods primOperation1() and primOperation2(). Invariant and Variant Template Method separates the invariant part of an algorithm from the parts that vary with each subclass. Example Template Method in JComponent A method that uses getComponentGraphics and createSwingGraphics to paint components. Guidelines on Making Template Methods Mark different places in methods, extract them into separate methods, and move common bodies to superclass. Iterator Pattern Hides the internal structure of an object while allowing clients to access components through an iterator. Enumeration The original Java iterator. Iterator The modern Java iterator available in the Collection framework in java.util package. Composite A structure that can have an iterator for its components, allowing iteration over all components in a tree. CompositeIterator An iterator that iterates over components in a Composite structure. weight() Method in CompositeEquipment Calculates the total weight of equipment by iterating over children components. Visitor Pattern A design pattern that defines a new operation without changing the classes of the elements on which it operates. Traversal Algorithm Responsibility In the context of Visitor and Composite, the traversal algorithm can be the responsibility of the components, the visitor, or a separate iterator. paint() Method A method that is common across multiple classes but may have different implementations. getComponentGraphics A method that retrieves the graphics context for a component. createSwingGraphics A method that creates a Swing graphics context from a given graphics context. paintComponent A method that handles the painting of the component. paintBorder A method that handles the painting of the component's border. paintChildren A method that handles the painting of the component's children. Command An interface or class that encapsulates a request as an object. Component A class that represents an element in a composite structure. Composite Class A class that can contain multiple components and provides an interface to access them. Visitor Pattern A design pattern that allows adding new operations to existing object structures without modifying those structures. Iterator An object that enables traversing a collection without exposing its underlying representation. Strategy Pattern A design pattern that enables selecting an algorithm's behavior at runtime by encapsulating algorithms in separate classes. ConcreteVisitor A specific implementation of the Visitor pattern that defines operations to be performed on elements of an object structure. Context The class that maintains a reference to a Strategy object and delegates the execution of the algorithm to the Strategy. AbstractStrategy An interface or abstract class that defines a common interface for all concrete strategies. Trade-Offs of Strategy Pattern Pros include easier management of behaviors and reduced conditional statements; cons include increased object count and awareness of strategies. Template Method Pattern A design pattern that defines the skeleton of an algorithm in a method, deferring some steps to subclasses. Validation The process of evaluating a system or its components to determine whether they meet the specified requirements. Verification The process of checking whether a product, service, or system meets the requirements and specifications. doItInContext A method in the Context class that executes the strategy's algorithm with the provided inputs. SortStrategy An interface for different sorting algorithms that can be used interchangeably. BubbleSort A simple sorting algorithm that repeatedly steps through the list, compares adjacent elements and swaps them if they are in the wrong order. QuickSort A highly efficient sorting algorithm that uses divide-and-conquer principles to sort elements. doIt1 A method that implements one variant of the algorithm in the Strategy pattern. doIt2 A method that implements another variant of the algorithm in the Strategy pattern. children() A method that returns an iterator over the children of a component in the Visitor pattern. accept(visitor) A method that allows a visitor to perform operations on a component. visitA(ComponentA c) A method in the Visitor pattern that defines how to interact with a specific type of component. ConcreteClass A specific implementation of an abstract class that provides concrete behavior for the template method. primOperation1() A primitive operation that must be implemented by subclasses in the Template Method pattern. primOperation2() Another primitive operation that must be implemented by subclasses in the Template Method pattern. Gamma et al. (1994) The authors of 'Design Patterns: Elements of Reusable Object-Oriented Software', a foundational text in software design patterns. Validation process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements Verification process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase Testing Purpose Improve quality - find faults Testing Purpose Measure quality Testing Purpose Prove there are no faults? (Is it possible?) Testing Purpose Determine whether software is ready to be released Testing Purpose Determine what to work on Testing Purpose Learn the software Testing Definition Testing shows the presence, not the absence of bugs. Test Case Run software under test with known inputs (test inputs/data), check results (w/ test oracles) Manual Test Example Test ID, Description, Expected Results, Actual Results Automated Test Example Doubling the balance and then plus 10 Test Automation Tests are code/scripts created by a tool that records user actions or written manually in a test scripting language When to Use Automated Tests When you run them over and over When to Use Manual Tests When you are only going to run the test once Who Writes Tests? Developer, Separate quality assurance group, User, Someone with a degree in testing, Someone with domain knowledge of the software When to Write Tests Requirements, Analysis, Design, Checking, Implementation, Unit Testing, Integration, System Testing, Maintenance, Regression Testing When to Run Tests After you change the software under test, Before you deliver the software, To customer, To next phase of project 1972 ACM Turing Awardee Edsger W. Dijkstra Test Inputs Data used to run the software under test Test Oracles Reference for determining if test results are correct Expected Results The anticipated outcome of a test case Actual Results The outcome observed when a test case is executed Programmer tests Tests conducted by programmers. Non-programmer tests Tests conducted by individuals who are not programmers. Developer A person who creates software. Tester A person who evaluates software for defects. Unit tests Tests that validate individual components of the software. Integration tests Tests that validate the interaction between integrated components. System tests Tests that validate the complete and integrated software system. Automated tests Tests that are executed using automated tools. Manual tests Tests that are executed by human testers without automation. Regression tests Tests that ensure previously developed and tested software still performs after a change. Exploratory tests Tests that are conducted without a formal test plan, exploring the software's functionality. Fault-based tests Tests that are designed to identify common faults. Scenario-based tests Tests that are based on user stories. Random tests Tests that use random input to check for crashes and validate output against expected results. Performance tests Tests that measure the time taken for each test. Load tests Tests that evaluate the system's performance under heavy load. Usability tests Tests that assess how well users can interact with the software. Security tests Tests that evaluate the software's security features. Test Design The process of designing test inputs to satisfy a test objective. Test Automation The process of embedding test inputs into executable scripts. Test Execution The process of running test inputs on the software and recording actual results. Test Evaluation The process of evaluating actual results and documenting expected results. Test ID A unique identifier for a specific test. Description A brief explanation of what the test does. Expected Results The anticipated outcome of the test. Actual Results The actual outcome observed when the test is executed. Assigning Right Persons The process of allocating appropriate individuals to different testing activities. Mistake An action taken by a developer that leads to a fault in the software. Fault A defect or bug introduced in the software that remains undetected during testing. Error The difference between a computed, observed, or measured value/condition and the true, specified, or theoretically correct value/condition. Failure The event when the program behaves unexpectedly based on test oracles during execution. PIE Model A model illustrating three conditions necessary/sufficient for a fault to cause a failure: Execution, Infection, and Propagation. Execution (PIE Model) The condition where the fault-containing location(s) in the software is executed. Infection (PIE Model) The condition where the state of the software is infected, causing an error. Propagation (PIE Model) The condition where the infected state is propagated to cause some state/output of the software to be observed. Testing The process of finding inputs (and test oracles) that cause the software to fail. Debugging The process of finding a fault given a failure. Equivalence Partitioning A testing technique that divides input data into partitions to reduce the number of test cases. Boundary Value Analysis A testing technique that focuses on the values at the boundaries of input ranges. Test Oracle A mechanism for determining whether a test has passed or failed. Statement Coverage A measure of how many of the executable statements in the code have been executed during testing. AssertTrue A method used in testing to assert that a condition is true. Account Class A class used in examples to demonstrate testing and debugging concepts. doWithdraw Method A method that checks if a withdrawal can be made based on the account balance. calAmount Method A method that calculates an amount based on the account balance. Test Manager The person responsible for overseeing the testing process and ensuring coverage. Tester The individual who conducts tests to find faults in the software. Bug Report A report documenting a bug found in the software. 100% Statement Coverage A goal in testing where every statement in the code is executed at least once. Voas, J. M. (1992) The author of the paper discussing the PIE model in software testing. IEEE Trans. Softw. Eng. A publication where the PIE model was discussed. White-Box Testing Testing techniques that involve looking at the internal structure of the code. Black-Box Testing Testing techniques based on specifications without knowledge of the internal workings. Equivalence Partitioning Dividing input domain into classes of equivalent values where inputs in the same class should behave similarly. Boundary Value Analysis Testing values at the boundaries of equivalence classes because faults tend to occur at the boundaries. Code Coverage A measure of how much of the source code is tested by a set of test cases. Specifications Documents that outline what the software is supposed to do, ensuring clarity and consistency. JavaDoc A documentation tool for Java classes and methods that starts as comments in code and generates web pages. Equivalence Class A group of input values that are treated the same by the program. Robustness Testing Testing beyond the boundaries of input values to ensure the system can handle unexpected inputs. Test Input Values Specific values used in testing to verify the behavior of the program. Test Case A set of conditions or variables under which a tester will determine whether a system is working correctly. Null Pointer A pointer that does not point to any object or value. Empty String A string that contains no characters. Empty Collection A collection that contains no elements. Circular Structure A data structure that loops back on itself, such as a circular linked list. Depth Greater Than One A characteristic of data structures like trees that have more than one level. Equal but Not Identical Objects that have the same value but are different instances in memory. Black Box Test Case A test case that evaluates the functionality of an application without peering into its internal structures. Test ID A unique identifier for a specific test case. Expected Results The anticipated outcome of a test case based on the requirements.
[Show More]
.png)
