OOSM

Q1 — What is the Unified Process? Compare its workflow with Waterfall.

Unified Process (UP) — short: an iterative, use-case driven, architecture-centric process for
developing software. Main phases: Inception (scope & feasibility), Elaboration
(architecture & risk reduction), Construction (build system), Transition (deploy &
stabilize). Each phase contains iterations; activities (requirements, analysis, design,
implementation, test) are repeated each iteration.

Waterfall — linear, sequential: Requirements → Design → Implementation → Verification

→ Maintenance. Each phase must finish before next starts.

Key differences (simple table):

 Approach: UP = iterative & incremental; Waterfall = linear.

 Risk handling: UP handles risks early via iterations; Waterfall tries to plan risks up
front.
 Customer feedback: UP gets feedback each iteration; Waterfall often gets late
feedback.
 Flexibility to change: UP flexible (scope can evolve); Waterfall rigid.
 Deliverables: UP produces working increments frequently; Waterfall delivers mostly
at the end.

When to use: UP for complex/uncertain projects; Waterfall for small/well-understood

projects.

Q2 — Class diagram for supplier–customer–order scenario and aggregation

use

Entities (classes) and typical attributes (simple):

 Customer { customerId, name, address }

 Order { orderId, date, totalAmount }
 OrderLine { lineNo, quantity, price }
 Part { partId, name, price }
 Catalogue { catalogueId } (contains Parts)
 Supplier { supplierId, name }
 Delivery { deliveryId, deliveryDate }

Relationships & multiplicity (text you can draw):

 Customer 1 --- * Order

(Customer places many Orders)
  Order 1 --- * OrderLine (composition: an Order contains OrderLines; OrderLines do
not exist without Order)
Use composition (black filled diamond at Order end).
 OrderLine * --- 1 Part
(Each order line refers to one Part; a Part can appear in many OrderLines)
 Supplier 1 --- * Catalogue --- * Part
(Supplier has a Catalogue that lists Parts)
Catalogue aggregates Parts (hollow diamond) if parts can be shared or exist
independently.
 Order 1 --- 1 Delivery (or 1 --- * Delivery depending if partial deliveries allowed).
Delivery aggregates delivered OrderLines.

Discuss aggregation use simply:

 Use composition when lifetime is tied (Order → OrderLine). If an Order is deleted,

its OrderLines are deleted.
 Use aggregation (lighter link) when ownership is weak: e.g., Catalogue aggregates
Part because a Part might exist independent of a particular Catalogue or be shared
across catalogues.

Example UML text (you can draw boxes & lines with multiplicities):

Customer "1" ── places ── "0..*" Order

Order "1" ◼── contains (composition) ── "1..*" OrderLine
OrderLine "1" ── refers ── "1" Part
Supplier "1" ── owns (aggregation hollow) ── "1" Catalogue
Catalogue "1" ── lists ── "0..*" Part
Order "1" ── deliveredBy ── "0..1" Delivery

Q3 — Benefits of Use-Case Analysis & Use-Case Diagram for Inventory

Management

Benefits (simple):

 Focus on what users need — clarifies requirements.

 Easy for non-technical stakeholders to understand.
 Drives test cases (acceptance tests).
 Helps identify actors and their responsibilities.
 Helps prioritize features and drives architecture decisions.

Use-Case Diagram for Inventory Management (actors & use-cases):

Actors: InventoryManager, Supplier, SalesPerson, SystemAdmin

Use cases (common):

 Add Item
 Update Item Details
 Receive Stock
 Issue Stock (to sales/orders)
  Generate Stock Report
 Reorder Item (trigger purchase to Supplier)
 Stocktake / Audit
 Manage Suppliers

How to draw quickly: Put actors on left/right as stick figures. Put an oval for each use case
in system boundary rectangle labelled InventoryManagementSystem. Connect actors to
relevant use cases. Example connections: InventoryManager → Add Item, Receive Stock,
Reorder Item, Generate Stock Report; Supplier ← Reorder Item.

