PLEASE ADD COMMENTS TO LET ME UNDERSTAND YOUR CODE

CODE SHOULD BE BY JAVA LANGUAGE

PLEASE LOOK TO PIC

For this assignment, you will build a TransactionSeq ADT, a sequence of transactions.

1 Concerning the TransactionSeq ADT

This ADT will make use of Transaction objects. You will not be working on the code for these.

Instead, you will simply be storing them in and retrieving them from an array. In no places you

will need to call Transaction methods.

The TransactionSeq ADT is a variant of the Sequence ADT from the textbook (Section 3.3 on

pages 145158 (142155, 3rd ed.)). This is what you will be developing for this homework. The

data structure is the same as in the textbook, with one addition: a boolean indicating whether

there is a current element. The ADT handles not having a current element separately from being

at the end of the sequence. which is a big difference from the textbook.

The sequence maintains a location within the sequence. If additionally there is a current

element, then this element is the current element. If the current element is removed, we dont have

a current element any more (unlike the textbook), but the sequence remembers where it was, so

if a new element is added (using either addBefore or addAfter, there is no difference), the new

element is placed where the removed element was. Other than being removed, it is also possible to

have no current element if one advances beyond the last element. In that case, any addition (again

with either addBefore or addAfter) is then placed at the end of the sequence.

The following methods thus have different semantics from the textbook: addBefore, addAfter,

removeCurrent, advance. We also add a new public method:

atEnd Return whether the current location is at the end of the sequence. If at the end, there is

never any current element. (This property must be checked along with the other invariants.)

You are also required to write your own toString method which may be useful when debugging

the ADT. This method must at the least show the current element and give an indication of where

the current index is.

Unlike the lab exercise, null transaction values are permitted. Nulls should count toward the

size, and a null transaction can be the current element.

Unlike the textbook, we recommend that you do not use System.arrayCopy. While it does

indeed run faster than doing a loop, its not very clear what it is doing. Use a for loop for clarity.

2 Concerning Invariants and Assertions

The sequence-specific data structure makes use of two integer fields, a boolean field, and an array

field. There are certain configurations that make no sense. In situations like this, programmers

are recommended to define and check object invariants. For our course, this recommendation is

coverted to a requirement. See page 126 (3rd ed. p. 123) in the textbook, but remember that we

also have added the new isCurrent field.

There are conventions and Java language features to help you codify and test the invariant.

For this homework, you will implement the class invariant as a private boolean method named

wellFormed(). Then the beginning of every public method must have code as follows:

Spring 2023 page 1 of 2

CompSci 351/CompSt 751: Data Structures & Algorithms Homework #2

assert wellFormed() : "Invariant failed at start";

and at the end of any public method that changes any field, there must be the following line:

assert wellFormed() : "Invariant failed at end";

We have placed these lines in the code in the skeleton file for your convenience.

Public methods assert the invariant in this way, so they should not be called by other methods

that are in the process of breaking and (one assumes) eventually restoring the invariant. Neiher

should they be called by code that is checking the invariant!

An invariant may be expensive to check. Therefore in Java, assertions are turned off by default.

For that reason, an assertion should not include some side-effect that needs to happen. Dont rely

on an assertion to check (say) that a parameter is good. Your code should still work as intended

when assertions are turned off.

You should always turn assertions on while running the main test suite. With the command

line, this is done by passing the flag -ea to the java executor. In Eclipse, assertions are enabled

by adding -ea (dont forget the hyphen!) as a VM argument on the Arguments tab of the run

configuration. This is done by defaul when running JUnit tests (but not when running random

tests see below).

The exception is efficiency tests. When running these, make sure that assertions are disabled by

removing -ea from the VM arguments. When testing efficiency, we want to know how quickly our

code will run in the real world, so spending time testing invariants is not what we are interested

in.

3 Concerning Random Testing

Its hard (and tedious) to provide exhaustive tests for an ADT. Sometimes, the best way forward

is to use random testing where the ADT implementation is tested against a (perhaps inefficient)

reference implementation. By doing a lot of random tests, we can increase confidence that the

implementation isnt using conditionals to work around our existing tests.

For this assignment, we provide a random test system. If your code is free of compiler errors (no

red Xes), you can run it. In the Referenced Libraries, open up homework2.jar. In the default

package, find RandomTest, right-click it, and Run As a Java Application.

It will carry out millions of tests. It may either find no errors and give you a congratulatory

message, or it outputs a specialized JUnit test that your implementation fails. The output can be

copied into a new file and executed so that you can perform debugging. Do not attempt to debug

the RandomTest executable itselfit does a different sequence of tests each time.

please look to pic to under standmore