Supporting Component-Based Software Development ... - CiteSeerX

Supporting Component-Based Software Development Using Domain Knowledge* L. Baum, M. Becker, L. Geyer, A. Gilbert, G. Molter, V. Tamara System Software Research Group, University of Kaiserslautern D-67653 Kaiserslautern, Germany {lbaum, mbecker, geyer, agilbert, molter, tamara}@informatik.uni-kl.de

Abstract A consistent implementation of component-based reuse bears several implications for the design of the software development process. For instance, requirements engineering has to be tailored to particularly elicit information necessary for selecting and configuring appropriate components. Concerning the development of components, a thorough analysis of the envisioned domain has to provide the necessary information about how specific requirements can be met. To this end, a domain model describes the commonalities and variabilities of possible solutions. While commonalities can be mapped directly to fixed implementations, this paper presents an approach to map requirements concerning the variabilities to concrete component configurations. Our approach is based on the technique of design spaces, which allows to both capture the variability of a domain and to formalize transformation rules leading from requirements to possible solutions. In the course of a detailed example, we demonstrate how the design space technique can be applied to provide tool support throughout the development process.

1. Introduction The highly competitive and dynamic field of software development implies the need to continuously increase the efficiency of development processes. Software reuse and especially the component paradigm are commonly recognized approaches to address this problem. After all, in order to actually gain positive economic effects, a thorough design of the reusable components as well as their infrastructure is essential [5][7]. For example, components both have to provide sufficient flexibility in order to be reusable in different environments, and have to be concrete enough to be of any use at all. The additional costs for making component implementations flexible, however, only pays off in case the components are reused often enough. To this end, an accurate analysis of the envisioned applications in a chosen domain is required, providing detailed information about common features that are likely to be subject to reuse. The result of such an analysis is a so-called domain model that captures all requirements perceived to be rele*This research was supported by the Deutsche Forschungsgemeinschaft as part of the Special Research Project 501.

vant for system design in the domain. These requirements can be distinguished as common to all software systems in the domain or as specific for individual systems. While common features relate to essential system functionality, variable features have to be further analyzed in order to decide if they are worth being implemented as reusable components. In particular, variable features are possible candidates for an implementation as generic components providing the flexibility to cover a set of similar requirements. While for large domains it is unlikely to cover all requirements by pre-built components, smaller domains with a manageable set of features offer the possibility to provide a set of ready-to-use solutions. In combination with a generic software technology allowing to automatically customize components, the development of software systems can thus be automated at least partially. During system development, reusable artifacts have to be explicitly considered, and the development process has to be tailored to appropriately reflect the reuse-based approach [8][16]. Reuse activities such as component selection and configuration have to be modeled as separate process steps rather than being performed under the hood of conventional development steps. In contrast to sporadically searching for reusable assets to implement a particular functionality, the whole development process is focused at the selection and configuration of pre-built components driven by application requirements. To this end, the domain model provides the necessary knowledge about which requirements are addressed by which components in the reuse pool, and in particular, which configurations of these components are required. By explicitly formalizing this information, tools can support substantial parts of the development process. In summary, the domain model plays an important role both during the development of reusable components and during the composition of systems based on these components. This paper proposes design spaces as a technique to describe the variable requirements of a domain, the configuration parameters of reusable components, and the rules for mapping requirements to component parameters. The deployment of this technique is demonstrated at the domain of embedded operating systems, which is perceived small enough to possibly cover a major part of the solution space by pre-built components. The remainder of this paper is structured as follows. Section 2 will discuss how a domain model in general can

SCI 2000 Invited Session on Generative and Component-based Software Engineering, July23-26, 2000, Orlando, Florida

support the selection and the configuration of reusable components. Section 3 then presents design spaces, our technique of choice for both capturing variable domain requirements and for describing component properties. In Section 4 the application of the design space technique is presented in general, while Section 5 adds a detailed example based on the QNX operating system. The paper is concluded with a discussion of our approach and some remarks on our objectives for future work in Section 6.

