Software vjhghjjkhjkkkghhjhEngineering.pdf

• necessity of software engineering
• Software engineering is an engineering approach for software
development. We can alternatively view it as a systematic
collection of past experience.

• The other approach to tackle problem complexity is decomposition. n
this technique, a complex problem is divided into several smaller
problems and then the smaller problems are solved one by one.
• However, in this technique any random decomposition of a problem
into smaller parts will not help.
• The problem has to be decomposed such that each component of the
decomposed problem can be solved independently and then the
solution of the different components can be combined to get the full
solution.
• If the different subcomponents are interrelated, then the different
components cannot be solved separately.

Program
• Programs are developed by individuals for
their personal use.
• They are small in size and have limited
functionality.
• the programmer himself is the sole user.
• a single developer is involved.
• the user interface may not be very important.
• very little documentation is expected.
• A program can be developed according to the
programmer’s individual style of
development.
Software product
• Software product are developed by group of
individuals.
• software products are extremely large.
• software product used by large number of
users.
• a large number of developers are involved.
• user interface must be carefully designed and
implemented because developers of that
product and users of that product are totally
different.
• a software product must be well documented.
• software product must be developed using
the accepted software engineering principles.

Software Life Cycle Model
• A software life cycle model (also called process model) is a descriptive
and diagrammatic representation of the software life cycle.
• A life cycle model maps the different activities performed on a
software product from its inception to retirement.
• What is the need for a software life cycle model?
• Without using of a particular life cycle model the development of a software
product would not be in a systematic and disciplined manner. When a software
product is being developed by a team there must be a clear understanding
among team members about when and what to do.

Types of software life cycle models
• Classical Waterfall Model
• Iterative Waterfall Model
• V Model
• Prototyping Model
• Evolutionary Model
• Spiral Model
• Agile Model

Different phases of the classical waterfall model
• Classical waterfall model divides the life cycle into the following
phases.
• Feasibility Study
• Requirements Analysis and Specification
• Design
• Coding and Unit Testing
• Integration and System Testing
• Maintenance

Block diagram of Classical Waterfall Model
Phases

Activities undertaken during feasibility study
• At first project managers or team leaders try to have a rough
understanding of what is required to be done by visiting the client
side. They study different input data to the system and output data to
be produced by the system.
• They study what kind of processing is needed to be done on these
data and they look at the various constraints on the behaviour of the
system.
• After they have an overall understanding of the problem they
investigate the different solutions that are possible.

• Then they examine each of the solutions in terms of what kind of
resources required, what would be the cost of development and what
would be the development time for each solution.
Activities undertaken during feasibility study
• Based on this analysis they pick the best solution and determine
whether the solution is feasible financially and technically.
• They check whether the customer budget would meet the cost of the
product and whether they have sufficient technical expertise in the
area of development.

Activities undertaken during requirements
analysis and specification:
• This phase consists of two distinct activities.
• Requirements gathering and analysis
• Requirements specification
• The goal of the requirements gathering activity is to collect all
relevant information from the customer regarding the product to be
developed. This is done to clearly understand the customer

requirements so that incompleteness and inconsistencies are
removed.
• The requirements analysis activity is begun by collecting all relevant
data regarding the product to be developed from the users of the
product and from the customer through interviews and discussions.
Activities undertaken during requirements
analysis and specification:
• Therefore it is necessary to identify all ambiguities and contradictions
in the requirements and resolve them through further discussions
with the customer. After all ambiguities, inconsistencies, and

incompleteness have been resolved and all the requirements properly
understood, the requirements specification activity can start.
• During this activity, the user requirements are systematically
organized into a Software Requirements Specification (SRS)
document.
Activities undertaken during design:
• The goal of the design phase is to transform the requirements
specified in the SRS document into a structure that is suitable for
implementation in some programming language.

• Two distinctly different approaches are available: the traditional
design approach and the object-oriented design approach.
• Traditional design approach : Traditional design consists of two different
activities; first a structured analysis of the requirements specification is carried
out where the detailed structure of the problem is examined. This is followed by
a structured design activity. During structured design, the results of structured
analysis are transformed into the software design.
• Object-oriented design approach : In this technique, various objects that occur in
the problem domain and the solution domain are first identified, and the
different relationships that exist among these objects are identified.

Activities undertaken during coding and unit
testing
• The purpose of the coding and unit testing phase (sometimes called
the implementation phase) of software development is to translate
the software design into source code. Each component of the design
is implemented as a program module.
• During this phase, each module is unit tested to determine the
correct working of all the individual modules. It involves testing each
module in isolation as this is the most efficient way to debug the
errors identified at this stage.

Activities undertaken during integration and
system testing
• Integration of different modules is undertaken once they have been
coded and unit tested. During the integration and system testing
phase, the modules are integrated in a planned manner.
• Finally, when all the modules have been successfully integrated and
tested, system testing is carried out. The goal of system testing is to
ensure that the developed system conforms to its requirements laid
out in the SRS document.

Types of System Testing
• System testing usually consists of three different kinds of testing
activities:
• α – testing: It is the system testing performed by the development team.
• β – testing: It is the system testing performed by a friendly set of customers.
• acceptance testing: It is the system testing performed by the customer himself
after the product delivery to determine whether to accept or reject the
delivered product.

Activities undertaken during maintenance
Maintenance involves performing any one or more of the following
three kinds of activities:
• Correcting errors that were not discovered during the product development
phase. This is called corrective maintenance.
• Improving the implementation of the system, and enhancing the
functionalities of the system according to the customer’s requirements. This is
called perfective maintenance.
• Porting the software to work in a new environment. For example, porting may
be required to get the software to work on a new computer platform or with
a new operating system. This is called adaptive maintenance.

ƒ
Shortcomings of the classical waterfall model
• The classical waterfall model can not be used in practical
development projects because this model supports no mechanism to
handle the errors during any of the phases.
• In practical development environments, the engineers do commit a
large number of errors in almost every phase of the life cycle.
• The source of the defects can be many: oversight, wrong
assumptions, use of inappropriate technology, communication gap
among the project engineers, etc. These defects usually get detected

