SOA 接続アプリケーション (JavaEE、PHP、および .Net の混合) の既存のスイートがあり、全体的な展開モデルまたはアーキテクチャ図を提供する必要があります。
J2EE アプリケーション展開用の UML ダイアグラムの例を見つけました。これは、現在のダイアグラム要件にほぼ適切なレベルの詳細 (アプリ、コンテナー、一部のコンポーネントの明示) であるため、魅力的です。
同じ著者のApplication Clustering Exampleのようなものを使用して、より高いレベルでそれらを集約することさえできます。
コンポーネント レベルやアーティファクト レベルに飛び込んで、そこから図を作成できると確信しています。
ただし、私は特定の Java コンポーネントも設計しており、現在の「アーキテクチャ」の演習が完了したら、全体的なクラス図を開発チームに提供し始めたいと考えています。これには、Java コードのリバース エンジニアリングとそこからの開始が含まれると思います。
私の質問は、現在の展開と将来のコンポーネント モデリングのニーズを満たすための最善の戦略は何ですか?
現在作成している現在のアーティファクト (WAR ファイルや JAR ファイルなど) を、後でリバース エンジニアリングされたコンポーネントで埋め戻すことは期待できますか?
今すぐリバース エンジニアリングを行い、「ボトムアップ」からアーティファクトを作成し、ほとんどのコンポーネントを無視して、後でコンポーネント モデリングのときにリバース エンジニアリングされたコードを更新する必要がありますか? .Net と PHP の部分は私のドメインではないため、論理的な (つまり、コードに支えられていない) コンポーネントのみが必要です。
コードが変更された場合は、配置図/アーティファクトを「手動で」更新する必要があるため、配置アーティファクトをコンポーネントから (異なる EA プロジェクトまたは同じプロジェクト内の切断されたモデルを介して) 分離して保持する必要がありますか?
私は Sparx EA (RSA から移行した後) を使い始めたばかりで、私よりも EA の経験が豊富な人の視点と、上記の説明で提起されたアンチパターンの危険信号に関するフィードバックをいただければ幸いです。