Knowledge-based Support to Process Integration in ODE

Process integration in Software Engineering Environments (SEE) is very important to allow tool integration. In this paper, we present a knowledge-based approach to improve process integration in ODE, an ontology-based SEE.

Integration -of tools, processes, artifacts, and views -has been considered one of the most challenging issues on software engineering environment (SEE) research [6].Integration demands consistent representations of software engineering information, standardized interfaces between tools, homogeneous means of communication between software engineers and tools, and an effective approach that enables SEE to move among various platforms [5].
The identification of the need for integrated support to software engineering activities throughout the software lifecycle represents the genesis of Software Engineering Environments (SEEs) [6].Thus, SEEs can be defined as integrated collections of tools that facilitate software engineering activities across the software lifecycle [6].A SEE provides a means of integrating people in a software development organization with the software process and with the supporting technology [7].To do that, SEEs must provide an infrastructure for tool integration that should address [3] [1]: • Data Integration: addresses the way tools share data.A SEE must provide data management services, allowing tools to share project and software engineering information.
• Presentation Integration: concerns commonality of user interface.The user interfaces in a SEE must be homogeneous and consistent, allowing developers to alternate between the tools without substantial style changes, and therefore, with less impact on productivity and learnability.
• Control Integration: relates to the ability of a tool to notify and initiate actions in another tool, controlling the events that might occur and sharing functionalities.
• Process Integration: concerns the linkage between the tools and the software development process.To integrate tools, it is necessary to have a strong focus on the software process management.The process must define the tools a developer can use, and when he/she will have access to these tools, according to the activities of the process he/she is performing.
• Platform Integration: relates to the independency of the platform on which the environment and their tools will run.
• Knowledge Integration: refers to the establishment of the semantics of the information exchanged be tween the various tools in a SEE.With the growing complexity of software processes, it becomes necessary to offer knowledge-based support to help software engineers in their tasks and to manage the knowledge captured during the software projects.In this way, knowledge, as well as data, has to be available to the environment in order to be shared among their tools.
The need for (semi-)automated support for the software process, in addition to tool support for artifact development, gave rise to a new class of SEEs, called Process-centered Software Engineering Environments (PSEEs), which integrate tool support for software artifact development with support for the modeling and execution of the software processes that produce those artifacts [6].The explicit representation of software processes, their products, and their interactions, is the foundation over which modern integrated development environments are built.In providing more powerful ways of describing and implementing software engineering processes, PSEEs have also provided a powerful means of integrating processes and tools, and (partially) automating tasks [6].In general, a PSEE should include mechanisms to [7]: (i) guide sequences of activities that compose the defined process; (ii) manage products that are being developed; (iii) invoke tools that developers require to do their tasks; (iv) perform automatic actions that do not need human intervention; (v) allow communication between the persons who are developing the project; (vi) gather metric data automatically; (vii) reduce human errors and (viii) provide project management with current accurate status information.[4] is a Process-centered SEE, developed using ontologies.ODE's design premise is based on the following argument: if the tools in a SEE are built based on ontologies, tool integration can be improved.The same ontology can be used for building different tools supporting correlated software engineering activities.Moreover, if the ontologies are integrated, integration of tools built upon them can be facilitated.This is the main feature that distinguishes ODE from other SEEs: its ontological basis.Especially in SEEs, ontologies can be used to reduce terminological and conceptual confusions, facilitating shared understanding and communication between people with different needs and points of view.Besides the standardization of concepts provided by it, an ontology allows a refined communication between the tools that compound the environment [4].

ODE ( Ontology-based software Development Environment)
Among the ontologies on which ODE is based, one must be highlighted in the context of this work: the software process ontology [1].This ontology defines the main concepts related to software process and is the basis for process integration in ODE.ODE's architecture reflects its ontological basis.It has two levels: the Base Level and the Meta-Level, as shown in figure1.The base level defines the classes that control the processes defined in the environment (the Control package) and their tools .The meta -level (or knowledge level) defines classes that describe knowledge about objects in the base level.Because of that, these classes are named prefixed by the character "K", as will be seen in section 4.

