JP2021505983A

JP2021505983A - 新しいプログラミング言語

Info

Publication number: JP2021505983A
Application number: JP2020521323A
Authority: JP
Inventors: ▲継▼▲輝▼ ▲張▼
Original assignee: 拜椰特（上▲海▼）▲軟▼件技▲術▼有限公司
Priority date: 2018-01-26
Filing date: 2019-01-20
Publication date: 2021-02-18
Anticipated expiration: 2039-01-20
Also published as: RU2020113119A; WO2019144852A1; CA3078659A1; EP3745255A4; US20200241848A1; CN110083339A; BR112020007044A2; RU2020113119A3; AU2019211612A1; EP3745255A1; JP7250009B2

Abstract

新しいコンピュータプログラミング言語、すなわちDT言語が開示される。この言語は、このプログラミング言語の固有の特徴およびその実現方法を含む。今日、データプロセスは、様々な産業およびあらゆる分野でますます広く利用されるようになってきている。数十年前に作成されたコンピュータプログラミング言語を使用してソフトウェアを開発したり、様々な産業のデータを処理したりするのは、今や、非常に面倒で、効率が悪く、困難であるため、開発後の事後メンテナンスを行うことができない。バグが多すぎて、開発時間サイクルが長すぎ、実装率が低すぎる。本発明は、「データ化プログラミング、構造化プログラミング、構成プログラミング」を開始し、新たに発明されたデータ型およびこれらのデータ型に対する作業を本言語で行うことで、迅速かつ効率的なソフトウェア生産およびデータ処理を実現した。開発者または設計者は、この言語によって提供されるクライアントエンドプログラミングツールを使用して、新しく追加されたデータ型を介して構成およびコーディングを行うことができる。構成およびコーディングの後、この言語のクライアントエンド、ブラウザエンド、またはサーバエンドによって解釈され、実行され、また、この言語のサーバエンドによって他の言語に解釈することもできる。

Description

本発明は、新しいプログラミング言語、すなわち「DTプログラミング言語」である。そのいくつかの実施形態では、特に、プログラミング効率、ソフトウェア開発および設計効率、ならびにデータ処理効率を向上させるための新しいプログラミング言語ツールである。

現在の主流のコンピュータプログラミング言語は、数十年前に作成されたものであり、そのほとんどが現代からはるかに遅れている。たとえば、1983年のC++、1995年のJava、2000年のC#.Net、1991年のPythonである。最新のプログラミング言語であるC#.Netでさえ、17年前に発売された。当時、人々がこれらのプログラミング言語を開発したとき、コンピュータハードウェアおよびソフトウェア技術は、依然としてごく予備的な開発段階にあり、様々な産業でのデータの広範な適用は行われていない。時が経つにつれて、コンピュータソフトウェアおよびハードウェアの進歩に伴い、データプロセスは、様々な産業およびあらゆる分野でますます広く利用されるようになってきている。数十年前に作成されたコンピュータプログラミング言語を使用してソフトウェアを開発したり、様々な産業のデータを処理したりするのは、非常に面倒で、効率が悪く、困難であるため、開発後の事後メンテナンスを行うことができない。バグが多すぎて、開発時間サイクルが長すぎ、実装率が低すぎる。ソフトウェアが正常に実装されたとしても、時間が経つにつれ、要求の変化により多くのユーザがそれを放棄した。現在、現在の主流のプログラミング言語を使用してソフトウェアを開発することは、企業のニーズの変化に対応していくのが難しい。当時は、データ時代(DT時代)がまだ来ていなかったので、プログラミング言語設計の熟練者たちは、これらの問題に気付いていなかった。

今日、現在主流のすべてのコンピュータプログラミング言語の処理効率は非常に低く、多くのバグがある。本発明は、生産効率および生産性を大幅に向上させる。本発明は、新しいコンピュータプログラミング言語、すなわち、DTプログラミング言語である。従来のコンピュータプログラミング言語とは異なり、現在の新しいプログラミング言語は、すべてのデータ型を「ライブラリ」データ型および「テーブル」データ型でカプセル化し、データ分析、データマイニング、および人工知能により貢献する「データ化プログラミング」方法を開始した。「アイデンティティデータ型、関係データ型、役割データ型、シーンデータ型、スキルデータ型、データフロー型...」など、新しく発明されたデータ型が現在の新しいプログラミング言語に追加された。この新しいプログラミング言語は、新たに発明されたデータ型によって、迅速かつ効率的なソフトウェア生産およびデータ処理を実現し、この新しいプログラミング言語によってこれらのデータ型に対する作業が行われてきた。

現在、現在主流のすべてのコンピュータ言語は、スタンドアロンバージョンのプログラミング言語であり、この新しいプログラミング言語は、ネットワークバージョンのプログラミング言語である。クライアントエンドはフロントデスクにあり、それらをサポートするためにバックステージには大量のクラウドサーバがある。ユーザは、クライアントエンドにおいてコーディング、書込み、開発を行い、次いで、それをこのプログラミング言語のクラウドサーバにアップロードする。サーバは、アプリケーションコードを解釈し、データマイニング法、機械学習法を使用して、ネットワーク全体からのデータとの比較を行い、次いで、最適化する必要がある最良の方法および最悪の方法または練習を評価し、これによって、コーディングおよび開発を向上させるようにユーザを促し、または、AIを使用して、ユーザにより良いコーディングもしくは書込みまたは練習を提供する。開発者または設計者は、この新しいプログラミング言語によって提供されるクライアントエンドのプログラミングツール、および新しく追加されたデータ型を使用して、構成およびコーディングを行うことができる。次いで、それは、このプログラミング言語のクライアントエンド、ブラウザエンド、またはサーバエンドによって解釈することができ、この言語のサーバエンドによって、Java、C#.Net、JavaScript、C++、Pythonなど他のプログラミング言語に解釈することもできる。

本プログラミング言語の新しい機能は以下の通りである。

1.構成がシンプルで使いやすく、バグが少ないので、手動コーディングよりも構成がより優れている。

2.すべてのデータ型は、「ライブラリ」データ型および「テーブル」データ型の形式でカプセル化され、ここでは「ライブラリ」および「テーブル」が分類されている。

3.新しいデータ型:A.アイデンティティデータ型、B.関係データ型、C.役割データ型、D.シーンデータ型、E.スキルデータ型、F.データフロー型、G.構成データ型およびユーザデータ型、H.検証データ型、I.Grad新グリッド制御データ型、およびこの言語での他の固有のデータ型。

a)アイデンティティデータ型
アイデンティティデータ型は、すべてのシーンの情報を含む。識別情報は、定義されるときに、各シーンで果たす役割を記述する必要がある。たとえば、テーブル:データベース内の1つのテーブルである。それは、マスターとして働くとき、すなわち、独立した管理インターフェースにある間、フロントインターフェースでのグリッド制御である。また、他のインターフェースによって呼び出されたとき(ゲストとして働くとき)、ドロップダウン制御またはツリー制御などである。

アイデンティティデータ型は、スキル項目も含み、スキル項目は、システムスキル項目またはユーザスキル項目にも分けられる。システムスキル項目は、このプログラミング言語によって提供されるいくつかの一般的なスキル項目であり、システム環境は、解釈および実行、または翻訳を担当する。ユーザスキル項目は、一般的には、ビジネス指向またはサービス指向であり、実際のニーズに応じて、この新しいプログラミング言語を使用して開発者によって書き込まれ、または構成される。

アイデンティティデータ型設計の原則は、それ自体およびそのすべての包含項目にのみ関係する。

b)関係データ型
関係データ型は、以下の2つのアイデンティティ、すなわちアイデンティティA、アイデンティティBなど、様々なシーンにおける2つのアイデンティティ項目の間の関係を記述し、それらは、データベース内の1対多の関係であり、アイデンティティAは1、アイデンティティBは多を示す。UIインターフェースでは、アイデンティティAのレコードが変更されると(変更項目は、この新しいプログラミング言語を使用して開発者によって構成することができる)、アイデンティティBは、操作をリフレッシュする。

c)役割データ型
役割データ型は、2つ以上のアイデンティティ項目間のアクションまたは相乗効果を記述する。アイデンティティ項目がタスクを完了するために他のアイデンティティ項目と協力する必要があるとき、役割が必要である。役割項目は、アイデンティティ項目と関係項目の両方が明確であることに基づいて定義され、すなわち、役割を定義するとき、関係項目が最初に定義され、次いで、役割が定義される。たとえば、アイデンティティAおよびアイデンティティB:それらの間には1対多の関係があり、時として、ユーザは、インターフェース上でそれらを使用する場合がある。アイデンティティAについて、アイデンティティAがアイデンティティBの情報を検索する必要がある場合、またはアイデンティティAがアイデンティティBの情報をカウントする必要がある場合、この場合、アイデンティティAは役割を使用する必要がある。役割項目は、役割スキルを含む。

d)シーンデータ型
シーンデータ型は、ソフトウェアの各実行ポイントを定義し、たとえば、データベースは、データベースエンドを示し、クライアントは、クライアントエンドを示し、サーバは、サーバエンドを示し、ブラウザは、ブラウザエンドを示し、モバイルは、モバイルエンド(またはフォンエンドもしくはパッドエンド)を示す。メンバーの定義はシーンごとに異なる。

e)スキルデータ型
スキルデータ型は、アイデンティティスキル項目および役割スキル項目に分けられ、これらはそれぞれ、アイデンティティ項目のアクションおよびシーン項目のアクションに使用される。1つのスキルが複数のシーンにまたがる可能性があるので、スキルデータ型は、シーン情報を含む。

f)データフローデータ型
データフロー型は、データフローまたはデータの宛先およびソースを定義する。テーブルレベルのフィールド項目を定義する必要がある場合、このフィールドのデータのソースを定義する必要がある。以下のようにいくつかのソース分類がある。

Everyone:任意のユーザの入力または選択から
Design:設計ユーザの入力または選択から
Debug:デバッグのユーザの入力または選択から
Install:インストールユーザの入力または選択から
User:最終的な操作ユーザの入力または選択から
UserSelect:ユーザ選択から、選択される項目を示す
Table:テーブルまたは他のアイデンティティ項目から、他のテーブル項目を指定する
Field:テーブル内のフィールドから
Record:テーブル内の1つのレコードから
Function:関数から、関数名を示す
Interface:インターフェースから
Instance:インスタンスから
Machine:マシンまたは機器から
Other:他の項目から

g)config構成データ型
構成データ型は、以下のレベルに分けられ、誰がそれらを別々に構成するかを示す。
design:設計者または開発者
debug:テスター
install:インストーラ
user:ユーザ
everyone:全員

h)検証データ型
Integer:nullオプションが許可されるかどうか、最小値、最大値を含む整数項目
Decimal:nullオプションが許可されるかどうか、最小値、最大値、および10進数を含む整数項目
Number:nullオプションが許可されるかどうか、最小長、および最大長を含む数値項目
String:nullオプションが許可されるかどうか、最小長、最大長、許可された項目、拒否された項目、正規表現、カスタム関数項目を含む文字列項目
Datetime:nullオプションが許可されるかどうか、日付の最小値、日付の最大値、日付形式を含む日付項目
File:nullオプションが許可されるかどうか、最小値、最大値を含むファイル項目
"businessCheck":ビジネスロジックチェック項目

i)Grad新グリッド制御データ型
新gradグリッド制御データ型は、通常のグリッド表示機能に加えて、パラメータエリア、表示エリア(ビューエリア)、編集エリアを追加するという点で、従来の制御とは異なる。これら3つのエリアは、1つの制御に統合され、それらの間の相互作用は、この新しいプログラミング言語によって調整または解釈される。パラメータエリアは、データを抽出しながらフィルタリングするためのグリッド制御を提供する。表示エリアは、ユーザがグリッド制御のレコードの行をクリックすると、詳細を表示する。編集エリアは、ユーザがボタンをクリックした後に編集する必要があるコンテンツの詳細をユーザに表示する。表示エリアと編集エリアを組み合わせることができる。ここで、gradグリッドの各内部項目、パラメータエリアの各内部項目、編集エリアの各内部項目、および表示エリアの各内部項目は、設計者または最終ユーザによって構成することができる。

現在、現在主流のすべてのコンピュータ言語は数十年前に作成されたものである。そのすべてがスタンドアロンバージョンのプログラミング言語であり、その開発効率は非常に低く、現在の生産ニーズを満たすには程遠く、多くのバグを生み出している。一方、この新しいプログラミング言語は、新しい科学理論および新しい科学技術に基づいている。この新しいプログラミング言語は、「関係指向」プログラミング言語(ROP)であり、データフローベースのプログラミング言語(DPL、データ化プログラミング言語(Datalization Programming Language))であり、「ネットワーク」ベースバージョンのプログラミング言語(NVP)である。クライアントエンドはフロントデスクにあり、クライアントエンドをサポートするためにバックグランドには大量のクラウドサーバがある。ユーザは、クライアントエンドにおいてプログラミング、コーディング、開発を行い、次いで、それをこのプログラミング言語のクラウドサーバにアップロードする。サーバは、アプリケーションコードを解釈し、データマイニング、機械学習法を使用して、ネットワーク全体からのデータとの比較を行い、次いで、最適化する必要がある最良の方法および最悪の方法または練習を評価し、これによって、コーディングおよび開発を向上させるようにユーザを促す。あるいは、「AI」方法を使用して、ユーザにより良いコーディング、書込み、または練習を提供し、生産効率および生産性を直接向上させることができる。

本プログラミング言語は、システムライブラリのデータ型、システムテーブルのデータ型、データベースのデータ型(本明細書中のデータベースは、指定されていない場合、従来のSQLデータベースではなく、本プログラミング言語の固有のデータ型のコレクションを指す)、データテーブルのデータ型(本明細書中のデータテーブルは、指定されていない場合、従来のSQLデータテーブルではなく、本プログラミング言語の固有のデータ型のコレクションを指す)を以下のように実現している。

bydatabase by
{
//システムの基本的なデータ型
system sheet object [アイデンティティ項目、役割項目](
string name [アイデンティティ項目、役割項目]
, string parent [アイデンティティ項目、役割項目]
, string comx [アイデンティティ項目、役割項目]
, string summery [アイデンティティ項目、役割項目]
, string tName [アイデンティティ項目、役割項目])
{
{ …… }
{int, , , "システムの基本的なデータ型", struct}
{long, , , "システムの基本的なデータ型", struct}
{string, , , "システムの基本的なデータ型", class}
{ …… }
}
}

上記の例では、"bydatabase"はシステムライブラリのデータ型、"by"はライブラリの名前であり、システムライブラリはシステムメモリにのみ記憶され、このプログラミング言語によって解釈または翻訳される。直接参照またはインスタンス化することができるが、他のライブラリで"object"テーブルを指定する必要はない。"System"は、これがシステムテーブルのデータ型であることを示す。システムテーブルとデータテーブルとの違いは、データテーブルはデータベースにのみ記憶され、すべてのレコードは特定のものではなく、動的に追加、削除、または更新することができることであるが、システムテーブルは、このプログラミング言語の環境内に記憶され、最初の起動時に環境メモリリストにインストールされる。システムライブラリ内のシステムテーブルは、データベースに記憶することはできないが、データベース内のシステムテーブルは、データベースに記憶することができる。

A.システムライブラリのデータ型およびデータベースのデータ型の実現
c#.netなど、現在の主流のプログラミング言語では、以下の通りである。
namespace byt
{
public class Class1
{
public string name {get; set;}
}
}

名前空間を使用して"byt"という名前を付けてコードを分類し、"byt"括弧内のすべてのコンテンツ項目は、"byt"の名前の下に配置される。

別の例として、java:
package test;
public class abc {
}

パッケージを使用して"test"という名前を付けてコードを分類する。以下のすべてのコンテンツは、"test"の名前の下に配置される。

従来の言語は修飾子を1つのみ使用するか、修飾子をまったく使用しない。

本プログラミング言語では、以下に定義されているように、2つの修飾子"bydatabase"、"database"を使用して分類する。
bydatabase by
{
//すべてのシステムの基本的な型、言語レベルのコンテンツを配置する。
}
database stock
{
//ユーザによって定義または構成されたすべてのコンテンツを配置する。
}

定義の実現後、このプログラミング言語は、上記の2つの定義について異なるステップを実行する。このプログラミング言語において"bydatabase"である場合、1対1対応のリストを生成し、メモリにロードし、検証作業などを提供する。データベーステーブルの場合、"bydatabase"項目の実行ステップに加えて、対応する実際のデータベースにおけるSQL言語を介してシステムシートで修正された対応するすべてのシステムテーブルも生成する(実際のデータベースとは、MS SQLサーバ、Oracle、MySQLなど、主流のデータベースの現在の一部を指す)。

この言語におけるすべてのデータ型は、すべて"systembaseby"のシステムライブラリに配置される。

ユーザによって書かれた、またはコーディングされたプログラムデータは、データベースによって修正された"database"に均一に配置され、その名前は、ユーザによって定義することができる。

B.システムテーブルのデータ型およびデータテーブルのデータ型の実現
1.システムテーブルのデータ型の実現
database by
{
system sheet cmd[関係項目、アイデンティティ項目、役割項目](string name[関係項目、アイデンティティ項目、役割項目], string summery )
{
{config, "構成キーワード"}
{constraint, "制約項目"}
}
}

データベースによって修正された上記の"bylibrary"には、CMDテーブルがある。"system"はシステムテーブルであり、テーブルはキーワードシートによって均等に表され、CMDはテーブル名である。"[]"内の内容は、「関係項目、アイデンティティ項目、役割項目」の参照情報である。「関係項目、アイデンティティ項目、役割項目」の説明については、本明細書の「関係項目、アイデンティティ項目、役割項目」のセクションを参照されたい。"()"内の内容は、システムテーブルの詳細フィールドヘッダであり、そのうちの1つは、文字列型の名前であり、もう1つは文字列型の要約である。"{}"内の次の「{config, "構成キーワード"}」は、テーブルのレコード項目である。レコード項目は、コンパイルまたは解釈を実行する前に追加、削除、更新、または変更することはできるが、実行時間中に追加、削除、更新、または変更することはできない。これは、システムテーブル内のレコード項目は、プログラムの実行開始前にプログラマによって変更することができるだけであり、実行時間中または実行時にSQLまたは他の方法によって追加、削除、変更、または修正することはできないことを意味する。

ここで、CMDの後の"[]"内の内容は、テーブルレベルに関連する「関係項目、アイデンティティ項目、役割項目」の説明である。また、"()"内の名前の後の"[]"内の内容は、フィールドメンバーレベルに関連する「関係項目、アイデンティティ項目、役割項目」の説明であり、文字列の後に"[]"が配置されている場合は配列を表し、他のプログラミング言語のものと同じ意味である。

2.データテーブル型の実現
実行時間中のシステムテーブルとデータテーブルとの間の呼出しを実現するには、以下の2つの実現方法がある。

1.書込みまたはコーディングが初めて完了した後、ユーザは、解釈または実行ボタンをクリックし、このプログラミング言語は、追加操作のために対応するデータベースに接続し、現在のユーザによって定義されたシステムテーブルを、行ごとに現在のデータベースに挿入し、この場合、システムテーブルは、開発環境に存在するだけでなく、データベースにも存在し、したがって、データベース内のデータテーブルは、データベース内のシステムテーブルを参照することができることを実現し、次いで、システムテーブルもデータベース内にあることを実現する。次いで、システムテーブルはSQLリレーション操作を介してリストにリンクすることができ、したがって、データテーブルがシステムテーブルを呼び出すことができることを実現する。

2.ユーザが呼び出すと、このプログラミング言語は、動的に解釈を行うことができ、ユーザは、このプログラミング言語でデータテーブル内のシステムテーブルを直接参照することができる。コードが実行のためにサーバエンドまたはクライアントエンドに引き渡されると、ユーザ指定のデータ項目が最初にデータベースから取り出される。また、ユーザによって参照されたシステムテーブル内の項目について、このプログラミング言語は、その元々定義されている情報を呼び出して、行ごとにトラバースし、現在のデータテーブル項目に追加する。または、コードが他のプログラミング言語のコードに解釈されるとき、システムテーブル内の項目がデータテーブルによって呼び出され、これは、行ごとにトラバースされ、このプログラミング言語でユーザによって呼び出されたシステムテーブルの項目に追加される場合、したがって、SQLデータベースストレージがなくても、システムテーブルを呼び出すことができることを実現する。

3.キャッシュテーブル型の実現
キャッシュテーブルは、他のテーブルのデータを一時的に記憶するためにのみ使用される。キャッシュテーブル内のデータは、他のテーブルからのものである必要がある。以下のように、レコードの1つの参照項目、またはテーブルの1つの参照項目のみが記録される。
/*システム環境テーブル*/
cache sheet environment [ identity.cache ] (
string tableName [ identity.refTable ]
, string fieldName [ identity.refField ]
, object ID [ identity.refRecord ]
, string summery [ identity.summery ] )
{
{ language , name , cn , "デフォルトの簡体字中国語" }
}

"tableName"は他のテーブルのテーブル名、"fieldName"は他のテーブルのフィールド名、IDは他のテーブルのレコード項目、"summery"項目は説明項目であり、キャッシュテーブルはキャッシュによって修正され、"{ language , name , cn , "デフォルトの簡体字中国語" }"は例示的なレコード項目である。

C.オブジェクトおよび機能の実現
1.オブジェクトの実現
オブジェクトの実現は、"object"テーブル、"object.state"テーブル、および"object.attribute"テーブルの3つのテーブルを含んでいる。合わせて、これら3つのテーブルは、このプログラミング言語ですべてのシステム内に含まれるオブジェクト、およびユーザによって追加されたオブジェクトを記述する。オブジェクトが追加されるたびに、オブジェクトの名前、親オブジェクト、組合せ項目、説明項目、およびアイデンティティ項目のレコードがオブジェクトテーブルに追加される。"object.state"テーブルは、オブジェクトテーブルに対して実行可能な操作を含む。"object.attribute"テーブルは、各オブジェクトテーブル内のオブジェクトが所有する属性(プロパティ)を含む。

