システムと設計の概念。 情報システムの設計における彼らの位置

前の記事「 構造の分類：構造の分類に関する例と誤解 」のコメントを読んだ後、用語の構成に関してどれだけ異なるアイデアがあるのか​​を理解しました。 記事を書いたとき、この用語は非常に単純に解釈されているように思えました。 しかし、コメントを読んだ後、私は彼について個別に話す価値があることに気付きました。

建設業

Efremovaの説明辞書では、2つの異なる概念を定義しています。これらは同じ構成用語で示されています。

1. 構造、メカニズムの各部分の構成と相対位置。
2. そのようなデバイスの構造またはメカニズム。

それらを正式な言語に翻訳してみましょう。



構成は多数であるため、最初の概念は次のように翻訳されます。構造は相互接続によって接続された多数のオブジェクトです。 さらに、定義から判断すると、オブジェクトは人工で無生物でなければなりません。 つまり、地球がエイリアンによって作られたと仮定しない限り、構造の形で地球を想像することは不可能です。 そのDNAが誰かによって作成されない限り、DNAを構造として想像することはできません。 つまり、構造の定義では、オブジェクトが人工であることを追加する必要があります。 たとえば、多くのオブジェクト：{fuselage、wings、tail}は人工オブジェクトで構成されているため、デザインと呼ぶことができます。 飛行機と呼ばれるデザイン。 この文脈では、飛行機はオブジェクトではなく、多数のオブジェクト{胴体、翼、尾}であることに注意してください。 この航空機のセット（k）を呼び出すことができます。



いくつのオブジェクトを構築できますか？ 定義はこの質問に答えません。 しかし、定義では接続について言及しているため、それらの最終数は1より大きいと想定できます。 合計の結果：人間が作成したオブジェクトの人工セット、オブジェクトは結合、有限セットで接続され、要素の数は複数です。



同時に、デザインに名前を付けたり、デザインを検討しているオブジェクトを明確に示すための前提条件はありません。 匿名のデザインをシミュレートできます。



「構築」という用語の2番目の概念は、次のことを意味します。構築は、オブジェクトのセットとして表現できるオブジェクトです。 たとえば、オブジェクトとしての飛行機は、胴体、翼、尾部からなる多数のオブジェクトとして表すことができるため、構造体とも呼ばれます。 このテキストでは、オブジェクトとしての航空機の指定とセットとしての航空機の指定を区別するために、次のように記述できます。プレーン（o）はオブジェクトのセット-プレーン（k）として表すことができます。



任意のオブジェクトを部分に分割できます。 分割できないオブジェクトは知りません。 つまり、オブジェクトを構築と呼ぶことができますか？ いや すべての人工オブジェクトを人工パーツに分割できるわけではないからです。 たとえば、人工物であるキャスティング（インゴット）は、人工部品に分割することはできません。 したがって、ディスクをデザインと呼ぶことはできません。



「構築」という用語を解析すると、言語の重要な特徴の1つが見つかりました。オブジェクトとその構築は同じ名前で呼び出されます。 つまり、日常生活の飛行機（o）と飛行機（k）は同じ名前で呼ばれます：plane。 オブジェクトと多くのオブジェクトが異なる概念であることは明らかです。 エフライムの辞書ではこれらの概念は異なりますが、日常生活では名前は同じであるため、人々はしばしばそれらを混同し、1つの用語で示されるこれら2つの概念を分離できません。 同じ問題は、機能、機能構造、スクリプトなどの概念であるプロセスアプローチにもありました。 1つの用語と呼ばれる-プロセス。 このため、多くのアナリストは、関数とスクリプトは同じものだと考えていました。



1つの単語で2つの概念に名前が付けられているという事実から生じる混乱は、次の質問への答えに現れます。これまたはそのオブジェクトは何ですか？ 回答は2つのタイプに分類できます。

• 答えの最初のタイプはオブジェクトを定義します。飛行機は、発電所と揚力を生み出す翼を備えた空気よりも重い航空機です。
• 2番目のタイプの答えは構造を定義します。飛行機は翼、エンジン、胴体、尾です。

最初のタイプの定義は概念（o）を定義し、2番目のタイプは概念（k）を定義します。



別の例：列車は、機関車または自動車で駆動される連結された鉄道車両の列車です。 このコンテキストでは、train（k）の定義が与えられます。 電車は乗客や物資を鉄道で輸送するための長い乗り物と言えます。 これがトレイン（o）の定義です。 興味深いことに、辞書には、これらの概念と他の概念の両方の定義があります。



