P-MARt: Pattern-like Micro Architecture Repository Yann-Ga¨el Gu´eh´eneuc D´epartement d’informatique et de recherche op´erationnelle Universit´e de Montr´eal – CP 6128 succ. Centre Ville Montr´eal, Qu´ebec, Canada, H3C 3J7 guehene@iro.umontreal.ca Abstract We introduce P-MARt, a repository of pattern-like micro-architetcures. The purpose of P-MARt is to serve as baseline to assess the precision and recall of pattern identification tools. Indeed, several approaches have been proposed to identify occurrences of design patterns, yet few have been independently validated for precision and recall for lack of known occurrences. We hope that P-MARt can be shared and enriched by re- searchers interested in design pattern identification. 1 Context Maintainers must be aware of design choices in order to modify an object-oriented software system. Design choices include decisions made by developers when de- signing and implementing the system: the structures of classes and the relationships among them. However, design choices are often scattered in the source code of systems after implementation because, with available object-oriented programming languages, they do not transcribe directly into source code; developers must write several lines of code to implement their choices. Moreover, documentation is often obsolete, if it even exists, and these choices are thus lost. However, design choices are often implemented with recurring patterns, “a form or model proposed for imi- tation” [9], to facilitate writing and understanding the source code. Idioms and design patterns are two types of patterns; architectural patterns and micro-patterns are others. Idioms are low-level patterns specific to some programming languages and to the implemen- tation of particular characteristics of classes or their relationships. They are intra-class patterns describing typical implementation of, for example, relationships, object containment, and collection traversal. Design patterns [5] are recurring inter-class patterns that de- fine solutions to common design problems in the or- ganisation of classes. They are “tactics” that generate the structure and behaviour of classes and their rela- tionships [2]. They influence the design of modules and classes but not the overall architecture. They are de- fined in terms of classes and relationships; thus their implementation uses idioms. Developers search for some kinds of patterns in order to understand a system [10]; by recognising concrete manifestations of these patterns, they deduce from their experience choices underlying the presence of pat- terns in the source code. During maintenance and evo- lution, maintainers would greatly benefit by knowing the design choices made during implementation, see for example [11]. Therefore, several researchers have proposed tools to identify occurrences of patterns in object-oriented systems. Design patterns have been of much interest since Wuyts’ precursor work [11]. 2 Vocabulary We use the term motif to express the solution of a pattern as “a reliable sample of traits, acts, tendencies, or other observable characteristics” [9] of a pattern. We distinguish between patterns and motifs because pat- terns encompass information that is not readily avail- able for their identification. For example, the Compos- ite design pattern [5, p.163] also includes information about its intent, motivation, applicability, and conse- quences, which are not observable characteristics. Only its structure, its participants, and their collaborations are observable in the source code. Thus, strictly speak- ing, we cannot use the terms design pattern “identifi- cation”, “detection”, or “instantiation” but rather the instantiation and identification of micro-architectures similar to some motifs; thus, we use the term “design motif identification” for the process traditionally called design pattern identification. We define the term micro-architectures (μA) as con- 1