JOOSSSE Applications for Small Software Companies:Java Object Oriented Small Scale Software Engineering.

Prof. Dan Diaper 1 & Dr. Martin Beer 2

School of Design Engineering and Computing,Bournemouth University. 1

Department of Computer Science,University of Liverpool. 2

AbstractJOOSSSE (Java Object Oriented Small Scale Software Engineering) applications are those that exploit the properties of the Java programming language so as to create additional functionality in existing, Java implemented, large software systems. As such, the JOOSSSE approach is particularly suitable for the resources available to small software companies. A JOOSSSE application involving the modification of the Table of Contents (ToC) of a typical, modern word processor is used to illustrate the approach. The example shows how a JOOSSSE application can add value, in this case by making the ToC more accurately reflect the structure of a hyperdocument and thus aid document creation, navigation and maintenance.

Keywords: software engineering, programming, Java, hypertext, internet or world wide web, word processing.

Section 1 Introduction

One traditional way to categorise commercial software products, and their associated projects, is to consider them either as either: (1) bespoke; or (2) generic (Brooke, 1993). Fundamentally, this distinction is not based on the properties of software products or projects but on the nature of the product’s intended end users or clients. Bespoke software is produced for a single client whereas generic software is intended for multiple purchasers. In sales terms, bespoke software is sold once, and is hence expensive, and generic software is cheap and relies on volume sales to turn a profit. The actual computer programming in either a bespoke or generic software project may be very similar.

One might think that the ideal generic software product is a “killer application”, i.e. a product that everyone wants but no one has. Successful killer applications are, of course, rare. There are two obvious causes of their rarity. First, of course, it is difficult to have the creative design inspiration (see: Diaper and Sahithi, 1995). Second, the new killer application has to be implemented in one or more software environments that are sufficiently common that volume sales can be assured before it is copied, reverse engineered, etc. Furthermore, a new killer application will probably have to be embedded in an existing software environment otherwise a high proportion of the program code that will need to be implemented will have little to do with the killer part of the application. It is unlikely that small software companies will have

sufficiently well developed existing applications packages and access rights to third party software, if available, are potentially very expensive.

Stand-alone commercially successful killer application software therefore has to be written to a high standard, which inevitably means a high level of design as well as coding, because the product must sell in volume, quickly. While this may not be a problem for the Very Large Software Companies (VLSCs), small software companies are in a very difficult market position. They must engineer well, which is expensive, and gamble that they can produce a significant profit on volume sales before they are reverse engineered out of the market, most likely by the VLSCs.

In today’s software market it would be easy to conclude that novel, killer application type software projects are not suitable for small software companies. This is unfortunate, as today’s VLSCs are rapidly becoming the monolithic, bureaucratic organisations similar to those they displaced. Extant and de facto software engineering standards are mainly developed in these bureaucratic environments and this inhibits innovation by requiring a level of pre-knowledge of the intended product that is simply not possible until at least a preliminary implementation is available to allow both users and developers to experiment (see: Rohm, 1999). It is difficult to see how this can be a good thing from the end users point of view. Good ideas, not emanating or supported by the VLSCs, will not be implemented because adequate profit cannot be guaranteed against the pre-release project development costs.

Brooke, and the authors (Diaper, 1994; Diaper and Beer, 1995) have proposed a third approach, a generic software one, which involves the development of small, loosely coupled programs. The authors’ approach, Small Scale Software Engineering (S3E), was developed to solve the moral problem associated with the enormous platform diversity that exists globally. The S3E approach involves producing small programs, say of about 200 Lines of Code (LoC), that have a single, well specified, functionality. Each S3E program is designed for implementation in a variety of languages so that everyone with a computer, no matter how humble it is, will be able to run S3E programs. Sophisticated functionality is achieved by users running S3E programs in sequence; different functionality being achieved by program and sequence selection. The well specified, single functionality of each S3E program is essential as it allows end users to sensibly select programs in sequence. This paper proposes an adaptation of the S3E approach that is object oriented and suitable for use by small software companies.

