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.

Development productivity study: Uniface delivers 3GL app in less time, using less code Study shows the reference application written in Uniface, Pet Plaza, requires one half to one eighththe lines of code needed by equivalent Java or .NET implementations.

WHITE PAPER: COMPUWARE UNIFACE

EXECUTIVE 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 EE (formerly J2EE) 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 EE 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 J2EE 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 white paper 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 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 USP templates, 1 startup shell, and 20 USP and service components

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 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 white paper will explain the origins of Pet Plaza, and present our findings about Uniface’s development productivity compared to those of J2EE and .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. J2EE also 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 J2EE best programming practices and design patterns, and to demonstrate J2EE’s key features for building enterprise applications. Another goal was to confirm the portability of J2EE applications 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.”

1 http://en.wikipedia.org/wiki/C._A._R._Hoare

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, J2EE was 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

2 http://www.theregister.co.uk/2001/11/12/pet_vs_pet_ms_opens/

3 http://www.ddj.com/184414966

4 http://www.theregister.co.uk/2001/11/12/pet_vs_pet_ms_opens/

5 http://databases.about.com/od/sqlserver/a/storedprocedure.htm

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.” 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 J2EE and .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 AJAX 6/RIA 7 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 J2EE).

Although the picture is somewhat blurred by the existence of powerful APIs and frameworks, both J2EE 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.” 8

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.

6 See: http://en.wikipedia.org/wiki/Ajax_(programming)

7 Rich Internet Application, see: http://en.wikipedia.org/wiki/Rich_Internet_application

8 http://www.todayinsci.com/K/Kelvin_Lord/KelvinLord-Quotations.htm

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 J2EE 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.

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.

Figure 2: Sample screens of Uniface Pet Plaza

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.

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.

Figure 3: Sample screens of Microsoft .NET Pet Shop

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 termsa 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 gloval 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

USP TEMPLATE TEMPL2 23 2 25

USP TEMPLATE TEMPL3 13 2 15

USP TEMPLATE PETPLAZA 50 0 50

TOTAL 1,319 571 1,890

Figure 4: Taking into account the established rules for counting LOC, Compuware created a Uniface code-counter program that came up with this analysis. USPs are Uniface Server Pages, the Uniface components used to create web pages.

Figure 5: This table compares the LOC required by Uniface Pet Plaza with those of Java Pet Store and Microsoft Pet Shop, as reported 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 5: 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.

IMPLEMENTING SUN’S JAVA PET STORE WITH MICROSOFT .NET AND UNIFACE

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 USP templates, 1 startup shell, and 20 USP and service components

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.

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 database 9 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.

CREATE PROCEDURE [dbo].[SaveOrder]

@P_UserId varchar(20),

@P_OrderDate datetime,

@P_ShipAddr1 varchar(80),

@P_ShipCity varchar(80),

@P_ShipState varchar(80),

@P_ShipZip varchar(20),

@P_ShipCountry varchar(20),

@P_BillAddr1 varchar(80),

@P_BillCity varchar(80),

@P_BillState varchar(80),

@P_BillZip varchar(20),

@P_BillCountry varchar(20),

@P_Courier varchar(80),

@P_TotalPrice decimal(10,2),

@P_BillToFirstName varchar(80),

@P_BillToLastName varchar(80),

@P_ShipToFirstName varchar(80),

@P_ShipToLastName varchar(80),

@P_CreditCard varchar(20),

@P_ExprDate varchar(7),

@P_CardType varchar(40),

@P_Locale varchar(20),

@P_ReturnValue int Output

AS

BEGIN TRANSACTION

INSERT INTO ORDERS(USERID, ORDERDATE, SHIPADDR1, SHIPCITY, SHIPSTATE, SHIPZIP, SHIPCOUNTRY, BILLADDR1, BILLCITY, BILLSTATE, BILLZIP, BILLCOUNTRY, COURIER, TOTALPRICE, BILLTOFIRSTNAME, BILLTOLASTNAME, SHIPTOFIRSTNAME, SHIPTOLASTNAME, CREDITCARD, EXPRDATE, CARDTYPE, LOCALE)

VALUES(@P_UserId, @P_OrderDate, @P_ShipAddr1, @P_ShipCity, @P_ShipState, @P_ShipZip, @P_ShipCountry, @P_BillAddr1, @P_BillCity, @P_BillState, @P_BillZip, @P_BillCountry, @P_Courier, @P_TotalPrice, @P_BillToFirstName, @P_BillToLastName, @P_ShipToFirstName, @P_ShipToLastName, @P_CreditCard, @P_ExprDate, @P_CardType, @P_Locale) SET @P_ReturnValue = SCOPE_IDENTITY()

COMMIT TRANSACTION

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

A popular in-memory relational database management system, see: http://www-01.ibm.com/software/data/soliddb/.

9

Compuware Corporation, the technology performance company, provides software, experts and best practices to ensure technology works well and delivers value. Compuware solutions make the world’s most important technologies perform at their best for leading organizations worldwide, including 46 of the top 50 Fortune 500 companies and 12 of the top 20 most visited U.S. web sites. Learn more at: compuware.com.

Compuware Corporation World Headquarters • One Campus Martius • Detroit, MI 48226-5099

© 2012 Compuware Corporation

Compuware products and services listed within are trademarks or registered trademarks of Compuware Corporation. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

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. MULTILINTGUAL

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.

CONCLUSION 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!