Notes Application

A note-taking application is a standalone application designed for recording and searching short, ad-hoc notes. Typically they are used by people as an informal way of organizing information for their own consumption e.g. code snippets, recipes, daily journal notes.

Although there are many different designs, the focus of every note-taking application is storing and managing text notes. Common features include adding, editing, deleting notes, as well as ways to organize or search them.

Example: Apple Notes.

There are even command-line applications which attempt to solve the same issue. For example, here’s Terminal Velocity on Linux, optimized for very quick note entry, for users who are accustomed to working from a terminal.

Required Features

There are four specific deliverables for this project:

• Core infrastructure
• Console application
• GUI application
• Web service

Core Infrastructure

• Your source code should be stored in your team’s GitLab repository.
• You must use issues in GitLab to track your work.
• You must use a Gradle project, with the project structure provided in-class.
• You are expected to write unit tests for all of your code, and add appropriate code comments.
• You are also expected to produce some form of installer, so that a user (or TA) could install and run your application without needing to build it from source!
• We will examine your source code! You should strive for well-structured and readable code.

Console Application

Your first application should be a console application that launches the notes application. You can add support for additional arguments if you wish.

Usage: notes

GUI Application

Your main application is a desktop application. You are expected to implement the following standard desktop functionality:

• A top-level menu bar that lists major functions, and indicates the hotkeys for each feature (e.g. File, Edit, View menu and submenus).
• Toolbars that let the user control settings and modes that apply to the application e.g. a Bold button that can be used to embolden text, and reflects the state of selected text.
• Window resizing, so that the user can resize and reposition the application. You should save the window size and position on exit, and restore that size and position when they relaunch it.
• Minimize/mazimize buttons function as expected.
• Undo-redo support for actions in the user interface.
• Cut-copy-paste text.

In addition to the platform requirements, you should support the following features:

• Create, edit, delete a note (using both keyboard and point-click).
• Group related notes together e.g. folders or tags. Support add/delete and rename groups, and move notes between groups.
• Display a list of notes by title, and allow sorting the list by title, modified date or created date.
• Search notes, either by title or body contents, and display the matching notes.
• Rich text support for the note body, including bold, italics, underlining and changing colour of text.
• Support for bulleted lists, including the ability to apply or remove bullets from a block of selected text.
• Save local application settings (e.g. window size and position) on the local system where the application is installed.
• Note data should be stored remotely and shared across application instances.
• Your application should work equally well on Windows, Linux or macOS.

Service

You will need to build a web service so your main data can be served remotely.

• A user should be able to launch multiple instances of the application, and have the instances load and use this remote data.
• Your application should communicate with the web service using HTTP protocol.
• Data should be saved so that if the web service is stopped and restarted, the data will persist.

Additional Features

The requirements above represent the minimal set of requirements for this project. Here we’ve listed some other ideas that might be interesting to implement! Pick-and-choose, or brainstorm your own.

• Image support, so that users can drag-drop images into a note, and resize them.
• Diagramming, so that the user can drag-drop and manipulate simple shapes within a note e.g. box and arrow diagrams.
• Support light and dark themes. The user should be able to set their preference in a Settings dialog and this setting should persist.

Examples

Here’s an incomplete list of similar applications. Use these to get a sense of what features you might want to consider, or some design approaches.

• Apple Notes: https://support.apple.com/en-ca/guide/notes/welcome/mac
• Bear: https://bear.app
• Evernote: https://evernote.com
• FSNotes: https://fsnot.es
• Google KeepL https://keep.google.com
• Joplin: https://joplinapp.org
• Notion: https://www.notion.so/product
• OneNote: https://www.onenote.com

Markdown Editor

You will create a Markdown editor: a text editor with features that support that markup language, including syntax highlighting, headings, and bulleted lists.

Here’s a screenshot of Typora, my preferred editor.

Required Features

There are four specific deliverables for this project:

• Core infrastructure
• Console application
• GUI application
• Web service

Core Infrastructure

• Your source code should be stored in your team’s GitLab repository.
• You must use issues in GitLab to track your work.
• You must use a Gradle project, with the project structure provided in-class.
• You are expected to write unit tests for all of your code, and add appropriate code comments.
• You are also expected to produce some form of installer, so that a user (or TA) could install and run your application without needing to build it from source!
• We will examine your source code! You should strive for well-structured and readable code.

Console Launcher

Your first application should be a console application that can launch the markdown editor with the document indicated on the command line. For example:

Usage: mdown [filename]

GUI Application

Your main application is a desktop application. You are expected to implement the following standard desktop functionality:

• A top-level menu bar that lists major functions, and indicates the hotkeys for each feature (e.g. File, Edit, View menu and submenus).
• Hotkeys/keyboard shortcuts for major functionality.
• Window resizing, so that the user can resize and reposition the application. You should save the window size and position on exit, and restore that size and position when they relaunch it.
• Minimize/mazimize buttons function as expected.
• Undo-redo support for actions in the user interface.
• Cut-copy-paste text.

In addition to the platform requirements, you should support the following features:

• You should support basic Markdown syntax, including headings, bold, italics, and so on. This includes syntax highlighting for these elements, and hotkeys to apply formatting (e.g. CMD-B to bold selected text).
• Users should be able to open an existing markdown file (extensions .md or .markdown), close the current file, save or save-as with appropriate dialogs.
• It should be possible to have multiple markdown files open simultaneously (in different windows or different tabs).
• You should support light and dark themes, and the user should be able to set their preference in a Settings dialog. These settings should persist across sections and files.
• Provide two view modes: raw markdown syntax (as above), or formatted text. You could do this as two panes that exist side-by-side (e.g. VS Code, or MarkdownPad) or as a mode so that the user can switch between the two different views (Typora).
• Save application settings in the cloud so that they are preserved across sessions. See below.
• Your application should work equally well on Windows, Linux or macOS.

Service

You will need to build a web service so your data can be shared across multiple systems.

• A user should be able to launch multiple instances of the application, and have the instances load and use this remote data. You should determine what data is appropriate to save in this fashion.
• Your application should communicate with the web service using HTTP protocol.
• Data should be saved so that if the web service is stopped and restarted, the data will persist.

Additional Features

The requirements above represent the minimal set of requirements for this project. Here we’ve listed some other ideas that might be interesting to implement! Pick-and-choose, or brainstorm your own.

• Add themes! Dark, Light, Solarized etc.
• Stylize the toolbars e.g. a fancy VS Code style, expanding toolbar.
• Support editing both in raw markdown or formatted text (similar to Typora, where you can mode-switch but edit in either mode).
• Save files in the cloud, instead of just settings. [ed. this would likely mean the ability to import files, browse, and delete from the cloud as well].
• Open multiple files in tabs instead of windows.
• Export as HTML.
• Export as PDF.

Examples

• Dillinger (online). https://dillinger.io
• MarkdownPad (Windows). http://markdownpad.com
• Typora (macOS). https://www.typora.io
• VS Code (macOS, Windows. Linux). https://code.visualstudio.com/download

Diagram Editor

You will build a collaborative diagram editor, that allows people to build different types of diagrams together.

Here’s an example of draw.io, a drawing application that be used directly from their website, or as an installed application [ed. Note that draw.io supports more shapes than you would be expected to support in your project].

Required Features

There are four specific deliverables for this project:

• Core infrastructure
• Console application
• GUI application
• Web service

Core Infrastructure

• Your source code should be stored in your team’s GitLab repository.
• You must use issues in GitLab to track your work.
• You must use a Gradle project, with the project structure provided in-class.
• You are expected to write unit tests for all of your code, and add appropriate code comments.
• You are also expected to produce some form of installer, so that a user (or TA) could install and run your application without needing to build it from source!
• We will examine your source code! You should strive for well-structured and readable code.

Console Launcher

Your first application should be a console application which can launch the diagram editor with the document indicated on the command line.

Usage: diagram [filename]

GUI Application

Your main application is a desktop application. You are expected to implement the following standard desktop functionality:

• A top-level menu bar that lists major functions, and indicates the hotkeys for each feature (e.g. File, Edit, View menu and submenus).
• Hotkeys/keyboard shortcuts for major functionality.
• Window resizing, so that the user can resize and reposition the application. You should save the window size and position on exit, and restore that size and position when they relaunch it.
• Minimize/mazimize buttons function as expected.
• Undo-redo support for actions in the user interface.
• Cut-copy-paste text.

In addition to the platform requirements, you should support the following features:

• Allow creation of different types of diagrams, including simple UML diagrams (e.g. class diagrams), flowcharts or other box diagrams.
• Users can add/remove/edit shapes; shapes should be selectable, movable and resizable.
• Visual properties of shapes can be modified (e.g. border width, colour).
• Intuitive hotkeys that handle mode-switching well.
• Support saving, loading the diagram from a file (using a format that you create).
• Additionally, save local application data (for window size and position).
• Save application settings in the cloud so that they are preserved across sessions. See below.
• Your application should work equally well on Windows, Linux or macOS.

Service

You will need to build a web service so that shared data can be served remotely.

• A user should be able to launch multiple instances of the application, and have the instances load and use remote data.
• Your application should communicate with the web service using HTTP protocol.
• Data should be saved so that if the web service is stopped and restarted, the data will persist.

Additional Features

The requirements above represent the minimal set of requirements for this project. Here we’ve listed some other ideas that might be interesting to implement! Pick-and-choose, or brainstorm your own.

• Connectors snap-to the shapes, so that you can connect them, move them and the connections follow.
• Add different types of diagrams e.g. floorplans.
• Allow users to build their own templates and populate these with shapes.
• Support full collaborative editing, so that users can edit a diagram together.
• Save files in the cloud, instead of just settings. [ed. this would likely mean the ability to import files, browse, and delete from the cloud as well].

Examples

• Draw.io. https://app.diagrams.net/
• Omnigraffle. https://www.omnigroup.com/omnigraffle/
• Lucidchart. https://www.lucidchart.com
• Visual Paradigm. https://www.visual-paradigm.com

Whiteboard

You will design and build a digital whiteboard - similar to something that we would have in a classroom, but meant to be used to collaborate online! The whiteboard is initially a large blank canvas; users can write on it, sketch simple diagrams, or even insert images. Multiple people can connect to the whiteboard from different systems and collaborate together in real-time!

Example: FigJam

Required Features

There are four specific deliverables for this project:

• Core infrastructure
• GUI application
• Web service

Core Infrastructure

• Your source code should be stored in your team’s GitLab repository.
• You must use issues in GitLab to track your work.
• You must use a Gradle project, with the project structure provided in-class.
• You are expected to write unit tests for all of your code, and add appropriate code comments.
• You are also expected to produce some form of installer, so that a user (or TA) could install and run your application without needing to build it from source!
• We will examine your source code! You should strive for well-structured and readable code.

Client Application

Your main application is a desktop application. You are expected to implement the following standard desktop functionality:

• A top-level menu bar that lists major functions, and indicates the hotkeys for each feature (e.g. File, Edit, View menu and submenus).
• Window resizing, so that the user can resize and reposition the application. You should save the window size and position on exit, and restore that size and position when they relaunch it.
• Minimize/mazimize buttons function as expected.

In addition to the platform requirements, you should support the following features:

• Multi-user login. You should prompt the user for username/password and use these to authenticate against your service.
• Changes made by one person should be shown in real-time on other user’s applications. (No “manual sync” required).
• Once logged in, the whiteboard will be loaded automatically.
• There are tools that support:
  • drawing (multiple pen styles and colours),
  • inserting text (multiple fonts, sizes and colours).
  • inserting shapes (rectangles, plus one or more additional shapes)
  • editing existing content
  • selecting and moving content around the whiteboard
  • erasing content
• Your application will need to save some local data (for window size and position). Other data should be saved on your remote service. See below.
• Your client application should work equally well on Windows, Linux or macOS.

Service

You will need to build a web service so your data can be shared across multiple systems.

• A user should be able to launch multiple instances of the application, and have the instances load and use this remote data. You should determine what data is appropriate to save in this fashion.
• Your application should communicate with the web service using HTTP protocol.
• Data should be saved so that if the web service is stopped and restarted, the data will persist.

Additional Features

The requirements above represent the minimal set of requirements for this project. Here we’ve listed some other ideas that might be interesting to implement! Pick-and-choose, or brainstorm your own.

