This site is from a past semester! The current version will be here when the new semester starts.
CS2103/T 2020 Aug-Dec
  • Full Timeline
  • Week 1 [Mon, Aug 10th]
  • Week 2 [Fri, Aug 14th]
  • Week 3 [Fri, Aug 21st]
  • Week 4 [Fri, Aug 28th]
  • Week 5 [Fri, Sep 4th]
  • Week 6 [Fri, Sep 11th]
  • Week 7 [Fri, Sep 18th]
  • Week 8 [Fri, Oct 2nd]
  • Week 9 [Fri, Oct 9th]
  • Week 10 [Fri, Oct 16th]
  • Week 11 [Fri, Oct 23rd]
  • Week 12 [Fri, Oct 30th]
  • Week 13 [Fri, Nov 6th]
  • Textbook
  • Admin Info
  • Dashboards
  •  Individual Project (iP):
  • Individual Project Info
  • iP Upstream Repo
  • iP Showcase
  • iP Code Dashboard
  • iP Progress Dashboard

  •  Team Project (tP):
  • Team Project Info
  • Addressbook-level3
  • Team List
  • tP Code Dashboard
  • tP Progress Dashboard
  • Report Bugs
  • Forum
  • Gitter (Chat)
  • Instructors
  • Announcements
  • Files
  • Tutorial Schedule
  • Java Coding Standard
  • Git Conventions
  • Forum Activities Dashboard
  • Participation Dashboard
  • Week 10 [Fri, Oct 16th] - Topics

    • [W10.1] Design Patterns

       Introduction

    • [W10.1a] Design → Design Patterns → Introduction → What

    • [W10.1b] Design → Design Patterns → Introduction → Format

       Singleton pattern

    • [W10.1c] Design → Design Patterns → Singleton → What

    • [W10.1d] Design → Design Patterns → Singleton → Implementation

    • [W10.1e] Design → Design Patterns → Singleton → Evaluation

       Facade pattern

    • [W10.1f] Design → Design Patterns → Facade Pattern → What

       Command pattern

    • [W10.1g] Design → Design Patterns → Command Pattern → What

       Abstraction Occurrence pattern

    • [W10.1h] Design → Design Patterns → Abstraction Occurrence Pattern → What : OPTIONAL

    • [W10.2] Defensive Programming
    • [W10.2a] Implementation → Error Handling → Defensive Programming → What

    • [W10.2b] Implementation → Error Handling → Defensive Programming → Enforcing compulsory associations

    • [W10.2c] Implementation → Error Handling → Defensive Programming → Enforcing 1-to-1 associations : OPTIONAL

    • [W10.2d] Implementation → Error Handling → Defensive Programming → Enforcing referential integrity : OPTIONAL

    • [W10.2e] Implementation → Error Handling → Defensive Programming → When

    • [W10.2f] Implementation → Error Handling → Design by Contract → Design by contract : OPTIONAL

    • [W10.3] Test Cases: Intro
    • [W10.3a] Quality Assurance → Test Case Design → Introduction → What

    • [W10.3b] Quality Assurance → Test Case Design → Introduction → Positive versus negative test cases

    • [W10.3c] Quality Assurance → Test Case Design → Introduction → Black box versus glass box

    • [W10.3d] Quality Assurance → Test Case Design → Testing based on use cases

    • [W10.4] Test Cases: Equivalence Partitioning
    • [W10.4a] Quality Assurance → Test Case Design → Equivalence Partitions → What

    • [W10.4b] Quality Assurance → Test Case Design → Equivalence Partitions → Basic

    • [W10.4c] Quality Assurance → Test Case Design → Equivalence Partitions → Intermediate

    • [W10.5] Test Cases: Boundary Value Analysis
    • [W10.5a] Quality Assurance → Test Case Design → Boundary Value Analysis → What

    • [W10.5b] Quality Assurance → Test Case Design → Boundary Value Analysis → How


    Guidance for the item(s) below:

    Previously, you learned:

    • Three basic design quality aspects: abstraction, coupling, cohesion
    • Some design principles that aims to improve those aspects (e.g., Single Responsibility Principle).

    This week, we cover design patterns, a concept that builds upon the above.

    [W10.1] Design Patterns


    Introduction

    Video

    W10.1a

    Design → Design Patterns → Introduction → What

    Can explain design patterns

    Design pattern: An elegant reusable solution to a commonly recurring problem within a given context in software design.

    In software development, there are certain problems that recur in a certain context.

    Some examples of recurring design problems:

    Design Context Recurring Problem
    Assembling a system that makes use of other existing systems implemented using different technologies What is the best architecture?
    UI needs to be updated when the data in the application backend changes How to initiate an update to the UI when data changes without coupling the backend to the UI?

    After repeated attempts at solving such problems, better solutions are discovered and refined over time. These solutions are known as design patterns, a term popularized by the seminal book Design Patterns: Elements of Reusable Object-Oriented Software by the so-called "Gang of Four" (GoF) written by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides.

    Which one of these describes the ‘software design patterns’ concept best?

    (b)

    W10.1b

    Design → Design Patterns → Introduction → Format

    Can explain design patterns format

    The common format to describe a pattern consists of the following components:

    • Context: The situation or scenario where the design problem is encountered.
    • Problem: The main difficulty to be resolved.
    • Solution: The core of the solution. It is important to note that the solution presented only includes the most general details, which may need further refinement for a specific context.
    • Anti-patterns (optional): Commonly used solutions, which are usually incorrect and/or inferior to the Design Pattern.
    • Consequences (optional): Identifying the pros and cons of applying the pattern.
    • Other useful information (optional): Code examples, known uses, other related patterns, etc.

    When we describe a pattern, we must also specify anti-patterns.

    False.

    Explanation: Anti-patterns are related to patterns, but they are not a ‘must have’ component of a pattern description.


    Guidance for the item(s) below:

    Now that you know what design pattern is, let's learn a few example design patterns.

    Singleton pattern

    Video

    W10.1c

    Design → Design Patterns → Singleton → What

    Can explain the Singleton design pattern

    Context

    Certain classes should have no more than just one instance (e.g. the main controller class of the system). These single instances are commonly known as singletons.

    Problem

    A normal class can be instantiated multiple times by invoking the constructor.

    Solution

    Make the constructor of the singleton class private, because a public constructor will allow others to instantiate the class at will. Provide a public class-level method to access the single instance.

    Example:

    You use the Singleton pattern when

    (c)

    W10.1d

    Design → Design Patterns → Singleton → Implementation

    Can apply the Singleton design pattern

    Here is the typical implementation of how the Singleton pattern is applied to a class:

    class Logic {
    private static Logic theOne = null;

    private Logic() {
    ...
    }

    public static Logic getInstance() {
    if (theOne == null) {
    theOne = new Logic();
    }
    return theOne;
    }
    }

    Notes:

    • The constructor is private, which prevents instantiation from outside the class.
    • The single instance of the singleton class is maintained by a private class-level variable.
    • Access to this object is provided by a public class-level operation getInstance() which instantiates a single copy of the singleton class when it is executed for the first time. Subsequent calls to this operation return the single instance of the class.

    If Logic was not a Singleton class, an object is created like this:

    Logic m = new Logic();

    But now, the Logic object needs to be accessed like this:

    Logic m = Logic.getInstance();

    W10.1e

    Design → Design Patterns → Singleton → Evaluation

    Can decide when to apply Singleton design pattern

    Pros:

    • easy to apply
    • effective in achieving its goal with minimal extra work
    • provides an easy way to access the singleton object from anywhere in the code base

    Cons:

    • The singleton object acts like a global variable that increases coupling across the code base.
    • In testing, it is difficult to replace Singleton objects with stubs (static methods cannot be overridden).
    • In testing, singleton objects carry data from one test to another even when you want each test to be independent of the others.

    Given that there are some significant cons, it is recommended that you apply the Singleton pattern when, in addition to requiring only one instance of a class, there is a risk of creating multiple objects by mistake, and creating such multiple objects has real negative consequences.


    Facade pattern

    Video

    W10.1f

    Design → Design Patterns → Facade Pattern → What

    Can explain the Facade design pattern

    Context

    Components need to access functionality deep inside other components.

    The UI component of a Library system might want to access functionality of the Book class contained inside the Logic component.

    Problem

    Access to the component should be allowed without exposing its internal details. e.g. the UI component should access the functionality of the Logic component without knowing that it contains a Book class within it.

    Solution

    Include a a French word that means 'front of a building'Façade class that sits between the component internals and users of the component such that all access to the component happens through the Facade class.

    The following class diagram applies the Facade pattern to the Library System example. The LibraryLogic class is the Facade class.

    Is the design below likely to use the Facade pattern?

    True.

    Facade is clearly visible (Storage is the <<Facade>> class).


    Command pattern

    W10.1g

    Design → Design Patterns → Command Pattern → What

    Can explain the Command design pattern

    Context

    A system is required to execute a number of commands, each doing a different task. For example, a system might have to support Sort, List, Reset commands.

    Problem

    It is preferable that some part of the code executes these commands without having to know each command type. e.g., there can be a CommandQueue object that is responsible for queuing commands and executing them without knowledge of what each command does.

    Solution

    The essential element of this pattern is to have a general <<Command>> object that can be passed around, stored, executed, etc without knowing the type of command (i.e. via polymorphism).

    Let us examine an example application of the pattern first:

    In the example solution below, the CommandCreator creates List, Sort, and Reset Command objects and adds them to the CommandQueue object. The CommandQueue object treats them all as Command objects and performs the execute/undo operation on each of them without knowledge of the specific Command type. When executed, each Command object will access the DataStore object to carry out its task. The Command class can also be an abstract class or an interface.

    The general form of the solution is as follows.

    The <<Client>> creates a <<ConcreteCommand>> object, and passes it to the <<Invoker>>. The <<Invoker>> object treats all commands as a general <<Command>> type. <<Invoker>> issues a request by calling execute() on the command. If a command is undoable, <<ConcreteCommand>> will store the state for undoing the command prior to invoking execute(). In addition, the <<ConcreteCommand>> object may have to be linked to any <<Receiver>> of the command (the object the command will operate on, in case different commands operate on different objects?) before it is passed to the <<Invoker>>. Note that an application of the command pattern does not have to follow the structure given above.


    Abstraction Occurrence pattern

    W10.1h : OPTIONAL

    Design → Design Patterns → Abstraction Occurrence Pattern → What

    Can explain the Abstraction Occurrence design pattern

    Context

    There is a group of similar entities that appear to be ‘occurrences’ (or ‘copies’) of the same thing, sharing lots of common information, but also differing in significant ways.

    In a library, there can be multiple copies of the same book title. Each copy shares common information such as book title, author, ISBN, etc. However, there are also significant differences like purchase date and barcode number (assumed to be unique for each copy of the book).

    Other examples:

    • Episodes of the same TV series
    • Stock items of the same product model (e.g. TV sets of the same model)

    Problem

    Representing the objects mentioned previously as a single class would be problematic because it results in duplication of data which can lead to inconsistencies in data (if some of the duplicates are not updated consistently).

    Take for example the problem of representing books in a library. Assume that there could be multiple copies of the same title, bearing the same ISBN number, but different serial numbers.

    The above solution requires common information to be duplicated by all instances. This will not only waste storage space, but also creates a consistency problem. Suppose that after creating several copies of the same title, the librarian realized that the author name was wrongly spelt. To correct this mistake, the system needs to go through every copy of the same title to make the correction. Also, if a new copy of the title is added later on, the librarian (or the system) has to make sure that all information entered is the same as the existing copies to avoid inconsistency.

    Anti-pattern

    Refer to the same Library example given above.

    The design above segregates the common and unique information into a class hierarchy. Each book title is represented by a separate class with common data (i.e. Name, Author, ISBN) hard-coded in the class itself. This solution is problematic because each book title is represented as a class, resulting in thousands of classes (one for each title). Every time the library buys new books, the source code of the system will have to be updated with new classes.

    Solution

    Let a copy of an entity (e.g. a copy of a book) be represented by two objects instead of one, separating the common and unique information into two classes to avoid duplication.

    Given below is how the pattern is applied to the Library example:

    Here's a more generic example:

    The general solution:

    The <<Abstraction>> class should hold all common information, and the unique information should be kept by the <<Occurrence>> class. Note that ‘Abstraction’ and ‘Occurrence’ are not class names, but roles played by each class. Think of this diagram as a meta-model (i.e. a ‘model of a model’) of the BookTitle-BookCopy class diagram given above.

    Which pairs of classes are likely to be the <<Abstraction>> and the <<Occurrence>> of the abstraction occurrence pattern?

    1. CarModel, Car (Here, CarModel represents a particular model of a car produced by the car manufacturer. E.g. BMW R4300)
    2. Car, Wheel
    3. Club, Member
    4. TeamLeader, TeamMember
    5. Magazine (E.g. ReadersDigest, PCWorld), MagazineIssue

    One of the key things to keep in mind is that the <<Abstraction>> does not represent a real entity. Rather, it represents some information common to a set of objects. A single real entity is represented by an object of <<Abstraction>> type and <<Occurrence>> type.

    Before applying the pattern, some attributes have the same values for multiple objects. For example, w.r.t. the BookTitle-BookCopy example given in this handout, values of attributes such as bookTitle, ISBN are exactly the same for copies of the same book.

    After applying the pattern, the Abstraction and the Occurrence classes together represent one entity. It is as if one class has been split into two. For example, a BookTitle object and a BookCopy object combine to represent an actual Book.

    1. CarModel, Car: Yes
    2. Car, Wheel: No. Wheel is a ‘part of’ Car. A wheel is not an occurrence of Car.
    3. Club, Member: No. This is a ‘part of’ relationship.
    4. TeamLeader, TeamMember: No. A TeamMember is not an occurrence of a TeamLeader or vice versa.
    5. Magazine, MagazineIssue: Yes.

    Which one of these is most suited for an application of the Abstraction Occurrence pattern?

    (a)

    Explanation:

    (a) Stagings of a drama are ‘occurrences’ of the drama. They have many common attributes (e.g., Drama name, producer, cast, etc.) but some attributes are different (e.g., venue, time).

    (b) Students are not occurrences of a Teacher or vice versa.

    (c) Module, Exam, and Assignment are distinct entities with associations among them, but none of them can be considered an occurrence of another.

    Follow up notes for the item(s) above:

    A couple of more design patterns will be covered next week.

    Guidance for the item(s) below:

    You already know some techniques (e.g., exceptions, assertions) to make the code more resilient to errors. Given next is an overarching approach to coding that aims to push further in that direction.

    [W10.2] Defensive Programming

    Video

    W10.2a

    Implementation → Error Handling → Defensive Programming → What

    Can explain defensive programming

    A defensive programmer codes under the assumption "if you leave room for things to go wrong, they will go wrong". Therefore, a defensive programmer proactively tries to eliminate any room for things to go wrong.

    Consider a method MainApp#getConfig() that returns a Config object containing configuration data. A typical implementation is given below:

    class MainApp {
    Config config;

    /** Returns the config object */
    Config getConfig() {
    return config;
    }
    }

    If the returned Config object is not meant to be modified, a defensive programmer might use a more defensive implementation given below. This is more defensive because even if the returned Config object is modified (although it is not meant to be), it will not affect the config object inside the MainApp object.

        /** Returns a copy of the config object */
    Config getConfig() {
    return config.copy(); // return a defensive copy
    }

    W10.2b

    Implementation → Error Handling → Defensive Programming → Enforcing compulsory associations

    Can use defensive coding to enforce compulsory associations

    Consider two classes, Account and Guarantor, with an association as shown in the following diagram:

    Example:

    Here, the association is compulsory i.e. an Account object should always be linked to a Guarantor. One way to implement this is to simply use a reference variable, like this:

    class Account {
    Guarantor guarantor;

    void setGuarantor(Guarantor g) {
    guarantor = g;
    }
    }

    However, what if someone else used the Account class like this?

    Account a = new Account();
    a.setGuarantor(null);

    This results in an Account without a Guarantor! In a real banking system, this could have serious consequences! The code here did not try to prevent such a thing from happening. You can make the code more defensive by proactively enforcing the multiplicity constraint, like this:

    class Account {
    private Guarantor guarantor;

    public Account(Guarantor g) {
    if (g == null) {
    stopSystemWithMessage("multiplicity violated. Null Guarantor");
    }
    guarantor = g;
    }
    public void setGuarantor(Guarantor g) {
    if (g == null) {
    stopSystemWithMessage("multiplicity violated. Null Guarantor");
    }
    guarantor = g;
    }

    }

    For the Manager class shown below, write an addAccount() method that

    • restricts the maximum number of Accounts to 8
    • avoids adding duplicate Accounts

    import java.util.*;

    public class Manager {
    private ArrayList<Account> theAccounts;

    public void addAccount(Account acc) throws Exception {
    if (theAccounts.size() == 8) {
    throw new Exception("adding more than 8 accounts");
    }

    if (!theAccounts.contains(acc)) {
    theAccounts.add(acc);
    }
    }

    public void removeAccount(Account acc) {
    theAccounts.remove(acc);
    }
    }

    Implement the classes defensively with appropriate references and operations to establish the associations among the classes. Follow the defensive coding approach. Let the Marriage class handle the setting/removal of references.

    public class Marriage {
    private Man husband = null;
    private Woman wife = null;

    // extra information like date etc can be added

    public Marriage(Man m, Woman w) throws Exception {
    if (m == null || w == null) {
    throw new Exception("no man/woman");
    }
    if (m.isMarried() || w.isMarried()) {
    throw new Exception("already married");
    }
    husband = m;
    m.enterMarriage(this);
    wife = w;
    w.enterMarriage(this);
    }

    public Man getHusband() throws Exception {
    if (husband == null) {
    throw new Exception("error state");
    } else {
    return husband;
    }
    }

    public Woman getWife() throws Exception {
    if (wife == null) {
    throw new Exception("error state");
    } else {
    return wife;
    }
    }

    // removal of both ends of 'Marriage'
    public void divorce() throws Exception {
    if (husband == null || wife == null) {
    throw new Exception("no marriage");
    }
    husband.removeFromMarriage(this);
    husband = null;
    wife.removeFromMarriage(this);
    wife = null;
    }
    }

    Give a suitable defensive implementation to the Account class in the following class diagram. Note that “{immutable}” means once the association is formed, it cannot be changed.

    class Account {
    private Guarantor myGuarantor; // should not be public

    public Account(Guarantor g) {
    if (g == null) {
    haltWithErrorMessage(“Account must have a guarantor”);
    }
    myGuarantor = g;
    }
    // there should not be a setGuarantor method
    }

    class City {
    Country country;

    void setCountry(Country country) {
    this.country = country;
    }
    }

    This is a defensive implementation of the association.

    False

    Explanation: While the design requires a City to be connected to exactly one Country, the code allows it to be connected to zero Country objects (by passing null to the setCountry() method).

    W10.2c : OPTIONAL

    Implementation → Error Handling → Defensive Programming → Enforcing 1-to-1 associations

    Can use defensive coding to enforce 1-to-1 associations

    Consider the association given below. A defensive implementation requires us to ensure that a MinedCell cannot exist without a Mine and vice versa which requires simultaneous object creation. However, Java can only create one object at a time. Given below are two alternative implementations, both of which violate the multiplicity for a short period of time.

    Option 1:

    class MinedCell {
    private Mine mine;

    public MinedCell(Mine m) {
    if (m == null) {
    showError();
    }
    mine = m;
    }

    }

    Option 1 forces us to keep a Mine without a MinedCell (until the MinedCell is created).

    Option 2:

    class MinedCell {
    private Mine mine;

    public MinedCell() {
    mine = new Mine();
    }

    }

    Option 2 is more defensive because the Mine is immediately linked to a MinedCell.

    W10.2d : OPTIONAL

    Implementation → Error Handling → Defensive Programming → Enforcing referential integrity

    Can use defensive coding to enforce referential integrity of bidirectional associations

    A bidirectional association in the design (shown in (a)) is usually emulated at code level using two variables (as shown in (b)).

    class Man {
    Woman girlfriend;

    void setGirlfriend(Woman w) {
    girlfriend = w;
    }

    }
    class Woman {
    Man boyfriend;

    void setBoyfriend(Man m) {
    boyfriend = m;
    }
    }

    The two classes are meant to be used as follows:

    Woman jean;
    Man james;

    james.setGirlfriend(jean);
    jean.setBoyfriend(james);

    Suppose the two classes were used like this instead:

    Woman jean;
    Man james, yong;

    james.setGirlfriend(jean);
    jean.setBoyfriend(yong);

    Now James' girlfriend is Jean, while Jean's boyfriend is not James. This situation is a result of the code not being defensive enough to stop this "love triangle". In such a situation, you could say that the referential integrity has been violated. This means that there is an inconsistency in object references.

    One way to prevent this situation is to implement the two classes as shown below. Note how the referential integrity is maintained.

    public class Woman {
    private Man boyfriend;

    public void setBoyfriend(Man m) {
    if (boyfriend == m) {
    return;
    }
    if (boyfriend != null) {
    boyfriend.breakUp();
    }
    boyfriend = m;
    m.setGirlfriend(this);
    }

    public void breakUp() {
    boyfriend = null;
    }
    ...
    }
    public class Man {
    private Woman girlfriend;

    public void setGirlfriend(Woman w) {
    if (girlfriend == w) {
    return;
    }
    if (girlfriend != null) {
    girlfriend.breakUp();
    }
    girlfriend = w;
    w.setBoyfriend(this);
    }
    public void breakUp() {
    girlfriend = null;
    }
    ...
    }

    When james.setGirlfriend(jean) is executed, the code ensures that james breaks up with any current girlfriend before he accepts jean as his girlfriend. Furthermore, the code ensures that jean breaks up with any existing boyfriends before accepting james as her boyfriend.

    Imagine that you now support the following feature in our Minesweeper game.

    Feature ID: Multiplayer
    Description: A minefield is divided into mine regions. Each region is assigned to a single player. Players can swap regions. To win the game, all regions must be cleared.

    Given below is an extract from our class diagram.

    Minimally, this can be implemented like this.

    class Player {
    Region region;
    void setRegion(Region r) {
    region = r;
    }
    Region getRegion() {
    return region;
    }
    }

    // Region class is similar

    However, this is not very defensive. For example, a user of this class can pass a null to either of the methods, thus violating the multiplicity of the relationship.

    Implement the two classes using a more defensive approach. Take note of the bidirectional link which requires us to preserve referential integrity at all times.

    In this solution, assume Regions can be created without Players (note that you cannot be 100% defensive all the time). The usage will be something like this:

    Region r1 = new Region();
    Player p1 = new Player(r1);
    Region r2 = new Region();
    Player p2 = new Player(r2);
    p1.setRegion(r2);
    r1.setPlayer(p2);

    Here are the two classes. Get methods are omitted as they are simple. Note how much extra effort you need to be defensive.

    public class Region {
    private Player myPlayer;

    public Region() {
    // initialise region
    }

    public void setPlayer(Player newPlayer) {
    if (newPlayer == null) {
    stopSystemWithErrorMessage("Multiplicity violation");
    }
    if (myPlayer == newPlayer) {
    return; // same player
    }
    if (myPlayer != null) {
    // I already have a Player!
    myPlayer.removeRegion(this);
    }
    myPlayer = newPlayer;
    // set the reverse link
    myPlayer.setRegion(this);
    }

    public void removePlayer(Player disconnectingPlayer) {
    if (myPlayer == disconnectingPlayer) {
    myPlayer = null;
    } else {
    stopSystemWithErrorMessage("Unknown Player trying to disconnect");
    }
    }

    private void stopSystemWithErrorMessage(String msg) {
    ...
    }
    }
    public class Player {
    private Region myRegion;

    public Player(Region region) {
    setRegion(region);
    }

    public void setRegion(Region newRegion) {
    if (newRegion == null) {
    stopSystemWithErrorMessage("Multiplicity violation");
    }
    if (myRegion == newRegion) {
    return; // no change in Region!
    }
    if (myRegion != null) {
    // previous region exists
    myRegion.removePlayer(this);
    }
    myRegion = newRegion;

    // set the reverse link
    myRegion.setPlayer(this);
    }

    public void removeRegion(Region disconnectingRegion) {
    if (myRegion == disconnectingRegion) {
    myRegion = null;
    }
    }

    private void stopSystemWithErrorMessage(String msg) {
    ...
    }
    }

    Note that the above code stops the system when the multiplicity is violated. Alternatively, you can throw an exception and let the caller handle the situation.

    Implement this bidirectional association. Note that the Bank uses the accNumber attribute to uniquely identify an Account object. Assume the Bank class is responsible for maintaining the links between objects.

    The code below contains a method in the Bank class to create an account; the bank field in the new account is thereby filled by the bank creating it.

    Assume that once an Account has been assigned to a Bank, it cannot be assigned to a different Bank. Once the Account is removed from the Bank, it will not be used anymore (hence, no need to remove the link from Account to Bank).

    public class Account {
    private int accNumber;
    private Bank theBank;

    public Account(int n, Bank b) {
    accNumber = n;
    theBank = b;
    }
    public int getNumber() {
    return accNumber;
    }
    public Bank getBank() {
    return theBank;
    }
    }
    import java.util.*;

    public class Bank {
    private HashMap<Integer, Account> theAccounts = new HashMap<Integer, Account>();

    public void createAccount(int n) {
    addAccount(new Account(n, this));
    }
    public void addAccount(Account a) {
    theAccounts.put(a.getNumber(), a);
    }
    public void removeAccount(int accNumber) {
    theAccounts.remove(accNumber);
    }
    public Account lookupAccount(int accNumber) {
    return theAccounts.get(accNumber);
    }
    }

    (a) Is the code given below a defensive translation of the associations shown in the class diagram? Explain your answer.

    class Teacher {
    private Student favoriteStudent;

    void setFavoriteStudent(Student s) {
    favoriteStudent = s;
    }
    }
    class Student {
    private Teacher favoriteTeacher;

    void setFavoriteTeacher(Teacher t) {
    favoriteTeacher = t;
    }
    }

    (b) In terms of maintaining referential integrity in the implementation, what is the difference between the following two diagrams?

    (c) Show a defensive implementation of the remove(Member m) method of the Club class given below.

    (a) Yes. Each link is mutable and unidirectional. A simple reference variable is suitable to hold the link.

    The Teacher class can be made even more defensive by introducing a resetFavoriteStudent() method to unlink the current favorite student from a teacher. In that case, the setFavoriteStudent(Student) method should not accept null. This approach is more defensive because it prevents a null value being passed to setFavoriteStudent(Student) by mistake and being interpreted as a request to de-link the current favorite student from the Teacher object.

    (b) First diagram has unidirectional links. Second has a bidirectional link. RI is only applicable to the second.

    (c)

    void removeMember(Member m) {
    if (m==null) {
    throw exception("this is null, not a member!");
    } else if (member_count == 10) {
    throw exception("we need at least 10 members to survive!");
    } else if (!isMember(m)) {
    throw exception("this fellow is not a member of our club!");
    } else {
    members.remove(m); // members is a data structure such as ArrayList
    }
    }

    Bidirectional associations, if not implemented properly, can result in referential integrity violations.

    True

    Explanation: Bidirectional associations require two objects to link to each other. When one of these links is not consistent with the other, you have a referential integrity violation.

    W10.2e

    Implementation → Error Handling → Defensive Programming → When

    Can explain when to use defensive programming

    It is not necessary to be 100% defensive all the time. While defensive code may be less prone to be misused or abused, such code can also be more complicated and slower to run.

    The suitable degree of defensiveness depends on many factors such as:

    • How critical is the system?
    • Will the code be used by programmers other than the author?
    • The level of programming language support for defensive programming
    • The overhead of being defensive

    Defensive programming,

    • a. can make the program slower.
    • b. can make the code longer.
    • c. can make the code more complex.
    • d. can make the code less susceptible to misuse.
    • e. can require extra effort.

    (a)(b)(c)(d)(e)

    Explanation: Defensive programming requires a lot more checks, possibly making the code longer, more complex, and slower. Use it only when benefits outweigh costs, which is often.

    W10.2f : OPTIONAL

    Implementation → Error Handling → Design by Contract → Design by contract

    Can explain the Design-by-Contract approach

    term was coined by Bertrand MeyerDesign by contract (DbC) is an approach for designing software that requires defining formal, precise and verifiable interface specifications for software components.

    Suppose an operation is implemented with the behavior specified precisely in the API (preconditions, post conditions, exceptions etc.). When following the defensive approach, the code should first check if the preconditions have been met. Typically, exceptions are thrown if preconditions are violated. In contrast, the Design-by-Contract (DbC) approach to coding assumes that it is the responsibility of the caller to ensure all preconditions are met. The operation will honor the contract only if the preconditions have been met. If any of them have not been met, the behavior of the operation is "unspecified".

    Languages such as Eiffel have native support for DbC. For example, preconditions of an operation can be specified in Eiffel and the language runtime will check precondition violations without the need to do it explicitly in the code. To follow the DbC approach in languages such as Java and C++ where there is no built-in DbC support, assertions can be used to confirm pre-conditions.

    Which statements are correct?

    • a. It is not natively supported by Java and C++.
    • b. It is an alternative to OOP.
    • c. It assumes the caller of a method is responsible for ensuring all preconditions are met.

    (a)(b)(c)

    Explanation: DbC is not an alternative to OOP. You can use DbC in an OOP solution.

    Guidance for the item(s) below:

    Previously, we learned how to measure test coverage. This week, we look into how to increase coverage with the least number of test cases.

    First, we take a look at test case design in general, different approaches to test case design, and few different categorization of test cases.

    [W10.3] Test Cases: Intro

    W10.3a

    Quality Assurance → Test Case Design → Introduction → What

    Video

    Can explain the need for deliberate test case design

    Except for trivial Software Under TestSUTs, testing all possible casesexhaustive testing is not practical because such testing often requires a massive/infinite number of test cases.

    Consider the test cases for adding a string object to a Java: ArrayList,
    Python: list
    collection
    :

    • Add an item to an empty collection.
    • Add an item when there is one item in the collection.
    • Add an item when there are 2, 3, .... n items in the collection.
    • Add an item that has an English, a French, a Spanish, ... word.
    • Add an item that is the same as an existing item.
    • Add an item immediately after adding another item.
    • Add an item immediately after system startup.
    • ...

    Exhaustive testing of this operation can take many more test cases.

    Program testing can be used to show the presence of bugs, but never to show their absence!
    --Edsger Dijkstra

    Every test case adds to the cost of testing. In some systems, a single test case can cost thousands of dollars e.g. on-field testing of flight-control software. Therefore, test cases need to be designed to make the best use of testing resources. In particular:

    • Testing should be effective i.e., it finds a high percentage of existing bugs e.g., a set of test cases that finds 60 defects is more effective than a set that finds only 30 defects in the same system.

    • Testing should be efficient i.e., it has a high rate of success (bugs found/test cases) a set of 20 test cases that finds 8 defects is more efficient than another set of 40 test cases that finds the same 8 defects.

    For testing to be Efficient and EffectiveE&E, each new test you add should be targeting a potential fault that is not already targeted by existing test cases. There are test case design techniques that can help us improve the E&E of testing.

    Given below is the sample output from a text-based program TriangleDetector that determines whether the three input numbers make up the three sides of a valid triangle. List test cases you would use to test this software. Two sample test cases are given below.

    C:\> java TriangleDetector
    Enter side 1: 34
    Enter side 2: 34
    Enter side 3: 32
    Can this be a triangle?: Yes
    Enter side 1:

    Sample test cases,

    34, 34, 34: Yes
    0, any valid, any valid: No

    In addition to obvious test cases such as

    • sum of two sides == third,
    • sum of two sides < third ...

    We may also devise some interesting test cases such as the ones depicted below.

    Note that their applicability depends on the context in which the software is operating.

    • Non-integer numbers, negative numbers, 0, numbers formatted differently (e.g. 13F), very large numbers (e.g. MAX_INT), numbers with many decimal places, empty strings, ...
    • Check many triangles one after the other (will the system run out of memory?)
    • Backspace, Tab, CTRL+C , …
    • Introduce a long delay between entering data (will the program be affected by, say the screensaver?), minimize and restore window during the operation, hibernate the system in the middle of a calculation, start with invalid inputs (the system may perform error handling differently for the very first test case), …
    • Test on different locales.

    The main point to note is how difficult it is to test exhaustively, even on a trivial system.

    Explain why exhaustive testing is not practical using the example of testing the newGame() operation in the Logic class of a Minesweeper game.

    Consider this sequence of test cases:

    • Test case 1. Start Minesweeper. Activate newGame() and see if it works.
    • Test case 2. Start Minesweeper. Activate newGame(). Activate newGame() again and see if it works.
    • Test case 3. Start Minesweeper. Activate newGame() three times consecutively and see if it works.
    • Test case 267. Start Minesweeper. Activate newGame() 267 times consecutively and see if it works.

    Well, you get the idea. Exhaustive testing of newGame() is not practical.

    Improving the efficiency and effectiveness of test case design can,

    • a. improve the quality of the SUT.
    • b. save money.
    • c. save time spent on test execution.
    • d. save effort on writing and maintaining tests.
    • e. minimize redundant test cases.
    • f. force us to understand the SUT better.

    (a)(b)(c)(d)(e)(f)

    W10.3b

    Quality Assurance → Test Case Design → Introduction → Positive versus negative test cases

    Can explain positive and negative test cases

    A positive test case is when the test is designed to produce an expected/valid behavior. On the other hand, a negative test case is designed to produce a behavior that indicates an invalid/unexpected situation, such as an error message.

    Consider the testing of the method print(Integer i) which prints the value of i.

    • A positive test case: i == new Integer(50);
    • A negative test case: i == null;

    W10.3c

    Quality Assurance → Test Case Design → Introduction → Black box versus glass box

    Video

    Can explain black box and glass box test case design

    Test case design can be of three types, based on how much of the SUT's internal details are considered when designing test cases:

    • Black-box (aka specification-based or responsibility-based) approach: test cases are designed exclusively based on the SUT’s specified external behavior.

    • White-box (aka glass-box or structured or implementation-based) approach: test cases are designed based on what is known about the SUT’s implementation, i.e. the code.

    • Gray-box approach: test case design uses some important information about the implementation. For example, if the implementation of a sort operation uses different algorithms to sort lists shorter than 1000 items and lists longer than 1000 items, more meaningful test cases can then be added to verify the correctness of both algorithms.

    Note: these videos are from the Udacity course Software Development Process by Georgia Tech

    W10.3d

    Quality Assurance → Test Case Design → Testing based on use cases

    Can explain test case design for use case based testing

    Use cases can be used for system testing and acceptance testing. For example, the main success scenario can be one test case while each variation (due to extensions) can form another test case. However, note that use cases do not specify the exact data entered into the system. Instead, it might say something like user enters his personal data into the system. Therefore, the tester has to choose data by considering equivalence partitions and boundary values. The combinations of these could result in one use case producing many test cases.

    To increase the E&E of testing, high-priority use cases are given more attention. For example, a scripted approach can be used to test high-priority test cases, while an exploratory approach is used to test other areas of concern that could emerge during testing.

    Every test case adds to the cost of testing. In some systems, a single test case can cost thousands of dollars e.g. on-field testing of flight-control software. Therefore, test cases need to be designed to make the best use of testing resources. In particular:

    • Testing should be effective i.e., it finds a high percentage of existing bugs e.g., a set of test cases that finds 60 defects is more effective than a set that finds only 30 defects in the same system.

    • Testing should be efficient i.e., it has a high rate of success (bugs found/test cases) a set of 20 test cases that finds 8 defects is more efficient than another set of 40 test cases that finds the same 8 defects.

    For testing to be Efficient and EffectiveE&E, each new test you add should be targeting a potential fault that is not already targeted by existing test cases. There are test case design techniques that can help us improve the E&E of testing.

    Quality Assurance → Testing → Exploratory and Scripted Testing →

    What

    Here are two alternative approaches to testing a software: Scripted testing and Exploratory testing.

    1. Scripted testing: First write a set of test cases based on the expected behavior of the SUT, and then perform testing based on that set of test cases.

    2. Exploratory testing: Devise test cases on-the-fly, creating new test cases based on the results of the past test cases.

    Exploratory testing is ‘the simultaneous learning, test design, and test execution’ [source: bach-et-explained] whereby the nature of the follow-up test case is decided based on the behavior of the previous test cases. In other words, running the system and trying out various operations. It is called exploratory testing because testing is driven by observations during testing. Exploratory testing usually starts with areas identified as error-prone, based on the tester’s past experience with similar systems. One tends to conduct more tests for those operations where more faults are found.

    Here is an example thought process behind a segment of an exploratory testing session:

    “Hmm... looks like feature x is broken. This usually means feature n and k could be broken too; you need to look at them soon. But before that, you should give a good test run to feature y because users can still use the product if feature y works, even if x doesn’t work. Now, if feature y doesn’t work 100%, you have a major problem and this has to be made known to the development team sooner rather than later...”

    Exploratory testing is also known as reactive testing, error guessing technique, attack-based testing, and bug hunting.

    Exploratory Testing Explained, an online article by James Bach -- James Bach is an industry thought leader in software testing.

    Scripted testing requires tests to be written in a scripting language; manual testing is called exploratory testing.

    False

    Explanation: “Scripted” means test cases are predetermined. They need not be an executable script. However, exploratory testing is usually manual.

    Which testing technique is better?

    (e)

    Explain the concept of exploratory testing using Minesweeper as an example.

    When we test Minesweeper by simply playing it in various ways, especially trying out those that are likely to be buggy, that would be exploratory testing.

    Guidance for the item(s) below:

    Next, a heuristic used for improving the quality of test cases.

    [W10.4] Test Cases: Equivalence Partitioning

    W10.4a

    Quality Assurance → Test Case Design → Equivalence Partitions → What

    Video

    Can explain equivalence partitions

    Consider the testing of the following operation.

    isValidMonth(m) : returns true if m (and int) is in the range [1..12]

    It is inefficient and impractical to test this method for all integer values [-MIN_INT to MAX_INT]. Fortunately, there is no need to test all possible input values. For example, if the input value 233 fails to produce the correct result, the input 234 is likely to fail too; there is no need to test both.

    In general, most SUTs do not treat each input in a unique way. Instead, they process all possible inputs in a small number of distinct ways. That means a range of inputs is treated the same way inside the SUT. Equivalence partitioning (EP) is a test case design technique that uses the above observation to improve the E&E of testing.

    Equivalence partition (aka equivalence class): A group of test inputs that are likely to be processed by the SUT in the same way.

    By dividing possible inputs into equivalence partitions you can,

    • avoid testing too many inputs from one partition. Testing too many inputs from the same partition is unlikely to find new bugs. This increases the efficiency of testing by reducing redundant test cases.
    • ensure all partitions are tested. Missing partitions can result in bugs going unnoticed. This increases the effectiveness of testing by increasing the chance of finding bugs.

    W10.4b

    Quality Assurance → Test Case Design → Equivalence Partitions → Basic

    Video

    Can apply EP for pure functions

    Equivalence partitions (EPs) are usually derived from the specifications of the SUT.

    These could be EPs for the isValidMonth example:

    • [MIN_INT ... 0]: below the range that produces true (produces false)
    • [1 … 12]: the range that produces true
    • [13 … MAX_INT]: above the range that produces true (produces false)
    isValidMonth

    isValidMonth(m) : returns true if m (and int) is in the range [1..12]

    When the SUT has multiple inputs, you should identify EPs for each input.

    Consider the method duplicate(String s, int n): String which returns a String that contains s repeated n times.

    Example EPs for s:

    • zero-length strings
    • string containing whitespaces
    • ...

    Example EPs for n:

    • 0
    • negative values
    • ...

    An EP may not have adjacent values.

    Consider the method isPrime(int i): boolean that returns true if i is a prime number.

    EPs for i:

    • prime numbers
    • non-prime numbers

    Some inputs have only a small number of possible values and a potentially unique behavior for each value. In those cases, you have to consider each value as a partition by itself.

    Consider the method showStatusMessage(GameStatus s): String that returns a unique String for each of the possible values of s (GameStatus is an enum). In this case, each possible value of s will have to be considered as a partition.

    Note that the EP technique is merely a heuristic and not an exact science, especially when applied manually (as opposed to using an automated program analysis tool to derive EPs). The partitions derived depend on how one ‘speculates’ the SUT to behave internally. Applying EP under a glass-box or gray-box approach can yield more precise partitions.

    Consider the EPs given above for the method isValidMonth. A different tester might use these EPs instead:

    • [1 … 12]: the range that produces true
    • [all other integers]: the range that produces false

    Some more examples:

    Specification Equivalence partitions

    isValidFlag(String s): boolean
    Returns true if s is one of ["F", "T", "D"]. The comparison is case-sensitive.

    ["F"] ["T"] ["D"] ["f", "t", "d"] [any other string][null]

    squareRoot(String s): int
    Pre-conditions: s represents a positive integer.
    Returns the square root of s if the square root is an integer; returns 0 otherwise.

    [s is not a valid number] [s is a negative integer] [s has an integer square root] [s does not have an integer square root]

    Consider this SUT:

    isValidName(String s): boolean

    Description: returns true if s is not null and not longer than 50 characters.

    A. Which one of these is least likely to be an equivalence partition for the parameter s of the isValidName method given above?

    B. If you had to choose 3 test cases from the 4 given below, which one will you leave out based on the EP technique?

    A. (d)

    Explanation: The description does not mention anything about the content of the string. Therefore, the method is unlikely to behave differently for strings consisting of numbers.

    B. (a) or (c)

    Explanation: both belong to the same EP.

    W10.4c

    Quality Assurance → Test Case Design → Equivalence Partitions → Intermediate

    Can apply EP for OOP methods

    When deciding EPs of OOP methods, you need to identify the EPs of all data participants that can potentially influence the behaviour of the method, such as,

    • the target object of the method call
    • input parameters of the method call
    • other data/objects accessed by the method such as global variables. This category may not be applicable if using the black box approach (because the test case designer using the black box approach will not know how the method is implemented).

    Consider this method in the DataStack class: push(Object o): boolean

    • Adds o to the top of the stack if the stack is not full.
    • Returns true if the push operation was a success.
    • Throws
      • MutabilityException if the global flag FREEZE==true.
      • InvalidValueException if o is null.

    EPs:

    • DataStack object: [full] [not full]
    • o: [null] [not null]
    • FREEZE: [true][false]

    Consider a simple Minesweeper app. What are the EPs for the newGame() method of the Logic component?

    As newGame() does not have any parameters, the only obvious participant is the Logic object itself.

    Note that if the glass-box or the grey-box approach is used, other associated objects that are involved in the method might also be included as participants. For example, the Minefield object can be considered as another participant of the newGame() method. Here, the black-box approach is assumed.

    Next, let us identify equivalence partitions for each participant. Will the newGame() method behave differently for different Logic objects? If yes, how will it differ? In this case, yes, it might behave differently based on the game state. Therefore, the equivalence partitions are:

    • PRE_GAME: before the game starts, minefield does not exist yet
    • READY: a new minefield has been created and the app is waiting for the player’s first move
    • IN_PLAY: the current minefield is already in use
    • WON, LOST: let us assume that newGame() behaves the same way for these two values

    Consider the Logic component of the Minesweeper application. What are the EPs for the markCellAt(int x, int y) method? The partitions in bold represent valid inputs.

    • Logic: PRE_GAME, READY, IN_PLAY, WON, LOST
    • x: [MIN_INT..-1] [0..(W-1)] [W..MAX_INT] (assuming a minefield size of WxH)
    • y: [MIN_INT..-1] [0..(H-1)] [H..MAX_INT]
    • Cell at (x,y): HIDDEN, MARKED, CLEARED

    Guidance for the item(s) below:

    Previously, you learned about equivalence partitions, a heuristic for dividing the possible test cases into partitions. But which test cases should we pick from each partition? Next, let us learn another heuristic which can addresses that problem.

    [W10.5] Test Cases: Boundary Value Analysis

    W10.5a

    Quality Assurance → Test Case Design → Boundary Value Analysis → What

    Video

    Can explain boundary value analysis

    Boundary Value Analysis (BVA) is a test case design heuristic that is based on the observation that bugs often result from incorrect handling of boundaries of equivalence partitions. This is not surprising, as the end points of boundaries are often used in branching instructions, etc., where the programmer can make mistakes.

    The markCellAt(int x, int y) operation could contain code such as if (x > 0 && x <= (W-1)) which involves the boundaries of x’s equivalence partitions.

    BVA suggests that when picking test inputs from an equivalence partition, values near boundaries (i.e. boundary values) are more likely to find bugs.

    Boundary values are sometimes called corner cases.

    Boundary value analysis recommends testing only values that reside on the equivalence class boundary.

    False

    Explanation: It does not recommend testing only those values on the boundary. It merely suggests that values on and around a boundary are more likely to cause errors.

    W10.5b

    Quality Assurance → Test Case Design → Boundary Value Analysis → How

    Video

    Can apply boundary value analysis

    Typically, you should choose three values around the boundary to test: one value from the boundary, one value just below the boundary, and one value just above the boundary. The number of values to pick depends on other factors, such as the cost of each test case.

    Some examples:

    Equivalence partition Some possible test values (boundaries are in bold)

    [1-12]

    0,1,2, 11,12,13

    [MIN_INT, 0]
    (MIN_INT is the minimum possible integer value allowed by the environment)

    MIN_INT, MIN_INT+1, -1, 0 , 1

    [any non-null String]
    (assuming string length is the aspect of interest)

    Empty String, a String of maximum possible length

    [prime numbers]
    [“F”]
    [“A”, “D”, “X”]

    No specific boundary
    No specific boundary
    No specific boundary

    [non-empty Stack]
    (assuming a fixed size stack)

    Stack with: no elements, one element, two elements, no empty spaces, only one empty space