Skip to content
CampusPrep
CS-802 (D) · Object Oriented Software Engineering/Quick Revision Short Notes

Object Oriented Software Engineering (CS-802 (D)) - Unit 4 Short Notes

How unit 4 is examined

This unit covers conventional versus OO design, CRC cards, UML design diagrams and case studies; the marks sit in the conventional-versus-OO comparison and the component/deployment diagrams.

Conventional v/s OO design approach

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Medium weight</span>

Definition. <mark>Conventional (structured) design decomposes a system into functions and data flows, whereas object-oriented design decomposes it into objects that bundle data with the operations on that data.</mark>

Key points.

  1. Conventional design is function-oriented: the system is split top-down into procedures, and data is shared globally between them.
  2. OO design is object-oriented: the system is a set of collaborating objects, each hiding its own data behind methods.
  3. Conventional design is modelled with data flow diagrams, structure charts and flowcharts; OO design uses UML diagrams such as class, sequence and state chart diagrams.
  4. OO design supports inheritance and polymorphism, so new behaviour is added by extending classes instead of editing working code.
  5. Modularity in OO is by class, which is a cohesive unit; in conventional design it is by function, which is tightly coupled through shared data.
  6. Reusability and maintenance are better in OO because changes stay inside one class.
Basis Conventional (structured) Object-oriented
Philosophy Function-oriented, "what the system does" Object-oriented, "who does it"
Decomposition Top-down into functions Bottom-up into objects and classes
Data Global, shared, exposed Encapsulated, private to the object
Modelling tools DFD, structure chart UML class, sequence, state diagrams
Reusability Low, functions are tied to context High, through inheritance and composition
Maintenance Change ripples across functions Change is localised in a class
Outcome Procedures and modules Classes, objects and components

Answer frame. Open with the definition of both approaches; then draw the 7-row table above; add points 4-6 as two lines on inheritance, modularity and maintenance; close with "OO design gives more reusable and maintainable systems than conventional design".

Asked: [7 marks] (May 2022, Jun 2025) Differentiate Conventional v/s OO design approach; compare their philosophies, processes and outcomes.

Design of CRC cards

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Low weight</span>

Definition. <mark>A CRC card is an index card that records a Class, its Responsibilities and its Collaborators, used to find the design of a system by role-playing.</mark>

Key points.

  1. The card has the class name at the top, responsibilities (what the class knows or does) on the left, and collaborators (other classes it needs help from) on the right.
  2. Step 1: identify classes from the nouns in the requirements or use cases.
  3. Step 2: write each class's responsibilities from the verbs, one short phrase each.
  4. Step 3: for each responsibility, list the collaborating classes that supply the missing help.
  5. Step 4: walk through a scenario with the team, moving cards to test and refine the design.
Class: Account
Responsibilities Collaborators
Hold balance<br>Debit and credit Transaction<br>Customer

Asked: [7 marks] (May 2022) What is a CRC card? How do you design it? Explain in detail.

Class diagram

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>A class diagram is a UML static structure diagram that shows classes with their attributes and operations, and the relationships between them.</mark>

Key points.

  1. Each class is a three-compartment box: name, attributes, operations, with visibility marks + public, - private, # protected.
  2. Relationships shown are association, aggregation, composition, generalization (inheritance) and dependency, with multiplicity such as 1..* on the ends.
  3. It is the main design diagram, and code skeletons are generated from it.

Interaction Diagram

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Low weight</span>

Definition. <mark>An interaction diagram is a UML behavioural diagram that shows how objects exchange messages to carry out one use case or operation.</mark>

Key points.

  1. Behavioural modelling describes how a system acts over time, and interaction diagrams do this at object level.
  2. A sequence diagram arranges objects across the top with vertical lifelines and shows messages as horizontal arrows in time order from top to bottom, so it emphasises time.
  3. A collaboration (communication) diagram shows the same objects as nodes with links and numbered messages (1, 1.1, 2), so it emphasises structural organization.
  4. The two are semantically equivalent and convertible; sequence suits time flow, collaboration suits object links.
  5. Example, ATM withdrawal: Customer sends 1: insertCard to ATM, ATM sends 2: verifyPIN to Bank, Bank returns 3: ok, and ATM sends 4: dispense.

<figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u4-01" viewBox="0 0 424 80" width="424" height="80" role="img" aria-label="Collaboration diagram, ATM withdrawal (C = Customer, A = ATM, B = Bank; numbers give message order)"><style>#dsfig-u4-01 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u4-01 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u4-01 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u4-01 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u4-01 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u4-01 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u4-01 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u4-01 .t{fill:#16181D;font-weight:500}#dsfig-u4-01 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u4-01 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u4-01 .dot{fill:#16181D}#dsfig-u4-01 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u4-01 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u4-01 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u4-01 .ah{fill:#454C5A}#dsfig-u4-01 .ah.hi{fill:#2340B8}#dsfig-u4-01 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u4-01 .wl .t{font-size:12px;font-weight:700}#dsfig-u4-01 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u4-01 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u4-01 .e{stroke:#B1B7C3}html.dark #dsfig-u4-01 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u4-01 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u4-01 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u4-01 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u4-01 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u4-01 .t{fill:#E6E8ED}html.dark #dsfig-u4-01 .t.inv{fill:#0F1115}html.dark #dsfig-u4-01 .kd{stroke:#E6E8ED}html.dark #dsfig-u4-01 .dot{fill:#E6E8ED}html.dark #dsfig-u4-01 .ann{fill:#8FA3FF}html.dark #dsfig-u4-01 .lbl{fill:#858D9C}html.dark #dsfig-u4-01 .ptr{fill:#8FA3FF}html.dark #dsfig-u4-01 .ah{fill:#B1B7C3}html.dark #dsfig-u4-01 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u4-01 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u4-01 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u4-01 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah7" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah" d="M0,1 L9,5 L0,9 z"/></marker><marker id="ahh7" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah hi" d="M0,1 L9,5 L0,9 z"/></marker></defs><path class="e" d="M57.8,46.6 Q126,72 192.3,47.3" marker-end="url(#ah7)"/><path class="e" d="M229.8,46.6 Q298,72 364.3,47.3" marker-end="url(#ah7)"/><path class="e" d="M366.2,33.4 Q298,8 231.7,32.7" marker-end="url(#ah7)"/><path class="e" d="M194.2,33.4 Q126,8 59.7,32.7" marker-end="url(#ah7)"/><g class="wl"><rect x="98.4" y="50.5" width="54.3" height="18" rx="9"/><text class="t" x="125.5" y="59.5" dy=".35em" text-anchor="middle">1.card</text></g><g class="wl"><rect x="263.2" y="50.5" width="68.7" height="18" rx="9"/><text class="t" x="297.5" y="59.5" dy=".35em" text-anchor="middle">2.verify</text></g><g class="wl"><rect x="278.1" y="11.5" width="40.8" height="18" rx="9"/><text class="t" x="298.5" y="20.5" dy=".35em" text-anchor="middle">3.ok</text></g><g class="wl"><rect x="99.3" y="11.5" width="54.3" height="18" rx="9"/><text class="t" x="126.5" y="20.5" dy=".35em" text-anchor="middle">4.cash</text></g><circle class="n" cx="40" cy="40" r="18"/><text class="t" x="40" y="40" dy=".35em" text-anchor="middle">C</text><circle class="n" cx="212" cy="40" r="18"/><text class="t" x="212" y="40" dy=".35em" text-anchor="middle">A</text><circle class="n" cx="384" cy="40" r="18"/><text class="t" x="384" y="40" dy=".35em" text-anchor="middle">B</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">Collaboration diagram, ATM withdrawal (C = Customer, A = ATM, B = Bank; numbers give message order)</figcaption></figure>

Asked: [7 marks] (Jun 2025) What are interaction diagrams in UML, and how do they contribute to behavioral modeling? Discuss sequence and collaboration diagrams and their significance.

State chart Diagram

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Low weight</span>

Definition. <mark>A state chart diagram shows the states an object passes through during its life, and the events, guards and actions that cause transitions between them.</mark>

