Lecture # 5

Slide 1: Use-Case Diagram

A use-case diagram is a common and popular way to show what a

system should do. It is mostly used to capture functional
requirements in software development.
It shows how users or stakeholders interact with the system.
This diagram is a high-level picture that explains the relationship
between the users and the system.
It is very useful when you want to explain your system to people
who are not technical, like clients or managers, because it is easy
to understand.
Slide 2: Purpose of Use-Case Diagram

Use-case diagrams are made in the early stage of development.

They are used to:

• Show the context of a system.

• Capture system requirements.
• Check the system design.
• Help with coding and making test cases.
• Created by analysts and domain experts together.

Slide 3: Elements of Use-Case Diagram – Types of Actors

Actors are people or systems that interact with your system.

How to find actors?

• They should give or take data from the system.

• They are outside the system (not part of the system itself).

Types of actors:

• Primary Actor: This is the main user. Their goals are

completed when they use the system. They start the use-
case.
• Supporting Actor: This actor helps the system. For example, a
payment service helps complete a purchase.
• Offstage Actor: This actor does not directly use the system,
but they are interested in the system’s work. For example, a
government tax agency might check reports.
Slide 4: Relationships in Use-Case Diagram

There are different types of relationships in a use-case diagram:

• Association Link: It shows which actors are connected to

which use-cases.
• Include Relationship: This is used when one use-case always
needs another extra step. For example, “Login” might be
included in many use-cases.
• Extend Relationship: This is for optional actions or extra
behaviors that happen sometimes.
• Generalization: This means a child use-case gets features
from a parent use-case and can add or change them.

Slide 5: Use-Case Levels & Example

Use-cases can be written in different levels of detail:

• Brief Use-Case: Only a few sentences that explain the main

goal. It is used in early stages and is very quick to write.
• Casual Use-Case: A few paragraphs that explain the main
steps in a simple way. Used in agile because it is fast and easy
to understand.
• Fully Dressed Use-Case: A detailed and complete version
that explains every small part. Used when the system is
complex and risky.

Example Main Scenario:

A customer brings items to return. The cashier uses the system to
record each returned item.
Alternate Scenarios:

• If the customer paid by credit card.

• If the item is not found in the system.
• If the system cannot connect to accounting.

Slide 6: Fully Dressed Use-Case – Details

A fully dressed use-case has these elements:

• Name: The title, usually starts with a verb (like “Book Ticket”).
• Primary Actor: The main user or thing using the system.
• Secondary Actor: Any other person or group who cares about
the use-case.
• Preconditions: What must be true before the use-case starts.
• Post-Conditions: What must be true after the use-case ends.
• Trigger: The event that starts the use-case.
• Main Success Scenario: Steps when everything goes right.
• Extensions: Steps when something different or wrong
happens.
• Exceptions: Things that stop the goal from happening.
• Quality: Special quality needs like speed, security, etc.

Slide 7: Exercise – Restaurant App

Question:
A restaurant chain wants to develop software for ordering.
Customers should:
 • View the restaurant menu.
• Place an order.
• Have a kids’ page with menu and games.
• Make changes to meals and add dietary restrictions.
• Kitchen should view orders.
• Customers should view and pay their bill.

Solution (Narrative Use-Case):

Use-Case Name: Place Order in Restaurant App

Primary Actor: Customer
Supporting Actors: Kitchen staff, Payment system
Precondition: The customer has opened the app and is inside the
restaurant.
Trigger: Customer decides to order food using the app.

Main Success Scenario (Basic Flow):

1. Customer opens the app and selects the restaurant they are
in.
2. Customer views the menu, including the kids’ page with kids’
menu and games.
3. Customer chooses the items they want to order.
4. Customer adds any changes to the meal (e.g., remove an
ingredient) and mentions any dietary restrictions.
5. Customer confirms the order.
6. The order is sent to the kitchen.
7. Kitchen staff views the order on their system and starts
preparing it.
8. Customer can view their order details and total bill in the app.
 9. Customer goes to the payment page and pays using the app.
10. System confirms the payment and shows the final
receipt.

Alternate Scenarios:

• If payment fails, the app shows an error and asks the customer
to try again.
• If an item is unavailable, the app tells the customer and
suggests other options.

Slide 8: Exercise – Flight Booking App

Question:
Write a narrative use-case for booking a flight using UACAir App
as described.
Solution (Narrative Use-Case):

Use-Case Name: Book a Flight Using UACAir App

Primary Actor: Passenger
Supporting Actor: Payment System
Precondition: Passenger has UACAir app installed and logged in.
Trigger: Passenger wants to book a flight.

Main Success Scenario (Basic Flow):

1. Passenger opens the UACAir app and selects “Book a Flight.”

2. Passenger enters departure city.
3. App shows arrival city options based on departure city.
4. Passenger chooses the arrival city.
5. Passenger selects trip type: One-way or Round Trip.
6. Passenger enters the number of tickets (adults and children).
7. If Round Trip, passenger enters departure and return dates.
a. If return date is earlier than departure date, the app
shows an error.
8. Passenger taps “OK.”
9. App shows available flights with details:
a. Airline name
b. Price
c. Departure and arrival date/time
d. Confirmation button
10. Passenger chooses the desired flight.
11. Passenger enters all passenger details based on tickets
selected.
12. Passenger clicks “Confirm” and moves to payment.
 13. Passenger pays using credit/debit card. (Only card
payments allowed.)
14. After successful payment, app shows itinerary in “My
Itinerary” tab.
15. Itinerary stays there until the travel date passes.

Alternate Scenarios:

• If payment fails, app shows error and asks to try again.

• If no flights are available, app shows “No flights found.”
Lecture # 6
Slide 1: Object-Oriented Analysis and Design (OOAD)

OOAD means planning and building software using real-world

ideas like objects (e.g., people, cars, animals).
First, you analyze what the system should do (analysis). Then you
design the system using object-oriented concepts (design).

Slide 2: What is UML?

UML stands for Unified Modeling Language. It is a visual language

used to draw diagrams that show how your system works.
Common UML diagrams:

• Class Diagram: Shows classes and their relationships.

• Use Case Diagram: Shows how users interact with the
system.
• Sequence Diagram: Shows how objects talk to each other
over time.
Slide 3: Object Orientation

Object Orientation is a way of thinking where everything is treated

as an object.
Each object has two main things:

• Properties (data): For example, a car has color and speed.

• Methods (actions): For example, a car can start and stop.

Slide 4: Important Object-Oriented Concepts

• Abstraction: Hide extra details and show only what is

important.
• Inheritance: Create a new class from an existing one. The new
class inherits features from the old class.
• Data Encapsulation: Keep data safe inside the class and only
allow changes through specific methods (e.g., deposit(),
withdraw()).
• Polymorphism: One action behaves differently for different
objects. Example: A draw() method can draw a circle or a
square based on the object.

Slide 5: Object-Oriented Design Principles

These principles help to design classes and objects in a clean

way:

• Avoid messy or repeated code.

 • Make code easier to test and change later.
• Reduce bugs by separating responsibilities.

Slide 6: SOLID Principles (5 Rules)

SOLID is a set of 5 important rules by Robert C. Martin to make

software:

• Flexible
• Easy to maintain
• Scalable

1. Single Responsibility Principle (SRP):

A class should do only one job.
Example: An InvoicePrinter class should only print invoices, not
calculate or save them.

2. Open/Closed Principle:
Software should be open for adding new features but closed for
changing old code.
Example: Instead of changing an old shape class to add new
shapes, create new shape classes from a base class.

3. Liskov Substitution Principle:

A subclass should work wherever its parent works.
Example: If Bird can fly, Penguin (a bird that can’t fly) should not be
a subclass of Bird.

4. Interface Segregation Principle:

Don’t make one big interface with many methods.
 Make small interfaces so classes only implement what they need.
