Abstract. A way to write proof scores showing that distributed systems have invariant properties in algebraic specification languages is described, which has been devised through several case studies. The way makes it possible to divide a formula stating an invariant property under discussion into reasonably small ones, each of which is proved by writing proof scores individually. This relieves the load to reduce logical formulas and can decrease the number of subcases into which the case is split in case analysis.

Software components are today the most promising approach to dealing with the complexity and uneven quality of software systems. The design-using-components paradigm has been extremely successful in almost every engineering field, with its benefits of rapid, routine, reliable system construction. The central dilemma of software design using components is that component developers cannot know how their components will be used and so cannot describe component properties for an unknown, arbitrary situation; but if the component customer (system designer) must determine relevant properties of each component before using it, component-based development loses much of its appeal. In technical terms, component behavior depends on the operational profile the component sees when in place in a larger system; in turn, that profile depends both on system usage and the internal structure of the system, neither of which can be known to the component developer.

TACCLE tests an automated assembly system in which the expected outcomes cannot be precisely defined and the actual results cannot be directly observed. F rom 30 % to 50 % of the resources in an average software project are typically allotted to testing. Still, inadequate software testing costs industry $22 billion to $60 billion per year in the U.S. alone [8]. We would all spend less if software engineers could use more effective testing methods and automated testing tools. On the other hand, testing is very difficult in real-world projects. Software testing is commonly accomplished by defining the test objectives, selecting and executing test cases, and checking results [2]. Although many studies have concentrated on the selection of test cases, checking test results is not trivial. Two problems are often encountered: How to determine success or failure. A test oracle [11] is the mechanism for specifying the expected outcome of software under test, allowing testers to check whether the actual result has succeeded or failed. 1 In theory, test oracles can be determined by the software specification. In practice, however, a specification may provide only high-level descriptions of the system and cannot possibly include all implementation details. Hence, software testers must also rely on domain knowledge and user judgment to evaluate results. Such manual efforts are often error prone [9].

Modern programs make extensive use of reusable software libraries. For example, a study of a number of large Java applications shows that between 17 % and 30 % of the classes in those applications use container classes defined in the java.util package. Given this extensive code reuse in Java programs, it is important for the interfaces of reusable classes to be well documented. An interface is well documented if it satisfies the following requirements: (1) the documentation completely describes how to use the interface; (2) the documentation is clear; (3) the documentation is unambiguous; and (4) any deviation between the documentation and the code is machine detectable. Unfortunately, documentation in natural language, which is the norm, does not satisfy the above requirements. Formal specifications can satisfy them but they are difficult to develop, requiring significant effort on the part of programmers. To address the practical difficulties with formal specifications, we describe and evaluate a tool to help programmers write and debug algebraic specifications. Given an algebraic specification of a class, our interpreter generates a prototype which can be used within an application just like any regular Java class. When running an application that uses the prototype, the interpreter prints error messages that tell the developer in which way the specification is incomplete or inconsistent with a hand-coded implementation of the class. We use case studies to demonstrate the usefulness of our system.

The aim of the open distributed processing (ODP) information viewpoint is to describe the semantics of the information and of the information processing in a system, from a global point of view, without having to worry about other considerations, such as how the information will be finally distributed or implemented or the technology used to achieve such implementation. Although several notations have been proposed to model this ODP viewpoint, they are not expressive enough to faithfully represent all the information concepts, or they tend to suffer from a lack of (formal) support, or both. In this paper, we explore the use of Maude as a formal notation for writing ODP information specifications. Maude is an executable rewriting logic language especially well suited for the specification of object-oriented open and distributed systems. We show how Maude offers a simple, natural, and accurate way of modeling the ODP information viewpoint concepts, allows the execution of the specifications produced, and offers good tool support for reasoning about them.

