Download Report - ARMI Wiki

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Structured programming wikipedia , lookup

Falcon (programming language) wikipedia , lookup

Abstraction (computer science) wikipedia , lookup

Class (computer programming) wikipedia , lookup

Java (programming language) wikipedia , lookup

C++ wikipedia , lookup

Design Patterns wikipedia , lookup

Go (programming language) wikipedia , lookup

Java performance wikipedia , lookup

Name mangling wikipedia , lookup

Object-relational impedance mismatch wikipedia , lookup

Java ConcurrentMap wikipedia , lookup

Object-oriented programming wikipedia , lookup

C Sharp syntax wikipedia , lookup

C Sharp (programming language) wikipedia , lookup

Transcript
TABLE OF CONTENTS
TITLE
Abbreviations & Definitions
Abstraction
1 Introduction
1.1 Objectives
1.2 Scope of the Project
2 Literature Survey
3 System Study of the Proposed Project
3.1 Existing System
3.2 Proposed System
4 System Analysis
5 System Design
5.1 Architectural Framework
5.1.1 Use case Diagram
5.1.2 Activity Diagram
5.1.3 Sequence Diagram
5.1.4 Class Diagrams
5.2 Interface Design
5.2.1 Swing Windows
5.2.2 Swing Containers
5.2.3 Swing Controls
5.2.4 Swing Menus
6 Implementation Methodology
6.1 Problem Statement
6.2 Problem Description
6.3 Features of the Project
7 Software Description
8 Testing and Validation
9 Future Enhancements
10 Conclusion
Appendix I : Working Environment
Appendix II: Screen Shots
References
Page No.
1
2
3
4
4
5
6
6
6
9
12
13
13
14
16
18
27
27
27
28
29
31
31
31
32
33
34
35
36
37
38
42
0
ABBREVIATIONS & DEFINITIONS
Abbreviations
AOP: Aspect Oriented Programming
OOP: Object Oriented Programming
DB: Database
LOG: Logging
Definitions
Aspect: A modularized implementation of a software concern that cuts across various objects
in a software implementation. Logging is a good example of an aspect. A collection of
pointcut designators and advice organized to perform a coherent task is called an aspect.
Join point: A point during program execution, such as a method executing or an exception
being handled.
Advice: The specification of what to do at the Join point is called advice
Pointcut: A declarative condition that identifies the join points for consideration during an
execution run.
Intercept-Mode: This specifies how an aspect injection takes place. There are two types of
interception- method and member. In method intercept-mode, an aspect injection takes place
with respect to a method execution- either before or after or on exception in the method. A
typical example is LOG. In member intercept-mode, injection is not confined to any
particular method execution. A typical example is DB.
1
ABSTRACT
Our project is aimed at designing an Aspect oriented language called JAspect. Our
language will be using the syntax of Java except for handling aspects. We have set two kinds
of aspects to handle. The one is predefined aspects which are provided with predefined
classes. We also provide facility to the user for writing his aspects specifying the point-cutsthe places for injecting the advice. In addition to designing syntax for handling aspects, we
have also developed an IDE which provides the user with the facility for developing and
storing Aspects, injecting them and weaving the injected code all through the help of GUIs.
As an example of testing our language we have selected database as a predefined aspect- the
database queries will usually cut across multiple classes and hence an aspect. We have
developed a DB class for handling database related operations like insert, delete and update.
We have used Derby as an example database here which uses SQL syntax. Having database
being implemented as an aspect makes make the user program work with any new database
with non-SQL syntax as well, with modifications in the DB class only.
2
CHAPTER 1
INTRODUCTION
Aspect-oriented programming (AOP) grew out of a recognition that typical programs
often exhibit behavior that does not fit naturally into a single program module, or even
several closely related program modules. Aspect pioneers termed this type of behavior
crosscutting because it cut across the typical divisions of responsibility in a given
programming model. In object-oriented programming, for instance, the natural unit of
modularity is the class, and a crosscutting concern is a concern that spans multiple classes.
Typical crosscutting concerns include logging, context-sensitive error handling, performance
optimization, and design patterns.
Several problems result from a lack of modularity. Because the implementation of a
crosscutting behavior is scattered, developers find the behavior difficult to reason about,
implement, and change. Code for logging, for instance, intertwines with code whose primary
responsibility is something else. Depending on the complexity and scope of the concern
being addressed, the resulting tangle can be anywhere from minor to significant. Changing an
application's logging policy could involve hundreds of edits -- an irritating, if doable, task.
AOP complements object-oriented programming by facilitating another type of modularity
that pulls together the widespread implementation of a crosscutting concern into a single unit.
These units are termed aspects, hence the name aspect-oriented programming. By
compartmentalizing aspect code, crosscutting concerns become easy to deal with. Aspects of
a system can be changed, inserted or removed at compile time, and even reused.
3
1.1 OBJECTIVES
Our project has two parts- the first is to design the syntax for JAspect- our Aspect
Oriented Language and the second is to create an easy to use IDE for the user to develop
programs in JAspect even without knowing its actual syntax.
1.2 SCOPE OF THE PROJECT
Aspect-oriented programming (AOP) grew out of a recognition that typical programs
often exhibit behaviour that does not fit naturally into a single program module, or even
several closely related program modules. Aspect pioneers termed this type of behaviour
crosscutting because it cut across the typical divisions of responsibility in a given
programming model. In object-oriented programming, for instance, the natural unit of
modularity is the class, and a crosscutting concern is a concern that spans multiple classes.
Typical crosscutting concerns include logging, context-sensitive error handling, performance
optimization, and design patterns.
Several problems result from a lack of modularity. Because the implementation of a
crosscutting behaviour is scattered, developers find the behaviour difficult to reason about,
implement, and change. Code for logging, for instance, intertwines with code whose primary
responsibility is something else. Depending on the complexity and scope of the concern
being addressed, the resulting tangle can be anywhere from minor to significant. Changing an
application's logging policy could involve hundreds of edits -- an irritating, if doable, task.
AOP complements object-oriented programming by facilitating another type of
modularity that pulls together the widespread implementation of a crosscutting concern into a
single unit. These units are termed aspects, hence the name aspect-oriented programming. By
compartmentalizing aspect code, crosscutting concerns become easy to deal with. Aspects of
a system can be changed, inserted or removed at compile time, and even reused.
4
CHAPTER 2
LITERATURE SURVEY
Object oriented programming has become the mainstream over the last years, having
almost completely replaced the procedural approach. One of the biggest advantages of object
orientation is that a software system can be seen as being built of a collection of discrete
classes. Each of these classes has a well defined task; its responsibilities are clearly defined.
In an OO application, those classes collaborate to achieve the application's overall goal.
However, there are parts of a system that cannot be viewed as being the responsibility of only
one class, they cross-cut the complete system and affect parts of many classes. Examples
might be locking in a distributed application, exception handling, or logging method calls. Of
course, the code that handles these parts can be added to each class separately, but that would
violate the principle that each class has well-defined responsibilities. This is where AOP
comes into play: AOP defines a new program construct, called an aspect, which is used to
capture cross-cutting aspects of a software system in separate program entities. The
application classes keep their well-defined responsibilities. Additionally, each aspect
captures cross-cutting behavior
AOP is designed to handle crosscutting concerns by providing a mechanism, the aspect,
for expressing these concerns and automatically incorporating them into a system. AOP does
not replace existing programming paradigms and languages; instead, it works with them to
improve their expressiveness and utility. It enhances our ability to express the separation of
concerns necessary for a well-designed, maintainable software system. Some concerns are
appropriately expressed as encapsulated objects, or components. Others are best expressed as
cross-cutting concerns.
5
CHAPTER 3
SYSTEM STUDY OF THE PROPOSED PROJECT
3.1 EXISTING SYSTEM
AOP is a concept and as such it is not bound to a certain programming language or
programming paradigm. It can help with the shortcomings of all languages that use single,
hierarchical decomposition. This may be procedural, object oriented, or functional. AOP has
been implemented in different languages, among them Smalltalk and Java.
Aspectml is a typed functional aspect oriented programming language. The main contribution
of Aspectml is the seamless integration of polymorphism, run-time type analysis and aspectoriented programming language features. In particular, Aspectml allows programmers to
define type-safe polymorphic advice using pointcuts constructed from a collection of
polymorphic join points.
The Java implementation of AOP is called AspectJ (TM) and has been created at Xerox
PARC. AspectJ has been designed to be implemented in many ways, including source- or
bytecode-weaving and directly in the VM (virtual machine). In all cases, the AspectJ
program is transformed into a valid Java program run in a Java VM. Any classes affected by
aspects are binary-compatible with the unaffected classes (in order to maintain compatibility
with any classes that were compiled with the unaffected originals). Supporting multiple
implementations allows the language to grow as technology changes, and being Javacompatible ensures platform availability. AspectJ also supports limited forms of pointcutbased static checking and aspect reuse (by inheritance).
3.2 PROPOSED SYSTEM
What we have done is to develop an Aspect Oriented Language, which can be easily
used by anyone knowing programming in Java and has an idea of aspects. Through our IDE,
he can develop Java projects as usual as well as define and implement aspects. In our
language, weaving is done directly in source-code before compilation. The aspects once
defined can be stored for use by future projects as well.
6
1) Aspect Syntax: The Aspect definition starts with # and ends with #. For the two types of
aspects based on intercept mode, there are two types of syntax. Consider the following
example
#log
.before(getName,getAge){ log()}
#
In given example log is the name of the aspect and getName() and getAge() are the methods
before which injection of the aspect code need to occur. Similar is the syntax of all aspects
whose intercept mode is method.
Database is an example of an aspect whose intercept mode is member. Following is the
syntax for insert injection of database aspect.
#db
.insert(“name”,”Philip”)
#
Inspite of having such syntax for the aspects, JAspect doesn’t require the user to learn them.
He has the option to use the GUI screens to develop and inject aspects.
3) Syntax of AJXML
<aspects>
<aspect
name="db"
class="myaspects.DataAccessService"
intercept-mode="member">
<params>
<param
name="driver">com.mysql.jdbc.Driver</param>
<param
name="url">jdbc:mysql://localhost:3306/test</param>
<param name="username">jock</param>
<param name="driver">lion</param>
</params>
<methods>
<method name="insert">
7
<method-params>
<class-fields full="false"/>
<param name="count" type="int"/>
</method-params>
</method>
</methods>
</aspect>
<aspect name="log" class="myaspects.LoggingService" interceptmode="method">
<params>
<param name="methodName">log</param>
</params>
</aspect>
</aspects>
Here also the user need not manually edit the XML file to add information into the XML file
it can be done with the help of the interface.
8
CHAPTER 4
SYSTEM ANALYSIS
Project Requirements
Input

