Software Reuse Issues and Methods

Pruthvi P, Sukruth Ananth

1

National Institute Of Technology Karnataka,India, 2National Institute Of Technology Karnataka,India Pruthvip15@gmail.com,ananath.sukruth@gmail.com

Abstract- Promoting software reuse practice requires more

effective support. In this paper we discuss some problems in current software reuse systems and how different methods can be employed to tackle these problems and we have provided a comparison study on the various models used in software reuse and picked the best method based on the comparative study. Keywords: Software reuse; Domain analysis; Software reuse issues; Software reuse methods I. INTRODUCTION Software reuse has been practiced informally since programming was invented. Programmers have been reusing algorithms, sections of code from previous programs, and subroutines from functional collections. They also adapt and reverse-engineer existing systems. All this, however, is done informally and very much ad-hoc. Substantial quality and productivity pay-off from reuse are only achieved if conducted systematically and formally. When software systems are developed with the concept of software reuse, fewer total lines of code may need to be written and also the amount of documentation and testing may be reduced. That is, software reuse should increase productivity. Increased 'productivity will reduce development cost and schedule overruns. Since reusable software resources have usually been rigorously tested and verified, software quality should also be improved by software reuse. Implementation of software Reuse in any organization: Analyze the application area or domain Identify and isolate common structures, templates, or recurring designs Make those structures generic and standardize their interfaces Identify common components operations, functions, or

The above steps will set up a reuse infrastructure which following groups: Asset Management Group- provides initiatives, funding, and policies for reuse. Identification and Qualification Group- identifies potential reusability areas, identifies common structures, designs common interfaces, and specifies reusable components. This group is also responsible for collecting and procuring new additions to the collection and for asset certification. Domain analysts and domain experts are key elements in this group. Maintenance Group- maintains and updates reusable software components. Development Group- creates new reusable components Reuser Support Group- assists and trains users and runs tests and evaluations of reusable components. Librarian- updates and distributes catalogs, classifies new assets, maintains library system, and manages asset requests.

II. MOTIVATION

There are several benefits associated with software reusability such as increased dependability,reduced process risk,standards compliance, and accelereated development. Early software reuse efforts focused on small-grained reuse of software code.As a result,the cost of creation and use of these small-grained assets often outweighed the modest gains.Fortunately,over the years reuse technology has evolved from subroutines towards large-scale and systematic reuse.Actually,companies have a competitive advantage when they understand their domains and implement systematic reuse.

Redesign or update common components to fit the common structures using standard interfaces Document and catalog components and make them available (preferably through a common library) Train engineers in the new way of software development by composition

2.1 Economic Cost

The source of the implementation problem resides mainly in the perception that reuse must be implemented in a single step, like building an assembly plant. In order to mitigate the high up-front cost , an incremental and progressive adoption of reuse. An organization may start with a small, low cost, low risk effort and progress towards a full blown formal reuse program in stages. Each new stage is initiated based on the results of the previous stage. A set of possible

stages is described below. During the initial stage existing software can be analyzed for selecting potentially reusable components (i.e., source code, documentation, designs, requirements, whole subsystems, etc.) A catalog describing these components should be produced and distributed to all engineers. This first catalog should raise the level of awareness about reuse and stimulate other individuals to identify potentially reusable components. As components are reused, metrics and experience records should be kept. Some work on domain selection and analysis can also be started during this stage. This initial stage can be at the project level involving one part time individual at almost negligible cost. The next stage can be started after assessing the first. A condition to continue should be that the effort is paying off if engineers are beginning to reuse and cost savings can be measured. Frequency of reuse should indicate which components are the most popular and which are not being used. This information should provide guidance in the domain analysis effort. Catalog expansion should be promoted through an improved mechanism of incentives and rewards and a common reuse library should be made available. Communication between domain analysts, reusers, and domain experts should be established and a formal domain analysis effort started. This second stage may require stronger commitment from management in the form of resources and support as well as a higher demand on the budget.

One of the objectives in pre-planned reuse is to have a repeatable process for doing domain analysis. The three leading methods for domain analysis are: FODA (Feature Oriented Domain Analysis) from the Software Engineering Institute in Pittsburgh; the STARS Reuse Library Process Model, also known as the Sandwich method; and the Domain Analysis and Design Process from DISA/CIM (Defense Information Systems Agency/Center for Information Management), in Arlington, VA.

III. COMPARATIVE STUDY

