Detector de problemas de diseño sobre el código fuente de un Ser-

Web

El detector es la parte encargada de identificar y advertir al desarrollador sobre posibles problemas en la interfaz del Servicio Web que pueden producir anti-patrones. A con- tinuación se describen los métodos de detección que utiliza la herramienta y las refac- torizaciones que propone a los desarrolladores para cada uno de los anti-patrones, cuya definición fue explicada en la Sección 2.4.

• Comentarios faltantes o inapropiados: para detectar la presencia de este problema es necesario analizar el código fuente de la interfaz y determinar si existe algún

Anti-patrón Origen Etapa Comentarios faltantes o

inapropiados

(1)El desarrollador no introduce comentarios o son inapropiados en los métodos de una interfaz Java. (2)La

herramienta de generación no tiene en cuenta los comentarios presentes en el código fuente de la interfaz

Java al crear el documento WSDL.

(1)Diseño de interfaz y (2)Generación automática de WSDL

Nombres ambiguos (1)El desarrollador asigna nombres ambiguos a métodos o parámetros de una interfaz Java. (2)La herramienta de generación asigna nombres ambiguos a los parámetros por no poder recuperar sus nombres originales a partir

delbytecodede la interfaz Java.

(1)Diseño de interfaz y (2)Generación automática de WSDL

Port–types redundantes La herramienta genera más de un port–type para una misma interfaz Java, típicamente uno por cada

protocolo de transporte soportado.

Generación automática de WSDL

Operaciones poco cohesivas

El desarrollador crea métodos no relacionados entre si en una interfaz Java.

Diseño de interfaz

Modelo de datos adjunto

La herramienta incluye las definiciones de los tipos de datos dentro del documento WSDL generado.

Generación automática de WSDL Modelo de datos

redundante

La herramienta genera definiciones duplicadas para un mismo tipo de dato.

Generación automática de WSDL Tipos de datos

comodines

(1)El desarrollador utiliza tipos de datos genéricos en los parámetros o valores retornados por los métodos de

una interfaz Java. (2)La herramienta asigna tipos de datos genéricos o tipos comodines a los mensajes de

entrada o salida de una operación.

(1)Diseño de interfaz y (2)Generación automática de WSDL Información de error encubierta en mensaje estándar

El desarrollador crea métodos que incluyen información de error en los datos retornados.

Diseño de interfaz

método que no ha sido comentado o cuyo comentario no es coherente con el nom- bre que se le ha asignado. Comprobar la primera condición es trivial, pero no ocurre lo mismo con la segunda. Para evaluar la coherencia entre los comentarios de un método y su nombre se utiliza una heurística propuesta en [27] que permite medir el grado de similitud semántica entre dos frases. Esta heurística puede tomar val- ores entre 0 y 1 e indica en qué medida dos frases se refieren a los mismos conceptos. La comprobación realizada para determinar la coherencia de los comentarios de un método consiste en calcular el grado de similitud semántica entre los comentarios y el nombre asignado al método. Si el grado de similitud es menor a un determinado valor se considera que el comentario no es apropiado para el método analizado, dado que se refieren a conceptos diferentes.

– Refactorización: para impedir la ocurrencia de este anti-patrón en el docu- mento WSDL, la herramienta sugiere al desarrollador agregar un comentario descriptivo a todos aquellos métodos donde falten los mismos y reemplazar los comentarios existentes por otros más adecuados en todos aquellos métodos cuyos comentarios hayan sido detectados como inapropiados.

• Nombres ambiguos: para detectar la presencia de este problema se realizan distin- tas comprobaciones. La primera es en base a su longitud dado que si un nombre tiene sólo un carácter o es muy largo es considerado ambiguo. La segunda com- probación que se realiza es determinar si alguna de las palabras que componen el nombre forman parte de una lista de palabras consideradas como no explicativas o demasiado generales [7] y son:param, arg, var, obj, object, foo, input, output, in, out, str, entre otras. Si un nombre de método o parámetro contiene al menos una de las pal- abras listadas previamente es considerado ambiguo. Por último, se comprueba que los nombres tengan una estructura gramatical adecuada. En el caso de nombres de métodos se verifica que la estructura sea verbo + sustantivo porque represen- tan acciones sobre entidades. En cambio, para los nombres de los parámetros se verifica que sea algún tipo de sustantivo, puesto que representan entidades. Para analizar la estructura gramatical de los nombres de métodos y parámetros se uti- liza unparserde gramática libre de contexto probabilístico [22]. Este tipo deparsers

permiten analizar una sentencia y asociarla con reglas que forman uno o más ár- boles de parsing donde cada regla tiene una probabilidad independiente. Esto hace posible calcular el árbol de parsing más probable de una sentencia, multiplicando las probabilidades de todas las reglas de cada árbol de parsing derivado. La heurís- tica para analizar el nombre de un parámetro consiste en comprobar si el árbol de parsing derivado por elparsertiene al menos un sustantivo en alguno de sus no- dos. Si esta condición no se cumple se considera que el nombre del parámetro es ambiguo. Para analizar los nombres de los métodos, la heurística añade "it must"

