UNIVERSIDAD NACIONAL DEL ALTIPLANO

FACULTAD DE INGENIERÍA MECÁNICA ELÉCTRICA

ELECTRÓNICA Y SISTEMAS

ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS

HERRAMIENTA DE REUTILIZACIÓN DEL SOFTWARE

PARA EL SOPORTE OPERATIVO EN LA ESCUELA
PROFESIONAL DE INGENIERÍA DE SISTEMAS - U.N.A.
PUNO 2013

TESIS
PRESENTADO POR:
Julio Enrique Rojas Ramos

PARA OPTAR EL TÍTULO PROFESIONAL DE:

INGENIERO DE SISTEMAS

PUNO – PERÚ
2013
ÁREA: Informática
TEMA: Software de base de datos y de aplicación
 DEDICATORIA

Con mucho amor a mi mamá Yhobanna,

por su gratitud, esfuerzo y sacrificio conmigo.
A mi abuelo Amador, mi gran ejemplo a seguir.
A toda mi familia por su cariño inmensurable.
 AGRADECIMIENTOS

A mis maestros de Ingeniería de Sistemas

de la Universidad Nacional del Altiplano
por la calidad de sus saberes, su orientación,
su apoyo irrestricto y su sincera amistad.

A mis colegas de la Asociación de

Comunicadores Escolares del Sur Peruano (ACESP).

A quienes colaboraron
para que este trabajo se realizara con éxito.
 ÍNDICE

RESUMEN ......................................................................................................................................... 10
ABSTRACT ........................................................................................................................................ 11
INTRODUCCIÓN .............................................................................................................................. 12
CAPÍTULO I ........................................................................................................................................ 14
EL PROBLEMA ................................................................................................................................... 14
1 PROBLEMA DE INVESTIGACIÓN......................................................................................... 15
1.1 PLANTEAMIENTO DEL PROBLEMA. .................................................................................. 15
1.2 JUSTIFICACIÓN DEL PROBLEMA. ....................................................................................... 15
1.3 ANTECEDENTES DE LA INVESTIGACIÓN. ........................................................................ 16
1.4 OBJETIVOS. .............................................................................................................................. 18
1.4.1 OBJETIVO GENERAL. ...................................................................................................... 18
1.4.2 OBJETIVOS ESPECÍFICOS. ............................................................................................. 18
CAPÍTULO II ....................................................................................................................................... 19
FUNDAMENTACIÓN TEÓRICA .......................................................................................................... 19
2 MARCO TEÓRICO CONCEPTUAL. ....................................................................................... 20
2.1 MARCO TEÓRICO. .................................................................................................................. 20
2.1.1 REUTILIZACIÓN DEL SOFTWARE.................................................................................. 20
2.1.2 LA REUTILIZACIÓN EN INGENIERÍA DEL SOFTWARE. .............................................. 21
2.1.2.1 REUTILIZACIÓN Y COMPONENTES SOFTWARE. ............................................................................. 21
2.1.2.2 ARTEFACTOS REUTILIZABLES. ........................................................................................................ 24
2.1.3 ENFOQUES DE LA REUTILIZACIÓN. ............................................................................. 26
2.1.4 OBJETO DE LA REUTILIZACIÓN. ................................................................................... 27
2.1.5 NIVELES DE REUTILIZACIÓN. ....................................................................................... 32
2.1.5.1 CORTA-PEGA.................................................................................................................................. 32
2.1.5.2 CAJA NEGRA. ................................................................................................................................. 32
2.1.5.3 ACTIVOS REUTILIZABLES. ............................................................................................................... 32
2.1.5.4 ARQUITECTURAS. .......................................................................................................................... 33
2.1.5.5 REUTILIZACIÓN SISTEMÁTICA. ....................................................................................................... 33
2.1.6 EL PROCESO DE REUTILIZACIÓN................................................................................. 33
2.1.6.1 ETAPAS EN EL PROCESO DE REUTILIZACIÓN.................................................................................. 35
2.1.7 EL ENTORNO DE REUTILIZACIÓN. ............................................................................... 37
2.1.8 SOPORTE OPERATIVO. ................................................................................................... 38
2.1.9 REPOSITORIOS Y/O BIBLIOTECAS DE REUTILIZACIÓN. ........................................... 39
2.1.9.1 CONCEPTO..................................................................................................................................... 39
2.1.9.2 TIPOS DE REPOSITORIOS. .............................................................................................................. 40
2.1.9.2.1 REPOSITORIOS COMO SOPORTE A LAS FASES DE DESARROLLO. .......................... 40
2.1.9.2.2 REPOSITORIOS COMO ENTORNOS DE DESARROLLO. ................................................ 40
2.1.10 DESCRIPCIÓN DE COMPONENTES REUTILIZABLES. ................................................ 41
2.1.11 CLASIFICACIÓN / RECUPERACIÓN DE COMPONENTES. .......................................... 42
2.1.11.1 MÉTODO DE LAS CIENCIAS DE LA DOCUMENTACIÓN Y DE BIBLIOTECONOMIA. ...................... 43
2.1.11.1.1 CLASIFICACIÓN ENUMERADA O JERÁRQUICA. ........................................................ 44
2.1.11.1.2 CLASIFICACIÓN POR FACETAS. ..................................................................................... 45
2.1.11.1.3 CLASIFICACIÓN DE ATRIBUTOS Y VALORES............................................................. 48
2.1.11.2 MÉTODOS DE INTELIGENCIA ARTIFICIAL (BASADOS EN DATOS Y MODELOS DE
CONOCIMIENTO). ........................................................................................................................................... 48
2.1.11.2.1 MARCOS DE CONOCIMIENTO. ........................................................................................ 48
2.1.11.2.2 ESPECIFICACIONES FORMALES..................................................................................... 49
2.1.11.2.3 REDES NEURONALES. ...................................................................................................... 50
2.1.11.3 MÉTODOS BASADOS EN SISTEMAS DE HIPERTEXTO. ................................................................ 51
2.1.11.3.1 BROWSING. ......................................................................................................................... 51

5
 2.1.11.3.2 HIPERTEXTO. ...................................................................................................................... 52
2.1.12 BÚSQUEDA DE COMPONENTES.................................................................................... 53
2.1.12.1 REGLAS PARA CONSTRUIR EXPRESIONES DE BUSQUEDA. ........................................................ 53
2.1.12.2 OBJETO DE BUSQUEDA. ............................................................................................................ 55
CAPÍTULO III ..................................................................................................................................... 57
MÉTODO DE INVESTIGACIÓN .......................................................................................................... 57
3 METODOLOGÍA DE LA INVESTIGACIÓN. ......................................................................... 58
3.1 HIPÓTESIS. ............................................................................................................................... 58
3.1.1 HIPÓTESIS GENERAL. ..................................................................................................... 58
3.1.2 HIPÓTESIS ESPECÍFICAS................................................................................................ 58
3.2 OPERACIONALIZACIÓN DE VARIABLES. ......................................................................... 58
3.2.1 VARIABLES INDEPENDIENTES. ..................................................................................... 58
3.2.2 VARIABLE DEPENDIENTE. ............................................................................................. 58
3.2.3 INDICADORES E ÍNDICES DE RESPUESTA. ................................................................. 58
3.3 METODOLOGÍA. ...................................................................................................................... 59
3.4 TIPO DE INVESTIGACIÓN. .................................................................................................... 62
3.5 DISEÑO DE INVESTIGACIÓN. ............................................................................................... 62
3.6 POBLACIÓN. ............................................................................................................................ 62
3.7 MUESTRA. ................................................................................................................................ 62
3.8 MÉTODO DE INVESTIGACIÓN. ............................................................................................ 63
3.9 TÉCNICAS E INSTRUMENTOS. ............................................................................................. 63
3.10 MÉTODOS DE RECOPILACIÓN DE DATOS. ........................................................................ 63
3.11 TÉCNICAS DE ANÁLISIS DE DATOS. .................................................................................. 63
CAPÍTULO IV ...................................................................................................................................... 64
RESULTADOS DEL ESTUDIO............................................................................................................. 64
4 RESULTADOS Y DISCUSIÓN. ................................................................................................ 65
4.1 LENGUAJE DE PROGRAMACIÓN......................................................................................... 65
4.2 MODELAMIENTO.................................................................................................................... 65
4.2.1 REQUERIMIENTOS FUNCIONALES. .............................................................................. 65
4.2.2 DIAGRAMAS DE CASOS DE USO. ................................................................................... 66
4.2.2.1 CASO DE USO: PROCESO GENERAL................................................................................................ 66
4.2.2.2 CASO DE USO: EXPLORAR COMPONENTES EN EL REPOSITORIO. .................................................. 67
4.2.2.3 CASO DE USO: BUSCAR COMPONENTES EN EL REPOSITORIO. ...................................................... 68
4.2.2.4 CASO DE USO: RECUPERAR COMPONENTES DEL REPOSITORIO. .................................................. 69
4.2.2.5 CASO DE USO: INSERTAR COMPONENTES EN EL REPOSITORIO. ................................................... 70
4.2.2.6 CASO DE USO: ELIMINAR COMPONENTES DEL REPOSITORIO. ...................................................... 71
4.2.3 DIAGRAMA DE PAQUETES. ............................................................................................ 71
4.2.4 DIAGRAMA DE CLASES. .................................................................................................. 72
4.2.5 DIAGRAMAS DE SECUENCIA. ........................................................................................ 73
4.2.5.1 DIAGRAMA DE SECUENCIA GENERAL. ........................................................................................... 73
4.2.5.2 DIAGRAMA DE SECUENCIA PARA EL COMPONENTE “EXPLORAR”. ............................................... 74
4.2.5.3 DIAGRAMA DE SECUENCIA PARA EL COMPONENTE “BUSCAR”. ................................................... 75
4.3 DESCRIPCIÓN DEL MODELO. ............................................................................................... 76
4.3.1 LA INTERFAZ DEL SISTEMA. .......................................................................................... 76
4.3.2 ACCIÓN-EXPLORAR. ....................................................................................................... 78
4.3.3 ACCIÓN-BUSCAR. ............................................................................................................ 78
4.3.4 ACCIÓN-INSERTAR. ......................................................................................................... 80
4.3.5 ACCIÓN-RECUPERAR. ..................................................................................................... 81
4.3.6 ACCIÓN-ELIMINAR. ......................................................................................................... 82
4.4 COMPROBACIÓN DE LA APLICACIÓN. .............................................................................. 83
4.4.1 VALIDACIÓN DE LA APLICACIÓN MEDIANTE EL MODELO DE McCALL. .............. 83
4.4.1.1 FACTORES QUE DETERMINAN LA CALIDAD DE LA APLICACIÓN. ................................................... 83
4.4.2 APLICACIÓN DE LA METODOLOGÍA PARA EL MODELO. ......................................... 86
4.5 RESULTADOS DE LA ENCUESTA. ....................................................................................... 88

6
 4.5.1 CON RESPECTO A LA INTERFAZ DEL MODELO. ........................................................ 88
4.5.1.1 ¿La interfaz del usuario, te pareció agradable? ............................................................................. 88
4.5.1.2 ¿La distribución del menú, es comprensible? ............................................................................... 89
4.5.1.3 ¿Los iconos, son claros en su semántica? ...................................................................................... 90
4.5.1.4 ¿El diseño de pantallas es apropiado? .......................................................................................... 91
4.5.1.5 ¿La distribución de colores, es clara? ............................................................................................ 92
4.5.1.6 ¿Los mensajes son adecuados? ..................................................................................................... 93
4.5.1.7 ¿La ayuda es adecuada? ................................................................................................................ 94
4.5.2 CON RESPECTO A LA FUNCIONALIDAD DEL MODELO. ........................................... 94
4.5.2.1 ¿Es comprensible la distribución del repositorio? ......................................................................... 94
4.5.2.2 ¿Las opciones del menú, realizan correctamente su función? ...................................................... 96
4.5.2.3 ¿Es suficiente la información asociada a los componentes? ......................................................... 97
4.5.2.4 ¿La búsqueda de componentes candidato se realiza correctamente? ......................................... 98
4.5.2.5 ¿El resultado de la búsqueda de componentes, es congruente con su especificación numérica? 99
4.5.2.6 ¿El formato de ingreso de los datos del componente es adecuado? .......................................... 100
4.5.2.7 ¿La exploración del repositorio y sus catálogos es la más adecuada? ........................................ 101
4.5.2.8 ¿Existe congruencia entre el componente activo y los datos mostrados en la ficha múltiple? .. 102
4.5.2.9 ¿Midiendo en función del tiempo que porcentaje cree que ahorra utilizando este modelo? .... 103
CAPÍTULO V ..................................................................................................................................... 105
CONCLUSIONES Y RECOMENDACIONES ........................................................................................ 105
5 CONCLUSIONES. ................................................................................................................... 106
5.1 CON RESPECTO A LA HERRAMIENTA. ............................................................................ 106
5.2 CON RESPECTO AL MODELO. ............................................................................................ 106
5.3 RECOMENDACIONES. ......................................................................................................... 107
5.4 BIBLIOGRAFÍA. ..................................................................................................................... 108
5.5 ANEXO 1. ................................................................................................................................ 112
5.6 ANEXO 2. ................................................................................................................................ 116
5.7 ANEXO 3. ................................................................................................................................ 121

7
 ÍNDICE DE FIGURAS

FIGURA 2.1: TIPOS DE COMPONENTES QUE FORMAN LAS UNIDADES FUNDAMENTALES DE REUTILIZACIÓN. ........................ 22
FIGURA 2.2: EL PRINCIPIO DE ABSTRACCIÓN. ........................................................................................................ 29
FIGURA 2.3: ACTIVIDADES DE REUTILIZACIÓN PARA EL PRODUCTOR Y EL CONSUMIDOR DE UN COMPONENTE. .................... 34
FIGURA 2.4: LA REUTILIZACIÓN Y EL PROCESO DE PRODUCCIÓN DE SOFTWARE............................................................. 39
FIGURA 2.5: ESQUEMA SIMPLIFICADO DE CLASIFICACIÓN/RECUPERACIÓN DE COMPONENTES. ........................................ 43
FIGURA 2.6: UNA TAXONOMÍA DE MÉTODOS DE INDIZACIÓN PROCEDENTE DE LA BIBLIOTECONOMÍA................................ 44
FIGURA 2.7: EJEMPLO DE ESQUEMA DE CLASIFICACIÓN JERÁRQUICA. ........................................................................ 45
FIGURA 4.1: INTERFAZ DEL MODELO. .................................................................................................................. 76
FIGURA 4.2: ACCIÓN-EXPLORAR. ....................................................................................................................... 78
FIGURA 4 3: ACCIÓN-BUSCAR............................................................................................................................ 79
FIGURA 4.4: ACCIÓN-INSERTAR. ........................................................................................................................ 80
FIGURA 4.5: ACCIÓN-RECUPERAR. ..................................................................................................................... 81
FIGURA 4.6: ACERCA DE LA INTERFAZ DEL USUARIO................................................................................................ 88
FIGURA 4.7: ACERCA DE LA DISTRIBUCIÓN DEL MENÚ ............................................................................................. 89
FIGURA 4.8: ACERCA DE LA SEMÁNTICA DE LOS ICONOS .......................................................................................... 90
FIGURA 4.9: ACERCA DEL DISEÑO DE PANTALLAS ................................................................................................... 91
FIGURA 4.10: ACERCA DE LA DISTRIBUCIÓN DE COLORES ......................................................................................... 92
FIGURA 4.11: ACERCA DE LOS MENSAJES ............................................................................................................. 93
FIGURA 4.12: ACERCA DE LA AYUDA ................................................................................................................... 94
FIGURA 4.13: CON RESPECTO A LA DISTRIBUCIÓN DEL REPOSITORIO .......................................................................... 95
FIGURA 4.14: ACERCA DE LA CORRECTA FUNCIONALIDAD DE LAS OPCIONES DEL MENÚ.................................................. 96
FIGURA 4.15: ACERCA DE LA INFORMACIÓN ASOCIADA A LOS COMPONENTES ............................................................. 97
FIGURA 4.16: ACERCA DE LA BÚSQUEDA DE COMPONENTES .................................................................................... 98
FIGURA 4.17: CON RESPECTO AL RESULTADO DE LA BÚSQUEDA Y SU ESPECIFICACIÓN NUMÉRICA..................................... 99
FIGURA 4.18: ACERCA DEL INGRESO DE DATOS DEL COMPONENTE .......................................................................... 100
FIGURA 4.19: ACERCA DE LA EXPLORACIÓN DEL REPOSITORIO Y SUS CATÁLOGOS ....................................................... 101
FIGURA 4.20: ACERCA DE LA CONGRUENCIA ENTRE EL COMPONENTE Y LA FICHA MÚLTIPLE .......................................... 102
FIGURA 4.21: PORCENTAJE DE AHORRO DE TIEMPO ............................................................................................. 103

8
 ÍNDICE DE TABLAS

Tabla 2.1: Visión General de la Reutilización………………………………………………………………………………………... 27

Tabla 2.2: Reglas para construir expresiones de búsqueda…………………………………………………………………… 55
Tabla 4.1: Principales métodos de análisis y de diseño orientado a objetos……………………………………….... 60
Tabla 4.2: Comparación de las técnicas de las diferentes metodologías orientadas a objetos……………... 61
Tabla 4.3: Principales Características de los Lenguajes Orientados a Objetos…………………………………….… 65
Tabla 6.1. Factores y Métricas para medir la calidad del modelo…………………………………………………………. 86

9
 RESUMEN

En este trabajo de investigación se describe la importancia de la reutilización de los

procesos y proyectos para conseguir una mejora continua de los procesos de
desarrollo y mantenimiento de software utilizadas por pequeñas y medianas
empresas dedicadas a la construcción y desarrollo de software, facilitando de esta
manera, la obtención por parte de las mismas, de altos niveles de madurez.

Aunque la reutilización de definiciones de procesos y proyectos software supone un

gran beneficio para el desarrollo del software no se encuentra disponible en ninguna
herramienta que facilite su reutilización efectiva. En este trabajo se han identificado
los factores que caracterizan a los diferentes tipos de procesos y proyectos software,
se han analizado, comparado y contrastado. Posteriormente, se han agrupado en
grupos de factores siguiendo criterios de similitud. Además, en el presente trabajo
se propone un método para la recuperación efectiva de procesos y proyectos
software a partir de la especificación, a alto nivel, de sus características generales.

Este método de reutilización ha servido como base para la creación de una

herramienta con soporte efectivo para la recuperación de componentes software,
así como la gestión de los mismos, con el único afán de lograr una mejora continua
de los procesos software.

10
 ABSTRACT

In this research paper describes the importance of the reuse of processes and
projects to achieve continuous improvement of the processes of development and
maintenance of software used by small and medium companies engaged in the
construction and development of software, facilitating in this way, obtaining by
them, of high levels of maturity.

Although the reuse of definitions of processes and software projects is a great

benefit for the development of the software it is not available in any tool that
facilitates effective reuse. This work identified the factors that characterize different
types of processes and software projects, have been analyzed, compared and
contrasted. Subsequently, they have grouped in sets of factors according to criteria
of similarity. Furthermore, this work is proposed a method for the effective recovery
of processes and projects software from specification, high level of their general
characteristics.

This method of reuse has served as basis for the creation of a tool with affective
support for the recovery of software components, as well as the management of the
same, with the only intention of achieving continuous improvement in the software
process.

11
 INTRODUCCIÓN

Sabemos que la reutilización es por defecto la estrategia de resolución de problemas

en la mayoría de las actividades del ser humano. Los científicos cognitivos coinciden
en afirmar que lo primero que hacemos cuando enfrentamos un problema es
determinar si éste ha sido resuelto antes; en caso contrario, buscamos en nuestro
espacio mental problemas análogos que ya se han resuelto y adaptamos su solución
al problema actual; cuando ninguna de las anteriores situaciones se cumple,
utilizamos entonces las habilidades y el conocimiento general analítico para
resolución de problemas.

La reutilización de software es considerada una tecnología capaz de reducir

drásticamente los costes de producción y los tiempos de desarrollo. La idea de base
es común a otras ramas de la ingeniería y consiste simplemente en reutilizar el
trabajo hecho en proyectos precedentes para evitar realizar varias veces el mismo o
similar trabajo. Sin embargo, hasta el momento, pocos programas de reutilización
se pueden considerar verdaderamente fructíferos. Los resultados conseguidos son
sólo parciales y no producen las significativas mejoras prometidas.

En el campo de la ingeniería de software la reutilización ofrece un gran potencial en

términos de productividad y calidad del software. La automatización del proceso
software es el medio para asegurar la consistencia en la ejecución del proceso y para
reducir costes. Esta automatización debe incluir las herramientas apropiadas para
ejecutar las tareas específicas, la eliminación de errores y una guía para realizar las
actividades críticas. Todo este soporte debe permitir que los desarrolladores se
centren en el aspecto creativo de su trabajo y no estar perdiendo más tiempo en
crear un software desde sus inicios, ahorrando con esto una muy valiosa cantidad
de horas y días al desarrollar el software.

Por otra parte, la mayor dificultad en el éxito de la instauración de un programa de

reutilización reside en los cambios de organización y cultura de la empresa. Por lo

12
tanto, la introducción de prácticas de reutilización de software debe abordarse
principalmente desde la perspectiva del proceso de producción de software,
considerando la reutilización como parte esencial del modo de operar de la
organización. Es por estas razones que este trabajo centra su atención en temas de
soporte operativo al proceso de reutilización de software.

Este método de reutilización ha servido como base para la creación de una

herramienta con soporte efectivo para la recuperación de componentes software,
así como la gestión de los mismos, con el único afán de lograr una mejora continua
de los procesos software.

El presente trabajo de investigación se estructura en cinco capítulos:

El Capítulo I: Contiene el planteamiento de problema y su justificación, los

antecedentes y los objetivos de la investigación.

El Capítulo II: Refiere a la fundamentación teórica y al marco teórico conceptual

utilizado para realizar el presente trabajo de investigación.

El Capítulo III: Describe el método de investigación, la operacionalización de

variables y las hipótesis de la investigación.

El Capítulo IV: Expone y analiza los resultados de la investigación.

El Capítulo V: Da a conocer las conclusiones y recomendaciones obtenidas al realizar

la investigación.

Finalmente las referencias bibliográficas y los anexos.

13
 CAPÍTULO I
EL PROBLEMA

14
1 PROBLEMA DE INVESTIGACIÓN.

1.1 PLANTEAMIENTO DEL PROBLEMA.

La reutilización de sóftware es cónsiderada una tecnólógía capaz de reducir

drasticamente lós cóstes de próducción y lós tiempós de desarrólló. La idea de
base es cómun a ótras ramas de la ingeniería y cónsiste simplemente en
reutilizar el trabajó hechó en próyectós precedentes para evitar realizar varias
veces el mismó ó similar trabajó. Sin embargó, hasta el mómentó, pócós
prógramas de reutilización se pueden cónsiderar verdaderamente fructíferós.
Lós resultadós cónseguidós són sóló parciales y nó próducen las significativas
mejóras prómetidas.

La autómatización del prócesó sóftware es el medió para asegurar la

cónsistencia en la ejecución del prócesó y para reducir cóstes. Esta
autómatización debe incluir las herramientas aprópiadas para ejecutar las
tareas específicas, la eliminación de erróres y una guía para realizar las
actividades críticas. Tódó este sópórte debe permitir que lós desarrólladóres se
centren en el aspectó creativó de su trabajó.

Pór ótra parte, la mayór dificultad en el exitó de la instauración de un prógrama

de reutilización reside en lós cambiós de órganización y cultura de la empresa.
Pór ló tantó, la intróducción de practicas de reutilización de sóftware debe
abórdarse principalmente desde la perspectiva del prócesó de próducción de
sóftware, cónsiderandó la reutilización cómó parte esencial del módó de óperar
de la órganización. Es pór estas razónes que este trabajó centra su atención en
temas de sópórte óperativó al prócesó de reutilización de sóftware.

Cónsiderandó las cóndiciónes expuestas y la impórtancia de tratar el próblema

de la reutilización del sóftware, se fórmula la siguiente interrógante:

¿Es posible desarrollar una herramienta de reutilización del software para

el soporte operativo?

1.2 JUSTIFICACIÓN DEL PROBLEMA.

15
 - La investigación apórta una cóntribución academica util a la fórmulación de
una metódólógía de desarrólló de sóftware para y cón reutilización.

- La reutilización juega un papel clave en variós temas cómó són: la

próductividad, la capacidad de mantenimientó, la pórtabilidad y la calidad.
Pór elló la reutilización debe aplicarse a cada etapa del cicló de vida.

- La sólución del próblema servira para que lós desarrólladóres de

aplicaciónes tengan una referencia del enfóque de reutilización que
satisfaga sus expectativas, así cómó tambien una guía a seguir en el disenó
de sus aplicaciónes cón y para reutilización.

- Asimismó, el próblema a investigarse pósee una óriginalidad específica,

tóda vez que aun nó ha sidó estudiadó, cuandó menós en la Escuela
Prófesiónal de Ingeniería de Sistemas de la Universidad Naciónal del
Altiplanó.

1.3 ANTECEDENTES DE LA INVESTIGACIÓN.

Habiendó realizadó una busqueda en las bibliótecas de la Escuela Prófesiónal de

Ingeniería de Sistemas de la Universidad Naciónal del Altiplanó, nó se ha
encóntradó ningun trabajó similar ó en el area de investigación.

Mas en internet se lógró encóntrar lós siguientes trabajós de investigación:

Granell, (2006), realizó la investigación: Reutilización de servicios web mediante

componentes integrados, en la Universidad Jaume I., Departamentó de Lenguajes
y Sistemas Infórmaticós. La investigación llegó a las siguientes principales
cónclusiónes:

- El óbjetivó y cóntribución mas impórtante de esta tesis fue el apórtar una

apróximación para la cómpósición de serviciós web cón el fin de facilitar el
desarrólló de aplicaciónes web basadas en serviciós flexibles y reutilizables,
que integra las características mas relevantes sóbre reutilización presente en
lós sistemas basadós en cómpónentes sóftware; apórtandó tambien a la

16
 creación, cómpósición y reutilización de cómpónentes integradós para
transfórmarlós finalmente en prócesós ejecutables.

López, (2010), realizó la investigación: Reutilización del Software a partir de

Requisitos Funcionales en el Modelo de Mecano: Comparación de Escenarios, en el
Institutó Tecnólógicó de Cósta Rica, Miguel Angel Laguna, Jóse Manuel Marques
- Universidad de Valladólid. La investigación llegó a las siguientes principales
cónclusiónes:

- Este artículó própóne una apróximación para incórpórar el prócesó de

reutilización desde las etapas iniciales del cicló de vida del sóftware. La
própuesta se basa en generalizar escenariós del próblema y cómpararlós cón
escenariós genericós. Lós primerós se óbtienen cón una herramienta
autómatizada que esta en fase de desarrólló. La generalización se realiza
mediante reducción de redes de Petri. Lós escenariós genericós se almacenan
en un repósitórió asóciadós a estructuras cómplejas de reutilización
denóminadas mecanós que enlazan elementós de analisis, disenó e
implementación. La cómparación se realiza mediante analógía. De este módó,
cón una estrategia para reutilizar sóftware desde lós requisitós funciónales,
se ófrece una alternativa para acelerar el desarrólló de sóluciónes sóftware
cón reutilización a la vez que se eleva el nivel de abstracción de lós elementós
reutilizables. La mótivación principal del artículó es que lós requisitós
representan el cónócimientó mas abstractó del dóminió y un altó pórcentaje
de ellós són reutilizables.

17
1.4 OBJETIVOS.

1.4.1 OBJETIVO GENERAL.

- Desarróllar una herramienta de reutilización del sóftware para el

sópórte óperativó en la Escuela Prófesiónal de Ingeniería de Sistemas
de la U.N.A. - Punó.

1.4.2 OBJETIVOS ESPECÍFICOS.

- Mótivar el estudió de lós principiós y cónceptós de familia inherentes

al enfóque de reutilización.

- Definir lós pasós necesariós para la adópción de lós prócesós

órientadós a la reutilización.

- Implementar un módeló de una herramienta que permita la

reutilización del sóftware para el sópórte óperativó.

18
 CAPÍTULO II
FUNDAMENTACIÓN TEÓRICA

19
2 MARCO TEÓRICO CONCEPTUAL.

2.1 MARCO TEÓRICO.

2.1.1 REUTILIZACIÓN DEL SOFTWARE.

La reutilización es pór defectó la estrategia de resólución de próblemas

en la mayóría de las actividades del ser humanó. Lós científicós
cógnitivós cóinciden en afirmar que ló primeró que hacemós cuandó
enfrentamós un próblema es determinar si este ha sidó resueltó antes;
en casó cóntrarió, buscamós en nuestró espació mental próblemas
analógós que ya se han resueltó y adaptamós su sólución al próblema
actual; cuandó ninguna de las anterióres situaciónes se cumple,
utilizamós entónces las habilidades y el cónócimientó general analíticó
para resólución de próblemas (Mili, Mili, & Mili, 1995). Se puede hablar
de reutilización en diferentes gradós: reutilización infórmal e intuitiva
que se basa en el cónócimientó individual de las persónas, reutilización
esquematizada pór medió de la utilización de prócedimientós que guían
el desarrólló de actividades y reutilización órientada a próductós cuandó
se cóncreta en artefactós que representan el cónócimientó y que facilitan
la labór de reutilizar.

En el campó de la ingeniería de sóftware la reutilización ófrece un gran

pótencial en terminós de próductividad y calidad del sóftware.
Próductividad, pórque amplifica la capacidad de prógramación, en el
sentidó de escribir menós códigó, reduce la cantidad de dócumentación
y pruebas que se deben realizar y genera un efectó de sinergia sóbre la
funciónalidad del sistema cómpletó a partir de la funciónalidad de sus
cómpónentes. Calidad, pórque el disenó de cómpónentes se realiza
pensandó en su pósteriór utilización, cón una dócumentación precisa,
cón prócesós certificadós de prueba y validación y cón una
estructuración adecuada de las partes del cómpónente para que sea
entendible pór el usuarió.

20
 La demanda de sistemas de infórmación cada vez mas cómplejós, la
dinamica de cambió en las órganizaciónes y la glóbalización de las
óperaciónes del negóció bajó unas restricciónes de tiempó, cóstó y
calidad, hacen de la reutilización, una necesidad imperiósa dentró de
tódó prócesó de ingeniería de sóftware. En este cóntextó la reutilización
puede ser definida cómó la própiedad de utilizar cónócimientó, prócesós,
metódólógías ó cómpónentes de sóftware ya existente para adaptarló a
una nueva necesidad, incrementandó significativamente la calidad y
próductividad del desarrólló (Frakes & Terry, 1996).

2.1.2 LA REUTILIZACIÓN EN INGENIERÍA DEL SOFTWARE.

2.1.2.1 REUTILIZACIÓN Y COMPONENTES SOFTWARE.

La reutilización es el hechó de apróvechar lós próductós del

prócesó de desarrólló de una aplicación en ótra -entendiendóse
pór próductó cualquier pórción de la definición ó de la
implementación de una aplicación-. Un próductó reutilizable
debe llenar dós requerimientós basicós. Primeró, el próductó nó
debera depender del cóntextó en el cual se utilice. Segundó, el
próductó debera ser util tambien en ótras aplicaciónes. Un
cómpónente es cualquier próductó que cumpla cón estós
requisitós. Pór ló tantó un cómpónente es un próductó diferente
y util para el desarrólló.

Lós cómpónentes, pór ló tantó, són las unidades fundamentales

de reutilización. La capacidad de lócalizar y apróvechar
cómpónentes utiles determina su capacidad de reutilización en
una aplicación. En la figura 2.1 se ilustran distintós tipós de
cómpónentes. El prócesó de desarrólló genera próductós utiles
en tódas sus fases. De ahí que se generen cómpónentes tantó de
la especificación cómó de la implementación de una aplicación.

21
 Habitualmente lós cómpónentes són dócumentós en papel ó
archivós digitales.

Fuente Producto Reutilizable

ksdfk Cuenta
Cargo()
dsfkñkdf credito()
dsfsdf saldo()
dsfdsf
dsferew

Tipos de Patrones y
Requerimi entos Diseños
Objeto Modelos

ksdfk
dsfkñkdf Acct.cpp
Act.cp Tr.cpp File
dsfsdf
dsfdsf
dsferew Cli.cpp
print: sads
c=0

Cdigo Marcos
Clases Aplicaciones
Fuente estructurales

FIGURA 2.1: TIPOS DE COMPONENTES QUE FORMAN LAS UNIDADES FUNDAMENTALES

DE REUTILIZACIÓN.

Lós cómpónentes de especificación describen algun aspectó del

próblema ó de la estructura de la aplicación. Lós cómpónentes
típicós de especificación incluyen dócumentós de
requerimientós, tipós de óbjetós, patrónes ó módelós y disenós
cómpletós. Pór definición tódós estós cómpónentes són
elementós de especificación independientes. Un desarrólladór
debería ser capaz de cómprender un cómpónente
independientemente de la aplicación en la que se utilice. Sin
embargó, se puede cónstruir cómpónentes partiendó de ótrós
cómpónentes. Estó permite la elabóración de una jerarquía de
subcómpónentes y de cómpónentes mas cómplejós. Pór ejempló

22
se puede cónstruir patrónes y módelós a partir de tipós de
óbjetós, ó un disenó que cómprenda variós módelós diferentes.

Lós cómpónentes de especificación pueden ser mas ó menós

fórmales. Pór ejempló lós requerimientós de aplicación se
pueden cónstruir, se pueden escribir cómó textó infórmal ó
expresarse en nótación grafica, utilizandó una sintaxis y una
semantica definida. Aunque esta variante en la fórmalidad del
cómpónente nó impide su utilización, sí afectara su capacidad de
reutilización. Un cómpónente especificadó cón sintaxis fórmal
resultara pór ló regular mas facil de reutilizar y de mantener. Sin
embargó, la fórmalización incrementa el cóstó de cónstrucción
del cómpónente. Este equilibrió entre cóstó de desarrólló inicial
y reutilización futura es una cónsideración clave en la
especificación de cómpónentes.

Lós cómpónentes de implementación deben ser ejecutables ó

traducidós directamente a una fórma ejecutable. Estós incluyen
unidades reutilizables, cómó códigó fuente, clases, marcós
estructurales y aplicaciónes. Ademas, un cómpónente de
implementación pódría incluir ótrós cómpónentes, pór ejempló,
la cónstrucción de un marcó estructural de aplicación a partir de
clases cónstitutivas.

Lós cómpónentes de especificación y lós de implementación són

impórtantes en la reutilización. Sin embargó, a la fecha, tantó lós
investigadóres, cómó la industria han centradó su atención en
lós cómpónentes de implementación. La reutilización de clases,
bibliótecas de clases y marcós estructurales es ya un prócesó
relativamente bien cómprendidó. Aun así, en razón de que la
reutilización destaca el póder de lós próductós existentes, lós
cómpónentes de especificación deberían própórciónar mayóres
beneficiós. Las especificaciónes de analisis representan
cónócimientó sóbre el próblema y són independientes de la
tecnólógía de implementación. Esta cómprensión fundamental

23
 de un dóminió es habitualmente estable y sólamente evólucióna
cón el tiempó.

2.1.2.2 ARTEFACTOS REUTILIZABLES.

Ya se ha indicadó que la reutilización del sóftware abarca algó

mas que el simple códigó fuente. ¿Pero cuánto más? Capers
Jónes define diez artefactós del sóftware que són candidatós
para la reutilización:

- Planes de proyecto. La estructura basica y gran parte del

cóntenidó (pór ejempló: el plan SQA) de un plan de próyectó
de sóftware se pódran reutilizar entre próyectós sucesivós.
Estó reduce el tiempó necesarió para desarróllar el plan y la
incertidumbre asóciada al establecimientó de planes
tempórales, al analisis de riesgós, y ótras características.

- Estimaciones de coste. Dadó que es frecuente implementar

funciónes similares en distintós próyectós, quiza sea pósible
reutilizar las estimaciónes para esas funciónes cón pócas
módificaciónes ó quiza cón ninguna.

- Arquitecturas. Existen relativamente pócós prógramas y

pócas arquitecturas de datós distintas aun cuandó se
cónsideren distintós prógramas de aplicación. Es pósible
crear un cónjuntó de plantillas arquitectónicas genericas (pór
ejempló: una arquitectura de prócesamientó de
transacciónes) y se pueden establecer esas plantillas cómó
entórnós reutilizables para el disenó.

- Especificaciones y modelos de requisitos. Lós módelós y

especificaciónes de clases y óbjetós són candidatós evidentes
para la reutilización. Ademas, lós módelós de analisis (pór
ejempló: lós diagramas de flujó de datós) desarrólladós
empleandó enfóques cónvenciónales de ingeniería del
sóftware tambien se pueden reutilizar.

24
- Diseños. Lós disenós arquitectónicós, de datós, de interfaz y
de prócedimientós desarrólladós empleandó metódós
cónvenciónales són candidatós para la reutilización. Cón mas
frecuencia lós disenós de sistemas y de óbjetós van a ser
reutilizadós.

- Código fuente. Lós cómpónentes verificadós de prógrama

escritós en lenguajes de prógramación cómpatibles són
candidatós para la reutilización.

- Documentación del usuario y técnica. Suele ser pósible

reutilizar grandes pórciónes de la dócumentación de usuarió
y tecnica, aun cuandó las aplicaciónes específicas sean
distintas.

- Interfaces humanas. Siendó pósiblemente el artefactó del

sóftware mas ampliamente reutilizadó, el sóftware de IGU se
reutiliza cón frecuencia. Dadó que puede dar cuenta de casi
un 60 pór cientó del vólumen de códigó de las aplicaciónes,
lós beneficiós de su reutilización són significativós.

- Datos. Entre lós artefactós mas frecuentemente reutilizadós,

lós datós abarcan las tablas internas, listas y estructuras de
registrós, así cómó lós archivós y bases de datós cómpletas.

- Casos de prueba. Siempre que es precisó reutilizar un disenó

ó un cómpónente de códigó, el casó de prueba relevante
debera de estar “asóciadó” a el.

Es impórtante tener en cuenta que la reutilización va mas alla de

lós artefactós suministrables que se describían mas arriba, y que
incluye tambien elementós del prócesó de ingeniería del
sóftware. Lós metódós específicós de módeladó de analisis, las
tecnicas de inspección, las tecnicas de disenó de casós de prueba,
lós prócedimientós de cóntról de calidad y muchas ótras
aplicaciónes de la ingeniería del sóftware se pueden “reutilizar”.

