Mr.

Moses
Assistant Professor -CSE

SOFTWARE ENGINEERING

Dept of Computer Science and Engineering

COMPUTER SCIENCE AND ENGINEERING @

MLRITM
COMPUTER SCIENCE AND ENGINEERING @
MLRITM
 SE – Unit IV
MLRITM

This unit Can be Organized into two sections:

Testing Strategies :
A strategic approach to software testing,
Test strategies for conventional software,
Black-Box and White-Box testing,
Validation testing,
System testing,
The art of Debugging.

MARRI LAXMAN REDDY INSTITUTE OF TECHNOLOGY AND MANAGEMENT

(AN AUTONOMOUS INSTITUTE)
 MLRITM SE – Unit IV

• Testing has been described as the process of executing a program

with the intention of finding errors.
• Testing is the process of evaluating a system or its component(s) with
the intent to find whether it satisfies the specified requirements or not.
• Testing is executing a system in order to identify any gaps, errors, or
missing requirements in contrary to the actual requirements.
• According to ANSI/IEEE 1059 standard, Testing can be defined as - A
process of analyzing a software item to detect the differences between
existing and required conditions (that is defects/errors/bugs) and to
evaluate the features of the software item.

Software Tests - Definition

Software testing is a formal process carried out by a specialized testing
team in which a software unit, several integrated software units or an
entire software package are examined by running the programs on a
computer. All the associated tests are performed according to
approved test procedures on approved test cases.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Objectives:
a. To identify and reveal as many errors as possible in the tested
software.
b. To bring the tested software, after correction of the identified
errors and retesting, to an acceptable level of quality.
c. To perform the required tests efficiently and effectively, within the
limits budgetary and scheduling limitation.
d. To compile a record of software errors for use in error prevention
(by corrective and preventive actions)

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Generic Characteristics
• To perform effective testing, you should conduct effective technical
reviews. By doing this, many errors will be eliminated before
testing commences.
• Testing begins at the component level and works “outward” toward
the integration of the entire computer-based system.
• Different testing techniques are appropriate for different software
engineering approaches and at different points in time.
• Testing is conducted by the developer of the software and (for large
projects) an independent test group.
• Testing and debugging are different activities, but debugging must
be accommodated in any testing strategy.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Testing Strategies:
• A strategy for software testing provides a road map that describes
the steps to be conducted as part of testing.
• when these steps are planned and then undertaken, and how
much effort, time, and resources will be required.
• testing strategy must incorporate test planning, test case design,
test execution, and resultant data collection and evaluation.
• A strategy for software testing is developed by the project
manager, software engineers, and testing specialists.
• Software is tested to uncover errors that were made inadvertently
as it was designed and constructed.
• As errors are uncovered, they must be diagnosed and corrected
using a process that is called debugging

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

STLC (Software Testing Life Cycle)

• Software Testing Life Cycle (STLC) is a sequence of specific
activities conducted during the testing process to ensure software
quality goals are met.
• STLC involves both verification and validation activities.
• There are following six major phases in every Software Testing
Life Cycle Model (STLC Model):
Requirement Analysis
Test Planning
Test case development
Test Environment setup
Test Execution
Test Cycle closure

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

What is Entry and Exit Criteria in STLC?

Entry Criteria: Entry Criteria gives the prerequisite items that must be completed
before testing can begin.
Exit Criteria: Exit Criteria defines the items that must be completed before testing can
be concluded

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Test Planning in this phase in which a Senior QA manager determines the

test plan strategy along with efforts and cost estimates for the project.
Moreover, the resources, test environment, test limitations and the testing
schedule are also determined. The Test Plan gets prepared and finalized in
the same phase.
Test Planning Activities
• Preparation of test plan/strategy document for various types of testing
• Test tool selection
• Test effort estimation
• Resource planning and determining roles and responsibilities.
• Training requirement
Deliverables of Test Planning
• Test plan /strategy document.
• Effort estimation document.
Test Case Development Phase
The Test Case Development Phase involves the creation, verification and
rework of test cases & test scripts after the test plan is ready.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Test Case Development Activities

• Create test cases, automation scripts (if applicable)
• Review and baseline test cases and scripts
• Create test data (If Test Environment is available)
Deliverables of Test Case Development
• Test cases/scripts
• Test data
Test Environment Setup decides the software and hardware conditions under which a work
product is tested. It is one of the critical aspects of the testing process and can be done in
parallel with the Test Case Development Phase. Test team may not be involved in this activity
if the development team provides the test environment. The test team is required to do a
readiness check (smoke testing) of the given environment.
Test Environment Setup Activities
Understand the required architecture, environment set-up and prepare hardware and software
requirement list for the Test Environment.
Setup test Environment and test data
Perform smoke test on the build
Deliverables of Test Environment Setup
Environment ready with test data set up
Smoke Test Results.
CSE AND IT @MLRITM
 MLRITM SE – Unit IV

Test Execution Phase is carried out by the testers in which testing of the software build is
done based on test plans and test cases prepared. The process consists of test script
execution, test script maintenance and bug reporting. If bugs are reported then it is
reverted back to development team for correction and retesting will be performed.
Test Execution Activities
• Execute tests as per plan
• Document test results, and log defects for failed cases
• Map defects to test cases in RTM
• Retest the Defect fixes
• Track the defects to closure
Deliverables of Test Execution
• Completed RTM with the execution status
• Test cases updated with results
• Defect reports

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Deliverables of Test Cycle Closure

• Test Closure report
• Test metrics

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Test Cycle Closure phase is completion of test execution which involves

several activities like test completion reporting, collection of test completion
matrices and test results. Testing team members meet, discuss and analyze
testing artifacts to identify strategies that have to be implemented in future,
taking lessons from current test cycle. The idea is to remove process
bottlenecks for future test cycles.
Test Cycle Closure Activities
• Evaluate cycle completion criteria based on Time, Test coverage, Cost,
Software, Critical Business Objectives, Quality
• Prepare test metrics based on the above parameters.
• Document the learning out of the project
• Prepare Test closure report
• Qualitative and quantitative reporting of quality of the work product to the
customer.
• Test result analysis to find out the defect distribution by type and severity.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Verification and Validation(V&V)

Testing Strategy
• Software testing is often referred to as verification and
Validation.
• Verification refers to the set of tasks that ensure that software
correctly implements a specific function.
Checking of whether we are building the product right
• Validation refers to a different set of tasks that ensure that the
software that has been built is traceable to customer
requirements.
Checking of whether we are building the right product
Verification followed by Validation

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Verification
Verification is the process of checking that a software achieves its
goal without any bugs. It is the process to ensure whether the
product that is developed is right or not. It verifies whether the
developed product fulfills the requirements that we have.
Verification is Static Testing.
Activities involved in verification:
• Inspections
• Reviews
• Walkthroughs
• Desk-checking

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Validation
Validation is the process of checking whether the software
product is up to the mark or in other words product has high
level requirements. It is the process of checking the validation of
product i.e. it checks what we are developing is the right
product. it is validation of actual and expected product.
Validation is the Dynamic Testing.
Activities involved in validation:
• Black box testing
• White box testing
• Unit testing
• Integration testing

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

