Product Line Engineering

SPLC 2008 Notes: Application Engineering – a Dying Discipline?

Posted in Bits'n'Pieces by danilo on September 18, 2008

One goes to SPLC to learn new ways of seeing and doing things. This year’s conference confirmed to me at least that I see some things  different from some other participants.

Who needs Application Engineers?

Some of the presenters called for the end of the tedious application engineering. If you are not too familiar with Software Product Line language: Application Engineering are the activities concerned with defining, building and deploying actual applications based on reusable core assets produced by Domain Engineering. Surely one wants to reduce the effort to create new applications to a minimum. And yes, in a lot of cases well designed core assets and PL architectures can even remove the necessity to develop application specific artifacts. Does this make application engineering obsolete? Not at all I would say. If a product was developed based on customer specifications, who is discussing the resulting application with the customer? Who makes sure that there are tests that are based on customer requirements for this specific application? Who tries to map the customer requirements to a configuration of the core assets in the first place? That are clearly application engineer’s activities. Depending on the domain and the product line implementation, these activities might take only a few hours or even minutes but they normally don’t go away even in perfect product lines if you have customer specified products. And finally, the description of the instance from your product line (configuration file, model, what ever used in the product line approach) is for sure an application engineering artifact.

Urban Myths

Another urban SPLC myth you hear once in a while is that one is able to derive THE product line architecture “automatically” from feature models just by doing the feature model right.

I must admit, I have seen architectures derived from features. So yes, it is possible. Question is one supposed to do this? A feature model shall be an easy to understand representation of variability in the problem space. A product line architecture is a solution space artifact providing means to easily produce products based on this architecture. In my experience, often this requires architecture and feature model structure to be very different. How would one resemble a layered architecture often used in communication protocol stacks such as TCP/IP stacks in a feature model?  The basic IP protocol is the layer on top of which we build TCP and UDP. So TCP and UDP could be “or” features below “IP”. IP in turn uses a physical layer which again provides different physical protocols such as Ethernet or serial lines (PPP) to transmit its data. So were do we put the “or” choice for Ethernet or PPP? On top of the IP Layer? Below?

graph0 graph1

I don’t know exactly, because both models offer similar but not identical choices. In the first case, the physical layer can be selected without an IP layer present, in the second case IP will imply also the physical layer to be present. Both models make sense but at least I would implement both feature models using the same architecture in order to be able to reuse the same core assets in both cases.

Also the implementation techniques (e.g. C vs. C++ vs. Java, use of aspect-oriented concepts, domain specific languages or models, … ) have a strong influence on the decomposition of the architecture into building blocks. For instance in an aspect-oriented approach a cross-cutting concern can be implemented in a single artifact whereas in a simple Java approach it has to be spread out in every implementation class.

And many features simple cannot be decompose in any kind of direct architectural mapping or crosscutting influence, they related to both kinds of solution space elements no matter how you do things.

The longer I think, the more I feel uncomfortable with a quasi direct mapping of problem space variation to solutions space structure…

What else?

Yeah, what else brought SPLC 2008? I am not sure. While it was the best attended SPLC ever, I was disappointed by the lack of new companies coming to SPLC to learn about Software Product Line Development. Sure, there was a strong Swedish group there (some 16 I counted) and some from the UK (about 8). But Germany being very strong in research (24) but only 6 were from industry (tool vendor participants excluded), if we leave out the product line consultants from Siemens and SAP, we are down to 4.  I am happy to hear that next years SPLC will try to attract more industry for instance by running an Industry track. I hope the promising location (San Francisco, USA) will help as well.

The weather was perfect for the conference (intermittent periods of hard rain throughout the week), the conference itself very well organized by the local team. However, I am already looking forward to the next SPLC and hope to see some improvements then.