Software Development

Software Development Life Cycle (SDLC) Stages

Requirements Analysis → Design → Implementation → Testing → Evolution

Software Development Methodologies

Waterfall, Prototyping, Agile, Rapid Application Development

Waterfall

Distinct Sequential Phases, each stage needing to be finished before moving on. Leads to well documented projects, but errors propagate easily.

Prototyping

Way of tackling larger stages of other methodologies. Lower function prototypes used to test ideas and get feedback. Can lead to complete shifts.

Rapid Application Development

Heavy focus on tools to reduce costs and time (IDEs, GUI builders, DBMS). Planning and implementation steps intertwines. Deadline is prioritised over requirements.

Agile

Development centred on short sprints. Allows client engagement, rapid development, early bug catching.

Pair Programming Roles

Driver (Coder) and Navigator

When to use Nested Classes

These are classes within classes. When you have two tightly couples classes that rely heavily on each other as it is a lot of work to create functions to access the members. Occurs frequently in GUI programming.

Static Nested Class

Does not have access to instance members. Outer class must be public (or package private by default).

Inner Class

Does not have access to instance members. Outer class must be public (or package private by default).

Local Class

Defined (and only exists) within a block (usually a method). Cannot have access modifiers. Cannot access local variables (unless they are *final* or passed as arguments). Can access all members of outer class.

Anonymous Classes

Declared with no class name. Can be defined within a method, and argument of a method.

Concurrency

Allows multiple processes to be run at the same time (parallelism).

\

Threads

A lightweight process within a process. Multiple threads can be run at once, virtually (on single processor) or physically (on multi-core processor).

Liveness

The concern that code is performed correctly, in time.

Creating Threads in Java

In two ways: Using (and extending) *Thread* class, or using *runnable* interface.

Java stopping a thread

Setting a flag - Loop will exit (and thread will stop) on the next iteration after done is set to true

or Interrupting - when isInterrupted() is called for this thread, it will stop unless the thread is sleeping/waiting.

Race conditions

Data synchronisation between threads causes issues. When the threads try to change data at the same time its a race condition.

Synchronisation

Add *synchronized* keyword to methods. When one thread is executing, other threads suspend execution until first thread is done with the object.

Atomic actions

Self contained and cannot be stopped when running. Either happen or do not happen. ¨ Reads and writes are atomic for all variables declared volatile, reads and writes are atomic for most primitive variables (all types except long and double).

Starvation

When a thread can’t gain regular access to shared resources as another thread is using it.

Livelock

Similar to deadlock, but both threads are too busy responding to each other to do work.

void wait();

waits for a condition to occur, must call from synchronised method/block.

Releases the lock and regains it using notify()

void wait(long timeStep);

waits for a condition for *timeStep* milliseconds, then returns, must call from synchronised method/block

void notify();

notifies a waiting thread a condition has occurred, must call from synchronised method/block (also void notifyAll();)

allows thread communication

Version control

Records changes over time, recall specific versions later. Allows a project wide undo button. Allows support of multiple releases. Records responsibility for changes. Changes aren’t lost when overwritten.

What should we store in version control?

EVERYTHING needed if local machines died.

Centralised vs distributed repositories

As soon as you commit to a centralised repository others can see your changes whereas Developers must push changes and pull updates from distributed repositories.

Strict locking (version control)

Only one person can change a file at any one time

Optimistic locking (version control)

All files can be changed but of any changes have occurred since last pull then you must address the changes before committing.

Version control and binary files

These are marked as non-mergable automatically, and manual merging must occur

What is polling

“while the event hasn’t happened, keep checking…”. Easy to implement but very wasteful.

Events

OS will notify program when event happens. More complex but better use of resources. Very useful in GUIs

Events in Java

Use delegation model with Sources, Events and Listeners.

Source (events)

Object that generates an event, typically in response to some change in state. Must register listeners to be notified of an event.

Listener (events)

An object that is notified of an event occurring. Must be registered and have methods to deal with notifications.

Event

an object that contains information about a state change in a source

Java event framework

Consists of two concrete classes, one abstract class (java.util.EventObject) and one interface (java.util.EventListener).

Listeners

Has a different method for each type of event notification.

These notifications are grouped together into categories represented by an event listener interface (extending java.util.EventListener) *EventCategoryNameListener.* These relate to a single event class typically.

