Software Design Methods

Jackson Structured Programming (JSP) Structured Systems Analysis and Structured Design Jackson System Development (JSD) Object Oriented Design (OOD)

The JSD model Jackson System Development (JSD)

JSD can be considered as a second generation software design method

It encompasses both analysis and design activities, directed towards constructing a model of a system in terms of a set of long-running interacting concurrent processes for its description, which is then transformed into a physical realization of the model

Used where time-ordering of actions may be a dominant characteristic, modelling processes rather than objects, and hence its use usually results in a design that has an interacting processes architectural style (communicating processes).

Systems developed using JSD are always realtime systems.

It is concerned with the design of systems that are realizable as a single sequential process; have well-defined streams. input and output data

JSD In terms of the following three stages:

a modelling stage, in which the problem is analysed and modelled in terms of the constituent entities and the actions that they perform, and where these entities are represented by longrunning sequential processes in the model itself;

a network stage, in which the overall structure of the system is developed from that of the model by adding the details of interactions between entities, and between the entities and the external world; an implementation stage, in which the abstract design is mapped onto a physical design. (Refer fig 15.1)

Fig 15.1

15.2 JSD representation forms

The JSD design process makes use of two principal forms of diagrammatical description.

1. The EntityStructure Diagram 2. The System Specification Diagram (SSD)

1. The EntityStructure Diagram

In JSD it is used to describe the evolution of an entity over a period of time. In this context, an entity is an active element ie identified through the operations of the modeling process itself. (processing agent )

The notation used for an EntityStructure Diagram (ESD) is the standard form used for a Structure Diagram but is a different interpretation of the diagram elements, in order to adopt a rather different viewpoint of the system model.

In the JSD model of a system is as a network of long-running sequential processes, the ESD provides a means of describing the behaviour of the sequential processes.

Figure 15.2 shows an example of such an EntityStructure Diagram, as developed for one of the entities in an Air Traffic Control (ATC) system (namely, an aircraft).

Figure 15.2 shows that this conforms to this framework at the first level of abstraction In this example, an aircraft becomes an entity of interest to the ATC system only when it crosses a boundary to enter the controlled airspace and it ceases to be of interest when it leaves that airspace. Between those events it might perform a number of actions, which can include:

doing nothing (the aircraft just flies through);

landing and taking off; being stacked before landing. time-ordering is important: an aircraft must land before it can take off, and if it enters the landing stack, it must leave the stack before it can be assigned to the runway for landing. allows for multiple occurrences of an aircraft being stacked, landing and taking off

Here an aircraft has been identified as one of the entities whose behaviour should be modelled, and so this diagram is constructed as part of the modelling task. Figure 15.3 shows the generic form of Structure Diagrams of this type; the overall basic sequence is concerned with: creation of the entity in the model; actions performed by the entity while in existence; deletion of the entity from the model.

Another Eg:

For other systems, a suitable entity might be a person, as in Figure 15.4, describing a student who is on a course of some kind. The person in question becomes of interest only when undertaking those actions that make him or her into a student, and a specific type of student at that (one registered for this course); and ceases to be of interest to the model on ceasing to be a student, whether this occurs through passing or failing the course.

Each of these examples of an entity might be of importance to a system designer using JSD.

In the first case, we can assume that modelling aircraft behaviour would be required when constructing an ATC system intended to provide assistance to the human controllers.

In the second, in order to create a system that will be used to maintain student records, the designer will need this model of student activity in order to help identify all the situations that the system will be required to handle.

2. The System Specification Diagram (SSD)

The SSD is basically a network diagram that identifies the interactions between the entities that make up the model of the system.

These interactions take place by two basic mechanisms for interprocess communication, which are:
A data-flow stream A state vector

A data-flow stream, in which messages are passed asynchronously between the entities concerned, using some form of pipeline mechanism, as shown in Figure 15.5.

A data-flow stream acts as a FIFO queue, and is assumed to have infinite buffer capacity, so that the producer process is never blocked on a write operation to the buffer of the stream. In contrast, the consumer process is blocked if it tries to read from a buffer when no message is available, as it has no means of checking whether data is available before issuing a read request.
A state vector that describes the local state of a process at a given time.

By inspecting this state vector, one entity can obtain required information from a second entity,where this is
contained in its current state.

The state vector will typically consist of the local variables of a process, including its program counter which is used to indicate the current state of execution.

Figure 15.6 shows an example of state vector inspection.

The notation used for SSDs has further elements to denote such features as multiplicity of data transfer operations and multiplicity of processes.

In particular, where a process reads from more than one stream, we can distinguish between the cases in which data is read from either stream as available using the rough-merged scheme (Figure 15.7 (a)), and those in which the inputs remain distinct (Figure 15.7 (b))

In the first case, the consumer is required to organize the handling of multiple inputs through one read operation, while in the latter it must organize the sequencing of consumption from the two sources.

Figure 15.8 shows an SSD describing a very simple network in a system.

The circle is used to label a data-flow arc, and an entity is represented by using an oblong box. The diamond shape used to describe the state vector ie associated with a particular entity by means of the labelling attached to it.

15.3 The JSD process 15.3.1 The modelling stage

15.3.2 The network stage

15.3.3 The implementation stage

15.3.4 The JSD design process

The procedures involved in the process part of JSD have undergone a certain amount of revision and repackaging since the method was first introduced. Figure 15.9 uses an ESD to describe the JSD process as it was originally presented in Jackson (1983), while
Figure 15.10 shows the form of the method as subsequently described in Cameron (1986). This modification is a more significant development than the previous one, since it gives additional structure to the design process for a task that is generally seen as posing difficult problems for the designer.

15.3.1 The modelling stage

Entity analysis (the entityaction and entitystructure steps)

15.3.1 The modelling stage

In many ways, the role of this step corresponds (rather loosely) to the analysis phase of other methods such as SSA/SD, in that it is concerned with building up a black box model of the problem, rather than considering the form of a solution. Entity analysis (the entityaction and entitystructure steps)

Jackson and others have recommended that a designer should begin this task by analysing the requirements specification in order to identify the entities in the system, the actions that they perform, the attributes of the actions, and the time-ordering of the actions.

As an excellent example of this distinction between entities and items outside the model boundary, Jackson (1983) develops an example of a simple banking system.

A major entity that is identified for the model is the customer, which performs such actions as opening and closing accounts, and paying in and withdrawing funds. The bank manager, on the other hand, is dismissed as being outside the model boundary,because modelling the time-ordered behaviour of the bank manager does not help with developing a model of how the banking system operates, which is the purpose of this stage. the analyst will also seek to identify those attributes of the aircrafts actions that are of interest to the modelling. These may include information about:
flight number
Call-sign Position

any other features that may be of assistance in distinguishing any one aircraft from the others in the airspace at a given time.

At this point in the design process the model consists of a set of (disjoint) process models for the major entities of the problem

15.3.2 The network stage

The initial model phase The elaboration phase

Elaboration phase 1: the interactive function step Elaboration phase 2: the information function step

Elaboration phase 3: the system timing step

The initial model phase

This phase involves the designer in linking the entities defined in the first step, and beginning the construction of the initial model of the system as a whole.

This initial model is concerned with modelling the interactions between the various entities, it produces a combination of SSDs and ESDs, with the added functionality The task of creating a model begins with the designer seeking to find the input that is required to trigger each action of an entity that has been identified in the first step.
Each such input will be either: an input corresponding to an event that arises externally to the system , for example,the radar detects a new aircraft in the control zone; an input generated internally by the system for example, when interest is added to the bank account every six months.