Evolution, Architecture, and Metamorphosis By: Brian Foote and Joseph Yoder University of Illinois Presented by: Gleyner Garden

About the Authors ► Both involved in researching object oriented programming especially when it comes to design and reuse at the University of Illinois ► Collaborated on this paper to explore new approaches to software development for Caterpillar

Introduction ► Design Pattern definition ► Software Tectonics ► Flexible Foundations ► Metamorphosis

Design Patterns ► According to Object Oriented and Classical Software Engineering, a pattern is a “solution to a general design problem in the form of a set of interacting classes that have to be customized to create a specific design” ► Also can be seen as a partial solution to a common problem

Widget Generator ► Tool that uses the set of classes created by the widget generator

Abstract Factory Pattern ► Abstract classes and abstract (virtual) methods ► The interfaces between client and program and generator are abstract ► The application program is uncoupled from the specific operating system

Patterns and Reusability ► If a design pattern is reused, then an implementation of that pattern probably can also be reused. ► Motivation for reusability: $$$ ► Example: GTE Data services implemented a successful scheme which saved the company $10 million in 5 years

Back to our Paper ► Foote and Yoder wanted to bring this sort of success to the Caterpillar corporation ► By doing so would allow Caterpillar to confront rapid change; “Software that cannot adapt as requirements change will perish”

Software Tectonics ► A high-level pattern which fulfills the need to deal with steady and unrelenting change over a long period of time ► Name derived by analogy of the benefits of many small earthquakes removing stress over a period of time as opposed to a sudden catastrophic one ► Gives the ability to tailor a system to meet individual needs by adapting to change as requirements change in a series of small, controlled steps ► By making a system tailorable, it greatly increases its reuse potential

Examples of Software Tectonics ► Customizable desktops ► Short-cut creation ► Modification of existing abstract classes to meet needs

Flexible Foundations ► Used to resolve some of the forces unleashed by the first by showing how to construct systems that can cope with change ► Name derived again from earthquake analogy ► Allows for selective exposure of the internal architecture of the system so that the elements of this architecture can serve as basis for changes and extensions (substructure, not source code) ► A flexible system that can easily be changed by its developers which will allow for fulfillments of new unexpected needs

Example of Flexible Foundations ► Dupont Model ► graphical model of a view of Profit/Loss statements for businesses. It provides a quick way for managers and accountants to view their return on assets ► A common interface widget that is used many times. By adding a "DuPont widget" to the visual builder with methods for the automatic generation of related code, the developer can quickly tailor different DuPont models to meet the needs of different users

Metamorphosis ► Helps to resolve the forces that arise in evolving systems by providing a means by which a system's behavior can be augmented without changing its primary interface. ► Previous design pattern allows users to add features, this one allows them to change features ► Further extends the life of software

Analogy of Metamorphosis ► There are two ways to change what happens on-stage during a play. The most direct way is to change the script, but you can also change the actors: Jim Carey VS. Anthony Hopkins ► If one wants to change the way a program works, one could change its code or data directly, or change the way that some underlying element of the system on which the application depends works ► Example: extensions to existing tools can be incorporated in the menus for other tools. Instead of creating a whole new tool you can adds capabilities to the existing tool. In order to do this, the tool's menus must be designed using a metamorphosis pattern

Evolution, Architecture, and Metamorphosis ► To be successful, software has to be able to rapidly adapt to changing conditions and requirements. To cope with this fact, software researchers and developers must find new ways to confront the need for continual evolution. ► Software must be designed so that it can change with the requirements that drive its evolution ► These design patterns when used with object oriented programs will allow for change and in doing so, will decrease maintenance and increase the lifespan of a software product

Conclusion by SW Author Brian Cox “Software is not at all like wood or steel. Its paint does not chip and it does not rust or rot. Software does not need dusting, waxing, or cleaning. It often does have faults that do need attention, but this is not maintenance, but repair. Repair is fixing something that has been broken by tinkering with it or something that has been broken all along. Conversely, as the environment around software changes, energy must be expended to keep it current. This is not maintenance; holding steady to prevent decline. Evolution is changing to move ahead.”

Questions/Comments ?