A strategic Approach to software Testing

• The software process may be viewed as the spiral

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

A strategy for software testing may also be viewed in the context of

the spiral
i) Unit testing begins at the vortex of the spiral and concentrates on
each unit (e.g., component, class) of the software as implemented
in source code. Tests focus on each component individually,
ensuring that it functions properly as a unit. Hence, the name
unit testing.
ii) Integration testing focus on design and software architecture.
Components must be assembled or integrated to form the
complete software package. Integration testing addresses the
issues associated with the dual problems of verification and
program construction. Test case design techniques that focus on
inputs and outputs are more prevalent during integration.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

IV) Validation testing, where requirements established as part of

requirements modeling are validated against the software that has
been constructed. Validation testing provides final assurance that
software meets all informational, functional, behavioral, and
performance requirements.

iv) System testing, where the software and other system elements
are tested as a whole. Software, once validated, must be combined
with other system elements (e.g., hardware, people, databases).
System testing verifies that all elements mesh properly and that
overall system function/performance is achieved.

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Test strategies for Conventional Software

There are many strategies that can be used to test software.

▪ At one extreme, you can wait until the system is fully constructed
and then conduct tests on the overall system in hopes of finding
errors. This approach, although appealing, simply does not work.
It will result in buggy software that disappoints all stakeholders.

▪ At the other extreme, you could conduct tests on a daily basis,

whenever any part of the system is constructed. This approach,
although less appealing to many, can be very effective.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Types of Test strategies

• Unit Testing
• Integration Testing
• Validation Testing
• System Testing

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Unit Testing

• Unit testing focuses verification effort on the smallest unit of

software design—the software component or module.
• The Process of executing a single unit/module without effecting
other modules present in the software and comparing the actual
outputs with predefined outputs in the component level
CSE AND IT @MLRITM
 MLRITM SE – Unit IV

The Developers are responsible for performing unit testing, this

can be carried at least once during software development and
repeated depending on changes.
Unit-test Considerations:
• The module interface is tested to ensure that information
properly flows into and out of the program unit under test .
• Local data structures are examined to ensure that data stored
temporarily maintains its integrity during all steps in an
algorithm’s execution.
• Boundary conditions are tested to ensure that the module
operates properly at boundaries established to limit or restrict
processing.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

• All independent paths through the control structure are exercised

to ensure that all statements in a module have been executed at
least once.
• Error-handling paths are tested.

Test cases should be designed to uncover errors due to erroneous

computations, incorrect comparisons, or improper control flow.

Unit-test procedures. Unit testing is normally considered as an

adjunct to the coding step. A review of design information provides
guidance for establishing test cases. Each test case should be coupled
with a set of expected results.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Integration Testing
• Integration testing is a systematic technique for constructing the
software architecture while at the same time conducting tests to
uncover errors associated with interfacing.
• The objective is to take unit-tested components and build a
program structure that has been dictated by design.
• The entire program is tested as a whole. A set of errors is
encountered. Correction is difficult because isolation of causes is
complicated by the vast expanse of the entire program.
• The program is constructed and tested in small increments, where
errors are easier to isolate and correct; interfaces are more likely to
be tested completely; and a systematic test approach may be
applied.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

• When individual components are already tested using unit testing

and all errors are uncovered, then the reason for integration testing
is to ensure that units work perfectly in isolation.
• When Modules are integrated following problems may raised:
▪ Data loss
▪ Increased impression error
▪ The purpose of modules may not fulfilled
▪ Modules may badly effect

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Integration Testing

Non-Increm
Incremental ental
Testing Testing

Big-Bang

Top-Dow Bottom-
Sandwich Regression Smoke
n Up

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Top-down integration
• Top-down integration testing is an incremental approach to
construction of the software architecture.
• Modules are integrated by moving downward through the
control hierarchy, beginning with the main control module
(main program).
• Modules subordinate to the main control module are
incorporated into the structure in either a
• depth-first or
• breadth-first manner.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Depth-first integration integrates all components on a major control path of the program
structure. For example, selecting the left-hand path, components M1, M2 , M5 would be
integrated first. Next, M8 or M6 would be integrated. Then, the central and right-hand control
paths are built.

Breadth-first integration incorporates all components directly subordinate at each level,

moving across the structure horizontally. From the figure, components M2, M3, and M4
would be integrated first. The next control level, M5, M6, and so on, follows

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

The integration process is performed in a series of five steps:

1. The main control module is used as a test driver and stubs are
substituted for all components directly subordinate to the main
control module.
2. Depending on the integration approach selected (i.e., depth or
breadth first), subordinate stubs are replaced one at a time with actual
components.
3. Tests are conducted as each component is integrated.
4. On completion of each set of tests, another stub is replaced with
the real component.
5. Regression testing may be conducted to ensure that new errors
have not been introduced
The process continues from step 2 until the entire program structure
is built.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Bottom-Up Integration Testing

• Bottom-up integration testing, as its name implies, begins
construction and testing with atomic modules (i.e., components at
the lowest levels in the program structure).
• Bottom-up integration strategy may be implemented with the
following steps:
1. Low-level components are combined into clusters that perform a
specific software subfunction.
2. A driver (a control program for testing) is written to coordinate test
case input and output.
3. The cluster is tested.
4. Drivers are removed and clusters are combined moving upward in
the program structure.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Integration follows the pattern illustrated in Figure 17.6.

Components are combined to form clusters 1, 2, and 3. Each of
the clusters is tested using a driver (shown as a dashed block).

Components in clusters 1 and 2 are subordinate to Ma. Drivers D1

and D2 are removed and the clusters are interfaced directly to Ma.
Similarly, driver D3 for cluster 3 is removed prior to integration
with module Mb. Both Ma and Mb will ultimately be integrated
with component Mc, and so forth

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Sandwich
• Sandwich Testing is the combination of bottom-up approach and
top-down approach, so it uses the advantage of both bottom up
approach and top down approach.
• Initially it uses the stubs and drivers where stubs simulate the
behaviour of missing component. It is also known as the Hybrid
Integration Testing.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Regression Testing
• Each time a new module is added as part of integration testing, the
software changes. New data flow paths are established, new I/O
may occur, and new control logic is invoked. These changes may
cause problems with functions that previously worked flawlessly.
In the context of an integration test strategy, regression testing is
the re execution of some subset of tests that have already been
conducted to ensure that changes have not propagated unintended
side effects.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Smoke Testing
• Smoke testing is an integration testing approach that is
commonly used when product software is developed.
• The smoke test should exercise the entire system from end to
end.
The smoke-testing approach encompasses the following activities:
1. Software components that have been translated into code are
integrated into a build that are required to implement one or
more product functions
2. A series of tests is designed to expose errors that will keep the
build from properly performing its function. The intent should
be to uncover “showstopper” errors.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

