Software Engineering(22413)

Hours: 10 Marks: 14

Prepared by:
Mrs. Kousar Ayub A.
Lecturer(Selection Grade)
Computer Engg. Dept
M. H. Saboo Siddik Polytechnic
Mrs. Kousar Ayub Akumalla
1
 Learning Outcomes
The learners will be able to:
Identify the elements of analysis model
for given s/w
Apply the specified design feature for s/w
Requirement Modeling.
Represent the specified problem in given
designed notation.
Prepare Test Cases for given Model.
Mrs. Kousar Ayub Akumalla 2
 3.1. ANALYSIS MODEL

• The analysis model and requirements

specification provide a means for assessing
quality once the software is built.
• Requirements analysis results in the
specification of software‘s operational
characteristics.

Mrs. Kousar Ayub Akumalla 3

 3.1. ANALYSIS MODEL

• The analysis model is a bridge between the

system description and the design model.
Objectives Analysis model must achieve three
primary objectives:
- Describe Customer needs.
- Establish a basis for software design.
- Define a set of requirements that can be
validated once the software is built.
Mrs. Kousar Ayub Akumalla 4
 Analysis Rules of Thumb
•The model should focus on requirements that
are visible within the problem or business
domain. The level of abstraction should be
relatively high.
•Each element of the analysis model should
add to overall understanding of software
requirements and provide insight into the
information, function, and behavior domains
of the system.
Mrs. Kousar Ayub Akumalla 5
 Analysis Rules of Thumb
•Delay consideration of infrastructure and other non-
functional models until design.
- For example, a database may be required, but the
classes necessary to implement it, the functions
required to access it, and the behavior that will be
exhibited as it is used should be considered only
after problem domain analysis has been
completed.

Mrs. kumalla 6
 Analysis Rules of Thumb
•Minimize coupling throughout the system.
The level of interconnectedness between
classes and functions should be reduced to a
minimum.
•Be certain that the analysis model provides
value to all stakeholders.

Mrs. Kousar Ayub Akumalla 7

 Analysis Rules of Thumb
•Each constituent has its own use for the model.
- Keep the model as simple as it can be.
- Ex: Don't add additional diagrams when they
provide no new information.
- Only modeling elements that have values should
be implemented.

Mrs. Kousar Ayub Akumalla 8

 ELEMENTS OF ANALYSIS
MODEL
1.Flow-oriented modeling
2.Scenario-based modeling
3.Class-based modeling
4.Behavioral modeling

Mrs. Kousar Ayub Akumalla 9

Structured analysis
ELEMENTS OF ANALYSIS
MODEL

Mrs. Kousar Ayub Akumalla 11

 ELEMENTS OF ANALYSIS
MODEL
•Flow-oriented modeling – provides an indication
of how data objects are transformed by a set of
processing functions.
•Scenario-based modeling – represents the
system from the user's point of view.
•Class-based modeling – defines objects,
attributes, and relationships.
•Behavioral modeling – depicts the states of the
classes and the impact of events on these states.
Mrs. Kousar Ayub Akumalla 12
 Write Importance Of Analysis
Modelling. (Study Any 4 Points)
1.Designing gets easier to the designer
2.Better understanding of system can be
accomplished
3.System feasibility can be determined
4.Defines data objects
5.Describes data attributes
6.Establishes data relationships
7.Identifies functions that transform data object
Mrs. Kousar Ayub Akumalla 13
 Write Importance Of Analysis
Modelling. (Study Any 4 Points)
8. Indicates different states of the system
9. Specifies events that cause the system to
change state.
10. Refines each model to represent lower levels
of abstraction
11. Refines data objects
12. Relates a functional hierarchy represent
behavior at different levels of detail
Mrs. Kousar Ayub Akumalla 14
3.2 TRANSLATING REQUIREMENT
MODEL INTO DESIGN MODEL

Mrs. Kousar Ayub Akumalla 15

3.2 TRANSLATING REQUIREMENT
MODEL INTO DESIGN MODEL
• Software design sits at the technical kernel of
software engineering and is applied regardless of the
software process model that is used.
• Beginning once software requirements have been
analyzed and specified, software design is the first of
three technical activities design, code generation, and
test—that are required to build and verify the
software.
• Each activity transforms information in a manner that
ultimately results in validated computer software.
Mrs. Kousar Ayub Akumalla 17
3.2 TRANSLATING REQUIREMENT
MODEL INTO DESIGN MODEL

