yQII..... H. KanuIthRuth E. Smllan

J..n G. Smith

Reaping Benefits WithObject-Griented Technology

Object-oriented technology (DOT) hasbeen avaluable assettoourproductdevelopment cycle. It resulted insignificant reuse ofcode, design, and anal­ysis; reduced development cycles; simplified system integration; and a moreefficient method ofgenerating and using requirements. By incorporatingmanageable pieces ofDOTinto ourdevelopment process, a few techniquesat a time, we have been able tolearn about it, introduce it ata manageablerate, and still meet ourcustomer commitments without asking for additionalresources for DOTwork. Our developers and system engineers continue toincorporate DOTtechniques into theiranalyses, designs, implementations,and testing, and look for new areas to enhance ourexisting paradigm. Thispaper is for project managers, architects, system engineers, and developerswho areusing, or areconsidering using, DOT. Our methods can be used inotherprojects to shorten the development cycle and enhance product quality.

IntroductionFor the last five years, the Call

Attempt DataCollection System (CADcs)development grouphas been usingobject­oriented technology (OOT), a product devel­opment methodology that uses object princi­plesrather than traditional datastructuresand procedures. The benefits ofOOThavebeen reduced product development time,increased design andcodereuse,analysisreuse,and improved quality. Three majorareasaddressed in this paperare:- A development approach using OOT-How

OOTwasintroduced andsupported inourproject development cycle.

- Object-oriented requirements-How CADCSrequirements shifted from prose, functionalrequirements, to object-oriented require­ments, andhowthe format and methodol­ogyweredefined to produce them.

- A new project startup based on CADcs-Howthe project wasextended intonewapplica­tionareas,anda new service managementsystem wasdelivered ineightmonths.

CADeS BackgroundCADCS provides a set ofcapabilities

forAT&T customers to monitor traffic intheir SOO-Service networks. It collects,

processes, anddelivers dataassociated withcallattempts on 800 numbers. Real-time datais delivered througha computer-based graph­icalinterface, andhistorical datais deliveredthrougha computer-based ASCII interface, orbya printer. The service capabilities also areusedby internal AT&T support organizationsforservice andsystem management

CADCS consists ofabout350,000 linesofcode (C++ andother languages) that runon a central processor, and 100 remote sys­temsdistributed acrossthe United States andinterconnected via an X.25 packet network.CADCS wasfirstreleased in October 1990,with subsequent releases delivered every sixmonths. Twenty-five developers andfour sys­tems engineers are responsible forthe plan­ning, feature requirements, architecture,development, systemtest, andfield supportfor CADCS. While the systems engineeringanddevelopment groupsare separated geo­graphically andorganizationally, wewereableto refine our object-oriented techniques inastable, friendly environment.

Development Approach usa.., GOTThe CADCS development paradigm is

a mixture offunctional andobject-orientedapproaches that has evolved overthe pastfive

14 AT&T TECHNICAL JOURNAL • SEPTEMBER/OCTOBER 1993

Some teamscrossorganizational boundaries toinclude system engineers, developers, andtestersforsystem release planning, architecture definition, systemintegration, andsystem verification.

Project ......ement. Weplanned DOT work aspartofthe overall system design anddevelopment pro­gram. An incremental development strategy wascreated,including well-defined schedules anddemonstrationsthatweretracked with other project deliverables. Ini­tially, DOT wasconsidered a risk item, and managed sothat it didnotjeopardize project commitments. Alongwith DOT, westrongly feel otherquality practices, such

Panel 1. Acronyms andTerms Used In This Paper

Abstraction - Atechnique that talksabout functionsanddatain higher-level terms inorderto dealwithcomplexity.

ASCII - American Standard Code forInformation-----------------------1 Exchange

C++ - Programming languageCADCS - Call Attempts DataCollection SystemCASE - Computer-aided software engineering, a gen­

erictermforsoftware tools that support a specificway ofdocumenting a process.

Class design - The software representation ofanobject

Common class- Ageneralclassthat is usedbymul­tiple applications.

Containment - The incorporation ofoneobjectwithin another.

Inheritance - The technique bywhich the key, oressential, elements ofan implementation canbe"inherited," or reused, byobjects derived from anabstractobject

Invocation - The ability ofoneobject or codeseg-mentto call on a behavior, or method, ofanobject

MR - Modification requestNVf - Network verification testOOA - Object-oriented analysisODD - Object-oriented designoOP- Object-oriented programmingOOR - Object-oriented requirementsDOT - Object-oriented technology, a technology in

which oneworks with objects, wheredatastruc­tures andbehaviors or services are incorporated,as opposed to the traditional datastructuresandassociated datamanipulation routines.