In S3E the primary modularisation of the software is at the level of the program. S3E is not dissimilar in this respect to using UNIX’s pipes and tees but S3E achieves this by programs running on common format files rather than on UNIX processes. In an object oriented environment it is messages that take the place of S3E’s files and the modularisation is at the level of object instances which contain most of the program code. Particularly in “pure” object orientated languages such as Java, and in contrast to hybrid ones such as C++ (e.g. Hunt, 1999), the accepted programming style is for object instances to be of a size comparable with that of S3E’s 200LoC heuristic.

The Java Object Oriented Small Scale Software Engineering (JOOSSSE) approach described in this paper proposes that there is a potential market that can be readily

exploited for functionally alternative parts of large software applications packages that are implemented in Java. This proposal relies on the strongly encouraged concepts of:

(1) object reuse particularly associated with pure object orientated languages, and in particular with Java;

(2) that Java is platform independent because code runs on the Java Virtual machine; and

(3) Java’s late, run-time binding which means that the unchanged parts of an application package do not require recompilation.

JOOSSSE is not new, but by giving the approach a name this paper attempts to alert small software companies to the market gap, that they can appropriately exploit, that arises from large software applications implemented in Java. At present, many small software companies have seen the opportunity of providing internet or World Wide Web (web) based programs but few have seen the corresponding market gap in the applications software market caused by Java implementation.

This paper considers the design of a simple example of a potential killer application showing how existing applications software can be modified effectively by relatively simple means. The example involves the word processing component of a Java implemented automated office system such as StarOffice. As is common in most modern word processors, navigation of a document can be assisted by a window showing a hierarchical Table of Contents (ToC) based on a document’s sections and subsections. The example killer application involves changing the ToC to a more flexible format which, in particular, is able to provide a more accurate model of a hyperdocument. As such, the proposed changes would make such a word processor particularly suitable for the creation and maintenance of web based hyperdocuments that contain embedded hypertext links within and across documents. The goal is to show how a quite small amount of Java programming can enhance the functionality of a pre-existing, Java implemented, software application package that a small software company could feasibly implement.

While not demonstrated in this paper, a closely related type of JOOSSSE application involves changing the way a large Java implemented software application displays its information to end users. End user functionality is modified because how users perceive information is a strong determinant of how they use information. This proposal relies on the Model-View-Controller (MVC) architecture that Java has inherited from Smalltalk and which strongly separates the information model, the display (view) and the control exercised by the program model and by end users. The MVC architecture has become a standard feature of how Java programs are written and is encouraged in nearly all object oriented design methods, including the widely used Unified Modelling Language (UML), which is endorsed, for example, by Microsoft, Hewlett-Packard, Oracle and Texas Instruments (Hunt, 1999, p536).

Section 2 Background to an Example JOOSSSE Application

This section describes the background to what is potentially a killer application that modifies existing Java application software. Whether the proposed application is really a killer one is not germane to the central argument to the paper, although, of

course, it would be nice for this were to be so. Whatever the application’s status, however, the example does illustrate how novel functionality can be incorporated into existing Java software without the need to extensively rewrite the existing code. This approach is therefore particularly appropriate for small software companies who cannot afford to implement complete application packages.

Section 2.1 Hierarchies and Heterarchies

A true hierarchy or tree consists of a number of nodes arranged in levels and where lower level nodes are always one or more unique children of a single, higher level, parent node. Critically, each node is unique. In computer science hierarchies can be formally represent using graph theory. Hierarchies are, of course, a special type of Directed Acyclic Graph (DAG).

In many areas of human endeavour, however, people wish to use representations that appear hierarchical but which violate the hierarchical rule of nodal uniqueness, i.e. nodes are repeated in the representation. This paper will use the term heterarchy to describe such representations that have nodal repetition. Logically, either nodes can be repeated or the links between unique nodes can be repeated, as is done with many hypertext representations (Section 2.1.3).

Figure 1. Three models of a cricket team: 1a - a true hierarchy; 1b - a heterarchy with nodal repetition; 1c – a heterarchy with multiple links.

A typical example of where a heterarchy might be employed is when considering a cricket team of batsmen and bowlers (the wicket keepers are ignored for simplicity). Figure 1a is a true hierarchy in that each terminal leaf node representing a team member (C1 – C11) occurs only once, but at the expense of creating an “All rounder”

