lessons learned becoming a framework developer

SOFTWARE—PRACTICE AND EXPERIENCESoftw. Pract. Exper. 2002; 32:789–800 (DOI: 10.1002/spe.459)

Lessons learned becoming aframework developer

James Carey1,∗,† and Brent Carlson2

1WebSphere Business Components, IBM Corporation, IMAD DXO, 3605 Highway 52N, Rochester,MN 55901, U.S.A.2LogicLibrary, Inc, 2717 Hwy 14W, Suite M, Rochester, MN 55901, U.S.A.

SUMMARY

When we began developing frameworks we were naive about what was involved in developing a frameworkversus other software. We had experience in object-oriented development, but even that did not prepareus for some of what we learned as we developed frameworks. This paper captures some of the lessonsthat we learned as we became framework developers. If you have already developed frameworks thesewill validate what you have already learned, but for someone just starting out these are the areas wherewe believe you will be surprised. For example, are you ready to become comfortable exposing your workcompletely, since almost everything might be part of the framework product? Are you ready to becomemore disciplined so you can manage and deliver all these pieces? Other lessons will validate and enhancewhat you learned developing object-oriented software; for example, the value of patterns, especially todefine customization points. All are part of the biggest lesson of all, that as a framework developer you areno longer independently developing an application for an end-user, instead you are on the many diversecustomer teams using the framework—helping them deliver their applications. Copyright 2002 JohnWiley & Sons, Ltd.

KEY WORDS: patterns; frameworks; software engineering practices; object-oriented applications and systems

When we began working on the IBM SanFrancisco‡ frameworks [1] we were naive about what itreally meant to develop a framework, especially a framework to be sold as a product. We had both hada number of years of experience applying object-oriented principles to the development of operatingsystem code in C++. Although this experience was crucial to our success working on object-orientedframeworks, it did not fully prepare us for what was involved in developing a framework. In this paperwe have captured the lessons we learned as we became framework developers. We present these lessonsas framework process patterns [2] that distill our experience into a form that is broadly applicable.

∗Correspondence to: James Carey, WebSphere Business Components, IBM Corporation, IMAD DXO, 3605 Highway 52N,Rochester, MN 55901, U.S.A.†E-mail: [email protected]‡IBM, and IBM SanFrancisco are trademarks or registered trademarks of International Business Machines Corporation. Othercompany product and service names may be trademarks or service marks of others.

Copyright 2002 John Wiley & Sons, Ltd.

790 J. CAREY AND B. CARLSON

These fundamental patterns will be recognized by experienced framework developers and can be usedto confirm their experience. For developers new to frameworks, they will help prepare you for what isahead, easing your transition.

We have identified both broadly applicable patterns and patterns applicable at specific points inthe development process. This paper is not long enough to cover all of the patterns we identified,so we will focus on a few key patterns. (More are available in Framework Process Patterns [2].)These patterns cover a number of areas: overall development principles, requirements, analysis, design,documentation, social aspects of development, and using a framework. In this paper, in order to give abroader flavor of the patterns we will discuss at least one pattern in each of these areas.

Each of these patterns has a short descriptive name that is sometimes humorous. This is an artifactof their identification and usage on the IBM SanFrancisco project. These names became part of theproject lexicon. We found that the humorous nature of the names (and the supporting pattern and storybehind the name) made it easier for new developers joining the project to grasp and retain the patterns.This allowed us, just as other pattern aficionados are able to rapidly communicate ideas through patternnames [3], to talk about these concepts at a higher level. We have provided a more descriptive name(in parentheses beside the pattern name) to allow you to use whichever name is more effective for you.We’ve also sprinkled throughout this paper references to a fictitious clothing management frameworkcalled Clothing Analysis and Placement, or CAP for short. While this domain is clearly simplistic, ithas the advantage of allowing us to point out specific aspects of our experience in concrete terms usinga domain that everyone understands.

OVERALL DEVELOPMENT PRINCIPLES

The first patterns we will describe are ones that apply across the entire development processor in general to the framework’s architecture. We will discuss two patterns: Alles in ordnung§

