COMMERCIAL AND PROFESSIONAL APPLICATION DEVELOPMENT
Part Four - From Conceptualization To Application

Written by Stéphane Richard (Mystikshadows)

INTRODUCTION:

Welcome to this Fourth part of this series. We've covered, I believe, alot of ground so far in this series, and this fourth part will be no exception. In this part we will be covering everything there is to know about the Development phase, or the Coding phase per se. We will be seeing what is available to you at this stage of the development cycle just as we have in the other phases. You'll also see here why the previous phases are important even in the coding phase. You need to understand that all documents, from the analysis documents to the modeling of the application play their role in this phase. You'll see how, and where, in this document. The coding phase is where you take all the knowledge, that you built from the analysis and conceptualization phase, and materialize them into an application. To do so, the right way, most big application projects will need a bit of preparation and documentation about different parts of the application to build.

With this in mind, let's begin this 4th part of the series by seeing what makes up an application and later we'll defined what is needed for each of them as far as documents (however detailed they may or may not need to be). Since our first target operating system is Windows™, the rest of this document will taking the target operating system into consideration throughout its contents.

THE MANY VISUAL PARTS OF AN APPLICATION:

Aside the objects defined in the UML Scriptual Model in the previous part of this series, there are also other types of components to consider when you are building an application. They each play their role in to proper operations of the application and well should be considered as independant of the main engines of the application. Here is a list of these parts along with their descriptions and considerations (if any):

• The Application Itself:
  In a windows™ application, there are 2 distinct standard when developing applications. The first that was created was S.D.I. (Single Document Interface) which tends to present every part of an application in it's independant window that offers no relation to the main Application window whatsoever. The other standard is called M.D.I. (Multiple Document Interface) and that one tends to offer the ability for other windows (usually the windows that pertain to the actual working document or database) as a child window to the main Application Window. This offers a visual indicator that a given form belongs to a given application and this is mainly why it became popular quite quickly. In our case, we will be using the M.D.I. standard means of presenting the application for all the popular reasons.


• The Menu System:
  The reason I mention The menu system this early in the list is because the menu system is usually and typically the part where all other parts of the application are accessed from. In the Windows™ operating system this is usually represented by a menu bar (at the top of a window) from which menu options are pull downwards when a menu option in the bar is clicked. Because of that action to virtually pull down the menu, this type of menu system was duely named a pulldown menu system. It was adopted way back in 1984 with C.U.A. (Common User Access) sub standard of the S.A.A. (Standard Application Architecture) standard as defined by I.B.M. The Menu bar typically have one word options only so when creating it you will need to make sure the top level of your menu are a list of one word options. The sub menues can have 2 or more words because they can be more detailed hence clearer this way. Again the C.U.A. standard defines certain common names for menu options that perform common tasks in all windows application you can look at other applications to see where these standard menues are and how they are named. Your menu should reflect that standard as much as possible to be easily learned by your users.


• The Main Application Form:
  Let's use examples here. For Microsoft Word™ the main application window is the Document, for Excel, it's the spreadsheet file. In the case of FinanceCAD, the main application window will be the window where the user can created their design on. It's the window from which the main supported file, document, format, datatabe are managed, editor or controled from. For the pulldown menu most function in the File Menu (usually the first in the list) create or close a main application window and most functions in the Edit, Insert and Format menues would typically affect the current main application window. The main application window will have a main drawing area (which will cover most of the window) along with 3 smaller windows offering alternate views on the main window (top, left and right views on the main design).


• The Accessory Forms:
  Indeed there's usually more than one of those involved. These forms are forms that affect what is currently selected in the main application window. For example, in Microsoft Word™ if you select text and go to the Format menu and select the fonts, a dialog appears letting you select which font you want, it's color, if it's bold or italic etc etc. When you close the form, whatever you selected on the form is then applied to the main document window's currently selected contents. This is the basic role of an Accessory Window. It's easy to see where we might need more than one. But they are used to help make things clearer and can be used at will. FinanceCAD will have at least one for each type of shape that can be inserted into a design as well as a special form to allow to preview and select the coumpound objects that can be built with the application to be used in any or all designs.


• The Independant Forms:
  These forms may or may not be related to the main application window. They can be forms that perform a task with the currently opened file such as the print document, or forms that have a specific purpose that is unrelated from the currently opened file (the printer options dialog is a good example of this). All you need to know is if the form needs the current main application window in order to get their job done, then they should be considered as accessory forms. In the case of FinanceCAD there will be many of these independant forms, for some example, the file open and save dialogs, the setting of the Design's scale (which doesn't need the main application window per see except that it affects it once a scale is selected). Usually File Open and File Save dialogs are considered system forms (see below) but in our case these dialogs will be custom made because of the added functionality such as design preview and others.


• The System Forms:
  These forms don't usually need any design. They are supplied either by the Windows API or the runtime library of the language being used. They provide standard OS functionality such as, but not limited to, folder selection, file open and save, standard font selection and standard color selection dialogs. No matter what the operating system running the application is, it is recommended to use the standard dialogs whenever there's no need for added functionality on the part of the application. For FinanceCAD, the file open and file save dialogs as well as the printer dialog will be created since we need more functionality that is provided by the standard dialogs. In many cases however there is no need to do this and you can use the system forms without a problem.


• The Option Forms:
  These forms have a very special purpose in a typical application. They serve to set the options that are to be made available globally throughout the whole application. What you will typically see is a global option form and a Document level set of options. They usually have tab controls to seperate the functional groups of options and one saves in the application's configuration file, the other saves it at in the document file itself. FinanceCAD will be no exception and will have application level options as well as design level options available to the user. For this we will need Option Forms as they are best used for this specific purpose.


• The User Feedback Forms:
  This type of form was created to give a consistent feedback to the user. Feedback is an important aspect of application development no matter what the operating system you are using. Today, no user likes to be left in the dark and wonder what just happened when he clicked on something or pressed some keyboard combination. If the button was there to let the user save a design for example, you should let them know that the saving of the design has been completed successfully and if there was an error, the user should be made aware so he doesn't assume that his design was saved when it really wasn't. Feedback form can play that role if used intelligently. They are typically used to report progress, errors if any, or even to allow to confirm that the user really wants to perform the selected action. Letting the user know what just happened and giving the user a chance to cancel an action is taken for granted these days simply because they are a given. Any application today should have them so they are expected no matter what the applicaiton is.

Those are pretty much all the forms you might ever need. Some very specific applications may find a different type of form but usually, simple common sense is all you need to figure those out as they are presented to you. I wanted to make a whole section on forms and dialogs because when you are creating an application, user interactivity is always an important aspect to your application, it's the part of the application that your users can make themselves an opinion on your work so when you design your forms, it's important to take the time to design them properly, align your controls, give your whole application a professional and consistent look and feel and users will like to use your application. Remember that you never get a 2nd chance to make a good first impression so the impact of your forms on your users should be top priority on your list of considerations especially if the application is to be sold commercially (in which case your forms also need to be universally acceptable to the common user).

And now that we also covered the visual aspect of an application, we can move on to the actual programming of the forms and the rest of the application. So let's talk a little bit about what development is exactly and see how we can go about developing the application.

WHAT IS THE PROGRAMMING PHASE:

The best way to describe the programming or coding phase is to simply say that this phase takes the documents and models as they were defined in the analysis and the conceptualization phase and creates an application that confirms to these documents and models. Sounds simple doesn't it? In a way I would say that it is that simple, long because applications this size still need a minimal time to code for, but simple nonetheless. Because of the importance of the visual aspect of an application as describe above, I would highly recommend breaking the coding phase into two independant sections. These sections are:

• The Visual Design Phase:
  Yes some may argue that the design phase could have happened in the conceptualization. Maybe, in some cases, it can. However, when you think of what you have at the conceptualization phase, all you have, typically, is required information, work to be done and desired output. You just don't have a complete baggage of information to design your forms. You could maybe create a rudimentary form to show your users, but chances are you'd have to change the design of your forms at least a few times before they are actually approve. Not to mention that during the conceptualizaton phase even the required input might change dramatically. So I like to have a whole phase dedicated to design forms like this. this way, every knows the phase is coming and everyone can plan to have some validating and aproving to do on the design. It also allows to close the design phase with atleast a minimal degree of certainty so that when these forms are to be coded, there are less chances that the forms would change as this phase is created to take the time to approve the forms.


