The Impact of Maintainability on Component-based Software Systems

Matinlassi Mari, Niemelä Eila VTT Technical Research Centre of Finland Software Architectures Group {Mari.Matinlassi, Eila.Niemela}@vtt.fi

Abstract and CORBA. CBSE includes wide-ranging issues from the theory of software reuse to the reality of commercial There is a great deal of inconsistency and vagueness in software markets, from available tools to programming the treatment of and terminology involved with software language mechanisms and from practical testing to maintainability. This is exacerbated by the fact that there rigorous formal specification. are a number of different dimensions of maintainability, This study discusses maintainability, i.e. the capability each requiring specific treatment. The trends of of the software to be modified [2, 3] from the perspective increasing systems functionality and increasing systems of component-based software systems, wherein today, the complexity have given rise to new dimensions of concept of maintainability is of major importance [4], [5]. maintainability since ISO/IEC defined maintainability as As a matter of fact, most of the software engineering “the capability of the software to be modified” in 1996. methods and techniques e.g. reuse, product line approach This paper introduces the framework of maintainability and component-based software engineering have the and the techniques that promote maintainability in three same final goal: maintainability. For instance, reusability abstraction levels; system, architecture and component. promotes maintainability through decreasing In the system dimension, the maintainability requirement development costs. On the other hand, maintainability is a is considered from a business-related point of view. In prerequisite for reusable software, because there is no architecture, maintainability means a set of quality meaning in e.g. a long-living reusable component that is attributes, e.g. extensibility and flexibility. At the not maintainable. As seen in many cases, some component level, maintainability focuses on modifiability, characteristics of maintainability can be seen as a pre- integrability and testability. requisite for the provision of another. The definitions for maintainability are many and its 1. Introduction various nuances are often confused or misunderstood, as are all the other quality attributes [6], [7], [8]. Therefore, Software maintenance is long known as one of the this study defines the dimensions of the maintainability most expensive and resource requiring phase of the requirement in component-based software systems and software development process. Especially in component- clarifies the impact of maintainability on software based systems, the development phase may be displaced systems. with integration in the near future. Therefore, The requirement of maintainability permeates all levels maintenance will get more and more attention and the of component-based software. Therefore, software requirement of maintainability and its impact on software developers need support for each maintainability development has to be clearly understood. The term dimension and in order to provide that support, it has to “software component” has varying definitions. According be understood what maintainability means and what its to [1] software component is a nontrivial, nearly impact on component-based software systems is. In independent, and replaceable part of a system that fulfills particular, maintainability of software that involves a clear function in the context of a well-defined externally developed components differs from the architecture. In addition, a component conforms to and traditional software maintenance in that the activity of provides the physical realization of a set of interfaces. In maintenance is likely to be performed by someone other addition, component-based software engineering (CBSE) than the developer. This is the case whether the is about developing, marketing and utilizing software component is an ‘in-house’ developed component or a components with their related assets. Therefore, CBSE pure commercial component. goes well beyond enabling technologies e.g. JavaBeans

