Systems Analysis
Pseudocoding & Flowcharting
1
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 pseudocoding/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 represents 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 common 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
/Users/gbenoit/Documents/LIS486 - Systems Analysis/Spring2013/InfoSystemsDesign-FlowCharting.rtf 12/30/12 7:41 PM
Systems Analysis
7.
Pseudocoding & Flowcharting
2
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 completed very quickly and using single-entry, single-exit logic may be difficult, at times impossible. As a consequence, 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 performed 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.
/Users/gbenoit/Documents/LIS486 - Systems Analysis/Spring2013/InfoSystemsDesign-FlowCharting.rtf 12/30/12 7:41 PM
Systems Analysis
Pseudocoding & Flowcharting
Repetitive Logic:
/Users/gbenoit/Documents/LIS486 - Systems Analysis/Spring2013/InfoSystemsDesign-FlowCharting.rtf 12/30/12 7:41 PM
3
Systems Analysis
Pseudocoding & Flowcharting
4
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 materials 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 functions 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
/Users/gbenoit/Documents/LIS486 - Systems Analysis/Spring2013/InfoSystemsDesign-FlowCharting.rtf 12/30/12 7:41 PM
Systems Analysis
Pseudocoding & Flowcharting
5
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 crossing 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 another 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
/Users/gbenoit/Documents/LIS486 - Systems Analysis/Spring2013/InfoSystemsDesign-FlowCharting.rtf 12/30/12 7:41 PM
Systems Analysis
Pseudocoding & Flowcharting
6
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 company 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.]
/Users/gbenoit/Documents/LIS486 - Systems Analysis/Spring2013/InfoSystemsDesign-FlowCharting.rtf 12/30/12 7:41 PM
Systems Analysis
Pseudocoding & Flowcharting
7
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 programmer 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 defined explicitly in the pseudocode:
READ data FROM source
And
WRITE data TO destination
Where 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, programmer, 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!”
/Users/gbenoit/Documents/LIS486 - Systems Analysis/Spring2013/InfoSystemsDesign-FlowCharting.rtf 12/30/12 7:41 PM
Systems Analysis
Pseudocoding & Flowcharting
8
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 summer 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 identify 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 USING RANGE 0, 100.
Here’s are a few examples:
If…then
IF condition
THEN
PERFORM block-1
ELSE
PERFORM block-2
ENDIF
IF hours_worked > 40
THEN
PERFORM overtime_pay
ELSE
PERFORM regular_pay
ENDIF
Nested if
IF condition-1
THEN
IF condition-2
THEN
PERFORM block-a
ELSE
PERFORM block-b
ENDIF
ENDIF
ELSE
PERFORM block-c
ENDIF
DO WHILE
WHILE condition DO
PERFORM block
ENDWHILE
/Users/gbenoit/Documents/LIS486 - Systems Analysis/Spring2013/InfoSystemsDesign-FlowCharting.rtf 12/30/12 7:41 PM
Systems Analysis
Pseudocoding & Flowcharting
9
REPEAT UNTIL
REPEAT
PERFORM block
UNTIL condition
DO … TO
DO (index = initial value TO limit)
PERFORM block
ENDDO
for (int i = 0; i < 100; i++) {
perform_block();
}
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 options 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 information 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
Example
SELECT variable
CASE (value-0)
Login USING
CASE (value-1)
Login USING
CASE (value-2)
Login USING
CASE (value-3)
Login USING
DEFAULT
Login USING
SELECT userLevel ;
CASE 0:
staffLogin(); break;
CASE 1:
managerLogin(); break;
CASE 2:
adminLogin(); break;
CASE 3:
techStaffLogin(); break;
DEFAULT:
publicUserLogin(); break;
staff
manager
admin
tech
public
/Users/gbenoit/Documents/LIS486 - Systems Analysis/Spring2013/InfoSystemsDesign-FlowCharting.rtf 12/30/12 7:41 PM
Systems Analysis
Pseudocoding & Flowcharting
10
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.
/Users/gbenoit/Documents/LIS486 - Systems Analysis/Spring2013/InfoSystemsDesign-FlowCharting.rtf 12/30/12 7:41 PM
Systems Analysis
Pseudocoding & Flowcharting
/Users/gbenoit/Documents/LIS486 - Systems Analysis/Spring2013/InfoSystemsDesign-FlowCharting.rtf 12/30/12 7:41 PM
11
Systems Analysis
Pseudocoding & Flowcharting
12
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 registration 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 completes 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.
/Users/gbenoit/Documents/LIS486 - Systems Analysis/Spring2013/InfoSystemsDesign-FlowCharting.rtf 12/30/12 7:41 PM
Systems Analysis
Pseudocoding & Flowcharting
13
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 circumference, color, and can be bounced. We might, then, create an objectd called “ball”:
Object:
ball
Properites:
circumference
color
tennisball
Actions:
bounce()
This 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. The object
class diagram is used by programmers to create the digital objects used in the program.
/Users/gbenoit/Documents/LIS486 - Systems Analysis/Spring2013/InfoSystemsDesign-FlowCharting.rtf 12/30/12 7:41 PM
Systems Analysis
Pseudocoding & Flowcharting
/Users/gbenoit/Documents/LIS486 - Systems Analysis/Spring2013/InfoSystemsDesign-FlowCharting.rtf 12/30/12 7:41 PM
14
Systems Analysis
Pseudocoding & Flowcharting
/Users/gbenoit/Documents/LIS486 - Systems Analysis/Spring2013/InfoSystemsDesign-FlowCharting.rtf 12/30/12 7:41 PM
15