Free degree-level programming lessons for careful independent study.

Degree Level Programmes · Programming 1 · Lesson 18

Portfolio Artefact 1: Console Application

Build a small console program from requirements through design, implementation, testing and reflection.

Lesson Overview

Build a small console program from requirements through design, implementation, testing and reflection.

Portfolio focus: Write the brief and acceptance criteria.

ConceptPortfolio project
Run filePortfolioArtefact1Demo.java
BaselinePortfolio evidence items: [write requirement, implement feature, test boundary case]
Evidence3 tasks

Starter: think before typing

Before running this portfolio project example, find the line where the main idea becomes active. Write a prediction: what must already be true for that line to work, and what should be different after it runs? The checked run ends with `Portfolio evidence items: [write requirement, implement feature, test boundary case]`; predict how the focus line helps produce that evidence.

Learning Objectives

  • Produce a complete small Java artefact.
  • Show requirements, design, code and tests as evidence.
  • Reflect on decisions and limitations.
  • Prepare the artefact for review.

Learning Outcomes

  • By the end of the lesson, you can produce a complete small Java artefact.
  • By the end of the lesson, you can show requirements, design, code and tests as evidence.
  • By the end of the lesson, you can reflect on decisions and limitations.
  • By the end of the lesson, you can prepare the artefact for review.

Why this idea exists

A portfolio artefact is a miniature software engineering cycle. It asks you to connect requirements, design, implementation, testing and reflection into one coherent piece of evidence.

This mirrors professional project work, where finished code is only one part of delivery. Reviewers also need to understand scope, decisions, constraints, risks and proof that the software behaves as claimed.

The first artefact should be deliberately modest. A small, complete, tested program teaches more than an ambitious unfinished one because it gives you the whole lifecycle to reflect on.

Deep dive

Mechanism in this example

The important mechanism is visible around `List<String> tasks = new ArrayList<>();`. Read it as a concrete move in the program, not as decorative syntax: identify what value, object, branch, call or boundary is being created at that point.

Design pressure

The first artefact should be deliberately modest. A small, complete, tested program teaches more than an ambitious unfinished one because it gives you the whole lifecycle to reflect on.

Failure mode to watch

For Portfolio Artefact 1: Console Application, deliberately disturb the assumption behind `List<String> tasks = new ArrayList<>();`: use an awkward value, missing input, wrong order of calls or boundary case. The useful question is how that disturbance exposes a weakness in the portfolio project design.

Extension step

Extend the example by doing this: Build the core features. The point is to make one small change that forces you to revisit the concept, rather than adding unrelated features.

Portfolio standard

The portfolio note should not repeat the lesson wording. It should show the edited code, the run result, and your own explanation of this evidence: submit code, tests and a 300-word reflection.

Lesson visual

Photo-real portfolio board with requirement cards, Java source printouts, test table and reflection page clipped together.
Photo-real portfolio board with requirement cards, Java source printouts, test table and reflection page clipped together.Download visual

Type this and run it

Create PortfolioArtefact1Demo.java, type the program, and run it before changing anything. This section is about reproducing the checked baseline.

import java.util.ArrayList;
import java.util.List;

public class PortfolioArtefact1Demo {
  public static void main(String[] args) {
    List<String> tasks = new ArrayList<>();
    tasks.add("write requirement");
    tasks.add("implement feature");
    tasks.add("test boundary case");
    System.out.println("Portfolio evidence items: " + tasks);
  }
}

Build and run it with:

javac PortfolioArtefact1Demo.java && java PortfolioArtefact1Demo

Expected baseline: Portfolio evidence items: [write requirement, implement feature, test boundary case]

Run the code in your browser

Use the editor as an experiment surface. First run the checked version, then make one small change to the part of the program that demonstrates portfolio project and compare the new behaviour with the reference output.

Line-by-line explanation

Read the code as a sequence of responsibilities. The focus line for this lesson is List<String> tasks = new ArrayList<>();; the surrounding lines prepare it, use its result or make the behaviour observable.

import java.util.ArrayList;

