Unit 1: Programming

Program Development & Algorithm

Design Report

Title: "Unit 1: Programming - Program Development & Algorithm Design Report"

Subtitle: "North Sussex Judo Fee Calculator"
Author: "Junior Software Developer, AQ Digital Solutions (AQDS)"
Date: "May 2026"
Word_Count: "~2,450 Words"
Table of Contents
1. Introduction................................................................................................................................................................3

2. Algorithm Definition and Design.......................................................................................................................3

2.1 Problem Analysis and Requirements Decomposition..........................................................................3

2.2 Algorithm Design Tool: Structured Pseudocode...................................................................................4

2.3 Flowchart Representation..............................................................................................................................6

3. Steps to Build the Application............................................................................................................................7

3.1 Development Environment Configuration...............................................................................................7

3.2 Programming Language Selection: Python 3.12...................................................................................8

3.3 Step-by-Step Construction Process............................................................................................................8

Step 1: Constant Definition and Configuration (Procedural Layer)..................................................8

Step 2: Input Validation Layer (Procedural Paradigm).........................................................................8

Step 3: Object-Oriented Domain Modelling (OOP Paradigm)...........................................................8

Step 4: Event-Driven Integration (Event-Driven Paradigm)................................................................9

Step 5: Error Handling and Edge Case Coverage....................................................................................9

4. Converting Algorithm to Program Code.......................................................................................................10

4.1 Algorithm-to-Code Relationship Analysis............................................................................................10

4.2 Challenges Faced and Solutions Implemented....................................................................................11

Challenge 1: Data Type Coercion and Validation Ordering.............................................................11

Challenge 2: Floating-Point Precision in Currency Calculations....................................................11

Challenge 3: Weight Category Boundary Logic...................................................................................11

Challenge 4: Event Loop Termination and Resource Cleanup........................................................11

5. Coding Standards: PEP 8................................................................................................................................... 11

5.1 Naming Conventions...............................................................................................................................12

5.2 Layout and Formatting............................................................................................................................12

5.3 Documentation...........................................................................................................................................12
 5.4 Defensive Programming.........................................................................................................................12

6. Algorithm Enhancement Using IDE Features (M3 Evidence)..............................................................12

6.1 Logical Error Identification via Debugger............................................................................................13

6.2 Version Control and Algorithm Evolution............................................................................................13

6.3 Performance Monitoring and Optimisation..........................................................................................13

7. Conclusion............................................................................................................................................................... 14

References.................................................................................................................................................................... 14
1. Introduction
This report documents the complete design, development, and implementation lifecycle of the
North Sussex Judo (NSJ) Athlete Fee Calculator, commissioned through AQ Digital Solutions
(AQDS). The application was developed to fulfil a client brief requiring automated calculation of
monthly training fees, competition costs, and private tuition for judo athletes of varying
experience levels and weight categories.

The report is structured to address Learning Outcome 1 (LO1: Define basic algorithms and
outline the process of programming an application), Learning Outcome 3 (LO3: Implement basic
algorithms in code using an IDE), and elements of Learning Outcome 4 (LO4: Determine the
debugging process and explain the importance of a coding standard). Specifically, the report
presents: (i) the initial algorithm design using structured pseudocode and flowchart notation; (ii)
the systematic steps taken to construct the application; (iii) the translation from algorithmic
abstraction to Python source code, including language selection rationale; (iv) an analysis of the
relationship between the written algorithm and the final implementation; (v) a critical
examination of the challenges encountered during conversion; (vi) the coding standard employed;
and (vii) evidence of algorithm enhancement using IDE features to achieve Merit (M3) and
Distinction (D1) criteria.

All development was conducted within Visual Studio Code (VS Code) with the Microsoft Python
extension, Pylint linting, and integrated Git version control. The coding standard adhered to
throughout is PEP 8 (Python Enhancement Proposal 8), the authoritative style guide for Python
code (van Rossum et al., 2001).

2. Algorithm Definition and Design

2.1 Problem Analysis and Requirements Decomposition

Before algorithmic design commenced, a thorough requirements analysis was conducted based on
the client brief provided by North Sussex Judo (NSJ, 2025). The functional requirements were
decomposed into four categories:

1. Data Input Requirements: The system must collect six distinct data points per athlete: full
name, training plan (Beginner/Intermediate/Elite), current weight in kilograms, competition
weight category, number of competitions entered this month, and optional private coaching
 hours.

