Regresar

Engineering the ontology for the SWEBOK: Issues and techniques

Abstract:

Auyang [2] described engineering as "the science of production". This and many other definitions of engineering put an emphasis on disciplined artifact creation as the essence of any engineering discipline. However, the material object produced by every engineering discipline is not necessarily of a similar nature. The case of software engineering is particularly relevant in the illustration of such differences, since software as an artifact is acknowledged as a very special piece of human work. The special nature of software was attributed by Brooks [7] to "complexity" as an essential characteristic. The following quote from Brooks paper illustrates the presupposed impact of complexity in the activities of engineering: Many of the classic problems of developing software products derive from this essential complexity and its nonlinear increases with size. From the complexity comes the difficulty of communication among team members, which leads to product flaws, cost overruns, and schedule delays. From the complexity comes the difficulty of enumerating, much less understanding, all the possible states of the program, and from that comes the unreliability. From complexity of function comes the difficulty of invoking function, which makes programs hard to use. From complexity of structure comes the difficulty of extending programs to new functions without creating side effects. From complexity of structure come the unvisualized states that constitute security trapdoors. The term "essential" (as opposed to "accidental") is a well-known tool for ontology engineers [17], which helps in determining the properties of concepts that objects possess "always and in every possible world". The position of Brooks on the essentials of the object of the discipline leads to a particular conception of software engineering as a human endeavour that attempts to tackle an inherently complex problem, since it takes as a point of departure the fact that complexity is a feature that cannot be removed from the engineering process. Consequently, it is difficult to consider methods that are definitive for the production of software, and the field is expected to change as methodologies are introduced and applied in an attempt to manage, to the extent possible, the complexity of the activities. This has a consequence on research and enquiry, since the qualities of a tool or method to tackle software complexity are difficult to assess, and this in turn leads to a plurality of approaches. Such diversity leads to difficulties in contrasting the appropriateness of techniques in terms of rational enquiry methods such as those established by Popper [12] in his method for scientific discovery. Empirical research on proposed software methods, processes, tools and techniques are of course fundamental to the discipline. In addition, ontology engineering is also important from our viewpoint for the evolution of the discipline of software engineering, at least in two dimensions. On the one hand, ontology may help in the organization and meta-analysis of empirical data and empirical approaches [6], facilitating an adequate comparison and evaluation of methods, techniques or tools. On the other hand, ontologies translated into machine-understandable representations may help in the development of computerized tools that, to some extent, take into account the purpose and consequences of the diverse software engineering activities. Even though we do not see ontologies as the "silver bullet" of every software production problem, they are promising tools to help in the work of researchers and practitioners, and they would also serve as an element of analysis and discussion for engineers and for learning about the discipline Consensus-reaching approaches to ontology engineering are deemed as appropriate for the crafting of representations of the concepts of some concrete domains. Nonetheless, in some domains the engineer can find pre-existing processes of consensus-reaching on conceptual frameworks. This is the case of software engineering, in which the SWEBOK project [1, 8] is the result of a considerable effort on the collaborative production of a subset of the knowledge of the discipline that is as of today subject to little controversy in the community of researchers. In addition to the collaborative effort, which will be briefly described next, the project adopts a literature- based approach [14] in selecting some relevant articles. Thus, the SWEBOK guide provides a ground of rationality and consensus that constitutes a valuable input for ontology engineering. The chapter by Ruiz and Hilera in this volume provides an overview of current approaches to the ontology of software engineering, some of them based on the SWEBOK. This chapter now concentrates on the specifics of two approaches to SWEBOK-based ontological enquiry that are complementary in their objectives and methods. The rest of this chapter is structured as follows. Section 3.2 provides an account of the SWEBOK as a project, its main principles and its method from creation to revision. Then, Sect. 3.3 describes some results of a process of enquiry on SWEBOK-based ontology from the viewpoint of the experimental study of the process of rational argument and consensusreaching by software engineers. Later on, Sect. 3.4 provides the complementary view of producing ontological representations linked to commonsense knowledge bases, analysing the benefits of reuse of existing ontological engineering and of being prepared for the construction of ontologybased tools. On the basis of the experiences described in Sects. 3.3 and 3.4, Sect. 3.5 sketches the main ontological elements distilled. © 2006 Springer-Verlag Berlin Heidelberg.