Tutorials

Important Dates
Submission deadline: March 19, 2007
Notification of acceptance or rejection: May 11, 2007
Deadline for camera-ready copy: July 30, 2007
Conference begins: October 21, 2007

Overview
This call for papers is an invitation to submit proposals for top-quality tutorials for OOPSLA 2007. OOPSLA will be held this year in Montreal from October 21-25, 2007.

OOPSLA attracts a unique mix of academics and practitioners who are interested in a wide variety of topics relating to object-oriented programming techniques, languages, and development methodologies.

OOPSLA tutorials are half-day classes, taught by experts, designed to help software professionals rapidly come up to speed on a specific technology area or methodology. Tutorials can be lecture-oriented or participatory.

About OOPSLA Tutorials
OOPSLA tutorials are half-day sessions consisting of two 90-minute blocks separated by a 30-minute break. Tutorials rooms are equipped with a laptop projector. Presenters prepare handouts that are provided to attendees before the tutorial session. These handouts are submitted by presenters to the conference several months in advance.

OOPSLA tutorial attendees deserve the highest standard of excellence in tutorial preparation and delivery. Tutorial presenters are typically experts in their chosen topic and experienced speakers skilled in preparing and delivering educational presentations. When selecting tutorials, we will consider the presenter's knowledge of the proposed topic and past success at teaching it.

Many tutorials use a traditional lecture style, with a series of slides that pace or keep stride with the speaker. An increasing number of tutorials use formats that involve attendees more actively, such as presentations that:

• show the presenter writing code or other artifact during the presentations;
• ask the attendees to develop software or other artifacts during the presentation; or
• teach attendees an educational game and let them play it.

We encourage the submission of tutorials that will teach in a nontraditional format. As with traditional techniques, your submission should cite previous successes at teaching using the format that you propose.

Each accepted tutorial is compensated in two ways, which can be apportioned among the presenters as they see fit:

• a complimentary admission to the full conference; and
• a $500 stipend.

Presenters are encouraged to stay for the entire conference.

Submission and Selection Process
Tutorial proposals will be submitted electronically through the OOPSLA submission system. Submitted proposals may be modified up until to the submission deadline. The tutorials committee will evaluate all tutorial proposals.

The selection committee consists of practitioners and researchers from industry and academia. When evaluating proposals, the committee will consider:

• Relevance, interest, and value of the topic to OOPSLA attendees;
• Completeness, clarity, and quality of the tutorial proposal;
• Expertise and experience of the presenters in the proposed topic and in delivering a successful educational presentation; and
• Effectiveness of the proposed presentation approach.

While proposals are due on March 19, 2007, the committee may read early proposals and work with the submitters to refine proposals that would benefit from additional information or small changes in content or format.

Accepted tutorials become part of the OOPSLA 2007 Tutorial Program and are described in the Advance Program using the abstract provided in the proposal.

OOPSLA may cancel accepted tutorials prior to the conference if there is not sufficient attendee interest.

Submission Contents
Each tutorial submission should include the following:

• Title. Choosing a good title can be more challenging than you might think! The title will serve as the first synopsis of your tutorial -- it is important to choose a short title that accurately describes your tutorial and motivates potential attendees to at least read the abstract.
• Abstract. A 200-word (maximum) description of the tutorial, which will appear in the OOPSLA Advance Program. This is your advertisement to (and contract with) participants, will who decide whether or not to take this tutorial based largely on this information. Attendees will also rate your tutorial based on whether you delivered on the promises made in the Abstract.
• Keywords. Along with the Abstract, these keywords help us to understand better the main topics of the submission and to choose appropriate reviewers.
• Presenters. For each presenter, include name, e-mail address, affiliation, address, and a brief biography listing their expertise and experience with the subject. If there are multiple presenters, please clearly designate the contact person for the tutorial.
• Attendee background. Briefly describe the knowledge attendees must or should have in order to benefit from this tutorial.
• Tutorial objectives. This should mirror the abstract, but without the advertising element. Explain what knowledge and capabilities the attendee will gain by attending this tutorial.
• Presentation format. Will this tutorial be a slide-based lecture, a hands-on exercise, a group problem-solving session, a game, some combination of these, or something else? Will participants be working on their laptops?
• Scheduling constraints. If the presenters have any constraints on when they can present the tutorial, these should be listed. These can refer to specific days or to other OOPSLA activities to which the presenters are committed.
• Can repeat? Are you willing to repeat the presentation of this tutorial if there is sufficient demand?
• Tutorial presentation history. A summary of the tutorial's presentation history, if it has been presented previously. If it is a new tutorial, simply indicate that it is new.
• Target audience. Indicate the audience(s) who will most benefit from this tutorial: researchers, practitioners, managers, educators, and/or others. If you check "others,", please explain in the Remarks field.
• Status. The current status of the material covered by this tutorial. You must, at minimum, indicate one of the following:
• The tutorial covers new ideas, which are not yet validated as of the time of the proposal submission.
• The tutorial covers material for which some preliminary validation or proof-of-concept exists. This include being accepted for publication at a major peer-reviewed conference or journal, being used in test applications or evaluation scenarios, being presented to standards boards, etc.
• The tutorial covers material for which significant validation exists. This includes acceptance by standards boards, being used in non-trivial applications and/or real-world settings, publication of material in a book by a major publisher, etc.
• URL with additional info. If you have additional information about the material contained in the tutorial available on the web, please include a URL for this web site.

