Formal Foundations of Reuse and Domain Engineering: 11th International Conference on Software Reuse, ICSR 2009, Falls Church, VA, USA, September ... Programming and Software Engineering)

Lecture Notes in Computer Science Commenced Publication in 1973 Founding and Former Series Editors: Gerhard Goos, Juris Hartmanis, and Jan van Leeuwen

Editorial Board David Hutchison Lancaster University, UK Takeo Kanade Carnegie Mellon University, Pittsburgh, PA, USA Josef Kittler University of Surrey, Guildford, UK Jon M. Kleinberg Cornell University, Ithaca, NY, USA Alfred Kobsa University of California, Irvine, CA, USA Friedemann Mattern ETH Zurich, Switzerland John C. Mitchell Stanford University, CA, USA Moni Naor Weizmann Institute of Science, Rehovot, Israel Oscar Nierstrasz University of Bern, Switzerland C. Pandu Rangan Indian Institute of Technology, Madras, India Bernhard Steffen University of Dortmund, Germany Madhu Sudan Microsoft Research, Cambridge, MA, USA Demetri Terzopoulos University of California, Los Angeles, CA, USA Doug Tygar University of California, Berkeley, CA, USA Gerhard Weikum Max-Planck Institute of Computer Science, Saarbruecken, Germany

5791

Stephen H. Edwards Gregory Kulczycki (Eds.)

Formal Foundations of Reuse and Domain Engineering 11th International Conference on Software Reuse, ICSR 2009 Falls Church, VA, USA, September 27-30, 2009 Proceedings

13

Volume Editors Stephen H. Edwards Department of Computer Science Virginia Tech Blacksburg, VA, USA E-mail: [email protected] Gregory Kulczycki Department of Computer Science Virginia Tech, Northern Virginia Center Falls Church, VA, USA E-mail: [email protected]

Library of Congress Control Number: 2009934448 CR Subject Classification (1998): D.2.13, D.2, D.3, D.1, D.3.3 LNCS Sublibrary: SL 2 – Programming and Software Engineering ISSN ISBN-10 ISBN-13

0302-9743 3-642-04210-4 Springer Berlin Heidelberg New York 978-3-642-04210-2 Springer Berlin Heidelberg New York

This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. springer.com © Springer-Verlag Berlin Heidelberg 2009 Printed in Germany Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India Printed on acid-free paper SPIN: 12752911 06/3180 543210

Preface

ICSR is the premier international conference in the field of software reuse. The main goal of ICSR is to present the advances and improvements within the software reuse domain, as well as to promote interaction between researchers and practitioners. The 11th International Conference on Software Reuse (ICSR 2009) was held during September 27–30, 2009 in Falls Church, VA, USA. 2009 was the year that ICSR went back to its roots. The theme was “Formal Foundations of Reuse and Domain Engineering.” We explored the theory and formal foundations that underlie current reuse and domain engineering practice and looked at current advancements to get an idea of where the field of reuse was headed. Many of the papers in these proceedings directly reflect that theme. The following workshops were held in conjunction with ICSR 2009: – – – –

Second Workshop on Knowledge Reuse (KREUSE 2009) RESOLVE 2009: Software Verification – the Cornerstone of Reuse First International Workshop on Software Ecosystems International Workshop on Software Reuse and Safety (RESAFE 2009)

Aside from these workshops and the papers found here, the conference also included five tutorials, eight tool demos, and a doctoral symposium. Links to all of this information and more can be found at the ICSR 11 conference website at icsr11.isase.org. September 2009

Stephen Edwards Gregory Kulczycki

VI

Preface

Welcome Message from the General Chairs Welcome to ICSR11. This conference began as an International Workshop on Software Reuse in 1991, and became a full conference in 1994. ICSR is currently managed by the ISASE International Society for the Advancement of Software Education. The ISASE website—www.isase.us—contains information about past ICSR proceedings and is a good place to check for future ICSRs. September 2009

John Favaro Bill Frakes

Organization

General Chairs Program Chairs Demos Chair Tutorials Chair Workshops Chair Doctoral Symposium Chair Corporate Donations Chairs

John Favaro (INTECS, Italy) and Bill Frakes (Virginia Tech CS, USA) Stephen Edwards (Virginia Tech CS, USA) and Greg Kulczycki (Virginia Tech CS, USA) Cl´audia Werner (Federal University of Rio de Janeiro Brazil) Stan Jarzabek (National University of Singapore) Murali Sitaraman (Clemson University CS, USA) Jason Hallstrom (Clemson University CS, USA) Asia – Kyo Kang (Pohang University, Korea) South America – Cl´ audia Werner (Federal University of Rio de Janeiro, Brazil) Europe – Jaejoon Lee (University of Lancaster, UK) and Davide Falessi (University of Rome Tor Vergata, Italy) US – Okan Yilmaz (NeuStar Inc., USA)

Program Committee Colin Atkinson Don Batory Ted Biggerstaff Martin Blom Cornelia Boldyreff Steve Edwards Davide Falessi John Favaro Bill Frakes Jason Hallstrom Stan Jarzabek Kyo Kang Greg Kulczycki Jaejoon Lee Chuck Lillie Wayne Lim Juan Llorens Brian Malloy Hong Mei

University of Mannheim, Germany University of Texas Austin, USA Software Generators, USA Karlstad University, Sweden University of Lincoln, UK Virginia Tech, USA University of Rome Tor Vergata, Italy INTECS, Italy Virginia Tech, USA Clemson University, USA National University of Singapore, Singapore Pohang University, Korea Virginia Tech, USA University of Lancaster, UK ISASA, USA Infosys, USA University of Madrid Carlos III, Spain Clemson University, USA Peking University, China

VIII

Organization

Maurizio Morisio Dirk Muthig Jefferey Poulin Ruben Prieto-Diaz Michael (Eonsuk) Shin Alberto Sillitti Murali Sitaraman Bruce Weide Cl´audia Werner Okan Yilmaz

Politecnico di Torino, Italy Fraunhofer IESE, Germany Lockheed, USA University of Madrid Carlos III, Spain Texas Tech University, USA University of Bolzano, Italy Clemson University, USA Ohio State University, USA Federal University of Rio de Janeiro, Brazil NeuStar Inc., USA

Sponsoring Institutions Virginia Tech, Falls Church, VA, USA International Society for the Advancement of Software Education, USA National Science Foundation, USA Software Generators, USA Reuse Software Engineering, Brazil Pohang University of Science and Technology, Korea

Table of Contents

Component Reuse and Verification Consistency Checking for Component Reuse in Open Systems . . . . . . . . . Peter Henderson and Matthew J. Henderson

1

Generating Verified Java Components through RESOLVE . . . . . . . . . . . . . Hampton Smith, Heather Harton, David Frazier, Raghuveer Mohan, and Murali Sitaraman

11

Increasing Reuse in Component Models through Genericity . . . . . . . . . . . . Julien Bigot and Christian P´erez

21

Verifying Component-Based Software: Deep Mathematics or Simple Bookkeeping? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jason Kirschenbaum, Bruce Adcock, Derek Bronish, Hampton Smith, Heather Harton, Murali Sitaraman, and Bruce W. Weide

31

Feature Modeling Extending FeatuRSEB with Concepts from Systems Engineering . . . . . . . John Favaro and Silvia Mazzini

41

Features Need Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sidney C. Bailin

51

An Optimization Strategy to Feature Models’ Verification by Eliminating Verification-Irrelevant Features and Constraints . . . . . . . . . . . Hua Yan, Wei Zhang, Haiyan Zhao, and Hong Mei

65

Reusable Model-Based Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Erika Mir Olimpiew and Hassan Gomaa

76

Generators and Model-Driven Development A Case Study of Using Domain Engineering for the Conflation Algorithms Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Okan Yilmaz and William B. Frakes

86

Model Transformation Using Graph Transactions . . . . . . . . . . . . . . . . . . . . Leila Ribeiro, Luciana Foss, Bruno da Silva, and Daltro Nunes

95

Refactoring Feature Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Martin Kuhlemann, Don Batory, and Sven Apel

106

X

Table of Contents

Variability in Automation System Models . . . . . . . . . . . . . . . . . . . . . . . . . . . Gerd Dauenhauer, Thomas Aschauer, and Wolfgang Pree

116

Industry Experience A Case Study of Variation Mechanism in an Industrial Product Line . . . Pengfei Ye, Xin Peng, Yinxing Xue, and Stan Jarzabek Experience Report on Using a Domain Model-Based Extractive Approach to Software Product Line Asset Development . . . . . . . . . . . . . . . Hyesun Lee, Hyunsik Choi, Kyo C. Kang, Dohyung Kim, and Zino Lee Reuse with Software Components - A Survey of Industrial State of Practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rikard Land, Daniel Sundmark, Frank L¨ uders, Iva Krasteva, and Adnan Causevic

126

137

150

Product Lines Evaluating the Reusability of Product-Line Software Fault Tree Analysis Assets for a Safety-Critical System . . . . . . . . . . . . . . . . . . . . . . . . . Josh Dehlinger and Robyn R. Lutz

160

Feature-Driven and Incremental Variability Generalization in Software Product Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Liwei Shen, Xin Peng, and Wenyun Zhao

170

Identifying Issues and Concerns in Software Reuse in Software Product Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Meena Jha and Liam O’Brien

181

Reuse of Architectural Knowledge in SPL Development . . . . . . . . . . . . . . . Pedro O. Rossel, Daniel Perovich, and Mar´ıa Cecilia Bastarrica

191

Reuse and Patterns Introducing Motivations in Design Pattern Representation . . . . . . . . . . . . Luca Sabatucci, Massimo Cossentino, and Angelo Susi

201

The Managed Adapter Pattern: Facilitating Glue Code Generation for Component Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Oliver Hummel and Colin Atkinson

211

Reusing Patterns through Design Refinement . . . . . . . . . . . . . . . . . . . . . . . . Jason O. Hallstrom and Neelam Soundarajan

225

Table of Contents

XI

Service-Oriented Environments Building Service-Oriented User Agents Using a Software Product Line Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ingrid Nunes, Carlos J.P. de Lucena, Donald Cowan, and Paulo Alencar

236

DAREonline: A Web-Based Domain Engineering Tool . . . . . . . . . . . . . . . . Raimundo F. Dos Santos and William B. Frakes

246

Extending a Software Component Repository to Provide Services . . . . . . Anderson Marinho, Leonardo Murta, and Cl´ audia Werner

258

A Negotiation Framework for Service-Oriented Product Line Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jaejoon Lee, Gerald Kotonya, and Daniel Robinson

269

Ranking and Selecting Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alberto Sillitti and Giancarlo Succi

278

A Reusable Model for Data-Centric Web Services . . . . . . . . . . . . . . . . . . . . Iman Saleh, Gregory Kulczycki, and M. Brian Blake

288

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

299

Consistency Checking for Component Reuse in Open Systems Peter Henderson1 and Matthew J. Henderson2 1

Electronics and Computer Science, University of Southampton, Southampton, UK [email protected] 2 Mathematics and Computer Science, Berea College, Berea, KY 40404, USA matthew [email protected]

Abstract. Large scale Open Systems are built from reusable components in such a way that enhanced system functionality can be deployed, quickly and effectively, simply by plugging in a few new or revised components. At the architectural level, when new variations of a system are being planned by (re)configuring reusable components, the architecture description can itself become very large and complex. Consequently, the opportunities for inconsistency abound. This paper describes a method of architecture description that allows a significant amount of consistency checking to be done throughout the process of developing a system architecture description. An architectural design tool is described that supports consistency checking. This tool is designed to support component reuse, incremental development and collaborative working, essential for developing the architecture description of large systems.

1 Introduction Systems Architecture is that branch of Information System design that determines the overall structure and behaviour of a system to be built. Typically, an architecture is captured as an evolving set of diagrams and specifications, put together by a team of System Architects and iteratively refined over a period of consultation with the customers for the solution. The extent to which the architecture represents a buildable or procurable solution depends a great deal on the consistency and completeness of the architecture description and the extent to which it can be validated prior to commitment to procure. Validation of the architecture as early as possible in the process of development is important. This aspect of System Engineering is not well supported by tools. In this paper we advocate an approach to architecture description that lends itself to validation throughout architecture development. Open Systems have modular, or component-based, architectures based on a catalogue of reusable components with publicly maintained interfaces. Devising a new configuration involves selecting reusable components from the catalogue, devising new ones or variations of existing ones, and plugging them together according to the architecture description. Opportunities for inconsistent reuse of existing components are particular pitfalls which need to be avoided eventually, but which need, for pragmatic S.H. Edwards and G. Kulczycki (Eds.): ICSR 2009, LNCS 5791, pp. 1–10, 2009. c Springer-Verlag Berlin Heidelberg 2009 

2

P. Henderson and M.J. Henderson

reasons, to be tolerated during design and development of a complex architecture description. The key idea is that the architects define a metamodel that enumerates the types of entities they are going to use in their description, along with the relationships between these entities. For example, as in this paper, they might choose to describe their architecture in terms of components and interfaces. As part of the metamodel, the architects will also specify constraints which a valid description must satisfy. Validation of the architecture description comprises checking the extent to which these constraints are satisfied. We have developed a tool, WAVE, to support this approach [1].

2 Background In Systems Engineering, in particular for software intensive systems, the design of a solution is normally developed around a system architecture.The description of this architecture is a shared model around which the architects work to understand the customer requirements and how these can be mapped on to programs and databases to realise a solution. The field of architecture description is now relatively mature [2,3,4,5,6,7,8]. Specific approaches to architecture description have, in many respects, found their way into standard representations such as UML [9] and SysML [10], so it is now quite common to find these notations in use in industrial projects. There are other approaches to architecture description [11,12,13,14,15,16,17,18,19,20,21,22] but these are generally ideas that are readily adopted as specialisations of the standard notations. Indeed, the Model Driven Architecture approach to system development [23] effectively assumes that a notation needs to be open to extension and specialisation. The need for architects to share a model, and for this model to evolve, immediately introduces the realisation that for most of its life the architecture description will be incomplete and probably inconsistent. Looking for inconsistencies in the architecture description is the principal means of validating it early in its life [24,25,26,12,27]. The research reported here builds on those ideas. In particular, like others, we take an approach to architecture description based on relational models [11,24]. We capture the details of an architectural description in UML or SysML, but support this with a precise specialised metamodel that has been expressed relationally. This means that we can capture the consistency constraints very precisely in relational algebra [28,29] and formally validate the metamodel as we develop the architecture description. The consequences for the research reported here are that we have a method of capturing an architectural metamodel, of capturing an architecture according to this metamodel in UML and a means of presenting that architecture for consistency checking throughout its life. We claim that this method (and our tool) supports component reuse, incremental development and collaborative working, for which we will give evidence in a later section. In order to describe the method, we begin with an example of architecture description based on UML Component diagrams.

Consistency Checking for Component Reuse in Open Systems

3

IA P

IA IB

IB

A

B IC

IC

Fig. 1. A consistent structure

3 Components and Interfaces Large scale Open Systems benefit from having their architecture described using Component diagrams in UML. These diagrams use Components to denote units of functionality and they use Interfaces to show how these units are plugged together to form assemblies with greater functionality. Components often denote quite substantial units of functionality (such as web servers, database servers etc.). Moreover, in large Open Systems there will often be dozens or hundreds of these replaceable components of various sizes and in many versions. Figure 1 shows a (simplified) Component diagram in which we see that Component P has nested within it two further components A and B. Strictly speaking, because it shows nesting, this is actually an example of a UML 2.0 Composite Structure diagram [9], where that diagram has been specialised to show nesting of Components. The interfaces in Figure 1 are shown by the ball-and-socket notation. For example Component A shows that it requires an Interface IB by its use of a socket with that label. Fortunately, also nested within Component P is a Component B which supplies such an interface, shown by the ball with that label. Normally, in a UML 2.0 diagram, this association between requires and supplies would be shown by an arrow from one to the other. Rather than do that here, since our diagrams are so simple, we have relied upon the reader’s ability to associate the two Components through their reference to an Interface by name. We see that all the components in Figure 1 supply or require interfaces. Normally, a component will both require and supply many interfaces, not just one of each as shown in this simple example. We say that the example in Figure 1 is consistent because all of the interface requirements are satisfied. The fact that Component B requires Interface IC is satisfied by this being brought to the outside and shown as a required interface on the parent P. Similarly, that Component P supplies Interface IA is satisfied by the fact that it contains a nested Component A which is the source of this interface. In contrast Figure 2 shows an inconsistent Component diagram. This time Component Q contains Components A and D which leads to some mismatches. Most obviously, we see that Component A, in this context, does not have its requirement for Interface IB satisfied, because there is no sibling that supplies that interface, nor has it been brought to the outside and made a required interface of the parent Q. We refer to this missing connection as dangling requires. We say that, within Component Q there is a danglingrequirement for Interface IB.

4

P. Henderson and M.J. Henderson IX

IA

Q

IA ID

IB

A

D IC

IC

Fig. 2. An inconsistent structure

Moreover Figure 2 shows an example of what we will call a dangling supplies. This is because Component Q supplies Interface IX but that is not one of the available interfaces supplied by one of its nested members. Again, note that this is a consistency constraint which is specialised from the metamodel that we are adopting and this will be explained later. Further, while we say that Component Q has a dangling-supplies of Interface IX, we do not consider the unused Interface ID of Component D to be a problem (again, a decision of the specialised metamodel). So far, what we have presented is an example of the type of Architecture Description that we advocate. It is based on a metamodel that we will introduce in a little while. The metamodel determines what types of entities will be described (here Components and Interfaces) and the consistency constraints that they must satisfy. In general, the metamodel will be defined by the Systems Architects for the specific system being designed and may use quite different entities and/or consistency constraints. We will discuss other metamodels later but first we will show how this one is formalised.

4 Specialised Metamodels Consider the way in which components and interfaces are conventionally described in a design notation such as UML or in a programming language such as Java or Python. A component will normally supply a number of interfaces and also make use of a number of interfaces supplied by other components. Figure 3 shows the entities and relations introduced by this description. It is the beginning of the metamodel against which we will check our system descriptions. The rest of the metamodel comprises the consistency constraints among these entities. Of course, this simple metamodel also needs to be extended with additional entities to be sufficiently useful in practice and these entities in turn will require further constraints. We will formalise the constraints that a correct design must obey in terms of the basic relations shown on the metamodel diagram. We denote the (natural) join operator of two relations by a dot (as for example in Alloy [30]). It forms the relational composition of its operands. Thus, for example contains.requires

denotes a binary relation formed from the composition (join) of two existing binary relations. That is, contains.requires denotes the relationship between Components and

Consistency Checking for Component Reuse in Open Systems

5

contains supplies Component

Interface requires

Fig. 3. A metamodel

Interfaces that we would describe as “Component c contains an unnamed Component that requires Interface i” . It is worth noting at this point that this focus on the whole-relation, leads to a holistic approach to the analysis of Systems Architectures, which is something we will return to in the section on Pragmatics. It is almost always the case that our relations are manyto-many. The relational algebraic approach affords a way of “reading-off” the diagram the derived relations that will be constructed as consistency rules in our metamodel. The way in which one uses relational algebra, as we will illustrate in the next section, is to construct predicates and challenge the consistency checker to construct the set of entities that fail to pass the test.

5 Consistency and Completeness The Architecture Description technique that we advocate assumes that the System Engineer will specify a metamodel and record the design against that metamodel. The metamodel will comprise entities, relationships and constraints. This section describes two such metamodels, shown respectively in Figure 3 and Figure 4. We develop consistency constraints that, according to the System Engineer who designed these metamodels, are among those that need to be satisfied if the Architecture being described is to be consistent. We also address a notion of completeness. We will assume that during development of the Architecture Description, interim models will not be consistent. The consequence for us here is that the constraints will be specified as sets of inconsistencies. The designer’s eventual objective is to achieve a design in which these sets of inconsistencies are eliminated. This approach to design supports both incremental and cooperative working. 5.1 Dangling Requires As a first example of a consistency rule, let us define the example we discussed in an earlier section, dangling-requires. Using the relations and entities illustrated in Figure 3 we can construct the relation dr as follows dr = contains.requires - contains.supplies - requires

Here, in addition to using relation join (composition) denoted by dot, we have used set difference, denoted by minus. This expression defines a relation dr which relates Components to Interfaces. The relation contains.requires contains all pairs (c,i) with the property that c contains a Component that requires i. Similarly contains.supplies contains all pairs (c,i) with the property that c contains a Component that supplies i.

6

P. Henderson and M.J. Henderson

contains supplies Component

Interface requires

derivedFrom implements tests Requirement

TestCase

Fig. 4. An extended metamodel

Thus the difference of these two relations contains all pairs where c’s requirement for i is not satisfied internally. Finally, by then constructing the difference between this set and the relation requires, we have that dr is the relation between Components c and Interfaces i, where c contains a nested Component that requires i but where that Interface is neither supplied internally nor required by the parent. This is exactly what we meant by dangling-requires. Constructing the relation dr has two benefits. First we have accepted that during development a design will be inconsistent and have decided to derive at any point in time a set of inconsistencies that the designer will eventually wish to remove. Second, by constructing a relation, we have taken a holistic approach, addressing the whole architecture description with our analysis rather than just looking at local inconsistencies. 5.2 Dangling Supplies We described informally, earlier, what we mean by dangling supplies. Formally, in terms of our metamodel we can specify this as follows ds = dom(contains) * s function IsEmpty (restores s: Stack) : control ensures IsEmpty = (s = empty_string) end StackTemplate

(c) Stack Reverse Contract

(b) Stack Contract Fig. 1. Stack Example

Our classification of the difficulty of the proof requirements of VCs is presented in Fig. 2(a). Note that the categories (i.e., sets of VCs) in Fig. 2(a) have a natural structure. The L category is a subset of every other category. Each LHi is a subset of LHi+1 , each MHi is also a subset of MHi+1 , and each DHi is a subset of each DHi+1 . Finally, each LHi is a subset of MHi ; also, each MHi is a subset of DHi . This structure forms a lattice shown in Fig. 2(b). Our methodology for analyzing the RESOLVE component catalog is to instrument an in-house VC prover, SplitDecision, to analyze each proven VC to

36

J. Kirschenbaum et al.

Label What is needed in the proof L Rules of mathematical logic Hn At most n hypotheses from the VC needed (n > 0) M Knowledge of mathematical theories used in the specifications D Knowledge of programmer-supplied definitions based on mathematical theories above (a) VC Classification

DH2 MH2 LH2

DH1 MH1 LH1

D M L

(b) Lattice of the VC categorization

Fig. 2. Table of VC Categorization and Diagram of Category Relationships

determine the “lowest” category the VC is in. We do this by checking if the goal is a tautology, checking to see how many hypotheses are needed in the proof, etc. The automatic nature of this can only guarantee we find an upper bound for any VC. For example, a particular VC categorized as MH1 might in fact be M or LH1 , but certainly not MH2 or DH1 . For VCs that are true but are not proven automatically (12.5% of VCs in the study), we manually examine those VCs to determine the category. Figure 3 shows a VC that falls ⇒ reverse(s0 ) ∗ Λ = reverse(s0 ) ∗ Λ into the L category. Its proof relies Fig. 3. Example from category L only on an axiom of first order logic with equality: ∀x.x = x. We note that VCs of type L are the “most obvious” kind: no knowledge of the underlying mathematical theory nor even any of the hypotheses of the VC are needed to establish the goal. Any rigorous, technical definition of “obvious” should include all VCs of this type. s2  =Λ A VC that falls into an LHn ∧ reverse(s ) ∗ tmp = reverse(s ) 2 2 0 ∗Λ category is given in Fig. 4. More ∧ |s 2| ≥ 0 specifically, we label this VC as LH1 ∧ is initial(x 3) because it is provable by noting sim⇒ s =  Λ 2 ply that the goal is one of the hypotheses. LH1 VCs clearly should be Fig. 4. Example from category LH1 considered “obvious,” whereas other LHn VCs may or may not be obvious, depending on the amount of logical deduction necessary to actually establish the implication. A VC in category M is given in |s2 | ≥ 0 Fig. 5. This VC depends only on the ⇒ s0  = Λ → |s0 | > 0 validity of the goal in the underlying mathematical theory. In this case, Fig. 5. Example from category M the goal is a direct consequence of