Composition of software elements into assemblies (systems) is a fundamental aspect of software development. It is an important strength of formal mathematical specification that the descriptions of elements can be precisely composed into the descriptions of assemblies. Testing, on the other hand, is usually thought to be “non-compositional. ” Testing provides information about any executable software element, but testing descriptions have not been combined to describe assemblies of elements. The underlying reason for the compositional deficiency of testing is that tests are samples. When two elements are composed, the input samples (test points) for the first lead to an output sample, but it does not match the input test points of the second, following element. The current interest in software components and component-based software development (CBSD) provides an ideal context for investigating elements and assemblies. In CBSD, the elements (components) are analyzed without knowledge of the system(s) to be later assembled. A fundamental testing theory of component composition must use measured component properties (test results) to predict system properties. This paper proposes a testing-based theory of software component composition based on subdomains. It shows how to combine subdomain tests of components into testing predictions for arbitrarily complex assemblies formed by sequence, conditional, and iteration constructions. The basic construction of the theory applies to functional behavior, but the theory can also predict system non-functional properties from component subdomain tests. Compared to the alternative of actually building and testing a system, the theoretical predictions are computationally more efficient. The theory can also be described as an exercise in modeling. Components are replaced by abstractions derived from testing them, and these models are manipulated to model system behavior.

Large-scale component-based software systems are becoming increasingly important. Building such a system requires more than just specifications for the overall system and its components. It is necessary to have a formal specification of how the components are composed to form the overall system. Furthermore, it is also necessary to have an explicit specification of the environment within which the system will be used. Finally, some mechanism must be available to make verification a tractable problem. To address all of these concerns, we suggest that component composition can be based on ontologies. An ontology is a shared understanding that allows individuals in a community to communicate. The increasing popularity of ontology-based computing has resulted in a rapid increase in the number of tools available for creating and for using ontologies. We suggest that leveraging these tools can improve the coverage and effectiveness of component composition compared with existing techniques. We also discuss a specific application domain that can be used as a testbed for the use of ontology-based techniques to achieve dynamic reconfiguration performed at run-time without direct human interaction.

In this paper, we present strategies to transform software component specifications written in CafeOBJ into Web Ontology Language (OWL), such that a proven software specification written in CafeOBJ can be searched on the internet using the semantic web technology, which allows web resources to be searched by their semantic meanings rather than just keywords. Key-Words: software specification, CafeOBJ, web ontology, semantic web 1

Inductive machine learning [1, 2] suggests an alternative approach to the algebraic specification of software systems [3]: rather than using test cases to validate an existing specification we use the test cases to induce a specification. In the algebraic setting test cases are ground equations that represent specific aspects of the desired system behavior or, in the case of negative test cases, represent specific behavior that is to be excluded from the system. Acceptable specifications must satisfy the positive test cases and must not satisfy the negative test cases. It is interesting to observe that in this alternative approach the burden of constructing a specification is placed on the machine. This leaves the system designer free to concentrate on the quality of the test cases for the desired system behavior. In addition, the induction process can be viewed as a coherence test for the test cases. For example, a failure of the system to induce a specification that satisfies all the (positive) test cases can be due to the fact that some of the test cases are contradictory. Inductive logic programming [4] and in particular inductive equational logic programming [5, 6] seem well suited for this task. In this framework the learning system is asked to search for an equational theory (hypothesis) H such that, H " B =E +, (1) and H " B #E $ , (2) where B is a possibly empty equational theory representing background knowledge, E + is the set of ground equations representing the positive test cases, and E- is the set of ground equations representing the negative test cases. Posterior sufficiency (1) states that the theory H ∪ B has to satisfy all the positive test cases and posterior satisfiability (2) states that none of the negative test cases can be a logical consequence of the induced theory together with the background. In addition, some other technical requirements such as prior satisfiability and prior necessity need to hold in order for this induction framework to make sense [4]. The following is a simple example that shows the induction of a stack specification from a set of positive test cases for the stack operations ‘top’, ‘push’, and ‘pop ’ [6]. They are given in the syntax of the OBJ3 specification language [3].

The Unified Modeling Language, UML, is the objectoriented notation adopted as the standard for objectoriented Analysis and Design by the Object Management Group. This paper reports on research to facilitate the formal revision of UML informal specifications. The approach is based on the algebraic specification formal theory, which is used to formalize the UML Statechart Diagrams and subsequently verify them. To illustrate the proposal, the so-called orthogonality property is investigated. This property is modeled at the UML metamodel level so that its fulfillment on the part of any particular UML Statechart diagram can be mathematically proven or disproven. The formal models obtained are specified in the executable formal language Maude thus providing the additional advantage of using them as functional prototypes. These results lead up to a whole formalization of the UML, which can be used in practice, and lay the foundations for the construction of rigorous UML CASE tools.