Nowadays achieving green software by reducing the overall energy consumption of the software is becoming more and more important. A well-known solution is to make the software energy-aware by extending its functionality with energy optimizers, which monitor the energy consumption of software and adapt it accordingly. Modular design of energy-aware software is necessary to make the extensions manageable and to cope with the complexity of the software. To this aim, we require suitable methods that guide designers through the necessary design activities and the models that must be prepared during each activity. Despite its importance, such a method is not investigated in the literature. This paper proposes a dedicated design method for energy-aware software, discusses a concrete realization of this method, and—by means of a concrete example—illustrates the suitability of this method in achieving modularity

Aksit, Mehmet

Bergmans, Lodewijk

Bockisch, Christoph

Brinke, Steven te

Malakuti, Somayeh

English

te Brinke, Steven

Akşit, Mehmet

NARCIS 

A design method for modular energy-aware software

Nowadays reducing the overall energy consumption of soft-ware is important. A well-known solution is extending the functionality of software with energy optimizers, which mon-itor the energy consumption of software and adapt it accord-ingly. To make such extensions manageable and to cope with the complexity of the software, modular design of energy-aware software is necessary. Therefore, this paper proposes a dedicated design method for energy-aware software

Steven Te Brinke

Somayeh Malakuti

Christoph Bockisch

Lodewijk Bergmans

CiteSeerX

Nowadays reducing the overall energy consumption of software is important. A well-known solution is extending the functionality of software with energy optimizers, which monitor the energy consumption of software and adapt it accordingly. To make such extensions manageable and to cope with the complexity of the software, modular design of energy-aware software is necessary. Therefore, this paper proposes a dedicated design method for energy-aware software

A Design Method For Modular Energy-Aware Software

University of Twente Research Information