(use a systematic development process) and Innocent questions (balancing domain and technicalconsiderations).

Alles in ordnung (use a methodical development process)

Using a methodical development process¶ is crucial when developing a framework. While beneficialto any software development effort, such a process has increased importance for framework developersbecause a framework has many more artifacts that ultimately become part of the delivered product.From the point of view of its users, a framework is not merely the sum total of its documentedapplication programming interfaces (APIs). Instead, a framework is an architecture and design inaddition to the working code. Making sure that all of the pieces are developed and documentedconsistently and that they fulfill the framework’s requirements mandates that developers follow asystematic process. When developing an application (especially a business application) where the

§This German phrase translates to ‘All is in Order’.¶We do not espouse any particular development process. Processes ranging as widely as the Extreme Programming [4] andthe Unified Software Development Process [5] can be effectively applied to framework development as long as the developersunderstand the process and their responsibilities within it.

Copyright 2002 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2002; 32:789–800

FRAMEWORK DEVELOPER 791

domain expertise and the technical expertise rarely reside in the same individual, the process allows forformal connection points where the artifacts can be verified by experts from both perspectives, ensuringthe framework properly fulfills its business and technical requirements.

This is not to say that you should have a heavy monstrous process, the kind that every projectmanager seems to desire. The point is not one of lots of process; the point is letting everyone knowwhat is expected, when it is expected, and how it will be verified. Any process that enables you toeffectively produce the artifacts (to be shipped as part of the framework) can be used. Which specificprocess you choose will be driven by size of team, preferred development style, and many other factors.

Innocent questions (connecting domain and technical)

As software moves more into specialized business domains, the domain expert and technical expert areoften not the same person. These people do exist, but they are rare. If you have one of these people,hold onto them like gold. In the past, learning a file system so you could implement it was possible.Not many developers will spend 20 years understanding supply chain management, just so they can actas both the domain and technical expert at the same time.

Since at least two people are involved throughout key stages of the development process, there are anumber of dynamics that have to be taken into account. One of the most crucial is making it clear whohas final say when. This sounds obvious, but we found it was necessary to be explicit. If clear ownershipis not established early in the project, it is very easy for technical experts, after a little experience in thedomain, to think they have become domain experts and vice versa. These pseudo-experts are dangerousand will adversely affect the framework. Defining who owns what is best done in terms of the artifactswithin the methodical development process (see above). We have found it most useful for the domainexpert to be responsible for the requirements, use cases, and initial analysis model, and the technicalexpert to be responsible for the refinement of the analysis model, the design model, and the code.However, the ultimate goal has to be kept in mind, which is to provide something recognizable anduseful for the framework consumer.

Having a methodical process also allows identification of specific points when who is driving thedevelopment changes. This frees the other expert to ask innocent questions that help them learn and(as discussed below) can help refine the framework. From the point of view of a framework designer,for example, innocent questions are those that another domain expert would not think of asking becausethey are too elementary, or because the answer is seemingly obvious. However, when asked by someonewithout a domain background, they often shed new light on the topic at hand, forcing the experts torethink their assumptions and making what seemed obvious not so obvious. The same principle appliesto domain experts as they ask questions about framework designs established by the technical team.

REQUIREMENTS

Gathering the requirements for a framework is crucial. When a framework is used, a customer will takethe requirements for their application and map them to the framework. In this way they will find whatportions of the framework can be used to fill a particular application requirement. Good requirementswill ensure that the framework addresses the right problems and will make it easier for the frameworkcustomer to use the framework. We will discuss four patterns: It depends (identifying customization),



What not how (implementations masquerading as requirements), Tor’s second cousin (how extreme istoo extreme?), and The stupid test (balancing capabilities versus keeping the framework focused).

It depends (identifying customization)