global system sheet object [アイデンティティ項目、役割項目]
(string name [アイデンティティ項目、役割項目],
string parent [アイデンティティ項目、役割項目],
string comx [アイデンティティ項目],
string summary [アイデンティティ項目],
string tName [アイデンティティ項目])
{
…
{ int , , , "システムの基本的なデータ型" , struct }
{ table.rows , table , include , "システムの基本的なデータ型" , class }
…
}

システムのオブジェクトは、"object"という名前のグローバルシステムテーブル(シート)に配置される。"[]"内の内容は、「アイデンティティ項目、役割項目」の参照情報である。「アイデンティティ項目および役割項目」の説明については、本明細書の「アイデンティティ項目および役割項目」のセクションを参照されたい。"()"内の内容は、システムテーブルの詳細フィールドヘッダである。第1の項目は、オブジェクトの名前を記述するために使用される、文字列型の「name項目」(名前)である。第2の項目は、オブジェクトがそこから継承されている、またはそこに含まれている親オブジェクトがどれかを記述するために使用される、文字列型の「parent項目」である。第3の項目は、オブジェクトと親オブジェクトの関係が継承されているか、または含まれているかを記述するために使用される、文字列型の「組合せ項目」である。第4の項目は、オブジェクトがどのデータ型に属するかを記述するために使用される、文字列型の「summary項目」である。第5の項目は、オブジェクトのタイプ(クラス、参照型/構造、値型/列挙、値型/インターフェースなど)を記述する、文字列型の「型」項目である。"{}"内の内容は、テーブル内のレコード項目の一部である。コンパイルまたは解釈を実行する前に、レコード項目を追加、削除、または修正することができるが、実行時間または操作時間中、追加、削除、および修正の操作は行うことができず、すなわち、システムテーブルのレコード項目は、プログラムの実行が開始される前にプログラマよって修正することしかできず、実行時または実行中にSQLまたは他の方法によって追加または変更することはできない。{int , , , "システムの基本的な(根本的な)データ型", struct}など、レコードのフィールドにいかなるコンテンツもない場合、これは、このintオブジェクトは親を有しておらず、他のオブジェクトの継承または包含がないことを意味する。
system sheet object.state [アイデンティティ項目、役割項目]
(string belong[アイデンティティ項目],
string name[アイデンティティ項目],
string summary[アイデンティティ項目])
{
…
{button.add , add , "追加"}
{button.add , complete , "完了"}
…
}

"object.state"テーブルは、オブジェクトテーブルを追加、削除、修正、クエリを行うためのオブジェクトを記述するために使用される、オブジェクトの詳細テーブルである。"[]"内の内容は、「役割項目、アイデンティティ項目」の参照情報である。「役割項目およびアイデンティティ項目」の説明については、本明細書の「役割項目およびアイデンティティ項目」のセクションを参照されたい。"()"内の内容は、テーブルの詳細フィールドヘッダである。第1の項目は、操作がどのオブジェクトに属するかを記述するために使用される、文字列型の「所属フィールド」である。第2の項目は、操作の名前(追加/削除/変更/クエリ/チェック/修正など)を記述するために使用される、文字列型の「名前フィールド」である。第3の項目は、操作のアクションを記述するために使用される、文字列型の「要約フィールド」(説明フィールド)である。"{}"内の内容は、このテーブル内のレコード項目の一部である。
system sheet object.attribute [アイデンティティ項目、役割項目]
(string belong [アイデンティティ項目],
string name [アイデンティティ項目],
object obj,
bool isStatic,
bool isPublic
)
{
…
{int, max, int, true, true}
{dataview, rowFilter, string, false, true}
…
}

"object.attribute"テーブルは、各オブジェクトが所有する属性を記述するために使用される、オブジェクトの下位テーブルである。"[]"の内容は、「役割項目、アイデンティティ項目」の参照情報である。「役割項目およびアイデンティティ項目」の説明については、本明細書の「役割項目およびアイデンティティ項目」のセクションを参照されたい。"()"内の内容は、テーブルの詳細フィールドヘッダである。第1の項目は、属性がどのオブジェクトに属するかを記述するために使用される、文字列型の「所属フィールド」である。第2の項目は、属性の名前を記述するために使用される、文字列型の「名前フィールド」である。第3の項目は、属性のタイプを記述するために使用される、オブジェクト型の「オブジェクト項目」である。第4の項目は、属性が属するオブジェクトの静的属性であるかどうかを記述するために使用される、bool型の「isStatic」フィールド(属性が静的かどうか)である。第5の項目は、属性が外部のメソッドによって呼び出すことができるかどうかを記述するために使用される、bool型の「isPublic」フィールド(パブリックかどうか)である。"{}"内の内容は、このテーブル内のレコード項目の一部である。

2.機能の実現
system sheet method(
string belong [アイデンティティ項目],
string name,
string[] paraType [アイデンティティ項目],
string[] paraName,
string returnType [アイデンティティ項目],
bool isStatic,
string body,
string summary [アイデンティティ項目]
)
{
…
{nodes, add, [node], [treeNode], int, false, {by}, {ノードをコレクションに追加し、ノードインデックスを戻します}}
{nodes, clear, [], [], void, false, {by}, {コレクション内のすべての要素を削除します}}
…
}

システムにおけるメソッドは、「メソッド」という名前のシステムテーブル(シート)に記憶される。"[]"内の内容は、「アイデンティティ項目、役割項目」の参照情報である。アイデンティティ項目および役割項目の説明については、本明細書の「アイデンティティ項目および役割項目」のセクションを参照されたい。"()"内の内容は、システムテーブルの詳細フィールドテーブルヘッダである。第1の項目は、メソッドがどのオブジェクトに属するかを記述するために使用される、文字列型の「所属項目」である。第2の項目は、メソッド自体の名前を記述するために使用される文字列型の「名前項目」である。第3の項目は、文字列[](文字列配列)型の"paraType"(パラメータ型)項目であり、メソッド内に含まれる各パラメータの型を記述するために使用され、文字列配列に順に記録される。第4の項目は、文字列[](文字列配列)型の"paraName"(パラメータ名)項目であり、メソッド内に含まれる仮パラメータの名前を記述するために使用され、文字列配列に順に記録される。第5の項目は、メソッドの戻り値型を記述するために使用される、文字列型の"returnType"項目である。第6の項目は、メソッドが静的メソッドであるかどうかを記述するために使用される、bool型の"isStatic"(メソッドが静的かどうか)項目である。第7の項目は、メソッドのメソッド本体を記述するために使用される、文字列型の"body"(メソッド本体)項目である。第8の項目は、メソッドの具体的な機能を記述するために使用される、文字列型の"summary"(説明)項目である。

以下のD、E、およびFセクションに含まれる例では、ここではテーブルAおよびテーブルBが引用される。
System sheet A [ identity.dictionaryRecord, relation.recordToField.record, role. recordActualize.record ](
string f1 [ identity.ID, relation.partner.A, role.valueDisplay.value ]
, string f2 [ identity.summery, relation.partner.B, role.valueDisplay.display ] )
{
{id1, "第1のレコード"}
{id2, "第2のレコード"}
}
System sheet B [ identity.actualize, relation.recordToField.actualize, role.recordActualize.actualize ] (
string id1 [ identity.refRecord : A.id1 ]
, string id2 [ identity.refRecord : A.id2 ] )
{…内容省略…,…内容省略…}

D.アイデンティティ項目(アイデンティティ型)の実現
1.アイデンティティ項目(アイデンティティ型)の定義
アイデンティティ項目(アイデンティティ型)は、アイデンティティテーブルで以下のように定義される。
System sheet identity [ identity.master, role.masterDetail.master, role.masterExtend.master ] (
string name [ identity.ID, role.tree.current ]
, string parent [ identity.refField : identity.name, role.tree.parent ]
, string comx [ identity.refField : reserve.family ]
, string summery [ identity.summery ] )
{
{ system, , , "by 言語システムアイデンティティ" }
//フィールド項目およびその子項目
{ field, , , "フィールド項目" }
{ ID, field, inherit, "固有のアイデンティティフィールド" }
{ summery, field, inherit, "説明フィールド" }
{ reference, field, , "参照項目" }
{ refField, reference, inherit, "参照項目フィールド(このフィールドはプライマリキーではありません) }
{ refRecord, reference, inherit, "参照テーブルの1つのレコード" }
……
// テーブル項目およびその子項目
{ table, , , "テーブル項目" }
{ master, table, inherit, "マスターテーブル" }
{ extend, table, inherit, "拡張テーブル" }
{ actualize, table, inherit, "実現化テーブル" }
{ dictionary, table, inherit, "辞書テーブル" }
{ dictionaryRecord, dictionary, inherit, "辞書レコードテーブル" }
……
//ブロック項目およびその子項目
{ block, , , "ブロック項目" }
{ masterExtend, block, inherit, "マスター拡張テーブル項目" }
{ masterDetail, block, inherit, "マスターテーブル詳細アイデンティティ" }
……
//機能項目およびその子項目
{ function, , , "機能" }
{ language, function, inherit, "言語項目" }
……
//すべての項目およびその子項目
{ everyone, , , "すべて" }
{ design, everyone, inherit, "設計者" }
{ debug, everyone, inherit, "テスター" }
{ install, everyone, inherit, "インストーラ" }
{ user, everyone, inherit, "ユーザ" }
……
}

テーブル内のアイデンティティ項目は、テーブル項目、フィールド項目、機能項目、ブロック項目(モジュール項目)、すべて項目に分けられる。これらのアイデンティティ項目はルート項目であり、子項目によって継承される。これらの子項目はまた、親としても働き、その他の子項目によって継承され、次いで、下方に拡張されて、ツリー状の構造を形成することができる。そして、ユーザは自身のニーズに応じて動的にそれを拡張することができるが、ユーザ定義のアイデンティティ項目は、システム定義のアイデンティティ項目を継承しなければならない。継承関係のために、子項目は親からすべての特徴を所有するだけでなく、親が所有していない特徴も所有する。

2.アイデンティティ項目(アイデンティティ型)の使用
アイデンティティ項目の使用方法は、次の2つの方法に分けることができる。
1.テーブル名またはフィールド名の後の"[]"内にアイデンティティ項目を追加する。
2.アイデンティティ項目構成テーブルにおいてそれらを構成する。

1.テーブル名またはフィールド名の後の"[]"内に「identity.identityItemName」の形式でアイデンティティ項目を追加する。例としてテーブルAを取り上げる。
System sheet A [ identity.dictionaryRecord ]
留意されたいのは、フィールド項目のアイデンティティを使用するとき、項目の親が「参照アイデンティティ項目」であり、参照フィールドを明示的に指定する必要がある場合、"[]"内の式は"identity.identityItemName: referenceTableName.referenceFieldName"となり、例として表Bのフィールドid1およびフィールドid2を取り上げる。
string id1 [ identity.refRecord : A.id1 ]
, string id2 [ identity.refRecord : A.id2 ]

2.アイデンティティ構成テーブルにおいてアイデンティティ項目を構成する。例としてテーブルAを取り上げる。
{A_instance, identity.dictionaryRecord, A}

第1の方法が使用された場合、システムは、テーブル名またはフィールド名、およびテーブルまたはフィールドの直後の"[]"内の内容を認識し、インスタンス名を生成し(たとえば、テーブルAによって生成されたアイデンティティインスタンスは「A_instance」という名前になる)、次いで、「インスタンス名、アイデンティティ項目、テーブル名(またはフィールド名)」の3項目が1つのレコードに結合され、これはアイデンティティ構成テーブルに挿入され、これは、第2の方法と同様である。第2の方法が使用される場合、システムがアイデンティティ構成情報を自動的に生成する必要はなく、ユーザは、アイデンティティ構成テーブルにおいてそれを直接構成することができる。

以上の2つの使用方法から、ユーザがどの方法を選択しても、システムは、インスタンス化の段階でアイデンティティ構成テーブルにアクセスすることによって、アイデンティティ項目のインスタンス化情報を取得することがわかる。比較すると、第1の方法はユーザが読むのにより適しているが、第2の方法はシステムのオーバーヘッドを節約することができる。これら2つの使用方法は、ユーザが自由に選択することができる。

3.アイデンティティ項目の構築
1).構築項目の定義
構築項目は、以下のようにアイデンティティ構築テーブルにおいて定義される。
system sheet identity.compose (
string belong [ identity.refField : identity.name ]
, string name [ identity.config ]
, string configType [ identity.reference ] /*宣言型、または型制約*/
, string cName [ identity.refField : reserve.config ]
, string roName [ identity.refField : role.detail.name ]
, string constraint [ identity.refTreeRecord : reserve.constraint ] //制約項目
, string summery [ identity.summery ] )
{
{ dictionaryRecord, idField, identity.ID, design, valueDisplay.value, must, "値項目としての役割を有するフィールドを含める必要があります" }
{ dictionaryRecord, summeryField, identity.summery, design, valueDisplay.display, must, "表示項目としての役割を有するフィールドを含める必要があります" }
}

