[tag] My homework too- ADL Analysis and Observations

This document describes some conventions that are used in the Assertion Definition Language Translation (ADLT) system, as described in the ADLT User Guide^[1]. The purpose of this document is to describe some potential conventions that could be adopted by the OASIS Test Assertion Group in the specification of Test Assertions.

References

ADLT Users Guide version 2.0, © The Open Group 1995-2007
ADL Frequently Asked Questions, © The Open Group 1995-2007
The Assertion Based Testing Tool for OOP: ADL2, Masaharu Obayashi - Hiroshi Kubota - Shane P. McCarron - Lionel Mallet, © 1998 (ICSE'98 Conference, Kyoto)

Introduction

ADLT is touted as a Test Development Tool. It is a system comprised of a translator, and a Specification Language (ADL) that is used to specify an encoded version of a specification. This system generates Tests and Test Descriptions as a product of the translator.

In my opinion, ADL was not designed to be a comprehensive formal language for assertion specification, but rather, a means toward the end of automated generation of Black Box and Functional Testing (as well as NL generation of documentation). Still, there are a number of design-decisions/conventions chosen for the formal-language used in assertion specification for practical reasons.

The interesting portion of this body of work (for the OASIS TAG group) is the ADL language used to formally describe a specification and its assertions. Conventions used to describe testable assertions, environment pre-conditions, and environment post-conditions in ADL should be considered for potential adoption in the TAG document.

As I am not an expert in ADL (and have never used the system myself), my evaluation here should be considered as a simple analysis appropriately.

Anatomy of ADL Specification Language

An ADL encoded specification is broken into modules that typically align with source modules in many programming languages (eg. Class constructs in Java/C++, a source file in C).
For each ADL module, a designer specifies:

ADL Module Name
a series of function declarations

An ADL function is specified by a name and signature, which eactly aligns to a method/function under test in an implementation (aka function under test). Each ADL function consists of:

Semantics (encoding of the outcome behavior, both expected and abnormal)
Assertions (encoded, atomic descriptions of normal and abnormal behavior)

In general, an ADL assertion is a boolean expression that describes the state of the system immediately after the function under test executes. These boolean expressions can be static, or somehow computed from the call-state (value of an expression before the function under test is executed.

ADL assertion expressions use operators to describe the behavioral relationship within an assertion:

Implication Operators
- -->
  (X --> Y means X implies Y
  (or if X is TRUE, Y must be TRUE))
- <--
  (X <-- Y means Y implies X
  (or if Y is TRUE, X must be TRUE))
- <->
  (X <-> Y means X implies Y AND Y implies X
  (or if X is TRUE, Y must be TRUE AND if Y is TRUE, X must be TRUE ))
Exception Operator ( <:> )
Specifies conditions that should be TRUE if an exception occurrs
Unary Operators
- @() call state operator
  (eg. @(X) evaluates to the value of X before the function is executed).
- unchanged() builtin function
  (eg. unchanged(X) returns TRUE if the value of X is identical before and after the function call).

Some observations, conventions, and applicability to TAG

Granularity and Grouping of Assertions

The ADL language specifies a hierarchy of items with the largest of granularity being the module. This does not specifically match the granularity of what TAG is trying to specify, which is the assertion itself.

The interesting thing about ADL is that it can provide interesting classifications of assertion characterizations by considering a larger granularity (and grouping of assertions). For example, consider how ADL groups assertion-statements describing normal behavior and abnormal behavior.

Another consideration is the sequential grouping of assertions. There may be inherent logic of conditions specified in an assertion, based on the order and specification of previous assertions.

Assertions are codified as Boolean expressions

This is a relatively simple concept, and I believe this applies to TAG as well.

Implication Operators

ADL Expressions are typically constructed with an implications Operation (which determines Boolean value for the assertion). These are operations describing unique behavioral relationships from a perspective of codifying the assertion as a logical expression.

Extrapolating on this further, one could view TAG assertions as codified logical expressions. In this case, a TAG responsibility would be to define all logical relationships used to construct an assertion expression. This could be as simple as usual logic constructs (AND, OR, NOT), or could even go as far as complex assertions expressed as prolog (as was done in Sun JCKs). Hopefully, a TAG recommendation suggests the behavioral operators, and what is considered good-style (eg. what is 'Too Big' of an expression for a given assertion).

ADL 'Macros'

It looks like ADL allows macro binding of conditions, to simplify assertion expressions. This is related to grouping of expressions (see above). In the examples above, an ADL function contains a semantics block that binds conditional-expressions to the keywords normal and abnormal. (eg. expression (returnval ≥ 0) binds to normal, and (returnval < 0) binds to abnormal). These expressions are later used to qualify a set of assertions (eg. if (normal) { assert1, assert2, ...} ).

One could view this as a "language shortcut" to simplify assertions (eg. assert1 is really if ((returnval ≥ 0) AND (other assert1 expressions)) ...)

State specification (before execution, after execution)

This is a similar concept to specifying test preconditions and test postconditions. The interesting thing for ADL specified assertions is that "state specification" is more generalized such that an assertion's logical behavior is expressed as a (potential) relationship of pre and post conditional states (rather than singly describing pre and post conditions outside of a specified test behavior).

tag message

ADL Conventions that can

be adopted by OASIS TAG

Table of Contents