LO 3 Validet The Design

Defense University
Maj. Gen. Mulugeta Buli Polytechnic

College
Ethiopian TVET-System
Database
Administration
Level III
Learning Guide # 3
Unit of Competence: Design Program Logic
Module Title : Design Program Logic
LG Code : ICT DBA3 05 0710
LO3: Validate the design
Date: Dec- 2019/2020

Compiled by: Abadit A. Page 1 of24
LO 3: Validate the design
3.1. Software Design Strategies
Software design is a process to conceptualize the software requirements into software

implementation. Software design takes the user requirements as challenges and tries to find
optimum solution. While the software is being conceptualized, a plan is chalked out to find the
best possible design for implementing the intended solution. There are multiple variants of
software design. Let us study them briefly:
 Structured Design
 Function Oriented Design
 Object Oriented Design
Structured Design
Structured design is a conceptualization of problem into several well-organized elements of

solution. It is basically concerned with the solution design. Benefit of structured design is, it
gives better understanding of how the problem is being solved. Structured design also makes it
simpler for designer to concentrate on the problem more accurately.
Structured design is mostly based on ‘divide and conquer’ strategy where a problem is broken
into several small problems and each small problem is individually solved until the whole
problem is solved.
The small pieces of problem are solved by means of solution modules. Structured design
emphasis that these modules be well organized in order to achieve precise solution.
These modules are arranged in hierarchy. They communicate with each other. A good structured
design always follows some rules for communication among multiple modules, namely -
Cohesion - grouping of all functionally related elements.
Coupling - communication between different modules.
A good structured design has high cohesion and low coupling arrangements.
Function Oriented Design
In function-oriented design, the system is comprised of many smaller sub-systems known as

functions. These functions are capable of performing significant task in the system. The system
is considered as top view of all functions.
Date: Dec- 2019/2020

Function oriented design inherits some properties of structured design where divide and conquer
methodology is used.
This design mechanism divides the whole system into smaller functions, which provides means
of abstraction by concealing the information and their operation. These functional modules can
share information among themselves by means of information passing and using information
available globally.
Another characteristic of functions is that when a program calls a function, the function changes
the state of the program, which sometimes is not acceptable by other modules. Function oriented
design works well where the system state does not matter and program/functions work on input
rather than on a state.
Object Oriented Design
Object oriented design works around the entities and their characteristics instead of functions
involved in the software system. This design strategy focuses on entities and its characteristics.
The whole concept of software solution revolves around the engaged entities. Let us see the
important concepts of Object Oriented Design:
 Objects - All entities involved in the solution design are known as objects. For example,
person, banks, company and customers are treated as objects. Every entity has some
attributes associated to it and has some methods to perform on the attributes.
 Classes - A class is a generalized description of an object. An object is an instance of a
class. Class defines all the attributes, which an object can have and methods, which
defines the functionality of the object.
In the solution design, attributes are stored as variables and functionalities are defined by
means of methods or procedures.
 Encapsulation - In OOD, the attributes (data variables) and methods (operation on the
data) are bundled together is called encapsulation. Encapsulation not only bundles
important information of an object together, but also restricts access of the data and
methods from the outside world. This is called information hiding.
 Inheritance - OOD allows similar classes to stack up in hierarchical manner where the
lower or sub-classes can import, implement and re-use allowed variables and methods
from their immediate super classes. This property of OOD is known as inheritance. This
makes it easier to define specific class and to create generalized classes from specific
ones.
 Polymorphism - OOD languages provide a mechanism where methods performing
similar tasks but vary in arguments, can be assigned same name. This is called
polymorphism, which allows a single interface performing tasks for different types.
Depending upon how the function is invoked, respective portion of the code gets
executed.
Date: Dec- 2019/2020