2. The notion of a domain model The notions of a domain and a domain model are still quite vague in the research community. A domain in this context is marked out by a set of similar applications, while similarity is defined by applications “having so many properties in common that it is advantageous to first study the common properties before analyzing individual characteristics” [13]. Applications having such an extensive set of properties in common ultimately form a family, and the entirety of those members of the family that are envisioned to be developed in the near future define the domain. From another point of view it can also be argued that a domain is defined by a reference architecture that can be instantiated in a number of ways and thus covers a set of similar applications. This definition however narrows the scope of a domain to what can be realized by a single architecture, whereas the former definition allows a domain to comprise several different architectures. For the remainder of this paper, we shall use the term ’domain’ in the somewhat broader sense. A domain model is intended to capture the properties of all existing and envisioned applications in a chosen domain. A specific domain model therefore lists both properties being common to all applications considered, and properties being characteristic of individual applications. The model moreover captures all possible interdependencies between these properties, thereby keeping track of which properties can be combined and which are mutually exclusive. Since properties directly correspond to application requirements, the domain model can also be understood as a generic requirements catalog for applications within the domain. The information about interdependencies can then be used to assure consistency for a given set of requirements. In most cases, domain models are expressed using informal prose, while in some cases additional techniques for stating requirements or for describing architectural aspects are used to complement the description of a domain model. Regardless of how a domain model is actually represented, the information provided is valuable both for setting up a pool of reusable components for a chosen domain, and for the actual development of applications in the domain. For the development of reusable assets, the domain model provides a first starting point to define the scope of component pools. Since components can sensibly only be developed for a specific architecture [4], the different architectures required to cover the domain have to be identified and have to be assigned individual pools of reusable components. Each architecture then has to be

designed with respect to the common properties as well as the variability required to cover the chosen set of requirements, and the respective component pools are implemented to meet these requirements. The decomposition of the system into subsystems and components as defined by the architecture ultimately also implies a decomposition of the requirements into requirements to individual components. In cases where such an attribution of requirements to components is not possible, for instance regarding aspects such as scalability or fault tolerance, the architecture as a whole can be considered to implement the respective requirements. The design knowledge of how requirements are mapped to components can consequently be captured in the domain model, providing a basis for substantial support during the deployment of the components. In the context of a development project, the domain model provides a first starting point in the form of a generic requirements catalog both facilitating requirements capturing and guiding the requirements description along the lines of existing components. The domain model is instantiated by actually selecting the desired application properties. Requirements identified by the domain model as common to all members of the family are then used to select the appropriate architecture and the appropriate pool of components. The knowledge about how requirements are mapped to components which is also coded in the domain model helps to further break down system requirements to individual components, thereby supporting the selection of appropriate components from the reuse pool. In our example domain of embedded operating systems, we furthermore use so-called generic components [1] which can be tailored at a fine degree of granularity in order to meet a set of different requirements. To this end, these components provide so-called generic parameters allowing to adjust certain properties without manually changing the implementation. Given the settings of generic parameters, generators automatically instantiate the generic component with the desired properties. In this context, the design knowledge coded in the domain model also helps to derive the configuration parameters for generic components. Using the semi-formal design space technique to both capture important aspects of the domain model and to describe the properties of components ultimately provides the opportunity the automate important parts of the overall development process.

3. Design Spaces One prerequisite for the automatic construction of software systems based upon generic components is the deployment of compatible description techniques for the representation of application requirements, domain knowledge, and component properties. For this purpose, we apply the concept of design spaces, which was originally presented in [9][10] as a semi-formal way to assess user-interface requirements and to study their effects on the choice of implementation architectures. However, our extended notion of design spaces has shown a general


suitability of this concept for representing and processing requirements as well as design decisions in several other application areas, too [2][3]. A design space (DS) is a multidimensional space representing requirements and design choices. It is spanned by a set of dimensions identifying relevant criteria for characterizing artifacts in a specific domain – components, subsystems, or complete systems. In the domain of embedded operating systems, e.g., such criteria might relate to functional aspects such as the scheduling strategy deployed, or to non-functional aspects such as the timing behavior of specific services. Design spaces comprise two types of dimensions. Discrete dimensions enumerate possible alternatives, so-called categories. Categories of the scheduling strategy dimension, for instance, are the available disciplines like round robin, first-come-first-served, shortest-job-first and so on. To enrich the expressiveness of the design space concept, we added continuous dimensions that represent either integer or real values. With such a dimension, it is e.g. possible to describe the number of semaphores offered by a runtime platform as an integer value. A design space in some sense represents a taxonomy for the variable aspects of systems in the target domain. A selection in the design space – a so-called design space profile – characterizes a concrete system along this taxonomy. threads lifecycle static dynamic