• Add themes! Dark, Light, Solarized etc.
• Stylize the toolbars e.g. a fancy VS Code style, expanding toolbar.
• Allow users to save/restore different whiteboards so that they can save their progress. Data would need to be saved in the cloud.
• Add specialised tools e.g. class diagram templates, or arrows/boxes that people can use to draw more professional looking diagrams.
• Flag the annotations on the board with a username. Establish permissions based on username and limits editing each others content (e.g. a user could set a flag to make her image “read-only” and restrict others from erasing it).
• Export as an image or PDF.

Examples

• Miro: https://miro.com
• FigJam: https://www.figma.com/figjam
• Lucidspark: https://lucidspark.com

Software Architecture

Formally, Software architecture is the “fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution” [IEEE 1471-200].

Architecture can also be seen as a shared understanding how the system is structured. Martin Fowler (2003) attempts to pin down the term in a couple of different ways:

Definition 1: “Expert developers working on a project have a shared understanding of the system design. This shared understanding is called ‘architecture’ [and] includes how the system is divided into components and how the components interact through interfaces.”

Definition 2: “Architecture is the set of design decisions that must be made early in a project [and that we would like to get right]”.

Architecture is the also holistic analysis of a system, and how it’s parts relate to one another. Instead of examining requirements in isolation, we instead want to look at the consequences of the structure itself, including the qualities that emerge from this structure.

Architecture can be said to address the intersection of business goals, user goals and technical (system) qualities. The architect needs to determine how to deliver the functional requirements in a way that also addresses these qualities, and other potential business needs (e.g. cost). This may very well include making tradeoff decisions ahead of time. e.g. a user may want a system to return the results of a query in less than 5 seconds, but the cost of doing this might be prohibitively expensive!

The benefit to a careful architecture is that we have a more stable initial design that reflects our project concerns, while still allowing for adaptability, flexibility and other desireable qualities. We’ll discuss different qualities of a system below.

Imposing Structure

Architects need to be concerned with both the logical structure of systems, and the physical realization of that structure.

Modularity (Logical)

Modularity refers to the logical grouping of source code into related groups. This can be realized as namespaces (C++), packages (Java or Kotlin). Modularity is important because it helps reinforce a separation of concerns, and also encourages reuse of source code through modules.

When discussing modularity, we can identify two related concepts: cohesion, coupling.

Cohesion is a measure of how related the parts of a module are to one another. A good indication that the classes or other components belong in the same module is that there are few, if any, calls to source code outside of the module (and removing anything from the module would necessitate calls to it outside of the module).

Coupling refers to the calls that are made between components; they are said to be tightly coupled based on their dependency on one another for their functionality. Loosely coupled means that there is little coupling, or it could be avoided in practice; tight coupling suggests that the components probably belong in the same module, or perhaps even as part of a larger component.

When designing modules, we want high cohesion (where components in a module belong together) and low coupling between modules (meaning fewer dependencies). This increases the flexibility of our software, and makes it easier to achieve desireable characteristics e.g. scalability.

Components (Physical)

Modules are logical collections of related code. Components are the physical manifestation of a module². Components can represent a number of different abstractions, from a simple wrapper of related classes, to an entire layer of software that runs independently and communicates with external systems.

• Library. A simple wrapper is often called a library, which tends to run in the same memory address as the calling code and communicate via language function call mechanisms. Libraries are usually compile-time dependencies.
• Layers or subsystems. Groups of related code deployed together that may communicate with one another directly.
• Distributed service. A service tends to run in its own address space and communicates via low-level networking protocols like TCP/IP or higher-level formats like REST or message queues, forming stand-alone, deployable units. These are useful in in architectures like microservices.

Top-Level Partitioning

Partitioning is the decision on how we organize and group functionality (we use the term top-level partitioning, because this is the highest level of organization).

There are multiple approaches to how we group functionality.

• Technical partitioning: we group functionality according to technical capabilities. e.g. presentation or UI layer, business rules or domain layer and so on.
• Domain partitioning: we group functionality according to the domain area or area of interest. e.g. a payment processing module, a shopping cart module, a reporting module and so on.

So which is correct? Good question.

Technical partitioning tends to be used more often. If we’re concerned about reusability, it’s much easier to design a third party library that can be injected into an application if you provide technical capabilities, as compared to designing a domain-specific library.

For example, we have lots of UI frameworks that sit at the presentation layer, that can be used to build any sort of application regardless of domain. There are very few CatalogCheckout libraries, since any code produced to address that functionality is likely designed around the assumptions of that specific instance of that domain - and is unlikely to be reusable.

From here, developers subdivide components into classes, functions, or subcomponents. In general, class and function design is the shared responsibility of architects, tech leads, and developers.

Determining Components

So we know what components are, but how do we determine what components we need to create? Here’s a couple of common approaches, both of which assume that you’ve identified Use Cases (in your Requirements phase).

Actor/Actions: From your Use Cases, identify actors who perform activities, and the actions that they may perform. This is simply a technique for discovering the typical users of the system and what kinds of things they might do with the system. These actions represent activities that can be mapped directly to a corresponding software component.

Workflow: This approach looks at the key activities being performed, determines workflows and attempts to build components to address those specific activities.

Architectural Characteristics

Where the requirements phase is concerned about functional requirements, this phase is concerned about the non-functional requirements or “architectural characteristics” [Richards & Ford 2020]. These are all of the things that software must do that aren’t directly related to the functional requirements. This includes considerations of the technical environment, choice of programming languages, technical constraints and so on.

An architectural characteristic meets three criteria:

1. specifies a non-domain design consideration,
2. influences some structural aspect of design,
3. is critical or important to the success of the application.

Examples of an architectural characteristic include software performance, and data security. These tend to not be identified as functional requirements, but should be considered.

It’s important to identify only those concerns that are relevant to your project! Addressing one of these characteristics adds cost and complexity to your project:

“Applications could support a huge number of architecture characteristics…but shouldn’t. Support for each architecture characteristic adds complexity to the design. Thus, a critical job for architects lies in choosing the fewest architecture characteristics rather than the most possible”

– Richard & Ford. 2020. Fundamentals of Software Architecture

Here are some potential characteristics that are often considered [Richards & Ford 2020]:

Operational characteristics

These are often relevant for large-scale software systems with dedicated uptime, and typically a large number of concurrent users. e.g. Gmail, Facebook.

Structural characteristics

These include characteristics related to code structure and code quality and production concerns.

Cross-cutting characteristics

These don’t fit neatly into a category but are worth considering:

Identifying Characteristics

So how do you identify which characteristics are relevant? You should look at the functional requirement (and project goals if they apply) and determine if there are any characteristics that help address those needs.

For example:

Non-Functional Requirements

Once you’ve identified a characteristic that you should address, you need to document it as a non-functional requirement (NFR).

• Include details of how you will measure it (all NFTs need to be measurable)
• Document how you will verify that you have met the requirement.
• Include consideration of this NFT in your topology and design (below).
• Clearly communicate this as an undercutting requirement to your team.

Example of non-functional requirements that would be included in our product backlog:

• “The application should launch and restore all state in less than 5 seconds on our target platform. We will measure this by manually timing execution during integration testing”.
• “When the Save button is pressed, the entire state should be saved, and control returned to the user in less than 10 seconds. We will write unit tests to check the amount of time consumed by this action and ensure that it never exceeds this threadhold”.
• “User records in all cases should consume less than 100 Kb each on disk. We will design our data classes to address this, and write integration tests to verify that this is the case”.

Architectural Styles

An architectural style (or architectural pattern) is the overall structure that we create to represent our software. In describes how our components are organized and structured. Similar to design patterns, an architectural style is a general solution that has been found to work well at solving specific types of problems. The key to using these is to understand the problem well enough that you can determine if a pattern is applicable, and useful to your particular situation.

An architectural pattern describes both the topology (organization of components) and the associated architectural characteristics.

Fundamental Patterns

There are some fundamental patterns that have appeared through history.

Big Ball of Mud

Architects refer to the absence of any discernible architecture structure as a Big Ball of Mud.

A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. – Foote& Yoder 1997.

A Big Ball of Mud isn’t intentional - it’s what happens when you fail to consider architecture in a software project. Treat this as an anti-pattern.

Unitary (Monolithic)

A monolithic structure simply means an application that is designed to run on a single system, and not communicate with any other systems. Source code had very little structure, these systems generally worked in isolation, on data that was carefully fed to them.

However, one inviolatable rule is that systems increase in complexity and capabilities over time. As systems grow, software has to be more carefully structures and managed to continue to meet these requirements.

Client-Server

Client-server architectures were the first major break away from a monolithic architecture, and split processing into front-end and back-end pieces. This is also called a two-tier architecture. There are different ways to divide up the system into front-end and back-end. Examples include splitting between desktop application (front-end) and shared relational database (back-end), or web browser (front-end) and web server (back-end).

Three-tier architectures were also popular in the 1990s and 2000s, which would also include a middle business-logic tier:

In this particular example, the presentation tier handled the UI, the logic tier handled business logic or applicaiton logic, and the data tier managed persistance.

These tiers are commonly used in other architectures, and we’ll revisit them shortly.

Monolithic Architectures

Monolithic architectures consist of a single deployment unit. i.e. the application is self-contained and deployed to a single system. (It may still communicate with external entities, but these are separate systems).

Layered

A layered or n-tier architecture is a very common architectural style that organizes software into horizontal layers, where each layer represents some logical functionality.

There is some similarlty to client-server, though we don’t assume that these layers are split across physically distinct systems (which is why we describe them as logical layers and not physical tiers).

Standard layers in this style of architecture include:

• Presentation: UI layer that the user interacts with.

• Business Layer: the application logic, or “business rules”.

• Persistence Layer: describes how to manage and save application data.

• Database Layer: the underlying data store that actually stores the data.

The major characteristic of a layered architecture is that it enforces a clear separation of concerns between layers: the Presentation layer doesn’t know anything about the application state or logic, it just displays the information; the Business layer knows how to manipulate the data, but not how it is stored and so on. Each layer is considered to be closed to all of the other layers, and can only be communicated with through a specific interface.

The layered architecture makes an excellent starting point for many simple applications that have few external interactions. However, be careful to ensure that your layers are actually adding functionality to a request, otherwise they are just added overhead with no added value. Layered is well-suited for small simple applications, but may not scale well if you need to expand your application’s functionality across more than a single tier.

Pipeline

A pipeline (or pipes and filters) architecture is appropriate when we want to transform data in a sequential manner. It consists of pipes and filters, linked together in a specific fashion:

Pipes form the communication channel between filters. Each pipe is unidirectional, accepting input on one end, and producing output at the other end.

Filters are entities that perform operation on data that they are fed. Each filter performs a single operation, and they are stateless. There are different types of filters:

• Producer: The outbound starting point (also called a source).
• Transformer: Accepts input, optionally transforms it, and then forwards to a filter (this resembles a map operation).
• Tester: Accepts input, optionally transforms it based on the results of a test, and then forwards to a filter (this resembles a reduce operation).
• Consumer: The termination point, where the data can be saved, displayed etc.

These abstractions may appear familiar, as they are used in shell programming. It’s broadly applicable anytime you want to process data sequentially according to fixed rules.

Examples include: photo manipulation software, shells.

Microkernel

A microkernel architecture (also called plugin architecture) is a popular pattern that provides the ability to easily extend application logic to external, pluggable components. e.g. IntelliJ IDEA which uses application plugins to add functionality for new programming languages.

This architecture works by focusing the primary functionality into the core system, and providing extensibility through the plugin system. This allows the developer, for instance, to invoke functionality in a plugin when the plugin is present, using a defined interface that describes how to invoke it (without need to understand the underlying code).

An example would be a payment processing system, where the core system handles shopping and payment calculations, and behaviour specific to a payment vendor could be contained within a plugin (e.g. Visa plugin, AMEX plugin and so on).

One final note: interaction between other system components and plugins is done through the core system as a mediator. This reduces coupling of components and the plugins, and retains the flexibility of this architecture.

Examples of this architecture include web browsers (which support extensions), and IDEA (which support plugins for various programming languages).

Distributed Architectures

Distributed architectures assume multiple deployments across different systems. These deployments communicate over a network, or similar medium using a defined protocol.

This overhead leads to some unique challenges that are referred to collectively as the fallacies of distributed computing. This includes concerns with network reliability, latency, bandwith, security and so on - things that are non-issues with monolithic architectures³.

Services-Based

A services-based architecture splits functionality into small “portions of an application” (also called domain services) that are independent and separately deployed. This is demonstrated below with a separately deployed user interface, a separately deployed series of coarse-grained services, and a monolithic database. Each service is a separate monolithic application that provides services to the application, and they share a single monolithic database.

