Introduction of project‫ن‬

‫اس پروجیکٹ کو بنانے کا مقصد ڈرئیوانگ اسکولوں کے لیے آن الئن بکنگ پلیٹ فارم بنانا تھا ۔ یہ ایپلیکیشن ڈرائیونگ‬
‫اسکولوں اور ان کے انسٹرکٹرز کو ایک پلیٹ فارم پر رجسٹر کرواائے گی اور سٹوڈنٹ کو اپنی ترجیح کے مطابق‬
‫انسڑٹر یا لوکیشن کے زریعے ڈرائیونگ اسکول منتخب کرنے میں سہولت فراہم کرے گی اسے ہی ڈرائیونگ‬
‫انسٹرکٹرز کو بھی مخصوص ڈرائیونگ اسکول کے تحت رجسٹر ہونے کی اجازت دینا ہے‬

Waterfall model
The classical waterfall model in software engineering divides the life cycle into phases. This
concept assumes that one phase can begin after the previous phase is completed. That is, the
output of one phase becomes the input of the next. As a result, the development process can be
viewed as a sequential flow in a waterfall. The phases do not overlap in this case..

‫ی‬
Spiral model
A spiral model looks like a spiral with many loops. This model supports risk handling, and the
project is delivered in loops. Each loop of the spiral is called a Phase of the software
development process.
The initial phase of the spiral model in the early stages of Waterfall Life Cycle that is needed
to develop a software product. The exact number of phases needed to develop the product can
be varied by the project manager depending upon the project risks. As the project manager
dynamically determines the number of phases, so the project manager has an important role to
develop a product using a spiral model.
VU process model:
The VU process model is a hybrid approach that combines elements of the waterfall and spiral
methodologies. It has five sequential phases: gathering requirements, planning, analysis and
design, development, and final reporting
Use Case Diagrams | Unified Modeling Language (UML)
A Use Case Diagram is a vital tool in system design, it provides a visual representation of how
users interact with a system. It serves as a blueprint for understanding the functional
requirements of a system from a user’s perspective, aiding in the communication between
stakeholders and guiding the development process.

1.1. Actors
Actors are external entities that interact with the system. These can include users, other
systems, or hardware devices

Use Cases
Use cases are like scenes in the play. They represent specific things your system can do.
System Boundary
The system boundary is a visual representation of the scope or limits of the system you are
modeling. It defines what is inside the system and what is outside. The boundary helps to
establish a clear distinction between the elements that are part of the system and those that are
external to it. The system boundary is typically represented by a rectangular box that surrounds
all the use cases of the system.

Association Relationship

The Association Relationship represents a communication or interaction between an actor and

a use case. It is depicted by a line connecting the actor to the use case. This relationship
signifies that the actor is involved in the functionality described by the use case.
Include Relationship
The Include Relationship indicates that a use case includes the functionality of another use
case. It is denoted by a dashed arrow pointing from the including use case to the included use
case. This relationship promotes modular and reusable design.

Example: Social Media Posting

 Use Cases: Compose Post, Add Image
Include Relationship: The “Compose Post” use case includes the functionality of “Add
Image.” Therefore, composing a post includes the action of adding an image.

Extend Relationship
The Extend Relationship illustrates that a use case can be extended by another use case under
specific conditions. It is represented by a dashed arrow with the keyword “extend.” This
relationship is useful for handling optional or exceptional behavior.
Example: Flight Booking System
 Use Cases: Book Flight, Select Seat
 Extend Relationship: The “Select Seat” use case may extend the “Book Flight” use case
when the user wants to choose a specific seat, but it is an optional step.

Generalization Relationship
The Generalization Relationship establishes an “is-a” connection between two use cases,
indicating that one use case is a specialized version of another. It is represented by an arrow
pointing from the specialized use case to the general use case.
Example: Vehicle Rental System
 Use Cases: Rent Car, Rent Bike
 Generalization Relationship: Both “Rent Car” and “Rent Bike” are specialized versions
of the general use case “Rent Vehicle.”

 Sequence Diagram Notation

 Actors
o Lifelines
o Messages
o Create message
o Delete Message
o Self Message
o Reply Message
o Found Message
o Lost Message
o Guards
Sequence Diagram Notation
1. Actors
An actor in a UML diagram represents a type of role where it interacts with the system and its
objects. It is important to note here that an actor is always outside the scope of the system we
aim to model using the UML diagram.

2. Lifelines
Lifeline elements are located at the top in a sequence diagram. We display a lifeline in a
rectangle called head with its name and type. The head is located on top of a vertical dashed
line.

 Difference between a lifeline and an actor

 o A lifeline always portrays an object internal to the system whereas actors are
used to depict objects external to the system.

Messages
Communication between objects is depicted using messages. The messages appear in a
sequential order on the lifeline.
 We represent messages using arrows.

Synchronous messages
A synchronous message waits for a reply before the interaction can move forward. The sender
waits until the receiver has completed the processing of the message. The caller continues only
when it knows that the receiver has processed the previous message i.e. it receives a reply
message.
 A large number of calls in object oriented programming are synchronous.
 We use a solid arrow head to represent a synchronous message.

An asynchronous message does not wait for a reply from the receiver. The interaction moves
forward irrespective of the receiver processing the previous message or not. We use a lined
arrow head to represent an asynchronous message.
Delete Message
We use a Delete Message to delete an object. When an object is deallocated memory or is
destroyed within the system we use the Delete Message symbol. It destroys the occurrence of
the object in the system.It is represented by an arrow terminating with a x.

Self Message
Certain scenarios might arise where the object needs to send a message to itself. Such
messages are called Self Messages and are represented with a U shaped arrow.

Reply messages
Reply messages are used to show the message being sent from the receiver to the sender. We
represent a return/reply message using an open arrow head with a dotted line. The
interaction moves forward only when a reply message is sent by the receiver.

Found Message
A Found message is used to represent a scenario where an unknown source sends the message.
It is represented using an arrow directed towards a lifeline from an end point.
Lost Message
A Lost message is used to represent a scenario where the recipient is not known to the system.
It is represented using an arrow directed towards an end point from a lifeline.

What are class Diagrams?

Class diagrams are a type of UML (Unified Modeling Language) diagram used in software
engineering to visually represent the structure and relationships of classes within a system i.e.
used to construct and visualize object-oriented systems.

What is a class?
In object-oriented programming (OOP), a class is a blueprint or template for creating objects.
Objects are instances of classes, and each class defines a set of attributes (data members) and
methods (functions or procedures) that the objects created from that class will possess. The
attributes represent the characteristics or properties of the object, while the methods define the
behaviors or actions that the object can perform.

1. Class Name:
 The name of the class is typically written in the top compartment of the class box and is
centered and bold.
2. Attributes:
 Attributes, also known as properties or fields, represent the data members of the class.
They are listed in the second compartment of the class box and often include the
visibility (e.g., public, private) and the data type of each attribute.
3. Methods:
  Methods, also known as functions or operations, represent the behavior or functionality
of the class. They are listed in the third compartment of the class box and include the
visibility (e.g., public, private), return type, and parameters of each method.

4. Visibility Notation:
 Visibility notations indicate the access level of attributes and methods. Common
visibility notations include:
o + for public (visible to all classes)
o - for private (visible only within the class)
o # for protected (visible to subclasses)
o ~ for package or default visibility (visible to classes in the same package)
o
Relationships between classes
In class diagrams, relationships between classes describe how classes are connected or interact
with each other within a system. There are several types of relationships in object-oriented
modeling, each serving a specific purpose. Here are some common types of relationships in
class diagrams:
1. Association
An association represents a bi-directional relationship between two classes. It indicates that
instances of one class are connected to instances of another class.
Example:
Let’s consider a simple system for managing a library. In this system, we have two main
entities: Book and Library. Each Library contains multiple Books, and each Book belongs to
a specific Library. This relationship between Library and Book represents an association.

Directed Association
A directed association in a UML class diagram represents a relationship between two classes
where the association has a direction, indicating that one class is associated with another in a
specific way.
 In a directed association, an arrowhead is added to the association line to indicate the
direction of the relationship. The arrow points from the class that initiates the association to
the class that is being targeted or affected by the association
Aggregation
Aggregation is a specialized form of association that represents a “whole-part” relationship. It
denotes a stronger relationship where one class (the whole) contains or is composed of another
class (the part). Aggregation is represented by a diamond shape on the side of the whole class.
In this kind of relationship, the child class can exist independently of its parent class.
Example:
The company can be considered as the whole, while the employees are the parts. Employees
belong to the company, and the company can have multiple employees. However, if the
company ceases to exist, the employees can still exist independently.
Composition
Composition is a stronger form of aggregation, indicating a more significant ownership or
dependency relationship. In composition, the part class cannot exist independently of the whole
class. Composition is represented by a filled diamond shape on the side of the whole class.
example:
Imagine a digital contact book application. The contact book is the whole, and each contact
entry is a part. Each contact entry is fully owned and managed by the contact book. If the
contact book is deleted or destroyed, all associated contact entries are also removed.
Generalization(Inheritance)
Inheritance represents an “is-a” relationship between classes, where one class (the subclass or
child) inherits the properties and behaviors of another class (the superclass or parent).
Inheritance is depicted by a solid line with a closed, hollow arrowhead pointing from the
subclass to the superclass.
Examoe
n the example of bank accounts, we can use generalization to represent different types of
accounts such as current accounts, savings accounts, and credit accounts.
Dependency Relationship
A dependency exists between two classes when one class relies on another, but the relationship
is not as strong as association or inheritance. It represents a more loosely coupled connection
between classes. Dependencies are often depicted as a dashed arrow.
Let’s consider a scenario where a Person depends on a Book.
 Person Class: Represents an individual who reads a book. The Person class depends on the
Book class to access and read the content.
 Book Class: Represents a book that contains content to be read by a person. The Book
class is independent and can exist without the Person class.
example
The Person class depends on the Book class because it requires access to a book to read its
content. However, the Book class does not depend on the Person class; it can exist
independently and does not rely on the Person class for its functionality.
Why primary key is not nul

 Uniqueness:

 The primary key uniquely identifies each record in a table. If a primary key could be null,
it would fail to uniquely identify rows because multiple rows could have a null value,
thus violating the uniqueness constraint.

 Identification:

 The primary key is used to identify a particular row in the table. If it were null, there
would be no way to identify that row distinctly.

Empty and Filled Diamonds in UML

In Unified Modeling Language (UML), diamonds are used to represent different types of
relationships between classes, specifically aggregation and composition.

Empty Diamond: Aggregation

 Symbol: An empty (hollow) diamond.

 Meaning: Aggregation represents a "whole-part" relationship where the part can exist
independently of the whole. This indicates a weak relationship.
 Example: A Library and Books. A book can exist outside of a library; the library may
hold many books, but the existence of books is not dependent on the library.
  Usage: Aggregation is used when one object "has-a" another object, but the lifecycle of
the contained object does not depend on the container object.

Filled Diamond: Composition

 Symbol: A filled (solid) diamond.

 Meaning: Composition represents a "whole-part" relationship where the part cannot exist
independently of the whole. This indicates a strong relationship.
 Example: A Car and its Engine. The engine is an integral part of the car and cannot exist
independently once the car is destroyed.
 Usage: Composition is used when one object "owns" another object, and the lifecycle of
the owned object is tightly coupled to the owner object.