ICT340 ECA July 2026 Sample: NEA Hawker Centre Inspection Singapore

For information and reference only – not to be submitted as your own work.

This ICT340 ECA July 2026 sample is a partial model answer for the SUSS NEA hawker centre inspection case. It follows the structure of the ICT340 ECA July 2026 NEA hawker centre question and covers a representative slice: use cases, one short critique, part of the class description, the Question 3 sequence and its Python, and the strategy pattern. For the method behind each question, read our ICT340 ECA approach guide.

It is an extract, not a full submission. You still need to draw your own use case, class, sequence and state diagrams. Here they appear as tables and lists so the reasoning is easy to inspect. If you want a broader, older example of the module, see the earlier ICT340 sample; this one is narrower and tied to the 2026 case.

What this ICT340 ECA July 2026 sample covers

An extract of Q1a, Q1b in full, a partial class table for Q2a, the Q3 message table and Python, and the Q5 strategy pattern. Q4 and the diagrams themselves are left for you.

Q1a: Actors and use cases (extract)

The Appendix names three kinds of user: the hawker centre operator, the NEA officer and the stall owner. Stick to those (the notation follows the UML specification; see Object Management Group, 2017). The system itself is not an actor, and the NEA as an organisation is represented by its officers.

Two modelling choices are worth explaining in your answer. First, “Monitor stall performance” is one use case with two actors, not two copies. Second, “Assign hygiene grade” is a separate use case from “Record inspection” because the Appendix treats the grade as an outcome of the recorded results. Whether you link them with an include relationship is your call, but justify it in a sentence.

Q1b: Two inadequacies in the extract (model wording)

The question asks you to compare the claims in the given extract with the Appendix and nothing else. Do not argue from what a real NEA system might do.

Inadequacy 1: “fully automated”. The Appendix has NEA assign officers to conduct inspections, and the officer assesses cleanliness and food handling, then records several scores and remarks. Those are human judgements entered by a person. The system stores, schedules and reports; it does not perform the assessment. Calling it fully automated overstates what the Appendix describes.

Inadequacy 2: grading at the officer’s discretion. The extract says a grade may or may not be issued depending on the officer’s discretion. The Appendix says a hygiene grade (A to D) is assigned based on the inspection results, and that a stall may receive multiple grades over time. A grade follows from the results of an inspection; it is not an optional extra. On the class diagram this shows up as a mandatory end: each inspection results in a grade.

Pick the two cleanest contradictions and quote the Appendix sentence for each. The “real time” monitoring claim is a third candidate, since the Appendix talks about monitoring outcomes over time through inspection history. The multiple-stalls-per-owner claim is the weakest: the Appendix fixes one owner per stall but does not clearly cap stalls per owner, so avoid building your two marks on it.

Q2a: Class description (partial extract)

A class description lists classes, their attributes and the hierarchy (the method is covered in Tegarden et al., 2025). Keep to the Appendix. Anything you add, such as an address field on a person, needs a reason.

Why a hierarchy for User? The Appendix says operators and officers log in with a given id and name, and stall owners sign up with name, NRIC and contact number. Id and name are shared, so a generalisation is justified. Stall owners add attributes of their own, so they are a subclass, not a copy.

Why RentalAgreement is its own class. A stall may have several agreements over time (renewals, rate changes). If you stored rate as an attribute of FoodStall you would lose that history. The same logic puts Inspection and HygieneGrade in separate classes rather than as stall attributes.

A caution for Q2b. Link Inspection to HygieneGrade and FoodStall to Inspection. Do not also draw FoodStall to HygieneGrade: it is derivable by going through Inspection, and the question penalises redundant associations.

Q3a: Sequence messages (extract)

The walkthrough names the objects and the order. Your diagram’s messages should match the code you write in Q3b, line for line.

Use a loop fragment around messages 5 and 6, and show the return arrow of the final list to the caller.

Q3b: Python for the walkthrough

The orchestrating class holds the stalls. The FoodStall class does the loop, because it owns its inspections.

from datetime import date


class HygieneGrade:
    def __init__(self, grade, valid_from):
        self.grade = grade
        self.valid_from = valid_from


class Inspection:
    def __init__(self, inspected_on, scores, grade):
        self.inspected_on = inspected_on
        self.scores = scores
        self.resultsIn = grade


