Aspect-Oriented Race Detection in Java

ABSTRACT
In the past, researchers have developed specialized programs to aid programmers in detecting concurrent programming errors such as deadlocks, livelocks, starvation, and data races. In this work, we propose a language extension to the aspect-oriented programming language AspectJ, in the form of three new pointcuts, lock(), unlock(), and maybeShared(). These pointcuts allow programmers to monitor program events where locks are granted or handed back, and where values are accessed that may be shared among multiple Java threads. We decide thread locality using a static thread-local-objects analysis developed by others. Using the three new primitive point cuts, researchers can directly implement efficient monitoring algorithms to detect concurrent-programming errors online. As an example, we describe a new algorithm which we call RACER, an adaption of the well-known ERASER algorithm to the memory model of Java. We implemented the new point cuts as an extension to the Aspect Bench Compiler, implemented the RACER algorithm using this language extension, and then applied the algorithm to the NASA K9 Rover Executive and two smaller programs. Our experiments demonstrate that our implementation is effective in finding subtle data races. In the Rover Executive, RACER finds 12 data races, with no false warnings. Only one of these races was previously known.

LIST OF CONTENTS

Page N0 List of Figures List of Tables 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Motivation 1.3.1 Definitions 1.3.2 Abbreviations 1.3.3 Model Diagrams 1.4 Overview 2. Literature Survey 2.1 Introduction 2.2 History 2.3 Purpose 2.4 Requirements 2.5 Technology Used 3. System Analysis 3.1 Existing System 3.1.1 Drawbacks 6 10 10 10 11 11 12 19 13 20 2 2 viii ix 1 1 1

3.2 Problem statement 3.3 Proposed System 3.3.1 Advantages 3.4 Feasibility Study 3.4.1 Economic Feasibility 3.4.2 Operational Feasibility 3.4.3 Technical Feasibility 3.5 Algorithm 4. System Requirements Specification 4.1 Introduction 4.2 Purpose 4.3 Functional Requirements 4.4 Non Functional Requirements 4.5 Hardware Requirements 4.6 Software Requirements 5. System Design 5.1 System Specifications 5.2 System Components 5.3 UML Diagrams 5.4DFD Diagrams 5.5 ER Diagram

20 21 23 24 24 24 25

26 26 26 27 27 28 28 29 29 29 33 38

6. Implementation 6.1 Sample Code 7. System Testing 7.1 Testing Methodologies 7.2 Test cases 7.3 Results and Discussions 8. Conclusion and Future Enhancements 8.1 8.2 Conclusion Scope for Future Enhancement

42 42 50 50 54 61 73 73 73 74

9. References

LIST OF FIGURES
Figure No.
1 2 3 4 5 6 7 8 9 10 11 12 11 12 14 15 16 17 18 19 20 21

Figure Name Page No Fig

class diagram use case diagram sequence diagram

Collaboration diagram

State chart Diagram Activity Diagram Deployment Diagram Component Diagram DFD Diagram
SOFTWARE TESTING LIFE CYCLE

Fig Login Form Fig Login validation Form Fig Registration Form Fig Registration validation Form

LIST OF TABLES
Table No. Table Name Page No

1 2 3 4

Positive Test case Negative Test Case

1. INTRODUCTION
PROGRAMMING errors occur frequently in software systems, and therefore, researchers have spent much effort on developing methods to detect and remove such errors as easily and early as possible in the development process. Concurrent programs are even more likely to suffer from programming errors as concurrent programming adds potential sources of failure. In a concurrent program, a programmer has to make sure to avoid deadlocks, to properly protect shared state from data races, and to protect single threads or processes from starvation. Researchers have developed specialized static and dynamic analyses to aid programmers with these tasks. All of these approaches share one common concern. They identify events of interest, such as the acquisition and release of locks or the access to shared state. Static approaches analyze the program source, while dynamic approaches analyze a trace or abstract-state representation generated by executing the program. Up to now, most existing dynamic approaches have used some form of low level bytecode instrumentation library to transform the analyzed program into one that generates those events. However, such libraries, for example, BCEL, are difficult to use and distract efforts from focusing on the more interesting algorithmic aspects of the analyses. Researchers have recognized aspect-oriented programming as a convenient tool to declare instrumentation at a high level of abstraction. Aspect oriented programming allows programmers to use predicates, called point cuts, to intercept certain events of interest at runtime. Unfortunately, in all of the current Java-based aspect-oriented programming languages, programmers can only intercept events such as method calls, field accesses, and exception handling. In particular, none of these languages allows programmers to intercept events that regard the acquisition and release of locks. This precludes programmers from implementing algorithms in Aspect J that are meant to find concurrency related programming errors such as data races. In this work, we hence propose a novel extension to the aspect oriented programming language Aspect J. The language extension that we propose enhances AspectJ with three new point cuts, to make available to the programmer three additional kinds of events: 1) the acquisition of a lock, 2) the release of a lock, and 3) the event of reading from or writing to a field that may be shared among threads. For instance, the following pointcut captures the event of locking on object l: lock() && args(l). A programmer can capture the converse event of unlocking l by simply writing unlock() && args(l). Setting a

potentially shared field on an object o is captured via the pointcut set(! static *)&&target(o) && may be Shared(). Matching the first two pointcuts against a given program is decidable. The problem of matching the may be Shared() pointcut is, however, generally undecidable. We therefore compute a sound over approximation using a static thread-local-objects analysis . The approximation assures that the pointcut matches every access to a field that is indeed shared. Because of the over approximation, the pointcut may, however, also match accesses to fields that are not actually shared, i.e., fields that only a single thread accesses. Using these three novel pointcuts, programmers can easily implement bug-finding algorithms that detect errors related to concurrency. The lock() and unlock() pointcuts allow a programmer to uniformly act on any acquisition and release of a lock using synchronized blocks and methods in any Java program. The programmer can use the maybeShared() point cut to gain runtime efficiency by monitoring accesses to only those fields that may be shared among threads. To demonstrate the feasibility of the approach, we implemented the three novel pointcuts as an extension to the Aspect Bench Compiler. To show how programmers can use this language extension,weadapted the ERASER race detection algorithm to Java, and implemented it using the new pointcuts. The new algorithm is named RACER. Both ERASER and RACER detect program executions which reveal potential for data races in the executed application. We presented a first version of the RACER algorithm at ISSTA 2008. However, we subsequently noted1 that a large number of potential data races that this version of RACER reported were unfortunately false warnings. The initial version of RACER reported these false warnings because it ignored calls to Thread.start(). The improved version of RACER that we present in this paper takes such calls into account and therefore avoids reporting these false positives. We applied the aspects implementing the RACER algorithm to a plan execution program for the NASA K9 rover and two other multithreaded programs written by computer science researchers. Our results show that the algorithm is effective in finding data races. In the NASA code, RACER found 12 races, 11 of which were previously unknown, although extensive studies had been performed on the K9 rover code before. In the other two programs, we found no races, which was expected because we strongly believe that these programs are race-free. RACER reported only one false warning on these three benchmarks. As we will show, beyond data race detection, the extension is able to support most (if not all) other concurrency analysis algorithms, which typically analyze properties of synchronization and field accesses. Our extension of AspectJ can capture all of Javas

synchronization primitives, and AspectJ already provides pointcuts for accessing those entities intended to be protected by synchronization, namely, field reads and writes. The extension, for example, will be able to support algorithms for deadlock detection , high-level data race detection , and stale-value detection. Researchers have previously implemented all of these algorithms using the low-level BCEL bytecode instrumentation library . Programmers could implement such bug-detection tools much easier using AspectJ. The main contributions of this work are: 1. a description of three novel AspectJ pointcuts, lock(), unlock(), and maybeShared(), 2. an implementation of these pointcuts in the Aspect-Bench Compiler in the case of the maybeShared() pointcut through a static whole-program analysis, 3. an algorithm for race detection in Java, coined RACER, that improves on ERASER, and an implementation using the three novel AspectJ pointcuts, and 4. an experiment showing that our implementation is effective in finding data races in a plan execution program for the NASA K9 rover.

1.1 Purpose
The language extension that we propose enhances AspectJ with three new pointcuts, to make available to the programmer three additional kinds of events: 1) The acquisition of a lock, 2) The release of a lock, and 3) The event of reading from or writing to a field that may be shared among threads.

1.2 Scope
Matching the first two pointcuts against a given program is decidable. The problem of matching the may be Shared() pointcut is, however, generally undecidable. We therefore compute a sound overapproximation using a static thread-local-objects analysis. The approximation assures that the pointcut matches every access to a field that is indeed shared. Because of the overapproximation, the pointcut may, however, also match accesses to fields that are not actually shared, i.e., fields that only a single thread accesses.

1.3.1 Definition.
Lamport defines an irreflexive partial ordering among events in a program execution called happened-before, written !. Two events ei, e j of a particular execution are ordered, i.e., ei !e j, if (1) they belong to the same thread and are ordered in the control flow of this thread, or (2) ei and e j belong to different threads and some inter-thread synchronization (e.g., locking, thread start or join) forced ei to occur before e j. According to Netzer and Miller , two events ei and e
j

participate in a data race, if (1) the events belong to different threads, (2) the events access the same variable, and (3) at least one event corresponds to a write and (4) the events are not ordered according to the happened-before relation.

1.3 Motivation
Using these three novel pointcuts, programmers can easily implement bug-finding algorithms that detect errors related to concurrency. The lock() and unlock() pointcuts allow a programmer to uniformly act on any acquisition and release of a lock using synchronized blocks and methods in any Java program. The programmer can use the maybeShared() pointcut to gain runtime efficiency by monitoring accesses to only those fields that may be shared among threads.

1.3.1 Abbreviations Module Description

The K9 Rover and Executive The Race on ActionExecution.status The Races on syncNum and syncNumOpt The Races between the RuntimeExecutive, TheExecTimer, and ExecCondChecker

The K9 Rover and Executive: The K9 Rover is an experimental hardware platform for autonomous wheeled rovers, targeted for the exploration of a planetary surface such as Mars. K9 was specifically used to experiment with new autonomy software. Rovers are traditionally controlled by low-level commands uploaded from Earth. The K9 Executive, a software module, provides a more flexible means of commanding a rover through the use of high-level plans in a domain-specific

programming language. High-level plans can, for example, be generated by an on-board AIbased planner. The Executive is essentially an interpreter for the plan language

The Race on ActionExecution.status To indicate a data race on a variable status in class ActionExectution, RACER issues the message. The ActionExecution thread and the Runtime Executive thread cause this race because they both access status without both first acquiring a common lock. This is exactly the error planted in the code during the original verification experiment

The Races on syncNum and syncNumOpt We will not show the error messages from RACER for the remaining data races. The two data racesmentioned in this section stem from an experimentperformed with the K9 Executive (after the case study from) in order to determine how effectively a static analysis algorithm could reduce the number of locking operations TheExecTimer and ExecCondChecker we show the situation between the two threads RuntimeExecutive and ExecTimer that cause another seven data races which RACER reported on the K9 Executive. The Main thread starts both these threads.

1.4 Overview
We have proposed a language extension to the aspect-oriented programming language AspectJ. We extend AspectJ with three new pointcuts lock(), unlock(), and maybeShared(). These pointcuts allow researchers to easily implement bug-finding algorithms for errors related to concurrency. As an example, we have implemented RACER, an adaption of the ERASER race-detection algorithm to the Java memory model. We found that, using our AspectJ extension, we were able to implement RACER very easily, in just two aspects with a small set of supporting classes. The RACER algorithm is different from C-based race detection algorithms like ERASER in the way that it treats object initialization. ERASER is very forgiving

to programmers in an objects initialization phase. RACER, on the other hand, detects and also reports races that comprise the initialization of an object.

2. LITERATURE SURVEY
INTRODUCTION

