Towards CASE tool support for rigorous structured analysis

R. B. France Dept. of Comp. Sci. and Eng.

Florida Atlantic University Boca Raton, FL 33431

Abstract Despite their potential, formal specification tech-

niques (FST’s) are rarely used in industry. This may be due to the perceived gap between the specifica- tion methods currently used in industry and the pro- posed FST’s. In this paper we describe our work on the development of a CASE tool, called Eclectic, that seeks to reduce the gap between formal and non-formal structured methods b y integrating them in a comple- mentary manner.

1 Introduction The use of simple, intuitively-appealing specifica-

tion artifacts has made Structured Analysis (SA) [l] one of the more popular requirements specification methodologies in industry. In SA, an application is modeled in terms of abstractions of its processing, data storage, data flow, and external elements. The central specification tool of SA is the data flow dia- gram (DFD), which provides a pictorial, data flow r e p resentation of an application. DFDs are supported by information organizations that provide descriptions of data and processes depicted in the DFDs [l]. The cre- ation and interpretation of DFDs and their supporting information organizations are based on syntactic and semantic notions that are not formally defined, thus the SA specification method and its products are re- ferred to as non-formal.

The need to state application requirements unam- biguously and to rigorously reason about specified a p plication properties has generated much interest in for- mal specification techniques. A formal specification technique consists of a precise specification language and a reasoning system that can be used as a basis for rigorous specification analysis techniques.

Formal specification techniques are often touted as revolutionary alternatives to non-formal specifica- tion methods, thus it is not surprising that orga- nizations with significant investments in non-formal structured specification methods are often reluctant to adopt them. Recent research on the integration of formal and non-formal specification methods seeks to reduce the perceived gap between formal and non- formal specification approaches (e.g., see [7])

In this paper we describe the basis of a tool we are currently developing, called Eclectic (see Fig- ure l), which supports flexible and rigorous require- ments specification. SAME (Structured Analysis Mod- elling Environment) is a modeling environment that

T. W. G. Docker

CITI Ltd. Milton Keynes, U.K., MK3 6DP

+ EX~DFD

tool + Formal design specification

Figure 1: Conceptual structure of Eclectic

supports the interactive creation of executable data flow diagram (DFD) models of an application. The ExtDFD (semantically Extended DFD) tool supports the creation of a formal specification from a SAME model. The formal specification can be used as the basis for a rigorous verification of subsequent designs and programs, and for formally verifying the internal consistency of the requirements specification.

Using SAME a developer, in conjunction with the customers/users, can create a model which imposes a structure on the problem to be solved. SAME s u p ports intuitive development of such structure; any at- tempt at creating a more formal specification at this stage could impede the discovery of an effective struc- ture. Once a suitable structure has been agreed upon formalization of the requirements can take place. De- veloping and validating the formal specification may reveal gaps, ambiguities, and inconsistencies in the in- tuitive understanding of the problem as expressed by a SAME model.

Section 2 describes an example specification cre- ated in SAME and gives an outline of the structure of Atomic Level Specifications ( ASpecs), which are the formal specifications associated with DFDs. In sec- tion 3 we describe the process for transforming SAME models to ASpecs. Finally, section 4 gives our con- clusions and the current status of our research, and identifies where further research is planned.

2 Library subsystem specifications In this section, we give a SAME model of a library

subsystem and outline the structure of ASpecs. The subsystem is concerned with the borrowing of books.

0-8186-4212-2/93 $03.00 0 1993 IEEE 474

book :

books : book-id, bookstat

book- borrowers

new_bonox_details

Figure 2: DFD for borrowing a book

A borrower can only borrow a book if she or he has less than six books out and has no outstanding fines. 2.1 The library subsystem example in