PCS - Personal communications servicesPSMS - PCS service management systemSMS - Service management systemSQL - Structured querylanguageX.25 - CCITT packet protocol

years. 1 Wegenerally have followed a bottom-upapproach forDOT, replacing functional, traditionalapproaches with DOT at low-level design and program­ming stages, andthen extending the use ofDOT tohigher-level designs and requirements definition. Bycarefully choosing the areaswewould addresswith DOT,avoiding toomuchnew technology (and risk), and moni­toring the overall development cycle, wehave success­fully managed its introduction andgrowth while meetingourproject commitments.

Transltlonl", from Functional to OOT Methods. Thepossible combinations ofmethods that canbe used in dif­ferent phasesofthe development cycle are shown inTable 1.

Atproject startupin 1988, wefollowed a tradi­tional operations-systems development paradigm, withfunctional requirements, architecture, and high-level sys­temdesign (line 1ofTable1).Anobject-oriented pro­gramming (oor) approach wasintroduced intothedetailed design and implementation phaseofour initialsoftware release (line 3).Over the nextsixCADCS soft­ware releases, wegradually became C++/object-orienteddesign experts.

Wethen concentrated on the performanceaspects and ODD reuse,as weenhanced our use ofODDand oOPin detailed designs and implementations, andused ODD andobject-oriented analysis (OOA) in highlevel designs (line 4). In the mostrecent release, a teamofdevelopers andsystem engineers wrote object­oriented requirements (OOR) , therebycombining thesystem engineers' requirements phasewith the develop­ers' object-oriented analysis phase (line 5).

Figure 1shows this DOT evolution-how welearned aboutan DOT area; how weincorporated it intoourmethodology; how webecame proficient at it; and,finally, wherewetackled a new areawith DOT.

SInaII T....... The use ofa small-team approachonCADCS has enhanced our use ofDOT techniques byfacilitating information sharing, and providing a forumfor teamownership ofissuesanddecisions.

Within the development group, teamsoftwo tofive people wereset up to decide aboutsystemdesign,class design, reuse,methodology, common classes, etc.Theteams cover common-elass development, applicationand feature development, database work, anddatacom­munications. Theyhave cleargoalsanddeliverables, anddocument their resultsvia manual pagesand methodol­ogy guidelines.

AT&TTECHNICALJOURNAL. SEPTEMBER/OCTOBER 1993 15

Table I. Alternatives for requirements and development methods

line Requirements Ana1ysis Design Implementation

1 Functional Functional Functional Functional2 Functional Functional Functional OOP

3 Functional Functional OOD OOP

4 Functional OOA OOD OOP

5 OOR/OOA OOD OOP

as best current practices (BCPs), mustcontinue to beused. Booch2 cautions project managers, saying 'TheuseofObject-Oriented Design doesn'tgive onethelicense to abandon the established practices ofqualityassurance."

Bycheckpointing our development progressmonthly, wereestimated OaT work, along with other pro­jectwork, to keep us on an achievable schedule. Some­timeswelowered the priority ofOaT work whenotherhigher-priority items wereinconflict. Ourincrementalapproach andfrequent demonstrations provided ways ofseeing early resultsofthe working system-as well aspotential problems. In every CADCS release, timeandquality commitments have been met.

Method.. When webeganlooking at OaT forCADCS, our process and methods weredefined at a highlevel. The teamsknew, generally, whatwasgoingon andunderstood their roles. Asnewpeople joined the group,the methodology document wasoneofthe firstthingstheyread.

Currently, development methodology (seeFig­ure 2) includes:- Working with system engineers to produce OaR,- Transitioning from OaR to produce development

objects, andcentralizing the listofobjects andtheirresulting classes,

- Establishing conventions forstyle, design, andclassdocumentation, suchas manual pages, and

- Forming object teamscomposed ofdesigners, devel­opers, andapplication users to define the classfunc­tionalities needed in the various objects.

The object teamsthen prepare manual pagesfor theclasses, so that application developers can proceed whilethe classes are codedand tested. Mer a classis testedandenteredin a library, it canbe used in the application.Atthe sametime, non-C++/non-object-oriented develop­mentalso proceeds.

16 AT&T TECHNICAL JOURNAL • SEPTEMBER/OCTOBER 1993

GuidelinesGeneral guidelines that werefollowed forusing

OaT to develop CADCS are discussed.Common c.... Development. Initially a few

domain-elass developers tookon the taskoflearningaboutOOD, and theysupported the team'sapplicationdevelopers as the lattertransitioned to OOD techniques.Wefocused on a core set ofcode, central to all partsofthe system, because codereuse wasoneofthe mainbenefits to be achieved withOaT. By defining this teamat the beginning ofthe development process, along withthe responsibility ofdefining common classes, classreuse wasenforced. Now, common-elass development isre-examined as the features are analyzed bydevelopersat the beginning ofeachrelease. The domain-elass devel­opersfocus efforts on:- Performing object-domain analysis ofthe system to iden­