Examples
Below are some exemplary examples of four portions of a tutorial proposal: Abstract, Objectives, Attendee Background section, and Presentation Format. We provide these as good examples of the requested information. (No endorsement of the topic or content is implied; they are merely for illustration.)

Example Abstracts:

Abstract. When the performance penalty of object-oriented systems is mentioned, a common response is to blame antiquated hardware designs for not supporting object-oriented languages as they deserve. To what extent can the performance gap between conventional languages and object-oriented languages be closed using hardware? What architectural changes benefit object-oriented systems, and by how much? There have been many attempts to make hardware that better supports object-oriented programming. This tutorial describes some of these systems, and the extent that they have succeeded or failed in their aims. These systems include the iAPX432, SOAR, Rekursiv, and MUSHROOM, as well as some features from mainstream architectures such as SPARC.

Abstract. This tutorial presents techniques for improving, understanding, and expressing object analysis and design models. These techniques include development of: Use Case Conversations, User Stories, User Navigation Models, CRC cards, object behavior stereotypes, control-style analysis, behavior refactoring worksheets, hot spot cards, and flexibility design. These techniques can be successfully applied to augment your analysis and design toolkit, regardless of methodology. This tutorial will be conducted as a hands-on-workshop where we review guidelines and examples to illustrate key techniques, and use the techniques to develop the artifacts.

Abstract. There are many issues that need to be addressed before a truly reusable C# class library can be built. This tutorial will examine these issues from both an abstract perspective (design) and a pragmatic perspective (code).

Abstract. As Java projects grow, they tend to hit the Java productivity wall--the point at which added resources do not contribute proportionately to project progress. This can happen at any point between three to six or more developers. This tutorial defines the problem, surveys available products, and provides generic and customized practical solutions using CVS as a model.

Abstract. A project that is using object technology and an iterative development process faces a number of unique issued in order to deal with the project's entire life cycle. This tutorial presents a process framework that can be tailored to a specific project's situation. The tutorial follows a logical order of topics facing projects. Topics include estimating, scheduling, methodology selection, iterative development, and reuse. Specific advice derived from multiple project experiences is given during the discussion of each topic area.

Example Objectives:

Objectives. The intermediate level C# programmer who attends this tutorial will gain experience in the following areas: the relationship of ASP.NET and code behind; the creation of skins and a few other advanced GDI+ capabilities; leveraging delegates and events; techniques for efficient operator overloading; the use of anonymous methods.

Objectives. This tutorial is intended to prepare the participant (1) to determine whether a native XML database is appropriate technology for his or her database needs (2) to understand the technical tradeoffs between relational and XML technologies, and (3) to evaluate the commercially available XML persistence products.

Objectives. Participants will learn 10-15 GoF patterns well enough to explain their purpose.

Objectives. Participants will be acquainted with a comprehensive test plan that includes test-driven development, the new relationship of developers and test teams, and how to position testing as a function within a typical corporation.

Example Presentation Formats:

Presentation Format. This tutorial will be lecture based.

Presentation Format. This tutorial will be 70% lecture and 30% individual paper exercises.

Presentation Format. This tutorial will offer a minimum amount of lecture, with the majority of time spent in small groups trying to solve specific problems. Lectures will be used to deliver the key points but after approximately every 30 minutes of lecture, participants will complete a set of short exercises to reinforce the lecture material. Solutions to the exercises will be presented and discussed.

Presentation Format. After a brief introduction by the presenter to set the scope and objectives for the session, participants will be divided into groups, and each group given one of four different problems to solve. Then two groups that have tackled different problems will swap members to compare solutions and prepare a poster that explains how the differences in the problems affected the solution approaches taken. There will then be an opportunity for all participants to view and discuss the posters. In the second half of the session the process will be repeated but with different group memberships and different problems. The session will end with the presenter drawing together the results of the exercises and explaining how they compare with recently published research results.

Example Backgrounds:

Background. Participants should be experienced Java programmers.

Background. Participants should have a general familiarity with the object-oriented paradigm, preferably being fluent in one or more object-oriented languages. Familiarity with C# will be useful, but not required. The intended audience is professionals charged with developing or managing instruction in object-oriented techniques, either in a university or industry context.

Background. The tutorial is targeted to those individuals interested in the managerial issues that influence the success of object-oriented software development efforts. It is assumed that the audience has some familiarity with the basic concepts of object technology and have begun to worry about how to effectively employ the technology.

Background. Basic knowledge of the operational behavior of languages, particularly inheritance and polymorphism, but with no formal theoretical understanding. Only a knowledge of simple set theory will be required; and a willingness to perform certain mathematical substitutions. The tutorial is aimed at software professionals wanting to write type-correct software; language designers wanting to understand type issues in OOP; final year undergraduates and first-year graduate students wanting to relate traditional notions of type to OOP.

For More Information

For additional information, clarifications, or answers to questions, please contact the Tutorials Chair, Brian Goetz, at tutorials@oopsla.org.

It is important that you contact the chair if you have special requirements for equipment, room set-up, or limitations on attendance. These can be expensive and can affect the likelihood of acceptance.

Tutorials Program Committee

• Brian Goetz, Sun Microsystems (chair)
• Shail Arora, Gradepoint, Inc.
• Joe Bowbeer, independent consultant
• Steve Metsker, independent consultant
• Ted Neward, independent consultant
• Bill Pugh, University of Maryland
• John Rose, Sun Microsystems
• Russ Rufer, independent consultant
• Brian Sletten, independent consultant
• Glenn Vanderburg, independent consultant
• Eugene Wallingford, University of Northern Iowa