2016-05-05 11 views
1

大きなコードベースをScalaに移行し、Akka Actorモデルを活用することを検討しています。Scala/akka離散事象シミュレーション

既存のコードベースでは、ビジネスロジックは、決定的な結果を持つSimPyのような離散事象シミュレーション(DES)を使用してテストされます。実時間プログラムが実行されている間、DESには数分かかります。リアルタイムシステムは非同期であり、テストセットアップの正確な順序に従う必要はありません。私は、テストセットアップとリアルタイムセットアップの両方に同じAkkaコードを活用したいと思います。 Scala + Akkaでこれを達成できますか?

私は、中央メッセージキューの俳優のアイデアを思いついた - しかし、これは正しいアプローチではないと感じています。

+0

私はちょうどここに同様の議論に出くわします。http: //stackoverflow.com/questions/13550532/time-based-simulation-withactors-model – user6296589

+0

私自身のExecutionContextを実装し、カスタムakka.Schedulerを提供するかもしれません。それで十分ですか? – user6296589

答えて

2

あなたが述べた問題を解決する私の一般的なアプローチは、Akkaコードから "ビジネスロジック"を分離することです。これによりビジネスコードをユニットテストすることができます&イベントは非常にリーンなAkkaコードを書くことができるAkkaから独立してテストされています。

例として、あなたはビジネスロジックは、いくつかのDataを処理することですねと言う:

object BusinessLogic { 
    type Data = ??? 
    type Result = ??? 

    def processData(data : Data) : Result = ??? 
} 

これは、任意の同時実行環境で実行することができますきれいな実装であるだけではなく、アッカ(スカラ先物、Javaスレッド、...)。このビジネスロジックは、個別イベントシミュレーションで実行することができます。

val someDate : Date = ??? 

val historicData : Iterable[Data] = querySomeDatabase(someDate) 

//discrete event simulation 
val historicResults = historicData map BusinessLogic.processData 

同時にロジックをAkka Actorsに組み込むことができます。一般的には、「データディスパッチャー」よりごreceive方法の何をしないために非常に有用である、receiveに存在する任意の実質的なコードがあってはならない。

class BusinessActor extends Actor { 

    override def receive = { 
    case data : Data => sender ! BusinessLogic.processData(data) 
    } 
} 
関連する問題