UNIT - I

DATA MODELS
M.Sc SOFTWARE SYSTEM
STRUCTURED SYSTEM ANALYSIS AND DESIGN
Introduction: Common types of systems - General systems
principles - People involved in systems development
project - The project lifecycle - Major issues in systems
analysis and development. Modeling tools: Characteristics
of modeling tools - Data Flow diagrams - The data
dictionary - Process specifications - Entity relationship
diagrams – State-transition diagrams - Balancing the
models - Additional modeling tools - Modeling tools for
project management.
Systems Analysis
It is a process of collecting and interpreting facts, identifying
the problems, and decomposition of a system into its
components.
System analysis is conducted for the purpose of studying a
system or its parts in order to identify its objectives. It is a
problem solving technique that improves the system and
ensures that all the components of the system work efficiently
to accomplish their purpose.
Analysis specifies what the system should do.
Systems Design
It is a process of planning a new business system or replacing an
existing system by defining its components or modules to satisfy the
specific requirements. Before planning, you need to understand the old
system thoroughly and determine how computers can best be used in
order to operate efficiently.

System Design focuses on how to accomplish the objective of the

system.

System Analysis and Design (SAD) mainly focuses on −

Systems
Processes
Technology
What is a System?
The word System is derived from Greek word Systema, which means an organized
relationship between any set of components to achieve some common cause or
objective.

A system is “an orderly grouping of interdependent components linked together

according to a plan to achieve a specific goal.”

Constraints of a System
A system must have three basic constraints −

A system must have some structure and behavior which is designed to achieve a
predefined objective.
Interconnectivity and interdependence must exist among the system
components.
The objectives of the organization have a higher priority than the objectives of
its subsystems.
Properties of a System
A system has the following properties −

Organization
Organization implies structure and order. It is the arrangement of
components that helps to achieve predetermined objectives.

Interaction
It is defined by the manner in which the components operate with each
other.

For example, in an organization, purchasing department must interact

with production department and payroll with personnel department.
Interdependence
Interdependence means how the components of a system depend on one another.
For proper functioning, the components are coordinated and linked together
according to a specified plan. The output of one subsystem is the required by
other subsystem as input.

Integration
Integration is concerned with how a system components are connected together.
It means that the parts of the system work together within the system even if
each part performs a unique function.

Central Objective
The objective of system must be central. It may be real or stated. It is not
uncommon for an organization to state an objective and operate to achieve
another.
Elements of a System
The following diagram shows the elements of a system −
Outputs and Inputs
The main aim of a system is to produce an
output which is useful for its user.
Inputs are the information that enters into
the system for processing.
Output is the outcome of processing.
Processor(s)
The processor is the element of a system that
involves the actual transformation of input into
output.
It is the operational component of a system.
Processors may modify the input either totally or
partially, depending on the output specification.
As the output specifications change, so does the
processing. In some cases, input is also modified to
enable the processor for handling the
transformation.
Control
The control element guides the system.
It is the decision–making subsystem that controls
the pattern of activities governing input,
processing, and output.
The behavior of a computer System is controlled
by the Operating System and software. In order
to keep system in balance, what and how much
input is needed is determined by Output
Specifications.
Feedback
Feedback provides the control in a dynamic
system.
Positive feedback is routine in nature that
encourages the performance of the system.
Negative feedback is informational in nature
that provides the controller with information
for action.
Environment
The environment is the “supersystem” within which
an organization operates.
It is the source of external elements that strike on
the system.
It determines how a system must function. For
example, vendors and competitors of
organization’s environment, may provide
constraints that affect the actual performance of
the business.
Boundaries and Interface
A system should be defined by its boundaries.
Boundaries are the limits that identify its
components, processes, and interrelationship when it
interfaces with another system.
Each system has boundaries that determine its sphere
of influence and control.
The knowledge of the boundaries of a given system is
crucial in determining the nature of its interface with
other systems for successful design.
INTRODUCTION:

A system is an organized relationship among functional units or components.

A system is designed to achieve a specific objective. Thus “a system is an
orderly grouping of interdependent components linked together according to
a plan to achieve a specific objective”. Components may be simple or complex,
basic or advanced.
Example:

A Computer is a System .The Components making up the computer are the

CPU, an output device, an input device and one or more storage units. When the
individual components are linked together they form the system as a whole.
TYPES OF SYSTEM:
There are mainly three types of system.
1. Physical or abstract
2. Open or closed
3. Man made information system
PHYSICAL OR ABSTRACT SYSTEM:

Physical systems are tangible entities that may be static or

dynamic. The physical parts of the computer center are the offices, desks
and chairs that facilitate the operation of the computer. Since they can be
seen and counted, they are static. A programmed computer is a dynamic
system.

Examples:

Data, programs, output are examples for dynamic system.

Abstract systems are conceptual or nonphysical entities.

Examples:

Formulas of relationships among sets of variables, a model etc are

examples of abstract systems. A model is a representation of reality.
SYSTEM MODELS:

Model is a representation of a real or a planned system. The work of an

analyst begins by first deciding upon the model. The models are used to simplify a
complex system into a more abstract one. The major system models are
1. Schematic models

2. Flow system models

3. Static system models

4. Dynamic system models

Schematic Models:
A schematic model is two dimensional chart depicting system
elements and their linkages. The following figure shows the
information flow between the Payroll and the Human Resources
Department.

Figure – 4. Information flow between the Payroll

Department and the Human Resources Department
Flow System Models:
A flow system model shows the flow of the material, energy and information
that hold the system together. (I.e.) it specifies the flow of logic in models.
Example:
A widely used example is PERT (Program Evaluation and Review Technique).
Consider the following

PERT uses arrows and circles to create a model in the form of a network.
Arrows represent tasks and circles represent events. A letter is placed above each
arrow denoting the activity and the time taken to complete the task. The critical
path (shown as dark lines) is the longest path through the network. So path 1
takes 36 days which makes path 1 the critical path. Thus PERT is used to abstract
a real world system in model form, manipulate specific values to determine the
critical path, interpret the relationships and relay them back as a control.
4.1.1.3. Static System Models:

This type of model exhibits one pair of relationships

such as activity-time or cost-quantity.
 The example above shows the activities on the
horizontal axis and the time on the vertical axis.
The diamond ( ) indicates the time frame within
which the event or activity has to complete. The
black diamond ( ) indicates the actual completion
date. Thus the completion of each activity within a
stipulated time is shown with the help of a Gantt
chart.
Dynamic System Models:

Dynamic systems are constantly changing systems.

Example:
Business organizations are dynamic systems. A dynamic
model approximates the type of organization or applications
that analysts deal with. It requires inputs, processors, and
programs to produce the desired output.
Open or Closed Systems
An open system must interact with its environment. It receives
inputs from and delivers outputs to the outside of the system.
For example, an information system which must adapt to the
changing environmental conditions.

