Fourth generation techniques (4GT)

The term fourth generation techniques (4GT) encompasses a broad array of software tools
that have one thing in common. Each enables the software engineer to specify some
characteristic of software at a high level, the tool then automatically generates source code
based on the developers specification.
The 4GT paradigm for software engineering focuses on the ability to specify software using
specialized language forms or a graphic notation that describes the problem to be solved in
terms that the customer can understand.
Currently, a software development environment that supports the 4GT paradigm includes some
or all of the following tools:

Non-procedural languages for database query

Report generation
Data manipulation
Screen interaction
Definition & code generation; high-level graphics capability
Spreadsheet capability

Like other paradigms, 4GT begins with a requirements gathering step, the customer would
describe requirements and these would be directly translated into an operational prototype.
Advantages
Simplified the programming process.
Use non-procedural languages that encourage users and programmers to specify
the results they want, while the computers determines the sequence of
instruction that will accomplish those results.
Use natural languages that impose no rigid grammatical rules.
Disadvantages
Less flexible that other languages
Programs written in 4GLs are generally far less efficient during program
execution that programs in high-level languages. Therefore, their use is limited
to projects that do not call for such efficiency.

 Questionnaires
Questionnaires are a further method of information gathering where the
potential users of the system are given questionnaires to be filled up and
returned to the analyst.
Questionnaires are special purpose documents that allow the analyst to collect
information and opinions from respondents.
Questionnaires are defined by Dibb Base document for research purposes,
providing the question and structure for an interview or self completion and
providing space for respondents answers.
Marshall said Questionnaires can help you collect information about what
people do, what they have, what they think, know, feel or want. Using this
technique we gather facts about the existing system from number of persons.
Types of Questionnaires
1. Structured
In structured questionnaires, respondent needs to select from possible options for
answers and thus the range of answers is limited. Examples of structured questionnaires
are- multiple choice, selection or ranking scale, selection of a rating and fill in the blanks.
2. Unstructured
In such method, respondents are made to answer freely. Such questions are open
ended. An open ended questionnaire just includes a question and has a sufficient space
for an unstructured reply.
Advantages
Questionnaires are considered as an economical way of collecting facts from a
huge number of people.
If it is well formatted and designed, then the results can be easily analyzed and
computerized.
Respondents get time to think over the questions and provide more accurate
data.
Disadvantages
Good questionnaires are difficult to construct.

Record review (recording outcome)

Records and reports are the gathering of information and collected over the time by the
users about the system and its operations.
For better understanding of any existing system is to review its operations. For better
understanding of any existing system is to reviewing of existing records or record
review.
It starts at the preliminary stage of the system study or later on in the study for
measuring actual operations with what the records indicate.
Records and reports may have a limitation if they are not up-to-date or if some essential
links are missing. All the changes, which the system suffers, may not be recorded.

Observations / site visit

Another information gathering technique used by the system analyst is known as on site
observation or direct observation, where the analyst personally goes to the site and
discovers the functioning of the system.
As an observer, the analyst can gain direct knowledge of the activities, operations,
processes of the system on-site; hence here the role of an analyst is of an information
seeker.
This technique is useful when on needs to actually observe how documents are handled,
how operations and activities are carried out.
Advantages

Facts gathered using this technique is highly reliable.

Inexpensive way of collecting data.
Using this technique, the system analyst can make out tasks that have been
missing or wrongly illustrated by other fact finding techniques.

Disadvantages
This technique is too time-consuming and the analyst should not jump to conclusions or
draw assumption from minute samples of observation rather the analyst should be more
patient in gathering the information.

Joint application development (JAD)

Joint application development (JAD) was developed by Chuck Morris of IBM Raleigh and
Tony Crawford of IBM Toronto in the late 1970s. in instance, JAD developed and gained
general approval in the data processing industry.
Originally, JAD was designed to bring system developers and users of varying
backgrounds and opinions together in a productive and creative environment.
The structured approach provides a good alternative to traditional serial interviews by
system analysts.
JAD is a technique that allows the developments, management, and customer groups to
work jointly to build a product.
It is a series of highly structured interviewed sessions aimed at reaching consensus on a
projects goal and scope. A typical JAD project is from 3 to 6 months.
JAD concept is based on 4 ideas
The users who do the job have the best understanding of that job.
The developers have the best understanding of how technology works.
The business process and the software development process work the same basic
way.
The best software comes out of a process that all groups work as equals and as one.
Advantages
JAD actively involves users and management in the development project.
JAD helps to avoid the requirements from being too specific and too vague, both
of which cause trouble during implementation and acceptance.
JAD reduces the amount of time required to develop systems since it eliminates
process delays and misunderstandings and improves system quality.
Disadvantages
Slow communication and long feedback time.
Weak or no support from upper management.
Bad documentation.

