An Object-Oriented Database Model for Integrated Software Reuse in Computer-Aided Software Engineering (CASE) Jeffrey S. Poulin Systems Software Development Tools International Business Machines Corporation Abstract: The success and acceptance of reuse tools and libraries depends on _____________________________________________________________________ their integration into existing software development environments. However, ____________________________________________________________________________ the addition of large libraries of reusable components to software design _________________________________________________________________________ databases only exacerbates the problem of design data management. Object- __________________________________________________________________________ oriented databases originated to meet the requirements of design data manage- _____________________________________________________________________________ ment that relational databases could not satisfy. This paper describes a _________________________________________________________________________ semantic data model for an object-oriented database supporting an integrated ____________________________________________________________________________ Computer Aided Software Engineering environment (CASE). The data model pro- ____________________________________________________________________________ motes reuse by providing objects that match program design requirements to __________________________________________________________________________ existing components in the reuse library. _________________________________________ KEYWORDS: Software reuse, Computer-Aided Software Engineering, CASE, Semantic data modelling, Object-Oriented Database Systems. 1 OVERVIEW ________ To successfully insert reuse into the software development process, we must integrate support for reuse into existing software tools and CASE environ- ments Ý15¨. Even in current CASE systems, software developers cannot conven- iently search reuse libraries. A programmer often has to exit the programming environment, use a limited set of tools to search for possible reusable components, then reenter the design environment. This causes the programmer to not only break important lines of thought in problem solving but also to make an additional investment in time and effort. This addi- tional effort often prevents reuse from taking place. Therefore, we believe that the success of reuse technology depends on the integration of reuse libraries into our design and programming environments Ý23¨. Our work in CAD/CAM systems for VLSI shows the importance of modeling design data in a way that supports the developer Ý18¨. We believe successful design systems for both CAD and CASE require an underlying data model that matches the user's conceptual view of the problem. To this end we built on existing CAD/CAM modeling techniques and created a data model for CASE that specif- ically supports software reuse. One attribute of software that makes it more difficult to produce than hard- ware comes from the relatively abstract nature of problem solving. Physical bounds do not constrain software components and designs as they do for hard- ware. The "hardness" of packaging assists hardware designers not only by providing physical limits (and challenges) but also by allowing them to see what they build Ý7¨. In contrast, we find it much more difficult to quantify and describe the ideas and concepts that make up software. This complicates software reuse because we do not generally have formal methods to specify requirements for what we need nor do we have verifiable ways to catalog what we have created. The cross-lifecyle nature of reuse has enormous potential benefits if inte- grated into a CASE system that guides development of software across the entire lifecycle. Reuse of requirements and high level design early in the design process results in the reuse of subsequent lifecycle products Ý14¨. We emphasize the importance of reuse early in the lifecycle by attempting to match developing requirements and designs with reusable components in the reuse library. This paper describes design data management issues and sol- ution techniques. The paper then describes semantic data modeling for CASE and an implementation built using our model. 2 DATA MANAGEMENT IN CAD AND CASE _______________________________ Storing software design data causes difficulties due to the many forms it may take. Not only do requirements, design, test cases, code, all have different formats and potentially different media, various classifications and descriptions may represent the information. Describing and defining the abstract nature of the work products exceeds the capabilities of the tradi- tional relational model. Today's workstation-based design systems must store and manipulate data rich in semantics and programmer knowledge. LIMITATIONS OF THE RELATIONAL MODEL ___________________________________ The success of the relational model for business and management does not fully extend to design applications. The relational model imposes restrictions on data representation due to the simple and powerful method used to organize data into tables. Each item in the database must fit the model established by the columns in the tables; storage difficulties arise with items that do not fit the well-defined relational model. Furthermore, the relational model does not explicitly include semantics regarding the information contained in the tables. This requires application programs to interpret and enforce all semantics. Because real-world objects do not fit well into the relational model, we must make artificial manipulations or extensions to accommodate the data. These techniques can not only adversely affect efficiency and performance but can also cause the loss of important semantic information Ý10¨. DATA MODELS FOR CAD/CAM _______________________ Although many VLSI and CAD/CAM systems use relational databases, many researchers recognize the inadequacy of the relational model for representing and storing design data Ý9¨. To meet the need for a powerful and straight- forward representation of design objects, complex objects and object-oriented databases emerged. Complex objects consist of hierarchical groups of tuples starting with a root tuple that represents the design object, and sets of dependent tuples that define the object. Complex objects can succinctly rep- resent the recursive, non-disjoint objects that the relational model cannot easily handle Ý12¨, Ý13¨. Design data commonly includes recursive data because real world objects often consist of smaller objects which retain many of the characteristics of the entire object. The following examples show how we can represent data modelling abstractions Ý24¨ using a tuple format: 1. Aggregation Abstractions- requires all tuple members. For example, a Point has both X and Y coordinates. Point : (X: real, Y: real) 2. Generalization Abstractions- requires at most one tuple member. For example, we can declare Numbers of type INTEGER or of type REAL. Data Management in CAD and CASE 3 Number : (INTEGER: integer + REAL: real) 3. Aggregation with Association Abstractions- requires all tuple members, zero or more times. For example, a Polygon has any number (0-N) of (X,Y) coordinate pairs. Polygon : (X: real, Y: real)(*) 4. Generalization with Association Abstractions- requires at most one tuple member, zero or more times. For example, a Number_collection may have 0-N numbers, each of either type INTEGER or of type REAL. Number_collection : (INTEGER: integer + REAL: real)(*) The molecular object model serves as an important example of a complex-object based model. Developed for VLSI CAD systems, the model defines two distinct parts; an interface and an implementation Ý2¨, Ý5¨. The interface of the object consists of all connections to the outside world and defines how other objects use and access the object. The implementation of the object defines how the object does its job. An interface may have several implementations. In VLSI, a molecular representation of a circuit would have an interface con- sisting of a list of pins and an implementation consisting subcircuits and the wires that interconnect them. When using the molecular model, a designer may refer to an interface without specifying an implementation for the interface. If the designer chooses not to specify, or bind, an implementation to the interface, we refer to the un- _____ bound interface as a socket in the design of the circuit. The designer must ______ specify an implementation for the interface by plugging the socket before he ________ can complete the design. The plugged socket results in an instance of the ________ subcircuit implementation in the design of the circuit. The molecular object model conceptually matches the way VLSI designers create circuits. VLSI designers create circuits by recursively decomposing the circuit into smaller subcircuits. When implementations for the subcircuits exist, they get wired into the design without alteration. When they do not exist, the designer must implement the subcircuit using basic gates and wires. The molecular object model succeeds in VLSI CAD systems because the semantics of the molecular model match the VLSI design process. DATA MODELS FOR CASE ____________________ Data models for CASE have many of the same requirements as those for VLSI CAD and other CAD/CAM data models Ý17¨, Ý21¨, Ý25¨. We believe the key to storing CASE design data lies in the underlying semantic data model used to represent the information. The more the model maps to the user's conceptual view of the program, the greater it will support his needs. Furthermore, a data model that provides a single representation of the design data provides better space utilization, reduced complexity of the database, and improves data integrity by guaranteeing that multiple copies of the same information do not become inconsistent. 4 We base our work with CASE data models on that of CAD/CAM data modeling because of our previous work in VLSI CAD systems. We also recognize the natural correspondence between the molecular view of VLSI objects and the object-based view of software modules. For example, inputs and outputs in the VLSI interface consist of a pin-list, which has an analogy in the _________ parameter-list of the software interface. Furthermore, the VLSI implementa- ______________ tion consists of gates, subcircuits, and wires, which have an analogy in the data declarations, subprograms, and program statements of the software imple- mentation. However, molecular concepts and definitions do not fully map onto those for software. First, the concept of instantiation has a different meaning in _____________ programming than it does in VLSI. In VLSI, instances of components refer to copies of the component. Although the database records only one definition of the component, in the final hardware product every instance of the compo- nent in the design results in a copy of that circuit in silicon. The soft- ware concept of instantiation has a different meaning. In the final software product, just as in software design, only one copy of the component exists.(1) Calls to subprograms take the form of references to software ser- vices. Normally, copies of that service do not exist until execution of the program. We do not find this view of instantiation, which implies the cre- ation of multiple copies of the design object, appropriate for software. +---------------------------------------------------------------------------+ | | | In the module specification: | | | | Procedure Sort (Var | ___________________ | Variable1: ArrayÝmin..max¨ of integer, | ______________________________________ | Variable2: Boolean); | ____________________ | | | In the module call: | | | | Sort(Integer_array, Error_flag); | ________________________________ | | +---------------------------------------------------------------------------+ Figure 1. The two roles of the software interface. As shown in Figure 1, the second change to the VLSI molecular model involves the dual role of the software interface. The interface found in the software specification (e.g., declaration) and the interface found in the software requirements (e.g., design) have different functions. In the first case, the interface represents a reusable module. Because the interface represents __________ possibly multiple implementations and versions of the module, we must limit how the user can modify the interface. The interface in the design, however, represents a request for service. It differs from the interface in the spec- ification because it evolves with the design. During early phases of the --------------- (1) We consider macros as an implementation technique used for efficiency. Although multiple copies of macros may exist (just as in VLSI) the soft- ware designer treats them in concept like other dynamically expanded __________ software services. Data Management in CAD and CASE 5 design the service request may not represent any actual software module. But as the design develops, the specification evolves into either: o a new module, or, o a call to an existing reusable module. Ideally, the designer fills the software specification with an existing module. Operations on the object should guide the designer towards satis- fying his needs with existing reusable software. THE INTERACTIVE DEVELOPMENT MODEL _________________________________ Our model extends the two-part molecular model to fully support the unique requirements of the software design process. We do this by providing a form of meta-interface for the designer to use while he develops the software ______________ requirements. We call this new object type a Call and refer to the ____ resulting three-part model as the Interactive Development Model (IDM). The Interface portion of the IDM gives a specification of the module behavior, thereby serving the declarative role of the interface in the VLSI molecular model. The Alternative portion of the IDM describes the design, code, and implementation details of the software module. The Call serves to abstractly represent software requirements. As shown in Figure 2, a reusable software library consists of a generalization with association abstraction of the three IDM objects where each IDM object serves as a base type in the data- base. The following paragraphs describe each of the three IDM objects in more detail. +---------------------------------------------------------------------------+ | | | Reuse_Library: | | (Call: call + | | Interface: interface + | | Alternative: alternative)(*) | | | | | +---------------------------------------------------------------------------+ Figure 2. Reusable software library data model The Interface The Interface object represents all implementations for the module. It con- sists of four major components: Header, Classifiers, Parameters, and Alterna- tives. The Header component contains the administrative information about the Interface; e.g., the designer name, date of creation, and owning organ- ization. The Classifiers component contains information describing the Interface. The classification information describes the function and purpose of the service that the Interface represents. In part, the Classifiers contain an aggregation with association abstraction of descriptive keywords, but this can vary depending on local requirements. The Parameters component also consists of an aggregation with association abstraction containing all data input and output by the Interface. The final component, Alternatives, 6 contains an aggregation with association abstraction of all valid Alterna- tives existing to implement the Interface. +---------------------------------------------------------------------------+ | | | Interface: | | (Header: header_info, | | Classifiers: classifier_info, | | Parameters: param_list, | | Alternatives: alt_list) | | | | | +---------------------------------------------------------------------------+ Figure 3. The IDM Interface The Alternative The Alternative represents an implementation of an Interface; an Interface may have several implementation Alternatives. The Alternative object con- sists of six major components; the first two components closely match those of the Interface. The Header contains administrative information about the Interface and Classifiers contains descriptive information about the function and purpose of the Alternative. The Declarations component consists of an aggregation with association abstraction of required local variables or vari- ables in the functional scope of the Alternative. Although the same kind of abstraction, Performance_attributes differs from Classifiers in that it con- tains information about externally visible properties of the Alternative, such as the space or time complexity for a given input. The Body of the Alternative consists of a generalization with association abstraction of requirements represented by Call objects. We use a generalization abstraction rather than aggregation to allow for program constructs such as iteration and conditionals. By identifying these program constructs we can map the design into a pseudocode for use during the coding phase of develop- ment. Finally, the Versions component manages the configuration and version control by linking descendent versions of the Alternative. +---------------------------------------------------------------------------+ | | | Alternative: | | (Header: header_info, | | Classifiers: classifier_info, | | Declarations: declare_list, | | Performance_attributes: performance_data, | | Versions: version_list, | | Body: call_list) | | | | | +---------------------------------------------------------------------------+ Figure 4. The IDM Alternative Data Management in CAD and CASE 7 The Call The Call represents requirements for a software service. As the designer works, he creates a more detailed description of the required service using the Call object. At a high level, requirements engineers and high level designers create and form the software service descriptions. Component level designers continue to evolve the design by further modifying and binding the Call objects with Interfaces. To complete implementation, coders either bind or develop Alternatives for the Interfaces already bound to the Call objects. The Call contains a Header and a Classifier component similar to the Inter- face and Alternative objects. The Call also contains a parameter list for anticipated input and output variables and a list of Performance_constraints. Both components consist of an aggregation with association abstraction. In general, the classification problem has a recurrent solution structure Ý6¨. A collection of data, generated from several sources, gets interpreted as a predefined pattern. The search proceeds by mapping the recognized pattern into a set of possible solutions from which the designer selects the most appropriate result for the given case. In the IDM, the search engine matches developing software requirements represented by the Call to existing reusable Interfaces and Alternatives using the components contained within the respective objects. The Classifier component in the Call represents the need; the Classifier component in the other two objects indicate what can meet the need. The search engine also matches the anticipated Parameters in the Call to existing Parameters in available Interfaces to complete the search. Finally, the search concludes when the Performance_attributes iden- tified in the Alternative object satisfy the Performance_constraints identi- fied in the Call object. Once the program designer examines and accepts an Interface and Alternative the designer binds the selected objects to the Call _____ using the simple aggregation abstractions provided by Bound_interface and Bound_alternative. +---------------------------------------------------------------------------+ | | | Call: | | (Header: header_info, | | Classifiers: classifier_info, | | Parameters: param_list, | | Performance_constraints: performance_data, | | Bound_interface: Interface, | | Bound_alternative: Alternative) | | | | | +---------------------------------------------------------------------------+ Figure 5. The IDM Call 8 PROTOTYPE SYSTEM ________________ A prototype developed in the ROSE (Relational Object System for Engineering) Database currently exists on DEC VAXstations. The object-oriented ROSE data model maps closely to the IDM and provides an excellent way to leverage our knowledge from CAD data management into CASE. ROSE consists of an integrated experimental database system, graphics, and user interface toolkit for developing CAD applications. The ROSE design gives fast object access by managing a cache of logical data clusters as physical objects. ROSE provides access to the database through a combination of powerful control structures based on the 'C' programming language and database commands extended from relational algebra Ý8¨. We can represent ROSE complex object data models in several ways. AND/OR trees Ý16¨ give an expressive representation of all abstractions when the user desires a schematic of the data model. Each node in the AND/OR tree serves to define the domain of an object or one of its sub-objects. Alter- nately, we can use the LISP-like tuple format to describe ROSE data struc- tures. The LISP notation has an advantage in that it maps closely to the internal storage tuples used by the ROSE object manager. The complete ROSE CASE system includes several graphical editors for design data input and a full GUI interface. Each editor presents the user with a view of the object base; because one underlying data model supports all views, a change in one view automatically results with all applicable changes in the other views. The tool supports structured design, program structure, and Input-Process-Output (IPO) design methods and views Ý3¨. The tools also allow multiple levels of abstraction for viewing each representation of the design. To support software reuse we classify design objects using facets Ý20¨ and free-text keywords Ý19¨. The ROSE CASE tool maps requirements specified by Call objects to Interfaces and Implementations using these classifiers. As the designer develops the requirements represented by the Call object, the search engine tries to identify existing Interface and Implementation objects matching the specification. The tool presents candidate reusable objects to the designer who may retrieve and examine them for possible use. When designer chooses a suitable object from the candidate list, he binds it to the call object. The designer may bind both an Interface and Implementation to the Call, or only bind an Interface. In this case, he leaves development of a suitable implementation for the coding phase. The designer completes the design by either binding all Call objects or leaving them unbound for later development. As shown in Figure 6, a program design consists of a col- lection of (either bound or unbound) Call objects. +---------------------------------------------------------------------------+ | | | Design: (Call: call)(*) | | | | | +---------------------------------------------------------------------------+ Figure 6. IDM program design representation Data Management in CAD and CASE 9 RELATED WORK ____________ The ARIES system uses a single underlying representation to store and present requirements knowledge Ý11¨. ARIES composes system descriptions from the following basic units: types, relations, events, and invariants. The system descriptions take the form of a collection of objects, each of which repres- ents some element of the system. However, although ARIES addresses reuse of requirements knowledge, ARIES focuses on presentation, reasoning, evolution of the knowledge. The CARE (Computer Aided Reuse Engineering) system at the University of Maryland supports a process model for extracting candidates for reusable com- ponents from existing software Ý1¨. CARE has two main parts, the component identifier and the component qualifier, and supports the derivation of program specifications and the verification of whether or not the programs meet those specifications. Techniques for classifying and identifying candidate reusable components include use of polymorphic types Ý22¨. Polymorphic types classify both defined components in a library and contexts of free variables in partially written programs. A system using polymorphic types may help programmers make better use of software libraries by implementing a retrieval system that matches the types representing software requirements to those defining existing reusable components. 10 FUTURE WORK ___________ We intend to extend the IDM by encapsulating retrieval algorithms and expert system strategies into the call object. A C++ implementation allows us to evaluate the feasibility of alternative reusable components through message passing and member functions. Upon receipt of a requirements message, the call object invokes the necessary methods to unify the requirement specifica- tion with available Alternatives. To support interoperability with other CASE systems and reuse libraries, we will extend the current database to record required information about member libraries and organizations. The database will contain library structure, physical location, access method, validation data, and other information required for interoperability. When the Call object fails to bind with a suitable local reusable interface and implementation, the object invokes a binding method against the database. The object then formats and initiates a query for associated libraries using the appropriate inference rules, query, and access method. When the object receives the query result, it evaluates binding options using the same rules as for local reusable objects. The database can also provide useful information about composite programs resulting from cross-library reuse. For example, the product test group can determine statistical reliability based on library quality data and can iden- tify modules without proven histories or test results. This information can help predict maintenance costs and resource allocation. Future Work 11 CONCLUSION __________ By dividing the molecular interface into a requirements object and a defi- nition object, the IDM permits a high level of flexibility during the design process. Since molecular interfaces define modules, the designer cannot modify an interface without affecting existing implementations or without creating a new object. However, Call objects represent requirement specifi- cations and may adapt interactively to the dynamic needs of the designer. The IDM provides support for all stages of the software engineering lifecycle. The IDM supports high level design and product maintenance by storing requirements with the code. At component level design the IDM reflects both the control flow and declaration structure of the program. At the implementation level, the language-independent pseudocode representation directly maps to the source code constructs required to implement the product. The IDM model supports software designers by mirroring the process of soft- ware development. The data model promotes reuse by creating Call objects that represent program design requirements and by matching the requirements to existing Interface and Alternative components in the reuse library. This not only makes a CASE system that implements the model conceptually easy to use, but by integrating support for reuse into the development environment makes reuse a natural result of software design. 12 CITED REFERENCES ________________ Ý1¨ Abd-El-Hafiz, S.K., V.R. Basili, and G. Caldiera, "Towards Automated Support for Extraction of Reusable Components," Proceedings of the Con- _______________________ ference on Software Maintenance, Sorrento, Italy, 15-17 Ocotber, 1991, ________________________________ pp. 212-219. Ý2¨ Batory, D.S. and Won Kim, "Modeling Concepts for VLSI CAD Objects," ACM ___ Transactions of Database Systems, Vol. 10, No. 3, September 1985, pp. _________________________________ 322-346. Ý3¨ Bergland, G.D., "A Guided Tour of Program Design Methodologies," in IEEE ____ Tutorial on Software Quality Assurance, ed. Tsun S. Chow, IEEE Computer _______________________________________ Society Press, Silver Springs, Maryland, 1985, pp. 219-243. Ý4¨ Bourland, D. David and Paul Dennithorne Johnston, ed., To Be or Not: An ________________ E-Prime Anthology, International Society for General Semantics, San _______________________________________________________________ Francisco, CA, 1991. Ý5¨ Buchmann, Alejandro P. and Concepcion Perez de Celis, "An Architecture and Data Model for CAD Databases," Proceedings of the 11th International _____________________________________ Conference on Very Large Databases, Stockholm, 1985, pp. 105-114. ___________________________________ Ý6¨ Clancy, William J., "Classification Problem Solving," Proceedings 3rd _______________ National Conference on Artificial Intelligence (AAAI), August 1984. ______________________________________________________ Ý7¨ Grady, Robert B., "Work-Product Analysis: The Philosopher's Stone of Software," IEEE Software,, March 1990, pp. 27-34. _______________ Ý8¨ Hardwick, Martin, "Why ROSE fast: Five Optimizations in the Design of an Experimental Database System for CAD/CAM Applications," Proceedings of ______________ ACM SIGMOD, San Francisco, CA, May 1987, pp. 292-298. ___________ Ý9¨ Helier, Sandra, Umeshwar Dayal, Jack Orenstein, and Susan Radke-Sproull, "An Object-Oriented Approach to Data Management: Why Design Databases Need It," Proceedings of the 24th Design Automation Conference, Las _____________________________________________________ Vegas, Nevada, 1987, pp. 335-340. Ý10¨ Hurson, A.R., Simin H. Pakzad, and Jia-bing Cheng, "Object-Oriented Database Management Systems: Evolution and Performance Issues," IEEE ____ Computer, February 1993, pp. 48-60. _________ Ý11¨ Johnson, W. Lewis, Martin S. Feather, and David R. Harris, "Represen- tation and Presentation of Requirements Knowledge," IEEE Transactions on ____________________ Software Engineering, Vol. 18, No. 10, October 1992, pp.853-869. _____________________ Ý12¨ Kim, Won, Hong-Tai Chou and Jay Banerjee, "Operations and Implementation of Complex Objects," Proceedings of the 3rd International Conference on __________________________________________________ Data Engineering, Los Angeles, CA, 1987, pp. 626-633. _________________ Cited References 13 Ý13¨ Lorie, Raymond and Wilfred Plouffe, "Complex Objects and Their Use in Design Transactions," Proceedings of the Annual Meeting of Engineering ________________________________________________ Design Applications, San Jose, CA, May 1983, pp. 115-121. ____________________ Ý14¨ Lubars, Mitch D, "Reusing Designs for Rapid Application Development," Proceedings of the International Conference on Communications, Denver, ______________________________________________________________ CO, 23-26 June 1991, pp. 1515-1519. Ý15¨ Matsumoto, Masao, "Automatic Software Reuse Process in Integrated CASE Environment," IEICE Transactions on Information Systems, Vol. E75-D, No. __________________________________________ 5, September 1992, pp. 657-73. Ý16¨ McLeod, D, et. al., "An Approach to Information Management for CAD/VLSI Applications," Proceedings of ACM Database Week, SIGMOD Conference, San _________________________________ Jose, CA, May 1983. Ý17¨ Onuegbe, Emmanuael O., "Database Management System Requirements for Software Engineering Environments," Proceedings of the 3rd International ____________________________________ Conference on Data Engineering, Los Angeles, CA, 1987, pp. 501-509. _______________________________ Ý18¨ Poulin, Jeffrey S. and Martin Hardwick, "Adapting Object-Oriented CAD Database Concepts for Computer Aided Software Engineering," Proceedings ___________ of the International Symposium on Database Systems for Advanced Applica- ________________________________________________________________________ tions, Seoul, Korea, April 1989, pp. 201-208. ______ Ý19¨ Poulin, Jeffrey S., and Kathryn P. Yglesias, "Experiences with a Faceted Classification Scheme in a Large Reusable Software Library (RSL)," sub- mitted for publication to the Seventeenth Annual International Computer _________________________________________ Software and Applications Conference, Phoenix, AZ, 3-5 November 1993. _____________________________________ Ý20¨ Prieto-Diaz, Ruben, and Peter Freeman, "Classifying Software for Reusa- bility," IEEE Software, Jan. 1987, pg. 6-16. ______________ Ý21¨ Roman, Gruia-Catalin, "Data Engineering in Software Development Environ- ments," Proceedings of the 3rd International Conference on Data Engi- _____________________________________________________________ neering, Los Angeles, CA, 1987, pp. 85-86. ________ Ý22¨ Runciman, C. and I. Toyn, "Retrieving reusable software components by polymorphic type," Journal of Functional Programming, Vol.1, pt.2, April __________________________________ 1991, pp. 191-211. Ý23¨ Shriver, Bruce D., "Reuse Revisited," IEEE Software, Jan. 1987, pg. 5. ______________ Ý24¨ Smith, J. and D. Smith, "Data Abstractions: Aggregation and Generaliza- tion," ACM Transactions on Database Systems, Vol. 3, No. 3, 1977, pp. _____________________________________ 105-133. Ý25¨ Yau, Stephen S., "Relationship Between Data Engineering and Software Engineering," Proceedings of the 3rd IEEE International Conference on _______________________________________________________ Data Engineering, Los Angeles, CA, 1987, pp. 84. _________________ 14 BIOGRAPHY _________ JEFFREY S. POULIN joined IBM's Reuse Technology Support Center, Poughkeepsie, New York, in 1991 as an advisory programmer. His primary responsibilities include developing and applying corporate standards for reusable component classification, certification, and measurements. Dr. Poulin has worked in the area of software reuse since 1985 and helped lead the development and acceptance of the IBM software reuse metrics. He participates in the IBM Corporate Reuse Council, the Association for Computing Machinery, and Vice- Chairs the Mid-Hudson Valley Chapter of the IEEE Computer Society. Dr. Poulin earned his Bachelors degree at the United States Military Academy at West Point, New York, and his Masters and Ph.D. degrees at Rensselaer Polytechnic Institute in Troy, New York. Biography 15