Supporting Component Presence Notifications in

Supporting Component Presence Notifications in Software Development Ramón R. Palacio1, German Padilla1, Alberto L. Morán2, Joaquín Cortez3, Aurora Vizcaíno4 1

Unidad Navojoa, ITSON Facultad de Ciencias, UABC 3 Unidad Nainari, ITSON 4 Alarcos Research Group, University of Castilla-La Mancha [email protected], [email protected], [email protected], joaquí[email protected], [email protected] 2

Abstract Abstract—One of the current approaches to software engineering is Component-based Software Engineering (CBSE). As its name implies, CBSE has to do with the development of open and distributed systems by assembling a set of components. However in practice it is difficult to follow the characteristics demanded by this working philosophy because when developers want to update or modify a component, they do not have the required and sufficient information to determine the degree of impact that a change will have. In order to understand the management of components in CBSE ten experts in software development were interviewed. With the information obtained, the requirements for a system that we call Component Presence Notifier were defined. This system supports the extraction of information from different repositories of the organization and presents it as elements of a graphical user interface (GUI). This information is provided to the developer while working with any of the registered components in order to increase his/her awareness of the impact of the proposed modification. As future work, this prototype will be evaluated for usability by a group of distributed software developers. Keywords—Component-based Engineering; Software Engineering; Collaborative Systems.

Software Notifications;

I. INTRODUCTION Software development is a complex intellectual activity that consists of generating a computer application from a need or requirement raised or identified by a customer, and that is necessary to ensure that the developed application meets this need [1]. One way to develop software is known as component-oriented. A software component [2, 3] can be a code fragment module or a part of a manual of data from series. Likewise one component is replaceable, i.e. the developers can exchange a software component

with another [2, 3]. This way, a component can be found in software organizations as a program that can be executed (executable), a source code or data file, a static or dynamic library, a database table or even an analysis or modeling document. During the creation of components in a software development environment they have the particular feature of having relations with model elements that are implemented. Therefore it is normal that a software component contains multiple elements (i.e. several classes, tables, etc.), which create dependencies among these elements, as they will be structured and modularized. As a consequence, there are build dependencies between components, and frequently other components are required to compile a given component. Therefore, during the development of a system developers have to carry out proper coordination between components, so that these can be interdependent, as they communicate with each other via interfaces [1-4]. Thus, when a component provides services to the rest of a system, it becomes a key element of the system design, and if treated incorrectly this could be very expensive to for the organization. This kind of activity requires a great effort to really make the component reusable [5]. That is, as the component must be completely documented, it should be tested as much as possible and it should be robust and handle errors properly [2]. Software organizations deal with the existence of a high interdependence level between components, for which developers claim constant and high communication and coordination [6]. However, when the worker makes software maintenance activities or adaptation to a software component, and does not have adequate and opportune information to do so, this may be a source of problems [7]. This is, by not having knowledge of components which depend on it, that colleagues have used the component, as they have applied, how it must be used, among other information that is necessary to know for the developer before beginning its activities with the component.

Therefore the following researcch questions have been proposed: n about the • What is the information needed components that the company has? • How this information can notiffy the presence of components? p software That is because in the current practice, developers do not have adequate suppport for the reuse of components [8]. For this reason they often decide m the beginning, to start their developments from because they have the certtainty to find incompatibilities between componeents and perform rework [4].

II. METHOD To perform this study annd defining the requirements that determine thhe presence of components before or duringg the software maintenance activities we carried ouut three phases as shown in Fig. 1.

In a Software Developpment organization, a project of a production system m is being developed. Delia, who is located in Ciudad Obregón, México, has the role of Analyst insidee the team. Her prime activities are understandingg the problem and comprehending the necessitiess to be solved in order to define the software that is going to be developed. c requirements to Delia is required to deliver client’s the Software Arquitect on tim me, so he or she can begin with the design activitiess. Germán, located in Tucsonn, USA, has the role of Software Arquitect. His main activity a is to design the structure of the system, baseed on the features the client demands, which were obtained by the work done by the Analyst. In a certain moment, Germán is designing the structure of the system’s database, d which he is modeling using an entity-reelation diagram inside Microsoft Visio. At that prrecise moment, Delia makes a change to the requireements document of the system, since the client gave g her information unknown to her at the time she wrote the requirements document. Moments later, Germán seends his product to the other collaborators of the prooject (the Programmer and the Database Administratoor), so they can do their corresponding share of dutys.

Fig. 1. Phases of Method

