Jackson System Development (JSD): An Overview
Program inversion extends the range of JSP applications into various areas such as coroutine design, implementing a system of simple programs as a hierarchy of subroutines, on-line programming and systems design. We will now look at JSD, a method for design information systems.A Simple Example: Student Loan System
Consider the following description of a student loan system:
Two output functions are desired: (1) an inquiry function that prints out the loan balance for any student, and (2) a repayment acknowledgment sent to each student after payment is received by the university.
Notice that each student who receives one or more loans generates a stream of data over a long-period of time, perhaps many years. We can write a program to process the whole data stream, if we can describe its structure, just as we can write a program to process the data input by a user at a terminal. A key feature of many information systems is that they consist of slow, long-running processes. JSD takes a bird's eye view --a holistic view-- of such processes, describing the entire serial file even though it has not yet been produced.
Modeling Phase
JSD consists of three main phases: the modeling phase; the network phase; and the implementation phase. In this section, we will look at the modeling phase. The modeling phase consists of three steps:
Step 1: Entity/action step
Actions have the following characteristics:
(1) An action takes place at a point
in time
(2) An action must take place in
the real world outside of the system.
(3) An action is atomic, cannot
be divided into subactions.
Entities have the following characteristics:
(1) An entity performs or suffers
actions in time.
(2) An entity must exist in the
real world, and not be a construct of a system that models the real world
(3) An entity must be capable of
being regarded as an individual; and, if there are many entities of the
same type, of being uniquely named.
Here are the candidate lists:
Actions/Attributes:
evaluate -action
of university? (university performs the evaluation); action of student?
(student is evaluated)
attributes: student-id, loan-no, date of evaluation, remarks
agree - action
of university? (university agrees to loan); action of student ? (agrees
to loan)
attributes: student-id, loan-no, date of agreement, amount of loan, interest
rate, repayment period)
make loan - action
of university
attributes: student-id, loan-no, date of loan, loan amount, interest rate,
repayment period
initiate - action of university?
(university initiates loan); action of student? (student initiates loan);
action of loan? (is initiated)
attributes: student-id,
date initiated
repay - action of loan? (loan is
repaid); action of student? (student repays the loan);
attributes: student-id,
date of repayment, amount of repayment
terminate - action of loan (loan
is terminated);
attributes: student-id,
date of termination, remarks
After discussion and reflection,
we end up with the following entity and action lists:
Actions/Attributes:
evaluate -action
of student; student? (student suffers the action, is evaluated);
attributes: student-id, loan-no, date of evaluation, remarks
agree - action
of student
attributes: student-id, loan-no, date of agreement, amount of loan, interest
rate, repayment period)
initiate - action
of student
attributes: student-id, date initiated
repay - action
of student
attributes: student-id, date of repayment, amount of repayment
terminate - action
of student
attributes: student-id, date of termination, remarks
The behavior of an entity in the real-world is modeled in terms of the actions it performs or suffers over time. The second step of JSD expresses the constraints in the ordering of an entity’s actions with a structure diagram.
The entity structure diagram for a student is shown below:
Step 3: Model process step
In the last step of the modeling phase we create an executable model process for each entity in the system. Each model process is described with a system diagram.
Our information system models each
real-world entity. We are not just simulating entities artificially, using
some statistical techniques for example; we are modeling each entity precisely
as it exists in the real world. Therefore, there must be a connection between
the entity in the real world and the entity model process in our information
system.
What is the structure of the serial data stream? The entity structure diagram describes its structure. The entity model process for a student can be described by a simple program that reads a serial data stream. We can use JSP to write the program text for this process. It is shown below:
Network Phase
In the network phase, we connect model processes and functions in a single system specification diagram (SSD). In our system, we have one entity and two functions. The SSD is shown below:
The loan balance inquiry function (LBE) is connected to the Student-1 process by state vector (SV) connection. In this type of connection, one process can examine the state vector of a second process. The double lines indicate that an inquiry process, over its life, will examine many student processes.
The function to produce the student acknowledgments data stream (ACK) is embedded in the student-1 process in the repays component as shown below:
DT is an input signal at the end of the day--a daily time marker--that tells the payment acknowledgment lister (PAL) function to begin. The ACK and DT data streams are rough-merged, that is, we don't know precisely whether a repayment acknowledgment will appear on today's or tomorrow's daily list.
The loan balance inquiry function (LBE) is designed using JSP as shown below:
(3) Implementation phase
First we examine the timing constraints of the system. The problem description for our system states that inquiries are to be answered on-line but repayment acknowledgments at the end of the day.
We then consider possible hardware and software for implementing our system. We decide to implement all student processes on a single processor. Each student process could have been allocated a dedicated processor.
Based on hardware and timing constraints, we design a system implementation diagram (SID) shown below:
In the SID, all of the serial data streams are input to the scheduler process. Note that the all student processes have an identical structure text; only their state vectors are different. Consequently, we can separate the state vectors of student processes from their process text--this separation is called state vector separation. The set of state vectors constitutes the data base of our student loan system.
The student-1 process is inverted with respect to its data stream, S. Student-1 is called by the scheduler to process a transaction, and then suspended when it has completed the processing of the transaction, with control returning to the scheduler. Note that the scheduler must access the student's state vector corresponding to the student-id on the input data stream, and for saving the updated state vector on completion of processing the transaction.
The loan balance inquiry is invoked by the scheduler when it has read an inquiry.
The repayment acknowledgment lister (PAL) is inverted with respect to both of its inputs, the repayment acknowledgment data stream and the daily marker. PAL is invoked by Student-1 whenever Student-1 processes a repayment transaction. The scheduler invokes PAL directly when it receives a DT and this triggers the daily listing.
The scheduler process is designed with JSP, and is shown below:
The exact meaning of the scheduler structure diagram is as follows: On any given day, records from the serial data stream (loan balance inquiries and student loan transactions) are read and processed in real-time. At the end of the day, a daily time marker--perhaps a signal to the system from the operator--is input, and the payment acknowledgment lister program is invoked. It processes payment acknowledgments that have been previously generated in real-time whenever a student repayment is made and stored in a buffer.