PRAGATI ENGINEERING COLLEGE

(AUTONOMOUS)
ADB Road, Surampalem, E.G. District, A.P.-533 437

DEPARTMENT OF CSE(DS)

Unit Pages numbers

Unit -3b Pages 3 to 9

Unit-4 Pages 11 to 31

Unit-5 Pages 33 to 49

STUDY MATERIAL :: R20 SOFTWARE ENGINEERING :: 2024-2025 AY

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

Syllabus: Unit-3(2)
Class-Based Modeling, Requirements Modeling Strategies, Flow-Oriented Modeling,
Creating a Behavioral Model, Patterns for Requirements Modelling, Requirements Modeling
for WebApps.
TEXTBOOK- I: Chapters 6, 7.

3.2.1 Class based modeling:

* CRC = Class-Responsibility-Collaborator is a part of Class based modeling.
* Class-based modeling represents the objects that the system will manipulate, the operations (also
called methods or services) that will be applied to the objects to effect the manipulation
* Identifying Analysis Classes: External entities (e.g., other systems, devices, people), Things (e.g.,
reports, displays, letters, signals), Occurrences or events, Roles (e.g., manager, engineer, salesperson),
Organizational units (e.g., division, group, team), Places(e.g., manufacturing floor or loading dock),
Structures (e.g., sensors, four-wheeled vehicles, or computers).
* Specifying Attributes: Attributes = define a class = clarify what is meant by the class in the
context of the problem space.

Fig1: CRC Index Card

* Defining Operations: Manipulate data, perform a computation, inquire about the state of an object,
monitor an object for the occurrence of a controlling event.
* Class-Responsibility-Collaborator (CRC) Modeling:
Classes: The taxonomy of class types can be extended by considering the following
categories:
1. Entity classes, also called model or business classes, are extracted directly from the
statement of the problem. These classes typically represent things that are to be stored
in a database and persist throughout the duration of the application (unless they are
specifically deleted).
2. Boundary classes are used to create the interface (e.g., interactive screen orprinted
reports) that the user sees and interacts with as the software is used. Boundary classes
are designed with the responsibility of managing the way entity objects are
represented to users.
3 .Controller classes manage a “unit of work” from start to finish. That is, controller
classes can be designed to manage
(i) the creation or update of entity objects,

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 3|Page

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

(ii) the instantiation of boundary objects as they obtain information from

entity objects,
(iii) complex communication between sets of objects,
(iv) validation of data communicated between objects or between the user
and the application. In general, controller classes are not considered until the
design activity has begun.

Responsibilities: Five guidelines for allocating responsibilities to classes:

 System intelligence should be distributed across classes
 Each responsibility should be stated as generally as possible.
 Information and the behavior related to it should reside within the same
class.
 Information about one thing should be localized with a single class, not
distributed across multiple classes.
 Responsibilities should be shared among related classes, when appropriate.

Collaborations:
 Collaborations represent requests from a client to a server in fulfillment of a
client responsibility. Collaboration is the embodiment of the contract between
the client and the server.
 An object collaborates with another object if, to fulfill a responsibility, it
needs to send the other object any messages. A single collaboration flows in
one direction—representing a request from the client to the server. From the
client’s point of view, each of its collaborations is associated with a particular
responsibility implemented by the server.
 In all cases, the collaborator class name is recorded on the CRC model index
card next to the responsibility that has spawned the collaboration.
 Therefore, the index card contains a list of responsibilities and the
corresponding collaborations that enable the responsibilities to be fulfilled.
 To help in the identification of collaborators, you can examine three different
generic relationships between classes:
o the is-part-of relationship
o the has-knowledge-of relationship
o the depends-upon relationship.
All classes that are part of an aggregate class are connected to the aggregate class via an is-
part-of relationship.

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 4|Page

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

(3.2.2) Requirements Modeling Strategies:

Structured Analysis: focuses on data objects, transformation as they flow through the
system.
Object-oriented analysis: focuses on definition of classes and their collaboration.

(3.2.3)Flow-oriented Modeling:
DFD = Data Flow Diagram --> Level 0, Level 1, Level 2
Terminology of DFD: bubble, primary input and primary output, label arrows and bubbles,
refine one bubble at a time.

Fig: Level_0 = single bubble and relations

Fig: Level_1 = basic bubble split into two or more detailed blocks

Fig: Level_2 = each bubble must be the simplest function

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 5|Page

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

(3.2.4) Creating a behavioral model:

1. identify events
2. state representations
3. sequence diagrams
4. build a state diagram for the system
5. review the model to verify accuracy and consistency.

Behv Model1: State diagram

Fig: State diagram

Behv Model2: Sequence diagram

Fig: Sequence diagram

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 6|Page

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

(3.2.5) Patterns for Requirements Modeling:

* Software pattern = mech(cap domain knowledge); This can be reapplied to a new problem.
* domain knowledge applied to a problem in same domain
* domain knowledge captured by a pattern, applied to a completely different application
domain.
So, Behavioral models = (i) State Diagram (ii) Sequence diagram in UML

(a) Discovering Analysis Patterns=> The requirements model is comprised of a wide variety
of elements: scenario-based (use cases), data-oriented (the data model), class-based, flow-
oriented, and behavioral.

(b) Requirements Pattern Example: Actuator-Sensor

Pattern Name: Actuator-Sensor
Intent: Specify various kinds of sensors and actuators in an embedded system.
Motivation: Embedded systems usually have various kinds of sensors and actuators.
Constraints: Each passive sensor, each active sensor, each actuator duty/ duties are to be
mentioned. duty = function/ task
Applicability: Useful in any system in which multiple sensors and actuators are present.

Structure:

Behavior:

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 7|Page

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

Participants:
• PassiveSensor abstract: Defines an interface for passive sensors.
• PassiveBooleanSensor: Defines passive Boolean sensors.
• PassiveIntegerSensor: Defines passive integer sensors.
• PassiveRealSensor: Defines passive real sensors.
• ActiveSensor abstract: Defines an interface for active sensors.
• ActiveBooleanSensor: Defines active Boolean sensors.
• ActiveIntegerSensor: Defines active integer sensors.
• ActiveRealSensor: Defines active real sensors.
• Actuator abstract: Defines an interface for actuators.
• BooleanActuator: Defines Boolean actuators.
• IntegerActuator: Defines integer actuators.
• RealActuator: Defines real actuators.
• ComputingComponent: The central part of the controller; it gets the data from the sensors
and computes the required response for the actuators.
• ActiveComplexSensor: Complex active sensors have the basic functionality of the abstract
ActiveSensor class, but additional, more elaborate, methods and attributes need to be
specified.
• PassiveComplexSensor: Complex passive sensors have the basic functionality of the
abstract PassiveSensor class, but additional, more elaborate, methods and attributes need to
be specified.
• ComplexActuator: Complex actuators also have the base functionality of the abstract
Actuator class, but additional, more elaborate methods and attributes need to be specified.

