システム設計は、指定された要件を満たすシステムのアーキテクチャ、コンポーネント、モジュール、インターフェイス、およびデータを定義するプロセスです。これには、ユーザーの要件を、実装フェーズをガイドする詳細な青写真に変換することが含まれます。目標は、拡張性、保守性、パフォーマンスなどの要素を考慮しながら、意図された目的を満たす、よく組織化された効率的な構造を作成することです。
システム設計をマスターすることは、堅牢でスケーラブルなシステムを構築したい人にとって非常に重要です。私たちの総合的な システムデザインコース この分野で優れた知識とスキルを提供します。実践的な例と専門家の洞察を通じて、ユーザーの要件を効果的に実装可能な詳細な設計に変換する方法を学びます。
システム設計上の重要なトピック
- なぜシステムデザインを学ぶのか?
- システム設計の目的
- システム設計の構成要素
- システム設計ライフサイクル (SDLC)
- システムアーキテクチャー
- システム設計におけるモジュール性とインターフェース
- 既存システムの進化/アップグレード/スケール
- システム設計例：航空券予約システム
- システム設計のメリット
なぜシステムデザインを学ぶのか?
ソフトウェアであれ、その他のテクノロジーであれ、あらゆる開発プロセスにおいて、最も重要な段階は次のとおりです。 デザイン 。設計フェーズがなければ、実装やテストの部分に進むことはできません。システムに関しても同様です。
システム設計は、システム開発における重要なステップであるだけでなく、ソフトウェアのビジネス ロジックを表すため、例外的なシナリオを処理するためのバックボーンも提供します。
SDLCにおけるシステム設計フェーズの重要性
整数をJavaの倍精度に変換する
上記の SDLC ステップから、システム設計がバックボーンとして機能することは明らかです。コーディング部分がどれほど適切に実行されたとしても、対応する設計が適切でなければ、後になって意味がなくなるからです。したがって、ここで、なぜそれがすべての製品ベースの企業で質問されるのかについての重要な重要な情報が得られます。
システム設計の目的
- 実用性 : 設計している対象となる一連の視聴者 (ユーザー) をターゲットにするシステムが必要です。
- 正確さ : 上記のシステム設計は、機能要件であっても非機能要件であっても、設計の基礎となるほぼすべての要件を満たすように設計される必要があります。
- 完全 : システム設計はすべてのユーザー要件を満たす必要があります
- 効率的 : システム設計は、リソースのコストを超えて過剰に使用したり、使用不足にならないようにする必要があります。そうすることで、スループット (出力) が低下し、応答時間 (レイテンシ) が低下することがわかっています。
- 信頼性 : 設計されたシステムは、一定期間、障害のない環境に近接する必要があります。
- 最適化 : 時間と空間は、システム内で動作する個々のコンポーネントのコード チャンクに対して行われる可能性があります。
- スケーラブル(柔軟性) : システム設計は、時間通りに変化し続けることがわかっている顧客のさまざまなユーザー ニーズに応じて、時間の経過とともに適応できる必要があります。ここでの最良の例は、有名な企業である Nokia です。これはシステム設計時に最も重要な側面であり、スタートアップ 100 社中 1 社が長期的に成功する理由の結果です。ここでの最良の例は techcodeview.com です。
システム設計の目的
注: システム設計は、1 つまたは 2 つのコンポーネントに障害が発生した場合でもソフトウェアが動作し続ける能力であるフォールト トレランスの実現にも役立ちます。
上記の目的をざっと確認した後、以下の利点により理解がさらに現実に近づくため、システム設計の利点についてよりよく説明します。
システム設計の構成要素
以下は、システム設計の主要コンポーネントの一部です。簡単に説明しました。これの詳細なバージョンについては、別の投稿で説明します。
- ロードバランサ: システムのスケーラビリティ、可用性、パフォーマンスの測定にとって最も重要なコンポーネント。
- キーバリューストア: これは、キーと値のストアが分散ハッシュ テーブルであるハッシュテーブルに似たストレージ システムです。
- BLOB ストレージ: Blob はバイナリ ラージ オブジェクトの略で、その名前が示すように、YouTube や Netflix などの非構造化データ用のストレージです。
- データベース: これは、簡単にアクセスして変更できるように整理されたデータのコレクションです。
- レートリミッター: これらは、サービスが満たせるリクエストの最大数を設定します。
- 監視システム： これらは基本的に、システム管理者が帯域幅、CPU、ルーター、スイッチなどのインフラストラクチャを監視するソフトウェアです。
- 分散システムメッセージングキュー: 生産者と消費者の間の取引媒体。
- 分散型固有 ID ジェネレーター: 大規模な分散システムの場合、常に複数のタスクが発生するため、区別するためにすべてのイベントに対応するタグが割り当てられます。
- 分散検索: どの Web サイトでも、訪問者が求める重要な情報が検索バーに表示されます。
- 分散ログサービス: イベントのシーケンスを端から端までトレースします。
- 分散タスクスケジューラ: CPU、メモリ、ストレージなどの計算リソース。
システム設計の構成要素
システム設計のライフサイクル (SDLC)
システム デザイン ライフ サイクル (SDLC) は、ソフトウェア アプリケーション、ハードウェア ソリューション、またはその両方を組み合わせた統合システムなど、システムの設計と開発に含まれる手順を概説する包括的なプロセスです。これには、ユーザーのニーズと組織の目標に合わせたシステムの作成をエンジニアがガイドする一連のフェーズが含まれます。 SDLC は、最終製品の信頼性、拡張性、保守性を確保することを目的としています。
文字列の日付を変換する
システム設計ライフサイクルのフェーズ (段階) は次のとおりです。
- 企画
- 実現可能性調査
- システムデザイン
- 実装
- テスト
- 導入
- メンテナンスとサポート
システムアーキテクチャー
ソフトウェア アーキテクチャは、私たちが定義する方法です。 設計のコンポーネントがどのように表現されるか ソフトウェアの設計と展開 。
これは基本的に、ソフトウェア システムのコンポーネント、抽象化レベル、その他の側面を表すソフトウェア システムのスケルトン設計です。素人の言葉で理解するには、ビジネスの目的やロジックが明確であり、1 枚の紙にまとめられている必要があります。ここには、既存のシステムと今後スケールアップされるシステムに関する大規模プロジェクトの目標とスケールアップへのさらなるガイドが含まれています。
システムアーキテクチャパターン
ソフトウェア アーキテクチャでコンポーネントを編成するにはさまざまな方法があります。また、ソフトウェア アーキテクチャ内のコンポーネントのさまざまな事前定義された構成は、ソフトウェア アーキテクチャ パターンとして知られています。多くのパターンが試行され、テストされました。彼らのほとんどはさまざまな問題をうまく解決しています。各パターンでは、ソフトウェア アーキテクチャの特定の問題を解決するために、コンポーネントが異なる方法で編成されます。
さまざまな種類のソフトウェア アーキテクチャ パターンには次のものがあります。
- レイヤードパターン
- クライアントサーバーパターン
- イベント駆動型パターン
- マイクロカーネルパターン
- マイクロサービスのパターン
システムアーキテクチャパターン
システム設計におけるモジュール性とインターフェース
- モジュール設計 完成品を作成するために、より小さな独立した要素を統合または組み合わせることを含む、製品設計の方法/手順を指します。大きな製品 (自動車など) は、モジュラー設計アプローチを使用して個別に開発および製造される、より小さく単純なコンポーネントに分割できます。これらの各構成部品を統合（組み立て）することで最終的な製品が生まれます。
- システム設計におけるインターフェース ユーザーが対話する領域です。これは、システムのナビゲーションを容易にする画面表示、データを収集する画面とフォーム、およびシステムのレポートで構成されます。
既存システムの進化/アップグレード/スケール
オフラインでもオンラインでもテクノロジーの使用量が増加するにつれ、現在、すべての開発者にとって、 スケーラブルなシステム 。システムがスケーラブルでない場合、ユーザーの増加に伴ってシステムがクラッシュする可能性が非常に高くなります。そこで、スケーリングの概念が登場します。
Java 8の機能
タスクを処理する特定のディスクと RAM の構成を持つシステムがあるとします。システムを進化させたりスケールアップしたりする必要がある場合、2 つの選択肢があります。
- 既存システムのアップグレード仕様: RAM やディスク サイズ、その他多くのコンポーネントをアップグレードすることで、プロセッサを改良しているだけです。ここでは、ネットワーク帯域幅のスケーラビリティと可用性については考慮していないことに注意してください。ここでは進化に従って、スケーラビリティが維持されることのみを考慮して可用性係数を検討しています。これは垂直スケーリングとして知られています。
- 複数のシステムを接続して分散システムを作成します。 スケーラビリティが基準に達していない場合、可用性対策には制限があるため、この対策には複数のシステムが必要であることが上記でわかりました。スケールアップするには、より多くのシステム (より多くのブロックのチャンク) が必要であり、これは水平スケーリングとして知られています。
既存システムの進化/アップグレード/スケール
システム間のデータの流れは次のとおりです。 データ フロー ダイアグラムまたは DFD 。
データ フロー ダイアグラムまたは DFD 情報を通じたデータの流れをグラフィカルに表現したものとして定義されます。 DFD は、システムがどのように小さな部分に分割されているかを示し、これらの部分間のデータの流れを強調するように設計されています。
Javaメソッドの配列
データ フロー ダイアグラムの基本構造を示す例を次に示します。
データフロー図の基本構造
DFD のコンポーネント:
| 表現 | 実行されたアクション |
|---|---|
| 四角 | データのソースと宛先を定義します |
| 矢印 | データフローを識別し、情報が流れるパイプラインとして機能します。 |
| サークル/バブル | 受信データ フローを送信データに変換するプロセスを表します |
| 開いた長方形 | データ ストアまたは保存データ/データの一時リポジトリです。 |
注記： 送信者と受信者は常に大文字で書く必要があります。むしろ、DFD の規則に従い、正方形のボックス内に配置されるものはすべて大文字を使用することをお勧めします。
システム設計例：航空券予約システム
ここまでシステム設計の基本について説明してきましたので、ここでは基本的な例である航空会社予約システムを通してシステム設計を理解しましょう。
航空会社予約システムのコンポーネントと設計についてより深く理解するために、まずそのコンテキスト レベルのフロー図を確認してみましょう。
システム設計例：航空券予約システム
foreach タイプスクリプト
ここで航空予約システムの DFD を理解しましょう。
- 上記のフロー図では、 乗客 、 旅行代理店 、 航空会社 データが移行されるソースです。
- ここからデータが送信されます 航空券を予約する乗客 旅行リクエストが行われる DFD の矢印記号で示されているように。
- さて、このデータは、上に示したように 2 つのソース間で送信されます。 旅行代理店 ' そして ' 航空会社 「席が空いたらどこで」 環境設定 そして 飛行 リクエストがソースに送信されます。
- 旅行代理店および対応する発券はリクエストに応じて手配されます。
- 利用可能な航空券がない場合は、旅客予約のリクエストが発行元である航空会社に送信されます。
システム設計のメリット
システム設計の導入を詳細に議論する際には、そのメリットとデメリットを議論することが必須です。
システム設計の最大の利点は、API プロトコル ゲートウェイ、ネットワーキング、データベースの相乗結合を通じて、フルスタック開発者に意識と創造性を植え付けることです。
システム設計の主な利点には次のようなものがあります。
- 製品の設計コストを削減します。
- スピーディなソフトウェア開発プロセス
- SDLC での全体的な時間を節約します
- プログラマーの効率と一貫性が向上します。
- リソースを節約します
システム設計を学ぶ: システム設計チュートリアル