Modelling the Application Domains of Software Engineering Technologies Andreas Birk Fraunhofer Institute for Experimental Software Engineering Sauerwiesen 6, D-67661 Kaiserslautern, Germany email:
[email protected]
2. Conceptual Basis
Abstract The effectiveness of software engineering technologies depends very much on the situation in which they are applied. In order to further improve software development practices we need to explicitly describe and utilise our knowledge about application domains of software engineering technologies. This paper suggests a modelling formalism for supporting systematic reuse of software engineering technologies during planning of software projects and improvement programmes.
1. Introduction Software management seeks for decision support to identify technologies that meet best the goals and characteristics of a software project or improvement programme. Accessible experiences and repositories that effectively guide that technology selection are still lacking. The work reported in this paper aims at supporting reuse of software engineering technologies through explicit models of their application domains. Targeted result is a repository of best practice that packages technologies together with information about when they should be used. A modelling schema is presented for defining domain models of software engineering technologies. It integrates faceted classification [1] with the Goal/Question/Metric (GQM) paradigm for software engineering measurement [2]. It is expected to overcome present problems with reuse of software engineering technology by providing a means for well-structured, intuitive, and unambiguous description of application domains.
Aim of technology domain analysis is to describe the class of context situations (e.g., kinds of software projects) in which a software engineering technology can be applied successfully. Successful application of a technology (e.g., Fagan inspections) means that using the technology for a particular task (e.g., code verification) yields a desired goal (e.g., highly reliable software). It depends on the characteristics of the context situation (e.g., programming language, amount of reuse, experience of developers, etc.). This conceptual model is depicted in Figure 1.
3. Requirements A modelling schema for technology domain models should fulfil the following requirements: • Application domains should be described in intuitive terms that meet the language of project planners and experienced software professionals. • Application domains should be described unambiguously and operationally, such that every real situation can be classified in terms of the domain model. • Technology domain models should reference the technology, its application task, its goal, as well as the viewpoint and the overall environment for which the domain model has been derived. The modelling schema that is presented in the next section fulfils these requirements.
4. Technology Domain Models Task Technology
applied to achieve
Goal
impacts
Context Fig. 1: Conceptual model of software engineering technology application.
This section briefly introduces a schema for modelling application domains of software engineering technologies. A detailed explanation can be found in [3] and [4]. A technology domain model consists of four parts: header, intuitive domain model, operationalisation, and operational domain model (see Figure 2). The header relates the domain model to its technology, task, goal, viewpoint, and environment. It contains the index informa-
Procedings of the 1997 International Conference on Automated Software Engineering (ASE'97) (formerly: KBSE) 0-8186-7961-1/97 $10.00 © 1997 IEEE
tion when using the modelling schema in repositories of technologies and their application domains. The remaining parts of a technology domain model describe the application context (i.e., domain) of the technology. Intuitive and operational domain model have the form of faceted classification schemes [1]. They allow for a well-structured and intuitive knowledge representation. Each facet is represented by an intuitive or operational domain factor such as “Size of project”. Each domain factor is defined through a set of discrete possible values. A facet of a concrete domain is characterised through one or more actual values from the set of possible values. A domain factor together with its actual value(s) form a domain characteristic. The semantics of each domain factor are explicitly defined in natural language. The distinction between intuitive and operational domain model reflects the need for unambiguous definition of technology application domains. It follows the principles of GQM [2]. The intuitive domain model describes the domain using terms from the language of software professionals. The operationalisation translates the intuitive domain model into an operational domain model. The operational domain model refers to real-world phenomena that can effectively be determined and measured for every context situation. The operationalisation maps each domain factor of the intuitive domain model to one or more domain factors of the operational domain model. There are three kinds of mappings: Direct operationalisation is to be used for intuitive domain factors that can already be determined unambiguously for every real context situation. Functional operationalisation is to be used for intuitive domain factors that should be decomposed into one or more elementary domain factors using a numerical or logical function. Vague operationalisation is to be used for intuitive domain factors for which the relation to operational domain factors can be defined most appropriately in terms of linguistic variables using fuzzy sets. See Figure 2 for examples.
5. Discussion and Conclusion Related work is currently performed at University of Nebraska-Lincoln by Scott Henninger and at University of Maryland by Carolyn Seaman, Victor Basili, and others. Henninger’s approach aims at capturing experiences on technology usage and domains using a case-based repository [5]. At University of Maryland domain information [6] is elicited through empirical techniques. Objective is to identify similarities between software development units that allow for the systematic transfer of experiences. The presented approach is expected to overcome some of the present difficulties with reuse of software engineering technologies. First empirical evaluation is currently
being conducted. Tool support is being developed for gaining technology domain models through knowledge acquisition, and for using them with multiple-attribute decision making [7] when selecting technologies for software projects and improvement programmes [4].
6. Acknowledgements The author thanks Klaus-Dieter Althoff, Dietmar Pfahl, and Carsten Tautz for the fruitful discussions on the reported work. This work has been partly supported by the CEC through ESPRIT project no. 23239, “Profes”.
7. References [1] R. Prieto-Diaz and P. Freeman. Classifying software for reusability. IEEE Software, 4(1):6–16, January 1987. [2] L. Briand, C. Differding, and D. Rombach. Practical guidelines for measurement-based process improvement. Software Process Improvement and Practice Journal, Vol(2) Issue 3, 1997. [3] A. Birk. Modelling the application domains of software engineering technologies. Technical Report IESE 014.97/E, Fraunhofer IESE, Kaiserslautern, Germany, 1997. [4] A. Birk. Domain analysis of software engineering technologies. http://www.iese.fhg.de/home/birk/tda.html. [5] S. Henninger, Accelerating the successful reuse of problem solving knowledge through the domain lifecycle. Fourth International Conference on Software Reuse, Orlando, FL, 1996. [6] V. Basili, L. Briand, and W. Thomas. Domain analysis for the reuse of software development experiences. 19th Software Engineering Workshop, Greenbelt, MD, December, 1994. [7] M. Molloghasemi, J. Pet-Edwards. Making multiple-objective decisions. IEEE Computer Society Press, Washington, DC, 1997. Technology Domain Model Header Technology: Fagan inspections Task: Code verification Goal: High reliability of software product Viewpoint: Quality assurance manager Environment: New Software Solutions Inc.
Domain Factor
Intuitive Domain Model Programming Amount Experience Size language of reuse of developers of project low small (1-site) Fortran < 10% C average large (1-site) < 40% Java high multi-site < 70% Smalltalk ≥ 70% Operationalisation Direct Operationalisation
Functional Operationalisation
ld
A = ( R / T ) x 100
Operational Domain Model Programming Total number Number of language of modules reused mod. Fortran {Positive {Positive C cardinal cardinal Java value} value} Smalltalk
Domain Characteristic Actual Value
... Possible Values
Vague Operationalisation
...
y
Years of experience {Positive cardinal value}
...
Fig. 2: Structure of technology domain models.
Procedings of the 1997 International Conference on Automated Software Engineering (ASE'97) (formerly: KBSE) 0-8186-7961-1/97 $10.00 © 1997 IEEE