Q4 — State & Event generalization / aggregation (explain with examples)

State generalization (simple): A superstate groups similar substates. Example: PowerOn is

a superstate with substates Standby, Active. Generalization arrow (open triangle) shows
Standby and Active are types of PowerOn.

Event generalization (simple): Events can be specialized. E.g., UserAction general event
with specialized events ShortPress, LongPress. Handlers can respond to the general event
or a specialized one.

Aggregation / Composite States: A composite (nested) state contains orthogonal or

sequential substates (used to model complexity). Example: Flight state for an aircraft can
contain substates Taxiing, Takeoff, Climb, Cruise, Descent, Landing. You draw a big
rounded box (superstate) and inside smaller states.

Why useful: Reduces repetition: common entry/exit actions defined at superstate; easier to
understand hierarchical behavior.

Q5 — Guarded transitions in State diagrams — representation & example

Definition: A guarded transition is a transition that fires only if a condition (guard) is true.
Shown as event [guard] / action.

Notation example on a transition label:

pay / or confirmPayment [balance >= amount] / sendReceipt

Simple example: Order state machine:

Order: Pending --(pay [balance >= amount] / move to Confirmed)--> Confirmed

Order: Pending --(pay [balance < amount] / showError)--> PaymentFailed

Why suitable: Guards model real-world conditions (e.g., only confirm if funds available).
They prevent illegal transitions.
PYQs from other images — short answers

Companies/employees class diagram (draw & notes)

Classes: Company, Employee

Attributes: Company { companyId, name } ; Employee { empId, name, role }
Relationships:

 Company "1" --- "*" Employee (company employs many employees)

 Company "1" --- "1" ManagingDirector (ManagingDirector is an Employee
assigned the role)
 Employee has a self-association manager : Employee (each employee may have a
manager) — multiplicity 0..1 for manager and 0..* for subordinates.

You can also model ManagingDirector as a role or subclass of Employee.

Differentiate Aggregation vs Composition (simple)

 Aggregation (hollow diamond): weak ownership; parts can exist independently. E.g.,
Department aggregates Employee. If Department deleted, employee can still exist.
 Composition (filled diamond): strong ownership; part's lifecycle tied to whole. E.g.,
Order composed of OrderLine — delete Order → delete lines.

Concurrency in state diagrams

 Use orthogonal regions (parallel regions inside a composite state) to show

concurrent substates.
 Example: Printer composite state with two regions: [PowerRegion: On/Off] and
[JobRegion: Idle/Printing/Paused]. Both run concurrently.
 Use fork and join pseudo-nodes for splitting/merging concurrency (more common
in activity diagrams).

Use-case approach importance in SDLC (short bullets)

 Elicits functional requirements clearly.

 Provides user scenarios for architecture & testing.
 Use cases drive iteration priorities.
 Help produce acceptance tests & user documentation.

Activity Diagram for online hotel booking (steps)

Flow: Start -> Search Hotel -> Choose Room -> Enter Guest Details -> Select
Payment -> Payment Successful? [yes/no] -> Confirm Booking (on yes) -> Send
Confirmation Email -> End
Include decision diamond at payment step and alternate path for payment failure or retry.

Interaction (sequence) diagram for transferring Rs.500 from Account A to B

Lifelines: Customer, BankUI, BankSystem, AccountA, AccountB

Messages (top→down):
 1. Customer -> BankUI: transferRequest(A, B, 500)
2. BankUI -> BankSystem: validateCustomer()
3. BankSystem -> AccountA: checkBalance()
4. AccountA -> BankSystem: balanceOK
5. BankSystem -> AccountA: debit(500)
6. AccountA -> BankSystem: debited
7. BankSystem -> AccountB: credit(500)
8. AccountB -> BankSystem: credited
9. BankSystem -> BankUI: success → BankUI -> Customer: showSuccess

