P209 leithiser-relationaldb-formal-specifications

A Relational Database Model for Representation of Formal
Specifications
Robert Leithiser
Department of Computer Science and Software Engineering
Auburn University
334 201-4536
leithrm@auburn.edu
ABSTRACT
Literature has established the effectiveness of formal specifications
for modeling specifications for computer system properties as well
as for verifying program correctness. However, tools that can
enable the typical commercial software developer to utilize formal
methods are not in widespread use. A possible reason for this is
that commercial tools can more easily be produced if industry-
standard storage mechanisms such as relational database
management systems (RDBMS) can be leveraged as repositories.
This paper explores how to model and store formal specifications,
specifically those based on the Zed method, in a relational
database. We explore a technique for fully decomposing the
predicate calculus to a relational database to provide a framework
for manipulation and reverse generation of formal specifications
and automating the implementation of relational states.
Categories and Subject Descriptors
D.2.10 [Software Engineering]: Design–Methodologies and
Representation.
General Terms
Algorithms, Design, Human Factors, Verification
Keywords
Zed, Relational Database Management System, RDBMS, Formal
Methods, Relational State, State Transition, Formal Specification
1. INTRODUCTION
Formal specifications provide a means to algebraically model
system behavior and state requirements as well as provide a
mechanism for verifying system correctness [17]. Despite the
effectiveness of formal specifications, implementation in industry
still lags behind their adoption in academia. In the name of Rapid
Application Development (RAD) and “agile development” [1],
much software development still relies on very lose interpretation
of software models or specifications, code duplication,
programmer preferences, and “brute-force” testing.
One of the difficulties in utilizing formal specifications lies in
comprehension [4] due in part to abstraction. This seems a
contradiction in that abstraction is generally viewed as an asset
for understanding software architecture. However, abstractness is
by definition not concrete and not malleable. Without a graphical
representation of what the abstract model means, the
specifications will be counter-intuitive to those who typically
work with code rather than discrete mathematics.
Historically, graphical tools have provided the impetus for
individuals to embrace technological breakthroughs. Only when
the technology is easy to use and visualize, does it generally gain
widespread acceptance. One only need think about the popularity
of different software programs to realize that a graphical user
interface that is intuitive to use may be far more successful in the
marketplace than a technically superior program that does not
provide a good user interface [12]. Programmers and project
leaders, even if educated in formal methods will leave these
behind for the sake of deadlines if the tools are not easy to use.
The Zed specification provides a mathematical technique to
model relations through predicate calculus that includes state [17]
and relational functions. Relational databases are based on
similar foundations that include mapping of relations [11].
Relational databases also provide the capability for animation [6]
since data can be retrieved and manipulated from any vantage
point in the model. Based on this, creation of a relational
framework for persisting Zed specifications can provide a
foundation for development of better tools.
One key to successful graphical interfaces is a relational object
framework [3] that stores metadata required for the interface. An
object relational approach provides a two-pronged mechanism to
enable user-friendly systems. The objects identify the behaviors
and properties while the relational aspect identifies how the
objects integrate with each other. Since formal methods, are
based on relationships derived from clearly defined set theory
[16], we maintain that the information for the schema can be
persisted in a relational database management system (RDBMS)
without loss of information. Relational storage of the predicate
calculus that retains the heuristics and constraints of the
specification enable opportunities for third-party tools and
industry-standard approaches such as Structured Query Language
(SQL) or XML tools to utilize this data in graphical user
interfaces to query and manage the schema.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
ACM SE’06, March, 10-12, 2006, Melbourne, Florida, USA
Copyright 2006 1-59593-315-8/06/0004…$5.00.
209

