Difference between revisions of "Java Team2 Benchmark3"

Revision as of 11:39, 6 July 2016

FiTS (A Financial Transaction System) is a bare-bones system mocking the behaviour of a financial transaction system. It emulates a virtual banking system in which users may open accounts from which they may perform money transfers. For more information read the manual at [1]

Categories: Financial

Benchmark Data

The Trace Part

The relevant files can be found on the server at: home/larva/Benchmark3

The script will run a scenario that violates the property defined in the rest of this page.

Instrumentation Information

We have defined the following pointcuts to capture the relevant events for this benchmark (see the next section for their use):

   pointcut openSession(UserSession us) : 
       call(public Integer UserSession.openSession()) && target(us);

   pointcut closeSession(UserSession us) : 
       call(public void UserSession.closeSession()) && target(us);

   pointcut log(UserSession us) : 
       call(public void UserSession.log(..)) && target(us);

Trace Statistics

The Property Part

Informal Description

Logging can only be made to an active session (i.e. between a login and a logout).

Demonstration Traces

Satisfying Traces

• userDepositFromExternal⁹⁹⁹; userDepositFromExternal; reconcile

• userPayToExternal⁹⁹⁹; userPayToExternal; reconcile

• userPayToExternal [Verification.totalExternalTransferAttempts < 1000000]; userPayToExternal [Verification.totalExternalTransferAttempts >= 1000000]; reconcile

Violating Traces

• userDepositFromExternal⁹⁹⁹; userDepositFromExternal; userDepositFromExternal;

• userPayToExternal⁹⁹⁹; userPayToExternal; userDepositFromExternal;

• userPayToExternal [Verification.totalExternalTransferAttempts < 1000000]; userPayToExternal [Verification.totalExternalTransferAttempts >= 1000000]; userDepositFromExternal

Formal Specification

The property is specified formally in a Guarded Command Language, units in which consist of an event, guarded by a condition, upon which a specified action is performed. For more information see [2].

   UserSession.openSession(..) target (UserSession s) 
         | -> { Verification.openSessions.add(s); }
   UserSession.closeSession(..) target (UserSession s) 
         | -> { Verification.openSessions.remove(s); }
   UserSession.log(..) target (UserSession s)
         |  !Verification.openSessions.contains(s)
         -> { Verification.fail("P10 violated"); }

Note that we also make use of the static class Verification for keeping tracking of the open sessions. This can be used by any attempts to monitor for this property.

We can also specify a regular expression for traces that violate this property as follows:

   property foreach target (UserSession u) not matching{
       (!openSession)*;(openSession;(!closeSession)*;closeSession)*;(!openSession)*;log
   }

A FO-LTL Specification

Clarification Requests

This is a space where other teams can ask for clarifications and the submitting team can answer. When a team requests a clarification, the team should be mentioned in the request and the request timestamped. The team submitting the benchmark should ensure they watch this page so that they get notifications of questions.

Looks like the Demonstration Traces are just copy and paste from Benchmark 2. Could you please update them. -- Malte, Mufin, 2016-07-04T11

The length of the benchmark means that performance monitoring will tell us very little. I suggest two solutions (i) we only score this benchmark for correctness, (ii) you loop some of the behaviour to give a non-trivial workload -- Giles, 2016-07-06