Ahmed M Elmisery
email: ael-misery@tssg.org

Dmitri Botvich
email: dbotvich@tssg.org

Privacy Aware Obfuscation Middleware for Mobile Jukebox Recommender Services

Keywords: privacy, clustering, mobile jukebox, recommender service, multiagent

Mobile Jukebox is a service offered by mobile operators to their clients, such that subscribers can buy or download anywhere, anytime fulllength music tracks over the 3G Mobile networks. Unlike some music download services, the subscribers can reuse the selected tracks on their music players or computers. As the amount of online music grows rapidly, Jukebox providers employ automatic recommender service as an important tool for music listeners to find music that they will appreciate. On one hand, Jukebox recommender service recommend music based on users' musical tastes and listening habits which reduces the browsing time for searching new songs and album releases. On the other hand, users care about the privacy of their preferences and individuals' behaviors regarding the usage of recommender service. This work presents our efforts to design an agent based middle-ware that enables the enduser to use Jukebox recommender services without revealing his sensitive profile information to that service or any third party involved in this process. Our solution relies on a distributed multi-agent architecture involving local agents running on the end-user mobile phone and two stage obfuscation process used to conceal the local profiles of end-users with similar preferences. The first stage is done locally at the end user side but the second stage is done at remote nodes that can be donated by multiple non-colluding end users that requested the recommendations or third parties mash-up service. All the communications between participants are done through anonymised network to hide their network identity. In this paper, we also provide a mobile jukebox network scenario and experimentation results.

Introduction

Being music a very important thing in people's life, music applications are present in every computer and over many mobile devices. For such reason, mobile operators offer Mobile Jukebox as a moderate price service to their clients, such that subscribers can buy or download full-length music tracks over 3G Mobile networks. Unlike some music download services, the user can reuse the selected tracks on their music players or portable music devices.

According to [START_REF] Perik | The Sensitivities of User Profile Information in Music Recommender Systems[END_REF] the more services appear in future, the more demand for personalization services will be to fight against information overload and find information relevant to each user. Recommender services can be seen as a suitable solution to these problems as they customize the offered services according to unique and individual needs of each user. The Jukebox providers employ recommender services to reduce browsing time for music listeners as the amount of online music grows rapidly. Jukebox recommender service becomes an increasingly important tool for music listeners to easily find new songs or playlists that they will appreciate. Examples of available Jukebox services are Apple iTunes ® and Last.fm ® . Apple iTunes automatically generates a playlist of songs from the user's library which is similar to the selected songs, While Last.fm builds a detailed profile for each user's musical taste by recording details of the songs the user listens to either from internet radio stations or user's computer or portable music devices. This information is transferred to Last.fm's database via music player and the user's profile data can be displayed on his profile page.

Jukebox recommenders commonly use collaborative filtering (CF) techniques to recommend music based on the listening behaviors of other music listeners. The Jukebox recommender harness the "wisdom of the crowds" to recommend music. Even though they generate good recommendations there are still some problems like the cold-start problem, as a recommender needs a significant amount of data before it can generate appropriate recommendations. However the acquisition, storage and application of sensitive personal information cause privacy concerns for users. There are many things having an impact on the perception of privacy for users like what kind of information is collected, how the information is used and the degree of accessibility of the information by others.

The authors in [START_REF] Perik | The Sensitivities of User Profile Information in Music Recommender Systems[END_REF] have done an empirical research concerning privacy preferences and individuals' behaviors regarding personalization in music recommender systems. They found out that information about the purpose of the disclosure, recipients of the information, and the degree of the information involved and the benefits users expect to gain from disclosing personal information are the main factors influencing disclosure behavior. Based on their questionnaire in [START_REF] Perik | Privacy & Personalization: Preliminary Results of an Empirical Study of Disclosure Behavior[END_REF], participants were more willing to disclose music preferences than their personality. Participants considered information about personality traits more personal and more sensitive information than preferences for music genres. Participants expressed worries about not knowing how their information will be used in the system and who gets access to their personal information. The sensitivity of information affects on the disclosure decision. The questionnaire also shows that some participants even consider what benefits they will gain from disclosing the information. Participants can be divided into two groups based on their disclosure behavior, depending on whether they want to disclose anonymously or including identity information. One important factor have an impact on people's disclosure behavior is the security and privacy standards taken by the Jukebox providers.

In this work, we proceed with our approach presented in [START_REF] Elmisery | An Agent Based Middleware for Privacy Aware Recommender Systems in IPTV Networks[END_REF][START_REF] Elmisery | Agent Based Middleware for Private Data Mashup in IPTV Recommender Services[END_REF][START_REF] Elmisery | Agent Based Middleware for Maintaining User Privacy in IPTV Recommender Services[END_REF][START_REF] Elmisery | Privacy Aware Recommender Service for IPTV Networks[END_REF][START_REF] Elmisery | Private Recommendation Service For IPTV System[END_REF] to build AMPR (i.e. acronym for agent based middleware for private recommendations) that allows end-users to receive useful recommendations without disclosing their real preferences to the service. In the following section we will describe some properties for AMPR:

1. AMPR is running as a multi-agent based middleware to support different types of clients either thin or thick. Moreover, this architecture enables smooth integration with wide range of existing recommender services 2. AMPR preserves the aggregates in the obfuscated profiles to maximize their utility in order to attain acceptable recommendations accuracy, which facilitate AMPR to work with different state-of art filtering algorithms. Extra overhead in computation and communication to be added in the recommendation process due to the two stage obfuscation process 3. AMPR employs two stage obfuscation process to conceal the user's preferences in his profile. The real user profile doesn't leave his mobile phone until it is properly desensitized and it is maintained encrypted with private password that is known only to the user. If the user doesn't accept to be tracked by the recommender service using his network identity, AMPR hides his identity by routing the submission of his locally obfuscated profile through relaying nodes in an anonymous communication network before sending it to the recommender service.

In the rest of this paper we will generically refer to songs and playlists as Items. In section 2, we describe some related work. Section 3 introduces recommender system for mobile jukebox service scenario landing AMPR. Section 4 introduces our proposed solution. Section 5 describes the recommendation strategy used in our PCRS. Section 6 presents some experiments and results based on our proposed solution. Section 7 includes conclusions and future work.

Related Work