Base Level
The classes in the meta-level are directly derived from the ontologies and its objects can be viewed as items of an ontology instantiation [4].These instances constitute the environment's knowledge, which can be used by their tools.In the case of the software process ontology, instances of knowledge classes describe knowledge about software processes, its activities, artifacts produced and consumed, resources and procedures (methods, techniques and guidelines), among others.
However, an ontology does not intend to describe all the knowledge involved in a domain, but only that one that is essential to conceptualize the domain (minimal ontological commitment [8]).Therefore, new classes, associations, attributes and operations have to be defined to deal with specific design decisions made in the application level.In fact, the ontology is a general, common sense model, and then it does not contain all necessary modeling elements to treat applications' requirements.
The cla sses in the base level are also built based on the ontologies.The main classes and associations are derived from the ontology, preserving the same constraints as Knowledge's model.To deal with software processes, for example, the classes of the Control package were developed.They are used for defining and tracking software processes for projects developed in ODE.Some of these classes have a corresponding class at the meta-level.This way, the meta-level is used to describe base-level objects' characteristics in the Control package (see section 4).

ODE's Inference Layer
In general, conventional systems that aim to represent knowledge, including object-oriented systems, keep their knowledge stored in a data repository, from where it can be consulted, and the rules related with this knowledge are embedded into the application code, turning impossible to take advantage of the whole potential that the knowledge-based technology can provide.
A first step towards a more effective approach to deal with knowledge is to choose a more suitable form of representation.Among the several forms of representing knowledge, there is the logical paradigm approach, where facts are stored and accessed from a data repository, and the rules are isolated from the application.Keeping rules isolated of the application is a flexible way to maintain the knowledge without the complete restructuring of applications.The result of its use is a more robust system, with a flexible knowledge base that can grow and change as the business evolves [9].Besides, the use of artificial intelligence techniques enables to improve the manipulation of these rules, allowing inferences.
If a SEE is able to deal with knowledge about projects, processes, activities, resources, methods and tools, it can offer intelligent support to managers and developers, by guiding, monitoring and aiding the use of tools during the software development.Therefore, in the ODE's context, an infrastructure was developed to support knowledge integration.This infrastructure has a layer responsible for combining objects and logic, the Inference Layer, endowing the SEE with the capability to represent knowledge through rules, and to perform inferences.Using the inference layer, knowledge can be captured from the environment's repository, represented in knowledge bases using a logical language (Prolog), and can be treated through an inference mechanism.
When introducing a logical language in an object-oriented environment, it is possible to take advantage of the benefits of a second paradigm.Situations as the ones that involve recursivity or working with many relationships between objects, demanding pattern matches or several accesses to objects' information, are likely to be treated by the logical paradigm.Those kinds of situations are quite common, especially in operations involving knowledge.

How the Inference Layer works
One of the goals of the Inference Layer is to make available in ODE a way of representing knowledge logically, using Knowledge Bases (KBs).The purpose is to express, through facts and rules, information that can be extracted from the environment, as, for example, data about past projects.
The logical representation of rules can bring advantages, because rules can be modified without the need to change or recompile the system.Taylor [10] says that keeping rules embedded in code works in small systems, but it does not scale up well and it requires reprogramming every time a rule changes.He also says that the harder task of rule manipulation is ma ke rules easy for business people to understand and use.This can be reached through friendly interfaces.Systems that combine objects and rules with graphical user interfaces become more robust, more understandable, and easier to maintain [9].
The Inference Layer must provide the knowledge engineer with a simple way to create and to manipulate KBs.For such, an editor of Knowledge Bases Structures was developed.In this editor, predicators and rules can be defined.Those structures are used as a framework for instantiating KBs.In KB instantiation, facts are defined from predicators (defined in the knowledge base structure) and data extracted from the environment, and the rules are those defined in the knowledge base structure.Starting from an instantiated KB, it is possible to manipulate its knowledge through a Prolog inference engine [11] incorporated into the layer.project(oid500).activity_name(oid511, 'Planning').activity_name(oid516, 'Quality Planning').activity_name(oid517, 'Risks Analysis').subAtividade(oid511, oid516).subAtividade(oid511, oid517).... subActiv(B,A) : -subActivity(A,B).subActiv(B,A) : -subActivity(A,X), subActiv(B ,X).

