デザイン/ホワイトボードのセッションがあるときは、正しい UML を生成しようとしますが、よく構造化されたUMLを作成しようとすると、常に UMLのように見えますが、部屋にいる人には少し説明があれば理解できるものになります。しかし、完璧なエンジニアにとってこれで十分でしょうか? ホワイトボードセッションでは、常によく構造化された UML を作成していますか? 設計パターンの本でそれを見て、wtf が進行中であることを知らないのではないかと考える開発者に、どのようなアドバイスがありますか。
質問する
699 次
3 に答える
6
デザインセッションでUMLを使用することはありません。常に自由形式です。次に、プロジェクトに応じて、開発者がコーディングする「最終的な」仕様ドキュメントを作成するときに、それを元に戻して、はるかに構造化されたUML設計に変換します。私の経験では、特に部屋にいる人の半数以上が図表の意味を理解していない場合、適切な形に焦点を合わせるためにデザインセッションを妨げる傾向があります。
于 2009-10-08T16:18:21.697 に答える
1
ソフトウェア エンジニアリングについては多くの議論があり、それが必要かどうかは、開発しているシステムの種類によって異なります。システムの要件が曖昧であるほど、SE のツールとテクニックが必要になります。
UML は、クライアントが内部システムの全体像を把握するのに役立ちます。これは、ユースケース図がある場合です。わからない人がいるのも事実ですが、ユースケース図を特別に説明するととてもわかりやすいです。次に、設計する必要がある最初の主要なクラスとパッケージを把握するのに役立つクラス図を作成します。他の UML 図はそれほど重要ではありません。
これは、クラス図とユースケース図をオンラインで数秒で作成するのに役立つ簡単な Web サイトです。
この 2 つのダイグラムを使用せずに中/大サイズのプロジェクトを行ったことはありません
于 2009-10-08T17:12:41.243 に答える
0
厳密な UML は必要ないと思います。
誰もがデザインを理解し、それを認める限り、それは問題ありません。私は、すべてを決定してゼロから変更できないよりも、実行中にプロジェクトをプロトタイプ化/テストし、「厳密ではない」仕様を変更できるアジャイルな方法論を好みます。
現実の世界では、最も入念に計画された UML 仕様でさえも驚くことがあります
于 2009-10-08T17:11:30.670 に答える