A source object-oriented project in java devoid of Aspects

Specification of one or more Aspects

Driver class which is a predefined string which allows connectivity to database
Output

A new object oriented project with Aspects included in specified class files
Modules
Aspect Definition Module
Aspect Storing & Retrieval Module
IDE Development Module
Aspect Injection Module
Aspect Weaving Module (~)
Database Module
Compilation & Running Module
1. Aspect Definition Module:
This module is concerned with the creation of GUI for defining Aspects.
Similar to an object, an Aspect has two parts- Aspect Parameters and Aspect Methods. There
must be separate GUI screens for
Defining Aspect
Defining Aspect Method
Defining Aspect Method Body
Use cases for Programmer
9

Define Aspect

Define Aspect Method

Define Aspect Method Body
The defined Aspects are then listed. From the list the programmer can select the
aspect he wants and inject at the points he wants in to be done.
Define Aspect:
This option is used to define a new Aspect. An Aspect will have an aspect name, an
optional set of aspect parameters and one or more aspect methods.
Define Aspect Method:
This option is used to define the methods for an aspect. An aspect method specifies
the method name and an optional list of method parameters.
Define Aspect Method Body:
This option is used define the body of the Aspect Methods. The programmer is
provided with an interface where he can type in a method body similar to one in a normal
IDE.
2. Aspect Storing & Retrieval Module
This module deals with the storing and retrieval of aspect details. Aspects are stored
in XML format. XML tags are defined for aspect name and aspect parameters. This module
also deals with the creation of Aspect Classes for user defined Aspects.
3. IDE Development Module
This module deals with providing the programmer with an easy to use interface to
develop a project in Java. The user needs to be provided with normal IDE features like
syntax highlighting, indentation, short cut keys, and listing of project files in a tree.
4. Aspect Injection Module
This module deals with how the Aspect injection will take place. As there are two
types of Aspects- member as well as method- there are two types of injections. The user
10
needs to be provided two separate GUIs for the same. The GUI screen needs to be shown as
the user selects the inject option after clicking on an Aspect from the listed ones.
5. Database Module
This module deals with the testing of database- an example of functional aspect,
through our project. As an example we have used Derby database which is provided by
NetBeans. The codes as defined in our syntax for database are translated into SQL syntax by
this module. The testing is done for normal database operations like insertion, deletion and
updating.
6. Aspect Weaving Module
This module deals with the translation of the Java source code written by the
programmer with the injected aspects, into a normal Java code, with the Aspect codes being
translated into normal Java syntax and placed at appropriate places.
7. Compilation & Running Module
This module deals with the compilation of the translated Java code into Java byte
code. The compilation errors and warnings are listed for the user. This module also handles
the running of the compiled project.
11
CHAPTER 5
SYSTEM DESIGN
System design is the process of planning of new systems or one to replace an
existing system. During this stage the analyst works with the user to develop a physical
model of the system flow chart. The modeling process and its outcome depend upon the
system to a certain extent and whether or not object oriented design is followed. The detailed
step followed in arriving at the model is known as the methodology. There are several
methodologies available. But currently the most popular methodology is known as 'the
unified process'. The result of these is a model for the system typically contained in several
diagrams. If unified process is followed the diagrams that result might be UML diagrams.
Input design is the process of creating user defined input in computer defined
format. User originated inputs are converted to a computer based format. It includes
determining the record media, methods of input, speed of capture and entry into the system.
The goal of designing input data is to make data entry easy. Thus the objective of the
designer is to achieve highest possible level of accuracy and ensure that the input is
acceptable and understood by user and the staff. A formatted form of the data entry is also
provided which requested the user to enter the data in appropriate location.
A quality output is the one, which needs the user requirements and presents
information carefully. Output design is an important step in the system design. Computer
output is the most direct and important information source to the user. Efficient, intelligible
output design should improve the system relationships with user and helps in decision
making. The primary consideration in design of output is the information requirement and
objectives of the end users. The major formation of the output is to convey the information
and so its layout and design need a careful consideration.
12
5.1 ARCHITECTURAL FRAMEWORK
5.1.1 USE CASE DIAGRAM
Use Case diagrams identify the functionality provided by the system (use
cases), the users who interact with the system (actors), and the association between the users
and the functionality. Use Cases are used in the analysis phase of software development to
articulate the high-level requirements of the system. Use Cases extend beyond pictorial
diagrams. In fact, text-based use case descriptions are often used to supplement diagrams,
and explore use case functionality in more detail.
Fig:Use case Diagram
13
5.1.2 ACTIVITY DIAGRAM
Activity diagrams are used to document work-flow in a system, from the
business level down to the operational level. In fact, the activity diagram is a variation of the
state diagram where the "states" represent operations, and the transitions represent the
activities that happen when the operation is complete. The general purpose of activity
diagrams is to focus on flows driven by internal processing vs. external events.
14
Fig: Activity Diagram
15
5.1.3 SEQUENCE DIAGRAM
Sequence diagrams describe interactions among classes in terms of an
exchange of messages over time. Class roles describe the way an object will behave in
context. Use the UML object symbol to illustrate class roles, but don't list object attributes.
Activation boxes represent the time an object needs to complete a task. Messages are arrows
that represent communication between objects. Use half arrowed lines to represent
asynchronous messages. Asynchronous messages are sent from an object that will not wait
for a response from the receiver before continuing its tasks. Lifelines are vertical dashed lines
that indicate the object's presence over time.
16
17
5.1.4 CLASS DIAGRAMS
In software engineering, a class diagram in the Unified Modeling Language (UML) is
a type of static structure diagram that describes the structure of a system by showing the
system's classes, their attributes, and the relationships between the classes.
18
19
20
21
22
23
24
25
26
5.2 INTERFACE DESIGN
The interface design is an important part of any software. The goal of user
interface is to make the user's interaction as simple and efficient as possible, in terms of
accomplishing user goals—what is often called user-centered design. Our system provides a
user friendly interface. The interface has been done using java swing components. Different
swing components such as Containers, Controls, Menus and Windows are used in our
system. Following are the details of the swing components being used:
5.2.1 Swing Windows

