Evolution, Architecture, and Metamorphosis

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
в–є Design
Pattern definition
в–є Software Tectonics
в–є Flexible Foundations
в–є Metamorphosis
Design Patterns
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
в–є Also can be seen as a partial solution to a
common problem
в–є According
Widget Generator
в–є Tool
that uses the
set of classes
created by the
widget generator
Abstract Factory Pattern
Abstract classes and
abstract (virtual)
в–є 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
Software Tectonics
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
в–є 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
в–є 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
в–є Previous design pattern allows users to add
features, this one allows them to change
в–є 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
в–є 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
в–є 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