3.1 FODA
FODA is based on identifying features" of a class of systems. A feature is a prominent, user visible aspect of a system. Domain analysts identify both features that are common to all systems, and features that distinguish individual systems or subclasses of systems within a domain. The FODA method defines three basic activities: 1context analysis, 2- domain modeling, and 3- architecture modeling. During context analysis, domain analysts interact with users and domain experts to bound and scope the domain and to select sources of information. The products of context analysis include structure and context diagrams. Domain modeling produces a domain model in multiple views. The domain analyst proposes the domain model to domain experts, users, and requirements analysts for review. The resulting model includes four views: features model, entity-relationship (E-R) model, data flow diagrams (DFD) model, and state-transition model. A standard vocabulary is also produced during domain modeling. During architecture modeling the domain analyst produces an architectural model that consists of a process interaction model and a module structure chart. The objective of the architectural model is to guide developers in the construction of applications and to provide mappings from the domain models to the architecture.

2.2 Domain analysis

The following stage should focus on domain analysis. As the reuse program continues to demonstrate its worth, resources are allocated to finding common structures, templates, and architectures. At this time all infrastructure groups should be fully functional. The implementation of the infrastructure may range from a single individual performing multiple tasks to a team of two or three individuals per group. Since domain analysis is a laborintensive activity, the suggested approach is to focus on a subdomain with high potential for commonality either within the same product line or across product lines. The objective is to demonstrate the value of pre-planed reuse by deploying basic patterns or structures and a set of common reusable components. The components may be re-engineered versions of popular components from the library. Training on how to use these templates should be part of this stage. Subsequent stages should be refinements and extensions of the previous two. Each increment should be assessed thoroughly and continuous improvements should be enforced. After several stages, a reuse program is bound to reach a steady state where reuse-based software development becomes the norm and requirements for new systems can be drafted based on what is there that can be reused. New systems then, can be implemented from slight variations of the common structures.

3.2 Sandwich
The Sandwich approach is based on methods for deriving classification schemes in library science and on methods for systems analysis bottom-up activities are supported by the classification process and top-down activities by systems analysis. The objective in this method is to produce domain models in the form of a generic architecture or standard designs. To guarantee reuse, low level components must act as building blocks for composing a skeleton design or architecture. This is accomplished by the bottom-up identification and classification of low level common functions and by standardizing their interfaces. Generic architectures are the outcome of top-down analysis of high level designs, domain concepts, and requirements of current and future systems. The products of the bottom-up analysis are

associated with the structures derived by top-down resulting in a natural match between high level generic models and low level components using domain models as skeleton guides.

IV. Conclusion This paper reviews a number of issues and attempts to provide recommendations on the steps taken for reuse to become an accepted reality.On the basis of the comparative study Sandwitch method is the best method and should be applied for domain analysis for softeare reuse projects.

3.3 Domain Analysis and Design Process

The Domain Analysis and Design Process from DISA/CIM are a collage of several techniques. It contains many of the elements of the sandwich approach but extends it to cover design and development of domain specific architectures and places more emphasis on the top-down process. The DISA/CIM guidelines borrow concepts from object oriented analysis and cover very thoroughly the process of scoping and selecting a domain. The high level activities include identify domain, scope the domain, analyze domain (the core activity), and design domain (i.e., architecture development). Being the most recent and comprehensive technique, it seems very promising.

ACKNOWLEDGMENT This work has been developed under the guidance of Prof. K Chandrasekaran

REFERENCES

FODA SANDWICH

Domain Analysis and Design Process Yes No No

[1] Jag Sodhi and Prince Sodhi, Software Reuse: Domain Analysis and Design Process [2] Ronald J Leach , Methods,Models, and Cost. Software Reuse :

[3] Capt James E.Cardow ,Issues On Software Reuse [4] Allessandro Dionisii ,Azza Mansour, FODAcom:An Experience with Domain Analysis in the Italian Telecom Idustry. [5] Matthieu DABIN ,Software Reuse and Case Tools

Top down Bottom Up Classification of low level components User Input Matching of High Level and Low level Components

No No No

Yes Yes Yes

Yes No

Yes Yes

Yes No

[6] Kyo C Kang James A Hess ,Feature Oriented Domain Analysis (FODA) Feasibility Study. [7] Yongbeom Kim Edward A Stohr , Software reuse and Research Directions

IV. C ASE STUDY Let us look at the top-down and bottom-up approach of building of a car.considering bottomup approach first,we need to look at the different components of the car.The different components of a car are tyres,gears,shaft,suspension,brakes,stering.This separation helped us to properly scope the domain and draw a domain boundary. For the top-down approach we have to take the car as a whole and then we need to look at the individual components of the car and we can do a check by doing both these approaches to check for the maximum reuse of the different components and check the domain.