Larry Latour

University of Maine

Department of Computer Science

222 Neville Hall

Orono, Maine, 04469

Tel: (207) 581-3523, fax: (207) 581-4977

Email: larry_latour@umit.maine.edu

A software engineering came across a friend looking for a lost quarter under a very bright street light. When asked where the quarter was lost, the friend replied, "down the street".

"So why are you looking here?" asked the puzzled software engineer.

"Because the light’s better here," replied the friend.

Reuse research in the ‘80’s focused on looking for solutions to the reuse problem where the light was shining — in large repositories of so-called "reusable artifacts". They collected them, organized them, classified them, and then tried to get their software engineer friends and colleagues to use them. Unfortunately the problem was, and still is, down the street. Those "in the know" realized that the problem was a systemic one. These hard ‘90’s problems are concerned not with components, but with components and their context — i.e., their architectural frameworks. Repositories are still a bit of a concern, but they are far from the focus of the problem. Components are part of the focus of the problem, but not the entire focus. We’re wearing bifocals, looking systemically at both component design and architectural framework design. In addition, to the extent that design is the distinctly human act of creating artifacts, a number of us are trying to avoid design with reuse altogether through the use of generative technologies. We all realize that the problem is not to adapt components to new contexts, but to adapt systems to new contexts, both on the macro level through the (human) design and use of component architectures, and the micro level through the (human) design and use of (machine) system generation tools.

Unfortunately most universities seem to be more concerned with their trade school image of training students for the job market than they are in properly educating them to deal with these very hard problems of ‘90’s brand systematic software reuse. This is made worse by a plethora of "hot" tools and methodologies that syphon off precious time from a necessary grounding in the fundamentals. I’ve participated in many arguments concerning whether or not to include languages and tools such as Java, Visual Basic, ActiveX, OLE, CORBA, etc., etc., in our curriculum. Industry must shoulder their share of the blame by expecting colleges to crank out experts in these "tools of the day". It’s fairly clear to me that providing undergraduate training in today’s professional toolset is like giving a high-powered rifle to a novice hunter. They might shoot something, but they’ll surely make a mess of it most of the time.

I also cringe whenever I hear academics arguing about why students should use components in their introductory courses. While using components plays a role in introductory concept development, it falls far short of what design with reuse is really all about. In any design medium it’s important for students to be familiar with the tools of the trade, including component libraries (such as the Microsoft Foundation Classes). But it is more important that students practice expressing ideas in the medium, exploring alternative mediums, thinking about alternatives, and building conceptual models.

Most of our Universities give computer science degrees that are far too short on analysis, both formal and informal, and far too long on non-introspective hacking. Students are more interested in getting the job done for an assignment than in understanding the greater ramifications of what they’ve done. A colleague of mine had some sage advice for me when I fell into the trap of wanting to shoehorn yet another topic into the curriculum: "A student takes 120 credits in four years, only 40 of which are computer science courses. We not only can’t teach them everything, but we shouldn’t try. They’ll master the tools in industry. Our job is to help students teach themselves how to think!"

Indeed, most students don’t know how to uncover and evaluate alternatives, don’t learn from their mistakes, don’t develop their own framework from first principles, and don’t know how to apply their newly found knowledge to new and unusual domains. In short, they don’t know how to think!

My position is that to understand the hard systemic problems of software reuse, a student has to first learn to be a good computer scientist and software engineer. The student has to be aware of a wide variety of topics and to know how to develop experience in applying them. To do this, the student needs to develop skills stating implications, challenging assumptions, considering alternatives, and using previous experience/knowledge about the multiple domains that are typically brought to bear on a problem.

In short, the student needs to learn how to think. Students don’t need to be trained to be good computer scientists and software engineers, they need to be educated to be good computer scientists and software engineers. Furthermore, this education is not complete when they leave the university and enter the job market. The best we can hope for is that it has been properly begun.

