• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
A Moose Slideshow
 

A Moose Slideshow

on

  • 3,322 views

 

Statistics

Views

Total Views
3,322
Views on SlideShare
2,412
Embed Views
910

Actions

Likes
2
Downloads
19
Comments
0

3 Embeds 910

http://moose.unibe.ch 908
http://192.168.10.100 1
http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    A Moose Slideshow A Moose Slideshow Presentation Transcript

    • A Moose Slideshow
    • fo rw g rin ar ee d in en ng gi ne ee er rs in ve g re { { { { { { } { { actual development } } } } } } } } {
    • built in Berne
    • built in Berne
    • used in several research groups > 100 men years of effort ~ 150 publications since 1997
    • is an analysis tool is a modeling platform is a visualization platform is a tool building platform is a collaboration
    • is an analysis tool is a modeling platform is a visualization platform is a tool building platform is a collaboration
    • s las odC McCabe = 21 #isG t: elec ss NOM = sse 0 cla 102 ,00 ... 3 75 = C LO { { { { } } } } } {
    • Metrics compress the system into numbers NOM NOC DUPLINES LOC NOCmts NAI TCC NOPA NOA WMC WLOC NI CYCLO WNOC ... ATFD WOC HNL MSG
    • Detection Strategies are metric-based queries to detect design flaws 6 scu 200 Marine Lanza,
    • Example: a God Class centralizes too much intelligence in the system Class uses directly more than a few attributes of other classes ATFD > FEW Functional complexity of the class is very high AND GodClass WMC ! VERY HIGH Class cohesion is low TCC < ONE THIRD 6 scu 200 Marine Lanza,
    • Polymetric views show up to 5 metrics Width metric Height metric Position metrics Color metric 03 0 Lanza 2
    • System Complexity shows class hierarchies 03 asse 20 uc anza, D L
    • Class Blueprint shows class internals 05 anza 20 L ucasse, D
    • Package Blueprint shows package usage tal 2007 ee Ducass
    • Distribution Map shows properties over structure tal 2006 ee Ducass
    • Semantic Clustering reveals implementation topics user, run, load, message, file, buffer, util property, AWT, edit, show, update, sp, set start, buffer, end, text, length, line, count action, box, component, event, button, layout, GUI start, length, integer, end, number, pre, count XML, dispatch, microstar, reader, XE, register, receive current, buffer, idx, review, archive, endr, TAR BSH, simple, invocation, assign, untype, general, arbitrary maximum, label, link, item, code, put, vector tal 2006 Kuhn e
    • Software Map gives software space a meaning tal 2008 Kuhn e
    • Softwarenaut explores the package structure 6 etal 200 Lungu
    • CodeCity shows where your code lives 7 nza 200 La Wettel,
    • Trace Signals reveal similar execution traces 06 eevy 20 r Kuhn, G
    • Feature Views show how features cover classes 6 etal 200 Greevy addPage addFolder
    • Feature Map shows relates features to code 7 etal 200 Greevy
    • Object Flow captures object aliases 9 00 nhard 2 Lie
    • Object Flow captures object aliases 9 00 nhard 2 Lie
    • Object Flow shows how objects move 7 etal 200 nhard Lie
    • Object Dependencies reveal features dependencies Open Join Channel Connect Send Message 7 etal 200 nhard Lie
    • Hierarchy Evolution reveals evolution patterns 5 etal 200 Girba
    • Evolution Radar shows co-change relationships za 2006 os, Lan D’Ambr
    • Ownership Map reveals patterns in CVS 6 etal 200 Girba
    • Kumpel shows how developers work on files 8 ker 200 Jun
    • Clone Evolution shows who copied from whom 6 etal 200 Balint
    • s las odC McCabe = 21 #isG t: elec ss NOM = sse 0 cla 102 ,00 ... 3 75 = C LO { { { { } } } } } {
    • is an analysis tool is a modeling platform is a visualization platform is a tool building platform is a collaboration
    • is an analysis tool is a modeling platform is a visualization platform is a tool building platform is a collaboration
    • FAMIX is a language independent meta-model Package Namespace packagedIn belongsTo * * superclass * Class Inheritance subclass * belongsTo belongsTo * * invokedBy * Invocation Method Attribute candidate * accessedIn accesses * * Access
    • FAMIX ... Class Method
    • Dynamix ... Instance Activation FAMIX ... Class Method
    • Dynamix ObjectFlow ... Instance Activation ... Alias FAMIX ... Class Method
    • Dynamix ObjectFlow ... Instance Activation ... Alias FAMIX ... Class Method Hismo Class Method ... History History
    • Dynamix ObjectFlow ... Instance Activation ... Alias FAMIX ... Class Method Subversion Hismo File File Class Method ... ... History Version History History
    • Dynamix ObjectFlow ... Instance Activation ... Alias CVS FAMIX File File ... ... Class Method History Version Subversion Hismo File File Class Method ... ... History Version History History
    • BugsLife Dynamix ObjectFlow ... Activity ... Instance Activation ... Alias Bug CVS FAMIX File File ... ... Class Method History Version Subversion Hismo File File Class Method ... ... History Version History History
    • BugsLife Dynamix ObjectFlow ... Activity ... Instance Activation ... Alias Bug CVS FAMIX Dude File File ... ... Class Method ... Duplication History Version Subversion Hismo File File Class Method ... ... History Version History History
    • BugsLife Dynamix ObjectFlow ... Activity ... Instance Activation ... Alias Bug CVS FAMIX Dude File File ... ... Class Method ... Duplication History Version Subversion Hismo ... File File Class Method ... ... ... History Version History History
    • BugsLife Dynamix ObjectFlow o...dels Alias ... Instance Activation -m eta y of m ... Activity Bug famil X is a FAMI FAMIX Core CVS Dude File File ... ... Class Method ... Duplication History Version Subversion Hismo ... File File Class Method ... ... ... History Version History History
    • FM3 is the meta-meta-model FM3.Element name: String fullName: String superclass opposite FM3.Package FM3.Class FM3.Property derived: Boolean keyed: Boolean multivalued: Boolean type extensions 08 20 rwaest e Kuhn, V
    • MSE is the exchange format (FAMIX.Class (id: 100) (name 'Server') (container (ref: 82)) (isAbstract false) (isInterface false) (package (ref: 624)) (stub false) (NOM 9) (WLOC 124)) (FAMIX.Method (id: 101) (name 'accept') (signature 'accept(Visitor v)') (parentClass (ref: 100)) (accessControl 'public') (hasClassScope false) (stub false) (LOC 7) 08 20 (CYCLO 3)) rwaest e Kuhn, V
    • is an analysis tool is a modeling platform is a visualization platform is a tool building platform is a collaboration
    • is an analysis tool is a modeling platform is a visualization platform is a tool building platform is a collaboration
    • Mondrian scripts graph visualizations view nodes: classes forEach: [ :each | view nodes: each methods. view gridLayout ]. view edgesFrom: #superclass. view treeLayout. 6 etal 200 Meyer
    • EyeSee scripts charts 7 tter 200 r, Hofste Junke
    • CodeCity scripts 3D visualizations 8 0 ettel 20 W
    • is an analysis tool is a modeling platform is a visualization platform is a tool building platform is a collaboration
    • is an analysis tool is a modeling platform is a visualization platform is a tool building platform is a collaboration
    • FAMIX Fame UI Mondrian EyeSee Repository
    • FAMIX Fame UI Mondrian EyeSee Repository MSE Smalltalk
    • FAMIX Fame UI Mondrian EyeSee Repository Java iPlasma MSE Smalltalk C++
    • FAMIX Fame UI Mondrian EyeSee Repository Java iPlasma MSE Smalltalk C++
    • Yellow Chronia CodeCity DynaMoose Hapax SmallDude Submarine FAMIX Fame UI Mondrian EyeSee Repository Java iPlasma MSE Smalltalk C++
    • CVS J-Wiretap MSE Source SVN Yellow Chronia CodeCity DynaMoose Hapax SmallDude Submarine FAMIX Fame UI Mondrian EyeSee Repository Java iPlasma MSE Smalltalk C++
    • CVS J-Wiretap MSE Source SVN ... Softwarenaut BugsLife Clustering Metanool Yellow Chronia CodeCity DynaMoose Hapax SmallDude Submarine FAMIX Fame UI Mondrian EyeSee Repository Java iPlasma MSE Smalltalk C++
    • CVS J-Wiretap MSE Source SVN ... Softwarenaut BugsLife Clustering Metanool Yellow Chronia CodeCity DynaMoose Hapax SmallDude Submarine FAMIX Fame UI Mondrian EyeSee Repository Java iPlasma MSE Smalltalk C++
    • is an analysis tool is a modeling platform is a visualization platform is a tool building platform is a collaboration
    • is an analysis tool is a modeling platform is a visualization platform is a tool building platform is a collaboration
    • Université Catholique de Louvain INRIA Lille Politehnica University of Timisoara University of Berne University of Lugano
    • Current Team Previous Team Stéphane Ducasse Serge Demeyer Tudor Gîrba Adrian Kuhn Michele Lanza Sander Tichelaar ears Contributors y en Previous m Current Contributors 100 > Tobias Aebi Michael Meer Hani Abdeen Jannik Laval Ilham Alloui Michael Meyer Philipp Bunge Adrian Lienhard Gabriela Arevalo Laura Ponisio Alexandre Bergel Mircea Lungu Mihai Balint Daniel Ratiu Frank Buchli Matthias Rieger Johan Brichau Oscar Nierstrasz Thomas Bühler Azadeh Razavizadeh Marco D’Ambros Damien Pollet Calogero Butera Andreas Schlapbach Simon Denier Jorge Ressia Daniel Frey Daniel Schweizer Georges Golomingi Mauricio Seeberger Orla Greevy Toon Verwaest David Gurtner Lukas Steiger Matthias Junker Richard Wettel Reinout Heeck Daniele Talerico Markus Hofstetter Herve Verjus Markus Kobel Violeta Voinescu Michael Locher Sara Sellos Martin von Löwis Lucas Streit Pietro Malorgio Roel Wuyts
    • is an analysis tool is a modeling platform is a visualization platform is a tool building platform is a collaboration
    • is an analysis tool is a modeling platform is a visualization platform ea id is a tool building platform an is is a collaboration
    • is an analysis tool is a modeling platform is a visualization platform ea id is a tool building platform an is is a collaboration
    • Semantic Clustering: Identifying Topics in Scripting Visualizations with Mondrian Test Blueprints — Exposing Side Effects in Source Code Execution Traces to Support Writing Unit Tests Michael Meyer and Tudor Gˆrba ı Software Composition Group, University of Berne, Switzerland Adrian Lienhard*, Tudor Gˆrba, Orla Greevy and Oscar Nierstrasz ı Adrian Kuhn a,1 St´phane Ducasse b,2 Tudor Gˆ a,1 Software Composition Group, University of Bern, Switzerland e ırba {lienhard, girba, greevy, oscar}@iam.unibe.ch Abstract 2 Mondrian by example a Software Composition Group, University of Berne, Switzerland b Language and Software Evolution Group, LISTIC, Universit´ de Savoie, France e Most visualization tools focus on a finite set of dedicated In this section we give a simple step-by-step example of Abstract Implementing a fixture and all the relevant assertions re- visualizations that are adjustable via a user-interface. In how to script a visualization using Mondrian. The example quired can be challenging if the code is the only source of this demo, we present Mondrian, a new visualization engine builds on a small model of a source code with 32 classes. Writing unit tests for legacy systems is a key maintenance information. One reason is that the gap between static struc- designed to minimize the time-to-solution. We achieve this The task we propose is to provide a on overview of the hi- task. When writing tests for object-oriented programs, ob- ture and runtime behavior is particularly large with object- by working directly on the underlying data, by making nest- Abstract erarchies. oriented programs. Side effects1 make program behavior jects need to be set up and the expected effects of executing ing an integral part of the model and by defining a powerful Creating a view and adding nodes. Suppose we can the unit under test need to be verified. If developers lack more difficult to predict. Often, encapsulation and complex scripting language that can be used to define visualizations. Many of the existing approaches in Software Comprehension focus on program pro- ask the model object for the classes. We can add those internal knowledge of a system, the task of writing tests is chains of method executions hide where side effects are pro- We support exploring data in an interactive way by provid- classes to a newly created view by creating a node for each gram structure or external documentation. However, by analyzing formal informa- non-trivial. To address this problem, we propose an ap- duced [2]. Developers usually resort to using debuggers to ing hooks for various events. Users can register actions for class, where each node is represented as a Rectangle. In the proach that exposes side effects detected in example runs of obtain detailed information about the side effects, but this tion the informal semantics contained in the vocabulary of source code are over- these events in the visualization script. case above, NOA, NOM and LOC are methods in the object the system and uses these side effects to guide the developer implies low level manual analysis that is tedious and time looked. To understand software as a whole, we need to enrich software analysis with representing a class and return the value of the correspond- when writing tests. We introduce a visualization called Test consuming [25]. the developer knowledge hidden in the code naming. This paper proposes the use ing metric. Blueprint, through which we identify what the required fix- Thus, the underlying research question of the work we of information retrieval to exploit linguistic information found in source code, such ture is and what assertions are needed to verify the correct present in this paper is: how can we support developers view := ViewRenderer new. as identifier names and comments. We introduce Semantic Clustering, a technique 1 Introduction behavior of a unit under test. The dynamic analysis tech- faced with the task of writing unit tests for unfamiliar legacy view newShape rectangle; based on Latent Semantic Indexing and clustering to group source artifacts that use width: #NOA; height: #NOM; linearColor: #LOC within: model classes; nique that underlies our approach is based on both tracing code? The approach we propose is based on analyzing run- withBorder. similar vocabulary. We call these groups semantic clusters and we interpret them method executions and on tracking the flow of objects at time executions of a program. Parts of a program execu- view nodes: model classes. view open. as linguistic topics that reveal the intention of the code. We compare the topics runtime. To demonstrate the usefulness of our approach we tion, selected by the developer, serve as examples for new Visualization is an established tool to reason about data. present results from two case studies. unit tests. Rather than manually stepping through the ex- to each other, identify links between them, provide automatically retrieved labels, Given a wanted visualization, we can typically find tools ecution with a debugger, we perform dynamic analysis to and use a visualization to illustrate how they are distributed over the system. Our that take as input a certain format and that provide the Keywords: Dynamic Analysis, Object Flow Analysis, Adding edges and layouting. To show how classes in- derive information to support the task of writing tests with- approach is language independent as it works at the level of identifier names. To needed visualization [4]. Software Maintenance, Unit Testing herit from each other, we can add an edge for each inheri- out requiring a detailed understanding of the source code. validate our approach we applied it on several case studies, two of which we present One drawback of the approach is that, when a deep rea- tance relationship. In our example, supposing that we can In our experimental tool, we present a visual represen- 1 Introduction in this paper. soning is required, we need to refer back to the capabili- ask the model for all the inheritance objects, and given an tation of the dynamic information in a diagram similar to ties of the original tool that manipulates the original data. inheritance object, we will create an edge between the node the UML object diagram [11]. We call this diagram a Test Note: Some of the visualizations presented make heavy use of colors. Please obtain can Creating automated tests for legacy systems is a key Another drawback is that it actually duplicates the required holding the superclass and the node holding the subclass. Blueprint as it serves as a plan for implementing a test. It maintenance task [9]. Tests are used to assess if legacy be- a color copy of the article for better understanding. resources unnecessarily: the data is present both in the orig- We layout the nodes in a tree. reveals the minimal required fixture and the side effects that havior has been preserved after performing modifications or inal tool, and in the visualization tool. Several tools take a are produced during the execution of a particular program extensions to the code. Unit testing (i.e., tests based on the view := ViewRenderer new. middle ground approach and choose to work close with the unit. Thus, the Test Blueprint reveals the exact information Key words: reverse engineering, clustering, latent semantic indexing, visualization view newShape rectangle; XUnit frameworks [1]) is an established and widely used width: #NOA; height: #NOM; linearColor: #LOC within: model classes; data by either offering integration with other services [1], that should be verified with a corresponding test. testing technique. It is now generally recognized as an es- PACS: withBorder. or providing the services themselves [2]. However, when To generate a Test Blueprint, we need to accurately an- view nodes: model classes. sential phase in the software development life cycle to en- view edges: model inheritances another type of service is required, the integration is lost. alyze object usage, object reference transfers, and the side sure software quality, as it can lead to early detection of from: #superclass effects that are produced as a result of a program execution. to: #subclass. We present Mondrian, a visualization engine that imple- defects, even if they are subtle and well hidden [2]. view treeLayout. To do so, we perform a dynamic Object Flow Analysis in ments a radically different approach. Instead of provid- The task of writing a unit test involves (i) choosing an view open. Email addresses: akuhn@iam.unibe.ch (Adrian Kuhn), sduca@unv-savoie.fr conjunction with conventional execution tracing [17]. ing a required data format, we provide a simple interface appropriate program unit, (ii) creating a fixture, (iii) execut- (St´phane Ducasse), girba@iam.unibe.ch (Tudor Gˆ e ırba). Object Flow Analysis is a novel dynamic analysis which Nesting. To obtain more details for the classes, we through which the programmer can easily script the visu- ing the unit under test within the context of the fixture, and tracks the transfer of object references in a program execu- We gratefully acknowledge the financial support of the Swiss National Science 1 alization in a declarative fashion (more information can be would like to see which are the methods inside. To nest we (iv) verifying the expected behavior of the unit using asser- tion. In previous work, we demonstrated how we success- found in [3]). That is, our solution works directly with the specify for each node the view that goes inside. Supposing tions [1]. All these actions require detailed knowledge of Foundation for the project “Recast: Evolution of Object-Oriented Applications” objects in the data model, and instead of duplicating the ob- that we can ask each class in the model about its methods, the system. Therefore, the task of writing unit tests may (SNF 2000-061655.00/1) 1 We refer to side effect as the program state modifications produced by jects by model transformation, we transform the messages we can add those methods to the class by specifying the prove difficult as developers are often faced with unfamiliar 2 We gratefully acknowledge the financial support of the french ANR for the project a behavior. We consider the term program state to be limited to the scope papers sent to the original objects via meta-model transformations. view for each class. legacy systems. of the application under analysis (i.e., excluding socket or display updates). “Cook: R´architecturisation des applications ` objets” e a 1 Preprint submitted to Elsevier Science 11 October 2006 e than e mor db shoul earch Res The Story of Moose: an Agile Reengineering Environment Oscar Nierstrasz Stephane Ducasse ´ Tudor Gˆrba ı Practical Object-Oriented Back-in-Time Debugging Enriching Reverse Engineering with Software Composition Group Software Composition Group Software Composition Group University of Berne University of Berne University of Berne Annotations Switzerland Switzerland Switzerland Adrian Lienhard, Tudor Gˆrba and Oscar Nierstrasz ı www.iam.unibe.ch/∼scg Andrea Br¨hlmann, Tudor Gˆ u ırba, Orla Greevy, Oscar Nierstrasz Software Composition Group, University of Bern, Switzerland ABSTRACT Software Composition Group, University of Bern, Switzerland http://scg.unibe.ch/ Abstract. Back-in-time debuggers are extremely useful tools for identifying the Requirements Moose is a language-independent environment for reverse- causes of bugs, as they allow us to inspect the past states of objects that are no and re-engineering complex software systems. Moose pro- longer present in the current execution stack. Unfortunately the “omniscient” ap- vides a set of services including a common meta-model, met- problem assessment xxx proaches that try to remember all previous states are impractical because they Xxx rics evaluation and visualization, a model repository, and z a Designs Abstract. Much of the knowledge about software systems is implicit, either consume too much space or they are far too slow. Several approaches rely generic GUI support for querying, browsing and grouping. z yyy and therefore difficult to recover by purely automated techniques. Archi- The development effort invested in Moose has paid off in on heuristics to limit these penalties, but they ultimately end up throwing out Yyy model capture and analysis tectural layers and the externally visible features of software systems are precisely those research activities that benefit from applying too much relevant information. In this paper we propose a practical approach two examples of information that can be difficult to detect from source a combination of complementary techniques. We describe Code migration to back-in-time debugging that attempts to keep track of only the relevant past how Moose has evolved over the years, we draw a number code alone, and that would benefit from additional human knowledge. data. In contrast to other approaches, we keep object history information together of lessons learned from our experience, and we outline the Typical approaches to reasoning about data involve encoding an explicit with the regular objects in the application memory. Although seemingly counter- present and future of Moose. meta-model and expressing analyses at that level. Due to its informal na- intuitive, this approach has the effect that past data that is not reachable from cur- Figure 1: The Reengineering life cycle. ture, however, human knowledge can be difficult to characterize up-front Categories and Subject Descriptors rent application objects (and hence, no longer relevant) is automatically garbage and integrate into such a meta-model. We propose a generic, annotation- collected. In this paper we describe the technical details of our approach, and D.2.7 [Software Engineering]: Maintenance—Restructur- based approach to capture such knowledge during the reverse engineering we present benchmarks that demonstrate that memory consumption stays within ing, reverse engineering, and reengineering process. Annotation types can be iteratively defined, refined and trans- practical bounds. Furthermore since our approach works at the virtual machine reengineer. In addition to the code base, there may be doc- formed, without requiring a fixed meta-model to be defined in advance. level, the performance penalty is significantly less than with other approaches. General Terms umentation (though often out of sync with the code), bug We show how our approach supports reverse engineering by implement- reports, tests and test data, database schemas, and espe- ing it in a tool called Metanool and by applying it to (i) analyzing archi- Measurement, Design, Experimentation cially the version history of the code base. Other important 1 Introduction tectural layering, (ii) tracking reengineering tasks, (iii) detecting design sources of information include the various stakeholders (i.e., Keywords flaws, and (iv) analyzing features. users, developers, maintainers, etc.), and the running system itself. The reengineer will neither rely on a single source of When debugging object-oriented systems, the hardest task is to find the actual root Reverse engineering, Reengineering, Metrics, Visualization information, nor on a single technique for extracting and cause of the failure as this can be far from where the bug actually manifests itself [1]. analyzing that information [11]. 1. INTRODUCTION 1 Introduction In a recent study, Liblit et al. examined bug symptoms for various programs and found Reengineering is a complex task, and it usually involves Software systems need to evolve continuously to be effec- that in 50% of the cases the execution stack contains essentially no information about several techniques. The more data we have at hand, the Most reverse engineering techniques focus on automatically extracting infor- tive [41]. As systems evolve, their structure decays, unless the bug’s cause [2]. more techniques we require to apply to understand this data. effort is undertaken to reengineer them [41, 44, 23, 11]. mation from the source code without taking external human knowledge into These techniques range from data mining, to data presen- Classical debuggers are not always up to the task, since they only provide access to The reengineering process comprises various activities, in- consideration. More often than not however, important external information is tation and to data manipulation. Different techniques are information that is still in the run-time stack. In particular, the information needed to cluding model capture and analysis (i.e., reverse engineer- implemented in different tools, by different people. An in- available (e.g., developer knowledge or domain specific knowledge) which would track down these difficult bugs includes (1) how an object reference got here, and (2) ing), assessment of problems to be repaired, and migration frastructure is needed for integrating all these tools. greatly enhance analyses if it could be taken into account. from the legacy software towards the reengineered system. the previous values of an object’s fields. For this reason it is helpful to have previous ob- Moose is a reengineering environment that offers a com- Only few reverse engineering approaches integrate such external human knowl- Although in practice this is an ongoing and iterative process, mon infrastructure for various reverse- and re-engineering ject states and object reference flow information at hand during debugging. Techniques we can idealize it (see Figure 1) as a transformation through edge into the analysis. For example, reflexion models have been proposed for ar- tools [22]. At the core of Moose is a common meta-model and tools like back-in-time debuggers, which allow one to inspect previous program various abstraction layers from legacy code towards a new for representing software systems in a language-independent chitecture recovery by capturing developer knowledge and then manually map- states and step backwards in the control flow, have gained increasing attention recently system [11, 13, 35]. way. Around this core are provided various services that ping this knowledge to the source code [1,2]. Another example is provided by [3,4,5,6]. What may not be clear from this very simplified picture is are available to the different tools. These services include Intensional Views which make use of rules that encode external constraints and that various kinds of documents are available to the software The ideal support for a back-in-time debugger is provided by an omniscient imple- metrics evaluation and visualization, a repository for storing are checked against the actual source code [3]. multiple models, a meta-meta model for tailoring the Moose mentation that remembers the complete object history, but such solutions are imprac- In this paper we propose a generic framework based on annotations to en- meta-model, and a generic GUI for browsing, querying and Permission to make digital or hard copies of all or part of this work for tical because they generate enormous amounts of information. Storing the data to disk grouping. personal or classroom use is granted without fee provided that copies are hance a reverse engineered model with external knowledge so that automatic instead of keeping it in memory can alleviate the problem, but it only postpones the Moose has been developed over nearly ten years, and has not made or distributed for profit or commercial advantage and that copies analyses can take this knowledge into account. A key feature of our approach end, and it has the drawback of further increasing the runtime overhead. Current imple- bear this notice and the full citation on the first page. To copy otherwise, to itself been extensively reengineered during the time that it republish, to post on servers or to redistribute to lists, requires prior specific mentations such as ODB [3], TOD [4] or Unstuck [5] can incur a slowdown of factor has evolved. Initially Moose was little more than a com- permission and/or a fee. Models 2008, Krzysztof Czarnecki, et al. (Eds.), LNCS, vol. 5301, Springer-Verlag, mon meta-model for integrating various ad hoc tools. As it 100 or more for non-trivial programs. Proceedings ESEC-FSE’05, pp. 1-10, ISBN 1-59593-014-0. September 2008, pp. 660-674. became apparent that these tools would benefit immensely 5–9, 2005, Lisbon, Portugal. from a common infrastructure, we invested in the evolution Copyright 2005 ACM 1-59593-014-0/05/0009 ...$5.00.
    • puzzle ch is a esear R addPage addFolder
    • tal 2007 reevy e G
    • puzzle ch is a esear R
    • 8 nza 200 ttel, La We
    • can e open ould b arch sh e Res
    • can dustry act in p ould im rch sh Resea
    • is an analysis tool is a modeling platform is a visualization platform is a tool building platform dea ni is a is a collaboration
    • e.ch unib se. o mo