Real-World Object-Oriented Design Experience for Computer Science Students

Transcription

1 Real-World Object-Oriented Design Experience for Computer Science Students Abstract Due to the limitations of time and resources, many undergraduate Software Engineering courses provide a survey of a broad range of development approaches rather than the experience of software production in a real-life setting. In this paper, we propose an innovative learning environment that integrates our undergraduate Software- Engineering course with an application course in Client/Server Computing. Such an environment allows students to apply software methodologies size. This paper to implement real-world applications of a meaningful presents detailed class schedules for both courses for a 16-week regular semester and analyzes the benefits of such a learning environment. Not all students in the softwareengineering course are taking the Client/Server Computing course, and vice versa. Therefore, team organization and student assessments become complicated and are discussed in the paper. Introduction According to the report generated by the ACM/IEEE-CS Joint Curriculum Task Force [1], the major focus of the undergraduate Software Engineering (SE) course is the specifications, design and production of large software systems. Students are asked to work in teams and apply the knowledge to solve real-life problems. For most other Computer Science (CS) courses such as Operating Systems, the subject of the course is the same as its problem domain. Furnishing good domain models, object classes, and problem-solving techniques for the domain is a routine part of the course [13]. However, for the SE course, the problem domain is not a direct subject of the course and students may lack the necessary domain background. This nature of SE courses limits the type and size of the projects that could be assigned to the students. To overcome this limitation, we propose to couple SE with another CS upper-division course, Client/Server Computing (CSC). Our objective is to assign a meaningful size term project with a real-world application and engage students in engineering activities that occur in a real software development environment. Since most of the current and future applications will be related to the client/server and internetbased paradigm [2], a team project in the client/server environment can help students better prepare themselves for future employment and would therefore be well received by students. Youwen Ouyang and Stanley S. Wang Department of Computer Science California State University San Marcos, CA To the best of our knowledge, there is no previous experiment of merging two such courses at other universities. The only similar approach is suggested by Villarreal and Butler [12], which combines SE with a database course. The sole benefit of their merge, as pointed out by the authors, was being able to assign students in both courses a larger project. Our merge of SE and CSC, on the other hand, involves a strong interaction between the two courses so that they can complement each other. This paper records our experience in designing and implementing this new curriculum during the Spring 1999 semester. We provide the background information of our students in the next section followed by our selection of term project, the organization of project teams, and coordination between SE and CSC. We discuss the benefits and potential expansion of our study in the last section. Background It is both necessary and prudent to evaluate the feasibility of a project at the earliest possible time [7]. In determining the feasibility of coupling the two courses, the background information about our potential students must be considered. In the CS Department at California State University San Marcos (CSUSM), SE is an upper-division required course, while CSC is an upper-division elective. The students entering both courses share the same prerequisites: a sequence of two programming courses and a course in data structures. The programming language currently used in all three courses is C++. When finishing the three courses, the students are expected to feel comfortable using C++ to implement well-designed and well-specified tasks. Thus, the students should have enough programming experience to appreciate the benefit of good documentation and the systematic software development process in SE. On the other hand, we consider that the three prerequisites alone do not provide sufficient background knowledge for CSC. Students who have completed the three prerequisites should have a sound foundation for understanding the program structure of any other Object- Oriented (OO) programming language such as Java. However, they lack training in OO analysis and design. In information systems, the client/server model is a concept for describing communications between computing processes that are classified as service consumers (or clients) and service providers (or servers) [11]. It is absolutely critical 13a3-1

