OPERAM: A Collaborative Semantic Workspace for Software Verification

Download PDF
3 downloads 14754 Views 977KB Size Report
Comment
goal. This work presents OPERAM, a collaborative semantic workspace that allows comparing the modeling performed at earlier stages of software development ...
OPERAM: A Collaborative Semantic Workspace for Software Verification Edenilson José da Silva

Emerson Torquato

Milton Pires Ramos

Emerson Cabrera Paraiso

Department of Informatics Universidade Tecnológica Federal do Paraná – UTFPR Pato Branco, Brazil [email protected]

Information Technology Department Pontifícia Universidade Católica do Paraná – PUCPR Curitiba, Brazil [email protected]

Center for Intelligent Systems Engineering Instituto de Tecnologia do Paraná - TECPAR Curitiba, Brazil [email protected]

Post-Graduate Program on Informatics – PPGIa Pontifícia Universidade Católica do Paraná – PUCPR Curitiba, Brazil [email protected]

Abstract — Collaboration is an important issue when developing software, because it involves working together towards a common goal. This work presents OPERAM, a collaborative semantic workspace that allows comparing the modeling performed at earlier stages of software development with JAVA code. OPERAM provides useful information for professionals involved in the task of developing code and even managing the project. OPERAM aims to allow monitoring of the project, helping users to be aware of the context they are working, allowing carry out verification of software development, confronting the modeling performed with source-code produced during the programming phase. We present its main features and architecture. A validation was conducted to prove the effectiveness of OPERAM. The results show the effectiveness of the workspace as a tool to support collaboration and software verification. Keywords: software verification; colaboration development; collaborative semantic workspace.

I.

in

software

INTRODUCTION

Software development is a collaborative activity, dependent on technology and performed by groups of people. The software technology involved is an important factor, because provides the necessary tools for the development of the work, and is essential in order to obtain more and better ways to produce software. This activity usually involves people with different roles: managers, software architects, developers, testers, and requirements engineers. All these professionals work with different types of artifacts in different tasks, most of these are junction or tasks requiring collaboration to be developed. These activities and people involved to develop software, observe the precepts of software engineering (SE), which seeks better ways of producing quality software. The organizational commitment defined in [1], is accomplished through people, considered an important component in SE. Creative people working together, and effective collaboration requires that stakeholders (actors in the process) coordinate their tasks efficiently [2]. For example, in a team, developers must decide

in advance who will work on a system request change. In addition, the team has to predict how this changes influence on the work of others, to ensure system consistency. Finally, software artifacts or development tasks are seldom independent and require coordination to run properly [2]. In this scenario, tools and environments used for best results are important because they help in defining strategies and ways of how to code, in order to achieve the full potential that the activity allows. Thus, OPERAM, presented in this paper, provides an environment for facilitating the collaboration between participants of a collaborative software development project. This is accomplished through the relationship between the participants and the artifacts they produce, especially by monitoring the code, to assist those involved in the process of setting up software to work together. Through this monitoring, it is possible to verify the implementation of the project that is being developed by actions taken in programming, comparing it with what was defined in the design phase, modeled through Unified Modeling Language (UML) class diagrams [4]. As a consequence, we expect a reduction of problems such as duplicated code, misuse of technology, lack of knowledge of what is being produced, lack of knowledge of the parts of the code already coded, among others, facilitating code verification. Another important contribution is bridge the gap between the modeling and effective implementation of the software. This gap has led many systems undergo constant maintenance, which results in higher costs of the project: more time spent and more resources allocated. According to financial costs and even higher, because according Al-badareen and colleagues [5], the software maintenance rates reach 90% of the total life cycle systems development. Finally, OPERAM contributes for the project awareness since what is coded becomes visible for all participants. OPERAM is a semantic workspace. By following up modeling to coding, it creates semantic links between source code, the model and project’s participants.

The next sections present the theoretical framework that based this work. We also present OPERAM, its architecture, features and functionality, as well as some experimental results. At the end we give a conclusion and present some perspectives of the work. II.

COLLABORATIVE SOFTWARE DEVELOPMENT

