UConn CSE 298/300 - Analyzing and Measuring Reusability in Object-Oriented (12 pages)

Previewing pages 1, 2, 3, 4 of 12 page document View the full content.
View Full Document

Analyzing and Measuring Reusability in Object-Oriented



Previewing pages 1, 2, 3, 4 of actual document.

View the full content.
View Full Document
View Full Document

Analyzing and Measuring Reusability in Object-Oriented

118 views


Pages:
12
School:
University Of Connecticut
Course:
Cse 298/300 - Distributed Object Computing
Distributed Object Computing Documents
Unformatted text preview:

Analyzing and Measuring Reusability in Object Oriented Designs I Steven A Demurjian Sr The University of Connecticut Compdter Science En grg Dept 191 Auditori Rd U 155 Sterrs CT 0626Q13155 JJSA tl860 486 4818 steveQeng2 uconn edu Margaretha W Price MountainNet Inc 2816 Cranberry Square Morgantown WV 26505 9289 USA l 304 594 9075 ext 28 mpriceQrbse mountain net ABSTRACT In this paper we present a technique to analyze and measure the reusability of object oriented 00 designs The metrics can be incorporated into a design development environment so that reusability measurements analysis and improvements can be part of Ubusiness as usual for an organization Design reusability measurements also enable early identification of poor reuse potential when it is still possible to modify refine the design The essential components of our approach are two reuse specific characterizations of classes and hierarchies and a set of metrics which objectively measures the dependencies among design components based on those reuse specific characterizations 1 INTRODUCTION Software components that are reused most often tend to be small components since they are normally less specific i e string functions abstract data types ADT or utility routines and thus more likely needed by other systems However small code reuse produces minimal savings representing only a small percentage of the final product 2 Poulin argues that there are three classes of software that make up a typical software application 20 s Domain independent 20 of the whole application This includes ADTs utility routines math libraries and other components which are useful in a wide range of problem areas l l Domain specific 65 of the whole application This is for software which is only useful within the specific domain The examples given include high speed communications device drivers navigational aids for aircraft and financial services libraries Application specific 15 of the whole application This includes software which implements the unique details of an application Permission to make digital hard copy of part or all this work personal or classroom use is granted without fee provided copies are not made or distributed for profit or commercial for that advan tage the copyright notice the title of the publication and its date appear and notice is given that copying is by permission of ACM Inc To copy otherwise to republish to post on servers or to redistribute to lists requires prior specific OOPSLA 97 IO 97 GA USA 0 1997 ACM permission and or a fee 0 89791 9084 97 0010 3 50 22 I 1i From the above breakdown we can expect the most savings if we reuse the domain specific soft ire Software companies do not have to make their software be reusable in all systems but they only have to niakemtheir software reusable in anticipated future systems in their organizations Our approach to reusability measurement facilitates domain specific reuse particularly domain and organization specific reuse This more restrictive goal of reusability makes domain analysis more manageable thereby minimizing the impact of the actual domain on the potential reuse 1 I The design of a program is normally described in terms of the program s components and the interactions among them 6 Our reusability metrics measure the level of interactions of software design components whJch are expected to be ieused together to the components that comprise the rest of the system Most of the implementation details are not specified in software designs thus the software designer has a significant amount of flexibility in modifying portions of a existing design to accommodate future systems thereby attviining design reuse b Figure 1 illustrates an 00 design development process ch incorporates design reusability measurements A software engineer starts the process by designing a system After the major components of the system and the interactions between them have been determined our metrics can be used to identify measure and provide feedbnck on the reusability of the 00 design The software designers then have the opportunity to modify their 00 design and reevaluate the reusability of their system The two arrows 1 can be repeated as many times as necessary in an iterative process that is intended to make the 00 design more complete After the reusable portions have been clearly identified and it has been determined that there exists no interactions which inhibit reuse we can store the design and d ocument the system architecture 2 Step 3 leads to the implementation process object coding testing and debugging and the storing of the completed implementation 4 Future software projects will then have the choice to reuse a previous 00 design 5 and its corresponding implementation 6 or just reuse the design and write a new implementation In some cases it may be necessary to revisit earlier stages of this process after the implementation has commenced i A I t Re design a system 6 1 i I 2 reusability evaluation I Store document implementations the criteria at the class hierarchy level of abstraction and to study the reusability of a class hierarchy as a whole portions of a class hierarchy or a set of related class hierarchies Thi s has also been argued in another context namely that the unit of abstraction for 00 applications should not only be at the cl s object type level but also at the class hierarchy Ievel 7J A class hierarchy is the result of an 00 mechanism referred to as inketitance or class deriuation Class inheritance allows members functions and data of one class parent to be used as if they were members of another class child or subclass During system design class hierarchies are used to group similar classes so that they can have one parent class containing the common operations and or data The subclasses ll then only need to define operations data specific to each subclass Thus a class is only made to be a child of another class if it needs some members of the parent class Consequently it is the nature of 00 design with inheritance to migrate more general information and operations up the hierarchy where they can be reused by all descendants while simultaneously pushing domain specific information and operations down the hierarchy where their potential reuse is limited Prom a reuse perspective since a child class needs members of its parent if we want to reuse a child class we have to also reuse the parent class However if we want to reuse the parent class we are not required to


View Full Document

Access the best Study Guides, Lecture Notes and Practice Exams

Loading Unlocking...
Login

Join to view Analyzing and Measuring Reusability in Object-Oriented and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Analyzing and Measuring Reusability in Object-Oriented and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?