Reflection Library for Eiffel PROJECT PLAN

Size: px

Start display at page:

Download "Reflection Library for Eiffel PROJECT PLAN"

Letitia Norman
5 years ago
Views:

1 Reflection Library for Eiffel PROJECT PLAN Master thesis Project period: Monday, Wednesday, Student: Beat Fluri Status: 9th semester Supervising Assistant: Bernd Schoeller Supervising Professor: Bertrand Meyer

2 1 Project Description 1.1 Overview State of the art programming languages like Java or C# provide a reflection API. Reflection means to discover properties of programs at runtime. This includes [5]: Determine the class of an object Get information about a class s modifiers, fields, methods, constructors, and superclasses Find out what constants and method declarations belong to an interface Create an instance of a class whose name is not known until runtime Get and set the value of an object s field, even if the field name is unknown to your program until runtime Invoke a method on an object, even if the method is not known until runtime Create a new array, whose size and component type are not known until runtime, and then modify the array s components The first obvious application area of reflection is certainly a debugger. But monitoring and modifying programms during runtime is as meaningfull, unless even more. In fact Eiffel does not feature a full reflection library. There exists an Eiffel class INTERNAL, which supports getting information about the fields of an object and modifying them, but as mentioned above this is only a part of a full reflection API. 1.2 Eiffel object model The special interest of this master thesis is to map a very sophisticated object model into a reflection library. Eiffel, compared to state of the art object-oriented programming languages, supports programmers with lots of specialities to increase software quality in large software systems. To show what specialities are meant, here is a small choice: Differentiation of class and type (genericity) Renaming or redefinition of features to reduce the complexity of multiple inheritence Feature export to only a set of classes 1.3 Scope of the work The master project is composed of tree parts: 1. Evaluation of the existing reflection APIs of Java, C#, Smalltalk and maybe one of the two script oriented languages Python or Ruby. Finally a comparison with the Eiffel class INTERNAL will be made: Showing usage of each API with short but clear examples Determining the design issues of each API Showing assets and drawbacks of the design of each API including a comparison of the APIs among each other 1

3 2. Design of a full Eiffel reflection library (ERL): Decision of a design on the basis of the results obtained by Partial implementation of ERL 4. Design and implementation of an object editor: Showing usage of ERL Providing possibilities to travers a given object structure to see and modify the fields 1.4 Intended results Reflection Library for Eiffel The aim of this thesis is to develop a reflection library for Eiffel. The library should be carefully designed according to the evaluation of the existing reflection APIs of Java, C# and Smalltalk and maybe Python or Ruby. To obtain a well designed Eiffel library the guidelines of OOSC2 ([2]) must be fulfilled (see 3.2). Because the compiler and runtime environment of Eiffel does not support full reflection, the implementation of the library is not feasible to full extend. But all contracted interfaces have to be available and all features available in INTERNAL must be implemented Object editor The object editor will show the usage of the reflection library. The required set of its features is to travers given object structures and modify their fields. To give the opportunity to use the object editor in Introduction to Programming course, it must be easy to use and have a user guide Thesis report The part of the evaluation of existing reflection APIs in the final report should give the readers an introduction to each API. This also includes reasonable examples to show how to use the APIs. Finally a comparison between their designs will point out how a good reflection library shoud be designed. All made design decisions of the ERL and the object editor must be well explained in the thesis report. Further the ERL design should be comprehensible with the result of the evaluation of the existing reflection APIs. 2 Background material 2.1 Reading list Eiffel object model: [1] Object technology, library design: [2], [3] Reflection in general: [4] Reflection in Java: [3], [5], [6], [7], [8], [9], [10] Reflection in.net: [3], [11], [12] Reflection in Smalltalk: [13], [14], [15] Reflection in Ruby: [16], [17] Reflection in Python: [18], [19] Object editors: [20] 2