3.The build is integrated with other builds, and the entire product
is smoke tested daily. The integration approach may be top
down or bottom up.
Smoke testing provides a number of benefits when it is applied on
complex, time critical software projects:

• Integration risk is minimized.

• The quality of the end product is improved.
• Error diagnosis and correction are simplified.
• Progress is easier to assess.
• Integration test documentation.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Non Incremental Testing

• The units are tested in unit testing are first combined to form a single
software package and then the package is tested as a whole such
approach is called non incremental or big bang approach.
Advantages:
• The big bang approach can be useful only for small systems.

Disadvantages:
• Testing can commence only after completion of coding.
• Testing may not uncover interface errors.
• Modules critical to the system may not receive the extra testing.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Validation Testing
• Software validation is achieved through a series of tests that
demonstrate conformity with requirements.
• A test plan outlines the classes of tests to be conducted.
• A test procedure defines specific test cases that are designed to
ensure that all functional requirements are satisfied.
• all behavioral characteristics are achieved,
• all content is accurate and properly presented,
• all performance requirements are attained,
• documentation is correct, and usability and other requirements
are met

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Alpha and Beta Testing

• It is virtually impossible for a software developer to foresee how
the customer will really use a program.
• A series of acceptance tests are conducted for end users to validate
all requirements.
• An acceptance test can range from an informal “test drive” to a
planned and systematically executed series of tests.
• Acceptance testing can be conducted over a period of weeks or
months, thereby uncovering cumulative errors that might degrade
the system over time.
• The alpha test is conducted at the developer’s site by a
representative group of end users. Alpha tests are conducted in a
controlled environment.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

• The beta test is conducted at one or more end-user sites. Unlike

alpha testing, the developer generally is not present.
• The beta test is a “live” application of the software in an
environment that cannot be controlled by the developer.
• The customer records all problems that are encountered during beta
testing and reports these to the developer at regular intervals.
• As a result of problems reported during beta tests, developer make
modifications and then prepare for release of the software product
to the entire customer base.
• A variation on beta testing, called customer acceptance testing, is
sometimes performed when custom software is delivered to a
customer under contract.
• The customer performs a series of specific tests in an attempt to
uncover errors before accepting the software from the developer.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

SYSTEM TESTING
• System testing is a series of different tests whose primary purpose
is to fully exercise the computer-based system.
• Software is incorporated with other system elements (e.g.,
hardware, people, information), and a series of system integration
and validation tests are conducted.
• After integration with other elements and tested this type of testing
called system testing.
• A classic system-testing problem is “finger pointing.” This occurs
when an error is uncovered, and the developers of different system
elements blame each other for the problem.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

SYSTEM TESTING
• Recovery Testing
• Security Testing
• Stress Testing
• Performance Testing
Recovery Testing:
• Recovery testing is a system test that forces the software to fail in a
variety of ways and verifies that recovery is properly
performed.
• If recovery is automatic (performed by the system itself),
reinitialization, checkpointing mechanisms, data recovery, and
restart are evaluated for correctness.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

• Many computer-based systems must recover from faults and

resume processing.
Security Testing
• Any computer-based system that manages sensitive information or
causes actions that can improperly harm (or benefit) individuals is
a target for improper or illegal penetration.
• Security testing attempts to verify that protection mechanisms
built into a system will, in fact, protect it from improper
penetration
Stress Testing
• Stress testing executes a system in a manner that demands
resources in abnormal quantity, frequency, or volume.
• Stress tests are designed to confront programs with abnormal
situations.
• A variation of stress testing is a technique called sensitivity testing.
CSE AND IT @MLRITM
 MLRITM SE – Unit IV

Performance Testing
• Performance testing is designed to test the run-time performance
of software within the context of an integrated system.
Ex. Real time embedded System.

Performance tests are often coupled with stress testing and usually
require both hardware and software instrumentation.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

BLACK-BOX and WHITE-BOX TESTING

• Black-box testing, also called behavioral testing, focuses on the
functional requirements of the software.
• black-box testing techniques enable to derive sets of input conditions
that will fully exercise all functional requirements for a program.
•

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

THE ART OF DEBUGGING

• Software testing is a process that can be systematically planned
and specified.
• Test case design can be conducted, a strategy can be defined, and
results can be evaluated against prescribed expectations.
• Debugging occurs as a consequence of successful testing.
• when a test case uncovers an error, debugging is the process that
results in the removal of the error
• Debugging is not testing but often occurs as a consequence of
testing.
• the debugging process begins with the execution of a test case.
Results are assessed and a lack of correspondence between
expected and actual performance is encountered.

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

• The debugging process attempts to match symptom with cause,

thereby leading to error correction.
• The debugging process will usually have one of two outcomes
(1) the cause will be found and corrected OR
(2) the cause will not be found
A few characteristics of bugs provide some clues:
1. The symptom and the cause may be geographically remote. That is, the symptom
may appear in one part of a program, while the cause may actually be located at a
site that is far removed.
2. The symptom may disappear (temporarily) when another error is corrected.
3. The symptom may actually be caused by non errors (e.g., round-off inaccuracies).
4. The symptom may be caused by human error that is not easily traced.
5. The symptom may be a result of timing problems, rather than processing
problems.
6. It may be difficult to accurately reproduce input conditions (e.g., a real-time
application in which input ordering is indeterminate).

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

7. The symptom may be intermittent. This is particularly common in embedded

systems that couple hardware and software.
8. The symptom may be due to causes that are distributed across a number of tasks
running on different processors.

Automated debugging:

• A wide variety of debugging compilers, dynamic debugging aids

(“tracers”), automatic test-case generators, and cross-reference
mapping tools are available.
• Integrated development environments (IDEs) provide a way to
capture some of the language specific predetermined errors (e.g.,
missing end-of-statement characters, undefined variables, and
so on) without requiring compilation

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Debugging Strategies:
• Debugging objective— to find and correct the cause of a
software error or defect. Three debugging strategies have
been proposed:
(1) brute force - It systematically checks all guesses until the correct
one is found.
(2) backtracking - It is an algorithmic-technique for solving
problems recursively by trying to build a solution incrementally, one
piece at a time.
(3) cause elimination - It is manifested by induction or deduction
and introduces the concept of binary partitioning.

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

▪ Once software requirements have been analyzed and modeled,

software design is the last software engineering action within the
modeling activity and sets the stage for construction
▪ The design model provides detail about software architecture,
data structures, interfaces, and components that are necessary
to implement the system.
▪ The design model is assessed by the software team in an effort to
determine whether it contains errors, inconsistencies, or
omissions; whether better alternatives exist; and whether the
model can be implemented within the constraints, schedule, and
cost.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Three characteristics of a good design

The goal of design is to produce a model or representation

that exhibits firmness, commodity, and delight.
Firmness: A program should not have any bugs that
inhibit its function.
Commodity: A program should be suitable for the purposes
for which it was intended.
Delight: The experience of using the program should be a
pleasurable one.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Goal of Design Process:

1. The design must implement all of the explicit requirements contained

in the requirements model, and it must accommodate all of the implicit
requirements desired by stakeholders.
2. The design must be a readable, understandable guide for those who
generate code and for those who test and subsequently support the
software.
3. The design should provide a complete picture of the software,
addressing the data, functional, and behavioral domains from an
implementation perspective.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Quality Guidelines:
In order to evaluate the quality of a design representation (or) to
achieve goals, the software team must establish technical criteria
for good design. Consider the following guidelines:
1. A design should exhibit an architecture that
(a) has been created using recognizable architectural styles or
patterns,
(b) is composed of components that exhibit good design
characteristics
(c) can be implemented in an evolutionary fashion, thereby
facilitating implementation and testing.
2. A design should be modular; that is, the software should be
logically partitioned into elements or subsystems.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

3. A design should contain distinct representations of data,

architecture, interfaces, and components.
4. A design should lead to data structures that are appropriate for
the classes to be implemented and are drawn from recognizable data
patterns.
5. A design should lead to components that exhibit independent
functional characteristics.
6. A design should lead to interfaces that reduce the complexity of
connections between components and with the external environment.
7. A design should be derived using a repeatable method that is
driven by information obtained during software requirements
analysis.
8. A design should be represented using a notation that effectively
communicates its meaning.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Quality Attributes
FURPS—Functionality, Usability, Reliability, Performance, and
Supportability.
The FURPS quality attributes represent a target for all software design:
• Functionality is assessed by evaluating the feature set and capabilities
of the program, the generality of the functions that are delivered, and the
security of the overall system.
• 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.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

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.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

DESIGN CONCEPTS
Fundamental Software Design Concepts provide the software designer with a
foundation from which more sophisticated design methods can be applied
1. Abstraction
2. Architecture
3. Patterns
4. Modularity
5. Information Hiding
6. Functional Independence
7. Refinement
8. Aspects
9. Refactoring
10. Design Classes
CSE AND IT @MLRITM
 MLRITM SE – Unit IV

1. Abstraction:
• At the highest level of abstraction, a solution is stated in broad
terms using the language of the problem environment.
• At lower levels of abstraction, a more detailed description of the
solution is provided and the solution is stated in a manner that can
be directly implemented.
I. A Procedural Abstraction
• A Procedural Abstraction refers to a sequence of instructions
that have a specific and limited function
• The name of a procedural abstraction implies these functions, but
specific details are suppressed.
Ex. open for a door. Open implies a long sequence of procedural
steps (e.g., walk to the door, reach out and grasp knob, turn knob and
pull door, step away from moving door, etc).
CSE AND IT @MLRITM
 MLRITM SE – Unit II

II Data Abstraction
• A Data Abstraction is a named collection of data that describes a
data object.
• The data abstraction for door would encompass a set of attributes
that describe the door (e.g., door type, swing direction, weight,
dimensions, opening mechanism).
2. Architecture
• Software architecture is the structure or organization of program
components (modules).
• The manner in which these components interact, and the structure
of data that are used by the components.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Properties of an Architectural Design:

Structural Properties:
This aspect of the architectural design representation defines the
components of a system (e.g., modules, objects, filters) and the
manner in which those components are packaged and interact with
one another.
Extra-Functional Properties:
The architectural design description should address how the design
architecture achieves requirements for performance, reliability,
security, adaptability, and other system characteristics.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

3. Patterns:
Design pattern describes a design structure that solves a particular
design problem within a specific context.
• 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
(3) whether the pattern can serve as a guide for developing a similar,
but functionally or structurally different pattern.

CSE AND IT @MLRITM

 MLRITM SE – Unit II

4 Modularity:
Software is divided into separately named and addressable
components, sometimes called modules, that are integrated to satisfy
problem requirements.

CSE AND IT @MLRITM

 MLRITM SE – Unit II

• The effort (cost) to develop an individual software module does

decrease as the total number of modules increases.
• However, as the number of modules grows, the effort (cost)
associated with integrating the modules also grows.
• Modularize a design so that development can be more easily
planned.
• Software increments can be defined and delivered; changes can
be more easily accommodated;
• Testing and debugging can be conducted more efficiently, and
long-term maintenance can be conducted without serious side
effects.

CSE AND IT @MLRITM

 MLRITM SE – Unit II

5 Information Hiding:

• The use of information hiding for modular systems provides the

greatest benefits when modifications are required during testing
and later during software maintenance.
• Hiding implies that effective modularity can be achieved by
defining a set of independent modules.
• The principle of information hiding suggests that modules should
be specified and designed so that information contained within a
module is inaccessible to other modules that have no need for
such information.

CSE AND IT @MLRITM

 MLRITM SE – Unit II

6. Functional Independence:
▪ Functional independence is a key to good design, and design is the
key to software quality.

Independence is assessed using two qualitative criteria: cohesion and

coupling.
▪ Cohesion is an indication of the relative functional strength of a
module.
▪ Coupling is an indication of the relative interdependence among
modules.

CSE AND IT @MLRITM

 MLRITM SE – Unit II

7. Refinement :
• Refinement is actually a process of elaboration.
• A statement of function (or description of information) that is
defined at a high level of abstraction i.e no information about the
internal workings of the function or the internal structure of them
information.
• In refinement elaborate on the original statement, providing more
and more detail as each successive refinement (elaboration)
occurs. Stepwise refinement is a top-down design strategy
8. Aspects :
An aspect is a representation of a crosscutting concern
Consider two requirements, A and B. Requirement A crosscuts
requirement B. ie., B cannot be satisfied without taking A into
account.

CSE AND IT @MLRITM

 MLRITM SE – Unit II

For example, the design representation, B of the requirement

received concern that, a registered user must be validated prior to
using SafeHome WebApp.
9. Refactoring:
Refactoring is a reorganization technique that simplifies the
design (or code) of a component without changing its function or
behavior.
When software is refactored, the existing design is examined for
redundancy, unused design elements, inefficient or unnecessary
algorithms, poorly constructed or inappropriate data structures, or
any other design failure that can be corrected to yield a better
design.

CSE AND IT @MLRITM

 MLRITM SE – Unit II

10. Design Classes:

• The requirements model defines a set of analysis classes
• The level of abstraction of an analysis class is relatively high. As
the design model evolves.
• A set of design classes that refine the analysis classes that present
significantly more technical detail as a guide for implementation.
• Five different types of design classes:
• User interface classes define all abstractions that are necessary for
human computer interaction (HCI).
• Business domain classes identify the attributes and services
(methods) that are required to implement some element of the
business domain.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

• 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.

Characteristics of a well-formed design class:

Complete and sufficient
Primitiveness.
High cohesion.
Low coupling.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

The Design Model

• The design model can be viewed in two different dimensions
I. Process Dimension
II. Abstraction Dimension

• Process Dimension:
It indicate the evaluation of the design model as design tasks are
executed as part of the software process.

