ingeniera inversas_1

8/6/2019 ingeniera inversas_1

1/23

Gisweb - Reingeniera para la implementacin de un Web Feature Service

Captulo 4 Ingeniera Inversa 40

Captulo 4Ingeniera Inversa

[4. Ingeniera Inversa]

El anlisis de un sistema para identificar sus componentes actuales y las

dependencias que existen entre ellos, para extraer y crear abstracciones de dicho

sistema e informacin de su diseo[Chifofsky, 1990].

El proceso de analizar el cdigo, documentacin y comportamiento de un sistema

para identificar sus componentes actuales y sus dependencias para extraer y crear

una abstraccin del sistema e informacin de diseo. El sistema en estudio no es

alterado, sino que se produce conocimiento adicional acerca del sistema[SEI,

2004].

En este captulo se trata el proceso de ingeniera inversa, sus variantes, y la

realizacin de la misma sobre la implementacin particular de un WFS desarrollado

por una iniciativa privada para obtener una abstraccin que nos permita generar la

documentacin necesaria para hacer una implementacin propia de ese servicio.

Como se mencion en los alcances y limitaciones de esta tesis, el proceso de

ingeniera inversa es muy amplio y debido al tiempo para desarrollar esta tesis, toda

la informacin descrita en la seccin 4.2 es para comprender el proceso, ms no se

realizaron todas las etapas del mismo. La seccin 4.3 contiene el trabajo realizado de

ingeniera inversa sobre la implementacin particular del WFS que se estudi.

4.1 Ingeniera Inversa, un proceso de reingeniera

La ingeniera inversa tiene la misin de desentraar los misterios y secretos de los

sistemas en uso. Consiste principalmente en recuperar el diseo de una aplicacin a

partir del cdigo.


2/23



Esto se realiza principalmente mediante herramientas que extraen informacin de los

datos, procedimientos y arquitectura del sistema existente.

Es aplicable a sistemas con las siguientes caractersticas:

Documentacin inexistente o totalmente obsoleta. Programacin en bloque de cdigos muy grandes y/o sin estructurar. Inexistencia de documentacin interna en los programas, o bien sta es

incomprensible o est desfasada.

La aplicacin cubre gran parte de los requisitos y del rendimiento esperado. La aplicacin est sujeta a cambios frecuentes, que pueden afectar a parte

del diseo.

Se prev que la aplicacin pueda tener an larga vida.

La ingeniera inversa puede extraer informacin de diseo del cdigo fuente, pero el

nivel de abstraccin, la completitud de la documentacin, el grado con el cual

trabajan al mismo tiempo las herramientas y el analista humano, y la direccionalidad

del proceso son sumamente variables [Cass, 1988].

4.1.1 N ivel de abstraccin

El nivel de abstraccin de un proceso de ingeniera inversa y las herramientas que se

utilizan para realizarlo aluden a la sofisticacin de la informacin de diseo que se

puede extraer del cdigo fuente. El nivel de abstraccin ideal deber ser lo ms alto

posible, es decir, el proceso de ingeniera inversa debe ser capaz de derivar:

Sus representaciones de diseo de procedimiento (con un bajo nivel deabstraccin).

La informacin de las estructuras de datos y de programas (un nivel deabstraccin ligeramente ms elevado).

Modelos de flujo de datos y de control (un nivel de abstraccin relativamentealto)

Modelos de entidades y de relaciones (un elevado nivel de abstraccin).


3/23



A medida que crece el nivel de abstraccin se proporciona al ingeniero de software

informacin que le permitir comprender ms fcilmente estos programas

[Pressman, 2003].

4.1.2 Completitud

La completitud de un proceso de ingeniera inversa alude al nivel de detalle que se

proporciona en un determinado nivel de abstraccin. En la mayora de los casos, la

completitud decrece a medida que aumenta el nivel de abstraccin. Por ejemplo,

dado un listado del cdigo fuente, es relativamente sencillo desarrollar una

representacin de diseo de procedimientos completa. Tambin se pueden derivar

representaciones sencillas del flujo de datos, pero es mucho ms difcil desarrollar un

conjunto completo de diagramas de flujo de datos o un diagrama de transicin de

datos.

La completitud mejora en proporcin directa a la cantidad de anlisis efectuado por

la persona que est efectuando la ingeniera inversa [Pressman, 2003].

4.1.3 Interactividad

