Tuesday, June 30, 2009
I learned many things in this subject. thus, programming really makes us great. about program design and many more. I aslo want to learn about electronics someday and robotics. I want to share this site foe those who are bold enough to extend the wings feild of TLE.-zero.eight
7:04 AM
FLOWCHARTING
INTRODUCTION
The flowchart is a means of visually presenting the flow of data through an information processing systems, the operations performed within the system and the sequence in which they are performed. In this lesson, we shall concern ourselves with the program flowchart, which describes what operations (and in what sequence) are required to solve a given problem. The program flowchart can be likened to the blueprint of a building. As we know a designer draws a blueprint before starting construction on a building. Similarly, a programmer prefers to draw a flowchart prior to writing a computer program. As in the case of the drawing of a blueprint, the flowchart is drawn according to defined rules and using standard flowchart symbols prescribed by the American National Standard Institute, Inc.
OBJECTIVES
At the end of this lesson, you will be able to understand:
the meaning of flowchart
the basic parts of the flowchart such as flowchart symbols and the flow lines connecting these symbols.
the advantages and limitations of flowchart
MEANING OF A FLOWCHART
A flowchart is a diagrammatic representation that illustrates the sequence of operations to be performed to get the solution of a problem. Flowcharts are generally drawn in the early stages of formulating computer solutions. Flowcharts facilitate communication between programmers and business people. These flowcharts play a vital role in the programming of a problem and are quite helpful in understanding the logic of complicated and lengthy problems. Once the flowchart is drawn, it becomes easy to write the program in any high level language. Often we see how flowcharts are helpful in explaining the program to others. Hence, it is correct to say that a flowchart is a must for the better documentation of a complex program.
GUIDELINES FOR DRAWING A FLOWCHART
Flowcharts are usually drawn using some standard symbols; however, some special symbols can also be developed when required. Some standard symbols, which are frequently required for flowcharting many computer programs are shown in Fig. 25.1
Start or end of the program
Computational steps or processing function of a program
Input or output operation
Decision making and branching
Connector or joining of two parts of program
Magnetic Tape
Magnetic Disk
Off-page connector
Flow line
Annotation
Display
Flowchart Symbols
The following are some guidelines in flowcharting:
In drawing a proper flowchart, all necessary requirements should be listed out in logical order.
The flowchart should be clear, neat and easy to follow. There should not be any room for ambiguity in understanding the flowchart.
The usual direction of the flow of a procedure or system is from left to right or top to bottom.
Only one flow line should come out from a process symbol.
or
Only one flow line should enter a decision symbol, but two or three flow lines, one for each possible answer, should leave the decision symbol.
Only one flow line is used in conjunction with terminal symbol.
Write within standard symbols briefly. As necessary, you can use the annotation symbol to describe data or computational steps more clearly.
If the flowchart becomes complex, it is better to use connector symbols to reduce the number of flow lines. Avoid the intersection of flow lines if you want to make it more effective and better way of communication.
Ensure that the flowchart has a logical start and finish.
It is useful to test the validity of the flowchart by passing through it with a simple test data.
ADVANTAGES OF USING FLOWCHARTS
The benefits of flowcharts are as follows:
Communication: Flowcharts are better way of communicating the logic of a system to all concerned.
Effective analysis: With the help of flowchart, problem can be analysed in more effective way.
Proper documentation: Program flowcharts serve as a good program documentation, which is needed for various purposes.
Efficient Coding: The flowcharts act as a guide or blueprint during the systems analysis and program development phase.
Proper Debugging: The flowchart helps in debugging process.
Efficient Program Maintenance: The maintenance of operating program becomes easy with the help of flowchart. It helps the programmer to put efforts more efficiently on that part
LIMITATIONS OF USING FLOWCHARTS
Complex logic: Sometimes, the program logic is quite complicated. In that case, flowchart becomes complex and clumsy.
Alterations and Modifications: If alterations are required the flowchart may require re-drawing completely.
Reproduction: As the flowchart symbols cannot be typed, reproduction of flowchart becomes a problem.
The essentials of what is done can easily be lost in the technical details of how it is done.
--------------------------------------------------------------------------------
Quiz!
IN-TEXT QUESTIONS 1
Fill in the blank.
A program flowchart indicates the_________ to be per formed and the __________ in which they occur.
A program flowchart is generally read from _____________ to ________________
Flowcharting symbols are connected together by means of ___________________
A decision symbol may be used in determining the ____________ or ___________ of two data items.
__________ are used to join remote portions of a flowchart
____________ connectors are used when a flowchart ends on one page and begins again on other page
A ________ symbol in used at the beginning and end of a flowchart.
The flowchart is one of the best ways of ________ a program..
To construct a flowchart, one must adhere to prescribed symbols provided by the __________ .
The programmed uses a ____________ to aid him in drawing flowchart symbols.
--------------------------------------------------------------------------------
Algorithm Flowcharts are often used to graphically represent algorithms.In mathematics, computing, linguistics, and related subjects, an algorithm is a finite sequence of instructions, an explicit, step-by-step procedure for solving a problem, often used for calculation and data processing. It is formally a type of effective method in which a list of well-defined instructions for completing a task, will when given an initial state, proceed through a well-defined series of successive states, eventually terminating in an end-state. The transition from one state to the next is not necessarily deterministic; some algorithms, known as probabilistic algorithms, incorporate randomness.
Why algorithms are necessary: an informal definition
For a detailed presentation of the various points of view around the definition of "algorithm" see Algorithm characterizations. For examples of simple addition algorithms specified in the detailed manner described in Algorithm characterizations, see Algorithm examples.
While there is no generally accepted formal definition of "algorithm", an informal definition could be "a process that performs some sequence of operations." For some people, a program is only an algorithm if it stops eventually. For others, a program is only an algorithm if it stops before a given number of calculation steps.
A prototypical example of an "algorithm" is Euclid's algorithm to determine the maximum common divisor of two integers (X and Y) which are greater than one: We follow a series of steps: In step i, we divide X by Y and find the remainder, which we call R1. Then we move to step i + 1, where we divide Y by R1, and find the remainder, which we call R2. If R2=0, we stop and say that R1 is the greatest common divisor of X and Y. If not, we continue, until Rn=0. Then Rn-1 is the max common division of X and Y. This procedure is known to stop always and the number of subtractions needed is always smaller than the larger of the two numbers.
Formalization
Algorithms are essential to the way computers process information. Many computer programs contain algorithms that specify the specific instructions a computer should perform (in a specific order) to carry out a specified task, such as calculating employees’ paychecks or printing students’ report cards. Thus, an algorithm can be considered to be any sequence of operations that can be simulated by a Turing-complete system. Authors who assert this thesis include Savage (1987) and Gurevich (2000):
...Turing's informal argument in favor of his thesis justifies a stronger thesis: every algorithm can be simulated by a Turing machine (Gurevich 2000:1)...according to Savage [1987], an algorithm is a computational process defined by a Turing machine. (Gurevich 2000:3)
Typically, when an algorithm is associated with processing information, data is read from an input source, written to an output device, and/or stored for further processing. Stored data is regarded as part of the internal state of the entity performing the algorithm. In practice, the state is stored in one or more data structures.
For any such computational process, the algorithm must be rigorously defined: specified in the way it applies in all possible circumstances that could arise. That is, any conditional steps must be systematically dealt with, case-by-case; the criteria for each case must be clear (and computable).
Because an algorithm is a precise list of precise steps, the order of computation will always be critical to the functioning of the algorithm. Instructions are usually assumed to be listed explicitly, and are described as starting "from the top" and going "down to the bottom", an idea that is described more formally by flow of control.
So far, this discussion of the formalization of an algorithm has assumed the premises of imperative programming. This is the most common conception, and it attempts to describe a task in discrete, "mechanical" means. Unique to this conception of formalized algorithms is the assignment operation, setting the value of a variable. It derives from the intuition of "memory" as a scratchpad. There is an example below of such an assignment.
For some alternate conceptions of what constitutes an algorithm see functional programming and logic programming .
Algorithms can be expressed in many kinds of notation, including natural languages, pseudocode, flowcharts, and programming languages. Natural language expressions of algorithms tend to be verbose and ambiguous, and are rarely used for complex or technical algorithms. Pseudocode and flowcharts are structured ways to express algorithms that avoid many of the ambiguities common in natural language statements, while remaining independent of a particular implementation language. Programming languages are primarily intended for expressing algorithms in a form that can be executed by a computer, but are often used as a way to define or document algorithms.
There is a wide variety of representations possible and one can express a given Turing machine program as a sequence of machine tables (see more at finite state machine and state transition table), as flowcharts (see more at state diagram), or as a form of rudimentary machine code or assembly code called "sets of quadruples" (see more at Turing machine).
Sometimes it is helpful in the description of an algorithm to supplement small "flow charts" (state diagrams) with natural-language and/or arithmetic expressions written inside "block diagrams" to summarize what the "flow charts" are accomplishing.
7:02 AM
Flowcharting-
flowchart is a common type of chart, that represents an algorithm or process, showing the steps as boxes of various kinds, and their order by connecting these with arrows. Flowcharts are used in analyzing, designing, documenting or managing a process or program in various fields.
History The first structured method for documenting process flow, the "flow process chart", was introduced by Frank Gilbreth to members of ASME in 1921 as the presentation “Process Charts—First Steps in Finding the One Best Way”. Gilbreth's tools quickly found their way into industrial engineering curricula. In the early 1930s, an industrial engineer, Allan H. Mogensen began training business people in the use of some of the tools of industrial engineering at his Work Simplification Conferences in Lake Placid, New York.
A 1944 graduate of Mogensen's class, Art Spinanger, took the tools back to Procter and Gamble where he developed their Deliberate Methods Change Program. Another 1944 graduate, Ben S. Graham, Director of Formcraft Engineering at Standard Register Corporation, adapted the flow process chart to information processing with his development of the multi-flow process chart to displays multiple documents and their relationships. In 1947, ASME adopted a symbol set derived from Gilbreth's original work as the ASME Standard for Process Charts by Mishad,Ramsan,Raiaan.
According to Herman Goldstine, he developed flowcharts with John von Neumann at Princeton University in late 1946 and early 1947.[2]
Flowcharts used to be a popular means for describing computer algorithms. They are still used for this purpose; modern techniques such as UML activity diagrams can be considered to be extensions of the flowchart. However, their popularity decreased when, in the 1970s, interactive computer terminals and third-generation programming languages became the common tools of the trade, since algorithms can be expressed much more concisely and readably as source code in such a language. Often, pseudo-code is used, which uses the common idioms of such languages without strictly adhering to the details of a particular one.
Flowchart building blocks
Symbols A typical flowchart from older Computer Science textbooks may have the following kinds of symbols:
Start and end symbols
Represented as lozenges, ovals or rounded rectangles, usually containing the word "Start" or "End", or another phrase signaling the start or end of a process, such as "submit enquiry" or "receive product". Arrows Showing what's called "flow of control" in computer science. An arrow coming from one symbol and ending at another symbol represents that control passes to the symbol the arrow points to. Processing steps
Represented as rectangles. Examples: "Add 1 to X"; "replace identified part"; "save changes" or similar. Input/Output Represented as a parallelogram. Examples: Get X from the user; display X. Conditional or decision
Represented as a diamond (rhombus). These typically contain a Yes/No question or True/False test. This symbol is unique in that it has two arrows coming out of it, usually from the bottom point and right point, one corresponding to Yes or True, and one corresponding to No or False. The arrows should always be labeled. More than two arrows can be used, but this is normally a clear indicator that a complex decision is being taken, in which case it may need to be broken-down further, or replaced with the "pre-defined process" symbol.
A number of other symbols that have less universal currency, such as:
A Document represented as a rectangle with a wavy base;
A Manual input represented by parallelogram, with the top irregularly sloping up from left to right. An example would be to signify data-entry from a form;
A Manual operation represented by a trapezoid with the longest parallel side at the top, to represent an operation or adjustment to process that can only be made manually.
A Data File represented by a cylinder
Flowcharts may contain other symbols, such as connectors, usually represented as circles, to represent converging paths in the flowchart. Circles will have more than one arrow coming into them but only one going out. Some flowcharts may just have an arrow point to another arrow instead. These are useful to represent an iterative process (what in Computer Science is called a loop). A loop may, for example, consist of a connector where control first enters, processing steps, a conditional with one arrow exiting the loop, and one going back to the connector. Off-page connectors are often used to signify a connection to a (part of another) process held on another sheet or screen. It is important to remember to keep these connections logical in order. All processes should flow from top to bottom and left to right.
Examples
A simple flowchart for computing factorial N (N!)A flowchart for computing factorial N (N!) where N! = (1 * 2 * 3 * ... * N). This flowchart represents a "loop and a half" — a situation discussed in introductory programming textbooks that requires either a duplication of a component (to be both inside and outside the loop) or the component to be put inside a branch in the loop.
Types of flowcharts
There are many different types of flowcharts. On the one hand there are different types for different users, such as analysts, designers, engineers, managers, or programmers.[3] On the other hand those flowcharts can represent different types of objects. Sterneckert (2003) divides four more general types of flowcharts:[3]
Document flowcharts, showing a document flow through system
Data flowcharts, showing data flows in a system
System flowcharts showing controls at a physical or resource level
Program flowchart, showing the controls in a program within a system
However there are several of these classifications. For example Andrew Veronis (1978) named three basic types of flowcharts: the system flowchart, the general flowchart, and the detailed flowchart.[4] That same year Marilyn Bohl (1978) stated "in practice, two kinds of flowcharts are used in solution planning: system flowcharts and program flowcharts...".[5] More recently Mark A. Fryman (2001) stated that there are more differences. Decision flowcharts, logic flowcharts, systems flowcharts, product flowcharts, and process flowcharts are "just a few of the different types of flowcharts that are used in business and government.[6]
Software
Manual
Any vector-based drawing program can be used to create flowchart diagrams, but these will have no underlying data model to share data with databases or other programs such as project management systems or spreadsheets. Some tools offer special support for flowchart drawing, e.g., ConceptDraw, SmartDraw, Visio, and OmniGraffle.
Automatic
Many software packages exist that can create flowcharts automatically, either directly from source code, or from a flowchart description language. For example, Graph::Easy, a Perl package, takes a textual description of the graph, and uses the description to generate various output formats including HTML, ASCII or SVG.
6:57 AM
www.kerviiin-oweight.blogspot.com