日常生活では、そのような定義の違いに気づきません。 たとえば、アナリストのグループには生産ラインのレイアウトが表示されます。 同時に、誰もが完全に異なる写真を見ることができます。 一方には「生産ライン」と呼ばれるオブジェクトが表示され、もう一方には同じ名前の構造が表示されます。 オブジェクトとその構造はまったく異なる概念であるため、まったく異なるものが表示されます。 このレイアウトの共通の見解に同意するまで、異なるオブジェクトについて話します。 まあ、コンテキストがそれらを1つの視点に収束させる場合。 ただし、これは常に発生するわけではありません。 議論の主題が明らかにされる段階は、通常スキップされます。 このため、理解の誤りが生じます。 オントロジーモデルを構築する場合にも同じ問題が発生します。 たとえば、属性「航空機の構造要素の数」を使用して航空機構造の複雑さを調べる場合、この属性が割り当てられているモデル内のオブジェクトを見つける必要があります。 飛行機をさまざまな方法でパーツに分割できるため、飛行機に割り当てることはできません（o）。 したがって、この属性は多くのオブジェクトに割り当てる必要がありますが、オブジェクトには割り当てないでください。

システム

システム工学がこの用語のパラドックスにどのように対処するかを見てみましょう。 システムエンジニアリングでは、次のようなシステムを定義しています。

• 特定の整合性を形成する関係および相互関係の多くの要素。

この定義は、最初の意味での構造の定義に近いことがわかります。 つまり、システムはプロパティを持つオブジェクトのセットです。

1. ところで、多くのオブジェクトは有限ですが、2つ以上ですか？
2. オブジェクト間にリンクがあります
3. 多くの接続からオブジェクトを合成できます

システムの人造に関する論文は、プロパティのリストから削除されます。 このシステムは人工製品と呼ばれるだけでなく、私たちの参加以外にも自然界に存在します。 たとえば、生物学的システム。 したがって、システムの概念は設計の概念よりも広いです。 構造は、システムのクラスの特殊なサブクラスであり、人工システムのみで構成されていると言えます。



構造について、オブジェクトとその構造の間の関係が「オブジェクトの構造」と呼ばれた場合、オブジェクトとそのシステムの間の関係を表すために別の用語、「オブジェクトの構造」が使用されます。 たとえば、人の構造は、人と人をつなぎます。 ところで、「オブジェクト構築」という用語との類推で「オブジェクトシステム」という用語がないのはなぜだろうか。



システムは多くのオブジェクトではなくオブジェクトと呼ばれますか？ つまり、用語構築がオブジェクトに適用されるのと同じ方法で、用語システムをオブジェクトに適用することは可能ですか？ ほとんどの場合-それは可能です。 たとえば、彼らはシステムが出現したと言います。 正式には、この論文は次のように翻訳されます。構造が調査中のシステムの形式で提示されるオブジェクトのプロパティは、このシステムの要素のプロパティとは異なります。 このコンテキストでは、オブジェクトはシステムと呼ばれるため、オブジェクトはシステムとも呼ばれます。



オブジェクトは部分に分割できるため、オブジェクトはシステムと呼ぶことができます。 すべてのオブジェクトをコンストラクションと呼ぶことはできないため、これはタームシステムとタームコンストラクションを区別します。



システムエンジニアリングに関する本を読んでいるエンジニアで発生する可能性のある衝突を排除するために、用語構築の2番目の意味と同様に、用語システムの2番目の定義を辞書に導入する必要があるように思えます。

• システムはオブジェクトとも呼ばれ、その構造はシステムとして表すことができます。

システムエンジニアリングに関するテキストが、このコンテキストでどのような概念を扱っているかを明示的に示しているとよいでしょう：オブジェクト、または多くのオブジェクト。



オブザーバーによってオブジェクトが異なる構造を持つことができるという理論をシステムに拡張することは可能ですか？ はい、できます。 私たちは人間の構造の2つの異なるパラダイムをよく知っています。それは、人間の内部構造と外部構造という異なる構造を生み出します。



システムエンジニアリングでは、多くの可能なオブジェクトに制限を課す要件もあります。 それは出現についてです。 構造がシステムの形式で表されるオブジェクトには、システムの要素のプロパティとは異なるプロパティが必要です。 これにより、2つの質問が発生します。

