|
|
|
News | CVS | Jira | The Codehaus |
The Model provides a repository of application entities and is analogous to the model in MVC, but supplements it with realizations of event and activity diagrams for Foundation use.
The Model is generally the most GC (Generator Centric) of all components. While a non-GC model could be created, it would likely be limited to legacy applications where the model was already very mature, interfaces for the PersistenceManager Service could be layered in, and the event and command structure was created manually or not used.
Almost all of the contents of the JAR generated by the Model build comes from UML metadata from an XMI format file in the Model project. These are:
Entities
Entities are generated by creating Entity objects in your UML source file and adding appropriate UML stereotypes. Gentaku processes the file, scanning for appropriate stereotypes, and generating Java source as appropriate based on Velocity template source. These templates are completely customizable, with the expectation that some projects may choose to rewrite them completely.
The standard Entity template generates an abstract POJO class that contains all the fields that map to the UML attributes in the model, plus whatever relations that exist between entities as appropriate for the PersistenceManager in use. The generated entities are currently annotated with XDoclet tags for use with Hibernate, although this weakness should be removed so that an Entity can be used with any PersistenceManager implementation that can understand a common metadata rendering.
The Entities are generated as abstract such that extension points may be defined by the developer. This is typically used for persistent queries that are more complex than what the generator was able to handle at the time that the query was written. UML operations that are unrecognized are generated as abstract methods, and an entity implementation class is maintained for the developer to implement these methods. By this method, the file system is used to manage the distinction between manually written and automatically generated code where complex and error-prone tags were used for this task in the past.
Convenience configurations are available that allow for a rapid build with maximum persistence configuration such that changes to the UML model are maximally propagated to the database schema with minimum time and effort on the part of the developer. While these configurations are not suitable for long term production use, it is a simple matter to change a Maven build property to generate a production-ready persistence implementation based on a JBoss SAR.
Events
Events are POJOs that act as envelopes for all data required to execute a use case in a Dentaku application. The front controller may build the information from one or several screens of data, environmental input such as time or geography, or means. When the Event is dispatched to the Dentaku Foundation, the Command that the Event is paired to is looked up and transactionally executed with the submitted Event. Upon successful completion of the Command, the Event is marshalled to a transaction log, which can be used for user, application or process auditing, backup or disaster recovery.
Events are represented in the UML source as a UML Use Case with associations to classes that define the Event envelope in aggregate. Associations to Actors define the role of the user required to pass declarative security constraits for use of that Event.
Commands and associated Workflow
Once an Event aggregate is defined, a UML Activity Diagram is used to generate a declarative workflow. This workflow definition provides the dynamic runtime relationships between various atomic components of a Command. Currently, Werkflow is used as the workflow engine, but any workflow engine could be used once the engine is encapsulated in a Service and some manner such as custom generators to provide the process description.
As process actions are encountered in the workflow, abstract methods are created in the Command, ready for implementation by the developer. These atomic actions all have the same execution contract, allowing actions to be more easily unit tested and providing for easier reuse in the future.
[ edit ]