much later in the life cycle. Therefore, in any practical software
development work, it is not possible to strictly follow the classical
waterfall model.

Iterative waterfall model
• The iterative waterfall model is probably the most widely used
software development model.
• This model is simple to understand and use. However, this model is
suitable only for well-understood problems; it is not suitable for very
large projects and for projects that are subject to many risks.

V-Model
• This model can be essential for those which focus on quality as an
important aspect of the delivery.
• The usage of V-Model can fall under the projects which not focus
on changing the requirements frequently. for example:
• Military projects
• Mission Critical projects, for example, in a Space shuttle • Embedded systems.
• Projects with defined and clear requirements

Evolutionary Model
• The evolutionary approach is suitable for large problems which can be
decomposed into a set of modules for incremental development and
delivery.
• This model is also widely used for object-oriented development
projects.

Prototyping Model
What is prototype in case of software?
A prototype is a toy implementation of the system. A prototype usually
exhibits limited functional capabilities, low reliability, and inefficient
performance compared to the actual software.
What is the need for a prototype in software development?
An important purpose is to illustrate the input data formats, messages,
reports, and the interactive dialogues to the customer. This is a valuable
mechanism for gaining better understanding of the customer’s needs:
• how the screens might look like

• how the user interface would behave
• how the system would produce outputs
Prototyping Model
• The prototyping model is suitable for projects for which either the
user requirements or the underlying technical aspects are not well
understood. This model is especially popular for development of
the user-interface part of the projects.
• A prototype of the actual software product is preferred in the
following situations.
• user requirements are not complete

• technical issues are not clear
Prototyping Model
Example of user requirements are not complete :
In any application software like billing in a retail shop, accounting in a
firm, etc the users of the software are not clear about the different
functionalities required. Once they are provided with the prototype
implementation, they can try to use it and find out the missing
functionalities.
Example of technical issues are not clear :

Suppose a project involves writing a compiler and the development
team has never written a compiler. In such a case, the team can
consider a simple language, try to build a compiler in order to check the
issues that arise in the process and resolve them.

Spiral model
• The Spiral model of software development appears like a spiral with
many loops. The exact number of loops in the spiral is not fixed.
• The spiral model is suitable for development of technically
challenging software products that are prone to several kinds of risks.
• Each loop of the spiral represents a phase of the software process.
For example, the innermost loop might be concerned with feasibility
study. The next loop with requirements specification, the next one
with design, and so on.
• Each phase in this model is split into four sectors (or quadrants).

• First quadrant (Objective Setting)
• During the first quadrant, it is needed to identify the objectives of the phase.
• Examine the risks associated with these objectives
Spiral model
• Second Quadrant (Risk Assessment and Reduction)
• A detailed analysis is carried out for each identified project risk.
• Steps are taken to reduce the risks. For example, if there is a risk that the
requirements are inappropriate, a prototype system may be developed.
• Third Quadrant (Development and Validation)

• Develop and validate the next level of the product after resolving the identified
risks.
• Fourth Quadrant (Review and Planning)
• Review the results achieved so far with the customer and plan the next
iteration around the spiral.
• Progressively more complete version of the software gets built with each
iteration around the spiral.

Agile Model
• Agile Model is a combination of the Iterative and incremental model
with focus on process adaptability and customer satisfaction by rapid
delivery of working software product.
• Agile Methods break the product into small incremental builds. These
builds are provided in iterations.
• At the end of all the iteration, a working product is displayed to the
customer and important stakeholders.

Advantages of Agile Model
• It allows more flexibility to adapt to the changes.
• The new feature can be added easily.
• Customer satisfaction as the feedback and suggestions are taken at
every stage.

Disadvantages of Agile Model
• Lack of documentation.
• Agile needs experienced and highly skilled resources.
• If a customer is not clear about how exactly they want the product to
be, then the project would fail.

Role of System Analyst/Software Architecture
• The following basic questions pertaining to the software product
should be clearly understood by the analyst/architecture in order
to obtain a good grasp of the problem.
• What is the problem?
• Why is it important to solve the problem?
• What are the possible solutions to the problem?
• What exactly are the data input to the system and what exactly are the data
output by the system?
• What are the likely complexities that might arise while solving the problem?

• If there are external software or hardware with which the developed software
has to interface, then what exactly would the data interchange formats with
the external system be?
Important parts of SRS document
The important parts of SRS document are:
• Functional requirements of the system.
• Non-functional requirements of the system, and
• Goals of implementation

Functional requirements of the Systems in SRS
document
• The functional requirements part discusses the functionalities
required from the system.
• The functional view of the system is shown below. Each function fi of
the system can be considered as a transformation of a set of input
data (ii) to the corresponding set of output data (oi).

Non-functional requirements of the Systems
in SRS document
• Non-functional requirements deal with the characteristics of the
system which can not be expressed as functions - such as the

maintainability of the system, portability of the system, usability of
the system, etc.
• Non-functional requirements may include:
• reliability issues,
• accuracy of results,
• human - computer interface issues,
• constraints on the system implementation, etc.

Goals of implementation of the Systems in SRS
document
• The goals of implementation part documents some general
suggestions regarding development. These suggestions guide
tradeoff among design goals.
• The goals of implementation section might document issues such as
revisions to the system functionalities that may be required in the
future, new devices to be supported in the future, reusability issues,
etc.

Properties of a good SRS document
• Concise: The SRS document should be concise and at the same time
unambiguous, consistent, and complete. Verbose and irrelevant
descriptions reduce readability and also increase error possibilities.
• Structured: It should be well-structured. A well-structured document
is , as a result it is easy to understand and modify. In practice, the SRS
document undergoes several revisions to cope up with the customer
requirements.
• Black-box view: It should only specify what the system should do and
refrain from stating how to do these. This means that the SRS