A key aspect of a framework is its flexibility; the flexibility that allows a customer to (by takingadvantage of variability) customize framework elements for their particular needs. Incorporatingflexibility into a framework involves identifying the correct set of requirements that will be fulfilled bythe framework—including the variability that needs to be supported. Some of this variability will beeasy to identify, some will not. The technical lead, not being a domain expert, is in a unique positionto help with this identification. He or she can do this by listening to domain expert discussions (andarguments) and pointing out that disagreements between experts may simply be places that requirevariability. This process also involves listening to the domain expert’s responses to innocent questions(as described above). While working on the IBM SanFrancisco project, we heard ‘It depends’ often aspart of the answer. This answer usually was a strong indication that variability should be incorporatedat that point in the framework.

Using our CAP example, let us consider a couple of potential requirements under this criteria. Shouldour CAP framework provide real-time access to fashion chat rooms and hourly updates from all the bigname designer web pages? Probably not—specialized features like these can help to differentiate onecompany’s application from another, but an application like Cowboy Clothes Corral (C3 for short) isnot going to be too interested in hooking up with Calvin Klein and Tommy Hilfiger. On the other hand,CAP needs to provide basic functions that every clothing selection application will use—functions likedefining clothing categories (which C3 will use to define categories like roundup wear, rodeo wear, anddying-with-your-boots-on wear) and making sure that the clothing wearer has selected clothing itemsfrom all the necessary clothing groups (C3 does not ever want to let any of its cowboy customers leavea bunkhouse without wearing a cowboy hat and boots).

Having access to a mix of expertise (for example, a cowboy outfitter, a clown outfitter, and a fashionconsultant serving as domain experts for CAP) is crucial to the quality of a framework. This variety ofexperience and focused tension exposes the framework requirements to many potential customizationsthat can be evaluated under the ‘It depends’ criteria (and other criteria discussed in this section),resulting in a more complete and effective framework for our application developers to use.

What not how (implementations masquerading as requirements)

How do you describe something to someone? When describing a pattern, you may have noticed that youhave to start with a number of examples before you can talk about the abstract pattern. When developingframeworks, you are trying to get from the specific requirements of a number of applications to a coreset of requirements (with variability) that the framework can use. This is not something most domainexperts do. They are used to talking about specific applications and not frameworks. A natural (andin our case unfortunate) side effect of this is that often requirements are described in terms of the lastapplication a domain expert worked on. When this happens the requirements document a particularimplementation, rather than the needed abstract requirement.

Why is this important? Knowing the true requirements frees you to solve the problem without thebaggage of what was done for a particular implementation. One case we encountered on the IBMSanFrancisco project was in the caching of account balances in the General Ledger. This requirement



was first given as the need to keep a set of base balances for all accounts (basically monthly totals).After exploring the objectives behind this requirement, we were able to determine that in reality therequirement was that some specific account balances needed to be retrieved rapidly. This realizationallowed us to provide a much more advanced implementation that supported specifying only thosebalances that were truly needed quickly, thus reducing the storage and update overhead of the cache.

Taking another page from CAP, let us consider the issue of clothing appropriateness. If our CAPframework domain expert specifies during requirements gathering that the framework should not allowstriped and checked clothes to be worn together, we need to push back a bit. First of all, if someoneuses CAP to build a clown clothing selector, then not allowing stripes and checks in the same outfit isgoing to be a serious limitation. As we question our domain expert, we find out that what the domainexpert really wants is for the framework to be able to determine if two items of clothing clash witheach other. It may seem to us as if we now have discovered the ‘real’ requirement behind the originalstatement. But, if we keep on exploring this topic with our expert, we might discover that in fact whatthe framework really needs is the ability to determine how compatible two clothing items are, and thatcompatibility might take into account color, style, and many other clothing attributes. In effect, what wehave done through this process is move from thinking of a particular implementation as requirementsto extracting the true framework requirements from our starting point.

Not all requirements will be implementations in disguise. Fully explore the objectives behind thestated requirements (sometimes using innocent questions) so that you discover the real requirementsand thus allow simpler, more efficient, and otherwise superior implementations.

Tor’s second cousin (how extreme is too extreme?)

