>>This article is published at SEPG Egypt at http://www.secc.org.eg/

Software reuse is a comprehensive issue; without taking into account all perspectives, it could fail. Here we are trying to look at different angles and highlight several issues.

Business View:

First, senior management should take reusability into consideration. Loading technical team alone with the reusability efforts will not normally succeed. It should start from top management. As opposed to seeing the business as developing a certain product for some customer, senior management should look at the business as developing an application family to satisfy different client’s needs. The business focus here will affect all efforts after it. As example, HP shifted their thinking from developing a new printer driver for each new printer to developing a reusable family of drivers. The result was a huge saving in cost and improved quality.

Requirements:

After focusing on a new business perspective regarding what is really required, reusing is shifted to create requirements with focus on reusability. Requirements even could be restated to match certain reusable components features. Requirements analysis phase will follow by creating use cases focused on variability points. The following example will explain the concept of determining variability points:

Vacation Request:

1. Employee requests vacation from his direct manager

2. Direct Manager retrieves balance from Human Resources

If there is no balance

3. The vacation request is rejected

If vacation is more than 3 days, Direct Manager forward to Senior Manager

4. Senior Manager approves or rejects the vacation request

If vacation is more than 3 days

5. SM needs to receive email notification

6. Direct manager approves or rejects the vacation

In some companies they don’t escalate to senior manager the vacation for whatever reason. The Direct manager always has permission to approve or reject the vacation request. We will mark variability with curly brackets {}.

1. Employee requests vacation from his direct manager

2. Direct Manager retrieves balance from Human Resources

If there is no balance

3. The vacation request is rejected

If {StrictSMFollowUp}

If vacation is more than [ApproveLimit] days,

4. Direct Manager forwards to Senior Manager

5. Senior Manager approves or rejects the vacation request

If vacation is more than {NotificationLimit} days

6. SM needs to receive email notification

7. Direct manager approves or reject the vacation

The StrictSMFollowUp is variable; it could be true or false based on the way the organization work. In our example, we classified the businesses that will use our application, some have strict SM follow-up, and others have not.

ApproveLimit states the max number of days Direct Manager allowed to approve without consulting Senior Manager. NotificationLimit states the max count of days that need no notification.

The above is just an example to identify variability points in the requirements. We can use many ways to mark variability in the requirements that makes sense for our own applications.

Variability Implementation:

• Inheritance: As an example, in a typical application we wanted to support different database servers. You can select the basic reference dbase and create classes to implement it. Each other new dbase could inherit from the base classes and override essential operations. As the basic SQL construct are the same between databases, you should centralize the variability in specific classes.
• Parameter: You can have pages or screens with customization parameters. Administrators have the permission to customize the system. As example, the timeout of waiting the response from the external bank server.
• Configuration: In many cases you can use extensive configuration files to adapt the behavior of the system. In some systems you can even specify a complete alternate component through the configuration file. As example, specifying another XML parser. In this case, your application should use standard XML parser interface and the new parser should implement the same interface.

Architecture and Design:

Building the architecture and design in a way that makes configurability and reusability easier is an important issue. Layered architecture and components based design make it easier for you to achieve better designs.

Focusing on using known architecture and design patterns will make it easier for you to build state of the art architecture and design. Explaining patterns is outside the scope of this article, but some references will be listed in the references section.

Reusable Asset Library:

Having a reusable assets library with processes that define how to reuse a certain component, how to add new component and how to update existing component is important of reuse success.

A traceability table that traces each component version with which products are using it is required to guide in updating the applications with new components updates if necessary.

Asset library should be organized so that each one item should has:

• Version number. A unique version number to the library item.
• Status: is it ready for reuse or still in beta state.
• Bin reusable component (if exist) such as DLL files or OCX files.
• Documentation: A simple document that specify how to use. A sample code will help component users to use it effectively.
• Release notes: This can specify what bugs are solved, new features, or knows issues compared to the earlier version of the same component.
• Source code: if applicable.

Process Support:

We will describe basic processes to help managing the reusable asset library. We will not state the details of each one.

1. Add new reusable code item: The steps needed and standards that should be satisfied in the new reusable code item.
2. Delete reusable code item: Remove a typical item as it is no longer used nor supported.
3. Update reusable code item: A new revision is created and needs to be available in the repository.
4. Use typical reusable code item: reusing should be organized to know the full dependencies between reusable code items and applications that use it.
5. Requirements development process should have activities for requirements development to guide in stating techniques and methods to state the variability points.
6. Architecture and design process should be stating using typical techniques to help focusing on reusability.
7. Testing processes should take into account testing variability points comprehensively.

Before adding a new version to the library, an extensive test and peer review is done to make sure the component is meeting quality requirements.

A common challenge is what to do with a large set of reusable code, should we create a project to organize them and add them to the new empty asset library? Or just focus on the new reusable components?

Without first closing the sink that continuously diminishes reusable code, we will always have the case of old code that need cleaning to be added to the reusable code repository. So first establish a system to close all waste holes and in parallel clean up and restructure old code.

Conclusion:

Whatever your company size and experience are, you can not simply order reuse or install it at once and expect it to happen. Rather, you should encourage reuse by following many steps as described in this article. Although reusability conceptually is a simple idea, many efforts should be done to realize its benefits. This article was an attempt to highlight many of these issues.

References:

• Software Reuse, Architecture, Process, and Organization fir Buisess Success by Jacobson, Martin Griss, and Patrik Jonsson
• Design Patterns, GOF, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
• Pattern Oriented Software Architecture, a system of Patterns, Volume 1 by Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sornmerlad, and Michael Stal.
• Patterns of Enterprise Application Architecture, By Martin Fowler, David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, Randy Stafford.