The majority of the literature addresses the problem of privacy for recommender services based on collaborative filtering technique, Due to it is a potential source of leakage of private information shared by the users as shown in [START_REF] Mcsherry | Differentially private recommender systems: building privacy into the net[END_REF]. In [START_REF] Esma | Experimental Demonstration of a Hybrid Privacy-Preserving Recommender System[END_REF] it is proposed a theoretical framework to preserve the privacy of customers and the commercial interests of merchants. Their system is a hybrid recommender that uses secure two party protocols and public key infrastructure to achieve the desired goals. In [START_REF] Canny | Collaborative filtering with privacy via factor analysis[END_REF][START_REF] Canny | Collaborative Filtering with Privacy[END_REF] it is proposed a privacy preserving approach based on peer to peer techniques using users' communities, where the community will have a aggregate user profile representing the group as whole and not individual users. Personal information will be encrypted and the communication will be between individual users and not servers. Thus, the recommendations will be generated at client side. In [START_REF] Polat | Privacy-Preserving Collaborative Filtering Using Randomized Perturbation Techniques[END_REF][START_REF] Polat | SVD-based collaborative filtering with privacy[END_REF] it is suggest another method for privacy preserving on centralized recommender systems by adding uncertainty to the data by using a randomized perturbation technique while attempting to make sure that necessary statistical aggregates such as mean don't get disturbed much. Hence, the server has no knowledge about true values of individual rating profiles for each user. They demonstrate that this method does not decrease essentially the obtained accuracy of the results. Recent research work [START_REF] Huang | Deriving private information from randomized data[END_REF][START_REF] Kargupta | On the Privacy Preserving Properties of Random Data Perturbation Techniques[END_REF] pointed out that these techniques don't provide levels of privacy as it was previously thought. In [START_REF] Kargupta | On the Privacy Preserving Properties of Random Data Perturbation Techniques[END_REF] it is pointed out that arbitrary randomization is not safe because it is easy to breach the privacy protection it offers. They proposed a random matrix based spectral filtering techniques to recover the original data from perturbed data. Their experiments revealed that in many cases random perturbation techniques preserve very little privacy. Similar limitations were detailed in [START_REF] Huang | Deriving private information from randomized data[END_REF]. We consider the scenario where a private centralized recommender service (PCRS) is implemented on an external third party server and end-users give information about their preferences to that server in order to receive music recommendations. The user preferences stored in his profile in the form of ratings or votes for different item, such that items are rated explicitly or implicitly on a scale from 1 to 5. An item with rating of 1 indicates that the user dislikes it while a rating of 5 means that the user likes it. PCRS collects and stores different users' preferences in order to generate useful recommendations.

Recommender System for Mobile Jukebox Service -Scenario

In this scenario there are two possible ways for user's discloser: through his personal preferences included in his profile [START_REF] Parameswaran | Privacy preserving data obfuscation for inherently clustered data[END_REF] or through the user's network address (IP). AMPR employs two principles to eliminate these two disclosure channels, respectively. The obfuscation agents perturb user's preferences for different items in his profile and the synchronize agent hides the user's network identity by routing the communication with other participants through relaying nodes in Tor [START_REF] Dingledine | Tor: the second-generation onion router[END_REF] anonymous network. The main challenge for synchronize agent is to tune up Tor and optimize its performance while maintaining the user anonymity.

We don't assume the server to be completely malicious. This is a realistic assumption because the service provider needs to accomplish some business goals and increase its revenues. In our framework, we will use the mobile phone storage to store the user profile. On the other hand, the Jukebox service maintains a centralized rating database that is used by the PCRS; Figure [START_REF] Perik | The Sensitivities of User Profile Information in Music Recommender Systems[END_REF] shows the architecture of our approach. Additionally, we alleviate the user's identity problems stated above by using anonymous pseudonyms identities for users.

Proposed Solution

In the next sub-sections, we will present our proposed middleware for protecting the privacy of users' profiles 2) demonstrates AMPR components that are running in the mobile phone at the user side. As shown, AMPR consists of different co-operative agents, A Learning agent captures user preferences about items explicitly or implicitly to build a rating table and meta-data table. The local obfuscation agent implements CTA obfuscation algorithm to achieve user privacy while sharing the data with other users or the system. The global perturbation agent is only invoked if the user is acting as a target user in recommendation process; it executes EVS-algorithm on the collected profiles finally. The synchronize agent is responsible for selecting the best suitable routing paths in the anonymised network to enhance its performance.

The recommendation process based on the two stage obfuscation process in our framework can be summarized as following:

1. The learning agent collects user's preferences about different items which represent a local profile. The local profile is stored in two databases, the first one is the rating database that contains (item_id, rating) and the other one is the metadata database that contains the feature vector for each item (item_id, feature1, feature2, feature3). The feature vector can include genre, author, album, decade, vocalness, singer, instruments, number of reproductions and so on. 2. The target user broadcast a message to other users near him to request recommendations for specific genre or category of items. Individual users who decide to respond to that request use their local obfuscation agent to obfuscate a part of their local profiles that match query. The group members submit their locally obfuscated profiles to the requester using an anonymised network like TOR to hide their network identities. Enhancing the performance of communication through Tor is discussed in the next sub-section. If the size of group formation less than a specific value, the target user contacts the PCRS directly to gets recommendation from the centralized profiles stored in it. 3. In order to hide items identifiers and meta-data from the requester and the PCRS.

The manger agent at each participant side use locality-sensitive hashing (LSH) [START_REF] Indyk | Approximate nearest neighbors: towards removing the curse of dimensionality[END_REF] to hash these values. One interesting property for LSH is that similar items will be hashed to the same value with high probability. PCRS is still be able to perform computations on the hashed items using appropriate distance metrics like hamming distance or dice coefficient. 4. After the target user receives all the participants' profiles (group profile), he/she incites his global perturbation agent to perturb the collected profiles. Then he can interact with PCRS by acting as an end-user has group profile as his own profile. The target user submits his/her group profile through an anonymised network to PCRS in order to attain recommendations. 5. PCRS performs its filtering techniques on the group profile which in turn return a list of items that are correlated with that profile. This list is encrypted with a private key provided by target-user and it is sent back on the reverse path to the target user that in turn decrypts and publishes it anonymously to the other users that participated in the recommendation process.

Enhancing The Anonymized Network (Tor) Performance

Tor [START_REF] Dingledine | Tor: the second-generation onion router[END_REF] is an anonymity network based on the original onion routing design but with several modifications in terms of security, efficiency, and deployability. The Tor network includes a small set of trusted authoritative directory servers responsible for aggregating and distributing signed information about known routers in the network.

Tor clients periodically fetch the directory information from directory mirrors in order to learn information about other servers in the network.

Tor network suffers from serious performance degradation because of its random path selection algorithms that use self-reported bandwidth values only, which might select with high probability a router with low bandwidth because it is sensitive to loads and changing network conditions. The synchronize agent seeks to enhance the performance by partitioning the Tor network into classes of high or low bandwidth Tor routers to better understand the relationships between different classes of routers /potential paths. Paths drawn from the class of high-bandwidth routers can provide better performance. Paths can be reserved for participating in specific recommendation requests based on a user's priorities or preferences. Therefore, inspired from the work in [START_REF] Pingley | CAP: A Context-Aware Privacy Protection System for Location-Based Services[END_REF] we have implemented a simple parameterized path selection algorithm (PPS) that allow the synchronize agent to enhance the path selection in the Tor network with two priorities and it can be easily extended to support priorities larger than two. The synchronize agent can create circuits in advance to reduce the waiting time then measure the path throughput P before using each path. PPS consists of the following steps:

1. The user input minimum path throughput P , and circuit throughput C to the synchronize agent. 2. Based on Tor authoritative directory servers, the algorithm start partitioning the class of high-bandwidth routers into a set of overlapping clusters (based on geographical location, platform, bandwidth, uptime, last update, number of connections and self-reported bandwidth estimate) using the algorithm on [START_REF] Fellows | Graph-Based Data Clustering with Overlaps[END_REF]. 3. It builds a pool of Tor nodes whose bandwidth from each cluster. In order to decrease the delay in circuit creation, the synchronize agent can select overlapping routers between clusters 4. Then, it randomly builds circuits passing through these clusters. Then measure each circuit throughput, and select the first circuit that achieve bandwidth C . 5. The synchronize agent then negotiates session keys with each router in the circuit.

