eliteforge-java-uml

EliteForge Java UML

目標

• 実用化可能で、構造が明確で、境界が明確で、関係が正確な Java 25 UML クラス設計を生成します。
• 正確性と実現可能性を優先し、描きすぎるよりも、誤って描かないことを重視します。

環境変数

• ELITEFORGE_SKILL_JAVA_UML_PLANTUML_ASL_JAR [必須] 生成した UML SVG のレンダリングと検証に使用する ASL PlantUML jar の絶対パスです。

実行順序（毎回実施）

1. ビジネスにおける集約ルート、コアオブジェクト、ルールオブジェクト、永続化オブジェクト、クエリ責務コンポーネント、操作責務コンポーネントを特定します。
2. レイヤーを区別します。基本レイヤーには Controller、Service、Repository、Domain、Enums、External を使用します。Service の下位は、機能の種類に応じてサブブロックに分割できます（例：ストレージ／ルール／キャッシュ／ゲートウェイ）。固定の単一レイヤーに限定しません。
3. 閉集合の概念を特定し、列挙型としてモデル化することを優先します（状態、タイプ、段階、ソースなど）。
4. 各ビジネスモジュールに色を割り当てます。同じモジュールには同系色を使用し、異なるモジュールは色系統を分けます。
5. 監査フィールドが必要なオブジェクトを判断し、固定の 6 フィールドを補完します（参考ルールを参照）。
6. 各関係に対応先があるか検証します。フィールドまたはメソッドシグネチャ（引数／戻り値）で確認します。
7. 技術的なノイズとなるノードを削除します。POJO 変換クラス（*Converter/*Assembler/*MapperStruct）と MyBatis 技術クラス（*Mapper/*Example/*Criteria/SqlSession）は図に含めません。
8. クエリ責務コンポーネントがページネーション制約（queryPage または queryByCursor）を満たすか検証します。
9. テーブルの帰属に関する注記を検証します。リレーショナル永続化モデルの Entity ノードには、必ず 表: xxx と明記します（同じテーブルを再利用する場合は 复用表: xxx と記述できます）。Repository ノードにはテーブル帰属の注記を記載しません。
10. Controller ノードの説明を検証します。インターフェースのプレフィックス 接口前缀: /api/.../ を必ず記載します。責務を分割した Controller には、それぞれ個別のプレフィックスを記載します。
11. まず .puml ファイルを生成して書き込みます。情報が不足している場合は、確定できる部分を先に書き込み、不確定な項目は図中に注記します。
12. ジェネリックの記述を確認します。メソッドシグネチャとフィールド型のジェネリックには、直接 <> を使用する必要があります。~ ジェネリックおよび </> エンティティの使用は禁止です。
13. セルフチェックリストの各項目を確認してから、最終結果を返します。

必須の出力制約

• PlantUML クラス図ファイルのみ生成します。ソースファイルの拡張子は .puml に固定します。
• 必ず UML ファイルを書き込んでから、必要な説明（パス／レンダリング結果）を補足します。
• 「見た目を完全にする」ために、クラス、フィールド、メソッド、関係、列挙型を捏造することは禁止です。
• Dto／Vo／ResVo ノードの描画は禁止です。メソッドシグネチャ内でのみ使用できます。
• Page／PageResult／PageResponse などのページネーションコンテナノードの描画は禁止です。
• POJO 変換フローの表現は禁止です。*Converter/*Assembler/*MapperStruct ノードおよび toXxx/fromXxx 変換メソッドの描画は禁止です。
• MyBatis 技術クラス（*Mapper/*Example/*Criteria/SqlSession）および XML マッピングの詳細の描画は禁止です。
• 対応先のない接続線、接続線の label、不要なノイズとなる接続線は禁止です。
• リストクエリにはページネーションが必須です。findAll／selectAll／queryAll／listAll／loadAll の使用は禁止です。
• リレーショナル永続化モデルの Entity ノードの説明には、テーブルの帰属を示す 表: xxx を必ず記載します（复用表: xxx と記載することもできます）。Repository ノードに 表:／复用表:／无表: を記載することは禁止です。
• Controller ノードの説明には、インターフェースのプレフィックス 接口前缀: /api/.../ を必ず記載します。
• すべてのノード（クラス／インターフェース／列挙型）に、クラス内の説明を記載します。形式は <<说明标题>> + 説明 1 行以上です。
• 列挙型にはインスタンス（定数）のみを表示し、メンバー変数と内部メソッドは表示しません。
• メソッドシグネチャとフィールド型のジェネリックには、直接 <> を使用する必要があります。~ ジェネリックおよび </> エンティティの使用は禁止です。
• 色はモジュールごとに割り当てる必要があります。技術レイヤーだけで固定の色を付け、モジュールの境界を無視することは禁止です。
• Persistence レイヤーを単独で描画しません。技術的な実装詳細が図に含まれないよう、Entity は Repository の機能サブブロックに配置します。
• スキルの実行時には、まず環境変数 ELITEFORGE_SKILL_JAVA_UML_PLANTUML_ASL_JAR が設定されているか確認します。未設定の場合はそのまま終了し、先に設定するようユーザーに案内します。
• UML の内容を追加または変更した場合は必ず ELITEFORGE_SKILL_JAVA_UML_PLANTUML_ASL_JAR を使用して再レンダリングし、成功しなければ最終結果を出力しません。
• 最終成果物として出力できるのは、1 つの *.puml ソースファイルと同じディレクトリにある *.svg のみです。追加の *.plantuml の生成は禁止です。
• 会話内に UML 本文を再掲しません。出力ファイルのパス、レンダリング結果、必要なエラー情報のみを返します。

参考ファイルの読み込み方針

• 通常の UML 設計リクエストに対応する場合は、まず 参考資料：UML の基本ルール を読みます。
• ユーザーがレイアウト、色、読みやすさ、クラス内の説明を重視している場合は、references/plantuml-template.md を読みます。
• ユーザーが「そのまま編集できるテンプレート／例が欲しい」と求めた場合は、references/plantuml-example-template.md を読みます。
• ユーザーがレンダリングの失敗やバージョン互換性を懸念している場合は、references/plantuml-validation.md を読みます。

出力スタイルの基本方針

• デフォルトでは top to bottom direction + skinparam linetype ortho を使用します。
• まずモジュールごとに色を付け、次にモジュール内でレイヤーノードを整理します。ユーザーから明確な指定がない限り、外部 note の使用は避けます。
• デフォルトでは列挙型に接続線を引かず、ノイズを減らします。

出力テンプレート

@startuml
top to bottom direction
skinparam linetype ortho

' 先放分层包，再放类定义与关系
' 信息不足时，用注释列出不确定项，仍保持 PlantUML 输出

@enduml

参考資料

• 汎用 UML ルールとセルフチェック
• PlantUML 出力テンプレート
• PlantUML サンプルテンプレート
• PlantUML のバージョンと検証