node to accommodate team members C7 and C8 who can both bat and bowl. Figure 1b is a heterarchy of the same team which uses nodal repetition to more usefully represent the team. It is more useful if one wishes to immediately see a complete list of batsmen and bowlers without having to compute this by combining the parent nodes to create sets from Figure 1a such as: [All batsman] = [Bat] [All rounders]; [All bowlers] = [Bowl] [All rounders]. Figure 1c is a heterarchy which, like 1b, has only two intermediate nodes and repeats links rather than terminal leaf nodes. Overall it is possible to argue that Figure 1c is the best of the three models in that it does not require the invention of a “false” node for the sake of making the model a hierarchy (1a), yet it can be used to more easily ask questions, post construction, about All rounders by counting links, should one choose to do so.

The following subsections describe some common uses of heterarchies in more computer-centric areas.

Section 2.1.1 Task Analysis

The concept and initial implementation of a heterarchy editor was directly derived from the development of the Liverpool University Task Analysis for Knowledge Descriptions (LUTAKD) toolkit (see the Acknowledgements to the TOM project). In the TAKD method (e.g. Diaper, 1989; Diaper and Johnson, 1989) the main analysis stage involves the construction of the Task Descriptive Hierarchy (TDH). Notwithstanding the first author's comments to the contrary in 1989, the TDH is in fact a heterarchy in that TAKD explicitly encourages the task analyst to copy possible nodes which are potentially meaningful but for which task data has not been collected. Similarly, Hierarchical Task Analysis (HTA) frequently actually produces a heterarchical representation. Even Shepherd's (1989, 1998) tutorial papers on HTA, while containing much on the heuristics of undertaking a HTA, does not address what is meant by a hierarchy, which is assumed to be so widely understood that it does not require definition or explanation.

Section 2.1.2 Software Engineering

Entity Life Histories (ELHs), called Structure Diagrams in Jackson Structured Design (e.g. Cameron, 1983), are widely used in software engineering. For example, ELHs provide one of the three main views of a system in SSADM (e.g. Downs et al., 1988; Eva, 1994)). Nodal repetition within an ELH is not illegal, i.e. an ELH may be a heterarchy. Ashworth and Goodland (1989), for example, show how a parallel structure in an ELH may be represented using such repetition, although they admit that their “diagram is made much more clear by the use of the parallel structure.” (p50) There are cases, however, where it is not merely clarity, but the model of the logical structure of the system which can benefit from nodal repetition.

Figure 2 shows two, partial ELHs for a very simplified banking system. Figure 2a can be considered a traditional model in that monies are either withdrawn or deposited (the o indicating mutually exclusive, alternative actions and the * iterations). While extremely straightforward, the terminal leaf node “Calculate balance” is repeated. Figure 2b is a redescription of 2a’s model and is a true hierarchy in that every node occurs only once. While there may be circumstances where 2b is to be preferred, this

figure achieves its hierarchical status at the expense of losing the withdraw/deposit distinction and is far harder to read, not least because it fails to explicitly relate the matching pairs under the “Submit” and “Issue” nodes, e.g. it does not indicate that after depositing cash and calculating the balance the proper operation is to issue a receipt and not cash.

Figure 2. Partial Entity Life Histories for a simplified banking system: 1a – a heterarchy with nodal repetition; 1b – a hierarchy.

Section 2.1.3 Hypertext and Hypermedia

Fundamental to the concept of hypertext is that a hyperdocument may be read in different ways by readers choosing the links that they will follow. It is not uncommon, however, for it to be desirable to produce a linear form of a hyperdocument (e.g. Rada and Diaper, 1991) and a linearisation algorithm should produce a traditional document where each node, containing part of the hyperdocument, is produced only once.

One experimental use of LUTAKD’s TDH editor that had nothing to do with task analysis (section 2.1.1) was to use it as an outliner. Outliner software allows authors to create document structures and these structures are true hierarchies, i.e. they allow the production of a structure that resembles a linear book’s ToC. Most modern word processors provide the user with the option of displaying two windows simultaneously, one containing the document and the other its ToC (Section 1). A second common word processor facility in most current applications allows users to embed hypertext links within sections of a document. These two facilities are in conflict as the hierarchical ToC no longer accurately represents the document structure as a reader may access it. This is because the reader can choose to follow each hypertext link on encountering it, eventually returning to the place in the document where each link was encountered, i.e. while reading section X, the reader follows an embedded hypertext link to read section Y and then returns to section X.

The situation becomes even more complicated when section Y can be accessed through more than one hypertext link, and while this latter situation is not naturally supported by HTML, it is not difficult to implement.

3a

3b

Figure 3. Models of the structure of a hyperdocument: 3a – a semantic net; 3b – a hierarchical Table of Contents on the left and a heterarchical one on the right.

Figure 3a shows part of a hyperdocument that illustrates both these properties. Each section of the document, which could be stored in separate HTML files, consists of a start node (light grey) and a finish node (dark grey). Sections 1, 1.3 and 2.1 contain embedded hypertext links. The situation is straightforward for section 1 in that a reader may choose to look at section1.1 while reading section 1, or not. Similarly for section 1.3 w.r.t. section 1.3.1, however, that section 2.1 also has a link to section 1.3.1 creates a more complicated situation which a human reader may not recognise, and which is difficult for a linearisation algorithm to cope with. Indeed, a hierarchical ToC cannot even adequately represent that section 1.1 naturally occurs within section 1 and such a ToC would appear as in the left hand side of Figure 3b.

The right hand side of Figure 3b illustrates a heterarchical ToC that accurately represents the document structure of Figure 3a. The conventions, while not themselves important to the purpose of this paper, involve using lower case letters (a, b, c, etc.) after section numbers and “(cont.)” after section titles to indicate a continuous section of a document that contains hypertext links that may be optionally traversed; multiple links to a document section are indicated by using italics and the original section numbering followed by one or more prime (‘) symbols, one for each additional link. A linearisation algorithm would ignore italicised sections marked with a prime thus fulfilling its desideratum of producing the complete document without repetition of sections of text.

Section 3 The Heterarchical Table of Contents JOOSSSE Application

Grand (1998) uses the design, in UML and Java, of a standard word processor as an illustration of the use of Design Patterns. The approach taken by Design Patterns is different from the JOOSSSE approach although they are related. Design Patterns are intended to allow experienced programmers to reuse patterns to solve recurring problems. In contrast, JOOSSSE is intended for the construction of new applications by the modification and extension of extisting, large software packages written in Java. Figure 4 shows Grand’s original “Table of contents classes” in grey and makes use of his proposed Visitor class. As it is a model of a standard word processor, Grand’s design produces a hierarchical ToC.

To produce a heterarchical ToC as described above (Section 2.1.3), the advantages of Java’s object oriented nature (Section 1) can be exploited such that producing such a ToC involves only the modification of the TOCVisitor class and the addition of one new object, the HypertextLink object, similar to Grand’s Document, Paragraph and LineOfText objects. These changes are shown in black in Figure 4. What is obvious in Figure 4, and demonstrates the power of Java’s object oriented nature, is how little requires changing.

Changes to TOCVisitor can be summarised using Grand’s description (p388). In keeping with the colouring convention of Figure 4, Grand’s description is quoted in grey and the changes are indicated in black:

TOCVisitorNew This subclass of the DocumentVisitor class is responsible for generating a heterarchical table of contents. It works by examining each Paragraph object and HypertextLink object that is directly owned by a Document object. When it finds a Paragraph or HypertextLink object that has a style that is in the internal heterarchical ToC tables, it generates a corresponding heterarchical table of contents entry. The heterarchical table of contents entry uses the contents of the first LineOfText or of a HypertextLink object that belongs to the Paragraph object.

Grand’s final listing of the Java code of TOCVisitor consists of 33 lines of code of which about one third is non-functional in that these lines indicate the termination of iteration (If) and conditional (While) statements. Grand’s TOCVisitor “navigates more deeply into a document’s object structure, concerning itself with Document objects, Paragraph objects and LineOfText objects. Its interests in LineOfText objects is that a table of contents entry will contain the text of the first LineOfText

