Jackson System Development

Zahra Emadi
Alsnousi Essa
Jon Mirhadi
Bahar Sadrzadeh
Neil Struth
Dike Ukaegbu
Introduction
• JSD acronym for Jackson System Development
• JSD is a structured systems analysis and design method
– Similar to SSADM
• JSD is used for developing IS with a strong time dimension
• JSD systems are real-time
– Simulates events dynamically
• Combines reality-drive and information-system driven
approaches
• It uses Entity Structure Diagrams (ESD), Network Diagrams
(ND) and System Implementation Diagrams (SID) to model a
system.
History
• Created by Michael A. Jackson and John Cameron in 1980’s.
• Created using the principles of JSP
– Jackson Structured Programming
– Developed in the 1970’s by Michael Jackson (Jackson, 1975)
– “Aspects of JSP are defused throughout JSD, so that the JSD
methodology is a significant development on its precursors, and
therefore should not be seen as a “front end” to JSP but an extension of
it, where JSP is the core” (Rawlings, n.d.)
• Orientated towards software and not organisational needs.
History (2)
• Can be used to design programs for any programming
language with structured control constructs (e.g. C, Java, Perl)
• Arguably one of the first Object Orientated software
development methods
– Identifies objects (entities) by time ordering events (actions)
• Updated versions have been described in:
– LBMS Jackson System Development (Wiley, 1992)
– Practical Program Development using JSP (Storer, 1987)
Aims and Purpose
• Purpose
– To create maintainable software
– A method for specifying and describing systems
• Whose application domain has a strong temporal flavour
• Contains objects whose behaviour can be described as sequences and
events
• Aims to:
– Ensure final system is a “true reflection” of developers and users
perceptions of the real world
• Begins with
– Describing the real world
Overview
• JSD can be described in phases and steps
• Three major phases of JSD:
– Modelling
– Network
– Implementation
• Broken into six steps
– First four concerned with deriving a specification for the required
system
– Last two concerned with implementation of the specification
Key Definitions
• Entity Structure Diagrams
– Entity
• An object that acts and is acted on by the system
– Action
• Carried out by entities and affect other entities
– Constructs – Sequence
• Identical to SSADM Entity Life History constructs
• Use a sequence to demonstrate actions that are executed in order(left to
right)
JSD Entity Structure Diagram
• A process model for both analysis and design
• Processes described by ESD (Entity Structure Diagram)
Three Stages: Modelling
• Modelling Stage
– Events and entities are identified
– Entity structures and entity life cycles are formed.
– Result of this stage is a set of
• Tables
• Definitions
• Diagrams
– This describes:
• in user terms:
– Exactly what happens in the organisation
• In implementation terms:
– the contents of the database, integrity and update rules.
Three Stages: Network
• Network Stage
– Inputs and outputs added to the derived model.
• Allows analysis of input and output subsystems
– The description of this is in terms of a network of program
• Network of Communicating Sequential Processes (CSP)
– Concept developed by Tony Hoare (Hoare 1985)
– Build network by:
• Making one program for each entity (from modelling)
• Add new programs and connect to existing network
Three Stages: Network (2)
• Network Diagram
– Represents interaction between processes
– Sometimes known as System Specification Diagrams (SSD’s)
– Processes can be connected in two ways:
• DataStream
– Connect processes and specify what information is passed

