概念モデルを備えた情報システム。 パート1

最新の情報システムを導入することにより、大企業は意思決定を迅速化し、ビジネスに隠された埋蔵量と機会を発見し、蓄積された経験を分析し、特定されたパターンに基づいて予測を構築することを期待しています。 ただし、多くの場合、情報システムの実際の収益ははるかに低く、実装時間とコストは予想よりも高くなります。 非効率的な管理、人的要因、時代遅れのインフラストラクチャに関連するものなど、非常に多くの理由があります。



重大な欠点は、情報システム自体にあります。 この記事では、従来の3層AISではなく、4層アーキテクチャのシステムについて説明することを提案します。4層の新しい層（プレゼンテーション層）がサブジェクト領域の概念モデルを実装します。 サブジェクト領域の変更でモデルを更新するために、プログラムする必要はありません。 さらに、モデルの実現と適用された問題の両方が、すべてのサブジェクト領域に対して意味的に不変な概念エンティティに対する操作によって解決されます。



その結果、概念ドメインモデルを使用して、情報システムの計算特性、技術特性、および運用特性を改善することができます。 しかし、それについては後で。









原則として、情報システムは、クライアントレイヤー、ロジックレイヤー、データベースレイヤーを含む3レイヤーアーキテクチャ上に構築されます。 このようなシステムの主な機能は、データを処理するプログラム（データベース層）とデータを処理するプログラム（論理層）および表示データ（クライアント層）を物理的に分離することです。



私たちの会社「 INSYSTEMS 」は、LANCAD情報システムを使用します。このシステムには、クライアント層、プレゼンテーション層、ロジック層、データベース層の4つの層があります。新しい層-プレゼンテーション層-は、主題領域の概念モデルを実装します。 概念モデルは、情報システムのユーザーと開発者の理解に近い、主題領域の高レベルの説明に役立ちます。



情報モデリングに対する他のよく知られたアプローチとは異なり、関連付けは、モデル内の役割または関係を定義する名前付きの接続の種類ではなく、共通の概念と見なされます。 後者により、モデルの抽象化レベルを上げ、計算の複雑さがほとんどない少数の一般的なアルゴリズムを必要とする情報システムを開発できます。 さらに、アルゴリズム自体は、概念に関する非常に一般的な操作で定式化されているため、サブジェクト領域から独立しています。

コンセプトのコンセプトについて

通常、概念は思考の形式（タイプ）として定義されます。これは、特定の共通セットに従って、客観的または主観的な現実のエンティティを組み合わせた結果であり、全体としてそれらの特徴的な兆候です。



思考を直接操作するために、適切かつ効果的な技術的手段はまだ発明されていないため、ユーザーの「思考」が現代の情報システムでどのように処理されるかを理解します。



抽象化中に概念が形成（定義）されると考えられています。



抽象的思考は人間の精神活動の主要なプロセスの1つです。いくつかの問題の影響下で、私たちが精神的に分離し、レビュー中の主題領域のエンティティの個々のプロパティ、側面または状態を個別のオブジェクトと見なします。 この場合、4つのタイプの概念が形成されます：単一、単純、具体的、抽象的。



単一のコンセプト。 単一の概念の形成において、抽象化は、ドメイン内の一意のエンティティを精神的に区別し、それらに名前を割り当てる能力に現れます。 言い換えれば、単一の概念の形成とは、ある意味でエンティティと同一の記号でエンティティを置き換えることです。 ここでは、誰もが知っているフレージュの三角形を思い出します。この三角形は、記号、価値（本質）、意味の関係をグラフィカルに示しています。



単一のコンセプトの例には、「グリーン」、「サワー」、「ラウド」、「ソリッド」、「ブライト」、「ヘビー」、「ロング」、「ワン」、「マニー」などのコンセプトがあります。



原則として、感覚器官または基本的な抽象表現の特定の状態を修正するために、単一の概念が形成されます。



単一の概念は、いくつかの基本的なエンティティを示すために設計された意味概念とも呼ばれます。 情報システムでは、ユニットの概念は単純なデータ型のユニット値としてエンコードされます。 たとえば、「-1」、「3.5」、「Ts」、「16:31」、「2018-04-10」、「ABV」。



