システムの要件には、賃貸人と借手の従業員の労働時間を記録するための通常の要件に加えて、支払いのマークまたは輸出許可なしで商品の輸出を禁止するという点でテナントによる顧客の管理要件が含まれます。 また、主要企業とテナントの間の両方でパートタイム労働者の存在を考慮する必要があります。
構造モデルの特徴
1つのアクセスポイントを備えたテリトリーでACSの構造モデルを構築します。 アクセスポイントにはロックが装備されており、その開口部にはキーのセットがあります。 このようなシステムの最も単純なモデルには、たとえば1つの玄関ドアのあるアパートなど、特定の役割を果たす4つのエンティティが含まれます。
ただし、エンティティの最も詳細な説明があったとしても、エンティティ間の接続は存在しないため、エンティティはシステムのモデルではありません。 たとえば、ドアを説明するとき、どのアパートに属しているかを知る必要があります。 エンティティ（オブジェクト）間の関係を確立し、それらの間の相互作用の結果を記録し、属性のセットとして関係を設定します：アパートへのドアは01.01.2000（日付属性）に設置され、ドアのロックはマスターペトロフP.Pによって02.01.2000（日付属性）に設置されます （属性マスター）。
関連するオブジェクトはそれぞれ、オブジェクト間の関係を独自に「見る」ことができるため、2つの関係を考慮する必要があります。 たとえば、 Lock＃Doorsという接続は属性のセットであり、
{" ", " ", " "}
接続ドア＃城 -属性のセット
{" ", " ", " ", [" "]}
ドアへの2番目のロックのインストールは、エンティティの新しいインスタンスの出現（その役割を変更しない）だけでなく、その「次元」の変更（1次元ロックから多次元ロックへの変更）も意味します。 同様に、2番目のドアを設置すると、対応するエンティティの「寸法」が変更されます。
エンティティ（たとえば、ディメンション）を変更するときにロールを保存すると、エンティティ間の関係の保持と構造が決まります。 多次元エンティティ（オブジェクト）間の2つの関係を引き続き検討しますが、関係自体は多次元になり、 Lock＃Doors接続のコンポーネントの数はシステム内のロックの数と等しくなり、 Door＃Lock接続ではドアの数になります。
ACSの観点から最も興味深い関係は、 KeysオブジェクトとLocksオブジェクト間の関係です（識別子とブロッキングデバイスの役割）。 これらの関係において、どのロックがどのキーで開かれたのか、閉じられたのかを追跡できます。 通信キー＃ロック 、例
次のようになります。
[{" ", " (/)", " "}, {}, ..., {}]
次に、通信ロック＃キーには、キーの受信、その紛失、交換に関連する属性があります。
いずれの場合でも、属性はシステムの要素として参照されますが、その属性は同じ時間で大きく変化する可能性がある関係とは対照的に、その観察中に属性は変化しません。 システム要素の属性セットの選択は、モデリング中にシステム設計者によって完全に決定されます。
構造モデルの役割とオブジェクト
実際のACSでは、多数の新しいロールとそれらを実行するオブジェクトを考慮する必要があります。 識別子のロールOwnerを構造モデルに追加します。このロールを果たすオブジェクトはVisitorと呼ばれ、いくつかのロールのエグゼキューターも変更します。
コミュニケーションタグ＃訪問者 ：
[{ " ", " ", " ": (, , ) ", " ", " ", " ": (, )}, ...]
この関係により、以下が可能になります。
タグで訪問者を一意に識別します（関係の1つのエントリのみがタグステータス=アクティブにできます）。
従業員に、忘れられたパスポートと引き換えに、1回限りまたは1日限りの一時パスを発行します。
一時パスの有効期間を設定します。
コミュニケーション訪問者＃タグ ：
[{" ", " ", " "}, ...]
このような関係により、たとえば、アクセスカードを紛失したり、定期的に忘れてしまった従業員のペナルティポイントの発生を整理できます。
コミュニケーションリーダー＃タグ ：
[{ " ", " ", " ": ( , , , ), " "}, ...]
この接続により、リーダーでイベントログを保持できます。
コミュニケーションタグ＃重要な属性がないため、リーダーはインストールしません。
入場が許可されているステータスを取得しても、入場が行われたという意味ではありません。 遷移に関連付けられた属性を表示するために、ラベルとターンスタイルの間にリンクを追加します。
タグとリーダーの間の接続は、どのタグがどのリーダーであるか、いつ決定されるかを示し、タグのステータスも記録する必要があります。
通信タグ＃ターンスタイル ：
[{ " ", " ", "": (, ), " "}, ...]
この接続により、ラベルに応じて各訪問者がターンスタイルを通過する交差点を追跡できます。
通信ターンスタイル＃タグ ：
{ " ", [" ", "": (, , ), " "]}
この関係により、訪問者と遷移のログを保持できます。 トランジションの方向を判別できない場合（ターンスタイルが両方向のボタンで開かれる）、トランジションが完了すると、接続は未定義の方向と空のラベル名でトランジションの時間を示します。
回転式改札口とリーダー、および回転式改札口とアクセスゾーン間の接続は、デバイスの操作を説明するために使用できます。たとえば、回転式改札口の通信＃Readers ：
{" ", [" c", ["": (, , ) ," "]]}
リンクMarks＃TurnstileおよびTurnstile＃Marksで遷移の方向を決定するには、アクセスゾーンに対する訪問者（マーク）の位置を知る必要があります。 ラベルとアクセスゾーンの間の接続に対応する属性を保持しておくと便利です。そのため、対応する接続を作成します。
コミュニケーションアクセスゾーン＃タグ ：
{" ", [" ", " ", ""]}
このような関係により、訪問者の位置をいつでも決定でき、複数のアクセスゾーンがある場合に位置の変更を制御できます。 たとえば、訪問者は、回転式改札口から入っていない場合、内部に入ることができません。
リンクタグ#Access Zone ：
[{" ", " ", " ", " ", " "}]
このような関係により、テリトリーで費やされた実際の時間を考慮して、勤務時間を記録するために必要なデータを取得できます。 ただし、このデータでは十分ではありません。 第一に、雇用会社（雇用会社）に関する情報、そして第二に、勤務スケジュールに関する情報が必要です。 そのような情報を説明するには、雇用主の役割で新しいCompanyオブジェクトを追加し、それと従業員（訪問者）との関係を確立します。
コミュニケーション訪問者＃会社 ：
[{" ", " ", " ", " ", " ", " ", " ", " "}]
このような関係には、労働時間の記録に加えて、起こりうる競合状況の解決に必要なすべてのデータが含まれています。 資格情報は、実際のデータと勤務スケジュールの比較に基づいて作成されます。 スケジュールデータは、関係会社＃Visitorsに含まれています。
{" ", [" ", " ", " ", ["", " ", " ", " "]]}
このような関係により、各従業員の勤務スケジュールに関するデータを考慮に入れることができ、休業日のアクセスゾーンへのアクセスを禁止または許可することができます。 通信データはACSの外部で生成され、企業からのものでなければなりません。
次に、企業のクライアントの管理について検討します。 そのような訪問者は、企業のバイヤーまたはサプライヤー（またはその代表者）です。 それらの企業は雇用主としてではなく、サプライヤーまたはバイヤーとして行動します。 したがって、オブジェクトにはいくつかの役割があります。
したがって、訪問者と会社の間の接続数も変わります。 そして、今ではすべての訪問者が構造モデルのフレームワーク内で従業員、バイヤー、またはサプライヤの役割を果たすことができますが、識別子の所有者という1つの役割だけを残しています。 しかし、接続数の増加
テナントのクライアントを監視するために必要なすべての情報を収集して保存できます。
コミュニケーション訪問者＃バイヤー＃会社 ：
[{" ", " ", " ", " ", " "}]
この関係により、サプライヤによって課された条件に応じて、バイヤーが終了できるようになります（3つすべてがゼロではありません）。 同様に、接続ビジター＃サプライヤ＃会社 ：
[{" ", " ", " ", " "}]
サプライヤーがテリトリーを離れることを許可するために必要なデータが含まれています。
したがって、アクセス制御システムのかなり単純な構造モデルを構築しました。これにより、このようなシステムが直面するすべての問題と多くの追加タスクを解決できます。
将来的には、データ編集管理システムとそのストレージ、および使用されるデバイスの説明を含む実装例について説明します。