Verifying Component-Based Software

37

a useful theorem in the mathematical theory of strings; it can be derived using the proof rules of first order logic, plus the theory of integers to account for 0 and >. If the theorem is known and available, then this VC is surely obvious. If not, it might seem obvious to humans on semantic grounds, but a symbolic proof is several steps long. Finally, in Fig. 6 we include a ...[9 irrelevant hypotheses] VC from an implementation of the ∧ n 0 ∗ m0 = n3 ∗ m3 + p 3 well-known Egyptian multiplication ∧ m3 = m 8 + m 8 ∨ m3 = m8 + m8 + 1 algorithm to illustrate the D cat∧ IS ODD(m3 ) egory. Its proof requires three hy⇒ n0 ∗ m0 = (n3 + n3 ) ∗ m8 + p3 + n3 potheses. Without knowledge of the programmer-supplied definition of Fig. 6. Example from category DH3 IS ODD—either an expansion of the definition or the algebraic properties thereof—the VC cannot be proven. The distinction between the D and M categories is based on the current state of the components. As more MH5 4 theories are developed it is possible DH4-7 0.5% that programmer-supplied definitions 4 0.4% are moved into the mathematical theories because of their general utility. MH4 However, it is also clear that there will DH3 26 always be examples of mathematical def9 3.0% 1.0% initions that are programmer-supplied, for example the format of a particular type of input file. MH3 37 4.3%

4 Analysis of Verification Conditions The VCs analyzed for the paper are generated from roughly fifty components that comprise a total of roughly two thousand lines of source code. The code ranges from simple implementations of arithmetic using unbounded integers, to sorting arbitrary items with arbitrary orderings, and includes classical code such as binary search using bounded integers. Figure 7 shows classification data for all VCs generated from a sample catalog of RESOLVE component client code that relies on existing, formally-specified components to implement extensions,

LH2 2 0.2%

DH2 5 0.6% MH2 84 9.7%

LH1 78 9.0%

MH1 222 25.7%

DH1 2 0.2%

D 2 0.2%

M L 183 21.2%

207 23.9%

Fig. 7. VCs as categorized

38

J. Kirschenbaum et al.

which add additional functionality (e.g., the aforementioned Stack Reverse). Here, the area of each bubble in the lattice is proportional to the fraction of the 865 VCs that fall into that category. The number and percentage of all VCs falling into each category is shown in or near its bubble. Several interesting features are exhibited in Fig. 7. First, over 30% of the VCs can be proved without the use of any mathematics or more than one hypothesis. Moreover, over 75% of the VCs can be proved using no more than general mathematical knowledge along with at most one hypothesis. However, programmer-supplied definitions do tend to result in more sophisticated proofs; more hypotheses tend to be needed than in the general case. It is rare for a VC to require only a programmer-supplied definition. The programmersupplied definitions tend to encapsulate complexity; this complexity is apparent from the larger number of hypotheses needed to prove such VCs. While the number of hypotheses needed to prove VCs is interesting, the metric may mask some other properties of the VCs. For example, a VC whose proof requires a larger percentage of the hypotheses might be considered “less obvious” than a VC whose proof requires a small fraction of the hypotheses. Based on the results, this is fairly rare; the majority of VCs (over 90%) can be proved using only 30% of the hypotheses.

5

Related Work

We are unaware of any prior work that empirically examines the structure or proof difficulty of VCs. Work in this area has focused instead on the initial subproblems of generating VCs and creating tools to prove them. For example, the problem of generating VCs has been tackled using the Why methodology [10], which involves a simplified programming language, annotated with logical definitions, axioms, pre-conditions, post-conditions and loop invariants, from which VCs can be generated. A subset of both C (with annotations) and Java (with JML specifications) can be translated into the simplified programming language, such that the VCs generated are claimed to represent the correctness of the original C or Java code. The translation process from C or Java must explicitly capture the memory model of the original source language (C or Java). As a result of using RESOLVE, we do not need an explicit memory model, dramatically simplifying the generated VCs. Also addressing the problem of generating VCs, the tool Boogie [11] takes as input annotated compiled Spec# [12] code and generates VCs in the BoogiePL language. This language has support for mathematical assumptions, assertions, axioms and function definitions along with a restricted set of programming language constructs. The BoogiePL representation is used by Boogie to generate first order mathematical assertions. The method [13] used for generating VCs is similar to the method presented in Section 2. Addressing both the problem of generating VCs from program source and of creating tools that can prove the generated VCs automatically, Zee et al. [14] have used a hybrid approach of applying both specialized decision procedures

Verifying Component-Based Software

39

and a general proof assistant to prove that code purporting to implement certain data structure specifications is correct. However, the use of Java as a starting language requires that the specifications use reference equality for comparison. Our approach proves properties that depend on the values of the objects instead. To repeat, none of the above papers nor any others we know about present empirical data about the sources of proof difficulty across even a small selection of VCs, let alone hundreds as reported here.

6

Conclusion and Future Work

This paper has presented the first, to our knowledge, examination of the structure of VCs generated for client code built on reusable software components. The statistics support our hypothesis that VC proofs are mostly simple bookkeeping. Only a few VCs are structurally complicated. Moreover, the vast majority of VCs can be proved using at most three hypotheses. We have done some work using formal proof rules underlying a goal-directed approach, discussed in [8]. Preliminary results suggest that the goal-directed proof system generates fewer VCs that are comparably simple, according to taxonomy and the metrics, as the tabular method of VC generation. Further investigation of this phenomenon is in order. Our goal is to extend this work toward a more rigorous definition of obvious with a finer grained evaluation of the current VCs that is more directly connected to a particular type of prover. Performing a more rigorous comparison of different VC generation strategies along with a comparison of VCs generated using different programming languages should provide valuable additional information about the sources of difficulty of VC proofs.

Acknowledgments The authors are grateful for the constructive feedback from Paolo Bucci, Harvey M. Friedman, Wayne Heym, Bill Ogden, Sean Wedig, Tim Sprague and Aditi Tagore. This work was supported in part by the National Science Foundation under grants DMS-0701187, DMS-0701260, CCF-0811737, and CCF-0811748.

References 1. Sitaraman, M., Atkinson, S., Kulczycki, G., Weide, B.W., Long, T.J., Bucci, P., Heym, W.D., Pike, S.M., Hollingsworth, J.E.: Reasoning about softwarecomponent behavior. In: Frakes, W.B. (ed.) ICSR 2000. LNCS, vol. 1844, pp. 266–283. Springer, Heidelberg (2000) 2. Hoare, C.A.R.: The verifying compiler: A grand challenge for computing research. J. ACM 50(1), 63–69 (2003) 3. Woodcock, J., Banach, R.: The verification grand challenge. Journal of Universal Computer Science 13(5), 661–668 (2007), http://www.jucs.org/jucs_13_5/the_verification_grand_challenge

40

J. Kirschenbaum et al.

4. Enderton, H.: A Mathematical Introduction to Logic. Harcourt/Academic Press (2001) 5. Weide, B.W., Sitaraman, M., Harton, H.K., Adcock, B., Bucci, P., Bronish, D., Heym, W.D., Kirschenbaum, J., Frazier, D.: Incremental benchmarks for software verification tools and techniques. In: Shankar, N., Woodcock, J. (eds.) VSTTE 2008. LNCS, vol. 5295, pp. 84–98. Springer, Heidelberg (2008) 6. Ogden, W.F., Sitaraman, M., Weide, B.W., Zweben, S.H.: Part I: the RESOLVE framework and discipline: a research synopsis. SIGSOFT Softw. Eng. Notes 19(4), 23–28 (1994) 7. Harms, D., Weide, B.: Copying and swapping: Influences on the design of reusable software components. IEEE Transactions on Software Engineering 17(5), 424–435 (1991) 8. Krone, J.: The Role of Verification in Software Reusability. PhD thesis, Department of Computer and Information Science, The Ohio State University, Columbus, OH (December 1988) 9. Heym, W.D.: Computer Program Verification: Improvements for Human Reasoning. PhD thesis, Department of Computer and Information Science, The Ohio State University, Columbus, OH (December 1995) 10. Filliˆ atre, J.C., March´e, C.: The Why/Krakatoa/Caduceus platform for deductive program verification. In: Damm, W., Hermanns, H. (eds.) CAV 2007. LNCS, vol. 4590, pp. 173–177. Springer, Heidelberg (2007) 11. Barnett, M., Chang, B.Y.E., DeLine, R., Jacobs, B., Leino, K.R.M.: Boogie: A modular reusable verifier for object-oriented programs. In: de Boer, F.S., Bonsangue, M.M., Graf, S., de Roever, W.-P. (eds.) FMCO 2005. LNCS, vol. 4111, pp. 364–387. Springer, Heidelberg (2006) 12. Barnett, M., Leino, K.R.M., Schulte, W.: The Spec# programming system: An overview, http://citeseer.ist.psu.edu/649115.html 13. Barnett, M., Leino, K.R.M.: Weakest-precondition of unstructured programs. In: PASTE 2005: Proceedings of the 6th ACM SIGPLAN-SIGSOFT Workshop on Program Analysis for Software Tools and Engineering, pp. 82–87. ACM, New York (2005) 14. Zee, K., Kuncak, V., Rinard, M.: Full functional verification of linked data structures. SIGPLAN Not. 43(6), 349–361 (2008)

Extending FeatuRSEB with Concepts from Systems Engineering John Favaro and Silvia Mazzini Intecs SpA via E. Giannessi, 5y – I-56121 Pisa, Italy {John.Favaro,Silvia.Mazzini}@intecs.it

Abstract. FeatuRSEB is a method for domain modeling of software system families using the industry standard notation of the Unified Modeling Language. FeatuRSEB/Sys is an extension of FeatuRSEB with constructs from the SysML profile for systems engineering, augmenting it with analysis and modeling mechanisms that are upstream from the original method, while nevertheless conserving the advantages of an industry standard notation and semantics. Keywords: Domain analysis, reuse, feature, UML, SysML, systems engineering, requirements, analysis, modeling, architecture, trade studies.

1 Introduction James Neighbors introduced the term domain analysis into the literature in 1984 in an article [1] on his pioneering Draco system. Another milestone occurred in 1990 with the introduction [2] of Feature-Oriented Domain Analysis (FODA). FODA became a catalyst for the development of subsequent methods due to a number of characteristics including a straightforward scheme for capture and classification of domain knowledge that is easily understandable by humans. These characteristics have led to the development of several FODA variants over the years [3]. The FeatuRSEB [4] variant of FODA is a feature-oriented extension of an application family development method, the Reuse Oriented Software Engineering Business (RSEB) [5], arising out of collaboration between Hewlett-Packard Research and Intecs. It has two characteristics of particular interest: • It was one of the first domain analysis methods to employ the notation of the Unified Modeling Language [6]. Since then, other feature-oriented methods using UML notation have appeared [7]. These approaches have the advantage that an industry-standard modeling notation is used instead of an ad hoc, proprietary notation, and the semantics of core modeling concepts (such as classes and relationships) are not interpreted in an ad hoc fashion. This makes it easier to focus on the value-adding characteristics of the method. • Due to its origins in the Reuse Driven Software Engineering Business, nontechnical, business-oriented factors are given more explicit emphasis with respect to purely technical factors; S.H. Edwards and G. Kulczycki (Eds.): ICSR 2009, LNCS 5791, pp. 41–50, 2009. © Springer-Verlag Berlin Heidelberg 2009

42

J. Favaro and S. Mazzini

Intecs works with clients in the aerospace, automotive, space, and telecommunications industries, where we advise them on development methodologies and provide specialized toolsets such as HRT-UML for the modeling of hard real-time systems [8]. This work has exposed us to the discipline of systems engineering, which is central to the development of large systems in those industries. Based upon this experience, we have extended FeatuRSEB with modeling concepts and constructs from the Systems Modeling Language (SysML) profile [9] of the UML in order to extend its capabilities for high-level analysis for domain modeling of large software system families, while preserving the advantages of an industry-standard notation and semantics.

2 Relating Systems Engineering to Domain Engineering Systems engineering as a recognized discipline dates back to the 1950s, and has been applied with success to large and complex systems in contexts ranging from defense and air traffic control to commercial products. Systems engineering essentially consists of three major concurrent activities (Fig. 1). Requirements elicitation and documentation activities

Analyses (feasibility studies, relationships, constraints, …)

High-level system functional design

Fig. 1. Three concurrent activities in systems engineering

• Requirements elicitation and documentation is the core activity of systems engineering. • Numerous types of analyses are carried out, related to the specific disciplines involved, and may include engineering and economic feasibility studies, documentation of relationships among components, and identification and documentation of physical constraints on system elements. In particular, they may include calculations and formulas related to non-functional requirements. • High-level system functional analysis identifies the principal subsystems, their interfaces, and dataflows through those interfaces. Although each of these activities superficially appears to have a direct counterpart in the software engineering life cycle, their nature and purpose are different in systems engineering. Requirements are first-class citizens in systems engineering (in the sense that they are elicited, documented, and managed as separate entities) because they are an output of the systems engineering process, whereas in software engineering processes, requirements tend to be managed as an input. In fact, it would be only a slight exaggeration to state that systems engineering is mostly concerned with eliciting requirements of systems and about analyzing the feasibility of designs. Requirements are elicited with the support of analyses that in turn elicit relationships and constraints among different parts of the system. The documentation of these analyses, trade-off studies, and associated decisions is likewise considered a firstclass citizen in systems engineering, rather than an afterthought as so often happens in

Extending FeatuRSEB with Concepts from Systems Engineering

43

software systems design (often something as poor as a simple text field to “describe rationale in 256 characters or less”). This elevation of rationale and decision-making documentation to first-class citizenship is in line with recent awareness in the software engineering community of its importance, e.g. through the addition of the Decision View in the standard 4+1 views model of software architectural description [10]. In domain analysis it is even more important, where the recording of trade-off and decision-related information for entire families of systems is crucial for informing the feature selection process for subsequent domain engineering of systems. The term “functional analysis” in systems engineering has a more general meaning than in software engineering. This is so in large degree because it is essential for determining subcontracting boundaries: systems engineers construct the product tree of all identified components of the system (including the software component) and then each such component is contracted out to others to construct (it is not unusual for a systems engineering organisation to have no construction capability at all). Requirements elicitation, analysis and decision-recording, and system component management mechanisms are much less well developed in software engineering processes because they are upstream from where software engineering processes generally start. Indeed, in the ECSS-E40 standard of the European Space Agency for software engineering [11], systems engineering activities are explicitly defined to be precedent to the software engineering activities. This is where the relationship of system engineering to domain engineering emerges: domain engineering is also upstream from the traditional (single-system) software engineering process. The outputs of domain engineering also serve as inputs to the activities for engineering (single) software systems. Therefore, in retrospect it is not surprising that we found precisely these mechanisms from systems engineering to add significant value to the domain modeling process.

3 Introducing SysML into Domain Analysis: The Domain Models The table in the Appendix summarizes the models and approach of FeatuRSEB/Sys, describing also the ways in which each model handles variability. In this section we discuss in more depth those models which integrate systems engineering concepts. 3.1 Context Model Context analysis was introduced in original FODA. The purpose of the context model is to define the scope of the domain that is likely to yield exploitable domain products. FeatuRSEB/Sys context diagrams are represented as SysML block diagrams. Standard UML is biased toward the concrete development of software systems: it naturally forces thinking in terms of objects and methods, quickly driving toward design. (Indeed it has been suggested by the inventors of FODA that it has been pushed beyond its original intention of analysis into design). At the highest levels of domain engineering, though, interfaces are much more important than specific “methods” on classes. With SysML blocks (thought of as “whited-out classes”) the domain analyst is freed from the “tyranny of the methods.” As in other FODA

44

J. Favaro and S. Mazzini

variants, context analysis provides the high level connections among major components related to the target domain. The exchange of information (dataflow) with external actors (peer domains) and lower domains is indicated at block boundaries by means of SysML flow ports. The SysML blocks and flow ports help to pull the context analysis up to a higher level of abstraction more suited to domain engineering. 3.2 Domain Dictionary The domain dictionary consolidates the definitions of all terms used in the domain and is updated over time. In FeatuRSEB the feature model did “double duty” as a domain dictionary, and this is also true in FORM [12] to a degree. In FeatuRSEB/Sys the domain dictionary is separate and explicit, serving the same role as in systems engineering of establishing a common basis for communication among all participants in the domain implementation activities. 3.3 Domain Requirements Model In FeatuRSEB the use case model alone represented user requirements, relieving the feature model of FODA from doing double duty to represent both user requirements and reuser features. In FeatuRSEB/Sys a similar phenomenon occurs: the use case model is relieved from representing both use scenarios and implicitly the requirements they embody, by adding a requirements model to model the requirements explicitly. Requirements reuse has received some attention in the literature [13], but its integration into domain analysis methods tends to take the form of implicit inclusion in domain use case models and to some extent feature models. We argue that a separate domain requirements model is a useful addition to the set of domain analysis models, for at least two reasons: first, although use case models are often referred to as “requirements models”, we subscribe to the point of view currently argued by many that use cases are at a lower level of abstraction than the requirements themselves – rather, use cases generally represent the results of requirements analysis; second, an explicit requirements model is particularly useful for documenting many types of technical, organizational, economic, and legal non-functional requirements, which are not handled well by use case techniques with their bias toward functional requirements, but which a domain analysis must capture in order to be complete. In short, explicit modeling of domain requirements contributes to keeping the level of abstraction of the domain analysis as high as possible. SysML provides an explicit requirements diagram (Fig. 2), which can serve as an important starting point for reusable requirements for new systems in a domain. For example, it gives the domain analyst a place to document the cost of implementing reusable requirements [14]. Furthermore, the requirements model allows requirements management tools to link from the requirements to their implementation in domain systems. This supports requirements traceability, and thereby provides support not only for the construction phase of domain engineering, but also for V&V, which has a heavier footprint in larger, more complex systems.

Extending FeatuRSEB with Concepts from Systems Engineering

45

Fig. 2. Two requirements from the domain requirements model corresponding to the telecommunications example in [4]. The requirement on the right-hand side could not be easily captured and modeled using only use case techniques.

3.4 Analysis Models In the UML, analysis has a rather narrow meaning, involving the transition from use cases to object design. FeatuRSEB inherited Jacobson robustness analysis from the RSEB for this purpose. But in systems engineering, analysis has a more general meaning, and is more about exploring feasibility, relationships and constraints at high system levels (relationships between large blocks of system functions), and in general doing supporting analysis to ensure that a system functional architecture is sound and cost-effective. In UML, there are no standard ways to document such characteristics. Some progress is being made with improved mechanisms for describing constraints, but in general the user is left to his own devices. In SysML, a new diagram has been introduced solely for documentation of constraints and relationships among system parts. Parametric diagrams are used to capture the properties of the applications or subsystems of the domain. They can express powerful constraints that abstract away specific constraints of individual systems into more general constraints (e.g. expressed in terms of formulas) characterizing aspects of system families. For example, perhaps a «performanceRequirement» can only be satisfied by a set of constraints along with an associated tolerance and/or probability distribution, or a «functionalRequirement» might be satisfied by an activity or operation of a block. Likewise, cost constraints can be explicitly documented in parametric diagrams. par [ ConstraintBlock] C

tf

tf

ts

ts

eq1: CallDuration {d = tf – ts - d}

ts

d

r

d

eq3: CostCalc

r

{C = r * d + b}

C

C

eq2: RateCalc rt

rt

{r = lookup (rt, ts)}

refines «requirement» Time-period based invoicing

Fig. 3. Parametric diagram for billing feature (simplified) in model of [4], to support analysis and identification of input parameters that must be made available by a domain architecture to support implementation of a requirement for time-period based call invoicing

46

J. Favaro and S. Mazzini

Parametric diagrams help the domain analyst to analyze constraints on the domain architecture needed to satisfy particular requirements. For example, in [4] one feature variant for the telephone call invoicing subsystem had a requirement to be able to support invoicing based upon time periods (e.g. “late night,” “daytime,” etc.). A parametric diagram (Fig. 3) helps document an analysis to identify the input parameters for such a feature that an architecture will have to support. Such an analysis supports refinement of the requirement and feasibility and cost studies. Feature modeling permits the documentation of reusable functionality – but what about reusable “non-functionality”? Domain analysis methods have not traditionally provided strong support for a reuse-oriented documentation of non-functional aspects of system families. For example, the theory and methods used to analyze performance constraints in families of real-time systems form an important part of their construction and documentation. The constraint blocks of SysML make it possible to package and document non-functional aspects as reusable artifacts (Fig. 4). Using the SysML concept of allocation, variability can be modeled with such mechanisms – for example, two different algorithms could be allocated to different system variants. bdd [ Package] Analysis Models

«constraint» Earliest Deadline First Model constraints

⎧ ⎨/U = ⎩

n

∑ i −1

⎫ Ci ≤ 1⎬ Ti ⎭

«constraint» Rate Monotonic Model constraints

(

)

n ⎧ ⎫ Ci n ⎨/ U = ∑ ≤ n 2 − 1 ⎬ T i − 1 i ⎩ ⎭

{size(T) = n & size(C) = n}

parameters T: Real [*] {ordered, unique} /U: Real C: Real [*] {ordered} n: Integer

parameters T: Real [*] {ordered, unique} /U: Real C: Real [*] {ordered} n: Integer

Fig. 4. Reusable analysis models for hard-real time system families packaged as constraint blocks

It is important to emphasize that, especially in a context of domain engineering of large and complex systems in the sectors in which our clients operate, those decisions which concern the scope of system families and the number of variations supported in a domain architecture are primarily business driven: considerations: the effort, time and costs required for domain design and implementation must be less than the effort, time and costs that would be required for the expected number of domain applications that may reuse the domain engineering results. Here FeatuRSEB/Sys inherits the business decision mechanisms from the Reuse Oriented Software Engineering Business upon which original FeatuRSEB was based. The difference is that the means to document these decisions is now provided in the new mechanisms from SysML. In particular, the parametric diagram mechanism supports the domain analyst in what in systems engineering are called trade (or trade-off) studies, whereby so-called measures of effectiveness (“moes”) are defined within an analysis context (Fig. 5).

Extending FeatuRSEB with Concepts from Systems Engineering

47

PhoneLine values «moe» throughput: T «moe» reliability: R «moe» quality: Q «moe» services: S

VOIP

POTS

values

values

«moe» throughput: T = 0.83 «moe» reliability: R = 0.75 «moe» quality: Q = 0.65 «moe» services: S = 0.95

«moe» throughput: T = 0.65 «moe» reliability: R = 94 «moe» quality: Q = 0.67 «moe» services: S = 0.45

Fig. 5. SysML analysis context for trade analysis for the phone line quality feature variants in [4] according to selected measures of effectiveness («moe»). Here another mechanism for handling variability is illustrated: the PhoneLine abstraction captures the variability between VOIP and POTS alternatives. Different objective functions will place emphasis on different characteristics (e.g. superior service offering flexibility on VOIP line or higher reliability of POTS line), allowing the domain engineer to select feature variants based upon the needs of the particular system.

3.5 High Level Generic Architecture SysML block diagrams are used to describe the top level partitioning of the domain system capabilities into functional blocks, as refinements of the context model structure diagrams; these blocks are defined as black boxes by putting the emphasis on provided and required interfaces. These interfaces do not require a full signature, but mainly describe named entities as SysML dataflows. Dataflow entities exchanged between domains and data that are handled by toplevel components (blocks) in the domain are described, categorized (by inheritance) and clustered (by aggregation) using object oriented technology, in order to provide their data structure. For this purpose UML class diagrams are used in a separate data package, thus describing the data model for information exchanged in the domain. The package may correspond to a library of data types available at domain level. The functional model identifies the functional commonalities and differences of the applications in the domain. The elements of the specification of a functional model can be classified in two major categories: First, specification of functions describes the structural aspects of the top level partitioning of the applications in terms of inputs, outputs, internal data, logical structures and data flow among them. Second, specification of the functional and dynamic behavior describes how an application behaves in terms of events, inputs, states, conditions and state transitions, sometimes defined as control flow. Activity diagrams and UML StateCharts are generally used to describe functional models, but other discipline-specific methods and languages may also be used, such as those used to model mechanical or control aspects of systems.