2 that the students have the ability to identify and distinguish the functionality and responsibility of both clients and servers. Without proper training in requirement analysis and OO design, students will not be able to fully grasp the concept and power of client/server systems. Therefore, SE is being listed as a co-requisite for CSC. As we show in a later section, we have carefully designed our course plans to ensure that knowledge about OO analysis and design is covered in SE before it is applied in CSC. Term Project Even though term projects are used in most SE courses for the purpose of teamwork and application of principles and methodologies, many of them are toy problems that are well defined and have fictional customers. Such projects fail to convey real-world experience to students. The problem gets worse when it comes to OO methodology. Many SE textbooks use objects with clear boundaries as examples to illustrate the concepts of OO analysis and design. Such examples over simplify the real-world problems, which frustrate students when they apply OO methodology in their term projects and/or real-world work projects. The above limitations are not due to the lack of expertise of instructors or authors, but rather due to the constraints of time and scope of courses and textbooks. Our approach overcomes the above limitation by expanding the SE courses through an application course in CS where the domain knowledge of term project can be extensively discussed. While searching for appropriate projects to be shared by both courses, we keep several factors in mind. First of all, the project should be best implemented as client/server applications. Secondly, the project should be of a reasonable size that can be accomplished within a semester. To ensure the above two factors, the instructors of both courses should get together before the semester and perform thorough research in different ways of approaching the problems for the project. Thirdly, the project should be in an application domain that most students are familiar with. Last, we search term projects that could produce useful products for the University community. That is, the clients of the term projects are not the instructors of the course but rather other faculty members or staff on campus. There are two reasons for this criterion. On one hand, students are motivated when they know that their work might actually be used by potential clients and last beyond the semester. On the other hand, students are dealing with the typical clients of a software project who are not computer professionals and not very clear about what they need at the beginning of the project. Due to the amount of supervision involved, we recommend only one project each semester. In Spring 1999, the term project is a campus Grade Tracking System (GTS). The goal of this project is to allow instructors to keep track of students performance and students to view their performance and standing throughout the semester. Students are familiar with the domain language and there are faculty members who are in need of such a service and willing to perform the role of clients for the project. The development environment for the term project consists of networked Personal Computers (PCs) and network servers partially supported by the National Science Foundation (NSF) under grant DUE Symantec Corporation provided the Symantec Visual Café, a Java database application development environment, under its educational program agreement. There is no limitation on which computer can access the system as long as the computer is networked to the Internet and has a valid IP address. Team Formation In Spring 1999, there are three groups of students in the two courses. As of the last drop day, there are 26 students in SE and 16 students in CSC. Among them, a total of 11 students decide to take both courses (referred to as Group I students hereafter). Five students in CSC already completed SE the previous year (referred to as Group II students hereafter); and 15 students in SE are not taking CSC (referred to as Group III students hereafter). Figure 1 shows the distribution of different groups of students in the two courses: Group I 35% Group II 16% Group III 49% Figure 1: Student Distribution Clifton has proposed an industry approach for forming project teams [4]. In his approach, students submit their resumes to apply for team positions and instructors determine a team formation based on the solicited resumes. We adopt the approach to ensure that our teams simulate the real-world environment where there are different specialists at different stages of software development. Every project team consists of a mix of students from the above mentioned three groups of students. Group I students are asked to participate in all aspects of the project including design, analysis, and implementation. Group II students have a limited role in designing the project, preparing documents and making presentations; while Group III students have reduced responsibility during implementation phase. At the beginning of the semester, we present to students a brief description of the project and introduce the concept of the software life cycle. A list of positions along with their 13a3-2

