Project Phase I Data Representation & EDI
The first phase of the project will focus on the design and implementation of several Java classes to model the various entities in the system. For the first phase, your classes may be simple data containers. Full behavior, methods, and the inheritance will be required in Phase II and you are encouraged to plan ahead for any modifications that you may need. Your classes will define, conceptually, what each of the entities are (their data and types and accessor/mutator methods) as well as provide means for creating and building instances of those entities.
You will also write a parser to process a collection of “flat” data files containing data on entities in the old system and build instances of each object. These files were dumped from the old system and are in a non-standard semi-colon and comma-separated value format.
Finally, you will also implement functionality to serialize your objects into a data interchange format. Specifically, you will serialize them to XML and/or JSON formats
2 Data Files
The data dumped from the old system is separated into several files. A full example of well-formatted input and acceptable output has been provided. However, you will also be required to develop your own non-trivial test case. In general, you may assume that all data is valid and properly formatted and all data files are named as specified. You should assume that all data files are located in a directory called data and output files should be saved to the same directory.
2.1 Persons Data File
Data pertaining to each person on the system is stored in a data file in data/Persons.dat . The format is as follows: the first line will contain a single integer indicating the total number of records. Each subsequent line contains semicolon delimited data fields:
Person Code – the unique alpha-numeric designation from the old system
Name – the person’s name in lastName,firstName format
Address – the mailing address of the person. The format is as follows:
Email Address(es) – an (optional) list of email addresses; if there are multiple email addresses, they will be delimited by a comma
2.2 Customer Data File
Data pertaining to each asset on the system is stored in a data file in data/Customers.dat . The format is as follows: the first line will contain a single integer indicating the total number of records. Each subsequent line contains semicolon-delimited data fields:
Customer Code – a unique alpha-numeric designation from the old system
Type – a single character indicating if the customer is a government ( G ) or Corporate ( C ) customer
Primary contact – a person code corresponding to the individual who serves as the customer’s primary contact
Name – the name of the customer
Address – the mailing address of the customer. The format is as follows:
2.3 Product Data File
Data pertaining to each product on the system is stored in a data file in data/Products.dat . The format is as follows: the first line will contain the total number of records (an integer). Each subsequent line contains semicolon delimited data fields depending on the type of product.
Equipment have the following format: code;E;name;pricePerUnit
Licenses have the following format: code;L;name;serviceFee;annualLicenseFee
Consultations have the following format: code;C;name;consultantPersonCode;hourlyFee
Note that for consultations, the person code is a reference to a particular person in the
You are required to design Java classes to model the entities above and hold the appropriate data. The classes you design and implement, their names, and how they relate to each other are design decisions that you must make. However, you should follow good object-oriented programming principles. In particular, you should make sure that your classes are designed following best practices.
In addition, your program will load data from the data files, construct (and relate) instances of your objects, and produce the appropriate output files.
It is your choice as to which format you produce, XML or JSON. For XML, your output file names should Persons.xml , Customers.xml and Products.xml; and for JSON, your output files should be Persons.json , Customers.json and Products.json respectively. Your output files should be placed in the same data directory as the input files.
There is no need to define a rigorous schema in either case. However, your XML/JSON should be well formatted and valid (in particular, you may need to escape certain characters). You should follow the general structures in the examples provided, though some flexibility is allowed for tag and element names. However, the output should conceptually match the expected output. It must also pass any and all validation tests (using the validators listed below). In addition, you may (in fact are encouraged to) use a library to convert your Java classes to XML and/or JSON if you wish. Some common libraries and more information on each of the formats can be found with the following resources:
W3C’s XML Tutorial: http://www.w3schools.com/xml/default.asp
An XML Validator: http://www.w3schools.com/xml/xml_validator.asp
JAXB, a standard Java-XML binding framework: http://www.oracle.com/technetwork/ articles/javase/index-140168.html
JSON Introduction: http://json.org/
A JSON Validator: http://jsonformatter.curiousconcept.com/
For this initial phase, your objects may be simple data containers since the only thing you are doing with them is parsing data files, creating object instances, and exporting them in a different format. However, much of the code you write in this phase will be useful in subsequent phases, so ensure that you have well-designed, robust, bug-free and reusable code.
You are expected to thoroughly test and debug your implementation using your own test case(s). To ensure that you do, you are required to design and turn in at least one non-trivial test case to demonstrate your program was tested locally to some degree. Ultimately your application will be tested on multiple test cases through webgrader.
Understand that the web grader is not a sufficient testing tool. Webgrader is a “black-box” tester: you don’t have access to its internals, to the test cases, nor can you debug with respect to it.
Also understand what a test case is: it is an input-output that is known to be good using a method independent of your program (calculated or verified by hand). We will use your test case when grading other assignments, so you are encouraged to be adversarial: design test cases to probe and break “bad” code, but stay within the requirements specified above.
DescriptionIn this final assignment, the students will demonstrate their ability to apply two ma
Path finding involves finding a path from A to B. Typically we want the path to have certain properties,such as being the shortest or to avoid going t
Develop a program to emulate a purchase transaction at a retail store. Thisprogram will have two classes, a LineItem class and a Transaction class. Th
1 Project 1 Introduction - the SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of
1 Project 2 Introduction - the SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of