A closed system does not interact with its environment. It is

isolated from environmental influences. A completely closed
system is rare in reality.
Adaptive and Non Adaptive System
Adaptive System responds to the change in the
environment in a way to improve their performance
and to survive. For example, human beings,
animals.
Non Adaptive System is the system which does not
respond to the environment. For example,
machines.
Permanent or Temporary System
Permanent System persists for long time. For example,
business policies.

Temporary System is made for specified time and after that

they are demolished.

For example, A DJ system is set up for a program and it is

dissembled after the program.
Natural and Manufactured System
Natural systems are created by the nature. For
example, Solar system, seasonal system.
Manufactured System is the man-made system. For
example, Rockets, dams, trains.
Deterministic or Probabilistic System
Deterministic system operates in a predictable manner and the
interaction between system components is known with
certainty. For example, two molecules of hydrogen and one
molecule of oxygen makes water.
Probabilistic System shows uncertain behavior. The exact output
is not known. For example, Weather forecasting, mail delivery.
Social, Human-Machine, Machine System
Social System is made up of people. For example, social
clubs, societies.

In Human-Machine System, both human and machines

are involved to perform a particular task. For example,
Computer programming.

Machine System is where human interference is

neglected. All the tasks are performed by the machine.
For example, an autonomous robot.
Man–Made Information Systems
It is an interconnected set of information resources to manage data for particular
organization, under Direct Management Control (DMC).
This system includes hardware, software, communication, data, and application
for producing information according to the need of an organization.
Man-made information systems are divided into three types −
Formal Information System − It is based on the flow of information in the
form of memos, instructions, etc., from top level to lower levels of
management.
Informal Information System − This is employee based system which solves
the day to day work related problems.
Computer Based System − This system is directly dependent on the computer
for managing business applications. For example, automatic library system,
railway reservation system, banking system, etc.
4.3.1. FORMAL INFORMATION SYSTEM:

A formal information system is based on the organization represented by the

organization chart. The chart is a map of positions and their authority relationships, indicated by
boxes and connected by straight lines. It is concerned with the pattern of authority,
communucation and workflow. Informations are formally disseminated in instructions, memos or
reports from top management to the intended user in the organization. This structure also allows
feedback up the chain for follow-up.

4.3.1.1. Categories of Information:

There are three categories of information related to managerial levels

1.strategic information system

2.managerial information system

3.operational information system

Strategic information system:

Strategic information relates to long range planning polices. These are of

direct interest of the upper management. Population growth, trends in
financial investment, changes in human resources etc are of interest to the
top officials who are responsible for setting up he company goals. This type
of information is obtained with the help of the decision – support systems
(DSS). DSS is obtained by adding Decision making capabilities to
Management Information System (MIS). DSS results from adding external
data sources, accounting, statistical models and interactive query
capabilities. The outcome is a system that serves all levels of management
to solve unstructured problem situations.
Managerial information system:

Managerial Information relates to short and intermediate range

planning polices. This is important to middle management and
department heads for implementation and control. Sales analysis,
annual financial statements etc are examples of the managerial
information. This type of information is maintained with the help of
Management Information Systems (MIS). MIS is a person –
machine system and a highly integrated grouping of information
processing functions designed to provide management with a clear
picture of specific operations.
Operational information system:

Operational information relates to short term polices. This deals

with day-to-day activities like daily employee absence sheets,
purchase orders, current stock available for sale. This type of
information is established by the Data Processing Systems (DPS).
4.3.1.2. Categories of decision – making:

Based on the nature of information and the managerial

levels Decision making is divided into the following types.
Structured decision making:

An Organizational process that is closed, stable and mechanistic is

structured because it relies on routine decision making for planning
and control. Such types of Decision-making are related to the lower
level management and are supported by a computer system.

Unstructured decision making:

All processes that are open, dynamic, are examples of

unstructured decision making because they lack a proper
structure in the decision – making process which makes it
difficult to secure a computer support.
Management level Information level

UPPER Strategic Planning

information

MIDDLE Management control

information

LOWER Operational information

Figure – 8. Managerial and Information levels in an

Organization.
4.3.2. INFORMAL INFORMATION SYSTEM:

It is an employee based system designed to meet personal and

vocational needs and to help and solve work related problems. It also
funnels information upward through indirect channels. It is a useful
system because it works within the framework of the business and its
stated policies. An analyst should have a complete knowledge about the
chain of authority, the power, authority and influence network and the
way in which decisions are made. Since the computers cannot provide a
proper detail on the staff cooperation, staff support etc, the analyst has
to maintain a proper communication with the informal systems.
4.3.3. COMPUTER BASED INFORMATION SYSTEM:

A third class of information system relies on the

computer for handling business applications. The computer is
now a required source of information. System analysis relies
heavily on computers for problem solving. This suggests that the
analyst must be familiar with computer technology and have
experience in handling people in an organization context. There
are two types of computer based information systems

⮚ MIS (Management Information System)

⮚ DSS (Decision Support System)
4.3.3.1. Management information system (MIS):

The computer has a significant impact on the techniques used by management

to operate a business. The level of the manager in the organization is also a factor in
determining the kind of information needed to solve a problem.
Lower level management needs detailed internal information to make day-to-
day, relatively structured control decisions. Higher-level management, for whom long-
range objectives are the primary concerns, requires summarized information from a
variety of sources to attain goals. In either case management action is based on
information that is accurate, relevant, complete, concise and timely. MIS has been
successful in meeting these information criteria quickly and responsively.

MIS is a person machine system and a highly integrated grouping of information

processing functions designed to provide management with a comprehensive picture of

specific operations.
Features of MIS:

1. It is a combination of information systems to do the job.

2. It should operate in real time
3. It should handle inquiries as quickly as they are received.
4. Management information must also be available early enough to affect a decision.
5. Operationally, MIS should provide for file definition, file maintenance and updating,
transaction and inquiry processing and one or more database linked to an organizational
database.
6. Within an MIS a single transaction can simultaneously update all related data files
in the system. This reduces data duplication.
A key element of MIS is the database. A database is a collection of interrelated data
items that can be processed through application programs and available to many users.
All records must be related in some way. Sharing common data means many programs
can use the same files or records. Information is accessed through a (DBMS) database
Advantages of a database system:

1. Processing time and the number of programs

written are reduced.
2. All applications share centralized data.
3. Storage space duplication is eliminated.
4. Data that is stored once in the database are
easily accessible when needed.
Disadvantages of a database system:

1. The cost of maintaining a database is more.

