Data Modelling & Interfacing Through QT Tool -- 2

S1. Data modelling and serialisation You should produce a data hierarchy for the identified naval assets with appropriate data fields for the system. You do not need to fully represent a given vessel, however, you need to be able to differentiate between the core types identified in the specification. This data must be capable of being written to disk and retrieved as needed. S2. Object management and representation These objects should be managed through a single data base type structure on which queries can be run. Appropriate use of data structures must be implemented to manage these and a GUI, or secondary interface, implemented to allow the results of queries to be displayed to the user. As you have already developed a major data management system in your previous task the storage system does not need to be overly advanced. S3. Data manipulation and control</p> A system must be developed to allow graphically constructed, and ideally text based queries, to be run on the &lsquo;data base&rsquo; to allow naval vessels to be identified and displayed on the interface defined in S2. This language should allow the searching for identified assets, and ideally the addition, removal, and editing of assets however these features are secondary.</p> <p>A need has been identified to develop a system which must represent the location, current state, and other factors as appropriate about a variety of British naval assets. The system must present the user with some kind of graphical interface through which parameters about naval assets can be queried. Ideally the system shall provide a secondary text based interface for this query process. There should be some separation between layers of the system, the ideal final model may be a distributed system so being able to demonstrate multiple interfaces to the system such as a text interface, a network interface, or similar functionality in the prototype would be a useful feature. The system must be capable of representing, at a minimum, the core ship parameters defined in appendix A, and differentiating between civilian, auxiliary / support, and combat vessels. The system shall be capable of differentiating within each category to represent: Civilian vessels &ndash; tankers, bulk carriers, and medical transports; combat vessels &ndash; Frigates, destroyers, and aircraft carriers and should be capable of differentiating between auxiliary vessels &ndash; landing craft, and patrol boats. Additional vessel types may be represented such as Marine Landing Craft, or Landing Dock Craft. The query capability must be capable of identifying a naval asset by searching on the service identifier of the vessel. An improved version shall allow searching on any named parameter and should be capable of either restricting the returned fields, or similar functionality. The system may provide for more complex queries. The system must be capable of storing its data on disk in some appropriate format, this should be a self-described format such as XML or JSON, however, it may be designed to interoperate with a database in the future through a name-value pair system. It should be noted that the system may be expanded beyond naval vessels in the future to include dock, airfield, and naval base (a combination of dock and airfields), if these can be integrated the system would be much improved. Appendix A: Core Ship Parameters Name Type Service Identifier Length Displacement Beam (waterline, extreme) Draft Speed Range Where appropriate: Armament (primary, secondary) Aircraft (Helicopters, Fixed Wing) On-board facilities (Aircraft facilities, landing ship facilities, troop facilities)</p> ERD attached for DB