3.2. Design Process: Software design process can be perceived as series of well-defined steps.
Though it varies according to design approach (function oriented or object oriented, yet It may
have the following steps involved:
 A solution design is created from requirement or previous used system and/or system
sequence diagram.
 Objects are identified and grouped into classes on behalf of similarity in attribute
characteristics.
 Class hierarchy and relation among them are defined.
 Application framework is defined.
3.3. Paradigms and models

The most used, popular and important SDLC models are given below:
 Entity-Relationship Model
 Waterfall model
 Iterative model
 Spiral model
 V-shaped model
 Agile model
3.4.1. Entity-Relationship Model
Entity-Relationship model is a type of database model based on the notion of real world entities
and relationship among them. We can map real world scenario onto ER database model. ER
Model creates a set of entities with their attributes, a set of constraints and relation among them.
ER Model is best used for the conceptual design of database. ER Model can be represented as
follows:
 Entity - An entity in ER Model is a real world being, which has some properties called
attributes. Every attribute is defined by its corresponding set of values, called domain.
For example: Consider a school database. Here, a student is an entity. Student has various
attributes like name, id, age and class etc.
 Relationship - The logical association among entities is called relationship.
Relationships are mapped with entities in various ways. Mapping cardinalities define the
number of associations between two entities.
Date: Dec- 2019/2020

Cardinality and Ordinality: Cardinality refers to the maximum number of times an
instance in one entity can relate to instances of another entity. Ordinality, on the other
hand, is the minimum number of times an instance in one entity can be associated with an
instance in the related entity.
Cardinality and cordiality are shown by the styling of a line and its endpoint, according to the
chosen notation style.
ER-Diagram (ERD)
ER-Diagram is a pictorial representation of data that describes how data is communicated and related to
each other. Any object, such as entities, attributes of an entity, sets of relationship and other attributes of
relationship can be characterized with the help of the ER diagram.
Conceptual ER diagram symbols
Conceptual Data Models establish a broad view of what should be included in the model set.
Conceptual ERDs can be used as the foundation for logical data models. They may also be used
to form commonality relationships between ER models as a basis for data model integration. All
of the symbols shown below are found in the UML Entity Relationship and Entity Relationship
shape library.
ERD entity symbols
Entities are objects or concepts that represent important data. Entities are typically nouns such as
product, customer, location, or promotion. There are three types of entities commonly used in
entity relationship diagrams.
Date: Dec- 2019/2020

Entity Symbol Name Description
Strong entity These shapes are independent from other entities, and are often
called parent entities, since they will often have weak entities
that depend on them. They will also have a primary key,
distinguishing each occurrence of the entity.
Weak entity Weak entities depend on some other entity type. They don't
have primary keys, and have no meaning in the diagram
without their parent entity.
Associative Associative entities relate the instances of several entity types.

entity They also contain attributes specific to the relationship between
those entity instances.
ERD relationship symbols
Within entity-relationship diagrams, relationships are used to document the interaction between
two entities. Relationships are usually verbs such as assign, associate, or track and provide useful
information that could not be discerned with just the entity types.
Relationship Symbol Name Description

Relationship Relationships are associations between or among
entities.
Weak Weak Relationships are connections between a

relationship weak entity and its owner.
ERD attribute symbols
ERD attributes are characteristics of the entity that help users to better understand the database.
Attributes are included to include details of the various entities that are highlighted in a
conceptual ER diagram.
Date: Dec- 2019/2020

Attribute Name Description
Symbol
Attribute Attributes are characteristics of an entity, a many-to-many
relationship, or a one-to-one relationship.
Multivalued Multivalued attributes are those that are can take on more
attribute than one value.
Derived attribute Derived attributes are attributes whose value can be

calculated from related attribute values.
Relationship Relationships are associations between or among entities.
Physical ER diagram symbols
The physical data model is the most rough level of entity-relationship diagrams, and represents
the process of adding information to the database. Physical ER models show all table structures,
including column name, column data type, column constraints, primary key, foreign key, and
relationships between tables.
As shown below, tables are another way of representing entities. The key parts of Entity-
relationship Tables are:
Fields: Fields represent the portion of a table that establishes the attributes of the entity.
Attributes are typically thought of as columns in the database that the ERD models.
In the image above, Interest Rate and Loan Amount are both attributes of the entity that are
contained as fields.
Date: Dec- 2019/2020

Keys: Keys are one way to categorize attributes. ER diagrams help users to model their
databases by using various tables that ensure that the database is organized, efficient, and fast.
Keys are used to link various tables in a database to each other in the most efficient way
possible.
Primary Keys: Primary keys are an attribute or combination of attributes that uniquely identifies
one and only one instance of an entity.
Rules for defining Primary key:

 Two rows can't have the same primary key value
 It must for every row to have a primary key value.
 The primary key field cannot be null.
 The value in a primary key column can never be modified or updated if any
foreign key refers to that primary key.
Foreign Keys: Foreign keys are created any time an attribute relates to another entity in a one-to-
one or one-to-many relationship.
Each car can only be financed by one bank, therefore the primary key Bank Id from the Bank
table is used as the foreign key Financed By in the Car table.
Types: Types refer to the type of data in the corresponding field in a table. Types can also refer
to entity types, which describe the composition of an entity; e.g., a book's entity types are author,
title, and published date.
ER diagram notation
While crow's foot notation is often recognized as the most intuitive style, some use OMT,
IDEF, Bachman, or UML notation, according to their preferences. Crow's foot notation,
however, has an intuitive graphic format, making it the preferred ERD notation for Lucidchart.
Date: Dec- 2019/2020

Conceptual, Logical and Physical data models
An ER model is typically drawn at up to three levels of abstraction:
 Conceptual ERD / Conceptual data model

 Logical ERD / Logical data model
 Physical ERD / Physical data model
While all the three levels of ER model contain entities with attributes and relationships, they
differ in the purposes they are created for and the audiences they are meant to target.
A general understanding to the three data models is that business analyst uses conceptual and
logical model to model the business objects exist in the system, while database designer or
database engineer elaborates the conceptual and logical ER model to produce the physical model
that presents the physical database structure ready for database creation. The table below shows
the difference between the three data models. Conceptual model vs Logical model vs physical
Data model:
ERD features Conceptual Logical Physical

Entity (Name) Yes Yes Yes
Relationship Yes Yes Yes
Columns Yes Yes
Column's Types Optional Yes
Primary Key Yes
Foreign Key Yes
Conceptual data model
Conceptual ERD models the business objects that should exist in a system and the
relationships between them. Conceptual model is developed to present an overall picture of the
system by recognizing the business objects involved. It defines what entities exist, NOT which
tables. For example, 'many to many' tables may exist in logical or physical data model but they
are just shown as a relationship with no cardinality under the conceptual data model.
Conceptual data model example
Date: Dec- 2019/2020

NOTE: Conceptual ERD supports the use of generalization in modeling the 'a kind of'
relationship between two entities, for instance, Triangle, is a kind of Shape. The usage is like
generalization in UML. Notice that only conceptual ERD supports generalization.
Logical data model
Logical ERD is a detailed version of a Conceptual ERD. A logical ER model is developed to

enrich a conceptual model by defining explicitly the columns in each entity and introducing
operational and transactional entities. Although a logical data model is still independent of the
actual database system in which the database will be created, you can still take that into
consideration if it affects the design.
Logical data model example
Physical data model
Physical ERD represents the actual design blueprint of a relational database. A physical data
model elaborates on the logical data model by assigning each column with type, length, null able,
etc. Since a physical ERD represents how data should be structured and related in a specific
DBMS it is important to consider the convention and restriction of the actual database system in
which the database will be created. Make sure the column types are supported by the DBMS and
reserved words are not used in naming entities and columns.
Date: Dec- 2019/2020

Physical data model example
How to draw an ER diagram?
If you find it difficult to get started with drawing an ER diagram, don't worry. In this section we
will give you some ERD tips. Try to follow the steps below to understand how to draw an ER
diagram effectively.
1. Make sure you are clear about the purpose of drawing the ERD. Are you trying to present
an overall system architecture which involves the definition of business objects? Or are
you developing an ER model ready for database creation? You must be clear about the
purpose to develop an ER diagram at right level of detail (Read the section Conceptual,
Logical and Physical Data Models for more details)
2. Make sure you are clear about the scope to model. Knowing the modeling scope prevents
you from including redundant entities and relationships in your design.
3. Draw the major entities involved in the scope.
4. Define the properties of entities by adding columns.
5. Review the ERD carefully and check if the entities and columns are enough to store the
data of the system. If not, consider adding additional entities and columns. Usually, you
can identify some transactional, operational and event entities in this step.
6. Consider the relationships between all entities and relate them with proper cardinality
(e.g A one-to-many between entity Customer and Order). Don't worry if there are orphan
entities. Although it's not common, it's legit.
7. Apply the technique of database normalization to re-structure the entities in a way that
can reduce data redundancy and improve data integrity. For example, the details of
manufacturer might be stored under the Product entity initially. During the process of
normalization, you may find that the detail keeps repeating record over record, then you
Date: Dec- 2019/2020

can split it as a separate entity Manufacturer, and with a foreign key that links between
Product and Manufacturer.
Data Dictionary
Data dictionary is the centralized collection of information about data. It stores meaning and
origin of data, its relationship with other data, data format for usage etc. Data dictionary has
rigorous definitions of all names in order to facilitate user and software designers.
Data dictionary is often referenced as meta-data (data about data) repository. It is created along
with DFD (Data Flow Diagram) model of software program and is expected to be updated
whenever DFD is changed or updated.
Requirement of Data Dictionary
The data is referenced via data dictionary while designing and implementing software. Data
dictionary removes any chances of ambiguity. It helps keeping work of programmers and
designers synchronized while using same object reference everywhere in the program.
Data dictionary provides a way of documentation for the complete database system in one place.
Validation of DFD is carried out using data dictionary.
Data dictionary should contain information about the following
 Data Flow
 Data Structure
 Data Elements
 Data Stores
 Data Processing
Data Elements
Data elements consist of Name and descriptions of Data and Control Items, Internal or External
data stores etc. with the following details:
 Primary Name
 Secondary Name (Alias)
 Use-case (How and where to use)
 Content Description (Notation etc. )
 Supplementary Information (preset values, constraints etc.)
Data Store
It stores the information from where the data enters into the system and exists out of the system.
The Data Store may include -
Date: Dec- 2019/2020

 Files
o Internal to software.
o External to software but on the same machine.
o External to software and system, located on different machine.
 Tables
o Naming convention
o Indexing property
Data Processing: There are two types of Data Processing:
 Logical: As user sees it

 Physical: As software sees it
Waterfall SDLC Model
Waterfall is a cascade SDLC model, in which development process looks like the flow, moving
step by step through the phases of analysis, projecting, realization, testing, implementation, and
support. This SDLC model includes gradual execution of every stage completely. This process is
strictly documented and predefined with features expected to every phase of this software
development life cycle model.
Advantages
 Simple to use and understand
 Management simplicity thanks to its rigidity, every phase has a defined results and
process review
 Development stages go one by one
 Perfect for the small or midsized project where requirements are clear and not equivocal
 Easy to determine the key points in the development cycle
 Easy to classify and prioritize the tasks
Disadvantages
 The software is read-only after the last stage is over
 High risks and uncertainty
Date: Dec- 2019/2020

 No the best choice for complex and object oriented project
 Inappropriate for the long term projects
 The progress of the stage is hard to measure while it is still in the development
 Integration is done at the very end, which does not give the option of identifying the
problem in advance
Iterative SDLC Model
The Iterative SDLC model does not need the full list of requirements before the project starts.
The development process may start with the requirements to the functional part, which can be
expanded later. The process is repetitive, allowing to make new versions of the product for every
cycle. Every iteration (which last from two to six weeks) includes the development of a separate
component of the system, and after that, this component is added to the functional developed
earlier. Speaking with math terminology, the iterative model is a realization of the sequential
approximation method; that means a gradual closeness to the planned final product shape.
Advantages
 Some functions can be quickly developed at the beginning of the development lifecycle
 The paralleled development can be applied
 The progress is easy measurable
 The shorter iteration is the easier testing and debugging stages are
 It is easier to control the risks as high risk tasks are completed first
 Problems and risks defined within one iteration can be prevented in the next sprints
 Flexibility and readiness to the changes in the requirements.
Advantages
 Iterative model requires more resources than waterfall mode
 Constant management is required
 Issues with architecture or design may occur because not all the requirements are
foreseen during the short planning stage
 Bad choice for the small projects
 The process is difficult to manage
Date: Dec- 2019/2020

 The risks may not be completely determined even at the final stage of the project
 Risks analysis requires involvement of the highly qualified specialists
Spiral SDLC Model
Spiral model — is SDLC model, which combines architecture and prototyping by stages. It is a
combination of the Iterative and Waterfall SDLC models with the significant accent on the risk
analysis. The main issue of the spiral model — is defining the right moment to make a step into
the next stage. The preliminary set time frames are recommended as the solution to this issue.
The shift to the next stage is done according to the plan, even if the work on the previous stage
isn’t done yet. The plan is introduced basing on the statistical data, received during the previous
projects even from the personal developer’s experience.
Advantages
 Lifecycle is divided into small parts and if the risk concentration is higher the phase can be
finished earlier to address the treats
 The development process is precisely documented yet scalable to the changes
 The scalability allows to make changes and add new functionality even at the relatively late
stages
 The earlier working prototype is done-sooner users can point out the flaws.
Disadvantages
 Can be quite expensive
 The risk control demands involvement of the highly skilled professional
 Can be ineffective for the small projects
 Big number of the intermediate stages requires excessive documentation.
Date: Dec- 2019/2020

V-shaped SDLC Model
V-shaped SDLC model is an expansion of classic waterfall model and it’s based on associated
test stage for every development stage. This is a very strict model and the next stage is started
only after the previous phase. This is also called “Validation and verification” model. Every
stage has the current process control, to make sure that the conversion to the next stage is
possible.
Advantages Disadvantages
 Every stage of v-shape model has strict result so it  Lack of the flexibility
is easy to control.
 Testing and verification take place in the early  Bad choice for the small project
stages
 Good for the small projects when requirements  Relatively big risks
are static and clear
Agile SDLC Model
In the agile methodology after every development and iteration the customer is able to see the
result and understand if he is satisfied with it or not. This is one of the advantages of the agile
software development life cycle model. One of its disadvantages is that with the absence of
defined requirements it is difficult to estimate the resources and development cost. Extreme
programming is one of the practical uses of the agile model. The basis of such model consists of
short weekly meetings — Sprints which are the part of the Scrum approach.
Date: Dec- 2019/2020

Advantages Disadvantages
 Corrections of requirements are  Difficulties with measuring the final cost

implemented into the development process because of permanent changes.
to provide the competitiveness.
 Project is divided by short and transparent  The team should be highly professional and
iterations. client-oriented
 Risks are minimized to the flexible change  New requirements may conflict with the
process existing architecture
 Fast release of the first product version  With all the corrections and changes there is
possibility that the project will exceed
expected time.
HIPO model
HIPO model (short for hierarchical input process output model) is a systems analysis design aid
and documentation technique from the 1970s, used for representing the modules of a system as a
hierarchy and for documenting each module.
It was used to develop requirements, construct the design, and support implementation of an
expert system to demonstrate automated rendezvous. Verification was then conducted
systematically because of the method of design and implementation.
The overall design of the system is documented using HIPO charts or structure charts. The
structure chart is similar in appearance to an organizational chart, but has been modified to show
additional detail. Structure charts can be used to display several types of information, but are
used most commonly to diagram either data structures or code structures.
Purpose
The HIPO (Hierarchy plus Input-Process-Output) technique is a tool for planning and/or
documenting a computer program. A HIPO model consists of a hierarchy chart that graphically
represents the program’s control structure and a set of IPO (Input-Process-Output) charts that
describe the inputs to, the outputs from, and the functions (or processes) performed by each
module on the hierarchy chart.
Date: Dec- 2019/2020

Strengths, weaknesses, and limitations
Using the HIPO technique, designers can evaluate and refine a program’s design, and correct
flaws prior to implementation. Given the graphic nature of HIPO, users and managers can easily
follow a program’s structure. The hierarchy chart serves as a useful planning and visualization
document for managing the program development process. The IPO charts define for the
programmer each module’s inputs, outputs, and algorithms.
In theory, HIPO provides valuable long-term documentation. However, the “text plus flowchart”
nature of the IPO charts makes them difficult to maintain, so the documentation often does not
represent the current state of the program.
By its very nature, the HIPO technique is best used to plan and/or document a hierarchically
structured program.
Inputs and related ideas
During the analysis stage of the system life cycle, the analyst creates logical models using such
tools as data flow diagrams and entity-relationship diagrams. Given those models as a base, the
analyst then identifies several alternative solutions during the high-level system design stage
using such tools as system flow diagrams to document them. The alternatives usually identify, at
a black box level, one or more programs. HIPO is a tool for planning and/or documenting the
programs.
Concepts
A completed HIPO package has two parts. A hierarchy chart is used to represent the top-down
structure of the program. For each module depicted on the hierarchy chart, an IPO (Input-
Process-Output) chart is used to describe the inputs to, the outputs from, and the process
performed by the module.
The hierarchy chart
Table 1 summarizes the primary tasks to be performed by an interactive inventory program.

Figure 1 shows one possible hierarchy chart (or visual table of contents) for that program. Each
box represents one module that can call its subordinates and return control to its higher-level
parent.
A Set of Tasks to Be Performed by an Interactive Inventory Program are:
 Manage inventory  Respond to query

 Update stock  Display status report
 Process sale  Maintain inventory data
 Process return  Modify record
 Process shipment  Add record
 Generate report  Delete record
Date: Dec- 2019/2020

Figure 1 A hierarchy chart for an interactive inventory control program.
At the top of Figure 1 is the main control module, Manage inventory (module 1.0). It accepts a
transaction, determines the transaction type, and calls one of its three subordinates (modules 2.0,
3.0, and 4.0).
Lower-level modules are identified relative to their parent modules; for example, modules 2.1,
2.2, and 2.3 are subordinates of module 2.0, modules 2.1.1, 2.1.2, and 2.1.3 are subordinates of
2.1, and so on. The module names consist of an active verb followed by a subject that suggests
the module’s function.
The objective of the module identifiers is to uniquely identify each module and to indicate its
place in the hierarchy. Some designers use Roman numerals (level I, level II) or letters (level A,
level B) to designate levels. Others prefer a hierarchical numbering scheme; e.g., 1.0 for the first
level; 1.1, 1.2, 1.3 for the second level; and so on. The key is consistency.
The box at the lower-left of Figure 1 is a legend that explains how the arrows on the hierarchy
chart and the IPO charts are to be interpreted. By default, a wide clear arrow represents a data
flow, a wide black arrow represents a control flow, and a narrow arrow indicates a pointer.
Date: Dec- 2019/2020

The IPO charts: An IPO chart is prepared to document each of the modules on the hierarchy
chart.
Overview diagrams
An overview diagram is a high-level IPO chart that summarizes the inputs to, processes or tasks
performed by, and outputs from a module. For example, Figure 2 shows an overview diagram for
process 2.0, Update stock. Where appropriate, system flowcharting symbols are used to identify
the physical devices that generate the inputs and accept the outputs. The processes are typically
described in brief paragraph or sentence form. Arrows show the primary input and output data
flows.
Figure 2 An overview diagram for process 2.0.
Overview diagrams are primarily planning tools. They often do not appear in the completed
documentation package.
Detail diagrams
A detail diagram is a low-level IPO chart that shows how specific input and output data elements
or data structures are linked to specific processes. In effect, the designer integrates a system
flowchart into the overview diagram to show the flow of data and control through the module.
Figure 3 shows a detail diagram for module 2.0, Update stock. The process steps are written in
pseudocode. Note that the first step writes a menu to the user screen and input data (the
transaction type) flows from that screen to step 2. Step 3 is a case structure. Step 4 writes a
transaction complete message to the user screen.
Date: Dec- 2019/2020

The solid black arrows at the top and bottom of the process box show that control flows from
module 1.0 and, upon completion, returns to module 1.0. Within the case structure (step 3) are
other solid black arrows.
Figure 3 A detail diagram for process 2.0.
Following case 0 is a return (to module 1.0). The two-headed black arrows following cases 1, 2,
and 3 represent subroutine calls; the off-page connector symbols (the little home plates) identify
each subroutine’s module number. Note that each subroutine is documented in a separate IPO
chart. Following the default case, the arrow points to an on-page connector symbol numbered 1.
Note the matching on-page connector symbol pointing to the select structure. On-page
connectors are also used to avoid crossing arrows on data flows.
Date: Dec- 2019/2020

Figure 4 A detail diagram for process 2.1.
Often, detailed notes and explanations are written on an extended description that is attached to
each detail diagram. The notes might specify access methods, data types, and so on.
Figure 4 shows a detail diagram for process 2.1. The module writes a template to the user screen,
reads a stock number and a quantity from the screen, uses the stock number as a key to access an
inventory file, and updates the stock on hand. Note that the logic repeats the data entry process if
the stock number does not match an inventory record. A real IPO chart is likely to show the error
response process in greater detail.
Date: Dec- 2019/2020

Data Flow Diagram
Data flow diagram is graphical representation of flow of data in an information system. It is

capable of depicting incoming data flow, outgoing data flow and stored data. The DFD does not
mention anything about how data flows through the system.
There is a prominent difference between DFD and Flowchart. The flowchart depicts flow of
control in program modules. DFDs depict flow of data in the system at various levels. DFD does
not contain any control or branch elements.
Types of DFD
Data Flow Diagrams are either Logical or Physical.
 Logical DFD - This type of DFD concentrates on the system process, and flow of data in
the system. For example in a Banking software system, how data is moved between
different entities.
 Physical DFD - This type of DFD shows how the data flow is actually implemented in
the system. It is more specific and close to the implementation.
DFD Components
DFD can represent Source, destination, storage and flow of data using the following set of
components -
 Entities - Entities are source and destination of information data. Entities are represented
by a rectangle with their respective names.
 Process - Activities and action taken on the data are represented by Circle or Round-
edged rectangles.
 Data Storage - There are two variants of data storage - it can either be represented as a
rectangle with absence of both smaller sides or as an open-sided rectangle with only one
side missing.
 Data Flow - Movement of data is shown by pointed arrows. Data movement is shown
from the base of arrow as its source towards head of the arrow as destination.
Date: Dec- 2019/2020

Levels of DFD
 Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which depicts the
entire information system as one diagram concealing all the underlying details. Level 0
DFDs are also known as context level DFDs.
 Level 1 - The Level 0 DFD is broken down into more specific, Level 1 DFD. Level 1
DFD depicts basic modules in the system and flow of data among various modules. Level
1 DFD also mentions basic processes and sources of information.
 Level 2 - At this level, DFD shows how data flows inside the modules mentioned in
Level 1.
Higher level DFDs can be transformed into more specific lower level DFDs with deeper
level of understanding unless the desired level of specification is achieved.
Date: Dec- 2019/2020


LO 3 Validet The Design

Uploaded by

Document Information

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

LO 3 Validet The Design

Uploaded by

Copyright:

Available Formats

Defense University

Maj. Gen. Mulugeta Buli Polytechnic

LO3: Validate the design

Date: Dec- 2019/2020

Software design is a process to conceptualize the software requirements into software

Structured design is a conceptualization of problem into several well-organized elements of

Cohesion - grouping of all functionally related elements.

Coupling - communication between different modules.

Function Oriented Design

In function-oriented design, the system is comprised of many smaller sub-systems known as

Date: Dec- 2019/2020

Object Oriented Design

Date: Dec- 2019/2020

3.3. Paradigms and models

3.4.1. Entity-Relationship Model

Date: Dec- 2019/2020

Conceptual ER diagram symbols

ERD entity symbols

Date: Dec- 2019/2020

Associative Associative entities relate the instances of several entity types.

ERD relationship symbols

Relationship Symbol Name Description

Weak Weak Relationships are connections between a

ERD attribute symbols

Date: Dec- 2019/2020

Derived attribute Derived attributes are attributes whose value can be

Relationship Relationships are associations between or among entities.

Physical ER diagram symbols

Date: Dec- 2019/2020

Rules for defining Primary key:

Date: Dec- 2019/2020

An ER model is typically drawn at up to three levels of abstraction:

 Conceptual ERD / Conceptual data model

ERD features Conceptual Logical Physical

Conceptual data model

Conceptual data model example

Date: Dec- 2019/2020

Logical data model

Logical ERD is a detailed version of a Conceptual ERD. A logical ER model is developed to

Logical data model example

Physical data model

Date: Dec- 2019/2020

How to draw an ER diagram?

Date: Dec- 2019/2020

Requirement of Data Dictionary

Data dictionary should contain information about the following

Date: Dec- 2019/2020

Data Processing: There are two types of Data Processing:

 Logical: As user sees it

Waterfall SDLC Model

Date: Dec- 2019/2020

Iterative SDLC Model

Date: Dec- 2019/2020

Spiral SDLC Model

Date: Dec- 2019/2020

Agile SDLC Model

Date: Dec- 2019/2020

 Corrections of requirements are  Difficulties with measuring the final cost

Date: Dec- 2019/2020

Inputs and related ideas

The hierarchy chart

Table 1 summarizes the primary tasks to be performed by an interactive inventory program.

A Set of Tasks to Be Performed by an Interactive Inventory Program are: