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.

1. 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 eighth
the 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

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

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

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

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

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

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

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

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

10. 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!