• The Programming Phase:
  At the same time as the design phase, if you have enough programmers to do so, these programmers can start working on the non visual aspects of the application. There is always a non visual aspect and the more time you have to work on that part, the better. This is the place to start creating some test cases for the code to come whether it is a form or some calculation engine or whatever other parts of the application that will ultimately need to be thouroughly tested. With the model of the application that you created at the conceptualization phase, along with the user requirements documents and the detailed analysis, you should have everything you need to accurately produce the solution to the problem at hand, in our case, FinanceCAD. The time to attribute to the development phase depends on how many forms you need to create, how many engines (or non visual elements of the applications) and of course the number of programmers that you have at your disposal.

I should note that sometimes the Visual Design Phase is spread out across the programming process in that each form is first designed, shown to the users to be approved, then the inner workngs of the form are coded and the form is then put to the test. I say this because not every company works the same way, but even if done on a form by form basis, the design phase is still very present and very important, it would be futile to create a form, code everything that goes under it, then show it to the user to see if they like it because you have 1/2 chances that they won't like it and you'll then have to start over from scratch. In the corporate world that's a very big lost of time for you, your team and the users which also means it's a waste of money. The more of these little waste of times you can avoid, the better it is for the life of the project, that goes without saying of course. Once again good planning from the start, all the way to the coding phase helps prevent alot of these situations just because you took the time to think about things for a little bit.

Of course, to begin the coding phase, it makes sense to know what programming language you'll be using since, obviously, it will be your main tool from now on in the development cycle. The following section will help you make the choice of language by highlighting some language features that you might want to consider for the project at hand. I will be covering the languages at the language level itself, not the brand of compiler. I will show you the popular compilers for each language however but just as a reference, not as a criteria for selecting the language itself.

WHICH PROGRAMMING LANGUAGES SHOULD YOU USE:

That is always a big question, it's not always as simple as saying "well everyone's using this language so I'll just go ahead and use it", atleast, it shouldn't be. The choice of language is just as important as the choice of tools you'll have to make throughout the rest of the development cycle and depending on the project, that can represent a big portion of the project's life. So then, what makes a language better suited for a given task? Well, if you really know what the task is, it's easier to come to a decision if you also know your languages. Of course, this is an ongoing debate, C and C++ programmers will argue that only C or C++ is the language to use, Ada developers will say otherwise, Pascal programmers will have their version of the story, VisualBasic users, well, you get the idea. You really have to sit down and write some list of consideration to choose the language. You see, all language manufacturers boast their own respective language as beeing an all purpose language capable of taking of all possible types of projects and project sizes. Now you need to take a step back, and think about what you want for your application and see what languages meet the criteria. Let's review what feature of FinanceCAD we have and let's see what we can determine from them:

• FinanceCAD is a Graphical Application:
  That is actually very important to mention right upfront. Let's face it, if you write a graphic routine, put it in a loop, execute it 1,000,000 times, you'll quickly notice that some languages handle graphics in a lighter and faster way when compared to others. Sometimes that difference is almost negligeable but in other circumstances, because in our case, FinanceCAD, being a graphical application, should be the fastest it can be as far as graphics are concerned. When I say graphical I don't mean that the application runs on a graphical user interface, I mean it creates graphical design files. All language can create Windows Application today, that doesn't make them all suitable for an application that manages and processes vector graphic files. The same goes for the Linux KDE, Gnome, and other Graphical User Interfaces you may encounter on any platform you may encounter as well. If the application has competition like the case of FinanceCAD, then performance becomes the most important issue quite quickly. these are the types of questions you need to ask yourself when choosing your language.


• FinanceCAD will be multiplatform:
  Pretty much all language have some implementation in most existing platforms, that's not a secret, however, not all language were designed to be multiplatform. Some languages will require quite alot of work to be ported to it's equivalent language in another platform, other languages just seem to flow between platforms like they were made for all of them. If you plan on porting your application to more than one platform, the choice language will determine the amount of work you'll need to actually port the application and that can be a very important factor if time, or costs, are important factors to the project. If we were to assume for example that FinanceCAD would only be developed for the Windows™ platform this feature wouldn't even be in the list but since it is to be multiplatform we have to take it into consideration when selecting the language. You'll see later that there are libraries available that can save you alot of time for GUI design for a multiplatform project and they too should be considered, even used whenever possible to minimize the porting time involved.


• FinanceCAD will need databases:
  As you remember, there's a considerable amount of database related functionality to be done. We need to stop and ask two important questions. First we need to ask ourselves what database should be used for the project as in what specific database features we are looking for. Here we need basically some querying capability so that should tell us that and SQL compliant database is in order. Second, we need to ask ourselves how easy it is for the language we'll be using to access these databases. Indeed, languages like Microsoft VisualBasic™ and Borland Delphi are known to be languages that can very easily connect to most databases available out there. Others may allow to connect to a database but with very specific set of low level functions that tend to become more problems than is usually worth. I say usually because in some cases, the rest of of the features of the application can superseed any problems or complications that can occur from using low level database API such as ODBC32 and others. It really depends on the nature of the application being developed. In our case, because of the 2nd level priority of the database functionality (2nd priority here means that FinanceCAD is a Design tool first, then a financial Analyst) I don't believe it would be worth the while to create low level API database calls. So our choice of language will have to consider easy connectivity to the database we'll be using.

Let's just stop at these three features because they should be enough to make our choice of language. Of course not all projects would allow you to make a decision based on three features, but in the case of an Autocad like application, like FinanceCAD is, these three features should be quite enough to come to a decision. To recapitulate, we want a language that is very fast on graphics, can be ported at least to the linux platform without the need to rewrite the whole application from scratch and while keeping the porting effort to a minimum. And we want a language that can connect to a database quite easily and trouble free. Let's look at some of the languages available and see what features they offer.

• Ada Programming Language:
  The Ada language is among the oldest language available today. However it is also the language that has passed the test of time with flying colors. Originally developed by the American Department Of Defense as a better language for military applications, it now offers these features as an all purpose development language. Ada is truely at it's best in embedded system and long lived system. It is designed to be fast, efficient while being the most readable language to date. It excels where the programmer that is modifying the code is not necessarily the programmer that created it. This is where readability of code is of highest importance and Ada was specifically designed for this type of project. It's greater features are it's data structures, it's tasking model, and it's version of Object Oriented Programming Paradigm. Ada has no problem being compiled on many of the platforms that are available today. A few of the well known Ada compiler vendors are: AdaCore Technologies, Aonix and RR Software.