tify common classes, then building common/abstractclasses that canbe usedbymultiple application develop­ers.These are general-purpose objects within our prob­lemdomain. Examples ofproblem-domain classes aredialed numbers, service type, andareacodes-commonobjects at the heartofthe system.

- Providing gooddocumentation bymaintaining manualpagesanddesign documents, soliciting feedback fromthe application developers, andestablishing smallteamsofusers that review andrevise the documents.

- Implementing keypartsofthe domain/commonclasses earlyin the development cycle. Thispermitsapplication developers to use working code. Thesekeypartsare identified jointly bythe common-elass devel­opment teammembers andthe application developers,so deliverables are understood bybothgroups.

AppIIc8tIon DesIin end Development. The applica­tiondevelopers focus their efforts on:- Deciding how much object-oriented design theywant

to handle, andwhentheyshould use functional-design

• Leam c++ • Developclasses • Heavyreuse of C++ components.u~++ • Use encapsulation • Test for performance

as tterC • Use simple Inheritance • Usetemplates• Writesimple • Some abstraction • Use multiple inheritanceprograms

• Reusea few C++ com~~ments(maps, lists, stopwatc • etc.)

OOP

000

OOR

Newproject

• Some domain analysis .• DefInemethodology• Build domain library• ProvIde C++ interface (wrappers)

• Do moreOOA• Designreuse• Class reuse in design• Use some notations in design

documents

• Do upfront domain analysis• DefInemethods and formats• produ~60R

• Reuseplatform• Reusedesigns. methods• Do 00 consultation

Figure 1. Object­oriented technology(DOT) was Introducedover a four-yearperiod by the devel­opers, starting withhigh-level tutorials In1989, and progress­Ing In an Incrementalbut systematic wayuntil the project wascompleted In 1993.The developers gar­nered enough exper­tise In this time thatthey were able toreuse much of theirwork on a new pro­ject starting In 1992.

1989 1990 1991 1992 1993

techniques. Initially, the application developers usedC++ as a better C,moving overtimeto the moreexten­sive use ofabstraction, inheritance, and 000. Attimes,a functional designand implementation makesmoresense for somefeatures and,as a result, not allofCADCS is designed and implemented usingDOT. Forexample, the user interface wasdesigned usinga func­tional approach and implemented usinga vendor­supplied fourth-generation language, and shellscriptsare used formany ofthe maintenance tools. (AlthoughC++ or other object-oriented languages may notbeavailable, onecan still use 000.)

- Working with the common-elass developers to identifyclassfunctionality, which is neededearlyto developworking prototypes.

- Designing processes, as well as classes. There are twomain areas ofdesign: classdesign and processdesign,or systemarchitecture. AsDOTwasapplied to classdesign, processdesignusingcommon andapplication-specific classeswasdoneinparallel, usingthe traditional, structureddesign paradigm.

Education. Werecognized early on that weneeded a set of required coursesand timeallocated for

teammembers to attendthem. Inaddition, as this is acomplex paradigm, andongoing education is needed touse it effectively, wecreatedan education committee thatorganizes talksanddiscussions on C++ and DOT.

De......... Code ReYlew.. These reviews are veryuseful to share knowledge; incorporate code, design, andanalysis reuse;learnsubtleaspectsofC++; andfocus onstandard approaches for000. The reviews serveas ameansofextending classroom knowledge to experience­basedlearning. Reviews and inspections promote team­work, resulting in better designswith fewer iterations indesign andcodechanges.

c++ Cia.. Interfllce W...ppe,.. When external soft­ware packages are reused in CADCS, a C++ interface isadded, whenever possible, to take advantage ofC++ andDOTbenefits. Forexample, a thin layerofC++ classlibraries wasaddedon topofthe vendor-provided X.25library package. The interface provided a convenient wayofhidinglow-level details ofthe vendorpackage from theobject-oriented applications usedfordatacollection anddistribution. Another example is the SQL++ class,designed byanotherproject, which provides a genericinterface to a relational database.

AT&TTECHNICALJOURNAL. SEPTEMBER/OCTOBER 199:1 17

1

End-users,marketing, system engineers,

and developers provide00 requirements

Systemrequirementsspecifications

Feature team does2 domain analysis, identifies objects,

and defines abstract base classesand common classes

Common classes list andabstract base classes

Systemrequirementsspecifications

Architects, plannersdefine archtecture

High-levelprocess view

and architecture

3Object class teams

establish methods forclass development

Manualpages

Object class teams definederived class Interface

4

Manualpages

