記事のディレクトリ
1.ソフトウェアアーキテクチャ設計のライフサイクル
アーキテクチャは何ですか？10人に聞いてみると、11の異なる答えを得ることができます。関連する本に行くと、それぞれが異なる定義を与える可能性があります。
したがって、方法が正しく、プロジェクトのタスクを完了できる限り、黒猫でも白猫でも、マウスを捕まえることができる猫は良い猫です。 ！！
1.ソフトウェア開発プロセス
ソフトウェアプロジェクトは、プロジェクトの開始から最終的な納品まで、多くのリンクを経てきました。ソフトウェア設計のライフサイクルに固有で、次の段階を含めることができます。要件調査-要件分析-概要設計-詳細設計-アーキテクチャ検証-開発ユニットテスト-統合テスト。
上記の手順はまだ非常に大まかな概念です。実際の操作では、これらの各ステップを多くの特定の実行リンクに分割できます。
例えば：
- 需要調査：何をすべきか？どのような方法が使用されますか？指導的イデオロギーとは何ですか？いくつかの良いツールは何ですか？
- 需要分析：どのように分析する必要がありますか？すべての要件を分析する必要がありますか？重要な要件を見つける方法は？
- 詳細設計：ソフトウェアエンジニアリングでより実用的な方法は何ですか？重ねる方法は？モジュールを分割する方法は？
これらはすべて、ソフトウェア設計のプロセスに関与する必要がある問題です。では、ソフトウェア設計の究極の目標は何ですか？次のドキュメントです。
- 論理アーキテクチャ
- 物理的構造
- オペレーティングアーキテクチャ
- 開発アーキテクチャ;
2.タオルについて
この世界では、あらゆる分野、あらゆる業界を含め、あらゆるものに日常的なものがあると思います。
たとえば、新しい分野に参入するとき、車両ディスパッチングシステム、ロボット制御システムを設計したり、トランシーバー、IoTゲートウェイを設計したりできます。この分野の初心者の場合は、黒い目を持っている必要があります。 ：私はこの分野をまったく理解していませんが、どのように設計すればよいですか？
これは私に小さな話を思い出させます：
かつて私は新会社に加わり、元同僚の仕事を引き継ぎました。その際、KPI評価が実施され、バグのストレートスルー率（つまり、一度に解決されたバグの割合であり、QAスタッフが再びバグを蹴ることはありません）は重要な指標です。システム内の非常に多くのバグに直面して、リーダーは私に尋ねました：これらの問題を解決するのにどれくらい時間がかかりますか？私は言った：私はこれまで仕事のこの側面に触れたことがなく、正確な時間を与えることはできません。リーダーは言った：それは問題ではありません、あなたは私に特定の時間を与える必要があります。その時私は唖然としました。
現時点で最も重要なことは、この分野の基本的かつ重要な背景知識をすばやく理解して習得することです。では、何をすべきでしょうか？ルーチンを見つけてください！
すべてに貪欲にならないでください。関連するすべてのコンテンツを習得することを期待しないでください。これは、特に短期間では不可能です。私たちの目標は、良い仕事をしてプロジェクトを完了することです。
現時点での私の一般的なアプローチは次のとおりです。ルーチンを見つけてください。
それを言うのは少し幻想かもしれないので、例としてソフトウェア開発のアーキテクチャ設計を取り上げましょう。ソフトウェアエンジニアリングまたはプロジェクト管理の書籍や資料で、次の関連コンテンツを見つけてください。
- 他の人はどのようにアーキテクチャを設計しましたか？
- 設計プロセスにはどのようなステップが必要ですか？
- 各ステップの入力は何ですか？出力は何ですか？
- 各ステップで考慮すべき点は何ですか？
- いくつかの優れたソフトウェアツールは何ですか？
- プロジェクトの関係者（プロジェクトマネージャー、開発者、テスター、パーティーAのクライアント）とどのようにコミュニケーションをとるのですか？
より多くのこれらの人々の経験の櫛自分のためのセットにまとめ、「方法論」を実行したときに、この特定のルーチンに従って段階的に行って、その後、実際の状況タイムリーに応じて動的に調整する、一般的に、私たちはスムーズにできますプロジェクトを進めます。
3.最初に剛体、次に最適化、次に固化
これらの9人のキャラクターは、Huaweiの責任者であるRen Zhengfeiが管理システムを導入したときに提案したもので、非常に実用的な方法です。
- 剛性：巨人の肩の上に立つ：学習の初期段階での「足を切って靴を履く」。
- 最適化：自己批判の武器を習得する：自分自身を最適化するために、実際に継続的に吸収、改善、革新します。
- 固化：イノベーションは段階的かつ制約されます。制限がない場合、イノベーションは混沌とした無秩序なイノベーションです。段階的な最適化の結果を固めるために、段階的に版築のように層ごとに押し上げる必要があります。
ソフトウェアアーキテクチャの設計については、次の手順に従うこともできます。
最初のステップは剛性です。これは固定されたルーチンに従うことです。「一般通念に陥る」可能性はありますが、少なくとも正しい方向に進み、曲がらないようにすることができます。これが最も重要なことです。
他の人から「レガシー」と見なされているとはどういう意味ですか？あなたのアプローチはこの分野で最も「一般的な」作業プロセスに沿っていると他の人が考えていることを説明します。これは、あなたが本当にこの分野に入ったことを認識することと同じです。これは良いことです。
初心者として、このように評価されていることを誇りに思いませんか？結局のところ、私たちは心の中で知っています。私はこの分野に参入したばかりのシャオバイです。
4.仏陀は言った：「私が言うことを知ることは私が言うことを理解する人のようなものです」
この記事を書く目的は、主に私がソフトウェアアーキテクチャの設計をどのように「厳密に」行うかについて話すことです。
私たちが最初にソフトウェア開発業界に参入したとき、私たちの日常業務は主にコード化であり、システム全体のアーキテクチャを設計するのに十分な資格がなかったのかもしれません。しかし、これは私たちが率先して学ぶことを妨げるものではありません。機会は準備ができている人のために予約されています。ある日、建築設計の穴がプロジェクトチームに現れた場合、リーダーはどのニンジンを見つけて穴を埋めますか？
したがって、この記事では、主に最も基本的なソフトウェア設計手順と、各手順で使用されるガイドのアイデアと便利なツールを紹介します。
すでにシニアソフトウェアデザインエンジニアであれば、コーヒーを飲みながら人生を楽しむことができます。もちろん、方法論を共有することもできます。私たちはお互いから学びます。
これらの内容は私自身では発見できませんでしたが、本を読んだり、資料を探したり、プロジェクト開発の過程でまとめたりして得たもので、自分が直面しているプロジェクトに適していて、知識のポーターにすぎません。
以前は、主にソフトウェアアーキテクチャの設計に関する本をいくつか参照し、お互いに学び、自分に合った一連の方法をまとめました。前回引っ越したとき、私はたくさんの本を失い、コンピューターに断片的なメモだけを残しました。この記事の資料のソースはこれらのメモです。もちろん、ほとんどのコンテンツは本からのものです。私はいくつかのトレードオフとカットを行いました。
「金剛般若経」の6番目の記事である如来は、「あなたは僧侶を待っています。比喩のように、私が言うことを知っています。違法は言うまでもなく、法律はまだ放棄されるべきです」と言います。
だるまは、人々が川を渡る筏のようなものです。川を渡って岸に着いたら、いかだを捨てて、心の中でいかだについて考えるのをやめるべきです。いかだはだるまのようなもので、だるま以外のものは言うまでもなく、だるまは捨てるべきです。なぜあなたはまだ彼と絡み合っているのですか。
したがって、ここで説明している設計ルーチンは、ソフトウェアアーキテクチャ設計に最初に入るときに役立つ足場であるいかだにも似ています。2番目の層の「最適化」に入ると、足場を捨てることができます。
その時、あなたは自信を持って言うことができます：「ダオ兄弟が書いているのは、書くこと、小児科についてです。私はより高度なランクを探求する必要があります。」この度、心よりおめでとうございます！
2.需要調査と需要分析
ほとんどの人は「需要がアーキテクチャを決定する」ことに同意しますが、要件はどのようにアーキテクチャを決定するのでしょうか。この部分で私の理解について話しましょう。
プロジェクトの承認段階で、運が良ければ、「ソフトウェア機能要件仕様」というドキュメントを入手できる場合があります（一部の日本企業の要件仕様については、実際にはひねくれた詳細なものです）。運が悪ければ、ドキュメントはありません。すべての要件を自分で収集して並べ替える必要があります。
狭義には、需要は関数です。広義には、品質属性や条件付き制約などの非機能要件も含まれます。
1.機能要件
機能要件の部分は最も直感的であり、それは私たちが設計するソフトウェアが達成する必要があるものです。システムでは、さまざまな機能の間に明確な境界はありません。各小さなモジュール間の特定の相互作用を通じて、指定された機能を完了するための「協力チェーン」が形成されます。
たとえば、次の図は私が以前に書いた記事です。IoTゲートウェイの開発：MQTTメッセージバスベースの設計プロセス（オン）、異なるモジュール間の相互作用モデル、赤と青の部分は2つの異なるコラボレーションチェーンです。
もちろん、この図は最終的に設計されたシステムアーキテクチャ（階層化されたサブモジュール）です。この図を取得する前に、まずすべての機能要件を収集して整理する必要があります。
この段階で最も重要なことは、どのように行うかではなく、何をするかです。さらに、デザイナーとして、あなたは自分自身に頻繁に質問する必要があります：あなたは不完全ですか？抜けはありますか？
2.品質属性
さまざまな段階に従って品質要件を分類できます。
開発段階
- 再利用性、繰り返し作業を行わないでください。
- 柔軟で拡張が容易（要件が変更されたときの開発者の心理的活動について考えてください）。
- 理解しやすい（他の人のプロジェクトを引き継ぐときを考えてください）;
- 便利なテスト（単体テスト、統合テスト）;
- ポータブル（特に組み込みプロジェクト、異なるプラットフォームで実行する必要があります）;
運用フェーズ
- システムは信頼できるものでなければなりません。
- パフォーマンスは特定の要件（スループット、応答時間など）を満たす必要があります。
- 抜け穴なし、システムセキュリティ。
- 拡張と展開を容易にするために、スケーラビリティは良好である必要があります。
3.制約
制約は主に、次のようないくつかの制限条件を指します。
- チームメンバーの技術スタック（全員がCを使用している場合は、C ++を選択しないでください）。
- リーダーから提供されたリソースは何ですか。
- オープンソースソフトウェアを使用している場合、バグはありますか？二次開発に便利ですか？
- プロジェクト開発サイクルはどのくらいですか？
- ソフトウェアのオペレーティングプラットフォームは何ですか？制限は何ですか？
4.ユースケース図を描く
ユースケース図の概念については、うまくまとめることができないので、BaiduZhiliの定義を直接引用します。
ユースケース図は、アクター（アクター）、ユースケース（ユースケース）、境界、およびそれらの間の関係で構成されるビューを参照して、システム機能を記述します。
ユースケース図（ユーザーケース）は、外部ユーザー（参加者と呼ばれる）が観察できるシステム機能のモデル図です。ユースケース図は、システムの青写真です。ユースケース図は、一部の参加者、一部のユースケース、およびそれらの間の関係を示しています。これらは主に、システム、サブシステム、またはクラスの機能動作をモデル化するために使用されます。
いくつかの概念があります：
- 参加者：特に人を指すのではなく、システムの使用またはシステムとの対話においてシステム外の人が果たす役割を指します。
- ユースケース：変数を含む一連のアクションシーケンスの説明です。システムはこれらのアクションを実行し、特定の参加者の価値を伝える観察可能な結果を生成します。
- システム境界：モデル化されるシステムの境界を表すために使用されます。境界の内側はシステムのコンポーネントを表し、境界の外側はシステムの外側を表します。
- 矢印：信号またはメッセージを相互に送信することによって相互作用する参加者とシステムの間の関係を示すために使用されます。
- 役割：（1）要件の取得、（2）ガイドテスト、（3）プロセス全体の他のワークフローでガイドの役割を果たすこともできます。
いくつかのオンラインユースケース図を見つけました。それぞれが円で、関数を表しています。
ユースケース図を通して、システムが提供するすべての機能を一目で確認できます。
5.ユースケースの説明を書く
ただし、ユースケース図では、各ユースケースの実行プロセスについて詳しく説明していません。つまり、ユースケース図では、システム全体の要件について説明していますが、動作プロセスについては説明していません。
したがって、このユースケースの動作プロセスをより具体的に確認するために、ユースケースの簡単な説明または詳細な説明を各ユースケースに添付できます。
以下は、インターネット上で見られる2つのユースケースの説明例でもあります。統一された形式はなく、プロジェクトの性質に応じて増減する必要があることがわかります。
6.主要な要件を特定する
継続的な収集と分析で可能な限りすべての要件（機能要件、品質属性、条件付き制約）をリストするとします。次に何をする必要がありますか？非常に多くの要求があるので、どれから始めるべきですか？
キー要件=キー機能+キー品質。アーキテクチャの一般的な方向を決定します。
最初に明確にすることは、すべてが等しくなる必要があることは不可能であるということです。多くのユースケースから、次の3種類の要件を見つける必要があります。
- 主要な機能要件：最も多くのモジュールとモジュール間のコラボレーションの最も代表的な方法を含む要件は、主要な機能のサブセットを除外します。
- 主要な品質属性：開発段階と運用段階で、ソフトウェアアーキテクチャに大きな影響を与える品質属性はどれですか。品質属性間に競合がある場合、どちらを優先する必要がありますか。
- リスクの高い部分：技術的な難しさの観点から、技術的な実装においてリスクがあり、事前に技術的な検証を経験する必要がある機能はどれですか？
これらの3種類の要件は、私たちが焦点を当てる必要のある要件であり、次のステップ（ドメインモデリング）の入力資料でもあります。
スペースの長さから、デザインパーツの内容（ドメインモデリング、アウトラインデザイン、詳細デザイン）については、次の記事に進みますので、よろしくお願いします！
[C言語]
C言語ポインター-基本的な原則から高度なスキルまで、グラフィックとコードを使用して
、元のgdbの基本的なデバッグ原則を簡単な
ステップバイステップの分析で説明します-Cを使用してオブジェクト指向プログラミングを実装し
、コードの強力なツール：マクロ定義-エントリからあきらめまで、C言語でsetjmpとlongjmpを使用して、
例外のキャプチャとルーチンを実装します
【アプリケーションデザイン】
モノのインターネットゲートウェイの開発：MQTTメッセージバスに基づく設計プロセス（パート1）モノのインターネットゲートウェイの開発：MQTTメッセージバスに基づく設計プロセス（パート2）
プロセス間の私のお気に入りの通信方法-メッセージバス
【モノのインターネット】
暗号化と証明書に関すること
はLUAスクリプト言語に深く入り込んでおり、デバッグの原理を完全に理解することができます。
[ナンセンス]私の失敗したキャリア経験に基づく
：職場に不慣れな技術者のためのいくつかのヒント