SAD Unit5 PGDCA

Unit-5
System Design and Modeling

Monita Wahengbam
Scientist-’C’
NIELIT Senapati Extension Centre
NIELITl Senapati Extension Centre

• Systems design is the process of defining the architecture, modules,
interfaces, and data for a system to satisfy specified requirements.
Systems design could be seen as the application of systems theory
to product development. There is some overlap with the disciplines
of systems analysis, systems architecture and systems engineering.
• System design is the phase that bridges the gap between problem
domain and the existing system in a manageable way. This phase
focuses on the solution domain, i.e. “how to implement?”.
• Systems modeling or system modeling is the interdisciplinary study
of the use of models to conceptualize and construct systems in
business and IT development.
• In this phase, the complex
activity of system
development is divided into
several smaller sub-activities,
which coordinate with each
other to achieve the main
objective of system
development.

Inputs to System Design
• System design takes the following inputs −

• Statement of work
• Requirement determination plan
• Current situation analysis
• Proposed system requirements including a conceptual data model,
modified DFDs, and Metadata (data about data).

Outputs for System Design
• System design gives the following outputs −
• Infrastructure and organizational changes for the proposed
system.
• A data schema, often a relational schema.
• Metadata to define the tables/files and columns/data-items.
• A function hierarchy diagram or web page map that graphically
describes the program structure.
• Actual or pseudocode for each module in the program.
• A prototype for the proposed system.

Types of System Design
• Architectural design
• The architectural design of a system emphasizes the design of the system architecture that describes the
structure, behavior and more views of that system and analysis.
• Logical design
• The logical design of a system pertains to an abstract representation of the data flows, inputs and outputs of
the system. This is often conducted via modelling, using an over-abstract (and sometimes graphical) model
of the actual system. In the context of systems, designs are included. Logical design includes entity-
relationship diagrams (ER diagrams).
• Physical design
• The physical design relates to the actual input and output processes of the system. This is explained in terms
of how data is input into a system, how it is verified/authenticated, how it is processed, and how it is
displayed. In physical design, the following requirements about the system are decided.
• Input requirement,
• Output requirements,
• Storage requirements,
• Processing requirements,
• System control and backup or recovery.
Process Modeling
• Process modeling involves graphically representing the processes, or
actions, that capture, manipulate, store, and distribute data between a
system and its environment and among components within a system. A
common form of a process model is a data-flow diagram (DFD). A data-flow
diagram is a graphic that illustrates the movement of data between external
entities and the processes and data stores within a system. Although several
different tools have been developed for process modeling, we focus solely
on data-flow diagrams because they are useful tools for process modeling.
Data-flow diagramming is one of several structured analysis techniques used
to increase software development productivity. Although not all
organizations use each structured analysis technique, collectively, these
techniques, like dataflow diagrams, have had a significant impact on the
quality of the systems development process.
Modeling a System’s Process
• The analysis team begins the process of structuring requirements with
an abundance of information gathered during requirements
determination. As part of structuring, you and the other team
members must organize the information into a meaningful
representation of the information system that exists and of the
requirements desired in a replacement system. In addition to modeling
the processing elements of an information system and transformation
of data in the system, you must also model the structure of data within
the system. Analysts use both process and data models to establish the
specification of an information system. With a supporting tool, such as
a CASE tool, process and data models can also provide the basis for the
automatic generation of an information system.

Deliverables and Outcomes
• In structured analysis, the primary deliverables from process modeling are a set of
coherent, interrelated data-flow diagrams. Table lists the progression of deliverables
that result from studying and documenting a system’s process. First, a context data-
flow diagram shows the scope of the system, indicating which elements are inside and
outside the system. Second, data-flow diagrams of the current system specify which
people and technologies are used in which processes to move and transform data,
accepting inputs and producing outputs. The detail of these diagrams allows analysts
to understand the current system and eventually to determine how to convert the
current system into its replacement. Third, technology-independent, or logical, data-
flow diagrams show the dataflow, structure, and functional requirements of the new
system. Finally, entries for all of the objects in all diagrams are included in the project
dictionary or CASE repository.