• Abstraction Dimension:
It indicate the level of details as each element of analysis model is
transformed into design equivalent and then refined iteratively

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

The Design Model

• From the figure the dashed lines indicates the boundary between
analysis and design models.
• The elements of the design model use many of the same UML
diagrams that were used in the analysis model.
• The difference is that these diagrams are refined and elaborated as
part of design;.
• Architectural structure and style, components that reside within the
architecture, and interfaces between the components and with the
outside world are all emphasized.
• The model elements indicated along the horizontal axis are not
always developed in a sequential fashion.
• In most cases preliminary architectural design sets the stage and is
followed by interface design and component-level design, which
often occur in parallel.
CSE AND IT @MLRITM
 MLRITM SE – Unit IV

The Design Model

• The deployment model is usually delayed until the design has been
fully developed.
1. Data Design Elements:
• Data design creates a model of data that is represented at a high level
of abstraction
• 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.
• At the application level, the translation of a data model into a
database is pivotal to achieving the business objectives of a system.
• 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.
CSE AND IT @MLRITM
 MLRITM SE – Unit IV

The Design Model

2. Architectural Design Elements:
• The architectural design for software is the equivalent to the floor
plan of a house.
• The floor plan depicts the overall layout of the rooms; their size,
shape, and relationship to one another; and the doors and
windows that allow movement into and out of the rooms.
• The floor plan gives us an overall view of the house and
Architectural design elements give us an overall view of the
Software.
• The architectural design element is usually depicted as a set of
interconnected subsystems, often derived from analysis packages
within the requirements model.
• Each subsystem may have its own architecture.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

The Design Model

3. Interface Design Elements:
• The interface design for software is analogous to a set of detailed
drawings (and specifications) for the doors, windows, and external
utilities of a house.
• These drawings depict the size and shape of doors and windows, the
manner in which they operate, the way in which utility connections
(e.g., water, electrical, gas, telephone) come into the house and are
distributed among the rooms depicted in the floor plan.
• They tell us where the doorbell is located, whether an intercom is to
be used to announce a visitor’s presence, and how a security system
is to be installed.
• These interface design elements allow the software to communicate
externally and enable internal communication and collaboration
among the components.
CSE AND IT @MLRITM
 MLRITM SE – Unit IV

The Design Model

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.
(3) Internal Interfaces between various design components.

4. Component-Level Design Elements:

• The component-level design for software is the equivalent to a set of
detailed drawings and specifications for each room in a house.
• These drawings depict wiring and plumbing within each room, the
location of electrical receptacles and wall switches, faucets, sinks,
showers, tubs, drains, cabinets, and closets.
• They also describe the flooring to be used, the moldings to be
applied, and every other detail associated with a room.
CSE AND IT @MLRITM
 MLRITM SE – Unit IV

The Design Model

• The component-level design for software fully describes the internal
detail of each software component.
• 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).
5. 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

CSE AND IT @MLRITM

 Mr. B. SRINIVAS GOUD
Assistant Professor -CSE/IT

SOFTWARE ENGINEERING

Dept of Computer Science and Engineering and

Information Technology

COMPUTER SCIENCE AND ENGINEERING @

MLRITM
COMPUTER SCIENCE AND ENGINEERING @
MLRITM
MLRITM SE – Unit IV

PART II
Creating an Architectural Design

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Software Architecture
Data Design
Architectural Styles and Patterns
Architectural Design
Conceptual model of UML
Basic Structural Modeling.
Class diagrams.
Sequence Diagrams.
Collaboration Diagrams.
Use Case Diagrams.
Component Diagrams.
CSE AND IT @MLRITM
 MLRITM SE – Unit IV

SOFTWARE ARCHITECTURE
The software architecture of a program or computing system is the
structure of the system, which comprise software components, the
externally visible properties of those components, and the relationships
among them.
Importance of software architecture:
(1) Architecture enables Analyze the effectiveness of the design in
meeting its stated requirements
(2) Consider architectural alternatives at a stage when making design
changes
(3) Reduce the risks associated with the construction of the software.
(4) Communicate between stakeholders
(5) highlights early design decisions
A design is an instance of an architecture similar to an object being an
instance of a class
CSE AND IT @MLRITM
 MLRITM SE – Unit IV

DATA DESIGN
The data design action translates data objects defined as part of the
analysis model into
1. Database architecture at the application level.
2. Data structures at the Component level.
Data design at Architectural level / Database architecture at the
application level:
• A data warehouse is a separate data environment that encompasses
all data used by a business.
• Data warehouse is a large, independent database that has access to
the data that are stored in databases that serve the set of applications
required by a business
• The data mining techniques, also called knowledge discovery in
databases (KDD) navigate through databases to extract appropriate
business level information.
CSE AND IT @MLRITM
 MLRITM SE – Unit IV

DATA DESIGN
Data design at component level / Data structures at the
Component level:
Data design at the component level focuses on the representation of
data structures that are directly accessed by one or more software
components
Set of principles followed for data specification:
• Data objects should be identified, alternative data organizations
should be considered, and the impact of data modeling on software
design should be evaluated.
• An abstract data type is defined for use in subsequent software
design.
• A data dictionary should be established and used to define both
data and program design.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

DATA DESIGN
• A process of stepwise refinement may be used for the design of
data.
• The representation of data structure should be known only to those
modules that must make direct use of the data contained within the
structure. The concept of information hiding.
• A library of useful data structures and the operations that may be
applied to them should be developed. Data structures can be
designed for reusability.
• A software design and programming language should support the
specification and realization of abstract data types.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

ARCHITECTURAL STYLES AND PATTERNS

• The architectural style is also a template for construction
• The intent of architectural style is to establish a structure for all
components of the system.
Each architectural style describes a system category that encompasses
(1) a set of components (e.g., a database, computational modules) that
perform a function required by a system.
(2) a set of connectors that enable “communication, coordination and
cooperation” among components
(3) constraints that define how components can be integrated to form
the system
(4) semantic models that enable a designer to understand the overall
properties of a system by analyzing the known properties of its
constituent parts

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

ARCHITECTURAL STYLES AND PATTERNS

An architectural Patterns can be used in conjunction with an
architectural style to shape the overall structure of a system.
An architectural pattern differs from an architectural style in a number
of fundamental ways:
(1) the scope of a pattern is focusing on one aspect of the
architecture rather than the architecture in its entirety.
(2) a pattern imposes a rule on the architecture, describing how the
software will handle some aspect of its functionality at the
infrastructure level (e.g., concurrency);
(3) architectural patterns tend to address specific behavioral issues
within the context of the architecture (e.g., how real-time
applications handle synchronization or interrupts).

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

ARCHITECTURAL STYLES

❑ Data Centered Architectures.

❑ Data-flow architectures.
❑ Call and return architectures
❑ Object-oriented architectures
❑ Layered architectures

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

ARCHITECTURAL STYLES
Data Centered Architectures:

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Data Centered Architectures:

• A data store (e.g., a file or database) resides at the center of this
architecture and is accessed frequently by other components that
update, add, delete, or otherwise modify data within the store.
• Client software accesses a central repository.
• Client software accesses the data independent of any changes to the
data or the actions of other client software.
• Data-centered architectures promote integrability.
• Existing components can be changed and new client components
added to the architecture without concern about other clients
(because the client components operate independently).

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

ARCHITECTURAL STYLES
Data-flow Architectures:

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Data-flow Architectures:

• This architecture is applied when input data are to be transformed

through a series of computational or manipulative components into
output data.
• A pipe-and-filter pattern has a set of components, called filters,
connected by pipes that transmit data from one component to the
next.
• The filter does not require knowledge of the workings of its
neighboring filters.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

ARCHITECTURAL STYLES
Call and return architectures:

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Call and Return Architectures :

This architectural style enables you to achieve a program structure that
is relatively easy to modify and scale.
A two substyles exist within this category:

Main program/subprogram architectures. This classic program

structure decomposes function into a control hierarchy where a “main”
program invokes a number of program components that in turn may
invoke still other components.

Remote procedure call architectures. The components of a main

program/subprogram architecture are distributed across multiple
computers on a network.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Object-Oriented Architectures:

• The components of a system encapsulate data and the

operations that must be applied to manipulate the data.
• Communication and coordination between components
are accomplished via message passing.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

ARCHITECTURAL STYLES
Layered Architectures:

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Layered Architectures:

• A number of different layers are defined, each accomplishing

operations that progressively become closer to the machine
instruction set.
• At the outer layer, components service user interface operations.
• At the inner layer, components perform operating system
interfacing.
• Intermediate layers provide utility services and application software
functions.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

PATTERNS
It collaborates with address problems.
Architectural pattern domains:
Access control:
There are many situations in which access to data, features, and
functionality delivered by an application is limited to specifically
defined end users.
Concurrency :
Many applications must handle multiple tasks in a manner that
simulates parallelism
Distribution.
The distribution problem addresses the manner in which systems or
components within systems communicate with one another in a
distributed environment.
CSE AND IT @MLRITM
 MLRITM SE – Unit IV

PATTERNS
The most common architectural pattern established to address the
distribution problem is the Broker pattern.
Persistence:
Persistent data are stored in a database or file and may be read or
modified by other processes at a later time.
In general, two architectural patterns are used to achieve persistence

Database Management System pattern that applies the storage and

retrieval capability of a DBMS to the application architecture.

Application Level- Persistence pattern that builds persistence

features into the application architecture

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

ARCHITECTURAL DESIGN

• The design should define the external entities (other systems,

devices, people) that the software interacts with and the nature of
the interaction.
• Once context is modeled and all external software interfaces have
been described.
• The designer specifies the structure of the system by defining and
refining software components that implement the architecture
• This process continues iteratively until a complete architectural
structure has been derived.

CSE AND IT @MLRITM

MLRITM SE – Unit IV

Representing the System in Context

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

ARCHITECTURAL DESIGN
A software architect uses an architectural context diagram (ACD) to
model the manner in which software interacts with entities external to
its boundaries.
Systems that interoperate with the target system (the system for which
an architectural design is to be developed) are represented as
Superordinate systems—those systems that use the target system as
part of some higher-level processing scheme.
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.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

ARCHITECTURAL DESIGN
Actors—entities (people, devices) that interact with the target system
by producing or consuming information that is necessary for requisite
processing.
Each of these external entities communicates with the target system
through an interface (the small shaded rectangles). Safe Home Security

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

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.
• The target system architecture is composed of these archetypes,
which represent stable elements of the architecture
• Each of archetypes is depicted using UML notation
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(Detector) and (2) a variety of alarm, flashing lights,
bell (indicators).
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.

CSE AND IT @MLRITM

MLRITM SE – Unit IV

Archetype

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

The set of top-level components that address the following

functionality:
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.

Each of these top-level components would have to be elaborated

iteratively and then positioned within the overall SafeHome
architecture.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Conceptual Model of UML

• UML is a standard language for specifying, visualizing,
constructing, and documenting the artifacts of software systems.
• It was initially developed by Grady Booch, Ivar Jacobson, and
James Rumbaugh in 1994-95 at Rational software, and its further
development was carried out through 1996. In 1997, it got adopted
as a standard by the Object Management Group.
• It is used to understand, design, browse, configure, maintain, and
control information about such systems.
• The UML captures information about the static structure and
dynamic behavior of a system.
• UML is not a programming language. Tools can provide code
generators from UML into a variety of programming languages, as
well as construct reverse- engineered models from existing
programs.
CSE AND IT @MLRITM
 MLRITM SE – Unit IV

• UML is intended to be a universal general-purpose modeling

language for discrete systems such as those made of software,
firmware, or digital logic.
• To understand the UML, need to form a conceptual model of the
language, and this requires learning three major elements.
• The UML's basic building blocks, the rules that dictate how those
building blocks may be put together, and some common
mechanisms that apply throughout the UML

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Building Blocks of the UML

The vocabulary of the UML encompasses three kinds of building
blocks:
Things
Relationships
Diagrams
Things are the abstractions that are first-class citizens in a model;
relationships tie these things together; diagrams group interesting
collections of things.
Things in the UML
There are four kinds of things in the UML:
Structural things
Behavioral things
Grouping things
Annotational things
CSE AND IT @MLRITM
 MLRITM SE – Unit IV

Structural Things
Structural things are the nouns of UML models.
These are the mostly static parts of a model, representing elements that
are either conceptual or physical
Collectively, the structural things are called classifiers.
Classes
A class is a description of a set of objects that share the same attributes,
operations, relationships, and semantics.
A class implements one or more interfaces. Graphically, a class is
rendered as a rectangle, usually including its name, attributes, and
operations.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Interface:

• An interface is a collection of operations that specify a service of a

class or component.
• An interface might represent the complete behavior of a class or
component or only a part of that behavior
• An interface defines a set of operation specifications (that is, their
signatures) but never a set of operation implementations.
• An interface provided by a class to the outside world is shown as a
small circle attached to the class box by a line.
• An interface required by a class from some other class is shown as a
small semicircle attached to the class box by a line

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Collaboration

A collaboration defines an interaction and is a society of roles and

other elements that work together to provide some cooperative
behavior that's bigger than the sum of all the elements

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

• Collaborations have structural, as well as behavioral, dimensions.

• Graphically, a collaboration is rendered as an ellipse with dashed
lines, sometimes including only its name

