acseac 24-25 september 2012

ACSEAC 24-25 SEPTEMBER 2012

African Conference on Software Engineering and Applied Computing(ACSEAC) 24th – 25th September 2012 Gaborone Botswana ISBN: 978-1-4673-1776-4

th African Conference on Software Engineering and Applied Computing(ACSEAC) 24

th – 25 September 2012


Software Engineering and Applied Computing Edited by: Rym Zailla Wenkestern University of Texas at Austine

Julius Stuller Academy of Sciences of the Czech Republic




Typesetting Joseph Kibombo Balikuddembe

All rights reserved. No part of these proceedings may be reproduced, stored in a retrieval system, or transmitted in any for or by any means without the prior permission in writing to the publisher.




Conference Organisation General Chair

Gerald Kotonya, UK Jamel. H. Abawajy, Australia Joseph Kibombo Balikuddembe, Uganda Cornelius Ncube, UK

Local Chair

Yirsaw Ayalew, Botswana

Local Organising Committee Aubrey P. Mokotedi Gontlafetse Mosweunyane, Audrey Masizana-Katongo Keneilwe Zuva Kefilwe Mooketsi

General Chair: Finance Antoine Bagula, South Africa

Program Co-chair Julius Stuller, Czech Republic Rym Wenkstern, USA Sonia Berman, South Africa

Publicity Co-chairs Raymond Mugwanya, South Africa Muthoni Masinde, Kenya

Publication Co-chair Mark Last, Israel

Tutorial Co-chairs Cornelius Ncube, UK J. H. Abawajy, Australia

Doctoral Symposium Co-chairs Paul Mzee Okanda, UK Kyadonghere Kyamakya, Austria Daniel M. Berry, Canada Chris Price, UK

Posters and Demo Chair John Mathenge Kanyaru, UK Kendra M.L. Cooper, USA

International Advisory Board

Jeffrey Kramer, UK Hakan Erdogmus, Canada Marco Zennaro, Italy Jean Chamberlain Chedjou, Austria. Chris Price, UK Kendra M.L. Cooper, USA

Steering Committee Joseph Kibombo Balikuddembe, Uganda Rym Wenkstern, USA Cornelius Ncube, UK Antoine Bagula, South Africa th African Conference on Software Engineering and Applied Computing(ACSEAC) 24



J. H. Abawajy, Australia Sonia Berman, South Africa

Program Committee

Jeffrey Kramer, Imperial College London, UK Rym Wenkstern, University of Texas at Dallas, USA Jonathan Lee, National Central University, Taiwan Andy Adamatzky, University of West of England, UK Danilo Caivano, University of Bari, ITALY Kendra M.L. Cooper, The University of Texas at Dallas, USA Joao Cangussu, University of Texas at Dallas, USA Dan Almog, Ben Gurion University of the Negev, Israel Abdellatif Tchantchane , University of Wollongong in Dubai, Dubai Muthoni Masinde ,University of Nairobi Kenya, Kenya Keith C.C. Chan, The Hong Kong Polytechnic University, Hong Kong Frank Maurer, University of Calgary, Canada Alan Wassyng, McMaster University, Canada Cornelius Ncube, Bournemouth University, UK Marcelo Cataldo, Carnegie Mellon University, USA Daniel M. Berry, University of Waterloo, Canada Laurence T. Yang , St. Francis Xavier University, Canada Baldassarre Maria Teresa, University of Bari, ITALY Douglas C. Schmidt, Vanderbilt University, USA Prabhat K. Mahanti, University of New Brunswick , Canada Isaac O. Osunmakinde, UNISA, South Africa Venkatesh-Prasad Ranganath, Microsoft, India Soraya Zertal, Université de Versailles Saint-Quentin-en-Yvelines, France Leonardo Garrido, Tecnológico de Monterrey, Mexico Rahel Bakele , University of Addis Ababa, Ethiopia Julius Stuller, Academy of Sciences of the Czech Republic, Czech Republic Matjaz Gams, Jozef Stefan Institute, Slovenia Wei Zhong , University of South Carolina Upstate, USA Mark Last, Ben-Gurion University of the Negev, Israel Ali Idri, ENSIAS, Mohamed V Souissi University, Morocco Dewayne Perry, University of Texas at Austin, USA Jude Lubega, Makerere University, Uganda Sebastian A. Rodriguez, Universidad Tecnológica Nacional, Argentina Kyadonghere Kyamakya, University of Klagenfurt, Austria Lorenzo Catelli, University of Trieste, Italy Eloisa Vargiu, University of Cagliari, Italy Ken MacGregor, University of Cape Town, South Africa Dumitru Dan Burdescu, University of Craiova, Romania Mohamed MOSBAH, Université Bordeaux, France Ella Hassanien, Cairo University, Egypt Sylvain Giroux, Université de Sherbrooke, Canada Vincenzo Pallotta, University of Fribourg, Switzerland Vincent Hilaire, UTBM, France Gerald Kotonya, Lancaster University, UK John Mathenge Kanyaru, Bournemouth University, UK Galal H Galal-Edeen, Cairo University, Egypt Paul Mzee Okanda, Lancaster University, UK Maweru Mwangi, JKUAT, Kenya Joy Garfield, Birmingham University, UK Alberto Sampaio, Portugal Ekow Otoo, South Africa Russel David, USA Tran Khanh Dang, Vietnam




Scientific Sponsors •

Department of Computer Science, University of Botswana

•

Department of Computer Science, University of Nairobi

•

Tensid

•

Springer

•

Google

•

IEEE, Computer Society

•

IEEE, Technical Committee on Scalable Computing (TCSC)

•

Best Paper Award by IEEE Software




Table of Contents Preface

8

Message From the Program Co-Chairs

11

Message From the General and Local Chairs

12

Software Engineering and Applied Computing

13

Experiences in creating Inclusive Information and Communications Technologies (IICT)

14

Multi-Perspective Ontology to Understand Organizational Requirements

21

Virtual Laboratory Development for Teaching Power

28

Systems via Interactive Experiment Environment

29

Measuring User Requirements Dependency: the Organizational Perspective

37

Model-driven Refactoring Approaches: A Comparison Criteria

43

Logic Verification of Product-Line Variant Requirements

48

A Principled Approach to the Management of Overlay Networks using Reflection

52

Indoor navigation using a mobile phone

60

Security-oriented Design for Web-based Systems: A Critical Review

66

Improving maintainability of COTS based system using Aspect Oriented Programming: An empirical evaluation

78

Topological Structure of Knowledge

85

Using a genetic algorithm for mining patterns from Endgame Databases

90

Software Engineering Ethical Decision Making and Professional Responsibility

97

TEACHING AND ASSESSING SOFTWARE ENGINEERING ETHICS IN THE 21

ST

CENTURY:

CASE STUDY FROM AMERICAN UNIVERSITY OF NIGERIA

105

Computing Education: A Discussion Paper on Teaching and Assessing Ethics

112




Preface The field of Software Engineering provides the appropriate engineering principles in building enabling technologies. On the other hand, the discipline of Applied Computing emphasizes the practicality of such technologies in meeting the desired need. The African Conference on Software Engineering and Applied Computing, ACSEAC2012, (Gaborone, Botswana, September 24th 25th, 2012) provides the opportunity to exachange knowledge and ideas between researchers and practioners. The conference is a forum for preentations and evaluation of both, currently used mothods and techniques and new approaches or directions in Software Engineering and Applied Computing. Main topics of the Conference include all aspects of software development and applied computing: Track 1: Principles and practice of software engineering • Development practices and approaches • Software Development Tools and Infrastructure • Software Project Management • Software Process • Requirements Engineering • Software Architectures & Design • Software Security • Testing & Quality assurance • Software Economics • Software Measurement • Validation and Verification Track 2: Applied computing techniques • Artificial Intelligence • Agent-based Technologies • Decision-support Systems • Scheduling and Optimization Techniques • Database Systems • Evolving Data Structures • Genetic Programming and Fuzzy Logics • Programming Environments • Distributed Systems • Real-time Systems • Web Technologies • Mobile Technologies • Testing Verification and Validation of varying applications • ICT for the Developing World Track 3: Industrial session on software process improvement • Defining and documenting software processes • Measuring software processes • Evaluating software process capability and effectiveness • Planning and managing software process improvement projects and programs • Implementing software process change • Building the requirement management process • Mastering the software product lifecycle • Software project management and planning • Effective risk management techniques • Agile software development methods • Balanced scorecard • Software measurement and analysis • The agile software review process • Six Sigma approaches to software process improvement




Track 4: Innovations in Education Innovative instructional technologies Evaluation and assessment techniques Application development environments and frameworks Use of Open source tools in software engineering courses Integration of agile practices in software engineering courses Industry-academia collaboration models Accrediting long-distance postgraduate degrees in software engineering Integrating industrial case studies Corporate continuing education and training Professional, ethical, and legal issues in software engineering education Integrating technical writing in software engineering courses Integration of research results into software engineering courses Forming learning communities among undergraduate and graduate students E-learning This book is based on the presentations given during the conference.

SEPTEMBER 2012




Message From the Program Co-Chairs The first African Conference on Software Engineering and Applied Computing (ACSEAC‘12) aims at bringing together African and international researchers and practitioners to present and discuss high-quality research outcomes and practical solutions in Software Engineering and Applied Computing. This year‘s ACSEAC conference is located in, Gaborone, Botswana. Gaborone is a bustling modern city, located in the shadow of the Kgale and Oddi Hills in the south of Botswana. Its relatively small size belies the fact that Gaborone is seen as one of southern Africa's economic success stories. Gaborone boasts a flourishing economy and a wide range of facilities; for it is a home to several attractions which are of interest to visitors who choose to linger a while in the city. ACSEAC‘12 features a keynote presentation, six regular sessions, and a special workshop on quantitative evaluation of process improvement. Besides the plenary sessions, ACSE‘12 runs in two parallel tracks comprising two major topics: Principles and Practice of Software Engineering and Applied Computing Techniques. ACSEAC‘12 is gathering software engineering and applied computing researchers, scientists and practitioners from 20 different countries (Austria, Botswana, Cameroon, Switzeland, DRC, Soudi Arabia, Bangladesh, Canada, China, Ethiopia, India, Iran, Kenya, Madagascar, Nigeria, South Africa, Uganda, UK, USA, Zimbabwe) Each paper submitted to ACSEAC‘12 was evaluated and reviewed by two to three members of the international program committee, judging the originality, significance, technical contents, application contents and presentation style. We used an online conference system to automate the workflow for submission and refereeing. ACSEAC‘12 received a total of 31 submissions, 22 of which were accepted as full papers for an acceptance rate of 71%. 17 out of the accepted 22 papers registered for the conference and were distributed into 4 presentation sessions. We gratefully acknowledge the professional work of the international program committee and the sub-reviewers contributing tremendous amount of referee reports. We appreciate the dedication of the invited speaker Dr. Hakan Erdogomus, Kalemun Research Inc, Canada. We owe great thanks to Yirsaw Ayalew, Joseph Kibombo Balikuddembe and Anthoine Bagula for the well-organized conference. We also want to thank all presenters and attendees for actively contributing to the success of ACSEAC. We are looking forward to excellent presentations and fruitful discussions. All participants are invited to make friends within the ACSEAC family. Welcome to Gaborone. Julius Stuller Academy of Sciences Czech Republic

Rym Zalila-Wenkstern University of Texas at Dallas USA




Message From the General and Local Chairs It is our great pleasure to welcome you to the second African Conference on Software Engineering and Applied Computing, which takes place in Gaborone on 24 - 25 September 2012. ACSEAC is held annually and is the world premier technical event covering all aspects of Software Engineering and Applied Computing. This will be rotated every year across the continent as we strive to reach out to the rest of the research community and also as we strive to strengthen partnerships and collaborative initiatives. Last year we were in Cape Town, South Africa and next year we will be in Nairobi, Kenya. In total, 17 papers will be presented to around 50 attendees from over 20 countries. All of the submissions were rigorously reviewed by at least three international experts who were mostly members of the program committee. Great thanks to our sponsors who have enabled us to reach this far. Our hope is that can continue with this partnership for the other forth coming conference series. The Organizing and Program Committees have worked hard to produce a first class technical conference and a pleasing and enjoyable social event. On behalf of the Organizing and Program Committees we welcome you all to Botswana and hope that you enjoy the scenery in Botswana. We look forward to an exciting two day conference of sharing technical ideas and visions with colleagues from around the world. We thank you for attending the conference and being a part of this very important event.

Welcome to Gaborone.

Joseph Kibombo Balikuddembe

Yirsaw Ayalew

Makerere University Kampala, Uganda

University of Botswana Gaborone Botswana




Software Engineering and Applied Computing




Experiences in creating Inclusive Information and Communications Technologies (IICT) Democratizing Software Development in Social Development Chrispen Hanyane Technology and Change Management ICL Botswana Gaborone, Botswana [email protected]

Abstract— Crowdsourcing, citizen journalism and social networks are Information and Communications Technologies (ICT) that have ushered in civil society’s participation in the ICT equation. However, the participation of civil society has been limited to creating content and, to some extent, capturing data about events around the community. An area that has been neglected is the inclusion of these new players in the software development life cycle. Democratizing software development by including civil society in the software development life cycle will increase the variety of software applications and generate more buy-in of applications that improve livelihoods. Such an approach will lead to the emergence of Inclusive Information and Communication Technologies (IICT). The challenges that arise when developing IICTs include, inter alia, ownership of IICT, computer illiteracy of beneficiary communities, balkanized nature of communities in place and the well-known challenge of the communication gap between software developers and user communities. My approach to addressing these challenges was to develop the Integrated Development Spatial Planning Framework (IDSPF), a systems development methodology that seeks to demystify software development for grassroots communities by using participatory techniques that are familiar to stakeholders who implement socio economic development projects. Keywords- grassroots; digital divide; GIS; IICT

I.

INTRODUCTION

There is a surge in the number of stakeholders whose social wellbeing is being directly affected by the proliferation of ICTs. When ICTs play a significant role in changing governments, as is the case with the Arab Spring, the entire populations of those countries are directly affected by ICTs. It then stands to reason that more stakeholders would be added to the population directly affected by ICTs. Furthermore, the demographics of stakeholders directly impacted by ICT drastically changes. The following are examples of applications that drive grassroots involvement in ICT: •

Crowdsourcing

•

Social networks (the Arab Spring)

•

Multi-purpose Community Centers

•

Citizen journalism

•

Mobile money

These innovations invariably bring all levels of society, including grassroots, within the ICT application catchment window. Experiences in implementing socio economic development projects within communities in place indicate that projects become more sustainable if their identification, planning, implementation and monitoring and evaluation is undertaken with the participation of beneficiary communities. When the opportunity to develop software for application in rural communities presented itself to me, I decided that the best approach of generating buy-in and sustainability of the software would be to adopt a participatory project development approach since such approaches have yielded positive results in socio economic development projects. I decided to include grassroots in the entire software development cycle. This is when the challenges of ownership, computer illiteracy, balkanized stakeholder communities and the communication gap between software began to loom large and it became clear that these, and other challenges, would pose significant risks to the success of the project. The challenge of bridging the communication gaps between software developers has usually been approached by developing methodologies that bridge the technical aspects of software development and the business demands of requirements analysis. Such approaches have led to the development of Joint Application Development (JAD), UML and other related tools and strategies that seek to bridge the communication gap between different participating groups through simplifying the dialogue between stakeholders during requirement analysis and system testing. Stakeholders from finance, human resources, operations and marketing began to participate in software development through JAD sessions and other requirement analysis forums in an effort to reduce software risks by involving stakeholders in the software development cycle. Moderate successes [1] have been recorded by this approach. However the history of these approaches is grounded is solving communications problems that arise when developing business software in private sector environments. Applying ICT in social development invariably brings in the public sector. Whilst the corporate sector can legitimately




claim moderate successes in reducing the application backlog through expanding the number of participants by, inter alia, adopting JAD sessions, the new kid on the block, the public sector, cannot pronounce the same modest gain. Put it another way, the social development sector, which includes government agencies, development practitioners, policy makers, aid agencies and grassroots, has not made significant strides in bringing the majority of their stakeholders into the application development cycle. Consequently, the majority of decision makers in the public (e.g. policy makers, government officials, extension services officers, donor programmer officers, grassroots community leaders) do not participate in software development. I developed the Integrated Spatial Development Framework (IDSPF) as a contribution to the software development community in particular, and to socio economic development in general to offer a pathway for including these decision makers and the grassroots in the software development cycle. If I was to propose to a group of software programmers that they include computer illiterate rural folks in their next JAD session, they would think I am asking for the impossible. Current implementations of JAD sessions and other software development methodologies/tools do not explicitly address the challenges that arise when one is developing software applications for supporting socio economic development projects in rural communities. IDSPF has been developed as a methodology that addresses such challenges thus it provides a framework for the development of IICTs by incorporating tools that promote and simplify software development activities for stakeholders that are traditionally classified as computer illiterate. IDSPF‘s major contribution to software development is providing a pathway for including all levels of society in the identification, development and implementation of software that improves livelihoods of communities in place. To most practitioners who are familiar with traditional software development practices, such a statement might sound like a Big, Hairy, Audacious Goal (BHAG) [7], however IDSPF has achieved this feat. I have tested these concepts through developing the Livestock Spatial Information System (LSIS) and the Agro-Dealer Network Spatial Information System (ADNSIS) which are systems that provide information within projects that seek to address the millennium goals of reducing extreme hunger and poverty and creating global partnerships for development, MGD 1 and 8, respectively. In this paper, I outline some of the challenges and strategic responses that I have built into IDSPF so that it democratizes software development by including grassroots in the software development cycle. II.

BACKGROUND AND PROBLEM DOMAIN

Lupane State University (LSU) is the fifth and youngest state university in Zimbabwe. Its main focus is developing graduates who can go and serve rural communities by working with them on projects in agriculture and natural resources management. As such, it can be surmised that the role of LSU is to improve the livelihoods of rural poor. To that end, LSU set up the Center for Agriculture and Rural Development (CARD) with the mandate of translating academic research to viable community based projects.

One of the strategies of CARD is to build a network of stakeholders, including private sector players, to provide a range of products and services to support community outreach projects. CARD initiated a community-based project called ―Promotion of Indigenous and Exotic Poultry Production for Food Security and Marketing for Eradication of Poverty among Rural Communities‖. This project was aimed at addressing the first goal of MDG, which is to ―Eradicate extreme poverty and hunger‖. I was drafted into the project and given the role of developing and implementing a ―system for collecting data, processing the data and managing and disseminating research information within the academic, scientific and social stakeholder network of the project‖. LSU‘s guiding principle is to ensure that beneficiary communities participate in all stages of development interventions that impact on their lives. Consequently, it became a requirement that I involve rural communities in the software application that was going to support the indigenous and exotic poultry project. This provided the background for me to start investigating issues related to engaging rural communities in software development. Not much ground was covered on the indigenous and exotic poultry project, but the basic questions surround engaging rural communities in software development took root in this project and I was then able to pursue them deeper during development of LSIS. My previous software development experience had been in the private sector. When developing LSIS, my initial approach was to use software development methodologies that I had applied in the private sector. However I quickly realized that some software development challenges that arise in the public sector are different from those experienced in the private sector. Most public sector software development challenges have their roots in the diversity of stakeholder skills, expectations, perceptions and authority and power levels within communities in place. When developing software in the private sector, it is normal that the software is for a specific company. That company will already have put in place structures that create stakeholder boundaries. Where stakeholders exhibit major differences that might prove to be a risk to project progress, the software designer can choose use the power based of existing company structures to manage that risk. Such support structures do not exist within communities in place. Differences in political views and livelihoods (i.e. farmers, brick layers and shop owners) create quite divergent and strong stakeholder perceptions about the project‘s outcome. There is no obvious power structure in place that can be used to address such divergent views. Structures that exist are either temporary or are only helpful for solving particular problems. For example one can use traditional leaders to solve a conflict about the use of and access to cultural sites. However trying to use traditional leaders to resolve a conflict about which school should be given a diesel generator to power a PC that will be used to capture community data would not be effective. The best approach would be to resort to participatory approaches that demonstrate the value of choosing one school over another. However proposing project value to groups with different skills levels is a challenge in its self. The language and tools for conducting meaning dialogue that clearly communicates the critical project variables that contribute to the value being proposed is a challenge, especially when the



14


project seeks to democratize software development by involving the communities in place in the entire software development cycle. It is against this background that I began to develop the following hypotheses: Hypothesis One: Public Sector and socio economic development is heavily influenced by geographic context. Hypothesis Two: Advances in Geographic Information Systems (GIS) should benefit Public Sector and Community Development project planning, implementation and monitoring and evaluation.

Sponsors (i.e. Government Departments, Parliamentarians, Policy Makers, Donors and NGOs), Communities in Place and Technical Services Providers (i.e. Extension Services officers, Consultants and Software Developers).I then decided to develop a high level strategy that will guide the adaption of private sector models for public sector application. Table 1 shows the Private to Public Sector Strategy Adaptation Matrix (PPSSAM) that I developed to guide adaptation of private sector strategies to address public sector realities. TABLE I.

Enterprise Architecture (EA) models applied in the private sector have proved their worth in providing a pathway for, inter alia; developing visual artifacts that enable non-technical business managers collaborate with IT specialists in aligning business goals to technology solutions. The Zachman Framework [6] was one the first EA models to demonstrate the theory that visual models and artifacts can help describe and build complex models that link high-level business questions to software solutions that answer these questions. An interesting approach developed by Zachman was to develop various artifacts that answer similar questions across diverse stakeholder groups like planners, owners, designers, builders and sub-contractors. Using the same approach, I grouped stakeholders in public sector development projects into

Suppliers Substitute Products New Entrants

Hypothesis Three: Current advances in planning and management systems that are gaining ground in the private sector need to be adapted before being applied in the public sector.

Customers

The decision to adopt GIS, which is supported by Hypothesis Two, was also consistent with the overall goal of simplifying dialogue with rural communities through adopting participatory approaches. Village Resources Maps [5], which are unstructured maps, are used in Participatory Rural Appraisal (PRA) methodologies to document the availability of resources within communities and discuss the impact of these resources on development activities taking place within the community. Thus maps are tools that have been successfully used within a media for bridging communication gaps between development officers and communities in place. Village Maps have proved useful in proving insight into a variety of development issues like how activities impact on the environment, gender access to land, location of water sources, availability of extension services and resolving land rights. Using GIS technology within IDSPF is a logical strategy of demystifying ICT through adopting a common visualization language that has been successfully applied in bridging knowledge and skills gaps within stakeholders in socio economic development projects. My approach of using private sector approaches in the public sector ran into problems. I started uncovering problems that seemed to be unique to the public and community development sectors. As a result, I added the following hypothesis to guide deeper inquiry into the public sector realities that were emerging as the project progressed:

Competitors

Based on these hypotheses, I proceeded to develop strategies that would ensure GIS is mainstreamed into most activities undertaken within the project.

PRIVATE PUBLIC SECTOR STRATEGY ADAPTATION MATRIC (PPSSAM) Current Private Sector Strategic Responses

Proposed Public Sector Strategic Responses

Completely obliterate competition in order to become dominant player in the market. Develop strategies for denying the competition access to market information, customers, raw materials and human resources.

Strengthen local competitors so they may serve more clients who are on public sector programmes. Share information and develop capacity of competitors to enter regional and global markets. Provide training, trade promotion, and quality assurance programmes. Encourage compliance and issue licenses.

Reduce power of supplier by becoming the preferred and largest customer. Develop strategies for setting terms for doing business.

Capacitate suppliers to become global players. Ensure competitive environments that creates competitive playing field for all suppliers. Encourage attainment of quality standards and develop supplier database.

Create entry barriers for new and competing substitute products. Maximize own product mix such that own products cover all profitable market niches

Encourage substitutes that lower cost to local companies such that that can enter global markets. Set up research institutions and incubation facilities to support product development. Share product knowledge and promote product and materials research.

Set up barriers for new entrants. Develop competitive strategies that make it costly and risky for new companies to enter the industry.

Encourage new entrants. Provide incubation facilities and organize training, trade promotions, and demonstration visits. Utilize trade missions and embassies to promote new entrants.

Reduce bargain power of customers. Lock in customers such that they do not move to other suppliers.

Empower customers such that they grow and move away from publicly funded programmes. Share information with customers such that they can set up powerful consumer organizations.

PPSSAM provided the adaptation strategy that enabled me to develop stakeholder engagement strategies that are consistent with public sector stakeholder mandates. III.

ICT FOR DEVELOPMENT CHALLENEGES

Most of the documented challenges of ICT for Development (ICT4D) applications have focused on infrastructure challenges [2]. They focus on the rural reach of




national power grids, connectivity, support of hardware and access to ICT. Table 2 shows challenges that have been identified and solutions that have been proposed [3]. What has not been extensively document are problems to do with stakeholder interactions and perceptions in during software development of ICT for Development applications. TABLE II.

DOCUMENTED ICT4D CHALLENGES

Challenge National power grid does not cover rural locations where ICT for Development applications should be rolled out. Connectivity is poor in rural environments.

· ·

· · ·

Cost of ICT too expensive for rural poor

· · ·

Proposed Solution Solar power units. Diesel generators

Use of ―internet in a box‖ solutions that simulate Internet use in remote locations. VSAT technology. External storage devices used to transport data between locations Open Source Software used to lower costs Tele-centers used to created shared resources that lower cost of ownership Mobile computing on cell phones lowers costs of access devices

I carried out a study that highlighted the following as some of the major challenges that would confront software developers who attempt to ensure participation of grassroots communities in the software development cycle: ·

·

·

Common Language: There is need for a common language to bridge the skills and knowledge gap between stakeholder communities and software developers. Visualization, GIS and PRA techniques provided attractive options for solving this challenge. ICT Priority: Stakeholders in social development, especially communities in place, attach very low priority to ICT projects. I chose and approach of developing artifacts that communicate how relevant information is critical to the success of the project. Once the importance of information to project success has been established, I then communicated why ICT is the best resource for hosting the information required. This then removes the stakeholders‘ perception of viewing ICT as an unnecessary indulgence in rural development projects. Identifying appropriate ICT applications: ICT projects for communities in place are usually sponsored by Government or development and aid agencies. This sponsor group is responsible for identifying development interventions and generally accepts that ICT has potential to improve livelihoods. However they have no capacity of envisioning how ICT can be deployed in community projects. Consequently, they do not budget for ICT when they are planning intervention projects. I solved this challenge by developing high level generic artifacts that communicate the link between development projects and ICT in general and then give such models context by

·

developing a pathway that links the model to a specific project being deployed in the community. Participation: Communities in place are viewed as computer illiterate and most software development tools are designed for engaging participants who are computer literate. I chose to use visualization, GIS and PRA as tools for designing inclusive framework guiding stakeholders who develop software for supporting community development interventions.

Challenges in ICT for Development arise due to the multiple and at times disjointed stakeholder interest groups [4] that are found in the community development constituency. IDSPF‘s value is in addressing the identified challenges using the approaches outlined to solve the identified challenges. Existing tools and technologies for analyzing and managing stakeholders in ICT projects have been developed within private sector environments. The corporate laager that has been built in private sector enterprises governs stakeholder interactions within the private sector. Corporate departmental structures, human resources policies, standards, mission statements and strategic and training plans have a huge impact on governing and directing stakeholder interactions and perceptions and roles and responsibilities within corporate ICT projects. Existing stakeholder management approaches either leverage on these corporate issues or attempt to remove barriers that are created within corporate organizations. For example, corporate ICT project governance structures usually bear resemblance to the organizational structure of the organization. Recruitment policies and job profiles have a significant impact in defining skills that are found within stakeholders of a corporation. Stakeholder management strategies can leverage on these skills. In socio economic development projects, such cohesive structures are absent. The community that benefits from socio economic projects comprises a confederation of loose, fluid, informal and at times undefined stakeholder groups. Such groups usually have conflicting perceptions and values about community resources that are used within socio economic development projects. For example farmers and brick makers have different and conflict values attached to water sources within the community. Such conflicting views have potential for nurturing stakeholder conflicts within socio economic projects. These conflicts invariably have direct or indirect influence on ICT for Development projects. Government departments and NGOs are significant players in community development. However their roles are on the ICT4D project can be undefined and conflicting. Existing corporate stakeholder analysis and management tools do not address such challenges. ICT4D is emerging at the time when the development community is embracing the concept of sustainable development. In 1987 the World Commission on Environment and Development (WCED) produced a report entitled Our Common Future which outlined a model for sustainable




