World Library  
Flag as Inappropriate
Email this Article

Jackson structured programming

Article Id: WHEBN0000070973
Reproduction Date:

Title: Jackson structured programming  
Author: World Heritage Encyclopedia
Language: English
Subject: Computer Aided Software Engineering, Requirements Engineering Specialist Group, Modeling language, Programming paradigms, Software architecture
Collection: Diagrams, Programming Paradigms
Publisher: World Heritage Encyclopedia

Jackson structured programming

Example of a JSP diagram.

Jackson structured programming (JSP) is a method for structured programming based on correspondences between data stream structure and program structure. JSP structures programs and data in terms of sequences, iterations and selections, and as a consequence it is applied when designing a program's detailed control structure, below the level where object-oriented methods become important.[1][2]


  • Introduction 1
  • Structural equivalent 2
  • The method 3
  • A worked example 4
  • Criticism 5
  • See also 6
  • References 7
  • External links 8


Michael A. Jackson originally developed JSP in the 1970s. He documented the system in his 1975 book Principles of Program Design.[3] Jackson's aim was to make COBOL batch file processing programs easier to modify and maintain, but the method can be used to design programs for any programming language that has structured control constructs, languages such as C, Java and Perl. Despite its age, JSP is still in use and is supported by diagramming tools such as Microsoft's Visio and CASE tools such as Jackson Workbench [4]

Jackson Structured Programming was seen by many as related[5] to Warnier structured programming,[6] but the latter method focused almost exclusively on the structure of the output stream. JSP and Warnier's method both structure programs and data using only sequences, iterations and selections, so they essentially create programs that are parsers for regular expressions which simultaneously match the program's input and output data streams.

Because JSP focuses on the existing input and output data streams, designing a program using JSP is claimed to be more straightforward than with other structured programming methods, avoiding the leaps of intuition needed to successfully program using methods such as top-down decomposition.[7]

Another consequence of JSP's focus on data streams is that it creates program designs with a very different structure to the kind created by the stepwise refinement methods of Wirth and Dijkstra. One typical feature of the structure of JSP programs is that they have several input operations distributed throughout the code in contrast to programs designed using stepwise refinement, which tend to have only one input operation. Jackson illustrates this difference in Chapter 3 of Principles of Program Design.[3] He presents two versions of a program, one designed using JSP, the other using "traditional" methods.

Structural equivalent

The JSP version of the program is structurally equivalent to

String line;

