Use Spring MVC framework

Coursework Description

Your task is to design and implement a web interface and RESTful web services backend for the Universal Modelling Editor (UME). UME is a web application that allows users to build a classes hierarchy, define attributes and relations between classes, as well as to create, store and search instances of user-defined classes.

UME consists of two main components: Taxonomy Builder and the Object Repository.

Taxonomy Builder: classes can be defined and organised into a superclass-subclass hierarchy, which is also known as taxonomy. A class definition includes the class name and properties. Properties can be attributes of primitive data types or relationships to other classes.

Object Repository: objects are instances of classes. The object repository provides a flexible data entry interface, which allows users to create instances of any user-defined class with dynamically generated form fields based on the class definition.

Note: some Java domain class templates are provided (see Appendix 1.3). You may use these classes in the implementation and you are allowed to modify them. However, you may choose not to use these classes.

Part 1: RESTFul Web Service:

Taxonomy Builder allows users to edit classes and properties, as well as organise class hierarchy. Your first task is to implement the following RESTful services to provide backend support for the web interface.

(1) GET /rest/class/create?classname=Postgraduate&superclass=Student

Create a subclass with a given superclass. Considering the example above, this request will create a class "Postgraduate", which is a subclass of "Student". The service should return true if the operation is successful, otherwise false is returned. If the superclass is not explicitly specified then the class will be created as a top-level class. If the class already exists, the service should add a new superclass to this class (multiple inheritance is allowed. e.g. TeachingAssistant can be a subclass of both Postgraduate and Staff)

Consider the following HTTP GET requests:

GET /rest/class/create?classname=Root

GET /rest/class/create?classname=Person&superclass=Root GET /rest/class/create?classname=Staff&superclass=Person GET /rest/class/create?classname=Student&superclass=Person GET /rest/class/create?classname=Lectuer&superclass=Staff

GET /rest/class/create?classname=TeachingAssistant&superclass=Staff GET /rest/class/create?classname=Undergraduate&superclass=Student GET /rest/class/create?classname=Postgraduate&superclass=Student

GET /rest/class/create?classname=TeachingAssistant&superclass=Postgraduate GET /rest/class/create?classname=Module&superclass=Root

GET /rest/class/create?classname=MScModule&superclass=Module GET /rest/class/create?classname=BScModule&superclass=Module

A class hierarchy will be created as follows:

(2) GET /rest/class/delete?classname=Student

Delete a class from the hierarchy. When a class is deleted, all its subclasses will also be deleted, all its instances (including instances of its subclasses) will be deleted too. For example, the request above will delete class "Student" and all its subclasses including "Postgraduate", "Undergraduate", "TeachingAssistant" and any instances of these classes will also be deleted. The service should return true if the operation is successful, otherwise false is returned.

(3) GET /rest/class/hierarchy?classname=Student

Return a hierarchical JSON string reflects a sub-tree structure in the class hierarchy with the given root. For example, the request above should return a JSON object in response:

(4) GET /rest/class/getSubclassList?classname=Student&direct=true

Return all subclass of the given class, with the boolean flag direct set to true for direct subclasses,
false for direct and inferred (indirect) subclasses. For example, the request above should return:

If direct is set to false, the response should be:

Note: the order in which the subclasses are listed is not important.

(5) GET /rest/class/createHierarchy? construct={Staff{Lecturer,TeachingAssistant},Student{Undergraduate,Postgraduate{ TeachingAssistant}}}&root=Person

This service will construct a substree from the given string. For example, the above request adds a subtree hierarchy to the "Person" class. The service returns true if the operation is successful, otherwise false is returned. (Hints: write a simple string parser using recursion or stack)

Note:
You may need to design and implement other RESTful web service to complete Part 2 and Part 3.

Part 2: Web Interface for Taxonomy Builder

Creating Classes and Class Hierarchy

The web interface should support the following features:

- Show the class hierarchy in a TreeView. (See Appendix for more information on TreeView)
- Create new subclasses with the selected superclass.
- Rename or delete existing class from the hierarchy.
- TreeView should be refreshed when the hierarchy is updated.
- List all properties that are available for a class to use, including properties inherited from the superclass.

Assume that

- All classes have distinct names. For example, all occurrences of TeachingAssistant in Figure (1) are referring to the same class.
- When a class is deleted, all its subclasses will also be deleted.
- Multiple inheritance is allowed. For example, TeachingAssistant can be a subclass of class
Postgraduate and Staff.

Defining Properties

Properties represent attributes and relationships of classes. The web interface should support allow us to:

- Create a new property
- Delete an existing property
- Specify the classes to which the property belongs
- Specify the data type of the property.

Assume that
- All properties have distinct names.
- Property types may be primitive data types or user-defined classes.
- Only four primitive types are supported: String, int, double, and boolean.
- Nested and recursive class definition are supported. For example, class Person may have a property called "spouse" of type Person.
- A property might be reused in several classes. For example, property name (of type String) can be
used in class Module and class Person.
- All of the properties are optional (not mandatory).
- A subclass always inherits all of the properties of its superclass. For example, if property employeeId is defined in class Staff then all its subclasses (e.g. Lecturer and TeachingAssistant) should also contain employeeId property.

Part 3: Web Interface for Object Repository

Object Repository provide a web interface for users to store instances. Objects in the repository are instances of pre-defined classes created in the Taxonomy Builder. The interface should allow us to :

- Create an instance of the selected class.

- List instances by their class.

- Assign values to properties with a dynamically generated form.

- View all property values of an instance

Assume that

- deleting a class should also delete all its instances (including instances of its subclasses)

- Instances cannot change their type once created.

- Nested and recursive class definition are supported. For example, class Person may have a property called "spouse" of type Person.

- The structure of a class cannot be changed once an instance of such class has been created. (If this is
not the case then any changes to the class require all instances of the changed class to be modified so as to reflect the modified class structure)

Bonus Question

Use Google Charts API to visualise instances in a Treemap. Classes are displayed as a rectangles in Treemap, the sizes of the rectangles represent the number of instances of in this class. See the link below for more information.