Proceedings of the 29th EUROMICRO Conference “New Waves in System Architecture” (EUROMICRO’03) 1089-6503/03 $17.00 © 2003 IEEE The structure of this paper is as follows. First, we software to environments other than those for which it define not only the pre-required quality attributes for was specifically designed. maintainability but also techniques that promote Although the quality model includes functionality, i.e. maintainability. Then, we divide software into three the system’s ability to do the work for which it was abstractions; system, architecture and component intended, we see it as a main category of dimensions and discuss the impact of quality attributes on executionfunctional quality attributes, realizing that each dimension. A case study of a product line of the functionality cannot be considered an architectural traffic information systems illustrates the impacts of quality attribute [9]. However, interoperability, maintainability. In the end, we conclude our statements adaptability and reliability can be considered special, and draw out our future plans. newly emerged forms of functionality, the forms that are architectural in nature [12]. While the characteristics of 2. Background software systems are changing from monolithic to modular networked systems, and furthermore, to 2.1. Quality attributes spontaneously self-organizing nets of adaptive computing ISO/IEC Draft 9126-1 defines a software quality units, new quality attributes are defined in order to model [2] with six categories of quality characteristics: characterize the qualitative properties of systems. Thus, functionality, reliability, usability, efficiency, the list of quality attributes is sensitive to changes in a maintainability and portability. Quality characteristics are similar way to attractiveness of systems’ qualities. also called quality attributes [9], which can be categorized Table 1. Functional Execution quality into functional execution and non-functionalevolution attributies. quality attributes (also called simply ‘qualities’). Functional Execution qualities are observable at run-time. Attribute Description That is, they express themselves in the behavior of the Performance Responsiveness of the system, system. Evolution Non-functional qualities cannot be which means the time required to discerned at run-time, meaning that the solutions for non- respond to stimuli (events) or the functionalevolution qualities lay in static structures of the number of events processed in software system. Therefore, they should be considered in some interval of time. the phases of the product’s life cycle, i.e. in development Security The system’s ability to resist and maintenance of a software system. Although we use unauthorized attempts at usage and categorization into execution and evolution qualities, denial of service while still other categorizations are available (see a collection e.g. in providing its service to legitimate [10]). users. Chung et al. [10] define a framework for representing Availability Availability measures the the design process of non-functional requirements (or proportion of time the system is up quality attributes, if you will). However, the framework and running. does not categorize neither define the quality attributes Usability The system’s learnability, explicitly but concentrates on recording the reasoning efficiency, memorability, error process behind the design decisions. avoidance, error handling and Table 1 and Table 2 define the functional execution satisfaction concerning the users’ and non-functionalevolution qualities by extending the actions. definitions in [11] with new attributes, namely being Scalability The ease with which a system or adaptability (functional execution quality) and component can be modified to fit extensibility (non-functionalevolution quality). [3] the problem area. denotes adaptability as a synonym for flexibility. Reliability The ability of the system or However, we believe the meaning of adaptability and component to keep operating over flexibility is different today and these attributes exist even the time or to perform its required in different attribute categories (execution and functions under stated conditions evolutionfunctional and non-functional). Adaptability for a specified period of time. means the ability of software to adapt its functionality Interoperability The ability of a group of parts to according to the current environment or user, whereas the exchange information and use the strict meaning of flexibility is about easy adaptation of one exchanged. Adaptability The ability of software to adapt its