2. Sensitive data has to be protected from unauthorized users.
The primary users of MIS are middle and top management, operational
managers and support staff. Middle and top management use MIS for preparing
forecasts, special
requests for analysis,long range plans and periodic reports. Operational managers
use MIS primarily for short range planning and periodic and exception reports. The
support staff finds MIS useful for special analysis of information and reports to help
management in planning and control.
A major problem encountered in MIS design is obtaining the
acceptance and support of those who will interface with the system.
An MIS within an Organization.

INPUTS PROCESSING OUTPUT

4.3.3.2. Decision support system (DSS):
DSS advances the capabilities of MIS. It assists management in
decision- making. It is actually a continually evolving model that relies
heavily on operations research. DSS is defined as follows

Decision - Emphasizes decision making in problem situations, not

information processing, retrieval, or reporting.

Support - Requires computer-aided decision situations with enough

structure to permit computer support

System - Accentuates the integrated nature of problem solving,

suggesting a combined “man”, machine and decision environment
 There are people who view DSS as an extension of MIS, DSS as independent of
MIS, or MIS as a subset of DSS.The commonly accepted view is that DSS is a second
generation MIS. MIS is generated when we add predefined managerial reports
(consisting of transaction processing, report generation and online inquiry
capabilities) within a given functional area such as production MIS or personnel MIS.
DSS results from adding external data sources, accounting and statistical models and
interactive query capabilities. The outcome is a system designed to serve all levels of
management and top management It is a system with intrinsic capability to support
ad hoc data analysis as well as decision-modeling activities.

Herbert Simon describes decision making as a three-phase continuous

process starting with

Intelligence – This involves awareness of the problem at the basic level. A DSS can
provide intelligence through information retrieval and statistical data.
Design – This phase focuses on finding alternatives for a decision.
DSS plays a major role in decision design under uncertainty.

Choice – The output of the models is the basis for the choice
phase.
Figure – 10. Simon’s Decision –making Process
System development life cycle

A candidate system must undergo various stages to achieve its

perfection. Each stage in the process or cycle are interrelated.

The following are the main stages in the system development life
cycle:

● Recognition of needs
● Feasibility study
● Analysis
● Design
● Implementation
● Post Implementation
Recognition of needs

This is the initial step and in this step we come to

know what the problem is –An initial investigation is
conducted in order to obtain the problem definition. The
organization must ensure whether the problem is serious
enough. Then an analyst is employed who must produce the
statement of the problem definition and its scope.
Feasibility study: As per this the system developer must crystalise the problem definition. During this phase the following
questions must be answered

i) What are the initial means in the development of the system?

ii) Is the problem is worth solving?
iii) Will this meet the organizations master MIS plan?

Cost Benefit Analysis is roughly made after analyzing the above questions. After deriving the answers an initial document or report is
submitted to the organization which consist of –

1. Statement of the problem

2. Findings & Recommendations
3. Details of findings
4. Recommendation & Conclusions

Statement of the problem - A clear definition of the problem that is tobe met by the candidate system.

Findings & Recommendations – The analyst must analyze the problem and justify few recommendation which are needed during the
development phase.

Details of Findings – A clear picture of the problem that the previous system incurred and how this can be improved through the
candidate system.

Recommendations & Conclusions – A conclusion about the problem is stated whether there is scope for the problem. This is a crucial
Analysis

As per the study made during the previous stage data are collected. The
main question arises here is “How to solve the problem?”. We estimate
the boundaries for the system and its relationship with other system.
Activities under gone during this phase are data flow diagrams, onsite
observations, interviews etc. In this interviewing is the best method
during data collection but it needs high knowledge about the system
and a good skill. Next he proceeds to the physical parts of the system
development stage. Till now all these stages considered about the
logical part only.
Design

Here begins the technical specification of the problem. A rough sketch

about the output designing is made and exact design about the system is
presented. The output designing is performed so that the output to be
present to the user. Corresponding input designing is done for his
specified/required output. Here unit testing is performed to initially check
the working of the system. A report should be submitted to the
management for approval. If the report is approved then it goes to the
next stage or else the project is terminated here.

The following is the flow diagram of the design phase.

Implementation

The major things that are done during this phase are –

1. User training
2. File/System Conversion

User training is a must in this phase. Here the user is trained about the
processing of the system.

File/System Conversion is an important task during this phase. Initially

the parallel processing is performed with the old system. Then ‘Live‘ are
fed and comparative analysis is made.

User friendly documentation is made during this phase

Post implementation

The three major things to be considered are

● Evaluations
● Maintenance
● Enhancement

Evaluation is done after the development of the system in future. If

any changes occurs in the system then the system must be flexible
to the changes made newly.
Players in system game:

There are 7 users in the system games:-

- user

- management

- auditors, quality assurance people and "standard bearers"

- system analysts

- system designers

- programmers

- operations personnel
There are several types of users who are categoriesed according to
the

job category

- operational users

- supervisor users and

- executive users
operational users:
# These users are fully concerned with the functions that the system

will perform. they are fully concerned about the interface issues only.

# These users tend to have the "local view" of the system.

# they tend to think of systems in very physical terms.

for example, How will the system intimate him when he has
commited a

mistake.
supervisory user : # They usually manage a group of operational users and they are
responsible for the performance of the system.

# they are fully oriented with reducing the processing time of the transactions
and reducing the errors in the work.

# they are the persons who emphasis on the operational effeciency.

# it is usuall the supervisors who think about introducing the candidate system,
so as to reduce the number of operational users

# these users are the person who often act as a middlemen between the system
analyst and the operational user.

Executive users :

# these users are directly involved with the system development projects.

# these users are mostly interested in the global view of the entire system, so
they are not interested in the in-depth of the operations that are carried out.
Management :

~~~~~~~~~~~~

there are three different kinds of managers, namely;

- user manager,

- EDP/MIS manager and

- General manager.
user manager :---------------

Managers are in charge of several personnel in the

operation areas.

Usually they are middle-level managers. they just generate the different kinds of
reports whenever necessary.

EDP/MIS manager :-----------------

these are the person who are in charge of the system development
project itself. they are concerned with the overall management and the
resource allocation to the technical staff.
General manager :

-----------------

They are the top level administrators of the organization, they are not

concerned about the technical aspects of the system. they just provide the

options as ordered by the lower levels of management.

auditors, quality assurence people and "standard bearers" :

# depending upon the size and activities, the organisation can have either

its own auditors(eg: Internal audit Dept) or outside professionals for the purpose

of controlling.

# likewise in order to have a better quality, the quality assurence

people and standard bearers are also employed.

# these group plays an important

role of checkpoint and authority on the affairs of an organisation

system analysts :

~~~~~~~~~~~~~~~~~

# they are the key members of any system development project.