quantity bounded yes no -1

preemption yes no

synchronization mechanisms locks semaphors monitors ... -0,8

Figure 1. Excerpt from a Design Space describing run-time platforms. The four dimensions are related to the lifecycle model for threads, the question whether the number of threads is bounded and if preemption is supported, and the synchronization mechanisms offered.

Beyond the expressiveness of faceted classification schemes [12][14][18], design spaces allow to represent favorable and unfavorable combinations of design choices. To this end, correlations between categories or between categories and dimensions can be specified. A correlation is a relationship between two sets of categories or dimensions, as illustrated in figure 1. Both sides of a correlation are combined by either a boolean term or by a functional expression. We distinguish between weak and hard correlations: In weak correlations, the relationship between the two sides is expressed by a weighted factor on a continuous scale from -1 (choices must not be combined) to +1 (categories have to be chosen in combination). In hard correlations, the relationship is expressed by a boolean value representing a positively or negatively dependent decision; the assignment of one side of the correlation implies an assignment of the affected dimensions on the other side of the correlation. In the case of positively dependent decisions, the terms on both sides

have to be true; for negatively dependent decisions, only one of the terms may be true. Only hard correlations can be evaluated by tools, weak correlations can only be used to decribe hints for the decision of a developer. As will be shown in the subsequent section, correlations allow to represent in a semi-formal way knowledge about the domain and about possible solutions. Design spaces can be used to describe several aspects like requirements, design decisions or properties of components. In order to separate the different aspects, a design space may be partitioned into subspaces, e.g. the set of possible requirements is expressed in the so-called requirements subspace. Correlations within this subspace express consistency constraints describing possible combinations of requirements, or combinations that are not favorable in one system. Correlations between different subspaces can be interpreted as design guidelines expressing, e.g., component configurations in a component subspace which are needed to meet certain requirements. Based upon our initial experiences, we have made some further extensions in order to ease the handling of design spaces. For example, it is now possible to define groups of related dimensions. Hierarchies allow selections in one dimension to hide or to disclose other dimensions, and finally, sequences express a preferred order in which selections in a design space should be made. Depending on the described kind of artifacts, design spaces may reach considerable size. For example, in our case studies, we have used between 40 and 80 dimensions with roughly the same number of correlations to describe multimedia servers, building automation systems, and run-time platforms. To take full advantage of the design space technique in the context of domain modeling, tool support is indispensable. On the one hand, the considerable size of design spaces calls for tools to provide context sensitive views on the profiles and to guide the developer along sequences of dimensions. On the other hand, correlations can favorably be evaluated by tools, thereby laying the basis for an automated processing of the represented knowledge. To this end, we have developed two interactive tools. The so-called Designer supports the development of design spaces in terms of dimensions, categories and correlations. Regarding correlations, the full expressiveness of the extended design spaces concept is provided to ease the efficient description of dependencies. The concepts of groups, hierarchies and sequences can further be applied to structure the information included in an design space in an intuitive manner. While the Designer is rather used in the domain engineering phase, the so-called Configurator is intended to support the interactive creation of design space profiles and to automatically evaluate correlations. The Configurator uses the structuring mechanisms like subspaces, groups, or hierarchies to present the relevant parts of the design space in dependence of the current profile and the current


state of the development process. It furthermore provides the possibility to automatically select values in dimensions by evaluating correlations.

Figure 2. The Configurator (top window) in this example is used to customize the QNX operating system along our QNX Design Space. The Designer (background window) allows to define and modify design spaces.

