この記事では主にアーキテクチャの概念を紹介し、需要分析の重要性を拡張します。
今後もフォローアップシリーズを企画し、勤務以来の要件実現事例を定期的に紹介していきたいと思います。
注: アーキテクチャの内容は比較的多く、各ポイントを一連の記事に展開できるため、
この記事は単なるとりとめのない話であり、内容のほとんどは単なる紹介に過ぎません。後で時間があるときに。
アーキテクチャの紹介
1.誤解
アーキテクチャに関して言えば、多くの開発者、特にバックエンド開発は、次のような多くの技術コンテンツに関連付けられます。
- サブライブラリとサブテーブル
- 負荷分散
- マイクロサービス設計
- 分散型 CAP 原則
- ヒューズのダウングレード電流制限
- 登録の発見
- サービスメッシュ
実際、これらはアーキテクチャの主要な内容ではなく、いくつかの要件や問題に対する解決策のほんの一部にすぎません。また、これらの解決策でさえ適用範囲が非常に狭く、主にインターネット プロジェクト (高い同時実行性) に使用されます
。 、高性能、大規模なデータ要件）
大多数のプロジェクト、特にスタートアップ プロジェクトでは、これらのソリューションはまったく使用されません。これは、最初のかなりの期間、ユーザーにそれほど大量のデータがないためです。 、または同時実行性。
2. コンセプト
プラットフォームが異なれば、アーキテクチャの解釈も異なります。
- Wikipedia: ソフトウェア アーキテクチャは、ソフトウェアの全体的な構造とコンポーネントを抽象的に説明したもので、大規模なソフトウェア システムのあらゆる側面の設計をガイドするために使用されます。
- ISO/IEC: システムの基本的な構造的アプローチ。システムの要素、これらの要素間の関係、システムの設計と実装の指針となる原則が含まれます。
- IEEE: アーキテクチャとは、システムの内部コンポーネント間の関係、コンポーネントと外部間の関係、およびシステムの設計と進化を決定する原則を含む、コンポーネント レベルでのシステムの基本的な構造表現です。
- Baidu Encyclopedia: アーキテクチャは、ソフトウェアの全体的な構造とコンポーネントを抽象的に記述したもので、大規模なソフトウェア システムのあらゆる側面の設計をガイドするために使用されます。
インターネットで見つけたアーキテクチャの定義の方が適切でわかりやすいと思います。
- 解決する問題に応じて、ターゲット システムの境界を定義します。
- そして、ある原則に従って対象システムをセグメント化します。セグメンテーションの原理は、分割された部分に対してさまざまな役割が並列または直列で作業できるようにすることです。一般に、並列処理により時間を短縮できます。
- これらの分割された部分に対して、通信メカニズムを確立します。
- 前のステップの通信メカニズムに従って、これらの部分が有機的に接続され、結合され、全体として組み立てられ、ターゲット システムのすべての作業が完了します。
注: セグメント化は、マイクロサービスを分割することを意味するものではありません。複数のモジュールを 1 つのユニットとしてデプロイすることもできます。ただし、セグメント化した後、後でマイクロサービスをデプロイする方が便利です。
3. なぜアーキテクチャが必要なのか
写真を見てください:
この写真は、私たちが生きている時代が変化しやすい時代であることを示しています。この写真は多くの製品/需要にも当てはまります。「需要の最大の確実性は需要の不確実性である」という格言があります
。
「変化する需要」を意味し、この特性は安定して変化しません。
インターネットからの抜粋:
- アーキテクチャ設計の主な目的は、システムの目的とする機能を実現することを前提として、システムの複雑さによって生じる問題を解決することです。
システムの複雑さの原因:- 要件がテクノロジーを複雑にする
- 人がテクノロジーを複雑にする
- テクノロジー自体の複雑さ
- システムの安定稼働の複雑さ
システムの複雑さや要件の変動に対応するには、事前にアーキテクチャの計画と設計を行う必要がありますが、アーキテクチャ設計の一般的な手順は次のとおりだと思います。
- 要件を収集し、
マーケティング担当者、製品マネージャー、エンドユーザーとのコミュニケーションや調整、実現可能性の分析などを含む要件を理解します。 - 要件分析 機能
要件、非機能要件 (セキュリティ要件を含む)、時間制約など、システムが達成すべき目標を明確にします。このステップでは通常、いくつかのユース ケース図、
シーケンス図、および状態図を整理して準備する必要があります。要件を説明し、伝達する。 - 技術選定・技術設計
この段階では、使用する開発言語、開発ツール、技術フレームワーク、データベース、ミドルウェアなどを明確にし、概要設計、詳細設計を行う必要があります。 - チーム分け・技術スケジューリング
- 反復開発/継続的デリバリー
- O&M導入/監視
アーキテクチャ設計の各段階では、アーキテクトは現在の背景に基づいて相対的にバランスの取れた計画を作成する必要があります。要件が
実現できるかどうかが最も重要な基準、または唯一の基準でさえあり、
どの要件にも単一の正しさはありません。アーキテクチャまたは独自のものです。実装。
建築家の背景要因には一般に次のようなものがあります。
- アーキテクトの個人的な技術的経験。これは主に技術的な選択に影響します。
たとえば、私は MySQL の問題を扱う経験は比較的豊富ですが、他のデータベースの経験は少ないため、PostgreSQL や MongoDB ではなく MySQL をデータベースとして選択します。 ; - アーキテクトのプロジェクト経験、これは主に境界認識とモジュール分割に影響します。
たとえば、私は SaaS システムに携わったことがあり、設計時にグローバル SaaS-ID の送信と将来のグレースケール リリースを事前に考慮しますが、まだ考慮していません
。保険事業に従事している人は、保険プロジェクトを行う場合、保険事業を設計する前に保険事業を理解するために多大なエネルギーを費やす必要があります。
システム要件 (非機能要件を含む、システムが達成できる機能と将来の期待を含む)、- 期間要件、システムに必要な配信時間、段階的に配信できるかどうか
- チームの機能。テクノロジの選択、作業分割、およびプロジェクト管理に影響します
。たとえば、チームに C++ の専門家がいる場合は、C++ を使用してクライアント側の画像圧縮またはサーバー側の画像圧縮を実装することを検討できます。 - ソフトウェアの制限はテクノロジーの選択に影響します。
たとえば、展開には Centos のみを使用できるため、.Net Framework 開発を選択することはできません。 - ハードウェアの制限は、テクノロジーの選択とコストの考慮事項に影響します。
たとえば、xx クラウドと連携していますが、RabbitMQ はサポートされていないため、メッセージ キューを他の利用可能なタイプに置き換える必要があります。
需要分析
1. 問題を解決することよりも、問題を見つけることが重要です
アーキテクチャ設計のステップで最も重要なステップは要件分析のステップです。その理由は次のとおりです。
【問題を解決することよりも問題を見つけることが重要】
問題を間違って理解すると、問題解決への投資が無駄になるか、問題を解決する正しいタイミングを逃し、予期せぬ結果を招く可能性があります。
写真を見てください、誰かがトマトと卵のスープを作っています:
私はこの写真を通して真実を説明したいと思います:
経験と知識は人それぞれ異なり、それが異なる認知結果につながります。あなたが常識だと思っていることもありますが、別の人は常識ではありませんまったく理解できていない
継続的なコミュニケーションや再説明を通じてニーズや問題を正しく理解し、次のステップを正しく実行する必要があります。
別の図を投稿して、間違った要件が実装された場合、実現のさまざまな段階でコストの差が異なることを示します。要件分析段階でのコストの無駄が最も少なく、その差はすでに 10 倍であることがわかります。オンライン保守フェーズは言うまでもなく、コーディング段階です。
2. ニーズ分析の方法
要件分析の最も重要な機能は、効果的な要件を特定することです。通常、要件には次の 3 つのレベルがあります。
-
ビジネス要件 ( ビジネス要件 ) は、組織または顧客の高レベルの目標を表します。ビジネス要件は通常、プロジェクトの投資家、製品を購入する顧客、実際のユーザーのマネージャー、マーケティング部門、または製品企画部門から来ます。ビジネス要件は、組織がシステムを開発する理由、つまり組織が何を達成したいかを記述します。理解: このシステムを構築したい人は誰であれ、住宅を建設するという不動産開発者の需要など、
市場の需要、どのような市場の問題や問題点が解決されているかも理解できます。 -
ユーザー要件 (ユーザー要件) は、ユーザーの目標、またはシステムが完了できるようにユーザーが要求するタスクを記述します。ユースケース、シナリオの説明、イベント応答テーブルはすべて、ユーザーのニーズを表現する効果的な方法です。言い換えれば、ユーザー要件は、ユーザーがシステムで何ができるかを記述します。
理解する: 誰がシステムを使用しているのか。たとえば、住宅を購入するユーザーが提示する住宅需要。 -
機能要件（機能要件）とは、開発者が製品に実装しなければならないソフトウェアの機能を規定したもので、利用者はこれらの機能を利用してタスクを完了し、ビジネスニーズを満たすために使用されます
。家自体にどのような機能が必要か
さまざまな段階でさまざまなレベルの要件が出力されますが、事業開発では 3 つのレベルの要件を理解し、各レベルの要件を順番に検討し、満たす必要があります。
要件分析の一般的な手順は次のとおりで、通常、対応する要件ドキュメントとさまざまな UML 凡例出力があります。
3. 一般的な UML 図:
この記事では、一般的に使用される 5 つの UML 図のみを紹介します。
システムコンテキスト図
構築するシステムと外部エンティティ (人、機器、その他のシステム) の間の境界とインターフェイスを定義します。現在のシステムに直接関連するエンティティのみに焦点を当て、依存関係の
依存関係は考慮しません。最初にシステム コンテキストを決定し、次にユース ケース モデリングを使用します。2. システム参加者が、より高いレベルで構築されるシステムのユーザーが誰であるかを直感的に理解できるようにしますか? このシステムは何に使用できますか? 何ができないのですか？システムは誰に依存しているのでしょうか? 3. システム構築者が正式な開始前にシステムの境界と範囲を明確にするのを支援し、関係者とのシステムの範囲の議論と改善を容易にします。
ユースケース図
これは、システムの参加者、システムに含まれるユースケース、およびそれらの間の関係を定義します。
以下は、市内高速システムのユースケース図です。
ユースケース図の役割:
ユースケース図は要件分析の結果であり、主な機能は参加者とユースケースの関係を記述することです。 、開発者がシステムの機能を視覚化するのに役立ちます。ユースケース図の助けを借りて、システムユーザー、システムアナリスト、システム設計者、およびドメイン専門家は視覚的な方法で問題について話し合うことができ、多くのコミュニケーション障壁を軽減し、問題についての合意を促進します。
ユースケース図はシステムの要件を視覚的に表現し、直観性と標準化という利点を持ち、純粋なテキスト記述の欠点を克服します。
ユースケース方式とは、システムの機能を外部から完全に定義するもので、要件と設計を完全に分離します。さまざまな機能がシステム内でどのように完結しているかは気にする必要がなく、システムは私たちにとってブラックボックスです。
状態図
イベント応答に基づいて、システム内のエンティティの動的な動作または状態遷移を記述します。
以下は、市内高速システムの順序状態図です。
状態図の役割:
状態図は状態間の遷移シーケンスを明確に記述し、イベントの実行シーケンスは状態遷移シーケンスを通じて明確に見ることができます。
状態図がなければ、外部イベントの法的な順序を説明するために必然的に多くの言葉を使用する必要があります。
イベントの順序が明確であれば、プログラマーはプログラム開発時にイベントの順序におけるエラーを回避できます。
システムシーケンス図
オブジェクト間で送信されるメッセージの時系列シーケンスを記述するために使用され、複数のオブジェクト間の動的なコラボレーションを示します。
以下は、都市内特急システムにおける注文取得のシーケンス図です。
シーケンス図の機能:
シーケンス図は、特定の時間範囲内のオブジェクト間の対話とメッセージ送信を示すために使用されます。シーケンス図は、システムの動作や、さまざまなオブジェクトが特定の機能を実行するためにどのように連携するかを視覚化し、理解するのに役立ちます。これは、ソフトウェア システムを分析、設計、理解するのに非常に貴重です。
システムアクティビティ図（フローチャート）
これは、システムのアクティビティ、意思決定ポイント、分岐などを記述するために使用されます。
以下は、受注獲得のための市内高速システムのビジネス アクティビティ図です。
アクティビティ図機能:
アクティビティ図は、主にビジネスを説明するために使用されます。システム内のロジック、ワークフロー、操作シーケンス。アクティビティ図は、特定のコンテキストにおけるさまざまなアクティビティ間の動的な関係とプロセス制御をグラフィカルに示します。システムの動作や動作シーケンスを深く分析し、設計段階で要件やロジックを明確にするのに役立ちます。
注: 実際の開発活動で最もよく使われるのはアクティビティ図であり、一般にアクティビティ図を描くことは頭の中でプログラム開発を行っていることに相当します。
4. 非機能要件
要件分析では、システムの非機能要件も確認し、要件分析の出力に出力する必要があります。
非機能要件に関する一般的な考慮事項:
- タスク完了の速度
- 結果の精度
- 運用上のセキュリティ
- 製品容量
- 許可される値の範囲
- スループット (tps など)
- リソース使用効率
- 信頼性
- フォールトトレランスと堅牢性
- スケーラビリティ
- スケーラビリティ
次回は、非機能要件の収集と生成プロセスを紹介します。