SAME, and the concepts behind the tool, have been described elsewhere [4, 3 SAME provides a flexi- ble environment for speci E; ing applications during re- quirements analysis. An application model is repre- sented by:

SAME

0 a hierarchy of DFDs, and

0 a set of data object definitions.

No separate procedural details, for example, mini- specs, are required in SAME, as the data transfor- mations are contained in the definition of the data objects.

Figure 2 is a DFD representation of the library s u b system and includes examples of all four basic DFD constructs: borrower is an external entity which de- fines the interface with the ‘outside world’ and is not, by definition, modeled further in the specification; bor- rowBook is a data transform which transforms input data to output data; books is a data store, which can be viewed as a conceptual file; borrow-details is a data flow which is exported (output by the external entity borrower, and imported (input 1 by the data transform borrowBook. For the purposes of this paper, the DFD in Figure 2 is an adequate model. However, usually each process within a Level 0 DFD is refined into a DFD in its own right, to produce a hierarchy of dia- grams.

In a similar way to a data transform being an ab- straction of its refined descendant data transforms, data can often be viewed as an abstraction of its component structures. This similarity in concept be- tween the refining of processes and data flows (or, more generally, data objects) is exploited in SAME, to the extent that AEgis, the dictionary language

( 1 , i n f , [book11 bookstatus :

”OK” if bookstat = ”available” or book-stat otherwise

borrowerid, borrowed, f ines

”OK” if borrowed < 6 & fines = 0 or (borrowed, f ines) otherwise

borrowdetails : borrow er i d , book i d

borrowstatus : boo k s t at us, borrower s t at us

borrstatus : borrowed, fines

ne w -book s t atus : ”on loan” if ok

ok : true if book-status = ”OK” & borrowerstatus = ”OK” or false otherwise

Figure 3: AEgis data object definitions for the example library subsystem

borrower :

borrow er s ta tus :

within SAME, can most usefully be described in dic- tionary terms as a definitional language [ l l ] . This follows from the fact that each AEgis ‘statement’ de- fines an object, where each definition is often given in terms of other objects, many of which are them- selves defined elsewhere. The structure of a definition is object-being-defined: defining-details where defin- ing-details is a tuple.

Part of the AEgis data object definitions for the li- brary subsystem are shown in Figure 3. where the symbol ‘;’ should be read as ‘is defined as’, and the symbol ‘,’ as ‘with’. The data object book- Borrower, for example, is defined as the tuple < bookid, borrowerid, borrowDate >. 2.2 Atomic-level Specifications

An ASpec (Atomic-level Specification) is made up of a data domain specification and operation specifica- tions. The data domain specification formally charac- terizes the data model of the application, and an o p eration specification (OSpec) is a predicative specifi- cation that characterizes the behavior of a data trans- form.

An ASpec’s data domain specification is made up of three parts:

Type definitions : This part contains type defini- tions for all data flow instances and data stored in data stores.

Global state definition : This part consists of dec- larations of the data structures associated with the data stores in the DFD. An instance of the

415

book = < bookid, bookstat >

bookBorrower = < book-id, borrowerid, borrowDate >

book-status = 'OK' + bookstat

borrowDate = date

borrowed = number borrowerstatus = 'OK'+ < borrowed, f i n e s >

< book-st at us , borrow er s t at u s > < borrowed, f i n e s > 'onloan'

borrowstatus =

bow-status =

new-bookstatus =

Figure 4: Type definitions for the example library subsystem

data structure associated with a data store is called a state of the data store.

Global state constraint : This part stipulates con- straints on the states of data stores.

Figure 4 contains some of the type definitions for the library subsystem example. The type definitions are expressed in a language taken from a class of lan- guages called Data Description (DD) languages (7,

ndque [9]. A DD language provides functions for con- structing data types from elementary and pre-defined parameterized abstract data types, using aggregation (< .. . >) and union (-+-) constructors. Each ele- mentary type in a DD language is associated with an algebraic specification characterizing instances of the type in terms of functions that create and manipu- late them (these specifications are not shown in the examples given in this paper).

Ewh data store in the subsystem is modeled as a set, where a data store add access corresponds to a set element insertion, a delete access corresponds to a set element deletion, and a read access corresponds to a membership test on the set. For example, the data store books is associated with a type definition books : set(book). Some data store type definitions may specify additional access functions. OSpecs use only functions defined in data store specifications to specify the effects of data transform behavior on data store states.

Given a DFD with data stores DS1,. . . ,OS,, a global state of the DFD is an indexed set of data store states, {ds l , . . . ,ds,}, where dsi, 1 5 i 5 n is a state

The global state constraint stipulates relationships that must be maintained among the elements of a global state. For example, in the library subsystem,

which are based on the algebraic specification tec I! -

of OS,.

476

a copy in books is unavailable if and only if it is in bookborrowers. This is expressed as a constraint as follows: Vc : bookid . ( ( c E C O P Y I B O R R . bookid) E (< c,'onZoan' > E C O P Y ) ) . where C O P Y I B O R R : set(bookborrower); C O P Y : set(book) are states of the data stores bookborrowers and books respectively. Any state that satisfies all the constraints in this section of the ASpec is said to be valid. Formally, the global state constraint is a for- mula characterizing valid global states.

An OSpec for a data transform with n inputs, and p outputs, whose input/output relation is determined by the predicate 3Int . Pred(In , Out , I n t ) (where I n is an input tuple variable, Out is an output tuple variable and In t is a tuple variable denoting internal data used to define the relationship), is written as follows:

OSpec Op input in1 : intypel, . . . , in, : intype, ou tpu t out1 : outtypel, . . . , out, : outtype, internal intl : inttypel, . . . , int, : inttype, Operation 1/0 definition Pred( ln , Out , I n t ) (where I n =< in1,. . .,in, >, Out =< O U t l , . . . , out, > and I n t =< intl, . . . , int, >)

3 Transforming SAME models to AS- pecs

In this section we describe, through the library sub- system example, how the ExtDFD tool transforms SAME models to an ASpec, using formal rules and specifier supplied information. The specifier supplied information pertains to the global state constraint (state invariant) since such information is not explic- itly available in a SAME model. 3.1 Obtaining the data domain definition

In this subsection we describe how the data domain definition of an ASpec is obtained from SAME object definitions and supplementary information.

3.1.1 Obtaining data definitions

The syntactic structure of the two types of AEgis def- initions used in the example library subsystem are specified below:

e < tuplestruct >::=< name >:< objedlist >, for example, book : bookid, bookstat.

e < choicestrud >::=< name >:< objedlist > if < cond > or < i f cond > otherwise where < i J cond >::=< objectlist > if < cond > c or example, newbookstatus : "onloan" if ok.

1 or < i f cond > otherwise]],

The following are some of the functions the ExtDFD tool applies to object definitions to obtain ASpec type definitions (in what follows an instance of the syntactic class < o > is denoted 0, and the notation < ... > denotes a tuple structure, not a syntactic class):

Agg(objectlist) =< objectlist >, for example, Agg((bookid, bookstat)) = < bookid, bookstat > Choice(object1ist if cond or ifcond otherwise) = Aggkbjectlist) + Choice(i f cond) and Choace objectlist) = Choice[objectlist if cond) = Agg(object1ist)) for example, Choice(”0K” if borrowed < 6 & fines = 0 or (borrowed, f ines) otherwise) = ‘OK’+ < borrowed, f ines >.

The rules for transforming SAME object definitions to ASpec type definitions, applicable to the library subsystem, can be stated as follows, where the symbol, H, can be read ‘maps to’:

8 (name : objectlist) H (name = Agg(objectlist))

name : objectlist if cond) H