Editing Knowledge Base Structures
The Knowledge Base Structures Editor allows to create and to maintain KB structures.Since a KB is formed by a collection of facts and rules, a KB structure has to have the necessary elements to create the facts and rules.The KB structures should not have facts, but just its structure.Therefore, predicators and rules compose them.Predicators are symbols that make statements using terms.Each predicator has an arity associated to it, which indicates the number of terms required for creating the statement.Through the predicators, the simplest statements are created: the atomic statements, called predicates.A predicate containing variables as terms is an open predicate.If all the terms are constants, the predicate is called a closed predicate or a fact [12].Rules are modeled as a conjunction of conditions plus a conclusion.The conditions and conclusion of the rules are represented by predicates [12].
Figure 3 shows the Logical Model package that models the concepts of first order logic according to the OO paradigm.This is the internal representation of knowledge base structures and knowledge bases in ODE.

Figure 3. Internal Structure of the Inference Layer -Class Diagram of the Logical Model Package
The first step to create a KB structure is to define its predicators.Starting from the ODE's package hierarchy, this can be done by using computational reflection to obtain information about classes and methods of the various packages that compound the environment.Two types of predicators can be created: ClassPredicator, to represent classes, and MethodPredicator, to represent the attributes and associations of classes, defined through their corresponding accessing methods.Those predicators store, besides their name s and arities, information about their origin (class or method and class) that is useful to instantiate a KB. Figure 4 shows some predicators being defined starting from the ODE's package hierarchy.

Figure 4. Predicators Definition
Once the predicators have been defined, rules can then be defined.A rule always owns one conclusion and, at least, one condition, represented by open predicates.Conditions are created from existing predicators and their associated terms (constants or variables), giving rise to predicates.A condition can be negated or not and its number of terms is determined by the arity of the predicator.A conclusion is created using a RulePredicator and associated terms, compounding an open predicate.Rule predicators are not created during predicator definition, but only when the rule heads (conclusions) are defined.Figure 5 illustrates the definition of rules using the previously defined predicators.

Executing Inferences
Creating KB structures (i.e., defining their predicators and rules), and instantiating them in KBs are steps that must occur previously to the inference execution.When the Inference Layer has an instantiated KB, it is able to attend to its main purpose: to perform logical inferences on knowledge, using a Prolog engine.A query can be done in two distinct ways, depending on the type of the predicator used: • Facts: since all terms in the query are constants, then the result indicates whether the fact is true or false; • OpenPredicate: since it has a variable as a term, the query result is a list containing the variable possible values.
In both cases, what the Inference Layer does is to transform the objects in logical data and then perform the inference on the Prolog file generated during the KB instantiation, using a Prolog engine.The result of the inference is transformed into objects and returned to the application.
The inferences can be executed in two modes: via graphical interface and via code.The first is simpler and used through a graphical application, in which the user mounts the desired queries and obtains the inference results only visually.The main goal of this functionality is to allow testing the KB structures defined and the KBs created, performing inferences in order to check coherence of the defined predicates and rules.Thus, the Knowledge Engineer can check a KB before it is effectively used in a system.Besides, this approach facilitates users to learn how the inference layer works, so they can use the second mode of inference (via code) better.
As shown in figure 7, the user defines the queries by choosing the corresponding elements needed to mount an open predicate or a fact.Initially, a predicator should be selected and its terms determined.After that, the inference is executed, and the results are presented in the frame on the right.It should be notice that business objects are shown as Strings between brackets.