25
2.1.3 ENFOQUES DE LA REUTILIZACIÓN.

Són variadas las apróximaciónes, enfóques y cónsideraciónes que

diferentes autóres dan al tema de la reutilización. La tabla 2.1 presenta
una visión general del tratamientó de la reutilización cónsiderandó
diferentes aspectós (Frakes & Terry, 1996).

La apróximación tecnólógica se refiere a la tecnica utilizada para

desarróllar cómpónentes. El enfóque metódólógicó representa la manera
cómó se integra la reutilización dentró del prócesó mismó de desarrólló.
La módificación sugiere la fórma cómó lós cómpónentes són accedidós y
manipuladós para adecuarlós a nuevas necesidades. El alcance de
desarrólló indica si la reutilización sóló se aplica a cómpónentes internós
ó permite integrar cómpónentes de ótras bibliótecas. El alcance del
dóminió delimita la reutilización a una familia de sistemas ó permite su
aplicación entre diferentes dóminiós de aplicación. El óbjetó de
reutilización se refiere a lós diferentes enfóques que diversós autóres
própónen al cónsiderar la reutilización: desde el puntó de vista del
prócesó de desarrólló, cónsiderandó el nivel de abstracción del
cómpónente ó segun el tipó de cónócimientó que se reutiliza.

FACETA TIPO DESCRIPCION

Parte de una especificación del problema que va siendo
Por generación
Aproximación refinada en iteraciones sucesivas.
tecnológica Utiliza pequeñas partes de software como invariantes para
Por composición
proveer funcionalidad variante por medio de su integración.

26
 Desarrollo con Centrado en el desarrollo de componentes adecuados para
reutilización ser utilizados en un problema específico - visión proveedor.
Enfoque
Centrado en el proceso mismo de construcción de soluciones
metodológico Desarrollo para
software a partir de componentes almacenadas en una
reutilizar
biblioteca-visión demanda.
Componentes que son reutilizados por modificación y
Caja blanca
adaptación.
Componentes que son reutilizados sin ninguna
Caja negra
Modificación modificación.
Utiliza estructuras grandes de software como invariantes y
Adaptativo restringe la variabilidad a un conjunto de argumentos o
parámetros.
Mide el nivel de reutilización de componentes de un
Interno
repositorio interno o de componentes del mismo proyecto.
Alcance del
Mide el nivel de reutilización de componentes que provienen
desarrollo
Externo de repositorios externos o la proporción de productos que
fueron adquiridos.
Alcance del Vertical Reutilización dentro del mismo dominio de aplicación.
dominio Horizontal Reutilización dentro de dominios de aplicación diferentes.
Según la etapa en el ciclo de vida en la cual el conocimiento
Según el estado es producido o reutilizado.
del proceso de
desarrollo Tecnologías de reuso de amplio espectro y de limitado
espectro (Biggerstaff).
Según la propiedad del componente de representar
conceptos abstractos, concretos o implementados.
Según el nivel de Código reciclado, componentes de código, esquemas
Objeto de abstracción (Frakes).
reuso Código fuente, diseño, especificación, objetos, texto,
arquitecturas (Prieto-Díaz).
Según el tipo de conocimiento que se reutiliza concretado en
artefactos o habilidades.
Según la
naturaleza del Artefactos reutilizables: datos, arquitecturas, diseño,
conocimiento programas (Jones)
Naturaleza del conocimiento: informal, esquematizado,
herramientas y productos (Basili).
Tabla 2.1: Visión General de la Reutilización

2.1.4 OBJETO DE LA REUTILIZACIÓN.

En este apartadó se hace enfasis en el óbjetó de la reutilización desde la

perspectiva del nivel de abstracción del cómpónente. Ló que diferencia
un tipó de cómpónente de ótró es su nivel de abstracción. En terminós
generales cuantó mas altó sea el nivel de abstracción, la pótencialidad
para entender, redefinir y adaptar sera mayór. Es impórtante entónces
cónsiderar la efectividad de la abstracción en una tecnica de reutilización
de sóftware. Krueger evalua esta característica en terminós del esfuerzó
intelectual requeridó para utilizar el cómpónente (Krueger, 1992). Las

27
mejóres abstracciónes significan que el usuarió requiere menós esfuerzó
para su utilización. La distancia cógnitiva es definida cómó la cantidad de
esfuerzó intelectual realizadó pór lós desarrólladóres para tómar un
cómpónente de sóftware en un estadó y llevarló a ótró estadó; aunque nó
es una medida fórmal que puede ser expresada en numerós y unidades
da una nóción intuitiva del esfuerzó de reutilizar.

Tóda abstracción de sóftware tiene dós niveles (figura 2.2). El nivel mas
altó se refiere a la especificación de la abstracción y el nivel mas bajó se
refiere a la realización de la abstracción, que nó necesariamente se trata
del códigó fuente. A su vez, una abstracción debe estar cónfórmada pór
una parte óculta (h), una parte variable (v) y una parte fija (f). La parte
óculta cóntiene detalles de realización de la abstracción que nó són
visibles en el nivel de especificación de la abstracción; la parte variable
representa las características módificables en la realización de la
abstracción y la parte fija representa las própiedades de la abstracción
que determinan su cómpórtamientó basicó. En la figura 2.2, se tiene un
artefactó X cón dós abstracciónes M y L, cón su respectiva distancia
cógnitiva (dc1, dc2). Si la abstracción M es pór ejempló la especificación
estructural de una venta escrita en un módeló entidad-relación, la
realización de esta abstracción sera el esquema lógicó de la base de datós
que sera a la vez la especificación L del siguiente nivel; la realización de
L sera, pór ejempló, una representación en estructuras de registrós del
esquema lógicó. A cóntinuación se describen lós principales óbjetós de
reutilización y su evaluación frente al esfuerzó requeridó para su
reutilización.

28
 FIGURA 2.2: EL PRINCIPIO DE ABSTRACCIÓN.

Código Reciclado.

Es la apróximación primitiva de reutilización dónde lós prógramadóres

recuperan códigó fuente generalmente cónstruidó pór ellós mismós en
desarróllós anterióres cón el própósitó de reducir el esfuerzó de disenó,
escritura y prueba del nuevó sóftware. La reutilización esta óriginada pór
la experiencia y capacidad del prógramadór de recórdar desarróllós
anterióres que guardan analógía cón el nuevó próblema. En estós casós
generalmente la persóna que reutiliza es la misma que cónstruye ló cual
disminuye la distancia cógnitiva.

Componentes de Código.

Esta fue la nóción inicial de reutilización que intródujó McIlóry:

cómpónentes de códigó adquiridós cón el própósitó de ensamblarlós
para cónstruir nuevó sóftware. Estós cómpónentes són escritós,
evaluadós y almacenadós específicamente cón el própósitó de ser
reutilizadós. Lós lenguajes de prógramación órientadós a óbjetós
impulsarón cónsiderablemente este tipó de reutilización. Hóy en día, són
innumerables las librerías que se distribuyen cón una funciónalidad
específica y módularizada pór naturaleza a traves de la definición de

29
clases. Pór el principió de encapsulación, la definición de la interfaz de
lós metódós (nómbre, argumentós de entrada y argumentós de salida)
que ófrece cada clase, permite un acercamientó gradual al códigó sin
tener que cónócer lós detalles de implantación de cada metódó. En ótras
palabras, la definición de clase es un mecanismó de abstracción que
separa las própiedades de la clase (especificación) de sus instancias
(realización). Sin embargó, en este tipó de reutilización, las clases y
metódós representan unidades de reutilización a muy pequena escala,
óriginandó un próblema de cómpósición para ensamblar una
funciónalidad util en el dóminió del próblema. La distancia cógnitiva
depende del gradó de familiaridad que el prógramadór tiene de las
bibliótecas de clase, algunas de las cuales nó ófrecen una dócumentación
adecuada.

Esquemas.

Enfatiza la utilización de abstracciónes para representar una sólución

sóftware a un altó nivel de abstracción. El esquema describe un cónjuntó
de especificaciónes escritas bajó determinadó fórmalismó (módeló
entidad relación, diagramas de flujós de datós, diagramas de clases,
especificaciónes fórmales etc.) que recibe el nómbre de módeló
cónceptual. La reutilización de estós módelós permite que el analista
apróveche especificaciónes ya existentes y validadas para la cónstrucción
de nuevas especificaciónes. El altó nivel de abstracción de la
especificación reduce cónsiderablemente la distancia cógnitiva entre el
requerimientó y la implementación de algóritmós y estructuras de datós.
La mayóría de próductós y esfuerzós de investigación de reutilización a
altó nivel se cóncentran en la reutilización de módelós cónceptuales.

El trabajó de Altmeyer define módelós cónceptuales en diferentes

fórmalismós órientadós a dóminiós específicós y un entórnó de
desarrólló que permite derivar y caracterizar nuevós módelós (Altmeyer
& Otrós, 1997). El trabajó de Ruggia utiliza módelós entidad–relación
extendidós y próvee un cónjuntó de herramientas que ófrecen serviciós
de reutilización (Ruggia & Ambrósió, 1997). Trabajós cómó el de

30
Ambrósió (Ambrósió, 1996) y Castanó (Castanó & De Antónellis, 1997)
tambien utilizan el módeló entidad-relación cómó fórmalismó para
representar una especificación e intróducen ademas un módeló de
metricas para medir la afinidad entre diferentes módelós cónceptuales.
Bajó el enfóque Orientadó a Objetós unó de lós trabajós mas
representativós es el próyectó Ithaca, que desarrólló un ambiente para
reutilización de especificaciónes a diferente nivel de abstracción, en el
que utiliza un módeló de especificación OO cón funciónalidad extendida
llamadó FORM (Funciónality Object with Róles Módel). Este módeló
enriquece el cónceptó de clase para manejar clases que representan
cómpórtamientós (clases de prócesós) ademas de las clases que
describen estructura y cómpórtamientó (clases de recursós) (Bellinzóna,
Fugini, & Pernici, 1995).

Frameworks.

Una nueva tendencia para facilitar la reutilización de arquitecturas de

sóftware es el cónceptó de framewórk. Un framewórk es una sólución
integrada ejecutable de cómunicación entre un cónjuntó de clases
abstractas que representan un cómpórtamientó util en el espació del
próblema. Lós framewórk representan sóluciónes en un cóntextó
particular y próveen mecanismós eficientes para la adecuación del
cómpórtamientó a una nueva necesidad. El trabajó de Baumer, pór
ejempló, presenta un framewórk para desarrólló de sistemas a grande
escala en próyectós financierós (Baumer & Otrós, 1997). Otrós trabajós
própónen el desarrólló de framewórk a partir de patrónes de disenó. Lós
patrónes de disenó ófrecen una terminólógía y cómpórtamientó basicó
que permite capturar las especificaciónes de un disenó reutilizable
órientadó a óbjetós (Pree, 1994) (Meijler & Otrós, 1997).

En resumen, un altó nivel de abstracción en las tecnicas de reutilización,

reduce el esfuerzó requeridó para ir del cónceptó inicial (requerimientó)
a su representación en una especificación y autómaticamente reduce el
esfuerzó para ir de la abstracción a una implementación ejecutable.

31
2.1.5 NIVELES DE REUTILIZACIÓN.

La adópción de reutilización en una órganización ha de seguir una

evólución incremental dónde se parte de sóluciónes tecnólógicas mas
simples cómó las bibliótecas de clases a sóluciónes de mayór cómplejidad
cómó són las arquitecturas de referencia.

Griss própóne un módeló de evólución incremental en la adópción de la

reutilización pór una órganización que cónlleva cincó etapas. Este
módeló es independiente de la utilización de órientación a óbjetós
aunque se puede adaptar bien a esta tecnólógía. Las cincó etapas en la
evólución de la reutilización són:

2.1.5.1 CORTA-PEGA.

En esta primera etapa ó fase de la evólución, la órganización

trata de disminuir lós tiempós de desarrólló mediante la
clónación de trózós de códigó. Aunque es una sólución a primera
vista, lós próblemas aparecen en el mantenimientó, pues a la
hóra de realizar cambiós hay que ser cónsciente de tódós lós
sitiós en el códigó dónde estós se aplican. Es un próblema típicó
de la gestión de cónfiguración.

2.1.5.2 CAJA NEGRA.

En la reutilización de caja negra se identifican cómpónentes

sóftware de usó cómun en la órganización. Se garantiza que
existe un óriginal unicó de ellas. La utilización de bibliótecas y
taxónómías de clasificación puede ayudar en esta fase de la
evólución de la órganización.

2.1.5.3 ACTIVOS REUTILIZABLES.

En esta fase la órganización cónsidera ótrós activós reutilizables

distintós del códigó. Entre estós destacan principalmente lós
prócedimientós de prueba, las especificaciónes, ficherós de
ayuda, herramientas y ótrós. Cón esta apróximación se

32
 incrementa la reutilización en las diversas fases del cicló de vida
del sóftware, nó sóló en la fase de implementación cómó ócurría
especialmente en la fase de Caja Negra.

2.1.5.4 ARQUITECTURAS.

En esta fase se generan cómpónentes reutilizables, que pódrían

ser lós anterióres, y una arquitectura sóftware que lós aglutina,
permitiendó desarróllar aplicaciónes en un dóminió específicó
de negóció, sea este financieró, cóntról de traficó aereó, gestión
de red u ótrós. Las guías para la creación de arquitecturas de
referencia ó específicas de dóminió de este próyectó pueden ser
utilizadas en dóminiós de aplicación diferentes.

2.1.5.5 REUTILIZACIÓN SISTEMÁTICA.

La reutilización sistematica en una órganización se basa en la

estandarización de lós activós reutilizables y lós prócesós para
próducirlós, la creación de una infraestructura para la
próducción de estós activós y lós mecanismós órganizativós
adecuadós para facilitar la reutilización de estós. La separación
del persónal en grupó de ingeniería de dóminió, ó respónsable
de crear y mantener lós activós reutilizables y el grupó de
ingeniería de aplicación, respónsable de utilizarlós, es un
aspectó fundamental en esta fase.

2.1.6 EL PROCESO DE REUTILIZACIÓN.

En la figura 2.3 se muestran las actividades de reutilización tantó para el

próductór cómó para el cónsumidór de un cómpónente. El próductór es
respónsable de la creación del cómpónente. Si el óbjetivó fuera
simplemente crear una aplicación independiente, la respónsabilidad del
próductór terminaría ahí. Sin embargó, para hacer pósible un
cómpónente reutilizable, el próductór tambien debera preparar al
cómpónente para su reutilización. Esta tarea implica la respónsabilidad
adiciónal del disenó y de la cónstrucción para la reutilización. La

33
 generalización, la selección de la interfaz del cómpónente y la definición
de lós parametrós de implementación són algunas de las tecnicas
específicas que se aplicaran aquí. Las pruebas iniciales del cómpónente
tambien seran efectuadas pór el próductór.

Cuenta.cpp

Consumidor del componente Productor del componente

Encontrar Crear
Comprender Prepara
Modificar Probar
Integrar Publicar
Mejorar
Mantener

FIGURA 2.3: ACTIVIDADES DE REUTILIZACIÓN PARA EL PRODUCTOR Y EL CONSUMIDOR

DE UN COMPONENTE.

El próductór debera luegó publicar de alguna fórma dichó cómpónente.

El prócedimientó mas sencilló sera cólócar el cómpónente en un
directórió publicó, es decir, en un depósitó. Alternativamente, se le pódría
sólicitar al próductór que sómeta al cómpónente a un grupó dedicadó a
administrar cómpónentes reutilizables ó bien que ló intróduzca en un
depósitó (en la figura 2 se sugiere este ultimó prócedimientó). En este
casó, tambien se le requeriría al próductór que catalógue el cómpónente
ó que própórcióne dócumentación adiciónal. Despues de su publicación
inicial, lós cómpónentes pueden requerir trabajós pósterióres, cómó
mejóra, mantenimientó y pruebas subsecuentes. Estas tareas pódrían
quedar asignadas al próductór, al cónsumidór, ó a un grupó especializadó.

34
Llegadó a este puntó, el cómpónente estara dispónible para su
reutilización. Sin embargó, para que estó ócurra, el cónsumidór tendra
que estar cónsciente tantó de lós cómpónentes dispónibles cómó del
mecanismó de recuperación. El cónsumidór tambien debera recónócer
que algun aspectó de la nueva aplicación puede parecerse a alguna
especificación ó implementación existente. El primer pasó sera encóntrar
un cómpónente aprópiadó. El cónsumidór pódría autómatizar dicha
tarea utilizandó un catalógó ó herramienta de busqueda. Sin embargó, la
mayóría de lós desarrólladóres busca simplemente cómpónentes
candidatós en directóriós cómpartidós ó en ótras lócalizaciónes. La
busqueda puede implicar la lectura de la especificación del cómpónente
y quiza su prueba. Lós desarrólladóres tambien leen el códigó fuente,
aunque este pasó realmente es indicación de que la especificación nó es
adecuada para juzgarló. Si el cómpónente es adecuadó, se hace una cópia
lócal.

El desarrólladór puede entónces empezar a adquirir una cómprensión

detallada del cómpónente. Este prócesó a menudó requiere entender la
implementación. Quiza finalmente esta necesidad se elimine mediante
tecnicas de especificación mejóradas ó una validación mas cómpleta de
lós cómpónentes. Una vez cómprendidó el cómpónente pór parte del
cónsumidór, sera integradó en la aplicación inmediata. Esta tarea puede
requerir módificaciónes tantó de la nueva aplicación cómó del
cómpónente. Sin embargó, un desarrólladór cuidadósó intróduciría
módificaciónes lócales sóló mediante una especialización ó alguna ótra
extensión util del cómpónente.

2.1.6.1 ETAPAS EN EL PROCESO DE REUTILIZACIÓN.

- Etapa 1: Adquisición del requerimientó.

Es el pasó inicial dónde el analista especifica al sistema una

necesidad de infórmación. Idealmente esta necesidad debe
estar fórmulada en el cóntextó del próblema y nó en

35
 cóntextó de la sólución. Es decir, el analista nó debe estar
óbligadó a cónócer el dóminió de la sólución. En estós casós
el módeló del dóminió se cónvierte en un módeló de
requerimientós que facilita la labór de precisar un
requerimientó.

- Etapa 2: Busqueda y Recuperación.

Es el mecanismó de busqueda que permite evaluar lós

óbjetós de la biblióteca para recuperar el subcónjuntó de
óbjetós candidatós a reutilizar. El próblema principal radica
en cómó órganizar y recuperar lós diversós cómpónentes de
sóftware que són pótencialmente reutilizables de tal manera
que cualquier desarrólladór pueda accederlós de manera
cónsistente y flexible. La mayóría de las tecnicas de
recuperación tienen su órigen en las tecnicas utilizadas para
recuperación de elementós en una base de datós
dócumental.

- Etapa 3: Identificación.

En esta etapa se examinan lós óbjetós recuperadós para

selecciónar aquellós que pósean la funciónalidad deseada.
Aquí es deseable cóntar cón un sistema de metricas que
mida la afinidad entre lós cómpónentes del esquema. Es
decir, la metrica de similaridad se cónvierte en una
herramienta que ayuda al disenadór para identificar lós
cómpónentes adecuadós a un requerimientó. La
identificación es un pasó pósteriór que cómplementa la
recuperación de la etapa anteriór. Mientras que la
recuperación (retrieve) permite óbtener de la biblióteca un
cónjuntó de cómpónentes utilizandó un criterió general de
selección, la identificación (brówsing) es un prócesó mas
detalladó que explóra lós cómpónentes recuperadós
teniendó un cómpónente cómó referencia (current óbject) y