development. Since sustainable development is a relatively new concept, there is an absence of a critical mass of development and ICT personnel who are conversant with the critical issues surrounding sustainable development. If ICT4D is to advance human development, it is important that it contributes towards creating sustainable development capacity within stakeholder in community development projects.

·

tools that can be used to demonstrate the value and role of ICT within a community development project. The models used should be visual and participatory.

These are some of the myriad of challenges that IDSPF is addressing. As such, IDSPF is a very compressive framework, which cannot be adequately addressed in a single paper. What I will do is to discuss a few of the IDSPF artifacts solve some of the identified challenges during project planning. IV.

ICT FOR DEVELOPMENT VALUE

Since ICT can be viewed as a low priority resource within impoverished communities, it is important that its value be communicated in the conception stages of the socio economic development project. The ideal point for communicating the value of ICT in community development projects is during an inception consultative workshop. Figure 1 shows how such a workshop fits within the overall rollout plan of a community development project.

Figure 1.

Figure 2.

IICT Awareness Workshop

Figure 3 is quite useful in discussing the role of ICT in socio economic development. I usually use it to build up an approach that demonstrates that sustainable development depends on the community‘s efficiency in utilizing natural and locally available resources during the project life cycle. A community that conserves resources by matching consumption to resource extraction creates less waste. Strategies that reuse resources also create less waste. The real payload of less waste is low pollution and conservation, which in turn leads to a more prosperous society. Societies that fail to do this degrade their environment which eventually leads to impoverishment of future generations. Figure 3 shows how community knowledge is important in sustainable development.

IICT Consultative Workshop

Groups that represent the whole stakeholder community should attend the ICT Planning Consultative Workshop (ICTPCW). Such groups include primary beneficiaries, government departments, NGOs, implementing consultants and community, political and business leaders. The broad spectrum of stakeholder groups present the skills gap challenge when discussing ICT needs. Such groups have varying knowledge about ICT usage, the ICT Awareness session should be guided by the following imperatives: ·

·

It should aim to demonstrate the value of ICT in development. This is where GIS can be used to give ICT context to and demystify ICT application in community development. Fig. 2 shows how the ICT Awareness workshop can add value to later stages of the project. The content should cover development project issues and not technology issues. For example, the concept of sustainable development should be given project and not technology context. Fig 3 shows one of the

Figure 3.

IICT Sustainable Development Model

To sell the value of ICT to participants, it is crucial to demonstrate the value of technology in the development project being pursued. If the project is about dress making for example, the technology to be discussed first should be the dress making technology like sawing machines, cutting machines and cloth making technologies. A case has to be made for demonstrating how knowledge about these technologies and the dress making production processes




adopted by the community contributes to community development. A pathway of linking appropriate adoption of technology and processes to sustainable development needs to be demonstrated. Once this has been achieved, ICT can then be added as one of the technologies that not only contribute to the success of the dressmaking project, but also to sustainable development and to hosting the sustainable development model shown in figure 3. This is where ICT‘s advantages in hosting Information and Knowledge systems can be discussed. Figure 4 can be used to discuss how ICT will be used to host the community knowledge system.

Figure 4.

Four Ps IICT hosting model.

The tool in figure 4 is useful in requirements analysis since it provides a template for guiding ICT Planning Consultative Workshop deliberations as indicated in Table III. TABLE III. Four Ps Place

People

Processes

LINKING FOUR Ps TO REQUIREMENT ANALYSIS Link to democratizing Software Development This establishes the physical boundaries of the project and provides the business case for using a GIS. The baseline about settlement patterns, spatial distribution of natural resources, the state of the environment and location of markets can be visually discussed with ―computer illiterate people‖. GIS provided us a powerful resource for developing a comprehensive pathway for including rural poor in requirements analysis. This provides the basis for creating a database of the project beneficiaries. Using GIS as the base technology enables one to show the spatial distribution of beneficiaries within the community. Their spatial relationship to the baseline maps built in the ―Place‖ perspective can be analyzed and the projects impact on the state of the environment tracked. I have already alluded to the fact that the IICT system user requirement analysis should be carried out with the community in place. For example, in a Goat Marketing project, community members are capable of discussing activities like vaccinating, building shelters, selling, and culling. These activities translate to processes. Social development practitioners have developed PRA as an effective participatory technique for engaging grassroots in brainstorming development project activities. I have leveraged PRA to build powerful IDSPF tools that use GIS as the base technology for simplifying user requirements analysis .

Four Ps Plans

Link to democratizing Software Development This helps in scheduling activities identified in the Processes perspective. This then constitutes the Project Plan of the intervention and the GIS then provides an environment for a building a spatially enabled monitoring and evaluation system.

The tools shown in figures 1 to 4 have proved to be simple enough to be understood by the representative groups that are targeted by the ICT Consultative Planning Workshop. My experiences in using these tools in developing LSIS and the ADNSIS software demonstrated that the simplicity of these tools does not compromise their ability to address the complex challenge of including grassroots in software development activities. These tools, together with others that comprise the comprehensive range of IDSPF artifacts, have been used to enable participation of ―computer illiterate‖ stakeholders in defining and setting up structures like Village Knowledge Worker Clusters whose responsibilities are to, inter alia, collect and validate community generated data before it is submitted for captured in the IICT application. The same ―computer illiterate‖ groups have also successfully used IDSPF tools in defining systems‘ Project Information Model during User Requirements Analysis conducted during ICT Planning Consultative Workshop. Thus the tools have significantly served the goal of democratizing software development by involving stakeholders who would be otherwise excluded from software development activities. A broad range of issues have emerged. For example we have noted that the stakeholder community is broad. You have the community in place (the grassroots), you have the government agencies, you have donor and development agencies and you have consultants and software engineers. This is a very diverse collection of focus groups and it is not possible to have a single tool that bridges the communication gap. Our approach has been to develop a collection of tools that are target the participants at each stage of the project stages outlined in Figure 1. The original approach had been to identify tools in the corporate sector and adapt them for use in the public sector if they address the identified challenge. I only justified the development of new tools where adaptation proved ineffective. However what has come as a pleasant surprise is that the new tools can be applied to the corporate sector with very little adaptation. This has major implications. Although the approaches used in the corporate sector to reduce the application backlog have recorded acceptable returns, I hypothesize that the new tools I have developed can contribute towards simplifying software development dialogue in the corporate sector. I believe this is possible since I have applied these tools in corporate consulting assignments. Their simplicity and visualization simplifies communications and clarifies concepts during stakeholder engagements in the corporate sector. IDSPF comprises a range of artifacts that address specific public sector challenges that I identified within the software development cycle. Only four artifacts are




building blocks of objects in UML terminology. Consequently GUS Docking Stations links IDSPF with software engineering tools that are familiar to most software designers. This bridges the gap between development stakeholders and software engineers.

discussed in this paper. These are artifacts that are used in the planning stages of the software development cycle. Table IV provides a summary of the current range of artifacts that comprise IDSPF.

Planning Stages

TABLE IV.

SUMMARY OF IDSPF ARTIFACTS

Artifact ICT Consultative Workshop (ICTCW)

Target and Purpose Used to provide a project road map to Sponsors (i.e. Donor Agencies, Government officers, extension workers and software engineers) on how to manage an IICT project that ensures inclusiveness.

IICT Sustainable Development Model

Provides a model for discussing the value of ICT in development projects. Grassroots usually perceive ICT as having lower priority in improving their livelihoods and the IICT Sustainable Development Model removes this perception. Provides a method of identifying how GIS is an appropriate tool for providing information that cuts across most socio economic development models. This tool can be used in enabling sponsors to develop capacity to identify ICT applications that are aligned to development projects. PRSP is a model used for rewarding workshop participates during workshop deliberation. Participants choose icons that represent assets like livestock, houses, farm equipment, natural resources and farm produce and pin these on a spatial map that represents an ideal environment they would like to live in. This tool is useful as an icebreaker during ICT Consultative Workshops since it introduces mapping techniques and lays the ground work for demonstrating the value of GIS as a tool for bridging stakeholder skills gaps. A PRA workshop facilitation technique commonly used in development is to have participants capture their contributions to workshop deliberations by record short sentences in cards that are then pinned on the wall. HPIM is used to rearrange the cards into hierarchical groups and then demonstrate how GIS can be used to provide Resource and Social Maps that address the projects information needs. The PVIM is a tool used by software designers to convert the HPIM that was built by participants during ICT Consultative Workshop into workflow that forms the basis of mapping software processes to program activities identified by stakeholders who include grassroots communities in place. GUS Docking Stations are used to dock each process in the PVIM workflow and articulate how software modules will provide GIS, structured and unstructured information. Elements of GUS Docking Station can be directly translated into classes that are the

Four Ps of ICT Hosting Model

Requirement Analysis

Participatory Rewarding Spatial Model (PRSP)

Hierarchical Program Information Model (HPIM).

Logical and Design

Program Value Information Model (PVIM)

GIS, Structured and Unstructured (GUS) Docking Station.

V.

CONCLUSION

The true value of ICT4D in development is going to be realized when ICT is applied in line-of-business areas in development. To achieve this, ICT has to support core socio economic project activities rather that the current situation where ICT is used mainly for word-processing and spreadsheet production. The process of embedding ICT in project activities has to be guided by the successful strategy of involving communities in designing project goals, objectives, activities and monitoring and evaluation. Development practitioners have successfully demonstrated that PRA techniques promote dialogue with grassroots during community development interventions. Existing software development tools are not optimized for addressing communication gaps that that exist between stakeholders in community development projects. These challenges emanate from the fact that stakeholders in community development environments comprise of loosely coupled independent groups that have, at times, conflicting agendas. ICT practitioners tasked with implementing ICT4D projects need to develop innovative approaches to addressing these challenges. In this paper I have attempted to outline how IDSPF solves these challenges and leads to democratizing software development by involving communities in place in articulating how technology should be used to improve livelihoods. This ushers in a new breed of applications I have come to call IICT. [1]

[2]

[3]

[4] [5]

[6] [7]

M. C. Yotco 1999. ―Joint Application Design/Development, Systems Analysis‖ [online] Available from www.umsl.edu/~sauterv/analysis/JAD.html [Accesed 16 March 2012] M. Jekins, J Van Rensburg, A.Veldsman, 2008. ―From Technologists to Social Enterprise Developers: Our journey as ICT for Development Practitioners‖ Information Technology for Development, Vol 14 (1) 2789 Inveneo, 2010 ―Sustsainability ICT Primers: What to consider when designing ICT projects for low-resource environments‖ [onlime] Available from www.inveneo.org [Accessed 11 Novemebr 2011]. C. Jamu, 2011. The New Harvest: Agricultural Innovation in Africa, Oxford University Press. FAO Corporate Repository. ―Conducting PRA Training and Modifying PRA tool for Your needs‖ [online] Available from www.fao.org/docrep/003/x5996e06.htm#6.2.1 [Last Accessed 5 June 2012] J.A Zachman, 2000. ―Enterprise Architecture – A framework‖ [online] Available from www.zifa.com [Accessed 25 August 2009] J.G. Collins and J. Porras, ―Built To Last‖ NewYork: Harper Business, 1997.




Multi-Perspective Ontology to Understand Organizational Requirements Mesfin Kifle IT PhD Program, Addis Ababa University Addis Ababa, Ethiopia [email protected]

Abstract—Requirements elicitation is a collaborative process that needs both domain and system experts’ attention to deal human and organizational aspects. Collaboration helps to build shared understanding about a system’s environment or contextual situation where a new information system intends to be a part. Lack of structured organizational knowledge representation and in depth understanding of organizational situation that includes both hard and soft system aspects, leads to poor requirements specification. In this paper, based on a conceptual model of an organization, a multi-perspective ontology is proposed to structure organizational knowledge. As a result, it facilitates expert-user collaboration and assist experts to understand contextual requirements. Empirical findings are examined to nurture the proposed ontology. The results, obtained in a case study, are encouraging to make use of the ontology. Keywords— Multi-Perspective; Ontology; Requirements Elicitation

I. INTRODUCTION Requirements elicitation is a collaborative process that needs domain and system experts‘ attention to deal human and organizational matters. It is a time of learning for action. In order to do act sensibly it needs to have a clear idea of what an organization is we are intervening in including the organizational and human factors. This means that while dealing organizational situations it is important to keep the whole in mind including the hard and soft system aspects [1], [2]. There are several factors for information system failures. According to [1], in many of the information systems failures the conclusion has been placed squarely on human and organizational factors rather than technical ones. The same result comes to effect if we are not making use of users‘ business knowledge during information system development. In soft systems methodology, the human factor is discussed in line with the notion of problematical situation of an organization [3]. Furthermore, since the nature of an

organizational system is too complex, understanding the problematical situation is important before taking action for change. Therefore, it is essential to include people in models in a way that represents their viewpoint. Despite the hard systems nature that mainly express in the form of business goals, processes and roles formally, the human aspect is too intricate since humans are knowledgeable entities. Davenport and Prusak [4] pointed out that knowledge in an organizational system is an accumulated result of experience, values, contextual information, and grounded intuition that originates and is applied in the minds of owners. It is also often embedded in organizational routines, processes, and practices. Moreover, goal aspects profoundly influence problem understanding by providing direction and focus in knowledge management. Employees develop and shape their working knowledge through multiple interactions with others by observing intentional behaviour and perceptions [2]. Therefore, it is also important to explore organizational knowledge in a multiperspective approach to facilitate collaboration, shared understanding, and then master the application domain knowledge [5]. As presented in Floyd et al. [6], the value of a multiperspective approach in information system development is highlighted. Perspectives are viewed for mutual learning for both developers and users, and this can be supported and facilitated by employing technical solutions. Ontology approach is widely used to address such issues. Ontology is commonly defined as ―a formal explicit specification of a shared conceptualization‖ where conceptualization refers to an abstract model of some phenomena in the world by having relevant concepts of the phenomena for some purpose [7]-[9]. The notion of situated ontologies is discussed in [10] to denote conceptual views in communities of practice. It is useful to organize and access knowledge to facilitate communication. Therefore, ontologies in information systems




development are like world models that would facilitate knowledge sharing and reuse. In literatures, there are several attempts which have proposed and used ontology as a technique for requirements elicitation [19], [21]-[24]. But, as discussed in section six, their capability to incorporate both hard and soft system aspects is limited, and particularly the human aspect in a multi-perspective approach is ignored. This paper is in reflection to the situation mentioned above, and it proposes a multi-perspective ontology to help experts and domain users to understand organizational requirements through mutual learning. This demands to address As-Is situation of organizations and anticipated To-Be system visions. The remaining part of this paper is organized as follows. In section II, organizational aspects, empirical findings, and perspectives are discussed. Section III presents the proposed conceptual model and ontology structure. In Section IV, implementation of the proposed ontology using an ontology development tool, protégé-2000, is presented. The related works are presented in section V, followed by conclusion and future work. II.

THE PREMISE

A. Three Aspects in Organizational Systems The author in [26] described three aspects in an organizational system: organizational, human and system aspects. The organizational aspect refers to concepts that are needed to build structure of an organization as they are described in business workflows. The human aspect includes both employees and customers. In reflection to organizational services, customers‘ have their own service view. Such services shall be realized through set of organizational tasks. The system aspect refers to any type of computer application (or agent) that supports organizational tasks. B. Empirical Findings The nature of employee task or working knowledge is discussed in the preceding section. For one year period since March 2010, a study has been conducted at the Office of the Registrar, Addis Ababa University. The aim was to understand employees‘ knowledge and detect pattern of activities or actions. The Office has thirteen branch units that provide academic related services. All active students get service from these units. The units are distributed across various Faculties, which are geographical dispersed. The main unit is located at the main campus, and it provides alumni service. During the study period, it was attempted to analyse and understand employee task knowledge and type of patterns and variability that can possibly be exhibited. Four task accomplishment or performance audits have been conducted

including employees‘ experience in the existing student information system. And then, based on the audit reports, consecutive plenary face-to-face discussions were made with heads of the units. Additionally, task stories of two employees, who were working at different units, have been collected and analyzed for seven student services. Consequently, based on the analysis results, employee task knowledge variability factors are identified. The factors potentially affect employee task knowledge pattern. The factors are: Location factor: in the study it is observed that employees in seven units have developed their own knowledge, which is unique to each unit. Two basic reasons are also identified: the unique type of problems that had happened in the unit and prior experience of the Faculty, the unit belongs. For example two Faculties were independent institutes before they were integrated to the University, and had their own practices. Experience and competency factor: due to self competency and range of work experience some employees have developed their own set of activities to accomplish a similar task than others. Such situations have also been observed in the same location. Education type factor: employee educational qualification type also affects the nature of employee task knowledge. In the study, variations in employee task knowledge pattern have been observed as to their educational type. For example, for roles like unit heads, the educational qualification requirement is basically defined based on educational level than type. For instance, to be a unit head, having a bachelor degree in any field with some years of experience is enough. The findings, in conclusion, points out that, in order to have a wider and in depth understanding about the working environment and situational problems, it is necessary to have a set of criteria during requirements elicitation so as to reach to the various types of employee working knowledge pattern and detect variability. C. Perspectives Humans have their own perspectives towards organizational systems [11]. A person‘s perspective is part of the cognitive universe that may structure her or his cognitive process when relating to situations within some domain [12].




In this paper, based on the type of collective organizational role behavior and their theoretical framework, three perspectives have been identified and discussed in this section: managers‘ (organizational or workflow), employees‘ and customers. Managers‟ (Organizational or workflow) Perspective: In organizational theory, an organization is a means to an end to achieve its goals. And, the management function is concerned with assigning tasks, grouping tasks into departments, and allocating resources to departments [13, 14]. Additionally, managers‘, who are also active members in an organization, are primarily concerned about how employees are performing tasks against the way tasks are stipulated in the organizational structure. The managers (organizational) perspective fosters productivity by promoting standardization and transparency, enabling traceability of past process executions, allowing effective controlling and monitoring mechanisms, and permitting easier synchronization and coordination of networked and interdependent activities. Here the process is in focus and dictates the way of execution down to details [15]. Employees‟ Perspective: The theoretical ground for this perspective is activity theory. Activity theory is a broad theoretical framework for describing the structure, development, and social context of human activities. According to this theory, an activity is the way a subject (either an individual or a group) moves towards an object with the purpose of attaining certain results or certain objectives. Participating in an activity is performing conscious actions that have an immediate and defined goal, or objective [16].

considered as a customer for unit B from the point of view of services, where unit B provides. Customers, by nature, build their view about an organization, and even, implicitly or explicitly, set ‗service standards‘ for their own sake based on what they assumed tobe. On the other hand, managers and employees might not envisage their customers view unless they set out proper demand side or customer-oriented management. III.

THE PROPOSED ONTOLOGY STRUCTURE

Based on the perspectives described in the previous section, a conceptual model is defined. Its intended meaning is described in the proposed ontology structure. In this section, the proposed conceptual model, the ontology structure with formal semantic definitions, user task story criteria, and sample ontology based queries are presented. A. The Conceptual Model Fig 1 shows the proposed conceptual model in line with the three perspectives. A task is a piece of work that is formally defined in an organizational system. In the model, tasks are considered as core or central concept in which organizational roles are based. Moreover, they are also assumed as operational goals. Business goals shall be operational through business processes or services, and each process is a collection of tasks in some order. Employees, as a human being, react and handle tasks by doing a set of activities as theoretically grounded in activity theory. In addition, based on the business processes that are defined or accustomed through experience, an employee plays a role towards the achievement of goals.

Employees‘ interaction might also bring unforeseen practices over time in an organization. As a result, in an organizational context, some business processes might be tacit. They are developed by the people over many years of experience and passed on from experienced workers to new recruit [17]. In reflection, therefore, there should be a means to capture these kinds of knowledge during requirements elicitation. As described in the next section, task stories are used and integrated in the proposed ontology to capture and analyze employee task knowledge.

Customers have service view towards an organization. A service is realized through a set of tasks that might span across business processes.

Customers‟ Perspective: Customers are individuals (or individuals that represent firms) that obtain service from an organization or a sub unit of an organization. They expect effective and efficient service. In response to the demand, organizations should work towards customers‘ goal satisfaction.

In this paper, an ontology is defined as depicted in [18] with a structure O =: {C, R, Hc, rel, Ao} where C is set of concepts, R is set of semantic relations, Hc (C1,C2) is the taxonomical hierarchy of concepts C1 and C2, rel: Rà C x C is a non-taxonomical relation function and Ao defines axioms that control or constrain behavioral properties of concepts and their relationships.

In this paper, the concept customer refers not only those, who are external entities to the organization but also employees and other individuals with respect to the target organizational unit where the system expert is dealing. For example an employee of an organization in unit A can be

As discussed in the previous section, a software system, if there is any in the existing situation or the intended software-to-be, is also another aspect in an organizational system that supports employees to accomplish their task in a better way. B. The Ontology Structure




Employee Perspective (Human Activity)

Manager (workflow) Perspective (Goals & Processes)

Software System (Requirements)

Tasks

Customer Perspective (Service View)

Fig 1: Perspective based conceptual model for the purpose of organizational requirements

For the purpose of this paper, the ontology in [19] is further refined and extended as shown in fig 2 so that it can reflect the points which are discussed so far. The concept goal refers intentional feature of an organization 1 . Goals are achieved through processes. A process is consists of a set of tasks that might require an artifact or resource during task execution. An employee has story about a task or set of tasks Moreover, an employee has intent or motivation that is potentially derived from goals to play a role. Employee task knowledge shall be tracked and be analyzed based on sufficiency criteria described later in this section. Likewise, education type and experience of an employee shall be maintained as properties of the employee concept. An agent represents a software system that either currently exists (as-is) or the intended (to-be) system. A set of tasks shall be supported by an agent in line with the related business goals. And an agent can be activated by an employee. An agent is supposed to satisfy a set of requirements. While eliciting requirements for an agent the proposed ontology guides to explore the related concepts in each aspect.

Therefore, the set of concepts in the ontology structure is C= where

G : is set of goals; T: is set of tasks; Ar: is set of artifacts; E: is set of employees; S: is set of services; Rq: is set of requirements;

P: is set of processes; A: is set of agents; Ro: is set of roles; Cm: is set of customers; L: is set of locations;

C. Formal Semantic Definitions Based on the ontology structure in the previous sub section, the following semantic definitions or axioms are defined in first order logic. Definition 1: the set of business goals in the ontology structure is denoted as G = {g1,g2,…,gn}. If gi∈G, then a unary predicate Goal(gi) is true. Definition 2: the hierarchy of goals is built by applying the goal refinement technique, i.e. a goal gi ∈ G can be RefinedTo one or more goals. Indeed, a RefinedTo

1

Organizations define intentions at different levels using terms vision, objective, purpose, goal or other similar terms. The goal concept, in this paper, can refer all these.




Human Aspect

Organizational Aspect

System Aspect

/ RefinedTo

Customer Goal / hasViewOf

/ InteractsWith

/ achieves

/ partOf

/ isRealizedBy

Service

Agent

/ ConsistsOf Task

Process

Supports / Requires

hasStoryAbout

/ MightActivatedBy

/ ResponsibleFor

Artifact

/ PlaysAs

Satisfy

Employee

Role / WorksAt

Requirements

/ ExchangeWith Location

Fig 2: Multi-perspective ontology structure for requirements elicitation

taxonomical relation is written as RefinedTo(gi,gk) and defines that gk is a refined goal of gi.

process pi consists of a task ti, then it is written as a binary predicate consistsOf(pi,ti).

Definition 3: the relation RefinedTo is transitive, nonreflexive and anti-symmetric.

Definition 7: the hierarchy of processes is built by partOf taxonomical relation, i.e. if a process p k is part of process pi, then it is written as a binary predicate partOf(pi,pk).

(transitive) ∀(g1,g2,g3) ((RefinedTo(g1,g2) RefinedTo(g2, g3)) → RefinedTo(g1,g3)) (non-reflexive) ∀g1 ~( RefinedTo(g1,g1) ) (Anti-symmetric) ∀ (g1,g2) (RefinedTo(g1,g2) → ~(RefinedTo(g2,g1)))

Definition 8: the relation partOf is non-reflexive, transitive and anti-symmetric (Non-reflexive) ∀p1 ~(partOf(p1,p1)) (Transitive) ∀(p1,p2,p3) (partOf(p1,p2) partOf(p1,p3))

Definition 4: a set of tasks in the ontology structure is denoted as T = {t1, t2, …, tm}. If predicate Task(ti) is true.

ti∈T, then a unary

(Anti-symmetric) ~(partOf(p2,p1))

∀(p1,

p2)

partOf(p2,p3) →