AspectJ Compiler representation:

These approaches are characterized by the roles and obligations of programmer, compiler, and runtime system to determine the correctness of the synchronization.

2.1 Terminology We adopt the terminology and notation from Choi et al. A program execution is defined as a sequence e0, . . . ,en of events where ei is defined as a tuple ho, f , t,L,ki: i is a unique id. o is the object instance (or class) that is being accessed. f is the field variable that is accessed inside the object. t is the thread accessing the object. L is the set of locks being held during the access. k is the kind of event (one of {READ,WRITE,LOCK,UNLOCK,START,JOIN}). Events shall not only be used to model variable access, but also lock and unlock, as well as thread start and join; for such events, the accessed field variable f is void. 2.2 Data races A critical section is a statement sequence that should execute without interference of other threads. The concept is useful to guarantee that access from different threads to the same data is ordered, avoiding inconsistency and data corruption. Races are used to characterize situations where the guarantee about non-interference of threads accessing shared data is violated. Netzer and Miller distinguish data races that refer to unsynchronized access of shared data and general races that are sources of nondeterminism in parallel programs in general. Our discussion in this section focuses on data races, while Section discusses synchronization defects related to general races.

Intuitive definition. An intuitive definition of a data race is that different threads access the least one access is a write, and the access events are not ordered in the flow of the execution. Static detection. The set of data races that are possible by the nature of a program (i.e., all possible executions) is called feasible data races . In an ideal world, one would like to define and detect precisely the feasible data races based on a static program representation (static detection). The multitude of patterns and mechanisms for data sharing and thread synchronization make it however difficult to conceive such a data race definition that matches the intuitive concept. The following results from complexity and computability analysis show that a precise analysis of the synchronization structure in concurrent programs is computationally intractable or even impossible: Taylor shows that various synchronization-sensitive analyses (those that consider only the possible interleavings and execution paths of a parallel program with rendezvous style synchronization) are NP-complete for programs without procedures and recursion. Ramalingam extends this result for programs with (recursive) procedures and shows that any context-sensitive, synchronization-sensitive static analysis is undecidable. Hence, practical static data race checkers provide an approximation and have the potential of covering all feasible data races however at the risk of reporting incidents that do not correspond to feasible program executions (overreporting, spurious data races); the reports of such a static tool are called apparent races. illustrates the conceptual relationship between data races and the findings of a typical static detection mechanism; the extent of the boxes does not reflect the multitude of incidents or reports. same data, at

2.2. DATA RACES According to, an ideal static checker should have the following properties: Soundness. A sound checker reports an error if there is some error in the program (no underreporting). Not all errors need to be reported according to this definition, e.g., a race detection tool is still sound if it omits reports of races that are a consequence of another race. Completeness. A checker that is complete reports only genuine errors, not spurious incidents (no overreporting).

Dynamic detection. Due to the difficulty of defining and analyzing data races based on a program representation, common data race definitions and detection mechanism have focused on program executions. An actual data race is the occurrence of a data race in a program execution. Dynamic detection determines actual data races. Current techniques of dynamic data race detection are afflicted with two sources of inaccuracy: Underreporting means that actual races are omitted in the reporting (omitted data race); overreporting means that there are reports that do not correspond to real data races (spurious data race); illustrates this discrepancy between reported and actual respectively feasible data races. We discuss three important variants of data race definitions that are relevant in this dissertation. The definitions differ in their approximation of ordering among execution events and in the granularity of data that is subsumed by an access event. For each data race definition, static and dynamic detection mechanisms are presented and assessed according to their accuracy and runtime efficiency.

2.2.1 Happened-before data races

Definition. Lamport defines an irreflexive partial ordering among events in a program execution called happened-before, written !. Two events ei, e
j

of a particular execution are

ordered, i.e., ei !e j, if (1) they belong to the same thread and are ordered in the control flow of this thread, or (2) ei and e j belong to different threads and some inter-thread synchronization (e.g., locking, thread start or join) forced ei to occur before e j. According to Netzer and Miller , two events ei and e j participate in a data race, if (1) the events belong to different threads, (2) the events access the same variable, and (3) at least one event corresponds to a write and (4) the events are not ordered according to the happened-before relation. Detection. There are basically two implementation alternatives for dynamic data race detection: Trace-based techniques record relevant events at runtime and determine data races during an offline analysis of the execution trace. Online techniques limit the amount of trace data and verify condition at runtime. Due to the limited context for inferring the happened-before relation (only a limited window of access events can be tracked by an online checker), online techniques are usually less precise than trace-based systems; moreover, the temporal ordering of access events is approximated through the occurrence of synchronization events at runtime, which

introduces scheduling dependence into the detector and might lead to omitted reports. An important approach to improve the accuracy of online checkers for programs with lock-based synchronization has been proposed in and has led to the lock-based definition of data races. Besides accuracy, the execution overhead of online checkers, which is typically a factor of 5 to 100 of the original execution, is a major concern. Mellor-Crummey uses compile-time information to avoid unnecessary checking of accesses to thread-local data in Fortran programs. Christiaens and de Bosschere have investigated object-oriented programs and avoid the checking of accesses to objects that are reachable only from a single thread; in their system,object reachability with respect to threads is determined dynamically. Compiler optimizations 2.2. DATA RACES and runtime tuning improve the overhead of online happened-before data race checkers to a factor of 2 to 20.

2.2.2 Lock-based data races The difficulty to infer the happened-before relation from a program execution has led to another definition of data races that is not based on the temporal ordering of events but on a locking policy. The rationale behind unique-lock data races is that accesses to shared mutable variables that are consistently protected by a unique lock cannot be involved in a data race. Definition. Let E(o, f ) be the set of events that access field f on object o. A unique-lock data race on the variable o. f is defined as uniqueLockRace(o, f ) , 9ei,e j 2 E(o, f ) : ei.t 6= e j.t ^ (2.2) 9ei 2 E(o, f ) : ei.a = WRITE^ \e2E(o, f )e.L = /0. This data race definition is suitable for programs that base their synchronization on locks and monitors which is common for object-oriented parallel programs. characterizes a conservative set of actual data races in a program execution: A complete set of access events to the same variable that are not ordered through monitor style synchronization is identified; there could be over reporting because the events might be ordered through other means of synchronization. This definition is however not practical, because several common and correct synchronization patterns violate the locking policy: initialization without lock, shared read-only data, and read-write

locks. Consequently, implementations that check for unique lock data races extend the uniquelock data race definition and delay the checking of the locking policy, until a variable is accessed by a second thread. This extension might lead to underreporting because the thread scheduler could arrange the access events of different threads such that the data race is hidden; the technique is however frequently applied in practice because it has been demonstrated that the risk of underreporting is low and worthwhile in the light of a significant reduction of spurious reports. The implementation of the more practical locking policy associates a lockset and state with each variable. The state specifies if the variable has been accessed by more than one thread (shared) and whether the second thread performed a write; the lockset records the locks that have been held during all access and is initialized as soon as a variable is accessed by more than one thread. At every access e, the lockset associated with variable is refined through intersection with set of locks e.L held during e. A report is generated if the lockset got empty, if the variable is in the shared state, and a write has been seen since the variable has become shared. Detection. The original implementation of a lock-based data race detection (Eraser) is based on a binary instrumentation of all memory access instructions that may target global or heap memory; this instrumentation causes slow down by factor of 10 and 30. Subsequent research has developed systems that exploit program analysis to reduce the amount of instrumentation and the runtime overhead. A significant improvement has been achieved by our early work on object race detection that used a simple escape analysis to reduce the program instrumentation and caused a runtime overhead of 16% to 129%. A further improvement in efficiency is achieved by Choi et. al.; their system actually checks for a refined version of unique-lock data races (common-lock data races ) and uses several static and dynamic techniques to reduce the overhead of dynamic data race detection for typical Java programs below 50%. One importants part of the system is the static data race detection that we discuss, along with other static analyses for race detection.

2.2.3 Object races

The data race definitions in previous sections defined the granularity of the detection as the smallest memory-coherent unit or individual variable. Object (data) races coarsen the granularity of this view for object-oriented programs and define locations as objects. This is justified because the fields of shared objects are typically accessed in the same locking context.

The coarsening of the memory granularity in the view of the checker enables runtime optimizations that reduce the frequency of dynamic checks.

Definition. Let E(o) be the set of events that access some field on object o. Object races are defined as a variant of unique-lock data races: objectRace(o) , 9ei,e j 2 E(o) : ei.t 6= e j.t ^ (2.3) 9ei 2 E(o) : ei.a = WRITE^ \e2E(o)e.L = /0. Detection. We describe and evaluate the system for object race detection in detail in Section 7.

Conclusion The data race definitions identify a conservative set of actual data races in a program execution. The definitions are however not operational, i.e., some of the predicates must be approximated from the observations in an execution trace. This can lead to overreporting. Practical mechanisms for data race detection use heuristics to assess the ordering among accesses. The heuristics may err (even if this is uncommon) and introduce hence unsoundness: Potential of underreporting is accepted in favor of a significant reduction of spurious reports that would be given if a conservative approximation of access ordering was used. Two important sources of inaccuracy of dynamic data race checkers are (1) their approximation of the temporal ordering relation (happened-before based checkers) and (2) the delayed checking until some data is accessed by more than one thread (unique-lock and object race checkers). illustrates the detection capabilities of different techniques for dynamic data race checking. None of the approaches covers all actual data races, and all approaches have the potential of overreporting. The choice of data race definition and the design of the dynamic checker should be adjusted to the synchronization mechanisms that are used in a program. Generally, happened-before based techniques are preferable for programs with post-wait, rendez-vous, or fork-join style synchronization; lock-based detectors are more appropriate for programs with monitor style synchronization. Static data race detection can provide a conservative approximation of feasible data races in a program and is hence useful to narrow the scope of dynamic detection mechanisms. The use of data races as a correctness criterion for programs or program executions

is not attractive in practice due to the absence of a precise detection mechanism.

2.3 Violations of atomicity Synchronization is not only used to prevent data races at the level of individual variables but also used to ensure non-interference for an access sequence. Access statements that ought to execute atomically form a critical section that can be understood as a macro-statement in theview of a thread scheduler. Critical sections as a unit execute atomically but, like statements, without order. Netzer and Miller refer to this phenomenon, which is the principal source of non-determinism in concurrent programs, as general race. If critical sections are too finegrained, undesired interference on shared data can occur although there is no data race.

Definition. A method is atomic if the effect of its execution is independent of the effects of concurrent threads. In particular, shared data that is accessed by a thread t in the dynamic scope of a method m must not be updated by concurrent threads as long as t executes m.

Examples. Consider the example of a bank account in Program 2.3: The shared variable balance is accessed under common lock protection and hence there is no data race. The structure of locking specifies that the lock associated with the Account instance protects either a read or a write of field balance. Method update applies this synchronization discipline, however it performs a read and a write and hence cannot be atomic. A lost-update problem can occur if multiple threads access an Account instance and execute method update, which is itself not a critical section, concurrently. Program 2.4 shows the example of a data structure that has atomic methods but includes a potential data race on variable size. Programs 2.3 and 2.4 demonstrate that the properties of race freedom and atomicity are incomparable.

2.4 Deadlock Definition. A (resource) deadlock situation occurs at runtime if threads use synchronization so that a mutual wait condition arises. Some deadlock definitions are more general and consider any situation without progress, e.g., the awaiting of an external communication interaction, as deadlock. Our focus is on resource deadlock.

