0% found this document useful (0 votes)

26 views

Automated Database Applications Testing Specificat... - (2. SpecDB A Database Design For Software Speci Cations)

Uploaded by

Ilsen Eugenia Pérez Velasco

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

26 views

Automated Database Applications Testing Specificat... - (2. SpecDB A Database Design For Software Speci Cations)

Uploaded by

Ilsen Eugenia Pérez Velasco

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 42

November 4, 2009 15:43 World Scientific Book - 9in x 6in SpecDB

Chapter 2

SpecDB: A Database Design for

Software Specifications

2.1 Introduction

From the market survey of existing testing tools in Chapter 1, it was con-
cluded that the current automated tools in the market lack an understand-
ing of the functionality of the software under construction and testing. The
literature review also showed how much of the research on automated tools
can benefit from machine-readable specifications, which can reason with
the specifications and automatically generate intelligent test cases and au-
tomatically determine whether the software passed the test based on its
understanding of the specifications and design. In this chapter, one of the
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

main models of this book is presented, namely SpecDB, a database that

stores part of the software specifications to aid in the process of automated
testing.
The design of SpecDB introduced in this book focuses only on the speci-
fications required for unit testing database operations, and is not, in its cur-
rent state a full representation of the complete specifications of a software
system under construction. However, the techniques used in this chapter
can be extended to include more of the software’s specification for other
types of testing; for example, security, performance, systems or integration
testing, etc. In the following section, the motivation for the research in,
and the development of the specification representation database, SpecDB
is emphasized.

21
Mikhail, Rana Farid, et al. Automated Database Applications Testing: Specification Representation For Automated
Reasoning : Specification Representation for Automated Reasoning, World Scientific Publishing Company, 2010. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/byui/
Created from byui on 2022-03-21 20:07:37.
November 4, 2009 15:43 World Scientific Book - 9in x 6in SpecDB

22 SpecDB: A Database Design for Software Specifications

2.2 The Advantages of a Database Representation

of Specifications

Since neither UML diagrams nor written formal specifications can be used
as an input to automated testing tools, another channel is required to relay
the specifications to automated tools. UML is not executable, nor machine
readable. On the other hand, formal specifications are a complete repre-
sentation, but are difficult to write and not used frequently. A database
representation is chosen because it has the benefit of being machine readable
and also not as hard to use as formal languages. Once the specifications of
the software under construction are expressed in a machine-readable way,
the specifications may be used and reasoned about by automated tools to
test or generate the code for software applications automatically.
In order to create a software tool, that automatically tests parts of an-
other software under construction, or automatically generates parts of the
code for another specified software; the former has to have a good under-
standing of what the latter is intended to do. Accordingly, the automated
software code generating / testing tool has to be given, in a machine-
readable way, the specifications of the other software being built. The
best way a software’s specification and design can be given in a machine-
readable format is through an adaptation of the already established formal
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

methods. Hence the idea of representing specifications in a machine read-

able format evolved. In this chapter a standard methodology is introduced
which represents software specifications in a machine readable format for
the purpose of automated code generation and automated software testing.
A database representation of the specifications was chosen as opposed to
other forms or representation for the advantage of the inherently scalable
nature of database designs. The design of SpecDB is scalable and it is easy
to modify or append to the design in order to accommodate more forms
of specifications. It is then very simple to update the queries created for
previous versions of SpecDB, to accommodate the new changes. Runtime
errors for database queries are not fatal, since they do not handle memory
allocations like linked list representations. Another advantage is the use
of the already stable and reliable database management systems available
in the market, and the ability to create constrains and runtime triggers
on database tables. Such constraints can aid in discovering contradictory,
incomplete or ambiguous specifications.
Another use of SpecDB is to automatically represent programmed code
and as an output, show the specifications of the programmed code. With

Mikhail, Rana Farid, et al. Automated Database Applications Testing: Specification Representation For Automated
Reasoning : Specification Representation for Automated Reasoning, World Scientific Publishing Company, 2010. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/byui/
Created from byui on 2022-03-21 20:07:37.
November 4, 2009 15:43 World Scientific Book - 9in x 6in SpecDB

2.3. The Specification Database Design: SpecDB 23

this reverse engineering approach, SpecDB can also be used with already
existing software. The advantage of this approach is to automatically test
programmed software, giving the actual behavior for each operation. The
analysts, designers and testers can then review all the software execution
results, hence showing faults of commission that might not otherwise be
spotted by normal testing techniques that deem a test successful if the
specified behavior occurs. However, in some cases, the software errors lie
in the fact that the programmed software does more than is specified. For
example, an e-commerce application might perform its task of ordering an
item, and also (as an unwanted side effect) send credit card information or
passwords to another non-secure location! The latter security leak cannot
be spotted by conventional black box functional testing techniques. Us-
ing SpecDB in this reverse engineering approach will spot those faults of
commission as will be shown in Chapter 4.3.
Code translation from one programming language to another can be
done using the reverse engineering tool and SpecDB. Code from one lan-
guage can be fed into SpecDB, the specifications can then be used to auto-
matically generate code in another language.

2.3 The Specification Database Design: SpecDB

SpecDB is a database. The entities of the SpecDB database store the (for-
mal) specifications of a software, necessary for unit testing. SpecDB is
designed to efficiently and accurately represent those parts of the specifica-
tions shown in this chapter.
In Section 2.4, the reader will see how SpecDB covers and has a means
to represent different forms of specifications. SpecDB is also designed to
be scalable, generic, upgradeable and modifiable. Since the model is a
database, it is easy to add more entities and/or more entity attributes to
represent a specification that cannot otherwise be represented in the given
SpecDB design in this chapter. As an example of SpecDB’s scalability, in
Chapter 4 two tables are added and an existing table in SpecDB is modified
to accomplish the task of an automated constraint generator using SpecDB.
The specification representation of SpecDB is designed to be the basis
for the process of automated software generation and testing. Automated
software code generation and/or testing tools can use SpecDB to under-
stand what a software is designed to do, and hence can accurately test
such a software by creating intelligent test cases with good coverage, and

24 SpecDB: A Database Design for Software Specifications

compare actual software behavior to its corresponding specified software be-

havior. With the use of SpecDB, the processes of automated software code
generation and automated software testing can become more intelligent,
efficient and reliable. In the design of SpecDB, constructs for both formal
specifications and programming were taken into consideration. These rules
and constructs can be found in [8, 9, 11-24, 65].
Figure 2.1 shows an overall diagram of SpecDB’s design. Throughout
Section 2.4 are figures showing parts of the relational database schema of
the design of SpecDB. The relations between the entities are shown. Also
the types of the fields in each entity are shown, numeric types are identified
by the symbol ”789”, text or character types are identified by ”A”, and date
or time types are identified by a calendar card. Table keys are identified by
a ”#” symbol, and whether each field is optional or mandatory is identified
by ”O” or ”*” respectively. There are some fields that are constrained to
a list of valid values, for example, Is Constant is a Boolean value that can
be only T for true or F for false. On the left of the field name, if the
value of the field is constrained to a list of valid values, a relation symbol
is viewed. Figures 2.2 and 2.3 are focused in parts of Figure 2.1, for better
readability. Throughout Section 2.4 each entitiy is described in detail with
focused images.
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

2.4 Entities for Specific Software Requirements

In this section, each of the entities of the SpecDB design is defined and
explained in detail, including examples of values for each attribute and how
to store the different components of a software specification. First, general
entities are defined, among those are the operators, List of Tables, Table
Description, Types, Types List of valid values (LOV) and restrictions. The
SQL scripts for the creation of the entities of SpecDB are provided within
each section, their corresponding constraints are listed in Appendix A .
The reader can refer to those constraints to see the allowable values of
the attributes, this may aid in the understanding of the meaning of the
attributes in each entity in SpecDB and what each represents.

2.4.1 Operator and Valid Operands

In this section, the entities of SpecDB that hold operators and valid
operands are explained. The Operator table holds the operators of op-

2.4. Entities for Specific Software Requirements 25

Fig. 2.1 An Overall Diagram of the SpecDB Design

erations used in any software (formal) specification or code. Operators

differ from one language to another, and hence SpecDB identifies them
with unique IDs to form a generic outcome that is not language dependent.
Examples of operator symbols are: /, MOD, AND, NOT, etc. If an op-
erator is overloaded, records are added to the Valid Operands table. The
subroutine that defines the operator overloading operation should be stored
in the Function Declaration table (described in Section 2.4.5), with a sub-
routine name, the same as the operator symbol or name.