48

J. Favaro and S. Mazzini

3.6 Feature Model The feature model in FeatuRSEB/Sys remains the “+1” model as described in original FeatuRSEB, summarizing the results of domain analysis and tracing the features back into the respective domain models, whereby the traces are extended to the other, additional models that have been introduced (e.g. the requirements model). In original FeatuRSEB a notation for the feature model was devised by extending the UML with stereotypes for describing the features and their relationships. This notation remains valid for FeatuRSEB/Sys, retaining the advantage of using the UML.

4 Conclusions and Further Work Systems engineering places emphasis on activities that are upstream from those of software engineering, whereby outputs considered valuable include requirements, feasibility analyses and trade studies, and high level functional breakdown at a higher level of abstraction than in software system architecture. The same is true of domain engineering, and the new concepts and diagrams of SysML help to raise the level of abstraction in domain analysis back to where it was originally conceived. It also provides another advantage: the feature model in the feature-oriented approaches is in its essence a mechanism for organization and traceability. Systems engineering provides extended mechanisms for traceability – of requirements, of analyses, and the like – that make it possible to broaden the scope of traceability and provide a more complete documentation of the domain analysis. FeatuRSEB/Sys originated in the COrDeT project of the European Space Agency, where it was used in the modeling of onboard Space system families [15]. Related efforts in modeling techniques are underway in other contexts – for example, the EAST-ADL2 profile for an automotive architectural modeling language that incorporates concepts and mechanisms from SysML [16]. Tool support is an important aspect of feature-oriented domain modeling, and significant progress has been made since its introduction [17]. The choice of UML and SysML is important not only for notational uniformity and familiarity, but for its implications for tool support. The combination of the improved UML Meta Object Facility (MOF) and its support by the Eclipse framework has made model based development of specialized tools feasible with reasonable costs. The provision of complete tool support for FeatuRSEB/Sys will be the focus of future efforts.

References 1. Neighbors, J.: The Draco Approach to Constructing Software from Reusable Components. IEEE Trans. Software Eng. 10(5), 564–574 (1984) 2. Kang, K., Cohen, S., Hess, J., Nowak, W., Peterson, S.: Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90-TR-21. Software Engineering Institute, Carnegie Mellon University, Pittsburgh (1990) 3. Frakes, W., Kang, K.: Software Reuse Research: Status and Future Directions. IEEE Transactions on Software Engineering 31(7) (July 2005)

Extending FeatuRSEB with Concepts from Systems Engineering

49

4. Griss, M., Favaro, J., D’Alessandro, M.: Integrating Feature Modeling with the RSEB. In: Fifth International Conference on Software Reusability, pp. 76–85. IEEE Press, New York (1998) 5. Jacobson, M., Griss, M., Jonsson, P.: Software Reuse: Architecture, Process and Organization for Business Success. Addison-Wesley-Longman, Menlo Park (1997) 6. Rumbaugh, J., Jacobson, I., Booch, G.: The Unified Modeling Language Reference Manual, 2nd edn. Addison-Wesley, Boston (2004) 7. Gomaa, H.: Designing Software Product Lines with UML: From Use Cases to Patternbased Software Architectures. Addison-Wesley, Boston (2004) 8. Mazzini, S., D’Alessandro, M., Di Natale, M., Domenici, A., Lipari, G., Vardanega, T.: HRT-UML: taking HRT-HOOD into UML. In: Proc. 8th Conference on Reliable Software Technologies Ada Europe (2003) 9. The Object Management Group, Systems Modeling Language (OMG SysML), Final Adopted Specification, document ptc/06-05-04 (2006), http://www.omg.org 10. Kruchten, P., Capilla, R., Dueñas, J.C.: The Decision View’s Role in Software Architecture Practice. IEEE Software 26(2), 36–42 (2009) 11. European Space Agency, ECSS-ST-40C – Software General Requirements (March 6, 2009), http://www.ecss.nl 12. Kang, K., Kim, S., Lee, J., Kim, K., Shin, E., Huh, M.: FORM: a feature-oriented reuse method with domain-specific reference architectures. Annals of Software Engineering 5(1), 143–168 (1998) 13. Lam, W.: A case-study of requirements reuse through product families. In: Annals of Software Engineering, vol. 5, pp. 253–277. Baltzer Science Publishers, Bussum (1998) 14. Favaro, J.: Managing Requirements for Business Value. IEEE Software 19(2), 15–17 (2002) 15. Mazzini, S., Favaro, J., Rodriguez, A., Alaña, E., Pasetti, A., Rohlik, O.: A Methodology for Space Domain Engineering. In: Proceedings Data Systems in Aerospace (DASIA), Palma de Majorca, Spain (2008) 16. Lönn, H., Freund, U.: Automotive Architecture Description Languages. In: Navet, N., Simonot-Lion, F. (eds.) Automotive Embedded Systems Handbook. CRC Press, Boca Raton (2009) 17. Antkiewicz, M., Czarnecki, K.: FeaturePlugin: Feature Modeling Plug-in for Eclipse. In: Eclipse 2004: Proceedings of the 2004 OOPSLA Workshop on Eclipse Technology eXchange, OOPSLA, pp. 67–72. ACM Press, New York (2004)

50

J. Favaro and S. Mazzini

Appendix: Summary of FeatuRSEB/Sys Models and Method Domain model Sub-components and components Notation(s) Context model

Context diagrams – SysML block diagrams

Use case diagrams – SysML use case diagrams

Utilization Positioning of the target domain with respect to higher, peer and lower domains. Variability expressed through different diagrams Description of domain capabilities. Variability expressed through different diagrams Updated throughout the domain analysis

Domain dictionary Requirement model

Text

High level generic architecture

Top-level partitioning (into Refinement of the context model applications) – SysML Block structure diagrams diagrams

Requirement diagrams – SysML Requirement diagrams

Link to Use cases and Blocks. Required variability has to be explicitly specified by link to related use cases and/or blocks and by link or requirement annotation.

Data package (library of data Data flow entities exchanged between types/structures) - UML domains and data handled by top level class diagrams components are described, categorized (by inheritance) and clustered (by aggregation) Application capabilities Application Use cases – SysML Use case diagrams Application Behaviors – SysML Interaction (sequence) diagrams Functional model

Feature model

Refinement of context level Use cases

Structural aspects of top level partitioning (inputs, outputs, internal data, logical Specification of functions – structures and data flow among SysML activity diagrams applications). Specific of dynamic behavior Application behavior (events, inputs, – SysML StateChart states, conditions and state transitions) Parametric diagram – SysML Capture functional and non functional Parametric diagram requirements through formulation of constraints. Document trade-off studies on architectural variants, including cost and performance factors. Feature model – UML Synthesis of domain analysis variability notation from FeatuRSEB as emerging from the above models.

Features Need Stories Sidney C. Bailin Knowledge Evolution, Inc., 1221 Connecticut Ave. NW, STE 3B, Washington DC 20036 [email protected]

Abstract. We present an extension of the notion of feature models. An ontology of stories clarifies the meaning of potentially ambiguous features in situations where there is no unified domain model, and where candidates for reuse have varied provenance. Keywords: features, domain model, story, ontology, evaluation.

1 Introduction This paper argues that feature models, while an essential tool for reuse in any domain, are not in themselves sufficient for the capture and communication of knowledge about variability. We argue that features carry a relatively small amount of semantics, if any at all, and that much of the intended semantics remain implicit in naming conventions, or tacit in experience, or undocumented in hearsay. We suggest that the missing semantics, addressing fine-grained questions of context, interface, function, performance, and rationale, can be usefully conveyed through stories attached to features. By story we mean something relatively specific, not simply a chunk of text. There are several attributes that make something a story, but one of the key attributes is that of being situated. In a story, context is (almost) everything. Examples of the kinds of stories we are looking for already exist in the user feedback sections of many web-based product catalogues. User feedback contributions, despite their unstructured form, tend to be highly situated and, thus, are often good examples of the notion of story we are advocating. Consumer assistance product reviews, on the other hand, are often much less situated; for this reason, they often fall short both in their sense of urgency and in the amount of crucial background information they provide. We are not simply advocating for stories. That is an argument we have made elsewhere [1]. Nor are we arguing here for a particular kind of feature model: that, too, we have addressed elsewhere [2]. In this paper we are specifically interested in the way in which stories can be used systematically to enrich the semantics of a feature model. At the core of this vision lies interplay between the formal and the informal. The bulk of the paper consists of a case study that involved the evaluation of alternative technologies for a particular function within a complex system of systems. We argue in Section 1.1 that the evaluation of alternative candidates is the essence of S.H. Edwards and G. Kulczycki (Eds.): ICSR 2009, LNCS 5791, pp. 51–64, 2009. © Springer-Verlag Berlin Heidelberg 2009

52

S.C. Bailin

the reuse process. Our goal is not, however, to present a methodology for trade studies, but rather to explore the kind of contextual information that is necessary in order to perform such evaluations, and to draw conclusions from this about the structure and contents of domain models. Our conclusions are applicable to virtually any domain modeling method. 1.1 Features and Engineering Analysis Many opportunities for reuse occur in situations lacking a well-developed domain model, and in which the resources required for a full-scale domain analysis (not just money but also time) are unavailable. Such opportunities cannot take advantage of feature-based reuse methods [3] and product-line architectures [4]. Yet they are far more systematic than what is often termed opportunistic reuse. We will call this real-world reuse. These situations are often opportunities for knowledge reuse: the primary decision is to choose an existing, well-defined technical approach to solve a problem. The technical approach is typically selected through an engineering analysis involving goals, priorities, and tradeoffs. Thus, knowledge reuse is closely related to the disciplines of engineering analysis. Such situations, however, often invite reuse not just of knowledge but of actual software, for the simple reason that the technical approaches are realized in software. Thus, there is a deep connection between software reuse and the process of engineering analysis—evaluating alternative technologies to meet a set of requirements. Conversely, any software reuse decision ought to involve an evaluation of alternatives. At a minimum, the question of make vs. buy (develop vs. reuse) should be addressed. Beyond that, if there are multiple candidates for reuse, or multiple features that may or may not be selected, then a systematic evaluation of tradeoffs ought to occur. But real-world reuse, lying somewhere between systematic and opportunistic, illustrates a limitation of feature models. Because it occurs without a unified domain model, the features considered in the tradeoff studies are not necessarily comparable from product to product, let alone from study to study. There is no controlled vocabulary with which to describe and evaluate the alternative solutions. 1.2 Features and Ontologies In a previous paper we described the use of ontologies to represent KAPTUR-style domain models: problems, alternatives solutions, their features, rationales, and tradeoffs [5]. We noted that ontology mismatches arise when there are many parochial models of a domain rather than one unified model, and we described a process of progressive resolution of mismatches. In the LIBRA method, this process of resolving models-in-conflict is viewed as the very essence of reuse [6]. Aspects of the parochial contexts can be formalized to provide enriched semantics for their respective feature sets. Using ontologies, which are intrinsically open-ended, we can add concepts for disambiguating features that have slightly different meanings in different contexts (see Section 4.1). But there is a point of diminishing returns at

Features Need Stories

53

which formalization may not be appropriate, at least not until the domain reaches a certain level of maturity. The appropriate medium for capturing this context is, in such cases, narrative. 1.3 What Is a Story? By story we mean a communication that speaks of characters responding to some situation. The characters need not be people; they can be organizations, systems, computers, software programs or even designs. Something about the initial situation is unstable and causes the characters to act. The actions change the situation, and what follows is a succession of situations requiring action, and actions taken in response. This is the forward movement of the story. The emphasis is on causation, or, from another point of view, rationale. Stories are an especially effective mode of communication because they draw the reader into the story world. This only happens, of course, if what is at stake for the characters is also a concern for the reader. When this happens, the immersive nature of the story and its forward movement give the communication an urgency and sense of reality that ordinary communications lack.

2 Case Study We illustrate our arguments with a real case study that involved selecting software for use in a large, complex system of systems (SoS). The primary tradeoff was a make vs. buy decision; but, as we shall see, each of the alternatives involves some form of reuse. Salient features of the SoS, which will remain anonymous in this paper, include life-critical functions, high cost, and a complex network of stakeholders including multiple engineering and development organizations. The application we consider here is a relatively small part of the SoS, responsible for transmitting large volumes of structured data between two major SoS components. The data stream contains sequences of fields in many different data types and occurring with different frequencies. Different fields originate from different sources, and are routed to other component systems belonging to different stakeholders. This is illustrated in Figure 1.

System A

System B

Fig. 1. A data transmission application serves as a case study

54

S.C. Bailin

We called this a compression trade study because the primary challenge is to transmit the data efficiently by compressing it into a compact form, then decompressing it upon receipt. 2.1 Evaluation Criteria Table 1 shows the criteria used to evaluate the alternative compression technologies. Table 1. Evaluation criteria used in the case study

Criterion Encoding / decoding speed

Encoding / decoding software cost Transmission speed

Interoperability

Learning curve / programming complexity

Maturity

Tool availability Tool reliability

Evolvability

Risk

Description Speed at which messages can be encoded into their compressed format and then decoded by the receiving end Cost of acquiring and maintaining the software that performs the encoding and decoding Direct measure of the size of the compressed messages, which must be averaged over the likely variations in message types and content Availability of the proposed encoding method on different systems, and the expected level of confidence that the implementations on different systems are compatible Complexity of an encoding method has a direct impact on the cost of any project-developed software implementing the method, but it may also limit the range of available COTS implementations, and lessen confidence that the implementations are correct Assessed both temporally (how long the method has been in existence) and spatially (how widely it has been used) Availability of software to perform the selected functions The level of confidence that the tool will perform its functions continuously and correctly, where continuity includes the traditional systems engineering notion of availability, while correctness refers to the satisfaction of functional and performance requirements (throughput/response time) Includes the ability of the selected technology to handle evolution in the data stream contents, and the potential impact of evolution in the compression method itself (as in the evolution of standards) General unknowns

Features Need Stories

55

The evaluation criteria are not mutually independent, but each has a unique emphasis that warrants its being considered explicitly. 2.2 Alternatives Considered Table 2 identifies the alternative methods that were evaluated: Table 2. Alternative solutions considered in the case study

Solution Custom packing maps

Description The format of the data stream messages is defined explicitly in terms of the admissible fields, their sequencing, and their respective length Abstract Syntax Notation ASN.1 is an international standard for describing (ASN.1) Packed Encoding structured data [7]; the PER is part of the standard that Rules (PER) provides for a compact binary encoding of such data Fast Infoset [8] An international standard for binary encoding of data represented in the Extensible Markup Language (XML) Lempel-Ziv (LZ) A family of compression technique used by tools such compression [9] as WinZip and Gzip Efficient XML Interchange An emerging recommendation of the World-Wide (EXI) Web Consortium (W3C) for binary encoding of XML data [10] These alternatives represent the gamut from the conventional approach for such systems as previously developed (custom packing maps), through international standards (ASN.1 and Fast Infoset) and widely used file compression techniques (LZ), to a recent W3C recommendation for binary XML transfers (EXI). The alternatives vary significantly in their levels of maturity, but there is a logic to their consideration. The custom packing map approach is the organization’s legacy approach for this type of system. ASN.1 and XML are the two primary standards for expressing structured data outside of programming and formal specification languages. There are several standard encodings for ASN.1, but PER is the primary encoding for efficient binary data transfer. Similarly, Fast Infoset is a current standard for binary encoding of XML, while EXI is an emerging standard for the same purpose, whose definition has itself taken into account many of the alternatives. Finally, LZ compression is widely used in a variety of tools familiar to the engineers responsible for designing and implementing the system. Further complicating the study is the role of another international standard that would govern the way in which a custom packing map would be specified. To some extent this mitigates the “custom” nature of this alternative (as does the fact that it, alone among the alternatives, draws heavily from the organization’s past experience).

56

S.C. Bailin

3 Reuse in the Case Study The case study does not sound like a typical reuse scenario. There is no repository of reusable components, and no domain model from which systems can be instantiated through a selection of appropriate features. Nevertheless, the case study illustrates what we are calling real world reuse. It is an example of reuse because each of the alternative solutions is a form of reuse. This is clear in the case of the off-the-shelf candidates; perhaps less obvious, but equally true, is reuse in the case of the custom packing map, which is the approach the organization had used in all previous systems. At the very least, if a custom packing map were to be adopted, fundamental design concepts from prior systems would be reused; more likely, there would be adaptation of existing source code as well. Why, then, does the case study appear to be more like a conventional engineering design analysis than a case of reuse? One reason is that the evaluation was performed not at the level of functionally equivalent alternatives (for example, alternative implementations of the ASN.1 PER), but rather at the level of alternative functional approaches. Formally, however, this is no different from conventional reuse: we have a specification at a certain level of abstraction, and the candidates for reuse are alternative realizations of the specification. In this case, we lack a unified feature model for characterizing the alternative solutions. But the evaluation criteria serve, in effect, as features. Conversely, in a feature-based reuse process, the features may be considered evaluation criteria in the selection of a solution. Viewed in this way, every tradeoff analysis creates a kind of domain model, but each model is usually unique to the analysis; they are not easily compared, which makes it difficult to base decisions on prior analyses that were performed in different contexts. 3.1 Features with Values One objection to viewing evaluation criteria as features is that the criteria are attributes with values, while features are often viewed as things to be selected, i.e., the candidate either has the feature or it does not. This effectively restricts features to attributes with values in a finite enumeration set (such as Boolean-valued attributes). It is an arbitrary limitation that dispenses with information essential to specifying or evaluating reusability. For example, an efficiency feature could take values in an enumeration set consisting of the time-complexity classes such as Logarithmic, Linear, Polynomial, etc. But it might equally well take the form of more detailed testing results that graph specific response times against different inputs. The studies we consulted follow the latter approach—rightly so, because they tested different classes and distributions of input. The efficiency feature carries implicit semantics that must be made explicit for proper comprehension.

4 Integrating Multiple Feature Models Having identified the alternative solutions and the criteria for evaluating them, we studied the literature to see what was already known. There was a substantial body of

Features Need Stories

57

prior work on just this problem, but none of the studies we found used exactly the same set of candidate solutions and none used exactly the same evaluation criteria. The studies varied in their scope, in the level of rigor, and in the detailed definition of features (especially performance features). Not surprisingly, the studies also differed from each other in their conclusions. As an example, Table 3 lists the criteria from a study by Qing&Adams along with their respective priorities [11]. Table 3. Evaluation criteria considered by Qing&Adams

Criterion High Compression Ratio Low Processing Overhead No Semantic Ambiguity 3rd Party API Support

Priority Required Required Required Desirable

These criteria resemble ours but are somewhat different. High compression rate is effectively synonymous with our transmission speed criterion, while low processing overhead corresponds to our encode/decode speed. We implicitly required that all the candidates be semantically unambiguous, but we did not specify this explicitly. Finally, their 3rd party API support could facilitate our interoperability, and could improve our tool availability; but their criterion is more specific and does not necessarily imply ours. Table 4. Candidate solutions considered by Qing&Adams

Solution Gzip and Bzip wbXML ASN.1 wbXML + Zip ASN.1 + Zip XML Binary Optimized Packaging (XOP): Message Transmission Optimization Mechanism (MTOM) XMill

Description Bzip is an alternative compression algorithm using Burrows-Wheeler methods [12] WAP Binary XML, developed by the Open Mobile Alliance [13] Apparently the PER encoding although this is not clear wbXML encoding followed by Gzip or Bzip compression ASN.1 encoding followed by Gzip or Bzip W3C recommendation dating from 2005 [14] W3C recommendation for binary message transmission especially in the context of the Simple Object Access Protocol (SOAP) [15] Open source XML compressor that claims better performance than (for example) Gzip [16]

58

S.C. Bailin

The alternative solutions considered by Qing&Adams are also similar but not identical to our set, as shown in Table 4. Of the four evaluation criteria in Table 3, the latter two (no semantic ambiguity and 3rd part API support) were quickly disposed of as being satisfied by all candidates, leaving compression ratio and processing overhead as the focus of the study. Most of the other studies focused on these two criteria, as well. The meaning of the terms, however, varied from study to study. Now we look at some of the criteria used by the EXI committee. Table 5 shows 7 out of the 21 criteria they applied: those that correspond or are closely related to our criteria [17]. Table 5. Subset of evaluation criteria used by the W3C EXI committee

Criterion Compactness Forward compatibility Implementation cost

Platform neutrality Processing efficiency

Transport independence

Widespread adoption

Description Amount of compression a particular format achieves when encoding data model items. Supports the evolution of data models and allows corresponding implementation of layered standards. How much time does it take for a solitary programmer to implement sufficiently robust processing of the format (the so-called Desperate Perl Hacker measure). Not significantly more optimal for processing on some computing platforms or architectures than on others Speed at which a new format can be generated and/or consumed for processing. It covers serialization, parsing and data binding. Only assumptions of transport service are "error-free and ordered delivery of messages without any arbitrary restrictions on the message length". Has been implemented on a greater range and number of devices and used in a wider variety of applications.

Table 6 illustrates the relationships between the criteria used in our case study and those used by the EXI committee. Some of them—such as widespread adoption—are intrinsically “soft” in that they admit of varying interpretations. For these, the value of elaborating the meaning with stories may be obvious. For example, what were the experiences of projects that adopted the technology? To drive our argument home, however, we focus on one particular feature that should, on the face of it, be relatively well-defined: compactness. 4.1 Semantics of the Compactness Feature The term compactness is ambiguous because it must cover a wide range of inputs. If we had only one input instance, compactness could be reduced to a positive

Features Need Stories

59

Table 6. Relationships between our evaluation criteria and those of the EXI study

Our Criterion Encoding / decoding speed Encoding / decoding software cost Transmission speed Interoperability Learning curve / programming complexity Maturity Tool availability Tool reliability Evolvability

Relation Synonymous with Includes off-the-shelf purchase cost as alternative to Effectively synonymous with Enhanced by

EXI Criterion Processing efficiency Implementation cost

Compactness

Increases

Platform neutrality Transport independence Implementation cost

Indicated by Indicated by Weakly indicated by Partially supported by

Widespread adoption Widespread adoption Widespread adoption Forward compatibility

integer-valued attribute, namely the size of the output. In reality, though, it must represent an aggregate assessment over a set of inputs. Resolving the ambiguity requires deciding on the sample inputs to use, the classes in which to group them, and the kind of aggregation to perform, e.g., averages, distributions, peaks, or some other measure. For example, Qing&Adams used as input 9 files from the Extensible Access Control Markup Language (XACML) conformance test suite [18], ranging in size from 2KB to 1MB [11]. Mundy et al created a custom application for exchanging attribute certificates to compare XML and ASN.1 [19], while Cokus&Winkowsi created test sets to resemble the exchange of binary formatted military messages [20]. The EXI study involved a detailed definition of widely varying use cases [21], while Augeri et al created a corpus modeled on the widely used Canterbury corpus for compression evaluations [22, 23]. How do we compare, contrast, and aggregate such various tests? Viewing a feature model as part of an ontology [5], we can create placeholders in which to add the relevant information. For example, the alternative candidates can have a property test results, which are then linked to the relevant features of the candidate as well as to the test set employed, as illustrated in Figure2. This provides a unified view of the past studies. It does not, however, provide much help in comparing the different results. How should one understand the differences in test sets? The EXI tests, for example, correspond to a set of 18 use cases, including Metadata in broadcast systems, Floating point arrays in the energy industry, X3D graphics compression, serialization, and transmission, Web services for small devices, Web services within the enterprise, etc.

60

S.C. Bailin

Candidate

hasTestResults

Test Results

obtainedUsing

Test Set

hasFeature

indicates

Compactness

Fig. 2. The open-world character of an ontology allows us to add contextual information to a feature model

We could add use cases as first-class objects and associate them with the corresponding test sets. Figure 3 illustrates part of the resulting ontology.

hasRationale

supports Test Set

Justification

Use Case occursIn

describedBy involves

Domain

Stakeholder

Scenario

Fig. 3. The feature model can be enriched with an endless amount of contextual information

