CSE4ASD Advanced Systems Design

Exploring Aspects for Software Development

PROBLEMS CENARIOS

The assignment is in three parts, the first two parts will involve providing extensions/augmentations to two program systems, and the last part on specifying use case slices. State your assumptions if any, and note that there may be more than possible solutions to the same problem.

Part A – AspectJ Programming

Take the simple shopping cart system and, without modifying any of the given code, define aspects (one independent aspect for each point here) to:

1. produce a log trace of the following three types of operations, when the Test program is executed:
   • creation of a new Item object
   • adding of an item to a ShoppingCart object
   • removal of an item from the ShoppingCart object

   (different messages should be produced before and after each instance of the above operations, i.e., on entry and exit of the methods, containing at least the method name and arguments involved, and the calling object’s ID and Class)

2. produce, during execution of the Test program, a message for every 5 Item objects created (e.g., output a message when 5 Item objects have been created, then another message when 10 Item objects have been created, a third message when 15 Item objects have been created, and so on), and output a message when the shopping cart is full (after the last item has been added which caused the cart to reach the cartsize as defined in the Test program)
3. determine, given an execution of the Test program, for each class (except Test), which classes (if any) uses its methods and what these methods are – you can output messages that indicate this information
4. enforce a policy that variables in all the classes except java starts with an underscore (“_”), raise a warning when this policy is violated (you can test your aspect by adding a variable to a class that violates this policy)
5. enforce a policy that no variables are accessed directly from anywhere, i.e. issue a warning when a variable’s value is accessed without using the corresponding get*() or set *() method(s)
6. add methods (of name IsEmpty() returning true or false) to the Inventory and ShoppingCart classes that will allow users of these classes to test whether an Inventory object is empty (e.g., before removing an item), or whether a ShoppingCart object is empty (e.g., before removing an item)
7. add precondition checks to ensure that Item objects are created with an ID which contains only alphanumeric characters (i.e., the ID is a string which contains only digits and letters of the alphabet), and a price value which is positive (cannot be zero or negative)
8. add methods/constructors and variables (if you deem necessary) to the Inventory and ShoppingCart classes so that Inventory and ShoppingCart objects can be created with a size limit (provide a default limit if no limit is given), and use advice(s) to disallow adding more items than the limit (you can add code to Test.java to test your newly added methods/constructors)

Name the aspects a1.java, a2.java, a3.java, a4.java, a5.java, a6.java, a7.java, and a8.java, respectively.

Part B – AspectJ Programming

The echo talk system comsists of two components: one is the echo server and the other is talk client. You should start the echo server program first in one command window. For example, after compiling the programs with ajc or javac, (or the corresponding Eclipse functions), we can start the server: at a given portnumber (say, 3000), which will now listen to messages form the Talk client:

> java Echod 3000

Then start the talk client program in a separate command window but specifying the same port number as the server:

>java Talk 3000

Now, if you type a string, say “hello” here and then press “enter”, the server will return an echo message “hello”, i.e.

>java Talk 3000

hello (you type “hello” and then press the enter key)

will result in

>java Talk 3000

hello

hello (the server echoes what you type)

the second “hello” coming from the server.

Take the echo talk system and using only aspects and/or additional classes (without modifying the given code), add the following features to it (you are free to use one or more aspects):

1. add a message filter on the server-side:

   only messages starting with the substring “echonow: ” will be echoed by the server

2. add another message filter, but on the client-side:

   only messages typed into the client during the day (between 11am and 4pm) will be sent to the server (you can use Java’s date utility)

3. simulate delay in replies from the server:

   use the Java sleep(<duration>) function to delay an echo reply by at least 10 seconds

4. add time-stamping:

   every message that is sent by the client is time-stamped; and similarly every message sent by the server is time-stamped, e.g.: the user types “echo: hello”, and the message is prefixed by a time-stamp before being sent to the server:

   “echo: hello <client-time-stamp>”

   and similarly the server's echo reply is time-stamped, of the form: “echo: hello <client-time-stamp> <server-time-stamp>” (time-stamps can be of any form but should show roughly time in hours and seconds and fractions of seconds)

5. add logging to the server-side and the client-side:

   the server writes into a file every message that it echoes back; and the client writes into a file every message that it sends to the server

6. resend echo messages from one server to another server (you need to run two Echod servers with different port numbers, and one Talk client which needs to connect to both the servers in order to test your implementation of this feature) – a message sent from one Talk client is sent to one Echod server, and then on receiving a reply (the echo) from the server, the Talk client then resends that message to the other  Echod server

Name the aspect b1.java if you use only one aspect, or b1.java, ..., bn.java if you use n aspects.

Part C - Aspect-Oriented Design using Use Case Slices

Consider the University Record System (URS) described in a lecture. See U M L - U s e C a s e D i a g r a m s . p p t , which contains amidst other examples, an i n i t i a l d e s i g n of the URS: use case diagrams and a high-level class diagram – this design as it stands is incomplete. This part of the assignment involves extending this initial design to support four use cases via use case slices.

For the following use cases, specify interaction diagrams and use case slices – for each use case/requirement below, give an interaction diagram for the use case, and then provide a use case slice which specifies

• classes (if any) which needs to be added (on top of those in the initial design) to realize this use case, and
• an aspect containing extensions (if any) to one or more classes (in the initial design or in another use case slice), where the extension(s) may be in the form of methods (i.e., operations) or variables to be added to the class, and/or an advice(s).

In your design, you are free to specify methods/operations that classes should have. Also, the interaction diagram you give should be consistent with the use case slice you provide (e.g., for a use case, the classes/objects and methods/operations mentioned in the interaction diagram should also occur in the corresponding use case slice). You can assume the system uses a form based interface (see the lecture on use case slices for examples of user interface forms in interaction diagrams) State any assumptions you make.

Use cases/requirements:

1. a student enrols in a subject, but each request to enrol requires an authorization from the academic staff that teaches that subject;
2. an academic staff deletes a subject from the database, which has implications, e.g. that any students enrolled in the subject must be unenrolled from it, etc;

3. enable a print academic history feature, which for a given student, can generate a list of subjects that the student has taken, as well as who teaches those subjects;

4. ensure that each update to the database is logged by sending an email to the URS system administrator [you do not have to provide an interaction diagram for this case]
5. notification of failures in database operations: ensure that an email is sent to the system administrator whenever a database operation fails and a log message records this
6. notification of changes to student enrolments: ensure that an email is sent to the academic coordinator each time a student is enrolled in or unenrolled from a subject in the database