ios press managing scientiﬁc software complexity with

Scientific Programming 16 (2008) 315–327 315DOI 10.3233/SPR-2008-0270IOS Press

Managing scientific software complexitywith Bocca and CCA

Benjamin A. Allan a,∗, Boyana Norris b, Wael R. Elwasif c and Robert C. Armstrong a

a Sandia National Laboratories, Livermore, CA, USAb Argonne National Laboratory, Argonne, IL, USAc Oak Ridge National Laboratories, Oak Ridge, TN, USA

Abstract. In high-performance scientific software development, the emphasis is often on short time to first solution. Even whenthe development of new components mostly reuses existing components or libraries and only small amounts of new code must becreated, dealing with the component glue code and software build processes to obtain complete applications is still tedious anderror-prone. Component-based software meant to reduce complexity at the application level increases complexity to the extentthat the user must learn and remember the interfaces and conventions of the component model itself. To address these needs,we introduce Bocca, the first tool to enable application developers to perform rapid component prototyping while maintainingrobust software-engineering practices suitable to HPC environments. Bocca provides project management and a comprehensivebuild environment for creating and managing applications composed of Common Component Architecture components. Ofcritical importance for high-performance computing (HPC) applications, Bocca is designed to operate in a language-agnosticway, simultaneously handling components written in any of the languages commonly used in scientific applications: C, C++,Fortran, Python and Java. Bocca automates the tasks related to the component glue code, freeing the user to focus on the scientificaspects of the application. Bocca embraces the philosophy pioneered by Ruby on Rails for web applications: start with somethingthat works, and evolve it to the user’s purpose.

Keywords: Code generation, software development environment, interface definition language, SIDL

1. Introduction

Software complexity has many measures. It can benaively quantified in terms of code measurements (e.g.,lines of code) or in the number of instructions neededto perform a defined task. Programmers today, how-ever, rarely create monolithic stand-alone programs;more often they find themselves contributing to a largerframework or runtime system. A better complexitymeasure in this case is the learning curve before theprogrammer can use the framework and contribute toit. Though hard to quantify, the intellectual cost oflearning a new framework can be greater than the valueof a programmer’s contributed code. Here we describea tool called Bocca whose main goal is to ease the com-plexity of developing high-performance software usingthe Common Component Architecture and automatingmany difficult and error-prone development tasks.

*Corresponding author: B.A. Allan, Sandia National Laborato-ries, 7011 East Ave., MS 9158, Livermore, CA 94551, USA. E-mail:[email protected].

1.1. The common component architecture

The Common Component Architecture (CCA) is acomponent model that admits and supports a modelfor parallel computing [2,3,14]. As a component modelCCA must mechanize linking together components atruntime without sacrificing performance. Among otherthings, this means that CCA must allow languages thatare associated more with performance than with easeof use – C, C++ and Fortran – and yet admit lan-guages more familiar to component computing, suchas Java and Python. Indeed, unlike most other com-ponent models, CCA eschews language details in itscomponent model, furnishing a connection mechanismbased on providing and using language-independentinterfaces (see Section 1.2). Two components can belinked when one component advertises that it can pro-vide an interface of a particular type for which anothercomponent advertises a need. Interfaces that are do-nated or imported in this way are called ports. A CCA-compliant framework keeps track of uses and pro-vides ports and takes care of transferring the port fromproviders to users (for more details see [2,7,10]).

1058-9244/08/$17.00 © 2008 – IOS Press and the authors. All rights reserved

316 B.A. Allan et al. / Managing scientific software complexity with Bocca and CCA

1.2. Scientific interface definition language and Babel

In addition to defining a design pattern for compo-sition, pragmatically a component model must be con-cerned about the mechanics of connecting the soft-ware together. Where performance is not an issue, con-nections can be made through a network line protocol(e.g., CORBA Component Model [16]). Another ap-proach is to require that the components be written ina particular language (e.g., Enterprise JavaBeans [8]).Neither of these options is open to the scientific com-puting developers of the Common Component Archi-tecture, requiring that it provide a language interoper-ability layer. This layer, called the Scientific InterfaceDefinition Language (SIDL) [15], is a specification fordefining interfaces that can be used to generate inter-operable code in a variety of languages. Babel [4] isthe SIDL interpreter that the CCA uses currently sup-porting Fortran 9X, Fortran 77, C, C++, Python andJava. Given a valid SIDL interface definition, Babelwill generate the skeletons (implementation side bind-ings) and stubs (calling side bindings) for any of thesupported languages invoking any other. An importantdifference between Babel and other language interop-erability tools (e.g. Simplified Wrapper and InterfaceGenerator, or SWIG [5]) is that Babel provides two-way invocation: each supported language can call orbe called by every other. Special care has been takenby the developers of Babel to reduce the performanceoverhead of using Babel to the level of a few functioncalls. Developers are thus free to create their compo-nents in the language with which they are most com-fortable and be certain that their work will be usableby other developers working in any of these supportedlanguages.

1.3. Bocca: A CCA component generator

The best description of Bocca is that it is an appli-cation generator or as described in this paper, a CCAcomponent generator. Armed with only the names ofcomponent and port types, users can create a completeskeleton application out of components in minutes.What Bocca does for the Common Component Archi-tecture is similar to what Rails does for Ruby-enabledweb applications (for more on this see Section 6).Bocca creates an entire application shell that runs outof the box and is ready for the programmer to insertimplementation code. It adopts the philosophy of ex-treme programming [6] that all working code comesfrom other working code. Bocca gives the program-

