Product Review: Application Development Made Easier Through Patterns
COOL:Plex is indeed "cool," but don't expect to pump out fully functional applications without a healthy investment in trainingTypically, application development tools ignore the analysis and design stages of software development and concentrate on the development stage. Other tools, such as Rational's Rose, or Computer Associates' PLATINUM ERWin can be used to help build a model, object-oriented or otherwise, but once the model is designed, transferring this model into your application development tool may be a problem. Even if there is a link to one or more analysis and design tools, the output is usually just function or object skeletons, with no real functionality.
Other tools, such as Microsoft's Visual Studio offer robust environments for creating Windows GUI applications, including the ability to visually design GUI screens. Unfortunately, the "visual" nature of these tools stop with GUI design and writing the code that drives the application is still up to you. Furthermore, these tools have a very weak connection to AS/400 back-ends that stop at ODBC front-ends to back-end AS/400 data.
Even IBM's own VisualAge tools fall short of being able to generate code, although they do allow you to visually connect GUI parts, which generates code to handle actions. VisualAge for Java's AS/400 Toolkit makes strides for improving access to AS/400 back-ends, but it requires learning the interfaces to the routine and manually programming the back-end connections.
If all of this makes you think that there isn't a tool out there that will allow you to model your application, generate code, and seamlessly interface to AS/400 back-ends, think again. Although not a solution to every problem,
Sterling Software's COOL:Plex goes a long way towards making AS/400 application development easier, without losing touch with the things that AS/400 developers know and love.
A Different Approach
Software engineering experts will tell you that the more time you put into the analysis and design stages of a project, the fewer problems you'll have during the development stage. Furthermore, it is much more expensive to make changes to a design once development has begun, and therefore, the time spent up front is well worth the extra effort.
This is where COOL:Plex differs from other tools. Its integrated model editor allows your team to design the entities that make up your application and then automatically generate the application code for screens, back-end logic, and database access.
In our evaluation of COOL:Plex, we set out to test the tools' suitability for use in two different application development scenarios-first, to build a model and an application from scratch; and second, to reverse engineer existing AS/400 physical tables and build an application for accessing this data using the COOL:Plex Application Integrator. We also explored Cool:Plex's ability to use the same model to deploy to different platforms. This testing was accomplished by changing the implementation languages for different parts of the application.
A Team EffortCOOL:Plex is designed from the ground up with team development in mind. Before you start modeling the entities that make up your model, you must create a Group Model. A Group Model holds all of the information that every team member needs to know about the project. From the Group Model, Local Models are created and parts of the Group Model can be extracted into the Local Model. The Local Model stores all of the information relevant to a specific part of the project that a developer is working on. Individual developers have their own Local Models and never work directly on a Group Model. When a developer comes to a good stopping point, the Group Model can be updated with the information stored in the Local Model.
This combination of Group and Local Models makes for a very flexible development environment that a manager can control to maximize the effectiveness of their developers.
New Group Models are created from the base template Group Model. Once the new Group Model is created you have to add the libraries that developers will use to inherit behavior from. This is where Patterns, discussed in full in the previous articles in this issue, come into play. Sterling has developed libraries of Patterns that typify the things that applications do. Usually you will add the Foundation Pattern library to your Group Model, which in turn adds the libraries that Foundation depends on.
Once the Group Model is loaded with the requisite Pattern Libraries, a Local Model can be used to build the entities, fields, and functions that make up your application. After the Local Model is created, the Pattern Libraries can be extracted from the Group Model and you're ready to go.
Before you get startedAs is true with most powerful development tools, COOL:Plex is complex. Be prepared to train your staff in both the use of the tool itself, as well as how to apply the Pattern Libraries to maximum effect. It is possible to build an application with COOL:Plex without any training, but the learning curve is steep and your developers will become more productive much faster if they go through the training.
If you've got the time and the money, Sterling offers numerous COOL:Plex training courses throughout the year. These courses range from a 5 day course on basic COOL:Plex concepts ($2000) to a 3 day course on using the Pattern Libraries ($1200.) Sterling education centers are located in many major cities including Atlanta, Dallas, and Chicago.
If your budget in time or money is limited, consider purchasing a few copies of
Phoenix Business Solutions COOL:Plex CBT CD-ROM ($2500 for a single user.) This self-guided training course will help a developer get up to speed on the tool, although it doesn't address the effective use of Patterns.
Sterling does provide a complete guided tour of Cool:Plex, including numerous tutorials illustrating COOL:Plex in action. We walked through the guided tour and one of the tutorials, and though they are useful, they are not a substitute for formal training. Take our advice: don't dive into COOL:Plex blind. Avoid the frustration your developers are likely to experience if they tackle COOL:Plex without training. The sometimes cryptic methods that COOL:Plex requires to accomplish some tasks can be best explained by an instructor. Even though we didn't attend the course, a few hours with the CBT CD and time on the phone with a Sterling product specialist did a world of good.
A Triple ThreatArmed with a Local Model and a little training, we tackled our first scenario--building an application from scratch, including a complete model. We decided to model something we knew well, our process for creating articles. There are two ways you can enter the information about your model. The most common method is to enter the information into the Model Editor using triples. Triples are a combination of three pieces of information, the source object, the verb, and the target object. The first triple we entered was "Track Entity ENT Emp" where Track is the source object, Entity is the verb, and Emp is the target object. This triple created two objects, a Subject Area named Track and an entity named Emp. A Subject Area is an object that points to other objects for the purpose of organization.
There are many different ways you can start to define the entities that make up your model, including using the triple "Emp Known By FLD Emp_Id" which defines an entity named Emp and a key field named Emp_Id. Just remember there is always more than one way to tackle this with COOL:Plex and in a Local Model, nothing is permanent until you update the group model. If you make a mistake, just go back and delete the triple from the Local Model and re-enter the correct one. For our Emp entity, we entered triples to define non-key fields named LName, FName, and EmpStatus. Although we defined a total of seven entities for our complete model, we are only mentioning the Emp entity here.
The next concept that needs to be mastered is the application of patterns from the Pattern Library. When we created our Local Model we had to customize some settings. The two settings that we changed from the defaults were the implementation language date validation and storage. We set data validation and storage to AS/400 server, which instructs COOL:Plex to generate RPG code on the AS/400 to perform date validation and data access. Setting the Storage parameter to AS/400 will also generate DDS code on the AS/400 to define physical and logical tables for our entities. Setting the parameter to AS/400 for storage and date validation didn't actually do any of the above, it merely tells COOL:Plex what to do at generate and build time.
The power of COOL:Plex lies in its use of patterns. In other application development tools, you would have to write code for date validation or data access yourself. You might have some code lying around to do these things, or you might not. COOL:Plex includes Pattern Libraries stocked with patterns for common programming tasks like validating a date in a certain format, or accessing data in a relational database table. It also has patterns for displaying information on a GUI screen or for representing a field in an application.
It is simple to apply a pattern to an entity or field. You just enter another triple. To tell COOL:Plex that we want the Emp entity to be represented by a relational database table, we enter the triple "Emp is a ENT RelationalTable" into the model editor. Although seemingly simple, this triple has far reaching effects. First, it finds the object RelationalTable in the STORAGE pattern library. Second, it defines a Physical Table object for Emp. Third, it inherits a number of functions from STORAGE/RelationalTable that tell the application how to access the data in the table.
This is very significant from a programming productivity standpoint. With the entry of just one triple, we have initiated a process that will eventually lead to the generation of ten AS/400 programs: three DDS programs and seven RPG programs. Imagine if your developers had to do this programming themselves. Even if you had a library of predefined data access routines, you wouldhave had to write these at some point, and every programmer would have to know where to find them and how employ them in a program. This could be especially difficult since you are building a Win32 application that accesses back-end AS/400 data. Sounds like a nightmare, but COOL:Plex makes it a dream. Now your programmers can concentrate on building business logic, rather than mundane data access code.
Once we had data access taken care of, the next logical step was to define a triple to tell COOL:Plex how we wanted our data to be displayed on the client-side. This was easily accomplished by entering the triple "Emp is a ENT EditDetail" into the model editor. Just like the previous triple, this triple does a myriad of things under the covers. Chief amongst these things is the definition of a default panel for entering and editing data into the Emp table, and functions for accessing the data on the server-side. In client/server terms, these functions are stub functions and don't know or care how the data is stored on the server.
We continued to fill our model by entering triples for fields of the Emp entity and defining the applications' representation of these fields. For instance, we entered the triple "Hire Date is a FLD CheckedDateISO." This told the model that Emp would have a field that would need to conform to ISO date validation standards. No Y2K problems here!
By decoupling the applications' representation of the fields from the physical representation, COOL:Plex achieves platform independence. The same COOL:Plex model can be made to generate any number of implementations of the application. These different implementations can range from a very fat client with everything but data storage done on the client, to a very thin client with only presentation done on the client, and any combination in between.
Once our model was complete, we were ready to take our first shot at generating our application code and building (compiling) the local and remote code. Our first scenario was to have COOL:Plex generate a Win32 front-end that would access data stored on our AS/400. The data access and validation routines would run as RPG programs.
The COOL:Plex development environment runs on Windows 95/98/NT. In order to compile the client-side programs you need to have Visual C++ 6.0 installed, which is not provided. In addition, if you are going to run any programs on the AS/400, you need to install the COOL:Plex library on your AS/400. This installation is simple and we had it up and running in a few minutes. You need a job running on the AS/400 that intercepts requests from COOL:Plex for remote compiles, and starts an AS/400 job or jobs. Before all this can work, you must define a Job Description on the AS/400 that points to the libraries that COOL:Plex will attempt to place the generated source code and the compiled object code. We used TCP/IP for accessing the AS/400, but COOL:Plex can be configured to access the AS/400 via SNA.
Once everything is properly set up on the AS/400, you are ready to generate and build your application. (We decided to generate and build just our Emp entity. We figured if this worked properly, all the other entities would work too.) But, before you can kick off the generate and build process, you must configure a few things. You need to define the AS/400 system you will be accessing, the source and object libraries on the AS/400, the ODBC data source that points to your AS/400 data library, and the Job Description that your build process will use, among other things.
We configured everything we needed to on the client and kicked off the generate and build process. A number of dialog boxes were displayed, and Visual C++ 6.0 was launched to compile the Win32 code for our GUI screen. Finally, a request was made of the AS/400 to compile all of the DDS and RPG code.
When all was complete, we checked the message log and the AS/400 status window to find that everything had compiled without error. We ran the edit panel for the Emp entity, and lo and behold, a window popped up where we could enter and edit data in the Emp table. We closed down and ran the panel again and there was our data, just as we had entered it. As a sanity check, we opened a 5250 session to our AS/400 and started Query Manager. We found the Emp table (which had a computer generated name that you can customize if you want to) and ran a simple query of the table to verify that the data was really there. And amazingly enough---it was really there!
A New FaceGiddy with the thrill of successfully building and running our first COOL:Plex application, we decided to tackle scenario two, which was to put a Java face on our application. This should have been as easy as changing the UIBASIC model variant from Base to Java and re-generating and building the application. Unfortunately, this was not the case. The generate and build operation was successful, but we couldn't get the Java code to run.
We spoke to a Sterling Software product specialist who had experience with the Java generation capabilities of COOL:Plex but he was stumped. He put me in touch with another Sterling person and after playing with numerous configuration parameters, we finally got it to work. It was as slow as molasses in winter, but this can be attributed more to Java's poor run-time performance than the Java code that COOL:Plex generates. The key to making Java front-ends work is to become an expert in all of the configuration parameters. It doesn't hurt to have a sound understanding of how Java applets and applications work either.
Going The Other WaySince we had been successful with scenarios one and two, it was time to move on to perhaps the most relevant use of COOL:Plex in an AS/400 shop-to build an application that would work with legacy data.
It is one thing to build a COOL:Plex application that uses your existing AS/400 as an application server and database server, but it is an entirely different matter to use COOL:Plex to generate an application that accesses existing AS/400 data and business logic.
For those brave souls who want to attempt this very thing, Sterling includes an add-on program called Application Integrator. To use Application Integrator effectively, you must install an additional library on your AS/400. This allows you to do a native database connection to an AS/400, as opposed to an ODBC connection. We highly recommend this native connection since the way ODBC returns data types to Application Integrator causes boatloads of problems.
Even though you use the native connection, Schema/400, to query the AS/400 for information about physical files, you're still in for some trouble. The process is fairly simple. You start Application Integrator and press the new button. You'll be prompted for the Schema type, which sends you to a screen where you can enter a Library name and File Name. If Application Integrator finds the physical file, it creates entities and fields appropriate for the physical file. You then repeat this process for each physical file you wish to import. Once all the files have been imported you apply the Pattern Libraries to the defined entities and fields and generate the import file that COOL:Plex will use. Once the file is generated, you create new group and local models and import the file you just generated.
We have two complaints: First, the whole process is unwieldy and difficult to work with, and second, the import process works but the RPG programs that COOL:Plex generates to access the newly created entities will not compile successfully.
After literally days on the phone with Sterling product support specialists, we could not get the model to build without errors. These errors ran the gamut from actually crashing the Windows 95 development PC we were using, to just not compiling on the AS/400.
We're not ready to condemn the whole COOL:Plex product due to the problems we encountered with Application Integrator, but if you are counting on reverse engineering existing AS/400 physical files into a COOL:Plex model, plan on spending time on the phone with Sterling support to work out the kinks. We ran out of time and never did get the thing working.
The Best of the Rest
It is not possible to cover all of the features of COOL:Plex in one product review. We could do a three part series and still not do it justice. Having said that, there are a few important points that are worth mentioning.
It is clear to us that with COOL:Plex, some training, and a little patience, you can significantly reduce the amount of time it takes to build a functional application. The only question is: Just how functional will this application be?
Unfortunately, the generated application is not likely to offer all of the functionality you'll want. Certainly this base application will be able to handle most simple data entry tasks including inserting, updating, and deleting records¾but it won't do much else and it won't look pretty. This is not to say that COOL:Plex applications can't be made more functional, just that this doesn't happen right out of the box.
The good news is that COOL:Plex provides all the facilities you need to take this basic application, make it pretty, and add any and all the business logic required to make it a fully functional application.
Once you have defined an entity and given it a pattern to inherit GUI behavior from, you can use the panel editor to tailor the look and feel of the interface any way you want. These changes are held over even if you change the entity, so you don't lose changes the next time you generate and build the application.
Adding business logic is fairly straightforward and can be done in such a way as to incorporate existing business logic on your AS/400, no matter what language it is written in. The only caveat is that this logic must exist as a standalone program and not a 5250 screen. Action Diagrammer is used to add additional functionality to a COOL:Plex application. Again, just like the panel editor, any additions you make using the Action Diagrammer are not lost when the application is generated and built.
Clearly, we have only scratched the surface of what COOL:Plex is, and how it can be used to generate applications in a fraction of the time it would take with traditional methods. If you haven't read "Capturing Knowledge in Patterns and Models" on page XX of this issue, please do, as it explains how American Software used COOL:Plex and patterns to radically reduce the time it took them to produce the latest version of their ERP software. The bottom line is that with training and patience, COOL:Plex can be a great asset to any software development organization.