Use Case Model

In this section we present a use case model for the RCS. We specify primary actors, those who will directly use the RCS services, and secondary actors, those who will collaborate with the RCS to realise a specific use case. In Figure 6.2 the diagram with the use cases we found is shown.

Replica Consistency Service

Update file

Retrieve update operations status

Manage RCS settings Register/Unregister

datasets

Monitor RCS functions Retrieve replicas status

Privileged User

Monitoring System

Replica Interface

Service Client

Get dataset info

RMS

Update replica Information Check dataset consistency

Check dataset coherence

Update DB

Time

6.2. Requirements 93

6.2.3.1 Actors

The main actor of this model is the Service Client: it can be a user that directly uses a command line client interface on its UI machine, a user’s job or even another software program or middleware service. For this reason we use the class icon instead of the stick figure.

The actor Privileged User is a specialisation of the previous actor, since it is a user with specific rights that allow him to do critical operations like setting and changing the RCS properties. Being a specialisation of the “Service Client” actor, it also inherits the use cases of its parent.

Then there is a possible Replica Management Service that might work in collab- oration with the RCS: its task as regards the RCS is to integrate information about dataset consistency provided by the RCS with the one that it directly manages.

The class representing the Monitoring System, in charge of collecting informa- tion regarding the behaviour of the RCS, is another primary actor.

Time can be seen as another actor in that some operations can be executed peri-

odically; in particular we should note that the Update file and Update DB use cases are associated both to the Service client and the Time actors. This means that these use casee can be executed by the client, with a specific request, or automatically, with a given periodicity.

As regards secondary actors, we have a Replica Interface which provides inter- face services between the RCS and the replicas.

6.2.3.2 Use cases description

In our case a formal use case specification is not very useful because the system has only two basic use cases: Update file and Update DB; all the others are ancillary to these two or represent simple methods to retrieve or set properties. Moreover, these use cases depend on complex algorithms and can be further specified in an automatic (triggered by a time event) and a manual one (triggered by a user request). Therefore, we focus our attention on these two use cases.

The use cases Update file and Update DB can be seen as specialisation of a gen- eral use case, Update dataset. Both of them can also have a manual and an automatic version. This generalisation is shown in Figure 6.3 where we highlighted the two specifications that we will focus on.

The two sub-cases have many similarities but are also different, not only for the data they work on, but also for the way the clients use them. For both cases we will show a basic scenario with the description of the main steps involved.

Service Client

Update dataset

Update DB Update File RCS

Time

Replica Interface

Automatic Manual Automatic Manual

Figure 6.3: Specialisation for the Update dataset use case based on the dataset type Another specialisation we can do over the Update dataset use case is related to the algorithm used. Looking at the classification done in Chapter 3 about optimistic replication, we can derive different use cases from the Update dataset one. The Figure 6.4 shows the consistency protocols hierarchy. The choice of the algorithm used is based on application specific requirements.

Update Dataset

Asynchronous

Synchronous

Single Master

Log-based File repl.

Multi Master

Figure 6.4: Specialisation for the Update dataset use case based on the protocol used In the next section we review two main use cases that will be the focus of our first prototype implementation.

6.2. Requirements 95

6.2.3.2.1 Automatic DB update with single-master asynchronous log-based push mode protocol Database update is one of the main use cases for the RCS since

it satisfies requirements regarding the replication of conditions databases (see Sec- tions 4.3) and Replica Catalogues (see Section 5.2). We now specify all the steps that must be done in order to execute this use case, stating actors involved, pre-conditions, flow of events and post-conditions.

• Actors: Time, Replica Interface.

• Preconditions:

1. A logical DB is registered with the RCS together with its replicas. 2. One of the replicas is the master one, and it is the only one that can be

updated by users. The other secondary replicas must be updated by the RCS.

3. At a certain point in time, the master database is updated and a log is created. A log file on the master database contains the statements that modified the database.

• Flow of events:

1. The use case scenario starts at a certain time and repeats with a given pe- riodicity. The RCS extracts update statements from the log of the master database and creates an update unit.

2. Database replicas can be hosted on DBMSs of different vendors, with different SQL dialects. The RCS before propagating the update unit must elaborate it to make it suitable for the replica it will be applied to. 3. The RCS propagates the update unit to the secondary replicas. The update

unit is stored until every replica has correctly received and applied it. Replicas are distributed geographically and by means of unreliable links: this implies that the RCS must deal with cases where some replicas are not available during an update operation. An update operation must be able to complete and deal with the disconnected replicas in a flexible way, with the possibility to use a quorum value.

4. At each replica site the update unit is applied to the database replica using the Replica Interface.

1. All the replicas of that DB, after a variable amount of time1_{, are synchro-}

nised.

6.2.3.2.2 Update file with single-master asynchronous file replacement push mode protocol This is the main use case for flat files.

• Actors: Service Client, Replica Interface.

• Preconditions:

1. A logical file is registered with the RCS together with its replicas. 2. A Service Client modifies a replica creating a new version of the file.

• Flow of events:

1. To update all the secondary replicas the Service Client requests an update file operation to the RCS, providing the location of the new version of the file.

2. The RCS finds all the replicas and propagates the new version of the file. The same consideration about disconnected sites for the previous scenario applies here as well. An update operation must be able to successfully execute despite disconnected nodes.

3. At the destination sites, the new file replaces the old one.

• Postconditions:

1. All the replicas of that file, after a variable amount of time are up-to-date and synchronised.