Download Small Scale Software Engineering (S3E):

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,
1
Bournemouth University.
Department of Computer Science,
2
University of Liverpool.
Abstract
JOOSSSE (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. McGrawHill.
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. SpringerVerlag.
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/