ユースケースを最初に行うか、クラスを最初に行うのが正しいアプローチはどれですか？どうして？
最初にユースケースを実行してからクラスを実行することを好む人もいますが、クラス図を最初に実行してからユースケースを実行することを好む人もいます。それで、それは便宜のために個人的な選択ですか？上記の方法の長所と短所は何ですか？
ユースケースは、解決する問題の説明であるため、プロセスの他のステップの前に行う必要があります。
問題を知らずに何か意味のあるものにすることは不可能だと私は主張したい。
コードを書く前にクラス図を作成するかどうかは、ユースケースによって設計内容が決まりますが、個人的な好みです。
あなたはそれについて言及するのを「忘れた」のですが、UMLを使用して新しいソフトウェアの要件を収集することについて話していると思いますよね？
これの最初のステップは常にユースケースを理解することだと思います（そして私は派手なユースケース図について話しているのではなく、ユーザーのビジネスプロセス、ユーザーが行っていること、および新しいソフトウェアをユーザーの作業に統合する方法）。これは、人々にインタビューしたり、観察したり、協力したりすることで実現できます。
このプロセスの結果を安全にするために、ユースケース図を組み込むことを試みることができますが、これらの図は、前のステップで学習したことの非常に高レベルの抽象化のみを提供します。したがって、ユースケースにはより詳細な説明を追加する必要があります。この説明では、他のツールを利用できます。
- 自然言語でのプロセスの口頭による説明
- シナリオ例（「ユーザーストーリー」とも呼ばれます）
- 非常に詳細なレベルでビジネスエンティティとデータをモデル化するためのクラス図
- " ドメイン駆動設計 "のようなドメインモデルの形式としてのクラス図
- データフロー図（UMLにはまだありません）
- UIドラフト
- テストケース
- 他のUML図（IMHOが実際に役立つことはめったにありませんが）
- [...]
したがって、システムの高レベルの概要をモデル化することが仕事である場合は、最初にユースケース図を作成し、それぞれに多かれ少なかれ小さな説明を付けます。処理されるデータが属性レベルまでモデル化される特定のユースケースの詳細を具体化する場合は、1つのユースケースから始めて、多くの詳細なボトムアップモデリングを実行できます（おそらく次のユースケースに進む前に、クラス図を多くのツールの1つとして）。したがって、モデリングの順序は、割り当てられたタスクの内容と、分析する必要のあるソフトウェアの大きさと複雑さによって異なります。
過去の多くのソフトウェアプロジェクトは、完全に過剰分析されたために失敗したことに注意してください-最初にコード行を作成せずに数か月にわたって作成された数百ページの仕様（もちろん、他のプロジェクトはまったく分析されていなかったため失敗しました）。適切なバランスを見つけることが重要です。また、ほとんどのソフトウェアシステムはリリースごとに作成されるため、バージョン1.0の要件を収集するタスクは最初のステップにすぎないことにも注意してください。バージョン2、3、4、5の場合、通常、以前のバージョンと比較して追加の要件のみを説明する必要があります。多くの場合、一連のユースケースはリリース間でほぼ安定していますが、バージョンnとn +1の詳細な違いは興味深いものです。したがって、バージョン1.0の運用開始後は、通常、ユースケース図よりも詳細なユースケースの説明のために上記のツールの方が重要になります。
最初のユースケースは正しいアプローチです。なぜなら、私たちの前にたくさんのソフトウェアエンジニアがすでに知っているからです。
最初にコーディングすることを好み（クラス図）、後でコーディングすることを好み（ユースケース）、それでも重要な動作ソフトウェアを作成できる人のことは聞いたことがありません。それどころか、それだけで完全に失敗したり、予算が足りなくなったりするプロジェクトがたくさんあると聞いています。
しかし、おそらく私はあなたの質問の本来の意図を誤解しました。
いくつかの「最初のクラスの短所」は次のとおりです：学んだ教訓、フルサイズの画像は プロジェクトの実際の仕組み-http：// www。 projectcartoon.com
いくつかの「最初のユースケースの長所」は次のとおりです。文献が推奨しているため。
スコットW.アンブラーのオンラインブック「アジャイルモデリング」の章 「想定される要件：アジャイルのベストプラクティス→最初に何をモデル化する必要がありますか？」 は次のように述べています。
システムの最初のリリースでは、いくつかの高レベルの要件とリリースの範囲（システムが行うべきだと思うこと）を特定するために数日かかる必要があります。目標は、プロジェクトが何であるかをよく理解することです。最初の要件モデルの場合、私の経験では、次の形式が必要です。
- 使用モデル
- ドメインモデル
- ユーザーインターフェイスモデル
3.1使用モデル
使用モデルを使用すると、ユーザーがシステムをどのように操作するかを調べることができます。これは、ユーザーが何を必要としているかを理解するために絶対に重要です。使用モデルは、基本的なユースケースまたはシステムのユースケースのコレクションである場合があります...
3.2ドメインモデル
特にビジネスアプリケーションの場合、最初のモデリング作業の一部には、概念ドメインモデルの開発が含まれる可能性があります。このモデルは非常にスリムで、主要なビジネスエンティティとそれらの間の関係をキャプチャする必要があります...モデルは完全である必要はなく、主要なビジネスコンセプトに慣れるために十分な情報をカバーする必要があります...
3.3ユーザーインターフェイスモデル
ユーザーインターフェイス（UI）は、ユーザーが直接対話するソフトウェアの一部です。ほとんどの利害関係者にとって、UIはシステムであるため、プロジェクトの最初の成功には、利害関係者がUIに期待することを確実に理解することが重要です。 UIの要件を調査する1つの方法は、エッセンシャルUIプロトタイプと呼ばれるものを作成することです。これは、抽象プロトタイプまたはペーパープロトタイプとも呼ばれます...