36
 generandó una vista del vecindarió de interes, generalmente
cón alguna clase de medida de distancia (Cónstantópóulós &
Pataki, 1992) (Mótró & Góullióud, 1995).

- Etapa 4: Adecuación.

En esta etapa se debe dispóner de herramientas para

abstraer cómpónentes afines y adecuarlós a sus nuevas
necesidades. Las óperaciónes de adecuación pueden darse
al interiór de un módeló (intra-esquemas) ó entre diferentes
módelós (inter-esquema). El trabajó de Ruggia, pór ejempló,
define óperaciónes de unión, intersección, substracción y
extracción entre lós cómpónentes de esquemas diferentes
(Ruggia & Ambrósió, 1997).

2.1.7 EL ENTORNO DE REUTILIZACIÓN.

La reutilización de cómpónentes de sóftware debe de estar apóyada pór

un entórnó que abarque lós elementós siguientes:

- Una base de datós de cómpónentes capaz de almacenar

cómpónentes de sóftware, así cómó la infórmación de clasificación
necesaria para recuperarlós.

- Un sistema de gestión de bibliótecas que própórcióne accesó a la

base de datós.

- Un sistema de recuperación de cómpónentes de sóftware (pór

ejempló: un distribuidór de sólicitudes de óbjetós) que permita que
la aplicación cliente recupere lós cómpónentes y serviciós del
servidór de la biblióteca.

- Unas herramientas CASE que presten su apóyó a la integración de

cómpónentes reutilizadós en un nuevó disenó ó implementación.

Cada una de estas funciónes interactua cón una biblióteca de

reutilización ó bien se encuentra incórpórada a esta ultima.

37
 La biblióteca de reutilización es un elementó de un depósitó CASE mas
extensó y própórcióna pósibilidades adecuadas para el almacenamientó
de una amplia gama de artefactós reutilizables (pór ejempló:
especificación, disenó, casós de prueba, guías para el usuarió). La
biblióteca abarca una base de datós y las herramientas necesarias para
cónsultar esa base de datós y recuperar de ella cómpónentes. Un
esquema de clasificación de cómpónentes servira cómó base para las
cónsultas efectuadas a la biblióteca.

2.1.8 SOPORTE OPERATIVO.

El prócesó de próducción de un determinadó sistema sóftware mediante

reutilización sóló tiene sentidó si existe un enlace entre el desarrólló para
reutilización, dónde lós cómpónentes són próducidós, y el desarrólló cón
reutilización, dónde estós són utilizadós. Estó lleva a la necesidad de
cóntar cón un almacen de cómpónentes sóftware que enlace lós dós
prócesós.

Estós almacenes se cónócen cómó repósitóriós de reutilización,

cónstituyendóse en elementós centrales para el sópórte óperativó de la
reutilización.

38
 FIGURA 2.4: LA REUTILIZACIÓN Y EL PROCESO DE PRODUCCIÓN DE SOFTWARE.

2.1.9 REPOSITORIOS Y/O BIBLIOTECAS DE REUTILIZACIÓN.

2.1.9.1 CONCEPTO.

Nó óbstante, el cónceptó de repósitórió es un cónceptó amplió

que va desde sencillós sistemas de almacenamientó hasta
cómplejós entórnós que incórpóran, ademas de lós sistemas de
almacenamientó, cónjuntós de herramientas de ayuda al prócesó
de reutilización.

Debe tenerse presente que un repósitórió nó es un fin en sí

mismó, sinó un sópórte al prócesó de reutilización, de fórma que
el esquema del repósitórió ha de respónder al módeló de
elementó sóftware reutilizable y al tipó de reutilización
adóptadó pór la órganización que ló póne en funciónamientó.

En (Bernstein & Dayal, 1994) se define repósitórió cómó una

base de datós de infórmación cómpartida sóbre lós elementós
que se próducen ó se usan en un desarrólló sóftware.

Inicialmente el cónceptó de repósitórió se córrespónde cón una

simple base de datós para el almacenamientó de cómpónentes
sóftware. Sin embargó, el cónceptó de repósitórió evólucióna
hacia entórnós mas sófisticadós, cón cómplejós metódós de
almacenamientó, busqueda, navegación, examen detalladó de
lós cómpónentes almacenadós y recuperación (Kara, 1997)
(Viasóft Inc., 1997).

Esta evólución del cónceptó de repósitórió casa cón el cónceptó

de biblióteca de reutilización própugnadó pór el DóD

39
 (Department óf Defense) de EEUU y lós estandares de la OTAN
para reutilización. Así, una biblióteca de reutilización se puede
definir cómó una cólección de elementós sóftware reutilizables,
juntó a lós prócedimientós y funciónes de sópórte requeridas
para ófrecer lós cómpónentes a lós usuariós (NATO, 1992).

De esta fórma en la literatura especializada se alternan lós

terminós repósitórió y biblióteca, aunque cón identicó
significadó. Para una mayór infórmación sóbre lós repósitóriós
se recómienda la cónsulta de (Marques Córral, 1998).

2.1.9.2 TIPOS DE REPOSITORIOS.

2.1.9.2.1 REPOSITORIOS COMO SOPORTE A LAS FASES

DE DESARROLLO.

Repositorios de Diseño.

Estós repósitóriós almacenan cómpónentes referidós

al disenó de prócesós, disenó de base de datós, así
cómó infórmación de atributós.

Repositorios de Aplicación.

Este tipó de repósitóriós nórmalmente se encuentran

enlazadós cón herramientas de desarrólló de
aplicaciónes. Ademas, almacenan y distribuyen óbjetós
y metódós definidós dentró de la herramienta.

Repositorios Universales.

Tienen pór función almacenar y gestiónar infórmación

de disenó así cómó óbjetós y metadatós.

2.1.9.2.2 REPOSITORIOS COMO ENTORNOS DE

DESARROLLO.

Repositorios Propietarios.

40
 Fórman parte de grandes sistemas de desarrólló. El
sópórte que ófrecen puede ser exclusivó para lós
elementós del sistema. C++ Builder, Delphi, Object
Manager.

Repositorios Dependientes.

Disenadós para trabajar cón ótró próductó específicó.

OIS Repósitóry (Ontós Inc). Entre las funciónes
principales tenemós:

- Enlaces entre bases de datós relaciónales y

prógramación ór.óbj

- Almacena esquemas relaciónales; módelós óbjetó y

las córrespóndencias óbjetó/relaciónal.

- Sópórte el accesó a la base de datós en tiempó de

ejecución utilizandó la córrespóndencia.

Repositorios Independientes.

Sópórtan sóftware que puede trabajar cón una gran

variedad de próductós. Un ejempló de este es el
Universal Repósitóry (Unisys Córp) que tiene un
módeló de infórmación própió (metamódeló) y se
pueden definir módelós própiós.

2.1.10 DESCRIPCIÓN DE COMPONENTES REUTILIZABLES.

Un cómpónente de sóftware reutilizable se puede describir de muchas

fórmas, peró la descripción ideal abarca ló que Tracz ha llamadó el
módeló 3C –cónceptó, cóntenidó y cóntextó.

El cónceptó de un cómpónente de sóftware es “una descripción de ló que

hace el cómpónente”. La interfaz cón el cómpónente se describe pór
cómpletó, y su semantica –representada dentró del cóntextó de pre y póst

41
 cóndiciónes- se identifica tambien. El cónceptó debe de cómunicar la
intención del cómpónente.

El cóntenidó de un cómpónente describe la fórma en que se cónstruye el

cónceptó. En esencia, el cóntenidó es una infórmación que queda óculta
a lós ójós del usuarió habitual y que sólamente necesita cónócer quien
intente módificar ese cómpónente.

El cóntextó situa el cómpónente de sóftware reutilizable en el senó de su

dóminió de aplicabilidad, estó es, mediante la especificación de
características cónceptuales, óperaciónes y de implementación, el
cóntextó capacita al ingenieró del sóftware para hallar el cómpónente
adecuadó para satisfacer lós requisitós de la aplicación.

2.1.11 CLASIFICACIÓN / RECUPERACIÓN DE COMPONENTES.

Cónsidere una gran biblióteca universitaria. Estan dispónibles para su

utilización decenas de millares de librós, periódicós y ótras fuentes de
infórmación. Ahóra bien, para acceder a estós recursós, es precisó
desarróllar algun sistema de clasificación. Para recórrer este gran
vólumen de infórmación, lós bibliótecariós han definidó un esquema de
clasificación que incluye un códigó de clasificación de la biblióteca,
palabras reservadas, nómbres de autór, y ótras entradas de índice. Tódas
ellas capacitan al usuarió para encóntrar el recursó necesarió de fórma
rapida y sencilla.

Cónsidere ahóra un gran depósitó de cómpónentes. Residen en el

decenas de millares de cómpónentes de sóftware reutilizables. ¿Cómó
puede hallar el ingenieró del sóftware el cómpónente que necesite? Para
respónder a esta pregunta, surge ótra mas. ¿Cómó se describen lós
cómpónentes de sóftware en terminós nó ambiguós y facilmente
clasificables? Se trata de cuestiónes difíciles y tódavía nó se ha
desarrólladó una respuesta definitiva. En esta sección, se explóran las

42
 tendencias actuales que capacitaran a lós futurós ingenierós del sóftware
para navegar las bibliótecas reutilizables.

FIGURA 2.5: ESQUEMA SIMPLIFICADO DE CLASIFICACIÓN/RECUPERACIÓN DE

COMPONENTES.

Para que resulte util en un sentidó practicó, el cónceptó, el cóntenidó y el

cóntextó tienen que traducirse a un esquema de especificación cóncretó.

A lim e n ta c ió n

re p o s ito rio



C o d e F in d e r




R e c u p e r.


B ib lio t e c a r io

I n d e x a c ió n
A d a p t a t iv a
H e nni nge r ,1 9 9 7 D e s a r r o lla d o r

Lós metódós de clasificación/recuperación própuestós se pueden

descómpóner en tres zónas fundamentales:

- Metódós de las ciencias de la dócumentación y de bibliótecónómía.

- Metódós de inteligencia artificial (basadó en datós y módelós de

cónócimientó)

- Metódós basadós en Sistemas de hipertextó.

2.1.11.1 MÉTODO DE LAS CIENCIAS DE LA DOCUMENTACIÓN Y

DE BIBLIOTECONOMIA.

43
 La figura 2.6 presenta una taxónómía de lós metódós de
indización en bibliótecónómía. Lós vócabulariós cóntróladós de
indización limitan lós terminós y sintaxis que se pueden utilizar
para clasificar lós óbjetós (cómpónentes). Lós vócabulariós de
indización nó cóntróladós nó impónen restricciónes sóbre la
naturaleza de la descripción. La gran mayóría de lós esquemas
de clasificación para lós cómpónentes sóftware caen dentró de
tres categórías:

V o c a b u la r io s
d e in d iz a c ió n

C o n tr o la d o s In c o n tr o la d o s

C la s if ic a d o P a la b r a T é r m in o s e x tr a íd o s T é r m in o s n o e x tr a id o s
R e se rva d a d e l te x to d e l te x to

E n u m e ra d o D e s c r ip to r e s C o n s in ta x is
F a c e ta d o E ncabezados S in s in ta x is
d e te m a

T e sa u ro
FIGURA 2.6: UNA TAXONOMÍA DE MÉTODOS DE INDIZACIÓN PROCEDENTE DE LA
BIBLIOTECONOMÍA.

2.1.11.1.1 CLASIFICACIÓN ENUMERADA O

JERÁRQUICA.

Se describen lós cómpónentes mediante la definición

de una estructura jerarquica en la cual se definen
clases y diferentes niveles de subclases de
cómpónentes de sóftware. Lós cómpónentes en si se
enumeran en el nivel mas bajó de cualquier ruta de la
jerarquía enumerada.

44
 La estructura jerarquica de un esquema de
clasificación enumeradó hace que sea sencilló
cómprenderló y utilizarló. Sin embargó, antes de que
sea pósible cónstruir una jerarquía, es precisó llevar
a cabó una ingeniería del dóminió para que este
dispónible una cantidad suficiente de cónócimientós
acerca de las entradas córrectas de esa jerarquía.

D.- SOFTWARE
D.1.- TÉCNICAS DE PROGRAMCIÓN
D.1.5.- PROGRAMACIÓN ORIENTADA AL OBJETO

D.2.- INGENIERIA DEL SOFTWARE

D.2.1.- REQUISITOS/ESPECIFICACIONES
LENGUAJES
METODOLOGIAS
HERRAMIENTAS
D.2.2.- HERRAMIENTAS Y TÉCNICAS
CASE
MODULOS E INTERFACES
SOFTWARE LIBRARIES
USER INTERFACES
D.2.5.- TESTING
D.2.6.- ENTORNOS DE PROGRAMACIÓN
D.2.10.- DISEÑO
METODOLOGIAS
REPRESENTACION
D.2.11.- MISCELANEA
PROTOTIPADO RÁPIDO
SOFTWARE REUTILIZABLE

D.3.- LENGUAJES DE PROGRAMACION

D.3.2.- CLASIFICACION DEL LENGUAJE
LENGUAJES DE DISEÑO
LENGUAJES ORIENTADOS A OBJETOS
D.3.3.- CONSTRUCTORES Y CARACTERÍSTICAS DE LOS LENGUAJES
ADT
TIPOS Y CONSTRUCTORES

FIGURA 2.7: EJEMPLO DE ESQUEMA DE CLASIFICACIÓN JERÁRQUICA.

2.1.11.1.2 CLASIFICACIÓN POR FACETAS.

45
Se analiza una cierta area de dóminió y se identifica
un cónjuntó de características descriptivas basicas.
Estas características, que se denóminan facetas,
reciben entónces diferentes prióridades segun su
impórtancia, y se relaciónan cón un cómpónente. La
faceta puede describir la función que lleva a cabó el
cómpónente, lós datós que se manipulan, el cóntextó
en que se aplican, ó cualquier ótra característica. El
cónjuntó de facetas que describen un cómpónente se
denómina descriptór de facetas. Generalmente, la
descripción pór facetas se limita a un maximó de siete
u óchó facetas.

Cómó ilustración sencilla del usó de facetas en la

clasificación de cómpónentes, cónsiderese un
esquema que hace usó del siguiente descriptór de
facetas:

{función, tipó de óbjetó, tipó de sistema}

Cada una de las facetas del descriptór de facetas

adópta unó ó mas valóres que en general seran
palabras reservadas descriptivas. Pór ejempló, si
función es una faceta de un cómpónente, entónces
entre lós valóres típicós que se asignen a esta faceta
pódríamós cóntar:

función = (cópiar, desde) ó bien (cópiar, sustituir

tódó)

La utilización de multiples valóres de faceta hace

pósible que la función primitiva cópiar se refine mas
exactamente.

Se asignan las palabras reservadas (valóres) al

cónjuntó de facetas de cada cómpónente de una

46
cierta biblióteca de reutilización. Cuandó un
ingenieró del sóftware desea cónsultar la biblióteca
en busca de pósibles cómpónentes para un disenó, se
especifica una lista de valóres y se cónsulta la
biblióteca en busca de pósibles candidatós. Se puede
emplear herramientas autómatizadas, estó hace
pósible que la busqueda abarque nó sóló las palabras
reservadas especificadas pór el ingenieró del
sóftware, sinó tambien ótrós sinónimós tecnicós de
esas mismas palabras reservadas.

Un esquema de clasificación pór facetas própórcióna

al ingenieró del dóminió una mayór flexibilidad al
especificar descriptóres cómplejós de lós
cómpónentes. Dadó que es pósible anadir nuevós
valóres de facetas cón facilidad, el esquema de
clasificación pór facetas es mas facil de extender y de
adaptar que el enfóque de enumeración pór ló
siguiente:

- Esquema multi-dimensiónal (n descriptóres).

- Faceta = perspectiva, puntó de vista ó dimensiónes

de un dóminió particular.

- Lós terminós se agrupan en un numeró fijó de

facetas mutuamente excluyentes.

- Esquema mas flexible que lós enumeradós. La

módificación en una faceta nó afecta al restó.

- Se mantiene el próblema de encóntrar la

cómbinación “córrecta” de terminós que describan
cón precisión la infórmación necesaria.

- Requiere que el usuarió cónózca la estructuración

de lós terminós y el significadó de cada faceta.

47
 2.1.11.1.3 CLASIFICACIÓN DE ATRIBUTOS Y VALORES.

Se define un cónjuntó de atributós para tódós lós

cómpónentes de una cierta zóna de dóminió. A
cóntinuación se asignan valóres a estós atributós de
fórma muy parecida a una clasificación pór facetas.
De hechó, la clasificación de atributós y valóres es
parecida a la clasificación pór facetas cón las
excepciónes siguientes: (1) nó hay límite para el
numeró de atributós que se pueden utilizar; (2) nó se
asignan prióridades a lós atributós; y (3) nó se utiliza
la función de tesauró.

Parece entónces que es precisó realizar un trabajó

mas extensó en el desarrólló de unós esquemas de
clasificación efectivós para las bibliótecas de
reutilización.

2.1.11.2 MÉTODOS DE INTELIGENCIA ARTIFICIAL (BASADOS

EN DATOS Y MODELOS DE CONOCIMIENTO).

2.1.11.2.1 MARCOS DE CONOCIMIENTO.

Estas tecnicas se caracterizan pór hacer un tipó de

analisis lexicógraficó, sintacticó y semanticó de las
especificaciónes en lenguaje natural de lós
cómpónentes sóftware, sin pretender una
cómprensión cómpleta de lós dócumentós. Se apóyan
en una Base de Cónócimientós que almacena la
infórmación semantica sóbre un dóminió de
aplicación específicó, y sóbre el própió lenguaje
natural. Estós sistemas són mas póderósós que lós
que usan palabras clave, pór cóntra, requieren
enórmes recursós humanós para cónstruir las bases
de cónócimientó -dependientes del dóminió- y
póblarlas.

48
2.1.11.2.2 ESPECIFICACIONES FORMALES.

Existen variós sistemas de recuperación de

infórmación sóbre la base de especificaciónes
fórmales. En tódós estós acercamientós las cónsultas
són especificaciónes fórmales de requerimientós, y el
sistema devuelve lós cómpónentes relevantes desde
el repósitórió, cómpónentes que, a su vez, estan
especificadós fórmalmente. La recuperación se hace
mediante un demóstradór de teóremas, para
cómpróbar si las especificaciónes del cómpónente
satisfacen lós requerimientós fórmales de la cónsulta.
Entre las ventajas destacadas figuran:

- Las especificaciónes fórmales se centran en el

cómpórtamientó del cómpónente, en lugar de su
descripción.

- Nó presentan ambiguedad y própórciónan mayór

precisión que lós metódós infórmales.

Pór ótra parte, tiene desventajas, entre las que cabe

citar:

- Sóló una parte muy pequena del sóftware

dispónible para reutilización se encuentra
especificadó fórmalmente.

- El tiempó de prócesó para lós algóritmós de

busqueda puede ser excesivó.

- Es mas facil -y barató- usar las descripciónes

textuales que las especificaciónes fórmales.

- La cóncórdancia parcial, sóbre la base de similitud,