JFrame:- An extended version of java.awt.Frame that adds support for the
JFC/Swing component architecture. JFrame is used to show the main window in the
project. This window has option to open and save new projects, displays the opened
projects in tree structure, lists aspects and has an editor pane for writing java class.

JDialog:- The main class for creating a dialog window. JDialogue is used for defining
Aspects, Aspect methods and Aspect method body as well as for injecting member
and method aspects.

JFileChooser:- JFileChooser provides a simple mechanism for the user to choose
a file. JFileChooser is used for opening an existing project as well as for opening
existing java, ajava and ajxml files.
5.2.2 Swing Containers

JPanel:- JPanel is a generic lightweight container. It’s used in the AspectMethod
GUI.
27

JSplitPane:- JSplitPane is used to divide two (and only two) Components. Its
used in the main frame to get two components- one for writing java class and the
other for listing the Aspects being used.

JScrollPane:- Provides a scrollable view of a lightweight component. JScrollPane is
used as a container object in all the UI screens being used.

JToolBar:- JToolBar provides a component that is useful for displaying commonly
used Actions or controls. It’s used in the main window for providing the following
controls- Define Aspect, Translate, Compile, Run and Run Project
5.2.3 Swing Controls

JTextField:- JTextField is a lightweight component that allows the editing of a
single line of text. Its used to get the AspectName and the AspectMethod names.

