InfoSystemsDesign FlowCharting

15
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

description

flow chart for designing planning...to get in the

Transcript of InfoSystemsDesign FlowCharting

  • 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. [Dont 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. Well 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

  • Systems Analysis Pseudocoding & Flowcharting 2

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

    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 (its 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 theres enough gas in the car (condition), THEN (true) Ill drive

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

    Sometimes the if/then are nested in other if/then conditions: If theres enough gas in the car, Ill

    go to my friends house; if I dont reach there by noon, Ill stop at a restaurant along the way.

  • Systems Analysis Pseudocoding & Flowcharting 3

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

    Repetitive Logic:

  • Systems Analysis Pseudocoding & Flowcharting 4

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

    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, Ill 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 Ive finished grading,

    Ill 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 students 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

  • Systems Analysis Pseudocoding & Flowcharting 5

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

    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

  • Systems Analysis Pseudocoding & Flowcharting 6

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

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

    goals arent 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.]

  • Systems Analysis Pseudocoding & Flowcharting 7

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

    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 programmers 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 youre defining the processes that the first

    person in the office performs every day. These include

    Turn on the lightsTurn on the photocopierTurn on the air conditionerTurn on the computersRead and reply to emergency emailsUnlock the front doorTurn the sign in the window from closed, come again! to Were Open!

  • Systems Analysis Pseudocoding & Flowcharting 8

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

    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 (lets say

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

    ING RANGE 0, 100.

    Heres are a few examples:

    Ifthen

    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

  • Systems Analysis Pseudocoding & Flowcharting 9

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

    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 ifthen statements are not very efficient from a computers 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 doesnt have a

    value assigned, it means theyre 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;

  • Systems Analysis Pseudocoding & Flowcharting 10

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

    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 wont 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.

  • Systems Analysis Pseudocoding & Flowcharting 11

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

  • Systems Analysis Pseudocoding & Flowcharting 12

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

    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 courses 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.

  • Systems Analysis Pseudocoding & Flowcharting 13

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

    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: circumferencecolortennisball

    Actions: bounce()

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

    Ball myTennisball

    Because we borrow the ball object, we inherit all the ball objects 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.

  • Systems Analysis Pseudocoding & Flowcharting 14

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

  • Systems Analysis Pseudocoding & Flowcharting 15

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