JML is a behavioral interface specification language tailored to Java(TM). Besides pre- and postconditions, it also allows assertions to be intermixed with Java code; these aid verification and debugging. JML is designed to be used by working software engineers; to do this it follows Eiffel in using Java expressions in assertions. JML combines this idea from Eiffel with the model-based approach to specifications, typified by VDM and Larch, which results in greater expressiveness. Other expressiveness advantages over Eiffel include quantifiers, specification-only variables, and frame conditions. This paper discusses the goals of JML, the overall approach, and describes the basic features of the language through examples. It is intended for readers who have some familiarity with both Java and behavioral specification using pre- and postconditions. Copyright c ○ 1998-2005 Iowa State University This paper is part of JML and is distributed under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. 1

JML is a behavioral interface specification language tailored to Java. It is designed to be written and read by working software engineers, and should require only modest mathematical training. It uses Eiffel-style syntax combined with model-based semantics, as in VDM and Larch. JML supports quantifiers, specification-only variables, and other enhancements that make it more expressive for specification than Eiffel and easier to use than VDM and Larch. JML [Leavens-Baker-Ruby00], which stands for "Java Modeling Language," is a behavioral interface specification language (BISL) [Wing87] designed to specify Java [Arnold-Gosling98] [GoslingJoy -Steele96] modules. Java modules are classes and interfaces. A behavioral interface specification describes both the details of a module's interface with clients, and its behavior from the client's point of view. Such specifications are not good for the specification of whole programs, but are good for recording detailed design decisions or do...

This article shines some light in the "four dark corners," exposing problems and proposing solutions. We show that all descriptions involved in requirements engineering should be descriptions of the environment. We show that certain control information is necessary for sound requirements engineering, and we explain the close association between domain knowledge and refinement of requirements. Together these conclusions explain the precise nature of requirements, specifications, and domain knowledge, as well as the precise nature of the relationships among them. They establish minimum standards for what information should be represented in a requirements language. They also make it possible to determine exactly what it means for requirements engineering to be successfully completed.

Partial specifications written in many different specification languages can be composed if they are all given semantm in the same domain, or alternatively, all translated into a common style of predicate logic The common semantic domain must be very general, the particular semantics assigned to each specification language must be conducive to composition, and there must be some means of communication that enables specifications to build on one another. The criteria for success are that a wide variety of specification languages should be accommodated, there should be no restrictions on where boundaries between languages can be placed, and intuitive expectations of the specifier should be met.

In 1990, Anthony Hall published a seminal article that listed and dispelled seven myths about the nature and application of formal methods. Today - five years and many successful applications later - formal methods remain one of the most contentious areas of software-engineering practice. Despite 25 years of use, few people understand exactly what formal methods are or how they are applied. Many nonformalists seem to believe that formal methods are merely an academic exercise -- a form of mental masturbation that has no relation to real-world problems. The media's portrayal of formal methods does little to help the situation. In many "popular press" science journals, formal methods are subjected to either deep criticism or, worse, extreme hyperbole. Fortunately, today these myths are held more by the public and the computer-science community at large than by system developers. It is our concern, however, that new myths are being propagated, and more alarmingly, are receiving a certain tacit acceptance from the system-development community. Following Hall's lead, we address and dispel seven new myths about formal methods: Formal methods delay the development process; formal methods lack tools; formal methods replace traditional engineering design methods; formal methods only apply to software; formal methods are unnecessary; formal methods are not supported; and formal-methods people always use formal methods.

The testing process is typically systematic in test data selection and test execution. For the most part, however, the effective use of test oracles has been neglected, even though they are a critical component of the testing process. Test oracles prescribe acceptable behavior for test execution. In the absence of judging test results with oracles, testing does not achieve its goal of revealing failures or assuring correct behavior in a practical manner; manual result checking is neither reliable nor cost-effective. We argue that test oracles should be derived from specifications and in conjunction with testing criteria, represented in a common form, and their use made integral to the testing process. For complex, reactive systems, oracles must reflect the multiparadigm nature of the required behavior. Such systems are often specified using multiple languages, each selected for its utility in specifying a particular computational paradigm. Thus, we are developing an approach for derivi...

This paper analyzes the root causes of safety-related software errors in safety-critical, embedded systems. The results show that software errors identifiedas potentially hazardous to the system tend to be produced by different error mechanisms than non-safety-related software errors. Safety-related software errors are shown to arise most commonly from (1) discrepancies between the documented requirements specifications and the requirements needed for correct functioning of the system and (2) misunderstandings of the software's interface with the rest of the system. The paper uses these results to identify methods by which requirements errors can be prevented. The goal is to reduce safety-related software errors and to enhance the safety of complex, embedded systems.

Empirical evaluation of software systems in actual usage situations is critical in software engineering. Prototyping, beta testing, and usability testing are widely used to refine system requirements, detect anomalous or unexpected system and user behavior, and to evaluate software usefulness and usability. The World Wide Web enables cheap, rapid, and large-scale distribution of software for evaluation purposes. However, current techniques for collecting usage data have not kept pace with the opportunities presented by Web-based deployment. This paper presents an approach and prototype system that makes large-scale collection of usage data over the Internet a practical possibility. A general framework for comparing software monitoring systems is presented and used to compare the proposed approach to existing techniques.

In this report we present the language TROLL . It is a language particularly suited to be used in the early stages of information system design where the problem domain or Universe of Discourse must be described. In TROLL , the description of the static and dynamic aspects of entities is integrated in object descriptions. TROLL is based on sublanguages for data terms, for first-order and temporal assertions and for processes. These sublanguages are the tools to describe static properties, behavior and evolution over time of objects. Object descriptions can be related in many ways. The abstraction mechanisms provided by TROLL are classification, specialization, generalization, roles, and aggregation. Abstraction mechanisms together with the basic structuring in objects help in organizing the system design. In order to support the composition of system descriptions from component description TROLL provides language features to state interactions and dependencies between components ...

Research issues related to requirements modeling are introduced and discussed through a review of the requirements modeling language RML, its peers and its successors from the time it was first proposed at the Sixth International Conference on Software Engineering (ICSE-6) to the present---ten ICSEs later. We note that the central theme of "Capturing More World Knowledge" in the original RML proposal is becoming increasingly important in Requirements Engineering. The paper highlights key ideas and research issues that have driven RML and its peers, evaluates them retrospectively in the context of experience and more recent developments, and points out significant remaining problems and directions for requirements modeling research. 1. Introduction "...Requirements definition is a careful assessment of the needs that a system is to fulfill. It must say why a system is needed, based on current and foreseen conditions, which may be internal operations or an external market. It must say wh...