- Shopping Bag ( 0 items )
Ships from: Chicago, IL
Usually ships in 1-2 business days
Ships from: Chatham, NJ
Usually ships in 1-2 business days
Ships from: acton, MA
Usually ships in 1-2 business days
"...provides guidelines for constructing a successful application framework...topics include leveraging existing design & code investment, tracking & controlling framework development, and measuring & evolving framework quality."
Application Frameworks (M. Fayad, et al. ).
Framework and Patterns: Architectural Abstractions (E. Jacobson & P. Nowack).
Frameworks Problems and Experiences (J. Bosch, et al. ).
FRAMEWORK PERSPECTIVES (M. Fayad).
Simula Frameworks: The Early Experience (J. Vaucher & B. Magnusson).
Visual Builders: Framework Design Issues (A. Jolin, et al. ).
Usability and Framework Design (A. Jolin).
FRAMEWORKS AND DOMAIN ANALYSIS (M. Fayad).
Deriving Frameworks from Domain Knowledge (M. Aksit, et al. ).
Harvesting Design (J. Boone).
FRAMEWORK DEVELOPMENT CONCEPTS (M. Fayad).
Reusing Hooks (G. Froehlich, et al. ).
A Framework Recipe (S. Jones).
Capturing Hypermedia Functionality (A. Garrido & G. Rossi).
Understanding Frameworks (N. Soundarajan).
Capturing Framework Requirements (G. Miller, et al. ).
Managing Class Dependencies (A. R?ping).
FRAMEWORK DEVELOPMENT APPROACHES (M. Fayad).
Framework Design by Systematic Generalization (H. Schmid).
Hot-Spot-Driven Development (W. Pree).
Structuring Large Application Frameworks (D. B?umer, et al. ).
Understanding Macroscopic Behavior Patterns with Use-Case Maps (R. Buhr).
Composing Modeling Frameworks in Catalysis (D. D'Souza & A. Wills).
FRAMEWORK TESTING AND INTEGRATION (M. Fayad).
Composition Problems, Causes, and Solutions (M. Mattsson & J. Bosch).
FRAMEWORK DOCUMENTATION (M. Fayad).
Documenting Frameworks (G. Butler & P. D?nomm?e).
Empowering Framework Users (J. Eckstein).
Describing and Using Frameworks (H. Mili & H. Sahraoui).
FRAMEWORK MANAGEMENT AND ECONOMICS (M. Fayad).
Strategic Analysis of Application Framework Investments (J. Favaro & K. Favaro).
Evaluting Structural and Functional Stability (J. Bansiya).
Future Trends (M. Fayad).
Object-oriented application frameworks are a very important issue for the software industry as well as academia at this time when software systems are becoming increasingly complex. We believe that object-oriented application frameworks will be at the core of leading-edge software technology of the twenty-first century. This part provides a complete overview of the application frameworks and other component-based reuse approaches. Part One is made up of three chapters and a sidebar.
Reuse of software has been one of the main goals of software engineering for decades. Reusing software is not simple, and most efforts resulted in small reusable, blackbox components. With the emergence of the object-oriented paradigm, the enabling technology for reuse of larger components became available and resulted in the definition of object-oriented application frameworks. Frameworks attracted attention from many researchers and software engineers, and frameworks have been defined for a large variety of domains. The claimed advantages of frameworks include increased reusability and reduced time to market for applications. Chapter 1 is an introduction and provides complete coverage of application framework issues. Chapter 1 defines application frameworks, provides several classifications of application frameworks, describes the characteristics of application frameworks, discusses the pros and cons of application frameworks, and contrasts the frameworks with other reuse approaches.
Chapter 2 elaborates on the understanding of the term software architecture by further developing the concept of architectural abstractions. The principal contributions are a conceptual model of architectural abstractions, an analysis of current pattern approaches, current framework understanding, and a new perspective on both patterns and frameworks as being examples of architectural abstractions. The technical innovation is a characterization of the concept of architectural abstraction in terms of structural characteristics, functionality, abstraction, and reuse.
Chapter 3 discusses the application framework problems based on the authors' experiences. The authors have been involved in the development and the utilization of several object-oriented application frameworks and based on the experiences from these projects, a number of problems related to frameworks are described. The problems are organized according to five categories: framework development, learning, usage, composition, and maintenance. For each category, the most relevant problems and experiences are presented. The goal of this chapter is to help software engineers avoid the described problems and to suggest topics for future research.
Sidebar 1 introduces the object-oriented enterprise frameworks (OOEFs). A new way of developing, deploying, extending, and administering enterprise systems is emerging. These systems either are developed as in-house solutions by organizations that were not satisfied with commercially available options for managing the enterprise or were procured from a small but growing population of enterprise framework vendors. OOEFs should not be confused with middleware and standards for distributed objects (such as Common Object Request Broker Architecture (CORBA) or Distributed Common Object Model (DCOM)). Interoperability represents but a single characteristic of an OOEF. Furthermore, OOEF components may be implemented as vertical CORBA facilities, but this definition alone does not satisfy the requirements of an OOEF either. OOEFs are an emerging discipline of developers and development teams that address reuse in a radical way. OOEFs allow distributed applications to be deployed rapidly with very little coding because applications leverage the framework and the enduring business processes and enduring business themes that are encoded into the framework itself.
Computing power and network bandwidth have increased dramatically over the past decade. However, the design and implementation of complex software remain expensive and error-prone. Much of the cost and effort stem from the continuous rediscovery and reinvention of core concepts and components across the software industry. In particular, the growing heterogeneity of hardware architectures and diversity of operating system and communication platforms make it hard to build correct, portable, efficient, and inexpensive applications from scratch.
Frameworks are an object-oriented reuse technique. They share a lot of characteristics with reuse techniques in general and object-oriented reuse techniques in particular. Although they have been used successfully for some time and are an important part of the culture of long-time object-oriented developers, most framework development projects are failures, and most object-oriented methodologies do not describe how to use frameworks. Moreover, there is a lot of confusion about whether frameworks are just large-scale patterns, or whether they are just another kind of component.
Even the definition of framework varies. A frequently used definition is "a framework is a reusable design of all or part of a system that is represented by a set of abstract classes and the way their instances interact." Another common definition is "a framework is the skeleton of an application that can be customized by an application developer." These are not conflicting definitions; the first describes the structure of a framework while the second describes its purpose. Nevertheless, they point out the difficulty of defining frameworks clearly.
Frameworks are important and are becoming more important. Systems like Object Linking and Embedding (OLE), OpenDoc, and Distributed System Object Model (DSOM) are frameworks. The rise of Java is spreading new frameworks like Abstract Window Toolkit (AWT), which is part of the Java Foundation Classes (JFC) and Beans. Most commercially available frameworks seem to be for technical domains such as user interfaces or distribution, and most application-specific frameworks are proprietary. But the steady rise of frameworks means that every software developer should know what they are and how to deal with them.
This chapter compares and contrasts frameworks with other reuse techniques and describes how to use them, how to evaluate them, and how to develop them. It describes the trade-offs involved in using frameworks, including the costs and pitfalls, and when frameworks are appropriate.
1.1 What Is an Application Framework?
Object-oriented (OO) application frameworks are a promising technology for reifying proven software designs and implementations in order to reduce the cost and improve the quality of software. A framework is a reusable, semi-complete application that can be specialized to produce custom applications [ Johnson-Foote 1988]. In contrast to earlier OO reuse techniques based on class libraries, frameworks are targeted for particular business units (such as data processing or cellular communications) and application domains (such as user interfaces or real-time avionics). Frameworks like MacApp, ET++, Interviews, Advanced Computing Environment (ACE), Microsoft Foundation Classes (MFCs) and Microsoft's Distributed Common Object Model (DCOM), Java-Soft's Remote Method Invocation (RMI), and implementations of the Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA) play an increasingly important role in contemporary software development.
A framework is a reusable design of a system that describes how the system is decomposed into a set of interacting objects. Sometimes the system is an entire application; sometimes it is just a subsystem. The framework describes both the component objects and how these objects interact. It describes the interface of each object and the flow of control between them. It describes how the system's responsibilities are mapped onto its objects [Johnson-Foote 1988; Wirfs-Brock 1990].
The most important part of a framework is the way that a system is divided into its components [Deutsch 1989]. Frameworks also reuse implementation, but that is less important than reuse of the internal interfaces of a system and the way that its functions are divided among its components. This high-level design is the main intellectual content of software, and frameworks are a way to reuse it.
Typically, a framework is implemented with an object-oriented language like C++, Smalltalk, or Eiffel. Each object in the framework is described by an abstract class. An abstract class is a class with no instances, so it is used only as a superclass [Wirfs-Brock 1990]. An abstract class usually has at least one unimplemented operation deferred to its subclasses. Since an abstract class has no instances, it is used as a template for creating subclasses rather than as a template for creating objects. Frameworks use them as designs of their components because they both define the interface of the components and provide a skeleton that can be extended to implement the components.
Some of the more recent object-oriented systems, such as Java, the Common Object Model (COM), and CORBA, separate interfaces from classes. In these systems, a framework can be described in terms of interfaces. However, these systems can specify only the static aspects of an interface, but a framework is also the collaborative model or pattern of object interaction. Consequently, it is common for Java frameworks to have both an interface and an abstract class defined for a component.
In addition to providing an interface, an abstract class provides part of the implementation of its subclasses. For example, a template method defines the skeleton of an algorithm in an abstract class, deferring some of the steps to subclasses [Gamma 1995]. Each step is defined as a separate method that can be redefined by a subclass, so a sub-class can redefine individual steps of the algorithm without changing its structure. The abstract class can either leave the individual steps unimplemented (in other words, they are abstract methods) or provide a default implementation (in other words, they are hook methods) [Pree 1995]. A concrete class must implement all the abstract methods of its abstract superclass and may implement any of the hook methods. It will then be able to use all the methods it inherits from its abstract superclass.
Frameworks take advantage of all three of the distinguishing characteristics of object-oriented programming languages: data abstraction, polymorphism, and inheritance. Like an abstract data type, an abstract class represents an interface behind which implementations can change. Polymorphism is the ability for a single variable or procedure parameter to take on values of several types. Object-oriented polymorphism lets a developer mix and match components, lets an object change its collaborators at run-time, and makes it possible to build generic objects that can work with a wide range of components. Inheritance makes it easy to make a new component.
A framework describes the architecture of an object-oriented system; the kinds of objects in it, and how they interact. It describes how a particular kind of program, such as a user interface or network communication software, is decomposed into objects. It is represented by a set of classes (usually abstract), one for each kind of object, but the interaction patterns between objects are just as much a part of the framework as the classes.
One of the characteristics of frameworks is inversion of control. Traditionally, a developer reused components from a library by writing a main program that called the components whenever necessary. The developer decided when to call the components and was responsible for the overall structure and flow of control of the program. In a framework, the main program is reused, and the developer decides what is plugged into it and might even make some new components that are plugged in. The developer's code gets called by the framework code. The framework determines the overall structure and flow of control of the program.
The first widely used framework, developed in the late 1970s, was the Smalltalk-80 user interface framework called Model/ View/ Controller (MVC) [Goldberg 1984; Krasner 1988; LaLonde 1991]. MVC showed that object-oriented programming was well suited for implementing graphical user interfaces (GUIs). It divides a user interface into three kinds of components: models, views, and controllers. These objects work in trios consisting of a view and a controller interacting with a model. Amodel is an application object and is supposed to be independent of the user interface. A view manages a region of the display and keeps it consistent with the state of the model. A controller converts user events (mouse movements and key presses) into operations on its model and view. For example, controllers implement scrolling and menus. Views can be nested to form complex user interfaces. Nested views are called subviews.
Figure 1.1 shows the user interface of one of the standard tools in the Smalltalk-80 environment, the file tool. The file tool has three subviews. The top subview holds a string that is a pattern that matches a set of files, the middle subview displays the list of files that match the pattern, and the bottom subview displays the selected file. All three subviews have the same model-- a FileBrowser. The top and bottom subviews are instances of TextView, while the middle subview is an instance of SelectionIn-ListView. As shown by Figure 1.2, all three views are subviews of a Standard-SystemView. Each of the four views has its own controller.
Class View is an abstract class with base operations for creating and accessing the subview hierarchy, transforming from view coordinates to screen coordinates, and keeping track of its region on the display. It has abstract and template operations for displaying, since different kinds of views require different display algorithms. TextView, SelectionInListView, and StandardSystemView are concrete subclasses of View, each of which has a unique display algorithm.
As a user moves the mouse from one subview to another, controllers are activated and deactivated so that the active controller is always the controller of the view managing the region of the display that contains the cursor. Class Controller implements the protocol that ensures this, so a subclass of Controller automatically inherits the ability to cooperate with other controllers.
Class Object provides a dependency mechanism that views can use to detect when the model's state changes. Thus, any object can be a model. There is also a Model class that provides a faster version of the dependency mechanism at the cost of an extra variable [ParcPlace 1988].
The file tool is a typical Model/ View/ Controller application that does not need new subclasses of View or Controller. Its user interface consists entirely of objects from classes that are a standard part of the Smalltalk-80 class library. The Smalltalk-80 class library contains several dozen concrete subclasses of View and Controller. However, when these are not sufficient, new subclasses can be built to extend the user interface.
Successful frameworks evolve and spawn other frameworks. One of the first user interface frameworks influenced by Model/ View/ Controller was MacApp, which was designed specifically for implementing Macintosh applications [Schmucker 1986]. It was followed by user interface frameworks from universities, such as the Andrew Toolkit from Carnegie Mellon University [Palay 1988], InterViews from Stanford [Linton 1989], and ET++ from the University of Zurich [Weinand 1988, 1989]. There are now a large number of commercial user interface frameworks, such as zAPP, Open-Step, and MFCs. Some, like OpenStep's, are a small part of a much more comprehensive system. Some, like zAPP, are designed for developing portable software and shield the developer from the peculiarities of an operating system. Each of these frameworks borrows ideas from earlier systems. Although the differences between the frameworks are due partly to different requirements, sometimes newer systems incorporate better design techniques, and so the state of the art gradually improves.
Frameworks are not limited to user interfaces, but can be applied to any area of software design. They have been applied to very large scale integration (VLSI) routing algorithms [Gossain 1990], to hypermedia systems [Meyrowitz 1986], to structured drawing editors [Beck 1994; Vlissides 1989], to operating systems [Russo 1990], to psychophysiological experiments [Foote 1988], to network protocol software [Hueni 1995], and to manufacturing control [Schmid 1995], to mention a few.
Frameworks do not even require an object-oriented programming language. For example, the Genesis database system compiler is a framework for database management systems (DBMSs) [Batory 1989] as well as a tool for specifying how DBMSs are built from the framework. Genesis does not use an object-oriented language but rather a macroprocessor and conditional compilation to implement an object-oriented design in C.
The important classes in a framework, such as Model, View, and Controller of Model/ View/ Controller, are usually abstract. Like MVC, a framework usually comes with a component library that contains concrete subclasses of the classes in the framework. Although a good component library is a crucial companion to a framework, the essence of a framework is not the component library, but the model of interaction and control flow among its objects.
A framework reuses code because it makes it easy to build an application from a library of existing components. These components can be easily used with each other because they all use the interfaces of the framework. A framework also reuses code because a new component can inherit most of its implementation from an abstract superclass. But reuse is best when you don't have to understand the component you are reusing, and inheritance requires a deeper understanding of a class that is using it as a component, so it is better to reuse existing components than to make a new one.
Of course, the main reason a framework enables code reuse is that it is a reusable design. It provides reusable abstract algorithms and a high-level design that decomposes a large system into smaller components and describes the internal interfaces between components. These standard interfaces make it possible to mix and match components and to build a wide variety of systems from a small number of existing components. New components that meet these interfaces will fit into the framework, so component designers also reuse the design of a framework.
Finally, a framework reuses analysis. It describes the kinds of objects that are important and provides a vocabulary for talking about a problem. An expert in a particular framework sees the world in terms of the framework and will naturally divide it into the same components. Two expert users of the same framework will find it easier to understand each other's designs, since they will come up with similar components and will describe the systems they want to build in similar ways.
Analysis, design, and code reuse are all important, though in the long run it is probably the analysis and design reuse that provide the biggest payoff [Biggerstaff 1996].
The primary benefits of OO application frameworks stem from the modularity, reusability, extensibility, and inversion of control they provide to developers, as described in the following:
Modularity. Frameworks enhance modularity by encapsulating volatile implementation details behind stable interfaces. Framework modularity helps improve software quality by localizing the impact of design and implementati
Posted June 21, 2001
An almost indispensable 3-volume reading to understand the success of framework technologies in today´s software systems. The books include most of the top articles on the subject, providing a thorough insight in both design and implementation issues regarding frameworks, also complemented with practical experience about framework usage. Although the work is mainly concentrated on technical aspects, the articles are comprehensible enough to be taken as reference material by a broad community, for example, software engineers, programmers, or technology managers. The books are useful for anybody planning to include framework-based techniques in software development processes or planning to improve current object-oriented practices. It is also an excellent source for graduate courses. Volume 1 lays the fundamental concepts supporting object-oriented frameworks, and describes the problems and challenges that this technology raises in software development. The book covers topics such as domain analysis, development concepts and approaches, documentation, and management, among others. Of course, the compilation of articles makes some parts little redundant, but this is a minor detail compared with the fruitful contributions made by the book. In particular, the articles on reusing hooks, hot-spot-driven development, composing modeling frameworks in Catalysis, and composition problems, causes and solutions, are a sample of the outstanding level of this work. Each chapter adds at the end a number of related questions and student projects aiming to reinforce concepts and promote further investigation. As a comment, novice readers should take the sections concerning hooks and hot-spots carefully because these topics are presented in a slightly confusing way. Volume 2 focuses on specific framework implementations, dealing with existing frameworks for different application domains, such as businesses, multi-agent systems, languages and system software. In this book, the readers will find a level of detail much closer to specific implementations issues than in the previous volume. Nonetheless, the writing style remains mostly clear and accessible for a quite broad audience. The case-studies and experience reports described by the articles show an attractive industrial perspective of the framework approach, and more important, they go an step forward in the road of a more mature discipline for software development. In addition, a CD-Rom with concrete examples of these applications is included with the book. Volume 3 completes this series with a number of domain-specific application frameworks developed by industry, showing how to apply the concepts and ideas of the previous books in software products. In this line, it includes very interesting frameworks for manufacturing systems and distributed systems, among others. It also goes through concrete software scenarios, illustrating the benefits of combining domain knowledge and object-orientation expertise. Although the level of the articles is rather odd, the volume certainly provides the readers a realistic picture of the problems of building and adapting frameworks by learning from others´ experience. A CD-Rom is also included with this book. Overall, these framework books collect the state-of-the-art on framework development, offering a comprehensive and easy-to-understand guide for both academics and practitioners in the field. It is clear that framework technologies will not solve all the problems (perhaps they rise more challenges than current approaches), however, taking advantage of the framework possibilities can make your development process more repeatable, productive, and also less painful. The gains of this retrain are no doubt a good investment.Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.
Posted January 6, 2000
This three volumes set distils the experience of a number of software practitioners, project managers, application engineers, researchers, and academics in dealing with framework-based software development. It offers a comprehensive and accessible treatment of the theory and practice of building and using application frameworks. The three volumes address the needs both of the business and of the research. They suggest practical solutions to recurrent development problems and point out hot research topics. In particular, Volume 1 'Building Application Frameworks' highlights the difficulties and draws the path towards the successful development of effective application frameworks. Each chapter has a final section with review questions and project proposals, which helps teachers and students to better assess the mastery of new concepts. Volume 2 'Implementing Application Frameworks' comprises a number of case studies that exemplify how to develop complex frameworks by exploiting the synergy of advanced techniques and methodologies, such as design patterns, architectural styles, software components, multi-agent systems, and more. Volume 3 'Domain-Specific Application Frameworks' emphasises the best practice in software development and reuse for a variety of application domains. Volumes 2 and 3 include two CD-ROMs with case studies, sample models, framework code, and demos.Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.
Posted December 12, 1999
I would like to congratulate the authors of three volumes on Building, Implementing and Domain specific application frameworks on an extremely well done job. I found the three volumes to be an invaluable and comprehensive source on application frameworks. These volumes cover all aspects pertaining to frameworks including models of development, key technical and business issues surrounding building of frameworks, experiences, lessons learned and successful practices to mention a few. In my opinion the three volumes are a must read for any software engineer who has been using or developing frameworks and as essential for software designers who want to be introduced and train in this area. The building volume is in particular attractive as a textbook for an advanced course on application frameworks.Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.