4. Domain modeling using design spaces In this section, we will demonstrate how the concept of design spaces can be deployed for domain modeling, and how this can be brought together with our – also design space-based – approach to build tailor-made embedded operating systems as presented in [4] As described before, the concept of design spaces offers a facility for modeling in a semi-formal and coherent way sets of knowledge expressed in various alternatives and their interdependencies. In consequence, this approach can favorably be applied in the course of the description of domain models and their application within individual development projects. In our approach, the variabilities of the domain are described in the respective requirements space, which expresses the range of – both functional and non-functional – requirements for applications in this domain, as opposed to solution strategies and structures. The dimensions in the requirements space represent on an abstract level the principal criteria for the variability in this domain. The respective alternatives are either represented as categories within discrete dimensions, or defined as intervals in continuous dimensions. Dependencies between the identified variable requirements are expressed during the domain engineering process with correlations. The correlation type thereby defines the type of knowledge: hard correlations represent dependencies between requirements resp. variants which must be considered while creating an application profile, weak correlations specify assumptions, heuristic knowledge or domain expertise. The design space correlations are used to ensure consistency of the requirements statement: violation of correlations may indicate potential flaws or contradiction in an application’s profile, or it

may suggest that the application does not fit well into the given domain model. Hard correlations moreover facilitate the execution of the requirements analysis for individual applications by restricting the set of acceptable alternatives in one dimension based upon the previous characterization along other dimensions. In order to keep the evolving design space manageable and to ease the profiling of individual applications, the structuring concepts provided by the design space concept can be applied favorably. Groups can be used to cluster related dimensions, e.g. those dimensions referring to the networking functionality of an embedded operating system. Hierarchies are useful for reducing the number of actually relevant dimensions that have to be considered during profile creation. For instance the dimensions that deal with network issues are dependent on the dimension indicating whether network access is needed or not. A selection of ’No’ in this dimension makes the further consideration of the network-related dimensions unnecessary; they are therefore masked using a hierarchy. Sequences, the third structuring concept introduced above, can be applied to recommend a course through the identified dimensions, which is considered advantageous by domain experts. For example, in the above mentioned requirements space for embedded operating systems, it is sensible to first decide about the target platform of an application – network host, single host or embedded system – before reasoning whether network support is required, because the characterization along the latter dimension is facilitated by appropriate correlations. After characterizing the individual application in the requirements space for the considered domain, an appropriate architecture can be selected based upon this profile and a dedicated design subspace reflecting architectural decisions, the so-called architecture space. The requirements of the planned software system are mapped onto the architecture space. In turn, each of the available architectures has to be described both in the requirements and in the architectural space, in order to cover both domainrelated and solution-space aspects in the course of the selection. The selected architecture then provides a framework and an infrastructure for the integration of the individual components in a subsequent development activity. It moreover reflects a decomposition of the application’s variant requirements onto the comprised components. This expert knowledge in the solution space is essential for executing the mapping from the application’s requirements to adequate component configurations; it is captured in the form of hard correlations between dimensions in the requirements space and in the so-called component spaces associated with the component types identified by the architecture. The component spaces capture the variable requirements referring to a specific component type. For example, an architecture for the embedded operating systems domain identifies a ’scheduler’ component type that is represented by an appropriate component space. This sched-


uler component space comprises dimensions like the supported number of processes and the applied scheduling strategy, e.g. An application’s profile in a specific component space corresponds to a particular parameterization of the respective component. The above-mentioned correlations reflecting design or configuration rules are used to deduce such a profile from the application’s characterization in the requirements and architecture spaces. Subsequently, the component space profiles have to be transformed into actual values for the generic parameters of the components. To this end, there is a specific parameter mapping associated with each component, which allows to automatically generate the ready-to-use component based upon the given component space profile. A more detailed discussion of this mapping process is given in [4].

R D S 1: Type of th e s ys tem ? N etw o rk S ingle E m bedd ed H os t H os t S y s tem

R D S 2: N um ber of th re ads ? Inte ger >1

1

1

R D S 3: N etw o rk ac c ess required?

R D S 4: D o the threa ds inte ra ct?

Yes

Yes

No

No

1 G roup: N e tw ork

G roup: IP C