mer an entire application that is “close” to what iswanted. From there the code can evolve to what theprogrammer has in mind. Because Bocca provides thecomponent-oriented glue code and attendant build sys-tem, the programmer needs to learn only that whichdirectly impacts the application, and nothing else. Thevalue of Bocca is measured in the lines of code that theprogrammer did not have to write and, more important,understand. As we shall see in the following example,the savings, even for the simplest componentized ap-plications, are considerable.

The utility of Bocca can be illustrated by usinga simple example that generates the basic skeletonof a functioning application composed of two CCA-compliant components.

Figure 1 gives a quick demonstration of the powerand simplicity of Bocca. Line 4 creates a new projectcalled myProject by constructing a new directory bythe same name and importing the build system into it.Every command related to this project must take placeinside this project directory or one of its antecedents.In line 8 we create a CCA port type called myPort,which at present has no methods but is nonetheless avalid port. In lines 10 and 12 we create two compo-nents: Worker, which provides a myPort, and Driver,which uses it. The Driver component also provides aGoPort that provides a standard GoPort, which is theapplication entry point (similar to a traditional mainprogram). In addition to the port type myPort eachcomponent needs an instance name for the port to dis-ambiguate multiple ports of the same type on the samecomponent. Here Worker names its myPort “xport”because it is providing a myPort and Driver namesthe port it will use “wport”. We configure, build,and test the project with the configure, make, andmake test commands. At this point we have anempty “shell” components and ports that have no meth-ods or corresponding implementations but neverthelesscan be linked together and “run” as a complete appli-cation (see Fig. 2).

Componentizing applications is a way, possibly thebest way, to manage complexity and allows a largeproject to scale both in size and number of devel-opers. The component model itself, however, intro-duces a different type of complexity that does not ex-ist in noncomponent software. Part of the motivationfor Bocca was to overcome this learning curve by cre-ating a runnable template for a componentized appli-cation into which users can easily insert code. In thisway users can learn the component model incremen-tally and in steps that are most relevant to their imme-diate goals.

B.A. Allan et al. / Managing scientific software complexity with Bocca and CCA 317

1 # ! / b i n / sh2 # P r o j e c t C r e a t i o n3

4 bocca c r e a t e p r o j e c t m y P r o j e c t5

6 cd m y P r o j e c t7

8 bocca c r e a t e p o r t myPort9

10 bocca c r e a t e component Worker −− p r o v i d e s =myPort : x p o r t11

12 bocca c r e a t e component D r i v e r −−u s e s =myPort : wpor t −−go=GO13

14 . / c o n f i g u r e15

16 make17

18 # T e s t new p r o j e c t s k e l e t o n19 make check

Fig. 1. Simple Bocca project creation script.

Fig. 2. An empty “shell” application resulting from the commands given in Fig. 1 shown in the CCA GUI.

2. Attacking complexity

Scientific software development and maintenanceprocesses have several kinds of superlinear social andtechnical complexities that make them generally un-scalable in costs for very large projects. We aim, byproviding Bocca and CCA, to directly reduce severalcomplexities of software development processes by en-abling the following approaches:

• scientific language interoperability,• software componentization,• configuration management by default,• source code layout by default,• portability by default.

The complexity reductions our approach affordsare easily expressed with the following numbers:

NL (number of programming languages), NTLOC (to-tal lines of code), NSF (source file count), NIL (in-terface lines of code), NDEV (number of develop-ers), NPL (number of platforms), NAP (number of ap-plications), NC (number of existing code libraries),NSH (number of shells) and NCM (number of configu-ration management tools).

Combining codes from among the languages fre-quently encountered in scientific computing toolkits(C, C++, Fortran 77, Fortran 90, Fortran 2003, Pythonand Java) is an arduous task if done manually. Many(more than N2

L) incompatible, point-to-point tools ex-ist to handle particular pairs of languages. Our use ofSIDL and Babel reduces interoperability complexityfrom N2 to 1: The owner of a code writes the multilan-guage wrapper for that code in the same language afterspecifying the wrapper with SIDL.


Software componentization reduces requirementson mental information processing in three areas bystrictly enforcing conventions for public interfaces andprivate implementations of all functionality. We ob-tain this often promised but seldom delivered result be-cause a runtime framework is responsible for all inter-actions across component boundaries and it is difficultfor a component developer to understand private im-plementation of another component which is not in thesame language.

The first area of complexity reduced by Boccais manual code inspection. The quadratic potentiallybuggy (or low performance) interactions that must bemanaged decrease from N2

TLOC to N2IL when interface

discipline is enforced.The second area reduced is design time spent nego-

tiating interactions between existing codes when be-ing integrated into larger projects. The specification ofsmaller, language-neutral interfaces in SIDL focusesdiscussions away from NDEV ∗ NL ∗ NC shortcuts andtoward NIL lines of SIDL representing a maintainable,portable solution.

The third area reduced is coding custom initial-ization and launch processes on parallel platforms.NPL ∗ NAP such efforts are simply eliminated onceeach code is built of components and the problem oflaunching a generic component framework has beensolved for a given platform.

Configuration management is a necessary part ofscientific computing; since no operating system orcompiler vendor meets the evolving needs of all li-braries used in a portable application code. Manu-ally managing NPL ∗ NSH ∗ NCM compilation scriptswith source code variations is too much for scientistsand developers, who often do not even have access toone or more of the platform and compiler combina-tions on which the libraries they contribute must run.Through Bocca we reduce the build clutter by auto-matically providing autoconf and gnu make scripts forthese tasks, reducing NPL ∗ NSH ∗ NCM complexityto O(1) complexity. A key part of the provided buildsupport is that Bocca-built software can be automati-cally installed for production use following commonstandards. These standards make detecting the installedpackages much easier for downstream software builds.

Creating and editing files require social effort onlarge projects. Development effort can be lost if con-flicting changes are made in the same files. In the gen-eral case, there may be NDEV ∗NSF interactions. Boccaprescribes that separate components are kept in sep-arate directories. This approach provides strong hints

