INTRODUCCIÓN - DSpace de la Universidad Catolica de Cuenca

Transcripción

Universidad Católica de Cuenca
Tnlg. Alvaro Nievecela
Facultad de Ingeniería de Sistemas
INTRODUCCIÓN
Todo sistema de información se construye para solucionar problemas
presentes. Un cambio en las condiciones del entorno organizacional
puede producir un cambio en los objetivos de la organización y, en
consecuencia, las reglas de la organización también se
Muchos
sistemas
modifican.
en funcionamiento, deben someterse a un
mantenimiento apremiante y constante. Para eso es necesario contar con
las herramientas necesarias para realizar un adecuado control de cambios
y mantenimiento del sistema.
En la actualidad muchas empresas (especialmente las pequeñas y
medianas empresas) que desarrollan software para otras empresas o
para ellas mismas no tienen conciencia de lo importante que es el
mantenimiento y tratan de “ahorrar” costos al no invertir en tareas de
documentación de sus sistemas, presentando así una inadecuada y
desactualizada documentación, y en algunos casos una documentación
nula, que desemboca con el tiempo en una degradación de la aplicación
y, por ende, en un servicio deficiente para el cliente y/o usuario. Existen
también muchos sistemas de software que son complejos o antiguos y
que su información no es fácilmente disponible, y sin el suficiente
entendimiento del sistema este mantenimiento no puede ser realizado
Ingeniería Inversa aplicada a sistemas desarrollados con P.O.O. para obtener la Documentación
1
Múltiples estudios señalan que el mantenimiento es la parte más costosa
del ciclo de vida del software. Estadísticamente está comprobado que el
coste de mantenimiento de un producto software a lo largo de toda su
vida útil supone más del doble que los costes de su desarrollo.
El propósito del presente trabajo es proponer una metodología de
ingeniería inversa como una solución para entender el sistema existente,
a través de la recuperación del diseño y la especificación de sus
requisitos, contribuyendo así con el entendimiento de la funcionalidad del
sistema que se va hacer mantenimiento.
2
CAPÍTULO 1
1.1 MARCO REFERENCIAL
Herramientas CASE para la Ingeniería Inversa ya existen algunas
herramientas de este tipo. Su evolución marcará notables mejoras en la
obtención de los diseños a partir del código ya existente (ingeniería
inversa) y la regeneración del mismo, una vez optimizado el diseño
(ingeniería directa).
Ejemplos de algunos:
Rational Rose
Es una de las más poderosas herramientas de modelado visual para el
análisis y diseño de sistemas basados en objetos. Se utiliza para modelar
un sistema antes de proceder a construirlo. Cubre todo el ciclo de vida de
un proyecto:
• Concepción y formalización del modelo,
• Construcción de los componentes,
• Transición a los usuarios y
• Certificación de las distintas fases
3
Telelogic Tau
La familia de productos de Telelogic Tau® automatiza las prácticas
recomendadas de diseño y desarrollo para:
Visualización de la concepción de los proyectos y de los requisitos
Ingeniería de sistemas
Arquitectura de sistemas de defensa
Desarrollo de software para sistemas embebidos y otros sistemas
avanzados
Pruebas con las eficaces funciones de modelado gráfico de Tau, los
usuarios pueden:
Especificar todos los aspectos del diseño de un sistema
Simular y verificar su comportamiento
Garantizar que el diseño es acorde con las necesidades del cliente,
incluso en las fases tempranas del proyecto
Generar código del modelo validado
Definir, generar y ejecutar pruebas en los modelos
4
Enterprise Architect
Enterprise Architect combina el poder de la última especificación UML 2.1
con alto rendimiento, interfaz intuitiva, para traer modelado avanzado al
escritorio, y para el equipo completo de desarrollo e implementación.
Es una herramienta comprensible de diseño y análisis UML, cubriendo el
desarrollo de software desde el paso de los requerimientos a través de las
etapas del análisis, modelos de diseño, pruebas y mantenimiento. EA es
una herramienta multi-usuario, basada en Windows, diseñada para ayudar
a construir software robusto y fácil de mantener. Ofrece salida de
documentación flexible y de alta calidad. El manual de usuario está
disponible en línea.
Vaquista
Esta herramienta es capaz de convertir una interfaz web en HTML a XIML
y después usar un proceso secundario para producir una tercera
representación.
Altova UModel 2007 es el punto de entrada para el desarrollo de software
exitoso. Utilice UModel 2007 para crear e interpretar diseños software
mediante la potencia del estándar UML 2.1. Dibuje su diseño de
aplicación y genere código Java o C# a partir de sus planos, o haga
ingeniería inversa de programas existentes a diagramas UML claros y
5
precisos para abarcar rápidamente su arquitectura software. Incluso podrá
corregir su código generado o sus modelos y completar la ronda
produciendo automáticamente nuevos diagramas o regenerando el
código. De cualquier manera, UModel le permite mantener su proyecto
sincronizado y al día. Los 13 posibles tipos de diagramas UML 2 están
soportados por UModel junto con un novedoso tipo de diagrama para
modelar Schema XML en UML
Imagix 4D
Imagix 4D es una herramienta para la Ingeniería Inversa estática. Esta
herramienta funciona en distintas plata-formas (Unix, Linux, Windows,
entre otras tantas) y posibilita el análisis de sistemas escritos en C y C++.
En Imagix 4D existen ventanas que muestran lo siguiente: i) relaciones
entre archivos, clases, funciones, variables, macros y tipos; ii) lugares
donde los símbolos se encuentran ubicados dentro de la estructura y
también posibilita ver el contenido de los archivos; iii) formas de navegar
entre los distintos archivos del sistema de estudio; iv) resultados de
búsquedas; v) navegación entre las distintas clases del sistema; vi)
diagramas de flujos. Las funciones provistas con Imagix 4D ayudan a
diferentes tareas relacionadas con la comprensión de programas, por
ejemplo: i) permite una rápida navegación a través del flujo de control;
herencias y relaciones entre las clases;
6
ii) facilita el estudio del programa por medio de componentes reusables y
el proceso de construcción;
iii) analiza el software de las siguientes maneras: focalizando en
actividades de verificación; ubicando cuellos de botellas;
iv)
permite
generar
documentación
actualizada
y
de
código
indocumentado
1.2 MARCO TEÓRICO
El Objetivo primordial de la Ingeniería Inversa es proporcionar una base
para el mantenimiento y futuros desarrollos. Este objetivo general se
puede traducir en los siguientes objetivos parciales:
•
Facilitar la reutilización.
•
Proporcionar documentación que no existe, o actualizar la
existente.
•
Migrar a otra plataforma hardware o software, cuando sea
necesario.
•
Llevar el sistema bajo el control de un entorno CASE.
A la vista de estos objetivos, los sistemas candidatos a aplicarles la
Ingeniería Inversa reúnen algunas de las siguientes características:
7
•
Las especificaciones de diseño y la documentación, no existen o
están incompletas.
•
El código no es estructurado.
•
El sistema necesita un excesivo mantenimiento correctivo.
•
Algunos
módulos
se
han
hecho
excesivamente
complejos
debido a los sucesivos cambios realizados en ellos.
•
Se necesita una migración hacia una nueva plataforma de
hardware o
de software.
Aplicar la Ingeniería Inversa supone un enorme esfuerzo y, por tanto, se
hace necesario evaluar exhaustivamente y siendo muy realistas, los
casos en los que es rentable su aplicación. A estos efectos, algunos
aspectos que se deben considerar son los siguientes:
•
Los programas que no se usan con mucha frecuencia no es
probable que vayan a cambiar.
•
Las herramientas de ingeniería inversa, generalmente herramientas
CASE relativamente sofisticadas, sólo pueden utilizarse para una
clase limitada de aplicaciones.
•
El coste en esfuerzo y en dinero puede ser prohibitivo.
8
No obstante, la Ingeniería Inversa produce una
serie de beneficios,
que también deben ser considerados. Los más importantes son los
siguientes:
•
Mejora la calidad del software, ya que los sistemas candidatos a
aplicarles Ingeniería Inversa son, en general, sistemas de baja
calidad.
•
Aporta una mayor ventaja competitiva, dado que al facilitar el
mantenimiento, permite un mayor poder de reacción ante los
cambios solicitados por los usuarios.
1.3 MARCO CONCEPTUAL
Ingeniería Inversa
El término “Ingeniería Inversa” tiene sus orígenes en el mundo del
hardware. Una empresa desensambla un producto de la competencia
para intentar comprender los secretos del diseño y de la fabricación. Pues
bien, la Ingeniería Inversa del software es bastante similar; si bien, en la
mayoría de los casos el producto objeto de la misma no es de una
empresa de la competencia sino, más bien, se trata de un trabajo propio,
generalmente realizado muchos años atrás, y del que no existen
especificaciones o éstas son muy incompletas.
9
La Ingeniería Inversa se ocupa de estudiar un sistema de información en
el orden inverso establecido en el ciclo de vida habitual; esto es,
partiendo del código fuente, se trata de identificar los componentes del
sistema y las relaciones existentes entre ellos. Hasta su llegada, el ciclo
de vida del software era, en teoría, en una sola dirección; ahora, se puede
hablar de dos direcciones: forward o hacia adelante, que es la tradicional,
y reverse o hacia atrás, que es la de la Ingeniería Inversa.
1.4 Herramientas para la ingeniería inversa
La Ingeniería Inversa requiere algunas herramientas especializadas que
no son normalmente familiares para muchos usuarios (e incluso para
muchos
desarrolladores de software.
Desensambladores
Descompiladores
Depuradores
Ingeniería Inversa/Editores Hexadecimales
Otras Herramientas
10
1.4.1 Ingeniería Inversa/Desensambladores
Esencialmente, un desensamblador es exactamente lo contrario de un
ensamblador. Tal como un ensamblador convierte código escrito en
ensamblador en código máquina binario, un desensamblador invierte el
proceso e intenta recrear el código en ensamblador partiendo del código
máquina binario.
Dado que la mayoría de los lenguajes ensambladores tienen una
correspondencia uno a uno con instrucciones máquina subyacentes, el
proceso
de
desensamblado
es
relativamente
sencillo,
y
un
desensamblador básico puede a menudo ser implementado simplemente
leyendo bytes, y efectuando una búsqueda en una tabla. Por supuesto,
desensamblar tiene sus propios problemas y escollos, que serán cubiertos
mas adelante en este capítulo.
Muchos desensambladores tienen la opción de producir instrucciones en
lenguaje
ensamblador
usando
la
sintaxis
de
Intel,
AT&T,
o
(ocasionalmente) HLA.
11
Desensambladores para Windows
Por conveniencia, separaremos los desensambladores Windows en 2
categorías:
Herramientas
Comerciales
(que
cuestan
dinero),
y
Herramientas Gratuitas (que son gratis y/o libres).
Herramientas Comerciales
IDA Pro
es un desensamblador profesional caro extremadamente potente. La
parte mala es su elevado precio.
PE Explorer
es un desensamblador que "se centra en facilidad de uso, claridad y
navegación". No es tan completo como IDA Pro, pero tiene un precio mas
bajo.
W32DASM
W32DASM es un excelente desensamblador 16/32 bit para Windows.
12
Herramientas Gratuitas
IDA Pro Freeware 4.1
Se comporta casi como IDA Pro, pero solo desensambla código para
procesadores Intel x86, y solo funciona en Windows.
IDA Pro Freeware 4.3
Mejor interfaz gráfico que la versión previa.
BORG Disassembler BORG
Es un excelente desensamblador con interfaz gráfico para Win32.
HT Editor
Un desensamblador analizador para instrucciones x86. La última versión
corre como un programa de interfaz gráfico de consola en Windows, pero
hay versiones compiladas para Linux también.
DiStorm64
DiStorm es una librería de desensamblador de stream altamente
optimizada para 80x86 y AMD64.
13
Desensambladores para Linux
Bastard DisassemblerBastard
Es un potente y programable desensamblador para Linux y FreeBSD.
Ciasdis
Permite construir conocimiento sobre un cuerpo de código de manera
interactiva e incremental. Es único en que todo el código desensamblado
puede ser re-ensamblado exactamente al mismo código. Soporta 8080,
6809, 8086, 80386, Pentium I y DEC Alpha. Facilidades de scripting
ayudan en al análisis de cabeceras de fichero Elf y MSDOS y hacen esta
herramienta extensible. ciadsis para Pentium I está disponible como
imagen binaria, las otras están en código fuente, cargables sobre lina
Forth, disponible del mismo sitio.
Objdump
Viene de manera estándar, y es típicamente usada para inspección
genérica de ficheros binarios.
Gdb
Viene de manera estándar, como depurador, pero es usado muy a
menudo para desensamblar. Si tienes un bloque arbitrario de datos en
hexadecimal
que
quieres
desensamblar,
simplemente
introdúcelo
14
(interactivamente) o compilalo en un programa como una cadena de texto
así: char foo[] = {0x90, 0xcd, 0x80, 0x90, 0xcc, 0xf1, 0x90}.
Lida linux interactive disassembler
Un desensamblador interactivo con algunas funciones especiales como
un criptoanalizador. Muestra referencias a cadenas, hace análisis de flujo
de código, y no depende de objdump. Usa la librería de desensamblage
Bastard para descodificar instrucciones individuales.
ldasm
LDasm (Linux Disassembler) es un interfaz gráfico basado en Perl/Tk para
objdump/binutils que intenta imitar el aspecto de W32Dasm. Busca
referencias cruzadas por ejemplo cadenas, convierte el código de GAS a
un estilo parecido a MASM, traza programas y mucho más. Viene con
PTrace, un logger para flujo de procesos.
Desensambladores para no-x86
Ciasdis
Esta herramienta basada en Forth permite construir conocimiento sobre
un cuerpo de código de manera interactiva e incremental. Es único en que
todo el código desensamblado puede ser re-ensamblado al mismo código
exactamente. Soporta procesadores 8080, 6809, 8086, 80386, Pentium I
15
y DEC Alpha. Facilidades de scripting ayudan en al análisis de cabeceras
de fichero Elf y MSDOS y hacen esta herramienta extensible. Los
desensambladores y ensambladores para no-Pentium solo están
disponibles commo código fuente, cargables sobre lina Forth..
Mac OS X
Gdb
Viene de manera estándar, como depurador, pero es usado muy a
menudo para desensamblar. Si tienes un bloque de datos hexadecimales
para desensamblar, introdúcelo (interactivamente) encima de otra cosa o
compílalo en un programa como cadena de esta manera: char foo[] =
{0x90, 0xcd, 0x80, 0x90, 0xcc, 0xf1, 0x90};
Machonist
Machonist es realmente más que un potente desensamblador. Contiene
funciones para ejecutar el programa bajo GDB, grabar y cargar parches,
añadir comentarios a un desensamblaje, parchear, hacer el de-mangling
de los nombres de funciones C++, y mucho más. Es una aplicación con
interfaz gráfica, así que los usuarios nuevos encontrarán más fácil
acostumbrarse.
16
Otool
Otool es un analizador binario muy potente que contiene funciones para
desensamblar el código de ejecutables.
Ndisasm
Desensamblador simple para x86, que simplemente desensambla un
fichero
binario
sin
conocimiento
del
formato
objeto.
Útil
para
desensamblar binarios de otras plataformas. Viene estándar con las Apple
Developer Tools.
Problemas del Desensamblador
Separación de código y datos
Puesto que tanto instrucciones como datos están almacenados como
datos
binarios
en
un
fichero
ejecutable,
una
pregunta
surge
espontáneamente: ¿Cómo puede un desensamblador separar código de
datos? ¿Es un byte en particular una variable, o parte de una instrucción?
El problema no sería tan difícil si los datos se limitaran a la sección .data
del ejecutable (explicado en un capítulo posterior) y si el código ejecutable
estuviese limitado también a la sección .code del ejecutable, pero a
menudo este no es el caso. Los datos pueden estar insertados
directamente en la sección de código (por ejemplo, las tablas de
17
direcciones de salto), y código ejecutable puede estar almacenado en la
sección de datos ( aunque sistemas nuevos evitarán esto por razones de
seguridad).
Muchos desensambladores interactivos ofrecerán al usuario la opción de
mostrar segmentos de código como código o datos, pero los
desensambladores
no
interactivos
harán
esta
separación
automáticamente. Los desensambladores suelen proveer en la misma
línea la instrucción y sus correspondientes datos en hexadecimal, para
reducir la necesidad de hacer decisiones sobre la naturaleza del código.
Algunos desensambladores (por ejemplo, ciasdis) te permiten especificar
reglas sobre si desensamblar como datos o código e inventar nombres
para la etiquetas, basándose en el contenido del objeto bajo escrutinio.
Scriptaer tu propio "crawler" de esta manera es más eficiente; para
programas grandes el desensamblaje interactivo puede ser difícil hasta el
punto de no ser practicable.
El problema general de separar datos de código en ejecutables arbitrarios
es equivalente al Halting Problem. Como consecuencia, no es posible
escribir un desensamblador que separe correctamente datos de código
para todos los programas de input. La ingeniería Inversa está llena de
tales limitaciones teóricas, aunque por el teorema de Rice ( Rice's
theorem ) todas las preguntas interesantes sobre propiedades de los
programas son indecidibles (así que los compiladores y muchas otras
18
herramientas que tratan con programas en cualquier manera también se
encuentran con tales límites). En la práctica una combinación de análisis
automático e interactivo con perseverancia puede manejar todos los
programas excepto aquellos específicamente diseñados para frustrar la
ingeniería inversa, como el uso de encripción o el desencriptado de
código justo antes de usarse, y mover código de un lado a otro en
memoria.
1.4.2 Ingeniería Inversa/Descompiladores
De manera semejante al desensamblado, la descompilación lleva el
proceso un paso más allá e intenta reproducir el código a un lenguaje de
alto nivel. Frecuentemente, este lenguaje es C, porque C es simple y lo
suficientemente primitivo para facilitar el proceso de descompilación. La
descompilación
tiene
sus
problemas,
porque
muchos
datos
y
construcciones para legibilidad se pierden durante el proceso original de
descompilación, y no pueden ser reproducidos. Puesto que esta disciplina
es todavía joven, y los resultados son razonablemente buenos pero no
excelentes.
19
Descompiladores Comunes
DCC Decompiler
Dcc es una excelente perspectiva teórica a la descompilación, pero el
descompilador sólo soporta programas MSDOS.
Boomerang Decompiler Project
El descompilador Boomerang es un intento de construir un potente
descompilador para varias máquinas y lenguajes. Hasta ahora, sólo
descompila en C con un éxito moderado.
Reverse Engineering Compiler (REC)
REC es un potente "descompilador" que descompila código ensamblador
a una representación del código semejante a C. El código está a medio
camino entre ensamblador y C, pero es mucho más legible que el
ensamblador puro.
1.4.3 Ingeniería Inversa/Depuradores
Los depuradores son, con la posible excepción de un descompilador
potente, el mejor amigo de un ingeniero inverso. Un depurador permite al
usuario ejecutar el programa paso a paso, y examinar varios valores y
acciones.
20
Los depuradores avanzados a menudo contienen por lo menos un
desensamblador rudimentario, características de reensamblado o edición
hexadecimal. Los depuradores generalmente permiten al usuario colocar
puntos de ruptura en instrucciones, llamadas a función e incluso lugares
de la memoria.
Un punto de ruptura (breakpoint) es una instrucción al depurador que
permite parar la ejecución del programa cando cierta condición se cumpla.
Por ejemplo, cuando un programa accede a cierta variable, o llama a ci
erta función de la API, el depurador puede parar la ejecución del
programa.
Depuradores Windows
OllyDbg
OllyDbg es un potente depurador Windows con un motor de ensamblado y
desensamblado
integrado.
Tiene
numerosas
otras
características
incluyendo un precio de 0$. Muy útil para parcheado, desensamblado y
depuración.
WinDBGWinDBG es una pieza de software gratuita de Microsoft
que puede ser usada para depuración local en modo usuario, o incluso
depuración remota en modo kernel. WinDBG no es lo mismo que el mejor
conocido.
21
CAPÍTULO 2
Estudio de la Herramienta Enterprise Architect
2.1 ¿Qué es Enterprise Architect?
Enterprise Architect de Sparx Systems es una herramienta CASE
(Computer Aided Software Engineering) para el diseño y construcción de
sistemas de software, para el modelado de procesos de negocios, y para
objetivos de modelado más generalizados. EA está basada en la
especificación the UML 2.1, que define un lenguaje visual que usa para
modelar un dominio o sistema en particular (existente o propuesto).
Tenga en Cuenta: UML es un estándar de modelado abierto, definido y
mantenido por el Grupo de Administración de Objeto. Para obtener más
detalles sobre UML, incluyendo los documentos de especificación de UML
actual, visite http://www.omg.org y siga los vínculos.
EA es una herramienta progresiva que soporta todos los aspectos del
ciclo de desarrollo, proporcionando una trazabilidad completa desde la
fase inicial del diseño a través del despliegue y mantenimiento. También
provee soporte para pruebas, mantenimiento y control de cambio.
Con más de 100,000 licencias vendidas, Enterprise Architect ha probado
ser muy popular a través de un rango amplio de industrias y es usado por
miles de compañías en todo el mundo. Desde organizaciones conocidas y
22
multinacionales hasta compañías y consultoras independientes y
pequeñas, Enterprise Architect se ha convertido en la herramienta de
modelado UML de elección para los desarrolladores, consultores y
analistas en más de 60 países.
2.2 Características de Enterprise Architect
Enterprise Architect esta disponible en las tres ediciones: Corporativo,
Profesional y Escritorio, cada uno de los cuales ofrece un rango diferente
de características. Para obtener una comparación de las ediciones de EA,
vea el tema Diferencia entre las ediciones Corporativa, Profesional, y
Escritorio.
•
UML 2.1 comprensivo -modelado basado
•
Administración de requisitos incorporada
•
Depuración y perfilación integrada para las aplicaciones Java y
.Net.
•
Soporte de administración del proyecto extensivo, incluyendo los
recursos, métricas y pruebas.
•
Soporte de pruebas: soporte para casos de prueba, JUnit y NUnit
•
Opciones de documentación flexible: HTML estándar y reportes
RTF.
23
•
Soporte para muchos lenguajes de ingeniería de código fuera de la
caja
•
Entorno de modelado extensible con la capacidad de hospedar
perfiles y tecnologías definidas por el usuario.
•
Uso.
•
Velocidad: EA es un ejecutor espectacularmente rápido.
•
Escalabilidad: EA puede manejar modelos y usuarios individuales,
y
modelos
extremadamente
grandes
y
muchos
usuarios
concurrentes con igual facilidad.
•
Precio: EA está evaluado para equipar el equipo completo,
haciendo del desarrollo de colaboración y del equipo una
posibilidad real.
2.3 ¿Qué puedo hacer con Enterprise Architect?
Enterprise Architect es un medio fuerte por el cual se puede especificar,
documentar y compilar sus proyectos de software. Usando las notaciones
y semánticas del UML, puede diseñar y modelar sistemas de software
complejos desde su comienzo.
EA le permite:
24
•
Modelar sistemas de hardware y software complejos en notación
UML.
•
Generar y realizar ingeniería de código inversa (Solo en Ediciones
Profesional y Corporativa) en:
•
Actionscript,
•
C
•
C++
•
C#
•
Delphi
•
Java
•
PHP
•
Python
•
Visual Basic
•
VB.NET.
•
Modelar base de datos y generar scripts DDL e invertir el esquema
de base de datos desde las conexiones ODBC.
25
•
Producir documentación detallada y de calidad en formatos RTF y
HTML.
•
Administrar cambio, mantenimiento y scripts de prueba.
•
Modelar dependencias entre los elementos.
•
Configurar clasificadores de objeto.
•
Modelar dinámicos del sistema y estados.
•
Modelar jerarquías de clase.
•
Modelar
los
detalles
de
despliegue,
componentes
e
implementación.
•
Recolectar incidencias del proyecto, tareas y el glosario del
sistema.
•
Asignar recursos a los elementos del modelo y comparar el
esfuerzo que llevo con el esfuerzo requerido.
•
Modelos de producción en formato compatible XMI 1.0, XMI 1.1,
XMI 1.2 y XMI 2.1 para exportar a otras herramientas que soporten
XMI.
•
Importar modelos en formato XMI 1.0, XMI 1.1, XMI 1.2 y XMI 2.1
desde otras herramientas.
26
•
Administrar el control de versiones a través de XMI usando MS
TFS, CVS y configuraciones de la subversión.
•
Usar
Perfiles
UML
para
crear
extensiones
de
modelado
personalizado.
•
Guardar y Descargar diagramas completos como patrones UML.
•
Analizar las relaciones entre los elementos en un formato tabular
usando la Matriz de Relación.
•
Escribir y trabajar con elementos UML y automatizar tareas
comunes usando una interfaz de Automatización detallada.
•
Conectar a las bases de datos SQL Server, MySQL, Oracle9i,
PostgreSQL, Adaptive Server Anywhere, y Progress OpenEdge
databases (Edición Corporativa).
•
Migrar cambios a través de un entorno distribuido con una
Replicación JET.
•
Usar paquetes controlados basados en importar y exportar XMI.
•
Realizar Transformaciones de Estilo MDA (ediciones profesional y
corporativa.
27
Ingeniería de Código
Ingeniería de Código es un proceso que incluye generación automática de
código, ingeniería inversa de código fuente y sincronización entre el
código y el modelo.
La Ingeniería de Código está disponible solamente en las versiones
Profesional y Corporativa de Enterprise Architect.
Generación de Código
Generación de código en también conocida como Ingeniería de Código
Directa. Enterprise Architect le permite generar código fuente de los
elementos de los modelos UML, creando un código fuente equivalente de
la clase o interface para futura elaboración y compilación. En particular
puede generar código fuente en C, C++, C#, Delphi, Java, PHP, Python,
ActionScript, Visual Basic and VB.NET. El código fuente generado incluye
definiciones de clases, variables y funciones para cada atributo y método
en la clase UML. Puede usar el Visor de código fuente para cualquier
código fuente que usted esté abriendo.
El Code Template Framework (CTF) le permite adaptar la manera en que
Enterprise Architect genera código fuente y también le permite generar en
lenguajes
que
Enterprise
Architect
no
soporta
específicamente
ayudándole a definir las plantillas de generación de código para ese
28
lenguaje (esto es discutido en "Enterprise Architect Software Developers'
Kit" (SDK).
Puede enlazar las facilidades de Enterprise Architect para otros entornos
de desarrollo. El Enlace MDG para Eclipse y MDG para Visual Studio.NET
son productos "standalone" que proveen una funcionalidad de generación
de código mejorada entre Enterprise Architect y los entornos de
desarrollo.
Enterprise Architect le permite modelar rápidamente, ingeniería directa e
ingeniería inversa Tecnologías XML, llamadas XML Schema (XSD) y Web
Service Definition Language (WSDL).
Ingeniería Inversa
Ingeniería Inversa es la importación de código fuente existente en
elementos del modelo, mapeando las estructuras de código fuente en sus
representaciones UML. Esto le permite examinar código antigüo y la
funcionalidad de las librerías de código para reusar, o para actualizar el
modelo UML con el código. Puede realizar ingeniería inversa en los
mismos lenguajes mientras realiza generación de código con Enterprise
Architect.
Enterprise Architect también permite realizar ingeniería inversa en algunos
tipos de archivos binarios: Java .jar y .NET PE.
29
Sincronización
Sincronización es cuando los cambios en el modelo son exportados a la
fuente y los cambios la fuente son importados en el modelo. Esto le
permite mantener su modelo y su código actualizados mientras el
proyecto avanza.
Ingeniería Completa
Ingeniería completa ocurre como una combinación de generación de
código inversa y directa y debe incluir sincronización entre el código
fuente en todos los proyectos de ingeniería de código. Para obtener el
mayor provecho de esta ingeniería en Enterprise Architect, usted debe
estar familiarizado con las convenciones de modelado usadas cuando
genera e ingeniería inversa de los lenguajes que usted usa.
2.4 Enterprise Architect V5.0
Combina el poder de la última especificación UML 2.1 con alto
rendimiento, interfaz intuitiva, para traer modelado avanzado al escritorio,
y para el equipo completo de desarrollo e implementación. Con un gran
conjunto de características y un valor sin igual para el dinero, EA puede
equipar
a
su
equipo
entero,
incluyendo
analistas,
evaluadores,
administradores de proyectos, personal del control de calidad, equipo de
desarrollo y más, por una fracción del costo de algunos productos
30
competitivos. Verifique el rango completo de las herramientas y
características case en detalle.
Enterprise Architect es una herramienta comprensible de diseño y análisis
UML, cubriendo el desarrollo de software desde el paso de los
requerimientos a través de las etapas del análisis, modelos de diseño,
pruebas y mantenimiento. EA es una herramienta multi-usuario, basada
en Windows, diseñada para ayudar a construir software robusto y fácil de
mantener. Ofrece salida de documentación flexible y de alta calidad. El
manual de usuario está disponible en línea.
Velocidad, estabilidad y buen rendimiento
El Lenguaje Unificado de Modelado provee beneficios significativos para
ayudar a construir modelos de sistemas de software rigurosos y donde es
posible mantener la trazabilidad de manera consistente. Enterprise
Architect soporta este proceso en un ambiente fácil de usar, rápido y
flexible. Para una mirada rápida al modelado UML en Enterprise Architect
vea nuestro tutorial UML y documentos.
Trazabilidad de extremo a extremo
Enterprise Architect provee trazabilidad completa desde el análisis de
requerimientos hasta los artefactos de análisis y diseño, a través de la
implementación y el despliegue. Combinados con la ubicación de recursos
31
y tareas incorporados, los equipos de Administradores de Proyectos y
Calidad están equipados con la información que ellos necesitan para
ayudarles a entregar proyectos en tiempo.
Construido sobre las bases de UML 2.1
Las
bases
de
Enterprise
Architect
están
construidas
sobre
la
especificación de UML 2.0 - pero no se detiene ahí! Usa Perfiles UML
para extender el dominio de modelado, mientras que la Validación del
Modelo asegura integridad. Combina Procesos de Negocio, Información y
Flujos de trabajo en un modelo usando nuestras extensiones gratuitas
para BPMN y el perfil Eriksson-Penker.
Soporte para los 13 diagramas de UML 2 y más.
Diagramas Estructurales:
•
Clase
•
Objeto
•
Compuesto
•
Paquete
•
Componente
•
Despliegue
32
Diagramas de Comportamiento:
•
Casos de Uso
•
Comunicación
•
Secuencia
•
Descripción de la Interacción
•
Actividad
•
Estado
•
Tiempo
Extendidos:
•
Análisis (actividad simple)
•
Personalizado (para requisitos, cambios, UI)
EA le ayuda a administrar la complejidad con herramientas para rastrear
las dependencias, soporte para modelos muy grandes, control de
versiones con proveedores CVS o SCC, Líneas Base por cada punto del
tiempo, la utilidad de comparar (diff) para seguir los cambios del modelo,
interfaz intuitiva y de alto rendimiento con vista de proyecto como un
"explorador".
33
Provee una generación poderosa de documentos y herramientas de
reporte con un editor de plantilla completo WYSIWYG. Genera reportes
detallados y complejos de EA con la información que usted necesita en el
formato que su compañía o cliente demanda.
EA soporta generación e ingeniería inversa de código fuente para muchos
lenguajes populares, incluyendo C++, C#, Java, Delphi, VB.Net, Visual
Basic y PHP. También hay Add-ins gratis para CORBA y Python
disponibles. Con un editor de código fuente con "resaltador de sintaxis"
incorporado, EA le permite navegar y explorar su modelo de código fuente
en el mismo ambiente. Para aquellos que trabajan en Eclipse o Visual
Studio.Net, Sparx Systems también vende puentes livianos para estas
IDE's, permitiéndole modelar en EA y saltar directamente al código fuente
en su editor preferido. Las plantillas de generación de código le permiten
personalizar el código fuente generado a las especificaciones de su
compañía.
EA le ayuda a visualizar sus aplicaciones soportando ingeniería inversa
de un amplio rango de lenguajes de desarrollo de software y esquemas
de repositorios de base de datos. Ingrese frameworks completos desde
código fuente o archivos Java.jar - o aún ensambladores binarios .Net!
Importando frameworks y librerías de código, Ud. puede maximizar la reutilización y entendimiento de su inversión existente.
34
EA soporta transformaciones de Arquitectura avanzada dirigida por
Modelos (MDA) usando plantillas de transformaciones de desarrollo y
fáciles de usar. Con transformaciones incorporadas para DDL, C#, Java,
EJB y XSD, Ud. puede rápidamente desarrollar soluciones complejas
desde los simples "modelos independientes de plataforma" (MIP) que son
el objetivo en "modelos específicos de plataforma" (MEP). Un MIP se
puede usar para generar y sincronizar múltiples MIP's - proveyendo un
aumento de productividad significativo.
Características Principales
Diseño y construcción de UML. Casos de Uso, Modelos Lógico, Dinámico
y Físico. Extensiones personalizadas para modelado de procesos y más.
Documentación de alta calidad compatible con MS Word. Intuitivo y simple
de usar. Bajo costo de Licencias. Modelado de Datos, Ingeniería directa
de Base de Datos a DDL e ingeniería inversa de Base de Datos desde
ODBC.
Multi-usuario
Corporativa). Ingeniería
(solamente
de
Código
para
ediciones
Directa
e
Profesional
Inversa
y
(ediciones
Corporativa y Profesional solamente) - Soporte para ActionScript 2.0,
Java, C#, C++, VB.Net, Delphi, Visual Basic, Python y PHP. Facilidad de
Importación/Exportación XMI. Corrector Ortográfico.
35
2.5 Requisitos de Sistema para Enterprise Architect
Versión de Windows
-
Procesador Intel® Pentium® (o mejor)
-
Microsoft® Windows 98 SE, Windows NT® 4.0 con Service Pack 5,
Windows 2000, Windows XP o Windows 2003
-
128 MB de RAM (256MB o más)
-
Espacio en disco disponible de 70 MB
-
800*600 (1024x768 o más)
Versión de Linux
-
Procesador Intel® Pentium II® (o un equivalente)
-
Sistema Operativo Linux (kernel 2.4 o posterior)
-
64 MB de RAM (128 MB o más)
-
Espacio en disco disponible de 70 MB
-
800*600 (1024*768 o más)
Soporte de Base de Datos para la edición Corporativa
-
SQL Server
-
MySQL
-
Oracle 9i and 10g
-
PostgreSQL
-
MSDE
-
Adaptive Server
-
MS Access
36
CAPÍTULO 3
3.1 Caso Aplicativo
Debido a la inexistencia de una metodología definida para la ingeniería
inversa
de software y en base a investigaciones realizadas sobre este
tema, se propone una metodología
que
ayude
al
proceso
de
ingeniería inversa en la recuperación de la documentación.
Mencionando además que la metodología está enfocada a la parte
conceptual, la cual será la que seguirá al proceso especificado en la
siguiente figura.
Figura del código fuente hacia el modelo conceptual
37
El código fuente es sometido a un análisis sintáctico a través del cual se
obtiene un modelo de código fuente intermedio, el cual es comparado con un
conjunto de modelos (usando para esto patrones de diseño) y dando como
resultado un modelo conceptual.
La metodología propuesta esta compuesta de las siguientes etapas:
1.
Estudio del sistema existente
Una técnica que ayudara al entendimiento del sistema será: la
entrevista.
2.
Recuperación arquitectónica
Para llevar a cabo esta etapa se utilizará el enfoque basado en 5 vistas,
cada vista servirá para recuperar cierta información de diseño. Entre
las tareas de esta fase tenemos:
2.1.
Identificación de las tareas funcionales del sistema.
•
Diagrama de casos de uso
2.2.
Recuperación de la vista de diseño
•
Utilización de una herramienta CASE
2.3.
Representación de la interacción entre los objetos
38
•
Diagrama de Secuencia y Colaboración
2.4.
Identificación de componentes de software
•
Diagrama de componentes
2.5
Identificación de componentes para el despliegue
•
Diagrama de despliegue
3.
Documentación de tareas y funciones del sistema.
Como caso de estudio, la metodología se aplica a un sistema de
reservación de hoteles y mantenimiento de agencias de viaje
(TravelPlus).
3.1. Estudio del sistema existente
Lo que se pretende en esta etapa, es lograr un entendimiento general de la
funcionalidad del sistema, antes de que éste sea sometido al proceso de
ingeniería inversa.
El equipo encargado del proceso de ingeniería inversa deberá contactarse con
analistas funcionales, arquitectos de sistema, ingenieros de software y/o con
los
usuarios,
tal
que
puedan
explicar
las
tareas
del
sistema
(funcionamiento, desarrollo, implementación, etc.).
Como técnica para poder comprender el funcionamiento del sistema hemos
39
seleccionado las entrevistas.
Tipos de entrevista:
•
Entrevistas
cerradas: se
buscan
respuestas
a
un
conjunto
de
preguntas predefinidas.
•
Entrevistas abiertas: no hay agenda predefinida, se realiza un dialogo de
manera abierta
Para el caso de estudio luego de entrevistar a los implicados se puede definir
lo que hace el sistema a grandes rasgos.
TravelSys es una empresa que ofrece el inventario de una serie de hoteles a
nivel del mundo a agencias de viajes, a través de su sistema TravelPlus. El
negocio esta en la comisión que TravelSys cobra a cada agencia por cada
reservación que estos realizan.
Los viajeros o incluso otras agencias de viajes pueden hacer reservaciones
directamente en línea, por teléfono, o enviando una solicitud por correo
electrónico.
El operador buscara el hotel conveniente haciendo una búsqueda con las
características que el viajero desee.
Se ingresara los datos de los ocupantes de las habitaciones y finalmente se
generará un código de reservación.
40
El Administrador del sistema tendrá la capacidad de poder crear nuevas
agencias que quieran trabajar con TravelSys y cancelarlos, también podrá
crear usuarios y hacer mantenimiento.
Las interfaces pueden ayudar mucho al entendimiento de las tareas, a
continuación se muestran alguna de ellas:
Pantalla de Ingreso al Sistema Travel
Pantalla de Listado de Agencias y Usuarios
41
Pantalla de Modificación de datos de una Agencia
42
Pantalla de Búsqueda de Hoteles
Pantalla de Hoteles encontrados
43
Pantalla de Detalle de Hotel
I
n
g
r
e
s
o
d
Datos de la reservación
44
Pantalla de constancia de reservación
45
3.2
Recuperación Arquitectónica
El uso de la ingeniería inversa para reconstruir los aspectos arquitectónicos del
software
puede
referenciarse
como
redocumentación
estructural
o
recuperación arquitectónica. Como resultado, se deriva la visión global del
sistema de interés y se pueden recapturar algunos aspectos de su diseño
arquitectónico.
Se presenta un enfoque de arquitectura de sistemas basado en vistas.
Estas vistas muestran los diferentes aspectos del sistema que son
modelados.
Descripción del modelo desde 5 vistas
Cada una de estas vistas servirá para realizar una tarea específica, para la
descripción del contenido de cada una de estas vistas usaremos los
diagramas. El estándar que hemos adoptado es el UML (Lenguaje de
46
Modelamiento Unificado) ya que proporciona un amplio conjunto de
diagramas que normalmente se usan en pequeños subconjuntos para poder
representar las cinco vistas principales de la arquitectura de un sistema.
El cuadro adjunto relacionamos las tareas, la vista y los diagramas que
Utilizaremos en cada uno de ellos.
Tarea
1.Identificación de requerimientos
Vista
Diagrama
Casos de uso
Casos de uso
Diseño
Clases
Procesos
Secuencia
Funcionales
2. Recuperación del diagrama de
Clases
3. Representación de la interacción
colaboración
entre los objetos
4. Identificación de componentes de
Implementación
Componentes
Software
5. Identificación de componentes para Despliegue
el despliegue
Despliegue
47
Identificación de requerimientos funcionales
Luego de conocer en mayor detalle el sistema, los diagramas de caso de
uso nos ayudaran a realizar esta tarea. En la ingeniería directa, el análisis
se enfoca en la funcionalidad y luego el diseño agrega los detalles
específicos de la implementación y los aspectos relacionados con los
requerimientos no funcionales. En la ingeniería inversa, todos los detalles
de diseño e implementaron ya están definidos, de esta manera el límite
entre el análisis y el diseño es bastante difuso.
En la ingeniería inversa, los casos de uso permiten descubrir y describir, en
un alto nivel, que hace el sistema desde el punto de vista del usuario. En
esta actividad, no interesa como hará algo el sistema.
3.3 Aplicación de ingeniería inversa en casos de uso:
a. Identificar cada actor que interactúa con el sistema.
b. Para cada actor, considerar la manera en la cual el interactúa con el
sistema, cambia el estado del sistema o su medio ambiente, o responde a
algún evento.
c.
Trazar el flujo de eventos en el sistema ejecutable relativo a cada
actor. Iniciar con flujos primarios y después considerar rutas alternativas.
d. Agrupar flujos declarando su correspondiente caso de uso.
e.
Proporcionar estos actores y casos de uso en un diagrama de casos
de uso, y establecer sus relaciones.
48
Entre los requisitos funcionales pertenecientes al sistema TravelPlus se
identificaron:
Actores
Los actores del sistema fueron identificados como:
*
Administrador: Es la persona que utiliza la parte administrativa y de
mantenimiento de tablas como Agencia y Usuarios
•
Usuario: Es la persona que utiliza el sistema de reservaciones.
•
Cliente:
*
Casos de Uso
Persona
Basados en los
que
solicita
una
reservación
actores y la funcionalidad
de
habitaciones
del sistema fueron
identificados los siguientes paquetes que agrupan casos de uso
relacionados:
• Gestión de Agencias de Viaje: Agrupa funcionalidades relacionada a la
agencias de viaje como son: Ingresar, modificar y eliminar.
• Gestión
de
usuarios:
Agrupa
funcionalidades
relacionada
a
la
administración de usuarios del sistema como son: Ingresar, modificar y
eliminar.
• Reservación de Hoteles: Agrupa funcionalidades relacionados al proceso
de reservación las cuales empiezan en la solicitud de reservación por
parte del cliente, el registro del mismo, hacer, consultar o cancelar una
49
reservación.
Los casos de uso identificados:
• Ingresar Agencia: este
caso de uso
es iniciado por
el
administrador,
consiste en crear una nueva agencia de viaje al sistema.
• Modificar
Agencia:
este
caso
de
uso
es
iniciado
por el
administrador, consiste en modificar datos de una agencia de viaje para
lo cual primero debe hacer una búsqueda de la agencia.
• Eliminar Agencia: este caso de uso es
iniciado
por
el
administrador,
consiste en cambiar el estado de una agencia de viaje siempre en cuando
esta no cumpla con el pago para lo cual primero debe hacer una búsqueda de
la agencia.
• Búsqueda Agencia: P ro po rcion a la capacidad de buscar una agencia.
• Ingresar Usuario: este
caso de uso es iniciado
consiste en crear un nuevo
• Modificar
Usuario:
este
usuario
caso
por
el
administrador,
que interactuara con el sistema.
de
uso
es
iniciado
por el
administrador, consiste en modificar los datos de un usuario del sistema
para lo cual primero debe hacer una búsqueda del usuario.
• Eliminar Usuario: este
caso
de
uso
es iniciado
por
el
administrador, consiste en eliminar un usuario del sistema para lo cual primero
50
debe hacer una búsqueda del usuario.
• Búsqueda Usuario: proporciona la capacidad de buscar un usuario.
• Registrar Cliente: este caso es iniciado por el usuario, consiste en registrar a
un nuevo cliente al sistema, previo a esto debe registrar la tarjeta de
crédito del cliente.
• Registrar Tarjeta: Proporciona la capacidad de registrar la tarjeta de crédito
del cliente.
• Solicitar Reservación: este caso es iniciado por el cliente, consiste en solicitar
una reservación de habitaciones, entre los datos de la reservación tenemos:
fecha, numero de cuartos, numero de niños por cuarto, etc.
Hacer Reservación: este caso es iniciado por el usuario, consiste en registrar
la reservación en el sistema de acuerdo a la solicitud del cliente.
• Consultar Información: este caso de uso es iniciado por el usuario,
consiste en consultar información relacionada a la reservación.
• Cancelar Reservación: este caso de uso es iniciado por el usuario,
consiste en cancelar la reservación a petición del cliente.
Todos estos casos de uso han sido implementados en el sistema. Estas
funcionalidades identificadas han sido modeladas usando la herramienta case
Rational Rose .
51
3.4 Recuperación del diagrama de clases
La vista de diseño soporta principalmente los requisitos funcionales del
sistema, o sea, los servicios que el sistema debe proporcionar. Es en esta
vista donde se obtiene una visión global del funcionamiento del sistema. Se
establecen los primeros requisitos funcionales en base a lo que se espera
conseguir. En esta etapa se identifican, dentro del código, las clases que
realizan o soportan las acciones descritas en los casos de uso. Para la
recuperación de los diagramas de clases haremos uso de una herramienta
case.
52
Diagrama de Clases de la capa de negocios
53
Diagrama de Clases de la capa de negocios
54
3.5 Identificación de componentes de software
La Vista de implementación describe la organización estática de los
módulos de software (código fuente, componentes, ejecutables) en el
ambiente de desarrollo en términos de paquetes, de capas y de la
administración de la configuración. Esta vista puntualiza una correspondencia
entre los elementos de la vista de diseño y las entidades físicas que
encapsulan su implementación.
Así mismo, también se indican las características físicas de los componentes,
tales
como:
memoria
requerida,
nombre
con
el
que
se registra el
componente en el sistema, versión y modelo del componente, tiempo de
servicio de cada operación, necesarios para realizar la evaluación de la
arquitectura.
55
Los aspectos capturados para el sistema TravelPlus:
TravelPlusUI.dll
TravelPlus Bl. dll
Travel Plus Be
TravelPlus DAL.dll
Identificación de componentes para el despliegue
La vista de despliegue de un sistema contiene los nodos que forman
la topología hardware sobre la que se ejecuta el sistema. Se
preocupa principalmente de la distribución, entrega e instalación de
las partes que constituyen el sistema.
Los aspectos estáticos de esta vista se representan mediante
los
diagramas de despliegue y los aspectos dinámicos con diagramas
de interacción, estados y actividades.
56
En esta vista se representan las características técnicas de cada uno de
los nodos (hosts, en la terminología TCP/IP) del sistema sobre el
que se ejecutara la aplicación, y la asignación de cada componente
físico a un nodo.
Describe la puesta en marcha, la instalación y el rendimiento del sistema.
3.6 Ingeniería Inversa basada en diseño de patrones
Una visión general de un ambiente de ingeniería inversa basado en la
descripción de diseño de patrones definidos por Gamma.
El propósito es introducir la ingeniería inversa basada en patrones como
una técnica de valor para comprender el software y así refutar la
sostenida creencia que el diseño de patrones únicamente es importante
durante la ingeniería directa.
El propósito del ambiente SPOOL (características deseables que
se separan en el diseño de orientado a objeto) de ingeniería inversa es
ayudar a entender el software de las organizaciones a través de
patrones.
Esto consiste de técnicas y herramientas para la captura del código
fuente, un repositorio de diseño y la funcionalidad de recuperación de
patrones de diseño y representación de diseños.
57
Visión general del ambiente SPOOL
1. Captura del código fuente
El propósito de la captura del código fuente es extraer un modelo
inicial desde el código fuente existente. Usando GEN++, el analizador
del código fuente
C++,
el
ambiente
generara
representaciones
basadas en código ASCII de elementos importantes de código fuente
(UML/CDIF
Modelador
fuente
intermedio),
el
propósito
de
la
representación intermedia es hacer el ambiente independiente de algún
lenguaje de programación especifico.
58
2. Repositorio de diseño
El
propósito
del
repositorio
de
diseño
es
proveer
un
almacenamiento centralizado, manipulación y consultas de los modelos
del
código
fuente,
los
componentes
del
diseño
abstracto
son
recuperados y los componentes del diseño recuperados dentro de los
modelos del código fuente.
El esquema del repositorio de diseño está basado en el extendido UML
metamodelo 1.1; Poet 5.1 sirve como un repositorio final para administrar
base datos orientado a objetos. El esquema es representado como clases
jerárquicas Java 1.1
3. Recuperación de diseño basado en patrones
El propósito de la recuperación del diseño basado en patrones es ayudar
a estructurar partes del diagrama de clases para armar diagramas
de patrones. Son tres las técnicas:
 Recuperación
estructuración
de
diseño
Automática,
completamente
automatizada
software acorde con la descripción
de
los
relaciona
de
diseño
patrones,
la
de
los
cuales son almacenados en repositorios como componentes de
diseño abstracto.
59

Recuperación de diseño Manual, relaciona la estructuración
de diseño de software agrupando manualmente elementos de
diseño, como clases, métodos, atributos o relaciones para reflejar
un patrón.

Recuperación de diseño
estrategias,
la
Semiautomática
automática
y
la
combina
manual.
Esto
ambas
puede
ser
implementado como una recuperación de procesos multifases.
La primera fase consiste de detección automática de bajos
niveles de idiomas o núcleo general de patrones de diseño, las
fases siguientes relacionan las
instancias
identificadas
con
detalles de implementación mas especifico.
4. Representación de diseño
El propósito de la recuperación de diseño es proveer la
visualización interactiva y el refinamiento de los modelos de código
fuente, abstracción de componentes de diseño y los componentes
implementados.
60
61
CONCLUSIONES
1.
La ingeniería inversa es un proceso de exanimación y no
involucra cambiar el sistema, es considerada como un subproceso
de la reingeniería, al cual si implica la modificación del sistema.
2.
La ingeniería inversa puede extraer información de diseño del
código fuente
pero el
nivel de abstracción, la completitud de la
documentación, el grado con el cual trabajan al mismo tiempo las
herramientas y el analista humano, y la direccionabilidad del proceso
son sumamente variables.
3. La necesidad de la ingeniería inversa emerge de problemas
operacionales reales en el actual sistema como por ejemplo errores
debido a la mala calidad de software, al alto costo del mantenimiento
debido a la carencia de documentación y a nuevos requerimientos de
los usuarios.
62
RECOMENDACIONES
1. El equipo de trabajo que se encargue de realizar el proceso
de ingeniería inversa debería estar integrado por miembros que
conozcan la lógica del negocio y que tengan conocimiento del
diseño de patrones.
2.
La
ingeniería
inversa solo
se
debe
aplicar a
empresas
grandes, cambiantes.
63
REFERENCIAS BIBLIOGRÁFICAS
www.monografias.com
www.rational.com
es.wikipedia.org
http://alarcos.inf-cr.uclm.es/per/fruiz/cur/mso/trans/s1.pdf
www.taringa.net
www.google.com
64

INTRODUCCIÓN - DSpace de la Universidad Catolica de Cuenca

Transcripción

Documentos relacionados

PORTADA e INTERIOR portada 04