(partOf(p1,p2)

→

-

Definition 5: The set of processes in the ontology structure

Definition 9: a set of agents is denoted by A =

is denoted as P = {p1, p2, …, pk}. If pi∈P, then a unary predicate Process(pi) is true.

{Ag1,Ag2,…,AgN). If Agi∈A, a unary predicate Agent(Agi) is true.

Definition 6: a process is a collection of ordered tasks and the collection set is defined with consistsOf relation. If a

Definition 10: the relation supports is defined to spell out the tasks that are going to be handled by an agent, i.e. a




binary predicate supports(Agi, ti) defines an agent Agi supports task ti. Definition 11: a process should consist of at least one task and every task should be aligned in a process. ∀pi (∃ti (Process(pi)

Task(ti)

consistsOf(pi,ti))

sample queries are presented to demonstrate the ontology query value. Query 1: Display

all processes and tasks that are

supported by the agent (software-to-be) Query 2: Display customer stories on the basis of Query 1 results

∀ti (∃pi (Process(pi)

Task(ti)

(consistsOf(pi,ti))

Definition 10: a service is realized by at least one task. The relation isRealizedBy is defined to spell out the collection of tasks that realize a service, i.e. a binary predicate isRealizedBy(Si, Ti) defines a service Si is realized by a set of tasks T i where Ti T.

Query 3: Display goals that are supported by the software-to-be Query 4: Display processes that do not have employee stories Query 5: Display all goals on the basis of Query 2 results

D. Sufficiency Criteria for Employee Stories The empirical findings, discussed in section two, are pointed out that setting minimal sufficiency criteria about the type and number of employee stories is critical. This helps experts to have a broader and in depth understanding about situational problems. In this multi-perspective ontology the following criteria are defined. Experience coverage is a criterion, which is defined by considering experience and competency factor. It demands to maintain at least two employee task stories per role: preferably experienced and junior employee stories. Location coverage is a criterion, which is defined by considering location factor. It demands to apply the experience coverage criterion across geographical location diversity. This criterion highlights to collect task stories from similar units that are working at different locations. When the number of locations is high in number, it could be challenging to apply the criterion as it is. Therefore, situational problem reports or other data collection sources can be reviewed to apply the criteria optimally. Service coverage is a criterion that demands to take customers‘ story about the nature of services they get. At least one customer story for each type of service is mandatory to satisfy the sufficiency criteria. E. Sample Queries Domain and system experts need to discuss and learn to each other by using ontology based queries. The proposed ontology structure allows answering questions that would augment to understand the context and analyse the scope of the system-to-be in the existing situational problem. Below

All the above queries can be answered using the proposed ontology concepts, their properties and relations. IV. IMPLEMENTATION The proposed ontology structure is implemented using Protégé-2000, a knowledge base ontology development tool. Protégé-2000 has many utilities to define concepts, relationships and axioms. Moreover, queries can be defined and keep in a query library and run by users [20]. Concepts in the proposed ontology are defined as concrete classes, and the relations are maintained using slots and facets. By the time of requirements elicitation, instances or particulars of concepts shall be created based on the proposed ontology structure. The axiomatic semantic definitions, defined in section four, are implemented using PAL (Protégé Axioms Language) constraints. Queries are defined to retrieve associated concepts and task stories by considering the three perspectives. To evaluate the validity of the proposed ontology, the author has participated in the project, which was aimed to develop alumni service system. The ontology content was maintained by supplementing it with expert and user level discussions. Employee and customer stories were analyzed to understand tacit knowledge and identify services, which have not been formally identified in the organizational perspective. As a result, three services and associated artifacts were able to track and address. The project is still underway and the ontology is also applying to understand the situation in depth and elicit requirements. The result is promising to make use of multi-perspective ontology to understand organizational requirements.




V. RELATED WORKS The ontology in [19] is defined as a learning artifact that will be used as a cooperation modeling for integrating organizational change into system development process. Three ontology structures are proposed corresponding with the three aspects mentioned in section two: organizational, human and system 2 . But the three ontologies are not integrated. Rather they are defined separately. Moreover, it does not consider human and employee perspectives discussed in section two. Business goals that derive application requirements are not included. In this paper, the three ontologies are adapted by considering the above shortcomings. Ontology based service requirements elicitation and knowledge extraction is described in [21, 22]. The authors proposed knowledge and intention oriented service requirements ontology for service selection and composition. They aimed to assist participants through formal reasoning to understand the social organizational relationships. Even though concepts like goals, tasks, and actors are maintained, their attempt to capture humans‘ knowledge in an organizational situation is limited. In addition, the ability to address tacit knowledge is not well addressed. In [23, 24] ontologies are defined to elicit requirements. The proposed ontology keeps functional requirements and their relations to represent domain knowledge. A reasoning power is added through inference rules and mapping procedures. User requirements are the main input in the proposed method. Then, further analysis shall be done. The authors aimed to utilize the ontology at the later stage of requirements analysis. It does not help much to address how to capture and analyse employee task knowledge systematically. A review of the method that combines goals with scenarios is discussed in [25]. The two concepts complement to each other. A way of discovering goals through scenarios is pointed out in the method. A linguistic analysis is applied to reason out scenarios. It does not use ontology as a means for representation. In this paper, the idea of taking scenarios and goals has been taken in an ontological approach.

It is used to model stakeholders, their objectives and processes. The notion actor is a central concept in i*. It has been used to represent agents, roles, and positions. An actor has attributes such as goals, abilities, beliefs and commitments. But its capability is limited to represent customer view point and capturing tacit knowledge. VI.

In this paper, based on literatures and empirical findings, I have presented multi-perspective ontology for requirements elicitation. The ontology aims to build shared understanding among experts and users during early stages. It represents core situational concepts of an organization by considering the three perspectives: managers‘(organizational), employee and customers. Sufficiency story criteria are defined in reflection to the empirical findings to enrich and support in depth understanding. Furthermore, the proposed ontology is implemented using an ontology development tool, Protégé2000. Test results have shown that task stories significantly help to understand the tacit working knowledge and uncover tacit requirements. To extend the functionality of the ontology, goal and scenario based analysis has to be further explored to extract intentional and task oriented concepts and map them to the ontology structure. This research work is currently underway. Furthermore, in the future, there is a need to link the ontology with use cases. ACKNOWLEDGMENTS The author would like to thank Christiane Floyd and Tesfaye Biru for their support as doctoral research supervisors. This paper is a progress report of this research. REFERENCES [1] [2] [3] [4]

[5]

The i*/Tropos, discussed in [27], is an agent-oriented framework that can be used for requirements engineering. 2

Due to space limitation the ontology structure and its descriptions are

CONCLUSION AND FUTURE WORK

[6]

D. Avison, and G. Fitzgerald, ―Information Systems Development,‖ McGraw-Hill Edu, 4th edition, 2006. P. Checkland, and J. Poulter, Learning for Action, Jhon Wiley & Sons Ltd, 2006. P. Checkland and J. Scholes, ―Soft systems methodology in action,‖ Wiley Chichester, 1990. T. H. Davenport and L. Prusak, ―Working Knowledge: How organizations manage what they know,‖ Harvard Business School Press, Boston, 2000. T. Biru, ―Reflective Steps,‖ PhD dissertation at the Department of Informatics, Hamburg University, 2008. C. Floyd, W. Mehl, F. Reisin, G. Schmidt, and G. Wolf, ―Out of Scandinavia: Alternative approaches to software Design and System Development,‖ Human-Computer Interaction, Volume 4, 1989, pp. 253-350.

not included in this paper.




[7]

[8] [9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

T. R. Gruber, ―Towards Principles for the Design of Ontologies Used for Knowledge Sharing,‖ In: Guarino, N.; Poli, R. (eds.): Formal Ontology in Conceptual Analysis and Knowledg Representation. Kluwer Academic Publishing, Deventer, 1993, pp 907-928. C. Calero & M. Piattini, ―Ontologies for Software Engineering and Software Technology,‖ Springer-Verlag Berlin Heidelberg, 2006. Dang Viet Dzung and A. Ohnishi, ―Ontology-Based Reasoning in Requirements Elicitation, Software Engineering and Formal Methods, Seventh IEEE International Conference, vol., no., 2009, pp.263-272, 23-27. C. Floyd and S. Ukena, ―On Designing Ontologies for Knowledge Sharing in Communities of Practice,‖ Proceedings of the CAISE‘05 Workshops Vol. 2,Portugal. FEUP, 2005, pp. 559-569. Barry Smith, ―Beyond Concepts: Ontology as Reality Representation,‖ Proceedings of Formal Ontology and Information Systems, 2004. K. Nygaard and P. Handlykken, ―The System Development Process: Its setting, some problems and need for methods,‖ software engineering environments, Amsterdam, 1981, pp. 157 – 172. N. Russell, A. ter Hofstede, W. van der Aalst, and N. Mulyar, ―Workow Control-Flow Patterns: A Revised View.,‖ Tech. Rep. BPM-06-22, BPMcenter.org, 2006. Ivan Markovic, Marek Kowalkiewicz, ―Linking Business Goals to Process Models in Semantic Business Process Modeling,‖ 12th International IEEE Enterprise Distributed Object Computing Conference, 2008, pp.332-338. A. Rickayzen, H. Maus, and W. Aalst, ―Challenges for Business Process and Task Management,‖ Journal of Universal Knowledge Management, vol. 0, no. 2, 2005, pp, 77-100. GC. Neto, A. Gomes, J. Castro, S. Sampaio, ―Integrating Activity Theory and Organizational Modeling for Context of Use Analysis‖, Proceedings of the Latin American conference on Human-computer interaction, 2005. P. Hall, and J. Fernandez-Ramil, ―Managing the software enterprise: software engineering and information systems in context,‖ 1st ed.). Int. Cengage Bussness Press (2007)

[18] K.K. Breitman and J. Cesar, ―Ontology as a Requirements Engineering Product,‖ Proceedings of the 11th IEEE International Requirements Engineering Conference, 2003. [19] B. Lahouaria, ―Cooperation Modeling for Integrating Organizational Change into the System Development Process,‖ SAIS Proceedings, 2007. [20] N. Fridman, R.W. Fergerson, and M.A. Musen, ―The knowledge model of Protégé-2000: combining interoperability and flexibility,‖ Stanford Medical Informatics Technical Report, Stanford University, 2000. [21] Jian Xiang, Lin Liu, Wei Qiao, and Jingwei Yang, ―SREM: A Service Requirements Elicitation Mechanism based on Ontology,‖ 31st Annual International Computer Software and Applications Conference, 2007, vol.1, no., pp.196-203, 24-27. [22] Lin Liu, Qiang Liu, Chi-hung Chi, Zhi Jin, and E. Yu, ―Towards A Service Requirements Ontology on Knowledge and Intention,‖ Sixth Quality Software International Conference, 2006, vol., no., pp.452-462, 27-28. [23] Dang Viet Dzung and A. Ohnishi, ―Ontology-Based Reasoning in Requirements Elicitation,‖ Seventh IEEE International Conference on Software Engineering and Formal Methods, 2009, vol., no., pp.263-272, 23-27. [24] H. Kayia and M. Saeki, ―Using Domain Ontology as Domain Knowledge for Requirements Elicitation,‖ Proceedings of 14th Requirements Engineering, Minneapolis, USA,2006, pp. 189-198. [25] C. Rolland and C. Salinesi, ―Supporting Requirements Elicitation through Goal/Scenario Coupling,‖ Mylopoulos Festschritf, LNCS 5600, 2009, pp. 398-416. [26] C. Floyd, ―Software Design and Management‖, Lecture note, 2008, AAU(unpublished) [27] A. Lapouchnian, ―Goal-Oriented Requirements Engineering: An Overview of the Current Research‖, Requirements Engineering, 2007




Virtual Laboratory Development for Teaching Power Systems via Interactive Experiment Environment Jules Simplice Djeumen1 Department of Power Engineering Vaal University of Technology Vanderbijlpark, South Africa Email: [email protected]

Jo Le Roux1 Department of Power Engineering Vaal University of Technology Vanderbijlpark, South Africa Email: [email protected]

Abstract —The creation and testing of computer-simulated interactive environment laboratory for use in the power systems field education will provide a highly interactive and powerful learning environment for all undergraduate power engineering students. This experiment will prepare students to approach their practical with more confidence and to better understand the theory in the class room. The study of electrical power systems requires a solid background on advanced mathematics, but many engineering students lack this required background. Using this tool, undergraduate students may improve their performance. MATLAB, particularly its Graphical User Interface (GUI) software has been used to design the interactive environment to calculate the fault currents and voltages that occur for different types of fault on the power systems transmission line. The manipulation on the internal connection of the power system components are the main focus. This paper describes the design of an interactive environment experiment for studying power systems fault analysis and the program will make the practical experiments in power engineering more attractive and understandable to undergraduate students. Keywords - MATLAB GUI; Laboratory experiments; learning tool; Simulation; Interactive environment; Power Systems Analysis

I.

INTRODUCTION

Computer technology has the potential to provide a highly interactive and powerful learning environment for engineering and science disciplines. As education and technology merge, the opportunities for alternative teaching and learning methodology expand even more. However, the very rapid rate of change in the fields of technology poses special problems for academic institutions, specifically within the power engineering discipline. There is of course a continual need to update and augment the content of curriculum to keep pace with this change. Online or e-learning has become very popular. Bisták has mentioned that, this development is also reflected in the education of engineers [1]. A virtual laboratory (Vlab) allows a variety of power system experiments to be performed with a minimum cost and minimum risk of hazard. In addition, the cost effective laboratory also allows the students to learn a tool that can be used in a variety of other courses. MATLAB/GUI is a tool that can be used for both design and laboratory simulation work.

Dan-Valentin Nicolae2 Department of Electrical engineering Tshwane University of Technology Pretoria West, South Africa Email: [email protected]

The Engineering field requires a solid background in advanced mathematics, however many engineering students lack this background, and as a result, it is difficult to teach electrical power systems in these programs. Another problem experienced in power systems, besides the students‘ lack of comprehending the mathematical concepts and the cost of the laboratory equipment. These problems result in is interpretation of the data and wasting valuable time during the experiments in the traditional laboratory. These problems can be effectively addressed by improving the student‘s conceptual understanding and comprehension of the specific topics through interactive learning and teaching with a virtual laboratory software package, such as MATLAB/GUI [2]. The goal is to create a virtual electrical power systems laboratory, an interactive environment where students can learn both electrical power systems with the use of MATLAB Graphical User Interface (GUI) as a tool. Students taking the electrical power analysis course are not necessarily required to have prerequisite knowledge of MATLAB/GUI. The primary goal of the electrical power systems fault analysis course is to have the students learn the types of faults that can occur on transmission lines. An additional goal is to have the students learn the latest of software application for lab work. Another objective of this paper is to present an interactive environment based virtual simulation tool and educational tool for power system analysis courses. Specifically on the transmission line, with the calculation of single line to ground (1SG), line to line (2LS), double line to ground (2LG) and three-phase balanced (3LS) fault on the power system analysis with the changing of the setting on different components as generator, transformers, line and motor. The rest of the paper is organized as follows. Section 2 present previous researches on the Vlab solving transmission line problems. The background of the study is presented in Section 3. Theoretical knowledge on the fault calculations is explained in Section 4. Section 5 provides the functionality and the design of the Virtual Laboratory. In Section 6 the laboratory environment experiments and results are presented in detail. The conclusion and future work are listed in the last Section.




II.

PREVIOUS RESEARCH

On a typical power system transmission line, many types of faults can occur. This work will only focus on the balanced and unbalanced three phase‘s faults depending on the parameter of the components included in the systems. Many researchers have completed the fault calculation on the power systems transmission lines; these researchers used different techniques including the Monte-Carlo method [4], the Wavelet Transform [5], [6] and [7], the dynamic phasors modeling [8] and the symmetrical component [2]. None of them have revealed the status of others machines which formed part of the power systems, such as transformers, motor and generator. The MATLAB/M-file has been used to solve balanced and unbalanced three-phase faults using symmetrical components [9], [10] and [2]. Not many researchers used the Graphical User Interface to display the fault currents and voltages. This is the continuation of the work done by Djeumen et al. [3], where different types of faults were tested without considering the changing of components within the power systems setting. In the work completed by [3], the faults were only focused on the transmission line and the internal connection of others components were not considered. The idea of symmetrical components was introduced by Fortescue in [11]. According to Fortescue‘s theorem, three balanced system of phasors can be constructed from three unbalanced phasor quantities. However, this research will only use the symmetrical components method. The proposed method is found to be stable and accurate for the transformation of an unbalanced system to a balanced system. The proposed method has major advantages and it can be easily implemented in MATLAB‘s GUI. Furthermore the method has been experimentally verified via case studies. The aim of this paper is to propose a design of an interactive environment virtual laboratory to calculate different type of unbalanced and balanced faults on the power systems transmission line. Our initial effort is to consider the internal connection of the transformers, generator and motor which are part of the system. Subsequent to this introduction, initial findings on the problems relating to the current manual laboratory practice are presented. We also describe the design of the system interface which depicts the actual experiment. III.

BACKGROUND

In a normal laboratory, students are usually expected to read the laboratory write-up or manual before the actual laboratory session takes place. During the laboratory session, the lab-technician may explain the main points of the experiments and demonstrate the use of the related equipment. At the end of the session, the students are expected to submit a report within a limited time frame. Based on these traditional laboratory settings, Lee [12] pointed out some drawbacks. Firstly, it may promote plagiarism in report writing among students as they are given a limited time frame to carry out experiments, doing calculation, performing analysis and writing the report. Secondly, meaningful discussions between the lab-technician and the students are reduced due to the limited time line; the student spent in the laboratory performing numerous tasks. These factors may hinder the valuable learning experience while student should gain important knowledge from the practical work.

The concept of reviewing the effect of introducing computer-based laboratories, as pre-laboratories for traditional laboratories, was chosen for several reasons. First, since traditional laboratories provide essential learning experiences in engineering education, it was decided to study how computer literacy could improve during this exercise. Secondly we hoped to indicate that the time needed for learning how to use a physical laboratory could be reduced by utilising a virtual laboratory as a pre-laboratory. Success in demonstrating this effect would enable us to argue that traditional laboratory costs could be reduced (i.e., by decreasing the time requirements for teaching assistants and the demands on the traditional laboratory). Thirdly, we hoped to determine which knowledge and skills virtual laboratories can facilitate. Fourthly, we hoped to determine if the use of virtual laboratories will improve student abilities to use a traditional laboratory and what level of competency students will attain by using the interactive environment. In future engineering education will certainly be facilitated by computers-in classroom instruction as well as laboratory instruction. A decrease in the cost of computer equipment coupled with the increase in computer literacy and practical skills guarantees that computer-facilitated learning will become a central concern in the study field of engineering education. The majority of students will have their own computers, just as every engineering student in the past had a screw driver or plier. Hence, it becomes mandatory for the engineering educator to understand how to apply this technology effectively for educational purposes. An initial survey was carried out to establish if the subject was perceived as difficult and to determine the usability of the laboratory experiment. Forty five power engineering students registered for the power systems subject participated in this survey. When asked about the importance of the power systems subject, seventy five percent agreed that it is a very important subject, while twenty five percent indicated that it is an important subject. Following the importance of the subject, more than three quarter of the students seventy six percent indicated that power systems as a subject and the topic of unbalanced faults is difficult. This analysis confirms that currently, students still perceive the subject to be difficult as has been reported in the literature of Kai et al. [13]. Fig. 1 presents the results on problems encountered during the practical laboratory session. Twenty percent of the students admitted their lack of skills in order to perform the experiments successfully. Fifteen percent agreed on their lack of preparation for the experiment, thirty percent indicated that the laboratory has limited equipment and fifteen percent indicated that the laboratory technician was incompetent. Fifteen percent of students agreed the limited time allocated in the traditional practical laboratory session and five percent for others eventualities. These factors may hinder them from successfully grasp the key concepts and knowledge expected from the experiments performed.




IV.

THEORY

KNOWLEDGE ON THE FAULTS CALCULATION

The main parameters on the fault calculations will be the positive sequence reactance, negative sequence reactance, zero sequence reactance (Z1, Z2 and Z0) respectively and includes the phase voltage Ea These parameters can be used to calculate the symmetrical and unsymmetrical faults. The symmetrical components have been explained in detail by Djeumen et al. in [3], hence only the summary of the formulae is presented. FIGURE 1: PIE-CHART

OF PROBLEM ENCOUNTERED DURING THE PRACTICAL

A. Three-phase fault

SESSION

(1) In order to overcome these problems, an interactive environment system to support the laboratory work is seen as a promising solution. Ninety five of the students agreed on the suitability of virtual laboratories to enhance their learning. In an interactive virtual laboratory, students have the ability to interactively adjust parameters of a system, which can then be evaluated and displayed in real time. With the advancement of technologies, more research has been completed in order to investigate the possibility of a simulation laboratory to complete experiments via virtual laboratories. A Vlab can summarize all basic knowledge and practical experience in an interactive environment and students may effectively grasp the concept of the fundamental power system [14]. Karady et al., in [15] mention that the teaching of Power Systems operations can be improved using a simulation laboratory. Vlab has been used in many fields such as Electronics [16] - [17], Geotechnical Engineering [18], Thermodynamics [19], Radiation Heat Transfer [20], Microelectronics [21], Tele-Control [22] Experimental design

(2) Where Ea and Z1 are phase voltage and positive sequence reactance. B. Single-phase to ground fault (3)

(4) Where Z0 and Z2 are zero and negative sequence reactance. C. phase-phase fault

(5)

by Koretsky et al., in [23] and Computer Networks [24]. Vlab is seen in many disciplines and has more contributions in the engineering sector. In view of this we can confirm that the Vlab is used all over in the educational sector. The given examples supplied a good demonstration of how the virtual laboratory and interactive environment that are based on theoretical concepts and simulations can be explored for education. The virtual laboratories allow students to investigate simple and complex phenomena by changing

(6) (7) D. Two-phase to ground fault

parameters, boundary conditions and other mathematical variables within computer-generated experiments [3]. However, there are certain limitations in virtual laboratories (even the most well designed software system cannot anticipate all the intricacies) such as bias error and noise [11]. In this paper, the proposed virtual laboratory attempts to present an

intermediate approach in learning. It aims is to assist the student in performing the experiments virtually in a more efficient manner so that they are better equipped to analyze the data in class and in the traditional laboratory. In addition, it will familiarize them with the physical set-up and running of the equipment before performing the procedure in the actual laboratory. It is undeniable that hands-on experience in the laboratory is inherently important to the students enhancing their engineering skills.

(8)

(9)

(10) The symmetrical components of phase-a can be calculated by using (11). Other phase voltages have been determined via the voltage of phase-a. The positive reactance must be calculated from (12) for the time variations of signals.

(11) th African Conference on Software Engineering and Applied Computing(ACSEAC) 24



'( #

!"#

'( $

% & )" !$

!"$

"

,

* & )"

+

!"

(12)

!"

Where; Xd‖, Xd‘ and Xd are direct-axis sub transient, transient and synchronous reactance, Td‖ and Td‘ are direct-axis sub transient time constants, Ea and E are complex and RMS value of phase-a voltage of the synchronous machine terminal before the fault occurred. Tables 1 & 2 may be used for calculating and illustrating as depicted in fig. 8 and 9, the fault current and voltage. The signals must be illustrated by taking the real parts of current equations into consideration. After finding the symmetrical components of a phase current, the value of current and voltage can be calculated. TABLE 1: SYMMETRICAL

COMPONENTS CIRCUIT CONSTANTS

Fault condition

Circuit constant L(t) L1(t)

R Ra

3LS 2LS

2*Ra

L1(t)+L2

1LS

2*Ra+R0

L1(t)+L2+L0

2LG

Note: /

-

-

0 1 2

, 3

-

.

4. , 3

4. ,

.

.

5 6 6 &7

89:;

FAULT CURRENTS

FIGURE 2A: USER

INPUTS AND TYPE OF FAULTS

The internal connections of the generator and the motor can be chosen by the students, (by clicking on the indicated radio button). This allows the students to play around with the star or delta connections, the earthed or not earthed scenario and the bolted or not bolted position which are the conditions that affect the output results. This is depicted in as shown in Fig. 2B.

Fault currents

Fault condition

Ia1

3LS 2LS 1LS

.

2LG

V.

A. Functionality of the Virtual Laboratory The particularity of this interactive experiment is the combination of two cases study on the balanced and unbalanced fault calculations on the transmission line. The first case study takes in consideration for the calculations of the faults, the connections of components such as the generator, the transformers, the motor and line. The second case study only calculates the faults on the transmission line without taking these parameters into account. After the MATLAB program is opened and the students have clicked on the file icon, the front panel appears which consists of the user‘s inputs such as pre-fault voltage, base Mva, base voltage, the type of faults and the internal connection of the components. These values can be increased or decreased via a corresponding slider. The front panel of this is depicted in Fig. 2A. On this panel a student can set the inputs and choose the type of fault.

. .

Where Ta is armature time constant, L(0) is initial inductance at t=0, Ra and R0 are armature resistance and zero-phasesequence resistances, L1(t), L2 and L0 are positive, negative and zero-phase-sequence inductances, respectively. The fault currents signals formulae are introduced in Table 2. TABLE 2: SYMMETRICAL-COMPONENTS

symmetrical components which were introduced by Fortescue in [11].

.

FUNTIONALITY

AND

. .

.

.

VIRTUAL LABORATORY DESIGN

This session will explain the functionality of the button, inputs parameters and mainly the outputs results after the inputs have been set and the student has activated on the prefault button. The design of the Vlab interface is displayed in Fig. 2 and all these faults have been calculated with the

FIGURE

2B: CONNECTION.

MOTOR

AND

GENERATOR

PARAMETERS

AND

INTERNAL

The transformers and the line impedances can also be set as depicted Fig. 2C; all these features allow the students to conduct various analyses which may be difficult and risky in a traditional laboratory as illustrated in Fig. 2C. Another point of this experiment is that the faults can be calculated at different bus levels.




VI.

FIGURE

2C: CONNECTION.

TRANSFORMER

AND

LINE

PARAMETERS

AND

ENVIRONMENT EXPERIMENTS

A. The main experiment named Practical 1 The interface design is important in order to give the impression that the users are actually on the interactive platform. Thus, the user interface is designed in such a way that it is as interactive as possible throughout the experiment. Two interfaces were designed, one for each of the fault calculations on the transmission line. The first experiment is where the internal connections of the different components involved in the systems are considered and the different fault currents and voltages are calculated at the different bus levels. The interface offers extra functionality such as save, print, insert, zoom in and out, open an existing file button, and particularly the help button, which offers some instruction and basic information on Vlab and transmission lines. All these features ensure that the Vlab becomes enjoyable and attractive for the users.

INTERNAL

During the execution time of the program, the input values are acquired as strings of characters. Thereafter, the input strings are converted into a numeric value and which can be displayed in the appropriate edit test box as illustrated in Fig. 2D.

FIGURE 2D: OUTPUTS

THE LABORATORY

BOXES

B. Structure of the Virtual Laboratory The structure of the developed interface is shown in Fig. 3 which is the flowchart of the interactive environment.

START

Experiment Practical 2

General Parameters of Practical 1

*Prefault

*Base Mva

*Base Voltage Press on ―Go to the Next Practical Button‖

Set the individual Parameters of:

Generator

Transformer 1

Line

Transformer 2

Enter Parameters ―Vb, Sb, Z0, Z1, Z2 and Zf‖

Motor

Different Calculation of Currents and Voltages

Press on ―Calculate‖ Button for the Outputs

Courants at the Faulted point

Voltages at the Faulted point

Voltages at the Calculated point

Yes

Different type of displays

Do you want to continue? Non Press on ―EXIT‖ push button

FIGURE 3: FLOWCHART

OF THE DEVELOPED

VIRTUAL LABORATORY END




Fig. 4 shows the interface of a first fault calculation on the transmission line experiment. This experiment was prepared and demonstrated to students to illustrate what the effect on the fault currents and voltages (at the different states of the components in the power systems) are as well as the faults at the different bus levels.

The results of fault calculation for 2LG with different setting of components with the fault at bus 3 are given in Fig. 6.

The students are required to supply the pre-fault voltage, the base apparent power, the base voltage, set all the components, the line parameters and the bus level where the faults occurs. For every setting, the experiment was operated by pressing the ―Calculate‖ push button. Results are obtained in a separate table.

FIGURE 6: 2LG VIRTUAL

EXPERIMENT FAULT CALCULATIONS.

The interface for the second practical experiment can be accessed by the users by clicking on the specific button shown below in Fig. 7. After the users have pressed this button a new experiment will launch and the goal of this practical is to let the students visually experience the varying signals, the magnitude of the fault currents, the voltages, the phase angle fault in per unit, SI unit as well and the equivalent circuit. FIGURE 4: 1LG VIRTUAL


The results of fault calculation for 2LS with different setting of components, with the fault at bus level 2 are depicted in Fig. 5.

FIGURE 7: THE SECOND

EXPERIMENT ACCESS BUTTON

B. Case Study and testing of the Program The given input values are shown in table 3. These values are the base power Sb, base voltage Vb, positive, negative, zero and bottle impedance, Z1, Z2, Z0 and Zf respectively. TABLE 3: THE VALUES

OF THE EXAMPLE USED IN THE PROGRAM .

Inputs

FIGURE 5: 2LS VIRTUAL

Abbreviation

Value

Positive sequence impedance (pu)

Z1

0.5

Negative sequence impedance (pu)

Z2

0.5

Zero sequence impedance (pu)

Z0

0.05

Bottle fault impedance (pu)

Zf

0

Base power (MVA)

Sb

11

Base voltage (kV)

Vb

60





The focus here will be more on the 1LG and 2LS faults; the two different types of faults which are single line to ground and line-to-line fault will be displayed on the coming figures. Fig. 8 represents the entire results 1LG fault, with all the outputs.

and experiments presented have been tested with the input values according to various examples in the textbooks and the obtained results matched the results of the examples. The Vlab offers more individualized and independent learning and provide simulation of complex scenario that is less likely to be demonstrated in a traditional laboratory. Without taking risks, students can manipulate internal connection of the components (generator, transformers and motor) and visualize the results. This interface can be used as an educational tool for power systems. Further work will be directed towards a graphical interface with animation of real time faults on the transmission line which allows the study of the conductors during the faults conditions. ACKNOWLEDGMENT The authors would like to acknowledge the invaluable contribution of Dr. Trudy Sutherland, my friend Mr. Gilles Djami for his assistance in the program writing. A particular thanks is due to the Department of Power Engineering at Vaal University of Technology for the financial support.

REFERENCES FIGURE 8: 1SG FAULT

REPRESENTATION

Fig. 9 represents the entire results spectrum for a 2LS fault, with all the outputs

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9] [10] [11] FIGURE 9: 2LS FAULT

REPRESENTATION

[12]

VII.

SUMMARY

AND CONCLUSION

The description of the Vlab interactive environment, on the fault calculation of the transmission lines has been described

[13]

P. Bisták, ―Virtual and remote laboratory based on MATLAB, JAVA and EJS, In Proceedings of the 17th International Conference on Process Control 2009, Štrbské Pleso, Slovakia, pp. 506-511, 9-12 June 2009. K. Sava and A. Zafer, ―A MATLAB/GUI Fault simulation tool for power system education‖, Mathematical and Computational Applications, Vol. 14, No. 3 pp. 207-217, 2009. J.S. Djeumen, N. Dan-Valentin and J. Le Roux. ―Interactive experiment in the virtual laboratory short circuit fault with symmetrical component‖ presented at the African Conference on Software Engineering & Applied Computing, - Cape Town, South Africa September 24-26, 2011. A. Sauhats and M. Danilova, ―Fault location algorithms for super high voltage power transmission lines‖, In proceedings of the IEEE PowerTech, Bologna, Italy, 2003. S. Shaaban and H. Takasshi ―Transmission line faults classification using wavelet transform‖, In Proceedings of the 14th International Middle East Power Systems Conference (MEPCON‘10), Cairo University, Egypt, December 19-21, 2010. P. Chiradeja and A. Ngaopitakkul, ―Identification of fault types for single circuit transmission line using discrete wavelet transform and artificial neural networks‖, In Proceedings of the International MultiConference of Engineers and Computer Scientists (IMECS 2009), Vol. 2, Hong Kong, March 18-20, 2009. A. Hajjar, M. Mansour and H. Tallat, ―Wavelets for six-phase transmission lines relaying: fault classification and phase selection‖, IEEE MELECON 2002, Cairo, Egypt, pp. 235-239, 7-9 May, 2002. A. M. Stankovi and A. Timur ―Analysis of asymmetrical faults in power systems using dynamic phasors‖ IEEE Transactions on Power Systems, Vol. 15, No. 3, pp. 1062-1068, August 2000. T. K. Nagsarkar and M.S Sukhija, Power system Analysis, Oxford Higher Education, University press, , pp. 381-418, 2007 J.C. Das ―Power System Analysis Short-Circuit Load Flow and Harmonics‖, Marcel Dekker, Inc. New York, 2202. C. L. Fostescue, ―Method of symmetrical c0-ordinates applied to the solution of polyphase networks‖, AIEE Transactions, Vol. 37, No. 2, July 1918. H.P. Lee, Comparison between traditional and web-based interactive manuals for laboratory-based subjects (pp. 307-314), International Journal of Mechanical Engineering Educational Vol. (30(4). T. Kai, N. Takeuchi, T. Funabashi and H. Sasaki, ―A Simplified Fault Currents Analysis Method considering Transient of Synchronous




[14]

[15]

[16]

[17]

[18]

[19]

Machine‖, IEEE Transactions on Energy Conversion, 12(3), 225-231, 1997. Y. Li, LeBeof, E.J., Basu, P.K and L.H Turnver, ―Development of a Web-Based Mass Trnsfer Process Laboratory: System Development and Implemetation‖, Computer Applications in Engineering Education Vol. 11, No. 1, pp. 25-39, 2003. G.G. Karady, G.T., Heydt, K.J., Olejniczak, A., Mantooth, S. Iwamoto, and M.L., Crow, Role of Laboratory Education in Power Engineering: Is the Virtual Laboratory Feasible? Power Engineering society summer Meeting, Vol.3, No.1, pp. 1471-1477. July 2000. A.. Bagnasco, P. Buschiazzo, D. Ponta, & M., Scapolla, A learning resources centre for simulation and remote experimentation in electronics, In Proceeding of the Petra, Athens, Greece, pp. 1-7. 2008. K.W.E., Cheng, C.L., Chan, N.C. Cheung, & Sutanto, D., 2009. Virtual Laboratory Development for Teaching Power Electronics, Hong Kong Polytechnic University, Hong Kong, China, pp. 461-466. T.R. Wyatt, P. Arduino, & E.J. Macari,. Assessment of a virtual Laboratory for geotechnical engineering education, Computer Education, pp. 27-35, Vol. 10, No.2, 2000. K.D. Forbus, S.E. Kuehne, P.B. Whalley, J.O. Everett, L. Ureel, M. Brokowski, and J. Baher,. CyclePad: An articulate virtual laboratory for engineering thermodynamics, Artificial Intelligence, pp. 297-347, Vol. 114, No.51, 1999.

[20]

[21]

[22]

[23]

[24]

N. Omar, R. Zulkifli, and R. Hassan, Development of a Virtual Laboratory for Radiation Heat Transfer, European Journal of Scientific Research, Seattle, USA, pp. 562-571, Vol.2, No.4, 16-20 July, 2009. U. Nazmul, Virtual laboratory for undergraduate microelectronics courses, In Proceeding of the 2nd International conference on Electrical and Computer Engineering ICECE 2002, Dhaka, Bangladesh, pp. 102-105. 26-28 December, 2002. O.J. Roesch, H. Roth, and H. Yahoui, Virtual Labs in the Engineering Education: a Standardization Approach for Tele-Control., Journal sur l‘enseignement des sciences et technologies de l‘information et des systems, Vol.4, No.4, Lyon, France pp 1-7. 2005. D. Koretsky, D. Amatore, C. Barnes, and S. Kimura, ―Enhancement of Student Learning in Experimental Design Using a Virtual Laboratory,‖ IEEE Transactions on Education, vol. 51, pp. 76-85, February 2008. K. Wong, T. Wolf, S. Gorinsky, & J. Turner, Teaching Experiences with a Virtual Network Laboratory, In Proceeding of the National Science Foundation, Covington, Kentucky, USA, pp. 481-485. March 7-10, 2007.




Measuring User Requirements Dependency: the Organizational Perspective Mesfin Kifle IT PhD Program, Addis Ababa University Addis Ababa, Ethiopia [email protected]

Abstract—In organizational environment, user requirements are key system aspects that need to be realized in the system-to-be context. Aiming to support transformational development, organizations insist to acquire software business applications that satisfy business goals and processes strategically. A software product quality for an organization depends on how well it fits to the organizational goals and business processes. In system problem decomposition, requirements dependency is critically important to measure cohesion and coupling properties of business applications. It can also be used to set acceptance criteria. The more software engineering techniques are getting far from organizational settings the gap between the business requirements and application increases. Such gaps can be minimized by employing context sensitive methods. In this paper, a heuristic method is presented to measure user requirements intentional and flow dependency by considering goal-scenario modeling. The method is designed by aligning business goals, processes, and scenario concepts. Keywords- Organizational Perspective; User Requirements; Requirements Dependency; Intentional Dependency; Flow Dependency; Scenario.

I.

INTRODUCTION

Aiming to support transformational development, organizations insist to acquire software business applications that satisfy business goals and processes. In organizational environment, user requirement is a key system aspect that has to be realized in the system-to-be context. User requirements describe what users will be able to do with the product, such as goals or tasks that users must be able to perform. Use cases, scenarios, user stories, and event-response tables are some of the techniques that are used to represent user requirements [1]. Business process reengineering (BPR) activities are aimed to build an improved system-to-be business environment. The BPR or other similar organizational documents maintain business goals explicitly by applying SMART criteria, where each goal has to be specified in a way that is Specific, Measurable, Achievable, Relevant, and Time bound [2]. And business processes are defined to achieve these goals. Therefore, it is natural that system requirements should be

able to properly reflect the intended organizational goals and business processes. As a result, user requirements need to be defined properly and systematical in order to achieve business goals. For this purpose, requirements engineering helps to conceptualize system and domain concepts, so as, potential users of the system can provide useful and realistic view points about the system-to-be. User requirements usually originate from stakeholders and posses intrinsic dependencies [3]. This means that requirements in a system exhibit a range of dependency types. Throughout system development activities, from requirements analysis to maintenance, requirements dependency can either positively or negatively affects the way development issues handle and the product quality at large. In this paper, a heuristic method is presented to measure user requirements intentional and flow dependency by considering goal-scenario modeling. The method considers organizational perspective in describing business processes using scenarios and intentional property of business processes. Explicit modelling of requirements dependency enable practitioners and decision makers to have better understanding about the system problem decomposition. In this regard, intentional and flow based user requirements dependencies shall be considered. Intentional dependency assesses contribution of requirements for business goal satisfaction, whereas, the flow based evaluates requirements order as users carry out operational tasks. The remaining part of the paper is organized as follows. Section 2 presents the running case study. Section 3 details the steps of goal-scenario modeling. Section 4 describes the proposed requirements dependency types. Section 5 describes the related work. Finally, section 6 concludes the paper.




II.

TABLE 3: BUSINESS GOALS

CASE STUDY: STUDENT INFORMATION SYSTEM

In this section, I introduce the running example of the paper, namely the development of a student information system at University A. The student information system shall allow a student to register according to his/her program level and fee management modality. A student can either be a regular or extension (or continuing program) student at undergraduate or postgraduate level. After a student settles tuition fee, the student receives a copy of a registration slip, which is verified and stamped. Process scenarios for student registration and diploma/transcript preparation business processes are presented in table 1 and table 2 respectively. (for simplification purpose the process scenario cases, where exception conditions happen, are not included. and also other constraints (time, space) are not addressed.). TABLE 1: REGISTER STUDENT PROCESS SCENARIO Scenario name

Flow Description

Register Student

Req.

Check eligibility for registration

R1

Check course validity

R2

Settle tuition fee ü If a student is not fee paying (or a regular student), s/he fills service agreement forms. ü Otherwise if he is fee paying (or extension), s/he has to settle in cash. ü Otherwise, sponsorship cases might entertain for postgraduate student

R3

R4 R5

Approve registration

R6

Renew Identification Card ü If a student had already id, renewal shall be effective otherwise identification cards shall be produced

R7

Goal Provide high quality student oriented services Provide student oriented and efficient registration Students will complete registration and receive/renew id within 10 minutes All graduating students will receive their unofficial transcripts and temporary diploma on the day of their graduation. Every student should get orientation during registration

Type

Label

Strategic

Gs-1

Strategic

Gs-2

Operational

Go-1

Operational

Go-2

Operational

Go-3

In the subsequent sections, the case study shall be explored to illustrate how to measure user requirements dependency from organizational perspective. III.

GOAL REFINEMENT AND BUSINESS PROCESSES

In this section, the preliminary concepts, goals and processes, are introduced. Their interrelationship is also modelled and presented in a hierarchal structure. As presented in [4], requires interdependency type is deemed to maintain goals refinement hierarchy. A. Goal Refinements The first step in defining a business process is to define the goals1 [5]. A business goal is the state of an enterprise that an action or a given set of actions is intended to achieve. Goals might be classified into several ways. In [6], following semantic classification, goals are of three types: achievement, maintenance and avoidance. A pragmatic classification divides goals into prescriptive and descriptive types [7] or strategic and operational goals [5]. These goals typically come from strategic management documents, BPR documents or organization's written procedures. In this study the pragmatic classification (strategic and operational) is taken since it is a common practice from organizational perspective.

TABLE 2: DIPLOMA/TRANSCRIPT PREPARATION PROCESS SCENARIO Scenario name

Flow Description

Diploma/transcript preparation

Req.

Check eligibility for graduation

R8

Prepare ü ü

R9 Transcript diploma

R10

Verify and authenticate

R11

Dispatch ü Transcript ü Diploma

R12 R13

Goals are useful for organizing and adjusting software requirements. They are often not given or stated explicitly to the detail. Thus it is important to support goal constructions through techniques like goal decomposition and scenario analysis. In requirements definition, high level strategic goals are elicited and refined to address existing system problems and then requirements elaborate to meet these goals [8], [9]. Goal refinement is a kind of relationship between goals. It integrates goals at different levels of abstraction and shall describe them in hierarchical structures [3], [7], [10]. Business goal models contain a hierarchy of an organization‘s business goals according to which the processes in the organization are

In relation to the business processes discussed above, four business goals are identified as shown in table 3. 1

In the context of this paper goals and objectives refer the same thing.




designed [5]. The higher level goals are refined into more specific or sub goals through decomposition.

C. Scenario Attributes

The goal refinement tree provides traceability links from high-level strategic to low-level operational goals. An operational goal is a short term contribution to a strategic goal. In a time where goals are not explicitly defined to sufficient level, requirement analysts should explore more by using the why-what-how method [5],[7],[9], [11]. In this method, a goal at each refinement level describes what needs to be done. At the same time this goal can also be considered as an end (why) for a refined goal, as well as a means to achieve (how) for a goal at a higher level. The refinement process continues until an operational goal is achieved through one or set of business processes in an organization.

attributes are identified. A concise explanation of the process scenario attributes is given in table 4. And then, a brief description of each attribute follows.

Now by using the why-what-how refinement method, the four business goals (from table 3) of the case study can be constructed in a refinement tree as shown in figure 1, since: Gs-2 is a specialization (or how) of Gs-1, Gs-1 is achieved through (or why of) Gs-2 and Go-2, Gs-2 is achieved through (or why of) Go-1 and Go-3. Gs-1

Gs-2

Go-3

Go-2

Go-1

Figure 1. Goal refinement hierarchy

B. Business Processes and Scenarios A business process can be seen as a sequence of activities that satisfy the goals by decreasing the distance between the current situation and the stakeholder‘s desired situation. A business process exists for a reason. It strives to achieve a set of business goals [5]. They usually describe as a sequence or set of related activities. Organizations should be able to define processes inline with the goals. The value of a software application is measured based on the extent it satisfies the business goals it had been intended to realize. In requirements engineering, a business process can be expressed with one or set of scenarios. Scenarios are used in eliciting and analysing requirements from stakeholder representatives. Since representatives exist at different levels of the business process, the analyst gets scenarios in different forms. There are at least two types: process scenario and explanatory scenarios [7]. For the sake of this study, a process scenario type is taken since it addresses every task of a process keeping the flow order. In process scenario, the analyst and the user walkthrough the steps of a business process in detail from the beginning to the end.

Scenarios can serve as a unit that encapsulates a set of related requirements [3]. In this study, a number of process scenario

TABLE 4: ATTRIBUTES OF A PROCESS SCENARIO Attribute Name Description Atomicity

Initial state End state

Meaning Meaningful character-string Presentation of the set of actions or requirements in detail The sequence of actions that results state change and every action in the scenario should apply for an object or entity State of an object or entity before the scenario executes State of an object or entity at completion of scenario execution

Name is any meaningful character-string in relation to the corresponding business process name. Description is a textual description of set of actions or requirements that are ordered according to their flow of execution. Atomicity refers to the flow order of tasks in a scenario. A process scenario is atomic only if every action in the scenario applies for an object or entity. When optional or alternative flow situations detect (like if ... something…), then the user scenario should be decomposed into other atomic types. For example, Register-Student scenario in table 1 is not atomic since R3, R4 and R5 are under alternatives or special conditions (likewise R9, R10, R12 and R13 in table 2).Therefore, register-student scenario for student registration business process (P1) and diploma/transcript preparation scenario for business process (P2) shall refine into set of atomic scenarios and construct a hierarchy as shown in figure 2 where: § § §

§

§ § §

P1 refers student registration business process PS11 refers atomic process scenario for register regular student scenario (R1, R2, R3, R6, R7) PS12 refers atomic process scenario for register fee paying (or extension) student scenario (R1, R2, R4, R6, R7) PS13 refers atomic process scenario for register sponsored (or postgraduate) student scenario (R1, R2, R5, R6, R7) P2 refers diploma/transcript preparation business process PS21 refers atomic process scenario for prepare diploma scenario (R8, R10, R11, R13) PS22 refers atomic process scenario for prepare transcript scenario (R8, R9, R11, R12) P2

P1

PS11

PS12


PS13

PS21


PS22


Figure 3. Goal-Process-Scenario Hierarchy (GPSH) Figure 2. Process scenario hierarchy

Initial state describes a state of an entity before the set of actions of a scenario act upon. For example in the register regular student scenario a student can be registered only if s/he is admitted and not registered. Therefore the student should be on unregistered state initially. End state describes a state of an entity after the set of actions of a scenario act upon. For example in the register regular student scenario a student changes its state from unregistered to registered. Based on the concepts discussed above the following definitions or axioms are defined. Definition 1: Every atomic scenario includes a set of requirements (r1, r2, … rn). A binary relation scenario requires (SRq) returns a value true if a requirement r belongs to the set and a value false if not: i.e. if r belongs to atomic scenario s then SRq(s, r) = true Definition 2: Every business process requires a set of scenarios (s1, s2, … sn) to be operational. A binary relation process requires (PRq) returns a value true if a scenario s belongs to the set and a value false if not: i.e. if s belongs to a process p then PRq (p, s) = true D. Linking Goals and Scenarios Linking the process-scenario hierarchy with goal refinement hierarchy is guided by the properties of requires dependency type [4] or operationalization of goals [7]. This would help us to maintain relations in hierarchical structure. The operational goal Go-1 is operational through (or requires) the business process P1. Therefore, linking P1 with Go-1 gives a combined Goal-Process-Scenario hierarchy (GPSH) as shown in figure 3. Likewise the process P2 and a new process P3 are linked with Go-2 and Go-3 respectively. In general, an operational goal can be operational with one or more business processes. Gs-1

Gs-2

Definition 3: Every operational goal (let Go) includes a set of processes (p1, p2, … pn). A binary relation isSatisfiedBy returns a value true if a process p belongs to the set and a value false if not: i.e if p belongs to an operational goal Go then isSatisfiedBy(Go, p) = true Definition 4: Every strategic goal (let Gs) includes a set of operational and other strategic goals (g1, g2, … gn) which contribute for Gs satisfaction. In each set, there must be at least one operational goal. A binary relation isRefinedTo returns a value true if a goal g belongs to the set of Gs and a value false if not: i.e. if g belongs to a strategic goal Gs then isRefinedTo (Gs, g) = true IV.

DEPENDENCY TYPES

The hierarchical structure of the nodes in GPSH graph gives an opportunity to assess requirements dependency by evaluating graph paths. Starting either from a strategic goal or operational goal, we can observe that which set of requirements contribute together to the purpose of each scenario and goals at large. And which are not interrelated as such. In this section, the proposed measurement method is presented for intentional and flow dependency. A. Flow Dependency Flow Dependency (FD) of two user requirements measures their correlation in the flow of business processes. Considering the process scenario refinement, requirements might appear in two or more scenarios even across business processes. Taking two different requirements r1in atomic scenario s1 and r2 in atomic scenario s2, their flow dependency depends on the return values of SRq and PRq binary relations. Based on the result three FD types are suggested as follows. Strong: if s1 and s2 are the same, i.e. r1 and r2 are strongly dependent. Loose: if s1 and s2 are different: i.e. if SRq (s1, r1) and SRq (s2, r2) returns true value, and if there is a process p where PRq (p, s1) and PRq (p, s2) return true, then r1 and r2 have FD type loose (or loosely dependent).

Go-2

Go-3 Go-1

PS31

Weak: if FD type of r1 and r2 is not strong or loose. In other words, they do not belong to the same process.

P2

P3

P1

PS11

PS12

PS13

PS21

PS22

For example, looking the case study, R3 and R2 have Strong FD type R3 and R4 have Loose FD type R3 and R8 have Weak FD type




concerns much about the unexpected conflicts or interference among requirements or features. B. Intentional Dependency Intentional Dependency (ID) of two user requirements measures their correlation to satisfy business goals. Taking two different requirements r1, and r2, their ID depends on their FD and respective strategic goal node position in the GPSH graph. Based on this analysis three ID types are proposed as follows. Operationally_Strong: if FD type of r1 and r2 is Strong or Loose.

Strategically_Weak: if FD type of r1 and r2 is Weak, and the following conditions are satisfied for two processes p1 and p2 where PRq(p1, s1) and PRq(p2, s2) returns true. o if there are two different operational goals Go1 and Go2 and a strategic goal Gs, where § isSatisfiedBy(Go1, p1) and isSatisfiedBy(Go2, p2) returns true, and § isRefinedTo(Gs,Go1) and isRefinedTo(Gs,Go2) returns true. Strategically_Strong: if ID type of r1 and r2 is Strategically_Weak, and if there is no strategic goal g where isRefinedTo(Gs, g) is true. For example, looking the case study, (assume R14 is in process P3) R3 and R2 are Operationally_Strong R3 and R8 are Strategically_Weak R3 and R14 are Strategically_Strong Since the proposed method is defined from organizational perspective, domain experts can use it for different purposes: setting acceptance criteria and to check out completeness of requirements in business applications. V.

RELATED WORK

The area of requirements dependencies is fairly discussed in few literatures [4]. But some researchers have proposed various types of dependencies among requirements from different views. In [12], around 18 types of dependencies are defined but later they are remodelled into fundamental interdependency types by classifying them as structural (with types requires, explains, similar_to, conflicts_with and influences) and cost/value [4]. Such classifications are presented from developers‘ perspective. Organizations can not utilize them directly for their perspective. This paper rather views requirements dependency from organizational perspectives by evaluating their correlation with business goals and processes. Requirements interaction dependency is proposed in [3] on the basis of features that are necessary for a software to achieve certain customer-desired goals. On the other hand, [13]

In [14], requirements dependencies are not discussed explicitly rather through requirements traceability links. It pointed out that decomposing critical requirements from high level to more detail is important to understand requirements mapping. The work in [7] gives a strategy to goal identification from process scenarios as a bottom up approach for business process reengineering purpose. The proposed method has presented analysis of requirements using goals and scenarios. Furthermore, linking business goals (strategic and operational goals) and business processes is discussed in [5]. In this paper, the approaches which are presented in [5] and [7] are used to construct the GPSH graph as presented in section 3. The i*/Tropos, discussed in [15], is an agent-oriented framework that can be used for requirements engineering. The notion actor is a central concept in i*. It has been used to represent agents, roles, and positions. Actor based dependency is discussed. Dependencies between actors are identified as intentional. Four dependency subjects are identified: goal, softgoal, task, and resource. It does not use scenarios. But, in this paper, by extending the basic concepts from organizational perspective, the graph theory is applied focusing on requirements and their relationship with goals and processes. VI.

CONCLUSION

The issue of requirements dependency concerns both stakeholders and developers from their own perspective. An organization, as a stakeholder, wishes to view requirements as a description of organizational aspects like business goals, processes, tasks, etc. Organizing requirements in a way that reflect the strategic and operational goals is critically important to manage organizational systems. In this paper, a heuristic method is proposed to identify user requirements dependency in two ways: intentional and flow based. Goal-scenario modelling is explored to be used in the proposed method. On the bases of properties of goals, processes and process scenarios, a hierarchal structure is constructed to show requirements dependency. To apply the proposed method in large projects, there are issues that will be explored further like efficiency of the method and determining when and how the method can be used optimally. These will be worked out in the future. ACKNOWLEDGMENT The author would like to thank Christiane Floyd and Tesfaye Biru for their support as doctoral research supervisors. This paper is a progress report of this research. REFERENCES [1] [2] [3]

Karl E. Weiger, Software Requirements, second edition, Microsoft press, 2003. M. Armstrong. A Handbook of Human Resource Management Practice, 10th edition, Kogan Page, London, 2006. W. Zhang, H. Zhao, and H. Mei, ―A Feature-Oriented Approach to Modeling Requirements Dependencies,‖ Proceedings of the 13th IEEE




[4]

[5]

[6]

[7]

[8]

International Requirements Engineering Conference, 2005, pages 273– 282. A.G. Dahlstedt, A. Persson, ―Requirements Interdependencies – Modeling the State of Research into a Research Agenda,‖ Proceedings of ninth International Workshop on Requirements Engineering: Foundation for Software Quality, Klagenfurt/Velden, Austria, June 2003, pp. 55-64. I. Markovic and M. Kowalkiewicz, "Linking Business Goals to Process Models in Semantic Business Process Modeling," 12th International IEEE Enterprise Distributed Object Computing Conference, 2008, pp.332-338. A. Dardenne, A.van Lamsweerde, and S. Fickas, "Goal-Directed Requirements Acquisition", Science of Computer Programming, April 1993,Vol. 20(1-2), pp. 3-50. A.I. Antón, W.M. McCracken and C. Potts, ―Goal Decomposition and Scenario Analysis in Business Process Reengineering,‖ Proceedings of 6th International Conference on Advanced Information System Engineering, June 1994, pp. 94-104. A.I. Anton, "Goal-based requirements analysis," Proceedings of the Second International Conference on Requirements Engineering, 1996, vol., no., pp.136-144, 15-18.

[9]

[10]

[11]

[12] [13]

[14]

[15]

C. Rolland, and C. Salinesi, ―Supporting Requirements Elicitation through Goal/Scenario Coupling,‖ In Conceptual Modeling: Foundations and Applications, LNCS 5600, 2009, pp. 398 – 416. A. van Lamsweerde , ―Goal-Oriented Requirements Engineering: A Guided Tour‖, Proceedings of 5th International. Symposium in Requirements Engineering, Aug 2001. V. Kavakli and P. Loucopoulos, ―Goal-driven business process analysis application in electricity deregulation,‖ Information Systems, 1999, Vol. 24, pp. 187–207. K. Pohl, ―Process-Centered Requirements Engineering,‖ John Wiley & Sons Inc, 1996. W.N. Robinson, S.D. Pawlowski, and V. Volkov, ―Requirements Interaction Management‖, ACM Computing Surveys, Jun 2003, Vol. 35, No. 2, pp. 132-190. B. Ramesh, and M. Jarke, ―Toward Reference Models for Requirements Traceability,‖ IEEE Transactions on Software Engineering, 2001, Vol.27, no1., p. 58-93. A. Lapouchnian, ―Goal-Oriented Requirements Engineering: An Overview of the Current Research‖, Requirements Engineering, 2007




Model-driven Refactoring Approaches: A Comparison Criteria Mohammed Misbhauddin Information and

Mohammad Alshayeb

Computer Science Department King Fahd University of Petroleum and Minerals Dhahran 31261, Saudi Arabia [email protected]

Information and Computer Science Department King Fahd University of Petroleum and Minerals Dhahran 31261, Saudi Arabia [email protected]

Abstract— Model-driven engineering, an emerging trend in software engineering, has enabled the application of refactoring to UML models. Due to its growing popularity in the domain of refactoring, a number of approaches to specify models and transformation rules have been proposed in literature. A comparison framework is required by researchers and practitioners to guide them in selecting an appropriate approach suitable to their specific needs and trade-offs. In this paper, we provide a set of suitable criteria to evaluate and compare the various model refactoring approaches that can aid practitioners and researchers in the selection process. The paper also compares the refactoring approaches against the framework. Keywords- Model Refactoring; UML; Comparision Criteria;

I.

INTRODUCTION

Model-driven software engineering (MDSE) is a development paradigm that promotes the use of models at different levels of abstraction during the development lifecycle. Prior to the formulation of MDSE, models were considered informal drafts of the software under development or used for ―mere‖ documentation [1]. One methodology from MDSE that gained immense popularity is the Model-driven Architecture (MDA) [2]. MDA tends to be more restrictive and focuses on UML-based modeling languages. The Unified Modeling Language (UML) [3], although not primarily designed for MDA, became a standard formalism for a wide range of application domains due to its wide use and popularity. UML is used to describe various types of models in MDA. It contains diagrams and views that can represent various perspectives of a system. Each diagram in the UML suite conforms to the UML metamodel that characterizes a set of valid models based on a defined set of syntax and semantics. Model Transformation is considered one of the integral activities that ensure that models can be used for software evolution, refinement and realization in code. Model transformation is defined as a process in which a source model is transformed into another model (target model). Model transformation can be either vertical or horizontal [4]. When the source model and the target model belong to different level of abstraction, the transformation is known as vertical. A horizontal transformation occurs when the source and target

model belong to the same level of abstraction. Horizontal transformation in which the source and target model not only belong to the same level of abstraction but also conform to the same metamodel (such as UML) is referred to as Software Refactoring. Software Refactoring was initially defined by Opdyke [5] in the discipline of Object Oriented Programming as ―a change made to the internal structure of the software while preserving its external behavior at the same level of abstraction”. Initial efforts of refactoring application focused mainly at source code-level also known as Program Refactoring. With the increasing popularity of MDA, the concept of refactoring was extended to a higher abstraction level. This initiated the concept of Model-driven Refactoring [6]. Refactoring at model-level is more multifaceted and challenging than at code-level. The process of model-driven refactoring includes a number of activities such as behavior specification and preservation, verification, consistency etc. UML is a graphical notation designed to specify, visualize and document artifacts of a software system. Specification of UML models to an appropriate formalism equipped for model checking and verification plays a significant part in the development of a model-refactoring approach. Effectiveness and application of model refactoring largely depends on the Model Transformation System (MTS) used [7]. An MTS consists of a model specification and transformation language that specifies the syntax, semantics and transformation rules that dictate the refactoring process. Quite a few approaches to model-driven refactoring have been proposed in literature. The main objective of this paper is to help software researchers and practitioners in selecting an appropriate model refactoring approach based on their requirement. As a result of a comprehensive review of literature in the field of model-driven refactoring, we identified a set of criteria that can be used to evaluate and compare approaches proposed for refactoring at model-level. The rest of this paper is organized as follows: Section 2 provides background on model-driven refactoring that is the scope of this paper. Section 3 identifies and discusses the various approaches available for refactoring specification at model-level. Section 4 defines the comparison criteria that will




be used for assessing the refactoring approaches. Finally, we conclude and provide directions for future work in Section 5. II.

MODEL-DRIVEN SOFTWARE REFACTORING

Model-driven refactoring is a special kind of model transformation that allows us to improve the structure of the model while preserving its internal quality characteristics. Model-driven refactoring is a considerably new area of research which still needs to reach the level of maturity attained by source code refactoring. The refactoring process for models consists of a number of distinct activities (based on the refactoring process for source code refactoring [8]): 1) Model Specification. Select an appropriate language for specifying the model. Models can be specified by either a formal or non-formal language. A formal language apart from specifying a syntax and semantics also provides a proof system for validation. 2) Model Transformation Language. A transformation language allows composition of rules that dictate the transformation process. The specification language along with the transformation language forms a Transformation System. 3) Model Smells. Model smells are portions within the model that needs to be refactored. A number of detection strategies are available in literature for identifying model smells. They are also referred to as Refactoring Opportunities. 4) Model Behaviour. One important constraint posed by refactoring is the notion of behaviour preservation. Since models are non-executable entities, the concept of behaviour has to be defined and verified before and after the application of refactoring(s). 5) Model Refactoring. Select suitable refactoring(s) that can be applied at the identified location(s). Refactoring operations are chosen based on the smell identified. 6) Refactoring Quality. Evaluate the effect of refactoring on the quality of the software model. 7) Tool Support. Application of Refactoring is usually supported by a tool. A refactoring tool can either perform refactoring automatically without user intervention or requires user confirmation before application. 8) Consistency Management. Refactoring a model leaves other related models and source code inconsistent. In order to preserve consistency between the refactored model and other software models and source code, model consistency approaches need to be adopted. Introduction to the concept of model refactoring using UML models as candidates was first proposed by Sunyé et al. [6]. Since then, a few surveys covering state-of-the-art [9], taxonomy [10], open issues and challenges [11, 12, 13, 14, 15] related to model-driven refactoring have been published in literature. Although the comparison of refactoring approaches proposed by Mohamed et al. [10] is closer to our work, they only classify model refactoring literature based on the different techniques employed for refactoring activities. In this paper, we not only classify model refactoring approaches based on the transformation system used but also provide and compare these