• This logical progression of deliverables helps you to understand the existing
system. You can then reduce this system into its essential elements to show
the way in which the new system should meet its information processing
requirements, as they were identified during requirements determination.
In later steps in the systems development life cycle, you and other project
team members make decisions on exactly how the new system will deliver
these new requirements in specific manual and automated functions.
Because requirements determination and structuring are often parallel
steps, data-flow diagrams evolve from the more general to the more
detailed as current and replacement systems are better understood. Even
though data-flow diagrams remain popular tools for process modeling and
can significantly increase software development productivity, they are not
used in all systems development methodologies.
Logical and physical design
• Logical Design
• Logical design pertains to an abstract representation of the data
flow, inputs, and outputs of the system. It describes the inputs
(sources), outputs (destinations), databases (data stores),
procedures (data flows) all in a format that meets the user
requirements.
• While preparing the logical design of a system, the system analyst
specifies the user needs at level of detail that virtually determines
the information flow into and out of the system and the required
data sources. Data flow diagram, E-R diagram modeling are used.

Physical Design
• Physical design relates to the actual input and output processes of the system. It focuses
on how data is entered into a system, verified, processed, and displayed as output.
• It produces the working system by defining the design specification that specifies exactly
what the candidate system does. It is concerned with user interface design, process
design, and data design.
• It consists of the following steps −
• Specifying the input/output media, designing the database, and specifying backup
procedures.
• Planning system implementation.
• Devising a test and implementation plan, and specifying any new hardware and
software.
• Updating costs, benefits, conversion dates, and system constraints.

• Architectural Design
• It is also known as high level design that focuses on the design of system
architecture. It describes the structure and behavior of the system. It defines
the structure and relationship between various modules of system
development process.
• Detailed Design
• It follows Architectural design and focuses on development of each module.

Conceptual Data Modeling
• It is representation of organizational data which includes all the major
entities and relationship. System analysts develop a conceptual data
model for the current system that supports the scope and
requirement for the proposed system.
• The main aim of conceptual data modeling is to capture as much
meaning of data as possible. Most organization today use conceptual
data modeling using E-R model which uses special notation to
represent as much meaning about data as possible.

Systems flowcharts and structured charts
• Structure Chart represent hierarchical structure of modules. It breaks
down the entire system into lowest functional modules, describe functions
and sub-functions of each module of a system to a greater detail. Structure
Chart partitions the system into black boxes (functionality of the system is
known to the users but inner details are unknown). Inputs are given to the
black boxes and appropriate outputs are generated.
• Modules at top level called modules at low level. Components are read
from top to bottom and left to right. When a module calls another, it views
the called module as black box, passing required parameters and receiving
results.

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

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

3. Loop (Repetitive call of module)
It represents the repetitive execution of module by the sub module.
A curved arrow represents loop in the module.

4. Data Flow 5. Control Flow
It represents the flow of data It represents the flow of control
between the modules. It is between the modules. It is
represented by directed arrow represented by directed arrow with
with empty circle at the end. filled circle at the end.

6. Physical Storage
Physical Storage is Example : Structure chart for an Email server
that where all the
information are to
be stored.

Types of Structure Chart:
• Transform Centered Structured:
These type of structure chart are designed for the systems that
receives an input which is transformed by a sequence of operations
being carried out by one module.
• Transaction Centered Structure:
These structure describes a system that processes a number of
different types of transaction.

• What is a Flowchart?
Flowchart is a graphical representation of an algorithm. Programmers
often use it as a program-planning tool to solve a problem. It makes
use of symbols which are connected among them to indicate the flow
of information and processing.
The process of drawing a flowchart for an algorithm is known as
“flowcharting”.

Basic Symbols used in Flowchart Designs
• Terminal: The oval symbol indicates Start, Stop and
Halt in a program’s logic flow. A pause/halt is
generally used in a program logic under some error
conditions. Terminal is the first and last symbols in
the flowchart.
• Input/Output: A parallelogram denotes any function
of input/output type. Program instructions that take
input from input devices and display output on
output devices are indicated with parallelogram in a
flowchart.

• Processing: A box represents arithmetic instructions.
All arithmetic processes such as adding, subtracting,
multiplication and division are indicated by action or
process symbol.
• Decision Diamond symbol represents a decision
point. Decision based operations such as yes/no
question or true/false are indicated by diamond in
flowchart.
• Connectors: Whenever flowchart becomes complex
or it spreads over more than one page, it is useful to
use connectors to avoid any confusions. It is
represented by a circle.
• Flow lines: Flow lines indicate the exact sequence in
which instructions are executed. Arrows represent
the direction of flow of control and relationship
among different symbols of flowchart.
• Advantages of Flowchart: Disadvantages of Flowchart:
• Flowcharts are better way of • It is difficult to draw
communicating the logic of system. flowchart for large and
• Flowcharts act as a guide for complex programs.
blueprint during program designed. • In this their is no standard to
• Flowcharts helps in debugging determine the amount of
process. detail.
• With the help of flowcharts • Difficult to reproduce the
programs can be easily analyzed. flowcharts.
• It provides better documentation. • It is very difficult to modify
• Flowcharts serve as a good proper the Flowchart.
documentation.