The iterative process we described in the previous section is very important when developingframework requirements, but there is a danger of pushing requirements too far. While developing theIBM SanFrancisco frameworks, we found that Tor, one of the domain experts working on the project,would often come up with unusual ways a user might want to customize the frameworks. Quite often,these unusual scenarios were very valuable because they forced us to deal with real inadequaciesin the frameworks. Sometimes, though, these scenarios represented a very small number of usersand supporting those users directly in the frameworks would have required making the frameworksmore difficult to understand and use. We blamed these scenarios on Tor’s fictitious (and crazy) secondcousin—customization support that just went too far.

Returning to CAP, let us suppose that one of our domain experts insists that the framework mustsupport the ability to specify the smelliness of the clothing chosen for wearing. He points out that ifsomeone is going to do a ‘dirty’ job and will be getting smelly anyway, he might like the clothingselection algorithm to reject clothing because it does not smell bad enough to begin with. Althoughthis capability could be useful in some (very limited) cases, we determine that most applications willnot want this ability so we exclude it from our framework requirements. This is a case of Tor’s secondcousin in action.

How did we decide that some scenarios went too far while others were appropriate to support in theframework? That is where having enough diversity of experience among the domain experts workingon the framework is crucial. One lone expert is not sufficient—no matter how skilled and experiencedthis expert is, he or she is going to have blind spots and biases which will weaken the framework ifnot caught in time. There is no one right answer for the correct number of domain experts; the moreexperienced the domain experts are, the higher the likelihood is that a small number of domain experts



will be sufficient. Too many domain experts working on a specific portion of the framework can alsobe a problem—they might not be able to reach agreement on the right approach quickly, or even reachagreement at all! We found that two to three domain experts working directly on a particular problem,bringing in a senior expert during early discussions and reviews, was usually quite effective.

Another way to look at this problem is to consider the alternative. What if the framework did supportall possibilities? Adding the ‘smelliness’ factor to CAP introduces one more piece of informationthat users have to understand. If such marginal features continue to accumulate, the framework willeventually become ‘top heavy’; there are too many possible solutions for the user to consider so he orshe just walks away and implements their own solution to the problem.

The stupid test (balancing capabilities versus keeping the framework focused)

Before we move on from discussing how to develop framework requirements, let us discuss onemore approach to deciding what a framework should provide. As we developed SanFrancisco, weoccasionally came across object attributes or behavior which, though they were not identified as part ofthe common behavior that all applications using the framework would need, were still included in theframework. Why did we break our rule about the framework providing only basic functions? Well, asit turns out, these attributes and behavior were ones that anyone familiar with the domain would thinkwe were stupid for not including—in other words, leaving them out of the framework did not pass thestupid test. It is not only important to get the framework requirements correct; it is also important tobe sensitive to how the framework will be perceived by potential users. Framework users are likely tohave common sets of basic requirements that should not be overlooked in our zeal to build a pure anduncluttered framework.

In our CAP example, the framework relies on the Clothing class providing information about theclothing item’s location, color, and size. As we discuss the domain, we determine that, even thoughCAP does not directly use it, we should also include fabric pattern as an attribute because of itslikely use by application developers using our framework. However, a set of stain descriptions is notsomething every application will want, so we will not provide this information.

ANALYSIS

Analysis is the first stage of breaking the larger problem down. Developing good analysis models thatproperly distribute the responsibilities defined by framework requirements is the key to building aflexible and useful framework. Because the analysis model so heavily influences framework design, itis crucial that domain and technical experts have a ‘meeting of the minds’ at this stage. We will discusstwo patterns that we have found quite helpful to guide framework analysis along these lines: Eating theelephant (decomposing the problem), and Where is Mr Spock when you need him (domain–technicalcross-team communication).

Eating the elephant (decomposing the problem)

Although there are a number of ways to partition a framework, we have found that it is valuableto establish large framework pieces that have minimal interaction with each other (i.e. are looselycoupled). This means that we collect together analysis classes that have an affinity for one anotherinto separate categories (clusters of framework classes that are closely related), keeping the contents



