モジュール化とワークフローエンジンに関するParnasの論文
ソフトウェアエンジニアリングのクラスでは、モジュール化に関するパーナスの独創的な論文を読むという課題がありました[0]。このホワイトペーパーでは、ソフトウェアをモジュールに分割する2つのアプローチについて説明します。
- 従来のアプローチ：フローチャートは、単一の処理ステップとプログラムの高レベルのフローを実行するために作成されます。次に、すべての処理ステップがモジュールに変換されます。このアプローチでは、あまり良い結果は得られません。
- 新しいアプローチ：すべての設計上の決定は、情報隠蔽によってモジュールに変換されます。このアプローチは、はるかに良い結果につながります。
設計上の決定という用語の私の個人的な解釈は、モジュールがアルゴリズムの処理ステップとしてではなく、データ構造として識別されるというものです。データ構造は、アルゴリズムのステップを処理するよりも情報を隠すのにはるかに適しているため、これは理にかなっています。 （データ構造内の情報は関数の背後に隠されていますが、関数はより詳細な処理ステップのみを隠し、情報は隠していません。情報は実際には引数として渡されます。）
2番目のアプローチが最初のアプローチよりもはるかにうまく機能するのはなぜですか？これが私の2番目の解釈です。アルゴリズムの単一の処理ステップは置き換え可能ではありません（したがって再利用できません）が、データ構造を他のデータ構造に変換することは可能です。
そして、ここに私の質問があります：それがワークフローエンジン（たとえばBPMNに基づく）を使用したソフトウェア開発が実際に成功しなかった理由でしょうか？
私の個人的な経験では、このようなワークフローで作成されたアクティビティはほとんど再利用されませんが、ほとんどのアクティビティで1つまたは2つしか使用されていない場合でも、関連するすべてのアクティビティにビッグデータ構造が渡されることがよくあります。
私の質問は誇張されています：マネージャーにParnasの論文を読んでもらうことで、これらの不器用なワークフローエンジンをすべて取り除くことができますか？
[0]：システムをモジュールに分解する際に使用される基準について（Parnas 1972）
「新しい」（1971年）アプローチが優れているのはなぜですか？
パーナスが推奨するアプローチである2番目のアプローチは、 関心の分離 の原則を保証します。
言い換えれば、変更が困難で変更される可能性のある設計上の決定を特定し、それらをモジュールにカプセル化すると、システムアーキテクチャが作成され、独立したものが独立した状態に保たれます。結果として、ほとんどの変更はモジュールに対してローカルのままになり、コードベースが大きくてもメンテナンスが容易になります。
今日では、オブジェクト指向プログラミングとマイクロサービスを使用して、この原則をさらにいくつかのレベルに適用しています。
それはワークフローエンジンを殺しますか？
ワークフローエンジンは非常に異なるニーズに対応しており、最初のアプローチの実装と見なされるべきではありません。
最初のアプローチは、タスクとビジネスプロセスのアルゴリズムによる順次分解に基づいています。これにより、分析されたワークフローに従って、モジュールが厳密な方法で相互に柔軟に通信しなくなります。
それどころか、ワークフローエンジンは、異なるシステムとアクター間の複雑な相互作用をモジュール方式で実装します。これらの相互作用をカプセル化することにより、オーケストレーションを簡単に変更できます。
さらに、ワークフローは技術的な問題だけではないことを言わなければなりません。たとえば、承認ワークフローを自動化するときに、人間をモジュールに置き換えることはありません。承認ワークフローでは、複数の人間のアクターがさまざまなシステムやアプリケーションを介して協力し、ビジネス上の意思決定を行います。