上記のレコードの各々は、「言語項目」アイデンティティの構築項目を表し、各列の意味は以下の通りである。
列1:構築する必要があるアイデンティティ項目の名前
列2:構築項目の名前
列3:構築項目のアイデンティティ制約
列4:構成項目、すなわち、開発者によって手動で構成する必要がある
列5:構築項目の役割の制約
列6:制約項目であり、"Must"は「必須項目」、"Option"は「オプション項目」、および"condition"は「条件項目」を表す。
列7:構築項目の記述情報。

すべてのシステム定義のアイデンティティ項目またはユーザ定義のアイデンティティ項目には、対応する構築項目が明示的に与えられる必要があり、子項目の構築項目は、親項目のすべての構築項目を含む。同じ構築項目が子項目において定義されている場合、子項目は、親項目と同じものを上書きする。構築項目はアイデンティティの構築を制約する。すなわち、各アイデンティティは、アイデンティティの構築を完了するためにいくつかの特定の構築項目を有していなければならない。さらに、ユーザは、システムの基本的なクラスライブラリの所与の部分に加えて、自分で定義したアイデンティティ項目のための構築項目を定義することもできる(アイデンティティ項目については、「アイデンティティ項目の定義」のセクションの説明を参照されたい)。

2).構築項目の構成
アイデンティティ構成テーブルの各アイデンティティインスタンス項目について、対応する構築項目をアイデンティティ構造構成テーブルにおいて構成する必要があり、これらの構築項目はすべて、アイデンティティ構築テーブルの定義からのものである。例としてテーブルAを取り上げる。

テーブルアイデンティティは、アイデンティティ構造構成テーブルにおいて以下のように構成されている。
system sheet config.identity.compose (
string belong [ identity.refField:config.identity.name ]
,string composeName [ identity.refField:identity.compose.name ] //構成要素名
, string belongTo [ identity.reference ] //構成対象)
{
{ A_instance, idField, f1 }
{ A_instance, summeryField, f2 }
}

ここで、列1は、テーブルAの「アイデンティティインスタンス名」、列2は、「構築項目名」、列3は、構築項目が示す具体的な内容である。上記の例からわかるように、アイデンティティ構成テーブルおよびアイデンティティ構造構成テーブルは、アイデンティティがインスタンス化されたとき、そのインスタンス名を介して、そのアイデンティティ内に含まれるアイデンティティ構築項目を見つけることができるように、アイデンティティのインスタンス名に関連付けられている。

4.アイデンティティ項目のチェック
アイデンティティチェック項目は、アイデンティティチェックテーブルにおいて定義されている。テーブルAのアイデンティティチェック項目の定義は以下の通りである。
system sheet identity.check [ identity.extend, role.masterExtend.extend ] (
string belong [ identity.refFieldAsID : identity.name ]
, script body )
{
{ dictionaryRecord,
{
if(!compose.idField.isIdField)
{
popup.show("プライマリキー項目を含める必要があります!");
}
if(!compose.summeryField.isSummeryField)
{
popup.show("説明項目を含める必要があります!");
}
……
}
}
}

第1の列はテーブルAのアイデンティティ項目名、第2の列はアイデンティティ項目に対応するチェックスクリプトであり、{}内の詳細はスクリプトの内容である。スクリプトの書込み構文は基本的に他の言語のものと同じである。スクリプトで使用される関数は、システムの基本的なクラスライブラリによって提供される。ユーザがユーザ定義のアイデンティティ項目をチェックする必要がある場合、システムが提供する関数を使用し、構文に従って対応するチェックスクリプトを書き込む。

アイデンティティ項目のチェックは、スクリプトによって行われるアイデンティティのインスタンス化プロセスの中核部分である。アイデンティティ項目とスクリプトとの間の対応関係は、アイデンティティチェックテーブルにおいて定義される。システム定義のアイデンティティ項目は、システムによってスクリプト化される。ユーザは、ユーザによって追加されたアイデンティティ項目に対応するスクリプトを書き込む必要がある。スクリプトは、アイデンティティ構造構成テーブルのアイデンティティ構築項目(アイデンティティビルダー項目)のチェックを担当する。アイデンティティ項目は継承されているので、アイデンティティ項目をチェックするとき、まずその親に対してアイデンティティチェックを行うものとする。さらに、子と親に重複して定義された構築項目(ビルダー項目)がある場合、チェック時に子のアイデンティティ構築項目(ビルダー項目)が親における重複を上書きするものとする。

5.アイデンティティ項目のインスタンス化
インスタンス化は「構文チェック」段階でシステムによって実行され、ユーザがアイデンティティ項目とそれが含むすべての項目(構築項目、チェックスクリプト...)を構成すると、「構文チェック」は一時的に中断される。そして、ユーザが構成プロセスを完了した後、アイデンティティのインスタンス化が開始される。例としてテーブルAのアイデンティティのインスタンス化を取り上げる。

1).ソースチェック
次のように、テーブルAのアイデンティティのインスタンス名、A_instanceを介して、アイデンティティ構成テーブル内の対応するレコードを見つける。
{A_instance, identity.dictionaryRecord, A}

ソースのその第2の列、すなわち、アイデンティティ項目、identity.dictionaryRecordをチェックする。

ソースのチェックは主に、アイデンティティ項目およびその親がアイデンティティテーブルにおいて定義されているかどうかを検証することである。例としてテーブルAを取り上げる。アイデンティティ項目およびその親は以下のように定義される。
{ table, , , "テーブル項目" }
{ dictionary, table, inherit, "辞書テーブル" }
{ dictionaryRecord, dictionary ,inherit, "辞書レコードテーブル" }

次いで、ルート項目が正しいかどうかを検証する(テーブルのアイデンティティルート項目はテーブル項目であり、フィールドのアイデンティティルート項目はフィールド項目でなければならない)。上記の定義からわかるように、テーブルAのアイデンティティルート項目はテーブル、すなわち、テーブル項目であるので、チェックをパスすることができる。

2).構築項目チェック(ビルダー項目チェック)
スクリプトが実行される前に、これらの構築項目の制約をチェックする必要がある。このステップでは、まず、以下のように、アイデンティティ項目"dictionaryRecord"を介してアイデンティティ構築テーブルにおいて定義されている構築項目を見つけることができる。
{ dictionaryRecord, idField, identity.ID, design, valueDisplay.value, must, "値項目としての役割を有するフィールドを含める必要があります" }
{ dictionaryRecord, summeryField, identity.summery, design, valueDisplay.display, must, "表示項目としての役割を有するフィールドを含める必要があります" }

構築項目「idField」と「summeryField」の両方が必須項目であること、すなわち、アイデンティティをインスタンス化する必要がある場合、アイデンティティ構造構成テーブルで構成する必要があることがわかる。

以下のように、インスタンス名を介してアイデンティティ構造構成テーブル内の関連する構築項目を探す。
{A_instance, idField, f1}
{A_instance, summeryField, f2}

アイデンティティ構築テーブルにおいて定義されている必須項目が構成されていることがわかるので、スクリプトチェックの次のステップに進むことができる。

3).スクリプトチェック
アイデンティティ項目を介してアイデンティティチェックテーブル内の対応するスクリプトを見つけ、システムは、スクリプトを解釈し、実行する。スクリプトが実行された場合、アイデンティティのインスタンス化は成功である。実行中にポップアップボックスが表示された場合、アイデンティティのインスタンス化が失敗したことを意味し、この場合、ユーザは、ポップアップボックスによって促された内容に従って、アイデンティティ構造構成テーブルをチェックする必要がある。

6.アイデンティティ項目のスキル
アイデンティティ項目とスキルとの間の対応関係は、アイデンティティスキルテーブルにおいて定義されている。さらに、どのアクション下でスキルが呼び出されるか、およびどのアイデンティティ内でスキルが呼び出されるか(ここでは、アイデンティティはマスターアイデンティティまたはゲストアイデンティティを指す)もテーブルにおいて定義されており、子は親のすべてのスキルを含む。以下は、「言語項目」アイデンティティ「翻訳」スキルの定義である。
system sheet identity .skill [ identity.detail , role.masterDetail.detail ](
string belong [ identity.refField : identity.name ]
, string name [ identity.ID ]
, string[] paraType [ identity.refField : object.name ] /*型1,型2, 型N...*/
, string[] paraName /* パラメータ名1,パラメータ名2, パラメータ名N...*/
, string returnType [ identity.refField : object.name ] /*戻り値型*/
, string summery [ identity.summery ]
, script body )
{
{ language, translate, query, guest, "翻訳",
{
//スキルメインコード
}
}
}

ここで、レコードの第1の列は「アイデンティティ項目名」である。第2の列は「スキル名」である。第3の列は、スキルが対象とする対応するデータテーブルがクエリ操作を行う際に呼び出されることを示す。第4の列は、スキルの対象となる対応するデータテーブルがゲストとして働いたとき、スキルが呼び出され、対応するデータテーブルの追加、削除、変更を行うことができないことを示す。第5の列は、スキル説明項目である。そして、第6の列は、スキルメインコード項目である。プログラムの実行中、データテーブルがゲストとして働いて「言語項目」アイデンティティの「解釈」(翻訳)スキルを呼び出した場合、システムは、このレコードを見つけ、第6の列のスキルメインコードを解釈し、実行し、次いで、スキルの呼出しを完了する。