La interactividad alude al grado con el cual el ser humano se integra con las

herramientas automatizadas para crear un proceso de ingeniera inversa efectivo. En

la mayora de los casos, a medida que crece el nivel de abstraccin, la interactividad

deber incrementarse, o si no la completitud se ver reducida [Pressman, 2003].

4.1.4 Direccionalidad

Si la direccionalidad del proceso de ingeniera inversa es monodireccional, toda la

informacin extrada del cdigo fuente se proporcionar a la ingeniera del software

que podr entonces utilizarla durante la actividad de mantenimiento. Si la

direccionalidad es bidireccional, entonces la informacin se suministrar a una


4/23



herramienta de reingeniera que intentar reestructurar o regenerar el viejo

programa [Pressman, 2003].

4.1.5 El proceso de ingeniera inversa

El proceso de ingeniera se representa en la figura 4.1. Antes de que puedan

comenzar las actividades de ingeniera inversa, el cdigo fuente no estructurado

(sucio) se reestructura para que solamente contenga construcciones de

programacin estructurada1. Esto hace que el cdigo fuente sea ms fcil de leer, y

es lo que proporciona la base para todas las actividades subsiguiente de ingeniera

inversa.

Figura 4.1 El proceso de ingen iera inversa

1 El cdigo se puede reestructurar automticamente empleando un motor de reestructuracin, es decir, una

herramienta CASE que reestructura el cdigo fuente.


5/23



El ncleo de la ingeniera inversa es una actividad denominada extraccin de

abstracciones. El ingeniero tiene que evaluar el viejo programa y a partir del cdigo

fuente (que no suele estar documentado) tiene que extraer una especificacin

significativa del procesamiento que se realizar, la interfaz de usuario que se aplica ylas estructuras de datos de programa o de base de datos que se utiliza [Pressman,

2003].

Para el caso especfico de esta tesis, se analiz y se llevo a cabo la abstraccin para

comprender el procesamiento, por lo tanto, solo trataremos esa parte del proceso

de ingeniera inversa del software.

4.1.5.1 Ingeniera inversa para comprender el procesamiento

La primera actividad real de la ingeniera inversa comienza con un intento de

comprender y extraer despus abstracciones de procedimientos representadas por el

cdigo fuente. Para comprender las abstracciones de procedimientos, se analiza el

cdigo en distintos niveles de abstraccin: sistema, programa, componente,

configuracin y sentencia.

La funcionalidad general de todo el sistema de aplicaciones deber ser algo

perfectamente comprendido antes de que tenga lugar un trabajo de ingeniera

inversa ms detallado. Esto es lo que establece un contexto para un anlisis

posterior, y se proporciona ideas generales acerca de los problemas de

interoperabilidad entre aplicaciones dentro del sistema. Cada uno de los programas

de que consta el sistema de aplicaciones representar una abstraccin funcional con

un elevado nivel de detalle. Tambin se crear un diagrama de bloques como

representacin de la iteracin entre estas abstracciones funcionales. Cada uno de los

componentes efecta una sub-funcin, y representa una abstraccin definida deprocedimientos. En cada componente se crea una narrativa de procesamiento. En

algunas situaciones ya existen especificaciones de sistema, programa y componente.


6/23



Cuando ocurre tal cosa, se revisan las especificaciones para evaluar si se ajustan al

cdigo existente2.

Todo se complica cuando se considera el cdigo que reside en el interior del

componente. El ingeniero busca las secciones de cdigo que representan lasconfiguraciones genricas de procedimientos. En casi todos los componentes, existe

una seccin de cdigo que prepara los datos para su procesamiento (dentro del

componente), una seccin diferente de cdigo que efecta el procesamiento y otra

seccin de cdigo que prepara los resultados del procesamiento para exportarlos de

ese componente. En el interior de cada una de estas secciones, se encuentran

configuraciones ms pequeas.

Por ejemplo, suele producirse una verificacin de los datos y una comprobacin de

los lmites dentro de la seccin de cdigo que prepara los datos para su

procesamiento.

Para los sistemas grandes, la ingeniera inversa suele efectuarse mediante el uso de

un enfoque semi-automatizado. Las herramientas CASE se utilizan para analizar la

semntica del cdigo existente. La salida de este proceso se pasa entonces a unas

herramientas de reestructuracin y de ingeniera directa que completarn el proceso

de reingeniera [Pressman, 2003].

4.1.6 Reestructuracin