Developers implementnon-C++/non-OO applications 8

6 Developers implement and testclass libraries

DevelopersImplement applications

based on class interfaces andfunctional decomposition

5

Class Applicationlib code

Developers test7 complete application

with class libraries

Integration, system verification

Figure 2. Currently, the development methodology usedIncludes: Working with system engineers to produce object­oriented requirements (OOR); transltlonlng from OOR to pro­duce development Objects, and centralizing the list ofobjects and their resulting classes; establishing conventionsfor style, design, and class documentation, such as manualpages; and forming object teams composed of designers,developers, and application users to define the class tunc­tlonalltles needed In the various objects.

18 AT&TTECHNICALJOlIRNAl.o SEPTEMBER/OCTOBER 1993

C.... lnt...... for Interproce.. Communication. Oneofthe implicit rulesthat has worked well is process-to­process interfaces via a class-any datasharing betweenprocesses musthave a classwrapper around it.Thesewrappers, bybeingdefined as classes, helpensureaclean, well-defined interface, with the functionalityreusedon bothsidesofthe IPe, as well as in the testtools. Thishides the detailed information ofthe classimplementation from users.Where possible, we

recommend having a classinterface between anytwosystems sharingdata. Doing so reducesmisunderstand­ingsandfacilitates maintenance.

Dev.lopment EnvironmentSupport. C++ and 000tools are notas mature as those forC andstructureddesign. Since theyare still emerging, there weresomeproblems with compilers anddebuggers. Forexample,some debuggers didnotwork forlargeprocess sizes,andcompiler updates wereinconsistent with olderver­sions. Another areaofconcern is in recompiling off-the­shelfpackages usinga newC++ compiler. Some pack­ageshave notbeencertified usingthe C++ compilers.

Asa resultofthese issues, extra resources areneeded formanaging the development environment.Someone mustbe responsible forthe development envi­ronment, aware ofthe issues, available to helpotherswhen theyencounter problems usingthe tools, andresponsible forinvestigating, introducing, andupdating000 tools.

AppIlatlon PerfornuInce. The performance ofapplications is a prime concern, due to the real-timenature ofour system and the costofproviding the pro­cessing capacity for the system. Critical applications areprototyped, andperformance measured, to ensure thattheystaywithin acceptable limits.

Processes cangrowverylargewhen weincludelarge C++ libraries, which can result in performanceissuesdue to process swapping. Asa result, weneededtofine tune someprocesses. Unlike Cfunctions, in C++you cannot choose subsetsofthe class/objectlibrariesthatare ofinterest. Instead, youhave to include thewhole classhierarchy defined in the library.

Performance implications ofan object mustbeunderstood before reusingthe object forpurposes otherthan itsoriginal intent. Sometimes, it is desirable to builda new object with less performance overhead, ratherthan reusingan existing object with unusedfunctionalityand performance overhead.

B.nefIts of OOTByusing OaT, CADCS has realized the benefits

discussed below:Reduced Dev.lopment Cycle. Development esti­

mates have been reduced byoneto two weeks per fea­ture, in many cases,whereaverage feature developmentsrunin the three-to-six month range. Much ofthe savingscomes from reuse ofexisting designs andclasses. Inte­gration testingshows significant savings-features fall

togethernaturally, sinceunderlying classes are sharedbetween interfacing processes, andclasses have beenextensively testedbefore reaching integration. In all ofour releases, integration andsystem-verification handoffshave occurred on time.R..... Outof492 classes developed in CADCS,190 (38%) are common classes thatare reusedin morethanonesoftware subsystem. With a richset ofclassesavailable to application developers, the application teamscontinually incorporate 000 within allCADCS mainlineapplications. The classes are generally straight-forwardto use,andcanbe extended to meetnew variationsneededbythe developers. Considerable reusealso ispossible fordesigns andrequirements, along with code.

Acaveat is in order.There is a cost involved infinding thingsto reuse. Searching libraries ofclasses todetermine whatis applicable andreusable cansome­timestake longerthanwriting a new class. Even withinsmall teamsofabout20developers, it is sometimes hardto keep upwith whatother subteams are doing to see ifthere are additional candidates forclassreuse. The con­ceptofa class librarian anda class browser might helpprovide even moreclassreuse.Oneperson could serveas the contact point as separate teamsidentify the needfornewclasses. The classlibrarian could determine ifothersalso have identified this need, therebymaking it anew common class. Or, if nooneelsehadyet identifiedthe need,the librarian could use expertjudgment todetermine if it should be a common classand, if so,per­haps identify additional member functions to make itmoregeneralpurpose.

R.slilence to C........ When good class definitionsare createdand developed, the system seemstogrowgracefully-new features tendto follow the samesystemflows, andare ableto reuse existing designs andclasses.

