2012-04-23 8 views

答えて

1

クラスとその中のプロパティ/メソッドの詳細の関係は、システムが何をしようとしているのかとは無関係です。システムがどのようにその仕事を行うのかとbtu。 このため、私はUMLクラス図を設計仕様に入れました。

さらに、私は通常、クラス図全体を設計仕様に入れるのではなく、特定のトピック(システム全体のサブタスク)に焦点を当てたものもあれば、その一部を配置します。 私は、アプリケーションを設計するためのクラス図(およびシーケンス図)を最初に使用していますが、それを文書化するのではなく、自分の考えを明確に見ています。クラス図は、リファクタリング

+0

ありがとうございます。 –

1

これは設計仕様のものです。機能仕様では、ソフトウェアが何をしなければならないか考えたいと思っています。設計仕様では、コードのユーザインタフェースのモックアップだけでなくUMLのドラフトも開始できます。

役に立ったと思っています。

+0

ありがとうございます。 –

2

他の回答の論理に同意しないでください。関連性があるかもしれないし、そうでないかもしれない別の考え方もある。

クラス図が問題のドメインをモデル化している場合(例:Domain-Driven Design)、問題ドメインの言語を定義するためのより基本的な目的を持つことができます(DDDの用語では「ユビキタス言語」)。

これは、(ソフトウェア)設計の人為的なものではなく、実際には公式化された用語集です。そのように、それは機能仕様で使用される用語を定義します。

オンラインショッピングシステムの例をご覧ください。あなたの機能的な要件は、「商品を購入する」、「買い物カゴに商品を置く」、「チェックアウトする」などについて話します。これらの用語(商品、商品、買い物かご)は暗黙的に定義されています。しかし、それらを関連付けるルールはどうですか?たとえば、一度にショッピングバスケットに入れることができる商品はいくつですか?チェックアウトしたい場合は、すべてのアイテムを一回の支払いで支払う必要がありますか?または分割することはできますか?

これらの種類のルールは、クラス図で形式化することができます。そのため、機能要件の非常に有用なコンポーネントとなります。

(a)クラス図の内容、(b)&あなたの要件の利害関係者が、それがもたらす用語の明確さから恩恵を受けるかどうかにかかっていますか。

私が言ったように、別の見通し。

hth。