Key points.

  1. It has an initial state (solid dot), states (rounded boxes), transitions (arrows labelled event [guard] / action) and a final state (bull's eye).
  2. For the Course and Registration System, a Course object moves Open, then Closed when full or on the deadline, then Cancelled or Completed.
  3. A Registration object moves Pending, then Confirmed when the fee is paid and a seat is free, then Dropped or Completed.
  4. Guards such as [seats available] decide whether a transition fires, and actions such as / send confirmation run on it.

<figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u4-02" viewBox="0 0 467 252" width="467" height="252" role="img" aria-label="Registration state chart (I initial, P Pending, C Confirmed, D Dropped, F final)"><style>#dsfig-u4-02 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u4-02 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u4-02 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u4-02 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u4-02 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u4-02 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u4-02 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u4-02 .t{fill:#16181D;font-weight:500}#dsfig-u4-02 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u4-02 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u4-02 .dot{fill:#16181D}#dsfig-u4-02 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u4-02 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u4-02 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u4-02 .ah{fill:#454C5A}#dsfig-u4-02 .ah.hi{fill:#2340B8}#dsfig-u4-02 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u4-02 .wl .t{font-size:12px;font-weight:700}#dsfig-u4-02 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u4-02 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u4-02 .e{stroke:#B1B7C3}html.dark #dsfig-u4-02 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u4-02 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u4-02 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u4-02 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u4-02 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u4-02 .t{fill:#E6E8ED}html.dark #dsfig-u4-02 .t.inv{fill:#0F1115}html.dark #dsfig-u4-02 .kd{stroke:#E6E8ED}html.dark #dsfig-u4-02 .dot{fill:#E6E8ED}html.dark #dsfig-u4-02 .ann{fill:#8FA3FF}html.dark #dsfig-u4-02 .lbl{fill:#858D9C}html.dark #dsfig-u4-02 .ptr{fill:#8FA3FF}html.dark #dsfig-u4-02 .ah{fill:#B1B7C3}html.dark #dsfig-u4-02 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u4-02 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u4-02 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u4-02 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah8" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah" d="M0,1 L9,5 L0,9 z"/></marker><marker id="ahh8" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah hi" d="M0,1 L9,5 L0,9 z"/></marker></defs><path class="e" d="M59,126 L148,126" marker-end="url(#ah8)"/><path class="e" d="M188,126 L277,126" marker-end="url(#ah8)"/><path class="e" d="M313.8,115.5 L409.5,51.6" marker-end="url(#ah8)"/><path class="e" d="M313.8,136.5 L409.5,200.4" marker-end="url(#ah8)"/><path class="e" d="M427,59 L427,191" marker-end="url(#ah8)"/><g class="wl"><rect x="77.4" y="117" width="54.3" height="18" rx="9"/><text class="t" x="104.5" y="126" dy=".35em" text-anchor="middle">create</text></g><g class="wl"><rect x="195.6" y="117" width="75.9" height="18" rx="9"/><text class="t" x="233.5" y="126" dy=".35em" text-anchor="middle">pay[seat]</text></g><g class="wl"><rect x="342.1" y="74" width="40.8" height="18" rx="9"/><text class="t" x="362.5" y="83" dy=".35em" text-anchor="middle">drop</text></g><g class="wl"><rect x="328.2" y="160" width="68.7" height="18" rx="9"/><text class="t" x="362.5" y="169" dy=".35em" text-anchor="middle">complete</text></g><circle class="n" cx="40" cy="126" r="18"/><text class="t" x="40" y="126" dy=".35em" text-anchor="middle">I</text><circle class="n" cx="169" cy="126" r="18"/><text class="t" x="169" y="126" dy=".35em" text-anchor="middle">P</text><circle class="n" cx="298" cy="126" r="18"/><text class="t" x="298" y="126" dy=".35em" text-anchor="middle">C</text><circle class="n" cx="427" cy="40" r="18"/><text class="t" x="427" y="40" dy=".35em" text-anchor="middle">D</text><circle class="n" cx="427" cy="212" r="18"/><text class="t" x="427" y="212" dy=".35em" text-anchor="middle">F</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">Registration state chart (I initial, P Pending, C Confirmed, D Dropped, F final)</figcaption></figure>

Asked: [7 marks] (May 2022) Compose the state chart diagram for Course and Registration System.

Implementation Diagram: Component and deployment Diagram

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Medium weight</span>

Definition. <mark>A component is a replaceable, executable physical part of a system that hides its contents and exposes its behaviour through interfaces.</mark>

Key points.

  1. A component diagram is the implementation view: it shows components, their provided and required interfaces, and the dependencies between them.
  2. A provided interface (lollipop) is a service the component offers; a required interface (socket) is a service it needs from another component.
  3. A component realizes one or more interfaces, and other components depend only on the interface, not on the internals.
  4. Organization is shown by grouping components in packages or layers, and dependencies as dashed arrows toward the supplier.
  5. A deployment diagram shows nodes (hardware such as server, client, database machine), the artifacts deployed on them and the communication links between nodes.
Basis Component Class
Nature Physical implementation unit Logical abstraction
Contents Groups many classes Attributes and operations
Access Only through its interfaces Direct through public members
Existence At run time, replaceable file or module Design-time concept

<figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u4-03" viewBox="0 0 424 80" width="424" height="80" role="img" aria-label="Component diagram (UI = Web UI, Ord = Order Service, DB = Data Access; edge label is the interface used)"><style>#dsfig-u4-03 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u4-03 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u4-03 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u4-03 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u4-03 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u4-03 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u4-03 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u4-03 .t{fill:#16181D;font-weight:500}#dsfig-u4-03 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u4-03 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u4-03 .dot{fill:#16181D}#dsfig-u4-03 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u4-03 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u4-03 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u4-03 .ah{fill:#454C5A}#dsfig-u4-03 .ah.hi{fill:#2340B8}#dsfig-u4-03 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u4-03 .wl .t{font-size:12px;font-weight:700}#dsfig-u4-03 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u4-03 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u4-03 .e{stroke:#B1B7C3}html.dark #dsfig-u4-03 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u4-03 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u4-03 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u4-03 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u4-03 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u4-03 .t{fill:#E6E8ED}html.dark #dsfig-u4-03 .t.inv{fill:#0F1115}html.dark #dsfig-u4-03 .kd{stroke:#E6E8ED}html.dark #dsfig-u4-03 .dot{fill:#E6E8ED}html.dark #dsfig-u4-03 .ann{fill:#8FA3FF}html.dark #dsfig-u4-03 .lbl{fill:#858D9C}html.dark #dsfig-u4-03 .ptr{fill:#8FA3FF}html.dark #dsfig-u4-03 .ah{fill:#B1B7C3}html.dark #dsfig-u4-03 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u4-03 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u4-03 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u4-03 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah9" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah" d="M0,1 L9,5 L0,9 z"/></marker><marker id="ahh9" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah hi" d="M0,1 L9,5 L0,9 z"/></marker></defs><path class="e" d="M59,40 L191,40" marker-end="url(#ah9)"/><path class="e" d="M231,40 L363,40" marker-end="url(#ah9)"/><g class="wl"><rect x="98.9" y="31" width="54.3" height="18" rx="9"/><text class="t" x="126" y="40" dy=".35em" text-anchor="middle">IOrder</text></g><g class="wl"><rect x="274.5" y="31" width="47.1" height="18" rx="9"/><text class="t" x="298" y="40" dy=".35em" text-anchor="middle">IData</text></g><circle class="n" cx="40" cy="40" r="18"/><text class="t" x="40" y="40" dy=".35em" text-anchor="middle">UI</text><circle class="n" cx="212" cy="40" r="18"/><text class="t" x="212" y="40" dy=".35em" text-anchor="middle">Ord</text><circle class="n" cx="384" cy="40" r="18"/><text class="t" x="384" y="40" dy=".35em" text-anchor="middle">DB</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">Component diagram (UI = Web UI, Ord = Order Service, DB = Data Access; edge label is the interface used)</figcaption></figure>

Answer frame. For the definition question: define component, give the table, then explain interface relation (points 2-3). For the purpose question: define the diagram as the implementation view, draw the figure, then organization (4), and deployment (5); close with an example of an online shop.

Asked: [7 marks] (May 2022) Define component. What are the differences between components and classes? How are component and interface related? Asked: [7 marks] (Jun 2025) Explain the purpose of component diagrams and how they illustrate the organization and dependencies of components in a system.

Illustrative Case Studies like ATM, Payroll, Course and Registration System

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Low weight</span>

Definition. <mark>A case study applies OO design to a real system by finding its classes, relationships and behaviour, then modelling them in UML.</mark>

Key points.

  1. Payroll classes are Employee (with subclasses Permanent and Contract), Payroll, Salary, Department and Attendance.
  2. Encapsulation keeps salary data private behind methods; inheritance lets Permanent and Contract employees share Employee and override calculateSalary(); association links Department to Employee (1 to many) and Employee to Attendance.
  3. The Salary state chart moves Draft, then Calculated, then Approved, then Paid, ending in the final state.
  4. The activity diagram flows: read attendance, calculate salary, deduct tax, approve, generate payslip, transfer payment.
  5. For ATM the classes are Customer, Account, Card, Transaction and Bank; for Course Registration they are Student, Course, Registration and Faculty.

Asked: [7 marks] (Jun 2025) Discuss the design of a payroll system using object-oriented principles: primary classes, and its behavior through state chart and activity diagrams.

Last-minute revision

  • Conventional design is function-oriented and top-down; OO design is object-oriented and bottom-up.
  • CRC stands for Class, Responsibility, Collaborator.
  • A CRC card is designed in four steps: classes, responsibilities, collaborators, scenario walkthrough.
  • A class box has name, attributes and operations compartments.
  • Sequence diagram emphasises time; collaboration diagram emphasises object links.
  • A state chart has initial dot, states, transitions (event [guard] / action) and final bull's eye.
  • Provided interface is a lollipop; required interface is a socket.
  • A component diagram is the implementation view; a deployment diagram shows nodes.
  • Payroll classes: Employee, Payroll, Salary, Department, Attendance.

Memory hooks

  • CRC: "Class Really Cooperates".
  • Sequence goes down with time, collaboration goes around with numbers.
  • Lollipop gives, socket takes.
  • Component is a "box of classes", node is a "box of hardware".

Coverage checklist

  • Conventional v/s OO design approach: Q1 (May 2022, Jun 2025)
  • Design of CRC cards: Q2
  • Class diagram: no past question
  • Interaction Diagram: Q6
  • State chart Diagram: Q7
  • Implementation Diagram: Component and deployment Diagram: Q4, Q5
  • Illustrative Case Studies like ATM, Payroll, Course and Registration System: Q3
Go to where you left off?

Quick Add to Notes

Save questions, your own notes and screenshots into notes filed by unit. It takes a free account.

Create free account

Have an account? Log in