FAST: Facilitated application specification technique

(FAST) is an important technique for requirements elicitation.
FAST is a technique for gathering requirements during early stages of analysis and
specification.
The main objective of this technique is to cover the gap between what the developers
think they are going to design and what customers believe they will receive from the
particular program.
This is a team oriented approach for requirement gathering.
Basic guidelines
Meeting is conducted at a neutral site and attending by both software
engineer and customer
Rule for preparation and participation are established
An agenda is suggested that is formal enough to cover all important points
but informal enough to encourage the free flow of ideas
A facilitator controls the meeting
A definition mechanism is used
The main goal is to identify the problem, purpose element of the solution,
negotiate different approaches and specify a preliminary set of software
requirements in an atmosphere that is conductive to accomplish the goal.
Representatives of FAST
Marketing person
Software and hardware engineer
Representative from manufacturing
An outside facilitator

Software design concepts

Following are software design or system design concepts:
1.
2.
3.
4.
5.
6.
7.
8.

Abstraction
Refinement
Modularity
Software architecture or structural design
Control hierarchy or program module
Data structures
Software procedures
Information hiding

1.Abstraction
Abstraction let a designer to focus on solving a dilemma (problem) without
being concerned about immaterial (irrelevant) lower level details. In other words, abstraction is
closing the eyes (ignoring) to insignificant facts and focusing on key attributes.
Abstraction is the act of representing essential features without including
the background details or explanations. In the computer science and software engineering
domain, the abstraction principle is used to reduce complexity and allow efficient design and
implementation of complex software systems.
Types of abstraction:
1] Procedural abstraction
A procedural abstraction is a named sequence of instructions that has a
precise (exact) and limited function. An example of a procedural abstraction would be the word
open for a door. Open implies a long sequence of procedural steps (e.g., walk to the door, reach
out and grasp knob, turn knob and pull door, step away from moving door, etc..)
2] Data abstraction
A data abstraction is a named collection of data that describes a data object.
In the framework of the procedural open noted above, we can identify a data abstraction called

door. For example, the data object door includes a set of characteristics (door type, door
dimension) that depict the door object clearly. In this abstraction mechanism, representation
and manipulation details are ignored.

3] control abstraction
The third form of abstraction is the control abstraction. Like procedural and
data abstraction, control abstraction implies a program control mechanism without specifying
internal details.

2.Refinement
Its the course of elaboration (explanation) where the designer provides consecutively
(successively) more detail for each design component.
Stepwise refinement is a top-down design strategy originally proposed by Niklaus wirth.
A program is developed by successively refining levels of procedural detail.
LEVEL 1- SYSTEM representing the overall product to be built.
LEVEL 2 SUB-SYSTEMS representing the business processes associated with the
system (one or more).
LEVEL 3 PROCEDURES representing the work flow of each sub-system. There are
essential two types of procedures; Administrative representing procedures executed
by humans; and computer.
LEVEL 4 PROGRAMS representing the programs needed to execute each computer
procedure.
Under stepwise refinement the levels are decomposed top-down during the design process,
and implemented bottom-up; a common engineering/ manufacturing technique.

3. Modularity
A module is a named entity that:

Contains instructions, processing logic, and data structures.

Can be separately compiled and stored in a library.
Can be included in a program.
Module segments can be used by invoking a name and some parameters.
Modules can use other modules.

Modularity is the scale (degree) to which software can be understood by examining its
components independently of one another.

Modularity concept provides the advantages such as:

To plan the growth of software in a more successful manner.

Put up change easily.
Conduct testing and debugging efficiently and proficiently.
Conduct maintenance work without harmfully affecting the execution of the
software.

Myer defines five criteria that permit us to assess a design method with
respect to its ability to define an effective modular system:

Modular decomposability: if the design technique imparts an organized means for

