Implementing, validating, modifying, or reengineering an object-oriented system requires an understanding of the object and class interactions which occur as a program executes. This work seeks to identify, visualize, and analyze interactions in object-oriented program executions as a means for examining and understanding dynamic behavior. We have discovered recurring interaction scenarios in program executions that can be used as abstractions in the understanding process, and have developed a means for identifying these interaction patterns. Our visualizations focus on supporting design recovery, validation, and reengineering tasks, and can be applied to both object-oriented and procedural programs.

In a language like Smalltalk in which objects communicate only via message passing, message passing control is a fundamental tool for the analysis of object behavior (trace, spying) or for the definition of new semantics (asynchronous messages, proxy,...). Different techniques exist, from the well known approach based on the specialization of the doesNotUnderstand: method to the exploitation the method lookup algorithm done by the virtual machine. Until now no comparison between these techniques has been made. In this article we compare the different techniques taking into account the reflective aspects used, the scope, the limit and the cost of the control. Keywords: message passing control, instance specialization, doesNotUnderstand:, error handling, method compilation, anonymous class, minimal object 1 Message Passing Control: A need Message passing control is the corner stone of a broad range of applications from application analysis (trace[BH90, PWG93], interaction diagrams, cl...

. The decomposition of a software application into components and connectors at the design stage has been promoted as a way to describe and reason about complex software architectures. There is, however, surprisingly little language support for this decomposition at implementation level. Interaction relationships which are identified at design time are lost as they get spread out into the participating entities at implementation. In this paper, we propose first-class connectors in an object-oriented language as a first step towards making software architecture more explicit at implementation level. Our connectors are run-time entities which control the interaction of components and can express a rich repertoire of interaction relationships. We show how connectors can be reused and how they enhance the reuse of components. 1 Introduction In modeling software architectures Allen and Garlan distinguish between implementation relationships and interaction relationships of ...

A discontinuity exists between object-oriented modeling and programming languages. This discontinuity arises from ambiguous concepts in modeling languages and a lack of corresponding concepts in programming languages. It is particularly acute for binary class relationships -- association, aggregation, and composition. It hinders the traceability between software implementation and design, thus hampering software analysis. We propose consensual definitions of the binary class relationships with four minimal properties -- exclusivity, invocation site, lifetime, and multiplicity. We describe algorithms to detect automatically these properties in source code and apply these on several frameworks. Thus, we bridge the gap between implementation and design for the binary class relationships, easing software analysis.

The dynamic behavior of object-oriented programs is difficult to design, implement, and modify. Understanding the interactions between classes and objects is necessary to create efficient designs and make safe modifications. This work seeks to identify, visualize, and analyze recurring message patterns in object-oriented program executions as a means for understanding and examining dynamic behavior. Our visualizations focus on supporting design recovery, validation, and reengineering tasks. Keywords: software visualization, object-oriented programs, program understanding, software reengineering 1 Addressing Problems of OO Dynamics The importance of dynamic behavior in the design and implementation of object-oriented (OO) systems cannot be over-emphasized. Object-oriented analysis and design techniques (OOA/D) that evolve around object models created from static problem statements or object decomposition of real-world systems must not avoid the dynamic issues. Usage-scenario based a...

When do we call a software development environment a composition environment? A composition environment must be built of three parts: i) a reusable component library, ii) a component framework determining the software architecture, and iii) an open and flexible compositionl anguage. Most of the effort in component technology was spent on the first two parts. Now it is crucial to address the last part and find an appropriate model to glue existing components together. In this work, we investigate existing component and glue models, define a set of requirements a composition language must fulfill, and report our first results using a prototype implementation of a general-purpose composition language based on the #-calculus.

Abstract The separation of concerns is important to attain object oriented systems which can be easily evolved. This paper presents a reflective architecture which enforces the separation of concerns by allocating functional, interaction and synchronization code to different levels. A variant of collaborations (CO actions) is used to capture interactions between objects and avoids spreading the description of interactions among the participating objects. Functional and interaction code are also separated from synchronization code by means of metalevel components. Introducing changes into the reflective architecture to consider evolution needs is facilitated by the loose coupling of different concerns. Hence, changing a concern often consists of modifying only one component of the reflective architecture. The paper describes the reflective architecture in terms of a case study. The evolution of the reflective implementation of the case study is compared with the evolution of an alternative implementation and the benefits of the proposed architecture are shown by using an evolution metric. 1

Design patterns are becoming increasingly popular as a way to describe solutions to general design problems. However, the implementation of design patterns has received only little attention so far. Traditional object models do not provide explicit support for design patterns. This situation leads to problems: design patterns are lost during the implementation creating a gap between software design and the implementation, and the software engineer has to implement a large number of methods or classes with trivial behavior. In this paper, we present how the interaction first class entities of the FLO language that represent interaction among object support explicit representation of design patterns at the implementation level. ...

Abstract—Design patterns are important in object-oriented programming because they offer design motifs, elegant solutions to recurrent design problems, which improve the quality of software systems. Design motifs facilitate system maintenance by helping maintainers to understand design and implementation. However, after implementation, design motifs are spread throughout the source code and are thus not directly available to maintainers. We present DeMIMA, an approach to semiautomatically identify microarchitectures that are similar to design motifs in source code and to ensure the traceability of these microarchitectures between implementation and design. DeMIMA consists of three layers: two layers to recover an abstract model of the source code, including binary class relationships, and a third layer to identify design patterns in the abstract model. We apply DeMIMA to five open-source systems and, on average, we observe 34 percent precision for the 12 design motifs considered. Through the use of explanation-based constraint programming, DeMIMA ensures 100 percent recall on the five systems. We also apply DeMIMA on 33 industrial components. Index Terms—Maintenance traceability, design patterns, interclass relationships. Ç 1

The flo language integrates management of inter-object dependencies into the object oriented paradigms. In this paper, we focus on the use of reactive dependencies (links) in object-oriented knowledge representation.