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.

A discontinuity exists between modeling and object-oriented programming languages. This discontinuity is a consequence of ambiguous notions in modeling languages and lack of corresponding notions in object-oriented programming languages. It hinders the transition between software implementation and design and hampers software maintenance. This discontinuity is particularly acute for binary class relationships, such as the association, aggregation, and composition relationships. We present a solution to bridge the discontinuity between implementation and design for the binary class relationships: we propose consensual definitions of the binary class relationships in terms of four properties (exclusivity, invocation site, lifetime, multiplicity). We describe algorithms to detect these properties in Java source code.

Design patterns ease the designing, understanding, and re-engineering of software. Achieving a well-designed piece of software requires a deep understanding and a good practice of design patterns. Understanding existing software relies on the ability to identify architectural forms resulting from the implementation of design patterns. Maintaining software involves spotting places that can be improved by using better design decisions, like those advocated by design patterns. Nevertheless, there is a lack of tools automatizing the use of design patterns to achieve well-designed pieces of software, to identify recurrent architectural forms, and to maintain software. We present a set of tools and techniques to help OO software practitioners design, understand, and re-engineer a piece of software using design-patterns. A first prototype tool, PATTERNS-BOX, provides assistance in designing the architecture of a new piece of software, while a second prototype tool, PTIDEJ, identifies design patterns used in an existing one. These tools, in combination, support maintenance by highlighting defects in an existing design, and by suggesting and applying corrections based on widely-accepted design pattern solutions.