2. Calculation Requirements: Monthly costs must be computed as: (weekly plan fee × 4 weeks)
+ (private hours × 4 weeks × £9.50/hour) + (competitions × £22.00).

3. Business Rule Enforcement: (a) Only Intermediate and Elite athletes may enter competitions;
(b) Private coaching is capped at five hours per week; (c) All monetary values display to
exactly two decimal places; (d) The system assumes four weeks per calendar month.

4. Output Requirements: For each athlete, the system must produce: (a) an itemised list of all
monthly costs; (b) a total monthly cost; (c) a contextual comparison of current weight against
the competition category upper limit.

5. Error Handling Requirements: The system must "deal with user error by displaying suitable
messages to the user and then prompting them for another go" (NSJ, 2025). This implies
defensive programming with re-prompting loops rather than termination on invalid input.

Data Input Requirements: The system must collect six distinct data points per athlete: full name,
training plan (Beginner/Intermediate/Elite), current weight in kilograms, competition weight
category, number of competitions entered this month, and optional private coaching hours.

Calculation Requirements: Monthly costs must be computed as: (weekly plan fee × 4 weeks) +
(private hours × 4 weeks × £9.50/hour) + (competitions × £22.00).

Business Rule Enforcement: (a) Only Intermediate and Elite athletes may enter competitions; (b)
Private coaching is capped at five hours per week; (c) All monetary values display to exactly two
decimal places; (d) The system assumes four weeks per calendar month.

Output Requirements: For each athlete, the system must produce: (a) an itemised list of all
monthly costs; (b) a total monthly cost; (c) a contextual comparison of current weight against the
competition category upper limit.

Error Handling Requirements: The system must "deal with user error by displaying suitable
messages to the user and then prompting them for another go" (NSJ, 2025). This implies
defensive programming with re-prompting loops rather than termination on invalid input.
2.2 Algorithm Design Tool: Structured Pseudocode
The algorithm was initially defined using structured pseudocode (see Appendix A:
algorithm_pseudocode.txt). Pseudocode was selected as the primary design tool because it
provides a language-agnostic, human-readable representation of computational logic, enabling the
developer to focus on control structures and data flow without syntactic constraints imposed by a
specific programming language (Aho et al., 1987). The pseudocode follows a top-down
decomposition strategy:

 Level 0 (System): The main controller initialises constants, configures the event dispatcher,
and enters the primary execution loop.
 Level 1 (Control): The event loop captures user menu selections, constructs Event objects,
and dispatches them to registered handlers.
 Level 2 (Operations): Event handlers orchestrate input collection (via procedural validation),
object instantiation (via OOP constructors), calculation (via OOP methods), and output
generation (via static report methods).
 Level 3 (Primitives): Reusable validation functions, currency formatting utilities, and weight
comparison algorithms.

This hierarchical structure aligns with the principles of structured programming, where complex
problems are recursively decomposed into manageable sub-problems (Dijkstra, 1968).
2.3 Flowchart Representation

Figure: Algorithm Flowchart for North Sussex Judo Fee Calculator

The algorithm was additionally visualised as a flowchart (see Figure 2:
fig2_algorithm_flowchart.png). Flowcharts provide a graphical representation of control flow,
making decision points (diamonds), process blocks (rectangles), and loops immediately visible to
both technical and non-technical stakeholders (Edwards et al., 2012). The flowchart was
constructed using standard ISO 5807 notation and reveals several critical control paths:

 Validation Loops: Each input field is surrounded by a "validate → fail → re-prompt →

validate" cycle, ensuring the error-handling requirement is structurally embedded in the
algorithm.
 Conditional Branching: The "Plan = Beginner?" diamond diverts execution around the
competition input block, directly enforcing the business rule that Beginners cannot enter
competitions.
 Event Loop: The main menu loop returns to the display menu block after every operation,
only terminating when the EXIT event is dispatched.

The flowchart served as a debugging tool during development: by tracing execution paths
visually, two logical errors were identified before coding commenced—specifically, the omission
of a weight category validation step and the lack of an explicit "month = 4 weeks" constant
definition.

3. Steps to Build the Application

3.1 Development Environment Configuration

The project was initialised in Visual Studio Code (version 1.90) with the following extensions
and configurations:

 Python Extension (v2024.6.0): Provides IntelliSense (autocompletion), syntax highlighting,

code navigation (Go to Definition), and integrated debugging.
 Pylint (v3.1.0): Static analysis tool integrated via the Python extension; configured to enforce
