Abstract not found

Software architectures shift the focus of developers from lines-of-code to coarser-grained architectural elements and their overall interconnection structure. Architecture description languages (ADLs) have been proposed as modeling notations to support architecture-based development. There is, however, little consensus in the research community on what is an ADL, what aspects of an architecture should be modeled in an ADL, and which of several possible ADLs is best suited for a particular problem. Furthermore, the distinction is rarely made between ADLs on one hand and formal specification, module interconnection, simulation, and programming languages on the other. This paper attempts to provide an answer to these questions. It motivates and presents a definition and a classification framework for ADLs. The utility of the definition is demonstrated by using it to differentiate ADLs from other modeling notations. The framework is used to classify and compare several existing ADLs, enabling us in the process to identify key properties of ADLs. The comparison highlights areas where existing ADLs provide extensive support and those in which they are deficient, suggesting a research agenda for the future.

Abstract not found

Abstract not found

The majority of work carried out in the formal methods community throughout the last three decades has (for good reasons) been devoted to special languages designed to make it easier to experiment with mechanized formal methods such as theorem provers, proof checkers and model checkers. In this paper we will attempt to give convincing arguments for why we believe it is time for the formal methods community to shift some of its attention towards the analysis of programs written in modern programming languages. In keeping with this philosophy we have developed a verification and testing environment for Java, called Java PathFinder (JPF), which integrates model checking, program analysis and testing. Part of this work has consisted of building a new Java Virtual Machine that interprets Java bytecode. JPF uses state compression to handle big states, and partial order and symmetry reduction, slicing, abstraction, and runtime analysis techniques to reduce the state space. JPF has been applied to a real-time avionics operating system developed at Honeywell, illustrating an intricate error, and to a model of a spacecraft controller, illustrating the combination of abstraction, runtime analysis, and slicing with model checking.

This paper provides an overview of the STATEMATE system, constructed over the past several years by the authors and their colleagues at Ad Cad Ltd., the R&D subsidiary of i-Logix, Inc. STATEMATE is a set of tools, with a heavy graphical orientation, in- tended for the specification, analysis, design, and documentation of large and complex reactive systems, such as real-time embedded sys- tems, control and communication systems, and interactive software or hardware. It enables a user to prepare, analyze, and debug diagram- matic, yet precise, descriptions of the system under development from three interrelated points of view, capturing structure, functionality, and behavior. These views are represented by three graphical languages, the most intricate of which is the language of statecharts [4], used to depict reactive behavior over time. In addition to the use of statecharts, the main novelty of STATEMATE is in the fact that it "understands " the entire descriptions perfectly, to the point of being able to analyze them for crucial dynamic properties, to carry out rigorous ex- ecutions and simulations of the described system, and to create run- ning code automatically. These features are invaluable when it comes to the quality and reliability of the final outcome.

Requirements analysis includes a preliminary acquisition step where a global model for the specification of the system and its environment is elaborated. This model, called requirements model, involves concepts that are currently not supported by existing formal specification languages, such as goals to be achieved, agents to be assigned, alternatives to be negotiated, etc. The paper presents an approach to requirements acquisition which is driven by such higher-level concepts. Requirements models are acquired as instances of a conceptual meta-model. The latter can be represented as a graph where each node captures an abstraction such as, e.g., goal, action, agent, entity, or event, and where the edges capture semantic links between such abstractions. Well-formedness properties on nodes and links constrain their instances - that is, elements of requirements models. Requirements acquisition processes then correspond to particular ways of traversing the meta-model graph to acquire approp...

Abstract: We introduce the input-output automaton, a simple but powerful model of computation in asynchronous distributed networks. With this model we are able to construct modular, hierarchical correctness proofs for distributed algorithms. We de ne this model, and give aninteresting example of how itcan be used to construct such proofs. 1

Statecharts, popular for modelling system behavior in the structural analysis paradigm, are part of a fully executable language set for modelling object-oriented systems. The languages form the core of the emerging Unified Modelling Language.

While message sequence charts (MSCs) are widely used in industry to document the interworking of processes or objects, they are expressively weak, being based on the modest semantic notion of a partial ordering of events as defined, e.g., in the ITU standard. A highly expressive and rigorously defined MSC language is a must for serious, semantically meaningful tool support for use-cases and scenarios. It is also a prerequisite to addressing what we regard as one of the central problems in behavioral specification of systems: relating scenario-based inter-object specification to state-machine intra-object specification. This paper proposes an extension of MSCs, which we call live sequence charts (or LSCs), since our main extension deals with specifying "liveness", i.e., things that must occur. In fact, LSCs allow the distinction between possible and necessary behavior both globally, on the level of an entire chart and locally, when specifying events, conditions and progress over time within a chart. This makes it possible to specify forbidden scenarios, for example, and enables naturally specified structuring constructs such as subcharts, branching and iteration.