Example : Draw a
flowchart to input two
numbers from user and
display the largest of two
numbers

Difference between Structure chart and Flow chart :
Structure chart Flow chart
Structure chart represents the software Flow chart represents the flow of control in
architecture. program.
It is easy to identify the different modules of the It is difficult to identify the different modules of the
software from structure chart. software from the flow chart.
Symbols used in structure chart are complex. Symbols used in flow chart are simple.
Data interchange between different modules is Data interchange among different modules is not
represented here. represented in flow chart.
In structure chart different types of arrows are used Only a single type of arrow is used to show the
to represent data flow and module invocation. control flow in flow chart.
It suppresses the sequential ordering of tasks It demonstrates the sequential ordering of inherent
inherent in a flow chart. tasks.
Structure chart is complex to construct in Flow chart is easier to construct in comparison of

comparison of flow chart. structure chart.
Structure chart is hard to understand. Flow chart is easy to understand.

Data flow diagram (DFD)?
• DFD is the abbreviation for Data Flow Diagram. The flow of data of a system or a process is
represented by DFD. It also gives insight into the inputs and outputs of each entity and the
process itself. DFD does not have control flow and no loops or decision rules are present.
Specific operations depending on the type of data can be explained by a flowchart. Data
Flow Diagram can be represented in several ways. The DFD belongs to structured-analysis
modeling tools. Data Flow diagrams are very popular because they help us to visualize the
major steps and data involved in software-system processes.
• Data means information, flow means to move, and diagram means a picture to represent
something. So, DFD is simply the graphical representation of the flow of data or
information. It is a framework or pattern of the data systems. It includes data input, data
output, storing data. DFD describes the process of taking the data as input, storing the
data, giving the data as output. DGD describes the path of data that completes the
process.
• There are mainly two types of DFD: Physical Data Flow Diagram, and Logical Data Flow
Diagram.
The Data Flow Diagram has 4 components:
• Process
Input to output transformation in a system takes place because of process function. The symbols of
a process are rectangular with rounded corners, oval, rectangle or a circle. The process is named a
short sentence, in one word or a phrase to express its essence
• Data Flow
Data flow describes the information transferring between different parts of the systems. The arrow
symbol is the symbol of data flow. A relatable name should be given to the flow to determine the
information which is being moved. Data flow also represents material along with information that is
being moved. Material shifts are modeled in systems that are not merely informative. A given flow
should only transfer a single type of information. The direction of flow is represented by the arrow
which can also be bi-directional.
• Warehouse
The data is stored in the warehouse for later use. Two horizontal lines represent the symbol of the
store. The warehouse is simply not restricted to being a data file rather it can be anything like a
folder with documents, an optical disc, a filing cabinet. The data warehouse can be viewed
independent of its implementation. When the data flow from the warehouse it is considered as data
reading and when data flows to the warehouse it is called data entry or data updation.

• Terminator
The Terminator is an external entity that stands outside of the system
and communicates with the system. It can be, for example,
organizations like banks, groups of people like customers or different
departments of the same organization, which is not a part of the
model system and is an external entity. Modeled systems also
communicate with terminator.

Rules for creating DFD
• The name of the entity should be easy and understandable without
any extra assistance(like comments).
• The processes should be numbered or put in ordered list to be
referred easily.
• The DFD should maintain consistency across all the DFD levels.
• A single DFD can have maximum processes upto 9 and minimum 3
processes.

Levels of DFD
• DFD uses hierarchy to maintain transparency thus multilevel DFD’s
can be created. Levels of DFD are as follows:
• 0-level DFD
• 1-level DFD:
• 2-level DFD:

