Flowcharting, pseudocoding, and process designdocshare01.docshare.tips/files/31039/310395325.pdf · demonstrated, the project goes to the next level – in-house staff. This diagram

Systems Analysis Pseudocoding & Flowcharting 1

/Users/gbenoit/Documents/LIS486 - Systems Analysis/Spring2013/InfoSystemsDesign-FlowCharting.rtf 12/30/12 7:41 PM

Flowcharting, pseudocoding, and process design

The purpose of “flowcharts” is to represent graphically the logical decisions and progression of steps

in the physical completion of a task. As such, flowcharts are the lowest level of decomposition. The

flowchart specifies the order in which tasks are performed. As such anyone who knows about the function

can recognize immediately changes to the actual performance of work. Since here the logic of the work is

tested, it is here the analyst identifies and documents changes to the physical work flow of people or the

design of a computer program.

In a large system the flow charting steps may be complex and the analyst may opt to represent the

system with algebra, structured English or pseudocode, or some type of decision tree or decision table.

When describing a complicated system to others it may be useful to use hierarchy charts or structure charts

[described later]. But for the information systems analysis, the best options are flow charts and pseudocod-

ing/Structured English. [Note that some authors see pseudocoding as a separating activity from Structured

English, others see the two as the same function with different names.]

Before beginning the flow charts, the analyst must have a complete understanding of the entire

process and participants (context level), the subroutines and their interdependencies (level-n diagrams), the

data (data dictionary, inputs/outputs) and transformation of data (DFDs). The flow chart documents the

flow of logic, control and the actual data through a routine or procedure. These activity completes the

logical part of analysis.

From here we proceed to integrate the whole decomposed process into something new - the revised,

more efficient and effective system. After flowcharting, we examine how the pieces fit back together and

express this in a system flowchart. [Don’t confuse the two types of flowcharting - the system flowchart repre-

sents the physical system; the flowcharting at the end of process decomposition represents the logical (think

“virtual”) system.]

Symbol set

There are seven commonly used symbols in flowcharting. However, be aware that people can create

their own symbol set and many software products designed to help manage systems analysis have blurred the

line between activities, using the same types of symbols for all aspects of analysis. We’ll consider those com-

mon symbols because they represent the main concepts.

1. Terminator: marks the beginning and end of a flowchart

2. Process: indicates that an operation changed or manipulated the data in some way

3. Data or input/output: an operation that inputs or outputs data

4. Decision: a logical decision point (e.g., if, then; true/false)

5. On-page connector: the logic continues at another place on the same page

6. Off-page connector: the logic continues on a different page



7. Predefined process: a predefined process or subroutine (similar to a predefined function or process

in database programming).

As a general rule, a flowchart has a single entry and exit point. In procedural programming (such as Perl 4),

it is fairly easy to create such charts. Object oriented programming, on the other hand, can become com-

pleted very quickly and using single-entry, single-exit logic may be difficult, at times impossible. As a conse-

quence, another kind of language has developed, Uniform Modeling Language (UML).

Program logic has three patterns: sequence, decision, and repetition.

Sequence:

A decision block implies IF-THEN-ELSE. A condition (“it’s the case that something is true …”, or

“while x is true …”) is tested: if the condition is true, the logic associated with the “THEN” branch is per-

formed while the ELSE block is skipped. If the condition is false, then the ELSE logic is executed and the

THEN logic is skipped. For example, “IF there’s enough gas in the car (condition), THEN (true) I’ll drive

to my friends’ house; ELSE (false, not enough gas) I’ll go to the gas station.

Sometimes the if/then are nested in other if/then conditions: If there’s enough gas in the car, I’ll

go to my friend’s house; if I don’t reach there by noon, I’ll stop at a restaurant along the way.



Repetitive Logic:



There are two main patterns for repetitive logic: DO WHILE and DO UNTIL.

In the first case (do while), the test is performed first and the associated instructions are performed

only if (while) the test condition is true. Example: while there are still papers to read, I’ll grade them.

DO UNTIL case the opposite is true: the associated instructions are executed first and then the

condition is tested (this means the function is be performed at least once): “UNTIL I’ve finished grading,

I’ll keep reading papers.”

Modules

Flowcharting symbols can be applied to manual processes – how a person completes a task – or to a

computerized function – as a precursor to writing the program. The analyst must often add information to

make a process comprehensible to humans or to machines. For example, the idea of gathering data or mate-

rials before beginning a process may not be obvious at first. In this example, a person is calculating the

average of student scores on a quiz. Imagine yourself doing the task. In this first iteration, the main func-

tions are identified:

1. Write down the score for each student’s quiz

2. Add the score to the running total

3. Count the number of assignments

4. Divide the running total by the number of assignments

So far, so good. But a computer needs to be told much more:

