Object Oriented Software Engineering (CS-802 (D)) Notes

How unit 3 is examined

UML notation, modelling and relationships carry the most marks; use case, activity diagram, requirement analysis and stereotypes are single 4-7 mark questions.

Notations

<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. UML (Unified Modeling Language) is the standard graphical language for visualising, specifying, constructing and documenting the artefacts of a software system. UML notations are its standard symbols and text conventions for drawing those models.

Key points.

A model is a simplified abstraction of the system, built to understand it before coding; modelling manages complexity, gives visualisation and lets stakeholders communicate.
The four principles of modelling: the choice of model shapes how the problem is solved; every model can be expressed at different levels of precision; the best models are connected to reality; no single model is enough, so a set of nearly independent models is used.
UML serves visualising, specifying, constructing and documenting a system, and its common notation lets customers, analysts, designers and testers read the same diagram.
Graphical notations are the symbols: a rectangle for a class, a stick figure for an actor, an oval for a use case, a rounded box for an activity, a box with tabs for a component.
Textual notations add detail inside the graphics: names, attributes, operations, multiplicity such as 1..*, and constraints in braces such as {ordered}.
Structural diagrams (class, object, component, deployment) show what the system is; behavioural diagrams (use case, activity, sequence, state) show what it does.

<mark>UML is a standard language of graphical and textual notations used to visualise, specify, construct and document a software system.</mark>

Answer frame. Open with the UML definition; list its four purposes; give the class, object and component symbols; for modelling, add the four principles; close with UML as the common language between stakeholders.

Asked: [5 marks] (May 2022) Write short notes on Notations. Asked: [7 marks] (May 2022) Explain the importance of modeling and its principles. Asked: [7 marks] (Jun 2025) What is UML, and what purpose does it serve in software development? Discuss its importance in facilitating communication among stakeholders in a project.

Relationships

Definition. A relationship in UML is a connection between two model elements, usually classes, showing how they are linked and how their objects interact.

