私が大学にいたとき、ある講師がシーケンス図を使ってコードを書いている人がいると言いました。私にはこれはプログラミングの良い方法のように思えますが、もちろん悪魔は細部に宿っています。いくつかの質問を聞きたいんです。
- これは実際に起こっているのでしょうか、それとも私が彼の言ったことを誤解していたのでしょうか?
- ここに実際にこれをやった人はいますか?
- それはより生産的ですか?
- 短所は何ですか?
- Java を使用する場合、どのようなツールが必要ですか?
私が大学にいたとき、ある講師がシーケンス図を使ってコードを書いている人がいると言いました。私にはこれはプログラミングの良い方法のように思えますが、もちろん悪魔は細部に宿っています。いくつかの質問を聞きたいんです。
「通常の」シーケンス図は、ほとんどの場合、価値があるよりも面倒であることがわかりました (ただし、LINQ でデータ フローを示すのに役立つことはわかっています)。私の経験では、「ラフで準備が整った」図を作成して説明する方がうまくいきます(できれば直接、しかしどちらにしてもたくさんの言葉を使って)。
アプリケーションの一種の「垂直スライス」を示す図 (または複数) を用意することをお勧めします。各レイヤーが別のレイヤーとどのように通信するか、適切なケースでの要求/応答の過程を示すことができます。ただし、これは「個々のメソッド呼び出しで常に 100% 正確」なレベルである必要はありません。読者が実際のコードに飛び込むことができると仮定すると、正しい一般的な印象を伝えることがより重要になります。
以上のことをすべて述べたとしても、UML に対する私の見解は一般的にほとんど同じです。そのため、正確な図が常に現実と細心の注意を払って同期されていることなどの大ファンである場合は、すべてを少しだけ理解してください :)
シーケンス図は、スレッド間で多数のメッセージが渡される複雑なマルチスレッド プログラムを視覚化するための最良の方法の 1 つだと思います。設計ではあまり使用しませんが、デバッグするのに最適な方法である場合があります。
以下の理由により、シーケンス図は実際のアプリケーションには不十分であることがわかりました。
制御のスレッドが 1 つしかない場合、レイヤーからレイヤーへの呼び出し階層を説明する英語のアウトラインを使用すると、うまくいくことができます。ここでは、MS Word のアウトライン スタイルが適切に機能します。
私の英語の説明は、UML の図よりも詳細であり、場所を取りません。
英語を使えば、ガード条件やループなどの他の詳細をシーケンス図よりもうまく説明できます。
UML を作成するよりもアウトラインをすばやく作成できます。
これほど詳細な「図」が本当に必要な場合は、おそらくアクティビティ図が役に立ちます。
一方、シーケンス図は、高レベルの概要を把握するのに最適です。
Java に関する限り、私のプロジェクト チームは、Java 5 コードベースのクラス階層をリバース エンジニアリングできるJudeをとても気に入っています。
シーケンス図は相互作用を示します。これは通常、コード内の単一のパスです。一方、コードはすべてのパス、すべての if-then-else やエッジ条件などを定義する必要があります。これらすべてをシーケンス図で示すことはできますが、複雑すぎて扱いにくくなる傾向があります。シーケンス図が役立つ場合は、設計段階でコードを視覚化するためにシーケンス図を使用することをお勧めしますが、それはおそらく必要な範囲です。
シーケンス図にはその場所があります。UML ダイアグラムをコードの変更と同期させることについて心配したことはありません。そうは言っても、私はブレインストーミング ツールとしてシーケンス図を使用するのが大好きです。チームが基本的なプロセスと呼び出し構造を理解し、同意する必要があります。引数とインスタンスの作成も追跡すると、理解の穴が浮き彫りになります。引数としてデータ 'x' が必要な場合、それは既にローカルであるか、渡される必要があります。"データベースからレポート データを要求しており、レポート タイプを送信する必要があります。入力パラメータですよね?
これは、デザインのハイレベル パスで機能します。その後、後発者向けの一般的なドキュメントとして機能します。彼らはあなたがどこに向かっていたのかを理解し、コードを見たときに変更にそれほど混乱することはありません.
シーケンス図は手続き型言語で機能します。オブジェクト指向言語にはあまり役に立ちません。