2. RELATED WORK
2.1 Zed Specifications – Perception/Usage
Leaders in the formal methods community have written that it is a
myth [7] to state that formal methods lie only in the domain of
highly trained mathematicians. However, Gray [6] outlines
difficulties of undergraduate students to understand formal
methods. He describes constraint animation as a means to
overcome difficulties in utilizing formal methods. Animation
allows queries against the specification to be answered in an
automated fashion. Our approach supports the animation concept
in that once the schema is stored in the repository, Structured
Query Language (SQL) or standard query tools can examine the
model from various perspectives. Such manipulation would be
very tedious using a strictly mathematical text representation.
2.2 Formal Methods: Tools and Trends
Several efforts have targeted creation and improvement of tools
to help further the adoption of formal methods including the Zed
technique. However, most of the current attempts do not address
the fundamental issue of database implementation. Instead, the
current approaches appear to be focused more on language
enhancements than on repository definition. Metadata definition
[9] is foundational for moving forward with tools development.
3. ZED RDBMS DESIGN REQUIREMENTS
3.1 Design Goals
We outline the following design goals to create a RDBMS that
provides an environment that facilitates the manipulation and
animation of formal Zed specifications. The vision for this design
is to foster an environment for increased use through a
comprehensive and intuitive data repository.
1. Decompose all Zed specifications to level of detail not only
to support reverse-generation of the specification, but also to
support manipulation and context-aware validation. That is,
the specification information should be stored in a format
that exposes the types and operations at the same level of
detail as a text specification. This ensures that any tool that
leverages the database can provide context validation of new
or updated specifications based on complete knowledge and
integration of related specifications. This also enables
additional benefits such as automatic RDBMS schema/code
generation based on the specification.
2. Provide extensibility for universal as well as custom type
definitions. This means that all types should be defined,
including standard Zed types, so that they can be mapped
and potentially processed by a rules-interface based engine
in order to generate the specifications.
3. Utilize native RDBMS database features to the maximum
extent possible to leverage existing capabilities rather than
building intelligence beyond that reflected by the schema.
This minimizes the amount of business logic required to
utilize the data model within an application
3.2 Design Approach
The Zed specification consists of a variety of operations or
functions that can be defined between types and relations. Rather
than attempting to define a database that encapsulates all
possibilities, we derive a database design to support a sample
application that represents typical specification scenarios. This
makes the scope of effort manageable, while still prototyping the
concept. Our approach will be to first state the requirements of
the system, next provide the Zed specification, and then walk
through the Zed RDBMS design and verify its support of the
predicate calculus. We base the specification problem and sample
solution from a programming assignment from a formal methods
graduate course [18].
3.3 Flight Reservation System
3.3.1 Requirements
The Flight Reservation system books passengers onto flights, and
handles check-in and boarding tasks. The flights are characterized
by flight date/time and number. The following constraints apply
to the system:
1. Since there can be multiple flights a day, flight numbers for a
given day need to be unique.
2. The system keeps track of passengers that made reservations
on each flight. To check-in, a passenger must be booked on
that flight. Similarly, to board, a passenger must have
already checked-in and the flight must be assigned a gate.
For our scenario, we will focus on the flight creation
operation.
3.3.2 Scope of Work
1. Define the necessary basic types, user defined sets, and
global constraints for the system.
2. Define the state space and invariants associated with the
system.
3. Define the schema for successful completion, various error
schemas, and complete (total) specification for the flight
creation operation.
3.3.3 A Zed Solution
First, we define the type definitions and assumptions for the
database definition. Complex types are used that consist of sub-
types (i.e. Date consist of Day x Month x Year) as well as
enumerated types for the output report. Range declarations are
also used for certain types (i.e. Month == 1.12). These
demonstrate a variety of methods for declaring types. One
method not included in this solution for declaring a type involves
the use of a function, which we will discuss later.
Type Definitions:
1. [Passenger, Gate]
2. Day == 1..31
3. Month == 1..12
4. Year == N
5. Date == Day x Month x Year
6. Minute == 0..59
7. Time == Hour x Minute
8. Flight = Date x Time x N
210