Collaborations: objects and classes interact with one another and how each carries out its
responsibilities.
ComputingComponent <----->---> PassiveSensor
ComputingComponent <---<-----> ActiveSensor (They send a life tick at least once during a
specified time frame)
ComputingComponent <-------->-----> actuator
ComputingComponent <-----query, set the operation state of the sensors and actuators
Ex: operation state =zero, then the error is sent to the FaultHandler (a class that contains
methods for handling error messages) like recovery mechanism or a backup device. If
recovery fails then last known value for the sensor or the default value used.
• The ActiveSensors offer methods to add or remove the addresses or address ranges of the
components that want to receive the messages in case of a value change.

Consequences:
* Sensor and actuator classes have a common interface.
* Class decides whether or not to accept the message.
Ex: if a value of an actuator is set above a maximum value, then the actuator class may not
accept the message, or it might use a default maximum value.
* The complexity of the system is potentially reduced because of the uniformity of interfaces
for actuators and sensors.

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 8|Page

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

(3.2.6) Requirements Modeling for WebApps:

1. How much analysis enough? i.e., number of stake-holders, degree to which stakeholders
worked, WebApp (size, its success effecting Org). '
2. Requirements modeling input: PASSWORD=maximum and minimum length, VIDEO=
Resolution, Alarm, Pan and Zoom, GEO-Tag,
Natural language description, rough outlines, sketches, and other formal representations.
3. Requirements modeling output:
Content model: (text, graphics (image, video, audio....))
Interaction model: manner in which users can interact with the WebApp
Functional model: operations that wll be applied to WebApp
Navigation model: navigation strategy of WebApp
Configuration model: environment in which WebApp resides

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 9|Page

UNIT -4
 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

Syllabus: Unit-4
Design within the Context of Software Engineering, The Design Process, Design Concepts,
The Design Model, Software Architecture, Architectural Genres, Architectural Styles,
Assessing Alternative Architectural Designs, Architectural Mapping Using Data Flow,
Components, Designing Class-Based Components, Conducting Component-Level Design,
Component-Level Design for WebApps, Designing Traditional Components, Component-
Based Development.
Text Book-I: Chapters 8, 9, 10.

TOPICS:
Design Concepts
4.1 Design within the Context of Software Engineering
4.2 The Design Process
4.3 Design Concepts
4.4 The Design Model

Architectural Design
4.5 Software Architecture
4.6 Architectural Genres
4.7 Architectural Styles
4.8 Assessing Alternative Architectural Designs
4.9 Architectural Mapping Using Data Flow

Component-level Design
4.10 Components
4.11 Designing Class-Based Components
4.12 Conducting Component-Level Design
4.13 Component-Level Design for Web Apps
4.14 Designing Traditional Components
4.15 Component-Based Development.

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 11 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

4.1 Design within the Context of Software Engineering

• why is design so important? => Answer is a single word—quality.
• interface design => software communicates with systems(interoperation) and humans
(who use it).
• The architectural design => major structural elements of s/w, the architectural styles,
design patterns, constraints
• The data/class => transforms class models to design class realizations (the imp data
structures to implement the s/w)
• The component-level design = structural elements of the software architecture
procedural description of software components.

4.2 The Design Process

Quality Guidelines
1. A design should exhibit an architecture that:
(a) recognizable architectural styles or patterns
(b) is composed of components that exhibit good design characteristics
(c) thereby facilitating implementation and testing.
2. A design = modular (logically partitioned into elements or subsystems)
3. A design = contain distinct representations of data, architecture, interfaces, and components
4. design = data structures appropriate for the classes to be implemented
5. A design should lead to components that have independent functional characteristics.
6. A design should lead to interfaces that reduce the complexity of connections and with the
external environment.
7. A design = derived using a repeatable method that is driven by information obtained during
software requirements analysis.
8. A design = notation that effectively communicates its meaning.

Quality Attributes
• Functionality is assessed by evaluating the feature set, capabilities, generality and
security of the overall system.

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 12 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

• Usability is assessed by considering human factors, overall aesthetics, consistency,

and documentation.
• Reliability is evaluated by measuring the frequency and severity of failure, the
accuracy of output results, the mean-time-to-failure (MTTF), the ability to recover
from failure, and the predictability of the program.
• Performance is measured by considering processing speed, response time, resource
consumption, throughput, and efficiency.
• Supportability combines the ability to extend the program (extensibility), adaptability,
serviceability—these three attributes represent a more common term,
maintainability—and in addition, testability, compatibility, configurability, the ease
with which a system can be installed, and the ease with which problems can be
localized.

The Evolution of Software Design

Refining software structures in a topdown manner
software design =emphasis on software architecture + the design patterns
Number of design methods, growing out of the work just noted, are being applied throughout
the industry
Common characteristics:
(a) requirements model design representation
(b) notation = represent functional components and their interfaces
(c) shortcuts for refinement and partitioning
(d) guidelines for quality assessment

4.3 Design Concepts (AAPS MIFR AROD)

Abstraction: * A procedural abstraction refers to a sequence of instructions that have a
specific and limited function
* A data abstraction is a named collection of data that describes a data object
* Data Abstraction = Door; then procedural abstraction= open
Architecture:
* architecture is the structure or organization of program components (modules)
* Components = major system elements set of architectural patterns enables a software
engineer to solve common design problems
* Structural models = architecture as an organized collection of program components
* Dynamic models = behavioral aspects of system config change due to external events.
* Process models= focus on the design of the business or technical process of the system
* Functional models = represent the functional hierarchy of a system
* Architectural Description Languages (ADLs) = developed to represent these models
Patterns:
* A pattern is a named nugget of insight which conveys the essence of a proven solution to a
recurring problem within a certain context amidst competing concerns
* The intent of each design pattern is to provide a description that enables a designer to
determine:
(1) whether the pattern is applicable to the current work,
(2) whether the pattern can be reused (hence, saving design time), and

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 13 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

(3) whether the pattern can serve as a guide for developing a similar, but functionally or
structurally different pattern
Separation of Concerns:
* A concern is a feature or behavior that is specified as part of the requirements model for the
software
* Separation of concerns is a design concept that suggests that any complex problem can be
more easily handled if it is subdivided into pieces that can each be solved and/or optimized
independently
Modularity:
* Software is divided into separately named and addressable components, sometimes
called modules, that are integrated to satisfy problem requirements.

Information Hiding:
* modules should be specified and designed so that information (algorithms and data)
contained within a module is inaccessible to other modules that have no need for such
information
Functional Independence:
* Independent modules are easier to maintain (and test) because secondary effects
caused by design or code modification are limited, error propagation is reduced
* Cohesion is an indication of the relative functional strength of a module.
* Coupling is an indication of the relative interdependence among modules
Refinement:
* Refinement helps to reveal low-level details as design progresses. It is actually a
process of elaboration
* Abstraction enables to specify procedure and data internally but suppress the need
for “outsiders” to have knowledge of low-level details
Aspects:
* If requirements analysis is done, then a set of “concerns” is uncovered.
* An aspect is a representation of a crosscutting concern.
* Req-A, Req-B: B can not be satisfied w/o taking A into consideration; => A
crosscuts B.
Refactoring:
* Refactoring is a reorganization technique that simplifies the design (or code) of a
component without changing its function or behavior
OOD Concepts:

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 14 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

