アーキテクチャベースのソフトウェア設計手法とその応用について
まとめ：
2017年5月に同社の「データセンター管理システム」プロジェクトの開発に参加し、システムのアーキテクチャ設計を担当するシステムアーキテクトを務めました。同システムは、全国に点在する同社のデータセンター内の機器の一元的な監視・管理の実現を目的としている。データセンター管理システムを例として、この文書では、プロジェクトにおけるアーキテクチャベースのソフトウェア設計手法の具体的な適用について説明します。この導入では、アーキテクチャ要件、アーキテクチャ設計、アーキテクチャ実装の 3 つの段階に焦点を当てます。アーキテクチャ要件段階では、ユーザーインタビュー、アンケート、現場観察、プロトタイプ構築を通じて要件を網羅的に取得し、アーキテクチャ設計段階では、UMLモデルの4+1ビューでシステムアーキテクチャをモデル化し、アーキテクチャ設計段階では、システムアーキテクチャをUMLモデルの4+1ビューでモデル化します。アーキテクチャの実現の段階では、システム コンポーネントが取得、開発、組み立てられます。このプロジェクトは2018年11月の受付完了後に正式にスタートし、納品・安定稼働を続けており、社内からの受賞やユーザーからの満場一致の賞賛をいただいております。
(交換ノート 345092496 へようこそ)
文章：
背景とプロジェクトの概要:
2016 年 7 月、チャイナ テレコムは、インテリジェンスの時代に適応し、ネットワーク インテリジェンス、ビジネス エコロジー、運用インテリジェンスの推進に重点を置き、インテリジェンスの時代に適応し、業界をリードするモノのインターネット向けのオープン プラットフォームを構築する 3.0 戦略を提案しました。そして、強力なモノのインターネット機能アプリケーション サービスを顧客に提供し、顧客のビジネス プロセスを再構築し、ビジネス価値を掘り起こし、運用コストを削減します。同社はグループ戦略を実行する一方で、長年にわたる事業の継続的な拡大により、徐々に全国に複数のデータセンターを建設してきました。つまり、データセンターごとに管理システムが設計され、システムの状態監視、イベント処理、データレポートを担当する管理担当者が配置されます。データセンターが継続的に増加し、地理的に広範囲に分散しているため、従来のスタンドアロン モードを使用し続けると、多くの人的および物的リソースが増加します。
全データセンターの設備をいかに一元管理し、管理コストを削減し、人的・物的支出を削減するかが、同社にとって喫緊の課題となっている。当社は長年データセンター機器の生産、モジュール設計、機器管理、関連ソフトウェア開発に従事しており、豊富な経験を持っており、社内各部門リーダーとの協議の結果、開発部門が責任を負うことが決定しました。データセンター管理システムの開発に。会社は 12 名と 3 人のシステム実装者からなる開発チームを設立し、私をプロジェクトのシステム アーキテクトとして任命し、ソフトウェア アーキテクチャの設計と開発を担当しました。
慎重に検討した結果、システムは 4 つの主要モジュールに分割されます。デバイス アクセス モジュールは、ゲートウェイ デバイスに接続されているモジュールで、ゲートウェイ デバイスとのメッセージ対話を担当します。メッセージ処理モジュールは、デバイスの受信メッセージとビジネス層の処理結果を認識できる形式に変換します。それぞれによって処理され、カスタムに従ってルール モジュール ルールは、対応するメッセージの処理結果をフィードバックし、メッセージを永続化します ビジネス モジュールには、システム管理、デバイス管理、ネットワーク コンポーネント管理、通知管理、ルール管理、ログ管理が含まれますおよびその他の機能。
遷移：
ABSD はアーキテクチャ主導型であり、ソフトウェア アーキテクチャの設計がビジネス、品質、機能の要件の組み合わせによって推進されることを強調しています。ソフトウェア アーキテクチャを視点とビューで説明し、要件をユース ケースと品質シナリオで説明することに重点が置かれています。ABSD には、機能分解、アーキテクチャ スタイルの選択、ソフトウェア テンプレートの使用という 3 つの基礎があります。この記事では、まず ABSD の開発段階と各段階に含まれるアクティビティを紹介し、プロジェクトと組み合わせた ABSD の具体的な応用について説明し、最後にこのプロジェクトの開発中に私が遭遇した問題と解決策、および私の個人的な洞察。
口論：
技術紹介:
アーキテクチャベースのソフトウェア設計 (ABSD) には、アーキテクチャ要件、アーキテクチャ設計、アーキテクチャ文書化、アーキテクチャレビュー、アーキテクチャ実装、およびアーキテクチャ進化という 6 つの段階が含まれます。アーキテクチャ要件フェーズでは、要件の取得、コンポーネントの特定、アーキテクチャのレビューなど、機能、動作、パフォーマンス、設計制約の観点からシステムに対するユーザーの期待を明確にし、アーキテクチャ設計フェーズでは、要件に従ってアーキテクチャの決定を生成および調整します。アーキテクチャモデルの提案、コンポーネントのマッピング、コンポーネントの相互作用の分析、アーキテクチャの生成とレビュー、アーキテクチャ文書化段階でのアーキテクチャ設計の分析と整理、アーキテクチャ仕様とアーキテクチャ品質指示の生成、アーキテクチャレビュー段階で、アーキテクチャが適切かどうかを評価階層コンポーネントの分割が合理的かどうか、要件を満たし品質特性を達成できる 潜在的なリスクを特定し、設計の欠陥やエラーを早期に発見する; アーキテクチャの分析と設計、コンポーネントの実装、アセンブリを含むアーキテクチャの実装段階でアーキテクチャを実装するアーキテクチャの進化段階では、主に、アーキテクチャの進化計画、コンポーネントの変更、コンポーネントの相互作用の更新、コンポーネントのアセンブリのテスト、技術レビューなど、開発中のユーザー要件の変化の問題を解決します。
プロジェクトを結合します:
アーキテクチャ要件の段階で直面する主な問題は、OJ プラットフォームが学校全体のプログラミング コースの教育活動をサポートする必要があることであり、そのためには要件を効果的かつ迅速に包括的に取得する必要があります。要件の初期段階では、ユーザーインタビューとアンケートを組み合わせて使用し、要件調査チームをいくつかのグループに分けて要件を個別に収集しました。コース指導チームのリーダーとの詳細なコミュニケーションを通じて、私たちは OJ システムの主要なビジネス機能とユーザーの役割を全体的かつ包括的に理解しています。その後、アンケート用紙を作成して全教員に配布し、統計や整理を行った上で、プログラミング講座の教育活動やプロセスの詳細について学びました。要求の中盤には、コース指導チームリーダーの支援と手配により、私たちは教師に続いて学校のコンピュータ実験室に行き、プログラミングコースの現在の実験教育現場を観察し、伝統的な実験でのことを学びました。指導方法、生徒と教師のための具体的な操作手順。要件の後半段階では、ほとんどのビジネス要件の収集が基本的に完了し、ユーザーが試してフィードバックできるラピッドプロトタイピングによる模擬 OJ システムを構築し、ユーザーが設計に参加できるようにし、ワークフローに不可欠なエクスペリエンスを提供します面や事業分野においても、今後のプロジェクトの合格を強力にサポートします。
アーキテクチャ設計段階で遭遇する主な問題は、ソフトウェア アーキテクチャをどのように合理的に設計して記述するかということです。UML モデルの 4+1 ビューでアーキテクチャをモデル化します。シーン ビューは、UML モデルのユース ケース図を使用してモデル化され、ユーザーのニーズと組み合わせて、学生、教師、システム管理者、部外者の 4 種類のユーザー ロールがシステムで定義され、これらのロールに対応するロールが識別されます。例。論理ビューは UML モデルのパッケージ図を使用してモデル化されており、分析の結果、開発にはマイクロサービス アーキテクチャ スタイルを採用することを決定し、システムをフロントエンド Web サービス、プラットフォーム保証サービス、ビジネス サービスの 3 つの部分に分割しました。フロントエンド Web サービスは負荷分散およびサーバー クラスターと結合され、プラットフォーム保証サービスは API ゲートウェイ、サービス登録センター、監視プラットフォームに分割されて基本的なサービス フレームワークを実現し、ビジネス サービスは複数のマイクロサービスに分割されて特定のビジネス機能を実現します。物理ビューは UML モデルの展開図を使用してモデル化され、システム マイクロサービスは分散展開方式を採用し、各マイクロサービスは実際の状況に応じて、同じ物理マシン上に複数のインスタンスを展開したり、複数の物理マシンを同時に展開したりできます。クラスタはロードバランシングによる統合アクセスを実行し、ルーティングモードで展開され、システムの内部ネットワークと外部ネットワークは異なる論理ネットワークに属します。負荷分散アルゴリズムの選択では、最小接続方式が使用されます。
アーキテクチャの実現段階で直面する主な問題は、システム コンポーネントをどのように実現して組み立てるかということです。コンポーネントの実現は、既存のコンポーネントを取得する方法と、新しいコンポーネントを開発する方法の 2 つに分けられます。OJシステムは教育行政やOAシステムと連携する必要があり、その実装には開発者が提供するSDK、Spring CloudやEurekaなどのマイクロサービスアーキテクチャの基本フレームワークと評価機が呼び出すコンパイラを利用します。などは、サードパーティのソフトウェア実装と直接統合されています。共通情報システムに共通するユーザ管理、ロール権限管理、ログ記録、コンテンツ保守、メッセージセンターなどの基本機能は、これまでのユニットのプロジェクト開発で蓄積された対応コンポーネントを利用して実現されます。OJシステム独自の機能部品については、特別な開発が必要であり、実験課題や競技、試験などのさまざまな利用シーンでの同一試験問題の展開を実現するデコレータパターンなど、さまざまなデザインパターンを採用しています。実現する戦略パターン C言語、Java、Pythonなどのプログラミング言語ごとに評価機のコンパイル方法が異なります。コンポーネントの実現が完了した後は、業種に応じて異なるコンポーネントの組み立て方法を採用します。例えば、試験サービスは問題バンクから試験問題情報を取得して同期メッセージ方式を採用、プログラム評価サービスは手間がかかるため非同期メッセージ方式を採用、承認プロセスを伴う業務はワークフローベースの組み立てを採用方法。
結論：
このプロジェクト開発の全体的な観点から見ると、アーキテクチャ スタイルを適切に選択すると、モジュール間の結合度が減少し、システム パフォーマンス、使いやすさ、変更可能性、その他の指標が向上し、企業の予想される要件を満たし、システムの二次開発を迅速に行うことができます。後の段階の開発とデータ アクセス。しかし、システム開発の過程では、デバイスの数が多いため、ID を使用してデバイスを識別すると、データの視覚化が不十分になり、デバイスの位置を特定することが困難になるといういくつかの問題が発生しました。このため、私は経度および緯度の測位とデバイス ID の識別を組み合わせて使用し、Echarts+VUE を使用してデータを取得し、Baidu マップをベースとして使用してすべてのデバイスを視覚的に表示します。これは迅速な測位に便利です。次に、多数の制御層コードとリレーショナル データベースの永続層間の相互作用により実行速度が低下するため、効率を向上させるために、キャッシュとして Redis と Elasticsearch 検索エンジンを追加しました。システムの複雑さは増加しましたが、 、データ アクセス速度が大幅に向上しました。大幅な改善です。
このプロジェクトが無事に完了したことで、私はプロジェクトの建築スタイルの選択においてより多くの経験を積むことができましたが、同時に、建築スタイルの選択におけるいくつかの欠陥も明らかになりました。