Assessing systems adaptability to a product family

Journal of Systems Architecture 50 (2004) 383–392 www.elsevier.com/locate/sysarc

Assessing systems adaptability to a product family Mika Korhonen *, Tommi Mikkonen Institute of Software Systems, Tampere University of Technology, P.O. Box 553, FIN-33101 Tampere, Finland Available online 27 November 2003

Abstract In many cases, product families are established on top of a successful pilot product. While this approach provides an option to measure many concrete attributes like performance and memory footprint, adequateness and adaptability of the architecture of the pilot cannot be fully verified. Yet, these properties are crucial business enablers for the whole product family. In this paper, we discuss an architectural assessment of one such seminal system, intended for monitoring electronic subsystems of a mobile machine, which is to be extended to support a wide range of different types of products. This paper shows how well the assessment reveals possible problems and existing flexibilities in assessed system, and this way helps different stakeholders in their further decisions. Ó 2003 Elsevier B.V. All rights reserved. Keywords: Software product lines; Product line architecture; Adaptability; Assessment

1. Introduction A pragmatic way to develop product families is to base them on a well-established seminal system. The possibility to use the seminal system as a basis for estimating many non-functional properties, like performance and memory footprint, for instance, is a definite advantage of such an approach. Another definite advantage is the available real-life experience on the required verification and validation effort. With precise input, the plan of the transition to product line architecting can also be more accurate. * Corresponding author. Tel.: +358-3-3115-5505; fax: +3583-3115-2913. E-mail addresses: mika.korhonen@tut.fi (M. Korhonen), tommi.mikkonen@tut.fi (T. Mikkonen).

What remains open with this approach, however, is the adaptability of the architecture of the seminal system to become a product line architecture (PLA) [4] for a range of related products. While concrete measurements obtained with the real system can be used to study the scalability of the system, issues related to variability needed for different products requires a different approach. Then, the focus is placed on intended modifications, and their relative cost and effort. The goal of this paper, a revised version of [8], is to introduce a real-life case where we were faced with the challenge of transforming single product architecture to product line architecture. As a tool for estimating the adaptability of the architecture, we assessed the architecture with respect to several quality properties that reflect adaptability needed in product line phase.

1383-7621/$ - see front matter Ó 2003 Elsevier B.V. All rights reserved. doi:10.1016/j.sysarc.2003.08.011

384

M. Korhonen, T. Mikkonen / Journal of Systems Architecture 50 (2004) 383–392

The rest of this paper presents the discussion structured as follows. Section 2 describes the PLA principles in shortly. Section 3 describes the product architecture as it had already been implemented. Section 4 introduces the procedure we used for assessing the adaptability of the system. Section 5 discusses the input created for the assessment, and the evaluation of the input data in the assessment. Then, Section 6 provides the conclusions we made as the result of the assessment. Finally, Section 7 concludes the paper with some final remarks.

2. PLA principles Paul Clements wrote in [1] that ‘‘A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way’’. So, the product line should help the work on some specific product domain, where is developed multiple similar applications. When the product line is available, it helps the application developing work in various ways, and in multiple hierarchical levels; product line provides the common requirements and implementations, and also the tools, and methods for the product developing work. 2.1. Introduction to PLA The PLA of the product line handles the variations of the applications of some problem domain in multiple abstraction levels, and also guides the developers in the product specialization work. The PLA can handle the variations of different products with e.g. code parameterization, dynamic binding, component connection interface, and so on. Inevitably, the PLA increases the common understanding between developers because of this shared framework knowledge, and this way helps the developersÕ movements between different application projects inside the product line. The commonality handling in PLA helps also testing and releasing of the single application.

Common modules are already been tested when the latest application is developed, and there are well-established methods for testing applications in this product family. Based on the above, the PLA is one of the product line assets that help on the product developing process when the new product is developed into the product family. The architecture of the product line plays an important role; the architecture defines many of the non-functional quality goals for the system, which are e.g. performance, reliability, modifiability, configurability and so on. It is not easy to define an architecture that fulfills these various non-functional requirements, and also the variations of the product line. 2.2. Initiating a PLA PLA can be produced in three different ways; it can be developed direct from the scratch, it can be based on the existing product group, or it can be build based on a single existing product. In the following, we will discuss each of these ways separately. Building the PLA directly, based on the requirements of the forthcoming product family is perhaps the most challenging and ambitious way. All the requirements of the product family have to be collected and requirements have to be classified. Also, the domain model of the product family has to be constructed, all the variations and commonalities needs to be documented, and variation points, and implementation methods of the variation points have to be designed. All this work should be done in quite short time, when it is not possible to collect enough domain information, if the domain is not well known for the product line developers. It is great benefit if there is an existing group of products, for the incoming product family. In this kind of case the common requirements and core abstractions of the product family are more focused than in the first case. In this case the variation points are easier to locate and the implementation of the PLA is more straightforward, because of the knowledge from the core abstractions of the product line.