Next briefly we describe all the phases p Phase 1: Initial Understandingg: relates to the analysis of literature with the aim m of identifying relevant papers on the component management m topic. Also we conducted semi-structured interviews to collect information about the sofftware production process. Phase 2: Identifying Problems: based on the findings resulting from the previouss phase, we define a set of requirements that help to moodel a prototype in which the developer can obtain infoormation about the components and the updates that they suffer at every moment. Phase 3: Design and Implemenntation: Once the system requirements were defined, we designed the functionality of the prototype to address them. A a prototype is description of the requirements and provided next.

ARIO III. ACTUAL SCENA

With the aim of showing the prooblems taken care of by this work, a scenario is presented in the following paragraphs:

After a while, in a project progress meeting with the team leader, Germán realizzes of the change made to the requirements docuument, which causes frustration to the team since thheir work has been done with erroneous requirements. With this scenario, we understand the work situation about the scarce information concerning the component and its relations.

QUIREMENTS IV. SYSTEM REQ

In order to identify som me of the component management problems that developers d face during component maintenance actiivities, semi-structured interviews were conductedd with 10 software developers directly involvedd in the production process (1 software productionn manager, 3 architect, 4 programmers, 1 database administrator and 1 tester). It is worth mentioninng that the interviewed software development group bases its production processes using the unifiedd modeling language (UML, for its acronym in engglish) and the Rational Unified Process (RUP) to moddel and design. The participants had expperience in developing software for ASP, C #. NET and Java implemented on personal computers and mobile devices using The database SQL Server 2005/20008 and MySQL. instrument for data collectionn during the interviews was a questionnaire, which waas based on literature on software component managem ment [1, 2]. It included questions about three main issues of interest for the

production of components: Interdependence between components (Maintenance Process), communication between members of the working group (Notifications), problems due to the lack of information of the components and component integration (Component Version). Examples of these questions are shown in Table I.

With this identified problems, needs were identified concerning the notification of the presence of components to developers. This information was used as a basis for establishing an initial set of requirements for our prototype that provides support relating to the existence of components.

TABLE I. SAMPLE INTERVIEW QUESTIONS Maintenance Process • Which are the situations that result in changes to software components? • Describe the maintenance process of how a change is made to a component. • Describe the use of the tools that you use for component management • Before performing maintenance to components, how do you report to get knowledge of the component? Component Version • How do you make sure that you are working with the latest version of the component? • How do you identify the configuration of the component that you are working on? • How do you get notified about changes that are / were made to components you are working on? Notifications • Do you know which people to inform when changes are applied to a component? • Please explain the method you use to notify your colleagues about the changes that you made to a component • Name the information elements that are needed to correctly notify a change. • What are the events or factors that you consider as necessary changes to report regarding component modifications?

Data obtained from the interviews were interpreted using qualitative analysis focused on identifying requirements and notification of changes in components. Data were extracted from interviews using a method based on grounded theory techniques [9]. A summary of the identified problems is presented in Table II. TABLE II. IDENTIFYING COMPONENT MANAGEMENT PROBLEMS. Component maintenance M1. Slow and imprecise identification of situations resulting in changes. M2. Difficult identification of components that affect others. M3. Lack of documentation of components. Component version V1. Frequently they do not know which the latest version of a component is. V2. Lack of mechanisms to identify the configuration of the component. V3. Slow traceability and not very effective changes in the component information. Notifications N1. The changes in the components do not notify them to all persons interested. N2. Notification only for implementators. N3. There are many events that are not considered important to notify, although these could be important and of great impact.

The requirements are: R1. Easy and fast access to the information provided by the repository of components from the identification of a given component (Problems M1, M2, V2). R2. Automatic notification of component-related information to developers concerned with the component (Problems N1, N2 and N3). R3. Light Mechanisms to integrate information, about a component, the component repository, the version control system, the repository of projects and staff Repository (Problems V1, V2, V3, M3). R4. Simple and constant access to information concerning to the components software (Problems N2 and N3). R5. It requires emailing the information updated or modified to the developers involved in the use of the component (Problems N1, N2 and N3).

V. FULFILLING THE REQUIREMENTS Once requirements have been defined, we proceeded to develop a prototype that meets these requirements. One of the programs used to design software is Microsoft Visio 2010 [10], which contains a set of tools for creating professional and intuitive diagrams. The proposed prototype is the creation of an Office complement that is integrated into the Visio 2010 application (see Fig. 2). When opening a document, it checks if the document is a component previously registered or part of one. If this component is registered it extracts information from the repository and displays it on an information view. This information view has two tabs: an Information tab that shows elements of related information from the accessed component (see Table III) and a Notification tab which is the one that contains a log of the changes performed on that component. Table III shows the relationship among of the proposed information elements and the repositories where the information is extracted. Further, in each information element is added the reference of the corresponding figure.

