Part Four - From Conceptualization To Application

Written by Stéphane Richard (Mystikshadows)


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.


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):

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.


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:

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.


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:

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.

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?


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.

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.


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

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.


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.

Stéphane Richard