We can take this further by elaborating the Scenario class in Figure 3 with properties specifying the functions performed, their relative importance (e.g., required vs. desirable), and their performance attributes. But this does not necessarily help in comparing the results of the different studies. The Canterbury corpus, for example, is not defined in terms of use cases, and its classification of input files is quite unlike the EXI classification. They are really different ontologies. Simply aggregating them provides little insight into the significance of using one test corpus vs. another. A similar issue arises in representing the test results. Some of the studies we consulted present a set of curves—one per candidate—graphing compressed size against original size. But Augeri et al average the results over all test sets and present additional analysis of the test set attributes that were contributing factors [22]. Should these distinctions be modeled in the Test Results class of Figure 2? A further source of ambiguity is the instrumentation software itself. Different studies may yield different results in part because of different instrumentation software. A discussion in one of the EXI documents illustrates the issues:

Features Need Stories

61

The results presented here come from a stored snapshot that has been judged sufficiently stable for making decisions. Even so, there is still some variation in the results. This is a concern especially with the C-based candidates that may exhibit enormous and inexplicable variance between different test documents. It is therefore likely that there are still some problems with how the test framework's Java code interacts with the C code of the candidates. Accordingly, the results from the C-based candidates were filtered more carefully, by eliminating results for individual documents that were obviously incorrect. In addition, the stableness review of the results paid careful attention to any improvements in these candidates in particular. [24] We could address this by adding classes of instrumentation, linking them to the test results in a manner similar to Figure 2. But should we? There will always be important contextual information that has not been modeled, that could in principle be modeled, but that would be expensive to model. The alternative is to decorate the feature model with informal elaborations: commentary, explanation, and discussion. The relationships between the formal entities serve to coordinate these informal elaborations into a coherent story that answers questions of the form, Who, Why, What, and How.

5 Elaborating the Feature Model with Stories Deciding where to draw the line between formalization and informal elaboration must take account of the goals of the model. In our case study, the purpose of the elaborated feature model is to help us choose one of the alternatives listed in Table 2. So let us see how this plays out. Transmission speed being one of the criteria, we consult the Compactness feature, which is effectively equivalent to transmission speed. But Compactness cannot be summarized in a single value. Instead, from the Compactness feature of a given candidate, we can trace back along the indicates relationship in Figure 2 to see those test results that tell us something about this candidate’s level of success in compressing various inputs. There may be many such test results for this one candidate, including tests by different organizations or individuals, using different test sets, different methodologies, and different instrumentation. Each test result should point to this information. In the simplest case, a single candidate outperforms all the other candidates, i.e., it consistently produces the smallest output over all test sets in all of the recorded tests. In that case, we can easily say that this candidate scores highest with respect to transmission speed. But of course that is not likely. It is even less likely that we can also identify a clear second-place candidate, third-place candidate, etc., which we would like to do because transmission speed is only one of ten evaluation criteria. Instead, we have to start asking questions, the answers to which start to provide us with a coherent story. For example: • Which test sets (if any) resemble our expected data? • Are the results consistent for those test sets? • Is the provenance of the test results credible?

62

S.C. Bailin

If the answers to any of these questions are less than conclusive—for example, if we are uncertain whether any test set closely resembles our data, or the results are not consistent, or the provenance is doubtful—then we have to delve deeper, asking more questions: • • • •

What was the context of a test? Who did the test, and what do we know of their agenda? Was the methodology rigorous? What is the source of inconsistency between this and the tests from other sources?

The answers to such questions may or may not be found in the elaborated feature model shown in Figure 2 and Figure 3, depending on how far one takes the model elaboration. The questions, however, are definitely not modeled explicitly. This http://www.w3.org/TR/xbcproperties/#compactness

Feature

assessedBy

http://www.w3.org/T R/2009/WD-exievaluation-20090407/

http://www.w3.org/XML/EXI /public-status.html

performedBy Evaluation

Stakeholders

Method

Test Results

mayCauseRevisionOf

http://www.w3.org/TR/2009/WD-exievaluation-20090407/#compactnessresults

motivatedBy

employs

yields

Goals mayCauseRevisionOf

http://www.w3.org/TR/xbcmeasurement/

http://www.w3.org/2003/09/ xmlap/xml-binary-wgcharter.html

Fig. 4. By incorporating story tags in the elaborated feature model we can guide the potential re-user directly to relevant information

illustrates a common problem with ontologies: they may be rich in information, but they tend not to be self-explanatory. Many ontologies suffer from an absence of documentation about why the information is there, and how to use it. This is where stories enter, because the emphasis in a story is on rationale. The persistent question, Why? is what distinguishes a story from a mere report. For example, rather than just telling us that a particular test set was modeled on the Canterbury corpus, it would tell us why the Canterbury corpus was used. Without knowing this we cannot fairly assess whether the test results are relevant to our problem. More generally, we would like the elaborated feature model to guide us to the following types of information:

Features Need Stories

• • • • • •

63

Who are the stakeholders? What are they trying to achieve? Why? Why is it non-trivial—what barriers must they overcome? What did they do to overcome these barriers? Were they successful? Why? Did some barriers remain, or new ones appear?

The last three question may be iterated until, eventually, success (or, perhaps, failure) is declared. For example, the Compactness feature for EXI can point us to the URI for the EXI evaluation, which in turn points to earlier documents addressing the above questions. This is the skeletal structure of a story. But more than that is possible. The questions actually suggest an ontology of stories, consisting (for example) of actors, goals, barriers, actions, and rationales. Discussions about candidates for reuse can be marked up to indicate explicitly the actors, goals, barriers, etc. that have been involved in developing, using, and reusing the candidates. The feature model can use such markup to point us to the information we need. This is illustrated in Figure 4 for the Compactness feature of the EXI alternative.

6 Conclusion Feature models are a powerful way to achieve reuse in well established domains, such as those admitting of a product line architecture. But much reuse occurs in situations where there is no unified domain model; rather, the candidates for reuse and the available knowledge about them have varied provenance. In such situations, features are less well-defined, and their meanings need to be elaborated through additional context. Stories, by definition, are situated in context and emphasize rationale. They therefore provide an effective way of enriching a feature model with the necessary context. We have illustrated this through a case study involving the transmission of structured data between two systems.

References [1] Bailin, S.: Diagrams and design stories. Machine Graphics and Vision 12(1) (2003) [2] Bailin, S., Moore, M., Bentz, R., Bewtra, M.: KAPTUR: Knowledge acquisition for preservation of tradeoffs and underlying rationales. In: Proceedings of the Fifth Knowledge-Based Software Assistant Conference. Rome Laboratory (September 1990) [3] Kang, K., Cohen, S., Hess, J., Novak, W., Peterson, A.: Feature-Oriented Domain Analysis (FODA) Feasibility Study. Carnegie Mellon University Software Engineering Institute Technical Report CMU/SEI-90-TR-021 [4] van der Linden, F., Schmid, K., Rommes, E.: Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering. Springer, Heidelberg (2007) [5] Bailin, S.: Software reuse as ontology negotiation. In: Bosch, J., Krueger, C. (eds.) Software Reuse: Methods, Techniques, and Tools. LNCS, vol. 3107, pp. 242–253. Springer, Heidelberg (2004)

64

S.C. Bailin

[6] Bailin, S., Simos, M., Levine, L., Creps, R.: Learning and Inquiry-Based Reuse Adoption (LIBRA). Wiley-IEEE Press (2000) [7] Abstract Syntax Notation: http://www.asn1.org [8] Sandoz, P., Triglia, A., Pericas-Geersten, S.: Fast Infoset, http://java.sun.com/developer/technicalArticles/xml/ fastinfoset/ [9] Ziv, J., Lempel, A.: A Universal Algorithm for Sequential Data Compression. IEEE Transactions on Information Theory 23(3), 337–343 (1977) [10] Efficient XML Interchange: http://www.w3.org/XML/EXI/ [11] Qing, X., Adams, C.: A comparison of compression techniques for XML-based security policies in mobile computing environments. In: Ottawa Workshop on New Challenges for Access Control (April 27, 2005) [12] Bzip: http://www.bzip.org/ [13] WAP Binary XML: http://www.w3.org/TR/wbxml/ [14] XML-binary Optimized Packaging: http://www.w3.org/TR/xop10/ [15] SOAP Message Transmission Optimization Mechanism: http://www.w3.org/TR/soap12-mtom/ [16] XMill: an Efficient compressor for XML, http://www.liefke.com/hartmut/xmill/xmill.html [17] Bournez, C.: Efficient XML Interchange Evaluation, W3C Working Draft (April 7, 2009), http://www.w3.org/TR/exi-evaluation [18] OASIS eXtensible Access Control Markup Language (XACML) TC, http://www.oasis-open.org/committees/ tc_home.php?wg_abbrev=xacml [19] Mundy, D.P., Chadwick, D., Smith, A.: Comparing the Performance of Abstract Syntax Notation One (ASN.1) vs. eXtensible Markup Language (XML). In: Terena Networking Conference 2008 / CARNet Users’ Conference 2008, Zagreb, Croatia (May 19-22, 2008) [20] Cokus, M., Winkiwski, D.: XML Sizing and Compression Study For Military Wireless Data, XML (2002) [21] XML Binary Characterization Use Cases: http://www.w3.org/TR/2005/NOTE-xbc-use-cases-20050331/ [22] Augeri, C.J., Bulutoglu, D.A., Mullins, B.E., Baldwin, R.O.: An Analysis of XML Compression Efficiency. In: Proceedings of the 2007 Workshop on Experimental Computer Science, San Diego, California (2007) [23] The Canterbury Corpus: http://corpus.canterbury.ac.nz/ [24] Efficient XML Interchange Measurements Note: http://www.w3.org/TR/2007/WD-exi-measurements-20070725/

An Optimization Strategy to Feature Models’ Verification by Eliminating Verification-Irrelevant Features and Constraints Hua Yan, Wei Zhang, Haiyan Zhao, and Hong Mei Key Laboratory of High Confidence Software Technology, Ministry of Education of China, Insititute of Software, School of Electronics Engineering and Computer Science, Peking University, Beijing, 100871, China {yanhua07,zhangw,zhhy}@sei.pku.edu.cn, [email protected]

Abstract. Feature models provide an effective approach to requirements reuse. One important problem related to feature models is the verification problem, which is NP-complete in theory. The existing approaches to feature models’ verification mostly focus on how to automate the verification of feature models using third-party’s tools, while these tools are usually designed to resolve general kinds of problems. However, by simply using these third-party’s tools, large-sized feature models still can hardly be verified within acceptable time. We argue that, to improve the efficiency of verification, the problem itself should be at first optimized. In this paper, we propose an optimization strategy to feature models’ verification, in which, verification-irrelevant features and constraints are eliminated from feature models and the problem size of verification is therefore reduced. We prove the correctness of this strategy, while experiments show the effectiveness of this strategy. Keywords: Feature model, Verification, Problem size, Reduction.

1 Introduction In software reuse, feature models provide an effective approach to modeling and reusing requirements in a specific software domain. The modeling responsibility of a feature model is achieved by encapsulating requirements into a set of features and clarifying possible dependencies among features. The reusing responsibility of a feature model is carried out through customization - that is, selecting a subset of features from a feature model, while maintaining those constraint dependencies among features. One important problem related to feature models’ customization is the verification problem. The verification of a feature model has two purposes. Before customization, the verification aims to find possible conflicts in constraints among features. After customization, the verification is intended to find possible conflicts in customizingdecisions on a feature model. Based on the discovery that constraints among features can be formalized as propositional formulas [4,7,1], the verification of a feature model can be formalized correspondingly as a set of propositional satisfiability (SAT) S.H. Edwards and G. Kulczycki (Eds.): ICSR 2009, LNCS 5791, pp. 65–75, 2009. © Springer-Verlag Berlin Heidelberg 2009

66

H. Yan et al.

problems, which are NP-complete in general. Because of the NP-complete nature, the verification of a complex feature model inevitably suffers from the state space explosion problem. For example, for a feature model with 1000 features and many complex constraints, the state-space of the verification problem is as large as 21000. Therefore, it is often infeasible to verify complex feature models without adopting any optimization strategy. In the existing research on feature models’ verification, most of them focuses on how to automate the verification of feature models using third-party’s tools (such as those SAT-solvers, CSP-solvers, and Model Checkers). However, as far as to our knowledge, very little work focuses on how to optimize the verification of feature models based on the characteristics of feature models’ verification (except some of our previous work [7,8]). Since those third-party’s tools are often designed to resolve general kinds of problem, it is impossible for them to incorporate any optimization strategy specific to feature models’ verification. In this paper, we propose an optimization strategy to feature models’ verification by eliminating verification-irrelevant features and constraints from feature models, and prove the correctness of this strategy. This strategy is developed based on the observation that most feature models contain some features and constraints that are irrelevant to feature models’ verification (in the sense that these verification-irrelevant features and constraints can be safely removed without changing the results of feature models’ verification), while the problem size of a feature model’s verification is exponential to the number of features and constraints in the feature model. Therefore, eliminating verification-irrelevant features and constraints from feature models will reduce the problem size of verification, and alleviate the state space explosion problem. Experiments have shown that this strategy improves the efficiency of and the capability to feature models’ verification. The rest of this paper is organized as follows. Based on some preliminary knowledge introduced in Section 2, Section 3 presents the optimization strategy to feature models’ verification, and gives its correctness proof. Experiments and analysis are shown in Section 4. Related works are discussed in Section 5. Finally, Section 6 concludes this paper with a short summary.

2 Preliminary In this section, we first give a notation for feature models with formal semantics of constraints among features, and clarify two kinds of constraint in feature models according to the source of constraints, and then introduce the criteria for feature models’ verification, which are proposed in our previous research [7]. 2.1 A Notation for Feature Models The symbols in this notation are listed in Table 1 and explained from the viewpoint of customization. The formal definitions of constraints among features are given in Table 2 and Table 3.

An Optimization Strategy to Feature Models’ Verification

67

Table 1. Symbols in the notation for feature models Symbol

Name

Explanation

A mandatory named “X”.

feature A mandatory feature must be selected in a customizing result,

X

An optional named “Y”.

feature

Y

if its parent feature is selected or it hasn’t a parent feature. If its parent is removed, it must be removed. An optional feature can either be selected in or be removed from a customizing result, if its parent feature is selected or it hasn’t a parent. If its parent is removed, it must be removed. A refinement connects two features. The feature connecting to the non-arrow end is called the parent of the other feature. A feature can only have one parent feature at most. A requires constraint connects two features. The feature connecting to the non-arrow end is called the requirer, and the other the requiree. This constraint means that if the requirer is selected, the requiree must be selected. An excludes constraint connects two features. This constraint means that the two features should not be both selected in a same customizing result. The left end connects to a composite constraint or to one of the right ends of a binding predicate. The right ends connect to a set of features or binding predicates. We define three types of binding predicate: and (denoted by ∧); or (denoted by ∨); xor (denoted by 1). See Table 2 for the formal definition of binding predicates. We define two types of composite constraint: requires (de); excludes (denoted by ). See Table 3 for noted by their formal definitions.

A refinement relation between two features. A requires constraint between two features. An excludes constraint between two features.

type

type

A binding predicate among a set of features and binding predicates A composite constraint between two binding predicate

Table 2. The formal definitions of binding predicates. In this table, A and B denotes features, and p and q denotes binding predicates. For a feature F, bind(F) is a predicate; it is true if F is selected, false otherwise. In our notation, we only use binding predicates as constituent parts of the composite constraints, but not as individual constraints. or(A, …, B, …, p, …, q)

Binding Predicate

type

A

type

A

p

bind(A)∨...∨¬bind(B) ∨...∨p∨...∨¬q

type

A

B

q

xor(A, …, B, …, p, …, q)

type

type

B

p

Formal Definition

and(A, …, B, …, p, …, q)

p

q

bind(A)∧... ∧¬bind(B) ∧...∧p∧...∧¬q

type

B

q

bind(A)⊗... ⊗¬bind(B) ⊗...⊗p⊗...⊗¬q

Table 3. The formal definitions of composite constraints. In this table, p and q denotes binding predicates. In the situation that p and q only contains one feature, the two types of composite constraints becomes the requires and the excludes constraints between two features. Composite Constraint Formal Definition

requires(p, q) p

type

type

p→q

excludes(p, q) q

p

type

type

p → ¬q

q

68

H. Yan et al.

2.2 Implicit Constraints and Explicit Constraints Constraints in feature models can be classified into two kinds according to their source. The first kind is the implicit constraints that are imposed by refinements relations between features. In feature models, each refinement relation implicitly imposes a requires constraint between the involved two features – that is, the child feature requires the parent feature. The second kind is the explicit constraints that are explicitly added into feature models by model constructors. Figure 1 shows a feature model example, in which, (a) is the refinement view, consisting of features and refinements between features, and (b) is the constraint view, consisting of those explicit constraints added by model constructors. Figure 1(c) shows all the constraints in the form of propositional formulas. The constraints from 1 to 6 are implicit constraints derived from the refinement view, and the constraints from 7 to 8 are explicit constraints. B

A

G

1. 2. 3. 4. 5. 6.

G

8.

F

D B

C

F

D

G

(a) Refinement view of the feature model

E

E B

(b) Constraint view of the feature model

bind(B) bind(C) bind(D) bind(E) bind(F) bind(G)

bind(A) bind(A) bind(A) bind(A) bind(C) bind(C)

7. ( bind(B) bind(D) bind(E) ) ( bind(F) bind(G) ) bind(B) bind(G) (c) Propositional formula view of the feature model

Fig. 1. A feature model example with explicit and implicit constraints

2.3 Three Criteria for Feature Models’ Verification In our previous research [7], we proposed three criteria for feature models’ verification. According to the deficiency framework for feature models [10], the three criteria can detect all the anomaly and inconsistency deficiencies. Due to space limitation, we just list the three criteria as follows without further explanations. 1. There exists at least a set of customizing decisions to all undecided features in a feature model that will not violate any constraints in the feature model. 2. Each undecided feature in a feature model has the chance to be selected without violating any constraints in the feature model. 3. Each undecided feature in a feature model has the chance to be removed without violating any constraints in the feature model. More information about what kinds of deficiencies exist in feature models and how the three criteria detect these deficiencies can be referred to literature [10] and [7].

3 Eliminating Verification-Irrelevant Features and Constraints In this section, we present the optimization strategy to feature model’s verification, and give the correctness proof of this strategy.

An Optimization Strategy to Feature Models’ Verification

69

3.1 The Optimization Strategy During feature models’ verification, one kind of errors (called implicit constraint violations) can be easily detected and fixed at first. This kind of errors occurs when a child feature is selected while its parent is not. By checking the binding states of two features in each refinement, implicit constraint violations can be detected. Then, these violations can be fixed by removing all the offspring features of the removed features and selecting all the ancestor features of the selected features. We have observed that certain features and constraints are irrelevant to the verification after handling implicit constraint violations. That is, these features and constraints can be safely eliminated without changing the verification results. Based on this observation, we develop an optimization strategy to feature models’ verification. This strategy is based on the following two concepts. Definition 1. Verification-irrelevant features. A feature is verification-irrelevant, iff this feature does not appear in any explicit constraint, and none of its offspring features appears in any explicit constraint. Definition 2. Verification-irrelevant constraints. A constraint is verification-irrelevant, iff at least one feature involved in this constraint is verification-irrelevant. Figure 2 shows the verification-irrelevant features and constraints in a feature model example. After eliminating these verification-irrelevant features and constraints, this feature model is reduced to the feature model in Figure 1.

A B B

C

D

F

E D

G I1

F

G

I2

I3

I4

I5

I6

I7

I8

(a) Refinement view of the feature model

E B

G

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.

15. ( bind(B) ( bind(F) bind(B)

16. (b) Constraint view of the feature model

bind(B) bind(C) bind(D) bind(E) bind(F) bind(G) bind(I1) bind(I2) bind(I3) bind(I4) bind(I5) bind(I6) bind(I7) bind(I8)

bind(A) bind(A) bind(A) bind(A) bind(C) bind(C) bind(B) bind(E) bind(E) bind(F) bind(F) bind(F) bind(I2) bind(I2) bind(D) bind(E) ) bind(G) ) bind(G)

(c) Propositional formula view of the feature model

Fig. 2. A feature model example. The verification-irrelevant features and constraints are shown in the grey area. There are 8 verification-irrelevant features (I1 to I8 in (a)) and 8 verificationirrelevant constraints (7 to 14 in (c))

Based on the above two definitions, the optimization strategy can be expressed as follows. Given a feature model without implicit constraint violations, eliminating those verification-irrelevant features and constraints from this feature model will not influence the verification result of this feature model.

70

H. Yan et al.

Following this strategy, we can deduce that the feature model in Figure 2 and the one in Figure 1 are equivalent from the verification point of view if the feature model in Figure 2 contains no implicit constraint violations. 3.2 The Correctness Proof We prove the correctness of this strategy by two theorems. In the first theorem, we show that, after handling implicit constraint violations, if the reduced feature model satisfies the three verification criteria, the original feature model will also satisfy these criteria. To prove this theorem, three lemmas are first introduced. In the second theorem, we show that, if the original feature model satisfies the three verification criteria, the reduced feature model will also satisfy them. Based on the two theorems, the correctness of this strategy can be naturally deduced. In the following, we use two pairs and to denote the original feature model and the reduced feature model, respectively. In the two pairs, F and F’ denote the feature sets of the two feature models, and C and C’ denote the constraint sets. In addition, we use to denote the feature model consisting of the feature set F and the set of verification-irrelevant constraints C−C’ being removed from the original feature model. The three verification criteria (see Section 2.3) on a feature model x are denoted by VerifyC1(x), VerifyC2(x) and VerifyC3(x), respectively. The conjunction of the three criteria is denoted by Verify(x).

∧

Lemma 1. ├ (VerifyC1() VerifyC1()) → VerifyC1() Proof: After handling implicit constraint violations, VerifyC1() is true, then, the assignment of F’ can be expanded to the assignment of F by giving each undecided eliminated feature a removing customizing decision, which will not cause any conflict.

∧

Lemma 2. ├ (VerifyC2() VerifyC2()) → VerifyC2() Proof: Model reusers can select all the undecided eliminated features without violating any constraint.

∧

Lemma 3. ├ (VerifyC2() VerifyC2()) → VerifyC2() Proof: Model reusers can remove all the undecided eliminated features without violating any constraint. Theorem 1. Verify() ├ Verify() → Verify() Proof: We can deduce from Lemma 1, Lemma2 and Lemma 3 that ├ (Verify() Verify())→Verify()) Thus, ├ (Verify() Verify())→Verify()) Verify() Verify () ├ Verify () Verify() ├ Verify() → Verify()

∧

⇒ ⇒

∧

∧

Theorem 2. ├ Verify()→Verify() Proof: F’ F, C’ C ├ Verify() → Verify()

⊆

⊆

⇒

Corollary. Verify() ├ Verify() ↔ Verify()

An Optimization Strategy to Feature Models’ Verification

71

4 Experiments In this section, we first introduce an algorithm of generating random feature models, and then apply our optimization strategy to the verification of a set of randomly generated feature models to demonstrate the effectiveness of this strategy. 4.1 An Algorithm of Generating Random Feature Models as Test Cases To provide test cases for our experiments, we design an algorithm of generating random feature models (see Algorithm 1). Algorithm 1. An algorithm of generating random feature models. In this algorithm, GetRandomInt(n) is a function that returns a random integer from 0 to n. Input:

fN cN mNC mW

: : : :

p

:

The number of features of the feature model. The number of explicit constraints of the feature model. The maximum number of features in the constraints. The maximum number of children of a feature. Its default value is 10. The percentage of verification-irrelevant features in the feature model. Its default value is -1, which means that the percentage of verification-irrelevant features is random.

