OOPSLA '04

Program
Technical Program
  Invited Speakers
  Technical Papers
  Onward!
  Panels
  Practitioner Reports
  Tutorials
Workshops
DesignFest
Educators' Symposium
Demonstrations
Posters
Doctoral Symposium
Exhibits
Student Research Comp.
FlashBoF
 
Turing Lecture
 
Social Events
 
Week at a Glance
 
Final Program (1.5M .pdf)

Find in Program
 

Page
Printer-friendly

Basket
view, help

"The Elements of Software Design"
Object-Oriented Programming, Systems, Languages and Applications
Home    Program    Housing & Transportation    Registration    Submissions    Wiki    Maps
 
  > Technical Program > Tutorials > All Tutorials

 : Wednesday Afternoon Tutorials (1:30 - 17:00) : Wednesday

The Elements of Software Design

Meeting Room 8
Wednesday, 13:30, half day
 


 
7·8·9·10·11·12·13·14·15·16·17·18·19·20·21

Jeff McKenna, Net Objectives:  Jeff McKenna has been involved in the software industry since 1963 in programming, system design, architecture, project management, sales and marketing, and as a small business owner. In the last decade, Jeff has focused on the problem of rapid development of software using object-oriented technology and agile processes. He has trained, coached, and mentored developers and customers to help them succeed using object-oriented technologies, facilitated implementation of agile processes, provided analysis, architecture, design expertise, testing, and defect tracking for companies large and small. He has given talks and presentations around the world on XP, development processes, design patterns, software testing and object-oriented development.
David Socha, Ph.D., Center for Urban Simulation and Policy, University of Washington:  David Socha is currently a Project Manager in the Center for Urban Simulation and Policy Analysis, and a Lecturer in the Computer Science & Engineering department of the University of Washington. David has over 20 years experience developing software in industry and academia, received an award for his software engineering teaching, has published several papers on teaching techniques, and is an active member of the American Society of Engineering Educators. His interests revolve around the human aspects of software development that drive success.

Tutorial number: 50

In the classical waterfall definition of software engineering, software design resides between Architecture and Coding. Software Design is often defined as the process by which a higher-level architecture is divided into low-level descriptions with enough detail so that the design documentation can be given to another developer for implementation. Software Design is often equated with being object oriented, or with UML modeling, or design patterns. All of these are poor descriptions of software design because they are talking about the tools and the artifacts of software design rather than the process and principles. Design is about problem solving and thus software design is about solving problems with software. In this course, we will learn that design is an iterative, collaborative, logical process for solving problems. We will learn that design is about testing ideas, failures and successes, about making rationalized selections or decisions, about compromise and optimization. We will learn about the components of a software design process, about strategies for communicating software designs, and about incorporating feedback and critique in producing still better software designs.

Intermediate: Attendees are expected to know how to program, but there are no other constraints on their knowledge. This tutorial is designed to provide a set of practices that developers at any level in their career can apply to become a better software designer. The tutorial will be more useful to those with less experience, but it will be worthwhile even for experts. Simple Test of Whether You Should Take This Course: Do you design solutions to problems before you start writing code? Do you document (in any way) those designs rather than just keeping the designs in your head? When doing design, do you seek criticism and then incorporate the suggestions into your design? When doing design, do you design at least three different solutions to the same problem and then choose the best one? When doing design, do you have a definition of how to measure "the best solution"? Have you read the design documentation of any other software system? Are all your designs the simplest solution to the problem? Do you have a personal design process (other than "I sit around and think about it")? If you answered "no" to two or more questions, this course is for you.