[name = Agg(objectlist))

8 (name : objectlist if cond or ifcond otherwise) w (name = Agg(objectZist) + Choice(i f cond))

The rules essentially strip away the procedural details from SAME definitions.

3.1.2

In the SAME model of the library subsystem, data stores are defined as lists which can hold up to an infi- nite number of elements, for example, the books data store is defined as a list that can hold one to an infi- nite number of book objects. The ExtDFD tool applies the following syntactic transformation on SAME data store object definitions to obtain ASpec data store type definitions:

dsobj : { 1, in f , [dselement]}) H I dsobj : set(dse1ement)) For example, (books: { l , i n f , [book]}) H (books : set(book))

If access functions (other than the usual set o p erations) need to be associated with the data store’s ASpec definition they will be added, together with specifier-supplied axioms, when the need arises, usu- ally during the development of the global constraint and the OSpec.

Obtaining the global state definition

3.1.3

SAME models do not explicitly state constraints on the global state. For this reason the ExtDFD tool de- pends on specifier-supplied information to create the global constraint of an ASpec. For the purposes of this paper we assume that the specifier supplies the global constraint (as a list of predicative expressions, see previous section) together with the axiomatic defi- nitions of any data store access functions that are not part of the global state definition.

Creating the global state constraint

3.2 Obtaining OSpecs Informally, an OSpec of a data transform is ob-

tained from SAME object definitions of its data flows as follows:

1. For each output data flow object definition, objname : obj-de f inition(obj1,. . . , obj,):

(a) replace the object definition by an equa- tion of the form: o = f (01,. . . , op) where o : objname; 01 : objr; . . . ; 0, : obj, and f is a function symbol for the transformation defined by objde f inition;

(b) determine how the objects objl, . . . , obj, are obtained by tracing their definitions in the SAME data dictionary, until they can be ex- pressed solely in terms of functions on data inputs and/or accesses on data stores;

(c) replace the variables 0 1 , . . . , opt by the func- tions determined in the previous step for objl, . . . , obj,, respectively.

2. Form the conjunction of the equations obtained for each output. This becomes the operation 1/0 definition of the OSpec. The rest of ‘the OSpec (the variable declarations) can be derived from the type definitions of the input and output flows of the data transform.

Rather than attempt to present a formalized ver- sion of the above we illustrate the transformation on an output flow of the example library subsystem.

We look at the object definition of the output flow borrowstatus. This definition is initially transformed as follows:

(borrowstatus : bookstatus, borrower-status) H

(s : borrowstatus; bks : bookstatus; brs : borrower-statuss =< bks, brs >)

Next, we look through the definitions to determine how the objects bookstatus and borrowerstatus are obtained. For booklrtatus the following transforma- tion is made:

(bookstatus : ”OK” if bookstat = ”available” or bookstat otherwise) H

(bks’ : bookstat; bks : bookstatus DSpecl

available’ A bks = I 0 K ’ ) V tbks‘ bks’ #‘ =’ available’ A bks = bks’))

We then try to determine the origin of the data ob- ject bookstat referred to in the above transformation. In this case the object definitions simply reveal that bookstat is a string. This means that the bookstat object is input to the data transform on an input flow. An examination of the input flows of the data trans- form will reveal that book-stat is read in from the data store books. We now need to know how the data is re- trieved from the data store. In this case a data item is retrieved by its key, which for books is the object bookid (this information is obtained from the oper- ational semantics of the SAME model not discussed

477

here), which is supplied as input to the data trans- form via the data flow borrowdetails. Retrieval of the object book-stat from the data store is expressed as follows (notice that no specific object definition is transformed here - this type of expression is created once an access to a data store is required and the ori- gin of the key object has been determined):

bd : borrow-details; bks' : bookstat; books;,, : books DSpec2 (< bd. bookid, bks' >E books;,)V (bd bookid # books;,, - bookid A bks' =',I)

The symbol ' I' represents the situation where un- defined data is generated on the data flow - in this case it reflects an unsuccessful retrieval from the data store, as would be the case if the book identified by the object bookid is not in the data store.

There is no need to go further with this since we have an expression solely in terms of input data. At this point we expand the expression obtained from book-status with DSpec, to get:

bks' : book-stat; bks : bookstatus; bd : borrowdetails; books;,, : books A = DSpecl A DSpec2

The expanded expression, say B, for borrowerstatus can be obtained in the same way. The expression ob- tained from borrowstatus can now be expanded as follows:

bks' : bookstat; bks : bookstatus; bd : borrowdetaih; books;,, : books b, f : number; brs : bOTTOWeTstatUS;

:. borrowers A A B A s =< bks,brs >

In the OSpec of the data transform both bks, brs will be declared as internal variables.

transformations for the output flows newbookstatus, new -borrow er s ta tus , and new -borrow detai ls can be carried out. Note that these three outputs are actually updates on data stores. Such updates are expressed in terms of set deletion and insertion operations in an OSpec.

The conjunction of the predicative expressions ob- tained for the output flows forms the OSpec's Opera- tion 1/0 definition.

4 Conclusion and further work The results produced by SAME and the ExtDFD

tool can impact on the requirements specification as follows:

0 SAME'S input to the requirements specification:

- Computer-based and/or hard-copy versions of the application models,

- Traces from the running of the executable model(2, showing the results of exercising the mo el(s) against user-defined sets of in- put data; that is, validation of the model(s).

Similar

0 ExtDFD tool's input to the requirements specifi-

- Computer-based and/or hard-copy formal specification of the functional aspects of the application models.

- Support for formal verification of subsequent implementations against the ASpec (not dis- cussed in this paper).

- Support for rigorous investigation of an a p plication's functional properties (see [ S I ) .

cation:

Work in progress includes: 0 designing and building an automated ExtDFD

0 extending the SAME 'user-friendly' interface to incorporate access to and from the ExtDFD tool.

Planned work includes providing automated support for rigorous validation of functional properties and for verifying internal consistency of ASpecs and extending our ideas to object-oriented techniques.

tool;

References T. DeMarco. Structured Analysis and System Spec- ification. Prentice-Hall, 1978.

T. W. G. Docker. SAME - a structured anal- ysis tool and its implementation in Prolog. In Logic Programming, Proceedings of the fifth inter- national conference and symposium. MIT press, 1988.

T. W. G. Docker. SAME - A structured analy- sis modelling environment: The design of an ex- ecutable data flow diagram and dictionary sys- tem. PhD thesis, Maasey University, New Zealand, 1989.

R. B. France. A predicative basis for struc- tured analysis specification tools. Technical re- port, Florida Atlantic University, to be published in Information and Software Technology, Novem- ber 1992.

R. B. France. Semantically extended data flow di- agrams: A formal specification tool. IEEE TSE, 18(4), 1992.

J. A. Goguen, J. W. Thatcher, E. G. Wagner, and J. B. Wright. An initial algebraic approach to specification correctness and implementation of abstract data types. In Current Trends in Pro- gramming Methodology, Vol 4: Data Structuring. Prentice-Hall, 1978.

L. Semmens, R. B. France, and T. W. G. Docker. Integrated structured analysis and formal specifi- cation techniques. The Computer Joumal, 35(6), 1992.

W. W. Wadge and E. A. Ashcroft. Lucid, the dataflow programming language. Academic Press, 1985.

478