"The Concise Handbook of Real-Time Systems"

Very long ago (1999?) I attended a conference where I got a small booklet called "The Concise Handbook of Real-Time Systems" by TimeSys Corporation.
I found the booklet to be a very usefull distillation of the most important concepts when designing real-time software. I even ordered some more copies for interested collegues. I hope more developers will be familliar with the content, it would prevent a number of problems...

I don't think the booklet can be ordered any more from the original company, but a quick googling found a later version in PDF here.

Lack of process view of automotive software

When discussing an architectural problem with my colleagues we identified that an initialisation/activation mechanism could be defined either as a method used between logical components or as an initialisation between run-time processes. But we could not propose the second mechanism since it would be impossible to communicate to the developers.

The reason for this is that we are not using a process view at Volvo (or at any other OEM that I have worked with either). With process view I mean the view as defined in the 4+1 paper by P. Kruchten. And I have not seen any other viewpoint used here that would fulfil a similar purpose.
This has some interesting implications:

• The deployment of functionality is in Kruchten's paper done by assigning logical components to processes and the deploying the processes onto the physical view. Among OEMs the deployment relationship is directly between static logical components and the hardware (i.e. ECUs). So there is no possibility to express concepts as "concurrency", "precedes" or "is activated by".
• It must be the responsibility of the ECU suppliers to define the process view of their ECU. And to be honest I have no idea if they do since this is not requested nor followed up by OEMs...
• The fundamental building block in AUTOSAR is the software component (SW-C), which can be called a static logical component if one is not too much of perfectionist with meta-models. The SW-C contains runnable entities which is the entity that is scheduled. But also in AUTOSAR it is the SW-C and not the runnable entities that are deployed to ECUs. I think this is driven by the first item above...
• Since it is the static SW-C that has the explicit relationship to other ECUs through the defined port and interface mechanisms in AUTOSAR there is no possibility to define a "dynamic" mechanism to "activate", "run simultaneously" or something similar usually defined in a process view (or process architecture).

I was thinking of writing a short paper elaborating on this and relating it to some research papers, but I probably will not. First it is not directly in line with the subject of my thesis. Second there are more pressing things to do. So if anybody else wants to pursue this I would be glad to be a co-author, discussion partner ot at least get mentioned in the acknowledgements.

The significant benefit of software architecture?

I have been convinced that it is impossible to design a perfect architecture. This is supported by a quote by P Kruchten which I have already mentioned in my blog:

The life of a software architect is a long (and sometimes painful) succession of suboptimal decisions made partly in the dark.

One corollary conclusion I make from this is:

The significant benefit of a software architecture is that it exists, not that it optimally fulfills the prerequisistes.

If the purpose of an architecture is to guide and control subsequent developement the fact that it actually provides some guidance is more important than the guidance have exactly the right bearing. I have a gut feeling that this is intimately related to if the system has any conceptual integrity or not.

Could I write some kind of position paper on this? What arguments could I use? Is such a paper already published?

Project presentation

I gave a presentation of my project at the annual Volvo Industrial PhD conference:

I did get the question how my project would have looked like if I would have had a quantitative approach instead. I wished I had the Dilbert strip about numbers as a backup-slide.
Now I had to resort to a serious answer that for some research a qualitative approach will get you a better understanding than a quantitative...

More Conferences...

Some readers responded to the previous blog post about conferences. I got information about two more conferences which could be interesting:

SEI Architecture Technology User Network (SATURN) Conference
17-21 May, 2010, Minneapolis, MN, USA
Submit a proposal by November 9, 2009.

17th IEEE International Conference and Workshops on Engineering of Computer-Based Systems
22-26 March, 2010, St. Anne’s College, University of Oxford, UK
Submission of titles and abstracts 1 November, 2009
Co-located with 15th IEEE International Conference on Engineering of Complex Computer Systems and 7th IEEE International Conference and Workshops on Engineering of Autonomic and Autonomous Systems

Architecture Smell

There is an "established" term called Code Smell, which is an indicatin/symptom that the code should be re-factored (or at least be considered for re-factoring).
I am curious if there are similar Architecture Smells that are symptoms that the architecture is deteriorating. Could these be indicators to see if the system should be re-engineered to the original architecture or even if the architecture should be updated or maybe replaced.

At the WICSA conference I heard Olaf Zimmerman state that one architecture smell for a large system would be if it did not have some kind of layered structure.

For a layered architecture I would say one smell is if there are an increasing number of design dependencies between components in each layer that does not follow the layered principle (i.e. there is a strict dependency from upper to lower layer).

As a comparison one can look at the following lists of Code Smells:
Wikipedia: Code Smell
A Taxonomy for "Bad Code Smells"
Coding Horror: Code Smells

Software Architecture conferences 2010

International Conference on Software Engineering (ICSE) 2010, 2-8 May in Cape Town. Paper submission was 6 September 2009.
Previous conferences had for example workshops on Automotive Software Engineering, Sharing and Reusing Architectural Knowledge and Leadership and Management in Software Architecture .
Workshop program is not yet published but preliminary deadline for workshop submissions are January 2010.

International Conference Series on the Quality of Software Architectures (QoSA), June 23-25, 2010, Prague, Czech Republic
Paper submission in February, I guess...

European Conference on Software Architecture (ECSA), IT-University Copenhagen, 23-26 August 2010
Submission deadline March 15, 2010

Anybody knows of other conferences on software architecture or on automotive software engineering?

Agile and Architecture

I have read and heard several "observations" on how to incorporate a guiding architecture in the current trend of having agile S/W development. There seem to be a lot of smoke but not so much substance, but I will try to summarise a few points which I have concluded through the smoke.

Caveat: My background is in automotive software, and there seems to be no business domain which is less agile than automotive...

Architecture is up-front design, so if no upfront design is important in you agile practice, then I claim the architecture will rather be manifested by your code than the result of making concious decisions between architectural alternatives. The question is if you could have a light architecture so that you avoid a big upfront design (BUD) and allow the architecture to evolve in parallel with the software while it still guides and controls the software development.

Most agile practices focus on delivering the functional behaviour (use cases, user stories, or whatever), which drives the software. Contrary to this architecture focuses on satisfying the non-functional properties as well, i.e. quality attributes which usually are system-wide. I think deciding between these two focuses is really a business decision on how you want the team to work. If the former is more important then you don't have the same need of someone preforming the role of an architect. If the latter is important it will be difficult to succeed if you don't empower them.
I have heard studies of agile practitioners that claim that non-functional properties are solved in re-factoring (for example one study by M.A. Babar at the experience track at the WICSA 2009 conference). I claim that some properties cannot be solved by re-factoring, for example in the development of safety-critical systems. But agile practices should perhaps never be used for development of those?

There seem to be a trend to use agile synonymous with no or little documentation. I don't mind having small architecture descriptions (AD). A possible problem: If the rationale is omitted to make the AD smaller, I think the value of the AD will be significantly less.

If I read the Agile Manifesto there is nothing that says you should de-emphasise a guiding architecture...

Some texts, blogs and presentations can be found with a little googling:
Software Architecture and Agile Software Development —An Oxymoron? by P Kruchten
Agile Architecture: Strategies for Scaling Agile Development by Scott W Ambler
Software Architecture-Centric Methods and Agile Development by Nord and Tomayko
The Formal Goodness of Agile Software Architecture, part 1 and part 2 by Dave Langer
Architecture Meets Agility by Hakan Erdogmus in IEEE Software

There is also a forthcoming book with the title "Lean Software Architecture" by Coplien and Bjørnvig, forthcoming in May 2010. They have some interesting links and excerpts on their website.