SOFTWARE ENGINEERING

4/24/2023
Software
engineering
3.Software Modeling and design

YASHVANT MANE 1
 SOFTWARE ENGINEERING

Translating Requirement model into design model

i. translating a requirement model into a design model is an important step in the

software development process. It involves taking the functional and non-functional
requirements identified in the requirement model and creating a design model that
can be used to develop the software system.
ii. The design model defines the architecture, components, interfaces, and algorithms
of the software system. It provides a blueprint for how the software system will be
built, tested, and maintained. The design model is typically created by software
architects and designers who have expertise in software engineering principles and
practices.
iii. The process of translating a requirement model into a design model typically
involves several steps, including:
iv. Analyzing the requirements: The first step is to analyze the requirements in detail
to understand their dependencies, constraints, and relationships.
v. Identifying design patterns: Design patterns are reusable solutions to common
design problems. Identifying appropriate design patterns can help simplify the
design process and improve the quality of the resulting software system.
vi. Creating a conceptual design: The conceptual design defines the high-level
architecture of the software system, including the components, modules, and
interfaces.

YASHVANT MANE 2
 SOFTWARE ENGINEERING

vii. Refining the design: The design is refined to include details such as data structures,
algorithms, and user interfaces. The design is also reviewed and revised as
necessary to ensure that it meets the requirements and is feasible to implement.
viii. Documenting the design: The design model is documented in detail to provide a
clear and comprehensive description of the software system. This documentation is
used by developers to implement the software system and by testers to verify that it
meets the requirements.
ix. Overall, translating a requirement model into a design model is a critical step in the
software development process. It ensures that the software system is designed to
meet the needs of its users and that it is implemented in a structured and organized
manner.

Data Modeling

Data modelling is the basic step in the analysis modelling. In data modelling the data
objects are examined independently of processing.

1. Data object is a collection of attributes that act as an aspect, characteristic, quality

or descriptor of the object

2. In data modeling, attributes refer to the characteristics or properties of an entity or

object. Attributes describe the data that needs to be stored about an entity, and they
help define the structure of a database.

YASHVANT MANE 3
 SOFTWARE ENGINEERING

3. In data modeling, relationships refer to the associations or connections between

two or more entities or objects. Relationships define how entities relate to each
other and how they interact in the context of a particular domain.
4. Cardinality in data modeling refers to the numerical relationship between two
entities in a relationship. It defines how many instances of one entity are related to
how many instances of another entity.
5. Modality in data modeling refers to the participation of an entity in a relationship.
It specifies the minimum and maximum number of times an instance of an entity
can participate in a relationship.

Analysis modeling

Elements of analysis modeling

Analysis Model

i. An analysis model is a high-level representation of a system or application that

captures the user's requirements, business rules, and system behaviors in a concise
and organized manner. It is created during the requirements analysis phase of the
software development lifecycle and serves as a blueprint for the design and
implementation of the system.
ii. The purpose of the analysis model is to provide a clear and comprehensive

YASHVANT MANE 4
 SOFTWARE ENGINEERING

understanding of the requirements and functions of the system, without getting into
implementation details. The analysis model typically includes use cases, activity
diagrams, class diagrams, and sequence diagrams, which describe the behavior,
structure, and interactions of the system components.
iii. The analysis model is an essential tool for communication between the
stakeholders, including the users, developers, and testers, as it provides a common
understanding of the system's requirements and functionalities. It helps to identify
potential problems and inconsistencies early in the development process, which
can save time and money in the long run.
iv. Overall, the analysis model is a vital component of the software development
process, as it provides a clear and comprehensive representation of the system's
requirements and behavior, which serves as a foundation for the design,
implementation, and testing of the system.

Following are the elements of analysis model: -

1) Scenario based elements
2) Flow-oriented elements
3) Behavioral elements
4) Class based elements

Design modeling

1) Abstraction :-
i. In fundamental design concepts, an abstract refers to a concept or idea
that is not concrete or tangible, but rather a generalization of specific
objects or entities. An abstract concept represents a high-level view of
something, without getting into the details of its implementation.
ii. In software design, abstraction is used to simplify complexity and create
a model of the system that is easier to understand and manipulate. It
involves identifying the essential characteristics of a system, ignoring the
irrelevant details, and creating a simplified representation of the system's
behavior.

YASHVANT MANE 5
 SOFTWARE ENGINEERING