The exit router is responsible for establishing the connection from the Tor network to the client's intended destination 6. The synchronize agent records the previously used Tor nodes and exclude them from future circuit building clusters.

Proposed obfuscation Algorithms

In the next subsections, we present two different algorithms used by the obfuscation agents in AMPR to obfuscate the user profile in a way that secure user's preferences in PCRS with minimum loss of accuracy.

Local Obfuscation using Clustering Transformation Algorithm (CTA).

We proposed a novel algorithm for obfuscating the user profile before sharing it with other users. CTA designed especially for the sparse data problem we have here. CTA partitions the user profile into smaller clusters and then pre-process each cluster such that the distances inside the same cluster will maintained in its obfuscated version. We use local learning analysis (LLA) clustering method proposed in [START_REF] Elmisery | Privacy Preserving Distributed Learning Clustering Of HealthCare Data Using Cryptography Protocols[END_REF] to partition the dataset. After complete the partitioning, we embed each cluster into a random dimension space so the sensitive ratings will be protected. Then the resulting cluster will be rotated randomly. In such a way, CTA obfuscates the data inside user profile while preserving the distances between the data points to provide high accurate results when performing recommendations. The algorithm consists of the following steps:

1. The user ratings is stored in his mobile phone as dataset consists of rows, where each row is a sequence of attributes where , where τ D is the distance matrix for the d-dim embedding space, and converts distances to inner products τ HSH/2.

… … … . 2.
7. For each cluster ∀ ∀ C , CTA randomly select two attributes x and x to perform rotation perturbation on selected attributes R x , x using transformation matrix M setup by the user for each cluster using range of angles defined in advance by the user. 8. Repeating steps 4-7 for all clusters in ∀ D to get the obfuscated portion D .

Finally, the obfuscated dataset is obtained by D ∪ D .

Global Perturbation using Enhanced Value-Substitution (EVS) Algorithm.

After executing the local obfuscation process the global perturbation phase starts. The key idea for EVS is based on the work in [START_REF] Ghinita | PRIVE: anonymous location-based queries in distributed mobile systems[END_REF] that uses Hilbert curve to maintain the association between different dimensions. In this subsection, we extend this idea as following, we also use Hilbert curve to map m-dimensional profile to 1-dimensional profile then EVS discovers the distribution of that1-dimensional profile. Finally, we perform perturbation based on that distribution in such a way to preserve the profile range. The steps for EVS algorithm consists of the following steps:

1. We denote the collected m-dimensional user profiles as dataset D of c rows, where each row is a sequence of m dimensions A A , A , A , A … … , A . 2. EVS divides the m-dimensional profile into grids of order k (where k is user defined value) as shown in [START_REF] Ghinita | PRIVE: anonymous location-based queries in distributed mobile systems[END_REF][START_REF] Reaz | A Scalable Peer-to-peer Protocol Enabling Efficient and Flexible Search[END_REF]. For order k, the range for each dimension divided into 2 intervals. 3. For each dimension ∀ of the collected profile :  Compute the k-order Hilbert value for each data point ∀ a . This value represents the index of the corresponding interval where it falls in.  EVS sort the Hilbert values from smallest to biggest, then use the step length (a user defined parameter) to measure whether any two values are near from each other or not. If these values are near, they are placed in the same partition ∀ . These two steps iterates for all m-dimensions. The final result from these steps is partitions for each dimension denoted as ∀ ∀ 4. EVS constructs a N shared nearest neighbour sets S where r 1 … . N as in [START_REF] Jarvis | Clustering Using a Similarity Measure Based on Shared Near Neighbors[END_REF] from different partitions with a new modified similarity function as following, two partitions in different dimensions , form a shared nearest neighbour set S if they share k-number of common elements such that = ∪ 5. For each newly created set S , EVS calculates the interquartile range. Then, for each point a ∈ S generate a uniform distributed random point in that range that can substitutes a . 6. Finally, the new set ∪ S is sent to PCRS

Recommendation Strategy

PCRS employ online mode filtering algorithms to make predictions on the ratings of a particular user by collecting preference information from other users. The collected profiles (group profile) represented as * user item matrix which contains a collection of numerical obfuscated ratings of M users on N items. After that, the neighbourhood formation at PCRS is done by calculating the similarity between users in the user-item matrix. Users similar to the target user using some proximity metric will form a proximity based neighbourhood with him [START_REF] Polat | Privacy-Preserving Collaborative Filtering Using Randomized Perturbation Techniques[END_REF]. This neighbourhood will utilize later for predication step. The prediction on rating of user i for item K is given by a weighted average [START_REF] Konstan | GroupLens: Applying Collaborative Filtering to {Usenet} News[END_REF] of users whose ratings are similar to the target user.

P v ∑ s u , u v v ∈ ∑ s u , u ∈
Where U i ∈ U|v ∅ is the set of users who have rated the k th item. v is the mean of all ratings made by user i. The weights of average s u , u are the similarity between user u and u such as the Pearson correlation coefficient or Euclidean distance. We represent the user as a vector consists of n features slots, one for each item. These slots contain user's ratings for different items or ∅. The similarity between users' vectors is calculated as the cosine of the angle formed between them as following:

s u , u ∑ v v v ⋯ v v ⋯ v
Finally, the recommendation process is to produce a predicted rating based on the neighbourhood for a list of items that have not been rated by the user, these items have a high potential of interest (predicated with high positive rating) to the user. The resulting items list can be further constrained based on marketing or Qos rules.

Experiments

The proposed algorithms are implemented in C++. We used message passing interface (MPI) for a distributed memory implementation of EVS algorithm to mimic a distributed reliable network of peers. We evaluated the proposed algorithms from two different aspects: privacy achieved and accuracy of results. The experiments presented here were conducted using the Movielens dataset provided by Grouplens [START_REF] Lam | MovieLens Data Sets[END_REF]. The dataset contains users' ratings on movies using discrete value between 1 and 5. The data in our experiments consists of 100.000 ratings for 1.682 items by 943 users. The experiments involve dividing the data set into a training set and testing set. The training set is obfuscated then used as a database for the PCRS. Each rating record in the testing set is divided into rated items and unrated items. The rated items are presented to the PCRS for making predication for the unrated items. To evaluate the accuracy of generated predications, we used the mean absolute error (MAE) metric proposed in [START_REF] Herlocker | Evaluating collaborative filtering recommender systems[END_REF]. MAE measures the predication verity between the predicated ratings and the real ratings, so smaller MAE means better recommendations provided by PCRS. To measure the privacy or distortion level achieved using our algorithms, we use variation of information metric VI [START_REF] Kingsford | Information Theory Notes[END_REF] to estimate data error. Where, the higher VI means the larger distortion between the obfuscated and original dataset, which means higher privacy level.

