Apr 1, 1991 - software process in a formal, process-programming lan- guage [Ost87]. ..... process status monitoring and execution tracing. APPL/A predicates ...
Programming a Software Requirements-Speci cation Process Stanley M. Sutton, Jr.
1
Mark Maybee
1 Department
Hadar Ziv
1
2
Dennis Heimbigner
Leon J. Osterweil
2
1
Xiping Song
2 Department
of Computer Science
University of Colorado
Harry E. Yessayan
2
2
of Information
and Computer Science
Boulder, Colorado 80309
University of California Irvine, California 92717
April 1, 1991
1
The goal of process programming is to bring increased rigor and consistency to the representation and application of software development methodologies. Software development methodologies are intended to improve software development by specifying the products to be created, describing the activities to be performed, and guiding the execution of these activities and the use of the products. Examples include the Waterfall model [Roy70], Spiral model [Boe88], Jackson System Development [Jac83, Cam86], Booch Object-Oriented Design [Boo83, Boo86], Structured Analysis and Modeling [RJ77, GS86, BBD77, EFRV86], and Structured Design [Mye78, Ber78]. Several problems prevent current software methodologies from being fully and generally successful. The speci cations of software processes and products are too often semi-formal or informal (if speci ed at all), the processes rely on manual interpretation and control, and the products may be managed and accessed haphazardly. A process may not be clearly understood, and to the extent that it is understood it may be dicult to modify e ectively. Consequently, software processes are often executed uncertainly and inconsistently, and software products are more likely to be incomplete, invalid, or incorrect. The potential advantages of process programming derive from the formality of process-programming languages and process programs. Process-programming languages are de ned by formal syntax and precise semantics; process programs are thus amenable to analysis and veri cation and should facilitate communication and education. Process programs are also potentially machine-executable. This would enable them to be executed in a consistent way, and allow them to be e ectively tested, debugged, and reused. Finally, it may be possible to apply conventional tools and techniques to
Introduction
Software-process programming is a comparatively new approach to the speci cation of software processes. It has attracted widespread interest but has not yet received general acceptance. For process programming to be accepted the issues involved must be better understood and its feasibility must be demonstrated. To these ends we have undertaken the development of REBUS, a prototype process program for the speci cation of software requirements. Through the development of REBUS we hoped to acquire knowledge about basic issues in process programming. In the REBUS program we hoped to o er an example of a plausible process program. In this introduction we review the advantages of process programming and argue that prototyping is an appropriate way to advance the state of the art; in the remainder of the paper we report on REBUS. A software-process program is the encoding of a software process in a formal, process-programming language [Ost87]. Software-process programming is the activity of developing software-process programs from requirements, through design, to code, followed by testing, analysis, use, and maintenance. Process programming is thus modeled after conventional programming. Processprogramming languages (i.e. process coding languages) are analogous to conventional programming languages, and process programs are analogous to conventional application programs. The di erence is that processprogramming languages and process programs apply to the domain of software processes and products. Software processes present new and challenging aspects not found in most conventional applications, for example, the need to accommodate both manual and automated activities and the need to manage highly complex, diverse, and interrelated persistent objects. 1
the development of process programs (eventually using process programs to support process programming). Because process programming is modeled after conventional programming, we can begin to write process programs as we would write conventional programs. However, software processes are a new domain for programming, one which is in many respects unusual and challenging. In attempting to write our rst process programs we encountered many fundamental questions: Is it feasible to model and implement software processes using programs? Are the programs which we can write plausible as software processes? What issues arise in the design of process programs? Can conventional development methods be usefully applied to the development of process programs? And what should languages for software process models, designs, and code look like? The answers to these questions are complicated at least in part because the issues involved are interdependent. For example, advances in process programming depend on advances in process-programming languages, but advances in process-programming languages depend on experience in process programming. This situation represents a kind of research deadlock. We believe that the most e ective way to break this deadlock is through the iterative prototyping of both processprogramming languages and process programs. Thus we have de ned prototype process-programming languages and written prototype process programs using those languages. In this way our understandings of both processprogramming languages and process programming have been able to evolve in concert. REBUS is the principal process program resulting from these prototyping exercises. REBUS is coded in APPL/A, a prototype process-programming language which is described in detail elsewhere [SHO90, Sut90]. The REBUS process is simple and general but, we believe, plausible and useful. REBUS was developed according to a simple software development methodology which included phases for requirements, modeling, design, implementation, and evaluation. In carrying out this development process we were forced to address several technical issues. These included (among others) the programming of the integration of manual and automated activities, the development of an approach to coordination of teams of workers, the design of a general and exible requirements model, and the provision of support for persistent data. In the remainder of this paper, we describe REBUS and aspects of its development and use. Section 2 discusses current approaches to software requirements speci cation and explains our choice of requirements speci cation for the prototype process. The next three sections discuss the development of REBUS: Section 3 presents goals for the prototyping experiment and sets out requirements for the process program, Section 4
presents product and process models for REBUS, and Section 5 describes the design and implementation of REBUS in APPL/A. Section 6 then describes our experience in using REBUS. Finally, Section 7 provides a discussion of our experience and the issues raised, and Section 8 summarizes our conclusions and indicates future work. 2
Rationale for
the
Program-
ming of a Requirements Process
In attempting to present an example of a plausible process program, we wanted to start by programming one phase of a typical software life-cycle. Requirements speci cation was a natural choice for several reasons. It represents the beginning of the development process, so it is an appropriate start for a more comprehensive life-cycle program. Moreover, we hoped to use a requirements-process program in developing the requirements for subsequent process programs which would ll out a more complete life-cycle. Additionally, the process of requirements speci cation incorporates both computer-supportable activities and manual activities involving both individuals and groups. This is typical of many software processes. Thus, in addressing the programming of such activities here, we acquire experience relevant to several generally important issues. Finally, a number of special-purpose languages and systems have been developed previously for speci cation and analysis of software requirements. These have been useful, but we do not believe they provide the best solution to the problem of requirements speci cation. Special-purpose languages for requirements speci cation include PSL/PSA [TH77], RSL/REVS [BBD77], SADT [Ros77], SSA [GS86], and SARA [EFRV86]. These languages are each based on a speci c approach to requirements speci cation which typically involves the creation of a speci c, often highly visual, requirements product. For example, RSL uses a ow-oriented approach to model the stimulus-response nature of process-control systems, whereas the SADT language (SA) supports the creation of a top-down decomposition hierarchy of diagrams that capture system activity and data ows. Although some of these languages support some degree of exibility and extensibility (for example, PSA provides the capability to de ne new PSL constructs and new report formats), the requirements speci cation process itself is generally determined implicitly by the requirements speci cation language. Sometimes the process is left almost totally unspeci ed. This lack of rigor and explicit process guidance can lead to diculties in understanding and maintaining both process and 2
product. It hinders communication and coordination of e orts, and often deprives human speci ers of valuable assistance that might have been furnished easily. Our hope is that by writing programs for the requirements-speci cation process we can remedy many of the problems associated with more conventional approaches. Process programs should provide explicit representations of requirements processes and products, enable more rigorous support of the intended process, facilitate communication and coordination among developers, and allow for systematic and e ective extension and modi cations of the process. REBUS is intended to be a rst step in this direction. 3
Flexibility and extensibility of the product: the requirements speci cation should be not only formal but exible and extensible
User interaction: it should accommodate user-
Team support: it should allow teams of develop-
Persistence: the requirements data should be stored persistently
Automation: activities in support of the speci -
Experimental Goals and Process Requirements
Formality of process and product: REBUS
Flexibility of speci cation approach: it should
ers to coordinate their e orts
cation process should be automated to the extent feasible
To begin to address these requirements we developed the product and process models described in the next section.
REBUS is a prototype process program for the speci cation of software requirements. As a prototype REBUS has several goals. The rst is to demonstrate that it is possible to construct an executable program for a plausible software process. We chose a requirements process, but we hoped to suggest that the programming of many other software processes is also feasible. The REBUS prototyping exercise also had other goals. Because REBUS is a program, albeit a process program, we hoped to be able to take a more or less conventional approach to its development. In the context of a research e ort it did not seem appropriate to carry out a full-scale development process. However, we did specify requirements for REBUS, develop models of the REBUS product and process, and design and code an implementation, which we then tested and evaluated. In pursuing this development path we also expected to address several issues which seem central to the development of process programs, for example, accommodation of manual activities, integration of manual and automated processes, and coordination of teams of developers. Formality and plausibility were two additional goals for our process program. A minimal formality is required for the program to be executable. A minimal plausibility follows if the program is usable and useful. To help assure and expand on these goals we imposed the following additional requirements:
interaction and user-input into the process, including process control
4
Process and Product Modeling
In order to help clarify our conceptions of REBUS we developed data and process models. In this section we describe those models. The REBUS data model, which characterizes the requirements speci cations produced by REBUS, is de ned in Section 4.1. A set of REBUS process models is then presented in Section 4.2. In Section 4.2.1 we rst use pseudocode to de ne the control model for a single-user requirements-speci cation process. In Section 4.2.2 we then model a more realistic multi-user process. For this purpose we use statecharts to de ne a coordination and concurrency-control model of user access to data, and we use pseudocode to model possible user actions in the context of this coordination/concurrency-control model. 4.1
Product Modeling
In order to provide a general and exible model of a requirements speci cation, as called for in Section 3, we model the requirements produced by REBUS as a directed acyclic graph (DAG) of requirements elements. Each node in the graph represents a functional requirement and each link represents an isa-sub-function relationship. The use of a DAG enables relationships among requirements elements to be structured, and it also allows multiple requirements nodes to share a sub-node representing a common sub-functionality. Each node in the requirements speci cation is modeled as a variant record with a xed aggregation of required elds and a variant aggregation of optional elds .
should support a formal model of software requirements and represent a formal model of the requirements speci cation process
allow alternative approaches to the construction of requirements speci cations
3
The required elds include node name, author, and description. The node name and author represent information about the requirement; the description provides a minimal characterization of the requirement. Optional elds provide more detailed information about speci c aspects of the requirement such as performance, safety, security, and robustness. These may be used only when called for by the requirements-speci cation process or only when relevant to the particular product (or product subfunction) being described. For example, safety and security requirements might only be used in a requirements speci cation for a safety-critical system (or in a particular part of such a system). Thus the variantrecord model of requirements enables requirements to be tailored to speci c products and development processes. Optional elds are also used to identify sub-nodes (and thus to represent the graph structure). A simple sketch of a REBUS DAG is illustrated in Figure 1. This gure shows the DAG structure of a requirements speci cation as well as templates for the various nodes. 4.2
A general single-user requirements process is sketched in Ada-like pseudocode in Figure 2. This model embodies several desired aspects of the process. First, it shows that development may follow a systematic or nonsystematic approach. In the case of a systematic approach, only the operations appropriate to that approach are provided. Second, it is very exible. It allows a variety of approaches to construction of the requirements DAG, and it admits the possibility that approaches may be selected and varied dynamically. The model also admits the possibility that the user can control the process by selecting an approach or by selecting operations within an approach. The ability to integrate user control into the process is another important requirement for REBUS. Finally, the model abstracts many of the control and data-manipulation functions in the process. This simpli es the model yet provides a context in which details may subsequently be added as appropriate to the purpose of the model and the process. For example, in a \production" version of the process, the choice of approach may be made by a manager according to management policy, whereas in our prototype version it might be more expedient for experimental purposes to allow the choice to be made by the developer.
Process Modeling
In this section we describe a single-user process model to give a basic idea of the individuals view of the process, then we provide a multi-user process model intended to accommodate teams of developers.
4.2.2 A Multi-User Requirements Speci cation Process
4.2.1 A Single-User Requirements Speci cation Process
The previous section provides a single-user view of a requirements-speci cation process. However, requirements speci cation is usually performed by a team of developers. In a team context, the work of various team members may be interdependent. For example, one practitioner may utilize a requirements node produced by another practitioner as a sub-node specifying some common functionality. Additionally, the relationships among nodes and developers may be complex. A single team member may be working on multiple requirements nodes, or a single requirements node may be elaborated by multiple team members. Therefore, developers must communicate with each other, and in particular they must coordinate their access to data. The REBUS approach to team coordination is based on a whiteboard , a communication and coordination mechanism derived from the blackboard concept [Nii86]. The whiteboard is shared by all developers; it represents the current \working status" of all requirements nodes, and it coordinates access to the nodes accordingly. In the whiteboard model, each requirements node is associated with a completion status. Initially, a requirements node is posted to the whiteboard to inform team members that the node needs to be worked on. The node is considered to be incomplete until satisfactory values are assigned to all of its elds; then it becomes complete. An incomplete node can be either
Given the above data model, the development of a requirements speci cation in REBUS will involve creating, evaluating, modifying, and relating requirements nodes in a DAG. The creation and modi cation of nodes will further consist of adding and deleting (optional) elds and providing and re ning their contents. Since the requirements model is a DAG, one natural way in which these graph- and node-oriented operations might be organized is by a top-down recursive descent from a root requirement. An alternative approach would be bottom-up from basic leaf requirements. While these approaches are systematic, they will certainly be too restrictive in practice. Developers may wish to work topdown for some requirements, then switch to bottom-up for others, and so on. Similarly, developers may wish to elaborate di erent parts of a DAG in parallel. Since our purpose here is to de ne a plausible but not necessarily elaborate model of a requirements process, we adopted the view that the basic process model for REBUS should accommodate a structured approach to requirements speci cation, but it should also allow users to vary their approach as it seems necessary to them. This addresses the requirements for user-interaction and
exibility of speci cation approach which are set out in Section 3. 4
NAME
DESCRIPTION
DATE
FUNCTIONALITY
AUTHOR
ROBUSTNESS
SECURITY
PERFORMANCE
NAME
DESCRIPTION
DATE
FUNCTIONALITY
AUTHOR
NAME
DESCRIPTION
DATE
FUNCTIONALITY
AUTHOR
ROBUSTNESS
ROBUSTNESS
NAME
DESCRIPTION
DATE
FUNCTIONALITY
AUTHOR
SECURITY
SECURITY
ROBUSTNESS
SECURITY
PERFORMANCE
PERFORMANCE
SAFETY
NAME
DESCRIPTION
NAME
DESCRIPTION
DATE
FUNCTIONALITY
DATE
FUNCTIONALITY
AUTHOR
AUTHOR
ROBUSTNESS
ROBUSTNESS
SECURITY
SECURITY
SAFETY PERFORMANCE PERFORMANCE
Figure 1: A Simple Requirements Graph Structure locked or unlocked. An unlocked node must be locked by a team member wishing to edit the contents of a node. A locked node may then be unlocked by the team member at the end of the node-editing session, making the node once again available for locking. The completion status of nodes on the whiteboard is easily modeled by a nite state machine. We have chosen to use statecharts1 for this purpose. The node statechart is given in Figure 3. The whiteboard model provides team members with ve operations to initiate or change node status:
initiate posting of a node to the whiteboard, informing other team members that the node needs to be worked on (it is incomplete and unlocked).
post:
change the node state from unlocked to locked, allowing the developer to edit the node while excluding other team members.
lock:
unlock:
submit:
repost:
locked.
change the node state from locked to un-
change the node state from incomplete to complete, informing other team members that the node is complete and consistent.
change the node state from complete to incomplete (to modify a submitted node).
Using the whiteboard model, we can de ne a pseudocode model of the requirements speci cation process that supports coordination among a team of practitioners. The process model sketched in Figure 4 integrates whiteboard operations with the process model presented in Figure 2.
1 Statecharts [Har87] are an extension of conventional nitestate machines (FSM's) and their visual counterpart, statetransition diagrams. They support the repeated decomposition of states into substates in an AND/OR fashion, combined with an instantaneous broadcast communication mechanism.
5
Node Incomplete Locked
Complete
Repost Unlock
Lock
Submit Unlocked
Figure 3: A Statechart Showing Transitions between Whiteboard States for a Node In this gure, states locked and unlocked are clustered into a state incomplete so that to be incomplete is to be either locked or unlocked. The arrow entering incomplete would appear to be underspeci ed, as it must cause entry to locked or unlocked; in fact, its meaning relies on the internal default arrow attached to unlocked, which causes entrance to unlocked.
system called Triton [Hei90]. APPL/A is a prototype process programming language based on Ada. The principal extensions that APPL/A makes to Ada include programmable persistent relations, triggers on relation operations, enforcible predicates on relations, and several statements that provide transaction-like capabilities. The Triton object management system is used to implement persistent storage for APPL/A relations. Triton provides a logically centralized repository of typed objects and functions for manipulating those objects. Triton utilizes an existing object manager, the Exodus database system [CDF+ 86], to provide lowlevel storage management capabilities and a persistent programming language derived from C++. The basic design of REBUS is in terms of a software process plus a supporting substrate of basic operations. These operations may be invoked by the process or by the user (possibly mediated by the process). The procedure of Figure 2 follows this pattern in that the operations such as \CreateRoot" ultimately invoke basic substrate operations such as \CreateNode." In the following two sections we describe the design of the process component and the design of the substrate component.
The multi-user model has basically the same control ow as the single-user model, with the addition of operations related to the whiteboard. However, in this model the actions of one developer may a ect others. One example of this is that con icts may arise if two developers want to work on the same node at the same time. The whiteboard-based model addresses this problem through node locking. Another example is that nodes worked on by one developer may relate to or otherwise a ect nodes worked on by another. A developer may create children for a node posted by someone else, or a developer may post a new node that others might nd useful as a representation of a subrequirement. Here the whiteboard helps by providing a common place where new and updated nodes may be (re)posted so that all developers may review and react to them. The multi-user model of Figure 4 not only illustrates the use of the whiteboard in these roles, but it also suggests that the appropriate use of the whiteboard can be enforced automatically. 5
Design and Implementation
REBUS was designed and implemented using the process programming language APPL/A [SHO90, Sut90], which in turn uses an underlying object management 6
Procedure MultiUserModel is ... Begin while not Done loop case CurrentApproach is when TopDown => if NeedRoot then Post(CreateRoot); elsif NeedChildren then SelectNodeToElaborate(CurrentNode); if Complete(CurrentNode) then Repost(CurrentNode); Lock(CurrentNode); if LockedBySomeoneElse(CurrentNode) then raise LockViolation; elsif NotLocked(CurrentNode) then Lock(CurrentNode); end if; CreateChildren(CurrentNode, ChildNodeSet); PostOrSubmit(CurrentNode); for Node in ChildNodeSet loop Post(Node); end loop; else SelectNodeToEdit(CurrentNode); if Complete(CurrentNode) then ... test and set whiteboard as above end if; EditNode(CurrentNode); if DoneEditing then UnlockNode(CurrentNode); PostOrSubmit(CurrentNode); end if; end if; when BottomUp => ... -- correspondingly when Arbitrary => ... -- correspondingly end case; end loop; End MultiUserModel;
Procedure SingleUserModel is ... Begin while not Done loop case CurrentApproach is when TopDown => if NeedRoot then CreateRoot; elsif NeedChildren then SelectNodeToElaborate(CurrentNode); CreateChildren(CurrentNode); else SelectNodeToEdit(CurrentNode); EditNode(CurrentNode); end if; when BottomUp => if NeedLeaves then CreateLeaf; elsif NeedParent then SelectNodesToGroup(CurrentNodeSet); CreateParent(CurrentNodeSet); else SelectNodeToEdit(CurrentNode); EditNode(CurrentNode); end if; when Arbitrary => if NeedNode then CreateNode; elsif NeedToRelateNodes then SelectNodesToRelate(CurrentNodeSet); RelateNodes(CurrentNodeSet); else SelectNodeToEdit(CurrentNode); EditNode(CurrentNode); end if; end case; end loop; End SingleUserModel;
Figure 4: The requirements process performed by a single developer using the whiteboard to coordinate with other developers
Figure 2: The requirements process performed by a single developer 5.1
actually designed to separate the process enforcement mechanisms (APPL/A triggers and predicates) from the actual process policy: top{down, bottom{up, or arbitrary. The basic substrate of operations remains unchanged by changes in policies. By replacing one set of predicates and triggers with another set, one can completely change the process policy enforced by REBUS. The use of constraints and triggers to enforce the process has a slightly disconcerting e ect. REBUS contains no instance of the procedure of Figure 2, but the sequence of substrate operations allowed by the constraints and triggers will appear to conform to the procedure in Figure 2. In this \proscriptive" model, users are free to attempt any operation from the substrate at any time.
Process Design
The process models described in Section 4.2 impose some severe requirements on the design of REBUS. It is possible to follow any of a variety of strategies in implementing a particular process. Thus, for example, a top{down or bottom{up process for building a requirements DAG could be implemented in a strictly procedural manner. That is, one could write procedures to choose speci c nodes and require the user to expand those, and only those, nodes. This was felt to be too constraining both on the user and on the our ability to easily explore and possibly inter-mix processes. In order to provide some exibility, REBUS was 7
However, attempts by the user to perform certain actions may be prohibited depending on the policy currently in force. Thus the user is led to perform actions in accordance with the desired process. 5.2
NodeName(Name, NodeId) EditLock(NodeId, Owner) NodeState(NodeId, State, Author, Trace) StatusTuple(NodeId, Created, Modified, Owner, Rights, Trace) FieldType(TypeName, ClassHandle, GetMethod, SetMethod, CollectionHandle) NodeTrace(NodeId, Stamp, From, To, Author, Previous) SubNode(Parent, Child) FieldValue(NodeId, Created, Modified, TypeName, Value) Project(Name, RootNode)
Operation Substrate
The REBUS program must provide a certain set of functions to the user (and to the process). Speci cally, it must provide operations for manipulating the requirements graph and also operations for manipulating the values associated with nodes in the graph. We chose, in this design, to divide these functions across two modules: a Directed Acyclic Graph (DAG) module and an EDIT module. The DAG module is the primary interface through which the requirements graph is displayed and manipulated. Additionally, it incorporates the interface to the whiteboard in so far as the whiteboard is directly visible to the user. The DAG provides operations for creating and destroying nodes and edges of the graph. It also provides operations for locking, unlocking, submitting, and reposting nodes to the whiteboard. Display operations per{se do not exist, but rather a user interface system undertakes to provide a correct and up{to{date display of the current state of the graph. The EDIT module contains the interface functions necessary for manipulating the attributes associated with a node in the graph. This interface is designed to be compatible with standard text editors such as emacs or vi, provided that all attribute values are coercible to and from string representations. This interface is also designed to be usable by special purpose editors for attribute elds with sophisticated type structure. The EDIT module also interacts with the whiteboard to guarantee that users do not attempt to edit nodes they have not previously locked. An additional reason for decomposing REBUS into modules was to allow e ective interaction with the Chiron [KCTT91b] user interface development system. Chiron is designed to provide wrappers (termed \artists") around abstract data type (ADT) instances so that operations on the ADT and outputs from the ADT are mediated through Chiron to provide a consistent user display of the state of the ADT. Chiron artists are provided for both the DAG module and the EDIT module. These artists provide a convenient menu and mouse interface for invoking operations on the graph, for selecting a node, and for selecting an attribute within a node for editing. 5.3
Figure 5: Names and Attributes of REBUS Relations of requirements elements and their relationships, process guidance, status monitoring, multi-user coordination and consistency management. We have been able to satisfy these needs with APPL/A and Triton. The DAG and EDIT modules store their persistent data (nodes with attributes, edges, and the whiteboard state) into a collection of persistent APPL/A relations. Some relations, such as those comprising the whiteboard, are used by both the DAG and the EDIT modules. APPL/A relations provide an abstract data modeling and storage capability for persistent data in REBUS. Relations are used to represent and store information regarding both REBUS products and processes, including requirements objects, inter-object relationships, and execution-history traces. Figure 5 lists the relations used in REBUS (appendix A contains a complete example of a relation speci cation as well as predicate and trigger examples). For example, a node, as an object, is represented by a unique identi er (NodeId in Figure 5). Various relations, such as NodeName and NodeState are used to associate values with a given node. The relation SubNode relates each REBUS node to its parent node (if any). The relations NodeState and NodeTrace are used to keep track of node state change and support process status monitoring and execution tracing. APPL/A predicates express conditions on the state of relations. When enforced they can serve as constraints or assertions. Predicates are used in REBUS mainly to support multi-user coordination. For example, the predicates LockBeforeEdit and PostBeforeLock ensure that REBUS nodes are accessed and manipulated according to the whiteboard model described in section 4. Predicates are also used to enforce uniqueness of names and to make sure that values are provided for required attributes. APPL/A triggers respond to operations on rela-
APPL/A Implementation
REBUS, as a process program, poses the need for special process support capabilities, such as persistent storage 8
tions, and can be used to propagate updates from one relation to others, to perform computations, to send messages, etc. Triggers are used in REBUS to keep the execution trace up-to-date. The triggers TraceStateInsert and TraceStateUpdate respond to changes in the state of a requirements element and update its trace relation. APPL/A relations are made persistent via the Triton object manager. Triton operates as a server process communicating with its clients, such as REBUS, using the Q [MOS90] remote procedure call mechanism. APPL/A relations are instantiated using a special APPL/A generic package that is parameterized by, among other things, a tuple type (a record), and by procedures for linearizing and delinearizing tuples so that they can be passed by remote procedure call. On the Triton side, each APPL/A relation has a corresponding instance of an E generic class, which is again parameterized by a tuple class. The two generics (one Ada, one E) are designed to communicate with each other so that operations on the APPL/A relation instance are correctly translated into operations on the corresponding E relation instance. Thus, when a user initiates REBUS, for example, this causes a number of APPL/A relations to be instantiated. These relations in turn communicate with an existing Triton server to access the persistent data in Triton. When REBUS terminates, the connection with Triton is severed and the persistent data is saved in Triton. The current implementation of REBUS is about 500 lines of code, 70% of which are APPL/A relations, predicates, and triggers. The 9 APPL/A relations used average about 60 lines of code2 for the speci cations and about 240 lines for the relation bodies. The relation bodies are all derived from a standard template for supporting APPL/A relations in Triton. Although comprising only 10% of the total code, the 3 APPL/A triggers and 13 APPL/A predicates account for the proactive nature of the REBUS process. The triggers average about 75 lines of APPL/A code, while the predicates average about 20 lines. Overall the code for REBUS forms a rather concise speci cation of a requirements de nition process, given the scope of its functionality. 6
A REBUS requirements DAG for the Triton Object Management System [Hei90, Ziv90] was constructed by some of the authors of this paper in an experiment to see whether REBUS could retrospectively capture some of the requirements of an existing system. This experiment provided initial validation of the REBUS formalism. These encouraging results led to a further experiment during the fall of 1990 in which students in the Software Project Course at the University of California,Irvine used the REBUS formalism. At this time, the prototype REBUS system was still under construction, so students used traditional text-editing and diagramdrawing tools to construct a requirements DAG for a Library Information System. The resulting DAG consisted of about 50 nodes, and he contents of each node averaged, in size, between 1 and 2 pages of text, including values for node name, description, functionality, input/output, environment, robustness, performance, accuracy, security, and safety. The students provided useful feedback that pointed out some advantages and disadvantages of the REBUS formalism (which are summarized at the end of this section). Subsequent to its completion, the executing prototype of the REBUS process program was used rst for simple experiments and then the development of a library example (based on [Kem85, Win88]). This allowed us to experiment with, and gain con dence in, the abstract interface to the REBUS tool. It also allowed us to test the implementation of some of the infrastructure components that support the REBUS tool, such as the APPL/A process programming language and the Triton object management system. At the same time, our research group has developed a set of prototype screen images of user interaction with the REBUS tool using the PRODUCER [RAYO90] system. An example screen image of the user interface to the REBUS tool is given in Figure 6, which shows a partial DAG for a Library Information System. We are currently implementing a fully-interactive user interface to the REBUS tool using the Chiron user interface development system [KCTT91a, KCTT91b]. Our experience with using both the REBUS formalism and the executable prototype system is summarized in the following observations: REBUS has provided useful guidance and coordination in the requirements speci cation process, thus addressing given requirements for user interaction and team support (Section 3). However, it has become apparent that REBUS would be more useful if it o ered stronger controls over the approach taken to elaboration of the graph and provided more support for the assignment of certain subgraphs or attributes to particular users. These capabilities would enhance support of the requirement for exibility of speci cation approach.
Experience
The REBUS formalism, namely a DAG of requirements elements, has been used by our research group and graduate and undergraduate students to capture requirements for a number of software systems, including an object management system and a library information system [Kem85] [Win88]. 2 In all code statistics the sizes given include whitespace and comments.
9
Figure 6: A Sample REBUS Screen Shot depicting a partial DAG for the requirements for a library information system.
10
The automatic activities performed by REBUS,
same requirements formalism, was easily extended to include signi cant aspects of the TRW Software Requirements Engineering Methodology (SREM) [BBD77]. Additionally, our formalism, based on DAGs of variant records, and implemented using a relational schema, should readily admit the addition of new requirements elds, the construction of new requirements structures, and the linking of these structures into an integrated requirements product. REBUS demonstrates that the programming of a simple requirements process is feasible; that demonstration, plus the exibility and extensibility of REBUS, gives us con dence that more comprehensive requirements processes are also programmable.
such as enforcement of the whiteboard, enforcement of required elds, re-evaluation of derived data, and consistency maintenance among requirements elements, help reduce the amount of mundane work that is performed by a requirements analyst. This contributes to satisfaction of the requirement for process automation.
REBUS does provide a formal model of software re-
quirements, as required, but that model is lacking in that it does not enforce the use of formal languages in specifying values for particular requirements elds.
Formality and Modeling in REBUS Another important goal of the REBUS experiment was to bring formality to software processes and products. The REBUS program provides a formal representation of both a requirements process and product. Moreover, formal process and product models were constructed during the development of the program. An interesting aspect of the REBUS development process and the resulting program is that, while the program satis es and implements the desired process and product models, it does not represent them in a one-to-one correspondence. (For example, the REBUS program uses several APPL/A relations to implement requirements nodes.) This lack of one-to-one correspondence is motivated by a desire to optimize the implementation in ways not related to formality or modeling. (Thus, the use of multiple relations to implement requirements nodes, which are logically variant records, facilitates extensibility while reducing storage. New variant parts can be added as new relations without a ecting existing relations, and if a node omits an optional eld it is not necessary to allocate a tuple in the corresponding relation. This approach is motivated by the goals of exibility and extensibility which are stated in Section 3.) Our work on REBUS has just begun to uncover issues in areas such as the tension between modeling and other goals of an implementation and the relationships among models used in various roles in development and implementation. We regard these as important subjects for future research.
REBUS also lacks support for such features as
a data dictionary and certain other information commonly found in requirements or used in requirements-speci cation systems. Addition of this information would make REBUS a more complete system, and thereby enhance its plausibility as a requirements-process program.
Although multi-user access to REBUS nodes is en-
abled and coordinated, REBUS provides no explicit means for capturing group interaction or the rationale behind the contents of those nodes. Extensions in this area would also help to make REBUS a more complete and useful system.
7
Discussion
In this section we discuss and evaluate the REBUS prototyping experiment and the REBUS process program.
REBUS as a Process Program The rst goal for
REBUS was to produce an executable process program. REBUS is certainly executable, and we believe it quali es as a process program. Its domain is one of the phases of software development, and its output is one of the products of software development. Moreover, it has many of the qualities which we associate with software processes, such as the combination of manual and automated activities, the use of persistent data, and support for teams of developers.
Applicability of Development Methods to REBUS Another goal of the REBUS experiment was to
REBUS as a Plausible Requirements Process
explore whether conventional approaches to software development could be applied to the development of process programs. This would help to con rm our hypothesis that software-processes programs can be modeled and otherwise treated as a kind of software. It would also begin to indicate whether conventional tools and methods may provide a technological basis for process programming. Within the context of a prototyping experiment, we were able to treat the development of RE-
We also believe that the requirements process represented by REBUS is plausible, if somewhat simple. The requirements issues addressed by REBUS appear necessary but not sucient for a comprehensive requirements process. However, we believe that it will be straightforward to extend REBUS to accommodate a wider range of requirements and requirement speci cation methods. Indeed, an earlier version of REUBS, based on the 11
BUS more or less like that of a conventional application. We speci ed requirements for the program, constructed product and process models, designed and coded an implementation to satisfy those models, and then began to test and use that implementation. We believe that our development e ort was helped by this approach. It forced us to think in a systematic way, to codify our results, and generally improved the discipline of the process. The particular methods we used seem applicable and useful, despite the somewhat novel area of application. Additionally, we have begun experiments using REBUS to capture requirements for other process programs.
to de ne requirements by operations organized around this graph structure. The development of REBUS also forced us to confront several more general issues about process programming. Thus REBUS embodies solutions to the problems of integrating manual and automated activities, coordinating teams of users, supporting persistent data in the context of a process program, isolating mechanisms to represent and implement process policies, and providing a exible and extensible substrate for process operations. Our goals for future REBUS-related work include Extending REBUS to accommodate a wider range
of requirements and requirements speci cation methods.
Satisfaction of Requirements We believe that the
REBUS program generally satis es the requirements set out for particular aspects of its process and product. It allows alternative approaches to the construction of requirements speci cations: requirements graphs can be built top-down or bottom-up, in one piece or several, or by a combination of these methods. A limitation of REBUS at present is that it does not allow any particular approach to be enforced (e.g. top-down versus bottom-up). REBUS should serve, though, as the basis for more structured requirements processes, and we plan to investigate these in the future. REBUS accommodates user interaction and input to the process through the whiteboard, which also serves to control interactions among teams of developers. An issue for the current whiteboard is that it supports only the locking of whole nodes. We believe that it would also be useful to coordinate work on subgraphs consisting of multiple nodes and on selected attributes in one or more nodes. Expansion of the whiteboard model to include these capabilities is another area for future work. The REBUS DAG model of variant records of requirements has proven extremely
exible, and we are working to extend the scope of the requirements to which it applies. Finally, the persistence of REBUS requirements data follows directly from their storage in APPL/A relations. 8
Expanding the whiteboard model to include ca-
pabilities to coordinate work with respect to subgraphs consisting of multiple nodes and with respect to selected attributes in one or more nodes.
Using this enhanced REBUS to build more struc-
tured requirements processes.
Exploring the tension between process modeling
and other goals of process-program implementation.
Investigating the relationships among models used
in various roles in process program design and implementation.
Using REBUS to capture requirements for other
process programs.
Acknowledgements
This research was supported by the Defense Advanced Research Projects Agency, through DARPA Order #6100, Program Code 7E20, which was funded through grant #CCR-8705162 from the National Science Foundation. Support was also provided by the Naval Ocean Systems Center and the Oce of Naval Technology. The authors wish to thank Sadie Kaneko for her help and feedback in addition to the UCI undergraduate students who used REBUS in the ICS-125B software project class in fall of 1990.
Conclusions and Future Work
REBUS constitutes a process program for a simple but plausible and exible requirements-speci cation process. Thus REBUS demonstrates to a signi cant extent that process programming is feasible. REBUS was developed according to a more or less conventional development methodology, indicating that process programs may be usefully treated like conventional software. The development of REBUS required that we devise a useful model of requirements and the requirements-speci cation process. The approach used in REBUS allows requirements to be speci ed as a DAG of variant requirements elements, and it allows users
References
[BBD77]
12
Thomas E. Bell, David C. Bixler, and Margaret E. Dyer. An extendable approach to computer-aided software requirements engineering. IEEE Transactions on Software Engineering, SE-3(1):49{60, February 1977.
[Ber78]
G. D. Bergland. Structured design methodologies. In 15th Annual Design Automation Conference Proceedings, pages 475{ 493, June 1978.
the Twenty-Fourth Annual Hawaii International Conference on System Sciences, volume 2, pages 60{69, Kauai, Hawaii, January 1991.
[Boe88]
B. W. Boehm. A spiral model of software development and enhancement. IEEE Computer, 21:61{72, May 1988.
[Boo83]
Grady Booch. Object-Oriented Design, pages 420{436. IEEE Computer Society, fourth edition, 1983.
[KCTT91b] Rudolf K. Keller, Mary Cameron, Richard N. Taylor, and Dennis B. Troup. User interface development and software environments: The chiron-1 system. In Proceedings of the Thirteenth International Conference on Software Engineering, pages ?{?, Austin, TX, May 1991.
[Boo86]
G. Booch. Object-oriented development. IEEE Transactions on Software Engineering, SE-12(2):211{221, February 1986.
[Cam86]
John R. Cameron. An overview of JSD. IEEE Transactions on Software Engineering, SE-12(2):222{240, February 1986.
[CDF+ 86] Michael J. Carey, David H. DeWitt, Daniel Frank, Goetz Graefe, M. Muralikrishna, Joel E. Richardson, and Eugene Shekita. The architecture of the exodus extensible dbms. In International Workshop on Object-Oriented Database Systems, pages 52{65, 1986. [EFRV86]
[GS86]
Gerald Estrin, Robert S. Fenchel, Rami R. Razouk, and Mary K. Vernon. SARA (System ARchitects Apprentice): Modeling, analysis, and simulation support for design of concurrent systems. IEEE Transactions on Software Engineering, SE-12(2):293{ 311, February 1986. C. Gane and T. Sarson. Structured Systems Analysis: Tools and Techniques. PrenticeHall, Englewood Cli s, New Jersey, 1986.
[Kem85]
Richard A. Kemmerer. \Testing Formal Speci cations to Detect Design Errors". IEEE Transactions on Software Engineering, SE-11(1), January 1985.
[MOS90]
M. Maybee, L. J. Osterweil, and S. D. Sykes. Q: A multi-lingual interprocess communications system for softare environment implementation. Technical Report CU-CS-476-90, University of Colorado, Boulder, June 1990.
[Mye78]
G. J. Myers. Composite/Structured Design. Van Nostrand Rheinhold Co., 1978.
[Nii86]
H. P. Nii. Blackboard systems: The blackboard model of problem solving and the evolution of blackboard architectures. AI Magazine, 7(2):38{53, August 1986.
[Ost87]
Leon J. Osterweil. Software processes are software too. In Proceedings of the Ninth International Conference on Software Engineering, pages 2{13, Monterey, CA, March 1987.
[RAYO90] Debra Richardson, Stephanie Aha, Harry Yessayan, and Leon Osterweil. Prototyping a Process-Centered Environment. Technical Report TR-90-28, Department of Information and Computer Science, University of California, April 1990.
[Har87]
David Harel. Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8:231{274, 1987.
[Hei90]
Dennis Heimbigner. TRITON Reference Manual. Arcadia Technical Report CUCS-483-90, University of Colorado, Boulder, September 1990. Version 0.7.
[RJ77]
Michael Jackson. System Development. Prentice-Hall, Inc., Englewood Cli s, New Jersey, 1983.
Douglas T. Ross and Kenneth E. Schoman Jr. Structured analysis for requirements de nition. IEEE Transactions on Software Engineering, SE-3(1):6{15, January 1977.
[Ros77]
[KCTT91a] Rudolf K. Keller, Mary Cameron, Richard N. Taylor, and Dennis B. Troup. Chiron-1: A user interface development system tailored to software environments. In Proceedings of
Douglas T. Ross. Structured Analysis (SA): A Language for Communicating Ideas. IEEE Transactions on Software Engineering, SE-3(1):16{34, January 1977.
[Roy70]
W. W. Royce. \Managing the Development of Large Software Systems". In Proceedings WESCON, August 1970.
[Jac83]
13
[SHO90]
Stanley M. Sutton, Jr., Dennis Heimbigner, and Leon J. Osterweil. Language constructs for managing change in processcentered environments. In Proc. of the Fourth Symposium on Practical Software Development Environments, 1990. Irvine, California.
[Sut90]
Stanley M. Sutton, Jr. APPL/A: A Prototype Language for Software-Process Programming. PhD thesis, University of Colorado, August 1990.
[TH77]
D. Teichrow and E. Hershey. PSL/PSA: A computer aided technique for structured documentation and analysis of information processing systems. IEEE Transactions on Software Engineering, SE-3(1):41{48, January 1977.
[Win88]
Jeannette M. Wing. A study of 12 speci cations of the library problem. IEEE Software, 5(4):66{76, July 1988.
[Ziv90]
Hadar Ziv. Summary of Requirements Analysis and Design Work that led to Triton. Arcadia Technical Report CU-90-05, University of Colorado, Boulder, August 1990.
A
APPL/A
Code
Examples
from Rebus
This appendix provides some examples of APPL/A units used in REBUS. It is not necessary to the main points of the paper but is intended to provide readers with a feel for the actual implementation code. Just a few comments on the implementation of the system and the features in the language are provided. An overview of APPL/A can be found in [SHO90]; the complete definition is presented in [Sut90]. It should be noted that the code used in REBUS and shown here is actually a slight variation on standard APPL/A; it includes some additional syntactic markers to facilitate translation.
----------
Title: NodeName Specification of the APPLA relation which associates a unique ID with a string identifier. This specification consists of a tuple type definition along with the specification of the operations defined for the relation. AUTHOR: Mark Maybee
CREATION DATE: FEB-90
-- Modified 26 Sep 1990, Harry Yessayan with Q, QDR; with Appla_Package; use Appla_Package; with RelationTypes; use RelationTypes; relation NodeName is type NodeNameTuple is tuple Name : in NameString; NodeId : out UniqueId; end tuple; entries entry Insert (Name:
in NameString);
entry Delete (Instance:
in NodeNameTuple);
entry Update (Instance: in NodeNameTuple; Update_Name: in BOOLEAN := FALSE; Name: in NameString := NoName); entry Find (Iterator: First: Instance: Found: Select_Name: Name: Select_NodeId: NodeId: end NodeName;
in in in in in in in in
out INTEGER; BOOLEAN := TRUE; out NodeNameTuple; out BOOLEAN; BOOLEAN := FALSE; NameString := NoName; BOOLEAN := FALSE; UniqueId := NoId);
Figure 7: Example REBUS relation
14
Figure 7 contains one of the relations used in REBUS. This relation maintains the relationship between the textual names applied to the individual nodes in a requirements graph and an internal identi er used by the REBUS process to identify all information associated with an individual node and to coordinate the operations on that node. Note that the insert entry, which has the e ect of creating new tuples in the relation, takes only a node name as an argument. The unique node ID is generated within the relation itself. Also note that the update entry provides only the ability to update the node name and not the node ID. These restrictions in the interface ensure that node ID's remain unique so that the REBUS data structures remain consistent. Although the restricted interface to the relation ensures that node ID's are unique, it does not ensure uniqueness of the node names. The predicate in gure 8 accomplishes this. This predicate is declared mandatory and enforced, which means that it is always to be enforced in every program which uses the relation NodeName, thus making it impossible to insert a nonunique node name into the relation. -------
----------
Every node must have a unique name. Compares each node name against every other in the relation.
WITH NodeName;
Trigger definition for node deletion. Whenever an instance from NodeName is deleted make sure to clean up all related tuples in: Status, FieldValue, State, NodeTrace, and parent/child links in the SubNode relation. AUTHOR: Mark Maybee
CREATION DATE: FEB-90
TRIGGER GLOBAL NodeNameDelete IS Status_Instance : StatusTuple; State_Instance : NodeStateTuple; Trace_Instance : NodeTraceTuple; link : UniqueId; BEGIN LOOP BEGIN TRIGGER SELECT UPON Delete (Instance: IN NodeNameTuple) IN NodeName COMPLETION DO Status_Instance := Status'TUPLE( Select_Id => TRUE, Id => Instance.NodeId); Status.Relation.Delete (Status_Instance); FOR Field:FieldValueTuple IN FieldValue WHERE Id = Instance.NodeId LOOP FieldValue.Relation.Delete (Field); END LOOP; State_Instance := NodeState'TUPLE( Select_Id => TRUE, Id => Instance.NodeId); link := State_Instance.Trace; NodeState.Relation.Delete (State_Instance); WHILE link /= Instance.NodeId LOOP Trace_Instance := NodeTrace'TUPLE( Select_Id => TRUE, Id => link); link := Trace_Instance.Link; NodeTrace.Relation.Delete (Trace_Instance); END LOOP; -- parent edges FOR Edge:SubNodeTuple IN SubNode WHERE Child = Instance.NodeId LOOP SubNode.Relation.Delete (Edge); END LOOP; -- children edges FOR Edge:SubNodeTuple IN SubNode WHERE Parent = Instance.NodeId LOOP SubNode.Relation.Delete (Edge); END LOOP; END UPON; OR TERMINATE; END TRIGGER SELECT; END; END LOOP; END NodeNameDelete;
Title: UniqueName
AUTHOR: Mark Maybee
Title: NodeNameDelete
CREATION DATE: FEB-90 USE NodeName;
PREDICATE MANDATORY ENFORCED UniqueName IS BEGIN RETURN EVERY instance:NodeNameTuple IN NodeName SATISFIES EVERY other_instance:NodeNameTuple IN NodeName SATISFIES IF instance.NodeId /= other_instance.NodeId THEN instance.Name.ALL /= other_instance.Name.ALL END IF END EVERY END EVERY; END UniqueName;
Figure 9: Example REBUS trigger
Figure 8: Example REBUS predicate Figure 9 contains a REBUS trigger used to help maintain internal data consistency. Although the UPON statement looks like an ACCEPT statement, its semantics are somewhat di erent. This UPON is never called explicitly within the REBUS code. Instead it is activated implicitly and automatically whenever the Delete entry of the NodeName relation successfully completes. Upon a successful deletion from NodeName this trigger is activated synchronously to clean up all data instances which referenced the relation instance. 15
