私はクライアント向けに構築しているPHP4システムを文書化しています。 MVCパターンを使用して、オブジェクト指向のロジックに従ってシステムが記述されます。私はすでにクラス図をスケッチしています。しかし、このようなシステムのオブジェクト図を作成するのが理にかなっているかどうかは、OOPモデルにかなりゆるやかに従っているので、今や私は不思議に思っています。PHP4とUML：オブジェクト図を設計するのは理にかなっていますか？
このシステムでオブジェクト指向の動作に最も近いのは、呼び出される方法に基づいて動作を変更するメソッドのほんの一部にすぎませんが、まったくまっすぐなクラスをインスタンス化することはできません。オブジェクトダイアグラムはこのシナリオから有用なものをすべて取得しますか、それともそれらを完全にスキップする方がよいでしょうか？前もって感謝します。
私の経験では、UMLクラス図は、システムのセクションを記述するために、分離されたコンテキストで最もよく使用されます。
私の答えは、ドキュメントにシステムの一部を記述していて、UMLクラス図がなら、読者がシステムの関連セクションを理解するのに役立つでしょう。そのセクションの図を作成する必要があります。それを含める。
システム全体で1つのクラス図を作成することは、それほど有用ではありません。また、コンテキストを持たないさまざまなクラス図を含めることはほとんど役に立たない。
あなたのUMLを使用する上で戦略的です。コミュニケーションツールであり、ドキュメンテーションツールではありません。
それは意味があり、あなたは絶対に正しいです。実際、私はクラス図の構造をパッケージにまとめ、構造の要素を鳥瞰で一般化し、より詳細な記述に分解しました。しかし、もし私がこれらの基本コンポーネントから1つを開発しようとすると、オブジェクトダイアグラムが顧客に構造をよりよく理解させるのに役立つかどうか疑いがあります。思考？ –
私の意見は単純です：あなたがそれを疑うなら、それを含めないでください。私は、クラス図が有益であることが一般にはっきりしていることを発見しました。言葉にするのは難しいですが、たとえば、インターフェイス/クラスの依存関係や関係を表示するなどです。 –
申し訳ありませんが、ありがとうございます。私はその選択肢がシンプルになるとは思っていませんでしたが、それは完全に妥当と思われます。 –
あなたの状況の柔軟性はUMLの期待と矛盾していると思います。
私は、ダイアグラムから実装レベルを抽象化（および嘘）し、それらのメソッドの機能を独自の作業を実行する独立したメソッドとして表現することをお勧めします。
トピックはありませんが、あなたはphp4で何かを構築してもよろしいですか？今年は中止されており、特にオブジェクトシステムは非常に扱いにくいです。 – troelskn
真実、それは話題ですが、私は説明のために懇願していると思います：既存のシステムはPHP4であり、PHP5に移植すると時間がかかり、リソースを消費することがあります。最終的に、いくつかの機能をPHP5サーバに移行する計画がありますが、これは将来的にしか採用されません。 –