私は大学の教授とUML図についてこの議論をしました。彼は、クラス図に入る前にシーケンス図を描くべきだと信じていますが、私は反対だと思います。ユースケース図が完成したら、次の図はクラス図になり、その後はシーケンス図になります。Rational roseでは、すでにクラス図にあるシーケンス図のクラスを使用する必要があります。
誰かがこれを手伝ってくれますか?
私は大学の教授とUML図についてこの議論をしました。彼は、クラス図に入る前にシーケンス図を描くべきだと信じていますが、私は反対だと思います。ユースケース図が完成したら、次の図はクラス図になり、その後はシーケンス図になります。Rational roseでは、すでにクラス図にあるシーケンス図のクラスを使用する必要があります。
誰かがこれを手伝ってくれますか?
お二人とも間違っていると思います。それらは同時に描画する必要があります。シーケンス図を描いていると、状態を追跡するために必要なプロパティや、クラス図を単独で作成した場合には思いもよらなかったプロパティを思いつくことは間違いありません。
もちろん、これは非常に主観的で個人的なものですが、長年の現実世界での経験 (学問的な理論とは対照的に) から、両方に同時に取り組むことを学びました。クラス図から始めることもあるかもしれませんが、プロセス フローを開始すると、クラス図は常に変化します。
それは、物事をどのように計画するかによって大きく異なります。主観の問題だと思います。ユースケースに対して実行されるアクションを説明し、これが完了した後、シーケンスを実行するために必要なものに基づいてクラスを作成する場合、教授は正しいです。
しかし、クラスの構造を決定し、アクション シーケンスをこれに適合させたい場合は、最初にクラス図を作成し、後でシーケンスを作成します。
私の経験では、それらを同時に行います。クラス図には基本的な属性を配置しますが、アクションには配置しません。また、シーケンス図を作成しながら、必要なメソッドと属性をクラス図に追加します。
シーケンス図を準備するには、クラス図ではなくクラスが必要です。シーケンス図の準備中に、その場で空のクラスを準備できます.... 識別クラス オブジェクトは、シーケンスの準備の一部であるか、事前にオブジェクトの識別を試みることができます。 ...シーケンスは論理プロセスであり、クラス図は最終出力です
標準的な答えは 1 つではありません。いくつかの意見、アプローチ、方法があります。統合プロセスでは、最初にユース ケースを特定し、次にそれらを実現する (シーケンス図など) と考えています。ユース ケースの場合と同様に、シーケンス内で相互作用するアクターとシステムおよび/またはそのパーツが存在します。実際、この相互作用は、設計を分解してクラスに到達するのに役立ちます。分析レベルでクラスを作成したら、クラスの設計と相互作用の設計にさらに進むことができます。ただし、これらはダイアグラムに描画するのが非常に多く、ほとんどの場合、コードはこのレベルで最高のドキュメントです。生成されたダイアグラムでさえ大きすぎて、コード自体を理解するのがより困難です。
どちらもシステムの2つの異なるビューであるため、図を作成する順序はないと思います。クラス図は構造的(静的)であり、シーケンスは動作的(動的)です。シーケンスを実行するにつれて作成するクラスが増えるので、シーケンス図から始めます。その時点であなたにとって意味のあることは何でもしてください。よりオブジェクト指向プログラミングを行う場合は、シーケンスの前にクラスを実行することを検討します。
最も単純なシステムを除くすべてのシステムの構造モデルと動作モデルは、自然に同時に反復的に作成され、時間の経過とともに両方が洗練されます。
CRCカードなどの「オブジェクト検出」の方法がある場合があります。これにより、コラボレーション(相互作用するクラス)と責任を備えた一連の初期クラスが生成され、必要な方法と内部の動作/状態の両方が通知されます。 /アクティビティ。
次に、シーケンス図または通信図を使用してユースケースとシナリオを調査します。これにより、必要なオブジェクト通信の詳細が公開されるため、パブリックメソッドと関係の生成に通知して、クラス図を改良すると同時に、システムの動作を調査します。これにより、作成されるオブジェクトとクラスがさらに生成される可能性があります。
また、クラスの内部動作を調査することもできます。特に、クラスがステートフルおよび/またはアクティブな動作をしている場合はそうです。これには、アクティビティとステートマシン図が役立ちます。
いずれにせよ、RationalRoseの使用が実際にダイアグラムの作成順序の決定要因であるとは思えません。Rationalでは、シーケンス図のクラスが存在する必要がある場合がありますが、実際にクラス図に表示される必要はないと思います。それらはおそらくシーケンス図で同じように作成し、後でクラス図に配置するか、プロジェクトエクスプローラーまたはそのツールにある同等のもので作成することもできます。クラスを作成する唯一の方法がクラス図に配置することである場合でも、シーケンス図で相互作用を調べる前に、クラスまたはその関係を改良して完了する必要はありません。
最初にアプリケーション フローを決定する必要があります。つまり、最初にシーケンス図を描く必要があります。この後、アプリケーションのフローが表示されます。クラス図に進む必要があります。
いくつかの服を購入する必要があります。最初に服を選び始めますか、それともどこに行くかを最初に決めますか? 同時に、シャツを買いたいなら靴屋に行きますか。
したがって、どちらも反復的ですが、間違いなく最初のステップは非常に高い (コンポーネント) レベルでのシーケンスであり、次にクラス レベルのシーケンスにドリルダウンします。