To evaluate the accuracy of CTA algorithm with respect to different number of dimensions in user profile, we control d-dim parameters of CTA to vary number of dimensions during the evaluation. Figure [START_REF] Elmisery | An Agent Based Middleware for Privacy Aware Recommender Systems in IPTV Networks[END_REF] shows the performance of recommendations of locally obfuscated data, as shown the accuracy of recommendations based on obfuscated data is little bit low when d-dim is low. But at a certain number of dimensions (500), the accuracy of recommendations of obfuscated data is nearly equal to the accuracy obtained using original data. In the first experiment performed on EVS algorithm, we measured the relation between different Hilbert curve parameters (order and step length) on the accuracy and privacy levels attained. We map the locally obfuscated dataset to Hilbert values using order 3, 6 and 9. We gradually increased the step length from 10 to 80. Figure [START_REF] Elmisery | Agent Based Middleware for Maintaining User Privacy in IPTV Recommender Services[END_REF] shows the accuracy of recommendations based on different step length and curve order. We can see that as the order increases, the obfuscated data can offer better predictions for the ratings. This is because as the order has higher value, the granularity of the Hilbert curve becomes finer. So, the mapped values can preserve the data distribution of the original dataset. On the other hand, selecting larger step length increases MAE values as large partitions are formed with higher range to generate random values from it, such that these random values substitute real values in the dataset. 6), when the order increases a smaller range is calculated within each partition which introduces less substituted values compared with lower orders that attain higher VI values. The reason for this is larger order divides the mdimensional profile into more grids, which makes Hilbert curve better reflects the data distribution. Also, we can see that for the same Hilbert curve order the VI values are generally the same for different step length except for order 3, in which VI values has a sharp increase when step length grows from 50 to 60.The effect of increasing step length on VI values is more sensible in lower curve orders as fewer girds are formed and the increase of step length covers more portions of them, which will introduce a higher range to generate random values from it. So the target user should select EVS parameters in such a way to achieve a trade off between privacy and accuracy. Finally, we measured the overall performance of PPS algorithm in terms of the enhancement achieved in uploading time for the collected profiles. Figure [START_REF] Elmisery | Private Recommendation Service For IPTV System[END_REF] illustrates the cumulative distribution function (CDF) of time uploading the collected profiles of 331,25 bytes from the target user under the proposed PPS algorithm. The term PPS = C 34KB/s refers to executing PPS with a circuit throughput equal to 34KB/s. Table [START_REF] Perik | The Sensitivities of User Profile Information in Music Recommender Systems[END_REF] gives the mean, median for execution of PPS with different circuit throughput values. Our analysis of Figure [START_REF] Elmisery | Private Recommendation Service For IPTV System[END_REF] and Table [START_REF] Perik | The Sensitivities of User Profile Information in Music Recommender Systems[END_REF] lead us to the following observations; the performance of Tor's default path selection algorithm is unacceptable for responsive recommender services. The largest uploading time for the profiles is 182.61s; also our PPS algorithm significantly improves path selection performance. In this paper, we presented our ongoing work on building an agent based middleware for private recommendation services. We gave a brief overview of the recommendations process with application to Jukebox music recommendations. Also we presented the novel algorithms that provide the users with complete control of the privacy of their profiles using two stage obfuscation process. We tested The performance of these proposed algorithms on real dataset. The experiential results show that preserving users' privacy for Jukebox recommender service is possible. In particular mean average error can be reduced with proper tuning of the algorithms' parameters for large number of users. We realized that there are many challenges in building an agent based middleware scenario. This allow us to move forward in building an integrated system while studying issues such as a dynamic data release at a later stage and deferring certain issues such as virtualized schema and auditing to future research agenda. We need to perform extensive experiments in other real data set from the UCI repository and compare the performance with other techniques. Also we need to consider different data partitioning techniques as well as identify potential threats and add some protocols to ensure the privacy of the data against those threats.

Fig. 1 .

 1 Fig. 1. Jukebox Service for Mobile Users with Third Party Private Recommender Service

Fig. 2 .

 2 Fig. 2. AMPR Components

Fig. 3 .

 3 Fig. 3. Accuracy of recommendations for obfuscated dataset using CTA In the second experiment performed on CTA algorithm, we examine the effect of ddim on VI values. As shown in Figure (4), VI values decrease with respect to the increase in d-dim values in user profile. d-dim is the key element for privacy level where smaller d-dim value, the higher VI values (privacy level) of CTA. However, clearly the highest privacy is at d-dim=100. There is a noticeable drop of VI values when we change d-dim from 300 to 600.d-dim value 400 is considered as a critical point for the privacy.Note that rotation transformation adds extra privacy layer to the data and in the same time maintains the distance between data points to enable PCRS to build accurate recommendation models.In the first experiment performed on EVS algorithm, we measured the relation between different Hilbert curve parameters (order and step length) on the accuracy and privacy levels attained. We map the locally obfuscated dataset to Hilbert values using order 3, 6 and 9. We gradually increased the step length from 10 to 80. Figure[START_REF] Elmisery | Agent Based Middleware for Maintaining User Privacy in IPTV Recommender Services[END_REF] shows the accuracy of recommendations based on different step length and curve order. We can see that as the order increases, the obfuscated data can offer better predictions for the ratings. This is because as the order has higher value, the granularity of the Hilbert curve becomes finer. So, the mapped values can preserve the data distribution of the original dataset. On the other hand, selecting larger step length increases MAE values as large partitions are formed with higher range to generate random values from it, such that these random values substitute real values in the dataset.

Fig. 4 .Fig. 5 .

 45 Fig. 4. Privacy levels for the obfucated dataset using CTA Fig. 5. Accuracy level for different step length and orders for EVS

Fig. 6 .Fig. 7 .

 67 Fig. 6. Privacy level for different step length and orders for EVS

  The dataset is portioned vertically into … … subsets of length , if / is not perfectly divisible then CTA randomly selects attributes already assigned to any subset and joins them to the attributes of the incomplete subsets.3. Cluster each subset ∀Using LLA algorithm, that result in clusters , , … . for each subset. So every point in the original dataset D falls exactly in one cluster. The aim of this step is to increase the privacy level of the transformation process and make reconstruction attacks difficult. 4. CTA generates two sets for each cluster in the subset these are and .Where is the set of points with highest values for field function and is the rest of points in .For each point ∈ construct a weighted graph Γ that contains its

	k-nearest neighbours in	, each edge e ∈ Γ has a weight equals to the influence
	function of that point	.
	5. Estimate the geodesic distances by Computing the shortest distance between each
	two points in graph Γ using Dijkstra or Floyd algorithm and then build a distance
	matrix	.
	6. Based on	,we find a d-dim embedding space	using classical MDS [22] as
	follows
	 Calculate the matrix of squared distances S D and the centering matrix
	H 1 1 N ⁄ ee
	 The characteristic vectors are chosen to minimize E	τ D
	τ D

Table 1 .

 1 Uploading Time for Different C values

		default	PPS=	PPS=	PPS=	PPS=
			10KB/s	20KB/s	30KB/s	34KB/s
	Mean	30.38	25.34	19.64	12.54	8.41
	Median	33.56	17.35	15.18	10.73	9.59

Acknowledgments : This work has received support from the Higher Education Authority in Ireland under the PRTLI Cycle 4 programme, in the FutureComm project (Serving Society: Management of Future Communications Networks and Services).


Remigijus Gustas
email: remigijus.gustas@kau.se

Prima Gustiene
email: prima.gustiene@kau.se

A Method for Conceptual Modeling of Semantically Integrated Use-case Scenarios

Keywords: Interaction dependencies, separation of concerns, basic pattern of a transaction, interaction loops, scenarios