about intellectual file ownership and editing responsi-bility, reducing the likelihood of accidental losses fromconflicting edits of the same file. Also, this directorylayout allows those who wish to exchange code via tarfiles instead of the formality of version control to easilyexport just that piece.

3. Enabling rapid development

Our aim is to decrease to near-zero the time re-quired to define, build, and maintain the componentglue aspects of CCA applications. We designed Boccato capture knowledge about component enabled high-performance computing (HPC) applications and to usethat knowledge to automate as much as possible theprocess of application construction and maintenance.The information to be captured and managed fallsbroadly into three categories:

1. An application: a list of component instances,port connections, runtime input parameters, andcomponent installations.

2. The SIDL entities and the uses/provides designpattern that defines a given component. This in-cludes any external dependencies (typically li-braries) required to build the implementation.

3. The choice of build tools.

Our software design reflects the different types ofdata that must be managed (see Fig. 3). Developers canleverage their favorite existing tools to perform all thefunctions that are generic to component software de-

Fig. 3. Bocca design overview.


velopment: compilation, source code editing and ver-sion management, and execution of the completed ap-plications in some framework. Packagers and users ofthe resulting software package need have no knowl-edge nor installation of Bocca at all.

Bocca is constrained by the unique key requirementsof HPC software development, specifically, Boccamust do the following:

1. Function well in ill-defined development proces-ses where the project requirements rarely stabi-lize and where the participants are scientific ap-plications programmers rather than experiencedsoftware engineers. Iteration and evolution of ap-plication, interface, and component design mustbe supported.

2. Be inexpensive. Complex, unusual, or propri-etary software and expensive training prerequi-sites are not allowable.

3. Have low abandonment costs. The user must beable to trivially export individual components orentire applications as packages that may be con-figured, built, used and maintained as part oflarger, Bocca-free projects.

4. Remain fully functional in the spartan develop-ment environments typical for high-performancearchitectures. Production HPC environments fre-quently lack particular graphical tools, access toremote desktops, and the very latest versions ofcommon open-source tools.

5. Be queryable for syntax help and examples aswell as the current project state.

Our approach is to design a command-line tool, sim-ilar in look and feel to many version control systems.The tool performs various actions (e.g., create, re-move, rename) on a set of SIDL and CCA subjects(e.g., component, port, class, interface). All the SIDLdefinitions are generated by the tool once the user spec-ifies the desired type names, leaving the user to fillin domain-specific method names and implementationcode. Graphs (or trees) are a natural choice for orga-nizing SIDL entities and representing their relation-

ships. Specifics of these data structures are discussedin Section 5. A small language for describing applica-tion [1,3] construction from Bocca-generated compo-nents is discussed in Section 4.3.

For both maintenance and rapid prototyping, Boccahas sufficient project data to handle renaming or re-moving any SIDL entity and then automatically updateboth the user-customized sources within the projectand the noneditable Bocca-generated sources (see Sec-tion 5).

4. Code lifecycle management

The simple example presented in Section 1.3 illus-trates how Bocca can be used to rapidly build a func-tioning prototype of a component-based application.The true utility of Bocca lies in the ability to managethe complete life cycle of complex component-basedapplications. Such applications comprise the full rangeof SIDL entities interconnected by nontrivial inheri-tance and dependency relationships. Figure 4 showsthe different Bocca commands used to manage differ-ent phases in the lifecycle of managed code.

Bocca uses the project abstraction as the con-tainer for all code artifacts. As can be seen in Fig. 4,upon creation of an initial set of artifacts that reflectthe intended structure of the target application, the userthen goes into an update-query-refine cycle to fine tunethe application and add implementation details to thevarious code skeletons generated by Bocca.

4.1. Code creation

While the full description of Bocca command syn-tax and various options is beyond the scope of this pa-per, we nonetheless outline some major themes thatunderline Bocca’s utility as a rapid development envi-ronment and code maintenance and management tool.Details can be found in the CCA Tutorial Hands-OnGuide [9].

Fig. 4. Code life cycle management using Bocca.


Extensive use of defaults: Bocca uses default valuesfor many aspects that define created code arti-facts. For example, the programming languagespecified at project creation time becomes thedefault language for classes and components be-longing to this project. If a default languageis never specified, then the default languageis C++. The use of defaults, especially forcomponent-related aspects of the code, expe-dites the process of creating a working applica-tion skeleton, while maintaining the user’s abil-ity to refine the design afterwards.

Dependency management: Bocca uses dependencyinformation explicitly provided by the user, aswell as those implicit in the created artifacts,to automatically generate code that reflects thisdependency in all supported languages. For in-stance, when a port is used by a component,Bocca automatically generates a SIDL methodthat incorporates the used port symbol as anargument. This in turn causes the Babel com-piler to generate the correct code that refers toany header files or modules needed to accesscode for the used port. This dependency man-agement is particularly important as it is used inthe Bocca-generated build system to streamlinethe build process.

Interaction with external code: Bocca supports theuse of code that is external to the current projectusing one of two approaches. The first approachincorporates such code into newly developedproject artifacts (e.g. the --import-sidl and--import-impl command line option). Thisapproach is particularly useful to migrate legacycode into Bocca-managed projects. The alter-native uses external SIDL symbols in-place,caching their definition in a local directory foruse by the build system. This latter approach al-lows for parallel development of inter-dependentprojects, without the need to totally subsume oneproject into the other.

4.2. Code maintenance

Bocca also plays an essential part in evolving andfine tuning an initial application prototype as the de-veloper gains a better understanding of the devel-oped code. At the core of Bocca’s ability to carry outapplication maintenance lies the detailed SIDL andCCA component dependency information maintainedby Bocca, which covers all managed code artifacts.