* OO design concepts such as classes and objects, inheritance, messages, and

polymorphism
Design Classes:
* design classes that refine the analysis classes by providing design detail that will
enable the classes to be implemented and implement a software infrastructure that supports
the business solution.
User interface classes define all abstractions that are necessary for human computer
interaction (HCI). In many cases, HCI occurs within the context of a metaphor (e.g., a
checkbook, an order form, a fax machine), and the design classes for the interface may be
visual representations of the elements of the metaphor.
Business domain classes are often refinements of the analysis classes defined earlier. The
classes identify the attributes and services (methods) that are required to implement some
element of the business domain.
Process classes implement lower-level business abstractions required to fully manage the
business domain classes.
Persistent classes represent data stores (e.g., a database) that will persist beyond the
execution of the software.
System classes implement software management and control functions that enable the system
to operate and communicate within its computing environment and with the outside world.

Complete and sufficient: A design class should be the complete encapsulation of all attributes
and methods that can reasonably be expected (based on a knowledgeable interpretation of the
class name) to exist for the class
Primitiveness: Methods associated with a design class should be focused on accomplishing
one service for the class. Once the service has been implemented with a method, the class
should not provide another way to accomplish the same thing.
High cohesion: A cohesive design class has a small, focused set of responsibilities and single-
mindedly applies attributes and methods to implement those responsibilities.
Low coupling: Within the design model, it is necessary for design classes to collaborate with
one another. However collaboration should be kept to an acceptable minimum

Design class for FloorPlan and composite aggregation for the class:

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 15 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

4.4 The Design Model

The design model can be viewed in two different dimensions:

process dimension indicates the evolution of the design model

abstraction dimension represents the level of detail as each element

Data Design Elements

a.Like other software engineering activities, data design (sometimes referred to as data
architecting) creates a model of data and/or information that is represented at a high level of
abstraction (the customer/user’s view of data).
b.This data model is then refined into progressively more implementation-specific
representations that can be processed by the computer-based system.
c.At the program component level, the design of data structures and the associated algorithms
required to manipulate them is essential to the creation of high-quality applications
d.At the application level, the translation of a data model (derived as part of requirements
engineering) into a database is pivotal to achieving the business objectives of a system.
e.At the business level, the collection of information stored in disparate databases and
reorganized into a “data warehouse” enables data mining or knowledge discovery that can
have an impact on the success of the business itself.

Architectural Design Elements

a. Architectural design elements give us an overall view of the software.
b. The architectural model is derived from three sources:
(1) information about the application domain for the software to be built;
(2) specific requirements model elements such as data flow diagrams or analysis classes, their
relationships and collaborations for the problem at hand; and
(3)the availability of architectural styles and patterns.

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 16 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

c. The architectural design element is usually depicted as a set of interconnected subsystems,

often derived from analysis packages within the requirements model.
d. Each subsystem may have it’s own architecture.
Interface Design Elements
a. The interface design elements for software depict information flows into and out of the
system and how it is communicated among the components defined as part of the
architecture.
b.There are three important elements of interface design:
(1) the user interface (UI);
(2) external interfaces to other systems, devices, networks, or other producers or consumers
of information; and
(3) internal interfaces between various design components.
c. These interface design elements allow the software to communicate externally and enable
internal communication and collaboration among the components that populate the software
architecture.
d. UI design (increasingly called usability design) is a major software engineering action.
Usability design incorporates aesthetic elements (e.g., layout, color, graphics, interaction
mechanisms), ergonomic elements.(e.g., information layout and placement, metaphors, UI
navigation), and technical elements (e.g., UI patterns, reusable components).

Component-Level Design Elements

a.The component-level design for software fully describes the internal detail of each software
component. To accomplish this, the component-level design defines data structures for all
local data objects and algorithmic detail for all processing that occurs within a component
and an interface that allows access to all
component operations (behaviors).
b.The design details of a component can be modeled at many different levels of abstraction. A
UML activity diagram can be used to represent processing logic. Detailed procedural flow for
a component can be represented using either pseudocode or some other diagrammatic form
(e.g., flowchart or box diagram). Algorithmic structure follows the rules established for
structured programming (i.e., a set of constrained procedural constructs).
Deployment-Level Design Elements
Deployment-level design elements indicate how software functionality and subsystems will
be allocated within the physical computing environment that will support the software.

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 17 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

For example, the elements of the SafeHome product are configured to operate within three
primary computing environments—a home-based PC, the SafeHome control panel, and a
server housed at CPI Corp. (providing Internet-based access to the system).

4.5 Software Architecture:

* What is Software Architecture? The software architecture of a program comprise software
components
*Why Architecture is important?
The architecture=representation (only, but not program) enabling:
#enabler for communication between all parties (stakeholders)
# early design decisions that will have a profound impact on all software engineering
work
# define model that details how its components work together
• Architectural Descriptions:
#Representations of software architecture are an enabler for communication between all
#architectural description is actually a set of work products that reflect different views of
the system parties (stakeholders) interested in the development of a computer-based system.
• Architectural Decisions: architectural decisions themselves can be considered to be one
view of the architecture.

4.6 Architectural Genres:

=> specific architectural approach to the structure that must be built ==> each genre
represents a unique challenge
Following are architectural genres for software-based systems:
• Artificial intelligence—Systems that simulate or augment human cognition, locomotion, or
other organic processes.

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 18 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

• Commercial and nonprofit—Systems that are fundamental to the operation of a business

enterprise.
• Communications—Systems that provide the infrastructure for transferring and managing
data, for connecting users of that data, or for presenting data at the edge of an infrastructure.
• Content authoring—Systems that are used to create or manipulate textual or multimedia
artifacts.
• Devices—Systems that interact with the physical world to provide some point service for an
individual.
• Entertainment and sports—Systems that manage public events or that provide a large
group entertainment experience.
• Financial—Systems that provide the infrastructure for transferring and managing money
and other securities.
• Games—Systems that provide an entertainment experience for individuals or groups.
• Government—Systems that support the conduct and operations of a local, state, federal,
global, or other political entity.
• Industrial—Systems that simulate or control physical processes.
• Legal—Systems that support the legal industry.
• Medical—Systems that diagnose or heal or that contribute to medical research.
• Military—Systems for consultation, communications, command, control, and intelligence
(C4I) as well as offensive and defensive weapons.
• Operating systems—Systems that sit just above hardware to provide basic software
services.
• Platforms—Systems that sit just above operating systems to provide advanced services.
• Scientific—Systems that are used for scientific research and applications.
• Tools—Systems that are used to develop other systems.
• Transportation—Systems that control water, ground, air, or space vehicles.
• Utilities—Systems that interact with other software to provide some point service

4.7 Architectural Styles:

* An architectural style is a transformation that is imposed on the design of an entire system.
* The software that is built for computer-based systems also exhibits one of many
architectural styles. Each style describes a system category that encompasses
# a set of components (e.g., a database, computational modules) that perform a
function required by a system;
# a set of connectors that enable “communication, coordination and cooperation” among
components;
# constraints that define how components can be integrated to form the system
# semantic models that enable a designer to understand the overall properties of a system by
analyzing the known properties of its constituent parts

