How to Pass ICT2622: Object-Oriented Analysis (2025 Guide)

ICT2622 acts as the bridge between “Requirements” (what the client wants) and “Code” (what the programmer writes). If you treat this module like a theory subject, you will fail. It is a practical skill module where you communicate using diagrams, not essays.

The exam usually gives you a 1-page case study (e.g., “A Hospital Management System”) and asks you to draw specific UML diagrams. This guide breaks down the “Big 3” diagrams you must master.

1. Requirements Analysis (The Foundation)

Before you draw, you must list what the system needs to do.

Functional Requirements: These are the verbs. What does the system do? (e.g., “Calculate Bill,” “Register Patient”).
Non-Functional Requirements: These are the adjectives. How well does it do it? (e.g., “Secure,” “Fast,” “Reliable”).
Tutor Tip: Use the FURPS+ acronym to remember these: Functionality, Usability, Reliability, Performance, Supportability.

2. The Use Case Diagram (The “Who” and “What”)

This diagram shows who interacts with the system. It is the simplest diagram but has tricky rules.

Actors: These are the stick figures. They can be humans (User) or external systems (Bank API).
Relationships:
- Association: A solid line connecting an Actor to a Use Case.
- Include (<<include>>): Used when a behavior is mandatory and shared (e.g., “Login” is included in “Check Balance”).
- Extend (<<extend>>): Used for optional behavior (e.g., “Print Receipt” extends “Withdraw Cash”).
The Trap: Students often point the arrow the wrong way. Remember: The base case points to the included case.

3. The Class Diagram (The Structure)

This is the most important diagram in Object-Oriented Analysis. It maps directly to your C++ or Java classes.

The Box

It has three sections:

Class Name (Top).
Attributes (Middle): The variables (e.g., - name: String). Note the minus sign for private.
Operations (Bottom): The methods (e.g., + register(): void). Note the plus sign for public.

Relationships

Association: A simple line (Student takes Module).
Aggregation (Open Diamond): “Has-a” relationship (Car has Tires). The parts can exist independently.
Composition (Filled Diamond): Strong ownership (House has Rooms). If the House is destroyed, the Rooms are destroyed.
Multiplicity: You must label the lines (e.g., 1..*). If you leave these out, you lose marks.

4. The Sequence Diagram (The Interaction)

This diagram shows time. It explains the order in which messages are passed between objects to complete a task.

Lifelines: The dashed vertical lines hanging from each object.
Activation Bars: The thin rectangles on the lifeline. They show when an object is “busy” working.
Messages:
- Synchronous (Solid Arrow): The sender waits for an answer (e.g., a function call).
- Reply (Dashed Arrow): The answer coming back (e.g., return true).
Common Mistake: Do not put logic (loops/if-statements) inside the message text. Use “Interaction Frames” (like alt for if/else or loop for loops) around the messages.

Decksh’s Top 3 Tips for a Distinction

Tip 1: Consistency is Key

The examiner checks if your diagrams “talk” to each other.

If you have a class called Student in your Class Diagram, the lifeline in your Sequence Diagram must also be named Student.
If a message in the Sequence Diagram is login(), then the Student class in the Class Diagram must have a login() method.

Tip 2: Don’t Invent Requirements

Read the case study carefully.

If the scenario says “The manager approves the loan,” you must have an Actor called “Manager” and a Use Case called “Approve Loan.”
Do not add features that weren’t asked for (like “Reset Password”) just because you think they should be there. Stick to the script.

Tip 3: Master the Arrowheads

In UML, the shape of the arrowhead changes the meaning entirely.

Open Triangle: Generalization (Inheritance).
Open Diamond: Aggregation.
Filled Diamond: Composition.
Stick Arrow: Association/Navigation.
Using the wrong arrow is like using the wrong word in a sentence.

Conclusion

ICT2622 is about precision. It forces you to think before you build. The best way to study is to take past exam papers, read the scenario, and draw the diagrams on blank paper. If you can translate a text story into a Class Diagram with correct multiplicity, you will pass.

Good luck!