Some thoughts on software architecture

Beside requirements engineering software architecture is the second important foundation of a software system. The architecture heavily relies on the requirements and has to define an abstract view with a clear separation of concerns. It outlines the distribution of tasks to components and declares the interfaces betwen them. The design of the communication flow between those components bases on the use cases, so that there's a direct link from the requirements to the architecture artefacts.

Very often, especially in small starting projects, the software architecture is disregarded. The usage of JEE or .NET as a technological platform is viewed as enough. But it isn't. It's just a rough layout, a blueprint, which mostly defines the vertical layers of an application system. But that's not enough for the functional separation. And also very often systems aren't realizable independently and from the ground up. They have to fit into existing environments, managing interfaces to existing systems. Starting here without taking the time to look ahead will lead to quick results, but also to badly increasing problems when the complexity grows or the system has to be evolved and maintained over the years.

So there's allways a strong need for a software architecture. Clear goals have to be defined and priorized as well as also a clear proceeding is needed. A matrix helps to sort all requirements into functional (vertical) and technological (horizontal) aspects. The result are clear layers (persistency, model, business logic, orchestration, and user interface) and business domains (e.g. financial accounting, supply chain management, customer relationship management, controlling, or human resources). The matrix gives a first impression of possible components and libraries. Now it's possible to define groupings, dependencies, interfaces, and the communication between the components.

It depends on the project how deep this has to be broken down. But what is also needed are the major patterns for the realization. Those are SOA and EAI patterns, software architecture patterns, and the most important ones for the medium and small components. This helps to get a common language, a common understanding of the whole system. Well documented in a small handout (max. 50 to 100 pages) with easy to understand deployment, component, and class diagrams - maybe some activity or sequence diagrams for dynamic aspects - will help all team members right from the start.

Featured book: The Myths of Innovation

There are many thoughts and ideas about innovation. And there are also many myths. Now Scott Berkun has wrote his second book called The Myths of Innovation and bringing some light into the world of invention, development, and discovery. After reading this book many facts taken for granted are now viewed from a different angle. And the own mindset about innovation changes. So it's really worth reading.

Why don't deliver on December, 28th?

It's allways the same, bad project management done with MS Project or similar products. Even if it is complex and painful it is possible to plan resources, their availability, and holidays, and to do a resource planing for each task. OK, your staff may change while working on a longer task, but you can document this through subtasks. And there are also switches to tell Project to let you solve resource conflicts by hand because of the nightmare of automatic reorganization. Relations, dependencies, dates, all have to be set very carefully. But when it's done allright your project management tool can help you to visualize and manage importand aspects of your undertaking.

But most time no resources are planned, no holidays are entered, the vacations are ignored. Only tasks with a rough duration estimation and some of the most importand dependencies. And where does it end? In nicely documented and communicated delivery dates like December, 28th. *sigh*

Is it really so hard?

Migration goes on

After the import of the sources into Squeak and first rough changes I'm proceeding with the unit tests and needed adjustments. Most ones are simple, but I changed the configuration class to work more simple. The old way has been hard to debug due to the heavy usage of dynamic method calls out of doesNotUnderstand:. However it is now less flexible, but still powerful enough.

The second big change concers the runtime environment. Until now it has been automaticly bound to the process where a lookup is called and where no environment exists and no parent process has a bound environment. But this has been a bit precarious in multi environment systems. So now every runtime environment has an id which has to be used for the lookup. Both has been applied to the Common Smalltalk Library (CSL), the unit tests have also been changed where needed and now all tests succeed. *smile*

The second library is now the Lightweight Application Server (LAS) which relies on the environment. So I've started to change the lookup mechanism like mentioned above. Here the first tests are green, but also some are failing. Those problems should be easy to fix.

The Smalltalk Object Store (SOS) has not yet been tested. There are two parts that may be a bit tricky. We'll see.

Another effect of playing with Scheme

Since I've tested PLT Scheme and started to re-develop the Tideland Dynamic Content Processor with it - the document node tree, navigation on it, and parsing SML text documents are allready working - I've done almost nothing in Smalltalk. So now I've thought a bit about the reason and I think I've got the answer.

I've started programming in Smalltalk with Squeak which is a full featured and innovative environment with a strange look'n'feel *scnr* and a motley community. After a while I switched to VisualWorks which is more professional and straight. I would really like to realize a professional project with VW. But it is also huge (not compared to Eclipse or Visual Studio *smile*), in some parts complex (e.g. Store vs Monticello), and - what counts most - not open source. Don't understand me wrong, I've got nothing against commercial software. I've bought lots of software for my Mac. But when developing my private software I use open source. So I want to give my applications and libraries back to the community. And I want to use them commercially and allow all others to do the same. Beside that I like that all together in a small and handy tool - like Squeak and PLT Scheme.

So I've allready started the porting of my sources back to Squeak. The export from VW is done, the Squeak development environment is set up, and first file-in tests leading to changes directly in the Smalltalk source file have been done. The only thing I've still got to change externally are the line endings. After that the file-in should work without problems and I can start to find needed code changes via the unit tests which cover most of my code. I hope I soon can provide the betas of the Common Smalltalk Library, the Smalltalk Object Store, and the Lightweight Application Server (take a look at the features). Additionally I can re-integrate the RDBMS strategies allowing the SOS to store objects in SQLite and PostgreSQL. Only the handling of large objects has changed and has to be adapted. The future development of the Net Business Framework - which is intended to have a REST interface - depends on some evaluations I'll do after the porting.

New MacBook arrived

The last days I've had a lot on my plate. The school year is ending and we had to write the regulations for the election of the parent representatives in the steering committee. This is a new construct all schools in Lower Saxony establish with the next school year. I've also had several customer visitings, a training for my role as a team manager, and a refinancing of our house. Oh, and by the way, I've had my birthday last week. Now my age reached the answer for all questions of the universe. *smile* But now this stress reduces and we slowly move into our summer holidays (OK, the childs do, I've got to wait until august).

Last saturday my new MacBook arrived. I've got the 2.16 MHz with 2 GB RAM and the 120 GB HDD. After now about 32 month my PowerBook will be sold. It has done a good job but now it's time for the new one. And it's a great piece of hardware again. I compare it to the HP NC4400 I'm using in my job. The HP is slower, it has fewer memory and a smaller HDD, and - what really disappoints me - is very bad manufactured. Advantages where the docking station, the external button to switch of WLAN and Bluetooth before the OS is started, and the weight. It can also be upgraded to a larger RAM size than the MacBook.

Additional advantages of the MacBook are the very good manufacturing, the bright screen, the track pad, the included DVD writer, the camera and the microphone (I've allready used it for a video chat, really nice), the MagSafe power connector, FireWire, and Front Row with the remote control. But most of all it's the software I allready know from my PB. OS X and the Mac apps I use are easier to handle without loosing power or flexibility. So I can just repeat the reason expressed of many Apple fans: "It works.".

The next steps will be the testing of VMware Fusion with images we're using at work and with the simulated Linux environment I've installed on my server at my hoster. So I can better test changes before they go live.