A Brief Taxonomy of Architectural Styles

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 19 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

Fig: Data Centric Architecture

Fig: Data-Flow Architecture

Fig: Main Program/ Syb-Program Architecture

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 20 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

Fig: Layered Architecture

Architectural Patterns
Architectural patterns address an application-specific problem within a specific context and
under a set of limitations and constraints
Organization and Refinement
* Control: How is control managed within the architecture? hierarchy ? topology
? synchronized ?
* Data: How are data communicated between components?

4.8 Architectural Design:

Representing the System in Context

The generic structure of the architectural context diagram is illustrated in Figure below:

Fig: Architectural Context Diagram

• Superordinate systems—those systems that use the target system as part of some higher-
level processing scheme.

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 21 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

• Subordinate systems—those systems that are used by the target system and provide data or
processing that are necessary to complete target system functionality.
• Peer-level systems—those systems that interact on a peer-to-peer basis (i.e., information is
either produced or consumed by the peers and the target system.
• Actors—entities (people, devices) that interact with the target system by producing or
consuming information that is necessary for requisite processing

The overall SafeHome product controller and the Internet-based system are both
superordinate to the security function is shown below:

Fig: Architectural Context diagram of SafeHome security function

Defining Archetypes
* An archetype is a class or pattern that represents a core abstraction that is critical to the
design of an architecture for the target system
* SafeHome security function has the following archetypes:

• Node: Represents a cohesive collection of input and output elements of the home security
function. For example a node might be comprised of (1) various sensors and (2) a variety of
alarm (output) indicators.
• Detector: An abstraction that encompasses all sensing equipment that feeds information into
the target system.

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 22 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

• Indicator: An abstraction that represents all mechanisms (e.g., alarm siren, flashing lights,
bell) for indicating that an alarm condition is occurring.
• Controller: An abstraction that depicts the mechanism that allows the arming or disarming
of a node. If controllers reside on a network, they have the ability to communicate with one
another
Refining the Architecture into Components
The overall architectural structure (represented as a UML component diagram) is illustrated
in Figure below:

• External communication management—coordinates communication of the security function

with external entities such as other Internet-based systems and external alarm notification.
• Control panel processing—manages all control panel functionality.
• Detector management—coordinates access to all detectors attached to the system.
• Alarm processing—verifies and acts on all alarm conditions.

Describing Instantiations of the System

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 23 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

4.9 Assessing Alternative Architectural Designs

An Architecture Trade-Off Analysis Method (ATAM)

The design analysis activities that follow are performed iteratively:
1. Collect scenarios: A set of use cases is developed to represent the system from the user’s
point of view.
2. Elicit requirements, constraints, and environment description: This information is
determined as part of requirements engineering and is used to be certain that all stakeholder
concerns have been addressed.
3. Describe the architectural styles/patterns that have been chosen to address the scenarios
and requirements. The architectural style(s) should be described using one of the following
architectural views:
• Module view for analysis of work assignments with components and the degree to which
information hiding has been achieved.
• Process view for analysis of system performance.
• Data flow view for analysis of the degree to which the architecture meets functional
requirements.
4. Evaluate quality attributes by considering each attribute in isolation The number of
quality attributes chosen for analysis is a function of the time available for review and the
degree to which quality attributes are relevant to the system at hand. Quality attributes for
architectural design assessment include reliability, performance, security, maintainability,
flexibility, testability, portability, reusability, and interoperability.
5. Identify the sensitivity of quality attributes to various architectural attributes for a
specific architectural style: This can be accomplished by making small changes in the
architecture and determining how sensitive a quality attribute, say performance, is to the
change. Any attributes that are significantly affected by variation in the architecture are
termed sensitivity points.
6. Critique candidate architectures (developed in step 3) using the sensitivity analysis
conducted in step 5: The SEI describes this approach in the following manner:
For example, the performance of a client-server architecture might be highly sensitive to the
number of servers (performance increases, within some range, by increasing the number of
servers). . . . The number of servers, then, is a trade-off point with respect to this architecture.

Architectural Complexity
Sharing dependencies represent dependence relationships among consumers who use the
same resource or producers who produce for the same consumers. For example, for two
components u and v, if u and v refer to the same global data, then there exists a shared
dependence relationship between u and v
Flow dependencies represent dependence relationships between producers and consumers of
resources. For example, for two components u and v, if u must complete before control flows
into v (prerequisite), or if u communicates with v by parameters, then there
exists a flow dependence relationship between u and v.
Constrained dependencies represent constraints on the relative flow of control among a set
of activities. For example, for two components u and v, u and v cannot execute at the same
time (mutual exclusion), then there exists a constrained dependence relationship between u
and v.

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 24 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

Architectural Description Languages

Architectural description language (ADL) provides a semantics and syntax for describing a
software architecture.
4.10 Architectural Mapping using Data Flow:

* Transform Mapping
Step 1. Review the fundamental system model
Step 2. Review and refine data flow diagrams for the software
Step 3. Determine whether the DFD has transform or transaction flow11 characteristics
Step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries
Step 5. Perform “first-level factoring"
Step 6. Perform “second-level factoring"
Step 7. Refine the first-iteration architecture using design heuristics for improved software
quality
The objective of the preceding seven steps is to develop an architectural representation of
software

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 25 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

See this figure in detail in next page

* Refining the Architectural Design

Develop a representation of software that will meet all functional and performance
requirements and merit acceptance based on design measures and heuristics

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 26 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

4.10 Components, 4.11 Designing Class-Based Components

* Large blocks of architecture are usually called Components.
* Component= a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.
* three views of a component
OO View Traditional View / Structured View Process- related View
Choose components
or design patterns
from the catalog and
use them to populate
the architecture i.e.,
created with
reusability

* Basic Design Principles: * Component-Level Design * Cohesion * Coupling

The Open-Closed Principle (OCP): A Guidelines
module [component] should be open Cohesion = single-mindedness Coupling = qualitative measure of
for extension but closed for Components: Naming of a component. the degree to which classes are
modification. conventions should be established connected to
The Liskov Substitution Principle for components OR one another.
(LSP): Subclasses should be
substitutable for their base classes” Interfaces: Interfaces provide a component or class Content Coupling:
Dependency Inversion Principle important information about encapsulates only attributes Component modifies data in another
(DIP): Depend on abstractions. Do communication and and operations that component (violates inf hiding)
not depend on concretions Collaboration are closely related to one
The Interface Segregation Principle another and to the class or Common Coupling:
Dependencies and Inheritance.

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 27 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

(ISP): Many client-specific interfaces For improved readability, it is a component itself. Global variable used by multiple
are better than one general purpose good idea to model dependencies components
interface from left to right and inheritance #Functional. Exhibited
The Release Reuse Equivalency from bottom (derived classes) to primarily by operations Control coupling. Occurs when
Principle (REP): The granule of reuse top (base classes) #Layer. Exhibited by packages, operation A() invokes operation B()
is the granule of release components, and classes and passes a control flag to B.
The Common Closure Principle #Communicational All
(CCP): Classes that change together operations that access the same Stamp coupling: Occurs when
belong together. data are defined ClassB is declared as a type for an
The Common Reuse Principle within one class. argument of an operation of ClassA.
(CRP): Classes that aren’t reused
together should not be grouped Data coupling: Occurs when
together operations pass long strings of data
arguments.

Routine call coupling: Occurs when

one operation invokes another

Type use coupling: Occurs when

component A uses a data type
defined in component B .i.e.,
changes definition type

Inclusion or import coupling:

Occurs when component A imports
or includes a package or the content
of component B.

External coupling: Occurs when a

component communicates or
collaborates with infrastructure
components.

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 28 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

4.12 Conducting Component-Level Design

Step 1. Identify all design classes that correspond to the problem domain
Step 2. Identify all design classes that correspond to the infrastructure domain.
Step 3. Elaborate all design classes that are not acquired as reusable Components

Step 3a. Specify message details when classes or components collaborate.

Step 3b. Identify appropriate interfaces for each component
Step 3c. Elaborate attributes and define data types and data structures required to implement
them.

Step 3d. Describe processing flow within each operation in detail

Step 4. Describe persistent data sources (databases and files) and identify the classes required
to manage them.
Step 5. Develop and elaborate behavioral representations for a class or component.
Step 6. Elaborate deployment diagrams to provide additional implementation detail.
Step 7. Refactor every component-level design representation and always consider
alternatives.

4.13 Component-Level Design for Web Apps

Content Design at the Component Level Functional Design at the Component Level
A number of potential content components Modern Web applications deliver
can be defined for the video surveillance increasingly sophisticated processing
capability: functions that:
(1) the content objects that represent the (1) perform localized processing to generate
space layout (the floor plan) with additional content and navigation capability in a
icons representing the location of sensors and dynamic fashion
video cameras, (2) provide computation or data processing
(2) the collection of thumbnail video captures capability that is appropriate for the
(each a separate data object), and WebApp’s business domain
(3) the streaming video window for a specific (3) provide sophisticated database query and
camera. Each of these components can be access, or
separately named and manipulated as a (4) establish data interfaces with external
package. corporate systems

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 29 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

4.14 Designing Traditional Components

Graphical Design Notation Tabular Design Notation Program Design
Language
A flowchart, like an activity diagram, is quite simple pictorially. Decision Tables = contain Conditions followed by Program design
actions. language (PDL), also
called structured
1. List all actions that can be associated with a specific English or pseudo code,
procedure (or component).
2. List all conditions (or decisions made) during execution of incorporates the logical
the procedure. structure of a
3. Associate specific sets of conditions with specific actions, programming language
eliminating impossible combinations of conditions; with the free-form
alternatively, develop every possible permutation of conditions. expressive ability of a
4. Define rules by indicating what actions occur for a set of natural language (e.g.,
conditions. English).

PDL provides an
elaboration of the
procedural design for an
early version of an
alarm management
component i.e.,
Algorithm like.

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 30 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

4.15 Component-Based Development.

Component-based software engineering (CBSE) is a process that emphasizes the design and construction of computer-based systems using
reusable software components.
Component Qualification, Classifying and Retrieving
Domain Engineering Analysis and Design for Reuse
Adaptation, and Composition Components
The steps in the process are Component Qualification key issues that form a basis for * Classification enables you to
defined as: Component qualification ensures design for reuse: find and retrieve candidate
1. Define the domain to be that a candidate component will reusable components, but a reuse
investigated. perform the function required, Standard data The application environment must exist to
2. Categorize the items extracted will properly “fit” into the domain should be investigated integrate these components
from the domain. architectural and standard global data effectively
3. Collect a representative sample style structures (e.g., file structures or a
of applications in the domain. complete database) should be * The reuse library is one element
4. Analyze each application in the Component Adaptation identified. All design components of a larger software repository
sample and define analysis In an ideal setting, domain can then be characterized to make
classes. engineering creates a library use of these standard data
5. Develop a requirements model of components that can be easily structures.
for the classes. integrated into an application
architecture. The implication of Standard interface protocols
“easy integration” Three levels of interface protocol
should be established: the nature
of intramodular interfaces, the
Component Composition design of external technical
The component composition task (nonhuman) interfaces, and the
assembles qualified, adapted, and human-computer interface.
engineered components to
populate the architecture Program templates An
established for an application. architectural style is chosen and
can serve as a template for the
architectural design of a new
software.

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 31 | P a g e

UNIT -5
 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

Syllabus: Unit-5
The Golden Rules, User Interface Analysis and Design, Interface Analysis, Interface Design Steps, Web App Interface Design, Design
Evaluation, Elements of Software Quality Assurance, SQA Tasks, Goals & Metrics, Statistical SQA, Software Reliability, A Strategic Approach
to Software Testing, Strategic Issues, Test Strategies for Conventional Software, Test Strategies for Object-Oriented Software, Test Strategies for
Web Apps, Validation Testing, System Testing, The Art of Debugging, Software Testing Fundamentals, Internal and External Views of Testing,
White-Box Testing ,Basis Path Testing
Topics:
Text Book-I: Chapters 11, 16, 17, 18. 5.1 The Golden Rules
5.2 User Interface Analysis and Design
5.3 Interface Analysis
5.4 Interface Design Steps
5.5 Web App Interface Design
5.6 Design Evaluation

5.7 Elements of Software Quality Assurance

5.8 SQA Tasks, Goals & Metrics
5.9 Statistical SQA,
5.10 Software Reliability
5.11 A Strategic Approach to Software Testing

5.12 Strategic Issues

5.13 Test Strategies for Conventional Software
5.14 Test Strategies for Object-Oriented Software
5.15 Test Strategies for Web Apps
5.16 Validation Testing
5.17 System Testing

5.18 The Art of Debugging

5.19 Software Testing Fundamentals
5.20 Internal and External Views of Testing
5.21 White-Box Testing
5.22 Basis Path Testing

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 33 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

5.1 The Golden Rules

1. Place the user in control.
2. Reduce the user’s memory load.
3. Make the interface consistent.

Place the user in control Reduce the user’s memory load Make the interface consistent
• Do not force unnecessary actions • Reduce demand on short-term memory • Current task into a meaningful context
• Flexible interaction • meaningful defaults • Maintain consistency across a family
• Interaction must be interruptible • Define shortcuts for intuitive of applications.
• Customization • Visual interface to be on a real-world • Past interactive model met user
• Skill levels from basic to advance effect expectations? If yes, then do not
• Hide technical internals from casual • Disclose information in a progressive modify unless compiled.
user fashion.
• Direct interaction of objects that
appear on screen

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 34 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

5.2 User Interface Analysis and Design

Models Types of users Process
• Human engineer creates user model • Novice: No idea/ No knowledge of the Spiral model:
• s/w engineer creates Design model system
• End user develops mental image model • Intermittent users: reasonable syntactic
• Implementers of the system create the knowledge, but low recall
Implementation model. • Good syntactic knowledge , shortcuts.

• Focus on profile of users

• Define set of interface objects and
actions
• Prototype creating usage scenarios
• Interface Validation:
o User task implementation
correctly
o Degree to which interface is
easy to use
o User’s acceptance level

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 35 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

5.3 Interface Analysis

It consists of following FOUR activities:
1.User Analysis
2.Task Analysis and Modeling
3.Analysis of Display Content
4.Analysis of the Work Environment.
User Analysis Task Analysis and Modeling Analysis of Display Content Analysis of the Work
Environment
* User Interviews: one-to-one • User tasks? • Type of content like • Work environment ?
meeting, GDs, etc., • Tasks and Sub-Tasks? photos, videos, graphics, o well lit?
• Sequence of tasks? text, …. o display placement?
* Sales input: Sales people meet • Hierarchy of tasks? • User customization Cockpit reachable?
with users on a regular basis and • Problem Domain? • Partitioning of large report o Keyboard available?
can gather information that will like content o Mouse available?
help the software team to • Error and Warning • Work culture
categorize users and better messages o Time per transaction
understand their requirements. • Scaling of graphical data o Accuracy
• Information sharing
* Marketing input: Market o Two or more people
analysis can be invaluable in the accessing same file
definition of market segments
and an understanding of how
each segment might use the
software in subtly different ways.
Ex: MS Office in School, College
and DTP-Centre have different
complexities in usage.

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 36 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

5.4 Interface Design Steps

1. Applying Interface Design Steps: Target, Source and Application objects are identified.
2. User Interface Design Patterns: design problem solution to be specific & well bounded
3. Design Issues = Response time, Help Facilities, Error handling, Command labeling
4. Response time: response time too long = increase stress level of user => Frustration
5. Help facilities: Help Command with one/two line suggestions
6. Error handling: Error messages, warning messages, misleading with more severity
increase user frustration
7. Menu and command labelling: proper menu and submenu generation
8. Application accessibility: visual, hearing, mobility, speech, and learning impairments
9. Internationalization: Guidelines provided for representing symbols by using Unicode
standard

5.5 Web App Interface Design

Provide user:
* Where am I? The interface should provide the indication of the “content in the hierarchy”.
* What can I do now? Functions available
* Where have I been, where am I going? in map like guidance for easy understanding of
WebApp content organization.
Principles and Guidelines:
1.Anticipation: anticipates the user’s next move.
2. Communication: interface should communicate status of any activity initiated by the user.
3. Consistency: The use of navigation controls, menus, icons, and aesthetics consistent
4. Controlled autonomy: facilitate user movement throughout the WebApp, but not force
5. Efficiency: interface should optimize user’s work efficiency, not the developers view
6. Flexibility: flexible to enable users to accomplish tasks directly / explore WebApp.
7. Focus: focused on the user task(s) at hand.
8. Fitt’s law: The time to acquire a target is a function of the distance to and size of the target
9. Human interface objects: vast library of reusable human interface objects were developed
10. Latency reduction: multitasking in a way that lets the user proceed with work
11. Learnability: A WebApp interface should be designed to minimize learning time
12. Metaphors: interaction metaphor is easier to learn, appropriate for application and user.
13.Maintain work product integrity: A work product must be automatically saved
14.Readability: information presented should be readable by young and old.
15.Track state: the state of the user interaction should be tracked, stored and retrieved (like
Sleep, and Resume service in Computer)
16.Visible navigation: A well-designed WebApp interface provides “the illusion that users
are in the same place, with the work brought to them”.

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 37 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

5.6 Design Evaluation

User Interface evaluation cycle takes the form shown below:

Fig: Design Evaluation cycle

* The prototype is evaluated by the user,11 who provides you with direct comments about the
efficacy of the interface.
* Ex: if formal evaluation techniques are used (e.g., questionnaires, rating sheets), you can
extract information from these data (e.g., 80 percent of all users did not like the mechanism)

* Number of evaluation criteria can be applied during early design reviews:

# The length and complexity of the requirements model
# The number of user tasks specified and the average number of actions per task
# memory load on users of the system = number of actions, tasks, and system states
indicated by the design model
# Interface style, help facilities, and error handling protocol

* To collect qualitative data, questionnaires can be distributed to users of the prototype.

Questions can be:
(1) simple yes/no response,
(2) numeric response,
(3) scaled (subjective) response,
(4) Likert scales (e.g., strongly agree, somewhat agree),
(5) percentage (subjective) response, or
(6) open-ended.

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 38 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

5.7 Elements of Software Quality Assurance

Standards: The IEEE, ISO, and other standards organizations for S/W Engg Standards
Reviews and audits: Technical reviews are a quality control activity performed by software
engineers for software engineers
Testing: one primary goal = to find errors
Error/defect collection and analysis: SQA collects and analyzes error and defect data to
better understand how errors are introduced
Change management: If it is not properly managed, change can lead to confusion, and
confusion almost always leads to poor quality.
Education: key contributor to improvement is education of soft ware engineers, their
managers, and other stakeholders
Vendor management: Three categories of software are acquired from external software
vendors.
• shrink-wrapped packages (e.g., Microsoft Office)
• a tailored shell that provides a basic skeletal structure that is custom tailored to the
needs of a purchaser
• contracted software that is custom designed and constructed from specifications
provided by the customer organization.
Security management: new government regulations regarding privacy, every software
organization should institute policies that protect data at all levels, establish firewall
protection for WebApps, and ensure that software has not been tampered with internally
Safety: impact of hidden defects can be catastrophic
Risk management: SQA ensures that risk management activities are properly conducted and
that risk-related contingency plans have been established

5.8 SQA Tasks, Goals & Metrics

SQA Tasks Goals & Metrics
Prepares an SQA plan for a project. Requirements quality: correctness,
completeness, and consistency of the
Participates in the development of the requirements model
project’s software process description.
Design quality: Every element of the design
Reviews software engineering activities to model should be assessed by the software
verify compliance with the defined software team to ensure that it exhibits high quality
process.
Code quality: Source code and related work
Audits designated software work products to products (e.g., other descrip tive information)
verify compliance with those defined as part must conform to local coding standards and
of the software process. exhibit charac teristics that will facilitate
maintainability.
Audits designated software work products to
verify compliance with those defined as part Quality control effectiveness: apply limited
of the software process. resources in a way that has the highest
likelihood of achieving a high-quality result
Records any noncompliance and reports to
senior management.

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 39 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

5.9 Statistical SQA

* Collect and categorize the information about software errors and defects
* An attempt is made to trace each error and defect to its underlying cause
* Using the Pareto principle (80 percent of the defects can be traced to 20 per cent of all
possible causes), isolate the 20 percent
* Once the vital few causes have been identified, move to correct the problems that have
caused the errors and defects

Generic Example Six Sigma for Software Engineering

• Incomplete or erroneous specifications (IES) The Six Sigma method ology defines
• Misinterpretation of customer communication three core steps:
(MCC) • Define customer requirements and
• Intentional deviation from specifications (IDS) deliverables and project goals via well
•Violation of programming standards (VPS) defined methods of customer
•Error in data representation (EDR) communication.
• Inconsistent component interface (ICI) •Error • Measure the existing process and its
in design logic (EDL) output to determine current quality
• Incomplete or erroneous testing (IET) performance (collect defect metrics).
• Inaccurate or incomplete documentation (IID) • Analyze defect metrics and determine the
•Error in programming language translation of vital few causes.
design (PLT)
•Ambiguous or inconsistent human/computer Two additional steps also suggested:
interface (HCI) • Improve the process by eliminating the
•Miscellaneous (MIS) root causes of defects.
• Control the process to ensure that future
work does not reintroduce the causes of
defects.

5.10 Software Reliability

* Measures of Reliability and Availability:
# A simple measure of reliability is mean time-between-failure (MTBF):
MTBF= MTTF + MTTR
where the acronyms MTTF and MTTR are mean-time-to-failure and mean-time-to
repair
# Software availability is the probability that a program is operating according to
requirements at a given point in time and is defined as
𝑀𝑇𝑇𝐹
𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑖𝑙𝑖𝑡𝑦 = × 100%
𝑀𝑇𝑇𝐹 + 𝑀𝑇𝑇𝑅
* Software Safety:
# Software safety = software quality assurance activity = focuses on the identification
and assessment of potential hazards that may affect software negatively and cause an
entire system to fail
# Ex: computer-based cruise control for an automobile might be:
(1) causes uncontrolled acceleration that cannot be stopped
(2) does not respond to depression of brake pedal (by turning off)
(3) does not engage when switch is activated
(4) slowly loses or gains speed

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 40 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

5.11 A Strategic Approach to Software Testing

Verification and Validation Organizing for Software Software Testing Strategy—The Big Criteria for Completion of
Testing Picture Testing
Verification refers to the set of * The software developer is One response to the question
tasks that ensure that software always responsible for testing is: “You’re never done testing;
correctly implements a specific the individual units the burden simply shifts from
function. (components) of the program, you (the software engineer) to
ensuring that each performs the the end user.”
Validation refers to a different function or exhibits the
set of tasks that ensure that the behavior OR
software that has been built is Fig: Testing Strategy
traceable to customer *misconceptions: “You’re done testing when you
requirements. # that the developer of run out of time or you run out
software should do no testing at of money.”
all
i.e., # that the software should be
“tossed over the wall” to But,
Verification: “Are we building strangers who will test it “a series of tests derived from
the product right?” mercilessly a statistical sample of all
# that testers get involved with possible program executions
Validation: “Are we building the project only when the by all users from a targeted
the right product?” testing steps are about to begin population.”
Fig: Software Testing Steps

i.e.,
Coding→ Unit Testing → Integration
Testing → Validation Testing →System
Testing → …..

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 41 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

5.12 Strategic Issues

* Specify product requirements in a quantifiable manner long before testing commences: a
good testing strategy also assesses other quality characteristics such as portability, maintain
ability, and usability

* State testing objectives explicitly: testing should be stated in measurable terms

* Understand the users of the software and develop a profile for each user category: Use
cases can reduce overall testing effort by focusing testing on actual use of the product

* Develop a testing plan that emphasizes “rapid cycle testing”: to control quality levels and
the corresponding test strategies

* Build “robust” software that is designed to test itself: capable of diagnosing certain classes
of errors, automated testing and regression testing.

* Use effective technical reviews as a filter prior to testing: reviews can reduce the amount
of testing effort

* Conduct technical reviews to assess the test strategy and test cases themselves: Technical
reviews can uncover inconsistencies, omissions, and outright errors, saves time.

* Develop a continuous improvement approach for testing process: metrics collected during
testing should be used as part of statistical process

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 42 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

5.13 Test Strategies for Conventional Software

Unit Testing: Integration Testing Smoke testing: It is integration testing approach, when product software is
verification effort on the smallest Top-down integration: verifies major developed, frequent basis.
unit of software design control or decision points early in the Activities of Smoke Testing:
test process # Software components → translated into code integrated into a build.
Build = all data files, libraries, reusable modules, components
# A series of tests is designed to expose errors
# The build is integrated with other builds, is smoke tested daily.
{Advantages of Smoke Testing} = Integration risk is minimized. The quality
of the end product is improved, Error diagnosis and correction are simplified,
Progress is easier to assess.
Strategic options:
* Sandwich testing = top-down tests(upper levels of the program structure)+
Bottom-up integration: Low-level bottom-up tests (subordinate levels)
components are combined into * Critical module to be identified
Unit-test considerations: Data clusters (sometimes called builds) * Critical module = several s/w requirements, high level control,
flow across a component, complex/error prone, performance requirements.
Selective testing, Boundary
testing, antibugging Integration test work products
* An overall plan for integration of the software and a description of specific
Unit-test procedures tests is documented in a Test Specification.
Example: SafeHomeSecurity System will have the following Test Phases
@ User interaction = command input and output, display, error
processing
@ Sensor processing= acquisition of sensor output, resolve sensor
conditions
@ Communications functions = to communicate with central
monitoring station
Regression testing: Testing → Errors @ Alarm processing = tests of software actions when an alarm is
found → Code changes → New Paths encountered
created → new I/O occur At all phases these are applied: Interface integrity, Functional validity,
Information content, Performance

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 43 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

5.14 Test Strategies for Object-Oriented Software 5.15 Test Strategies for Web Apps
The strategy for WebApp testing adopts the basic principles for all software
* Unit Testing in the OO Context: testing and applies a strategy and tactics that are used for object-oriented
# You can no longer test a single operation in isolation systems. The following steps summarize the approach:
but rather as part of a class
# conventional software testing = focus on the
1. content model reviewed to uncover errors.
algorithmic detail of a module and the data that flow
across the module interface 2. interface model is reviewed to ensure that all use cases can be
# class testing for OO software = {operations accommodated.
encapsulated by the class} +{state behavior of the class} 3. design model is reviewed to uncover navigation errors.
4. The user interface is tested to uncover errors in presentation and/or
navigation mechanics.
* Integration Testing in the OO Context: There are two
5. Each functional component is unit tested.
different strategies for integration testing of OO systems.
6. Navigation throughout the architecture is tested.
# thread-based testing: integrates the set of classes
required to respond to one input or event for the system. 7. The WebApp is implemented in a variety of different environmental
Each thread is integrated and tested individually configurations and is tested for compatibility with each configuration.
# use-based testing: begins the construction of the 8. Security tests are conducted in an attempt to exploit vulnerabilities in the
system by testing those classes (called independent WebApp or within its environment.
classes) that use very few (if any) server classes. After 9. Performance tests are conducted.
the independent classes are tested, the next layer of 10. The WebApp is tested by a controlled and monitored population of end
classes, called dependent classes, that use the users.
independent classes are tested.
# Cluster testing is one step in the integration testing of The results of their interaction with the system are evaluated for content and
OO software. Here, a cluster of collaborating classes
navigation errors, usability concerns, compatibility concerns, and WebApp
(determined by examining the CRC and object-
reliability and performance. Because many WebApps evolve continuously,
relationship model) is exercised by designing test cases
that attempt to uncover errors in the collaborations. the testing process is an ongoing activity, conducted by support staff who
use regression tests derived from the tests developed when the WebApp was
first engineered.

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 44 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