26 SpecDB: A Database Design for Software Specifications

Fig. 2.2 A Focused Diagram of the General SpecDB Design (Left Section)

Prompt Creating Table ’Operator’

Create Table Operator
(Operator_Id Number(2) Not Null
,Symbol_Syntax Varchar2(5) Not Null
,Over_Loaded Varchar2(1) Default ’F’)

The Over Loaded attribute in both the Operator and Valid Operands
tables is a Boolean variable that can be True or False. If more than three

2.4. Entities for Specific Software Requirements 27

Fig. 2.3 A Focused Diagram of the General SpecDB Design (Right Section)

operands are involved in the operator overloading process, another attribute

to represent the Operand4 Type can be added to the Valid Operands table.
The types of the operands have to reference records in the Types table
(described in Section 2.4.3).

28 SpecDB: A Database Design for Software Specifications

Fig. 2.4 Representing Operators and Operator Overloading in SpecDB

Prompt Creating Table ’Valid_Operands’

Create Table Valid_Operands
(Operator_Id Number(2) Not Null
,Operand1_Type Varchar2(10)
,Operand2_Type Varchar2(10)
,Operand3_Type Varchar2(10)
,Over_Loaded Varchar2(1) Default ’F’)
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

2.4.2 List of Tables and Table Descriptions

The List of Tables entity in SpecDB stores all the software/user-defined
sets and tables. The Table Description entity stores the names of the fields
of the user-defined tables and sets, and their respective types. In Chapter 4,
this table will be extended, to aid in the process of the automated creation
of database level business rules and constraints.

Fig. 2.5 Representing User Tables and Sets and their Description in SpecDB

2.4. Entities for Specific Software Requirements 29

Prompt Creating Table ’List_Of_Tables’

Create Table List_Of_Tables
(Table_Name Varchar2(240)
,Composite_Primary_Key Varchar2(1) Default ’T’
,Order_To_Fill Number)

2.4.3 Types, Types LOV and Type Restrictions

The Types entity stores the non-standard user-defined types. This entity
stores types that are not sets, arrays, linked lists, or any type designed
for data storage and retrieval. SpecDB represents the latter storage types
as user-defined tables in the database, and stores their descriptions in the
List of Tables and Table Descriptions entities (described in Section 2.4.2).
The Types entity stores user-defined types like month names, days of the
week, etc. Each of those user-defined types has a basic type, e.g. String,
Integer, etc. Also types can have size restrictions, e.g. a String of 20
characters. SpecDB allows for user-defined restrictions on types too. User
defined restrictions can be one of the following:

Prompt Creating Table ’Types’

Create Table Types
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

(Type_Name Varchar2(20) Not Null

,Type Varchar2(10)
,Type_Size Integer
,Has_Lov Varchar2(1) Default ’T’
,Has_Range Varchar2(1) Default ’T’
,Even_Odd Varchar2(1)
,Range_From_Int Integer
,Range_To_Int Integer
,Range_From_Real Real
,Range_To_Real Real
,Range_From_Char Char
,Range_To_Char Char
,Range_From_Date Date
,Range_To_Date Date)

2.4.3.1 List of Valid Values (LOV)

In the first kind of type-value restrictions, the values of a variable of a
specific type are constrained to only values in a defined list of valid values.

30 SpecDB: A Database Design for Software Specifications

A type can be restricted to a list of valid values, i.e. any variables of the
specified type can only take on one of the values in the LOV. For example,
the type Month Name can be either January, February, etc. In this case the
Has LOV attribute value of the Types entity for the Month Name record is
set to T for true and the valid months names are placed in the Types LOV
entity, each in a separate record.

Prompt Creating Primary Key On ’Types_Lov’

Alter Table Types_Lov
Add (Constraint Tlov_Pk Primary Key
(Lov_Id))

2.4.3.2 Other Restrictions

Types can also be restricted to a set of valid values that are better spec-
ified by ranges. In this case, the ranges are stored in the Types table in
their respective fields to define the allowable range. For example, for a
Month Number type, valid values are between the range of 1 o 12. Hence
the Range From Int in the Types Table in the record defining the months
is set to 1 and Range To Int is set to 12. A range can also be speci-
fied, with inclusions, e.g. all even integers between 0 and 100 including
0. Also exclusions can be defined from certain defined ranges by using the
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

Type Excluded Ranges Table.

Prompt Creating Table ’Type_Restrictions’

Create Table Type_Restrictions
(Type_Name Varchar2(20) Not Null
,Restriction# Integer Not Null
,Include_Exclude Varchar(1)
,Has_Range Char
,Even_Or_Odd Varchar2(1)
,Range_From_Int Integer
,Range_To_Int Integer
,Int_Value Integer
,Range_From_Char Char
,Range_To_Char Char
,Char_Value Char
,Range_From_Real Real
,Range_To_Real Real
,Real_Value Real

2.4. Entities for Specific Software Requirements 31

Fig. 2.6 Representing Types, Type Restrictions and Types Valid Values in SpecDB

,Range_From_Date Date
,Range_To_Date Date
,Date_Value Date
,Range_From_Time Date
,Range_To_Time Varchar2(240)
,Time_Value Date
,Text_Value Varchar2(240))

The Types LOV table contains a record for each value in the list of
valid values for each type with LOV restrictions. The table has been de-
normalized to include values of all basic types, based on the ”type” attribute
value in the Types table, the value of the LOV will be stored in the relevant
attribute. For example if the type of the Month Number Type is Integer,
then there will be twelve records in the Types LOV table, each record will
have a unique value between 1 and 12 stored in the Int Value attribute.

32 SpecDB: A Database Design for Software Specifications

Prompt Creating Table ’Types_Lov’

Create Table Types_Lov
(Type_Name Varchar2(20) Not Null
,Lov_Id Number Not Null
,Int_Value Integer
,Char_Value Varchar2(1)
,Text_Value Varchar2(240)
,Real_Value Real
,Date_Value Date
,Time_Value Date
,Bool_Value Smallint Default 0)

Prompt Creating Table ’Type_Excluded_Ranges’

Create Table Type_Excluded_Ranges
(Type_Name Varchar2(20) Not Null
,Restriction_Num Integer Not Null
,Has_Range Char
,Range_From_Int Integer
,Range_To_Int Integer
,Int_Value Integer
,Range_From_Char Char
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

,Range_To_Char Char
,Char_Value Char
,Range_From_Real Real
,Range_To_Real Real
,Real_Value Real
,Range_From_Date Date
,Range_To_Date Date
,Date_Value Date
,Range_From_Time Date
,Range_To_Time Varchar2(240)
,Time_Value Date
,Text_Value Varchar2(240))

2.4.4 Variables and Restrictions on Variable Values

In SpecDB, the Var entity stores the specifications of a used variable. In-
cluding, its type, that can be also a user-defined type already defined in the
Types entity. The SpecDB design, takes into account the fact that in the

2.4. Entities for Specific Software Requirements 33

same software, many different variables can have the same name, but de-
fined in different contexts or subroutines. This entity stores qualities each
variable should possess. This aids automated testing tools in creating test
cases that make sure that in all the software’s execution cycle and in all its
states, each variable maintains its designed properties. If a variable is part
of a class or an object, this can be specified, together with its encapsulation
property; public, private or protected.

Prompt Creating Table ’Var’

Create Table Var
(Var_Id Integer Not Null
,Var_Name Varchar2(15) Not Null
,Type Varchar2(10)
,Sub_Routine_Name Varchar2(30)
,Length Integer
,Is_Input Varchar2(1) Default ’T’
,Is_Output Varchar2(1) Default ’T’
,Is_Constant Varchar2(1) Default ’T’
,Is_Gui_Object Varchar2(1) Default ’T’
,Class_Name Varchar2(240)
,Object_Name Varchar2(240)
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

,Encapsulation Varchar2(10)
,Gui_Window Varchar2(240)
,Has_Lov_Restrictions Varchar2(1) Default ’T’
,Has_Table_Restrictions Varchar2(1) Default ’T’
,Has_Other_Restrictions Varchar2(1) Default ’T’
,Num_Of_Other_Restrictions Integer
,Physical_Logical Varchar2(1)
,Mandatory Varchar2(1) Default ’T’
,Default_Char_Value Varchar2(1)
,Default_Text_Value Varchar2(100)
,Default_Int_Value Integer
,Default_Real_Value Real
,Default_Bool_Value Varchar2(1) Default ’T’
,Default_Date_Value Date
,Default_Time_Value Date
,Current_Char_Value Varchar2(1)
,Current_Real_Value Real
,Current_Text_Value Varchar2(100)

34 SpecDB: A Database Design for Software Specifications

,Current_Int_Value Integer
,Current_Bool_Value Varchar2(1) Default ’T’
,Current_Date_Value Date
,Current_Time_Value Date)

