Populating the Model
Now we are ready to create a method that reads a UML diagram and populates a model of a CF application. Again, this is a simple matter of looping over all the classes we found in the XMI document and then drilling into each (Listing 2). From there, we will loop over the class properties, extracting what we find and pushing information into an instance of the Model class (Listing 3). Next, we loop over the functions and, for each of those, down into its arguments (Listing 4). When finished, our createModelFromFile function returns a Model object that represents the information in our diagram.

Generating Code from Templates
Having all of the diagram's information distilled into a struct makes it quite easy for us to generate out any kind of template code we want, adhering to whatever standard or framework fits our fancy. In the interest of time, we'll just show generation of the CFProperty section of a webservice-oriented CFC. As you'll see, it becomes simple to generate out all the code for that boring task, and generating out classes containing CFFunction 'stubs' for all of the documented functions is not much more difficult. While some code-generation frameworks encourage modeling your database first and then generating code from Entity Relationship model, I would suggest creating a class model and then generating your Data Definition Language scripts from your classes. You could go all the way and generate out stored procedures to provide supporting functions for generated stub code. I am writing such generators for my own use.

The approach used to generate code is straightforward. We create templates to generate ColdFusion or SQL code, using CFSaveContent to keep the generated content in a string buffer. To get ColdFusion to generate ColdFusion code, we use symbols to represent where in our code we want to write three special characters: <, >, and #. We want to keep the stuff we're generating fairly readable, so we substitute the double angle bracket characters for angle brackets ("") and dollar signs ($) for the pound signs. The double angle bracket character is not on your keyboard, so if you follow this method, you will have to map that character somehow. I have a macro that replaces my two typed angle brackets with one double angle bracket character. Once we have generated the whole file we want to save and have it in a string variable, we can clean up all of those placeholder symbols with the real thing with some simple string functions like replace (input,'"','>','all').

The idea is to loop over a model struct outputted from our Model.getModel() function. Below is an example of generating CFProperty code using our special templating characters. In our generation framework, this kind of code would be wrapped up in functions in the Generator class.

<cfset myModel= model.getModel() />
<cfloop collection="#myModel#" item="componentName" >
    <cfset currentCFC = myModel[componentName] />
    <cfloop collection="#currentcfc.properties#" item="propName" >
      <cfset currentProp = currentcfc.properties[propName] />
      <cfsavecontent variable="generatedProperties">
        <cfoutput>
          "cfproperty name="#propName#"
          required="#currentProp.required#"
          type="#currentProp.type#"
          hint="#currentProp.hint#"
          default="#currentProp.default#"
          displayname="#currentProp.displayname#"
        /"
        </cfoutput>
      </cfsavecontent>
    </cfloop>
</cfloop>

Saving the Code
Now that we have generated all this great stuff, we need to do something with it. Our Writer class will write out the generated content to files, but it would be nice if it would also help protect us from ourselves by, for example, moving existing files to a backup location to prevent overwrites and loss of work, and logging any problems encountered. Remember that, in many cases, the output is meant to be edited; it is just an outline for the real code. Down the road, maybe this class would be smart enough to use Subversion to try to merge changes from the model into your edited code. After cleaning up our generated code above and writing it to a file, we would see something like:

<cfproperty name="lastName"
    required="yes"
    type="string"
    hint="The User's family name"
    default=""
    displayname="Family Name"
/>

Conclusion
In this article, we have attempted to lay the foundation for a code-generation system that encourages developers to model before they code. When the model does more than fulfill documentation requirements, it becomes a more valuable tool for the developer. The blueprint for the application is generated at the start of the project, providing benefits across the development team. For organizations, model-driven development presents an opportunity to build-in standards and best practices. Senior developers and architects can focus on iteratively improving their generators to produce more code cleanly and handle mundane, repetitive tasks. Junior developers are provided a great environment for learning, and the structure they need to complete their projects rapidly. If this concept is of interest to you and your team, I encourage you to check out the OpenModel project on CFOpen and to contact me at openModel@anthrologik.net.

References