はじめに
3つの異なる平面上の1つのオブジェクトの3つの投影は、オブジェクトではありません。 これが彼の絵です。 3つの投影法すべてにより、エンジニアは部品を提示できます。 これを行うには、図面内のポイントと空間内のポイントを関連付けます。 このスキルは、記述ジオメトリのトレーニングによって促進されます。
投影モデリングについてもまったく同じことが言えます。 空間と時間の両方の投影だけが、デザイナーが言いたかったことを想像することを可能にします。 これを行うには、4-D時空を正しくモデル化する方法を学習し、これらの投影を互いに正しく相関させる必要があります。 この記事では、この種のモデリングの実用的な例を紹介します。 誰かにとって、それは非常に珍しいことです。 逆に、誰かにとっては、すべてが明白すぎるように思えます。
森林組成モデリング
身近なオブジェクトのモデリングから始めましょう-フォレストをシミュレートしようとします。 Ivanovが森林などのオブジェクトとして扱う4-Dボリュームがあります。 この事実をシミュレートするために、この4-Dボリュームをシミュレートする情報オブジェクト（IO）が作成されます。 次に、この4Dボリュームに関するIvanovのアイデアをシミュレートするIOが作成されます。 このオブジェクトは、「何を表す」関係によってボリュームの4-Dモデル、「誰が表す」というイバノフモデル、および「どのように表すか」というフォレストのモデルと接続されています。
森の構成をシミュレートするように頼んだらどうしますか？ おそらく、このフォレスト内のすべての木をシミュレートすることをお勧めします。 それから私はあなたに質問があります：最初のものより詳細な説明があり、2番目よりも詳細ではありませんか？
そのような説明があります。 子どもたちに森とは何かを説明すると聞くことができます。 森は木でできていると言われます。 正式に説明してみましょう。 特定の森林は、アスペン30％とシラカバ70％で構成されていることをお知らせください。 この事実をシミュレートするには、バーチとアスペン（OOPではこれらはクラス）のツリータイプをモデル化する2つのIO、ヒープの形式での4DボリュームのIvanovの表現をシミュレートする1つのIO、およびヒープの構成をモデル化する1つのIOが必要です。 次に、モデリング構成であるAIを、「70％からなる」接続を持つシラカバの種類と、「30％からなる」接続を持つアスペンの種類に接続します（これはOOPでは不可能です）。
私たちは森を木の山と考えましたが、森に似た要素の山と考えることもできます-森の一部であり、森でもある山から。
このモデリング方法は、ソリッドモデリングの例で理解しやすくなります。 固体物理学を経験した人は、音波をシミュレートするには物質を物質に分解する必要があることを覚えています。
森林の例はまだ緊張しているように見えるかもしれませんが、この種のモデルは、商品のロールごとの在庫がグループに変わるときに発生します。 たとえば、生産が商品の各ユニット（箱）を考慮に入れ、消費者が箱のバッチで記録を保持する場合。 または、多くのコンシューマがある場合、それらはすべて配信ネットワークのノードを表し、それぞれが異なるボリュームのバッチでレコードを保持します。 ボックスの作成から廃棄までのライフサイクル全体をトレースできるシステムを作成する場合、この場合、そのようなロットをシミュレートできる必要があります。
私の記事では、セットモデリングを通じてこの種のケースをシミュレートする必要性について繰り返し話し、通常のモデリング表記法または最新のプログラミング言語を使用してこれを行うことは不可能であることを示しました。 なぜこれが起こったのかはわかりませんが、これがモデリング科学の発展にブレーキをかけたことは確かです。 この種のツールがあれば、私たちの前にどんな機会が開かれるかについて話し、興味のある人にそのようなツールを作成するように勧めます。
機能モデリング
モデルセットの可能性を示す印象的な例は、関数のモデリングです（単語の数学的な意味ではなく、機能の説明という意味で）。
モデリングセットが不可能であるために関数の定義を正確に定式化することが不可能になった場合、関数に関してかなり奇妙な状況が発生しました。 また、関数の定義がないため、アナリストはそれを想像することもモデル化することもできません！
投影モデリングの助けを借りて、関数の決定とモデリングの問題は、森林モデリングと同じ方法で解決されます。
蒸気機関車を製造している企業があるとします。 この4-Dボリュームの解釈はIvanovによって行われたと仮定します。 企業は宇宙で感じられ、見られ、聞かれ、ローカライズされます。
Ivanovは、同じ4-Dボリュームの別の解釈を行うことができます。 彼はそれを蒸気機関車の生産のための関数として解釈することができます（1つの観点は他の観点と矛盾しません）。 初めて私を読んだ人にとって、この機能は、企業のように、宇宙で感じられ、見られ、聞かれ、ローカライズされると言えます。 この機能を説明するように頼むと、おそらくこれを行うのは難しいでしょう。 これを行おうとする人は、次の間違いを犯す可能性があります。
- 関数を記述する代わりに、彼らはこの関数の構造を記述しようとします。 たとえば、蒸気機関車を製造する機能は、蒸気機関車を製造し、蒸気機関車を販売することであると彼らは言います。
- 機能を説明する代わりに、彼らはこの機能が含まれる設計を説明しようとします。蒸気機関車の生産は、蒸気機関車のスペアパーツの生産と蒸気機関車の消費に含まれます。 このようなエラーは、関数が変換であると言うときに発生します。
- 関数を記述する代わりに、その関数は抽象化であり、感じたり記述したりできないと述べられます。
- 最も近いのは、関数に出入りするスレッドをシミュレートしようとする人です。 関数に関するこの観点は、IDEF0標準によって課せられたものであり、それ以来、そのような記述の望ましさは疑問視されていません。 しかし、それは特定の種類の衝突を引き起こします。これについては、以前何度も書いています。
関数は、オブジェクトだけでなく、イベント（操作）、関数、またはこれらの要素からの基本的な構成要素であるヒープです。
Ivanovが蒸気機関車の生産機能を説明することにしたと仮定します。 これを行うには、3つの方法があります。
最初の方法
イワノフは、イベント（操作）のクラスを区別することができます。 次に、蒸気機関車を解放する機能は、イベントのクラス「蒸気機関車の解放」として表すことができます。 この場合の関数は、イベントクラスによってモデル化されます。 これらのイベントは、IDEF0表記のダイアグラム上で、正方形を出る矢印として見ることができます。
第二の方法
イワノフは、機能のクラス「蒸気列車生産」を区別できます。 最初のケースとの違いは、サブ機能に蒸気機関車の問題が多いことです（いくつが不明か）。 この場合の関数は、関数のクラスによってモデル化されます。 この種のモデリングをサポートするためのツールはまだありませんが、これはモーターシャフトの回転などの連続的な機能をシミュレートする方法です。
第三の方法
イワノフは、一連のイベント（運用）を強調することができます。スペアパーツの購入、蒸気機関車の生産、蒸気機関車の出荷です。 この場合の関数は、基本構造のクラスとして記述されます-スクリプト。 この機能の記述方法は、IDEF0表記でモデル化された機能をIDEF3、EPC、またはBPMN表記でモデル化された典型的なシナリオに「分解」する形で企業の活動をモデル化するソフトウェア製品に実装されます。
3つのモデリング方法はすべて、イベント、関数、イベントチェーンの4次元オブジェクトのヒープ形式での表現に対応しています。
機能モデリング標準
さて、関数とは何か、どのようにモデル化されているかを説明した後、質問に答えることができます。IDEF0表記の関数とIDEF3、EPCまたはBPMN表記の「分解」の関係は何ですか。 この関係は、エンタープライズモデリング製品であるAllFusion ERwin Data ModelerおよびBusiness studioに実装されています。 この関係はこれです：IDEF0表記のフローに対応する操作のヒープとして機能としてモデル化された4-Dボリュームは、IDEF3、EPC、またはBPMN表記で説明されている同じタイプのシナリオのヒープの形式の機能として表されます。
テキストを理解するのが難しい
プログラミングから遠く離れた人々に私のテキストを読ませるとき、彼らはそれを非常に簡単に理解し、しばしば疑問に思います。 プログラマがこのテキストを読むとき、彼らは何も理解していません。 私の記事を理解する上で障害となる可能性のある困難を策定しました。
- オブジェクトの特性と構造の特性が分離されており、1つのボトルに混合されていない場合、思考の規律を学ぶことは困難です。
- オブジェクトのような機能が4-D空間の異なる考え方であり、オブジェクトのような機能が感じられることを理解することは困難です。
- フローモデリングが正しくない理由を理解することは困難です。 ストリームからイベントクラスを構築できることを理解する必要がありますが、その逆も同様です。イベントクラスからストリームを構築できるとは限りません。
- 企業が機能していることを示唆する思考のステレオタイプを克服する必要があります。 このモデルは、4-Dボリュームには2つの視点があることを示しています。 一方では、これはオブジェクトであり、他方では、関数です。
- OOPの観点ではなく、主題領域の観点で考えることに慣れることは困難です。 サブジェクト領域には操作と操作の種類があり、OOPには操作と操作のインスタンスがあります。 私が手術と言うとき、私は昨日8時00分に起こったものを意味します。 操作の種類について言う必要がある場合、私はそう言う-操作の種類。 OOPでは、すべてが混乱しています。 そこでは、オペレーションについて言う必要があるとき、彼らは言う：オペレーションのインスタンス、そしてタイプについて言う必要があるとき、彼らは言う-オペレーション。
次の記事では、イベントモデリングについて説明します。 このトピックは、誰かにとっても、明らかな誰かにとっても難しいように思えるかもしれません。