Diagram. <figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u3-01" viewBox="0 0 424 252" width="424" height="252" role="img" aria-label="Cus Customer, Ord Order (association); Ln Line item (composition, filled diamond); Dep Report depends on Acc Account (dashed arrow); Sav Savings inherits Acc (hollow triangle)"><style>#dsfig-u3-01 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u3-01 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u3-01 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u3-01 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u3-01 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u3-01 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u3-01 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u3-01 .t{fill:#16181D;font-weight:500}#dsfig-u3-01 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u3-01 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u3-01 .dot{fill:#16181D}#dsfig-u3-01 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u3-01 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u3-01 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u3-01 .ah{fill:#454C5A}#dsfig-u3-01 .ah.hi{fill:#2340B8}#dsfig-u3-01 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u3-01 .wl .t{font-size:12px;font-weight:700}#dsfig-u3-01 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u3-01 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u3-01 .e{stroke:#B1B7C3}html.dark #dsfig-u3-01 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u3-01 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u3-01 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u3-01 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u3-01 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u3-01 .t{fill:#E6E8ED}html.dark #dsfig-u3-01 .t.inv{fill:#0F1115}html.dark #dsfig-u3-01 .kd{stroke:#E6E8ED}html.dark #dsfig-u3-01 .dot{fill:#E6E8ED}html.dark #dsfig-u3-01 .ann{fill:#8FA3FF}html.dark #dsfig-u3-01 .lbl{fill:#858D9C}html.dark #dsfig-u3-01 .ptr{fill:#8FA3FF}html.dark #dsfig-u3-01 .ah{fill:#B1B7C3}html.dark #dsfig-u3-01 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u3-01 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u3-01 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u3-01 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah4" 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="ahh4" 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 L193,40"/><path class="e" d="M231,40 L363,40" marker-end="url(#ah4)"/><path class="e" d="M59,212 L191,212" marker-end="url(#ah4)"/><path class="e" d="M365,212 L233,212" marker-end="url(#ah4)"/><g class="wl"><rect x="105.6" y="31" width="40.8" height="18" rx="9"/><text class="t" x="126" y="40" dy=".35em" text-anchor="middle">1..*</text></g><g class="wl"><rect x="281.2" y="31" width="33.6" height="18" rx="9"/><text class="t" x="298" y="40" dy=".35em" text-anchor="middle">has</text></g><g class="wl"><rect x="105.6" y="203" width="40.8" height="18" rx="9"/><text class="t" x="126" y="212" dy=".35em" text-anchor="middle">uses</text></g><g class="wl"><rect x="281.2" y="203" width="33.6" height="18" rx="9"/><text class="t" x="298" y="212" dy=".35em" text-anchor="middle">isa</text></g><circle class="n" cx="40" cy="40" r="18"/><text class="t" x="40" y="40" dy=".35em" text-anchor="middle">Cus</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">Ln</text><circle class="n" cx="40" cy="212" r="18"/><text class="t" x="40" y="212" dy=".35em" text-anchor="middle">Dep</text><circle class="n" cx="212" cy="212" r="18"/><text class="t" x="212" y="212" dy=".35em" text-anchor="middle">Acc</text><circle class="n" cx="384" cy="212" r="18"/><text class="t" x="384" y="212" dy=".35em" text-anchor="middle">Sav</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">Cus Customer, Ord Order (association); Ln Line item (composition, filled diamond); Dep Report depends on Acc Account (dashed arrow); Sav Savings inherits Acc (hollow triangle)</figcaption></figure>

Key points.

Association is a structural link between classes, drawn as a plain line with optional name, role and multiplicity; a Customer places Orders.
Aggregation is a "has-a" whole-part association where the part can exist without the whole, drawn with a hollow diamond at the whole; a Department has Teachers.
Composition is a stronger aggregation where the part cannot outlive the whole, drawn with a filled diamond; an Order owns its Line items and deleting the order deletes them.
Generalization (inheritance) is an "is-a" link from a subclass to a superclass, drawn as a solid line with a hollow triangle at the parent.
Dependency is a weak, temporary "uses" relationship where a change in the supplier may affect the client, drawn as a dashed arrow.
Relationships show both the structure (association, aggregation, composition, generalization) and the interaction (dependency, messages) between objects.

<mark>Association is a link, aggregation is shared whole-part, composition is owned whole-part, generalization is is-a and dependency is uses.</mark>

Relationship	Meaning	Notation	Example
Association	uses / knows	solid line	Student - Course
Aggregation	has-a, part independent	hollow diamond	Team - Player
Composition	owns, part dies with whole	filled diamond	House - Room
Generalization	is-a	hollow triangle	Car - Vehicle
Dependency	temporarily uses	dashed arrow	Report - Printer

Answer frame. Open with the definition; draw the small class diagram with all five notations; describe each in the order association, aggregation, composition, generalization, dependency with one example; close with how they model object interaction.

Asked: [7 marks] (May 2022, Jun 2025) Write short notes on Relationships. Explain the different types of relationships in UML (association, aggregation, composition, inheritance, dependency). How do these relationships help in modeling the interactions between objects? Pitfall: Drawing the diamond at the part instead of at the whole.

Stereotypes

Definition. A stereotype is a UML extensibility mechanism that creates a new kind of model element from an existing one, written in guillemets such as <<actor>>.

Key points.

It extends the UML vocabulary without changing the language itself, so a designer can add domain-specific meaning to an existing element.
It is written as a name inside double angle brackets << >> placed above or before the element name.
Common examples are <<interface>> on a class, <<actor>>, and the analysis stereotypes <<boundary>> (user interface), <<control>> (coordination logic) and <<entity>> (persistent data).
Other examples include <<include>> and <<extend>> on use case dependencies.
Along with tagged values and constraints, stereotypes form UML's extension mechanisms.

<mark>A stereotype, written <<name>>, extends the UML vocabulary by defining a new kind of element based on an existing one.</mark>

Asked: [5 marks] (May 2022) Write short notes on Stereotypes.

Study of UML based tools Like Rational Rose, Poseidon, etc.

Definition. UML tools are CASE tools used to draw UML diagrams and often to generate code from them.

Key points.

Rational Rose (IBM) is a commercial tool supporting all UML diagrams, forward code generation and reverse engineering of code into models.
Poseidon for UML is a Java-based tool derived from ArgoUML, with a community free edition and a paid professional edition.
Other tools are StarUML, Visio and Enterprise Architect.
Benefits are consistent diagrams, a shared model repository, documentation and less manual coding.

Conventional v/s OO analysis approach

Definition. Conventional (structured) analysis models the system as processes and data flow; OO analysis models it as interacting objects and classes.

Basis	Conventional	Object-oriented
Focus	functions and processes	objects and classes
Models	DFD, ER diagram, data dictionary	use case, class, sequence diagrams
Data and behaviour	kept separate	encapsulated together
Reuse	low	high through inheritance
Change	ripples through functions	localised in classes

Requirement analysis

Definition. Requirement analysis is the process of studying, identifying, refining and documenting the needs of stakeholders so that the system to be built is clearly and correctly specified.

Key points.

Interviews with stakeholders give direct, detailed needs and clear up doubts on the spot.
Questionnaires collect the views of many users cheaply and quickly.
Workshops (JAD sessions) bring users and developers together to agree requirements and settle conflicts.
Use cases capture requirements as actor-system interactions in the user's own terms.
Prototyping shows a working model early so users can correct misunderstandings.
The outcome is a documented, verified and prioritised set of requirements in the SRS (Software Requirements Specification).

<mark>Requirement analysis identifies, refines and documents stakeholder needs, and its outcome is the SRS.</mark>

Answer frame. Open with the definition; explain the five techniques in the order interviews, questionnaires, workshops, use cases, prototyping, saying what each contributes; close with the SRS as the documented result.

Asked: [7 marks] (Jun 2025) What is requirement analysis in the context of software development? Discuss the techniques used in requirement analysis and how they contribute to identifying and documenting the needs of stakeholders?

Use case diagram

Definition. A use case diagram shows the actors, the use cases of a system and the associations between them; it describes what the system does for its users.

Key points.

A use case is a set of actions that the system performs to give an actor a measurable result, drawn as an oval; for example "Withdraw cash".
An actor is an external user, device or system that interacts with the system, drawn as a stick figure; for example Customer or Bank.
A flow of events is the step-by-step description of a use case: the main flow is the normal success path, and alternate flows cover errors and exceptions such as a wrong PIN.
Actors are linked to use cases by association lines, and use cases may be related by <<include>> and <<extend>>.

<figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u3-02" viewBox="0 0 553 252" width="553" height="252" role="img" aria-label="ATM: Cu Customer actor, Wd Withdraw cash and Bal Check balance use cases, Bk Bank actor"><style>#dsfig-u3-02 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u3-02 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u3-02 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u3-02 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u3-02 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u3-02 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u3-02 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u3-02 .t{fill:#16181D;font-weight:500}#dsfig-u3-02 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u3-02 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u3-02 .dot{fill:#16181D}#dsfig-u3-02 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u3-02 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u3-02 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u3-02 .ah{fill:#454C5A}#dsfig-u3-02 .ah.hi{fill:#2340B8}#dsfig-u3-02 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u3-02 .wl .t{font-size:12px;font-weight:700}#dsfig-u3-02 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u3-02 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u3-02 .e{stroke:#B1B7C3}html.dark #dsfig-u3-02 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u3-02 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u3-02 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u3-02 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u3-02 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u3-02 .t{fill:#E6E8ED}html.dark #dsfig-u3-02 .t.inv{fill:#0F1115}html.dark #dsfig-u3-02 .kd{stroke:#E6E8ED}html.dark #dsfig-u3-02 .dot{fill:#E6E8ED}html.dark #dsfig-u3-02 .ann{fill:#8FA3FF}html.dark #dsfig-u3-02 .lbl{fill:#858D9C}html.dark #dsfig-u3-02 .ptr{fill:#8FA3FF}html.dark #dsfig-u3-02 .ah{fill:#B1B7C3}html.dark #dsfig-u3-02 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u3-02 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u3-02 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u3-02 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah5" 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="ahh5" 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="M58,120 L280,46"/><path class="e" d="M58,132 L280,206"/><path class="e" d="M315.6,47.1 L495.4,118.9"/><circle class="n" cx="40" cy="126" r="18"/><text class="t" x="40" y="126" dy=".35em" text-anchor="middle">Cu</text><circle class="n" cx="298" cy="40" r="18"/><text class="t" x="298" y="40" dy=".35em" text-anchor="middle">Wd</text><circle class="n" cx="298" cy="212" r="18"/><text class="t" x="298" y="212" dy=".35em" text-anchor="middle">Bal</text><circle class="n" cx="513" cy="126" r="18"/><text class="t" x="513" y="126" dy=".35em" text-anchor="middle">Bk</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">ATM: Cu Customer actor, Wd Withdraw cash and Bal Check balance use cases, Bk Bank actor</figcaption></figure>

<mark>A use case is a sequence of actions giving an actor a result, an actor is an external role, and the flow of events lists the main and alternate steps.</mark>

Answer frame. Define use case, actor and flow of events in turn, each with the ATM example; draw the small diagram; close by writing the main flow and one alternate flow.

Asked: [7 marks] (May 2022) Explain the following with an example: i) Use case ii) Actor iii) Flow of events