3 descriptions is also distributed to students in SE. Students are given a week to submit cover letters and resumes in support of their application to two positions in the order of their own preference. Every member of a team will play the role of a leader at some point of the development. It is made clear that a leader is not to do everything on his/her own for the phase that he/she is in charge of. Nor is it a good idea for a leader to make other team members his/her servants. Throughout the semester, students are required to document their participation as evidence to receive appropriate credit for the project. Table 1 lists the job openings along with brief descriptions. Table 1: Job Openings and Brief Descriptions Title Co-Managers (two persons) System Analyst Quality Assurance Specialist System Librarian Brief Description Oversee the activities of all stages and ensure appropriate progress of the team. Coordinate the activities that ensure a thorough understanding of clients' needs. Coordinate the activities that ensure the quality of products throughout the development. Coordinate the activities that ensure the documents are consistent and complete. We evenly distribute the eleven students from Group I into five teams. The majority of them are co-managers with a few exceptions as system analysts or quality assurance specialists. In addition, we assign the five students from Group II as programmers into the five teams. As a result, there are a total of six to seven members in each team, among them three to four students are taking CSC. This is to ensure enough manpower during implementation. Coordination between SE and CSC Most SE textbooks present the OO methodologies as partial life-cycle models concerned with program design or the requirements phase only [5]. They identify activities within the software development process as a linear series of actions, each of which must be completed before the next chapter/phase is begun. However, iteration is an intrinsic property of software production in general and the OO paradigm in particular. Therefore, in SE, we present the materials in a spiral fashion that corresponds to the nature of OO methodology in software development [7]. 1. Concept Development 2. New Product Development 3. Product Enhancement Figure 2: A Spiral Model in Teaching OO SE Our model (see Figure 2) is a revised version of the spiral model of [3] which is based on the assumption that the developer, as well as the customer, understand and react to risks better as software evolve. Each cycle involves a progression that addresses the same sequence of steps, for each portion of the product and for each of its levels of elaboration [8]. The horizontal line defines the project entry point axis. The numeric numbers placed along the axis represent the starting points for different iterations. Table 2 lists activities of the task regions that are shared by all three iterations. Task Region Customer Communication Concepts and Rules Risk Analysis Construction and Release Evaluation Table 2: Acitivies of Each Task Region Activities Establish effective communication between student and customer. Solicit customer requests. Introduces the concepts and rules applicable to current stage of the development. Illustrate by examples how to apply the knowledge to accomplish the required products. Assess the impact of the new concepts and/or requirements on the previously defined product. Explore different alternatives. Discuss the pros and cons of the alternatives. Construct, test, and document the product. Evaluates the product in terms of utility, reliability, robustness, performance, and correctness. Evaluate the product in terms of its conformance with SE principles. Analyze the potential of reuse and the impact of design upon maintenance. 13a3-3

4 The first iteration emphasizes the concept development and results in preliminary OO models of the original project. A rapid prototype can be used to present the user interface and potential functionality of the product. During the second iteration, customers can refine the project requirement based on the first iteration. This is to accommodate the situation in which the customer says I can t tell you what I want, but I ll know it when I see it. The second iteration produces the design and an operational system of the project. The final iteration accommodates additional features from the customer and generates an enhanced product. Based on the new features, the instructor guides students in reusability analysis and identification of inheritance among classes. Students will have an opportunity to evaluate the scalability of their design and learn from the shortcomings of the original design Table 3: Integrated Class Schedules Client/Server Computing Introduction to client/server computing Java basics: program structure, data types, and control flow Object-oriented programming with Java Middle tier and JDBC API Software Engineering Introduction to software engineering Requirement Analysis and Rapid Prototyping Object-oriented Analysis & Modeling Architecture Design Join lecture: Allocating data and services in Client/Server Computing First hands-on exam Talking to databases Structured Query Language components Window programming Java GUI components Java abstract window toolkit Understand & control threads Event-driven programs Event handling with Java Different network services Different network protocols Connection vs. connectionless ODBC standards JDBC API The middle tier Remote Method Invocation First quiz Architecture design: Interaction among Detailed design: User Interface design & Testing Detailed design: Operations in classes and Interactions among classes Detailed design: Testing Teams present their designs for class evaluation Implementation & integration: Configuration control, Testing, Putting the components together 13a Exception in Java How Java handles exception? Second hands-on exam Client/server--business vs. technical prospective Examples of missioncritical client/server applications Finish your project Third hands-on exam Implementation & integration: Exceptional handling Acceptance testing Second quiz Maintenance Phase & Advanced Features of SE Finalize documents Final exam We carefully design our class schedules according to the revised spiral model so that, for many selected topics, Group I students can be exposed to their design issues (in SE) and implementation issues (in CSC) at the same time. The schedules are listed in Table 3 where the first column represents the weeks of a semester. For CSUSM, there are 16 weeks in a semester. The first iteration emphasizes the concept development of the project. About four weeks are devoted to the first iteration. Only brief descriptions of the project are given to the students. This is done to reflect the real-world situation that most new systems begin with a rather nebulous concept of the desired function [8]. It is up to system analysts on the teams (SE students) to carry out requirement solicitation and specification. Students are asked to conduct actual interviews with faculty members to find out what faculty do to keep track of students performance and the approach faculty may take to calculate final grades. Students experience rapid prototyping as an effective tool for requirement requisition. In addition, these students would perform OO analysis to generate the conceptual model of the project. Through this hands-on exercise, SE students have a better understanding of the four inherent difficulties of software development: complexity, conformity, changeability, and invisibility [9]. Meanwhile, students in CSC are introduced to the basic syntax and semantics of Java as a programming language as well as the concept of client/server computing. Programming assignments are given to these students to ensure their understanding of Java features. Fundamental OO concepts are introduced in SE before the OO perspective of Java programming is introduced in CSC. This is to prepare those students who are taking both CSC and SE in the same semester. As a result, SE covers OO analysis of the problem at the same time CSC covers OO implementation of the conceptual model. At the end of the first iteration, the instructor for SE can introduce the purpose and activities of architectural design. The two courses, then, meet together to learn about the architectural design of OO client/server systems. The instructors demonstrate to the students through some examples of allocating data and services in client/server systems.