approaches against a well-defined comparison framework. The objective of this paper is different from all the others as it proposes comparison criteria for model-driven refactoring. It is organized from the perspective of the researcher and practitioner so they can select an appropriate model refactoring approach based on their requirement. Grønmo et al. [16] proposed a single criteria comparison of three model transformation languages. In this paper, we provide a multiple criteria comparison framework for approaches related specifically to model refactoring. III.

MODEL REFACTORING APPROACHES

UML is a semi-formal language as its syntax and static semantics are precisely defined [3] but its dynamic semantics are not formally defined. The process of model-driven refactoring includes a number of activities such as behavior conservation, verification, synchronization etc. that requires a formal set of both static and dynamic semantics to ensure behavior-preserving transformation. Although many authors use the UML metamodel and models as-is for model refactoring, they annotate the model with formal behavioral constraints using OCL (Object Constraint Language) [17]. Apart from the specification language, transformation rules that dictate the transformation from source model to the target model are also required to be specified. Languages or formalisms used to describe these rules are known as Model Transformation Languages (MTL). A transformation rule is a depiction of how a collection of constructs in the source metamodel can be altered into one or more constructs in the target metamodel. A transformation rule consists of a LeftHand Side (LHS) component and a Right-Hand Side (RHS) component. The LHS accesses the source model and the RHS component access the target model. Both the LHS and RHS components are described using model fragments (or patterns) with zero or more model elements. The choice of MTL depends on the selected model specification language. Combination of both the specification and transformation language forms the refactoring approach. In this section, we describe popular model refactoring approaches used in practice. 1) Graph Based Approach: One of the most popular and widely used specification languages to represent UML models is graphs. The use of graphs to represent models is motivated by the fact that models are fundamentally graph-based in nature. A graph consists of a set of vertices (V) and a set of edges (E) such that each edge e in E has a source s(e) and a target t(e) in V. A graph is given as a tuple where s and t are two functions that assign each edge a source and a target node. Graph transformation languages are based on algebraic graph grammars. There exist two paradigms for graph transformation approaches. The conventional paradigm, also known as Algebraic Graph Transformation, defines transformation rules declaratively. Transformation rules in Algebraic Graph Transformation have a Left Hand Side (LHS) graph and a Right Hand Side Graph (RHS). On application of the rule, elements in the LHS are deleted and the elements in the RHS are added. A transformation rule also consists of an arbitrary number of negative application condition (NAC) [18]