In Portfolio Artefact 1: Console Application, this imports ArrayList: a resizable list implementation for changing collections.

import java.util.List;

In Portfolio Artefact 1: Console Application, this imports List: the ordered collection type used to hold several values.

public class PortfolioArtefact1Demo {

This names the runnable class for the Portfolio Artefact 1: Console Application example, giving the compiler and JVM one clear unit to build.

public static void main(String[] args) {

This is the program entry point. In Portfolio Artefact 1: Console Application, it keeps the demonstration of portfolio project in one traceable starting script.

List<String> tasks = new ArrayList<>();

This creates a collection object in Portfolio Artefact 1: Console Application, choosing the data structure before tasks is stored or looked up.

tasks.add("write requirement");

This calls tasks.add with "write requirement" in Portfolio Artefact 1: Console Application. Look for the method definition to see what work actually happens.

tasks.add("implement feature");

This calls tasks.add with "implement feature" in Portfolio Artefact 1: Console Application. Look for the method definition to see what work actually happens.

tasks.add("test boundary case");

This calls tasks.add with "test boundary case" in Portfolio Artefact 1: Console Application. Look for the method definition to see what work actually happens.

System.out.println("Portfolio evidence items: " + tasks);

This prints "Portfolio evidence items: " + tasks as the observable evidence for Portfolio Artefact 1: Console Application. The output lets the learner check whether the portfolio project idea behaved as predicted.

}

This closes the innermost Portfolio Artefact 1: Console Application block, so the immediately preceding method, branch or loop has finished.

}

This closes the outer Portfolio Artefact 1: Console Application structure, returning the reader to the surrounding class or file.

Worked example

From code to explanation

Problem: Use Portfolio Artefact 1: Console Application to complete a small portfolio-quality step: Write the brief and acceptance criteria.

Method: Locate the line `List<String> tasks = new ArrayList<>();`, explain the exact role it plays, then decide what you would change to extend the example without changing the whole program.

Reveal worked answer

The checked run should produce `Portfolio evidence items: [write requirement, implement feature, test boundary case]`. A strong answer links the result back to portfolio project: what was created, selected, stored, called or protected, and why that matters for the portfolio task.

Trace the program

Before: Before the key operation, identify the relevant value, object, branch or resource that the portfolio project concept depends on.

During: Trace `List<String> tasks = new ArrayList<>();` as the Portfolio Artefact 1: Console Application example executes. Say whether that operation creates data, checks a condition, calls behaviour, stores information or crosses a boundary.

After: Compare the run with the expected evidence: `Portfolio evidence items: [write requirement, implement feature, test boundary case]`.

Change: Now build the core features, run again, and explain the smallest reason the behaviour changed.

Common misconception

A common mistake in portfolio artefact 1: console application is treating the example as a finished answer. For portfolio project, the important question is narrower: which operation carries the idea, what does it make possible, and what would break if you changed it carelessly?

Quick checks

1. In this Portfolio Artefact 1: Console Application example, what is the best reason to focus on `List<String> tasks = new ArrayList<>();`?

2. Which evidence is strongest after you edit and rerun this example?

How to study this lesson

For Portfolio Artefact 1: Console Application, predict how portfolio project changes the run before you press Run.

Use the first portfolio task as your main edit: Write the brief and acceptance criteria.

Use the second task as your variation: Build the core features.

Finish with evidence, not a diary entry: Submit code, tests and a 300-word reflection.

Portfolio Practice

  1. Write the brief and acceptance criteria.
  2. Build the core features.
  3. Submit code, tests and a 300-word reflection.

Final self-check

Can you explain the key operation?

Explain the line identified in the quick check in one or two sentences. Your answer should say what it does before the output Portfolio evidence items: [write requirement, implement feature, test boundary case] appears.

Can you justify the portfolio evidence?

Your evidence should include the original run, one edited run, and a short note explaining how the edit affected portfolio project.

Study route

Practise portfolio project by predicting the Java example, typing it, running it in the browser, tracing the result and saving portfolio evidence.

Next, move into Portfolio Artefact 2 and Review and carry forward one improvement from this lesson into the next program.