1. 一連のオブジェクトに出現があるかどうかを誰が判断しますか？ たとえば、パイプラインのセクションがあるとします。 これらのセクションの設計は、パイプラインのより大きなセクションを形成します。 このサイトには新しいプロパティがありますか？ そうでない場合、システムエンジニアリングはパイプラインシステムのセクションの構造に名前を付けることができません。 新しいプロパティがあると言う被験者がいる場合、多くのサイトがシステムに変わります。 つまり、オブジェクトのセットが構造であるかどうかに関する決定は、サブジェクトによって行われます。 彼は誰ですか？ ところで、定義の作者によると、プロセスが目的を持つべき部分で、ビジネスプロセスの定義にも同様の問題が存在します。 同じプロセスは、それを見ている人に応じて、プロセスである場合とそうでない場合があります。
   
   
   
   
2. 2つ目の質問は、システムエンジニアリングをISO 15926規格に結合することに関するものであり、それらが結合されると、ISO 15926規格に出現しない構造をモデル化する方法の問題が生じます。 たとえば、システムエンジニアに、パイプラインの2つのセクションを1つのセクションに結合しても出現しないと言わせてください。 ただし、顧客はパイプラインセクションをこのように分割しています。 システムエンジニアリングは、出現しないオブジェクトのセットに名前を付けて、それらをISO 15926標準でモデル化する方法を説明するか、システムエンジニアリングがそのようなセットを考慮せず、ISO 15926がそれらをモデル化することを許可しないと言う必要があります。

構造の定義に戻ると、質問をすることができます：構造（o）には出現の特性があるべきですか？ そうすべきだとしましょう。 そして、構造のセット（k）はシステムのセット（c）のサブセットです。 そうでない場合、構造のセット（k）はシステムのセット（c）と交差します。

建設の概念の一般化

それでは、構築（k）とシステム（c）の概念をより広いクラスのオブジェクトとセットに一般化してみましょう。 私の記事では、これはまさに私がやりたかったことです。 どうやら、現在のエントリがなければ、これは明確ではありませんでした。 一般化された構造の概念（k）を導入しました。これは、一般に受け入れられている構造の概​​念とは次の点で異なります。

1. 一般化された構造は、結合によって相互接続されたオブジェクトのセットを示しますが、このセットで合成されたオブジェクトを意味するものではありません。 これにより、用語の構成後に接頭辞（k）を指定できなくなります。
2. 一般化された構造には、任意の数のオブジェクトで構成される多くの要素が含まれる場合があります。 これは、空のセット、1つのオブジェクトで構成されるセット、カウント可能な数のオブジェクトで構成されるセット、オブジェクトの連続体などがあることを意味します。
3. 複数は、複数のオブジェクトで構成されます。
4. オブジェクトはどんな性質のものでもかまいません。
5. 出現およびその他の可能な基準は、一般化された構造の前提条件ではありません。

前回の記事で、概念名から一般化された単語を削除して、より簡潔にしました。



次のクラスの階層が判明しました：一般化された構造は、システムと構造がサブセットである最も広いセットです。



一般的な構造の導入は、さまざまな構造を記述するために作成するすべての構造を均一に表示し、これらの構造を単純化するときに生じる制限を記述するために必要でした。



たとえば、ほとんどの場合、構造モデリングは部分全体の関係を使用して行われます。 同時に、構造に関する情報（たとえば、構造要素の平均質量）を、構造をモデル化しているオブジェクトのモデルに送信します。 このモデリング方法の制限は、異なるパラダイムの設計であっても、同じパラダイムの設計であってもバージョンが異なる、1つのオブジェクトの複数の異なる設計を作成できないことです。



かつて、私は単一の宇宙船の設計のさまざまなバージョンのモデリングを任されました。 バージョンは同時に存在し、設計ソリューションのさまざまなバージョンをモデル化しました。 さらに、設計上の決定が時間とともに進化したため、バージョン自体も時間とともに変化しました。 構築の概念を導入することなく、このような問題を解決することはできましたが、非常に奇妙に見えました。 同様の問題は、作業計画をモデル化するときに解決されました。同時に複数のバージョンがありました：楽観的、悲観的、現実的です。 さらに、作業計画は、別の作業計画の一部でした。 構造をモデル化するオブジェクトをモデルに入力する前のモデリングは、さまざまな色で「ペイント」された多くの部分全体の接続でした。 「赤」の結合はオブジェクトの1つの設計をモデル化し、「緑」の結合は別の設計をモデル化しました。 多くの「色」があり、異なる色を結合する問題がありました。 実際、これらの「色」は、オブジェクトを明示的に呼び出すことなく、オブジェクトの構築に関するさまざまな視点をモデル化しました。 構築プロパティが転送されるオブジェクトのプロパティについても同じことを行う必要がありました。「赤」のプロパティ値と「緑」がありました。 そのため、「デザイン」の概念を導入する前に状況から抜け出しました。 同様のケースがISO 15926でどのようにモデル化されているのでしょうか？



