On Designing Intelligent Systems for Information in Software Engineering
Hypertext Management
Pankaj K. Garg and Walt Scacchi Computer Science Department University of Southern California Los Angeles, CA 90089-0782 garg or
[email protected]
ABSTRACT Information systems
are best suited for this purpose
in the nodes results
of a hypertext.
system
that
system
might
could
System
utilize
albeit
useful
can use such knowledge
design of an I-SHYS use of I-SHYS
organizing
[in
terms
terms
the design
and theiT
methods
system
of the ‘agents’
describe
that
software
perform).
called
tasks
process,
knowledge
We present
uses of such knowledge,
rather
Such
Hypertext
defined
a framework
GOT
limits
and
embedded
and partly
of
a
being
than
its environment
is partly
identify
Based
a hypertext
Software
about
tools
DIF.
and products.
an Intelligent
suppoTts)
I-SHYS
engineering
foT developing
is knowledgeable This
Hypertext
types that is permitted
of such a system
we define
process.
problem.
software
with
in the software
which
that
agents
potential
cbcumventing
jot
As such,
in the software
of tasks
system
the need and the potential
its users
facility.
hypertext
to assist
this knowledge,
and suggest
1
(in
about
stoTage
as a software
(I-SHYS~)
We descn’be
we recognized
knowledge
is a challenging in information
of a hypertext
be able to act as an active participant
then
a passive,
system.
in using DIF,
engineering
because of the diversity
The integration
in a software hypertext
on our experiences
just
in IaTge scale soflware
management
in the
during defining
OUT
the and
approach,
them.
INTRODUCTION
Hypertext
systems are useful for information
of the diverse types of information
management
permitted
in large scale software engineering
in hypertext
nodes [BEH*87].
related to a software system is stored in the same hypertext A Software
Hypertext
conjunction
with
Environment
System which
various
software
of the hypertext
1 Pronounced
November1987
engineering
tools, provide
the facilities
of a software
an Integrated
(hypertext
of tools for automated
system can be used for storing
If all the information
then we call it a Software Hypertext.
the management
[Hen86]. The advantage of this combination
tools) is that one can exploit facilities
supports
because
hypertext
Software
can, in
Engineering
system + software engineering processing
and retrieving
of information, information.
while We have
eye-&s
Hypertext‘87 Papers
409
designed and implemented System Factory
such a software life cycle Documents
with
DIF led us to the notion
(I-says).
DIF is a passive system with little
In
we wish to design an active hypertext
of engineering
Facility
(DIF)
in the
at USC [GS88].
Our experiments
I-SHYS
Integration
large software
explicit
of an Intelligent knowledge
Hypertext
about its surrounding
which participates
system,
systems throughout
Software
their life cycle2.
System
environment.
and assists in the process
As such, a software
hypertext
enviTon7nent consists of 1. The software hypertext;
engineering
tools that process documentable
software
descriptions
stored as a
and
2. The software engineering If we encode knowledge system can actively
tasks that people perform
about the hypertext
assist in the activities
System. For an Intelligent
through
environment
into the hypertext
of its environment,
Software Hypertext
System
it. system, such that the
then we get an Intelligent we have identified
(I-SHYS),
Hypertext
three perspectives
of such knowledge: 1. Knowledge
of the capabilities
and uses of software tools that the environment
2. Knowledge
about the roles people play in the software process;
3. Knowledge
about
the tasks and actions
people perform
at different
stages
provides;
in the software
process. Before we can formalize software regard. overview
and encode such knowledge
process from these perspectives.
of a Software
tools with a hypertext
Section 3 describes the software process by categorizing the tasks that they perform, on a software hypertext. Finally
2
in Section 4 we summaize
DIF is a software hypertext used throughout experimental
410
simplicity, throughout
System by giving
an
system are discussed in this section.
the roles of agents in the process, describing
which can be used to categorize interactions.
LIFE CYCLE DOCUMENTS system which helps integrate
INTEGRATION
“software
process”
FACILITY
and manage the documents
produced
and
It was designed for use in the System Factory, an
created at USC to study the development,
we use the term their life cycle.
in this
the discussion and suggest future work in this direction.
the life cycle of software projects.
laboratory
Hypertext
understanding
the
how their tasks can be broken down into actions performed
It also discusses the attributes
DfF: A SOFTWARE
aFor systems
and detailing
we need to understand
I-SHYS,
This paper describes our current
In Section 2 we present our understanding of DIF. Issues about interfacing
in an
as shorthand
Hypertext‘87 Papers
for
the
use, and maintenance process
of engineering
large
of large software
November1987
software
systems [Sca86]. It has been used in the System Factory
for more than a dozen software
systems, resulting
in the creation
to support
the software process
of some 40Mbytes
of software
hypertext3. DIF provides an interface documentation
to a hypertext-based
process. A hypertext
over eight life cycle activities. related
to a software
nodes are internally
DIF
support:
into pre-defined
document
below enabIe software
(e) documentation
traceability, standards,
reusable software component The integration For instance,
manipulating
software
System’ envisioned
(e.g., creation
by DIF.
to document
their
In total,
software
of formalized
and display, documents
(d) indexed
information
nodes as files and directories for the “operational
handled
descriptions
by DIF. without
nodes, (b) intra-
of persistent
of files and directories.
browsing,
annotations,
(g)
and walkthroughs.
is invisible
to the user of DIF.
of the system, the user
the operational
The user need only be concerned being concerned
of
process in ways that
sharable
requirements”
the text associated with
of directories
or query-driven
with/without
that
the capabilities
document
catalogs, and (h) online software inspections
This provides an object oriented environment simply a loose collection
nodes of a software hypertext
file management
and completeness
(f) multi-version
The document
and files (see Figure 1). Users of DIF enter
nodes) is handled
does not have to create the file for storing this chore is automatically
all routine
(c) formatting
of software hypertext
when entering
by teams of software engineers
and across projects.
(but redefinable)
engineers
(a) analysis of the consistency
and inter-document
manner within
organized as a tree of Unix directories
of files for related
described
is built
and to a structured
DIF provides several features which allow users to view information
treated as files. Subsequently,
and naming
storage structure
of software information
system in an integrated
software process information are internally
information
requirements;
with
creating
or
about how they are stored or where.
software system descriptions
This is reflective
rather than
of the ‘Next Generation
Operating
by Balzer [Bal86].
DIF also allows software engineers in the System Factory to develop parts of documents in parallel without
worrying
about concurrent
the operational requirements. 2.1
requirements The individual
System
Factory
The organizational System Factory turn,
the project
the software hypertext. 3 We have documentation,
November1987
of the target
issues. Hence person A could be writing
system while person B is writing
efforts are automatically
the non-operational
merged in the same hypertext.
Structure
structure
these prescriptions
access or integration
supported
by DIF in the System Factory
manager prescribes
implicitly
is shown in Figure 2. In the
what needs to be described
in each document.
represent the software process in effect within
There are also potentially
several projects in the factory
also utilized its facilities to “publish” hard-copy, where one complctc printing produced a series
Hypertext‘87 Papers
laser-printed of listings
renditions about 4 feet
the structure
In of
at the same time.
of this encyclopedic tall after binding.
software
411
Figure
Several
software
engineers
same software DIF
define
DIF
a general
(what
of the documents
(what
2.2
Forms
Basic
User defines
of the System
Factory
can be constrained
User role and a General
are in the factory
needs to be documented). through
the information
(1) at the information
The rest of this section and
and all projects
in DIF
and end user respectively.
proj&cts
and browse
user can operate:
a Super
administrator
level.
A Super
412
to the database
modify,
Documents
to follow
the
process.
structure
to create,
of Software
on each project,
two roles for users:
the factory
structure
work
(documentation)
supports
be compared
1: Hypertext
describes
level,
the functionalities
User role.
In the Super
and who is responsible In the General hypertext.
The
User role, users for each), and the
User role,
There
two roles can
users exploit
are two levels
at which
and (2) at the structure-of-the-information of DIF.
Templates
the forms
and the Basic
was to ensure
that
Templates
all the projects
Hypertext ‘87 Papers
(BTs)
in the factory.
One of the concerns
have the same (standardized)
structure
November 1987
of
I..
Software
Engineers
Figure
documents.
Basic models
Thus
Templates
each document
(BTs)
the software
specifications
form
is shown
be followed
by team
with
or tasks in Table
members
Users)
2: System
Factory
as a form.
is defined
to be filled
process,
(General
A form
For example,
therein.
on related
Section Number Overview and summary of functional Informal narrative specification Narrative specification Functional diagrams
is a tree structured
A collection
information.
1. Such forms
working
Structure
provide
The Super BTs entails
User defines
the super providing
*Narrative *Graphical
November1987
the attribute
Text Diagrams
the nature of the BT
Section specification
the process
tasks
to
that
Heading
1.0 2.0 2.1 2.2 2.2.1 2.2.2 2.2.3 3.0 3.1 BT Heading
Specifications
of information as being
the functional
projects.
Form
each form only once and all the projects
user also defines
of
then implicitly
Factory,
a way of specifying
Functional network diagrams State-transition diagrams Formal specification Gist Processor Results BT Number 1: Functional
of related forms
in the System
Type lattice
Table
organization
inherit
that
form.
needs to be given
When
defining
in each BT.
This
one of:
l NuMIL Structural Specifications l Gist Functional Specifications
Hypertext‘87 Papers
l C Source Code l Executable Object
Code
413
This tells DIF which editor (e.g., a Gist language-directed tools to process the information
2.3
Project
Information
on them.
This information
which consists of a list of projects and the software engineers enables DIF
General users are allowed to create, modify, There is no restriction privileges
2.4
on reading
to check the read/write
and revise information
the information
of any project.
privileges
of the users.
related to their projects
only.
Super Users have read/write
for all information.
Information
Facilities
to use for a BT and which software
of the BT.
Super Users provide project information working
editor)
Level
are provided
in DIF for a user to enter, modify,
and use the information
forms as dictated
by the super user. Language-directed
emacs-like
formal
that are used in the System Factory
(e.g., Gist, NuMIL,
languages
general user enters the information DIF automatically
in BTs without
worrying
required
editors are provided
by the
for aIl the
and C [ScaSS]).
The
about the fles that need to be created.
generates a unique filename depending
on the project
and the BT.
Whole forms can be stored in the revision control system, RCS [Tic82] for backup and incremental revisions.
Functions
supported
by DIF (through
RCS) include:
1. Checking
in of a form. The user can ask DIF to check in a form into RCS.
2. Checking
out of a form. The user can check out a whole form from RCS.
0,ptions
such as retrieving
through
the interface.
that it interfaces
revisions
through
This is an example of ‘interface
cut-off
transparency’
entering
request its compilation.
that DIF provides for the tools
the operating
in a BT through
a software tool can be made within
For example,
system.
Some such requests are handled
if a BT contains
through
to nroff/troff,
the documenters synchronous
workbench
communications
tory (e.g., application
among project
the user with a text processing
computer
participants. animation
Other tools available environment)
[Sta84], some are
tool as opposed to a Unix tool). environment
[Dwb], while interfaces to mail, rn, and talk, support
generators,
with DIF in a straightforward
414
spell, etc. provide
akin to
asynchronous
and
in the System Fac-
[Sca86] can also be interfaced
manner.
Hypertext‘87 Papers
DIF
C code, the user can
editor interfaces
built into DIF (those which require the service of a System Factory Interfaces
dates, etc. are available
to (section 2.6).
Request to process the information itself without
user defined identifiers,
November1987
2.5
Structure-of-Information
Level
The structure-of-information4 information
level allows the general user to navigate
1. Links:
through
the information
The user (super or general)
the links allowed add annotations operational
by most hypertext to the currently
requirements
capability.
hypertext
of
can define links between BTs. systems.
visited
The links are similar
Hence a person browsing
the hypertext
BT, add links to other BTs, etc. For instance,
provides a mechanism for maintaining
that support
consistency
to can the the
and traceability
of links prevalent
in
[Con871 and those in DIF:
Links define relationships from creating
between existing
nodes. Except for annotation
links, links are
new nodes.
Links are allowed to be operational descriptions
ways:
There are two key differences between the definition
literature
precluded
in a project in the following
of the system can be linked up to the code/modules
This, therefore,
across documents.
l
the hypertext
that is stored in DIF.
The user can navigate
l
through
need to be linked
links.
This readily supports the cases where executable
to the source code.
For example,
a C code BT can be
linked to the object code BT that represents that code. Such a link is defined in DIF as an operational
link.
shell procedure 2. Keywords:
attachments
that link results in the execution to links will be supported
in that BT. The decision to allow for user defined keywords rather than
automatically
generated keywords was based on the results of studies reported
DIF to use the querying
associated facilities
with BTs in an Ingres relation.
of Ingres for navigating
For example, the user can look for all BTs (within
through
This allows the user of
documents
and across projects)
using keywords.
which have a particular
list the keywords of a BT, search for BTs which have keywords satisfying
etc. Standard
function&ties
such as form-based
querying
are provided
a pattern,
by DIF for users not
in Quel [Que].
An interesting
feature of DIF is that it allows the reader of documents
of their own. This allows new personnel
in a project
team to quickly
also to create keywords tune the documents
their needs. ‘This is diRerent from whereas here the structure
November1987
by
science [Sal86].
DIF stores the keywords
trained
in future versions of DIF.
contained
researchers in information
keyword,
of the linked BT. Arbitrary
For each BT the user can define keywords which describe the semantics of the
information providing
Visiting
In a schema the structure a ‘database schema’. is dependent on the currently defined links.
Hypertext‘87 Papers
does not change
with
the information,
415
to
3. Forms
and Configurations:
the user with
A Form is a tree-structured
organization
a convenient
way of viewing
the documents
the potential
of the hypertext
of information
relating
of BTs. This provides
to each software
process
activity. To fully utilize
of BTs.
own configuration
A configuration
to a form, except that it is not enforced
on all projects
but is associated with the individual
Configurations
can be defined, not unlike forms, by defining
user who is browsing
the documents.
the constituent
BTs. Configura-
tions can also be defined on the basis of the trail
which a user has followed
through
are mainly
the information
ing hardcopy
hypertext.
documents,
The user information use the information
space is restricted
of another
one that is being visited. visited.
Configurations
much like the path facility
to the project currently
level commands
Structure-level
information
guidance,
the current
project
used as a mechanism
for print-
being ‘visited’
by the user. To
visit that project.
This means that
on the information
of projects
other than the
is available regardless of which project is being
This is done to avoid the risk of the user getting
an additional
while browsing
suggested by Trigg [Tri83].
project the user has to explicitly
the user cannot use the information
2.6
is similar
in DIE’, the user can define his/her
lost in the information
and BT are displayed
space [Con87].
As
in the main menu.
DI F+Tools
The basic idea in DIF is to provide a system such that all the life cycle activities DIF itself.
In this sense, DIF can be considered
the progress of the target a uniform
interface
analyzer. or NuMIL transparency’ mechanisms
software
system through
to access the appropriate Processor.
a software engineering
i.e., DIF provides
unobtrusive
environment
[Hen86].
the various life cycle activities,
tools as necessary,
In the interfaces
can be done through
DIF provides
e.g., a functional
to these tools, it supports
specification
the notion
use of the tool that it interfaces
With
of ‘interface
to, while providing
that the tool itself lacks.
Figure 3 shows the organization
of DIF with respect to the other tools in the System Factory.
The basic set of tools comprises [S&86]: 1. A Gist Specification formal functional 2. A Module evolution
Analyzer
and Simulator
specifications
Interconnection of multi-version
which facilitates
of software (sub)systems
and Interface system (module)
Definition
the development
under development
[BGW82,Sca85];
processor that supports
configurations
described
and use of the
the design and
in the NuMIL
language
[NS87b,NS87a]; 3. An EMACS-like revision
language-directed
of structured
documents
editing
environment
and system description
which
helps in the construction
languages such as Gist, NuMIL
C; and 416
Hypertext ‘87 Papers
November 1987
and and
GIST Specifications Analyzer
Information
Bank
$1
Figure 4. A system
visualizer
which
‘-2q
3: Organization
graphically
presents
of DIF system
configurations
expressed
in NuMIL
[~~87]; 5. Unix
tools
system
such as Rcs, Make,
helps
individuals
Spell,
Nroff/Troff,
to coordinate
their
Talk
and Mail.
activities
The interface
by structured
to the mailing
messages
consisting
of
BTs. DIF
supports
the notion
of Eziensibility
in its interfaces
to tools.
It is simple
to add new tools
to the environment.
Tool
Options:
Most
the application ‘g’ option
at hand.
which
by the symbolic of informing taking compiled only
informs
generate
November1987
The
appropriate
switches
that
of “switches”
compiling it should
but
system
generate
way to view
in which
being
is also useful can store
for the compiler.
in other
this information As another
Hypertext‘87 Papers
places
table
information
is to consider
informed
as means
of information that
such as reporting and then
consider
for
to be used
them
Such information
generically, example,
of the tool
the user can give a
the processing
is being
debugged.
the behavior on Unix,
symbol
the switches
case, the compiler
one and is currently
to tune
a C program
of the environment
in the above
of the switch hypertext
while
An interesting
of some aspect
is an experimental
the project.
for the input
the compiler
For example,
for purposes
allow
For exam;.,ie,
debugger.
the tool
place.
tools
is
the code being is required the status
not of
‘automatically’
the ‘c’ option
of the C
417
compiler
on the Unix system, which informs
system and the compiler another
design of the system.
This information
at
need be given to
places. This is currently
not provided
for I-SHYS.
Summary
In this section we have presented an overview documents
of a Hypertext
ways in which
and suggested interesting
System to manage software life cycle
smart interfaces
to software
vided in such a system. Our next concern is that the process model considered it by way of Forms and BTs) is at a level of granularity repository
and processing environment
ware process.
In the following
too high to provide
that organizes document
section,
paper is semi-formal;
a formal presentation
AGENT-TASK-PRODUCT
into its network
users play when performing
agent
be knowledgeable simulate
that
nor can it explicitly
different
participates
developed
to
but a passive through
a soft-
down the process model into
by an I-SHYS.
of interacting
represent and utilize
The treatment
in this
PROCESS descriptions
with its users to help elicit knowledge
of what roles its
software process tasks. Instead, we would like to have a system of DIF, but does so in ways that it can eventually
in the software
Thus,
process.
about its users, their tasks and products,
and represent knowledge
process. Agents are people or intelligent
such a hypertext
become
system should
and be able to ask/answer
software process tasks, and to reason about and explain
We first seek capture
anything
system in that it waits for users to enter software
that not only subsumes the capabilities an active
by DIF (described
OF THE SOFTWARE
of linked nodes. However, it is incapable
emerging software descriptions,
tools can be pro-
is given in [Gar87b].
PERSPECTIVE
DIF is a passive software hypertext
products
we describe ways of breaking
finer grained actions such that they can be better supported
3
is required
Hence, the information
system only once and it can use it at multiple
by DIF and is planned
2.7
that the code in the file is part of a bigger
should not load the file using a loader.
level, viz. the architectural
the hypertext
the compiler
questions,
its behavior.
about the ‘agents’ participating
in the software
systems that play well defined roles. An individual
in the
software process can play the role of more than one agent. For example, a person who has designed, implemented,
and used a personal database management
manager, and a user. We consider the following
system is at once a designer, implementor,
four categories of agents [GLB*83]:
1. Users: Agents who will use the target software system (end users) and/or the system developed 2. Managers:
Agents
roles of managers
(clients). who are responsible
that
we consider,
the process (Process Manager, process (Quality-Assurance 418
agents who want
PM),
Manager,
for software
project
agents who coordinate
management. the activities
and agents who analyze and evaluate
There
are two
of other agents in the status of the
QAM).
Hypertext ‘87 Papers
November 1987
3. Developers:
Agents who develop the system. Their tasks involve design and innovation,
they transform
the Users’ requirements
roles including
Analysts,
4. Maintainers:
into a working
Specifiers, Designers, Implementors,
Software systems are frequently
ments or discovery
target system.
modified
of errors in system development.
tions, but may not have participated
Developer
to take care of changes in the requireMaintainers
as the system’s initial
take care of such modifica-
developers.
and Developers
in the process:
of this categorization
each function
the existence
intertwined
to the Manager
to the End User, Maintainer,
in the new framework).
The advantage
preclude
and (2) G eneral User (equivalent
in the new framework),
agents play
Testers, and Integrators.
Notice that DIF considered only two categories of agents: (1) Super User (equivalent and Client
where
is that it helps us conceptualize
viewed as a task associated
of interactions
with
the functions
one kind of agent.
of agents
This does not
between agents, which become necessary when agents have
tasks.
The next step is to identify
the software process tasks of agents and to see how an I-SHYS
can
assist them. For this purpose we define: l
Meta-tasks
which
the software
process.
organizational l
define the nature, Much
perspective
configuration,
and possible orderings
of this is based on our study
yses of software engineering
l
Actions
l
Primitive
borrowing
and from definitions
from our empirical
prevalent
anal-
in the software engi-
(e.g., see [Boesl]). in order to fulfill
actions which can be performed
the commitments
on a hypertext
but creation
of some commitment
of a sorting
program
[McD85].
of tasks.
system.
between an action and a task is that a task represents
which entails the fulfillment an action;
[Sca81,BS87]
that need to be performed
The distinction
process from an
[Sca84].
Product tasks that agents in the software process perform,
neering literature
of the software
of other tasks in
the action of an agent
Hence, creation of a sorting program is
by an agent, A for sorting
the flies on,a tape, T is a
task. The following
3.1
sections elaborate
this categorization.
Meta-Tasks
Meta-tasks
are all performed
agent does not necessarily following November 1987
meta-tasks
by an agent assuming the role of a ‘Manager’. have a one-to-one
have been identified
mapping
with
the individuals
We reiterate
that an
in the process.
[Sca84, p. 461:
Hypertext ‘87 Papers
419
The
l
Planning(PM5):
l
Organizing(PM):
l
Stafling(PM):
Assigning
l
Directing(PM):
Giving
of uncertain
Detailing
the tasks that need to be performed
Allocating
resources to the agents.
agents to tasks. help to other agents in terms of what decisions to make in situations
or incomplete
l
Coordinating(PM):
l
Scheduling(PM):
l
Validating(QAM):
l
Verifying(QAM):
in the software process.
information.
Getting
groups of people to work collaboratively.
Assigning
time constraints
Confirming
on tasks.
that the running
C on fi rming the consistency,
system meets the requirements completeness,
and integrity
of the Users.
of evolving
software
descriptions. Each meta-task
has a document with
or processable description Accordingly,
it.
associated
knowledge
about the software process, and their relationship
in order to be capable of providing 3.2
Product
Product
to other meta-tasks
the Users and guidelines
tasks
active participation.
Definition
2. Requirements
Analysis
3. Functional
5. Detailed
a Maintainer,
change the system
of Users. Developers build the system using requirements
posed by
in this regard:
(Clients) (Analysts)
Specifications
4. Architectural
for the system and use the system. Maintainers
suggested by PMs. Several tasks can be performed
1. Requirements
(Specifier)
Design (Designer)
Design (Designer)
6. Implementation
(Implementor)
7. System Integration 8. System
source of
and product
related tasks are carried out by agents assuming the role of either a Developer,
based on emerging requirements
6Agcnt
needs to encode a different
Tasks
or a User. Users pose requirements
420
each meta-task
structure)
(e.g., plans, schedules, work breakdown
Delivery
category
(Integrator) (Integrator)
responsible
for the task
Hypertext ‘87 Papers
November 1987
9. System Use (End User) 10. Fixing
bugs in the system (Maintainer)
11. Creating
revisions
12. Enhancing
of the system (Maintainer)
the system (Maintainer)
13. Creating
new versions of the system (Maintainer)
14. System bug discoveries and reporting 15. Testing
(Tester)
16. Requesting The definition
Enhancements
upon its completion.
integrity
on the system (End User).
of these tasks can be found in any book on software engineering
As before, each product
help elicit
(End User)
In turn,
the pertinent of intra-
task has an associated document forms with
software
and inter-tasks
information
methods attached
in order to evaluate
result in a task diagram
of tasks of the three agents:
Maintainers,
example of a task of PM and that of a specifier elaborated.
completeness,
and
as shown in Figure 4. The figure Developers,
For a detailed
Th e intertwining
to requirements
as discussed in section 3.5.
November1987
are needed in order to
consistency,
related tasks, the reader is referred to [SBB*86]. of interaction
that is produced
products.
The tasks viewed from this viewpoint shows the distribution
computational
or software description
(e.g., see [Boe&l]).
and collaboration,
Hypertext‘87 Papers
and Users, with
account
of tasks of multiple
an
of the process agents leads
421
t : l .
3.3
Actions
Actions
are obtained
Corn the definition
agent in order to effectively
of tasks by detailing
the steps that need to be done by the
carry out the task.
As an example consider the Develop
functional
specifications
task in Figure 4. This task
can be broken down into several actions [Ben87]: l
Understand
Users’ requirement
l
Understand
functional
l
Develop informal
l
Access library
l
Develop formal specifications
l
Develop a specifications
Each action
specifications
of exemplar
can be carried
Figure 4) indicates
that:
A cannot be effectively can possibly
of the system
of the system
specifications of the System
document
for the system.
out by the Specifier
(1) (Weak Dependency)
agent.
If action A is dependent
of actions
(as shown in
on action B, then action
of action B. This means that A
be started before the end of action B, but the results will not be as effective as when A
at a library
For example, a specifier can start developing of exemplar
specifications.
on B, then A cannot be started unless B has finished. specifications
The dependency
started unless there is a successful completion
is started after B is finished. before looking
specifications
document
(2) (Strong
Dependency)
For example,
unless the formal and the informal
the formal specifications
a specifier cannot develop the
specifications
These tasks can be related to the BTs defined for the Functional
If A is dependent
have been written.
Specifications
Form (Table 1)
8s follows: l
Understand
users’
l
Understand
functional
requirement
specifications
system lead to the Narrative l
Access the
l
library
leads to the informal
Specifications
of exemplar
specifications
specification
informal
BT 2.0;
specifications
of the
BT 2.1;
specifications
system lead to BTs 2.2 through
Develop
and Develop
narrative
and Develop
formal
specifications
of
3.0; and
document
for the system leads to the Functional
Specifications
Form, with all its BTs integrated. The support
provided
by DIF in integrating
the results of multiple
deals with only the results of tasks, and not how tasks are performed. a very coarse level of granularity, November 1987
ignoring
tasks is now clearer. Hence it supports
the tasks at
the actions that compose the task. In an I-SHYS
Hypertext ‘87 Papers
But DIF
our
423
focus
is to develop definitions
of tasks in terms of the actions that compose them, such that the actions
are simple enough to be automatically
supported.
As an aside, we must caution
aspects of the process.
we are not suggesting
to reduce the creative
reduce its non-creative
aspects which encumber creative aspects. This is in tune with the philosophy
being pursued by Delisle and Schwartz in their definition project
Rather,
the reader that
we are suggesting
to
of an Idea Processor [DS87], by the Colab
PARC [FSSS] and project Nick at MCC [BCE*8’7].
at XEROX,
To see how this could be achieved, is part of the task of Develop
consider the action
functional
Understand
Users’s
which
requirements,
It can. be broken into finer grained
specifications.
actions as follows: l
View the requirements
l
Create notes of the key points of the requirements;
l
If something
l
If still unclear then discuss it with fellow Developers,
l
Organize
is unclear, communicate
Primitive
Consider
with the Users to understand
of Primitive
Actions
PMs, or Users;
on a hypertext
as follows.
Actions
the hypertext
to consist of objects and relationships
DIF these were BTs and links between BTs.) identify
it better;
notes about the understanding.
This leads to the definition 3.4
document;
the following
primitive
between
the objectse[Gar87a].
From the example in the previous
subsection,
(In we can
actions: -
‘look at’ an information
l
VIEW(REQUIREMENT)
l
ANNOTATE(REQUIREMENT)
l
EXPLAIN-REQUEST(REQUIREMENT,
object containing
attach notes of ‘understanding’
-
to an object X.
request an explanation
U) -
a User’s requirement.
of a requirement
from
a User agent. l
{AI, AZ,. . . An})
DISCUSS(REQUIREMENT,
-
discuss a requirement
with
other agents of
the process. l
PRINT-ANNOTATIONS(REQUIREMENTS) to
Understand
actions as the following
424
or g anize and print the annotations
attached
the requirements.
The action
‘The
-
objects
User’s
diagram
Requirements
can be understood
in terms of these primitive
shows:
are the nodes in the hypertext
graph,
and the rcIationsbips
Hypertext‘87 Papers
arc the edges.
November1987
1 UNDERSTAND(REQUlREMENTS) 1
0
-
DISCUSS(REQUIREMEN-l-, {User, PM, Developers})
EXPLAIN-REQUEST(REQUIREMENT, User)
PRINT-ANNOTATlONS(REQUIREMENTS)
Consider
the diagram
flowchart.
The double lined arrows show the rela-
[SFG85] which means that the action ordering
tion ‘elaboration’ considered
as a non-deterministic
as the elaboration
The primitive
at the head of the arrow can be
of the action at the tail of the arrow.
actions developed in this manner can be generalized by replacing REQUIREMENT
with an arbitrary
object X. For example, we can have an action UNDERSTAND(X)
posed of VIEW(X),
DISCUSS(X,a),
ANNOTATIONS(X),
EXPLAIN-REQUEST(X,(),
which is com-
ANNOTATE(X),
w h ere a is a set of agents, and C is the agent responsible
and PRINT-
for the creation
of
X.
3.5
Discussion
There are several ways that this approach tasks, and products Establishing
being encoded in an I-SHYS.
of conlezt [DS87] of the hypertext.
establishes the context
An I-SHYS can therefore automatically to one of these actions.
current
November1987
practices
Since the action of Understand
establishment
For example, the Understand
actions Users
actions can be taking place.
prune out the objects and relationships
objects and relationships context
we discuss these issues.
in which one of the five primitive
a period of time, this can reduce the information to worry.about
In this subsection
about software process agents,
The break up of tasks into actions and of actions into primitive
Context:
results in the establishment Requirements
can result in knowledge
Users ) Requirements
that are not pertinent is carried out over
overload on the agent, as the agent does not have
which are not relevant
to his/her
would have to be done manually
Hypertext‘87 Papers
immediate
action.
In
by the users of hypertext
425
and can lead to much semantic complexity Semantically which
Rich
Commands:
can be converted
commands
The analysis naturally
into semantically
the hypertext
rich commands.
For example,
with the hypertext
it is possible
[Wing?]
is required
can be provided
to provide
about object
support
there can be a command to PRINT-ANNOTATIONS(X) attached
actions
and Sluoier and Cash-
system, to ‘intelligently’
system to organize and print the annotations
what kind of organization
of primitive
to start a discussion
tools such as suggested by Winograd
man [SC841 can then be integrated between agents. Similarly
leads to definitions
’ f orms the hypertext w hi ch m
such as DISCUSS(X,A)
X with agent A. Coordination
[DS87].
discussions
which instructs
to an object.
The encoding
along the lines of configurations
of
suggested in
section 2.5. Task
Coordination:
pertext
A break down of tasks into the actions that constitute
system to be informed
allows the hypertext
about the agents and what tasks they are expected to perform.
system to perform task coordination,
VI),
For example,
if agent Ai performs
then agent Ur is expected
suggestion fired which
[Win87].
to respond
someone else. There
with
abandon
an explanation,
a certain
denial,
time framework
the request, send a complain
support
acts which
for their coordination
to a manager,
[Ked83].
the intervention
of other agents, For example, the action EXPLAIN-R.EQUEST(X,A)
Agents:
of object X by agent A. To support of interactions
which can possibly influence
medium
descriptive
subjected mixture Time:
to automated of natural
time period
language,
semantic
language,
explicitly
requests the
we have identified
in completing
required
product
require
the following by them:
or meta-tasks.
object which is the focus ofinteraction.
or language used for the interaction.
we consider are: (1) natural
which
the nature of support
The categories and number of agents that interact
Communicated-object: Signal:
there are actions
such interactions
or ask
arise in the course of a
As we saw in the previous
attributes
examples,
or an alternative
then a demon can be
Interactions:
explanation
The various forms of signal of interaction
(2) figures and graphs,
analysis),
(3) formal
and (4) semi-formal
language
language
(which
(language
which
that can be has a
figures, graphs, and formal language).
over which the interaction
is carried out. We distinguish
tions as being either long or short, or (2) whether
426
either
are a whole set of such communication
software process and which need automated
an action requires a response from
the action EXPLAIN-REQUEST(REQUIREMENT,
If Ur does not respond within
suggests to Al to either:
This
by which it can trigger demons in case ac-
tions which were supposed to be done are not done, or if performing an agent.
them, allows the hy-
the interaction
Hypertext ‘87 Papers
is synchronous
(1) duration
of interac-
or asynchronous-
November 1987
Space: the geographical that the interacting discussions;
relationship
agents are geographically
or (2) local, meaning
and therefore
of agents interacting.
that the interacting
attributes
example, a interaction Similarly
cannot engage in face to face
a interaction
on the functionalities
can be trivially
carried out synchronously
The advantage
location
requires a computer
carried out asynchronously
of encoding
of the hyper-
this information
For
mediated real time conferencing
requires into an I-SHYS
some structured
mail support
is that in a complex
of the hypertext
on the stage at which the process is. If the hypertext
change itself to meet the requirements
demanded
mapped from the value of the attribute.
such as the software process, the demands on the functionalities depending
implying
agents are in the same geographical
has an influence
text system. Most of the functionalities
[MGL*87].
dispersed and therefore
(1) distributed,
can engage in face to face discussion.
Each of the interaction
support.
This can be either:
process
system can change
system ‘knows’
about this, it can
imposed by the stage of the process.
4 SUMMARY AND FUTURE WORK In this paper we have described a Software Hypertext of a Software Hypertext System (I-SHYS), work.
System can be extended to the concept of an Intelligent
by studying
Implementation
LISP machine. of Situation
of parts of I-SHYS
of I-SHYS
model of I-SHYS
the process, can be defined a priori.
by complex
Empirical
investigations
The
process is an open system [Hew861 where the tasks and interactions relationships
as:
l
Primary
Tasks versus Articulation
l
Routine
Interaction
Tasks [BS87,Gas86],
versus Non-routine
tasks are the tasks prescribed
non-deterministic
sequence of actions
task. Articulation
interaction
by
and
[Gas86];
that must be performed
Hypertext‘87 Papers
that
in which the
These concepts are illustrated
by the policies of the process.
tasks emerge when primary
of
are determined
between the process, the agents in the process, the setting
the tasks and interactions
patterns
of the process, however, indicate
categorizing
November1987
of I-SHYS.
in the process, and the interaction
which is being developed.
primary
of the theory
studies of the software process [Sca84,BS87].
process is carried out, and the product
Primary
using an extension
made in systems such as I-SHYS is that the software process is a closed system wherein
the tools used in the process, the tasks performed
the software
frame-
on the TI Explorer
in the approach presented in this paper for the construction
has been suggested by the results of empirical
An assumption
from a tools, tasks, and interaction
are in progress using Knowledge&aft
a theoretical
Software Hypertext
[McD85,Gar87b]
There is a limitation limitation
the environment
We are also building
Calculus
System DIF. We have then shown how notions
Articulation
tasks are a
in order to effectively
carry out a
tasks descriptions
are incomplete
to handle
unexpected
circumstances
such as when breakdowns,
foul-ups,
or resource bottlenecks
suddenly
emerge. An example will make this clearer7: Suppose that the primary ing of the functional complete
specifications
understanding,
text-formatter
the report the use of a text-editor
Also suppose that the agent is not familiar
Then in order to accomplish
the agent has to accomplish
In parallel
to the notions
an understand-
of a system. Suppose that the agent has developed
and in order to print
are required.
text editors available. report)
task of an agent is to print a report detailing
the primary
the articulation
of primary
and a
with any of the
task (that
task of understanding
tasks and articulation
a
of printing
a
a text editor.
tasks, we distinguish
between two
kinds of interactions: 1. Routine
interactions,
2. Non-routine A routine
interaction.
interaction
peculiar
and
to particular
occurs as part of the ‘ideal’ settings.
Programming,
editor, and compiler is a routine
interaction.
process tasks depart from expectation by multiple Wirth’s
refinement
real world situations, non-routine
interactions
process and not because of situations as an interaction
interactions
For example,
interaction.
Ideally
emerge when primary
negotiations
for competing
a programmer
and develop efficient smooth
between implementor,
‘literate
software resources
should be able to follow
programs’
and thus the programmer
[Knu84]. might
But in
have to try
(e.g., discuss issues with associates) to develop the final program.
Articulation
fails. As an alternative,
can provide
support
tasks and Non-routine
for Primary interaction,
tasks and Routine the approach
one can explore the use of Case Based Reasoning.
tasks and non-routine
interaction,
we find that these can be successfully
who have had similar
experiences
before.
Case Based Reasoning
interactions.
For
suggested in this paper If we analyze articulation
provides
accomplished a framework
by agents by which
experiences
of several agents can be encoded in a knowledge based system and the system can provide
suggestions
to the agents by examining
before. Encoding articulation
such knowledge
tasks and non-routine
to encode such knowledge the situations 7This
428
or plan.
progress is not readily
Systems such as I-SHYS supporting
paradigm
considered Non-routine
agents may be a non-routine
step-wise
software
example
the actions of agents who were faced with similar
requires a set of empirical interaction
studies which acquire knowledge
in various projects.
such that similarity-reasoning
It requires a framework
can be performed
in past cases. Our group has started efforts in this direction is the essence of a more detailed
example
presented
Hypertext ‘87 Papers
situations about
in which
on present situations [Ben87,Jaz87].
in [BS87]
November 1987
to
5
ACKNOWLEDGMENTS
The ideas in this paper have benefited from discussions with Salah BendifaIIah Comments
from Salah Bendi&lIah
The work reported
on earlier versions of the paper have improved
here has been supported
mation Systems, TRW Systems Engineering under contract
number KSR5’76195-SN8,
81-C-0331 from DARPA by the USC graduate
and AbduIaziz
to USC/ISI.
through
Design and Development, IBM through
In addition,
school through
research grants or contracts
Jazzar.
the presentation. with AT&T
Infor-
Hughes Radar Systems Group
the Socrates project at USC, and MDA 903-
the first author acknowledges
the AR-University-Pre-Doctoral
Merit
the support
provided
Fellowship.
References [BaI86]
R. Balzer.
Living
in the Next Generation
World Computer [BCE*87]
Conference, IFIP
Operating
System.
Congress, Dublin,
In Proceedings
Ireland,
September
M. Begeman, P. Cook, C. Ellis, M. Graf, G. Rein, and T. Smith. ings Augmentation
and Analysis.
In Computer
of the 10th
1986.
PROJECTNICK:
Supported Cooperative
Meet-
Work Conference,
1987. [BEH*87]
T. Biggerstalf, Management
C. Ellis, F. Halasz, C. Kellog, Challenges
S. BendifaIIah.
Program,
Undemtanding
PhD thesis, Computer
and D. Webster.
in the Software Design Process. Technical
MCC, Software Technology [Ben871
C. Richter,
January
Software
Report
STP-039-87,
1987.
Specifications
Work:
Univeristy
of Southern
Science Department,
Infomzation
An Empirical California,
Analysis. December
1987. Forthcoming. [BGW82]
R. BaI zer, N. Goldman, prototyping.
and D. WiIe.
ACM SIGSOFT
Operational
Software Engineering
[BoeSl]
B. Boehm.
[BS87]
S. BendifalIah
and W. Scacchi. Understanding
ical Analysis.
IEEE
Jeff Conklin.
Hypertext:
[Con871
Software Engineering
Transactions
ber 1987. Also available [DS87]
P wbl November1987
Economics.
Prentice
Contexts:
puter Supported
Work Conference,
Documenters
Work Bench.
UNIX
a Partitioning
CIitfs, NJ, 1981. Work:
SE-13, March
Compufer,
Report no. STP-356-86,
N. Delisle and M. Schwartz.
1982.
Hall, Englewood
Software Maintenance
and Survey.
as MCC Technical
as the basis for rapid
Notes, 7(5):3-16,
on Software Engineering,
An Introduction
Cooperative
specification
Concept
An Empir-
1987.
20(9):1741,
Septem-
Rev. 1.
for Hpertexts.
In Com-
1987.
Documentation
Hypertext‘87 Papers
429
[FS86]
G. Foster and M. Stefik.
Cognoter,
Proceedings of the Computer
Suppoded
[Gar87a]
P. Garg. Abstraction
[Gar87b]
P. Garg.
Theoretical
Computer
Science Department,
[G&6]
Infomation [GLB*83]
Mechanisms
Descriptions. [~~88]
In
Work Conference, pages 7-15, 1986.
1987. To be presented at Hypertezt Software
and routine
T. Cheatham,
Technical
Report
Software
1987. Submitted
tool.
Hypertext
Systems.
‘87. 1987.
work. ACM
Bansactions
on Ofice
July 1986.
R. Balzer,
P. Garg and W. Scacchi.
of a colab-orative
USC, In preparation.
of computing
Based Software Assistant. [GS87]
Cooperative
for Intelligent
Systems, 4(3):205-225,
C. Green, D. Luckam,
and practice
in Hypertext.
foundations
L. Gasser. The integration
theory
and C. Rich.
KES.U.83.2,
Hypertext
for publication,
Report on a XnowIedge
Kestrel
Environments
Institute,
June 1983.
for Configured
Software
1987.
P. Garg and W. Scacchi. A Hypertext
System for Software Life Cycle Documents.
uary 1988. To Appear
of the Zlst Hawaii
in Proceedings
International
Jan-
Conference
on
System Sciences. [Hen861
P. Henderson,
editor.
neering Symposium
Proceedings
on Practical
of the ACM
Software Development
notices, vol. 22, no. 1, Palo Alto, California, [Hew861
C. Hewitt.
Offices are open systems. ACM
4(3):271-287, [Jaz87]
Software
Environments.
Engi-
ACM, SIGPLAN
Dec. 9-11, 1986. Transactions
on Ofice Information
Systems,
PhD thesis, Univeristy
of South-
July 1986.
A. Jazzar. A Model for Managing ern California,
[Ked83]
SIGSOFT/SIGPLAN
December
B. I. Kedzierski. Development
1987. Computer
Knowledge-Based
Environment.
1983. Avialable
Software Documents.
as Kestrel
Science Department,
Communication
PhD thesis, University Institute
Technical
Forthcoming.
and Management of Southwestern
Report
KES.U.83.3
Support in a System Louisiana,
November
kestrel Institute
Palo
Alto California [Knu84]
D. E. Knuth.
[McD85]
D. McDermott. Theories
The ComputeT Journal,
Sense World, pages 269-317,
Ablex
1984.
PubIishing
Corporation,
New Jersey, 1985.
T. W. Mal one, K. R. Grant, K Lai, R. Rao, and D. Rosenblitt.
Coopemtiue
27(2):97-111,
Reasoning about plans. In J. R-Hobbs and R. C. Moore, editors, Formal
are surprisingly
430
Programming.
of the Common
Norwood, [MGL*87]
Literate
useful for computer-supported
Work Conference,
coordination.
Semi-structured In Computer
messages Supported
1987.
Hypertext ‘87 Papers
November 1987
[NS87a]
K. Naryanaswamy Evolution.
[NS87b]
and W. Scacchi.
The Journal
K. Naryanaswamy Systems. IEEE
and W. Scacchi. Transactions
Ingres Reference ManuaL
[Sal861
G. Salton.
[SBB*86]
Another
[SC841
A. Bloch,
1987.
Communications
of the
Based Approach.
1986. System Factory
Tool for Supporting Conference
Office Proon Ojjke Au-
Society, Silver Spring MD, 1984. in Computing:
A Study of the Social Dynamics
of Computer
Science, University
of California,
1981.
W. Scacchi.
Managing
software
engineering January
W. Scacchi. Software specification
Marina
1985.
projects:
a social analysis.
IEEE
Trans.
1984.
engineering:
an approach to the construction
Research Report
USC/Information
of evolv-
Sciences Institute
Del Rey CA in preparation.
W. Seacchi.
A Software
Proc. 19th Hawaii [SFG85]
March
P. Garg, J. Skeer, and M. J. Turner.
XCP: An Experimental
PhD thesis, Department
ing system descriptions.
[Sea861
Systems.
1984 Proceedings of the First International
Software Eng., SE-10(1):49-59, [Sca85]
S. Choi,
The Process of Innovation
of Computing.
[Sca84]
Text-Retreival
Process: A Knowledge
IEEE Computer
W. Scacchi.
Irvine,
SE-13(3):324-334,
Software
Manuscript.
cedures. In IEEE
[ScaSl]
of Evolving
July 1986.
S. Sluzier and P. M. Cashman.
tomation,
Systems
Unix 4.2BSD Documentation.
the Software
Unpublished
Software
March 1987.
Configurations
on Software Engineering,
W. Scacchi, S. Bendifallah, Modelling
Maintaining
look at Automatic
29(7):648-656,
to support
of Systems and Software, 7(1):37-49,
EQuel
ACM,
Database Foundation
Engineering
Intern.
Environment
IEEE
PAMI,
Project.
In
Conf. System Sciences, 1986.
A. Sathi, M. Fox, and M. Greenberg. agement.
for the System Factory
September
Theory
of activity
representation
1985. Special issue on principles
in project
man-
of knowledge
based
systems. [St?L84]
R. Stallman.
EMACS:
In D. R. Barstow, Environment.?, [Tic821
W. Tichy. International
November1987
The Extensible,
Customizale,
Self-Documenting
H. E. Shrobe, and E. Sandelwall,
pages 300-325, McGraw-Hill
Design, Implementation, Conference
Book Company,
and Evaluation
on Software Engineering,
Hypertext‘87 Papers
editors,
Interactive
Display
Editor.
Programming
1984.
of a Revision
Control
System. In 6th
pages 58-67, Tokyo, Japan, 1982.
431
[Tri83]
R. H. Trigg.
A Network-Based
Community.
PhD thesis, Maryland
November [Win871
Artifitial
to Text Handling Intelligence
GOT
the Online
Group, University
Scientific
of Maryland,
1983.
T. Wmograd. Computer
Approach
A language/action
Supported
Cooperative
perspective work
on the design of cooperative
Conference,
work.
In
1987.
Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. D 1989 ACM 089791-340-X/89/001 l/O432 $1.50
432
Hypertext ‘87 Papers
November 1987