シンプルなコンセプト。 単純な概念の形成において、抽象化は、ある種の意識的な無知として現れます。これにより、多くのエンティティの1つの共通の機能に集中し、他のエンティティを無視できます。



単純な概念は、ある意味で類似したエンティティを組み合わせることによって形成されます。 単純な概念には、単一の概念として考えられる一意の名前が付けられ、許容される兆候の領域（エンティティに属する値）が設定され、単一の概念のセットとして考えられます。



単純な概念の例は、「色」などの概念です。これは、表現可能な整数で構成される「赤」、「緑」などの個々の概念、または「整数」の本質を組み合わせたものです。



情報システムでは、単純な概念は、値のセットを制限することにより、単純なデータ型またはそれらから派生したデータ型に対応します。 たとえば、「符号付き整数」、「記号」、「浮動小数点数」、「時刻」、「日付」、「文字列」など。



特定のコンセプト。 具体的な概念は、同じ属性セットを持つエンティティの組み合わせに基づいて形成され、特定の概念に属するエンティティと概念に属さないエンティティを区別できます。 際立った特徴は単純な概念と考えられ、特定の概念の名前は個々の概念と考えられます。



情報システムでは、特定の概念はテーブルで表され、その列は概念記号に対応し、行には概念に属するエンティティのこれらの記号の値が含まれます。



たとえば、「ボール」の特定の概念には、「色」、「直径」、「材料」などの概念記号が含まれる場合があり、表の行によって「ボール」の概念の本質が決まります：（「赤」、「10」、「ゴム」） 、（「グリーン」、「15」、「ファブリック」）など サブジェクトドメインのエンティティに、そのようなテーブルの任意の行に属する属性の値がある場合、このエンティティは「ボール」として認識されます。



プログラミング言語では、特定の概念は、単純なデータ型のフィールドを持つ構造体の配列で表され、データベースでは、列が同じ単純なメロン型のテーブルで表されます。



抽象的な概念。 抽象概念の形成では、記号の独立、分化、統合の関係の概念間の確立に基づいて、抽象のより複雑な形式が使用されます。抽象概念を含む任意の概念はすでに記号として機能します（図1）。







図 1.概念の兆候の関係：a）独立。 b）差別化; c）統合



2つの抽象化、つまり一般化と関連付けを使用して、抽象概念を形成します。 一般化は、記号の区別に現れる概念の類似性を表し、関連は記号の統合に現れる概念の構成を明らかにします。



脳の左半球が一般化の形成を担い、右が連合の形成を担っていると考えられています。



協会。 関連して、新しい概念の生成は、関連する概念の特性を組み合わせることによって発生します。 つまり、関連付けの概念には、構成要素として他のいくつかの概念が含まれます。



たとえば、「アプリケーション」という用語は、「ユーザー」（アプリケーションの作成者）、「日付」（アプリケーションの作成日）、「対象」（アプリケーションの本質の説明）などの概念で構成されます。



しかし、関連する概念の本質のすべての組み合わせが、関連の概念の真の本質を構成できるわけではありません。 このため、関連付けはテーブル形式で定義され、列は関連付けられた概念に対応し、各行は関連付けの概念の1つのエンティティの説明です。



たとえば、特定の日に特定のユーザーによって送信されたアプリケーションがない場合があります。 このため、特定の概念に関して、関連付けはテーブル形式で定義されます。列は関連付けられた概念であり、各行は関連付け概念の各エンティティを構成する関連付けられた概念の対応するエンティティです。



関連付けの特別なケースは、集約のよく知られた抽象化です。 集約中、集約された概念の概念記号は、受け入れ可能な値を取ることができると想定されます。 この場合、集約を定義するために、エンティティとその属性のリストを持つテーブルを形成する必要はありません。コンセプトと属性の任意の組み合わせが有効な集約であるためです。 集約概念の例は、「複素数」の概念です。これは、「実数」の2つの概念の集約です。 実際には、抽象的な概念の集合体は非常にまれです。