M. Korhonen, T. Mikkonen / Journal of Systems Architecture 50 (2004) 383–392

The development approach where the best parts of the above approaches are aimed at is developing the product family based on a single pilot product. In this solution there are the same benefits as when we move from a group of applications to a product family, but here we do not have as much previously discovered material. This solution can be seen as the middle road between the other two methods; there is some existing material available, the product domain is quite clear to all developers, and some of the most obvious problems have already been encountered. Also the developed architecture has been tested based on the non-functional requirements of the product family, at least from the perspective of the pilot product. However, the PLA is still in its youth, and the amount of architectural legacy should be minimal. In this paper we analyze the adaptability of this single application architecture to see how easy it would be to move to PLA.

3. Pilot product In our case, the pilot product was built on demonstration purposes, and it was thought that it would be used only in some technology and concept tests. Like in a normal software project the product swell up little by little, until the whole project was too late to start from the scratch again. Of course, we could have been build the product line right form the start, but the idea from the product line did not come to us early enough to do so. So, we made some concept tests with the first application and revised the architecture so that it better fulfilled the new product line requirements. When the first demonstrations are made in a problem domain that is totally new, it is not clear at all, what are the real needs for the new application, and what are the constraints for the application. These kinds of problems are met when we are developing new kind of product which requirements are unclear for all stakeholders. In situation like this, the method that we chose seems to work well.

385

3.1. Environment The environment and architecture, discussed in the following, is what we have expected with the pilot product. However they are also assumed to be applicable for the whole product line. The physical environment of our application consists of mobile machines, especially mobile work machines. All these work machines consists some kind of engine, breaking system, transmission, and suspension controlling. These communicating subsystems often provide extra data from their status and current activity. In some cases subsystems contain control interfaces that can be accessed through some communication interface. In addition to extremely complex individual subsystems, many (if not all) work machines contain some kind of a communication network (or networks) that connects the subsystems together. Information in these communication networks can be traced and collected for further use if needed, like in our pilot product. In the pilot system, controller area network (CAN) [3] is used as a communication network within the vehicle. This network is widely used in automotives and factories and nowadays also in ships and buildings. In general, the main area of CAN networks is reliable real-time applications. 3.2. Pilot product The main goal of the prototype application is to make it possible to trace and receive data from various data sources of the physical environment. An auxiliary goal is to decrease the amount of received data, so that only necessary data is stored for the later use. The application also provides user interface (UI) that provides reports from the collected data for the user. In some configurations of the application there are also communication network connectors, so that other applications can connect to the tracer application and vice versa. 3.3. Software architecture The main philosophy of the architecture resembles physical device environment. In the software

M. Korhonen, T. Mikkonen / Journal of Systems Architecture 50 (2004) 383–392

CAN bus interface Local database Application settings Application log User inferface language interpreter

Software bus

architecture, the physical communication network and associated devices have been implemented with equivalent software modules. Each software module traces equivalent physical module and provides some kind of advanced information from the physical component for some other components that does the real analyzing and data storage work. The resulting architecture is a mix of three wellknown patterns; mediator, strategy and observer patterns of [2]. In this paper, the combination of these three patters will be called software bus [5]. Selected architecture is an obvious result from the point of view of the problem domain, where similar elements can be found. The CAN network acts as a software bus and subsystems in CAN network can be compared to functionalities (components) of the application that are communicating to each other through software bus. In our implementation, the software bus routes extensible markup language (XML) messages, which eases the debugging and specification work, and decreases the dependency of different components, compared to communication with object (or component) references. The abstract architecture of such a system is illustrated in Fig. 1, with components representing different kind of functionalities.

Network connection

Fig. 2. Available application framework for the product line.

Common components: CAN bus interface, Database, Settings, Log, User interface language interpreter

Software bus

386

Monitoring components

Fig. 3. Implemented seminal system.

ration, extending it with right data monitoring components. This application configuration is illustrated in Fig. 3.

3.4. Component configuration 4. Assessing system architecture