9. Report :== ok | flight_already_exists |
nonexistent_flight | passenger_already_booked |
passenger_not_booked | passenger_already_checkdin |
passenger_not_checkedin | passenger_already_boarded |
no_gate_assigned
Database Definition:
1. A passenger may be booked on more than one flight at a
time
2. A passenger may only check in to one flight at a time
3. A passenger may only board one flight at a time
4. A flight may only be assigned to one gate
Next, we define the main schema, states of the schema and
initialization as shown below:
Figure 1. Flight Reservation System Database Schema
Finally, we define our sample operation for creating a flight - the
Create_Flight operation:
Figure 2. Flight Reservation System Create_Flight Schema
There are additional specifications for booking a flight, checking
in, and boarding. However, for purposes of our exercise, we will
only model the first two operations, as the additional operations
do not contain any constructs not already established in the first
two operations.
4. THE ZED RDBMS IMPLEMENTATION
In this section, we define the Zed RDBMS implementation by
illustrating the database schema. We then enumerate the process
for populating the database to reflect the example. We utilize
standard database normalization principles using a functional
dependency approach [2] to identify the entities (relations) and
relationships between the entities.
4.1 Zed RDBMS Database Design
A graphical representation of a candidate database model is
shown below. This representation illustrates the major relations
and foreign key constraints for storing the Zed Schema. Some
constructs for enforcing rules required for the integrity of the Zed
specification are not shown in this diagram. This is mainly due
to limitations around the relational model. Further research may
show that an object-relational database system would allow
specification of more advanced rules directly in the design
211

Figure 3. Zed RDBMS Entity Relationship Diagram
4.2 Entity Summary Chart
The below chart summarizes the purpose of each relation in
narrative format. The definition section outlines specifically how
each entity supports the sample Zed specification.
The names of the entities do not necessarily match what they are
called in Zed. In order to provide a normalized and maintainable
database implementation, an optimal relational implementation
does not map directly to Zed specification. In some cases, it
requires multiple relations to decompose a particular construct of
Zed.
212

