4.2 Wymagania funkcjonalne

Projektując symulator (System Replikacji Transakcji, w skrócie: SRT) musieliśmy przyjąć odpowiedni poziom wierności odwzorowania rzeczywistego systemu [7]. Wprowadzenie dużej liczby szczegółów znacznie zwiększa nakład czasowy na implementację systemu i prawdopodobieństwo wystąpienia błędów a także utrudnia ich wyśledzenie. Z kolei zbytnie uproszczenie systemu zmniejsza wiarygodność uzyskanych wyników. Ustaliliśmy pewien kompromis i przyjęliśmy następujące założenia:

1. System umożliwia wymianę komunikatów w ramach transakcji w modelu klient-serwer.
2. System działa na dwóch maszynach: maszynie podstawowej i maszynie zapasowej. Klienci są umieszczeni tylko na maszynie podstawowej. Transakcje są uruchamiane na maszynie podstawowej, a replikowane na maszynie zapasowej.
3. System umożliwia testowanie różnych algorytmów -- czynnikami zmiennymi są algorytmy, ich parametry oraz rodzaj obciążenia roboczego systemu.
4. System nie jest odporny na awarie -- chociaż rzeczywisty system powinien być odporny, to nie wymaga się tej cechy w przypadku symulacji. Wydajność algorytmów jest testowana dla przypadku, gdy nie występują awarie (można założyć taką sytuację, ponieważ w rzeczywistym systemie awarie zdarzają się stosunkowo rzadko).
5. Transakcje nie działają w modelu konwersacyjnym. Przyjęliśmy podejście charakterystyczne dla RPC^4.1, czyli synchroniczną obsługę żądań klienckich przez serwer.
6. Zajmowanie zasobów jest symulowane przez opuszczanie semaforów. Rezygnacja z zastosowania rzeczywistej bazy danych uniezależnia wyniki od konkretnej implementacji i upraszcza system testowy.
7. Serwer nie ma możliwości wycofania transakcji. Może to zrobić tylko serializator w przypadku ich złego uszeregowania.

Rysunek 4.1: Architektura systemu