Task 1: complete the Maude specification

The module includes equations that define all the operations except acceptRequest; you should complete the specification by adding equations to define the functionality of this operation: this may involve adding some helper operations (one helper operation, remove, is declared but needs equations to define it: you should add these equations). In addition, the operations addRequest and getRequests have helper operations isIn and getReqs that are missing equations: you should add equations to complete the specification of the functionality. Add your equations and helper operations to the file friendFace.maude and submit this completed specification.

Task 2: test the Maude specification

The file friendFaceTest.maude

contains some test reductions. These only test the functionality of register, getRequests, and getFFriends; you should add more test reductions that test all of the six main operations. These test reductions will give a test of your solution to Task 1. Add your tests to the file friendFaceTest.maude and submit your edited file.

Task 3: implement the FriendFace functionality in Java

To implement this in Java, you need to implement a class FriendFace with six public operations. A skeleton of such an implementation is given in the file FriendFace.java. Your implementation should use various lists (e.g., of members, requests, etc.), you should implement these yourself as linked lists (possibly generic): do not use, for example, arrays or java.util.LinkedList.

Note that you need to implement the functionality of the six operations register, addRequest, getRequests, acceptRequest, refuseRequest, getFFriends; you do not need to implement any of the helper sorts or operations. Some of the helper operations, such as isIn will be useful, but others will not be useful. For example, you can implement getFFriends with a simple nested loop, which will give a much more elegant solution than implementing helper methods getAllFriends, etc. Similarly, if you implement a class Member, it would make sense to store their list of friends as a list of Members rather than a list of strings as in the Maude spec.

It is also possible to change the types of some of the operations in the Maude spec. For example,

op register : String FriendFace -> FriendFace .

could be implemented as

public void register(String name) { … }

but in FriendFace.java it has a boolean return type, which will be useful in Assignment 2 when you implement the FriendFace server: if a user tries to register with an existing name, register will return false and the client can be informed that the name is already taken.

Similarly, if you choose to implement a helper method isIn you could make its return type the same type as type of the elements in the list, returning null if there is no element in the list with the parameter string as name, and returning the found object itself if there is such an element. Such a method might be used as follows

SomeType result = myList.isIn(“Moss”);

if (result == null) {

// no object called “Moss” in myList

…

} else {

// found object named “Moss”, do something with result

…

}

Apart from the requirement that you use linked lists, you are free to implement FriendFace in any way that meets the given specification.

Task 4: test your Java implementation

Class FriendFace in FriendFace.java has a main method with tests corresponding to the three test reductions in friendFace.maude. You are asked to add more Maude test reductions, and you should add corresponding tests to the main method in class FriendFace. These tests should give the same results as the test reductions you add to friendFace.maude.

Task 5: document your Java implementation

Each class, method, field and constructor in your Java implementation should have a javadoc comment, even if its scope is private. You should use @param and @return tags where appropriate.

 

Click Order now to have a similar paper completed for you by our team of Experts.