• BASIC Programming Language:
  Well BASIC (Beginner's All Purpose Symbolic Instruction Code) pretty much speaks for itself. It's a language designed to be learned quickly to say the least. As such it is usually very limited in terms of keywords and usage. However there are many exceptions today that tend to push BASIC as a considerable alternative to other languages. Today BASIC is now compiled to native code which gives it a speed feature that cannot be ignored at least in some cases. Today's BASIC is Object Oriented, most windows implementation have a strong integrated support for databases and reporting technologies. All in all BASIC compilers should be considered for many database applications because of the speed of development that they usually offer. The flaw in commercial BASIC compilers is that most have limited multiplatform abilities. To name a few BASIC implementation are: Power Basic™, Microsoft VisualBasic™ and PureBasic.


• Pascal and ObjectPascal Programming Languages:
  Pascal started out as an excellent learning language, at least it was it's original goal at the time. Since it first came out however, Pascal has seen many incarnations and is getting some very good scores as far as all around performances go. It offers solid Object Oriented Extensions thanks to the ObjectPascal implementation and offers a great feature called inline assembly (for those really low level programming needs). Because of it's teaching origins, Pascal and ObjectPascal are language that have a very strong and defined structure, this helps a great deal in making code that is organized and readable. The best known Pascal Compiler is of course Borland Delphi™ and Borland Kylix™ for the Linux platform.


• The Java Programming Language:
  Java is the latest craze in the programming industry. it is also the newest and is fast becoming the prefered language for all online development. In my opinion, Java is getting more credit than it deserves because in my experiences, Java is not the fastest language available. the language is nice to code in however and I believe that this is it's strong point as far as it's popularity goes. As an online language it's performances are adequate. But As a compiled language, it is far from the fastest alternative available. Perhaps, speed and performance should be the only goal of the next release of Java. Commercially, only Borland JBuilder™ is worth the attention in my most humble opinion.


• C and C++ Programing Languages:
  These are by far the most widespread of all languages available today. I believe C and C++ are the most opportunist languages there ever was. Most C programmers will swear by C and C alone. Same thing for C++ programmers. Notice that I tend to seperate the two languages. I do have a reason for it, C is not C++ and C++ doesn't have C in it. In other words, these languages took very independant branches when C++ was first implemented and that hasn't changed since. C and C++ are renouned for their speed and performances. They are also known to be the most crytic and non readable languages available today. C++ integrates the STL (Standard Template Library) and that gives it part of it's power. As far as commercial compilers go however, I haven't found one that was truely multiplatform. One comes close as far as Linux and Mac OS X and that is the XL C/C++ developed by IBM. Like Ada, C/C++ benifit from a large userbase and an OpenSource C++ community that keep the language striving and accessible to people that don't necessarily have the big budgets to buy the commercially available compilers with today's price tags. In my opinion, C and C++ should be used in conjunction with the other languages where there is a real need of performance. However, programmers could use Assembly language to even more performance gains. There are two well known commercial C/C++ compilers. There is Microsoft Visual C++™ and Borland C++ Builder™.

Before you go ahead and wonder why I haven't mentionned any other language as a feasible solution, you need to remember that this series is aimed at professional and commercial application development. In this context I have stopped my suggestions to what is commercially available only. I know there are many other languages, each with their own set of features and I believe each language is a work of art and art is a question of taste. One thing I don't like is a group of programmers of a language bring other languages down because they are not the language they would choose to program in. So this is not the object of this series of documents. The object is to give you, the professional programmer a lead on what's available out there. If you choose whatever language, it really doesn't matter to me as long as the language you choose gets the job done for you. In this document I'm just trying to give you a few pointers to help make sure you select the language that is truely suited for your particular big scale projects. With this information there are two more things we need to cover for FinanceCAD and for alot of other projects as well. There is the issue of finding a good multiplatform GUI library so that the visual aspect of the application can be ported with minimal to no effort between the platforms we will want to support. And the issue of which database we could use for our database and reporting purposes. Let's get right into it shall we?

ARE THERE GOOD MULTIPLATFORM GUI LIBRARIES:

This questions ringed in my head many times in my career. The biggest issue, when it comes to multiplatform development projects is none other than the user interface, the visual aspect of the application. Windows™, KDE, Motif, Gnome, Mac OS X all have specific functionalities available as far as how controls are built, drawn and managed at the operating system level. If there weren't any good multiplaform GUI (Graphical User Interface) multiplatform libraries out there, this would surely raise alot of concerns at pretty much all phases of the development cycle. Surprisingly, my recommendations here are not all at the commercial level as it seems that the libraries I will be suggesting here seem to offer better control and a better coding experience than anything I've seen commercially available. Of course, if you are creating a text mode application or a 100% GUI independant graphical application then the issue of multiplatform GUI is irrelevant in your particular case. We will be looking at four widely used GUI libraries so that you know of their existence for one thing and that you have a brief overview of how it works and how you could potentially use it in your application projects.

• The Qt Class Library and tools: [Commercial]
  The Qt Class Library and tools is my only commercial recommendation. In the words of the website: "Qt is a complete C++ application development framework. It includes a class library and tools for cross-platform development and internationalization. It achieves its goal by abstracting low-level infrastructure functionality in the underlying window and operating systems, providing a coherent and logical object-oriented interface that makes sense to programmers". From what customers seem to say from this library, it comes highly recommended because of it's relatively small learning curve for the capabilities that it offers.


• The wxWindows GUI Development System: [OpenSource]
  The wxWindows System is what seems to be a highly object oriented based hierarchy of GUI objects that are designed to be drawn independantly of the operating system they are executed under. Although an opensource solution, wxWindows is used in many commercial applications already, and the main reason is performances in a multiplatform GUI library. From what I've seen, wxWindows offers many more controls than even Qt (see above) and the inner organization of the hierarchy of control object is logical and sensible. I would recommend it for a vast range of application development. Take a look around on the website, don't just take my word for it, see for yourself why wxWindows is listed in my recommendations.


• GTK (Gimp ToolKit) Library: [OpenSource]
  The The Gimp ToolKit is probably the most widely spread OpenSource multiplatform GUI toolkit I've ever seen. Another important aspect is that it's probably the toolkit that can be used by the widest list of programming languages. If it wasn't for the need to tweak the library in order to get it to perform reasonably on the speed scale, this toolkit would have been strongly recommended. Indeed this one is not for anybody to just install and use efficiently. Users do report that when tweaked appropriately, the performance of the application rivals those offered by the other toolkits or even faster, I have no personal experience using GTK so I'll just have to take the time to tweak it myself to make my own judgement, if they are right, perhaps GTK would deserve your time to take a serious look at.


• TCL/TK (Tool Command language/ ToolKit): [OpenSource]
  The TCL/TK (Tool Command language/ ToolKit) is part of my recommendations because it has it's very unique means of creating a user interface. It is a scripting language, in essence, and what it creates can be used in a good range of programming languages. People that use TCL/TK can't help but brag about it's features and methods of doing things so because of that royalty from it's users, I had to recommend it if not for any other reason, so that you know it's there, it's different, and it's definitaly worth looking at. There is alot of reference available on the internet that you can learn from so that gives it another good reason to be considered.

These are the four toolkits I can recommend. If you take a look at the links I provide to each of them, you can get a much better picture of what the toolkits are capable of and where they have been used so far. You will aslo be able to make a better judgement as to which library you should consider for your programming project. Just remember that, as you can see, there are tools and libraries available to greatly help you when the time comes to port your project to other platforms.

WHAT ARE MY CHOICES FOR A GOOD DATABASE MANAGEMENT SYSTEM:

The first thing I can say about the databases is that they all do one thing in common. They all serve to manage databases and each databases consists of table structures, primary keys, indexes and the likes to present the data in desired orders and to allow to quickly locate records in the tables. All the databases I am recommending here also offer SQL (Structured Query Language) which allows for a complete range of database maintenance functions and reporting purposes. In order to select the right database for the job, you need to take a look at the exact reasons why your project would be using the database in question. How powerful does it really need to be to meet your specific needs depends on what the needs are to begin with. There are 6 database I would like to recommend you look at. 3 of them are commercial products, the others are OpenSource (for OpenSource projects) and have licenses available for commercial development using those database systems).