Proceedings of the 29th EUROMICRO Conference “New Waves in System Architecture” (EUROMICRO’03) 1089-6503/03 $17.00 © 2003 IEEE functionality according to the components. current environment or user. Portability The ability of the system to run under different computing systems: With a quick look, some of the non- hardware, software or combination functionalevolution qualities in Table 2 seem to be of the two. almost the same. However, the attributes really have at Reusability The system’s structure or some of least a different sound to their meaning. For example, its components can be reused again maintainability may be equalized with modifiability [9]. in future applications. However, we think maintainability is also affected by Integrability The ability to make the separately many other evolution quality attributes than modifiability. developed components of the Modifiability includes adding, deleting and changing system work correctly together. software structures and therefore, extensibility (also called expandability or extendability [3]) and portability Testability The ease with which software can can be considered special forms of modifiability. be made to demonstrate its faults. Furthermore, modifiability includes e.g. optimization and With the interpretation represented above, we conclude fault correction. the definition of maintainability as in Figure 1. Two of the non-functionalevolution qualities have a Maintainability is the ease with which a software system qualitative sound to their definition. In other words, two or component can be modified. Modifications may of the quality attributes define the others qualitatively as include extensions, porting to different computing follows. Flexibility means the ease with which software systems or improvements. However extensibility and can be modified and modifiability means the quickness portability occur as distinct attributes, “improvability” and cost-effectiveness of modifications. does not – so far – appear in literature as a quality ISO/IEC defines sub characteristics of maintainability attribute. Improvements include correcting faults or sub characteristics as follows: changeability, testability, exceeding any functional execution or non- analysability and stability. Changeability is a synonym for functionalevolution qualities of the system. Flexibility, modifiability. The definition of testability in [2] is reusability, testability and integrability contribute to somewhat restricted and our definition of testability modifiability and therefore, are defined as sub attributes therefore covers both testability and analysability. As far of maintainability. as stability is concerned it equals to modularity [3] both meaning the degree to which software is composed of Flexibility discrete components such that a change to one component has minimal impact on the other components. These Reusability definitions are very close to coupling, i.e. the manner and Extensiblity degree of interdependence between software modules [3]. Maintainability Modifiability Low coupling is generally known as a basic rule of thumb Portability in component-based software architecting, not as a Testability quality requirement or attribute of any particular system. Table 2. Non-functionalEvolution qualitiy Integrability attributes. Figure 1. Sub attributes of maintainability. Attribute Description Maintainability The ease with which a software 2.2. Other characteristics related to system or component can be maintainability modified or adapt to a changed environment. In this section, we introduce other characteristics Flexibility The ease with which a system or related to maintainability. Often, these characteristics are component can be modified for use confused with quality attributes, but actually they are in applications or an environment techniques that promote and support achievement of other than those for which it was maintainability and its sub-attributes. specifically designed. Modifiability The ability to make changes 2.2.1 Traceability. Traceability is the ability to quickly and cost-effectively. document and follow the life of a concept throughout Extensibility The systems ability to acquire new system development. It is forward directed (post

Proceedings of the 29th EUROMICRO Conference “New Waves in System Architecture” (EUROMICRO’03) 1089-6503/03 $17.00 © 2003 IEEE traceability: describing the deployment and use of a or monitoring of user behavior, is an essential property concept) as well as backward directed (pre traceability: for a maintainable system [4]. describing the origin and evolution of a concept) [13]. According to [19], the classification of monitoring Although traceability is an essential characteristic of the capabilities is as follows: component-based software development to achieve a x Intra-component; these techniques observe the maintainable solution, it is a supporting technique to behavior of a component, to understand and achieve the qualitative property of the artifacts produced demystify the component developer’s assumptions during the development process. and intended usage of the component. x Inter-component; these techniques observe the 2.2.2 Variability. According to [14], the differences behavior of two or more components, to understand among products are managed by delaying design potential mismatches between components. decisions, thereby introducing variation points, which x Extra-component; these techniques observe a system again are bound to a particular variant or variants. A of cooperating components, to understand macro- variation point identifies a location at which a variation level issues dealing with performance and misfits, can occur in the system [15]. Therefore, variability is not etc. That is to say, extra-component monitoring is a quality factor as such, but it provides a mechanism to system level monitoring. manage the anticipated changes in software structure(s) A Built-In-Test (BIT) component [20] is a component during the evolution of systems, thus increasing all sub- model that has one or more test interfaces (for intra- qualities of maintainability. component monitoring) and a test mechanism (for inter- Different (and overlapping) types of variants are component monitoring) embedded in a component. BITs introduced [16], [17], [18], but the most commonly used offer two benefits: the component user can check the are: behavior of the component and the component can check x Mandatory; the type included in all products in the if it is deployed in an inappropriate environment. Thus, domain. monitorability is a technique that promotes testability. x Optional; the type for any product in the domain. x Alternative; a choice that cannot coexist with other 3. The impact of maintainability alternatives (in the same variation point). Maintainability has an impact on three abstraction Possible dependencies between variants are the levels: system, architecture and component dimension. In ‘requires’ relationship and the ‘mutually exclusive’ i.e. the following, we define the impact of the maintainability mutex relationships. requirement on all dimensions. Table 3 summarizes the impact of maintainability on a software system (S), 2.2.3 Tailorability. Tailorability is a loose term used architecture (A) and component (C). ‘X’ means that in component-based software development to describe the quality attribute has a certain impact at the level in ability to customize and configure components, but also question. Each column in Table 3 and Table 4 will be to add new components to the system and combining concerned in more detail in the following sections from services of multiple components in novel ways [4]. Here 3.1 to 3.3, wherein the differences of attribute impacts at we consider tailoring as a technique (like variation points) each level are discussed. but instead of software architecture, tailorability focuses on customizing the internal capabilities of components Table 3. Quality impacts on the dimensions of according to customers’ needs. maintainability. Attribute S A C 2.2.4 Monitorability. Isolating the faults in a Flexibility X component-based system is difficult, especially in Reusability X X X systems that utilize third party components, because the Modifiability X X integrator has to ascertain (1) how the components work Extensibility X X and (2) why they do NOT work. The source of the Portability X difficulty is obvious: the integrator has no visibility into Testability X X X the components and no control of their operation [19]. Integrability X X Therefore, monitorability, that is the systems property to support e.g. measurement of performance and resource usage, watching for failures, chase up security violations