2) Information Hiding: -
i. Information hiding is a fundamental design concept in software
engineering that aims to protect the internal details of a system from
being exposed or modified by external entities.
ii. In the context of design modeling, information hiding involves creating a
clear separation between different aspects of the system, such that each
aspect can be designed and developed independently without affecting
the others.
3) Structure :-
i. Structure is a fundamental design modeling principle that refers to the
arrangement of elements in a system, and the relationships between those
elements.
ii. In software engineering, structure is important because it determines the
organization of the code, and can affect the efficiency, maintainability,
and scalability of the system.
4) Modularity :-
i. Modularity is a fundamental design modeling principle that refers to the
ability of a system to be broken down into smaller, self-contained parts,
or modules. In software engineering, modularity is important because it
allows different parts of the system to be developed and tested
independently, and can make it easier to maintain and modify the system
over time.
5) Concurrency :-
i. Concurrency is a fundamental design modeling principle that refers to the
ability of a system to handle multiple tasks or processes simultaneously.
ii. In software engineering, concurrency is important because it can improve
the performance and responsiveness of the system, and can make it easier
to handle large volumes of data and requests.
6) Verification:-
i. Verification in design modeling refers to the process of evaluating
whether the design model meets the specified requirements and conforms
to the desired standards.
ii. Verification is an important aspect of design modeling as it helps to
ensure that the system will function as intended and that it will meet the
needs of the users and stakeholders.
7) Aesthetics :-
i. Aesthetics in design modeling refers to the visual and sensory appeal of
the system, including its layout, color scheme, typography, and other
design elements.
ii. Aesthetics is an important aspect of design modeling as it can impact the

YASHVANT MANE 6
 SOFTWARE ENGINEERING

user's perception of the system and can influence their overall experience
and satisfaction with it.

Design Notations

Data flow diagram

i. The data flow diagrams depict the information flow and the transforms
that are applied on the data as it moves from input to output.
ii. The symbols that are used in data flow diagrams are -
iii. The data flow diagrams are used to represent the system at any level of
abstraction.
1. The DFD can be partitioned into levels that represent increase in
information flow and detailed functionality.
2. A level 0 DFD is called as ‘fundamental system model’ or
‘context model’. In the context model the entire software system
is represented by a bubble with input and output indicated by
incoming and outgoing arrows.
3. Each process shown in level 1 represents the sub functions of
overall system.
4. The number of levels in DFD can be increased until every process
represents the basic functionality.
5. As the number of levels gets increased in the DFD, each bubble
gets refined. The following figure shows the leveling in DFD.
Note that the information flow continuity must be maintained.

YASHVANT MANE 7
 SOFTWARE ENGINEERING

❖ LEVEL 0 DFD :-

❖ Level 1 DFD :-

YASHVANT MANE 8
 SOFTWARE ENGINEERING

Structured flowchart: -
i. The structure chart is a principal tool of structured design.
ii. The basic element in the structured chart is module. Module is defined as
a collection of program statement with four attributes.
iii. Input and output: What the module get from the invoker is called input
and what the receiver gets from the module is called output.
iv. Function: The function processes the input and produces the output.
v. Mechanics: The code or the logic by which the function is carried out.
vi. Internal data: It is the own workspace.
vii. The two modules can be connected to each other by a connector as
shown below
viii. The module uses data and flags. The data is processed by different
modules. The flag is used as a control signal. It can be set or reset.
ix. For example, if we have two modules one for getting the employee
detail(subordinate) and another module is for finding the employee’s
name(superordinate). Then the caller module will send the data as
employee’s ID and using that ID the called module will find the name of
employee. If the employee ID is valid then that message will be given by
the called module to a caller module. The use of data and flag can be as
shown below.
x. The iterations and decisions on a structured chart are as shown below.

YASHVANT MANE 9
 SOFTWARE ENGINEERING

Decision Table :-
i. A decision table is a design notation used in software engineering to
represent complex decision-making processes.
ii. It is a table that lists all possible combinations of conditions and the
corresponding actions or outcomes.
iii. Each row of the decision table represents a unique combination of
conditions, while each column represents a particular action or outcome.
iv. The conditions are typically expressed as Boolean expressions, which can be
true or false depending on the inputs or state of the system.
v. The actions or outcomes can be any desired result or response of the system,
such as an error message, a calculation, or a change in state.
vi. Decision tables are commonly used in situations where there are multiple
inputs or conditions that can affect the behavior or output of the system, and
where there are different actions or outcomes that can result from these
inputs or conditions. They can help to simplify complex decision-making
processes, reduce errors and inconsistencies, and provide a clear and concise
representation of the system's behavior.
vii. Overall, decision tables are a useful tool in design modeling, as they can
help to represent complex decision-making processes in a simple and
intuitive way.
viii. By using decision tables, software engineers can design systems that are
more efficient, effective, and reliable, and that can better meet the needs and
expectations of the users and stakeholders.
Ex:-

YASHVANT MANE 10
 SOFTWARE ENGINEERING

Testing