Forexample, as the CADCS service grew, newservice typeswereadded to our customer records, andthe systemrequirements forareacodeswerechanged.Because these changeswerelocalized to objects, wecould accommodate the modifications ina straight­forward manner, without causing ripple effects.

F.w.r Modlllation Requ.sts In OOT Area.. Sinceworking codeis used, rather thannewly developed code,many bugscanbe eliminated throughcodeanddesignreuse.Commonality in design approaches also leadstomorestandard interfaces andanticipated behaviors,resulting in fewer coding problems.

In our mostrecentrelease, the number ofbugs

AT&TTECHNICALJOURNAL. SEPTEMBER/OCTOBER 1993 19

Table II. Rle types and files modified

Total # % ofTotal # of Modified % of ModifiedFile Type Total KLOC of Files Files Files Files

c/cH mainline 131 1125 36 24 8c/c-« ui 24 65 2 36 11shell 60 466 15 43 14fonns/ui 44 768 25 183 58other 118 690 22 28 9

total 377 3114 100 314 100

found in our network verification test (NVf) phase (fieldtestingthat occursaftersystemtestingis completed)wasanalyzed. Testers created78modification requests(MRs) in two monthsofNVf testing. Asa resultoftheseMRs, developers modified 314 files. Only 8% ofthesemodified files wereC/C++ files in the mainline process­ing. This file-type breakdown is shown inTable2.

Most (81%) ofthe files modified duringthis test­ingphasewerein shellscripts, user-interface forms, anduser-interface supporting code. OaT techniques were notapplied either in designing andcoding shellscripts, or inthe codeimplemented in user-interface languages. Theuser interface is a complex area,and many changesarerequired late in the development cycle, as user needsbecome better known. Certainly not allmodifications areattributable to the structured/functional design para­digm, but it is reasonable to assumethat this section ofcodewould be morebug-free, and easier to maintain, ifit had been designed and implemented usingOaT.

Object-Grlented Requirement.The mostrecent OaT changeon this project

was the incorporation ofOaT intothe requirementsphase. Ourgoalwasto facilitate the processofproducingrequirements that are easyfor systemsengineers towrite and developers to understand. The requirementsmustbe complete, precise, andfacilitate the transitionfrom requirements to design.

The term "object-oriented requirements" canhave several interpretations. Whatmany people mean,whenreferring to object-oriented requirements, is thenotation neededto transition from functional require­mentsto object-oriented design. Forexample, Bailin3

describes "a method ofanalyzing requirements forobject-oriented software." That is notwhatwemean.

20 AT&TTECHNICALJOURNAL. SEPTEMBER/OCTOBER 1993

Wemean writing the requirements specification in theform ofobjects, so that no transition is needed from textrequirements to object-oriented design.

The main triggerin moving us toward object­oriented requirements wasa new set ofreporting features.Froma marketing and systems engineering point ofview,the features wereindependent features, separate fromeach other, sincetheywereused fordifferent types ofcus­tomers. Butfrom a development point ofview, there wasconsiderable software commonality among the reportingfeatures. It wasdifficult to find this commonality in thefunctional requirements, and it took a major effort to shiftfrom requirements to design. It was this difficulty that ledto the ideaofusingobjects forrequirements. It becameclearthat byusingobjects, synergies among featurescould be discovered earlyandused to advantage.

The experience motivating us to do OaR wasapowerful demonstration ofBerard's observation that, "Afunctional decomposition 'front-end' to an object-orientedprocess, in effect, breaksup objects and scatterstheirparts. Later, these partsmustbe retrieved and relocal­ized around objects."! Also, by usingobjects in require­ments, reuse could apply whenwriting requirements,both within a releaseacrossfeatures andfrom onereleaseto the next. Refer toIordan! formoredetailsaboutthe format, methods and benefits ofobject­oriented requirements.

OOR Guideline.This section describes someofthe guidelines

used to produce our first OaR.System Englnee.....-Dev.lopers Team. The shift to

the newrequirements format followed a number ofmeet­ingsbetween the systemsengineers anddevelopers.Using the project's existing base ofobject-oriented

The "Status" field indicates whetherthis is a newobjectinthis release, or an object modified from a previousrelease, to aid in reusingobjects across releases. A"Par­ent Of' field wasinitially defined to indicate the

techniques, methodsweredefined. Ahierarchical listofrequirements objects in the existing systemwasdefined,sowecould allunderstand whatwasmeantby require­mentsobjects.

Requirements objects are basically real-worldobjects, not design or programming objects. It is impor­tantto notethat designis not specified in the require­ments, and that requirements objects do notalways mapdirectly to programming objects. Requirements objects,suchas a telephone switch or a report, are in the prob­lemdomain. Programming objects, such as a listor mes­sagequeue, are in the solution domain. Thus, require­mentswritersdo nothaveto become object-oriented pro­grammers, but do haveto learnhowto describe the realworld in terms ofobjects.

