CSC/ECE 517 Fall 2010/ch3 1b SP

Definition A pre-written program code being used either partially or completely when a similar functionality is required in program, is known as Code Reuse. Wikipedia defines code reuse as, Code reuse, also called software reuse, is the use of existing software, or software knowledge, to build new software. [1]

Contents

Overview Types of code reuse Techniques Advantages Disadvantages See also References

Overview Code reuse is common practice in computer programming. Either ad hoc or systematically but programmers have always reused sections of code to save time and other resources in software development. Consider simple C++ code where print_line function is used more than once. This example explains basic code reuse concept.

void print_line () { puts("-------------------------------------------"); } void print_firstname(char* first_name) { puts(first_name); print_line(); } void print_lastname(char* last_name) { puts(last_name); print_line(); }

Sometimes even simple copy-paste programming [2] is also considered as type of code reuse.

Though such traditional methods exist for code reuse, Douglas McIlroy [3] of Bell Laboratories efforts made code reuse as area of study in software engineering. In modern practice, code reuse can be achieved using Object Oriented Programming, Software Libraries, Software product line engineering, etc. Few of such software engineering methods useful for code reuse are explained in techniques.

Types of code reuse

One of the code reuse can be categorized as [4] • Opportunistic reuse – Assume a programmer is writing code for indexing. After he sorts index file the next step is to use those index keys for better access to the records in disk. While developing that code he realizes that he can use binary search for better results which could have been implemented previously by some other developer in team. Now he searches libraries for required code and then reuses it with available interface. In this example developer has to be aware of opportunities for reuse and be motivated to search, retrieve and reuse such components. This type of reuse is very common in software practices. Any content can be reused by this type.

• Systematic reuse (planned reuse) – A company develops a code to support house-holding machines like microwaves or washing machines. Every year company launches one or two new models in market. Though models are new the basic functionalities remain same for all. While developing few models at the beginning, company took a systematic reuse approach by maintaining modularity in code. Hence while developing code for any new upcoming model, management system decides on which components are to be reused and add them in documents. Hence developer doesn’t need to go through the process of determining, finding, retrieving and inserting reusable components while developing any new functionality. He may not be even aware of such reused components. This approach needs more cost and technology to implement as it requires more planning and design procedures to be followed.

Another way code reuse can be categorized as [5] • Internal reuse – In this type of reuse, all the components are developed by the team itself for later use within system. Some critical components are maintained using this type.

• External reuse – Though it costs high, sometimes using license versions of standard components saves overall development time. Hence system prefers to use external components in code.

Code reuse can also be categorized as [6] • Action reuse – Set of instructions that carry certain action can be separated out from other code and pack in different module or function which can be reused at more than one place in code. This is referred as action reuse as separated out code performs some specific action.

• Context reuse – set of instructions is separated out from other code which is performed before and after number of actions is referred as context reuse. For example, different operations like read, write, sort or retrieve can be performed on file, whereas before every action we need to open file and after every operation we need to close files. Since this context is common for all actions we can separate it out from other code and use that set of instructions at number of times through function call or any other interfaces.

Techniques

Many software engineering techniques support code reuse these days. But not all the code that is developed is made reusable. The problem is about selecting which components to make reusable. For Example, Development of large scale packaged software such as user interfaces and middleware relies on reusing a few well-known building blocks, but customized business applications involves a large number of domain-specific components of different granularity.

The developer has to decide the level of abstraction at which the components will be written. And reusability has to be taken in account not only while reusing components but even while developing such reusable components. The developer has to decide the level of abstraction at which the components will be written. Such reusable components are developed by 1. Developers when they are developing their code. 2. Dedicated developers specially assigned to develop reusable components in library.

While writing reusable code, developer has to take factors into consideration like modularization, code-level Generation, separate code for business logic & framework, DRY principle and loose coupling.

All such reusable objects, components or code pieces reside in same repository and are available for use. Many times such repositories are not indexed and this increases search period. In practice it is found that programmers prefer to write their own code instead of searching them in common repository. Hence management of such reusable components is equally important in code reuse.

Here we cover few software techniques which support code reusability

Component based development [Roger pressman (2001), Software Engineering: A practitioner’s Approach] – Object Oriented technologies provide base for component based development. This model adds assumes classes as unit of reusability. It incorporates iterative nature of spiral model with support of library. At the start of activity developer identifies classes by examining data and operations to be performed. These classes are searched in library, if found they get reused and if not they get developed. But if any new class gets developed they get added in library for reusing it next time. This way library gets built simultaneously with development.

http://www.objectmentor.com/publications/granularity.pdf]

The Reuse/Release Equivalence Principle (REP) [7] - If code is copied from source and if any bug gets resolved in original code, changes should affect all the copies, which is difficult to maintain. Reusing released code is preferable any time as tracking release versions is better than tracking unreleased code changes. This technique considers component as unit of reuse and release.

The Common Reuse Principle (CRP) –This principle considers code reuse at component level but not at class level. This means that even for requirement of few classes many times we need to reuse complete package which contains number of classes coupled together tightly. As we use set of classes together, it is important to decide which classes should be packed together in component. The common reuse principle helps to decide on such class selection in package. When developer develops any code, in normal practice he tries to put together all classes which are dependent on each other from functional point of view, whereas this principle approach suggests to bind all classes together which can be reused together.

The Common Closure Principle CCP) – Change is inevitable in any software system and maintenance is necessary to follow proper changes. This principle suggests that classes which are dependent on each other should be bind together in one package, so that all the classes in package are likely to go for same change in future. Hence change is restricted to minimum number of packages in future.

The Acyclic Dependencies Principle (ADP) – When many developers are working on same source file there are high chances that their code will affect on each other. Due to this sometimes the code written newly becomes ineffective as someone else has made some changes in same or dependent code. To avoid this ‘morning after syndrome’ [8], this principle suggests to partition development areas in releasable packages such that teams will work different parts of project which are releasable. When they get working modules they release their package to use by other teams. Only released packages are trusted to use. UML diagrams are used to identify such class and package dependencies in advance. Design takes into consideration of all packages and their dependencies and develops directed acyclic graph (DAG) [9] where packages represent graph nodes and edges represents dependencies.

There are many other techniques in software engineering which supports code reuse principle.

Advantages [10]

• Save time – Once the problem is solved and solution is made available in system, there is no need to resolve the same problem again or to code same solution as solution will be available readily. This leads to greater productivity. • Reduces bugs in system – Developing large code leads to lot of testing. Regression is very important in large systems as large system contains more bugs in it. Maintaining packages with software reusable principles makes testing better and more reliable. Sharing the code makes it less buggy. • Maintenance – Following code reuse principles makes it easy to maintain any large software. • Building libraries – Special subject libraries can be developed for future use. For example, library to support all database functionality in bank system. • Benefits of DRY principle – Code reuse principles strongly support DRY principle which avoids duplication of code or addition of unused instruction in code which leads to clean code avoiding code bloat [11]

Disadvantages [12]

• Problem using third party libraries – developer has to be dependent on interface provided by such third party libraries. Sometimes developers find it easy to develop required functionality instead of using such tightly coupled libraries. • Bugs get replicated – If source code is buggy, those bugs get replicated at reused places. • Legal issues – Some legal practices need to be followed while going for licensing any source code. • Poor documentation – if source libraries are not documented properly, it may happen that developer will spend more time understanding library functions than developing code. • Time learning new libraries – For short duration projects though code reuse saves considerable time, learning or configuration of external libraries may take more time than expected.

See Also

References