graphs. If the rule matches any of its NAC, then the rule cannot be applied. The other paradigm is known as Triple Graph Grammar (TGG). The transformation rules in TGG are always bidirectional. The relationship between the source graph and the target graph is described by a correspondence graph. 2) Logic Based Approach: Another popular approach to represent UML models is logic-based representation. Logic is a formal system that allows definition of formulas representing propositions. Formulas can be derived by the use of welldefined rules and axioms also known as theorems. For instance, Boolean logic limits the truth-values of its propositions to two values: true and false. Popular logic based languages include Alloy [19, 20], Z notation [21], Object-Z [22] and Description Logic [23]. Primitive transformations in logic-based systems are formalized as algebraic laws that consist of templates with which the actual declarations match. Each law defines two templates of equivalent models on the left and the right side. Equivalence allows application of the law in both directions. 3) Direct Manipulation Approach: This approach allows direct manipulation of the metamodel without conversion to any other specification language. One of the main reasons for the popularity of this methodology is the availability of quite a few model-to-model transformation languages such as Query/View/Transformation (QVT) [24], Xpand [25] and the ATLAS Transformation Language (ATL) [26] to describe refactoring rules. The Object Constraint Language (OCL) is usually used with UML to define pre and post conditions in order to ensure behavior preservation. 4) Language Specific Approach: Another popular approach to model refactoring is using standard programming language scripts. Programming language specific approaches provide tool-support and mechanisms necessary for accessing and modifying UML models. Transformations are encoded as scripts and integrated within the tool. Porres [27] first proposed the System Modeling Workbench (SMW) toolkit based on Python programming language to implement UML model refactorings. Other scripting languages popularly used for model-driven refactoring include OCL-Script [28] and Embedded Constraint Language (ECL) [29]. 5) Text Based Approach: In this approach, UML models are encoded in a standard text based format and notation for model specification. Transformation is encoded in a tool independent script and performed by an independent trnasfromation engine. One of the most widely-used text based approach is XMI/XSLT. The XML Metadata Interchange format (XMI) [30] is a standard notation used by metamodels represented by the MOF-metamodel for specification and exchange. The Extensible Stylesheet Language for Transformation (XSLT) [31] is a dedicated language used to implement model transformations based on XMI.

IV.

COMPARISION FRAMEWORK

In order to compare the identified model refactoring approaches, we developed a framework comprising of ten comparison criteria. These comparison criteria have been cautiously selected to identify and present both the advantages and disadvantages of using these approaches. The comparison criteria and their descriptions are elaborated below. A comparison of the model refactoring approaches against the framework is shown in TABLE I. 1) Object Oriented (OO) Concept Support: Since the scope of model refactoring in this paper is limited to UML models, refactoring approaches should be able to specify core concepts related to object-oriented paradigm. These concepts include Abstraction (ABS), Polymorphism (POLY) and Inheritiance (INH). 2) Formality: A model refactoring approach can either be formal or informal. A transformation system is considered formal if it specifies at meta-level (i) a syntax, (ii) static semantics, and (iii) a proof system [32]. Apart from adding the power of expressiveness and preciseness to UML model refactoring, formal approaches allows the use of a number of applications to verify behavior and correctness such as model checkers, theorem provers etc. This criteria is evaluated on a dichotomous yes-no scale. 3) Ease of Use: Simplicity of use is an important factor when it comes to implementing complex refactoring operations. Refactoring specifications should be convinent to read and easily understood by the developers. The effort required to understand and implement a proposed refactoring should be minimal. For the sake of comparision, we classify approaches based on this criteria into three categories. An approach is Simple if the intent of refactoring is understood without requiring an in-depth knowledge of the specification language. An approach is Average if the specification is easy to read but requires some knowledge about the domain to completely understand the intent. An approach is Complex if comprehension of a refactoring operation requires expertise in the specification language domain. 4) Conciseness: Refactoring rules that transform the source model should be as concise as possible. Simple refactoring operations such as Rename Entity should be represented through a single rule. Refactoring approaches that provide a concise manner of transformation rules specification are more manageable than ones that use multiple rules to represent simple refactoring operations. Expansive approaches become more complex with the specfiication of composite refactoring operations. This criteria is evaluated on a dichotomous yes-no scale. 5) Artifact Coverage: A software model is built up from many different views, normally using a variety of different UML notations or diagrams. UML 2 defines 14 different diagrams as part of its most recent specification [3]. A view is a collection of diagrams that illustrate similar characteristics of the system. Typically UML models can be classified into three views: structural (ST), functional (FN) and behavioral (BH)




[33]. A model refactoring approach should be able to represent models belonging to each of these views. 6) Expressievness: As discussed in Section 2, the refactoring process for models consists of a number of distinct activities. Three important activities that should be expressed by any model refactoring approach include opportunity detection (OD), refactoring rule specification (RS) and behavior preservation (BP). 7) Granularity: Refactoring operations can be classfied into three categories based on their level of granularity: Primitive (P), Composite (C) and Fine-Grain (FG). Primitive refactoring is an atomic refactoring operation that cannot be split into more than one refactoring during application [5]. A sequence of primitve refactorings is known as composite refactoring. Composition of refactoring allows application of sequential refactoring operations on the model as a single unit [34]. Fine-grain refactoring allows transformation specification on any element of the model [35]. A fine-grain refactoring is more general than primitive refactoring and a sequence of Fine-grain refactorings form a primitive refactoring. 8) Automation: Based on the activities required for Modeldriven refactoring presented in Section 2, it is evident that in order to be completely practical, automation support is necessary to cover the entire range of designated activities. Refactoring approaches can be classified based on their degree of automation: Manual, Semi-Automated and FullyAutomated. A fully-automated approach provide automatic detection and correction of design defects without user intervention. Semi-automated approaches require interaction with the user throughout the refactoring process. A semiautomated refactoring approach assists the user by proposing refactoring opportunities and their suggested solutions. The decision to perform the actual transformation is left to the user. Manual refactoring approaches are UML modeling tools that leave the process of model smell detection and application decision to the user completely. Manual refactoring approaches automate behavior preserving model transformations only.

TABLE I. COMPARISION Comparison Criteria OO Concepts Formality Ease of Use Conciseness Artifact Coverage Expressiveness Granularity Automation Portability Rule Handling

Graph Based ABS/POLY/INH Yes Average Yes ST/FN/BH RS/BP P/C Semi No SEQ/CD

OF

9) Portatbility: Specification languages used in modeldriven refactoring approaches usually conform to a metamodel. For instance, in graph-based approach, a type graph is used to ensure whether or not a graph is well-formed or not. Portability of an approach is hindered mainly due to the use of different metamodels to represent UML models. This criteria is evaluated on a dichotomous yes-no scale. 10) Tranformation Rule Handling: A transformation rule specifies the actual transformation to be performed on the source model to obtain the target model. Two important aspects a model-refactoring approach should consider prior to rule application are 1) sequence of refactoring application (SEQ) and 2) conflict detection between rules (CD). A refactoring approach should provide formalisms to detect conflicts between refactoring rules and also allow scheduling of rules to attain maximum quality improvement. Approaches that do not provide any mechanism for sequencing and conflict detection leave it up to the developer to manually address these issues. V.

CONCLUSION

FUTURE WORK

UML model-driven refactoring is a highly active area of research. Quite a few quality approaches have been proposed in this area, but it still has some important open issues and limitations to be addressed. An important part of model-driven refactoring is the selection of an appropriate specification and transformation approach. This selection is usually constrained with a number of different characteristics. In this paper, we identified and discussed ten criteria based on which various approaches can be assessed. These criteria have been carefully selected to portray the pros and cons of each refactoring approach. The main objective of this comparative study was to provide guidance to researcher and practitioners in selecting an appropriate approach based on their needs. Although these comparison criteria have been carefully selected, there may exist others that can provide a better perspective to the practitioner. We plan to analyze approaches that, although are easy to comprehend and use, lack important characteristics such as formality, conciseness and rule handling. Integrating these features will improve usability of these approaches.

MODEL REFACTORING APPROACHES AGAINST

Logic Based ABS/POLY/INH Yes Complex No ST/FN/BH RS/BP P/C/FT Semi No SEQ/CD

AND

THE FRAMEWORK

Model Refactoring Approaches Direct Manipulation Language Specific ABS/POLY/INH ABS/POLY/INH No No Simple Complex Yes No ST/FN/BH ST/BH OD/RS/BP OD/RS/BP P/C P/C Full Full Yes No Manual SEQ/CD


Text Based ABS/POLY/INH No Average No ST/FN/BH OD/RS/BP P/C Full Yes Manual



ACKNOWLEDGMENT The authors acknowledge the support of King Abdul Aziz City for Science & Technology (KACST) as well as the Deanship of Scientific Research of the King Fahd University of Petroleum and Minerals in the development of this work. REFERENCES

[17] OMG, "UML 2.0 OCL Specification," Object Management Group, 2003. [18] A. Habel, R. Heckel, and G. Taentzer, ―Graph grammars with negative application conditions,‖ Fundam. Inf., vol. 26, no. 3-4, pp. 287-313, 1996. [19] D. Jackson, I. Shlyakhter, and M. Sridharan, ―A micromodularity mechanism,‖ SIGSOFT Software Enggineering Notes, vol. 26, no. 5, pp. 62-73, 2001. [20] D. Jackson, Software abstractions: logic, language and analysis: MIT Press, 2006.

[1]

E. Seidewitz, ―What models mean,‖ IEEE Software, vol. 20, no. 5, pp. 26-32, 2003.

[2]

J. Miller, and J. Mukerji, MDA Guide Version 1.0.1, 2003.

[21] J. M. Spivey, The Z notation: a reference manual, Hertfordshire, UK: Prentice Hall International, 1992.

[3]

OMG, "Unified Modeling Language: Superstructure," Version: 2.4.1, Object Management Group, 2011.

[22] G. Smith, The Object-Z Specification Language: Kluwer Academic Publisher, 2000.

[4]