The process of developing software is highly based on teams working together, and these teams need to collaborate in order to achieve common goals in a shorter period of time. Thus, the design of collaborative software development is a subject on which many researchers have contributed, as in [3], where authors investigated the collaboration models and presented the results of a systematic review, in the form of a table of factors and sub-factors of collaboration. Other studies that investigated the way to work collaboratively on software development are found in [6], [7] and [8]. Collaborative tools are also a way to improve collaboration in the area of software development. In [9], the authors present the design of a collaborative tool to support asynchronous software development, called TagSEA. Another tool, proposed in [10], is integrated into the Eclipse development environment, which adds up waypoints and create a set of tags associated with it, in order to create a mechanism that captures documentation relevant items on the source code that can be shared with the development team. The analysis of the source code also provides important information to monitor and measure the behavior of programs under development. There are several techniques, such as code instrumentation [11], analysis of source code (static and dynamic) [12] and software measurement [13]. OPERAM does the monitoring of the source code, as it was done in [14], where sensors were attached on development tools that nonintrusively, collect and send data to a process for further analysis. CSCW researchers are among the main contributors with tools to support collaborative software development. Several studies have been previously developed [9], [15], [16] and [17]. Some projects still under development ([18] [19] [20] and even other areas has also contributed [21]). These studies emphasize mostly the improvement of the infrastructure to support distributed development (through integrated environments or groupware).

code development and to compare it with the UML models that model de system under development. OPERAM may follow several projects simultaneously, contributing to the project awareness [22] (by allowing participants to follow the code under development in real time) and maintainability. Another important OPERAM´s capability is the ability to create semantic relationships between source code, models and developers. The principle is simple: participants in a collaborative software development write artifacts, such as source code, models, and so on. Each artifact has a number of co-writers associated (an is-cowriter-of association). Each source code is related to an UML Class Diagram (an is-relatedto association). Each project has a responsible (an isresponsible-for association). Several relationships can be inferred and controlled by OPERAM. Finally, OPERAM concerns an important issue in software engineering: Software Verification. As presented in [23], Software Verification determines whether the development products of a given activity conform to the requirements of that activity and whether the product satisfies its intended use and user needs. OPERAM verifies and points any inconsistence between modeling and source code. As a consequence, we expect that the source code produced in this workspace has less errors helping maintainability. The next sections show that, by graphically presenting the overall situation of a project, developers and the project manager are kept updated. For instance, an email is sent to participants related to a model if it is modified. A. The OPERAM Overview The workspace is compounded by the OPERAM itself and ordinary tools like an IDE, a modeling tool and a data base repository. Fig. 1 shows how participants interact with the system. First, a new project must be added to OPERAM. The project manager is the responsible for registering UML models and participants (developers) involved with the project.

The activity of software development is complex, consisting of several steps and naturally supported by tools specifically designed for this purpose. In general, software is produced collaboratively, with the participation of several experts (managers, analysts, developers and others). Users work in a team, and suffer from a multiplication of documents generated during the work, often collaboratively written. In this sense, the OPERAM acts as a tool to support collaborative software development. The tool is presented in the next sections. III.

OPERAM: A SEMANTIC WORKSPACE

OPERAM is a workspace that aims to support collaborative software development. Its main feature is to monitor source

Figure 1. The OPERAM overview.

Once registered, OPERAM starts following the development of the project. The idea is that developers start to code (no matter how many they are) and, in real time, OPERAM confronts the code under development with models previously uploaded. To do so, OPERAM has a sensor that collects data from each source code under development. This sensor is based on HACKYSTAT [24], which unobtrusively collects and sends raw data about the development process to a web service called the Hackystat SensorBase for storage. The SensorBase repository can be queried by other web services to form higher level abstractions of the stored raw data, and/or integrate it with other internet-based communication or coordination mechanisms, and/or generate visualizations of the raw data, abstractions, or annotations. Our sensor was developed to collect information from Eclipse users. Several and different data are collected. These data are produced and stored during the interaction between the user and the tool. In our tool those data are related to events (Table I shows an excerpt of the list of events) generated during the source code construction. Table I. Excerpt of the list of events List of Events (part of) Project under construction File under construction (arq.java) Creation of a method Deletion of a method Creation of a class Compilation errors and succeeds Runtime errors and succeeds When and who did the modification on a file

