GRASP ソフトウェア開発モデルに関する簡単な説明

あなたは優れたソフトウェア開発者ですか?グラスプってご存知ですか？ GRASP ソフトウェア開発モデル (正式名は General Responsibility Assignment Software Patterns) は、有名なソフトウェア モデル GoF (Gang of Four、私たちがよく呼ぶ 23 のソフトウェア開発モデル) と同じくらい有名なもう 1 つのソフトウェア開発モデルです。ただし、GoF とは異なり、特定のソフトウェア組織構造を提案するのではなく、実際のビジネス機能をソフトウェア開発の特定のオブジェクトに抽象化するプロセスで従うべきいくつかの基本原則を提案します。これらの基本原則に従うことによってのみ、高品質のソフトウェアを開発することができます。開発したいソフトウェア プロジェクトでは、ファクトリー パターン、シングルトン パターン、オブザーバー パターンを使用する必要はありませんが、ソフトウェア開発において、現実世界のビジネス機能を特定のオブジェクトに抽象化しないことは不可能です。この観点から、ソフトウェア開発の品質を向上させるには、GoF の深い理解よりも GRASP の深い理解が重要です。しかし、GoFを紹介する記事が多く、GRASPを紹介する記事は少ないようです。このため、今回は GRASP を紹介します。 GRASPには9つの基本原則である9つのパターンが含まれています。これについては、ソフトウェア設計の第一人者であるクレイグ・ラーマンによる古典的な書籍『UML とパターン・アプリケーション』で詳しく説明されています。 GRASP は一般責任割り当てソフトウェア パターンと呼ばれます。GRASP を理解するには、なぜオブジェクトの分析および設計プロセス中に責任を割り当てる必要があるのか​​を理解する必要があります。

1. 責任の割り当てと責任主導の設計

