0018-9162/99/$10.00 © 1999 IEEE24 Computer

Com

putin

g Pr

actic

es

Design Patterns inObject-OrientedFrameworks

Developing interactive software systemswith complex user interfaces hasbecome increasingly common, withprototypes often used for demonstrat-ing innovations. Given this trend, it is

important that new technology be based on flexiblearchitectures that do not require developers to under-stand all the complexities inherent in a system.

Object-oriented frameworks provide an importantenabling technology for reusing both the architectureand the functionality of software components. Butframeworks typically have a steep learning curve sincethe user must understand the abstract design of theunderlying framework as well as the object collabo-ration rules or contracts—which are often not appar-ent in the framework interface—prior to using theframework.

In this article, I describe our experience with devel-oping an object-oriented framework for speech recog-nition applications that use IBM’s ViaVoice speechrecognition technology. I also describe the benefits ofan object-oriented paradigm rich with design patternsthat provide a natural way to model complex conceptsand capture system relationships.

OBJECT-ORIENTED FRAMEWORKSFrameworks are particularly important for devel-

oping open systems, where both functionality andarchitecture must be reused across a family of relatedapplications. An object-oriented framework is a set ofcollaborating object classes that embody an abstractdesign to provide solutions for a family of relatedproblems. The framework typically consists of a mix-

ture of abstract and concrete classes. The abstractclasses usually reside in the framework, while the con-crete classes reside in the application. A framework,then, is a semicomplete application that contains cer-tain fixed aspects common to all applications in theproblem domain, along with certain variable aspectsunique to each application generated from it.

The variable aspects, called hot spots, define thoseaspects of an application that must be kept flexible fordifferent adaptations of the framework.1 What differ-entiates one framework application from another in acommon problem domain is the manner in which thesehot spots are defined.

Despite the problem domain expertise and reuseoffered by framework-based development, applicationdesign based on frameworks continues to be a difficultendeavor. The framework user must understand thecomplex class hierarchies and object collaborationsembodied in the framework to use the framework effec-tively. Moreover, frameworks are particularly hard to

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 SrinivasanIBM

.

document since they represent a reusable design at ahigh level of abstraction implemented by the frame-work classes.

But design patterns—recurring solutions to knownproblems—can be very helpful in alleviating softwarecomplexity in the domain analysis, design, and main-tenance phases of development. Framework designscan be discussed in terms of design pattern concepts,such as participants, applicability, consequences, andtrade-offs, before examining specific classes, objects,and methods.

Documenting a framework—on paper or in thecode itself—as a set of design patterns is an effectivemeans of achieving a high level of communicationbetween the framework designer and the frameworkuser.2 Using design patterns helped us establish a com-mon terminology with which we could discuss thedesign and use of the framework.

DESIGN PATTERNSDesign patterns are descriptions of communicating

objects and classes that are customized to solve a gen-eral design problem in a particular context.2 By theirvery definition, design patterns result in reusableobject-oriented design because they name, abstract,and identify key aspects of a common design structure.

Design patterns fall into two groups. The first groupfocuses on object-oriented design and programmingor object-oriented modeling, while the second group—a more recent trend—focuses on patterns that addressproblems in efficient, reliable, scalable, concurrent,parallel, and distributed programming.3 In this article,I focus primarily on the first group, although my col-leagues and I used patterns from both categories toaddress our design problems.

In designing speech-recognition applications, weused patterns to guide the creation of abstractions nec-essary to accommodate future changes and yet main-tain architectural integrity. These abstractions helpdecouple the major components of the system so thateach may vary independently, thereby making theframework more resilient.

In the implementation stages, the patterns helpedus achieve reuse by favoring object composition ordelegation over class inheritance, decoupling the userinterface from the computational component of anapplication, and programming to an interface asopposed to an implementation.

In the maintenance phases, patterns helped us doc-ument strategic properties of the software at a higherlevel than the source code.

ContractsDesign patterns describe frameworks at a very high

level of abstraction. Contracts, on the other hand, canbe introduced as explicit notation to specify the rules

that govern how objects can be combined toachieve certain behaviors.4

However, frameworks don’t enforce con-tracts; if an application does not obey the con-tracts, it does not comply with the intendedframework design and will very likely behaveincorrectly. To make these relationships moreclear, a number of researchers have introducedthe concept of motifs to document the purposeand use of the framework in light of the role ofdesign patterns and contracts.5,6

A FRAMEWORK FOR SPEECH RECOGNITIONWe designed a framework for speech recog-