Commands that can be used to evolve a component-based application include bocca rename, whichchanges the name of a code artifact; bocca edit,which streamlines the editing process of Bocca-gener-ated code; and bocca display, which queries theBocca-maintained project database for information re-lated to project entities. Such commands also includebocca change, which captures changes applied tothe structure of the code entities themselves and theirinter-dependencies. Such a change may include adding(or removing) a port used (or provided) by a com-ponent, changing the inheritance attributes of an in-terface or a class, or capturing the dependency on asymbol in a method argument to properly structure thebuild system. Code maintenance commands also in-clude bocca remove, to delete a code entity fromthe managed project.

4.3. Application generator

Appgen is an application generator that interpretsdirectives for manipulating components and creates amain() program in a language of the user’s choice.While not strictly part of Bocca, it works with Bocca-generated components. The generated code can beused as is or incorporated as part of a larger appli-cation. Appgen takes advantage of the fact that theCCA specification requires that compliant frameworksmay also be used passively like a library, instantiatingcomponents and linking them together on behalf of andriving application. This embedding of CCA compo-nent networks allows even main() programs to ap-pear in a CCA framework as a component itself [3].

Figure 5 is an example of Appgen input source thatcreates a standalone application that runs the exam-ple from Section 1.3. The path command in line 2tells the framework where to find components in thefilesystem. Lines 5 and 6 define how the symbols forthe particular component class are to be loaded in thecase of a shared object library. If the components arestatically linked in, such as might be the case in ahigh-performance setting, then these statements haveno effect. get-globalmeans load all of the symbolsglobally so they are resolved at the top level for the en-tire application. Lines 10 and 11 instantiate the compo-nents by their classname (first argument) giving each aunique instance name (second argument). The instancename will be used to refer to these components forconfiguration and invocation. Next, in line 14, we con-nect the myPort uses port on the Driver to the pro-vides port of the same type on the Worker compo-


1 # i d e n t i f y where t h e appgen t o o l can f i n d t h e components :2 p a t h s e t / u s r / s h a r e / cca3

4 # r e t r i e v e and load t h e component symbo l s :5 r e p o s i t o r y ge t −g l o b a l m y p r o j e c t . D r i v e r6 r e p o s i t o r y ge t −g l o b a l m y p r o j e c t . Worker7

8 # i n s t a n t i a t e t h e components and g i v e them9 # t h e names ‘ ‘ d r i v e r ’ ’ and ‘ ‘ worker ’ ’ :

10 c r e a t e m y P r o j e c t . D r i v e r d r i v e r11 c r e a t e m y P r o j e c t . Worker worker12

13 # c o n n e c t t h e components :14 c o n n e c t d r i v e r myportname worker myportname15

16 # run t h e d r i v e r component by i n v o k i n g i t s ‘ ‘ go ’ ’ p o r t :17 go d r i v e r

Fig. 5. Input for the Appgen tool which will create a main() program in the language of the user’s choice, assembling and running thecomponents as an application.

nent. Finally, on line 17, we invoke the GoPort on theDriver. This yields the same application shown fromthe GUI view (see Fig. 2) but as an executable gener-ated in any of the supported programming languages.

5. Implementation

Bocca is implemented in Python by using an ex-tensible architecture of interfaces and modules corre-sponding to the different parts of the system.

5.1. Project graph representation

Unlike graphical IDEs, Bocca cannot maintain elab-orate project state in memory and must thus rely onan efficient persistent representation of all project in-formation. We have chosen a graph representation forexpressing the relationships between project entities,based on a Python graph package developed by Dickand Gaitanis [12]. The vertices of the graph generallycorrespond to SIDL entities, such as package, inter-face, port, class, component and enum. Dependenciesbetween entities are represented by edges between thecorresponding vertices. There are several types of de-pendencies between vertices:

• “extends” dependence between an interface thatextends another interface, or a class that extendsanother class;

• “implements” dependence between a class thatimplements an interface;

• “uses” and “provides” dependencies betweenports and components;

• “contains” dependence, which is used to expressthe relationships between packages and the SIDLentities they contain, as well as noninheritance-related dependencies between any two SIDL en-tities, for example, a SIDL interface used as anargument type in a class method.

The project graph representation is serialized andstored in ASCII form. Initially Bocca used Python’scPickle serialization, but it proved more cumbersometo implement and maintain the special handling ofgraph entities (due to potential circular references)than to implement a slightly less general custom se-rialization for the graph. Storing the graph in a bi-nary format is possible, as well, but does not offersignificant performance advantages. In addition, thepersistent project state file is human-readable, aidingin debugging. A high-level visual representation ofthe project is also available via a Graphviz [13] dotfile, which is automatically generated by the boccadisplay command.

Figure 6 shows a visualization of the graph rep-resentation of the simple Bocca project presentedin Section 1.3, which consists of a package con-taining a port (myProject.myPort) and two compo-nents: myProject.Component1, which uses the port,and myProject.Component2, which provides the port.

5.2. Command dispatching

Each Bocca action (e.g., create, change, dis-play) corresponds to a method in the interface that all


Fig. 6. Graph project representation illustration for a simple Bocca project.

pertinent SIDL entities implement. Each Bocca com-mand also has a subject (e.g., project, port, compo-nent), which is the entity to which the action applies.Sometimes the subject is implicit, as in bocca dis-play, where the subject is project, or when a SIDLname for an entity that exists in the project is used,as in bocca display MyPort, where the subjectis port. In the graph project representation describedin Section 5.1, the BVertex interface contains methodscorresponding to all command-line actions. Each sub-ject is a class descended from BVertex.

