We frequently get questions about JSD from students whose professors have asked them to research JSD, or to develop a JSP or JSD design. If that is you, then this is the page you've been looking for. Note, however, that we will not do your homework for you!
JSD evolved from JSP, and includes JSP. So JSP is a part, or subset, of JSD. Or you can think of JSD as an extension, or superset, of JSP.
JSD has several diagram types. One of the diagrams, called the action structure diagram or entity life history diagram is a JSP structure diagram put to a new use. In JSP, structure diagrams are used to describe data structures and program structures. In JSD, they are used to describe the lifecycle of real-world entities. The difference is not as great as you might first think. In JSD, it is often the case that each event in the life of a real-world entity generates a message that is sent into the information system. So the structure of events in the life of the real-world entity, and the data structure of the stream of event-messages that the real world entity sends into the information system, are the same.
JSD includes a number of diagrams that are not a part of JSP, including the network structure diagram and the system implementation diagram.
The JSP steps in developing a program are:
- Draw a data structure for each input and output file.
- Draw a single program structure that contains program components to handle correspondences between the input and output data structures. For example: "Consume input file record; write output report line"
- Complete the program structure by adding program components to handle input and output data components that have no counterparts in other structures. For example: "Write report file summary line"
- List the operations needed by the program.
- Allocate each operation to the appropriate component of the program structure. Note that certain operations (READ operations, for example) may be allocated multiple times, to several different components of the program structure.
- Specify the conditions for iteration and selection.
- Translate the whole thing into code or pseudo-code.
So the answer to your question is to start with step number 1 — draw a data structure for each input and output file.
No, it is not true. In fact JSD has a very real claim to being one of the first object-oriented system development methods.
The term "structured" has been stretched so far that it has become meaningless. In fact, the term has become a joke. Don't put any weight on it.
Big system/project methodologies such as SSADM cover so many areas that it is really meaningless to characterise them as being (or not being) "structured". SSADM, for instance, despite its name, contains methods that are not "structured" methods. JSD constructs such as Entity Life History diagrams are among the non-structured methods.
With respect to systems analysis and design methods, the term "structured" is generally applied to methodologies whose central method is functional decomposition and whose central diagram type is some sort of data flow diagram. Neither of these is true of JSD.
To oversimplify, JSD's central method (like other object-oriented analysis methods) is analysis ("modeling") of the problem domain in terms of objects (entities). JSD's central diagram type is an "action structure diagram" (aka "entity life history diagram") to model the behavior of objects. Other OO methods also model object behavior, but typically use state transition diagrams to do it. This is the one area in which I would say JSD is — without question — superior to other OO analysis methods.
JSD was originally developed for use with business information systems, but was also found to be very useful for real-time embedded systems as well. There are a number of case studies where the British military used it for embedded systems, such as torpedo guidance systems. You can find a couple of these case studies in the IEEE book "JSP and JSD", edited by John Cameron. When LBMS purchased Michael Jackson Systems Ltd. in the late 1980's, I believe they did so primarily in order to acquire MJSL's customer base in the British military — which was using Ada and JSD to develop embedded systems.
JSD is a technical method. Other technical methods include Structured Analysis and Design and Object-Oriented Systems Analysis and Design. The purpose of technical methods is to give you assistance in thinking about the structure of your software development problem and its solution — what functions and processes the system must perform, what data it must remember, the events that trigger the running of the processes, and so on.
The waterfall approach (sometimes called the "big bang" approach) and the iterative approach are project management methods. The purpose of such management methods is to give you assistance in thinking about and planning your project — how long it will take, how many people, the activities, milestones, and delivery dates, and so on.
In short, technical methods (such as JSD) are about features of the system to be built. Project management methods are about the features of the project that creates the system.
JSD, as a technical method, is compatible with, and can be used with, almost any project management method.
In theory, JSD could be quite a good method for rapid prototyping (see the article on executable specifications in JSP and JSD). In actual practice, however, there aren't any commercial tools that support prototyping JSD specifications. So if you're trying to do prototyping, your best strategy is to think in JSD (in order to get the requirements right), then to prototype using whatever capabilities your prototyping environment offers.
JSD is certainly compatible with an old-fashioned waterfall management approach, and with a new-fashioned iterative development approach. JSD and XP (extreme programming) on the other hand, are not natural partners. JSD implicitly assumes that it is appropriate — and that you're willing and able — to spend time thinking about — and documenting — the requirements of your system before you start hacking code. So small code-hacking projects generally won't require much in the way of a technical method. For such projects, some form of "extreme programming" is probably a good choice.
The problem with extreme programming, of course, is that you can't always tell in advance whether or not extreme programming will be good enough for the project at hand. There is always the danger that you might start the project thinking that the requirements are so simple that you can just sit down and start coding... but then as you get deeper into the system, you find that things are a lot more complicated than you thought at first. If this happens, you may be looking at many profound refactoring steps. A little up-front thought might have saved you a lot of work. The reply of the extreme programmer, of course, is that if — for all projects both big and small — you always spend a lot of up-front time analyzing the situation, you simply will not be able to operate on "Web time". "Analysis paralysis" and all that. The bottom line is that you need to use your judgment in choosing your project management approach for each individual project.
In connection with this question, you may find an e-mail exchange on problem frames and XP interesting.
Since we've been talking about extreme programming, now might be a good time to address a related question, namely . . .
To categorize a piece of software as "web" software is to categorize it in terms of its implementation technology -- web servers, http, HTML, etc. JSD is primarily a method for developing functional (in a very broad sense of "functional") requirements for a system. Since functional requirements are (ideally) independent of the implementation technology -- what the user wants to do is independent of the technology used to do it -- talking about JSD and web software in the same sentence is talking about apples and oranges.
Looking at the question from a different perspective, we can say that JSD is a requirements specification method for information systems having complex requirements. But the functional requirements for most web software are simple to the point of being trivial. A lot of web software does very simple tasks -- for example, it gets a request from a user, retrieves data from a database, and returns it in the form of a Web page. Building this kind of software using "web" technology can be challenging. You may need to know a lot about a lot of different kinds of software -- languages, web servers, database management systems, etc. -- to be able to write the web applications. But from the standpoint of the user requirements, such software is extremely simple.
Often, for web applications, you don't need any requirements analysis at all -- using JSD or any other requirements analysis method. That's why developers of web applications find approaches such as XP (extreme programming) and "agile" software development so appealing. These approaches don't involve any explicit requirements gathering -- they just involve the user sitting down with the programmer, and working with the programmer while he hacks together code.
But if the functional requirements for your web application are at all complex, you do need to devote serious attention to requirements analysis. Which means that you need a serious requirements-gathering method. And in such cases JSD can very effective.
JSD has a reasonable claim to being the first -- and in some ways, still the best -- object-oriented software development method. So many of the benefits claimed for object-oriented methods also apply to JSD. Perhaps the strongest feature of JSD was its "action diagrams" or "entity life history" diagrams, which are vastly superior to state-transaction diagrams because they empasize the events, rather than the states, in an entity's life cycle.
JSP and JSD were widely used in the 1970's and 1980's in Great Britain and in Sweden. But outside of those two countries, they were not widely used. Within Britain, JSD techniques were widely used as part of SSADM, which incorporated JSD's entity/event modeling. There is a lot of information about SSADM on the Web. SSADM was originally developed by John Hall and Keith Robinson of Model Systems, which still supports it.
This is a question that JSD practitioners have been asking themselves for years. One proposal is that lack of CASE-tool support held JSP and JSD back. Another is that Michael Jackson had the natural personality of a researcher. He wasn't by nature a promoter, the way that, say, Ken Orr was. He just wasn't that interested in selling his methods.
Personally, I can't accept either of these ideas. At one time, JSD did have a number of CASE tools, including JSP-tool, and Speedbuilder. And it is not clear that a promoter's personality invariable leads to long-term success... who now speaks of the Warnier/Orr method?
So here's my personal opinion, for what its worth.
The state of professional development for most practicing programmers is so weak that software development methodologies are never successful; only programming languages are successful. Programmers are coders; they learn programming languages. They learn only whatever development methods are able to ride in on the coat-tails of the programming language du jour. Object-oriented methods didn't kill the old "structured" methods. Turbo Pascal killed COBOL, and then Visual Basic killed Turbo Pascal, and then Java killed Visual Basic, and object-oriented methods rode in on the tail of Java.
The reason that JSD was never widely used is that there was no language that had — built right into the language features — support for basic JSD concepts such as backtracking, the suspend/resume mechanisms required by program inversion, and the ability to persist a long-running process to disk. The pinnacle of sophistication for most software development shops is simply buying a compiler, so if your methodology required some capability that didn't come with the compiler, then your methodology didn't even make it out of the starting gate. Macro processors that could generate flat code never found a market.
Finally, though, and probably most significant, is the fact that no methodologies have ever achieved widespread market penetration. Even at the zenith of popularity of the "structured" methods, surveys revealed that very few software shops were using any methodology at all.
So there matters stand. "Successful" or not, the fact of the matter is that Michael Jackson's books provide uniquely powerful insights into the structure and development of software systems. So there will always be a small number of people who are big Jackson fans. There won't be many of them, but they will be wildly enthusiastic.
The main reason that you can't find much on the Web is that JSD was first articulated and worked out in the 1980's. Pre-Web days. So virtually all of the material describing JSD is printed, and very little of it is available on the Web.
The JSP and JSD page has some useful links.
Michael Jackson's home page has links to a number of useful papers.
I don't FAX or e-mail materials. Some material can be downloaded from various Web sites. The JSP and JSD page has some useful links.
For FAXed material, visit the IEEE documents Web site: http://www.ieee.org/services/askieee/ and request a copy of an article titled "An Overview of JSD" by John R. Cameron. It appeared in the February 1986 issue (vol SE-12, No. 2) of the IEEE Transactions on Software Engineering, pages 222 through 240. It may have a document number of 0098-5589/86/0200-0222.
The literature page has information about literature and publications describing JSP and JSD.
The major published works on JSD are:
- System Development , Michael Jackson
- JSP and JSD, ed. John Cameron (IEEE Computer Society Press, ISBN 0-8186-8858-0, 1989).
Michael Jackson's home page has links to a number of useful papers.
I recommend two articles by John Cameron: "An Overview of JSD" and "The Modelling Phase of JSD". Both are reprinted in JSP and JSD, ed. John Cameron (IEEE Computer Society Press, ISBN 0-8186-8858-0, 1989). Used copies are available on Amazon.com, or check your university library.
Also useful, and available online, are "A System Development Method" [PDF] by Michael Jackson and JSD Version 2 and an Overview of Developments in JSD [PDF] by Jim Newport.
For a book-length introduction, Jackson System Development by Alistair Sutcliffe (Prentice Hall; ISBN 0-13-508136-X; 1988) is a very readable introduction to JSD. Used copies are available on Amazon.com, or check your university library.