r2hat.qxp C O V E R F E A T U R E 0018-9162/06/$20.00 © 2006 IEEE42 Computer P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y A middleware-based, component-oriented software system consists of • an integrating middleware layer that abstracts the execution environment and implements services and communication channels, and • a network of cooperating components that run on the middleware services and enforce the business logic. This clear separation of infrastructure and applica- tion modules, and the ability to easily compose such modules, naturally suggests three distinct development roles: The product-line architect sets the system archi- tecture, selects infrastructure platforms, and organizes the development process; the component developer builds the business-logic modules; and the component integrator assembles the components into systems. The “Product-Line Development Roles” sidebar describes these roles in more detail. Advances in architecture description languages and metamodeling environments3 have enabled software product managers to hide the complexities of lower- level implementation details by defining structural abstractions of components, interfaces, connectors, and system assemblies that can be visualized and analyzed Existing software modeling approaches fail to support many product-line development activities. The Cadena platform, together with its core modeling concept, the Cadena Architecture Language with Metamodeling, addresses this deficiency by providing a highly adaptive type-centric modeling framework with robust, flexible, and extensible tool support. Adam Childs, Jesse Greenwald, Georg Jung, Matthew Hoosier, and John Hatcliff Kansas State University L arge-scale software development efforts are increasingly based on product lines, a develop- ment process in which developers build the soft- ware for similar product families from reusable infrastructure and common application compo- nents.1 By emphasizing systematic reuse, the product-line approach can reduce development and production time as well as overall costs by a factor of 10 times or more.2 Using component middleware frameworks supports the product-line approach by • providing well-defined interfaces that prevent client code from becoming unnecessarily tangled with low-level implementations; and • making units easier to plug and unplug, which facil- itates reuse and system evolution. Product-line development based on such frameworks has been successful in numerous application domains ranging from large-scale distributed real-time and embed- ded computing systems used in mission- and safety-crit- ical domains—including commercial air traffic control, military systems, electrical power grids, industrial process control, and medical imaging—to user-level operating- system and desktop-application integration. CALM and Cadena: Metamodeling for Component-Based Product-Line Development February 2006 43 and that can drive automatic generation of various forms of infrastructure code. However, these modeling tools are often not directly targeted to product-line development roles. CALM/CADENA The Cadena development-tool platform, together with its core modeling concept, the Cadena Architecture Language with Metamodeling (CALM), addresses this deficiency by providing a highly adaptive type-centric modeling framework with robust, flexible, and exten- sible tool support. CALM CALM (www.cadena.projects.cis.ksu.edu/calm) is an architecture description language that enables strongly typed modeling of platforms, components on these plat- forms, and component assemblies of concrete scenar- ios. It also supports inheritance-based hierarchical organization of platforms with aspect mechanisms for Product-Line Development Roles Product-line architects, component developers, and component integrators each play a distinct role in middle- ware-based, component-oriented software product-line development. PRODUCT-LINE ARCHITECTS Product-line architects initially analyze commonalities and differences among systems in the product family as well as any inherent dependencies between their fea- tures and capabilities. Guided by this analysis, they con- struct a common software infrastructure, including a component model and supporting services, that devel- opers can reuse for all products within the family. Product-line architects also define coding and modeling guidelines to constrain and organize the development process. Developers can use numerous industry-standard compo- nent platforms, such as the CORBA Component Model and Enterprise JavaBeans, to support product-line development. Most out-of-the box implementations of CCM and espe- cially EJB also add functionality that is not part of the plat- form specification. In addition, specialized platforms have been developed to build specific, large-scale projects—for example, the Boeing Bold Stroke/Prism model, which is used for avionics-control systems, and the Gnome-Bonobo platform, which is the basis for the Gnome desktop-man- ager event system. Given the number of different component models and implementations targeted at various classes of applications (such as embedded versus nonembedded), it is often benefi- cial to organize the product line in a platform-independent manner by working at a level of abstraction that avoids com- mitting to specific underlying component models or imple- mentations.This allows using different middleware implementations for different products and can facilitate migration to middleware platforms across the product line’s lifetime. The product-line architect is responsible for developing rules, guidelines, and even automated transformations for migrating platform-independent models and artifacts to platform-specific models and implementations. In large- scale systems of systems, architectures may need to support multiple component models and platforms. COMPONENT DEVELOPERS Component developers fall into two broad categories. Common component developers design components that are intended to be reused across multiple projects, as well as abstract versions of more special components that are refined—for example, via inheritance—and implemented for use in specific projects. Project-specific component developers implement com- ponents for particular systems and customize or refine common components to satisfy functional requirements for their portion of the system. Components that offer related functionality are grouped into modules or libraries. The component developer carefully models the event and data interfaces provided to client components as well as those on which the component depends as component ports.The component integrator resolves these dependen- cies later during system assembly and configuration. Components can use infrastructure services such as a persistence, time, event, or replication. Often the configura- tion settings for such services are exposed by the compo- nent developer in metadata associated with the component so that the component integrator can choose a particular setting after determining the component’s context. COMPONENT INTEGRATORS Component integrators work on specific projects.They attempt to satisfy the functional and real-time requirements of a particular system by hooking together general-purpose and project-specific components drawn from a component library and by selecting distribution strategies, execution priorities, and infrastructure-specific communication services. This phase benefits most obviously from tool support, such as automatic valuation of metadata or deployment information through implemented heuristics, or more sim- ply through graphical display and editing of assemblies. Partial assemblies that support certain recurring functional- ities (subassemblies) can be saved as libraries similar to component-type libraries. 44 Computer Product-line architects use the top style tier to define architectures and capture middleware infrastructure properties by specifying languages for building types of components, interfaces, and connectors, along with appropriate metadata schemas. Component developers use those languages on the middle module tier to define component and interface types within a particular archi- tecture. System integrators use the bottom scenario tier to allocate instances of declared component and con- nector types, connect allocated component instances, and configure underlying middleware, services, and network deployments by setting model-level attribute values. While CALM exists as a textual language, develop- ers use specialized spreadsheet-based or graphical input/output and editing environments to integrate it into Cadena, making CALM/Cadena intuitively easy to use with little training. Cadena Cadena (www.cadena.projects.cis.ksu.edu) provides a variety of forms of support for creating, editing, query- ing, and browsing and transforming CALM models. CALM models are connected to underlying component middleware frameworks as well as analysis and code- generation facilities via Cadena plug-ins. These plug-ins effectively serve as model interpreters that realize the semantics of CALM models. Cadena provides a spec- trum of plug-in points, letting users add specialized func- tionality for the component systems modeled at each CALM stage. Each plug-in is associated with a partic- ular CALM architecture type, and inheritance on archi- tecture types guarantees effective plug-in reuse on models as they are migrated to more specific platforms. Cadena is engineered from the ground up to serve as an extensible tool platform rather than as a single tool. Based on Eclipse (www.eclipse.org), IBM’s widely used open source integrated development environment, Cadena itself is implemented as a series of Eclipse plugs-ins. Cadena exploits the Eclipse Modeling Framework’s autocoding facilities so that developers can create extremely robust, efficient tool features such as incremental type checking and model-change propagation. Cadena plug-in points are available to associate EMF adapter factories with CALM styles, enabling Cadena plug-in developers to add specialized constraint languages, constraint checkers, involved analysis frameworks, automated design heuris- tics, and autocoding and deployment facilities. MODELING IN CALM/CADENA The starting point of a CALM specification is the def- inition of component, connector, and interface kinds to describe a metamodel of a system’s architectural ele- ments at the style tier. In accordance with type theory,4 each kind defines a language of types at the module tier, and every software code unit, or instance, at the sce- nario tier is derived from a type. For example, a single incorporating specific platform attributes into general architectural descriptions. The framework offers a rigorous, type-based approach for transitioning platform-independent models to plat- form-specific models via a series of tool-supported refine- ment steps. These steps incrementally incorporate more structural details regarding particular component mod- els, underlying middleware, and product development contexts. They also augment the models with increasingly precise and detailed metadata, attributes, and weave-ins. Basic modeling primitives in CALM are based on the three fundamental types of entities that define every component-based system and, more generally, every sys- tem of communicating processes: • business-logic containers—the locations of compu- tation (components); • services—the locations of communication (connec- tors); and • the interaction points between components and con- nectors that define the assumptions and guarantees (interfaces). The formation and use of these entities is realized in CALM using a tiered metamodeling approach aligned with the three product-line development roles. A model in a particular tier defines the language or vocabulary of entities that can be used in constructing models in the tier below it. Figure 1. Cadena style editor. The table, or spreadsheet, view reveals basic CORBA Component Model entities in their CALM definition. component instance has a certain compo- nent type, and the component type is defined within its component kind. To spec- ify component kinds, CALM uses the con- cept of metakinds—toolboxes that serve as a factory for new types of components, interfaces, and connectors. The relation between instance and type is the same as that between type and kind. Although the concept is simple, this addi- tional level of abstraction gives CALM/ Cadena the flexibility to provide specialized development environments for a huge class of platforms. Style tier Figure 1 shows the Cadena style editor with the Common Object Request Broker Architecture (CORBA) Component Model specification (www.omg.org/technology/ documents/formal/components.htm). The table, or spreadsheet, view reveals basic CCM entities in their CALM definition, such as the highlighted CCMComponent with its capabilities to send and receive events (consumes, emits, publishes) or to provide and use data interfaces (provides, uses). Note that the CCMComponent is derived from a specific template, the metakind mCCMComponent. Component kinds. These describe a platform’s soft- ware unit primitives and possible mechanisms that these units may use to interact with one another. The possible interaction points, called port options in CALM, pro- vide a means to declare explicit context dependencies— a central theme of component-based development. The product-line architect uses port options to specify the kinds of interfaces a component kind can feature, together with the necessary keywords—for example, consumes for CCM event input ports, and publishes or emits for CCM event output ports, as shown in Figure 1. Further, developers can add attributes, typed through CALM’s own extensible type system, to the component kind to define its ability to carry metadata. These attrib- utes—which can be specified for the whole kind, types therein, or concrete instances—can hold data for deploy- ment information, initialization values, and all sorts of functional, structural, or organizational content. Connector kinds. These model the services the plat- form provides. The chosen platform can include vari- ous middleware services supporting intercomponent communication, distribution, persistence, and state replication, among others. Each connector kind repre- sents a distinct platform service or family of services. Each connector definition may contain multiple role dec- larations, much like port options in component kinds, and interface-type constraints governing each role. Single-role connectors abstract services such as time-out generators, while multirole connectors model inter- component communication services. Note that connectors are abstractions, which are not meant as descriptions of the services’ implementations. Rather, they describe the service’s intended usage and thus enforce certain coding styles. Interface kinds. These categorize interaction points of platform components and check component-connec- tor compatibility. For example, the CCM component interacts with the asynchronous connector through event interfaces and the synchronous connector through CCM data interfaces. Interface kinds are defined by a set of attributes in the same manner as component kinds. For the CALM CCM style, for example, module-tier attributes for interface kinds describe possible method signatures of CCM interface types. After an architectural style is specified within Cadena, the tool suite does not remain static. Rather, upon alter- ation of a style, the lower tiers adapt and offer new and changed primitives in that style’s language. Module tier Working with the kinds—that is, type languages— defined for a particular architectural style, component developers use the module tier to define libraries of design-time component types that conform to that style. Component and interface kinds from the style are avail- able in the Cadena module editor, shown in Figure 2, to February 2006 45 Figure 2. Cadena module editor. While operating under the CALM CCM style, the editor adapts to provide customized CCM support. 46 Computer create component and interface types. The library of design-time types in the module is then available for allo- cating and connecting component instances at the sce- nario tier. Building types at the module tier is analogous to defin- ing component types using the CCM Interface Definition Language in the standard CCM development process. Module-tier component types are typically associated with a Cadena autocoding plug-in that generates stubs, skeletons, and other infrastructure code required for component implementation. After applying autocoding plug-ins to generate skeleton implementations, compo- nent developers can use Eclipse development environ- ments—for Java or C++, for example—to complete component implementations by coding the business logic associated with components. Scenario tier To allocate and connect component instances at the scenario tier, Cadena offers two standard development environments: a tree-based editor and a graphical editor. Figure 3 shows the graphical editor open to a CCM sys- tem. At the top is an instance diagram representing the Communication component shown in Figure 2. Within the graphical editor, the user can insert new components and configure connections through drag-and-drop matching of the connector role and component port. Large system assemblies with many components can overwhelm developers and inhibit their ability to reason effectively about a system. To help developers build impor- tant structural abstractions that collect multiple cooper- ating components together in a single unit, Cadena supports the notion of a nested assembly—essentially a virtual component that is actually realized as a nested net- work of connected component instances. Cadena’s graph- ical scenario editor allows a developer to form a nested assembly from a set of components, view this nested assembly as one entity in the graphical scenario editor, and expand and edit the nested assembly as needed. PRODUCT-LINE SUPPORT Product-line development includes many involved tasks such as designing and establishing platform spec- ifications, refining these specifications for more specific projects, combining distinct platform specifications into hybrid platforms, migrating components and assemblies from one platform to the next, augmenting a platform specification to accommodate deployment or metadata, Figure 3. Cadena scenario editor. The user can insert new components and configure connections through drag-and-drop matching. and integrating standard functionality into different platforms. Inheritance hierarchies To support these tasks, CALM introduces inheritance hierarchies, an object-oriented programming concept, into style design. For one CALM style specification to inherit from another means that the component, connector, and interface kinds defined in the parent style are also present in the substyle. CALM further allows multiple inheri- tance—that is, a style can name multiple parent styles. In addition to facilitating style specifications, a well- organized hierarchy of architectural styles serves as a con- ceptual basis for code reuse over distinct platforms by providing a guide for type-safe migration of artifacts from compliance with one style to compliance with another. As Figure 4a shows, the specialization of generic plat- form specifications toward more individual platforms corresponds to a parent-to-child transition, while the abstraction from a particular platform to a more generic, reusable form corresponds to a child-to-parent transi- tion, as Figure 4b shows. In addition, the reuse of elements from one platform on another generally corresponds to model migration, as Figure 4c illustrates. Finally, as Figure 4d shows, one platform inheriting from multiple platforms yields a hybrid or combination platform. Developers also can use this operation to establish integrative styles that mit- igate between platforms as well as to factor in standard definitions that are reusable over multiple, otherwise unrelated styles. Attribute attachment A second mechanism for refining architectural styles, and models therein, is attribute attachment, shown in Figure 4e. CALM offers an extendable value-type sys- tem that allows the definition of new types through names or combinations of existing types. Attributes typed in this system can be defined directly within a style specification or on separate attribute sheets, which can be added at every model tier. Some values that attributes capture can be specific to particular scenarios, such as deployment or location information. Other sorts of attributes recur in a general context, such as structures used to describe method sig- natures in interfaces, or in specific contexts such as com- ponent run rates in real-time systems. Developers can use attribute sheets to factor in general data over mul- tiple systems as well as to factor out specific data in par- ticular systems—for example, to allow viewing a projected system’s structural interrelations without hav- ing to set real-time data. EXAMPLE PRODUCT LINE One of the benchmark test cases for CALM/Cadena is Boeing’s Avionics Open Experimental Platform (OEP), developed as part of the Defense Advanced Research Projects Agency’s Program Composition for Embedded Systems project and available for exchange within the academic research community. The Avionics OEP is inspired by Boeing’s Bold Stroke mission-control soft- ware product-line architecture for its military avionics platforms such as the F-18. The OEP implements Prism, a model that consists of three component kinds. The business component is equivalent to the CCM component—that is, it is the generic container for business logic. The correlator is a specialized component that lowers network load through asynchronous message filtering. The event- channel component serves as the source for periodic time-out events. The event-channel component models an infrastructure unit that also manages threading and buffers asynchronous communication, but these tasks are deliberately hidden in the abstraction of the services. February 2006 47 (a) (b) (c) (d) (e) Style Inheritance Model transformation Figure 4. CALM style hierarchies. (a) Model specialization. (b) Model abstraction. (c) Model migration. (d) Hybrid model construction. (e) Attribute sheet attachment. 48 Computer Figure 5 shows a table view of the Prism style in Cadena. Prism offers two types of services: an untyped, asynchronous, event-propagation mechanism with a sta- tically set publish-subscribe connection scheme (event connection) and a synchronous, typed, data transmis- sion service (interface connection). Figure 6a illustrates using Cadena to model a single- processor modal scenario from the OEP. As Figure 6b shows, Cadena seamlessly supports the three different kinds of Prism components, which can be assigned cus- tom shapes, within the three CALM tiers. Adding to the communication infrastructure Like many other Prism examples, ModalSP exploits control-push data-pull, a dual connection in which a component supplying data first sends an asynchronous message announcing that new data is available, then the receiving component uses a synchronous connection to retrieve the data. This guarantees that the synchronous connection never blocks or waits for updates. The con- trol-push data-pull strategy links many components by two connectors instead of one. When developers use this approach, tool support must be available to ensure that both connectors’ end points match. In CALM, it is also possible to define a dedicated connector with both syn- chronous and asynchronous connection points that cap- tures the control-push data-pull protocol in a single entity. Adding real-time metadata In addition to the communication network, a Prism system configuration consists of deployment informa- tion and metadata such as initialization values, security levels, run rates, and location data. CALM features an attribute-attachment system that lets users weave in attributes orthogonal to the style hierarchy on each tier of the development process. Cadena provides multiple forms of support for attribute management, including declaration and checking of domain-specific attribute types, and plug-in facilities for processing attribute data values. For example, Prism developers must assign a priority value to each component event-handler port following a particular set of development heuristics that involve trac- ing data, event, and control dependencies across net- works of components. In the Cadena Prism development environment, a Prism plug-in automates calculation of these priority settings by coding the previously manually implemented heuristics, significantly reducing the time and effort required for this particular task. This is an instance of a general strategy for using a model-centric approach to minimize development effort and increase overall confidence levels: Important system attributes are presented at the modeling level and vari- ous domain-specific analyses, configuration mecha- nisms, automated developer advice, and integrity checks are automated through plug-ins tailored to a particular development context. Advanced platform organization The CALM style hierarchy is more than a mechanism for capturing features or abstractions of existing compo- nent platforms; it provides a structured approach for leveraging commonalities and capturing differences across families of closely related platforms. For example, the Boeing Bold Stroke line entails some abstract parent styles from which the actual Prism platform definition inherits, as well as child styles for particular platforms such as the F/A-18 Hornet fighter, which in turn branches into the F/A-18E and F/A-18F Super Hornet aircraft. The guiding principle for style inheritance is the reuse of infrastructure implementation as represented by CALM kinds. Reimplementations and new additions within the substyle, which appear in the definition of the substyle as new kinds, integrate naturally into the specification. Systems designed for distinct platforms often must cooperate in personal computing—for example, desk- Figure 5. Boeing Bold Stroke/Prism style in Cadena. Prism offers an untyped, asynchronous, event-propagation mechanism with a statically set publish-subscribe connection scheme as well as a synchronous, typed, data transmission service. top systems integrate CCM and Bonobo components— and even more frequently in companywide business inte- gration. CALM is the first conceptual framework to accomplish straightforward type-safe merging of plat- forms. The strategy is to create a child style that inher- its from each style to be merged. Within the child style, developers can easily specify necessary components or services that act as mitigators between the parent styles. T he design principles underlying CALM/Cadenahave been influenced by extensive interaction withproduct-line architects at Boeing Phantom Works and Lockheed Martin. In addition, collaboration with real-time middleware and modeling experts at Vanderbilt University to integrate Cadena with the school’s CoSMIC (Component Synthesis with Model-Integrated Com- puting) CCM environment (www.dre.vanderbilt.edu/ February 2006 49 Instances Kinds Instance of Extends Types Module tier Meta-kinds Style tier Scenario tier mInterfacemComponent mConnector mPrismComponent mPrismEventConnector mPrismTimeout mPrismEvent mPrismInterfacemPrismConnector PrismCorrelatorPrismComponent PrismTimer PrismTimeout PrismEvent PrismInterface Device Modal Modal1 ModeSource modeChange DataAvailable data time-out BinaryAnd BinaryAnd1 BinaryAnd2NavDisplay TacticalSteering NavSteering LazyActive AirFrame PilotControl NavSteeringPoints GPS Navigator Passive Modal2Display PushDataSource mPrismCorrelator mPrismTimer mPrismTimeoutConnector mPrismInterfaceConnector Figure 6. Boeing’s single-processor modal scenario in Cadena. (a) Graphic view. (b) Specifying ModalSP within CALM. (a) (b) 50 Computer cosmic), Generic Modeling Environment (www.isis.van- derbilt.edu/Projects/gme), and CIAO (Component Integrated ACE ORB) real-time component middleware (www.cs.wustl.edu/~schmidt/CIAO.html) have provided significant opportunities to enhance and refine our prod- uct-line modeling ideas. Compared to many existing approaches that focus on modeling and analyzing single-system assemblies in a fixed component model, CALM/Cadena is a rigorous type- based framework for modeling multiple component mid- dleware platforms, systematically organizing and tran- sitioning between platform definitions, and creating cus- tomized development environments that leverage domain knowledge and automate development process steps to enable early design decisions for entire product lines. The framework continues to evolve. The initial set of features in Cadena 2.0, soon to be released, focuses on capturing and specifying basic entities with their struc- tural interrelations. This will enable users to establish platform terminologies, build and assess topologies, pro- vide basic autocoding and deployment facilities, design attribute-seeding mechanisms, and conduct fundamen- tal analysis such as slicing and cycle detection. Because a main focus of Cadena is its extensibility, custom views of component systems can also easily be added. As for CALM, research is under way to flexibly attach various forms of behavioral specification. This will enable much finer grained dependence analysis and eval- uation of systems’ temporal behavior, both absolute tim- ing (real-time and schedulability analysis) and relative timing (temporal logic properties, model checking, and safety analysis). More information about CALM/Cadena and other analysis and verification tools built by the Laboratory for Specification, Analysis, and Transformation of Software at Kansas State University can be found at the SAnToS Lab home page (www.cis.ksu.edu/santos). ■ Acknowledgment This work was supported in part by the Defense Advanced Research Projects Agency as part of the Program Composition for Embedded Systems project (contract F33615-00-C-3044) and the Army Research Office’s High-Confidence Embedded Systems initiative (contract DAAD19-01-1-0564). References 1. P. Clements and L. Northrop, Software Product Lines: Prac- tices and Patterns, Addison-Wesley Professional, 2002. 2. K. Schmid and M. Verlage, “The Economic Impact of Prod- uct Line Adoption and Evolution,” IEEE Software, vol. 19, no. 4, 2002, pp. 50-57. 3. A. Ledeczi et al., “The Generic Modeling Environment,” Proc. IEEE Int’l Workshop Intelligent Signal Processing, 2001; www.isis.vanderbilt.edu/publications/archive/Ledeczi_A_5_1 7_2001_The_Generi.pdf. 4. B.C. Pierce, Types and Programming Languages, MIT Press, 2002. Adam Childs is pursuing an MS in computer science at Kansas State University. His research interests include soft- ware architecture, model-driven development, and compo- nent-based software. He is a member of the ACM. Contact him at achilds@cis.ksu.edu. Jesse Greenwald is a research associate in the Department of Computing and Information Sciences at Kansas State University. His research interests include model-driven development and component-based software. Greenwald received an MS in software engineering from Kansas State University. Contact him at jesse@cis.ksu.edu. Georg Jung is a PhD candidate and graduate research assis- tant in the Department of Computing and Information Sci- ences at Kansas State University. His research interests include specification, typing, and verification of software architectures and component-based systems. Jung received a Diplom in computer science from Saarland University, Germany. Contact him at jung@cis.ksu.edu. Matthew Hoosier is a research associate in the Department of Computing and Information Sciences at Kansas State University. His research interests include model-checking and software specification and verification techniques. Hoosier received an MS in computer science from Kansas State University. Contact him at matt@cis.ksu.edu. John Hatcliff is a professor in the Department of Comput- ing and Information Sciences at Kansas State University, where he also leads the SAnToS Laboratory. His research interests include model-driven development, program analy- sis and verification, and software engineering for safety- and mission-critical systems. Hatcliff received a PhD in com- puter science from Kansas State University. He is a mem- ber of the ACM. Contact him at hatcliff@cis.ksu.edu. N o t a m e m b e r ? J o i n o n l i n e t o d a y ! www.computer.org/join