Output: The random generated feature model generate_random_fm(int fN,int cN,int mNC,int mW=10,int p=-1){ FeatureModel fm = new FeatureModel(); Queue queue = new Queue(); Feature f = new Feature(); queue.push(f); int counter = 1; while(!queue.isEmpty()){ Feature parent = queue.pop(); for(int i = 0; i < GetRandomInt(mW); i++){ Feature child = new Feature(); parent.addChild(child); fm.featureSet.add(child); counter++; if (p != -1 && counter experts--> documents, and allows us to perform quicker database input/output (I/O) on a maximum of two tables at a time. In terms of performance, our synonym queries on the WordNet database comprise by far the heaviest data processing task of the entire system. This comes about as a consequence of two factors. First, WordNet is split into several large tables: synsets, hypernyms, hyponyms, and antonyms, all of which represent in excess of 250,000 records (in fact, WordNet is much larger than that, but we only use a smaller portion of it). Second, we made a design decision to query all four tables in a single statement, and aggregate all items in a single result set. This extra processing takes long to complete, but has Graph1- QueryTime the advantage of presenting the user with a single operation, instead of forcing the user to perform several queries. Current searches can vary considerably in time. For instance, the query for the word "extensive" takes no more than 2 seconds to complete (it only returns 1 record), while the query for "system" takes approximately 15 seconds (it brings back in excess of 120 records). In all, performance is considered acceptable as we have tested the scenarios in Table 1. For example, the first line of the table indicates that when the system has accumulated 300 domain analysis projects (say, from different

DAREonline: A Web-Based Domain Engineering Tool

253

users), a single user should be able to open one of his/her domain analysis projects and view all of its items in approximately 25 seconds (query time + page transition). This number reflects the amount of time to display the page with all of its associated items, but may be higher when users decide to spend time on each page. This number also assumes that the 300 projects are each comprised of 3 exemplar systems, 5 experts per system, 25 document sources per system, 2 system characteristics, and 1 scope statement. Graph 1 shows that the query time for the site grows significantly with an increasing number of domain analysis projects. With 10000 domain analysis items, it would take the user approximately 360 seconds to open and view one single project among those 10000. At closer inspection, however, it becomes apparent that the number of exemplar systems is the factor that dictates performance, rather than the overall number of domain analysis projects that users have introduced into the system. This can be explained by the fact that systems can carry a heavy load of associated items, such as names of experts and lists of document sources, as mentioned previously. Our server runs Linux as the OS and Apache Tomcat 5.5 as the web server. Both the web pages and the database are currently housed in the same machine.

3 Evaluation

Fig. 3. DAREonline Activity Flow

DAREonline was initially tested in a graduate software quality and design class at Virginia Tech. A group of 49 students were given access to the site and instructed to use it in its full capacity, or to just try parts of it as a helping tool while using DARE COTS. Of the 18 respondents, 25% had no more than 1 year of computer

254

R.F.D. Santos and W.B. Frakes

programming experience, 37% had between 1 and 3 years, 13% had 3 to 5, and 25% had more than 5. Being the first release of DAREonline, some issues had already been documented and certain enhancements had already been envisioned, though not yet worked on. Our goals were to: understand if the site flow was consistent with the steps an analyst would take while performing domain analysis; verify how easy it was to understand the various pieces of functionality; and obtain an overall satisfaction rating from participants. As shown in Figure 3, the initial page of DAREonline was designed as a sequence of steps that we believed would “make sense” in a domain analysis project. While there are many different sequences to the way a domain analysis project can be performed, this flow proposes a top-down organization in which the overall scope of the domain should be established early on. This idea underlies the fact that the analyst should have a good grasp on what the domain in question does or does not do, before moving on to the next steps. Our previous study had shown that improper scoping lead to serious problems in the domain analysis [12]. However, it must be said that DAREonline does not programmatically enforce that users establish a domain scope as the first step. In this sense, DAREonline takes a “passive” role since users are free to go about the site without any predefined order. One limitation, however, has to do with exemplar systems. A system is a parent element of a document, an expert, or a system characteristic. Therefore, at least one system must be created before any of the aforementioned components are created. This explains why Systems are the second element of the flow in Figure 3. Identifying documentation for software systems is an important part of Domain Engineering. Documents such as logs, diagrams, and source code, can be used with the vocabulary and code analysis tools to mine many pieces of information, such as repeated code structures, common classes, and word frequencies. When some of these items have been identified as features, they can be plugged into feature or facet tables and saved for later use. The last item of the flow is a diagramming tool.

Graph 2 - Survey Responses

Graph 3 - DARE COTS Ratings

DAREonline: A Web-Based Domain Engineering Tool

255

In our study, there is no clear method to evaluate the usefulness of the proposed flow. We therefore investigated the number of data items that were created in order to see the extent of usage, as it may provide clues into success or failure. In a period of 30 days, there were 1,780 hits to DAREonline pages that resulted in the creation of 97 domain analysis projects. Out of those, 31 were “empty stubs”, meaning that the user created the initial project, but did not follow through with it (nothing was added). This points to users who were possibly trying out the system for the first time and experimenting with it. Further, there were 55 projects that were incomplete”, meaning that users added certain data points, but not others. We consider “incomplete” any project that lacks one or more of the following: at least one exemplar system, at least one system characteristics form, at least one piece of documentation, and at least one expert. Finally, 11 projects were created with a minimum number of the items above, and are considered “complete”. Due to the high number of empty or incomplete projects, we can speculate that most users employed DAREonline as a guiding tool rather than the principal tool for their analysis. DAREonline is clearly more restrictive than DARE COTS, but may be more assistive. In addition, the fact that it is a new tool carries with it a certain amount of getting used to, which may at first discourage usage. Class participants were asked to grade DAREonline in terms of its ease of use, functionality, and how much it helps understand the DARE framework (Graph 2). Most participants agreed that DAREonline is helpful in pointing to what needs to be done, as all answers fell in the fair, good, and excellent categories. As for functionality, the results reveal a certain amount of satisfaction with the various tools, but leave room for much improvement. This was expected. All users rated functionality fair or good. In terms of ease of use, the results are scattered across the board. 12% rated it poor, 12% excellent, with the remainder (38% each) finding ease of use either fair or good. A closer look at the vocabulary analysis tools (data not shown in graphs) indicates that 62.5% of users found the lexical analysis tool to be good, while the word counter received 50%, and the stemmer 37.5%. The synonyms tool was less utilized, as 37% did not respond to having used it. The remainder conveyed mixed satisfaction ranging from poor to good almost equally. When compared with DARE COTS (Graph 3), DAREonline’s overall satisfaction falls somewhat short. DARE COTS receives high grades possibly due to its flexibility in the choice of tools that can be used, among other reasons. Users suggested that some tools should be integrated with one another (e.g., allow output of one tool to serve as the input to another, in order to facilitate vocabulary analysis). In addition, they reported that DAREonline could benefit from online examples of how to perform various actions.

4 Conclusions and Future Work Over time, the DARE framework has been implemented on different operating systems (e.g., Windows and Linux) and supported by several programming languages (e.g., C and VB). We now present DAREonline, a web-based application that assists users implementing domain engineering tasks under the DARE framework. More specifically, we take the domain book concept and create a centralized environment with tools for domain analysis. In addition, we propose the use of web services to

256

R.F.D. Santos and W.B. Frakes

obtain data and functionality externally. We target SOA components for their strong reuse potential across distributed environments. Our goal is to provide a repository of functions that is helpful in domain analysis while maintaining ease of use throughout the application. DAREonline is designed with open-source tools, some of which are developed and maintained in-house, and others provided by third parties. DAREonline has certain advantages over previous versions: platform independence as it requires only a browser and a standard Java Runtime Environment; centralized deployment when changes are necessary; easy integration of new tools; a structured and more assistive interface and fast data processing. This paper describes the object model, the data model, and the tools that currently support DAREonline. This first release was made available to Virginia Tech students who rated it according to its ease of use, functionality, and helpfulness in understanding the DARE framework. While results were mixed, we envision many enhancements that can be introduced in order to make DAREonline more robust. For example, we plan to investigate how workflow languages (e.g., EBPL, WSFL) can be leveraged to identify and schedule the execution of reusable services as part of our SOA research. We must also understand how to assure software quality given that web services are often disconnected components over which service consumers have little control. In addition, we plan to introduce upload/download capabilities for documents as well as a search tool. We continuously examine tools that can be added to the repository, such as software for code analysis. Our initial results motivate us to continue pursuing intelligent options to support the DARE framework.

References [1] Frakes, W., Prieto-Diaz, R., Fox, C.: DARE: Domain Analysis and Reuse Environment. Annals of Software Engineering 5, 125–141 (1998) [2] Frakes, W.B., Baeza-Yates, R.: Information Retrieval: Data Structures and Algorithms. Prentice-Hall, Englewood Cliffs (1992) [3] http://www.comp.lancs.ac.uk/computing/research/stemming/ index.htm (last accessed on May 09, 2009) [4] http://findbugs.sourceforge.net/ (last accessed on April 12, 2009) [5] http://www.jfimage.com/ (last accessed on May 06, 2009) [6] http://java.sun.com/developer/technicalArticles/Programming/ jnlp/ [7] Alonso, O., Frakes, W.B.: DARE-Web: Domain Analysis in a Web Environment. In: AMCIS Americas Conference on Information Systems, Long Beach, CA (2000) [8] Frakes, W., Prieto-Diaz, R., Fox, C.: DARE-COTS A Domain Analysis Support Tool. In: XVII International Conference of the Chilean Computer Society, Valparaiso, Chile, pp. 73–77. IEEE Press, Los Alamitos (1997) [9] Frakes, W.: A Method for Bounding Domains. In: IASTED International Conference on Software Engineering and Applications, Las Vegas (2000) [10] Paice, C.: An evaluation method for stemming algorithms. In: Proceedings of the 17th Annual International ACM SIGIR Conference on Research and Development in Information Retrieval, Dublin, Ireland (1994)

DAREonline: A Web-Based Domain Engineering Tool

257

[11] Java Security Architecture, http://java.sun.com/j2se/1.4.2/docs/guide/security/ spec/security-specTOC.fm.html (last accessed on May 07, 2009) [12] Frakes, W., Harris, D.: Domain Engineering: An Empirical Study, http://eprints.cs.vt.edu/archive/00000936/01/ techReportDomainEngineering.htm (last accessed on May 09, 2009) [13] Frakes, W., Kang, K.: Software Reuse Research: Status and Future. IEEE Transaction on Software Engineering 31, 529–536 (2005)

Extending a Software Component Repository to Provide Services Anderson Marinho1, Leonardo Murta2, and Cláudia Werner1 1

PESC/COPPE – Universidade Federal do Rio de Janeiro Rio de Janeiro – RJ – Brazil {andymarinho,werner}@cos.ufrj.br 2 Instituto de Computação – Universidade Federal Fluminense Niterói – RJ – Brazil [email protected]

Abstract. A Software Component Repository is a tool that supports component based development (CBD). Generally, most of the existing repositories only provide components physically, not considering another important way of providing them: as services. Therefore, this paper presents an infrastructure for providing component services in a component repository. This infrastructure deals with access control, utilization monitoring, components to services conversion, and composite services generation issues. Keywords: CBD, SOA, component, service, repository, pricing.

1 Introduction Software reuse is the discipline responsible for creating software systems from existing software [1]. This discipline is considered a form of gaining better indicators of quality and productivity in the construction of complex systems [2]. One of the paradigms used is Component-Based Development (CBD), which aims at the development of interoperable components to be reused when building new systems [3]. In CBD, an important tool is a component repository that consists of a place for publication, storage, search, and retrieval of components [4]. Normally, components in a repository are physically distributed. It means that in order to use a component it is necessary to download its files and deploy them in a specific platform. However, in some scenarios this kind of usage has drawbacks, such as low interoperability, which makes component reuse difficult in different platforms. Moreover, different organizations are adopting outsourcing, transferring to third-parties their development and production infrastructures. To overcome these issues, an alternative is to distribute components as services. Services solve interoperability and outsourcing issues since they are not executed in the requester's machine, but in a remote provider [5]. Therefore, there is no need to deploy components in specific platforms. Services also use standard languages and protocols, which are common in any information technology environment. Moreover, services have been considered to be a major step to distributed [5] and demanding [6] S.H. Edwards and G. Kulczycki (Eds.): ICSR 2009, LNCS 5791, pp. 258–268, 2009. © Springer-Verlag Berlin Heidelberg 2009

Extending a Software Component Repository to Provide Services

259

computing. Regarding the former, services may be offered by different enterprises over the internet, constituting a distributed computing infrastructure. From that infrastructure, new applications can be constructed via the collaboration of different enterprises. Regarding the latter, processing will not be made locally but purchased by services offered in the Web, just like electricity or communication services [6]. For that reason, repositories should be prepared for the market needs and be extended by providing components not only physically but also as services, which results in a greater reuse perspective. However, this evolution must be carefully made in order to provide services in a similar way as components. Hence, some issues must be considered, such as access control, utilization monitoring, contract establishment, pricing, among others, which are the basic functionalities in a repository. Even though these functionalities are, in a certain way, easy to be applied in components, this situation is not the same regarding services. The main reason is due to the fact that services are not something concrete, which a repository can keep under control. Services may be hosted in remote providers, out of reach of the repository. For that reason, keeping them under control is a challenge. Another difference between providing components and services is related to the resources required to provide them. A hosting server is necessary to provide services. However, not all users of a repository have this kind of resource available. Therefore, a repository can actively participate in this sense, providing resources to allow users to publish their own services. These resources can be taxed by the repository (e.g., discounting a stipulated percentage over the service price) in order to pay back the costs involved to maintain the services. Hence, a repository can offer three types of mechanisms to help producers to create and provide their services: (1) mechanisms of services generation from previously published components, dealing with producers who have no resources to provide services; (2) external services publication mechanisms, dealing with producers who already provide services and want to publish them in a repository; and (3) mechanisms for the generation of services from the composition of existing ones, dealing with producers who have no resources to provide services and no specific component to generate a new service, but want to create and publish a new service from the composition of existing ones. The goal of this paper is to describe an infrastructure for service reuse implemented in a component repository, enabling two perspectives of component usage: physical or as a service. This infrastructure deals with access control, utilization monitoring, components to services conversion, and composite services generation issues. The remaining of this paper is organized as follows. Section 2 presents the redesign of a component repository to host services. Section 3 presents some related work. Finally, Section 4 concludes the paper, presenting some limitations and future work.

2 Services in a Component Repository This section presents an approach for extending a component repository to provide services. This approach was implemented in the Brechó repository [7]. Brechó is a web information system that goes beyond a simple repository with basic functionalities such as documentation, storage, publication, search, and retrieval of software components. Brechó provides advanced functionalities that enable its use for both

260

A. Marinho, L. Murta, and C. Werner

commercial and non-commercial purpose. Some of these functionalities are: management of contracts that connect producers, consumers, and acquired components; mechanism for component pricing; mechanisms for component evaluation; and mechanisms for marketing and negotiation. Therefore, some detail about Brechó’s implementation will be discussed along this section for better understanding of our approach. However, it is important to notice that we used Brechó as guinea pigs to validate the idea of supporting both physical components and services in a repository. Our approach is not restrict to Brechó, and can be implemented in other repositories. One of our concerns of transforming a conventional component repository in a service-enabled component repository is to provide services in an analogous manner to physical components. It means that the services published in the repository should be supported with access control and utilization monitoring mechanisms. These mechanisms are important to make the repository proactive, not only for service discovery but also for service utilization. Different functionalities can be derived from the repository participation at the service utilization moment. One of them is service charging, which can be easily applied when services have access control. Charging is very important, mostly to commercial repositories, since providing services implies in costs. Another functionality is the utilization monitoring, which enables the capturing of important information about the service utilization. In Brechó, for instance, the utilization monitoring mechanism captures information about the service consumer, the operation requested, and the price paid for the service. This kind of information can help both producers and consumers to improve their selling and purchases, respectively, in the repository. For instance, a producer can adjust the service prices according to the usage frequency. On the other hand, a consumer can use this information as a reliability parameter of a service, especially if it is complemented with satisfaction feedback [8]. As mentioned before, we defined three strategies for publishing services in the repository: external services, for already existing services; hosted internal services, for services generated from previously published components in the repository; hosted composite services, for services constructed from the composition of external and internal services. In a general way, each publication strategy presents some difficulties in its implementation. Regarding hosted internal services, the major issue is related to the generation of services from components. This generation is complex because a component may be written in any programming language, and each language has a distinct way to provide services. On the other hand, the external services issue is related to how to adapt these kinds of services to provide access control and utilization monitoring mechanisms. It is complex because they are deployed outside the repository. Regarding hosted composite services, the main difficulty is the implementation of an engine to execute these services. The engine should be able to instantiate a composite service from BPEL specification [9] and orchestrate it. Fig. 1 shows the architecture of a components’ repository extended with the service infrastructure. The main idea of this architecture was to maintain the repository with only component and service management basic functionalities. The most complex mechanisms for service publishing and generation were transferred to specific modules. These modules can be classified into three types: Language specific modules, which generate services from components written in a specific programming language, Legacy module, which adapts existing services to work according to the repository’s access

Extending a Software Component Repository to Provide Services

261

control and utilization monitoring mechanisms, and Orchestrator module, which produces composite services from BPEL descriptor documentation. This architecture division between basic and complex functionalities is important, because it makes the repository adaptation easier. Therefore, a repository should change its core to support only the service management and the module communication API. The modules implementation is done separately, since they do not depend on the repository.

Fig. 1. Component repository extended with services infrastructure

The communication between modules and the repository is done through a services API defined by the repository. This API defines, at a high level, the modules operation and can be classified into two types: API for service publishing and API for service utilization. The first type is related to the communication between module and repository during the service publishing and removal processes. This type of API is defined differently for each module. It is due to the fact that the modules have different services publishing processes. The second type of API is related to the service utilization process. It is used by modules to communicate with the repository during a service request, having the purpose of performing the access control and utilization monitoring functionalities. This API, however, does not differ for each module, as the service utilization process is the same for everyone. Fig. 2 shows the service utilization process. In the first step, the consumer requests the service, sending authentication information and service parameters. The service request goes directly to the module where the services are hosted. When the module receives the request, it communicates with the repository to perform the authentication and verifies if the consumer is authorized to use the service or not. In the positive case, the service request is registered, and then the module forwards the request to the service. At the end of the process, the module returns the result to the consumer.

Fig. 2. Service utilization process

262

A. Marinho, L. Murta, and C. Werner

The following sections present the three types of services modules, describing their main functionalities. 2.1 Language Specific Modules These modules are responsible for generating services from software components. In principle, each module is responsible for generating services from components written in a specific programming language. This feature is due to the lack of a generic solution for building services. Therefore, the repository should activate the appropriate module according to specific requirements and generate services from components coded in a specific programming language. For instance, if a repository just works with Java and .Net components, two language specific modules are needed. The architecture of a language specific module can vary for each programming language. For that reason, we chose Java as one example of language specific module. The Java module architecture is composed of four main elements: session manager, reflection engine, service generator, web service hosting service, and the deployer. The session manager is responsible for controlling the service generation states for each component requested by the repository. The reflection engine uses a reflective API [10] to extract information of component classes to construct the services. In this case, the engine uses the Java reflection API. The service generator and web service hosting service are the most important elements of the Java module. They are responsible for exposing Java classes as services and hosting them to be used by the repository consumers. These two architectural elements can be implemented by Apache Axis2 tool [11]. Axis2 is widely used in Java developing to construct services from Java classes. Apache Axis2 is a good option to the Java module since it provides many features that ensure the module mechanism operation. For example, Axis2 enables the classpath configuration of Java applications that will be exposed as services. This feature is important because it allows that each component that will be exposed as service has its own classpath, eliminating the problem of components that have ambiguous classes but are functionally different. This kind of situation happens in a repository all the time. Another important feature is that Axis2 works with the web services official security specifications, such as WS-Security [12]. This specification is essential to enable the access control and the service utilization monitoring mechanism. The deployer element is used to intermediate the communication between the module and Axis2. This element is responsible for preparing a component to be deployed or undeployed to Axis2. The deployer element creates service configuration files and uses Axis2 API to perform the communication. Regarding the service generation process, it can be done automatically or semiautomatically. In the first case, all the component functionalities are automatically defined as service operations. However, working in this way, the process ignores the fact that the producers may want to define which component functionalities they want to expose as service. In the second case, the producers participate more actively in the process, defining the operations that will be included in the service. Nevertheless, the process becomes semi-automated. In order to make the service generation process more flexible for producers, the language specific module works in a semi-automatic manner. Thus, the process is characterized by three stages: (1) to analyze and extract

Extending a Software Component Repository to Provide Services

263

the component operation candidates; (2) to allow the user to select the desired operations; and (3) to generate the service. In order to illustrate the service generation process, Fig. 3 shows the screenshots for creating internal services in Brechó. At the first step, the user should fill in a form, which requires some information to create an internal service, as shown in Fig. 3.a. This information is: name, description, price, and the programming language in which the component has been coded. This last information is needed to allow the selection of the appropriate language specific module to communicate with. When the user submits the form, the repository communicates with the module, sending a component and requesting the operation candidates that can be extracted from it. According to the module, the operations or methods of the component are analyzed and transmitted to the repository (Stage 1). The available operations for the service are shown in a new screen, according to Fig. 3.b. These available operations are extracted from the component in which the user previously chose to publish the service. In this example, a service is being generated from a Java component. The available operations are shown in a tree form, where nodes represent classes and leaves represent methods (the operations to choose from). According to Fig. 3.b, the sine and cosine methods were selected as operations of the service that will be generated (Stage 2).

(a)

(b)

Fig. 3. Internal service registration screens

After that, Brechó sends this data to the module to initiate the service generation (Stage 3). In the Java module case, the deployer communicates with Axis2 to request the creation of a new service. Based on the component and its selected functionalities, the deployer creates the deploy configuration file for the service and communicates with Axis2 sending along the component files. At the end, the service descriptor (i.e., WSDL [13]) of the new service is sent to Brechó to finish the service publication. 2.2 Legacy Module The Legacy module has the duty of adapting external, or legacy, services to the repository context. This adaptation consists of the insertion of access control and utilization monitoring mechanisms in the service with the purpose of having the repository to participate at the service utilization as well as service discovery moment. Nevertheless, this adaptation is complex, since these services are hosted in a remote server,

264

A. Marinho, L. Murta, and C. Werner

out of reach of the repository. A solution to this problem is to make this adaptation indirectly through the generation of another service, which works as a broker. The broker service intermediates all the requests to the external service in order to perform the access control and utilization monitoring mechanisms. Fig. 4 shows the broker service operation. The broker service receives the request from the user and communicates with the repository to authenticate and authorize him. If the user is authorized, the broker service adapts the request message written in SOAP protocol [14] to fit to the external service specification. This adaption consists of removing the user authentication header and changing some namespaces values. Afterwards, the adapted SOAP message is sent to the external service, which processes and returns the response to the broker service. In the last step, the broker service receives the response and forwards it to the user.

Fig. 4. Broker service operation

Each broker service is constructed based on the external service characteristics that it represents. This means that broker services provide the same communication protocols, and service operation signatures provided by the external services. It is important because it allows the external services to be used in the same way that they are used out of the repository. The main difference between the broker service and the external service specification is the addition of WS-Security protocol to provide the access control mechanism. The Legacy module architecture is composed by three main elements: web services hosting server, message adapter, broker service generator. The web services hosting server is the element responsible for hosting the broker services that are used to represent the adapted external services. Likewise in language specific modules, the Axis2 tool can be used to play this role. The message adapter has the task of receiving a request SOAP message and adapting it to the external service specification. In order to work properly for each external service, this component is configured and attached to each broker service. Finally, the broker service generator element is responsible for constructing broker services for each external service. They are constructed based on the external services specification document (WSDL), which contains all necessary information, such as operation service signatures, interface, and protocol definitions. The broker service generator is responsible for constructing the message adapter application, according to the external service, and the access control and utilization monitoring mechanisms that are used by Axis2 to generate the broker service.

Extending a Software Component Repository to Provide Services

265

Fig. 5.a shows external services being published in Brechó. This form is similar to the internal service form. The only difference is the replacement of the programming language field by the WSDL field. This field requires the URL location for the WSDL of the external service that the user wants to publish. When the user submits the form, the service is published. However, in this moment, Brechó transparently communicates with the Legacy module to adapt the external service provided by the user. 2.3 Orchestrator Module Having internal and external services published in the repository, the next step is to enable producers to publish new services from the composition of existing ones in the repository. The orchestrator module was designed to fulfill this task. This module is responsible for creating and hosting composite services from BPEL specification files. These services can be composed of not only services published in the repository but also external services that were not published yet. Furthermore, the composite services generated by this module provide access control and utilization monitoring mechanisms just like the services that are generated or adapted by the other modules. The architecture of the Orchestrator Module may be classified into four main elements: service orchestration engine, web service hosting server, deployer, and configurator. The service orchestration engine is responsible for coordinating the execution of a composite service. This engine invokes each service that is part of a composite service following a BPEL specification. This specification describes the service execution order and the data that are exchanged between them. The web service hosting server works together with the service orchestration engine hosting the composite services. A tool that can be used to represent these two elements is Apache ODE [15]. This tool creates and hosts composite services from BPEL specifications. Specifically, ODE supports both current WS-BPEL 2.0 [9] and legacy BPEL4WS 1.1 [16] specifications. The deployer element is used by the Module to communicate with the web service hosting server to perform the service deployment process. The deployer element is constructed according to the web service hosting server and service orchestration engine used. In case of using Apache ODE, the deployer is constructed according to it. Finally, the configurator element is responsible for setting up the composite services to support the access control and utilization monitoring mechanisms. This configuration is made before the service deployment process. In Brechó, Apache ODE is used, hence the composite service generation process in the Orchestrator Module is defined by the following steps: (1) Setting up the access control and utilization monitoring mechanisms in the composite service; (2) performing the service deployment in Apache ODE; and (3) returning the composite service specification (WSDL) to the repository. Fig. 5.b shows composite services being published in Brechó. This form is very similar to the previous one, only differing by the addition of a ZIP file field. This field requires a zip file that should contains all the documents necessary to generate a composite service. For example, this file must contain the BPEL file, which describes the composite service execution, and WSDL files, describing the composite service interface and the simple services that are used by it. However, this last type of WSDL files is optional depending on how the BPEL specification is coded. When the user submits this information, Brechó communicates with the Orchestrator module, requesting the

266

A. Marinho, L. Murta, and C. Werner

generation of a new composite service and sending the zip file submitted by the user. When a new request arrives, the Orchestrator Module triggers the configurator element for setting up the access control and utilization monitoring mechanisms in the composite service. This configuration is done through the generation of scripts that are attached to the service at deployment time in Apache ODE. The scripts will be triggered every time a new request arrives to the service. Having done the configuration, the deployer element is activated to perform the composite service deployment in Apache ODE. It sends to Apache ODE the composite service descriptor files, and the scripts generated by the configurator element. At the end of the process, the WSDL of the new service is sent to Brechó to finish the service publishing.

(a)

(b)

Fig. 5. Legacy and composite service publish screens

3 Related Work There are some related works that deal with the presented problem. A similar work from Lee et al. [17] presents a mechanism to service generation from components in a repository. This work does not provide a solution to the problem of components written in different programming languages. It is limited to Java and C++ components, and the mechanism is not extensible to support other languages. This approach does not provide a solution for access control and, consequently, utilization monitoring of services. In addition, it is not concerned about service composition. Another work from Smith [18] deals with reflection to generate services dynamically. This work, differently from ours, does not present to the user a preview of the possible service operations that can be extracted from an existing application. Moreover, the tool does not generate a WSDL document to the new service. There are some commercial tools to service repositories [19,20], but these tools do not provide service generation mechanisms, neither from components nor BPEL descriptors. They do not treat access control either.

4 Conclusions This paper presented an infrastructure for enabling services in a software component repository. This infrastructure provides specific mechanisms for access control and

Extending a Software Component Repository to Provide Services

267

utilization monitoring, besides automated mechanisms for service generation from either software components or BPEL descriptor documents. The access control and utilization monitoring mechanisms are important, but increase the load of the repository, since all service requests need to be processed in the repository. Nevertheless, this issue can be solved by placing modules distributed in different machines to balance the load. Another issue is the increase of the service response time due the repository intervention. This issue, however, cannot be solved with the prior strategy. An alternative solution is to let the insertion of these mechanisms optional during the service publication. The drawback is that these services will not support all repository functionalities, such as pricing, consumers list, etc. The current version of the infrastructure only provides support for converting components written in the Java programming language. Besides, the Java module imposes a restriction on the programming style, which forces that all java components classes should follow the JavaBean specification [21]. We are planning to implement additional specific modules to other programming languages, such as .Net, C++, etc. The current version of Brechó, including the service management support described in this paper, can be found at http://reuse.cos.ufrj.br/brecho. It is at this moment under an initial usage evaluation in an academic setting. However, we intend to submit Brechó to a more systematic evaluation in commercial settings in the near future. Acknowledgments. The authors would like to thank CAPES, CNPq and FAPERJ for the financial support, and to all participants of Brechó Project.

References 1. Krueger, C.: Software reuse. ACM Comput. Surv. 24, 131–183 (1992) 2. Frakes, W., Kang, K.: Software Reuse Research: Status and Future. IEEE Trans. Softw. Eng. 31, 529–536 (2005) 3. Szyperski, C.: Component Software: Beyond Object-Oriented Programming. AddisonWesley Professional, Reading (1997) 4. Sametinger, J.: Software Engineering with Reusable Components. Springer, Heidelberg (2001) 5. Papazoglou, M.: Service-oriented computing: concepts, characteristics and directions. In: Proc. of the Fourth International Conference on WISE 2003, Rome, Italy, pp. 3–12 (2003) 6. Smith, M., Engel, M., Friese, T., Freisleben, B.: Security issues in on-demand grid and cluster computing. In: Sixth IEEE International Symposium on Cluster Computing and the Grid Workshops, 2006, Singapore, pp. 14–24 (2006) 7. Brechó Project, http://reuse.cos.ufrj.br/brecho 8. Santos, R., Werner, C., Silva, M.: Incorporating Information of Value in a Component Repository to Support a Component Marketplace Infrastructure. In: 10th IEEE IRI, Las Vegas, USA (to appear, 2009) 9. OASIS: Web Services Business Process Execution Language (WSBPEL) 2.0 (2007) 10. Sobel, J., Friedman, D.: An introduction to reflection-oriented programming. In: Proceedings of Reflection 1996, San Francisco, USA, pp. 263–288 (1996) 11. Apache Axis2, http://ws.apache.org/axis2/ 12. OASIS: Web Services Security (WS-Security) 1.1 (2006) 13. W3C: Web Service Description Language (WSDL) 1.1 (2007) 14. W3C: Simple Object Access Protocol (SOAP) 1.2, 2nd edn (2007)

268

A. Marinho, L. Murta, and C. Werner

15. Apache ODE, http://ode.apache.org/ 16. IBM: Business Process Execution Language for Web Services (BPEL4WS) 1.1 (2007) 17. Lee, R., Kim, H.-K., Yang, H.S.: An architecture model for dynamically converting components into Web services. In: 11th Asia-Pacific Software Engineering Conference, 2004, Busan, Korea, pp. 648–654 (2004) 18. Applied Reflection: Creating a dynamic Web service to simplify code, http://downloads.techrepublic.com.com/download.aspx?docid=26 4551 19. WebSphere Service Registry and Repository, http://www-306.ibm.com/software/integration/wsrr 20. Logic Library Logidex, http://www.logiclibrary.com 21. Enterprise JavaBeans Technology, http://java.sun.com/products/ejb

A Negotiation Framework for Service-Oriented Product Line Development Jaejoon Lee, Gerald Kotonya, and Daniel Robinson Computing Department, InfoLab21, South Drive, Lancaster University, Lancaster, United Kingdom (tel) +44-1524-510359, (fax) +44-1524-510492 {j.lee,gerald,robinsdb}@comp.lancs.ac.uk

Abstract. Software product line engineering offers developers a low-cost means to rapidly create diverse systems that share core assets. By modeling and managing variability developers can create reconfigurable software product families that can be specialised at design- or deployment-time. Serviceorientation offers us an opportunity to extend this flexibility by creating dynamic product-lines. However, integrating service-orientation in product line engineering poses a number of challenges. These include difficulty in i) ensuring product specific service compositions with the right service quality levels at runtime, ii) maintaining system integrity with the dynamically composed services, and iii) evaluating actual service quality level and reflecting this information for future service selections. In this paper, we propose a negotiation framework that alleviates these difficulties by providing a means of achieving the dynamic flexibility of service-oriented systems, while ensuring the userspecific product needs can be also satisfied.

1 Introduction Software product lines are designed to be reconfigured. However, the reconfigurations are largely limited to design-time configurations where the developer modifies a common core by developing, selecting or adapting components to create a new system, and deploy-time configurations where a generic system is designed for configuration by a customer [1]. Increasingly, however, there’s need to support software product lines in a dynamic environment of continuously changing user needs and expectations, often at runtime [2]. A possible solution is to integrate service-orientation with software product line engineering. Service oriented technology provides a framework for realizing dynamic software systems by allowing applications to be composed and reconfigured using services discoverable on the network [3][4]. However, combining service-orientation with product line engineering raises several of challenges. These include difficulty in i) ensuring product specific service compositions with the right service quality levels at runtime, ii) maintaining system integrity with the dynamically composed services, and iii) evaluating actual service quality level and reflecting this information for future service selections. S.H. Edwards and G. Kulczycki (Eds.): ICSR 2009, LNCS 5791, pp. 269–277, 2009. © Springer-Verlag Berlin Heidelberg 2009