5.THE SYSTEM DEVELOPMENT LIFE CYCLE :
System development life cycle is also referred as system study. The
system analyst gives a system development project meaning and direction. A
candidate system is approached after the analyst has a thorough understanding of
user needs and problems.

System development life cycle has 6 phases. They are

1. Recognition of need

2. Feasibility study

3. Analysis

4. Design

5. Implementation

6. Post-implementation and maintenance

5.1. RECOGNITION OF NEED:

One must know what the problem is before it can be solved. The basis for a candidate system is recognizing the need for
improving an information system or a procedure.
Example :
A supervisor may want to investigate the system flow in purchasing. This need leads to a preliminary survey or an initial
investigation to determine whether alternative systems can solve the problems. It starts by looking into the duplication of efforts,
bottleneck, inefficient existing procedures or whether parts of the existing system would be candidates for computerization.
The idea for change occurs in he environment or in the firm. Environmental – based ideas originate from customers,
vendors, government sources etc. Ideas for change also come from the top management, the user, the analyst. An organization needs to
update existing procedures in the following cases
❖ An organization acquires another organization
❖ A local branch branches into the suburbs.
❖ Unauthorized access.
❖ For combining two or more departments doing the same work.
Also serious problems in operations, a high rate of labor turnover, labor intensive activities, and high reject rates of finished goods also
prompt the management to initiate an investigation and a change.
5.2. FEASIBILITY STUDY:

Depending on the results of the initial investigations the survey is expanded to feasibility study. Feasibility study is
defined as a test to a proposed system according to its workability, impact on the organization, ability to meet user needs and
effective use of resources. The objective of a feasibility study is not to solve the problem but to acquire a sense of its scope. During
this study, the problem definition is crystallized and aspects of the problem to be included in the system are determined.
The result of the feasibility study is a formal proposal. This is like a report. This report summarizes what is known and
what is going to be done. It consists of the following.
1. Statement of the problem - A carefully worded statement of the problem that led to

analysis.

2. Summary of findings and recommendations - A list of the major findings and

recommendations of the study

1. Details of findings - An outline of the methods and procedures undertaken by the

existing system, followed by the objectives and procedures of the candidate system.
 2. Recommendations and conclusions - Specific recommendations
regarding the

candidate system, including personnel assignments, costs,

project schedules and target dates.

Then the management reviews this report. After the proposal is

reviewed, it becomes a formal agreement that paves the way for actual
design and implementation. This is a very important stage in system life
cycle. Many projects die here, whereas the more promising ones
continue to go on. Changes in the proposal are made in writing,
depending on the size, complexity and the cost of the project.
5.3. ANALYSIS:

Analysis is a detailed study of the various operations performed by a system and their
relationships within and outside the system. The key question in carrying out the analysis is
“what must be done to solve the problem?” One aspect of analysis is defining the boundaries
of the system and determining whether or not a candidate system should consider other related
systems. During analysis data are collected on the available files, decision points and transactions
handled by the present system. Data flow diagrams, interviews, on site observations and
questionnaires are some tools that are used in analysis.

Analysis requires special skills and sensitivity to the subjects being interviewed. Bias in data
collection and interpretation can be a problem. Training, experience and common sense are
required for the collection of the information to carry out he analysis.

Once all the details are collected, the analyst has an idea of what has to be done. With this idea in
mind, he proceeds on to the next step – the design phase.
5.4. DESIGN:

The system design phase is one where we move from the logical to the physical aspects of the
problem stated. This is the phase where the problem is actually solved and hence is the most creative and
challenging phase of system life cycle. The term design describes a final system and the process by which it
is developed. It refers to the technical specifications that will be applied in implementing the candidate
system. It also includes the construction of programs and program testing. The key question in carrying out
the design process is “how should the problem be solved?”.

There are four steps in design phase. They are

Output design - This step determines how the output is to be produced and the format of the required output.

Input design - In this step the inputs and the format of the inputs are designed.

File design - In this step the master file, transaction files have to be designed.

Processing design - This is also called Operational Phase. In this step the

program construction and testing is performed.

Finally details related to justification of the system and an estimate of the impact of the Candidate
5.5. IMPLEMENTATION:

The implementation phase is less creative than system design. It is primarily

concerned with the user training, site preparation and file conversion. Implementation includes
the following testing
♦ When a candidate system is linked to a network, the tests of the network are done as
part of the implementation.
♦ User acceptance is done followed by user training. Depending on the nature of the
system extensive user training may be required. Conversion usually takes place at about the
same time the user is being trained or later.
♦ System testing checks the readiness and accuracy of the system to access, update
and retrieve data from new files. Once the programs become available test data are read into
the computer and processed against the files provided for testing. If successful the programs
is then run with live data. Otherwise a diagnostic procedure is used to locate and correct
errors in the program.
♦ Sometimes a parallel run is conducted where the new system is made to run along
5.6. POST IMPLEMENTATION AND MAINTENANCE:

Like any system there is an aging process that requires periodic

maintenance of hardware and software. If the new information is inconsistent
with the design specification, then changes have to be made. Hardware also
requires periodic maintenance to keep into with the design specification. The
importance of maintenance is to continue to bring new systems to standards.

User priorities, organizational requirements, environmental factors

call for system enhancements. This change requires evaluation, program
modifications and testing to meet the needs of the user or the organization.
5.7. REASONS FOR FAILURE OF A SYSTEM:

A project is generally dropped after the review process if

❑ The objectives are constantly changing.

❑ The requirements of the user cannot be met.
❑ Sudden increase in user’s budget.
❑ Increase in design costs.
❑ The project exceeds the time and cost schedule.

A newly developed system fails due to the following reasons

❑ User requirements are not properly understood.

❑ No user participation in the important phases of system development.
❑ Inexperienced analysts and programmers.
❑ Insufficient time.
❑ Poor user training.
❑ Defective hardware.
Modeling tools :

Models : (An Introduction)

Model is an inexpensive facsimile of a complex system. The models are being

built for 3 reasons

⮚ To focus on important system features while downplaying less

important features.
⮚ To discuss changes and corrections to the users requirements at
a low cost and with minimal risks.
⮚ To verify that we understand the users environment and have
documented it in a such a way that systems designers and
programmers can build the system.
Any modeling tools must have the following characteristics:

⮚ It should be graphical, with appropriate supporting textual

detail.
⮚ It should allow the system to be viewed in a top-down,
partitioned system
⮚ It should have minimal redundancy.
⮚ It should help the reader predict the systems behavior.
⮚ It should be transparent to the reader.
GRAPHICAL MODELS

“A picture is worth a thousand words”. A well chosen picture can

convey an enormous amount of information concisely and
compactly.

⮚ Graphics are being used to identify the components of a system