• Advantages of DFD
Disadvantages of DFD
• It helps us to understand the •At times DFD can confuse the
functioning and the limits of a
system. programmers regarding the
system.
• It is a graphical representation
which is very easy to understand •Data Flow Diagram takes long
as it helps visualize contents. time to be generated, and
many times due to this
• Data Flow Diagram represent
detailed and well explained reasons analysts are denied
diagram of system components. permission to work on it.
• It is used as the part of system
documentation file.
• Data Flow Diagrams can be
understood by both technical or
nontechnical person because they
are very easy to understand.
• 0-level DFD:
It is also known as a context diagram. It’s designed to be an
abstraction view, showing the system as a single process with its
relationship to external entities. It represents the entire system as a
single bubble with input and output data indicated by
incoming/outgoing arrows.

• 1-level DFD:
In 1-level DFD,
the context
diagram is
decomposed
into multiple
bubbles/process
es. In this level,
we highlight the
main functions
of the system
and breakdown
the high-level
process of 0-
level DFD into
subprocesses.
• 2-level DFD:
2-level DFD
goes one
step deeper
into parts of
1-level DFD.
It can be
used to plan
or record the
specific/nece
ssary detail
about the
system’s
functioning.

DFD for Library Management System
• Data Flow Diagram (DFD) depicts the flow of information and the transformation
applied when a data moves in and out from a system. The overall system is
represented and described using input, processing and output in the DFD. The
inputs can be:
• Book request when a student requests for a book.
• Library card when the student has to show or submit his/her identity as a
proof.
• The overall processing unit will contain the following output that a system will
produce or generate:
• Book will be the output as the book demanded by the student will be given to
them.
• Information of demanded book should be displayed by the library information
system that can be used by the student while selecting the book which makes it
easier for the student.

• Level 0 DFD –

• Level 1 DFD –
At this level, the system has
to show or exposed with
more details of processing.
The processes that are
important to be carried out
are: 1) Book delivery,
2) Search by topic
• List of authors, List of Titles,
List of Topics, the
bookshelves from which
books can be located are
some information that is
required for these
processes. Data store is
used to represent this type
of information.
• Level 2 DFD –

Entity Relationship Diagram (ERD):
• ERD is also known as the Entity-Relationship Model. ERD was
originally proposed by Peter Chen. Entity means any object used to
store information and are distinguishable, relationship means
connection, and diagram/model means a picture uses to represent
something. So, ERD is simply the diagram or model that is used to
represent or show the relationship between the entities or data
objects that are stored in a database. The main components of the E-
R model are an entity, attributes, and relationship. It is a very easy
way to represent the database design.

• ER Model is used to model the logical view of the system
from data perspective which consists of these components:
• Entity, Entity Type, Entity Set –
• An Entity may be an object with a physical existence – a
particular person, car, house, or employee – or it may be an
object with a conceptual existence – a company, a job, or a
university course.
• An Entity is an object of Entity Type and set of all entities is
called as entity set. e.g.; E1 is an entity having Entity Type
Student and set of all students is called Entity Set.
• Entity Type is represented as:
• Attribute(s):
Attributes are the properties which define the
entity type. For example, Roll_No, Name, DOB,
Age, Address, Mobile_No are the attributes
which defines entity type Student. In ER
diagram, attribute is represented by an oval.
• Key Attribute –
The attribute which uniquely identifies each
entity in the entity set is called key attribute.For
example, Roll_No will be unique for each student.
In ER diagram, key attribute is represented by an
oval with underlying lines.
• Composite Attribute –
An attribute composed of many other attribute is
called as composite attribute. For example, Address
attribute of student Entity type consists of Street,
City, State, and Country. In ER diagram, composite
attribute is represented by an oval comprising of
ovals.
• Multivalued Attribute –
An attribute consisting more than one value for
a given entity. For example, Phone_No (can be
more than one for a given student). In ER
diagram, multivalued attribute is represented
by double oval.
• Derived Attribute –
An attribute which can be derived from other
attributes of the entity type is known as derived
attribute. e.g.; Age (can be derived from DOB).
In ER diagram, derived attribute is represented
by dashed oval.

The
complete
entity
type Student
with its
attributes
can be
represented
as:

Relationship Type and Relationship Set:
• A relationship type represents the association between entity types.
For example,‘Enrolled in’ is a relationship type that exists between
entity type Student and Course. In ER diagram, relationship type is
represented by a diamond and connecting the entities with lines.

• A set of relationships of same type is known as relationship set. The
following relationship set depicts S1 is enrolled in C2, S2 is enrolled in
C1 and S3 is enrolled in C3.

