First and foremost will be the Java class file. Let's say that you're taking a Data Structures class, and the professor introduces you to the Bounded Set. "Good Golly," you say, "That's incredible! A data structure that will store a set of values! Who'd-a-thunk-it?" Then, you get to thinking, "Gee, I bet I could do better than that! I'm going to make a data structure that can store a set of values, but this time, it can store more than one of each value! It will store any number of values, and it will be able to tell you how many of each value it has!" This is exactly the type of radical thinking that has changed history.
Being the insightful, yet lazy person that you are, you decide to write your new Bounded Bag class as an extension of the Bounded Set class. You get to work, and within weeks, you've produced a veritable masterpiece, the Bounded Bag class.
As you sit back on your laurels, reveling in your success, you have a nagging thought in the back of your head. "What if," this nagging thought asks, "what if I made a mistake somewhere? Unlikely though it is, there is always the small chance of a bug." This persistant doubt keeps you awake for a month, until finally you decide to test your implimentation using Danish.
Looking through the documentation, you realize that you must create an axiom file which will describe how your ADT should behave. So you take Comp 204, and three months later, you know how to create axiom files. So you decide to do just that.
But before you can do this, you realize that you need to add some more methods to your class, to test Bounded Bags for equality and print them out. After a couple months, you have your new class file.
Returning to your axiom file, you soon realize that you also must create a signature file so your axiom file willbe understood by Danish. Well, this is easy. Simply record each method name on a separate line, preceded by the return values, and followed by the list of parameters. Since the methods are members of a class, the first parameter must be the object name in {braces} so it is not explicitly passed. Similarly, when a modified object is implicitly returned, the return type is the object name in {braces}. Soon, you have your Bounded Bag signature file.
While writing your signature file, you notice that some method names, like
"new BBag" and "System.out.print" won't parse right,
since they are more than one word. So, you start on your
alias file. You also decide to use a
limit of 15 on the size of the tested BBag, and use the
signature file and newly created
alias file to accomplish your
purpose.
With your support files completed, you can now finish your axia file. Now, you work on your test vectors file. You add some ints, you add some sets, and you're done.
Now comes the easy file - creating the resource file. In fact, it's so easy, you don't even have to do it. But since you're lazy, and it makes things easier to run, you make it. "Surely that's not all there is to it is there?" you ask? So you run Danish, and...
it fails.
Why? This is an example of the problems with one variable type taking on two roles. In this case, an int can either be the data or the number of data. In axiom s2d, you were trying to add 123456789 0's to the list - far too many.
So you go back, and add a new type, called 'count', creating a new alias file. This new type, count, represents an integer when it stands for a number of entries, as opposed to an entry itself. You then must change your signature file to make use of your new variablke type. Note that you must also add a print function for count, which is just System.out.print(), since count is actually just an int. You must also change your axiom file to reflect the new type, as well as adding count vectors to your vector file. Here, you must also change your set test vectors, since, for example, add_many takes a set, an int, and a count now, instead of a set and two ints.
So you make all the necessary changes, and glory be, it works! Congratulations, you've successfully implimented the Bounded Bag. Your college education was well worth the money spent. But now, something's still bothering you. You want to be more sure that you have coded correctly. So you decide to use the contract class to be sure that some pre- and post-conditions are correct.
This time, the changes are simpler. Just add the lines indicated in the directions, and you're all set with your new Java class. Just make sure you use your old Java class when using your ADT for real, since the new one has changes that won't make sense out of the context of Danish.
Previous Topic
Next Topic