Rindrics Mumbles logo

Rindrics Mumbles

ABC 計算のモデル化

以前の記事で資源評価事業の DFD をいくつか描いてみたので、今回は実際に事業の一部をモデル化してみた。

ごく入り口ではあるが、レベル0 DFD の入口部分にあった「資源計算」の部分だ:

本記事でモデリングした関心領域

本記事でモデリングした関心領域

DFD には書き忘れたが、「資源計算」と言っているのは ABC（生物学的許容漁獲量）算定の部分だ。

コードはこのリポジトリにあり、実装言語には TypeScript を選んだ。 本当は、ドメインモデリングには学習を兼ねて Haskell を使ってみたかったのだけれど、動く web アプリケーションとしての開発速度とデプロイ速度も重視したいという現実的な理由から、ひとまず Next.js on Vercel を選んだ。 開発メモとして記事に残しておく。 当然だが、ここで解説されている設計は執筆当時のもの。

モデルの概要

ドメインモデルは src/domain/models.tsに置いてある。

資源評価評価対象の系群は、入手可能なデータの質と量が豊富な順に「1系」「2系」「3系」と分類されているので1、これもモデル化しておいた:

export type FisheryStock = Type1Stock | Type2Stock | Type3Stock;

ABC を得るには、まず資源量推定をして、

export abstract class FisheryStockBase {
  // 中略
  estimateAbundance(
    catchData: CatchData,
    biologicalData: BiologicalData,
  ): this {
    this.#abundance = `estimated using ${catchData.value} and ${biologicalData.value}`;
    return this;
  }
}

それから評価タイプに応じた計算する必要がある（資源評価法も分かれてた気もするが、それはあとからモデリングすればよい）。 1系資源の場合には再生産関係を使って将来予測し、

export class Type1Stock extends FisheryStockBase {
  // 中略
  assess(): AcceptableBiologicalCatch {
    // Simulation logic with stock-recruitment relationship
    return {
      value: `Simulated WITH recruitment using its abundance "${this.abundance}"`,
    };
  }
}

3系資源の場合には直接算定する:

export class Type3Stock extends FisheryStockBase {
  assess(): AcceptableBiologicalCatch {
    // Direct ABC estimation logic
    return {
      value: `ABC estimated DIRECTLY using its abundance "${this.abundance}"`,
    };
  }
}

この ABC 算定のステップをドメインモデルをそのまま使って表現すると下記のようになる:

const type1Stock = new Type1Stock("なんか 1系の魚"); // 将来的には MaiwashiTaiheiyou() みたいなコンストラクタがほしい

const abc = type1Stock.estimteAbundance(catchData, biologicalData).assess();

これを DFD と整合するレベルに整えるためにアプリケーションサービスで包んだ:

const type1Stock = new Type1Stock("なんか 1系の魚");
const abc = calculateAbc(type1Stock, catchData, biologicalData);

ということで、コード中に使われているクラス名で DFD を描き直すと下記のようになる:

型のシグネチャが DFD と一致しているのがポイント

型のシグネチャが DFD と一致しているのがポイント

アプリケーション中での利用

執筆時点の本番環境には、資源評価結果を示す /dashboard という画面が提供されており、ここに表示されている情報は前述のアプリケーションサービス経由で表示されている:

文字しかないが、一応すべて「計算」されたもの。この曳光弾を頼りに改善していけばいい

文字しかないが、一応すべて「計算」されたもの。この曳光弾を頼りに改善していけばいい

このモデリング時点では、それぞれの「計算」は雑に文字列を結合しただけのものではあるが、画面に表示されている情報が実際に「計算」されたものであるところに意味がある。 『達人プログラマー』がいうところの「曳光弾」というやつだ。 今後の改善で正式な実装に差し替えればいい。

展望

ひとまず値が画面上に見えるようにしたかったこともあり、現時点の /dashboard の設計は本来あるべき姿になっていない。 というのも、/dashboard 中で ABC 算定をやっているのだ。 本来なら、/assess のような画面が必要なはずで、評価担当者が自分専用のその画面でパラメータ調整などをし、「確定」処理によって評価結果を登録するイメージだ。 /dashboard は、そのように書き込まれたデータを読み出すだけの画面にする必要がある。

ということで、現時点では下記の開発 epic を積んである:

今回はここまで。

  1. ここやここで解説されている ↩︎

comments powered by Disqus