Q: Differentiate OOA and OOD (short)

 OO Analysis (OOA): Find what the system must do — identify actors, use cases,
domain concepts, classes (conceptual). Focus on requirements and domain model.
 OO Design (OOD): Plan how to build it — define software classes, interfaces,
patterns, interactions, persistence, performance. Focus on architecture and
implementation choices.

Q: Links & Associations (short)

 Association: static relation between classes (line connecting class boxes).

 Link: a specific instance of an association at runtime (object A refers to object B).
Associations show multiplicity; links are actual references.

Q: Phases in OO software development (explain)

You can answer using UP phases (preferred for OO):

 Inception: define scope, identify major use cases and costs.

 Elaboration: refine requirements, build architecture baseline, mitigate risks.
 Construction: implement most functionality, iterate to build.
 Transition: deploy product, fix defects, user training.

Or generic SDLC (requirements → analysis → design → implementation → testing →

deployment → maintenance), but emphasize iterative cycles.

Typing in Object Oriented System (short)

 Static typing: types checked at compile time (e.g., Java, C++).

 Dynamic typing: types checked at runtime (e.g., Python, Ruby).
 Strong vs weak typing: whether implicit conversions allowed.
 Polymorphism & subtype polymorphism: objects of subclass used where superclass
expected.
 Generic typing: templates/generics for parameterized types.

Class diagram vs Object diagram (short)

  Class diagram: blueprint — classes, attributes, methods, relationships.
 Object diagram: snapshot — instances (objects) with current values, showing links.

Basic building blocks of UML (short)

 Structural: Class, Object, Component, Node, Package.

 Behavioral: Use Case, Activity, State Machine, Sequence, Communication.
 Additional: Stereotypes, Notes, Constraints.
Use cases model requirements; class diagrams show static design; sequence diagrams
show interactions; state diagrams show lifecycle behavior.

2) Syllabus topics — short exam-friendly

coverage (Unit-1 & Unit-2)
I’ll list each topic with a short explanation + what to draw/remember in exam.

Unit-1 (Object Oriented Design & Modeling)

Object-oriented fundamentals

 Four pillars: Encapsulation (hide data), Abstraction (model essential), Inheritance

(specialize), Polymorphism (many forms).
 Benefit: Reuse, modularity, easier maintenance.

Objects and Classes

 Class: template with attributes & methods.

 Object: instance of class with concrete values.
 Draw: class box with +/- attributes and methods.

Object Oriented Design Process

 Steps: gather requirements → analysis (domain model) → design (detailed classes &
interfaces) → implementation → test.
 Use patterns & principles (SRP, OCP, DRY).

Importance of Modeling

 Visualize complex systems, communicate with stakeholders, reduce ambiguity, basis

for code and tests.

Principles of Modeling
  Keep models simple, use correct abstraction, show required detail only, validate with
stakeholders, iterate.

OOAD Methods

 Examples: RUP/Unified Process, Booch, OMT, OOSAD — UP is most common; use

cases drive design.

Software Development Life Cycle (SDLC)

 Requirements, analysis, design, implementation, testing, deployment, maintenance;

emphasize iterations (Agile/UP) vs waterfall.

Introduction to Unified Process

 Discuss Inception/Elaboration/Construction/Transition, iteration, risk-driven, use-case

driven, architecture-centric.

Introduction to UML & Terminology

 UML: standard notation for modeling. Terms: Actor, Use Case, Class, Object, Link,
State, Activity, Component, Node, Package.

Conceptual model of UML

 UML shows structure (class, component), behavior (use case, activity), interaction
(sequence). Use diagrams appropriately.

Use of UML in Unified Process

 Use cases for requirements, class diagrams for analysis & design, sequence diagrams
for interaction, state diagrams for behavior, activity for workflows.

Unit-2 (Structural Modeling & Use Case Modeling)

Classes, Relationships, common mechanisms

 Relationships: Association, Aggregation (hollow diamond), Composition (filled

diamond), Generalization (inheritance), Dependency.
 Mechanisms: Multiplicity, visibility, abstract classes, interfaces.