7.アイデンティティ項目のシーン。
アイデンティティ項目、シーン、およびシーンで表されるアイデンティティ項目の意味(システムによって解釈される式の形式で記述される)は、アイデンティティシーンテーブルにおいて定義される。例として「マスターテーブル」アイデンティティ項目のアイデンティティシーンの定義を取り上げる。
system sheet identity.scene (
string iName [ identity.refField : identity.name ]
, string sName [ identity.refField : scene.name ]
, script isWho
, string summery [ identity.summery ] )
{
{ master, database, datatable, "マスターテーブル" }
{ master, client, [ host:object.grad, guest:object.popupList ], "グリッド制御がホストとして働き、ポップアップウィンドウがゲストとして働くとき" }
{ master, browser, [ host:object.grad, guest:object.popupList ], "グリッド制御がホストとして働き、ポップアップウィンドウがゲストとして働くとき" }
{ master, pad, [ host:object.grad, guest:object.popupList ], "グリッド制御がホストとして働き、ポップアップウィンドウがゲストとして働くとき" }
{ master, mobile, [ host:object.grad, guest:object.popupList ], "グリッド制御がホストとして働き、ポップアップウィンドウがゲストとして働くとき" }
}

ここで、レコードの第1の列は「アイデンティティ項目名」、第2の列は「シーン名」(詳細については「シーンデータ型」の説明を参照されたい)、第3の列は、対応するシーンにおけるアイデンティティ項目の意味を示し(システムによって解釈される式の形式で記述される)、第4の列は「説明項目」である。プログラムの実行時間中、システムは、所与のアイデンティティ項目およびシーンに従って、アイデンティティ項目を所有するデータテーブルを変換する。例として上記アイデンティティ項目を取り上げると、データベース内のマスターテーブルは、メインインターフェースの形式で表示される場合はグリッド制御として、ゲストとして呼び出される場合はポップアップウィンドウとして、クライアントエンド、ブラウザエンド、タブレットエンド、およびモバイルエンドにおいて、データテーブルとして使用される。

8.アイデンティティ項目のアクション
ここでは、以下の例の「従業員情報シート」を参照する。
data sheet employees[ identity .master] (string ID, string NO, string name, string pwd ,string email, datetime entryDt, datetime dt )
{
}

1).アクション項目の定義
アイデンティティアクション項目はアイデンティティアクションテーブルにおいて定義されており、例としてアクション項目"insert"の定義を取り上げる。
system sheet identity.action [ identity.detail, role.masterDetail.detail ](
string belong [ identity.refField : identity.name ]
, string name [ identity.config : config.data.flow.reference ], string summery [ identity.summery ] )
{
{ table, insert, "追加" }
}

レコードの第1の列は「アイデンティティ項目名」、第2の列は「アクション項目名」、および第3の列は「説明項目」である。"insert"アクション項目はテーブル項目のアイデンティティに属していることがわかるので、テーブル項目のアイデンティティを継承するすべての子はアクション項目を使用することができる。

2).アクション項目の使用
例として上記のアクション項目を取り上げると、その使用は以下の通りである。
identity.table.insert.insertFlow

ここで、"insertFlow"の前の部分はアクション項目を指定するために使用され、"insertFlow"はアクション項目のデータフロー操作を完了させるために使用される(データフローデータ型の実現を参照されたい)。

E.関係項目(関係型)の実現
1.関係項目の定義
関係項目は、「テーブル関係項目」および「フィールド関係項目」に分けられ、テーブル関係項目は、2つ以上のテーブルに適しており、フィールド関係項目は、1つのテーブル内の2つ以上のフィールドに適している。関係項目は、どのメンバーが関係に含まれるか、関係詳細テーブルにおいて定義された、各メンバーの制約を含む関係テーブルにおいて定義される。

以下は、関係テーブルにおける関係項目の定義である。
system sheet relation [ identity.master, role.masterDetailSlavery.master ] (
string name [ identity.ID, role.valueDisplay.value ]
, string summery [ identity.summery, role.valueDisplay.display ] )
{
//テーブル関係項目
{ recordToField, "レコード実現化" }
……

//フィールド関係項目
{ partner, "パートナー" }
……
}

ここで、第1の項目は「関係名」、第2の項目は「説明項目」である。

以下は、関係テーブルに対応する関係詳細テーブルにおける定義である。
system sheet relation.detail [ identity.slavery, role.masterDetailSlavery.slavery ] (
string rName [ identity.refField : relation.name ]
, string member [ identity.slaveryID ]
, string csName [ identity.refField : identity.name ]
, string summery [ identity.summery ] )
{
//テーブル関係項目
{ recordToField, recordToField.record, csTable, "レコードテーブル" }
{ recordToField, recordToField.actualize, csTable, "実現化テーブル" }
……

//フィールド関係項目
{ partner, partner.A, csField, "フィールドA" }
{ partner, partner.B, csField, "フィールドB" }
……
}

ここで、第1の項目は「関係項目名」、第2の項目は「関係項目」のメンバー、第3の項目は各メンバーの制約(テーブル関係項目メンバーはテーブルであり、フィールド関係項目メンバーはフィールドでなければならない)、第4の項目は説明項目である。

2.関係項目の使用
関係項目の使用は、"relation.relationItemName.relationItemMember"の形式で、テーブル名またはフィールド名の後の"[]"の中に関係項目を追加することである。例として以下のテーブルAおよびテーブルBの関係項目の使用を取り上げる。
System sheet A [ relation.recordToField.record ] (
string f1 [ relation.partner.A ]
, string f2 [ relation.partner.B ] )
System sheet B [ relation.recordToField.actualize ]

3.関係項目シーン
関係項目、シーン、およびシーン内の関係項目の意味(システムによって解釈される式の形式で記述される)は、関係シーンテーブルにおいて定義される。例として関係項目「マスターテーブル、拡張テーブル」の関係シーンの定義を取り上げる。
system sheet relation.scene (
string rName [ identity.field : relation.name ]
, string rSence [ identity.refField : sence.name ]
, script exp /*関係式*/
, string summery [ identity.summery ] )
{
{ masterExtend, database, one_to_one at least one ; all: solo, "1対1、少なくとも1つ" }
{ masterExtend, client, design config click refresh, "マスター項目をクリックして関連項目をリフレッシュする" }
{ masterExtend, browser, design config click refresh, "マスター項目をクリックして関連項目をリフレッシュする" }
{ masterExtend, pad, design config click refresh, "マスター項目をクリックして関連項目をリフレッシュする" }
{ masterExtend, mobile, design config click refresh, "マスター項目をクリックして関連項目をリフレッシュする" }
}

ここで、第1の項目は「関係項目名」であり、第2の項目は関係項目に対応するシーンであり、第3の項目は対応するシーンにおける関係項目の意味(システムによって解釈される式の形式で記述される)であり、第4の項目は説明項目である。プログラムの実行時間中、システムは、所与の関係項目およびシーンに従って、複数のデータテーブルをこの関係項目に関連付ける。例として上記の関係項目を取り上げると、関係項目は、データベースにおけるマスターテーブルおよび拡張テーブルとして働き、「1対1、少なくとも1つ」の条件を満たすことができ、クライアントエンド、ブラウザエンド、タブレットエンド、およびモバイルエンドにおいて「マスター項目をクリックして関連項目をリフレッシュする」を履行することができる。

F.役割項目(役割型)の実現
1.役割項目の定義
役割詳細テーブルにおいて定義される、役割に含まれるメンバー、各メンバーのアイデンティティ、各メンバーの関係を含めて、役割項目は役割テーブルにおいて定義されており、役割項目は、アイデンティティ項目および関係項目はいずれも明確であることに基づいて、設定する必要がある(「役割データ型」の説明を参照されたい)。

以下は、役割テーブルにおける役割項目の定義である。
system sheet role [ identity.master, role.masterDetailSlavery.master ] (
string name [ identity.ID ]
, string rName [ identity.refField : relation.name ]
, string summery [ identity.summery ] )
{
{ valueDisplay, partner, "値項目、表示項目" }
{ recordActualize, recordToField, "辞書レコードテーブル、実現化テーブル" }
……
}

ここで、第1の項目は「役割名」、第2の項目は「関係名」、第3の項目は「説明項目」である。

以下は、役割テーブルに対応する役割詳細テーブルの定義である。
system sheet role.detail [ identity.slavery, role.masterDetailSlavery.slavery ] (
string roName [ identity.refField : role.name ]
, string name [ identity.slaveryID ]
, string iName [ identity.refField : identity.name ]
, string rName [ identity.refField : relation.detail.member ]
, string summery [ identity.summery ] )
{
{ recordActualize, record, dictionaryRecord, recordActualize.record, "辞書レコードテーブル" }
{ recordActualize, actualize, actualize, recordActualize.actualize , "実現化テーブル" }
{ valueDisplay, value, ID, partner.A, "値項目" }
{ valueDisplay, display, summery, partner.B, "表示項目"}
}

ここで、第1の項目は「役割項目名」、第2の項目は役割項目のメンバー、第3の項目は役割項目のメンバーのアイデンティティ制約である。たとえば、"recordActualize"役割項目の"record"メンバーのアイデンティティは、"dictionaryRecord"でなければならない。第4の項目は、役割項目メンバーの関係制約である。たとえば、"recordActualize"役割項目の"record"メンバーは、"recordToField"の"record"メンバーに対応している。そして、第5の項目は説明項目である。

2.役割項目の使用
役割項目の使用は、テーブル名またはフィールド名の後の"[]"の中に、"role.roleItemName.memberName"の形式で役割項目を追加することである。例としてテーブルAおよびテーブルBを取り上げる。
System sheet A [ role.recordActualize.record ] (
string f1 [ role.valueDisplay.value ]
, string f2 [ role.valueDisplay.display ] )
System sheet B [ role.recordActualize.actualize ]

3.役割項目のスキル
役割項目はスキル項目を含み、役割項目とスキル項目との間の対応関係は、役割スキルテーブルにおいて定義される。

以下は、すべての役割項目の一般的なスキル項目の定義である。
{AVG, "対応するテーブルの平均を求める"}
{sum, "対応するテーブルの合計を求める"}
{max, "対応するテーブルの最大値を求める"}
{min, "対応するテーブルの最小値を求める"}
{count, "対応するテーブルの数字を求める"}

ここで、第1の項目はスキル名であり、第2の項目は説明項目である。役割項目がインスタンス化されると、データシートは上記のこれらの一般的なスキルを使用することができる。

プロジェクト作成の実現
プロジェクトが生成されるたびに、新しく作成されたプロジェクトに対するユーザの設定を保存するために、対応する2つのテーブルが作成される。"project"という名前のシステムテーブルは、プロジェクトのカテゴリを保存するために使用され、"project.config"という名前のシステムテーブルは、ユーザによって作成されたプロジェクトのシステム構成を保存するために使用される。
system sheet project(
string name [アイデンティティ項目],
string summary [アイデンティティ項目]
)
{
…
{singleClient, "シングルクライアントエンドプロジェクト"},
{clientServer, "クライアントエンドサーバエンドプロジェクト"}
…
}