• Degree of a relationship set:
The number of different entity sets participating in a relationship set
is called as degree of a relationship set.
• Unary Relationship –
When there is only ONE entity set participating in a relation, the
relationship is called as unary relationship. For example, one
person is married to only one person.

• Binary Relationship –
When there are TWO entities set participating in a relation, the
relationship is called as binary relationship.For example, Student is
enrolled in Course.
• n-ary Relationship –
When there are n entities set participating in a relation, the
relationship is called as n-ary relationship.

• Cardinality:
The number of times an entity of an entity set participates in a
relationship set is known as cardinality. Cardinality can be of different
types:
• One to one – When each entity in each entity set can take part only
once in the relationship, the cardinality is one to one. Let us
assume that a male can marry to one female and a female can
marry to one male. So the relationship will be one to one.

• Using Sets, it can be represented as:

• Many to one – When entities in one entity set can take part only
once in the relationship set and entities in other entity set can take
part more than once in the relationship set, cardinality is many to
one. Let us assume that a student can take only one course but one
course can be taken by many students. So the cardinality will be n to
1. It means that for one course there can be n students but for one
student, there will be only one course.

• Using Sets, it can be represented as:
• In this case, each student is taking only 1 course but 1 course has
been taken by many students.

• Many to many – When entities in all entity sets can take part more
than once in the relationship cardinality is many to many. Let us
assume that a student can take more than one course and one course
can be taken by many students. So the relationship will be many to
many.

• Using sets, it can be represented as:
• In this example, student S1 is enrolled in C1 and C3 and Course C3 is
enrolled by S1, S3 and S4. So it is many to many relationships.

• Participation Constraint:
Participation Constraint is applied on the entity participating in the relationship
set.
• Total Participation – Each entity in the entity set must participate in the
relationship. If each student must enroll in a course, the participation of student
will be total. Total participation is shown by double line in ER diagram.
• Partial Participation – The entity in the entity set may or may NOT participate in
the relationship. If some courses are not enrolled by any of the student, the
participation of course will be partial.The diagram depicts the ‘Enrolled in’
relationship set with Student Entity set having total participation and Course
Entity set having partial participation.

• Using set, it can be represented as,
• Every student in Student Entity set is participating in relationship but
there exists a course C4 which is not taking part in the relationship.

• Weak Entity Type and Identifying Relationship:
As discussed before, an entity type has a key attribute which uniquely identifies
each entity in the entity set. But there exists some entity type for which key
attribute can’t be defined. These are called Weak Entity type.
• For example, A company may store the information of dependants (Parents,
Children, Spouse) of an Employee. But the dependents don’t have existence
without the employee. So Dependent will be weak entity type and Employee will
be Identifying Entity type for Dependant.
• A weak entity type is represented by a double rectangle. The participation of weak
entity type is always total. The relationship between weak entity type and its
identifying strong entity type is called identifying relationship and it is represented
by double diamond.

Difference between DFD and ERD :
S.No. DFD ERD
1. It stands for Data Flow Diagram. It stands for Entity Relationship Diagram or Model.
Main objective is to represent the processes and data Main objective is to represent the data object or entity
2.
flow between them. and relationship between them.
It explains the flow and process of data input, data It explains and represent the relationship between
3.
output, and storing data. entities stored in a database.
Symbols used in DFD are: rectangles (represent the data

Symbols used in ERD are: rectangles (represent the
entity), circles (represent the process), arrows (represent
4. entity), diamond boxes (represent relationship), lines
the flow of data), ovals or parallel lines (represent data
and standard notations (represent cardinality).
storing).
Rule followed by DFD is that at least one data flow

Rule followed by ERD is that all entities must represent
5. should be there entering into and leaving the process or
the set of similar things.
store.
It model entities like people, objects, places and
6. It models the flow of data through a system.
events for which data is stored in a system.

SAD Unit5 PGDCA

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAD Unit5 PGDCA

Uploaded by

Copyright:

Available Formats

Unit-5

System Design and Modeling

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

• System design takes the following inputs −

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

Structure chart is complex to construct in Flow chart is easier to construct in comparison of

Structure chart is hard to understand. Flow chart is easy to understand.

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

NIELITl Senapati Extension Centre

Symbols used in DFD are: rectangles (represent the data

Rule followed by DFD is that at least one data flow

You might also like