In this paper, we specify an open problem: predictable component assembly, and state a position on compositional reasoning techniques that we believe are necessary for this purpose. 1 A Rhetorical Question? Yes, naturally, the question in the title is meant to be rhetorical. However, by formality I do not mean that which is exemplified by existing formal methods. Rather, I mean the use of a priori reasoning, instead of the prevalent a posteriori reasoning used for verification-based software construction. 2 What is A Priori Reasoning? Verification-based methods take the `posit-and-see' approach: given the specification for a program, first posit a program, then see if the program is correct (wrt to the given specification); similarly, to construct a specified composite, first posit the components and their composition, then see if their composition meets the given specification. This is what I call a posteriori reasoning: reasoning about correctness (or other properties) takes place...

Frameworks are increasingly recognised as very useful components in the emerging paradigm of component-based software development (CBD). They are widely accepted as better units of reuse than objects. The CBD methodology Catalysis, for instance, uses frameworks. However, at present, Catalysis frameworks are described only informally, which means we cannot reason formally about frameworks, in particular their composition, and thereby their reuse. For this we would need to specify frameworks (and their composition) formally. In this paper, we describe our approach for doing so. 1. Introduction In Object-oriented Design (OOD), a framework is a group of (interacting) objects. For example, in the CBD (Component-based Development) methodology Catalysis [5], a driver may be represented as the framework: Driver Car Person drives A driver is a person who drives a car, or in Object-oriented Design (OOD) terminology, a driver is a framework composed of a car object and a person object, lin...

There is a general consensus that the paradigm shift to component-based software development should be accompanied by a corresponding paradigm shift in the underlying approach to specification and reasoning. Work in modular specification and verification has shown the way, and following its lead, in this position paper, we outline our approach to specifying and reasoning about components, which uses a novel notion of correctness. 1 What is this paper about? As the title suggests, this paper is about an approach to formal specification of software components. The purpose of such an approach is to allow formal reasoning about components. The ultimate goal of Component-based Software Development (CBD) is third-party assembly. To achieve this, it is necessary to be able to specify components in such a way that we can reason about their construction and composition, and correctness thereof, a priori. Work in modular specification and verification, e.g. [9, 14] has shown the way, and our approach follows its lead. However, our approach is novel and hence different in the way we define correctness. In this paper, we will discuss how we specify components, and in particular how we define and reason about correctness, and why this is useful for CBD. 2 Specifying Components Ideally components should be black boxes, in order that users can (re)use them without knowing the details of their innards. In other words, the interface of a component should provide all the information that users need. Moreover, this information should be the only information that they need. Consequently, the interface of a component should be the

Abstract. We believe that the paradigm shift to component-based software development should be accompanied by a corresponding paradigm shift in the underlying approach to specification and reasoning. In this position paper, we propose a priori reasoning as a suitable candidate, and outline our approach to specifying and reasoning about components, based on a priori reasoning. 1

To date Logic Programming has not made any impact on Software Engineering. As Software Engineering moves on from objects to components, will Logic Programming be simply forgotten forever? In this position paper, I will argue that the answer could be and should be, perhaps surprisingly, negative. 1 Introduction In the mainstream of the field of Software Engineering, the imperative paradigm (in particular, the object-oriented paradigm) dominates. C/C++ and now Java are the only game in town. Declarative paradigms may be acknowledged by software engineers as elegant and nice in theory, but in practice these paradigms don't get a look in. CASE tools based on functional or logic programming? In your dreams! Does this mean that Logic Programming will forever be irrelevant to Software Engineering? I believe and hope not. In this position paper, I will try and explain why I think (and hope) so. The reason for my belief (and optimism) lies in the so-called Industrial Revolution for Informa...

Components must be trustworthy if they are worth deploying at all. In this position paper, we identify some ingredients that we think are essential for enabling components to be trustworthy.

. The Herbrand model H of a denite logic program P is an initial model among the class of all the models of P , interpreting P as an initial theory. Such a theory (program) proves (computes) only positive literals (atoms) in P , so it does not deal with negation. In this paper, we introduce isoinitial semantics for logic programs and show that it can provide a rich semantics for logic programs, which can deal with not just negation, but also incomplete information, parametricity and compositionality. We dedicate this paper to the memory of the originator of isoinitial semantics: Pierangelo Miglioli (1946-1999). 1 Introduction The intended model of a denite logic program P is its Herbrand model H . It interprets P under the Closed World Assumption [16]. Among the class of all the models of P , H interprets P as an initial theory [9]. A distinguishing feature of an initial theory P is that, in general, it proves (computes) only positive literals in P , so it does not deal wi...

Our general goal is to provide a semantic foundation for the specification of concurrent and distributed object systems. We use Troll, a formal object-oriented language, for system specification. It is now widely accepted that object classes are unsuitable modularisation units when it comes to dealing with very large systems. An intermediate concept between the system and the objects is needed for allowing reusability of specifications and providing a clearer system structure. Enriching Troll with a module concept forces us to develop new theoretical constructs ensuring an appropriate underpinning of the language. We propose a module logic Mdtl for specifying and reasoning about the dynamic aspects of distributed and modular object systems. The main features of the logic include the ability to express module interaction and internal module concurrency. In this paper, we present the syntax and model-theoretic semantics of the module logic Mdtl. The logic is illustrated and...