Abstract. Software frameworks impose constraints on how plugins may interact with them. Many of these constraints involve multiple objects, are temporal, and depend on runtime values. Additionally, they are difficult to specify because they are often extrinsic and may break behavioral subtyping. This work introduces relationships as an abstraction for specifying framework constraints in FUSION (Framework Usage SpecificatIONs), and it presents a formal description and implementation of a static analysis to find constraint violations in plugin code. We define three variants of this analysis: one is sound, one is complete, and a pragmatic variant that balances these tradeoffs. We prove soundness and completeness for the appropriate variants, and we show that the pragmatic variant can effectively check constraints from real-world programs. 1

The relationships between objects in an object-oriented program are an essential property of the program’s design and implementation. Two previous approaches to implement relationships with aspects were association aspects, an AspectJ-based language extension, and the relationship aspects library. While those approaches greatly ease software development, we believe that they are not general enough. For instance, the library approach only works for binary relationships, while the language extension does not allow for the association of primitive values or values from non-weavable classes. Hence, in this work we propose a generalized alternative implementation via a direct reduction to tracematches, a language feature for executing an advice after having matched a sequence of events. This new implementation scheme yields multiple benefits. Firstly, our implementation is more general than existing ones, avoiding most previous limitations. It also yields a new language construct, relational tracematches. We provide an efficient implementation based on the AspectBench Compiler, along with test cases and microbenchmarks. Our empirical studies showed that our implementation, when compared to previous approaches, uses a similar memory footprint with no leaking, but the generality of our approach does lead to some runtime overhead. We believe that our implementation can provide a solid foundation for future research.

Relationships have been an essential component of OO design since the 90s, yet mainstream OO languages still do not support first-class relationships. Most programs implement relationships in an ad-hoc fashion which results in unnecessarily complex code. We examine the requirements for a good first-class relationship abstraction and compare this with existing work. These requirements serve both as a specification and a progress metric for adding first-class relationships to OO languages.

Abstract. Relationships have been an essential component of OO design since the 90s and, although several groups have attempted to rectify this, mainstream OO languages still do not support first-class relationships. This requires programmers to implement relationships in an ad-hoc fashion which results in unnecessarily complex code. We have developed a new model for OO languages which presents relationships as the dominant mechanism for defining object-oriented behaviour. We believe that a language based on this model could bring the benefits of relationships to mainstream languages and allow better integration between OO systems and other paradigms such as relational databases. 1

Reasoning about object-oriented programs is difficult since such programs usually involve aliasing, and it is not easy to identify the ways objects can relate to each other and thus to confine a program’s heap. In this paper, we address this problem in the context of a relationship-based programming language. In relationship-based programming languages, relationships are first-class citizens and allow a precise description of inter-object relationships. Relationships enforce a modularization discipline that is closer to the natural modularity inherent to many problem domains and that yields, as a result, program heaps that are DAGs. We further describe a mechanism, member interposition, that leverages the new modularization discipline and supports encapsulation of fields of shared objects. We have implemented the described modularization discipline and the mechanism of member interposition in the context of Rumer, a relationship-based programming language with support for contract specifications. We discuss the implications of member interposition for the modular verification of object invariants with an example. Relationships and interposed members provide an alternative to ownership type systems.

Abstract. We discuss how relationships can be employed to embody role models at the programming language level. We show that member interposition, a mechanism that we introduced for the specification and verification of object collaborations, is particularly helpful for the description of the role-dependent properties of an object. 1

Object collaborations are at the core of all objectoriented programming, yet current class-based objectoriented programming languages do not provide an explicit construct to capture the relationships between objects. This paper reports on an empirical study that investigates the occurrence of object collaborations to assess the need of intrinsic support for relationships in a programming language. We introduce a categorization of possible forms of object collaborations and their corresponding implementation patterns when using a traditional class-based object-oriented language (Java) and analyze 25 Java programs (ranging from 4 to 6275 classes) with the Relationship Detector for Java (RelDJ) to identify occurrences of these patterns. The empirical results show that object collaborations are indeed a frequent phenomenon and reveal that collaborationrelated code does not remain encapsulated in a single class. These observations strongly support efforts to define language constructs to express object relationships: relationships allow the encapsulation of a frequently occurring phenomenon and increase program expressiveness. 1

Abstract. Relationships capture the interplay between classes in object-oriented programs, and various extensions of object-oriented programming languages allow the programmer to explicitly express relationships. This paper discusses how relationships facilitate the verification of multi-object invariants. We develop a visible states verification technique for Rumer, a relationship-based programming language, and demonstrate our technique on the Composite pattern. The verification technique leverages the “Matryoshka Principle ” embodied in the Rumer language: relationships impose a stratification of classes and relationships (with corresponding restrictions on writes to fields, the expression of invariants, and method invocations). The Matryoshka Principle guarantees the absence of transitive call-backs and restores a visible states semantics for multi-object invariants. As a consequence, the modular verification of multi-object invariants is possible. 1