This site is from a past semester! The current version is here.

Week 8 [Oct 7]

[W8.1] Design: Models

[W8.1a] Design → Modelling → Introduction → What
[W8.1b] Design → Modelling → Introduction → How

[W8.2] Structure Diagrams

Revisiting: Class/Ojbect Diagrams - Basics

[W8.2a] Design → Modelling → Modelling Structure → OO Structures
[W8.2b] Design → Modelling → Modelling Structure → Class Diagrams (Basics)
[W8.2c] Design → Modelling → Modelling Structure → Object Diagrams
[W8.2d] Tools → UML → Object vs Class Diagrams

UML: Class Diagrams - Intermediate

[W8.2e] Tools → UML → Notes
[W8.2f] Tools → UML → Constraints
[W8.2g] Tools → UML → Class Diagrams → Associations as Attributes
[W8.2h] Design → Modelling → Modelling Structure → Class Diagrams - Intermediate

UML: Association Classes

[W8.2i] Paradigms → OOP → Associations → Association Classes

[W8.3] Behavior Diagrams

UML: Sequence Diagrams - Basics

[W8.3a] Design → Modelling → Modelling Behaviors Sequence Diagrams - Basic

UML: Sequence Diagrams - Intermediate

[W8.3b] Design → Modelling → Modelling Behaviors Sequence Diagrams - Intermediate
[W8.3c] Tools → UML → Sequence Diagrams → Reference Frames
[W8.3d] Tools → UML → Sequence Diagrams → Parallel Paths

[W8.4] Error Handling

Logging

[W8.4a] Implementation → Error Handling → Logging → What
[W8.4b] Implementation → Error Handling → Logging → How

Assertions

[W8.4c] Implementation → Error Handling → Assertions → What
[W8.4d] Implementation → Error Handling → Assertions → How
[W8.4e] Implementation → Error Handling → Assertions → When

[W8.5] Product design guidelines

[W8.1] Design: Models

W8.1a Design → Modelling → Introduction → What

Can explain models

A model is a representation of something else.

A class diagram is a model that represents a software design.

A model provides a simpler view of a complex entity because a model captures only a selected aspect. This omission of some aspects implies models are abstractions.

Design → Design Fundamentals → Abstraction →

What

Abstraction is a technique for dealing with complexity. It works by establishing a level of complexity we are interested in, and suppressing the more complex details below that level.

The guiding principle of abstraction is that only details that are relevant to the current perspective or the task at hand needs to be considered. As most programs are written to solve complex problems involving large amounts of intricate details, it is impossible to deal with all these details at the same time. That is where abstraction can help.

Data abstraction: abstracting away the lower level data items and thinking in terms of bigger entities

Within a certain software component, we might deal with a user data type, while ignoring the details contained in the user data item such as name, and date of birth. These details have been ‘abstracted away’ as they do not affect the task of that software component.

Control abstraction: abstracting away details of the actual control flow to focus on tasks at a higher level

print(“Hello”) is an abstraction of the actual output mechanism within the computer.

Abstraction can be applied repeatedly to obtain progressively higher levels of abstractions.

An example of different levels of data abstraction: a File is a data item that is at a higher level than an array and an array is at a higher level than a bit.

An example of different levels of control abstraction: execute(Game) is at a higher level than print(Char) which is at a higher than an Assembly language instruction MOV.

Abstraction is a general concept that is not limited to just data or control abstractions.

Some more general examples of abstraction:

An OOP class is an abstraction over related data and behaviors.
An architecture is a higher-level abstraction of the design of a software.
Models (e.g., UML models) are abstractions of some aspect of reality.

A class diagram captures the structure of the software design but not the behavior.

Multiple models of the same entity may be needed to capture it fully.

In addition to a class diagram (or even multiple class diagrams), a number of other diagrams may be needed to capture various interesting aspects of the software.

W8.1b Design → Modelling → Introduction → How

Can explain how models are used

In software development, models are useful in several ways:

a) To analyze a complex entity related to software development.

Some examples of using models for analysis:

Models of the problem domain can be built to aid the understanding of the problem to be solved.
When planning a software solution, models can be created to figure out how the solution is to be built. An architecture diagram is such a model.

b) To communicate information among stakeholders. Models can be used as a visual aid in discussions and documentations.

Some examples of using models to communicate:

We can use an architecture diagram to explain the high-level design of the software to developers.
A business analyst can use a use case diagram to explain to the customer the functionality of the system.
A class diagram can be reverse-engineered from code so as to help explain the design of a component to a new developer.