To be notified of events, a class must implement a listener interface.

event notification method

public void specificEvent (EventCategoryNameEvent e)

State Object

n All states related to an event should be captured in this object when the event occurs. The class of this object must be a subclass of *java.util.EventObject*, as a minimum it must record which object was the source of the event.

\
By convention this call is named EventCategoryNameEvent e ¨ E.g., ActionEvent e, KeyEvent e, ScannedRobotEvent e

Concept of operations

A statement of goals and objectives of a system. Includes strategies, tactics, policies and constraints. Clear statement of responsibilities of those involved. Specifies how to develop, maintain and retire system.

Requirements analysis

Gathering requirements, analysing them, and documenting them

High-level design

Describes platforms, systems etc that the developed system will depend on. Typically has an architecture diagram.

Detailed design

Specifies how system will be constructed, e.g., what functions/objects/methods should be. You should be able to create tests off of this.

Integration testing

Testing after grouping together components.

Types of testing

Unit, Integration, System, User acceptance

System testing

Testing the entire system and ensuring it does not impair performance of wider environment

User acceptance testing

Performed in a user environment resembling production, using realistic data. Ensures delivered system meets user’s requirements and is ready for use. Validation rather than verification.

V-model

Way of approaching development. Highly structured, but not suitable where requirements might change as difficult to go back and change functionality when in testing stage.

Static testing

Assessing documents (review, walkthroughs, …)

Dynamic testing

Testing that involves executing program code. Whit, grey and black box testing.

Types of code coverage

Function, statement, decision, predicate.

Corner cases

Like edge cases but where many variables are at extremes. Most tests are focussed on typical system use so miss these situations. These are hard to replicate, so modern code is often instrumented to track how they occurred.

Purpose of Unit Tests

It is hard to test if something works, so you only disprove it doesn’t work. Test underlying hypothesis of developer that code works as intended.

Benefits of Unit Tests

Reduces time spent on debugging. Helps communicate intended use, how code should perform.

Right-BICEP

Right – are the boundary results correct? (or “right”)

B – are all the boundary conditions correct?

I – can you check the inverse relationships?

C – can you cross-check the results using some other means?

E – can you force error conditions to occur?

P – are the performance characteristics within bounds?

Properties of good tests

ATRIP

Automatic, Thorough, Repeatable, Independent, Professional (high standard)

How do you test tests?

By introducing bugs, it should fail as expected.

Unit test process

1\. Set up all conditions needed for testing (create any required objects, allocate any needed resources, …)

2\. Call the method to be tested on the object

3\. Verify that the object/class to be tested functions as expected

4\. Clean up after itself

AssertEquals and Floating Points

Floating point values are not exact due to finite memory, so you should specify a tolerance.

*assertEquals (String msg, expected, actual, tolerance)*

Mock objects

Provide predictable placeholder objects that allow testing of methods as it can be difficult to otherwise test.

When should you use mock objects?

When the real object is: slow, non-deterministic, difficult to trigger, doesn’t exist yet, difficult to set up or uses a UI.

How to implement mock objects

1\. Use an interface to describe the object

2\. Implement the interface for production code

3\. Implement the interface in a mock object for unit testing

Test suites

Allow multiple test classes to run as a single batch.

Test-driven development

Can help you design your code better and see code from user perspective.

Invariants

Assertions about classes/objects that should not change e.g., bank account credits and debits match balance or measurements should be equal after conversions.

Design pattern

Meant to provide a general reusable solution to one type of problems during software development – they provide an architecture.

Creational Patterns

Object creation

Structural Patterns

Composition of classes and objects

Behavioral Patterns

interaction between objects

Factory Pattern

Defines an interface for creating an object, but lets subclasses decide which class to instantiate. It lets a class defer instantiation to subclasses.

\
Factory Pattern uses inheritance (extend a class and override a factory method) and gives you a complete object in one shot.

Abstract Factory Pattern

Provides an interface for creating families of related or dependent objects without specifying their concrete classes. Supports creation of different families. Supports creation of different families e.g., for different OS.

\
This uses composition (defines an abstract type for creating a family of products and lets subclasses decide how those products are produced) and returns a family of related classes.

Builder Pattern