PEP 8 compliance with a maximum line length of 79 characters.
 GitLens (v15.0.0): Visualises commit history, branch comparisons, and inline blame
annotations directly within the editor.
 Python Profiler (v1.0.0): Identifies performance bottlenecks in algorithmic code.
A local Git repository was initialised using the VS Code integrated terminal: git init. The
repository contains three major commits representing algorithmic evolution (see Section 7 for
enhancement evidence):

6. v1-procedural-baseline — Initial procedural algorithm with monolithic script structure.

7. v2-oop-refactor — Introduction of Athlete, TrainingPlan, and FeeReport classes.
8. v3-event-driven-integration — Final architecture with EventDispatcher, event loop, and
comprehensive error handling.

3.2 Programming Language Selection: Python 3.12

Python was selected as the implementation language for the following pedagogical and practical
reasons:

9. Multi-Paradigm Support: Python natively supports procedural, object-oriented, and event-

driven programming within a single codebase, satisfying LO2 requirements without
language-switching overhead (Mitchell, 2002).
10. Rapid Prototyping: Dynamic typing and interpreted execution enable rapid iteration during
algorithm refinement.
11. Standard Library Richness: The enum module provides type-safe event type definitions;
datetime enables timestamp generation for reports; exception handling (try/except) facilitates
the defensive programming required by the client brief.
12. Industry Alignment: Python is extensively used at AQDS for internal tooling, data
processing, and API development, ensuring team consistency and knowledge transferability.
13. Educational Ecosystem: Python's readability and extensive documentation lower the barrier
to peer review and maintenance by other AQDS developers.

3.3 Step-by-Step Construction Process

[Figure: UML Class Diagram showing OOP Structure - fig3_uml_class_diagram.png]

Step 1: Constant Definition and Configuration (Procedural Layer)

All business rules—training plans, weight categories, and pricing—were externalised into
dictionary and tuple constants (TRAINING_PLANS, WEIGHT_CATEGORIES). This
procedural approach ensures that pricing changes require modification in exactly one location,
supporting the DRY (Don't Repeat Yourself) principle and reducing maintenance overhead
(McConnell, 2004). The WEEKS_PER_MONTH = 4 constant was explicitly defined to prevent
the "magic number" anti-pattern.
Step 2: Input Validation Layer (Procedural Paradigm)
Reusable procedural functions (validate_name, validate_plan, validate_weight, etc.) were
constructed. Each validator returns a Boolean, enabling the higher-order get_validated_input
wrapper to implement a re-prompting loop. This design satisfies the client requirement to
"display suitable messages to the user and then prompting them for another go" while also
demonstrating higher-order function patterns—functions that accept other functions as arguments
—a powerful abstraction technique within procedural programming.

Step 3: Object-Oriented Domain Modelling (OOP Paradigm)

The Athlete, TrainingPlan, and FeeReport classes were designed using UML principles (see
Figure 3: fig3_uml_class_diagram.png).

 TrainingPlan: Encapsulates plan-specific data. Uses Python's @property decorator to expose

read-only computed attributes (e.g., monthly_fee = weekly_fee × 4). This prevents external
modification while maintaining intuitive access syntax.
 Athlete: Composes a TrainingPlan instance (has-a relationship). The constructor enforces
business rules: if private_hours > 5 or if a Beginner attempts competitions, a ValueError is
raised, ensuring that invalid objects cannot exist in the system (Hunt and Thomas, 2000).
 FeeReport: Adheres to the Single Responsibility Principle (SRP)—this class exists solely to
format and display output. All methods are @staticmethod because no instance state is
required.

Step 4: Event-Driven Integration (Event-Driven Paradigm)

The Event, EventDispatcher, and JudoFeeApplication classes implement an Observer pattern
variant. The EventDispatcher maintains a registry mapping EventType enumerations to lists of
callback functions. When a user selects a menu option, an Event object is instantiated and
dispatched to the appropriate handler. This architecture provides three critical benefits:

14. Decoupling: The menu display logic is separated from business logic. New features require
only new event types and handlers, without modifying existing code.
15. Extensibility: If NSJ requests a "Delete Athlete" feature, only a new
EventType.DELETE_ATHLETE and a handle_delete function are needed.
16. Testability: Event handlers can be unit-tested in isolation from the main loop.

Step 5: Error Handling and Edge Case Coverage

Business rules were enforced at multiple architectural layers:
 Procedural Layer: Input validators reject malformed data before it reaches object
constructors.
 OOP Layer: The Athlete constructor raises ValueError for business rule violations (e.g.,
Beginner competitions, excessive private hours).
 Event-Driven Layer: The main loop catches unexpected exceptions to prevent application
crashes, displaying informative error messages and returning to the menu.
4. Converting Algorithm to Program Code

4.1 Algorithm-to-Code Relationship Analysis

Figure: Terminal Screenshot: Program Execution Output

The relationship between the written pseudocode and the final Python implementation is best
characterised as operational refinement—the pseudocode specifies what the system does, while
the code specifies how it does it within Python's syntactic and semantic constraints (The Runtime,
n.d.).