Figure 7. Inference Execution via Interface
The second mode to use inferences is accomplished via implemented code.Even keeping rules isolated, the systems need to access them to work.The intention is to make the environment obtain results through rules of a KB.Working like this, operations purely codified can be replaced by calls to a KB, with the advantage that the rules involved in those operations, because they are interpreted, can be easily changed, without need to recompile the system.It is important to emphasize that the system continues to operate with objects, obtained, now, through a different paradigm.
To perform inferences via code, the KnowledgeBase class provides two methods for query: one for facts and another for open predicates.For both methods, the name of the inference predicator and its terms should be passed as arguments.The constant terms are application objects and the variable terms are instances of the class Variable.
Figure 8 shows a fragment of code used to perform an operation via logical inference, which the result is a list of objects.As it can be observed, what should be done to perform the operations is to infer on a KB, passing the predicator name and an array of objects as terms.Internally, the KB searches for the predicator and creates the terms using the objects passed as arguments.Then the predicate is mounted to perform the inference and the result is treated and returned.

PROCESS INTEGRATION IN ODE
Since ODE is a process centered SEE, process integration is essential to it.ODE's process kernel was built using the software process ontology presented in [1] as its foundation.This ontology was designed to support software process definition, tracking and integration in a PSEE.Every tool compromised with this ontology shares a common vocabulary, facilitating the communication between tools and allowing reuse.
To deal with software processes, first the environment should support their definition.The process definition, in turn, is used to establish an explicit connection between the environment's tools and the defined processes.In the next subsections, important features of the process integration in ODE are discussed, including process definition and process control, establishing the connection with the tools that automate it.

Process Definition in ODE
Software process definition is a hard and knowledge intensive task.To do that, project managers must have a high level of experience and knowledge.Several aspects should be considered, such as the development team characteristics, project specific features, and organization's knowledge level in software engineering.
ODE uses a three-level approach to process definition [13], as shown in Figure 9.Each level has different features that influence the processes definition in it.At the higher level, the standard process of the organization is defined.The organizational process contains the process assets (activity, artifacts, resources and procedures) that should be part of the processes of any organization's project.At the intermediate level, the standard process can b e specialized to consider development technologies, paradigms or specific application domains.During the specialization, process assets can be added or modified, in agreement with the context of the specialization (technology, paradigm or application domain).Finally, in the lowest level of the process definition model, it is the instantiation of a standard process or a specialized process for a specific project.The process instantiation consists in tailoring a standard or specialized process for a specific project.In this adaptation, particularities of the project and development team characteristics should be considered.At this moment, the life cycle model to be used during the development is defined, and new activities, as well as consumed and produced artifacts, used resources and adopted procedures, can be added to the process.The different levels of process definition occur in the different levels of ODE's architecture (presented in the figure 1).The standard and specialized processes describe the activities (and the others process assets) that should belong to all the organization's project processes.In other words, those processes describe the knowledge regarding the processes of that organization.This way, according to ODE's architecture, standard and specialized processes are defined in the Meta-Level, i.e., in the Knowledge Package, shown in Figure 10.
Once the life cycle models for a standard or specialized process has been defined, these can be used in the project process instantiation.It should be emphasized that, unlike standard and specialized processes definition that occurs in the Meta-Level of ODE's architecture, the project process definition occurs in the base level, more specifically in the Control Package, shown partially in Figure 11.The class Process represents project processes, defined for specific software projects (represented by the class Project).A project process can be defined based on a standard or specialized process, or it can be defined starting from the knowledge repository of the environment.Therefore, a Process can have, or not, an association with KStandardProcess.When a project process is defined starting from a standard or specialized process, all their assets are replied for the new process, in agreement with the standard/specialized process and the life cycle model chosen.At that moment, the activities of the process are created as well as its associations with the corresponding artifacts (KArtifact), resources (KResource) and procedures (KProcedure).The interface for standard, specialized or project process definition is similar and it is presented in Figure 12.The tree located on the left part of the window contains the process assets already defined for the process in definition (activities, artifacts, resources and procedures).On the right part, a panel makes possible to choose the process assets for the selected item in the tree.In this panel, the right list contains the elements already defined for the process.The left list contains the assets suggested by inferences performed in the knowledge base using the Inference Layer of the environment.The knowledge bases, previously defined by the Knowledge Manager based on the Knowledge package, are instantiated in the initialization of the tool.They are used through inferences to give suggestions for the project manager who is defining the process, offering knowledge based support to him/her.
Defining subactivities for a certain activity is an example of the use of inferences in the tool.The process definition tool should suggest, in a first moment, only the subactivities associated to an activity, as defined in the Knowledge package model.However, a more elaborated form of suggestion is given based on the subactivities rule shown in Figure 13.According to that rule, the subactivities of the subactivities are also exhibited, in agreement with the transitivity imposed by the rule, turning more effective the support to the process definition.