Variables can have pre-defined types, but in turn also have their own
restrictions. SpecDB has the flexibility to define restrictions on both types
and variables. A variable can have a LOV restriction or other restrictions
as the ones previously discussed for the types restrictions.
A variable can also have a Table Restriction, i.e. the variable can only
take on values that are stored in a specific field in a user-defined table. The
Var LOV table stores preset values that are preset before a software is exe-
cuted, e.g. names of the months of the year. On the other hand, a variable
can be restricted to take on values that are determined as the software ex-
ecutes, these values are stored in user-defined tables; e.g. names of people
in an address book, where the names are continuously added as the address
book is used. Those restrictions are stored in the Var Table Restrictions
entity. SpecDB gives the flexibility for a variable to be restricted to take
on only values from another table, or, by exclusion, to take any value that
does not currently exist in the specified table. This is done by specifying
the operator in the Var Table Restrictions entity.
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

Prompt Creating Table ’Var_Table_Restrictions’

Create Table Var_Table_Restrictions
(Var_Tab_Rst_Id Integer Not Null
,Var_Id Integer Not Null
,Sub_Routine_Name Varchar2(240)
,Var_Name Varchar2(30)
,Input_Or_Output Varchar2(1)
,Operator Varchar2(240) Not Null
,Which_Table Varchar2(240) Not Null
,Which_Field Varchar2(240)
,Equivalence_Class Varchar2(240))

Prompt Creating Table ’Var_Restrictions’

Create Table Var_Restrictions
(Var_Id Integer
,Restriction_Num Integer Not Null
,Sub_Routine_Name Varchar2(50)

2.4. Entities for Specific Software Requirements 35

Fig. 2.7 Representing Variables, Variable Restrictions and Variable Valid Values in
SpecDB
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

,Var_Name Varchar2(30)
,Input_Or_Output Char
,Include_Exclude Varchar(1)
,Has_Range Char
,Even_Or_Odd Varchar2(1)
,Equivalence_Class Varchar2(240)
,Range_From_Int Integer
,Range_To_Int Integer
,Int_Value Integer
,Range_From_Char Char
,Range_To_Char Char
,Char_Value Char
,Range_From_Real Real
,Range_To_Real Real
,Real_Value Real
,Range_From_Date Date
,Range_To_Date Date

36 SpecDB: A Database Design for Software Specifications

,Date_Value Date
,Range_From_Time Date
,Range_To_Time Varchar2(240)
,Time_Value Date
,Text_Value Varchar2(240))

Prompt Creating Table ’Var_LOV’

Create Table Var_Lov
(Id Number Not Null
,Var_Id Integer
,Var_Name Varchar2(30)
,Sub_Routine_Name Varchar2(240)
,Input_Or_Output Char
,Equivalence_Class Varchar2(240)
,Char_Value Varchar2(1)
,Text_Value Varchar2(100)
,Int_Value Integer
,Real_Value Real
,Date_Value Date
,Time_Value Date)
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

2.4.5 Procedure, Function, and Subroutine Descriptions

Subroutines, or units are a major part of software specifications as well
as the actual program code, and the focus of this book. In the SpecDB
database, procedures differ from functions in the fact that functions return
a value, whereas procedures are subroutines that do not return a value, yet
can change the system state. If a procedure should change the state of the
system, then the value of the Changes System State field, is set to true.
Automated testing tools can use this specification to make sure that the
programmed subroutines are implemented as designed. The inputs for both
procedures and functions are placed in the Subroutine IP Description en-
tity. Inputs are represented with their respective orders using the IP Order
field.

Prompt Creating Table ’Procedure’

Create Table Procedure
(Proc_Name Varchar2(30) Not Null
,Num_Of_Inputs Integer
,Changes_System_State Varchar2(1) Default ’T’

2.4. Entities for Specific Software Requirements 37

,Class_Name Varchar2(240)
,Encapsulation Varchar2(10))

For a function
that takes two inputs, such as Calculate Interest Only Monthly Mortgage
(Loan Amount, Rate), the record in the Function Declaration ta-
ble will be: (Calculate Interest Only Monthly Mortgage, 2, Real, 68,
Monthly Mortgage, F, F, F, F, . . . ) where F stands for False. There
should be two records in the Sub Routine IP Description table: (Calcu-
late Interest Only Monthly Mortgage, 1, Real, Loan Amount, F, F, T) and
(Calculate Interest Only Monthly Mortgage, 2, Real, Rate, F, F, T). The
two inputs can have a restriction to be greater than zero. In this case two
records have to be placed in the Var Restrictions table to describe those
restrictions.

Prompt Creating Table ’Sub_Routine_IP_Description’

Create Table Sub_Routine_Ip_Description
(Subroutine_Name Varchar2(30) Not Null
,Ip_Order Integer Not Null
,Type Varchar2(240) Not Null
,Sr_Var_Name Varchar2(240)
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

,Has_Lov_Restrictions Char
,Has_Table_Restrictions Char
,Has_Other_Restrictions Char)

Prompt Creating Table ’Function_Declaration’

Create Table Function_Declaration
(Func_Name Varchar2(240) Not Null
,Num_Of_Inputs Integer
,Op_Type Varchar2(240) Not Null
,Op_Var_Id Integer
,Op_Var_Name Varchar2(30)
,Op_Has_Lov_Restrictions Varchar2(1) Default ’T’
,Op_Has_Table_Restictions Varchar2(1) Default ’T’
,Op_Has_Other_Restrictions Varchar2(1) Default ’T’
,Changes_System_State Varchar2(1) Default ’T’
,Class_Name Varchar2(240)
,Encapsulation Varchar2(10) )

38 SpecDB: A Database Design for Software Specifications

Fig. 2.8 Representing Units (Subroutines) in SpecDB

The output value returned by a function (OP) can also have restrictions.
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

SpecDB provides a place to store these pre-determined restrictions on the

valid allowable values a function can return.

2.4.6 Subroutine Parameters and Post-Conditions

Each time a subroutine is invoked during the life of the software run-
time, it is given different parameters. The Subroutine IP Instance is
where the values, or the sources for the values of the parameters are
specified for each one of those instances. For example, if on the sev-
enth call to Calculate Interest Only Monthly Mortgage in the program
specifications or program, the input is taken from the GUI text fields
(:HouseValue, :NegotiatedRate), in the Interest Only window. Accord-
ingly, the records in the Subroutine IP Instance table will be (7,1, Calcu-
late Interest Only Monthly Mortgage, GUI, , :HouseValue, Interest Only,
. . . ).

Prompt Creating Table ’Sub_Routine_Ip_Instance’

Create Table Sub_Routine_Ip_Instance

2.4. Entities for Specific Software Requirements 39

(Instance_Num Integer Not Null

,Ip_Order Integer Not Null
,Subroutine_Name Varchar2(30) Not Null
,Source_Type Varchar2(5)
,From_Var_Id Integer
,From_Gui_Object_Name Varchar2(50)
,From_Gui_Window Varchar2(50)
,From_Seq_Name Varchar2(30)
,From_Char_Const_Value Varchar2(1)
,From_Text_Const_Value Varchar2(100)
,From_Int_Const_Value Integer
,From_Real_Const_Value Real
,From_Bool_Const_Value Varchar2(1) Default ’T’
,From_Date_Const_Value Date
,From_Time_Const_Value Date
,Object_Name Varchar2(240) )

The Designed SR Post Conditions, holds the designed post conditions

for subroutines, functions and procedures. Those will be compared to the
actual post conditions during the testing phase to spot out software errors if
there exists discrepancies between the designed subroutine post conditions
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

in this table and the actual runtime subroutine post conditions, declared
in the Runtime SR Post Conditions table.
The Type of the post condition could be a modification to or execution of
one of the following: GUI, DB, File, Report, Sequence, Message, Database
Privilege or Role, Global Variable, Commit command, Savepoint command,
Rollback, Run another program, Open a window or terminate the program
execution. The source and the destination of the post condition are specified
in this table.
If the subroutine should result in a database operation being executed,
the unique ID for that operation is placed in the DB Operation Num
field, and the actual specifications for that operation is placed in the
DB operations and DB Operation Details tables.

Prompt Creating Table ’Runtime_Sr_Post_Conditions’

Create Table Runtime_Sr_Post_Conditions
(Sub_Routine_Name Varchar2(50) Not Null
,Post_Cond_Num Integer Not Null
,Instance_Num Integer Not Null

40 SpecDB: A Database Design for Software Specifications

,Source Varchar2(5)
,Post_Cond_Type Varchar2(10)
,From_Var_Id Integer
,From_Gui_Obj_Name Varchar2(30)
,From_Gui_Window Varchar2(30)
,From_Seq_Name Varchar2(20)
,From_Char_Const_Value Varchar2(1)
,From_Text_Const_Value Varchar2(100)
,From_Int_Const_Value Integer
,From_Real_Const_Value Real
,From_Bool_Const_Value Varchar2(1) Default ’T’
,From_Date_Const_Value Date
,From_Time_Const_Value Date
,To_Gui_Obj_Name Varchar2(30)
,To_Gui_Window Varchar2(30)
,To_Var_Id Integer
,To_File_Name Varchar2(100)
,To_File_Type Varchar2(10)
,To_File_Change Varchar2(10)
,To_File_New_Location Varchar2(100)
,To_Message_Text Varchar2(240)
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

,To_Report_Name Varchar2(100)
,To_Report_Destination Varchar2(10)
,To_Report_File_Name Varchar2(100)
,To_Inc_Seq_Name Varchar2(30)
,Run_Exe_Name Varchar2(100)
,Savepoint_Rollback_Name Varchar2(20)
,Open_Window_Name Varchar2(40)
,Db_Operation_Num Integer )

The Runtime SR Post Conditions table is a duplicate of the De-

signed SR Post Conditions, with the difference that actual post conditions
that occur due to the execution of a function or procedure are stored in
the latter. Each time a subroutine is instantiated during runtime, an in-
stance number is generated, and the input parameters used to invoke the
subroutine, is stored in the Subroutine IP Description table.
The post conditions of that instance are stored in the Run-
time SR Post Conditions table, using that same instance number. The
fields in this table are exactly the same as those of the De-

2.4. Entities for Specific Software Requirements 41

Fig. 2.9 Representing Subroutines Instances, and Post Conditions in SpecDB

signed SR Post Conditions table, with the difference that the field Instance
number is added, and is part of the key to this table. Also the data in the
records indicate the actual runtime post condition behavior after a sub-
routine is run, as opposed to the designed or the expected, detailed in the
Designed SR Post Conditions table. This table will be populated after the
software is implemented and executed. An automated testing tool can make
use of this table.

Prompt Creating Table ’Designed_Sr_Post_Conditions’

Create Table Designed_Sr_Post_Conditions
(Sub_Routine_Name Varchar2(50) Not Null
,Post_Cond_Num Integer Not Null
,Source Varchar2(5)
,Post_Cond_Type Varchar2(10)
,From_Var_Id Integer
,From_Gui_Obj_Name Varchar2(30)
,From_Gui_Window Varchar2(30)

42 SpecDB: A Database Design for Software Specifications

,From_Seq_Name Varchar2(20)
,From_Char_Const_Value Varchar2(1)
,From_Text_Const_Value Varchar2(100)
,From_Int_Const_Value Integer
,From_Real_Const_Value Real
,From_Bool_Const_Value Varchar2(1) Default ’T’
,From_Date_Const_Value Date
,From_Time_Const_Value Date
,To_Gui_Obj_Name Varchar2(30)
,To_Gui_Window Varchar2(30)
,To_Var_Id Integer
,To_File_Name Varchar2(100)
,To_File_Type Varchar2(10)
,To_File_Change Varchar2(10)
,To_File_New_Location Varchar2(100)
,To_Message_Text Varchar2(240)
,To_Report_Name Varchar2(100)
,To_Report_Destination Varchar2(10)
,To_Report_File_Name Varchar2(100)
,To_Inc_Seq_Name Varchar2(30)
,Run_Exe_Name Varchar2(100)
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

,Open_Window_Name Varchar2(40)
,Savepoint_Rollback_Name Varchar2(30)
,Db_Operation_Num Integer )

2.4.7 Dataflow, Triggers and Input/Output Definitions

In order to specify the order of operations of a unit in an application, the
operations have to be given serial numbers. Accordingly, as a preparation
stage for representing the specifications in SpecDB, unique dataflow num-
bers are given to operations in the (formal) specifications. Accordingly,
SpecDB assumes that the program is numbered. Every line of the (formal)
specification of a software as well as every line of code generated is given a
unique serial number. SpecDB assumes that every line of code is a simple
program statement, unnecessary bundling of code or specification on the
same line is forbidden in this representation, to simplify the representation
and enhance readability from SpecDB by automated tools. Accordingly, a
preparation phase to simplify the specifications or code is necessary. The
dataflow table stores what each line of the (formal) specification presents.

2.4. Entities for Specific Software Requirements 43

SpecDB can also be used to represent actual lines of programmed code and
automatically compare the actual behavior to the specified behavior using
this reverse engineering approach where the Dataflow table would contain
the actual programmed lines of code.

Prompt Creating Table ’Dataflow’

Create Table Dataflow
(Pos_Num Integer Not Null
,Suc_Num Integer Not Null
,Pos_Type Varchar2(9) Default ’Process’
,Result Varchar2(1) Default ’T’
,Procedure_Name Varchar2(240)
,Instance_Num Integer
,Open_Window_Name Varchar2(240)
,Run_Exe_Name Varchar2(240)
,Object_Name Varchar2(240)
,Class_Name Varchar2(240) )

Each position is identified by a number, a successor number, and a

type. The position type can be one of the following: initial, begin, in-
put, assignment, decision, while loop, for loop, run exe, output, subroutine
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

call, database, open window, construct object, destruct object, call object
method, end, end loop, end for, or terminal. According to the type of the
position, the successor number can change. A position number can have
many successor numbers and vice versa. For example, a decision point can
have two results (true or false), and hence two successors, depending on the
result.
Database management systems have structures similar to subroutines
called triggers. The difference between triggers and other subroutines is
that procedures or functions are called explicitly, sometimes with argu-
ments, whereas triggers are executed implicitly when a pre-specified event
occurs, also there are no arguments passed to triggers. For our design spec-
ification purpose, the trigger table stores the events that cause triggers to
execute. Those cannot be part of the normal dataflow table, since they do
not follow the same dataflow process as the rest of the software specification
or code. However, this table will refer to the dataflow table once a trigger is
defined, to adopt the same technique used to describe a normal subroutine
body, to describe the trigger body. Also what is named smart trigger is
described in this table. Smart triggers execute once a pre-specified event

44 SpecDB: A Database Design for Software Specifications

occurs to a graphical user interface (GUI) object. For example, when the
mouse pointer enters a specific area in a window or when a button right
click occurs, etc. If the LHS var is assigned to a GUI object value, the
var id is the place to identify that GUI object, since all GUI used vars are
listed in the VAR table.

Prompt Creating Table ’Input_Output_Definition’

Create Table Input_Output_Definition
(Pos_Num Integer Not Null
,Var_Id Number(3) Not Null
,Var_Sequence Integer Not Null
,Input_Output Varchar2(1)
,Source_Destination_Var_Id Integer
,Type Varchar2(240)
,Report_Name Varchar2(240)
,Destination_Device Varchar2(240)
,File_Name Varchar2(240)
,File_Type Varchar2(240)
,File_Append_Overwrite Varchar2(1)
,Message_Text Varchar2(240))

The Input Output Definition table describes how inputs and outputs to
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

and from the software are represented. Inputs and outputs can be repre-
sented in many forms, file, database, through the GUI or to output devices
like a printer (where a report is printed), or from other input devices. If
the input or output is a database operation, then in the dataflow table,
the line of code will be of type database operation, not input or output,
and hence this type of input or output will not be represented in this In-
put Output Definition table.