A Design Method For Modular Energy-Aware SoftwareSteven te Brinke, Somayeh Malakuti, Christoph Bockisch, Lodewijk Bergmans, andMehmet AkşitUniversity of Twente – Software Engineering group – Enschede, The Netherlands{brinkes, malakutis, c.m.bockisch, bergmans, aksit}@cs.utwente.nlABSTRACTNowadays reducing the overall energy consumption of soft-ware is important. A well-known solution is extending thefunctionality of software with energy optimizers, which mon-itor the energy consumption of software and adapt it accord-ingly. To make such extensions manageable and to cope withthe complexity of the software, modular design of energy-aware software is necessary. Therefore, this paper proposesa dedicated design method for energy-aware software.Categories and Subject DescriptorsD.2.2 [Software Engineering]: Design Tools and Tech-niques—Modules and interfacesGeneral TermsDesign, PerformanceKeywordsenergy-aware software, modularity, design method1. INTRODUCTIONGreen computing emphasizes the need for reducing the en-vironmental impacts of IT solutions by reducing their energyconsumption. Green computing can be achieved by makingsoftware energy-aware by augmenting it with so-called en-ergy optimizers, which monitor the energy consumption ofthe software during its execution and optimize it accordingly.Today’s software is already facing the problem of com-plexity [7], and extending its functionality with energy opti-mizers increases this problem. Modularization is commonlyconsidered as means to cope with the complexity of the soft-ware, because the scope of focus can be reduced to individualmodules [6], which communicate with each other throughwell-defined interfaces.To cope with the complexity of energy-aware software, weclaim that energy optimizers must be modularized. This canPermission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SAC’13, March 18–22, 2013, Coimbra, Portugal.Copyright 2013 ACM 978-1-4503-1656-9/13/03 ...$15.00.Figure 1: Resource-Aware Component Notationbe understood as the separation of the functional and opti-mization concerns. Energy optimizers need to gather nec-essary information from functional components to optimizetheir energy consumption. For exchanging this information,functional and optimizer components must provide suitableinterfaces to each other. Along this line, we have proposeda dedicated notation for modeling such components [5].However, a modeling notation is not sufficient to achievemodularity in the design of energy-aware software. In thispaper, we propose a design method to guide designers throughthe activities performed to identify and modularly design (1)necessary components and the energy-specific interfaces ofthese components, (2) the models that must be preparedduring each activity, and (3) the analysis that must be per-formed on the models. More details of the design methodand a concrete realization to modularly design a real-lifemedia player are described in a technical report [2].2. NOTATION FOR COMPONENTSFigure 1 depicts a notation—which we proposed earlier[5]—for modeling resource-aware components. We considerenergy as a special kind of resource; a component may con-sume various resources, which eventually may lead to theconsumption of energy. Therefore, such resources must alsobe taken into account. The provided services, required ser-vices, provided or required resources are specified in termsof a name and signature of a single attribute.In contrast to the services and resources, the resource uti-lization model (RUM) of the component is more complex,because it represents the relations between all the servicesand resources provided and required by the component. TheRUM is represented as the light gray box inside the compo-nent and exposed through the octagonal port; each compo-nent has only one RUM. It has already been proposed toexpress the RUM as a state chart in which states are anno-tated with resource behavior, and invocations on the servicesof the component are modeled as transitions.1180Model resource behaviorModel resource portsModel service portsIdentifyfunctionalcomponentsIdentifyoptimizercomponentsIdentifyuser components[consistent and complete][consistent and complete][consistent and complete][inconsistent or incomplete][inconsistent or incomplete][inconsistent or incomplete]Analyze system resource behavior[consistent and complete][inconsistent or incomplete]Select most suitable optimizer componentsFigure 2: Design method for energy-aware software3. DESIGN METHODThis paper proposes a method to design energy-awaresoftware systems such that modularity is achieved in thedesign of such systems. Figure 2 is a UML activity diagramthat depicts the activities that are performed in our designmethod, along with the order and dependency of activities.The activities are depicted as boxes and each activity resultsin a model. The arrows represent the order of activities; theactivities between bars can be performed in any order. Thediamonds represent points in our method where the modelsare evaluated and possibly are redesigned iteratively, e.g.,by changing the decomposition, or adding details. The ac-tivities result in a set of modeled components, which arerepresented in the notation depicted in Figure 1.While our design method can always be applied with penand paper, if automatic analyses are desired, a tool mustbe used. In a technical report [2], we present more detailsabout the design method and our concrete experience withthe model checker Uppaal.3.1 Identify componentsAt the top of the diagram are the activities for identifyingthe software components. The design method distinguishesthree kinds of components: functional, user and optimizer.The functional components refer to both software andhardware components which form the target system; eachcomponent implements part of the functionality of the sys-tem and interacts with other components to accomplish theoverall functionality. Since there are already various guide-lines for modularizing functional aspects of software [6, 3],our method suggests to adopt an existing guideline to iden-tify functional components.The way in which users interact with software can have alarge influence on the overall energy consumption [4]. For ex-ample, if a media-player application adopts a caching mech-anism, caching would not be effective if a user disturbs thenormal stream of video by seeking forward and backward.Therefore, to be able to analyze the effectiveness of an opti-mization strategy, it is needed to model the usage scenarios.Since it is not possible to foresee all possible usage scenar-ios, it is desirable to at least model most common scenarios.Our design method represents these scenarios as user com-ponents. To facilitate analysis of resource consumption, wepropose to model deterministic user behavior.The optimizer components monitor and adapt the resourceconsumption of functional components during execution. Forthis matter, they interact with functional components. Ourdesign method distinguishes optimizer components from otherfunctional components to emphasize that they must be mod-ularized so that various optimization strategies can be usedinterchangeably during the concrete design.3.2 Model portsThe service ports of a component represent the function-ality provided and required by the component. These portsare part of the interface of the component and must be mod-eled after the components are identified.Both software and hardware functional components canprovide and consume resources; the kind of resources may bedifferent for hardware and software components. For exam-ple, a hardware device consumes electric energy as resource;whereas a software component may require a network con-nection or a buffer as a resource.To be able to analyze resource consumption of compo-nents, the provided and required resources must be spec-ified as the interface of the components. In addition, theinter-connection among the components must be specified sothat a provided resource can be consumed by other compo-nents. Therefore, our design method proposes the followingapproach for modeling the resource ports.First, identify a resource with respect to which the soft-ware should be optimized and the components that directlyrequire this resource. Second, add the corresponding re-quired resource ports to these components. Componentsthat consume the resource of interest in general also provideresources which relate to the resource of interest (e.g., be-cause they consume the initial resource in order to provideanother resource at a higher abstraction level). Such relatedresources must be added as provided resource ports to thecomponents. This activity must be applied recursively untilall relevant resources are identified.3.3 Model resource behaviorAfter modeling the components and their interfaces, wemodel their resource behavior. The resource behavior is thedynamic resource consumption and provision of componentsduring their execution, and we represent them via RUMs(see Figure 1). This dynamic relation can, for example, in-clude the following information: which resources are con-sumed or produced by each service port, and how switchingamong the services influences the resource consumption.RUMs are energy state charts [1] that represent the re-source behavior of components. The RUM of a componentcan be modeled, for example, through the following activi-ties.Start by identifying states with distinct functional behav-1181ior of a component, for example, by considering the function-ality defined as service ports, or by referring to the require-ments or hardware specification. Define transitions betweenthese states that can happen at events related to service in-vocation and possibly other events such as time-outs. Next,add the resource consumption to the model by annotatingeach state with the amount of resources it consumes or pro-duces; thereby you must refer to the required and providedresource ports of the component.States with multiple characteristics of resource usage mustbe split into multiple states. Now, identify the possible tran-sitions between these new states and the already existingstates, and events triggering these transitions. This stepmust be applied recursively until all states have a singlecharacteristic of resource consumption.3.4 AnalysisOur design method considers checking activities after eachmodeling step. Examples of checks are: checking whetherany component is missing; checking whether the requiredinterfaces of components are bound to compatible providedinterfaces of other components, etc. If a model fails suchchecks, the initial activities are performed again in a newiteration to improve the design until it passes the checks.When at least an initial version of all models exists, theeffectiveness of various optimizer components can be ana-lyzed. Specific to our method is the analysis of the system’sresource behavior using RUMs. This can, for example, beused to analyze which optimization results in the least re-source consumption. Based on this analysis, designers canselect a composition for the final system design using themost suitable one among alternative optimizer components.4. RELATED WORKThis section discusses two categories of related work. Foreach category, we only compare our work with one represen-tative paper. A more extensive review of related work canbe found in a technical report [2].A wide range of techniques and mechanisms are proposedfor making software green. However, there is a lack of meth-ods and techniques that take software modularity into ac-count. For example, adopting the solution proposed by Gotzet al. [4] requires to design and implement the software suchthat it complies with their component model. However, thismight not be an effective solution; first because large-scalecommercial software might not be implemented in this com-ponent model; and second there are already a large numberof legacy software systems that must be extended with en-ergy optimization functionality, and re-implementing themaccording to a new component model might not be consid-ered suitable. In our design model we reused the existingnotation and activities to design modular software and ex-tended them with energy-specific notations and activities.This paper focuses on optimization of energy usage, butour work can more generally be used to specify the software’susage of arbitrary resources. This relates to modeling thenon-functional properties of services. Zschaler [8] proposesa semantic framework for the specification of non-functionalproperties. This framework allows checking whether a cer-tain composition meets the quality goals. However, theframework only reasons about a single composition; it doesnot know how the composition can be improved. Therefore,Zschaler’s approach does not support optimization. In con-trast, our approach specifies the amount of resource usageand how this can be influenced, to facilitate optimization.5. CONCLUSIONS AND FUTURE WORKThis paper discussed the need for designing energy-awaresoftware in a modular way, and proposed a method for thismatter. We also applied the method to a media-player asa case study. This case study, including more details aboutour approach, is described in a technical report [2].One of the challenges when applying the approach is howmuch detail should be added to resource utilization models.RUMs are part of the interface of a component, so it is de-sired that RUMs do not contain any implementation details.However, some implementation details might be needed toexplain the resource behavior. This increases the coupling:Controllers that depend on the precise resource behaviorgiven in the RUM, might not be applicable to implemen-tations that have different resource behavior. Therefore, itmight be desired to add less detail to the RUM, even thoughit could hinder some optimization strategies. We will ad-dress the desired level of detail in RUMs in future work.As future work we will apply this method to large-scalesystems such as industrial printers. In addition, we willextend our notation to be able to model diverse kinds ofadaptation actions that energy optimizers can perform onfunctional components. We will also investigate suitableprogramming mechanisms to implement and modularize thesoftware that is designed according to our method; aspect-oriented languages are among our first candidates.6. REFERENCES[1] L. Benini, R. Hodgson, and P. Siegel. System-levelpower estimation and optimization. In Proc. Int.Sympos. Low Power Electron. Des., pages 173–178,Aug. 1998.[2] S. te Brinke, S. Malakuti, C. M. Bockisch, L. M. J.Bergmans, and M. Akşit. A design method for modularenergy-aware software. Technical ReportTR-CTIT-12-28, Centre for Telematics and InformationTechnology, University of Twente, Enschede, Nov. 2012.[3] J. Garland and R. Anthony. Large-Scale SoftwareArchitecture: A Practical Guide using UML. Willey, 1stedition, 2003.[4] S. Gotz, C. Wilke, S. Cech, and U. Assmann.Architecture and mechanisms for energy auto tuning.In Proc. Sustainable ICTs and Management Systemsfor Green Computing, 2012.[5] S. Malakuti Khah Olun Abadi, S. te Brinke, L. M. J.Bergmans, and C. M. Bockisch. Towards modularresource-aware applications. In Proc. 3rd Int. Workshopon Variability & Composition (VariComp 2012), pages13–17, New York, March 2012. ACM.[6] D. L. Parnas. On the criteria to be used indecomposing systems into modules. Commun. ACM,15(12):1053–1058, Dec. 1972.[7] W. Royce. Improving software economics-top 10principles of achieving agility at scale. White paper,IBM Rational, May 2009.[8] S. Zschaler. Formal specification of non-functionalproperties of component-based software systems.Software and Systems Modelling, 9:161–201, 2009.1182

Steven te Brinke

Mehmet Akşit

Crossref

A tutorial on Uppaal.

Architecture and mechanisms for energy auto tuning.

ECOSystem: managing energy as a ﬁrst class operating system resource.

Energy types.

Energy-driven integrated hardware- software optimizations using SimplePower.

Formal speciﬁcation of non-functional properties of component-based software systems.

Formal veriﬁcation of UML statecharts with realtime extensions.

Green software.

Improving software economics-top 10 principles of achieving agility at scale. White paper, IBM Rational,

Large-Scale Software Architecture: A Practical Guide using UML. Willey, 1st edition,

On the criteria to be used in decomposing systems into modules.

Precise service level agreements.

Sustainable software development.

Towards modular resource-aware applications.

A design method for modular energy-aware software

Abstract

Similar works

Full text

Available Versions

NARCIS

CiteSeerX

NARCIS

University of Twente Research Information

University of Twente Research Information

Crossref