1. Start the process of averaging student scores

2. Are the quizzes available?

a. If not, get them

b. If so, process

3. Running score = 0

4. Number of quizzes processed = 0;

5. while there are quizzes to process

a. get the score from this quiz

b. add the score to Running score

c. add 1 to the number of quizzes processed

6. Divide the Running score by the Number of quizzes processed

7. Store the answer

8. End the process



Since flowcharts are a graphic representation of the steps, the sequence is indicated by arrows. But in a

complicated flowchart, it can be difficult to understand if the directional arrows cross each others. In that

case, try to rearrange the elements so the visual flow from top left to bottom right is not hampered by cross-

ing lines or use on-page connections (in numbered pairs). For instance, if the logic flows into a small circle

marked “3”, look for another small circle marked with “3” and a flowline that rejoins the flowchart at an-

other point (similar to what you did for process decomposition). The same with Off-page connectors.

Note, though, that if there are many off-page connectors, the flowchart is probably too big. In this case,

reconsider the modularization: can you identify redundant processes or processes whose level of granularity

is inconsistent with others on the chart? In this situation, you may prefer a different charting technique.

Here is an example of using a decision tree. In the first example, there are three decisions. The first decision

(if then…) point is whether the organization can afford to buy a new system. We see that if the decision is

not to buy the system, then the cost is $0. If the decision is to purchase a new system, then notice how the



next decision point suggests that if the organization reaches its goals, it will earn $1,000,000. But if the

goals aren’t reached, then the company can lose $500,000.

In this next example, a company performs a feasibility study. If the company owners believe the need is

demonstrated, the project goes to the next level – in-house staff. This diagram suggests that the company is

willing to spent up to $100,000 for retraining of existing staff, but is unwilling to hire new staff (probably

because the cost of hiring, training new staff). If the cost of in-house staff retraining is approved, the compa-

ny asks whether there is sufficient available network capacity for its computers. Here again if there capacity

is available, they proceed to build a new system. [Naturally, there are many more steps involved, such as

projecting how long and how much traffic the network can sustain before reaching capacity, etc.]



Pseudocoding

The purpose of pseudocoding is to be an approachable bridge between the logic of the design and

the physical creation of a new system. Pseudocoding might be considered the textual equivalent of

flowcharting and is useful for explaining logic models to people who shy from anything that looks technical.

The advantage, too, of pseudocoding that if performed fully and accurately a computer programmer can

translate the Structured English directly to computer code.

Creating pseudocode is a useful step outside systems analysis: if the analyst can describe orally the

steps involved, including logical dependencies, then s/he can explain the new system to any audience and

will identify logical problems before they are manifested in the design.

A word of warning: programmers may resist pseudocode that dictates how to solve the problem.

The programmer needs to understand the logic and should not have to guess what the analyst means. On

the other hand, if the analyst dictates the data structures to be used (e.g., use a hash here, an array there, or

try this enumeration…) then the programmer’s ability to create a viable program is impacted. [Let the pro-

grammer determine the best way for the machine to handle the data.]

In the flowcharting examples above, we included two variables “Running score” and “Number of

quizzes processed.” Such techniques are useful: e.g., count = 0; takehomePay = grossPay – taxes – Fica –

401K – dental – medical + bonus. The names of the data are taken from the data dictionary.

Input and output instructions are de!ned explicitly in the pseudocode:READ data FROM source

AndWRITE data TO destinationWhere data refers to a list of variables, a data structure, or a record and source and destination refer to

a file or database [these are the sources/sinks that you identified early on].

Blocks of logic:

Note that many processes that are repeated or complicated may be defined by another analyst, pro-

grammer, or may come from a library of programming routines. In this situation, the analyst may refer to

the whole set of instructions as a single block. For example, say you’re defining the processes that the first

person in the office performs every day. These include

Turn on the lights

Turn on the photocopier

Turn on the air conditioner

Turn on the computers

Read and reply to emergency emails

Unlock the front door

Turn the sign in the window from “closed, come again!” to “We’re Open!”



Instead of writing these steps down every time, you could group them under the label “Open the

Store”. Then when defining the work process for many new employees, you could just refer to the above as

“Open the store.” You can pass “parameters” to a block of instructions without changing the block. For

example, in the above “turn on air conditioning”, you might say PERFORM Open the Store USING sum-

mer or PERFORM Open the Store USING winter. In the first case, the A/C is turned to cool; in the

latter, it is turned to heat.

For computing, it is the same process. Say you need a random number generator. You could iden-

tify a block of instructions and call them collectively “randomizer”. Then in the pseudocoding you can call

the entire set of instructions by referring only to the block “randomizer”:

PERFORM randomizer

