Model Driven Architecture..Huh! What is that?

As you all would have noticed, lately I have been pondering a lot about architecture, design and the way software development can be made easier for the software community. Well, this led to me Model Driven Architecture. Now, you would wonder-what is different about Model Driven Architecture? After all, all software starts with design where you develop a sort of model of the end software.

First let me try to explain a problem which we software developers face almost everyday-CHANGING TECHNOLOGY. First there was VB, then came VB.NET, first there was remoting, then came web services. Each time a new technology comes into the market, lot of rework needs to be done. Add to this the plethora of rapidly changing requirements and the ability that your software needs to interact with other systems and you get a fairly complex scenario which haunts you everyday. I on a personal basis hate the client asking me to change the application so that his application can run on Oracle database as well.

Allow me to explain a little more, Model Driven Architecture is a new way of writing just what you thought-“Specifications”. Here, no technology is taken into consideration. So, what do you exactly write? You develop a platform independent base UML model aptly called Platform Independent Models (PIMs). You are not supposed to concentrate on the language to be used or the database on which the software will run or the number of frigging threads the application will spawn. You concentrate only on the functionality and the end behavior of the application. There is no relation what so ever with the implementation details.

So, what is the benefit of this sort of architecture?

With today’s fast changing technology environment, lots of new platforms and infrastructure are coming into the market. Now what happens to your existing applications? If your applications have been written solely targeted towards a particular platform or infrastructure, then they become redundant-right? So, that means you lose all your investment that you have been putting into technology hoping for a better tomorrow. Now, that’s a really scary situation. This is where Model Driven Architecture steps into the picture.

MDA is already being projected as the next big step to be taken by the software industry. At the heart of the MDA development is UML, which involves developing models in order to develop your application. So, during the analysis of the requirements, UML is used to develop a model in a standard way which acts like a blueprint for your application. But you would be wondering how can just developing a model, lead to the development of the entire application. So, here in order for the application to be targeted towards a particular platform or infrastructure, the Platform Independent Model needs to be converted into a Platform Specific Model (PSM). So, if you wish to put it into simple words, a PIM sits at the center of the application and then a PSM is written around the PIM. The PSM can be written in any technical language-be it CORBA, or .NET or JAVA. The business functionality and the behavior of an application are etched into the PIM and the UI and the UI components are written in any available language.

It is then the responsibility of the platform specialists to convert the model into one targeted towards a specific platform like CCM, EJB or MTS. Standardized tools are used in order to do this conversion from PIM to PSM. This is one area where a lot of scope is still there for research and development due to the fact that although the tools being used today use standard mappings to do the conversion, there is still a lot of human intervention involved. So, this is a sort of developing art which needs some hand-holding even today.

The next step is the actual generation of the code. Finally, the software developers would have heaved a sigh of relief here-after all what will they do if everything is done by the model. The actual code generation will involve generating a lot of configuration files, interface files and so on. If the models generated using UML are complete or encompass the entire functionality of the application, there will be lesser work to do during the PSM conversion phase and the better the application nitty-gritty’s and runtime behavior have been handled in the PSM, the lesser code will have to generated.

This type of architecture is still in its infancy stage right now and if you expect that you can generate all your code using models TODAY, then you are probably mistaken. MDA offers just another layer of reusability below the development tools which we all are already using these days. This art of architecture still has to grow a lot before we start searching for expert UML modelers rather than expert C# developers.

Domain Driven Design

Well, a couple of google searches later, I have come to know that there is infact a community of developers who are working on providing domain specific designs and they have coined a name to it-Domain Driven Design (DDD)-COOL!

DDD works on the assumption that all software that is developed is BASED on a proper understanding of the domain-its intricacies, its complexities. So, rather than spending hours trying to solve the technical complexities, a developer should be spending more time with the analyst or domain expert trying to understand the complexities involved in the domain on which the software or code piece is to be written. DEVELOPERS AND ANALYSTS WORKING TOGETHER??? Since when did this become possible? After all, they are supposed to be entirely different backgrounds. A developer might be someone who has done his B.S/B.Tech., whereas the analyst might be some arts graduate who has done his MBA from some B School and has some expertise on the domain say finance. How can these two different types of creatures survive together?

But howsoever impossible it might sound, the domain and technology experts need to sit together and pool in their knowledge of the domain so that it can form the basis of the software. Together, their knowledge can be invaluable (obviously only when the mostly egoistical programmer learns to share his/her knowledge ;-) ) This is not so impossible, since I have to come to know that in a large account of Tavant Technologies the developers are in fact working with the analysts in order to understand the financial domain more-thanks to Nitish for this information.

Design Patterns based on Domains

Recently we have been discussing around domains-which problems we had faced while working on what domain, how we had solved it, which domain offers more job opportunities and stuff like that. This made us come up with the premise that probably there should be design patterns targetted towards specific domains. Since design patterns offer solutions to complex problems which have been faced by developers across technologies across the world, maybe there should be a forum where similar design patterns are discussed for problems faced while developing an application for a particular domain. Dont you think this would offer more lucid designs and help architects and developers to think alike. Rather than focussing on some technical issue, they can rather concentrate on providing a better solution itself to the user. Need to do some research on this.

AJAX or AHAB???

Recently I was going through Peter Bromberg's blog and happened to go through his archives. I saw the article This Just In: AJAX doesnt Have to be -- AJAX, which was sort of his views (against) about the AJAX hype. Google certainly seems to have upped the hype on this very OLD technology by incorporating it in almost all of its products. As the term Google is growing in the market, so is the term AJAX. Every web developer wants to use XMLHTTP web requests in order to seamlessly integrate page post backs and add his/her own touch of Googleism to his/her website (even I have tried that and my current application is completely done using XMLHTTP web requests)

Setting up test environment.....What is involved?

Scenario:

We have completed the development phase and need to deploy the app to
the test environment. Needed to know what all things are involved in
setting up the test environment.
the application consists of Serviced Components and ASP.NET 2.0
pages/code and SQL 2005 database.

I think i would need the following:

Need to install the Serviced components on the test server
Copy over the ASP.NET pages and the precompiled Code behind.
However I should use the existing database server setup in the test
environment. I think it is a bad idea to backup the DEV database and
restore it to the TEST database, since it would already contain the
data that is supposed to get populated after you run the application
and play around with it right???

Solution:

An insight into deploying a .NET web application:

I think using something like NAnt and CruiseControl would be a much
better option. You can also create a deployment project for your web
app using VS.NET

If you prefer to use the manual way, you just need to simulate your
development enviroment on the test machine-folders and stuff.

Copy over your web app dll to the bin folder and make sure you copy all
the aspx pages. You dont need the code behind.

Regarding the database, create scripts for all your tables, sps,
triggers etc and run the script on the test/staging machine. This
should also populate the tables which are necessary to 'start' the
application such as user roles etc. Other than this, the transactional
data should not be populated using these scripts. The data should be
populated next.

I would suggest not to use your development data on the staging
machine. Create scripts to insert values into the newly created tables
and then populate the data. Make sure someone who knows the
functionality of the application and has an overview of the database
design, but doesnt know the code does this, as then the testing will
bring out some bugs which developers tend to hide using 'manipulated
data'.