• Each of the elements of the analysis model

provides information that is necessary to
create the four design models required for a
complete specification of design.

1.The data/class design transforms analysis

classes into design classes along with the data
structures required to implement the software.

Mrs. Kousar Ayub Akumalla 18

3.2 TRANSLATING REQUIREMENT
MODEL INTO DESIGN MODEL
2. The architectural design defines the relationship
between major structural elements of the software;
architectural styles and design patterns help achieve
the requirements defined for the system.
3. The interface design describes how the software
communicates with systems that interoperate with it
and with humans who use it.
4. The component level design transforms structural
elements of the software architecture into a
procedural description of software components.
Mrs. Kousar Ayub Akumalla 19
 3.4 FUNDAMENTAL DESIGN
CONCEPTS
❑ Abstraction:
• When we use modular approach to find the solution to
the problem, there are chances of having different
levels of abstraction at the topmost level of
abstraction; a solution is present in broad terms with
the help of language of the problem environment.
• At the lower levels of abstraction a more detailed
description of the solution is provided. Data
abstraction is named collection of data that describes a
data object.
Mrs. Kousar Ayub Akumalla 20
 3.4 FUNDAMENTAL DESIGN
CONCEPTS
❑ Information Hiding:
• It is about controlled interfaces.
• Modules should be specified and design so that
information (algorithm and data) contained within a
module is inaccessible to other modules that have no
need for such information.
• Hiding implies that effective modularity can be
achieved by defining a set of independent modules that
communicate with one another only that information
necessary to achieve software function.
Mrs. Kousar Ayub Akumalla 21
 3.4 FUNDAMENTAL DESIGN
CONCEPTS
❑ Information Hiding:
• The use of Information Hiding as a design criterion for
modular systems provides the greatest benefits when
modifications are required during testing and later,
during software maintenance.
• Because most data and procedures are hidden from
other parts of the software, inadvertent errors
introduced during modifications are less likely to
propagate to other location within the software.

Mrs. Kousar Ayub Akumalla 22

 3.4 FUNDAMENTAL DESIGN
CONCEPTS
❑ Structure:
• Structure is a fundamental characteristics of
computer software. The use of structuring permits
decomposition of a large system into smaller, more
manageable units with well-defined relationships to
the other units in the system.
• The structure of the system is composed of
various components of a system/program, the
attributes of those components and the relationship
amongst them.
Mrs. Kousar Ayub Akumalla 23
 3.4 FUNDAMENTAL DESIGN
CONCEPTS
❑ Modularity:
• Software is divided into separately named and
addressable components, called modules that are
integrated to satisfy problem requirements.
• Modularity is the single attribute of software that
allows a program to be intellectually manageable.
• Modularity enhances design clarity, which in turn
eases implementation, debugging, testing,
documenting and maintenance of the software
product.
Mrs. Kousar Ayub Akumalla 24
 3.4 FUNDAMENTAL DESIGN
CONCEPTS
❑ Concurrency:
• Concurrent systems have independent processes that
can be activated simultaneously if multiple processors
are available.
• If software design, concurrency is implemented by
splitting the software into multiple independent units of
execution, like modules and executing them in parallel.
• In other words, concurrency provides capability to the
software to execute more than one part of code in parallel
to each other.
Mrs. Kousar Ayub Akumalla 25
 3.4 FUNDAMENTAL DESIGN
CONCEPTS
❑ Verification:
• Verification is a fundamental concept in software
design. Design is the bridge between customer
requirements and an implementation of software that
satisfies those requirements.
• A design is verifiable if it can be demonstrated that
the design will result in an implementation that
satisfies the customer’s requirements.

Mrs. Kousar Ayub Akumalla 26

 3.4 FUNDAMENTAL DESIGN
CONCEPTS
❑ Aesthetics:
• Aesthetics considerations are fundamental to design,
whether in art or technology. Simplicity, elegance, and
clarity of purpose distinguish products of outstanding
quality from mediocre products.
• Software engineering is a largely creative design
discipline, where new designs are created from scratch.
It is difficult to list objective criteria for evaluating the
aesthetic factors in a software product, but an
aesthetically pleasing product is easily recognized.
Mrs. Kousar Ayub Akumalla 27
 3.5 DATA FLOW DIAGRAM