A use-case is specified as a set of possible scenarios of interactions. Scenarios can be decomposed into workflows on different granularity levels. Use-cases are fundamentally a text-based documentation form written in natural language text. The textual description of a complicated scenario can be ambiguous, incomplete and inconsistent. In this paper we demonstrate a conceptual modeling method for representing use-case descriptions by using a graphical language. Simple interaction loops are viewed as fundamental elements for composition of scenarios. Each interaction loop is analyzed separately and therefore it provides a natural way of decomposition. Modeling of overlaying interaction flows between organizational and technical components enables separation of crosscutting concerns in system engineering without requirement to specify a complete solution. The goal of this paper is to demonstrate the advantages of conceptual modeling approach, which allows to introduce evolutionary extensions and to construct use-case scenarios with a comprehensible structure.

Introduction

Use-cases are a way to capture requirements. It is the form of requirements engineering [START_REF] Arlow | UML 2 and the Unified Process[END_REF]. According to Cockburn [START_REF] Cockburn | Writing Effective Use Cases[END_REF] a use-case is a description of the possible sequences of interactions between the system and its external actors. Each sequence of interaction events can be viewed as a scenario. Every use-case contains a set of possible scenarios related to the goal of a primary actor. Historically use-cases descriptions are written as text-based documentation. Natural language is verbose and flexible to use in conversations, but it is really problematic when it comes to system modeling as natural language is notoriously ambiguous in its meaning [START_REF] Miles | Learning UML 2.0[END_REF]. Especially, complex scenarios may result in ambiguous, incomplete and inconsistent textual descriptions.

According to Jacobson [START_REF] Jacobson | Aspect-Oriented Software Development with Use Cases[END_REF], use-cases can be seen as different stakeholders concerns, which are important to understand while exploring and collecting the requirements for the system. Very often a certain concern is spread across multiple components. It means that the realization of functional requirements, which are usually specified as use-cases can cut across multiple components. Inability to keep crosscut-ting concerns separate causes problems for system designers when the requirements are modified. The designer must identify all related components and to find out how these components are affected by introduced changes. Especially, modifying the requirements, which are related to a big number of diagrams, is quite problematic. Poor understanding of crosscutting concerns makes it difficult to make even simple evolutionary extensions of information system (IS) specifications.

The scope of scenario can vary. It may include all business events, or it may include just some events, which are of interest to one specific actor. Scenarios can be used to define workflows on different granularity levels. Our studies indicate that simple interaction loops [START_REF] Denning | Completing the Loops[END_REF] can be viewed as fundamental elements for the composition of scenarios. Each interaction loop can be analyzed separately as it is required by the principle of separation of concerns. In such a way, interaction loops provide a natural way of decomposition. Two related loops can be used for analyzing integrity between static and dynamic aspects of some scenario. They are also useful as a concern composition mechanism. A scenario is an excellent means for describing the order of interactions. It can be conceptualized as a combination of several loops between a set of loosely coupled actors.

Use-cases can be described on different levels of abstraction and they can be combined into scenarios in various ways. In the object-oriented modeling approaches, a scenario is typically specified by a textual narrative description. A textual description of a complicated scenario can be incomplete and inconsistent with other representations. One of the goals of this paper is to demonstrate how use-case scenarios can be expressed by using Semantically Integrated Conceptual Modeling (SICM) method [START_REF] Gustas | Modeling Approach for Integration and Evolution of Information System Conceptualizations[END_REF]. This approach puts into a foreground the modeling of interactions [START_REF] Dietz | Enterprise Ontology: Theory and Methodology[END_REF] among actors [START_REF] Wagner | The Agent-Object-Relationship Metamodel: Towards a Unified View of State and Behavior[END_REF]. Interaction dependencies are used to preserve the modularity of concerns and to integrate behavioral effects with structural changes in various classes of objects.

Use-cases can be viewed as slices, which are analogous to overlays. Such overlays can be stacked on top of each other. In this way, overlays can be understood as a concern separation technique [START_REF] Jacobson | Aspect-Oriented Software Development with Use Cases[END_REF]. Use-case slices define the behavior that extends the element structure. So, it looks like use-case composition mechanism and concern separation principles are quite obvious. However, introducing evolutionary changes, which are related to a big number of diagrams, is quite problematic in object-oriented approach using Unified Modeling Language (UML). It is common to all system analysis and design methods to separate disparate views [START_REF] Zachman | A Framework for Information Systems Architecture[END_REF], because a human mind allows focusing on a particular type of diagram at a time. Designers are typically dealing with one type of diagram, which defines behavioral, interactive or structural aspects of a system in isolation. Therefore, it is difficult to take into account semantic dependencies between the static and dynamic aspects related to a particular concern in a very early modeling phase. That is why most conventional IS design methods are not so useful for the detection of inconsistency or incompleteness in various use-cases specifications. In this paper, we will demonstrate how interaction dependencies can be used to construct unambiguous graphical descriptions of scenarios with sequential, iterative, synchronized and alternative behavior. Most of information system methodologies are quite weak in representing the alternative scenarios and the consequences if commitments between actors are broken.

Use-Case Descriptions

Use-case diagrams can be produced in two steps. The first task of the system analyst or project team member is writing use-case descriptions by using a natural language text. The second task is to translate the use-case descriptions into use-case diagrams. A use-case description should contain all needed information for building other UML diagrams. Unambiguity of use-case descriptions is important to validate the semantic integrity of the diagrams. The problem is that the narrative text, which defines flows of events of different use-cases, can be ambiguous, incomplete and inconsistent. There are three types of event flows, which are documented for a use-case: 1) Normal flow of events, 2) Subflows, and 3) Alternate flows.

A use-case can be understood as a transaction. Any transaction can be analyzed as a simple workflow loop [START_REF] Denning | Completing the Loops[END_REF], which captures service value exchange between two or more parties. Both requests and responses are viewed as necessary business events. According to Ferrario and Guarino [START_REF] Ferrario | Towards an Ontological Foundation for Service Science[END_REF], service interactions are not objects or products, they are events. Service responses cannot be delivered without initiating service requests. A response can be viewed in a number of ways. It can be represented by a promise to deliver a desirable result to service requester or it can be viewed as statement, which brings a desired value flow [START_REF] Gordijn | Business Modelling is not Process Modelling[END_REF] to service requester. Any workflow loop indicates that service provider receives service request and transforms it into service response. Service requester, request, service provider and response are minimal set of elements for defining any type of a service interaction loop. It is illustrated graphically in figure 1. The presented elementary interaction loop is a basic element, which can be used in a very early conceptual modeling phase for separation of concerns in information system analysis and design. Two loosely coupled actors will be represented by the following expression [START_REF] Gustas | Conceptual Modeling and Integration of Static and Dynamic Aspects of Service Architectures[END_REF]:

If Request(Service Requester Service Provider) then Response(Service Provider  Service Requester). We will demonstrate the conceptualization of normal flow of events and alternate flows for the slightly modified case study example, which was analyzed by Jacobson and Ng [START_REF] Jacobson | Aspect-Oriented Software Development with Use Cases[END_REF]. In this example, the Reserve Room use-case is extended by the Handle Waiting List use-case. Both use-cases are represented in figure 2.

Fig.2. Example of use-case diagram

The Reserve Room use-case scenario can be graphically defined by two interaction loops between Customer and Hotel Reservation System. The primary interaction loop is composed of the underlying interaction loop. Both loops of the Reserve Room usecase scenario are graphically defined in figure 3. The presented service requesters and service providers are actors. Actors are active concepts, which can only be motivated by a set of interaction dependencies that keep the enterprise system viable. Interaction dependency R(AB) indicates that actor A is an agent, which can perform action R on one or more recipients B. Interaction dependencies in the diagrams are graphically indicated by broken arrows. Broken arrows denote moving flows between actors such as information, decisions or materials. Actors are represented by square rectangles and actions are represented by ellipses. All actions are used to show the legal ways in which actors interact with each other. The first interaction loop (it is graphically represented in figure 3,a) cannot be executed without triggering the underlying interaction loop on the more specific granularity level (figure 3,b). The second interaction loop is initiated by the Hotel Reservation System.