5.16 Validation Testing

* Validation-Test Criteria: * Alpha and Beta Testing
* Configuration Review:
# Software validation is achieved through a series # The alpha test is conducted at the developer’s site by a
Ensure that all elements of
of tests that demonstrate conformity with representative group of end users.
the software configuration
requirements # The beta test is conducted at one or more end-user sites.
have been properly
# After each validation test case has been The developer generally is not present. Therefore, the beta
developed, are cataloged,
conducted, one of two possible conditions exists: test is a “live” application of the software in an
and have the necessary
(1) The function or performance characteristic environment that cannot be controlled by the developer.
detail to bolster the support
conforms to specification and is accepted or # A variation on beta testing, called customer acceptance
activities
(2) a deviation from specification is uncovered testing, is sometimes per formed when custom software is
and a deficiency list is created delivered to a customer under contract

5.17 System Testing

Stress Testing: Resources in abnormal quantity, PerformanceTesting: Performance
Recovery Testing: It is a system test that forces frequency, or volume. Test cases that tests are often coupled with stress
the software to fail in a variety of ways and (1) generate ten interrupts per second, when one or testing and usually require both
verifies that recovery is properly performed. If two is the average rate hardware and software
recovery is automatic (performed by the system (2) input data rates may be increased by an order of instrumentation
itself), reinitialization, checkpointing magnitude to determine how input functions will
mechanisms, data recovery, and restart are respond Deployment Testing: sometimes
evaluated for correctness (3) maximum memory or other resources are called configuration testing,
executed exercises the software in each
Security testing: It attempts to verify that (4) thrashing in a virtual operating system are environment in which it is to
protection mechanisms built into a system will, designed, operate
in fact, protect it from improper penetration (5) Excessive hunting for disk-resident data are
created.

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 45 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