A dispatcher module is responsible for deter-mining what the action and subject are on the com-mand line. The only option the dispatcher recognizesis --help/-h. All other options are parsed and han-dled by the class corresponding to each subject. Foreach Bocca command, the dispatcher performs the fol-lowing steps:

1. Determine and validate the action and subject.2. Load the project graph and attempt to determine

the subject if it was not given on the commandline.

3. Load the Python module containing the classimplementing the subject (e.g., Interface, Port,Class, Component).

4. When the create action is present, create a newinstance of the subject class.

5. For refactoring actions (e.g., change, rename),retrieve the vertex from the project graph corre-sponding to the specified subject.

6. Invoke the method corresponding to the action onthe instance corresponding to the subject.

7. After completion of the method, perform cleanupand, if necessary, save the project state.

The dispatcher also performs some special help ac-tion handling (to support the help command outsideof a Bocca project) and allows some flexibility in thecommand line syntax, such as not specifying the sub-ject explicitly.

5.3. Code generators

Bocca automatically generates SIDL definitions andboilerplate component code in the implementation forall Babel-supported languages. Babel parses SIDL andgenerates code in C, C++, Fortran, Java or Python,using splicers, or special structured comments,to designate portions of the code, referred to assplicer blocks, that can be edited by the user. Thefirst concern of both Bocca and Babel code genera-tors is never to lose anything a user writes by hand.A splicer block is a set of lines that begins with aline key.begin(symbol), where the key is a splicertype and symbol is the SIDL symbol associated withthe particular splice. Each splicer block ends with aline key.end(symbol). Any text contained betweenthe begin/end splicer comments is not modified byBabel, while any code outside of a splicer block isregenerated when Babel is applied to the SIDL file.Bocca generates SIDL files containing splicer blocksfor user comments, methods (in interfaces and classes),and enumerators (in enums).

After Babel generates the implementation code inthe target language, Bocca inserts component and otherboilerplate code within the Babel splicers. Two typesof code are generated by Bocca:

• Bocca default code: boilerplate code for gettingports, handling exceptions and other commonoperations associated with CCA components orSIDL interfaces. This code is generated once andcan be modified or removed entirely by the devel-oper.

• Protected code: the contents of protected blocksare essential for compilation and correctness andshould not be modified or removed by the user.

For example, Fig. 7 contains a code excerpt fromthe implementation of the “Driver” component gener-ated from the example in Section 1.3 and illustrated


