Towards a service-oriented measurement infrastructure - CiteSeerX

Published in the Proceedings of

Towards a service-oriented measurement infrastructure Martin Kunz, Andreas Schmietendorf, Reiner R. Dumke, Cornelius Wille

Abstract The importance of software measurement during the software development process is generally accepted, nowadays. Unfortunately, in practice common software measurement tools find small acceptance due to their high costs, inflexible structures, and therewithunclear cost/benefit ratio. On this account this paper introduces a framework creating a measurement infrastructure by means of a service-oriented architecture. For this approach the ISO/IEC 15939 standard has been proved to be meaningful. By using meta-models and ontologies, related services can be categorized and/or classified. Moreover, services can be bound flexibly with the aid of configuration defaults being referenced by the meta-model. Furthermore, we present a web-service based ontology aligned towards object-oriented metrics as an example for a service-oriented infrastructure component. Finally, an analysis about integration aspects presents a way to enhance the infrastructure with new functionality corresponding to the ISO/IEC 15393 standard.

Keywords Software Measurement, Service-oriented Architecture, ISO 15939, Metrics Ontology

1. Introduction The increasing economic relevance of software measurement for organisations cannot be neglected. But issues like complexity and missing traceability of measurement processes constitute the need for direction and guidance in this regard. That need could be satisfied by the development of the Practical Software Measurement (PSM) [1]. The main concepts of PSM provide a foundation for the international standard ISO/IEC 15939 [2]. The ISO/IEC 15939 Information Technology – Software Measurement Process helps to identify, define, select, apply, and improve software measurement in any software development project. This standard describes a compliant measurement process concerning its purposes and outcomes combined with appropriate activities and tasks. Thereby the core measurement process is divided in the sub-processes “plan” and “perform” taking the information needs as input, for example by using the Goal Question Metric approach [3] with the aid of appropriate business goals.

Figure 1: Scope of ISO/IEC 15939 standard [2]

197

Published in the Proceedings of

To date, the core measurement process can be facilitated by monolithic software measurement tools taking a set of metrics and the measurement object as input and producing measurements together with some kind of evaluation or analysis. Owing to high license costs of such monolithic and rigid measurement tools, the real benefit is hard to identify. Because of that the commercial application of software measurement seems to be increasable by using flexible infrastructures without high acquisition costs and with the possibility to tailor the functionality according to a project’s measurement information needs.

2. Service-oriented measurement infrastructure Based on the general characteristics of ISO/IEC 15939 a service-oriented measurement infrastructure with different services and components should be specified and implemented to realise the defined processes and activities [5]. To create such an infrastructure it is necessary to define the technology or the notation in which the different elements or specifications have to be implemented or described. In this way a level-based procedure was used as shown in figure 2.

Figure 2: Level-based infrastructure composition At first it is essential to describe the process model in a semantic manner to obtain a highlevel view of the entire measurement process and to enforce a standard compliant procedure. Therefore, we apply the Business Process Modelling Notation (BPMN) [8]. In doing so this representation describes all processes, sub-processes, properties, and sub-properties of ISO/IEC 15939. This process model is used to divide the complete measurement process into different architectural components. Furthermore, we use the BPMN to produce the business process diagram (figure 3) on the basis of the ISO/IEC 15939 process model.

198

Published in the Proceedings of

Figure 3: Business process diagram By using such representation one can derive the Business Process Execution Language (BPEL) by using BPEL4WS [8]. This Business Process Execution Language leads us to a key technology for realising service- oriented architectures: the web service orchestration [6]. As shown in figure 4 the orchestration process is used to build up new web services out of existing web services in a hierarchical manner. In the service-oriented infrastructure the web service orchestration is used for the composition of the ISO/IEC 15939 process out of the four sub-processes (“establish”, “plan”, “perform”, and “evaluate”) in the so-called Orchestration Process (OP).

199

Published in the Proceedings of

Figure 4: Orchestration versus Choreography [7] In this way the result of the orchestration process is four equitable sub-processes. One has to recognise that collaboration of the four sub-processes has to be performed in a peer-to-peer manner. Therefore, the different sub-processes are divided into four choreography processes (CP) [6]. The difference between orchestration and choreography means that orchestration refers to an executable process and choreography traces the message sequence between different sources [7]. Because of the fact that the choreography process implies the orchestration process, we define the orchestration process as the level 1 process and the choreography process as the level 2 process (see figure 5). By taking a closer look to the four sub-processes one has to identify which of the subprocesses can be executed by the presented infrastructure or which sub-processes can merely be supported by our infrastructure. In doing so, one has to ascertain that the “plan” subprocess will be the key process in a service-oriented measurement infrastructure. Because of that figure 5 describes a set of required components with a focus on the “plan” sub-process. The color of the component shows to which composition level (see figure 2) the distinct component belongs.

Figure 5: Fragment of the proposed infrastructure

200

Published in the Proceedings of