関連付けは、概念記号の関連付けを通じて特定の概念の形成の基礎となる抽象化であることがわかります。



一般化。 一般化するとき、新しい概念が元の概念の共通の特徴のすべてまたは一部を保持し、他の特徴を無視する場合、いくつかの同様の概念の本質を組み合わせることによって新しい概念が生成されます。



一般化の概念の例は、「フルーツ」の概念です。これは、「リンゴ」、「梨」、「桃」、「アプリコット」などの概念の本質を組み合わせた結果です。 同時に、すべての一般化された概念に共通する特性は固定されています。たとえば、「食用性」、「種の存在」、および解決される問題の記述に従って果物から分離された他の兆候（すべてではない可能性があります）などです。



一般化の特殊なケースは、タイピングの抽象化です。 入力するとき、すべての入力された概念は同じ特性を持っていると仮定されます。 型の概念の例は、すべてプログラミング言語の単純なデータ型です。 したがって、それらはタイプと呼ばれます。



一般化は、意味の概念を入力することにより、単純な概念の形成の基礎となる抽象化であることに注意してください。



「コンセプト」のコンセプト。 概念はすべて、すべての概念に共通する一連の機能を備えた概念であることに注意してください。



LANCAD情報システムでは、「概念」の概念を含むすべての概念に次の機能が含まれます（図2）：「_Entity」（エンティティの一意の数値識別子）、「_ Title」（エンティティの名前）、「_ Icon」（エンティティのアイコン）、 _Model "（プレゼンテーション層の追加のエンティティ属性）、" _Flags "（ロジックおよびデータ層の追加のエンティティ属性）。



エンティティごとに、一般的なものに加えて、「概念」、特定の特性が設定されます：「抽象」（概念エンティティの抽象化、次の値のいずれか：概念値、概念記号、概念関連付け、概念一般化）および「アスペクト」（概念の側面）エンティティについては後で説明します）。







図 2.「コンセプト」の概念の兆候

意味のバリエーション

説明辞書から任意の単語を選択し、その定義を明確にして拡張するために2人を招待すると、ほとんどの場合、対談者は相容れない矛盾に陥ります。 情報システムでも同じ問題が発生します。 異なるユーザーグループの同じ概念には異なる意味があり、その結果、異なる説明が必要です。



このため、属性「アスペクト」が各コンセプトに割り当てられると、コンセプトのマルチアスペクト記述がLANCAD情報システムで提供されます。 これにより、同じ名前で異なる側面の概念を定義できます。



図 図３は、概念記号「アスペクト」の表の断片を示している。







図 3.コンセプトサイン「アスペクト」の本質



たとえば、一般的な（空の）側面の「プロジェクト」の概念は、組織的な意味でプロジェクトを特徴付けます。開始日、終了日、予算、誘致されたリソースなどが指定されます。 また、「プロ」の側面では、「プロジェクト」という用語はプロジェクトを建設的な意味で特徴付けます。建設オブジェクト、建設のタイプ、設計段階、断面のリスト、図面セットのグレードなどが指定されます。 明らかに、異なる側面で定義された2つのプロジェクトの間には共通点がありますが、重大な違いもあり、互換性がない場合もあります。 たとえば、一般的な側面では、プロジェクトには常に特定の完了日があり、建設の側面では、プロジェクトは建設オブジェクトが存在する限り関連しています。

現実構造

LANCAD情報システムでは、さまざまな性質と意味の多くの概念が定義されている概念（概念スキーム、概念グラフ、オントロジー、裁量論理、セマンティックネットワーク、クラス図など）の相互接続性を記述するために使用されるよく知られた形式とは対照的別の形式が使用されます-概念構造は、2種類のマッピングを持つ概念のセットとして定義されます。その唯一の目的は、概念がどのように形成され、どのように抽象化されるかを示すことです。



概念構造は、主題領域の概念分析の結果を反映することを目的としており、一部の概念を他の概念にマッピングすることを表します。 これに使用される抽象化は、記述された主題領域に関連して蓄積された表現を精神的に分離し、別個の概念に変えるために必要かつ十分な精神的操作と見なされます。