Use-case scenarios are conceptualized by identifying the flow of interaction events. Each event makes about the same amount of progress towards completion of a use-case. The equivalent narrative text of the Reserve Room use-case normal flow of events (see figure 3) can be described as follows:

1) The Customer requests room by entering the specific room requirements (including the desired period of stay), 2) The Hotel Reservation System offers various available rooms with different rates,

3) The Customer selects the available room and enters the required information about an expected room guest. This step can be repeated several times. It means that more than one room can be selected, 4) The Hotel Reservation System creates reservation with the details of all selected hotel rooms, displays reservation information to the Customer and consumes the selected types of available room.

Both graphical and textual descriptions in essence define the Reserve Room usecase as the flow of interaction events. Events are identified by using two kinds of guidelines as far as the syntactic and semantic structure of sentence is concerned. The syntactic guideline has something to do with the form of sentence. Each individual event should be expressed as subject-verb-object and, optionally, preposition-indirect object [START_REF] Dennis | System Analysis and Design with UML. An Object-Oriented Approach[END_REF]. Such constructions are useful in identifying actors, operations and classes. The second set of guidelines is related to the semantic roles various concepts play in the sentences. Normally, each event should define the requester or performer of the action. The use of request-response type of sentences results in user-centered requirements documentation that can be useful for user training and testing. If the usecase description is too complex, it should be decomposed into a set of more simple flows. Subflows or alternate flows can be used for this purpose.

The Basic Constructs of SICM Approach

Event flows can be defined in terms of essential interactions between organizational or technical components. Technical components correspond to enterprise subsystems such as machines, software and hardware. Organizational components can be humans, organizations, their divisions or roles, which denote the groups of people. Interaction dependencies among actors are important for the separation of crosscutting concerns. By following interaction dependencies, it is possible to explore various ways in which enterprise system components are used. Event flows can be analyzed as a set of workflow loops [START_REF] Denning | Completing the Loops[END_REF]. A workflow loop in SICM method [START_REF] Gustas | Pragmatic -Driven Approach for Service-Oriented Analysis and Design[END_REF] is considered as a basic element of scenario, which describes interplay between service requesters and service providers. In its simplest form, any workflow loop is viewed as a response to request that creates promise or provides a value to service requester.

Interaction dependencies are extensively used in a foreground of enterprise engineering methods [START_REF] Dietz | Enterprise Ontology: Theory and Methodology[END_REF]. These methods are rooted in the interaction pattern analysis and philosophy of language. The purpose of introducing them was initially motivated by the idea of creation computer-based tools for conducting conversations. The goal of this paper is different. We are going to demonstrate how to apply the interaction dependencies in combination with the set of semantic dependencies, which can be used for the graphical description of use-case scenarios. The sequences of interaction events are crucial for analyzing scenarios, which are expressed in terms of requests and responses between actors. For example, Create Reservation action can be viewed as a promise in connection to Request Room action.

Behavioral and structural aspects of interactions can be analyzed in terms of their reclassification, creation or termination effects. When two subsystems interact one may affect the state of each other [START_REF] Evermann | Ontology Based Object-Oriented Domain Modeling: Representing Behavior[END_REF]. Structural changes of objects are defined in terms of object properties [START_REF] Bunge | Treatise on Basic Philosophy: A World of Systems Ontology II[END_REF]. Interaction dependency R(AB) between two active concepts A and B indicates that A subsystem can perform action R on one or more B subsystems. An action typically manipulates properties of objects. Otherwise, this action is not purposeful. Property changes may trigger object transitions from one class to another. The behavioral effects of communication actions are expressed by using transition links (──) between various classes of objects. Reclassification of object can be defined in terms of communication action that is terminating an object in one class and creating it in another class. Sometimes, objects may pass several classes, and then they are terminated. Graphical notation of the reclassification construct is graphically represented in figure 4. Structural changes of objects are manifested via static and dynamic properties. Dynamic properties are represented as actions, which are connected to classes by creation and termination links. Static properties can be represented by the mandatory attributes. The mandatory attributes are linked to classes by the single-valued or by multi-valued attribute dependencies. One significant difference of the presented modeling approach is that the association ends of static relations are nameless. The justification of this way of modeling can be found in some other papers [START_REF] Gustas | Conceptual Modeling and Integration of Static and Dynamic Aspects of Service Architectures[END_REF], [START_REF] Gustas | Overlaying Conceptualizations for Managing Complexity of Scenario Specifications[END_REF]. Semantics of static dependencies are defined by cardinalities, which represent a minimum and maximum number of objects in one class (B) that can be associated with the objects in another class (A). Single-valued dependency is defined by the following cardinalities: (0,1;1,1), (0,*;1,1) and (1,1;1,1). Multi-valued dependency denotes either (0,1;1,*) or (1,1;1,*) cardinality. Graphical notation of various static dependencies is represented in figure 5. Overlapping classes can be used to synchronize interaction loops together. For instance, Create Reservation action terminates Hotel Reservation Request object, which was created as a result of Request Room action, and creates Hotel Reservation object. These creation and termination effects are graphically described in figure 6. The corresponding Hotel Reservation and Hotel Reservation Request objects are composed of parts, which must be terminated and created at the same time. In this way, creation and termination effects define constraints on various types of objects in sending and receiving interaction flows between actors. Inheritance, composition and mandatory attribute dependencies can be used for reasoning about the consequences of object creation and termination effects. According to the conceptual modeling rules [START_REF] Gustas | Modeling Approach for Integration and Evolution of Information System Conceptualizations[END_REF], the creation of Hotel Reservation is causing creation of at least one Hotel Room[Reserved] and expected Guest. It should be noted that the semantic power of UML object flow and sequence diagrams combined together is not sufficient for capturing the equivalent effects.

Composition of Interaction Loops

Elementary interaction loops can be viewed as fundamental elements for defining scenarios [START_REF] Gustas | Overlaying Conceptualizations for Managing Complexity of Scenario Specifications[END_REF]. Graphical representation of scenario is an excellent means for describing the order of interactions. More specific underlying interaction loops can be analyzed in the context of the overlaying loops on higher granularity levels as it is required by the principle of separation of concerns. It means that the scope of scenario can vary. A scenario may include just some events, which are of the interest to one specific actor. However, it can naturally be linked to all other overlaying business events. The natural language descriptions of such complex use-case scenarios require a lot of supplementary information, which specifies pre-conditions, post-conditions and other special constrains for inserting subflows into main flow of events. In this section, we demonstrate how to construct the graphical descriptions of scenarios with a more comprehensible structure.