Detection. Dependencies among processes and resources can be modeled in a bipartite resource allocation graph. Nodes correspond to processes and exclusive resources, edges from processes to resources stand for a wait-for relation, and edges between resources and processes represent current-use relations. The basic principle of dynamic deadlock detection is to record and update such a graph at runtime. If the graph becomes cyclic, a deadlock is detected. Variations of this simple algorithm have been developed for distributed systems where a unique global view of the system in a resource allocation graph is difficult to determine and maintain at runtime. In Java, resource deadlock can occur through mutual dependencies among threads in the usage of locks. Recent Java runtime environments track the monitor ownership of threads in a data structure that resembles the resource allocation graph and determine deadlock through cycle detection. We describe and evaluate a static technique to detect potential resource deadlock in Chapter.

2.5 Trails to correct synchronization This section discusses different development approaches of concurrent software. First, we categorize the approaches and discuss their strategies to address the problem of synchronization defects. Second, we argue about the correctness criteria that are applicable to assess correct synchronization in each approach. Third, we emphasize and discuss the approach that is pursued in this dissertation. Canonical approaches. Figure 2.4 illustrates canonical approaches along their flexibility to express synchronization patterns and their susceptibility to synchronization defects. (A) In the programmer-centric approach, the programmer is exposed to a variety of language features that allow to explicitly control multi-threading and synchronization. The correct application of these features is left to the programmer. While this approach offers the widest flexibility in the design of concurrent systems, it has important shortcomings: Compiler and runtime technology are mostly adopted from sequential environments such that tools that assess concurrency and synchronization defects are not integrated in them development process. The debugging of synchronization defects is mostly done with conventional techniques. The programmer-centric approach is current practice for the development of multi-threaded Java and C] applications today. (B) The compiler and runtime controlled approach offers the same flexibility for the programmer

in the use of concurrency features as the programmer-centric approach. However, the compiler and runtime system reason about the structure of parallelism and synchronization, and determine potential synchronization defects. For the example of data races, the assessment through the compiler can lead to three situations: (1) The report of the compiler reflects an actual synchronization defect that is corrected by the programmer. (2) The compiler issues a report that is identified as benign by the programmer. The programmer communicates the synchronization intention through an annotation to the compiler, which in turn relaxes its rules for checking in this situation. (3) The compiler report is ignored by the programmer and a dynamic checker determines the occurrence of synchronization defect at runtime. (C) In the language-centric approach, certain classes of synchronization defects (data races, deadlock) are ruled out by the design of the type system. Examples are the programming language Guava, and type extensions of Java like or . These languages require that the programmer specifies the synchronization discipline explicitly through type annotations and declaration modifiers. Some systems allow to infer a large number of annotations automatically , or provide appropriate defaults to match the common

TRAILS TO CORRECT SYNCHRONIZATION The language-centric approach is a promising and attractive direction to address the problem of synchronization defects. However, these systems force the software designer to use the synchronization models that can be type-checked, and some popular and efficient, lock-free synchronization patterns are not accommodated.1 In addition, it is unclear if the specific locking discipline that is imposed by the type system and requires, e.g., lock protection for access to all potentially shared mutable data structures, is well amenable to program optimization and high performance in concurrent software systems. Hence it will be a while until language-centric approaches to concurrency control become widely accepted. (D) In the synthesized approach, the view of the programmer is confined to sequential programming and parallelism is automatically synthesized through the compiler. Such autoparallelizing compilers employ dependence analysis, discover computations without data interference that can be executed concurrently, and finally generate efficient parallel programs. Vectorization, e.g., has been successful along this procedure: Vectorizing compilers typically focus on loops and exploit concurrent execution features of synchronous processor architectures

(SIMD). The transfer of auto-parallelization to asynchronous multiprocessors (MIMD) has however brought new challenges. Parallel execution is done in separate threads, and current hardware and OS systems cause a critical overhead in managing threads and shared data. The focus on loops is often not sufficient and compilers are compelled to unveil new opportunities and larger scopes for parallel execution. For object-oriented programs, dependence analysis is complicated through the use of dynamic data structures and the effects of aliasing. Hence speculative approaches have been conceived that can be successful to improve the performance of programs where static dependence analysis fails. The synthesized approach to parallelism is conceptually appealing because synchronization defects cannot occur by design. The challenges posed through modern processor architectures and applications are however hard and manifold. Hence automated or speculative parallelization are often not as effective as techniques where parallelism is specified explicitly by the programmer. The scope of the dependence analysis and speculation is usually limited to local program constructs, and hence automated parallelization is not successful for programs where independent computational activities can be separated at a high-level in the system design. Kennedy argues that ... it is now widely believed that (auto)parallelization, by itself, is not enough to solve the parallel programming problem.

Correct synchronization. We have presented three important classes of synchronization defects (data races, violations of atomicity, and deadlock). Based on their definitions, we would like to conclude with a notion of correctness for parallel programs that reflects the absence of such synchronization defects. For the synthesized approach (D), the correctness criterion is to preserve the semantics of the initial sequential program. The presence of data races or atomicity violations is an implementation aspect. In the language-centric approach (C), correctness criteria are explicitly stated by the programmer and verified by the type checker. Most type systems focus on specific synchronization defects, and hence the scope of the check is limited, e.g., to the absence of data races and deadlock. For the programmer-centric (A) and the compiler- and runtime controlled (B) approach, a precise notion of correctness is difficult to achieve: First, there is no explicit definition of the synchronization discipline in a program, and the structure of synchronization is generally difficult to determine from the program text. Current object-oriented programming languages

like Java and C], e.g., offer low-level features that allow for a large variety of inter-thread synchronization mechanism; such mechanisms and their synchronization effect are not easily recognized by a static analysis. Second, the given definitions do not allow to draw a clear line between benign and harmful incidents: The different detection mechanisms of data races have incomparable reporting capabilities that are neither sound nor complete. These aspects make the three classes of synchronization defects a guideline rather than a correctness criterion.

Compiler and runtime controlled concurrency. This dissertation pursues the compiler and runtime controlled approach to concurrency. The approach is founded on a cooperation of programmer, compiler, and runtime system; the roles and challenges of the individual participants respectively constituents are discussed in the following: The programmer specifies parallelism and synchronization explicitly, and preferably follows certain synchronization patterns that are recognized by the compiler. In cases where the compiler is unable to infer the intention of the programmer, the programmer can provide annotations (e.g., type modifiers like final or volatile) to avoid unnecessary conservatism in the downstream tool chain (compiler and runtime). The compiler analyzes the program and reports potential incidents for different classes of synchronization defects. The challenges are to avoid underreporting, and at the same time to minimize the number of false positives due to conservatism. Reports presented to the user should be aggregated and concisely specify the class and source of the problem. The runtime system is responsible to check residual cases of potential faults that are not resolved by the programmer. The challenge is to avoid underreporting while making the checker efficient.

2.5 Technology Used

General A programming tool or software tool is a program or application that software developers use to create, debug, maintain, or otherwise support other programs and applications. The term usually refers to relatively simple programs that can be combined together to accomplish a task. The Chapter describes about the software tool that is used in our project.

Java Technology Initially the language was called as oak but it was renamed as Java in 1995. The primary motivation of this language was the need for a platform-independent (i.e., architecture neutral) language that could be used to create software to be embedded in various consumer electronic devices. Java is a programmers language. Java is cohesive and consistent. Except for those constraints imposed by the Internet environment, Java gives the programmer, full control. Finally, Java is to Internet programming where C was to system programming.

Importance of Java t o the Internet Java has had a profound effect on the Internet. This is because; Java expands the Universe of objects that can move about freely in Cyberspace. In a network, two categories of objects are transmitted between the Server and the Personal computer. They are: Passive information and Dynamic active programs. The Dynamic, Self-executing programs cause serious problems in the areas of Security and probability. But, Java addresses those concerns and by doing so, has opened the door to an exciting new form of program called the Applet. Java can be used to c reate two types of programs Applications and Applets : An application is a program that runs on our Computer under the operating system of that computer. It is more or less like one creating using C or C++. Javas ability to create Applets makes it important. An Applet is an application designed to be transmitted over the Internet and executed by a Java compatible web browser. An applet is actually a tiny Java program, dynamically downloaded across the network, just like an image. But the difference is, it is an intelligent program, not just a media file. It can react to the user input and dynamically change. Features of Java Security

Every time you that you download a normal program, you are risking a viral infection. Prior to Java, most users did not download executable programs frequently, and those who did scan them for viruses prior to execution. Most users still worried about the possibility of

infecting their systems with a virus. In addition, another type of malicious program exists that must be guarded against. This type of program can gather private information, such as credit card numbers, bank account balances, and passwords. Java answers both these concerns by providing a firewall between a network application and your computer. When you use a Java-compatible Web browser, you can safely download Java applets without fear of virus infection or malicious intent.
Portability

For programs to be dynamically downloaded to all the various types of platforms connected to the Internet, some means of generating portable executable code is needed .As you will see, the same mechanism that helps ensure security also helps create portability. Indeed, Javas solution to these two problems is both elegant and efficient.
The Byte code

The key that allows the Java to solve the security and portability problems is that the output of Java compiler is Byte code. Byte code is a highly optimized set of instructions designed to be executed by the Java run-time system, which is called the Java Virtual Machine (JVM). That is, in its standard form, the JVM is an interpreter for byte code. Translating a Java program into byte code helps makes it much easier to run a program in a wide variety of environments. The reason is, once the run-time package exists for a given system, any Java program can run on it. Although Java was designed for interpretation, there is technically nothing about Java that prevents on-the-fly compilation of byte code into native code. Sun has just completed its Just In Time (JIT) compiler for byte code. When the JIT compiler is a part of JVM, it compiles byte code into executable code in real time, on a piece-by-piece, demand basis. It is not possible to compile an entire Java program into executable code all at once, because Java performs various run-time checks that can be done only at run time. The JIT compiles code, as it is needed, during execution.

Java Virtual Machine (JVM)

Beyond the language, there is the Java virtual machine. The Java virtual machine is an important element of the Java technology. The virtual machine can be embedded within a web browser or an operating system. Once a piece of Java code is loaded onto a machine, it is verified. As part of the loading process, a class loader is invoked and does byte code verification makes sure that the code thats has been generated by the compiler will not corrupt the machine that its loaded on. Byte code verification takes place at the end of the compilation process to make sure that is all accurate and correct. So byte code verification is integral to the compiling and executing of Java code.
Overall Description

Picture showing the development process of JAVA Program Java programming uses to produce byte codes and executes them. The first box indicates that the Java source code is located in a. Java file that is processed with a Java compiler called javac. The Java compiler produces a file called a. class file, which contains the byte code. The .Class file is then loaded across the network or loaded locally on your machine into the execution environment is the Java virtual machine, which interprets and executes the byte code. Java Architecture Java architecture provides a portable, robust, high performing environment for development. Java provides portability by compiling the byte codes for the Java Virtual Machine, which is then interpreted on each platform by the run-time environment. Java is a dynamic system, able to load code when needed from a machine in the same room or across the planet. Compilation of code When you compile the code, the Java compiler creates machine code (called byte code) for a hypothetical machine called Java Virtual Machine (JVM). The JVM is supposed to execute the byte code. The JVM is created for overcoming the issue of portability. The code is

written and compiled for one machine and interpreted on all machines. This machine is called Java Virtual Machine.

Compiling and interpreting Java Source Code

Java PC Compiler Java

Source Code .. ..
SPARC (Platform Independe nt) Macintosh Compiler Byte code

Interpreter (PC) Java Interpreter (Macintosh) Java Interpreter (Spare)

..

Compiler

During run-time the Java interpreter tricks the byte code file into thinking that it is running on a Java Virtual Machine. In reality this could be a Intel Pentium Windows 95 or SunSARC station running Solaris or Apple Macintosh running system and all could receive code from any computer through Internet and run the Applets. Simple Java was designed to be easy for the Professional programmer to learn and to use effectively. If you are an experienced C++ programmer, learning Java will be even easier.