Component 1 Component 2

…

Software bus

We will refer to a collection of different components as a configuration. The different features needed in different subsystems will then be implemented via configurations, and added on top of a default configuration, that contains the basic infrastructure for the real applications (Fig. 2). The default configuration has already been used as a basis for a real application. The application contains the components of the default configu-

Architecture assessments are a well-established mechanism for studying the adaptability of software systems. In the simplest case, one lists the intended modifications (or best estimates), and then, the modifications are reflected on the system architecture to reveal supported and problematic modifications. Finding the right modifications, is an obvious a challenge. In this section, we will introduce the practice of software architecture assessment. In addition, we will also give an insight to the assessment procedure that we chose to organize. 4.1. Software architecture assessment: an overview

Component n Fig. 1. Architecture based on a software bus.

Assessing software architectures is a practical necessity for ensuring that the designed architec-

M. Korhonen, T. Mikkonen / Journal of Systems Architecture 50 (2004) 383–392

ture meets its functional and quality requirements. For instance, if there is a requirement for fault tolerance, the architecture should enable its implementation with e.g. replication. If no support can be found, it becomes questionable whether the requirement can be satisfied. There are two basic categories of architecture assessments, those based on questionnaires and those based on metrics. Assessments based on questionnaires assume that the assessment team collects information regarding the expectations of the stakeholders of the system. This can be implemented with series of questions answered by the stakeholders. Questions can be predefined and reused in many different assessments virtually unmodified. However, with more detailed and domain sensitive questions, it is possible to obtain more accurate information. For instance, a question can be formulated as a scenario that defines a detailed change in the functions of a system. Answering this question then gives an idea about the flexibility of the system with respect to that particular function. Measurements used for assessing software architectures contrast questionnaires in the sense that they are not about raising questions about the system but about producing answers to them. Usually they imply the development of simulations, prototypes or test environments that can be used for measurements. Moreover, there are some conventional metrics that can be applied at the architectural level. In general, however, the problem of measurements often is the lack of reliable data to measure. 4.2. Our assessment procedure The assessment we decided to carry out is loosely based on available scenario-based architecture assessment methods [6,7]. However, as we only had a limited amount of working time available, we decided to carry out the assessment in an agile fashion in two half-day meetings. Both meeting were attended by same people, which ensured smooth continuation during the second day. The number of participants in the assessment was 10, including two assessment experts, one architect, two software developers responsible for

387

implementing the system, and one project leader. In addition, a group of software architecture experts participated. The first meeting, lasting three hours, was used for introducing the assessment setting and the architecture of the system. This time, however, would not have been enough if the architecture of the system had not been familiar to the participants at an abstract level. After the first meeting, all participants were given a task to think about different scenarios for identifying whether the architecture could be used as a basis for a software product line or not. One week was allocated to this task. The total number of scenarios that we were able to identify was 46. The second meeting, lasting four hours, again gathered all the participants to a meeting. During the meeting, we went through the scenarios one by one, aiming at finding the different topic areas that the scenarios implied. Obviously, as scenarios were originally derived in isolation, many of them were combined for eased handling. Also, many of the scenarios were such that they could fit to several categories. Finally, when we were satisfied with the scenarios and their grouping to different topics, we reflected the scenarios to the actual architecture in order to detect any mismatches. In the following we will discuss the results of the assessment in more detail.

5. Evaluating scenarios Input for the assessment was a collection of potential future scenarios that the architecture should adapt to. In the following, we describe the most important scenarios grouped into four categories; adaptability, configurability, reliability, and performance. Scenarios in these categories are the most interesting ones (for the stakeholders) and that is why PLA should adopt to all these scenarios in some way at least. 5.1. Adaptability The purpose of adaptability scenarios was to assess how well our architecture would adapt if

388

M. Korhonen, T. Mikkonen / Journal of Systems Architecture 50 (2004) 383–392