もう1つの実用的なケース：一方で電力線をルートに分割し、各ルートをワイヤーに分割できます。 一方、各トラックは、サポートなどの間でトラックのセクションに分割できます。







したがって、電力線はさまざまな方法で部品に分解できます。 そして、各方法は特定の実用的な問題を解決します。 この場合、アナリストはこれらの構造をISO 15926標準に基づいてどのようにモデル化する必要がありますか？



同じオブジェクトを異なる方法でパーツに分割するための興味深い手法があります。 この手法は、オブジェクトを分割するオブジェクトが異なるサブジェクト領域に属する場合に機能します。 たとえば、エンタープライズと同じオブジェクトに名前を付けることはできますが、関数には名前を付けることができます。 これらは、同じものを表すための2つの異なるパラダイムです。 次に、機能を会社ごとに別々に分けます。 原則として、新しいタイプのオブジェクトを追加できる場合、さまざまなパラダイムのオブジェクトのモデリングに関連する問題の一部は、この方法で閉じられます。



部分全体の関係を使用した構造モデリングは、モデルのボリュームを大幅に削減し、モデルを操作するためのアルゴリズムを簡素化するため、非常に一般的です。 したがって、多くの場合、アナリストはこのモデリング方法を使用します。 ただし、この方法では、同時に存在するバージョンの構造の数に制限が課せられるため、たとえ誰かがこのモデルを逆効果にしたとしても、企業のすべての支店が1つの構造モデルで作業する必要があります。 さらに、オブジェクトの設計について話している場合、企業のさまざまな部門がまだ何らかの形で同意する可能性がありますが、機能構造をモデリングすると、そのような合意は不可能になります。 したがって、ISO 15926標準に戻ると、何が起こっているのか、何が起こっているのかについて2つの観点のみをシミュレートするために、それが先鋭化されたと考えるのは怖いです。 そのために、物理オブジェクトと機能オブジェクトの2種類のオブジェクトがあります。 さらに、2つの視点をモデル化するたびに、設計者は物理的と呼ばれるものと機能的オブジェクトと呼ばれるものの間で難しい選択をする必要があります。 1つと他の構造の両方が同時に機能する、または同時に物理オブジェクトになることがあるためです。 たとえば、サポート間の送電線のセクションは、物理的または機能的なオブジェクトですか？ 物理的であると言えますが、お客様がこのセクションの機能がエネルギーを遠くに伝えることであると言う場合、サポート間の電力線のセクションは機能的なオブジェクトになり、1つの電力線の2つの異なる構造をシミュレートすることはできません。 または、より明白な例：水素分子は、一方では原子（一方のシステム）で構成され、他方では核と電子（もう一方のシステム）で構成されています。 これらのシステムの性質が同じ-物理的であることは明らかです。 ISO 15926は、これら2つの異なる物理構造をどのようにモデル化しますか？



OOPプログラミングの問題は同じです：OOPの設計は、オブジェクトの集約、実際には部分全体の関係を使用してモデル化されます.OOPのオブジェクトが異なる構造の形で表現されることは想像できません。 なぜなら、OOPは構造モデリングに対しても強化されますが、それは1つの観点からのみです。 OOPでは、同じオブジェクトの2つの異なる構造でさえ構築することは不可能です。 OOPでは、送電線がルートで構成され、同時にサポート間の送電線のセクションで構成されているという事実をシミュレートする方法を教えてください。

思考の過程における建設の場所