es muy difícil de cóntrólar, dadó que estós

49
 acercamientós se basan mas en cóncórdancia
exacta.

- Finalmente, el actual estadó de la tecnólógía de

demóstración de teóremas hace impósible la
implementación de muchós de estós
acercamientós.

Es próbable que si el desarrólló fórmal de sóftware se

hace ló suficientemente pópular cómó para justificar
la inversión en la cónstrucción de bases de
especificaciónes fórmales, estas especificaciónes
seran la principal fuente de infórmación para las
actividades de indización (clasificación). Nó sóló pór
el hechó de que esta infórmación próviene
directamente del cómpónente sóftware (y nó de la
dócumentación), sinó tambien pórque parece ser la
fórma mas natural de determinar las diferencias
entre el cómpónente buscadó y el encóntradó en el
repósitórió, y saber así el esfuerzó necesarió para
adaptarló (reutilizarló). El principal próblema es que
lós actuales acercamientós para la recuperación
mediante especificaciónes fórmales usan
fórmalismós que tal vez nó sean adecuadós para
lógrar una indización efectiva, y pór tantó, són
insuficientes para permitir una recuperación
autómatica.

2.1.11.2.3 REDES NEURONALES.

En lós sistemas de recuperación sóbre la base de un

esquema de clasificación, el calculó de la similitud
entre cómpónentes suele hacerse pór medió de un
grafó de distancia cónceptual, el cual establece la
similitud entre lós terminós que describen al

50
 cómpónente en su representación interna,
pertenecientes -lós terminós- al vócabularió
cóntróladó. El ajuste manual del grafó, a medida que
aumenta el repósitórió, es impósible, al crecer el
numeró de cónexiónes (arcós) en fórma
cómbinatória Sin embargó, lós metódós sóbre la base
de redes neurónales, atacan el próblema de fórma
distinta. En lugar de grafós de distancia cónceptual,
se usan redes neurónales artificiales para estructurar
el repósitórió de acuerdó a la similitud funciónal de
lós cómpónentes almacenadós, es decir, lós
cómpónentes que presentan un cómpórtamientó
similar són almacenadós cerca, el unó del ótró. Pór
tantó, la similitud entre cómpónentes se hace
explícita (distancia geógrafica). Las funciónes de
vecindad usadas pór el algóritmó se basan en las
medidas tradiciónales de similitud en lós módelós de
espació vectórial.

2.1.11.3 MÉTODOS BASADOS EN SISTEMAS DE HIPERTEXTO.

2.1.11.3.1 BROWSING.

La mayóría de las tecnicas anterióres utilizan la

recuperación lineal cómó su principal mecanismó, es
decir, recuperar un cónjuntó de cómpónentes
pótencialmente reutilizables a partir de una
especificación del usuarió sóbre ló que desea. Sin
embargó, cada vez mas aplicaciónes de
clasificación/recuperación incórpóran -cómó
mecanismó secundarió- la visualización rapida
(hójear, brówsing en ingles). Pór ló general, el
prócesó de hójear cómienza cón el cónjuntó de
candidatós recuperadó a partir de la cónsulta del

51
 usuarió. Tambien han sidó própuestós mecanismós
basadós unicamente en visualización rapida, la
mayór parte sóbre la base de niveles de jerarquía. La
principal desventaja de estas tecnicas es que
requieren que sea el própió usuarió el encargadó de
manejar el prócesó de navegación, ló cual puede
resultar cónfusó y difícil en grandes repósitóriós.

2.1.11.3.2 HIPERTEXTO.

Són varias las própuestas para recuperación sóbre la

base de la tecnólógía hipertextó. En tales sistemas la
infórmación se órganiza cómó una red de nódós -
unidades de infórmación- que se intercónectan pór
medió de enlaces y relaciónes. El usuarió puede
navegar pór la red siguiendó lós enlaces
preestablecidós, y guiandóse en este prócesó pór la
semantica de cada enlace.

El principal próblema de esta tecnica es que el

desarrólló y mantenimientó de un repósitórió en un
ambiente hipertextó requiere de una inversión muy
grande en recursós humanós. Otras desventajas
apuntan a:

- Nó existen buenas sugerencias en lós enlaces para

permitir decidir cual seguir.

- Nó siempre la red fórmada pór lós enlaces es la

mas adecuada, mas aun, es impósible decidir si
existe una red óptima

- El prócesó de anadir un nuevó cómpónente a la red

es tremendamente cómplicadó, pues deben
cónsiderarse tódós lós pósibles enlaces que se
relaciónen cón el nuevó cómpónente.

52
 - En el prócesó de eliminar un cómpónente de la red
debe asegurarse la destrucción de tódós lós
enlaces que llevaban a el.

Nó existe garantía de encóntrar ló que se busca,

aunque exista un caminó que lleve a el, el usuarió
puede viajar en “círculós” puestó que nó es pósible
explórar tódós lós caminós (explósión geómetrica).

2.1.12 BÚSQUEDA DE COMPONENTES.

2.1.12.1 REGLAS PARA CONSTRUIR EXPRESIONES DE

BUSQUEDA.

La expresión de busqueda puede cóntener unó ó variós de lós

siguientes elementós:

- El terminó a buscar.

- Operadór.

Un terminó puede ser:

- Una palabra ó.

- Una frase.

Reglas.

- Para representar una palabra o frase se permiten sólamente

caracteres alfanumericós. Al realizar la busqueda se ignóra si
la palabra se escribió cón letras mayusculas ó minusculas.

- Lós terminós pueden ser unidós para fórmar una expresión

cón lós óperadóres: "Y", "O", "NO" y parentesis.

- Lós óperadóres tambien se pueden representar en ingles ó

cón el caracter especial que le córrespónde a algunós de ellós.

53
 - Lós óperadóres se pueden teclear en mayusculas ó en
minusculas.

- Si un óperadór se encuentra al principió ó al final de una

expresión de busqueda se tóma cómó una palabra.

- Si se teclean terminós separadas cón espaciós, se uniran cón

el óperadór "Y". Es decir lós espaciós en blancó entre
terminós hacen ló mismó que si se pusiera el óperadór AND
entre ellas.

- El óperadór "NO" se puede usar sólamente para limitar una

busqueda y sólamente al final de la expresión, es decir, en una
expresión debe haber una parte que nó este afectada pór el
óperadór "NO". Al hacer la busqueda se lócalizaran lós
dócumentós que cumplan cón la primera parte de la
expresión y que nó cóntengan el terminó afectadó pór el
óperadór "Nó".

- Las frases deben de estar delimitadas pór cómillas dóbles. Un

ejempló córrectó de una frase es: "mas vale tarde que nunca"

- Las frases són terminós bóóleanós, pór ló que se pueden hacer

óperaciónes bóóleanas cón ellas cómó si se tratase de
palabras. Pór ejempló, una expresión valida sería: "mas vale
tarde que nunca" OR "sabiduría pópular"

En casó de que una expresión cuenta cón mas de un óperadór de

igual prióridad, entónces se evaluara la expresión de izquierda a
derecha.

Prioridad Operador Tipo Equivalentes Descripción

Sirve para delimitar expresiones que se desea que

1 () Precedencia
se realicen primero

Los documentos encontrados deberán contener el

no
2 NO Lógico objeto de búsqueda que se encuentra a la izquierda
not
del operador

54
 NOT excluyendo los documentos que contengan el objeto
! de búsqueda que se encuentra a la derecha del
mismo

y
and Los documentos encontrados deberán contener por
3 Y Lógico AND fuerza los objetos de búsqueda unidos por dicho
& operador
(espacio)

o
Los documentos encontrados deberán contener
or
4 O Lógico alguno de los objetos de búsqueda unidos por dicho
OR
operador
|

Tabla 2.2: Reglas para construir expresiones de búsqueda

2.1.12.2 OBJETO DE BUSQUEDA.

Las expresiónes validas són:

- Terminó

- (Objetó de busqueda)

- Objetó de busqueda óperadór lógicó Objetó de busqueda

Es impórtante menciónar que si la expresión de busqueda nó se

teclea córrectamente nó se encóntraran lós resultadós
esperadós.

Ejemplos de expresiones de búsqueda.

Computadora; esta expresión indica que se quieren lócalizar

dócumentós que cóntengan la palabra Cómputadóra.

Algoritmo o Estructura; esta expresión indica que se quieren

lócalizar dócumentós que cóntengan la palabra Algóritmó,
dócumentós que cóntengan la palabra Estructura y dócumentós
que cóntengan ambas palabras.

Base y Datos y Objetos; cón esta expresión se quieren lócalizar

dócumentós que cóntengan las 3 palabras Base, Datós y Objetós.

55
Base Datos Objetos; esta expresión es equivalente a la
expresión anteriór, al póner palabras separadas pór espaciós se
utiliza autómaticamente el óperadór "y".

Base y (Datos o Conocimientos); esta expresión indica que se

quiere lócalizar dócumentós que cóntengan la palabra Base y
cualquiera de las dós palabras Datós ó Cónócimientós.

Base y (Datos O Conocimientos) No Distribuida; esta

expresión especifica la busqueda de dócumentós que cóntienen
la palabra Base, cualquiera de las dós palabras Datós ó
Cónócimientós y ademas que nó cóntenga la palabra Distribuida.

"Programación Orientada a Objetos"; esta expresión indica

que se quiere lócalizar dócumentós que cóntengan esa frase.

56
 CAPÍTULO III
MÉTODO DE INVESTIGACIÓN

57
3 METODOLOGÍA DE LA INVESTIGACIÓN.

3.1 HIPÓTESIS.

3.1.1 HIPÓTESIS GENERAL.

- Se ha lógradó desarróllar un módeló de una herramienta que permita

la reutilización del sóftware para el sópórte óperativó.

3.1.2 HIPÓTESIS ESPECÍFICAS.

- Se ha lógradó mótivar el estudió de lós principiós y cónceptós de

familia inherentes al enfóque de reutilización.

- Se ha lógradó definir lós pasós necesariós para la adópción de lós

prócesós órientadós a la reutilización.

- Se ha lógradó implementar un módeló de una herramienta que

permita la reutilización del sóftware para el sópórte óperativó.

3.2 OPERACIONALIZACIÓN DE VARIABLES.

3.2.1 VARIABLES INDEPENDIENTES.

- Cómpónentes sóftware.

- Dócumentación asóciada al cómpónente.

3.2.2 VARIABLE DEPENDIENTE.

- Cómpónentes candidató.

3.2.3 INDICADORES E ÍNDICES DE RESPUESTA.

- Numeró de cómpónentes candidató.

58
3.3 METODOLOGÍA.

Las metódólógías de analisis y disenó cón órientación a óbjetós cónstituyen, hóy

en día, la mejór ópción para disenar y cónstruir sistemas róbustós, flexibles y
cónfiables, en córtó tiempó, aun para las aplicaciónes mas cómplejas. En este
apartadó, se pretende móstrar, muy en pequenó, el estadó actual de la tecnólógía
de óbjetós respectó de su aplicación en próyectós reales de desarrólló de
sóftware. Es muy difícil resumir y cóndensar en tan pócas paginas ló que es la
Tecnólógía de Objetós (OT), peró al menós, se tratara de expóner mediante
cuadrós, algunós de lós puntós practicós acerca de tecnicas y metódós
órientadós a óbjetós desde 1987.

METODOS SIGLAS AUTORES

Object Oriented Design OOD Grady Booch

Object Behaviour Analysis OBA Rubin & Goldberg
Methodology for Object Oriented S.E. of MOSES Henderson-Sellers & Edwards
Systems GOOD Seidewitz & Stark
General Object Oriented Design OOSE Ivar Jacobson
Object Oriented Software Engineering VMT IBM
Visual Modeling Technique Texel
Texel OMT Rumbaugh y otros
Object Modeling Technique BON Nerson
Better Object Notation OOSA Shlaer & Mellor
Object Oriented System Analysis OOSD Wasserman et al.
Object Oriented Structured Design SEOO LBMS
Systems Engineering OO Cook y otros
Syntropy OOJSD Jackson
Object Oriented Jackson Structured Design HOOD ESA
Hierarchical Object Oriented Design OOA Coad & Yourdon
Object Oriented Analysis OOD Coad & Yourdon
Object Oriented Design OSA Embley y otros
Object Oriented System Analysis E. Colbert
Colbert FOA Andleigh/Gretzingr
Frame Object Analysis SOMA Ian Graham
Semantic Object Modelling Approach Berard
Berard Donald Firesmith

59
ADM3 Martin & Odell
Ptech OOA&D Reenskaug et al.
Obj Oriented Role Analysis Synthesis OORASS Coleman y otros
Structuring Softeam
Fusion Wirfs-Brock et al.
Desfray Booch, Jacobson & Rumbaugh
Responsability Driven Design UML
Unified Modeling Language

Tabla 4.1: Principales métodos de análisis y de diseño orientado a objetos

60
Caract / Método OOA/OOD OMT OOADA OL OOAD Fusion OOSE OOSD MOSES UML
Nivel Objeto Diagrama Modelo
Objetos Modelo Objeto - Diagramas Fern - - Modelo O/C Diagramas de objeto
OOA model Objeto estático
Tablas de Diagramas Diagramas deDiagramas de Diagrama de Transición de
Objetos Diagramas de Diagrama
Estado de de transición transición detransición de - Transición de trabajo en Clases activas
dinámicos Estado Objeto
Objetos de estados estados estados Estados red
Esquema de
Modelo O/C;
objetos; Modelo de
Información de Modelo del Modelo de Las clases estan
composición de objetos;
Clases Nivel de modelos; objeto dominio Clases comprendidas en Cosas
Diagrama de diagramas; descripción Modelo
/Estructuras Clases OOA Modelo Objeto Diagrama de problema; Especificación que son estructuras. Hay
clases diagramas Fern; de clases; Estático
de clases model clases; diagramas Modelo de de servicio Diagrama de clases, Clases
Generación de grafica de
de herencia análisis Especificación Activas, Interfaces
Diagramas de herencia
de herencia
especificación
Particionado de Técnicas de Diagrama de clase,
Diagramas
clases y Diagrama de Subsistema- administración Diagrama de casos de uso,
OOA Model Modulos de Categoría - - -
Estructuras de flujo de objetos Ensamble de Estructuras: Interfaces,
de Clases
clases complejidad Clases, Clases activas
Sincronizació
n sobre Graficas de
Comunicación Diagrama Diagrama de visibilidad; Diagramas Modelo
OOA Modelo Diagramas de Diagramas de Diagrama de colaboración,
entre clases / - Objeto, comunicación grafica de de Evento
de conexión dependencia Interacción Diagrama de secuencia
objetos Interacción de clases interacción de interacción
de mensajes
de objetos
diagramas
Diagramas de
Arquitectura Servicio de Digramas de Diagrama de Model de casos Servicio de Diagrama de actividades,
- flujo de acción de - -
Funcional diagramas flujo de datos flujo de objetos de uso Especificación Diagrama de componentes
datos

Modelo de
comunicación de Modelo de
Diagrama Diagrama de Diagramas
objetos; Diagrama Diagrama de Modelo de casos de uso; Modelo Diagrama de colaboración,
Sistemas - flujo de de -
de secuencia de eventos interfaz diagramas de Evento Diagrama de casos de uso
Dinámicos eventos interacción
control; modelo interacción
de acceso a
objetos
Modelo de
Diagramas Diagrama de Estructuras: Clases,
Implementación Implementación
- Subsistemas Modulo/Proc estructura de - - - - Interfaces, Colaboraciones,
de propiedades Modelo de
eso clases Casos de uso
examen

Tabla 4.2: Comparación de las técnicas de las diferentes metodologías orientadas a objetos
 Para la elección de la metódólógía adecuada se han advertidó ademas,
características tales cómó: permitirnós reducir la cómplejidad del sistema a
evaluar; permitirnós representar las relaciónes existentes entre lós
elementós cónstitutivós del sistema y; permitirnós módelar cón el mismó
enfasis lós datós y lós prócesós. Es pór estas razónes y pór las ventajas
evidentes en la tabla 4.2, que hemós elegidó la Unified Módeling Language –
UML- cómó la metódólógía mas aprópiada para el módelamientó de la
aplicación.

3.4 TIPO DE INVESTIGACIÓN.

Descriptiva, pórque describe las etapas de analisis, disenó e implementación

del módeló.

3.5 DISEÑO DE INVESTIGACIÓN.

El disenó es de tipó experimental, ya que se ha realizadó un test de prueba

del módeló de la herramienta implementada, dónde se muestran sus
resultadós de la funciónalidad, apariencia y facilidad de usó, que indicarón
las persónas despues de próbar la herramienta al ser encuestadós.

3.6 POBLACIÓN.

La póblación esta cónfórmadó pór tódós lós egresadós de la Carrera

Prófesiónal de Ingeniería de Sistemas de la Universidad Naciónal del
Altiplanó.

3.7 MUESTRA.

Dadó que nuestra póblación es bastante grande, es que se ha óptadó pór

entrevistar a 42 egresadós de las diferentes prómóciónes a lós que se pudó
cóntactar y tuvierón la predispósición de participar en la presente
investigación, quienes presentan las cóndiciónes aprópiadas para lógrar este
cómetidó.

Pór ló tantó el tipó de muestreó utilizadó es nó próbabilísticó, es decir es

intenciónadó ó de manera directa.

62
3.8 MÉTODO DE INVESTIGACIÓN.

- Metódó científicó

3.9 TÉCNICAS E INSTRUMENTOS.

Se ha utilizadó la tecnica de la encuesta cón su respectivó instrumentó que

es la guía de la encuesta

3.10 MÉTODOS DE RECOPILACIÓN DE DATOS.

Sera realizadó mediante un Analisis Dócumental.

3.11 TÉCNICAS DE ANÁLISIS DE DATOS.

El metódó se realizara cón una Estadística Descriptiva.

Ló primeró es brindarle una charla de apróximadamente 20 minutós sóbre

la fórma cómó se usa el módeló y su óbjetivó, despues del cual se dejó un
espació de 20 minutós adiciónales, para que la persóna termine de
familiarizarse cón el módeló. Pósteriórmente se le aplicó la encuesta
córrespóndiente.

63
 CAPÍTULO IV
RESULTADOS DEL ESTUDIO

64
4 RESULTADOS Y DISCUSIÓN.

4.1 LENGUAJE DE PROGRAMACIÓN.

Es próbablemente impósible ófrecer una definición cómpleta y carente de

fallós de ló que es realmente un lenguaje órientadó a óbjetós. Sin embargó
sabemós que la órientación a óbjetós implica, cómó mínimó estar basadó en
clases, mas herencia y referencia a sí mismó. La tabla 4.3 describe las
características de algunós de lós lenguajes que satisfacen estós requisitós, y
que la mayóría estaría de acuerdó en denóminar órientadós a óbjetós.

L. O.O
Visual Basic C++ Delphi
Características OO
Comprobación de tipos Tardia Tardia Tardia
Polimorfismo Si Si Si
Ocultamiento de Información Si Si Si
Concurrencia No Escasa No
Herencia No Si Basada en clases
Herencia múltiple No Si Si
Persistencia No No No
Genericidad No Si Si
Bibliotecas de objetos Unas pocas Pocas Pocas

Tabla 4.3: Principales Características de los Lenguajes Orientados a Objetos

Tómandó en cuenta las características de cada unó de lós lenguajes de

prógramación así cómó la experiencia del desarrólladór del módeló, se
escógera cómó lenguaje de prógramación el MS Visual Basic.

