Todd Hansen—Softbank Net Solutions, USA
Steven Fraser —Northern Telecom, USA
Craig Hilsenrath—Greenwich Capital Markets, USA
Bill Opdyke—Lucent Technology, USA
Arthur Riel —Greenwich Capital Markets, USA
Frameworks are key components for achieving reuse of analysis, design and implementation in object-oriented technology. However, developing high-quality frameworks is a challenging task for most organizations. The purpose of this workshop was to help identify the key ingredients for developing, supporting, and maintaining successful frameworks.
The format of the workshop included an initial group introduction session. The goals of this session were to briefly introduce each participant and discuss individual expectations, experiences, views on successful framework characteristics, and areas of interest. Subsequently, the results of this session were summarized and participants split into groups to discuss the following topics:
This year’s workshop was comprised of many seasoned framework developers with expertise in domains as diverse as graphical user interfaces, telephony, real-time controls and testing. As in prior workshops, we were unable to completely agree on the definition of a framework. We did, however, add some new ideas to the definitions proposed at the OOPSLA 96 frameworks workshop.
Owing to time constraints, only a select group of framework development issues were addressed during the workshop. Other important issues were glossed over or omitted entirely. These are good candidate topics for future framework workshops.
Expectations & Issues
Participants expressed a personal interest in the following framework development issues:
Although there was no clear consensus, some new definitions of a framework were suggested. This definition has been controversial in past workshops, so no additional time was spent attempting to refine these statements.
Characteristics of Successful Frameworks
Successful frameworks exhibit the following characteristics:
Many of the framework development issues that were raised could be categorized as communication, technical, architecture, lifecycle, economics or organizational. Participants, in smaller working sessions, discussed these topics to varying degrees. A summary of these discussions is provided below:
How do you effectively communicate a framework to your customers? This encompasses issues such as documentation, usability, vocabulary, training and comprehensibility.
Typically, there are three types of framework users. The first, "user level one", are the application builders. This group of developers uses the framework "out of the box" and usually only require the highest level of architectural understanding (e.g. key domain objects). The documentation for these users should consist of the following items:
Training material for application builders should be conveyed via a "live" trainer and additional mentoring/consulting should be available. To ensure that the framework is used properly (i.e. in adherence to the frameworks basic principles), advanced users (e.g. level two or three developers) should participate in all application design/code reviews.
"User level two" represents the advanced framework users. These developers may modify the framework by extending or customizing key domain concepts. In addition to understanding the key domain abstractions, they require information on the framework hot-spots and some insight into the framework design (e.g. collaboration between components). Documentation for these users should include both a "hot-spots" cookbook with tutorial and a "limited" reference on how the framework works. Training for the level two user is identical to that of the application builder, but can be less formal and rigorous.
The framework developers, "user level three", should be the highest skilled developers. These developers need to understand both the domain abstractions and the detailed framework design. Complete design and implementation guides as well as a statement of the framework "vision" should be provided to these users. Instruction is the least formal at this stage, but both formal and informal domain training is necessary.
How do you determine which paradigms, languages, tools and technology to use when developing a framework?
Due to the inherit advantages (e.g. encapsulation, polymorphism) of the object-oriented paradigm, frameworks developed using object-oriented analysis and design techniques have better odds of success. However, implementation is a language issue based on primarily cost, legacy integration and skill set. If an organization is starting a new framework development project from scratch then the object-oriented paradigm should be used.
Coverage, regression, versioning and automation tools are as essential in framework development as they are in any other type of software development. But most mature frameworks are by-products of continuous refactoring. Therefore, tools and languages that assist in and directly support refactoring framework designs are important.
Frameworks should be developed using a common domain language. Standard architectural patterns should be used and clearly documented.
How are frameworks architected? How are patterns utilized in framework development? What practices should be avoided when developing a framework?
Is there a technique to accelerate the process of framework analysis and development? The current reality is that frameworks are developed in one of two ways:
Standard techniques and patterns, (both analysis and design), should be utilized in framework development. A strategic approach to analysis of domain/architecture can lead to effective frameworks. However, some techniques should be avoided:
The future vision for frameworks involves a standardization of taxonomy, development of methods and tools to support framework evolution, and reengineering of existing assets into frameworks and components.
How do successful frameworks evolve and mature?
Most successful frameworks require significant time and investment. They should evolve incrementally, maintain a shared vocabulary and a constant "vision". Premature generalization or shotgun marriages to applications are common in immature frameworks and should be avoided. Frameworks typically mature from "white-box" to "black-box" interfaces and experience constant consolidation and refactoring.
What are the economic factors influence framework development and adoption?
Frameworks do scale and can provide significant return on investment. But they should be considered a long-term investment. There are many economic issues that may influence framework development and adoption. Some of these issues include:
What is the ideal team structure for framework development? How can frameworks be protected against organizational pressures?
Frameworks should be developed by dedicated design teams that interface directly with application developers (ideally co-located). These framework teams should typically consist of the best and brightest developers in the corporation. Domain knowledge is important but good object-oriented analysis and design skills and pattern knowledge are essential for these developers.
Frameworks often fall prey to corporate cost cutting measures. Therefore, it is important for organizations to periodically determine and document how much development effort they have saved by adopting a specific framework. Additionally, framework groups need to routinely convince management that refactoring and framework maintenance is important to a framework’s longevity.
Frameworks need to be protected against loss of generality caused by the influence of a corporation’s flagship application. Often, a single successful corporate application (e.g. "the bread winner") can make unreasonable demands on a framework, thus forcing it in the wrong direction. This act will undoubtedly have an adverse effect on all other applications that rely on the framework.
John Artim Orient Overseas Container Lines Jartim@acm.org
Boris Bokowski Bokowski@inf.fu-berlin.de
Einar Dehli Computas As firstname.lastname@example.org
Paul Dyson email@example.com
Brian Foote Univ. Ill firstname.lastname@example.org
Steven Fraser Nortel Sdfraser@nortel.ca
Todd Hansen Softbank Net Solutions email@example.com
Craig Hilsenrath Greenwich Capital Markets Hilsenc@gcm.com
Lee Krause Software Productivity Solutions Lkrause@sps.com
Peter Long Rolfe & Nolan Systems firstname.lastname@example.org
Bill Opdyke Lucent Technologies/Bell Labs email@example.com
Arthur Riel Greenwich Capital Markets 72360.151@Compuserve.com
Mathew Schemenaur Perot Systems firstname.lastname@example.org
Michel Tilman Unisys Belgium Mtilman@argo.be
Tim Tjarks Lucent Technologies/Bell Labs Tjarks@lucent.com
Larry Williams ObjectTime Larryw@objecttime.com
Joe Yoder Univ. Ill email@example.com