The Reserve Room use-case scenario can be graphically defined by a number of interaction loops between Customer and Hotel Reservation System. The primary interaction loop (see figure 6) can be viewed as an overlay of secondary loop on more specific granularity level. Composition of two interaction loops of Reserve Room usecase scenario is presented in figure 7. A simple interaction loop between service requester and provider in the SICM method is viewed as the basic element of any communication process [START_REF] Denning | Completing the Loops[END_REF]. Interaction loops may be composed together into more complex interaction webs by using creation and termination links. If the object transition effects cannot be conceptualized by using pre-condition or post-condition classes, then the communication action is not purposeful. Interaction dependencies without purposeful actions make no sense and should be eliminated. The modeling of interactions and object transition effects together is critical for reaching semantic integrity among static and dynamic aspects of IS specifications. In the presented example, object creation, termination and reclassification effects show very important semantic details of unambiguous scenario in which two interaction loops are composed together. The more specific workflow loop is underlying the primary interaction loop. The underlying loop is required for the selection of desirable room type and for providing necessary data about guest. Underlying loops can be mandatory or optional. By following the interaction dependencies between actors, designers are able to understand the creation and termination effect in various classes of objects. In this way, the transition links are used to capture the dynamic dependencies between interaction loops.

Select

Bridging from SICM constructs to the Basic Pattern of a Transaction

Interaction dependencies are successfully used in the area of enterprise engineering [START_REF] Dietz | Enterprise Ontology: Theory and Methodology[END_REF]. Our intention is to apply the interaction dependencies in combination with the conventional semantic relations, which are used in the area of system analysis and design. Interaction loops can be expressed by interplay of coordination or production events, which appear to occur in a particular pattern. The idea behind a conversation for action schema [START_REF] Winograd | Understanding Computers and Cognition: A New Foundation for Design[END_REF] can be explained as turn-taking. Requester (R) initiates a request (R: Request) action and then is waiting for a particular promise (P: Promise) or a service provision (P: State) action from Performer (P). Request, Promise and Acceptance are typical coordination actions, which are triggered by the corresponding types of basic events. Coordination events are always related to some specific production event. Both coordination and production events can be combined together into scenarios, which represent an expected sequence of interactions between requester and performer. We will show how creation, termination or reclassification constructs of the SICM method can be used to define the new facts, which result from the main types of events of the basic transaction pattern [START_REF] Dietz | Enterprise Ontology: Theory and Methodology[END_REF]. Four basic events and related reclassification effects are represented in figure 8. New facts resulting from four basic events are instantiated by such classes of objects as Request, Promise, Stated Result and Accepted Result. Two interaction loops between Requester and Performer of the basic transaction pattern are composed together. A promise is created in the first interaction loop. It can be consumed in the next interaction loop. Created or terminated objects and their properties are interpreted as facts, which represent requests, promises and statements about delivered or accepted results. For instance, the Create Reservation action in figure 6 can be interpreted as a Hotel's promise to Provide Hotel Room. Request Room and Create Reservation are typical coordination actions, which can be viewed as triggering events for a corresponding production action.

Two interaction loops, which are illustrated in figure 9, represent one example of the basic pattern of a transaction. It is obvious from the presented example that the Provide Hotel Room business event is viewed as a production event. It creates effects, which can be associated with the transition P: State in the conversation schema (see figure 8). Production event creates the new fact of Stated Result. For example, an Assigned Hotel Room is supposed to create a value for a Room Guest. It is often the case in practice that the promise or acceptance actions are missing, because they are performed tacitly. For instance, the Create Reservation and Accept Room actions are missing in the following service interaction loop:

If Request Room(Room Guest Hotel) then Provide Hotel Room(Hotel  Room Guest).

The pattern, which is illustrated in figure 8, defines the case when service requester and performer are consenting to each other's communication actions. For a communication action to be successfully performed an agent initiates the interaction flow and a recipient agrees to accept it. An enterprise system can be analyzed as the composition of the autonomous interacting components, which may not necessarily consent with each other. Actors can be involved in various interaction loops, because they want to get rid of problems or to achieve their goals. Goals, problems and opportunities [START_REF] Gustas | Pragmatic -Driven Approach for Service-Oriented Analysis and Design[END_REF] may help to understand why different actors act, react or not act at all. For instance, an agent may be not interested to initiate any interaction, or a recipient may refuse to accept the interaction flow. There are many other alternative business events [START_REF] Dietz | Enterprise Ontology: Theory and Methodology[END_REF], which may take be superimposed on the basic transaction pattern.

Alternative Interaction Loops

Alternative interaction loops should be introduced to handle possible breakdowns in the basic interaction pattern. These alternatives are represented by such reclassification actions as Reject and Decline in the standard pattern of a transaction. The alternative actions are necessary for actors involved in the business process to deal with unexpected situations. For instance, a performer may fail to deliver a desired result on time. A performer may experience difficulties in satisfying a request. For example, Hotel Reservation System may Reject Request, because the request requirements were simply incorrect or incomplete. Instead of promising, the performer may respond by rejecting request. Requester may also express disappointment in stated result and decline it. Decline is represented by the termination of Stated Result and creation of Declined Result object. For instance, the Hotel Guest may decline the assigned hotel room, which was assigned by the Provide Hotel Room action. The basic transaction pattern can be supplemented with two dissent patterns, which are represented in figure 10. This extended schema is known as the standard pattern [START_REF] Dietz | Enterprise Ontology: Theory and Methodology[END_REF]. Alternative actions can be represented by different reclassification, creation or termination events with the same object. For example, Request can be either reclassified to Promise or to Rejection. It means that Promise and Reject actions are exclusive. The creation of Promise or creation of Rejection object can only be performed once. The alternative actions must be introduced to handle the breakdowns in the main interaction pattern. For instance, the normal Reserve Room use-case scenario can be accomplished if and only if one or more desirable types of rooms are available for the required period of stay. This flow of events would fail when there are no available rooms, which can be offered. The alternative flow is inserted when the normal flow of events fails. The Handle Waiting List use-case represents such alternative, which can be described as follows:

1) If desirable type of room is not available (failure to offer at least one available room), then the Hotel Reservation System offers waiting list possibility.

2) If customer rejects waiting, then the Hotel Reservation System declines hotel reservation request by Reject Request action.

3) If customer accepts waiting, then the system puts customer on a waiting list and preserves information about his Hotel Reservation Request.

Two different alternatives for handling a Hotel Reservation Request are represented in figure 11 by Reject Request and Handle Waiting List actions. In practice, it is also common that either requester or performer is willing to completely revoke some events. For example, the requester may withdraw his own request. There are four cancellation patterns [START_REF] Dietz | Enterprise Ontology: Theory and Methodology[END_REF], which may lead to partial or complete rollback of a transaction. Every cancellation action can be performed if the corresponding fact exists. For instance, the Withdraw Request action can be triggered, if a request was created by the Request action. In our example, Withdraw Request action is missing. Nevertheless, it is reasonable and should be introduced. The possibility to superimpose four cancellation patters on the standard pattern is not the only advantage of the presented modeling approach. The SICM method has sufficient expres-sive power to cover the other special cases, which are not matching the standard pattern and four cancellation patterns. For instance, it is unclear how the methodology for design and engineering of organizations [START_REF] Dietz | Enterprise Ontology: Theory and Methodology[END_REF] would cope with the Handle Waiting List alternative, which is represented in figure 11. This option is also excessive in comparison with all legal transitions, which are defined by the conversation for action schema [START_REF] Winograd | Understanding Computers and Cognition: A New Foundation for Design[END_REF].

Concluding Remarks