What is DFD? Explain its symbol
1)Data Flow Diagram (DFD) is also called as
Bubble chart‘. This is a graphical technique that
represents information flow, and transformer
those are applied when data moves from input
to output.
2)DFD represents system requirements those
becomes program in design.

Mrs. Kousar Ayub Akumalla 28

 3.5 DATA FLOW DIAGRAM
3)DFD may be further partitioned into different
levels to show detailed information flow e.g. level
0, level 1, level 2 etc.
4)DFD focuses on the fact what data flow, rather
how data is processed

Mrs. Kousar Ayub Akumalla 29

 3.5 DATA FLOW DIAGRAM
5) DFD is used to represent information flow, and
the transformers those are applied when data
moves from input to output.

6)To show the data flow with more details the DFD
is further extended to level 1, level 2, level 3 etc.
as per the requirement.

Mrs. Kousar Ayub Akumalla 30

 3.5 DATA FLOW DIAGRAM
• The symbols that are used are-
NAME SYMBOL DESCRIPTION

Entity A system comes into action based on

input signal or data it receives from an
entity. Used to represent people and
organizations outside the system. They
either input information to the system,
accept output information from the
system or both.

Process The process causes some

transformation to data. A process
accepts input data and produces data
that it passes on to another part of DFD
Mrs. Kousar Ayub Akumalla 31
 3.5 DATA FLOW DIAGRAM
Data It represents flow of data to or
Flow from a process.

Data Here, data is stored either

Store temporarily or permanently. Data
elements stored in a data file are
called data store.

Mrs. Kousar Ayub Akumalla 32

 DECISION TABLE
• Explain with example- Decision table
•Decision table is a software testing technique used
to test system behavior for different input
combinations.
•This is a systematic approach where the different
input combinations and their corresponding system
behavior (Output) are captured in a tabular form.
•That is why it is also called as a Cause-Effect table
where Cause and effects are captured for better test
coverage.
Mrs. Kousar Ayub Akumalla 33
Data flow diagram level 0 and 1 for a
Book publishing House
Level 1 DFD for Book Publishing House
 Example
• Draw Level 0 and Level1 DFD for Food
Ordering System.
• Draw level 0 and Level 1 DFD for Online
Shopping System
• Draw level 0 and Level 1 DFD for Banking
 Data Dictionary
• Data dictionary is the centralized collection of information
about data.
• It stores meaning and origin of data, its relationship with
other data, data format for usage etc.
• Data dictionary is often referenced as meta-data (data about
data) repository.
• It is created along with DFD (Data Flow Diagram) model of
software program and is expected to be updated whenever
DFD is changed or updated.
• Data dictionary provides a way of documentation for the
complete database system in one place. Validation of DFD is
carried out using data dictionary.
 Requirement of Data Dictionary

• The data is referenced via data dictionary while

designing and implementing software.
• Data dictionary removes any chances of
ambiguity.
• It helps keeping work of programmers and
designers synchronized while using same
object reference everywhere in the program.
 Contents

Data dictionary should contain information about

the following
1. Data Flow
2. Data Structure
3. Data Elements
4. Data Stores
5. Data Processing
Data Flow is described by means of DFDs as
studied earlier and represented in algebraic
form as described.
= Composed of
{} Repetition
() Optional
+ And
[ / ] Or
Example:
Address = House No + (Street / Area) + City + State
Course ID = Course Number + Course Name + Course Level +
Course Grades
 Data Elements

Data elements consist of Name and descriptions

of Data and Control Items, Internal or External
data stores etc. with the following details:
1. Primary Name
2. Secondary Name (Alias)
3. Use-case (How and where to use)
4. Content Description (Notation etc. )
5. Supplementary Information (preset values,
constraints etc.)
 Example
• Name: Mobile Number
• Alias: Mob-no
• Where used/How used:
Dial Phone and send Msg.
• Description:
Mob-no=country code+ mobile
number.
Data Store: It stores the information from where
the data enters into the system and exits out of
the system. The Data Store may include -
• Files
– Internal to software.
– External to software but on the same machine.
– External to software and system, located on different
machine.
• Tables
– Naming convention
– Indexing property
Data Processing
There are two types of Data Processing:

Logical: As user sees it