プロジェクトのマスターテーブルは、"project"という名前のシステムシートに記憶されている。"[]"内の内容は、「アイデンティティ項目、役割項目」の参照情報である。「アイデンティティ項目および役割項目」の説明については、本明細書の「アイデンティティ項目および役割項目」のセクションを参照されたい。"()"内の内容は、システムテーブルのヘッダである。第1の項目は、この項目がどの型に属するかを決定するために使用される、文字列型の「名前項目」である。第2の項目は、「名前項目」によって表されるプロジェクトの具体的な内容を記述するために使用される、文字列型の「要約(説明)項目」である。
system sheet project.config(
string pName [identity.refField: project.name],
string sName [identity.refField: sence.name],
string defaultDevelop [identity.refField: reserve.language],
string licence [identity.refField: reserve.config],
string summary [identity.summary]
)
{
…
{singleClient, database, sqlServer, design, "MS SQL Server"}
{clientServer, database, sqlServer}
…
}

プロジェクトの構成テーブルは、"project.config"という名前のシステムシートに記憶されている。"[]"内の内容は、「アイデンティティ項目、役割項目」の参照情報である。「アイデンティティ項目および役割項目」の説明については、本明細書の「アイデンティティ項目および役割項目」のセクションを参照されたい。"()"内の内容は、システムテーブルのヘッダである。第1の項目は、プロジェクトの名前を記述するために使用される、文字列型の"pName"(プロジェクト名)項目である。第2の項目は、プロジェクトがどのシーン(データベース、クライアント、またはサーバ)に適用されるかを記述するために使用される、文字列型の"sName"(シーン名)項目である。第3の項目は、プロジェクトがどのデフォルト言語によって開発されるかを記述するために使用される、文字列型の"defaultDevelop"(デフォルト開発言語)項目である。第4の項目は、プロジェクトがどのような制約を受けるかを記述するために使用される、文字列型のlicense(制約)項目である。第5の項目は、プロジェクトの特定の実装言語を記述するために使用される、文字列型の「summary」(説明)項目である。

G.データフローデータ型の実現
以下は、「employees」という名前のデータテーブル(一例)である。
data sheet employees[ identity .master] (
string ID
,string NO
,string name
,string pwd
,string email
,datetime entryDt
,datetime dt
){ }

以下は、構成データソーステーブル:config.data.sourceである。
system sheet config.data.source[identity.config](
string belong [identity.refRecord]
,string name [identity.name]
,string equal [identity.refField]
,string sourceDic [identity.refRecord:reserve.source]
,string sourceParameter [identity.refRecord:reserve.source]
,string fromAction [identity.refRecord:reserve.dataAction]
,string currentAction [identity.refRecord:reserve.dataAction]
,string hostGuet [identity.refRecord:reserve.hostGuest]
)
{
{employees.ID,autoNo, ,function,object.field.generation.autoNO(), ,insert,host}
{employees.NO,userInput, ,user, , ,insert,host}
{employees.name,userInput, ,user, , ,[insert,update],host}
{employees.pwd,userInput, ,user, , ,[insert,update],host}
{employees.email,userInput, ,user, , ,[insert,update],host}
{employees.dt,getDate, ,function,datetime.now().format(reserve."yyyy-MM-dd HH:mm:ss"), ,insert,host}
}

データソーステーブル"config.data.source"において、"belong"項目は、どの項目についてそれが構成されるかを表す。"name"項目はフローの名前である。また、"equal"項目は、主に仮想テーブルの項目に使用される。たとえば、フラグビットが1である場合はテーブルAからのものであり、フラグビットが2である場合はテーブルBからのものであるなどである(この項目が利用可能でない場合はnullである)。"sourceDic"項目は、データが分類辞書名からのものであることを記述し、これは、"reserve.source"からのものでなければならず、"reserve.source"は、予約詳細テーブルのソース項目である。"sourceParameter"項目は、データがパラメータ値からのものであることを記述する。パラメータが関数である場合、関数のアドレスおよび名前が示される。パラメータがフィールドである場合、その特定のテーブル名およびフィールド名が示される。パラメータがレコードの場合、そのライブラリ名、テーブル名、レコードIDが示される必要がある。"fromAction"項目は、ソースアクションを示し、これは、テーブル:"reserve.dataAction"からでなければならず(この項目が利用できない場合はnullになる)、言い換えれば、この項目は、フローのソースアクションがこの項目のあらかじめ定義された定義に準拠しているという条件の下でのみ、ソースアクションが合法であることを示す。"currentAction"項目は、前の項目と似ている。ホストがホストとして働いているとき、またはゲストがゲストとして働いているときの現在のアクションについてのみ、すなわち、マスターインターフェースまたはその他のインターフェースによって呼び出される。

データフロー型テーブル:config.data.flow:
system sheet config.data.flow [ identity.table ](
string NO[identity.ID]
, string belong [ identity.refTable ]
,string action[identity.refRecord:reserve.dataAction]
,string summery [ identity.summery ]
,string[] body[identity.refField:dataSource.name]
)
{
{ employeesInsert , employees ,insert, "employeesテーブルにおいてデータを追加する" ,
{
employees.ID:autoNo,
employees.NO:userInput,
employees.name:userInput,
employees.pwd:userInput,
employees.email:userInput,
employees.dt:getDate
}
}
{ employeesUpdate , employees ,update, "employeesテーブルにおいてデータを更新する" ,
{
employees.name:userInput,
employees.pwd:userInput,
employees.email:userInput
}
}
{ employeesDelete , employees ,delete, "employeesテーブルからデータを削除する" ,
{
//employees.ID.autoNo
}
}
}

データフローテーブル"config.data.flow"では、"NO"項目はシリアル番号、"belong"項目はソース、および"action"項目は「現在のアクション辞書項目」(制限されていない場合はnull)であり、「reserve.dataAction」からのものである必要があり、"summery"項目は説明項目、および"body"項目はフローの具体的な内容である。

データフロー参照テーブルまたは呼出しテーブル:config.data.flow.reference:
system sheet config.data.flow.reference [ identity.table ](
string belongFlow [ identity.refField:flow.NO ] //データフロー
,string belongTo [ identity.reference ] //このデータフローがそのために構成されている
,string belongFrom [ identity.reference ] //構成されるべきデータのデータソースアドレスを指定する
)
{
{employeesInsert,employees,identity.table.insert}
}

"config.data.flow.reference"テーブルの"belongFlow"は、どのデータフローかを示す"flow.NO"項目に由来し、"belongTo"項目は、このデータフローがそのために構成されていることを示し、"belongFrom"項目は、構成されるべきデータのデータソースアドレスを示す。例としてテーブル内のレコードを取り上げる。
"{employeesInsert, employees, identity.table.insert}"

H."Config"構成データ型の実現
1."config.data.guide"テーブルは、構成パラメータのガイドテーブルである。
この項目は、型のために構成されたテンプレート制約項目、または構成パラメータのソース項目であり、テーブル、ライブラリ、フィールド、またはレコード項目を構成することができる。このテーブルにおいて設定された項目は、構成の範囲を宣言するテンプレート制約項目である。テーブルの詳細は以下の通りである。
system sheet config.data.guide(
string belong [identity.refRecord:reserve.config]
,string name [identity.name]
,string range [identity.reference]
,string constraint[identity.refTreeRecord:reserve.constraint]
,string poser [identity.refTreeRecord:identity.everyone]
,string vertify [identity.vertify]
,string summery [identity.summery]
)
{
{database,name,string,must,install,{vertify.string.Variable},"サードパーティデータベース内の名前、この項目は、インストールレベル以上のユーザによって構成されます。"}
{database,IP,string,must,install,{vertify.string.IP},"IPアドレス、この項目は、インストールレベル以上のユーザによって構成されます。"}
{database,user,string,must,install,{vertify.string.Variable},"ユーザ名、この項目は、インストールレベル以上のユーザによって構成されます。"}
{database,password,string,must,install,{vertify.string.password},"パスワード、この項目は、インストールレベル以上のユーザによって構成されます。"}

//構成フィールド項目
{field,summery,string,option,design,{vertify.string.length128},"説明項目"}
{field,dbName,string,must,design,{vertify.string.Variable},"データベース内のフィールド名"}
{field,dbDataType,string,must,design,{vertify.string.Variable},"データベース内のフィールド型"}
{field,dbDefaultValue,string,option,design,{},"データベース内のフィールドデフォルト"}
{field,dbPrimaryKey,bool,must,design,{},"データベースの現在のフィールドがプライマリキーであるかどうか"}
{field,UIName,string,must,everyone,{vertify.string.length128},"ユーザインターフェースに表示される名前"}
{field,UIEditName,string,option,everyone,{vertify.string.length128},"ユーザインターフェースの編集エリアに表示される名前"}
{field,UIViewName,string,option,everyone,{vertify.string.length128},"ユーザインターフェースの表示エリアに表示される名前"}
{field,UIParameterName,string,option,everyone,{vertify.string.length128},"ユーザインターフェースのパラメータエリアに表示される名前"}
//構成テーブル項目
{table,summery,string,option,everyone,{vertify.string.length128},"説明項目"}
{table,UIName,string,option,everyone,{vertify.string.length128},"ユーザインターフェースに表示される名前"}
}

ここで、"belong"は"reserve.config"テーブル内のレコード項目からのものであり、"name"は現在のレコード名、"range"は項目範囲である。「Constraint項目」は、"reserve.constraint"の制約であり、必須であるか任意であるかを示す。"poser"は、アイデンティティシステムテーブルの"identity.everyone"項目およびその子項目に由来する構成許可項目を記述する。"verify"項目は検証項目であり、システムの"verify"型テーブルおよびその詳細型項目に由来し、"summery"は、レコードの説明項目である。