La transformacin desde una forma de representacin a otra en el mismo nivel de

abstraccin, preservando las caractersticas externas del sistema (funcionalidad y

semntica). [Chifofsky, 1990]

La reestructuracin del software modifica el cdigo fuente y/o los datos en un intentode adecuarlo a futuros cambios. En general, la reestructuracin no modifica la

arquitectura global del programa. Tiene a centrarse en los detalles de diseo de

mdulos individuales y en estructuras de datos locales definidas dentro de los

2Con frecuencia, las especificaciones escritas en fases centradas de la historia del programa no llegan a actualizarsenunca. A medida que se hacen cambios, el cdigo deja de satisfacer esas especificaciones.


7/23



mdulos. Si el esfuerzo de la reestructuracin se extiende ms all de los lmites de

los mdulos y abarca la arquitectura del software, la reestructuracin pasa a ser

ingeniera directa (forward engineering) [Pressman, 2003].

Arnold [Arnold, 1989] define un cierto nmero de beneficios que se pueden lograrcuando se reestructura el software:

Programas de mayor calidad con mejor documentacin y menoscomplejidad, y ajustados a las prcticas y estndares de la ingeniera del

software moderna.

Reduce la frustracin entre ingenieros del software que deban trabajar con elprograma, mejorando por tanto la productividad y haciendo ms sencillo el

aprendizaje.

Reduce el esfuerzo requerido para llevar a cabo las actividades demantenimiento.

Hace que el software sea ms sencillo de comprobar y de depurar.

La reestructuracin se produce cuando la arquitectura bsica de la aplicacin es

slida, aun cuando sus interioridades tcnicas necesiten un retoque. Comienza

cuando existen partes considerables del software que son tiles todava, y solamente

existe un subconjunto de todos los mdulos y datos que requieren una extensa

modificacin3 [Pressman, 2003].

4.1.7 Redocumentacin

La redocumentacin es tambin una forma de ingeniera inversa. Es el proceso

mediante el que se produce documentacin retroactivamente desde un sistema

existente. Si la redocumentacin toma la forma de modificacin de comentarios en el

cdigo fuente, puede ser considerada una forma suave de reestructuracin. Sinembargo, puede ser considerada como una sub-rea de la ingeniera inversa porque

la documentacin reconstruida es usada para ayudar al conocimiento del programa.

Se piensa en ella como una transformacin desde el cdigo fuente a pseudocdigo

3En algunas ocasiones, resulta difcil distinguir entre una reestructuracin extensa y un nuevo desarrollo. Ambos soncasos de reingeniera.


8/23



y/o prosa, esta ltima considerada como ms alto nivel de abstraccin que la

primera.

Aunque la aparicin de multitud de herramientas facilita las labores de la ingeniera

inversa, es la labor humana (humanware) la decisiva a la hora de completar elestudio del sistema [Tilley, 1995].

4.2 Caso part icular : WFS Geoserver

El proyecto Geoserver v. 1.1.1 [Geoserver, 2004] consiste en la implementacin de

un WFS basado en la especificacin de OpenGIS [WFS, 2002]. Es gratuito y est

disponible bajo la licencia GPL 2.0 en la direccin:

http://sourceforge.net/project/showfiles.php?group_id=25086

Esta implementacin se mostr bastante robusta cuando se prob, y haciendo uso de

la licencia GPL se decidi que encajaba como solucin al problema propuesto. Al

estudiarlo ms a fondo, descubrimos que careca de informacin del sistema, incluso

el cdigo tena una documentacin muy escasa, casi nula. Dadas estas circunstancias

se decidi realizar un proceso de ingeniera inversa con la cual, mediante

abstracciones a partir del cdigo fuente, se pudiera obtener informacin importante

acerca de la implementacin, como diseo de implementacin, diagramas, paquetes

y dems informacin que sea necesaria para el desarrollador en caso de querer

modificar en un futuro la aplicacin.

Se entabl comunicacin con una de las personas encargadas del proyecto Geoserver

y se le coment la idea de tener una implementacin propia de la que desarrollaron

ellos. El se mostr interesado, pues al ser an un proyecto, cualquier tipo de

retroalimentacin que se les proporcionar sera de gran ayuda. Una de losprincipales intereses fue la idea de implementar el sistema sobre una arquitectura no

probada, como la que tenemos en la UDLA-P. Con esto se logra, no slo tener una