Proceedings of the 29th EUROMICRO Conference “New Waves in System Architecture” (EUROMICRO’03) 1089-6503/03 $17.00 © 2003 IEEE Table 4. Factors conducive to quality position where realization of maintainability provides the attributes. most benefits. After prioritizing the sub-qualities of maintenance, the appropriateness of supporting Technique S A C Attribute techniques has to be estimated. Tailorability X Modifiability Monitoring of behavior and system resource usage Monitorability X X X Testability gives information required when changed systems have to Variability X X Extensibility be tested. Monitoring techniques also set prerequisites for Traceability X X X Maintainability the system-level test support. Table 4 illustrates how each technique related to On the other hand, variability management provides a maintainability promotes the sub-qualities of mechanism to handle the hot spots of changing maintainability. Also, the dimensions of impact (S, A or functionality, structure, behavior and allocation. C) are defined. Tailorability largely means modifiability Post traceability of requirements through architecture in the component dimension. Monitorability is expressed and components to code requires robust and reasonable in all dimensions as follows. Extra-component documentation, but it also provides a path to put monitorability affects system level testability and second, maintainability into practice and a tracking mechanism inter-component monitorability affects testability on the for quality maintenance. architectural level and finally, intra-component A standard way of providing traceability is the monitorability is conducive to individual component establishment of cross-reference data. Such references testability. Variability appears largely in the architecture can be expressed as links or matrices where connections dimension but also in the system dimension whereas between the various artifacts in code, architecture and traceability must be provided from the system level requirements are made explicit [17]. through the architecture and the design to the 3.2. Architecture dimension components. These key factors may be similar to what normally In the architecture dimension maintenance definitely exist also in non component-based systems. However, means modifications that have to be done quickly and using components means that the nature of these cost-effectively. Modifications may include porting the maintenance activities changes as described below. system into a new operating system or other environment, or extending the system with new functional features. 3.1. System dimension That is, quality requirements (derived from When the overall quality requirement is maintainability) that should be considered at the maintainability, at the system level its value is considered architectural level are at least modifiability, portability from business-related points of view as follows [21]: and extensibility. x Estimation of the effort required for adopting Extensions to the architecture may also mean the software to other contexts, i.e. for producing other integration of third party software components. products, sub-systems or components. How often Therefore, integrability concerning future third-party is this kind of work required? components also has to be supported in architecture. x Extent of software usable for future products. In spite of the fact that architecture has been designed When will it be utilized? to be easily modifiable for changes that can be predicted, x Identification of the execution platforms upon in order to have a maintainable architecture, the which software should be executed. Why are they modifications that are not predicted should also be easy to selected? do. Easy modifications for environments the architecture x Identification of software that might be changed was not initially designed for means flexibility of the during the life cycle of the product. Which architecture. standards will be adhered to? So far, all the maintainability impacts described above x Assumptions of the extended purpose of the have been related to modifying the architecture. Testing system. Why and how is it happening? the modified parts of the architecture follows x Anticipation of maintenance cost based on modifications. As a matter of fact, testability is the estimated length of the life cycle of the system. capability of the architecture to enable modified software What does an upgrade cost, and how often is it to be validated. However, at the architecture level, required? testability means quality analysis, i.e. evaluation of architecture and how maintainable it is. There are several Discovering the facts of the above-mentioned list of appropriate scenario-based analysis methods that can be issues attempts to assist in finding out the type, scope and