nition applications intended to enable rapidintegration of speech recognition technology inapplications using IBM’s ViaVoice speech recog-nition technology (http://www.software.ibm.com/speech/). Our primary objective was to simplify thedevelopment of speech applications by hiding com-plexities associated with speech recognition technol-ogy and exposing the necessary variability in theproblem domain so the framework user may cus-tomize the framework as needed.

We focused on the abstractions necessary to identifyreusable components and on the variations necessaryto provide the customizations required by a user tocreate a specific application. While this methodadheres to the classical definition of what a frameworkmust provide, we consciously incorporated feedbackinto the framework evolution process.

Speech concepts and complexitiesAt a simplistic level, the difference between two

speech recognition applications boils down to whatspecific words or phrases you say to the applicationand how the application interprets what you say.What an application understands is of course deter-mined by what it is listening for—or its active vocab-ulary. Constraining the size of the active vocabularyleads to higher recognition accuracy, so applicationstypically change their active vocabulary with a changein context.

The result that the speech recognition engine returnsin response to a user’s utterance is a recognized word.In the context of a GUI application, the active vocab-ulary and the recognized words may be different foreach window and may vary within a window, depend-ing on the state of the application.

Several factors contribute to complexity in devel-oping speech recognition applications. Recognitiontechnology is inherently asynchronous and requiresadhering to a well-defined handshaking protocol.Furthermore, the asynchronous nature of speechrecognition makes it possible for the user to initiatean action during an application-level task so that the

February 1999 25

Documenting aframework as a setof design patterns

is an effectivemeans of achieving

a high level of communication

between the framework designerand the framework

user.

.

26 Computer

application must either disallow or defer any actionuntil all previous speech engine processing can be com-pleted.

Also, speech-programming interfaces typicallyrequire a series of calls to accomplish a single appli-cation-level task. And achieving high accuracyrequires that the application constantly monitor theengine’s active vocabulary. The uncertainty associatedwith high-accuracy recognition forces the applicationto deal with recognition errors while the recognitionengine communicates with applications. It must do soat a process level and carries no understanding of GUIwindows or window-specific vocabularies. The appli-cation must therefore build its own infrastructure todirect and dispatch messages at the window level.

Framework abstractions and hot spotsCommon application functions include establish-

ing a recognition session, defining and enabling a poolof vocabularies, ensuring a legal engine state for eachcall, and directing recognized word messages andengine status messages to different windows in theapplication. The application needs explicit hot-spotidentification to handle variations such as the activewindow, the active vocabulary in a specific active win-dow, the recognized words received by the active win-dow based on the active vocabulary, and the actionthat an active window must take based on the recog-nized word.

Figure 1 shows a high-level view of the layeredframework architecture that we adopted in order toendow this theory with maximum flexibility andreuse. The speech recognition engine and speech appli-cation are separate processes. The first layer, the coreframework, encapsulates the speech engine function-ality in abstract terms, independent of any specific GUIclass library. A GUI speech recognition applicationusually involves the use of a GUI class library; there-fore, the second layer extends the core framework fordifferent GUI environments to provide tightly inte-grated, seamless speech recognition functionality.

Each GUI speech application requires customizingthe GUI extension for the core framework. We mod-

eled the common aspects of the problem domain byabstract classes in the core framework; the applica-tion implements concrete classes derived from theabstract classes. The class diagrams in the followingsections describe the extensions to the core frameworkfor IBM’s VisualAge GUI class library.

We use the prefix “I” as a naming convention forthe GUI extension classes. For example, the classISpeechClient refers to the GUI framework extensionclass 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.

Framework collaborations The class diagram shown in Figure 2 shows the

eventual interface classes for the VisualAge extensionto the core framework classes. (The frameworkevolved over time as we developed various applica-tions.) The IVocabularyManager, ISpeechSession,ISpeechClient, ISpeechText, and ISpeechObserverclasses provide the necessary abstractions to direct,dispatch, and receive speech recognition engine eventsat a level that is meaningful to the application. TheISpeechSession class must establish a recognition ses-sion through ISpeechManager prior to any speechfunctions starting.

ISpeechClient, ISpeechText, and ISpeechObserverprovide the necessary abstractions for implementing aGUI application, but do not contain a GUI compo-nent. An application creates a speech-enabled GUIwindow using multiple inheritance from theISpeechClient class and a VisualAge window classsuch as IFrameWindow. This inheritance providesspeech functionality and speech engine addressabilityat a GUI window level so that recognized words canbe directed to a particular GUI window.

Similarly, an application creates a speech-enabledtext widget using multiple inheritance from theISpeechText class and a VisualAge text-widget classsuch as IEditControl. This process provides speechfunctionality and speech engine addressability at a text-widget level. Derived ISpeechObserver classes providea publish-subscribe protocol necessary to maintain aconsistent speech recognition engine state across allwindows in the application. The IVocabularyManagerclass supports the dynamic definition and manipula-tion of vocabularies. The collaborations of these classesis internally supported by the ISpeechManager class,which behaves in the manner of a Singleton pattern2

(discussed later) that makes the class itself responsiblefor keeping track of its sole instance.

Figure 3 shows one of the primary hot spots in thesystem, the processing of words recognized by theactive ISpeechClient. DictationSpeechClient is a con-crete class derived from the abstract ISpeechClient

Recognizedword

Engine status

Speechrecognition

engine

Recognitionsession

Vocabularydefinition

Coreframework

GUI extension

Speech application

Figure 1. The speechrecognition engineand speech applica-tion are separateprocesses. The firstlayer, the core frame-work, encapsulatesthe speech enginefunctionality inabstract terms, inde-pendent of any spe-cific GUI class library.The second layerextends the coreframework for differ-ent GUI environmentsin order to providetightly integrated,seamless speechrecognition function-ality.

.

class. The speech engine invokes the pure virtualmethod, recognizedWord(), when it recognizes aword; this gives DictationSpeechClient the ability toprocess the recognized word in an application-specificmanner. This process works as designed only if theapplication obeys the accompanying contract, whichstates that before a user speaks into the microphone(which invokes the recognizedWord() method),the application must specify the active ISpeechClientand its corresponding vocabularies.

A GUI application might contain several windows,each of which is a multiple-inheritance-derived instanceof ISpeechClient and IFrameWindow. In a case like this,the framework user must at all times keep track of thecurrently active ISpeechClient and ensure that the cor-rect one is designated as being active. Likewise, enablingthe appropriate vocabulary based on the activeISpeechClient is the framework user’s responsibility.

One way to do this is to designate the foregroundwindow as the active ISpeechClient. The applicationmust track changes in the foreground window anddesignate the appropriate derived ISpeechClient asactive. This means that the application must processthe notification messages sent by the IFrameWindowclass when the foreground window changes and mustalso update the active ISpeechClient and vocabulary.Only then will the implementation of the hot spot inFigure 3 ensure delivery of the recognized words tothe correct window by calling the active ISpeech-Client’s recognizedWord() method.

FRAMEWORK EVOLUTION THROUGH REUSEWe used a single framework to build four applica-

tions: MedSpeak/Radiology, MedSpeak/Pathology, theVRAD (visual rapid application development) envi-ronment, and a socket-based application providingspeech recognition functionality to a video-catalogingtool. Each application we developed had a particulareffect on the development and evolution of the frame-

work itself. We used some well-known design patternsto facilitate reuse of design and code and to decouplethe major components of the system. Table 1 sum-marizes some of the design patterns we used and thereason we used them.

Initially, we used the Facade pattern to provide aunified, abstract interface to the set of interfaces sup-ported by the speech subsystem. The core abstractspeech classes shown in Figure 2 communicate withthe speech subsystem by sending requests to the Facadeobject, which forwards the requests to the appropri-ate subsystem objects. Facade implements the Singletonpattern, which guarantees a sole instance of the speechsubsystem for each client process.

As the framework evolved, we found ourselvesincorporating new design patterns to extend theframework’s functionality and manageability.

Radiology dictation applicationWe designed the MedSpeak/Radiology dictation

application—the first framework we created—to buildreports for radiologists using real-time speech recog-nition.8 We ourselves were the developers and usersof the framework, which vastly contributed to ourunderstanding of what the framework requirementswere and helped us find a balance between encapsu-lating problem domain complexities and exposing the

February 1999 27

IVocabularyManager

ISpeechSession

ISpeechManager

SpeechManager

ISpeechClient

ISpeechText

ISpeechObserver

Applicationcreates anduses SingletonISpeechSession,which instantiates the Visual AgeISpeechManagerclass

ISpeechManagercreates SingletonSpeechManagercontainingpSpchMgr, which points to itself

1

1

1 1 pSpchMgr

fSpchMgr

= Aggregation by value

Figure 2. Interfaceclasses for theVisualAge extension tothe core frameworkclasses. IVocabulary-Manager, ISpeechSes-sion, ISpeechClient,ISpeechText, andISpeechObserverclasses provide thenecessary abstractionsto direct, dispatch, andreceive speech recog-nition engine events ata level that is meaning-ful to the application.The prefix “I” signals aGUI extension class.

ISpeechClientrecognizedWord (IText &)

DictationSpeechClient

= Pure virtual method

Figure 3. A hot spotthat processes wordsrecognized by theactive ISpeechClient.DictationSpeechClientis a concrete classderived from theabstract ISpeech-Client class. Thespeech engineinvokes the pure vir-tual method, recog-nizedWord(),when it recognizes aword; this gives Dicta-tionSpeechClient theability to process therecognized word in anapplication-specificmanner.

.

.

28 Computer

variability needed in an application. Specifically, itindicated to us that we needed a clear separationbetween the GUI components and the speech compo-nents, so we defined the concept of a SpeechClient toabstract window-level speech behavior.

We used the class Adapter (or Wrapper) pattern toenable the use of existing GUI classes whose interfacesdid not match the application’s speech class interfaces.2

For example, we used Adapter to create a speech-enabled GUI window that multiple inherits from bothan abstract SpeechClient class and a specific GUI win-dow class—in this first application, the XVT GUI classlibrary. Thus, we were able to encapsulate speech-aware behavior in abstract framework classes so thatGUI classes did not have to be modified to exhibitspeech-aware behavior.

Finally, we used the Active Object9 and ServiceConfigurator10 patterns to further decouple the GUIimplementation from the speech framework. Usingthe principle embodied in the Active Object pattern,we separated method definition from method execu-tion by the use of a speech profile for each applica-tion, which in essence is the equivalent of a lookuptable. This delayed the binding of a speech commandto an action from compile time to runtime and gave ustremendous flexibility during development.

Similarly, the Service Configurator pattern decou-ples the implementation and configuration of services,thereby increasing an application’s flexibility andextensibility by allowing its constituent services to beconfigured at any point in time. We implemented thispattern again using the speech profile concept, whichset up the configuration information for each appli-cation (initial active vocabularies, the ASCII string tobe displayed when the null word or empty string isreturned, and so forth).

Pathology dictation applicationMedSpeak/Pathology was similar to the radiology

dictation application, but customized for pathology

workflow. We worked closely with the frameworkusers in extending the core framework for a GUI envi-ronment different from that of the previous applica-tion—namely, the VisualAge GUI class librarydiscussed earlier in the “Framework collaborations”section. The ease with which we accomplished thisporting effort validated our Adapter approach to pro-viding speech functionality in GUI-independentclasses.

However, it brought out an additional requirementstemming from the specific GUI builder that was beingused—that the class form of the Adapter pattern,which uses multiple inheritance, was unacceptable.We therefore modified our usage of the Adapter pat-tern to the object form (using composition) to accom-plish the same result. Instead of defining a class thatinherits both Medspeak/Pathology’s SpeechClientinterface and VisualAge’s IFrameWindow implemen-tation, for example, we added an ISpeechClientinstance to IFrameWindow so that requests for speechfunctionality in IFrameWindow are converted toequivalent requests in ISpeechClient.

Furthermore, the need to provide an abstractSpeechText class to provide speech-aware edit controlfunctionality became apparent when we realized thecomplexity associated with maintaining the list of dic-tated words. Likewise, the problems associated withmaintaining the speech engine state across differentwindows led to the definition of the SpeechObserverclass using the Observer pattern. The Observer pat-tern defines an updating interface for objects that needto be notified of changes in a subject.2

The VRAD environmentThe visual rapid application development (VRAD)

class of applications that used our framework providedus with insight into our original objectives, whichincluded hiding speech complexities and providingvariability. We planned that the speech frameworkclasses would be included in an all-encompassing

Table 1. Design patterns used in building the speech-recognition framework.

Design pattern used Reason for using the pattern

Object-oriented patternsAdapter2 (or Wrapper) Enable the use of existing GUI classes whose interface did not match the speech class interface

Create a reusable class that cooperates with unrelated GUI classes that don’t necessarily have compatible interfaces

Facade2 Provide an abstract interface to a set of interfaces supported by the speech subsystemAbstract speech concepts to facilitate the use of a different speech recognition technology

Observer2 Notify and update all speech-enabled GUI windows in an application when speech engine changes occur

Singleton2 Create exactly one instance of the speech subsystem interface class per application since the recognition system operates at the process level

Distributed or concurrent patternsActive Object9 Decouple method invocation from method execution in the application when a particular word is

recognizedAsynchronous Completion Token12 Allow applications to efficiently associate state with the completion of asynchronous operationsService Configurator10 Decouple the implementation of services from the time when they are configured

.

object-oriented programming framework, the Visual-Age class library. The previous pathology dictationapplication was one instance of an application thatused the VisualAge class library together with thespeech framework.

The greatest impediment to the acceptance of theframework by the VRAD users was that the publicinterface by itself didn’t adequately provide the under-standing necessary to create speech applicationsrapidly. For example, the variability provided by thehot spot in Figure 3 requires that the applicationenforce the designation of the correct ISpeechClientas well as the active vocabulary. Users had to turn tothe framework documentation in order to understandthe accompanying contracts. Furthermore, our use ofthe class form of the Adapter pattern, which uses mul-tiple inheritance, forced the users to understand thebehavior of the parent classes. This was additionalmotivation for us to favor the object form of theAdapter pattern.

We therefore modified the public interface in aneffort to reflect the client’s view, while still ensuringthat the necessary contracts were enforced. To accom-plish this, we created additional hot spots that helpedframework users comply with the internal constraintsnot ordinarily visible in the external interface butapparent on reading the documentation. The actualimplementation of the additional hot spots adhere tostandard framework practice of maintaining invari-ants within the framework and forcing the clients tooverride abstract methods.

SpeechSession. Figure 4 shows an implementationof the first user-identified hot spot in which the activeISpeechClient must be explicitly specified by theframework user. The new hot spot requires the frame-work user to create a concrete AppSpeechSession classderived from an abstract ISpeechSession class.SpeechSession hides from the user the speech subsys-tem’s Facade object, which was previously a publicframework class. To implement AppSpeechSession,the framework user must define the pure virtualmethod, getSpeechClient(), which the frame-work invokes to get the active ISpeechClient.

This hot spot necessarily draws the frameworkuser’s attention to the fact that an active ISpeechClientmust be specified prior to beginning the recognitionprocess, which alleviates the problem of designatingthe active ISpeechClient when the application starts.However, the behavior of updating the activeISpeechClient when the foreground window changesmay also be implemented by the same hot spot. Thecreation of a new abstract class that derives fromISpeechClient and IFrameWindow can encapsu-late the change in foreground window notificationfrom the IFrameWindow class and invoke the getSpeechClient() method.

SpeechClient. Figure 5 shows an implementation ofthe second user-identified hot spot. When a particu-lar ISpeechClient is active, the appropriate vocabularymust be activated. Enforcing this rule by invoking apure virtual method, getVocabulary(), in theactive ISpeechClient ensures that the active vocabu-lary gets updated by the framework user for each newactive ISpeechClient. This method returns the rightvocabulary based on the state of that particularISpeechClient. Here again, this hot spot forces theframework user to specify the active vocabulary priorto beginning the recognition process, which alsoensures that there are no surprises regarding activevocabularies and recognized words received by theactive ISpeechClient.

Socket interface applicationsThe socket interface class of applications was dif-

ferent from the others because we used a specificframework application to provide speech recognitionservices to numerous non-C++ client applications. Webuilt a VRAD application and extended the frame-work to support a socket interface to read and writeoperations on a socket connection, thus making irrel-

February 1999 29

ISpeechSessiongetSpeechClient () : ISpeechClient

AppSpeechSession

Figure 4. User-identified hot spot: Which ISpeechClient isactive? The new hot spot requires the framework user to cre-ate a concrete AppSpeechSession class derived from anabstract ISpeechSession class. This hot spot necessarilydraws the framework user’s attention to the fact that anactive ISpeechClient must be specified prior to beginning therecognition process.

ISpeechClientgetVocabulary () : IText

DictationSpeechClient

Figure 5. User-identified hot spot: Which vocabulary is active?When a particular ISpeechClient is active, the appropriatevocabulary must be activated. Enforcing this rule by invoking apure virtual method, getVocabulary(), in the activeISpeechClient ensures that the active vocabulary gets updatedby the framework user for each new active ISpeechClient.

.

30 Computer

evant the runtime environment of the actual speechapplication. The relative ease with which we were ableto add a socket-based string interface for speech recog-nition in a new SocketSpeechClient class only rein-forced our Adapter approach in the framework.

BUILDING RESILIENCETable 2 summarizes different aspects of our experi-

ence with the various framework applications wedeveloped. With each new application, the number offramework interface classes grew to encapsulate dis-tinct functional areas, which exemplifies the principleof modularizing to conquer complexity. But we didn’tcapture all abstractions in the problem domain duringthe initial analysis phase. In fact, some frameworkapplications led to the creation of new speech inter-face abstractions necessary in the analysis and designphases.

As a result, though, the framework realized moredesign patterns allowing for greater resilience. Wewere able to abstract more domain knowledge intothe core framework, which minimized the requiredGUI-specific extensions. The last rows in Table 2 sum-marize the breakdown of code split between the coreframework and the GUI extensions to the framework.Figure 6 shows the movement of the classes from theapplication/GUI extension to the core framework,which results in the 97 to 3 percent split from the orig-inal 75 to 25 percent.

MOTIVATED AND UNMOTIVATED USERSThe unmotivated user’s perspective helped further

abstract problem domain concepts. Figure 6 shows anincreasing abstraction of speech concepts into the coreframework classes with each new application. It showsthe change in distribution of functionality between thecore framework classes, GUI-specific extensions, andthe application—as the framework evolved.

The first framework application, Medspeak/Radiology, forced the framework user to understandand create SpeechObserver and VocabularyManagerconcepts. By the second application, we realized thatthese concepts were sufficiently abstract to be encap-sulated within the framework. At the end of the thirditeration, where we faced the most critical users, we had further abstracted SpeechObserver andVocabularyManager classes into the core framework.This was largely driven by an attempt to alleviate theuser’s confusion in understanding the collaborationsbetween the VocabularyManager, SpeechObserver,and SpeechSession classes.

The unmotivated framework user’s perspective canalso contribute to the evolution to a black-box frame-work from a white-box one.11 Our original white-boxframework required an understanding of how theGUI extensions to the core framework classes work,so that correct subclasses could be developed in theapplication. The VRAD user’s reluctance to acceptthis forced us to favor composition over inheritancein the application. We continued to use inheritancewithin the framework to organize the classes in a hier-archy, but use composition in the application, whichallows maximum flexibility in development.

REDUCING THE LEARNING CURVE WITH HOT SPOTS

Additional hot spots created as a result of theframework user’s perspective play an important rolein reducing the learning curve associated with a frame-work. This conclusion appears somewhat paradoxi-cal because hot spots are typically implemented inframeworks using object inheritance or object com-position,1,2 and both suffer from severe limitations inunderstandability.

A classic problem in comprehending the architec-ture of a framework from its inheritance hierarchy is

Table 2. Framework applications summary.

OO framework Radiology dictation Pathology dictation VRAD applications Socket applications

External framework SpeechClient SpeechClient, SpeechSession, SpeechSession,classes SpeechText, SpeechClient, SpeechClient,

SpeechObserver SpeechText, SpeechText,SpeechObserver, SpeechObserver,VocabularyManager VocabularyManager

Required extensions Yes Yes Yes NoEmployed patterns Active Object, Active Object, Active Object, Active Object, Adapter,

Adapter, Adapter, Adapter, Asynchronous Completion Token,Facade/Singleton, Facade/Singleton, Asynchronous Facade/Singleton, Observer,Service Configurator Service Configurator Completion Token, Service Configurator,

Facade/Singleton Observer, Service Configurator

Speech functions Dictation, Command Dictation, Command Dictation, Command, Command, GrammarsGrammars

Speech functionality (percentage)in core framework 75 80 90 97 in the GUI extensions 25 20 10 3

.

that inheritance describes relationships betweenclasses, not objects. Object composition achievesmore flexibility because it delegates behavior to otherobjects that can be dynamically substituted. Howeverit does not contribute to the understanding of thearchitecture either, since the object structures may bebuilt and modified at runtime. Despite this, we believethat the hot spots contribute to reducing the learningcurve. The primary hot spots address high-level vari-ability, but require an understanding of the underly-ing contracts and related framework architecture.

Designing for variability appears to be an impor-tant facet of the user perspective, too. Applicationscan be made to obey framework contracts, where pre-viously contracts were merely structured documen-tation techniques to formalize object collaborations.And since variability is often implemented usingdesign patterns, we were able to achieve an impor-tant goal: a common vocabulary for communicatingwith the framework users. The additional hot spotsgenerated by the user’s perspective complement theprimary ones and result in a design that necessarilyexposes the object collaborations in the framework.

Arguably, the new hot spots identified as the frame-work evolved could have been identified in the origi-nal design. We contend that as domain experts, eventhough we abstract the common aspects and separatethem from the variable aspects, we do so at a suffi-ciently high level that we mandate a minimum under-standing of built-in object collaborations in theframework. Originally, we had identified the hot spotaddressing the flexibility required to process recog-nized words within an application. But this works only

if the user understands the underlying collaborationsbetween vocabulary objects and speech client objectsdocumented in a contract. Some of the less glaring hotspots—such as the active vocabulary and active speechclient—are apparent as hot spots only when we viewthe framework from a framework user’s perspective.The level of reuse and the productivity gains achievedsummarized in Table 2 were obtained by informal usertesting, and by evaluating the number of lines of codewritten and the amount of time spent to develop a newframework application as the framework evolved.

Ultimately, using a common set of abstractionsacross the analysis, design, and implementa-tion phases and the use of design patterns to

capture these abstractions led to better communica-tion and a more efficient technique for handlingchanges as the framework evolved. Design patternshelped us more effectively communicate the internalframework design and made us less dependent on thedocumentation. ❖

AcknowledgmentThis framework was originally developed as part of

the Medspeak/Radiology product with John Vergo atthe IBM T.J. Watson Research Center.

References 1. W. Pree, Design Patterns for Object-Oriented Software

Development, Addison-Wesley, Reading, Mass., 1994.2. E. Gamma et al., Design Patterns: Elements of Reusable

February 1999 31

Vocabularymanager

Speechsession

Medspeak/pathology

Speechclient

Speechtext Core framework

Speechobserver

VisualAge extensions to core framework

(b)

Speechobserver

Vocabularymanager

Medspeak/Radiology

Speechclient

Core framework

Speechtext

XVT extensions to core framework

(a)

Speechobserver

Vocabularymanager

Core framework

Speechclient

Speechtext

Speechsession VisualAge extensions to core framework

(c)

VRAD application

Figure 6. Increasing abstraction of problem domain concepts with each new contract implicit in each application. Each application requires a slightly different architecture: (a) Medspeak/Radiology application, (b) Medspeak/Pathology application, (c) VRAD applications. The Socket application (notshown) simply adds a socket interface class on top of the SpeechSession class as an extension to the VRAD framework classes.

.

Object-Oriented Software, Addison-Wesley, Reading,Mass., 1995.

3. D.C. Schmidt, R.E. Johnson, and M. Fayad, “SoftwarePatterns,” Comm. ACM, Oct. 1996, pp. 36-39.

4. R. Helm, I.M. Holland, and D. Gangopadhyay, “Con-tracts: Specifying Behavioral Compositions in Object-Oriented Systems,” Proc. OOPSLA 90, ACM Press,New York, 1990, pp. 169-180.

5. R.E. Johnson, “Documenting Frameworks Using Pat-terns,” Proc. OOPSLA 92, ACM Press, New York,1994, pp. 63-76.

6. R. Lajoie and R. Keller, “Design and Reuse in Object-Oriented Frameworks: Patterns, Contracts, and Motifsin Concert,” Proc. Colloquium on Object Orientation inDatabases and Software Engineering, World Scientific,River Edge, N.J., 1994, pp. 295-312.

7. G. Booch, Object Oriented Analysis and Design, Ben-jamin/Cummings, Los Angeles, 1994.

8. J. Lai and J. Vergo, “MedSpeak: Report Creation withContinuous Speech Recognition,” Proc. CHI 97, ACMPress, New York, 1997, pp. 431-438.

9. D.C. Schmidt and G. Lavender, “Active Object: AnObject Behavioral Pattern for Concurrent Program-ming,” Proc. Second Pattern Languages of Programs

Conf., Addison-Wesley, Menlo Park, Calif., 1995.10. P. Jain and D. Schmidt, “Service Configurator–A Pattern

for Dynamic Configuration of Services,” Proc. ThirdUsenix Conf. Object-Oriented Technology and Systems,Usenix, Berkeley, Calif., 1997.

11. D. Roberts and R.E. Johnson, “Evolving Frameworks:A Pattern Language for Developing Object-OrientedFrameworks,” Pattern Languages of Program Design 3,R. Martin, D. Riehle, and F. Buschmann, eds., AddisonWesley Longman, Reading, Mass., 1998.

12. T. Harrison, D. Schmidt, and I. Pyarali, “AsynchronousCompletion Token,” Pattern Languages of ProgramDesign 3, R. Martin, D. Riehle, and F. Buschmann, eds.,Addison Wesley Longman, Reading, Mass., 1998.

Savitha Srinivasan is a software engineer in the VisualMedia Group at the IBM Almaden Research Centerin San Jose, California. Her current research interestsinclude using speech recognition and other synergis-tic techniques, while practicing object-oriented tech-nology. She received an MS degree in computer sciencefrom Pace University.

Contact Srinivasan at savitha@almaden.ibm.com.

PURPOSE The IEEE Computer Society is theworld’s largest association of computing pro-fessionals, and is the leading provider oftechnical information in the field.

ME M B E R S HI P Members receive themonthly magazine COMPUTER, discounts, andopportunities to serve (all activities are led byvolunteer members). Membership is open toall IEEE members, affiliate society members,and others interested in the computer field.

B O A R D O F G O V E R N O R STerm Expiring 1999: Steven L. Diamond, Rich-ard A. Eckhouse, Gene F. Hoffnagle, Tadao Ichikawa, James D. Isaak, Karl Reed, Deborah K. ScherrerTerm Expiring 2000: Fiorenza C. Albert-Howard, Paul L. Borrill, Carl K. Chang, Deborah M.Cooper, James H. Cross III, Ming T. Liu, Christina M.SchoberTerm Expiring 2001: Kenneth R. Anderson, Wolfgang K. Giloi, Haruhisa Ichikawa, David G. McKendry, Anneliese von Mayrhauser, Thomas W. WilliamsNext Board Meeting: 19 Feb. 1999, Houston, Texas

I E E E O F F I C E R SPresident: KENNETH R. LAKERPresident-Elect: BRUCE A. EISENSTEINExecutive Director: DANIEL J. SENESESecretary: MAURICE PAPOTreasurer: DAVID CONNORVP, Educational Activities: ARTHUR W. WINSTONVP, Publications: LLOYD “PETE” MORLEYVP, Regional Activities: DANIEL R. BENIGNIVP, Standards Activities: DONALD LOUGHRYVP, Technical Activities: MICHAEL S. ADLERPresident, IEEE-USA: PAUL KOSTEK

EXECUTIVECOMMITTEE

President: LEONARD L. TRIPP *Boeing CommercialAirplane GroupP.O. Box 3707, M/S19-RFSeattle, WA 98124O: (206) 662-4437 F: (206) 662-14654404l.tripp@computer.org

President-Elect:GUYLAINE M. POLLOCK *Past President:DORIS CARVER *VP, Press Activities:CARL K. CHANG*VP, Educational Activities:JAMES H. CROSS *VP, Conferences and Tutorials:WILLIS KING (2ND VP) *VP, Chapter Activities:FRANCIS LAU *VP, Publications:BENJAMIN W. WAH (1ST VP)*VP, Standards Activities:STEVEN L. DIAMOND *VP, Technical Activities:JAMES D. ISAAK *Secretary:DEBORAH K. SCHERRER *Treasurer:MICHEL ISRAEL*IEEE Division V DirectorMARIO R. BARBACCIIEEE Division VIII DirectorBARRY JOHNSON *Executive Director and Chief Executive Officer:T. MICHAEL ELLIOTT

C O M P U T E R S O C I E T Y W E B S I T EThe IEEE Computer Society’s Web site, at http://computer.org, offers information and samplesfrom the society’s publications and conferences, aswell as a broad range of information about tech-nical committees, standards, student activities, andmore.

COMPUTER SOCIETY O F F I C E SHeadquarters Office1730 Massachusetts Ave. NW, Washington, DC 20036-1992Phone: (202) 371-0101 • Fax: (202) 728-9614E-mail: hq.ofc@computer.orgPublications Office10662 Los Vaqueros Cir., PO Box 3014Los Alamitos, CA 90720-1314General Information: Phone: (714) 821-8380 • membership@computer.orgMembership and Publication Orders:Phone (800) 272-6657 • Fax: (714) 821-4641E-mail: cs.books@computer.orgEuropean Office13, Ave. de L’AquilonB-1200 Brussels, BelgiumPhone: 32 (2) 770-21-98 • Fax: 32 (2) 770-85-05E-mail: euro.ofc@computer.orgAsia/Pacific OfficeWatanabe Building, 1-4-2 Minami-Aoyama,Minato-ku, Tokyo 107-0062, JapanPhone: 81 (3) 3408-3118 • Fax: 81 (3) 3408-3553E-mail: tokyo.ofc@computer.org

E X E C U T I V E S T A F FExecutive Director and Chief Executive Officer: T. MICHAEL ELLIOTTPublisher: MATTHEW S. LOEBDirector, Volunteer Services: ANNE MARIE KELLYChief Financial Officer: VIOLET S. DOANChief Information Officer: ROBERT G. CAREManager, Research & Planning: JOHN C. KEATON

12JAN1999

®

.