概念構造を表示する例を図に示します。 4：概念のリストとそのエッセンスは、ツリーの形でフォームの左パネルに表示され、概念の名前、抽象化の方法、および側面はリストの形で左に表示されます。







図 4.概念構造



たとえば、「プリンシパル」の概念は「ユーザー」および「グループ」の概念の一般化であり、「ユーザー」の概念は「パスワード」、「名」、「ミドルネーム」、「姓」、「電話」などの概念の関連付けです。 （図5）。







図 5.「ユーザー」の概念の属性



同様に、「名」、「ミドルネーム」、「ラストネーム」、「電話」、「メール」などの概念は、正規表現の形式で値の範囲が制限された、対応する長さの文字列概念値として定義されます。



抽象概念の記号には他の抽象概念が含まれる場合があるため、このような概念では、「記号」という言葉の代わりに「属性」という言葉が使用されます。

アイザック・アシモフは正しいですか？

4層の情報システムは、ドメインモデルと連携し、ドメインモデルの状態と動作を適切に記述する必要があります。



アイザック・アシモフは小説「The End of Eternity」で、リアリティに対する変更の疑いをモデル化するために使用される電卓がリアリティ自体と複雑なほど複雑であるとリアリティが示唆しました（図6）。 実際のモデルは本当に複雑ですか？ それとも、単に「調理できない」のでしょうか？ これらの質問に答えてみましょう。







図 6.現実をモデル化するためのコンピューター。 出所



以前に検討されたサブジェクト領域の概念構造では、概念の名前、それらの抽象化メソッド、および概念が定義されている概念属性のリストが定義されています。 ただし、単純な概念がどのように定義されるか、概念属性のどの値のセットがこれを決定するか、具体的および抽象的な概念の本質は不明のままです。



明らかに、サブジェクト領域の完全な説明のために、各概念に属するエンティティを説明することにより概念構造を拡張する必要があります。 この拡張の結果として、対象領域の概念モデルを取得し、その上で既存の応用問題を解決します。



データベース層では、ユニットの概念（値の概念）は組み込みのデータ型で表されます。 LANCAD情報システムは38の価値概念を使用しています（図7）。







図 7.概念の意味



次に、単純な概念（概念記号）は、そのような概念に属するエンティティ値の列挙を含むテーブルの形式で実装されます。 概念属性「アスペクト」のプレゼンテーションの例は、前の図で与えられています。 3、および図4の概念構造での表示 4。



具体的な概念は、列が値の概念に対応するテーブルで表現できます。 図 図8は、「色」の特定の概念を表すテーブルのフラグメントを示しています。概念の特定の属性は、「色」の列で表されています。







図 8.「色」の具体的なコンセプト



関連付けの概念は、関連付けられた概念のエンティティを関連付けの概念の本質に接続するテーブルの形式で提示されます。特定の概念とは異なり、列は抽象的な概念に対応し、エンティティの一意の識別子（_Entityフィールドの値）を含むことができます。



概念関連付けテーブル「Concept」の例を図に示します。 9。







図 9.コンセプトアソシエーション「コンセプト」



抽象概念の一般化の提示は、共通フィールドの特定のリストを持つ一般化された概念のテーブルからレコードを収集するデータベースクエリを使用して実行されます。



概念一般化「プリンシパル」の仮想テーブルの例を図に示します。 ここで、68に等しい一意の識別子の最初の数字を持つエンティティは「グループ」という概念のエンティティであり、数字67を持つエンティティは「ユーザー」という概念のエンティティです。 このようなエンティティの一般的な属性は、概念「名前」と「パスワード」でした。







図 10.汎化の概念「プリンシパル」



したがって、データベース層では、サブジェクト領域の概念モデルは、物理テーブルおよび仮想テーブルの概念の本質のリストによって表されます。 物理テーブルはメモリに直接格納され、仮想テーブルはデータベースへのクエリの結果として動的に生成されます。