of those categories as separate from other categories as possible. Some component categories willbe obvious (like separating clothing repair from purchasing algorithms in CAP), while others willcome about only through extensive iteration over the analysis model. We have found that it is bestto establish an initial component category structure early in the analysis process, populating thosecategories with the core (that is, ‘obvious’) analysis classes. As analysis continues, new analysis classeswill be defined and additional responsibilities will be placed on existing analysis classes. Throughoutthis process, you will find that some categories will become tightly coupled. You may need to moveclass responsibilities, move entire classes from one category to another, or even create new categoriesto minimize cross-category coupling.

We also found it useful to keep dependencies unidirectional as much as possible—having uppercategories depend on lower categories but not vice versa. This approach defines a natural sequencefor further incremental development of the framework, and also simplifies framework maintenancebecause you are not likely to encounter cyclical dependencies between categories when fixing bugs oradding new framework capabilities.

Where is Mr Spock when you need him (domain–technical cross-team communication)

The first point in the development process where the domain and technical teams have to work closelytogether is on the analysis model. Without the help of Mr Spock’s Vulcan mind-meld (or a reasonablefacsimile thereof), a correct and complete analysis model will not happen automatically. We havefound that it’s very helpful for domain experts to define an initial analysis model. Even though thismodel is likely to contain many errors, it still provides a useful base upon which the technical teamcan apply their analysis skills. Once this initial model has been established, we have found thateffective communication between domain and technical experts is essential to refining the analysismodel. You could start with the most crisply and completely defined requirements ever put to paper,but if your technical experts are unable to understand the implications of those requirements, they arelikely to misallocate responsibilities across analysis classes, even to the point of completely droppingsome requirements. Your domain experts have an important responsibility here, asking the necessaryinnocent questions to ensure that all requirements make the transition into the analysis model. In manycases, the original analysis model serves to trigger these questions, as its contents are a type of domainchecklist. If a concept captured in the original analysis model is not present in the refined model, thismismatch becomes an obvious point of discussion.

DESIGN

Taking the requirements, use cases, and analysis models, and realizing them as an object-orientedframework design is an area where we defined many useful patterns. Three of them, Pass thebuck (knowing when a framework should not do something), Missed it by that much (developingand applying patterns), and it’s still OO to me (frameworks are not exempt from good and badobject-oriented practices), are covered here.

Pass the buck (knowing when a framework should not do something)

Coming from non-framework development, we had a natural desire to make the framework bulletproof:to make sure that, no matter what happens, the situation is covered. The transition from this approach



to one that ‘passes the buck’, i.e. that defers many decisions to the framework user, was one of themost difficult transitions we had to make. It is important to keep in mind that deferring decisions is atthe very core of a framework. There are three main categories of decisions that must be incorporatedinto a framework design. One category is decisions that can be made by the framework. These arethe framework elements that are dealt with consistently in all instances no matter what. This maybe either from a technical perspective—such as deciding how to distribute objects—or at a domainlevel—realizing that everyone does a particular business process a certain way. The second category offramework decisions, which we have found to be the most common, is decisions that can be partiallymade by the framework. These aspects of a framework are the extension points (hotspots [6]) thatsupport framework variability. We describe these aspects of a framework as partially made decisionsbecause the structure surrounding the decision is established by the framework—for example, theparameters passed through a domain class to its contained strategy object [3]. The third category isdecisions that should not be made in the framework. Making these decisions prevents the frameworkfrom being used in a number of situations. In many situations, there is not even agreement in thedomain about what should be done.

For example, let us suppose that our CAP framework prevented users from selecting clothes to beworn if they had even the slightest tear. While this might be appropriate for some uses of the framework,it is overly restrictive for most uses. This is a case where we should allow the application developer tomake the final decision (i.e. to ‘pass the buck’ to the application developer).

Knowing which category a decision falls into is important because it impacts on the usability andapplicability of the framework. Accepting that sometimes the right decision is to not make any decisionat all—to ‘pass the buck’ to the framework customer—is crucial to creating a successful framework.