R. B. France, and J. M. Bieman, ―Multi-View Software Evolution: A UML-based Framework for Evolving Object-Oriented Software,‖ 17th IEEE International Conference on Software Maintenance (ICSM'01), pp. 386, 2001.

[23] F. Baader, D. Calvanese, D. McGuinness, D. Nardi, and P. PatelSchneider, The Description Logic Handbook: Theory, Implementation and Applications.: Cambridge University Press, 2003.

[5]

W. Opdyke, ―Refactoring Object-Oriented Frameworks,‖ PhD thesis, University of Illinois at Urbana Champaign, 1992.

[6]

G. Sunyé, D. Pollet, Y. Le Traon, and J.-M. Jézéquel, "Refactoring UML Models," «UML» 2001 — The Unified Modeling Language. Modeling Languages, Concepts, and Tools, Lecture Notes In Computer Science, pp. 134-148, Berlin: Springer-Verlag, 2001.

[7]

K. T. Kalleberg, ―Abstractions for Language-Independent Program Transformations,‖ Doctoral thesis, Department of Informatics, University of Bergen, Bergen, Norway, 2007.

[8]

T. Mens, and T. Tourwe, ―A Survey of Software Refactoring,‖ IEEE Transactions on Software Engineering, vol. 30, no. 2, pp. 126-139, 2004.

[9]

T. Mens, G. Taentzer, and D. Müller, "Model-Driven Software Refactoring," Model-Driven Software Development: Integrating Quality Assurance: IDEA Group Publishing, 2008.

[10] M. Mohamed, M. Romdhani, and K. Ghedira, ―Classification of model refactoring approaches,‖ Journal of Object Technology, vol. 8, no. 6, pp. 121-126, 2009. [11] M. Katić, and K. Fertalj, ―Challenges and Discussion of Software Redesign,‖ The 4th International Conference on Information Technology, Amman, Jordan, pp. 1-7, 2009. [12] T. Mens, and A. Van Deursen, ―Refactoring: Emerging Trends and Open Problems,‖ Proceedings First International Workshop on REFactoring: Achievements, Challenges, Effects (REFACE), 2003. [13] T. Mens, G. Taentzer, and D. Müller, Refactoring,‖ International Workshop Reengineering, Berlin, Germany, 2007.

―Challenges in Model on Object-Oriented

[14] T. Mens, S. Demeyer, B. Du Bois, H. Stenten, and P. Van Gorp, ―Refactoring: Current Research and Future Trends,‖ Electronic Notes in Theoretical Computer Science, vol. 82, 2003. [15] R. Van Der Straeten, T. Mens, and S. Van Baelen, "Challenges in Model-Driven Software Engineering," Models in Software Engineering, Lecture Notes in Computer Science, M. Chaudron, ed., pp. 35-47, Berlin / Heidelberg: Springer, 2009. [16] R. Grønmo, B. Møller-Pedersen, and G. Olsen, "Comparison of Three Model Transformation Languages," Model Driven Architecture Foundations and Applications, Lecture Notes in Computer Science, R. Paige, A. Hartman and A. Rensink, eds., pp. 2-17, Berlin / Heidelberg: Springer, 2009.

[24] OMG, "Meta object faacility (MOF) 2.0 query/view/transformation specification," 2004. [25] openArchitectureware.org. "openArchitectureWare (oAW) (Online)," Available at http://www.openarchitectureware.org/. [26] F. Jouault, F. Allilaire, J. Bézivin, I. Kurtev, and P. Valduriez, ―ATL: a QVT-like transformation language,‖ Companion to the 21st ACM SIGPLAN symposium on Object-oriented programming systems, languages, and applications, Portland, Oregon, USA, pp. 719-720, 2006. [27] I. Porres, ―Rule-based update transformations and their application to model refactorings,‖ Software and Systems Modeling, vol. 4, no. 4, pp. 368-385, 2005. [28] A. Correa, and C. Werner, ―Refactoring object constraint language specifications,‖ Software and Systems Modeling, vol. 6, no. 2, pp. 113138, 2007. [29] J. Zhang, Y. Lin, and J. Gray, "Generic and Domain-Specific Model Refactoring Using a Model Transformation Engine," Model-Driven Software Development, S. Beydeda, M. Book and V. Gruhn, eds., pp. 199-217, Berlin Heidelberg: Springer, 2005. [30] OMG, "XML Metadata Interchange Management Group, 2007.

Specification

2.1.1," Object

[31] W3C. "XSL Transformations (XSLT) Version 2.0 (Online)," Available at http://www.w3.org/TR/xslt20/. Last Updated January 2007. [32] M. Gogolla, "Benefits and Problems of Formal Methods," Reliable Software Technologies - Ada-Europe 2004, Lecture Notes in Computer Science, A. Llamosí and A. Strohmeier, eds., pp. 1-15: Springer Berlin / Heidelberg, 2004. [33] J. Iivari, ―Object-orientation as structural, functional and behavioural modelling: a comparison of six methods for object-oriented analysis,‖ Information and Software Technology, vol. 37, no. 3, pp. 155-163, 1995. [34] G. Kniesel, and H. Koch, ―Static composition of refactorings,‖ Science of Computer Programming, Special Issue on Program Transformation, vol. 52, no. 1-3, pp. 9-51, 2004. [35] E. Saadeh, D. Kourie, and A. Boake, ―Fine-grain transformations to refactor UML models,‖ Proceedings of the Warm Up Workshop for ACM/IEEE ICSE 2010, Cape Town, South Africa, pp. 45-51, 2009.




Logic Verification of Product-Line Variant Requirements Shamim Ripon*, Sk. Jahir Hossain, Keya Azad and Mehidee Hassan Department of Computer Science and Engineering East West University Dhaka, Bangladesh *[email protected]

Abstract—Formal verification of variant requirements has gained much interest in the software product line (SPL) community. Feature diagrams are widely used to model product line variants. However, there is a lack of precisely defined formal notation for representing and verifying such models. This paper presents an approach to modeling and verifying SPL variant feature diagrams using first-order logic. It provides a precise and rigorous formal interpretation of the feature diagrams. Logical expressions can be built by modeling variants and their dependencies by using propositional connectives. These expressions can then be validated by any suitable verification tool. A case study of a Computer Aided Dispatch (CAD) system variant feature model is presented to illustrate the verification process. Keywords-Software Product line; First order logic; modeling variants; Feature Model.

I.

INTRODUCTION

The increase competitiveness in the software development sector with immense economic considerations such as cost, time to market, etc. motivates the transition from single product development to product-line development approach. Software product line is a set of software intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or missions and that are developed from a common set of core assets in a prescribed way [1]. The main idea of software product line is to explicitly identify all the requirements that are common to all members of the family as well as those that vary among products in the family. This implies a huge model that helps the stakeholders to be able to trace any design choices and variability decision. A particular product is then derived by selecting the required variants and configuring them according to the product requirements. Common requirements among all family members are easy to handle and can be integrated into the family architecture and are part of every family member. But problem arises from the variant requirements among family members. Variants are usually modeled using feature diagram, inheritance, templates and other techniques. In comparison to analysis of a single system, modeling variants adds an extra level of complexity to the domain analysis.

Different variants might have dependencies on each other. Tracing multiple occurrences of any variant and understanding their mutual dependencies are major challenges during domain modeling. While each step in modeling variants may be simple but problem arises when the volume of information grows. As a result, the impact of variant becomes ineffective on domain model. Therefore, product customization from the product line model becomes unclear and it undermines the very purpose of domain model. This short paper presents our work-in-progress logic verification approach for variant requirements of software product line. Our particular interest is on the notion of variant dependencies that play a vital role in product customization. In our earlier work [2] we have shown how a Ùnified Tabular' representation along with a decision table can be augmented with feature diagram to overcome the hurdles of variant management during an explosion of variant dependencies. However, defining such table involves manual handling of variants and hence, formal verification is not directly admissible for such approach. This paper uses first-order logic to represent product line variants and their dependencies. Such representation is amenable for various kind sof formal verifications. We present a case study of Computer Aided Dispatch (CAD) 1 system product line by analyzing and modeling the variants as well as the variants dependencies. In the remainder of the paper, Section II gives an overview of the CAD domain model along with a brief description of the variants and their dependencies. How variants of the CAD domain are modeled is depicted in Section III and a detailed feature model of CAD domain is presented as well. The formal definitions of variant models and their dependencies are presented in Section III. By answering various questions regarding variants models we show how the verification is performed over the logical representation of the variant model. Finally, we conclude our paper and outline our future plans in Section V.

1

The CAD case study is adopted from Software Engineering Research group, Computer Science, National University of Singapore, http://xvcl.comp.nus.edu.sg/xvcl/cad/CAD.html




II.

CAD OVERVIEW

A Computer Aided Dispatch system (CAD) is a missioncritical system that is used by police, fire and rescue, health

Figure 1. Basic operational scenario of a CAD system

service, port operation, taxi booking and others. Fig. 1 depicts a basic operational scenario and roles in a CAD system. When an incident has occurred, a caller reports the incident to the command and control center of the police unit. A Call Taker in the command and control center captures the details about the incident and the Caller, and creates a task for the incident. There is a Dispatcher in the system whose task is to dispatch resources to handle any incident. The system shows the Dispatcher a list of un-dispatched tasks. The Dispatcher examines the situation, selects suitable Resources (e.g. police units) and dispatches them to execute the task. The Task Manager monitors the situation and at the end, closes the task. Different CAD members have different resources and tasks for their system. At the basic operational level, all CAD systems are similar; basically they support the dispatcher units to handle the incidents. However, there are differences across the CAD systems. The specific context of operation results in many variations on the basic operational theme. Some of the variants identified in CAD domain are: !

!

!

Call taker and dispatcher roles: In some CAD system Call taker and dispatcher roles are separated, whereas in some system their roles are merged and one person plays the both roles. Validation of caller and task information differs across CAD systems. In some CAD systems basic validation (i.e., checking the completeness of caller information and the task information) is sufficient while in other CAD systems validation includes duplicate task checking, yet in other CAD systems no validation is required at all. Un-dispatched task selection rule: In certain situation at any given time there might be more than one task to be dispatched and it is required to decide which task will be dispatched next. A number of algorithms are available for this purpose and different CAD system use different algorithm.

This simple description of CAD variants hints us about numerous variants and their dependencies, which focus the importance of managing them properly.

III.

MODELING VARIANTS

An explicit variability model as a carrier of all variability related information like specifications, interdependencies, origins, etc. can play an important and maybe the central role in successful variability management. Features are user visible aspects or characteristics of a system and are organized into And/Or graph in order to identify the commonalities and variants of the application domain. Feature modeling is an integral part of the FODA method and the Feature Oriented Domain Reuse Method (FORM) [3]. Features are represented in graphical form as trees. The internal nodes of a tree represent the variation point and their leaves; represent the values of corresponding variation points, known as variants. Graphical symbols are used to indicate the categories of features. The root node of a feature tree always represents the domain whose features are modeled. The remaining nodes represent features which are classified into three types: Mandatory, Optional, and Alternative. Mandatory features are always part of the system. Optional features may be selected as a part of the system if their parent feature is in the system. The decision whether an optional feature is part of the system can be made independently from the selection of other features. Alternative features, on the other hand, are related to each other as a mutually exclusive relationship, i.e. exactly one feature out of a set of features is to be selected. There are more relationships between features. One is Orfeature [4], which connects a set of optional features with a parent feature, either common or variant. The meaning is that whenever the parent feature is selected then at least one of the optional features will be selected. Feature diagram also depicts the interdependencies among the variants which describes the selection of one variant depends on the selection of the dependency connected variants. A CAD feature tree is illustrated in Fig. 2. IV.

LOGIC REPRESENTATION

A feature model is a hierarchically arranged set of features. The relationships between a parent (or variation point) feature and its child features (variations) are categorized as follows: !

Mandatory: A mandatory feature is included if its parent feature is included.

!

Optional: An optional feature may or may not be included if its parent is included

!

Alternative: One and only one feature from a set of alternative features are included when parent feature is included.

!

Optional Alternative: One feature from a set of alternative features may or may not be included if parent in included.

!

Or: At least one from a set of or feature is included when parent is included.

!

Optional Or: One or more optional feature may be included if the parent is included




Figure 2. CAD feature diagram with dependencies

The logical notations that we use in this paper to represent these features are illustrated in Fig. 3.

Figure 3. Logical notations for feature models

A feature model can be considered as a graph consists of a set of subgraphs. Each subgraph is created separately by defining a relationship between the variation point (vi) and the variants (vi.j) by using the expressions shown in Fig. 3. For brevity, a smaller partial feature graph is drawn from CAD feature model in Fig. 4.

Figure 4. A partial CAD feature graph using symbolic notations

The complexity of a graph construction lies in the definition of dependencies among variants. When there is a relationship between cross-tree (or cross hierarchy) variants (or

variation points) we denote it as a dependency. Typically dependencies are either inclusion or exclusion: if there is a dependency between p and q, then if p is included then q must be included (or excluded). Only inclusion dependencies are shown in this paper. Dependencies are drawn by dotted lines. For example, there is a dotted line from v2.3.1 to v1.1 in Fig. 4. A. Analysis of Variants Automatic analysis of variants is already identified as a critical task [5]. Various operations of analysis are suggested in [6], [7]. Our logical representation can define and validate a number of such analysis operations. The validation of a product line model is assisted by its logical representation. While constructing a single system from a product line model, we assign TRUE (T) value to selected variants and FALSE (F) to those not selected. After substituting these values to product line model, if TRUE value is evaluated, we call the model as valid otherwise the model is invalid. A product graph is considered to be valid if the mandatory subgraphs are evaluated to TRUE. Example 1: Suppose the selected variants are v1, v1.1, v2, v2.1, v2.3, v2.3.1, v2.4, v3 and v3.2. We check the validity of the subgraphs G1, G2 and G3 by substituting the truth values of the variants of the subgraphs.

As the subgraphs G1, G2 and G3 are evaluated to TRUE, the product model is valid. However, variant dependencies are not considered in this case. Dependencies among variants are defined as additional constraints which must be checked separately apart from checking the validity of the subgraphs. Evaluating the dependencies of the selected variants, we get




Dependency:

It concludes that the selected features from the feature model create a valid product. Example 2: Similar to Example 1, suppose the selected variants are v1, v2, v2.1, v2.3, v2.3.1, v2.4, and v3. Initially, neither v1.1 nor v3.2 is selected. However, there is inclusion dependency between v2.3.1 and v1.1, and between v2.4 and v3.2 and the dependent variants are not selected. Therefore, the whole product model becomes invalid. To handle such scenarios where dependency decision can be propagated, a set of rules has been defined using first-order logic. One of the rules indicates that if there is an inclusion dependency between x and y and if x is selected then y will be selected. Due to inclusion dependency, both v1.1 and v3.2 will be automatically selected and the product graph will be evaluated to TRUE resulting in a valid model. It indicates how the model supports decision propagation. Example 3: Suppose the selected features are v1, v1.2, v2, $v2.3, v2.3.1, v3 and v3.1. For such selections each of the subgraphs is valid. Due to dependency between v2.3.1 and v1.1, the variant v1.1 will be selected automatically. But v1.1 and v1.2 have XOR relation; hence both variants cannot be selected together. It introduces an inconsistency into the model. It is now possible to decide which variant selection can result in an invalid model and take necessary measures. A dead feature is a feature that never appears in any valid product model. Identifying dead feature can optimize the product derivation from the product line model. Following the approaches shown in earlier examples, applying product model validity and decision propagation, dead features can be detected from the logical expressions. It is also possible to decide whether at least one product requirement can be selected from the product line model.

We are interested in developing an integrated variant modeling environment that will support the construction of graphical feature models followed by the generation logical models. By using an intermediate language, such as XML, this model can then be translated to any other languages that can be directly fed into verification tools such as Alloy [16], CSP Solvers etc. REFERENCES [1] [2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

V.

CONCLUDING REMARKS

This short paper presented an approach to formalizing and verifying SPL variant models by using formal reasoning techniques. We provided formal semantics of the feature models by using first-order logic and specified the definitions of six types of variant relationships. We also defined cross-tree variant dependencies. Examples are provided describing various analysis operations, such as validity, inconsistency, dead feature detection etc. We are currently working towards answering all the analysis questions mentioned in [6], [7]. In contrast to other approaches [8]-[13], our proposed method defines across-graph variant dependencies as well as dependencies between variation point and variants. These dependencies are defined as additional constraints while creating subgraphs from the feature graph. A knowledge-based approach to specify and verify feature models is presented in [14]. Comparing to that presentation, our definition relies on first-order logic which can be directly applied in many verification tools as in [15].

[11]

[12] [13]

[14]

[15]

[16]

P. Clements and L. Northrop, Software Product Lines: Practices and Patterns, 3rd ed. Addison-Wesley Professional, Aug. 2001. S. Ripon, ―A Unified Tabular Method for Modeling Variants of Software Product Line,‖ SIGSOFT Softw. Eng. Notes, vol. 37, no. 2, May 2012. K. C. Kang, S. Kim, J. Lee, K. Kim, E. Shin, and M. Huh, ―Form: A feature-oriented reuse method with domain-specific reference architectures,‖ Ann. Softw. Eng., vol. 5, pp. 143–168, Jan. 1998. K. Czarnecki and U. W. Eisenecker, Generative programming: methods,tools, and applications. New York, NY, USA: ACM Press/Addison-Wesley Publishing Co., 2000. K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, and A. S. Peterson,―Feature-oriented domain analysis (foda) feasibility study,‖ Carnegie-Mellon University Software Engineering Institute, Tech. Rep., November 1990. D. Benavides, A. R. Cortés, P. Trinidad, and S. Segura, ―A survey on the automated analyses of feature models,‖ in JISBD, 2006, pp. 367– 376. D. Benavides, S. Segura, and A. R. Cortés, ―Automated analysis of feature models 20 years later: A literature review,‖ Inf. Syst., vol. 35,no. 6, pp. 615–636, 2010. M. Mannion, ―Using first-order logic for product line model validation,‖ in Proceedings of the Second International Conference on Software Product Lines, ser. SPLC 2. London, UK: Springer-Verlag, 2002, pp.176–187. W. Zhang, H. Zhao, and H. Mei, ―A Propositional Logic-Based Method for Verification of Feature Models,‖ in Formal Methods and Software Engineering, ser. LNCS, J. Davies, W. Schulte, and M. Barnett, Eds.Springer Berlin / Heidelberg, 2004, vol. 3308, ch. 16, pp. 115–130. D. Benavides, P. Trinidad, and A. Ruiz-Cortés, ―Automated reasoning on feature models,‖ in Proceedings of the 17th international conference on Advanced Information Systems Engineering, ser. CAiSE‘05. Berlin,Heidelberg: Springer-Verlag, 2005, pp. 491–503. D. S. Batory, ―Feature models, grammars, and propositional formulas.‖ in SPLC, ser. LNCS, J. H. Obbink and K. Pohl, Eds., vol. 3714.Springer, 2005, pp. 7–20. M. Janota and J. Kiniry, ―Reasoning about feature models in higherorder logic.‖ in SPLC. IEEE Computer Society, 2007, pp. 13–22. K. Czarnecki and M. Antkiewicz, ―Mapping features to models: A template approach based on superimposed variants.‖ in GPCE, ser.LNCS, R. Glck and M. R. Lowry, Eds., vol. 3676. Springer, 2005,pp. 422–437. A. O. Elfaki, S. Phon-Amnuaisuk, and C. K. Ho, ―Knowledge based method to validate feature models.‖ in SPLC (2), S. Thiel and K. Pohl,Eds. Lero Int. Science Centre, University of Limerick, Ireland, 2008,pp. 217–225. J. Sun, H. Zhang, and H. Wang, ―Formal semantics and verification for feature modeling,‖ in Proceedings of the 10th IEEE International Conference on Engineering of Complex Computer Systems, ser. ICECCS‘05. Washington, DC, USA: IEEE Computer Society, 2005, pp. 303–312. D. Jackson, ―Alloy: a lightweight object modelling notation,‖ ACM Trans. Softw. Eng. Methodol., vol. 11, no. 2, pp. 256–290, Apr. 2002..




A Principled Approach to the Management of Overlay Networks using Reflection Paul Okanda School of Computing and Communications InfoLab21, Lancaster University Lancaster, LA1 4WA UK [email protected]

Gordon Blair School of Computing and Communications InfoLab21, Lancaster University Lancaster, LA1 4WA UK [email protected]

Lei Liu School of Computing and Communications InfoLab21, Lancaster University Lancaster, LA1 4WA UK [email protected]

Abstract—Overlay networks could be defined as a technique used by application developers to create virtual networks that suit their (applications’) operating environment. Overlay networks are developed on top of physical networks and are typically used in distributed systems such as client-server applications, cloud computing and peer-to-peer networks. Recent implementations of peer-to-peer applications such as file sharing and Voice over IP (VoIP) have increasingly meant that overlay networks have almost become ubiquitous. As a result, future overlay networks will increasingly coexist on the same node. A number of middleware frameworks such as GRIDKIT [1], P2 [2] and ODINS [3] currently offer support for the co-existence of multiple overlay networks. However, co-existing overlay networks interfere with each other’s performance either through competition for resources or the lack of collaboration between them. This paper introduces a principled approach called virtual overlays which uses reflection to manage competition and collaboration between co-existing overlay networks in a way that is expressive, flexible, configurable and dynamically adaptable. Keywords-Reflection; Overlay Networks; Virtual Overlays;

I.

INTRODUCTION

An overlay network can be seen as an application level network layer or partial network stack which represents a virtual network. This virtual network is realized as a composition of nodes and logical links abstracting from an underlying existing network. The main motivation behind overlay networks is the provision of more tailored application services to support applications in different domains e.g. multimedia file sharing, peer-to-peer networks etc. Overlay networks have gained widespread utilization in recent years as a way through which services offered by the underlying physical network can be tailored to better support the requirements of applications. Applications such as multimedia file sharing and Virtual Private Networks (VPNs) have proven that overlay networks provide a powerful and efficient solution for specific problems, e.g. security and content distribution.

The success of current overlay networks e.g. Chord [5], SCRIBE [6] and Pastry [7] has meant that future trends will result in nodes that run different distributed applications hosting multiple overlays at a time. This is bound to introduce competition for local resources such as CPU time, memory consumption and network resources such as bandwidth. There is therefore a need for a framework that resolves competition for local and network resources, manages collaboration between two or more overlay networks and, creates a higher level of abstraction that provides developers with better control over the management of resource conflicts and collaboration between overlay networks. We propose the use of virtual overlays and reflection as a means through which the strengths of multiple overlapping overlay networks can be combined to not only efficiently resolve conflicts between overlay networks but also manage competition between them and support their collaboration in a flexible, adaptive and configurable way. This paper is structured as follows: Section II presents a background on reflection. It defines, justifies and details different types of reflection. Section III then provides a background into Overlays and an insight into our overall approach using Virtual Overlays, while a description of our system‘s design and implementation is covered in section IV. Details of experiments and their evaluation are provided in section V. Section VI then presents related work and finally, section VII concludes the paper. II.

BACKGROUND ON REFLECTION

A. Definition of Reflection The conceptual origin of reflection could be traced to Smith [17] who introduced it thus: „In as much as a computational process can be constructed to reason about an external world in virtue of comprising an




ingredient process (interpreter) formally manipulating representations of that world, so too a computational process could be made to reason about itself in virtue of comprising an ingredient process (interpreter) formally manipulating representations of its own operations and structures‟. This insight triggered an initially limited body of research in programming languages such as Lisp and a few others in the object-oriented community. Subsequently, this research diversified into areas such as distributed systems [18] in which contemporary research emphasis has been on architecting middleware platforms that are geared towards accommodating a wide variety of requirements imposed by both applications, mobility and underlying execution environments. For the purposes of this paper, we provide a simple contextspecific definition of reflection in Overlay networks as; „a design principle that allows a virtual network to have a representation of itself in a manner that makes its adaptation to a changing environment possible‟. B. Why Reflection? The motivation for all reflective systems could broadly be considered to stem from two concerns. These are: 1. The desire for open implementation [19],[20]. The classical view in software design is to handle complexity by the use of abstraction (from simple to high level) to hide implementation details from the users. This blackbox approach to design promotes re-use of components but it is not always desirable to hide all implementation details from the user. This is because hiding implementation details necessitates making implementation decisions on behalf of the application regardless of how essential the information the application has on the use of a particular module is. The ultimate objective of open implementation is to overcome this problem by exposing the implementation details of the system. This must however be achieved in such a way that there is a principled division between the functionality they provide and the underlying implementation. In this context, the former can be thought of as the base interface of a module and the latter as a meta-interface whose purpose is to provide access to the meta-level of the system. This approach is captured by Rao [21]: „A system with an open implementation provides (at least) two linked interfaces to its clients, a base-level interface to the system‟s functionality similar to the interface of other such systems, and a meta-level interface that reveals aspects of how the base-level interface is implemented‟. Meta interface (offers a MOP)

Service interface Figure I An Open implementation

It is important to note that in object-oriented systems, this meta-level interface is often referred to as the meta-object protocol for the object (or MOP) [22]. The Common Lisp Object System (CLOS) MOP for instance creates a reflective object system, using its own mechanisms to create an object-oriented representation of its behaviour. 2.

The desire to provide a principled (as opposed to ad hoc) means of accessing the underlying implementation of a system. The ability to access the underlying implementation mechanism of a system could be useful in two main aspects: Inspection: Reflection can be used to inspect the internal structural behaviour of a language or system. Exposing the system‘s underlying implementation subsequently makes it straight-forward to insert additional structural behaviour to monitor implementation. Adaptation: Reflection can also be used to adapt the internal behaviour of a system either by changing the interpretation of an existing feature (by modification or replacement) or by adding new features.

The use of reflection also has some potential drawbacks. The first drawback is that its use inevitably incurs an additional performance overhead. The most observable issue is the requirement that additional code be used to resolve the precise interpretation of behaviour in the system. The second obvious drawback results from the desire to open up the implementation. Care must always be taken by designers to maintain system integrity when the programmer has open access to the implementation. III.

BACKGROUND

ON OVERLAYS

A. Definition of Overlays An overlay network can be defined as an application level network layer or partial network stack which represents a virtual network. This virtual network is realized as a composition of nodes and logical links that are an abstraction from an underlying existing network. The main motivation behind the implementation of overlays is to provide more application-specific or tailored network services which are not provided by the underlying network. The advantages of overlay networks are pointed out in Aberer et al [4] thus: “In principle, distributed application services could also use directly the physical networking layer for managing their resources, but using an overlay network has the advantage of supporting application specific identifiers and semantic routing, and offers the possibility to provide additional, generic services for supporting network maintenance, authentication, trust, etc., all of which would be very hard to integrate into and support at the networking layer.” This general idea of overlay networks is well known and has been shown to work well. Transmitting information by sending telegraphs on top of a circuit switched network can be seen as a historic example. Dial-up connections between computers and bulletin board systems are an example that is close to the type of overlay that is the subject of this research




paper. Modern overlay networks are a critical part of distributed applications. For instance peer-to-peer applications use overlay technologies to create virtual networks as an abstraction from heterogeneous underlying networks, Virtual Private Networks (VPNs) add authentication and encryption to messages sent through them, which often cannot be provided by the underlying networks while peer-to-peer applications are ubiquitous and are used broadly. Current software systems that utilize overlay technologies, e.g. Chord [5], SCRIBE [6], or Pastry [7], usually implement a specific well known and well defined overlay routing mechanism and a corresponding topology. These virtual networks act like classic, message based, networks on top of underlying networks. They can be used in a stacked manner, but they keep their basic topology. Hence if an overlay network layer is designed as a ring network it maintains this structure when stacked with other overlay networks. B. Why Virtual Overlays? Current overlay networks have been shown to provide software engineers with high levels of abstraction at the cost of fine grained control on the message transmission. The wide adoption of overlay technologies results in co-existing implementations executing in nodes, e.g. the deployment of a VPN and a peer-to-peer file sharing application on a single computer. The new concept presented in this paper aims to provide an approach for controlling and orchestrating multiple coexistent overlay networks. In order to address the requirement mentioned in the introduction, virtual overlays provide a technology that can be used to a) resolve resource conflicts, e.g. competition for memory between an application specific implementation of a multicast overlay network and an unreliable transmission overlay network, b) manage collaboration between coexisting overlay networks e.g. between an overlay providing reliable transmission and an overlay providing multicast without forcing developers to give up the advantages of application-specific overlays and, c) provide a higher-level abstraction that gives developers the ability to configure the behaviour of overlays at a fine grained level, i.e. on a per message basis. This fine-grained permessage manipulation of behaviour implies that an overlay‘s behaviour is not only dependent on its static forwarding mechanism but also on the message which is passed. This also implies that technologies which are usually used on a packet level within the ISO/OSI layers can be used to orchestrate overlay networks. As will be seen in the next section, the focus of the design and implementation of the proof-of-concept system is on the manipulation of message routing in overlay networks at a finer level of granularity and in a more flexible way, without having a significant negative impact on understandability or system performance.

IV.

DESIGN

AND IMPLEMENTATION OF THE VIRTUAL OVERLAY

In this section, we describe our design of a virtual overlay by presenting a background on GRIDKIT and demonstrating how the design is realized on top of the GRIDKIT middleware framework. Crucially, the goal is to provide an approach that uses reflection to manage competition and collaboration between multiple overlay structures. A. Background on GRIDKIT GRIDKIT is a middleware solution whose aim is to provide support for the development of complex distributed systems. It can be used to develop a range of approaches some of which are service-oriented. In order to provide an array of interaction types, GRIDKIT provides different plug-able overlays at different levels of abstraction. The set of services provided by the GRIDKIT middleware for grid environments consists of service bindings, resource discovery, resource management and security. All of these can be combined with the communication layer realized by the GRIDKIT Overlay Framework [1]. GRIDKIT addresses the common challenges of middleware systems by providing developers with the possibility to interconnect overlays in different ways. In their paper ‗GRIDKIT: Pluggable Overlay Networks for Grid Computing‘, Grace et al [1] summarize the main goal of the GRIDKIT framework as follows: “The goal of our research in this area is to develop ways of building fully customizable, extensible, and evolvable overlays by factoring out generic techniques and protocols (e.g. largescale neighbor discovery, and network capability discovery techniques), and enabling these to be composed, extended and dynamically reconfigured under the auspices of a well defined [component frameworks].” As described above, overlay networks can be used to create functionality on top of underlying networks. In GRIDKIT, the developer is given the freedom to combine different overlay networks or even components of different overlay networks to create custom overlay networks. These custom overlay networks are created by interconnecting OpenCOMJ [1] components and component frameworks (CFs). This provides software developers with the tools to create custom interaction types based on pre-existing building blocks. This approach gives software architects more flexibility during the design of their applications [9], [1]. As described above, every overlay consists of OpenCOMJ components [1]. As shown in Figure II below, an overlay has to control its topology and provide its forwarding technique. Since the topology management and the forwarding are based on shared information, a third component is used to provide state information.

Identify applicable sponsor/s here. (sponsors)




Figure II An Architecture for a GRIDKIT Overlay Each overlay layer needs to be connected to an IDeliver interface and provides an IDeliver interface. This interface is used in the GRIDKIT framework to pass messages between layers of stacked overlays. An integer value is used to identify the overlay class that a message is passed to. The IDeliver interface is used to pass messages upwards through the overlay stack. Each overlay also provides and consumes at least one IForward interface. In contrast to IDeliver, the IForward interface is used to pass messages downwards through the overlay stack. High level control functionality is accessed using the IControl interface as it can be used to join and leave overlay networks. B. Extensions on GRIDKIT to support Virtual Overlays The system is implemented as part of GRIDKIT which features support for the co-existence of overlay networks. Overlay Network

Plugin 1

Plugin n-1

Plugin n

Message Tagging Rule Engine

State

Overlay Network

Control

Forward

State

Figure III An Architecture for a Virtual Overlay built on an Overlay

I) to the management of overlays (meta-overlays) and indeed this is implemented using GRIDKIT‘s underlying reflective mechanisms (presented as the service interface in Figure I). Below, we describe the fundamental constituents of the virtual overlay. Message Tagging & Rule Engine - The general concept of tagging messages was inspired by IP Filters [12] and Conoboy et al‘s [11] work on the rule language and its influence on packets being processed by the packet filter. All messages are tagged by all applicable rules; the process of tagging does not alter the message itself but adds a flag to the message for each applied rule. After adding all applicable flags to the message, a set of filters is used to alter the message according to the flags the message was tagged with. To ensure consistency with the idea of an interchangeable rule engines, the central requirement for a rule engine in the context of this project is its full compliance to JSR 94 [13]. This specification defines the general interfaces a rule engine needs to implement without specifying a rule definition language or a specific technology for the rule engine. Since the main differences for rule engines in this context are the technology and the language used to define the rules, the number of candidates for the virtual overlay‘s implementation was fairly limited. The following criteria were used during the decision making process: complexity, license, rule language, community, and documentation. Amongst the rule engines evaluated were Jess [14], JBoss Rules [15] and Hammurapi Rules [16]. Although the Hammurapi Rules development community is relatively small, its lightweight implementation made it the best choice for a prototype system. Plugins - The intercepted messages are tagged according to a rule set and based on the tagging of each message, control plugins manipulate the message. Finally the message is injected into or sent via a native overlay. Each plugin checks whether a message contains specific tags and if the message does, it performs some action, otherwise the plugin executes its default action. Crucially, the virtual overlay does not only intercept messages within the existing overlays but is in itself an overlay which can be stacked on top of existing overlays. It can receive messages from other overlays and send messages using the default set of overlay interfaces. In order to offer support for the orchestration of overlays, the system‘s overlay components implement an interception and injection interface. Figure IV below illustrates a plugin that checks whether a message contains specific tags. If the message does, it performs some action, otherwise the plugin executes its default action.

As shown in Figure III above, a virtual overlay component intercepts all messages sent, received or forwarded by native overlay networks. Depending on the content of the messages and the functions implemented by the plugins and the rule set deployed by the virtual overlay, these intercepted messages may or may not be re-injected into the native overlay networks. Note that this effectively equates to a reflective meta-level approach (presented as the meta interface in Figure




Figure IV Java Source Code for a Sample Filter Plugin The method processMessage checks if a message was passed to it, and it was it checks for the tag DROP and the absence of the tag PASS. If a DROP tag is found and not a PASS tag the message is set to null. If a PASS tag is found or no DROP tag is found the message is not manipulated. In either case, the message or null is passed to the next plugin by calling the parent method processMessage. This ensures that the entire chain of plugins is processed and the default action is carried out. Cases which require to process all messages can be imagined hence it is required that the messages are passed down the chain even if they are null. The inherited class GenericPlugin also implements the entire OpenCOMJ functionality. The development of a plugin only requires overloading the processMessage function - if a behavior different from just passing the message is required. The tagging engine in this prototype was developed as a façade around the rule engine to tag messages. In order to show that the tagging of messages with a following processing of the messages based on their tags is an efficient way of manipulating messages on middleware level a small rule set was defined. Figure V below shows how a rule can be created by implementing the infer method in a class inheriting from Rule.

Figure V A sample rule for Hammurapi Rules V.

EXPERIMENTAL EVALUATION

This section details an experimental evaluation of the implementation of the design discussed in section IIIB above. To facilitate the experiments, two representative and existing overlay networks are used to prove the concept of the described system; Tree Building Control Protocol (TBCP) [8] and Chord [5]. TBCP is used to span a balanced application level multicast tree. While Chord represents a distributed hash table (DHT)-based overlay ring network. Chord is a well known overlay network while TBCP is a clean realization of an application level multicast tree. Implementations of both overlay networks are part of the GRIDKIT framework.

From our implementation of the design detailed in section III above, we set up two sets of incremental experiments that focused on validating the architecture described in the previous section. As a first step, the general concept was verified by implementing a sample application that could be used to show major aspects of the proposed system and its basic performance metrics. Since overlay networks are not only defined by the forwarding technique that they implement but also by their topology and their state, the components maintaining and realizing their topology and state are represented in the context of virtual overlay networks. The second set of experiments aims to show a non-static (dynamic) implementation of meta-routing. It presents a prototype developed for inter-overlay routing based on self-configuring routes. A. A Basic Middleware Firewall Overview The proof-of-concept implementation presented in this subsection shows the realization of interception of messages within an overlay and reinjection of messages in the very same overlay. Crucially, its aim is to a) illustrate the internals of a minimal configuration of a virtual overlay and b) evaluate the performance overhead that is introduced by the implementation of a virtual overlay. Implementation As detailed below, this experiment implements the three constituents of a virtual overlay described in section III above. It involves a selection and implementation of a message injection mechanism, an implementation of a message tagging technology and an implementation of a rule engine. Message Injection – The fundamental concept of the proposed architecture is message interception and message injection. To prove this concept, a test application comprising two parts, a sender and a receiver was developed. Both components intercept messages before sending or receiving them. The intercepted messages get manipulated and then reinjected into (other or the same) overlay networks. In the initial stages of the experiment, a TBCP tree containing exactly two nodes was created, one node being the sender while the second node acted as a receiver. The sample application used a custom Log4J[10] appender to published messages to a multicast tree. Since broadcast messages were filtered within the sender and receiver in a multicast application that was extended to provide support for the interception of inbound and outbound messages, this could be considered a simplified firewall. Message Tagging - In the first prototype implementation, the filter basically drops or passes messages according to their tags. To gain higher flexibility, the plugin processing the tags has to define a default behavior in case no matching tags can be found or in case conflicting tags are attached to a message. The mechanism of using a separate tagging engine which does not define the behavior of the stack creates flexibility in choosing a rule engine for a particular task, or to meet specific




environmental constraints. It also allows the use of precompiled sets of tags to be attached to precompiled messages, which might be relevant in throughput-critical systems. Rule Engine - As illustrated in Figure VI below, the TBCP Overlay was extended to provide the interface IOverlayCallback. It also provides intercepted messages to the Virtual Overlay component using the IIntercept interface. The Virtual Overlay component uses a Tagging Engine component to wrap the rule engine via the interface ITag and forwards tagged messages to a chain of plugins using the IPlugin interface. The diagram below shows the components used. The chain of plugins only consists of two generic empty plugins as proof of the concept of the plugin chain as well as the DROPPlugin. The chain of plugins is realized using the IPlugin interface that each plugin has to implement.

as well as the time of reception to a file. To provide reproducible and facilitate comparison of results without the need to consider time synchronization, the receiving and sending application executed on the same computer. All involved Java Virtual Machines (JVMs) were running with normal priorities as user applications. Two virtual machines were used to span a tree containing one root node and one non-root node. All measurements were carried out free of external network interruptions, only the loopback device was used. Two measurements were taken; one showing the native GRIDKIT framework delivering the messages without any filtering or tagging and one showing the performance of the GRIDKIT framework using the prototype presented in this section. Table VII below shows the delay measured per message of the second set of 1000 sent messages.

