Structuring Your IA

IA Preparation: This page brings together everything from the OOP and JavaFX pages into a practical guide for planning, building, and organising your Internal Assessment project.

Table of Contents

1. Why This Page Exists
2. Planning Your Classes
   1. Start with the Problem, Not the GUI
   2. The Three-Layer Architecture
   3. Example: Recipe Manager
3. What Examiners Look For
   1. Criterion A: Planning (6 marks)
   2. Criterion B: Solution Overview (6 marks)
   3. Criterion C: Development (12 marks – highest weight)
   4. Criterion D: Functionality and Extensibility (6 marks)
   5. Criterion E: Evaluation (6 marks)
4. Building Incrementally
   1. The Right Order
5. Demonstrating OOP
   1. Encapsulation
   2. Collections of Objects
   3. MVC Separation
   4. Aggregation
6. Common IA Pitfalls
   1. Scope: Too Big vs Too Small
   2. Code You Cannot Explain
   3. Missing Validation
7. IA Structure Checklist
8. Quick Check
9. Code Completion
10. Spot the Error
11. Practice Exercises
    1. Core
    2. Extension
    3. Challenge
12. Connections

---

Why This Page Exists

You have learned the individual pieces: classes, encapsulation, MVC, JavaFX, FXML, file I/O. This page shows how to put them all together into a well-structured IA project that:

• Meets the examiner’s expectations for Criteria A-E
• Is modular enough to develop and debug incrementally
• Demonstrates genuine OOP understanding (not just a GUI wrapper around procedural code)

---

Planning Your Classes

Start with the Problem, Not the GUI

Many students jump straight to building the interface. Instead, start with the data:

1. What objects exist in the problem? (students, books, recipes, products…)
2. What attributes does each object have?
3. What actions can be performed on each object?
4. What collections are needed? (a list of students, an inventory of products…)

Only after answering these questions should you think about the interface.

The Three-Layer Architecture

Every well-structured IA has at least these layers:

┌─────────────────────────────────────────────────┐
│                   Application                    │
│            (creates and wires everything)         │
├─────────────────────────────────────────────────┤
│                   Controller(s)                  │
│         (event handlers, coordinates M↔V)         │
├──────────────────────┬──────────────────────────┤
│       Model(s)       │          View(s)          │
│   data + logic +     │     FXML + UI controls    │
│   file I/O           │                           │
└──────────────────────┴──────────────────────────┘

Example: Recipe Manager

Step 1 – Identify the objects:

Object	Attributes	Key Methods
Recipe	name, category, servings, ArrayList of ingredients, instructions	getters, setters, toString
Ingredient	name, quantity, unit	getters, toString
RecipeList	ArrayList of Recipe objects	add, remove, findByName, filterByCategory, sortByName

Step 2 – Plan the files:

src/
├── RecipeApp.java              // Application
├── model/
│   ├── Recipe.java             // data class
│   ├── Ingredient.java         // data class
│   ├── RecipeList.java         // collection + business logic
│   └── RecipeFileHandler.java  // CSV load/save
├── controller/
│   ├── MainController.java     // main screen logic
│   └── AddRecipeController.java // add/edit form logic
└── view/
    ├── main-view.fxml          // main screen layout
    └── add-recipe-view.fxml    // add/edit form layout

Step 3 – Plan the screens:

Screen	Purpose	Key Controls
Main	Display recipe list, search, filter	ListView, search TextField, category ComboBox, buttons
Add/Edit	Enter or modify a recipe	TextFields for name/servings, TextArea for instructions, add ingredients

---

What Examiners Look For

Criterion A: Planning (6 marks)

• Clearly defined problem with a real client
• Success criteria (specific, measurable features the client wants)
• Proposed solution explaining why a computer-based solution is appropriate

Criterion B: Solution Overview (6 marks)

• Record of tasks showing development was planned, not random
• UML class diagrams or other design documents
• Explanation of how the solution was developed

Criterion C: Development (12 marks – highest weight)

This is where your code structure matters most:

What examiners want	How to demonstrate it
Complex programming techniques	OOP with multiple classes, encapsulation, collections of objects
Modular design	MVC separation, methods with single responsibilities
Good coding practices	Meaningful names, validation, error handling
Evidence of understanding	Code that you wrote and can explain, not copied from tutorials

Common mistakes that cost marks:

• Writing one massive class instead of multiple focused classes
• No encapsulation (public fields instead of private + getters/setters)
• GUI code mixed with data logic (no MVC separation)
• No input validation (accepting any input without checking)
• No file persistence (data lost when the app closes)

Criterion D: Functionality and Extensibility (6 marks)

• The product works as described in the success criteria
• The solution is extensible – new features could be added without rewriting everything
• MVC makes extensibility natural: new features follow the Model-View-Controller pattern

Criterion E: Evaluation (6 marks)

• Test the product against the success criteria from Criterion A
• Get client feedback on whether the product meets their needs
• Identify improvements that could be made

---

Building Incrementally

The Right Order

Do not try to build everything at once. Follow this sequence:

Phase 1 – Model only (no GUI)

1. Write your data classes (e.g., Recipe, Ingredient)
2. Write your collection class (e.g., RecipeList)
3. Test them with a simple main method – add objects, search, print
4. Only move on when your Model works correctly

Phase 2 – File I/O

1. Write the file handler (save and load)
2. Test save/load with your main method
3. Verify data survives a “close and reopen” cycle

Phase 3 – Basic GUI

1. Create the main FXML layout
2. Write the Controller with event handlers
3. Wire everything in the Application class
4. Test: can you add, view, and save data through the GUI?

Phase 4 – Additional screens

1. Add popup windows for add/edit forms
2. Add search, filter, sort features
3. Add validation and error feedback

Phase 5 – Polish

1. Handle edge cases (empty input, missing file, duplicate names)
2. Add auto-save on close
3. Test with your client

Build the Model first. If your data classes do not work, the GUI will not help.

---

Demonstrating OOP

Examiners want to see that you understand OOP, not just that you built a GUI. Here is what “genuine OOP” looks like in an IA:

Encapsulation

// Good: private fields with validated setters
public class Recipe {
    private String name;
    private int servings;

    public void setServings(int servings) {
        if (servings < 1) {
            throw new IllegalArgumentException("Servings must be at least 1");
        }
        this.servings = servings;
    }
}

Collections of Objects

// Good: a dedicated class managing a collection
public class RecipeList {
    private ArrayList<Recipe> recipes;

    public ArrayList<Recipe> filterByCategory(String category) {
        ArrayList<Recipe> results = new ArrayList<>();
        for (int i = 0; i < recipes.size(); i++) {
            if (recipes.get(i).getCategory().equals(category)) {
                results.add(recipes.get(i));
            }
        }
        return results;
    }
}

MVC Separation

// Good: Controller handles the event, delegates to Model
@FXML
private void handleSearch() {
    String query = searchField.getText().trim();
    if (query.isEmpty()) {
        refreshDisplay(model.getAll());  // show all
    } else {
        refreshDisplay(model.filterByCategory(query));
    }
}

Aggregation

// Good: Recipe HAS ingredients (composition/aggregation)
public class Recipe {
    private String name;
    private ArrayList<Ingredient> ingredients;

    public void addIngredient(Ingredient i) {
        ingredients.add(i);
    }
}

---

Common IA Pitfalls

Scope: Too Big vs Too Small

Too big: A full school management system with student records, grades, attendance, scheduling, and reports. You will run out of time and submit incomplete work.

Too small: A basic calculator or unit converter. Not enough complexity to demonstrate OOP.

Just right: A focused app that manages one type of data with add/edit/delete/search/sort and file persistence. Examples: recipe manager, book catalogue, fitness tracker, inventory system, quiz maker.

Aim for 3-5 model classes, 2-3 screens, and 3-4 meaningful features (search, filter, sort, etc.).

Code You Cannot Explain

If you copied code from a tutorial and cannot explain every line, do not include it. Examiners may ask you to explain your code in a follow-up interview. If you cannot explain it, you lose marks.

