Our design process has come a cropper with the problem of how does the distribution center know about items in an order and the address of the customer. Before I get to the problem, a quote from Grady Booch (not my favorite author) (page 229 of Object-Oriented Analysis and Design with Applications, second edition)
The amateur software engineer is always in search of magic, some sensational method or tool whose application promises to render software development trivial. It is the mark of he professional software engineer to know that no such panacea exists. Amateurs often want to follow cookbook steps; professionals know that right approaches to development usually lead to inept design products, born of a progression of lies, and behind which developers can shield themselves from accepting responsibility for earlier misguided decisions. The amateur software engineer either ignores documentation all together, or follows a process that is documentation-driven, worrying more about how these paper products look to the customer than about the substance they contain. The professional acknowledges the importance of creating certain documents, but never does so at the expense of making sensible architectural innovations.
With this off his chest (and mine) he goes on to say that while object-oriented design is not cookbook, it is sufficiently well-defined to offer a predictable and repeatable process.
Let's look at the sequence of events in our course program. When we add new professors, there is no effect on the section list, only the list of professors changes. You can do anything to the section list and in this model it has no effect on the professor list. When we edit a professors information, if there is a name change, you must tell the section window to repaint itself or the new professor information will not be seen in that window. If you delete a professor, you will have trouble since the professors id key is listed in some section table records and will no longer exist. If you do infact delete a professor who has a course section, you will get a database error. This means that before you delete a professor, you must reassign his sections to other professors.
In order to facilitate the delete function, you will first learn to use Structured Query Language (SQL). SQL uses simple statements like:
"Select * from Sections where professor like 150 "This statement retrieves all entries in the table Sections with professor field 150.
Borland Builder has a class TQuery which like TTable is a descendent of TDataset. This means once you have made a query using SQL, the results of your query will be stored in the TQuery, which will respond to the same commands that you used to manipulate a TTable.
Before you solve the main problem, you will use SQL to solve some simple problems. In most cases, the list of all sections is to large to search visually for all sections taught by a given professor. In many cases the window could not accomadate all of the sections. You will create a Query that searchs the data base for all sections taught by a given professor. This will require three things:
You must