solucin robusta a los problemas planteados con esta tesis, sino que adems

participamos en el desarrollo del proyecto Geoserver.


9/23



En la actualidad no hay un documento que exija o que evale cuales son los pasos

para una ingeniera inversa satisfactoria. As que a continuacin se propone una

metodologa que sirva como pautas para orientar en el proceso de ingeniera inversa

a quien as lo desee.

4.2.1 Metodologa

Debido a que no hay un documento que especifique como es exactamente un

proceso de ingeniera inversa, cada ingeniero de software que desea realizar un

proceso de este tipo propone su propia metodologa. El instituto de ingeniera de

software propone un marco de trabajo para llevar a cabo un proceso de ingeniera

inversa [SEI, 2004]. Tomando en cuenta este documento y con la ayuda de un

experto en la materia se propuso la metodologa de la figura 4.2 [fuente propia] para

realizar un proceso de ingeniera inversa. Principalmente lo que incluye la

metodologa propuesta es:

1. Definicin y delimitacin del componente de software2. Recoleccin de funcionalidades existente

a. Documentacin de Casos de Uso3. Generacin automtica de diagramas de clase y de paquete mediante una

herramienta semi-autimatizada CASE

a. Diagramas de claseb. Diagramas de paquete

4. Anlisis de cdigo y relacin entre paquetes5. Mapeo de requerimientos a paquetes y de ser posible a clases


10/23



Figura 4.2 Metodologa propuesta para el proceso de ingeniera inversa

4.2.1.1 Definicin y delimitacin

Esta es la primera etapa del proceso de ingeniera inversa y es la que comprende la

seleccin y evaluacin del o de los componentes a los que se les aplicar el proceso

de ingeniera inversa. Geoserver fue escogido primeramente por ser una

implementacin pblica que cumple con los requisitos que se necesitan para nuestra

solucin. Algunos de estos requisitos es que est hecho en Java, es OpenSource,

cumple con la especificacin que rige las implementaciones WFS, maneja peticiones

por HTTP GET y HTTP POST.

4.2.1.2 Casos de Uso

Para el proceso de recoleccin de funcionalidades existentes se desarrollaron los

casos de uso de las tres operaciones que soporta el WFS. La figura 4.3 muestra el


11/23



diagrama de caso de uso que incluye a estas tres operaciones y despus estn los

casos de uso de cada operacin.

Figura 4.3 Diagrama de caso de uso de las tres operaciones soportadas por el WFS


12/23



Reingeniera para la implementacin de un WFSUse-Case: Operacin GetCapabilities

Versin 1.0

Historia de revisionesFecha Versin Descripcin Autor

12/04/04 Draft_a Operacin GetCapabilities Abraham A. LpezAmeneyro

14/04/04 Draft_b Correcciones Abraham A. Lpez

Ameneyro15/04/04 1.0 Versin final Abraham A. Lpez

Ameneyro

Use-Case: Operacin GetCapabilities

1 Props i t o

El propsito de este caso de uso es explicar de manera textual y posteriormente

grfica, el uso de la operacin GetCapabilities.

1.1 A lcanceEste caso de uso es la descripcin de una de las tres operaciones que soporta el

servicio WFS, por lo tanto guarda una relacin con la descripcin de las restantes dos

operaciones (GetFeature y DescribeFeatureType).

1.2 Def in ic iones, Acrn im os y Abrev iac iones

WFS Web Feature Service OGC OpenGIS Consortium GML Geography Markup Language XML eXtensible Markup Language CQL Common Query Language Feature Abstraccin de un evento del mundo real, y que se define como un

conjunto de propiedades, puede ser pensado como una tupla {nombre, tipo,

valor}

Interface Conjunto de operaciones que caracterizan el comportamiento deuna entidad


13/23



Aplicacin cliente - Una aplicacin cliente ser cualquier aplicacin que puedaconectarse al servidor WFS y hacer peticiones ya sea por HTTP GET o HTTP

POST. Por ejemplo: thin clients, FME, ArcView, incluso otro WFS.

1.3 Referenc ias

OpenGIS Web Feature Service Implementation Specificationhttp://www.opengis.org/docs/02-058.pdf

OpenGIS Filter Encoding Implementation Specificationhttp://www.opengis.org/docs/02-059.pdf

OpenGIS Catalogue Interface Implementation Specificationhttp://www.opengis.org/docs/02-087r3.pdf