The goal of this paper was to demonstrate the advantages of conceptual modeling approach, which allows introducing evolutionary extensions of use-case scenarios. We have demonstrated how use-case narrative descriptions can be replaced by graphical representations. Integrated conceptual modeling method was used to visualize event flows in terms of underlying, sequential and alternative interaction loops, which are fundamental elements for composition of use-cases scenarios. Elementary interaction loops are important for system architects to construct scenarios, which have an understandable structure. The networks of interaction loops may span across several organizations or partnerships. Each interaction loop can be analyzed separately as it is required by the principle of separation of concerns. In such a way, interaction loops provide a natural way of decomposition of use-case scenarios.

Introducing underlying interaction loops allows system designers to meet evolving needs of stakeholders and to avoid scenario breakdowns, which can be viewed as hidden requirements defects. The breakdowns in the main scenario can be eliminated by introducing the alternative actions, which are necessary to deal with failures. The presented way of interaction loop composition suggests a flexible way for managing the complexity of conceptual representations. We have demonstrated by examples some basic principles of a non-traditional conceptual modeling approach, which allows designers to visualize and to analyze semantic integrity between conceptual representations of use-case scenarios. The advantage of such conceptual representations is that interaction loops can be gradually enhanced or effectively replaced on demand.

Semantic integrity problems in the early system development stages are one source of errors, because use-case descriptions touch several classes. It is very difficult to achieve semantic integrity between the static and dynamic aspects of complex scenarios, because the conventional conceptual modeling methods are developed for analyzing business processes and business data in isolation. Most graphical modeling techniques are not flexible for the visualization of interplay among behavioral, interactive aspects and structural changes of objects. It was also demonstrated how sequential, iterative, parallel and alternative behavior is captured by identifying the transition dependencies between classes in various interaction loops. Separation of concerns is achieved by decomposing complex scenarios into simple underlying loops, which can be analyzed in isolation. The presented graphical descriptions of scenarios are easier to understand, extend and maintain.

Fig. 1 .

 1 Fig.1. Basic interaction loop

Fig. 3 .

 3 Fig.3. Elementary interaction loops of the Reserve Room use-case

Fig. 4 .

 4 Fig.4. Graphical notation of reclassification Unbroken arrows indicate control flow of creation and termination effects. Object classes represent a persistent or transient set of objects. Fundamentally two kinds of changes are possible during any reclassification: termination and creation of an object. A creation is denoted by outgoing transition arrow to a post-condition class. A termination action is represented by a transition dependency directed from a precondition object class. Before an object can be terminated, it must be created. A precondition class in the termination construct is understood as final. For instance, when the Hotel Reservation Request is created, it can be reclassified to the Hotel Reservation by using Create Reservation action.Structural changes of objects are manifested via static and dynamic properties. Dynamic properties are represented as actions, which are connected to classes by creation and termination links. Static properties can be represented by the mandatory attributes. The mandatory attributes are linked to classes by the single-valued or by multi-valued attribute dependencies. One significant difference of the presented modeling approach is that the association ends of static relations are nameless. The justification of this way of modeling can be found in some other papers[START_REF] Gustas | Conceptual Modeling and Integration of Static and Dynamic Aspects of Service Architectures[END_REF],[START_REF] Gustas | Overlaying Conceptualizations for Managing Complexity of Scenario Specifications[END_REF]. Semantics of static dependencies are defined by cardinalities, which represent a minimum and maximum number of objects in one class (B) that can be associated with the objects in another class (A). Single-valued dependency is defined by the following cardinalities: (0,1;1,1), (0,*;1,1) and (1,1;1,1). Multi-valued dependency denotes either (0,1;1,*) or (1,1;1,*) cardinality. Graphical notation of various static dependencies is represented in figure5.

Fig. 5 .

 5 Fig.5. Notation of static dependencies between conceptsThe diagram presented in figure3does not provide any semantic details of control flows between communication actions. It shows only the necessary events in a Room Reservation scenario. The actions such as Request Room and Create Reservation should also specify the acceptable ways for structural changes to occur in different classes of objects. In general, communication actions can be sequential, iterative, alternative or synchronized with the secondary workflow loops. Triggering conditions of the secondary interaction loops may depend on the objects, which are created or terminated in the overlaying interaction loops. Pre-condition and post-condition classes are crucial to understand the dynamic aspects of interactions. A created object in one loop can be consumed in another. The creation and termination of objects allows constructing scenarios, which are enclosing optional or mandatory workflows.Overlapping classes can be used to synchronize interaction loops together. For instance, Create Reservation action terminates Hotel Reservation Request object, which was created as a result of Request Room action, and creates Hotel Reservation object. These creation and termination effects are graphically described in figure6.

Fig. 6 .

 6 Fig.6. Overlaying description of the Reserve Room use-case scenario

Fig. 8 .

 8 Fig.8. The basic pattern of a transaction

Fig. 9 .

 9 Fig.9. Example of the basic transaction pattern

Fig. 10 .

 10 Fig.10. The standard transaction pattern

Fig. 11 .

 11 Fig.11. Two alternatives of handling Hotel Reservation Request Create Reservation action is an event of the expected scenario. It can be performed successfully on a condition that Hotel Reservation is created. Possibility of failure to compose the Hotel Reservation of at least one Hotel Room[Reserved] would cause a breakdown in the basic transaction pattern, which requires the definition of at least one alternative event. The first alternative is represented by Handle Waiting List action, which defines the reclassification effects of Hotel Reservation Request object. The second alternative is the termination of Hotel Reservation Request by Reject Request action. This option may be caused by a failure of the Handle Waiting List action. Please note that Customer[On Waiting List] object can be created just in case the Customer agrees to Accept Waiting in the underlying interaction loop.In practice, it is also common that either requester or performer is willing to completely revoke some events. For example, the requester may withdraw his own request. There are four cancellation patterns[START_REF] Dietz | Enterprise Ontology: Theory and Methodology[END_REF], which may lead to partial or complete rollback of a transaction. Every cancellation action can be performed if the corresponding fact exists. For instance, the Withdraw Request action can be triggered, if a request was created by the Request action. In our example, Withdraw Request action is missing. Nevertheless, it is reasonable and should be introduced. The possibility to superimpose four cancellation patters on the standard pattern is not the only advantage of the presented modeling approach. The SICM method has sufficient expres-

  Integrated conceptual representation of the Reserve Room scenarioThe primary loop of the Reserve Room use-case is synchronized with the underlying interaction loop. It defines the functionality of offering and selecting available hotel rooms. The underlying interaction loop is as follows:If Offer Rooms(Hotel Reservation System Customer) then Select(Customer  Hotel Reservation System). According to the presented control flow, the Select room action cannot be triggered prior to Offer Rooms action. Select action can only be performed in parallel with the Create Reservation action, because the creation of Hotel Reservation is synchronized with the creation of its compositional part Hotel Room[Reserved]. The termination of Hotel Reservation Request is synchronized with the reclassification of Type of Room[Desirable] to Offer, which is composed of at least one Hotel Room [Available].

		Room Requirements	Request Room		Hotel
					Reserva-
					tion System
	Customer	Hotel Reservation		Customer
		Request
			Create	Reservation
		Reservation		Customer
		Type of Room			Identified
		Desirable		Hotel Reservation
		Offer Rooms	Available Hotel Rooms
				Hotel Room
	Customer	Hotel Room Available	Offer	Reserved	Hotel Reserva-
					tion System
				Guest
		Room Guest
		Data
	Fig.7.