[Next] [Previous] [Up] [Top] [Contents]

CHAPTER 6

6.4 Understanding Methods

One of the most important parts of understanding a software system is understanding the methods that make up the system. This makes method understanding a critical part of discovery, and clearly a natural focus of tools for assisting discovery.

From a code-level perspective, a method is completely defined by three things: its parameters, its return value, and its side-effects. The ontology described so far can greatly assist a maintainer in understanding the first two aspects of a method. For the third, side effects, a surprisingly small and elegant addition to the ontology enables automatic identification of all side effects. The ease with which this complex notion was implemented is another testimony to the value of a CSIS style representation for software.

A discovery scenario involving understanding a method is given in Section 7.2.1.

6.4.1 Parameters

A maintainer can get a lot of information about the parameters of a method. To begin with, each parameter has an immediate data-type which directly links it to the domain model, and helps to answer questions about what the parameter is supposed to represent.

Next, the access roles described in Section 6.1.2 automatically link each parameter to every value in the program that is passed in as a value of the parameter. The role passed-by of each parameter is filled with every individual of pass-parameter that passes a value for this parameter, and each of these individuals has an argument-value role which is filled with the individual of software-value that will be used. This tells a lot about the parameter, since its relevance can be determined in a larger context than just the method.

Finally, every place within the method that the parameter is used, changed, or sent a message is recorded in the various accessed-by roles of the parameter, and this provides all the information about what the parameter means to the method.

6.4.2 Return Value

The return value of a method usually indicates what the method does, and as with the parameters, a maintainer can get a lot of information about what a method returns.

The return value of a method is determined by the individuals of return that fill its has-implementation role. There may be more than one, but there must be at least one, and the code-level ontology does require that every branch of the control flow end in a return. Methods that do not return a value may return a void, which is a data-type under the host-thing hierarchy that has one instance, a constant that can be used globally (this is not actually part of the ontology, but part of the support environment for development).

Each return statement in the method has a role return-value, which is filled with an individual of software-value. All these values must have the same data-types, and it is these data-types that are derived to be the fillers for the has-return-data-type role of the method with the simple rule:

Again, knowing the data-type of any value can provide important domain information about the value, and as with any other software value, the accessed-by roles can give a lot of information about what the value actually is, most importantly where the value is changed.

Chris Welty - Dissertation - 17 SEP 1996
[Next] [Previous] [Up] [Top] [Contents]

Generated with Harlequin WebMaker