This is the first post in a series that I announced this weekend. In this post, I will introduce the core architecture I use to create my DSL based web development environment. Although not mentioned in the announcement, this post will have multiple editions - hence the (1) in the title - because no architecture is finished and correct the first time. Every time it's revised, a new post on this subject will appear.
Components of the architecture
The key components of the architecture I have in mind are twofold: a run-time environment and a design time environment. The reason for having both environments explicitly as a part of my architecture is based on my interpretation of the IEEE 1471 definition of architecture:
Architecture: the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.
I strongly value the bold parts, more than many architects I have met over the past 15 years. I interpret these parts as meaning that the relationship between the components that form a system strongly determine the acceptance and usability of the system by it's intended users, and that an architecture needs to take into account the way the system is going to be designed, realized and extended, including the components used to achieve that.
With these components in place, we have everything to support a model driven software development process.
A model driven development process
The model driven software development process is based on domain specific languages, and generating code from models defined in those languages.
The process I have in mind here consists of an interative approach, in which three items have to be maintained: a (set of) domain specific modeling language(s) and models created using those languages, a (set of) code generator(s) to generate code from the models, and a generic framework containing the foundation on top of which we generate code. It's no use generating all the code in the framework, since that is not application specific.
Each iteration in my process consists of the following steps:
- Select content of the iteration, in terms of features to realize
- Model the features using the available domain specific modeling language(s), extending it (them) where necessary.
- Generating the code for the new feature, if necessary by prototyping it first and then extending the code generator(s) and/or the framework.
In the experiment described in this series of blog posts, the process is mainly executed by me, myself and I, but past experiences show that this approach works well in cooperation with others, including the domain experts you need to develop an application. I should add here, that my DSL is based on domain terminology from the web application development domain, for which the web itself provides a great dictionary, and the terminology I use when discussing a new web based venture I am starting with two partners. These partners do not speak "W3C", they only speak 'end-user' and 'money maker'.
My selection of components
For my first attempt at building applications based on this architecture, I selected the following components.
- The XAMPP platform, which contains a web server, database and scripting engine:
- Apache 2.1.x web server
- MySQL 5.1.x database
- PHP 5.3.x scripting engine
- CodeIgniter 1.7.x - a Model-View-Controller framework based on PHP, to get a headstart w.r.t. generic stuff
- MetaEdit+, a graphical DSL creation and modeling environment by MetaCase. This is the only component in my set up that is not Open Source
- Subversion and Trac for version management and issue/progress tracking
That's what we start with...
...and the next post in this series will contain an overview of how these items fit together, and what the first iteration looked like.