Table 1. Zed Entity Summary
Attribute Creates a mapping to a type extendable to a
domain. When the attribute is linked to a
domain, it becomes a set relation. An attribute
that is unbounded (not linked to a domain) may
serve as a global constant or a parameter. To
avoid inconsistencies at the predicate level, an
attribute may not be referenced as both a
parameter and a domain attribute.
Domain Identifies a schema extended through an
attribute mapped to a type. The type must
specify all of the relations required for the set.
This is done through the type composition
entity.
Domain
State
Defines a state of a domain; For example, a
domain state may be changed (delta),
unchanged, or initial. There is no limit on the
number of states linkable to a domain. The state
of the domain is defined through the linked
predicate.
Domain
Tree
Allows domain entities to be organized such that
a domain may be included in the schema of
another domain; There are no limitations
regarding reuse of schemas. A domain schema
may be reused as a child domain in multiple
domains and may itself be a parent of different
domains. The definition is not recursive (i.e. a
domain cannot be it’s own parent)
Function A function represents a relational operator. It
can either be a set or item operator (i.e.,
memberOf, union, equals). The function is
defined in terms of its output type to ensure
consistency with the predicate arguments to
which it is linked. The output type of the
function and input parameter type must align
with the type of the related attribute.
Operation Identifies a schema for operations: Operations
schemas are similar to domain schemas in that
they support linkage of states. However, they
are defined through parameters rather than
attributes.
Operation
Parameter
Defines an attribute that may be used as an input
or output parameter.
Operation
State
Defines a state of an operation; Each operation
state is assumed to be unioned for the total
specification. Thus, each operation state is
mutually exclusive. As is the case with a
domain state, the operation state is defined
through the linked predicate.
Predicate Defines an operator to be used with one or more
arguments (PredicateArgument); Predicates are
named for documentation purposes, but are
organized using the PredicateTree entity.
Predicate
Argument
Maps to an attribute in order to apply the
function (operator) specified by the Predicate
entity.
Predicate
Tree
Organizes predicates according to an expression
tree structure; This allows any combination of
functions with arguments to be specified while
retaining the granularity of the actual argument
(attribute) and relational operator (function).
Type Identifies the range and orientation of values;
Types may be referenced by other types for
super-type purposes or through the Type
Composition entity to create multi-part types.
Type
Composition
Allows multiple types to be joined together to
form a complex type. The types are joined in a
total function unless the nillable attribute is set,
in which case a partial function is used.
Type Value Identifies specific values allowed for a type –
can be used for enumerated types or for range
specifications.
4.3 Approach
4.3.1 Zed Item Naming Conventions
To avoid code generation problems with object names, the data
values for specification items are given in text format rather than
native notation. For example, DflightDb is defined in the
database as FlightDb_Delta. Similarly, a prime is identified by
the suffix “_prime”. Functions are identified by name along with
a definition. Potentially, the definition could contain the actual
special characters such as e for memberOf. For this iteration, the
definition fields are based on the TeX specification to enable
reverse-generation of a Zed specification using LaTex tools [10].
4.3.2 Database Views
For presentation purposes, several views have been created in the
database. These views map the identifiers of the entities directly
to the descriptive names and join related entities. These are used
throughout the ensuing example rather than the native data. The
actual data is linked in most cases by a unique identifier, rather
than the descriptive values.
4.4 Schema Definition
We now attempt to model the Zed Specification through data
values stored in our Zed RDBMS. In this section and in the
Operation Definition section, we enumerate the values required to
support the example.
4.4.1 Type Definition
The Type relation identifies the type name, along with a restrictor
to define how to represent the type values. At this time, the only
valid restrictor besides “N” (positive integer) is range, which
indicates that a range of two values will construct the type. This
defines types such as hour or minute that have a definite range. If
no restrictor is specified, any number of values may be associated
with the type using the TypeValue table. TypeValue includes a
sequence number to order the low and high values. The sequence
number can also be used for other types that do not require a
specific ordering for presentation purposes. For example, it may
be desirable to list the “OK” value as the first enumerated Report
type value rather than sorting alphabetically.
Table 2. Sample types with values:
213