Prompt Creating Table ’Triggers’

Create Table Triggers
(Trigger_Name Varchar2(30) Not Null
,Dataflow_Pos_Num Integer
,On_Gui_Object Varchar2(1) Default ’T’
,Gui_Object_Var_Id Integer
,Gui_Trigger_Event Varchar2(240)
,On_Table Varchar2(1) Default ’T’
,Before_After Varchar2(1)
,Table_Insert Varchar2(1) Default ’T’

2.4. Entities for Specific Software Requirements 45

Fig. 2.10 Representing Dataflow, Triggers and System Inputs and Outputs in SpecDB

,Table_Delete Varchar2(1) Default ’T’

,Table_Update Varchar2(1) Default ’T’
,Field_Name Varchar2(20)
,Table_Name Varchar2(30)
,For_Each_Row Varchar2(1) Default ’T’
,When_Condition_Num Integer)

2.4.8 Assignment and Calculation

Assignment operations and calculations are discussed in this section. A
variable can be assigned to a constant or another variable, e.g. a:=65; b:=c.
A variable can also be assigned to a calculation or a predicate statement
resulting in a true or false value, e.g. a:=5+b; e:= (a AND b) OR (c XOR
d). If a variable is assigned to a calculation, then there might be a number
of records in the Calculation table describing this calculation. A calculation

46 SpecDB: A Database Design for Software Specifications

identifier is provided in the Cal Num field, and then at least one record is
inserted in the Calculations table.

Prompt Creating Table ’Assignment’

Create Table Assignment
(Pos_Num Integer Not Null
,Assign_To_Var_Id Number(3) Not Null
,Rhs_Type Varchar2(5)
,Const_Type Varchar2(10)
,Cal_Num Integer
,Func_Name Varchar2(100)
,Instance_Num Integer
,Var_Id Number(3)
,Const_Int_Value Integer
,Const_Char_Value Varchar2(1)
,Const_Real_Value Real
,Const_Date_Value Date
,Const_Text_Value Varchar2(100)
,Const_Boolean_Value Varchar2(1) Default ’T’
,Const_Time_Value Date
,Sequence_Name Varchar2(30))
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

Fig. 2.11 Representing Assignment Operations and Calculations in SpecDB

2.4. Entities for Specific Software Requirements 47

In the Calculation table, complex calculations are stored in the form

of simple components. Each component involves only two operands and
an operator. An operand can be simple like a variable or a constant or
can be complex, and consists in itself of components. An example of a
Simple Calculation is a+b. The LHS is a variable, and thus ”a” will be
stored in the Left Var ID field. ”b” will be stored in the Right Var ID field,
and the operator ID for ”+” will be stored in the Operator ID field. Also
a+109; a¡b; a - mod(b); are all simple calculations. Examples of a complex
calculations are: (a / b) + c; (U OR V) AND (Not W), are all complex
calculations.

Prompt Creating Table ’Calculation’

Create Table Calculation
(Cal_Num Integer Not Null
,Component_Num Integer Not Null
,Left_Operand_Type Varchar2(5) Default ’Comp’ Not Null
,Left_Component_Num Integer
,Left_Var_Id Integer
,Left_Text_Const Varchar2(240)
,Left_Num_Const Float(12)
,Left_Func_Name Varchar2(50)
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

,Left_Func_Instance_Num Integer
,Right_Operand_Type Varchar2(5) Default ’Comp’ Not Null
,Right_Component_Num Integer
,Right_Var_Id Integer
,Right_Text_Const Varchar2(240)
,Right_Num_Const Float(12)
,Right_Func_Name Varchar2(50)
,Right_Func_Instance_Num Integer
,Operator_Id Integer Not Null)

In the first example, (a/b) + c, (a/b) is one component, and c is an-

other simple component. Accordingly, there will be two records for this
calculation in the Calculation table. One record with Component Num
= 1, where Left Operand Type=”Var”, Left var ID is that of ”a”, and
Right Operand Type = ”Var”, and Right Var ID is that of ”b” and Op-
erator ID is that of the ”/” operator sign. The other record with the
same Cal Num, but Component Num = 2, will have Left Operand Type
= ”Comp”, the Left Component Num = 1, and the Right Operand Type

48 SpecDB: A Database Design for Software Specifications

= ”Var” and the Right Var ID = that of ”c”.

2.4.9 Predicate
The Predicate table described in this section stores complex predicate state-
ments or database conditions. Each line of specification or code i.e. posi-
tion, has a type that is stored in the Dataflow table. If the Pos Type is
either a decision, while loop, for loop, or database operation, the statement
details at this line of code are stored in this Predicate table. In case the
Pos Type is a decision, a decision statement can have a simple or a complex
predicate. An example of a simple predicate is:

if a = b then ...

In this case, there are no calculations, or several components. There

is only one component, and the left and right operands are variables, or a
variable and a constant. An example of a complex predicate is

if (a+b) < (d+11) then ...

In this case there are several components. The components are them-
selves calculations. Records are inserted in this table starting with the low-
est level components, i.e. the ones that contain only simple predicates, with
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

just variables and constants, i.e. from the inside out. Finally the predicate
that represents the relationship among the already described components
is inserted, using their respective component numbers. The technique is
very similar to that used in the calculation table.

Prompt Creating Table ’Predicate’

Create Table Predicate
(Pos_Num Number(7) Not Null
,Component_Num Number(7) Not Null
,Left_Operand_Type Varchar2(5) Default ’Comp’
,Left_Component_Num Integer
,Left_Var_Id Integer
,Left_Text_Const Varchar2(240)
,Left_Num_Const Float(12)
,Left_Table_Name Varchar2(240)
,Left_Table_Alias Varchar2(240)
,Left_Db_Field Varchar2(240)
,Left_Func_Name Varchar2(240)

2.4. Entities for Specific Software Requirements 49

,Left_Func_Inst_Num Integer
,In_Db_Oper_Num Integer
,Right_Operand_Type Varchar2(5) Default ’Comp’
,Right_Component_Num Integer
,Right_Var_Id Integer
,Right_Text_Const Varchar2(240)
,Right_Num_Const Float(12)
,Right_Func_Name Varchar2(240)
,Right_Func_Instance_Num Integer
,Right_Table_Name Varchar2(240)
,Right_Table_Alias Varchar2(240)
,Right_Db_Field Varchar2(240)
,Operator_Id Integer Not Null )

In case the Pos Type is a loop, the beginning of a loop is a decision

statement, determining whether another iteration through the loop should
take place or to exit. The same discussion above for decisions is followed
to describe a while loop predicate.
In case the Pos Type is a database operation, the predicate table is
where the WHERE clause of a database operation is stored. Similar to the
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

above examples, the operands are database fields compared to one another,
for example: S.ID = Emp.ID. In this example, both the left and the right
operands are database fields in the S and Emp tables (or table alias) This
example will be treated as a simple predicate, as discussed above. However,
if the WHERE clause had many such simple predicates joined with AND
or other operators, they will again be treated each as a component. The
components will be stored in this predicate table as in the above examples
involving only variables, and/or constants.
Finally, if the Pos Type is a set operation, the predicate table is also
used to express operations on sets. For example:

N∈
/ Known

In this case, the Component Type is a DB Table. Database tables are

sets. And the records are the tuples belonging to the sets. Left and/or
Right Table Name are the fields from the predicate table used in this case.

50 SpecDB: A Database Design for Software Specifications

Fig. 2.12 Representing Predicates and Conditions in SpecDB

2.4.10 Database Operations

In this subsection
the DB Operations, DB Operation Tables and DB Operation Details ta-
bles of SpecDB are discussed. The DB Operation Tables table contains a
list of tables involved in each DB operation defined in the DB Operations
table. The DB Operations table stores database structure query language
(SQL) statements. Good references for SQL standards can be found in [73,
74, 75, 76]. Since a database select, insert, delete, update, etc, each is con-
sidered one statement; this table is dedicated to describe those operations.
There is one record for each SQL statement in the software specification or
code.
The WHERE clause is stored in the Predicate table, in this case the
DB Condition Num is the same as the Pos Num in the predicate table.
This table is a representation of some of the database operations that can
be programmed in a PL-SQL environment. Following the same technique all

2.4. Entities for Specific Software Requirements 51