270

J. Lee, G. Kotonya, and D. Robinson

What lies at the heart of these challenges is how SOA can facilitate the dynamic composition of services so that a consumer can have a right product that s/he expects. Thus, a product line infrastructure that supports not just service discovery for dynamic composition, but also considers product specific needs is required. Service selection and reconfiguration is likely to vary with consumer needs, application runtime environment and the obligations placed on the consumer by the service provider. Therefore, some form of negotiation is required to achieve an acceptable service agreement between the consumer and provider [5][6]. However, current negotiation processes for service-oriented systems offer poor support for important product-line engineering aspects such as variability and product specific service compositions. Instead they focus on the negotiation of QoS parameters for the creation of Service Level Agreement (SLA) between the service consumer and provider [7]. Our solution has been to develop a pluggable negotiation framework that integrates product line engineering with service-orientation. The framework is based on a brokerage model [8], that combines pluggable QoS negotiation, QoS ontology and SLA evaluation with consumer strategies to compute service acceptability. The rest of this paper is organized as follows; section 2 describes a case study and provides an overview of the development process. Section 3 describes the service analysis activity of the development process. Section 4 describes the negotiation framework. Section 5 illustrates an architecture of service consumer. Section 6 provides some concluding thoughts.

2 Case Study: A Navigation System Product Line We developed a medium-size service-oriented Navigation System (NS) consisting of multiple services as a case study. A series of consumer devices which run the application were simulated, along with multiple service providers of different service types. NS is composed of location, maps, traffic, weather, and information services. Providers of simulated location, maps, and traffic, weather, and information services also register with the service registry, and each provider establishes a relationship with a broker from the brokerage system. Each provider offers services with different levels of QoS, making certain providers more acceptable than others for different consumers. The consumer devices query the service registry to obtain a consumer broker from the brokerage system, obtain monitors from the monitoring system. The process of developing core assets for a service-oriented product line comprises five activities; feature analysis, service analysis, workflow specification, dynamic service and QoS specification and system composition. Feature analysis identifies externally visible characteristics of products in a product line and organizes them into feature model [9]. During service analysis the features are classified based on two categories: workflow service (i.e., orchestrating) and dynamic service. The workflow services are to define transactions (behaviors) of services and the dynamic services are the services that should be searched and used at runtime for executing the workflow services. In the next activities, the workflow services are specified and developed, while the identified dynamic services are specified along with their quality of service levels. The runtime system interacts with service providers through an automated negotiation broker that combines consumer strategy with pluggable QoS

A Negotiation Framework for Service-Oriented Product Line Development

271

negotiation, QoS ontology and SLA evaluation and a provider rating system to ensure service acceptability. Fig. 1 shows a feature model of the NS product line. Feature modeling is the activity of identifying externally visible characteristics of products in a product line and organizing them into a model called a feature model. The primary goal of feature modeling is to identify commonalities and differences of products in a product line and represent them in an exploitable form, i.e., a feature model. Common features among different products in a product line are modeled as mandatory features (e.g., Route Calculation), while different features among them may be optional (e.g., Points of Interest) or alternative (e.g., Shortest Path or Major Roads First). Navigation System Local Map Info

… Route Calculation

Local Info Display Local Info Current Events Display

…

POI Display

Points of Interests

Current Events

Weather Info

Path Selection Strategy

Shortest Path

Avoid Congestion

MajorRoadsFirst

Real-time Traffic Info Construction Info

Real-time Traffic Consideration

Avoid Construction Area

Avoid Bad Weather

Composition Rules - Local Info Display requires Local Inf o. - Current Events Display requires Current Events. Legend Mandatory feature

Optional feature

Static-composition

Alternative features Dynamic-composition

Fig. 1. Feature Model of the Navigation System Product Line

Optional features represent selectable features for products of a given product line, and alternative features indicate that no more than one feature can be selected for a product. Composition rules supplement the feature model with mutual dependency and mutual exclusion relationships which are used to constrain the selection from optional or alternative features. In the NS product line, Local Info Display requires Local Info and they should be selected together. In our approach, we have distinguished a static relation between features from a dynamic one to present the availability of features explicitly. For example, the availability of Local Info can only be determined at runtime, as we have to search a service provider and check whether the provider provides traffic information of a certain location. In such cases, these features are connected with a dotted line, which

272

J. Lee, G. Kotonya, and D. Robinson

indicates a dynamic composition relation between them. (See the line between Local Info and Current Events in Fig. 1) This also implies that its dependent features (i.e., Local Info Display and its descending features require Local Info via the composition rule.) can only be composed and activated at runtime.

3 Service Analysis Once we have a feature model, the features are further analyzed through the service analysis activity. During service analysis the features are classified based on two categories: workflow service (i.e., orchestrating) and dynamic service. The workflow services are to define transactions (behaviors) of services and the dynamic services are the services that should be searched and used at runtime for executing the workflow services. For workflow services, correctness of their overall control behavior is the foremost concern. For example, providing an expensive color-printing service with proper authorization and billing processes is critical for virtual office service providers. Therefore, adopting a formal method framework to specify, validate, and verify is the most suitable way for developing orchestrating services. In our approach, we adapted a workflow specification language [10] with pre/post conditions and invariants to enhance the reliability of specifications. 1: dynamic service Local_Info_Display (Local_Info li) 2: invariants li.available == true; 3: precondition Local_Info_Display.selected == true; 4: postcondition li.fee_paid == true; 5: option POI_Display; 6:

binding time runtime;

7:

precondition POI_Display.selected == true &&

8: 9:

li.Points_of_Interests.available == true; postcondition none;

10: option Current_Events_Display; 11:

binding time runtime;

12:

precondition Current_Events_Display.selected == true &&

13: 14:

li.Currents_Events.available == true; postcondition none;

Fig. 2. Local Info Display Feature Specification

On the other hand, the availability of dynamic service features, which are shared by the workflow services, depends on the service providers and they have to be searched and integrated into the system at runtime. For example, the Local Info service and its optional features (Points of Interests and Current Event) are selected at runtime among available service providers. (See Fig. 1 for the features with the dynamic-composition relation.) Depending on their availability, their dependent dynamic services are bound into the workflow services. This dependency is specified by

A Negotiation Framework for Service-Oriented Product Line Development

273

using the dynamic service specification template. For example, the Local Info Display specification in Fig. 2 shows its pre/post-conditions and invariants that have to be satisfied to for the service provision. Also note that one of the preconditions is about the feature selection, which checks whether the feature is selected for the particular product configuration. If a feature is not selected for the product configuration, the service feature cannot be provided though the service provider is available at runtime.

4 Negotiation Framework The framework provides automated negotiation of services and service agreements. Its architecture features one or more brokerage systems, which create service brokers for consumers and providers on demand. These brokerage systems are registered with the service registry, for consumers and providers to discover. An overview of the framework architecture is shown in Fig. 3. Negotiation can be contained within a single brokerage system, or span two or more distributed brokerage systems. supplies negotiation models and strategies

IService Requester

Service Consumer Service Consumer Service Consumer (Product ofofthe (Product (Product ofthe the product line) product productline) line) sends service ratings

returns negotiated SLAs

IReputation Service

IBrokerage Service

Brokerage System QoS Negotiation SLA Creation/Evaluation

Reputation System

Service technology Interfaces

Service Rating

Connector

SOA Implementation (e.g. Web Service, Jini, other)

IReputation Service

Resource Management queries reputation IService Provider

returns negotiated SLAs

Service Provider supplies negotiation models and strategies

Fig. 3. Negotiation Framework

The brokerage system is designed to support the integration of a variety of different negotiation models and decision support algorithms. The service consumer or provider supplies the brokerage system with templates that describe the negotiation models to use. These templates also contain the details of decision algorithms and service strategies that should be applied during the creation and evaluation of service proposals. The brokerage system is designed to negotiate and manage specific consumer needs. This ensures product-specific compositions with the right service quality levels at runtime. It also provides a mechanism for evaluating actual service quality levels for product-line evolution (i.e. service selection). The negotiation process is initiated and led by the service consumer. Consumer brokers negotiate a single quality at a time. The counter proposal from the provider

274

J. Lee, G. Kotonya, and D. Robinson

broker contains not only its offer for that quality, but offers for any other qualities which are related to that quality. Once the consumer broker has finished negotiating with the set of discovered provider brokers for each service, each possible composition is ranked, and the service proposals for the most acceptable composition are accepted. The remaining proposals are rejected but are recorded in a negotiation cache. The negotiation cache enables brokers to record the negotiation behaviour and proposals provided by other brokers that they have previously interacted with. During negotiation, the consumer proposal engine combines the reputation of a provider with the service proposal from the provider's broker, in order to determine a proposal's overall acceptability. Provider proposal engines use the reputation system to avoid the brokers of consumers who have previously provided them with poor ratings. 4.1 Service Acceptability The service brokers are configured with utility methods for calculating the acceptability of service proposals and provider reputation with the service strategies of consumers and providers. Each service, service operation and service quality in the strategy template is given a weighting from 0.0 to 1.0 (the ideal QoS). The total quality acceptability, Qta, is calculated as shown in equation (i). Qta = (Qa ×Pw) + (R × Rw)

(i)

Qa is the proposed quality acceptability; Pw is the weight of the proposal. R represents the total reputation of the proposer’s creator and Rw is the weight of the total reputation. Pw+Rw=1.0. The total acceptability of a single service operation Ota is calculated as shown in equation (ii). The operation's weight Ow, in relation to other operations of the same service, is applied to the acceptability of each operation quality Qta, and the result divided by the total number of service operations On +1. I

Ota=

∑

|Qta|i×

i=0

Ow On + 1

(ii)

The total acceptability of a single service Sta is calculated as shown in equation (iii). The service acceptability is the sum of each operation acceptability Ota, plus the summed acceptability of each service-level quality Qta after dividing by the number of service operations On + 1. I

Sta=

J |Qta|j |Ota|i + ∑ O +1 i=0 j=0 n

∑

(iii)

The total acceptability of a service composition Cta is calculated as the sum of each total service acceptability Sta, after applying the individual service weight Sw to each service. I

Cta=

∑ i=0

|Sta|i × Sw

(iv)

A Negotiation Framework for Service-Oriented Product Line Development

275

4.2 Negotiation Sessions and Composition Overviews We have developed GUI for visualizing the negotiation and composition processes at runtime. The consumers of the application simulate a navigation device with different requirements, such as a mobile phone, internet tablet, or automobile navigation system. These differences in requirements mean that different providers are more acceptable to different types of consumers. Each provider offers their services with arbitrary differences in levels of QoS and cost. To simulate the different provider scenarios, each service provider is randomly doped so that they occasionally violate the operational qualities agreed in the SLA with their consumers. We don’t have the space to show all the different negotiation and service visualizations. However, Fig. 4 represents a typical scenario. The user can view the contents of any proposal (see Fig. 4 (a)).

Fig. 4. GUI for Visualizing the Negotiation and Composition Process

The example in Fig. 4 shows an accept proposal message from the provider of MapService. The user can also compare the final proposals from each provider of a particular service (Fig. 4 (b)). Overviews of negotiated and runtime composition acceptability are also provided (Fig. 4(c) and Fig. 4(d) respectively). Messages and charts are updated in real-time, as events flow from consumer brokers back to the simulation application.

5 An Architecture Model for Service Consumer For the development of the Navigation System product line, we adapt the C2 style [11], which provides flexibility through its layered structure and modular

276

J. Lee, G. Kotonya, and D. Robinson

components, which are called "bricks." A brick can send/receive messages to/from other bricks through its top and bottom ports, and bus-style connectors connecting ports. In the following, we explain the meta-models of architectural styles and an instance of the meta-model for the Navigation System. The UML based presentation of C2 style proposed in [12] is extended to include two different types of bricks: workflow brick and dynamic service brick types. The workflow brick is for deploying workflow services and the dynamic service brick is for deploying the proxies for the dynamic services. For dynamic services, it first needs to be included in a product configuration and its activation is decide based on service availability at runtime, as a result of negotiation with the available service providers. A configurator brick manages reconfiguration of deployed product at runtime and maintains the product configuration information for the service negotiation. Fig. 5 shows an instance for a NS product.)



Master Co nf ig urato r

>

Trip P lanner

>

>

D estinatio n Selectio n

Interactive Menu





Real-time Traf f ic Co nsid eratio n

Lo cal Inf o D isp lay

Fig. 5. An Instance of the Meta-Model for PDA with an Internet Connection

For example, the product shown in Fig. 5 can access the dynamic services and is capable of providing the Local Info Display service. In this case, the Master Configurator detects contextual changes and, if Local Info is available from a selected service provider, it dynamically binds a corresponding Local Info Display brick and activates it. That is, a configurator brick maintains the connection to the brokerage system in Fig. 3 and negotiates SLAs with it.

6 Conclusions Adopting the service-oriented paradigm for product-line engineering poses a number of challenges. These include difficulty in identifying services and determining configurations of services that are relevant in different user contexts and maintaining the system integrity after configuration changes. Current initiatives in service-oriented software development do not address these challenges adequately. In this paper we have proposed a consumer-centered approach that integrates product line engineering

A Negotiation Framework for Service-Oriented Product Line Development

277

with service-orientation by adapting feature-oriented product-line engineering to service-oriented development. What lies at the heart of these challenges is how SOA can facilitate the dynamic composition of services so that a consumer can have a right product that s/he expects. Therefore, some form of negotiation is required to achieve an acceptable service agreement between the consumer and provider. The self-managing brokerage system that combines consumer-defined service strategies with pluggable negotiations provides a means of achieving Service-Level Agreements (SLAs) by searching the best matches between service providers and consumers. The brokerage system also incorporates a reputation system that provides a means to reward and penalize service consumers in accordance with SLA violation. Our approach represents a feasible solution to a set of challenging problems in service-oriented product line development. We are currently exploring better ways tailoring the service granularity to enhance reusability.

