At the Universidad Simón Bolívar we have been using Java in an introductory Software Engineering course since January 1999 and we are currently adopting it in two more advanced advanced Software Engineering courses. There are a number of other Java-based courses scattered throughout our Computer Science curriculum.

Our introductory Software Engineering course is taught early in the curriculum, in the middle of the students' sophomore year. Traditionally this has complicated the selection of term projects since the students have had no formal exposure to database management systems, user interfaces, general programming language concepts or operating systems. The course focused most on topics in (structured) design and testing.

Last winter, we taught an experimental version of the introductory course, switching to an object-oriented software engineering focus. We based the course on use cases and OMT for analysis and design and attempted to lightly refocus testing towards objects, relying heavily on the use of OMT's state diagrams as a basis for test case generation. Based on this experience, we rehauled the course in time to teach a new, but still experimental, course in time for our spring term. This time we decided to adopt Larman's UML based RPM methodology and update to JDK 1.2, setting AWT components aside in favour of the newer Swing components.

I also had the chance to teach and apply RPM with a student, Jennifer Anato, who developed a new version of an ATM management tool for a Venezuelan-Chilean firm.

This is what I found:

1. I needed to spend more time on requirements analysis since the OO methodologies couple design more tightly to requirements.

2. The students require better writing skills for the OO methodologies basically in order to write sharp, precise use cases.

3. RPM is pedagogically superior to  use cases tacked on to OMT, even if you update OMT's notational base to UML.

4. The students have a hard time with the consistency between their OO models.

5. The use of conceptual/structural models is key to OOSE, however a firm grasp of the more basic E-R model is strongly recommended before adding more advanced concepts like aggregation and inheritance.

6. Taking into account that the students had no prior exposure to automata theory, it is hardly surprising that OMT's reliance on state diagrams, which include such relatively advanced concepts as concurrency and actions on transitions overwhelmed them. Even RPM's use of object collaboration diagrams turned out to be heavy going, much to this author's surprise, who considered they would be easier to understand than state diagrams. In fact, they seemed to be about equally difficult for the students. As Victor Theoktisto, a colleague, pointed out this is probably due to the fact that collaboration diagrams are based on message-passing, a paradigm for which the students were unprepared and which is far from trivial to grasp.

7. Modeling takes up far more time to cover and  to do in an OO approach than in traditional structured approaches; it is also more complex. Note that whereas in a traditional introductory SE course you can get away with two models (one to capture data flows and the other to capture the structure of the design) and cover analysis and design, in an OO approach you need from four to five models to cover the same ground.

8. More time is required to design OO software. Most initial student designs do not really take advantage of  OO programming concepts and they tend to revert to a more traditional programming style. The easiest part of teaching Java programming is teaching Java, the hardest part is teaching to program in an object-oriented style. (Of course, the same comment applies to other OO programming languages). The key to an object-oriented style are object-oriented patterns. To put it mildly, most people are not born knowing these patterns. In 1997 my students and I  searched about ten different "object-oriented" final year student projects for six basic Gang of Four patterns and found only one use of one pattern but identified that all the projects could have benefitted naturally from the use of at least four of the patterns. Teaching patterns is not easy; it is far too easy (and deadly) to fall into a catalogue description mode.

7. The pressure to start coding becomes worse. As in most SE courses, the most interesting and the most challenging goal for the students is to develop a medium-sized software product. Postponing coding in order to analyze and design seems to be an exercise in frustrating the students. Of course the longer lead times aggravate this situation to the point where one of the student teams got to the point of simply throwing away their carefully revised designs and banging away at their keyboards in a daze of adrenalin. Unfortunately, we have found that many industry programmers and managers share similar attitudes. They appear to have discovered in OO the perfect excuse to program first and think about design later. After all, the first software increments are supposed to be throw-away prototypes, right? Of course when you are snarled in a business-critical application which is into its seventh (undocumented) kludge version, you begin to wonder just what has been thrown away.

8. Object-oriented software testing gets pushed aside. To be honest, the first time round I thought I could probably extend some basic testing concepts. I know, I should have read the literature --but I discovered the hard way that it is not that easy. I extended cyclomatic path testing to automata and simply applied this to the classes' automata diagrams. I wrote a paper on this and one of the reviewers thought it was a nice try at exhumation; the other one wasn't quite so polite about it. The second time around, testing simply fell off the course --that is, we ran out of time.

