12  Download (0)

Full text







There are various phases in software project development. The various phases are: SRS, Design, Coding, Testing, Implementation, and Maintenance. During the design phase, UML class diagrams are constructed and the methods and programs are developed. The UML class diagram acts as a powerful tool between the developer and the user. It is like a contract where both parties agree for software development using UML class diagram. When a team of developers is designing a large application, which must be used by an enterprise, it is not enough to just put together a collection of code modules. The structure of an application is often known as its architecture, and the architecture must be defined in a way which allows the maintenance programmer, to easily find bugs and fix them. Because many bugs don't show up until long after the develop process, the programmer should be able to fix them quickly.

The developed project’s method signatures are stored in ontology and the project files are stored in Hadoop. To develop a new project, the developer search for components in the ontology and retrieve code from Hadoop. The ontology represents the knowledgebase of the company for the code reuse. The methods available in the UML class diagram is extracted and searched in the ontology and the matched methods can be retrieved from the Hadoop and used in the new project development. The method metadata are extracted from the UML and passed to the SPARQL to extract the available methods from the ontology. The developer can select appropriate method from the list and the corresponding code component is retrieved from the Hadoop. The main focus of the research is to find out the number of available methods for development and extracting them from Hadoop using UML class diagram.



This chapter begins with detailed features and process for method retriever in section 6.2 and the Keyword Extractor for UML in section 6.3. The Method Retriever by Jena framework is in section 6.4 and the Source Retriever from the HDFS is in section 6.5.


The total numbers of methods used in the project are transformed into a Method Ontology (MO). Method Retriever is a process that takes either UML class diagram or XMI file as an input mentioned by the user. Method Retriever identifies the reusable methods for the given class diagram. The Method Retriever consists of three components:

1. Keyword Extractor 2. Method Matcher 3. Source Retriever

The process of the Method Retriever process is presented in Figure 6.1. The Keyword Extractor for UML extracts the metadata from the UML class diagram. The class diagram created by Umberllo tool is passed as input to the Keyword Extractor. The input for the process is an existing UML class diagram or created by the tool. Both types of input are loaded in to Umberllo and the file type for storing UML class diagram is XMI format.

The file is parsed for metadata extraction. The parser extracts method signatures from the XMI file and passes it to the Method Matcher component. The Method Matcher component retrieves the matched methods from the method ontology. It constructs SPARQL query to retrieve the matched results. The user should select the appropriate method from the list of methods and retrieve the source code by Source Retriever component which interacts with HDFS and displays the source code.



Figure 6.1 - Process of Method Retriever for UML


To make sense of various approaches of an object oriented analysis and design, an Analysis and Design Task Force was established within the Object Management Group (OMG). By November 1997, a de jure standard was adopted by the OMG members called,

UML [72], [73] and [74]. UML 2.0 is the latest version of UML [75]. To create UML class diagram, Umberllo UML Modular open source tool is used. The diagram is stored in XMI format. The XMI is an OMG standard for exchanging metadata information using XML.

The process flow of Keyword Extractor for UML is shown in the Figure 6.2. The XMI or UML file is parsed with the help of the SAX Parser. SAX provides a mechanism



for reading data from an XML document. SAX loads the UML diagrams with the extension of .xmi files are used in the Method Extraction. Each diagram consists of Class, Operation, Field etc. It gets the attribute value of the tags by attributes.getValue(<Name of the attributes>) method. The retrieved attributes by the methods are Parse, Attributes and getValue(nameOfAttribute). The Parse() method will parse the XMI file. The Attribute is to hold the attribute value. GetValue(nameOfAttibute) method returns class information,

Figure 6.2 - Process of Keyword Extractor for UML

method information and parameter information of the attribute. The XMI file consists of XML tags. To extract class information, method information and parameter information, they are identified with the appropriate tag as illustrated in Table 6.1. Using the tags the metadata of the UML or the XMI is extracted. The extracted metadata - class, methods, attributes etc., are passed to the Method Retriever component.



Method Matcher component interact with the OWL and returns the available methods for the given class diagram. This is represented diagrammatically in Figure 6.3. The extracted information from the UML file by the Keyword Extractor for UML is passed to the Method Retriever.

Table 6.1 - Tags used to extract Metadata from XMI file

Tag Purpose

UML:DataType It holds the data type information

UML:Class It holds the class information like name of the class, visibility of the class ,etc.,

UML:Attribute Attribute is a sub tag of class. It holds the information of the class attributes like name of the attributes, type of the attributes, and visibility of the attributes etc.,

UML:Operation It holds the methods information of the class like name of the methods, return type of the methods, visibility of the methods.

UML:BehavioralFeature.parameter It holds the information of the methods parameters like name of the parameter, data type of the parameter.

Query answering is important in the context of the Semantic Web, since it provides a mechanism via, which users and applications can interact with ontology and data. Several query languages have been designed for this purpose, including RDQL, SeRQL and, most recently, SPARQL.


91 6.4.1" Query Processor

