Extending open up for autonomic computing english_finalversionupload 6


Published on

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Extending open up for autonomic computing english_finalversionupload 6

  1. 1. Extending OpenUp for Elicitation of Non-Functional Autonomous Software Requirement Viviane Priscila S. Santos, Anselmo Leonardo O. Nhane, Humberto Torres Marques-Neto Department of Computer Science Pontifical Catholic University of Minas Gerais (PUC MINAS) Belo Horizonte – Brazil – 30.535-901 vpssantos@sga.pucminas.br, anselmo.nhane@sga.pucminas.br, humberto@pucminas.brAbstract— In the last decade several contributions to the would compromise the software quality [3, 6, 7]. Takingdevelopment of autonomic computing were presented in the this into consideration, this paper proposes an extension ofliterature. However, it is clear that there is still a need for the OpenUP process for developing autonomous softwaresfurther research to consolidate this computing paradigm. This focusing on the elicitation of NFRs. This extension waspaper proposes the extension of the OpenUP software process done including new artifacts for independent elicitation ofto promote the development of applications emphasizing theanalysis of non-functional requirements (NFRs) related to the NFRs in this process, because, usually, NFRs areautonomic capabilities: self-configuration, self-optimization, described together functional requirement.self-healing, and self-protection. Basically, the changes were We present a case study of Brazilian Emergencymade in the software requirements discipline of OpenUP, more System for illustrating the usage of proposed extensionspecifically for proposing two new artifacts: NFR Description done. The results show that the new artifacts can helpand Misuse Case. These changes were important to discover software engineers in the task of the elicitation of NFRs.other NFRs. In order to illustrate the proposed extension, we This paper is organized in five sections. Section 2present a case study of the Brazilian Emergency System. presents the Related Work and describes aspects and Keywords-component: Open UP; Autonomic computing; concepts used in this work. In Section 3, we show ourAutonomous system; Non-functional Requirements; Software proposal of extending OpenUP for autonomic computing.Process; Section 4 presents an illustrative case study and, finally, in Section 5 we offer the conclusions. I. INTRODUCTION II. RELATED WORK In recent decades, the development of computingpower and the growth of the number of devices used for A. Autonomic Computingprocessing information have grown exponentially [24]. The concept of Autonomic Computing (AC) wasThe computing has a very important role in the introduced by Paul Horn [5]. This concept is inspired byinformation society. It is noticed that computing the Human Nervous System in order to find new ways oftechnologies are developed and incorporated quickly to implementing software able to answer some challengesexisting computer systems, which increase the complexity posed by the increasing complexity of current IT systems.[5]. Such complexity hampers the human intervention The AC refers to a system that incorporates mechanismsrequired for software maintenances. It is expected that the for self-management based on the following qualitativeautonomic computing (AC) can be used to tackle part of characteristics: self-configuration, self-optimization, self-these needs, because the autonomic systems may be able healing and self-protection [10, 12, 13].to evaluate themselves and take appropriate action, thus The MAPE-K (monitor, analyze, plan, execute,avoiding the need for human intervention for its operation. knowledge) is a reference model for autonomic control In 2000s, software processes were focused on the loop, generally used to provide architectural aspects foragility and integration [14], emphasizing collaborative autonomic systems [11]. The control loop defines themethods, infrastructure environment, values-based elements that help to be in accordance with autonomicmethods, architectures and business systems built by users. characteristics which are linked to the NFR. Approach forDifferent software processes, like RUP, XP, OpenUP, designing the software require multi-disciplinary groupamong others, were used for software developing and its [16, 18] of systems engineering, once the software processmaintenance. However, these processes do not give the should consider all the autonomic characteristics, whichattention needed for the non-functional software affect the software design. In this context, MAPE-K playsrequirements (NFRs) because, normally, they focus on the a crucial role for satisfying the self-management qualities.handling of functional requirements which can be easilynoticed and tested by final user [4]. Nevertheless, the B. Software ProcessNFRs are very important for some kinds of software and The first generic processes, such as Waterfall model, Vthe lack of their elicitation may cause problems which models, among others, did not always work for all 1
  2. 2. domains. On the other hand, it motivates the proposal forthe customization of generic software processes to workwell in a specific domain. For instance, the softwareprocess for embedded systems should focus on thedetermination of various challenges of integration betweensoftware and hardware [23]. Moreover, in the ubiquitouscomputing (any computing device can build dynamicallycomputational models of the environment in which it isinserted and configure their services depending on theneeds) the software process should focus on, e.g. thelimitations imposed by the characteristics of the devices inthe environment [27]. According to Dhaminda [22] SOTA (“Stat Of Affair”)is a general model for modeling the adaptationrequirement. This model enables a uniform andcomprehensive way of modeling functional and non-functional software requirements. SOTA initially allowsthe verification of requirements, identification of theknowledge needed for self-adaptive and identifying Figure 1. NFR in the Autonomic Systems Qualitiespatterns of self-adaptive more appropriate [22]. SOTA isan integration of context modeling multidimensional and it The OpenUP is a software process with a minimaltries to identify the general needs for the systems and content for developing software of high quality. Thus, itdynamic components for self-adaptive focusing on the does not provide guidance on various topics that cansystem architecture. The same happen on the SASSY handle projects, such as contractual situations, safety or(Self-Architecting Software System) proposal, a model- mission critical applications, technology specific guidance,driven framework target at dynamics settings in which a etc. [26]. Thus, to meet the requirements that are notsystem´s requirement might change [25]. covered in your content, the OpenUP is extensible to be Other research [8] has an architecture for self-adaptive, used as a basis on which process content can be added orand it proposes a framework of quality metrics – as a modified.methodology for software engineering based on IEEE Std Moreover, the OpenUP is iterative and agile process.1061-1998, which makes explicit the qualities of The process consists of a few disciplines, including roles,autonomic computing. The paper [15] proposes a Multi- artifacts and tasks, which are divided in Requirements,Agent Systems approach and highlights the importance of Architecture, Development, Test, Project Management,NFR for autonomic computing. and Configuration & Change management [9, 26]. As the AC properties are directly connected to NFRs, This work was extended only the discipline of theas shown in Figure 1, the inadequate processing along the requirements. This extension is reported in subsection B.generic software processes can be a problem. These There were no direct changes in other disciplines, butgeneric software processes, like RUP, are focused on taking into account the iterative phases of OpenUP, wecontinuous iterations with stakeholders to achieve the presented in subsection C that the impacts can be avoided.functional requirements during the software process. The A. Adapting OpenUp for ACsame finding was observed in the software processes forembedded systems, which leads us to conclude that non- Our proposal is to insert two new artifacts in thefunctional requirements have always been on the margins requirements discipline of the OpenUP. The first one is theof software processes. However, aspects conducive to NFR Description, which contains a list of NFRs with theirachieving the AC requirements are strongly conditioned to detailing, identifying ambiguities, disability/inconsistency of these requirements and conflicts. NFRs defined bythe NFR that requires special attention in the treatment of different actors can run between them, with the solution, asthe software process, and in the modeling of autonomic can be seen in Figure 2. The main goal of this new artifactsystems, as documented in Figure 1. Current studies are is to make feasible a greater focus on NFRs elicitation.focused on proposed models for AC architecture based on To identify ambiguities among the requirements, boththe standard cycle control MAPE-K as well as those NFR and FR must declare them consistently andproposals affect the design and analysis of systems. objectively, avoiding double interpretation. The III. EXTENDING OPENUP FOR THE ELICITATION OF inconsistency is reflected in the development and typicallyNON-FUNCTIONAL AUTONOMIC SOFTWARE REQUIREMENT results in a system where user satisfaction is a question [2]. Ambiguity or inconsistency of NFRs can result in system As mentioned before, this paper proposes some crashes such as the famous example of the Londonextensions to the OpenUP process in order to tailor it to Ambulance System [1].the development autonomous systems. These extensionswere done in the activities of the requirement discipline. 2
  3. 3. For some NFRs are only identified among the functional requirements, i.e. are hidden among the FRs beyond those specified by the stakeholders. Thus, for this purpose it is proposed to use the Misuse Case artifact. The Figure 3 modifies the basic OpenUP [28], demonstrates the tasks of the requirements elicitation in extended OpenUP which included the two new artifacts here indicated by circles: Misuse Case and NFR Description. This provides inputs and outputs of Requirements elicitation in order to identify and refine requirements. In Input 1 has the artifacts Glossary and Vision. These are the tasks of the system specifications in the view of stakeholder and analyst. This input produces other artifacts, output 1, will be explained only those are proposed in this paper. The output 1 produces besides the Figure 2. Description NFR Structure ancient artifacts of OpenUP. NFR Description and Misuse Cases are new artifacts where all the specifications The NFRs obtained through different actors of the described above are followed. This is the first iteration.system may have conflicts with each other. It is necessary The second input, the level of NFRs seeks to use thethat all the functional and non-functional requirements are Misuse Cases for modifying the NFR Description. Theysatisfied. It is very difficult to tell when NFR are satisfied. are inserted into the new NFRs discovered through faultsHence, the term partial NFR satisfaction is used when in the FRs of the system in the NFR Description.there is a solution considered good, even if this is not ideal Therefore, all NFRs are defined. Procedures are applied to[17]. Therefore the conflict must be explained including all find out if there are ambiguities and conflicts betweenits dependencies. The decisions to resolve the conflict them after that obtains the final NFR.must be based on the classification of priorities [19],which seeks to apply the NFR. B. Impacts of Changes in OpenUP The indentify and Refine Requirements are present in three phases of Patterns of Inception phase Elaboration Iteration Phase Construction Phase Iteration what the requirements are presents and Transition Phase Iteration. Thus the changes proposed here can impact and add new goals to these iterative phases. In the initiation phase iteration of the objectives of this stage, affects the pattern model iteration (the identification and refinement requirements) in order to determine a relative solution autonomic possible. Assess the key features based on the autonomic system. realizes all limitations associated with non-functional and functional requirements, which will impact the product by minimizing maintenance and future corrections due to this requirement. The iteration of the elaboration phase - this phase, the process OpenUP impact on goals in two fundamental aspects: Definition of the architecture (must allow modification with changes of context, which will require an additional study of restrictions and changes that may occur) and in the detailing of non-functional requirements according to our proposal, will highlight new non- functional requirements. Another relevant aspect is in accordance with the need for the project, identifying Figure 3. Steps Requirements elicitation OpenUP, modified for professionals of different areas that are covered by the elicitation of NFRs characteristics of the system under study. Iteration of the construction phase - this phase the The Misuse Case was also added to the OpenUp OpenUP also recommends the Refinement of thesoftware process. This is based on scenarios of negative requirements that will impact the development, includingcircumstances used in situations where error occurs in the how to identify the policies that define the behavior of thesystem. Misuse Cases can improve the elicitation process autonomic system.they may lead to yet unidentified NFRs that are hidden [2]. 3
  4. 4. In general, the process extension increases the attention shows the sequence of events where a most events cangiven to non-functional requirements, instead of relying occur simultaneously (eg as in box 6 and 10).only on use cases. The process focuses on the qualities andNFR based on metrics for autonomic computing. OpenUP B. Appling Extended OpenUp in SBEprovides guidance on the specification of autonomic For requirements elicitation this system was applied tosoftware quality(self-configuration, self-healing, self- the artifacts here proposed as an extension of the OpenUP,optimization, etc..) That best suits the project under study. so defined correctly the NFRs.Firstly, we got the system description and produce traditional artifacts of OpenUP asC. Non-Functional Requirements and MAPE-K a list of requirements and UML diagrams, which were It is very important to define correctly the NFRs of the specified FRs and NFRs normally. After this was doneautonomic system, as well as conflicts, if any, between where the NFR Description was identified first order twothem. It can directly influence the political system NFRs ambiguous, ie, those that could be bad roles playedmanagement. How goals are often expressed using by others, such as Architects, Developers and Testers.political event-condition-action (ECA) the policies of goal, After it was built the Misuse Case.or political utility function [21]. As the policies define how The next step is the built of the Misuse Case, where itand when MAPE-K should act in relation to managed was possible to discover other NFRs hidden amid the FRs.Element, Plan and Knowledge, influence that the actions These NFRs could not be identified in most processestaken by the autonomic system. Furthermore, through the commonly used for modeling focused FRs [2] and thus,NFRs is possible to define what properties (self-Healing, the analyst cannot perceive them. Generally, all NFRs areself-protection, self-configuration and self-optimization) not specified by stakeholders. It requires observation of theare added to the AC system, as can be seen in Figure 1. analyst, which does not always happen due to the short An example would be an autonomic system that time frame for completion of the system. This can result indetects two sub-problems at the same time as one of software (system) that does not solve completely theconfiguration, and other Healing, priorities of NFRs problem of users [28], leading to the need for correctionsdetermine which decision is the highest priority and should when the process is already at an advanced stage or systembe executed first, if it is not possible to place them at the in use. This is very bad because NFRs corrections aresame time. much more expensive and difficult to do [2]. Another factor is that this information is possible to Some NFRs found integrations with external systemsselect which application analyst MAPE-K is appropriate to are already in use. This is shown in Figure 5, where thethe system. Example a system that has as NFRs system should decrease the time of the traffic lights on thePerformance and Maintainability can be implemented route traced, but it must be integrated into the controlusing the tool ABLE, this has performance monitoring, system. Moreover, there is also integration with traffichealth monitoring, prediction level and length of service system that was forgotten in the first instance, whose needfor contract management [20]. was perceived when simulations of traffic problems in using functional part Misuse Case, where it is necessary to IV. CASE STUDY divert the route in case of traffic blockage. As well asA. Brazilian Emergency System changes in the climate where drastic changes in climate should also divert the route of MSU, so it is necessary As a Case Study to illustrate this changes proposed integration with the weather system. These integrations inhere, we applied the two new artifacts in set of the both the systems, traffic and weather, was also required inrequirements of the Brazilian Emergency System (SBE). the case of Figure 6, where the system checks the necessity This system aims to integrate the attendance of SAMU of sending helicopter, if such is available. Also noted is(Emergency Phone Number: 192), the emergency care unit other NFR a need for integration in real time.in Brazil, and Fire Department (Emergency Phone In the second iteration, the NFR Description has beenNumber: 193), in order to solve problems caused by the redone and all NFRs uncovered from Misuse Case weredisjunction of these systems of care. These two units are added. In this new list were sought ambiguities anddisjoint emergency entities and sometimes we can observe conflicts. The only conflict was found that the externalproblems of communication among them. In an emergency system for diversion of priority, i.e. the climate and traffic.situation, SAMU ambulance and firefighter’s vehicle are In this case the climate was chosen as a priority, as in thecalled unnecessarily, causing disputes between service case of certain roads may flood rains. Moreover, thereunits and allocation of professional and unnecessary were some NFRs that could be misinterpreted and itsvehicles that could meet other cases. description was improved so that it is more objective. This paper proposed an autonomous system that isselected for the best care unit for each type of call. Itsoperation can be seen in Figure 4, where the numbering 4
  5. 5. Figure 4. Operation of Emergency System Figure 5. Misuse case part applied to the SBE Figure 6 - Misuse case part applied to the SBEC. Impact properties AC  As Self-configuration: The emergency system in Brazil (SBE) have to change settings and route These changes were important because aside from traffic lights, according to the external conditionsdiscovering other NFRs that they could be disregarded by to be monitored by this, among other;not receiving adequate attention on the beginning of the  Self-optimization: SBE should increase or reduceproject [2], these requirements were also attached the its performance according to the system need;properties of the autonomic system. This can be seen inFigure 1, largely Self-Healing and Self-configuration due  Self-healing: SBE must be able to function evento the nature of the system. This connection between the with faults such as networks and repairs them.AC and properties NFRs are exemplified below: This is because the system must always be available to users; and 5
  6. 6.  Self-protection: The system must recognize and [10] J. A. McCann and M. C. Huebscher. “Evaluation Issues in replace, malicious services by other suitable Autonomic Computing”, Grid and Cooperative Computing - GCC 2004 Workshops, Springer Berlin / Heidelberg, vol. through the result of the discovery. 3252, 2004, pp. 597-608. Thus, it is clear that when the NFRs receive due [11] M. C. Huebscher and J. A. McCann. “A survey ofattention positively impact the outcome ddo process, may autonomic computing—degrees, models, and applications”,reduce costs and delays [2]. For this reason, the extension ACM Comput. Surv., vol. 40, Aug. 2008, pp. 7:1--7:28,here proposed NFRs attempts to identify the beginning of doi: 10.1145/1380584.1380585.the process software, as proposed in [3] and [4]. [12] L. D. Paulson. “Computer System, Heal Thyself”, Computer, vol. 35, Aug. 2002, pp. 20--22, doi: V. CONCLUSION 10.1109/MC.2002.1023783. [13] A. J. Ramirez, D. B. Knoester, B. H. Cheng and P. K. There are clearly problems in the elicitation of NFRs in Mckinley. “Plato: a genetic algorithm approach to run-timeconventional software processes, which may generate reconFiguretion in autonomic computing systems,” Clustersystem failures. This includes standalone systems, as Computing, vol. 14, Sep. 2011, pp.229-244, doi:realized during this work, the AC is intertwined with 10.1007/s10586-010-0122-y.NFRs. Bearing this in account the work done here [14] B. Boehm et al; A View of 20th and 21st Century Software Engineering; University of Southern California, Universityprovides a new way of NFR elicitation supported by Park Campus, Los Angeles, 2006.Misuse Cases. This proposal appears to be adequate, since [15] H. Kuang and O. Ormandjieva, "Self-Monitoring of Non-it focuses on the NFRs since the beginning of the software Functional Requirements in Reactive Autonomic Systemsprocess. Thus, we conclude that the extension made in Framework: A Multi-Agent Systems Approach"; IEEE,OpenUP can get good results, facilitating the identification Concordia University, Montreal, Canada, 2008.and refinement of NFRs using the NFR Misuse Case [16] E. Shahriar at al, "Software Process Engineering: Strengths,Description and which are present in the process since the Weaknesses, Opportunities and Threats", Malasia, 2010.beginning of the process. It is still desired changes in the [17] L. M. Cysneiros, "Evaluating the Effectiveness oftest area and adding documentation to choose the best Using Catalogues to Elicit Non-Functional Requirements," Proceedings of 10th Workshop in Requirementsapplication through the specified NFRs for autonomous Engineering, 2007.system development. Furthermore, we intend to review the [18] J, Cleland-Huang; "Goal-Centric Traceability forimpact on all other process disciplines, for these managing Non-Functional Requirements", ICSE, USA,modifications. 2005. [19] D. K. Barham Paech, "Non-Functional Requirements REFERENCES Engineering - Quality is Essential," 10th Anniversary[1] A D. J. Finkelstein, "A comedy of Errors: The London International Workshop on Requirements Engineering: Ambulance Service Case Study," IEEE Computer Society Foundation for Software Quality(REFSQ04), 2004. Press pp 2-5 1996. [20] Bigus, J. P.; Schlosnagle, D. A.; Pilgrim, J. R.; Mills III,[2] Ullah, S.; Iqbal, M.; Khan, A.M.; , "A survey on issues in W. N.; Diao, Y.; , "ABLE: A toolkit for building non-functional requirements elicitation,", 2011, pp.333-340 multiagent autonomic systems," IBM Systems Journal , doi: 10.1109/ICCNIT.2011.6020890. vol.41, no.3, pp.350-371, 2002 doi: 10.1147/sj.413.0350.[3] L. M. Cysneiros., J. C. S. P, Leite. "Non-functional [21] J.O. Kephart, and W. E. Walsh. "An artificial intelligence requirements: from elicitation to modelling languages," perspective on autonomic computing policies." In Software Engineering,. ICSE 2002. Proceedings of the 24rd Proceedings of the 5th IEEE International Workshop on International Conference, pp.699-700, 2002. Policies for Distributed Systems and Networks. 3–12 2004.[4] B. A N. Lawrence Chung. Eric Yo, and John Mylopoulos, [22] B. Dhaminda, Abeywickrama et ali, SOTA: toward "Non Functional Requirements in Software General Model for Self-Adaptative Systems; IEEE 21st Engineering," Boston: Kluwer Academic Publishers, International Wetice, 2012. 2000. [23] D. E. Damkeres; “Aplicação da abordagem GQM para a[5] Horn P., 2001. "Autonomic computing: IBM’s perspective definição de um processo de engenharia de requisitos de on the state of information technology". URL: software embarcado”, Masterdegree, Universidade Católica http://researchweb.watson.ibm.com/autonomic. de Brasilia; Brazil; 2008.[6] M. S.Emami , N. Binti Ithnin and O. Ibrahim, “Software [24] Would Statistics, http://www.factfish.com/statistic/. Accessed Process Engineering: Strengths, Weaknesses, Date: 07.11.12; Opportunities and Threats”. Networked Computing (INC), [25] D. Menascé et ali; SASSY(Self-architecting software 6th International Conference on, IEEE, 2010. system), IEEE Software, 2011[7] L. M. Cysneiros and J. C. S. P. Leite. “Using UML to [26] Introduction to OpenUP (Open unified Process. Project. reflect non-functional requirements”. In Proceedings of the URL: http://www.eclipse.org/epf/general/OpenUP.pdf. 2001 conference of the Centre for Advanced Studies on [27] C. Cirilo; "Computação Ubíqua: definição, princípios e Collaborative research (CASCON 01), 2001. tecnologias"; Cientifc article, Universidade Federal de São[8] P. Lin, A. Mac, J. Leaney, “Defining Autonomic Carlos, Brasil. Computing: A Software Engineering Perspective,” [28] A. Matouss and R. Laleau , "A Survey of Non-Functional Proceedings of the 2005 Australian Software Engineering Requirements in Software Development Process" TR- Conference (ASWEC’05), Mar. 2005; Australia. LACL-2008-7. 2008.[9] Eletronic Document: OpenUp: Unified Project. URL: [29] OpenUp/Basic "Maneged Requeriments". 2012. URL: http://epf.eclipse.org/wikis/openup/ <http://epf.eclipse.org/wikis/openuppt/index.htm> 6