As academics, our responsibility is to mold students so that they are in a position of understanding and appreciating the hard problems of systematic reuse. As I said earlier, presenting the latest whiz bang tools, environments, and methodologies is nice, but when they are presented without the proper background they are a waste of the student’s time.

Liesbeth Dusink and I studied the human process of creating software, and found that software engineers have some very deep rooted problems to overcome [2]. Specifically, they tend to design solutions to problems in ways that are functionally fixed. That is, they tend to design in ways that solve particular problems at hand, and not always in ways that are easily generalizable. In order to fight this tendency, we proposed that they practice uncommitting design decisions from these functionally fixed designs in ways that lead to the generalizations they seek. We observed that this uncommit process is done with the support of exactly those concepts stated in the previous section: reasoning by analogy, stating implications, challenging assumptions, and above all properly applying previous experience/knowledge.

But this type of thinking is what a good university education should foster, not just in technical courses, but across a broader liberal arts curriculum. Unfortunately, a number of factors combine to "squeeze out" the time necessary to properly do this. Here are just a few examples in a typical undergraduate computer science curriculum:

• Introduction to programming: all too often students are asked to write programs to solve vaguely specified problems and hand in solutions with poorly structured and documented programs. This is typically followed with very little feedback on program structure, and very little sense of alternative ways to solve a problem. It is the process and not the product of program design that we need to focus on.

• Data Structures and Algorithms: students are typically asked to learn a wide variety of textbook artifacts (data structures, algorithms, proofs of correctness) without focusing on the deeper question of context. When I lead this course I get across the important concepts of our community without ever having to be explicit about reuse. I do this through an exploration of alternatives, often complex, often heavily context dependent, and almost never cut and dried. Linked list structures are a good example. Design decisions include single vs. double linking, anchors, current vs. previous pointers for object handles, and the resulting O(1)/O(n) operation complexity tradeoffs. Often students choose one alternative from the many implementation choices only because it’s the simplest alternative they know. The goal is to design problems that get down to hard context-dependent choices.

• Operating Systems: again, this course is about alternatives: alternative process scheduling algorithms, alternative memory allocation schemes, alternative disk caching schemes, alternative synchronization mechanisms. It is in effect a course focusing on a domain specific software architecture. These alternatives interact with applications in complex ways that can only become clear with a great deal of introspection and understanding of use context. My personal approach is to provide a small but rich operating system project that allows students to "feel" and discuss the ramifications of their design decisions. However the course is led, students need to develop a feel for why choices are made.

Even on the graduate level we need to be careful that we don’t deal with reuse prematurely. Consider the course I lead on the Specification and Implementation of Software Systems, focusing on the mechanics of software systems development. Topics include the ramifications of David Parnas’s separation of concerns and information hiding, Mary Shaw’s architectural design styles, Gregor Kiczales’s meta-object protocols and aspect-oriented programming, Bruce Weide’s RESOLVE discipline, and Don Batory’s architecture generation work. Reuse is a concern but not the main focal point. Understanding the alternatives one faces when constructing a software system is.

One way to provide students with experience in understanding design alternatives is by guiding them through the construction of a number of small systems. But this is extremely time intensive. Another way is through a rich set of case studies. One such case study is Starlogo [5], a multi-agent modeling system we’ve been porting from the Macintosh to the PC. Starlogo was originally developed by the MIT Media Lab for use in the K-12 community.

Each different case study is designed to highlight a specific concept important to the student. This particular case study explores issues related to the aspect oriented programming of Gregor Kiczales [4]. Specifically, systems provide both an abstract model and an implementation model for integration into application architectures. For example, while many applications make use of the abstract model of a window, a typically "heavy" implementation model will probably not be useful in applications requiring large numbers of small, dynamically opening and closing windows — spreadsheet cells for example. We’ve experienced the same problem with the Starlogo port. While the abstract model of Starlogo seems straight-forward, the implementation model required to satisfy our speed requirements led to a fairly complex implementation architecture.