something were totally different in some specific product of the product line. 5.1.1. Scenario: architectural requirement changes This scenario covers a range of different detailed scenarios. For instance, we could consider the introduction of new message type to the software bus for some new special communication needs. This kind of change would be derived e.g. from performance requirements. For instance, the requirements on processing of messages obtained from the software bus or memory footprint could be changed so that new types of protocols are used. For instance, XML might be replaced by a native protocol for performance reasons. Also the internal architecture of the database component might be forced to change for some performance restriction, with the exception that we may have configurations where no database is present at all. 5.1.2. Scenario: new tasks, not only tracing The system may be extended to cover high priority controlling of different tasks. One of these tasks could be controlling the physical devices that are connected to the communication bus. This would lead to a more complex interface to the CAN bus and would introduce a new component that would do the controlling calculations. Usually controlling calculation adds some real-time requirements for the application, and which is however not expected from the application, until now. This is because the application is designed to collect data on speed of its own. In the worst case the software bus is not able to handle the increasing data flow and Scenario 5.1.1 would take place. 5.1.3. Scenario: changes in the user interface Localization was considered as a necessity for an application of this type. This would cover both changes in the language as well as changes in the units used to describe e.g. tolerances (inches vs. millimeters). The implementation that covers these value conversions is maybe implemented to some independent component that can change the needed units. This introduced component would processes systems XML messages, which would

contain the wanted values, with the source and target units. In addition to this, different kind of target devices would force to change the amount of data to be shown on the UI and of course the look and feel of the UI would be different. If real-time UI updating is required, then the current report style UI philosophy is going to change and leads to some changes in the UI component. However these changes are not causing other changes in the other components of the system, because real-time data is available, but it is not used in the UI at the moment. If new kind of reporting components are needed (e.g. component that shows data in three-dimensional matrices), then only UI reporting system needs new functional class that can generate that kind of visual component (image). So, only the variation point (dynamic binding) of UI reporting system gets new functional variants from the visual components. 5.1.4. Scenario: external application Other applications might need to communicate with our system. This forces our application to open some kind of communication channel for the external applications and some kind of interface should be provided. In the architecture it is not a problem to provide information for other application because all the available information and events are available at the software bus, only some additional component has to be implemented that provides bridge from XML message communication to some other communication channel. It is also possible that our application needs information from external applications. In this kind of situation the similar communication bridge is needed, as in the previous case. 5.1.5. Scenario: infrastructure changes Different processor types may be needed when the tasks performed by the system change. This may depend on the type of vehicle, where we are developing an application. In addition to processor types, it is possible that the operating system or component technology is upgraded or altered. Similarly, when dealing with a totally different type of a product (e.g. a boat), it

M. Korhonen, T. Mikkonen / Journal of Systems Architecture 50 (2004) 383–392

may be a necessity to change the infrastructure considerably, because of totally different kind of constraints of the environment (processor time, storage devices, and so on). If the architecture does not consume too much processor time, then the current C++-based architecture framework can be used in multiple platforms, even in the embedded devices. The only problem seems to be the unnecessary processor load in the software bus and the quite high memory consumption in XML message communication (that is used together with the binary message communication). 5.1.6. Scenario: new product All the previous problems can realize when a new product is planned. Therefore, no special considerations were made for this issue. 5.2. Configurability Configurability scenarios have been included in the assessment to see how easily it would be possible to introduce new functionalities to the application environment. Configurability is also discussed because the functionality changes in the assessed architecture are handled with the changes in the used component configuration. 5.2.1. Scenario: multiple configurations in the same system There could be multiple configurations that can be used in one machine, depending on e.g. the needed functionality or selected user profile. Additional concerns can be raised in cases where some selected configuration does not work. In situation like this the application should probably replace the failing configuration with the latest functioning configuration. Changes in the configuration controlling causes at least changes to the software bus that maintains the active functional components. Configuration controlling might also introduce some new components to the software bus. 5.2.2. Scenario: automatic configuration In some cases, the application probably should configure itself automatically. In particular, this

389

covers issues where a special purpose hardware unit is added, and the application could react to that. This would result in a plug-and-play like configuration management. No such features have been included in the system in the current phase but maybe in future. This kind of functionality can be easily added to the system, when it is needed. 5.2.3. Scenario: configuration control upgrades The option of using remote configuration facilities was proposed instead of in-place configuration that was implemented in the current system. In addition to creating a configuration, the scenario also covers a feedback mechanism that enables the transmission of the configuration status remotely. In the long term, this may also lead to run-time configuration controlling, where new configurations are loaded on the fly, not only when the vehicle is executing its startup sequence. These and other configuration management requirements can be handled by some configuration management component or by the software bus. 5.2.4. Scenario: erroneous configuration When new components are introduced, there can be problems due to interacting components. Therefore, extra facilities are needed for checking the compatibility of different components included in the same configuration. This can obviously be checked either off-line when creating the configuration or on-line immediately before taking the configuration to use. Similar problems can be encountered at runtime as well. However, this is much more difficult to detect, as the underlying hardware and the user can affect the run-time behavior. Similarly to previous configuration scenarios this function can be separated to an independent functionality that uses configuration controlling capabilities of the software bus. 5.3. Reliability/robustness As mobile machines are usually embedded systems, reliability and robustness are important properties for them. In order to ensure that our architecture does not risk these properties, we

