C ov e r F e at u re
Dynamic Variability in SoftwareIntensive Embedded System Families Jan Bosch, Chalmers University Technology, Sweden Rafael Capilla, Rey Juan Carlos University, Spain
Dynamic software product lines address many of the challenges of building highly configurable software and use runtime variability mechanisms to support automatic decision making.
I
n the era of autonomic, self-adaptive, mobile, and increasingly software-intensive embedded systems, a system family that can adapt to new environments and reconfigure and incorporate new functionalities can provide a significant competitive advantage. This trend requires software product lines (SPLs) to become more adaptable and evolvable—in other words, dynamic. Customers also demand that systems continue to evolve after purchase and deployment and allow dynamic binding to services. Large- and medium-sized companies need to use more dynamic approaches to produce software with configuration and extension capabilities at runtime. Dynamic SPLs (DSPLs) leverage current SPL approaches to incorporate runtime properties that make them more adaptable and configurable.1 However, these systems must satisfy stringent quality requirements, including safety, reliability, and performance. Allowing for dynamic extension and reconfiguration creates challenges in verifying the behavior of members of an embedded system family, requiring dynamic variability models to manage system behavior predictability while allowing for dynamicity. As the “Contemporary Runtime Variability Initiatives” sidebar describes, dynamic variability models are a critical and
28
computer
challenging area not well covered by current SPL approaches. Our runtime variability mechanism adds the capabilities needed to change the structural variability at execution time.
TRENDS AND NEEDS IN LARGE-SYSTEM FAMILIES A study of current trends within software-intensive systems reveals several patterns that are key drivers of dynamic and extensible variability. These drivers include the customer, the changing product development life cycle, and the increasing adoption of open innovation, especially in the form of software ecosystems.2
The unique customer For companies that provide software-intensive products, differentiating themselves from their competitors is a clear driver toward creating as many “small batch” products as possible.3 However, this approach obviously lacks the economies of scale required for companies to achieve economic success. Companies such as Nokia have addressed this challenge by developing system families, in which many different products target a single market segment. The user experience resulting from this approach, however, has been unsatisfactory. In response, companies such as Apple have developed an alternative model, in which they produce one or a small number of products while allowing for high degrees of postdeployment personalization, letting customers create a unique product that reinforces their desire for differentiation. Creating these highly customizable mechanisms for users requires significant support for dynamic variability.
Published by the IEEE Computer Society
0018-9162/12/$31.00 © 2012 IEEE
Contemporary Runtime Variability Initiatives
The postdeployment evolution era For virtually all software, the development process traditionally focused on understanding customer needs, building a product that meets the company’s interpretation of those needs, and then shipping the product. However, an increasingly large community is seeking to upset that model, focusing instead on short development cycles and postdeployment software distribution. The main benefit for customers is that the product continues to improve after they have put it into use. Although frequent or continuous software deployment has become the norm for Web 2.0 and software as a service (SaaS), organizations are starting to adopt this technology for traditional installed software as well as embedded software-intensive systems. One effective mechanism for achieving this is to use dynamic and extensible variation points in the software to manage the most critical and replaceable parts, given that embedded systems demand adaptation capabilities that do not require stopping and restarting the system. Fields such as autonomic computing, domotics, and sensor networks have introduced a niche in which DSPLs can play a key role in supporting runtime changes. Adapting systems to a new context requires redeploying them using dynamic approaches instead of static variability models, and then tackling performance and adaptation challenges that arise.
Customizable and context-aware services Cloud and service-oriented architectures (SOAs) are driving this new SaaS trend. Flexibility and low cost are the main factors in service selection, but these factors demand that SaaS providers expand their scale to amortize the cost of development and operations over a sufficiently large number of users. To accomplish this, providers must meet three requirements: •• ••
••
The services must be more customizable to appeal to users in different configurations. The service or service-based platform must offer a relevant level of context awareness so that it can adjust to the context in which the customer is using it. Systems might need to rebind services dynamically to address new quality concerns, as this impacts dynamic service selection. The Business Process Execution Language (BPEL) 2.0 or extensions such as VxBPEL4 support dynamic binding of composite services, which introduces new variants (that is, system features that vary) for dynamically selecting and changing services.
R
untime variability implementations are relatively uncommon in existing commercial and research tools. This is due in large part to customers’ lack of awareness of the advantages and challenges associated with product and service providers guaranteeing system properties. For example, two commercial tools (tools A and B) provide limited runtime variability. (We do not give the companies’ or tools’ real names to avoid any commercial harm to their sales based on characteristics not yet implemented.) Tool A supports using the latest multistage binding times at system start-up. Tool B indirectly supports multiple binding times, which allows stepwise refinements of variant configurations. A connector to Matlab/Simulink models allows dynamic rebinding of variation points. Recent research efforts attempt to tackle the challenge of implementing runtime variability mechanisms. With the emergence of dynamically changing mobile and ubiquitous markets, the Dynamic Variability in Complex Adaptive Systems project (DiVA; www.ictdiva.eu) addresses changing system behavior and identifies the characteristics needed to support these systems’ dynamicity. Furthermore, the ITEA 2 Model-Driven Development of Highly Configurable Embedded Software-Intensive Systems project (MoSiS; www.itea2.org) developed the Common Variability Language for modeling and managing variability of software-intensive systems, with proven use in sectors such as railway signaling and communication.1 CVL models runtime variability transformations and service reconfiguration. Its constructs allow different types of substitutions to configure and reconfigure new versions of base models. Despite these advances, however, current efforts to realize runtime variability in software systems requiring autonomous behavior or highly configurable capabilities lack many of the capabilities necessary for defining and implementing runtime variability mechanisms.
Reference 1. Ø. Haugen et al., “Adding Standardized Variability to Domain Specific Languages,” Proc. Software Product Lines (SPLC 08), vol. 1, IEEE CS, 2008, pp. 139-148.
essary scale of services, which motivates the adoption of DSPLs. Moreover, new SOA product lines attempt to deal with some of these challenges by incorporating runtime mechanisms that can address the diversity of context awareness when SPL members need to evolve after deployment.5
Implications for dynamic variability These trends require levels of dynamicity beyond what contemporary solutions can deliver. Specifically, systems must evolve in three ways: •• ••
Meeting these requirements demands both dynamic and extensible variability approaches to deliver the nec-
Variation points become increasingly dynamic, changing while the system is operating. The set of variants for a variation point can be extended after a system is deployed at the customer site and ultimately while the system is operating.
OCTOBER 2012
29
C ov e r F e at u re ••
Systems increasingly select the variants as they seek to maintain or achieve certain metrics as part of their operation, often referred to as self-*behavior.
Finally, these three factors often imply that new versions of system components will replace earlier versions, and solutions must guarantee system properties in the face of such dynamicity. Runtime variability offers dynamic reconfiguration capabilities for systems requiring continuous or periodic adaptations. In this way, dynamic built-in system features can trigger runtime reconfigurations to activate and deactivate system features when needed, and these features can adapt system behavior to different scenarios. Examples using runtime reconfiguration and autonomic behavior can be found in smart systems6 or sensor networks,7 reinforcing the need for runtime adaptation of feature models that can be reconfigured or restructured dynamically with minimal human intervention.8
Runtime variability offers dynamic reconfiguration capabilities for systems requiring continuous or periodic adaptations.
service-based systems or when mobile software locates and binds to resources on demand (for example, the Bluetooth protocol). In addition, when they bind dynamically to a new system option or when software features are configured at runtime, systems might need to be rebound dynamically to an alternative scenario or a particular configuration.
IMPLEMENTING RUNTIME VARIABILITY Predicting all the variability an SPL needs is impossible, but as the requirements we have described illustrate, DSPLs need customizable mechanisms. Because current feature-modeling approaches lack appropriate mechanisms to manage dynamic properties, some researchers have suggested configuring and managing the runtime variability at the architecture level and using reflectivebased technologies to make their runtime decisions.10-12 However, runtime variability mechanisms require that the dynamic changes made in the system are also aligned to the architecture and feature models. Less important for the structural variability are those configurable user options that are activated at the customer side because they don’t affect the variability model’s current organization. We therefore introduce a mechanism for DSPLs that addresses the dynamic variability requirements.
Changing the structural variability at runtime DYNAMIC VARIABILITY REQUIREMENTS Systems that demand some kind of adaptation require customizable features that can be modified dynamically according to changing needs, and DSPLs must provide support for runtime behavior.9 DSPL models need to implement several characteristics through runtime variability mechanisms. First, these systems must provide adaptable and highly configurable features. In markets such as the mobile field, customers demand increasingly configurable options that can be activated or deactivated at any time. In addition, autonomous systems require context-awareness features to adapt and configure themselves during normal system operation. Second, the models must incorporate and change system features. Smart systems might require adding replaceable hardware-software functionality at runtime, and runtime variability mechanisms must incorporate and reflect these new characteristics dynamically. Finally, to be considered highly reconfigurable, the systems must offer multiple binding options and rebinding capabilities. For example, systems must be able to activate features during configuration and at start-up. Typical scenarios include configuring an operating system kernel or installing a software package after deployment. Scenarios of pure runtime binding occur in
30
computer
To let customers activate, deactivate, and configure built-in features or adapt themselves to new environments, systems can use dynamic libraries and configuration files. These files are either uploaded dynamically when a change demands updating the current system configuration or uploaded from context information sources. Runtime variability lets users select different alternatives and allows runtime reconfiguration, while the structural variability remains unchanged. Adding, changing, or removing features affects a system’s structural variability. Runtime variability mechanisms can change the variants dynamically with no or minimal human intervention and in a controlled manner. As a consequence, the software architect will know which runtime changes affect which architectural and system features.
Types and supertypes of variants Our approach to modifying variants at runtime relies on the notion of types and supertypes. Based on the notion of context variability,13 supertypes serve as general classifiers for variants. Using supertypes, we automate the modification of the variants in the feature model at runtime. (Here, we focus on automating variants’ structural variability because modifying variation points typically requires much more human intervention, but variation points can also support the notion of supertypes.) We define a super-
type, denoted by st, as a list of strings (names) defined by the user and applied to categorize and classify a system feature. V denotes a variant. More concretely, a variant V is a set consisting of
tion, it means moving the variant to a different location in the feature model. When moving variants from one place to another, we can implement the operation as a removal task followed by the addition of the variant. We use the following procedure to add variants:
a list of allowed values belonging to the following basic types: integer, numerical, string, and Boolean; a type, denoted by T, assigned to the values; and a list of compatible supertypes (STs).
1. We compare the variant’s supertype with those of its siblings and parents. 2. If the new variant has the same supertype as its parent and any of its siblings, we can automatically insert it as a child. 3. If the siblings have different supertypes, the new variant can be inserted if its supertype is compatible with any of its siblings’. Otherwise, a new supertype must be defined for the parent before the variant can be included.
•• •• ••
Variants can belong to one or several compatible supertypes. They can have ranges of integers and numerical values (for example, [10 ... 20]), lists of numerical values (for example, 1, 3, 5; 4.5, 6.7), and lists of strings (for example, blue, red, yellow). Supertypes supersede the basic types associated with variants and define additional categories for variants sharing a common functionality. We also define a compatibility rule between supertypes, which we use when the variability model must include a new variant. This compatibility function, named Comp(), is a Boolean function defined as follows: Comp (stA, stB) = 1, if stA is equal to stB; or if stA and stB belong to a list of compatible supertypes Comp (stA, stB) = 0, otherwise Hence, supertypes organize the system variants under shared or compatible categories (defined by the software designer), except for the root node in the feature model. The compatibility between supertypes can be checked by reading configuration files at runtime or querying a database. Compared to static SPL approaches, supertypes ease the modification of the structural variability. We devise three scenarios. First, adding a variant implies that we need to define where it will be located in the feature model. Because we can only add variants with supertypes that are compatible with their siblings and parent, we need to check the compatibility of the supertype and the new variant with respect to those of its siblings and its parent’s. Second, removing a variant means dropping it from the feature tree and removing any logical formula using this variant. Software variability management mechanisms must check the feature’s dependencies on other variants when removing it. (This work does not cover the modification of dependencies between features when modifying the variants, as this is an integral part of software variability management. However, new approaches can suggest ways to manage runtime dependencies, or we could even constrain runtime variability to those changes that do not affect the dependencies.) Finally, changing a variant in its simplest form means changing only its value, whereas in a more complex situa-
Changing a variant in its simplest form means changing only its value, whereas in a more complex situation, it means moving the variant to a different location in the feature model.
4. If supertypes are incompatible, the new variant cannot be added unless we add new supertypes for the existing features or create a new variation point with compatible supertypes. 5. If a new variant has no siblings, we only check the compatibility of the variant’s supertype with its parent’s supertype, as this new variant will be the first feature added under that parent.
An example smart home system We use a simple scenario to demonstrate supertype notion. In this scenario, a smart home system (SHS) remotely controls a smart building’s security, ambient living, and multimedia features. Figure 1a shows a subset of the home’s sample feature model, which consists of three variation points for different functional system features: security, ambient living, and multimedia. The table in the figure defines the supertypes and basic types. For example, the ambient living variation point’s supertype is “ambient,” but the basic variant types are integer (a range of numerical values for the heating system) or Boolean (for example, lights can be switched on or off). We can manage the SHS software manually or automatically, and some options can be controlled remotely using a Web application or mobile phone. The system can also adapt to the ambient living conditions. At runtime, it can detect if a new module or device has been added and then reconfigure itself to incorporate the new functionality.
OCTOBER 2012
31
C ov e r F e at u re
SHS
Security
SHS
Ambient living
Alarm
Lights Camera
Security
Multimedia Home cinema
Heating system
Home cinema
Alarm Heating system
STs: Ambient temperature Basic types Integer Integer, Boolean String
Multimedia
Camera
(a) Supertypes (STs) Security Ambient Multimedia
Ambient living
ST: Ambient
Variant point Variant Dynamically inserted variant
Feature added dynamically
Lights
A/C
STs: Ambient temperature
(b)
Figure 1. Subset of a smart home’s feature model altered dynamically using supertypes: (a) smart home system (SHS) feature model and (b) modified feature model after a new variant is added.
We simulated a new feature’s impact on the variability model by adding an air conditioning module under the ambient living subsystem. We used a basic software prototype to add and change system features dynamically (our software prototype also manages dependency rules between variants and variation points). The feature tree automatically includes the new A/C feature because it has the same supertype as its new parent (ambient living) and the heating system variant. Figure 1b shows the result of this operation. There are many incompatibility scenarios in which variants cannot be added. For example, in Figure 1, the security subsystem does not share compatible supertypes with the multimedia subsystem, and a new feature for controlling the home’s locks cannot be included under the multimedia subsystem. Because new features might fit several supertypes simultaneously, we need policies to determine the exact point at which these features must be anchored, such as to limit the inclusion of features in the selected subsystem.
Dynamic rebinding and multiple binding capabilities Because mobile software and self-adaptive systems increasingly require autonomic behavior, runtime variability mechanisms must provide both dynamic rebinding and multiple binding options following deployment. For example, systems such as mobile software and Internetbased applications demand continuous updates and can bind to services located anywhere.
32
computer
Web services partially solve the rebinding problem in atomic and composite services, and mobile software can also rebind to new functionality offered by telecommunication providers. Automating rebinding mechanisms requires extensive use of runtime variability mechanisms for which we foresee the following three alternatives: ••
••
••
Use dynamic configuration files to update the system configuration. Variability is used to select between alternative configurations. Use variability to select between different choices to provide rebinding capabilities at runtime (for example, approaches for SOA development4). Use built-in variants to select between pure runtime options that are unknown until the user selects one of them (for example, a Bluetooth device).
However, these alternatives do not affect the structural variability described in the feature model. Few systems meet the third dynamic variability requirement—representing multiple binding times at the architecture level and in feature models. Table 1 provides a finer classification of binding times, ranging from static to dynamic. We use the term “pure runtime” to distinguish runtime bindings that occur during the first or every startup from those that occur only when the system is already running. The transition column describes the possible outcomes when multiple bindings occur. For a predominant binding time (for example, pure runtime), we define which binding times are supported simultaneously and which
Table 1. Binding times, ranging from static to dynamic. Binding time
Static/dynamic binding
Design
S
Configurability
N/A
Single/multiple binding times
SI
Binding on the developer/customer side
D
Transition for multiple binding times
N/A
Compilation/link
S
Low
SI
D
N/A
Build/assembly
S
Low
SI
D
N/A
Programming
S
Medium
SI
D
N/A
Configuration (Cf)
S/D
Medium/high
SI/MU
D/C
Cf→Dpl Cf→RT
Deploy (Dpl) and redeploy (Rdpl)
S/D
Medium/high
SI/MU
D/C
Dpl→Rdpl Rdpl→Cf
Runtime (RT) (start-up)
D
High
SI/MU
C
Dpl→RT Rdpl→RT RT→Rdpl RT→Cf
Pure runtime (PRT) (operational mode)
D
Very high
SI/MU
C
RT→PRT PRT→Cf Cf→PRT PRT→PRT
systems or software applications can bind to a different operational mode. Furthermore, our approach is compatible with feature binding units (that is, a set of features that need to be bound together14) because supertypes classify features with common functionality.
APPLICATION DOMAINS Several trends are driving the need for dynamic and extensible variability. Here, we discuss the current and expected future adoption of dynamic variability in specific application domains.
Software as a service SaaS will likely lead dynamic variability adoption. Various companies already use dynamic and extensible variability techniques for A/B (or split) testing as well as for customization and personalization. A/B testing in particular requires extensible variability because new experiments are added to the system continuously, run for a period of time while collecting data, and then are subsequently removed. A/B testing also requires dynamic selection of variants given that versions are assigned to customers randomly. Future SaaS software will likely increasingly incorporate the user’s current context to provide an optimal user experience. This requires dynamic and extensible variability mechanisms to deal with current and changing context.
Desktop software Modern desktop operating systems frequently deploy new software on their installed base, with the deployment taking place in terms of individual components. As
the granularity of the unit of deployment decreases and deployment frequency increases, dynamic and extensible variability becomes increasingly important. The need for effective rollback mechanisms that let users return their systems to an older, but working, configuration exacerbates this issue. Application software installed in customer systems is experiencing similar developments. A prime example is the Google Chrome browser, which updates itself automatically and continuously. With SaaS increasingly assuming the traditional role of desktop software, developers will likely increasingly focus on functionalities not easily implemented using SaaS. These functionalities include context awareness and other technologies that dynamically change in the user’s context and are recognizable by the device. This change will increase the need for dynamic and extensible variability mechanisms.
Mobile The mobile device and application industry has adopted many of the principles already applied in the desktop software domain. In addition, modern mobile operating systems (for example, iOS and Android) and mobile applications use postdeployment dynamicity to continuously evolve the deployed system and to increase its customization and personalization capabilities. Going forward, we can expect mobile devices to increasingly act as an interface between the user and the devices and infrastructure in the current user context. This requires dynamic and context-specific incorporation and removal of variation points and variants as new devices,
OCTOBER 2012
33
C ov e r F e at u re such as a printer or external screen, become available or are no longer necessary.
Automotive The automotive industry is another domain expected to see growth in dynamic variability. Because cars and trucks are among the most expensive purchases individuals and companies make, they will likely be the first to broadly offer network connectivity. Once a system is connected to the Internet—and, according to Ericsson, 50 billion devices will have that capability by 2020 (www. ericsson.com/res/docs/whitepapers/wp-50-billions.pdf)— the need for postdeployment, dynamic, and extensible variability increases significantly. Consequently, we predict the automotive industry will broadly adopt the techniques discussed in this article in the near future, although obviously starting in areas with no or limited safety implications.
Other areas We envision four key application areas for runtime variability: ••
•• ••
••
use variability mechanisms to update system functionality without disruption while allowing easy rollback, facilitate customization and personalization of functionality, enact A/B tests to prove new or alternative implementations of existing or new functionality by modeling the A and B alternatives for a variation point, and facilitate effective context-aware and self-*behaviors by systems through dynamic selection of existing and new variants.
Eventually, this technology will be applied in all domains where software plays a significant and increasingly important role, including industrial automation, healthcare, and logistics.
C
ontrolled automatic decision making about software capabilities is possible, and runtime variability mechanisms can facilitate the dynamic selection of designs. Emerging DSPL approaches treat automatic decision making as an optional characteristic because the decision to change or customize a feature is sometimes left to the user. In systems where human intervention is impossible or extremely difficult, runtime variability can help facilitate autonomic decision making. For example, a robot sent to Mars might find that a change ordered remotely by a human is not possible because of lost communication. In addition, although dynamically added features might have different priorities based on varying context conditions,
34
computer
we can use priority lists to determine the order in which features must be activated, or use state machines.15 Using a supertype-enabled DSPL to introduce new system features is another case in which certain decisions can be automated even if they affect the structural variability model. These supertypes broaden the traditional static feature model to support modifying variability at runtime and group system features by common functionality. Furthermore, supertypes facilitate the visualization of large variability models for use in filtering out subsets of system variants, in particular when the number of variants exceeds the screen’s visualization capabilities. Although runtime variability handles system evolution better than a static feature model and empowers automatic and autonomic decision making to manage unpredicted conditions, more complex changes still require human intervention.
References 1. S.O. Hallsteinsen et al., “Dynamic Software Product Lines,” Computer, Apr. 2008, pp. 93-95. 2. J. Bosch, “From Software Product Lines to Software Ecosystems,” Proc. Software Product Line Conf. (SPLC 09), ACM, 2009, pp. 111-119. 3. P. Barnes, Capitalism 3.0: A Guide to Reclaiming the Commons, Berrett-Koehler Publishers, 2006. 4. M. Koning et al., “VxBPEL: Supporting Variability for Web Services in BPEL,” Information and Software Technology, vol. 51, no. 2, 2009, pp. 258-269. 5. H. Gomaa and K. Hashimoto, “Dynamic Software Adaptation for Service-Oriented Product Lines,” Proc. Software Product Line Conf. (SPLC 11), ACM, vol. 2, 2011, article 35. 6. C. Cetina et al., “Designing and Prototyping Dynamic Software Product Lines: Techniques and Guidelines,” Proc. Software Product Line Conf. (SPLC 10), Springer-Verlag, 2010, pp. 331-345. 7. N. Gámez, L. Fuentes, and M.A. Aragüez, “Autonomic Computing Driven by Feature Models and Architecture in FamiWare,” Proc. 5th European Conf. Software Architecture (ECSA 11), LNCS 6903, Springer, 2011, pp. 164-179. 8. C. Cetina et al., “Strategies for Variability Transformation at Run-Time,” Proc. Software Product Line Conf. (SPLC 09), ACM, 2009, pp. 61-70. 9. R. Capilla and J. Bosch, “The Promise and Challenge of Runtime Variability,” Computer, Dec. 2011, pp. 93-95. 10. M. Goedicke, C. Köllmann, and U. Zdun, “Designing Runtime Variation Points in Product Line Architectures: Three Cases,” Science of Computer Programming, vol. 53, no. 3, 2004, pp. 353-380. 11. N. Bencomo et al., “Reflective Component-Based Technologies to Support Dynamic Variability,” Proc. Workshop on Variability Modelling of Software-Intensive Systems (VaMoS 08), ACM, 2008, pp. 141-150. 12. R. Froschauer, A. Zoitl, and P. Grünbacher, “Development and Adaptation of IEC 61499 Automation and Control Applications with Runtime Variability Models,” Proc. Conf. Industrial Informatics (INDIN 09), IEEE CS, 2009, pp. 905-910.
Jan Bosch is a professor of software engineering and director of the Software Research Center at Chalmers University Technology, Sweden. His research interests include open innovation, software ecosystems, software product families,
and software variability management. Bosch received a PhD in computer science from Lund University, Sweden. Contact him at
[email protected]. Rafael Capilla is a tenured assistant professor in the Department of Computer Science and heads the Software Architectures and Internet Technologies research group at Rey Juan Carlos University, Spain. His research interests include software architectures, product line engineering, and variability management. Capilla received a PhD in computer science from Rey Juan Carlos University. Contact him at
[email protected].
Selected CS articles and columns are available for free at http://ComputingNow.computer.org.
SubScribe TodaY
13. H. Hartmann and T. Trew, “Using Feature Diagrams with Context Variability to Model Multiple Product Lines for Software Supply Chains,” Proc. Software Product Line Conf. (SPLC 08), IEEE CS, 2008, pp. 12-21. 14. J. Lee and K.C. Kang, “A Feature-Oriented Approach to Developing Dynamically Reconfigurable Products in Product-Line Engineering,” Proc. Software Product Line Conf. (SPLC 06), IEEE CS, 2006, pp. 131-140. 15. I. Montero, J. Peña, and A. Ruiz-Cortés, “Representing Runtime Variability in Business-Driven Development Systems,” (ICCBSS 08), IEEE CS, 2008, pp. 228-231.
IEEE Software offers pioneering ideas, expert analyses, and thoughtful insights for software professionals who need to keep up with rapid technology change. It’s the authority on translating software theory into practice.
www.computer.org/ software/subscribe
OCTOBER 2012
35