Proceedings of the 29th EUROMICRO Conference “New Waves in System Architecture” (EUROMICRO’03) 1089-6503/03 $17.00 © 2003 IEEE applied [22]. However, in order to be testable the x Stability of the component. What does the architecture has to be documented properly [23]. component version history reveal? How high is the Reuse of architecture may be the only way to frequency of upgrades? What are the reasons for implement reusability when implementation technology is upgrades? changing from one product to another. Although it is not x Marketing trends. What are the technology the case in most component-based software systems, alternatives on the markets? Are there alternative, architecture sets the conditions, scope and time when comparable components available in the market? reuse is possible and beneficial. x Availability of customer support. How complete is the customer support for the component? What is the 3.3. Component dimension form of the support (phone-based, online, discussion The impact of maintainability varies depending on the groups etc.)? Is the support cost in balance with the size of the component. At least the following assistance provided by the vendor? maintainability impacts apply to small components: x Integrability, i.e. conformance to component model 4. Case study and standards used in the system the component is to be integrated in. 4.1. Overview x Interoperability with components from many Our case study, a product line (PL), consisted of different vendors. Although interoperability is an different kinds of client terminals used for fare collection execution quality, it is related to integrability and in public transportation. When considering a product line transitively to maintainability. we define the first two product line members as: x Modifiability, how easy it is to modify the x P1; a driver terminal, used for fare collection, travel component to satisfy local requirements. card loading and usage, data transfer and locating. x Testability of black box components through The device is a fixed-point device located in a monitoring intra-component behavior and failures. vehicle or point of sales. In the case of large software components that have x P2; a conductor terminal used for fare collection, their own architecture or perhaps a product line travel card loading and usage, data transfer and architecture, the impacts are naturally the same as the locating. The device is a wireless, portable terminal impact on architecture dimension as described above. used in a vehicle. Monitoring black-box components is difficult because At the end of the day, accountings are transferred from the intra-component behavior is hidden. Thus, rather than the Px devices to an office system at the depot. The office intra-component capabilities maintainers must use inter- system states for software connected with the PC component and extra-component monitoring capabilities computers of the system. However, the office system’s to observe system behavior [4]. Component suppliers are software was out of the scope of this product line. responsible for intra-component monitoring capabilities Both products share a common software architecture through creation of special open monitoring interfaces. and many common features. Both product line members Business factors also affect maintainability of also have in-product variability, meaning different commercial components [4], [24]. The following criteria product versions depending on the target country and [24] aim to address the factor of system evolution in market area. component selection: The aim of this case study was to improve the x Vendor business stability. how long has the vendor maintainability of the software product line. been in business? Is there a risk of the vendor going Maintainability requirements were discovered in a out of business? product line phase, wherein one product (P1) was already x Development process. What kind of testing process implemented and the first customer deliveries of that does the vendor use? Is the certification process at product were just about to emerge (Figure 1). The the vendor site appropriate? feasibility study of the second product, the family x Obsolescence of the component. What happens if the member P2 was ongoing. vendor goes out of business? What happens if the The case study concentrated on considering component becomes obsolete? maintainability from the perspective of architecture. In x Maintenance contract. Who (vendor/integrator) is addition, the case study included one OCM (Original responsible for the component maintenance and to software Component Manufacturer) and one COTS what degree? (Commercial-Off-the-Shelf) component, which refined the scope of the example. The OCM component serves