class FoodStall:
    def __init__(self, stall_id):
        self.stallId = stall_id
        self.hasInspections = []

    def get_grade_history(self):
        history = []
        for inspection in self.hasInspections:
            grade = inspection.resultsIn
            history.append((grade.grade, grade.valid_from))
        return history


class GradeHistoryService:
    def __init__(self, stalls):
        self.hasStalls = stalls

    def find_stall(self, stall_id):
        for stall in self.hasStalls:
            if stall.stallId == stall_id:
                return stall
        return None

    def get_grade_history(self, stall_id):
        a_stall = self.find_stall(stall_id)
        if a_stall is None:
            return []
        return a_stall.get_grade_history()

A quick check with illustrative data shows the output. With two inspections on one stall, graded B (valid from 15 January 2026) and A (valid from 15 July 2026), the call returns both tuples in order. An unknown stall id returns an empty list.

s = FoodStall("S-01")
s.hasInspections.append(Inspection(date(2026, 1, 10), [90, 85, 80],
                                   HygieneGrade("B", date(2026, 1, 15))))
s.hasInspections.append(Inspection(date(2026, 7, 10), [95, 92, 90],
                                   HygieneGrade("A", date(2026, 7, 15))))
service = GradeHistoryService([s])
print(service.get_grade_history("S-01"))
print(service.get_grade_history("X"))

Q5: Strategy pattern for the overall inspection score

The overall score can be computed in two ways: a plain average, or a weighted sum with weights 0.5, 0.3 and 0.2 across three scores. The Strategy pattern (Gamma et al., 1994) puts each rule in its own class behind a shared interface, so the Inspection context can switch rules without changing its own code.

In Python, the abstract class uses the abc module so it cannot be instantiated and subclasses must implement the method (Python Software Foundation, n.d.).

from abc import ABC, abstractmethod


class ScoringStrategy(ABC):
    @abstractmethod
    def compute(self, scores):
        """Return the overall inspection score for a list of scores."""


class StandardScoring(ScoringStrategy):
    def compute(self, scores):
        if not scores:
            raise ValueError("scores must not be empty")
        return sum(scores) / len(scores)


class WeightedScoring(ScoringStrategy):
    WEIGHTS = [0.5, 0.3, 0.2]

    def compute(self, scores):
        if len(scores) != len(self.WEIGHTS):
            raise ValueError("expected exactly 3 scores")
        return sum(w * s for w, s in zip(self.WEIGHTS, scores))


class Inspection:
    def __init__(self, scores, strategy):
        self.scores = scores
        self._strategy = strategy

    def set_strategy(self, strategy):
        self._strategy = strategy

    def overall_score(self):
        return self._strategy.compute(self.scores)

With the illustrative scores 80, 90 and 70, StandardScoring gives 80.0 and WeightedScoring gives 81.0 (0.5 x 80 + 0.3 x 90 + 0.2 x 70). Trying to create ScoringStrategy() directly raises a TypeError, and passing two scores to WeightedScoring raises a ValueError. Note the context class here is a slimmed Inspection; in your own answer, keep the same Inspection class you drew in Q2 so the diagrams agree.

In your Q5a class diagram, show a generalisation arrow from each concrete class to ScoringStrategy and an association from Inspection to ScoringStrategy. Do not draw arrows from Inspection to the concrete classes.

Further help

If you are stuck on the diagrams or the Python, our team offers ECA assignment help, computer science assignment help and programming assignment help for SUSS students. The service supplies model answers and guidance; how you use them, and your school’s rules, remain your responsibility.

About the expert

According to his profile, Eric Koh holds an MS in Computer Science with a specialisation in computer design and systems software from the National University of Singapore, and helps with computer science subjects such as data structures, algorithms, operating systems and computer networks.

References

• Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design patterns: Elements of reusable object-oriented software. Addison-Wesley.
• Object Management Group. (2017). Unified Modeling Language (UML), version 2.5.1. https://www.omg.org/spec/UML/2.5.1
• Python Software Foundation. (n.d.). abc: Abstract base classes. Python documentation. https://docs.python.org/3/library/abc.html
• Tegarden, D. P., Samuel, B., Lukyanenko, R., Dennis, A., & Wixom, B. H. (2025). Systems analysis and design: An object-oriented approach with UML (7th ed.). Wiley.