I’m pleased to announce that Steven Kelly (MetaCase) and Markus Völter (Independent) have accepted our invitation to keynote next year’s Code Generation 2009 event in Cambridge, UK.

Both Steven and Markus are recognised experts in the field, regular conference speakers and published authors as well as strong supporters of our previous Code Generation conferences.

More details of their keynote speeches will be available as the event programme shapes up.

Next Sunday I’ll be taking part with 1500 or so people in the annual Oxford to Cambridge cycle ride in aid of the British Heart Foundation.

The ride is over 89 miles (143 kilometres) of the rolling English countryside and I have an approximate target time of 7 hours based on not very much analysis to be honest

If you’d like to sponsor me for this event then you can donate by credit card at my fundraising page or sponsor me on a per mile basis by contacting me through Software Acumen.

Thanks in advance.

Check out the updated article I’ve co-written with Matthew Fowler of NT/e on UML vs. Domain-Specific Languages at embedded.com

Of course since the article was written Microsoft have got excited about modelling so our final prediction may need some revision…

I mentioned previously that I was organising a Code Generation stream for the Embedded Systems Conference in Birmingham on 2nd October. The first thing to note is that the early-bird booking period for the event closes today.

The programme, which will cover a range of topics on model-driven software development approaches, tooling and process issues is now final and looks like this:

9.30	WELCOME Mark Dalgarno (Software Acumen)
9.45	Tutorial: Code Generation – The fundamentals Matthew Fowler (NT/e)
10.45	Tutorial: MDA Allan Kennedy (Kennedy Carter)
11.45	BREAK
12.00	Tutorial: Introduction to the Eclipse Modelling Project Karsten Thoms (Itemis AG)
13.00	LUNCH
13.45	Tutorial: Model it your way – Efficient modelling using Domain Specific Languages Karsten Thoms (Itemis AG)
14.45	Case Study: Testing Code Generators Axel Terfloth (itemis AG)
15.45	Panel: 10 Years from now nobody will write code by hand Moderator Andrew Watson (OMG)
16.45	Drinks Reception

I hope you agree that this is a good selection of speakers and topics that should be of interest to anyone who wants to learn how to get into code generation and what the alternative approaches are.

I’m also looking forward to some interesting discussion during the final panel session, hopefully there will be some sceptics on the panel and in the audience…

More information on booking options can be found here.

Juha-Pekka Tolvanen has sent me the following Call for Articles for a special issue of IEEE Software on DSLs and DSM:

---

Call for Articles: IEEE Software Special Issue on Domain-Specific Languages & Modeling
Submission Deadline: 1 Dec 2008

IEEE Software seeks submissions for a special issue on Domain-Specific Languages and Modeling (DSL&M). This issue will focus on benefits that the field’s practitioners and designers observed or quantified, especially scenarios that could not be implemented easily using general-purpose techniques. The issue will explore how mature domain-specific techniques address issues of efficiency, integration, maintainability, and reliability. In addition, articles can address specific challenges associated with DSL&M. Suggested areas of interest include:

• software development process with DSLs;
• state of the art descriptions of DSLs and tools;
• industrial experiences of applying DSLs in practice, including lifecycle issues;
• design of DSLs as language engineering (guidelines, patterns, and frameworks);
• interoperability with mainstream languages, IDEs, and other tools;
• metrics for productivity using DSL and DSM techniques;
• testing, system confidence, test case generation, validation and verification;
• generative techniques, code reuse, code generation;
• semantics for integrating heterogeneous systems, or heterogeneous tools;
• selection/design of DSLs and tools to best suit project requirements; and
• impact of DSLs on software architecture.

Submissions can address many different vertical domains, including:

• automotive, avionics, embedded and other cyber-physical systems software;
• mobile systems, including mobile phones and sensor networks;
• telecom, communications, and software-defined radio systems;
• medical systems, devices and health records systems;
• consumer electronics;
• enterprise systems;
• software and systems integration; and
• hardware/software systems design and co-design.

Outstanding papers will provide empirical evidence, such as usage statistics, metrics for productivity that can be compared to general-purpose languages, code-generation statistics, or other evidence that future practitioners may find useful in evaluating a DSL/DSM approach during project planning. Articles that
are overly complex, center on pure research results, or are theoretical in nature, are not appropriate for this issue.

Submitted papers should have a decidedly practical orientation, and be written in a style appropriate for practitioners. Papers should cover either:

1. a case study example that is a system or software body already in production, or
2. a large system or software body scheduled for delivery.

Authors of papers that do not satisfy either of the two criteria above should contact the Guest Editors prior to submission.