Type Restrictor Type Values
Hour Range 1,24
Minute Range 1,60
Day Range 1..31
Month Range 1..12
Year N
Boolean True, False
Report OK, flight_already_exists,
no_gate_assigned,
nonexistent_flight, etc
FlightNo N
Passenger
There are three additional features associated with type, only one
of which is implemented in this example. The unimplemented
features include definition through a function (predicated type)
and super-typing. The SuperTypeName field permits abstract
operation definitions by allowing a sub-type to belong to a super-
type. Type composition is used and it provides the capability to
reuse the same type multiple times.
The predicated type feature provides a mechanism to define a
type in terms of a function by using the Predicate construct
(discussed later). This feature supports special types that can
include domain validation. For example, a UniqueId type could
be defined such that all values in the domain of the type must be
unique within a set based on the below Zed notation:
N | A S : seq X • UNIQUE_ID S ¤ A i,j: dom S |i Îj • S(i)
Î S(j))
Another example could be an improved definition for the Day
type. Rather than this being simply a range from 1 to 31, this
could be defined in terms of a function that calculated the valid
day range given the month and year.
TypeComposition supports many-to-many mappings between
composition types and master types. This means that the same
component type may be used as part of multiple master types.
For example, the Flight type requires a mapping of Date x Time x
N (FlightNo). This is represented by associating types “Date”,
“Time”, and FlightNo as component types with the master type
“Flight”. A master type may itself be a component of another
master type. For instance, Date is a component of Flight, but
Date itself consists of components Day, Year, and Month. This
approach is in keeping with Zed specification that allows free
definition of composite types.
Table 2. Sample Type Composition (TypeComposition):
Master Type Component Type
Time Hour
Minute
Date Day
Month
Year
Flight Date
Time
FlightNo
Booking Flight
Passenger
4.4.2 Attribute definition
The attribute definition step involves creating a mapping from a
type for use in a domain, global variable, or parameter. The
attribute can then be used as an argument for a Predicate through
PredicateArgument to define post-conditions for states of the
schema and operations. Unbounded attributes (not linked to a
domain) are used for operation parameters.
4.4.3 Domain definition
The Domain relation defines the non-operational schemas to
support the specification. The domain relation defines a schema
and identifies the subordinate relations based on mapping of the
attribute to a particular type. The attribute thus becomes the
power set of the specified type. A cardinality attribute can be
defined in the schema to limit the set to a specific number of
occurrences, but this feature is not required in this example.
DomainTree supports organization of sub-domains under a master
domain. A Domain may be enlisted as a sub-Domain in any other
Domain and a sub-Domain may itself contain domains. For
example, Flights, Bookings, Checkins, Boardings, and gates
reference FlightDb as the parent domain. FlightDb is also
referenced as a child domain by both FlightDb_Delta and
FlightDb_Schema. DomainTree is intended to be non-recursive -
the domain cannot specify itself as the parent.
Table 3. Sample Domain Tree (DomainTree):
Parent Domain Child Domain with Type (Attribute)
FlightDb Boardings: Boarding
Bookings: Booking
Checkins: Checkin
Flights: Flight
Gates: Gate
FlightDb_Delta FlightDb: Schema
FlightDb_Prime: Schema
FlightDb_Schema FlightDb: Schema
FlightDb_Delta: Schema
4.4.4 Domain State and Predicate Definition
DomainState constitutes the specification paragraph that includes
the schema and operations. Domain states may be created
without reference to a predicate if only the schema is needed. In
order to define the state post-conditions for the specification, a
predicate must be linked to the Domain State.
Predicates are defined through relations between attributes. The
Predicate relation structure supports the decomposition of all
attributes and functions. This is required to support the design
goals and allow reverse generation and consistency validation.
All expressions are reduced down to the lowest database types
and functions – no free-format expressions allowed.
The Predicate relation is the starting point for defining a predicate
and its arguments. This relation provides the operator used
between arguments. If a predicate requires different operators
(i.e. AND/OR) then separate sub predicates must be defined. This
is equivalent to a parenthetical notation within the Zed predicate
calculus. The predicate structure is formed through the Predicate
Tree to support the complete logic structure. It allows multiple
predicates to be organized in a hierarchical fashion with different
operations, similar to an Expression Tree [15]. PredicateTree and
Predicate provide a blueprint for the logic.
214