The semantic description as shwon in figure 2 is realised within a metrics ontology (see figure 5). In history ontologies possessed the capability to retain this semantic knowledge in a machine-accessable manner. Therefore, we use the ontology approach for a cataloging web system [10] to create our own ontology for a subset of metrics (object-oriented metrics). Thereby, the ISO/IEC 9126 product quality standard [4] is used to categorise the metrics. In general the ontology is used to connect an information need with a certain metric. That means that all metrics, which are calculated by an included measurement service, must be decribed within this ontology. At the moment we restrict our ontology to objectoriented metrics. The ontology scheme is illustrated in figure 6 by using the Unified Modelling Language (UML) [11].

Figure 6: Object-oriented Metrics Ontology [12]

201

Published in the Proceedings of

3. Technical background for the level 2 choreography process “plan” After presenting the plannend architecture we will describe the building blocks for implementing the different components to obtain an infrstructure to perfom sub-process “plan”. The “plan” process is part of the ISO/IEC 15939 core measurement process [2]. This subprocess takes the information need as an input and describes several activities among others, for instance “characterize the organisational unit”, “acquire supporting technologies”, and “approve measurement tasks” [5]. As shown in figure 5 the “plan” process should result in a service-oriented measurement architecture, which can then perform a certain measurement task. So the resulting measurement tool is tailored according to the information needs.

3.1. Search and integration process for measurement services To realise the components for the service directory and measurement service integration we choose the approach of a SOA-Service-Centre [9]. Such a service centre supports different tasks and implies the use of already existing tools and new approaches. It provides several functionalities like a directory about all available services, descriptions for provided interfaces, and informations about existing service compositions. A second important information in this concrete use case aims at the metrics that a distinct measurement service supports. In addition, one can add Meta information about the provided services in such a service centre, for example sequence relationships or expected quality behaviour. But more important for building up an infrastructure are the provided search functionalities. Therefore, the service centre offers functionalities like runtime search, criteria-based search, and information where the services already have been used [9].

SOA Service Center

Registry

MQ WebSphere: IP-Adressen, QueueManager & -Name

Web Service: URL

...

...

Web Service: WSDL

...

...

Service Interface MQ WebSphere: XML-Schemata

Service Specification Non Standard description formats

Web Services: UDDI

Standard description format

Search Engine

Service Endpoint

...

SLA Management

Availabilty Management

Security Management

QoS Measurement

Billing Support

Version Management

Choreography Management

Negotiation Management

Figure 7: SOA Service Centre

202

Certification

Management

Visualisierung & Animation

Published in the Proceedings of

3.2. Selection factors for measurement services Having introduced a component for searching and managing services we come to the next key process to build a service-oriented architecture: the procedure to select certain services according to a project’s measurement information needs. Probably the most important question is whether a metric can satisfy the information needs or not. Therfore we have implemented the Object-oriented Measurement Ontology (OOMO) [12] of the ontology scheme presented in figure 6. This ontology is realised as a web-service and a key part of the service-oriented measurement infrastructure.

Figure 8: Object-oriented Measurement Ontology [12] The second important question addresses the security of measurement services. Logically, no user will accept that his measurement objects become public. Therefore, it is necessary that the integration architecture is able to ensure that the web services that are being used to build the measurement infrastructure are compliant to the security policy of the concrete environment. On this account we use the Web Service Security framework that describes how to incorporate security technologies (e.g. Kerberos [14]) into web services by defining a place for them within the SOAP headers [13]. The WS-Security specification targets message alteration by including digital signatures and message disclosure by supporting message encryption, while it can also be used to authenticate messages through the use of Kerberos [13].

203

Published in the Proceedings of

Two other selection factors (performance and costs) will be realised by the use of Quality of Service Measurement [15] and Billing Support by the Service Centre as shown in figure 7. An implementation of a web service measurement tool which forms a key component of a Service Centre has already been presented in [16].

Figure 9: Web Services Measurement Service [16] In conclusion, one can identify four major selection factors, namely information value, security, performance, and costs. A service-oriented measurement infrastructure has to take into account at least these four selection factors. As shown above the functionality to realise the infrastructure can also be contained in components.

3.3. Resources for a service-oriented measurement infrastructure The focus of this paper is not to present as much measurement services as possible rather than describe a model for the integration of existing measurement services to a measurement infrastructure. But to clarify how measurement services work, two examples of measurement services are presented in the following.

204

Published in the Proceedings of

The Open Office Activity Sensor [17] is intended to measure different functionalities (e.g. open a file, save a file) that a user can use within Open Office [19]. This type of measurement tool can measure all activities of a development process using Open Office as an integrated development environment (IDE). To realise the implementation the HackyStat framework [18] was used to create this measurement service, using the Simple Object Access Protocol (SOAP), which facilitates a simple integration into service-oriented software measurement architecture.