これは、ドメインモデルの複雑さはドメイン自体の複雑さと釣り合っているという結論に直接つながります。 いくつかの概念またはその本質を「隠す」と、情報システムにはそれらが存在しなくなります。 そして、何らかの方法でそれらを識別することは不可能です。



人は海の存在を推測するために一滴の水を落とすことができますか？ はい、多分。 しかし、その後、人は彼の知性を使わなければなりません。それは合理的な思考に還元できず、私たちはそれを自動化しようとしています。 そのような場合、情報システムのユーザーの知的活動の結果である新しい概念とエンティティで概念モデルを補足する以外に何も残っていません。

イリスのTempora Mutantur et nos mutamur

タイトルは有名なラテン語の格言であり、「時代は変わりつつあり、私たちは彼らと共に変化しています」と述べています。 どのような概念モデルを作成したとしても、その作成時点ではすでに古くなっています。 サブジェクト領域の変更後のモデルの更新を確実にする方法は？



明らかに、概念モデルの更新は、概念に関する3つの操作、つまり概念の本質の作成、概念の本質の変更、概念の本質の削除に還元できます。 各概念は「概念」の概念の本質であるため、これらの操作のフレームワークでは、概念自体を作成、変更、削除できます。



エンティティを作成します。 概念の本質を作成する操作は、作成されたエンティティの属性値に等しいフィールドを持つ概念のテーブルに新しい行を挿入することによって実行されます。 これを行うには、データベース層でINSERT型のSQLクエリが使用されます。



次に、ドメインの概念モデルが複雑で、新しい概念の名前を決定し、それを抽象化するためのメソッドを設定し、概念属性を一覧表示することで、概念エンティティを作成する操作が発生します。 概念のタイプに応じて、概念-記号と概念-関連のデータベースにテーブルが作成されるか、概念-一般化のビュー（英語ビュー）が作成されます。 データベース層で概念を作成するには、適切なストアドプロシージャを作成して、そのような操作後のデータベースの整合性と、概念モデルの整合性を間接的に保証する必要があります。



エンティティを削除します。 概念エンティティを削除する操作は、SQLクエリを実行して、タイプDELETEの概念テーブルから行を削除することによって実行されます。 削除された概念のエンティティは相互に参照できるため、関連付けられているエンティティを削除しない限り、すべての削除操作が可能というわけではありません。 この関係を確保するために、概念テーブルを作成するときに、このテーブルのすべての抽象フィールドに外部キーが定義されます（図11）。 その結果、密結合データベースとなり、外部キーメカニズムにより概念モデルの整合性が確保されます。



概念エンティティを削除する操作は、サブジェクト領域のモデルが大幅に変更された場合に発生し、すべての概念の説明を変更することで構成され、その定義には削除された概念が含まれます。 概念モデルの整合性を確保するために、概念の削除は対応するストアドプロシージャによって実行されます。







図 11.概念テーブルの外部キー



本質の変化。 エンティティを変更する操作は、対応する概念のテーブルの1つまたは複数の行のフィールドを変更するUPDATEタイプのSQLクエリと同等です。 テーブルに定義された外部キーは、変更操作を実行するときに概念モデルの整合性を保証します。



概念を新しい主題コンテンツで埋める必要がある場合、概念エンティティの変更が発生します。 コンセプト変更操作は、コンセプトテーブルを変更し、挿入された抽象列の外部キーを設定する、対応するストアドプロシージャによって実行されます。



ユーザーインターフェース 概念エンティティを追加および削除する操作は、アプリケーションのコンテキストメニューに表示されます（図12）。







図 12.エンティティの作成および削除操作



エンティティを変更する操作は、単純な概念の意味を直接変更するか、ドロップダウンリストから抽象概念の許容値の1つを選択することで実行されます（図13）。 この場合、抽象概念のエンティティは、名前と対応するアイコン（属性_Titleおよび_Icon）の形式でユーザーインターフェイスに表示されます。







図 13.エンティティ変更操作



そのため、記事の最初の部分では、概念的な高レベルモデルの定義を検討しました。 そして、第2部では、INSYSTEMSで主題領域の概念モデリングに基づいて完全に機能する情報システムを実装した方法を説明します。 継続する 。