the SQL Language functions can be represented in this table. The functions
listed and accounted for by fields are just a few examples to show the
feasibility of the approach. The DB Operation Details table contains the
details of the Database operations described in the DB Operations table.
For SELECT Statements, the variables to select are inserted in the
Field Name attribute. If there are n fields to select, there will be n records
in this table with the same DB Operation Num. If the database operation
was SELECT *, then there will be only one record, and the Field Name
will be *. The INTO portion of the select statement, i.e. the variable
where the selected value should be stored is indicated in the INTO Var ID
attribute. The FROM clause is listed in the DB Operation Tables table,
with the same DB Operation Num. Finally, The WHERE clause is stored
in the Predicate table, with the POS NUM = the DB Conition Num. If
a cursor is defined, the Operation Type is in the DB Operations table is
’Cursor’, it is treated the same as a SELECT statement, with the addition of
identifying the cursor name in the Cursor Name field in the DB Operations
table. Also if a Fetch operation on a cursor is the DB Operation type, again
the Cursor Name field is populated, and all the details of which values to
put from the cursor SELECT statement into variables are all stored in the
DB Operation Details table.
For INSERT INTO statements, the table name will be in
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

DB Operation Tables table, with the same DB Operation Num. If spe-

cific attributes (sequence) is specified, there will be a record in this table
for each attribute. The attributes will be stored in the Field Name field.
The corresponding value that should be inserted in this attribute, will be
placed in the appropriate Type Value field, according to its type.

Prompt Creating Table ’DB_Operations’

Create Table Db_Operations
(Db_Operation_Num Integer Not Null
,Operation_Type Varchar2(6)
,Db_Name Varchar2(30)
,Db_Condition_Num Integer
,Sequence_Name Varchar2(240)
,Sequence_Incremented Varchar2(1) Default ’T’
,Sequence_Start_With Number
,Savepoint_Rollback_Name Varchar2(30)
,Role_Priv_Name Varchar2(6)
,Role_Priv_User Varchar2(20)

52 SpecDB: A Database Design for Software Specifications

,Priv_Object_Name Varchar2(240)
,Grant_Admin_Option Varchar2(1) Default ’T’
,View_Name Varchar2(240)
,Table_Name Varchar2(240)
,As_Table_Name Varchar2(240)
,As_Select Varchar2(1) Default ’T’
,Cursor_Name Varchar2(240) )
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

Fig. 2.13 Representing Database Operations in SpecDB

If the database statement is an INSERT statement of the following type:

INSERT INTO table_name SELECT ...

then the Insert Select attribute will be set to true. Also the In-
sert Select DB Oper Num will be filled out and the Select operation will
be defined in the DB Operations table, under its Pos Num.

Prompt Creating Table ’DB_Operation_Details’

Create Table DB_Operation_Details
(Db_Operation_Num Integer Not Null

2.4. Entities for Specific Software Requirements 53

,Order_Num Integer Not Null

,Field_Type Varchar2(10)
,Field_Name Varchar2(30)
,Into_Var_Id Number
,From_Var_Id Integer
,Char_Value Varchar2(1)
,Text_Value Varchar2(100)
,Int_Value Integer
,Real_Value Real
,Bool_Value Varchar2(1) Default ’T’
,Date_Value Date
,Time_Value Date
,Whole_Table Varchar2(1) Default ’T’
,Order_By_Requested Varchar2(1) Default ’T’
,Order_Desc Varchar2(1) Default ’T’
,Order_By_First Varchar2(15)
,Order_By_Second Varchar2(15)
,Order_By_Third Varchar2(15)
,Order_By_Fourth Varchar2(15)
,Insert_Select Varchar2(1) Default ’T’
,Insert_Select_Db_Oper_Num Number
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

,Delete_Where_Pos_Num Number )

For DELETE datbase operations, the table name will be in the

DB Operation Tables table, with the same DB Operation Num. If there
is no WHERE clause, then all the rows in the table will be deleted, and
thus the Whole Table field should be set to True. If there are some specific
rows to be deleted, identified by a where clause, the where clause will be
specified in the Predicate table, under a POS Num equal to the position
number of the current Delete Statement in the code. This number will be
also stored in the Delete Where Pos Num field.
For UPDATE database operations, the table name will be in the
DB Operation Tables table, with the same DB Operation Num. The at-
tributes will be stored in the Field name field. The corresponding value
that should be inserted in this attribute, will be placed in the appropriate
’type’ Value field, according to its type. (if there are n fields to update,
there will be n records in this table with the same DB Operation Num).
The WHERE clause is stored in the Predicate table, with the Pos Num =
the DB Condition Num. In a query, the same table can be used twice, with

54 SpecDB: A Database Design for Software Specifications

different aliases. Accordingly, the key to the DB Operation Tables table is

a numeric ID.

Prompt Creating Table ’DB_Operation_Tables’

Create Table Db_Operation_Tables
(Id Integer Not Null
,Db_Operation_Num Integer
,Db_Constraint_Num Number
,Table_Name Varchar2(30) Not Null
,Table_Alias Varchar2(240) )

2.4.11 Classes, Objects and Class Relations

SpecDB can represent object oriented constructs; classes, objects, and rela-
tionships between classes. In this section, the entities of SpecDB that hold
object oriented constructs are explained.

Prompt Creating Table ’Classes’

Prompt Creating Table ’Objects’

Create Table Objects
(Object_Name Varchar2(240) Not Null
,Class_Name Varchar2(240) Not Null )

The Classes table holds the names of the classes, the rest of the in-
formation of the class are stores in their respective locations, with an
identifier pointing to their respective classes. For example, class variables,
methods and encapsulations rules are stored in the Var table, in Section
2.4.4 and either the Procedure or the Function Declaration tables respec-
tively, explained in Section 2.4.5. Relationships between classes, like inher-
itance, association, aggregation, etc, are stored in the Class Relationships
table. In the Class Relationships table, two classes from the Classes table
are referenced in Class Name1 and Class Name2. The relationship type
between those two classes is stored in the relationship attribute in the
Class Relationships table. This attribute has a list of valid values represent-
ing the types of relationships among classes, e.g. inheritance, encapsulation,
etc.

2.5. Conclusion 55

Fig. 2.14 Representing Object Oriented Classes and Objects in SpecDB

Prompt Creating Table ’Class_Relationships’

,Class_Name1 Varchar2(240) Not Null

,Relationship Varchar2(30) Not Null
,Class_Name2 Varchar2(240) Not Null)

2.5 Conclusion

Chapter 2 contains the design of SpecDB, a database designed to hold parts

of a software’s specification for the purpose of unit testing. Through the use
of SpecDB, automated tools can become more intelligent in generating and
testing programs, based on an understanding of what the software under
construction is supposed to do, by design. The database design of SpecDB
is scalable and thus, allows for any additions to accommodate more pro-
gramming constructs or requirements, new forms of input or output, etc., as
they evolve in the future. The motivation behind building SpecDB has been
expressed in Chapter 1, mainly to aid the process of automated intelligent
test case generation based on a machine-readable specifications. In order to
create these machine-readable specifications to allow for automated reason-

56 SpecDB: A Database Design for Software Specifications

ing, SpecDB was created. A scalable representation of the specification was

chosen for this task, namely the use of a database specification representa-
tion. The standard technique of representation for portions of the software
specifications to aid in the process of unit testing has been detailed in this
chapter. Each of the entities of the SpecDB design has been explained in
detail. Representing software specifications in this manner aids the pro-
cess of automated testing and automated code generation. In Chapter 3, a
translation algorithm is described, to translate formal specifications to the
SpecDB representation, showing how a formal software specification can be
automatically represented in SpecDB.
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

2.5. Conclusion 57

2.5.1 Other SpecDB Entities

The following SQL Scripts are for creating other SpecDB Entities:

Prompt Creating Table ’Actual_Input’

Create Table Actual_Input
(Ai_Ip# Number(7) Not Null
,Ai_Test_Case# Number(7) Not Null
,Ai_Category Varchar2(4)
,Ai_Db_Table Varchar2(20)
,Ai_Db_Field Varchar2(25)
,Ai_Db_Row# Integer
,Ai_Value Varchar2(240)
,Ai_Into_Var Varchar2(240)
,Ai_Gui_Window Varchar2(240)
,Ai_Gui_Component Varchar2(240)
,Ai_Type Varchar2(240)
,Ai_File_Name Varchar2(240))