Figure 13. Some Used Rules
In a similar way, the resource rule (also shown in Figure 13) provides more effective suggestions for resource allocation.As shown in the code fragment of the Figure 14, the use of that rule allows an activity allocate resources that were defined for their subactivities.As shown in Figure 12, the Planning activity can allocate a risks management tool even if Planning doe not have Risk Analysis as one of its subactivities in the process that is being defined.Although in the Knowledge model the risks management tool is associated only to the Risk Analysis activity, that allocation becomes possible.This is a consequence of the performed inference using the resource rule (Figure 13) and of the fact that the Knowledge model defines Risk Analysis as a potential subactivity of Planning.

Process Control in ODE
Once the project process is defined and the project initiated, the environment should support project controlling and tracking.This control includes various functionalities such as managing the states of the activities and controlling the access to the software tools in the environment, allowing the execution of the process activities.
During the definition of a project process, the types of necessary resource for accomplishing an activity are defined.For instance, a Software Engineer (instance of the class KHumanResource) can be assigned to execute the activity of Requirement Analysis.Only in a second moment, during resource allocation, a person is allocated, for instance, Maria (an instance of the class HumanResource of the Control package), that naturally should exercise Software Engineer's function.In a similar way, software tools are allocated to activities.For instance, once defined the need for a Modeling Tool to execute the activity of Requirements Analysis, there should be chosen which modeling tool available in the organization will really be used to support this activity.
Based on the process activities, and human resources and software tools allocated to them, the environment is able to configure itself according to the user logged on.In other words, starting from the identification of the human resource that is using the environment, the functionalities are made available in a personalized way, according to the user profile and the resource allocation to projects.
The availability of the tools of the environment is defined based on the project resource allocation and the states of the activities.In a project, a human resource should have access only to the necessary tools to perform his/her activities.Therefore, only those tools allocated to the activities to which the user is also allocated are shown in the menu.In addition, the activities should be in execution.Figure 15 shows this self configuration feature of ODE.It shows ODE's main interface when a Project Manager is logged on the environment.In the tool menu, there are links for tools that support allocation of tools, quality planning (ControlQ), risks analysis, documentation, etc.Those tools constitute the whole set of tools that the user can access, considering the active activities of the process (Planning) to which he/she is allocated.The selection of tools that will be shown in ODE's tools menu is performed using the configuration knowledge base of the environment, which holds the use rule, shown in the figure 16, where ido1_131 represents the state "In Execution".
% The human resource HR can access the software tool ST if both are allocated to the same activity X and the state of X is In Execution.access(HR,SF) :-humanResource(HR), softwareTool(ST), allocate(X,HR), allocate(X,ST), activity_state(X, oid1_131).

Figure 16. Rule of the Configuration Knowledge Base
In that way, when a user logs on the environment, the tool menu is dynamically configured as a result of inferences using the method shown in the figure 17.In this case, the Inference Layer is also supporting process integration in ODE, allowing the configuration of ODE's tool menu.This approach makes integration easier, more efficient and more flexible, since the used rule can be easily changed.