The Fig. 2 shows how OPERAM was implemented. OPERAM is a client-server system, implemented using the MVC (Model-View-Controller) concept [25]. Clients access OPERAM via a HTTP connection. In this actual version, OPERAM works with Eclipse IDE (http://www.eclipse.org), MYSQL data base (http://www.mysql.com), ASTAH (http://www.astah.net) for modeling and source code written in Java. Fig. 3 shows the OPERAM’s main window, where a Class Diagram is updated in real time, according to what is happening during codification. On the left side it is shown the original Class Diagram (done by the system architect). This diagram changes according to what is done by developers. The changes are related to events collected by the sensor. Every single class starts colored in white. Its color changes when OPERAM detects a difference between the code and the model. It goes green if a new item (a method or an attribute) is found in the code. It goes blue when an item is renamed. It goes red if the class is deleted.

Figure 2.

Deployment diagram.of OPERAM.

The principle is based on Kanban board one of the tools which can be used to implement the Kanban method [26]. Kanban is a method for developing software with an emphasis on just-in-time delivery while not overloading the software developers. Kanban boards are perceived as a variation on traditional kanban cards. Instead of the signal cards that represent demand or capacity, the board utilizes magnets, plastic chips, colored washers or sticky notes to represent work items. Each of these objects represents item in a production process and it moves around the board. Its movement corresponds with a manufacturing process. The board is usually divided into three sections: “awaiting production”, “work in progress” and “completed work”. In our approach, the colors help us to, visually, check the status of each class. The system updates the class diagram continuously (every 10 minutes). The use of class diagram and Kanban in a visual interface has the goal to improve collaboration between the project’s participants. Since every participant may follow the whole implementation, we expect to improve awareness. On the right side of Fig. 3 it is presented the time line of the project, based on the events caught by the sensors. The system registers every event in a data base. Those registered events represent the history of the project. Inspecting them one may evaluate some metrics related to the implementation process, such as: time needed to write each class, the number of changes

Figure 3. OPERAM visually tracking a project. (Obs.: the actual user interface of OPERAM is only in Portuguese).

a class had, the participation of each developer in each class, among others. The user may come back in time and see the status of a project in a given date.

This meta-model models the project and is compounded by several classes. The most important are presented in the next paragraphs.

B. The OPERAM Meta-model In order to keep a representation of the model been coded, OPERAM has a meta-model, shown in Fig. 4

The PROJECT meta-class is the key one, containing the information about the project been developed. The class encapsulates the ASTAH model, the project owner, to name a few. It is important to highlight that OPERAM works with multiple projects. The STATUS meta-class encapsulates the status of each class been coded. It main goal is to signal the actual situation of each class (“awaiting production”, “work in progress” and “completed work”). The meta-classes CLASS, ATRIBUTE, METHOD and PARAMETER model the key components of a class been coded. For instance, the meta-class METHOD encapsulates the signature of each method, its visibility, the information whether the method was implemented respecting or not the class diagram, among others. The meta-class USER models the users participating in a given project. Finally, the meta-class EVENT describes the events caught during code implementation (Table I). IV.

Figure 4. OPERAM meta-model class diagram for monitoring the coding.

EXPERIMENTAL RESULTS

This section presents the results of a study that have been conducted to evaluate OPERAM. A small team compounded by three developers and a project manager was invited to develop a system called MyBMI. The team was set especially

for this experimentation. Developers are experimented Java coders. They had 10 days to develop the application.

those involved in the development process. Table 2 shows some relationships created during the MyBMI development.

The goal of MyBMI is to control the overweight and underweight of an individual, managing the calories consumed by someone and evaluating his/her body mass index (BMI). In order to facilitate the process, one gave to the team the class diagram shown in Fig. 5. The project manager created a project into OPERAM, inserting on it the ASTAH model. Each developer received a set of class to code.

Table II. MyBMI data (excerpt): project. Semantic Relationship is-responsible-for last-updated-by last-updated-by is-related-to is-related-to class-created-by is-cowriter-of is-cowriter-of

Description Project manager CalorieGoal.java and Developer 1 X.java and Developer 2 CalorieGoal.java and class diagram PersonData.java and class diagram BMI.java and Developer 3 CalorieGoal.java and Developer 1 CalorieGoal.java and Developer 3

The table shows an excerpt of semantic relationships created during codification. OPERAM creates several different relationships (about ten relationships). OPERAM turns available management data, which may be used by the project manager to make important decisions about the way the project is being conducted, such as relocating people with specific skills to help others with difficulties in a given task. These data are available by inspecting the data base where OPERAM storages every event generated during the project codification. Inspecting the events generated during MyBMI codification, one may conclude, for instance, that Developer 1 worked during ten hours. It is also possible to name the developer that wrote the source code with more differences from the model (for example: created new methods and attributes). V.

Figure 5. Class diagram of MyBMI system.

The results showed us that developers respected the original model. The most common modifications are related to methods and its signature (as shown in right side of Fig. 6).

CONCLUSIONS

The OPERAM was presented and its features were described. A validation was also conducted and presented as a way to demonstrate the OPERAM’s potential as a semantic workspace environment for software verification and awareness. The results and the potentially of OPERAM encourage further research to make it available as a tool for the community. OPERAM helps software developers and project managers to carry out their work, as a contributing element to the software verification. It improves collaboration among participants, providing semantic information within the context of software development. Despite the evidence of effectiveness of OPERAM, some aspects can be improved in a future version, such as the creation of dashboards to present the current status of the project being developed, and also the incorporation of a CVS (Concurrent Version System). ACKNOWLEDGMENT

Figure 6. Class diagram of MyBMI system.

The experiment also allowed proving the effectiveness of OPERAM as a semantic workspace to support the software verification and awareness. It allows the encoding performed in real time and faces it with the UML modeling previously held. OPERAM also collects data related to collaboration among

This research is partially supported by Fundação Araucária and CAPES (Coordenação de Aperfeiçoamento de Pessoal de Nível Superior) (FA/ADE/131/2012). REFERENCES [1]

R. S. Pressman, “Software engineering: A practitioner's approach”. 7th Ed. Tata McGraw-Hill Education. 928 pgs. 2010.

[2]

[3]

[4] [5]

[6]

[7]

[8]

[9]

[10] [11]

[12] [13] [14]

[15]

J. Whitehead, “Collaboration in software engineering - a roadmap”. Proceeding’s of FOSE '07 - Future of Software Engineering. pp 214-225. IEEE Computer. 2007. H. Patel, M. Pettitt, J. R. Wilson, “Factors of collaborative working: A framework for a collaboration model”. Applied ergonomics, v. 43, n. 1, pp. 1–26. Elsevier Ltda. 2012. G. Booch, J. Rumbaugh, I. Jacobson, “The unified modeling language user guide”, Publisher: Addison Wesley 512 pages. 1998. A. B. Al-badareen, M. H. Selamat, M. A. Jabar, J. Din, S. Turaev, “The impact of software quality on maintenance process”. ACM International Journal Of Computers. Issue 2, Vol 5. 2011. T. Hildenbrand, F. Rothlauf, M. Geisser, A. Heinzl, T. Kude, “Approaches to collaborative software development”. International Conference. on Complex, Intelligent and Software Intensive Systems, p 523–528. 2008. M. A. Teruel, E. Navarro, V. López-Jaquero, F. Montero, J. Jaen, P. González, “Analyzing the understandability of requirements engineering languages for CSCW systems: A family of experiments”. Information and Software Technology, v. 54, n. 11, p. 1215–1228, 2012. R. Duque, M. L. Rodríguez, M. V. Hurtado, C. Bravo, C. RodríguezDomínguez, “Integration of collaboration and interaction analysis mechanisms in a concern-based architecture for groupware systems”. Science of Computer Programming, v. 77, pp. 29–45. Editora Elsevier. 2012 M. A. Storey, L.T. Cheng, I. Bull, P. Rigby, “Shared waypoints and social tagging to support collaboration in software development”. Proceedings of the CSCW - 20th Conference on Computer Supported Cooperative Work: pp. 195-198. 2006. E. Clayberg, D. Rubel, “Eclipse: Building commercial-quality plug-ins”. Eclipse Series.: Addison-Wesley Professional. p. 800. 2004. P. K. Chittimalli, V. Shah, “Gems: A generic model based source code instrumentation framework”. IEEE Fifth International Conference on Software Testing, Verification and Validation, pp. 909–914. 2012 D. Binkley, “Source code analysis: A road map”. Conference of Future of Software Engineering. IEEE Computer Societ. pp 104-119. 2007. T. Tahir, A. Jafar, "A systematic review on software measurement programs," Frontiers of Information Technology (FIT). pp.39,44, 2011. P. M. Johnson, H. Kou, J. M. Agustin, Q. Zhang, A. Kagawa, T. Yamashita, “Practical automated process and product metric collection and analysis in a classroom setting: Lessons learned from hackystatUH”. International Symposium on Empirical Software Engineering (ISESE’04). ISBN: 0-7695-2165-7 . 2004. C. Cook, N. Churcher, “Modelling and measuring collaborative software engineering”, Proceedings of ACSC2005: Twenty-Eighth Computer

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

Science Conference, volume 38 of Conferences in Research and Practice in Information Technology. 2005. T. Jiang, J. Ying, M. Wu, M. Fang, “An architecture of process-centered context-aware software development environment”. In: 10th Computer Supported Cooperative Work in Design. CSCW2006, 2006. A. Sarma, Z. Noroozi, A. van der Hoek, “Palantir: Raising awareness among configuration management”.Workspaces. In: 25th International Conference on Software Engineering (ICSE). 2003. J. Yuyan, Z. Zhuting, W. Zheng, S. Hao, “Analysis and design of an online collaborative editing systems on CSCW”. Multimedia Technology (ICMT-2011) - School. of Manage. Sci. e Eng., Anhui Univ. of Technol., Maanshan, China. P. 490-493. 2011. Y. Linxia, “An Application of a task-based CSCW system in enterprise informatization”. Management and Service Science (MASS), Inst. of Comput. Sci. e Technol., Taiyuan University. of Science. e Technology. 2010. W. J. Sarmiento, C. A. Collazos, “CSCW Systems in virtual environments: A general development framework”. 10th Conference on Creating, Connecting and Collaborating through Computing (C5). 2012. J. A. Barthès “Exchanging information among cognitive agents in collaborative environments.” In Proceedings of the IEEE International Conference on Systems, Man and Cybernetics, Anchorage, Alaska, USA, pp.1908-1913. 2011. C. Treude, M. Storey, “Awareness 2.0: Staying aware of projects, developers and tasks using dashboards and feeds”. Proceedings of the 32nd ACM/IEEE International Conference on Software EngineeringVolume 1. pp.365–374. 2011. IEEE Std 1012-2012. “IEEE Standard for System and Software Verification and Validation”. The Institute of Electrical and Electronics Engineers, Inc. ISBN 978-0-7381-7268-2. 2012. P. M. JOHNSON, “Requirement and Design Trade-offs in Hackystat: An In-Process Software Engineering Measurement and Analysis System”. International Symposium on Empirical Software Engineering and Measurement. pp. 81–90. 2007. S. Sengupta, A. Sengupta, S. Bhattacharya, “Requirements to components: A Model-View-Controller architecture”. Proceedings of 14th Monterey Workshop, pp 167--184, Monterey, CA, USA. 2007. M. Ikonen, E. Pirinen, F. Fagerholm, P. Kettunen, P. Abrahamsson, “On the impact of kanban on software project work: An empirical case study investigation”. 16th International Conference on Engineering of Complex Computer Systems. pp: 305-314. 2011.