Each service provides coarse-grained domain functionality (i.e. operating at a relatively high level of abstraction) and addresses a particular business-need. e.g. a service might handle a customer checkout request to process an order.

Working at a coarse-grained level of abstraction like this means that these types of services can rely on regular ACID (atomicity, consistency, isolation, durability) database transactions to ensure data integrity. In other words, since the service is handling the logic of the entire operation, it can consolidate all of the steps in a single database transaction. If there is a failure of any kind, it can report the status to the customer and rollback the transaction.

e.g. a customer purchasing an items from your online storefront: the same service can handle updating the order details, adjusting available inventory and processing the payment.

Microservices

A microservices architecture arranges an application as a collection of loosely coupled services, using a lightweight protocol.

Some of the defining characteristics of microservices:

• Services are usually processes that communicate over a network.
• Services are organized around business capabilities i.e. they provide specialized, domain-specific services to applications (or other services).
• Service are not tied to any one programming language, platform or set of technologies.
• Services are small, decentralized, and independently deployable.

Each microservice is expected to operate independently, and contain all of the logic that it requires to perform its specialized task. Microservices are distributed, so that each can be deployed to a separate system or tier.

The advantage of microservices over services is that we have prioritized decoupling of components and maximized cohesion - each microservice has a specific role and no dependencies. This makes extending and scaling out new microservices trivial. However, the cost of this is performance – communication over the network is relatively slow compared to inter-process communication on the same system.

The driving philosophy of microservices is the notion of bounded context: each service models a domain or workflow. Thus, each service includes everything necessary to operate within the application, including classes, other subcomponents, and database schemas. – Mark Richards

Although the services themselves are independent, they need to be able to call one another to fulfil business requirements. e.g. a customer attempting to checkout online may have thier order sent to a Shipping service to organize the details of the shipment, but then a request would need to be sent from the Shipping service to the Payment service to actually process the payment.

This suggests that communication between microservices is a key requirement. The architect utilizing this architecture would typically define a standard communication protocol e.g. message queues, or REST.

Coordinating a multi-step process like this involves either cooperation between services (as described above), or a third coordinating service.

Coordination in Microservices [Richards 2020].

Orchestration in Microservices [Richards 2020].

Which style to choose?

Software Design

The term “software design” is heavily overloaded, with many different interpretations of what it entails.

• A UX designer will treat design as the process of working with users to identify requirements, and iterating on the interaction and experience design with them to fine tune how they want the experience to work.
• A software engineer will want to consider ways of designing modules and source code that emphasize desireable characteristics like scalability, reliability and performance.
• A software developer may want to consider readability of the code, and compatibility with existing code bases (among other things).

In this course, we’ll treat design as the complete set of low-level implementation decisions that are made prior to coding a system. We’ll discuss some different approaches to design that have been impactful and useful.

Features of Good Design

It doesn’t take a huge amount of knowledge and skill to get a program working. Kids in high school do it all the time… The code they produce may not be pretty; but it works. It works because getting something to work once just isn’t that hard.

Getting software right is hard. When software is done right, it requires a fraction of the human resources to create and maintain. Changes are simple and rapid. Defects are few and far between. Effort is minimized, and functionality and flexibility are maximized.

– Bob Martin, Clean Architecture (2016).

One recurring theme keep cropping up: the notion that software should be enduring. Software that you produce should be able to function for a long period of time, in a changing environment, where adjustments will need to be made over time; defects will be found and fixed; new features will be introduced and old features phased out.

As “Uncle Bob” points out, It’s relatively easy to get something to compile and work once, in a restricted environment; it’s much more difficult to build something that can be extended and modified over time. If you want software that can be useful for a long time, you need to design for that as well.

Of course, first and foremost, we want to design software that performs its intended function, but we also want robust software that is a joy to extend and maintain. Let’s talk about the characteristics of “good” software that support this approach.

Code Reuse

Software is expensive and time-consuming to produce, so anything that reduces cost or time is welcome. Reusability, or code reuse is often positioned as the easiest way to accomplish this. It also reduces defects, since you’re presumably reusing code that is tested and known-good.

“I see three levels of reuse.

At the lowest level, you reuse classes: class libraries, containers, maybe some class “teams” like container/iterator.

Frameworks are at the highest level. They really try to distill your design decisions. They identify the key abstractions for solving a problem, represent them by classes and define relationships between them. JUnit is a small framework, for example. It is the “Hello, world” of frameworks. It has Test, TestCase, TestSuite and relationships defined.

A framework is typically larger-grained than just a single class. Also, you hook into frameworks by subclassing somewhere. They use the so-called Hollywood principle of “don’t call us, we’ll call you.” The framework lets you define your custom behavior, and it will call you when it’s your turn to do something. Same with JUnit, right? It calls you when it wants to execute a test for you, but the rest happens in the framework.

There also is a middle level. This is where I see patterns. Design patterns are both smaller and more abstract than frameworks. They’re really a description about how a couple of classes can relate to and interact with ”

– Shvets citing Erich Gamma: https://refactoring.guru/gamma-interview.

One of the reasons that we like design patterns is that they’re a different type of reuse: instead of reusing the software directly, we’re reusing designs in a way that results in better code. We’ll discuss these in detail below.

Extensibility

Extensibility implies the ability to modify your code, to expand existing features or add new features. e.g. an image editor adding support for a new image type; a plain text editor adding support for code fences and syntax highlighting. Conditions will change over the lifetime of your software, and you need to design in a way that allows you to respond to changes.

In the sections below, we will discuss different approaches to handling these challenges.

Readability

We’re programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We’re not excited by incremental renovation: tinkering, improving, planting flower beds.

There’s a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:

It’s harder to read code than to write it. —Joel Spolsky, Things You Should Never Do, Part I (2000)

It’s very likely that the software that you write will need to be read by someone else: your teammates, the people that follow you on a project, maybe even hundreds or thousands of other developers if you relase it publically.

For that reason, it’s not enough to have code that works; it should work, and be clear and understandable to other people that will need to read it. Keep in mind that the “other people” may include future-you. Will your code still make sense if you have to come back to it a year from now? Five years from now? Code comments (that describe why you made your design decisions), and consistent code structure go a long way to making code readable.

Design Principles

What is good soft­ware design? How would you mea­sure it? What prac­tices would you need to fol­low to achieve it? How can you make your archi­tec­ture flex­i­ble, sta­ble and easy to under­stand?

These are the great ques­tions; but, unfor­tu­nate­ly, the answers are dif­fer­ent depend­ing on the type of appli­ca­tion you’re build­ing.

– Shvets, Dive Into Design Patterns (2020).

We do have some universal principles that we can apply to any situation.

Encapsulate What Varies

The main goal of this prin­ci­ple is to min­i­mize the effect caused by changes.

You can do this by encapsulating classes, or functions. In both cases, your goal is separate and isolate the code that is likely to change from the rest of your code. This minimizes what you need to change over time.

The following example is taken from Shvets (and rewritten in non-idiomatic Kotlin).

fun getOrderTotal(order) {
  total = 0
  for (item in order.lineItems)
    total += item.price * item.quantity

  if (order.country == "US")
    total += total * 0.07 // US sales tax
  else if (order.country == "EU"):
    total += total * 0.20 // European VAT

  return total
}

Given that the tax rates will likely vary, we should isolate them into a separate function. This way, when the rates change, we have much less code to modify.

fun getOrderTotal(order) {
  total = 0
  foreach item in order.lineItems
    total += item.price * item.quantity

  total += total * getTaxRate(order.country)

  return total
}

fun getTaxRate(country) {
    return when (country) {
        "US" -> 0.07 // US sales tax
        "EU" -> 0.20 // European VAT
        else -> 0
    }
}

Similarly, we can split up classes into smaller independent units.

Restructured classes.

Program to an Interface, Not an Implementation

When classes rely on one another, you want to minimize the dependency - we say that you want loose coupling between the classes. This allows for maximum flexibility.

Do do this, you extract an abstract interface, and use that to describe the desired behaviour between the classes.

For example, in the diagram below, our cat on the left can eat sausage, but only sausage. The cat on the right can eat anything that provides nutrition, including sausage. The introduction of the food interface complicates the model, but provides much more flexibility to our classes.

Favor Composition over Inheritance

Inheritance is a useful tool for reusing code. In principle, it sounds great - derive from a base class, and you get all of it’s behaviour for free!

Unfortunately it’s rarely that simply. There are sometimes negative side effects of inheritance.

1. A subclass cannot reduce the interface of the base class. You have to implement all abstract methods, even if you don’t need them.
2. When overriding methods, you need to make sure that your new behaviour is compatible with the old behaviour. In other words, the derived class needs to act like the base class.
3. Inheritance breaks encapsulation, because the details of the parent class are potentially exposed to the derived class.
4. Subclasses are tightly coupled to superclasses. A change in the superclass can break subclasses.
5. Reusing code through inheritance can lead to parallel inheritance hierarchies, and an explosion of classes. See below for an example.

A useful alternative to inheritance is composition.

Where inheritance represents an is-a relationship (a car is a vehicle), composition represents a has-a relationship (a car has an engine).

Imagine a catalog application for cars and trucks.

Here’s the same application using composition. We can create unique classes representing each vehicle which just implement the appropriate interfaces, without the intervening abstract classes.

SOLID Principles

SOLID was introduced by Robert (“Uncle Bob”) Martin around 2002. Some ideas were inspired by other practitioners, but he was the first to codify them.

The SOLID Principles tell us how to arrange our functions and data structures into classes, and how those classes should be interconnected [ed. The use of the word “class” does not imply that these principles are applicable only to object-oriented software. A class is simply a coupled grouping of functions and data. Every software system has such groupings, whether they are called classes or not].

The goal of the principles is the creation of mid-level software structures that:

• Tolerate change (extensibility),
• Are easy to understand (readability), and
• Are the basis of components that can be used in many software systems (reusability).

The SOLID principles are are as follows. The diagrams and examples are from Ugonna Thelma’s Medium post “The S.O.L.I.D. Principles in Pictures”.

1. Single Resposibility

“A module should be responsible to one, and only one, user or stakeholder.” – Robert C. Martin (2002)

The Single Responsibility Principle (SRP) claims to result in code that is easier to maintain. The principle states that we want classes to do a single thing. This is meant to ensure that are classes are focused, but also to reduce pressure to expand or change that class. In other words.

• A class has responsibility over a single functionality.
• There is only one single reason for a class to change.

There should only be one “driver” of change for a module.

2. Open-Closed Principle

“A software artifact should be open for extension but closed for modification. In other words, the behavior of a software artifact ought to be extendible, without having to modify that artifact. “ – Bertrand Meyers (1988)

This principle champions subclassing as the primary form of code reuse.

• A particular module (or class) should be reusable without needing to change its implementation.
• Often used to justify class hierarchies (i.e. derive to specialize).

This principle is also warning against changing classes in a hierarchy, since any behaviour changes will also be inherited by that classes children! In other words, if you need different behaviour, create a new subclass and leave the existing classes alone.

3. Liskov-Substitution Principle

“If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behaviour of P is unchanged when o1 is substituted for o2, then S is a subtype of T”. -– Barbara Liskov (1988)

It should be possible to substitute a derived class for a base class, since the derived class should still be capable of all of the base class functionality. In other words, a child should always be able to substitute for its parent.

In the example below, if Sam can make coffee but Eden cannot, then you’ve modelled the wrong relationship between them.

4. Interface Substitution

It should be possible to change classes independently from the classes on which they depend.

Also described as “program to an interface, not an implementation”. This means focusing your design on what the code is doing, not how it does it. Never make assumptions about what the underlying code is doing – if you code to the interface, it allows flexibility, and the ability to substitute other valid implementations that meet the functional needs.

5. Dependency Inversion Principle

The most flexible systems are those in which source code dependencies refer to abstractions (interfaces) rather than concretions (implementations). This reduces the dependency between these two classes.

• High-level modules should not import anything from low-level modules. Both should depend on abstractions (e.g., interfaces).
• Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.

This is valuable because it reduces coupling between two classes, and allows for more effective reuse.

In the example below, the PizzaCutterBot should be able to cut with any tool (class) provided to it that meets the requirements of able-to-cut-pizza. This might include a pizza cutter, knife or any other sharp implement. PizzaCutterBot should be designed to worwk with the able-to-cut interface, not a specific tool.

UX & UCD

User Experience Design (UX)