Figure 10: Open Office Activity Sensor [17] The implementation using SOAP does not mean that a resource has to be implemented with SOAP. Distinct interface specifications make it possible to use, for example .NET. Besides this process-oriented measurement, software products can also be measured with distinct resources. An example is the “Object-oriented measurement of Java Technologies” (OOMJ) [20]. OOMJ is a software measurement web service designed to reliably compute Chidamber & Kemerer and MOOD metrics for any Java library or application and provides an efficient graphical analysis of the obtained results. It is unique in being freely available online and providing the metrics results in a portable (XML) format for further customized analysis or otherwise use [20].

Figure 11: Object-oriented measurement of Java Technologies [20]

205

Published in the Proceedings of

4. Conclusion and Future Work This paper has introduced a first draft of a service-oriented measurement infrastructure intended to create a flexible measurement tool tailored to a certain project’s information needs or project requirements. This service-oriented approach creates a framework including semantic knowledge, an integration concept, and a lot of potential resources to create an architecture that is able to realise an ISO/IEC 15939 measurement process. An increasing number of SOA-capable measurement services and accordingly the integration of existing measurement tools can increase the functional range nearly to no limits. In this way the concept provides a standard compliant procedure, supports measurement automation and distributed measurement and avoids new measurement tool development by creating tailored measurement service sets. This implies furthermore new license models and accounting methods for the use of measurement functionalities deliviered by measurement tool providers. Future research should consider the following points: • Enhancement of process and metrics ontologies. • Analysis of integration opportunities for existing measurement tools. • Extension of the architecture concerning ISO/IEC 15939 sub-processes “perform” and “evaluate”. • Guidline for measurement tool providers to support SOA-Capabilities. • Promote the development of measurement services rather than proprietaer measurement tools.

5. References [1]

McGarry, J.; Card, D.; Jones, C.; Layman, B.; Clark, E.; Dean, J. & Hall, F. “Practical space Software Measurement: Objective Information for Decision Makers” Addison-Wesley, space 2001 [2] ISO/IEC, “ISO 15939 --- Information Technology --- Software Engineering --- space space Software Measurement Process” 2001 [3] Basili, V.; Caldiera, G. & Rombach, H.D.”Encyclopaedia of Software Engineering The space Goal Question Metric Approach” John Wiley & Sons, Inc, 1994 [4] ISO/IEC 9126-1:2001 --- Software engineering -- Product quality -- Part 1: Quality model, 2001 [5] Dumke, R., Braungarten, R., Kunz, M., Hegewald, H. “An ISO 15939-Based space space Infrastructure Supporting the IT Software Measurement”, Proc. of the MetriKon 2005, space Kaiserslautern 2005 [6] Erl, T. “Service-Oriented Architecture Concepts, Technology, and Design” Prentice space Hall, 2005 [7] Peltz, C. “Web Services Orchestration and Choreography”, Computer, 2003 [8] OMG (Object Management Group), “Business Process Modeling Notation (BPMN) space Final Adopted Specification”, 2005 [9] Schmietendorf, A., Dimitrov, E. “Implementation of services-oriented infrastructures by the use of a Service Centre” Proc. of the 2nd International Workshop on eServices and eLearning, Plovdiv 2004 [10] Martin, M., Olsina, L. “Towards an Ontology for Software Metrics and Indicators as the Foundation for a Cataloging Web System”. 2003 [11] Wang, X., Chan, C. “Ontology Modeling Using UML” Proc. of the 7th International space Conference on Object Oriented Information Systems, 2001

206

Published in the Proceedings of

[12] Weise, E. “Konzeption und prototypische Realisierung einer Web-Service basierten space Ontology objektorientierter Metriken” Diplomarbeit, Otto-von-Guericke Universität space Magdeburg, 2006 [13] Newcomer, E., Lomow, G. “Understanding SOA with Web Services” Addision space space Wesley, 2003 [14] MIT (Massachusetts Institute of Technology) Kerberos: The Network Authentication space Protocol, http://web.mit.edu/kerberos/ 2005 [15] Schmietendorf, A., Dumke, R. “A Measurement Service for Monitoring the Quality space Behaviour of Web Services offered within the Internet” Shaker Publ. Proc. of the space space IWSM/MetriKon 2004 [16] Schmietendorf, A.,Rud,D. “Performanceaspekte choreographierter Anwendungen auf space Basis lose gekoppelter Web Services”, Proc. of the 6th Workshop „Performance space space Engineering in der Softwareentwicklung“ (PE 2005), 2005 [17] Ullwer, C. “Konzeption und prototypische Realisierung einer Telemetrie-basierten MessArchitektur“ Diplomarbeit, Otto-von-Guericke Universität Magdeburg, 2006 [18] Johnson, P.M.; Kou, H.; Paulding, M.; Zhang, Q.; Kagawa, A. & Yamashita, T. space space “Improving Software Development Management through Software Project Telemetry” space IEEE Software, 2005 [19] OpenOffice, http://www.openoffice.org/, 2006 [20] Farroq, A. “Conception and Prototypical Implementation of a Web Service as an space space Empirical-based Consulting about Java Technologies” Masterthesis, University of space Magdeburg, 2005

207