document should specify the external behaviour of the system and
not discuss the implementation issues. For this reason, the SRS
document is also called the black-box specification of a system.
Properties of a good SRS document
• Conceptual integrity: It should show conceptual integrity so that the
reader can easily understand it.
• Response to undesired events: It should characterize acceptable
responses to undesired events. These are called system response to
exceptional conditions.

• Verifiable: All requirements of the system as documented in the SRS
document should be verifiable. This means that it should be possible
to determine whether or not requirements have been met in an
implementation.
Problems without a SRS document
• Without developing the SRS document, the system would not be
implemented according to customer needs.
• Software developers would not know whether what they are
developing is what exactly required by the customer.

• Without SRS document, it will be very much difficult for the
maintenance engineers to understand the functionality of the system.
• It will be very much difficult for user document writers to write the
users’ manuals properly without understanding the SRS document.
Cohesion
• Cohesion is a measure of functional strength of a module.
• A module having high cohesion and low coupling is said to be
functionally independent of other modules.

• By the term functional independence, we mean that a cohesive
module performs a single task or function. A functionally independent
module has minimal interaction with other modules.
Classification of cohesion
• Cohesion is classified in to seven types.
• Coincidental cohesion: A module is said to have coincidental cohesion if it
performs a set of tasks that relate to each other very loosely. In other words
functions have been put in a module out of pure coincidence without any
thought or design. For example module for miscellaneous functions, customer
record usage, displaying of customer record, calculation of total sales, reading
the transaction record etc..

• Logical cohesion: A module is said to be logically cohesive, if all elements of
the module perform similar operations. An example of logical cohesion is the
case where a set of print functions generating different output reports are
arranged into a single module.
• Temporal cohesion: When a module contains functions that are related by
the fact that all the functions must be executed in the same time span. The
set of functions responsible for initialization, start-up, shutdown of some
process.
Classification of cohesion
• Procedural cohesion: A module is said to possess procedural cohesion, if the
set of functions of the module are all part of a procedure in which certain

sequence of steps have to be carried out for achieving an objective. For
example a function which checks file permissions then opens the file.
• Communicational cohesion: A module is said to have communicational
cohesion, if all functions of the module refer to or update the same data
structure. For example module determines customer details like use customer
account no to find and return customer name and loan balance.
• Sequential cohesion: A module is said to possess sequential cohesion, if the
elements of a module form the parts of sequence, where the output from
one element of the sequence is input to the next. For example a function
which reads data from a file and processes the data.

• Functional cohesion: Functional cohesion is said to exist, if different elements
of a module cooperate to achieve a single function. For example Lexical
analysis of an XML and assign seat to airline passenger.
Coupling
• Coupling between two modules is a measure of the degree of
interdependence or interaction between the two modules.
• Coupling is classified in to five types.
• Data coupling: Two modules are data coupled, when methods share data,
regularly through parameters.
• Stamp coupling: Two modules are stamp coupled, if they communicate using
a composite data item such as a record in PASCAL or a structure in C.

• Control coupling: Control coupling exists between two modules, if data from
one module is used to direct the order of instructions execution in another.
• Common coupling: Two modules are common coupled, if they share data
through some global data items. In other words multiple modules reading and
writing to that global location.
• Content coupling: Content coupling exists between two modules, if they
share code.
What is the Need for functional independence ?
• A module having high cohesion and low coupling is said to be
functionally independent of other modules.

• A functionally independent module has minimal interaction with other
modules.
• Functional independence is a key to any good design due to the
following reasons.
• Error isolation: Functional independence reduces error propagation. The reason
behind this is that if a module is functionally independent, its degree of interaction
with the other modules is less. Therefore, any error existing in a module would not
directly effect the other modules.
• Scope of reuse: Since each module does some well-defined and precise function, and
the interaction of the module with the other modules is simple and minimal.
Therefore, a cohesive module can be easily taken out and reused in a different
program.

• Understandability: Complexity of the design is reduced, because different modules
can be understood in isolation as modules are more or less independent of each
other.
Software design
• Design activities can be broadly classified into two important parts
:
• Preliminary (or high-level) design.
• Detailed (or low-level) design.

High-level Design
• High-level design means identification of different modules and
the control relationships among them and the definition of the
interfaces among these modules.
• The outcome of high-level design is called the program structure
or software architecture.
• There are two types of approach present in high level design such
as function oriented design and object oriented design.

Function-oriented design
• A system is viewed as something that performs a set of functions. Starting
at this high-level view of the system, each function is successively refined
into more detailed functions.
• Each of these sub-functions may be split into more detailed subfunctions
and so on.
Example
The owner of a large multi-stored building wants to have a computerized fire
alarm system for his building. Smoke detectors and fire alarms would be
placed in each room of the building. The fire alarm system would monitor
the status of these smoke detectors. Whenever a fire condition is reported

by any of the smoke detectors, the fire alarm system should determine the
location at which the fire condition is reported by any of the smoke detectors
and then sound the alarms only in the neighboring locations. The fire alarm
system should also flash an alarm message on the computer console.
Function-oriented design(Fire-Alarm System )
• Global data item(system state) which represent the state of the
system:
BOOL detector_status[MAX_ROOMS];
int detector_locs[MAX_ROOMS];
BOOL alarm_status[MAX_ROOMS];

/* alarm activated when status is set */
int alarm_locs[MAX_ROOMS];
/* room number where alarm is located */
int neighbor-alarm[MAX_ROOMS][10];
/* each detector has at most 10 neighboring locations */
Function-oriented design(Fire-Alarm System )
• The functions which operate on the system state are :
• interrogate_detectors();
• get_detector_location();

• determine_neighbor();
• ring_alarm();
• reset_alarm();
• report_fire_location();
Object-oriented design
• In the object-oriented design approach, the system is viewed as
collection of objects (i.e. entities).
• Objects have their own internal data which define their state. Each
object manages its own state information.