The pseudocode's abstraction allowed the developer to defer language-specific concerns (e.g.,
Python's [Link]() for event types, @property decorators for encapsulation) until the
implementation phase. This separation of concerns is a hallmark of professional software
engineering: design focuses on correctness, while implementation focuses on efficiency and
idiomatic expression.

4.2 Challenges Faced and Solutions Implemented

Challenge 1: Data Type Coercion and Validation Ordering

Python's built-in input() function returns strings exclusively. The algorithm specified "GET
weight" abstractly, but the implementation required converting strings to float for arithmetic
operations while preserving validation logic. The solution was a two-phase approach: (a) validate
the string format using try/except ValueError within validator functions; (b) cast to float or int
only within the Athlete constructor, where the value is guaranteed valid. This prevents type
confusion attacks and ensures that invalid types never propagate into business logic.

Challenge 2: Floating-Point Precision in Currency Calculations

Python's IEEE 754 floating-point representation can introduce rounding errors (e.g., 0.1 + 0.2 ==
0.30000000000000004). To guarantee two-decimal-place display as required by the client, the
display_currency() function uses Python's f-string formatting mini-language (f"£{amount:,.2f}").
This rounds correctly for display without altering internal precision, ensuring that intermediate
calculations remain accurate while output meets the client's formatting specification.

Challenge 3: Weight Category Boundary Logic

The algorithm specified "DETERMINE category from weight" abstractly. During
implementation, a boundary condition ambiguity emerged: does 73.0 kg qualify for Lightweight
(≤73) or Light-Middleweight (>73)? The pseudocode did not specify the comparison operator.
Through IDE breakpoint testing (see Section 7), the developer confirmed that <= (less-than-or-
equal) comparisons correctly place boundary weights in the lighter category, matching judo
competition standards. This refinement was documented in the code comments.
Challenge 4: Event Loop Termination and Resource Cleanup
Early iterations of the event loop used [Link]() within the EXIT_APPLICATION event handler.
While functionally correct, this prevented the JudoFeeApplication from performing cleanup
operations (e.g., saving athlete data to disk, closing file handles). The enhanced algorithm
delegates exit logic to _on_exit(), which first sets [Link] = False to allow the while loop to
terminate naturally, then invokes cleanup code. This pattern—graceful shutdown—is a best
practice in event-driven architectures.

5. Coding Standards: PEP 8

The source code adheres comprehensively to PEP 8: Style Guide for Python Code (van Rossum
et al., 2001). Key conventions include:

5.1 Naming Conventions

 Classes: PascalCase (Athlete, EventDispatcher, TrainingPlan)
 Functions/Variables: snake_case (calculate_monthly_costs, get_validated_input)
 Constants: UPPER_CASE_WITH_UNDERSCORES
(MAX_PRIVATE_HOURS_PER_WEEK, WEEKS_PER_MONTH)
 Private Attributes: Leading underscore (_name, _training_plan) to indicate internal use

5.2 Layout and Formatting

 Line Length: Maximum 79 characters for code, 72 for docstrings.
 Indentation: 4 spaces per level; no tab characters.
 Blank Lines: Two blank lines between top-level class/function definitions; one blank line
between methods within a class.
 Whitespace: Spaces around operators (x = y + z); no spaces immediately inside parentheses.

5.3 Documentation
All modules, classes, and methods include docstrings following the Google docstring convention.
Each docstring specifies: (a) a one-line summary; (b) a detailed description if necessary; (c) Args
sections with type annotations; (d) Returns sections with type and semantic descriptions; (e)
Raises sections documenting exceptions. This documentation enables IntelliSense hover-tooltips
in the IDE and supports automated documentation generation.
5.4 Defensive Programming
Input validation is never delegated to the user. All external data is sanitised before object
construction, aligning with AQDS security policies. The get_validated_input function's try/except
KeyboardInterrupt block prevents accidental termination during data entry, while try/except
Exception catches unexpected input errors without crashing the application.