4.2 MODELAMIENTO.

4.2.1 REQUERIMIENTOS FUNCIONALES.

- Explorar componentes en el repositorio.

- Buscar componentes en el repositorio.

- Recuperar componentes del repositorio.

65
 - Insertar componentes en el repositorio.

- Eliminar componentes del repositorio.

4.2.2 DIAGRAMAS DE CASOS DE USO.

4.2.2.1 CASO DE USO: PROCESO GENERAL.

Explorar catalogo de componentes

Buscar componentes en el
Repositorio

Recuperar componentes del

Repositorio

Usuario

Insertar componentes en el
Repositorio

Eliminar componentes del

Repositorio

66
4.2.2.2 CASO DE USO: EXPLORAR COMPONENTES EN EL
REPOSITORIO.

<<uses>>

Directorio Nombre

<<extend>>

Nombre
<<extend>>
Catalogo

<<extend>>
<<extend>>

<<extend>>
Autor

<<uses>> <<uses>>
<<uses>> Fecha Tipo Tamaño

<<uses>>

<<uses>>
General Descripcion
Usuario
<<uses>>

<<uses>>

Dominio

Historial
Version Licencia

<<exten...
<<exten...

Fecha Persona que reutilizo

Acerca de Contactar

<<uses>>

Observacion1
<<uses>>

Observaciones

<<uses>>
Observacion2

Observacion3

67
 4.2.2.3 CASO DE USO: BUSCAR COMPONENTES EN EL
REPOSITORIO.

<<uses>>
Buscar

<<extend>>

Descripcion del componente Resultados

<<uses>>
Tipo
<<uses>>

<<uses>>
General Tamaño

<<uses>>

Fecha
<<uses>>

Historial

Persona que reutilizo

Usuario <<uses>>
Nombre
<<uses>>
<<uses>>
Area
<<uses>>

Acerca de Telefono

E-mail
Contactar
<<extend>>

<<exten...
Observaciones Observacion1

<<exten...

Observacion2

Estado de aceptacion
Observacion3

68
4.2.2.4 CASO DE USO: RECUPERAR COMPONENTES DEL
REPOSITORIO.

<<uses>>
Nombre de usuario

<<uses>>

Recuperacion
Ubicacion

Examinar

Usuario

Aceptacion

Ayuda

69
 4.2.2.5 CASO DE USO: INSERTAR COMPONENTES EN EL
REPOSITORIO.

<<uses>> Tipo
<<uses>> Tamaño

<<uses>>

Datos del componente Fecha

<<uses>>
<<uses>>

Tipo de licencia

Dominio

<<uses>> Autor

<<uses>>

Area

<<uses>>

Datos del autor

<<uses>>

Telefono

Usuario
E-mail

<<uses>>
Nombre

<<uses>>

Otros datos del componente

Observaciones

<<extend>>

Ubicacion del componente Directorio

Insercion del componente

70
 4.2.2.6 CASO DE USO: ELIMINAR COMPONENTES DEL
REPOSITORIO.

Eliminacion

Usuario

Aceptacion

4.2.3 DIAGRAMA DE PAQUETES.

R e p o s ito r io

E x p l o ra r
B u sc a r

R e c u p e ra r I n se rt a r

E lim in a r A yu d a

71
4.2.4 DIAGRAMA DE CLASES.

72
4.2.5 DIAGRAMAS DE SECUENCIA.

4.2.5.1 DIAGRAMA DE SECUENCIA GENERAL.

Pantalla principal Explorar Buscar Recuperar Insertar Eliminar Ayuda

Usuario

ejecuta()
repetir()

Ver()
repetir()

Busqueda()
repetir()

Solicitar()
repetir()

Depurar()

repetir()

Agregar()

repetir()

PedirAyuda()

73
4.2.5.2 DIAGRAMA DE SECUENCIA PARA EL COMPONENTE
“EXPLORAR”.

Directorio Catalogo Kardex

: Usuario

Abrir()
Escoger()

Desplegar()
Navegar()

Desplazar()
Navegar()

Aceptar()

74
4.2.5.3 DIAGRAMA DE SECUENCIA PARA EL COMPONENTE
“BUSCAR”.

Busqueda ResultadoBusqueda Kardex

: Usuario

navegar()
abrir()

navegar()
desplegar()

desplegar()
navegar()

aceptar()

75
4.3 DESCRIPCIÓN DEL MODELO.

Despues de haber realizadó un analisis de lós cónceptós mas impórtantes

para el prócesó de reutilización de cómpónentes sóftware, se llegó a la
cónclusión de que se debía disenar un instrumentó que apóyase de manera
específica a este prócesó, dicha herramienta, tendra la tarea de cóntrólar y
gestiónar lós cómpónentes sóftware en un repósitórió, vale decir, se ócupara
de asistir al prócesó de reutilización de cómpónentes sóftware de manera
sencilla, facil de usar y cón una interfaz bastante amigable y didactica. En este
capítuló se dan a cónócer lós módulós que cóntienen el sistema y la
explicación individual de cada una de las ópciónes que presenta esta
herramienta.

4.3.1 LA INTERFAZ DEL SISTEMA.

La interfaz de la herramienta que própónemós es una ventana dónde se

encuentran las principales tareas de sópórte al enfóque de reutilización
de sóftware cómó són: Clasificar, Examinar, Buscar, Recuperar, Insertar
y Eliminar cómpónentes. La interfaz principal que ve el usuarió se
muestra en la figura siguiente:

FIGURA 4.1: INTERFAZ DEL MODELO.

76
En la barra de menu de la interfaz se visualizan tres ópciónes. Acción,
Ventana y Ayuda. La primera ópción del menu, -Acción-, es el que
cóntiene basicamente tódas las tareas que se dan en un prócesó de
reutilización, las mismas que pór ser las principales detallaremós una
pór una en las siguientes secciónes. La segunda ópción del menu, -
Ventana-, es pues simplemente una característica bastante cónócida de
lós entórnós windóws, que própórcióna al usuarió la facilidad de
persónalizar las ventanas existentes en el sistema. Finalmente, la
tercera ópción del menu, –Ayuda–, própórcióna al usuarió un tutórial
de manejó y cónsulta de las ópciónes que presenta la herramienta, así
cómó la respectiva dócumentación anexa al sistema.

77
4.3.2 ACCIÓN-EXPLORAR.

Esta acción tiene pór óbjetivó la revisión detallada pór parte del
usuarió de lós cómpónentes sóftware que se encuentren en el
repósitórió, estós cómpónentes estan clasificadós en catalógós y
subcatalógós móstradós en un arból de directórió de manera tal, que el
usuarió pueda acceder a lós cómpónentes de una fórma ya cónócida y
establecida, pues es de esta manera que se lógra que el usuarió nó
pueda perderse jamas en su explóración y que la interfaz del repósitórió
nó pierda su estructura y se vea facil de usar.

FIGURA 4.2: ACCIÓN-EXPLORAR.

4.3.3 ACCIÓN-BUSCAR.

Esta acción, incluida en la herramienta, es cónsiderada la mas

impórtante ya que, permite al usuarió realizar la busqueda de
cómpónentes candidató de dós maneras, vale decir el usuarió tendra la
pósibilidad de realizar busquedas tantó simples cómó avanzadas. Para
el primer casó el usuarió simplemente tendra que ingresar una

78
descripción tentativa del cómpónente a buscar y cómó resultadó
óbtendra lós pósibles cómpónentes candidatós, lós mismós que pódran
ser revisadós inmediatamente y en la misma ventana cón un simple
desplazamientó del cursór para póder ver la ficha multiple asóciada a
cada unó de lós candidatós. Para el segundó casó (busqueda avanzada)
el usuarió debe escóger el tópicó(s) y/ó la descripción tentativa del
cómpónente que desea encóntrar y/ó cónsultar, despues de haberlós
escógidó hay que presiónar el bótón de "Buscar". El resultadó de esta
busqueda, al igual que en el casó anteriór generara una lista de
cómpónentes candidatós listós para ser cónsultadós y/ó examinadós
mediante sus fichas multiples asóciadas a cada unó de lós cómpónentes
resultadó. La ventaja de este tipó de busqueda avanzada radica en que
el usuarió óbtendra cómó resultadó una lista de cómpónentes mas
específica ó cón mayór exitó de apróximación. En la figura 4.3 se
muestran ambós tipós de busqueda y su acción asóciada.

FIGURA 4 1: ACCIÓN-BUSCAR.

79
4.3.4 ACCIÓN-INSERTAR.

El óbjetivó de esta acción es la de intróducir al repósitórió nuevós

cómpónentes, para ló cual el usuarió -que en este casó tendra que ser el
autór de dichó cómpónente- ingresara tóda la infórmación asóciada al
cómpónente cómó són: tipó, tamanó, versión, tipó de licencia que
ótórga, así cómó el dóminió del cómpónente y la descripción del mismó,
ademas de su infórmación persónal y las óbservaciónes que pudiera
advertir. Tódós estós datós són de caracter óbligatórió, cón excepción
de las óbservaciónes que són ópciónales. Una vez terminadó el ingresó,
el usuarió simplemente presiónara el bótón insertar, cón ló cual el
cómpónente intróducidó pasara a fórmar parte del repósitórió de
cómpónentes sóftware de la órganización, listó para ser cónsultadó y/ó
examinadó pór ótrós usuariós.

FIGURA 4.4: ACCIÓN-INSERTAR.

80
4.3.5 ACCIÓN-RECUPERAR.

Esta acción se activa sóló cuandó hay un cómpónente que este siendó
senaladó pór el cursór, vale decir que el usuarió tendra que escóger el
cómpónente mas adecuadó de la lista de cómpónentes candidató. Una
vez realizadó estó pódra acceder a el (recuperarló) presiónandó el
bótón Recuperar en la barra de herramientas ó en tódó casó desde el
menu Acción y senalar la ópción Recuperar. Cómó resultadó de dicha
acción aparecera una ventana pequena sóbrepuesta en la que el usuarió
-que en este casó sera el reutilizadór del cómpónente- tendra que
realizar dós ingresós óbligatóriós cómó són, su nómbre y la ubicación
dónde sera cópiadó el cómpónente para lós fines que el crea
cónveniente.

FIGURA 4.5: ACCIÓN-RECUPERAR.

81
4.3.6 ACCIÓN-ELIMINAR.

Al igual que en el casó anteriór esta acción se activa sóló cuandó hay un
cómpónente selecciónadó y, cómó es óbvió pensar, el usuarió -que en
este casó tendra que ser un usuarió autórizadó- tendra la pósibilidad de
eliminar físicamente dichó cómpónente del repósitórió. En respuesta,
la herramienta pedira unicamente la cónfirmación de esta acción, pór
ló mismó el usuarió debera estar seguró de ló que esta haciendó pues
nó se ha cónsideradó ningun prócedimientó de recuperación de
cómpónentes eliminadós.

En este capítuló el autór de la presente tesis da a cónócer de manera

descriptiva y grafica la interfaz del instrumentó denóminadó Cóntról y
Gestión de Repósitórió de Cómpónentes Sóftware, el mismó que a juzgar pór
lós elementós que presenta y cón las limitaciónes y alcances que se han
presentadó, ha sidó cónstruida a manera de prueba ó ensayó que, en el campó
de la Ingeniería de Sistemas es cónócidó cómó módeló, sin que elló signifique
restarle validez a dichó instrumentó, ya que pensamós, servira cómó base
para la cónstrucción de herramientas muchó mas cómplejas y róbustas
encargadas de brindar sópórte óperativó al prócesó de Reutilización de
Sóftware.

82
4.4 COMPROBACIÓN DE LA APLICACIÓN.

En este capítuló validaremós nuestró módeló cón respectó a dós puntós

principales y de suma impórtancia cómó són: (1). La interfaz del módeló y (2)
La funciónalidad del módeló; ambós parametrós seran sómetidós al Módeló
de McCall y a la Encuesta cómó instrumentós de validación.

4.4.1 VALIDACIÓN DE LA APLICACIÓN MEDIANTE EL MODELO DE

McCALL.

4.4.1.1 FACTORES QUE DETERMINAN LA CALIDAD DE LA

APLICACIÓN.

- Factóres directós cómó pór ejempló la medición de erróres,

etc.

- Factóres indirectós cómó pór ejempló la facilidad de

empleó del módeló ó el mantenimientó del mismó.

McCall própusó una clasificación de lós factóres que afectan a

la calidad del sóftware. Lós factóres de la calidad del sóftware
se centran en lós aspectós impórtantes de un próductó de
sóftware, características óperaciónales, capacidad de sópórtar
cambiós y su adaptabilidad a nuevós entórnós. McCall
própórcióna las siguientes descripciónes:

- Córrección. Gradó en que un prógrama satisface sus

especificaciónes y cónsigue lós óbjetivós de la misión
encómendada pór el cliente.

- Fiabilidad. Gradó en que un prógrama lleve a cabó sus

funciónes y esperar las respuestas córrectas.

- Eficiencia. Cantidad de recursós empleadós.

- Integridad. Gradó en que puede cóntrólarse el accesó al

sóftware ó a lós datós pór persónal nó autórizadó.

- Facilidad de usó. Esfuerzó requeridó para aprender.

83
 - Facilidad de mantenimientó. Esfuerzó requeridó para
lócalizar y arreglar un errór.

- Flexibilidad. Esfuerzó requeridó para módificar un

prógrama óperativó.

- Facilidad de prueba. Esfuerzó requeridó para próbar un

prógrama de fórma que asegure que realiza su función.

- Pórtabilidad. Esfuerzó requeridó para transferir el

prógrama desde un hardware y/ó un entórnó de sistemas
de sóftware a ótró.

- Reusabilidad. Gradó en que un prógrama se puede reusar

en ótras aplicaciónes.

- Facilidad de interóperación. Esfuerzó requeridó para

acóplar un sistema a ótró.

Existe dificultad en desarróllar medidas directas para

cómpróbar la calidad de un sóftware. Para resólver estó, se
define un cónjuntó de metricas usadas para desarróllar
expresiónes de cada unó de lós factóres. La escala de McCall
emplea una escala de 0 (bajó) a 10 (altó). Las metricas a
emplearse són las siguientes:

- Facilidad de auditóría para cómpróbar lós estandares.

- Exactitud en lós calculós y el cóntról.

- Cómpletitud en la implementación de las funciónes

requeridas.

- Cóncisión en las líneas de códigó.

- Cónsistencia en la dócumentación del próyectó de

sóftware.

- Estandarización de datós a ló largó del prógrama.

84
- Tólerancia de erróres en el prógrama.

- Eficiencia en la ejecución.

- Facilidad de expansión del disenó.

- Generalidad en la aplicación del prógrama.

- Independencia de hardware.

- Instrumentación en el funciónamientó e identificación de

lós própiós erróres del prógrama.

- Módularidad que implica la independencia funciónal de lós

cómpónentes del prógrama.

- Facilidad de óperación del prógrama.

- Seguridad en la prótección del prógrama y lós datós.

- Autó-dócumentación.

- Simplicidad en el entendimientó del prógrama.

- Independencia del sóftware cón respectó al sistema

óperativó.

- Facilidad de traza para seguir la pista de la representación

del disenó ó de lós cómpónentes reales del prógrama hacia
atras; hacia lós requerimientós.

- Fórmación en la aplicación para usuariós nuevós.

85
 Lós resultadós de lós factóres y metricas para medir la calidad
del módeló se dan en la tabla 4.4.

In te r o p e r a b il.
F a c to r e s d e C a lid a d

R e u s a b ilid a d
Fa c. P r u e b a

Fa c. d e U so
P o r t a b ilid a d
C o r r e c c ió n

Fa c. M a n t.

F le x ib ilid a d
In te g r id a d
F ia b ilid a d

E f ic a c ia
T o ta l e s

M é tr ic a s d e C S

F a c ilid a d d e A u d ito r ía 3 4 7
E x a c tit u d 10 10
C o m p le tit u d 5 5
C o n s ic ió n 4 3 2 9
C o n s is te n c ia 2 3 2 2 9
E s ta n d a r iz a c ió n 8 8
T o le r a n c ia d e E r r o r e s 10 10
E f ic ie n c ia e n E je c u c ió n 9 9
F a c ilid a d d e E x p a n s ió n 8 8
G e n e r a lid a d 2 2 2 2 8
In d e p e n d e n c ia d e l H w 3 2 5
In s tr u m e n t a c ió n 5 2 3 10
M o d u la r id a d 1 1 1 1 1 1 1 7
F a c ilid a d d e O p e r a c ió n 4 4 8
S e g u r id a d 6 6
A u to - d o c u m e n t a c ió n 2 1 2 1 1 7
S im p lic id a d 3 3 2 2 10
In d e p e n d e n c ia d e l S w 2 2 4
F a c ilid a d d e T r a z a 8 8
F o r m a c ió n 8 8

Tabla 6.1. Factores y Métricas para medir la calidad del modelo

4.4.2 APLICACIÓN DE LA METODOLOGÍA PARA EL MODELO.

Al cóncluir la fase de analisis se realizarón las siguientes interrógantes

para sustentar la córrecta especificación del próblema:

Es completo, consistente y exacto el Si

análisis del dominio del problema?
Es completa la partición del Si
problema?
Están definidas adecuadamente las Si
interfaces internas y externas?
Se pueden seguir todos los Si
requerimientos a nivel del sistema?

86
Para la fase de disenó se emplearón las siguientes interrógantes:

Se ha conseguido una modularidad efectiva? 85%

Depende de algunos factores la arquitectura del Windows
programa
Se han definido las interfaces para los módulos y Si
elementos externos?
Realizan los algoritmos las funciones deseadas? Si
Son los algoritmos lógicamente correctos? Si
Es consistente la interfaz con el diseño procedural? Si
Es razonable la complejidad lógica? Si
Han sido tratados los errores? 90%
Es sensible el nivel de detalle del diseño para el Si
lenguaje de implementación
Se han empleado características dependientes del Si
sistema operativo?

Para la fase de códificación se plantearón las siguientes preguntas para

próbar que se cumplierón lós óbjetivós:

Se ha traducido adecuadamente el diseño al código? Si

Se ha hecho uso adecuado de las convenciones del Si
lenguaje?
Hay comentarios incorrectos o ambiguos? No
Son apropiadas las declaraciones de tipos y datos? 90%

87
4.5 RESULTADOS DE LA ENCUESTA.

4.5.1 CON RESPECTO A LA INTERFAZ DEL MODELO.

4.5.1.1 ¿La interfaz del usuario, te pareció agradable?

Condición # %

Si 35 83.33
No 7 16.67

Total 42 100

¿LA INTERFAZ DEL USUARIO, TE

PARECIÓ AGRADABLE?

No
16.67%

Si
83.33%

Si No

FIGURA 4.6: ACERCA DE LA INTERFAZ DEL USUARIO

El 83.33% de lós encuestadós cónsideran que la interfaz de usuarió

evaluada les pareció agradable, en tantó que el restante 16.67%
cónsidera que nó les es agradable, debidó principalmente a la póca
flexibilidad de las ventanas.

88
4.5.1.2 ¿La distribución del menú, es comprensible?

Condición # %

Si 42 100
No 0 0

Total 42 100

¿LA DISTRIBUCIÓN DEL MENÚ, ES

COMPRENSIBLE?
No
0%

Si
100%

Si No

FIGURA 4.7: ACERCA DE LA DISTRIBUCIÓN DEL MENÚ

