The Unified Modeling Language UML is a language for specifying, visualizing and documenting object-oriented systems. UML combines the concepts of OOA/OOD, OMT and OOSE and is intended as a standard in the domain of object-oriented analysis and design. Due to the missing formal, mathematical foundation of UML the syntax and the semantics of a number of UML constructs are not precisely defined.

A new visual notation is proposed for precisely expressing constraints on object-oriented models, as an alternative to mathematical logic notation used in methods such as Syntropy and Catalysis. The notation is potentially intuitive, expressive, integrates well with existing visual notations, and has a clear and unambiguous semantics. It is reminiscent of informal diagrams used by mathematicians for illustrating relations, and borrows much from Venn diagrams. It may be viewed as a generalization of instance diagrams.

A notion of object ownership is introduced as a solution to difficult problems of specifying and reasoning about complex linked structures and of modeling aggregates (composite objects). Syntax and semantics are provided for extending Eiffel with language support for object ownership annotation and checking. The ideas also apply to other OOPLs such as C++. 1. Overview In section 2, we analyse the requirements of a mechanism for implementing the components of an aggregation or composite object, and we evaluate the extent to which the techniques of inheritance, expanded type attributes, reference type attributes and selective export satisfy these requirements. We restrict consideration to examples of composite objects from the solution (programming) domain. In section 3, we propose the use of reference type attributes with ownership properties to implement components and propose a syntax and semantics for object ownership. Section 4 shows how object ownership can be used in the natural modelling of aggregation structures identified in the problem domain. Section 5 discusses related work and section 6 concludes with a summary of contributions and issues for further investigation. 1.1 Terminology We adopt the Eiffel terminology for OO systems [Meyer 88,92] throughout this article.

Building software from components, rather than writing the code from scratch has several advantages, including reduced time to market and more efficient resource usage. However, component based development without consideration of all the risks and limitations involved may give unpredictable results, such as the failure of a system when a component is used in an environment for which it was not originally designed. One of the basic problems when developing component-based systems is that it is difficult to keep track of components and their interrelationships. This is particularly problematic when upgrading components. One way to maintain control over upgrades is to use component identification and dependency analysis. These are well known techniques for managing system configurations during development, but are rarely applied in managing run-time dependencies. The main contribution of this thesis is to show how Configuration Management (CM) principles and methods can be app...

In current OO Design, most of the existing (semi-formal) methods use classes or objects as the basic unit of design. However, it is increasingly recognised that classes are not the best focus for design. Typical design artefacts are about groups of objects and the way they interact. In the Catalysis project, we use the term frameworks for descriptions of groups of objects, their relationships, division of responsibilities, and interactions. The power of frameworks lies in the fact that interactions can also occur at the level of frameworks. In a previous paper, we defined a framework formally as a (first-order) many-sorted theory with a modeltheoretic semantics and showed how it can be represented using a pictorial notation for practical system development. However, we considered only frameworks that do not interact with one another. In this paper, we discuss frameworks that interact with one another, and show that such frameworks are very powerful tools for formal OO Design. 1 Introd...

. Seamlessness, reversibility, and software contracting have been proposed as important techniques to be supported by object-oriented methods. These techniques are used to provide a framework for the comparison of two modeling languages, the Business Object Notation (BON) and the Unified Modeling Language (UML). Elements of the UML and its constraint language that do not support these techniques are discussed. Suggestions for further improvements to both BON and UML are described. 1 Introduction ...There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. C.A.R. Hoare, Turing Award Lecture 1980 [7]. As described by Brooks [1], the key factor in producing quality software is specifying, designing and implementing the conceptual construct that underlies the program. This conceptual construct is usually complex and highly ...

. Current Object-oriented Design (OOD) methodologies tend to focus on objects as the unit of reuse, but it is increasingly recognised that frameworks, or groups of interacting objects, are a better unit of reuse. Thus, in next-generation Component-based Development (CBD) methodologies, we can expect components to be frameworks rather than objects. In this paper, we describe a preliminary attempt at a formal semantics for OOD frameworks in CBD in computational logic. 1 Introduction Most of the existing (semi-formal) Object-oriented Design (OOD) methods such as Fusion [4, 6] and Syntropy [5] use classes or objects as the basic unit of design or reuse. These methods are based on the traditional view of an object, as shown in Figure 1, which regards an object as a closed entity with one fixed role. visible functions structure internal encapsulated Fig. 1. Traditional view of an object. This, however, does not reflect the nature of objects (and classes that describe them) in practical syst...

This paper proposes a revised semantic interpretation of UML Statechart Diagrams which ensures, under the specified design rules, that Statecharts may be constructed to have true compositional properties. In particular, hierarchical state machines may be properly encapsulated to allow independent verification and compositional testing, something which is not possible under the current UML semantics. Certain problems regarding the formal tractability of UML Satechart Diagrams are addressed, such as the confusion over states and connectors, the flattening effect of boundary-crossing transitions, and the consequences of inverting the inter-level priority rule for handling concurrent events. A set-theoretic formal treatment of object states, events, guards and run-tocompletion processing is given, describing both serial and concurrent Statecharts. 1

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...

This paper presents a formal axiomaticsemantics for the essential model notations of Syntropy,where an essential model provides a step towards the speci#cation of an object-oriented system. Syntropy likeother objectoriented developmentmethods uses intuitiveand easy to understand graphical notations for expressingthestatic and dynamic aspectsofthemodel. However, Syntropy di#ers from other methods bythe use of mathematical notations to annotatethe graphical notations andby the use of event broadcastingtoabstract from message passingbetween objects. The lack of complete formality in Syntropy preventstheevaluation of completeness and consistency of itsmodels. Thesemantics is expressed in the speci#cation language the LarchShared Language. The formalisation of the essential model contributes toamathematical basis for reasoningusingthetools provided by Larch, and isavaluable aid for developing support tools for the method. The formalisation can be extended quite easily to provideasemantics...