Activity diagram

Definition. An activity diagram is a UML behavioural diagram that shows the flow of control from one activity to another, like a flowchart, including decisions and parallel flows.

Key points.

It models the workflow of a use case or an operation as activities (rounded boxes) joined by transitions.
Notation: filled circle for start, circle with a ring for end, diamond for decision and merge, thick bar for fork and join, and swimlanes to show who is responsible.
Fork splits one flow into parallel flows and join synchronises them again.

<figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u3-03" viewBox="0 0 596 252" width="596" height="252" role="img" aria-label="Order processing: S start, Ord receive order, F fork, Pk pack items, Bl bill customer, J join, E end"><style>#dsfig-u3-03 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u3-03 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u3-03 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u3-03 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u3-03 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u3-03 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u3-03 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u3-03 .t{fill:#16181D;font-weight:500}#dsfig-u3-03 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u3-03 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u3-03 .dot{fill:#16181D}#dsfig-u3-03 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u3-03 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u3-03 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u3-03 .ah{fill:#454C5A}#dsfig-u3-03 .ah.hi{fill:#2340B8}#dsfig-u3-03 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u3-03 .wl .t{font-size:12px;font-weight:700}#dsfig-u3-03 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u3-03 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u3-03 .e{stroke:#B1B7C3}html.dark #dsfig-u3-03 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u3-03 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u3-03 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u3-03 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u3-03 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u3-03 .t{fill:#E6E8ED}html.dark #dsfig-u3-03 .t.inv{fill:#0F1115}html.dark #dsfig-u3-03 .kd{stroke:#E6E8ED}html.dark #dsfig-u3-03 .dot{fill:#E6E8ED}html.dark #dsfig-u3-03 .ann{fill:#8FA3FF}html.dark #dsfig-u3-03 .lbl{fill:#858D9C}html.dark #dsfig-u3-03 .ptr{fill:#8FA3FF}html.dark #dsfig-u3-03 .ah{fill:#B1B7C3}html.dark #dsfig-u3-03 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u3-03 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u3-03 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u3-03 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah6" 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="ahh6" 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 L122.2,126" marker-end="url(#ah6)"/><path class="e" d="M162.2,126 L225.4,126" marker-end="url(#ah6)"/><path class="e" d="M261,113.8 L333.5,53.4" marker-end="url(#ah6)"/><path class="e" d="M261,138.2 L333.5,198.6" marker-end="url(#ah6)"/><path class="e" d="M364.2,52.2 L436.7,112.6" marker-end="url(#ah6)"/><path class="e" d="M364.2,199.8 L436.7,139.4" marker-end="url(#ah6)"/><path class="e" d="M471.8,126 L535,126" marker-end="url(#ah6)"/><circle class="n" cx="40" cy="126" r="18"/><text class="t" x="40" y="126" dy=".35em" text-anchor="middle">S</text><circle class="n" cx="143.2" cy="126" r="18"/><text class="t" x="143.2" y="126" dy=".35em" text-anchor="middle">Ord</text><circle class="n" cx="246.4" cy="126" r="18"/><text class="t" x="246.4" y="126" dy=".35em" text-anchor="middle">F</text><circle class="n" cx="349.6" cy="40" r="18"/><text class="t" x="349.6" y="40" dy=".35em" text-anchor="middle">Pk</text><circle class="n" cx="349.6" cy="212" r="18"/><text class="t" x="349.6" y="212" dy=".35em" text-anchor="middle">Bl</text><circle class="n" cx="452.8" cy="126" r="18"/><text class="t" x="452.8" y="126" dy=".35em" text-anchor="middle">J</text><circle class="n" cx="556" cy="126" r="18"/><text class="t" x="556" y="126" dy=".35em" text-anchor="middle">E</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">Order processing: S start, Ord receive order, F fork, Pk pack items, Bl bill customer, J join, E end</figcaption></figure>

Basis	Activity diagram	Interaction diagram
Shows	flow of activities	messages between objects
Focus	workflow and control	object collaboration
Ordering	decisions, parallel flows	time order of messages
Elements	activity, fork, swimlane	object, lifeline, message

<mark>An activity diagram models the flow from activity to activity, whereas an interaction diagram models messages passing between objects.</mark>

Answer frame. Open with the definition; draw the order example with a decision, fork-join and swimlanes; explain the notation; add the comparison table; close with the difference of flow versus object interaction.

Asked: [7 marks] (May 2022) What are Activity Diagrams in UML? How is it different from Interaction diagrams? Explain with example.

Analysis class Model

Definition. The analysis class model is the first class model built in analysis, identifying the problem-domain classes without design detail.

Key points.

Analysis classes are found from use cases and are of three stereotypes: boundary, control and entity.
They carry responsibilities and attributes but no implementation detail or exact operations.
They are refined into design classes in the design phase.

Last-minute revision

UML: standard language to visualise, specify, construct, document.
Four modelling principles: model choice matters; levels of precision; tied to reality; many models.
Aggregation hollow diamond; composition filled diamond; generalization hollow triangle; dependency dashed arrow.
Stereotype is written in << >>; boundary, control, entity.
Rational Rose (IBM) and Poseidon (ArgoUML based) are UML tools.
Conventional analysis is process and data-flow based; OO analysis is object based.
Requirement techniques: interviews, questionnaires, workshops, use cases, prototyping; result is the SRS.
Use case is an oval, actor a stick figure; flow of events has main and alternate flows.
Activity diagram: fork, join, decision, swimlane; shows flow, not object messages.

Memory hooks

Diamonds: hollow is "hangs out" (aggregation), filled is "fixed" (composition).
Requirement techniques: I-Q-W-U-P (Interview, Questionnaire, Workshop, Use case, Prototype).
Stereotypes: B-C-E, Boundary Control Entity.
Activity is the "flowchart", interaction is the "conversation".

Coverage checklist

Notations: Q7 (5 marks), plus modelling importance (Q5) and UML purpose (Q6).
Relationships: Q2.
Stereotypes: Q8.
Study of UML based tools Like Rational Rose, Poseidon, etc.: no past question.
Conventional v/s OO analysis approach: no past question.
Requirement analysis: Q3.
Use case diagram: Q4.
Activity diagram: Q1.
Analysis class Model: no past question.