1.4-Software-Development-Principles

Exam Software Development Principles - 2028-06-08 (Exam)

Introduction

This exam is made up of three parts. These test your ability to explain and apply development principles.

Please note that this is an example text. It shows the structure of the exam. There cannot be any rights derived from this example.

Points

You can get a total of 16 points. These points are distributed as follows:

Component	Number of points	Time suggestion
Part 1	4	15 min
Part 2	8	30 min
Part 3	18	75 min
Total	30	120 min

Documentation

The following websites are available during the test:

• https://docs.oracle.com/
• http://fasterxml.github.io/jackson-core/javadoc/2.5/
• https://junit.org/junit5/docs/current/user-guide/
• https://www.javadoc.io/doc/com.fasterxml.jackson.core

Part 1: Terminology [4pt]

Answer the questions below. Write your answers in the studentAnswers.md. There is a .md file for english and dutch. Choose the language you prefer. (You must not add other languages!)

Question 1a [2pt]

What is meant by a ****? Please describe this concept in your own words. Provide two examples.

Write your answer in the student answers file of the project.

Question 1b [2pt]

What is meant by a ****? Give an example of this too.

Write your answer in the student answers file of the project.

Part 2: Streams [8pt]

The resources folder contains a file which lists **** and their characteristics. Some fields are: (THIS IS AN EXAMPLE!)

• number
• firstName
• lastName
• birthday
• class

Questions to answer [2pt per question]

There are four methods with no meaningful content (doStreams1(), doStreams2(), etc.) They are used to display information about the dataset.

1. Count the number of entries that **** (There should be about X.)
2. Return a list of names of all **** (List should contain among others "X".)
3. Calculate average X for all ****. (Should lie somewhere between X and Y.)
4. List the highest Y over all ****. (Hint: This requires the use of .flatMap.)

Implement the four methods using java streams. Any other implementation method will not award any points.

Part 3: Refactoring [16pts total]

Introduction

In this segment you will improve a rather badly written program. The questions below will guide you through the process.

You are ONLY required to change the code of the <this-class>. The Application and the <that-package> classes should not require any changes.

3a Enums and/or constants [4pt]

The code starts with a long list of “X”. Please rewrite the code to use a clear set of constants.

• Group all constants together
• Use enums where applicable

3b Generics [4pt]

Reading data from the file delivers a ****. Make this class generic.

• Make the list structure generic
• Make the program use the list in a generic way.

There are some tests that should confirm the working of your list. (See chapter 3d Additional Testion)

3c Dependency injection [4pt]

The **** is the only way to read data into the program. I want to be able to test the application with a different source, for instance JSON, or a database. For testing purposes provide a `****` which provides a hardcoded list of three ****. Please make sure that the Application no longer directly depends on the ****.

• Make the application read data through your interface.
• Implement a **<DummyDataSource>** class that generates data for three dummy objects.
• Declare a JSONDataSource, but leave the implementation empty.

3d Additional Testing [4pt]

Please write tests for the following classes and situations:

• Confirm that the **<insert-object-here>** class throws the correct exceptions. (Both IllegalArgument AND IndexOutOfBounds!)
• Confirm that a new **<your-generic-storage>** is actually empty.
• Confirm that after adding something, **<your-generic-storage>** is no longer empty, and now contains that item.
• Confirm that, when iterating over **<your-generic-storage>**, the correct elements are provided.
• Confirm that the **<DummyDataSource>** returns the right number of objects, and check their content.

3e Quality and Readability [2pt]

When making changes, make sure that the code clearly improves:

• Apply the naming conventions
• Use clear names for your methods
• Methods should only do one thing
• Remove duplicate/unused code
• Create packages that divide the code in clear segments.
• Make sure that the program still works afterward.

When writing tests follow these rules:

• Tests should only confirm one type of activity.
• Tests must have a clear name. We prefer Given_When_Then notation.