2. Operacin GetCapabilities

2.1 Descr ipc in Breve

Esta operacin se encarga de presentar al usuario un documento, el cual describe

todas las capacidades (operaciones y features) del servicio WFS.

3. Flujo de eventos

3.1 Flu j o bs ico

3.1.1

El caso de uso inicia cuando una aplicacin cliente solicita (E1) el documento que

describe las capacidades del servicio. El servidor recibe la peticin, genera el

documento de capacidades el cual debe estar definido y validado contra el esquema

A.5 del apndice del documento OpenGIS Web Feature Service Implementation

Specification [WFS, 2002], y lo enva a la aplicacin cliente para su visualizacin, con

esto termina este caso de uso.

3 . 2 Fl u j os a l t e rna t i vos

3.2.1

(E1) La aplicacin cliente puede formar mal la peticin para el documento de

capacidades, a lo que el servidor debe responder con una excepcin de servicio.

4. Categora

Core

5. Requerimientos especiales

La interface debe estar definida en XML y se define con respecto al esquemaA.3 del documento OpenGIS Web Feature Service ImplementationSpecification [WFS, 2002]

Las bases de datos deben ser opacas a la aplicacin cliente La solicitud debe definirse en XML y ser derivada de CQL Se debe usar esquemas XML (SCHEMAS) que son documentos GML vlidos,

para la descripcin del servicio


14/23



Reingeniera para la implementacin de un WFSUse-Case: Operacin DescribeFeatureType

Versin 1.0


12/04/04 Draft_a Operacin DescribeFeatureType Abraham A. LpezAmeneyro

15/04/04 Draft_b Correcciones Abraham A. Lpez

Ameneyro

16/04/04 1.0 Versin final Abraham A. LpezAmeneyro

Use-Case: Operacin DescribeFeatureType

1. Props i to


grfica, el uso de la operacin DescribeFeatureType.

1.1 A lcance

Este caso de uso es la descripcin de una de las tres operaciones que soporta el


operaciones (GetFeature y GetCapabilities).


WFS Web Feature Service OGC OpenGIS Consortium GML Geography Markup Language XML eXtensible Markup Language CQL Common Query Language Feature Abstraccin de un evento del mundo real, y que se define como un


valor}



15/23





1.3 Referenc ias




2. Operacin DescribeFeatureType

2.1 Descr ipc in brev e

Esta operacin se encarga de presentar al usuario un documento en el cual describe

como el servicio WFS espera que se codifiquen los features en las consultas, y comoser la salida generada por el servicio WFS.

3. Flujo de eventos

3.1 Flu j o bs ico

3.1.1

El caso de uso inicia cuando una aplicacin cliente solicita (E1) el documento que

describe como se codificarn los features tanto en la entrada como en la salida. El

servidor recibe la peticin y genera el esquema que describe como se encuentra

estructurado el feature solicitado el cual es un GML vlido. Finalmente lo enva a la

aplicacin cliente y con esto termina este caso de uso.


3.2.1

(E1) La aplicacin cliente puede formar mal la peticin del documento de descripcin

de features, a lo que el servidor debe responder con una excepcin de servicio.

4. Categora

Core


La interface debe estar definida en XML y se define con respecto al esquemaA.3 del documento OpenGIS Web Feature Service ImplementationSpecification [WFS, 2002]

La solicitud debe definirse en XML y ser derivada de CQL Se deben usar esquemas XML (SCHEMAS) que son documentos GML vlidos,

para la descripcin de los features


16/23



Reingeniera para la implementacin de un WFSUse-Case: Operacin GetFeature

Versin 1.0


12/04/04 Draft_a Operacin GetFeature Abraham A. LpezAmeneyro

15/04/04 Draft_b Correcciones Abraham A. LpezAmeneyro

15/04/04 1.0 Versin final Abraham A. Lpez

Ameneyro

Use-Case: Operacin GetFeature

1. Props i to


grfica, el uso de la operacin GetFeature.

1.1 A lcance

Este caso de uso es la descripcin de una de las tres operaciones que soporta el


operaciones (GetCapabilities y DescribeFeatureType).


WFS Web Feature Service OGC OpenGIS Consortium GML Geography Markup Language CQL Common Query Language XML eXtensible Markup Language Feature Abstraccin de un evento del mundo real, y que se define como un


valor}





17/23



1.3 Referenc ias