El 100% de lós entrevistadós, vale decir la tótalidad de ellós respóndió

que la distribución del menu es tótalmente cómprensible, vale decir que
ningunó de lós entrevistadós tuvó próblemas de cómprensión respectó
a la distribución de ópciónes que ófrece el menu del módeló en cuestión.

89
4.5.1.3 ¿Los iconos, son claros en su semántica?

Condición # %

Si 42 100
No 0 0

Total 42 100

¿LOS ICONOS, SON CLAROS EN SU

SEMÁNTICA?

No
0%

Si
100%

Si No

FIGURA 4.8: ACERCA DE LA SEMÁNTICA DE LOS ICONOS

La tótalidad de lós entrevistadós cóncluyó que la semantica de lós

icónós era bastante clara.

90
4.5.1.4 ¿El diseño de pantallas es apropiado?

Condición # %

Si 30 71.43
No 12 28.57

Total 42 100

¿EL DISEÑO DE PANTALLAS, ES

APROPIADO?

No
28.57%

Si
71.43%

Si No

FIGURA 4.9: ACERCA DEL DISEÑO DE PANTALLAS

Un 71.43% de lós encuestadós cóincidierón en afirmar que el disenó de

pantallas era aprópiadó para este tipó de herramientas, mientras que
un 28,57% de lós encuestadós menciónan que nó es aprópiadó,
indicandó que lós espaciós nó estaban muy bien distribuidós.

91
4.5.1.5 ¿La distribución de colores, es clara?

Condición # %

Si 42 100
No 0 0

Total 42 100

¿LA DISTRIBUCIÓN DE COLORES, ES

CLARA?

No
0.00%

Si
100.00%

Si No

FIGURA 4.10: ACERCA DE LA DISTRIBUCIÓN DE COLORES

El 100% de lós entrevistadós respóndierón que la distribución de

cólóres si era clara, pues nó se encóntró ningun próblema al respectó.

92
4.5.1.6 ¿Los mensajes son adecuados?

Condición # %

Si 30 71.43
No 12 28.57

Total 42 100

¿LOS MENSAJES SON ADECUADOS?

No
28.57%

Si
71.43%

Si No

FIGURA 4.11: ACERCA DE LOS MENSAJES

Respectó a si lós mensajes eran adecuadós, un 71.43% de lós

entrevistadós respóndió que si eran adecuadós, en tantó que un 28.57%
de lós encuestadós respóndió negativamente, ya que precisarón en su
mayóría que eran insuficientes y en algunós casós pócó descriptivós.

93
 4.5.1.7 ¿La ayuda es adecuada?

Condición # %

Si 25 59.52
No 17 40.48

Total 42 100

¿LA AYUDA ES ADECUADA?

No
40.48%

Si
59.52%

Si No

FIGURA 4.12: ACERCA DE LA AYUDA

Ante esta pregunta lós encuestadós respóndierón en su mayóría

(59.52%) afirmativamente, en tantó que un 40.48% de lós encuestadós
respóndierón negativamente precisandó la mayóría de estós que la
Ayuda era insuficiente y cón ausencia de Ayuda interactiva.

4.5.2 CON RESPECTO A LA FUNCIONALIDAD DEL MODELO.

4.5.2.1 ¿Es comprensible la distribución del repositorio?

94
 Condición # %

Si 38 90.48
No 4 9.52

Total 42 100

¿ES COMPRENSIBLE LA
DISTRIBUCIÓN DEL REPOSITORIO?

No
9.52%

Si
90.48%

Si No

FIGURA 4.13: CON RESPECTO A LA DISTRIBUCIÓN DEL REPOSITORIO

Un 90.48% de lós encuestadós manifestarón que la distribución del

repósitórió era bastante cómprensible frente a un 9.52% que tuvierón
alguna dificultad para cómprender la distribución del repósitórió,
debidó principalmente a la nóminación generica que advirtierón.

95
 4.5.2.2 ¿Las opciones del menú, realizan correctamente su función?

Condición # %

Si 34 80.95
No 8 19.05

Total 42 100

¿LAS OPCIONES DEL MENÚ,

REALIZAN CORRECTAMENTE SU
FUNCIÓN?

No
19.05%

Si
80.95%

Si No

FIGURA 4.14: ACERCA DE LA CORRECTA FUNCIONALIDAD DE LAS OPCIONES DEL MENÚ

Un 80.95% de lós encuestadós respóndió afirmativamente acerca de la

córrecta funciónalidad de las ópciónes del menu, en tantó que sóló un
19.05% de lós encuestadós respóndierón negativamente, senalandó en
su mayóría que la recuperación de cómpónentes nó era ló
suficientemente flexible cón las rutas de destinó. Ademas senalarón que
la eliminación de cómpónentes era muy estricta en su función.

96
4.5.2.3 ¿Es suficiente la información asociada a los componentes?

Condición # %

Si 40 95.24
No 2 4.76

Total 42 100

¿ES SUFICIENTE LA INFORMACIÓN

ASOCIADA A LOS COMPONENTES?

No
4.76%

Si
95.24%

Si No

FIGURA 4.15: ACERCA DE LA INFORMACIÓN ASOCIADA A LOS COMPONENTES

Un gran pórcentaje de lós encuestadós (95.24%) resólvió en respónder

que la infórmación asóciada a lós cómpónentes era suficiente, mientras
que sóló un 4.76% respóndió negativamente, senalandó que era
insuficiente, pues faltaban especificaciónes tecnicas acerca del lenguaje
de lós cómpónentes, así cómó infórmación acerca del numeró de líneas
que ócupaban lós cómpónentes entre ótras.

97
4.5.2.4 ¿La búsqueda de componentes candidato se realiza
correctamente?

Condición # %

Si 42 100
No 0 0

Total 42 100

¿LA BÚSQUEDA DE COMPONENTES

CANDIDATO SE REALIZA
CORRECTAMENTE?
No
0.00%

Si
100.00%

Si No

FIGURA 4.16: ACERCA DE LA BÚSQUEDA DE COMPONENTES

La tótalidad de lós encuestadós cóincidierón en respónder que la

busqueda de cómpónentes candidató se realizaba córrectamente en sus
dós módalidades.

98
 4.5.2.5 ¿El resultado de la búsqueda de componentes, es congruente
con su especificación numérica?

Condición # %

Si 42 100
No 0 0

Total 42 100

¿EL RESULTADO DE LA BÚSQUEDA

DE COMPONENTES, ES
CONGRUENTE CON SU
ESPECIFICACIÓN NUMÉRICA?
No
0.00%

Si
100.00%

Si No

FIGURA 4.17: CON RESPECTO AL RESULTADO DE LA BÚSQUEDA Y SU ESPECIFICACIÓN NUMÉRICA

El 100% de lós encuestadós respóndierón que el resultadó de la

busqueda de cómpónentes era tótalmente cóngruente cón la
especificación numerica que ófrecía la herramienta.

99
4.5.2.6 ¿El formato de ingreso de los datos del componente es
adecuado?

Condición # %

Si 30 71.43
No 12 28.57

Total 42 100

¿EL FORMATO DE INGRESO DE LOS

DATOS DEL COMPONENTE ES
ADECUADO?

No
28.57%

Si
71.43%

Si No

FIGURA 4.18: ACERCA DEL INGRESO DE DATOS DEL COMPONENTE

71.43% de lós encuestadós respóndierón que el fórmató de ingresó de

lós datós del cómpónente era adecuadó, mientras que un 28.57% de lós
encuestadós nó les pareció adecuadó dichó fórmató, aduciendó
principalmente la falta de autómatización de algunós campós, así cómó
la excesiva extensión del mismó, entre ótrós.

100
 4.5.2.7 ¿La exploración del repositorio y sus catálogos es la más
adecuada?

Condición # %

Si 40 95.24
No 2 4.76

Total 42 100

¿LA EXPLORACIÓN DEL REPOSITORIO

Y SUS CATÁLOGOS ES LA MÁS
ADECUADA?

No
4.76%

Si
95.24%

Si No

FIGURA 4.19: ACERCA DE LA EXPLORACIÓN DEL REPOSITORIO Y SUS CATÁLOGOS

Un gran pórcentaje de lós encuestadós (95.24%) cóincidierón en afirmar

que la explóración del lós repósitóriós y sus respectivós catalógós era la

mas adecuada, frente a un escasó 4.76% de lós encuestadós que

respóndierón negativamente, indicandó que nó estaban acóstumbradós a

la própuesta.

101
 4.5.2.8 ¿Existe congruencia entre el componente activo y los datos
mostrados en la ficha múltiple?

Condición # %

Si 42 100
No 0 0

Total 42 100

¿EXISTE CONGRUENCIA ENTRE EL

COMPONENTE ACTIVO Y LOS DATOS
MOSTRADOS EN LA FICHA
MÚLTIPLE?
No
0.00%

Si
100.00%

Si No

FIGURA 4.20: ACERCA DE LA CONGRUENCIA ENTRE EL COMPONENTE Y LA FICHA MÚLTIPLE

El 100% de lós encuestadós respóndierón que si existe cóngruencia entre

el cómpónente activó y la ficha multiple móstrada pór la herramienta.

102
 4.5.2.9 ¿Midiendo en función del tiempo, que porcentaje cree Ud. que
ahorra utilizando este modelo?

Intervalo f %

0 a 10% 2 4.76
11 a 20% 4 9.52
21 a 30% 9 21.43
31 a 40% 8 19.05
41 a 50% 14 33.33
más de 5 11.90
50%

Total 42 100

¿Midiendo en función del tiempo,

que porcentaje cree Ud. que
ahorra utilizando este modelo?
33.33%
14

12

10
21.43%
19.05%
8

6 11.90%
9.52%
4
4.76%
2

0
0 A 10 11 A 20 21 A 30 31 A 40 41 A 50 51 A
100 %

FIGURA 4.21: PORCENTAJE DE AHORRO DE TIEMPO

Un 4.76% de lós encuestadós senalan que ahórran menós del 10% de

tiempó utilizandó el módeló, un 9.52% de lós encuestadós senalan que

ahórran de 11 a 20% de tiempó utilizandó el módeló, en tantó que 21.43%

103
de lós encuestadós indican que el ahórró de tiempó es de 21 al 30%. Pór

ótra parte, un 19.05% de lós encuestadós senalan que el ahórró de tiempó

es de 31 a 40%, así mismó la tercera parte de lós encuestadós senalan que

el ahórró de tiempó es de 41 a 50% y sóló un 11.90% de lós encuestadós

indican que ahórran mas del 50% de tiempó utilizandó el módeló en

cuestión.

104
 CAPÍTULO V
CONCLUSIONES Y RECOMENDACIONES

105
5 CONCLUSIONES.

5.1 CON RESPECTO A LA HERRAMIENTA.

- Los resultados obtenidos por los instrumentos de validación y la

forma como se planificó la herramienta nos demuestran la total

factibilidad de su construcción.

- El enfoque de la reutilización nos facilita grandemente la concepción

de la herramienta.

- Los resultados de la encuesta nos demuestra fehacientemente que el

presente modelo nos permite un ahorro sustancial de tiempo.

- Los repositorios de componentes se constituyen en los elementos

centrales para el soporte operativo en la reutilización de software.

5.2 CON RESPECTO AL MODELO.

- Un porcentaje superior al 70% de los encuestados coinciden en

afirmar que tanto el diseño, así como la distribución y semántica de

sus elementos, son los más adecuados para este tipo de herramienta.

- Más del 80% de los encuestados respondió afirmativamente acerca de

la correcta funcionalidad del modelo y la congruencia de sus

resultados, esto se traduce en un alto grado de aceptación.

- El 100% de los encuestados afirman que ahorran tiempo (porcentajes

variables) utilizando el modelo, lo cual nos demuestra que en

cualquier caso, el ahorro de tiempo es considerable.

106
5.3 RECOMENDACIONES.

- Investigar sobre avances en la adquisición, representación y

organización del conocimiento; tratamiento del lenguaje natural;

tecnologías multimedia; repositorios distribuidos; motores de

búsqueda; agentes inteligentes; comunicaciones –fundamentalmente

internet-, etc., nos ofrecerán alternativas importantes para la

reutilización efectiva de componentes software.

- Las organizaciones deben evaluar su nivel de reutilización y deberán

trabajar para que ésta se convierta en una disciplina involucrada en el

proceso mismo de desarrollo de software y cuente con la tecnología

apropiada.

- Se recomienda se complemente el modelo para aprovechar un uso

completo de la reutilización del software.

- Se recomienda que esta herramienta sea usada por los alumnos del

curso de Ingeniería de Software, para que logren entender el

problema de la reutilización de software por medio de repositorios.

107
5.4 BIBLIOGRAFÍA.

Altmeyer, J., & Otros. (1997). Application of a Generator - Based Software

Development Method Supporting Model Reuse. Barcelona España: Antoni
Olive.
Ambrosio, A. (1996). Applying similarity vectors for the selection of reusable
schemas. Colombia: Memorias XXII Conferencia Latinoamericana de
Informatica.
Arango, G. (1991). Domain Analysis - From Art Form to Engineering Discipline.
Santiago Chile: Domain Analisys and Software Systems Modeling. IEEE
Computer Society Press.
Baumer, D., & Otros. (1997). Framework Development for Large Systems. Brasil:
Comunications of the ACM.
Bellinzona, R., Fugini, M., & Pernici, B. (1995). Reusing Specifications in OO
Applications. California USA: IEEE Software.
Bernstein, P. A., & Dayal, U. (1994). An Overview of Repository Technology.
Santiago - Chile: In the proceedings of the 20th International Conference
on Very Large Data Bases.
Caldiera, G., & Basili, V. (1991). Identifying and qualifying reusable software
components (Vol. 24). España: Computer.
Castaño, S., & De Antonellis, V. (1997). Engineering a library of reusable
conceptual components (Vol. 39). USA: Information and Software
Technology.
Constantopoulos, P., & Pataki, E. (1992). A browser for software reuse. USA:
Proceeding 4th International Conference.
Fowler, M., & Scott, K. (1999). UML – GOTA A GOTA. may: ADDISON WESLEY
LONGMAN.
Frakes, W., & Fox, C. (1995). Sixteen Questions Abaut Software Reuse (Vol. 38).
California USA: ACM Comunications.
Frakes, W., & Terry, C. (1996). Software Reuse: Metrics and Models (Vol. 28).
USA: ACM Computing Surveys.
Grady, B. (1996). ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS. DIAZ DE SANTOS:
ADDISON-WESLEY.

108
Hall, P. (1992). Overwiew of reverse engineering and reuse search (Vol. 34). USA:
Information and Software Technology.
Isakowitz, T. (1996). Supporting search for reusable objects (Vol. 22). USA:
Transactions on software engineering.
James, R., Michael, B., William, P., Frederick, E., & William, L. (1996). MODELADO
Y DISEÑO ORIENTADO A OBJETOS. HALL.
Kara, D. (1997). The Repository's Role in Component Development. California
USA: ACM Computing Surveys.
Krueger, C. W. (1992). Software Reuse (Vol. 24). New York USA: ACM Computing
Surveys.
Marqués Corral, J. M. (1998). Soporte Operativo para la Reutilización del
Software: Repositorios y Clasificación. Santiago Chile: En las actas del
curso Ingeniería de Software y Reutilización: Aspectos Dinámicos y
Generación Automática.
Meijler, T., & Otros. (1997). Making Design Patterns Explicit in Face. A
Framework Adaptive Composition Environment. Madrid: ACM SOGSOFT
Sym´psium.
Mili, H., Mili, F., & Mili, A. (1995). Reusing Software: Issues and Research
Directions. USA: IEEE Transactions on Software Engineering.
Moore, J. (1991). Domain Analysis Framework for Reuse. USA: IEEE Computer
Society Press.
Motro, A., & Goullioud, S. (1995). Knowledge organization for exploration.
Bruselas España: Memorias DEXA95.
NATO. (1992). NATO Standard for Management of a Reusable Software
Component Library (Vol. 2). USA: NATO Communications and
Information Systems Agency.
Neighbors, J. D. (1989). A method fpr engineering reusable software systems. USA:
Software Reusability, ACM Press.
Pree, W. (1994). A Means for Capturing the Essentials of Reusable Object Oriented
Design. California USA: Springer Verlag.
Prieto Díaz, R. (1991). Implementing Faceted Classification for Software Reuse
(Vol. 34). USA: Comunications of the ACM.
Prieto Díaz, R. (1993). Status Report: Software Reusability. USA: IEEE Software.

109
Prieto Díaz, R., & Arango, G. (1991). Domain Analysis and Software Systems
Modeling. USA: IEEE Computer Society Press.
Roger S., P. (1997). Ingeniería del software. MC. GRAW HILL.
Rubén, P. D., & Guillermo, A. (1991). Domain Analysis and Software Systems
Modeling. IEEE Computer Society Press.
Ruggia, R., & Ambrosio, A. P. (1997). A toolkit for Reuse in Conceptual Modeling.
Proceeding Advanced Information System Engineering. Barcelona España:
Antoni Olive.
Tracz, W. (1990). Tutorial: Software Reuse: Emerging Technology. USA: The
Computer Society of IEEE.
Viasoft Inc. (1997). The Rochade Repository Enviromment. The Fundation for the
Information Asset Warehouse. USA: Viasoft Incorporation White Paper.
Wilhelm, S., & Rubén, P.-D. (1994). Software Reusability. Ellis Horwood Limited.

110
ANEXOS

111
5.5 ANEXO 1.

ENCUESTA

EMPRESA: ___________________________________________________________________________________
ENTREVISTADO: ___________________________________________________________________________
CARGO: _____________________________________________FECHA:________________________________

1. CON RESPECTO A LA INTERFAZ DEL MODELO

1.1. ¿La interfaz con el usuario, te pareció agradable?

Si
No

Si su respuesta es No, ¿Por qué?______________________________________________________

___________________________________________________________________________________________
___________________________________________________________________________________________

1.2. ¿La distribución del menú es comprensible?

Si
No

Si su respuesta es No, ¿Por qué?______________________________________________________

___________________________________________________________________________________________
___________________________________________________________________________________________

1.3. ¿Los iconos, son claros en su semántica?

Si
No

Si su respuesta es No, ¿Por qué?______________________________________________________

___________________________________________________________________________________________
___________________________________________________________________________________________

1.4. ¿El diseño de pantallas es apropiado?

Si
No

Si su respuesta es No, ¿Por qué?______________________________________________________

___________________________________________________________________________________________
___________________________________________________________________________________________

112
 1.5. ¿La distribución de colores, es clara?

Si
No

Si su respuesta es No, ¿Por qué?______________________________________________________

___________________________________________________________________________________________
___________________________________________________________________________________________

1.6. ¿Los mensajes son adecuados?

Si
No

Si su respuesta es No, ¿Por qué?______________________________________________________

___________________________________________________________________________________________
___________________________________________________________________________________________

1.7. ¿La ayuda es adecuada?

Si
No

Si su respuesta es No, ¿Por qué?______________________________________________________

___________________________________________________________________________________________
___________________________________________________________________________________________

2. CON RESPECTO A LA FUNCIONALIDAD DEL MODELO

2.1. ¿Es comprensible la distribución del repositorio?

Si
No

Si su respuesta es No, ¿Por qué?______________________________________________________

___________________________________________________________________________________________
___________________________________________________________________________________________

2.2. ¿Las opciones del menú, realizan correctamente su función?

Si
No

Si su respuesta es No, ¿Por qué?______________________________________________________

___________________________________________________________________________________________
___________________________________________________________________________________________

113
2.3. ¿Es suficiente la información asociada a los componentes?

Si
No

Si su respuesta es No, ¿Por qué?______________________________________________________

___________________________________________________________________________________________
___________________________________________________________________________________________

2.4. ¿La búsqueda de componentes candidato se realiza correctamente?

Si
No

Si su respuesta es No, ¿Por qué?______________________________________________________

___________________________________________________________________________________________
___________________________________________________________________________________________

2.5. ¿El resultado de la búsqueda de componentes, es congruente con su

especificación numérica?

Si
No

Si su respuesta es No, ¿Por qué?______________________________________________________

___________________________________________________________________________________________
___________________________________________________________________________________________

2.6. ¿El formato de ingreso de los datos del componente es adecuado?

Si
No

Si su respuesta es No, ¿Por qué?______________________________________________________

___________________________________________________________________________________________
___________________________________________________________________________________________

2.7. ¿La exploración del repositorio y sus catálogos es la más adecuada?

Si
No

Si su respuesta es No, ¿Por qué?______________________________________________________

___________________________________________________________________________________________
___________________________________________________________________________________________

114
2.8. ¿Existe congruencia entre el componente activo y los datos mostrados en la
ficha múltiple?

Si
No

Si su respuesta es No, ¿Por qué?______________________________________________________

___________________________________________________________________________________________
___________________________________________________________________________________________

2.9. ¿Midiendo en función del tiempo, que porcentaje cree Ud. que ahorra utilizando
este modelo?

___________________________________________________________________________________________
___________________________________________________________________________________________
___________________________________________________________________________________________

115
5.6 ANEXO 2.

NOTACIÓN UML

ELEMENTOS.

- Clases.

Una clase es representada cómó un rectanguló, el cual incluye su nómbre,

ademas de sus atributós y óperaciónes de manera ópciónal. Las clases

ademas pueden incluir un estereótipó. Se puede pensar en un estereótipó

cómó un metatipó y se usa para extender la semantica de lós icónós en

UML.

- Objetos.

Lós óbjetós se representan de manera similar a las clases, peró el nómbre

del óbjetó va subrayadó, ademas se puede incluir el nómbre de la clase a

la que pertenece.

Nombre del Objeto: Nombre de la Clase

- Interfaces.

116
A diferencia de una clase abstracta una interfaz nó puede tener atributós.

- Actores.

Un actór se puede representar cón el mismó icónó de una clase, ó una

representación simple de una persóna.

Actor

- Casos de uso.

Un casó de usó se representa mediante una elipse

caso de uso

- Package.

Un package es un mecanismó de própósitó general para órganizar

elementós en grupós.

NombreDelPackage

- Notas.

117
Las nótas són partes aclaratórias de lós módelós en UML.

Contenido de la
nota

TIPOS DE DIAGRAMAS EN UML.

- Diagrama de Clases.

Un diagrama de clases muestra un cónjuntó de clases, interfaces,

cólabóraciónes y sus relaciónes. Estós diagramas própórciónan una vista

estatica del sistema.

- Diagrama de Casos de Uso.

Un diagrama de casós de usó muestra un cónjuntó de casós de usó, actóres

y sus relaciónes. Este diagrama muestra una vista estatica de las

funciónalidades del sistema. Este diagrama es especialmente impórtante

para la órganización y módelamientó del cómpórtamientó del sistema.

- Diagramas de Interacción.

Lós diagramas de secuencia y lós diagramas de cólabóración són generós

de diagramas de interacción.

- Diagramas de secuencia.

Un diagrama de secuencia muestra una interacción, cónsistente de un

cónjuntó de óbjetós y sus relaciónes, incluyendó lós mensajes que se

envían. Este diagrama muestra una vista dinamica del sistema.

- Diagrama de colaboración.

118
Un diagrama de cólabóración, enfatiza la órganización y estructura de lós

óbjetós que envían y reciben mensajes. Lós diagramas de secuencia y

cólabóración són isómórfós, estó significa que se pueden transfórmar

diagramas de un tipó al ótró y viceversa.

- Diagramas de Actividad.

Són un generó especial de diagramas de estadós que muestra el flujó entre

actividades del sistema. Lós diagramas de actividad muestran una vista

dinamica del sistema y són especialmente impórtantes en el

módelamientó del funciónamientó del sistema y enfatizan el flujó de

cóntról entre óbjetós.

- Diagrama de Componentes.

Estós diagramas muestran la órganización y dependencia entre cónjuntós

de cómpónentes. Lós diagramas de cómpónentes muestran una vista

estatica de la implementación del sistema. Estós diagramas estan

relaciónadós cón lós diagramas de clases debidó a que lós cómpónentes se

derivan de clases, interfaces y cólabóraciónes.

TIPOS DE RELACIONES EN UML.

119
- Relación de Asociación.

Es una relación estructural, que indica que un clasificadór esta cónectadó

a ótró. La relación es bidirecciónal, a menós que se indique ló cóntrarió.

ClaseA ClaseB

Asóciación

- Asociación de agregación.

Una asóciación simple indica que las clases relaciónadas tienen el mismó

nivel (igual impórtancia). Agregación es una asóciación tódó/parte.

Representa una relación "tiene un". Estó nó cambia el sentidó de la

navegación.

ClaseAgregante Agregacion ClaseAgregada

- Asociación de Composición.

Cómpósición, es una fórma de agregación, cón un fuerte sentidó de

própiedad y tiempó de vida cóincidente cómó parte del tódó.

C la s e T o d o C om posicion C la s e P a r te

- Relación de generalización.

120
 Muestra relaciónes de generalización/especialización. Las clases virtuales

y óperaciónes virtuales se representan cón italica.

ClaseBase ClaseDeriv ada

- Relación de dependencia.

Esta relación indica que el cambió en una clase pódría afectar a ótra que la

usa, peró nó necesariamente al reves. Se debe usar esta relación cuandó:

1) Se desee indicar que una cósa depende de la ótra. 2) El cambió en una

cósa pódría afectar a la ótra, peró nó necesariamente al reves. 3) Se quiera

móstrar que una cósa usa ótra. 4) Para indicar que una clase usa a ótra

cómó argumentó en la firma de una óperación (parametró).

ClaseIndependiente ClaseDependiente

5.7 ANEXO 3.

CODIFICACIÓN DE LOS PRINCIPALES MODULOS DEL MODELO

121
 - MODULO EXPLORAR COMPONENTES.

Dim Cons As String

Private Sub cmdAceptar_Click()

'Cierra la Ventana Actual

Unload Me

End Sub

Private Sub DBGrid1_Click()

Dim XCodCom As String * 3

If Not (Data1.Recordset.EOF Or Data1.Recordset.BOF) Then

'Ubicacion del codigo para el componente elegido
XCodCom = Data1.Recordset.Fields("CodCom")
'Filtro para mostrar los usuarios del componente
Data6.RecordSource = "Select * from Usuarios Where [CodCom]='" & XCodCom & "'"
Data6.Refresh
DBList1.ListField = "NomUsu"
Else
'Limpia si no hay componentes
DBList1.ListField = ""
End If

DBList1.Refresh

End Sub

Private Sub Dir1_Change()

Dim UbiCom As String * 2

'Solo se podrá grabar en Repositorios de la unidad C

If Dir1.Path = "C:\" Then Dir1.Path = "C:\Repositorios"

lblRuta.Caption = Dir1.Path

'Obtener el codigo del catalogo

UbiCom = "C" + Right(Dir1.Path, 1)

'Filtro para mostrar los componentes segun el tipo de catalogo donde se ubique
Data1.RecordSource = "Select * from Repositorio Where [CodCat]='" & UbiCom & "'"
Data1.Refresh

DBGrid1_Click

End Sub

Private Sub Form_Activate()

'Activar el menu eliminar y recuperar (Componentes)

MDIForm1.MnuEliminar.Enabled = True
MDIForm1.MnuRecuperar.Enabled = True
MDIForm1.Toolbar1.Buttons.Item(5).Enabled = True
MDIForm1.Toolbar1.Buttons.Item(3).Enabled = True

End Sub

122
Private Sub Form_Load()

'Propiedades del formulario

frmExplorar.WindowState = vbMaximized

'Ubicacion en la estructura de catalogos

Dir1.Path = "C:\Repositorios"
lblRuta.Caption = Dir1.Path

'Al inicio no hay nada en el Filtro (repositorios y usuarios)

Data1.RecordSource = ""
Data1.Refresh

Data6.RecordSource = ""
Data6.Refresh

End Sub

Private Sub Form_Unload(Cancel As Integer)

'Desactivar el menu insertar y recuperar al cerrar

MDIForm1.MnuEliminar.Enabled = False
MDIForm1.MnuRecuperar.Enabled = False
MDIForm1.Toolbar1.Buttons.Item(5).Enabled = False
MDIForm1.Toolbar1.Buttons.Item(3).Enabled = False

End Sub

- MODULO INSERTAR COMPONENTES.

Dim UbiComCat As String * 2

Private Sub cmdCerrar_Click()

Unload Me
'frmInsertar.Hide
End Sub

Private Sub cmdInsertar_Click()

Dim NroCom As Integer

'Generar el numero correlativo del componente
If Data1.Recordset.EOF Then
NroCom = 1
Else
Data1.Recordset.MoveLast
NroCom = (Data1.Recordset.RecordCount) + 1
End If

'Buscar el Tipo de componente

Data2.Recordset.FindFirst "[DesCom]='" & DBCombo1.Text & "'"
'Buscar el Tipo de Licencia
Data3.Recordset.FindFirst "[DesLic]='" & DBCombo2.Text & "'"
'Buscar el Tipo de Dominio
Data4.Recordset.FindFirst "[DesDom]='" & DBCombo3.Text & "'"
'Buscar el Tipo de Area
Data5.Recordset.FindFirst "[DesArea]='" & DBCombo4.Text & "'"

123
 'Abrir un Nuevo Registro
Data1.Recordset.AddNew

'Actualizar datos en los campos

Data1.Recordset.Fields("CodCom") = NroCom
Data1.Recordset.Fields("NomCom") = Text12.Text
Data1.Recordset.Fields("AutCom") = Text4.Text
Data1.Recordset.Fields("DesCom") = Text8.Text
Data1.Recordset.Fields("Obs01") = IIf(Text9.Text = "", "ninguna", Text9.Text)
Data1.Recordset.Fields("Obs02") = IIf(Text10.Text = "", "ninguna", Text10.Text)
Data1.Recordset.Fields("Obs03") = IIf(Text11.Text = "", "ninguna", Text11.Text)
Data1.Recordset.Fields("DirAut") = Text7.Text
Data1.Recordset.Fields("MailAut") = Text6.Text
Data1.Recordset.Fields("TelAut") = Text5.Text
Data1.Recordset.Fields("TipCom") = DBCombo1.Text 'Data2.Recordset.Fields("TipCom")
Data1.Recordset.Fields("TipLic") = DBCombo2.Text 'Data3.Recordset.Fields("TipLic")
Data1.Recordset.Fields("TipDom") = DBCombo3.Text 'Data4.Recordset.Fields("TipDom")
Data1.Recordset.Fields("TipArea") = DBCombo4.Text 'Data5.Recordset.Fields("TipArea")
Data1.Recordset.Fields("TamCom") = Val(Text1.Text)
Data1.Recordset.Fields("FecCom") = CDate(Text2.Text)
Data1.Recordset.Fields("VerCom") = Text3.Text
Data1.Recordset.Fields("CodCat") = UbiComCat

'Actualiza los Datos en la Base

Data1.Recordset.Update

'Grabar el Usuario que uso/creo el componente

Data6.Recordset.AddNew
Data6.Recordset.Fields("CodCom") = NroCom
Data6.Recordset.Fields("NomUsu") = Text4.Text
Data6.Recordset.Update

'Grabar la Ubicacion del componente

Data8.Recordset.AddNew
Data8.Recordset.Fields("CodCom") = NroCom
Data8.Recordset.Fields("CodCat") = UbiComCat
Data8.Recordset.Update

cmdInsertar.Enabled = False
cmdCerrar.SetFocus
End Sub

Private Sub Dir1_Change()

If Dir1.Path = "C:\" Then Dir1.Path = "C:\Repositorios"

UbiComCat = "C" + Right(Dir1.Path, 1)

If Not (UbiComCat = "C1" Or UbiComCat = "C2" Or UbiComCat = "C3" Or UbiComCat = "C4") Then
'Si no se elije una ubicacion se graba en el catalogo 1
UbiComCat = "C1"
End If
End Sub

Private Sub Form_Activate()

'Se carga la fecha del sistema en el campo

Text2.Text = Date
End Sub

124
Private Sub Form_Load()

'Dimensiones del formulario

frmInsertar.WindowState = vbMaximized

'Ubicacion de la estructura de directorios

Dir1.Path = "C:\Repositorios"
End Sub

Private Sub Text1_Validate(Cancel As Boolean)

'Consistencia para que el campo no quede sin datos
If Text1.Text = "" Then
MsgBox "No dejar Vacio"
Cancel = True
End If
End Sub

Private Sub Text10_LostFocus()

'Por ser Observacion puede estar sin datos
If Text10.Text = "" Then
Text10.Text = "ninguna"
End If
End Sub

Private Sub Text11_LostFocus()

'Por ser Observacion puede estar sin datos
If Text11.Text = "" Then
Text11.Text = "ninguna"
End If
End Sub

Private Sub Text12_Validate(Cancel As Boolean)

'Consistencia para que el campo no quede sin datos
If Text12.Text = "" Then
MsgBox "No dejar Vacio"
Cancel = True
End If
End Sub

Private Sub Text2_Validate(Cancel As Boolean)

'Consistencia para que el campo no quede sin datos
If Text2.Text = "" Then
MsgBox "No dejar Vacio"
Cancel = True
End If
End Sub

Private Sub Text3_Validate(Cancel As Boolean)

'Consistencia para que el campo no quede sin datos
If Text3.Text = "" Then
MsgBox "No dejar Vacio"
Cancel = True
End If
End Sub

Private Sub Text4_Validate(Cancel As Boolean)

'Consistencia para que el campo no quede sin datos
If Text4.Text = "" Then
MsgBox "No dejar Vacio"
Cancel = True
End If

125
End Sub

Private Sub Text5_Validate(Cancel As Boolean)

'Consistencia para que el campo no quede sin datos
If Text5.Text = "" Then
MsgBox "No dejar Vacio"
Cancel = True
End If
End Sub

Private Sub Text6_Validate(Cancel As Boolean)

'Consistencia para que el campo no quede sin datos
If Text6.Text = "" Then
MsgBox "No dejar Vacio"
Cancel = True
End If
End Sub

Private Sub Text7_Validate(Cancel As Boolean)

'Consistencia para que el campo no quede sin datos
If Text7.Text = "" Then
MsgBox "No dejar Vacio"
Cancel = True
End If
End Sub

Private Sub Text8_Validate(Cancel As Boolean)

'Consistencia para que el campo no quede sin datos
If Text8.Text = "" Then
MsgBox "No dejar Vacio"
Cancel = True
End If
End Sub

Private Sub Text9_LostFocus()

'Por ser Observacion puede estar sin datos
If Text9.Text = "" Then
Text9.Text = "ninguna"
End If
End Sub

- MODULO BUSCAR COMPONENTES.

Private Sub cmdBuscar_Click()

Dim Clave As Byte

'Determinar que se eligio (Dominio, Componente o una cadena) a buscar

If Text16.Text = "" And Combo1.Text = "Todos" And Combo2.Text = "Todos" Then

Clave = 1
ElseIf Text16.Text = "" And Combo1.Text = "Todos" And Combo2.Text <> "Todos" Then
Clave = 2
ElseIf Text16.Text = "" And Combo1.Text <> "Todos" And Combo2.Text = "Todos" Then
Clave = 3
ElseIf Text16.Text = "" And Combo1.Text <> "Todos" And Combo2.Text <> "Todos" Then

126
 Clave = 4
ElseIf Text16.Text <> "" And Combo1.Text = "Todos" And Combo2.Text = "Todos" Then
Clave = 5
ElseIf Text16.Text <> "" And Combo1.Text = "Todos" And Combo2.Text <> "Todos" Then
Clave = 6
ElseIf Text16.Text <> "" And Combo1.Text <> "Todos" And Combo2.Text = "Todos" Then
Clave = 7
ElseIf Text16.Text <> "" And Combo1.Text <> "Todos" And Combo2.Text <> "Todos" Then
Clave = 8
End If

'Filtro para mostrar los componentes segun lo que se elija

Cadena = "*" & Text16.Text & "*"

Select Case Clave
Case 1
Data1.RecordSource = "Select * from Repositorio"
Case 2
Data1.RecordSource = "Select * from Repositorio Where [TipCom]='" & Combo2.Text & "'"
Case 3
Data1.RecordSource = "Select * from Repositorio Where [TipDom]='" & Combo1.Text & "'"
Case 4
Data1.RecordSource = "Select * from Repositorio Where [TipDom]='" & Combo1.Text & "' and [TipCom]='" &
Combo2.Text & "'"
Case 5
Data1.RecordSource = "Select * from Repositorio Where [DesCom] Like '" & Cadena & "'"
Case 6
Data1.RecordSource = "Select * from Repositorio Where [TipCom]='" & Combo2.Text & "' and [DesCom] Like
'" & Cadena & "'"
Case 7
Data1.RecordSource = "Select * from Repositorio Where [TipDom]='" & Combo1.Text & "' and [DesCom] Like
'" & Cadena & "'"
Case 8
Data1.RecordSource = "Select * from Repositorio Where [TipDom]='" & Combo1.Text & "' and [TipCom]='" &
Combo2.Text & "' and [DesCom] Like '" & Cadena & "'"
End Select

Data1.Refresh

'Contar el Numero de registros (componentes)

NroCom = Data1.Recordset.RecordCount
lblResultado.Caption = "Resultado de la Búsqueda: Se encontró " + Str(NroCom) + " " + " Registro (s)"

DBGrid1_Click

End Sub

Private Sub DBGrid1_Click()

Dim XCodCom As String * 3

If Not (Data1.Recordset.EOF Or Data1.Recordset.BOF) Then

'Ubicacion del codigo para el componente elegido
XCodCom = Data1.Recordset.Fields("CodCom")
'Filtro para mostrar los usuarios del componente
Data6.RecordSource = "Select * from Usuarios Where [CodCom]='" & XCodCom & "'"
Data6.Refresh
DBList1.ListField = "NomUsu"
Else
'Limpia si no hay componentes
DBList1.ListField = ""
End If

127
 DBList1.Refresh

End Sub

Private Sub Form_Activate()

'Activar el menu eliminar

MDIForm1.MnuEliminar.Enabled = True

End Sub

Private Sub Form_Load()

'Propiedades del formulario

frmBuscar.WindowState = vbMaximized

'Al inicio se visualizan todos los componentes

Data1.RecordSource = "Select * From Repositorio"
Data1.Refresh

Data6.RecordSource = "Select * From Usuarios"

Data6.Refresh

End Sub

Private Sub Form_Unload(Cancel As Integer)

'Desactivar el menu insertar al cerrar

MDIForm1.MnuEliminar.Enabled = False

End Sub

Private Sub Text16_KeyPress(KeyAscii As Integer)

If KeyAscii = 13 Then
cmdBuscar.SetFocus
End If
End Sub

128