Measurement

Logging Component IPlugin IPlugin

DROPPlugin

IPlugin

Logging Compone nt

GRIDKIT & Prototype GRIDKIT

Mean Msg. Delay in s 0.058

Std Deviation in s (%)

No. of Msgs. Sent

0.013 (22)

1000

No. of Msgs. Received (%) 800 (80)

0.055

0.013 (23)

1000

1000 (100)

Table VII Quantifying the Overhead of Virtual Overlays IPlugin ITag

Virtual Overlay

Tagging Engine

IIntercept

IVirtualOverlayCallback

TBCP Overlay

DROPFilter Virtual Overlay S.Steinhauer 19.03.2008

Figure VI Major components of the first prototype It is also implemented by the Virtual Overlay component which re-injects messages into the TBCP Overlay after they have completed the entire chain. The prototype‘s major components are briefly described below. The Tagging Engine – This rule tags all messages containing the word “DEBUG” with the tag DROP. A similar rule is used to tag all message having the word “FATAL” in them with the tag PASS. All other messages are not tagged at all. The rule engine automatically loads rules listed in a rule set definition file. The Tagging Engine also checks the rule set definition file for updates before tagging a message. This very simple approach allows runtime manipulation of the deployed rule set and was implemented to show that runtime adaptability can be achieved using the proposed system.

It is evident that the virtual overlay firewall performed its intended purpose since the expected number of messages (200 or 20%) did not reach the receiving node in the test using the prototype implementation. It also shows that all messages send using the native GRIDKIT implementation arrived at the identical receiving node. The difference between the average message delay when using the virtual overlay compared to not using it is around 0.003s. The standard deviation calculated for both measures is 13ms. In all instances, the measured delay from all messages sent using the altered framework was smaller than delays measured for the pure GRIDKIT implementation. This might indicate that the overhead added by the prototype implementation is smaller than other factors interfering with the message transmission. The main suspected factors are the virtual machine internal thread management as well as the process scheduling of the operating system. This experiment shows a sample application that realizes the basic architecture of a virtual overlay. The performance metrics detailed above prove that the configurability and expressiveness that is achievable using the proposed system makes the overhead insignificant. The next two experiments build on the implementation presented above to present more complex scenarios. B. An Enhanced Virtual Overlay

Evaluation To evaluate the prototype, a basic system creating log messages was used. The generator sends two sets of 1000 numbered messages with priorities iterating over {DEBUG, INFO, WARN, ERROR, FATAL}. A small receiver application logged the message, including the time of creation,

Overview This experiment aims at showing that our approach is not limited to message filtering or static routes but that virtual overlays can use their own state and a meta-routing algorithm




to reproduce GRIDKIT‘s Control, Forward and State overlay pattern introduced in section III. As illustrated in Figure VIII below, the namespace spanned by a Chord ring is used to globally address messages while messages sent to nodes in the Chord ring are actually routed via appropriate direct routes, which are in this example smaller Chord rings (with only 2 nodes).

Tagging Engine Logging Component IPlugin

IPlugin

Routing Plugin

IPlugin

Logging Component

IPlugin

ITag

Virtual Overlay Abstraction

1 – Namespace 1 – NW ICallback

0 – NS 0 – NE

Multi CHORD Overlay IDeliver

2 – Namespace 0 – Namespace 0 – NW

NW NS

0 – EW 1 – SW

NE

1 – NE 1 – EW 0 – SE

IDeliver

Iteration 3 Components

EW 3 – Namespace

SW

1 – SE

SE

CHORD Overlay

CHORD Overlay

1 – NS 0 – SW

Figure VIII Illustration of TBCP Trees and Chord Ring Setup This gives developers the flexibility to create virtual overlays which do not route messages within the actual overlays but between multiple overlays. Implementation As shown in Figure IX below, central to achieving this experiment‘s aim is the Routing Packet Overlay which uses a time controlled trigger to send information about each node it is deployed on in intervals. If the trigger fires, the Routing Packet Overlay obtains a list of all local Chord endpoints created by the Multi CHORD Overlay component. It then creates a message containing the global identifier (defined for the global namespace Chord ring) of the current node as well as the name and local identifier of the node in each Chord Overlay. The packet is sent via the local network named within the message. Thus the nodes in each local network can route messages correctly as they get to ‗know‘ the global identifiers of the nodes on that network. This data is stored and managed in Routing Table. The Multi CHORD Overlay component was developed to provide a unified interface to a multitude of Chord overlay networks. The component uses a network name to distinguish between the Chord overlay networks. In order to create a prototype which shows easily verifiable behavior, the Chord framework implementation was altered to support direct definition of node IDs.

Virtual Overlay S.Steinhauer 25.03.2008

Figure IX Major components in the scenario "Enhanced Virtual Overlay" Figure IX above shows three major components developed as part of this prototype (Routing Packet Overlay, Routing Table and Routing Plugin). Evaluation This scenario shows how the given components work together to route messages in a multi-overlay environment through collaborative message routing between nodes. The evaluation scenario is based on an overlay network environment with two nodes being part of two different Chord networks. Since the overhead of creating and maintaining the routing data within the hybrid network significantly influences the performance, it is not quantified. A scenario to demonstrate the effectiveness of the proposed system in an expressive manner would have required a bigger network and setup work beyond the scope of this paper. VI.

RAELATED WORK

In Cooper et al‘s paper ‗Trading Off Resources between overlapping Overlays‘ [3], an architecture called ODIN-S is introduced which has a focus on different methods to mediate resource usage between coexisting overlay networks. It uses a set of ingoing and outgoing filter to intercept messages on a shared communication layer. In this approach overlay networks are not stand-alone entities but plugins running on top of a common transport system. This transport system communicates with a set of filters in order to control throughput and order of messages being sent through the overlay network. ODIN-S also assumes a homogeneous deployment of ODIN-S instances since it uses specific receiver originated messages to control the throughput of messages on sending nodes. In general the paper shows that manipulation of messages on their entry point into the overlay environment can be used to achieve QoS through the control of resource conflicts between coexisting overlay networks. Some generic ideas for the design of the proposed system were inspired by a project called P2 [2]. This project makes use of a




declarative language to define overlays on top of a shared transport layer. The work stresses that declarative approaches can be efficient and expressive for describing the behaviour of overlay networks. The novelty of the concept of virtual overlays, as detailed in this paper is that it addresses the more general management of collaboration and competition between multiple overlay structures. VII.

[3]

[4]

[5]

CONCLUSION [6]

This paper has presented an argument for the use of virtual overlays as a technique by which competition and collaboration between co-existing overlay network structures can be managed. Although a number of middleware frameworks e.g. GRIDKIT [1] and P2 [2] currently offer support for the co-existence of overlay networks, co-existing overlay networks inevitably interfere with each other‘s performance either through competition for resources or the lack of collaboration between them. More specifically, the paper has provided a high level overview of a middleware design which uses a meta-overlay to combine the strengths of multiple overlapping overlays (hybrid overlay networks) with a strong focus on dynamic adaptability, flexibility and configurability. We therefore argue that the use of virtual overlays to resolve resource conflicts, optimize performance via collaboration between multiple overlay structures and provide a higher-level abstraction that gives developers control over the overlay networks they deploy is the way forward in the design of next generation middleware. Areas of future work include research into deployment of multiple rule sets, development of a custom rule engine and rule language, self-configuration of rule sets and performance metrics in a large scale deployment environment. We are currently doing research on group communication over Mobile Ad-hoc NETworks (MANETs) which could be viewed as overlays of multiple overlays of a network. Our sample experiments as detailed in this paper perform real-time analysis of the content of messages, append particular tags depending on the contents and inject the messages to the overlay. There are similarities between this and content based grouping in which nodes with different tags can be treated as different groups and be made to perform different actions, e.g. to drop or forward a particular message based on its content. REFERENCES [1]

Grace, P., G., C., Blair, G., Mathy, L., Yeung, W., K., Cai, W., et al: GRIDKIT: Pluggable Overlay Networks for Grid Computing. In Proceedings of Distributed Objects and Applications(DOA), Cyprus (2004).

[2]

Loo, B., T., Condie, T., Hellerstein, H., M., & Maniatis, P.: Implementing Declarative Overlays. In Proceedings of ACM Symposium on Operating System Principles 2005 (SOSP), Brighton, UK (2005).

[7]

[8]

[9]

[10] [11] [12] [13]

Cooper, F., B.,: Trading Off Resources between overlapping Overlays. In Proceedings of the ACM/IFIP/USENIX 7th Middleware Conference, Melbourne, Australia (2006). Aberer, K., Alima, L., O., Ghodsi, A., Girdzijauskas, S., Haridi, S., & Hauswirth, M.: The essence of P2P: A Reference Architecture for Overlay Networks. In Proceedings of the 5th IEEE Conference on Peerto-Peer Computing, Konstanz, Germany (2005). Stoica, I., Morris, R., Karger, D., Kaashoek, F., & Balakrsihnan, H.:Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications. In Proceedings of the ACM SIGCOMM Conference, San Diego, CA, USA (2001). Davis, A., M.: Operational Prototyping: A New Development Approach. IEEE Software, 9(5), pp 70-78 (1992). Rowstron, A., & Druschel, P.: Pastry: Scalable Decentralized Object Location and Routing for Large Scale Peer-to-Peer Systems. Lecture Notes in Computer Science, 2218, 329 et sqq. Mathy, L., Canonico, R., & Hutchinson, D.: An Overlay Tree building Control Protocol. In Proceedings of the 3rd International Workshop on Networked Group Communication, NGC, London (2001). Coulson, G., Blair, G., Grace, P., & Joolia, A.: A Component Model for Building Systems Software. In Proceedings of IASTED Software Engineering and Applications (SEA), Cambridge, MA, USA (2004). The Log4J Appender, http://logging.apache.org/log4j/docs/index.html Conoboy, B., & Fichtner, E.,: IP Filter Based Firewalls HOWTO Tutorial, http://www.obfuscation.org/ipf, 2002. IP Filter ver. 4.1.27, http://coombs.anu.edu.au/~avalon/ Toussaint, A.: Editor, Java Rule Engine API: JSR-94, Java Community Press, Sept. 2003.

[14] Friedman-Hill, E.: Jess Information, the Jess Engine for the Java Platform, http://www.jessrules.com/jess/index.shtml [15] JBoss: JBoss Rules Documentation Library, jboss.org: http://labs.jboss.com/jbossrules/docs [16] Hammurapi Group: Hammurapi Rules, http://www.hammurapi.biz/hammurapibiz/ef/xmenu/products/hammurapirules/index.html [17] Smith, B.C., “Procedural Reflection in Programming Languages”, PhD Thesis, MIT, Available as MIT Laboratory of Computer Science Technical Report 272, Cambridge, Mass., 1982. [18] McAffer, J., “Meta-Level Architecture Support for Distributed Objects”, In Proceedings of Reflection 96, G. Kiczales (Ed), pp 39-62, San Francisco. [19] Kiczales, G., “Towards a New Model of Abstraction in the Engineering of Software”, In Proceedings of IMSA ‘92 (Workshop on Reflection and Meta-Level Architectures), pp 1-11, A. Yonezawa, B.C. Smith (Eds), Tokyo, November 1992. [20] De Volder K., P. Steyaert, “Construction of the Reflective Tower Based Open Implementations”, Technical Report vub-prog-tr-95-01; Available from Programming Technology Lab, PROG(WE), Vrije Universiteit, Brussel, Pleinlaan 1, 1050 Brussel, Belgium, 1995. [21] Rao, R., “Implementational Reflection in Silica”, Proceedings of ECOOP ‘91, Lecture Notes in Computer Science, P. America (Ed), pp 251-267, Springer-Verlag, 1991. [22] Kiczales, G., J. des Rivieres, D.G. Bobrow, “The Art of the Metaobject Protocol”, MIT Press, 1991.




Indoor navigation using a mobile phone Brett Ausmeier Computer Science Department University of Cape Town Cape Town, South Africa

Thomas Campbell Computer Science Department University of Cape Town Cape Town, South Africa

Abstract—This paper describes the InNAVation system for indoor navigation using a mobile phone. A tool such as this requires a method of storing building data and routing information on the phone, as well as the ability to automatically track phone location as users walk around. We describe two alternative approaches to mapping building data along with a routing database design that make the project viable despite the limited storage, processing power and battery life of the phone. In particular, we compare GUI building plan annotation on a desktop computer with pedometer-based mapping of a building using the accelerometer on a mobile phone. Experiments indicate that users found plan annotation usable and database size scaled well for large buildings. The accelerometer-based approach to mapping a building was not acceptable due to inaccurate distance estimates; however this was adequate for tracking and directing users through a building, since small imprecisions were easily accommodated by users - they appreciated that directions would not give exact distances and were able to follow instructions to their destination in all test cases. Keywords: indoor navigation; mobile phone; user location; user tracking; building data capture

I.

INTRODUCTION

While GPS is commonly used in numerous applications, it is not sufficiently accurate for indoor navigation. This paper describes an investigation into the use of a mobile phone application to guide a user around a building or campus. Initially designed for a firm of consultants who wanted to save time when working at clients‘ premises, it can also be used in a variety of other useful contexts from museums to shopping malls. Such a system has two main requirements: the ability to store and process routing information for buildings on a mobile phone, and the ability to track the users as they walk. A system called InNAVation was built at UCT which utilised the accelerometer on a phone to track users‘ walking in order to direct them to their desired destination. Two alternative approaches to capturing route information were implemented and compared. One used the accelerometer to implement a pedometer-based mapping of buildings, whereby users clicked on locations as they walked past them. The other presented a plan of the building on a desktop computer which users annotated by clicking on points of interest. This paper reports on both approaches to building data capture, and the results of our experiments investigating the viability of indoor navigation using cellphones. Section 2 presents some background work, followed by one section on each of the two major components: building data capture and user tracking. Section 5 outlines the results of our experiments using

Sonia Berman Computer Science Department University of Cape Town Cape Town, South Africa [email protected]

InNAVation, and is followed by our conclusions and suggestions for future work. II.

BACKGROUND

Possible approaches to indoor tracking of mobile phones include the use of WiFi and Radio Frequency networks, Bluetooth localization, image matching, ambient fingerprinting and pedometer systems. Triangulation of a user‘s location can use readings from wireless transmitters, but this relies on their existence in the areas of interest, and is susceptible to wall attenuation in some buildings [1], people movement [2] and other factors such as the weather [3]. A cheaper solution is to set up Bluetooth transmitters in the building, and locate devices based on proximity to these. However this is not very accurate, and the cost of Bluetooth queries is high [4]. Cheaper still are passive RFID tags that reflect signals transmitted to them, but few phones have RFID readers built in [5] and they have such a short range that users would have to touch the RFID tags with their phone [6]. While few phones have RFID readers, most have cameras. Users could take photographs which could be matched up against an image database, but the database needs to include the full extent of lighting and camera angles [7]. Since this requires too much storage and processing for a phone, a server would need to be accessed which would be costly. Alternatively barcode readers on phones could be used if barcodes were distributed around the building. None of these methods is able to pinpoint the location of a phone with great accuracy, so ambient fingerprinting [8] could be used – this distinguishes rooms according to sound, movement, lighting and the like. The cheapest and most promising approach seemed to be the pedometer method, where step counts and lengths are used to determine location – accuracy of more than 98 percent was reported in [9]. An indoor navigation system also requires that building data is captured, so as to record the location of points of interest and the pathways between them. Architectural plans comprise accurate scaled 2-D representations of a building. Modern plans are kept in digital format, and even old buildings typically have digitized plans created when they undergo renovation. A plan drawn on paper can be manually digitized with a digitizing tablet by moving the cross-haired cursor and clicking to create points or features. Alternatively, a camera can create a digital image of a plan, but some distortion caused by the lens needs to be eliminated [10]. An indoor GIS application in [9] uses shape files to store building information as polygons with associated room details, services, operational status and personal details of occupants. A similar system [11]




characterizes routes in terms of time rather than distance, while [12] includes access privileges with route information. III.

PLAN ANNOTATION

FOR BUILDING DATA CAPTURE

For indoor navigation to be viable, it is vital that the capturing of data for a building is as cheap and simple as possible. For this reason we chose building plans as the starting point, rather than require installation of RFID tags or the like. The building plan is converted to an image that is displayed to the user, who then constructs a graph of points of interest or POIs (nodes) and walkable pathways (edges) on top of this image. Each POI is associated with a name (such as the room number) and a set of metadata keywords or tags indicating e.g. whose office that room is, which facilities (e.g. printer or fax machine) exist there, etc. The image needs to be calibrated so that distances in pixels can be converted to meters to walk. Two calibration options are provided. One alternative is for the user to supply the distance in meters between two POIs (nodes); this can be done using the Tracking Component or by independently measuring the distance between 2 adjacent POIs. By counting the pixels along the path between those two POIs, meters per pixel can be calculated and used to convert all other pixel distances into meters for user instructions. The simpler calibration option is for the user to supply the image resolution (pixels per inch) and the scale that appears on the building plan (meters per inch) from which the pixels/meter is calculated by the system. The GUI for building data capture was developed iteratively, and user evaluation was included in each iteration. A. Initial protoypes The first prototype can be seen in figure 1. It implemented the basic requirements of opening a building plan and, in a layer above this diagram, allowing users to construct the graph of POIs and routes between them. POIs were linked to pixel co-ordinates so that they were correctly transformed when the image was manipulated by zooming or scrolling. Two modes were needed in order to disambiguate mouse actions: one for adding information to the graph (construction mode), the other for altering the graph (edit mode) e.g. by relocating several nodes at a time.

Figure 1: First prototype showing Points of Interest and pathways.

In the second iteration distances were associated with edges and the shortest paths between POI pairs computed. Larger graphs were used in test cases, and the jagged look of pathways started to look untidy. This occurred in the following way. If the user indicated there was a path from A to B and from B to C, the system would draw these two edges by connecting the corresponding node centres. Thus, if the user had not placed A and C equidistant from walls - which tended to be the case seeing as humans do not click with great accuracy - the line from A to B to C would not be straight, as shown in figure 2.

Figure 2: Jagged lines resulting from poor placement by users.

Figure 3: Automated straightening of routes.

B. Aesthetic Improvements and Shortcuts The third prototype addressed the problem of jagged lines by detecting straight lines and corners using node co-ordinates along a route. It implemented a smoothing function that straightened the lines representing pathways accordingly, as shown in figure 3. The pathway detection algorithm first looked for nodes having X (or Y) values that differed by only a few pixels at most, and ―snapping‖ these nodes into a straight line. However this had to be altered to work with links rather than nodes to avoid situations such as those shown in figure 4.

Figure 4: Automated straightening has to consider not only node coordinates but also links, to avoid errors as in the above example.




The fourth prototype used node colours and shapes to show at a glance information that test subjects had requested. To avoid making the graph too complicated, only 2 shapes and 3 colours were used. As red is the most attention-grabbing colour, a red circle was used to indicate a node for which no data had been supplied, not even a room number. A green circle was used for nodes with a name but no metadata, and a yellow star was used for a node with both name and tags (indicating complete). Since a user could in theory supply metadata but no name, such nodes were represented by a red (no number) star (contain metadata). An example showing the different node representations can be seen in figure 5. This prototype also introduced shortcuts for selecting multiple nodes, and for drawing a node and an edge at the same time. The latter is done by holding down the shift key while clicking POIs whenever the intention is to also link a new POI to its predecessor.

Figure 7: Automated naming of nodes after applying pattern recognition.

Figure 8: Using end-points to ensure patterns are applied appropriately.

Figure 5: Fourth prototype showing the use of node colours and shapes.

The final version focused on aesthetic changes, and on time-saving shortcuts. Firstly, pattern detection was used to limit the number of POI names that users had to enter. Given that room numbers typically follow a pattern as one proceeds down a corridor, the user only needed to name two rooms and click the ―use pattern‖ button to have all selected nodes numbered automatically. The system detected which parts of the name were changing, and how. In the test building for example, there was a sequence of rooms named I4D2a, I4D2b, etc. as well as rooms named CSC300, CSC301, etc. which were correctly handled. The pattern naming system encountered problems when users selected nodes belonging to more than one corridor, as shown in figures 6 and 7. The first remedy attempted was to distinguish the major and minor axes along which nodes were linked, but this did not accommodated circular or hairpin bend paths. The final algorithm worked by detecting end nodes and then applying the pattern recognition to each branch of such multiple-corridor cases, as shown in figure 8.

The entry of tags was also considerably facilitated by allowing import of a file containing the room metadata. Since most organisations will have such information on a file in any case, this avoided the need to re-enter e.g. staff name, job title, telephone number and so on for offices, etc. Aesthetic changes requested by users were incorporated, such as renaming and reorganisation of buttons, and the use of different colouring for nodes so that the overall effect was easier on the eyes and gave a more professional look to the tool. An example of the final version of the system can be seen in figure 9.

Figure 9: Final version of building plan annotator. Figure 6: Any 2 rooms can be named on a path for pattern detection.

C. Porting routing data to the phone The Building Capture Component exported routing data to a SQLite3 database for use by the Navigation Component. This




database initially comprised a relation Nodes, containing the co-ordinates of each node, a relation Tags containing metadata associated with nodes, and a relation Routes containing the shortest path from each node to every other node. An additional relation Links contained each edge and its distance in meters, so that the Navigation Component could give appropriate instructions such as how far to walk before turning. The database was subsequently modified so as to limit storage space and processing time on the mobile device. The Node and Tag relations were combined so that all node information could be accessed by the mobile device at the same time, and the Links relation was abandoned since it was faster to calculate distances (from node co-ordinates) on the device itself. The database was sufficiently small for use on a mobile phone, and once database accesses were batched rather than individually executed, performance was not a problem. IV.

ACCELEROMETER -BASED INDOOR

NAVIGATION

A pedometer-based approach to tracking the location of a walking user requires a method of detecting steps and a method of determining someone‘s stride length. The subsections that follow consider each of these in turn. An overview of the Android application can be seen in figure 10.

while. A fourth attempt thus looked instead for peak-trough pairs, but this doubled the error rate rather than reducing it. Finally approximate peak volume was used for step detection, as this was essentially a combination of the merits of all the previous algorithms and gave the greatest accuracy.

Figure 11: Accelerometer readings when walking with a phone.

Initially users were asked to walk a given number of steps and the algorithm attempted to find exactly that number of peaks in the data; however this was not robust as users were found to mis-count and then off-by-one errors meant the peak thresholds were affected. A hybrid approach was then adopted – the application does automatic step detection using peak volume and then compares this with the number of steps the user was told to take. B. Determining step length GPS was first used to determine distance walked and then this was divided by the number of steps taken to calculate the user‘s average stride length. Unfortunately the best accuracy achieved using GPS on the phone was 4 meters. Clearly this is unacceptable for indoor navigation. Hence users were asked to walk a pre-measured distance instead, and this was divided by the number of steps taken to get average stride length for that user.

Figure 10: Overview of the subsystem residing on the Android phone.

A. Step detection The accelerometer on a phone measures the acceleration of the device. Assuming a mobile phone that is giving someone directions will be held face up, only acceleration up and down on the z axis is needed to detect steps. The first step detection method identified peaks (see figure 11) by finding points P such that P was greater than both its predecessor and its successor. A threshold to distinguish noise from steps was needed, but unfortunately this differed from one person to the next. To overcome this problem, peaks that differed by more than one standard deviation from the mean were regarded as noise. Unfortunately, experiments showed that steps taken from a standstill differ from those taken after walking for a

A user‘s location is tracked by having them indicate which entrance they use to the building, and then using the phone to detect distance walked and orientation. To overcome any error in step detection or stride length, a technique called ―corner snapping‖ is employed: when orientation changes close to 90 degrees, users have clearly turned right/left and hence their location can be adjusted/snapped to the corresponding corner/junction. This is done only if there is a passage at that point, to avoid snapping when someone is simply changing direction to e.g. walk round an obstacle or look at a notice on the wall. To optimize the corner-snapping, rather than choose a set distance from a possible junction this threshold is a percentage of the corridor length. Initially we anticipated that step calibration would be a once-off operation for a user, after which the system would only be engaged in tracking the user‘s location as s/he moved through the building. InNAVation was later changed to continually update stride length during the tracking phase so as to improve accuracy. This was particularly necessary because people tended to exaggerate their steps during the calibration stage instead of walking normally. Also, users tend to slow down on the final step and the last peak is thus lower than the others.


Pedometer calibration has a simple interface where one simply pushes a button at the start and again at the end of the walk. The navigation interface shows estimated current location in an (editable) ―From‖ box, and the user enters only the destination (e.g. ―fax machine‖ or ―Joe Soap‘s office‖). The route to take is shown as a sequence of instructions along with a ―distance remaining‖ value for the current instruction (see figure 12). When this reaches 0 the instruction disappears and the next instruction becomes current. For initial usage, the user has to indicate where s/he is in the ―From‖ box, which defaults to Main Entrance.

Mall, and even the calculation of shortest routes took less than a second to complete.

Figure 13: The ground floor of the Gateway shopping mall.

The usability of the plan annotation approach to building data capture was evaluated using constructive interaction and post observation. In constructive interaction users work in pairs and are encouraged to talk to each other as they carry out the given tasks, so that the users‘ thinking and understanding is more readily apparent. This method was used with 6 subjects working in 3 pairs, and with a further 4 subjects working with the system developer himself. In the latter case the developer was careful not to give any hints, and was able to question the subject if they did something without explaining why. In all cases the subject who was least confident and knowledgeable as regards computer usage was given control of the mouse, and this led to a great deal of communication in each pair. In the post observation phase, users were interviewed about anything that had arisen during their session and to elicit overall opinions and ideas.

Figure 12: Simple interface for directions, which shows remaining distance to go in the current step.

V.

SYSTEM EVALUATION

The mobile system was implemented on an Android phone using SQLite3 for data storage. The building plan annotation system was developed using JUNG and GraphML. The scalability of the system was tested using incrementally larger sections of a building, and finally by using the plan of the largest shopping mall in the Southern Hemisphere, namely the Gateway Mall in Durban, South Africa (see figure 13). It contained over 300 nodes and the growth of the database was studied by incrementally adding these in batches of 10. The database grew from 50 nodes (1225 routes) requiring 79Kb to 300 nodes (22350 routes) requiring 2654Kb. Each floor and its associated shortest routes are stored separately, hence the 2 growth of order N applies to N being the number of nodes per floor (150 in the case of Gateway). No lag was experienced while using the system to construct the graph of the Gateway

The tasks that the subject pairs were given were designed to gradually introduce system functionality. In the first task they were shown an example of a building that had been completely captured, and were asked to do likewise for a fresh, small plan. In the second task they were asked to name the nodes and told that patterns would be automatically detected. In the third task they were asked to calibrate and to enter metadata, and finally they were asked to check the metadata of a few nodes to ensure this had worked correctly. The 10 subjects were all in their 20‘s, and included males and females, with technical expertise ranging from ―terrible with computers‖ to those hinting that they were very knowledgeable. Overall they found the system usable and were able to complete all but one of the tasks easily. Some users experienced difficulty at first in trying to insert name and metadata information, and took some time before right-clicking on the node; others immediately right-clicked. On a scale of 1 (poor) to 5 (good) the majority rated the first task a 5, with some choosing 4. In the second task a lot of difficulty was experienced using pattern naming – users would click on that button before entering any names at all, some did so after entering only one name, and some entered several names but then clicked on the button without selecting any