Figure 17. Code Fragment of the Environment Configuration
Suppose that another approach for menu configuration is considered better.In this approach, the user might have access to all the tools allocated to activities to which he/she is allocated, independently of the state of the activity.Therefore, the user could access tools allocated to future activities and he/she can review his/her work using tools allocated to activities already finished.This change in the operation mode of the environment is fully supported by the Inference Layer, without rewriting ODE's code.In this case, the Knowledge Manager should only modify the use rule, removing its last condition and, later, instantiating the knowledge base again.In this way, it is not necessary to change or to recompile the code of the environment.

RELATED WORK
TABA Workstation [14] is a meta-environment that generates software engineering environments suitable to specific projects, based on the software processes defined.As ODE, TABA Workstation has tools that support process definition and management.Process integration in TABA is considered when, from a defined process, a SEE is instantiated according to the process assets.Like TABA, ODE supports process definition and management; however, the environment configures itself dynamically from human resource and tool allocation to the current project's process activities.It is worthwhile to point out that ODE is a configurable environment, while TABA is a meta-environment.Thus, ODE supports access to several projects in the same session, while the TABA's instantiated environments are project specific.
Prolog is also used in TABA to represent knowledge modules [1,15].It is used to formalize knowledge descriptions, transcribing ontology's axioms for a logical representation.TABA's and ODE's approaches are quite similar as to encapsulation and communication with Prolog engine.However, the concept of Knowledge Base Structures does not exist in TABA, neither supporting for rule edition, letting this task for the knowledge engineer do directly in Prolog.Furthermore, there is no functionality to support checking the edited knowledge bases.
Charon tool [15] provides support for software process modeling, simulation, execution and management.In this tool, facts are represented in knowledge bases and rules are incorporated into intelligent agents.An inference engine is used for the agents do queries and modifications in the knowledge bases.Thus, the facts are determined by the application and the modification of the rules consists in modification or inclusion of agents.There is no flexible way for maintaining facts or rules by the user.
Other process centered environments, such as EPOS [16] and Oz [17], use rules for modeling processes.However, the majority of these approaches use logic for software development specific purposes, like process modeling.They are not worried about providing an infrastructure to represent and manipulate knowledge bases in logic.In other words, such approaches do not provide automated support for editing predicates and rules, and generally, work with rules embedded in the application code.

CONCLUSIONS
This paper presented the knowledge-based approach for process integration in ODE, a processcentered environment.It presented ODE's tool supporting software process definition, as well as others knowledge-based functionalities for process control and environment configuration.
There is a strong connection between the tool of software process definition and the process ontology in which the environment is grounded.The use of inferences made possible to the tool to work in accordance with the ontology, respecting its relations and axioms.The situations discussed in the paper are part of a group of operations that approximate the tool to its conceptual model.Many times, performing those types of operations in the conventional way is extremely hard.H owever, the use of logical deductions made it possible to implement these operations in an easier way.This approach also focuses on the maintainability and extensibility of the environment.
The approach of leveled software process definition can lead to a continuous software process improvement based on the experience captured and projects' information that use the standard/specialized processes as basis.In this context, inferences can be used to support the retrieval and dissemination of historical data, obtained from previous projects, offering subsidies for a continuous process improvement.

Figure 2
Figure 2 illustrates the general operational scheme of the Inference Layer, and figure 3 shows its internal structure, which are detailed follow.

Figure 6 .
Figure 6.Example of a generated Prolog File.

Figure 12 .
Figure 12.Standard, Specialized and Project Process Definition.

/Figure 14 .
Figure 14.Code Example using the Inference Layer.

•
MethodPredicator: generates facts with arity 2 (two), which are logical representations of attributes and associations of the origin class.The facts are created in the form method_predicator(instance, method_return).So, a method predicator named activity_state, that represents an association between objects of the classes Activity and ActivityState, originates facts like activity_state([Requirements Analysis],[In Execution]), indicating that the activity Requirements Analysis is in the state In Execution.