Class & Object Diagrams: terms & modelling techniques

 Use class boxes; add attributes and operations; show multiplicities; use stereotypes
<<interface>>.
Links and Associations

 Association = conceptual relation between classes. Link = runtime instance.

Link Attributes and Link Classes

 When an association itself has attributes (e.g., Employment with salary between
Person and Company) you model it as a link class (separate class connected to
association), or as association attributes in some notations.

Generalization and Inheritance

 Subclass inherits attributes/operations. Use open triangle arrow.

Aggregation and Composition

 Aggregation: weak relationship (hollow diamond).

 Composition: strong ownership (filled diamond). Use when parts can't exist without
whole.

Qualified Association

 A qualifier reduces multiplicity on the other side (e.g., Account qualified by

accountNumber to retrieve specific account quickly).

Handling multiplicity in object creation

 Show multiplicities at association ends; factory methods for creation; use constructors
and patterns to enforce multiplicity.

Abstract Classes

 Classes that cannot be instantiated; contain abstract operations to be implemented by

subclasses.

Specifying constraints in Class Diagrams

 Use OCL or simple notes «constraint» or bracketed constraints like {ordered},

{unique}.

Advanced Structural Modeling: Advanced classes, relationships

 Interfaces (contracts), roles (role names on association ends), types, associations with
qualifiers, association classes.

Interfaces, Types and Roles

  <<interface>> with provided/required roles; type (data type) used for attribute
definitions; role names clarify association ends.

Packages

 Group related classes into packages; draw package box. Use for modularization.

Use Case Modeling: Use Cases & Use Case Diagrams

 Actors interact with system use cases; model primary scenarios and extensions;
include <<include>> and <<extend>>.

Use Case Driven Methodology

 Use cases drive requirements, design, test; prioritize iterations by use cases.

3) My “pro thinking” — likely questions for

today’s exam
I’ll list short, exam-style questions (most likely based on syllabus + PYQs). You can
memorize these or prepare quick sketches:

1. Explain the Unified Process. Describe its phases with objectives.

2. Compare Unified Process with Waterfall model (pointwise).
3. Draw a labeled class diagram for a company/employees system (managing director,
manager-subordinates).
4. How is aggregation different from composition? Give two examples.
5. Draw class diagram for an order–supplier–catalogue–delivery system and explain
multiplicities.
6. What are the benefits of Use-Case Analysis? Draw a use-case diagram for Inventory
Management.
7. Explain association, link, and link-class with an example.
8. Define generalization/inheritance and draw an example with Vehicle, Car, Truck.
9. What is a qualified association? Draw a diagram.
10. Explain how to represent concurrent behavior in state diagrams. Give an example.
11. What are guarded transitions? Show notation and example.
12. Explain nested (composite) state diagrams and draw one for an aircraft.
13. Differentiate Object Oriented Analysis (OOA) and Object Oriented Design (OOD).
14. Explain the basic building blocks of UML briefly (list & short purpose).
15. Draw an activity diagram for online hotel booking (include payment decision).
16. Draw an interaction (sequence) diagram for transferring money between bank
accounts.
17. Explain link attributes and association classes with example (e.g., Enrollment between
Student and Course).
18. What is an abstract class? How is it different from an interface?
 19. What are stereotypes and constraints in UML? Give examples.
20. How is use-case driven methodology applied in Unified Process?
21. Explain typing in object oriented systems (static vs dynamic; subtype polymorphism).
22. Draw a class diagram for restaurant order management (actors & classes).
23. Explain the purpose of packages and how they aid large systems.
24. How do you specify multiplicities and what do they mean? (short answer)
25. Explain the role of UML in requirement elicitation and testing.

1. Explain the Unified Process. Describe its phases with objectives.

The Unified Process (UP) is an iterative and incremental software development

methodology that is use-case driven, architecture-centric, and risk-focused.

Phases:

1. Inception – Define project scope, feasibility, identify key use cases, cost estimation.
2. Elaboration – Refine requirements, establish baseline architecture, mitigate major
risks.
3. Construction – Implement system features through iterations, focus on coding and
testing.
4. Transition – Deliver system to users, perform testing, training, and deployment.

2. Compare Unified Process with Waterfall model (pointwise).

Feature Unified Process (UP) Waterfall Model

Approach Iterative, incremental Sequential, linear
Risk Management Risks addressed early Risks handled late
Customer Feedback Continuous (each iteration) Late (after implementation)
Flexibility Changes allowed between iterations Very rigid
Deliverables Working system in increments Final product only at the end

3. Draw a labeled class diagram for company–employees system.

Classes & Relationships:

 Company employs many Employee.

 Each company has one ManagingDirector (special role).
 Each employee has one Manager, who may manage many subordinates.

Diagram (text description):

Company "1" ── employs ── "0..*" Employee

Company "1" ── has ── "1" ManagingDirector (role of Employee)
Employee "0..1" ── manages ── "0..*" Employee (self-association)
4. How is aggregation different from composition?

 Aggregation (hollow diamond): Weak ownership. Part can exist without the whole.
Example: Department aggregates Employees. If Department is deleted, Employees
may still exist.
 Composition (filled diamond): Strong ownership. Parts cannot exist without the
whole.
Example: Order composed of OrderLines. If Order is deleted, OrderLines are deleted.

5. Draw class diagram for order–supplier–catalogue–delivery system.

See earlier detailed answer (Customer, Order, OrderLine, Part, Supplier, Catalogue,
Delivery).

 Composition: Order → OrderLine.

 Aggregation: Catalogue → Part.
 Association: Supplier owns Catalogue, Order produces Delivery.

6. What are the benefits of Use-Case Analysis? Draw a use-case diagram for
Inventory Management.

Benefits:

 Simple way to capture requirements.

 Easy for users & developers to understand.
 Drives testing, architecture, and development planning.
 Prioritizes important system behavior.

Actors: Inventory Manager, Supplier, SalesPerson, Admin.

Use Cases: Add/Update Item, Receive Stock, Issue Stock, Generate Report, Reorder Item,
Manage Supplier.

7. Explain association, link, and link-class with an example.

 Association: Relationship between classes. Example: Student ― enrolls in ― Course.

 Link: A specific instance of an association at runtime. Example: “Ram is enrolled in
DBMS course.”
 Link-Class: A class that belongs to an association with attributes. Example:
Enrollment (with attribute: grade, date) between Student and Course.

8. Define generalization/inheritance with example.

Generalization: Relationship where one class is a specialized version of another.
Example:

 Superclass: Vehicle
 Subclasses: Car, Truck, Bike

Diagram: Vehicle (top) → Car, Truck, Bike (arrows with open triangle pointing to Vehicle).

9. What is a qualified association?

A qualified association uses a key/qualifier to reduce multiplicity.

Example:

 Bank manages many Accounts.

 Qualified by accountNumber.
So instead of Bank → * Account, it is Bank → [accountNumber] → 1 Account.

10. Explain concurrency in state diagrams.

Concurrency is modeled using orthogonal regions inside a composite state.

 Example: Printer has two concurrent regions:

1. Power Region → [On, Off]
2. Job Region → [Idle, Printing]
Both run in parallel.
Notation: Draw a composite state with two separated compartments, each
with its own states.

11. What are guarded transitions? Give example.

Guarded transitions: Transitions in state diagrams that only occur if a condition (guard) is
true.
Notation: event [guard] / action

Example:
Order (Pending) → Confirmed on pay [balance >= amount].
Order (Pending) → PaymentFailed on pay [balance < amount].

12. Explain nested (composite) state diagrams with example for aircraft.

Nested/Composite state: A state that contains substates inside.

