This site is from a past semester! The current version will be here when the new semester starts.
CS2113/T 2021 Jan-May
  • Full Timeline
  • Week 1 [Mon, Jan 11th]
  • Week 2 [Mon, Jun 21st]
  • Week 3 [Mon, Jun 28th]
  • Week 4 [Mon, Jul 5th]
  • Week 5 [Mon, Jul 12th]
  • Week 6 [Mon, Jul 19th]
  • Week 7 [Mon, Jul 26th]
  • Week 8 [Mon, Aug 9th]
  • Week 9 [Mon, Aug 16th]
  • Week 10 [Mon, Aug 23rd]
  • Week 11 [Mon, Aug 30th]
  • Week 12 [Mon, Sep 6th]
  • Week 13 [Mon, Sep 13th]
  • Textbook
  • Admin Info
  • Dashboards
  •  Individual Project (iP):
  • Individual Project Info
  • iP Upstream Repo
  • iP Code Dashboard
  • iP Progress Dashboard

  •  Team Project (tP):
  • Team Project Info
  • Reference AB3
  • Team List
  • tP Code Dashboard
  • tP Progress Dashboard
  • Java exercises
  • Report Bugs
  • Forum
  • Gitter (Chat)
  • Instructors
  • Announcements
  • Files (handouts, submissions etc.)
  • Tutorial Schedule
  • Java Coding Standard
  • Git Conventions
  • Forum Activities Dashboard
  • Participation Dashboard
  • Week 10 [Mon, Aug 23rd] - Topics

    • [W10.1] Sequence Diagrams: Basics
    • [W10.1a] Design → Modelling → Modelling Behaviors Sequence diagrams - basic
    • [W10.2] Sequence Diagrams: Intermediate-Level
    • [W10.2a] Design → Modelling → Modelling Behaviors Sequence diagrams - intermediate

    • [W10.2b] Tools → UML → Sequence Diagrams → Parallel paths

    • [W10.2c] Tools → UML → Sequence Diagrams → Reference frames : OPTIONAL

    • [W10.3] Design Patterns

       Introduction

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

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

       Singleton pattern

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

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

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

       Facade pattern

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

    • [W10.4] Testing: Test Coverage
    • [W10.4a] Quality Assurance → Testing → Test Coverage → What

    • [W10.4b] Quality Assurance → Testing → Test Coverage → How


    Guidance for the item(s) below:

    Good news: this will the the last installment of UML notations.
    Bad news: we are going to cover an entire new diagram type in one go (reason: to give you more time to use them in project documentation).

    [W10.1] Sequence Diagrams: Basics

    W10.1a

    Design → Modelling → Modelling Behaviors Sequence diagrams - basic

    Can draw basic sequence diagrams

    Explain in your own words the interactions illustrated by this Sequence Diagram:

    Consider the code below:

    class Person {
        Tag tag;
        String name;
    
        Person(String personName, String tagName) {
            name = personName;
            tag = new Tag(tagName);
        }
    }
    
    class Tag {
        Tag(String value) {
            // ...
        }
    }
    
    class PersonList {
        void addPerson(Person p) {
            // ...
        }
    }
    

    Draw a sequence diagram to illustrate the object interactions that happen in the code snippet below:

    PersonList personList = new PersonList();
    while (hasRoom) {
        Person p = new Person("Adam", "friend");
        personList.addPerson(p);
    }
    

    Find notation mistakes in the sequence diagram below:

    [W10.2] Sequence Diagrams: Intermediate-Level

    W10.2a

    Design → Modelling → Modelling Behaviors Sequence diagrams - intermediate

    Can draw intermediate-level sequence diagrams

    Method calls to static (i.e., class-level) methods are received by the class itself, not an instance of that class. You can use <<class>> to show that a participant is the class itself.

    In this example, m calls the static method Person.getMaxAge() and also the setAge() method of a Person object p.

    Here is the Person class, for reference:

    What’s going on here?

    • a. Logic object is executing a parallel thread.
    • b. Logic object is executing a loop.
    • c. Logic object is creating another Logic instance.
    • d. One of Logic object’s methods is calling another of its methods.
    • e. Minefield object is calling a method of Logic.

    (d)

    Explain the interactions depicted in this sequence diagram.

    First, the createParser() method of an existing ParserFactory object is called. Then, ...

    Draw a sequence diagram to represent this code snippet.

    if (isFirstPage) {
        new Quote().print();
    }
    

    The Quote class:

    class Quote {
    
        String q;
    
        Quote() {
            q = generate();
        }
    
        String generate() {
            // ...
        }
    
        void print() {
            System.out.println(q);
        }
    
    }
    
    • Show new Quote().print(); as two method calls.
    • As the created Quote object is not assigned to a variable, it can be considered as 'deleted' soon after its print() method is called.

    W10.2b

    Tools → UML → Sequence Diagrams → Parallel paths

    Can interpret sequence diagrams with parallel paths

    UML uses par frames to indicate parallel paths.

    Notation:

    Logic is calling methods CloudServer#poll() and LocalServer#poll() in parallel.

    If you show parallel paths in a sequence diagram, the corresponding Java implementation is likely to be multi-threaded because a normal Java program cannot do multiple things at the same time.

    W10.2c : OPTIONAL

    Tools → UML → Sequence Diagrams → Reference frames

    Can interpret sequence diagrams with reference frames

    UML uses ref frame to allow a segment of the interaction to be omitted and shown as a separate sequence diagram. Reference frames help you to break complicated sequence diagrams into multiple parts or simply to omit details you are not interested in showing.

    Notation:

    The details of the get minefield appearance interactions have been omitted from the diagram.

    Those details are shown in a separate sequence diagram given below.

    Follow up notes for the item(s) above:

    After you have learned how to interpret sequence diagrams, you can watch this:

    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). There are many more principles but we covered only two (to reduce workload) just to give you a taste only.

    This week, we cover design patterns, a concept that builds upon the above. Again, we limit to only two of them, for similar reasons.

    [W10.3] Design Patterns


    Introduction

    Guidance for the item(s) below:

    First, let's learn what design patterns are, in general.

    W10.3a

    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.3b

    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

    W10.3c

    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.3d

    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.3e

    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

    W10.3f

    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).

    Follow up notes for the item(s) above:

    To learn more design patterns, you can refer to https://se-education.org/se-book/designPatterns/

    Guidance for the item(s) below:

    Previously, you learned how to write JUnit tests. How do you know which parts of the code is being tested by your tests? That's where test coverage comes in.

    [W10.4] Testing: Test Coverage

    W10.4a

    Quality Assurance → Testing → Test Coverage → What

    Can explain test coverage

    Test coverage is a metric used to measure the extent to which testing exercises the code i.e., how much of the code is 'covered' by the tests.

    Here are some examples of different coverage criteria:

    • Function/method coverage : based on functions executed e.g., testing executed 90 out of 100 functions.
    • Statement coverage : based on the number of lines of code executed e.g., testing executed 23k out of 25k LOC.
    • Decision/branch coverage : based on the decision points exercised e.g., an if statement evaluated to both true and false with separate test cases during testing is considered 'covered'.
    • Condition coverage : based on the boolean sub-expressions, each evaluated to both true and false with different test cases. Condition coverage is not the same as the decision coverage.

    if(x > 2 && x < 44) is considered one decision point but two conditions.

    For 100% branch or decision coverage, two test cases are required:

    • (x > 2 && x < 44) == true : [e.g. x == 4]
    • (x > 2 && x < 44) == false : [e.g. x == 100]

    For 100% condition coverage, three test cases are required:

    • (x > 2) == true , (x < 44) == true : [e.g. x == 4]
    • (x < 44) == false : [e.g. x == 100]
    • (x > 2) == false : [e.g. x == 0]
    • Path coverage measures coverage in terms of possible paths through a given part of the code executed. 100% path coverage means all possible paths have been executed. A commonly used notation for path analysis is called the Control Flow Graph (CFG).
    • Entry/exit coverage measures coverage in terms of possible calls to and exits from the operations in the SUT.

    Which of these gives us the highest intensity of testing?

    (b)

    Explanation: 100% path coverage implies all possible execution paths through the SUT have been tested. This is essentially ‘exhaustive testing’. While this is very hard to achieve for a non-trivial SUT, it technically gives us the highest intensity of testing. If all tests pass at 100% path coverage, the SUT code can be considered ‘bug free’. However, note that path coverage does not include paths that are missing from the code altogether because the programmer left them out by mistake.

    Guidance for the item(s) below:

    Learn how to measure test coverage in your tP. You will be asked to demo that in the coming tutorial.

    W10.4b

    Quality Assurance → Testing → Test Coverage → How

    Can explain how test coverage works

    Measuring coverage is often done using coverage analysis tools. Most IDEs have inbuilt support for measuring test coverage, or at least have plugins that can measure test coverage.

    Coverage analysis can be useful in improving the quality of testing e.g., if a set of test cases does not achieve 100% branch coverage, more test cases can be added to cover missed branches.

    Measuring code coverage in Intellij IDEA