私たちの思考における建築の場所、そしてそのためのモデリングについてのいくつかの言葉。 理解を達成するには、合成と分析の2つの方法があります。 分析を行う場合、一般化された構造の形でオブジェクトを想像しますが、逆に、合成の場合、オブジェクトの形で一般化された構造を表します。 分析を行い、オブジェクトがどのように構造化されているかを理解し、合成を行い、モデルを一般化することでモデルを単純化しようとします。 チェーンが判明します。...オブジェクト-その構造-オブジェクト（この構造の要素）-オブジェクトの構造-オブジェクト（この構造の要素）-オブジェクトの構造...さらに、このクラスの構造を意味するため、「一般化」を繰り返しません。 オブジェクトと構造の両方でモデリングを開始できます。 オブジェクトの階層を上下に移動して、分析または合成を実行できます。 別の方法では、これはオブジェクトに近づいている、またはオブジェクトから遠ざかっていると表現できます。 近づいて、分析を行い、記述をより詳細にし、離れて移動します-合成、または一般化。 かなりおかしいですが、現代のモデリング標準では、分解については多く読みましたが、合成についてはほとんど読みません。 作曲に特化した何かがある場合、それは解釈がかなり難しい曖昧な言葉で書かれています。 たとえば、Shekhartの方法論に従って操作に関する統計を収集する場合、オブジェクト（関数）のパラメーターを取得しますが、オブジェクト自体には名前を付けません。 プロセスをモデル化し、操作を分解する場合、何らかの理由で、逆の操作（操作内のプロセスの構成）を実行できません。 または、何らかの理由でサブジェクト領域を記述するプロセスは、「分析」と呼ばれます。 しかし、なぜ「合成」ではありませんか？ 私の意見では、アナリストは1つのプロセスともう1つのプロセス、つまり合成と分析の両方に従事しています。 統計レポートの作成、合成、オブジェクトのパーツへの分類、分析に取り組んでいます。



しかし、標準で十分に説明されていると思われる分析でも、実装の問題が発生します。

1. 多くの場合、モデル化されたオブジェクト（タイプではなくオブジェクト）を分割できるオブジェクトのタイプは、標準のコード、データ構造で厳密に定義されます。 たとえば、規格では、電力線はルートに分割されていると書かれています。 しかし、他の実用的なタスク（たとえば、電力線にサービスを提供するチーム）の場合、この部門では十分ではありません。 それらのために、いくつかの問題を解決するために、電力線はルートに分割され、他の問題を解決するために-サポート間の電力線のセクションで必要です。 規格がこれを許可していない場合、いくつかの実際的な問題を解決するには、松葉杖を使用する必要があります。
   
   
   
   
2. 2番目の複雑さはより微妙で明白ではありません-これが分割の制限です。 ほとんどの場合、アトミックオブジェクトがいくつかあり、それに基づいて複雑なオブジェクトのアセンブリが行われます。 同時に、アトミックオブジェクトをパーツに分割することは不可能です。コードまたはデータモデルではこれが許可されていないためです。 テレコムのテクニカルアカウンティングを設計するときに初めてこの問題に出会いました。 ツイストペアは不可分なエンティティとしてコードに縫い付けられ、構造内の有限リーフレットとして検索するためのアルゴリズムがコードに記述されました。 乗数をシミュレートする必要があったとき（これは異なるペアから2本のワイヤが取られるときです）、ペア検索アルゴリズムには大きな困難がありました。 実際、ツイストペアは構造の最後のリーフではなくなり、その検索のアルゴリズムが変更されました。 彼らが契約をモデル化したときに私がこれに出会ったのは2回目です。 契約は、取引先間で達成された契約のモデルです。 契約は分割不可能なエンティティではないことが判明しました。 契約が契約で構成できるように、契約は契約で構成できます。 コードはアトミックエンティティとして「契約」タイプのエンティティに関連付けられていたため、契約を部分に分割する必要があるため、ほとんどのコードが書き直されました。 そのようなケースの数は無数にあり、誰もがプロジェクトで同様の例をたくさん見つけます。

自由に思考を開始し、標準、ツール、およびフレームワークによって課される制限から逃れるために、私たちが思考で構造を使用する理由について考えることをお勧めしますか？ 私が言ったように、分析と統合は、主題分野のより一般的な、またはより一般的な説明として想像することができます。 構造は、主題領域のより詳細な、またはより一般的な表現の方向に移動できるようにするような思考の道具であると想定することができます。 このような角度から構築物を見ると、構築物は、理解を達成するために使用する合成と分析のサイクル（解釈サイクル）のモデリングの手段であることがわかります。 オブジェクトの詳細を明確にするたびに、実際にその構造を構築していますが、そうであれば、構造の概念を一般化し、1つのオブジェクトで構成される一般構造を想像できます。 たとえば、都市は次の座標を持つオブジェクトであると言えます：（...; ...）。 この情報を詳しく説明し、都市がピークのある正方形であると言って、ピークの座標をリストできます。 さらに、都市は同じ座標を持つ正方形の1つのエリアで構成されていると言えます。 新しい建設パラダイムでは、最初の都市は2番目の都市で構成され、2番目の都市は地区で構成されます。 構造はオブジェクトのより詳細な概念であるという考えを使用して、以前は考えもしなかった構造を見たところに到達しました。 マップをモデリングするとき、オブジェクトのより詳細な表現のタスクはそのように解決できると思います。



