当初、プログラミングは数学から生まれましたが、時間が経つにつれて数学に精通した厳密さが失われました。 それにもかかわらず、数学との関係は存在し続けています。 いくつかの問題を解決するために、個別の数学と論理のセクションが助けとなり、明快さと独自性をもたらします。 ほとんどのビジネスプロセスには個別の特性があるため、離散数学はビジネスオートメーションシステムの形式化に適しています。 たとえば、契約の種類の数は、数十単位で計算されますが、数百単位ではありません。 日付にも個別の性質があり、その数は1年の日数に比例します。 実際、ほとんどの場合、浮動小数点数で記述されるように見えるマネー操作は、セントまたはセントの整数で正確に記述されます。 したがって、セントまたはセントは、組織が存在する間ずっと組織を通過しており、非常に具体的な自然数で表されます。 また、現代の数学の基準では、これらの数値はすべて非常に小さいものです。
数学者にとって、質問の声明は明確です。 数え切れないほどの数のオブジェクト、数え切れないほどの数の自由度、オブジェクトの状態などがあります。 すべての仕様は、単純なカウントに役立ちます。 可算有限集合の推定と計算は難しくありません。 組み合わせ論または離散数学のコースを完了した人は、システムのすべての可能な状態を形式化する方法と、正しい状態と正しくない状態を識別する方法の計画を概説することができます。 数学から得られるものは次のとおりです。
- オブジェクトの状態の可能なオプションの数を数えます。
- すべてのオプションが考慮されているか、または考慮されていないかにかかわらず、完全性の証拠。
- 不正確な条件の有無の証拠;
- 誤った状態または正しい状態につながる例を検索します。
- 特定のアクションの等価性の証拠;
- などなど。
今、私たちはこのプロセスを複雑にしている陰険な敵に対処しようとします。 たとえば、TORの作成者は、何らかのアクションが実行される契約の種類の特定のリストを転送します。 TKに「すべての種類の契約」または「...を除く他のすべての種類の契約」という語句が表示される場合があります。 プログラマーは、ビジネスからの時間とプレッシャーの欠如で、ToRを正しく実現しようとします。 多くの場合、新しい変更に対するプログラムの準備について考える必要はありません。テストに合格し、コメントを修正し、合格し、報告し、先に進むだけです。
プログラマーがアカウンティングエントリのアカウント番号を置き換える手順を実行するとします。 TORでシステムに存在するすべてのタイプのコントラクトのリストを見たり、「すべてのタイプのコントラクト」というフレーズを見たりすると、プログラマーは最初の間違いを犯します。 その結果、アカウントを置換する彼の手順は、契約のタイプを分析しません。 一見、犯罪はありません。
それがキャッチです。ToRの執筆時点での「すべてのタイプの契約」という概念には、10種類が含まれていました。 その後、この概念が変わり、半年後にさらに2、3種類が追加されます。 そして、それらが古いロジックに適合するかどうかは、前もって明らかではありません。
大規模なプロジェクトでは、新しいハンドラーを挿入できる場所がさらに多くあります。 最初のプログラマーは長い間他のタスクに切り替え、タイプに応じて、アカウントがどこでどのように置き換えられるかを忘れていました。 新しいタイプの契約を処理するタスクは、システムを研究した後、ハンドラーを追加できる新しい場所を見つけた別のプログラマーに委ねることができます。 たとえば、2番目のものは別の場所に処理を追加します。クライアント上、サーバー上のプロシージャ内、トリガー内、またはその他の場所です。 このような放浪により、時間の経過に伴う論理はほとんど理解されなくなります。 ルールを処理し、最も予期しない場所でルールの例外を処理すると、コードが混乱します。
運がよければ、新しいタイプの契約には以前の契約との違いはほとんどありません。 そしておそらく、一般化を許可し、なじみのない要素のヒットを分析しなかったハンドラーは正しく動作します。 しかし、経験豊富な各プログラマーは、慎重に作成された回路を破る新しい要件を顧客が持ち込んだ状況に遭遇しました。 数十人または数百人の従業員のチームが数年にわたって開発した新しいタイプの契約を追加した後、プログラムがどのように動作するかを予測することは困難です。 古い普遍的な手順と機能は、ますます多くの種類の契約の下で徐々に機能し始め、ますます多くのデータがそれらの作業に依存しています。 修正を行うとシステムが破損する可能性があり、湾曲したデータの修正、バックアップからの回復、変更履歴の分析に時間がかかるため、時間が経つにつれて、これらの手順や機能に入ることがますます危険になります。 食い違いがあるため、本来あるべきではないところにバックラッシュが現れ、外れたところに硬い構造が現れます。 このプロジェクトは、ギアボックスが詰まった車のようになり、ステアリングホイールが前後にぶら下がります。
この状況から抜け出す方法は、それ自体を示唆しています-技術タスクまたは後続の技術設計の段階で契約のタイプのリストを修正する必要があり、プログラムが不慣れなタイプに遭遇した場合、エラーを出します。 これにより、形式化に有害な一般化が排除され、プログラムが突然新しいアカウントにないタイプに遭遇した場合、プログラムはすべての場所から自動的に通知します。 開発者は、新しい要素を考慮する場所を知っており、毎回古いコードにくさびを入れる新しいバージョンを使用しません。
あなたが自分自身を判断するこの利益の程度。
- TKコンパイラーと開発者との間の不一致が軽減されます。 一般的な単語は詳細によってサポートされています。
- テストされていないパラメータがデバッグされたアルゴリズムに入る可能性を減らします。
- 新しいタイプの処理を追加する必要があるコード内の場所が表示されます。
- コードの規律を増やします。 ロジックが同じ場所に集中し、散らばらない可能性が高まります。
- 形式化と自動コード分析が容易になります。
データベースで管理できるハードコードリストは提案しません。 pl / sqlに似た擬似コードの原則を説明するために、最も単純な例を示します。
// 1. // , . // , . // , // . forall type_id in (all_type_list) loop do_something; end loop; // 2 // if type_id not in (555,666) then do_something; end if; // 3 // , . // // , if type_id in (333,444) then do_something; end if; ////////////////////////////////////////////////////////////////////// // . //////////////////// // 4. if type_id in (1,2,3) then do something; else // , , . raise error; end if; // 4,5,6. // 1, . if type_id in (1,2,3,4,5,6) then do_something; else raise error; end if; // 2, . if type_id in (1,2,3) then do_something; elsif type_id in (4,5,6) then do_something_2; else raise error; end if;
トピックに関する続きを書く予定です。
- 条件タイプ/サブタイプのバンドルを処理する方法
- TKで競合する要件を自動的に検出する方法
- リストを自動化し、アナリストにリストを管理させる方法
- 数学を使用してシステムを分析する方法
- メタシステムによるプロジェクト開発
D.A.リバコフ、2016
博士号