Because Java inherits the C/C++ syntax and many of the object oriented features of C++. Most of the confusing concepts from C++ are either left out of Java or implemented in a cleaner, more approachable manner. In Java there are a small number of clearly defined ways to accomplish a given task. Object-Oriented Java was not designed to be source-code compatible with any other language. This allowed the Java team the freedom to design with a blank slate. One outcome of this was a clean usable, pragmatic approach to objects. The object model in Java is simple and easy to extend, while simple types, such as integers, are kept as high-performance non-objects. Robust The multi-platform environment of the Web places extraordinary demands on a program, because the program must execute reliably in a variety of systems. The ability to create robust programs was given a high priority in the design of Java. Java is strictly typed language; it checks your code at compile time and run time. Java virtually eliminates the problems of memory management and de-allocation, which is completely automatic. In a well-written Java program, all run time errors can and should be managed by your program.

Servlets and Jsp

Java Servlet technology and JavaServer Pages (JSP pages) are server-side technologies that have dominated the server-side Java technology market; they've become the standard way to develop commercial web applications. Java developers love these technologies for myriad reasons, including: the technologies are fairly easy to learn, and they bring the Write Once, Run Anywhere paradigm to web applications. More importantly, if used effectively by following best practices, servlets and JSP pages help separate presentation from content. Best practices are proven approaches for developing quality, reusable, and easily maintainable servlet- and JSP-based web applications. For instance, embedded Java code (scriptlets) in

sections of HTML documents can result in complex applications that are not efficient, and difficult to reuse, enhance, and maintain. Best practices can change all that. In this article, I'll present important best practices for servlets and JSP pages; I assume that you have basic working knowledge of both technologies. This article:

Presents an overview of Java servlets and Java Server pages (JSP pages) Provides hints, tips, and guidelines for working with servlets and JSP pages Provides best practices for servlets and JSP pages

Overview of Servlets and JSP Pages Similar to Common Gateway Interface (CGI) scripts, servlets support a request and response programming model. When a client sends a request to the server, the server sends the request to the servlet. The servlet then constructs a response that the server sends back to the client. Unlike CGI scripts, however, servlets run within the same process as the HTTP server. When a client request is made, the service method is called and passed a request and response object. The servlet first determines whether the request is a GET or POST operation. It then calls one of the following methods: doGet or doPost. The doGet method is called if the request is GET, and doPost is called if the request is POST. Both doGet and doPost take request and response In the simplest terms, then, servlets are Java classes that can generate dynamic HTML content using print statements. What is important to note about servlets, however, is that they run in a container, and the APIs provide session and object life-cycle management? Consequently, when you use servlets, you gain all the benefits from the Java platform, which include the sandbox (security), database access API via JDBC, and cross-platform portability of servlets. JavaServer Pages (JSP) The JSP technology--which abstracts servlets to a higher level--is an open, freely available specification developed by Sun Microsystems as an alternative to Microsoft's Active

Server Pages (ASP) technology, and a key component of the Java 2 Enterprise Edition (J2EE) specification. Many of the commercially available application servers (such as BEA WebLogic, IBM WebSphere, Live JRun, Orion, and so on) support JSP technology. How Do JSP Pages Work? A JSP page is basically a web page with traditional HTML and bits of Java code. The file extension of a JSP page is .jsp rather than .html or .htm, which tells the server that this page requires special handling that will be accomplished by a server extension or a plug-in. When a JSP page is called, it will be compiled (by the JSP engine) into a Java servlet. At this point the servlet is handled by the servlet engine, just like any other servlet. The servlet engine then loads the servlet class (using a class loader) and executes it to create dynamic HTML to be sent to the browser, as shown in Figure 1. The servlet creates any necessary object, and writes any object as a string to an output stream to the browser.

Figure 1: Request/Response flow calling a JSP page

The next time the page is requested, the JSP engine executes the already-loaded servlet unless the JSP page has changed, in which case it is automatically recompiled into a servlet and executed.

Best Practices In this section, I present best practices for servlets and particularly JSP pages. The emphasis on JSP best practices is simply because JSP pages seem to be more widely used (probably because JSP technology promotes the separation of presentation from content). One best practice that combines and integrates the use of servlets and JSP pages is the Model View Controller (MVC) design pattern, discussed later in this article.
Don't overuse Java code in HTML pages:

Putting all Java code directly in the JSP page is OK for very simple applications. But overusing this feature leads to spaghetti code that is not easy to read and understand. One way to minimize Java code in HTML pages is to write separate Java classes that perform the computations. Once these classes are tested, instances can be created.
Choose the right include mechanism:

Static data such as headers, footers, and navigation bar content is best kept in separate files and not regenerated dynamically. Once such content is in separate files, they can be included in all pages using one of the following include mechanisms: Include directive: <%@ include file="filename" %> Include action: <jsp: include page="page.jsp" flush="true" />

The first include mechanism includes the content of the specified file while the JSP page is being converted to a servlet (translation phase), and the second include includes the response generated after the specified page is executed. I'd recommend using the include directive, which is fast in terms of performance, if the file doesn't change often; and use the include action for content that changes often or if the page to be included cannot be decided until the main page is executed. Another include mechanism is the action tag provided by the JavaServer pages Standard Tag Library (JSTL). You can use this tag to bring in, or import, content from local and remote sources. Here are some examples:

Don't mix business logic with presentation:

For advanced applications, and when more code is involved, it's important not to mix business logic with front-end presentation in the same file. However, production JSP code should be limited to front-end presentation. So, how do you implement the business logic part? That is where JavaBeans technology comes into play. This technology is a portable, platformindependent component model that lets developers write components and reuse them everywhere. In the context of JSP pages, JavaBeans components contain business logic that returns data to a script on a JSP page, which in turn formats the data returned from the JavaBeans component for display by the browser. A JSP page uses a JavaBeans component by setting and getting the properties that it provides. The benefits of using JavaBeans components to augment JSP pages are: 1. Reusable components: Different applications will be able to reuse the components. 2. Separation of business logic and presentation logic: You can change the way data is displayed without affecting business logic. In other words, web page designers can focus on presentation and Java developers can focus on business logic. 3. Protects your intellectual property by keeping source code secure. If you use Enterprise JavaBeans (EJBs) components with your application, the business logic should remain in the EJB components which provide life-cycle management, transaction support, and multi-client access to domain objects (Entity Beans). Please refer to the Enterprise BluePrints for further details on this.
Use custom tags:

Embedding bits of Java code (or scriptlets) in HTML documents may not be suitable for all HTML content developers, perhaps because they do not know the Java language and don't care to learn its syntax. While JavaBeans components can be used to encapsulate much of the Java code, using them in JSP pages still requires content developers to have some knowledge of Java syntax.

JSP technology allows you to introduce new custom tags through the tag library facility. As a

Java developer, you can extend JSP pages by introducing custom tags that can be deployed and used in an HTML-like syntax. Custom tags also allow you to provide better packaging by improving the separation between business logic and presentation logic. In addition, they provide a means of customizing presentation where this cannot be done

Some of the benefits of custom tags are: They can eliminate scriptlets in your JSP applications. Any necessary parameters to the tag can be passed as attributes or body content, and therefore no Java code is needed to initialize or set component properties. They have simpler syntax. Scriptlets are written in Java code, but custom tags can be used in an HTML-like syntax. They can improve the productivity of nonprogrammer content developers, by allowing them to perform tasks that cannot be done with HTML. They are reusable. They save development and testing time. Scriptlets are not reusable, unless you call cut-and-paste "reuse." The following programming guidelines are handy when writing custom tag libraries: Keep it simple: If a tag requires several attributes, try to break it up into several tags. Make it usable: Consult the users of the tags (HTML developers) to achieve a high degree of usability. Do not invent a programming language in JSP pages: Do not develop custom tags that allow users to write explicit programs. Try not to re-invent the wheel: There are several JSP tag libraries available, such as the Jakarta Taglibs Project. Check to see if what you want is already available.
Do not reinvent the wheel: While custom tags provide a way to reuse valuable components, they

still need to be created, tested, and debugged. In addition, developers often have to reinvent the wheel over and over again and the solutions may not be the most efficient. This is the problem

that the JavaServer Pages Standard Tag Library (JSTL) solves, by providing a set of reusable standard tags. JSTL defines a standard tag library that works the same everywhere, so you no longer have to iterate over collections using a scripted (or iteration tags from numerous vendors). The JSTL includes tags for looping, reading attributes without Java syntax, iterating over various data structures, evaluating expressions conditionally, setting attributes and scripting variables in a concise manner, and parsing XML documents.
Use the JSTL Expression Language: Information to be passed to JSP pages is communicated using

JSP scoped attributes and request parameters. An expression language (EL), which is designed specifically for page authors, promotes JSP scoped attributes as the standard way to communicate information from business logic to JSP pages. Note, however, that while the EL is a key aspect of JSP technology, it is not a general purpose programming language. Rather, it is simply a data access language, which makes it possible to easily access (and manipulate) application data without having to use scriptlets or request-time expression values.

In JSP 1.x, a page author must use an expression <%= aName %> to access the value of a system, as in the following example:

<someTags:aTag attribute="<%= pageContext.getAttribute ("aName") %>">

An expression language allows a page author to access an object using a simplified syntax. For example, to access a simple variable, you can use something like: And to access a nested JavaBeans property, you would use something like: If you've worked with JavaScript, you will feel right at home, because the EL borrows the JavaScript syntax for accessing structured data.
Use filters if necessary: One of the new features of JSP technology is filters. If you ever come

across a situation where you have several servlets or JSP pages that need to compress their content, you can write a single compression filter and apply it to all resources. In Java BluePrints, for example, filters are used to provide the SignOn.

Use a portable security model: Most application servers provide server- or vendor-specific

security features that lock developers to a particular server. To maximize the portability of your enterprise application, use a portable web application security model. In the end, however, it's all about tradeoffs. For example, if you have a predefined set of users, you can manage them using form-based login or basic authentication. But if you need to create users dynamically, you need to use container-specific APIs to create and manage users. While container-specific APIs are not portable, you can overcome this with the Adapter design pattern.
Use a database for persistent information: You can implement sessions with an Http Session

object, which provides a simple and convenient mechanism to store information about users, and uses cookies to identify users. Use sessions for storing temporary information--so even if it gets lost, you'll be able to sleep at night. (Session data is lost when the session expires or when the client changes browsers.) If you want to store persistent information, use a database, which is much safer and portable across browsers.
Cache content: You should never dynamically regenerate content that doesn't change between

requests. You can cache content on the client-side, proxy-side, or server-side.

Use connection pooling: I'd recommend using the JSTL for database access. But if you wish to

write your own custom actions for database access, I'd recommend you use a connection pool to efficiently share database connections between all requests. However, note that J2EE servers provide this under the covers.
Cache results of database queries: If you want to cache database results, do not use the JDBC's

Result Set object as the cache object. This is tightly linked to a connection that conflicts with the connection pooling. Copy the data from a ResultSet into an application-specific bean such as Vector, or JDBC's RowSets.
Adopt the new JSP XML syntax if necessary. This really depends on how XML-compliant you want

your applications to be. There is a tradeoff here, however, because this makes the JSP more toolfriendly, but less friendly to the developer.

Read and apply the Enterprise BluePrints: Sun's Enterprise BluePrints provide developers with

guidelines, patterns, and sample applications, such as the Adventure Builder and Pet Store. Overall, the J2EE BluePrints provide best practices and a set of design patterns, which are proven solutions to recurring problems in building portable, robust, and scalable enterprise Java applications. Integrating Servlets and JSP Pages The JSP specification presents two approaches for building web applications using JSP pages: JSP Model 1 and Model 2 architectures. These two models differ in the location where the processing takes place. In Model 1 architecture, as shown in Figure 2, the JSP page is responsible for processingi requests and sending back replies to clients.

Figure 2: JSP Model 1 Architecture

The Model 2 architecture, as shown in Figure 3, integrates the use of both servlets and JSP pages. In this mode, JSP pages are used for the presentation layer, and servlets for processingi tasks. The servlet acts as a controller responsible for processingi requests and creating any beans needed by the JSP page. The controller is also responsible for deciding to which JSP page to forward the request. The JSP page retrieves objects created by the servlet and extracts dynamic content for insertion within a template.

Figure 3: JSP Model 2 Architecture

This model promotes the use of the Model View Controller (MVC) architectural style design pattern.. The Apache Struts is a formalized framework for MVC. This framework is best used for complex applications where a single request or form submission can result in substantially different-looking results. Conclusion Best practices -- which are proven solutions to recurring problems -- lead to higher quality applications. This article presented several guidelines and best practices to follow when developing servlet- and JSP-based web applications. Keep an eye on servlets and JSP technologies, because several exciting things are in the works. JavaServer Faces (JFC), for example, a Java Community Process effort that aims to define a standard web application framework, will integrate nicely with Apache Struts.

Oracle 10g
. 10g is Oracle's grid computing product group including (among other things) a database

management system (DBMS) and an application server. In addition to supporting grid computing features such as resource sharing and automatic load balancing, 10g products automate many database management tasks. The Real Application Cluster (RAC) component makes it possible to install a database over multiple servers

Oracle Data Dictionary Concepts

The data dictionary is full of Metadata, information about what is going-on inside your database. The data dictionary is presented to us in the form of a number of views. The dictionary views come in two primary forms: The DBA, ALL or USER views These views are used to manage database structures. These views are used to monitor real time database statistics Throughout the rest of this book we will introduce you to data dictionary views that you can use to manage your database. You will find the entire list of Oracle Data Dictionary views documented in the Oracle documentation online. There are hundreds of views in the data dictionary. To see the depth of the data dictionary views, here are the views that store data about Oracle tables: * dba_all_tables * dba_indexes * dba_ind_partitions * dba_ind_subpartitions * dba_object_tables * dba_part_col_statistics * dba_subpart_col_statistics * dba_tables * dba_tab_cols * dba_tab_columns * dba_tab_col_statistics * dba_tab_partitions * dba_tab_subpartitions

3. SYSTEM ANALYSIS
One interesting research topic is the exploitation of users profiles and behaviour models in the data mining process, in order to provide personalized answers. The Web mining (Kosala & Blockeel, 2000) is a data mining process applied to the Web. Vast quantities of information are available on the Web and Web mining has to cope with its lack of structure. Web mining can extract patterns from data trough content mining, structure mining and usage mining. Content mining is a form of text mining applied to Web pages. This process allows to discover relationships related to a particular domain, co-occurrences of terms in a text, etc. Knowledge is extracted from a Web page. Structure mining is used to examine data related to the structure of a Web site. This process operates on Web pages hyperlinks. Structure mining can be considered as a specialisation of Web content mining. Web usage mining is applied to usage information such as logs files. A log file contains information related to the queries executed by users to a particular Web site. Web usage mining can be used to modify the Web site structure or give some recommendations to the visitor. Personalisation can also be enhanced by usage analysis The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in systems engineering, information systems and software engineering, is the process of creating or altering systems, and the models and methodologies that people use to develop these systems. In software engineering the SDLC concept underpins many kinds of software development methodologies. These methodologies form the framework for planning and controlling the creation of an information system the software development process. SOFTWARE MODEL OR ARCHITECTURE ANALYSIS:

SDLC Methodology: This document play a vital role in the development of life cycle (SDLC) as it describes the complete requirement of the system. It means for use by developers and will be the basic during testing phase. Any changes made to the requirements in the future will have to go through formal change approval process. SPIRAL MODEL was defined by Barry Boehm in his 1988 article, A spiral Model of Software Development and Enhancement. This model was not the first model to discuss iterative

development, but it was the first model to explain why the iteration models. As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with a client reviewing the progress thus far. Analysis and

engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project. The steps for Spiral Model can be generalized as follows: The new system requirements are defined in as much details as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system. A preliminary design is created for the new system. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product. A second prototype is evolved by a fourfold procedure: 1. Evaluating the first prototype in terms of its strengths, weakness, and risks. 2. Defining the requirements of the second prototype. 3. Planning an designing the second prototype. 4. Constructing and testing the second prototype.

At the customer option, the entire project can be aborted if the risk is deemed too great. Risk factors might involved development cost overruns, operating-cost miscalculation, or any other factor that could, in the customers judgment, result in a less-than-satisfactory final product.

The existing prototype is evaluated in the same manner as was the previous prototype, and if necessary, another prototype is developed from it according to the fourfold procedure outlined above.

The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.

The final system is constructed, based on the refined prototype. The final system is thoroughly evaluated and tested. Routine maintenance is carried on a continuing basis to prevent large scale failures and to minimize down time.

ADVANTAGES: Estimates(i.e. budget, schedule etc .) become more relistic as work progresses, because important issues discoved earlier. It is more able to cope with the changes that are software development generally entails. Software engineers can get their hands in and start woring on the core of a project earlier.

The following diagram shows how a spiral model acts like:

Fig 1.0-Spiral Model

Existing Algorithm: PROGRAMMING errors occur frequently in software systems, and therefore, researchers have spent much effort on developing methods to detect and remove such errors as easily and early as possible in the development process. Concurrent programs are even more likely to suffer from programming errors as concurrent programming adds potential sources of failure. In a concurrent program, a programmer has to make sure to avoid deadlocks, to properly protect shared state from data races, and to protect single threads or processes from starvation. Researchers have developed specialized static and dynamic analyses to aid programmers with these tasks. Disadvantages: Concurrent programs are even more likely to suffer from programming errors as concurrent programming adds potential sources of failure.

Proposed System: Matching the first two point cuts against a given program is decidable. The problem of matching the maybe Shared() point cut is, however, generally un decidable. We therefore compute a sound over approximation using a static thread-local-objects analysis. The approximation assures that the point cut matches every access to a field that is indeed shared. Because of the over approximation, the point cut may, however, also match accesses to fields that are not actually shared, i.e., fields that only a single thread accesses. Using these three novel point cuts, programmers can easily implement bug-finding algorithms that detect errors related to concurrency. The lock () and unlock() point cuts allow a programmer to uniformly act on any acquisition and release of a lock using synchronized blocks and methods in any Java program. The programmer can use the may be Shared() point cut to gain runtime efficiency by monitoring accesses to only those fields that may be shared among threads. To demonstrate the feasibility of

the approach, we implemented the three novel point cuts as an extension to the Aspect Bench Compiler. To show how programmers can use this language extension, we adapted the ERASER race detection algorithm to Java, and implemented it using the new point cuts. The new algorithm is named RACER. Both ERASER and RACER detect program executions which reveal potential for data races in the executed application.

Advantages: An additional advantage of using AspectJ is that we could easily modify the Locking aspect to take other locking styles into account. For instance, if Reentrant- Locks were used we could just extend the pointcuts in with an additional disjunct.

3.4 FEASIBILITY STUDY

Preliminary investigation examine project feasibility, the likelihood the system will be useful to the organization. The main objective of the feasibility study is to test the Technical, Operational and Economical feasibility for adding new modules and debugging old running system. All system is feasible if they are unlimited resources and infinite time. There are aspects in the feasibility study portion of the preliminary investigation: Technical Feasibility Operational Feasibility Economical Feasibility

3.4.1 ECONOMIC FEASIBILITY A system can be developed technically and that will be used if installed must still be a good investment for the organization. In the economical feasibility, the development cost in creating the system is evaluated against the ultimate benefit derived from the new systems. Financial benefits must equal or exceed the costs. The system is economically feasible. It does not require any addition hardware or software. Since the interface for this system is developed using the existing resources and

technologies available at NIC, There is nominal expenditure and economical feasibility for certain.

3.4.2 OPERATIONAL FEASIBILITY Proposed projects are beneficial only if they can be turned out into information system. That will meet the organizations operating requirements. Operational feasibility aspects of the project are to be taken as an important part of the project implementation. Some of the important issues raised are to test the operational feasibility of a project includes the following: Is there sufficient support for the management from the users? Will the system be used and work properly if it is being developed and implemented? Will there be any resistance from the user that will undermine the possible application benefits? This system is targeted to be in accordance with the above-mentioned issues. Beforehand, the management issues and user requirements have been taken into consideration. So there is no question of resistance from the users that can undermine the possible application benefits. The well-planned design would ensure the optimal utilization of the computer resources and would help in the improvement of performance status.

4.3 TECHNICAL FEASIBILITY The technical issue usually raised during the feasibility stage of the investigation includes the following: Does the necessary technology exist to do what is suggested? Do the proposed equipments have the technical capacity to hold the data required to use the new system? Will the proposed system provide adequate response to inquiries, regardless of the number or location of users? Can the system be upgraded if developed? Are there technical guarantees of accuracy, reliability, ease of access and data security?

Earlier no system existed to cater to the needs of Secure Infrastructure Implementation System. The current system developed is technically feasible. It is a web based user interface for audit workflow at NIC-CSD. Thus it provides an easy access to the users. The databases purpose is to create, establish and maintain a workflow among various entities in order to facilitate all concerned users in their various capacities or roles. Permission to the users would be granted based on the roles specified. Therefore, it provides the technical guarantee of accuracy, reliability and security. The software and hard requirements for the development of this project are not many and are already available in-house at NIC or are available as free as open source. The work for the project is done with the current equipment and existing software technology. Necessary bandwidth exists for providing a fast feedback to the users irrespective of the number of users using the system.

3.5 Algorithm Racer Algorithm:

when method execution accesses field f if (f is uninitialized) { if (f is reference field of type T) { non-deterministically initialize f to null a new object of class T (with uninitialized fields) an object created during prior field initialization (alias) } if (f is numeric/string field) initialize f to a new symbolic value }

4. SYSTEM REQUIREMENTS SPECIFICATION

4.1 INTRODUCTION
One interesting research topic is the exploitation of users profiles and behaviour models in the data mining process, in order to provide personalized answers. The Web mining (Kosala &

Blockeel, 2000) is a data mining process applied to the Web. Vast quantities of information are available on the Web and Web mining has to cope with its lack of structure. Web mining can extract patterns from data trough content mining, structure mining and usage mining. Content mining is a form of text mining applied to Web pages. This process allows to discover relationships related to a particular domain, co-occurrences of terms in a text, etc. Knowledge is extracted from a Web page. Structure mining is used to examine data related to the structure of a Web site. This process operates on Web pages hyperlinks. Structure mining can be considered as a specialisation of Web content mining. Web usage mining is applied to usage information such as logs files. A log file contains information related to the queries executed by users to a particular Web site. Web usage mining can be used to modify the Web site structure or give some recommendations to the visitor. Personalisation can also be enhanced by usage analysis.

4.2 PURPOSE
Web mining can be useful to add semantic annotations (ontologies) to Web documents and to populate these ontological structures. As stated below, Web content and Web usage mining should be combined to extract ontologies and to adapt them to the usage. Ontology creation and evolution require the extraction of knowledge from heterogeneous sources. In the case of the Semantic Web, the knowledge extraction is done from the content of a set of Web pages dedicated to a particular domain. Web pages are semi-structured information. Web usage mining extracts navigation patterns from Web log files and can also extract information about the Web site structure and user profiles. Among Web usage mining applications, we can point out personalization, modification and improvement of Web site, detailed description of a Web site usage. The combination of Web content and usage mining could allow to build ontologies according to Web pages content and refine them with behaviour patterns extracted from log files. Web usage mining provides more relevant information to users and it is therefore a very powerful tool for information retrieval. Another way to provide more accurate results is to involve users in the mining process, which is the goal of visual data mining, described in the next section

I.

FUNCTIONAL REQUIREMENTS

1. Start the Racerpro server. 2. To run the web application 3. To display the home page 4. Select any one of the OWL file representation process 5. To get that tags of representation process 6. Select any one of the tag. 7. To identify the instances representation process. 8. To display the number of urls representation process.

4.4 NON FUNCTIONAL REQUIREMENTS

The major non-functional Requirements of the system are as follows Usability The system is designed with completely automated process hence there is no or less user intervention. Reliability The system is more reliable because of the qualities that are inherited from the chosen platform java. The code built by using java is more reliable.

Performance This system is developing in the high level languages and using the advanced front-end and back-end technologies it will give response to the end user on client system with in very less time. Supportability The system is designed to be the cross platform supportable. The system is supported on a wide range of hardware and any software platform, which is having JVM, built into the system. Implementation The system is implemented in web environment using struts framework. The apache tomcat is used as the web server and windows xp professional is used as the platform. Interface the user interface is based on Struts provides HTML Tag

4.5 HARDWARE REQUIREMENTS

System Hard Disk Floppy Drive Monitor Mouse Ram : : : : : : Pentium IV 2.4 GHz. 40 GB. 1.44 Mb. 15 VGA Color. Logitech. 512 MB.

4.6 SOFTWARE REQUIREMENTS

Operating System Technology Framework Web Technologies IDE Web Server Database Softwares

: : : : : : : :

Windows xp , Linux Java Struts Html, JavaScript, CSS My Eclipse8.0 Tomcat 5.5 Oracle J2SDK1.5, Oracle 9i

5. SYSTEM DESIGN
5.1 SYSTEM SPECIFICATIONS OBJECTIVES
The objective of this sub-project is to develop tools and methods to support the earlier phases of systems development; for implementation independent specification and verification, and for subsequent synthesis of specifications into efficient implementations. The sub-project is divided into four sub-tasks: i) adopt/further develop a model for formal, high-level system specification and verification. ii) Demonstrate the efficacy of the developed model by applying it to a suitable part of the consortium demonstrator, the network terminal for broadband access. iii) Develop a systematic method to refine the specification into synthesizable code and a prototype tool which supports the refinement process and links it to synthesis and compilation tools.

Justification
Today it is common to specify systems on higher levels using some natural language (e.g. English). For large systems, where large amounts of information must be handled, problems arise with ambiguities and inconsistencies with such specifications. Errors that are introduced are often detected late in the design cycle - in the simulation of the design after much design work has already been carried out - if detected at all. By making the initial system specifications in a formal language at a high abstraction level, functionality can be verified/simulated earlier in the development process. Ambiguities and inconsistenciescan be avoided, errors can be discovered earlier, and the design iteration cycles can beshortened, thereby reducing development times. It is of critical importance that the

Architecture:

specification language provides modelling concepts at a high abstraction level to allow the representation of system functions at a conceptual level without introducing unnecessary details.

Further, most of the languages that are used for implementation of HW / SWdesigns (e.g. VHDL, C++) do not lend themselves well to formal verification. This is because they lack a formally defined semantics or because the semantics is complex. A lack of formal semantics sometimes causesambiguities in the interpretation of the designs. Our goal is to develop functional system specification method for telecom systems, to demonstrate its efficacy on an industrially relevant example and to develop a tool to support the mapping of such specifications to synthesizable VHDL/C++. The specification language in which the system level functions will be developed will have a formal semantics in order to support formal verification of specifications.

5.2 SYSTEM COMPONENTS:

The diagram shows a general view of how desktop and workstation computers are organized. Different systems have different details, but in general all computers consist of components (processor, memory, controllers, video) connected together with a bus. Physically, a bus consists of many parallel wires, usually printed (in copper) on the main circuit board of the computer. Data signals, clock signals, and control signals are sent on the bus back and forth between components. A particular type of bus follows a carefully written standard that describes the signals that are carried on the wires and what the signals mean. The PCI standard (for example) describes the PCI bus used on most current PCs.
KEYBOARD MOUSE JOYSTICK SCANNER SCANNING DEVICE DIGITIZING TABLET TOUCH-SENSITIVE SCREEN MICROPHON

5.3 UML Diagrams

UML DIAGRAMS:

The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems. The UML is a very important part of developing objects oriented software and the software development process. The UML uses mostly graphical notations to express the design of software projects. Using the UML helps project teams communicate, explore potential designs, and validate the architectural design of the software. Types of UML DIAGRAMS Each UML diagram is designed to let developers and customers view a software system from a different perspective and in varying degrees of abstraction. UML diagrams commonly created in visual modeling tools include Use Case Diagram displays the relationship among actors and use cases Class Diagram models class structure and contents using design elements such as classes, packages and objects. It also displays relationships such as containment, inheritance, associations and others. Interaction Diagrams

Sequence Diagram displays the time sequence of the objects participating in the interaction. This consists of the vertical dimension (time) and horizontal dimension (different objects)

Collaboration Diagram displays an interaction organized around the objects and their links to one another. Numbers are used to show the sequence of messages.

State Diagram displays the sequences of states that an object of an interaction goes through during its life in response to received stimuli, together with its responses and actions.

Activity Diagram displays a special state diagram where most of the states are action states and most of the transitions are triggered by completion of the actions in the source states. This diagram focuses on flows driven by internal processing. Physical Diagrams

Component Diagram displays the high level packaged structure of the code itself. Dependencies among components are shown, including source code components, binary code components, and executable components. Some components exist at compile time, at link time, at run times well as at more than one time.1

Deployment Diagram displays the configuration of run-time processing elements and the software components, processes, and objects that live on them. Software component instances represent run-time manifestations of code

Use Case Diagram: A use case diagram in the Unified Modeling Language (UML) is a type of behavioral diagram defined by and created from a Use-case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals , and any dependencies between those use cases. Actor You can picture an actor as a user of the IT system, for example Mr. Steel or Mrs. Smith from check-in. Because individual persons are irrelevant for the model, they are abstracted. So the actors are called check-in employee or passenger:

Actors represent roles that users take on when they use the IT system, e.g., the role of a check-in employee. One person can act in more than one role toward the IT system. It is important for the IT system in which role a person is acting. Therefore, it is necessary to log on to many IT systems in a certain role, for instance, as a normal user or as an administrator. In each case access to the appropriate functionalities (use cases) is granted. Actors themselves are not part of the IT system. However, as employees they can be part of the business system (see Figure 4.5). Use Case Use cases describe the interactions that take place between actors and IT systems during the execution of business processes:

A use case represents a part of the functionality of the IT system and enables the user (modeled as an actor) to access this functionality. Anything that users would like to do with the IT system has to be made available as a use case (or part of a use case). Functionalities that exist in the IT system, but that are not accessed by means of use cases, are not available to users. Even though the idea behind use cases is to describe interactions, flows of batch processing, which generally do not include interactions, can also be described as use cases. The actor of such a batch use case is then the one who initiates batch processing. For instance, generating check-in statistics would be a batch use case. Relationships:

Association An association is a connection between an actor and a use case. An association indicates that an actor can carry out a use case. Several actors at one use case mean that each actor can carry out the use case on his or her own and not that the actors carry out the use case together:

According to UML, association only means that an actor is involved in a use case. We use associations in a restricted manner In this Diagram Working Two Actor in different task 1. User 2. Admin

Start the RacerPro software

select any one of the owl file

display the concepts of information

select any one of the concept User identify the instance and roles of represenation

based on the instance to identify the results

Sequence Diagram:

Squence

diagrammes

blong

to

group

of

UML

diagrams

called

Interaction

Diagrammes. Sequence diagrams describe how objects interact over the course of time through an exchange of messages. A single sequence diagram often represents the flow of events for a single use case. Instance: An instance of a class shows a sample configuration of an object. On the sequence diagram, each instance has a lifeline box underneath it showing it's existence over a period of time. Actor: An actor is anything outside the system that interacts with the system. It could be a user or another system. Message: The message indicates communication between objects. The order of messages from top to bottom on your diagram should be the order in which the messages occur. Sequence diagrams: In this Diagram there are eight Object Interaction to other Objects 1.Sequence digram:

User

start the RacerPro

OWL file

concepts

instances

results

1 : start the server()

2 : select that any one of the owl file()

3 : to identify the concepts()

4 : invalid()

5 : based on the concept to identify the instance()

6 : based on the instance to identify the results()

Sequence diagram

Collaboration Diagram:
Collaboration diagrams belong to a group of UML diagrams called Interaction Diagrams . Collaboration diagrams, like Sequence Diagrams, show how objects interact over the course of time. However, instead of showing the sequence of events by the layout on the diagram, collaboration diagrams show the sequence by numbering the messages on the diagram. This makes it easier to show how the objects are linked together, but harder to see the sequence at a glance. Instance: An instance of a class shows a sample configuration of an object. On the sequence diagram, Eich instance has a life line box underneath it showing itsa existence over a period of Collaboration diagrams: in this Diagram eight instance

Collaboration diagram:

results

6 : based on the instance to identify the results()

instances

5 : based on the concept to identify the instance() 4 : invalid() concepts

3 : to identify the concepts()

OWL file

start the RacerPro

1 : start the server() 2 : select that any one of the owl file()

User

Collaboration diagram

Class Diagram:
Class diagrams are widely used to describe the types of objects in a system and their relationships. Class diagrams model class structure and contents using design elements such as classes, packages and objects. Class diagrams describe three different perspectives when designing a system, conceptual, specification, and implementation. These perspectives become evident as the diagram is created and help solidify the design. This Diagram Show the relationship between tables There are Six Table in this Diagram

Class diagram:

Class diagram:

STATE CHART DIAGRAM Introduction State diagrams are used to describe the behavior of a system. State diagrams describe all of the possible states of an object as events occur. Each diagram usually represents objects of a single class and track the different states of its objects through the system. When to Use: State Diagrams Use state diagrams to demonstrate the behavior of an object through many use cases of the system. Only use state diagrams for classes where it is necessary to understand the behavior of the object through the entire system. Not all classes will require a state diagram and state diagrams are not useful for describing the collaboration of all objects in a use case. State diagrams are other combined with other diagrams such as interaction diagrams and activity diagrams. 1 How to Draw: State Diagrams State diagrams have very few elements. The basic elements are rounded boxes representing the state of the object and arrows indicting the transition to the next state. The activity section of the state symbol depicts what activities the object will be doing while it is in that state.

STATE CHART DIAGRAM State Chart Diagram: in this diagrams there are five state

Apply the racer algorithm

to indentify the XML schema

indentify the concepts of information

based on the concept to derive the instances and roles

based on the instances to identify the meaningful results

State Chart Diagram:

ACTIVITY DIAGRAM

Introduction Activity diagrams describe the workflow behavior of a system. Activity diagrams are similar to state diagrams because activities are the state of doing something. The diagrams describe the state of activities by showing the sequence of activities performed. Activity diagrams can show activities that are conditional or parallel. Activity diagrams describe the workflow behavior of a system. Activity diagrams are similar to state diagrams because activities are the state of doing something. The diagrams describe the state of activities by showing the sequence of activities performed. Activity diagrams can show activities that are conditional or parallel. Activity diagrams should be used in conjunction with other modeling techniques such as interaction diagrams and state diagrams. The main reason to use activity diagrams is to model the workflow behind the system being designed. Activity Diagrams are also useful for: analyzing a use case by describing what actions need to take place and when they should occur; describing a complicated sequential algorithm; and modeling applications with parallel processes.

start the server

select the owl file

select any one of the concept

select any one of the instance

to generate the results of information

Activity diagrams

5.3 Data Flow Diagrams:

A graphical tool used to describe and analyze the moment of data through a system manual or automated including the process, stores of data, and delays in the system. Data Flow Diagrams are the central tool and the basis from which other components are developed. The

transformation of data from input to output, through processes, may be described logically and independently of the physical components associated with the system. The DFD is also know as a data flow graph or a bubble chart. DFDs are the model of the proposed system. They clearly should show the requirements on which the new system should be built. Later during design activity this is taken as the basis for drawing the systems structure charts. The Basic Notation used to create a DFDs are as follows: 1. Dataflow: Data move in a specific direction from an origin to a destination.

2. Process: People, procedures, or devices that use or produce (Transform) Data. The physical component is not identified.

3. Source: External sources or destination of data, which may be People, programs, organizations or other entities.

4. Data Store: Here data are stored or referenced by a process in the System.

CONTEXT LEVEL DIAGRAM

Context Level DFD

user Data Storage Registration

admin Search the Content

Report

Login DFD

Login Master

Open Login Form

Enter Username Password

yse

Check username Password

yes

User Home Page

No

Validation Data

6. Implementation
6.1 Sample Code : RacerServer.java
package jracer; import java.io.ByteArrayOutputStream; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; import java.io.PrintStream; import java.net.Socket; public class RacerServer {

/** The socket that enables communication with the racer server. */

private Socket racerSocket;

/** The input stream from the RACER server socket. */

private InputStream racerInputStream;

/** The output stream to the RACER server socket. */

private PrintStream racerOutputStream;

/** The IP location where the racer server is located. */

private String racerServerIP;

/** The port used by the racer server. */

private int racerServerPort; private static final String SERVER_END_STRING = ":eof";

public RacerServer(String ip, int port) { racerServerIP = ip; racerServerPort = port;

} public void openConnection() throws IOException { racerSocket = new Socket(racerServerIP, racerServerPort); racerInputStream = racerSocket.getInputStream(); OutputStream out = racerSocket.getOutputStream(); racerOutputStream = new PrintStream(out, true); }

public void closeConnection() throws IOException { if (racerOutputStream != null) { racerOutputStream.print(SERVER_END_STRING); racerOutputStream.flush(); racerInputStream.close(); racerOutputStream.close(); racerOutputStream = null; } if (racerSocket != null) { racerSocket.close(); racerSocket = null; } }

/** This method reads a string from the racer socket connection. */

private static String readFromSocket(InputStream in) throws IOException {

ByteArrayOutputStream baos = new ByteArrayOutputStream(); int c = in.read(); baos.write(c); while (c != 10) { c = in.read(); if (c != 10) { baos.write(c); }

} return baos.toString();

public String send(String command) throws RacerException, IOException { racerOutputStream.println(command); String result = readFromSocket(racerInputStream); return parseResult(command, result); } protected String parseResult(String message, String result) throws RacerException { // return null if the result is ok if (result.charAt(1) == 'o') { String warning = getWarningFromOK(result); if (warning != null)

printWarning(warning); return null; } // we check whether it has been an error and throw an exception if (result.charAt(1) == 'e') { String error = getError(result); throw new RacerException(error); } // otherwise, we check whether the result is an answer and retrieve the // answer if (result.charAt(1) == 'a') { String[] ansAndWar = getResultAndWarningFromAnswer(result); if (ansAndWar[1] != null) printWarning(ansAndWar[1]); return ansAndWar[0]; } // unknown answer throw new RacerException("RACER MESSAGE: " + message + "; produced a RACER answer unknown: " + result); } protected String getError(String result) { String s = new String(); int iniMessage = result.indexOf(' ', 7); int ini = result.indexOf('"', iniMessage); int fi = result.indexOf('"', ini + 1);

s = iniMessage + 1 < ini - 1 ? result .substring(iniMessage + 1, ini - 1) : ""; if (iniMessage + 1 < ini - 1 && ini + 1 < fi) s = s + ". "; s = s + result.substring(ini + 1, fi); return s; } protected String[] getResultAndWarningFromAnswer(String result) { String[] s = new String[2]; int ini = result.indexOf('"', 10); int fi = ini; boolean esFinal = false; while (!esFinal) { fi = result.indexOf('"', fi + 1); esFinal = result.charAt(fi - 1) != '\\'; } s[0] = result.substring(ini + 1, fi); if (fi + 4 < result.length()) s[1] = result.substring(fi + 3, result.length() - 1); return s; } protected String getWarningFromOK(String result) { String warning = null; int ini = result.indexOf('"', 6); int fi = result.length() - 1;

if (ini < fi - 1) warning = result.substring(ini + 1, fi); return warning; } protected void printWarning(String warning) { for (int i = 0; i < warning.length(); i++) { char c = warning.charAt(i); if (c == (char) 9) System.out.println(); else System.out.print(warning.charAt(i)); } System.out.println(); }

RacerConnect.java
package com.know; import java.io.IOException; import java.util.StringTokenizer; import java.util.Vector; import jracer.RacerException; import jracer.RacerServer; public class RacerConnect { RacerServer racer1;

public RacerConnect(String string) { try { string = string.replace("\\", "/"); System.out.println(string); String str = "(owl-read-file\"" + string + "\")"; racer1 = new RacerServer("localhost", 8088); racer1.openConnection(); racer1.send(str); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (RacerException e) { // TODO Auto-generated catch block e.printStackTrace(); } }

public Vector<String> getConcepts() { // TODO Auto-generated method stub Vector<String> ret = null; try { ret = new Vector<String>(); String concepts = racer1.send("(all-atomic-concepts)"); System.out.println(concepts); StringTokenizer st = new StringTokenizer(concepts, "#| ()");

while (st.hasMoreElements()) { String tok = st.nextToken(); if (!tok.startsWith("http:")) ret.add(tok); } racer1.closeConnection(); } catch (RacerException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } return ret; }

public String getInduals(String ind) { // TODO Auto-generated method stub String ret = null; try {

String concepts = racer1.send("(describe-individual |#"+ind+"|)"); System.out.println(concepts); ret=concepts; racer1.closeConnection();

} catch (RacerException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } return ret; }

public Vector<String> getRoles() { // TODO Auto-generated method stub Vector<String> ret = null; try { ret = new Vector<String>(); String roles = racer1.send("(all-roles)"); System.out.println(roles); StringTokenizer st = new StringTokenizer(roles, "()"); String temp=""; while (st.hasMoreElements()) { temp = st.nextToken().trim(); } st = new StringTokenizer(temp, "| |"); while (st.hasMoreElements()) { temp = st.nextToken().trim();

ret.add(temp); System.out.println(temp); } racer1.closeConnection(); } catch (RacerException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } return ret; } public Vector<String> getInvRoles() { // TODO Auto-generated method stub Vector<String> ret = null; try { ret = new Vector<String>(); String roles = racer1.send("(all-roles)"); System.out.println(roles); StringTokenizer st = new StringTokenizer(roles, "()"); String temp=""; while (st.hasMoreElements()) { temp = st.nextToken().trim(); ret.add(temp);

} racer1.closeConnection(); } catch (RacerException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } return ret; } public Vector<String> getInstances(String cons) { // TODO Auto-generated method stub Vector<String> ret=new Vector<String>(); try { System.out.println("-------------Instances----------------"); String queryResult = racer1.send("(concept-instances |#"+cons.trim()+"|)"); //String queryResult = racer1.send("(retrieve-concept-instances |#Technique|)"); System.out.println("-------------Instances----------------"); //System.out.println(queryResult); StringTokenizer st = new StringTokenizer(queryResult, "#|"); while (st.hasMoreElements()) { String temp = st.nextToken().trim(); if (!(temp.startsWith("http") || temp.startsWith("(") || temp.startsWith(")") || temp.equals(""))) {

//System.out.println(temp); ret.add(temp); } } racer1.closeConnection(); } catch (RacerException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } return ret; } }

Test.java
package com.know; import java.util.StringTokenizer; public class Test { public Test() { // TODO Auto-generated constructor stub String ss = "((inv |http://www.w3.org/2000/01/rdf-schema#comment|) " + "(inv |http://www.w3.org/2002/07/owl#comment|)" + " (inv |http://www.w3.org/2000/01/rdf-schema#seeAlso|)" + " (inv |http://www.w3.org/2002/07/owl#seeAlso|)"

+ " (inv |http://www.w3.org/2000/01/rdf-schema#isDefinedBy|) " + "(inv |http://www.w3.org/2002/07/owl#isDefinedBy|) " + "(inv |http://www.w3.org/2000/01/rdf-schema#label|)" + " (inv |http://www.w3.org/2002/07/owl#label|)" + " (inv |http://www.w3.org/2002/07/owl#versionInfo|) " + "(inv |http://lsdis.cs.uga.edu/library/resources/ontologies/swtopics.owl#topic_requires|) " + "(inv |http://lsdis.cs.uga.edu/library/resources/ontologies/swtopics.owl#topic_supports|)" + " (inv |http://lsdis.cs.uga.edu/library/resources/ontologies/swtopics.owl#topic_usesTechnique|)" + " (inv |http://lsdis.cs.uga.edu/library/resources/ontologies/swtopics.owl#topic_subtopic|) " + "(inv |http://lsdis.cs.uga.edu/library/resources/ontologies/swtopics.owl#topic_relatedTo|) " + "(inv |http://lsdis.cs.uga.edu/library/resources/ontologies/swtopics.owl#topic_relatedProjects|) " + "(inv |http://purl.org/dc/elements/1.1/description|)" + " (inv |http://purl.org/dc/elements/1.1/contributor|)" + " (inv |http://purl.org/dc/elements/1.1/identifier|)" + " (inv |http://purl.org/dc/elements/1.1/alternative|) " + "(inv |http://purl.org/dc/elements/1.1/title|) " + "(inv |http://lsdis.cs.uga.edu/library/resources/ontologies/swtopics.owl#topic_usedIn|) " + "|http://lsdis.cs.uga.edu/library/resources/ontologies/swtopics.owl#topic_usedIn| " + "|http://purl.org/dc/elements/1.1/title| |http://purl.org/dc/elements/1.1/alternative|" + " |http://purl.org/dc/elements/1.1/identifier| "

+ "|http://purl.org/dc/elements/1.1/contributor|" + " |http://purl.org/dc/elements/1.1/description| " + "|http://lsdis.cs.uga.edu/library/resources/ontologies/swtopics.owl#topic_relatedProjects|" +" |http://lsdis.cs.uga.edu/library/resources/ontologies/swtopics.owl#topic_relatedTo| " + "|http://lsdis.cs.uga.edu/library/resources/ontologies/swtopics.owl#topic_subtopic| " + "|http://lsdis.cs.uga.edu/library/resources/ontologies/swtopics.owl#topic_usesTechnique| " + "|http://lsdis.cs.uga.edu/library/resources/ontologies/swtopics.owl#topic_supports| " + "|http://lsdis.cs.uga.edu/library/resources/ontologies/swtopics.owl#topic_requires|" + " |http://www.w3.org/2002/07/owl#versionInfo|" + " |http://www.w3.org/2002/07/owl#label| " + "|http://www.w3.org/2000/01/rdf-schema#label| " + "|http://www.w3.org/2002/07/owl#isDefinedBy|" + " |http://www.w3.org/2000/01/rdf-schema#isDefinedBy| " + "|http://www.w3.org/2002/07/owl#seeAlso| " + "|http://www.w3.org/2000/01/rdf-schema#seeAlso|" + " |http://www.w3.org/2002/07/owl#comment| " + "|http://www.w3.org/2000/01/rdf-schema#comment|)"; StringTokenizer st = new StringTokenizer(ss, "()"); String temp=""; while (st.hasMoreElements()) { temp = st.nextToken().trim(); // if (!(temp.startsWith("http") || temp.startsWith("(")

// || temp.startsWith(")") || temp.startsWith("0") // || temp.equals("") || temp.contains("."))) { // System.out.println(temp); // // } // System.out.println(temp); } //System.out.println(temp); st = new StringTokenizer(temp, "| |"); while (st.hasMoreElements()) { temp = st.nextToken().trim(); System.out.println(temp); } }

/** * @param args */ public static void main(String[] args) { // TODO Auto-generated method stub new Test(); } Tools.java package com.know; import java.io.IOException;

import java.io.PrintWriter; import java.util.Vector; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.servlet.http.HttpSession; public class Tools { String file = ""; RacerConnect connect;

public Tools() { // TODO Auto-generated constructor stub }

public void setfile(PrintWriter out, HttpServletRequest request, HttpServletResponse response) { // TODO Auto-generated method stub Vector<String> ret = null; try { file = request.getParameter("owlfile");

connect = new RacerConnect(file); ret = connect.getConcepts();

} finally { try {

HttpSession ses = request.getSession(true); ses.setAttribute("Concepts", ret); response.sendRedirect(request.getRequestURL().substring(0, request.getRequestURL().lastIndexOf("servlet")) + "home.jsp"); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } }

public Vector<String> getVInstance() { System.out.println("file:" + file); Vector<String> ret = new Vector<String>(); return ret; }

public void setInverse(String inv) { System.out.println(inv); }

HttpSession role = null; HttpSession ins = null;

HttpSession invrole = null; String conpts="";

public void instances(PrintWriter out, HttpServletRequest request, HttpServletResponse response) { // TODO Auto-generated method stub try { String cons = request.getParameter("concepts"); conpts=cons; Vector<String> ret; Vector<String> roles;

connect = new RacerConnect(file); ret = connect.getInstances(cons); connect = new RacerConnect(file); roles = connect.getRoles(); System.out.println("cons1:" + ret); ins = request.getSession(true); ins.setAttribute("Instances", ret); role = request.getSession(true); role.setAttribute("Roles", roles); response.sendRedirect(request.getRequestURL().substring(0, request.getRequestURL().lastIndexOf("servlet")) + "home.jsp?r=rol"); } catch (Exception e) {

// TODO Auto-generated catch block e.printStackTrace(); public void invroles(PrintWriter out, HttpServletRequest request, HttpServletResponse response) { // TODO Auto-generated method stub try { Vector<String> invroles; connect = new RacerConnect(file); invroles = connect.getInvRoles(); System.out.println(invroles); invrole = request.getSession(true); invrole.setAttribute("InvRoles", invroles);

response.sendRedirect(request.getRequestURL().substring(0, request.getRequestURL().lastIndexOf("servlet")) + "home.jsp?r=invr"); } catch (Exception e) { // TODO Auto-generated catch block e.printStackTrace(); }} public void result(PrintWriter out, HttpServletRequest request, HttpServletResponse response) { // TODO Auto-generated method stub try { String ind=request.getParameter("ind").trim(); System.out.println("ind:"+ind);

connect = new RacerConnect(file); String ret=connect.getInduals(ind); HttpSession ses = request.getSession(true); ses.setAttribute("FRes", ret); response.sendRedirect(request.getRequestURL().substring(0, request.getRequestURL().lastIndexOf("servlet")) + "home.jsp?re=Result"); } catch (Exception e) { // TODO Auto-generated catch block e.printStackTrace(); }}

7. SYSTEM TESTING
TESTING STRATAGIES: Testing concepts: a. Testing b. Testing Methodologies Black box Testing: White box Testing. Gray Box Testing.

c. Level of Testing Unit Testing. Module Testing. Integration Testing. System Testing. User Acceptance Testing.

d. Types of Testing

Smoke Testing. Sanitary Testing. Regression Testing. Re-Testing. Static Testing. Dynamic Testing. Alpha-Testing. Beta-Testing. Monkey Testing. Compatibility Testing. Installation Testing. Adhco Testing. Etc.

Testing:

The process of executing a system with the intent of finding an error. Testing is defined as the process in which defects are identified, isolated, subjected for
rectification and ensured that product is defect free in order to produce the quality product and hence customer satisfaction.

Quality is defined as justification of the requirements Defect is nothing but deviation from the requirements Defect is nothing but bug. Testing --- The presence of bugs Testing can demonstrate the presence of bugs, but not their absence Debugging and Testing are not the same thing! Testing is a systematic attempt to break a program or the AUT Debugging is the art or method of uncovering why the script /program did not execute
properly.

7.1 Testing Methodologies

Black box Testing: is the testing process in which tester can perform testing on an application without having any internal structural knowledge of application. Usually Test Engineers are involved in the black box testing. White box Testing: is the testing process in which tester can perform testing on an application with having internal structural knowledge. Usually The Developers are involved in white box testing. Gray Box Testing: is the process in which the combination of black box and white box tonics are used. Levels of Testing:

Module1 Units

Module2 Units

Module3 Units

i/p

Integration o/p i/p

Integration o/p

System Testing: Presentation + business +Databases

UAT: user acceptance testing

Fig 11 STLC (SOFTWARE TESTING LIFE CYCLE)

Test Planning: 1. Test Plan is defined as a strategic document which

describes the procedure how to perform various testing on the total application in the most efficient way. 2. This document involves the scope of testing, 3. Objective of testing, 4. Areas that need to be tested,

5. Areas that should not be tested, 6. Scheduling Resource Planning, 7. Areas to be automated, various testing tools used. Test Development: 1. Test case Development (check list) 2. Test Procedure preparation (Description of the Test cases). 1. Implementation of test cases. Observing the result. Result Analysis: 1. Expected value: is nothing but expected behavior Of application. 2. Actual value: is nothing but actual behavior of application Bug Tracing: Reporting: Collect all the failed cases, prepare documents. Prepare document (status of the application)

7.2 Test cases

Test cases can be divided in to two types. First one is Positive test cases and second one is negative test cases. In positive test cases are conducted by the developer intention is to get the output. In negative test cases are conducted by the developer intention is to dont get the output. +VE TEST CASES S .No 1 Test case Description Create the new registration process Actual value Expected value Result

user New user created To update successfully database MSACESS

the True in

Enter the java programs Execute the total Identify the bugs True root directory for the structure of bugs of information. identification of fault using information. Dynamic test case generation process. Using HTML validator to Identify the bugs Bugs can be True specify the related bugs in position wise. identified as a report generation

finder generation process 4

process

Check the verification It can be contains It can be working True process of tags. the state manager as a constraint report process solver process

-VE TEST CASES S .No 1 Test case Description Create the new registration process Actual value Expected value Result

user New user can not There is no False be created updating process successfully of database That can be limited number of tags representation process Contains only False less number of tags specification process

Enter the java programs root directory for the identification of fault using Dynamic test case generation process.

Using HTML validator to It can be process specify the related bugs the execution finder generation process process like semi permanently

It can be False registered as a limited faults specification process False

Check the verification Constraint solver It should work process of tags. was not executed with less perfectly constraints generation process

Types of Testing: Smoke Testing: is the process of initial testing in which tester looks for the availability of all the functionality of the application in order to perform detailed testing on them. (Main check is for available forms) Sanity Testing: is a type of testing that is conducted on an application initially to check for the proper behavior of an application that is to check all the functionality are available before the detailed testing is conducted by on them. Regression Testing: is one of the best and important testing. Regression testing is the process in which the functionality, which is already tested before, is once again tested whenever some new change is added in order to check whether the existing functionality remains same. Re-Testing: is the process in which testing is performed on some functionality which is already tested before to make sure that the defects are reproducible and to rule out the environments issues if at all any defects are there. Static Testing: is the testing, which is performed on an application when it is not been executed. Ex: GUI, Document Testing Dynamic Testing: is the testing which is performed on an application when it is being executed. Ex: Functional testing. Alpha Testing: it is a type of user acceptance testing, which is conducted on an application when it is just before released to the customer. Beta-Testing: it is a type of UAT that is conducted on an application when it is released to the customer, when deployed in to the real time environment and being accessed by the real time users. Monkey Testing: is the process in which abnormal operations, beyond capacity operations are done on the application to check the stability of it in spite of the users abnormal behavior. Compatibility testing: it is the testing process in which usually the products are tested on the environments with different combinations of databases (application servers, browsersetc) In order to check how far the product is compatible with all these environments platform combination.

Installation Testing: it is the process of testing in which the tester try to install or try to deploy the module into the corresponding environment by following the guidelines produced in the deployment document and check whether the installation is successful or not. Adhoc Testing: Adhoc Testing is the process of testing in which unlike the formal

testing where in test case document is used, with out that test case document testing can be done of an application, to cover that testing of the future which are not covered in that test case document. Also it is intended to perform GUI testing which may involve the cosmetic issues.

7.3 Results and Discussions

SNAPSHOTS

Screenshots: RacerPro software execution steps: Start the RacerPro software process:

CONCLUSION AND FUTURE ENHANCEMENTS 8.1 Conclusion:

In this work, we have proposed a language extension to the aspect-oriented programming language AspectJ. We extend AspectJ with three new pointcuts lock(), unlock(), and maybeShared(). These pointcuts allow researchers to easily implement bug-finding algorithms for errors related to concurrency. As an example, we have implemented RACER, an adaption of the ERASER race-detection algorithm to the Java memory model. We found that, using our AspectJ extension, we were able to implement RACER very easily, in just two aspects with a small set of supporting classes. The RACER algorithm is different from C-based race detection algorithms like ERASER in the way that it treats object initialization. ERASER is very forgiving to programmers in an objects initialization phase. RACER, on the other hand, detects and also reports races that comprise the initialization of an object. This revealed 12 data races in program code of the NASA K9 Rover Executive, 11 of which went previously undetected, although extensive studies of this code had already been performed at a time when nine of these undetected races were already present.

REFERENCES: [1] J. Harrow, Runtime Checking of Multithreaded Applications with Visual Threads, SPIN Model Checking and Software Verification, K. Havelund, J. Penix, and W. Visser, eds., pp. 331342, Springer, 2000. [2] R. OCallahan and J.-D. Choi, Hybrid Dynamic Data Race Detection, Proc. ACM SIGPLAN Symp. Principles and Practice of Parallel Programming, pp. 167-178, 2003. [3] C. von Praun and T.R. Gross, Object Race Detection, Proc. Ann. ACM SIGPLAN Conf. Object-Oriented Programming, Systems, Languages, and Applications, pp. 70-82, 2001. [4] K. Havelund, Using Runtime Analysis to Guide Model Checking of Java Programs, SPIN Model Checking and Software Verification, pp. 245-264, Springer, 2000. [5] K. Havelund and G. Rosu, An Overview of the Runtime Verification Tool Java PathExplorer, Formal Methods in System Design, vol. 24, no. 2, pp. 189-215, 2004. [6] C. Artho, K. Havelund, and A. Biere, High-Level Data Races, Software Testing, Verification and Reliability, vol. 13, no. 4, pp. 207-227, 2003. [7] C. Artho, K. Havelund, and A. Biere, Using Block-Local Atomicity to Detect Stale-Value Concurrency Errors, Automated Technology for Verification and Analysis, F. Wang, ed., pp. 150-164, Springer, 2004. [8] C. Flanagan and S.N. Freund, Atomizer: A Dynamic Atomicity Checker for Multithreaded Programs, Proc. 31st ACM SIGPLANSIGACT Symp. Principles of Programming Languages, pp. 256-267, 2004. [9] L. Wang and S.D. Stoller, Run-Time Analysis for Atomicity, Electronic Notes in Theoretical Computer Science, vol. 89, no. 2, 2003. [10] F. Chen, T.F. Serbanuta, and G. Rosu, jPredictor: A Predictive Runtime Analysis Tool for Java, Proc. 30th Intl Conf. Software Eng., pp. 221-230, 2008.