Saturday, September 17, 2005

Keep your models in sync!

During my last 3 years working for Zühlke as a consultant and software architect I've learnt to appreciate modelling in different projects. To be honest: There are several situations in which you’d like to express your thoughts in a way your tool doesn’t support. But if you are really lucky and have (one of the few) usable modelling tools, your whole team will gain architectural overviews, that are hard (or maybe impossible) to provide without graphical representations and abstractions of your work.Models are perfect for sketching and documentation, this is a well known fact - but they can do more for you. Typically models provide structural and behavioural views on your project as a whole. Rational defines several views in its Rational Unified Process (logical, process, component, deployment views) – you might need others for your specific project needs. One of the most important issues only few people think and talk about is model integration. Models tend to grow, especially if they’re used efficiently, and every team member uses parts of the model for his/her daily work. Sooner or later you need to split your model in several parts. Or you distinguish analysis and design models. First you create some high level analysis classes or components and add some typical sequences and interactions to get a better understanding of your target domain.
Later you drill down some technical issues in your design model. You literally “dive into” parts of your analysis model. You see errors and change your design because of technical restrictions, optimizations, or simply to correct some errors you made during high level analysis, because you’re recognizing new details about the problem at hand.
This is one of the most critical moments in iterative software design: Most teams forget to update their good old analysis model they used throughout the initial project iterations. Your architectural overview in the analysis model will become unclear - and as time passes by – simply false.
You need to attack this problem during the early days of your project. Don’t divide your team into those using the analysis model and others using the design model and code. Don’t create roles for architects, who never see the design model or code. These guys are known as “PowerPoint architects” – living in their own world. Be aware of them. You certainly need team members who are responsible for the overall architectural issues – usually both technical and business focussed architects. But keep them in touch with your daily development issues. You need them to regularly extract important design information back into their analysis model. The modern idiom for this extraction is called “harvesting” (see IBM/Rational Software Modeller).
Most modelling tools aren’t capable to automate this important harvesting step. And it is no simple task. How should a tool decide which design aspects are architecturally relevant and which are not. Sure – you can use stereotypes or something else to annotate certain classes’ relevance. But it is more difficult for behavioural aspects of your design. Imagine your high level analysis model showed some business-critical component and service interactions. What should happen, if you change certain design aspects of this interaction down in your design model? Could any tool tell with some certainty, if your overview is concerned by those changes? Can we define these rules? Do we have patterns for these decisions? I think we need much more experience in model integration, updating and cross model referencing before we will be able to automate those tasks…

Pragmatic Programming - the way towards your own DSL

I for myself am a passionate coder and usually prefer lightweight tools. It’s always fun to read books from the pragmatic bookshelf (see www.pragmaticprogrammer.com). Dave Thomas and Andy Hunt really hit the point with most of their opinions, which are taken from real life projects. Good programming skills are the most important basis if you want to develop and engineer larger software projects.
You want to automate certain aspects in your design and development process, as it is proposed by the ideas of Software Factories? Well, first you need to know how to accomplish these tasks manually in an elegant way. I think, it’s an important prerequisite, nobody talks about…
Remember these steps:
  1. Learn to program

  2. Learn to design

  3. Learn to model

  4. Learn to automate

  5. Design your automation through DSLs

Saturday, September 03, 2005

Software Factories

I've finally made it - I'm through more than 600 pages of this interesting book by Jack Greenfield and Keith Short. And it was worth while taking the time to understand the motivation behind (Microsoft's) Software Factory initiative.
The main point behind the idiom Software Factories is to use modern software development environments to industrialize software development for product lines. Software Factories use techniques like modelling with Domain Specific Languages, combined with patterns, frameworks, guidance and code generation to automate tedious, repetitive (!) and error prone hand-crafted code. The book describes the theory and ideas behind Software Factories, while Microsoft tries to deliver the proof of concept: The upcoming versions of Visual Studio Team System will contain numerous tools that give you the opportunity to create and visualize your own domain specific languages, synchronize models through transformations and automate and enforce your software development process through the new Guidance Automation Toolkit.
I’ll use my next blog entries to investigate some of the key points that are touched by Software Factories and try to illustrate them with issues from my own practical experience.