Missed it by that much (developing and applying patterns)

We are strong believers in the power of design patterns. Design patterns make framework developersmore efficient, and more importantly, they help to ensure consistency across the framework. This meansthat similar situations within the framework are addressed by applying the same pattern (or variationsof it). This is particularly important to framework consumers—it both reduces their learning curve forthe framework and reassures them that they properly understand important aspects of the frameworkand will be able to effectively use them.

Let us look at a simple example from our CAP framework. This framework provides a methodon Clothing to determine cleanliness. This is a method that simply returns the stored attribute whichcontains the cleanliness enumerated value (e.g., fresh as a daisy, neutral, dusty, or dirty). Or is it?We have a requirement that in some instances the cleanliness will diminish with time (clothes get dustyin a closet), so that the enumerated for cleanliness changes depending on when you ask the question.If the method is left as it is, then to make this change you must replace our Clothing class so that youcan replace the incorrect method. If this is a Tor’s second cousin case, then this is fine. If it is not, thenwe should use the Strategy design pattern [3] to encapsulate the algorithm for determining cleanliness,providing a default strategy which simply returns the attribute. This means that that framework userwho needs time-based cleanliness can simply replace the default strategy with their own strategyimplementation without affecting anything else.

In this example, the use of the Strategy design pattern is extremely important. It allows not onlydifferent variable parts of the object to be varied independently, but it also allows them to be developed



independently, allowing the expert in cleanliness to work on the cleanliness strategy without having toworry about anything else, such as the repair instructions.

Throughout the development of the IBM SanFrancisco frameworks, the most used book on our deskswas Design Patterns [3]. Because we knew that these patterns were widely adopted and understood bythe software industry, we applied them to our framework designs whenever possible. However, weencountered cases where the existing patterns did not fully meet our needs. Sometimes we were ableto define minor extensions to a pattern (for example, the IBM SanFrancisco project’s Policy pattern[7, p. 61] introduces specific contexts to the Strategy pattern [3]). In other situations, we found thattwo or more patterns could be combined to meet our needs (for example, the IBM SanFranciscoproject’s Chain Of Responsibility-Driven Policy pattern [7, p. 75] incorporates a chain of responsibilityfor policy retrieval that allows us to naturally define both default behavior as well as allow frameworkusers to easily override this behavior on a case by case basis).

Occasionally we realized that none of the existing patterns we were aware of met our needs. Oftenin these situations we first applied our object-oriented design skills to the problem and came up withwhat we thought was a reasonable solution. As you would expect, we refined this design in an iterativefashion until it met our objectives, then moved onto the next task. In many cases, we eventually hitupon one or more new situations that were more or less similar to our original problem. We did notalways immediately recognize that this was the case. Once we did, however, we then entered the zoneof pattern definition. Those of you who have attempted to define and document a pattern know thatthis is no small task, and we did not take this step lightly. Only when the cost–benefit ratio was highenough did we formalize a pattern for use by our development team.

One way we determined if the return was high enough was by working with our domain expertsto evaluate the framework as a whole. In this way we were able to see if there were enough specificsituations where our potential pattern applied to warrant the cost of defining a pattern (and possiblyretrofitting that pattern to portions of the framework that had been designed beforehand). This processis ‘iteration in the large’, and while painful, can contribute greatly to the usability of a framework.

It’s still OO to me (frameworks are not exempt from good and bad object-oriented practices)

Although many aspects of developing an object-oriented framework differ from non-frameworkdevelopment, there are also elements that rely directly on object-oriented principles. The samerules you learned through years of hard-earned experience developing object-oriented software areimportant to follow when developing object-oriented frameworks. Sometimes these rules are evenmore important! During the development of the IBM SanFrancisco frameworks, we were seducedby the evils of inheritance for code reuse. We were able to reuse the code from one class in a similarclass by extracting an implementation base class from the original design, but this approach madethings confusing (especially due to complications related to contravarience) for both the developer thatmaintained it and the customers trying to understand it—remember that customers get to see not onlythe APIs to your software but also the design and other documentation! Suddenly, just to save copyinga few lines of code, two things that really were not related but did the same sort of thing had an explicitinheritance relationship to a common base class. Unfortunately, the fact that we were developing aframework did not magically make this a good idea and we had to eventually change the design andimplementation accordingly.



