Since this workshop deals with design (as opposed to analysis), the expectation of analysis is addressed so that we can begin discussing design from the same point. Analysis, at the least, needs to include the list of requirements for the system and the definition of terms in order to avoid later confusions. The list of requirements may contain interfaces to hardware, user requirements, and quality requirements. Of course, as the design is fleshed out, iterations going back to analysis make sure there are no missing requirements and that there are no requirements that are impossible to meet. Analysis, ideally, includes end-to-end system scenarios that fulfill and help to fully define the requirements. End-to-end system scenarios are scenarios that model the system as a whole and completely fulfill the requirements. They should be broad enough so that the customer can use them to see if their wishes are being met.
Simply put, a good design is one that meets the following criteria:
The KISS principle - Keep It Simple Stupid.
Design is an iterative process. The first pass at design should be the 'ideal' system design. No database specifics or platform considerations are given in the first pass design. The first pass design is the first step from analysis to design in which the designer starts thinking about the objects that will make up the system. The designer uses the results of analysis to identify objects and assign responsibilities to them. As this list of objects is iterated over, the designer is able to consolidate the list discarding, consolidating and more fully defining the objects. The subsystems are determined by the grouping of clustered objects. By drawing object diagrams, the designer can clearly see clusters of objects as given by the abundance of communications between them. Although in some cases, the subsystems are defined first, and then the objects are assigned to them. In most systems, the basic subsystems are the communications, the persistent data storage and the user interface. In the second pass of design, platform and database specifics need to be considered. In the second pass, specifics of the system are dealt with and usually the design is not as 'ideal' as it was in the first pass.
If you talk to good designers, you will find that what makes them good designers is experience. They know how to solve the problems because they have seen them before. They know where they are going with a design because they have already been there. So, how can experience be taught?
Design patterns are a very good way to relate experience in systems to first timers. Although patterns certainly do not replace the needed experience, they do help the non-experienced start with more of a knowledge base. With the widespread activity in the patterns community and the many books and articles being published, many patterns are already easily accessible to teachers.
Students need to be introduced with simple examples so that the student is not confused too often and discouraged. Students need to see applicability, therefore examples that take them through building small systems, and pieces of systems are a great way to transfuse the experience into them. Having assignments that are system based (e.g. a small town, a university campus, a video store, etc...) and not 'data structures and algorithms' based helps the student to understand what building a system entails.
Classroom group activities should include design reviews where the reviewers are the students classmates and the professor acts as facilitator. Assignments should not only give the student a chance to develop 'from scratch' but also add enhancements or re-architect an existing system.
The student should be given guidelines on required documentation. Documentation should at least address: class comments, design diagrams, and interface documents (between subsystems). At least one assignment should include a list of requirements where one is not doable given another. This assignment teaches the student not only how iteration is useful, but gives them a real-world experience.
The student should take an introduction to an OO language in conjunction with this class. By structuring the curriculum this way, code examples may be used to help illustrate ideas effectively. In both classes, the importance of design should be emphasized and illustrated with examples of what can go wrong if design is left by the wayside.
The role of OO design in the first year is to take the student through examples of building systems including all the dynamics of an industry team environment.
In reviewing a design, the reviewer validates that the design meets the requirements, does not have unnecessary complexity, and the existence of each subsystem and object is rational. Determining unnecessary complexity may prove to be a difficult task if one lacks experience. Design patterns can help and the advice of an experienced OO designer is invaluable. By the rationality of subsystems and objects, I mean that each has proven its right to be by having logical responsibilities. The importance of sharing a design with others needs to be illustrated to the student. Refining the design, identifying potential problem areas, using the experience and knowledge of fellow team members, gaining insights, taking criticism, and other useful experiences that occur during reviews, are not usually formally addressed in the classroom situation, but are expected and necessary in the real world.
I have been interested in the teaching and learning of OO design since I took my first OO design class. I later saw many shortcomings in my introduction to OO design and wish to share my views in the hopes that others may gain from my experience. I have been greatly intrigued with the idea of developing a software application that teaches OO design, which is inclusive of teaching how to build systems. Although I am not a teacher in the academic sense, I find that throughout industry, the experienced take on the role of teacher/mentor for the less experienced.
I wish to share my insights on what I found to be lacking in my introduction to OO design. I found that in my first academic course that claimed to teach software design, the course actually did not teach design at all. It was mainly concerned with teaching data structures and algorithms particular to one specific language. Academic courses need to be restructured drastically to adequately address good OO design. First year courses need to be structured similarly to industry design teams so that students gain experience out of their courses that is relevant to the real world as well as providing a good ground for future courses.
I have found no examples of OO design in the first academic year - I have found several post-graduate courses and courses for industry professionals. None I have seen try to emulate industry by treating the class as a team, building systems, maintaining systems and using design reviews as would occur in the real-world. At my company, KSC, STAPs (Smalltalk Apprentice Programs) do this to a certain degree but are geared toward the professional, not a first year academic student.
Recently, an article was published on a tool for scaffolded examples that teach the user OO design. This article touches on ideas described in this paper and could be potentially a good learning tool.
Design Patterns. Gamma, Helm, Johnson, Vlissides.
Scaffolded Examples for Learning Object-Oriented Design. Communications of the ACM. April 1996, Vol. 39 No. 4. Mary Beth Rosson and John M. Carroll.
I have been working with Smalltalk for three years. My first industry job using OO design was in the telecommunications industry. I am currently working at Knowledge Systems Corporation. My OO experience consists of VisualWorks (and Envy), Gemstone, the Booch methodology with Rational Rose, Jacobson with Objectory, and various other methodologies and tools.