Chapter 3 notes

Translating analysis model to design model

Software requirements, manifested by the data, functional, and

behavioral models, feed the design task.
Each of the elements of the analysis model provides information that is
necessary to create the four design models required for a complete
specification of design.
Using one of a number of design methods, the design task produces a data
design, an architectural design, an interface design, and a component design.
In the software engineering context, design focuses on four major areas of
concern: data, architecture, interfaces, and components .
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.
Part of data design may occur in conjunction with the design of software
architecture. More detailed data design occurs as each software component is
designed.
The architectural design can be derived from system specification,
the analysis model and the interaction of subsystems defined
within analysis model.

2
The interface design describes how the software communicates within
itself, with systems that inter-operate with it, and with humans who use
it.
An interface implies flow of information and specific type of behavior.
Therefore, data and control flow diagrams provide information for
interface design.
Information obtained from PSPEC, CSPEC and STD serve as basis for
component design
Data Modeling
 Data modeling is one of the parts of requirements modeling.
 The team defines all data objects which are required for system.
 ERD is used to represent all data objects that are entered, stored, transformed
and produced within an application.

1. Data Objects
a. It is a representation of composite information that must be understood by
the software.
b. Composite information means something that has number of different
properties / attributes.
c. A data object can be :
i. an external entity
ii. a thing
iii. a role
iv. a place
v. an organizational unit, etc.
d. The data object can be represented in tabular form. Headings of table
represent the attribute of the object. Rows represent different instances of
object.
Example: To define a data object for student
Enrollment Number Name Department Mobile Number
1001 XYZ A 123456789
1002 ABC B 214365879

In above table, Enrollment number, name , department and mobile number are the
attributes of student.

2. Data Attributes
a. Data attributes define the properties of data objects.
b. One or more attributes must be defined as identifier to uniquely identify each
instance.
c. Attributes can be used to :
o Name an instance of data object
o Describe the instance
o Make reference to another instance in another table
Example: Attributes for Student object would be Enrollment Number, Name,
Mobile number, Name,etc.
Enrollment number acts as identifier attribute.
Name, department will act as descriptive attributes.

3. Relationships
Data objects are connected to one another in different ways.These connections
represent relationship between the objects. These relationships must be represented.
Eg. Person owns a car. Here Person and Car are two different data objects
related to one another.

Owns
Person Car
4. Cardinality
 It describes the degree of association between two entities in a relationship.
 It is specification of number of occurrences of one object that can be related to
number of occurrences of another object.
 It represents relationship in following types:
o One to One relationship
o One to Many relationship
o Many to One relationship
o Many to Many relationship

Analysis Modeling:-

1. Analysis model represents customer requirements by depicting software in three

diffrenent domains as follows:
a. Information Domain
b. Functional Domain

c. Behavioral Domain
2. Analysis model operates as a link between the ’system description’ and the
’design model’.
3. It forms the basis for design model.

Figure 4: Elements of Analysis model model

Elements of the analysis model listed belows.
(a) Scenario based element.
• This type of element represents the system user point of view.
• Scenario based elements are use case diagram, user stories.
(b) Class based elements.
• Class based elements represent objects that the system will
manipulate.
• It defines the object,attributes and relationship.
• It represent the collaboration is occurring between the classes.
• Class based elements are the class diagram, collaboration diagram.
(c) Behavioral elements.
• Behavioral elements represent state of the system and how it is
changed by the external events.
• The behavioral elements are sequenced diagram, state diagram.
(d) Flow based elements
• It shows how the data objects are transformed while they flow be-
tween the various system functions.
• The flow elements are data flow diagram, control flow diagram.

3
3 Design Modeling.
1. Design modeling in Software Engineering represents the features of software that
help engineer to develop it effectively, the architecture, the user interface, and the
component level detail.
2. It is important phase that represent the data structure, program structure,
interface characteristics and procedural details.
3.It is mainly classified into four categories:

Data design
Architectural design
Interface design
Component level design

3.1 Fundamental Design Concepts.

1. Abstraction.
• Abstraction can be defines as ability to look at something without being
concerned with its internal details.
• A solution is stated in large terms using the language of the problem
environment at the highest level abstraction.
• The lower level of abstraction provides a more detail description of the
solution.
• A sequence of instruction that contain a specific and limited function
refers in a procedural abstraction.
• A collection of data that describes a data object is a data abstraction.

2. Architecture.
• Architecture is the structure of program components, the manner in which
these components interact and the structure of data that are used by components.
 Architecture should specify following properties:
o Structural properties : Components of the system and there
interaction
o Extra functional properties: Should address requirements for
performance, reliability, security and other system characteristics.
o Families of related system: Should find repeatable patterns and
increase the ability to resuse.

4
3. Refinement.
• It is the process of elaboration. A hierarchy is developed by decomposing
a macroscopic statement of function in a step-wise fashion until program-
ming language statements are reached.
• In each step, one or several instructions of a given program are decom-
posed into more detailed instructions.
• Abstraction and Refinement are complementary concepts.
4. Modularity.
• A software is separately divided into name and addressable components.
Sometime they are called as modules which integrate to satisfy the prob-
lem requirements.
• We should break the design into modules to make understanding easier
and as a consequence, reduce the cost required.
 Unmodularity and over modularity should be avoided.
 We modularize a design so that :
o development can be easily planned.
o software increments can be defined and delivered.
o testing can be done efficiently.
o changes can be accommodated easily.
o maintenance becomes easy
5. Information hiding
• Modules must be specified and designed so that the information like algo-
rithm and data presented in a module is not accessible for other modules
not requiring that information.
• Hiding implies that effective modularity can be achieved by defining a set
of modules that can communicate with one another only the necessary
information.

