Defining and Building Domain-Oriented Software Development ...

Defining and Building Domain-Oriented Software Development Environments Káthia Oliveira1,2, Cátia Galotta1,3, Ana Regina Rocha1, Guilherme Travassos1,4, Crediné Menezes5 1

2

COPPE / Computer Science Department – Federal University of Rio de Janeiro Caixa Postal 68511 – Cep 21945-970 - Rio de Janeiro - RJ – Brazil Phone/Fax: 0055 21 5902552

Unit of Cardiology and Cardiovascular Surgery/Fundação Bahiana de Cardiologia– Brazil 3

4

5

IPqM – Brazilian Navy Research Institute – Brazil

ESEG/CS - University of Maryland at College Park – USA

UFES – Computer Science Department - Federal University of Espírito Santo – Brazil e-mail: {kathia, cgalotta, darocha, ght}@cos.ufrj.br

Abstract Developing software is a complex and time-consuming task. It is even more difficult when the software team is not familiar with the problem domain. The use of domain knowledge during software development can render this process easier and increase productivity. To address this problem, we defined the concept of Domain-Oriented Software Development Environment (DOSDE). Using the domain-knowledge embedded into it, DOSDE guides the software developers through the several phases of the software development process. Two features are essential in a DOSDE: having the domain-knowledge explicitly defined and using this knowledge to facilitate the software development. To apply this in real situations we defined two DOSDEs: &25',6, a DOSDE for cardiology, and 1(7812, a DOSDE for acoustic propagation. Key-words: domain oriented software development environments, ontology, domain theory, software development environments, CASE tools.

1. Introduction Software teams have hard times to develop software when they are not familiar with the problem domain. The most critical activity is probably the correct identification and description of what the software system must accomplish (requirements). We realized this while developing software during the last years for two different domains: cardiology, in a joint project with the Cardiology and Cardiovascular Surgery Unit of the Federal University of Bahia (UCCV/FBC), Brazil, and acoustic propagation for the Research Institute of Brazilian Navy. These experiences showed us that the crucial problem for software development in these domains is the lack of domain knowledge by the software team. Moreover, domain experts consider the process of knowledge acquisition and requirement elicitation boring and stressful in particular, because they need to explain basic concepts of the domain to the computer science personnel for each new software development project. This problem is made worse by the high turnover of the software teams, common in projects. It is also important to recognize that the quality of software development and the productivity of the software team can be improved by the use of a Software Development Environment (SDE). An SDE is a computational system that provides support for the construction, management and maintenance of software products. It automates a software development process that disciplines and organizes software development, making it easier to control software construction. Based on these two aspects – the need to understand the domain and the importance of an SDE – we propose to use domain-knowledge in an SDE to support the developers to build systems in non-familiar domains. We call this new class of Software Development Environments: Domain-Oriented Software Development Environment (DOSDE) [1]. A DOSDE uses the domain-knowledge to guide the software developers through the several phases of the software development process. This environment makes knowledge available about the domain in a symbolic representation by using domain ontologies. Specific domain activities, domainspecific tools and generic tools customized for the domain introduced into the software development environment allows for the usage of this knowledge during the software development process. To apply these ideas in real situations, we have defined and constructed two DOSDE: &25',6, a DOSDE for cardiology and, 1(7812, a DOSDE for acoustic propagation. In the following sections we present the definition and features of DOSDE. In section 2, we consider domain-knowledge, how it is defined and used in the software development. Based on these definitions, we describe, in section 3, the requirements and the infrastructure on top of which a DOSDE is built. In those sections we show examples from cardiology and acoustic propagation domains. Finally, we present some conclusions and future research directions.

2. Domain Theory and Ontologies Using domain-knowledge in software development is not an easy task. It is difficult to define exactly which knowledge is necessary and to do so considering only the domain itself, not the specific applications.

