$6.4 FORMALIZING THE SPECIFICATION 129 Aided by a teaching assistant,I thus embarked on a task which seemed obvious enough although not commonly taught in software engineering courses:systematic program deconstruction.Sure enough,we quickly found the first place where the program accessed the sender's name,and we removed the corresponding code.This,we naively thought,would have done the job,so we recompiled and sent a test mail message;but the sender's name was still there!Thus began a long and surreal process:time and again, believing we had finally found the last reference to the sender's name,we would remove it,recompile,and mail a test message,only to find the name duly recorded once again in its habitual field.Like the Hydra in its famous fight,the mailer kept growing a new head every time we thought we had cut the last neck. Finally,repeating for the modern era the earlier feat of Hercules,we slew the beast for good;by then we had removed more than twenty code extracts which all accessed,in some way or other,information about the message sender. Writing MAIL Although the previous sections have only got us barely started on our road to abstract MESSAGE is the data types,it should be clear by now that any program written in accordance with even the topic of exercise E6.4,page161. most elementary concepts of data abstraction would treat MAIL MESSAGE as a carefully defined abstract notion,supporting a query operation,perhaps called sender,which returns information about the message sender.Any portion of the mail program that needs this information would obtain it solely through the sender query.Had the mail program been designed according to this seemingly obvious principle,it would have been sufficient,for the purpose of my little exercise,to modify the code of the sender query. Most likely,the software would also then have provided an associated command operation set sender to update sender information,making the job even easier. What is the real moral of that little story (besides lowering the reader's guard in preparation for the surprise mathematical offensive of the next section)?After all,the mail program in question is successful,at least judging by its widespread use.But it typifies the current quality standard in the industry.Until we move significantly beyond that standard, the phrase "software engineering"will remain a case of wishful thinking Oh yes,one more note.Some time after my brief encounter with the mail program, I read that certain network hackers had intruded into the computer systems of highly guarded government laboratories,using a security hole of that very mail program-a hole which was familiar,so the press reported,to all those in the know.I was not in the know; but,when I learned the news,I was not surprised. 6.4 FORMALIZING THE SPECIFICATION The glimpse of data abstraction presented so far is too informal to be of durable use. Consider again our staple example:a stack,as we now understand it,is defined in terms of the applicable operations;but then we need to define these operations! Informal descriptions as above(put pushes an element"on top of"the stack,remove pops the element"last pushed"and so on)do not suffice.We need to know precisely how these operations can be used by clients,and what they will do for them.§6.4 FORMALIZING THE SPECIFICATION 129 Aided by a teaching assistant, I thus embarked on a task which seemed obvious enough although not commonly taught in software engineering courses: systematic program deconstruction. Sure enough, we quickly found the first place where the program accessed the sender’s name, and we removed the corresponding code. This, we naïvely thought, would have done the job, so we recompiled and sent a test mail message; but the sender’s name was still there! Thus began a long and surreal process: time and again, believing we had finally found the last reference to the sender’s name, we would remove it, recompile, and mail a test message, only to find the name duly recorded once again in its habitual field. Like the Hydra in its famous fight, the mailer kept growing a new head every time we thought we had cut the last neck. Finally, repeating for the modern era the earlier feat of Hercules, we slew the beast for good; by then we had removed more than twenty code extracts which all accessed, in some way or other, information about the message sender. Although the previous sections have only got us barely started on our road to abstract data types, it should be clear by now that any program written in accordance with even the most elementary concepts of data abstraction would treat MAIL_MESSAGE as a carefully defined abstract notion, supporting a query operation, perhaps called sender, which returns information about the message sender. Any portion of the mail program that needs this information would obtain it solely through the sender query. Had the mail program been designed according to this seemingly obvious principle, it would have been sufficient, for the purpose of my little exercise, to modify the code of the sender query. Most likely, the software would also then have provided an associated command operation set_sender to update sender information, making the job even easier. What is the real moral of that little story (besides lowering the reader’s guard in preparation for the surprise mathematical offensive of the next section)? After all, the mail program in question is successful, at least judging by its widespread use. But it typifies the current quality standard in the industry. Until we move significantly beyond that standard, the phrase “software engineering” will remain a case of wishful thinking. Oh yes, one more note. Some time after my brief encounter with the mail program, I read that certain network hackers had intruded into the computer systems of highly guarded government laboratories, using a security hole of that very mail program — a hole which was familiar, so the press reported, to all those in the know. I was not in the know; but, when I learned the news, I was not surprised. 6.4 FORMALIZING THE SPECIFICATION The glimpse of data abstraction presented so far is too informal to be of durable use. Consider again our staple example: a stack, as we now understand it, is defined in terms of the applicable operations; but then we need to define these operations! Informal descriptions as above (put pushes an element “on top of” the stack, remove pops the element “last pushed” and so on) do not suffice. We need to know precisely how these operations can be used by clients, and what they will do for them. Writing MAIL_ MESSAGE is the topic of exercise E6.4, page 161