Low Level Design
Uploaded by
sam1_ra9059Low Level Design
Uploaded by
sam1_ra9059Low Level Design
Introduction
Structured design consists of two main activities:
Architectural design (also called high-level design) and detailed design (also
called low-level design).
High-level design involves decomposing the system into modules, and
representing the interfaces and the invocation relationships among the modules. During
detailed design, internals of the individual modules are designed in greater detail (e.g.,
the data structures and algorithms of the modules are designed and documented).
1. Modularization
There are many definitions of the term module. They range from “a module is a
FORTRAN subroutine” to “a module is an ADA package” to “a module is a work
assignment for an individual programmer.”All of these definitions are correct, in the
sense that modular systems incorporate collections of abstractions in which each
functional abstraction, each data abstraction, and each control abstraction handles a
local aspect of the problem being solved. Modular system consists of well-defined,
manageable units with well-defined interfaces among the units
Desirable Properties of modular systems include
• Each function in each abstraction has a single, well-defined purpose.
• Each function manipulates no more than one major data structure.
• Functions share global data selectively. It is easy to identify all routines
that share a major data structure.
• Functions that manipulate instances of abstract data types are encapsulated
with the data structure being manipulated.
What for Modularization?
Modularity enhances design clarity, which in turn eases implementation, debugging,
testing, documenting, and maintenance of the software product.
Modules that may be created during program modularizations are:
Process support modules: In these all the functions and data items that are
required to support a particular business process are grouped together.
Data abstraction modules: These are abstract types that are created by
associating data with processing components.
Functional modules: In these all the functions that carry out similar or
Closely related tasks are grouped together.
Hardware modules: In these all the functions, which control particular
Hardware are grouped together.
Advantages of Modular Systems
1. Modular systems are easier to understand and explain because their parts are
functionally independent.
2. Modular systems are easier to document because each part can be documented
as an independent unit.
3. Programming individual modules is easier because the programmer can focus
on just one small, simple problem rather than a large complex problem.
4. Testing and debugging individual modules is easier because they can be dealt
with in isolation from the rest of the program.
5. Bugs are easier to isolate and understand, and they can be fixed without fear
of introducing problems outside the module.
6. Well-composed modules are more reusable because they are more likely to
comprise part of a solution to many problems. Also, a good module should be
easy to extract from one program and insert into another.
Modularity is an important property of most engineering processes and products. For
example, in the automobile industry, the construction of cars proceeds by assembling
building blocks that are designed and built separately. Furthermore, parts are often
reused from model to model, perhaps after minor changes. Most industrial processes
are essentially modular, made out of work packages that are combined in simple ways
(sequentially or overlapping) to achieve the desired result.
2. Structure Charts
Structure charts are used during architectural design to document hierarchical
structures, parameters, and interconnections in a system.
It partitions a system into black boxes. A black box means that functionality is known to
the user without the knowledge of internal design. Inputs are given to a black box and
appropriate outputs are generated by the black box. This concept reduces complexity
because details are hidden from those who have no need or desire to know. Thus,
systems are easy to construct and easy to maintain. Here, black boxes are arranged in
hierarchical format as shown below.
Hierarchical Format of a Structure Chart
Modules at the top level call the modules at the lower level. The connections between
modules are represented by lines between the rectangular boxes. The components are
generally read from top to bottom, left to right. Modules are numbered in a hierarchical
numbering scheme. In any structure chart there is one and only one module at the top
called the root.
Basic Building Blocks of a Structure Chart
The basic building blocks of a structure chart are the following:
1. Rectangular Boxes. A rectangular box represents a module. Usually a
rectangular box is annotated with the name of the module it represents.
2. Arrows. An arrow connecting two modules implies that during program
execution, control is passed from one module to the other in the direction of
the connecting arrow.
3. Data-flow Arrows. Data-flow arrows represent that the named data passes
from one module to the other in the direction of the arrow.
4. Library Modules. Library modules are the frequently called modules and are
usually represented by a rectangle with double edges. Usually when a module
is invoked by many other modules, it is made into a library module.
5. Selection. The diamond symbol represents that one module out of several
modules connected with the diamond symbol are invoked depending on the
condition satisfied, which is written in the diamond symbol.
6. Repetitions. A loop around the control-flow arrows denotes that the respective
modules are invoked repeatedly.
Example 5.1. A software system called RMS calculating software reads
three integral numbers from the user in the range between –1000 and +1000 and
determines the root mean square (rms) of the three input numbers and then
displays it.
FIGURE 5.9 Structure Chart For Example 5.1
3.Pseudo-Code
“Pseudo” means imitation or false and “code” refers to the instructions written in a
programming language. Pseudo-code notation can be used in both the preliminary
and detailed design phases.
Advantages of Pseudo-Code
The various advantages of pseudo-code are as follows:
• Converting a pseudo-code to a programming language is much easier compared
to converting a flowchart or decision table.
• Compared to a flowchart, it is easier to modify the pseudo-code of program
logic whenever program modifications are necessary.
• Writing of pseudo-code involves much less time and effort than the equivalent
flowchart.
• Pseudo-code is easier to write than writing a program in a programming
language because pseudo-code as a method has only a few rules to follow.
Disadvantages of Pseudo-Code
The various disadvantages of pseudo-code are as follows:
• In the case of pseudo-code, a graphic representation of program logic is not
available as with flowcharts.
• There are no standard rules to follow in using pseudo-code. Different
programmers use their own style of writing pseudo-code and hence
communication problems occur due to lack of standardization.
• For a beginner, it is more difficult to follow the logic or write the pseudo-code
as compared to flowcharting.
Examples
INITIALIZE tables and counters; OPEN files
READ the first text record
WHILE there are more text records DO
WHILE there are more words in the text record DO
EXTRACT the next word
4. Flowcharts
A flowchart is a convenient technique to represent the flow of control in a program. A
flowchart is a pictorial representation of an algorithm that uses symbols to show the
operations and decisions to be followed by a computer in solving a problem. The actual
instructions are written within symbols/boxes using clear statements. These boxes are
connected by solid lines having arrow marks to indicate the flow of operation in a
sequence.
In fact, flowcharts are the plan to be followed when the program is written. Expert
programmers may write programs without drawing the flowcharts. But for a beginner it is
recommended that a flowchart should be drawn before writing a program, which in turn
will reduce the number of errors and omissions
Difference between Flowcharts and Structure Charts
A structure chart differs from a flowchart in the following ways:
• It is usually difficult to identify different modules of the software from its
flowchart representation.
• Data interchange among different modules is not represented in a flowchart.
• Sequential ordering of tasks inherent in a flowchart is suppressed in a structure
chart.
• A structure chart has no decision boxes.
• Unlike flowcharts, structure charts show how different modules within a
program interact and the data that is passed between them.
Thank you
