UMLモデリング設計開発時、Javaクラスの論理パッケージと物理パッケージ(Java完全修飾パッケージ名)とを区分して管理したいと思っています。
例えば、AActionというクラスを開発するとき、ビューの階層的には
論理ビュー　＞　設計モデル　＞　Web層　＞　AAction
として管理したいが、実際Javaクラスに完全修飾クラス名は
Jp.Company.AAction
としたい場合など、現状論理パッケージと物理パッケージの分離区分ができないため、
モデルからソースForward時や、ソースからモデルリバース同期時など
うまく整合性が取れるよう管理できなく苦労しています。
現状の運用では、設計モデルのクラス(論理パッケージ)と実装モデルのクラス(Java物理パッケージ)を分けて管理する
(コンポーネントビュー　＞　実装モデル　＞　jp＞company＞AAction？？)
しかないかなと思っていますが、リバース時のクラス名の重複競合エラーの件もあり、あまりベストな回避策をとれないでいます。

何とかもう少しうまく解決はかれる方法はないでしょうか？

こちらに関してはいくつか方法がありそうですが
ひとつの方法としましては、まずjp＞company＞AActionという構成で
パッケージの親子関係を作成し、その中にクラス要素をすべて保存します。

それとは別に、論理ビュー＞設計モデル＞Web層というパッケージの
親子関係を作成し、こちらにはダイアグラム(クラス図)を入れます。

このようにしたうえで、基本的には後者のツリーで作業をし、
クラスの追加などは前者のツリーに対して行います。クラスの編集などは
クラス図で行った変更がもちろん前者のツリー内のクラス要素に反映されます。
クラス図の編集中にプロジェクトブラウザ内のクラスの位置を確認したい場合も
あると思いますが、「プロジェクトブラウザ内の位置を表示」機能を利用すれば
比較的効率的に参照できると思います。

また、ダイアグラムのプロパティから「外部オブジェクトを明示する」の
チェックを外しておくと見た目にもすっきりすると思います。

ぜひ、お試しください。

ご回答の方法は回避策として了解しました。

ただ、開発作業手順として、
UML分析：分析モデル→UML設計：設計モデル→Javaコード実装→モデルメンテ(設計モデル修正→実装モデルと同期)となります。

デフォルトでクラスはダイアグラムと同じ階層に作成されると思うので、設計モデルダイアグラム作成したあと、別の場所への移動と移動する際、論理パッケージと物理パッケージの階層Mapping対応付けを確認しながらになるので少々面倒臭いし、結局、設計時頭で考えたクラス設計と実際に実装コーディングしたときとはギャップがあり、プログラム作成したあとの設計モデル再修正個所は結構現実的にはかなり多くなるので、モデルメンテナンス作業は面倒かな？と思いました。
(ソース→モデルリバース同期もそれほど自動化できないので、ラウンドトリップ/ライブ開発ツールじゃないのでしょうがないですが。。。)

なので、EAの場合は、設計モデルは設計時に考えた時のモデルとして管理して、実装リバースモデルはそれで、別に分けてクラス管理した方が良いのかな？と思っています(ダイアグラム作成しなおしが必要となってしまいますが)。

もう少し、何か良い方法/運用回避策あったら、また情報教えていただければです。

よろしくお願いします。

Enterprise Architectは、別の投稿にもありましたように
例えば、属性や操作の削除時には同期して削除するような仕組みにはなっていません。

こういったことからも明らかなように、現時点では完全な
ラウンドトリップには対応していません。そういった意味では
記述頂いた案のように、設計モデルから一度コード生成した後は
実装モデルを別のパッケージにリバースして、それを同期するほうが現段階では効率がよいかもしれません。

パッケージ構成とJavaにおけるパッケージ階層構造の連携については
ちょっと機能改善案を考えてみます。

こういった実際の開発現場での使い方というのは、
なかなかこちらには届いてこないのが現状です。
そのため、実際に現場で利用してみると、こういうところが使いにくい、
という点があるかもしれません。

ぜひ、そういった点がありましたら、使い方や改善案などを
お寄せいただけると助かります。それにより、
より使いやすいツールに改善していきたいと思います。