Java代写 | COM6102 Project: An indexing web browser

本次为COMP6102 Advance Programing之Java实现一个索引Web浏览器

COM6102 Project: An indexing web browser
Stage 2 Searching the index
The goal of stage 2 is to construct and process a simple query language which can be used to search the indexes for documents containing some logical combination of words.
In this occasion, you should modify slightly your program so that it accepts an additional command line argument providing a filename containing a list of queries:
WebTest [fileList.txt] [filenameWithListOfQueries.txt]
The text file [filenameWithListOfQueries.txt] will contain a list of individual queries, one per line. Details about the format of the queries is provided later in this handout. In this stage, you will use the queries in this file in conjunction with the test documents provided for stage 1 to produce a printed set of results for each (i.e., given a query, produce a list of matching URLs). Results should take the form of a list of matching URLs for each query string.
q Youshouldbecomfortablewithrecursivestructuresandalgorithms,interfacesandinheritance q YoushouldbefamiliarwithstringhandlingandtheJavaCollectionsFramework
A query can, in general, be regarded as an expression made up of operators such as ‘and’, ‘or’ and ‘not’ and a set of query terms. For instance, the following are all queries:
music and rock and roll
western and (not country)
punk or (new and wave)
(blues or jazz) and guitar
Handling query expressions in this form is complicated due to the need to identify which parts represent query operators, and then to find which query terms belong with each. The additional part involves processing queries in the above form. However, for the compulsory part, you will be dealing with a slightly simpler query syntax:
grunge and(music,rock,roll) and(western,not(country)) or(punk,and(new,wave)) and(or(blues,jazz),guitar)
Notice that the query has the form of a single term (e.g. grunge) or, more generally: QueryOperator(query1,query2,….,queryN)
where each of the sub-queries itself can be any query. Thus, the definition of a query is recursive.
Note, this is an individual assignment. You are not allowed to work in groups and your code must be all your own work. You may not use other peoples’ code or ideas, e.g., taken from the Internet.
Any form of unfair means (plagiarism or collusion) will be treated as a serious academic offence and will be processed under our University Discipline Regulations. These might result in a loss of marks, a possible failure of the module or even expulsion from our University.
For further details, please visit the PGT Student Handbook:

In this project, each query will return a set of URLs. The four query types act as follows:
1. ‘and’ represents the set intersection of the results returned by the constituent parts
2. ‘or’ represents the set union
3. ‘not’ represents the set difference between the set of all documents and the results returned by the query
inside the not (There can only be one query for the not operator, e.g., not(punk) is fine but not(punk,guitar) is
4. a single word matches all URLs whose document contains that word. We’ll refer to this case as an ‘atomic’
query in what follows. For simplicity, we disallow querying the operator names: ‘and’, ‘or’ and ‘not’.
The Query interface
The task of a query in general is to provide a set of matches against a WebIndex. We can represent this via an interface called Query, which mandates that any implementation must provide the matches method:
public interface Query {
public Set<WebDoc> matches(WebIndex wind); }
We can represent each of the four query types above using four classes each of which implement the Query interface. For example, an AndQuery class could represent its query as a list of Query instances. Its matches method would call the matches method of each of its Query instances and return their intersection. Note that since a Query instance may itself be an AndQuery, this may result in a recursive call.
You should provide implementations of each of the four query types in classes AtomicQuery, OrQuery, AndQuery and NotQuery. You should provide an appropriate toString method, which you can use to test your code.
The QueryBuilder class
A query is input as a String which must somehow be converted into a Query instance. Since a string query typically involves more than one Query subclass, the question arises of how and where to construct the Query. Situations like this are usually dealt with using a so-called Builder class. This class is responsible for parsing the query and thereby constructing a Query instance.
You should provide a QueryBuilder implementation which conforms to the following skeleton:
public class QueryBuilder {
public static Query parse(String q) { … }
For instance, calling the parse method on the query string “and(western,not(country))” would return an AndQuery instance whose contents are an AtomicQuery (for “western”) and a NotQuery which contains an instance of an AtomicQuery (for “country”).
Infix Form Input
In addition to the query input form described above, include another method in QueryBuilder with signature
public static Query parseInfixForm(String q) { … }
which builds queries from queries of the form
(A and B) or C
Note that the operators ‘and’ and ‘or’ must be applied to exactly two arguments in this syntax, unlike for the simpler prefix notation which should allow any number of arguments. When the brackets are omitted, this can give rise to ambiguity. For instance, ‘A and B or C’ could be interpreted as either of
A and (B or C) = and(A,or(B,C)) or (A and B) or C = or(and(A,B),C)

Programming languages have complex rules about operator precedence (typically and/&& binds tighter that or/||) but implementing these are beyond the scope of the assignment. Instead you can make (and document) an assumption about how these ambiguous situations are resolved. E.g., always bracketing to the left or the right.
To demonstrate that your code works, convert each of the queries for the compulsory part into infix form by hand, and then provide a printed output of the queries that are built by your infix query builder (hence you will need to provide sensible toString methods for each of the Query subclasses). You do not need to run the queries on the index again.
What to hand in via MOLE & interviews
As done in Stage 1, once you have finished this assignment, you should submit electronically via MOLE the following:
1. Your code in a zip file (not rar or any other compression format), including all your java source (.src)
and .class files.
2. A PDF document (not Word or any other format) with the following sections (maximum length of
report is 2 pages):
a. A class diagram showing all the classes and any relationships between them (max 1 page). 
If you
modified any classes from stage 1, then include class diagrams for them too.
b. A brief justification of the design of your classes (max 1/4 page).
c. A brief description and justification of your choice of collections framework objects used to store the
queries (max 1/2 page).
d. A summary explaining what you think you have learnt from this assignment (max 1/4 page).
Be honest and realistic.
After the submission deadline, you will need to demonstrate your code in a ~10-min session during the lab immediately after the submission (i.e. on the Tuesday 4-6pm time-slot). The exact interview times will be provided by the lecturer the day before.
During the demonstration, you will be interviewed by the lecturer and one of the lab demonstrators. You will be asked to run your program and to explain briefly what certain sections of the code are doing as well as to justify your choices.
On the demonstration day, you will be given access to another file with a different list of queries to the one provided with this handout. Please ensure that your code compiles, provides the required classes and methods, that your code works and your output is of the right format. A more strenuous test will be applied for marking, so you should not rely solely on the initial files provided.
Your solutions to the provided queries will be recorded by a demonstrator. As indicated earlier, you should therefore ensure that your output is in an easily-readable form.
Failure to demonstrate will result in loss of marks.
Assessment Criteria
Submissions will be assessed against the same criteria as for Stage 1, namely correct outputs (30%), sensible and efficient programming practices (40%), good object-oriented design, clear documentation and good coding style (25%), and demonstration (5%). See Stage 1 for details. As before, code that does not compile will be assigned a score of 0 and compiler warnings will attract a penalty.
You can check in MOLE the Coding Tips document for useful tips aimed at improving your coding skills.


本网站支持淘宝 支付宝 微信支付  paypal等等交易。如果不放心可以用淘宝交易!

E-mail: [email protected]  微信:itcsdx