Use Case:
• A use case is a description of sequences of actions that a system
performs that yield observable results of value to a particular actor.
• A use case is used to structure the behavioral things in a model.
• A use case is realized by a collaboration.
• Graphically, a use case is rendered as an ellipse with solid lines,
usually including only its name

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Active Class:
An active class is a class whose objects own one or more processes or
threads and therefore can initiate control activity.
An active class is just like a class except that its objects represent
elements whose behavior is concurrent with other elements
Graphically, an active class is rendered as a class with double lines on
the left and right; it usually includes its name, attributes, and
operations

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Components:
A component is a modular part of the system design that hides its
implementation behind a set of external interfaces.
Within a system, components sharing the same interfaces can be
substituted while preserving the same logical behavior.
The implementation of a component can be expressed by wiring
together parts and connectors
Graphically, a component is rendered like a class with a special
icon in the upper right corner

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Artifacts:
An artifact is a physical and replaceable part of a system that
contains physical information.
An artifact typically represents the physical packaging of source or
run-time information
Graphically, an artifact is rendered as a rectangle with the keyword
«artifact»

Nodes:
A node is a physical element that exists at run time and represents
a computational resource, generally having at least some memory
and, often, processing capability.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

A set of components may reside on a node and may also migrate from
node to node.
Graphically, a node is rendered as a cube, usually including only its
name.

Behavioral Things:
Behavioral things are the dynamic parts of UML models.
These are the verbs of a model, representing behavior over time and
space.
There are three primary kinds of behavioral things
Interaction
State Machines
Activity CSE AND IT @MLRITM
 MLRITM SE – Unit IV

Interaction:
• It is a behavior that comprises a set of messages exchanged
among a set of objects or roles within a particular context to
accomplish a specific purpose.
• The behavior of a society of objects or of an individual operation
may be specified with an interaction.
• An interaction involves a number of other elements, including
messages, actions, and connectors .
• Graphically, a message is rendered as a directed line, almost
always including the name of its operation

Message

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

State Machine:
• It is a behavior that specifies the sequences of states an object or
an interaction goes through during its lifetime in response to
events, together with its responses to those events.
• The behavior of an individual class or a collaboration of classes
may be specified with a state machine.
• A state machine involves a number of other elements, including
states, transitions (the flow from state to state), events (things that
trigger a transition), and activities (the response to a transition).
• Graphically, a state is rendered as a rounded rectangle, usually
including its name and its substates

States

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Activity:
an activity is a behavior that specifies the sequence of steps a
computational process performs.
In an interaction, the focus is on the set of objects that interact
In a state machine, the focus is on the life cycle of one object at a
time.
In an activity, the focus is on the flows among steps without
regard to which object performs each step.
A step of an activity is called an action. Graphically, an action is
rendered as a rounded rectangle with a name indicating its
purpose.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Grouping Things
• Grouping things are the organizational parts of UML models.
• There is one primary kind of grouping thing, namely, packages.
Package:
• A package is a general-purpose mechanism for organizing the
design itself.
• Structural things, behavioral things, and even other grouping things
may be placed in a package.
• Graphically, a package is rendered as a tabbed folder, usually
including only its name and, sometimes, its contents

Packages
CSE AND IT @MLRITM
 MLRITM SE – Unit IV

Annotational Things:
Annotational things are the explanatory parts of UML models.
These are the comments you may apply to describe, illuminate, and
remark about any element in a model.
There is one primary kind of annotational things, called a note.
A note is simply a symbol for rendering constraints and comments
attached to an element or a collection of elements.
Graphically, a note is rendered as a rectangle with a dog-eared corner,
together with a textual or graphical comment.

Notes

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Relationships in the UML

There are four kinds of relationships in the UML:
I. Dependency
II. Association
III. Generalization
IV. Realization
Dependency:
• A dependency is a semantic relationship between two model
elements in which a change to one element (the independent one)
may affect the semantics of the other element.
• Graphically, a dependency is rendered as a dashed line, possibly
directed, and occasionally including a label

Dependencies

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Association
• An association is a structural relationship among classes that
describes a set of links.
• A link being a connection among objects that are instances of the
classes.
• Aggregation is a special kind of association, representing a
structural relationship between a whole and its parts.
• Graphically, an association is rendered as a solid line, possibly
directed, occasionally including a label, and often containing
other adornments, such as multiplicity and end names.

Associations

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Generalizations:
• A generalization is a specialization/generalization relationship in
which the specialized element (the child) builds on the specification
of the generalized element (the parent).
• The child shares the structure and the behavior of the parent.
• Graphically, a generalization relationship is rendered as a solid line
with a hollow arrowhead pointing to the parent.

Realizations:
A realization is a semantic relationship between classifiers, wherein
one classifier specifies a contract that another classifier guarantees to
carry out.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Graphically, a realization relationship is rendered as a cross between a

generalization and a dependency relationship.

Diagrams in the UML

• A diagram is the graphical presentation of a set of elements, most
often rendered as a connected graph of vertices (things) and paths
(relationships).
• Drawing diagrams to visualize a system from different perspectives,
so a diagram is a projection into a system.
• A diagram may contain any combination of things and
relationships.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

List of UML Diagrams

I. Class diagram
II. Object diagram
III. Component diagram
IV. Deployment diagram
V. Use case diagram
VI. Sequence diagram
VII. Collaboration diagram
VIII. State diagram
IX. Activity diagram

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

I. Class diagram
• A class diagram shows a set of classes, interfaces, and
collaborations and their relationships.
• Class diagrams address the static design view of a system.
• Class diagrams that include active classes address the static
process view of a system.
• Class diagram represents the object orientation of a system.
Hence, it is generally used for development purpose.
• The class diagram below models a customer order from a retail
catalog. The central class is the Order. Associated with it are the
Customer making the purchase and the Payment. A Payment is
one of three kinds: Cash, Check, or Credit. The order contains
OrderDetails (line items), each with its associated Item.

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

I. Object diagram
An object diagram shows a set of objects and their relationships.
Object diagrams represent static snapshots of instances of the things found in class
diagrams.
These diagrams address the static design view or static process view of a system as do
class diagrams, but from the perspective of real or prototypical cases.
The usage of object diagrams is similar to class diagrams but they are used to build
prototype of a system from a practical perspective.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Component Diagram:
A component diagram is shows an encapsulated class and its interfaces,
ports, and internal structure consisting of nested components and
connectors.
Component diagrams address the static design implementation view of a
system.
During the design phase, software artifacts (classes, interfaces, etc.) of a
system are arranged in different groups depending upon their relationship.
Now, these groups are known as components.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Deployment Diagram:
• A deployment diagram shows the configuration of run-time
processing nodes and the components that live on them.
• Deployment diagrams address the static deployment view of an
architecture. A node typically hosts one or more artifacts.
• Deployment diagrams are used for visualizing the deployment view
of a system. This is generally used by the deployment team
• The main purpose of the deployment diagram is to represent how
software is installed on the hardware component. It depicts in what
manner a software interacts with hardware to perform its execution.

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Use case Diagram

A use case diagram shows a set of use cases and actors (a special kind
of class) and their relationships.
Use case diagrams address the static use case view of a system.
These diagrams are especially important in organizing and modeling the
behaviors of a system.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Graphical Notation:
The basic components of Use Case diagrams are the Actor, the Use Case, and the Association.
Actor:
An Actor, as mentioned, is a user of the system, and is depicted using a stick figure. The role of
the user is written beneath the icon.

