What users are saying about QCGU™

"Using our framework and QCGU to generate the building blocks of Delphi code, we find that we can now build a rather complex screen in a couple of days instead of a couple of weeks."
—Patrick Barel, VDA [full review]

"Now we have more time to focus on business logic. We spend less time on base PL/SQL and Oracle functionality, leaving it to QCGU to do the work for us."
—Brede Fladen, Matiq [full review]

QCGU User: Patrick Barel — VDA (www.vda.nl)
Project: Generating Delphi framework code using QCGU

Summary When building new, complex applications, it is very beneficial to agree on an overall development framework (set of standards, naming conventions and shared components).  The time it takes to build the framework is easily made up by the "downstream" productivity improvements of framework-based development.  Add generating code using QCGU to this picture and you will see big savings on your project.  Using the framework and QCGU to generate the building blocks of Delphi code, we find that we can now build a rather complex screen in a couple of days instead of a couple of weeks.  Where we normally used 3 weeks to build a screen, we now do that in just one week.  About 50% of the timesavings can be attributed to generating the building blocks (both reusable code and starting-point templates) using QCGU.

"So to conclude: Building applications with a framework is a good thing for productivity.  Generating building blocks with QCGU is even better for productivity."

Detailed report A couple of months ago we decided to build a Delphi framework for Oracle-based applications.  The way we saw it, that was a lot of code for a CRUD-screen (create-retrieve-update-delete) – or any screen in an application.  That means that this code can be centralized in higher classes and the real screens can be built as descendants of those classes.  While building the framework we decided that:

• As much code as possible should be in the framework classes
• As much code as possible should be in classes that can be 100% generated based on the data model
• The rest of the code should be generated once based on the data model
• For building the screens we wanted to use as little code as possible

While building the framework we kept these four rules in mind with everything we did.  And during the development of the framework we found that QCGU was a great helper tool for our framework.  We identified six different pieces of code that all consist of one class that can be 100% generated and one class that is generated as a starting point for the developer to do the layout work and put in the custom code for the application.

The development of a working version of the framework took about one month to complete.  (Frameworks like these are never really "finished", because we are always finding ways to improve it; with QCGU, we have a product that lets us easily evolve the framework.)  Then we started writing the scripts to generate code.  We took code we had written as a test application while developing our framework, identified the parts that were related to the database (tables, views, column-names etc), and replaced them with templates built with CGML (Code Generation Markup Language).

The next step was to identify the different task-groups and tasks that would build up the application (at least the generated part).  We decided that we needed two major task groups (one to generate once and one to generate over and over again).  Underneath each of these two task groups we identified 3 task groups:

• Generate the database object code
• Generate the frames
• Generate the forms

Underneath these groups we created the different tasks for the different parts to be generated.  These tasks then consist of one or more roadmaps identifying the scripts needed to create the code.

When all of this was in place, we started generating the code so we could start building the application.  We have a rather big application to build (or actually to migrate from Oracle Forms), so generating the code took about 6-8 hours.  That might seem like a rather long time, but if you consider the amount of code generated (about 25 - 30 MB of text files) then that is rather fast, especially compared to writing this yourself.

Now that we have all the generated code in place we can start rebuilding our application.  This is a lot like building with Legos.  We've got a lot of building blocks in place which we have to connect using a couple of short statements.  Using these blocks takes us about 30 minutes to build a screen for a master-detail relation in the database.  Although the layout of the forms is not nice, the screens are working.  Now we just have to take a couple of minutes to do some layout on the different parts of the screen (in the correct files) and then we are done with our master-detail screen.  All the CRUD stuff is working.

As a rule of thumb we calculate one hour for one part of the screen.  That means that we get about four hours to complete a rather simple Master-Detail screen.  That should be easy to do.  Most of the time, we spend less than two hours doing this.  But, when we have a rather complex screen with details in details, the layout of the objects on the screen can take up more time and the connections between the different parts may take a bit more time.  But as an average, it's a good timing estimate.

Now consider building a master-detail screen for yourself.  You'll have to figure out what fields are in a table, what kind of object you want to use for that (an edit box or a memo field).  Then you have to put all these on your screen, do the layout, connect the fields to the database, and implement the insert/update/delete/select statements over and over again.  This takes up a lot of time.

So to conclude: Building applications with a framework is a good thing for productivity.  Generating building blocks with QCGU is even better for productivity.

[top]

---

QCGU User: Brede Fladen - Matiq (www.matiq.no)
Project: Upgrade to major application based on QCGU

Summary By using QCGU to help us upgrade a major application, we were able to focus much more of our efforts on the application-specific logic and let QCGU build the routine, lower-level elements of the upgrade code.  We estimate that the project team saved at least 100 hours using pre-production QCGU on this 2000 hour project.  We expect our savings in future projects to be much higher.

Throughout the last half of 2004, we performed an upgrade to our Integrated Sales and Production Forecasting and Planning application (ISP).  ISP is used by the Gilde Norwegian Meat for forecasting and planning of fresh food production and delivery.

"I recommend QCGU to all PL/SQL developers who want to be more productive."

We used a new modeling method to define the business logic; we decided to use PL/SQL for the backend implementation.  In the spring of 2004, Svein Inge Carlsen, a member of the ISP team, attended the MIN-MAX PL/SQL seminar taught by Steven Feuerstein and learned about QCGU.  The ideas behind QCGU seemed very interesting; we thought that if QCGU delivered even half of what it promised, it would help us to be more productive.  But what could it do in real life? We decided to join the QCGU Testers list and find out. 

We worked with beta versions of QCGU over several months.  We reaped the following benefits from the pre-production release of QCGU:

• Access to Steven Feuerstein's expertise "in a nutshell."  We learned from him by using QCGU in a real life project.
• A solid framework for PL/SQL development.  We didn't need to invent the wheel all by our self.
• An efficient and well-designed implementation of the basic functionality we needed to maintain the information in our database tables.
• An effective transition to record-based coding.  It hadn't been something we used extensively, but Qnxo's scripts gave us an easy path to learning and using these structures./li>
• A script language and generator engine that we used for writing additional scripts for generation of code that was specific to our application.  We now even generate a critical part of our architecture, a special view layer, using custom QCGU scripts that we wrote ourselves.
• All of this gave us a rich and logical access layer for our base tables and views.

As a result of using QCGU, we have seen major improvements in our overall development environment:

• Standard access layer for tables and views.
• Faster implementation of changes: Do it once, place in the script, generate it for all relevant tables and views.
• More time to focus more on business logic: we spend less time on base functionality, leaving it to QCGU to do the work for us.
• We are able to take ongoing advantage of the expertise of Steven Feuerstein on PL/SQL through the mentoring aspects of QCGU. 

We ran into some challenges, mostly regarding version control of QCGU scripts, our own scripts, and the code that was generated.  What should be version controlled and how? How to do we control upgrades, i.e., when QCGU scripts are modified, do we use those changes or keep our code based on the old scripts? controlled upgrade? At the moment, we don't have all the answers to these questions based on the administration functionality available in QCGU.  This will need to be addressed in the future.  Conclusion: I recommend QCGU to all PL/SQL developers who want to be more productive.

[top]