and the interfaces between the components.
⮚ The documents that support textual documents are the process
specification & data dictionary.
⮚ Graphics is the primary document that the user turns to in order
to understand tha system.
⮚ The textual documents serve as a reference material to be
TOP DOWN PARTITIONING :

The aspect of a good modeling tool is its ability to portray a

system in a top-down partitioned fashion.

It will be impossible for anyone to focus on the entire system at

once. The modeling tools allow to portray individual parts of the
system in a stand-alone fashion, together with a straight forward way
of getting from one part of the system model to another.

A good model of a complex information system should proceed in

the same top-down fashion a high-level portion of the model gives the
reader a good idea of the major high-level components.

The subsequent portions of the model should provide information

about low-level detail components of the system.
MINIMALLY REDUNDANT MODELS :

Models are a representation of some real world systems, and the system itself
may be static or dynamic.

If the system changes, then the model most be changed. It multiple changes are
required, then the model becomes less accurate.

TRANSPARENT MODELS :

A good model should be very much easy to read. This takes some education
and practice.

If we are trying to model something that is linear, we must use a textual modeling tool.

If the model is multidimensional, we must use a graphical modeling tool.

DATA FLOW DIAGRAMS:

A data flow diagram is a modeling tool that allow us to picture a

system as a network of functional processes,connected to one another by
“pipelines” and “holding tanks” of data.

Another names for data flow diagrams are

● Bubble chart
● DFD
● Bubble diagram
● Process model
● Work flow diagram
● Function model
● “A picture of what’s going on around here”
-The data flow diagram is one of the most commonly used
system-modelling tools,particularly for operational sytem in
which the functions of the system are of paramount importance
& more complex than the data that the system manipulates.

-DFDs were 1st used in the software engineering field as a

notation for studying system design issues.

-DFDs cannot only be used to model information processing

systems,but also as a way of modeling whole organizations,that
is as a tool for business planning and strategic planning.

-It provides only one view of the system-the function oriented

view.
Components of a DFD

● The process
● The flow
● The store
● The terminator
Data flow diagrams can be used to provide a clear
representation of any business function. The technique starts
with an overall picture of the business and continues by
analyzing each of the functional areas of interest. This analysis
can be carried out to precisely the level of detail required. The
technique exploits a method called top-down expansion to
conduct the analysis in a targeted way.
 FIVE SYMBOLS

1. ENTITY
2. Data Flow
3. PROCESS
4. DATA STORE
5. 5.RESOURCE FLOW
Data flow Diagrams – Diagram Notation
There are only five symbols that are used in the drawing of
business process diagrams (data flow diagrams). These are now
explained, together with the rules that apply to them.

This diagram represents a banking process, which maintains

customer accounts. In this example, customers can withdraw or
deposit cash, request information about their account or update their
account details. The five different symbols used in this example
represent the full set of symbols required to draw any business
process diagram.
Data Flow Diagrams – The Rules Dramles

DATA FLOW DIAGRAMS - CONTEXT DIAGRAMS

Data Flow Diagrams –level1 Diagrams
DataFlowDiagrams–Numbering rules
Data Flow Diagrams - When to Stop
It is important to know when to stop the process of top-down
expansion. Usually this will be at level 2 or level 3.
There are 3 useful guidelines to help you to decide when to stop the analysis:
Firstly, if a process has a single input data flow or a single output data flow
then it should be apparent that there is little point in analyzing it any further.
Secondly, when a process can be accurately described by a single active verb
with a singular object, this also indicates that the analysis has been carried out
to a sufficiently low level. For example, the process named validate enquiry
contains a single discrete task.
Finally, ask yourself if anything useful will be gained by further analysis of a
process. Would any more detail influence your decisions?
If the answer is no, then there is little point in taking the analysis further.
DATA DICTIONARY

The phrase data dictionary is almost self-defining.The data dictionary is an

organized listing of all the data elements that are pertinent to the system,with
pecise,rigorons definitions so that both user & system analyst will have a
common understanding of all inputs,components of stores & intermediate
calculations.The data dictionary defines the data elements by doing the following..

- Describing the meaning of the flows & stores shown in the data flow
diagrams.
- Describing the composition of aggregate packets of data moving along
the flows,that is complex packets that can be broken into more
elementary items.
- Describing the composition of packets of data in stores.
- Specifying the relevant values & units of elementary chunks of
- Describing the details of relationships between stores that are
highlighted in an entity-relationship diagram
- The second major component of the structured analysis model
of the system is the data dictionary. The data dictionary
contains formal definitions of all the data items shown in the
data-flow diagrams. If you didn't create data flow diagrams in
your analysis, then in general, every data item in your solution
must be included in the data dictionary. If you wrote Use Cases,
then every noun that isn't an Actor is a data item or attribute.
It is used to provide precise detail concerning the data entities.
Importantly the dictionary items are defined as they are found
in the problem domain, not in the implementation or solution
- The data dictionary has two different kinds of items: composite data and
elemental data.
Higher-level (composite) elements may be defined in terms of lower-level
items. Elemental data are items that cannot be reduced any further and are
defined in terms of the values that it can assume or some other
unambiguous base type.
- The general format of a data dictionary is similar to a standard dictionary;
it contains an alphabetically ordered list of entries. Each entry consists of a
formal definition and verbal description. The verbal description is simply a
sentence or two in English describing the data element. The formal
description provides a more precise definition using a mathematical sort of
notation.
 COMPOSITE DATA
- Composite data can be constructed in three ways:
sequence, repetition, or selection of other data types.

sequence + A plus sign indicates one element is followed by or

: concatenated with another element.
repetitio [ ] Square brackets are used to enclose one or more optional
n: elements.
|
A vertical line stands for "or" and is used to indicate
alternatives.
sequence: + A plus sign indicates one element is followed by or concatenated with
another element.

repetition: [ ] Square brackets are used to enclose one or more optional elements.

A vertical line stands for "or" and is used to indicate alternatives.

|

selection: {} Curly braces indicate that the element being defined is made up of a
series of repetitions of the element(s) enclosed in the brackets.

{}y The upper limit on the number of allowable repetitions can be indicated
by including an integer superscript on the right bracket. Here y
represents an integer and indicates that the number of repetitions
cannot be greater than y.
Examples
- sequence:
- Mailing-address = name + address + city +
zip-code
* The address at which the customer can
receive mail *

repetition:
- Completed-order = [ item-ordered ]
* A complete customer order *
 - selection:
Atm-transaction = { deposit |
withdrawal }
* An customer transaction at an
automated teller machine *
- In these examples asterisks are used to
delimit the comment or verbal
description of the item, but other
notations can be used as well.
 ELEMENTAL DATA
