Development productivity study: Uniface deliver 3GL app in less time, using less code

Study shows the reference application written in Uniface, Pet Plaza, requires one half to one eighth the lines of code needed by equivalent Java or .NET implementations.

Execute summary

Uniface, Compuware’s advanced, enterprise development environment, allows 3,500 companies worldwide to reduce time-to-market of sophisticated, business-critical applications. Uniface speeds up development and allows applications to be deployed anywhere due to its support for all leading technologies, from mobile to the mainframe. These competitive advantages combined with its upward compatibility are the reason Uniface’s installed customer base has endured for almost a quarter of a century.

Java EEEE (formerly J2EEEE) and Microsoft .NET are the two dominant enterprise programming models today. Accordingly, Compuware often is asked to compare Uniface’s development productivity and runtime performance with those of Java EEEE and .NET. This is a challenging task, given the notorious difficulty of making fair comparisons on the basis of synthetic benchmarks.

Compuware decided the best approach was to create a new sample application and benchmark, based on the J2EEEE Pet Store and .NET Pet Shop applications. To differentiate it from these older programs, Compuware’s sample application is known as Uniface Pet Plaza. This article compares the development productivity of Pet Plaza with those of Pet Store and Pet Shop, focusing on the number of files and total lines of source code (LOC) required. A comparative study of the three applications’ runtime performance will be described in a future paper.

All things being equal, there is a tradeoff between development quality and productivity on one hand, and runtime performance on the other. As a modern fourth generation language (4GL), Uniface excels in reducing the amount of code required to create a given application. The resulting simplification also makes for improved software quality, as the smaller amount of higher-level code is easier to understand, share and maintain. However, a Uniface application may not run quite as fast as an equivalent one written in Java or with .NET.

Application	L.O.C.	Derivedfrom
Java Pet Store:	14,273	273 text and Java files
Microsoft Pet Shop:	3,484	65 files
Uniface Pet Plaza:	1,959	2 models, 1 library, 2 USPtemplates, 1 startup shell, and 20 USPand service components

Figure 1: This table shows the total lines of code (LOC) and number of separate files required by Uniface Pet Plaza, Java Pet Store and Microsoft Pet Shop.

Pet Plaza takes 56 percent of the LOC, and 37 percent of the files, used by Microsoft Pet Shop to deliver the same functionality. And Pet Plaza takes 14 percent of the LOC, and 9 percent of the files, used by Java Pet Store to deliver the same functionality. When we drill down to individual application tiers, the difference in LOC between Pet Plaza and the others ranges between 1:2 and 1:8.

The facts reveal that developing with Uniface makes it possible to implement a given application with slightly over half the LOC required by .NET, and about one-seventh of the LOC required by Java. The saving of development time alone is substantial, even before considering the likely additional benefits in software quality, maintainability, flexibility and project cost. Let’s take a closer look at the Compuware study in development productivity.

Compuware is often asked, by customers and others, to compare Uniface’s productivity, performance and other characteristics with those of alternative software stacks. However, performance benchmarking is difficult to do accurately, and results can be misleading if incorrectly interpreted. Productivity, too, is hard to measure mostly because opportunities to compare like with like occur so rarely.

In an attempt to share as much information as possible about the development productivity, runtime performance and other attributes of Uniface, Compuware has created its own sample application and benchmark: Pet Plaza.

This article will explain the origins of Pet Plaza, and present our findings about Uniface’s development productivity compared to those of J2EEand .NET. A subsequent paper will focus on the companion topic of runtime performance.

Pet Store and Pet Shop: The Background

Java Pet Store has become a highly controversial piece of software, but its origin was quite modest. When Sun launched Java 2 Enterprise Edition (J2EE) at the end of 1998, it included more than just the J2EE specification. J2EEalso comprised a compatibility test suite, a reference implementation and a set of “blueprints.” The latter, of which Pet Store was the first, were intended to illustrate J2EEbest programming practices and design patterns, and to demonstrate J2EE’s key features for building enterprise applications. Another goal was to confirm the portability of J2EEapplications across a wide variety of platforms.

Pet Store was not designed to be a benchmark of any kind. Rather, it was Sun’s intention to give programmers a “worked example” of how best to use the many APIs (some of them quite complicated) that made up J2EE. There is absolutely no place in such an example for the kind of optimization usually required to squeeze the best performance out of any piece of code.