(debe) al comienzo del mismo para darle forma de oración imperativa y mejorar el análisis gramatical que realiza elparser. Dado que los nombres de métodos suelen comenzar con un verbo en infinitivo, elparserpuede tener dificultades para recono- cer la estructura de la frase y detectar como sustantivos los verbos al comienzo de la misma. Nuevamente, agregar "it must" al comienzo de la oración aumenta las probabilidades de que el parser detecte la primera palabra del nombre del método como un verbo en lugar de sustantivo. Posteriormente, la heurística examina los nodos del árbol de parsing y comprueba que existan al menos un verbo y un sus- tantivo. Si esta condición no se cumple se considera que el nombre del método es ambiguo.

– Refactorización: para evitar que este anti-patrón se presente en el documento WSDL, la herramienta sugiere al desarrollador reemplazar los nombres de métodos y parámetros detectados como ambiguos por nombres más adecua- dos. En el caso de los métodos, se recomienda que los nombres contengan al menos un verbo y un sustantivo, que denoten la acción llevada a cabo. Para los nombres de los parámetros se sugiere utilizar sustantivos o frases sustantivas, que representen sujetos, objetos o conceptos.

• Operaciones poco cohesivas: para detectar la presencia de este problema se analiza la cohesión particular de cada método de la interfaz, en lugar de la cohesión de la interfaz como un todo. Se utiliza una heurística basada en técnicas presentadas en [5, 8], que utiliza grafos para modelar las relaciones entre los distintos métodos de una interfaz y determinar el grado de cohesión entre los mismos. Básicamente se crea un grafo no dirigido cuyos nodos pueden representar métodos, tipos de datos intercambiados o sustantivos presentes en los nombres de métodos, y sus arcos representan las relaciones existentes entre ellos. A partir del grafo de relaciones construido se puede determinar el grado de relación que existe entre dos métodos en términos de los tipos de datos que utilizan en común y los conceptos a los que se refieren. De esta forma, si dos o más métodos utilizan el mismo tipo de dato, ya sea en sus parámetros o como tipo de retorno, habrá un camino entre ambos en el grafo, dado que los nodos que representan dichos métodos estarán conectados a través del nodo del tipo de dato en común. Por otro lado, si dos o más métodos contienen en sus nombres referencias al mismo concepto también habrá un camino que los una en el grafo puesto que estarán conectados a través del nodo del concepto al que hacen referencia. La heurística propuesta consiste en detectar si el grafo generado es un grafo conexo. En caso contrario, se calcula la cantidad de métodos de todos los sub-grafos conexos que existen en el grafo de relaciones y se toma como el más representativo de la interfaz aquel que conecta la mayor cantidad de métodos. Para determinar cuáles son los métodos no cohesivos basta con verificar cuáles no se

encuentran presentes en dicho sub-grafo.

– Refactorización: para prevenir la ocurrencia de este anti-patrón en el docu- mento WSDL, la herramienta sugiere al desarrollador incluir los métodos con- siderados poco cohesivos por la heurística en interfaces que provean una fun- cionalidad con conceptos más relacionados.

• Tipos de datos comodines: para detectar la presencia de este problema se examinan los métodos de la interfaz del servicio en busca de tipos de parámetros o tipos de retorno genéricos [1]. Los tipos de datos considerados genéricos son:Object, Vector, List, Map, Collection, Enumeration, Vector<Object>, List<Object>, Map<Object,Object>, Collection<Object> y Enumeration<Object>.

– Refactorización: para evitar los problemas que puede ocasionar este anti-patrón en los documentos WSDL, la herramienta sugiere al desarrollador reemplazar los tipos de parámetros o de retorno que hayan sido detectados como genéri- cos por tipos de datos más específicos, que representen adecuadamente los objetos o tipos de datos intercambiados por el servicio.

• Información de error encubierta en mensaje estándar: para detectar la presencia de este problema se analizan los tipos de retorno de los métodos definidos en la inter- faz que materializa el servicio para determinar si permiten transportar información de error. Esta comprobación sólo se realiza sobre los tipos de retorno no primitivos y consiste en examinar los nombres de sus atributos para determinar si alguno de ellos indica que puede transportar información de error. Si el tipo de retorno de un método contiene un atributo cuyo nombre pertenece a la siguiente lista: ping, error, errors, fault, faults, fail, fails, exception, exceptions, overflow, mistake, misplay, se considera que dicho tipo permite transportar información de error.

– Refactorización: para evitar este anti-patrón, la herramienta sugiere al desar- rollador convertir todos aquellos tipos de retorno que hayan sido detectados como transportadores de información de error encubierta en excepciones ar- rojadas por dichos métodos.