- Elemental data is described in terms of a data type or by listing
the values that the item can assume.
desired-temperature = floating point
*Desired-temperature is the value the user sets for desired
water temperature in the pool. It is a floating point number in the
range from 0.0 to 100.0, inclusive. The units are Celsius.*
- age = non-negative integer
*Age is how old the customer is in years. Age is a whole
number greater than or equal to zero.*
- performances-attended = counter
* Performances-attended is the number of performances this
customer has attended. Note: Since the person doesn't get entered
into the mailing list until they have attended a show this value can
never be zero. *
- counter = positive integer
*Counter is a whole number greater than zero that can only be
incremented by one and never decremented.*
- Furthermore, details concerning input or output formats can be specified
in the data dictionary. Suppose the subscription system will print a monthly report
of new subscribers. In the data-flow diagram, one activity is shown that produces
a data element as output, New-Subscribers-Report. In the data dictionary, the
format of the report could be defined as follows:
- New-Subscribers-Report = report-header + new-subscriber-list + report-
summary
- report-header = report-title + current-date
- report-title = 'Monthly Report of New Subscribers'
- new-subscriber-list = [ subscriber-name + subscriber-address ]
- report-summary = 'The total number of new subscribers:' + Number-of-
new-subscribers
- Any non-terminal terms used in these definitions must be defined
elsewhere in the data dictionary. Single quote marks are used to surround and
PROCESS SPECIFICATION:

- The description of what’s happening inside each bottom-

level,poimitive bubble in a data flow diagram.
- Minispec(miniature specification) alternative for process
specification.
- It defines what must be done in order to transform inputs into
outputs.It is a detailed description of the user’s business policy that each
bubbles carries out.

Tools for process specification:

- Structured English
- Decision tables
- Pre/Post conditions
STRUCTURED ENGLISH

Structured English, as the name implies, is “English with structure.” It is

also known by such names as PDL (for program design language) and PSL
(for problem statement language or problem specification language). Its
purpose is to strike a reasonable balance between the precision of a
formal programming language and the casual informality and readability
of the English language.

A sentence in structured English may consist of an algebraic equation, for

example
X = (Y*Z)/(Q+14)
COMPUTE X = (Y*Z)/(Q+14)
GET (or ACCEPT or READ)
PUT (or DISPLAY or WRITE)
FIND (or SEARCH or LOCATE)
ADD
SUBTRACT
MULTIPLY
DIVIDE
COMPUTE
DELETE
FIND
VALIDATE
MOVE
REPLACE
SET
SORT
▪ The IF-THEN-ELSE construct is used to describe alternative sentences that are to be
carried out based on the result of a binary decision. The IF-THEN-ELSE construct can take either of
the following two forms:
IF condition-1

sentence-1
ENDIF
or
IF condition-1

sentence-1
ELSE

sentence-2
ENDIF