References 1. Sommeville, I.: Software Engineering, 8th edn. Addison-Wesley, Reading (2006) 2. Cetina, C., Pelechano, V., Trinidad, P., Cortes, A.R.: An Architectural Discussion on DSPL. In: Proceedings of the 12th International Software Product Line Conference (SPLC 2008), pp. 59–68 (2008) 3. Brereton, P., Budgen, D., Bennnett, K., Munro, M., Layzell, P., MaCaulay, L., Griffiths, D., Stannett, C.: The Future of Software. Communications of the ACM 42(12), 78–84 (1999) 4. Bennett, K., Munro, M.C., Gold, N., Layzell, P., Budgen, D., Brereton, P.: An Architectural Model for Service-based Software with Ultra Rapid Evolution. In: Proceedings of IEEE International Conference on Software Maintenance (ICSM 2001), p. 292 (2001) 5. Elfatatry, A., Layzell, P.: A Negotiation Description Language. Software Practice and Experience 35(4), 323–343 (2005) 6. Lee, J., Muthig, D., Matthias, M.: An Approach for Developing Service Oriented Product Lines. In: Proceedings of the 12th International Software Product Line Conference, pp. 275–284 (2008) 7. Yan, J., Kowalczyk, R., Lin, J., Chhetri, M.B., Goh, S.K., Zhang, J.: Autonomous Service Level Agreement Negotiation for Service Composition Provision. Future Generation Computer Systems 23(6), 748–759 (2007) 8. Robinson, D., Kotonya, G.: A Self-Managing Brokerage Model for Quality Assurance in Service-Oriented Systems. In: Proceedings of High Assurance Systems Engineering Symposium (HASE 2008), pp. 424–433 (2008) 9. Lee, J., Muthig, D.: Feature-Oriented Variability Management in Product Line Engineering. Communications of ACM 49(12), 55–59 (2006) 10. JBoss jBPM 2.0 jPdl Reference Manual, http://www.jboss.com/products/jbpm/docs/jpdl (viewed May 2009) 11. Medvidovic, N., Rosenblum, D.S., Taylor, R.N.: A Language and Environment for Architecture-Based Software Development and Evolution. In: Proceedings of the 21st International Conference on Software Engineering (ICSE 1999), pp. 44–53 (1999) 12. Robbins, J.E., Redmiles, D.F., Rosenblum, D.S.: Integrating C2 with the Unified Modeling Language. In: Proceedings of the 1997 California Software Symposium (Irvine, CA), UCI Irvine Research Unit in Software, Irvine, CA, 11–18 (1997)

Ranking and Selecting Services Alberto Sillitti and Giancarlo Succi Center for Applied Software Engineering, Free University of Bolzano, Via della Mostra 4, Bolzano, Italy {asillitti,gsucci}@unibz.it

Abstract. Service composition is the most recent approach to software reuse. The interactions among services propose many problems already approached in the composition of software components even if introducing more issues related to the run-time composition that is very limited in the components world. One of such problems is the identification of a set of services that can be integrated to build a complete system. This paper proposes an adaptation of a methodology for ranking and selecting components to a service-based environment. In particular, the methodology has been extended to support the peculiarities of services and include the support to the related technologies.

1 Introduction Service-oriented development is becoming a mature discipline. The emergence and the consolidation of standard protocols and architectures allow integrators to build complex systems through the integration of services. However, researchers and developers have to deal with several challenging problems including the retrieval of suitable services to develop a complete system. In this paper, we propose the adaptation to a service-based environment of a methodology to select components for building an integrated system (Clark et al., 2004) introduced in (Sillitti and Succi, 2008). This work aims at adapting this approach to a service-based environment. According to the definitions of SOA (Service Oriented Architecture) provided by W3C (http://www.w3.org/) and OASIS (http://www.oasis-open.org/), a service has all the characteristics of a component and some more: a) It can be developed using different technologies; b) It can be executed independently in different run-time environments. This last feature allows the development of systems that result from the run-time integration of several pieces owned and run independently. This new kind of integration generates new problems related to the dynamic composition: the ability to modify (semi)automatically the structure of a system at run-time changing the services involved and/or the integration workflow. A SOA is quite similar to the architecture proposed to support the component integration but the roles and the interaction protocols are defined through W3C standards. The main actors of a SOA are three: 1) a service supplier; 2) a service integrator; 3) a service directory (or registry or broker). S.H. Edwards and G. Kulczycki (Eds.): ICSR 2009, LNCS 5791, pp. 278–287, 2009. © Springer-Verlag Berlin Heidelberg 2009

Ranking and Selecting Services

279

If a huge set of services is available, the main problem is retrieving the ones that satisfy the requirements of the integrator. Therefore, a requisite for an effective adoption of the service-oriented paradigm is the availability of a smart broker service (PrietoDiaz and Freeman, 1987). A broker is a mediator between service suppliers and system integrators. Technologies such as UDDI (http://www.uddi.org/), ebXML (http://www.ebxml.org/), and their evolutions have been developed to support the creation of public and private directories in which suppliers can deploy the description of their services using a standard language such as WSDL (Web Service Description Language). However, such technologies present several limitations from the points of view of the description and the discovery of the services stored in the broker. When developing directories and search tools for them, the integrator’s perspective – namely, building systems – needs to be kept in mind: a service-based system is built from existing services that work together through integration. The difficulties of single service selection multiply in the case of the selection of many services for building a system. This system perspective is adopted throughout this paper. The paper is organized as follows: section 2 introduces the background of the study; section 3 presents the proposed process in relation to the state of the art; section 4 details the selection process; finally, section 5 draws the conclusions and presents future work.

2 State of the Art At present, the most common technologies for implementing service directories are two: UDDI (http://www.uddi.org/) and ebXML (http://www.ebxml.org/). UDDI does not force any specific format for service description and often such description is just plain text. This approach is suitable if the user querying the directory is a human being but it is nearly useless if the user is a machine. In UDDI, queries are designed in a way that is very close to the ones used in standard search engines and are based on keywords matching. Again, this kind of approach is suitable for human beings but not for machines. For these reasons, the standard structure offered by UDDI is not suitable for advanced automated queries. ebXML registries provide a higher level of functionalities compared to the UDDI ones. ebXML has a more structured approach to service description including concepts like classification taxonomies (also present in UDDI), XML-based descriptions, relations/associations among objects in the directory. In this way, it is able to support a wider set of service descriptions that are more suitable for automated inspection and retrieval. However, the querying mechanism is still limited and mostly based on keywords matching. This is because the structure of the directory is quite general and it does not provide pre-defined schemas for the definition of the XML documents that describe the services. Therefore, advanced searches that need such information are required to download all the descriptions and analyze them locally without any support provided by the directory infrastructure. There are a number of research projects focusing of the development of an improved SOA through extending the capabilities of the directory service and providing a more useful description of the services and support their retrieval (e.g., SeCSE – http://secse.eng.it/).

280

A. Sillitti and G. Succi

CONTEXT

Ostertag et al. (1992) define the ability to reuse components (therefore, services) in four steps: 1) Definition; 2) Retrieval; 3) Adaptation; 4) Incorporation. Definition is the capability to represent services. Retrieval is the capability to find and retrieve services according to their definition. Adaptation and incorporation specify the effort to customise and integrate them into a system. In a service environment, the customization deals with the development of adapters that are able to make communicate services that support different data format and/or communication protocols. The proposed approach fully satisfies the first two steps using an internal classification mechanism (description) and a selection process (retrieval’s step). It partially approaches problems related to integration and customisation giving integrators useful information about capabilities of candidate services to collaborate to build a system. The approach does not fully support adaptation and incorporation because these are tasks on the integrator side, whereas the scope of the work is to build a broker’s infrastructure. Typically, suppliers and integrators interact with the broker only through the classification and selection interfaces. There are several ways to define a classification schema (Henninger, 1997): enumerated classification, free-text indexing, and faceted classification. The goal of integrators is the inspection of a directory to find services to build a system. If an integrator wants to retrieve a service, he must define a target. The target is a description of the ideal element. The target can be a service and allows the broker to find the most similar services in the directory. The selection of a system of services is similar to the single service selection, but now the target describes an entire system. The broker does not look for a single service, but for a set of services able to interact and compose the required system. The task of the broker is to match the integrator’s requirements with internal classification. Below are illustrated the steps that compose a system selection. 1. Understanding integrator’s Requirements requirements. It means to FUNCTIONAL NON-FUNCTIONAL understand the integrator’s REQUIREMENTS REQUIREMENTS “target”. 2. Definition of integrator’s profiles. The broker must SERVICES SELECTION understand user profile to understand better the reCOMPATIBILITY quirements. CHECK 3. The searching mechanism. The broker “translates” reSYSTEM SELECTION quirements in a query to the directory to find candidate services. SYSTEM 4. Ranking a multitude of candidate services. The possible great amount of candidate service can be unmanageable. The broker must help the selection of the most promising ones. 5. Compatibility. Services must interact each other to be used in a system. The broker has to check compatibility among them.

Ranking and Selecting Services

281

The integrator describes that system through requirements. Requirements concerned with precise definition of the task to be performed by the system (Meyer, 1985). For understanding integrator’s target, a broker must address some issues (Maiden and Ncube, 1998). Natural language is the simplest way to express requirements. It is the ideal notation for human communication. It is extremely powerful and, above all, requires low effort for users. Unfortunately, in software requirements it is not the best solution. Meyer (1985) identifies seven faults in natural language. These include: presence of useless information, lack of specification, and ambiguity. Another way to express requirements is the use of formalism. Formalism allows a better understanding of requirements, reducing ambiguity and lacks of natural language. Generally, formalism is based on a description logic that expresses human thoughts in a mathematical way (Premkumar and Jones, 1997). An example of a language for formalism in specification is Larch. Larch describes services through definition of its functionality and pre and post-conditions. Using formalism is more onerous, but allows a profitable interaction reducing system’s misunderstanding. Another possible approach to the problem is the usage of facets (Prieto-Diaz and Freeman, 1987). In the early definition, facets are a set of pairs key-value that describe properties of a system including both functional qualities (e.g., data formats supported, functionalities offered, etc.) and non-functional ones (e.g., price, reliability, response time, etc.). Facets allow providers to describe in a structured way the relevant aspects of a software system. Moreover, if a common and meaningful set of key-value pairs is defined, potential users can perform advanced searches inside a repository. Such queries can be more complex than the traditional keyword matching in a plain text description and exploit the additional semantic available in the facets such as values in a specific range or in a pre-defined set. In this way, users can design queries specifying conditions such as the support of a specific set of features, the response time below a specific threshold, the price in a certain range, etc. The ability to find a specific service in a large directory is related to: the quality of the taxonomy used to define the keys and the quality of the values inserted in the description by the provider. Taxonomies allow the definition of proper keys in a specific (and limited) domain area. For this reason, the usage of different taxonomies to cover different domains is a suitable solution to provide extensive support to facets. However, taxonomies are useless if the providers do not use them correctly and do not provide a complete description of their services through them. This approach requires a considerable amount of effort from the provider but is extremely useful form the point of view of the user that is looking for a service. This basic definition of facets is very limited since it is not able to support complex descriptions, relations among the defined attributes, etc. In many cases, the usage of a single value or a set is not enough and some properties need to be described in a more expressive way. For this reason, the concept of facet has evolved to include complex structures based on XML technologies (Sawyer et al., 2005; Walkerdine et al., 2007). Facets can be described through a set of XML documents. A facet is defined as a set that includes a facet type and one or more facet specifications (Fig. 1). A facet type is a label that describes the high-level concept of the facet such as quality of service, interoperability, etc. while the facet specification is the actual im-

282

A. Sillitti and G. Succi

plementation of the concept. It is possible that several facet specifications are associated to a single facet type providing different ways of describing the high-level concept. Every facet specification includes two documents: an XML schema that defines the structure and the related XML implementation (Fig. 2). Directory

FacetType: Quality of Service

FacetSpecification1

FacetSpecification2

FacetSpecificationXSD1

FacetSpecificationXSD2

FacetType

…

FacetSpecification

FacetSpecificationXSD

FacetSpecificationXML1

FacetSpecificationXML2 FacetSpecificationXML

Fig. 1. Example of facet structure

Fig. 2. Internal structure of the directory

The selection process is relevant only inside the target system’s domain. Different terminology, different relevance assigned to properties and role of the integrator during selection can attach different meanings to selection. The broker localizes services in a directory. Requirements and integrator’s profile provide the whole information needed to compose a query to localize services in the directory. The retrieval process is not a simple matching between requirements and service’s properties (Henninger, 1994). The creation of the query must consider: • • •

•

Classification influences the query composition. E.g., enumerated classification requires users to understand the repository structure (Henninger, 1997). Users and repository use different vocabularies. Words have different meanings in different domains, and also studies indicate that people name common objects in different ways (Furnas et al., 1987). Query evolves over the time. The integrator changes requirements as a consequence of results presented by the broker (Prieto-Diaz and Freeman 1987, Henninger 1994, Henninger 1997). The presence of pre-existing services binds the design. Therefore, an integrator adapts design to services or services to design. Selection allows the integrator to understand better possible design solutions. The selection of the first set of services affects the choice of subsequent services. The integrator uses this selection to set a general framework to his system. Subsequent selected services fill the details of the framework. This is a depth first approach (try to build the whole system), but it is useful to support different “starting points”.

A high number of candidate services may discourage the integrator from evaluating them accurately. On the other hand, a small number allows the integrator to

Ranking and Selecting Services

283

evaluate services deeply. In both cases, the broker can help ranking candidates according to integrator’s preferences. Ranking is done considering a set of properties (in a faceted classification). So a decision is provided in presence of multiple criteria. The decision making process can be done under uncertainty (uncertainty about data value or user preferences) or multiple criteria (which considers trade-off about criteria, and relationships between objectives) (Fandel and Spronk, 1985). Whatever decision making the broker use, iterations with integrators have to be as simple and profitable as possible (Liping and Hipiel, 1993). Decision support systems are a mature discipline since about twenty years ago. There are many tools for decision support useful to rank information about components, visualize solutions and iterations with users (Bhargava et al., 1999). A system is a set of co-operating services through compatibility mechanism. Services are black boxes that carry out some functionality. The integrator knows service’s functionality, but does not know how functionality is carried out. Services expose only interfaces that show how to interact with them. Module Interconnection Languages (MIL) and Interface Definition Languages (IDL) provide notations for describing modules with well-defined interfaces (Allen and Garlan, 1997). An interesting formalization of the problem is to consider services as black boxes and defining ports and links (Wang et al., 1999). Ports schematize service’s interface and the way to access its functionality. Ports are connection points at a service’s boundary. Links are the association among services’ ports. Ports and links are implemented in literature at different levels of abstraction. Wang et al. (1999) use them to extend EJB and JavaBeans to check compatibility. Van Der Linden and Muller (1994) include in ports also functional features of components. Allen and Garlan (1997) use the concept of connectors to link components among them.

3 The Proposed Selection Process The proposed process starts with requirements definition and end with system selection. The selection process is not a waterfall model. There is a predefined path, but the integrator can move through the steps. The process supports the following features: 1) Target’s definition through system’s functionality; 2) Definition of requirements; 3) Ranking mechanism; 4) Branches selection; 5) Compatibility check. The process starts with target definition. The integrator defines the target system describing its functionality and the broker uses functionality to discriminate services in the directory. In the repository, the faceted classification describes functionality of a service through “functional ability” property. Functional abilities are a list of actions, i.e., pairs of (with several possible variations to this scheme) (Prieto-Diaz and Freeman, 1987). Some actions can be further refined in smaller actions. This mechanism creates a hierarchy of functional abilities at different levels of granularity. The functional ability at the highest level (the root) describes the general functionality of a service.

284

A. Sillitti and G. Succi

Functional abilities of a service are a tree-like structure. From the root to leafs, the description looses abstraction and improves details. For example, a service for “account management” follows: + Account Management - Request Account Set-up - Maintain Account - Close Account The “account management” can be broken down into three smaller functional abilities. The integrator describes target’s functional requirements (in addition to other requirements not considered here). The integrator should be able to express its requirement with only a functional ability saying, for instance, “I want to <manage e-commerce service>”. <manage e-commerce service> is a valid functional ability and can be used to query the repository. If a component that matches <manage e-commerce service> is found, the integrator’s requirement is fulfilled. However, a matching is not likely to be found at the root level. In most cases, the integrator needs to decompose a single functional ability into smaller ones. This refinement process could be repeated recursively, until a matching is found within the directory. This refinement of the description is performed manually by the integrator that details the functional abilities based on: a pre-defined taxonomy for the description of the domain and its own needs. As a result, the integrator creates a system that implements the root functional ability (<manage e-commerce service>) through the composition of services that implement finer-detail functional abilities. Using the previous example, the root functional ability could be decomposed as follows: + Manage e-commerce service - Set up catalogue - Order and Quote Management - Product Management - Account Management If the broker is not able to find these functional abilities, the integrator could refine the decomposition even more (by breaking down “set up catalogue” and so on): + Manage e-commerce service + Set up catalogue - Introduce Product + Order and Quote Management - Provide Quote - Manage Order Process …

Ranking and Selecting Services

285

When the broker finds candidate services, it presents them to the integrator and the process of refinements stops. We have classified requirements in constraints and preferences. Constraints indicate what the system must do, therefore the integrator needs. Preferences indicate what the system should (if possible) do, therefore the integrator wishes. The first requirements contain a list of functional properties, as defined in previous paragraph. The integrators can choose to order, or not, constraints. According to this, the broker can consider it as a preference. An ordered list facilitates the starting choice of the most important services (for the integrator) in the system. The first requirements are the ones, which are the most important and influence the followings. After the definition, the broker translates the requirements into XPath queries to the directory. The integrator refines the query at each step of interaction with the broker. He starts in a state with a lot of preferences and few constraints and, at the end, he is in state with a lot of constraints satisfied by a set of services, and no more preferences. The approach supports query reformulation to add (or remove) requirements during the entire process. Each constraint can be satisfied by a wide set of services. The ranking mechanism helps the integrator to find right ones. Simple ranking, according to only one property is possible, but, generally, the integrator has to take a decision in presence of multiple criteria. The ranking mechanism is possible only with comparable values. Noncomparable values are ignored and the integrator evaluates these manually. The broker has to know the preference of the integrator to compare services. Criteria can be concurrent (e.g., cost/quality), and the broker has to know how to evaluate concurrent properties. Some preferences are in the context, others can be requested to the integrator. The selection process uses MCDM (Multiple Criteria Decision Methods) to help comparison and selection. Such methods are based on algorithms that require different amount of information from the integrator (e.g., weights of the different properties). Many candidate services can satisfy a single constrain. Therefore, several compositions with the same functionalities are possible. All the candidate systems proposed are compared at the end of selection based on the non-functional properties and the context defined by the integrator. At the end of the process, the integrator has different candidate systems and evaluates the candidate systems through reports. These reports highlight common features (e.g., standards support), compatibility issues, and aggregated information (e.g., total cost). Service-based systems are made by services that communicate exchanging messages/data across the HTTP channel. There is a problem to ensure that groups of services are compatible. The broker can suggest a list of services, which satisfy a set of requirements, but if those services are not able to work together due to incompatibilities, the selection is useless. Therefore, the broker needs to describe the communication mechanisms of the services in a way to consider automatically compatibility issues. The adoption of stacks with layered protocols and formats is a recommended approach. Each layer has attributes and roles associated with it. This concept is much

286

A. Sillitti and G. Succi

Layer 4 Layer 3 Layer 2

My Do cument-Schema formats

XML SOAP

protocols

HTTP

Layer 1 Fig. 3. Simple stack

Fig. 4. A concrete example

easier to visualize, understand, and automate. A stack is an abstraction to represent data path (messages) through services. A stack is made up of layers (Fig. 3). Layers get more specialized from bottom to top. Upper layers are the “semantic” layers (e.g., the pdf document format). Bottom layers are conceptually similar to transport protocols (e.g., SOAP). Fig. 4 shows a concept example. My Document-Schema specifies the message format. The Schema is semantic aware, i.e. it is suitable to represent concepts in the semantic domain. XML provides a format for My Document-Schema. SOAP is the application protocol used to send content. Finally, HTTP is the physical communication protocol. Services have stacks to describe all possible interaction ways. Two services must implement compatible stack to allow communication.

4 Conclusions In this paper, we have adapted a methodology for retrieving components from a repository to the retrieval of services from a directory. The service retrieval includes a wide research area. This work introduces a process to improve the identification of services and the selection of a complete system build using them. The main features are the following: 1. 2.

3. 4. 5.

Selection of interacting services for a system as opposed to single service selection This methodology allows a profitable interaction between the broker and the integrator. The broker helps the integrator to define and refine his queries (through requirements’ definition and reports) It improves the reuse of software (through services selection) It allows multiple selections to consider impact of different decisions (selection branches) It checks the interaction capability among services (compatibility checks)

The work intends to support the selection of services as a human-driven process. However, some concepts can be extended and applied at run-time when most of the decisions have to be taken by an automated system.

Ranking and Selecting Services

287

References 1. Allen, R., Garlan, D.: A Formal Basis for Architectural Connection. ACM Transactions on Software Engineering and Methodology 6(3) (1997) 2. Bhargava, H., Sridhar, S., Herrick, C.: Beyond Spreadsheets: Tools for Building Decision Support Systems. IEEE Computer 32(3) (1999) 3. Clark, J., Clarke, C., De Panfilis, S., Granatella, G., Predonzani, P., Sillitti, A., Succi, G., Vernazza, T.: Selecting Components in Large COTS Repositories. Journal of Systems and Software 73(2) (2004) 4. Fandel, G., Spronk, J.: Multiple criteria decision methods and applications. Springer, Heidelberg (1985) 5. Furnas, G., Landauer, T., Gomez, L., Dumais, S.: The Vocabulary Problem in HumanSystem Communication. Communications of the ACM 30(1) (1987) 6. Henninger, S.: Using iterative refinements to find reusable software. IEEE Software 11(5) (1994) 7. Henninger, S.: An evolutionary approach to constructing effective software reuse repositories. ACM Transaction on Software Engineering and Methodology 6(2) (1997) 8. Liping, F., Hipel, K.: Interactive Decision Making. Wiley, Chichester (1993) 9. Maiden, N., Ncube, C.: Acquiring Requirements for Commercial Off-The-Shelf Package Selection. IEEE Software 15(2) (1998) 10. Meyer, B.: On formalism in specifications. IEEE Software 2(6) (1985) 11. Ostertag, E., Hendler, J., Prieto-Daz, R., Braun, C.: Computing similarity in a reuse library system: An AI-based approach. ACM Transactions on Software Engineering and Methodology 1(3) (1992) 12. Premkumar, T., Jones, M.: The Use of Description Logics in KBSE Systems. ACM Transactions on Software Engineering and Methodology 6(2) (1997) 13. Prieto-Diaz, R., Freeman, P.: Classifying Software for Reusability. IEEE Software 4(1) (1997) 14. Sawyer, P., Hutchinson, J., Walkerdine, J., Sommerville, I.: Faceted Service Specification. In: Workshop on Service-Oriented Computing: Consequences for Engineering Requirements (2005) 15. Sillitti, A., Succi, G.: Reuse: from Components to Services. In: 10th International Conference on Software Reuse (ICSR-10), Beijing, China (May 25-29, 2008) 16. Van Der Linden, F., Muller, J.: Creating architectures with building blocks. IEEE Software 12(6) (1994) 17. Walkerdine, J., Hutchinson, J., Sawyer, P., Dobson, G., Onditi, V.: A Faceted Approach to Service Specification. In: 2nd International Conference on Internet and Web Applications and Services (2007) 18. Wang, G., Ungar, L., Klawitter, D.: Component Assembly for OO Distributed Systems. IEEE Computer 32(7) (1999)

A Reusable Model for Data-Centric Web Services Iman Saleh1, Gregory Kulczycki1, and M. Brian Blake2 1

Virginia Polytechnic Institute and State University, Computer Science Department, Falls Church, VA, USA 2 University of Notre Dame, Department of Computer Science and Engineering, South Bend, IN, USA {isaleh,gregwk}@vt.edu, [email protected]

Abstract. Service-oriented computing (SoC) promotes a paradigm where enterprise applications can be transformed into reusable, network-accessible software modules or services (i.e. Web services). In many cases, existing concrete applications can be wrapped to perform within the SoC environment by (1) converting their required input data and output provisions into XML-based messages (e.g. SOAP) and (2) specifying the newly-created services using other XML-based software specifications (e.g. WSDL). In addition, enterprise organizations also devise natural language specifications to describe the service capability. Unfortunately, consumers of these capabilities often misinterpret the data requirements for using the underlying services. In this paper, we propose a generic model for data-centric Web Services that aids formal specification of service-data interactions and provides practical and verifiable solutions to eliminate data ambiguity and promote service reusability. Keywords: Data-Centric Web Services, SOC, SOA, Formal Specification.