2. Operacin GetFeature

2.1 Descr ipc in breve

Esta operacin se encarga de hacer la consulta y recuperacin de los features

disponibles del servicio WFS.

3. Flujo de eventos

3.1 Flu j o bs ico 3.1.1

El caso de uso inicia cuando una aplicacin cliente genera una consulta (E1) y la enva

al servidor. El servidor recibe la peticin, la interpreta y la resuelve, generando un

documento con el resultado de la consulta el cual es un GML vlido y debe tambin ser

vlido contra el esquema generado por la operacin DescribeFeatureType. Finalmente

se enva a la aplicacin cliente. Con esto termina este caso de uso


3.2.1

(E1) La aplicacin cliente puede formar mal la consulta, a lo que el servidor debe

responder con una excepcin de servicio.

4. Categora

Core


La interface debe estar definida en XML y se define con respecto al esquemaA.3 del documento OpenGIS Web Feature Service Implementation

Specification [WFS, 2002]

La consulta o filtro debe definirse en XML y ser derivada de CQL Se debe usar GML para expresar los features dentro de la interface


18/23



4.2.1.3 Generacin automtica de diagramas de clase

Esta parte del proceso de ingeniera inversa comprende la generacin de los

diagramas de clase y/o de paquetes usando una herramienta CASE semi-

automatizada, como por ejemplo JBuilder 9.0, Enterprise Architect o Rational Rose.En nuestro proceso de ingeniera inversa utilizamos JBuilder para generar los

diagramas de clase. Debido al gran nmero de diagramas generados, slo se

muestra uno representativo en este documento, sin embargo todos estn disponibles

en lnea en este mismo proyecto Gisweb. La figura 4.4 es un ejemplo de diagrama de

clase generado por una herramienta CASE semi-automatizada, en este caso JBuilder.

Este describe la clase WFService del paquete org.vfny.geoserver.servlets y muestra

sus relaciones de dependencia y extensiones. Ms detalladamente muestra que

hereda de la clase AbstractService y que depende de las clases ExceptionHandler y

WfsExceptionHandler. Esta clase es muy importante, el paquete

org.geoserver.servlets.wfs que contiene los servlets principales de este servicio,

hereda de esta clase.

Figura 4.4 Ejemplo de diagrama de clase


19/23



4.2.1.4 Anlisis del sistema

Esta parte del proceso de ingeniera inversa consiste en el estudio por parte del

analista para descubrir con ayuda de la informacin obtenida hasta el momento elfuncionamiento del sistema, pero a un nivel ms detallado. Este es tal vez la parte

de la metodologa ms pesada porque entra la pericia del analista para descubrir

como funciona el sistema a partir de la poca o nula informacin que posee. Para

ayudarnos y seguir contribuyendo a la documentacin de esta implementacin en el

proceso de anlisis se desarrollaron los siguientes diagramas de secuencia.

El primer diagrama de secuencia mostrado en la figura 4.5 pertenece al caso de uso

de la operacin GetCapabilities y es la comunicacin de mensajes a alto nivel para

responder la peticin hecha por la aplicacin cliente. El diagrama de la figura 4.6

pertenece al caso de uso de la operacin DescribeFeatureType y al igual que la figura

anterior, es el proceso de comunicacin de mensajes entre clases para responder

una peticin hecha por la aplicacin cliente. Finalmente el diagrama mostrado en la

figura 4.7 pertenece al caso de uso de la operacin GetFeature y describe el mismo

proceso que las dos anteriores.

Figura 4.5 Diagrama de secuencia: GetCapabilities


20/23



Figura 4.6 Diagrama de secuencia: DescribeFeatureType

Figura 4.7 Diagrama de secuencia: GetFeature


21/23



4.2.1.5 Mapeo de requerimientos a paquetes

Esta parte del proceso es una aportacin importante a la documentacin de un

software o componente pues facilita mucho identificar que ocurre cuando deseamos

modificar una parte del cdigo. Consiste en una tabla donde se ponen losrequerimientos del sistema, los casos de uso involucrados, y las clases o paquetes

afectados y establece la relacin entre todos estos elementos de la tabla. Una vez

que se tenga la tabla (la cual puede llegar al nivel de detalle que se necesite) si en

un futuro se quiere modificar parte del cdigo la tabla indique que casos de uso se

vern afectados y por consiguiente que requerimientos tambin estarn

