Ultimo Caso De Estudio

Universidad Don Bosco Facultad de Ingeniería Escuela de Computación Ingeniería de Software Ciclo 02 / 2008

Caso de Estudio Número 3: “La Tecnología de la Ingeniería Inversa”.

Catedrático: Ing. Milton Narváez

Grupo Teórico: 01

Integrantes: Henríquez Serrano, Diana Margarita

HS040778

Iraheta Díaz, Ivon Annelly

ID051070

Martínez Rodríguez, Ricardo Marcel

MR050083

Rojas Moreno, Diana Margarita

RM040019

Sánchez Ramírez, Ruth Estela

SR050907

Viernes, 10 de octubre del 2008 1

1. ¿En que consiste el enfoque oportunísimo? Describa un ejemplo en el cual se pueda aplicar dicho enfoque.

El enfoque oportunísimo es un método de análisis que permite identificar los requisitos previamente considerados en el diseño de un sistema, para poder obtener los componentes más importantes de una aplicación. Permitiendo aprovechar al máximo dichos componentes, ya que selecciona los que ayudan a resolver el problema actual"

Ejemplo: "un software utilizado porque un banco puede ser perfectamente generado usando el enfoque oportunísimo, puesto que los procesos que en el se desarrollan serán los mismos, pues el modelado del negocio se mantiene o varia de forma poco significativa. Es por ello que para pasar a un nuevo sistema se agregan las nuevas funcionalidades que se necesitan

2. Describir el "modelo de vistas 4+1" a través de un ejemplo.

El modelo 4+1 consta de cuatro enfoques que nos ayudan a visualizar la parte arquitectónica de un sistema heredado del cual deseamos sacar la documentación para reimplementarlo. Esta excelente herramienta de la ingeniería inversa está consolidada por el enfoque de los escenarios con los cuales cada parte de las 4 se consolida en uno solo, y para esto ilustraremos con un ejemplo. En un sistema de administración de notas que fue concebido para fox pro y que solo funciona en una máquina con Windows 95 a esta altura de la vida está más que desfasado y la realidad no hay herramientas para extraer años de registros e implementar un nuevo sistema antes de que la máquina expire totalmente es imperante rescatar la estructura para continuar con el registro. Un buen punto de partida sería ver los escenarios más utilizados que pueden ser extraídos de la experiencia misma con el sistema, hacemos un listado detallado, 2

observando al usuario frecuente, si es que lo hay, y a partir de él podemos extraer la vista lógica elaborando un diagrama de clases que describa en buena medida los objetos que detectamos en el sistema, que en nuestro caso podríamos intuir que cada hoja de notas de cada grado individual no es más que una instancia de una posible clase llamada: hoja de notas. Es importante tener presente que pueda que no todas las posibles clases salgan en un primer momento, lo más natural es que al hacer éste análisis de manera iterativa cada vez vayan surgiendo nuevos objetos que modelar. Para continuar y siempre partiendo del análisis de escenarios y casos de uso detectados por la simple observancia de cómo se llevan a cabo los procesos del sistema. Con esta simple observancia y sumándole todas las posibles clases que hayamos obtenido de la vista lógica, podremos ver cuáles son los procesos de transito de información dentro de este. Esta parte tan importante es la vista de proceso con la cual vemos el flujo de la información dentro del sistema y consolidar el análisis. Esta parte pueda que lleve un componente mayor de definición porque en nuestro caso de ejemplo. Pueda que existan tratos de información tan transparentes para el usuario que no es tan evidente como se efectúan, aunque cuando uno ya tiene experiencia en la ingeniería directa podemos reconstruir estos procesos de manera que cumplan con la función. Ese es el objetivo principal, reconstruir de manera que funcione igual. Podemos pasar entonces a la fase de vista de desarrollo con la cual únicamente enlazamos los modelos obtenido con las dos vistas anteriores, y a la luz de los escenarios,

hacemos la interfaz teórica entre los que hemos encontrado y el

código fuente en si, puntualizando en los recursos físicos del nuevo sistema en su dimensión de implementación. En nuestro ejemplo ya habiendo refinado luego de algunas iteraciones los objetos y relaciones que tiene nuestros sistemas de notas, visualizamos el lenguaje o modo que convendría más al propósito, como siempre velando por el mejor aprovechamiento de recursos en función de la utilidad.

3

La última vista, la vista física, hace referencia a la parte tangible y un poco más operacional, puesta en marcha y detalles técnicos que si bien no son parte integrante de la dimensión operacional del sistema en si, son importantes para que el sistema no tenga problemas en su ejecución, en nuestro ejemplo, ver si existirá algún tipo de conexión con otro sistema, o si será un isla, en el caso de imprimir los reportes de notas, todos estos ya tienen el formato deseado para su presentación, todos estos detalles que son hasta cierto punto externos son importantes para el desempeño del nuevo sistemas. Es de resaltar la necesidad de tener bien definidos los casos de uso para todos y cada uno de los procesos del sistema, de esta manera y sabiéndolos integrar de buena manera, el documento resultante será la punta de la lanza en adaptar el sistema heredado a un nuevo nivel y sacarle el mejor provecho.

3. ¿Qué relación hay entre ingeniería inversa, reingeniería y UML? Amplíe su explicación a través de un ejemplo.

La reingeniería de software se define como la alteración de un sistema de software para reconstruirlo y reimplementarlo en una nueva forma en otras palabras lo que hace es tratar de mejorar una aplicación de manera que disminuya el costo de mantenimiento y ayude a manejar la información con mayor calidad. Para poder aplicar la reingeniería en un sistema heredado se hace a través del uso de la ingeniería inversa, la cual es hacer los pasos que se hacen normalmente en ingeniería del software solo que de forma inversa ya que esta se basa por medio del código heredado que se posee para conocer el dominio del problema. Para hacer que la reingeniería del software sea más fácil, se puede hacer uso de UML, que este hace mas fácil la tarea de integrar un código heredado a las nuevas arquitecturas que se están diseñando. Ejemplo. si tomamos el ejemplo de nuestro proyecto sobre el sistema de interrupciones programadas podemos notar que para poder realizarlo se tomaron como base algunas funciones de conexión y otras funcionalidades que existían en el modelo de

4

sistema en papel. En cuanto a algunas porciones de códigos de páginas que se encontraban en Internet, estás sirvieron para propósitos mas gnerales, como creación de tablas y otros efectos poco especifos del sistema, tal código se estudio bien, y se añadió a la arquitectura de la página que se estaba creando y para poder integrarlo y saber exactamente donde colocar esa parte de código se utilizaron los diagramas UML para poder ver más detalladamente que es lo que realmente necesitaba el cliente y como lo pedía el cliente.

5

4. Elabore un mapa conceptual en el que se resuma el artículo completo.

6

7