さて、UMLダイアグラムはプログラムの構築に役立つことを理解していますが、いつ使用されますか?コーディングを始める前に必要ですか?何をコーディングする必要があるかを知るためにそれらが必要ですか?それとも、プログラムをコーディングした後でそれらを使用しますか?
7 に答える
少し違う見方をします。
アーキテクチャ/設計段階にあることが多いシーケンス図を除いて、厳密な意味でUMLを使用しません。正確で理論的なことを説明するとき、それは学界で最も役立つと思います。
毎日の仕事では、一枚の紙の上の箱や矢印が期限になります。実際に使用するのに良いルールは、手で描いた一枚の紙でデザインを説明できない場合、それは複雑すぎるということです。
私はこのテーマについていくぶん冷笑的である傾向があります...そしてUML図は決して使用されるべきではないと答えます。
UMLダイアグラムは、プログラミングを実際に理解していない人々とコミュニケーションをとる必要がある場合に使用される傾向があります。素敵なグラフィックの描画は、それらをより簡単で快適にしますが、通常は以前と同じように無知です。
私の経験では、UMLは時間の大きな損失であり、より単純で効率的な他のツールに取って代わる傾向があります。擬似コードはクラス図と同じくらい読みやすく(私にとっては簡単です)、入力もはるかに簡単です。ユースケースは、スクラムやXPのような優れたユーザーストーリーよりも効率的ではありません。など。すべての図は、コードベースやドキュメントと一緒に維持するのが面倒です。また、他の方法よりも簡単に設計エラーを描画できます(UML形式にすると、設計エラーの検出と克服がはるかに困難になります。おそらく、描画について考えるときに最も明白なエラーを回避することに同意します)。
UMLダイアグラムを描くのに多くの時間を失ったと思いますが、それでも、それらが私にきちんとした利益を与えてくれるケースを探しています。
前、中、後。
それらを使用して、要件、目的のアーキテクチャ、ソフトウェアの設計、実装、および展開を説明します。
ソフトウェアを使用するための操作手順でさえ、UML図の形式で記述できます。
UMLダイアグラムは単なる表記法であるため、実際の問題は、モデリングをそのように使用する必要がある場合です。さまざまなアプローチと態度を持つ多くの異なる方法論があります。統一プロセスはその1つであり、無料でUMLを大いに活用しています。そこから、UMLダイアグラムの使用方法と有用性を学ぶことができます。ただし、どのプラクティスが自分に適しているかを判断する必要があります。私は個人的に、UMLとモデリングを主にコード生成に使用できるツールと見なしているため、これらのモデルは実際には宣言型プログラムです。ただし、ドキュメントとしても役立ちます。一方、それらが動的な振る舞いの要件と説明に使用される最良のツールであるかどうかは疑わしいかもしれません。私はあなたにいくつかの手がかりを与えてくれることを願っています。
私はさまざまなプロジェクトでいくつかの異なる方法でそれらを使用しました。設計ドキュメントの一部となる設計時の成果物として使用されるクラス図とシーケンス図を見たことがありますが、それらは当時非常に役立つと思います。それらは、クラス間の関係とそれらがどのように相互作用するかを伝えるのに役立ちます。特に他の誰かの設計レビューに参加しているときは、一目で、どのインターフェイスとクラスが何であるか、どのインターフェイスとクラスが相互に拡張/実装されているかを知ることが役立つと思います。ただし、開発者が設計ドキュメントを最新の状態に保つことに熱心でない場合、これらのUML図はすぐに古くなる可能性があることがわかりました。
ただし、AndroMDAと呼ばれるUMLコード生成ツールを使用しているため、現在のプロジェクトではUMLを多用しています。確かに浮き沈みがありますが、バックエンドクラス、インターフェイス、スタブimpl、休止状態の構成ファイル、Spring構成ファイルを生成するために使用します。UMLに注釈を追加すると、休止状態とSpringの構成ファイルが可能になります。とにかく、このツールを使用しているため、バックエンドコードに変更を加えるときはいつでも、最初にUMLを更新することから始める必要があります。したがって、UMLが常にコードで実際に起こっていることを表していることが保証されます。
方法論DSDMを使用して携帯電話アプリケーションの開発を推進した経験では、機能プロトタイピング段階(開発が始まる前)でUML図を利用しました。
アプリケーションがどのように見えるか、人々や他のシステム間でどのように相互作用するかについて、彼らは私にはるかに明確な理解を与え、コードがどのように構造化されるべきかを私に示し始めました。
たとえば、アプリケーションの開発を開始する前にクラス図を作成します。これにより、必要になる可能性のあるクラスと属性について考えることができます。
私の経験では、これらは主に実装前にコンポーネントの構築方法を伝えるために使用されます。それらは人々が素晴らしい標準化されたフォーマットで潜在的なデザインをレビューする方法を提供します(デザインレビュー)。また、システムに関心のある非開発者にシステムの高レベルのビューを提供することもできます(機能レビュー)。また、システムがどのように機能するかを学ぶ必要がある新しい開発者のためのリファレンスとして、実装後にそれらが使用されるのを見てきました。