この設計は、オブジェクトについて新しいことを学ぶのに役立つはずです。 たとえば、部品も平面図になる平面図を考えます。 そのような分割の可能性により、ヨルダンの尺度の概念を導入することができ、それにより、面積の概念を導入することができます。 オブジェクトを類似のオブジェクトに分割することにより、測定の概念を導入することができました。 したがって、水を水に分割することで、水についての新しいこと、つまりその量を知ることができます。 したがって、私はまた、水を水に分割することを構造と呼び、構造の定義において、それが理解のためのツールとして機能するという理論を作り上げました。

モデリング標準の制限

モデリング標準には何が欠けていますか？ まず、解決するタスクのクラスの説明。 標準は、異なるアクターが解決するタスクのフレームワークで等しく理解するモデルを作成し、これらの問題の解決策を自動化し、解決されるタスクのフレームワーク内で異なる情報システム間で情報交換を確立できるなどの点で優れています。 それらの何が問題になっていますか？ 標準が悪いのは悪いことであり、多くの場合、アプリケーションの境界線はまったく説明されていません。 したがって、標準は、あるクラスの問題の解決のために研ぎ澄まされ、別のクラスの解決に拡張しようとします。 タスクのサークルの概要が示されている場合、このサークルを超えた問題を解決しようとすると、標準が変更されるか、放棄されることになります。



現在、単一のオントロジーに基づいて単一の情報モデルを作成するタスクが一般的になりつつあります。 同時に、彼らはしばしばある種の業界標準を基礎として、すべての問題の解決策をこの標準にマッピングしようとします（つまり、後で拡張するためにそれを基礎として使用しようとします）。 しかし、人間の活動のさまざまなブランチがさまざまな方法でオブジェクトを生成するという理由だけで、これは不可能です。 したがって、単一の情報モデルへの新しい知識の追加は、既存のオブジェクトと構造にマッピングする必要がある新しい構造と新しいオブジェクトの作成に関連付けられます。

オブジェクト、機能、および操作の統一。

前回の記事で、オブジェクト、操作、機能が同一であり、主題によってさまざまな方法で解釈されることに繰り返し気づきました。 この論文により、さまざまな構造のパラダイムを紹介することができました。 しかし、活動のモデルとオブジェクトのモデルは、多くの人が信じているように、完全に非混和性のモデルであることが判明しました。 なぜそうでないのかを説明します。 川の流れを見ているとします。 私たちの目は、水面のスライバーと泡に沿って左右に動きます。 これは、イベントまたは操作の認識です。 このモードでの短い観察の後、意識は疲れて目が止まり、意識は何か全体を見るようになります-イベントの流れ。 これは完全に異なるタイプの認識であり、川の流れまたは機能としての認識に対応します。 さらに、意識は日々観察を続け、遅かれ早かれ、ストリームを見るのをやめ、オブジェクトを見るようになります。 川は流動性のない物体になります。 そうでなければ、あたかも川から遠ざかっているように想像できます。 遅かれ早かれ、彼女はただのオブジェクトになります。 私の定義では、オブジェクトは不変であると認識しますが、実際には不変ではないため、実際に変化します。 別の例：ドラムビート、ドラムビートのリズムと作曲。 この説明は同じですが、詳細度が異なります。 あなたが注意していたなら、あなたは意識が次のスキームに従って一般化をしていることに気づいた：操作、機能、オブジェクト。 これらの3つの異なるタイプの表現は同じですが、詳細度が異なります。 オブジェクトから始めて、詳細に向かって進むことができます。 たとえば、エンタープライズのモデリングから始めて、機能をモデリングし、それをオペレーションに分解できます。 したがって、同じものが最初にオブジェクトとして、次に関数として、次に一連の操作として表示されます。 つまり、関数はオブジェクトの構築であり、操作は関数の構築です。