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 developer s 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 respondent s 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 1970 s. 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 project s 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. Advantages Disadvantages 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. 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. 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. Abstraction 2. Refinement 3. Modularity 4. Software architecture or structural design 5. Control hierarchy or program module 6. Data structures 7. Software procedures 8. 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 It s 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 1 Function 3 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 elements. It s the representation of the logical relationship among individual data 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