Example: Instead of IMachine with print(), scan(), fax(), create
IPrinter, IScanner, IFax separately.

5. Dependency Inversion Principle:

High-level classes should depend on interfaces, not on low-level
classes.
Example: A RemoteControl should work with a TV interface, not just
SamsungTV, so we can change TV brands easily.

Slide 7: GRASP Principles (9 Rules)

GRASP = General Responsibility Assignment Software Patterns.

It helps assign responsibilities to classes and objects properly.

1. Information Expert:
Give a task to the class that has the required data.
Example: Invoice should calculate its own total because it has all
items.

2. Creator:
A class should create another class if it contains or uses it.
Example: Order creates OrderLine.

3. Controller:
A controller class should handle system input, not UI or model
directly.
Example: OrderController handles “Place Order” request.
4. Low Coupling:
Classes should be less dependent on each other. This makes
testing and changes easy.

5. High Cohesion:
A class should have one clear purpose.
Example: Invoice should not handle printing or emailing.

6. Polymorphism:
Use the same interface for different behaviors.
Example: CashPayment and CardPayment both implement pay().

7. Pure Fabrication:
Sometimes make a helper class to keep design clean even if it’s not
real-world.
Example: Logger class.

8. Indirection:
Use an extra class to reduce direct connection between two
classes.
Example: Service Layer between Controller and Model.

9. Protected Variations:
Design your code so that changes in one part do not affect others.
Example: Use interfaces or abstract classes.

Lecture # 7
Slide 1: Why We Need Architecture

We need architecture because it organizes the code in a clean way.

It helps:

• Make software easy to understand.

• Make changes without breaking everything.
• Reduce bugs by separating parts of the system.

Slide 2: Types of Architecture

MVC (Model-View-Controller)

• Model: Handles data and business logic.

• View: Shows the data to the user and sends user actions to the
Controller.
• Controller: Handles user input, updates the Model, and
decides which View to show.

Slide 3: MVC Details

In MVC, the View usually knows about both Model and

Controller, which can make them tightly connected.
This sometimes makes testing and maintenance harder.
Slide 4: Challenges of MVC

• Complexity: For small apps, MVC can be too much and cause
extra work.
• Learning Curve: Developers must understand all components
very well.
• Overhead: More files and work because of separating Model,
View, and Controller.
• Synchronizing them can make development slower and harder
to debug.

Slide 5: Popular MVC Frameworks

• Django (Python): Uses MVT (Model-View-Template), includes

many built-in features.
• Ruby on Rails: Server-side framework for building web apps
quickly.
• Angular: For single-page apps (SPAs), uses components and
dependency injection, similar to MVC.

Slide 6: MVC Example (Booking System in Node.js)

• Model: Defines booking structure and interacts with the

database.
• View: Displays bookings list (HTML template).
• Controller: Handles logic for getting bookings and adding new
bookings.
 • Routes: Connect URLs to the correct Controller actions.
• Server Setup: Starts the server, connects to the database, and
uses routes.

Slide 7: MVP (Model-View-Presenter)

• Model: Manages data and logic (same as MVC).

• View: Displays data and sends user input to Presenter. The
View is passive (has very little logic).
• Presenter: Middle layer between Model and View. Handles
input, updates Model, and decides what View shows.
• Presenter is easy to test because it is not tied to platform-
specific code.

Slide 8: MVVM (Model-View-ViewModel)

• Model: Handles data and business logic (same idea as

MVC/MVP).
• View: The UI (e.g., screens in Android).
• ViewModel: Holds data and logic for the UI. Connects Model
and View. Often uses data binding, so changes in data update
the UI automatically.
MVVM is great for complex apps with a lot of UI updates.

Slide 9: Key Differences

• Mediator Role:
 o MVC uses Controller
o MVP uses Presenter
o MVVM uses ViewModel
• Coupling: MVC has tighter connections between View and
Model. MVP and MVVM have better separation.
• Testability: MVP and MVVM are easier to test.
• Data Binding: MVVM supports automatic updates between
View and ViewModel.

Question 1: (Comparative Design Challenge)

Question:
You are tasked with designing a complex, real-time healthcare
monitoring system. Based on the characteristics of MVC, MVP, and
MVVM architectures, analyze which architecture would be the most
suitable for this system and why. Discuss how the choice affects
data binding, testability, component decoupling, and
maintainability.

✅ Answer:

The most suitable architecture for a real-time healthcare

monitoring system is MVVM (Model-View-ViewModel).

Why MVVM is best?

• Data Binding:
MVVM provides two-way data binding. Real-time patient
 health data automatically updates in the UI without manual
refresh. MVC requires manual updates, which is slow for real-
time systems. MVP has limited binding.
• Testability:
Business logic in ViewModel makes unit testing easy without
depending on UI. MVC is hard to test because of tight coupling.
• Component Decoupling:
MVVM separates View and Model completely using
ViewModel as a mediator. MVC has tight coupling between
View and Model. MVP improves separation, but MVVM is best
for complex UI and live updates.
• Maintainability:
MVVM is easy to maintain because new features can be added
without affecting other layers. This is important for healthcare
systems where updates happen often.

(MVVM Real-Time Heart Rate Update Code):

let heartRate = 80; // Model data
setInterval(()=>console.log(`Heart Rate: ${heartRate++}
bpm`),2000); // View auto updates every 2 sec

Question 2: (Debugging Scenario-Based Question)

Question:
In an MVC-based hotel booking application, users report that the
list of bookings doesn’t update after submitting a new booking until
they manually refresh the page. The controller logic appears
correct. Identify potential architectural and implementation flaws
that may be causing this issue. Propose detailed technical solutions
using asynchronous programming strategies.

✅ Answer:

Diagnosis:

• MVC is sending full HTML on each request. After new booking,

page refresh is required.
• No asynchronous update in the View.

Flaw:

• The View is tightly coupled to full-page rendering.

• Controller returns full page instead of JSON for dynamic
update.

Solution:
✔ Use AJAX or Fetch API to send booking data and update View
dynamically.
✔ Use WebSockets for real-time updates if needed.

(Using Fetch API) Code:

fetch('/bookings').then(r=>r.json()).then(data=>console.log('Update
d:',data));
Question 3: (Refactoring and Optimization)

Question:
A developer implemented MVC in Node.js, but the View directly
calls Model functions, bypassing the Controller. Analyze the impact
and explain how to restructure the app to follow MVC principles.

✅ Answer:

Impact:

• Breaks MVC principle of separation of concerns.

• Logic spread across Views → Hard to maintain.
• Hard to test because UI and business logic are mixed.
• Scalability suffers because changes in Model affect Views
everywhere.

Solution:
✔ Move all data access logic to Controller.
✔ View should only display data from Controller and send user
input to Controller.

Code MVC:

// Controller

res.render('bookings',{data:await Booking.find()});
Question 4: (Multi-Layer Integration and Strategy)

Question:
A legacy MVC app must integrate modern frontend features like
reactive data binding and modular UI (React or Angular). Propose
migration strategy for backward compatibility and modern benefits.
Discuss challenges and mitigation.

✅ Answer:

Migration Strategy:
✔ Keep existing MVC backend.
✔ Expose Controllers as REST APIs to serve JSON instead of full
HTML.
✔ Build React/Angular SPA as the new View layer.
✔ Migrate step-by-step:

• Phase 1: Old View + new SPA co-exist.

• Phase 2: Fully switch to SPA.

Challenges:

• Data Binding: Use Angular/React for real-time UI updates.

• Backward Compatibility: Keep old routes working during
migration.
• Team Training: Train developers for modern frameworks.

Short Code (API + React Fetch):

// Backend API

app.get('/api/bookings',(req,res)=>res.json(bookings));

// React fetch

fetch('/api/bookings').then(r=>r.json()).then(console.log);