object in the paragraph that the table of contents entry corresponds to.” (p394-5) In addition to this, TOCVisitorNew must be able to use the HypertextLInk object’s identification of hypertext links and modify the TOC so that paragraphs may be split so that the terminal letters (a, b, c, etc.) can be appended to section numbers and “(cont.)” added to their titles. TOCVisitorNew must also generate TOC sections and subsections corresponding to the first line of paragraph text following hypertext link traversal. TOCVisitorNew must also be able to recognise multiple links to such a subsection and italicise and append one or more primes to the section numbers in cases where there is more than one link.

Figure 4. Reproduction of Grand’s “Table of contents classes.” for a word processor in grey and the modifications necessary for the production of a heterarchical Table of Contents in black.

Alternative styles to the one proposed in this paper can equally easily be implemented. Alternatively, a stronger version of the MVC architecture (Section 1) than that employed by Grand will allow different heterarchical TOC formatting conventions to be displayed without changing a more general version of TOCVisitorNew. Given the size of Grand’s TOCVistor class, even with relatively clumsy programming, TOCVisitorNew is likely to require less than 100 lines of Java code.

The new HypertextLink object must, of course, be able to recognise hypertext links. Where the document is in HTML then this can be done by recognition of HTML strings such as: <A HREF=” and <BASE HREF=”. Slightly more sophisticated solutions may be needed to accommodate other hypertext document formats but overall the programming of the HypertextLink object is still relatively straightforward.

Quite properly, and particularly suitable for small software companies, the production effort will primarily be in the design of new objects and classes as the actual amount of Java programming will in most JOOSSSE applications remain extremely modest.

Section 3.1 Further Work

The first advantage of a heterarchical ToC compared with a traditional, hierarchical one is that it provides to end users a more accurate description of a hyperdocument’s structure. A heterarchical ToC can replace in web pages the numerous styles of buttons, HTML links and so forth that are currently used with more or less success to aid user navigation within web hyperdocuments.

A second major advantage of a heterarchical ToC is that, because it is produced from the hyperdocument’s contents, maintenance of it as a navigational aid is automatic. Thus, if the contents of a hyperdocument are changed then the heterarchical ToC will also change. This would ameliorate some of the identified, formal problems of hyperdocument maintenance (e.g. Bench-Capon and Dunne, 1989) of which many web authors are apparently unaware.

Third, once the creative idea for one JOOSSSE application has been seen, it is likely that related ones will naturally occur to people. The ideas behind the heterarchical ToC (Section 2) are based on the work of the authors and others on hypertext systems in the 1980s and before the invention of the web. Many current web document authors are apparently unfamiliar with this early research. To give an example of a related JOOSSSE application to the heterarchical ToC, further work may now progress on the automatic linearisation of hyperdocuments and, in particular, the production of different linear versions for different people and purposes, as suggested, for example, by Diaper and Beer (1990). Such JOOSSSE linearisation programs could, for example, replace the manual navigation currently required within most available web sites.

Finally, a version of the heterarchical TOC that uses a stronger MVC architecture than Grand’s would allow companies to customise the appearance of their heterarchical TOC navigation aid thus providing their web sites with a distinctive and consistent look and feel at little cost.

Section 4 Conclusions

Obviously the replacement of a traditional ToC with a heterarchical one can be argued to be only a minor change in the application software. On the other hand, as argued above, such changes can have a significant impact on perceived software functionality, i.e. how the software is seen and used by authors and end-users. What we believe is uncontroversial about the design of our heterarchical ToC is that it demonstrates that existing software can be enhanced by the production of program code that is well within the resources of small software companies. The JOOSSSE approach is able to do this because it explicitly relies on the three “strongly encouraged concepts” associated with Java described in Section 1.

The primary, potential problem with the JOOSSSE approach to software development is likely to be a commercial one. It is, of course, essential that the main application’s

class and object interfaces are available to small software companies who wish to exploit the market niche that JOOSSSE applications are intended to fill. The arguments for Open Systems have been previously well rehearsed (e.g. Elliman and Sanger, 1991). What may encourage the owners of these primary application packages, generally the VLSCs, to accept the publication of their Java object interfaces is that JOOSSSE application extensions will only operate within the context of their main software application packages. Thus the VLSCs cannot lose revenue as their software is essential for running a JOOSSSE application developed by a small software company and their current anti-piracy protection mechanisms will not be compromised. Indeed, it is possible that the existence of JOOSSSE applications may increase a VLSCs market share of their software packages at no cost to them. While the cynic might suggest that the past behaviour of VLSCs such as Microsoft (e.g. Rohm, 1999) would appear to indicate that anything that will support other software companies is anathema to them, international Open System standards, supported by anti-monopoly legislation, may force compliance where rational argument fails. The very existence of the JOOSSSE approach identifies the necessity for the widespread publication of Java interface specifications.