• The Oracle Database System: [Commercial]
  Oracle has been there since pretty much the dawn of the PC industry. It offers a complete range of features as far as databases are concerned. For example, it has SQL (Structure Query Language) for database interrogation, stored procedures you name it. Oracle is typically installed on a Unix or Linux server and can be easily accessed from Microsoft Windows™. It's performances speak for themselves and it is used in places where reliability is of high priority. Oracle features a rich set of tools and utilities to help the maintenance of the databases and the generation of queries and report to give it's users full control of the data and it's processing.


• The Sybase Databases: [Commercial]
  The Sybase Databases are offered in two flavors so to speak. There is the classic Sybase Database Management System and Sybase SQL Anywhere (specialized in portable computing and data replication). Like Oracle, the classic Sybase Database is typically installed in a Unix or Linux environment and offers pretty reliable and secure database management system. For the Windows™ platform, connecting to Sybase is as easy as having the right connection string. Sybase offers stored procedures, SQL for it's queries and a good user interface, a bit easier to learn in my opinion than Oracle that offers intuitive means of creating and maintaining your databases.


• Microsoft SQL Server™ Database Management System: [Commercial]
  The The SQL Server Database Management System has already been available for quite some time now. In my experience it is by far the easiest to learn and still Microsoft managed to pack a full range of features and a full range of application to help you in your database management and database programming endeavours. As far as FinanceCAD is concerned, the face that SQL Server is only available for Windows pretty much eliminates it for a central database. Or at least it would mean that table structures, relationships and indexes will need to be converted to the new database for the other platforms.