Manuscripts must not exceed 5,400 word including figures and tables, which count for 200 words each. Submissions in excess of these limits may be rejected without review. Articles deemed appropriate will be peer-reviewed and are subject to further editing for magazine style, clarity, organization and space. We reserve the right to edit the title of all submissions. Be sure to include the name of the area(s) of interest to which your manuscript most closely responds. To submit a manuscript, visit:
https://mc.manuscriptcentral.com/cs-ieee.

Please visit http://www.ece.arizona.edu/~sprinkle/dsl/ for direct links to the submission site, author tips, and materials useful for formatting submissions. Note that the scheduled Issue Publication Date is Jul/Aug 2009.

You may contact the Guest Editors at dsl@istlab.dsst.aueb.gr

—–

On behalf of the Guest Editors,

Jonathan Sprinkle
Marjan Mernik
Juha-Pekka Tolvanen
Diomidis Spinellis

Further to my previous post on Agile Product Line Engineering I should mention that I’m taking part in a research project that is investigating the integration of agile and product line approaches, specifically in requirements engineering.

As you may be aware, an emerging problem in the product line engineering community is how to effectively integrate agile development principles with product line engineering techniques, which have tended to be more plan-oriented.

Our research group is investigating this problem. More specifically, we are focusing on the definition of a collection of re-usable process patterns to support the requirements engineering (RE) activities for single and product line development. The process patterns are going to be tailored versions of the (standard) Unified Process, defined by the OMG. RE activities include elicitation, negotiation, specification, analysis, and management. The process patterns will support different degrees of agility for projects.

Recognizing there is a substantial body of knowledge in the community (both researchers and practitioners), our group is working to collect and embody the expertise in a system. The system will be freely available for use.

We would sincerely appreciate your contribution to this collection of knowledge by filling in our questionnaire.

Your contribution (individual or organization) can be either anonymous or publicly recognized, as you choose. This is an option when you fill in the questionnaire.

The questionnaire is at: http://129.110.92.41/REProcess.aspx and takes around 10 minutes to complete.

Thank you very much!

Kunwu Feng, University of Texas at Dallas
Kendra Cooper, University of Texas at Dallas
Mark Dalgarno, Software Acumen
Frank Maurer, University of Calgary

The second day of the annual Software Product Lines Conference saw me attending a session on Agile Product Line Engineering. The session, advertised as a panel, was led by industry veteran John MacGregor.

In an innovation for SPLC the audience were divided into small discussion groups and tasked with answering three questions:

1. What are the advantages, if any, of using agile techniques in a PL organisation?
2. Where in the operation of an SPL is the agile approach possible/appropriate/advantageous?
3. Are changes to the ‘usual’ product line approach necessary to take advantage of agile techniques? If so, what
   • Research issues should be investigated?
   • Practices should be adopted?

John volunteered me and a few other SPLC regulars to lead the discussion in our respective groups so I rounded up 8 willing participants and we kicked off by introducing ourselves and describing our product line and agile experiences.

In a nice twist of fate we had a couple of researchers who are already looking at combining agile and software product line methods, one representative from a company trying to implement Scrum in a product line setting and a mix of sceptics and optimists when it comes to combining the best of the two approaches.

John will write up the session outputs at a later date but here are a few notes our group made:

• Some people have perceived a conflict between agile methods (e.g. Scrum) and Software Product Lines but the group’s experience was that there wasn’t necessarily a conflict.
• The communities around either approach are probably not known to each other. If they are aware of each other then their perceptions of each other are probably not accurate (e.g. thinking of agile as ‘hacking’ as opposed to a highly-disciplined but lightweight approach)
• Do SPLs need more documentation than agile can support? Some specialised product lines in regulated industries may do.
• Would an agilist resist core asset development (development of a highly-reusable software asset base)? Do such developments violate the principles of avoiding Big Design Up-Front or You Ain’t Gonna Need It? Maybe there’s a role for Agile development after the core asset base has been developed.
• On the plus side, agile’s focus on Test-Driven approaches would sit well in an SPL.
• Agile’s focus on the customer and a strong emphasis on prioritising requirements would also fit well with an SPL. The question would be how to collate and prioritise requirements from a massive customer base across multiple locations.
• Is there a problem with hardware co-development. (Although one participant’s organisation had hardware development done in an agile way through rapid prototyping).
• Size of project may be an issue? Can agile be scaled to an SPL effort? Lots of people in the agile community looking at scaling up agile. Anyone looking at scaling down SPL?

In response to the set questions our thoughts were:

1. What are the advantages, if any, of using agile techniques in a PL organisation?
   • Lightweight methods (SMEs) can adopt SPL more quickly?
   • Strong focus on testing (TDD, CI)
   • Strong focus on prioritising requirements.
   • Refactoring
   • More customer involvement?
     • Distinction between a customer for the product and a customer for the product line.
     • Deliver early and deliver often is typical in SPL already.
2. Where in the operation of an SPL is the agile approach possible/appropriate/advantageous?
   • Define an architecture/ platform first and then become agile when developing products? Can a PL architecture just emerge? But you need stability of architecture in a PL.
3. Are changes to the ‘usual’ product line approach necessary to take advantage of agile techniques? If so, what?
   • Research issues?
   • Practices?
     • Have a strong separation of concerns to enable smaller agile teams? Must still have a hierarchy e.g. Scrum of Scrums.
     • Have agility but keep stable component owners? (As in the InnerSource model discussed in the keynote)
     • If you know you’re going to need something then do develop it for reuse otherwise just do opportunistic reuse as in agile.

So, there you have it. Look out for more on combining Agile Methods with Software Product Lines in the future…

This  week’s Software Product Line conference was used as the launchpad for pure::variants v3.0 – the most comprehensive software product line solution on the market.

With 100+ new features this is certainly a bumper product release. But for me the key change is support for Hierarchical Variant Composition – giving the ability to compose complex product line hierarchies from preconfigured variants. This makes it much easier to produce multiple product variants as a group rather than independently.

At the same time as announcing the new release pure-systems, the developers, also announced a technology agreement with MKS, providing integration with MKS Source, MKS Integrity and MKS Requirements. This is in addition to newly announced integrations with Rhapsody, Artisan Studio and Enterprise Architect.

pure::variants is available for free download for academic or research use in a limited Community Edition. A Standard Edition time-limited evaluation is also available.

Contact Software Acumen for more information.

I’m at the annual Software Product Lines Conference this week in Limerick, Ireland.

Today has been my busiest day – a panel to chair and a demo session to give.

First up was the panel on Product Line Scoping in Practice. I was lucky to have a great selection of panellists with wide experience of product line scoping. Danilo Beuche of pure-systems has been around the product line scene for a while, as a researcher, as a product line builder and latterly as a vendor and consultant. Isabel John of Fraunhofer IESE  has a very strong research background in Product Lines and Scoping and also a lot of practical consultancy work. Klaus Schmidt in his own words is a veteran of the product line scene with a very strong research and industry background initially at Fraunhofer IESE and latterly at the University of Hildesheim. Finally, Christa Swanniger gets involved in many product line activities at Siemens AG in her role in the central technology group.

Adding weight in the audience were people like the SEI’s Paul Clements, Sholom Cohen and Gary Chastek. Dave Weiss of Avaya Labs was also present and contributed some good insights from his lengthy experience. Perhaps depressingly there were no product managers in the audience – the key role for product line scoping.

We didn’t get through half the material we were hoping to get through – with Isabel in particular just ‘warming up’ – mainly due to the great number of questions and comments from the audience many of whom were working in existing product lines. Interestingly, many of these people claimed to be running product lines without doing any form of scoping. A handful did do scoping. Later it emerged that some of the people who didn’t do scoping actually did do it but either didn’t call it that or were not closely involved with the group doing scoping.

I’ve (hopefully) recorded the panel so will publish the recording later once I’ve got through my editing backlog.

My demo session Jump-Starting Software Product Lines with Clone Detection was based around using clone detection to help mine assets from existing software in order to act as a basis for a product line platform and to monitor the product line e.g. to ensure that application developers are not simply copying code from the platform into their applications and then modifying it or to look for new reuse opportunities in the code base where multiple applications include  the same code.

Of course the rationale for the demo was to showcase the features of the Axivion Bauhaus Suite in this area. As well as a tool demo I also described two case studies where Bauhaus had been applied to real product lines. In the first study around 160 functions in application code were identified as code clones – representing a good basis for an extended product line platform. In the second study Bauhaus was used to help monitor the product line and showed that although there was some opportunity for reuse that was being missed by the organisation they were in fact operating the product line very effectively.

I didn’t feel I ran the demo that well – maybe I relaxed a bit after the panel session had gone so well – but afterwards a few people did come up and say it was a nice demo and certainly there were very few Bauhaus flyers left afterwards so perhaps it went better than I thought. Anyway, I hope to record the demo for later videocast soon so keep an eye out for this if you’re interested.

Lots of familiar faces here so it looks like the rest of conference will be fun…