involucrados. Esto es de gran ayuda en sistemas grandes porque no tenemos que

esperar a las pruebas de regresin para descubrir que fue lo que se alter. La tabla

4.1 muestra el mapeo de requerimientos a paquetes y clases de Gisweb pero de alto

nivel, por lo tanto es de los requerimientos funcionales bsicos y algunos especiales

(estos requerimientos se encuentran en la seccin 4.3.1.2 de este documento de

tesis). En el siguiente captulo se implementa este cdigo en una Webapp para

poder tenerlo en lnea con toda la informacin pertinente.


22/23



Requerimientos Caso de uso Clases

Medio por el cual el WFSproporciona al cliente la

opcin de preguntar comose estructura y cuales sonlas caractersticas de un

feature DescribeFeatureType

org.vfny.geoserver.requests.wfs.Descorg.vfny.geoserver.requests.readers.wfs.D

org.vfny.geoserver.requests.wfs.Descorg.vfny.geoserver.servlets.Abstra

org.vfny.geoserver.responses.wfs.Descorg.vfny.geoserver.config.Catalo

org.geotools.gml.producer.FeatureTypeTransformeMedio por el cual el WFSproporciona al cliente la

opcin de preguntar por suspropias capacidades,

fearures y operacionesdisponibles sobre cada

feature. GetCapabilities

org.vfny.geoserver.servlets.Abstraorg.vfny.geoserver.requests.Capabil

org.vfny.geoserver.requests.readers.wfs.Cap

Medio por el cual el WFSproporciona al cliente la

opcin de hacer consultasespaciales y decriptvas

sobre uno o ms features GetFeature

org.geotools.filter.LogicSAXPaorg.geotools.gml.GMLFilterGeo

org.vfny.geoserver.requests.readers.wfs.Georg.xml.sax.helpers.AttributesImpl org.geoto

org.vfny.geoserver.requests.wfs.Featorg.vfny.geoserver.servlets.Abstra

org.vfny.geoserver.responses.wfs.Featorg.vfny.geoserver.config.Catalo

org.vfny.geoserver.config.DataStoorg.geotools.factory.FactoryF

org.geotools.gml.producer.FeatureTransforme

Las interfaces deben estardefinidas en XML

GetCapabilitiesDescribeFeatureType

GetFeature

org.vfny.geoserver.servlets.wfs.Caorg.vfny.geoserver.servlets.wfs.Dorg.vfny.geoserver.servlets.wfs.

Usar GML para representarfeatures GetFeature package org.geotools.featu

La peticin debe hacerse enXML y ser derivada de CQL

GetCapabilities

DescribeFeatureTypeGetFeature

org.vfny.geoserver.requests.readers.wfs.D

org.vfny.geoserver.requests.readers.wfs.Caporg.vfny.geoserver.requests.readers.wfs.Ge

Bases de datos

GetCapabilitiesDescribeFeatureType

GetFeatureorg.vfny.geoserver.config.Catalo

org.vfny.geoserver.config.DataSto

Tabla 4.1 - Mapeo de requerimientos y clases


23/23



En este captulo vimos el proceso de ingeniera inversa a la implementacin pblica de

Geoserver de su WFS y como obtuvimos los diagramas de diseo del funcionamiento

global del sistema. La ingeniera inversa aqu presentada fue muy general debido a la

complejidad del proyecto en cuestin, pero se puede hacer tan detallada como se

desee. Se puede repetir este ciclo a niveles cada vez ms profundos hasta llegar alanlisis de lneas de cdigo. La importancia de la ingeniera inversa es que con el

resultado de este proceso, es fcil entender el funcionamiento de un sistema, y saber

qu hacer y en dnde cuando ocurra un problema o simplemente cuando sea tiempo

de darle mantenimiento al sistema. Se propuso una metodologa en base a

comentarios de un experto en el rea que sirva de gua en futuros procesos de

ingeniera inversa. La figura 4.8 muestra que parte de este proyecto de tesis

representa este captulo y el trabajo restante para completar nuestro sistema Gisweb.

En el siguiente captulo se trata la implementacin del WFS como webapp al integrarse

con una interfaz de usuario.

Figura 4.8 Diagrama w e b a p p Gisweb

WFSClases

Interfazdeusuario

WFSResponse.classsw.jsp

Package org.geotoolsPackage org.vfny.geoserver

ingeniera inversas_1

Documents

Transcript of ingeniera inversas_1