Looking at the current knowledge engineering research, we have identified that the best way to describe and organize this knowledge is to use domain ontologies. Ontology [2] is an explicit specification of a conceptualization, that is to say, an explicit specification of the objects, concepts and other entities that are assumed to exist in some area of interest and the relationships that hold among them. Basically, an ontology consists of concepts and relations, their definitions, properties and constraints expressed by axioms. Domain ontologies [3] express conceptualizations that are specific for particular domains. They place constraints on the structure and contents of domain knowledge. Working with ontologies has several benefits [3]. They can promote sharability of knowledge bases, knowledge organisation, interoperability among systems and facilitate the communication between experts and the knowledge engineers during the software development, since it establishes a common vocabulary and a semantic interpretation of terms. Domain ontology is the basis of the domain model, named Domain Theory, which will be used in a DOSDE. A domain theory uses a domain ontology and contains an identification of tasks mapped with the domain knowledge defined. These tasks represent activities that take place in specific domains, such as diagnosis, interpretation, etc. They are domain-independent (for example, there is diagnosis of diseases and diagnosis of machine failures) but are important to specify each software application, so this is useful for the understanding of what should be done and, therefore, for the software development. The first step to define the domain theory consists in defining the domain ontology. For this step we used a methodology which considers the following phases [4]: the definition of the purpose of the ontology, its conceptualization, formalization (or coding) and, finally, validation. In our case, the purpose for ontology to be defined is to help in software development. This means it should cover the main concepts of the domain, help to understand the domain and be useful in software development. Conceptualization is the longest phase and requires the definition of the concepts of the domain, a good description for each one, the minimum attributes that characterize the concepts, possible domain values and constraints. To make this activity more manageable and the domain model well organized, we have defined that a Domain Theory should be divided in sub-theories. Each sub-theory has a group of domain concepts and relations among them (i.e, the domain ontology) that have the same semantic context. The sub-theories between themselves have relations to compose the whole domain. Therefore, in the conceptualization phase it is important to define the scope of the domain theory and the sub-theories that characterize the domain. After that, each concept is defined and introduced in the right subtheory. Finally, the ontology is validated and formalized in the environment. The second step in the definition of the domain theory is the identification of the main tasks (i.e. activities) of the domain and their mapping with the sub-theories. It can be difficult to identify all possible tasks, but we consider important to consider, at least, the more typical ones. Figure 1 shows the domain theory for cardiology and figure 2 the domain theory for acoustic propagation.

Diagnosis Sub-Theory

Heart Anatomy Sub-Theory Anatomy

Physiology

Theraphy Sub-Theory

has

Diagnosis

has function

Theraphy

Syndromic

Anatomy Component

Clinic

Ethiologic

refers to

Pathology Sub-Theory

orinates in Myocardium

Artery

Vein

Valve

Interventionist

causes

Septum Cardiac condution system

Pathogenesis

Pathology manifests Evidence

Findings Sub-Theory

Test

Clinical Situation

Demography Data

Symptom

Visual Sign

Pulse

Abdomem

Tactile Sign

Edema

Sign

Past History

Auscultatory sign

Cardiac

Habitual Sound

Olfative Sign

Personal History

Invasive Test Family History

Non-invasive Test Eletric Ultrasound-based Radiation Signal-based test based test test

Laboratory test

Extra Habitual Sound

Figure 1- Concepts of Sub-theories for Cardiology

Sub-theory of Propagation Theory

Models

Subtheory of Acoustic Environment

SONAR

SOUND

emits/detects

LIQUID SURROUNDING

propagates through

Caustic Active Sonar

Emitted Sound

Passive Sonar

Transducing Element

Hydrophone

Sound Generated by the Sonar

Received Sound

Own Noise

Echo Excess

Shadow Zone

Layer

Noise

Mixed Layer

Seasonal Main Thermocline Thermocline

detects

Sea Life

Deep Isothermal Layer

influences

Surrounding Noise

Machines

Helix

Dome

Duct

Irradiated Noise Deep Sound Channel

Surface Duct Hydrodynamic

Convergence Zone

Towed Sonar

TARGET

Internal Duct

BOUNDARY

Surface

Solar Heating

Wind

Botton

Sea State

Composition

Sub-Bottom

Batimetria Composition

Figure 2 - Concepts and Sub-Theories for Acoustic Propagation