B

A

C F

D

E

G I

H J

K L M O

N P

Q

Fig. 2. The proposed Visio 2010 complement view

TABLE III. INFORMATION ELEMENTS OF THE PROPOSED VISIO 2010 COMPLEMENT VIEW. Repository Component Record

Version Control

Project Manager

Personal Record

Information element • Component Id (Fig. 2C) • Configuration Id of the component (Fig. 2E). • Type of the component in the development process (Fig. 2F). • Name of the component (Fig. 2G). • Component’s System Id (Fig. 2H). • Component’s description (Fig. 2J) • Link to the component’s Quick Guide (Fig. 2K). • Version ID of the component (Fig. 2D). • Overview of changes of the component (Fig. 2Q). • List of change notifications (Fig. 3). • Developer Identification (Fig. 2J) • Role (Fig. 2N) • Information about the projects where this component has been connected (Fig. 3). • Developer’s name (Fig. 2K) • Developer’s last name (Fig. 2L) • City of residence (Fig. 2M) • Personal Telephone (Fig. 2O) • Telephone extension (Fig. 2P)

Fig. 3 shows the Information tab that lists all the changes that have been generated about the changes made to the component. In order to explain how our prototype supports the presence of components in the software development group, in the next section we show an application

Fig. 3. Component View - Notification tab

scenario, which takes as a reference the actual scenario presented in section 3.

VI. PROJECTED SCENARIO When Delia makes the change to the system requirements document, the components’ presence system identifies that it is a registered component that is related to other components or artifacts of the system. Therefore, when the changes are made, a notification is sent to all those working on the project. Given that Germán is involved in the Project, a new

notification warning is shown on hiis taskbar (Fig. 4) thanks to the Component Notificattion System (Fig. 1). Next, Germán goes to the "com mplement view" in Microsoft Visio (Fig. 2A y 2B B), then to the notifications tab (Fig. 3) for innformation about changes, and becomes aware of thhe change to the requirements document made by Delia. This was possible using the "Componnents’ presence Notification" tool, resident as a com mplement view in Microsoft Visio. Germán gets contaact information of the author of the modification (e.g. phone extension, s in Fig. 5. location, information update), as shown Using this info, Germán immediateely communicates with Delia to learn more about the changes c that were applied. This way, Germán makes decisions quickly and works in a more conscious way of what is happening regarding the componentss.

Fig. 5. Notification innformation

updates the Component Inforrmation View. Finally, the actual data used to populatte the GUI components (e.g. component name, type, involved i user, etc.) are retrieved by the Client Interfa face from the dataview (SQLServer) through an HTTP H connection (IIS WebService). Fig. 4. Components’ Presence Notifi fication

VII. IMPLEMENTATION ASPECTS The current version of ouur prototype is implemented as a system applicattion in C# .NET 2010, which was embedded in i Visio as a complement.

It is important to menntion, that dataviews (SQLServer) retrieve the information i from the Human Resources Inform mation System, the Subversion system and Miccrosoft Project Server (Server Tool Support). Having established how the prototype was implemented, inn the following section we present the Conclusions.

It is worth mentioning that thiis implementation uses data from the project managem ment system [11] deployed in the company (see Fig. 6). 6 The Client automatically deetermines which component was recently edited on the client-side by listening to the OnChanged (Creattion, Change, and Delete) and OnRenamed (Rename) file events of the FileSystemWatcher class of the .NET Framework w application Class library, while it determines which and files are currently in use (receiiving focus at the user screen) by using the GetFooregroundWindow method from the Windows User32..dll (dynamic link library). The classpath of the file thhat is currently in use or has recently been modified is i then sent to the Notification Server by means of an HTTP-based mpared with the service. Once there, it is com information on the dataview (SQLServer) to determine whether the file is asssociated with a registered component. b determined, Once the component have been information about the participants involved is obtained and released from the datavview (SQLServer) concerning to component notificaation, notification history and update component. Thhis information is also automatically forwarded to the User Interface by means of an HTTP-based servicee, which in turn

Fig. 6. Architecturre diagram

ND FUTURE WORK VIII. CONCLUSIONS AN

The Component-based software engineering (CBSE) approach implies thaat components must be documented at an opportunne time, because the component information must be updated when the wever, in actual software developer has to reuse it. How production that is not practicall. This is due to the fact that software developers usually u lack technical