Write code you understand. It is better to have a simpler solution you can explain fully than a complex one you copied.

Missing Validation

Every text input should be validated:

• Is it empty?
• Is it the right type (number, date, etc.)?
• Is it within acceptable range?
• Is it a duplicate of an existing entry?

Validation is easy to add and demonstrates good coding practices.

---

IA Structure Checklist

Before submitting, verify your project meets these structural requirements:

Category	Check
Model	At least 2 data classes with private fields and getters/setters
Model	At least 1 collection class with add/remove/search methods
Model	File I/O for persistence (load on start, save on close)
Model	Input validation in constructors or setters
View	FXML files separate from Java logic
View	At least 2 screens (main + add/edit popup)
Controller	Event handlers in Controller classes, not in View or Model
Controller	Error messages displayed to the user (status label or alerts)
MVC	Model has no javafx.* imports
MVC	View has no business logic (if statements about data)
MVC	Controllers wire Model and View together
General	Meaningful variable and method names
General	No massive 200+ line methods – break logic into helper methods
General	Comments only where the logic is not obvious from the code

---

Quick Check

Q1. When building an IA project, what should you develop first?

Q2. Which IA criterion carries the most marks and focuses on code quality?

Q3. Which project scope is most appropriate for an IA?

Q4. How can you verify that your MVC separation is correct?

Q5. Why does MVC architecture help with Criterion D (Extensibility)?

---

Code Completion

Complete the class planning for an IA project.

Fill in the blanks: Identify the correct MVC role for each class in a Book Catalogue IA.

// Book.java stores title, author, genre, rating
// Role: 

// BookList.java manages an ArrayList of Books (add, search, sort)
// Role: 

// main-view.fxml defines the layout with a ListView and buttons
// Role: 

// MainController.java handles button clicks and updates the display
// Role: 

// BookFileHandler.java reads/writes Books to a CSV file
// Role: 

---

Spot the Error

A student’s IA has this class structure. One class violates MVC principles.

Bug Hunt: Find the MVC violation in this Model class.

1import javafx.scene.control.Alert; 2 3public class Product { 4 private String name; 5 private double price; 6 7 public Product(String name, double price) { 8 if (price < 0) { 9 Alert a = new Alert(Alert.AlertType.ERROR); 10 a.setContentText("Price cannot be negative"); 11 a.showAndWait(); 12 return; 13 } 14 this.name = name; 15 this.price = price; 16 } 17}

Pick the correct fix:

---

Practice Exercises

Core

1. Class planning – Choose an IA topic (e.g., a sports team manager, a movie collection, a study planner). List 2-3 model classes with their attributes and methods. Draw a UML class diagram for each.

2. Development sequence – For the same project, write out the 5 development phases (Model, File I/O, Basic GUI, Additional Screens, Polish) with specific tasks for each phase.

Extension

1. Build a prototype – Implement the Model layer (data classes + collection class + file handler) for your planned IA. Test it with a simple main method that adds sample data, saves to file, loads it back, and prints the results. No GUI needed.

2. Add the GUI – Take your working Model from exercise 3 and build a basic GUI with one main screen (list view + add button). Wire it with a Controller using MVC. Add file persistence on start and close.

Challenge

1. Complete mini-IA – Build a complete, small-scale IA project with:
   • At least 2 model classes with encapsulation and validation
   • A collection class with search and sort methods
   • CSV file persistence
   • A main screen and at least one popup form
   • MVC architecture with FXML views
   • Input validation and error feedback

   This exercise simulates the full IA development process. Aim for a project you could complete in 2-3 coding sessions.

---

Connections

• Prerequisites: Classes and Objects, Encapsulation – Model design
• Prerequisites: Aggregation – collections of objects in the Model
• Prerequisites: UML Class Diagrams – planning your classes
• Prerequisites: JavaFX Basics – controls and event handling
• Prerequisites: MVC Architecture – separating concerns
• Prerequisites: FXML and Controllers – View layer
• Prerequisites: Multi-Window Apps – multiple screens
• Prerequisites: File I/O in Apps – data persistence
• Related: OOP Method Patterns – common method patterns used in IA code