5.18 The Art of Debugging

The Debugging Process: Debugging is not cause may actually be located at a site that is far # Backtracking is a fairly common
testing but often occurs as a consequence of removed. Highly coupled components exacerbate debugging approach that can be used
testing. The debugging process will usually this situation. success fully in small programs.
have one of two outcomes: 2. The symptom may disappear (temporarily) # Cause elimination is manifested by
(1) the cause will be found and corrected or when another error is corrected. induction or deduction and introduces the
(2) the cause will not be found. 3. The symptom may actually be caused by concept of binary partitioning
In the latter case, the per son performing nonerrors. (example: round-off inaccuracies). Automated debugging: Integrated
debugging may suspect a cause, design a test 4. The symptom may be caused by human error development environments (IDEs) provide
case to help validate that suspicion, and work that is not easily traced a way to capture some of the language
toward error correction in an iterative fashion. 5. The symptom may be a result of timing specific predetermined errors (e.g.,
problems, rather than processing problems. missing end-of-statement characters,
6. It may be difficult to accurately reproduce input undefined variables, and so on) without
conditions (e.g., a real-time application in which requiring compilation
input ordering is indeterminate). The people factor: A final maxim for
7. The symptom may be intermittent. This is debugging might be: “When all else fails,
particularly common in embedded systems that get help!”
couple hardware and software inextricably. Correcting the Error
8. The symptom may be due to causes that are “correction” that removes the cause of a
distributed across a number of tasks running on bug. After correction, questions to be
different processors. posted are:
Psychological Considerations: evidence on # Is the cause of the bug
debugging is open to many interpretations, large reproduced in another part of the
variances in debugging program?
Few characteristics of bugs provide some Debugging Strategies # What “next bug” might be
clues: Debugging tactics: introduced by the fix I’m about to
1. The symptom and the cause may be # Brute force category of debugging is probably make?
geographically remote. That is, the symptom the most common and least efficient method for
may appear in one part of a program, while the isolating the cause of a software error.
cause

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 46 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