line = in.readLine();
while (line != null) {
    int count = 0;
    String firstLineOfGroup = line;

    while (line != null && line.equals(firstLineOfGroup)) {
        line = in.readLine();
    System.out.println(firstLineOfGroup + " " + count);

and the traditional version of the program is equivalent to

String line;

int count = 0;
String firstLineOfGroup = null;
while ((line = in.readLine()) != null) {
    if (firstLineOfGroup == null
            || !line.equals(firstLineOfGroup)) {
        if (firstLineOfGroup != null) {
            System.out.println(firstLineOfGroup + " " + count);
        count = 0;
        firstLineOfGroup = line;
if (firstLineOfGroup != null) {
    System.out.println(firstLineOfGroup + " " + count);

Jackson criticises the traditional version, claiming that it hides the relationships which exist between the input lines, compromising the program's understandability and maintainability by, for example, forcing the use of a special case for the first line and forcing another special case for a final output operation.

The method

JSP uses semi-formal steps to capture the existing structure of a program's inputs and outputs in the structure of the program itself.

The intent is to create programs which are easy to modify over their lifetime. Jackson's major insight was that requirement changes are usually minor tweaks to the existing structures. For a program constructed using JSP, the inputs, the outputs, and the internal structures of the program all match, so small changes to the inputs and outputs should translate into small changes to the program.

JSP structures programs in terms of four component types:

  • fundamental operations
  • sequences
  • iterations
  • selections

The method begins by describing a program's inputs in terms of the four fundamental component types. It then goes on to describe the program's outputs in the same way. Each input and output is modelled as a separate Data Structure Diagram (DSD). To make JSP work for compute-intensive applications, such as digital signal processing (DSP) it is also necessary to draw algorithm structure diagrams, which focus on internal data structures rather than input and output ones.

The input and output structures are then unified or merged into a final program structure, known as a Program Structure Diagram (PSD). This step may involve the addition of a small amount of high level control structure to marry up the inputs and outputs. Some programs process all the input before doing any output, whilst others read in one record, write one record and iterate. Such approaches have to be captured in the PSD.

The PSD, which is language neutral, is then implemented in a programming language. JSP is geared towards programming at the level of control structures, so the implemented designs use just primitive operations, sequences, iterations and selections. JSP is not used to structure programs at the level of classes and objects, although it can helpfully structure control flow within a class's methods.

JSP uses a diagramming notation to describe the structure of inputs, outputs and programs, with diagram elements for each of the fundamental component types.

A simple operation is drawn as a box.

A box labeled 'A'
An operation

A sequence of operations is represented by boxes connected with lines. In the example below, operation A consists of the sequence of operations B, C and D.

A box labeled 'A' connected to three boxes below it labeled 'B', 'C' and 'D'
A sequence

An iteration is again represented with joined boxes. In addition the iterated operation has a star in the top right corner of its box. In the example below, operation A consists of an iteration of zero or more invocations of operation B.

A box labeled 'A' connected to a box labeled 'B' below it with a star in the top right corner
An iteration

Selection is similar to a sequence, but with a circle drawn in the top right hand corner of each optional operation. In the example, operation A consists of one and only one of operations B, C or D.

A box labeled 'A' connected to three boxes below it labeled 'B', 'C' and 'D' each with a circle in the top right hand corner
A selection

A worked example

As an example, here is how a programmer would design and code a run length encoder using JSP.

A run length encoder is a program which takes as its input a stream of bytes. It outputs a stream of pairs consisting of a byte along with a count of the byte's consecutive occurrences. Run length encoders are often used for crudely compressing bitmaps.

With JSP, the first step is to describe the structure of a program's inputs. A run length encoder has only one input, a stream of bytes which can be viewed as zero or more runs. Each run consists of one or more bytes of the same value. This is represented by the following JSP diagram.

The run length encoder input

The second step is to describe the structure of the output. The run length encoder output can be described as zero or more pairs, each pair consisting of a byte and its count. In this example, the count will also be a byte.

The run length encoder output

The next step is to describe the correspondences between the operations in the input and output structures.

The correspondences between the run length encoders inputs and its outputs

It is at this stage that the astute programmer may encounter a structure clash, in which there is no obvious correspondence between the input and output structures. If a structure clash is found, it is usually resolved by splitting the program into two parts, using an intermediate data structure to provide a common structural framework with which the two program parts can communicate. The two programs parts are often implemented as processes or coroutines.

In this example, there is no structure clash, so the two structures can be merged to give the final program structure.

The run length encoder program structure

At this stage the program can be fleshed out by hanging various primitive operations off the elements of the structure. Primitives which suggest themselves are

  1. read a byte
  2. remember byte
  3. set counter to zero
  4. increment counter
  5. output remembered byte
  6. output counter

The iterations also have to be fleshed out. They need conditions added. Suitable conditions would be

  1. while there are more bytes
  2. while there are more bytes and this byte is the same as the run's first byte and the count will still fit in a byte

If we put all this together, we can convert the diagram and the primitive operations into C, maintaining a one-to-one correspondence between the code and the operations and structure of the program design diagram.


int main(int argc, char *argv[])
    int c;

    c = getchar();
    while (c != EOF) {
        int count = 1;

        int first_byte = c;

        c = getchar();

        while (c != EOF && c == first_byte && count < 255) {
            c = getchar();

    return EXIT_SUCCESS;


This method will work only when translation from input to output is equivalent to a context-free grammar.

See also


  1. ^ .
  2. ^ .
  3. ^ a b .
  4. ^
  5. ^ .
  6. ^ .
  7. ^ .

External links

  • A free graphical JSP Editor written in JAVA
  • A JSP editor
  • A brief history of the Jackson methods
  • Jackson Workbench site
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.

Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.