The specification of the attributes to utilize for arguments is done
through the PredicateArgument relation. The number and role of
each argument is derived based on the function associated with
the predicate. The attributes do not need to link to a domain
schema. If an attribute is specified that belongs to a domain
schema, the attribute must be part of the same domain schema
linked to the predicate. An unbounded attribute may be used for
the predicate argument in order to support the use of a global
variable or a parameter. The sequence of the argument is
significant in the case where the function is not reflexive, such as
for a subset operator or implication operator because it defines
how to arrange the arguments in the context of the operator. For
example for the predicate “boardings domain”, boarding is
identified as a subset of flights rather than the reverse.
The following diagram illustrates an instatiation of data to support
a predicate tree for state “flight_exists”. This state could then be
indicated as part of the predicate for a successful “Assign_Gate”
operation. The item in bracket refers to the data structure. The
Function entity determines the arguments that can be specified for
a particular predicate operation.
Figure 4. Flight Assignable predicate tree instantiation:
4.4.5 Implementation Summary
At this point, schema definition is complete. The database
contains information necessary to reverse-generate the schema
definition. Model consistency is provided through the
combination of database relationships and constraints discussed.
The database can be used by a graphical UI to define Zed
specifications in a self-validating and context-sensitive fashion.
Additionally, the RDBMS model can be generated directly from
the specification. The below outlines high-level methods and
relational queries to generate specifications as well as RDBMS:
1) GenerateZedSchema(Domain Name)
2) Output elementary types (select types that are not part of a
master types) along with values
3) Output composite types (select types that have component
types) and list the component types
4) Output elementary domains (select domains that are not a
child of other domains)
a) Output domain name and type based on attribute
mapping
b) Select predicate associated with the domain
c) For each predicate in predicate tree
d) Output conditions recursively (continue to access each
predicate until reaching bottom of tree outputting
conditional statements).
5) For each domain in Domain Tree
a) Output domain name and type
b) Select predicates associated with the domains in the
same way as C3.
6) GenerateRDBMS(Domain Name)
7) Enumerate Domains
a) For each Domain
b) Generate “Create Table” command
c) For each sub-type found in the attribute linked to the
domain table
i) Generate system-defined primary key
ii) Generate column definition
iii) If column indicates not nillable, then this column
becomes part of a second unique key.
d) For each predicate
e) Evaluate predicate function
i) If simple “in” relation function, then generate
foreign key relation
ii) Create constraints using predicate attributes – this
requires mapping the function (i.e. “memberOf”)
to a SQL relational construct such as “Select x
from table where x in table y”.
4.5 Operation Definition
Operation definition is similar to schema definition. The only
substantial difference is that operations include parameters that
are defined using the OperationParameter relation and that
attributes defined as Operation parameters are then specified in
the PredicateAttribute. The database must check that the
predicate arguments are parameters or that the predicate
arguments are from the same domain schema.
4.5.1 Operation Parameters
The parameters are linked directly with the operation. This
eliminates the need to re-specify the same input and output
parameters for joined operations such as in the case of
“create_database_ok and “create_database_failed_flight_exists”.
Operation states are joined (union) to represent outcomes from the
same operation. Each operation state references a specific
predicate. This predicate identifier is related to the identical
relations used for domain specification.
215