4 3 Project management 3.1 Objectives and priorities Eiffel reflection library Objective Priority API Design 1 API Documentation 1 Implementation of INTERNAL features Object editor Objective Priority Design and implementation 1 Ease of use Thesis report Objective Priority Evaluation of exiting reflection APIs 1 Explanation of ERL design decisions 1 Object editor user guide Criteria for success The main goal of this project is to develop a well designed reflection library for Eiffel. Therefor the criteria for success is the quality of software and the documentation. The subprojects object editor and evaluation of existing reflection APIs have to fulfill the same criteria. To achieve this, some points must be satisfied: Quality of software: Design by contract Core principles of OOSC2 [2] Good design of the interface Completeness with respect to the limitations of the compiler and runtime environment: Complete interface of all features of a full reflection library in contractual form Implementation of all features available in INTERNAL Implementation of the object editor to travers a given object structure and modify the fields Quality of documentation: Good structure Understandability Completeness 3

5 3.3 Method of work The technologies involved are:.net Framework and SDK 1.1 Java 2 SDK and 1.5beta Squeak (Smalltalk) Python / Ruby ISE EiffelStudio LATEX The Java reflection examples, the ERL and the object editor will be developed on Linux, the C# reflection examples on Windows. The documentation is written using LATEX. 3.4 Qualitiy management Documentation The thesis report will be written throughout the whole project. Each of the project steps will be adhered in a corresponding chapter. The user guide for the object editor is part of the thesis report Validation steps To close the project successfully the following meetings should be made: Weekly status report to the supervising assistant, reasonably every friday Special meetings with the supervising assistant after completing a subproject Obscurities will be discussed with the supervising assistant 4 Plan with milestones 4.1 Project steps and milestones Existing reflection APIs (M1): Develop Java, C#, Smalltalk and maybe Python or Ruby reflection examples Evaluate APIs and compare them with INTERNAL Design of the eiffel reflection library (M2): Specify full reflection according to the existing APIs and the Eiffel object model [1] Design of ERL Validation Partial implementation of ERL (M3): Implement features of INTERNAL Test cases 4

6 Object editor (M4): Design and specification Implement object editor Test cases Implement example object structur User guide Thesis report (M5) 4.2 Deadline Project start: Monday, Project end: Wednesday, Total work time: 26 weeks + 3 days = 133 days 4.3 Tentative schedule References [1] Meyer, Bertrand. Eiffel: The Language, 1st Edition, 2nd Printing, Prentice Hall PRT, [2] Meyer, Bertrand. Object-Oriented Software Construction, 2nd Edition, Prentice Hall, [3] Szyperski, Clemens. Component Software - Beyond Object-Oriented Programming, 2nd Edition, Addison-Wesley,

7 [4] Proceedings of the Reflection 96 Conference, San Francisco, April www2.parc.com/csl/groups/sda/projects/reflection96/index.html [5] Green, Dale. Trail: The Reflection API java.sun.com/docs/books/tutorial/reflect/ [6] Sosnoski, Dennis M. Java programming dynamics, Part 1: Classes and class loading www-106.ibm.com/developerworks/java/library/j-dyn0429/ [7] Sosnoski, Dennis M. Java programming dynamics, Part 2: Introducing reflection www-106.ibm.com/developerworks/java/library/j-dyn0603/ [8] Sosnoski, Dennis M. Java programming dynamics, Part 3: Applied reflection www-106.ibm.com/developerworks/java/library/j-dyn0715.html [9] Sosnoski, Dennis M. Java programming dynamics, Part 4: Class transformation with Javassist www-106.ibm.com/developerworks/java/library/j-dyn0916.html [10] Becker, Dan. Reflection: A new way to discover information about Java classes www-106.ibm.com/developerworks/java/library/j-reflection.html [11] Liberty, Jesse. Programming C#, 3rd Edition, O Reilly, [12] Microsoft MSDN Library msdn.microsoft.com/library/ [13] Goldber, Adele & Robson, David. Smalltalk-80: The Language, 1st Edition, [14] Rivard, Fred. Smalltalk: a Reflective Language, Proceedings of the Reflection 96 Conference, San Francisco, April [15] Squeak [16] Programming Ruby - The Pragmatic Programmer s Guide [17] Ruby: Programmers Best Friend [18] Andersen, Anders. A note on reflection in Python 1.5 [19] Python Programming Language [20] BlueJ - The Interactive Java Environment 6

EIFFEL TEST STUDIO Locating faults in external code Master Thesis Project Plan

EIFFEL TEST STUDIO Locating faults in external code Master Thesis Project Plan Reto Ghioldi Department of Computer Science ETH Zürich September 6, 2005 Project period 8.September 2005-9.March 2006 Student