9. RPM is an incremental iterative methodology and in that sense is very representative of most OO methodologies. With all the models one has to cover, I have not found it possible to develop more than one increment in the course. So the students don't get to see just how this incremental business works --even though Larman does a wonderful job in his book of showing how it could be done. Currently I'm trying a different tack -- I provide the students with OO software and ask them to develop the next increment. On the plus side, this looks promising since you are forced to grapple with software maintenance right from the start --which is where most of the student's professional life is going to be spent-- and hopefully the software is a case study in good design and documentation. On the minus side,  understanding  someone else's software adds even more lead time to the course and, personally, I believe maintaining software is much harder than developing it from scratch since not only do you have to understand that design but you also have to respect it  in order to extend it in a natural way. Therefore does it make sense to start here? As far as I'm concerned it's an interesting open question.

10. Object-oriented development benefits from larger teams. In traditional introductory courses we tended to rely on two to four member teams; in the new object-oriented courses we have been experimenting with much larger sizes (four member teams for design, eight to twenty member teams for implementation). In general this works well when you are lucky in the team's group dynamics, but it can become a nightmare if the team cannot handle the pressure. In general I believe that this will lead to the need to address more about group skills, much earlier and much more explicitly than what is customary for traditional SE courses. The problem is, I have the sneaking suspicion that the teachers' group skills may not be all that hot either, so we may need to enlist the help of some good social psychologists for our Object-Oriented Software Engineering courses.

11. Java is a fine programming language but some of its class libraries are still in a state of flux. To program well in Java, you need to know the language (easy), you need to acquire an object-oriented style (difficult) and you have to acquire knowledge about the philosophy and components in the class libraries (hard and time-consuming, respectively). Switching from AWT to Swing was not easy for us. How many library classes do you need to know before you can be considered a competent Java programmer? Which ones? Which one do you tackle first? How do you find the class you need? Actually, it''s worse than that because you can seldom find the class you want, since what you are looking for is usually split up among a collection of classes. In order to use those classes you have to understand how they fit together --and what sort of demands the interfaces are actually demanding of you. Just how much of this knowledge can you fit into a course that has a host of other demands? Does this mean, Java library specifics need to more covered in  previous courses?  In which courses? In a  freshman course on algorithms? Aren't the libraries too heavy for this? Can we teach programming in Java without at least some smattering of object-oriented design methods?  At this point one feels as if either this is a chicken-and-egg problem or there is a need for an introductory course for the introductory course on OOSE.
 

Based on these experiences, my conclusions are:

1. Is teaching OOSE different from teaching traditional SE?
Yes it is harder and it requires different skills from the teacher and the student. It requires more modeling activities and provides a larger and extremely fun design space to play around in. It can easily overwhelm the novice student but it has can really pull together many more apparently disparate Computer Science strands for the more advanced students. It requires working on larger projects in order to appreciate its benefits and the size of the projects threatens to overflow any one-term, one-teacher courses.

2. How much influence will Object Oriented Software Development have on Software Engineering
A great deal. We are already seeing how the classical waterfall model of software development is being challenged by more incremental methodologies, how the frontiers between analysis and design have become much fuzzier. I think we have yet to see how the full implications of modeling, which will play an increasing part in Software Engineering (perhaps marking for SE an important milestone on the path to becoming a mature Engineering discipline). There are a quite a few surprises in store for us as regards testing (and not all of them pleasant). I also believe that we are poised on the verge of having to treat "software maintenance" as the key technical problem in Software Engineering and developing team skills for this as the key cultural problem.

3. Why will Java have this influence?
Java seems to have the potential to pull together domains that seemed to be drifting apart: data bases, operating systems, embedded systems and graphical user interfaces. By placing these domains on a simple, equal but distributed footing, Java reveals itself as the programming glue that may allow integrated software systems on a scale barely glimpsed at before. For this possibility to become true, Software Engineering must provide new analysis, design, test, project control and other development methods and tools that span those diverse domains to help  envison, specify, build, fit, adjust and prepare the pieces from those domains for glueing.

Java will also play a key part in education because it's free and it is widely distributed. These factors should not be subestimated in a world of spiraling education costs and dwindling university resources. Especially for poorer countries, where a simple PC may cost a "privileged" university professor more than a month's salary, free, state of the art software may play an important part in helping their educational systems prepare the competent information and computer professionals necessary to belong to a better world.