Example: Aircraft system
Superstate: InFlight
Substates: Takeoff → Climb → Cruise → Descent → Landing.

This shows hierarchy and reduces complexity.

13. Differentiate Object-Oriented Analysis (OOA) and Object-Oriented

Design (OOD).

Aspect OOA (Analysis) OOD (Design)

Focus What system should do How system will be implemented
Conceptual model (use cases, Design model (detailed classes, DB,
Output
classes) interfaces)
Concern Requirements and domain concepts Architecture, performance, patterns

14. Explain basic building blocks of UML.

 Structural diagrams: Class, Object, Component, Deployment.

 Behavioral diagrams: Use Case, Activity, State Machine.
 Interaction diagrams: Sequence, Communication.
 Additional: Packages, Notes, Stereotypes, Constraints.

15. Activity diagram for online hotel booking.

Flow:
Start → Search Hotel → Choose Room → Enter Details → Payment → [Success?] Decision
→ Confirm Booking → Send Email → End.
If payment fails → Retry or Cancel.

16. Interaction (sequence) diagram for transferring money (Account A to B).

Actors: Customer, BankSystem, AccountA, AccountB.

Flow:

1. Customer → BankSystem: transfer(A, B, 500)

2. BankSystem → AccountA: checkBalance
3. AccountA → BankSystem: OK
4. BankSystem → AccountA: debit(500)
5. BankSystem → AccountB: credit(500)
6. BankSystem → Customer: success message
17. Explain link attributes and association classes with example.

 Link attributes: Attributes that belong to an association.

 Example: Student ― enrolled in ― Course. The enrollment has an attribute date.
 Model as association class: Enrollment between Student and Course, with attribute
date and grade.

18. What is an abstract class? How is it different from an interface?

 Abstract class: Cannot be instantiated, may contain abstract and concrete methods.
Used for partial implementation.
 Interface: Pure contract (only abstract methods). Class implementing interface must
define all methods.

Example:
Abstract class: Shape with method area() abstract.
Interface: Drawable with method draw().

19. What are stereotypes and constraints in UML?

 Stereotypes: Extend UML to create new model elements. Written as «stereotype».

Example: «interface», «entity».
 Constraints: Rules that restrict elements. Written in braces {}. Example: {ordered},
{unique}.

20. How is use-case driven methodology applied in Unified Process?

 Requirements are captured as use cases.

 Iterations are planned based on use cases.
 Analysis, design, coding, and testing are performed use-case by use-case.
 Ensures user functionality is always central.

21. Explain typing in object-oriented systems.

 Static typing: Types checked at compile time (Java, C++).

 Dynamic typing: Types checked at runtime (Python).
 Strong typing: Prevents mixing types implicitly.
 Weak typing: Allows implicit type conversions.
 Polymorphism: Subclass can be used where superclass expected.
  Generic typing: Parameterized types (List<T> in Java).

22. Class diagram for restaurant order management.

Classes:

 Customer
 Order (composition with OrderItems)
 OrderItem (quantity, price)
 MenuItem (name, price)
 Restaurant (manages Orders, MenuItems)

Associations:

 Customer places Orders.

 Order composed of OrderItems.
 OrderItem linked to MenuItem.

23. Explain the purpose of packages and how they aid large systems.

 Package: Logical grouping of classes, interfaces, or diagrams.

 Helps manage complexity, improves modularity, and allows reuse.
 Example: In an e-commerce system: package User, package Order, package
Payment.

24. How do you specify multiplicities in UML?

 Multiplicity shows how many instances can be related.

Examples:
 1 → exactly one.
 0..* → zero or more.
 1..* → at least one.
 0..1 → optional.

E.g., One Customer places 0..* Orders.

25. Explain the role of UML in requirement elicitation and testing.

 UML diagrams help capture requirements clearly (use cases).

 Diagrams like sequence & activity help model workflows.
 State diagrams help define test cases for all possible states.
 UML ensures shared understanding between developers, testers, and clients.