Software Architecture
By: Hermawih Hasan
Introduction
Specific for Microsoft® Access
4WH Formula
Where are the right places?
What things we should consider putting them in the right
places?
Who should make the decision about putting things on the
right places?
How we judge that one place is better than other places?
When we should take one option over the other options?
Sample
A ten years old boy approached and asked me, "What is
architecture?" I was stunned by his question. Soon I
realized that he had read title one of my books. At the time
I must choose a way to explain this as clearly and simple as
possible to him in order not to confuse him. Picking up that
book and reading it to the boy was probably not a good idea.
He might be nodding in agreement as I read the definition to
him. But I am sure that he would not understand it. Worse
yet if he will never ask me again for anything.
By putting myself in his shoes, I then described what
architecture is, "Putting things on the right places". I
then explained to him about putting things in our home at
the right positions. Supposedly that one of our toilet was
built near the dinning room, "What do you think?" I asked
the boy. Judging by his answer, I concluded that he got my
point.
At this article, I will not discuss about architecture
for a building. I will discuss about software architecture,
specifically application architecture built with Microsoft® Access.
Specific for Microsoft® Access
Why did I mention that this article is specifically for
Microsoft® Access? If you are developing a Microsoft® Access application using only Microsoft® Access for your
tool then you do not have choices creating library with
technology known as dynamic linking library "dll" or ActiveX
Control "ocx". Don’t be too disappointed. We could use other
techniques to achieve the same thing for your Microsoft® Access applications.
Depending on complexity of the library, creating libraries
using dll or ocx are not difficult as it seems to be. We
created our first ocx, using VB6 in just a couple of hours.
We can make it in a short time because there are so many
excellent books instructed us doing it in step by step
approach. That is not the case when you are creating library
using Microsoft® Access. Check your Microsoft® Access
books and search for a chapter for creating library. We,
Microsoft® Access developers, have so limited options in
"putting things in the right places".
If I tell you that it took me two years to figure it out how
to do it with Microsoft® Access, probably some of you will
laugh. Following instructions from any sources and creating
it on your own are very different matter. I did so many
silly things before making it worked. What I found is
simple, that makes me wonder "Why it took me so long to
realize the power of that knowledge". To be precise, I am
referring about using object oriented programming "OOP", and
creating many tiers application using Microsoft® Access. I
do not want to exaggerate it by saying those two
technologies, OOP and creating tiers are simple. I am
referring that if that information available for Microsoft® Access, I think we could absorb that technology in faster
pace. I think, I understand the reasons why we could not
find suitable information about those subjects in Microsoft® Access documentation. Those things are not simple and easy.
4WH Formula
I am sure that many of you reading this article are older
and wiser than that ten years old boy. To make things
simple, however, I will not change my approach. I will
describe this as you are all just beginners in programming.
So in that simple definition of architecture, we then could
ask:
- Where are the right places?
- What things we should consider putting them in the right
places?
- Who should make the decision about putting things on the
right places?
- When we should take one option than the other options?
- How we judge that one place is better than other places?
You see now that things are getting more complicated as I am
applying the formula "4WH".
Where Are The Right Places?
Where should we put our tables?
Where should we put our user interfaces?
Where should we put our class modules?
Where should we put our modules?
Where should we put our macros?
Should we put all our tables, user interfaces, class
modules, modules in one place or should we put them in many
different places. As I wrote this part, the term "Business
Objects" splashes into my mind. Should I explain this term
in this article? Well, I think I should not. With only two
words that term could be elaborated in one thousand pages of
a book. I will not complicated things even more. There are
so many good books about "Business Objects" available
created by much more experiences and abler authors than me.
My advice is, do not search that type of a book in
Microsoft® Access book category. You will not find any.
What things we should consider putting them in the right
places?
What should we put in a library, named xyz.mde? Should we
put only modules, only Class modules, only tables, or only
user interfaces in that library? Taking dynamic linking
library as an example, there is technological constraint
what we could put there. You can not insert any user
interface (form) in dynamic linking library.
Who should make the decision about putting things on the
right places?
This is depending on organization’s size and complexity. In
many organizations, this question can be answer easily
because there are not so many we. In many organizations,
programmer, user interface designer, person who does OOA &
OOD, and architect is referring to the same person.
How we judge that one place is better than other places?
There are at least two things to consider of how we judge
that one place is better than the others: performance and
flexibility or usability.
How the decision will affect application performance?
How decision will affect application flexibility or
reusability?
Unfortunately, we can not have both ways. We should select
one over the others. If we choose performance over
flexibility then in some ways the decision will affect
reusability. Putting tables, forms, modules, class modules
in one place will have better performance than putting them
in four separate places. But it will absolutely decrease
application reusability. That is simple example. In some
cases, these decisions are not that simple. Suppose you want
to create library for error message and library for user
management. Should we put those two different categories of
library in one place or should we put them in separate
places? We had that experience. We had six different
categories of library, including error message, user
management created separately in six different places. It
was not easy managing them in so many different places. So
we move them all in just one place and call them system
library. Up until now, we are not so sure whether that is
the right decision. It is a lot easier to manage. But when
we add more libraries to that system library, it will surely
increase the size. If the sizes are getting bigger and
bigger, we must then make another adjustment to separate
them into different places.
When we should take one option over the other options?
To answer this question, we should consider not only
technology but also economic reason.
How advanced is current hardware technology?
How advanced is our programming tools?
How much is the price to get faster processor, bigger memory
(RAM), and faster hard disk?
In the old days when prices of hardware are high, creating
naming convention to increase application performance makes
sense. But now with prices of hardware is lower then
creating naming convention so they will be self descriptive
is more logical. We do not want to waste our time memorizing
all the term we create for small benefit of performance,
don’t we?
Some of you probably heard about disconnected recordsets.
This term especially become more popular when ADO.Net is
introduced. Even without ADO.Net we could actually create
disconnected recordsets with a little bit more work and a
lot of memory usages. Many of our application processes are
executed using disconnected recordsets by using memory
cached. Our judgment using a lot of memory based on our
assumption that user will not hesitate to increase his/her
hardware performance by increasing its memory. If our
judgment is wrong, user with 64 MB on his/her computer, will
need tremendous patience waiting our program to run. So our
judgment is based on economic reason. If there are still
many people using slow processor and low memory then we will
just assume that they are not our target of customers.
Included with this article is a sample application to
demonstrate of how you could easily create user management
library. The sample is using two Microsoft® Access
databases. The first is main.mdb and the second is
usrmgt.mdb. The first, main.mdb will reference the second,
usrmgt.mdb. This can also be created using technique called
"creating add-ins". We do not like the approach because we
have to register it to the registry. You will find in the
sample that our approach is simpler and easier. You will not
find any useable code in that sample. Our sample is just for
demonstrating of how you can open a form from another mdb
without creating any registry. Probably some of you know
something about Xcopy development. Well, by using this
technique you can do that.
Click here to download
architect.zip. |