2.構成詳細項目テーブル。例としてデータテーブル「employees」のフィールド項目を取り上げると、構成テーブル"config.data"は、構成ガイド項目"config.data.guide"の実現化テーブルであり、以下の通りである。
system sheet config.data(
string name [identity.reference]
,string belongConfig [identity.refRecord:reserve.config]
,string belongGuide [identity.refField:config.data.guide ]
,string value [identity.parameter]
)
{
//フィールド
//構成例
{employees.ID,field,summery,"自動ナンバリング"}
{employees.ID,field,dbName,ID}
{employees.ID,field,dbDataType,{reserve.developer.sqlServer:int}}
{employees.ID,field,dbDefaultValue, }
{employees.ID,field,dbPrimaryKey,true}
{employees.ID,field,UIName,"ナンバリング"}
{employees.ID,field,UIEditName,"自動ナンバリング"}
{employees.ID,field,UIViewName,"自動ナンバリング"}
{employees.ID,field,UIParameterName,"自動ナンバリング"}
//フィールド
//入力日
{employees.entryDt,field,summery,"入力日"}
{employees.entryDt,field,dbName,ID}
{employees.entryDt,field,dbDataType,datetime}
{employees.entryDt,field,dbDefaultValue, {datetime.now().format(reserve."yyyy-MM-dd HH:mm:ss")}}
{employees.entryDt,field,dbPrimaryKey,true}
{employees.entryDt,field,UIName,"入力日"}
{employees.entryDt,field,UIEditName,"入力日"}
{employees.entryDt,field,UIViewName,"入力日"}
{employees.entryDt,field,UIParameterName,"入力日"}
//フィールド
//入社日
{employees.dt,field,summery,"入社日"}
{employees.dt,field,dbName,ID}
{employees.dt,field,dbDataType,datetime}
{employees.dt,field,dbDefaultValue, {reserve.developer.sqlServer:getdate()}}
{employees.dt,field,dbPrimaryKey,true}
{employees.dt,field,UIName,"入社日"}
{employees.dt,field,UIEditName,"入社日"}
{employees.dt,field,UIViewName,"入社日"}
{employees.dt,field,UIParameterName,"入社日"}

//データテーブル
//構成例
{employees,table,summery,"従業員情報フォーム"}
{employees,table,UIName,"従業員情報"}

}

ここで、"name"は構成されるべきオブジェクト、すなわちそのために構成されるオブジェクトであり、"belongConfig"は、システムによってあらかじめ設定された予約されたキーワード"reserve.config"のレコード項目からのもの、"belongGuide"項目は、"config.data.guide"からのもの、"value"は、構成されるべきコンテンツ項目である。

I.検証データ型の実現
検証データ型の実現は、3つのテーブル、すなわち、"verify"テーブル、"verify.detail"テーブル、および"verify.detail.identity"(アイデンティティ検証詳細)テーブルによって実現される。"verify"テーブルは、システムにおける異なる項目に対して実行することができるすべてのタイプの検証を記憶するために使用される。"verify.detail"テーブルは、検証の特定の方法、および必要なパラメータ/デフォルト値を保持する。"vertify.detail.identity"テーブルは、アイデンティティ項目の検証のタイプを保持する。
system sheet vertify [identity.master, role.masterDetailSlavery.master](
string name [アイデンティティ項目、役割項目],
string parent [アイデンティティ項目、役割項目],
string summary [アイデンティティ項目]
)
{
…
{int, , "整数"},
{string.IP, string, "IPアドレス"}
…
}

システムの検証項目(チェック項目)は、"verify"という名前のシステムシート(テーブル)に記憶されている。"[]"内の内容は、「アイデンティティ項目、役割項目」の参照情報である。「アイデンティティ項目および役割項目」の説明については、本明細書の「アイデンティティ項目および役割項目」のセクションを参照されたい。"()"内の内容は、システムテーブルの詳細フィールドヘッダである。第1の項目は、チェック項目が何を検出するために使用されるかを記述するために使用される、文字列型の「name項目」である。第2の項目は、文字列型の「parent(親クラス)項目」であり、親項目は、このチェックがどのようなタイプのチェックに属するかを記述するために使用される(たとえば、文字列型チェックは、長すぎるかどうか、パスワードの要件を満たしているかどうかなどを含んでいる)。第3の項目は、コメントと同様にチェックの内容を言語で記述するために使用される、文字列型の「説明項目」である。"{}"内の内容は、このテーブル内のレコード項目の一部である。レコードに"{int, , "整数"}"のような「parent」フィールドがないとき、このチェックは、タイプが正しいかどうかをチェックするだけである。
system sheet vertify.detail [アイデンティティ項目、役割項目](
string belong[アイデンティティ項目、役割項目],
string name[アイデンティティ項目],
string defaultValue [アイデンティティ項目],
string summery [アイデンティティ項目]
)
{
…
{ int, min, -2147483648 },
{ string.password, min, 6, "最小入力"}
…
}

"verify.detail"テーブルは、各検証に必要な特定の条件を記憶するために使用される「verifyテーブル」の下位テーブルである。"[]"内の内容は、「アイデンティティ項目、役割項目」の参照情報である。アイデンティティ項目および役割項目の説明については、本明細書の「アイデンティティ項目および役割項目」のセクションを参照されたい。"()"内の内容は、システムテーブルの詳細フィールドヘッダである。第1の項目は、「verifyテーブル」の名前に対応する、このチェックがどのタイプのチェックに属するかを記述するために使用される、文字列型の「belong項目」である。第2の項目は、(たとえば、"min"は最小値をチェックするため、"notNull"は項目が空かどうかをチェックするためなど)このチェックがどのような内容をチェックしているかを記述するために使用される、文字列型の「name項目」である。第3の項目は、チェックのデフォルトの結果や、チェックによって必要とされるパラメータを記憶するために使用される、文字列型の"defaultValue"(デフォルト)項目である。第4の項目は、コメントと同様にチェックの特定の内容を言語で記述するために使用される、文字列型の「summery(説明)項目」である。"{}"内の内容は、このテーブルのレコード項目の一部である。
config sheet vertify.detail.identity(
string belong [identity.refRecord: identity.field],
string name [identity.refField: vertify.detail.name],
string defaultValue,
string poser [identity.config: identity.everyone]
)
{
…
{ID, int.min, 1, everyone}
{NO, int.min, 1, everyone}
…
}

"verify.detail.identity"テーブルは、アイデンティティテーブルの構成パラメータが妥当かどうかをチェックするために特別に設計されたテーブルである。"[]"内の内容は、「アイデンティティ項目、役割項目」の参照情報である。「アイデンティティ項目および役割項目」の説明については、本明細書の「アイデンティティ項目および役割項目」のセクションを参照されたい。"()"内の内容は、システムテーブルの詳細フィールドヘッダである。第1の項目は、文字列型の"belong"項目であり、チェック項目によってアイデンティティテーブルのどの構成がチェックされるかを示す。第2の項目は、文字列型の"name"項目であり、チェック項目が具体的にどのような内容をチェックするか(空かどうか、数字が範囲外かどうかなど)を示す。第3の項目は、チェックのデフォルトの結果またはチェックに必要なパラメータを保存するために使用される、文字列型の"defaultValue"(デフォルト)項目である。第4の項目は、どのようなタイプのユーザがアイデンティティテーブル上でこのチェックを実行できるかを記述するために使用される、文字列型の"poser"(パブリッシャ)項目である。"{}"内の内容は、このテーブルのレコード項目の一部である。

J.新Gradグリッド制御データ型の実現
grad新グリッド制御データ型は、オブジェクトテーブルに記憶された制御データ型の"ctrol.grad"によって実現される。gradデータ型が作成された後、ユーザは、これを操作用のグラフィカルインターフェースとして生成することができる。グラフィカルインターフェースは、ビュー(表示)エリア、編集エリア、クエリ(検索)エリア、リスト(詳細)エリアを含み、各エリアは、システムが所有する制御を含む。
{ ctrol.grad , ctrol , inherit, "グリッド制御" , class }
{ ctrol.grad.list , ctorl.grad , include , "リストエリア" , class }
{ ctrol.grad.edit , ctrol.grad , include ,"編集エリア" , class }
{ ctrol.grad.query, grad , include , "クエリエリア", class }
{ ctrol.grad.view, ctrol.grad , include , "ビューエリア" , class }

"Ctrol.grad"は、システムが所有するデータ型である。システムデータ型の実現については、本明細書の「オブジェクトの実現」のセクションを参照されたい。その親の型は制御型であり、"Ctrol.grad"とその親との関係は「継承」であり、型はクラスである。"Ctrol.grad"は4つのコンポーネントを含む。第1のコンポーネントは"ctrol.grad.list area"であり、その親の型は"ctrol.grad"(グリッド制御型)であり、その親との関係は"including"(「包含」)であり、クラス型である。「リストエリア」は、gradインターフェース全体の中央に配置されており、データをテーブル形式で表示するためのテーブル型データテーブルを含む。第2のコンポーネントは"ctrol.grad.edit area"であり、その親は"ctrol.grad"(ネットワーク制御型)であり、その親との関係は"including"(「包含」)であり、クラス型である。「編集エリア」は、「gradインターフェース」全体の下部、および「ビューエリア」の下に配置されている。「編集エリア」は、多くのラベル(編集されるべきフィールドの名前を表示するために使用されるラベル制御)、および多くのテキストボックス(ユーザによって修正された値を入力するために使用される)を含む。ユーザが「ビューエリア」においてレコードを選択すると、ユーザは「編集エリア」においてその選択されたレコードのフィールドを修正することができる。第3のコンポーネントは"ctrol.grad.query area"(検索エリア)であり、その親は"ctrol.grad"(ネットワーク制御型)であり、その親との関係は"including"(「包含」)であり、クラス型である。「クエリエリア」は、「gradインターフェース」全体の左端にある。「クエリエリア」は、多くのラベル(編集されるべきフィールドの名前を表示するために使用されるラベル制御)、および多くのテキストボックス(ユーザがクエリしたい値を入力するために使用される)、ならびに特に日付をクエリするために使用されるラベル制御を含む。ユーザは、「クエリエリア」において検索項目を設定することができる。ユーザは、検索項目を入力した後、「表示エリア」においてレコード内の対応するフィールドを検索して、検索結果を取得することができる。第4のコンポーネントは、"ctrol.grad.view area"(表示エリア)である。ビュー(表示)詳細エリアは、多くのラベル(「表示エリア」において現在選択されているレコードの内容を、ヘッダとフィールドとを1対1対応させた形式で表示するために使用されるラベル制御)を含む。

K.グローバルアクセスの実現
「グローバルアクセス」の実現は、インデックステーブルを介して実現される。「グローバルアクセス」とは、ユーザが変数を宣言し、その変数にオブジェクト型およびアイデンティティを割り当てた後、システムは、変数のオブジェクト型およびアイデンティティの対応するテーブルを変数自体に直接バインドすることができ、したがって、変数がその型、そのアイデンティティメソッドなどの関連を直接呼び出すことができるようになることを意味する。
system sheet index(
string name[identity.ID],
string ref[identity.reference]
)
{
…
{long, object.long},
{double, object.double}
…
}

システムのグローバルインデックスは、"index"という名前のシステムシートに記憶されている。"[]"内の内容は、「アイデンティティ項目、役割項目」の参照情報である。「アイデンティティ項目および役割項目」の説明については、本明細書の「アイデンティティ項目および役割項目」のセクションを参照されたい。"()"内の内容は、システムテーブルの詳細フィールドヘッダである。第1の項目は、システムが所有する様々なタイプおよびグローバルユーザの構成レベルのアイデンティティを記憶するために使用される、文字列型の「name項目」である。第2の項目は、各名前項目に対応するオブジェクト/アイデンティティのインデックスを記憶するために使用される、文字列型の「ref(参照)項目」である。このインデックスを介して、オブジェクト/アイデンティティが記憶されているテーブルを検索し、見つけ、次いで、テーブル内のメソッドパラメータなどを参照することができる。

上記の説明は、本開示の好ましい特定の実施形態の1つにすぎず、本開示を限定するものではない。本開示の意図および原理内でなされたいかなる修正、等価な置換および改良も、本開示の保護の範囲に含まれるものとする。