JButton:- An implementation of a "push" button. It’s used in most of the UI screens
for triggering a specific action.

JCheckBox:- An implementation of a check box -- an item that can be selected or
deselected, and which displays its state to the user. It’s used in the UI screen for
injecting method Aspects for selecting the three options for injection- before, after
and on exception.

JComboBox:- A component that combines a button or editable field and a dropdown list. It’s used in AspectDefinition screen for selecting the intercept mode of the
Aspect and in the Injection of Method Aspect for selecting the method, relating to
which the Aspect is to be injected.

JLabel:- A display area for a short text string or an image, or both. It’s used to
describe the components in the UI screens.

JList:- A component that allows the user to select one or more objects from a list. It’s
used to display the list of aspects being used. From the list, aspects can be injected,
edited as well as written to a java class file.

JEditorPane:- A text component to edit various kinds of content. Its used to provide
the programmer the facility for writing source code in Java.
28

JTree:- A control that displays a set of hierarchical data as an outline. It’s used to
display the opened project and the files in it in a hierarchical structure.

JTable:- The JTable is used to display and edit regular two-dimensional tables of
cells. It’s used to enter Aspect parameters and Aspect Method parameters.

JTextPane:- A text component that can be marked up with attributes that are
represented graphically. It’s used to display the compilation warnings and errors.
5.2.4 Swing Menus

