Elektronik automotive magazine has published an article describing work done at Daimler Chrysler on managing diversity in the automotive domain.

A basic problem automotive systems developers are facing is the large number of possible vehicle functions and options due for example to differences in target markets, vehicle type and engine capacity.

This variability can only be handled economically through strategic reuse and this requires a formal model for the variability inherent in the product line.

The article describes an approach to this using the pure::variants specialist solution for managing variability and product lines in conjunction with the widely-used Simulink® toolset.

Here’s the blurb:

A characteristic of today’s motor vehicles is a wide range of variants with slightly different functions. Since this variability has to be reflected in the software development models, it is essential that there are concepts for systematically handling the variability of functional models. Differentiating between the central and model specific variability information allows uniform handling in Simulink and creates an explicit representation of distributed model variability.

I couldn’t have said it better myself…

The original version of the article is in German but an English version can be downloaded from the Software Acumen web site here: Handling functional variants in Simulink® models (PDF 898kb opens in new window)

Simulink is a registered trademark of The Mathworks Inc.

The Methods & Tools Summer 2008 edition has just been published and contains a short article by Matthew Fowler of NT/e and yours truly on the topic of using UML and / or DSLs for code generation.

We introduce both approaches and give some basic advice about their respective usefulness. We also make the mistake of predicting the future by claiming that UML tools will gradually lose market share to DSLs. Come back in five years time to see if we have to eat our words…

View the Methods & Tools Summer 2008 Edition (PDF 1.1Mb).

Well, the title says it all. Booking closes for next week’s Code Generation 2008 event on Monday.

Join 120+ developers, architects and others from around the world for three days of intensive learning and discussion on the practical aspects of code generation tools and technologies in Cambridge, UK.

I ran my workshop When Good Architecture Went Bad again at this week’s Software Architect 2008 conference. The session drew just under 40 participants which was very satisfactory from my point of view.

Regular readers will know that the session covers common patterns of architectural decay and gives some tips on how to address such decay.

I’ve previously run the session at SPA 2008, ACCU 2008 and as a straight talk at May’s Embedded Masterclass events. Each time there’s no shortage of participants willing to share their architectural horror stories and yesterday’s session was no exception…

The examples I collected included:

• A software system where the threading architecture decayed so badly over time that the system became unmaintainable and had to be scrapped.
• A couple of examples of business logic (with associated SQL) being captured in the software’s presentation layer – making it hard to replace this layer.
• An example of a software package that became so big it couldn’t be understood by one person and so became really hard to maintain.
• A software system whose architecture had to be seriously bent in order to meet performance targets.
• Software with a large number of cyclic dependencies that ended up as brittle spaghetti code.
• Several examples of drive-by programming – team-membership constantly changing, programmers not understanding architecture and so making mistakes when they code and then moving on.
• One example of drive-by-architecting with similar consequences.
• Problems with obsolete software and hardware technology, lack of skills in these obsolete technologies leading to decay.
• A couple of examples of over-engineered (gold-plated) software modules.
• Sales-driven evolution – where there is no clear roadmap or scope for the software system and so the implemented software architecture inevitably diverges from the intended architecture.
• Lack of architectural direction – no one responsible for laying out an architectural vision, see related point on sales-driven evolution.
• Software that is bloated with technologies – new technologies e.g. web communication technologies being added without obsoleting older technologies.
• A big example where an outsourcer implemented everything in a software system rather than buying in some best-of-breed components. It was a good system but this example of not-invented here led to a huge software base that in the end couldn’t be maintained by the outsourcer or the customer due to lack of resources and skills.
• Merged companies with different cultures and different principles having to collaborate on a software system leading to decay.
• Uncontrolled code use – programmers grabbing code, classes and even variables from other parts of the software without any control on what could and couldn’t be used – once again led to an unmanageable code base.
• New people coming into the team and adding untested technologies to the software in an uncontrolled manner.

You can see reports on the previous deliveries of the workshop here: When Good Architecture Went Bad at ACCU 2008 and here: Architectural Decay at the Embedded Masterclass.