breaking problem into sub problems, it will decrease the complexity of the overall
problem.
Modular compos ability: if the design technique facilitates existing design components
to be assembled into a new system, it will give up a modular solution that does not
reinvent the wheel.
Modular understandability: if a module can be understood as a standalone unit without
reference to other module it will be easier to put up and easier to change.
Modular continuity: if small changes to the system requirements consequence in
changes to individual module, rather than system wide changes, the impact of change
induced side effects will be minimized.
Modular protection: if an unusual state crop up within a module and its effects are
constrained within that module, then impact of error induced side effects are
minimizes.

4. Software architecture (structural design)

Software architecture also called structural design is a sketchy map of the system.
In other terminology, structural design is the hierarchical construction of program modules, the
mode in which these modules act together, and the structure of the data that are used by the
modules.

The Goal of Architecture

The purpose of architecture is to make out the requirements that influence the structure of the
application.

Expose the structure of the system but hide the implementation details.
Realize all of the use cases and scenarios.
Try to address the requirements of various stakeholders.
Handle both functional and quality requirements.

5. Control hierarchy or program module

Correspond to the module organization and implies a control hierarchy, but does not represent
the procedural aspects of the software. The control relationship amongst modules is articulated
in the following means:
1] A module that controls another module is said to be super ordinate to it and
2] A module controlled by another is said to be subordinate to the controlled.
Structural partitioning
Structural partitioning is achieved while following hierarchical nature in
architectural design. The construction (structure) of a program can be partitioned into two
ways:

Horizontal partitioning
Vertical partitioning

Function 3

Function 1

Function 2

Figure (a- Horizontal partitioning)

Control module (Decision
making modules)

Worker
modules

Figure (b- Vertical partitioning)

In horizontal partitioning the control modules (as described in the shaded

boxes in figure) are used to co-ordinate communication between and execution of the
functions. Horizontal partitioning characterizes separate branches of the modular hierarchy for
each major program function. Simplest way is to partition a system into: input, data
transformation (processing), and output.
Advantages

Easy to test, maintain, and extend.

Fewer side effects in change propagation or error propagation.

Disadvantage

More data to be passed across module interfaces.

Make difficult the overall control of program flow.

Vertical partitioning suggests the control and work should be distributed

top-down in program structure. In vertical partitioning the control (decision making) modules
are located at the top, and work is distributed top-down in the program structure. That is, top
level modules perform control functions and do little actual processing, while modules that are
low in the structure performs all input, computation and output tasks.
Advantages

Excellent at dealing with changes.

Easy to sustain the changes.
Lessen the change impact and propagation.

6. Data structure
Its the representation of the logical relationship among individual data
elements.

7. Software procedures

The principles and procedures to be used to conduct design and

development activities, including the following.
The design and development processes to be pursue together with assignment of tasks,
techniques to be used.
Procedures for preparing unit test plans and conducting test.

8. Information hiding
Information hiding is conceivably the most significant intellectual instrument developed to hold
software design. Modules should be designed as well as specified in such an approach that
information enclosed within one module is inaccessible to other modules that do not require
such information.

Effective Modular Design

A module is a logically separable part of a program. It is a program unit that is discreet and
identifiable with respect to compiling and loading. In terms of common programming language
constructs, a module can be a macro, a function, a procedure (or subroutine), a process, or a
package. In systems using functional abstraction, a module is usually a procedure of function or
a collection of these.
To produce modular designs, some criteria must be used to select modules so that the modules
support well-defined abstractions and are solvable and modifiable separately. In a system using
functional abstraction, coupling and cohesion are two modularization criteria, which are often
used together.

Function Independence
The concept of functional independence is a direct outgrowth of modularity and the
concepts of abstraction and information hiding.
Functional independence is achieved by developing modules with single-minded
function and an aversion to excessive interaction with other modules. Stated another
way, we want to design software so that each module addresses a specific sub-function
of requirements and has a simple interface, when viewed from other parts of the
program structure. It is fair to ask, why independence is important. Software with
effective modularity, that is, independent modules, is easier to develop because
functions may be compartmentalized and interfaces are simplified (consider the
ramifications when development is conducted by a team). Independent modules are
easier to maintain (and test) because secondary effects caused by design or code
modification are limited, error propagation is reduced, and reusable modules are
possible. To summarize, functional independence is a key to good design, and design is
the key to software quality.
Cohesion
Coupling