Physical: As software sees it
 The Control specification
The Control specification (CSPEC) represent the
behavior of a system in two different ways but it
gives no information about the inner working of
the processes that are activated as a result of this
behavior.
1.State diagram- sequential specification of behavior
2.Program activation table- combinatorial
specification of behavior.
 The process specification
The process specification(PSPEC) is used to
describe all flow model processes that appear at
the final level of refinement.
The content of process specification can include
narrative text, program design language
(PDL),mathematical equation, tables,diagrams
,charts etc.
Using process specification engineer creates mini
specification that can serve as a guide of the s/w
component that will implement the process.
 Scenario Based Modeling
If s/w engineer understand how end users
want to interact with a system ,s/w team will
be better able to properly characterized
requirement and build meaningful analysis
and design model.
It begins with the creation of scenarios with
the help of:-
1. Use case diagram
2. Activity diagram
3. Swim lane diagram.
 Developing/writing use cases
The use case captures the interaction that
occur between producers and consumers of
information and system itself.
 Purpose of Use Case
⚫ Use cases are used to model the system from
the point of view of end user.
⚫ Person or thing that are involved are called
as actors and the operations that take place
are called as actions.
⚫ Use case helps in understanding the exact
product requirements
⚫ Providing a clear and unmistakable
description of how system and end user
interact with each other.
⚫ Provide basis for the purpose of validation
testing.
 Activity Diagram
The UML (Unifies Modeling Language) activity
diagram supplements the use case by providing
a graphical representation of the flow of
interaction within a specific scenario.
An activity diagram uses rounded rectangles to
imply a specific systems function, arrows to
represent flow through the system, decision
diamonds to depict a branching decision and
solid horizontal lines to indicate that parallel
activities are occuring.
 Behavioral model
The behavior model indicates how s/w will respond to
external events.
To create the behavior model analyst must perform
following steps:-
1. Evaluate all use cases to fully understand the sequence of
interaction within system.
2. Identify the events and understand how these events
relates to specific classes.
3. Create a sequence for each use case.
4. Build the static diagram for the system.
5. Review the model to verify accuracy and consistency.
A event occurs whenever the system and an
actor exchange information.
It is important to note that an event is not the
information that has been exchanged,but
rather the fact that information has been
exchanged.
Example. Homeowner enters a 4-digit pwd.
here object homeowner transmits an event
to the object control panel. here event is
password entered. The information
transferred is 4-digit that constitute the
pwd,but this is not an essential part of
behavioral model.
It is imp to note that some events have an
explicit impact on the flow of control of use
case,while others have no direct impact on
the flow of control.
Event pwd entered does not explicitly change
the flow of control but the result of event
compare password will have explicit impact
on the information and control flow of safe
home system.
 State Representation
Two different characterizations of states must
be considered.
I) It shows how change proceed over time, it
shows the dynamic nature of a system.
II) Clarify following things for state diagram
- identify object
- identify state
- identify event.
State diagram for control panel class
 Sequence Diagrams

From examining use case diagram for events,

modeler creates a sequence diagram- a
representation of how events cause flow
from one object to another as a function of
time.
It represents key classes and the events that
cause behavior to flow from class to class.
 DECISION TABLE
Example 1: Decision Base Table for Login Screen

The condition is simple if the user provides correct

username and password the user will be redirected to the
homepage. If any of the input is wrong, an error message
will be displayed.
Mrs. Kousar Ayub Akumalla 64
 DECISION TABLE

Legend:
T – Correct username/password
F – Wrong username/password
E – Error message is displayed
H – Home screen is displayed
Mrs. Kousar Ayub Akumalla 65
 DECISION TABLE
• Interpretation:
• Case 1 – Username and password both were
wrong. The user is shown an error message.
• Case 2 – Username was correct, but the password
was wrong. The user is shown an error message.
• Case 3 – Username was wrong, but the password
was correct. The user is shown an error message.
• Case 4 – Username and password both were
correct, and the user navigated to homepage.
Mrs. Kousar Ayub Akumalla 66
 3.6 TESTING

What is software testing?

• Software testing is an activity to uncover
errors.
• The purpose of software testing is to ensure
whether the software functions appear to be
working according to specifications and
performance requirements.

Mrs. Kousar Ayub Akumalla 67

 3.6 TESTING

• List four objectives of testing.