• Similar objects constitute a class. In other words, each object is a
member of some class. Classes may inherit features from super class.
Object-oriented design(Fire-Alarm System )
Example
class detector
attributes:
status, location, neighbors
operations: create, sense_status,
get_location,

find_neighbors
class alarm
attributes:
location, status operations:
create, ring_alarm,
get_location, reset_alarm
Function oriented Vs Object oriented design
Function oriented design
• System is designed from a
functional viewpoint.
• It uses top down approach.
• DFD is used for design.

Object oriented design
• System is viewed as a
collection of objects.
• It uses bottom up approach.
• UML is used for design.
Function oriented Software design
• Software design deals with transforming the customer requirements,
as described in the SRS document, into a form (a set of documents)
that is suitable for implementation in a programming language.
• The design technique discussed here is called structured
analysis/structured design (SA/SD) methodology.

• As the name itself implies, SA/SD methodology involves carrying out
two distinct activities:
● Structured analysis (SA)
● Structured design (SD)

Schematic diagram of roles of structured
analysis (SA) and structured design (SD)

Structured analysis (SA)
• The structured analysis activity transforms the SRS document into a
graphic model called the DFD model.
• Structured analysis technique is based on the following essential
activity:
• Top-down decomposition approach.
• Divide and conquer principle. Each function is decomposed
independently.
• Graphical representation of the analysis results using Data Flow
Diagrams (DFDs).

What is DFD?
• The DFD (also known as a bubble chart) is a hierarchical graphical
model of a system that shows the different processing activities or
functions that the system performs and the data interchange among
these functions.
• Each function is called a process or a bubble and it is considered as a
processing station (or process) that consumes some input data and
produces some output data.

• A DFD model only represents the data flow aspects and does not show
the sequence of execution of the different functions and the
conditions based on which a function may or may not be executed.
Primitive Symbols of DFD
• A DFD model uses following symbols to represent the functions
performed by a system.

Primitive Symbols description of DFD
• Function symbol: A function is represented using a circle. This symbol is called a
process or a bubble. Bubbles are annotated with the names of the corresponding
functions
• External entity symbol: represented by a rectangle. The external entities are
essentially those physical entities external to the software system which interact

with the system by inputting data to the system or by consuming the data
produced by the system.
• Data flow symbol: A directed arc (or an arrow) is used as a data flow symbol. A
data flow symbol represents the data flow occurring between two processes or
between an external entity and a process in the direction of the data flow arrow.
• Data store symbol: A data store is represented using two parallel lines. It
represents a logical file. That is, a data store symbol can represent either a data
structure or a physical file on disk. Connected to a process by means of a data flow
symbol. The direction of the data flow arrow shows whether data is being read
from or written into a data store.
• Output symbol: The output symbol is used when a hard copy is produced.

Synchronous and asynchronous operations
• If two bubbles are directly connected by a data flow arrow, then they
are synchronous. This means that they operate at the same speed.
• If two bubbles are connected through a data store, as below Figure
then the speed of operation of the bubbles are independent.

Data Dictionary
• Data Dictionary is the major component in the structured analysis methodology of
the system. Every DFD model of a system must be accompanied by a data
dictionary. A data dictionary lists all data items that appear in a DFD model.

• A data dictionary in Software Engineering means a file or a set of files that includes
a database’s metadata such as data ownership, relationships of the data to another
object, and some other data.
• It includes all data flows and the contents of all data stores appearing on all the
DFDs in a DFD model.
• For the smallest units of data items, the data dictionary simply lists their name and
their type and for Composite data items, the data dictionary simply lists their
component data items using certain operators.
• A data dictionary provides a standard terminology for all relevant data for use by
the developers working in a project.
• CASE tool is used to maintain data dictionary as it captures the data items
appearing in a DFD automatically to generate the data dictionary.

Components of Data Dictionary
• In Software Engineering, the data dictionary contains the following
information:
• Name of the item: It can be your choice.
• Aliases: It represents another name.
• Description: Description of what the actual text is all about.
• Related data items: with other data items.
• Range of values: It will represent all possible answers.
• For the smallest units of data items, the data dictionary lists their
name and their type.

• Composite data items can be defined in terms of primitive data items
using the following data definition operators:
Notations Meaning
X = a+b X consists data elements a and b.
X = [a/b] X consists of either elements a or b.
X = a X X consists of optimal data elements a.
X = y[a] X consists of y or more events of data element a

X = [a] z X consists of z or less events of data element a
X = y [a] z X consists of some events of data elements between y and z.
/* */
Anything appearing within /* and */ is considered as a
comment.
[a,b] It represents either a occurs or b occurs.
a+(b) It represents either a occurs or a+b occurs.
{name}* It represents zero or more instances of name data.

{name}5 It represents five instances of name data.
Developing the DFD model of a system:
• The DFD model of a problem consists of many DFDs and a single data
dictionary.
• The top level DFD is called the level 0 DFD or the context diagram.
• This is the most abstract (simplest) representation of the system (highest level). It
is the easiest to draw and understand.
• Level 0 and Level 1 consist of only one DFD each. Level 2 may contain
up to 7 separate DFDs, and level 3 up to 49 DFDs, and so on.

Context Diagram/Level 0 DFD
• The context diagram is the most abstract (highest level) data flow
representation of a system. It represents the entire system as a single
bubble.
• The bubble in the context diagram is annotated with the name of the
software system being developed.
• The context diagram establishes the context in which the system
operates; that is, who are the users, what data do they input to the
system, and what data they received by the system.

• The data input to the system and the data output from the system are
represented as incoming and outgoing arrows.
Level 1 DFD
• The level 1 DFD usually contains three to seven bubbles.
• The system is represented as performing three to seven important
functions.
• To develop the level 1 DFD, examine the high-level functional
requirements in the SRS document.

