Mapping Non-Functional Requirements To Cloud Applications
Mapping Non-Functional Requirements to CloudApplicationsDavid Villegas and S. Masoud SadjadiSchool of Computing and Information SciencesFlorida International UniversityMiami, Florida{dvill013, sadjadi}@cs.fiu.eduAbstract—Cloud computing represents a solution for applications with high scalability needs where usage patterns, andtherefore resource requirements, may fluctuate based on externalcircumstances such as exposure or trending. However, in orderto take advantage of the cloud’s benefits, software engineersneed to be able to express the application’s needs in quantifiable terms. Additionally, cloud providers have to understandsuch requirements and offer methods to acquire the necessaryinfrastructure to fulfill the users’ expectations. In this paper, wediscuss the design and implementation of an Infrastructure as aService cloud manager such that non-functional requirementsdetermined during the requirements analysis phase can bemapped to properties for a group of Virtual Appliances runningthe application. The discussed management system ensures thatexpected Quality of Service is maintained during execution andcan be considered during different development phases.I. I NTRODUCTIONThe emergence of cloud computing responds to a increasingtrend in web application emergence and utilization. The wideadoption of Internet has resulted in systems that need toaccomodate millions of users [1] and provide capabilities thatuntil now were only required by critical, high availabilityor high throughput software. The practice of Software Engineering provides methodologies to ensure such characteristicsare met, but it is necessary to review how they fit in thisnew paradigm. In this paper, we explore the applicability oftraditional processes to the incipient field of cloud computingfrom the perspective of our research in an Infrastructure as aService (IaaS) cloud manager.Internet has resulted in rapid cycles of software development, deployment and consumption by users. The risingnumber of subscribers, better network connectivity and bandwidth, and the growing connectedness between users havecreated new dynamics where applications can be rapidlydiscovered and consumed. However, the benefits produced bythese circumstances are hindered when expected requirementsare not met. Nowadays, cloud computing is often employedas a solution to this problem. Capabilities such as pay-peruse, scalability or elastic provisioning of resources can helpto overcome these new challenges. Nevertheless, applicationdevelopers need to recognize how to apply Software Engineering methods to the cloud in order to successfully map theirneeds to fulfill service expectations.There are two interrelated points that we believe have tobe considered to successfully make use of clouds to developapplications that respond to the new demands generated in thisfield. First, developers must understand which non-functionalrequirements take renewed importance in cloud applicationsso that they can be accounted for during the requirementsanalysis phase. Second, cloud providers need to define betterguarantees for their services, so developers can design theirsystems accordingly. We believe that providing a solution tothese problems will result in a more dependable use of cloudsto confront the new challenges of this era.In this paper we consider the concept of Distributed Ensembles of Virtual Appliances (DEVAs), introduced in [2], asa model to represent complex systems with Quality of Service(QoS) guarantees. We discuss how a software architecturecan be mapped to a DEVA, and how through the use ofperformance modeling and prediction we can make certainassurances about its behavior in the cloud in order to addressits non-functional requirements. We finally present a casestudy were we demonstrate the feasibility of our approachto model the expected number of requests per second andresponse time of a web application hosted in the cloud.II. BACKGROUNDWe define a cloud application as any software that runs on adistributed system that complies with the definition of a cloud.Such systems ([3], [4]) possess certain common capabilitiessuch as on-demand provisioning, resource elasticity or payper-use billing model. Therefore, cloud applications can bedeployed on remote resources with a minimal cost, and scaleddynamically when user demand grows.We consider three main actors in our scenario: applicationusers, application providers, and cloud providers. In thisproposed division, application providers also have the role ofcloud users, even though in certain cases it would be possiblethat application and cloud providers are the same individualor organization. The cloud is usually divided in Software,Platform and Infrastructure as a Service [3] —SaaS, PaaSand IaaS respectively. Application providers are in charge ofimplementing the SaaS layer, while the PaaS and IaaS layersare supplied by cloud providers.A DEVA [2] is a group of Virtual Appliances and virtualnetwork devices, where individual and composite policies canbe defined for elements. Virtual Appliances [5] are Virtual
UptimeFig. 1.General architectureThe total time the service is available. It may be expressedas a percentage. When considering this requirement, it isnecessary to take into account the provider’s own uptime.For example, if a provider has an uptime of 99.5%, it wouldbe impossible to deploy an application with a higher uptime.Other factors involve the recoverability of the system (i.e.,how much time it takes to restart the service after a failurehappens).Requests per unit of timeMachines with specific functions, usually containing a particular software and configuration; for simplicity, we’ll use themore general term VM to refer to them. Figure 1 illustrates thearchitecture of the DEVA Manager. A user sends a specification for a list of VMs and their associated QoS requirements,which may consist of CPU, memory and required software forindividual VMs, and network bandwidth and latency for thenetwork links. Then, the Manager instantiates the ensembleacross heterogeneous resources, which may be located indifferent administrative domains. A group of agents monitorseach VM’s behavior and provides the requested QoS andnetwork isolation.III. R EQUIREMENT ANALYSIS AND ARCHITECTURALDESIGNIn Software Engineering, the requirements analysis phaseis in charge of determining the functional and non-functionalrequirements of the system based on the client’s needs. Inparticular, non-functional requirements [6] describe the characteristics of the system not related to its functionality. Theserequirements shape the architecture of the system during thedesign phase.In this paper we target a class of applications that arespecially suited to be hosted in the cloud and have a prevalentset of non-functional requirements. Identifying them allowsdevelopers to ensure that they are addressed during the requirement analysis phase, and establish a set of requisites that mustbe met by cloud providers in order to quantify their serviceand ascertain the application goals are met successfully. Weenumerate the most salient ones next.Response timeThis requirement describes how much time it takes fromthe moment a user sends a request to the system, until acomplete response is provided. In web applications, this comprehends request transmission and processing, and responsetransmission. The factors that account for it are resource capabilities —processing power, memory, disk, network latencyand bandwidth— and the load produced by other processesrunning in the server or the number of concurrent requests.For complex requests, this may also involve calls to externalsystems, or to other subsystems, in which case the host’sinternal network characteristics and other resources’ load maybe taken into account.This requirement describes the number of requests thesystem can handle successfully per unit of time, and can alsobe referred to as the system’s throughput. Resource allocationand usage has an impact in this parameter. Additionally, thenumber of requests can have an impact in the response timerequirement (i.e., a high number of requests will result in adeterioration of the overall response time).Fault toleranceOne of the system’s properties is how it can withstanderrors, either hardware or software-based. In the case of cloud,non-software errors can be generated either at the physical orthe virtual machines hosting the service. While the first case isusually out of the developer’s control, virtual machine faultscan be handled by different means, for example by spawningnew instances, or having backup VMs to respond to failures.SecuritySecurity is another requirement that can be applied tothe cloud provider or to the developed system. In the firstcase, the application developer is under the provider’s securitymeasures such as physical infrastructure access policies ornetwork isolation mechanisms. Alternatively, security in theinstantiated VMs must be handled by the cloud user.Operational costIn traditional systems, hardware was determined based onthe application’s initial requirements. Changes in requirements would typically result in costly upgrades involving theacquisition of new physical machines and installation andconfiguration of the application to run on them. In cloudsystems, resources can be upgraded almost instantaneously,meaning that cost can be considered a changing variable.This allows defining tradeoffs to architectural (static) andoperational (dynamic) behavior.During the requirements analysis, it is the job of the software engineer to give appropriate values to each of the nonfunctional requirements according to the user’s expectations.Each of these parameters needs to be reflected in one or morearchitectural decisions and tradeoffs.
IV. M APPING R EQUIREMENTS TO DEVA SThe original implementation of the DEVA Manager acceptsthree types of parameters: nodes (VMs and virtual networkdevices), edges between nodes, and element annotations. Basicannotations describe node and edge characteristics such asVM processor power or memory size, and link bandwidth andlatency, respectively.An application developer could map the assigned nonfunctional requirement values to any of the discussed DEVAparameters in order to ensure the application’s operationalguarantees. For example, the number of desired requests persecond would influence the assigned latency for the linksbetween VMs; alternatively, the targeted response time couldtranslate to a minimum processing power for the VMs in theensemble.However, this process is complicated and error-prone: therelationship between non-functional requirements and lowlevel values is in many cases difficult to determine, andmany factors can take part in the fulfillment of one individualparameter. Thus, we propose an extension to our system wherenon-functional requirements can be directly mapped to theexecution platform, not only during the deployment phase, butalso along the whole design process.Our proposed approach in this paper extends DEVA annotations with new high-level values that correspond to nonfunctional requirements. An underlying application-dependentmodel is in charge of translating high-level parameters to lowlevel ones, and performing the required operations on theappropriate elements. We describe our system design next, anddiscuss its implementation.Fig. 2.Extended architectureA. Processing annotations for DEVAsOnce the user defines a set of nodes, edges and annotations,a request is sent to the DEVA manager, which parses itand assigns the virtual resources to physical hosts that cancomply with the requested QoS parameters. At each host, anumber of VMs and virtual network links are created so thatthe ensemble appears as an isolated group of machines withdedicated resources. Additionally, a set of DEVA Agents arein charge of monitoring the infrastructure usage and ensuringglobal and individual QoS.Requirements in the request are realized in two phases:first, the scheduling module of the manager chooses the targetresources so that the ensemble requirements can be met. Thisimplies selecting hosts with enough free memory and CPU forthe VMs and ensuring the underlying physical network will beable to support the requested bandwidth and latency. Second,control measures are applied to constraint resource usage sothat shared requests don’t interfere among them. VM resourcesare adjusted by a Virtual Machine Monitor such as Xen orVMWare running in the target host, while network resourcesare controlled by a DEVA Agent. Agents apply shaping andmonitoring to manage network QoS.In order to implement high-level annotations representingnon-functional requirements, we need to extend the DEVAmanager and agents so that the new parameters can betranslated into the existing ones. Figure 2 shows the systemarchitecture with the new components in a darker shade.First, the manager needs to translate non-functional requirements into values that can be considered as part of thescheduling process. We provide a non-functional requirements(NFR) Parser that is in charge of converting high-level valuesto low-level ones. For this, a Static Application Model isemployed. Such model is dependent on the type of application,and can be defined either theoretically or empirically. Wedefine a global annotation for the request, where the user canspecify the application type. The value of this annotation willdetermine the model to use in the scheduler.The Non-Functional Requirements Parser generates a set ofrequirements for nodes and connections based on the translatedparameters, and these are fed to the scheduler, which takesthem into account to generate a list of physical machinecandidates. Each of the candidates is assigned a number ofVMs to host. Finally, the Infrastructure manager, implementedin our system by OpenNebula [7], sends instantiation requeststo Hypervisors and the DEVA Agents in charge of the dynamicbehavior of the application.After VMs are instantiated, DEVA Agents create a virtualnetwork in the hosting machines. In our proposed architecture,we extend the system by adding three new components inthe agents: First, we define an additional monitoring modulewith application dependent rules. While the basic componentreads values such as CPU, memory and bandwidth usage, newvalues need to be contemplated in order to track non-functionalrequirements compliance. Examples of this are requests persecond for a web server or database transactions for a databaseserver. The application-dependent monitoring module can beextended based on different applications. All agents send themonitored data to the DEVA Manager, where the data isaggregated to determine high-level actions.The second change in the DEVA Agents consists in an Application Management module similar to the existing NetworkManagement component. While the later one is in charge ofdetermining low-level actions to maintain network QoS, thenew subsystem needs to consider high-level requirements andsend them as an input to the other module. The third modification of the agent, the Dynamic Application Model, provides
the mapping based on a model of the application’s behavior.Contrarily to the Non-Functional Requirements Parser and theStatic Application Model, the components in the agent canalso consider the runtime state of the application.B. Model-based translation of non-functional requirementsThere are two modules with the task of translating nonfunctional —high level— to infrastructure or low-level requirements. As stated in the last section, the first one considers the static behavior of the application and provides thenecessary criteria to the scheduler, while the second one takesinto account the dynamic state of the application. There aredifferent approaches in the literature to modeling applicationperformance such as [8] or [9], which can be divided intothe categories of empirical, theoretical and on-line simulationmodels.The first category corresponds to those models createdfrom the application’s off-line execution. Requirements canbe inferred by observing the behavior of the system underdifferent conditions and creating a model that can be later usedto obtain approximate parameters to provide to the underlyingmanagement system. These models are usually measured bytreating the application as a black-box (i.e., without employingany knowledge of the internal implementation or design).The second category consists of creating a mathematicalmodel to relate the application’s characteristics to its requirements. In this case, knowledge about the internal implementation is used to quantify the application’s behavior based onavailable resources.Finally, some models perform on-line (runtime) simulationof the application in order to find its behavior for a certaininput. Simulations can be either event-based, for which anabstract model is created to approximate the behavior undercertain conditions, or real-time, where a part or the wholeapplication is executed to predict how the real system wouldbehave.Our system does not make any assumptions about themodels used to map non-functional requirements to low-levelones. In fact, any of these could be employed either for thestatic or the dynamic modules in the manager and the agents.The basic prerequisite is that the used model understandsthe application’s requirements and is able to determine aset of values that can be expressed via DEVA annotations.Some models may consider individual components of thesystem separately, while others contemplate complex relationsbetween modules and how changes in one may affect others.C. Non-functional requirements fulfillmentThe modules added to the system allow the translation ofnon-functional requirements to low-level ones by using anapplication model. However, the DEVA Manager and agentsneed to perform the appropriate actions in order to fulfill therequested requirements. We classify these actions in two areas:resource allocation, and resource control. These categories alsocorrespond to static and dynamic management, respectively.The first type of actions is decided and enforced by theDEVA Manager based on the initial ensemble request and themodel mapping. After parsing the user’s input, non-functionalrequirements are translated into a set of low-level QoS values,which can be in turn used by the scheduler componentto assign virtual elements to physical infrastructure. In ourimplementation in [2], the scheduler executes a metaheuristicalgorithm to iteratively choose a near optimal placement ofthe requested DEVA in the available resources. This mappingwould ensure that non-functional requirements are met by employing the appropriate infrastructure. Additionally, the DEVAManager sends a description of the requested network linksto each agent. Agents perform traffic isolation and shapingoperations on the physical links to multiplex their usage amongensemble members, and when needed, create tunnels betweenphysical hosts in different domains to build a virtual overlaynetwork.However, static allocation is not enough to respond to theruntime behavior of the application. While some values canbe applied during the instantiation phase, most of the nonfunctional requirements need to be considered in terms of theapplication’s dynamic usage. The DEVA agent is in chargeof monitoring the system’s running state and execute theappropriate control mechanisms. In many cases, these actionshave associated trade-offs which need to be considered. Examples of control mechanisms run by the agents are dynamicbandwidth or CPU adjustment, provisioning of additional VMinstances or VM migration.V. E XPERIMENTAL VALIDATIONIn order to validate the proposed architecture, we have implemented a prototype extending the original DEVA Managerand agent. There are two main goals for this section:1) Demonstrate the feasibility of translating high-level,non-functional requirements into a deployed ensembleof VMs.2) Show how high-level QoS requirements are met
non-functional requirements can be directly mapped to the execution platform, not only during the deployment phase, but also along the whole design process. Our proposed approach in this paper extends DEVA an-notations with new high-level values that correspond to non-functional requirements. An underlying application-dependent
concept mapping has been developed to address these limitations of mind mapping. 3.2 Concept Mapping Concept mapping is often confused with mind mapping (Ahlberg, 1993, 2004; Slotte & Lonka, 1999). However, unlike mind mapping, concept mapping is more structured, and less pictorial in nature.
What are Non-functional Requirements? Functional vs. Non-Functional – Functional requirements describe what the system should do functions that can be captured in use cases behaviours that can be analyzed by drawing sequence diagrams, statecharts, etc. and probably trace to individual chunks of a program – Non-functional .
Argument mapping is different from mind mapping and concept mapping (Figure 1). As Davies described, while mind mapping is based on the associative connections among images and topics and concept mapping is concerned about the interrelationships among concepts, argument mapping “ is interested in the inferential basis for a claim
Mapping is one of the basic elements in Informatica code. A mapping with out business rules are know as Flat mappings. To understand the basics of Mapping in Informatica, let us create a Mapping that inserts data from source into the target. Create Mapping in Informatica. To create Mapping in Informatica, open Informatica PowerCenter Designer .
Mind mapping Mind mapping (or ‘‘idea’’ mapping) has been defined as ‘visual, non-linear representations of ideas and their relationships’ (Biktimirov and Nilson 2006). Mind maps comprise a network of connected and related concepts. However, in mind mapping, any idea can be connected to
Mapping Analyst for Excel includes mapping specifications and metamaps. Mapping Specifications A mapping specification is a Microsoft Excel file that includes metadata to import into the PowerCenter repository. Use a mapping specification to define sources or targets or to define a mapping by describing the
i. Definition of Utility Mapping. ii. History of Utility Mapping. iii. Objectives of Utility Survey & Mapping in Malaysia. iv. The scope of Utility Mapping in standard guidelines for underground utility mapping. v. The role of utility owner, surveyor and JUPEM in underground utility mapping. 1 UNDERSTAND THE UTILITY QUALITY LEVEL ATTRIBUTES i.
Automated Quality Assurance of Non-Functional Requirements for Testability Abderahman Rashwan A Software Requirements Specification (SRS) document contains all the require-ments to describe a software system to be developed. These requirements are typically separated into Functional Requirements (FRs), which describe the fea- tures of the system under development and Non-Functional .