ソフトウェア プロジェクトの開始時には、通常、顧客がどのような種類のソフトウェアを設計する必要があるか、ソフトウェアにどのような機能が必要かを理解するために要件分析を行う必要があります。要件分析では、現実世界で顧客が必要とするビジネス機能を理解します。多くの場合、各ビジネス機能はビジネス プロセス、つまり顧客が日常業務で完了し続けるビジネス プロセスです。同時に、ユーザーの問題の世界には、相互に関連するいくつかの事柄や事柄が存在するはずです。
ソフトウェアレビュー管理システムを例に挙げます。レビュー管理システムのビジネス要件は次のとおりです。
1.レビュー主催者はレビュー計画を作成し、リーダーに提出して承認を得た後、電子メールでレビュー担当者に通知します。
2.レビュー担当者には、レビュー オブジェクトをそれぞれレビューし、レビュー フォームに記入し、レビュー オブジェクトに関する質問を提起するように通知されます。
3.レビュー主催者はレビュー担当者の質問を要約し、レビュー会議を開催してこれらの質問について議論します。会議では、問題になった質問もあれば、問題にならなかった質問もあり、まだ確認できない質問もあった。
4.会議後、審査主催者が質問を整理して審査報告書を作成し、審査員による審査の合否の投票を行います。最後に、レビュー主催者は投票結果を要約し、レビューの結論を作成します。
5．レビューの主催者は問題の解決策を追跡します。
上記の要件の説明を通じて、レビュー主催者、レビュー計画、レビュー担当者、レビュー対象、レビューフォーム、質問、レビューレポート、レビュー結論、質問など、問題の世界全体から関連するものを見つけるのは難しくありません。たとえば、レビュー計画とレビュー担当者は 1 対多であるのに対し、レビュー報告書とレビュー結論は 1 対 1 であるなど、これらの関係を分析することは難しくありません。 RUP では、ビジネス要件はユース ケース モデル
とその記述ドキュメントのユース ケースを形成し、物事とその関係はドメイン モデルのオブジェクトを形成します。もちろん、ユース ケース モデルとドメイン モデルをどのように作成するかは範囲を超えています。この記事に興味があれば、友達は関連記事を読むことができます。 ドメイン モデル内のオブジェクトは、ソフトウェア開発で特定のオブジェクトを形成するための基礎になります (ソフトウェア開発でどのようなオブジェクトが形成されるかは、ソフトウェア開発の特定のニーズに従って決定され、必ずしもドメイン モデルのオブジェクトと一致する必要はありません)ドメインモデル）。ユース ケース モデルのユース ケースは、これらのオブジェクトに動作を割り当てることによって実装されます。ここで、ユース ケース モデル内の関数、または一連の動作をこれらのオブジェクトにどのように割り当てるべきかという疑問が生じます。つまり、同じタスクを完了するために、動作 A をオブジェクト X またはオブジェクト Y に割り当てることができます。動作 A の具体的な実装は、それをオブジェクト X に渡すときとオブジェクト Y に渡すときで異なりますが、どちらも動作 A のタスクを完了できます。それでは、オブジェクト X またはオブジェクト Y に渡すべきでしょうか?基本的な原則はありますか？そう、それは責任に応じてタスクを割り当てることです。理論的には、オブジェクトを任意に定義したり、オブジェクトを無意味にしたり、任意の作業を完了したりできますが、通常はそのように設計しません。通常、レビュー計画オブジェクトやレビュー担当者オブジェクトを設計するなど、オブジェクトを現実世界のオブジェクトに接続します。そして、オブジェクトを設計する際には「表現差の少なさ」を実現する必要があります。表現の差異が少ないということは、設計するオブジェクトが現実世界のオブジェクトと可能な限り一致する必要があることを意味します。たとえば、現実世界にはレビュー担当者が存在するため、「レビュー担当」というオブジェクトを設計します。同時に、レビューアー オブジェクトに割り当てる動作は、レビューアーの追加、レビューアーの変更、レビューアー情報の取得など、現実世界と可能な限り一致する必要があります。したがって、このオブジェクトにどの動作を割り当てる必要があるかは、責任によって決定する必要があります。 現実世界の分析またはドメインモデルの分析を通じてソフトウェアシステム内のオブジェクトを設計します。このとき、各オブジェクトに責任を割り当てる必要があります。オブジェクトの責任は何ですか? もちろん、それは現実世界とこのオブジェクトが完了すべきタスクの分析を通じて定義されます。たとえば、レビューアー オブジェクトの役割は、レビューアーに関連するデータにアクセスすることです。もちろん、オブジェクトの責任は必ずしも同じではありません。たとえば、レビュー計画にはレビューオブジェクトとレビュー担当者のサブ項目が含まれているため、レビューオブジェクトとレビュー担当者の情報アクセスを代理で処理できます。仕事が忙しくないときにオブジェクトを確認してください。ただし、オブジェクトの責任が多すぎてはならず (2 つまたは 3 つだけ)、関連性が高くなければなりません。たとえば、評価フォームのオブジェクトに、評価フォームを処理し、評価計画のデータも処理する責任が割り当てられている場合、これは責任独立と呼ばれます。
責任の分散は、現在、優れたソフトウェア設計が従うべき原則として認識されています。これには次の利点があります。
1.ソフトウェア開発は 1 人で行うものではないため、表現の違いが少ないため、ソフトウェアが明確に構造化され、理解しやすくなります。複数の人々が開発するソフトウェア プロジェクトでは、明確なソフトウェア構造により、開発者の誤解によって引き起こされる不要なエラーを回避できます。
2．保守と変更が簡単です。レビュー計画に問題がある場合、または修正が必要な場合は、レビュー担当者に問題がある場合はレビュー担当者に行きます。他人とは一切関係ありません。 。
このように、オブジェクト、責任、コラボレーションを考慮したオブジェクト設計とコンポーネントのアプローチを「責任駆動設計 (RDD)」と呼びます。責任駆動設計では、まずユースケースモデル、ユースケースモデルの説明、運用契約、システムシーケンス図、ドメインモデル、用語集を設計し、次に分析モデルと設計モデルを段階的に作成し、それぞれの相互作用図とクラス図を作成します。ここでは複雑なプロセスについては詳しく説明しません。ただし、非常に重要な点に注意してください。ソフトウェア システム内のオブジェクトは現実世界から抽象化されており、オブジェクトの定義に基づいて、いくつかの関連性の高いタスクが割り当てられます。ただし、これらの原則に従ったとしても、依然としてかなりの設計の柔軟性があり、同じ機能に対しても人によってそれぞれの理解に基づいて異なる設計が行われます。 GRASP は中国語で「一般責任割り当てソフトウェア パターン」と訳され、オブジェクトの分析と設計における責任割り当ての問題に関するいくつかの基本原則を提唱しています。同時に、これらの基本原則はある程度把握しておく必要があり、すべての状況に適用できるものではなく、絶対的な指標でもありません。たとえば、低結合は絶対的な非結合を意味するわけではありません。結合がなければ、ソフトウェアの凝集性を無限に高くすることはできません。そうしないと、システムが複雑になり、異常になります。

2. GRASP パターンを 1 つずつ分析

GRASP ソフトウェア デザイン パターン には 9 つのパターンが含まれています: Creator、Information Expert、Low Coupling、Controller、High Cohesion、Polymorphism、Pure Fiction、Indirect Sex、Prevent Mutation 。

以上がGRASP ソフトウェア開発モデルに関する簡単な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。