Some confusion is being caused by the fact that the robustness diagrams for the "Open Account" use case refer to a "Master Account Table" whereas a class called "User" appears in the static design. I think these are probably the same.
It is not necessary to combine use cases together in your testing. It is acceptable for each use case scaffold to set up the environment a particular use case needs to execute. Naturally, once a user interface is in place testing would include real user tasks, but at this early stage it is not required. The reason, that has not been discussed in class, is that oftentimes a choice of user interface technology will have a great effect on how the various interactions of a program will connect together. For instance, a graphical user interface with multiple windows can implement a use case as a modal dialog, for instance a "wizard". When a wizard is done the dialog closes exposing what the user was working on previously. As a result nothing explicit needs to be done to return to the previous work. On the other hand, a web application that is limited to one window may have to carry forward a URL of the previous work. For this reason you do not need to attempt to link together multiple use cases in your test scaffold.
Pretend that you are the project lead for a small company building the site for a large company. The contract calls for one checkpoint early in development. Pretend that being paid for the last few weeks in a timely manner depends on your report convincing a senior engineer employed by your client that your testing shows that the program so far supports the use cases. Thus, your report has to clearly argue what your test strategy is and how the results of the testing demonstrate that your entity classes work.
I thought that your test results should probably be organized by use case and that a preamble that describes your test strategy would almost certainly be required. In addition, I also suggested that javadoc or other internal or external documentation of the actual implementation was somewhat less important to this assignment.
To put your boundary classes into perspective I suggested you pretend that only after this check point is passed will any user interface work commence -- by a different team of programmers. They will likely throw away all the boundary object code you write for this check point.
We discussed how no database ought to be implemented -- you need support the protocols required to exercise the entity classes but can statically initialize, or read from a file, or programatically initialize your data. There is no need to write changes permanently.
We discussed that several styles of test scaffold were possible. An ambitious approach would be to build a text user interface in which boundary classes would read and write text commands. This will be pretty hard. The advantage is that you can drive your program interactively as you debug it. Much simpler would be to build test classes that put the implementation through its paces one use case at a time. These could be packaged as "main" programs, or static methods in test classes corresponding to use cases, or any other way that you like. Obviously the cleaner the packaging the better.
The model in the book and the handout does not, correctly in my opinion.
Follow the static model and fix the generated code. Good eye.
> I just wanted to clear something up about the design in Assignment 1. In > the design, Book is NOT a subclass of Item. But the starter code that you > gave us (which I realize is not completely correct) shows that Book extends > Item. It seems to me to make sense that a book is a subclass of an item, > but the design does not say so. I just wanted to confirm that Book is NOT a > subclass of Item.
We are assuming that the "real" implementation of the system will be interactive. This issue boils down to advice from the "entity" model team to the "UI" team that they will have to use some sort of event handling mechanism to avoid stack overflow.
Having noted that we can ignore the issue for our test program. Practically speaking, you could probably run an awful lot of use case test before actually blowing the Java stack.
Thanks for another thoughtful question.
> For example, in the login sequence diagram, the LoginPage display() > will be called by HomePage display(), then inside the LoginPage > display(), it will call HomePage display() back. In this case, the > HomePage display() will appear in the stack more than once and it will > stay there until the program exits.
I'll try and follow the FAQ format subsequently, but a lot of messages have zipped by already. The historical stuff I'll just concatenate below.
> Q1 > Do we need to save the accounts in a file or some kind of database? or > we just keep it in the memory? >There is no need to make your system "persistent". You can initialize the entity objects with code.
> Q2 (Please refer to the sequence diagram on page 12) > If the customer enters an ID that the system doesn't recognize, the > system calls "displayErrorAndPrompt()" to ask the customer to input > another ID.Like we were discussing in class yesterday, sometimes you have to have an idea of the UI to answer this question. For instance, the current red hat linux login screen just displays a message right in the login screen. Windows XP, on the other hand, sometimes will post a "bubble" (Mr paperclip is gone thank goodness) from your task bar. The use case does not describe the systems behaviour to this extent, so you get to decide. In one case you could just print a message from LoginPagge.displayErrorAndPrompt. In the other case you would need another boundary object and print the message from there. In either case your test results document would note that the appropriate message was observed.
> Should we create the input line in "displayErrorAndPrompt()"? > Or we just need to display an error message in > "displayErrorAndPrompt()" > and go back to the login page by calling "display()"? >
> I am confused about the 'add item to shopping cart' use case and 'edit > contents in shopping cart'. The way the static model looks right now, > there is an 'onAddToShoppingCart' method in the 'Search Results Page" > class. There is nothing in the 'ShoppingCart' class that involves > adding items. I would have thought you would want to 'add items' to > the shopping cart. So my question, is this a design mistake or is it > actually a requirement. Some elaboration is appreciated :-)Indeed. That was what I was on about on the first slide of yesterday's lecture. ICONIX skipped analyzing the "add item to shopping cart" use case because it was trivial, or at least so they thought. As a consequence, they missed a method on shopping cart!
> Questions.Good questions. Remember that designs aren't perfect.
> On page 10 of the handout, as an alternate course for the Use Case of > Log > In it is said that the system should be able to display a reminder word > stored for that customer by clicking the reminder word button. How is > the > system supposed to know who the customer is as s/he has not logged in > at > this point or entered a user id?Well, I think the fact that it is an "alternate course" implies that the user has just muffed a password and so we know his userid.
> *** Questions for second use case 'Open Account' **** > > In the second robustness diagram I cannot find anything in the Use Case > that would indicate why the New Account Page Boundary object interacts > with the Get Account Info controller. Am I missing something?Perhaps. The last alternate course implies that the system has to check if the account already exists.
> Also the arrow from New Account Page to 'Validate Correct Entry of > Account > info Controller has the label 'click create account'. Shouldn't this > be on > the arrow between Customer and New Account Page?Perhaps it would be better named "validate pending new account" or something. > Is there a reason for omitting the 'already existing account' alternate > course from the sequence diagram of that use case? How about someone ran out of space on the page?
> I am confused about inconsistencies between the robustness diagrams of > the > three use cases. While all of the use cases include displaying error > messages as a part of their alternate courses only the second one (Open > account robustness page 14) explicitly shows these error pages. Also > this > diagram is the only one without a general display controller. Is there > a > reason for this? > > As a general question, when this program starts up it is not going to > have > any users, authors, or books in the system. The only method the > customer > has to populate any database is via the "New Account" case. As such > there > can be no items in this store, nothing to be searched on, and nothing > to > add to the shopping cart.. Is this acceptable?Well, no, you will have to populate that sort of data from "scaffold" code in order to test your entity classes in any meaningful way.
> Q1. > In the handouts, you mentioned that we should not redesign the system, > do u mean that we should not add any new class, method or variable? >no, you may have to do that to work around mistakes in the design. Just don't go wild and design the code in some way that you "like" more. Try and follow the design.
> Q2. > Some of the class variables in the starter codes are commented out, do > you > mean that we should not use those varaibles?Nope, if you look at them you will see that they are potentially useful things that were generated in illegal syntax
> Q3. > There is method "finalize" in each class, what the purpose >That method is often important when databases are involved. Probably redundant in this case. Read up on what finalize does. It's basic Java.
> Hi Mathew, (you might be receiving this a second time since I'm not > 100% sure which email cdf/cs you want your email sent to), > > but I have a few questions concerning assignment 1. > > 1) What kind of results should we return for search by author? (since > we don't have and are not required to create a database for books) What attributes does the Book entity class have? Okay then, so what do you think you return? > > 2) How do we validate userID and Password? (since we don't have a DB > storing account data) > > 3) Do we have to implement the search by author function? If so, how? > (since we are not working with a DB, thus we can't use SQL) >You can ignore "persistence" issues. Keep the data in Java memory, like an array, initialized somehow from your test scaffold.
> Hi, > > I also have some minor questions about the use case and robustness > diagrams > in the A1 handout. Although, it is clear that the customer goes to the > Login > Page coming from the Home Page (explained in the documentation and the > diagram of the Log In use case), it is not clear how the customer > enters the > Shopping Cart page. In page 11, it is shown that the "Open Account" > use case > can be invoked from the Login Page, but there is no indication that the > "Edit Contents of Shopping Cart" use case could be invoked from the > Home > Page. The students were a bit confused about how the user would go to > the > Shopping Cart page (I think that the same happens with the search > page).well, search by author specifically mentions: Then the system displays the list of Books on the Search Results Page, with the Books listed in reverse chronological order by publication date. Each entry has a thumbnail of the Book's cover, the Book's title and authors, the average Rating, and an Add to Shopping Cart button. The Customer presses the Add to Shopping Cart button for a particular Book. The system passes control to the Add Item to Shopping Cart use case. That use case, in turn, is not described. Add to shopping cart could, I guess, just invoke "edit shopping cart" after adding the book.
> Also, it is not clear why there is an arrow from the "Open Account" > use case > back to the Login Page (page 11). In the documentation of the "Open > Account" > use case (pages 13-14), it says that the customer is sent to the Home > Page > and not to the Login Page.This is an inconsistency, no doubt about it. Both the text and the sequence diagram take the user back to the home page. The robustness diagram is wrong.
> > Finally, the main use case diagram (page 5) does not include "check > out" > which is presented in later diagrams.Darn, this is my mistake. I wanted to skip check out because I didn't want the students faking up back ends. I missed the invocation from "edit contents of shopping cart"
> there are some boundary classes which represent gui, like login or > search > screens. What functionality do you expect from the text gui?That's up to you. My position is that the role of test scaffold boundary classes is to support some sort of verification that the use cases execute correctly. No more. That means that in this case you just need to be able to argue that whatever they input/output is sufficient to tell that each use case you decided to test worked.