1.Finding programming defects.
2.Gaining confidence in and providing
information about the level of quality.
3.To make sure that the end result meets the
business and user requirements.
4.To ensure that it satisfies SRS that is System
Requirement Specifications.
Mrs. Kousar Ayub Akumalla 68
 Benefits of s/w testing:-
1.Integration risk is minimized.
2.The quality of the end product is improved.
3.Error diagnosis and correction are simplified.
4.Progress is easier to assess.
 White Box Testing
⚫ White Box Testing is also known as glass box
testing or clear box testing.
⚫ In White Box Testing code is tested and it is
done by s/w developers.
⚫ In this testing test cases are written to check :-
1. Independent paths atleast once
2. All logical decision(true or false)
3. All loops( boundaries)
4. All internal data structures.
 Cont.
White Box Testing helps to remove the logical
errors,logical path related errors.
The types of White Box Testing are statement
testing,condition coverage and decision
coverage.
 Black box testing
Black box testing ignores the internal
mechanism of the system or components
and focuses only on the o/p generated.
Here system is considered as a black box.
I/p are given and o/p are compared against
specification.
Test cases are based on requirements
specification.
Here testers do not requires the knowledge
of code in which system is developed.
 3.7 Difference between Black box
testing and white box testing
BLACK BOX TESTING WHITE BOX TESTING
1. Black box testing is called as White box testing is called as glass
behavioral testing box testing
2. Black box testing examines some In white box testing, internal logic is
fundamental aspects of the system closely examined.
with little regard for internal
logical structure of the software.

3. Testing is done by customers as Testing is done by developers

well as developers
4. This type of testing is suitable for This type of testing is suitable for
large projects small projects.
5. During black box testing the White box testing lead to test the
program cannot be tested 100 program thoroughly.
percent
6. Programming knowledge is not Programming knowledge is required.
Mrs. Kousar Ayub Akumalla 73
required here.
3.8 Unit Testing

Mrs. Kousar Ayub Akumalla 74

 3.8 Unit Testing
• Testing that occurs at the lowest level is called unit testing
or module testing. In this type of testing techniques are
applied to detect errors from each software component
individually.
• Unit testing is performed to test the individual units of
software. Unit is the smallest part of software system which
is testable.
• Individual components are tested independently to
ensure their quality.
• The focus is to uncover error in design and
implementation.
Mrs. Kousar Ayub Akumalla 75
 3.8 Unit Testing
• The various tests that are conducted during unit testing are described
below:
1. Module interfaces are tested for proper information flow
in and out of the program
2. Local data are examined to ensure that integrity is
maintained.
3. Boundary conditions are tested to ensure that the module
operates properly at the boundaries established to limit
or restrict processing.

Mrs. Kousar Ayub Akumalla 76

 3.8 Unit Testing
4. All the independent paths are tested for ensuring that
all statements in the module have been executed only
once.
5. All error handling paths should be tested.

Drivers and stubs are two such elements used in software

testing process, which act as a temporary replacement for
a module.

Mrs. Kousar Ayub Akumalla 77

 Unit test procedures
In most applications a driver is nothing more then
a main program that accepts test case data
passes to component to be tested and prints
results.
Stubs serves to replace modules that are called by
the component to be tested.
A stub or dummy sub program uses the sub
ordinate modules interface, may do data
manipulation, provides verification and returns
control to the module under going testing.
Drivers and stub are kept simple, actual over head
is kept low.
 cont
Example of Stubs and Drivers is given below:-
For Example we have 3 modules login, home, and
user module. Login module is ready and need to
test it, but we call functions from home and user
(which is not ready). To test at a selective module
we write a short dummy piece of a code which
simulates home and user, which will return values
for Login, this piece of dummy code is always
called Stubs and it is used in a top down
integration.

Mrs. Kousar Ayub Akumalla 79

 Example
Considering the same Example above: If we have Home
and User modules get ready and Login module is not
ready, and we need to test Home and User modules
Which return values from Login module, So to extract
the values from Login module We write a Short Piece of
Dummy code for login which returns value for home
and user, So these pieces of code is always called
Drivers and it is used in Bottom Up Integration
Conclusion:-
So it is fine from the above example that Stubs act
“called” functions in top down integration. Drivers are
“calling” Functions in bottom up integration.

Mrs. Kousar Ayub Akumalla 80

 Example
