Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Additional Reusable Components
This material was covered during lectures on March 21, 1997.
The book of Gamma et al contains a small amount of material about other reusable-components that can be used for object-oriented design:
E. Gamma, R. Helm, R. Johnson, J. Vlissides
Design Patterns: Elements of Reusable Object-Oriented Software
Addison-Wesley, 1995
The following book has recently appeared, and is the reference for some of the material included at the end of these notes.
G. Rogers
Framework-Based Software Development in C++
Prentice-Hall, 1997
A Toolkit is a set of related or reusable classes designed to produce useful, general purpose functionality.
The C++ I/O Stream Library is an example of a toolkit.
Toolkits don't impose a particular design on the application, but provide ``functionality'' that can help your application do its job.
On the other hand, a Framework is a set of cooperating classes that make up a reusable design for a specific class of software. A framework is generally given as a class library that includes both concrete and abstract classes, explicitly designed to be used together.
The framework definitely does dictate the architecture of the application tha uses it.
Rogers (cited above) describes two ``broad classes'' of frameworks.
In particular, he defines ``horizontal frameworks'' to be very general frameworks that can be used in a broad range of applications, and gives a ``Graphical User Interface Toolkit'' as an example of a horizontal framework.
Rogers defines ``vertical frameworks'' to be frameworks that are specifically intended for a particular application domain, and that thereforw won't be as widely used.
It seems that Rogers might be using the term ``framework'' to define a broader set of ``libraries of reusable classes'' than other references. In particular, some of the ``horizontal frameworks'' that he includes in examples seem to be toolkits (as other references define them), rather than frameworks.
The following is a reproduction of Figure 1-2 on page 9 of Rogers' book, and it is intended to illustrate how frameworks (and toolkits) might be used to design an object-oriented system:
This shows the use of a vertical framework (or, perhaps, ``framework'' in the terminology of other references) and four horizontal frameworks (or, possibly, three frameworks and a ``toolkit''): The ``Auto Dealership Framework'' is a (vertical) framework that contributes abstract and concrete classes that will probably be useful for almost any ``Auto Dealership'' system. In order to use a framework, you generally need to provide concrete classes corresponding to some of the abstract classes that the framework includes. In this example, some of these concrete classes are obtained by using three other more ``horizontal'' frameworks - for ``Payroll,'' ``Accounting,'' and ``Inventory'' subsystems. Another horizontal framework (possibly a ``toolkit'' in this case) - a ``Graphical User Interface'' toolkit - provides another set of concrete classes for the windows, menus, etc. that the system will used. Finally, a (relatively) small number of classes need to be written to combine everything together.
The ``Graphical User Interface'' toolkit should not be written - it should be ``bought off the shelf'' if one isn't already available. The other frameworks and toolkits might be available for purchase, or they might be libraries that a developer creates on his or her own and refines (and uses) over time, when working on several similar systems.
Here are some notable differences between design patterns and frameworks that are mentioned by Gamma, et al (which might help you to decide which is which).
It might be useful to review the example of a design pattern and the example involving frameworks and toolkits given above, before (or after) considering these points.
Object-oriented development is attractive (or necessary) in part because (significant parts of) new systems are more complex than systems that were developed in the past. It's no longer really feasible, for example, for a modern system's human computer interface to be developed ``from scratch.'' As well, the demand for new systems, and for old systems to be maintained, is high enough so that improved software reuse is seen as necessary in order to meet it.
The emergence of toolkits, patterns, and frameworks is evidence that object-oriented development really might facilitate software reuse, as its proponents have hoped.
Patterns and frameworks also provide a way for experienced developers to convey additional information to less experienced developers in a useful way: After learning to read, select, and use patterns and frameworks, an inexperienced developer can use the patterns and frameworks that more experienced developers have developed in the past.
In order for object-oriented development to continue to be useful (and, perhaps, for it to have the advantages that its proponents have already claimed), it will be necessary for additional patterns and frameworks to be developed.
This is, for the most part, beyond the scope of Computer Science 333, and the specification and design methods described so far in this course aren't adequate for it, because they tend to concentrate on a single application that is to be developed. In order to develop useful toolkits, patterns, and frameworks, it is necessary to study a collection of (related) systems, and to try to ``abstract out'' the common features that will be useful and that should be included in a toolkit, pattern, or framework that one hopes will be useful for the development of new systems that resemble them.
Gamma, et al provide a template that can be used to write down new patterns, but don't appear to say very much about how you go about finding them.
On the other hand, Rogers does describe a method that might be used for the development of new frameworks. This includes a description of domain analysis, and how it can be used to study related systems in order to create a framework, as well as a catalogue of design patterns to be used for framework development, a set of ``design rules'' that ``document sensible ways that the C++ language should be used,'' and a description of design metrics and development procedures that are intended to help you apply the method and patterns to create a pattern, and then assess and improve it.
Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Additional Reusable Components