SOFTWARE ENGINEERING APPRENTICE CS1 - CS2 LABORATORY ACTIVITIES The accompanying files contain complete lab activities for CS1 - CS2 courses. They include student assignments, solutions, instructor notes, and operational source code in Ada. ORGANIZATION OF THESE MATERIALS Directory Description --------- ----------- cases There are eight case studies, each in its own subdirectory. Each case study contains: 1) Read.me file which describes the files associated with the case study. 2) Source code in Ada for the application being studied. 3) Documentation of the software, such as requirements specification, module hierarchy chart, and test plans. 4) Assignments. A description of the activities students are to undertake and the resources they need to complete them. The case studies should be explored in this order: (CS1) pizza, moon, hurkle, jotto, invntory, (CS2) mahjongg, prospero, animals activity The files in this directory contain directions and procedures for students to follow as they carry out the lab activities. The procedures apply to more than one lab, so rather than repeat them with each case study, they have been collected in this directory and are referred to specifically by each lab activity which needs them. solution This directory contains two subdirectories, one which has the source code for the solutions to the lab activities, and one which contains notes to the instructor about each case study. Instructors using the lab assigments will probably want want to ensure students may not access this directory. utilities This directory contains the source code for two utility packages which are used in the solutions to the lab exercises. FILENAME CONVENTIONS The filenames are compatible with MS_DOS file naming conventions. Each directory contains a file named "read.me" which gives a table of contents for the directory. Extension Contents --------- -------- .ads Ada source code file (package specification) .adb Ada source code file (package body or subprogram unit) .sol Ada source code for a solution .dat application data file .txt ASCII text file, containing lab activities or software documentation. .act Activity procedures .ins instructor notes about a case study PREPARING TO USE THESE MATERIALS The files are all in ASCII text and therefore can be easily printed or moved to whatever environment is desirable. The instructor will probably want to keep the files in the "solution" subdirectory unavailable to students, either by setting appropriate file permissions or by simply removing them. If students will be working in a shared or networked development environment, it is desirable to create a single "class" ada library which can be accessed by everyone. Into this class ada library are compiled the utility packages provided in the utilities directory. The package bodies for these utilities should NOT be available to students, only the package specification. Student programs may access the utility packages by including the appropriate context clause (WITH statement). This strategy simulates a realistic project development environment, rather than giving each person a copy of the source code which they must compile into their own library. INTRODUCTION FOR INSTRUCTORS The notion of a software engineering "apprentice" provides the instructional model underlying these laboratories. In this model the student learns good programming practices by serving in an "apprentice" role to a more experienced practicioner. The skills of software testing, and code comprehension and maintenance, are taught first. Students practice these basic skills extensively before the more abstract techniques for software design are introduced. Using a kind of "case study" approach, students study and explore software that someone else has written which (we hope) exemplifies good software engineering practices. Unlike traditional programming assignments where students are assigned a small "throw away" program which they must develop from scratch, in these activities, students must modify or enhance an already working application which is considerably larger than they could develop by themselves. Our intent is that from the outset students perceive that their work must integrate with and build upon the work of others. A more elaborate discussion of this model can be found in "The Software Process Laboratory for CS1-CS2." INTEGRATING THE LABS INTO YOUR COURSE The materials provided are a kind of "smorgasboard" from which the instructor can pick and choose those which fit best into his or her existing course outline. Each case study is self-contained. The activities are not tightly interdependent. In most cases any particular lab may be selected without concern for any "prerequisite" labs. Even within a particular lab, the instructor may choose to designate only certain items for students to complete. We suggest that the case studies be introduced in the following order: Pizza Moon Lander Hurkle Jotto Inventory Mahjongg Prospero Animals There is generally more than one lab for each case study, and the labs are numbered in an order which introduces skills in this sequence: Software Testing, "Bebugging" Code modification Code enhancement The following chart details which Ada language features are used in each of the case studies. Pizza - unit price calculator Integer and Float operators and input/output Explicit type conversions Moon Lander - simulation/game Get and Put of numbers and strings constants simple IF complex IF WHILE loops using a utility package (random) Hurkle - guessing game Subtypes procedures and functions FOR loops boolean expressions Jotto - word guessing game String I/O string processing nested FOR loops general loops functions (boolean, numeric, character) procedures and parameters complex IF text file input exception handler Inventory - database inquiry CASE text file input records arrays of records array traversing, searching, selecting Mahjongg - solitaire game multi-dimensional arrays packages implementing ADT's stacks instantiating generic packages Prospero - priority queue simulation designing and implementing ADT's priority queues Animals - 20 questions game binary trees LAB NOTEBOOKS The lab activities direct students to utilize a lab "notebook." While keeping a lab notebook is not the norm in computer science classes, it is standard in other engineering disciplines and in the empirical sciences. The intent is that students will keep records of their explorations and discoveries. The notebook serves as documentation of the students learning process: what mistakes they made, what strategies they attempted, what solutions they discovered, what problems they encountered and how they solved them. TEAM PROJECTS Several of the labs provide directions for the students to work in teams. It is possible to ignore these guidelines and have the assignments be completed individually. However, we have had very good results assigning students to work in teams, and we think that the team experience may be the most valuable learning students take with them from the course. The team activities are usually arranged so that each student has a clearly defined task to complete, and thus individual grades can still be awarded, in addition to a "team" grade for the entire project. TECHNICAL SUPPORT We would be delighted to receive feedback, critical comments, and suggestions for improvement to these materials. To the extent of our limited resources we will attempt to provide technical support with installing and maintaining these materials, including the Ada software. Contacts: Dr. John Dalbey Computer Science Department Cal Poly, San Luis Obispo, CA, 93407 USA (805) 756-2921 jdalbey@calpoly.edu Dr. S. Ron Oliver Computer Science Deoartment Cal Poly, San Luis Obispo, CA 93407 USA (805) 756-6133 sroliver@calpoly.edu ACKNOWLEDGEMENTS These materials were developed under a grant from Defense Information Systems Agency (#DCA100-94-1-0004). DISTRIBUTION The materials may be freely distributed without restriction. DISCLAIMER This software and its documentation are intended for educational purposes only, and are provided "AS IS" without any expressed or implied warranties whatsoever. No warranties exist as to performance, merchantability, or fitness for a particular purpose. In no event shall any person or organization of people be held responsible for any direct, indirect, consequential or inconsequential damages or lost profits.