UML2Dep: Formal UML Dependency Modeling

• The paper introduces a rigorous framework that converts UML models into Boolean dependency graphs for streamlined SPL and SOA analysis.
• It formalizes UML feature relationships using propositional logic templates to ensure configuration consistency and automated verification.
• Empirical evaluations demonstrate high precision and recall in industrial scenarios, supporting reliable code synthesis and system validation.

UML2Dep is a rigorous framework leveraging Unified Modeling Language (UML) models as the substrate for deriving mathematically precise dependency representations, supporting both requirement analysis in Software Product Line (SPL) engineering and controllable code synthesis in industrial Service-Oriented Architectures (SOA). It formalizes structure and data flow by systematically transforming visual UML artifacts into explicit logic or dependency graphs, which can be verified or operationalized using automated reasoning tools or LLMs (Ripon et al., 2013, Mao et al., 5 Aug 2025).

1. Formalization of UML Feature Relationships

The original UML2Dep methodology targets SPL engineering by mapping standard UML feature-variation relationships onto propositional logic fragments. The supported relationship types include:

• Mandatory: $\mathrm{mand}(P,C):\; C \leftrightarrow P$
• Optional: $\mathrm{opt}(P,C):\; C \rightarrow P$
• Or-group: $$\mathrm{orGroup}(P,\{C_i\}):\; [P \rightarrow \bigvee_i C_i] \wedge \bigwedge_i[C_i \rightarrow P]$$
• Xor-group: $$\mathrm{xorGroup}(P,\{C_i\}):\; [P \rightarrow \bigvee_i C_i]\wedge \bigwedge_i [C_i\rightarrow P]\wedge \bigwedge_{i<j} \neg(C_i\wedge C_j)$$
• Requires: $\mathrm{requires}(A,B):\; A \rightarrow B$
• Excludes: $\mathrm{excludes}(A,B):\; \neg(A\wedge B)$

These logical forms serve as an interlingua for automated analysis—every feature model or dependency network expressible in UML diagrams is systematically encoded as a conjunction of Boolean constraints, denoted $\Phi$, suitable for direct input to SAT/SMT solvers or verified within model-finding frameworks such as Alloy (Ripon et al., 2013).

2. Exact Logical Semantics and Metamodel

UML2Dep operates in pure propositional logic. A finite set of Boolean feature atoms $F = \{f_1,\ldots,f_n\}$ encodes model elements, with each system configuration $\sigma \subseteq F$ corresponding to a truth assignment. The formula syntax is:

• $\top$, $\mathrm{opt}(P,C):\; C \rightarrow P$0
• $\mathrm{opt}(P,C):\; C \rightarrow P$1
• $\mathrm{opt}(P,C):\; C \rightarrow P$2
• $\mathrm{opt}(P,C):\; C \rightarrow P$3
• $\mathrm{opt}(P,C):\; C \rightarrow P$4
• $\mathrm{opt}(P,C):\; C \rightarrow P$5

Semantics follow classical Boolean logic, mapping each system variant selection to model validity, dead features, or configuration consistency (Ripon et al., 2013).

Expanding to SOA code generation, UML2Dep introduces an extended UML sequence diagram $\mathrm{opt}(P,C):\; C \rightarrow P$6, incorporating lifelines, messages with typed API specs, control-flow fragments, and decision tables (DT) for business rules (Mao et al., 5 Aug 2025).

3. End-to-End Pipeline: From UML Model to Dependency Constraints

A four-step transformation pipeline provides systemic translation from UML diagrams to analyzable Dep (dependency) models:

1. UML Model Preparation: Annotate model elements—«variationPoint» for variation points, «variant» for features. Explicitly connect elements using compositional connectors and cross-tree «requires»/«excludes» links.
2. Feature Graph Extraction: Traverse model, collect direct children for each variation point, identify grouping modality, and record cross-tree dependencies.
3. Rule Mapping: Assign each parent-child or cross-tree group to its corresponding propositional template (as above).
4. Dep Model Assembly: Conjoin all fragments into global $\mathrm{opt}(P,C):\; C \rightarrow P$7; optionally, encode into Alloy or SAT/SMT solver inputs (Ripon et al., 2013).

For SOA, this pipeline is adapted to process enhanced sequence diagrams, performing static parse operations to extract execution dependencies and formalizing data dependencies at the messaging and decision-rule level (Mao et al., 5 Aug 2025).

4. Data Dependency Inference for Code Generation

In its recent instantiation, UML2Dep formalizes the Data Dependency Inference (DDI) problem as follows:

• Input: Extended sequence diagram $\mathrm{opt}(P,C):\; C \rightarrow P$8.
• Output: Directed graph $\mathrm{opt}(P,C):\; C \rightarrow P$9, where $$\mathrm{orGroup}(P,\{C_i\}):\; [P \rightarrow \bigvee_i C_i] \wedge \bigwedge_i[C_i \rightarrow P]$$0 are nodes (messages/fragments/input/output), $$\mathrm{orGroup}(P,\{C_i\}):\; [P \rightarrow \bigvee_i C_i] \wedge \bigwedge_i[C_i \rightarrow P]$$1 is the set of data entities, and $$\mathrm{orGroup}(P,\{C_i\}):\; [P \rightarrow \bigvee_i C_i] \wedge \bigwedge_i[C_i \rightarrow P]$$2 encodes which node produces/consumes which data.

The formal matching problem must obey:

• Reachability: Data dependencies only between reachable nodes.
• Producer/Consumer Roles: Data is only produced/consumed by valid node types.
• Completeness: Every data item consumed is produced by exactly one predecessor.

The core inference uses symbolic prompts to steer LLMs in structured dependency extraction, leveraging mathematical constraint templates with explicit predecessor sets and output schema (Mao et al., 5 Aug 2025).

5. Preprocessing: Static Parsing and Context Pruning

UML2Dep preprocessing phases ensure tractable and accurate DDI problem statements:

• Static Parsing: Constructs an execution dependency graph (EDG) with hierarchical (containment) and sequential (ordered execution) edges.
• Reachability-Based Context Pruning (RBCP): For each inference target node, only reachable predecessors are retained contextually, cutting spurious dependencies and reducing cognitive complexity for both LLM-driven and algorithmic analyses.

Algorithmically, this corresponds to a two-graph traversal collecting parents and sequential ancestors, omitting branches not relevant to the node's ancestry, as defined in the provided pseudocode (Mao et al., 5 Aug 2025).

6. Evaluation Metrics and Analysis

Task-level performance of UML2Dep on industrial SOA scenarios is evaluated via:

• DDI Task Metrics:
  • Precision: $$\mathrm{orGroup}(P,\{C_i\}):\; [P \rightarrow \bigvee_i C_i] \wedge \bigwedge_i[C_i \rightarrow P]$$3
  • Recall: $$\mathrm{orGroup}(P,\{C_i\}):\; [P \rightarrow \bigvee_i C_i] \wedge \bigwedge_i[C_i \rightarrow P]$$4
  • $$\mathrm{orGroup}(P,\{C_i\}):\; [P \rightarrow \bigvee_i C_i] \wedge \bigwedge_i[C_i \rightarrow P]$$5 score: Harmonic mean of Precision and Recall

Empirical results from "WeChat Pay" use cases (224 dependencies: 157 API, 60 Condition, 7 Action) demonstrate:

• Average Recall: 89.97%
• Average Precision: 95.06%
• Average $$\mathrm{orGroup}(P,\{C_i\}):\; [P \rightarrow \bigvee_i C_i] \wedge \bigwedge_i[C_i \rightarrow P]$$6: 92.33%

In code synthesis, DDI-driven prompts lead to improved test metrics over baseline:

• Compilation pass rate: +8.83 points (85.50% → 94.33%)
• Unit-test pass rate: +11.66 points (81.17% → 92.83%)
• Full test-suite pass rate: +5.00 points

In complex use cases, much larger impacts are documented—e.g., compilation pass rates in "QueryPMAccount" increased by 29 points, unit-test by 36 points (Mao et al., 5 Aug 2025).

7. Automated Verification and Practical Deployment

The Dep model, whether for SPL feature configuration or SOA data flows, directly supports automated verification. Regular queries include:

• Consistency checking (SAT/UNSAT)
• Dead/false-optional feature detection (by existence of $$\mathrm{orGroup}(P,\{C_i\}):\; [P \rightarrow \bigvee_i C_i] \wedge \bigwedge_i[C_i \rightarrow P]$$7 with or without certain features)
• Configuration or "product" enumeration (by constraining allowed feature choices)
• Detection of inconsistent or unreachable configurations

The methodology is solver-agnostic: The machine-checkable Boolean backbone of Dep supports Alloy, SAT4J, MiniSat, Z3, and CVC4 back ends. For data dependencies, the dependency graph underpins method signature synthesis, variable wiring, and testable code skeleton production. The graphical-to-logical pipeline remains visual and editable for domain experts, but is fully formalized for automated, trustworthy analysis and generative workflows (Ripon et al., 2013, Mao et al., 5 Aug 2025).