Migrating from An Object Based Approach to an Object Oriented Approach to Software Design Brian A. Malloy, Devidas Gupta, Anuradha Kare, and John D. McGregor Department of Computer Science Clemson University Clemson, SC 29634 - 1906. E-Mail:
[email protected] Phone: 803-656-0808 Fax: 803-656-0145 Abstract
In this paper we discuss our experience in building a series of laboratory exercises intended to serve as a model of an extensible, reusable database management system. The target audience for the laboratory exercises is students at the CS 2 level. We begin our discussion by detailing our migration from a design of the laboratory exercises that is object-based to a design that is object-oriented. Our original objectbased design was implemented in the Ada 83 language. However, our migration to an object-oriented design includes an implementation that is accomplished using the Ada 95 language[2] and the GNAT compiler[5]. The laboratory exercises present several implementations of a database management system that permit students to use several keys, and various con gurations of the data in the system. The data con gurations include a table, a list and a binary tree: three important data structures in the CS 2 curriculum.
1 Introduction One of the major problems for instruction of the core computer science courses is to build meaningful, extensible laboratory exercises that guide the student toward mastery of the course material. The goal of one such course, CS 2, is the mastery of the fundamental data structures including tables, lists, and trees. Another problem is the choice of language as vehicle for instruction at this level. The ideal language should provide facilities for modularization, data abstraction, error detection, reusability and extensibility. The language should also a ord the student some help in the form of type checking. Ada 83 is an imperative, strongly typed, block-structured language, designed to foster sound software engineering principles[15]. Ada 83 includes such attractive features as packages for system modularization, private types for data abstraction, exceptions for dealing with run-time errors and generics for reusability.
This work is partially supported by DARPA Grant # DCA100-95-1-0002
However, Ada 83, because of its lack of a full inheritance mechanism[17], does not support extensibility as completely as an object-oriented language. The Ada 95 language enhances Ada 83 to provide full support for object orientation[2] and therefore it supports a more powerful form of software extension. In this paper we discuss our experience in building a series of laboratory exercises intended to serve as a model of an extensible, reusable system for students at the CS 2 level. The laboratory exercises, coded in Ada 95[2], present several implementations of a database management system that permit students to use several keys, and various con gurations of the data in the system. The data con gurations include a table, a list and a binary tree: three important data structures in the CS 2 curriculum. In the next section we provide some background material on Ada 83 and Ada 95. We also discuss the objective of the Ada 83 lab exercises and the need for a move toward object orientation. In section 3 we detail the old exercises which illustrated the object based approach. Section 4 is the main focus of this paper and presents the new set of exercises that we have incorporated into the CS2 curriculum. We conclude in section 5 by presenting the current work and future directions.
2 Background We now highlight the salient features of the Ada 83 and Ada 95 languages together with the overall design of the database problem that is the focal point of the laboratory exercises.
2.1 Ada 83 Imparting skills for good software development is an important goal of the undergraduate core computer science courses. The initial courses such as CS1 and CS2 stress good coding styles and sound software engineering methodologies. The programming language used for the core courses can support the goals of the instructor by providing an environment wherein bad or incorrect programming techniques are not tolerated. Ada 83 has been successful in this role. Ada 83 provides features which make the language attractive for use as the medium of instruction for the core computer science courses. The strong typing of Ada 83 and the block-structured approach provide an excellent environment that encourages good code development and discourages ad-hoc code development. The contractual model of modularization that splits a module into a speci cation and an implementation
component, separates the speci cations from the implementation details. The procedures and functions and their parametrization yield small, cohesive units[8]. Private types provide for data abstraction. Packages allow for modularization of the procedures and functions, and the data types. The exception handling feature of Ada 83 provides a structured way to control the ow of information and allows for error recovery to be incorporated seamlessly into the design. The genericity provide by Ada 83 facilitates code reuse.
2.2 Ada 95 The Ada 83 language has been enhanced to include features that support object oriented programming. This new language, Ada 95, is a more attractive language that has increased the language support for achieving curriculum goals. The addition of object-oriented features such as inheritance and runtime dispatching allow programs to be constructed that can more accurately re ect the underlying software design as well as reduce the cost of maintaining the software. Ada 95 is the rst object oriented programming language to be standardized. Inheritance and type extension permit the creation of extensible software in the true spirit of object oriented programming. The strong type checking of Ada, along with the type extension, provide a powerful mechanism to develop software systems that are less error-prone and more easily maintained. Class-wide types and class-wide operations allow the programmer to construct procedures and functions that can operate on an entire class rooted at a speci c type. Runtime dispatching supports type extension by providing a mechanism whereby the programmer need not explicitly indicate the speci c procedure or function to be called but rather let's the runtime support system make the appropriate choice. This runtime dispatching obviates the need for code change when type extension takes place. The type of the object decides the procedure or function to which the call gets dispatched. Abstract subprograms and types permit the creation of a blueprint for a type and the supporting functions that the inheritance class builds upon[14]. Abstract subprograms and types thus permit the software architect to create a set of minimal types and functions that the implementation must support.
2.3 Software Architecture We now present the design architecture of the database problem that is used as the medium to demonstrate object oriented concepts and techniques to the CS2 student. All the laboratory exercises are based on a
single design. This approach makes it easier for the students to learn new concepts, since they do not have to spend as much time learning about the problem itself. The goal of the series of laboratory exercises is to provide, for the student, an example of a well-engineered database management system that is extensible to families of related types of records and reusable across sets of unrelated families of records. The database system allows for the insertion, deletion and lookup operations on data records. The organization of the database is exible and can be con gured as an array, a list or a binary tree. The data records themselves can be of any type and do not impact the operation of the database. The database is unaware of the contents of each record. The encapsulation of the functionalities of each component of the database system is provided by table 1, which provides an overview of the core packages that make up the database system. Package
De ned Types Interface Functions Uses
NamePackage
NameType
IdPackage
IdType
EmployeePackage
EmployeeType
TablePackage
TableType
KeyPackage ElementPackage
KeyType ElementType
ContainerPackage ContainerType
Name, ">", "", ""(Id1, Id2 : IdType) return Boolean; function ""(Key1, Key2 : KeyType) return Boolean; function ""(Key1, Key2 : KeyType) return Boolean; function ""(Key1, Key2 : KeyType) return Boolean is abstract; function ""(Id1, Id2 : IdType) return Boolean; function ""(Ele1, Ele2 : ElementType) return Boolean is function ""(Employee1, Employee2 : EmployeeType) return Boolean; function "