c) As a blueprint for creating software. Models can be used as instructions for building software.

Some examples of using models to as blueprints:

A senior developer draws a class diagram to propose a design for an OOP software and passes it to a junior programmer to implement.
A software tool allows users to draw UML models using its interface and the tool automatically generates the code based on the model.

Model Driven Development extra

Model-driven development (MDD), also called Model-driven engineering, is an approach to software development that strives to exploit models as blueprints. MDD uses models as primary engineering artifacts when developing software. That is, the system is first created in the form of models. After that, the models are converted to code using code-generation techniques (usually, automated or semi-automated, but can even involve manual translation from model to code). MDD requires the use of a very expressive modeling notation (graphical or otherwise), often specific to a given problem domain. It also requires sophisticated tools to generate code from models and maintain the link between models and the code. One advantage of MDD is that the same model can be used to create software for different platforms and different languages. MDD has a lot of promise, but it is still an emerging technology

[W8.2] Structure Diagrams

Revisiting: Class/Ojbect Diagrams - Basics

W8.2a Design → Modelling → Modelling Structure → OO Structures

Can explain structure modelling of OO solutions

An OO solution is basically a network of objects interacting with each other. Therefore, it is useful to be able to model how the relevant objects are 'networked' together inside a software i.e. how the objects are connected together.

Given below is an illustration of some objects and how they are connected together. Note: the diagram uses an ad-hoc notation.

Note that these object structures within the same software can change over time.

Given below is how the object structure in the previous example could have looked like at a different time.

However, object structures do not change at random; they change based on a set of rules, as was decided by the designer of that software. Those rules that object structures need to follow can be illustrated as a class structure i.e. a structure that exists among the relevant classes.

Here is a class structure (drawn using an ad-hoc notation) that matches the object structures given in the previous two examples. For example, note how this class structure does not allow any connection between Genre objects and Author objects, a rule followed by the two object structures above.

UML Object Diagrams are used to model object structures and UML Class Diagrams are used to model class structures of an OO solution.

Here is an object diagram for the above example:

And here is the class diagram for it:

W8.2b Design → Modelling → Modelling Structure → Class Diagrams (Basics)

Can use basic-level class diagrams

Classes form the basis of class diagrams.

Associations are the main connections among the classes in a class diagram.

The most basic class diagram is a bunch of classes with some solid lines among them to represent associations, such as this one.

An example class diagram showing associations between classes.

In addition, associations can show additional decorations such as association labels, association roles, multiplicity and navigability to add more information to a class diagram.

Here is the same class diagram shown earlier but with some additional information included:

Which association notatations are shown in this diagram?

a. association labels
b. association roles
c. association multiplicity
d. class names

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

Explanation: '1’ is a multiplicity, ‘mentored by’ is a label, and ‘mentor’ is a role.

Explain the associations, navigabilities, and multiplicities in the class diagram below:

Draw a class diagram for the code below. Show the attributes, methods, associations, navigabilities, and multiplicities in the class diagram below:

class Box {
    private Item[] parts = new Item[10];
    private Item spareItem;
    private Lid lid; // lid of this box
    private Box outerBox;

    public void open(){
        //...
    }
}

class Item {
    public static int totalItems;
}

class Lid {
    Box box; // the box for which this is the lid
}

W8.2c Design → Modelling → Modelling Structure → Object Diagrams

Can use basic object diagrams

Object diagrams can be used to complement class diagrams. For example, you can use object diagrams to model different object structures that can result from a design represented by a given class diagram.

This question is based on the following question from another topic:

Draw a class diagram for the code below. Show the attributes, methods, associations, navigabilities, and multiplicities in the class diagram below:

class Box {
    private Item[] parts = new Item[10];
    private Item spareItem;
    private Lid lid; // lid of this box
    private Box outerBox;

    public void open(){
        //...
    }
}

class Item {
    public static int totalItems;
}

class Lid {
    Box box; // the box for which this is the lid
}

Draw an object diagram to match the code. Include objects of all three classes in your object diagram.

W8.2d Tools → UML → Object vs Class Diagrams

Can distinguish between class diagrams and object diagrams

Compared to the notation for a class diagrams, object diagrams differ in the following ways:

Shows objects instead of classes:
- Instance name may be shown
- There is a : before the class name
- Instance and class names are underlined
Methods are omitted
Multiplicities are omitted