3. Domain Oriented Software Development Environments Domain-Oriented Software Development Environment (DOSDE) is an SDE that supports the development of software systems in a specific domain considering the embedded knowledge of this domain to guide the software developers across the several phases of the software development process [1]. A DOSDE, like any other SDE, should have a repository that stores all the information related to the software project throughout its life cycle and a set of tools to support the technical and managerial activities involved. This new class of SDE requires two essential features: (a) having domain-knowledge and, (b) using this knowledge during the software development. To address these features, we have first defined the Domain Theory, described in the previous section, as a domain model that contains the knowledge to assist the software developers. Feature (b) implies that we need to create a specific activity in the software process that considers the study of the domain in the software process. To allow for its use during the software development (feature b), a specific DOSDE should meet the following requirements: (i) support domain investigation during software development using some adequate level of formalism; (ii) allow user (software developer) interaction with the problem domain; (iii) support the identification, access and use of domain-knowledge objects that are important for the activity to be done; and, (iv) support cooperative work between the domain experts (or users) and software developers as used in the environment the domain vocabulary defined in the theory. To construct the infrastructure for DOSDE we used the frameworks provided by TABA [5], a meta-environment developed at COPPE/UFRJ allowing for the creation (i.e. instantiation) of diverse SDE according to the requirements of different technologies. TABA allows software engineers to describe software development processes, methods, and build CASE tools needed by software developers to carry out the automated activities of the software development process. These elements are captured by TABA’s Instantiated Environment Model. To instantiate a DOSDE, that is, to allow for the creation of an SDE that considers the domain theory, a number of new requirements were included to TABA [5], such as: (i) assist in the definition of a domain theory; (ii) allow for building tools using this theory and to use them in the software development; (iii) allow the description of tasks; and, (iv) support the evolution of the domain theory as long as it is being used in software development and in new DOSDEs instantiated for the same particular domain. A Domain Theory editor was included in TABA to support requirement (i). This editor introduces the knowledge in TABA according to the architecture defined for knowledge servers [6]. To support feature (ii), we first create specific knowledge servers through the definition of a domain theory making available the domain knowledge in the environment. Then, we define a specific sub-activity, named domain investigation, to establish the use of the domain knowledge defined for a specific DOSDE. This activity is introduced in all software processes defined for a DOSDE. The descriptions of tasks (requirement (iii)) in this version is done by storing documents describing the purpose of the task, the main points that should be considered by the developers and references for the specific literature. For the last requirement (iv), we should consider the instantiation of the domain theory and the inclusion of new concepts. The instantiation will be supported by specific tools using the domain theory. The evolution of the