R D S 5: S u pport o f E th ern et ne tw ork a dapte r?

R D S 7: A re virtu al c irc uits req uired?

Yes

No

Yes

R D S 6: S u pport o f A rc net ne tw ork a dapte r? Yes

No

No

R D S 8: A re pro xies re quired ? Yes

No

CDS 1 = 3 * RDS2 CDS 1 = 2 * RDS2 CDS 1 = 1 * RDS2

C D S 1: N um ber of p ro ces s es? Inte ger

1

[1 .. 3276 7]

Legend H iera rc hy

C orrela tion

Figure 3. shows an excerpts from the design space used to configure QNX. The figure summarizes the basic features offered by the design space technique in order to map system requirements to generic components. The example is discussed in detail in the text.

In summary, the presented approach allows to completely automate the mapping from the application’s requirements to component parameterizations, using the application’s component space profiles as intermediary products.

5. Example from the embedded operating systems domain One of the domains we have modeled using the aforementioned method is the domain of embedded systems under consideration of the configuration options provided by the QNX operating system [15]. In figure 3, an excerpt of the developed design spaces is presented, comprising a few dimensions of the requirements (RDS) and component (CDS) design spaces. In the following, we explain the application of the above mentioned concepts for the representation of interdependencies between design decisions, and for the automatic transformation of requirements into component space profiles. In this design space, the decision whether network access is required or not is represented by the dimension RDS3. This dimension depends strongly on the actual choice of the target system's type represented in dimension RDS1. This dependency is expressed through two hard correlations between dimensions RDS1 and RDS3, stating that network access is required in a network system, but makes no sense in a single host system. On the other hand no general statement can be given if the target system is an embedded system; network access could be required or not. The dimensions RDS5 and RDS6 are part of a whole

group of dimensions concerning network issues. Since they are only needed when network support is required these dimensions are covered by a hierarchy, i.e., they are only accessible if the selection in dimension RDS3 is ’Yes’, otherwise they are masked out. In this case, about 30 dimensions with their respective correlations are hidden in the complete QNX design space, resulting in a significant reduction of the complexity. The decision in the ’network access required’ dimension - RDS3 - has yet another effect. If this decision is made to ’No’, no virtual circuits – a QNX specific IPC mechanism – are needed. This knowledge is represented by the hard correlation between RDS3 and RDS7. A more sophisticated kind of correlation can be seen on the right side of the picture. The functional correlation on this side calculates the number of processes – a parameter of the QNX process manager – dependent on the number of threads and the chosen IPC mechanisms. For instance, if it is intended to run 10 threads on the system and virtual circuits are needed as well as proxies, then the number of processes is set to 30. In this case, an actual value for the parameter ’Number of processes’ is deduced from the decisions made on more abstract levels. This example shows how the configuration knowledge embodied in design spaces can be exploited to support the transformation of high-level requirements into actual values of generic parameters.

6. Conclusions and further work In this paper, we present an approach for the automation


of component-based software development. A domain model is used as the starting point for the selection of reusable components and their configuration to the requirements of a specific application. To perform this mapping, knowledge about the decomposition of the requirements onto the reusable components is required. In our approach, we use design spaces to represent the domain model and the configuration knowledge. Using this technique, it is possible to automatically deduce the parameterization of generic components from an application’s requirements profile. The availability of configuration knowledge and the uniform representation of domain models, architectural knowledge and component properties thus allows to automate considerable parts of the component-based development process. This approach may can be compared to domain specific languages [6][19] which offer a related way to generate applications. One advantage of out approach is the possibility to develop a software family evolutionary, starting with the common parts and step for step integrate additional components which implement variant parts of the domain. So the new knowledge can be seemlessly integrated into the design space. Another advantage of the approach is the flexible mapping from requirements to solutions, so heuristic knowledge can be expressed in the design space, so the developer can decide the best solution for the given problem. One problem of a software family approach is the evolution of the domain resulting in changes in the domain model. In domain specific languages such changes may result in not trivial change of the language as well as the language compiler. The design spaces used in our approach are open to changes by adding new dimensions, categories and corresponding correlations, so the domain model may easily be adapted. As a consequence, the domains do not have to be as stable as for domain specific languages. It has to be mentioned though, that complete system generation always needs a stable domain to be economical feasible. One problem of design space is their complexity, which, however, was made tractable by providing appropriate tools for the creation, maintenance and deployment of design spaces. It remains to be examined, however, how changes in the modeled domain can be handled in a systematic way. Another topic for further work is the extension of the presented approach to guide the realization of component toolkits, including design spaces, architectures, and components.

