engineering 1
INTRODUCTION
Software is the application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of software, i.e., the
application of engineering to software (IEEE Std 610.12). Specification and testing are
the hardest parts of software engineering.
Ideally, a specification provides a clear,
complete and correct description of aspects of a software product under development,
such as behavior, performance, interfaces, etc. Because the specification is the foundation
from which the software product is developed, it is important to be able to validate that
the specification describes the product intended by a client.
Many specification
languages are used in software engineering, but none is universal except natural language
(e.g., English). The specification is also used as the basis for testing the completed
product: the software tester develops test cases consisting of input (or stored) data values,
the invocation of product features, and the expected outcomes (results) from the feature
invocation. In order for the conclusions reached from product testing to be reliable, (1)
the specification must be precise, and (2) the tester must correctly formulate test cases
from the specification.
This research is motivated by the opportunity to connect the processes of software
specification and software testing in the following manner: during the specification
process, use testing to validate the specification; and use the specification to formulate
test cases. The benefits of this two-way approach include finding deficiencies in the
specification before the product is built, and to creating a good set of test cases to use
during product testing. Connecting the front-end process of specification with the back-
14
15
end process of software testing is a central idea behind model-based development and
model-based testing1 (Bertolino, 2007), and test-driven specification (Jones, Test-driven
specification: paradigm and automation, 2006). (See chapter 3 for a more detailed
discussion.)
1.1 Some History of Decision Tables
Decision tables have been used for over fifty years for logical specifications. They
were accepted as a tool in systems analysis (Ibramsha & Rjaraman, 1978) and for
program specification in the 1960s (King, 1968). Decision tables were used by
programmers, analysts, and other users of computer facilities because they provide a
simple tabular representation of complex decision logic. Although developed primarily as
a vehicle for man-to-man communications, decision tables can ease the problems of
programming and documentation in many applications where the feasibility of using the
traditional flowchart, narrative description, or other communications media is
questionable (Pooch, 1974). Some areas of application include:
Business analysis
Systems analysis and engineering
Decision science
Artificial Intelligence
The use of decision tables in a variety of fields has stimulated a market for
automated decision table tools. Two of the more popular tools, PrologA (Vanthienen &
1
Model based testing is a testing technique aimed at the automatic generation of tests using models extracted from the
software artifacts produce throughout the development process.
16
Dries, 1993) and LogicGem (Catalyst Development Corporation, 2006) are used in
decision science and artificial intelligence The use of decision tables by programmers,
analysts, and other users of computer facilities increased over the years because they
provide a simple tabular representation of complex decision logic (Pooch, 1974). Certain
properties of decision tables mesh well with software engineering (Hurley, 1983):
1. Decision tables provide a disciplined way to design the interaction of
conditions and actions in systems;
2. Decision tables provide a natural, concise and standardized notation for
system documentation, development, and maintenance.
3. Decision tables provide ways of checking for incompleteness, redundancy,
and inconsistency in designs.
1.2 Problem Statement
Although decision tables are intuitive and easy to read, they are difficult to create
manually. When computer supported construction is available, decision tables largely
outperform other conditional logic techniques (Vanthienen & 1993) Robben, .
Much of the resurgence is due to the existence of automated tools that facilitate
the creation of tables and that check the table for correctness. (A more detailed discussion
of correctness is given in chapter 2.)
Automated tools deliver to developers the
unmistakable strengths of decision tablespreciseness, conciseness, and ease of
comprehension (Pooch, 1974). Unfortunately, no single decision table tool provides the
set of integrated features proposed in this research.
17
The purpose of this research is to develop an open source integrated environment
that supports the creation and use of decision tables for software specification and modelbased testing. The integrated environment will contain the following tools:
Decision table editor (DTE) for creating and modifying decision tables.
Decision Table Analyzer (DTA) that performs test-driven dynamic analysis of the
completeness, clarity and correctness of a decision table.
Boundary test data generator (BTDGen) that automates the generation of test data
derived from the constraints specified in the decision table.
Combinatorial boundary test data generator (ComboBT) that minimizes the size
of the test data sets generated by BTDGen.
1.3 Research Approach
The decision-based software specification and verification environment
(DBSSVE) will be developed using the Java programming language that supports
platform independence. Several of the existing tools to be integrated into DBSSVE have
already been developed in Java. The NetBeans IDE 6.9.1 is the development platform.
The specific approach taken for this research includes meeting the following
objectives:
1. Reengineer an existing decision table editor written in C++ into Java (DTE).
Implement static checking to:
Enforce meta-data usage restrictions
Prohibit the creation of complex conditions
18
Prohibit the creation of condition duals (e.g., duplicate, negated or
equivalent conditions)
Prohibit the specification of duplicate actions and rules
Flag partially defined computation rules (e.g., once rules have been
added, adding a new condition (action) to the table requires updating
all existing rules to incorporate the newly added condition (action)).
2. Reengineer the existing decision table analyzer into Java, DTA.
3. Identify and remove defects in the legacy tools.
4. Integrate DTA, ComboBT, BTDGen and DTA.
5. Validate that each integrated tool retains its standalone functionality.
6. Verify that true integration has occurred, i.e., that a user can navigate
seamlessly between the component tools.
Software testing is the main technique used to verify that these objectives have
been met. Project deliverables include complete documentation of test plans, data, results
and bug reports.
19
1.4 Contribution
The first contribution of the Decision-Based Software Specification and
Verification Environment (DBSSVE) is to integrate research tools developed by former
thesis students into an integrated environment that supports the creation and analysis of
decision table specifications, and the automated generation of test data. It is expected that
future research projects will evolve DBSSVE. DBSSVE provides the CIS Department an
important tool for teaching students about lightweight formal specifications, critical
thinking about issues of specification correctness, and concepts of software testing.
Various features of DBSSVE can be introduced in a number of courses in the curriculum,
from introductory programming, computing theory, to the capstone course.
Several features of DBSSVE are unique. DTE supports strong typing of decision
table variables, by which table semantics can be enforced. The approach to automated
boundary test generation is novel. Finally, DBSSVE is extendible to other logic-based
specifications such as pre- and post-condition specifications.
20
Figure 1 Decision Based Software Specification and Verification Environment
1.5 Thesis Organization
Chapter 2 includes the background, chapter 3 related works in the areas of
decision tables, boundary testing, and model-based testing, chapter 4 discusses the
detailed design of the integrated environment. Chapter 5 includes a test plan which assists
in the evaluation of DBSSVE, chapter 6 validates the results and chapter 7 discusses
future work.