Prompt Creating Table ’Pre_Post_Conditions’

,Condition_Num Number Not Null

,Pre_Post Varchar2(4))

Prompt Creating Table ’Actual_Output’

Create Table Actual_Output
(Ao_Op# Integer Not Null
,Ao_Test_Case# Integer Not Null
,Ao_Category Varchar2(240)
,Ao_Db_Table Varchar2(240)
,Ao_Change Varchar2(240)
,Ao_Field Varchar2(240)
,Ao_Row# Varchar2(240)
,Ao_Value Varchar2(240)
,Ao_From_Var Varchar2(240)
,Ao_Window Varchar2(240)
,Ao_Component Varchar2(240)
,Ao_Type Varchar2(240)
,Ao_Name Varchar2(240)

58 SpecDB: A Database Design for Software Specifications

,Ao_Text Varchar2(240)
,Ao_Destination Varchar2(240)
,Ao_User Varchar2(240)
,Ao_Role_Id Varchar2(240)
,Ao_Privilege_Id Varchar2(240)
,Ao_Database Varchar2(240)
,Ao_Savepoint Varchar2(240))

Prompt Creating Table ’Db_Test_Operation’

Create Table Db_Test_Operation
(Operation_Id Number Not Null)

Prompt Creating Table ’Test_Templates’

Create Table Test_Templates
(Db_Operation_Id Number Not Null
,Test_Template_Name Varchar2(30) Not Null)

Prompt Creating Table ’Expected_Output’

,Eo_Category Varchar2(240)
,Eo_Db_Table Varchar2(240)
,Eo_Change Varchar2(240)
,Eo_Field Varchar2(240)
,Eo_Row# Varchar2(240)
,Eo_Value Varchar2(240)
,Eo_From_Var Varchar2(240)
,Eo_Window Varchar2(240)
,Eo_Component Varchar2(240)
,Eo_Type Varchar2(240)
,Eo_Name Varchar2(240)
,Eo_Text Varchar2(240)
,Eo_Destination Varchar2(240)
,Eo_User Varchar2(240)
,Eo_Role_Id Varchar2(240)
,Eo_Privilege_Id Varchar2(240)
,Eo_Database Varchar2(240)
,Eo_Savepoint Varchar2(240))

2.5. Conclusion 59

Prompt Creating Table ’Attributes_Changed’

Create Table Attributes_Changed
(Db_Operation_Id Number Not Null
,Attribute Varchar2(30)
,Of_Table Varchar2(40))

Prompt Creating Table ’Host_Var’

Create Table Host_Var
(Db_Operation_Id Number Not Null
,Host_Var_Name Varchar2(30) Not Null
,Input_Output Varchar2(1)
,Direct_Indirect Varchar2(1)
,On_Attribute Varchar2(30)
,Of_Table Varchar2(40))

Prompt Creating Table ’Constants’

,String_Value Varchar2(240)
,Date_Value Date
,Time_Value Date)

Prompt Creating Table ’Expected_Input’

Create Table Expected_Input
(Ei_Ip# Number(7) Not Null
,Ei_Test_Case# Number(7) Not Null
,Ei_Category Varchar2(4)
,Ei_Db_Table Varchar2(20)
,Ei_Db_Field Varchar2(25)
,Ei_Db_Row# Integer
,Ei_Value Varchar2(240)
,Ei_Into_Var Varchar2(240)
,Ei_Gui_Window Varchar2(240)
,Ei_Gui_Component Varchar2(240)
,Ei_Type Varchar2(240)
,Ei_File_Name Varchar2(240))

60 SpecDB: A Database Design for Software Specifications

Prompt Creating Table ’Char_Equiv_Class’

Create Table Char_Equiv_Class
(Var_Name Varchar2(15) Not Null
,Range_From Varchar2(1) Not Null
,Range_To Varchar2(1) Not Null
,Equivalence_Class Integer Not Null)

Prompt Creating Table ’Equivalence_Class’

Create Table Equivalence_Class
(Db_Operation_Id Number Not Null
,Data_Group_Name Varchar2(240) Not Null
,Attribute_Name Varchar2(30)
,Int_Value Integer
,Real_Value Real
,Char_Value Varchar2(1)
,Text_Value Varchar2(100)
,Date_Value Date)

Prompt Creating Table ’Real_Equiv_Class’

,Range_From Real Not Null

,Range_To Real Not Null
,Equivalence_Class Integer Not Null)

Prompt Creating Table ’Data_Group_Values’

Create Table Data_Group_Values
(Db_Operation_Id Number Not Null
,Data_Group_Name Varchar2(240) Not Null
,Int_Value Integer
,Real_Value Real
,Char_Value Varchar2(1)
,Text_Value Varchar2(100)
,Date_Value Date)

Prompt Creating Table ’Int_Equiv_Class’

Create Table Int_Equiv_Class
(Var_Name Varchar2(15) Not Null
,Range_From Integer Not Null
,Range_To Integer Not Null

2.5. Conclusion 61

,Equivalence_Class Integer Not Null)

Prompt Creating Table ’Constraints’

Create Table Constraints
(Constraint_Name Number Not Null
,Constraint_Num Integer Not Null
,Constraint_Or_Assertion Varchar2(1)
,On_Field Varchar2(1) Default ’T’
,Field_Name Varchar2(240)
,Table_Name Varchar2(240)
,Db_Name Varchar2(240)
,Condition_Predicate_Pos_Num Integer
,Constraint_Clause_Pred_Num Number
,Db_Op_Tables_Id Integer
,Db_Operation_Num Integer
,Db_Operator_Id Number(2))

Prompt Creating Table ’Data_Group’

Create Table Data_Group
(Db_Operation_Id Number Not Null
,Data_Group_Name Varchar2(240) Not Null
,Attribute Varchar2(30) Not Null
Copyright © 2010. World Scientific Publishing Company. All rights reserved.

,Of_Table Varchar2(40)
,Probability Number)

Prompt Creating Table ’Table_Field_Description’