In this example, say you want to randomizer process to go no lower than a certain number (let’s say

0) and no greater than another number (say 100). Here, then, you might say PERFORM randomizer US-

ING RANGE 0, 100.

Here’s are a few examples:

If…then

IF condition IF hours_worked > 40THEN THEN

PERFORM block-1 PERFORM overtime_payELSE ELSE

PERFORM block-2 PERFORM regular_payENDIF ENDIF

Nested ifIF condition-1

THENIF condition-2

THENPERFORM block-a

ELSEPERFORM block-b

ENDIFENDIF

ELSEPERFORM block-c

ENDIF

DO WHILEWHILE condition DO

PERFORM blockENDWHILE



REPEAT UNTILREPEAT

PERFORM blockUNTIL condition

DO … TODO (index = initial value TO limit) for (int i = 0; i < 100; i++) {

PERFORM block perform_block();ENDDO }

This for … statement is very common. The “int” means “integer”; the letter i is commonly used as the name

of a variable that is of type integer. In the above statement we see that the variable i has been set to equal 0.

The next part (i < 100) means “as long as the value in i is less than 100, do whatever is in “perform_block()”.

Once the block has been performed, the value of i is increased by 1 (this is what i++ means. Take the value

of i and add 1. If you want to add more than one, for example, you want to increase the value of i five times

for every time the “perform_block()” is completed, you can write i += 5.

The “if…then” statements are not very efficient from a computer’s perspective. Although you, the

analyst, may say “If …” in your design, the programmer may select more efficient techniques. [Of course, the

analyst can also specify them.]

Here is a better example when there are many nested if statements or when the number of if op-

tions is greater than three. [This is a rule of thumb, not carved into stone.]

Say we have a variable “userLevel” that determines what happens when someone logs into an infor-

mation system. Regular staff users of some computer system are assigned a value of 0; the managers are

assigned a value of 1; the administrators are assigned “2”, the technical staff “3.” If someone doesn’t have a

value assigned, it means they’re a general, public user (say of a patron using an OPAC). If anyone of those

levels logs into the system, we want the system to perform different functions. For example, the staff and

other people should not have access to certain database functions, while the tech staff does need such

access. We use the select statement:

Model ExampleSELECT variable SELECT userLevel ;

CASE (value-0) CASE 0:Login USING staff staffLogin(); break;

CASE (value-1) CASE 1:Login USING manager managerLogin(); break;

CASE (value-2) CASE 2:Login USING admin adminLogin(); break;

CASE (value-3) CASE 3:Login USING tech techStaffLogin(); break;

DEFAULT DEFAULT:Login USING public publicUserLogin(); break;



ENDSELECT

[We add a “break;” statement so the case statement stops and we jump out of the select statement block.]

——————————————————————————————————————————————————————

Action Diagram

In passing we should note that another form of diagramming is called Action Diagrams. We will

not include here now Action Diagrams demonstrate logic, but will use an example to suggest how diagrams

can help design physical functions (such as menu design). In this example, the purpose is to suggest how

the menu function might work. We can imagine this same function being applied to web page design. The

first diagram has major functions (which were extracted from the Level-1 diagram). The second diagram

suggests how logic can be integrated. [We won’t pursue this in class in detail, but it is a helpful tool when

working with “Information Architects” and people who do not know about systems analysis.





Object Oriented Techniques

Software and work processes today are “object-oriented.” [A description of the object model will

follow later.]

Below is an example of object oriented processes being applied to a work process (student registra-

tion process) and then an example of software designed using objects.

Try to read this chart. Starting with the first block (Registrar) we read it as “One Registrar com-

pletes many (*) course registrations.” When a course registration is complete, a student receives a copy. The

student can enroll in multiple courses (*). Each course’s tuition is paid individually. Payment may be by

the student or by a scholarship.

A course must exist (the black diamond) in order to be enrolled in. A single course registration (1)

has at least one (1..) to many (*) classes.

Enrolling in a class reduces the available seats or registrations by 1. Each class is described by a

single class description.



Finally, an object is supposed to reflect conceptually things in the real world by identifying the properties of

the object and what actions an object can perform. For example, a “ball” object has the property of circum-

ference, color, and can be bounced. We might, then, create an objectd called “ball”:

Object: ball

Properites: circumference

color

tennisball

Actions: bounce()

"is describes all balls. To describe our own tennisball, we “instantiate” the “ball object” or bor‐row the properties of all balls and apply them to our tennisball.

Ball myTennisball

Because we borrow the ball object, we inherit all the ball object’s abilities. To say “the color of my tennisball is orange” can be represented as myTennisball.color = orange.

Above is an example of the “student enrollment process”, expressed as an object oriented conceptual model. Following the model is an expression of the actual object classes. "e object class diagram is used by programmers to create the digital objects used in the program.