5.19 Software Testing Fundamentals

* Testability: how a program can be tested is called Testability. # Stability: The software recovers well from failures
# Operability: quality in mind while programming => few bugs that # Understandability: dependencies between internal,
block execution of tests => testing progresses external, and shared components are well understood.
# Observability: Source code is accessible. Input/output variables Technical documentation is instantly accessible, well
observable. organized, specific and detailed, and accurate.
# Controllability: control the I/O, inputs, outputs
# Decomposability: independent modules that can be tested * Test Characteristics.
independently # A good test has a high probability of finding an error.
# Simplicity: functional simplicity (e.g., the feature set is the #A good test is not redundant
minimum necessary to meet requirements. structural simplicity (e.g., # A good test should be “best of breed”
architecture is modularized to limit the propagation of faults) and # A good test should be neither too simple nor too
code simplicity (e.g., a coding standard is adopted for ease of complex
inspection and maintenance).

5.20 Internal and External Views of Testing

* Engineered product (and most other things) can be tested in one of two ways:
# Knowing the specified function Ex: Black-box testing
# Knowing the internal working Ex: White-box testing

5.21 White-Box Testing

* White-box testing = glass-box testing
* component-level design to derive test cases
* derive test cases that
# guarantee that all independent paths within a module have been exercised at least once
# exercise all logical decisions on their true and false sides
# execute all loops at their boundaries and within their operational bounds
# exercise internal data structures to ensure their validity.

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 47 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