Acknowledgements

The TOM project (Task Oriented Modelling for Interactive System Design) was a collaboration between Logica, British Aerospace, University College London, Queen Mary and Westfield College, and the University of Liverpool. It was lead by Logica Cambridge Ltd. and was funded under the United Kingdom’s Government’s Department of Trade and Industry (DTI) and Science and Engineering Research Council (SERC) Information Engineering Advanced Technology Program (Grant No. IED 1/4/1717). The views presented in the paper are those of the author and should not be assumed to be shared by other partners on the project.

References

Ashworth, C. and Goodland, M. (1990) SSADM: A Practical Approach. McGraw-Hill.

Bench-Capon, T. and Dunne, P. (1989) Some Computational Properties of a Model for Electronic Documents. Electronic Publishing, 2, 231-256.

Brooke, J. (1993) User Interfaces for CSCW Systems. in Diaper, D. and Sanger, C. (Eds.) CSCW in Practice: An Introduction and Case Studies. 23-30. Springer-Verlag.

Cameron, J.R. (1983) JSP & JSD: The Jackson Approach to Software Development. IEEE Computer Society Press.

Diaper, D. (1989) Task Analysis for Knowledge Descriptions (TAKD): The Method and an Example. in Diaper, D. (Ed.) Task Analysis for Human-Computer Interaction. 108-159. Ellis Horwood.

Diaper, D. and Johnson, P. (1989) Task Analysis for Knowledge Descriptions: Theory and Application in Training. in Long, J. and Whitefield, A. (Eds.) Cognitive Ergonomics and Human-Computer Interaction. 191-224. Cambridge University Press.

Diaper, D. and Beer, M. (1990) Headed Record Expertext and Document Applications. in Hypertext Update. 63-69. UNICOM Seminars.

Diaper, D. (1994) Small Scale CSCW Systems in Spurr, K., Layzell, P., Jennison, L. and Richards, N. (Eds.) Computer Support for Cooperative Work. 89-198. Wiley.

Diaper, D. and Beer, M. (1995) Collaborative Document Annotation using Electronic Mail. Journal of Computer Supported Cooperative Work, 3, 297-325.

Diaper, D. and Sahithi, P.S. (1995) Red Faces over User Interfaces: What Should Colour be User For? in Kirby, M.A.R., Dix, A.J. and Finlay, J.E. (Eds.) People and Computers X. 425-435. Cambridge University Press.

Downs, E., Clare, P. and Coe, I. (1988) Structured Systems Analysis and Design Method: Application and Context. Prentice Hall.

Elliman, T. and Sanger, C. (1991) Open Systems for Europe. Chapman & Hall.

Eva, M. (1994) SSADM Version 4: A User's Guide. 2nd. Edition. McGraw-Hill.

Grand, M. (1998) Patterns in Java: A Catalog of Reusable Design Patterns Illustrated in UML. Wiley.

Hunt, J. (1999) Java for Practitioners: An Introduction and Reference to Java and Object Orientation. Springer.

Rada, R. and Diaper, D. (1991) Converting Text to Hypertext and Vice Versa. in Brown, H. (Ed.) Hypermedia/Hypertext and Object Oriented Databases. 167-200. Chapman and Hall.

Rohm, W.G. (1999) The Microsoft file: The Secret Case Against Bill Gates. Times Business: Random House.

Shepherd, A. (1989) Analysis and Training in Information Technology Tasks. in Diaper, D. (Ed.) Task Analysis for Human-Computer Interaction. 15-55. Ellis Horwood.

Shepherd, A. (1998) HTA as a Framework for Task Analysis. Ergonomics, 41, 11, 1537-1552.

StarOffice http://www.stardivision.com/