Centro Nacional de Investigación y Desarrollo ... - CENIDET · 2.1.2 Reestructura de código...
Transcript of Centro Nacional de Investigación y Desarrollo ... - CENIDET · 2.1.2 Reestructura de código...
-
SEP SElT DGlT
Centro Nacional de Investigación
y Desarrollo Tecnológico
cenidet
FACTORIZACIÓN DE FUNCIONES HACIA MÉTODOS DE PLANTILLA
TESIS Que para obtener el grado de
Maestro en Ciencias en Ciencias Computacionalec
Presenta
Laura Alicia Hernández Moreno
Director de la tesis: M.C. René Santaolaya Salgado
Co-Director de la tesis: -0 3 - o o 1 8 ..-
Cuernavaca, Morelos Febrero del 2003
-
SEP SElT DGlT
Centro Nacional de Investigación y Desarrollo Tecnológico
cenidet FACTORIZACIÓN DE FUNCIONES HACIA
MÉTODOS DE PLANTILLA*
TESIS Que para obtener el grado de
Maestro en Ciencias en Ciencias Computacionales
Presenta
Laura Alicia Hernández Moreno
Director de la tesis:
M.C. René Santaolaya Salgado
Co-Director de la tesis: M.C. Olivia G. Fragoso Diaz
Cuernavaca, Morelos Febrero del 2003 ~
'"Esta tesis es parte del proyecto No. 32042-A "Sistema de Administración de Componentes de Software Basado en Frameworks" financiado por CONACYT. y el proyecto No. 450.01-P "SR2: Sistema de Reingenieria para Reuso" financiado por COSNET.
-
Cuemavaca, Mor., a 17 de Febrero de 2003.
Dr. Gerard0 Reyes Salgado Presidente de fa Academia de Cienciac €ompuia&nales Presente
Nos es @o eomuntmrle, que confamie a los Iineamientas pafala obtenctón det grado de Maestro en Ciencias de este centro, y después de haber sometido a revisión académica la tesis denominada. "FACTOREACIÓN DE FUNCK)NES HACiA WrÉroDOS DE PLANTILLA", Barizada por h C. Laura Alicia Hemández Maceno, y habiendo cumplido con todas las correcCones que le fueron indicadas, acordamos no tener objeción para que se le conceda la autorización de impresión de la tesis
Sin otro partidar, quedamos de usted.
Atentamente-
La comisión de revisión de tesis
I4 6u.iL-0- . M C MARIO GUtLLEN RODRIGUEZ M C. REYNALDO ALANIS CANTU
Director De Tesis
M C OLiVlA FRA-GOSO EIAZ Co-director de tesis
C.C.P. Dr. Rodolfo A. Pazos RangeüJefe del Depto. de Ciencjas Computgcionates
INTERIOR INTERNADO PALMIRA S/N. COL, PALMIRA , A.P. 5-164. CP. 62490, CUERNAVACA, MOR. - M t X I C O TELS. 1777) 312 23 14.318 77 41. FAX (777) 312 24 34 EMAIL [email protected]
-
FORMA C4 AUTOREACION DE IMPRESIÓN DE TESIS
Cuernavaca, Mor., a 17 &Febrerode 2003
C. Laura Alicia Hemández Moreno Candidato al grado de Maestro en CmQas en Ciencias Computacionales Presente
Después de haber atendido las indicaciones sugeridas por la Comisión Revisora de la Academia Ciencias Computacionales en relación a su trabajo de tesis: "FACTORIZACION DE FUNCIONES HACIA METODOS DE PLANTILLA"., me es grato m i c a r i e , que conforme- a los linearnientos establecidos para la obtención del grado de Maestro en Ciencias en este Centro, se le concede la autorización para que proceda amla it-ftpr- de su tesis.
Atentamente
Dr. Rodoifo &ham PAos Rangel Jefe del üepto. de Ciencias ComputacEonaies
INTERIOR INTERNADO PALMIRA S/N, COL, PALMIRA . A.P. 5-164. CP. 62490, CUERNAVACA. MOR. - MEXICO TELS. (777) 312 23 14.318 77 41, FAX (777) 3F2 24 34 EMAlL [email protected]
-
W u y cerca de mi ocaso yo fe bendgo, Vida,
porque nunca me &fe ni esperanza fallda
ni lrabajos iymtos, ni pena inmerecida.
Torque oeo al jnal ¿e mi largo camino
que f i i yo el arquifecfo de mi propio des fino
que si extraje la miel o la hiel de los cosas
' fue porque en ella puse hiel o mieles sabrosas;
cuando plan fé rosales. coseché siempre rosa2
cieno, a mis lozanias DB a seguir el inoiemo
i3a?tis iú no me @de que mayo fuera eferno!
%alle sin duda largas las noches de mis penas
mcis no me promer'ísfe fu, solo noches buenas
y en cambio fuoe algunas sanfamenfe serenm
Smé. fui amado, el sol acaricio mi faz
j Vida, nada me debes. oída, esfarnos en paz!
%nado Weroo
&iura a;5cia pemrjndez Woreno
Febrero ¿el 2003
-
9 9ios por darme Is dicha de oioir y
permiiime dia a dio dar un nueoo paso.
mi madre por ser iodo para mí por todo lo que hemos oioido y pasado junim
3aluchas gracias mamá.
T e Quiero %ucho.
9 dos personas especiales que siempre esiarán en mi corazón.. CraciaJ
3ali abuelo Ymnenegildo'
q o n WanueP
8uan 5;8bnd mi nooio, por miar iodo este tiempo a mi lado incondcionahenfe
y por ser la persona con quien quiero compadir el resto ¿e mi oida. T e 9mo.
-
5i&p¿ecirníen fos
9 C&J%&(Tpor aceptarme como becan0 dentro de su programa “C8pacifación ¿e jODenes hacia el posgrado
9 C & W C i ) & T p o r abrirme sus puerta
a diloia &¡no ‘Tuenlar que sin conocerme inicia/mente, me ha dado su conjanza y R quien considero mi amiga
9 mis drectoras de tesis el %C %ne c
-
1
Índice
índice de Tablas ...........................................................................................
lndice de Figuras ........................................................................................................
Capítulo 1. INTRODUCCION ...................................................................................... 1 .I Descripcion del problema .__.___........ ... .......................................... 1.2 SR2: Reingeniería de software legado par
. .,
1.2.1 Objetivo ... 1.2.2 Modelo de referencia ...
1.2.2.1 Proceso de análisis 1.2.2.2 Proceso de reestructura del código original _....,.____._......._.____.... 1.2.2.3 Proceso de refactorización .................................................
1.3 Objetivo de la tesis ................................................................................................. 1.4 Beneficios de la tesis .... 1.5 Justificacion del estudio ............................................................................... 1.6 Límites y alcances del estudio. 1.7 Organización de esta tesis ._...._..._.._.._,.._____....
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . , . . . . . . . . . , . . . ..
. . . . . , . . . . . . . . . . . . . , . . . . . . . . , . . , . . . . , . . , . . . . . . . . , , . . . . , . . . . . . . , . . . . . . . . . . . . . . . . .
-
.. II
2.1.7 SPRUCE: Un framework para reestructurar software ............................. 24
2.2 Análisis comparativo de los trabajos relacionados con respecto a esta tesis ............................................................................................................... 26
Capítulo 3. MARCO TEORICO .................................................................................. 3.1 Factorización ........................ 3.2 Programación por procedimientos en lenguaje C .............
3.3 Análisis e ingeniería de dominios .......................................
. . . . . . . . . . . , , . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.7 Software legado _._._ . . . . . . . . . . . . . . . . . . , . . . . , , . . 3.4 Patrones de diseño .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . , . . . . . . . . . . . . . . .
3.4.1 Template Method ......................................................................................... 3.4.2 Factory Method .....,. . . . . . . . . . . . . . . , . . . . . . . . . . . . , . 3.4.3 Decorator
3.5 Arquitectura de software basada en componentes _..__...._........._._._ 3.5.1 Programación orient
3.5.2 Reuso de
3.5.3 Componente _.___....,. 3.5.4 Framework o marco de componentes reusables ._..,.,.
3.6 Meta-Lenguaje ANTLR .........
3.5.1.1 Lenguaje de programación C++
Capítulo 4. DESCRIPCIÓN DE LOS MÉTODOS DESARROLLADOS ...................... 4.1 Proceso de análisis de código fuente ._._....__.._.___..,.___..... . . . . . . . . . . , . . . . . . . . . . . . . .
4.1 .I Identificación de operaciones y atributos ...__..__.__......___._. 4.1.1.1 Tipos de datos estructurados.. . . . . . . . . . , , . , . . . . . . . . . . . . 4.1 .I .2 Variables o datos globale 4.1.1.3 Funciones.
4.1.2 Identificación de relaciones ____._....,....____.._...... 4.1.2.1 Funciones - Datos Globales 4.1.2.2 Datos locales por función ..................................................... 4.1.2.3 Funciones - Parámetros ..........
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . , , . . . .
. . . . . . . . . . . . . . . . . . . . . . . 4.2 Proceso de reestructura de software le
33
34
34
36
38
38
43
47
51
54
55
57
58
58
59
60
61
62
66
67 69
71
73
73
75
77
79
-
... 111
4.2.1 Método de creación de clases ...... ......................................
4.2.1.1 Conversión de tipos de datos estructurados a clases de objetos ................................. ....
4.2.1.2 Conversión de datos globales a clases de objetos ................... 4.2.1.3 Conversión de funciones a clases de objetos ...........................
4.2.2 Método de declaración de constructores ............. ............................. 4.2.3 Método de composición de clases .......................................................... 4.2.4 Método de reubicación de funciones ...................................................... 4.2.5 Método de fragmentación de funciones .................................................. 4.2.6 Método de superjerarquizar .... ........... ................. 4.2.7 Método de fábrica de objetos ..........................................................
4.3 Diagrama de clases que integran hasta ahora el sistema SR2 ........................... 4.4 Diagrama de clases que componen al proceso de reestructura ....
79
80 84 86 88 90 92 94 95 98
102 103
Capítulo 5 . CONCLUSIONES .................................................................................. 5.1 Trabajos futuros .................................................................................................... 108
105
Bibliografia ................................................................................................................. 115 Anexos ........................................................................................................................ 119
-
iv
Índice de Figuras
Figura 1.1. Estructura de un programa ejemplo escrito bajo el paradigma de procedimientos .................................. ..
-
Figura 4.10. Estructura de clases que se tienen cuando se identifican
datos candidatos a aplicar el método de superjerarquizar ............._... 97 Figura 4.11. Representación tipica de una fábrica de objetos obtenida
a partir de la figura 4.2 .................................................................... 101
-
vi
índice de Tablas
Tabla 2.1. Tabla comparativa de los trabajos relacionados contra esta tesis .............. Tabla 3.1. Categorias en las que se dividen los patrones de diseño ...........................
Tabla 4.1 Estructura de la tabla UDTs .................................................................
Tabla 4.2 Estructura de la tabla UDTxCC ....................................................................
Tabla 4.3 Estructura de la tabla DGs ...........................................................................
Tabla 4.4 Estructura de la tabla Fs ...............................................................................
Tabla 4.5 Estructura de la tabla FFxDG ...................................................................
Tabla 4.6 Estructura de la tabla FFxUDTxCC ...........................................................
Tabla 4.7 Estructura de la tabla DLs ..........................................................................
Tabla 4.8 Estructura de la tabla ParF ...........................................................................
Tabla 5.1. Diseño de una tabla de información que puede ser de
utilidad para aplicar la fragmentación ..........................................................
32
42
68
68
70
72
74
74
76
78
110
-
Cauítulo 1 introducción
traves del tiempo nos hemos dado cuenta que la complejidad de los sistemas informáticos ha aumentado en forma impresionante, hasta el punto que el hecho de
dar mantenimiento a estos sistemas es muy difícil y en muchos casos hasta imposible; esto dio comienzo a la crisis del software [PRE93]. Esta crisis se debe principalmente a la
acumulación de productos desarrollados que no son reusados, a los altos costos de
mantenimiento que implican los sistemas y a los costos de invención de nuevas
aplicaciones
Laura Alicia Hernández Moreno
A . ' .
1 Cenidet 2003
-
Capítulo 1 introducción
I¡
De acuerdo a nuestra experiencia por haber laborado en una de las fábricas de
software de México[SOFWW] e información preliminar[MCC94, MCC94b, MCC951, las
diversas empresas que producen software en nuestro país y en otros países, empezaron
con el desarrollo de sistemas pequeños. Algunas.empresas han desertado y las que aún
permanecen con el tiempo ha crecido su número de clientes y la complejidad de sus
sistemas, lo cual ha venido .obligando a la adopción de procesos de desarrollo más o
menos formales por parte de las diversas empresas. C ello, cada empresa adoptó los
procesos de desarrollo basandose en su experiencia y en sus necesidades. La forma de los ciclos de desarrollo de sistemas obedecía más bien a la naturaleza de los clientes, al nicho del mercado y al tamaño de los sistemas, pero no a un proceso de desarrollo estandarizado que garantizara la confiabilidad o el éxito en los productos emitidos.
!I
11 . ’
Los paradigmas para la construcción de software como una herramienta dentro de la ingeniería de software se han venido considerando como la solución al así llamado
“problema de software” o “crisis del software’’ [UDE94] que aun permanece con nosotros.
“Durante muchos años se ha visto al reuso como una de las técnicas más
importante para,dar solución al problema de costo’y esfuerzo que radica en el desarrollo y
administración .. de los sistemas de información. El término reuso se ha tratado de frabajar
en conjunto concada uno de los paradigmas de programación que han ido apareciendo. Sin embargo, en la actualidad no se ha logrado establecer en totalidad que la producción
de sistemas de información se haga bajo una política de reuso, como un modelo de
reingenieria” [SANOZ]. “Hoy en dia, han emergido nuevas tecnologías como: el análisis e ingeniería de
dominios; herramientas CASE; modelos de referencia para el ciclo de vida del software, modelos de arquitecturas de software sustentadas en tecnologías de análisis, diserio y programación orientada a objetos; patrones de diseño; y marcos de componentes de software para reuso. Como se puede observar las tecnologías mencionadas ofrecen
soporte para dar un nuevo impulso al desarrollo de herramientas que apoyen al reuso”
#,
[SANOZ]. ‘i “Para agregar madurez al proceso de desarrollo de sistemas [AHRSS], una meta
actual de la lngenieria de Soffware es la de otorgar facilidades en los procesos por medio de la adopción de ambientes de desarrollo que integren herramientas automatizadas, visuales e interactivas, para construir, entender, mantener y documentar el software,
2 Laura Alicia Hernández Moreno Cenidet 2003
-
Capítulo 1 introducción
conduciendo a una mejor calidad y contabilidad de los servicios de cómputo, así como a
una más grande satisfacción de/ cliente” [SAN02]. En esta tesis se presenta una estrategia base, que parte de la reingenieria inicial
de código que ha sido desarrollado y que aun sobrevive en algunas empresas. La
estrategia se basa en la ampliación de su tiempo de vida útil, por medio de su recuperación y transformación, a través de un proceso de reestructura. El desarrollo que
aqui se presenta toma código legado escrito bajo el modelo de procedimientos en
lenguaje de programación C y lo transforma en arquitecturas de componentes reusables
para aplicaciones orientadas a objetos escritos en lenguaje de programación C++. Cada vez es más frecuente que la arquitectura que exhibe un marco de este tipo
incorpore patrones de diseño en su estructura. Por lo que el enfoque que se le da a esta tesis es la de incorporar patrones de diseño a la arquitectura del código resultante del
proceso de reingenieria de software legado para reuso.
1 .I Descripción del problema Construir marcos de componentes reusables de dominios específicos a partir del
software legado, mediante procesos de ingeniería inversa y10 reingenieria, puede resultar
una estrategia aceptable. Sin embargo, a la fecha, relativamente poco esfuerzo se h a
invertido en trabajos de investigación enfocados a buscar formas para extender el tiempo
de vida útil de a plicaciones I egadas existentes. Por I o q ue, aún n o e xisten sistemas o
herramientas a decuadas q ue permitan transformar I a a rquitectura d e sistemas legados instrumentados en lenguajes de procedimientos, hacia arquitecturas o marcos reusables de aplicaciones orientadas a objetos, que permitan la maduración de dominios
especificoc de aplicaciones.
En apoyo a la solución de este problema, en el CENIDET se está desarrollando una herramienta conocida como SR2 (Reingenieria de Software Legado para Reuso), que
permite transformar código legado por procedimientos a marcos de componentes
reusables. con el objetivo de poder reusar el software existente de dominios de
aplicaciones en nuevos desarrollos de software del mismo dominio (Véase sección 1.2).
Una de las etapas iniciales de la herramienta mencionada en el párrafo anterior consiste en el análisis del código fuente escrito en lenguaje C y en la identificación y
3 Laura Alicia Hernández Moreno Cenidet 2003
-
Capítulo 1 ' Introducción
extracción de la información necesaria que sirva para construir frameworks de dominios
de aplicación orientados a objetos.
En general el SR2, incorpora los procesos'ide preprocesamiento, análisis de código fuente, reestructura a través de patrones de diseño (State, Strategy), reestructura de
datos (variables y funciones) y un proceso de refactorización. De los procesos descritos,
en esta tesis se'desarrollo el método de reestructura de datos, el cual ataca el problema
que a continuación se describe.
1
En la figura 1.1, se muestra la estructura de un programa ejemplo escrito bajo el
paradigma de procedimientos, a partir de la cual mostraremos el problema a resolver.
Programa Ejemplo
Variables Globajes: Varl Var2 Var3 Var4
Funciones: F1() /I Accede Varl ,VaR F2() /I Accede Varl ,Var3 F3() /I Accede YaR, Var3 F4() /I Accede Var l a Var4
I
Figura 1 .I. Estructura de un programa ejemplo escrito bajo el paradigma de procedimientos.
'!
Podemos ver en la figura que un programa procedural puede estar compuesto de
variables globales y funciones, en donde las funciones pueden acceder a una, varias o a todas las variables globales dando por consiguiente un nivel de anidamiento que no es
factible si se desea hacer reuso de alguna de las funciones existentes de ese programa o de la aplicación en general.
't
4 Laura Alicia Hernández Moreno Cenidet 2003 ,I
-
CaDítulo 1 Introducción ~~
Una forma rápida en la que se puede pensar para reusar las funciones que existen
en un programa procedural, sería que cada función que este definida en un programa sea
una clase, como se muestra en la figura 1.2.
ClaseFl ClaceF4
Var3 Var4
F40
Figura 1.2. Creación de clases por funciones.
Se puede observar que esta forma no es la más apropiada para obtener una
arquitectura de clases ya que existiría la duplicación de variables en mas de una clase, lo
cual es un factor importante que debe considerarse para su buen funcionamiento, ya que
si una variable fue afectada en su valor al estar en una clase, dicho valor puede ser utilizado en una función subsecuente que se encuentre.
El problema que se resuelve en esta tesis, consiste en reducir en lo mayor posible el nivel de anidamiento que se puede presentar en un programa empleando una herramienta de reestructura de software, que nos permite incorporar datos especificos en
clases especificas. Los métodos de reestructura que componen a la herramienta desarrollada en este trabajo de tesis, se describen detalladamente en el capitulo 4.
1.2 SR2: Reingeniería de software legado para reuso El trabajo de tesis que en este documento se describe tiene su base sobre la
herramienta SR2. En las subceccionec 1.2.1 y 1.2.2 se presentan el objetivo y una descripción breve del modelo de referencia, los cuales fueron planteados por el M.C. René Santaolaya Salgado el cual es candidato a obtener el grado de Doctor en Ciencias
de la Computación por el Centro de Investigación en Computación del Instituto Politécnico
5 Laura Alicia Hernandez Moreno Cenidet 2003
-
Capítulo 1 Introducción
Nacional. Los secciones siguientes fueron estructuradas tomando puntos de referencia de [SAN02]. ' ' II
1.2.1 Objetivo El objetivo de SR2, es organizar el software legado, desarrollado bajo el
paradigma de programación por procedimientos, en lenguaje de programación "C",
para Su reuso en futuras aplicaciones del mismo dominio. Con el propósito de tener
beneficios en cuanto a la productividad de los programadores, de la calidad de los sistemas de software desarrollados y para un mejor enfrentamiento a la complejidad
de los actuales sistemas de software.
El enfoque que se ha dado al proyecto SR2 para el logro de este objetivo, consiste en diseñar y proponer un modelo de referencia que sirva de guia para
cambiar la arquitectura de sistemas existentes, escritos en lenguajes de
procedimientos, hacia una arquitectura orientada a objetos (utilizando C++), y un sistema de reingenieria basado en este modelo, con el propósito de construir marcos
reusables de aplicaciones orientadas a objetos &e dominios.
. < , . li 1.2.2 Modelo de referencia ' . El modelo de referencia de SR2 (Reingenieria de Software Legado para Reuso)
considera tres aspectos importantes (Véase figura 1.3), análisis de código fuente, reestructura del código fuente, y refactorización'del marco de aplicaciones orientado a
objetos obtenido para cada dominio. El sistema de reingeniería (SR2) incorpora tecnologias modernas tales como
reconocimiento de patrones, de código para la fase de análisis, arquitecturas
orientadas a objetos y patrones de diseño para los procesos de reestructura, y refactorización para el control de la evolución y aumento de la vida Útil del software.
II
6 Laura Alicia Hernández Moreno Cenidet 2003
-
Capítulo 1 Introducción
de Dams
(. . L Se hace uso de:
( a Paimnes dediseño 1 2. .
Figura 1.3. Modelo de referencia de SR2 (Reingeniería de Software
Legado para Reuso).
1.2.2.1 Proceso de análisis de código fuente En este proceso se explora el código fuente, en el que se trata de identificar los
siguientes requerimientos:
1. La identificación de atributos y operaciones que sirven de referencia para ia creación de clases de objetos, tales como:
P Identificación de UDTs (tipos de datos estructurados). P DGs (datos globales). P DLs (datos locales).
Laura Alicia Hernández Moreno 7
Cenidet 2003
-
Capítulo I Introducción
P Par (parámetros). 9 Fs (funciones),
P Patrones de comportamiento de los patrones de diseño State y Strategy[GAM95], entre otros.
2. La identificación de relaciones'entre las entidades del sistema, es decir, relaciones de: 9 Agregación o asociación. 9 Generalización-especialización. :/)
I/'
> Creación de instancias. El software desarrollado bajo un enfoque por procedimientos no cuenta de manera
explícita con la información que satisfaga los requerimientos ya mencionados. Sin embargo se parte del supuesto de que esta información existe en los sistemas de manera
implícita. Por lo tanto, este proceso consiste en la extracción de la información necesaria,
la cual es depositada en tablas (diccionario de datos) que la almacenan para su posterior
utilización en la generación de código orientado a objetos.
1 , .
1.2.2.2 Proceso de reestructura del código original Este proceso toma como entrada el diccionario de datos que se obtuvo en el
proceso de análisis de código' fuente y realiza la reestructura del código original,
construyendo una arquitectura orientada a objetos (lenguaje procedural C a lenguaje O0 C++). Esto es, el diseño de la estructura del modelo compuesta por las clases de objetos
y la manera en que éstas se relacionan entre si. Los métodos que componen este proceso son: I. Creación de clases estratégicas.(Toma la estructura del patrón de diseño Strategy) 2. Creación de clases de comportamiento dinámico (Toma la estructura del patrón de
diseño State).
3. Conversión de UDTs a clases.
4. Conversión.de DGs a clases. 5. Conversión de funciones a clases. 6. Conversión de parámetros a clases.
7. Declaración de constructores.
11
.?I
I¡,
8. Reubicación de funciones.
Laura Alicia Hernández Moreno 8
Cenidet 2003 I(
http://Conversi�n.de
-
introducción Capítulo 1
9. Fragmentación de funciones
1 O. Superjerarquizar.
11. Subjerarquizar.
12. Fábrica de objetos.
13. Composición de objetos.
En el siguiente capítulo se hace una descripción detallada de los métodos
desarrollados en este trabajo de tesis y/o algunas sugerencias para el desarrollo de otros
métodos.
1.2.2.3 Proceso de refactorización Utilizando el modelo de clases de la arquitectura o framework del sistema
obtenido y la estructura de los patrones de diseño de Gamma[GAM95], en este
proceso, se proporciona un medio interactivo auxiliado por los métodos de refactorización d e Martin Fowler[FOW99] para que se facilite al usuario o personas
identificadas con el dominio (experto en el dominio, o el experto en software) un
refinamiento del modelo de clases actual, incorporando tópicos del contexto que
influyen en el diseño, así como la mejor manera en la que se relacionan las entidades
de la arquitectura del modelo.
Los cambios al modelo podrán hacerse en nombres de clases, identificadores de variables de instancia o de los métodos, así como posibles cambios en las
relaciones de herencia, agregación o asociación, jerarquización por herencia y composición por delegación.
En este proceso también se buscan similitudes estructurales entre el framework y los patrones de diseño, mediante una máquina de pareo de sus formas canónicas,
con el objeto de evolucionar el modelo de clases buscando las mejores condiciones de
reuso del framework de aplicaciones orientadas a objetos obtenido.
9 Laura Alicia Hernandez Moreno Cenide! 2003
-
Capítulo 1 Introducción
1.3 Objetivo de la tesis Desarrollo de una herramienta de software, que permita realizar de forma
automática la reestructura de código legado escrito en lenguaje C bajo el paradigma de
programación por procedimientos. Dicha reestructura, enfocada hacia los tipos de datos
estructurados, datos globales y las funciones que estos utilizan, obteniendo como
resultado arquitecturas de clases reusables orientadas a objetos.
Para el 'logro de ' este objetivo, en esta tesis consideramos dos procesos
importantes, los cuales son: análisis de código fuehte y reestructura del código fuente (Ver
capítulos 4.1 y 4.2).
1.4 Beneficios de la tesis Para efectos de mantenimiento y para !evolucionar el software legado hacia
esquemas de reuso, la Única fuente confiable de información disponible es su código fuente.
La mayoría de las veces, los sistemks legados cuentan con muy poca
documentación, lo que implica la ausencia de información 'critica de decisiones de diseño. En muchas ocasiones la documentación es confusa o contradictoria y
usualmente i nconsistente con I a instrumentación del código. Esto sucede porque la actualización a l a documentación del software(si es que se actualiza) raramente es -'
congruente con la evolución del código. i/
En consecuencia, antes de intentar la transformación de software hay que tratar
directamente con su código fuente para obtener un entendimiento de su estructura y su comportamiento.
Por lo tanto, la actualización de software desarrollado involucra la extracción
adecuada de información, y en base e Sta i nformación reestructurar e I código hacia plataformas tecnológicas más modernas.
El propósito de transformar software escrito bajo el paradigma de programación por procedimientos hacia arquitecturas de aplicaciones orientadas a objetos no es una
tarea fácil, porque se necesita extraer información desde el código fuente que no se
encuentra expficitamente en él. La complejidad radica en el tipo de información
necesaria para este propósito como aquella que permita encapsular entidades 10
Laura Alicia Hernández Moreno
I
Cenidet 2003
-
Capítulo 1 Introducción
relacionadas del código original, la que permita establecer relaciones de herencia y
asociación entre las diferentes entidades del código, así como de encontrar la forma
de crear instancias de las diferentes entidades del código transformado en relación
directa con el código original.
Así mismo, dentro del contexto de la maduración y evolución de dominios de
aplicaciones, la herramienta permite construir arquitecturas de aplicaciones orientadas
a objetos de dominios, lo que hace posible alcanzar un mayor grado de maduración de
dominios de aplicaciones de manera más rápida, y ahora se podrán desarrollar
incrementalmente, nuevas aplicaciones del dominio, personalizando por extensión,
composición y/o reemplazo, a la arquitectura de aplicaciones orientado a objetos
obtenida como resultado de la aplicación de la herramienta al software legado de
dominios.
A continuación se hace una sintecis de los beneficios que provoca este proceso de reestructura:
La obtención de una arquitectura de clases y de las relaciones entre clases, para
poder generar un nuevo framework, incorporando patrones de diseño que hacen
más factible s u reuso. La ampliación del tiempo de vida y recuperación del valor del software legado.
La reducción del tiempo al realizar la reestructura de una manera automática.
Mejora el diseño del código para que sea más fácil refinar o ampliar el programa [OPD93].
Otros beneficios que se obtienen con el desarrollo y culminación de este proyecto de
tesis, consisten en:
d Dar inicio al proceso de reestructura que forma parte del proyecto SR2 (Reingeniería de Sofhvare Legado para Reuso).
d Abrir caminos a nuevas investigaciones dentro del proyecto SR2.
1 1 Laura Alicia Hernández Moreno Cenidet 2003
-
Capítulo 1 Introducción
iJ
1.5 Justificación del estudio A p e s a r d e q u e e l c o n c e p t o d e r e u s o ~ o e s n u e v o y d e l a gran cantidad de
artículos publicados, que justifican la creación de modelos, métodos, técnicas Y herramientas que ayuden en el proceso de desarrollo, mantenimiento y evolución de
software, de dominios, y la utilización de bFbliotecas de reuso para las nuevas aplicaciones del dominio; dos motivos fueron los que originaron la idea de realizar este
trabajo de tesis.
El primero es que en la actualidad el desarrollo de software se está moviendo
rápidamente de una forma artesanal hacia un proceso de ingeniería y manufactura a
gran escala. Este movimiento está causando una urgente necesidad d e contar con
artefactos reusables de software que cuenten con una mejor calidad y que puedan ser
configurados para dar respuesta a varias aplicaciones ante las necesidades de cambio
con un mínimo de inversión en costo y esfueko. Considerando que la adquisición
comercial de estos componentes reusables desde catálogos especializados por
dominios se ve limitada por su escasa producción para todos los dominios de aplicaciones, y/o adquirirlos a partir de la espekificación de dominios de aplicaciones puede ser riesgoso y caro, y puede llevar muchos años antes de que las funciones de
sistemas disponibles sean reemplazadas por un sistema orientado a objetos confiable y equivalente.
La segunda razón que motivó este trabajo de tesis radica en que con el paso
del fiempo, mucho código, basado en proceüimienios, ha sido desarrollado para
diferentes aplicaciones y dominios de problemas. Ahora, con el advenimiento de
nuevos modelos y tecnologías de desarrollo de software, este código tiende a quedar obsoleto, Todo este software representa una inversión considerable en las organizaciones, el cual se cree que no tiene valor, sin embargo, este código puede ser
legado para la construcción de componentes reusables, lo que puede representar un ahorro considerable en los costos de produc6ión de software, sobre todo cuando
algunos de estos componentes lleguen a ser usados con cierta frecuencia,
amortizando así el costo de su conversión. Por lo tanto, se hace necesario pensar en estrategias para aumentar su tiempo de vida Ctil mediante su recuperación y trarkformación . . en arquitecturas de componenfes reusables [SANOZ].
81
I/
'I
'I
I .
12 Laura Alicia Hernández Moreno Cenidet 2003
-
Caoítulo 1 Introducción
Esta tesis proporciona una estrategia que cubre ambos aspectos, basada en la
reestructura de software legado escrito en lenguaje de programación " C , bajo el modelo de desarrollo por procedimientos, hacia marcos de aplicaciones orientadas a
objetos para reuso. escritos en lenguaje de programación "c++". En relación al tiempo que se invierte en realizar el proceso de reestructura a
través de la herramienta desarrollada en esta tesis, es cuestión de segundos o un par
de minutos dependiendo del tamaño del programa fuente que sirva de entrada. Sin
embargo, en comparativa con llevar a cabo el proceso de reestructura en forma
manual podemos decir que la herramienta desarrollada en esta tesis resulta factible,
ya que el realizar una identificación de los datos que componen al programa de
entrada en forma manual se llevara minutos y posiblemente hasta horas dependiendo del tamaño del programa a reestructurar, además de tener que llevar una relación muy
rigurosa en cuanto a la clasificación de datos y su reubicación correcta de funciones en el archivo o clase que haya sido generado para determinado tipo de dato. En si, el
realizar el proceso en forma manual puede ocasionar equivoco y/o redundancia d e
datos, sin que se puedan dar cuenta fácilmente los encargados de realizar el proceso.
1.6. Límites y alcances del estudio El alcance de este trabajo de tesis, se limita a hacer una reestructura inicial del
código fuente con el propósito de construir arquitecturas iniciales de componentes
reusables orientadas a objetos de dominios (se considera un objeto de dominio a un
conjunto d e datos del dominio encapsulado junto con las operaciones del dominio que
manipulan a esos datos).
No se ha pretendido con este trabajo obtener.el mejor diseño de arquitecturas o garantizar las mejores condiciones de reuso, esto es tan solo una parte inicial del proyecto SR2 tal y como se menciona en la sección 1.1 de este documento. SR2 esta apoyado por otros trabajos de maestría que trabajarán en colaboración para lograr así lo
planteado en [SAN02].
El lenguaje de origen del código a analizar y reestructurar debe de ser "C". dando como resultado al aplicar el proceso de reestructura, código orientado a objetos en
lenguaje "C++".
Laura Alicia Hernández Moreno 1 3
Cenidet 2003
-
Capítulo 1 Introducción
La limitación que se tiene en cuanto ai proceso de reestructura de software legado,
radica en que, para automatizar este' procesoilse requiere de la instrumentación de
métodos o algoritmos especificos de este trabajo y los cuales se describen
detalladamente en la sección 4.2.
I' !'
1.7 Organización de esta tesis Para describir el trabajo que se realizó para llevar a cabo esta tesis, a continuación
El propósito de este capitulo fue presentar ki entorno de investigación en el cual se se da un panorama de la organización de este documento.
desarrolló este trabajo.
En el capítulo 2, se presenta una revisión de los trabajos relacionados con este tema de investigación y se describe un análisis comparativo de éstos con respecto a este
En el capítulo 3, se hace una revisión de los conceptos y temas relacionados con
trabajo de tesis. .Il
esta investigación, con la finalidad de presentar el fundamento teórico de ésta.
Posteriormente, en el capítulo 4 se describen detalladamente los métodos desarrollados en esta tesis y que conforman la herramienta SR2.
En el capitulo 5. se presentan las conclusiones observadas en esta investigación.
En la Última parte del documento se presentan la bibliografía y anexos que
integran a este trabajo, Los anexos consisten en la descripción detallada de un programa fuente y la forma en que fue reestructurado. 'I¡
14 Laura Alicia Hernández Moreno Cenidet 2003
-
Revisión de la literatura Capítulo 2
2.1 Trabajos relacionados con esta tesis Los trabajos que fueron encontrados y que más se acercan a este trabajo de tesis,
son aquellos que tratan de atacar el problema de mantenimiento en sistemas legados, en
los que tratan que sus sistemas evolucionen o sean entendibles a través de un buen
diseño de su código. Dentro de los trabajos relacionados se mencionan algunos puntos importantes de la implementación de los mismos, tales como las herramientas o métodos
15 Laura Alicia Hernandez Moreno Cenidet 2003
-
Capítulo 2 I' Revisión de la literatura
que utilizan para el análisis y extracción de datos a partir de un programa fuente. Los
trabajos se describen en las siguientes subsecciones.
2.1 .I Transformación automática de sistemas legados [PHIOI] En este documento se menciona la necesidad de búsqueda y creación de técnicas
o herramientas que sirvan de apoyo al sector industrial, donde proporcionen a éste una
disminución en costos de desarrollo, un mayor entendimiento de ¡os sistemas legados, un
cambio de paradigma de programación para que su software legado no se vuelva obsoleto.
Menciona que las alternativas de solución para la modernización de los sistemas incluyen el desarrollar un nuevo sistema, el reemplazar sistemas con soluciones
comerciales (COTS - Component off-the- Shelf, Componentes de software comerciales de vitrina o anaquel) o la reescritura manual de las aplicaciones de software legado hacia
un ambiente moderno de programación. Donde el desarrollar totalmente un nuevo sistema
o reemplazar los sistemas legados por medio de la reescritura manual de los sistemas de software con el soporte de herramientas semiautomaticas es extremadamente costoso y
consume tiempo.
Reemplazar el sistema usando COTS aunque es menos costoso y consume menor
tiempo, tiene la desventaja de que no permite extender o expandir los componentes que
los integran con la finalidad de brindar mas funcionalidad en los sistemas en donde los estén usando.
Se describe que a través de la tecnología de Inteligencia Artificial es posible construir herramientas que nos permitan lograr un alto porcentaje en el análisis,
transformación, refactorización o reingeniería. KBSA (Air Force-funded Knowledge-Based
Software Assistant) en su intento por tratar de construir herramientas que den soporte en la transformación de software legados a un nivel de automatización que se acerque a un
loo%, se ha dado a la tarea de tratar de construir una herramienta que nos permita hacer la transformación de sistemas legados escritos en lenguaje COBOL, JOVIAL, FORTRAN.
C, ASSEMBLER, ADA, CMS-2 y MUMPS hacia lenguajes tales como C++, JAVA, C# y J2EEI.NET.
'11
I , - . ,
I'
16 Laura Alicia Hernandez Moreno Cenidet 2003 1)
http://J2EEI.NET
-
Revisión de la literatura Capítulo 2
Se menciona que se han hecho pruebas de transformación sobre 10s lenguajes
JOVIAL, COBOL, c , FORTRAN y ASSEMBLER; mas no se menciona en que IenguaMs)
han sido transformados.
El proceso de reingenieria se define sobre cuatro procesos, los cuales son:
Ei proceso de análisis se realiza a través de la construcción en memoria de un
árbol de sintaxis abstracto basado en conocimiento (KBAST) generado a partir del código
de entrada que se da a la herramienta.
análisis, reestructura, refactorización y Web-enablement.
Las interpretaciones que se van realizando del KBAST se van almacenando para
posteriormente documentar decisiones acerca de las situaciones que se encuentren en el
código (propiedades) y así poder llevar a cabo la transformación.
El proceso de reestructura consiste en especificar o generalizar cada una de las
interpretaciones obtenidas en el proceso de análisis. Las interpretaciones que se hacen
se basan en las estructuras del programa, en la definición de datos estructurados, en
bloques básicos de código, funciones o variables de entrada del programa. Tanto el proceso de transformación así como el proceso de refactorización
requieren intervención manual. cuando es necesario establecer sistemas que apoyen la
tarea de clasificación.
El proceso de refactorización se encarga de extraer y parametrizar métodos,
mezclar y consolidar métodos similares, reducir el conjunto de métodos asociados con
una clase, el conjunto mínimo de operaciones para mejorar. Reduce la duplicidad y
redundancia de código.
Web-enabiement trata de vincular la transformación de una aplicación hacia aplicaciones distribuidas o trabajo en red (crear componentes distribuidos o los
actualmente llamados servicios web), haciendo uso de herramientas que permitan trabajar
sobre ambientes distribuidos, tal es el caso de las siguientes herramientas:
I Para bases de datos. ODBC(0bject Data Base Connectivity), JDBC (Java Data Base Connectivity).
i Para proveer servicios de componentes distribuidos. CORBA (Common Object Request Broker Architecture)
17 Laura Alicia Hernández Moreno Cenidet 2003
-
Revisión de la literatura 1 Capítulo 2
El objetivo que persiguen [PHIOI]. es cbnstruir una herramienta genérica que
permita realizar la reingenieria sobre los lenguajes ya mencionados en párrafos
anteriores. Lo que no queda claro ya que no lo mencionan, es en que lenguaje(es) quedarían como resultado de aplicar la reingenieka. Otra de las cosas que no mencionan
es la forma en que realizan la reestructura, lo que mencionan en relación a esto es que es una tarea dificil y que en su mayoría requiere de la intervención manual.
2.1.2 Reestructurar código legado C en C++ [RICOO]
el Departamento de Ciencias Computacionales de la Universidad de Detroit, E.U..
En este documento se hace mención de un prototipo, el cual esta en desarrollo en
Se hace uso de una herramienta que sirve para realizar el proceso de reestructura
y para tareas más complicadas de reestructura se hace uso de escenarios que combinan el uso de la herramienta con la intervención del usuario.
La herramienta de reestructura se compone de las siguientes fases: inserción de
variables en clases, hacer'accesos a variables no locales, agregar parámetros a funciones
y cambiar especificaciones de accesos de una clase.
Para la identificación de los elementos o datos del programa fuente y que habrán
de servir para el proceso de reestructura, se empleo una herramienta de análisis llamada
GEN++. GEN++ es un analizador de código programable basado en el Cfront de AT&T. Este analiza el código fuente escrito en lenguaje "C" y lo almacena en un grafo semántico abstracto, a través del cual el programador puede escribir consultas (queries) analizando
el grafo en un lenguaje tal como LISP. El proceso de reestructura se compone de tres partes:
li
.I1
9
9
Restricciones del analizador (implementado en GEN++). Se asegura que estén todas
las precondiciones requeridas para llevar a cabo el proceso de transformación. Transformación del analizador (implementado. en GEN++). Localiza todas las partes del código que pueden ser cambiadas (variables globales ylo locales, funciones,
parámetros, accesos a variables y funciones) y que cambio es requerido en ellas. Los datos obtenidos los guarda en un archivo.
'I
18 Laura Alicia Hernandez Moreno Cenidet 2003 I\
-
Revisión de la literatura Capítulo 2
> Código reestructurado (implementado en C++). Esta parte usa el archivo obtenido en el punto anterior y realiza los cambios necesarios para su reestructura apoyado con la
intervención del experto humano.
2.1.3 Extracción automática de clases desde sistemas legados [ANDOO] Este artículo menciona algunas de las ventajas del paradigma de programación
orientado a objetos, da una breve descripción de la herramienta Rescueware, y un análisis por parte del escritor con relación a una nueva forma de extraer en forma
automática las clases desde sistemas legados.
Las ventajas que menciona son acorde a [B0094], y son las siguientes: > Los objetos proveen un buen modelo del mundo real, ayudan a simplificar el diseño de
un sistema (abstracción, descomposición).
> Los objetos son independientes e interactúan usando interfaces definidas o métodos. > El uso de la herencia, nos permite hacer más fácil poder agregar características
nuevas a objetos existentes.
> Cuando un objeto necesita ser actualizado, este es un cambio interno y no afecta a otros objetos (consecuencias de la encapsulación).
La herramienta Rescueware considera la tarea de transformar sistemas legados escritos en lenguaje COBOL a programas orientados a objetos en lenguajes modernos de programación, tales como C++, Java o Visual Basic. Los principales pasos que sigue esta herramienta son: Creación del procedimiento, localización o eliminación completa del
GOTO. localización de datos y transformación optimizada. El proceso se basa generalmente en la representación del programa fuente en un árbol de
sintaxis abstracto (AST) y 'lo que se hace con éste, es localizar e incorporar en clases las variables definidas en el programa (las cuales no son difíciles de identificar porque todas
sus variables son globales y están como una sola estructura), hace una descomposición
de los procedimientos localizados como funciones e incorpora a estas últimas parámetros que vendrán a tomar la representación de las variables que utiliza el procedimiento en
descomposición.
El autor del documento que en este punto se describe brevemente, plantea los siguientes principios básicos para la extracción de clases de programas legados:
19 Laura Alicia Hernandez Moreno Cenidet 2003
-
Revisión de la literatura Capítulo 2
Acoplamiento de datos, llamadas y nivel de variables. A través de estos principios hace
un llamado a un mejor análisis base a las variables globales y el nivel de anidamiento y/o
dependencia entre variables y procedimientos. ,
2.1.4 Reingeniería de software legado a':través de la conversión del
lenguaje [MAAOO] Proyecto desarrollado en la Universidad' de Tempere en el Departamento de
Computación y Ciencias de la Información, Finlakdia. Este es un ambiente de desarrollo
que da soporte a un proceso de reingenieria en apoyo a la industria de este pais.
La reingenieria, es un proceso de transformación o conversión que toma como
código fuente o de entrada programas escrito; en el lenguaje PL/M (Programming Language for Microcomputers) dejando por resultado programas en lenguaje C. El
proceso que se sigue consiste principalmente de un proceso de reestructura. En la reestructura, el software legado es bnalizado utilizando la herramienta que
lleva por nombre TaLE (Tampere Language Editor), ésta nos brinda soporte en el
desarrollo o implementación de lenguajes. Su desarrollo ha sido en Eiffel, C++ y actualmente en lenguaje Java. /I
En este trabajo TaLE parte de la gramática de PUM y de un programa de entrada escrito en PUM, una vez que lo está analizando empieza a mostrar los elementos de la gramática encontrados en forma gráfica, a su vez hace empleo de tablas de simbolos y archivos para guardar la información obtenida, la cual se enfoca a la identificación de variables globales, funciones y sus relaciones. De los datos obtenidos se despliega en una interfaz a través de un árbol, las variables globales que localizó dentro del programa y a partir de éstas pide la intervención del usuario para ir asignando nombres a los archivos
que va crear. La creación de archivos la lleva a cabo de la siguiente forma:
> Toma como archivo principal, la primera variable global que encontró y a las demás las
'1
II incorpora en otros archivos, con sus respectivas operaciones.
9 En el archivo principal pone como librerías a los demás archivos creados.
1 En este articulo se menciona que se tiene contemplado llegar hasta un diseño
onentado a objetos, el cual es un paradigma de programación que promete un mejor 20
Laura Alicia Hernández Moreno Cenidet 2003 11
-
Capítulo 2 Revisión de la literatura
diseño y calidad en los sistemas de software. Sin embargo para llegar al paradigma planteado anteriormente, se menciona que no es una tarea fácil de automatizar, por la
complejidad que se tiene de manejar diferentes paradigmas de programación (estructural
- orientado a objetos).
2.1.5 Un framework para reestructurar software [KYB99] Es un prototipo desarrollado en la Universidad de Colorado, E.U., que soporta la
reestructura de software procedural escrito en lenguaje C, COBOL, FORTRAN o Pascal.
Tiene como objetivo mejorar las características de diseño, sin cambiar su paradigma de
programación.
El framework consta de tres elementos principales: modelo de diseño de software, métricas basadas en criterios de reestructura y un proceso para reestructurar mediciones.
Los autores de este documento usan el término de "módulo", para referirse a procedimientos o funciones individuales definidos en un programa.
El modelo de diseño de software, generalmente usa gráficos para representar los componentes de un módulo y las conexiones entre módulos. Trata de ajustarse a los requerimientos del framework (entradaslsalidas de un módulo).
Las métricas basadas en criterios de reestructura, se basan sobre la cohesión y acoplamiento de módulos.
La cohesión de software o relación fuerte, se refiere a la relación que puede existir
entre los componentes (operaciones) de un módulo a través de sus atributos; donde los módulos cohesivos son difíciles de dividir en componentes separados.
El acoplamiento de software se refiere a la conexión que puede existir entre módulos.
Uno de los objetivos del proceso de reestructura es incrementar la cohesión y
,
reducir el acoplamiento.
Los tipos de cohesión y acoplamiento que se pueden identificar son:
9 Cohesión coincidental, temporal, procedural, de comunicación, secuencial y funcional. 9 Acoplamiento común, condicional, computacional, secuencial y el no acoplamiento.
DG'T\ SEP CENIDET CENTRO DE INFORMAC~O~
21 Laura Alicia Hernandez Moreno Cenidet 2003
-
Capítulo 2 Revisión de la literatura
I Las medidas de cohesión y acoplamiento son un punto importante para el proceso
de reestructura. ya que indican si un módulo será o no descompuesto, y compuesto en un nuevo diseño. 11
El proceso de descomposición de los módulos los realiza a través de la partición de los mismos módulos (entiéndase por módulos a las funciones o procedimientos), los
cuales los integra en nuevos módulos con una funcionalidad especifica. Ese proceso es mejor conocido como partición de programas (program slices) y trabaja en conjunto con el
nivel de cohesión y acoplamiento de módulos, algunos de los trabajos mas recientes
referentes a partición de programas, cohesión y acoplamiento podemos ver en [ARU99,
HEE99, BIE981 I1 El proceso de reestructura consiste de una secuencia de descomposición y
composición o creación de módulos. En este proceso que integra a la herramienta que en esta sección se describe, se hizo uso inicialmente de una herramienta que lleva por nombre F-Slicer para hacer las particiones de programas, sin embargo esta herramienta
no es completamente automática. Los elementos que integran al framework se
encuentran incorporados dentro de la herramienta que lleva por nombre FUNCO. La
herramienta hace uso de los analizadores lex y yacc en conjunto con el compilador gcc (UNIX). La herramienta ha sido probada e instalada en una SUN SPARCstatation.
.I
r. L
2.1.6 RESTRUCT [SAGWW, SAG98, SAG971 Es una herramienta CASE de reestructura,, que hace uso de la ingeniería inversa,
la cual ha sido desarrollada en base la integración de proyectos estudiantiles de la Universidad de Montfort, Inglaterra. Transforma programas escritos en lenguaje C que están pobremente estructurados, en programas con una estructura orientada a objetos
utilizando el lenguaje Java.
La herramienta parte del uso de una base de datos que contiene los componentes
o datos extraídos, donde éstos se extraen en forma manual (de acuerdo a [ S A G W ) del programa candidato a ser reestructurado.
Mencionan que las técnicas de identificacih de objetos sobre las cuales se apoya
la herramienta están sustentadas por tres algoritmos descritos por Livadas & Roy [LIV92],
Liu & Wilde [LIU90]. Los algoritmos de identificación de objetos son los siguientes: 22
Laura Alicia Hernández Moreno Cenidet 2003
-
Revisión de l a literatura Capítulo 2
> Basado en variables globales (gboi). Consiste en agrupar las variables globales Y las funciones que manipulan estas variables.
> Basado en tipos (tboi). Agrupa tipos definidos por el usuario con las funciones que utilizan estos tipos como parámetros formales o valores de retorno.
k Basado en el reconocimiento de receptores (rboi). El algoritmo define un objeto
candidato como un par (F,T) donde F es un conjunto de rutinas que modifican par variables de tipo T. Los receptores son tipos de variables representados' como
variables globales o parámetros pasados por referencia.
Los métodos de transformación que utiliza RESTRUCT son: P Partición simple, Se usa cuando un conjunto de variables son modificadas por un
conjunto de rutinas o funciones y estas variables no están relacionadas a otros
conjuntos de funciones o rutinas. Lo cual indica que estos conjuntos de variables y funciones o rutinas definen un comportamiento común y pueden ser clasificadas en
clases separadas.
> Partición con métodos parametrizados. Se utiliza cuando las funciones o rutinas que son separadas en una clase independiente de la clase original, acceden a algunas
de las variables que permanecen a esta última. Lo cual sugiere que la separación puede efectuarse aplicando una partición simple, pero pasando como parárnetros a
las variables accedidas por las funciones a ser separadas de la clase original. Los parámetros se pasan por valor si las variables sólo son,referidas y por referencia si las variables son modificadas.
> Partición con herencia. Se utiliza cuando una relación de este tipo es más natural que las relaciones de agregación (composición) de los métodos de partición anteriores. Por ejemplo se puede utilizar este método de partición cuando un
conjunto de funciones que podrían ubicarse en una subclase pueden llamar a otras funciones que permanecen a la clase original.
P Extracción de librerias de clases estáticas reusables. Nos dice que la mayoría de los programas que contengan métodos que pueden ser utilizados por otros programas o que pueden ser requeridos por un gran número de clases (creando librerías), no
pueden ser incluidos en ninguna de las clases. Tales métodos pueden ser agrupados
en una librería de clases declarada como pública y estática, indicando con.esto que
no hay instanciación de esta clase. De tal manera que ahora las funciones o
23 Laura Alicia Hernández Moreno Cenidet 2003
-
Capítulo 2 1 Revisión de l a literatura
métodos de esta clase pueden ser compartidas por todas las clases que las
P Partición con una superclase estática reusable. La partición con una superclase estática reusable se utiliza cuando se presentan los siguientes dos problemas: cuando
un conjunto de funciones o rutinas usan a otro conjunto de funciones o rutinas de la
clase original, pero estas funciones son candidatas a'ser parte de otra clase.
Este es un problema causado por las reglas de alcance de los lenguajes orientados a objetos de verificación robusta' de tipos, ya que estos dos conjuntos
de funciones no estarán al alcance unos de otros después de la transformación.
Este problema se resuelve ubicando a las funciones o rutinas utilizadas junto con
sus variables asociadas como miembros;. de una superclase y heredar los componenfes de la clase que contiene a las funciones invocadas.
requieran. 1
Sin embargo, el segundo problema se presenta cuando hay dos subclases
en la misma situación, porque cuando se genera una instancia de cada una de las
subclases se produce la creación de dos variables de instancia, cuando puede
darse el caso de que sea necesaria solamente una variable de clase compartida por las dos subclases. h!
La solucibn que plantea este método de partición es declarar las variables
de la superclase como estáticas, asegurando de esta manera sólo una copia en memoria de estas variables para todas las irktancias del tipo de las subclases que
se declaren en una aplicación.
I1
2.1.7 SPRUCE: Un framework para reestructurar software [DAV97] SPRUCE (System fo.r Providing assistance with' Restructuring CodE), es un
sistema que proporciona ayuda para reestructurar código de programas escritos en
lenguaje Pascal (mejorar las características de diseño). Soportado en parte por la NSERC
(Natural Sciences and Engineering Research Council), por los estudiantes de posgrado
del NSERC y a la ITRC (Information Technology Ffesearch Centre) el cual es parte de los Centros de programa de Excelencia de Ontario. En este sistema proponen dividir la reestructura en cuatro etapas:
24 Laura Alicia Hernández Moreno Cenidet 2003
-
Revision de l a literatura Capítulo 2
9
9
P
P
Reestructurar nivel del código. Consiste en la identificación de tomas de decisiones (if-
then-else) y en las entradas y salidas que pueden surgir dentro de un ciclo (llamadas a otros módulos, uso de goto's).
Reestructura de datos. Analiza las relaciones que pueden existir entre estructuras de
datos y variables, es decir, identifica si una variable o estructura de datos tiene alguna relación con alguna otra variable o estructura de datos. Incluye identificar si una
variable global puede ser local y si parámetros de variables pueden ser parámetros de valores.
Reestructura procedural. Divide un programa en un conjunto lógico de rutinas, pero
menciona que las rutinas obtenidas no son necesariamente la mejor división. Se
menciona que por cada rutina se deberia tener sólo un punto de entrada y un punto de salida, en la cual se integre cada rutina como una función abstracta de tal forma que
las rutinas puedan ser organizadas en una jerarquia.
Remodulación. Es la reestructuración de un sistema existente en una jerarquia modular; esto incluye mover rutinas en módulos apropiados.
Cada una de estas etapas tiene tres fases: Reunir información, efectuar decisiones
y ejecutarlas.
Para limitar la dependencia del lenguaje, SPRUCE procesa un árbol abstracto de
sintaxis con un lenguaje independiente "tree walker". El "tree walker" entiende la estructura del árbol abstracto de sintaxis y provee rutinas que permiten acceder de la
información en los nodos y para instruir el "tree walker" para moverse entre nodos. La tabla de entradas para cada tipo de nodo llama al "tree walker" para que realice la
reestructura.
Hace uso de otros procedimientos tales como: Análisis del grafo de llamadas,
alternado del código, análisis del flujo de datos, análisis del goto, controlador de interface. controlador de la estructura del módulo, análisis de procedimientos, reescribir procedimientos, organizar la estructura de módulos, renombrar variables y análisis del uso
de variables.
Lo que se encontró, que se ha construido de SPRUCE es lo siguiente:
9 Un parser en Pascal y un analizador semántico parcial.
9 Análisis de datos y flujo de control.
9 Implernentación de la facilidad para renombrar variables.
25 Laura Alicia Hernandez Moreno Cenidet 2003
-
Capítulo 2 Revisión de la literatura
9 Una implementación parcial de una interface de usuario basada en SUNView para
visualizar el código fuente escrito en lenguaje pascal.
> Implementación de lineas de código, otras herramientas como Halstead. McCabe y unas pocas métricas no muy conocidas.
Estos trabajos han surgido como proyectos separados desarrollados por
estudiantes, los cuales no han sido integrados aún.
2.2 Análisis comparativo de los trabajos relacionados con respecto a esta tesis
Como se puede observar, existen trabajos que no hacen una transformación de C
a C++ que es lo que se hace en este trabajo de tesis. Sin embargo tienen un punto muy en común, el cual esta enfocado a tratar de c o n h i r herramientas o metodologias que
ayuden a los programadores al entendimiento del software legado para su fácil o mejor mantenimiento, reduciendo con esto tiempo y esfuerzo (costos). As¡ también se enfocan a mejorar las características del diseño, donde algunos cambian su paradigma de
programación tratando de evolucionar y mejorar sus diseños, mientras que otros tratan de mejorar sus diseños sin cambiar su paradigma de programación.
Se hace mención que el paradigma de programación orientado a objetos nos
brinda muchas ventajas, siendo una de las más importantes la siguiente: Hacer diseños
reusables a través de la creación de componentes o marcos de componentes reusables, los cuales pueden ser utilizados en extensiones o nuevas aplicaciones del mismo dominio.
Uno de los puntos importantes de este trabajo de tesis es poder obtener marcos
de componentes reusables, cosa que en la mayor parte de los trabajos no se prevee, la reusabilidad.
Una de las similitudes que existen entre al&nos de los trabajos ya descritos en las
subsecciones anteriores (principalmente de la herramienta RESTRUCT) y este trabajo de tesis, es la identificación de variables y funciones que se trata de hacer para realizar un proceso de transformación o reestructura.
I1
I/
I1
Desde esta perspectiva podemos decir que existe una diferencia ya que en este
trabajo de tesis no sólo nos referimos a la incorporación de variables globales y las 26
Laura Alicia Hernández Moreno Cenidet 2003
-
Revisión de l a literatura Capítulo 2
funciones que las acceden en una clase o archivo separado, va mas allá empleando 10s siguientes criterios en el proceso de reestructura: conversión de tipos de datos
estructurados a clases de objetos, conversión de datos globales a clases de objetos y conversión de funciones a clases de objetos. Estos criterios se describen en el capítulo 4 de la tesis.
Hasta ahora no se ha encontrado una herramienta que trate de incorporar en
clases de objetos a los tipos de datos estructurados a través de un proceso de
reestructura, refiriéndonos principalmente a los tipos de datos estructurados anidados. Se ha llegado a hacer dejando a la definición del tipo de dato estructurado en una clase y los campos que integran al tipo de dato estructurado se forma una clase por cada campo y los métodos que utilizan a cada campo son agrupados en la clase correspondiente al campo. Se crean variables de instancia en la clase creada a partir de la definición del tipo
de dato estructurado, las variables de instancia corresponden a las clases creadas a partir
de los campos que componen al tipo de dato estructurado.
Podemos ver que la mayor parte de los trabajos tratan de ver un proceso de reestructura tan sólo como una encapsulación de datos, esto debido a que no se tiene
contemplado un diseño que permita el reuso. Dado que el reusar utiliza otros mecanismos
para su buen funcionamiento tales como: herencia, agregación, instanciación y un concepto nuevo que ha venido a ser de gran utilidad el cual es, los patrones de diseño.
El Único trabajo encontrado que haga uso de patrones, es el de Harald C. Gall, Rene Klosh, Roland T. Mittermeir y Johannes Weidl (GAL951 los cuales realizan un proceso de reestructura que transforma código legado en C, Pascal y PUI a una
arquitectura orientada a objetos y hacen uso de los patrones del catálogo de Peter Coad (patrones de análisis y patrones de diseño) con el objetivo de modelar dominios de aplicaciones.
Respecto a este trabajo la diferencia principal radica en que su modelado de dominios se ve limitado debido a que no contempla algunos patrones de diseño que son
fundamentales para la construcción de arquitecturas y/o marcos de componentes reusables orientados a objetos, tales como: El patrón de diseño template method con el cual se puede implantar la definición de métodos gancho que nos permiten la inversión del flujo de control, el patrón de diseño facfory method que permite crear una alternativa o interfaz de implantación, y por Último el patrón de diseño Decorator el cual nos sirve para
27 Laura Alicia Hernández Moreno Cenidet 2003
-
Revisión de la literatura 11 Capítulo 2
estructurar la funcionalidad en clases de los tipos de datos abstractos cuando existen
anidaciones, es decir un tipo de datos estructurado dentro de otro(s).
Cabe mencionar que esta tesis esta siendo extendida, actualmente se está
trabajando sobre la incorporación de nuevos patrhes de diseño en la herramienta SR2.
Con respecto a los trabajos de las subsecciones anteriores se dice que alguno de ellos (véase sección 2.1.4) hace uso del patrón de diseño Singleton el cual sirve para hacer la incorporación o agregación de una clase a otra (como una simple agregación o composición).
La herramienta FUNCO (2.1.5) se trató'ide investigar a través de su uso, su funcionalidad. Después de varios dias de tratar de hacer funcionar la herramienta se encontró que ésta no estaba completa, por lo cual se le envió un correo electrónico a uno 1 de los autores el Dr. Bieman, el cual afirmó que laiherramienta no ha sido aún terminada.
En la tabla siguiente (tabla 2.1) se describe en forma general un análisis
comparativo entre los trabajos relaciones a este trabajo de tesis y sus desventajas 1
respecto a esta tesis.
de inteligencia artificial. 9 su proceso de
reingenieria esta
sustentado en cuatro procesos: análisis,
reestructura,
refactorización Y
9 Para el proceso de
clasificación de datos
servicios web. :.
compiladores haciendo
uso de la herramienta ANTLR. se aplican métricas y se hace uso de patrones de diseño
propios para el reuso.
9 El proceso completo de SR2 contempla los
mismos procesos que se
mencionan
28 Laura Alicia Hernández Moreno Cenidet 2003 I)
-
Revisión de la literatura Capítulo 2
leestructurar código legadc
: en C++ [RICOO]
menciona el articulo que se requiere de
intervención manual.
Tratan de hacer una
transformación de
lenguajes tales como:
COBOL, JOVIAL,
FORTRAN, C, ASSEMBLER, ADA,
CMS-2 y MUMPS hacia
lenguajes tales como
C++, JAVA, C# y J2EEI.NET. No
mencionan
específicamente, las
transformaciones de los
lenguajes, es decir, un
determinado lenguaje
hacia cual ienguaje(s) es
transformado. AI parecer
este trabajo aun no se
termina.
Es un prototipo que se
encuentra en desarrollo.
Se compone de las siguientes fases: inserción de variables en
clase, hacer accesos a
variables no locales,
agregar parámetros a
funciones y cambiar
columna de desempeño
sin embargo nc
mencionan los método5
que se llevan a cabo er
cada proceso. En este
trabajo de tesis SE
aplican 7 métodos tar
solo para el proceso dr reestructura.
En este trabajo de tesi:
se lleva a cabo un:
reestructura dr
programas escritos er
lenguaje C hack
programas escritos er
lenguaje C++ orientado:
a objetos.
Los siete métodos de reestructura han sidc
concluidos en este trabajo de tesis.
* Las fases de este trabajo
de tesis van más allá de
una simple inserción de
datos en clases, se hace
uso de conceptos de la
29 Laura Alicia Hernandez Moreno Cenidet 2003
http://J2EEI.NET
-
I
I
Capítulo 2 Revisión de la literatura
I
Extracción automática de
clases desde sistemas
legados [ANDOO]
Un framework para
reestructurar software
[KYB99]
especificaciones de
accesos de una clase.
P Hace uso del analizadoi GEN++. analiza códigc
escrito en'lenguaje C y Io
almacena en ''un grafo
semantico. Las consultas
al gráfo se! hacen a
través de un programa
para consultas tal como LISP. 11.
I
+. Realiza la transformación
de sistemas legados
escritos en '1 lenguaje COBOL a programas
orientados a li objetos
(C++, Java o Visual
Basic).
Prototipo que sbporia la reestructura de software
procedural escrito en
lenguaje C, COBOL,
FORTRAN o PASCAL. Teniendo como objetivo mejorar las
caracteristicas de
diseño, sin cambiar su paradigma de
programación. I/
programación orientada
a objetos, así como de
patrones de diseño.
+. ANTLR proporciona las
facilidades de
reconocimiento, de
consulta y obtención de
datos sin tener que
interactuar con otras
herramientas. Genera
código en lenguaje Java.
+ Se aplica la reestructura
a programas escritos en
lenguaje C hacia
programas escritos en
lenguaje C++ orientado a
objetos.
AI realizar el proceso de
reestructura se esta
llevando a cabo un
cambio de paradigma de
programación de
programación procedural a programación
orientada a objetos.
Siendo esta ultima uno
de los paradigmas actuales de mayor auge
y con mayor desempeño
en el reuso de software.
30 Laura Alicia Hernández Moreno Cenidet 2003 a
-
Capítulo 2 Revisión de la literatura
tESTRUCT [SAGWW
;AG98, SAG971
>PRUCE [DAV97]
* Transforma programas
escritos en lenguaje C,
en programas con una
estructura orientada a
objetos utilizando el
lenguaje Java. Se
menciona que hace uso
de patrones de diseño,
sin embargo dentro de
sus artículos no hay
ninguna publicación que
lo demuestre.
* En el trabajo que presenta RESTRUCT al
parecer solo hacen uso de la composición ya que
de una clase grande van
sacando a clases los datos globales y sus
respectivas funciones.
' En las publicaciones de
RESTRUCT se menciona que el proceso
se realiza en una forma
automática, sin embargo no 'se han publicado
pruebas que corroboren
esta afirmación.
> Mejora las características de diseño
de programas escritos en
El hacer uso de la
programación orientada
a objetos (en esta tesis)
va más allá del uso de tan solo una
composición. Va hacia la
creación de un marco
completo de
componentes reusables.
SR2 aplica los patrones
de diseño Strategy,
State, Decorator, Factory
Method, Template Method, entre otros.
SR2 es una herramienta
automática que permite
generar código en
lenguaje C++ a partir de programas escritos en
lenguaje C.
Se continua trabajando
tratando de obtener
marcos de componentes
reusables mas
completos y en donde esta herramienta sea de utilidad dentro de
dominios específicos. Se trata no de mejorar
las características de
diseño, sino de obtener
31 Laura Alicia Hernandez Moreno Cenidet 2003
-
Capítulo 2 Revisión de la literatura
I lenguaje Pascal buenos diseños que permitan el fácil
entendimiento. extensión
y actualización de los programas. Esto es lo
que persigue SR2.
Tabla 2.1 Tabla comparativa de los trabajos relacionados contra este trabajo de tesis
32 Laura Alicia Hernandez Moreno Cenidet 2003
-
Marco teórico Capítulo 3
ada día crece más la necesidad de pensar en estrategias o herramientas que nos
ayuden a diseñar sistemas de información con más tiempo de vida útil. En esta tesis se construye una metodología de reingeniería para ampliar el tiempo de vida útil del software. reestructurándolo para su reuso.
c En este sentido a continuación se presentan los conceptos empleados en torno a
este proyecto de tesis.
33 Laura Alicia Hernández Moreno Cenidet 2003
-
Capítulo 3 Marco teórico
3.1 Factorización La factorización implica la descomposición o partición de un determinado
programa en una jerarquia de clases, partiendo de una clase padre o raiz y llegando a las clases concretas o atómicas que realizan las funciones operativas.
Análogamente a lo que sucede en las organizaciones humanas, una clase padre de máximo nivel no realiza ninguna de las tareas del sistema por si mismo, sino a través
de sus subordinados. En el caso limite, una clase raiz solo contiene llamadas a otras
clases. Las clases padres (alto nivel) normalmente tratan decisiones globales, en tanto
que las de bajo nivel tratan aspectos especificos de las decisiones de nivel superior
[TORXX].
¡I
3.2 Programación por procedimientos en lenguaje C [SANO21 La programación estructurada fue empleada desde el principio de la década de los
setenta, y tuvo como filosofia, construir un programa a partir de la composición de
funciones o procedimientos entre otros modelos que permiten que los programas sean más fáciles de escribir, verificar, leer y mantener.'iLos programas deben de estar dotados de una estructura. De tal manera, que los principales elementos del reuso fueron las bibliotecas de funciones.
La programación por procedimientos en lenguaje C, está cimentada en mecanismos que dan facilidades para comunicar, como argumentos, información a
procedimientos ylo funciones y retornar valores desde las funciones. Este modelo de
programación cuenta con estructuras de datos globalec, aunque también se han desarrollado mecanismos para manejar el alcance y el tiempo de vida de las variables, siendo factible dependiendo de: el lenguaje ,de implantación, manejar variables
globales y locales con tiempo de vida que puede ser estático, dinámico y automático.
j
Bajo el contexto de reuso, la meta principal de este modelo de programación
es la de permitir a los programadores ejecutar segmentos de código, organizados en bibliotecas de funciones, más de una vez, sin tener que duplicar el código en cada localidad fisica donde son necesarios.
Los programadores observaron que podian insertar subrutinas extraídas de sus
programas previamente desarrollados, o ta'mbién aquellas escritas por otros 34
Laura Alicia Hernandez Moreno . : . - I;
Cenidet 2003
-
Marco teórico Capítulo 3
programadores, en nuevas aplicaciones, tomando ventaja de la funcionalidad Sin tener
que involucrarse con 10s detalles del código. Así es como nació el concepto de reuso
de software [BR096].
A pesar de que las subrutinas representan un gran avance para el desarrollo de programas de aplicación con mayor rapidez, con mayor calidad y con más facilidad,
este paradigma de programación no ha sido suficiente para lograr que la producción
de software se realice bajo un esquema completo de reuso. El resultado de construir sistemas de software bajo este paradigma son
programas de una sola pieza, que por ser diseñados para resolver un problema específico es difícil su reuso, parcial o total, en otros problemas aún del mismo dominio de aplicación, pues como dice Clemens Szyperski [SZYSS] "no basta con e/
diseño monolitico de una solución completa y después fragmentarla, cuyo beneficio es
mínimo, sino que /as descripciones tienen que ser cuidadosamenfe generalizadas para
permitir su reuso en muchos contextos diferentes".
Estos programas monolíticos exhiben una gran cantidad de líneas de código,
estatutos condicionales con profundos niveles de anidamiento, alto grado de
acoplamiento entre las diferentes funciones y procedimientos, y cualquier línea de
código puede acceder a las estructuras de datos globales.
Estos factores producen en el software un alto nivel de complejidad,
disminución de su comprensión y entendimiento, muchas dependencias funcionales,
una baja importante del nivel de cohesión entre los datos y las funciones ylo procedimientos.
Como consecuencia, se dificulta el mantenimiento de este tipo de programas,
se impide su reuso aún en el mismo dominio de aplicación, porque existe dificultad
para fragmentar y modular el código, ocultar los detalles de implantación, extender y especializar la funcionalidad, factorizar en funcionalidades comunes para reuso, e ínter
operar con un menor nivel de dependencias.
Para minimizar estos problemas, Dijkstra [DIJ68] mostró que las piezas de código de un programa podrían ser desarrolladas de manera independiente y David
Parnas [PAR721 introdujo el concepto de Ocultación de Datos. Así han ido surgiendo
nuevos paradigmas de programación, sin embargo hoy en día el paradigma de
35 Laura Alicia Hernández Moreno Cenidet 2003
-
Capítulo 3 Marco teórico
desarrollo basado en componentes apoyado en la orientación a objetos prevalece y se
presenta como una alternativa de solución a los problemas de software.
3.3 Análisis e ingeniería de 'dominios[SAN02] El análisis de dominios ha sido identificado como un factor esencial en el reuso
sistemático de software. Por medio de un análisis de dominios se pretende identificar a
las entidades, relaciones, y operaciones básicas de un dominio de aplicación.
Un dominio es un conjunto de sistemas que tienen propiedades comunes, lo
cual proporciona la ventaja de poder estudiar y organizar esas propiedades .comunes
en una colección de componentes reusables para ser usados en la construcción de
nuevos sistemas en el dominio.
El análisis e ingeniería de dominios :I son tendencias de investigación y
desarrollo emergentes de los últimos años para poner fin al problema del reuso de
software. Si bien esto ha sido uno de los puntos más promisorios y de los que se han obtenido más ventajas, también se han encontrado diversos problemas. Los
principales son de tipo técnico, ya que se tieneiuna carencia de herramientas para su
soporte.
El análisis de dominios está en un proceso de maduración, en donde los
resultados hasta ahora obtenidos apenas empiezan a tomar forma. Como ejemplo de
un resultado importante es la especificación de!algunos estándares sobre el reuso de
software que particularmente se pueden utilizar para análisis de dominios.
El 'análisis de dominios [MIL95], sigue un proceso similar al de desarrollo de sistemas de software.
Especificación de requerimientos.
Análisis del problema.
Producción de componentes reusables de amplio dominio.
Pero, las salidas difieren del desarrollo tradicional de sistemas: Componentes
reusables típicamente incluyen estándares y guías (por ej. conocimiento semántico),
as¡ como generalidades y particularidades, tales como los modelos de dominios (por
ej. arquitecturas funcionales genéricas), arquitecturas genéricas de diseño y plantillas, y aun fragmentos de código genérico.
36 Laura Alicia Hernández Moreno
. ... Cenidet 2003//
-
Capítulo 3 Marco teórico
Las herramientas de indexación, localización y exploración, juegan un papel
muy importante en la organización del conocimiento del software existente para los propósitos (de entradas) de la ingeniería de dominios, pero no proporcionan o generan
componentes utilizables directamente.
El modelado de dominios sirve para tres propósitos fundamentales: 1.
2.
3.
Ayuda a los programadores a entender el dominio de una aplicación.
Se utiliza para el análisis de sistemas. Proporciona una base dependiente de la aplicación para clasificar a los componentes de software existentes, para que las oportunidades de reuso puedan
ser identificadas en el proceso de desarrollo de software tan pronto como sea
posible.
De acuerdo al tipo de actividades que se realiza en un método de análisis de dominios y sus objetivos finales, que dan como resultado modelos, Holmes (HOL931 ha hecho una clasificación de los modelos: 1. Modelos funcionales. Descriptivos y Prescriptivos. 2. Modelos Dinámicos. 3. Modelos de Objetos.
sistema dentro de un dominio, desde el punto de vista del usuario.
problema o dominio de interés.
Los modelos funcionales son utilizados para describir el comportamiento de un
Los modelos descriptivos. describen información acerca del espacio del
Los modelos prescriptivos se enfocan al espacio de solución, o hacia las ciencias de la computación relacionadas con aspectos requeridos para implantar un
sistema en el dominio.
Los modelos dinámicos describen el comportamiento, el control o la secuencia temporal de actividades de un sistema.
Los métodos de análisis de dominios más nuevos utilizan modelos de objetos, apoyándose en las Últimas tecnologias de análisis orientado a objetos. Herramientas
de análisis y diseño orientado a objetos tales como UML, Rational Rose, Visio entre
otras.
37 Laura Alicia Hernández Moreno Cenidet 2003
-
Capítulo 3 I4 Marco teórico
3.3.1 Software legado I¡
Faisal y Santanu dan el concepto de software legado de la siguiente forma:
4 Faisal [FA198]. “Son programas que son criticos para /a operación de /as compañías, pero que fueron desarrollados en el lapso de varios años”,
4 Santanu [SAN95]. “Son sistemas de software muy largos, que a menudo corren en millones de líneas de código fuente y han sido adaptados, corregidos y mejorados
lentamente sobre el tiempo para adaptarlos a las necesidades cambiantes de, una
amplia base de usuarios”.
Faisal menciona que por lo general muchos de los sistemas que fueron desarrollados en el lapso de varios años, se crearon en plataformas tecnológicas que hoy
estan cayendo en desuso, tal es el caso de los sistemas hechos utilizando la
programación estructurada o por procedimientos, que se caracterizan por su arquitectura
monolitica y poco reutilizable.
:I
!,
ij
il
Otros programas se desarrollaron, cuando las tecnologías orientadas a objetos
comenzaban a aparecer, por lo cual, la falta de comprensión de estos conceptos
revolucionarios se tradujo en la implementación de disetios deficientes que no proporcionan las ventajas asociadas con estas tecnologías [CAS98].
A medida que las empresas han aceptado el paradigma de desarrollo basado en componentes y experimentado sus ventajas, los procesos de migración de software legado y la adquisición de componentes para el desarrollo de nuevas aplicaciones, han adquirido mayor interés. Por lo cual, podemos decir que la construcción de frameworks de componentes a partir de software legado es una.nueva línea d