Analysis and Design Engineering

Introduction of Analysis elements

Introduction to analysis element
 Introduction to analysis element

• The analysis model must achieve three primary objectives:

(1) to describe what the customer requires.
(2) to establish a basis for the creation of a software design.
(3) to define a set of requirements that can be validated once the
software is built.
 Introduction to analysis element

The structure of the analysis mode

Data Dictionary
• At the core of the model lies the data dictionary—a repository that
contains descriptions of all data objects consumed or produced by
the software.
The entity relation diagram (ERD)
• It depicts relationships between data objects.
 E-R Diagram

• Entity
• A data object can be an external entity (e.g., anything that produces or consumes information),
• a thing (e.g., a report or a display), an occurrence (e.g., a telephone call) or event (e.g., an alarm
• a place (e.g., a warehouse), or a structure (e.g., a file).
• For example, a person or a car can be viewed as a data object in the sense that either can be
defined in terms of a set of attributes.
 E-R Diagram

Relationships: Data objects are connected to one another in different ways.

• Consider two data objects, book and bookstore.
• example, • A bookstore orders books. • A bookstore displays books.
• The relationship between two entities could be
1. one-to-one
2. Many to one
3. One to Many
The data flow diagram (DFD)
• It serves two purposes:
• (1) to provide an indication of how data are transformed as they
move through the system and
• (2) to depict the functions (and sub-functions) that transform the
data flow.
Data Flow Diagram
Scenario Based Element
 Scenario Based Element

Use Case diagram demonstrates various scenarios in which the

user interacts with the system
• It has two major components:
• (1) Actor – is the user who interacts with the system.
• (2) Use Cases- Processes in the system
 Use case

•
Class Based Element
 Class Diagram

A class is a description of a set of objects that share

the same attributes,operations, relationships, and
Class Name semantics.

Graphically, a class is rendered as a rectangle, usually

attributes including its name, attributes, and operations in
separate,
designated compartments.
operations
Attribute is a property or characterstic of a class.
Class Diagram
Operations describe the class behavior .
Behavioural Based Element
 Behaviour Based Element

Behavioral modeling is an operational principle for all requirements analysis

methods.
• The state transition diagram represents the behaviour of a system by
depicting its states and the events that cause the system to change state.
State chart diagram
• A State chart diagram shows the lifecycle of an object.
• A state is a condition of an object for a particular time.
• An event causes a transition from one state to another state.
• Here is a State chart for a Phone Line object:
State Transition Diagram
 Sequence Diagram:Behavioural Element

• A sequence diagram shows object interactions arranged in time sequence.

• It includes the sequence of messages exchanged between the objects needed to carry
out the functionality of the scenario.
Flow Oriented Element
 Flow oriented Element

The data flow diagram (DFD)

• It serves two purposes:
• (1) to provide an indication of how data are transformed as they
move through the system and
• (2) to depict the functions (and sub-functions) that transform the
data flow.
Data Flow Diagram
 Design Concepts

• Abstraction
• Architecture
• Patterns
• Modularity
• Information hiding
• Functional independence
• Refactoring
• Refining
 Design Concepts

• Abstraction
• at highest level solution is stated in broad terms using language terms of problem environment;
• at lower levels a more detailed description is provided;
• data abstraction is a named collection of data that describes a data object.
• Architecture
• Is the structure/organization of program components (modules), the manner in which these
components interact, and the structure of data that is used by the components.
• Components can be generalized to represent major system elements and their interactions.
 Design Concepts

• Patterns
• Should provide description that enables designer to determine:
o whether pattern is applicable to current work;
o whether the pattern can be reused;
o whether the pattern can serve as a guide for developing similar, but functionally or
structurally different pattern.
• Modularity
• Diving a system into individual unit for simplicity
• “divide an conquer” strategy – it’s easier to solve complex problem when you break it into
manageable pieces.
 Design Concepts
• Information Hiding
• Hiding prevents error propagation outside of a module.
• Hiding defines and enforces access constraints to procedural details and local data structures used within
a module.
• Functional Independence

• Each module should address a specific sub function of requirements and have a simple interface.
• Functional independent modules are easier to develop, maintain, and test;
• Error propagation is reduced and reusable modules are possible;
• Assessed using two qualitative criteria:
o cohesion;
o coupling
• Refinement
• A top-down design strategy by which program is designed by successively refining levels of
procedural detail;
• Abstraction and refinement are complementary features:
o one specifies procedure and data without details;
o other allows to elaborate by providing low-level details.
• Refactoring
• It is the process of changing a software system in such way that it does not alter the external
behavior of the code yet improves its internal structure.
 Design Principles

• Design Principles are as follows:-

• Design must be traceable to the analysis model -The design model translates this
information into an architecture: a set of subsystems that implement major functions, and
a set of component-level designs that are the realization of analysis class.
• Always consider architecture. S/W architecture is the skeleton of the system to be built.
Only after the architecture is built should the component-level issues should be considered.
• Focus on the design of data as it is as important as a design. Data design is an essential
element of architectural design.
 Design Principles

• Interfaces (both user and internal) must be designed. A well designed interface makes
integration easier and assists the tester in validating component functions.
• User interface design should be tuned to the needs of the end-user. “Ease of use.”
• Component-level design should exhibit functional independence. The functionality that is
delivered by a component should be cohesive- that is, it should focus on one and only one
function.
• Components should be loosely coupled to one another and to the external environment.
Design Model
 Data Design

• The data design transforms the information domain model created during analysis into
the data structures that will be required to implement the software.
• The data objects and relationships defined in the entity relationship diagram and the
detailed data content depicted in the data dictionary provide the basis for the data
design activity.
 E-R Diagram

• Entity
• A data object can be an external entity (e.g., anything that produces or consumes information),
• a thing (e.g., a report or a display), an occurrence (e.g., a telephone call) or event (e.g., an alarm
• a place (e.g., a warehouse), or a structure (e.g., a file).
• For example, a person or a car can be viewed as a data object in the sense that either can be
defined in terms of a set of attributes.
 E-R Diagram

• Relationships:
• Data objects are connected to one another in different ways.
• Consider two data objects, book and bookstore.
• example, • A bookstore orders books. • A bookstore displays books.
• The relationship between two entities could be
1. one-to-one
2. Many to one
3. One to Many
Architectural Design
 Architectural Design

• The architectural design defines the relationship between major structural elements of the software.
• The architectural design can be derived from the system specification, the analysis model, and the
interaction of subsystems defined within the analysis model.
 Class Diagram

A class is a description of a set of objects that share

the same attributes,operations, relationships, and
ClassName semantics.

Graphically, a class is rendered as a rectangle, usually

attributes including its name, attributes, and operations in
separate,
designated compartments.
operations
Attribute is a property or characterstic of a class.
Class Diagram
Operations describe the class behavior .
Interface Design
 Interface Design

• The interface design describes how the software communicates within itself, with
systems that interoperate with it, and with humans who use it.
• An interface implies a flow of information (e.g., data and/or control) and a specific type
of behavior.
 Interface Design

The data flow diagram (DFD)

• It serves two purposes:
• (1) to provide an indication of how data are transformed as
they move through the system and
• (2) to depict the functions (and sub-functions) that transform
the data flow.
Data Flow Diagram
Component Level Design
 Component Level Design

• The component-level design transforms structural elements of the software

architecture into a procedural description of software components.
• Information obtained from the PSPEC, CSPEC, and State Transition Diagram serve as the
basis for component design
 Component Level Design

State chart diagram

• A State chart diagram shows the lifecycle of an object.
• A state is a condition of an object for a particular time.
• An event causes a transition from one state to another state.
• Here is a State chart for a Phone Line object:
State Transition Diagram
Testing
 Need of Testing

• Testing is a process of executing a program with the intent of

finding an error.
• Testing is a set of activities that can be planned in advance and
conducted systematically.
• To check the functionality of the software.
• To check whether the software is working as per requirement.
• For this we need to have a set of test cases, design techniques
and testing methods.
 Testing Tactics

• A strategy for software testing provides a road map that the steps are
planned and then undertaken, and how much effort, time, and resources
will be required.
• Therefore, any testing strategy must incorporate test planning, test case
design, test execution, and resultant data collection and evaluation.
• A software testing strategy should be flexible enough to promote a
customized testing approach.
• At the same time, it must be rigid enough to encourage reasonable
planning and management tracking as the project progresses.
 Testing Tactics

Characteristics of good test

• A good test has a high probability of finding an error.
• A good test is not redundant.
• Testing time and resources are limited.
• A good test should be “best of breed”.
• A good test should be neither too simple nor too complex.
 Testing Tactics

Test Traceability Matrix

 TEST CASE

• What is a Test case?

• A test case has components that describe an input, action and an expected
response, in order to determine if a feature of an application is working
correctly.
• A test case is a set of instructions on “HOW” to validate a particular test
objective/target, which when followed will tell us if the expected behavior
of the system is satisfied or not.
 Sample test case

Sr.no Action Inputs Expected Actual Test Test

Output Output REsult Comment

1. Launch https://www.apple.com/ Apple Apple PAss Prema

application home home 10/17/2020

2. Enter correct Login id: test@xyz.com Login Login PAss Prema

login id and Password: ********* success success 10/17/2020
password
Testing Strategies
 Testing Strategies

• Initially, system engineering defines the role of software and leads to software requirements analysis, where the
information domain, function, behaviour, performance, constraints, and validation criteria for software are
established.
• Moving inward along the spiral, you come to design and finally to coding.
• A strategy for software testing may also be viewed in the context of the spiral.
• Unit testing begins at the vortex of the spiral and concentrates on each unit (e.g., component) of the software as
implemented in source code.
• Testing progresses by moving outward along the spiral to integration testing, where the focus is on design and the
construction of the software architecture.
• Taking another turn outward on the spiral, you encounter validation testing, where requirements established as
part of requirements modeling are validated against the software that has been constructed.
• Finally, you arrive at system testing, where the software and other system elements are tested as a whole.
• To test computer software, you spiral out in a clockwise direction.
 Types of Testing

• Unit testing:
• It focuses verification effort on smallest unit of software design- the software component or module.
• It focuses on the internal processing logic and data structures within the boundaries of a component.
• This type of testing can be conducted in parallel for multiple components.
• Integration testing:
• It 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.
• Regression testing:
• It is the re-execution of some sub set of tests that have already been conducted to ensure that changes have not
propagated unintended side effects.
• Validation testing:
• It begins at the culmination of integration testing when individual components have been
exercised.
• The software is completely assembled as a package and interfacing errors have been
uncovered and corrected
• System Testing:
• Testing of the entire system after it is completely integrated.
 Unit Testing

• Unit testing focuses verification effort on the smallest unit of software

design—the software component or module.
• Using the component-level design description as a guide, important
control paths are tested to uncover errors within the boundary of the
module.
• The relative complexity of tests and the errors those tests uncover is
limited by the constrained scope established for unit testing.
• The unit test focuses on the internal processing logic and data structures
within the boundaries of a component. This type of testing can be
conducted in parallel for multiple components.
Unit Testing
 Unit Testing

It checks :-
• 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.
• All independent paths through the control structure are exercised to ensure that all
• statements in a module have been executed at least once.
• Boundary conditions are tested to ensure that the module operates properly at boundaries
• established to limit or restrict processing.
• And finally, all error-handling paths are tested.
Integration Testing
 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.
• Types of Incremental integration testing
• Top down integration
• Bottom up integration
Top Down Integration Testing
•
•
•
•
•
•
•
•