OOR Methods. Methods and formats werecre­ated, rather than relying on a CASE tool. Thiswasdoneforthree reasons. First, it meantboth verylow overheadanda smallleamingcurve. Second, wewanted to takeadvantage ofthe OOD workthat already existed in thedevelopment community, and to extendthis to therequirements phase. Third, it saved timeand,basedonprevious studies, object-oriented CASE supportis stillsomewhat newand limited.

Requirements Document Fonnat. Ourformat isbased on the classresponsibility collaborator cards(CRe),6 with extensions defined for inheritance, contain­mentand invocation. Two templates weredefined forrequirement objects, one foran object definition and onefor eachobject responsibility. An object has onedefinition, and usually morethan one responsibility.Each responsibility defines a specific requirement. Thedataand related functions are tied togetherby the objectname field ofthe two templates.

An object definition consistsofthe followingdata:

Object:Definition:Status:Child Of:Contains:

Name ofobjectAone-line descriptionNew or existingAny parent (inheritance)list ofobjectswithin this one

inheritance relationship, but wefelt it would taketoomucheffort to keep this up to date. It alsois redundantwith the "Child Of' field.

An object responsibility consists ofthe followingdata:

Object: Name ofobjectAbstract: One-line abstractofthis responsibilityResponsibility: The detailed requirementCollaborator: Otherobjects invoked, ifanyInvoked By: Object(s) calling this responsibility

Bywriting requirements within the context ofobject templates, a precise language is imposed upon therequirements. Bailin3 suggestsusinga requirementsdatabase as a starting point ofidentifying problem­domain objects, rather than starting with text require­ments. Hedefines a requirements database as "distillingthe original textual statements intoa set oftraceablerequirements." Our OOR serveas botha requirementsdatabase and the complete set oftraceable requirements.

Benefits of OORAfter the first cycle with OOR, weidentified sev­

eral benefits. Further use ofOOR and metrics are neededto quantify these results, particularly in the areasofreuse and resilience to change. The benefits are:

Complete..... The requirements were morecomplete, sincequestions wereaskedas requirementswerewritten. For example: Whatobject invokes thisrequirements object? Whatobject does it collaboratewith to get itsjob done?

Communication.. OOR improves communicationsbetween the systemsengineers and the developers. Thisleadsto a better understanding ofthe requirements, astheyare beingwritten, and provides developers with ahead start on the design/development phase.

Reduced Cycle Time. OOR resulted ineliminatingthe paradigm shiftbetween the requirements phaseandthe development phase. Berard! notesthat,"There havebeen quitea numberofattempts to reconcile the outputofa non-object-oriented processwith the input require­mentsofan OOD process... noneofthese scenarios are asclean and easyas usingan object-oriented approach fromthe verybeginning ofthe software life-cycle."

In previous releases, the end ofthe require­mentsphaseand the beginning ofthe development

AT&T TECHNICAl. JOURNAL. SEPTEMBER/OCTOBER 1993 21

Reuse level

~II)

'Eo(Jl;::

'~Ulc::'n;E8

Select CADCS applications PSMS application

PSMS class libraries

CADeS class librariesSQL++, X25 class, domain, error, trace

External AT&T AT&T AT&Tvendors database BaseWorX communicationproducts products products products

UNIX-

, - ... -

H8nIWn pIetIormIi

IL _

Rgure 3. This illustration shows the architecture layers Inthe PeS service management system (PSMS) product, builtusing the CADCS core functionality. By using the CADCS classlibraries, PSMS was able to reuse the same lower layers ofthe CADeS system, such as extemal vendor products,BaseWorX, etc. New layers were added, of course, In thedomaln-speclflc PSMS application layer and clas..lbrary layer.

phaseweremarked by whatwascalled a "conceptualdesign review." Whenthe requirements werecomplete,the developers reviewed them and produced a high-leveldesign ofthe system, incorporating the newfeatures intothe existing design. The developers and systemsengi­neers then met to review this design.

Byusingobject-oriented requirements, the con­ceptual design review stepcould be eliminated. Devel­opersweremoreinvolved with the requirements as theywerebeingwritten. Bothgroupsagreedonwhattherequirements objects werebefore the requirements werewritten, so there werefew surprises in the finalspecification.

In comparing the development cycle timesforthe last two releases, and normalizing the data to takethe releasesizes intoaccount, wefound an:- 8% reduction in requirements time,- 30% reduction in requirements staffeffort,- 30% reduction indevelopment time, and- 20% reduction in development staffeffort.