Furthermore, multiple object diagrams can correspond to a single class diagram.

Both object diagrams are derived from the same class diagram shown earlier. In other words, each of these object diagrams shows ‘an instance of’ the same class diagram.

Which of these class diagrams match the given object diagram?

(a) (b)

Explanation: Both class diagrams allow one Unit object to be linked to one Item object.

UML: Class Diagrams - Intermediate

W8.2e Tools → UML → Notes

Can use UML notes

UML notes can augment UML diagrams with additional information. These notes can be shown connected to a particular element in the diagram or can be shown without a connection. The diagram below shows examples of both.

Example:

W8.2f Tools → UML → Constraints

Can specify constraints in UML diagrams

A constraint can be given inside a note, within curly braces. Natural language or a formal notation such as OCL (Object Constraint Language) may be used to specify constraints.

Example:

W8.2g Tools → UML → Class Diagrams → Associations as Attributes

Can show an association as an attribute

An association can be shown as an attribute instead of a line.

Association multiplicities and the default value too can be shown as part of the attribute using the following notation. Both are optional.

name: type [multiplicity] = default value

The diagram below depicts a multi-player Square Game being played on a board comprising of 100 squares. Each of the squares may be occupied with any number of pieces, each belonging to a certain player.

A Piece may or may not be on a Square. Note how that association can be replaced by an isOn attribute of the Piece class. The isOn attribute can either be null or hold a reference to a Square object, matching the 0..1 multiplicity of the association it replaces. The default value is null.

The association that a Board has 100 Sqaures can be shown in either of these two ways:

W8.2h Design → Modelling → Modelling Structure → Class Diagrams - Intermediate

Can use intermediate-level class diagrams

A class diagram can also show different types of associations: inheritance, compositions, aggregations, dependencies.

Modeling inheritance

Modeling composition

Modeling aggregation

Modeling dependencies

A class diagram can also show different types of class-like entities:

Modeling enumerations

Modeling abstract classes

Modeling interfaces

Which of these statements match the class diagram?

a. A Snake must belong to at least one Board.
b. A SnakeHeadSquare can contain only one Snake head.
c. A Square can contain a Snake head.
d. A Snake head can be in more than one SnakeHeadSquare
e. The Board has exactly 5 Snakes.

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

Explanation:

(a) does not match because a Snake may or may not belong to a Board (multiplicity is 0..1)
(b) matches the diagram because the multiplicity given in 1
(c) matches the diagram because SnakeHeadSquare is a Square (due to inheritance)
(d) matches the diagram because the multiplicity given is *
(e) matches the diagram because the multiplicity given in 5

Explain the meaning of various class diagram notations in the following class diagram:

Consider the code below:

public interface Billable {
    void bill();
}

public abstract class Item
         implements Billable {
    public abstract void print();
}

public class StockItem extends Item {
    private Review review;
    private String name;

    public StockItem(
        String name, Rating rating){

        this.name = name;
        this.review = new Review(rating);
    }

    @Override
    public void print() {
        //...
    }

    @Override
    public void bill() {
        //...
    }
}

public enum Rating {
    GOOD, OK, POOR
}

public class Review {
    private final Rating rating;

    public Review(Rating rating) {
        this.rating = rating;
    }
}

import java.util.List;

public class Inventory {
    private List<Item> items;

    public int getItemCount(){
        return items.size();
    }

    public void generateBill(Billable b){
        // ...
    }

    public void add(Item s) {
        items.add(s);
    }
}

(a) Draw a class diagram to represent the code
(b) Draw an object diagram to represent the situation where the inventory has one item with a name spanner and a review of POOR rating.

UML: Association Classes

W8.2i Paradigms → OOP → Associations → Association Classes

Can explain the meaning of association classes

An association class represents additional information about an association. It is a normal class but plays a special role from a design point of view.

A Man class and a Woman class is linked with a ‘married to’ association and there is a need to store the date of marriage. However, that data is related to the association rather than specifically owned by either the Man object or the Woman object. In such situations, an additional association class can be introduced, e.g. a Marriage class, to store such information.

Implementing association classes

There is no special way to implement an association class. It can be implemented as a normal class that has variables to represent the endpoint of the association it represents.

In the code below, the Transaction class is an association class that represent a transaction between a Person who is the seller and another Person who is the buyer.

class Transaction{
    
    //all fields are compulsory
    Person seller;
    Person buyer;
    Date date;
    String receiptNumber;
    