JMenuBar:- An implementation of a menu bar. It’s used in the main frame.

JPopupMenu:- An implementation of a popup menu -- a small window that pops up
and displays a series of choices. Two JPopupMenus are used in the main frame- one
for Aspect Context when right clicked on the JList and the other for creating a new
source file when right clicked on the ‘src’ node in JTree.

JMenus:- An implementation of a menu -- a popup window containing JMenuItems
that is displayed when the user selects an item on the JMenuBar. Two menus are
contained in the main frame menubar – File and Edit, two in main frame popup
menu for Aspect Context and one in the popup menu for src.

JMenuItem:- An implementation of an item in a menu. The various menus used are
shown below their respective menus as follows:
o FILE

New Project- A new project is created with the necessary directories
and it’s displayed in the JTree.

Open Project- Opens a JFileChooser for selecting an existing project.
A .pro file must be there in the project directory.

Save- Saves the currently working file.

Save As- Opens a JFileChooser for saving the currently working file in
a new name.
o EDIT

Copy- Copies the selected contents from JEditorPane
29

Cut- Cuts the selected contents from JEditorPane

Paste- Pastes the cut or copied contents to the JEditorPane

Delete- Deletes the selected contents from JEditorPane
o ASPECTCONTEXT

Edit- Opens a new JDIalogue for editing the selected Aspect

Inject- Opens a new JDialogue for injecting the selected Aspect

Create Aspect Class- Creates a Java class from the selected Aspect and
stores it in the myaspects directory.
o SRCPOP

New- Creates a new Java file and adds it to the ‘src’ node in the JTree
30
CHAPTER 6
IMPLEMENTATION METHODOLOGY
Implementation includes placing the system into operation and providing the users and
operation personnel with the necessary documentation to use and maintain the new system.
Implementation includes all those activities that take place to convert from the old system to
the new. The new system may be totally new, replacing an existing system. Proper
implementation is essential to provide a reliable system to meet the organizational
requirements. Successful implementation may not guarantee improvement in the organization
using the new system, as well as, improper installation will prevent any improvement. There
are four methods for handling a system conversion.
6.1 PROBLEM STATEMENT
To design an Aspect Oriented Language and develop an IDE for developing Aspect
oriented projects providing easy to use features to the user.
6.2 PROBLEM DESCRIPTION
We have to first design a syntax for defining aspects. Then we have to design an IDE
to develop projects in JAspect. This IDE has provision to write java code, to define aspects
and to do all operations related to aspect oriented programming.
In the IDE,we have to create a GUI through open java project files. The IDE should be
capable of editing and compiling the open java project. It should also have a provision for
running the compiled java project. For implementing the aspect, we need the IDE to provide
aspect definition features. For this, we have to create GUI’s for different phases of the
definition of aspects. This includes the definition of the aspect, the definition of the functions
in the aspect and other parameters. The IDE should also provide facilities to inject the aspect
wherever required in the project.
31
6.3 FEATURES OF THE PROJECT