1 Introduction Web Services are reusable software components that make use of standardized interfaces to enable loosely-coupled business-to-business and customer-to-business interactions over the Web. In such environments, service consumers depend heavily on the service interface specification in order to discover, invoke and synthesize services over the Web. In this paper, we consider data-centric Web Services whose behavior is determined by its interactions with a data store. A major challenge in this domain is interpretation of the data that must be marshaled between consumer and producer systems. Some of the consumers’ feedback on Amazon and PayPal Web Services included:“I have met a problem when I was trying to get the sales rank of digital cameras using the web service. It showed me pretty different sales ranks from what I saw through Amazon Website…”[1] and “Can someone explain the precise distinction between 'Completed' and 'Processed' [as the output of a payment service]?”[2]. These comments and many others indicate the confusion of service consumers due to ambiguous data interactions and hidden business rules. As detailed in Figure 1, when a service consumer produces the input messages that must be used to invoke a web service, S.H. Edwards and G. Kulczycki (Eds.): ICSR 2009, LNCS 5791, pp. 288–297, 2009. © Springer-Verlag Berlin Heidelberg 2009

A Reusable Model for Data-Centric Web Services

289

(s)he must interpret natural language specifications (annotated as A) and formulate messages as specified with WSDL [3] specifications (annotated as B). The messages are used to invoke the Web service via an enterprise gateway. While the Web Services Description Language (WSDL) is currently the de facto standard for Web services, it only specifies a service operation in terms of its syntactical inputs and outputs; it does not provide a means for specifying the underlying data model, nor does it specify how a service invocation affects the data. The lack of data specification potentially leads to erroneous use of the service by a consumer. We suggest that there is some logical data model and business rules (annotated as D) that exist between the interface-based messages and the underlying concrete software applications. With the existing service-based specifications, the definition of this model and rules is not well represented.

Fig. 1. Data Specification Challenges within the SoC environment

There are number of interesting problems that arise with regards to the scenario described in Figure 1. 1. Is there a reusable model/template that can be used in the formal specification of service-data interactions (as annotated by D)? 2. Can such a formal specification be used to predictably enhance the usage of the underlying data-centric services? 3. Can automated systems on the provider-side capture consumer usage behavior (and mistakes) to facilitate evolution and enhancement of the advertised specifications? In this work, we focus on (1) and (2). In addressing research question (1), we introduce a model that enables the specifications of the service-data interactions and we evaluate the effectiveness of employing different levels of the specification. Our model is based on formal methods and hence enables automatic reasoning about the service behavior. In section 2, we present our model, and in Section 3 we demonstrate its use using a real life example. We employ our example within a case study in section 4 to demonstrate its effectiveness in disambiguating data and interaction aspect of a service

290

I. Saleh, G. Kulczycki, and M.B. Blake

(effectively addressing research problem (2)). We review some related work in Section 5. Section 6 concludes the paper and presents our future work.

2 Modeling a Data-Centric Web Service We model a data source as set of entities where each entity is a set of records. In addition to a unique record identifier (key), a record can have zero or more attributes. We view this model as a common denominator of many popular data models that we surveyed [4][5][6] including mainly the relational and object-oriented modeling of databases, and some earlier efforts for formally specifying databases [7][8]. We adapt class GenericDataModel attribute entity1: Set(GenericRecord1) attribute entity2: Set(GenericRecord2) ... attribute entityn: Set(GenericRecordn) operation GenericRecordi findRecordByKey(key: GenericKeyi) requires ( GenericKeyi is the key for GenericRecordi ) ensures (result.key = key and result in this.entityi ) or result = NIL operation Set(GenericRecord_i) findRecordByCriteria( values1: Set(Ti1) values2: Set(Ti2), ... valuesn: Set(Tin)) requires ( Tij is the type of the j-th attribute of GenericRecord_i ) ensures ∀rec in result, rec.attrj in values_j and result in this.entityi operation GenericDataModel createRecord( gr:GenericRecordi) requires this.findRecordByKey( gr.key) = NIL ensures result.entityi = this.entityi U gr and ∀j ≠ i, result.entityj = this.entityj operation GenericDataModel deleteRecord(key: GenericKeyi ) requires this.findRecordByKey(key) ≠ NIL ensures result.entityi = this.entityi – this.findRecordByKey(key) and ∀j ≠ i, result.entityj = this.entityj operation GenericDataModel updateRecord(gr:GenericRecordi) requires this.findRecordByKey( gr.key) ≠ NIL ensures result.entityi = this.entityi – this.findRecordByKey(key) U gr and ∀j ≠ i, result.entityj = this.entityj end GenericDataModel class GenericRecord attribute key: Tkey attribute attr1: T1 attribute attr2: T2 ... attribute attrn: Tn end GenericRecord

Listing 1. Generic Data Model class

A Reusable Model for Data-Centric Web Services

291

the CRUD (Create-Read-Update-Delete) [9] model to include functional descriptions of the basic data operations. We implement our model as a generic class (shown in Listing 1) to facilitate its understanding by programmers of Web services. The Read operation is supported in our model by two functions; findByKey and findByCriteria. The findByKey takes a data model and a key value and returns a record whose key value matches the input key. The findByCriteria takes a data model and set of filtering values for each attribute type in the model. It returns a set of records such that an attribute value of a returned record is a member of the corresponding input filtering set. Our generic model class can be used as the basis for a reusable JML[10] or Spec#[11] specification class to model different data-centric services. Using the proposed model, a developer of a data-centric Web service can specify its data-behavior by following these steps: 1- Abstracting the service underlying data model as set of records, and identifying their attributes’ types. 2- Implementing the service data model as a class using our generic data model as a template (Listing 1). 3- Annotating the data model class with invariants that define any data constraints or business rules. 4- Annotating the service interface with formal specifications that are defined in terms of the data model and data functionalities defined in step 2.

3 Example: Amazon Associates Web Service Amazon provides a collection of remote services for e-commerce tools that are used by more than 330,000 developers [1]. We will use our model to specify a simplified version of the ItemSearch service which searches for items within Amazon product catalog given a set of search filters. The service is described as follows: Service Signature ItemInfo[] ItemSearch(searchIndex: CatString, keywords: String, minPrice: Float maxPrice: Float author: String artist: String title: String availability: AvailString merchant: String sort: SortString)

Data Types CatString: Enum of {Books, CD, DVD, All} AvailString: Enum of {Available} SortString: Enum of {price, -price} ItemInfo: Array of [itemId: Integer, detailPageURL: String, title: String, author: String, artist: String]

We used the service documentation available at [1] and our own testing of the service to guess the underlying data schema and constraints, and specified the service behavior accordingly. We model the service data a set of records of type ItemRecord. Listing 2 shows our model implemented as the ItemSeacrhDataModel class that is based on our template class defined earlier. ItemSeacrhDataModel supports the same data operations as our template class. We have, however, omitted their definition in listing 2 to avoid repetition. The data constraints and business rules are defined as

292

I. Saleh, G. Kulczycki, and M.B. Blake

class invariants. For example, the first class invariant states that a record whose category is either CD or DVD cannot have a non-nil author attribute. class ItemSearchDataModel attribute itemEntity: Set(ItemRecord) end ItemSearchDataModel class ItemRecord attribute key: Integer attribute category: { Book, CD, DVD } attribute merchantName: String attribute author: String attribute artist: String attribute title: String attribute price: Float attribute stockLevel: Integer invariant (category = CD or category = DVD) ⇒ author = NIL invariant (category = Book) ⇒ artist = NIL invariant stockLevel ≥ 0 invariant price ≥ 0 invariant merchantName ≠ NIL invariant title ≠ NIL end ItemRecord

Listing 2. The ItemSearch data model class

Finally, Listing 3 is the service specification based on the defined data model. The service preconditions and postconditions are enclosed in requires and ensures clauses, respectively. The old prefix denotes the value of a variable before service execution. The variable result denotes the service output. We define a specification variable isdm of type ItemSearchDataModel. Additionally, a group of specification variables (lines 4-7) are used to denote data filters. For example, the assertion at line 17: ensures (old(keywords) ≠ NIL) and (old(searchIndex) = Books) ⇒ Book searchIndices and old(keywords) authors and old(keywords)

titles

denotes that when the input keywords is provided, and the searchIndex input is set to Books, the search is done for items with category equal to Book and either the title or the author is matching the keywords. For the sake of simplicity, we assume the service searches for exact match between the keywords and the title/author. The sets searchIndices, authors and keywords are used in line 11 as the input filtering sets to the findByCriteria function. Lines 13-27 represent different search scenarios (search by keywords, by title, etc.). Lines 28-36 represent further filtering criterion based on input parameters. Lines 37-39 specify that when the sort input is set to price, the resulting items are sorted ascending by the item price and when sort input is set to –price, the results are sorted in descending order. It should be noted that, while the model provides the necessary constructs for full specification of the data model and data interactions, it is up to the service developer to decide on the sophistication level of the specification. This flexibility ensures that our model is applicable under different time and cost constraints.

A Reusable Model for Data-Centric Web Services

293

1 requires minPrice ≥ 0 and maxPrice ≥ 0 and minPrice ≤ maxPrice 2 ensures result.length ≥ 0 3 // The following specification variables are assumed: isdm: ItemSearchDataModel 4 // authors, artists, titles, merchants: Set(String) 5 // searchIndices: Set(CatString) 6 // prices: Set(Float) 7 // stockLevels: Set(Integer) 8 // Specifying the results in terms of the service inputs and the defined model 9 ensures ∀i, 1 ≤ i < result.length, 10 result[i] ∈ { [rec.key, ”http://www.amazon.com”+rec.key, rec.title, rec.author, rec.artist] 11 | rec ∈ isdm.findRecordByCriteria(searchIndices, merchants, authors, artists, titles, 12 prices, stockLevels)} 13 // Case 1: searching by keywords in the CD and DVD categories 14 ensures old(keywords) ≠ NIL and (old(searchIndex) = CD or old(searchIndex)= DVD) ⇒ 15 {DVD,CD} ∈ searchIndices and old(keywords) ∈ artists and old(keywords) ∈ titles 16 // Case 2: searching by keywords in the Books category 17 ensures (old(keywords) ≠ NIL) and (old(searchIndex) = Books) ⇒ 18 Book ∈ searchIndices and old(keywords) ∈ authors and old(keywords) ∈ titles 19 // Case 3: searching by keywords in all categories of items 20 ensures (old(keywords) ≠ NIL) and (old(searchIndex) = All) ⇒ 21 {Book, DVD, CD} ∈ searchIndices and old(keywords) ∈ titles 22 // Case 4: searching by title in the Books category 23 ensures (old(title) ≠ NIL) and (old(searchIndex) = Books) ⇒ 24 Book ∈ searchIndices and old(title) ∈ titles 25 // Case 5: searching by author in the Books category 26 ensures (old(author) ≠ NIL) and (old(searchIndex) = Books) ⇒ 27 Book ∈ searchIndices and old(author) ∈ authors 28 // Filtering results by the min and max prices 29 ensures (old(minPrice) ≠ NIL) ⇒ ∀ Float v ∈ prices, v ≥ old(minPrice) 30 ensures (old(maxPrice) ≠ NIL) ⇒ ∀ Float v ∈ prices, v ≤ old(maxPrice) 31 // Filtering results by availability 32 ensures old(availability) = Available ⇒ Z+ ∈ stockLevels 33 ensures old(availability) = NIL ⇒ {0} U Z+ ∈ stockLevels 34 // Filtering results by the merchant name, this parameter has a default value “Amazon” 35 ensures old(merchant) ≠ NIL ⇒ old(merchant) ∈ merchants 36 ensures old(merchant) = NIL ⇒ “Amazon” ∈ merchants 37 // Results are sorted based on the value of the sort input 38 ensures old(sort) = price ⇒ ∀i, 1 ≤ i < result.length, result[i].price ≤ result[i+1].price 39 ensures old(sort) = -price ⇒ ∀i, 1 ≤ i < result.length, result[i].price ≥ result[i+1].price

Listing 3. ItemSearch specification using the data model

4 Case Study: Improving Accessibility to the Deep Web The Deep Web refers to online data that is hidden behind dynamically generated sites and hence cannot be crawled or indexed by search engines. It is estimated that 80% of

294

I. Saleh, G. Kulczycki, and M.B. Blake

the content on the Web is dynamically generated [12]. With the increasing use of Web Services as gateways to online databases, data can be automatically queried and indexed by search engines by automatically invoking the corresponding services. We extracted from [13] a set of goals for effectively and efficiently crawling the Deep Web. We consider Amazon’s repository as part of the hidden Web and demonstrate how our specification for ItemSearch service (listing 3) helps achieve each of the crawler goals. - Goal 1: Identifying services that are candidates for crawling data. Such services are typically read-only, either for any inputs or under certain input conditions. . In the later case, these input conditions should be identifiable by the Web crawler. The ItemSearch service can be easily identified as read-only under any inputs since our specification does not contain any delete/create/update operations. - Goal 2: Balancing the trade-off between trying fewer queries on the online database and maximizing the returned result set. This is achieved by enabling only relevant queries to be formulated by a crawler. When an input can have different values, the crawler can consult our model to automatically identify the relevant set of values that will maximize the result set. For example, as shown in Listing 3, the searchIndex input can have 4 different values but setting it to All (case 3) maximize the result set since the filtering set searchIndices will contain all possible item categories {Book, CD, DVD}. - Goal 3: A service should be invoked with inputs that would potentially return distinct sets of records to avoid crawling duplicate data. The crawler can automatically reason about the filtering criteria under different inputs. For example, a search for books by keywords (case 2) includes both a search by title (case 4) and by author (case 5). Consequently, if a search by keywords is performed, the same search using the title or the author will not return new results. - Goal 4: Identifying presentation inputs, i.e. inputs that only affect the output presentation like for example a parameter representing a sorting criteria. Different values for these presentation inputs will actually retrieve the same results. Presentation inputs can be identified in our model as those inputs that do not affect the filtering sets. The sort input is an example. - Goal 5: Avoiding invalid inputs that would generate error pages. Invalid inputs can be identified from the preconditions like in line 1 of the specification. They can also be identified from the model invariant. We next evaluate our model success in decreasing the level of ambiguity about the service behavior. Our evaluation is based on the observation that the more queries the crawler has to try to retrieve the same set of data records, the more ambiguous the service behavior. Consequently, we consider the total number of possible input combinations (queries) as an indication of the level of ambiguity of the service specification. Our goal is to minimize the total number of input combinations by only considering the relevant ones. Table 1 shows the inputs of the ItemSearch service and their possible values. We assume the crawler can generate 2 values for each of the free text inputs using the

A Reusable Model for Data-Centric Web Services

295

technique in [13]. We also assume that a min and a max values are selected for the minPrice and maxPrice inputs, respectively, and each of them can also be set to Nil. Table 1. Summary of number of possible values for each input parameter Input Parameter searchIndex minPrice maxPrice keywords author artist title merchant availability Sort

Possible Values Books, CD, DVD, All min, max, Nil min, max, Nil 2 Free Text strings, Nil 2 Free Text strings, Nil 2 Free Text strings, Nil 2 Free Text strings, Nil 2 Free Text strings, Nil Available, Nil price, -price

# of Values 4 3 3 3 3 3 3 3 2 2

Table 2 summarizes the effect of the specification level on the number of queries formulated. Levels are defined in terms of number of assertions from Listing 3 that are used to annotate the service. Levels are cumulative. Table 2. Number of possible queries for each service specification level Specification Level L0:No specifications L1:Lines 1-2 L2:Lines 3-27

L3:Lines 28-33

L4:Lines 34-36 L5:Lines 37-39

Number of queries Queries filtering criterion 4*37*22 = 34,992 None (some of these queries are invalid) 4*8*35*22 = 31,104 Excluding queries that have minPrice > maxPrice since they violate the precondition 1*8*2*13*3*22 = 192 Only case 3 is considered to return maximum number of records, case 1,2, 4 and 5 will generate duplicates. 1*8*2*13*3*1*2 = 96 Excluding queries where availability is set to Available since it implies a more strict filtering set. 1*8*2*14*2 = 32 merchant default value is used to ensure results are returned. 1*8*2*16= 16 The sort input is identified as a representation parameter.

It can be seen from table 2 that the service specifications have a great impact not only on narrowing the search space for queries but also selecting those queries that will not generate errors, and that will avoid duplicates and maximize the result set.

5 Related Work Current research in data-centric Web Services focuses on either schema integration or transactions planning. The work in [14] falls in the first category and proposes an architecture for designing a data service layer to provide a declarative foundation for

296

I. Saleh, G. Kulczycki, and M.B. Blake

building SoC applications within an enterprise. The main idea is to abstract and compose information from a range of enterprise data sources and expose it as set of data services. While our work employs a similar methodology in abstracting data sources, our goal is not to enable information integration within an enterprise but rather to provide a data contract for the service that is exposed as part of the service specification targeting the less-controlled Web environment. On the other hand, research in transactions planning has recognized the evolvement of Web Services as an industry standard to implement transactional business processes. The OASIS Business Transactions Protocol (BTP) [15] and the Web Services Transactions (WS-Tx) [16][17] specification are the two major efforts in this area. These protocols define interactions between the service consumer and the service provider to ensure that they agree on the outcome of a transaction. It is assumed that compensation transactions are implemented to undo updates upon transaction failures. While these techniques are meant to ensure database integrity, they are all based on the assumption that service interactions against the database are well defined and known before planning a transaction. They also assume that service developers will follow protocol guidelines while implementing their data-centric Web Services. These assumptions are only valid when all services belong to a specific business domain or implemented within the same enterprise with strict conventions. On the Web however, services are typically combined from different providers that potentially employ different implementation conventions and practices. Moreover, many hidden business rules related to data manipulation may lead to incorrect transaction outcome even if transaction management measures are in place. Our model helps formally specifying the data behavior of an individual service and hence guaranteeing the service outcome when it is included within a transaction.

6 Conclusion Aspects of formal specifications as provide solutions for effectively specified web services. We believe that formal methods may allow for more rigor than processoriented languages (e.g. BPEL4WS, OWL-S, and WS-CDL). However, the two approaches can be also combined. In this paper, we propose a model for data-centric Web service based on formal code specification. Our case study and evaluation shows that our model has a large impact on disambiguating the service behavior in terms of its data interactions. While our model is applicable to any data-centric application, it is most useful in the case of Web services for the following reasons: - Testing and debugging a Web service is much costlier than a local method call. Service providers may restrict the number of calls, or charge the consumer for each call, so trial and error may not be an option [18]. - Web services can be exposed to a very wide range of clients that use different technologies [18]. So it is important for service providers to be able to unambiguously define the service behavior to simplify error and exception processing. - With the increasing need for automation, Web services will soon be accessed directly by software agents rather than by human beings [19]. A machine-readable specification of Web Services’ data interactions is an essential ingredient to fulfill this promise since it enables machine reasoning about the service behavior.

A Reusable Model for Data-Centric Web Services

297

Our future work includes implementing tools that can be used by a Web Service developer to easily construct the model, annotate the service with specifications and verify the consistency of the specification with respect to the model. We are also considering alternative design for our reusable class template that would enable implementation of a service model by simply inheriting from a generic superclass.

References 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

11.

12. 13. 14.

15. 16. 17.

18. 19.

Amazon Web Services, http://aws.amazon.com/ PayPal Developer Community, http://developer.paypal-portal.com/pdn/ Web Service Description Language (WSDL), http://www.w3.org/TR/wsdl20/ Codd, E.F.: The relational model for database management: version 2. Addison-Wesley Longman Publishing Co., Amsterdam (1990) Vossen, G.: On formal models for object-oriented databases. SIGPLAN OOPS Mess. 6, 1–19 (1995) Date, C.: An Introduction to Database Systems. Addison Wesley, Reading (2003) Fisher, G.: Formal Specification Examples, http://users.csc.calpoly.edu/~gfisher/classes/308/doc/ ref-man/formal-spec-examples.html Souto, R., Souto, R., Barros, M., Barros, M.: On the Formal Specification and Derivation of Relational Database Applications, PhD Dissertation (1994) Kilov, H.: From semantic to object-oriented data modeling, Systems Integration. In: Proceedings of the First International Conference on Systems Integration, pp. 385–393 (1990) Leavens, G.T., Cheon, Y., Clifton, C., Ruby, C., Cok, D.R.: How the design of JML accommodates both runtime assertion checking and formal verification. Science of Computer Programming 55, 185–208 (2005) Barnett, M., Rustan, K., Leino, M., Schulte, W.: The Spec# programming system: An overview. In: Barthe, G., Burdy, L., Huisman, M., Lanet, J.-L., Muntean, T. (eds.) CASSIS 2004. LNCS, vol. 3362, pp. 49–69. Springer, Heidelberg (2005) Lawrence, S., Giles, C.L.: Searching the World Wide Web. Science (1998) Madhavan, J., Ko, D., Kot, L., Ganapathy, V., Rasmussen, A., Halevy, A.: Google’s Deep Web crawl. In: Proc. VLDB Endow., vol. 1, pp. 1241–1252 (2008) Carey, M.: Data delivery in a service-oriented world: the BEA aquaLogic data services platform. In: Proceedings of the ACM SIGMOD international conference on Management of data, pp. 695–705. ACM, Chicago (2006) OASIS Business Transaction Protocol, http://oasis-open.org/committees/business-transactions/ Web Services Atomic Transaction (WS-Atomic Transaction) version 1.2, Committee Specification 01 (2008), http://docs.oasis-open.org/ws-tx/wstx-wsat-1.2-spec.pdf Web Services Business Activity (WS-Business Activity) version 1.2, Committee Specification 01 (2008), http://docs.oasis-open.org/ws-tx/ wstx-wsba-1.2-spec-cs-01.pdf Design by Contract for Web Services, http://myarch.com/design-bycontract-for-web-services Bansal, A., Patel, K., Gupta, G., Raghavachari, B., Harris, E.D., Staves, J.C.: Towards Intelligent Services: A Case Study in Chemical Emergency Response. In: International Conference on Web Services (ICWS), pp. 751–758. IEEE Computer Society, Los Alamitos (2005)

Author Index

Adcock, Bruce 31 Alencar, Paulo 236 Apel, Sven 106 Aschauer, Thomas 116 Atkinson, Colin 211 Bailin, Sidney C. 51 Bastarrica, Mar´ıa Cecilia Batory, Don 106 Bigot, Julien 21 Blake, M. Brian 288 Bronish, Derek 31

Lee, Jaejoon 269 Lee, Zino 137 L¨ uders, Frank 150 Lutz, Robyn R. 160

191

Causevic, Adnan 150 Choi, Hyunsik 137 Cossentino, Massimo 201 Cowan, Donald 236 da Silva, Bruno 95 Dauenhauer, Gerd 116 Dehlinger, Josh 160 de Lucena, Carlos J.P. 236 Dos Santos, Raimundo F. 246 Favaro, John 41 Foss, Luciana 95 Frakes, William B. 86, 246 Frazier, David 11 Gomaa, Hassan

76

Hallstrom, Jason O. 225 Harton, Heather 11, 31 Henderson, Matthew J. 1 Henderson, Peter 1 Hummel, Oliver 211 Jarzabek, Stan 126 Jha, Meena 181 Kang, Kyo C. 137 Kim, Dohyung 137 Kirschenbaum, Jason 31 Kotonya, Gerald 269 Krasteva, Iva 150 Kuhlemann, Martin 106 Kulczycki, Gregory 288 Land, Rikard 150 Lee, Hyesun 137

Marinho, Anderson 258 Mazzini, Silvia 41 Mei, Hong 65 Mohan, Raghuveer 11 Murta, Leonardo 258 Nunes, Daltro Nunes, Ingrid

95 236

O’Brien, Liam 181 Olimpiew, Erika Mir

76

Peng, Xin 126, 170 P´erez, Christian 21 Perovich, Daniel 191 Pree, Wolfgang 116 Ribeiro, Leila 95 Robinson, Daniel 269 Rossel, Pedro O. 191 Sabatucci, Luca 201 Saleh, Iman 288 Shen, Liwei 170 Sillitti, Alberto 278 Sitaraman, Murali 11, 31 Smith, Hampton 11, 31 Soundarajan, Neelam 225 Succi, Giancarlo 278 Sundmark, Daniel 150 Susi, Angelo 201 Weide, Bruce W. Werner, Cl´ audia Xue, Yinxing

31 258

126

Yan, Hua 65 Ye, Pengfei 126 Yilmaz, Okan 86 Zhang, Wei 65 Zhao, Haiyan 65 Zhao, Wenyun 170