Reu....... R.slilence to e........ Oneofthe pri­mary obstacles inwriting requirements is the instability

within the customerbase andfeature-set base.Alotofinformation aboutcustomers andfeatures is notavailableat the start ofa releasecycle. This causesa tremendousamountofchum while writing requirements, reviewingrequirements, and startingdevelopment. The reuseofobjects should helpas feature sets shiftduring a release.

General requirements objects should be abletobe reused from one releaseto another. There are baseobjects that pertain to the systemingeneralthat willspanreleases. Also, per-feature requirements objectsshould be reusable as features are enhanced insubse­quent releases.

New Project StartupAfter applying OOT to the product development

cycle through several releasesofCADCS, wehad an oppor­tunity to apply this experience to building a newsystem. Itis interesting to see howmuchofthis experience, as wellas the assets,such as sourcecode, tools, processes, anddocuments, could be leveraged in this effort.

The result is a PeS Service Management System(PSMS) for the Personal Communication Services (pcs)Business Unit. Wehad eightmonthsto define require­ments, design, develop, andverify the system, anddeliver it to first-office application testing. The firstreleaseofthe PSMS system consisted ofabout160,000linesofapplication code (C++ andothers) that ran on acentralprocessor. In addition to this delivered applica­tioncode, we integrated intothe system packages ofthird-party vendors. Ateamof12developers was

22 AT&TTECHNICALJOURNAL. SEPTEMBER/OCTOBER 1993

Table III. PSMS class reuse and new development

Description CADCS Reused Modified Developedclasses as is reuse new

Domain specific classes 302 4 7 47Common classes providing func- 190 49 5 13tionality such as networking, errorhandling, and DB access

Total classes 492 53 12 60

C++ NCSL (out of lOOK total code) 25K 5K 27K

responsible forthe architecture, design, development,and system verification ofthe PSMS system. Wemet ourgoal ofdelivering a high-quality systemon time, whilespending less than the allocated budget. To summarizethe keyingredients ofour success inone sentence, wereused the assets from CADCS bystrategically includingreuse in the PSMS development plan.

Startup Guideline.Some ofthe startupsteps that wetookfor the

new project included:Plenned Reu... McClure points out that one of

the reasonsfor limited success insoftware reuse acrossprojects is a lackofup-front planning for reusability. 7

From the conception ofthe PSMS system, reuse wascon­sidered strategically requiredto meet the costandschedule demands ofthe customer. Because the PSMSdevelopment wasstartedwith a few seed developersfrom the CADCS project, several forms of reuse occurred.Thisreuse includes CADCS hardware and base softwareplatform, the CADCS user interface package andgeneralapproach, the development environment and methods,application sourcecode (C++ andother languages), anddesign ideas. Also, we reused the test tools and test envi­ronment, systemverification approach and tools, internaldocumentation formats and templates, external user doc­uments and procedures, project management tools andtechniques. In addition, wewereableto takeadvantageofstaff and first-line manager continuity.

All of these areas ofreuse contributed to produc­ing a high-quality systemon a tight schedule.

Softw.... Reu.....llty. Figure 3 shows the architec­ture layers in the PSMS product, builtusingthe CADCScorefunctionality. New layers wereadded in the applica­tion layer andclass-library layer. Byusingthe CADCS

classlibraries, PSMS wasableto reuse the samelowerlayers ofthe CADCS system, such as external vendorproducts, BaseWorX, etc.

The CADCS and PSMS applications have some sim­ilarities but, from a functional viewpoint, theyare verydifferent. By focusing on underlying similarities thatwould apply formostoperations systems, suchas systemadministration, datacommunications, eventreporting,and reportgeneration, muchofCADCS software wasreused.Differences werelocalized to the application andclass-library layers. Here, PSMS software supports provi­sioning, billing-data processing, andservice-data analysisfeatures, in lieuofCADCS features, such as real-timegraphical statusdisplays andhistorical reports.

Instead ofcreating one largelibrary, CADCSdevelopers grouped objects intospecific libraries,depending upon the natureofthe workthe objects per­formed, such as an X25-class library forgeneral-purposecommunications, a SQL++ classlibrary forvendor data­baseaccess, anda CADCS domain classlibrary fortheapplication-specific objects. Asa result, it was easyforthe PSMS project to pick upwhatwasneeded. Reuse canbe maximized if objects are moregeneral, andare pack­agedso that other projects havethe flexibility to pick andchoose. Reuse should be basedupon a choice oflibrariesand components, as opposed to an all-or-nothing basis.

Asa measure ofclassreuse,Table3 shows thenumberofclassesthat werereusedwith andwithoutmodification from CADCS, and the numberofnewclassesdeveloped in PSMS.