1 / * *2 *3 * E x e c u t e s o m e e n c a p s u l a t e d f u n c t i o n a l i t y o n t h e c o m p o n e n t.4 * R e t u r n 0 i f o k , −1 i f i n t e r n a l e r r o r b u t c o m p o n e n t m a y b e5 * u s e d f u r t h e r , a n d −2 i f e r r o r s o s e v e r e t h a t c o m p o n e n t c a n n o t6 * b e f u r t h e r u s e d s a f e l y .7 */8 i n t 3 2 _ t m y P r o j e c t : : D r i v e r _ i m p l : : go_impl ( )9 {

10 / / DO−NOT−DELETE s p l i c e r . b e g i n ( m y P r o j e c t . D r i v e r . go )11 / / User e d i t a b l e p o r t i o n i s i n t h e midd le a t t h e n e x t I n s e r t −UserCode−Here l i n e .1213 / / Bocca g e n e r a t e d code . bocca . p r o t e c t e d . b e g i n ( m y P r o j e c t . D r i v e r . go : boccaGoProlog )14 i n t b o c c a _ s t a t u s = 0 ;15 / / The use r ’ s code s h o u l d s e t b o c c a _ s t a t u s 0 i f c o m p u t a t i o n p r o c e e d e d ok .16 / / The use r ’ s code s h o u l d s e t b o c c a _ s t a t u s −1 i f c o m p u t a t i o n f a i l e d b u t might17 / / s u c c e e d on a n o t h e r c a l l t o go ( ) , e . g . when a r e q u i r e d p o r t i s n o t y e t18 / / c o n n e c t e d .19 . . .20 gov : : cca : : P o r t p o r t ;2122 / / n i l i f n o t f e t c h e d and c a s t s u c c e s s f u l l y :23 m y P r o j e c t : : myPort myPort ;24 / / True when r e l e a s e P o r t i s needed ( even i f c a s t f a i l s ) :25 boo l m y P o r t _ f e t c h e d = f a l s e ;26 / / Use a m y P r o j e c t . myPort p o r t w i th p o r t name myPort27 t r y {28 p o r t = t h i s −>d _ s e r v i c e s . g e t P o r t ( " myPort " ) ;29 } c a t c h ( : : gov : : cca : : CCAException ex ) {30 / / we w i l l c o n t i n u e wi th p o r t n i l ( n e v e r s u c c e s s f u l l y a s s i g n e d ) and31 / / s e t a f l a g .32 . . .33 }34 i f ( p o r t . _ n o t _ n i l ( ) ) {35 / / even i f t h e n e x t c a s t f a i l s , must r e l e a s e .36 m y P o r t _ f e t c h e d = t rue ;37 myPort = : : b a b e l _ c a s t < m y P r o j e c t : : myPort >( p o r t ) ;38 i f ( myPort . _ i s _ n i l ( ) ) {3940 # i f d e f _BOCCA_STDERR41 s t d : : c e r r << " m y P r o j e c t . D r i v e r : E r r o r c a s t i n g gov : : cca : : P o r t "42 << " myPort t o t y p e "43 << " m y P r o j e c t : : myPort " << s t d : : e n d l ;44 # e n d i f / / _BOCCA_STDERR4546 go to BOCCAEXIT ; / / we c a n n o t c o r r e c t l y c o n t i n u e . c l e a n up and l e a v e .47 }48 }4950 / / Bocca g e n e r a t e d code . bocca . p r o t e c t e d . end ( m y P r o j e c t . D r i v e r . go : boccaGoProlog )5152 / / When t h i s t r y / c a t c h b l o c k i s r e w r i t t e n by t h e use r , we w i l l n o t change i t .53 t r y {54 / / A l l p o r t i n s t a n c e s s h o u l d be r e c h e c k e d f o r . _ n o t _ n i l b e f o r e c a l l i n g55 / / i n u s e r code . Not a l l p o r t s need be c o n n e c t e d i n a r b i t r a r y use .56 / / The u s e s p o r t s a p p e a r a s l o c a l v a r i a b l e s h e r e named e x a c t l y a s on t h e57 / / bocca commandline .5859 / / I n s e r t −UserCode−Here { m y P r o j e c t . D r i v e r . go }60 . . .61 / / DO−NOT−DELETE s p l i c e r . end ( m y P r o j e c t . D r i v e r . go )62 }

Fig. 7. Excerpt of the Bocca-generated code for Driver.GoPort from the example in Fig. 1, line 12.


by Fig. 1. Specifically, this code is generated for the“GO” method on the Driver component in C++. Re-call that this method is called by a CCA-compliantframework to start execution. Line 10 in Fig. 7 is thestart of the splicer block that has been generated byBabel to protect user code from changes by Babel.Within this block are special “protected” blocks gen-erated by Bocca of the form bocca.protected.begin(symbol) closed by bocca.protected.end(symbol) (line 13 closed by line 50 in Fig. 7; notethat this is only a partial listing because of space con-siderations). This block will be parsed and changed byBocca and serves as a warning to developers that al-terations may break the code or will be lost. All usermodifications outside of bocca.protected blocksand inside splicer blocks will be preserved.

5.4. Project refactoring

In addition to project creation, Bocca automatesmany project refactoring and maintenance tasks. Be-fore Bocca, some common operations, such as remov-ing or renaming an interface or a class, were time-consuming and error prone, requiring manual updatesto SIDL files, header and implementation files in var-ious languages and makefiles. Bocca relies on the de-pendence information in the project graph representa-tion to propagate all changes correctly and automati-cally updates affected files, as well as the project graph.

5.4.1. Importing existing codeIn many cases, the developer is not starting from a

blank slate and may wish to leverage existing SIDL andimplementation code when creating or modifying aBocca project. To serve this common need, Bocca pro-vides import functionality, both for SIDL and for im-plementation code in the languages supported by Ba-bel. To support SIDL imports, Bocca contains a SIDLparser, implemented using Ply [11], which is a pure-Python implementation of the popular compiler con-struction tools lex and yacc. As with other Bocca com-mands, the --import-sidl option can be appliedto different SIDL entities. An entire SIDL package canbe imported into a Bocca project or package, or indi-vidual interfaces, ports, classes, components, or enumscan be imported into an existing Bocca package.

In addition to importing SIDL, Bocca can importimplementation code from existing Babel-based soft-ware. The import implementation relies on the Babelsplicers in the code and thus does not need to parseeach of the supported languages. Usually a few manualchanges are necessary after importing implementationsource code.

5.4.2. Managing the project stateAs described in Section 5.2, the persistent graph

project representation is loaded and stored before andafter each Bocca command. When a Bocca commandfails, the persistent state is not modified.

Many Bocca commands result in the creation of newfiles or modifications to existing files. If a commandfails halfway through its execution, after modifyingcertain files, simply exiting with an error code wouldleave the project in an inconsistent state. To providegraceful recovery from errors, Bocca uses a “smart”file manager that is able to undo any operation on a fileperformed during the execution of a command. Addi-tionally, the file manager automatically makes backupsfor all destructive actions, e.g., rename and remove.

Users can control many aspects of Bocca throughthe use of a projectwide configuration file. For exam-ple, one can specify different levels of validation af-ter user input into SIDL files: from no validation, torunning a syntax check, up through regeneration of allaffected implementation code.

5.4.3. Help systemThe help action and --help/-h options are an

important source of documentation for Bocca and areimplemented using the Python docstrings embedded inthe method implementations. Since help informationis dynamically obtained from the modules correspond-ing to each command, Bocca ensures that help will beavailable for any new modules that simply documenttheir implementations and will not be out of sync withthe implementation.

5.5. Build system

Bocca does not incorporate a specific build para-digm. The definition of multiple different build sys-tems is made possible through a pair of abstract inter-faces, LocationManager and Builder. These interfacesallow different build systems to be plugged into Bocca-managed projects using an option in the project config-uration file. As part of the Bocca distribution, a GNUMake [17] plugin is provided. This plugin generatesmakefile segments that automate the build of all Bocca-managed entities. Users can extend and override makevariables and rules using special user-controlled make-file segments that are then included in the automati-cally generated build files. Users can define rules thatare executed before and after each stage of the build:code generation, compilation, linking and installation.In addition to the predefined makefile variables pro-


vided by the builder plugin (e.g., installation locations,compilers, compiler and other flags), developers candefine new makefile variables that are used in prede-fined and/or user-defined rules.

6. Related work

It is tempting to consider Bocca, albeit command-line driven, just another IDE. Although Boccafulfillsmany functions traditionally associated with IDEs, itdoes not provide the language-syntax-enabled editors,visual programming interfaces, and so on that are in-separable from traditional IDEs. It is difficult to drawdistinctions between the typical IDE and Bocca, butcertainly the IDE is more comprehensive. By takingadvantage of language and application domain partic-ulars, the intention of an IDE is to speed the devel-opment process generically. Traditional IDEs are in-volved in every aspect of the development. Hence,special-purpose IDE application is necessary for all as-pects of code creation, testing and deployment. Uniquepeculiarities in these languages and bindings are ex-ploited to flatten the learning curve and otherwisespeed code construction. Bocca, on the other hand, ismeant to create a CCA shell application or import ex-isting code into a componentized application and islimited to that purpose. The CCA application devel-oper relies on Bocca only to define and maintain CCAcomponents and SIDL interfaces; the rest of the de-velopment process is left to other tools. Pragmatically,a typical IDE takes many more man-years of effort inorder to be viable, an effort that is beyond the resourcesof the Bocca team.

Bocca borrows from the extreme programming phi-losophy that all working code comes from other work-ing code, and it is easier to evolve a working appli-cation than to start out with a blank slate. There isno requirement for Bocca itself to build or edit theapplication after it has been invoked except to aug-ment or change aspects of its componentization. Whiletypical IDEs are concerned with every aspect of soft-ware development, Bocca is concerned only with theCCA componentization. Possibly the closest analoguein commercial software is Ruby on Rails [18]. Givena database schema and a few names, Rails creates adatabase-backed web application shell that users canmodify to suit their needs. Similar to Bocca, does notseek to speed the traditional process of developmentbut to change the process itself by giving the user aworking web application. Also similarly, Rails’ scope

is limited to the web application domain and is not in-volved in editing, building, or running of the applica-tion itself. Users employ their own tools to insert spe-cific implementation code.

Depending on its design, the IDE is a full partnerin a developer’s code creation means that once under-taken, the IDE is forever the basis of the developer’scode base. Traditional IDEs are involved in every as-pect of the development meaning that special-purposeIDE application is necessary for all aspects of codecreation, testing, and deployment. Unless Boccais in-voked specifically to alter or augment some componentaspect, the application is otherwise edited, built, anddebugged without Bocca intervention. Thus, Bocca’s“cost of abandonment” is low. There is little penaltyfor getting started with Bocca, and in the event thatBoccabecomes too restrictive, continuing developmentwithout it.

7. Quantifying Bocca’s impact

Quantitative studies of Bocca’s impact on developerproductivity have not been performed because of therapid and iterative nature of Bocca ’s development.We can, however, provide measures of the complex-ities managed by counting the artifacts Bocca auto-matically manages. The statistics in Table 1 refer tothe previous example of Section 1.3 choosing an im-plementation language of C++. These are rough mea-sures of Bocca’s effectiveness in reducing the softwareengineering complexity the scientist must deal within developing portable component software. The onlysignificant dependence of these results on the choiceof implementation language is that the lines of helpercode (CCA source) generated are substantially higherto manage object type handling and exceptions in lan-guages lacking those concepts, such as C and For-tran.

We show in Table 1 the quantity and sizes of filesand code generated by Bocca use, by execution ofthe builder plugin, and by installation of the result-ing product. For the two components and one port inthe example of Fig. 2, the set of customizable files issmall, while the glue code is both lengthy and wide-spread. The majority of the glue code is due to theCCA requirement that components be language agnos-tic.

Portable HPC software build systems are expen-sive to create, debug, and maintain. The CCA speci-fication and the Babel tool prescribe no standards for


Table 1

Project entities managed with Bocca

Files Lines Code type

User customizable

3 116 SIDL Files

4 1354 Babel Impl source

16 481 Build system

Uneditable

n/a 498 CCA source (inserted into Impl)

94 9732 Babel glue source code

798 157,709 Build process intermediates

Installed product

26 n/a Interface libraries

2 n/a Component libraries

70 22,513 Headers or scripts

201 4 Package metadata (xml)

build processes or installation practices. Bocca fillsthis void using the pattern set by the builder-plugin ofthe user’s choice, completely hiding the size and com-plexity of the build infrastructure required to assemblethe different makefile fragments into a complete buildprocess.

Several Bocca users have adopted the more radi-cal (and considerably cheaper) approach that the entirebuild system is only a generated and therefore dispos-able artifact. These users permanently manage only thefiles containing their value-added work: the SIDL def-initions, the component implementations, the externalsoftware dependencies, and the scripts that regeneratethe build system.

8. Conclusions and future work

The development environment for high-perfor-mance computing software presents unique require-ments that are not addressed by any of the com-monly available integrated development systems. Suchrequirements include the need to seamlessly supportmixed language development, where the same projectinvolves code written in any of the commonly usedlanguages in high performance computing. Addition-ally, the need to support development and deploy-ment on high-end computing platforms that may lackproper infrastructure for GUI-based development ren-ders the command-line user interface essential for de-velopment tools that target such platforms. Further-more, the fact that HPC code is typically ported to sev-eral platforms during its useful life time renders the

use of any platform-specific development environmenthighly undesirable.

The Bocca development tool addresses the uniquerequirements for high-performance scientific comput-ing software. Bocca facilitates the rapid prototyping ofcomplex multilingual applications, while at the sametime providing the required infrastructure for the con-tinued refinement and update of the original applica-tion design. Bocca’s infrastructure, developed entirelyin the widely available Python programming language,guarantees ease of portability to any HPC platform.The default Bocca-generated build system uses stan-dard, portable tools that guarantee maximum porta-bility of Bocca projects across HPC platforms. Fur-thermore, Bocca generated projects are not dependenton Bocca itself for build and deployment. Thus, suchprojects can evolve independently of Bocca, should theneed arise.

The underlying design philosophy of Bocca maxi-mizes the reuse of widely accepted standard tools in theHPC community, while streamlining the developmentand deployment process. The pluggable build systemback-end architecture of Bocca relies on the integra-tion of widely available build systems and tools, ratherthan introducing a new build system that locks devel-opers into a specific build methodology that may notfit their expertise or development requirements.

Acknowledgments

This work was supported in part by the Mathemati-cal, Information, and Computational Sciences Divisionsubprogram of the Office of Advanced Scientific Com-puting Research, Office of Science, US Departmentof Energy, under Contract DE-AC02-06CH11357 (Ar-gonne National Laboratory); Oak Ridge NationalLaboratory, managed by UT-Battelle, LLC, for theUS Department of Energy under contract DE-AC05-00OR22725. Sandia is a multiprogram laboratory op-erated by Sandia Corporation, a Lockheed MartinCompany, for the US Department of Energy under con-tract DE-AC04-94AL85000.

References

[1] B.A. Allan and R.C. Armstrong, CCA tutorial: Intro-duction to the Ccaffeine framework, http://www.cca-forum.org/tutorials/archives/2002/tutorial-2002-06-24/tutorialModFramework.pdf, 2002.


[2] B.A. Allan, R. Armstrong, D.E. Bernholdt, F. Bertrand,K. Chiu, T.L. Dahlgren, K. Damevski, W.R. Elwasif, T.G.W.Epperly, M. Govindaraju, D.S. Katz, J.A. Kohl, M. Krishnan,G. Kumfert, J.W. Larson, S. Lefantzi, M.J. Lewis, A.D. Mal-ony, L.C. McInnes, J. Nieplocha, B. Norris, S.G. Parker, J. Ray,S. Shende, T.L. Windus and S. Zhou, A component architec-ture for high-performance scientific computing, Intl. J. HighPerform. Comput. Appl. 20(2) (2006), 163–202.

[3] B.A. Allan, R.C. Armstrong, A.P. Wolfe, J. Ray, D.E. Bern-holdt and J.A. Kohl, The CCA core specification in a dis-tributed memory SPMD framework, Concurr. Comput.: Pract.Exp. 14(2) (2002), 323–345.

[4] Babel homepage, http://www.llnl.gov/CASC/components/babel.html, 2008.

[5] D. Beazley, Simplified wrapper and interface generator(SWIG), http://www.swig.org, 2008.

[6] K. Beck, Extreme Programming Explained: Embrace Change,Addison-Wesley Longman Publishing Co., Inc., Boston, MA,USA, 2000.

[7] D.E. Bernholdt, R.C. Armstrong and B.A. Allan, Managingcomplexity in modern high end scientific computing throughcomponent-based software engineering, in: Proc. of HPCAWorkshop on Productivity and Performance in High-End Com-puting (PPHEC 2004), Madrid, Spain, 2004, IEEE ComputerSociety, 2004.

[8] R.M.-H. Bill Burke, Enterprise JavaBeans 3.0, 5th edn,O’Reilly Media, Inc., Sebastopol, CA, 2006.

[9] CCA tutorial hands-on guide: A step-by-step walk-throughfor creating CCA components, http://www.cca-forum.org/download/tutorial/guide-html-0.5.3_rc1.

[10] CCA tutorials, http://www.cca-forum.org/tutorials/.

[11] Dabeaz LLC, Ply homepage, http://www.dabeaz.com/ply/index.html, 2008.

[12] R. Dick and K. Gaitanis, Graph – Directed and undi-rected graph data structures and algorithms, http://ziyang.ece.northwestern.edu/ dickrp/python/mods.html, 2005.

[13] J. Ellson, E. Gansner, L. Koutsofios, S.C. North and G. Wood-hull, Graphviz – Open source graph drawing tools, in: GraphDrawing, LNCS, Vol. 2265, Springer, Berlin/Heidelberg, 2002,pp. 594–597.

[14] W. Elwasif, B. Norris, B. Allan and R. Armstrong, Bocca:A development environment for HPC components, in: HPC-GECO/CompFrame 2007, Montreal, Canada, October 2007.

[15] S.R. Kohn, G. Kumfert, J.F. Painter and C.J. Ribbens, Divorc-ing language dependencies from a scientific software library,in: 10th SIAM Conference on Parallel Processing, Portsmouth,VA, 2001.

[16] G.T. Leavens and M. Sitaraman, Foundations of Component-Based Systems, Cambridge University Press, New York, NY,2000.

[17] R. Mecklenburg, Managing Projects with GNU Make, O’ReillyMedia, Inc., Sebastopol, CA, 2004.

[18] D. Thomas, D.H. Hansson, L. Breedt, M. Clark, J.D. David-son, J. Gehtland and A. Schwarz, Agile Web Development withRails, 2nd edn, Pragmatic Progammer, Lewisville, TX, 2006.

Submit your manuscripts athttp://www.hindawi.com

Computer Games Technology

International Journal of

Hindawi Publishing Corporationhttp://www.hindawi.com Volume 2014


Distributed Sensor Networks


Advances in

FuzzySystems

Hindawi Publishing Corporationhttp://www.hindawi.com

Volume 2014


ReconfigurableComputing

Hindawi Publishing Corporation http://www.hindawi.com Volume 2014


Applied Computational Intelligence and Soft Computing

Advances in

Artificial Intelligence


Advances inSoftware EngineeringHindawi Publishing Corporationhttp://www.hindawi.com Volume 2014


Electrical and Computer Engineering

Journal of

Journal of

Computer Networks and Communications


Hindawi Publishing Corporation

http://www.hindawi.com Volume 2014

Advances in

Multimedia


Biomedical Imaging


ArtificialNeural Systems

Advances in


RoboticsJournal of



Computational Intelligence and Neuroscience

Industrial EngineeringJournal of


Modelling & Simulation in EngineeringHindawi Publishing Corporation http://www.hindawi.com Volume 2014

The Scientific World JournalHindawi Publishing Corporation http://www.hindawi.com Volume 2014


Human-ComputerInteraction

Advances in

Computer EngineeringAdvances in


ios press managing scientiﬁc software complexity with

Documents