concepts of the domain theory is still an open question in our research. We are considering that this activity will be done manually by software developers, and that it consists only of inclusion of new concepts but not of changes in those already defined. In this way, the software applications already built will keep their integrity. With this extension, it is possible to introduce a Domain Theory, integrate the domainspecific tools to be used in each software development phase and, therefore, build a DOSDE for an specific domain. The instantiation of a DOSDE according TABA's infrastructure is based on the definition of a domain theory and a software process. The domain theory of figure 1 was used to define &25',6, a DOSDE for Cardiology to be used at UCCV/FBC and the domain theory of figure 2 to instantiate 1(7812, a DOSDE for acoustic propagation to be used at the Brazilian Navy Research Institute (IPqM). The software processes used to instantiate those DOSDE were defined taking into account the international standard of software process (ISO/IEC 12207 [7]), the introduction of domain orientation in the software process and several software practices already in use in the organization (such as test with real cases and prototyping used in UCCV/FBC and contract definition and mathematics research used at IPqM). For each organization, we have defined a standard process, which describes the fundamental elements expected to be incorporated into any defined process of the organization [8]. Using the standard process, several software processes may be specialized considering the features of each kind of software (such as knowledge-based systems, object-oriented systems, etc.). In each specialization, the activities are organized according to a life cycle model suitable to that kind of software. The activities of the standard process are refined into more detailed ones, and new activities may be introduced. Methods, techniques and tools are also defined for each activity. To be used in a specific software project, the suitable specialized software process is instantiated to fit the particularities of the project such as complexity, size, schedule, and expected service life of the product. Figure 3 summarizes this approach and shows its several steps from the definition of the standard software processes to the specific ones that will be effectively used for a project. After the definition of the domain theory and the software process, the next step is to build a DOSDE is to integrate domain specific tools. These tools may be specifically developed for a DOSDE or customized for the domain from generic tools. These tools differ from more classical ones because they use the vocabulary of the domain or domain-specific information about the domain. We built, for instance, for &25',6, a specific knowledge editor to assist in the knowledge acquisition process considering the cardiology domain: KED, a Knowledge EDitor for cardiology specific for the diagnosis task. The tool inquires information about cases to the cardiologist considering the concepts of the domain theory. The cardiologists provide justification for the diagnosis of each case. These justifications are simple diagnostic associations, which are generalized by the toll as long as the cardiologists introduce new associations. In the end, the software developers find available some general rules for the diagnosis of specific pathology to use in future interviews for knowledge acquisition.

definition

ISO, organization activities and domain activity

Kind of software, life cycle, methods, tools

Standard SP

specialization

Specialized SP

Specialized SP

...

Specialized SP-

instantiation Particularities for the project

SP – Project 1

SP – Project 1

...

SP – Project 1

Figure 3: Domain-Oriented Software Process Another tool developed for &25',6 was 48$/&25',6 defined to assist in the quality requirements elicitation48$/&25',6 considers ISO 9126 [9], specific quality attributes for medical software and uses fuzzy logic to deal with the uncertainty of this process. In this way quality attributes are enhanced considering the differences in the opinion of cardiologists, nurses, administration staff and computer science personnel. For 1(7812, a specific browser for the Domain Theory of acoustic propagation was developed. With this tool the software developer can learn about the domain by looking for concepts, their relations, where they are used and which kind of tasks can consider them. This browser is integrated in the environment and is used in the domain investigation activity defined in the software process.

4. Conclusion Not understanding the problem domain is a recurring problem for the software developers. We argue that productivity is strongly influenced by the extent to which the designers know the domain and, therefore, software development environments will be more effective if they take domain knowledge into account. Based on this idea, we have proposed DOSDEs – DomainOriented Software Development Environments – considering the infrastructure of a metaenvironment commonly used by our group. In this paper, we present the definition and construction of DOSDE for two domains: cardiology and acoustic propagation. Those two experiences are the first step to attest the validity of these ideas. Now we are working in the definition and construction of new tools to be integrated into a specific DOSDE, such as tools to assist in the software modeling activity, and to assist in the software product evaluation, according to specific software quality attributes.

Acknowledgments We thank Dr. Alvaro Rabelo, Dr. Antonio Ximenes, Professors Crediné Menezes, Stan Matwin and Ricardo Falbo for their valuable contributions to this work. We also acknowledge CNPq, the

financial support from Brazilian Government for this project, and CAPES, Brazil partially support for Prof. Guilherme H. Travassos while visiting the ESEG at UMCP.

References [1] K.Oliveira, A.R. Rocha, G.H.Travassos, C.S.Menezes: Using Domain-Knowledge in Software Development Environment for Cardiology; Proceedings of the eleventh Conference on Software engineering and Knowledge Engineering, pp. 180-186, Kaiserslautern, Germany, June 1999. [2] T.R. Gruber: Toward Principles for the Design of Ontologies used for Knowledge Sharing; International Journal Human-Computer Studies, 43: 907-928, 1995. [3] M.Uschold, M. Gruninger: Ontologies: principles, method and applications; The Knowledge Engineering Review, 11(2):93-136, 1996. [4] A.Gómez-Pérez, M. Fernandez, A.J. Vicente: Toward a Method to Conceptualize Domain Ontologies; Proceedings of Workshop on Ontological Engineering/ECAI; Budapest, Hungary, August 1996. [5] A.R. Rocha, T.C. Aguiar, J.M. Souza. Taba: A Heuristic Workstation for Software development. Proceedings of COMPEURO, Tel Aviv, Israel, May 1990. [6] R.Falbo, C.Menezes, A.R. Rocha: Using Knowledge Servers to Promote Knowledge Integration in Software Engineering Environments; Proceedings of the eleventh Conference on Software engineering and Knowledge Engineering, pp. 170-174, Kaiserslautern, Germany, June 1999. [7] ISO/IEC 12207: Information technology - Software Life Cycle Processes, International Standard Organization, 1995. [8] K. E Emam, J. Drouin, W. Melo: SPICE – The Theory and Practice of Software Process Improvement and Capability Determination; IEEE Computer Society Press, 1998. [9] ISO/IEC 9126: Information Technology Software Product Evaluation Quality Characteristics and Guidelines, 1991.