CS302: Software Engineering

In this section, we discuss the suitability of reusable libraries and program templates to the three classes of methodologies. Because of the encapsulation of data and function in object orientation, object methods are best suited to the large scale development of reusable modules. The other methodologies, process and data, can use program templates and reusable modules, but such modules are not identified as naturally as with objects. 

Object methods are best suited to reusable components because the design method results in small, single function modules automatically. The method assumes that only data needed for a function will be available to it when it is called. Thus, the entire method assumes and strives for modules that are potentially reusable. When a module is identified in object analysis as being invoked from multiple calling objects, it is automatically targeted as potentially reusable. Further analysis determines if the functionality is identical for all users. If the functionality is the same, the module becomes locally reusable. 

The step from local reuse to organizational reuse is small, with the criteria being the number of other applications needing the function. Here too, object methods are more amenable to identifying reusable functionality at the analysis stage than the other methodologies. Think back to Chapter 11, in which we developed the table of actions (or functions) and the objects to which they were attached (see Table 18-1). It is at this stage that reuse is identified. When an action has more than one object attached, they are examined to determine whether the same action is performed for each. If both objects use the action identically, they are labeled potentially reusable.

 
			else
				move 1 to err(5).
			If In-Date-Month = 2
				If In-Date-Year = (1992 or 1996 or 2000 or 2004 or 2008 or 2012)
					   If In-Date-Day < 30
						      go to End-Test
                                           else move 1 to err(6)
			else
            			If In-Date-Day < 29
            					      go to End-Test
                                else move 1 to err(7)
                        else
                                If In-Date-Month = (4 or 6 or 9 or 11 )
            			           If In-Date-Day < 31
            					      go to End-Test
                                else move 1 to err(8)
                        else
                                If In-Date-Month = (1 or 3 or 5 or 7 or 10 or 12)
            			           If In-Date-Day < 32
            					      go to End-Test
					   else move 1 to err(9)
                        else
            			move 1 to err(10).
           End-Test.
                        Enter linkage.
                        Return.
                        Enter COBOL.

FIGURE 18-2 Reusable COBOL Module for Date Edit (Continued)

Then, the potentially reusable actions are used to search the reusable library to see if similar actions in reusable form already exist. When a match is found, the reusable module code is examined to determine its fit to the current need. Based on the closeness of fit, the designers choose to design their own module or use the reusable module. The reusable module can be used as it exists or can be customized to exactly fit the application. The point is that the analysis action is matched to a reusable action at the logical level. Only when the logical actions match, the physical implementation is then examined for its appropriateness. When many such logical level matches are found, the time savings in analysis, design, and implementation can be considerable. 

It has long been held that structured and modular design reduces maintenance effort by facilitating the definition of understandable chunks of analysis and designs. Modular design, in turn, is then applied to program modules. The designer uses his or her experience, applying the principles of information hiding, minimal coupling and maximal cohesion, to develop single function modules. In this manner, the nonobject methodologies are more brute force methods of developing modules with object-like properties. While the nonobject methodologies rely on personal designer knowledge, such knowledge also is more important in object methods than is commonly recognized at present. The results in nonobject methodologies, though, are less uniform and less likely to cause ready recognition of reusable components than object methods. Therefore, reusable component libraries are most likely to be effective and widely used in object-oriented environments.

TABLE 18-1 Sample Actions with Related Objects

* Actions are (R)ead, (W)rite, Data Entry (DE), (D)isplay (P)rocess in memory, (PR)int

The opposite situation is true of program templates. The nonobject methods, because they are used mostly for COBOL applications, can take advantage of program template libraries easily and effectively. As much as 60-80% of all COBOL code is boilerplate, that is, code which does not vary from one program to another. The boilerplate can be standardized and provided as program templates. 

With object methods, the boilerplate in an object package is minimal but still can be standardized. The remaining code is either reused or customized. The types of COBOL template programs, for instance, a report with a sort, do not exist in the same form as objects. There might be a report object and there might be a sort object, and both might be reusable, but the code for using either object is most likely provided by custom developed code.