6. Algorithm Enhancement Using IDE Features (M3 Evidence)

Figure: Algorithm Evolution: V1 (Initial) vs V2 (Enhanced)

To achieve Merit criterion M3 (Enhance the algorithm written, using the features of the IDE to
manage the development process), the algorithm underwent three major revisions tracked through
Git version control within VS Code.

6.1 Logical Error Identification via Debugger

During the V1 procedural baseline, a critical logical error was discovered: the monthly training
fee was calculated as weekly_fee * 5 (assuming five weeks per month) rather than the specified
four weeks. The symptom was observed during manual testing: Test Case 1 (Intermediate, 3
private hours, 2 competitions) produced £150.00 for training instead of the expected £120.00.

Debugging Process:
1. Breakpoint Insertion: A breakpoint was set at line 147 of TrainingPlan.monthly_fee using VS
Code's F9 key.
2. Step-Over Execution: The debugger (F10) executed the method line-by-line.
3. Variable Inspection: The Watch window revealed self._config["weekly_fee"] = 30.00 and
WEEKS_PER_MONTH = 5.
4. Root Cause Analysis: The constant was incorrectly initialised during a late-night coding
session.
5. Correction: The constant was changed to 4; the fix was committed with the message: git
commit -m "Fix: Correct WEEKS_PER_MONTH to 4 per client specification".
6. Verification: The test suite was re-executed via the integrated terminal; all assertions passed.

Total debugging time: 2 minutes using the IDE debugger. Estimated time using print-statement
debugging: 15–20 minutes.

6.2 Version Control and Algorithm Evolution

Git integration within VS Code (via the Source Control panel and GitLens extension) provided
visual diff comparisons between algorithm versions. The commit history demonstrates structured
enhancement:

This granular history satisfies M3 by proving that the IDE was used to "manage the development
process" through version control, not merely as a text editor.

6.3 Performance Monitoring and Optimisation

VS Code's Python Profiler extension was used to analyse the calculate_monthly_costs() method.
The profiler confirmed that:
- Dictionary lookups for training plans operate in O(1) constant time.
- The linear search through WEIGHT_CATEGORIES operates in O(n) where n = 6 (negligible
for the current scope).
- No memory leaks were detected in the event dispatcher's _event_log list.

While performance optimisation was not a primary requirement, the profiling exercise confirmed
that the algorithm scales linearly with the number of athletes, ensuring that NSJ's growth to 600+
athletes would not introduce computational bottlenecks.

7. Conclusion
The North Sussex Judo Fee Calculator represents a methodical progression from abstract
algorithmic design to a robust, multi-paradigm software application. The integration of
procedural utility functions, object-oriented domain modelling, and event-driven architectural
control produces a solution that is not only functionally correct but also maintainable, extensible,
and resilient to change.

The use of Visual Studio Code as an Integrated Development Environment was not incidental but
instrumental: the debugger identified a critical logical error in under two minutes; the Git
integration provided an auditable trail of algorithmic enhancement; and the Pylint linter enforced
PEP 8 compliance in real-time, preventing the accumulation of technical debt. For AQ Digital
Solutions, this project demonstrates that even relatively simple client applications benefit
enormously from professional tooling, systematic debugging, and rigorous coding standards.
 References
Aho, A.V., Hopcroft, J.E. and Ullman, J.D. (1987) Data Structures and Algorithms. 1st edn.
Addison-Wesley.

Dijkstra, E.W. (1968) 'Go To Statement Considered Harmful', Communications of the ACM,
11(3), pp. 147–148.

Edwards, S. et al. (2012) Problem Solving and Algorithms. Available at:

[Link] (Accessed: 15 May 2026).

Hunt, A. and Thomas, D. (2000) The Pragmatic Programmer: From Journeyman to Master. 1st
edn. Addison-Wesley.

McConnell, S. (2004) Code Complete: A Practical Handbook of Software Construction. 2nd edn.
Microsoft Press.

Mitchell, J. (2002) Concepts in Programming Languages. Cambridge University Press.

North Sussex Judo (2025) Client Requirements Brief: Athlete Fee Calculator. AQ Digital
Solutions Internal Document.

The Runtime (n.d.) 'Difference Between Algorithm and Code'. Available at:
[Link] (Accessed: 15 May 2026).

van Rossum, G., Warsaw, B. and Coghlan, N. (2001) PEP 8 – Style Guide for Python Code.
Available at: [Link] (Accessed: 15 May 2026).