Quite the contrary, it is generally understood by software engineers that tuning for the best possible performance is an activity that should be kept strictly separate from the main business of design and coding. In the words of the famous computer scientist C. A. R. Hoare1, “We should forget about small efficiencies, say about 97 percent of the time: premature optimization is the root of all evil.”

Normal best practice is to structure an application in the most logical and flexible way, and to undertake specialized tuning only if performance turns out to be disappointing. As often as not, such problems are caused by one or two fairly obvious bottlenecks, which an expert can quickly find and eliminate.

Needless to say, these considerations were of little concern to the marketing fraternity and those developers who were keen to prove the superiority of their chosen platform. In October 2001, members of the Microsoft-backed gotdotnet.com community published a .NET version of Pet Store, which they called the .NET Pet Shop. The headline news was shocking, to say the least: Pet Shop was said to use only a third as many LOC as Oracle’s implementation of Pet Store, and to run up to 28 times faster with 450 users. Surely this was convincing proof that .NET was lightning fast, J2EEwas lumberingly slow or, possibly, both.

Informed critics immediately began pointing out some potential flaws in the Pet Shop benchmark or, to be more exact, in the conclusions drawn by gotdotnet.com.2 For a start, Pet Shop ran on completely different hardware from the Oracle implementation of Pet Store. Moreover, Pet Store was hardly, if at all, optimized—whereas Pet Shop was heavily optimized in a number of ways. Indeed, Pet Store had deliberately been written in pure object-oriented (OO) style, which is known to risk poor performance in distributed applications. (See, for example, Martin Fowler’s First Law of Distributed Objects: “Don’t distribute your objects!”)3

The Pet Shop developers had also placed some of the Pet Store code inside their SQL Server database. One of them, Scott Stanfield, admitted Pet Shop was really “a relatively thin layer that wraps stored procedures.”4 This is a technique that, when skillfully applied, can result in “tremendous performance boosts.”5

In due course, Larry Barron and Steve Wilson, the two original developers of Pet Store code, confirmed the application was purely illustrative. Among other things, they noted, “It’s one of the worst benchmark documents we’ve ever seen. It runs on Solaris 2.6, which is several years’ old and old hardware.”6

Uniface Pet Plaza: Rationale

Although it is not necessarily the case, development productivity and quality often work against runtime speed—and vice versa. It is an old engineering truism that you can optimize only one parameter at a time, and many of the characteristics that make software development easier and more efficient tend to add overhead, thus slowing down runtime performance.

Every combination of development and runtime products has its own unique profile—almost a “personality.” Smalltalk, to take an extreme and rather unfashionable example, has an excellent reputation as a development platform. But nowadays most developers feel this is outweighed by its runtime limitations, such as relatively poor performance.

Even if a limited set of metrics can be agreed upon, there are still many uncontrolled variables such as application size, proportion of database access and other I/O to processing, user response time, scalability, hardware used, etc. Faced with such a daunting prospect, it is tempting for technicians to respond with their usual evasiveness: “How long is a piece of string?”

In spite of these obvious difficulties, Compuware did its best to provide helpful answers. After all, it is quite reasonable to ask any vendor for objective facts and figures about the quality, ease of use and performance of its products. After some thought, it was decided to explore the possibilities of Sun Microsystems’ Java Pet Store and its family of sample applications and benchmarks. This approach offered the following clear-cut advantages:

• Several vendors (including Sun, Microsoft and Oracle) had implemented similar applications in their attempts to demonstrate superiority of one kind or another. So the Pet Store concept was already well known in the IT industry.
• By using Pet Store as a starting point, Compuware avoided any suspicion that it might try to bias the exercise in favor of Uniface.
• Versions of Pet Store (Pet Shop, etc.) had already been created for J2EEand .NET, providing a convenient baseline.
• The Middleware Company (now serverside.com) had already performed a carefully objective comparison of Microsoft’s Pet Shop with Sun’s original Pet Store reference application.

To distinguish Compuware’s exercise from Sun’s Pet Store and Microsoft’s Pet Shop, it was decided to give the new sample application the distinctive and rather more stylish name “Pet Plaza.”

The Compuware team was aware of the controversy stirred up by The Middleware Company’s report, and didn’t want to publish yet another study “proving” the superiority of one particular product. Instead they set out to demonstrate Uniface’s capabilities and dispel some unjustified assumptions about it; in short, to generate light rather than heat. They decided to copy the Microsoft Pet Shop application, both functionally and visually.

There were other good reasons for taking this approach:

• Server technology has moved on since the earlier reports. To carry out a fair comparison Compuware would have to repeat all The Middleware Company’s tests with both the Java Pet Store and .NET Pet Shop. That would mean updating the software to the latest versions, which would inevitably change the “baseline.” Other than hardware, Compuware made only two configuration changes in Pet Plaza: to use Windows Server 2003 instead of Windows 2000 Server, and MS SQL Server 2005 instead of MS SQL Server 2000.
• Compuware needed to obtain the latest servers, at considerable cost. The company preferred to start with the sort of servers available to current Uniface customers for a reasonable price to estimate what response times and transaction throughput can be reasonably expected. In the chosen environment, the current retail price of each of the servers is around $3-$4K (probably less if you shop wisely). That is quite a modest investment.

Compuware is restructuring and enhancing Uniface with the pending release of AJAX7/RIA8 support and would like to produce a more complete study at that time. This follow-up study would include not only the Windows platform but also UNIX and Linux, perhaps on Sun hardware or even an IBM mainframe. As Pet Shop is not supported in these latter environments, it would be impossible to include it in comparative benchmarks.

The Compuware team concluded two important criteria had emerged from The Middleware Company’s exercise:

1. All things being equal, the fewer LOC needed to specify an application, the better. Given a constant error rate, less code tends to mean fewer errors. The work can be undertaken by a smaller team, thus reducing the communication difficulties that are the bugbear of big projects. The code becomes simpler to read and understand, so enhancement and maintenance are easier and less error-prone. On the other hand, there is really no obvious downside to a genuine reduction in code size.
2. A reasonably credible performance metric can be derived from the number of simultaneous users an application can support, given a fixed hardware configuration, transactional throughput and end-user response time. (It was on this basis that Microsoft claimed The Middleware Company’s tests showed .NET to be superior to J2EEEE).

Although the picture is somewhat blurred by the existence of powerful APIs and frameworks, both J2EEEE and .NET are essentially third-generation language (3GL) environments. That is to say, they are based on 3GLs like Java, C# and C++. Uniface, on the other hand, is based on a classic fourth generation language (4GL) which provides a more abstract (high-level) programming interface. In other words, each Uniface statement is equivalent to several lines of 3GL code.

Uniface excels in reducing the amount of code required to create a given application (the first of the two criteria listed above). On the other hand, it may support fewer users with a given configuration (the second criterion). To decide which criterion is more important, it is necessary to quantify them. In the words of the great physicist Lord Kelvin: “When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind.”9

If solution A can create an application with half as much code as solution B, while delivering 90 percent of the runtime performance, many IT managers would prefer A. If, on the other hand, A requires 90 percent as much code as B while delivering half the runtime performance, the decision would be expected to go the other way.

Uniface Pet Plaza: The Application

When Compuware set out to create Pet Plaza, it decided early on to base it (as far as possible) on Microsoft’s Pet Shop. There was little to choose between Pet Store (Java) and Pet Shop (.NET) as far as technology was concerned; Uniface differs from both J2EEEE and .NET more than they differ from one another. At the time, however, Pet Shop was the more recent; and it had apparently proved itself the better performer of the two.

Given that Pet Shop was supposed to be an exact equivalent of Pet Store, one might ask whether it was necessary to distinguish between them at all. Once detailed work began, however, it soon turned out that the two applications were by no means identical. For a variety of reasons, changes had crept in. Rather unexpectedly, some of the most obvious of these highlighted a key, though often neglected, feature of Uniface.

Developers often ask why Uniface stores code in a repository, rather than the more usual practice of keeping it in plain text files. Doesn’t this merely impose unnecessary overhead and cost? The standard answer is the repository ensures structural integrity, and helps eliminate inconsistencies and casual errors that may remain undetected in text files.

Figure 2: Sample screens of Uniface Pet Plaza

On close examination of Microsoft’s Pet Shop, the Pet Plaza team discovered some surprising inconsistencies. For example, the Oracle and Microsoft SQL Server implementations differ in quite unnecessary ways. One RDBMS uses a data type called “char” where another uses one called “varchar.” But the team noticed, for instance, the address field is 80 characters long in the SQL Server implementation, but only 40 characters long in the Oracle one. In the Oracle data definitions, moreover, the primary key is a different length from the related foreign key in the table it pointed to. Neither of these discrepancies will necessarily cause a given piece of code to crash or give incorrect results; but they might if the code was changed or extended later on. Simple inconsistencies like these wouldn’t get past any alert QA team. With Uniface, however, they wouldn’t get past the repository!