Suppose you have a function (Function A) that
calculates the total marks obtained by a student in
a particular academic year. Suppose this function
derives its values from another function (Function
b) which calculates the marks obtained in a
particular subject.
You have finished working on Function A and wants
to test it. But the problem you face here is that
you can't seem to run the Function A without
input from Function B; Function B is still under
development.
 Cont.
In this case, you create a dummy function to act in
place of Function B to test your function. This
dummy function gets called by another function.
Such a dummy is called a Stub.

To understand what a driver is, suppose you have

finished Function B and is waiting for Function A
to be developed. In this case you create a dummy
to call the Function B. This dummy is called the
driver.
Mrs. Kousar Ayub Akumalla 82
 3.9 TEST DOCUMENTATION
Test Case Template
1.Test Case ID: Unique ID for each test case.
2.Test Case Objectives: Functionality which is to be
tested.
3.Pre-requisites: Any pre-condition that must be
fulfilled before execution of the test case
4.Steps: List of all test execution steps in detail. Write
test steps in the order in which these should be
executed.
5.Input: Use of test data as an input for the test case.
You can provide different data sets with exact values
to be used as an input.
Mrs. Kousar Ayub Akumalla 83
 3.9 TEST DOCUMENTATION
6.Expected Results: Describe the expected result in
detail including message/ error that should be
displayed on screen.
7.Actual Results: Actual result should be filled after test
execution.
8.Status: If actual result is not as per the expected result
mark the test as failed. Otherwise update the test as
pass.

Mrs. Kousar Ayub Akumalla 84

 WHAT IS TEST PLAN?
Test plan: A document describing the scope, approach,
resources and schedule of intended test activities.
• It identifies amongst others test items, the features to
be tested, the testing tasks, who will do each task,
degree of tester independence, the test environment,
the test design techniques and entry and exit criteria
to be used, and the rationale for their choice, and any
risks requiring contingency planning.
• It is a record of the test planning process master test
plan: A test plan that typically addresses multiple test
levels.
Mrs. Kousar Ayub Akumalla 85
 .
Defect Report

1. Defect ID Unique identifier given to a defect

2. Defect Name Name of the defect. It should be intuitive

about the kind of defect
3. Project Name Name of the project in which the defect
is found
4. Module Name of the module or sub-module in
Name which the defect is located

Mrs. Kousar Ayub Akumalla 86

 .
Defect Report
5. Phase There are various project life cycle phases
Introduced such as requirements gathering, design,
coding, testing and maintenance. The defect
might occur in any of these phases. The
defect template gives information about
when defect has been introduced. If the
tester is not aware of the defect introduction
phase, the person doing an analysis may
add this defect introduction in defect
template. This also helps in identifying
defect leakage from one phase to another.
6. Phase Found Phases of the project when the defect found
is addedMrs.here
Kousar Ayub Akumalla 87
 .
Defect Report
7. Defect Type Various defect types are – Functionality
defects, Security defects, user interface
defects. The information about defect type
is written here.
8. Defect Defect Severity might be from critical,
Severity high, medium and low. For instance –
S1 indicates defect is critical because
some functionality might be missing
S2 indicates that the functionality is not
present but the work around is possible.
S3 indicates that defect is of minor nature.
Mrs. Kousar Ayub Akumalla 88
 .
Defect Report
9. Priority Priority defines how to take defects for fixing.
The priority is defined as high, medium and
low. The highest priority defects affect the
people or users
10. Summary The defect is described in the shortest possible
way
11. Description It describes the defect in detail. It must include
what has been observed and the defect’s possible
impact on users. It must include the steps for
reproducing defect, the expected outcome and
what was observed by the tester. It must include
error logs, screenshots showing the defect, video
clips supporting the stages to produce a defect
Mrs. Kousar Ayub Akumalla 89
 .
Defect Report

12. Status Status of a defect is a dynamic field.

Typically, the status of the defect is –
‘open’, ‘assigned’, ‘closed’, ‘hold’,
‘deferred’ or ‘reopened’.
13. Reported by Information of the tester who found the
defect and date of defect on which it is
found.
14. Assigned to The name of the person who is responsible
for handling the defect.

Mrs. Kousar Ayub Akumalla 90

THANK YOU…..

Mrs. Kousar Ayub Akumalla 91