• The MySQL Database System: [OpenSource/Commercial licenses]
  The The MySQL Database System is probably the closest cousin to SQL Server that you will ever see. The SQL syntax is very close to SQL Server so migrating the database between the two databases is almost a sinch. MySQL can be installed in Windows and Linux so portability between those platforms are as good as they get. If you are to develop a commercial application with MySQL as your database however, you will have to contact them to purchase a commercial license of the product. At the time of writing, MySQL doesn't support stored procedures, however, it will in the next major release of their product.


• The PostGreSQL Database System: [OpenSource]
  The PostGreSQL Database Management System is probably the oldest freely available database management system available. As such, one can say it is also the most tested of them all hence the safest to use in all of the free database systems. That's not far from the truth and many applications developed to support MySQL as their database are starting, more and more, to offer the usage of PostGreSQL as well. As far as SQL goes, it's implementation in PostGreSQL is still SQL 89 compliant whilst the other databases are typically at leas ANSI SQL 92 compliant. But that doesn't stop it from being a good all around reliable database to use. It can be installed in any Linux configuration and version so compatibily isn't really an issue.


• The Firebird Database Management System: [OpenSource]
  The Firebird Database Management System is the OpenSource version of the well known Borland Interbase version 6.0. As a follower to a commercial product now available freely through the OpenSource community, Firebird offers some very advanced features as is expected in a commercial quality product. It has stored procedures and has had them for a while now. I still fail to see why this database is not more widespread than it is. But if you sit down and compare features you'll be tempted, like many before you, to consider Firebird quite seriously and rightfully so. It installs in Windows™ and Linux so it answers the call of our multiplatform criteria quite well. As many other OpenSource projects, there is no ownership, no one is responsible for any error produced by the database system and that is often a show stopper in teh commercial world. Me, if it does the job, I would have no problem recommending it.

There are of course other databases available. These seem to be the most widely used and that is basically why I recommended those. Depending on the database needs however you might find other databases outthere that answers your needs without giving you all the power that are offered by those listed above. For example, I can think of two systems that offer their databases as engines that you can include with your appliation, they are smaller, and probably faster (for smaller database tasks) than the 6 listed. They are SQL Lite and Suneido. It all depends on your specific database needs. So to know which database you should use, you need to know exactly what you'll be doing with the database as in it's specific role in the application. You can find this kind of information in the detailed analysis and the application model but usually, the detailed analysis is where it should at least first appear.

AND IN CONCLUSION:

That was a big chunk of theory I threw at you in this part of the series. You might want to reread this a few times and take the time to visit the links I provided to get better acquainted with the products that you can choose from and do a little research just so that when you need to use this theory, you'll be a bit better equipped to make the choices that will drive your project to it's success. I think that by now you noticed that I always seem to be pushing the need to be as prepared as you can be between the different parts of the application development process. You're right, I am pushing this, with a good reason too. I strongly believe that being prepared is the only way to take on a project of these sizes (the big scale projects). You have to think in terms of what you have versus what you need. the more closely these two lists follow each other, the less questions you'll have to ask later and the less research you'll have to do at a later time in the project. The less research in the analysis, the faster the analysis can be completed, and this rolls off and accumulates itself throughout the whole development cycle too. All the time you can save at the beginning will shorten your project's development life. If you are developing a commercial product, I'm sure you know that especially in that case, time is of the essence. You need to get things done fast, and right. And the better you can do that, throughout the development process, the better for the project and for you too, of course.

In the next section, we will be looking at that ever eternal phase I "not so affectionately" like to call "testing and debugging". Yes, every programmer's nightmare, it is unevitable no matter how well intensionned you and your development team are, sooner or later, you will fall into this phase. Rest assured however, there are many tools to help you out in that phase too. We'll see what they are and the role they play. We'll also see how to best prepare for that phase too (indeed preparation plays an important role here as well). So until then, if you have questions and comments, by all means, do email me and we'll see what we can do to clear things up for you. Happy reading and see you in the next section.

MystikShadows
Stéphane Richard
srichard@adaworld.com