5 The second iteration in SE develops the concept of the project from the first iteration into an actual product. This iteration involves design and implementation of the system. Therefore, students from both courses participate in the development. This is the iteration where the two courses interact and complement each other the most. The iteration starts at the second half of the fifth week and ends at the end of the tenth week. Most students in SE have very limited experience designing real life problems. From our past experience in teaching SE, we found that one of the main obstacles in learning design principles is not being able to visualize and hence anticipate the impact of the design. Therefore, we design parallel course plans so that, for each task, we can teach the design principles and implementation techniques at the same time but in two courses separately. For example, in the sixth week, SE covers the design of user interfaces and CSC covers the Java implementation of graphical user interfaces (GUI). Therefore, the instructor of CSC can use design documents from SE as examples and teach students in CSC how to read design documents. In addition, students will learn the Java GUI components that can be used to implement the design documents. On the other hand, the instructor of SE can use Java programs from CSC as examples to teach students the roles of user interfaces in a project and to help students organize the flow of an application through user interfaces. Students will also learn the techniques of writing design documents for user interfaces. The main goal of OO design is to define logical software specifications that fulfill the functional requirements based on decomposition by classes of objects. An essential step of detailed design is the allocation of responsibilities of objects and illustrating how they interact via message passing [6]. Thus, in the seventh week, students in SE are asked to refine the essential use cases, which are identified in the first iteration, to real use cases. For each real use case, a sequence of system operations is identified. Students are asked to define a contract for each system operation where they need to clearly specify the states of classes and/or associations before and after execution of the operation. The corresponding collaboration diagram for each contract is used to allocate responsibilities to each class and identify interactions among classes. The SE instructor can use Java programs from CSC to illustrate the concept of message passing and event-driven programming to implement OO designs. In addition, the examples can be used to analyze the impact on a design. On the other hand, in the seventh week, CSC covers the concept of threads and event handles in Java. The instructor of CSC can demonstrate how to use the Java class hierarchy to implement the class diagram that is produced in SE. In addition, the instructor can discuss the distribution of classes in a client/server environment. For the term project, users of GTS will access the system through GUIs on PCs that serve as client sites for the system. The actual data of the system is stored in an Oracle database that serves as the data server of the system. The middle-tier that is supported by the system consists of the implementation of the classes identified in the class diagram from the SE course. As a result, students will have a better understanding of the architecture of the system. We design the rest of the second iteration based on the same principle so that the students in SE are not only exposed to abstract concepts of OO design but also experience concrete applications of the concepts. The backend of the system is an Oracle database running on a server machine. Since relational database management system is not the prerequisite for either of the courses, the actual design of the database is provided by the instructor after students submit their class diagrams. This is to ensure that the implementation of the project will not be hindered by students ability in database design. However, CSC does cover basic commands in Structure Query Language (SQL) so that students can embed SQL statements in their program to retrieve data from and store data into Oracle database. In addition, CSC covers making a Java connection to an Oracle database. Students from both courses participate in implementation of the first round product. At the end of the second iteration, students demonstrate their product and submit the product for use by clients. The clients, at this point, can request additional features or make changes to the functionality of the product. However, the two courses proceed with separate routes after this point. The third iteration of SE involves the maintenance phase of software production. In addition, advance features of software engineering can be introduced to students. The instructor guides the students in evaluating the design of their project in terms of scalability and potential of reusability. If time permits, the concepts and activities of reverse engineering and re-engineering can be also introduced. At the same time, students in CSC study examples of both successfully implemented and challenged mission-critical client/server applications. They also explore other Java advanced features such as remote objects, remote method invocation, and distributed computing. Conclusion According to Standish Group [10], businesses in the United States alone spend an estimated $250 billion each year on application development. The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. Most projects are either over budgets or over the time estimated, and offer fewer functions than originally specified. Most of the main factors for the failure, according to the study, are related to poor design and analysis. Yet the analysts and designers are experienced software professionals. But students in undergraduate SE courses are 13a3-5

