Lecture Series James Overton Mining Software Design Patterns
Above: Mr. James Overton with Dr. Linda Hayden
Brief Overview of James Overton's Research and Development Experience
Mr. Overton began his R&D experience at IBM in 1969 where he worked for two years. During that time, he was a Sr. Test Development Engineer. He was responsible for developing and programming test for S/370 computer circuit boards. During his first week on the job at IBM, Mr. Overton was faced with a special problem: the high cost of circuit board testing. Six months later, Mr. Overton had solved that problem and saved IBM $1,000,000 over a five year period. In 1975, Mr. Overton went to work at ITT Standard Electrica in Madrid, Spain. Mr. Overton was a Reliability and Quality Manager. He was given a problem that no one had been able to solve: the reliability calculation of an entire electronic telephone exchange. Six months later, Mr. Overton solved the problem and published the results in the Mundo Electronico(Electronic World). In 1977, Mr. Overton was assigned to a team of three Spaniards whose job it was to develop a graphical, real-time, multitasking programming language called Galileo. One year later, they had done so and presented the results to ITT and NATO representatives. In 1983 in Ottawa Canada at the National Research Council, Mr. Overton continued conducting R&D on graphical, real-time, multitasking programming languages for the modeling of program behavior. Eighteen months later, he had proved the concept and produced a prototype on a minicomputer. In 1985, Mr. Overton formulated the concept that software designs should be extracted from old code and placed in handbooks, much the same as designs are done for other engineering disciplines. This is what has led him to be interested in design patterns, whose object it is to make good practices known throughout the software industry.
Photos
Above: Math and CS Students listen to Mr. Overton
Notes
Mining Software Design Patterns Introduction Pattern mining has to do with the quest for increasing one's personal productivity and one's ability to produce quality products and services by discovering and using methods that have worked well for others. Productivity and quality are important because historically, few organizations have reliably met their cost and schedule commitments. This poor record has not only given software engineering a bad name, it has also caused serious problems. There are many examples of business failures, contract disputes, lawsuits, and customer inconvenience. Ashton Tate, a major software firm, went out of business because of poor quality software. Each Pattern describes a problem which occurs over and over again... and then describes the core of the solution to that problem in such a way that you can use this solution a million times over, without ever doing it the same way twice. Pattern Content Name Problem Context(of the problem) Forces Author and Date Rationale for the solution Consequences(of using the solution) Related Patterns Known Uses The Solution Mature, proven(rule of 3) Something you did not invent yourself Built on the insight and creativity of the problem solver Can be implemented a million times without ever being the same twice Aggressive disregard for originality Example: System Test Pattern Pattern: End User Viewpoint Problem: How do you test new features in a system without repeating tests that have already been completed? Forces: Duplicate testing takes up valuable schedule time. There is a perception that code not changed since feature testing doesn't require system testing. Because of feature interactions, changes to one feature can affect another feature. Solution: Test outside the normal scope of the features. Take the end user's point of view. Don't system test with the same tests used for feature testing. Use the customer documentation. Test feature interactions. Resulting Context: By testing from an end user point of view, flaws in the system as the end user will use it, can be discovered and corrected before the system is shipped. Test tests expand the scope of previous testing and are not redundant. Rational: End users don't use systems as they are designed. Designers develop features, but the system is sold to provide service to the end user. These are these services that the end user sees, not the features that are developed by the designer. No Pattern is an island The benefits of a set of related patterns is more than the sum of the benefits of each individual pattern in the set. Law of Conservation of Problems The application of a set of patterns to solve a series of problems can uncover another series of problems. Patterns and all problem solving techniques are subject to the law of conservation of problems: Problems can not be destroyed; they can only be transformed. A Pattern is not... A simple rule A prescriptive recipe An algorithm or data structure A fequently asked question Just a clever idea by one person Etched in stone Rather, a pattern is... A way of capturing broad practices that have been proven good. A living thing that changes as we learn more about the problem, context and the solution. Pattern Mining Capture knowledge and document it in the form of a pattern Pattern Mining - How do we find patterns? Patterns aren't manufactured or created. They are mined from proven practice. They must be sought out, verified, and carefully codified. Pattern Mines - Old Discarded Programs and Code Millions of dollars were spent on developing software applications that became obsolete and have been discarded without attempting to salvage the valuable design information embedded in them. These software applications can be loosely classified according to use as: Administrative Scientific Technical Training Testing Support These software applications can be loosely classified according to the industry which uses them as: Power Garment Utilities Healthcare Department Stores Electronics Defense Communications The Opportunity Software engineering is one of the few disciplines in which the wheel is reinvented on a project basis almost all the time. Civil, electrical, and mechanical engineers have handbooks in which the best practices are presented and explained. There exists and opportunity for interested people in the field of software engineering to create such a handbook of best software engineering practices. This work can be done by either advanced undergraduates or graduate students. Types of Patterns in the Handbook Structural Patterns - represented by class diagrams Behavior Patterns - represented by sequence diagrams Format of Patterns in the Handbook Name - simple descriptive term Intent - brief description of aim Motivation - concrete example Applicability - where is it useful Structure - blueprint diagram Participants - each class in the pattern Collaborations - relationships among participants Consquences - implications of use Implementation - general implementation Sample code - for a particular application Known uses - applications where used Related patterns - to combine or substitute
Return to ONR