nodes to apply this to. It appeared that pattern recognition was not understood by participants, and a help function or wizard was needed. Alternatively a ―next‖ button that is clicked repeatedly could be used. Whichever of these options is selected for novices, the existing procedure should be retained as it is quickest for experienced users. The overall score for this task was 3 (average). In the third task users rated the calibration step as 4 out of 5, while metadata entry and checking was rated 5 by most, and 4 by a few. Some users disliked that all metadata for a node is displayed in one line rather than having each item (e.g. staff name, telephone number, printer, etc.) on a separate line, and one pointed out that this would be inconvenient for editing when people moved office. To test pedometer-based distance measuring, 20 users were asked to walk from A to B and the distance calculated by the Tracker System was compared to the actual distance walked, which was 28meters. The Tracker returned between 25.8m and 28.7m , with an average of 27.1m over the 20 tests, which is an accuracy of 97%. Since indoor navigation is unlikely to involve very long distances, a 3 percent error is acceptable, but illustrates the need for the corner-snapping employed by the Tracker (since in the worst of the 20 cases the error was as high as 2.2m). All 20 users were given a number of locations to visit in the building using the Tracker system, and all were able to find their way as directed every time – if the Tracker showed e.g. that they had no further to go before turning right, but in fact they had a wall on their right, they simply walked the extra meter or so and then turned. VI.

CONCLUSION

Experiments showed that a cellphone pedometer is a viable method of tracking a user and directing him or her to predefined locations within a building. A cellphone is able to store shortest-path data even for large buildings such as the largest shopping centre in the southern hemisphere. Even a simple interface was sufficient for users to correctly navigate a building using such a mobile application. The accuracy of the pedometer-based approach was however not adequate to map out a building layout; it is only suitable for navigation purposes when common sense is able to deal with small errors. When slight inaccuracy became evident to those users whose steps or stride length were not perfectly calibrated, they remained happy to follow directions on the understanding that distance remaining (to next instruction) was approximate rather than exact. In an experiment involving 20 users, each was always able to follow directions correctly. Two adjacent pathways right next to each other may however cause navigation problems for those users whose step calibration was not precise; fortunately such buildings are relatively rare. The plan annotation method - capturing nodes and pathways in a building by clicking over an image of the building plan - and importing a file of information for each node/room did prove to be a viable method for capturing location and routing information. In our experiments most usability ratings were 4 or 5 out of 5, with the exception of the

automated room-naming facility which was rated average. This appears to be a fault of the interface design however, rather than a problem with the pattern recognition method of automatically naming rooms for entire corridors at a time. Storing node and shortest route data in a SQLite database on a phone is practical in terms of both space and processing requirements, and required only 2.6M for capturing the largest shopping centre in the southern hemisphere. Future work is recommended given our promising findings with the prototype. An obvious improvement would be to show the building plan on the mobile device as people navigate, but space- and processor-efficient mechanisms would need to be developed for this. The system could also be modified to assist disabled people, for example by having voice input-output for blind users along with phone vibration when a turning point is near. Additional capabilities could enhance the convenience of deploying our application, such as having building-detail databases stored on the Web. Using the phone‘s GPS to identify one‘s location, this could then be automatically downloaded on entering a building. Facilities for easily editing information when changes take place in a building are needed. In addition, the tradeoff in replacing the Routes relation with one that saves space but requires more processing should be investigated. REFERENCES [1]

P. Bahl and V.N. Padmanabhan, ―Radar: an in-building rf-based user location and tracking system,‖ Proc. INFOCOM 2000, 19th Annual Joint Conf. , IEEE, 2000,pp.775-784.

[2]

M. Youssef and A. Agrawala, ―The horus wlan location determination system,‖ Proc. 3rd Int. Conf. on Mobiles Systems, Applications and Services, ACM 2005,pp.205-218. R. Elias and A. Elnahas, ―An accurate indoor localization technique using image matching‖, Proc. 3rd IET Int. Conf. on Intelligent Environments, IET, 2007, pp. 376-382.

[3]

[4]

K. Lin, A. Kansal, D. Lymberopoulos and F. Zhao, ―Energy-accuracy tradeoff for continuous mobile device location,‖ Proc. 8th Int. Conf. on Mobile Systems, Applications and services, ACM 2010,pp.285-298.

[5]

L. M. Ni, Y. Liu, Y. C. Lau and A. P. Patil, ―Landmarc: indoor location sensing using active rfid,‖ in Wireless Networks, vol. 10, pp. 701-710, 2004. J. Candy, ―A mobile indoor location-based gis application,‖ Proc. 15th Int. Symp. on Mobile Mapping Technologies, Padua, Italy, 2007.

[6] [7]

N. Ravi, P. Shankar, A. Frankel, A. Elgammal and L. Iftode, ―Indoor localization using camera phones,‖ {rpc/ 7th IEEE Workshop on Mobile Computing Systems and Applications, IEEE 2006,pp.49-59.

[8]

M. Azizyan, I Constandache, and R. Choudhury. ―Soundsense: mobile phone localization via ambience fingerprinting,‖ Proc. 15th Annual Int. Conf. on Mobile Computing and Networking, ACM, 2009, pp. 261-272.

[9]

D. K. Cho, M. Mun, U. Lee, W.J. Kaiser and M. Gerla, ―Autogait: a mobile platform that accurately estimates the distance walked,‖ Proc.PerCom 2010, Int. Conf. on Pervasive Computing and Communications, IEEE, 2010,pp.116-124.

[10] Z. Zhang, ―A flexible new technique for cmera calibration,‖ in Constraints, Microsoft 1998, pp.1-19 [11] M. Meijers, S. Zlatanova and N. Pfeifer, ―3D geoinformation indoors: structuring for evacuation,‖ Proc. Next Generation 3D City Models, 2005,pp.21-22. [12] P. Y. Gillieron, D. Buchel and I. Spassov, ―Indoor navigation performance analaysis‖, in Context, 2004, pp.1-9.




Security-oriented Design for Web-based Systems: A Critical Review

Marriette Katarahweire

Joseph K. Balikuddembe

School of Computing & Informatics Technology Makerere University Kampala, Uganda [email protected]

School of Computing & Informatics Technology Makerere University Kampala, Uganda [email protected]

Abstract—Security of web-based systems still remains a key challenge for most IT executives; for software is vulnerable at various stages and most severely weakened in the operational environment. In the past, models and tools or even design techniques have been devised to tackle this challenge. But we still see the reemergence of the same security issues that afflict both traditional and modern web-based systems. Our major goal is to examine what has been done to date in managing this risk, particularly during the software development process and at the deployment stage; so as to establish the research gap upon which further research can revolve. Our findings show that available literature has not extensively addressed how current security mitigating mechanisms can enhance the development of secure web-based systems. Hence, future work directed at bridging this perspective will perhaps provide more insight in advanced techniques that can help manage this problem. Keywords- Web-based System Security, Software Security, Design for Security

I.

INTRODUCTION

The current state of the art in web-based applications security i s far from being satisfactory. There are new security vulnerabilities which are discovered on an almost daily basis [1]. Still, many systems are developed, deployed, and used over years that contain significant security weaknesses. Proponents[2 - 4], in security engineering have observed that web application vulnerabilities and threats arise from poor designs, lack of security awareness on the side of developers and lack of support from management. This often results in the security of such applications being thought of past the development stage. Although high-quality development of secure web-based systems is still proving to be difficult, new software engineering mechanisms can perhaps provide better answers to these security concerns. Our inference is that we require cross-cutting security models that double check the design, code and the operational environment as a whole before deployment of such applications is done. In this paper we examine available literature in relation to security oriented design for web-based systems and the key outstanding research concerns that can provide guidelines for future work in this area. The rest of this paper is structured as follows. Section I constitutes this introduction. Section II constitutes the




rationale for this study; section III analyzes the current security management mechanisms in the design process; section IV provides the research gap and the next steps envisaged to address this gap. We conclude our paper with section V with highlights from our observations. II.

RATIONALE

Industrial experience in the production of software has proven that tracing requirements during software development is in itself difficult enough, yet enforcing security requirements is intrinsically subtle; hence, increasing the design and development complexity of software. In this kind of security tracing pattern, one has to take into account the interaction of the system with motivated adversaries that act independently. Anderson [5] observes that security is compromised most often not by breaking dedicated mechanisms such as encryption or security protocols, but by exploiting weaknesses in the way they are being used. The current industrial best practice dictates that code reviews, penetration testing and static code analysis can be used to analyze security related faults in a given piece of software. However, these may not be enough if security is not critically thought of right from the design stage. Additionally, assumptions made about the software do not eliminate security threats but have to be properly documented. Techniques like static code analysis are indicative in nature and do not involve security planning. It is hard to assume completeness when we validate what we did not plan for. Researchers in this area such as Maguire and Miller [2] and Steven et al. [6], have observed that project managers and users of the envisaged system assume the developer(s) will take care of the security aspects. Sadly, often these developers have limited expertise in software security related aspects. This means that security can easily be left out in the software development process as different stakeholders think it is another stakeholder‘s responsibility yet all are responsible. Thus, examining available literature on this subject so as to ascertain key outstanding issues that provide better insight in the design and development of such systems will help in bridging this perspective.




III. C URRENT SECURITY MANAGEMENT IN DESIGN Traditional software security design models have been proposed to include development of abuse/misuse cases [7- 8] and threat models [9]. Abuse cases aim at identifying those vulnerabilities that can be predicated onset. While threat models help highlight design faults that could cause security risks in the application. This kind of security management is well emphasized in the SQUARE methodology initially proposed by Mead and Stehney [10]. There are also available tools on the market such as HPWebInspect [11] and IBM Rational AppScan [12] that perform code analysis for security defects in software. There are also penetration testing tools that look at environment assessment of the infrastructure with regard to security. However, most of these seem to be looking at security at independent levels. Yet an attacker analyzes the vulnerability of the web application from design to implementation; so should the defense.

As illustrated in figure 1 below, security needs to cut across the three levels, that is, design stage, implementation and deployment and this assessment must be bidirectional at all levels. However, the current management of security across these 3 levels is delinked.

Figure 1: Cross-cutting Model

As illustrated above, a design model for the envisaged system maps to the business model upon which requirements are generated. Security is emphasized as a non-functional requirement, and abuse cases are identified and analyzed at this stage. Threat models are then applied on the design model to assess any security faults that could exist within the design. At the development stage, code is then reviewed, analysis done and where possible penetration testing executed. Once the application is ready for deployment, usually application firewalling is applied atop the existing infrastructure security. This kind of security integration across these levels has been successful where fat client applications are concerned; in that vulnerability is internally controlled. However, web-based applications have rendered this approach ineffective.

A. General Security Analysis & Techniques 1) Analysis Techniques: The software development lifecycle (SDLC) is made up of distinct common phases irrespective of the model used. When one follows the complete SDLC, it is an assurance that the application developed is up to standard. However, this may not be the case if security is not an integral component of this entire process. Various authors such those in [3] and [13]–[16] have emphasized the importance of security integration. Their contention is that it is important that security is built into web applications right from the start of the SDLC. If security is included right from the start of the software development process, from design to deployment, and not just at deployment level, then most of the security vulnerabilities and threats would be eliminated. Equally, Steven et al. [6] assert that many assumptions are made during the software development process but are not documented. Some of these assumptions relate to security requirements, which when not documented may never be implemented. Accordingly, as observed by Maguire and Miller [17], involving security right from the start of the SDLC is an effective approach. Security should not just be in reaction to a security breach which may occur after the application has been developed and deployed at the application layer through penetration testing and application firewalls. Other authors such as Wilander and Gustavsson [18] have also advanced the same claim. In their approach to managing this issue, they categorize security requirements into functional, non-functional and assurance requirements and this contribution is most relevant to the elicitation process rather than the entire SDLC. th African Conference on Software Engineering and Applied Computing(ACSEAC) 24



On the other hand, Howard and Lipner [19] suggest a Microsoft oriented approach for the development of secure software. This is geared at adding security-focused related activities and deliverables to the software development process. In this approach a security team is identified at the requirements gathering phase and this team is responsible for identifying the security requirements of the application. Additionally, threat models are introduced in the design phase, static analysis scanning tools and code reviews at the implementation level and penetration testing at the end. Whereas this is great mechanism for managing security related challenges, this is rather viewed as a best practice that is followed with disparate tools managing different aspects of security. It is also difficult enough to ascertain how this can extend to web engineering. Without the prior security knowledge, application testers whether carrying out source code analysis, dynamic analysis or penetration testing may still lack security requirement to test against. 2) Dynamic & Static Techniques: Several techniques have been employed and developed to detect security




vulnerabilities in applications. Most of these techniques are applicable past the development stage. These have been segmented into static and dynamic analysis techniques. Dynamic analysis techniques are employed as the application runs while static analysis techniques are applied on the applications source or object code. Static analysis techniques tend to use taint tracking as illustrated in [20 22]. On the other hand dynamic analysis techniques use symbolic execution and model checking [23 - 24]. Accordingly, various tools have been developed hinging on these techniques. For example, WebSSARI [25] and Pixy [26]. However, most of these tools require prior knowledge of potential vulnerabilities and are somewhat specific to particular programming languages. For instance, Pixy, WebSSARI are both meant for PHP, Java and JavaScript. 3) Hybrid Techniques: Apart from the dynamic and the static techniques, there are also other techniques that use a hybrid method as a combination of static and dynamic code analysis. For example, the technique suggested by Han et al. [27] as a testing method, uses finite state machines and composite nets to test against data as it moves through the system. However, this method fails to adequately illustrate how this input data is defined and whether this test data is design dependent or not. Equally, Jurjens and Yu [28] while basing on a hybrid technique developed an automated tool that analyses UMLSec modules against security requirements by checking the associated constraints with the UMLSec stereotypes. They implemented a plugin that uses an automated theorem prover for first-order logic to verify security properties of UMLsec models that make use of cryptography. With this approach, there is an assumption that everyone is using UML for system modeling which may not be the case and it is only for models that make use of cryptography. Hence, this is not generic enough for other modeling approaches. B. Security Design Models for Web Engineering Within the web development sphere, application security has also been in the limelight. For instance, Offut [29] highlights security as one of the quality attributes of web software applications on top of other quality attributes such as reliability, usability, availability, scalability, maintainability and time-to market. In this regard, various techniques have been designed to manage security related aspects in web-based applications. For example, Xie et al. [30] developed the ASIDE technique (Application Security IDE) which is an Eclipse plugin for Java that interactively provides reminder support to developers of web applications. The support provided is in form of code refactoring and annotation. This is in such instances where input validation or encoding and cross-site request forgery may exist. By developing this approach, they are confident that this mechanism can prevent programming errors if provided with such support in the IDE. Using an IDE may be a brilliant idea only if it provides

the programmer with a means to emphasize security parameters from the design phase; by checking all the static or hardcoded vulnerabilities. More still, Joshi et al. [31] suggest security models for web-based applications especially for access control. They also note that web application vulnerabilities may arise from browser vulnerabilities, network firewalls that let in malicious but authorized traffic. They contend that, given the architecture of web applications as three-tiered model, attacks on web applications can be from the application‘s environment. Thus, access-based modeling can provide better results in managing this risk. However, this kind of modeling will only cover one aspect of threats that are applicable to web applications while neglecting others security risks such as those related to authentication, data input, among others. There are various tools that have been developed to analyze security of these applications and some authors such as Auronen [32] have done a good review on this. The key observation here is that there are general tools that scan the application for all known vulnerabilities and others that scan only for specific vulnerabilities. There are others that allow the user to customize the attack tests to be carried out while others do not. However, most only scan HTML forms for parameters. Other work has concentrated on vulnerability assessment and detection after an application has been developed. This involves vulnerability scanning and application firewalling as described by Thompson [33]. Vulnerability scanners scan the application for loopholes by carrying out potential attacks and generate a report about threats in the application. Application firewalls are applied to a web application in a production environment. They attempt to protect the application against threats that were detected from the vulnerability assessment and were not corrected. Such tools assess and detect known vulnerabilities such as SQL injections and cross-site scripting attacks, among others. These are largely triggered by failure to validate inputs. An example of such tools is the F5 BIG-IP Application Security Manager initially proposed by Silva [34]. The downside with vulnerability detection and assessment methods is that more costs may be incurred to correct the errors in an already developed application. Our inclination is that these threats require prior analysis and modeling such that at the implementation stage validations are synonymously executed. C. Cross-cutting Models Cross-cutting models that link analysis to design, development and deployment can be viewed as sufficient models in managing this security paralysis. Cabot and Zannone [35] observe that there is no unified approach to tackling security from requirements analysis to implementation. As such, they propose a framework that considers security issues from problem domain analysis to implementation using model-driven development. This is




done by integrating all security protocols needed into the framework. However, this framework seems to be inclined to traditional applications other than web applications and it only stops at the implementation phase without looking at the deployment environment. On the other hand, Chan and Kwok [36] propose a Software Development Process for Secure systems (SDPSS) as a design pattern for integrating security into the software development process for e-commerce systems. Their model is based on UML and SSE-CMM for modeling the risks from design to deployment. However, the notion of abuse or misuse cases is neglected at design stage. Equally, Brose et al. propose an integrated security policy design into the software development process. However, this looks at access control as the key security loophole yet more exist. IV.

RESEARCH GAP & NEXT STEPS

Overall, the existence of various best practices with regard to security assessment and management in the SDLC cannot be refuted and if well adopted, secure applications can perhaps be guaranteed. However, these practices simply provide a ―what should be done‖ and not a ―how it should be done‖ approach. We have come across models and tools that exist at each stage of the SDLC. However, it is still difficult to see how well they interlink at the various stages of the SDLC. More still application firewalls, penetration testing tools and code analysis tools normally search or guard against known vulnerabilities. It is possible that an application, due to its functionality, may have additional vulnerabilities that are not among the well known vulnerabilities and these could cause great harm once exploited. The other key issue is that most of these existing models and frameworks have been premised on traditional software application than the management of web engineering security related challenges. Hence, the quest for web-based frameworks that cut across the entire SDLC in managing security is still on. Future work will need to provide answers to key questions that are still outstanding. For instance; • We need to understand the cost correlations and project management implications as a result for this security oriented design within the SDLC; with the view that integration does not render the software production process costly and much lengthened; • We need to ascertain how these existing frameworks can be applied to web engineering mechanisms and if the same mitigations observed previously can also be tracked in this realm; • We need to see how the proposed frameworks can be applied to various software development processes and the modeling approaches available as this seems to be lacking; • We also need to assess if the envisaged cutting models can really help in managing security vulnerabilities in web-based systems.

V.

CONCLUSION

The security of web applications is of paramount importance and software developers, architects and project managers need to be aware of the security implications, if web development is the preferred technology. For security mechanisms, such as security protocols, are notoriously hard to design correctly, even for experts. Also, a system is only as secure as its weakest part or aspect. Otherwise, if static and dynamic code analysis, penetration tests and source code reviews are done without major emphasis on security inclusive design; this will result in treatment of problem symptoms other than the actual root causes. Hence, the only way we can reassure our software consuming market of this software quality attribute is by using models and frameworks that look at security not as an aftermath of development, but rather as an integrated approach independent of a software development process and also cross-cutting to embrace all the various technologies. REFERENCES [1] [2] [3]

[4] [5] [6] [7]

[8] [9] [10]

[11] [12] [13]

[14] [15]

[16]

[1] OWASP. Owasp top 10 for 2010. [Online]. Available: https://www.owasp.org/index.php/Category:OWASP Top Ten Project J. Maguire and H. Miller, ―Web-application security: From reactive to proactive,‖ IT Professional, vol. 12, no. 4, pp. 7–9, july-aug. 2010. A. K. Dalai and S. K. Jena, ―Evaluation of web application security risks and secure design patterns,‖ in Proceedings of the 2011 International Conference on Communication, Computing & Security. ACM, 2011, pp. 565–568. J. D. Meier, Improving Web application security: threats and countermeasures. Microsoft, 2003. R. J. Anderson, Security Engineering - a guide to building dependable distributed systems. Wiley, 2001. J. Steven, G. Peterson, and D. A. Frinckle, ―Software Assumptions Lead to Preventable Errors,‖ Building Security In, pp. 84–87, 2009. J. McDermott and C. Fox, ―Using abuse case models for security requirements analysis,‖ in Proceedings of the 15th Annual Computer Security Applications Conference, ser. ACSAC 1999. Washington, DC, USA: IEEE Computer Society, 1999, pp. 55–. G. Sindre and A. L. Opdahl, ―Eliciting security requirements with misuse cases,‖ Requir. Eng., vol. 10, no. 1, pp. 34–44, Jan. 2005. F. Swiderski and W. Snyder, Threat Modeling. Microsoft, 2004. N. R. Mead and T. Stehney, ―Security quality requirements engineering (square) methodology,‖ SIGSOFT Softw. Eng. Notes, vol. 30, no. 4, pp. 1–7, May 2005. HP, ―Web application security across the application lifecycle,‖ White Paper, 2010. Rational appscan family. [Online]. Available: http://www-01. ibm.com/software/awdtools/appscan/ A. K. Ghosh, C. Howell, and J. A. Whittaker, ―Building software securely from the ground up,‖ IEEE Software, vol. 19, no. 1, pp. 14– 16, 2002. D. Scott and R. Sharp, ―Developing secure web applications,‖ IEEE Software, 2002. R. Jones and A. Rastogi, ―Secure coding: Building security into the software development life cycle,‖ Information Systems Security, vol. 13, no. 5, pp. 29–39, 2004. R. Kissel, K. Stine, M. Scholl, H. Rossman, and J. Fahlsing, ―Nist special publication 800-64 revision 2 security considerations in the system development life cycle,‖ Nist Special Publication, pp. 1–34, 2008.




[17] J. R. Maguire and H. G. Miller, ―Web-application security: From reactive to proactive,‖ IT Professional, vol. 12, pp. 7–9, 2010. [18] J.Wilander and J. Gustavsson, ―Security requirements - a field study of current practice,‖ in E-Proceedings of the Symposium on Requirements Engineering for Information Security, in conjunction with the 13th IEEE International Requirements Engineering Conference, 2005. [19] S. Lipner and M. Howard, ―The Trustworthy Computing Security Development Lifecycle,‖ 2005, http://msdn.microsoft. com/enus/library/ms995349.aspx. [20] V. B. Livshits and M. S. Lam, ―Finding security vulnerabilities in java applications with static analysis,‖ in Proceedings of the 14th conference on USENIX Security Symposium - Volume 14, ser. SSYM‘05. Berkeley, CA, USA: USENIX Association, 2005, pp. 18– 18. [21] Y. Xie and A. Aiken, ―Static detection of security vulnerabilities in scripting languages,‖ in Proceedings of the 15th conference on USENIX Security Symposium - Volume 15, ser. USENIX-SS‘06. Berkeley, CA, USA: USENIX Association, 2006. [22] O. Tripp, M. Pistoia, S. J. Fink, M. Sridharan, and O. Weisman, ―Taj: effective taint analysis of web applications,‖ in Proceedings of the 2009 ACM SIGPLAN conference on Programming language design and implementation, ser. PLDI ‘09. New York, NY, USA: ACM, 2009, pp. 87–97. [23] S. Nanda, L.-C. Lam, and T.-c. Chiueh, ―Dynamic multiprocess information flow tracking for web application security,‖ in Proceedings of the 2007 ACM/IFIP/USENIX international conference on Middleware companion, ser. MC ‘07. New York, NY, USA: ACM, 2007, pp. 19:1–19:20. [24] V. Haldar, D. Chandra, and M. Franz, ―Dynamic taint propagation for java,‖ in 21st Annual Computer Security Applications Conference (ACSAC 2005), 5-9 December 2005, Tucson, AZ, USA. IEEE Computer Society, 2005, pp. 303–311. [25] Y.-W. Huang, F. Yu, C. Hang, C.-H. Tsai, D.-T. Lee, and S.-Y. Kuo, ―Securing web application code by static analysis and runtime

[26]

[27]

[28] [29] [30]

[31]

[32] [33] [34] [35] [36]

protection,‖ in WWW ‘04: Proceedings of the 13th ninternational conference on World Wide Web. New York, NY, USA: ACM, 2004, pp. 40–52. N. Jovanovic, C. Kruegel, and E. Kirda, ―Pixy: A static analysis tool for detecting web application vulnerabilities,‖ Secure Systems Lab, Vienna University of Technology, 2006. W. Han, H. Ye, and Z. Ding, ―A New Approach to Measure Software Security,‖ in Proceedings of the International MultiConference of Engineers and Computer Scientists, 2010. R. E. K. Stirewalt, A. Egyed, and B. Fischer, Eds., Tools for modelbased security engineering: models vs. code. ACM, 2007. J. Offutt, ―Quality Attributes of Web Software Applications,‖ IEEE Software, 2002. J. Xie, B. Chu, H. R. Lipford, and J. T. Melton, ―Aside: Ide support for web application security,‖ in Proceedings of the 27th Annual Computer Security Applications Conference, ser. ACSAC ‘11. ACM, 2011, pp. 267–276. J. B. D. Joshi, W. G. Aref, A. Ghafoor, and E. H. Spafford, ―Security models for web-based applications,‖ Commun. ACM, vol. 44, pp. 38–44, February 2001. L. Auronen, ―Tool-based approach to assessing web application security,‖ Nov 2002. H.H Thompson, ― Application penetration testing‖ IEEE Journal on Security Privacy, vol. 3, no. 1, pp. 66-69, 2005. P. Silva, ―Vulnerability Assessment with Application Security,‖ F5 Networks Inc, Tech. Rep., 2010. J. Cabot and N. Zannone, Towards an Integrated Framework for Model-driven Security Engineering. Citeseer, 2008, pp. 1–10. M. T. Chan and L. F. Kwok, ―Integrating security design into the software development process for e-commerce systems,‖ Information Management and Computer Security, vol. 9, no. 3, pp. 112 – 122, 2001.




) ! " # "

$ "$ '(

!+

-$

% &

!

*+ ,

!

! " #

$ "$ (

% #

!

#

! +

! "

"

#

" ./0" .10" .//0

! )

2 " 3

"

" 45" )

* 3

2

!6 *

/

3

/

) 2 7 8/9

*

/7 )

2

3

5

.?0

: 819 :

;9 )

2

"

3

)5! )

2 #

)

"

< 3 # 5 >

"

"

"

2

2

"

"

"

-=

"

" "

3 ! )

")

2

> #

3

"

8

9

4 8 9 #

4$)@>!




"

2 )

3

"

3

#

" 3 3 "

# "

"

@ ! "# "

@

"

" A 8B

9

#

!

"

B

$

$ .C0 *

"

-)

A

#

-) .E0"

-) )

1DC 6

@

" 1DC 6 )

"

-) .E0

!!!

4> )55,! ) ! +

@ )2 ./10 4

! ! 3

4 ,D 545 3

"

#

"

)2 " !!

!F) ! + @ @

!

#

@

#

J , 8

# !

*

19

#

# "

"

!

)

"

#

#

A

)F>

) 8

@

97

, 8 )

>

++>

" !F! K

9 .D0

"

#

" .G0

@* .H0 8$

9 @ > )6,! 4>-

# 83 .;0

3

" ** ,!+>

./I0" 3

"

# B$!

)

"

!+3"

$ 3

>

F

9

# th

African Conference on Software Engineering and Applied Computing(ACSEAC) 24


->"


*

*

17 4

,

?7 F

>

)

A 8

*

;9 9" 8 * @

8

! < H9" " 8

#

*

?9

" *

" 8

D 9

*

C

*

D7 -

*

* *

;7 ) L>

C7 3

>



$


N

.10

)

7 ) # $ 6L>> 1IIG 1E" >> " 6 # " * 1IIG "6 " #" F ! ! ! " .;0 4 # 3 ! 5 ;H " !3$ # #"> 4 " Q 7 ) # R !>>> "/GGI" F ;G" + ?" ??HO?DG .G0 ) " F + " = " F + 5 " > 6 7 ! 5 D > # " +>J