This site is from a past semester! The current version will be here when the new semester starts.

Week 4 [Fri, Aug 28th] - Topics

[W4.1] Design: Models

[W4.1a] Design → Modelling → Introduction → What
[W4.1b] Design → Modelling → Introduction → How
[W4.1c] Design → Modelling → Introduction → UML models

[W4.2] Class/Object Diagrams: Basics

[W4.2a] Design → Modelling → Modelling Structure → OO structures
[W4.2b] Design → Modelling → Modelling Structure → Class diagrams - basic
[W4.2c] Design → Modelling → Modelling Structure → Object diagrams
[W4.2d] Tools → UML → Object versus class diagrams

[W4.3] Class Diagrams: Intermediate-Level

[W4.3a] Tools → UML → Notes
[W4.3b] Tools → UML → Constraints : OPTIONAL
[W4.3c] Tools → UML → Class Diagrams → Associations as attributes
[W4.3d] Design → Modelling → Modelling Structure → Class diagrams - intermediate
[W4.3e] Paradigms → OOP → Associations → Association classes

[W4.4] Java: JavaFX

[W4.4a] C++ to Java → Miscellaneous Topics → JavaFX

[W4.5] Java: varargs

[W4.5a] C++ to Java → Miscellaneous Topics → Varargs :

[W4.6] Code Quality: Naming

[W4.6a] Implementation → Code Quality → Naming → Introduction
[W4.6b] Implementation → Code Quality → Naming → Basic → Use nouns for things and verbs for actions
[W4.6c] Implementation → Code Quality → Naming → Basic → Use standard words
[W4.6d] Implementation → Code Quality → Naming → Intermediate → Use name to explain
[W4.6e] Implementation → Code Quality → Naming → Intermediate → Not too long, not too short
[W4.6f] Implementation → Code Quality → Naming → Intermediate → Avoid misleading names

[W4.7] Static Analysis

[W4.7a] Quality Assurance → Quality Assurance → Static Analysis → What

[W4.8] Code reviews

[W4.8a] Quality Assurance → Quality Assurance → Code Reviews → What

[W4.9] RCS: Managing Pull Requests

[W4.9a] Tools → Git and GitHub → Reviewing PRs

[W4.10] Automating the Build Process

[W4.10a] Implementation → Integration → Introduction → What
[W4.10b] Implementation → Integration → Build Automation → What
[W4.10c] Implementation → Integration → Build Automation → Continuous integration and continuous deployment

Guidance for the item(s) below:

In the tP, you'll be thrown into a codebase of about 6K Lines of CodeLoC. It would be hard to understand the design simply by reading the code. That's why the code base comes with a Developer Guide containing some design models i.e., the diagrams. That means, you should be able to interpret those models by the time you start the tP in a few weeks. 😨

Let's start getting ready for that today. First, let's go through a high-level explanation of models.

[W4.1] Design: Models

W4.1a

Design → Modelling → Introduction → What

Can explain models

A model is a representation of something else.

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

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

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

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

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

W4.1b

Design → Modelling → Introduction → How

Can explain how models are used

In software development, models are useful in several ways:

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

Some examples of using models for analysis:

Models of the i.e. the environment in which the software is expected to solve a problemproblem domain can be built to aid the understanding of the problem to be solved.
When planning a software solution, models can be created to figure out how the solution is to be built. An architecture diagram is such a model.

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

Some examples of using models to communicate:

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

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

Some examples of using models as blueprints:

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

Model Driven Development extra

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

Design → Modelling → Introduction → UML models

Can identify UML models

The following diagram uses the class diagram notation to show the different types of UML diagrams.