4.5.2 Operation Definition Steps
Operation definition can be summarized as follows:
1) Define high-level operations
2) Define operation states for disjoint operation results (i.e.
create_flight_ok and create_flight_failed)
3) Create unbounded attributes (do not link to a domain) to
represenet parameters such as “newFlight?” or
“report_out!”
4) Link the unbounded attributes as parameters for the
Operation
5) Create predicates that describe actions along with the
operators for arguments to the predicate
6) Create predicate tree to organize actions
7) Identify the predicate arguments by linking in the
attributes
4.5.3 Operation Table Values
The contents of the relations required to support the CreateFlight
operation are:
OperationName StateName
Create_Flight Create_Flight_Ok
Flight_failed_exists
These two operations are unioned to form the total specification.
The parameters required for the CreateFlight operation are:
OperationName AttributeName TypeName
Create_Flight newFlight_in Flight
report_out Report
The operation states are decomposed into the below Predicate
Hierarchy:
Parent
Predicate
Parent
Op.
ChildPredicate Child
Op.
create flight fail-
flight exists
and new flight in flight IN
and report flight exists equals
create flight ok and boardings unchanged equals
and bookings unchanged equals
and checkins unchanged equals
and flight_prime is flight
union new flight
equals
and gate unchanged equals
and Not_new flight in
flights
NOT
IN
and Report ok equals
flight_prime is
flight union new
flight
equals flight union new flight union
Note that “flight_prime is flight union new flight” is broken down
into a child relation in order to support the union operator to
create the new flight from the parameter. The predicate
parameters are defined in a manner similar to that for the schema
state.
4.5.4 Operation Implementation Summary
The RDBMS at this point contains the information necessary to
generate operation schemas. Additionally, generation of stored
procedures to actually change data values and state based on
parameter values received is possible. The algorithms for
generating the operations schema are identical as that for
domains, except that the Operation and Operation States define
the schema paragraphs.
The predicate attributes in conjunction with the parameter
definitions can allow the generation of database stored procedures
through a mapping table that maps the equivalent functions to
SQL Verbs. For instance, a function of “IN” that combined
domain attributes and parameter attributes in the
predicateArgument could generate a SQL statement of Select col1
from table1 where col1 in (select col2 from table2 where col2 =
parameter1.
5. CONCLUSION
In this paper, we have focused on the creation of a relational
model that can provide a repository for Zed specifications. This
has significance for providing an infrastructure for creating tools.
Using a Zed RDBMS representation allows third party tools to
leverage information in the database to persist the information in
the database to XML. The approach for persisting RDBMS
structures in XML is discussed by Fong [5].
Although formal specifications are not intended to provide
implementation details, many common software application
requirements may be met simply by implementing the state
transitions modeled through formal methods. For instance, the
business rules for workflow applications that require prior pre-
conditions in order to perform the next operation can be
implemented directly from specification into a relational database
with database constraints and table relationships.
The reality is that all software systems are merely abstractions of
finite-state machines. At the core, every operation performed is
based on the state of a set of variables at a given point in time.
Thus we do not need to demonstrate the capability to transition
any formal specification that defines states to a state-oriented
programming approach, we only need to determine the extent to
which the solution should be state-oriented which makes most
sense given the resources. As Budd [3] describes, the capability
to automate state definition and implementation has significance
in advancing efficiency and quality of software development.
5.1 Limitations and Objections
Complexity: This scenario does not stress all of the requirements
for relational representation of Zed specifications. More complex
scenarios require more complex database entities – at this point,
only a simple example has been pursued. However, Park [14] has
proven algebraically that persistence of any formal specification
can be persisted relationally.
Data Integrity: Consistency errors can only be prevented with
database constraints and through execution of stored procedures
for input/updates to certain relations. This is due mainly to
limitations in current RDBMS implementations. This highlights
the benefit of improving RDBMS systems to support post-
conditional constraints natively within the metadata, for
facilitating the storage of metadata to support the formal methods
at the database level.
216

Rapid Development: One of the objections to formal
specifications comes from the RAD programming community due
to the time involved. However, development time can actually be
improved by using tools that could facilitate the entry of Zed
specifications and generate code from the specifications. Herranz
[8] describes a system called “SLAM” that integrates rapid
prototyping with formal specification. Storing the specification in
a database opens up the opportunity to automate code generation
and maintenance.
5.2 Areas for Further Research
Relational Implementation: We have shown how to extend a
relational database with specific tables to support a formal
specification schema. A much better approach is to support this
natively in the RDBMS product, particularly since much of what
is being defined may in fact be actual database tables. Much of
the implementation requires the coding of more complex
constraint checking than afforded by standard RDBMS
implementations. This code could be eliminated by supporting
state-oriented constructs in the database.
Zed Graphical Manipulation Tool: Given the constraints
already built into the database, such a graphical tool could easily
render the relations within the specification and check the validity
of specifications. This is a significant improvement over most
current Zed tools that simply allow linear input of a specification
and then check for consistency. A relational database model
under girding the tool can make it possible for the tool to
objectify the semantics and allow manipulation and cascading of
entities within the model.
State-Oriented Programming Language Improvements:
Various innovations can integrate more closely with state-oriented
programming concepts. This includes the ability for a language to
support constructs that are based on relational state rather than
simply on procedural language. State-oriented programming has
the potential to revolutionize the quality of software development
[13].
6. ACKNOWLEDGMENTS
1. Levent Yilmaz, PhD, Professor, Auburn for assistance
with Formal Methods and Zed notation examples
2. Drew Hamilton, PhD, Professor, Auburn for guidance
in formulating paper
7. REFERENCES
[1] Agile Aliance. 2005. Agile Alliance. Retrieved December
12, 2005, from http://www.agilealliance.com/
[2] Bernstein, P. A. 1976. Synthesizing third normal form
relations from functional dependencies. ACM Trans.
Database Syst. 1, 4 (Dec. 1976), 277-298. DOI=
http://doi.acm.org/10.1145/320493.320489
[3] Budd, T. A. 1991. “Blending Imperative and Relational
Programming,” IEEE Software, vol. 8, no.1, pp. 58-65 (Jan.
1991),. DOI= http://dx.doi.org/10.1109/52.62933
[4] Finney, Kate. 1996. “Mathematical Notation in Formal
Specification: Too Difficult for the Masses?” IEEE
Transactions on Software Engineering, (Feb. 1996) pp.
158−159
[5] Fong, J, Pang, F., Bloor, C. 2001. “Converting relational
database into XML document”, Database and Expert
Systems Applications, 2001. Proceedings. 12th International
Workshop on 3-7, (Sept. 2001), pp. 61 – 65.
[6] Gray J., Schach S. 2000. “Constraint Animation Using an
Object-Oriented Declarative Language”, Proceedings of the
38th Annual ACM SE Conference, Clemson, SC, (Apr.
2000), pp. 1-10. Available online at
http://www.cis.uab.edu/gray/Pubs/acmse-2000.pdf
[7] Hall, Anthony 1990. “Seven Myths of Formal Methods,”
IEEE Software, (Sept. 1990), pp. 11−19.
[8] Herranz, Angel; Moreno-Navarro, Juan Jos´e "Rapid
Prototyping and Incremental Evolution Using SLAM," rsp,
14th IEEE International Workshop on Rapid System
Prototyping (RSP'03), (2003), p. 201.
[9] Jeffery, Keith, G. Metadata. The Future of Information
Systems, Retrieved on 12/12/2005 from
http://www.wmo.ch/web/www/WDM/ET-IDM/Doc-2-
3.html
[10] Latex Project Site. 2005. LaTeX – A document preparation
system. Retrieved December 12, 2005, from
http://www.latex-project.org/
[11] Markowitz, V. M. and Makowsky, J. A. 1990. Identifying
Extended Entity-Relationship Object Structures in Relational
Schemas. IEEE Trans. Softw. Eng., vol. 16, no. 8 (Aug.
1990), pp. 777-790. DOI=
http://dx.doi.org/10.1109/32.57618
[12] Nielsen, J. and Levy, J. 1994. Measuring usability:
preference vs. performance. Commun. ACM vol. 37, no. 4
(Apr. 1994), pp. 66-75. DOI=
http://doi.acm.org/10.1145/175276.175282
[13] Nomoto, H. 2004. State oriented programming
High Assurance Systems Engineering, 2004. Proceedings.
Eighth IEEE International Symposium, (2004), pp. 304 –
305
[14] Park, H. C. and Kim, T. G. 1998. “A relational algebraic
framework for VHDL models management,” Trans. Soc.
Comput. Simul. Int. vol. 15, no. 2 (Jun. 1998), pp. 43-55
[15] Preiss, B. R. 1999. Data Structures and Algorithms with
Object-Oriented Design Patterns in Java. NY. Wiley. p. 264.
Retrieved December 12, 2005, from
http://www.brpreiss.com/books/opus5/html/page264.html
[16] Spivey, J.M. 1992. The Z Notation: A Reference Manual,
Prentice-Hall, New York, NY, 1992
[17] Wing, J.M 1990. “A Specifier's Introduction to Formal
Methods,” IEEE Computer, (Sept. 1990) vol. 23, no, 9, pp.
8-24,
[18] Yilmaz, Z. (2005). Formal Methods for Software
Engineering - Flight Reservation Assignment. Retrieved
December 12, 2005, from
http://www.eng.auburn.edu/~yilmaz/comp7730/HW4.pdf
217

P209 leithiser-relationaldb-formal-specifications

More Related Content

What's hot

Viewers also liked

Similar to P209 leithiser-relationaldb-formal-specifications

Recently uploaded

P209 leithiser-relationaldb-formal-specifications