開発しなければならないソフトウェアのドキュメントを書いています。私はVモデルを尊重しています:
http://sqa.fyicenter.com/FAQ/Software-Development-Models/models_1.JPG
私の質問は、機能仕様または設計仕様のどこでUMLクラス図を使用する必要があるかということです。
開発しなければならないソフトウェアのドキュメントを書いています。私はVモデルを尊重しています:
http://sqa.fyicenter.com/FAQ/Software-Development-Models/models_1.JPG
私の質問は、機能仕様または設計仕様のどこでUMLクラス図を使用する必要があるかということです。
クラスとその中のプロパティ/メソッドの詳細との関係は、システムが何をするかとは関係ありませんが、システムがどのように仕事をするかとは関係ありません。このため、UMLクラス図を設計仕様に入れました。
さらに、私は通常、クラス図全体を設計仕様に入れることはしませんが、特定のトピック(システム全体のサブタスク)に焦点を当てたその一部(ある場合)も含めます。私は主にクラス図(そしてもちろんシーケンス図)を使用して、ソリューションを明確に理解できるようにアプリケーションを設計しますが、それを文書化するためには使用しません。クラス図は、主にリファクタリングのために、最初から変更される可能性があります。 。
他の答えの論理に異議を唱えないでください。これは、関連する場合と関連しない場合がある別の視点です。
クラス図が問題のあるドメインをモデル化する場合(たとえば、ドメイン駆動設計など)、問題のあるドメインの言語(DDD用語での「ユビキタス言語」)を定義する上で、より基本的な目的を持つことができます。
つまり、(ソフトウェアの)デザインアーティファクトではなく、実際には形式化された用語集です。そのため、機能仕様で使用される用語を定義します。
オンラインショッピングシステムの例を見てみましょう。機能要件では、「商品の購入」、「買い物かごへの商品の配置」、「チェックアウト」などについて話し合う可能性があります。これらの用語(製品、アイテム、買い物かご)は暗黙的に定義されています。しかし、それらに関連するルールはどうですか?たとえば、一度にいくつの商品を買い物かごに入れることができますか?チェックアウトする場合、すべてのアイテムを1回の支払いで支払う必要がありますか?それとも分割できますか?
これらの種類のルールはクラス図で形式化できるため、機能要件の非常に便利なコンポーネントになる可能性があります。
それがあなたに適用できるかどうかは、(a)クラス図の内容、および(b)あなたとあなたの要件の利害関係者がそれがもたらすことができる規則と用語の明確さから利益を得るかどうかに依存します。
私が言ったように:別の視点。
hth。
これはもっと設計仕様のものだと思います。機能仕様では、ソフトウェアが何をしなければならないかを考えたいと思います。設計仕様では、コードのユーザーインターフェイスのモックアップだけでなく、いくつかのUMLのドラフトを開始できます。
それが役立つことを願っています