The CASE construct is used to describe alternative sentences to be carried out based on the results
of a multivalued decision (as compared to the binary decision that takes place with an IF-THEN
DO CASE
CASE variable = value-1
sentence-1
CASE variable = value-n
sentence-n
OTHERWISE
sentence-n+1
ENDCASE
DECISION TABLES:

There are situations where neither structured English nor pre/post conditions are
appropriate for writing process specifications. This is particularly true if the
process must produce some output or take some actions based on complex
decisions

the following steps to create a decision table for a process specification:

1. Identify all the conditions, or variables, in the specification. Identify all the
values that each variable can take on.
2. Calculate the number of combinations of conditions. If all the conditions are
binary, then there are 2N combinations of N variables.
3. Identify each possible action that is called for in the specification.
4. Create an “empty” decision table by listing all the conditions
and actions along the left side and numbering the combinations of
conditions along the top of the table.
5. List all the combinations of conditions, one for each vertical
column in the table.
6. Examine each vertical column (known as a rule) and identify
the appropriate action(s) to be taken.
7. Identify any omissions, contradictions, or ambiguities in the
specification (e.g., rules in the decision table for which the
specification does not indicate that actions should be taken).
8. Discuss the omissions, contradictions, and ambiguities with
the user.
OTHER PROCESS SPECIFICATION TOOLS

Graphs and Charts

Figure 11.8: Insurance premium as a function of age

Narrative English

Narrative English is not a recommended tool for writing process specifications.

This is because:

An unrestricted vocabulary (i.e., indiscriminate use of nouns, verbs, and adjectives) makes
it likely that the process description will include terms that are not in the data dictionary
and whose meaning is not clear.

Alternative actions (i.e., decisions) are often expressed in a clumsy, ambiguous fashion.
This becomes even more dangerous when nested decisions are expressed.

Repetitive actions (i.e., loops) are also expressed in a clumsy, ambiguous fashion. Nested
loops are extremely dangerous when expressed in colloquial English.

The concept of block structures can only be expressed with indentation or an outline-style
presentation; if one is willing to go this far, one might as well use the formal structured
English notation.
Flow chart - An unstructured flowchart; source
Nassi-Shneiderman Diagrams

When structured programming first became popular in the mid-1970s, Nassi-

Shneiderman diagrams were introduced as a structured flowcharting technique;

- simple imperative statement is represented by a rectangle

- The binary IF-THEN-ELSE construct is represented by the graphic notation
shown in Figure 11.12(b); and the repetitive DO-WHILE construct is represented by
the graphic notation
-
Representation of an IF-THEN-ELSE construct
 Representation of an IF-THEN-ELSE construct

Representation of a DO-WHILE
construct
PRE/POST CONDITIONS

Pre/post conditions is a convenient way of describing the function that must be

carried out by a process, without saying very much at all about the algorithm or
procedure

Preconditions describe all the things (if any) that must be true before the process
begins operating. It’s sometimes convenient to think of the process as a “sleeping
princess,” and the pre-conditions represent the “magic kiss” that will awaken the
process and set it to work. Alternatively, you can think of the preconditions as a
guarantee from the user:

preconditions will describe the following:

- What inputs must be available.

- What relationships must exist between inputs or within inputs.
- What relationships must exist between inputs and data stores.
- What relationships must exist between different stores or
within a single store.

postconditions describe what must be true when the process has finished
doing its job.

Postconditions typically describe the following:

- The outputs that will be generated or produced by the process.

- The relationships that will exist between output values and the
original input values.
- The relationships that will exist between output values and
values in one or more stores.
- The changes that will have been made to stores: new items
added, existing items modified, or existing items deleted.
Entity-Relationship Diagram

Definition: An entity-relationship (ER) diagram is a specialized

graphic that illustrates the interrelationships between entities in a
database. ER diagrams often use symbols to represent three
different types of information. Boxes are commonly used to
represent entities. Diamonds are normally used to represent
relationships and ovals are used to represent attributes.

Also Known As: ER Diagram, E-R Diagram, entity-relationship

model
Examples:

Consider the example of a database that contains information on the residents of

a city. The ER digram shown in the image above contains two entities -- people
and cities. There is a single "Lives In" relationship. In our example, due to space
constraints, there is only one attribute associated with each entity. People have
names and cities have populations.
STEPs / how do we start ERD

1. Define Entities: these are usually nouns used in descriptions of the

system, in the discussion of business rules, or in documentation;
identified in the narrative (see highlighted items above).

2. Define Relationships: these are usually verbs used in descriptions of

the system or in discussion of the business rules (entity ______ entity);
identified in the narrative (see highlighted items above).

3. Add attributes to the relations; these are determined by the

queries,and may also suggest new entities, e.g. grade; or they may
suggest the need for keys or identifiers.
4. Add cardinality to the relations
Many-to-Many must be resolved to two one-to-manys with an
additional entity
Usually automatically happens
Sometimes involves introduction of a link entity (which will be all
foreign key) Examples: Patient-Drug
5. This flexibility allows us to consider a variety of questions such as:
a. Which beds are free?
b. Which assistants work for Dr. X?
c. What is the least expensive prescription?
d. How many doctors are there in the hospital?
e. Which patients are family related?
6. Represent that information with symbols.
Generally E-R Diagrams require the use of the
following symbols:
Entity-Relationship Diagrams (ERD)

Data models are tools used in analysis to describe the data

requirements and assumptions in the system from a top-down
perspective. They also set the stage for the design of databases later on
in the SDLC.
There are three basic elements in ER models:
Entities are the "things" about which we seek information.
Attributes are the data we collect about the entities.
Relationships provide the structure needed to draw
information from multiple entities.
Generally,ERD's look like this:
Developing an ERD

Developing an ERD requires an understanding of the system and its

components. Before discussing the procedure, let's look at a narrative created by
Professor Harman.

Consider a hospital:
Patients are treated in a single ward by the doctors assigned to
them. Usually each patient will be assigned a single doctor, but in rare
cases they will have two.
Heathcare assistants also attend to the patients, a number of these are
associated with each ward.
 Initially the system will be concerned solely with drug
treatment. Each patient is required to take a variety of drugs a
certain number of times per day and for varying lengths of time.
The system must record details concerning patient treatment
and staff payment. Some staff are paid part time and doctors and
care assistants work varying amounts of overtime at varying rates
(subject to grade).
The system will also need to track what treatments are
required for which patients and when and it should be capable of
calculating the cost of treatment per week for each patient
(though it is currently unclear to what use this information will be
put).
State Transition Diagrams (STD's)

An STD is a way of describing the time-dependent behaviour of a

system. The basic consistency rule is: "A system's behaviour in any
state must be the same no matter by which path the state is arrived
at".

States:

● A state is an observable mode of behaviour of the system.

● At any time a particular STD can only be in one state.
● .. but a system's behaviour could be described by more than one
Transition conditions:● internal events or events external to the system

Transition actions:

● actions in response to the events

● triggering one-shot actions

● synchronizing between different STD's
● producing control outputs

Drawing STD's:

● Identify observable states of the system

● Select the states with normal behaviour
● Specify the conditions that mark a transition
● Specify the actions to produce the observable behaviour in the destination state for
Hotel Reservation State Transition Diagram
BALANCING MODEL

1. How to balance a DFD against the data dictionary;

2. How to balance a DFD against a process specification;
3. How to balance a process specification against the data
dictionary;
4. How to balance an ERD against the DFD and process
specification;
5. How to balance an ERD against the data dictionary; and
6. How to balance a DFD against the state-transition diagram.
Balancing the DFD against the DD

The rules for balancing the dataflow diagram against the data dictionary are as
follows:

- Every dataflow (i.e., an arrow on the DFD) and every data store must be
defined in the data dictionary. If it is missing in the data dictionary, the
dataflow or data store is considered to be undefined.
- Conversely, every data element and every data store defined in the data
dictionary must appear someplace on a DFD. If it does not appear, the
offending data element or data store is a “ghost” -- something defined but not
“used” in the system. This can happen if the data elements are defined to
correspond with an early version of the DFD; the danger is that the DFD may
be changed (i.e., a dataflow or data store may be deleted) without a
Balancing the DFD against the PROCESS SPEC

Here are the rules for balancing the DFD against the process specifications:

- Every bubble in the DFD must be associated with a lower-level DFD or a

process specification, but not both. Thus, if the DFD shows a bubble that
is identified as 1.4.2, then there must either be a corresponding figure
identified as Figure 1.4.2 whose bubbles are identified as 1.4.2.1,
1.4.2.2, and so on, or the structured specification must contain a
process specification for bubble 1.4.2. If both exist, the model is
unnecessarily (and dangerously) redundant.
- Every process specification must have an associated bottom-level bubble
in the DFD. Since the process specification does require a lot of work,
one would think it highly unlikely that there would be “tramp” process
specifications floating around a system. But it can happen: the process
specification may have been written for a preliminary version of the
DFD, after which a revision process might eliminate some of the DFD
bubbles.
- Inputs and outputs must match. The DFD will show incoming and
outgoing flows for each bubble, as well as connections to stores. These
should be evident in the process specification, too: thus, we should
expect to see a READ statement (or GET, or INPUT, or ACCEPT, or some
other similar verb) corresponding to each incoming dataflow and a
WRITE (or PUT, or DISPLAY, etc.) for each outgoing dataflow.
Balancing the PROCESS SPECS against the DFD and DD

The rules for balancing the process specifications against the dataflow
diagram and data dictionary can be described as follows; each data
reference in the process specification (typically a noun) must satisfy
one of the following rules:

- It matches the name of a dataflow or data store connected to

the bubble described by the process specification, or
- It is a local term, explicitly defined in the process specification,
or
- It appears as a component in a data dictionary entry for a
dataflow or data store connected to the bubble.
Balancing the DD against the DFD and PROCESS SPECS

From the discussion above, it can be seen that the data dictionary is
consistent with the rest of the model if it obeys the following rule:

- Each entry in the data dictionary must be referenced by a

process specification, or a DFD, or another data dictionary
entry.

This assumes, of course, that we are modeling the essential

behavior of a system. A complex, exhaustive data dictionary of
an existing implementation of a system may contain some data
elements that are no longer used.
Balancing the ERD against the DFD and PROCESS SPECS

The entity-relationship diagram, as we saw in Chapter 12, presented a

very different view of a system than did the dataflow diagram.
However, there are some relationships that must hold in order for the
overall system model to be complete, correct, and consistent:

- Every store on the DFD must correspond to an object type, or a

relationship, or a combination of an object type and relationship
(i.e., an associative object type) on the ERD. If there is a store
on the DFD that does not appear on the ERD, something is
wrong; and if there is an object or relationship on the ERD that
does not appear on the DFD, something is wrong.
- Object names on the ERD and data store names on the DFD
must match. As we saw in Chapter 9 and Chapter 12, the
convention in this book is to use the plural form (e.g.,
CUSTOMERS) on the DFD and the singular form on the ERD.
- The data dictionary entries must apply to both the DFD model
and the ERD model. Thus the data dictionary entry for the
above example should include definitions for both the object on
the ERD and the store on the DFD. This would imply a data
dictionary definition such as the following:
 CUSTOMERS = {CUSTOMER}

CUSTOMER = name + address + phone-number + ...

The data dictionary entries for the singular form (e.g.,

CUSTOMER) must provide the meaning and composition of a
single instance of the set of objects referred to (in the singular) in
the ERD and (in the plural) in the data store of a DFD. The data
dictionary entries for the plural form (e.g., CUSTOMERS) provide
the meaning and the composition of the set of instances.
Balancing the DFD against STD

The state transition diagram can be considered balanced against the

dataflow diagram if the following rules are met:

- Every control bubble in the DFD has associated with it a state-

transition diagram as its process specification. Similarly, every
state-transition diagram in the overall system model must be
associated with a control process (bubble) in the DFD.
- Every condition in the state-transition diagram must correspond to
an incoming control flow into the control process associated with
the state-transition diagram. Similarly, every incoming control
flow on the control bubble must be associated with an appropriate
condition on the corresponding state-transition diagram.
 - Every action in the state-transition diagram must correspond to an outgoing control
flow in the control process associated with the state-transition diagram. Similarly,
every outgoing control flow on the control bubble must be associated with an
appropriate action on the corresponding state-transition diagram.

The additional modeling tools include,

● Flow charts and their variants.

● System flow charts.

● HIPO diagrams and structure charts.

● Variations on data flow diagrams.

● Variations on entity – relationship diagrams.

Flowcharts and their variants

1)Classic flow chart-earlier flow chart:

It is an informal exposure to data processing or

programming.

Notations:

- Rectangular box - an executable computer instruction or

a contiguous sequence of instructions.
- Diamond shaped box – Decision/binary decisions.
- Arrows – Represent the flow control.
- An unstructured flowchart
Variations on flowcharts

There aresome variations that you should be

aware of. We will mention four:

1. Nassi-Shneiderman diagrams

2. Ferstl diagrams

3. Hamilton-Zeldin diagrams

4. Problem analysis diagrams

Nassi-Shneiderman diagrams

It is a way of enforcing a strict structured

programming

approach.It is easy to read.

4. Problem analysis diagrams

Nassi-Shneiderman diagrams

It is a way of enforcing a strict structured programming

approach.It is easy to read.

Ferstl diagrams

It is used to show parallel processing

Hamilton-Zeldin diagrams

There were developed as part of the software development activities for NASA’s
Space

Shuttle project. sometimes referred to as a structured design diagram

Problem analysis diagrams (PAD)

2)System flowcharts