• If there are three to seven high level functional requirements, then
each of these can be directly represented as a bubble in the level 1
DFD.
• Next, examine the input data to these functions and the data output
by these functions as documented in the SRS document and represent
them appropriately in the diagram.
Commonly made errors while constructing a DFD
model
• A context diagram should represent the system as a single bubble. Many
beginners draws more than one bubble in the context diagram.

• All external entities interacting with the system should be represented
only in the context diagram. In other words external entities should not
appear at other levels of the DFD. Many beginners draws external
entities at all levels of DFDs.
• Only 3 to 7 bubbles per diagram should be allowed, i.e. each bubble
should be decomposed in between 3 and 7 bubbles. Many beginners
draws more than 7 or less than 3 bubbles at all levels of DFDs.
• A data store cannot be connected to another data store or to an
external entity. Many beginners draws data store connects to bubbles
through data arrows.

Commonly made errors while constructing a DFD
model
• All the functionalities of the system must be captured by the DFD
model. Many beginners do not mention some functionalities in DFD.
• The designer should not assume functionality of the system , which is
not specified by the SRS document.
• The data and function names must be intuitive. Many beginners give
data name such as a,b,c etc.

• DFD is the data flow representation of a system, and it does not
represent control information. Followings are some example.
• when or in what order different functions (processes) are invoked.
• we need to represent data that flows between bubbles A and B or bubbles A and C
and not the conditions depending on which the two modules are invoked.
Difference between DFD and Flow Chart
Flow Chart
• The main objective is to
represent the flow of control in
the program.
• It has only a single type of
arrow is used to show the
control flow in the flow chart.

• It is the view of the system at a
lower level.
• 28 symbols used in Flowchart.
Data Flow Diagram (DFD)
• The main objective is to
represent the processes and
data flow between them.
• It defines the flow and process
of data input, data output, and
storing data.
• It is the view of the system at a
high level.
• Five symbols used in a DFD.

Trading-House Automation System (TAS)
• The trading house wants us to develop a computerized system that
would automate various book-keeping activities associated with its
business.
• The following are the salient features of the system to be
developed:
• The trading house has a set of regular customers. The customers place orders
with it for various kinds of commodities. The trading house maintains the
names and addresses of its regular customers. Each of these regular customers

should be assigned a unique customer identification number (CIN) by the
computer.
• Once order is placed, as per current practice, the accounts department of the
trading house first checks the credit-worthiness of the customer. The
creditworthiness of the customer is determined by analyzing the history of his
payments.
• If the customer is not credit-worthy, his orders are not processed any
further and an appropriate order rejection message is generated for the
customer.

• If a customer is credit-worthy, the items that have been ordered are
checked against a list of items that the trading house deals with. The items
in the order which the trading house does not deal with, are not processed
any further and an appropriate apology message for the customer for these
items is generated.
• The items in the customer’s order that the trading house deals with are
checked for availability in the inventory. If the items are available in the
inventory in the desired quantity, then
• A bill with the forwarding address of the customer is printed.
• A material issue slip is printed.
• Inventory data is adjusted to reflect the sale to the customer.

• If any of the ordered items are not available in the inventory in sufficient
quantity to satisfy the order, then these out-of-stock items along with the
quantity ordered by the customer and the CIN are stored in a “pendingorder”
file for the further processing to be carried out.
• The purchase department should be allowed to periodically issue commands
to generate indents. When a command to generate indents is issued, the
system should examine the “pending-order” file to determine the orders that
are pending and determine the total quantity required for each of the items.
• The system should also answer managerial queries regarding the statistics of
different items sold over any given period of time.

The context diagram for the trading house
automation system(TAS)

Data Dictionary for the DFD Model of TAS
• response: [bill + material-issue-slip, reject-message]
• query: period /*query from manager regarding sales statistics */
• period: [date + date, month, year, day]
• date: year + month + day
• year: integer
• month: integer
• day: integer
• order: customer-id + {items + quantity}* + order#

• accepted-order: order /* ordered items available in inventory */
• reject-message: order + message /*rejection message*/
• pending-orders: customer-id + {items + quantity}*
• customer-address: name + house# + street# + city + pin
• name: string
• house#: string
• street#: string
• city: string

• pin: integer
• customer-id: integer
• customer-file: {customer-address}*
• bill: {item + quantity + price}* + total-amount + customer-address + order#
• material-issue-slip: message + item + quantity + customer-address
• message: string
• statistics: {item + quantity + price}*
• sales-statistics: {statistics}* + date
• quantity: integer

• order#: integer /* unique order number generated by the program */
• price: integer
• total-amount: integer
• generate-indent: command
• indent: {indent + quantity}* + vendor-address
• indents: {indent}*
• vendor-address: customer-address
• vendor-list: {vendor-address}*
• item-file: {item}*

• item: string
• indent-request: command

