Monday, October 01, 2007

Object oriented COBOL and a political science application

In developing the Political Argument and Facts project (look in my main blog, for example here), I thought it would be useful to describe how it could be implemented in COBOL, with object oriented concepts. Of course, a project like this might be more likely to get done in a language like java, C# or C++, with considerable sophistication in architecture for web interface. But it’s helpful to think about how this might be done with older, essentially procedural languages that may be more familiar to many IT professionals.

Remember the basic components of such a system. There are objects, which comprise data and methods to operate on the data. In a system, in practice an object exists as a reference to a location in memory. A template for an object, with data layouts but no data, and corresponding methods (procedural code) is called a class. An object is created by instantiating a class (sometimes with a “constructor.”)

Murach, in his COBOL text, gives an example of a book inventory application. An analyst does some functional decomposition to identify the classes and objects. In Murach’s example, the objects can be “book inventory” (an item), file manager, book manager, and user interface.

In this “political science” application, the “objects” (again, corresponding to template classes) would be arguments, incidents, facts, media references, authors, and resumes. “Facts” could well be “subclasses” of “incidents” as they would be simpler. (An example of a “fact” would be the text or a specific state or federal statute.) From a resume, one could determine if a given author or contributor was a “professional” or “amateur.” Media would comprise books, periodicals, websites, movies, and television series and programs. Whereas in Murach’s example a “book item” is the specific object for a class “book” (that is, “my book” is really “my copy of the book” – definitely relevant to copyright law!) in this application, a book is really the piece of intellectual property. A better decomposition is with periodicals. The meaningful object will usually be a specific “periodical article” that usually has specific dates, page numbers, author, publisher, etc. The information roughly corresponds to footnote or bibliography information in a high school or college term paper.

Microfocus COBOL provides one template for object-oriented code in this language. Mainframe compilers may have templates that are a bit different. The overall scheme starts with a driver program. In the Environment Division there is an Object Section and a Class-Control that enumerates the classes. The Data Division, in the Working-Storage section, will contain (binary – computational) object references words to all of the objects in the application. It also contains working storage areas with the data items that apply to each separate object (for each separate class). The Procedure Division will start with an INVOKE of an object to create it with a “New” option. It then will invoke the various classes, and the applicable methods in each class.

Each class itself becomes a compilable COBOL program. As with the main program, in the Environment Division there is an Object Section with Class-Control that enumerates the classes. There follows an “Object” declaration with a “working-storage section” for that class, followed by a Procedure Division with the Methods for the class. What looks odd is that each Method itself has a Data Division and Linkage Section with the data values for the particular object that the method must work with, and a separate Procedure Division with the statements for the method. The program source ends with an End Object and End Class statement, even within the context of the Environment Division, and this will seem odd to programmers used to procedural use of COBOL.

It’s important to remember that this environment seems to suggest computing environments that may have been popular more than a decade ago, when software vendors wrote DOS applications that did not even require Windows (or something comparable) and where companies wanted to deploy “end user” controlled applications on their work stations, well before XML and web integration became more standard.

So how would this play out with my proposed political application? It’s useful to think about what a typical application might be. One idea would be to trace all the arguments related to a particular topic, say, “mandatory paid maternity leave.” I’ll leave aside for right now the political and social controversy and just say that there seem to be compelling arguments on “both” sides. The application would first invoke the class to look up the argument (maybe by a free form key – certainly an SQL lookup with the appropriate error processing). It would then invoke another class to track all the “incidents” related to each side of the argument. For each incident, it would have to invoke still another method (with some linkage parameters for positioning) to display the bibliographic objects, such as book or periodical or web references. (Such a program might provide hyperlinks with embedded image files, in a manner similar to the way banks and insurance companies or even payroll companies may display information to secured visiting customers.) Finally, for each bibliographic entry, it might provide the resume “object” of the contributor, so the visitor could assess the professional credibility of the source of the information. The visitor would experience as set of professional looking web pages, linked forward and backward conveniently (perhaps with indexes displayed in a frame) and in a ten minute visit could assess what is really going on with a controversial issue like this. With such an application with all the factual information so well organized and publicly available, politicians would have a harder time with one-sided behavior.

Then consider how update applications would be designed. The argument class program would have a “create argument” method, which would accept the argument text and various items of supplementary information. In my own prototype, I have an item called “srcecode” which identifies a body of incidents or facts that would justify the argument. The method could establish (with an SQL Select) whether the “source code” has been used. If not, it could cause an incident panel to come up to force the visitor to enter justifying incidents or facts. The incident record(s) will require unique “incident codes” and bibliographic information which will in turn invoke bibliographic source class’s methods (I call them “media” in my own hard drive). There would also be “contributor” objects and classes that would process resume data for people who contribute to the database, in order to help establish the credibility of what finally appears to visitors.

Typical classes:

Fact (subclass of incident)
Media item (could have different classes for books, periodicals, movies, websites, with subclasses and common methods – polymorphism)
Contributor (with resume)

No comments: