Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Spring 2003 M6: Handle basic queries on system
To parse simple expressions in Smalltalk.
You now have quite a bit of data. To effectively retrieve that data, it would be nice to allow user's to construct custom queries on your system. In the world of databases, there is a standard language called Structured Query Language (SQL) to handle that task. For our application we are going to have a much reduced version of the language to allow user's to enter simple queries and get responses.
Here is a simple specification of the language. Note it is space delimited:
- <query> := <select_statement> | <report_statement>
- <select_statement> := SELECT <entity> WHERE <condition_statement>
- <entity> := PORTFOLIO | ACCOUNT
- <condition_statement> := <condition> | <condition> AND <condition_statement>
- <condition> := <name> <relop> <value>
- <name> := BALANCE | NUMBER | NAME ;
- <value> := "alphanumeric string of characters" | aNumber (Note double quotes surrounds string value)
- <relop> := > | < | =
- <report_statement> := REPORT <transaction_types> FOR <entity> WITH <account_id>
- <transaction_types> := NORMAL | FULL | EXCEPTION
- <account_id> := "alphanumeric string of characters"
Some sample queries:
Show me all the accounts where my balance is more than $100.
- SELECT ACCOUNT WHERE BALANCE > 100
What portfolios are COKE in?
What accounts do I have with First Union?
- SELECT PORTFOLIO WHERE NUMBER = "COKE"
Show me a normal transaction report for COKE.
- SELECT ACCOUNT WHERE NAME = "First Union"
- REPORT NORMAL FOR ACCOUNT WITH "COKE"
Clearly we could make the language more robust and complete, but this subset is enough to give you a feel for design issues and to experience parsing in smalltalk. You may parse queries using any technique you wish. You may write a simple custom parser or you may us TGen. How you implement the UI for supporting queries is a design decision that can generate interesting possibilities. In the most general case, you could just accept a raw character string and parse it to see if it is syntactically correct. You could also build queries graphically to try and minimize errors due to spelling. For instance our language only allows two keywords to start a query SELECT or REPORT thus we could force the user to choose only between these two. There are many other ways to allow input and handling of queries. Think about the advantages and disadvantages of each. Remember 50% of the grade is the DESIGN. Don't just start hacking something.
Turn-in your code using the Spring 2003 Turnin Information with the code 'M6'. Turn in your design in class.
(NOTE: A good design is VERY important here! It's okay if it's very different from P3 – we want to see that you thought it all through.)
- 10% Good Scenarios: Accounts for all major functions in assignment, touches on every class.
- 10% Good CRC card analysis: Reasonable names, understandable and clearly defined responsibilities, good exploration of other class names
- 10% Good test plan: equivalence classes clearly identified, test cases clearly defined.
- 10% Good UML class diagram: Correct usage of notation (3%), detailed and understandable descriptions and names (7%).
- 10% Quality of the design
- 50% Working system:
- 20% SELECT statement operation correct
- 10% SUnit tests.
- 20% REPORT statement operation correct.
Note: If the TAs can't figure out how to do these things, they don't have to give you the points. The UI must be usable.
Links to this Page