User experience design (UX) is about designing for people first: building a well-organized, cohesive and compelling user experience. It focuses the design lens on the user-interface itself, and the role of user interaction in satisfying a customer’s expectations.

Building a consistent visual and behavioural experience provides a number of benefits¹.

• Users will learn your application faster if the user interface is familiar.
• User can accomplish their tasks more quickly, since the interface is consistent with other applications they’ve used.
• Users with special needs will find your product more accessible.
• Your application will be easier to document and explain.

Apple’s Human Interface Guidelines

Apple has published a series of Human Interface Design principles which characterize a compelling, useful and efficient user interface. First published with the MacIntosh in 1983, these have been refined over the years, but still reflect underlying design principles:

1. Metaphor. Take advantage of people’s knowledge of the world by using metaphors to convey concepts and features of your application. Use metaphors that represent concrete, familiar ideas, and make the metaphors obvious, so that users can apply a set of expectations to the computer environment. For example, graphicsl operating systems often use the metaphor of file folders for storing documents.
2. Reflect the User’s Mental Model. The user already has a mental model that describes the task your software is enabling. This model arises from a combination of real-world experiences, experience with other software, and with computers in general. For example, users have real-world experience writing and mailing letters and most users have used email applications to write and send email. An email application that ignores the user’s mental model and does not meet at least some of the user’s expectations would be difficult and even unpleasant to use.
3. Explicit and Implied Actions. Most operations involve the manipulation of an object using an action. In the first step of this manipulation, the user sees the desired object onscreen. In the second step, the user selects or designates that object. In the final step, the user performs an action, either using a menu command or by direct manipulation of the object with the mouse or other device. Explicit actions are obvious and clear from user actions (e.g. a menu command). Implied actions arise from interaction with objects (e.g. dragging a graphic into a window to import it). The user’s mental model and expectations should drive your choice of action.
4. Direct Manipulation. Direct manipulation is an example of an implied action that allows users to feel that they are controlling the objects represented by the computer. According to this principle, an onscreen object should remain visible while a user performs an action on it, and the impact of the action should be immediately visible. e.g. selecting text with the mouse; dragging a graphic between windows to move it.
5. User Control. Allow the user to initiate and control actions. Provide users with capabilities, but let them remain in control.
6. Feedback and Communication. Keep users informed about what’s happening by providing appropriate feedback and enabling communication with your application. Look for ways to communicate state!
7. Consistency. Consistency in the interface allows users to transfer their knowledge and skills from one application to another. Use the standard elements of the interface to ensure consistency within your application and to benefit from consistency across applications. When uncertain, look at what previous applications have done.
8. Modelessness. As much as possible, allow users to do whatever they want at all times. Avoid using modes that lock them into one operation and prevent them from working on anything else until that operation is completed.

User-Centred Design (UCD)

“I walk around the world and encounter new objects all the time. How do I know how to use them?” — Don Norman

In the mid 1980s, while on sabbatical at the Applied Psychology Unit at Cambridge University, Don Norman found himself puzzled by the light switches he encountered. Why light switches? As the story goes, the switches moved in the opposite direction to what he expected (“up” denoting “on” by North American convention, while at Cambridge they worked in the opposite direction ). This led him to consider the “perceived affordance” between user and item being used; the visual “hints” that suggest how something should be used. In other words, “how we [manage] in a world of tens of thousands of objects.”

These ponderings eventually led to the publication of his book, The Design of Everyday Things in 1988 [Norman 1988, 2013]. In this book, Norman presents case studies of objects we interact with everyday, from door handles to computers and phones. He shows what good and bad design look like across a wide spectrum of devices, inviting us to think about all the daily “user experiences” we take for granted. He wasn’t thinking about software explicitly, but his insights apply equally well to that domain.

For Norman, the two most important characteristics of good design are discoverability – the ability of a user to determine the purpose of an object – and understanding – figuring out how it works and how to use it. From Norman’s perspective, good design should make these characteristics obvious and intuitive.

Norman illustrates what he considers the fundamental principles of interaction:

• Affordances: cues that allow a person to figure out what an object does without any instructions. e.g. a door with a “pull” handle (formally called “perceived affordance”, which positions then as properties of the perceiver, as much as the object itself).
• Signifiers: visible signs or sounds that communicate meaning. They indicate what is happening, or what can be done. e.g. a door that says “push” on it.
• Mapping: the relationship between two sets of things that conveys associated meaning. e.g. grouping controls and putting them next to the thing that you want to manipulate.
• Feedback: the result of an action, communicated to a user. e.g. a button changing color when depressed; a walk indicator that lights up when the walk button is activated.
• Conceptual models: simplifed explanations of how something works; related to mental models that people automatically form when working with an object to help them explain and predict its behaviour.

“Good” design is about getting these characteristics “right” to reduce the friction between the user’s intention and the outcome of interacting with an object. In order for something to be useful, it needs to serve a clear purpose for some user, and it should be intuitive to use (in other words, designed using the principles he specified).

So how do we know when we have things “right”? We talk to users! We iterate on our designs, collect feedback and made revisions until we get the best design that we can. Norman’s insights kick-started a shift towards designing for users, and directly led to the emergence of UCD and modern UX.

User-Centered Design (UCD) is design process that was developed in parallel to the Agile models that we have discussed. It focuses on addressing the needs of users first, to ensure that we’re building a high-quality solution and solving the correct problem for our users. UCD uses a mixture of investigative tools (e.g. interviewing) and generative methods (e.g. brainstorming) to design systems based on user needs, and collect feedback through the process².

The first requirement for an exemplary user experience is to meet the exact needs of the customer, without fuss or bother.

Next comes simplicity and elegance that produce products that are a joy to own, a joy to use. True user experience goes far beyond giving customers what they say they want, or providing checklist features.

In order to achieve high-quality user experience in a company’s offerings there must be a seamless merging of the services of multiple disciplines, including engineering, marketing, graphical and industrial design, and interface design.

– Don Norman and Jakob Nielsen

UCD Principles

1. Understand and address the core problems. Ensuring that we solve the core, root issues, not just the problem as presented.
2. Be people-centred. We are designing software for people. A well-engineered solution that nobody uses is a failure.
3. Use an Activity-Centred Approach. Design must focus upon the entire activity under consideration, not just isolated components. Most complications result from the interdependencies of multiple parts.
4. Use Rapid Iterations of Prototyping and Testing. Continually test and refine our solution, and get feedback to ensure that it truly meets the needs of users.

UCD is frequently mistaken for UX (User Experience). They are related but not identical. User-Centred Design is the process of considering users through planning design and development of a product. It’s a set of steps and methods that we can use to ensure that we are designing for users. User Experience (UX) is the conceptualization of a user’s full experience with a product. It’s concerned with the users perceptions of the entire solution.

This course is primarily concerned with design and implementation, so we’ll utilize UCD in our design³.

Collecting Feedback with Prototypes

It’s possible that a large feature may take multiple iterations to complete. In cases like this, you may want to elicit feedback on the feature before completing it. We can do this by building a low-effort prototype which demonstrates some degree of functionality, without being complete.

A prototype is a mockup of a system, intended to demonstrate some functionality. A prototype is NOT an “early version” of release software, but an early demonstration of functionality intended to elicit feedback from users.

The value in a prototype is (a) that is represents a lower commitment (time, cost) than building the feature outright, and (b) because of this, can be discarded or modified as needed.

Prototypes make sense for high-effort features. For simple features that don’t require feedback, or ones that can be implemented in a single sprint, it may not be worth the effort.

Low-fidelity prototypes are simple, low-tech, and represent a minimal investment of time and effort. They are shown to users to elicit early feedback on layout, navigation and other high-level features. Low-fidelity prorotypes are often sketches on paper, or non-interactive wireframe diagrams.

High-fidelity prototypes represent a more significant effort and are intended to be close to the final product. They are suitable for demonstrating complex functionality. High-fidelity prototypes may include interactive screen mockups that demonstrate the expected interaction. Commercial products exist for this purpose e.g. balsamiq.

Popular wireframe and prototyping tools

• Balsamiq: wireframes only
• Figma: wireframes and interactive prototypes, encourages collaboration
• Miro: Multi-purpose collaboration tool, includes wireframes
• Sketch: wireframes and interactive prototypes.

Design Patterns

A design pattern is a generalizable solution to a common problem that we’re attempting to address. Design patterns in software development are one case of a formalized best practice, specifically around how to structure your code to address specific, recurring design problems in software development.

We include design patterns in a discussion of software development because this is where they tend to be applied: they’re more detailed that architecture styles, but more abstract than source code. Often you will find that when you are working through high-level design, and describing the problem to address, you will recognize a problem as similar to something else that you’ve encoutered. A design pattern is a way to formalize that idea of a common, reusable solution, and give you a standard terminology to use when discussing this design with your peers.

Patterns originated with Christopher Alexander, an architect, in 1977¹. Design patterns in software gained popularity with the book Design Patterns: Elements of Reusable Object-Oriented Software, published in 1994 [Gamma 1994]. There have been many books and articles published since then, and during the early 2000s there was a strong push to expand Design Patterns and promote their use.

Design patterns have seen mixed-success. Some criticisms levelled:

• They are not comprehensive, and do not reflect all styles of software or all problems encountered.
• They are old-fashioned and do not reflect current software practices.
• They add flexibility, at the cost of increased code complexity.

Broad criticisms are likely unfair. While it’s true that not all patterns are used, many of them are commonly used in professonal practice, and new patterns are being suggested. Design patterns certainly can add complexity to code, but they also encourage designs that help avoid subtle bugs later on.

In this section, we’ll outline the more common patterns, and indicate where they may be useful. The original set of patterns were subdivided based on the types of problems they addressed. We’ll examine a number of patterns in each category below: the original patterns are taken from Eric Gamma et al. 1994. Design Patterns: Elements of Reusable Object-Oriented Software. Examples and some explanations are from Alexander Shvets. 2019. Dive Into Design Patterns.

Creational Patterns

Creational Patterns control the dynamic creation of objects.

Example: Builder Pattern

Builder is a cre­ation­al design pat­tern that lets you con­struct com­plex objects step by step. The pat­tern allows you to pro­duce dif­fer­ent types and rep­re­sen­ta­tions of an object using the same con­struc­tion code.

Imagine that you have a class with a large number of variables that need to be specified when it is created. e.g. a house class, where you might have 15-20 different parameters to take into account, like style, floors, rooms, and so on. How would you model this?

You could create a single class to do this, but you would then need a huge constructor to take into account all of the different parameters.

• You would then need to either provide a long parameter list, or call other methods to help set it up after it was instantiated (in which case you have construction code scattered around).
• You could create subclasses, but then you have a potentially huge number of subclasses, some of which you may not actually use.

The builder pattern suggests that you put the object construction code into separate objects called builders. The pattern organizes construction into a series of steps. After calling the constructor, you call methods to invoke the steps in the correct order (and the object prevents calls until it is constructed). You only call the steps that you require, which are relevant to what you are building.

Even if you never utilize the Builder pattern directly, it’s used in a lot of complex Kotlin and Android libraries. e.g. the Alert dialogs in Android.

val dialog = AlertDialog.Builder(this)
	.setTitle("Title")
  .setIcon(R.mipmap.ic_launcher)
  .show()

Example: Singleton

Sin­gle­ton is a cre­ation­al design pat­tern that lets you ensure that a class has only one instance, while pro­vid­ing a glob­al access point to this instance.

Why is this pattern useful?

1. Ensure that a class has just a sin­gle instance. The most com­mon rea­son for this is to con­trol access to some shared resource—for exam­ple, a data­base or a file.
2. Pro­vide a glob­al access point to that instance. Just like a glob­al vari­able, the Sin­gle­ton pat­tern lets you access some object from any­where in the pro­gram. How­ev­er, it also pro­tects that instance from being over­writ­ten by other code.

All imple­men­ta­tions of the Sin­gle­ton have these two steps in common:

1. Make the default con­struc­tor pri­vate, to pre­vent other objects from using the new oper­a­tor with the Sin­gle­ton class.

2. Cre­ate a sta­t­ic cre­ation method that acts as a con­struc­tor.

In languages like Java, you would express the implementation in this way:

public class Singleton {

