A software product line approach to enhance a meta-scheduler ...

Home

Search

Collections

Journals

About

Contact us

My IOPscience

A software product line approach to enhance a meta-scheduler middleware

This article has been downloaded from IOPscience. Please scroll down to see the full text article. 2012 J. Phys.: Conf. Ser. 341 012030 (http://iopscience.iop.org/1742-6596/341/1/012030) View the table of contents for this issue, or go to the journal homepage for more

Download details: IP Address: 150.162.59.37 The article was downloaded on 09/02/2012 at 18:19

Please note that terms and conditions apply.

High Performance Computing Symposium 2011 Journal of Physics: Conference Series 341 (2012) 012030

IOP Publishing doi:10.1088/1742-6596/341/1/012030

A software product line approach to enhance a meta-scheduler middleware Rafael F Scheidt, Katreen Schmidt, Gabriel M Pessoa, Matheus A Viera and Mario Dantas University of Santa Catarina (UFSC), Department of Informatics and Statistic (INE), 88040-900, Florianopolis - SC, Brazil E-mail: {rfscheidt, katreenschmidt, gabrielm, matviera, mario}@inf.ufsc.br Abstract. Software Projects in general tend to get more software reuse and componentization in order to reduce time, cost and new products resources. The need for techniques and tools to organize projects of higher quality in less time is one of the greatest challenges of Software Engineering. The Software Product Line is proposed to organize and systematically assist the development of new products in series at the same domain. In this context, this paper is proposed to apply the Software Product Line approach in Distributed Computing Environments. In projects that involve Distributed Environments, each version of the same product can generate repeatedly the same artifacts in a product that evolves its characteristics; however there is a principal architecture with variations of components. The goal of the proposed approach is to analyze the actual process and propose a new approach to develop new projects reusing the whole architecture, components and documents, starting with a solid base and creating new products focusing in new functionalities. We expect that with the application of this approach give support to the development of projects in Distributed Computing Environment.

1. Introduction A Software Product Line represents a set of systems sharing common functionalities and characteristics that satisfies the needs of a particular market or specific segment [1]. Such a system set also can be named as Product Family [2]. The members of the product family are specific products systematically developed by the Software Product Line also classified as core assets. The core assets are represented by a variable features set which indicate a late decision of design of project [1]. The assets choice and configuration composes a specific product [3]. The Computational Grid approach in general presents a complex and distributed structure involving hardware and software that allows access with low costs to the high performance computing resources [4]. In the context of this approach, could find several elements like graphic interfaces to access the environment, middleware, meta-scheduler and so on, in consequence involve several knowledge areas that can derive other set of elements. In this sense it becomes a challenge to systematically organize through the Software Product Line, such elements and architecture, aimed at planning systematic reuse and fast customization for products development that complete other needs and have the same structure. This paper is organized as follows: Section II represents the value of concept Software Product Line. Section III describes the Distributed Computing Environments. Section IV illustrates and focuses

Published under licence by IOP Publishing Ltd

1



on the proposal and related works. Section V discusses the facts and problems found at the moment. Section VI provides comments e directions about future works. 2. Software Product Line Software Product Line respects to systematical planning and strategic reuse productivity, by exploiting similar features of a product. Its main goal is to achieve significant reduction in organizations in terms of development, cost reduction in maintenance, reduce time-to-market, improve quality productivity and customer satisfaction as well to anticipate the problems encountered [1]. The main difference between conventional Software Engineering and Software Product Line is the variation presence in some or all the software requirements and the focus. In the conventional systems the focuses is a unique goal, in other words, produce a specific product. While the conventional systems development works ad-hoc, in other words, contract oriented, the Product Line development has a strategic vision of the niche market [5]. The implementation of Software Product Line approach requires efforts on the major artifacts in the development cycle. Table 1 shows the main characteristics of the essential artifacts for Software Product Line. Table 1. Implementation costs of a Software Product Line [6]. Core Artifacts Architecture Software Components

Test Plans, Test Cases and Test Data Business Case and Market Analysis Project Plans Tools and Processes People, Skills and Training

Implementation cost Must support variation inherited of Product Line It should be design to be general, without loss of performance, must have support of variation points Should be considered variation points and multiple instances of Product Line Should approach a family of software products, not just a product It should be generic or extensible to accommodate variations of the product Should be more robust Should involve training and experience about the artifacts and procedures associated with the Product Line

There are essential activities for Software Product Line. Such activities are Domain Engineering, which aims to develop the core of artifacts and Application Engineering, which will be instantiated in the core of artifacts to generate different products also known as Product Development [1]. Core assets are a set of assets ready to be reused in new product development. The core assets can be software components, project patterns, documents used in development, architecture, schedule and other artifacts that will serve as building blocks in the Product Line. The core assets are present in every product line. The architecture is one of these core assets and carries with it the possibilities of line variability. Architecture core asset, in particular, is seen as a key point of a product line and if it is projected badly can derail the entire project [2]. The main objective of Product Development is the generation of products based on core assets of a Product Line. It corresponds to the instantiation of applications and since found new requirements that had not been specified, it starts a feedback between this activity and the activity of core assets (Domain Engineering), in cycles in an evolutionary way. A very important concept intrinsic to a Software Product Line is the variability. To form a software family through Software Product Line it is necessary identify possible changes that may occur in the 2



artifacts produced. The products generated during products development phase can be differentiated in terms of behavior, quality attributes, physical configurations, scaling factors, among others [2]. Variations are the tangible differences between the products of Product Line in any device such as architecture, components, interfaces between components and components connection. The variations can be identified in any development phase of Products Line [7]. To represent the possible variations identified in a particular domain becomes necessary an approach of variability, which until now, there is no consensus about how to identify and represent variability in Product Line because it is a recent issue [8]. One possible approach available and based on UML was developed and named SMarty (Stereotype-based Management of Variability) [8]. The SMarty approach was developed based on the activities and on the concepts of variability. A SMarty approach was created to manage the variability consisting of a UML profile called SMartyProfile and a process named SMartyProcess. The main goal of SMarty approach is to allow the variability of a Product Line to be managed effectively supporting UML models. 3. Distributed Computing Grid computing is characterized by making a variety of distributed resources, including services, devices and applications, available to a wide range of users [9]. Various organizations, both real and virtual (VO), can make different types of resources available under dynamically changing availability constraints and with varying policies for access and use of these resources [10]. As a result of their nature, this variety of services and resources can be incorporated for achieving computational tasks. Specifically, users can access resources, applications and services, submit jobs for execution either via queues or by advance reservation, create combination processes in workflows, and verify the status of jobs or systems. Also, there has been a movement towards integrating grid computing environments with mobile computing [11] [12], creating an interface for users access the resources and services of a grid from anywhere, at anytime. One the other hand, clusters environments are common configurations used in many organizations to reach high performance computing (HPC) for specific local applications. Multi-clusters, if well orchestrate as a grid environment, can represent a differential computational power for a global execution of several class of applications, including also parallel jobs. A grid environment, composed by multi-clusters configurations, can be considered in a private or in multi-domain organizations. In other words, this metacomputing [13] environment can be employed as a HPC facility inside a specific organization, or among different organizations, creating in both cases the concept of virtual organization (VO). One important challenge is how to reach an efficient re-utilization of this environment and coordinate all resources and services. 4. Proposal and Related Works With a focus on Distributed Computing Environment the present study aims to systematically organize the elements and architecture, aiming the systematic reuse planning and rapid customization for new product development to complete other requirements and to have the same structure. To achieve this objective, this work applies the SMarty process specifically in the project being developed by the laboratory LaPesD at the Federal University of Santa Catarina UFSC, contributing to the development of techniques to systematize a process for reuse of the artifacts, architecture and components of Software Products Line in Distributed Computing Environment. Among the existing approaches of Software Product Line and researches, SMarty approach was chosen due to its ability of modeling artifacts and ability of integrate with the UML. Currently in the literature are few works in the area of Distributed Environments. One of the few existing, but with excellent quality [14] [15] proposes to build an approach of Software Product Line for Grid-Oriented Middleware. The work developed a Software Product Line Architecture to facilitate

3



the development of Grid-Oriented Middleware Systems. In order to validate the proposed PLA, it is instantiated in the construction of a middleware for grid computing. Another approach is named GISPL (Grid Infrastructure Software Product Line) adopts SPL concepts in the design, optimization and implementation of Grid-Oriented Middleware. Initially, the requirements are defined through ontology and a specific language. Next, service oriented architecture is defined that incorporates software and hardware artifacts needed to the functioning of VO (Virtual Organization). The architecture is modeled in System Modeling Language (SysML), which allows specifying the infrastructure using specific models derived from the ontology defined in the previous step. Finally, the infrastructure models are prototyped and optimized [16] [15]. Unlike the presented approaches, the purpose of this study is to apply in the Distributed Computing Environment as a whole, covering all the part of domain and instantiating complete applications distributed at the stage of product development. 5. Discussion The initial motivation to use a Software Product Line approach in the distributed environment, which is often a complex architecture, was based on problems encountered, such as: architecture elements are deployed and are removed a few times, because the client does not know exactly what you want about a project. Such problem without using Software Product Line causes a massive rework. In the proposed architecture, each element presented (GUI Interface, Meta-scheduler, schedulers) can be componentized as part of a common architecture called Domain Engineering (DE), and then every new product would made an analyze to an instance of this Architecture of Application Engineering (AE) and specialization of the parties not common.

Figure 1. Domain Engineering in the Distributed Computing Environment. For example it can apply ontologies aimed to describe the existing settings in the available network resources specializing only one of the architecture components. It can also add new elements or components in the architecture, such as an upper layer to replace the GUI for a mobile application with

4



an ontology itself (where this component would be part of the Domain and later reused in other products). All these elements presented in the architecture and in any layer can be planned carefully developed thinking of reuse and variations points (mandatory, optional and alternative) aimed at creating a Software Product Line in the Distributed Computing Environment. Study the possibility of using OSGI [17] on the GUI layer and on the cellular phone. This technology increases the level of componentization lowering the granularity of each module. 6. Conclusion and Future Works This paper presented an approach to Software Product Line architecture specially designed for distributed computing environments. The principal relevance for this approach can be defined as follow. Increasingly through the Software Engineering seeks to reuse elements for reuse in project from the same domain. This practice is directly related to improvement in the cost of projects, time and productivity [6]. The Software Product Line contributes with all these features and to increase the quality of final product, productivity and so on. The adoption of Software Products Line concepts provides a way for better integration of environment components quickly and securely, and also supports an approach of mass customization. The reuse of the artifacts and final product decreases the number of errors, increases compliance of the produced software, eases maintenance and reduces development time. We are now applying the approach in the projects and documenting information about this. With the application of the approach, we are able to solve practical problems related to the user’s indecision as to what elements in its architecture the user would like to have and quickly add and remove elements without major problems. 7. References [1] Pohl K, Böckle G and van der Linden F J 2005 Software Product Line Engineering:

Foundations, Principles, and Techniques (Secaucus, NJ: Springer-Verlag) [2]

Clements P C and Northrop L M 2002 Software Product Lines: Practices and Patterns (Boston, MA: Addison-Wesley) [3] Junior E A O, Gimenes I M S and Maldonado J C 2011 A meta-process to support trade-off analysis in software product line architecture Proc. Int. Conf. on Software Engineering and Knowledge Engineering (Miami) vol 1 (Skokie, IL: Knowledge Systems Institute) pp 687692 [4] Silva A P C and Dantas M A R 2007 A selector of grid resources based on the semantic integration of multiple ontologies Proc. 19th Int. Symp. on Computer Architecture and High Performance Computing (Gramado) vol 1 (Washington, DC: IEEE Computer Society) pp 143-150 [5] van der Linden F J, Schmid K and Rommes E 2007 Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering (Secaucus, NJ: Springer-Verlag) [6] Software Engineering Institute [homepage on the Internet] Pennsylvania: Carnegie Mellon University 2011 Available from: http://www.sei.cmu.edu/ [7] Gimenes I M and Travassos G H 2002 O Enfoque de Linha de Produto para Desenvolvimento de Software (Florianópolis, SC: SBC) pp 1-32 [8] Junior E A O SystEM-PLA: um método sistemático para avaliaçao de arquitetura de linha de produto de software baseada em UML PhD [dissertation] São Carlos: Universidade Federal de São Paulo 2010 Avaiable from: Biblioteca Digital de Teses e Dissertações da USP [9] Foster I 2002 What is the grid? a three point checklist GridToday 1 22-25 [10] Foster I, Kesselman C and Tuecke S 2001 The anatomy of the grid: enabling scalable virtual organizations In. J. of High Per. Comp. App. 15 200-222

5



[11] Chu D C and Humphrey M 2004 Mobile ogsi. net: grid computing on mobile devices Proc. 5th IEEE/ACM Int. Work. on Grid Computing (Pittsburgh) vol 1 (Washington, DC: IEEE Computer Society) pp 182-191 [12] Gomes A T A, Ziviani A, Lima L S and Endler M 2007 DICHOTOMY: a resource discovery and scheduling protocol for multihop ad hoc mobile grids Proc. of the 7th IEEE Int. Symp. on Cluster Computing and the Grid (Rio de Janeiro) vol 1 (Washington, DC: IEEE Computer Society) pp 719-724 [13] Czajkowski K, Foster I, Karonis N, Kesselman C, Martin S, Smith W and Tuecke S 1998 A resource management architecture for metacomputing systems Proc. of the 4th Work. on Job Scheduling Strategies for Parallel Processing (Orlando) vol 1 (Secaucus, NJ: SpringerVerlag) pp 62-82 [14] Oliveira D and Rosa N 2009 Ubá: a software product line architecture for grid-oriented middleware Proc. of the 2009 33rd Annual IEEE Int. Computer Software and Applications Conf. (Seattle) vol 2 (Washington, DC: IEEE Computer Society) pp 160-165 [15] de Oliveira D J S and Rosa N S 2010 Evaluating product line architecture for grid computing middleware systems: ubá experience Proc. of the 2010 IEEE 24th Int. Conf. on Advanced Information Networking and Applications Work. (Perth) vol 1 (Washington, DC: IEEE Computer Society) pp 257-262 [16] Goasguen S and McGregor J D 2007 Poster: grid infrastructure software product line Proc. of the 8th IEEE/ACM Int. Conf. on Grid Computing (Austin) vol 1 (Washington, DC: IEEE Computer Society) [17] Open Grid Services Infrastructure [homepage on the Internet] California: OSGi Alliance 2011 Available from: http://www.osgi.org/

6