本発明は、データ生産、データ製造、データフロー、データ交換、データ変換、データ変換、データ送信、データ記憶、データ管理、データマイニング、データ分析、データ操作、データプロセス、データセキュリティ、データ利用、データサービスなどに関与するすべての産業およびあらゆる分野に適用可能である。

Claims

新しいプログラミング言語であって、この言語におけるオブジェクトの作成方法は、「テーブル」データ型を使用してオブジェクトを作成し、記述することであり、
オブジェクト名、継承関係/包含関係、記述などは、システムの「オブジェクト」テーブルによって記録され、記述され、
オブジェクト属性名、クラス、特徴などを含むオブジェクト属性は、"object.attribute"テーブルによって記録され、記述され、
オブジェクトテーブルの操作および"object.attribute"テーブルの操作は、"object.state"テーブルによって記録され、記述される、
新しいプログラミング言語。
この言語における「メソッド」は、テーブルデータ型を介して記録され、記述され、前記メソッドが属する前記オブジェクト、メソッド名、メソッドパラメータ、メソッドタイプ、メソッド本体、メソッド記述などを前記システム内に記録するために、この言語におけるシステムテーブルのメソッドテーブルが使用される、請求項1に記載の新しいプログラミング言語。
アイデンティティ項目(アイデンティティ型)、関係項目(関係型)、役割項目(役割型)を含む新しいプログラミング言語。
前記アイデンティティ項目(アイデンティティ型)、および前記アイデンティティ項目(アイデンティティ型)の実現方法は、
アイデンティティ項目の定義であり、アイデンティティ項目はツリー構造の形式でアイデンティティテーブルにおいて定義され、子項目は親項目を継承することができ、ユーザは必要に応じて前記アイデンティティテーブルを動的に拡張することができるが、カスタム定義された前記アイデンティティ項目は、システム定義されたアイデンティティ項目を継承しなければならない、アイデンティティ項目の定義と、
アイデンティティ項目の使用方法であり、アイデンティティ項目の使用の方法は、1.テーブル名またはフィールド名の後の"[]"にアイデンティティ項目を追加すること、および2.アイデンティティ構築テーブルにおいてアイデンティティ項目を直接構成することとの2つがある、アイデンティティ項目の使用方法と、
アイデンティティ項目の構築であり、構築項目は、前記アイデンティティ構築テーブルにおいて定義され、前記システム定義されたアイデンティティ項目またはユーザ定義されたアイデンティティ項目のすべてが対応する構築項目で明確に定義されなければならず、前記子項目が前記親項目と同じ構築項目によって定義されている場合、前記子項目は前記親項目の同じ項目(項目)を上書きし、前記構築項目の構成は、アイデンティティ構造構成テーブルにある、アイデンティティ項目の構築と、
アイデンティティ項目チェックであり、前記アイデンティティ項目チェックは、スクリプトによって完了され、アイデンティティ項目とスクリプトとの間の対応関係がアイデンティティチェックテーブルにおいて定義され、前記システム定義されたアイデンティティ項目は、前記システム内の前記スクリプトによってチェックされ、前記ユーザによって追加された前記アイデンティティ項目は、前記ユーザによって書き込まれる必要がある対応するチェックスクリプトによってチェックされる、アイデンティティ項目チェックと、
アイデンティティ項目インスタンス化であり、アイデンティティ項目のインスタンス化のプロセスは、1)ソースチェック:アイデンティティ項目およびその親項目が前記アイデンティティテーブルにおいて定義されているかどうかを検証し、次いで、ルート項目が正しいかどうかを検証する(テーブルのアイデンティティルート項目はテーブル項目でなければならず、フィールドの前記アイデンティティルート項目はフィールド項目でなければならない)、2)構築項目チェック:前記アイデンティティ項目内に含まれる構築項目のすべての必須オプションが構成されているかどうかを検証する、3)スクリプトチェック:各構築項目がアイデンティティ制約および役割制約を満たしているかどうかを検証する、の3つのステップを含む、アイデンティティ項目インスタンス化と、
アイデンティティ項目スキルであり、前記アイデンティティ項目と前記スキルとの間の前記対応関係がアイデンティティスキルテーブルにおいて定義され、さらに、どのアクションの下で前記スキルが呼び出され、どのアイデンティティ(ここでは、前記アイデンティティは、マスターアイデンティティまたはゲストアイデンティティを指す)で前記スキルが呼び出されるかも前記テーブルにおいて定義されており、子は、親の前記スキルのすべてを含む、アイデンティティ項目スキルと、
アイデンティティ項目シーンであり、アイデンティティ項目、シーン、およびこのシーンにおけるアイデンティティ項目によって表される意味(前記システムによって解釈される式の形式で記述される)は、アイデンティティシーンテーブルにおいて定義される、アイデンティティ項目シーンと、
アイデンティティ項目の前記アクションであり、アイデンティティアクション項目は、アイデンティティアクションテーブルにおいて定義され、データフローは、前記アイデンティティアクション項目を使用することによって操作することができる、アイデンティティ項目の前記アクションと
を含む、請求項3に記載の新しいプログラミング言語。
前記関係項目(関係型)および前記関係項目(関係型)の実現方法は、
関係項目の定義および使用であり、関係項目は、関係項目テーブルにおいて定義され、どのメンバーが関係に含まれるか、および各メンバーの制約条件は、関係詳細テーブルにおいて定義される、関係項目の定義および使用と、
関係項目の使用であり、前記関係項目の使用方法は、"relation.relationItemName.memberName"である、関係項目の使用と、
関係項目シーンであり、関係項目、シーン、およびこのシーンのアイデンティティ項目によって表される意味(前記システムによって解釈される式形式で記述される)は、関係シーンテーブルにおいて定義される、関係項目シーンと
を含む、請求項3に記載の新しいプログラミング言語。
前記役割項目(役割型)、および前記役割項目(役割型)の実現方法であり、前記役割項目は、特定のアイデンティティ項目および特定の関係項目に基づいて設定する必要があり、
役割項目定義であり、役割項目は、役割項目テーブルにおいて定義され、どのメンバーが当該役割に含まれているか、ならびに各メンバーの前記アイデンティティおよび関係は、役割詳細テーブルにおいて定義される、役割項目定義と、
役割項目の使用であり、前記役割項目の使用方法は、"role.roleItemName.memberName"である、役割項目の使用と、
役割項目スキルであり、役割項目とスキルとの間の対応関係は、役割スキルテーブルにおいて定義される、役割項目スキルと
を含む、請求項3に記載の新しいプログラミング言語。
新しいプログラミング言語であって、検証データ型の実現方法であり、
検証(チェック)項目名、検証(チェック)項目親名、および検証(チェック)項目説明は、検証テーブルによって記録され、
検証(チェック)項目の所属、検証(チェック)項目名、検証(チェック)項目のデフォルト/パラメータ、および検証(チェック)項目の説明は、verify.detailテーブルに記録され、
アイデンティティチェック(検証)の所属、前記アイデンティティチェック(検証)の名前項目、前記アイデンティティチェック(検証)のデフォルト値項目、前記アイデンティティチェック(検証)のパブリッシャ項目を含む、前記アイデンティティテーブルの検証(チェック)テーブル、
を含む、新しいプログラミング言語。
型チェック(検証)に必要な前記パラメータおよび所属などを記憶し、名前フィールドを介して、それがどのような種類のチェック(検証)であるかを示し、テーブルの関連付けを容易にするために、テーブルを使用する方法をさらに含む請求項7に記載の新しいプログラミング言語。
迅速なグローバルアクセスの方法であり、この言語の前記システムにおける"index"という名前の固定テーブルに記憶される型オブジェクトは、グローバルにアクセスすることができ、型名項目、型参照項目を含む、新しいプログラミング言語。
インデックステーブルのタイプ、および実現化方法が記憶されている前記テーブルのインデックスを1つのテーブルに入れることをさらに含み、それを介して、ユーザは、いくつかのタイプのクイックグローバルアクセスを直接完了することができる、請求項9に記載の新しいプログラミング言語。
表示エリア、編集エリア、クエリエリア、リストエリア、およびグラフィックエリアを含む可視化グリッド空間を実現した"grad"という名前のデータ型を介した"grad"データ型の実現方法、新しいプログラミング言語。
前記可視化グリッド空間内の前記表示エリア、編集エリア、クエリエリア、およびリストエリアによって一緒に実現されるコラボレーションの実現方法をさらに含み、前記コラボレーションを介して、ユーザがグラフィカルインターフェースを使用することによってデータを操作することができる、請求項11に記載の新しいプログラミング言語。
言語の構造が、システムテーブルのデータ型の様々なシリーズを含む、新しいプログラミング言語。
前記システムテーブルのデータ型がシステムキーワードによって修正され、システムテーブル構造が、テーブル名、括弧"[]"内の補足指定、丸括弧"( )"内のテーブルフィールド、波括弧"{}"内のテーブルレコード項目によって順に構成される、請求項13に記載の新しいプログラミング言語。
前記括弧"[]"が前記テーブル名またはフィールド項目の後に続く場合、前記括弧"[]"内の内容は、テーブルまたはフィールドの前記アイデンティティ項目(アイデンティティ型)、関係項目(関係型)、および役割項目(役割型)である、請求項13に記載の新しいプログラミング言語。
前記システムテーブルのデータ型をデータテーブルのデータ型に変換し、実行時にデータベースに追加することができる実現方法、新しいプログラミング言語。
キャッシュテーブルが他のテーブルからのデータを記憶するための一時的ストレージとして使用される実現方法、新しいプログラミング言語。
構成の実現方法であり、config構成テーブルは、他のテーブル、ライブラリ、フィールド、またはレコード項目のために構成するように実装される、新しいプログラミング言語。
構成データ型の許可が、設計者の許可、テスターの許可、インストーラの許可、ユーザの許可、および全員の許可を含む高から低までの5つの許可レベルに分けられることをさらに含む、請求項18に記載の新しいプログラミング言語。
前記構成テーブルのネーミング方法は、元のテーブル名を前記構成テーブルに追加する前記方法を介して、ツリー構造の形式で命名されることをさらに含み、異なるタイプのテーブル、ライブラリ、フィールド、レコードエントリごとに、その対応する前記構成テーブルが異なる、請求項18に記載の新しいプログラミング言語。
構成テーブルを識別する方法をさらに含み、テーブルヘッダの"belong"項目を介して、前記構成テーブルは、このテーブルがどのテーブルによって構成されたかを識別することができる、請求項18に記載の新しいプログラミング言語。
各構成テーブルが、その対応する名前および説明フィールドを有することをさらに含み、異なるテーブルに属する構成テーブルごとに、前記構成テーブルの他のフィールドが異なることができる、請求項18に記載の新しいプログラミング言語。
「データフロー」データ型の実現方法であり、前記データフローデータ型は、データの所在、トレース、およびソースを定義する、新しいプログラミング言語。
データフローデータ型の構成方法であり、前記構成テーブルによる構成の前記方法を介して、前記データフローがデータテーブルに構成される、請求項23に記載の新しいプログラミング言語。