    Transaction (Person seller, Person buyer, Date date, String receiptNumber){
        //set fields
    }
}

Which one of these is the suitable as an Association Class?

(a)(b)~~(c)~~(d)

Explanation: Mileage is a property of the car, and not specifically about the association between the Driver and the Car. If Mileage was defined as the total number of miles that car was driven by that driver, then it would be suitable as an association class.

[W8.3] Behavior Diagrams

UML: Sequence Diagrams - Basics

W8.3a 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:

UML: Sequence Diagrams - Intermediate

W8.3b Design → Modelling → Modelling Behaviors Sequence Diagrams - Intermediate

Can draw intermediate-level sequence diagrams

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.

W8.3c 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 us to break complicated sequence diagrams into multiple parts or simply to omit details we 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.

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

[W8.4] Error Handling

Logging

W8.4a Implementation → Error Handling → Logging → What

Can explain logging

Logging is the deliberate recording of certain information during a program execution for future reference. Logs are typically written to a log file but it is also possible to log information in other ways e.g. into a database or a remote server.

Logging can be useful for troubleshooting problems. A good logging system records some system information regularly. When bad things happen to a system e.g. an unanticipated failure, their associated log files may provide indications of what went wrong and action can then be taken to prevent it from happening again.

A log file is like the black box of an airplane; they don't prevent problems but they can be helpful in understanding what went wrong after the fact.

