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…
