CHAPTER 4

4.1 Domain Modeling

The CSIS ontology described in the previous chapter supports domain modeling as the first step in building a CSIS. It is important to note again that the CSIS ontology is domain-independent. That is, individuals of the concepts described in the CSIS ontology are used to describe a domain. They are also used to describe programs. A single domain model may include several programs. In essence, the CSIS ontology is a model of the domain of programming [Redmiles, Terveen, and Welty, 1995].

Modeling a domain can be described as the identification and clarification of the objects, attributes, and relations in the application domain [Miriyala and Harandi, 1991], as well as the actions which take place on those objects [Bobrow and Winograd, 1985]. There are three basic elements of the CSIS ontology that support this: data-types, slots, and methods.

For a deeper understanding of these concepts, we must first consider their ontological definitions. All three are in the software-object part of the code-level taxonomy, shown in Figure 3.5 on page 61, and as a result will all have a role called name which must be filled with strings. The central concept here, of course, is data-type, which was discussed in some detail in the previous chapter. Each individual of data-type in the code model universe becomes a concept in the domain model universe through the mapping function.

4.1.1 Data-Types

It is also important for the modeler to understand the order in which roles must be closed. Again, closing a role on an individual tells Classic that there will be no more fillers there. Rules, particularly path rules, in Classic require all roles be closed before any inference will take place. The rule for deriving superclasses, for example, was:

• data-type --> inherited-superclass (immediate-superclass superclass)

If, for example, the modeler closed the superclass role on data-type-07 with the knowledge-base in the state shown in Figure 4.2, then since the superclass role of data-type-05 is not closed, any new filler for that role would cause a new filler to be derived for data-type-07, whose role is closed. Adding a filler to a closed role causes an error (a very expensive error, because the new filler for data-type-05 must be retracted, see Section 7.1.3.4), and because of the price of such errors, the path facility (described in Section 2.2.4.2) prevents roles from being closed in the wrong order. In this example, the correct order is for the superclass role to be closed first in data-type-01, then data-type-03, then data-type-05, and finally data-type-07, in other words, from the topmost data-type down. Let us assume in this example that all the immediate-superclass roles have been closed (again, the order of closing roles that cannot have derived fillers isn't significant). The first step is to close the superclass role for data-type-01. Because it has no fillers for any of its superclass roles (immediate and inherited), no inference will take place. Next, the superclass role for data-type-03 is closed. Again, there are no fillers to inherit, so no inference takes place. Next, the superclass role for data-type-05 is closed. Now, since all the roles in the path are closed, the result, as shown in Figure 4.3, is that four new derived fillers are added. These new fillers are shown as thick dotted lines in the figure. When the superclass role is closed for data-type-05, the superclass inheritance rule fires on data-type-05, and fills the inherited-superclass role in data-type-05 with all the fillers from the path (immediate-superclass superclass). There is only one filler for immediate-superclass, data-type-03, which itself has only one filler for superclass, data-type-01. This individual is the end of the path, so it is added as a filler for inherited-superclass in data-type-05. After the rule fires, the inverse of inherited-superclass, inherited-subclass, is added in the other direction (i.e. data-type-05 becomes a filler for the inherited-subclass role of data-type-01), then the parent of inherited-superclass, superclass, is added (i.e. data-type-01 becomes the second filler for the superclass role of data-type-05), and finally as the parent of inherited-subclass and the inverse of superclass, the subclass role of data-type-01 is filled with data-type-05.

The final step is to close the superclass role of data-type-05, with its two derived fillers. The superclass inheritance rule now fires on data-type-07, and eight new links are derived. These new links are shown in Figure 4.4. For clarity, all the roles that are not directly involved in the inference have been removed, and again dotted lines show derived information, and the thick lines show the new information derived from the firing of the superclass inheritance rule on data-type-07. There are two endpoints to the path (immediate-superclass superclass) that starts with data-type-07, they are data-type-01 and data-type-03. When the rule fires, it adds these two individuals to the inherited-superclass role of data-type-07. The inverse links, inherited-subclass, are added for each, the parent role superclass is added for each, and the inverse parent role subclass is added for each. In all, three told role fillers (the immediate-superclass links) and six closed roles yield, through inference, twenty-one derived role fillers.

While the result of this process is actually something fairly standard (inheritance of the superclass relationship), it is nevertheless important for the modeler to understand, since part of the inference shown here will not happen until all the right roles are closed.

For the parts of a data-type, the methods and slots, there are also immediate and inherited roles. For the inherited slots and methods to be inherited down the superclass hierarchy to a particular data-type, the superclass hierarchy above the data-type must be closed. In addition, all the roles to be inherited must also be closed. For slots, the has-slots role must be closed in every superclass, and for methods the has-methods role must be closed. As with the superclass role, the topmost data-type in the hierarchy must have its method and slot roles closed first.

4.1.2 Slots

• software-object, from which it gets the name role.

• software-value from which it gets the has-data-type role. A slot is really a relationship between two individuals (two data-types) implemented as an individual. The has-data-type role is the second half of the relationship that the slot represents (the first half is the has-slots role coming from the source data-type), it specifies the destination of the link. In essence, it is the data-type of the values that will fill the slot. The slot will map into a role in the domain universe, and it is the value of the has-data-type role that is used to specify the all restriction on the role the slot becomes. This is illustrated in Figure 3.3 on page 58 and Figure 3.4 on page 60.

• data-type-instance from which it gets the ability to be sent messages (discussed in Section 4.2).

• changeable-instance from which it inherits the ability to be used in an assignment statement.

4.1.3 Methods

The representation allows the decomposition (in terms of other methods) of a method to be represented by filling the has-decomposition role (or its inverse, decomposition-of) with other individuals of method. Another useful attribute of methods for domain modeling is the parameters of the method. These can be identified as individual of parameter in the role has-parameters. Parameters, as specializations of variables, have a data-type, and this information can be helpful in describing what a method will eventually do. Similarly, the role has-return-data-type can be filled with an individual of data-type, to indicate what the data-type will be of the value the method will return. This role, unlike has-parameters can have derived fillers inferred by a rule that checks the implementation of the method. This rule will be discussed in the next chapter, since specifying the implementation of a method is not traditionally part of domain modeling.

Methods can also be placed in a hierarchy in several ways. Clearly decomposition is a kind of hierarchy, though it is a hierarchy relating parts to a whole. The role specialized-method-of is analogous to the role specialized-slot-of. It relates a method to a more general version of the same method. This role is used in specialization override during the inheritance of methods down the superclass hierarchy, but it can also relate a method to a more generic description of that method, even if the more generic one isn't attached to a data-type. One can easily imagine such a hierarchy of methods for sorting, with a general method called sort that has many specializations such as quicksort, merge-sort, etc.

The second role for method hierarchies is the interface-method-of role. This relationship is perhaps a little more useful in the code model, but nevertheless represents the fact that one method is a special version of another in the following way: in the actual implementation of the more specialized method is a call to the more general one. The most obvious use of this relationship is in the case where the more general method is one which requires many parameters, yet is used very frequently with the same values for most of the parameters, and only a small subset that change. For example, a method called find-frame might take several parameters, such as the type of the frame to find, the kinds of inference to check, other control information, etc., and an interface to that method might be find-person, which takes only the control parameters and calls find-frame always specifying the type as person.

Generated with Harlequin WebMaker