support to provide them certainty about the changes made to a component. In this work, our premise was to take advantage of existing explicit knowledge of workers in a software organization to facilitate the presence of components in a oportune manner. Our approach to cope with this was to make this kind of information available to developers by means of specialized gathering and distribution mechanisms from their development environment. Firstly, we identified which information topics, and their sources, were important to achieve the Components’ Presence Notification by means of an initial understanding about software production. Later, the identification of information flows obtained from the literature and from expert interviews allowed for the identification of problems, and possible solutions to the general problem, from where design insights were derived. Finally, based on these insights, an ensemble of information elements and gathering and presentation mechanisms were proposed to inform the development of a prototype that could improve the way in which developers initiate component maintenance. This is because they obtain information elements about the component at the specific moment. With this information they could estimate more precisely the degree of impact that would result in the modification of the component. We think that a notification about changes in the components offers the advantage of integrated information. However, currently the company has the problems of consulting a version control system, a project management tool and in some cases even the human resources system. This is due to the lack of information about changes to the components. Instead, our proposal offers to the developer a good perspective of the component in terms of existing versions, stakeholders who potentially could see, a quick guide to the how-to-use the component, among other information items. Concerning future work, the use of the Components’ Presence Notification is yet to be evaluated in a real situation. We plan to evaluate it by deploying the tool for a test trial of at least 4 weeks in a software group distributed in different cities of Mexico.

ACKNOWLEDGEMENTS This work has been funded by the GEODAS-BC project (Ministerio de Economía y Competitividad and Fondo Europeo de Desarrollo Regional FEDER, TIN2012-37493-C03-01). It is also supported by ORIGIN (IDI-2010043 (1-5)) funded by CDTI and FEDER, GLOBALIA (PEII11-0291-5274, Consejería de Educación y Ciencia, Junta de Comunidades de Castilla-La Mancha) and PEGASO/MAGO (Ministerio de Ciencia e Innovación MICINN and

FEDER, TIN2009-13718-C02-01) and by UABC under grant 207 of XIII Convocatoria Interna de Proyectos de Investigación. The first author was supported through P/PIFI-2012-26MSU0023H-06-02 Fortalecimiento de la capacidad académica y mejora de la competitividad académica de la DES Navojoa. It is also was partially supported by PROMEP under grant 103.5/11/3804 de la Convocatoria de Apoyo a la Reincorporación de Ex -becarios 2011 and by Programa de Apoyo y Fomento a la Investigación (PROFAPI).

REFERENCES [1] S. R. Schach, Object-Oriented and Classical Software Engineering, Sixth ed. USA, 2005. [2] R. S. Pressman, Software Engineering: A Practitioner's Approach 7th ed.: McGraw-Hill Science/Engineering/Math, 2009. [3] I. Jacobson, G. Booch, and J. Rumbaugh, The Unified Software Development Process 1st ed.: Addison Wesley, 1999. [4] P. Parra, O. R. Polo, M. Knoblauch, I. Garcia, and S. Sanchez, "MICOBS: multi-platform multi-model component based software development framework," presented at the Proceedings of the 14th international ACM Sigsoft symposium on Component based software engineering, Boulder, Colorado, USA, 2011. [5] U. Kumari and S. Bhasin, "A composite complexity measure for component-based systems," SIGSOFT Softw. Eng. Notes, vol. 36, pp. 1-5, 2011. [6] R. R. Palacio, A. L. Morán, V. M. Gonzalez, and A. Vizcaíno, "Selective availability: Coordinating interaction initiation in distributed software development," IET Software, vol. 6, pp. 224-231, 2012. [7] P. Vitharana, "Risks and challenges of component-based software development," Commun. ACM, vol. 46, pp. 67-72, 2003. [8] P. Štěpán, "Design pattern solutions as explicit entities in component-based software development," presented at the Proceedings of the 16th international workshop on Component-oriented programming, Boulder, Colorado, USA, 2011. [9] Anselm Strauss and J. Corbin, Basics of Qualitative Research: Grounded Theory Procedures and Techniques / A. Strauss, J. Corbin: Newbury Park, EUA : Sage, 1990. [10] office.com. (2010, October 3, 2012). Visio 2010. Available: http://office.microsoft.com/es-hn/visio/pagina-principal-devisio-2010-FX010048786.aspx [11] Microsoft_Project. (2010, October 25th, 2012). Project Server 2010. Available: http://www.microsoft.com/project/es/es/project-server2010.aspx