Jump to content

Jackson system development

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Tassedethe (talk | contribs) at 20:01, 9 January 2022 (v2.04 - Repaired 1 link to disambiguation page - (You can help) - Michael A. Jackson). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Jackson System Development (JSD) is a linear software development methodology developed by Michael A. Jackson and John Cameron in the 1980s.

History

JSD was first presented by Michael A. Jackson in 1982, in a paper called "A System Development Method".[1] and in 1983 in System Development.[2] Jackson System Development (JSD) is a method of system development that covers the software life cycle either directly or, by providing a framework into which more specialized techniques can fit. Jackson System Development can start from the stage in a project when there is only a general statement of requirements. However, many projects that have used Jackson System Development actually started slightly later in the life cycle, doing the first steps largely from existing documents rather than directly with the users. The later steps of JSD produce the code of the final system. Jackson’s first method, Jackson Structured Programming (JSP), is used to produce the final code. The output of the earlier steps of JSD are a set of program design problems, the design of which is the subject matter of JSP. Maintenance is also addressed by reworking whichever of the earlier steps are appropriate.

JSD continued to evolve, and a few new features were introduced into the method. These are described in a 1989 collection of papers by John Cameron, JSP and JSD,[3] and in the 1992 version (version 2) of the LBMS JSD manual.[4]

Development of the JSD method came to an end in the early 1990s as Jackson's thinking evolved into the Problem Frames Approach with the publication of Software Requirements and Specifications (1995) and Problem Frames: Analyzing and Structuring Software Development Problems (2000).

Principles of operation

Three basic principles of operation of JSD is that:

  • Development must start with describing and modelling the real world, rather than specifying or structuring the function performed by the system. A system made using JSD method performs the simulation of the real world before any direct attention is paid to function or purpose of the system.
  • An adequate model of a time-ordered world must itself be time-ordered. Main aim is to map progress in the real world on progress in the system that models it.
  • The way of implementing the system is based on transformation of specification into efficient set of processes. These processes should be designed in such a manner that it would be possible to run them on available software and hardware.

JSD steps

When it was originally presented by Jackson in 1982,[1] the method consisted of six steps:

  1. Entity/action step
  2. Initial model step
  3. Interactive function step
  4. Information function step
  5. System timing step
  6. System implementation step

Later, some steps were combined to create a method with only three steps.[5]

  1. Modelling stage (analysis): with the entity/action step and entity structures step.
  2. Network stage (design): with the initial model step, function step, and system timing step.
  3. Implementation stage (realisation): the implementation step.

Modeling stage

In the modeling stage the designer creates a collection of entity structure diagrams and identifies the entities in the system, the actions they perform, the time-ordering of the actions in the life of the entities, and the attributes of the actions and entities. Entity structure diagrams use the diagramming notation of Jackson Structured Programming structure diagrams. Purpose of these diagrams is to create a full description of the aspects of the system and the organisation. Developers have to decide which things are important and which are not. Good communication between developers and users of the new system is very important.

This stage is the combination of the former entity/action step and the entity structures step.

Network stage

In the network stage a model of the system as a whole is developed and represented as a system specification diagram (SSD) (also known as a network diagram). Network diagrams show processes (rectangles) and how they communicate with each other, either via state vector connections (diamonds) or via datastream connections (circles). In this stage, the functionality of the system is defined. Each entity becomes a process or program in the network diagram. External programs are later added to the network diagrams. The purpose of these programs is to process input, calculate output and to keep the entity processes up-to-date. The whole system is described with these network diagrams and are completed with descriptions about the data and connections between the processes and programs.

The initial model step specifies a simulation of the real world. The function step adds to this simulation the further executable operations and processes needed to produce output of the system. System timing step provides synchronisation among processes, introduces constraints. This stage is the combination of the former ‘Initial model’ step, the ‘function’ step and the ‘system timing’ step.

Implementation stage

In the implementation stage the abstract network model of the solution is converted into a physical system, represented as a system implementation diagram (SID). The SID shows the system as a scheduler process that calls modules that implement the processes. Datastreams are represented as calls to inverted processes. Database symbols represent collections of entity state-vectors, and there are special symbols for file buffers (which must be implemented when processes are scheduled to run at different time intervals).

The central concern of implementation step is optimization of the system. It is necessary to reduce the number of processes because it is impossible to provide each process that is contained in specification with its own virtual processor. By means of transformation, processes are combined in order to limit their number to the number of processors.

Designing the diagrams

Entity structure diagram (ESD)

The diagram shows how the action entities cooperate with the system. Entity structure diagram (ESD) notations:

  • Entity: An entity is an object that is used on the system and by the system.
  • Action: The actions that are carried out by entities and the actions that affect other entities.
  • Construct-sequence: The JSD construct is identical to the SSADM Entity Life History construct. Use a SequenceConstruct to illustrate actions that are applied from left to right.
  • Construct-selection: To reflect a choice between two or more actions. Mark the options in the topright corner with a "o" (option).
  • Construct-recurrence: When an action repeats, place a small asterisk (*) in the topright corner.

Normally there would be only one action underneath a RecurringConstruct.

  • Null component: A Null component can make sure nothing happens in an IF-ELSE statement.
Network diagram (ND)

Network diagrams show the interaction between the processes. Sometimes they are referred to as system specification diagrams (SSDs). Network diagram (ND) notations:

  • Process: Processes represent system functions. A process model represents the primary system functions. It generally has a relation with an outside entity through the datastream.
  • Datastream connection: In a datastream connection, process A (the entity that writes the datastream) actively sends information to another process B.
  • State vector inspection: In a state vector connection, process B (the entity that reads the state vector information) reads the state vector information of another entity A.

The difference between a state vector connection and a data stream connection lies in which process is active. In a datastream connection, the process with the information, A, is the active process; it actively sends a message to the datastream reader B at a time that it (A, the sender) chooses. In a state vector inspection, the process with the information, A, is passive; it does nothing but let the reader process B inspect its (A's) state vector. B, the process doing the inspection, is the active process; it decides when it will read information from A. Roughly speaking, datastream connection is an abstraction of message passing, while state vector inspection is an abstraction for polling (and for database retrieval).

References

  1. ^ a b "A System development method Archived 2012-02-06 at the Wayback Machine" by M. A. Jackson, published in Tools and notions for program construction: An advanced course, Cambridge University Press, 1982
  2. ^ System Development, M. A. Jackson, Prentice Hall, 1983
  3. ^ JSP and JSD: The Jackson Approach to Software Development, ed. John R. Cameron (IEEE Computer Society Press, ISBN 0-8186-8858-0, 1989)
  4. ^ LBMS Jackson system development, Version 2.0 Method manual by LBMS (Learmonth, Burchett Management Systems), John Wiley & Sons, ISBN 0-471-93565-4; 1992
  5. ^ Decision systems Inc. (2002), Jackson System Development. Accessed 24 Nov 2008.

Further reading

Retrieved from "https://en.wikipedia.org/w/index.php?title=Jackson_system_development&oldid=1064704707"