Proceedings of the 29th EUROMICRO Conference “New Waves in System Architecture” (EUROMICRO’03) 1089-6503/03 $17.00 © 2003 IEEE for data transfer between the product (P1 or P2) and the obsolescent travelling card technologies. At the depot, whereas a database was acquired as a COTS component level, the OCM component for data transfer component. The system level dimension of was required to be easily customized (that is, component maintainability was achieved through considering the level modifiability) to support different data transferring system from the perspective of overall functional and technologies. quality requirements of software. However, marketing At the system level, extensibility included the trends, emerging standards and future advances in possibility to easily extend the product features towards hardware capabilities also affected the maintainability public transportation information management, instead of requirements in the system dimension. bare fair collection and accounting. Thus, at the architecture level, extensions to the architecture were PL Requirements implemented through variation points. Variability was Functional Quality traced through the chain of development artifacts. Requirements Requirements Portability in the architecture dimension meant capturing the environment-specific software into Evolution Execution qualities qualities components or layers that encapsulated environment users from the environment. Environment here means e.g. different peripherals, display and printer types. Therefore, Reusability, Maintainability, in some of the portability requirements variability was extensibility, portability portability used as a supporting technique. One of the portability requirements was also that the software should be PL initiation New product portable to a single fixed node and to a distributed environment with the main module and a trip computer.

P1 P2 5. Conclusion and future work Maintainability permeates all levels of component- V1 V2 V3 V1 V2 based software and therefore its nature is often misunderstood. In order to clarify the meanings of Figure 1. Case study: extension of a PL. maintainability, its relations to other qualities were analyzed resulting in a framework that attempts to assist 4.2. The impact of maintainability on the case software developers become aware of when, where and study how they should pay attention to the many faces of maintainability. Table 5 summarizes the impact of maintainability Maintainability concerns the whole life cycle of the requirements on the PL case study with two product component-based software, and therefore, it exists at all members. In the table, lines with gray shading concerned abstraction levels in software development. We identified the case study. The main quality requirement was three levels: system, architecture and component. In these maintainability. During the evaluation, it revealed that in dimensions, maintainability means different things, and this particular case, maintainability was expressed in the therefore, techniques to achieve it also vary. However, form of modifiability, extensibility and portability. traceability from one level to another is the key; if it is Table 5. Maintainability dimensions in the case omitted, investments will not be returned. That is why study. our further work will focus on the qualities essential for evolvable systems and methods and techniques to develop Attribute S A C and keep them living on. Flexibility X Reusability X X X Acknowledgment Modifiability X X We would like to thank Buscom Oy for providing the Extensibility X X case study. The publication of this paper has been Portability X supported by a national joint research project funded by Testability X X X the National Technology Agency (Tekes), VTT and Integrability X X Finnish industry. At the architecture level, modifiability included requirements such as deleting features that are related to