390

M. Korhonen, T. Mikkonen / Journal of Systems Architecture 50 (2004) 383–392

decided to assess this issue separately from the rest of the system. 5.3.1. Scenario: communication network problems When using a remote connection to monitor a vehicle, it is possible that the external communication network fails. This will result in bursts of data to be transmitted, while potentially downgrades the options of controlling the vehicle. Obviously, the vehicle itself cannot recover from such problems. Additional problems can be found from security. It may be a necessity to introduce a cryptographic and user identification functionality to secure the information that the vehicle transmits. These features can be located in the communication component or to some other component that is working tightly with the communication component. 5.3.2. Scenario: erroneous data The reception of faulty commands from the user or from the CAN bus (or from other communication buses) can be a problem. Then, if overlooking the commands is not an option, the system should either panic or preferably return to the previous configuration that was functioning in accordance to specifications. The best solution to recover from this problem would be the introduction of a component that monitors the correctness of communication messages between different devices and sensors attached to the bus. 5.3.3. Scenario: breakdown The most obvious problem falling in this category is the failure of the monitoring application, potentially leading to the corruption of the associated database or other ongoing tasks. The easiest way to improve this aspect would be the introduction of a scan at the beginning of the boot sequence that would rebuild the database and rescue the interrupted tasks in a case of problems. Also other resources should be monitored and rescued if possible and needed. A run-time error in the computation of the monitoring application is a potential problem that we have not addressed in the current application.

This could be improved by introducing a feature that would monitor the execution. Monitoring could be based on e.g. minimum and maximum values of a certain measurement (like condition monitoring). In XML-based communication, one validity checking could be based on XML validity checks. 5.3.4. Scenario: out of memory or disc space When generating the database, it is possible to run out of memory or disk. A manager module could be added that monitors the amount of available memory and disk. Problems should obviously generate some kind of an indication to the user, potentially using remote communications link. 5.4. Performance Performance of the prototype system has been acceptable. However, we had not studied the different implications of new configurations and tasks before the assessment. Therefore, we chose to treat performance as a topic of its own. 5.4.1. Scenario: N -fold increase on number of measurements When the number of measurements increases, a more efficient processor or some distribution mechanism is required. The latter is eased by the use of software bus as the architecture of the system, as this message bus can be easily used for distribution of tasks as well. 5.4.2. Scenario: configuration uses too much processor time A potential problem in the system is that the current system optimistically tries to execute all its tasks. With a more dynamic configuration scheme, a situation may occur where too many tasks are configured for execution. For such cases, the introduction of a priority management feature may become a necessity.

6. Assessment results The most challenging problems we were able to identify in the assessment were related to config-

M. Korhonen, T. Mikkonen / Journal of Systems Architecture 50 (2004) 383–392

uration. Online configuration controlling would require changes in some parts of the core of the application framework, as this option was simply overlooked in the first version of the system. In fact, the configuration controlling might have been useful also in the implemented pilot system. The additional configuration controlling component is also needed to the product line, if the configuration should automatically adapt to the current physical environment. This additional component is also the solution if the application should control multiple separate configurations, e.g. normal, test, and minimum configurations. An additional source of problems was the handling of error situations. It is unclear to us, what part of the system extends to this kind of an error surveillance mechanism and how widely it should be used in the final product line. This category also contains an automatic surveillance mechanism that could be called as condition monitoring for the application itself. Both error handling and surveillance mechanism belong to the further studies. It might be that these problems create the greatest challenges before the next assessment phase. Even if this assessment concentrated on the scenarios in various categories, it seems that almost all of them can be handled with some new or existing functional components. It also seems that all the features are located in some specific components, and are not spread all over the system. Therefore, it is not the architecture that should be modified to host the upgrades, but the individual components that take care of actual executions. The base architecture does not depend on the normal functional requirements, which makes it possible to add various types of features without changing the architecture. This architectural independence of the change of functional requirements makes it a flexible environment for product prototyping. Of course there are some side effects; one of them is unnecessary waste of processor time in the software bus. The benefits that come from a stable architecture during prototyping can be transferred to product line development. In this case, the prototype architecture can be used as a base architecture for the PLA because prototype has been developed for architecture testing, not for functionality test-

