[Ber91] P. Bergstein, “Object-Preserving Class Transformations”,Proceedings of OOPSLA ‘91, 1991.[Coa95] P. Coad,Object Models: Strategies, Patterns, and Applications, Prentice Hall, 1995.
[Foo94] Brian Foote and Bill Opdyke, “Consolidation and Aggregation Patterns that Support Evolution
and Reuse”. Submitted toPLOP ‘94.
[Gam92] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, “A Catalog of Object-Oriented Design
Patterns”, Technical Report in preparation, IBM Research Division, 1992.
[Gam94] E. Gamma, R. Helm, R. Johnson, and J. Vlissides,Design Patterns: Elements of Reusable
Object-Oriented Software, Addison-Wesley, 1994.
[Gri93] W. Griswold and D. Notkin, “Automated Assistance for Program Restructuring”,ACM
Transactions on Software Engineering and Methodology, July 1993.
[Hun92] H. Huni, R. Johnson, and R. Engel, “A Framework for Network Protocol Software”, submitted
to OOPSLA 95.
[Joh88] R. Johnson and B. Foote, “Designing Reusable Classes”,Journal of Object-Oriented
Programming, pages 22-35, June/July 1988.
[Joh92] R. Johnson, “Documenting Frameworks with Patterns”,SIGPLAN Notices, 27(10), October 1992.[LaL91] W. LaLonde and J. Pugh, “Subclassing != Subtyping != Is-a”,Journal of Object-Oriented
Programming, pages 57-62, January 1991.
[Lie88] K. Lieberherr and I. Holland, “Assuring Good Style for Object-Oriented Programs”,IEEE
Software, pages 38-48, September 1989.
[Lie91] K. Lieberherr, W. Hursch, and C. Xiao, “Object -Extending Class Transformations”, Technical
Report, College of Computing Science, Northeastern University, 1991.
[Opd92] W. Opdyke, “Refactoring Object-Oriented Frameworks”, Ph.D. Thesis, University of Illinois at
Urbana-Champaign, 1992.
[Roc86] R. Rochat, “In Search of Good Smalltalk Programming Style”, Technical Report CR-86-19,
Tektronix, 1986.
[Rum91] J. Rumbaugh et. al. Object-Oriented Modelling and Design. Prentice Hall, Englewood Cliffs,
New Jersey, 1991.
[Smi90] D.R. Smith, “KIDS: A semiautomatic program development system”,IEEE Transactions on
Software Engineering, 16(9), pages 1024-1043, 1990.
[Zwe90] J. Zweig and R. Johnson, “The conduit: a communication abstraction in C++”,USENIX C++
Conference, 1990.
6
the program. Also, some of the design patterns will require transformations on the source code formethods. We adopt Gamma’s extensions [Gam94] to Rumbaugh’s notation [Rum91] which can exposea method’s source code.
The work which is most closely related to the work proposed was originated by Foote and Opdyke[Opd92, Foo94]. They suggested a series of program transformations for evolving aggregation relation-ships in object-oriented systems and made an attempt to implement the transformations in C++. The sametransformations are currently being implemented to transform Smalltalk programs. Foote’s design princi-ples are used to justify the transformations created.
At this time, Foote’s principles cannot account for the design patterns being discovered. Principles donot provide concrete target states for transformations as design patterns do and a suite of transforma-tions based on these principles will be incomplete. This may be corrected in time through the additionof transformations which support established design patterns. The other major difference is that thetransformational system in this proposal will be applied to a large and evolving software system. Largesoftware systems differ in complexity from small or proof of concept software systems by orders of mag-nitude. The research proposed is likely to uncover complexities which would never arise in small orartificially constructed software systems.
4 Conclusion
Developing good designs requires experience and experimentation. Design patterns capture object-ori-ented design experience. The proposed research offers the following contributions to design experimenta-tion:
•DIP’s. Identifies a set of domain-independent design patterns which occur in evolving systems.•OOT’s. Formalizes a set of composable transformations which can implement the design patterns iden-tified.
•Proof of concept. Demonstrates the implementation of DIP’s on test programs using the OOT’s identi-fied.
•Scalability. Tests the scalability of object-oriented transformations by applying them to a larger soft-ware systems.
The intellectual contribution of this work is to view the evolution of object-oriented software designs as aninteractive transformational process. Just as GUI prototyping tools allow developers to quickly alterscreens to meet user needs, an object-oriented transformation tool would allow designers to quickly altersoftware designs to meet the needs imposed on their software system. This research explores the viabilityof such a tool.
5 References
[And94] B. Anderson, “Patterns: Building Blocks for Object-Oriented Software Architectures”,Software
Engineering Notes, January 1994.
[Bat94] D. Batory, J. Thomas, and M. Sirkin, “Reengineering a Complex Application Using a Scalable
Data Structure Compiler”,ACM SIGSOFT, December 1994.
[Bax90] I. Baxter, “Design Maintenance Systems”,Communications of the ACM, 35(4), pages 73-89,
4.Program-preserving transformations preserve the correctness of the program but may alter individual objectswithin the program [Opd92].
5
3 Related Work
Our work is closely tied to developments in the design patterns community [Gam92, Joh92, And94,Gam94, Coa95]. Patterns are not exclusive to object-oriented software designs; they can also be found instructured software systems. Patterns may be domain-specific (e.g. patterns for implementing businesstransactions) or domain-independent (e.g. see Abstract Factory example in Section 4 of Appendix). Pat-terns may also vary based on the availability of language features. For example, some languages providefactory methods for creating new objects while others use a design pattern to achieve the same result. Thecurrent focus of design pattern research has been to catalog patterns [Gam94]. The design patterns ofGamma et. al. are the most relevant because they deal with domain-independent patterns discovered inlarge object-oriented software systems and all patterns can be expressed using C++ constructs.Our research uses design patterns as target states for transformations.
Our research is also related to work in program transformations. One focus of program transformationresearch is to transform abstract descriptions of a program into concrete implementations [Smi90, Bax90,Bat94, and many others]. The transformations for these systems tend to be domain-specific. Once thetransformations for a domain are developed, a developer in this domain can reuse the designs and code bycomposing transformations.
The system we propose transforms from one human readable concrete program to another human read-able concrete program. Programs are written in a standardized commercial object-oriented language(C++). The transformations we will examine are not tied to a domain because the design patternswhich they implement occur in a variety of domains (see Appendix for list of domain-independentdesign patterns).
Griswold developed a system for performing transformations on simple block-structured programs[Gri93]. The goal of this system was to assist in the restructuring of functionally decomposed software. Anexample transformation in this system isvariable-to-expression which replaces references to a vari-able with its defining expression. Most of Griswold’s transformations operate at the level of a function orwithin a block of code. For this reason, the ratio between lines of code affected and lines of transformationspecification may be low.
Our proposed transformation system will alter units of abstraction that are much larger than functions,i.e. classes and frameworks. This allows a user to experiment with different designs, not just differentfunction implementations. A number of transformations will require a significant degree of code analy-sis and would be error prone if performed by hand.
Bergstein defines a set of object-preserving class transformations that can be applied to class diagrams[Ber91]. Lieberherr implements these transformations in the Demeter object-oriented software environ-ment [Lie91]. Example transformations are deleting useless subclasses and moving instance variablesbetween a superclass and a subclass. Bergstein’s transformations preserve objects so they cannot add,delete, or move methods or instance variables exported by a class. They operate on Demeter notationwhich does not expose the source code for methods. Thus, design patterns such as Template Method,Object Adapter, and Strategy which affect method source code (see Appendix) are not supported3.Bergstein’s transformations are a useful subset of the transformations required to implement designpatterns. Our work will be program-preserving rather than object-preserving.4 This allows for trans-formations which move methods or instance variables between objects but preserve the correctness of
3.Transformations to support these patterns replace an algorithm with a call to a new method which contains thealgorithm.
4
Program PParser/Semantic AnalyzerUser-GuidedTransformationsAbstract Syntax TreeTransformerCode GeneratorO-O TransformationDatabaseProgram P’Figure 1: Transformation Process
6.Test scalability. Apply transformations to an old version of the software system. An attempt will bemade to retrace the class and framework evolution path of this system using automated transformationswhenever possible.(5 months.) The following issues can then be addressed:
•Completeness of DIP’s. What portion of the class and framework evolution could be handled by design
patterns? Do the systems under study suggest new design patterns?
•Completeness of OOT’s. To what degree was the evolution automated via program transformations? To
what degree could the evolution have been automated via program transformations?
•Practicality. Can object-oriented design changes be viewed as transformations on a class diagram? Is
this a useful methodology for dealing with software evolution?
•Degree of automation. What was the ratio between lines of code transformed and lines of code changed
manually?
Figure 2 provides a timetable for the steps to be completed.
521346Writing and defenseStart1 year2 yearsFigure 2: Timetable of events
3
Design patterns are applied manually. Small changes in the design phase often lead to large changes in theimplementation phase making experimentation with designs a costly but necessary step in the softwareengineering process. This proposal calls for the automation of design changes as program transformationswhich implement design patterns. Automating transformations which implement design patterns wouldlower the implementation cost of evolving systems and should substantially reduce the number of errorsintroduced during this phase. Users would have the freedom to focus on design level changes withoutattending to implementation level details.
2 Proposed Work
Software evolution is often driven by the need to extend existing software. Design patterns express pre-ferred ways to extend object-oriented software and provide desirable target states for software designs. TheAppendix (University of Texas, Department of Computer Sciences Technical Report 95-06) identifies acollection of design patterns which occur in evolving systems and demonstrates that these patterns can beexpressed as a series of parameterized program transformations applied to a plausible initial software state.A software tool is proposed which uses primitive transformations to evolve object-oriented applications.Continuation of this research will proceed in the following steps:
1.Perform domain analysis. Identify a list of domain independent patterns (DIP’s) which might occur inthe evolutionary phase of development. For each pattern, there should be some plausible initial soft-ware state which can be transformed to employ the pattern. A preliminary domain analysis of object-oriented design patterns has revealed sixteen patterns which may be supported through transformations(see Appendix).(1 month)2.Develop transformations. Develop a suite of object-oriented program transformations (OOT’s) whichcan be composed to map initial states to target states using DIP’s identified in Step 1. Transformationspreviously identified may require other arguments or may be decomposed into even more primitivetransformations. The goal will be to obtain the leanest possible set of transformations which providescoverage of the DIP’s. (2 months)3.Implement transformation system. Write a program transformation system which implements theOOT’s by automating the check for enabling conditions and carrying out all program changes. Theinput to the system will be a C++ program and a series of user-guided transformations to be applied.The program is parsed to produce an abstract syntax tree1. Transformations are then applied to the tree.The tree is then unparsed to produce a transformed C++ program. See Figure 1. (9 months)4.Test on small scale.Develop sample programs and apply OOT’s to implement DIP’s. (See Section 4 ofTechnical Report 95-04 for an example.) This will validate the transformation system for small pro-grams with clean software designs.(3 months)5.Identify large system. A software system will be identified to test the scalability of the ideas. Below is alist of required characteristics2(2 months to identify and obtain a large system):
•A rich class hierarchy (lots of inheritance, delegation, aggregation, etc.). Nouse of templates if possible
since none of Gamma’s design patterns use the template feature of C++.
•Architectures for multiple versions available with some significant changes to the class or framework
structure between versions.
1.The leading candidate for a C++ parser is Sage++ from Indiana University.
2.A candidate is the Conduits software for network protocols [Zwe90]. An evolved version of this software archi-tecture is described in [Hui95].
2
Program Transformations for Evolving Object-Oriented Software
Systems
Thesis Proposal
Lance Tokuda
Department of Computer SciencesThe University of Texas at Austin
Austin, Texas 78712unicron@cs.utexas.edu
Abstract
Developing good software designs takes a great deal of experience and experimentation.Design patterns capture the experience of object-oriented software architects by docu-menting preferred ways to extend and structure object-oriented software. What is neededis a facility for experimenting with different designs using design patterns.
Our preliminary research indicates that design patterns can be introduced in evolving soft-ware systems via automated program transformations. This proposal calls for the identifi-cation of design patterns used in program evolution and the development of a suite oftransformations which automate the use of these patterns. The result will be a tool for rap-idly evolving software designs which are more extensible and easier to reuse, while reduc-ing the number of errors introduced as software evolves. The Appendix (University ofTexas, Department of Computer Sciences Technical Report 95-06), describes this work infurther detail.
1 Introduction
Evolution and maintenance currently accounts for between 60% and 80% of the software budget for infor-mation systems organizations. Object-oriented design methodologies offer important opportunities forreducing maintenance costs. For example, object-oriented software is organized into classes and frame-works which provide modularity and enhance reusability. This, in turn, can substantially reduce the cost ofadding new functionality to a product. Language features such as inheritance also contribute to extensibil-ity and reuse by allowing specializations of a class to be built without altering the original class. Extensibleand reusable frameworks are not a guaranteed result of an object-oriented development style. Good frame-works are the result of extensiveexperience andexperimentation [Joh88].Two approaches for transferring object-oriented design experience have emerged. One method of transfer-ring design experience is through the statement of design rules [Roc86, Joh88, Lei88, LaL91]. Rules tendto identify bad design practices and suggest better alternatives. They provide a checklist which preventscertain bad designs from occurring. One problem with design rules is that there is often no rule which willhelp a user to solve a specific design problem. A more recent effort has been to catalogdesign patterns[Gam94]. Design patterns capture recurring patterns of classes and relationships in the designs of experi-enced object-oriented software architects. Many have been developed independently to achieve the samepurpose. Instead of creating a new design when confronted with an old problem, a user can now check thecatalog of known design patterns for an expert’s solution to a problem.
1
因篇幅问题不能全部显示，请点此查看更多更全内容