Notice that as the objects become moredomain­specific, less reuse occurs, as is shown in the pyramiddiagram. Efforts should be madeto push the classlibraries down in the hierarchy to maximize reuse. Wealso can see that 52% ofthe PSMS classescame from

AT&TTECHNICALJOURNAL. SEPfEMBER/OCTOBER 1993 23

CADCS, many from the lower levels ofthe hierarchy, suchas error handling, database access, etc.

quality, Cost, and SChedule•• Software andmethodology reuse has resultedina quality productdelivered ina short timeframe. The modification requestdensity, that is, the numberofMRs per kilo-lines ofcode,was calculated to be less than 0.1%. This rate is muchlower thanweprojected, basedon the CADCS project.While the entire reduction cannotbe attributed to OOT, itseemsto haveplayed an important role.

The PSMS development teamestimated that hadthe PSMS been developed from the groundup,and notbasedon CADCS, it would havecost 1.8-2.2 more inbud­get and 1.5-2.0 morein development time. The generalconsensus wasthat planned reuse resulted not only insavings in development effort, but alsoin integration andtestingefficiencies, leading to an overall cycle reduction.OOTeased the modification and reuse ofexisting CADCScodefor PSMS, allowing us to leverage the technologyinvestment ofCADCS inbuilding PSMS.

ConclusionsMany projects ponderthe question ofwhetheror

not to get intoOOT. The experience described in thispapermay helpanswer someofthe questions. OOTdoesnot solve allofthe problems ofsoftware developmentand project management. Forexample, people issuesandquality assurance remain outside the scope ofOOT.Butby introducing a few techniques at a time, and treat­ingthem initially as risk itemsthat need to be managed,wehave been ableto learnaboutOOT, implement it at arate the teamwascomfortable with, and meetour com­mitments without askingforadditional resources.

OOTcanbe practiced at a low costwithout usingcommercially available CASE tools. Asmall, empoweredproject teamdefined a methodology that the projectcould handle, and then implemented it.Our OOR methodis simple and straight-forward to use with UNIX tools.

OOThas been a valuable asset to our productdevelopment cycle, resulting in significant reuse. How­ever,reuse has to be a project norm-planned from thebeginning-and reuse canapply to muchmorethansourcecode.

Weare glad that wetookthe riskof introducingOOTinour product development cycle. Our developersand systemsengineerscontinue to use it, andwebelieve

24 AT&TTECHNICALJOURNAI.• SEPTEMBER/OCTOBER 199~

these methods canbe used inother projects to improvethe development cycle andenhance product quality.

References1. Kamath, Y.H. andSmith, ].G.,"Experiences in C++ andObject­

Oriented Design,"Journal ofObject-oriented Programming,Nov.-Dec. 1992.

2. Booch, G. Object-Oriented Design with Applications,Benjamin/Cummings Publishing Company, Redwood City. Califor­nia,I990.

3. Bailin, SC, "Object-Oriented Requirements Specification Method,"Communications ofthe ACM. May 1989, pp.608-623.

4. Berard, E.V., Essays onObject-oriented Software Engineering Vol­ume1,Prentice-Hall. Inc.1993.

5. Jordan,R.D., Smilan, R.E., Wilkinson, AC., "Accelerated ProjectCycle Using Object-Oriented Requirements," AT&T Software Sym­posium, Oct. 1993.

6. Beck, K and Cunningham, W., "ALaboratory forTeaching Object­oriented Thinking," OOPSLA-89 Proceedings.

7. McClure, C. The Three RsofSoftware Automation, Re-Engineering,Repository, Reusability, Prentice Hall, 1992.

(Manuscript approved November 1993)

Yogeesh H. Kamath is a distinguished member of technicalstaff in the Network Management System Development Divi­sion at AT&T Bell Laboratories in Columbus. Ohio. He isresponsible for the planning and development of ServiceManagement System (SMS). He has a B.E. degree in electron­ics and communications from the University of Mysore inMysore, India, and an M.S. degree in computer science fromthe University of South Carolina in Columbia. He joined thecompany in 1986.Ruth E. Sm/lan is a member of technical staff at AT&T BellLaboratories in Columbus, Ohio, and is a software developeron the Call Attempts Data Collection System (CADeS) Team.She joined the company in 1983. She has a B.S. degree andan M.S. degree in computer science from Ohio State Univer­sity in Columbus.Jean G. Smith is a technical manager in the Network Manage­ment Systems Development Division at AT&T Bell Labora­tories in Columbus, Ohio. She manages the Service Manage­ment System (SMS) project. She has an M.S. degree in com­puter science from Rutgers University, New Brunswick, NewJersey, and a B.S. degree in mathematics from Ohio Univer­sity in Athens. She joined the company in 1972.