5.22 Basis Path Testing

* Flow Graph Notation

Fig: Flow-graph notation Fig: (a) Flowchart, (b) Flow Graph

* Independent Program Paths

Path 1: 1-11
Path 2: 1-2-3-4-5-10-1-11
Path 3: 1-2-3-6-8-9-10-1-11
Path 4: 1-2-3-6-7-9-10-1-11

# Cyclomatic complexity is a software metric that pro vides a quantitative measure of the logical complexity of a program. Complexity is
computed in one of three ways:
@ The number of regions of the flow graph corresponds to the cyclomatic complexity.
@ Cyclomatic complexity V(G) for a flow graph G is defined as V(G) =E -N +2 where E is the number of flow graph edges and
N is the number of flow graph nodes.

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 48 | P a g e

 SOFTWARE ENGINEERING NOTES :: R20 :: AY 2024-2025

@ Cyclomatic complexity V(G) for a flow graph G is also defined as V(G) =P +1 where P is the number of predicate nodes
contained in the flow graph G
* Deriving Test Cases
# Using the design or code as a foundation, draw a corresponding flow graph.
# Determine the cyclomatic complexity of the resultant flow graph
# Determine a basis set of linearly independent paths
# Prepare test cases that will force execution of each path in the basis set.

* Graph Matrices
# A data structure, called a graph matrix, can be quite useful for developing a software tool that assists in basis path testing.
# A graph matrix = square matrix whose size (i.e., number of rows =columns) is equal to the number of nodes on the flow graph. Each row and
column correspond to an identified node, and matrix entries correspond to connections (an edge) between nodes.
# Consider below example:

DEPT OF CSE (DS) :: PRAGATI ENGINEERING COLLEGE (A) 49 | P a g e