Using turtle graphics primitives, students can program hundreds of individual turtles to move around on and interact with a cellular automata grid. The main implementation requirement for these creatures is that they be fast. This is necessary in order for dynamic population behavior to emerge visually. We ported a significant amount of the original source architecture to the PC. The architecture consisted of a front end Starlogo compiler and scheduler written in Lisp, and a back-end byte-code micro-machine written in assembler. We ported the compiler/scheduler almost intact, rewriting the micro-machine from by hand-translating the assembler code to C.

The details of this port were described in [1]. Without getting too deeply into the implementation architecture, we found that the following issues were critical:

• Partial compilation: Starlogo code for each turtle needed to be compiled into a Java-like byte code that was then generated by an efficient Micro-machine.
• Scheduling: turtle code was scheduled in a MIMD fashion using a small time-slice to simulate highly parallel execution in the visual environment
• Efficient Micro-machine: while the original micro-machine was coded in assembler, it was sufficient for the PC micro-machine to be coded in C.
• GUI Interface: while the original micro-machine updated a screen buffer directly, the PC micro-machine needed to provide a level of indirection through an API using directX.

This project has turned out to be a wonderful case study in stating implications, challenging assumptions, and considering alternatives. Here, were a few issues raised:

• Why did we port the front end intact in Lisp? The original compiler was written in Lisp because (1) it was an integral part of the MIT software development environment, and (2) Starlogo, a variant of Logo, was similar in syntax to Lisp. We ported the front end intact because we simply didn’t want to deal with rewriting the entire compiler, which we didn’t know very much about. It has since been suggested by the Media Lab designers that we rewrite the front end, if only to clean up the fairly messy implementation.

• Why was the micro-machine implemented in assembler? Both we and the Media Lab design team assumed that we needed to squeeze every last ounce of execution speed out of the micro-machine. It turns out that with faster machines, the bottleneck is not here. It’s in the API. Also, C compilers generate fairly efficient code when not heavily using procedure calls.

• Why not duplicate the Macintosh effort and write directly to a low-level screen buffer? We realized that to make the PC implementation compatible with a wide range of graphics cards we would have to provide a level of indirection through an API. Using Microsoft’s DirectX was a reasonable compromise.

We certainly could have considered the reuse issues concerning this "family" of cross-platform system implementations. But just getting the student project team to recognize the implications of the variety of implementation alternatives was not an easy task.

Are students getting short-changed by not being exposed to reuse practice? I think not. They’re getting short-changed by not being exposed to critical thinking scenarios. Reusability is an —ility that in itself is not a primary goal of the curriculum. Composability and adaptability are closer to what we should be focusing on, but the underlying issues of these —ilities are what we need to provide a firm grounding in.

While computer science education journals talk about a number of these issues, few in our community are actively addressing the underlying principles specific to us as educators. Neither do they explicitly have to. But it would be very useful to have a series of case studies from the community that could be used in the way that our Starlogo project has been used. Projects such as those described by Greor Kiczales [4] and Dave Garlen [5] are just two examples, but there are many others out there that can be extremely useful to educators.

Larry Latour is an Associate Professor of Computer Science at the University of Maine, having received his PhD degree in Computer Science from Stevens Institute of Technology in 1985. His work was in the development of a model theoretic approach to concurrency control, and he has since looked at how algebraic specifications of abstract objects can enhance concurrency control in object databases. At the same time he developed his software engineering interests at the Ft. Monmouth Center for Software Engineering. He was introduced to reuse in 1986 at the Syracuse University Annual Software Engineering Workshop in Minnowbrook, NY, where he and a small group of Tools and Environments working group members began what is currently the National WISR workshop series on software reuse. In conjunction with this workshop he manages the WISR repository at Maine. Along with his reuse interests, Larry is exploring interdisciplinary teaching techniques and K-12 learning environments, all of which focus on the understanding problem.