Perhaps aiming to maximize performance, the Pet Shop developers chose to use hard-coded text strings throughout, although the Java Pet Store included a complete multi-language implementation. Undeniably, the hard-coded text is more compact and speeds things up, but it did not seem fair to leave out a fairly substantial feature of the original application—and one that can often be business-critical. The Uniface Pet Plaza team decided to put the missing multi-language capabilities back again, even though this meant increasing the total number of LOC.

Other apparent defects in the Pet Shop code—possibly due to an excessive emphasis on performance—included a shopping cart total that does not add up and a billing address implementation that simply does not work.

Figure 3: Sample screens of Microsoft .NET Pet Shop

The first version of Pet Plaza was rather overambitious, adopting a more “state-of-the-art” architecture than either Pet Store or Pet Shop. It was a multi-tier distributed application, using XML as a universal communication format. Once the software was up and running, it quickly became apparent why this approach wasn’t more widely chosen. The serialization and de-serialization that accompanied every message, no matter how short, had a serious impact on performance. As the developers put it, it simply used up processor cycles for no real benefit. Because neither Pet Store nor Pet Shop used XML in this way, it was decided to remove the feature in Version 2.

Pet Plaza 2 does differ in one important way from Pet Store and Pet Shop. It doesn’t make extensive use of data caching. Otherwise, the aim was to duplicate Pet Shop’s functionality and look-and-feel as nearly as possible. The user interface is nearly identical as seen in figures 2 and 3.

Counting lines of code

Although Compuware set out to measure development productivity, the “elapsed time” dimension was impossible to capture realistically. The company spent more time writing Pet Plaza than would be considered normal to build a Uniface application as simple as this. The main reason was Compuware wanted it to look and perform exactly the same as the Microsoft Pet Shop, thus spending a lot of time validating layouts.

The other important productivity dimension is the amount of new code that had to be written, and this was much easier to measure. If you ignore the total LOC, and instead focus on the number of components, you will see that Java Pet Store was supported by 273 source files, Microsoft .NET Pet Shop by 65 source files and Uniface Pet Plaza by 26. True, two of these are Compuware’s own models but there is less inside than you might think. There are no indications in any of the studies of how long it took to build Pet Store or Pet Shop, so it’s difficult to compare elapsed development times. But let’s agree that creating and supporting 24 objects and two models looks more efficient than doing so for 65 or 273 files.

The previous studies used total LOC as a prime metric for comparison. This was perhaps the most difficult part to determine, as Uniface stores its code inside a repository, not in “flat’ text files like Java or .NET. The repository maintains relational constructs inside an application model that contains proc-code (Uniface’s procedural programming language) inherited by components as they are built and compiled. Compuware does not have whole libraries of external code as with Java and .NET. Interestingly enough, neither party chose to disclose how many LOC make up their various add-on libraries.

In an attempt to be fair, Compuware first decided to define some basic rules for proc-code counting. The company could have simply counted the contents of the XML export files, but these are in XML format (which is known for its verbosity). Because Uniface exports contain file layout and structure definitions as well as source code, the team needed an alternative and decided:

• Lines of inherited code—whether inherited from the model or template—would be counted where first defined, and not counted when inherited by triggers inside components. In the event that inherited code was changed in any way—becoming in Uniface terms a component variation—the code was included in the LOC count.
• Lines of included “type proc-code” were also counted when defined but not when referenced inside components. (Although the #include statement counted as one code line providing that the included statement itself was not inherited code).
• Uniface applications are event-driven by using a trigger mechanism. Uniface triggers are placeholders for proc-code that determine the action taken when an event occurs (such as a user action, proc-statement, asynchronous interrupt, or GUI event). All code in all Uniface triggers was counted unless inherited according to the above rules or as part of the Uniface defaults. If default code was changed, it was included within the count.
• All declared “defines” counted as one line for each “defines,” unless inherited according to the previous rules.
• Only comment lines where column one was a “;” were ignored; everything else was included in the count, just in case.
• Blank lines were not counted.
• No global or central procedures were used.
• Uniface messages used to define fixed text in the application were not counted. Usage of each statement line using the Uniface function $text() was counted, as these could have been replaced by fixed text in a monolingual application like the Microsoft Pet Shop.
• How to count the screen layouts was problematic, as these are stored internally and expressed in as little as a single line or broken down for each HTML tag. As the Microsoft study choose to count code based on how it is stored in files, we decided to do likewise and count the number of storage lines used to hold the layout information inside the database. This appeared to be consistent, as the internal NVU editor reformats the layout every time it is retrieved from the database and Compuware has no control over that process.
• Uniface defaults (i.e., those items beginning with “U”) were not counted because none of the defaults were changed in any way and they remain mandatory entries in the Uniface development environment.
• Templates and template code were counted.
• Only two global variables were used.

The results of counting lines of code

Component Type	Name		L.O.C.	Layout			Total
MODEL	PETPLAZA		30	0			30
MODEL	SYS		7	0			7
LIBRARY	PETPLAZA		203	0			203
EXTERNAL FILES	TOTAL OF THREE		113	0			113
USP	CATEGORY		11	23			34
USP	CHECKOUT		22	30			52
USP	CREATEACCOUNT		23	70			93
USP	DEFAULT		3	26			29
USP	EDITACCOUNT		16	64			80
USP	HELP		3	11			14
USP	ITEMDETAILS		15	30			45
USP	ITEMS		22	21			43
USP	MYACCOUNT		15	10			25
USP	ORDERBILLING		140	103			243
USP	ORDERPROCESS		37	42			79
USP	SEARCH		46	29			75
USP	SHOPPINGCART		211	53			264
USP	SIGNIN		35	32			67
USP	SIGNOUT		12	10			22
USP	SYSTEM		14	13			27
SERVICE	ACCOUNTSVC		17	0			17
SERVICE	BANNERCACHE		16	0			16
SERVICE	INVENTORYSVC		47	0			47
SERVICE	NEWORDER		128	0			128
SERVICE	SEARCHSVC		47	0			47
USPTEMPLATE	TEMPL2		23	2			25
USPTEMPLATE	TEMPL3		13	2			15
STARTUPSHELL	PETPLAZA		50	0			50
Total		1,319			571	1,890

Figure 4: Result of the LOC counter program. USPs are Uniface Server Pages, the
Uniface components used to create web pages.

Application	L.O.C.	Derived from
Java Pet Store:	14,273	273 text and Java files
Microsoft Pet Shop:	3,484	65 files
Uniface Pet Plaza:	1,959	2 models, 1 library, 2 USPtemplates, 1 startup shell, and 20 USPand service components

Figure 5: Comparison with Java Pet Shop and Microsoft Pet Shop as reporterd by The Middleware Company.

As stated before, the fewer lines of code to write and maintain, the better. Because of the higher level of abstraction for the Uniface proc language and the Uniface application model, far fewer lines of code are necessary. Compared to the Java and .NET implementations, which require two to eight times as many LOC, Uniface applications are faster to write and easier to understand.

In general, 3GL applications usually define or create a data access object or DAO to funnel requests through to the database in a consistent manner, minimizing data connections. If the database is changed, just this single definition or object needs to be replaced. The Microsoft Pet Shop uses this technique for the test under SQL Server and Oracle where it has two separate DAO objects for each database. There is nothing magic in this concept; just good programming practices that are equally valid whether you develop in assembler, COBOL or any other language.

Uniface already has that capability via its database drivers, so creating an additional component to route requests is pointless and a waste. A similar argument could be applied to the Uniface front-end, but in this case, Compuware decided to isolate simple data reads from potentially more complex data updates. The company created separate services to create orders and update inventory. Aside from that, Uniface lived up to its reputation of making things smaller, simpler and easier by maintaining a degree of simplicity with the remaining Uniface Server Pages (USPs), which was reflected in the low LOC count.

Figure 6: This chart shows the overall LOC count for Pet Shop, Pet Store and Pet Plaza and also the contributions of the various tiers. Compuware did not divide the application into tiers like Pet Store, Pet Shop and Version 1 of Pet Plaza. In any case, some of the conceptual reasoning behind multiple-tier architectures is inherent in the design of any Uniface application.

Uniface constructs

To achieve the degree of compactness achieved by Pet Plaza, Compuware adopted standard Uniface techniques with an emphasis on inheritance, use of templates, and reusing code wherever possible. As for including code inside the model, the system used two templates for all USPs. The company could have used more templates, but the greatest gain came through template code overlay inheritance for operations at the component level. Overlay inheritance allows you to define operations and then add other operations without replacing or invalidating the inherited code, which normally occurs when inheriting trigger code from the model. Taking into account the established rules for counting LOC, Compuware created a Uniface code-counter program that came
up with this analysis. The results of this counter program (see figure 4) are compared with the LOC of Java Pet Shop and Microsoft Pet Shop (see figure 5).

We established a common entry operation called “USPX” for all Server Pages that works like .NET’s “ASPX.” Among other advantages, this would make it extremely easy to add a validation scheme to help prevent “hacking.” We did not actually add that piece, as the Pet Shop developers didn’t either. The mechanism used by .NET Pet Shop to interact and pass web parameters via the URL was faithfully reproduced. This means in effect that you could intermix .NET and Uniface transactions and web pages by simply replacing “ASPX” by “USPX” and each would understand when to search, select products and add items to shopping carts.

To eliminate component variables which cannot be inherited from templates and to reduce initialization overhead, we deployed a single global variable and used a list to hold variable data that required persistence outside the context of an operation. Two inherited modules were used to get and set variable data. This technique allowed Compuware to initialize the entire application by setting the variable to “null” via the startup shell for every request, eliminating any possibility of carrying data across requests.

Compuware also defined a single “error” variable to initialize in the same manner, which was used to trigger a fatal error that was processed via a “system” component.

Two mechanisms were used for storing “stateful” data across requests: the Uniface state component and cookies. The Uniface state component was directed to use a local solidDB database10 instance, instead of imposing an additional load on the SQL Server 2005 database. Cookies are obviously restrictive in content length but they were more than sufficient for this limited exercise.

The .NET implementation on SQL Server 2005 uses identity columns to maintain unique order numbers. The Uniface MSS driver does not support this construct, so Compuware created an order record via a stored procedure that returns the new ID back to Uniface. The record was then immediately retrieved, while the remaining processing continued within Uniface. This stored procedure in Figure 7 is invoked via the Uniface SQL proc-statement.

Figure 7: The stored procedure invoked via the Uniface SQL proc-statement.

Database pagination

The application needed to mimic the same functionality and iterate through database selections in pages of four items per page. Web applications cannot use the Uniface hit list and some of the displays are not sorted, so using a selection to begin retrieval profiles based on the last item in the previous page is problematic at best. Compuware fell back on a technique used in the PHP scripting language (which has similar problems in this respect) and used the database retrieval profile to make the database present pages of information using the “TOP” and “LIMIT” SQL constructs.

When using the Uniface “where” extension, this required a SQL sub-query and the creation of a common proc to calculate the database offset and format the required where clause.

Using SQL Server 2005, the team built the routine to work equally well with Oracle, the other database used in the original test, and included the necessary code in the overall LOC count. To validate its practicality, Compuware extended this procedure to work with DB2, solidDB, MySQL and Sybase. Because these were not a part of The Middleware Company’s test, Compuware removed these lines from the final LOC count. For the record, they would only have added five more LOC per database.

Multilingual

The Compuware team retained the original Pet Store concept of a multilingual application, implementing both U.S. and French versions. Both text and images were controlled by the current language, which is derived from user preferences when logged on. In addition, Compuware set the browser language preference so users who were logged on with a browser default language setting were automatically identified, and the language switched to that setting. User preferences always override this action.
The 1st paragraph …

Conclusions

The Uniface model-driven development process is a combination of declarative development and coding. The information stored in the Uniface application model is sufficient to implement full working prototypes of enterprise applications, without writing one single line of code. Code written in Uniface only has one purpose: implement business functionality.

Delivered by no more than 20 Uniface components consisting of some 1,959 LOC, this study demonstrates Uniface is a development environment which allows developers to build enterprise applications efficiently. All necessary Create Read Update and Delete (CRUD) functionality is implemented automatically by Uniface.

When developing web applications with Uniface, delivering applications with fewer lines of code increases the potential for greater productivity and ROI.

If this was simply a race to build an application, we could probably stop here. However, all applications will change through time. In this area, Uniface excels. Some 3GLs rely on code generators and wizards to generate code. That’s great if you don’t need to change anything, but what if you do? With Uniface’s driver technology and platform independence environment, specific code changes become unnecessary in the first place. However, when real changes are necessary, re-engineering code, or to use the accepted term, re-factoring, is made a lot easier with the reduced number of components and code lines within a Uniface application and this, ultimately, increases an application’s return on investment.

A second but more subtle point is that 4GLs are sometimes criticized for being unable to do the things that 3GLs can do. Undeniably there is an element of truth to this. However, one of Compuware’s goals in duplicating these two sample applications, both visibly (in using the same images, database and environment) and functionally (with respect to transactions and interoperability) is to demonstrate that Uniface can deliver the same solution as a 3GL, but more quickly and with less code!