Just FYI. From my point of view, it is not necessary to use this tool/method.

Armedia CodeGen generates Data Access Objects (DAOs) and Data Transfer Objects (DTOs) for Documentum object types. DAOs and DTOs are design patterns for encapsulating persistent data sources and data. Design patterns are common approaches to solving typical problems. By associating a name to the problem and solution, the developer community facilitates easier communication.

Problem

Armedia has worked on multiple large engagements where Documentum is the core of the system; however a custom non-WDK (Web Development Kit) user interface was developed. As part of the software architecture, various sources interfaced with Documentum to manage content. To encapsulate knowledge about Documentum (i.e., the persistent data source), the team implemented the DAO pattern to provide create, read, update, and delete (CRUD) features. This allowed interfacing systems to manipulate POJOs (plain old java objects) versus DFC or DFS (Documentum Foundation Classes or Documentum Foundation Services) classes.

Benefit

• Fewer consultants needing to ramp-up on Documentum
• Reduced cost of Documentum upgrade since greatest costs are associated with migrating custom user interfaces
• Reduced dependency by reducing coupling of disparate applications
• Reduced development cost

Return on Investment

• Assume 10 Documentum Types (1 day / object type)
  • Create DAO
  • Create DTO
  • Create JUnit Test Case
• Cost: 10 object types X 1 day/object type X 8 hr/day X $100/hr = $8000
• Armedia CodeGen takes less than 5 minutes to generate for less than $100 / developer