• Legal_character = [a-z|A-Z]
• Legal digit = [0-9]
• Special_character = [@|$|#]
• Book_Details = book _code + book_name + price +author_name + publisher +
• edition + copies
• Book_code = (legal character +legal digit) *
• Book_name = (legal character) *
• Price = (legal digit) *
• Author_name = (legal character) *
• Publisher = (legal character) *
• Edition = (legal digit) *

• Copies = (legal digit) *
• Member_details = name+member_id
• Name=first_name + (middle name) + last name
• first_name = (legal character) *
• member_id= (legal digits) *
• Staff_details = name + staff_id
• staff_id = (legal digit) *
• login=username +password
• username = (legal character + legal digit) *
• password = (legal character + legal digit) *

Structured Design
• The aim of structured design is to transform the results of the
structured analysis (i.e. a DFD representation) into a structure chart.
• The structure chart representation can be easily implemented using
some programming language.

Basic building blocks of Structure Chart
• The basic building blocks which are used to design structure charts are
the following:
• Rectangular boxes: Represents a module.
• Module invocation arrows: Control is passed from one module to another module in
the direction of the connecting arrow.
• Data flow arrows: Arrows are annotated with data name; named data passes from
one module to another module in the direction of the arrow.
• Library modules: Represented by a rectangle with double edges.
• Selection: Represented by a diamond symbol.
• Repetition: Represented by a loop around the control flow arrow.

• In any structure chart, there should be one and only one module at the
top, called the root.
• There should be at most one control relationship between any two
modules in the structure chart. This means that if module A invokes
module B, module B cannot invoke module A.
Transformation of a DFD Model into Structure
Chart
• Structured design provides two strategies to guide transformation of
a DFD into a structure chart:
• Transform analysis

• Transaction analysis
• Normally, one would start with the level 1 DFD, transform it into
module representation using either the transform or transaction
analysis and then proceed toward the lower level DFDs.
• At each level of transformation, it is important to first determine
whether the transform or the transaction analysis is applicable to a
particular DFD.
Whether to apply transform or transaction
processing?

• Given a specific DFD of a model, one would have to examine the data
input to the diagram.
• If for every input data item the processing(processed by input part
bubble, output part bubble and processing part bubble) is same then
transform analysis is applicable. Otherwise, transaction analysis is
applicable.

Steps to design structure chart using Transform
Analysis
• In structure chart we have to draw functional component for each
central transform, for each afferent branch and each efferent
branch.
Guidelines for identifying central transforms:
• Trace the inputs until a bubble is found whose output cannot be deduced
from the inputs alone.
• Processes which validate input are not part of central transform.
• Processes which sort input or filter data are part of central transform.

• First level of structure chart: Draw a box for each input and output
units and a box for the central transform.
Transform Analysis
• Transform analysis identifies the primary functional components
(modules) and the input and output data for these components.
Steps to design structure chart
• The first step in transform analysis is to divide the DFD into three
types of parts:

• Input (afferent branch) : In the DFD, processes which convert input data from
physical to logical form.(e.g. Read characters from the terminal and store in
internal tables and lists.).Each input portion is called afferent branch.
• Processing (central transform)
• Output (efferent branch) : In the DFD, processes which converts output data
from logical form to physical form. Each output portion is called efferent
branch. .(e.g. Read characters from internal tables and lists and display in the
terminal.).
Steps to design structure chart
• In the next level the structure chart is refined by adding sub-functions
required by each of the high-level module.

• These are drawn below a root module, which would invoke these
modules.
• This process of breaking functional components into subcomponents
is called factoring. Factoring can be achieved by adding read and write
modules, error-handling modules, initialization and termination
process, identifying customer modules, etc.
• The factoring process is continued until all bubbles in the DFD are
represented in the structure chart.

Design the structure chart from DFD using
transform analysis
Example RMS Software
Following four basic functions the software needs to perform.
• Accept the input numbers from the user.
• Validate the numbers.
• Calculate the root mean square of the input numbers.
• Display the result.

Context diagram of RMS Software.

Level-1 diagram of RMS Software.

Structure chart design of RMS software
• In the above figure read number and validate number are part of
input part.
• In the above figure display is part of output part.
• In the above figure compute RMS is the processing part.

Transaction analysis
• Transaction analysis is an alternative to transform analysis and is useful while designing
transaction processing programs.

• A transaction allows the user to perform some specific type of work by using the
software.
• For example, ‘issue book’, ‘return book’, ‘query book’, etc., are transactions.
• As in transform analysis, first all data entering into the DFD need to be identified.
• In a transaction-driven system, different data items may pass through different
computation paths through the DFD.
• This is in contrast to a transform centered system where each data item entering the DFD
goes through the same processing steps.
• Each different way in which input data is processed is a transaction. For each identified
transaction, trace the input data to the output.
• All the traversed bubbles belong to the transaction.
• These bubbles should be mapped to the same module on the structure chart.
• In the structure chart, draw a root module and below this module draw each identified
transaction as a module.

The format of structure chart from DFD using
transform analysis
• The structure chart should contain one transaction center module .
• Several module initiated from the transaction center module.
• Each module from the above several module can be divided into sub
module using transform analysis and transaction analysis.

Structure chart design of TAS software
• In the above figure we have seen that it contains many processing
unit , which accept input from different possible input parts.
• Accept order bubble accept input as order.
• Handel query bubble accept input as query.
• Handel incident request bubble accept input as incident request.

• A model in the context of software development can be graphical,
textual, mathematical, or program code-based. Models are very
useful in documenting the design and analysis results.
• Graphical models are very popular because they are easy to
understand and construct.
• Once models of a system have been constructed, these can be used
for a variety of purposes during software development, including the
following:
• Analysis
• Specification
• Code generation

• Design
• Visualize and understand the problem and the working of a system
• Testing, etc.
Unified Modelling Language (UML)
• Different software development houses were using different
notations to document their object-oriented designs.
• Followings are some example of some different software
development houses.
• Object Management Technology [Rumbaugh 1991]
• Booch’s methodology [Booch 1991]

• Object-Oriented Software Engineering [Jacobson 1992]
• Odell’s methodology [Odell 1992]
• Shaler and Mellor methodology [Shaler 1992]
• UML was developed to standardize the large number of
objectoriented modeling notations that has come because for the
above different software development houses.
Unified Modelling Language (UML)
• UML is primarily a graphical modeling tool. However, it often requires
text explanations to accompany the graphical models.

• UML, as the name implies, is a modelling language. It may be used to
visualize, specify, construct, and document the software system.
• It provides a set of notations (e.g. rectangles, lines, ellipses, etc.) to
create a visual model of the system.
• Like any other language, UML has its own syntax and semantics.
• It has successfully been used to model both large and small problems.
• UML is now being used in a large number of software development
projects worldwide.

Unified Modelling Language (UML) Diagram
• UML can be used to construct nine different types of diagrams
to capture five different views of a system.
• Like a building can be modeled from several views (or
perspectives) such as ventilation perspective, electrical
perspective, lighting perspective, heating perspective, etc.
• The UML diagrams can capture the following five views of a
system:
• User’s view
• Structural view

• Behavioural view
• Implementation view
• Environmental view

Different types of diagrams and views
supported in UML

User’s view and Structural view of UML
• User’s view: This view defines the functionalities (facilities) made
available by the system to its users.
• The users’ view is a black-box view of the system where the internal
structure, the dynamic behaviour of different system components,
the implementation etc. are not visible.
• Structural view: The structural view defines the kinds of objects
(classes) important to the understanding of the working of a system
and to its implementation. It also captures the relationships among
the classes (objects).

• The structural model is also called the static model, since the
structure of a system does not change with time.
Behavioural , Implementation and Environmental
view of UML
• Behavioural view: The behavioural view captures how objects
interact with each other to realize the system behaviour.
• Implementation view: This view captures the important components
of the system and their dependencies.

• Environmental view: This view models how the different components
are implemented on different pieces of hardware.
Use case diagram of UML
• Use cases represent the different ways in which a system can be used by
the users. A simple way to find all the use cases of a system is to ask the
question: “What the users can do using the system?”.
• The use cases partition the system behavior into transactions, such that
each transaction performs some useful action from the user’s point of
view.

• To complete each transaction may involve either a single message or
multiple message exchanges between the user and the system to
complete.
• Use cases can be represented by drawing a use case diagram.
• In the use case diagram, each use case is represented by an ellipse with the
name of the use case written inside the ellipse. All the ellipses (i.e. use
cases) of a system are enclosed within a rectangle which represents the
system boundary.

Use case diagram of UML
• The different users of the system are represented by using the stick
person icon. Each stick person icon is normally referred to as an actor.
An actor is a role played by a user with respect to the system use.
• It is possible that the same user may play the role of multiple actors.
Each actor can participate in one or more use cases. The line
connecting the actor and the use case is called the communication
relationship.

• Both the human users and the external systems can be represented
by stick person icons. When a stick person icon represents an external
system, it is annotated by the stereotype <<external system>>.
Use case diagram example of UML
• Following is a use case model for the Supermarket Prize Scheme.
• It contains three usecases as: “register-customer”, “register-sales”,
and “select-winners”.
• It contains four actors such as customer, sales clerk,manager,clerk.

Factoring of use cases
• It is often desirable to factor use cases into component use cases.
Actually, factoring of use cases are required under two situations.
• First, complex use cases need to be factored into simpler use cases.
This would not only make the behavior associated with the use case
much more comprehensible, but also make the corresponding
interaction diagrams more tractable.
• Secondly, use cases need to be factored whenever there is common
behavior across different use cases.
• UML offers three mechanisms for factoring of use cases as follows:

• Generalization
• Includes
• Extends
Generalization
• Use case generalization can be used when one use case that is similar
to another, but does something slightly differently or something
more.

• The child use case inherits the behavior and meaning of the parent
use case.

Includes
• The includes relationship occurs when a chunk of behavior that is
similar across a number of use cases. The factoring of such behavior
will help in not repeating the specification and implementation across
different use cases.
• The includes relationship is represented using a predefined
stereotype <<include>>. In the includes relationship, a base use case
compulsorily and automatically includes the behavior of the common
use cases.

Extends
• The extends relationship is similar to generalization. But unlike
generalization, the extending use case can add additional behavior
only at an extension point only when certain conditions are satisfied.

Class diagrams
• A class diagram describes the static structure of a system. It shows
how a system is structured rather than how it behaves.
• The static structure of a system comprises of a number of class
diagrams and their dependencies.
• A class diagram constitutes classes and their relationships:
generalization, aggregation, association, and various kinds of
dependencies.
• The classes represents entities such as attributes and operations.

• Classes are represented as solid outline rectangles with
compartments. Classes have a mandatory name compartment where
the name is written centered in boldface. The class name is usually
written using mixed case convention and begins with an uppercase.
The class names are usually chosen to be singular nouns.
• Classes have optional attributes and operations compartments.
Class diagrams
Attributes
• Attributes are listed with their names, and may optionally contain
specification of their type, an initial value, and constraints.

Class diagrams
• The type of the attribute is written by appending a colon and the type
name after the attribute name. Typically, the first letter of an attribute
is a small letter. An example for an attribute is given.
• bookName : String
Operation
• Operation is the implementation of a service that can be requested
from any object of the class to affect behavior.

• An object’s data or state can be changed by invoking an operation of
the object. A class may have any number of operations or no
operation at all.
Operation
• Typically, the first letter of an operation name is a small letter. Abstract
operations are written in italics. The parameters of an operation (if any),
may have a kind specified, which may be ‘in’, ‘out’ or ‘inout’.
• An example for an operation is given.
• issueBook(in bookName):Boolean
Association
• Associations are needed to enable objects to communicate with each
other.

Class diagrams
• An association describes a connection between classes. A class can have an
association relationship with itself (called recursive association).The
association relation between two objects is called object connection or
link.
• Association between two classes is represented by drawing a straight line
between the concerned classes.

Class diagrams
Association
• The name of the association is written along side the association line. An
arrowhead may be placed on the association line to indicate the reading
direction of the association.
• On each side of the association relation, the multiplicity is noted as an
individual number or as a value range. The multiplicity indicates how many
instances of one class are associated with each other.
• An asterisk is a wild card and means many (zero or more). The below
association tells Many books may be borrowed by a Library Member.

Class diagrams
Aggregation
• Aggregation is a special type of association. It describes a part-of
relationship. It is a binary association, i.e., it only involves two classes.
• It is a kind of relationship in which the child is independent of its
parent.

• Aggregation is represented by the diamond symbol at the composite
end of a relationship.
• Aggregation relationship cannot be reflexive (i.e. recursive). That is,
an object cannot contain objects of the same class as itself.
• Also, the aggregation relation is not symmetric. That is, two classes A
and B cannot contain instances of each other. However, the
aggregation relationship can be transitive.

Class diagrams
• Consider car and wheel example. A car cannot move without a
wheel. But the wheel can be independently used with the bike,
scooter, cycle, or any other vehicle. Thus the wheel object can exist
without the car object, which proves to be an aggregation
relationship.

Class diagrams
Composition
• Composition is a stricter form of aggregation. It portrays the
wholepart relationship. It depicts dependency between a composite
(parent) and its parts (children).
• When the whole is created, the parts are created and when the
whole is destroyed, the parts are destroyed.
• The composition relationship is represented as a filled diamond
drawn at the composite-end.

Class diagrams
• Following is the composition association relationship which connects
the Person class with Brain class, Heart class, and Legs class. If the
person is destroyed, the brain, heart, and legs will also get discarded.

Comparision between Association vs.

Sequence Diagram
Aggregation vs. Composition

Association Agrégation
• Association • Aggregation
relationship is relationship is represented
using an represented by a
arrow. straight line with an
• In UML, it can exist
empty diamond at
between
two or more
one end.
classes. • It is a part of the
association
relationship.
Composition
• The composition
relationship is
represented by a
straight line with
a black diamond
at one end.
• It is a part of the
aggregation
relationship.

Sequence Diagram
Interaction Diagram
• Interaction diagrams are models that describe how group of objects
collaborate to realize some behavior.
• An interaction diagram shows a number of example objects and the
messages that are passed between the objects within the use case.
• There are two kinds of interaction diagrams:
• sequence diagrams
• collaboration diagrams.

• A sequence diagram shows interaction among objects as a two
dimensional chart. The chart is read from top to bottom.
• The objects participating in the interaction are shown at the top of
the chart as boxes attached to a vertical dashed line.
• Inside the box the name of the object is written with a colon
separating it from the name of the class and both the name of the
object and the class are underlined.
• The objects appearing at the top signify that the object already
existed when the use case execution was initiated.
• However, if some object is created during the execution of the use
case and participates in the interaction (e.g. a method call), then the

Sequence Diagram
object should be shown at the appropriate place on the diagram
where it is created.

Sequence Diagram
• The vertical dashed line is called the object’s lifeline. The lifeline
indicates the existence of the object at any particular point of time.
• The rectangle drawn on the lifetime is called the activation symbol
and indicates that the object is active as long as the rectangle
exists.
• Each message is indicated as an arrow between the lifeline of two
objects.
• Reading the message from the top to the bottom would show the
sequence in which the messages occur.

Sequence Diagram
• Each message is labeled with the message name. Some control
information can also be included.
• The sequence diagram shows behavioral aspects.
• Two types of control information are particularly valuable.
• A condition indicates that a message is sent, only if the condition is true.
• An iteration marker shows the message is sent many times to multiple receiver
objects as would happen when a collection or the elements of an array are
being iterated.

Collaboration Diagram
• A collaboration diagram shows both structural and behavioral aspects
explicitly.
• The structural aspect of a collaboration diagram consists of objects
and the links existing between them.
• In this diagram, an object is also called a collaborator. The behavioral
aspect is described by the set of messages exchanged among the
different collaborators.
• The link between objects is shown as a solid line and can be used to
send messages between two objects. The message is shown as a

labeled arrow placed near the link. Messages are prefixed with
sequence numbers because they are only way to describe the relative
sequencing of the messages in this diagram.

Activity diagrams
• The activity diagram focuses on representing activities or chunks of
processing which may or may not correspond to the methods of classes.
• An activity is a state with an internal action and one or more outgoing
transitions.
• If an activity has more than one outgoing transitions, then these must be
identified through conditions.
• An interesting feature of the activity diagrams is the swim lanes. Swim
lanes enable you to group activities based on who is performing them.

• Thus swim lanes subdivide activities based on the responsibilities of some
components. The activities in a swim lane can be assigned to some model
elements, e.g. classes or some component, etc.
• This is carried out during the initial stages of requirements analysis and
specification. Later these diagrams can be used to develop interaction
diagrams.

Activity Diagram for Renew Book

State chart diagram
• A state chart diagram is normally used to model how the state of an
object changes in its lifetime. State chart diagrams are good at
describing how the behavior of an object changes across several use
case executions.
• State chart diagrams are based on the finite state machine (FSM)
formalism.
• A state chart is a hierarchical model of a system and introduces the
concept of a composite state (also called nested state).

State chart diagram
• The basic elements of the state chart diagram are as follows: • Initial
state. This is represented as a filled circle. • Final state. This is
represented by a filled circle inside a larger circle. • State. These are
represented by rectangles with rounded corners. • Transition. A
transition is shown as an arrow between two states. Normally, the
name of the event which causes the transition is places along side the
arrow. A guard to the transition can also be assigned. A guard is a

Boolean logic condition. The transition can take place only if the
grade evaluates to true.
Software design
Detailed (or low-level) design
• Detailed design means design the data structure and the algorithms of
the different modules.
Items developed during the software design phase
• Different modules required to implement the design solution.
• Control relationship among the identified modules. The relationship is
also known as the call relationship or invocation relationship among
modules.

• Interface among different modules. The interface among different
modules identifies the exact data items exchanged among the modules.
• Data structures of the individual modules.
• Algorithms required to implement each individual module.
Software design
Characteristics of a good software design
• Correctness: A good design should correctly implement all the
functionalities identified in the SRS document.
• Understandability: A good design is easily understandable.
• Efficiency: It should be efficient.

• Maintainability: It should be easily amenable to change.

Reference
• Fundamentals of software engineering by Rajib Mall.

Software vjhghjjkhjkkkghhjhEngineering.pdf

Recommended

Recommended

More Related Content

Similar to Software vjhghjjkhjkkkghhjhEngineering.pdf

Similar to Software vjhghjjkhjkkkghhjhEngineering.pdf (20)

Recently uploaded

Recently uploaded (20)

Software vjhghjjkhjkkkghhjhEngineering.pdf