Meaning of Testing
i. In software engineering, testing refers to the process of evaluating a software
application or system to identify defects or errors in its functionality,
performance, security, usability, and other quality attributes. The main goal
of testing is to ensure that the software meets the intended requirements and
works as expected under different conditions and scenarios.
ii. Testing involves various techniques and methodologies, such as manual
testing, automated testing, unit testing, integration testing, regression testing,
acceptance testing, and more. These techniques can be applied at different
stages of the software development life cycle (SDLC), including
requirements gathering, design, coding, testing, and maintenance.

Purpose of testing
1) The purpose of testing in software engineering is to ensure that a software
application or system meets the intended requirements and functions
correctly, reliably, and efficiently under different conditions and scenarios.
Here are some of the main purposes of testing:
i. Identifying defects: Testing helps to identify defects or errors in the
software, including bugs, glitches, and other issues that can affect the
functionality, performance, security, and usability of the system. By
detecting these defects early in the development process, testing helps
to reduce the cost and time required for fixing them.
ii. Ensuring quality: Testing helps to ensure the quality and reliability
of the software by verifying that it meets the specified requirements
and performs as expected. Testing also helps to ensure that the
software is easy to use and provides a good user experience.
iii. Improving performance: Testing helps to identify performance
bottlenecks and other issues that can affect the speed, responsiveness,
and scalability of the software. By optimizing performance, testing
helps to ensure that the software can handle the expected workload
and provide a fast and seamless user experience.
iv. Enhancing security: Testing helps to identify security vulnerabilities
and other risks that can compromise the confidentiality, integrity, and
availability of the software and its data. By addressing these security
issues, testing helps to ensure that the software is safe and secure for
its intended use.

YASHVANT MANE 11
 SOFTWARE ENGINEERING

v. Ensuring compliance: Testing helps to ensure that the software

complies with applicable laws, regulations, and industry standards,
such as data privacy laws, accessibility guidelines, and security
standards.

Testing methods

Testing methods
1. Black box testing
2. White box testing

1. Black box testing

i. Black box testing involves testing a system with no prior knowledge of its
internal workings.
ii. A tester provides an input, and observes the output generated by the system
under test.
iii. This makes it possible to identify how the system responds to expected and
unexpected user actions, its response time, usability issues and reliability
issues.
iv. Black box testing is a powerful testing technique because it exercises a
system end-to-end.
v. Just like end-users “don’t care” how a system is coded or architected, and
expect to receive an appropriate response to their requests, a tester can
simulate user activity and see if the system delivers on its promises. Along
the way, a black box test evaluates all relevant subsystems, including
UI/UX, web server or application server, database, dependencies, and
integrated systems.
vi. An example of a security technology that performs black box testing is
Dynamic Application Security Testing (DAST), which tests products in
staging or production and provides feedback on compliance and security
issues.

YASHVANT MANE 12
 SOFTWARE ENGINEERING

Advantages of Black box testing: -

Disadvantages of black box testing

i. Limited coverage, since only a selected number of test scenarios is actually
performed.
ii. Inefficient testing, due to the fact that the tester only has limited knowledge
about an application.
iii. Blind coverage, since the tester cannot target specific code segments or
error-prone areas.
iv. The test cases are difficult to design.

2. White Box testing

i. White box testing techniques analyze the internal structures the used data
structures, internal design, code structure, and the working of the software
rather than just the functionality as in black box testing.
ii. It is also called glass box testing or clear box testing or structural testing.
White Box Testing is also known as transparent testing, open box testing.
iii. White box testing is a software testing technique that involves testing the
internal structure and workings of a software application.
iv. The tester has access to the source code and uses this knowledge to design

YASHVANT MANE 13
 SOFTWARE ENGINEERING

test cases that can verify the correctness of the software at the code level.
v. White box testing is also known as structural testing or code-based testing,
and it is used to test the software’s internal logic, flow, and structure.
vi. The tester creates test cases to examine the code paths and logic flows to
ensure that they meet the specified requirements.

Advantages of White box testing:

i. White box testing is very thorough as the entire code and structures are
tested.
ii. It results in the optimization of code removing error and helps in removing
extra lines of code.
iii. It can start at an earlier stage as it doesn’t require any interface as in case of
black box testing.
iv. Easy to automate.
v. White box testing can be easily started in Software Development Life Cycle.
vi. Easy Code Optimization.

Disadvadvantages of White box testing

i. It is very expensive.
ii. Redesign of code and rewriting code needs test cases to be written again.
Testers are required to have in-depth knowledge of the code and
programming language as opposed to black box testing.
iii. Missing functionalities cannot be detected as the code that exists is tested.
iv. Very complex and at times not realistic.
v. Much more chances of Errors in production.