DOCUMENTATION

The documentation of the framework includes not only the development artifacts shipped as part of theproduct, but also the documentation to allow users to quickly understand the framework.

Souvenirs (keeping just enough to write documentation later)

Most developers do not like to document, instead they like to write code. Getting them to writedocumentation can be very painful. However, if you expect a framework customer to be able toeffectively use the framework, they will have to be able to understand it in great detail. Unless youplan to hold lots of seminars or provide lots of hand holding, you are going to have to provide lots ofdocumentation. This documentation has to address the needs of the different users of the framework—the domain experts looking at it to see if it will solve their problems and the developers trying toget something to execute. We found it necessary to make the team aware of this importance and theimportance of at least leaving reminders (which we called ‘souvenirs’) along the way to allow thisdocumentation to be written at a later time—either by the developer or by a technical writer (andreviewed by the developer).

Remember that someone using framework documentation to evaluate the framework must be able totrust that it reflects what is actually implemented in the framework. When application developers useCAP, they need to be able to read the requirements and analysis and determine that some aspect of theframework partially or completely meets the needs of their application. They should not be put in thesituation of completing gap analysis for the Clothing class (as we discuss in the section ‘Map early,map often’ below) and its associated processes, then discovering once they begin application designand implementation that the framework documentation is out of synch with its implementation. If thathappens too often, they will soon become an ex-framework user!

SOCIAL ASPECTS

Developing object-oriented software is a social activity. Discussions of designs, techniques, andapproaches are the key to getting to the right solution. This is particularly true of frameworkdevelopment. Because of the need to ensure that proper abstractions and extensions are incorporatedinto the framework, interaction between the domain experts and the developers is especially importantwhen developing frameworks. These interactions have some special needs.

The great communicator (translating between domain and technical terminology and concepts)

Each profession seems to have a language all of its own. Programming is as guilty (or perhaps guiltier,with our propensity towards acronyms) of this as any profession. Bringing together software developerswith domain experts can be a real challenge because of this ‘terminology gap’. Accountants do not talkabout abstraction and inheritance and developers do not talk about currency revaluation and reversingentries. We found that it was crucial to have someone bridge this gap; someone who could translatebetween the two distinct languages. This person came in a number of forms. Occasionally, we werefortunate enough during IBM SanFrancisco framework development to find a single person who could



serve as both domain expert and technical expert for a team. Usually such a person naturally gravitatedtowards this role for the team. In other cases, someone just had to step up to the job and learn theterminology of the other side—sometimes from scratch, but sometimes from previous knowledge,such as a class in college on accounting.

USING FRAMEWORKS

Developing an application with a framework also requires changes. Like any software being reused, anup-front effort is needed to find out what it provides and how it provides it. Then you can map to anduse the framework.

Map early, map often (use frameworks by mapping)

It is not enough to know what the framework provides; somehow it has to get used as early as possiblein the development cycle. We have found the best way to do this is to add explicit mapping steps tothe development process. These mapping steps, which should start with requirements, ensure that theframework is used at the highest level possible. The higher it is used the more reuse is realized. Reuseat the requirements level means that (via customization) the design and tested code provided by theframework can be reused. If you do not add these mapping steps, the framework may become nothingmore than a class library—mapped to at the implementation stage.

As you map against the framework capabilities, you are bound to discover cases where theframework’s contracts are inadequate for your needs. Usually this means you are replacing a methodbecause it does not do what you want. For example, you might want to introduce more extensiveclothing size information than CAP provides—replacing a simple size value with a compound valueobject. You cannot do this within the contracts. You have to break the contracts, in effect renegotiatinga new contract within the context of the framework. This means that you may be breaking all sortsof important object-oriented rules, such as contravariance. The key is that you will be breaking themconsistently, since you know how you are actually using the method. It is up to you to ensure thatall uses of the original contract (i.e. method) are consistent with the new contract. In cases wherethe framework does not use the method, this is easy. When the framework does use the method,however, then some changes to the framework may be required. How do you find those places where theframework needs to be modified? By reviewing the extensive, complete, and consistent documentationshipped with the framework, of course!