_{source:https://commons.wikimedia.org}

Why is logging like having the 'black box' in an airplane?

a. Because they can be used to find more info about how the system behaved before/during an ‘incident’.
b. Because they are hidden from the view of normal users.
c. Because they both can be in hardcopy form or digital form.
d. Because they are hard to open by normal users.

(a)

W8.4b Implementation → Error Handling → Logging → How

Can use logging

Most programming environments come with logging systems that allow sophisticated forms of logging. They have features such as the ability to enable and disable logging easily or to change the logging intensity.

This sample Java code uses Java’s default logging mechanism.

First, import the relevant Java package:

import java.util.logging.*;

Next, create a Logger:

private static Logger logger = Logger.getLogger("Foo");

Now, you can use the Logger object to log information. Note the use of logging level for each message. When running the code, the logging level can be set to WARNING so that log messages specified as INFO level (which is a lower level than WARNING) will not be written to the log file at all.

// log a message at INFO level
logger.log(Level.INFO, "going to start processing");
//...
processInput();
if(error){
    //log a message at WARNING level
    logger.log(Level.WARNING, "processing error", ex);
}
//...
logger.log(Level.INFO, "end of processing");

Tutorials:

Java Logging API - Tutorial -- A tutorial by Lars Vogella
Java Logging Tutorial -- An alternative tutorial by Jakob Jenkov

A video tutorial by SimplyCoded:

Best Practices:

10 Tips for Proper Application Logging -- by Tomasz Nurkiewicz
What each logging level means -- conventions recommended by Apache Project

Assertions

W8.4c Implementation → Error Handling → Assertions → What

Can explain assertions

Assertions are used to define assumptions about the program state so that the runtime can verify them. An assertion failure indicates a possible bug in the code because the code has resulted in a program state that violates an assumption about how the code should behave.

An assertion can be used to express something like when the execution comes to this point, the variable v cannot be null.

If the runtime detects an assertion failure, it typically take some drastic action such as terminating the execution with an error message. This is because an assertion failure indicates a possible bug and the sooner the execution stops, the safer it is.

In the Java code below, suppose we set an assertion that timeout returned by Config.getTimeout() is greater than 0. Now, if the Config.getTimeout() returned -1 in a specific execution of this line, the runtime can detect it as a assertion failure -- i.e. an assumption about the expected behavior of the code turned out to be wrong which could potentially be the result of a bug -- and take some drastic action such as terminating the execution.

int timeout = Config.getTimeout();

W8.4d Implementation → Error Handling → Assertions → How

Can use assertions

Use the assert keyword to define assertions.

This assertion will fail with the message x should be 0 if x is not 0 at this point.

x = getX();
assert x == 0 : "x should be 0";
...

Assertions can be disabled without modifying the code.

java -enableassertions HelloWorld (or java -ea HelloWorld) will run HelloWorld with assertions enabled while java -disableassertions HelloWorld will run it without verifying assertions.

Java disables assertions by default. This could create a situation where you think all assertions are being verified as true while in fact they are not being verified at all. Therefore, remember to enable assertions when you run the program if you want them to be in effect.

Enable assertions in Intellij (how?) and get an assertion to fail temporarily (e.g. insert an assert false into the code temporarily) to confirm assertions are being verified.

Java assert vs JUnit assertions: They are similar in purpose but JUnit assertions are more powerful and customized for testing. In addition, JUnit assertions are not disabled by default. We recommend you use JUnit assertions in test code and Java assert in functional code.

Tutorials:

Java Assertions -- a simple tutorial from javatpoint.com
Programming with Assertions (first half) -- a more detailed tutorial from Oracle

Best practices:

Programming with Assertions (second half) -- from Oracle (also listed above as a tutorial) contains some best practices towards the end of the article.

W8.4e Implementation → Error Handling → Assertions → When

Can use assertions optimally

It is recommended that assertions be used liberally in the code. Their impact on performance is considered low and worth the additional safety they provide.

Do not use assertions to do work because assertions can be disabled. If not, your program will stop working when assertions are not enabled.

The code below will not invoke the writeFile() method when assertions are disabled. If that method is performing some work that is necessary for your program, your program will not work correctly when assertions are disabled.

...
assert writeFile() : "File writing is supposed to return true";

Assertions are suitable for verifying assumptions about Internal Invariants, Control-Flow Invariants, Preconditions, Postconditions, and Class Invariants. Refer to [Programming with Assertions (second half)] to learn more.

Exceptions and assertions are two complementary ways of handling errors in software but they serve different purposes. Therefore, both assertions and exceptions should be used in code.

The raising of an exception indicates an unusual condition created by the user (e.g. user inputs an unacceptable input) or the environment (e.g., a file needed for the program is missing).
An assertion failure indicates the programmer made a mistake in the code (e.g., a null value is returned from a method that is not supposed to return null under any circumstances).

A Calculator program crashes with an ‘assertion failure’ message when you try to find the square root of a negative number.

a. This is a correct use of assertions.
b. The application should have terminated with an exception instead.
c. The program has a bug.
d. All statements above are incorrect.

(c)

Explanation: An assertion failure indicates a bug in the code. (b) is not acceptable because of the word "terminated". The application should not fail at all for this input. But it could have used an exception to handle the situation internally.

Which statements are correct?

a. Use assertions to indicate the programmer messed up; Use exceptions to indicate the user or the environment messed up.
b. Use exceptions to indicate the programmer messed up; Use assertions to indicate the user or the environment messed up.

(a)

Week 8 [Oct 7]

[W8.1] Design: Models

W8.1a Design → Modelling → Introduction → What

What

W8.1b Design → Modelling → Introduction → How

[W8.2] Structure Diagrams

Revisiting: Class/Ojbect Diagrams - Basics

W8.2a Design → Modelling → Modelling Structure → OO Structures

W8.2b Design → Modelling → Modelling Structure → Class Diagrams (Basics)

W8.2c Design → Modelling → Modelling Structure → Object Diagrams

W8.2d Tools → UML → Object vs Class Diagrams

UML: Class Diagrams - Intermediate

W8.2e Tools → UML → Notes

W8.2f Tools → UML → Constraints

W8.2g Tools → UML → Class Diagrams → Associations as Attributes

W8.2h Design → Modelling → Modelling Structure → Class Diagrams - Intermediate

Modeling inheritance

Modeling composition

Modeling aggregation

Modeling dependencies

Modeling enumerations

Modeling abstract classes

Modeling interfaces

UML: Association Classes

W8.2i Paradigms → OOP → Associations → Association Classes

Implementing association classes

[W8.3] Behavior Diagrams

UML: Sequence Diagrams - Basics

W8.3a Design → Modelling → Modelling Behaviors Sequence Diagrams - Basic

UML: Sequence Diagrams - Intermediate

W8.3b Design → Modelling → Modelling Behaviors Sequence Diagrams - Intermediate

W8.3c Tools → UML → Sequence Diagrams → Reference Frames

W8.3d Tools → UML → Sequence Diagrams → Parallel Paths

[W8.4] Error Handling

Logging

W8.4a Implementation → Error Handling → Logging → What

W8.4b Implementation → Error Handling → Logging → How

Assertions

W8.4c Implementation → Error Handling → Assertions → What

W8.4d Implementation → Error Handling → Assertions → How

W8.4e Implementation → Error Handling → Assertions → When

[W8.5] Product design guidelines