Create Table Table_Field_Description
(Has_Constraint_Restriction Varchar2(1) Default ’T’
,Table_Name Varchar2(240) Not Null
,Field_Name Varchar2(240) Not Null
,Field_Id Varchar2(240)
,Field_Type Varchar2(240)
,Is_Primary_Key Varchar2(1) Default ’T’
,Is_Unique Varchar2(1) Default ’T’
,Mandatory Varchar2(1) Default ’T’
,Length Integer
,Has_Lov_Restriction Varchar2(1) Default ’T’
,Has_Table_Restriction Varchar2(1) Default ’T’
,Has_Range_Restriction Varchar2(1) Default ’T’
,Num_Of_Constraint_Restriction Integer

62 SpecDB: A Database Design for Software Specifications

The Subtle Art of Not Giving a F*ck: A Counterintuitive Approach to Living a Good Life
From Everand
The Subtle Art of Not Giving a F*ck: A Counterintuitive Approach to Living a Good Life
Mark Manson
4/5 (6412)
Principles: Life and Work
From Everand
Principles: Life and Work
Ray Dalio
4/5 (640)
The Gifts of Imperfection: Let Go of Who You Think You're Supposed to Be and Embrace Who You Are
From Everand
The Gifts of Imperfection: Let Go of Who You Think You're Supposed to Be and Embrace Who You Are
Brené Brown
4/5 (1173)
Never Split the Difference: Negotiating As If Your Life Depended On It
From Everand
Never Split the Difference: Negotiating As If Your Life Depended On It
Chris Voss
4.5/5 (990)
The Glass Castle: A Memoir
From Everand
The Glass Castle: A Memoir
Jeannette Walls
4.5/5 (1851)
Grit: The Power of Passion and Perseverance
From Everand
Grit: The Power of Passion and Perseverance
Angela Duckworth
4/5 (650)
Sing, Unburied, Sing: A Novel
From Everand
Sing, Unburied, Sing: A Novel
Jesmyn Ward
4/5 (1267)
The Perks of Being a Wallflower
From Everand
The Perks of Being a Wallflower
Stephen Chbosky
4.5/5 (4101)
Her Body and Other Parties: Stories
From Everand
Her Body and Other Parties: Stories
Carmen Maria Machado
4/5 (887)
Shoe Dog: A Memoir by the Creator of Nike
From Everand
Shoe Dog: A Memoir by the Creator of Nike
Phil Knight
4.5/5 (627)
The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers
From Everand
The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers
Ben Horowitz
4.5/5 (361)
Hidden Figures: The American Dream and the Untold Story of the Black Women Mathematicians Who Helped Win the Space Race
From Everand
Hidden Figures: The American Dream and the Untold Story of the Black Women Mathematicians Who Helped Win the Space Race
Margot Lee Shetterly
4/5 (1015)
Steve Jobs
From Everand
Steve Jobs
Walter Isaacson
4.5/5 (1138)
Elon Musk: Tesla, SpaceX, and the Quest for a Fantastic Future
From Everand
Elon Musk: Tesla, SpaceX, and the Quest for a Fantastic Future
Ashlee Vance
4.5/5 (581)
The Emperor of All Maladies: A Biography of Cancer
From Everand
The Emperor of All Maladies: A Biography of Cancer
Siddhartha Mukherjee
4.5/5 (297)
A Man Called Ove: A Novel
From Everand
A Man Called Ove: A Novel
Fredrik Backman
4.5/5 (5143)
Angela's Ashes: A Memoir
From Everand
Angela's Ashes: A Memoir
Frank McCourt
4.5/5 (943)
The Yellow House: A Memoir (2019 National Book Award Winner)
From Everand
The Yellow House: A Memoir (2019 National Book Award Winner)
Sarah M. Broom
4/5 (100)
The Little Book of Hygge: Danish Secrets to Happy Living
From Everand
The Little Book of Hygge: Danish Secrets to Happy Living
Meik Wiking
3.5/5 (460)
Brooklyn: A Novel
From Everand
Brooklyn: A Novel
Colm Tóibín
3.5/5 (2126)
The Art of Racing in the Rain: A Novel
From Everand
The Art of Racing in the Rain: A Novel
Garth Stein
4/5 (4355)
Devil in the Grove: Thurgood Marshall, the Groveland Boys, and the Dawn of a New America
From Everand
Devil in the Grove: Thurgood Marshall, the Groveland Boys, and the Dawn of a New America
Gilbert King
4.5/5 (278)
The World Is Flat 3.0: A Brief History of the Twenty-first Century
From Everand
The World Is Flat 3.0: A Brief History of the Twenty-first Century
Thomas L. Friedman
3.5/5 (2289)
Yes Please
From Everand
Yes Please
Amy Poehler
4/5 (2001)
Bad Feminist: Essays
From Everand
Bad Feminist: Essays
Roxane Gay
4/5 (1087)
The Woman in Cabin 10
From Everand
The Woman in Cabin 10
Ruth Ware
3.5/5 (2786)
A Tree Grows in Brooklyn
From Everand
A Tree Grows in Brooklyn
Betty Smith
4.5/5 (2032)
The Outsider: A Novel
From Everand
The Outsider: A Novel
Stephen King
4/5 (2876)
Team of Rivals: The Political Genius of Abraham Lincoln
From Everand
Team of Rivals: The Political Genius of Abraham Lincoln
Doris Kearns Goodwin
4.5/5 (244)
A Heartbreaking Work Of Staggering Genius: A Memoir Based on a True Story
From Everand
A Heartbreaking Work Of Staggering Genius: A Memoir Based on a True Story
Dave Eggers
3.5/5 (233)
The Sympathizer: A Novel (Pulitzer Prize for Fiction)
From Everand
The Sympathizer: A Novel (Pulitzer Prize for Fiction)
Viet Thanh Nguyen
4.5/5 (141)
Wolf Hall: A Novel
From Everand
Wolf Hall: A Novel
Hilary Mantel
4/5 (4087)
On Fire: The (Burning) Case for a Green New Deal
From Everand
On Fire: The (Burning) Case for a Green New Deal
Naomi Klein
4/5 (78)
Fear: Trump in the White House
From Everand
Fear: Trump in the White House
Bob Woodward
3.5/5 (835)
Manhattan Beach: A Novel
From Everand
Manhattan Beach: A Novel
Jennifer Egan
3.5/5 (918)
John Adams
From Everand
John Adams
David McCullough
4.5/5 (2546)
Rise of ISIS: A Threat We Can't Ignore
From Everand
Rise of ISIS: A Threat We Can't Ignore
Jay Sekulow
3.5/5 (144)
The Light Between Oceans: A Novel
From Everand
The Light Between Oceans: A Novel
M.L. Stedman
4.5/5 (814)
The Unwinding: An Inner History of the New America
From Everand
The Unwinding: An Inner History of the New America
George Packer
4/5 (45)
Little Women
From Everand
Little Women
Louisa May Alcott
4.5/5 (2369)
The Constant Gardener: A Novel
From Everand
The Constant Gardener: A Novel
John le Carré
4/5 (278)
Quality Stage USPS
No ratings yet
Quality Stage USPS
15 pages
The Best Laptops For Programming in 2021
No ratings yet
The Best Laptops For Programming in 2021
8 pages
R03 IND560drive TM EN
No ratings yet
R03 IND560drive TM EN
40 pages
GEABtt GBJan 2011
No ratings yet
GEABtt GBJan 2011
13 pages
Files PoP Notes
No ratings yet
Files PoP Notes
26 pages
DJG201 2.1.0 Advanced Django Sample
No ratings yet
DJG201 2.1.0 Advanced Django Sample
219 pages
Resume (Rohit Thapliyal)
No ratings yet
Resume (Rohit Thapliyal)
2 pages
Software Using Licensing Keys
No ratings yet
Software Using Licensing Keys
3 pages
Quick Start Guide: HPE Apollo 4200
No ratings yet
Quick Start Guide: HPE Apollo 4200
1 page
Operating Systems: Simple/Basic Segmentation
No ratings yet
Operating Systems: Simple/Basic Segmentation
29 pages
(1) Đoàn Phước Miền, Phạm Thị Trúc Mai (2014) - Tài Liệu Giảng Dạy Môn Thiết Kế Và Lập Trình Web. Trường Đại Học Trà Vinh
No ratings yet
(1) Đoàn Phước Miền, Phạm Thị Trúc Mai (2014) - Tài Liệu Giảng Dạy Môn Thiết Kế Và Lập Trình Web. Trường Đại Học Trà Vinh
6 pages
Zoomba: A Micro-Language For Jvms .
No ratings yet
Zoomba: A Micro-Language For Jvms .
163 pages
L13 Clips Tut
No ratings yet
L13 Clips Tut
38 pages
Lab2 Rashid Habib Ullah Reg. No. 109
No ratings yet
Lab2 Rashid Habib Ullah Reg. No. 109
12 pages
CH5 PHP
No ratings yet
CH5 PHP
89 pages
Doc-20231217-Wa0003. 20231217 234608 0000
No ratings yet
Doc-20231217-Wa0003. 20231217 234608 0000
11 pages
APS Project
50% (2)
APS Project
40 pages
Lo 1
No ratings yet
Lo 1
65 pages
user-manual-RICOH-AFICIO MP 4500-E
No ratings yet
user-manual-RICOH-AFICIO MP 4500-E
2 pages
Web Design Course Starter Pack: HTML Tags Elements
No ratings yet
Web Design Course Starter Pack: HTML Tags Elements
11 pages
07-Interprocess Communication
No ratings yet
07-Interprocess Communication
14 pages
Chapter 3
No ratings yet
Chapter 3
14 pages
ESRIDevSummit2019 ArcGISEnterpriseSecurity GDBDesignBestPractices
No ratings yet
ESRIDevSummit2019 ArcGISEnterpriseSecurity GDBDesignBestPractices
91 pages
Prashant Sharma
No ratings yet
Prashant Sharma
6 pages
Evolution of Computer Mouse
No ratings yet
Evolution of Computer Mouse
21 pages
SELinux
No ratings yet
SELinux
2 pages
ANGULAR FRAMEWORK Final Question Bank
No ratings yet
ANGULAR FRAMEWORK Final Question Bank
4 pages
Sonoline G20: System Options Introduction
No ratings yet
Sonoline G20: System Options Introduction
6 pages
Basic Editing of Adobe Premiere Pro (2)
No ratings yet
Basic Editing of Adobe Premiere Pro (2)
19 pages
Session 10516 WebSphere Application Server Z - OS L2 Update
No ratings yet
Session 10516 WebSphere Application Server Z - OS L2 Update
32 pages