WicsaWikiWANParty:Technical
From WICSA Conference Wiki
Keynote 1
In his keynote, Manfred Broy mentioned the issue of feature interactions between services, giving examples from the automotive domain (not being able to close an open widow if the car is locked) and mobile phone domain (alarm clock sounding an alarm and a call coming in at a same time - will the call get through). When doing practical work in the latter domain, we have realized that these kind of interfering behaviors can often be modeled and managed in terms of a shared resource. That is, the phone application and the alarm clock share the same input and output channels (audio, screen, keypad) which causes the interference. Then, it is a matter of defining priorities for the different users of the resource to solve the conflicts.
But these kind of interactions often stem from a certain implementation technology. For example, on some phone models we cannot have applications A and B running simultaneously because of the low performance CPU used in the phone. On the other hand, the same applications run happily together on a high end phone with more processing power. So, I am not sure if these type of interaction specifications should be part of service (feature) specifications because they are implementation dependent. For example, we could build a phone with a separate physical alarm clock module with its own UI and control buttons. And in my car, if I remove the ignition key, I cannot operate the windows because there is no power, not because the car is locked.
But may be there are other kinds of interactions that could and should be specified as part of service specifications? Antti-Pekka Tuovinen
In our experience it is a good idea to clearly distinguish between specifications coming from requirements (desired behavior) and specifications coming from technical constraints (necessary behavior). This especially holds for product families because the technical constraints may differ among the family members. Pierre America
Some commments on 'Real World Influences on Software Architecture - Interviews with Industrial System Experts'
This work reflects quite well our experiences at Nokia. However, in the case of mobile phone products, the HW still tends to come first. One reason behind this is that these affordable consumer products are produced in vast quantities and that the manufacturing costs need to be minimized (in large production numbers the cost of HW dominates the manufacturing cost). On the other hand, as many features are increasingly implemented by SW, the SW is coming more and more important.
Another difference is that process issues are important in our case, where for Symbian OS based phones, we have three different product platforms that each supply SW for different families of mobile phone products. The development work is highly distributed (and parallelized) and under heavy time-to-market pressure denmanding a high degree of reuse. Without commonly agreed ways of working, SW development would be quite impossible.