391

ing. That is also why the architecture has been quite well tested against possible requirement changes in the prototype developing time. Functionalities that have been implemented in the prototype development phase advances the PLA developing. In the point of preliminary analysis it seems that implemented functionalities are also the commonalities of a great amount of incoming products of the product family. Available functionalities fasten the first product line at product delivery time, because only product specific functionalities have to be implemented. Even if the configuration control seems to add some implementation and some reparations has to be done on the core of the PLA, the current architecture supports it at an ideological level. The current architecture makes it possible to change the configuration between runs. This limitation can be changed to in advance with some minor framework changes, so that the application framework also supports run-time configuration changes. The control of the run-time configuration is another aspect of this problem, and it can be separated from the application framework to separate functional component, as previously told. As a result, the current architecture does not change a lot. Only few additions has to be implemented on the PLA, and some new configuration functionalities has to be implemented to some component that can be used in products that require dynamic configuration controlling e.g. automatic adaptability that could be one part of the further studies.

7. Conclusions In this paper, we have introduced a case study on analyzing whether or not an architecture designed for a pilot product can be used as a basis for a product line. As a tool for analyzing this adaptability problem, we used a software architecture assessment. The purpose of the assessment was to study whether the architecture of a pilot system can be adopted as a basis for a product family. Adaptability, configurability, and scalability of the architecture, the most important

392

M. Korhonen, T. Mikkonen / Journal of Systems Architecture 50 (2004) 383–392

properties to be studied when considering the generalization of a pilot system to a product family, were all included in the assessment. In our experience, scenario-based evaluation methods (e.g. [6,7]) work well also for this type of an assessment, even if they may not be originally designed for such purpose. However, the challenge is to be able to find the right scenarios to evaluate. This requires intimate information on future products and software evolution of existing ones, which we did not have in detail. Therefore, some of the issues we chose to assess were derived from potential products via the process of abstraction, addressing e.g. general adaptability requirements. In fact, we believe that such concerns should be addressed in any case when transforming single product architecture into PLA. Moreover, the experiences of this paper can also be seen as a part of a check list that should be used when transforming single product architectures to product lines. Composing such a check list remains as a future challenge, however. Moreover, it is obvious that numerous additional cases need to be studied before publishing such a list for practical use. For this particular case, the experiences from the assessment have provided both software developers and associated vehicle manufacturers improved understanding on the structure of the pilot system, as well as on future products that would fit this product family.

References [1] P. Clements, L. Northrop, Software Product Lines: Practices and Patterns (The SEI series in software engineering), Addison-Wesley, Reading, MA, August 2001. [2] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns, Addison-Wesley, Reading, MA, 1995. [3] ISO 11519-1 Road Vehicles––Low Speed Serial Data Communications––Part 1 Low Speed Controller Area Network (CAN), 1994-06.

[4] L. Jacobson, M. Griss, P. Jonsson, Software Reuse: Architecture, Process, and Organisation for Business Success, Addison-Wesley–Longman, 1997. [5] J. Jokinen, H.-M. J€arvinen, T. Mikkonen, Incremental introduction of behaviors with static software architecture, in: H.R. Arabnia, Y. Mun (Eds.), In Proceedings of the 2002 International Conference on Software Engineering Research and Practice (SERPÕ02), CSREA Press, 2000, pp. 10–16. [6] R. Kazman, G. Abowd, L. Bass, P. Clements, Scenariobased analysis of software architecture, IEEE Software 13 (6) (1996) 47–56. [7] R. Kazman, M. Klein, P. Clements, ATAM: method for architecture evaluation, Report CMU/SEI-2000-T-04, Software Engineering Institute, Carnegie Mellon University, PA, 2000. [8] M. Korhonen, T. Mikkonen, Assessing systems adaptability to a product family, in: H.R. Arabnia, B. Al-Ani, Y. Mun (Eds.), Proceedings of the 2003 International Conference on Software Engineering Research and Practise (SERPÕ03), CSREA Press, 2003, pp. 135–141. Mika Korhonen (MSc. 2001 from Tampere University of Technology) is a researcher in Institute of Software System at Tampere University of Technology. His current research interests include software architectures and variation management.

Tommi Mikkonen (MSc. 1992, Tech. Lic. 1995, Dr. Tech. 1999 all from Tampere University of Technology) is a professor of distributed systems software at Tampere University of Technology. His current research interests include software architectures, distributed systems, and mobile software.