• State Vector
– Specify the characteristic or state of the entity being changed by a process
Implementation Stage
• Implementation Stage
– Detailed design and coding
– How can the specification be transformed to run on hardware?
– Results of this stage is the final system
– The only stage where the machines and software the system is to run
is considered
– Thus it covers design issues:
• Physical Data Design
• Reconfiguring the network (combining components)
– This would not be considered “implementation” by other
methodologies
Entity/Action Step
• In abstract terms the developer describes the real world
– JSD more concerned with behaviour rather than attributes or
relationships.
• Describe in terms of entities and actions in which they
participate.
• JSD is concerned with modelling system dynamics
– Conventional modelling presents a static view
• A JSD entity must meet the following:
– "it must perform or suffer actions in a significant time ordering
– it must exist in the real world outside of the system that models the
real world
– it must be capable of individual instantiation with a unique name"
(Rawlings, n.d.)
Entity Structure Step
• A diagrammatic notation known as Structure Diagrams is
introduced by JSD
• Used to represent entity structure and time ordering of
actions
• Actions applied to entity as a sequence
– Either-or selection or
– Repetitively (iteration)
• Represented by a *
Initial Model Step
• By the point the developer has an "abstract description of the
real world in terms of sequential access" (Jackson, 1983)
• Converts the abstract description into a specification
– By stating connections between processes in the real world and
processes in the model
• Portrayed using a System Specification Diagram
• Internal details can be specified using structure text

Simple elevator example

Function Step
• Newly-defined functions are connected with existing model
processes in the System Specification Diagram
• At this stage the following should be documented:
– in terms of the initial model restate the informal requirements
– Expand System Specification Diagram
• illustrate how each function can be connected or built into a process
– Details of each function using structure text.
• Must consider “explicitly whether the values of system
outputs are sufficiently constrained” (Néel , 1982)
System Timing Step
• After specification is produced consider:
– timing and lag within processes
– the effect of this on output
– which are acceptable and which are not
• Specification produced is effectively “capable of direct
execution” (Néel, 1982)
– Mismatch between specification and available hardware/software will
be too severe.
• Sometimes necessary to reduce the number of processes:
– Combine processes
– Interleaved execution of combined processes
Implementation Step
• The abstract network model of the solution is converted into a
physical system
• Represented as a System Implementation Diagram(SID).
– Abstraction of all the real-world scheduling possibilities
• The SID shows the system as a scheduler process that calls
modules that implement the processes.

Example implementation diagram for elevator

Advantages
• JSD's one main advantage over many other methodologies is
the introduction of a preliminary stage that concentrates on
process modelling and control.
• JSD is sound and teachable design methods for the class of
programs and information systems to which they apply.
• Perhaps the strongest feature of JSD are its "action diagrams"
or "entity life history" diagrams, which are vastly superior to
state-transaction diagrams because they emphasise the
events, rather than the states, in an entity's life cycle.
Disadvantages
• Poor quality CASE tools
– Software that automates processes in the life cycle phases
• JSD doesn’t incorporate many prevalent ideas in software
engineering such as
– Inheritance, Polymorphism and use case.
• Sometimes faces the criticism that it does not address
organisational needs:
– Project selection – User interface
– Cost justification – Procedure Design
– Requirements analysis – User Participation
– Project management
Conclusion
• JSD is a methodology aimed at developing maintainable
software
• It is aimed towards software and not towards organisation.
• JSD represents a dynamic view of the real world
– Entity modelling arguably has a static view
– Aided by the use of diagrams in combination with structure text
• It is self-consciously incomplete as a methodology
Conclusion
• JSD derives the overall structure of the system to be
implemented.
– Decomposing this structure into subsystems is not addressed.
– Steps do not exist to say what entities, processes and functions should
be joined to form a subsystem
– This procedure is purely up to the analyst
• Based on heuristics
Bibliography
• Jackson, M.A.,1983. System Development, London: Prentice-Hall
International.
• Rohde, F., 1995. An Ontological Evaluation of Jackson's System
Development Model.
• Jackson, M.A., 1975. Principles of Program Design. Academic Press.
• Newport, J.R., 1996. JSD Version 2 and an overview of developments in
JSD. Jackson System Development (JSD) - The Original Object Oriented
Method. 1996(020). pp. 1/1-1/5
• Hoare, C. A. R., 1985. Communicating Sequential Processes. Prentice Hall.
• http://www.smartdraw.com/resources/tutorials/Introduction-to-
JSD#/resources/tutorials/Network-Diagram
• Néel D.,1982, Tools and Notions for Program Construction: An Advanced
Course, Cambridge University Press
• Rawlings P., n.d. Peter Rawlings Senior Lecturer in Information Systems,
UWE