    private static Singleton instance = null;
    private Singleton() {
    }

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

In Kotlin, it’s significantly easier.

object Singleton{   
    init {
        println("Singleton class invoked.")
    }
    fun print(){
        println("Print method called")
    }
}

fun main(args: Array<String>) {     
    Singleton.print()
    // echos "Print method called" to the screen
}

The object keyword in Kotlin creates an instance of a generic class. i.e. it’s instantiated automatically. Like any other class, you can add properties and methods if you wish.

Singletons are useful for times when you want a single, easily accessible instance of a class. e.g. Database object to access your database, Configuration object to store runtime parameters and so on. You should also consider it instead of extensively using global variables.

Structural Patterns

Structural Patterns are about organizing classes to form new structures.

Example: Adapter

Adapter is a struc­tur­al design pat­tern that allows objects with incom­pat­i­ble inter­faces to collaborate.

Imagine that you have a data source that is in XML, but you want to use a charting library that only consumes JSON data. You could try and extend one of those libraries to work with a different type of data, but that’s risky and may not even be possible if it’s a third-party library.

An adapter is an intermediate component that converts from one interface to another. In this case, it could handle the complexities of converting data between formats. Here’s a great example from Shvets (2019):

The simplest way to implement this is using object com­po­si­tion: the adapter is a class that exposes an interface to the main application (client). The client makes calls using that interface, and the adapter performs necessary actions through the service (which is often a library, or something whose interface you cannot control).

1. The client is the class containing business logic (i.e. an application class that you control).
2. The client interface describes the interface that you have designed for your application to communicate with that class.
3. The service is some useful library or service (typically which is closed to you), which you want to leverage.
4. The adapter is the class that you create to serve as an intermediary between these interfaces.
5. The client application isn’t coupled to the adapter because it works through the client interface.

Behavioural Patterns

Behavioural Patterns are about identifying common communication patterns between objects.

Example: Command

Com­mand is a behav­ioural design pat­tern that turns a request into a stand-alone object that con­tains all infor­ma­tion about the request (a command could also be thought of as an action to perform).

Imagine that you are writing a user interface, and you want to support a common action like Save. You might invoke Save from the menu, or a toolbar, or a button. Where do you put the code that actually handles saving the data?

If you attach it to the object that the user is interacting with, then you risk duplicating the code. e.g.

The Command pattern suggests that you encapsulate the details of the command that you want executed into a separate request, which is then sent to the business logic layer of the application to process.

The command class relationship to other classes:

Example: Observer (MVC)

Observ­er is a behav­ioral design pat­tern that lets you define a sub­scrip­tion mech­a­nism to noti­fy mul­ti­ple objects about any events that hap­pen to the object they’re observing. This is also called publish-subscribe.

The object that has some inter­est­ing state is often called sub­ject, but since it’s also going to noti­fy other objects about the changes to its state, we’ll call it pub­lish­er. All other objects that want to track changes to the pub­lish­er’s state are called sub­scribers, or observers of the state of the publisher.

Subscribers register their interest in the subject, who adds them to an internal subscriber list. When something interest happens, the publisher notifies the subscribers through a provided interface.

The subscribers can then react to the changes.

A modified version of Observer is the Model-View-Controller (MVC) pattern, which puts a third intermediate layer between the Publisher and Subscriber, which manages user input. That layer is not required for this pattern.

For more details on MVC, see the Building Applications section.

UML

Architecture and design are all about making important, critical decisions early in the process. It’s extremely valuable to have a standard way of documenting systems, components, and interactions to aid in visualizing and communicating our designs.

The Unified Modelling Language (aka UML) is a modeling language consisting of an integrated set of diagrams, useful for designers and developers to specify, visualize, construct and communicate a design. UML is a notation that resulted from the unification of three competing modelling techniques¹:

1. Object Modeling Technique OMT [James Rumbaugh 1991] - was best for analysis and data-intensive information systems.
2. Booch [Grady Booch 1994] - was excellent for design and implementation. Grady Booch had worked extensively with the Ada language, and had been a major player in the development of Object Oriented techniques for the language. Although the Booch method was strong, the notation was less popular.
3. OOSE (Object-Oriented Software Engineering [Ivar Jacobson 1992]) - featured a model known as Use Cases.

All three designers joined Rational Software in the mid 90s, with the goal of standardizing this new method. Along with many industry partners, they drafted an intial proposal which was submitted to the Object Management Group in 1997. This led to a series of UML standards driven through this standards body, with UML 2.5 being the current version.

The primary goals of UML include:

• providing users with a common, expressive language that they can use to share models.

• provide mechanism to extend the language if needed.

• remain independent of any particular programming language or development process²

• support higher-level organizational concepts like frameworks, patterns.

UML contains a large number of diagrams, intended to address the needs to a wide range of stakeholders. e.g. analysis, desigers, coders, testers, customers.

UML contains both structure and behaviour diagrams.

Structure diagrams show the structure of the system and its parts at different level of abstraction, and shows how they are related to one another. Behaviour diagrams show the changes in the system over time.

These diagrams are intended to cover the full range of possible scenarios that we want to model. It’s common (and completely reasonable!) to only use the diagrams that you actually need. You will find, for instance, that component and class diagrams are commonly used when discussing component-level behaviour; package and deployment diagrams are used when determining how to install and execute your deliverable and so on.

Below we’ll highlight the most commonly used UML diagrams³. For more comprehensive coverage, see Visual Paradigm or Martin Fowler’s UML Distilled [Fowler 2004].

Structure Diagrams

These document the static components in a system.

Class Diagram

The class diagram is a central modeling technique that runs through nearly all object-oriented methods. This diagram describes the types of objects in the system and various kinds of static relationships which exist between them.

There are three principal kinds of relationships which are important to model:

1. Association - represent relationships between instances of types (a person works for a company, a company has a number of offices.
2. Inheritance - the most obvious addition to ER diagrams for use in OO. It has an immediate correspondence to inheritance in OO design.
3. Aggregation - Aggregation, a form of object composition in object-oriented design.

Component Diagram

A component diagram depicts how components are wired together to form larger components or software systems. It illustrates the architectures of the software components and the dependencies between them. Those software components including run-time components, executable components also the source code components.

Deployment Diagram

The Deployment Diagram helps to model the physical aspect of an Object-Oriented software system. It is a structure diagram which shows architecture of the system as deployment (distribution) of software artifacts to deployment targets. Artifacts represent concrete elements in the physical world that are the result of a development process. It models the run-time configuration in a static view and visualizes the distribution of artifacts in an application. In most cases, it involves modeling the hardware configurations together with the software components that lived on.

Behaviour Diagrams

These document behaviours of the system over time.

Use Case Diagram

A use-case model describes a system’s functional requirements in terms of use cases. It is a model of the system’s intended functionality (use cases) and its environment (actors). Use cases enable you to relate what you need from a system to how the system delivers on those needs. The use-case model is generally used in all phases of the development cycle by all team members and is extremely popular for that reason.

Activity Diagram

Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency. It describes the flow of control of the target system. Activity diagrams are intended to model both computational and organizational processes (i.e. workflows).

Interaction Overview Diagram

The Interaction Overview Diagram focuses on the overview of the flow of control of the interactions. It is a variant of the Activity Diagram where the nodes are the interactions or interaction occurrences. The Interaction Overview Diagram describes the interactions where messages and lifelines are hidden. You can link up the “real” diagrams and achieve high degree navigability between diagrams inside the Interaction Overview Diagram.

State Machine Diagram

A state diagram is a type of diagram used in UML to describe the behavior of systems which is based on the concept of state diagrams by David Harel. State diagrams depict the permitted states and transitions as well as the events that effect these transitions. It helps to visualize the entire lifecycle of objects and thus help to provide a better understanding of state-based systems.

Sequence Diagram

The Sequence Diagram models the collaboration of objects based on a time sequence. It shows how the objects interact with others in a particular scenario of a use case.

Pair Programming

Pair programming means that two people design and implement code together, on a single machine. This is a very collaborative way of working that involves a lot of communication and collaboration between them. While a pair of developers work on a task together, they do not only write code, they also plan and discuss their work. They clarify ideas on the way, discuss approaches and come to better solutions.

Originally an Extreme Programming practice, it is considered a best-practice today, used successfully on many programming teams.

Benefits

There are tangible benefits to pair programming - both to the organization and project team, and to the quality of the work produced.

For the organization:

• remove knowledge silos to increase team resiliency
• build collective code ownership
• help with team building
• accelerate on-boarding
• serve as a short feedback loop, similar to a code review happening live

For the team, and the developers:

• improve learning
• increase efficiency
• improve software design
• improve software quality
• reduce the incidence of bugs
• increase satisfaction
• increase safety and trust of the developers pairing
• increase developer confidence

Research supports the idea that a pair of programmers working together will produce higher quality software, in the same or less time as the developers working independently (Williams et al. 2000).

Surprising, research also suggests that there is no loss in productivity when pair programming. In other words, they produce at least the same amount of code as if they were working independntly, but it tends to be higher quality than if they worked alone.

Styles of Pairing

Styles adapted from https://martinfowler.com/articles/on-pair-programming.html#HowToPair

Driver and Navigator

This is the classic form of pair programming.

The Driver is the person at the wheel, i.e. the keyboard. She is focussed on completing the tiny goal at hand, ignoring larger issues for the moment. A driver should always talk through what she is doing while doing it.

The Navigator is in the observer position, while the driver is typing. She reviews the code on-the-go, gives directions and shares thoughts. The navigator also has an eye on the larger issues, bugs, and makes notes of potential next steps or obstacles.

Image from https://unruly.co/.

Remember that pair programming is a collaboration. A common flow goes like this:

• Start with a reasonably well-defined task. Pick a requirement or user story for example.
• Agree on one tiny goal at a time. This can be defined by a unit test, or by a commit message, or some goal that you’ve written down.
• Switch keyboard and roles regularly. Alternating roles keeps things exciting and fresh.
• As navigator, leave the details of the coding to the driver - your job is to take a step back and complement your pair’s more tactical mode with medium-term thinking. Park next steps, potential obstacles and ideas on sticky notes and discuss them after the tiny goal is done, so as not to interrupt the driver’s flow.

Ping-Pong

This technique is ideal when you have a clearly defined task that can be implemented in a test-driven way.

• “Ping”: Developer A writes a failing test
• “Pong”: Developer B writes the implementation to make it pass.
• Developer B then starts the next “Ping”, i.e. the next failing test.
• Each “Pong” can also be followed by refactoring the code together, before you move on to the next failing test.

Strong-Style Pairing

This is a technique particularly useful for knowledge transfer. In this style, the navigator is usually the person much more experienced with the setup or task at hand, while the driver is a novice (with the language, the tool, the codebase, …). The experienced person mostly stays in the navigator role and guides the novice.

An important aspect of this is the idea that the driver totally trusts the navigator and should be “comfortable with incomplete understanding”. Questions of “why”, and challenges to the solution should be discussed after the implementation session.

Switching Roles

Here’s some suggestions on role-switching from Shopify Engineering:

Switching roles while pairing is essential to the process—it’s also one of the trickiest things to do correctly. The navigator and driver have very different frames of reference.

The Wrong Way

Pairing is about working together. Anything that impedes one of the pairers from contributing or breaks their flow is bad. Two of the more obvious wrong ways are to “grab the keyboard” or “push the keyboard”.

Grabbing the keyboard: Sometimes when working as the navigator it’s tempting to take the keyboard control away to quickly do something. This puts the current driver in a bad position. Not only are they now not contributing, but such a forceful role change is likely to lead to conflict.

Pushing the keyboard: Other times, the driver feels a strong need to direct the strategy. It’s very tempting to just “push” the keyboard to the navigator, forcing them to take the driver’s seat, and start telling them what to do. This sudden context switch can be jarring and confusing to the unsuspecting navigator. It can lead to resentment and conflict as the navigator feels invalidated or ignored.

Finally, even a consensual role switch can be jarring and confusing if done too quickly and without structure.

The Right Way

The first step to switching roles is always to ask. The navigator needs to ask if they can grab the keyboard before doing so. The driver needs to ask if the navigator is willing to drive before starting to direct them. Sometimes, switching without asking works out but these situations are the exception.

It’s important to take some time when switching as well. Both pairers need to time to acclimatizing to their new roles. This time can be reduced somewhat by having a structure around switching (e.g. Ping-pong pairing) which allows the pairers to be mentally prepared for the switch to happen.

Pair Rotation

If a feature will take a long time, you might consider rotating people into and out of the pair over time (e.g. one person swaps out and a new person comes). You don’t want to do this frequently, no more than once per day over a full working day. It’s helpful to prevent the duo from become stale or frustrated with one another, and may help with knowledge transfer.

In a small team, with very short cycles, this may not be practical or necessary.

Setup for Pairing

Physical Setup

Ideally, you would work together in the same space. It is worth spending some time figuring out a comfortable setup for both of you.

• Make sure both of you have enough space, and that both of you can sit facing the computer.
• Agree on the computer setup (key bindings, IDE etc). Check if your partner has any particular preferences or needs (e.g. larger font size, higher contrast, …)
• It’s common to have a single keyboard, mouse for the driver, but some pairs setup with two keyboard - that’s your choice.

Remote Setup

If you’re working remotely, you may not be able to physically sit together. Luckily, there are practical solutions to pairing remotely. For remote pairing, you need a screen-sharing solution that allows you to not only see, but also control the other person’s machine, so that you are able to switch the keyboard.

There are also development tools that are designed to specifically address this:

• IntelliJ Code with Me

• Visual Studio Live Share

• Sharing over SSH and tmux

Challenges

The biggest challenges with pair programming are not code related, but issues with communication and understanding one another. Don’t be afraid to switch roles, or take breaks when required, and be patient with one another!

Post-Mortem

If possible, spend some time reflecting on the pairing session when its over. Ask yourself what went well, and what you can improve. This can be help clear the air of any tension or issues that came up during the session, and help you improve as a team.

TDD & Unit Testing

Test-Driven Development (TDD) is a strategy introduced by Kent Beck, which suggests writing tests first, before you start coding. You write tests against expected behaviour, and then write code which works without breaking the tests. TDD suggests this process:

1. Think about the function (or class) that you need to create.
2. Write tests that describe the behaviour of that function or class. As above, start with valid and invalid input.
3. Your test will fail (since the implementation code doesn’t exist yet). Write just enough code to make the tests pass.
4. Repeat until you can’t think of any more tests to write.

Running out of tests means that there is no more behaviour to implement… and you’re done, with the benefit of fully testable code.

Courtesy of https://medium.com/@tunkhine126/red-green-refactor-42b5b643b506

Why TDD?

There are some clear benefits:

• Early bug detection. You are building up a set of tests that can verify that your code works as expected.
• Better designs. Making your code testable often means improving your interfaces, having clean separation of concerns, and cohesive classes. Testable code is by necessity better code.
• Confidence to refactor. You can make changes to your code and be confident that the tests will tell you if you have made a mistake.
• Simplicity. Code that is built up over time this way tends to be simpler to maintain and modify.

What are unit tests?

A unit test is a test that meets the following three requirements [Khorikov 2020]:

1. Verifies a single unit of behavior,
2. Does it quickly, and
3. Does it in isolation from other tests.

Unit tests are just Kotlin functions that execute and check the results returned from other functions. Ideally, you would produce one unit or more unit tests for each function. You would then have a set of unit tests to check all of the methods in a class, and multiple sets of units tests to cover all of your implementation classes.

Your goal should be to have unit tests for every critical class and function that you produce¹.

Installing JUnit

We’re going to use JUnit, a popular testing framework² to create and execute our unit tests. It can be installed in number of ways: directly from the JUnit home page, or one of the many package managers for your platform.

We will rely on Gradle to install it for us as project dependency. If you look at the section of a build.gradle file below, you can see that JUnit is included, which means that Gradle will download, install and run it as required. IntelliJ projects will typically include Gradle by default.

dependencies {
  // Use the Kotlin test library.
  testImplementation org.jetbrains.kotlin:kotlin-test'

  // Use the Kotlin JUnit integration.
  testImplementation'org.jetbrains.kotlin:kotlin-test-junit'
}

How to write tests

A unit test is just a Kotlin class, with annotated methods that tell the compiler to treat the code as a test. It’s best practice to have one test class for each implementation class that you want to test. e.g. class Main has a test class MainTest. This test class would contain multiple methods, each representing a single unit test.

Tests should be placed in a special test folder in the Gradle directory structure. When building, Gradle will automatically execute any tests that are placed in this directory structure³.

Your unit tests should be structured to create instances of the classes that they want to test, and check the results of each function to confirm that they meet expected behaviour.

For example, here’s a unit test that checks that the Model class can add an Observer properly. The addObserver() method is the test (you can tell because it’s annotated with @Test). The @Before method runs before the test, to setup the environment. We could also have an @After method if needed to tear down any test structures.

class ObserverTests() {
    lateinit var model: Model
    lateinit var view: IView

    class MockView() : IView {
        override fun update() {
        }
    }

    @Before
    fun setup() {
        model = Model()
        view = MockView()
    }

    @Test
    fun addObserver() {
        val old = model.observers.count()
        model.addObserver(view)
        assertEquals(old+1, model.observers.count())
    }

Gradle will automatically execute and display the test results when you build your project.

Code coverage

Tests shouldn’t verify units of code. Rather, they should verify units of behaviour: something that is meaningful for the problem domain and, ideally, something that a business person can recognize as useful. The number of classes it takes to implement such a unit of behaviour is irrelevant. — Khorikov (2020)

Code coverage is a metric comparing the number of lines of code with the number of lines of code that have unit tests covering their execution. In other words, what “percentage” of your code is tested?

This is a misleading statistic at the best of times (we can easily contrive cases where code will never be executed or tested).

TDD would suggest that you should have 100% unit test coverage but this is impractical and not that valuable. You should focus instead on covering key functionality. e.g. domain objects, critical paths of your source code.

One recommendation is to look at the coverage tools in IntelliJ, which will tell you how your code is being executed, as well as what parts of your code are covered by unit tests. Use this to determine which parts of the code should be tested more completely.

https://www.jetbrains.com/help/idea/code-coverage.html

https://www.jetbrains.com/help/idea/running-test-with-coverage.html

https://xkcd.com/2200/

Code Reviews

What is the value of a code review? When to perform them? What feedback is useful? What to do with the feedback you’re given?

Refactoring

We all want to write perfect code, but given , we often end-up with less-than-perfect solutions.

• Rushed features: Sometimes we don’t have enough time, so we cut corners.

• Lack of tests: We might think that the code is ready, but we haven’t tested it adequately.

• Lack of communication: Perhaps we misunderstood requirements, or how a feature would integrate into the larger product.

• Poor design: Possibly our design is rigid and makes adding or modifying features difficult.

These are all actions that may cost us time later. We may need to stop and redesign a rushed feature, or we may need to fix bugs later.

We refer to this as technical debt — the deferred cost of doing something poorly.

What is refactoring?

Martin Fowler (2000) also introduced the notion of refactoring: systematically transforming your working code base into a cleaner, improved version of itself that is easier to read, maintain and extend.

Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations, each of which “too small to be worth doing”. However the cumulative effect of each of these transformations is quite significant.

– Martin Fowler, 2018.

Refactoring suggests that code must be continually improved as we work with it. We need to be in a process of perpetual, small improvements.

The goal of refactoring is to reduce technical debt by making small continual improvements to our code. It doesn’t reduce the likelihood of technical debt, but it amortizes that debt over many small improvements.

Refactoring your code means doing things like:

• • Cleaning up class interfaces and relationships.
    • Fixing issues with class cohesion.
    • Reducing or removing unnecessary dependencies.
    • Simplifying code to reduce unnecessary complexity.
    • Making code more understandable and readable.
    • Adding more exhaustive tests.

In other words, refactoring involves code improvement not related to adding functionality.

TDD and Refactoring work together. You continually refactor as you expand your code, and you rely on the tests to guarantee that you aren’t making any breaking changes to your code.

How to refactor code?

The Rule of Three

• When you’re doing something for the first time, just get it done.
• When you’re doing something similar for the second time, do the same thing again.
• When you’re doing something for the third time, start refactoring.

When adding a feature

• Refactor existing code before you add a new feature, since it’s much easier to make changes to clean code. Also, you will improve it not only for yourself but also for those who use it after you.

When fixing a bug

• If you find or suspect a bug, refactoring to simplify the existing code can often reveal logic errors.

During a code review

• The code review may be the last chance to tidy up the code before it becomes available to the public.

Refactorings

Martin Fowler. 2018. Refactoring: Improving the Design of Existing Code. 2nd Edition. Addison-Wesley. ISBN 978-0134757599.

The author has also made them available at: https://refactoring.com/catalog/

IntelliJ IDEA also makes this easy by providing automated ways of safely transforming your code. These refactorings often involve operations that would be tricky to do by-hand but easy for the tool do perform for you (e.g. renaming a method that is called from multiple locations).

To invoke refactorings, select an item in your source code (e.g. variable or function name) and press Ctrl-T to invoke the refactoring menu. You can also access from the application menu.

They have a complete list of these in the IntelliJ IDEA documentation. Refactorings include:

Code Smells

A “code smell” is a sign that a chunk of code is badly designed or implemented. It’s a great indication that you may need to refactor the code.

• Adjectives used to describe code:

• • “neat”, “clean”, “clear”, “beautiful”, “elegant” <— the reactions that we want
    • “messy”, “disorganized”, “ugly”, “awkward” <— the reactions we want to avoid

• A negative emotional reaction is a flag that your brain doesn’t like something about the organization of the code - even you can’t immediately identify what that is.

• Conversely, a positive reaction indicates that your brain can easily perceive and following the underlying structure.

The following categories and examples are taken from refactoring.guru.

Bloaters

Bloaters are code, methods and classes that have increased to such gargantuan proportions that they are hard to work with. These smells accumulate over time as the program evolves (and especially when nobody makes an effort to eradicate them).

• Long method: A method contains too many lines of code. Generally, any method longer than ten lines should make you start asking questions.
• Large class: A class contains many fields/methods/lines of code. This suggests that it may be doing too much. Consider breaking out a new class, or interface.
• Primitive obsession: Use of related primitives instead of small objects for simple tasks (such as currency, ranges, special strings for phone numbers, etc.). Consider creating a data class, or small class instead.
• Long parameters list: More than three or four parameters for a method. Consider passing an object that owns all of these. If many of them are optional, consider a builder pattern instead.

Object-Oriented Abusers

All these smells are incomplete or incorrect application of object-oriented programming principles.

• Alternative Classes with Different Interfaces: Two classes perform identical functions but have different method names. Consolidate methods into a single class instead, with support for both interfaces.
• Refused bequest: If a subclass uses only some of the methods and properties inherited from its parents, the hierarchy is off-kilter. The unneeded methods may simply go unused or be redefined and give off exceptions. This violates the Liskov-substitution principle! Add missing behaviour, or replace inheritance with delegation.
• Switch Statement: You have a complex switch operator or sequence of if statements. This sometimes indicates that you are switching on type, something that should be handled by polymorphism instead. Consider whether a class structure and polymorphism makes more sense in this case.
• Temporary Field: Temporary fields get their values (and thus are needed by objects) only under certain circumstances. Outside of these circumstances, they’re empty. This may be a place to introduce nullable types, to make it very clear what is actually happening (vs. constantly checking fields for the presence of data).

Dispensibles

A dispensable is something pointless and unneeded whose absence would make the code cleaner, more efficient and easier to understand.

• Comments: A method is filled with explanatory comments. These are usually well-intentioned, but they’re not a substitute for well-structured code. Comments are a maintenance burden. Replace or remove excessive comments.
• Duplicate Code: Two code fragments look almost identical. Typically, done accidentally by different programmers. Extract the methods into a single common method that is used instead. Alternately, if the methods solve the same problem in different ways, pick and keep the most efficient algorithm.
• Dead Code: A variable, parameter, field, method or class is no longer used (usually because it’s obsolete). Delete unused code and unneeded files. You can always find it in Git history.
• Lazy Class: Understanding and maintaining classes always costs time and money. So if a class doesn’t do enough to earn your attention, it should be deleted. This is tricky: sometimes a small data class is clearer than using primitives (e.g. a Point class, vs using x and y stored as doubles).

Couplers

All the smells in this group contribute to excessive coupling between classes or show what happens if coupling is replaced by excessive delegation.

• Feature envy: A method accesses the data of another object more than its own data. This smell may occur after fields are moved to a data class. If this is the case, you may want to move the operations on data to this class as well.
• Inappropriate intimacy: One class uses the internal fields and methods of another class. Either move those fields and methods to the second class, or extract a separate class that can handle that functionality.
• Middle man: If a class performs only one action, delegating work to another class, why does it exist at all? It can be the result of the useful work of a class being gradually moved to other classes. The class remains as an empty shell that doesn’t do anything other than delegate. Remove it.

https://xkcd.com/1513

CI/CD

Test-Driven Development addresses the issue of doing local, small-scope testing as part of implementation. However, it doesn’t address issues related to the system as a whole, or that might only occur when components are integrated.

Martin Folwer introduced the term continuous integration to describe a system where we also perform integration testing at least once pr day.

The fundamental benefit of continuous integration is that it removes sessions where people spend time hunting bugs where one person’s work has stepped on someone else’s work without either person realizing what happened. These bugs are hard to find because the problem isn’t in one person’s area, it is in the interaction between two pieces of work.

– Fowler, 2000.

A system that supports continuous integration needs, at a minimum, the following capabilities:

• It requires a revision control system, with a centralized main revision that can be used.
• The build process should be automated so that anyone can manually launch the process. [it should also support automated testing based on other events, like integrating a branch in the source tree].
• Tests should be automated so that they can be launched manually as well.
• The system should produce a final distribution.

CI Systems

Continuous Integration Systems are software systems that provide these capabilities. Early standalone systems include Jenkins (Open Source), and CircleCI. Many source control platforms also provide CI functionality, including Bitbucket, GitHub and GitLab.

For example, you can automate GitLab so that it will build and run your tests anytime a specific action is performed like committing to a branch, or merging a PR. This is managed through the CI/CD section of the project configuration.

The GitLab configuration and terminology is pretty standard:

• A pipeline represents the work or the job that will be done.
• A stage represents a set of jobs that need to be executed together.
• Jobs are executed by runners, which define and where a job will be executed.

These all represent actions that will be taken against your source code repository at specific times. The examples that they provide include:

• A build stage, with a job called compile.
• A test stage, with two jobs called test1 and test2.
• A staging stage, with a job called deploy-to-stage.
• A production stage, with a job called deploy-to-prod.

In this way, you can setup your source code repository to build, test, stage and deploy your software automatically one or more times per day, as a result of some key event, or when manually executed.

Unit Testing

What is a unit test?

Let’s define it more formally. A unit test is a test that meets the following three requirements [Khorikov 2020]:

• Verifies a single unit of behavior,
• Does it quickly, and
• Does it in isolation from other tests.

Unit tests should target classes or components in your program. i.e. they should exercise how a particular class works. They should be small, very focused, and quick to execute and return results.

Testing in isolation means removing the effects of any dependencies on other code, libraries or systems. This means that when you test the behaviour of your class, you are assured that nothing else is contributing to the results that you are observing. We’ll discuss strategies to accomplish this in the [Dependencies] section.

Structuring a test

A typical unit test uses a very particular pattern, known as the arrange, act, assert pattern. This suggests that each unit test should consist of these three parts:

1. Arrange: bring the system under test (SUT) to the starting state.
2. Act: call the method or methods that you want to test.
3. Assert: verify the outcome of the above action. This can be based on return values, or some other conditions that you can check.

Note that your Act section should have a single action, reflecting that it’s testing a single behaviour. If you have multiple actions taking place, that’s a sign that this is probably an integration test (see below). As much as possible, you want to ensure that you are writing minimal-scope unit tests.

How to write tests

Practically, a unit test is just a Kotlin class with annotated methods that tell the compiler how to treat the code. It’s best practice to have one test class for each implementation class that you want to test. e.g. class Main with a test class MainTest. This test class would contain multiple methods, each representing a single unit test.

Tests should be placed in a special test folder in the Gradle directory structure. When building, Gradle will automatically execute any tests that are placed in this directory structure¹.

Your unit tests should be structured to create instances of the classes that they want to test, and check the results of each function to confirm that they meet expected behaviour.

For example, here’s a unit test that checks that the Model class can add an Observer properly. The addObserver() method is the test (you can tell because it’s annotated with @Test). The @Before method runs before the test, to setup the environment. We could also have an @After method if needed to tear down any test structures.

class ObserverTests() {
    lateinit var model: Model
    lateinit var view: IView

    class MockView() : IView {
        override fun update() {
        }
    }

    @Before
    fun setup() {
        model = Model()
        view = MockView()
    }

    @Test
    fun addObserver() {
        val old = model.observers.count()
        model.addObserver(view)
        assertEquals(old+1, model.observers.count())
    }
}

Let’s walkthrough creating a test.

To do this in IntelliJ, select a class in the editor, press Alt-Enter, and select “Create Test” from the popup menu. This will create a unit test using JUnit, the default test framwork. There is a detailed walkthrough on the IntelliJ support site.

The convention is to name unit tests after their class they’re testing, with “Test” added as a suffix. In this example, we’re creating a test for a Model class so the test is automatically named ModelTest. This is just a convention - you can name it anything that you want.

We’ve manually added the addition() function. We can add as many functions as we want within this class. By convention, they should do something useful with that particular class.

Below, class ModelTest serves as container for our test functions. In it, we have two unit tests that will be automatically executed when we built. NOTE that you would need more than these two tests to adequately test this class - this is just an example.

import org.junit.After
import org.junit.Assert.assertEquals
import org.junit.Before
import org.junit.Test

class ModelTests {
    lateinit var model: Model
    
    @Before
    fun setup() {
        model = Model()
        model.counter = 10
    }

    @Test
    fun checkAddition() {
        val original = model.counter
        model.counter++
        assertEquals(original+1, model.counter)
    }

    @Test
    fun checkSubtraction() {
        val original = model.counter
        model.counter--
        assertEquals(original-1, model.counter)
    }

    @After
    fun teardown() {
    }
}

The kotlin.test package provides annotations to mark test functions, and denote how they are managed:

In our test, we call utility functions to perform assertions of how the function should successfully perform.

How to run tests

Tests will be run automatically with gradle build or we can execute gradle test to just execute the tests.

$ gradle test
BUILD SUCCESSFUL in 760ms
3 actionable tasks: 3 up-to-date

Gradle will report the test results, including which tests - if any - have failed.

You can also click on the arrow beside the test class or name in the editor. For example, clicking on the arrow in the gutter would run this addObserver() test.

Integration Testing

Unit tests are great at verifying business logic, but it’s not enough to check that logic in a vacuum. You have to validate how different parts of it integrate with each other and external systems: the database, the message bus, and so on." – Khorikov, 2020.

A unit test is a test that meets these criteria (from the previous chapter):

• Verifies a single unit of behaviour (typically a class),
• Does it quickly, and
• Does this in isolation from other dependencies and other tests.

An integration test is a test that fails to meet one or more of these criteria. In other words, if you determine that you need to test something outside of the scope of a unit test, it’s considered an integration test (typically because it’s integrating behaviours from multiple components). Performance tests, system tests, etc. are all kinds of integration tests.

There are a lot of different nuanced tests that are used in computer science, but we’ll focus on building generic integration tests.

Typically an integration test is one where you leave in selected dependencies so that you can test the combination of classes together. Integration tests are also suitable in cases where it is difficult to completely remove a dependency. This can happen with some critical, external dependencies like an external database.

This diagram demonstrates how unit tests primarily test the domain model, or business logic classes. Integration tests focus on the point where these business logic classes interact with external systems or dependencies.

Note that in this diagram, we’re also identifying code that we shouldn’t bother testing. Trivial code is low complexity, and typically has no dependencies or external impact so it doesn’t require extensive testing. Overcomplicated code likely has so many dependencies that it’s nearly impossible to test - and it should likely be refactored into something similer and more manageable before you attempt to add tests to it.

How many tests?

When discussing unit tests, we suggested that you should focus on core classes and their behaviours. This is reasonable for unit tests.

We can expand this to suggest that you should “check as many of the business scenario’s edge cases as possible with unit tests; use integration tests to cover one happy path, as well as any edge cases that can’t be covered by unit tests.”

A “happy path” in testing is a successful execution of some functionality. In other words, once your unit tests are done, you should write an integration tests that exercises the functionality that a customer would likely exercise if they were using your software with common features and a common workflow. Focus on that first and only add more integration tests once you have the main execution path identified and tested.

The primary purpose of integration tests is to exercise dependencies, so that should be your main goal. Your main integration test (the “happy path test”) should exercise all external dependencies (libraries, database etc). If it cannot satisfy this requirement, add more integration tests to satisfy this constraint.

Guidelines

Here’s some guidelines for creating integration tests.

1. Make domain model boundaries explicit.

Try to always have an explicit, well-known place for the domain model in your code base. The domain model is the collection of domain knowledge about the problem your project is meant to solve. This can be a separate class, or even a package reserved for the model.

2. Reduce the number of layers of abstraction

“All problems in computer science can be solved by another layer of indirection, except for the problem of too many layers of indirection.” – David J. Wheeler

Try to have as few layers of indirection as possible. In most backend systems, you can get away with just three: the domain model, application services layer (controllers), and infrastructure layer. Having excessive layers of abstraction can lead to bloated and confusing code.

3. Eliminate circular dependencies

Try to keep dependencies flowing in a single direction. i.e. don’t have class A call into class B, and class B call back into class A with results. Circular dependencies like this create a huge cognitive load for the person reading the code, and make testing much more difficult.

Dependencies

The idea of a dependency is central to our understanding of how to isolate a particular class or set of classes for testing.

When you are examining a software component, we say that your component may be dependent on one or more other software entities to be able to run successfully. For example, you may need to link in another library, or import other classes, or connect to another software system (like a database). Each of these represents code that affects how the code being tested will execute.

We often call the external software component or class a dependency. That word describes the relationship (classes dependent on one another), and the type of component (a dependency with respect to the original class).

A key strategy when testing is to figure out how to control these dependencies, so that you’re exercising your class independently of the influence of other components.

We can further differentiate these dependencies:

Managed vs. Unmanaged dependencies. There is a difference between those that we control directly (managed), vs. those that may be shared with other software. A managed dependency suggests that we control the state of that system.

• Examples: a library that is statically linked is managed; a dynamically linked library is not. A database could be single-file and used only for your application (managed) or shared among different applications (unmanaged).

Internal vs. External dependencies. Running in the context of our process (internal) or out-of-process (external). A library is internal, a database is typically external.

• Examples: A library, regardless of whether it is managed, is internal. A database, as a separate process is always external.

It is important to think about these distinctions for our dependencies because they affect what we can and cannot control during testing. For example, an unmanaged dependency means that we do not control it’s state and we may not be able to test that specific component or dependency. The best we could do it test our interface against it, since we may not be able to trust the results of any actions that we take against it.

Generally speaking, we cannot test unmanaged dependencies since we cannot control them. We also tend to be limited in our ability to test external systems, since we do not manage their state.

Test doubles

To achieve isolation in testing, we often create test doubles — classes that are meant to look like a dependent class, but that don’t actually implement all of the underlying behaviour. This lets us swap in these “fake” classes for testing.

There are five principal kinds of test doubles: Dummies, Fakes, Stubs, Spies and Mocks.

Mocks are “objects pre-programmed with expectations which form a specification of the calls they are expected to receive.” – Martin Fowler, 2006.

A mock is a fake object that holds the expected behaviour of a real object but without any genuine implementation. For example, we can have a mocked File System that would report a file as saved, but would not actually modify the underlying file system.

You can fairly easily create these mock classes yourself for code domain objects.

Several libraries have also been established to help create mocks of objects. Mockito is one of the most famous, and it can be complemented with Mockito-Kotlin. Here’s an example of a mock File that reports a path, but doesn’t actually do anything else.

private val mockedFile: File {
	return mock { on { absolutePath} doReturn "/random"}
}

The value in mocks is that they break the dependency between your method-under-test (MUT) and any external classes, by replacing the external dependency with a “fake class” with predetermined behaviour that helps you test.

The value of interfaces

One important recommendation is that you introduce interfaces for out-of-class dependencies. For instance, you will often see code like this:

public interface IUserRepository
public class UserRepository : IUserRepository

This is common when testing, even in cases when that class may represent the only realization of an interface. This allows you to easily write mocks against the interface, where it’s relatively easy to determine what expected behaviour should be.

Dependency injection

The second half of this is dependency injection. This is the practice of supplying dependencies to an object in it’s argument list instead of allowing the object to create them itself. If you design your classes this way, then it’s easy to create an instance of a mock and provide that to your function, instead of allowing the function to instantiate the object itself.

Dependency injection is basically providing the objects that an object needs (its dependencies) instead of having it construct them itself. It’s a very useful technique for testing, since it allows dependencies to be mocked or stubbed out.

https://stackoverflow.com/questions/130794/what-is-dependency-injection

For instance, we might have a class that uses a database for persistence:

class Persistence {
  val repo = UserRepository() // dependency
  
  fun saveUserProfile(val user: User) {
    repo.save(user)
  }
}

val persist = Persistence()
persist.saveUserProfile(user) // save using the real database

Imagine that we want to test our saveUserProfile method. This would be extremely difficult to do cleanly, since we have a dependency on the repo that our Persistance class creates.

We could instead change our Persistence class so that we pass in the dependency. This allows us to control how it is created, and even replace the UserRepository() with a mock.

class Persistence(val repo: IUserRepository) {
    fun saveUserProfile(val user: User) {
    repo.save(user)
  }
}

class MockRepo : IUserRepository { 
	// body with functions that mirror how the repo would work
  // but no real implementation
}
val mock = MockRepo()
val persist = Persistance(mock)
persist.saveUserProfile(user) // save using the mock database

Obviously you don’t want to mock everything - that would turn this into a unit test! However, you should use this technique to isolate the classes that you are using, and test just the intended path.

Evaluation

To this point, we’ve focused on testing the functional requirements and the correctness of our results. However, there’s other criteria: the non-functional requirements or properties of our system that we defined during the requirements gathering phase.

Non-functional requirements are defined as significant, measurable characteristics of a system. They can include things like:

• Processing speed: how long particular computations or functions take to execute.
• Volume of data processed: images processed, calculations performed and so on.
• Network performance: how long transmitting, receiving data over a network takes.
• Memory consumed: peak, and average memory consumption.
• Startup time: how long it takes to launch.

Verifying these requirements is only possible if we can collect the appropriate information.

In this section, we’ll talk about approaches to measuring and capturing different forms of data. Doing this often involves instrumenting your application – adding functionality directly to your source code that helps us collect this information. Unlike writing tests, which aim to existing externally to your source code, instrumenting your code can mean making direct modifications.

Gathering information

The Kotlin and JDK libraries contains a number of useful functions that can help us collect system information.

Typically you want to capture data before and after a critical operation, and then compare them to determine the cost of that operation, whatever that might be (e.g. time that it took to execute, memory consumed).

If you are measuring time, the measureTimeMillis function from the kotlin-stdlib is particularly helpful since it takes a lambda argument which is the block of code to execute.

fun performLengthyComputation() {
	// a lot of processing goes on here
}

// manually calculating how long a function takes to run
val start = getTimeMillis()
performLengthyComputation()
val end = getTimeMillis()
println("The elapsed time in milliseconds is ${end-start}")

// using kotlin-stdlib
val elapsed = measureTimeMillis { performLengthyComputation() }
println("The elapsed time in milliseconds is $elapsed")

You are going to want to measure everything that you listed in your non-functional requirements.

• If the functionality that you want to measure spans many classes or functions, you may need to write a top-level function to encapsulate that behaviour so that it’s easier to measure.
• Milliseconds is probably the most coarse-grained you want to measure; there are also functions to measure microseconds but your tests will not be accurate to that level.
• Keep in mind that your system has other things running that will consume memory, drive space and so on. It is difficult/impossible to completely isolate your application.

To gather information, it’s important that you actually use the functions that you want to measure: run the application, and interact with the features that you care about testing. You should plan on doing this multiple times, and collect data from each attempt - average the results to get a more accurate estimate the value that you are collecting, which will reduce the impact of other applications that may be running on the system and consuming resources.

Logging your data

You will want to gather the information in a text file or database, so that you can examine and analyze it later. You should record each event as a single row in your log file. Each row should contain at least the following:

• Timestamp: Measure events and record time in milliseconds.
• Event type: this is more useful if you use logging for debugging purposes (where you can setup INFO, WARNING, EXCEPTION categories of messages). Use a default option here e.g. INFO.
• Description: Include a description of what your are logging. e.g. “time to execute bigFunction()”
• Value: Capture the numeric value in question. e.g. time in milliseconds.

Kotlin does not have a built-in logging class, but there are some options:

• Android has a Log class which is extremely robust and integrates with the development environment.
• Desktop/JDK users can use the Java Logging API. Although it’s a Java library, its easy to use and compatible with Kotlin.
• There are also third-party solutions like Log4J that are popular for commercial environments.

Here’s an example of using the Java logging class to save log information.

import java.util.logging.*

object LoggerExample {
    private val LOGGER = Logger.getLogger(LoggerExample::class.java.getName())

    @JvmStatic
    fun main(args: Array<String>) {
        // Set handlers for both console and log file
        val consoleHandler: Handler? = ConsoleHandler()
        val fileHandler: Handler? = FileHandler("./example.log")
        LOGGER.addHandler(consoleHandler)
        LOGGER.addHandler(fileHandler)

        // Set to filter what gets logged at each destination
        consoleHandler?.setLevel(Level.ALL)
        fileHandler?.setLevel(Level.ALL)
        LOGGER.level = Level.ALL

        // Log some data
        LOGGER.info("Information")
        LOGGER.config("Configuration")
        LOGGER.warning("Warning")

        // Console handler removed
        LOGGER.removeHandler(consoleHandler)

        // This should still go to the log file
        LOGGER.log(Level.FINE, "Finer logged without console")
    }
}

This class was designed for logging large amounts of data, so it provides a great deal of flexibility in determining how data gets saved, and even allows you to send different data to different destinations. By default, this library generates output in XML. Here’s one record that was generated from the example above.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE log SYSTEM "logger.dtd">
<log>
<record>
  <date>2022-03-08T22:13:55.289391Z</date>
  <millis>1646777635289</millis>
  <nanos>391000</nanos>
  <sequence>0</sequence>
  <logger>LoggerExample</logger>
  <level>INFO</level>
  <class>LoggerExample</class>
  <method>main</method>
  <thread>1</thread>
  <message>Information</message>
</record>
</log>

Real-time Profiling

Finally, IntelliJ IDEA and Android Studio both include real-time profiling tools that can help you detect performance issues. These are not a replacement for instrumenting your application but are extremely helpful for debugging and finding issues.

To launch the profiler in IntelliJ IDEA:

• Run - Run
• Run - Attach Profiler to Process…

This will launch your application. IntelliJ IDEA will collect data from your application as it’s running. Once you feel you have enough data (i.e. you’ve run through the functionality one or more times), choose to stop collecting in the UI, and display the data. You will then be able to browse memory, CPU usage and so on over the time your application was being profiled.

Examining these results is beyond what we will attempt in this course.

Copyright & Licensing

Copyright

Before distributing your software, in any form, it’s critical to establish ownership and rights pertaining to that software.

A copyright is a type of intellectual property that gives its owner the exclusive right to copy and distribute a creative work, usually for a limited time. Copyright is intended to protect the original expression of an idea in the form of a creative work, but not the idea itself. A copyright is subject to limitations based on public interest considerations, such as the fair use doctrine.

Software copyright is the application of copyright in law to machine-readable software. Under Canadian and US law, all software is copyright protected, in both source code and object code forms.

Practically, this means that different companies can independently produce software that solves the same problem, and there is no law preventing that from occurring, provided that they do not reuse actual source or object code from their competitor.

How do I assert copyright?

In Canada, software is protected under the Copyright Act of Canada. Copyright is acquired automatically when an original work is generated; the creator is not required to register or mark the work with the copyright symbol in order to be protected. The rights holder is granted: the exclusive right of reproduction, the right to rent the software, the right to restrain others from renting the software and the right to assign or license the copyright to others.

It’s common practice to assert your copyright claim in the header of your software source files. Although is not required to assert copyright, it’s a flag for potential violators, and it might make it easier to defend in court.

Copyright (c) 2022. Jeff Avery.

Licensing

As the rights holder, you can grant others rights with respect to your software. A software license is a legal instrument that grants the licensee (i.e. an end-user) permission to use the software in a manner dictated by the license. These rights could include (but aren’t limited to) the right to install and use it, the right to modify the source code, or the right to redistribute the software with or without changes.

Authors of copyrighted software can also choose to donate their software to the public domain, in which case it is also not covered by copyright and, as a result, cannot be licensed.

Standard Licenses

There are a number of standard software licenses that have been developed and are commonly used, particularly with resepect to Open Source software¹. The following table is extracted from the Wikipedia page for software licensing.

A permissive software license, sometimes also called BSD-style is a free-software license which instead of copyleft protections, carries only minimal restrictions on how the software can be used, modified, and redistributed, usually including a warranty disclaimer. Examples include the GNU All-permissive License, MIT License, BSD licenses, Apple Public Source License and Apache license. As of 2016, the most popular free-software license is the permissive MIT license.

Copyleft is the practice of granting the right to freely distribute and modify intellectual property with the requirement that the same rights be preserved in derivative works created from that property.

Copyleft software licenses are considered protective in contrast with permissive free software licenses, and require that information necessary for reproducing and modifying the work must be made available to recipients of the software program. This information is most commonly in the form of source code files, which usually contain a copy of the license terms and acknowledge the authors of the code. Notable copyleft licenses include the GNU General Public License (GPL), originally written by Richard Stallman, and the Creative Commons share-alike license.

Non-commercial licenses are intended to be used only be entities with no profit motive, including charities and public institutions. This is not common, and is both difficult to interpret and enforce.

A proprietary license refers to any other license, but usually one which grants few to no rights to the end-user (e.g. most commercial software licenses, which do not grant you any rights apart from the ability to install and use on a single machine).

It’s standard practice to include your license agreement with your product, typically as a license.txt file or something similar in your distribution.

How do I apply a license?

1. Distribute the license with your program.

• Include a license.txt file in your distribution.
• If you provide source code to anyone, include a statement about how it is licensed in the header of each file. Check the license to see what is required.

2. Include a licensing statement on your website.

• See terms of each license to check what’s suitable. e.g.

Unless explicitly stated otherwise all files in this repository are licensed under the Apache Software License 2.0 [insert boilerplate notice here]

Resources

Open Source Initiative. 2022. Licenses and Standards. https://opensource.org/licenses

Documentation

If your product is complex, or if you want a way to showcase your features, you might consider producing user documentation. This comes in many different forms:

• Getting started guide (web page, PDF): the basics to use your software
• Tutorials (web pages): walk through simple tasks with examples
• User Guide: comprehensive documentation

Documentation can be printed and bundled (uncommon), distributed with your software (PDF, other formats, more common) or hosted on your website (very common).

Keep in mind that this all takes effort. Tailor your documentation to the complexity of your product (and the likelihood of users actually taking the time to read it!)

Release notes

Every public release should include release notes: a list of changes that you have made to your product for that particular release. Depending on the nature of your product, and your relationship with your users, the details can be fairly general (“added support for Windows 11”) or incredibly detailed (“fixed bug XXX”).

The release notes are also a good place to put things like

• OS or hardware compatibility details
• copyright and license information
• information on how users can contact you or get help

Release notes are typically released in one of the following ways:

• a readme.txt file included in your distribution.
• a popup window in your application that includes these details.
• a page on your website (if you do this, put a way to open that page from within your application).

Suggestions

A discussion of how to write effective documentation is beyond the scope of this course, but we make some broad suggestions:

• Consider Markdown as an authoring format. You can then convert markdown to PDF, EPUB, or HTML for publishing using pandoc. This site, for example, is authored in Markdown and then converted to a website using Hugo.
• If you wish to create developer documentation (including class diagrams and so on), there are specialized authoring tools. Dokka can generate Javadoc, HTML or Markdown documentation from Kotlin code (much as Javadoc does for Java code).
• Finally, IntelliJ IDEA can generate class diagrams from source code. Right-click on the project file, then select Diagrams from the popup menu.

Release Process

What do we need to do for a software release?

• Update our internal project tracking systems

  • Close the sprint
  • Update and close issues
  • Update our internal documentation e.g. wiki

• Prepare additional materials for the release

  • Release notes
  • User documentation
  • Update build scripts/configuration
  • Build installers

Versioning

• You should version your software, so that every release has a release number and date associated with it.
• The standard convention is a triple, separated by decimals, of the format: major.minor.build. For example, 1.2.3 would be major version 1, minor version 2, build 3.
• • Major signifies a major product release. This is somewhat arbitrary, but typically is released infrequently and includes major features changes or additions. If you charge by release, you would typically charge for every new major version. You might release a new major version as frequently as once per year, or as infrequently as once very few years.
  • Minor indicates a minor product release, typically a combination of new minor features, and bug or compatibility fixes. You might release a minor version a few times per year and users would not ordinarily expect to pay for these.
  • Build number is internal build number within a minor release. This is intended to reflect bug fixes only; you typically iterate over builds internally and release the final successful version publically.

Release Chart