CONCLUSION

These are just a few of the patterns we identified and used as part of the IBM SanFrancisco frameworkproject. They all share a common root in the framework’s goal to provide recognizable and reusablecontent to the framework user coupled with the realization that framework development meansexposing much more of the software development to the framework customers, making it more ofa partner than a supplier to its customers. While each framework development project is unique, thesepatterns should give you a jump-start as you become a framework developer.



APPENDIX. FURTHER READING ON FRAMEWORKS

• These framework process patterns and others not covered are described in the book FrameworkProcess Patterns [2].

• Many detailed papers on framework development are available in the books BuildingApplication Frameworks: Object-Oriented Foundations of Framework Design [8], Domain-Specific Application Frameworks: Framework Experience by Industry [9], and ImplementingApplication Frameworks: Object-Oriented Frameworks at work [10].

• See Ralph Johnson’s Frameworks Home Page [11].• Framework Meta patterns are described in Design Patterns for Object-Oriented Software

Development [6].• For an article on the novel use of the IBM SanFrancisco projects Warehouse Management

support in human resource scheduling see [12].• The book Surviving Object-Oriented Projects: A Manager’s Guide [13] deals with and is

complementary to many of the same topics addressed in this paper.• IBM’s WebSphere Business Components [14] are examples of Enterprise JavaBean components

developed using the process patterns described by this paper.• Products that help organizations more easily manage, search for, and distribute information about

software frameworks and components are entering the software marketplace. One example ofsuch a product is the Logidex Asset Library from LogicLibrary [15].

REFERENCES

1. Monday P, Carey J, Dangler M. SanFrancisco Component Framework: An Introduction. Addison-Wesley: Reading, MA,1999.

2. Carey J, Carlson B. Framework Process Patterns: Lessons Learned Developing Application Frameworks. Addison-Wesley:Reading, MA, 2002.

3. Gamma E, Helm R, Johnson R, Vlissides J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley: Reading, MA, 1994.

4. Beck K. Extreme Programming Explained: Embrace Change. Addison-Wesley: Reading, MA, 2000.5. Jacobson I, Booch G, Rumbaugh J. The Unified Software Development Process. Addison-Wesley: Reading, MA, 1999.6. Pree W. Design Patterns for Object-Oriented Software Development. Addison-Wesley: Reading, MA, 1995.7. Carey J, Carlson B, Graser T. SanFrancisco Design Patterns: Blueprints for Business Software. Addison-Wesley: Reading,

MA, 2000.8. Fayad ME, Schmidt DC, Johnson RE. Building Application Frameworks: Object-Oriented Foundations of Framework

Design. Wiley: New York, NY, 1999.9. Fayad ME, Schmidt DC, Johnson RE. Domain-Specific Application Frameworks: Framework Experience by Industry.

Wiley: New York, NY, 1999.10. Fayad ME, Schmidt DC, Johnson RE. Implementing Application Frameworks: Object-Oriented Frameworks at work.

Wiley: New York, NY, 1999.11. Ralph Johnson’s frameworks home page. http://st-www.cs.uiuc.edu/users/johnson/frameworks.html.12. Jaufmann E, Jr, Logan D. The use of IBM SanFrancisco’s core business processes in human resource scheduling. IBM

Systems Journal 2000; 39(2):285–292.13. Cockburn A. Surviving Object-Oriented Projects: A Manager’s Guide. Addison-Wesley: Reading, MA, 1998.14. IBM Corporation. WebSphere business components Web site. http://www.ibm.com/software/webserves/components.15. LogicLibrary Web site. http://www.logiclibrary.com.


lessons learned becoming a framework developer

Documents