Proceedings of the 29th EUROMICRO Conference “New Waves in System Architecture” (EUROMICRO’03) 1089-6503/03 $17.00 © 2003 IEEE References Evaluation, PuLSE-DSSA," IESE, IESE-Report 038.00/E, June 2000 2000. [1] A. Brown and K. Wallnau, "The Current State of [14] J. Bosch, G. Florijn, D. Greefhorst, J. Kuusela, H. CBSE," IEEE Software, vol. September/October, pp. Obbink, and K. Pohl, "Variability Issues in Software 37 - 46, 1998. Product Lines," in Proceedings of the 4th [2] ISO/IEC, "Information Technology - Software Quality International Workshop on Product Family characteristics and metrics - Part 1: Quality Engineering, PFE-4. Bilbao, Spain: European characteristics and sub-characteristics,"., 1996, pp. 21. Software Institute (ESI), 2001, pp. 11 - 19. [3] IEEE, "IEEE standard glossary of software [15] S. Salicki and N. Farcet, "Expression and usage of the engineering terminology," in Std 610.12-1990: IEEE, Variability in the Software Product Lines," in 1990, 84p. Proceedings of the 4th International Workshop on [4] M. Vidger, The Evolution, Maintenance and Product Family Engineering. Bilbao, Spain: European Management of Component-based Systems. Boston: Software Institute (ESI), 2001, pp. 287 - 297. Addison-Wesley, 2001. [16] K. C. Kang, S. Cohen, J. Hess, W. Novak, and A. [5] P. Bengtsson and J. Bosch, "Architecture Level Peterson, "Feature-Oriented Domain Analysis. Prediction of Software Maintenance," in Proceedings Feasibility study,," Software Engineering Institute, of the Third European Conference on Software Pittsburgh CMU/SEI-90-TR-21, 1990. Maintenance and Re-engineering, 1999, pp. 139 - 147. [17] M. Anastasopoulos and C. Gacek, "Implementing [6] O. Preiss, A. Wegmann, and J. Wong, "On Quality Product Line Variabilities," in Proceedings of the Attribute Based Software Engineering," in The SSR'01: ACM, 2001, pp. 109 - 117. Proceedings of the 27th Euromicro Conference: IEEE, [18] F. Bachmann and L. Bass, "Managing Variability in 2001, pp. 114 - 120. Software Architectures," in Proceedings of the [7] M. Bertoa and A. Vallecillo, "Quality Attributes for SSR'01: ACM, 2001, pp. 126 - 132. COTS Components," presented at ECOOP Workshop [19] S. Hissam, "Experience Report: Correcting System on Quantitative Approaches in Object-Oriented Failure in a COTS Information System," in Software Engineering, Malaga, Spain, 2002. Proceedings of the International Conference on [8] J. Offutt, "Quality Attributes of Web Software Software Maintenance: IEEE, 1998, pp. 170 - 176. Applications," IEEE Software, vol. 19, pp. 25 - 32, [20] H. Edler, Hörnstein, J., "BIT in software components," 2002. EC 5th Framework Project IST-1999-20162. 2001. [9] L. Bass, P. Clements, and R. Kazman, Software [21] E. Niemelä and T. Ihme, "Product Line Software Architecture in Practice. Reading, Massachusetts: Engineering of Embedded Systems," in Proceedings Addison-Wesley, 1998. of SSR'01, Symposium on Software Reusability. [10] L. Chung, B. Nixon, E. Yu, and J. Mylopoulos, Non- Toronto, Ontario, CA, 2001, pp. 118 - 125. functional requirements in software engineering. [22] L. Dobrica, Niemelä, E., "A Survey on Software Boston, Dordrecht: Kluwer Academic Publishers, Architecture Analysis Methods," IEEE Transactions 2000. on Software Engineering, vol. 28, pp. 638-653, 2002. [11] L. Dobrica and E. Niemelä, A strategy for Analyzing [23] A. Purhonen, E. Niemelä, and M. Matinlassi, Product Line Software Architectures, vol. 427. Espoo: "Viewpoints of DSP Software and Service VTT Electronics, 2000. Architectures," To appear in the Journal of Systems [12] L. Davies, Gamble, R. F., Payton, J., "The impact of and Software, 17p, 2003. component architectures on interoperability," The [24] S. Yacoub, A. Mili, C. Kaveri, and M. Dehlin, Journal of Systems and Software, vol. 61, pp. 31-45, "Hierarchy of COTS Certification Criteria," in 2002. Proceedings of the First Software Product Lines [13] M. Anastasopoulos, J. Bayer, O. Flege, and C. Gacek, Conference, P. Donohoe, Ed. Boston: Kluwer "A Process for Product Line Architecture Creation and Academic Publishers, 2000, pp. 397 - 411.

Proceedings of the 29th EUROMICRO Conference “New Waves in System Architecture” (EUROMICRO’03) 1089-6503/03 $17.00 © 2003 IEEE