6 often novice programmers and lack design experience in any real-life software. They often find the abstract nature of the design and analysis concepts hard to comprehend. When even a medium sized term project is assigned, students have difficulty visualizing the overall architecture of the final system, not to mention the detailed design of such a system. However, instructors of SE courses usually cannot afford to discuss the implementation of any particular type of application before the term projects start. In fact, most SE textbooks discuss the implementation phase of software development in terms of team organization, documentation, and testing methods. As a result, the size of the problems used in SE courses to introduce design and analysis philosophy is typically small. Such small problems fail to convey the real-life experience of software development. In our approach, CSC supplements SE by presenting a thorough discussion of the topics necessary to implement a client/server application. In the beginning of the semester, CSC students are provided with an overview of the architecture and adequate implementation training for client/server systems. In addition, we have designed new course plans that coordinate design issues with their impact on implementation. As a result, students can better apply the design principles and analysis techniques to software development. By integrating SE with CSC, our methodology furnishes a learning environment that would provide students the much-needed experience in developing real-world-like applications. It is worth noting that client/server computing is only one of the many subject areas in CS where a problem domain is clearly defined. Thus, the proposed approach can be modified to integrate SE with another subject such as Database Management Systems, Operating Systems, or Computer Networks. (6) Larman, C. Applying UML and Patterns, An Introduction to Object-Oriented Analysis and Design, Prentice Hall, Upper Saddle River, NJ, (7) Ouyang, Y. and Wu, S. Teaching Object-Oriented Software Engineering in a Spiral Fashion Proceedings of the IASTED International Conference on Software Engineering, pp , Las Vegas, NV, October (8) Pressman, R. S., Software Engineering: A Practitioner s Approach, 4 th ed. McGraw Hill (9) Schach S. R., Classical and Object-Oriented Software Engineering with UML and Java 4 th ed. WCB McGraw- Hill 1998 (10) The Standish Group, "CHAOS" (11) Umar, A., Object-Oriented Client/Server Internet Environments, Prentice Hall, Upper Saddle River, NJ, (12) Villarreal, E. and Butler, D., Giving Computer Science Students a Real-World Experience in Proceedings of SIGCSE 98, pp , Atlanta, GA, 2/25-3/1, (13) Winslow, L. E., Programming Pedagogy A Psychological Overview SIGCSE Bulletin, Vol. 28, No. 3, pp (September 1996). References (1) Association for Computing Machinery, "Computing Curricula Report of the ACM/IEE-CS Joint Curriculum Task Force" IEEE Computer Society Press, (2) Bernstein, P., Middleware: A Model for Distributed Systems Services, Communications of the ACM, February 1996, pp (3) Boehm, B. W. A Spiral Model of Software Development and Enhancement, IEEE Computer, Vol. 21, No. 3 (May 1988). (4) Clifton, J., An Industry Approach to the Software Engineering Course SIGCSE Bulletin, Vol. 23, No. 1, pp (March 1991). (5) Henderson-Sellers, B. And Edwards, J. M. The Object- Oriented System Life Cycle Communications of the ACM, Vol. 33, No. 9 (September 1990). 13a3-6