7. References [1]

Baum, L.: Towards Generating Customized Run-time Platforms from Generic Components, Proc. of the 11th Conference on Advanced Information Systems Engineering (CAISE’99), 6th DC, Heidelberg, Germany, June 1999

[2]

Baum, L.; Becker, M.; Geyer, L.; Molter, G.; Sturm, P.: Driving the Composition of Run-time Platforms by Archi-

tectural Knowledge, Proc. of the 8th ACM SIGOPS European Workshop, Portugal, September 1998 [3]

Baum, L.; Geyer, L.; Molter, G.; Rothkugel, S.; Sturm, P.: Architecture-centric Software Development Based on Extended Design Spaces, Proc. of the 2nd ARES Workshop (Esprit 20477), Las Palmas de Gran Canaria, February 1998

[4]

Baum, L.; Becker, M.; Geyer, L.; Molter, G.: Mapping Requirements to Reusable Components using Design Spaces, Proc. of the IEEE Int'l Conference on Requirements Engineering (ICRE-2000), June 19-23 2000, Schaumburg/Chicago, USA

[5]

Biggerstaff, T.: The Library Scaling Problem and the Limits of Concrete Component Reuse, Proc. of IEEE Int’l Conference on Software Reuse, November 1994

[6]

Czarnecki, K; Eisenecker, U.: Components and Generative Programming, in Nierstrasz, O.; Lemoine M. (Eds.): Software Engineering - ESEC/FSE'99, LNCS 1687, Springer Verlag, 1999

[7]

Garlan, D.; Allen, R.; Ockerbloom, J.: Architectural Mismatch: Why Reuse is So Hard, IEEE Software, 12(6), 1995

[8]

Jacobson, I.; Griss, M.; Jonsson P.: Software Reuse Architecture, Process and Organization for Business Success, ACM Press/Addison-Wesley, 1997

[9]

Lane, T. G.: Guidance for User-Interface Architectures, in: Garlan. D., Shaw, M.: Software Architecture – Perspectives on an Emerging Discipline, Prentice Hall, 1996

[10] Lane, T. G.: Studying Software Architecture Through Design Spaces and Rules, Technical Report CMU/SEI-90TR-18, Carnegie Mellon Univ., 1990 [11] Nehmer, J.; Sturm, P.; Baentsch, M.; Baum, L.; Molter, G.; Rothkugel, S.: Customization of System Software for Large-scale Embedded Applications, Computer Communications Vol. 20, Elsevier, June 1997 [12] Ossher, H.; Tarr, P.: Multi-Dimensional Separation of Concerns using Hyperspaces, IBM Research Report 21452, April 1999 [13] Parnas, D.L.: On the Design and Development of Program Families, IEEE Transactions on Software Engineering, SE-2:1-9, March 1976 [14] Prieto-Diaz, R.: Classifying Software for Reusability, IEEE Software, January 1987 [15] QNX Software Systems Ltd.: QNX System Architecture, System Documentation, QNX Software Systems, Canada, 1993 [16] Sametinger, Johannes: Software Engineering with Reusable Components, Springer, 1997 [17] Schäfer, W.; Prieto-Diaz, R.; Matsumoto, M (eds.): Software Reusability, Ellis Horwood, New York, 1994 [18] Tarr, P.; Ossher, H.; Harrison, W.; Sutton, S. M.: N Degrees of Separation: Multi-Dimensional Separation of Concerns, Proc. of the Int’l Conference on Software Engineering (ICSE’99), May 1999 [19] Weiss, D.: Software Product-Line Engineering: A FamilyBased Software Development Process, Addison Wesley, 1999