A query processor executes the SPARQL Query and retrieves the matched results. The SPARQL Query Language for RDF [76] and the SPARQL Protocol for RDF [77] are increasingly used as a standardized query API for providing access to datasets on the public Web and within enterprise settings. The SPARQL query takes method parameters and returns the results. The retrieved results contains project details like name of the project, version of the project and method details like name of the package, name of the class, method name, method return type, method parameter. Query processer takes the extracted method name and the method parameter as an input and retrieves the methods and project information from the OWL. The steps followed to extract the matched methods are as follows:

 Load the Ontology model.

 Create a SPARQL Query to retrieve method details from the OWL. This SPARQL Query filters the details based on the given method name. Create Query using the create(String query) static method of QueryFactory.

 Execute the query and obtain the result using the create(query, model) static method of QueryExecutionFactory. Get the ResultSet from the QueryExecution. From the ResultSet get the QuerySolution.

 This QuerySolution will contain a row of record. Using this query solution the user gets the value of each query variable. These query variables appear in the SPARQL with prefix of question mark (eg. ?projectName). So the user gets the value of projectName by row.get(“projectName”).toString(). This will return the name of the project. Similarly pass all the query variables and get the result.

6.4.2 SPARQL Query

The SPARQL query is constructed to extract the project name, version, package name, class name, method name, return type, return identifier name, method parameter name and type. The sample query is as follows:



Figure 6.3 – Process of Method Matcher for UML

PREFIX rdf:<>

SELECT ?pname ?version ?packname ?cname ?mname ?rType ?identifier ?paramName ?parmDT ?paramT


?project rdf:type base:Project .

?project base:Name ?pname .

?project base:Project_Version ?version .

?project base:hasPackage ?pack . ?pack base:Name ?packname .


93 ?class base:Name ?cname .

?class base:hasMethod ?subject .

?subject base:Name ?mname .

?subject base:Returns ?rType.

?subject base:Identifier ?identifier.

?subject base:hasParameter ?parameter.

?parameter base:Name ?paramName.

?parameter base:DataType ?parmDT.

?parameter base:DataType ?parmT. FILTER regex ( ?mname , "add" , "i" ) .

FILTER regex ( ?parmT , "java.lang.String" , "i" ) . }


Source Retriever component retrieves the appropriate source code from HDFS. The source code file location of the Hadoop repository path is obtained from the OWL and retrieved from the HDFS by the copyToLocal(FromFilepath,localFilePath) method.

In order to retrieve the source code from Hadoop process, it must be started at background. Only then the user is allowed to retrieve the source code. The user selects the methods for viewing code from the Hadoop. The parameters associated with the methods such as project name, version, package name, class name, and Method Name are passed as input to the Hadoop process.

Hadoop file system lists the available data in the given path. The data can be a file or a directory itself. If it is a directory, again list the available data in the path. If not, get the file name from the listed path using getName() method of the Path. This will return the name of the file. If the class name from the metadata matches the name of the java file, open the file path using Hadoop file system and create instance for BufferedReader.



In Hadoop repository files are organized in the same hierarchy of java folder. This BufferedReader instance holds the entire content of the file. The above is a recursive operation. So when the recursive operation gets over, The BufferedReader instance will have the content of the file. Create a new instance of the JavaDocBuilder of the Qdox library. Then add the created BufferedReader instance as resource to the JavaDocBuilder. List all the methods from the JavaDocBuilder instance using getMethods(). Search through the listed methods with the method name. If a method matches with method in the meta data get the source code of the method using getSourceCode() .

The entire process is illustrated in Table 6.2. The sample output of the matched methods is listed in Table 6.3. From the list the appropriate method will be selected and the QDox retrieves the source code from the HDFS and displays the method definition of the selected methods. It is shown in the output of the Source Retriever Table 6.2.

This chapter presented a process to extract the method code components from the ontology using the UML class diagram. With this sample process flow of the UML method matching, the chapter argued that it is indeed possible to extract code from ontology using the UML class diagram. The method ontology for the source code has already been created and this chapter searched and extracted thecode and components and reuses to shorten the software development life cycle. Before starting the coding phase of the development, the framework helps the software development team, to access the possibilities of how much code can be reused and how much code need to be developed.



Table 6.2 - Process flow of the UML Method Matching

Process Input


UML Extraction

Given Class Diagram Name : validateLogin Return : Boolean visibility : public Parameters : User Name DataType : username Method Retriever validateLogin(String userName) Refer Table 5.3 Source Retriever validateLogin(String userName)

boolean returnStatus = false;

DatabaseOperation databaseOperation = new DatabaseOperation();

String strQuery = "SELECT * FROM login WHERE uname='"+userId+"'"; ResultSet resultSet = databaseOperation.selectFromDatabase(st rQuery); try { while({ returnStatus = true; } } catch (SQLException e) { e.printStackTrace(); } return returnStatus;



Table 6.3 – Method Matcher Output

Sl. No.



Project Name : CBR_1.0

Package : Class Name : Login


Name : ValidateLogin Parameters : UserName Return Type : boolean


Project Name : RBR_1.0

Package : Class Name : LoginManger


Name : LoginLog

Parameters : UserName,ActivityCode Return Type : boolean


Name : LoginContol

Parameters : UserName,password Return Type : boolean


Project Name : BHR_1.0



Class Name : ControlManager Method

Name : ManageLogin

Parameters : UserName,password,memberId,ActionId Return Type : boolean


Name : ValidateLogin

Parameters : UserName,password Return Type : boolean