Aspect Oriented Programming is made easier.

Users can write Java programs and use the GUI for defining and injecting aspects.

Aspects can be saved and used in new projects.

IDE makes working with software projects easier. Usual IDE features like hierarchical
display of project files, listing of aspects, syntax highlighting, indentation, short cut
keys etc are supported.

Two aspects – DB and LOG are predefined and provided with class files.
32
CHAPTER 8
SOFTWARE DESCRIPTION
This software is implemented using Net Beans IDE 6.7 and JDK 1.6.The software
provides a user interactive interface (GUI). User interface is implemented using java swing
components.
Software when run by user shows a startup window. This window has option to create
a new project or open an existing project. If the user chooses ‘New Project’, a new project
directory and four sub directories- src, inc, lib and build as well as a project information file
are created and they are shown in the JTree. Else if the user choses ‘OpenProject’, then a
JFileChooser is opened to select an existing project directory and its contents are listed in the
JTree. Then the user can create new Java files by right clicking on the ‘src’ node in the JTree
or opens a existing java file by right clicking on it from the JTree. The contents of the opened
file are shown in the JEditorPane for the user to edit.
User also has the option to open the .ajxml for getting an Aspect or he has the option
to define his own Aspects. GUI screens are provided for defining Aspects, defining Aspect
Methods and for defining bodies of Aspect Methods. The newly defined or opened Aspects
are listed. From the list, user can edit the Aspect, inject the Aspect at appropriate places and
create an aspect class file.
After all the Aspects are injected, then the source codes are translated into pure java
code. Then when clicked on the ‘Compile’ button, they are compiled. Compilation warnings
are shown in JTextPane. If compilation is successful, then the project is run by clicking on
the ‘Run’ button.
33
CHAPTER 9
TESTING AND VALIDATION
Software testing is the process of checking whether the developed system is
working according to the original objectives and requirements. The system should be tested
experimentally with test data so as to ensure that the system works according to the required
specification. When the system is found working, test it with actual data and check
performance. Software testing is a critical element of software quality assurance and
represents the ultimate review of specification, design and coding.
JAspect is tested by developing a sample library project which makes use of both our
predefined aspects- DB and LOG. The database operations are found to be performed
successfully and the logging of the method calls are also done successfully.
34
CHAPTER 10
FUTURE ENHANCEMENTS

Though, there is option to automatically generate the class file for a user-defined
aspect, the user need to add information like variable initializations and imports in the
generated class.

The debugging features available in standard environment are not available at present
and it is a feature that we are trying to include.

As of now we have created only some trivial aspects like logging and database. The
project can still be extended for other aspects like security and transactions.
35
CHAPTER 11
CONCLUSION
We are happy to find our project working well. The DB and LOG aspects are
successfully injected into our sample Library project and the project is compiled and run
successfully. The interface for user defined aspects is also working fine. With the help of
documentation comments, we have developed java docs for our project. We hope our project
will be useful for Java programmers interested in doing Aspect Oriented programming.
36
APPENDIX I: WORKING ENVIRONMENT
a.) SOFTWARE SPECIFICATION

Java software development kit 1.6

Java Runtime Environment
b.) HARDWARE SPECIFICATION

1 GHz or above processor

20 MB free hard disk space
37
APPENDIX II: SCREEN SHOTS
Fig: IDE for developing the project
38
Fig: Form for defining aspect configuration
Fig: Form for defining the methods
Fig: Form for defining the method body
39
Fig: Form for defining the aspect
Fig: Code before translation
40
Fig: Code after translation
41
REFERENCES
1. http://www.voelter.de/data/articles/aop/aop.html
2. http://en.wikipedia.org/wiki/Aspect-oriented_programming
3. http://www.eclipse.org/aspectj/
4. http://java.sun.com/j2se/1.5.0/docs/api/
5. http://netbeans.org/kb/
42