5
 6. Functional independence.
• The functional independence is the concept of separation and related to
the concept of modularity, abstraction and information hiding.
• The functional independence is accessed using two criteria i.e Cohesion
and coupling.
• This Fundamental Independence can be divide into two parts.
(a) Cohesion.
– Cohesion is indication of functional strength of module. .
– A cohesive module performs a single task and it requires a small
interaction with the other components.
-- High cohesion is desirable.
(b) Coupling
– Coupling is an indication of interconnection between modules in
a structure of software.
– Low coupling is desirable

7. Refactoring
• It is a reorganization technique which simplifies the design of components
without changing its function behaviour.
• It focuses on improving internal structure .
 By refactoring we can find redundancy, unused design elements, inefficient
algorithms or any other design failure.
8. Concurrency.
• Concurrency in modeling design means the collection of techniques and
mechanisms that enable a computer program to perform several different
tasks simultaneously, or apparently simultaneously.
9. Verification.
• Verification ensures that the product designed is same as the product required.
• It verifies whether the developed product fulfills all the requirements stated by
client.
4 Design Notations.
4.1 Data Flow diagram(DFD).
1. A data flow diagram shows the way information flows through a process or
system.
2. It includes data inputs and outputs, data stores, and the various sub processes
the data moves through.
3. DFD graphically representing the functions, or processes, which capture, ma-
nipulate, store, and distribute data between a system and its environment and
between components of a system.
5. DFDs are built using standardized symbols and notation to describe various
entities and their relationships.

4.1.1 There are four basic symbols that are used to represent a
data-flow diagram.
(a) External entity.
• an outside system that sends or receives data, communicating with
the system being diagrammed.

• They are the sources and destinations of information entering or leav-

ing the system. They might be an outside organization or person, a
computer system or a business system.
• They are also known as terminators, sources and sinks or actors.
They are typically drawn on the edges of the diagram.
(b) Process.

10
 • A process that changes the data, producing an output. It might
perform computations, or sort data based on logic, or direct the data
flow based on business rules.
• A short label is used to describe the process, such as “Submit pay-
ment.”
(c) Data store.

• A data is files or repositories that hold information for later use, such
as a database table or a membership form. Each data store receives
a simple label, such as “Orders.”
(d) Data flow.
• The route that data takes between the external entities, processes
and data stores. It is interface between the other components and
is shown with arrows, typically labeled with a short data name, like
“Billing details.”

11
4.1.2 Levels in Data Flow Diagrams (DFD)
(a) n Software engineering DFD(data flow diagram) can be drawn to repre-
sent the system of different levels of abstraction.
(b) Higher level DFDs are partitioned into low levels-hacking more informa-
tion and functional elements.
(c) Levels in DFD are numbered 0, 1, 2 or beyond. Here, we will see mainly
3 levels in data flow diagram, which are: 0-level DFD, 1-level DFD, and
2-level DFD.
i. 0-level DFD:

• It is also known as context diagram.It’s designed to be an ab-

straction view, showing the system as a single process with its
relationship to external entities.
• It represent the entire system as process with input and output
data indicated by incoming/outgoing arrows.
ii. 1-level DFD:

• In 1-level DFD, context diagram is decomposed into multiple

bubbles/processes.

12
 • in this level we highlight the main functions of the system and
breakdown the high level process of 0-level DFD into subpro-
cesses.
iii. 2-level DFD:

• 2-level DFD goes one step deeper into parts of 1-level DFD.
• It can be used to plan or record the specific/necessary detail
about the system’s functioning.

4.2 Structured flowchart

Structure Chart represents the hierarchical structure of modules. It breaks down the
entire system into the lowest functional modules and describes the functions and
sub-functions of each module of a system in greater detail
Symbols used in structured flowchart

1. Module
It represents the process or task of the system. It is of three types:
Control Module: A control module branches to more than one submodule.
Sub Module: Sub Module is a module which is the part (Child) of another module.
Library Module: Library Module are reusable and invokable from any module.

13
2. Conditional Call
It represents that control module can select any of the sub module on the basis of
some condition.

3. Loop (Repetitive call of module)

It represents the repetitive execution of module by the sub module. A curved
arrow represents a loop in the module.

4. Data Flow
It represents the flow of data between the modules. It is represented by a directed
arrow with an empty circle at the end.

14
4.3 Decision Table.
1. A decision table is a notation that translates actions and conditions in tabular
form.
2. The table is divided into four sections. The upper left quadrant represents list of
all conditions. The lower left quadrant contains all actions. The right hand
quadrants form a matrix that indicates condition combinations and corresponding
actions that will occur for specific combinations.

The following steps are applied to develop a decision table:

1. List all actions that can be associated with a specific procedure (or component).
2. List all conditions (or decisions made) during execution of the procedure.
3. Associate specific sets of conditions with specific actions, eliminating impossible
combinations of conditions.
4. Define rules by indicating what actions occur for a set of conditions.

Example:
Consider a shop with 3 types of customer (based on amount of business they do
with the shop) regular, silver and gold customer. Regular customers are given no
discounts, silver customers are given 8% discount, gold customers are given 15%
discount. Additional x% discount is given if the shop permits. The decision table
will be as follows for above scenario:

15
5 Testing.
1. Software testing is a method to verify and validate functionality of the
software program.

2. The process checks whether the actual requirements matches the expected
requirements and ensures the software is bug free.

3. The process identifies the errors, defects or missing requirements in contrast to

actual requirements.

5.1 Purpose of Testing.

(a) Software testing is really required to point out the defects and errors.
(b) To improve the quality of the software.
(c) To increase customer satisfaction.
(d) To verify and validate if the system is fit for purpose.
(e) To save time and money for maintenance

16