A high-level view of the organization of a system can be shown by

another kind of flowchart: the system flowchart.

the rectangular boxes represent operational aggregates of computer

software the rectangular boxes represent operational aggregates of
computer software (e.g., computer programs,job steps, runs, or other
units of computer software). The system flowchart also shows various
kinds of physical files (e.g., magnetic tape files or disk files). And it may
show the presence of on-line terminals and telecommunication links.
3 )HIPO(High Input Process Output) diagrams
- HIPO diagrams were developed by IBM in the 1970s
and have been used by some systems analysts to
present a high-level view of the functions performed
by a system, as well as the decomposition of
functions into subfunctions,
- It is mainly used for organization chart to describe the
hierarchy of managers,submanagers.
- It is only to understand the data relationships.
4) Structure charts

A variation on HIPO diagrams that is in wide use is the structure chart.

in addition to showing the functional hierarchy, it also shows the data interfaces
between

the components the rectangular box in a structure chart does not represent a
single computational statement or a contiguous group of statements; instead, it
represents a module. (Common examples of modules are FORTRAN subroutines, C
procedures, COBOL subprograms,and SECTIONs.) The arrows connecting the
modules do not represent GOTO statements, but instead represent subroutine
calls; the notation implies that a subroutine will exit, or return, to its caller when it
has finished carrying out its function.
5) Variations of dataflow diagrams

The primary differences usually involve such things as the

use of a rectangle or oval instead of a bubble to show the functions
carried out by a system; dataflow diagrams drawn with ovals are
frequently referred to as Gane-Sarson diagrams.

there is at least one significant variation on the classic

dataflow diagram; it is known as the SADT diagram and was
developed at Softech the SADT diagrams distinguish between data
flow and control flow by the placement of the arrows on the
rectangular boxes.
6)Variations on entity-relationship diagrams

The other popular data structure notations:

* Bachman diagram

* DeMarco’s data structure diagrams

* Jackson’s data structure diagrams

Bachman diagram, first developed by Charles Bachman in the

1960s. it is similar to the entity-

relationship diagram, but does not explicitly show the relationship

between objects. Note also the double-headed arrow: this indicates a
one-to-many relationship (e.g., a customer
 The DeMarco data structure diagrams have achieved considerable
popularity during the past ten years; in addition to showing each object
in the data model, the diagram shows the key field;
 Jackson’s data structure diagrams are not widely used in
the United States at the present time, they are quite popular in
England, Europe, and other parts of the world; have developed
similar data models, which are somewhat more popular in the
United States. Rather than concentrating on the relationship
between different objects in a system, the Jackson diagrams
provide a graphical means of showing the hierarchical structure of a
single object. note that this same hierarchical structure can also be
documented directly in a data dictionary using the notation.
 MODELING TOOLS FOR PROJECT MANAGEMENT:

For managing a system development project we use charts/tools like

PERT chart

GANTT chart

Why does management need models:

- To estimate the money, time & people required to develop the project.
- To update & revise those estimates as the project continues.
- To manage the tasks & activities of the people working on the project.

PERT chart
- Program Evaluation Review Technique
- Developed in 1960s as management tool for the us Navys for submarine project.
- It is widely used in Industry & Govt projects.
- Each rectangular box represent a task or an activity.
- The boxes with rounded corners are known as milestones & meaning within the context of a typical project.
- The line connecting the boxes show dependencies.
 A Gantt chart lists tasks in a project on a
timeline with their interdependencies. It often also
shows who is responsible for what task. It is
especially useful for planning tasks in a project,
and monitoring progress as the project goes on.
Gantt charts emphasise time rather than task
relationships.