Level of testing

Unit testing
i. Unit testing is the first level of testing. This testing is the most basic
type of testing done by the developers before handing the
software/product to the testing team.
ii. Unit Testing Definition: Unit testing is a type of software testing in
which individual units or components of the software are tested.
iii. Primary Objective: The main objective of unit testing is to isolate
each component of the software and then perform tests to illustrate
that every individual component is accurately meeting the

YASHVANT MANE 14
 SOFTWARE ENGINEERING

requirements and delivering the expected output.

iv. Also explore: Software Engineer Online Courses & Certifications

Advantages of Unit Testing

i. Here are some of the advantages of unit testing:
ii. Helps to catch bugs/defects earlier, which preserves both – time and money
iii. Detects regression bugs (It is a kind of bug that is not found until and unless
the
iv. software/product is released or is in production)
v. Helps to understand the behavior of the code
vi. The cost of conducting unit testing is low.

Disadvantages of Unit Testing

i. Here are some of the disadvantages of unit testing, such as:
ii. Writing test cases takes time.
iii. Unit testing is incapable of detecting all errors.
iv. GUI code testing must be performed correctly, as it will be challenging to
test the
v. software’s graphical user interface using unit testing.

YASHVANT MANE 15
 SOFTWARE ENGINEERING

Test Documentation

Test case template

1. Test cases are used to determine the presence of fault in the program.
Sometimes even if there is some fault in our program the correct output can
be obtained for some inputs. Hence it is necessary to exercise those set of
inputs for which faults (if any) can be exposed off.
2. Executing test cases require money because –machine time is required to
execute test cases human efforts are involved in executing test cases. Hence
in the project testing minimum number of test cases should be there as far as
possible.
3. The testing activity should involve two goals –
i. Maximize the number of errors detected.
ii. Minimize the number of test cases.
4. Selection of test cases is determined by some criteria which is called as test
selection criterion. Hence the test selection criterion T can be defined as the
set of conditions that must be satisfied by the set of test cases.
5. Testing criterion are based on two fundamental properties - reliability and
validity.
6. A test criterion is reliable if all the test cases detect same set of errors.
7. A test criterion is valid if for any error in the program there is some set
which causes error in the program.
8. For testing criteria there is an important theorem - “if testing criterion is
valid and reliable if a set satisfying testing criterion succeeds then that
means program contains no errors".
9. Generating test cases to satisfy criteria is complex task.

YASHVANT MANE 16
 SOFTWARE ENGINEERING

Test plan
1. Test plan is not a static document. It gets generated during the development.
The main purpose of test planning is to describe the product tests and to
establish the standards in testing process. The structure of test plan is as
given below.
i. Testing process in this section various phases of testing process are
described.
ii. Requirements traceability Testing should be planned to meet all the
requirements.
iii. Tested items the tested products of software are tested.
iv. Testing schedule It includes testing schedule and resource allocation
for this schedule.
v. Test recording procedures After running the tests, it is necessary to
record those tests in order to check whether tests are conducted
systematically or not.
vi. Hardware and software requirements the required software tools
and hardware utilization is specified under this section.
vii. Constraints All the factors affecting the testing process are listed

YASHVANT MANE 17
 SOFTWARE ENGINEERING

Introduction to test defect report

Test summary report

1. Test Objective – Include the purpose of the testing, this shows that the test
object and the requirement were clear with the testing team.
2. Areas Covered – Include the areas and the functionalities of the product
that were covered in testing. It need not capture each and every test scenario in
detail but should cover all the areas at a high level.

YASHVANT MANE 18
 SOFTWARE ENGINEERING

3. Areas Not Covered – It is very essential to capture the areas of the product
that were not covered in testing. Any areas not tested can raise an alarm at the
client’s end, so we should ensure that anything that has been left untested is noted
and expectations around it are set accordingly. Also, ensure that each point has an
associated reason, for example, limitation of access to the availability of devices.
4. Testing Approach – This is important to cover since it indicates what and
how the testing was performed. Ensure to provide details of the steps taken and the
types of testing approaches that were adopted to achieve the task.
5. Defect Report – Defect Report, though it usually gets captured already in
the bug report, having it included in the test summary report can give an additional
advantage to your report.
6. Platform Details – Nowadays, products are tested across multiple
platforms. With the growing demand, testing is not just limited to multiple devices
or browsers but different versions as well. So, let’s ensure to include details of
every single platform and environment on which the product was tested.
7. Overall Summary – This section is mainly for us to provide our feedback
on the overall status of the application under test. It should inform the client about
the critical issues that were discovered and how many are still open so that they
can estimate how close they are to shipping the product to the customer.

YASHVANT MANE 19