Design Patterns in Object-Oriented Computing Practices Frameworks Object-oriented frameworks provide an important enabling technology for reusing software components. In the context of speech-recognition applications, the author describes the benefits of an object-oriented framework rich with design patterns that provide a natural way to model complex concepts and capture system relationships. Savitha eveloping interactive software systems Srinivasan with complex user interfaces has IBM become increasingly common, with prototypes often used for demonstrat- ing innovations. Given this trend, it is Dimportant that new technology be based on flexible architectures that do not require developers to under- stand all the complexities inherent in a system. Object-oriented frameworks provide an important enabling technology for reusing both the architecture and the functionality of software components. But frameworks typically have a steep learning curve since the user must understand the abstract design of the underlying framework as well as the object collabo- ture of abstract and concrete classes. The abstract ration rules or contracts—which are often not appar- classes usually reside in the framework, while the con- ent in the framework interface—prior to using the crete classes reside in the application. A framework, framework. then, is a semicomplete application that contains cer- In this article, I describe our experience with devel- tain fixed aspects common to all applications in the oping an object-oriented framework for speech recog- problem domain, along with certain variable aspects nition applications that use IBM’s ViaVoice speech unique to each application generated from it. recognition technology. I also describe the benefits of The variable aspects, called hot spots, define those an object-oriented paradigm rich with design patterns aspects of an application that must be kept flexible for that provide a natural way to model complex concepts different adaptations of the framework.1 What differ- and capture system relationships. entiates one framework application from another in a common problem domain is the manner in which these OBJECT-ORIENTED FRAMEWORKS hot spots are defined. Frameworks are particularly important for devel- Despite the problem domain expertise and reuse oping open systems, where both functionality and offered by framework-based development, application architecture must be reused across a family of related design based on frameworks continues to be a difficult applications. An object-oriented framework is a set of endeavor. The framework user must understand the collaborating object classes that embody an abstract complex class hierarchies and object collaborations design to provide solutions for a family of related embodied in the framework to use the framework effec- problems. The framework typically consists of a mix- tively. Moreover, frameworks are particularly hard to 24 Computer 0018-9162/99/$10.00 © 1999 IEEE . document since they represent a reusable design at a that governhow objects can be combined to Documenting a high level of abstraction implemented by the frame- achieve certain behaviors.4 work classes. However, frameworks don’t enforce con- framework as a set But design patterns—recurring solutions to known tracts; if an application does not obey the con- of design patterns problems—can be very helpful in alleviating software tracts, it does not comply with the intended is an effective complexity in the domain analysis, design, and main- framework design and will very likely behave means of achieving tenance phases of development. Framework designs incorrectly. To make these relationships more can be discussed in terms of design pattern concepts, clear, a number of researchers have introduced a high level of such as participants, applicability, consequences, and the concept of motifsto document the purpose communication trade-offs, before examining specific classes, objects, and use of the framework in light of the role of between the and methods. design patterns and contracts.5,6 Documenting a framework—on paper or in the framework designer code itself—as a set of design patterns is an effective A FRAMEWORK FOR SPEECH RECOGNITION and the framework means of achieving a high level of communication We designed a framework for speech recog- user. between the framework designer and the framework nition applications intended to enable rapid user.2 Using design patterns helped us establish a com- integration of speech recognition technology in mon terminology with which we could discuss the applications using IBM’s ViaVoice speech recog- design and use of the framework. nition technology (http://www.software.ibm.com/ speech/). Our primary objective was to simplify the DESIGN PATTERNS development of speech applications by hiding com- Design patterns are descriptions of communicating plexities associated with speech recognition technol- objects and classes that are customized to solve a gen- ogy and exposing the necessary variability in the eral design problem in a particular context.2 By their problem domain so the framework user may cus- very definition, design patterns result in reusable tomize the framework as needed. object-oriented design because they name, abstract, We focused on the abstractions necessary to identify and identify key aspects of a common design structure. reusable components and on the variations necessary Design patterns fall into two groups. The first group to provide the customizations required by a user to focuses on object-oriented design and programming create a specific application. While this method or object-oriented modeling, while the second group— adheres to the classical definition of what a framework a more recent trend—focuses on patterns that address must provide, we consciously incorporated feedback problems in efficient, reliable, scalable, concurrent, into the framework evolution process. parallel, and distributed programming.3 In this article, I focus primarily on the first group, although my col- Speech concepts and complexities leagues and I used patterns from both categories to At a simplistic level, the difference between two address our design problems. speech recognition applications boils down to what In designing speech-recognition applications, we specific words or phrases you say to the application used patterns to guide the creation of abstractions nec- and how the application interprets what you say. essary to accommodate future changes and yet main- What an application understands is of course deter- tain architectural integrity. These abstractions help mined by what it is listening for—or its active vocab- decouple the major components of the system so that ulary. Constraining the size of the active vocabulary each may vary independently, thereby making the leads to higher recognition accuracy, so applications framework more resilient. typically change their active vocabulary with a change In the implementation stages, the patterns helped in context. us achieve reuse by favoring object composition or The result that the speech recognition engine returns delegation over class inheritance, decoupling the user in response to a user’s utterance is a recognized word. interface from the computational component of an In the context of a GUI application, the active vocab- application, and programming to an interface as ulary and the recognized words may be different for opposed to an implementation. each window and may vary within a window, depend- In the maintenance phases, patterns helped us doc- ing on the state of the application. ument strategic properties of the software at a higher Several factors contribute to complexity in devel- level than the source code. oping speech recognition applications. Recognition technology is inherently asynchronous and requires Contracts adhering to a well-defined handshaking protocol. Design patterns describe frameworks at a very high Furthermore, the asynchronous nature of speech level of abstraction. Contracts, on the other hand, can recognition makes it possible for the user to initiate be introduced as explicit notation to specify the rules an action during an application-level task so that the February 1999 25 . Recognized word Engine status I extensi U on eled the common aspects of the problem domain by G Speech abstract classes in the core framework; the applica- recognition Core tion implements concrete classes derived from the engine framework abstract classes. The class diagrams in the following sections describe the extensions to the core framework for IBM’s VisualAge GUI class library. We use the prefix “I” as a naming convention for Vocabulary Sp n the GUI extension classes. For example, the class ee tio Recognition definition ch applica ISpeechClient refers to the GUI framework extension session class that provides the core SpeechClient class func- tionality. We use the Unified Modeling Language (UML)7 notation generated by Rational Rose to rep- resent the class diagrams. Figure 1. The speech application must either disallow or defer any action Framework collaborations recognition engine until all previous speech engine processing can be com- and speech applica- pleted. The class diagram shown in Figure 2 shows the tion are separate Also, speech-programming interfaces typically eventual interface classes for the VisualAge extension processes. The first require a series of calls to accomplish a single appli- to the core framework classes. (The framework layer, the core frame- cation-level task. And