_{source:https://en.wikipedia.org/}

Guidance for the item(s) below:

Now that we have a high-level understanding of the role played by models, let's start learning some UML models, starting with UML class diagrams (and object diagrams which are like a distant cousin of class diagrams).

Note that we are learning to interpret these models only, not draw them (that would come later), or design them. Hence, we will be going through these topics fairly rapidly.

[W4.2] Class/Object Diagrams: Basics

Video

W4.2a

Design → Modelling → Modelling Structure → OO structures

Can explain structure modeling of OO solutions

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

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

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

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

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

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

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

Here is an object diagram for the above example:

And here is the class diagram for it:

W4.2b

Design → Modelling → Modelling Structure → Class diagrams - basic

Can use basic-level class diagrams

Contents of the panels given below belong to a different chapter; they have been embedded here for convenience and are collapsed by default to avoid content duplication in the printed version.

Classes form the basis of class diagrams.

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

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

An example class diagram showing associations between classes.

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

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

Which association notations are shown in this diagram?

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

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

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

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

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

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

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

class Item {
    public static int totalItems;
}

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

W4.2c

Design → Modelling → Modelling Structure → Object diagrams

Can use basic object diagrams

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

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

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

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

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

class Item {
    public static int totalItems;
}

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

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

W4.2d

Tools → UML → Object versus class diagrams

Can distinguish between class diagrams and object diagrams

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

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

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

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

Which of these class diagrams match the given object diagram?

(1) (2)

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

[W4.3] Class Diagrams: Intermediate-Level

Video

W4.3a

Tools → UML → Notes

Can use UML notes

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

Example:

W4.3b : OPTIONAL

Tools → UML → Constraints

Can specify constraints in UML diagrams

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

Example:

W4.3c

Tools → UML → Class Diagrams → Associations as attributes

Can show an association as an attribute

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

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

name: type [multiplicity] = default value

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

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

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

Show each association as either an attribute or a line but not both. A line is preferred as it is easier to spot.

W4.3d

Design → Modelling → Modelling Structure → Class diagrams - intermediate

Can use intermediate-level class diagrams

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

Modeling inheritance

Modeling composition

Modeling aggregation

Modeling dependencies

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

Modeling enumerations

Modeling abstract classes

Modeling interfaces

Which of these statements match the class diagram?

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

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

Explanation:

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

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

Consider the code below:

public interface Billable {
    void bill();
}

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

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

    public StockItem(
        String name, Rating rating) {

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

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

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

public enum Rating {
    GOOD, OK, POOR
}

public class Review {
    private final Rating rating;

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

import java.util.List;

public class Inventory {
    private List<Item> items;

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

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

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

(a) Draw a class diagram to represent the code. Show all attributes, methods, associations, navigabilities, visibilities, known multiplicities, and association roles. Show associations as lines.
(b) Draw an object diagram to represent the situation where the inventory has one item named spanner and a review of POOR rating
i.e., new Inventory().add(new StockItem("spanner", new Review(Rating.POOR))).

W4.3e

Paradigms → OOP → Associations → Association classes

Can explain the meaning of association classes

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

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

Implementing association classes

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

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

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

Which of these are suitable as an Association Class?

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

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

Guidance for the item(s) below:

Switching to Java now, let's learn how to write Java GUIs. Fair warning: GUI programming is hard in any language, especially so in Java. Buckle down and get through it; there's no way around it.

[W4.4] Java: JavaFX

W4.4a

C++ to Java → Miscellaneous Topics → JavaFX

Can use JavaFX to build a simple GUI

JavaFX is a technology for building Java-based GUIs. Previously it was a part Java itself, but has become a third-party dependency since then. It is now being maintained by OpenJDK.

Refer to the JavaFX tutorial @SE-EDU/guides to learn how to get started with JavaFX.

Guidance for the item(s) below:

While we are on the topic of Java, also take note of this is a lesser-known Java 'syntactic sugar' feature that was introduced not long ago, in case you come across it one day or find some use for it in your coding.

[W4.5] Java: varargs

W4.5a :

C++ to Java → Miscellaneous Topics → Varargs

Can use Java varargs feature

Variable Arguments (Varargs) is a syntactic sugar type feature that allows writing a method that can take a variable number of arguments.

The search method below can be called as search(), search("book"), search("book", "paper"), etc.

public static void search(String ... keywords){
   // method body
}

Resources:

[W4.6] Code Quality: Naming

W4.6a

Implementation → Code Quality → Naming → Introduction

Can explain the need for good names in code

Proper naming improves the readability of code. It also reduces bugs caused by ambiguities regarding the intent of a variable or a method.

There are only two hard things in Computer Science: cache invalidation and naming things. _{-- Phil Karlton}

W4.6b

Implementation → Code Quality → Naming → Basic → Use nouns for things and verbs for actions

Can improve code quality using technique: use nouns for things and verbs for actions

Every system is built from a domain-specific language designed by the programmers to describe that system. Functions are the verbs of that language, and classes are the nouns.
_{-- Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship}

Use nouns for classes/variables and verbs for methods/functions.

Examples:

Name for a	Bad	Good
Class	`CheckLimit`	`LimitChecker`
Method	`result()`	`calculate()`

Distinguish clearly between single-valued and multi-valued variables.

Examples:

Good

Person student;
ArrayList<Person> students;

Good

name = 'Jim'
names = ['Jim', 'Alice']

W4.6c

Implementation → Code Quality → Naming → Basic → Use standard words

Can improve code quality using technique: use standard words

Use correct spelling in names. Avoid 'texting-style' spelling. Avoid foreign language words, slang, and names that are only meaningful within specific contexts/times e.g. terms from private jokes, a TV show currently popular in your country.

W4.6d

Implementation → Code Quality → Naming → Intermediate → Use name to explain

Can improve code quality using technique: use name to explain

A name is not just for differentiation; it should explain the named entity to the reader accurately and at a sufficient level of detail.

Examples:

Bad	Good
`processInput()` (what 'process'?)	`removeWhiteSpaceFromInput()`
`flag`	`isValidInput`
`temp`

If a name has multiple words, they should be in a sensible order.

Examples:

Bad	Good
`bySizeOrder()`	`orderBySize()`

Imagine going to the doctor's and saying "My eye1 is swollen"! Don’t use numbers or case to distinguish names.

Examples:

Bad	Bad	Good
`value1`, `value2`	`value`, `Value`	`originalValue`, `finalValue`

W4.6e

Implementation → Code Quality → Naming → Intermediate → Not too long, not too short

Can improve code quality using technique: not too long, not too short

While it is preferable not to have lengthy names, names that are 'too short' are even worse. If you must abbreviate or use acronyms, do it consistently. Explain their full meaning at an obvious location.

W4.6f

Implementation → Code Quality → Naming → Intermediate → Avoid misleading names

Can improve code quality using technique: avoid misleading names

Related things should be named similarly, while unrelated things should NOT.

Example: Consider these variables

colorBlack: hex value for color black
colorWhite: hex value for color white
colorBlue: number of times blue is used
hexForRed: hex value for color red

This is misleading because colorBlue is named similar to colorWhite and colorBlack but has a different purpose while hexForRed is named differently but has a very similar purpose to the first two variables. The following is better:

hexForBlack hexForWhite hexForRed
blueColorCount

Avoid misleading or ambiguous names (e.g. those with multiple meanings), similar sounding names, hard-to-pronounce ones (e.g. avoid ambiguities like "is that a lowercase L, capital I or number 1?", or "is that number 0 or letter O?"), almost similar names.

Examples:

Bad	Good	Reason
`phase0`	`phaseZero`	Is that zero or letter O?
`rwrLgtDirn`	`rowerLegitDirection`	Hard to pronounce
`right` `left` `wrong`	`rightDirection` `leftDirection` `wrongResponse`	`right` is for 'correct' or 'opposite of 'left'?
`redBooks` `readBooks`	`redColorBooks` `booksRead`	`red` and `read` (past tense) sounds the same
`FiletMignon`	`egg`	If the requirement is just a name of a food, `egg` is a much easier to type/say choice than `FiletMignon`

[W4.7] Static Analysis

W4.7a

Quality Assurance → Quality Assurance → Static Analysis → What

Video

Can explain static analysis

Static analysis: Static analysis is the analysis of code without actually executing the code.

Static analysis of code can find useful information such as unused variables, unhandled exceptions, style errors, and statistics. Most modern IDEs come with some inbuilt static analysis capabilities. For example, an IDE can highlight unused variables as you type the code into the editor.

The term static in static analysis refers to the fact that the code is analyzed without executing the code. In contrast, dynamic analysis requires the code to be executed to gather additional information about the code e.g., performance characteristics.

Higher-end static analysis tools (static analyzers) can perform more complex analysis such as locating potential bugs, memory leaks, inefficient code structures, etc.

Some example static analyzers for Java: CheckStyle, PMD, FindBugs

Linters are a subset of static analyzers that specifically aim to locate areas where the code can be made 'cleaner'.

Guidance for the item(s) below:

Next up are two techniques that can be used to improve code quality. You need to learn them as you will be encountering both in your iP soon.

[W4.8] Code reviews

W4.8a

Quality Assurance → Quality Assurance → Code Reviews → What

Video

Can explain code reviews

Code review is the systematic examination of code with the intention of finding where the code can be improved.

Reviews can be done in various forms. Some examples below:

Pull Request reviews
- Project Management Platforms such as GitHub and BitBucket allow the new code to be proposed as Pull Requests and provide the ability for others to review the code in the PR.
In pair programming
- As pair programming involves two programmers working on the same code at the same time, there is an implicit review of the code by the other member of the pair.

Formal inspections
- Inspections involve a group of people systematically examining project artifacts to discover defects. Members of the inspection team play various roles during the process, such as:
  - the author - the creator of the artifact
  - the moderator - the planner and executor of the inspection meeting
  - the secretary - the recorder of the findings of the inspection
  - the inspector/reviewer - the one who inspects/reviews the artifact

Advantages of code review over testing:

It can detect functionality defects as well as other problems such as coding standard violations.
It can verify non-code artifacts and incomplete code.
It does not require test drivers or stubs.

Disadvantages:

It is a manual process and therefore, error prone.

10 tips for reviewing code you don’t like - a blog post by David Lloyd (a Red Hat developer).

Guidance for the item(s) below:

Being able to work with PRs is an essential skill. To get started on that, let's learn how to review PRs properly. Besides, you'll be doing some PR reviews in the iP this week.

[W4.9] RCS: Managing Pull Requests

W4.9a

Tools → Git and GitHub → Reviewing PRs

Video

Can review PRs on GitHub

The PR review stage is a dialog between the PR author and members of the repo that received the PR, in order to refine and eventually merge the PR.

Given below are some steps you can follow when reviewing a PR.

1. Locate the PR:

Go to the GitHub page of the repo.
Click on the Pull requests tab.
Click on the PR you want to review.

2. Read the PR description. It might contain information relevant to reviewing the PR.

3. Click on the Files changed tab to see the diff view.

4. Add review comments:

Hover over the line you want to comment on and click on the icon that appears on the left margin. That should create a text box for you to enter your comment.
To mark multiple lines, click-and-drag the icon.
Enter your comment.
This page @SE-EDU/guides has some best practices PR reviewers can follow.
After typing in the comment, click on the Start a review button (not the Add single comment button. This way, your comment is saved but not visible to others yet. It will be visible to others only when you have finished the entire review.
Repeat the above steps to add more comments.

5. Submit the review:

When there are no more comments to add, click on the Review changes button (on the top right of the diff page).

Type in an overall comment about the PR, if any. e.g.,

Overall, I found your code easy to read for the most part except a few places
where the nesting was too deep. I noted a few minor coding standard violations
too. Some of the classes are getting quite long. Consider splitting into smaller
classes if that makes sense.

LGTM is often used in such overall comments, to indicate Looks good to merge.
nit is another such term, used to indicate minor flaws e.g., LGTM, almost. Just a few nits to fix..

Choose Approve, Comment, or Request changes option as appropriate and click on the Submit review button.

Guidance for the item(s) below:

As your project gets bigger and changes become more frequent, it's natural to look for ways to automate the many steps involved in going from the code you write in the editor to an executable product. This is a good time to start learning about that aspect too.

[W4.10] Automating the Build Process

W4.10a

Implementation → Integration → Introduction → What

Can explain integration

Combining parts of a software product to form a whole is called integration. It is also one of the most troublesome tasks and it rarely goes smoothly.

W4.10b

Implementation → Integration → Build Automation → What

Can explain build automation tools

Build automation tools automate the steps of the build process, usually by means of build scripts.

In a non-trivial project, building a product from its source code can be a complex multi-step process. For example, it can include steps such as: pull code from the revision control system, compile, link, run automated tests, automatically update release documents (e.g. build number), package into a distributable, push to repo, deploy to a server, delete temporary files created during building/testing, email developers of the new build, and so on. Furthermore, this build process can be done ‘on demand’, it can be scheduled (e.g. every day at midnight) or it can be triggered by various events (e.g. triggered by a code push to the revision control system).

Some of these build steps such as compiling, linking and packaging, are already automated in most modern IDEs. For example, several steps happen automatically when the ‘build’ button of the IDE is clicked. Some IDEs even allow customization of this build process to some extent.

However, most big projects use specialized build tools to automate complex build processes.

Some popular build tools relevant to Java developers: Gradle, Maven, Apache Ant, GNU Make

Some other build tools: Grunt (JavaScript), Rake (Ruby)

Some build tools also serve as dependency management tools. Modern software projects often depend on third party libraries that evolve constantly. That means developers need to download the correct version of the required libraries and update them regularly. Therefore, dependency management is an important part of build automation. Dependency management tools can automate that aspect of a project.

Maven and Gradle, in addition to managing the build process, can play the role of dependency management tools too.

Getting Started with Gradle -- documentation from Gradle
Gradle Tutorial -- from tutorialspoint.com

Gradle is used for,

a. better revision control
b. build automation
c. UML diagramming
d. project collaboration

(b)

W4.10c

Implementation → Integration → Build Automation → Continuous integration and continuous deployment

Can explain continuous integration and continuous deployment

An extreme application of build automation is called continuous integration (CI) in which integration, building, and testing happens automatically after each code change.

A natural extension of CI is Continuous Deployment (CD) where the changes are not only integrated continuously, but also deployed to end-users at the same time.

Some examples of CI/CD tools: Travis, Jenkins, Appveyor, CircleCI, GitHub Actions