现在的一切都是为将来的梦想编织翅膀，让梦想在现实中展翅高飞。
Now everything is for the future of dream weaving wings, let the dream fly in reality.
システムアーキテクチャ設計における高度なスキル・階層アーキテクチャ設計の理論と実践
1. 階層アーキテクチャの概要
1.1 定義
ソフトウェア アーキテクチャは次のように定義できます。 ソフトウェア アーキテクチャは、ソフトウェア システムの構造、動作、プロパティの高レベルの抽象化を提供します。これは、システムを構成する要素の記述、これらの要素の相互作用、パターンの説明で構成されます。要素の統合と、これらのパターンの制約をガイドします。ソフトウェア アーキテクチャは、システムの組織構造とトポロジを指定するだけでなく、システム要件とシステムを構成する要素の間の対応関係を示し、設計上の決定のためのいくつかの基本原則を提供し、ソフトウェア上に構築されたシステム レベルの複合体です。システムの使用です。
階層化アーキテクチャは最も一般的なアーキテクチャ設計方法であり、設計を効果的に簡素化し、設計されたシステム構造を明確にし、再利用性と製品保守機能の向上を促進します。階層アーキテクチャ設計では、システムを階層構造に編成し、各層が上位層として機能し、下位層の顧客として機能します。一部の階層システムでは、慎重に選択されたいくつかの出力関数を除いて、内部層インターフェイスは隣接する層にのみ表示されます。コネクタは、層がどのように相互作用するかを決定するプロトコルによって定義され、トポロジ上の制約には、隣接する層間の相互作用に関する制約が含まれます。各層は最大でも 2 層にのみ影響を与えるため、隣接する層に同じインターフェイスが提供されている限り、各層を異なる方法で実装することができ、ソフトウェアの再利用を強力にサポートします
。
1.2 階層型アプリケーションの構成
1.3 特徴と注意事項
2. プレゼンテーション層フレームワークの設計
2.1 MVC (モデル-ビュー-コントローラー) パターン
MVC はソフトウェア設計パターンです。MVC は、アプリケーションの入力、処理、出力プロセスをビュー、コントロール、モデルの観点から分離し、コントローラー、モデル、ビューの 3 つのコア モジュールを形成します。(1) コントローラー: ユーザー入力を受け入れ、モデルを呼び出します
。ユーザーのニーズを満たせるビューを提供します。
(2) モデル: アプリケーションの主要部分であり、ビジネス データとビジネス ロジックを表します。
(3) ビュー: ユーザーが表示し、通信するためのインターフェイス。
図に示すように、この 3 つの連携関係により、
MVC パターンを使用してプレゼンテーション層を設計すると、次の利点が得られます。
(1) さまざまなユーザー インターフェイスの拡張が可能になります。
(2) メンテナンスが容易です。
(3) 強力なユーザーインターフェイスを簡単に構築できます。
(4) アプリケーションの拡張性、堅牢性、柔軟性が向上します。
2.2 MVP (モデル-ビュー-プレゼンター) モード
MVP モードでは、モデルがデータを提供し、ビューが表示を担当し、コントローラー/プレゼンターが論理処理を担当します。MVP は、ビューとモデル間の結合を回避するだけでなく、プレゼンターのビューへの依存をさらに軽減します。
図に示すように、MVP 設計パターン:
MVP パターンを使用してプレゼンテーション層を設計すると、次の利点があります:
(1) モデルはビューから完全に分離され、モデルに影響を与えることなくビューを変更できます。
(2) すべての対話は 1 か所 (Presenter 内) で行われるため、モデルをより効率的に使用できます。
(3) プレゼンターのロジックを変更せずに、1 つのプレゼンターを複数のビューに使用できます。ビューは常にモデルよりも頻繁に変更されるためです。
(4) Presenter にロジックを配置すると、ユーザーインターフェイスなしでロジックのテスト (単体テスト) ができます。
2.3 MVVM (Model-View-ViewModel) パターン
MVVM は MVC や MVP に似ており、その主な目的はビューとモデルの分離を実現することです。違いは、MVVM では、View と Model 間の対話が ViewModel を通じて実現されることです。つまり、View と Model は直接通信できず、この 2 つの間の通信は ViewModel を通じてのみ実現できます。ViewModel は MVVM の中核であり、データ状態の処理、データバインディング、データ変換を含む DataBinding を通じて View と Model 間の双方向バインディングを実現します。
図に示すように、MVVM 設計パターンは次のとおりです。
3. 中間層フレームワークの設計
3.1 ビジネスロジック層のコンポーネント設計
ビジネス ロジック層のコンポーネントは、インターフェイスと実装クラスの 2 つの部分に分かれています。インターフェイスはビジネス ロジック コンポーネントを定義するために使用され、ビジネス ロジック コンポーネントが実装する必要があるメソッドの定義は、システム動作全体の中核です。ビジネス ロジック コンポーネントは通常、モジュールに従って設計されます。各モジュールはビジネス ロジック コンポーネントで設計され、各ビジネス ロジック コンポーネントは複数のデータ アクセス オブジェクト (DAO) コンポーネントをベースラインとして使用して、システムのビジネス ロジック サービスを外部に提供します。
3.2 ビジネスロジック層のワークフロー設計
Workflow Management Coalition (WFMC) は、ワークフローを次のように定義しています: ビジネス プロセスの完全または部分的な自動化。このプロセスでは、ドキュメント、情報、またはタスクが特定のプロセス ルールに従って流れ、組織メンバー間の調整が行われ、ビジネスの全体的な目標が達成されます。
図に示すように、ワークフロー参照モデルは次のとおりです。
3.3 ビジネスロジック層エンティティの設計
ロジック層エンティティは、ビジネス データおよび関連機能 (一部の設計) へのステートフルなプログラムによるアクセスを提供します。ビジネス ロジック レイヤーのエンティティは、多くの場合、データベース内の複数の関連テーブルから取得される、複雑なスキーマを持つデータを使用して構築できます。ビジネス ロジック層のエンティティ データは、ビジネス プロセスの I/O パラメーターの一部として渡すことができます。ビジネス ロジック層エンティティは、現在の状態を維持するためにシリアル化できます。
3.4 ビジネスロジック層フレームワーク
ビジネスロジックフレームワークは、システムアーキテクチャの中間層に位置し、システム機能を実現するための中核となるコンポーネントです。コンテナの形式を採用し、開発、コードの再利用、システム機能の管理を容易にします。ビジネスコンテナでは、ドメインモデル・サービス・コントロールの考え方に従ってビジネスロジックが実装されます。(1) ドメイン モデルは
、ビジネス関連の属性のみを含むドメイン層ビジネス オブジェクトです。
(2) サービスはビジネス プロセス実装の不可欠な部分であり、アプリケーション プログラムの異なる機能単位であり、明確に定義されたインターフェイスとこれらのサービス間のコントラクトを通じて接続されます。
(3) コントロール サービス コントローラーはサービス間のリンクであり、異なるサービス間の切り替えはこれを介して実現されます。
4. データアクセス層フレームワークの設計
4.1 データアクセスモード
(1) オンライン アクセス
(2) データ アクセス オブジェクト
(3) データ転送オブジェクト
(4) オフライン データ モード
(5) オブジェクト/関係マッピング
4.2 データアクセス層でのファクトリパターンの適用
これには、実際の開発プロセス中に、これらのデータベース アクセス クラスを再度カプセル化する必要があります。このようにカプセル化すると、上記の目的が達成されるだけでなく、データベースの操作手順が削減され、コードの記述量も削減されます。工場設計パターンが主に使用される方法です。
ファクトリ パターンはオブジェクトを作成するためのインターフェイスを定義し、サブクラスがどのクラスをインスタンス化するかを決定できるようにします。ファクトリ メソッドを使用すると、クラスのインスタンス化をそのサブクラスに延期できます。ここでは複数のデータベースに対する操作を処理できるため、最初にデータベースを操作するためのインターフェイスを定義し、次にクラス ファクトリがデータベースに基づいてどのクラスをインスタンス化するかを決定する必要があります。
4.3 ORM、Hibernate、CMP2.0 の設計アイデア
ORM (オブジェクト リレーション マッピング) は、リレーショナル データベースとオブジェクトの間のマッピングを作成します。これにより、データベースを具体的に操作するときに、複雑な SQL ステートメントを扱う必要がなくなり、通常の操作と同じように操作するだけで済みます。オブジェクト。(OR マッピングを使用せずに) アプリケーションを開発する場合、データベースなどからのオブジェクト情報の保存、削除、読み取りに使用されるデータ アクセス層に多くのコードが含まれる場合があります。ただし、これらのコードは作成時に常に繰り返されます。 。より良い方法は、OR マッピングを導入することです。基本的に、OR マッピングによって DAL が生成されます。DAL コードを自分で記述する代わりに、OR マッピングを使用する方が良いため、開発者はオブジェクトのみを考慮する必要があります。
4.4 XMLスキーマ
XML スキーマは、XML ドキュメントの法的構造、内容、制限を記述するために使用されます。XML スキーマは、XML 1.0 によって自己記述され、名前空間を使用します。豊富な埋め込みデータ型と強力なデータ構造定義機能を備え、DTD (XML 文書構造とコンテンツ制限の従来の記述) を完全に変換し、大幅に拡張します。メカニズム) は、徐々に置き換えられます。 DTD は XML システムの正式な型言語となり、XML 仕様および名前空間仕様とともに、XML システムの強固な基盤となります。
4.5 トランザクション処理の設計
トランザクションは、現代のデータベース理論の中核となる概念の 1 つです。一連の処理ステップがすべて実行されるか、まったく実行されない場合、その一連の処理ステップをトランザクションと呼びます。すべてのステップが 1 つの操作として完全に実行されると、トランザクションがコミットされたと言います。1 つ以上のステップが失敗し、ステップがコミットされないため、トランザクションをロールバックする (元のシステム状態に戻す) 必要があります。トランザクションは、ISO/IEC によって確立された ACID 原則に準拠する必要があります。ACID は、Atomicity、Consistency、Isolation、Durability の略語です。トランザクションのアトミック性とは、トランザクションの実行中に障害が発生すると、トランザクションによって行われた変更が無効になることを意味します。一貫性とは、トランザクションが失敗したときに、トランザクションの影響を受けるすべてのデータをトランザクションが実行される前の状態に復元する必要があることを意味します。分離とは、トランザクションがコミットされるまで、トランザクション実行中のデータへの変更が他のトランザクションから認識されないことを意味します。永続性とは、トランザクションの実行が失敗した場合でも、送信されたデータのステータスが正しい必要があることを意味します。
4.6 接続オブジェクト管理設計
共有リソースには、リソース プールという非常に有名な設計パターンがあります。このモデルは、リソースの頻繁な割り当てと解放によって引き起こされる問題を解決するように設計されています。このモデルをデータベース接続管理の分野に適用すると、データベース接続プールが確立され、一連の効率的な接続割り当てと使用戦略が提供されます。接続プールを確立する最初のステップは、静的接続プールを確立することです。いわゆる静的とは、プール内の接続がシステムの初期化中に割り当てられ、自由に閉じることができないことを意味します。この接続プールを使用すると、カスタマイズされた一連の割り当ておよび解放戦略を以下に提供できます。クライアントがデータベース接続を要求すると、まず接続プールに未割り当ての接続があるかどうかを確認します。アイドル状態の接続がある場合、その接続はクライアントに割り当てられ、それに応じて処理されます。
5. データアーキテクチャの計画と設計
5.1 データベースとクラス設計の統合
クラスとクラス間の関係を正しく識別することがデータ モデルの鍵です。このセクションでは、クラスを検出、識別、および説明する方法について説明します。モデリング プロセスを単純な段階的なプロセスに減らすことは不可能です。本質的に、モデリングは芸術です。特定の複雑な状況に対応する単一の正しいデータ モデルはありませんが、優れたデータ モデルは存在します。企業または機関にとって、あるデータ モデルが別のデータ モデルよりも優れている場合もありますが、特定のシステムのデータ モデルをモデル化する方法については単一の解決策はありません。
優れたモデルの目標は、プロジェクトの全期間にわたってコストを最小限に抑えながら、時間の経過とともに起こり得るシステムの変化も考慮に入れることであるため、設計ではこれらの変化への適応も考慮する必要があります。したがって、開発費を最小限に抑えることに重点を置くのは間違いです。
5.2 データベース設計と XML 設計の統合
XML ドキュメントは 2 つのカテゴリに分類されます。1 つはデータ中心のドキュメントです。構造が規則的で、内容が同型で、コンテンツの混合やネストされたレベルが少なく、人々はドキュメントのみを気にします。ドキュメント内のデータは気にしません。データ要素の格納順序。この種の文書は略してデータ文書と呼ばれ、Web データの格納や送信によく使用されます。もう 1 つは文書中心の文書です。このタイプの文書は、構造が不規則で、内容が散在し、内容がより混合されており、要素間の順序に関連性があります。このタイプの文書は、Web ページに説明を掲載するためによく使用されます。性的な情報、製品性能紹介やメール情報など。
XML ドキュメントを保存するには、ファイルベースのストレージとデータベース ストレージの 2 つの方法があります。
6. モノのインターネットの階層アーキテクチャ設計
-
(1) 知覚層:
知覚層は、オブジェクトを識別し、情報を収集するために使用されます。認識層には、QR コード タグとリーダー、RFID タグとリーダー、カメラ、GPS、センサー、M2M 端末、センサー ゲートウェイなどが含まれます。その主な機能は、物体を識別し、情報を収集し、皮膚や顔の特徴の役割を認識することです。人間の体の構造も似ています。 -
(2) ネットワーク層:
ネットワーク層は、情報の送信と情報の処理に使用されます。ネットワーク層には、通信ネットワークとインターネットの統合ネットワーク、ネットワーク管理センター、情報センター、知能処理センターが含まれます。ネットワーク層は、人体の構造における神経中枢や脳と同様に、知覚層で得られた情報を送信および処理します。 -
(3) アプリケーション層:
アプリケーション層は広範なインテリジェンスを実現します。アプリケーション層は、モノのインターネットと業界の専門知識を深く統合し、業界のニーズを組み合わせて業界のインテリジェンスを実現します。これは人々の社会的分業に似ています。