Separates the construction of a complex object from its representation so that the same construction processes can create different representations. Allows variation of products internal representation.

How do Builder Patterns work?

**Builder** specifies interface for creating parts of the object.

**ConcreteBuilder** object creates and assembles parts that make up product through builder interface.

**Director** object takes responsibility for construction process of object but delegates actual creation and assembly to Builder.

**Product** represents complex object that is created by **ConcreteBuilder** object. Consists of multiple parts that are created separately by ConcreteBuilder.

Advantage and Use of Builder pattern

Encapsulates the way a complex object is constructed. Unlike one-step factories, allows objects to be constructed in a multistep/varying process. Hides the internal representation of the product from the client.

\
Useful when: “Considering that you order a drink (Coffee or Tea) in Costa Coffee. The waiter tells the builder I need a drink - large coffee with caramel flavour.”

Factory vs Abstract Factory vs Builder Patterns

\
* Factory pattern constructs a complete object in one shot
* Abstract Factory pattern returns a family of related classes
* Builder pattern constructs a complex object step by step

Singleton Pattern

Ensures that a class has only one instance, and provides a global point of access to it. e.g., window managers, file systems.

How to create a Singleton Pattern

Static member: Create a private static variable of the Singleton class. This is the only instance of Singleton class.

Private constructor: Create a private constructor for making sure an outer class can NOT instantiate object from the Singleton class.

Static public method: Create a global point of access to get a Singleton instance.

\
May be resource heavy so not always used.

Lazy vs eager instantiation

Eager - Creates instance at time of class loading

Lazy - Instance is not created until getInstance() is called for first time.

Decorator Pattern

Attaches additional behavioural responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

You can use one or more decorators to wrap an object

The Command Pattern

Encapsulates a request as an object to let you use objects as parameters with different requests. Used widely in GUI design.

e.g., Client sets up a remote control so a light activator (receiver) is bound to a particular ConcreteCommand (button).

Invoker then interacts with the button and the resulting behaviour is determined by the client.

Invoker (Command Pattern)

Holds a command and asks the Command to carry out request by calling execute() method

Command (command pattern)

Declares interface for all commands (allows concrete implementers to be interchangeable)

ConcreteCommand (command pattern)

Defines binding between action and receiver. Once bound the invoker can make a request of the command object (*execute()*) resulting in ConcereteCommand calling one or more actions on the receiver.

Receiver (concrete classes)

Preforms the work required to carry out the request. Any class can be a receiver.

Client (command pattern)

Instantiates the *ConcreteCommand* and sets its *Receiver*.

Pattern Overview

OOP and Patterns

Encapsulate what varies.

Program to an interface, not an implementation.

Favour ‘object composition’ over class inheritance.

Classes should be open for extension, but closed for modification.

Depend on abstractions, not concrete classes.

Java generics

Facilitate generic programming style that allows algorithms to be written for different types and specified later.

Uses **Type parameters** to provide a way to re-use code with different inputs.

Advantages of Java Generics

Leads to safer code, as bugs that appear at runtime can be detected at compile time.

Common type parameter names

E - element

K - key

N - number

T - type

V - value

S, U, V - 2nd, 3rd, 4th types

Three Types of Generics

Generic types, generic methods, generic constructors

Bounded types

Writing a class/methods to operate with generic types but exhibiting certain properties.

Upper bound = *extends*

Lower Bound = *super*

\
e.g., *Public void genericMethod(S input)* means to legally compile, the *genericMethod* argument must be a Number or a subtype of it

Type erasure

Ensures backwards compatibility, as generics were added late. Compiler removes type information from parameters and arguments within generic classes/methods.

\
e.g., Use *generic class Spoon* to create *Spoon*

This is converted into type *Spoon* (raw type - generic class name minus type argument).

Heap Pollution

The situation in which a variable of a declared parametrised type refers to an instance not of the type.

Collections

An object that groups multiple elements into a single unit. Can be iterated over using *for-each*, although needs an *Iterator* object to remove elements.

e.g., poker hand = collection of cards

Collection vs Map

Collection - A group o objects known as elements - *public interface Collection*

Map - a group of objects where each object maps keys to values - *public interface Map

Set interface

Contains no duplicate elements. If two of these contain the same elements then they are treated equally.