Use Case:
A Use Case is functionality provided by the system, typically described as verb + object (e.g.
Register Car, Delete User). Use Cases are depicted with an ellipse. The name of the use case is
written within the ellipse.

Association:
Associations are used to link Actors with Use Cases, and indicate that an Actor participates in
the Use Case in some form. Associations are depicted by a line connecting the Actor and the Use
Case.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Interaction Diagram
• Both sequence diagrams and collaboration diagrams are kinds of
interaction diagrams. An interaction diagram shows an interaction,
consisting of a set of objects or roles, including the messages that
may be dispatched among them.
• Interaction diagrams address the dynamic view of a system.
• A sequence diagram is an interaction diagram that emphasizes the
time-ordering of messages.
• A communication diagram is an interaction diagram that emphasizes
the structural organization of the objects or roles that send and
receive messages.
• Sequence diagrams and communication diagrams represent similar
basic concepts, but each diagram emphasizes a different view of the
concepts.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Sequence diagrams emphasize temporal ordering, and communication

diagrams emphasize the data structure through which messages flow.
A timing diagram shows the actual times at which messages are
exchanged.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Notation:
In a Sequence diagram, classes and actors are listed as columns, with vertical lifelines
indicating the lifetime of the object over time.
Object:
Objects are instances of classes, and are arranged horizontally. The pictorial representation
for an Object is a class (a rectangle) with the name prefixed by the object name (optional)
and a semi-colon.

Actor:
Actors can also communicate with objects, so they too can be listed as a column. An Actor
is modeled using the ubiquitous symbol, the stick figure.

Lifeline:
The Lifeline identifies the existence of the object over time. The notation for a Lifeline is a
vertical dotted line extending from an object.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Activation:
Activations, modeled as rectangular boxes on the lifeline, indicate when the object is
performing an action.

Message:
Messages, modeled as horizontal arrows between Activations, indicate the communications
between objects.

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

State Diagram
• A state diagram shows a state machine, consisting of states,
transitions, events, and activities.
• A state diagrams shows the dynamic view of an object.
• They are especially important in modeling the behavior of an
interface, class, or collaboration and emphasize the event-ordered
behavior of an object, which is especially useful in modeling
reactive systems.
• Any real-time system is expected to be reacted by some kind of
internal/external events. These events are responsible for state
change of the system.
• A statechart diagram shows the possible states of the object and the
transitions that cause a change in state.

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Activity Diagram:
• An activity diagram shows the structure of a process or other
computation as the flow of control and data from step to step within
the computation.
• Activity diagrams address the dynamic view of a system.
• These are especially important in modeling the function of a system
and emphasize the flow of control among objects.
• Activity diagrams are used to visualize the flow of controls in a
system. This is prepared to have an idea of how the system will
work when executed.
• Activity diagram is a variation of the state diagram where the
"states" represent operations, and the transitions represent the
activities that happen when the operation is complete

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Activity States
Activity states mark an action by an object. The notations for these states are rounded
rectangles, the same notation as found in State chart diagrams.

Transition:
When an Activity State is completed, processing moves to another Activity State. Transitions
are used to mark this movement. Transitions are modeled using arrows.

Swim lane:
Swim lanes divide activities according to objects by arranging objects in column format and
placing activities by that object within that column.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Initial State:
The Initial State marks the entry point and the initial Activity State. The notation for the Initial
State is the same as in State chart diagrams, a solid circle. There can only be one Initial State
on a diagram.

Final State:
Final States mark the end of the modeled workflow. There can be multiple Final States on a
diagram, and these states are modeled using a solid circle surrounded by another circle.

Synchronization Bar:
Activities often can be done in parallel. To split processing ("fork"), or to resume processing
when multiple activities have been completed ("join"), Synchronization Bars are used. These
are modeled as solid rectangles, with multiple transitions going in and/or out.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Rules of the UML

• The UML has a number of rules that specify what a well-formed
model should look like.
• A well-formed model is one that is semantically self-consistent and
in harmony with all its related models.
• The UML has syntactic and semantic rules for
Names What you can call things, relationships, and diagrams

Scope The context that gives specific meaning to a name

Visibility How those names can be seen and used by others

Integrity How things properly and consistently relate to one another

Execution What it means to run or simulate a dynamic model

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Models built during the development of a software-intensive system

tend to evolve and may be viewed by many stakeholders in different
ways and at different times.
It is common for the development team to not only build models that
are well-formed, but also to build models that are
Elided Certain elements are hidden to simplify the view

Incomplete Certain elements may be missing

Inconsistent The integrity of the model is not guaranteed

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Common Mechanisms in the UML

It is made simpler by the presence of four common mechanisms that
apply consistently throughout the language.
1. Specifications
2. Adornments
3. Common divisions
4. Extensibility mechanisms.
Specifications
• The UML is more than just a graphical language.
• Behind every part of its graphical notation there is a specification
that provides a textual statement of the syntax and semantics of that
building block.
• For example, behind a class icon is a specification that provides the
full set of attributes, operations (including their full signatures), and
behaviors that the class embodies
CSE AND IT @MLRITM
 MLRITM SE – Unit IV

Use the UML's specification to state the system's details.

The UML's specifications provide a semantic backplane that contains
all the parts of all the models of a system, each part related to one
another in a consistent fashion.

Adornments:
• Most elements in the UML have a unique and direct graphical
notation that provides a visual representation of the most important
aspects of the element.
• The notation for a class is intentionally designed to be easy to draw,
because classes are the most common element found in modeling
object-oriented systems.
• The class notation also exposes the most important aspects of a
class, namely its name, attributes, and operations.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Examples: The basic notation of association is line, but this could be adorned with
additional details, such as the role names and multiplicity of each end

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Common Divisions:
In modeling, object-oriented systems get divided in multiple ways. For
example, class vs. object, interface vs. implementation An object uses
the same symbol as its class with its name underlined.

Extensibility Mechanisms:
Extensibility mechanisms allow extending the language in controlled
ways. They include Sterotypes, Tagged Values and Constraints.

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Stereotypes
Tagged Values
Constraints

Stereotypes
Stereotypes are used to create new building blocks from existing blocks
New building blocks are domain-specific
Stereotypes are used to extend the vocabulary of a system
Graphically represented as a name enclosed by guillemets (« »)

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Tagged Values
Tagged values are used to add to the information of the element
(not of its instances)
Stereotypes help to create new building blocks, whereas tagged
values help to create new attributes
These are commonly used to specify information relevant to code
generation, configuration management and so on

CSE AND IT @MLRITM

 MLRITM SE – Unit IV

Constraints
Constraints are used to create rules for the model
Rules that impact the behavior of the model, and specify conditions
that must be met
Can apply to any element in the model, i.e., attributes of a class,
relationship
Graphically represented as a string enclosed by braces {....} and placed
near the associated elements or connected to that elements by
dependency relationships

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM

MLRITM SE – Unit IV

CSE AND IT @MLRITM