ATTRIBUTE-BASED PRODUCT-LINE ARCHITECTURE DEVELOPMENT FOR EMBEDDED SYSTEMS

This paper suggests a practical solution for product-line architecture (PLA) development in embedded systems, founded on analysis of the software quality attributes at the architecture level. PLA is developed based on a measurement instrument, which determines whether a product should be added to a product line or not, which parts should be added to the domain architecture framework, and which parts should be product specific. 1. Analyzing quality attributes in a domain Product-line (PL) and reusable software components are suitable approaches for embedded systems, which are often re-engineered from existing systems. Important issues in the development and maintenance of these software systems are functionality and quality. Although there are some similarities between embedded systems regarding quality attributes, there are also differences. If a quality attribute is important to one product-line domain, it does not necessarily mean it is important to another one. For example, availability is very important to switching systems, but generally it does not have the maximum level of priority. Power consumption and weight are features that may cause restrictions in the case of wireless products. In addition, the weight changes when different types of software that may exist in a product are considered. Performance requirements, such as latency and throughput, have the highest value for digital signal processing software. An important quality is cost, which is caused by the code size and data storage capacity. In order to be able to define a list of quality attribute priorities the embedded systems domain should be very well delimited. Domain analysis is also important for the evolution of a PL. From this point of view the development quality attributes such as modifiability, reusability, maintainability etc. should be considered and another list with their priorities could also be organized. 2. Definitions of the main concepts related to software PLA In this section we present an overview of the main concepts that are frequently relevant in the context of software PLA. The first part is concerned with the terminology related to the common denominator in software engineering development, which is considered to be software architecture. The definition, description and design elements of software architecture are introduced here. The second part focuses on the particular concerns related to PL software development. The definition, initiation and evolution processes of software PL and also PLA specific description represent the main headings of this second part. Definition of software architecture. A definition of software architecture is given in [3]. Here the software architecture of a program or computer system is defined as “the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them”. This definition focuses only on the internal aspects of a system and most of the analysis methods are based on this definition. Description of Software Architecture. The research in the architecture description is designed to address the different perspectives one could have of the architecture. Each perspective is described as a view. Although there is still no general agreement about which views are the most useful, the reason behind multiple views is always the same: Separating different aspects into separate views help people manage complexity. The information relevant to one view is different from that of others and should be described using the most appropriate technique for each view. Several models have been proposed that include a number of views that should be described in the software architecture. The view models share the fact that they address the static structure, the dynamic aspect, the physical layout and the development of the system. Bass et al. [3] introduce the concept of architecture structures as being synonymous to view. In addition to the four structures that are identical to the views in the 4+1 View model [18], the authors mention the uses structure, the calls structure, the data flow, the control flow or the class structure. In general, it is the responsibility of the architect to decide which view to use to describe the architecture. complement each other ARCHITECTURE DESCRIPTION Taxonomy of orthogonal properties Multiple views Abstraction level Dynamism Aggregation levelion level Dynamism Aggregation level Decomposition of functionality -conceptualDetailed design –realizationLogical Concurrency Physical Development commonalties variabilities maintainability modifiability reusability portability performance reliability security availability capacity bandwith managing administrative control Figure 1. Architecture description and the relevance to analysis of quality attributes. From the point of view of quality analysis at the architectural level, the possible representations could be very relevant in quality prediction and effort estimation. An evaluation method may need structures, which are concerned with (Figure 1): • The decomposition of the functionality that the products need to support. Components are functional (domain) entities, and the connectors are ‘uses’ or ‘passes-data-to’ relations. • The realization in a detailed design of the conceptual abstractions from which the system is built. Components can be packages, classes, objects, procedures, functions, methods, etc., all of which are vehicles for packaging functionality at various levels of abstraction. Relations include passes-control-to, passes-data-to, shares-data-with, calls, uses, is-an-instance of, etc. This structure could be crucial for understanding the maintainability, modifiability, reusability and portability of the system. • Logical concurrency. The components of this structure are units of concurrency that are ultimately refined to processes and threads. Relations include synchronizes-with, is-higher-priority-than, sends-data-to, can’trun-without, etc. Properties relevant to this structure include priority, preemptability and execution time. This structure is a key to understanding performance and is also important in reliability and security. • Hardware, including central processing units, memory, buses, networks and input/output devices. Properties relevant to this structure include availability, capacity and bandwidth. • Files and directories. This structure is important for managing and ensuring administrative control of the system as is fleshed out, including the division of work into teams (i.e. modularity) and configuration management. A taxonomy of formally-defined orthogonal properties of software architectures (TOPSA) that extends an architecture definition is given in [8]. The TOPSA space has three dimensions: abstraction level (conceptual, realization), dynamism (static, dynamic) and aggregation level. The TOPSA can facilitate discussions regarding software architecture during development and evolution. This model makes a clear distinction between conceptual architecture and realization architecture, suggesting the creation of architecture models suited for different purposes and different stakeholders. Syntactic architectural notations should be well understood by the parties involved in the analysis. Architectural descriptions need to indicate the system’s computation and data components as well as all the relationships between components. The result of an architecture evaluation process depends on how well the description is made. The TOPSA model and the architecture representation based on multiple views complement each other. Different views offer valuable examples for abstraction, dynamism and aggregation dimensions in a TOPSA space. Table 1 exemplifies the mappings of two quality attributes, the performance and reusability, on the architecture views associated in a TOPSA space. For example, performance could be analyzed from the logical concurrency viewpoint in a realizational plane of TOPSA space. Table 1. The mapping of quality attributes on architecture description. Quality attribute Architecture View TOPSA space (Abstraction, Dynamism, Aggregation) Performance Logical Concurrency Realizational Reusability Functional, Detailed design, Development Conceptual/Realizational, Aggregation An analysis method could exploit these relationships in the form of a defined set of rules, which states which view in the TOPSA space is the most appropriate for the analysis of a given quality attribute. Software Product Line. A software product line is defined as a group of products sharing a common, managed set of features that satisfies specific needs of a selected market [3]. The products should be suitable to a market strategy and application domain. They share an architecture and are built from components. The PL definition includes three main concepts which are feature, architecture and component. The common set of features represents the source of information for the shared architecture design, which is called PLA. From the viewpoint of decomposition and composition approaches of the architecture design methods, we can identify a bidirectional relation between PLA and the set of components [2]. In one direction of this relation, PLA influences component development considering the decomposition. In the opposite direction of this relation the composition aspect acts and the set of components influences PLA development. Some of the issues with PL are related to the process of initiation and how to deal with its evolution process. • Initiation. Software PL does not appear accidentally, but require a conscious and explicit effort from the organization interested in using the PL approach. Basically, one can identify two relevant dimensions with respect to the initiation process. The organization may take an evolutionary or a revolutionary approach to the initiation process. On each dimension the PL initiation can be