CHAPTER 6
Acquisition of application domain knowledge for software maintenance is typically not a process that is initiated by itself. It is most common for a maintainer to seek certain pieces of domain knowledge as a result of trying to understand a part of the code. This integrated representation provides easy access from the code model to related parts of the domain model. Every method is part of a data-type, and has a return data-type. Every code-level action involves a value which has a data-type. Every variable used by a method has a data-type. Every slot is part of a data-type and has a data-type. A maintainer can simply pop up views of the section of the software that is being examined, and click on objects to bring up role filler windows which can then be used to link into the domain model. There is much information available at the click of the mouse button, all linked together.
The power of this approach is made clear only in a comparison to previous methods. In these previous systems, a maintainer must deal with three artifacts: the code, the domain model, and the SIS code-model. In such a system, when the maintainer comes across e.g. a variable, and desires to understand what the variable is supposed to represent, the domain model can be consulted. What does the maintainer ask for? The data-type of the variable can presumably be found easily enough, but then what? How does the maintainer use the domain model to understand the data-type? The only course of action is to take the name of the data-type in the code and hope that the domain model used the same name! There may be no connection between the two at all. In fact, there is no guarantee that domain model objects with the same name as code model objects really represent the same thing.
For example, consider the domain of KBEDS. Using good software engineering practice, the design team develops a domain model, and then the program is implemented based on the domain model. Note that while the developers may use the domain model as a guide, like documentation it is a separate artifact. The program starts out with a fairly tight correspondence, at least conceptually, between the domain model and program. There is an object in the domain model called mail-recipient, which is defined to be a person with an email address and a mailbox. In the code, there is a data-type with the same name, and in a method called deliver-message is a variable of this type which is given a value by searching through all the known recipients for one with the email address found in the To: field of the current mail message. The method then adds the current message to the end of the mailbox associated with that person.
Sometime during the life of the software, the developers decide that groups of people should also be able to receive mail, and so they change the code to allow for this, by changing the deliver-message method to check if the recipient is a group, in which case it handles it specially.
Later still, a maintainer is doing discovery and sees the variable in the deliver-message method. To help determine what it is, the maintainer looks in the domain model for any objects called "mail recipient." Of course, at this point, the maintainer will have discovered false information, since the domain model still indicates that a mail recipient is a person.
This is not merely some imagined hypothetical example. The simple fact is that domain models are almost always developed by different people, even by entirely different groups, than those who write the program. In the LaSSIE SIS, the domain model was developed long after the program, and was based on information acquired from experts in the domain [Devanbu, 1994]. While useful for helping maintainers understand the domain, there was no way of knowing how accurately the domain model reflected the domain knowledge that was implicitly in the code through its implementation.
Specific examples of using the integrated domain knowledge to assist discovery are given in Section 7.2.1.
Generated with Harlequin WebMaker