& telemÁtica - icesi.edu.co · sistemas 1 & telemÁtica efectos del terreno en la...

1SISTEMAS& TELEMÁTICA

Efectos del terreno en la propagación electromagnéticaen entornos urbanos sobre la región andina,usando el modelo COST 231-Walfisch-Ikegamiy herramientas de planificación basadas en GIS 13A. Paolo García A.Homero Ortega B.Andrés Navarro C.Alexys H. Rodríguez A.

Arquitectura de software basada en la internetpara la simulación virtual de cirugía endoscópicaotorrinolaringológica 35Andrés A. NavarroJorge A. VélezLuis E. MúneraGregorio Bernabé

KeyConcept: Un motor de búsqueda conceptual 47Juan Manuel Madrid MolinaSusan Gauch

Representación de la arquitecturade software usando UML 63Sandra Victoria Hurtado Gil

Construcción de indicadores de gestión bajoel enfoque de sistemas 77José Hernando Bahamón L.

La evolución en la arquitectura de las redes 89Alvaro Pachón D.

2 SISTEMAS& TELEMÁTICA


INGENIERÍA DE SISTEMAS E INGENIERÍA TELEMÁTICA

UNIVERSIDAD ICESI

R e v i s t a d e l a f a c u l t a d d e i n g e n i e r í a

COMITÉ EDITORIAL DE LA UNIVERSIDAD

Francisco Piedrahíta Plata José Hernando BahamónRector Director Académico

Héctor Ochoa Díaz Henry Arango DueñasDecano de la Facultad de Ciencias Decano de la Facultad de Ingenierías

Administrativas y Económicas

Lelio Fernández Druetta Mario Tamayo y TamayoDecano de Derecho y Humanidades Director de Investigaciones

y Publicaciones

COMITÉ EDITORIAL DE LA REVISTA

Guillermo Londoño Acosta Gonzalo UlloaDirector del Programa Director del Programa

de Ingeniería de Sistemas de Ingeniería Telemática

Alvaro Pachón de la Cruz Narcís CardonaJefe del Departamento de Redes Profesor de la Universidad Politécnica

y Comunicaciones de Valencia, España

Andrés Navarro Cadavid Joaquín RestrepoProfesor de la Universidad Icesi Profesor de la Pontificia Universidad

Bolivariana de Medellín

Juan Manuel Madrid Edwin MontoyaProfesor de la Universidad Icesi Profesor de la Universidad EAFIT, Medellín

Luis Eduardo Múnera David Fernández McCaanProfesor de la Universidad Icesi Profesor de la Universidad de Antioquia, Medellín

Andrés Navarro Newball Homero OrtegaProfesor de la Pontificia Profesor de la Universidad Industrial

Universidad Javeriana, Cali de Santander, Bucaramanga

•Los autores de los artículos de esta publicación son responsables delos mismos.

•El material de esta publicación puede ser reproducido sin autorización,mencionando título, autor y, como fuente, S & T. Revista de Ingenieríade Sistemas e Ingeniería Telemática, Universidad Icesi.

Http://www.icesi.edu.coInformes: Tel.: 555 2334. Ext. 377

Fax: 555 1706 - 555 1745Editor. e-mail:[email protected]: e-mail:[email protected]

Cali, Valle, Colombia, Sudamérica

OFICINA DE INVESTIGACIONES Y PUBLICACIONESUNIVERSIDAD ICESI

EDITOR


GUÍA PARA LOS AUTORESDE ARTÍCULOS

Para los autores de los artículos dela Revista «S & T Ingeniería de Sis-temas e Ingeniería Telemática» de laUniversidad Icesi.

• El autor debe garantizar que suartículo no ha sido publicado enningún medio.

• Los autores de artículos serán res-ponsables de los mismos, y portanto no comprometen ni los prin-cipios o políticas de la Universi-dad, ni los del Comité Editorial.

• El Comité Editorial se reservael derecho de publicar o no losartículos que no cumplan con loscriterios de publicación por partede la Universidad Icesi.

• La temática de los artículos debeser de las diferentes áreas de In-geniería de Sistemas, Informáti-ca y Telemática, resultado de in-vestigación propiamente dicha,aplicaciones reales, productos deinvestigación formativa, procesossistémicos de análisis de proble-mas y propuestas de solución.

• Los artículos deben contener:

- Título (claro y preciso)

- Breve reseña del autor.

- Abstract o resumen ejecutivodel artículo (máximo doce ren-glones a doble espacio).

- Palabras claves.

- Clasificación Colciencias*.

- Introducción.

- Desarrollo.

- Referencias y notas de pie depágina.

- Conclusiones.

- Bibliografía o fuentes de infor-mación.

- Extensión: No exceder de 25 pá-ginas en total.

- Tipo de letra: Arial (o equiva-lente) fuente No. 12 y con inter-lineado a doble espacio.

- Una copia impresa y su respec-tivo disquete en Word Win ocompatible IBM. No enviar Ma-cintosh.

Es conveniente resaltar los párrafosu oraciones más significativos delcontenido del artículo y todo aquelloque dé significado a la estructura delmismo.


Los artículos se deben redactar entercera persona del singular, imper-sonal, contar con adecuada puntua-ción y redacción, carecer de erroresortográficos. Conservar equilibrio enla estructura de sus párrafos.

* Clasificación Colciencias para ar-tículos científicos y tecnológicos:

a) Artículos de investigación cien-tífica y de desarrollo tecnológi-co: documentos que presentanresultados derivados de proyec-tos de investigación científicay/o desarrollo tecnológico.

b) Artículos de reflexiones origina-les sobre un problema o tópico

particular: documentos que co-rresponden a resultados de es-tudios realizados por el o losautores sobre un problema teó-rico o práctico.

c) Artículos de revisión: estudioshechos por el o los autores conel fin de dar una perspectivageneral del estado de un domi-nio específico de la ciencia y latecnología, de sus evolucionesdurante un período y donde seseñalan las perspectivas de sudesarrollo y evolución futuros.


GUÍA PARA LAS RESEÑASBIBLIOGRÁFICAS

• Tipo de libro reseñado: Debe serde tipo ejecutivo, no un texto aca-démico.

• Título del libro: Tomado de la ca-rátula.

• Autor del libro: Apellidos, Nombre(persona del autor, lo relevante).

• Nombre del traductor (si lo tuvie-re).

• ISBN

• Editorial, ciudad y fecha.

• Tamaño: 16.5 cm x 23.5 cm.Número de páginas.

• Fortalezas (puntos del porqué elejecutivo debe leerlo, cómo estáestructurado el libro: partes, ca-pítulos) etc.

• Debilidades (puntos no tan atrac-tivos del libro).

• Extensión entre 700 a 800 pala-bras (equivalente a página y me-dia, a doble espacio).

• Lenguaje ejecutivo (breve, no aca-démico, darle ayuda / consejopráctico para hoy, con ejemplos deltexto).


La Revista S & T Ingeniería de Sistemas eIngeniería Telemática, está dirigida a ingenie-ros de sistemas, ingenieros electrónicos, inge-nieros telemáticos y afines; profesores univer-sitarios y estudiantes en las diferentes áreasde la ingeniería; profesionales especializadosen estas áreas.

Usted puede acceder a ella entrando en nues-tra página Web en internet y bajar en forma-to PDF el artículo de su interés o la totalidaddel número que desee, sólo debe entrar a ladirección: http://www.icesi.edu.co/es/publica-ciones y seleccionar la edición correspondien-te. Cualquier duda o comentario dirigirlo a lacuenta de correo [email protected];[email protected]

EL EDITOR


Efectos del terreno en la propagaciónelectromagnética en entornos urbanos

sobre la región andina,usando el modelo Cost 231-Walfisch-Ikegami

y herramientas de planificaciónbasadas en GIS

A. Paolo García A.Universidad Industrial de Santander - GTI-UIS-E3T

[email protected]

Homero Ortega B.Universidad Industrial de Santander - GTI-UIS-E3T

[email protected]

Andrés Navarro C.Universidad Icesi-I2T

[email protected]

Alexys H. Rodríguez A.Universidad Industrial de Santander

[email protected]

RESUMENEl presente artículo hace parte deldesarrollo de un algoritmo que consi-dera la influencia del relieve en lapropagación electromagnética paraun entorno semi-urbano, trabajandoen la banda de UHF (300MHz-3GHz)utilizada en los actuales y futuros sis-temas de comunicación inalámbricos(i.e. 800-900MHz en sistemasDAMPS/US-TDMA/IS-136 y GSM).El modelo base, el COST231-Walfis-ch-Ikegami, empleado en la investi-gación, demostró beneficios, junto conlos Sistemas de Información Geográ-fica (SIG) y las Herramientas de Pla-nificación, para el desarrollo de losestudios de propagación, estimaciónde coberturas y análisis de los prin-cipales factores que afectan la plani-

ficación de un sistema móvil celular.Aquí se describen los conceptos bási-cos utilizados para el desarrollo delalgoritmo aplicado, las consideracio-nes sobre las cuales se llevaron a cabolas campañas de medidas y el proce-so de validación de resultados quecomprueban la utilidad del algoritmodesarrollado para la predicción dePath Loss. El trabajo se basó en lafusión del modelo de propagaciónCOST231-Walfisch-Ikegami con laHerramienta de Planificación Cell-View (fundamentada en el SIG Ar-cView) y la realización de medicionesen la ciudad de Bucaramanga con unaunidad móvil de radiocomunicacióny control del espectro radioeléctricode propiedad del Ministerio de Comu-nicaciones de Colombia, seccional


Bucaramanga. El estudio llevado acabo para la banda del sistema IS-136, mostró resultados de simulacióny validación que permiten corroborarlas aproximaciones empleadas.

PALABRAS CLAVESWalfisch-Ikegami, GIS, CellView,modelos de propagación, Path Loss,difracción, zonas de Fresnel, sistemasmóviles e IS-136.

ABSTRACTThis paper is aimed to develop anelectromagnetic propagation algori-thm considering the influence ofmountain terrain in UHF (300MHz-3GHz) band for wireless communica-tions systems (i.e. 800-900MHz inDAMPS/US-TDMA/IS-136 and GSMstandard). The Model COST 231-Walfisch-Ikegami used in this inves-tigation proved, together with Geo-graphic Information System (GIS)and prediction tools for mobile pro-pagation, to facilitate propagationstudies, coverage analysis and analy-sis of main factors for cell planningin mobile systems.

The paper describes the basic con-cepts used to design the algorithm,the parameters used in measure-

ments and results analysis in orderto verify its applicability in cellularcoverage prediction. The studies havebeen done by the research group GTI(Grupo de Investigación en Telecomu-nicaciones e Informática) of Univer-sidad Industrial de Santander (UIS)together with Universidad Icesi, bothin Colombia, in cooperation with Va-lencia Technical University, in Spain.Measures have been done initially inBucaramanga, a city located in theAndean Mountain system, for IS-136band system. Coverage predictionshave been done using a locally modi-fied version of CellView, a GIS basedPlanning tool developed by the Valen-cia Technical University, and themeasurements was done using por-table monitoring unit (i.e. MiniportReceiver EB200-Rohde&Schwarzfrom 10kHz-3GHz) in cooperationwith the Ministry of Communicatio-ns Bucaramanga-Colombia.

KEYWORDSWalfisch-Ikegami, GIS, CellView, pro-pagation models, Path Loss, diffrac-tion, Fresnel zones, mobile planning,IS-136.

Clasificación: A


INTRODUCCIÓNLos algoritmos para la predicción depérdidas por trayectoria o Path Loss,en la propagación de ondas electro-magnéticas para la planificaciónavanzada de sistemas de comunica-ción inalámbricos, deben hacer con-sideraciones respecto a los efectos delambiente y los obstáculos sobre loscuales ocurre la propagación, como loson edificios, calles, árboles, monta-ñas, etc., entre las radio bases y losabonados móviles. Pocos estudios sehan llevado a cabo para un ambienteurbano afectado por terreno ondula-do, en condiciones como la región an-dina, con amplia presencia de colinas.Gracias a la ayuda de los Sistemasde Información Geográfica y a lasherramientas de planificación se pue-de obtener más eficiencia a la horade analizar los resultados de un mo-delo como el COST231-Walfisch-Ike-gami [10] en condiciones urbanas nouniformes sobre terreno escarpado,como ocurre en ciertos sectores de laciudad de Bucaramanga.

En Colombia y en los países de la re-gión andina, las ciudades comúnmen-te se han construido sobre terrenoondulado, habiendo así presencia decolinas, valles y edificios en un mis-mo entorno. Por lo anterior, la propa-gación de radio se ve afectada porcada uno de estos parámetros de for-ma diferente. Se han escrito variostrabajos alrededor del tema [3], [9] y[12], entre otros, pero la mayoría seenfocan a un tipo de ambiente en es-pecial ya sea urbano, rural o afecta-do por montañas. En [3] y [12] se ha-cen postulaciones para ambientesurbanos en terreno montañoso, perosolo en [12] se plantea un modelo ge-neral aunque no se ha verificado. Enel presente trabajo se valoró la pro-

pagación electromagnética sobre edi-ficios y calles, en varios perfiles deterreno, con el fin de estimar los fac-tores que introducen la variabilidaden la señal transmitida entre dospuntos. Se consideró conveniente ha-cer uso del modelo Cost231-Walfisch-Ikegami [10], una modificación de losmodelos Walfisch-Bertoni [8] e Ikega-mi [11]. Este modelo considera laorientación de las calles permitiendoobtener mejores aproximaciones enentornos urbanos.

El uso de una herramienta de plani-ficación celular como CellView, desa-rrollada por el Grupo de Comunica-ciones Móviles de la Universidad Po-litécnica de Valencia, permitió reali-zar las simulaciones con otros mode-los de propagación, aprovechando lainformación cartográfica digital exis-tente, editada y creada de la ciudadde Bucaramanga. Además, el uso delCellView permitió enlazar el nuevomodelo a la herramienta, elCOST231-Walfisch-Ikegami, admi-tiéndose de esta manera la realiza-ción de nuevas consideraciones topo-gráficas en las simulaciones, graciasa la versatilidad de su plataformaGIS.

Con el fin de confrontar los resulta-dos de simulación con una situaciónreal, se realizaron mediciones encampo haciendo uso del sistema ce-lular actualmente instalado en Co-lombia, el DAMPS/US-TDMA/IS-136, (i.e: [14]). En esta etapa del es-tudio se contó con el apoyo del Mi-nisterio de Comunicaciones de Co-lombia Seccional Bucaramanga y susUnidades de Radiocomunicación,Monitoreo y Control del EspectroRadioeléctrico, las cuales permitenobtener información en áreas preci-sas en cuanto a ubicación (por me-


dio de GPS), ancho de banda, inten-sidad (en dB µV/m), potencial (en dBµV) y desplazamiento en frecuenciade la señal analizada.

La importancia de esta investigaciónaplicada se verá reflejada en el de-sarrollo de los sistemas móviles 2G,2,5G y 3G [7], donde se debe buscarsolución al desempeño del mecanis-mo de acceso (parámetros que afec-tan la interfaz aire) y el ancho debanda disponible para las aplicacio-nes, que dependen en gran medidadel entorno en que se lleva a cabo lapropagación. La aplicación futura deeste desarrollo, y similares, permi-tirá a los operadores de telefoníamóvil minimizar costos, maximizarel cubrimiento y mejorar la calidaddel servicio, y a los entes regulado-res, estimar el impacto de las tecno-logías aplicadas (como la contamina-ción electromagnética), ejercer con-troles y establecer parámetros parala adecuada distribución del espec-tro electromagnético en cada paísque presente condiciones topográfi-cas similares a las andinas.

EL MODELO COST 231WALFISCH-IKEGAMIAntes de profundizar en los concep-tos utilizados para el desarrollo delalgoritmo implementado en la inves-tigación, se debe realizar un detalla-do estudio del modelo utilizado (i.e.[10]) y los factores que envuelven sucomportamiento físico.

En este caso, el modelo Walfisch-Ber-toni [8] ha sido combinado con el mo-delo de Ikegami [11] para considerarla difracción descendente hasta elnivel de las calles y algunos factoresempíricos de corrección para incorpo-rar acuerdos, con referencia a medi-ciones, resumidos en un único mode-

lo, basándose además, en las diferen-tes contribuciones de los miembrosdel “COST 231 Subgroup on Propa-gation Models”, dando como resulta-do el modelo COST231- Walfisch-Ike-gami. Este modelo permite incorpo-rar a la estimación de Path Loss másparámetros que describen las carac-terísticas de un ambiente urbano,estos son: alturas de edificios (hRoof),ancho de las calles (w), separaciónentre edificios (b) y orientación de lasvías (ϕ) respecto al trayecto directode radio entre la Estación Base (BS)y el Abonado Móvil (MS). Los pará-metros se definen en las Figuras 1 y2. Sin embargo, este modelo es aúnde tipo estadístico y no determinísti-co, ya que sólo puede considerar va-lores característicos del entorno y novalores específicos provenientes debases de datos topográficas, lo cualconllevó a la realización de aproxima-ciones y promedios durante el diseñodel algoritmo para el cálculo del PathLoss basados en el GIS de Bucara-manga.

El modelo distingue entre las situa-ciones en las que hay línea de vista(line-of-sight: LOS) y en las que no lahay. En el caso de LOS se aplica unafórmula simple para las pérdidas depropagación, diferente a la aplicadaen el caso de espacio libre. Esta sebasa en mediciones llevadas a caboen la ciudad de Stockholmo y estádada por:

Lb (dB) = 42.6 + 26log (d)+ 20 log (f) (1)

para d ≥ 20m, d expresada en km y fexpresada en MHz. Para condicionesNLOS (sin línea de vista) el total depérdidas está dado por:


Lb = Lo + Lrts + Lmsd para Lrts+ Lmsd > O (2)

donde L0 son las pérdidas por espaciolibre, Lmsd son las pérdidas por difrac-ción de múltiples filos de cuchillo an-tes del techo del edificio final y Lrts(roof-top-to-street) las pérdidas debi-das a una única difracción final haciael nivel de la calle, ocasionada por eltecho del último edificio, y un procesode dispersión ocurrido a esta altura.Lb dará un valor mínimo de L0 cuandoLrts + Lmsd ≤ 0 y en otros casos puedellegar a ser negativo. Las pérdidas porespacio libre están dadas por:

Figura 1. Parámetros del modelo. Geometría en terreno plano.

Figura 2. Parámetro de orientación.

Lo(dB) =32.4 + 20 log(d)+ 20 log(f) (3)

para d expresada en km y f expresadaen MHz. Un análisis detallado parala obtención de (3) y varias de las ecua-ciones presentadas a continuaciónpuede encontrarse en [1] y [2].

La determinación de Lrts se basa prin-cipalmente en el modelo de Ikegami,teniendo en cuenta el ancho de lascalles y su orientación. Sin embargo,el COST 231 aplicó otra función deorientación para las vías, diferente ala de Ikegami, resultando en:


Lbsh =

Lrts = – 16.9 – 10 log(w) + 10Log(f)+ 20Log(∆hMobile) + LOri (4)

donde w es la distancia entre las ca-ras de los edificios ubicados a los la-dos de la calle donde se encuentra elMS, típicamente w≈ b/2 y se expre-sa en metros, f en MHz y ∆hMobile enmetros. El término final de (4) consi-dera la orientación de las calles a unángulo ϕ según como se indica a con-tinuación.

- 10 + 0.354 ϕ → O° ≤ ϕ < 35°

2.5 + 0.075(ϕ – 35) →35°≤ ϕ < 55° (5)

4.0 - 0.114 (ϕ – 55) →55°≤ ϕ ≤ 90°

kf = – 4+

f925

f925

LOri =

además

∆hMobile = hRoof - hMobile (6)

La formulación electromagnética es-calar de la difracción debida a múlti-ples filos de cuchillo conlleva a unaintegral denominada Integral deaproximación de Kirchhof-Huygens(una descripción detallada de estaintegral se puede encontrar en [1, 5])a la cual Walfisch y Bertoni publica-ron una solución aproximada dada en[8], para el caso en que la antena dela BS se encuentra por encima de laaltura de los techos de los edificios.Este resultado de aproximación esextendido por el COST 231 para loscasos en que la altura de la antenase encuentra por debajo de los techosde los edificios y para ello utilizan unafunción empírica basada en medicio-nes. Resumiendo, la difracción debi-da a la presencia de múltiples techosde edificios separados a lo largo del

trayecto de radiopropagación, en eltérmino Lmsd en (2), es modelada porpantallas absorbentes de la mismaaltura de los edificios y las pérdidasa las que conlleva están dadas por:

Lmsd = Lbsh + ka + kd Log (d)+ kf Log(f) - 9 Log (b) (7)

donde d se da en kilómetros, f enMHz, b en metros y cada uno de losparámetros adicionales de (7) se es-pecifican a continuación.

18 para hBase ≥ hRoof

(8)

- 18 log(1 + ∆hBase)

para hBase > hRoof

O para hBase ≤ hRoof

54 para hBase > hRoof

ka = 54 - 0.8 ∆hBasepara d ≥ 0.5kmy hBase ≤ hRoof

54 - 08 ∆hBase

para d < 0.5kmy hBase ≤ hRoof

(9)

d0.5

ka =

(10)

kd =∆hBase

hRoof

18-15

para hBase ≤ hRoof

para ciudadesmedianas y centrossuburbanos conmediana densidadde árboles

(11)

0.7 ( –1)

1.5 ( –1)

para centrosmetropolitanos


hRoof =

donde

∆hBase = hBase - hRoof (12)

El término ka representa el incremen-to de Path Loss debido a una antenade la radio base ubicada a una alturamenor a la de los techos de los edifi-cios adyacentes. Los términos kd y kfcontrolan la dependencia de las pér-didas por difracción debidas a múlti-ples filos de cuchillos versus la dis-tancia y la frecuencia de radio, res-pectivamente. Por otro lado, si lascaracterísticas de los edificios y lascalles son desconocidas, los siguien-tes valores por defecto, para los pa-rámetros, pueden ser utilizados parala realización de un trabajo aproxi-mado:

3m * nfloors

para techos planos

3m * nfloors + 3m

para techos puntiagudos(13)

b = 20... 50m, w = b/2, ϕ = 90°

donde nfloors es el número de pisos delos edificios. El modelo está restrin-gido para 800MHz≤f≤2000MHz,4m≤hBase≤50m, 1m≤hMobile≤3m y0.02km≤d≤5km, comportándose deforma muy adecuada para situacio-nes donde la altura de la antena dela BS es mayor a la de los edificios.Sin embargo, se pueden presentargrandes errores para condiciones don-de hBase ≈ hRoof y un desempeño po-bre cuando hBase << hRoof. Por otro lado,debido a que los parámetros b, w y ϕno son considerados físicamente sig-nificativos en micro-celdas el error enla predicción de Path Loss en estoscasos puede ser demasiado grande.

El modelo no considera propagaciónmulti-trayectoria y su confiabilidaden la estimación del Path Loss dis-minuye si el terreno no es plano o sila región de cobertura no es homogé-nea. Debido a que el modelo se dise-ñó para un correcto desempeño enterreno plano, fue necesaria la reali-zación de aproximaciones para la óp-tima estimación de pérdidas de pro-pagación por medio del algoritmo di-señado, en el caso de entornos semi-urbanos sobre terreno montañoso.Estas aproximaciones se explican afondo más adelante.

Una alternativa de aproximación,para el cálculo de las pérdidas debi-das a múltiples edificios difractores,es reemplazar Lmsd por Ln(t) del mo-delo de filos de cuchillo uniformespropuesto por S.R. Saunders en [2,8.4.4]. Esto habilitaría al exponentede Path Loss para que varíe de acuer-do con el número de edificios y serademás uniformemente válido paralos casos en que hBase ≤ hRoof. Sin em-bargo, nótese que en radio bases conantenas muy bajas, otros mecanismosde propagación estarían presentes,así como la difracción alrededor de losbordes verticales de los edificios y lasmúltiples reflexiones provenientes delas paredes de los mismos, siendo sig-nificativas a la hora de predecir laspérdidas totales.

El modelo aplicado en el desarrollodel algoritmo para entornos semi-ur-banos tipo escarpado utilizó todas lasecuaciones antes mencionadas parala estimación de Path Loss, conside-rándose además la modificación pro-puesta en [4] para las pérdidas debi-das a la difracción final, provenientedel techo del último edificio, y la re-flexión de la pared del edificio si-


guiente, resumida en Lrts. De esta for-ma la constante de la ecuación (4) pa-saría de ser -16.9 a ser -8.2, obtenién-dose

Lrts = –8.2 – 10log(w) + 10Log(f)+ 20Log(∆hMobile)+LOri (14)

donde w se expresa en metros, f enMHz y ∆hMobile en metros. Una des-cripción detallada de las tesis consi-deradas para esta modificación se en-cuentra en [4].

ALGORITMO PARA ENTORNOSSEMI-URBANOSAFECTADOS POR COLINASCon el objetivo de hacer todas las con-sideraciones para un entorno semi-urbano sobre terreno escarpado (verFigura 3) se realizaron algunasaproximaciones para así poder calcu-lar el Path Loss por medio del algo-ritmo diseñado para el modeloCOST231-Walfisch-Ikegami.

Básicamente la aproximación utiliza-da sigue los principios de la difrac-ción debida a múltiples filos de cu-chillo, considerando además ciertascaracterísticas físicas del entornopara el cálculo de las pérdidas en (7)y (14). Para la obtención de todos losparámetros del modelo se consideróen primera instancia la ubicación deMS respecto al entorno; a manera deejemplo, las tres ubicaciones relati-vas presentadas en la Figura 3. Deesta forma, las alturas efectivas detodos los obstáculos presentados a lolargo del trayecto del rayo de radio-propagación, incluida la BS, tendránuna referencia cero diferente, depen-diendo de la ubicación del MS sobreel terreno. Esto ocasiona que las al-

turas de los edificios difractores(hRoof) y la de BS (hBase) varíen depen-diendo del perfil analizado y la refe-rencia dada por la ubicación del re-ceptor. Además, según sea la ubica-ción del MS, también se generaránpicos difractores en relación con lascolinas existentes a lo largo del tra-yecto, lo que ocasionará que estasafecten la altura promedio de los fi-los de cuchillo (hRoof para los cálculosfinales de Lmsd), la difracción múlti-ple, y que en ocasiones no sean lostechos de los edificios los que gene-ren la difracción final para el cálculode Lrts, sino los picos del terreno ubi-cados al final del trayecto antes delMS. Esto se muestra para las posi-ciones 2 y 3 en la Figura 3, donde elpico debajo de la posición 1 se con-vierte en un filo de cuchillo al finaldel trayecto hacia los receptores 2 y3. De igual manera las distintas coli-nas, de tamaño considerable, ocasio-narán que el valor promedio de b va-ríe según sea la separación entre losedificios y ellas mismas, como se apre-cia en la Figura 3. Por otro lado, elvalor de w dependerá del últimoobstáculo difractor ubicado antes delMS, ya sea un edificio o una colina.Según las consideraciones para estealgoritmo, todos los obstáculos sontratados como elementos de la mis-ma clase, ya que sólo se estima el efec-to difractor de los mismos, a excep-ción de los casos donde se presentaLOS, en los cuales se calcula el rayoreflejado en tierra, lo que en generalha dado resultados aceptables comose aprecia en el análisis presentadomás adelante. Dado que el modeloCOST231-Walfisch-Ikegami está ha-bilitado para los casos en que la altu-ra de la antena de la BS está a me-nor altura que la de los techos de los


Figura 3. Geometría del algoritmo implementado para la aproximación enterreno montañoso.

edificios, éste también se comporta-rá de manera aceptable cuando losedificios están ubicados sobre colinasque sobrepasan la altura hBase.

Se presentan algunos casos especia-les, también considerados dentro delalgoritmo, cuando no existe la presen-cia de edificios, estimando que elmodelo es afectado únicamente porla difracción debida a múltiples filosde cuchillo generados por los picos delterreno. Además, gracias al uso de unSistema de Información Geográfica,para cada ubicación particular delMS se analiza de forma independien-te si la variabilidad del terreno essuficiente, respecto al MS, para sertenida en cuenta dentro de los cálcu-los, y se estima de igual forma laorientación de la vía sobre la que seencuentra ubicado el receptor. Enpocas palabras, el algoritmo fue di-señado para desempeñarse en tres ca-sos diferentes e independientes: en-tornos urbanos sobre terreno plano,entornos urbanos sobre terreno mon-tañoso y entornos montañosos; habi-litando para cada uno de los casos la

presencia o no de vías con sus respec-tivos parámetros de orientación. Enparticular, en el presente artículo sehace referencia a entornos semi-ur-banos debido a que el algoritmo estácapacitado para la consideración depoca densidad de edificios sobre te-rreno montañoso o plano, y además,a que en el estudio realizado se in-cluyeron procesos de simulación yvalidación de resultados (por mediode mediciones) en un sector de la ciu-dad de Bucaramanga que cumple conestas características.

Hacia futuro, para mejorar el desem-peño del algoritmo podrían conside-rarse otra serie de aproximacionesdonde se tengan en cuenta con ma-yor veracidad la variabilidad del te-rreno y las curvaturas significativasde los picos, ya que al asumirlas deun ancho infinitesimal se está contri-buyendo al incremento del error enel cálculo del Path Loss. Una alter-nativa es considerar a las colinascomo un cilindro de radio finito, talcomo lo propone el modelo de difrac-ción por cascada cilindros [9]. Otro


Figura 4. Diagrama de bloques herramientas CellView y DCCell. CortesíaUVP

acercamiento, donde el cilindro di-fractor es aproximado a un filo decuchillo, permitiendo reducir la com-plejidad del proceso, se postula en [2,6.7]

HERRAMIENTA DE PLANIFICACIÓNCOMPUTARIZADA BASADAEN GIS - EL CELLVIEWMuchos de los modelos avanzados depropagación a menudo se implemen-tan dentro de programas de cómpu-to para hacer más práctica la plani-ficación. El desarrollo de esta clasede software basado en GIS ha sidomotivado y promovido por un grannúmero de factores, entre los cualesestán:

• La enorme y creciente necesidadde planificar sistemas celularescon precisión y velocidad.

• El desarrollo de rápidos recursosde cómputo.

• El desarrollo de sofisticados Sis-temas de Información Geográfica,los cuales pueden contener datoscartográficos e información orga-nizacional de emplazamientosurbanos, áreas de lotes, alturas deedificios, orientación de calles, al-turas del terreno, etc., y que ha-cen fácil su manipulación graciasal manejo de archivos de informa-ción tipos Vector y Raster.

Varias técnicas computacionales hansido implementadas en herramientasde planificación comerciales. Algunasde estas herramientas se listan en [2,C.2]

Para responder a los exigentes retosde modelamiento, el GCM-UPV de-


sarrolló la herramienta de planifica-ción DCCell en un entorno UNIX so-bre ARC/INFO. Más adelante se di-señó el CellView [13] sobre ArcView,herramienta que ha sido utilizada porel grupo GTI-UIS para el desarrollodel presente estudio, gracias a un con-venio de cooperación entre las Uni-versidades UVP, Icesi y la UIS, y so-bre la cual se empalmó el algoritmodiseñado para la predicción del PathLoss para entornos semi-urbanos so-bre terreno montañoso, basándose en[10] y [4]. Las dos herramientas men-cionadas aprovechan las ventajas delGIS en cuanto al manejo de archivosde información geográfica tipo Ras-ter, lo cual brindó grandes posibilida-des de manipulación de datos al al-goritmo diseñado para las distintasconsideraciones realizadas en el es-tudio de radio comunicación para laciudad de Bucaramanga. Las exten-siones del ArcView para el geoproce-samiento cartográfico, ofrecieron ayu-das adicionales para el análisis y edi-ción de datos. Entre otras, se resal-tan las extensiones: Spatial Analyst,Geoprocessing y 3D Analyst. En laFigura 4 puede apreciarse el procesollevado a cabo para el desarrollo delCellView, partiendo de la experienciadel DCCell, pasando por una prime-ra versión de CellView para Windo-ws, hasta llegar a la herramienta ac-tual sobre una plataforma ArcView(CellView v5), con posibilidades loca-les de planificación celular desarro-lladas sobre el mismo GIS y libreríasexternas fácilmente enlazables.

Para el desarrollo de la presente in-vestigación aplicada fue necesaria laedición y/o creación de tres archivostipo Raster requeridos por el algorit-mo implementado y los cuales permi-tieron incluir un nivel de realidad

mayor a la simulación. De esta for-ma, se generó dentro de la herramien-ta un nuevo tipo de análisis según elentorno, el cual fue llamado “Entor-no Total”, donde se incluyen archivosindependientes con información dealturas de edificios, alturas del terre-no y orientación de vías. En la Figu-ra 5 se presenta el esquema utiliza-do para la ejecución del algoritmo,incluyendo los archivos de entrada,funciones de manipulación y archivosde salida. En la Figura 6 se presentala interfaz de usuario para la ejecu-ción de los análisis tipo Total.

Se debe destacar que la utilización delCellView [13], como plataforma parael montaje del algoritmo diseñado enla UIS, permitió hacer cálculos de co-bertura (tipo macro-celda) con losmodelos de propagación habilitadosdentro de la herramienta (incluyen-do al nuevo modelo), cálculos de co-bertura con el modelo Walfisch-Ber-toni [8] adaptado a medidas [13],cálculos de zonas de Fresnel entre de-terminados puntos (entre la BS ypuntos donde se realizaron las cam-pañas de medidas), identificación dezonas que presentan línea de vista(LOS) e importación de archivos (enformato TEMS) de las campañas demedidas realizadas en cada una delas seis rutas seguidas en dos barriosde la ciudad de Bucaramanga. Parala habilitación de las anteriores fun-ciones fue necesaria la creación ymodificación de pequeños scrips (enlenguaje propietario Avenue del GISArcView) pertenecientes a la aplica-ción CellView, de complejidad relati-vamente baja, lo que permitió crearuna nueva proyección de georreferen-ciación para los mapas de la ciudadde Bucaramanga y los mapas de lasmediciones realizadas, además de


habilitar todas las funciones decálculo antes mencionadas.

Otras posibilidades de análisis quesurgen como ventaja de la utilizaciónde una Herramienta de Planificaciónbasada en GIS, como el CellView, sepueden apreciar en [6].

PARÁMETROS DE SIMULACIÓNPara la realización de las simulacio-nes se siguieron ciertos parámetrosde entrada y consideraciones que per-mitieron al final del proceso obtenerresultados fácilmente evaluables. Enprimer lugar, debido a los requeri-mientos del modelo de propagaciónCOST231-Walfisch-Ikegami, se nece-sitaron tres archivos de entrada talcomo se mencionó en la sección ante-rior, ellos fueron: alturas de edificios(dadas en metros), alturas del terre-no (dadas en metros) y orientación delas vías respecto al oriente geográfi-co (dada en grados). Tal como se ex-plicó previamente, todas las alturasde los obstáculos (edificios y picos delterreno) y la altura de la antena dela BS se referenciaron a la altura delterreno justo debajo de la ubicacióndel MS. En la Figura 7 se aprecianlas gráficas de los archivos de entra-da, para los edificios y el terreno, uti-lizados en la zona piloto escogida parala realización del presente estudio. LaZona Piloto para Bucaramanga seidentificó anticipadamente siguiendolos parámetros de análisis estableci-dos en la aproximación utilizada en[3] para las consideraciones del efec-to del terreno sobre el Path Loss enambientes de tipo urbano, siguiendoun modelo de colina-valle-colina en lamayoría de las direcciones. Con elobjetivo de obtener resultados útilespara la ejecución de comparacionescon otros modelos, se realizaron si-

mulaciones de forma independiente,considerando en primera instanciasólo el archivo de alturas de edificiosy utilizando todos los modelos paraentorno urbano habilitados dentro delCellView (para más detalles sobre losmodelos ver [13, A1.4]). Como segun-do paso, se realizaron simulacionescon el archivo de alturas del terrenoutilizando uno de los modelos paraentorno rural habilitado dentro de laherramienta. En el paso final, se re-currió al algoritmo diseñado para elmodelo de estudio, haciendo uso delos tres archivos de entrada de formasimultánea, opción que no se encon-traba habilitada dentro del CellView.

Siguiendo el objetivo de realizar lassimulaciones de la forma más realposible, se recurrió al estudio de losparámetros principales que definena la BS que cubre el servicio de tele-fonía móvil celular (estándar IS-136)en la zona piloto de estudio. Las ca-racterísticas principales de la esta-ción base se definen en [14], desta-cándose que el sistema actualmenteinstalado en la ciudad de Bucara-manga corresponde a una versiónTDMA que se desempeña en la ban-da de los 800-900MHz. Como uno delos principales parámetros de entra-da para el algoritmo diseñado, seencuentra el patrón de radiación delas antenas utilizadas en dicha BS,el cual correspondió a un tipo de an-tena Omni fabricada por la compa-ñía Decibel Products [15]. En estecaso la antena fue la referenciadacomo ASPD 977, cuyo patrón de ra-diación se aprecia en la Figura 8 y elcual fue obtenido gracias a los pla-nos H-V del patrón encontrado en[15]. Todos los valores de gananciade la antena, para cada uno de lospuntos en la zona de cobertura, es-


Figura 5. Diagrama de bloques del proceso de ejecución del algoritmo.Archivos de entrada, funciones y archivos de salida.

Figura 6. Interfaz de usuario para análisis tipo Entorno Total. Archivostipo Raster utilizados en el estudio para la ciudad deBucaramanga.


Figura 7. Parámetros físicos de entrada. En la parte superior se aprecianlos edificios de la zona piloto de análisis y en la parte inferior laconstitución geográfica del terreno. Las vías son definidas segúnlos contornos de los edificios y lotes del sector.

Figura 8. Patrón de radiación antena Omni ASPD 977.


tán dados en decibeles y correspon-den a la mitad volumétrica inferiordel patrón de radiación de la Figura8, teniéndose 8.5dBd como gananciade referencia para esta antena. To-dos los demás parámetros de la BS ylos utilizados como valores de entra-da para la realización de las simula-ciones se aprecian en la Tabla 1.

nectores, amplificadores, etc., delmismo equipo.

Para la realización de las campañasde medidas, utilizadas para la vali-dación de resultados del algoritmo,fue necesario el uso del Canal de Con-trol Analógico (CCA) ubicado en los880.11MHz para la BS de estudio.Dado que los resultados de las medi-ciones se dieron en dB µV/m se re-quirió la conversión de este valor aunidades manejables por el algorit-mo (i.e. dBm) y para ello se utilizó laecuación (15) obtenida de [5]. La cuales válida para una resistencia real decarga en el receptor RL = 50Ω

Pr(dBm) = E(dBµV/m)– 113dB + 10Log( )2

(15)

λπ

Los parámetros utilizados para el MSse restringieron a las característicasdel equipo de medición Miniport Re-ceiver EB200 [16], facilitado por el Mi-nisterio de Comunicaciones de Co-lombia Seccional Bucaramanga, ypara el cual se tomó como valor deganancia de recepción 0dB, debido ala compensación de ganancias y pér-didas ocasionadas por la antena, co-

Tabla 1. Parámetros de la BS y el MS. Valores de entrada para lassimulaciones.

Parámetros Valor

Pire del transmisor 42.48dBm

Ganancia del receptor OdB

Ganancia antena ASPD 977 8.5dBd

Frecuencia CCA 800.11 MHz

Altura del transmisor 40m

Altura del receptor 1.7m

Downtilt de la antena 0°Acimut de la antena 90°Factor de curvatura K 1.33

Tamaño de celdas del grid para simulación 2m


ANÁLISIS DE RESULTADOSLos resultados de simulación del al-goritmo diseñado para el modeloCOST231-Walfisch-Ikegami se mues-tran en las Figuras 9 y 10, compa-rándose en la Figura 9 (gráfica supe-rior) con los resultados de las medi-ciones realizadas en las seis rutasescogidas para las campañas de me-didas. Para las rutas 2, 3 y 5 el mode-lo se comportó de forma muy aproxi-mada y no tanto para las rutas 1,4 y6. Dado que las mediciones se lleva-ron a cabo siguiendo la consideracióncolina-valle-colina, de forma similara las posiciones 1,2 y 3 de la Figura3, agregando además una posición 4en la colina al final de la gráfica, sepuede afirmar que el modelo se com-portó de forma aceptable indepen-dientemente de la variabilidad delterreno. Sólo en condiciones donde loscambios en la altura del terreno sonmuy pequeños comparados con el pro-medio de altura de los edificios, comoes el caso de las rutas 1,4 y 6, el algo-ritmo presenta mayores errores, pro-blema fácil de solucionar para poste-riores simulaciones. Por otro lado, encasos específicos donde no se defineexactamente la orientación de lasvías, como son los puntos de conver-gencia de varias calles, se presentanlos mayores errores. Una compara-ción entre las distintas simulaciones,utilizando algunos modelos habilita-dos dentro del CellView, el algoritmodiseñado y las mediciones realizadas,se muestra en la Figura 9, gráficainferior. De esta se puede apreciarque el comportamiento del algoritmose encuentra dentro de los márgenesaceptables y que sigue de forma másaproximada el comportamiento de lasmediciones en comparación con losotros modelos.

Se debe tener en cuenta que algunosfactores no fueron considerados en lasimulación, como lo son la utilizaciónde paneles reflectores en las antenasy la distribución de la sectorizaciónde la BS, lo cual pudo ocasionar gran-des errores en zonas de solapamien-to de sectores y en donde el patrón deradiación de la antena utilizada notiene gran ganancia.

Realizando un análisis por medio delcálculo de las zonas de Fresnel, paraun perfil que cumpliera con la condi-ción colina-valle-colina, se obtuvo unresultado aceptable el cual se apre-cia en la Figura 11. Se puede valorarque a partir de los puntos donde laprimera y segunda zonas de Fresnelson obstruidas, el nivel de la intensi-dad de campo recibido decae abrup-tamente, cumpliendo con los concep-tos físicos establecidos.

CONCLUSIONESEste trabajo ha demostrado resulta-dos aceptables en cuanto al desem-peño del algoritmo diseñado para lapredicción de Path Loss en entornossemi-urbanos sobre terreno montaño-so, basándose en el modelo COST231-Walfisch-Ikegami [10], las modifica-ciones presentadas en [4] al mismomodelo y las mediciones realizadas enla ciudad de Bucaramanga. El errormedio de los resultados de simulacióncomparados con las campañas de me-didas se ubicó en el rango de los ±6dBy la desviación estándar en el rangode los 3-9dB. No se obtuvieron bue-nos resultados en los sectores dondela variabilidad del terreno era peque-ña comparada con las alturas de losedificios y en los puntos donde habíaconvergencia de varias calles. El mo-delo Walfisch-Bertoni ajustado a me-diciones, incluido en el CellView, pre-


Figura 9. Comparación de resultados de simulación versus campañas demedidas. En la parte superior se aprecian los resultados delalgoritmo diseñado relacionados con las mediciones. En elcentro y figura inferior los resultados de todos los modelosrelacionados con las mediciones.


Figura 10. Vista del resultado de la simulación (recuadro). En las regionesoscuras se presenta mayor intensidad del campo recibido y enlas más claras una menor intensidad, según los valores de laescala lateral.

Figura 11. Análisis según las Zonas de Fresnel para el barrio La Victoria. Enla parte superior se aprecian la primera y segunda zonas deFresnel para el perfil de estudio. En la parte inferior se aprecia laintensidad del campo recibido a lo largo del perfil (datos en dBm).


sentó el mayor margen de error paratodos los sectores. Los modelos Uni-Valencia y Saunders-Bonar, en lossectores de terreno plano, fueron losmás aproximados, y el modelo MeeksExacto junto con el AlgoritmoCOST231/WI presentaron un mejorcomportamiento en los sectores afec-tados por las colinas y el cañón a lolargo del perfil. De esto puede con-cluirse que el desempeño del algorit-mo en la mayoría de los casos se en-cuentra dentro de los márgenes tole-rables y que el uso de una herramien-ta de planificación basada en GISofrece grandes ventajas a la hora deobtener veracidad, simplicidad y aho-rro de tiempo en el desarrollo de es-tudios de esta clase. Como desventa-ja de la herramienta CellView estásu dependencia del lenguaje propie-tario Avenue del GIS ArcView, lo cualrestringe la manipulación de la infor-mación para el desarrollo de ciertasaplicaciones.

La aproximación por difracción demúltiples filos de cuchillo, tanto paralos edificios como para las colinas, secomportó de forma apropiada, desta-cándose que podría obtenerse un me-joramiento sustancial, mediante laaplicación de aproximaciones para elterreno, utilizando la teoría de difrac-ción por casada de cilindros plantea-da en [2, 6.7], [3] y [9]. Además, el con-tar con información cartográfica ac-

tualizada, haciendo uso de imágenessatelitales, y el conocer de forma pre-cisa el tipo de patrón de radiación dela antena transmisora, los parámetrosde ganancia-pérdidas de la BS y ladistribución de la sectorización permi-tirían realizar simulaciones más pre-cisas y confiables. Con el mismo obje-tivo de mejorar los resultados en elcálculo de Path Loss se podrían apro-vechar las ventajas de una platafor-ma GIS e incluir otros mecanismos depropagación y efectos ambientales enlas simulaciones, tales como: difrac-ción por bordes verticales de edificios,atenuación por árboles, refracción tro-posférica, temperatura ambiental ycondiciones de sol o lluvia, entre otros.

En particular, dado el gran interés enel desarrollo de una herramienta deplanificación celular para la regiónandina, basada en un software de usolibre y pensando en la llegada de lossistemas 2.5G, 3G y 4G, se concluyóla presentación de la propuesta deInvestigación Aplicada «Diseño deuna plataforma basada en GIS parael estudio de modelos de radio propa-gación en la zona andina” presenta-da ante el Sistema Nacional de Cien-cia y Tecnología de Colombia, y don-de participan los Grupos de Investi-gación GTI (de la E3T-UIS), Geomá-tica (de Ingeniería Civil-UIS), I2T (dela Universidad Icesi) y GCM (de laUPV de España).


REFERENCIAS[1]. Henry L. Bertoni. Radio Propagation

for Modern Wireless Systems, USA:Prentice Hall PTR, 2000.

[2]. Simon R. Saunders. Antennas andPropagation for Wireless Communi-cation Systems, Baffins Lane, Chi-chester, West Sussex U.K: John Wiley& Sons, Ltd., 1999.

[3]. Leonard Piazzi and Henry L. Berto-ni, “Effect of Terrain on Path Lossin Urban Environments for WirelessAplicatios”, IEEE Trans. Antennasand Propagation, Vol. 46, No. 8, Au-gust 1998.

[4]. Dongsoo Har, Alix M. Watson andAnthony G. Chadney. “Comment onDiffraction Loss of Rooftop-to-Streetin COST 231-Walfisch-Ikegami Mo-del”, IEEE Trans. Vehicular Techno-logy, Vol. 48, No. 5, September 1999.

[5]. William C. Y. Lee. Mobile CellularTelecommunicatios Systems, USA:McGraw-Hill Book Company, 1989.

[6]. Narcís Cardona Marcet y AndrésNavarro Cadavid. “Modelo de simu-lación para análisis de capacidad ensistemas W-CDMA usando herra-mientas de planificación basadas enGIS y Matlab” IEE First Internatio-nal Communications Techonologies,Londres, U.K, Marzo 2000.

[7]. Harri Holma and Antti Toskala,WCDMA for UMTS, Radio AccessFor Third Generation Mobile Com-munications, West Sussex U.K: JohnWiley & Sons, Ltd., 2000.

[8]. Joram Walfisch and Henry L. Berto-ni. “A Theoretical Model of UHF Pro-pagation in Urban Environments,”IEEE Trans. Antennas and Propaga-tion, Vol. 36, No. 12, December 1988.

[9]. D.E Eliades. “Terrain Simulation forthe Cascaded Cylinder diffraction

Model,” IEE Proceedings-H, Vol.140, No. 4, August 1993.

[10]. Cost 231 Final report. Digital MobilRadio: COST 231 View on the Evo-lution Towards 3rd Generation Sys-tems, P. 134-140, Commission of theEuropean Communities and COSTTelecommunications, Brussels, 1999.

[11]. F. Ikegami, T. Takeuchi, and S. Yos-hida, “Theoretical Prediction ofMean Field Strength for Urban Mo-bile Radio,” IEEE Trans. Antennasand Propagation, Vol. 39, No. 3,1991.

[12]. S.R.Saunders and F.R. Bonar. “Pre-diction of Mobile Radio Wave Pro-pagation Over Buildings of Irregu-lar Heights and Spacings”. IEEETransactions on Antennas and Pro-pagation, Vol. 42, No. 2, February1994, pp. 137-144.

[13]. Vicente Roig Galán. “Planificacióny análisis de sistemas de comunica-ciones móviles de tercera generaciónsobre CellView”, Universidad Poli-técnica de Valencia, Valencia Espa-ña, 1996.

[14]. Noé Darío Valero y Ricardo Carre-ño, «Sistemas móviles terrestres: di-seño de cobertura celular para laComuna 12 que conforma la ZonaMetropolitana de Bucaramanga»,Universidad Pontificia Bolivariana,Especialización en Telecomunicacio-nes, Agosto de 2001.

[15]. “Vari-Tilt Omni Antenna - ASDP-975, ASPD-977, ASP-978, 8.5 to10dBd Gain”, web page Decibel Pro-duts: www.decibelproducts.com

[16]. “Miniport Receiver EB200 - Porta-ble Monitoring From 10kHz to3GHz”, web page Rohde&Schwarz:www.rohde-schwarz.com


CURRÍCULOS

ALEXIS PAOLO GARCÍA ARIZA. Nació enBucaramanga-Colombia el 9 de ju-nio de 1978. Obtendrá el título deIngeniero Electrónico en diciembrede este año en la Universidad In-dustrial de Santander, Escuela deIngenierías Eléctrica, Electrónicay Telecomunicaciones. Hace partedel Grupo de Investigación en Te-lecomunicaciones e Informática-GTI-UIS, Bucaramanga-Colom-bia. Actualmente, como tesis decarrera y base de este artículo, rea-liza investigaciones en el ámbitode Modelos de Propagación aplica-bles a la región andina utilizandoGIS, en cooperación con el Minis-terio de Comunicaciones de Colom-bia-Seccional Bucaramanga, Icesiy la UPV. Sus áreas de interés in-cluyen sistemas de tercera gene-ración, sistemas de informacióngeográfica aplicados a las teleco-municaciones, modelos de propa-gación y redes de datos móviles.(Teléfono: (57 7) 634 4000 -Ext.2356, 637 5356e-mail: [email protected],[email protected]).

HOMERO ORTEGA BOADA. Ph.D. of En-gineering Sciences de la Universi-dad Internacional de la AviaciónCivil de Kiev-Rusia. Actualmentetrabaja como profesor e investiga-dor en la Universidad Industrialde Santander, Escuela de Ingenie-ría Eléctrica Electrónica y de Te-lecomunicaciones, pertenece alGrupo de Investigación en Teleco-municaciones e Informática-GTI-UIS, Bucaramanga-Colombia. An-teriormente trabajó como instruc-tor e investigador en la empresaEricsson, con tecnologías comoPSTN, IN, ATM, IP, NGN, DWDM,

DataCom. A.A. 678 Bucaramanga,Colombia (Teléfono:+573 259 4033,e-mail: [email protected]).

ANDRÉS NAVARRO CADAVID. Nació enMedellín, Colombia, el 28 de mayode 1969. Ingeniero Electrónico dela Universidad Pontificia Boliva-riana. Obtuvo la Maestría en Ges-tión Tecnológica en la UniversidadPontificia Bolivariana y ahora escandidato a Doctor Ingeniero deTelecomunicación en la Universi-dad Politécnica de Valencia, Espa-ña. Actualmente trabaja como pro-fesor e investigador de la Univer-sidad Icesi, Cali-Colombia. Dirigeel Grupo de Investigación en In-formática y Telecomunicaciones-I2T-Icesi. Sus áreas de interés in-cluyen sistemas de tercera gene-ración, CDMA, sistemas móviles yredes de datos móviles (Teléfono:(57 2) 555 2334 - Ext.410,555 1745,e-mail: [email protected]).

ALEXYS HERLEYM RODRÍGUEZ AVELLA-NEDA. Nació en Bucaramanga-Co-lombia el 22 de septiembre de1975. Ingeniero Civil de la Univer-sidad Industrial de Santander, Es-pecialista en Telecomunicacionesde la Universidad Autónoma deBucaramanga. Actualmente tra-baja con Sistemas de InformaciónGeográfica, Herramientas CAD,GPS, procesos de Teledetección yBases de Datos. Sus áreas de inte-rés incluyen sistemas de informa-ción geográfica aplicados a las te-lecomunicaciones, redes de datos,sistemas de posicionamiento y lasáreas referentes a la Geo-mática.(Teléfono: (57 7) 634 4000-Ext.2356, 637 2701 e-mail:[email protected]).


RESUMENEn este trabajo el término arquitec-tura se refiere principalmente a la es-tructura lógica de sus componentesde software. Sin embargo, cuando serequiera, otros aspectos tales como elhardware y el sistema operativo setienen en cuenta. El objeto del siste-ma resultante es brindar dos servi-cios de telemedicina otorrinolaringo-lógica a practicantes en medicina o adoctores en locaciones remotas. Engeneral, el difícil acceso a la prácticay la dificultad de acceder a serviciosmédicos en locaciones geográficamen-te remotas son situaciones comunesen América Latina. De acuerdo conesto, un sistema de soporte sería degran ayuda. Los servicios sugeridos,

Arquitectura de software basadaen la internet para la simulación virtual

de cirugía endoscópicaotorrinolaringológica

Andrés A. NavarroPontificia Universidad Javeriana

[email protected]

Jorge A. VélezServicios de Salud Ecopetrol

[email protected]

Luis E. MúneraUniversidad Icesi

[email protected]

Gregorio BernabéUniversidad de [email protected]

entrenamiento remoto utilizando si-mulación virtual y soporte remoto ala toma de decisiones, deben estarsoportados por una arquitecturaapropiada a la internet. Este docu-mento presenta primero una intro-ducción al proyecto. Seguidamente sedescribe la novedad del trabajo. A con-tinuación se detallan los servicios yla arquitectura propuestos. Final-mente, se presentan los resultados yuna serie de conclusiones y pasos aseguir.

PALABRAS CLAVESTelemedicina, medicina virtual, rea-lidad virtual, otorrinolaringología.

Clasificación: A


ABSTRACTIn this work, the term architecturerefers mainly to the overall structu-re of its logical software components.However, when required, other as-pects, like the hardware and the ope-rating system, are taken into account.The aim of the resulting system is toprovide two telemedicine services inotolaryngology for doctors in remotelocations or to practitioners. Difficultaccess to medical services in remotegeographical location is a common si-tuation in Latin America. Accordingto this, a support system would behelpful. The suggested services, re-mote training using virtual simula-

tion and remote decision support,must be supported using a softwarearchitecture that is appropriate forthe Internet. This document presentsfirst an introduction to the projectfollowed by a description of the pro-blem and the novelty of the work.Next a preliminary description of thearchitecture is done before the resul-ts of the project are shown. Finally,conclusions and further work arepresented.

KEYWORDS:

Telemedicine, virtual medicine, vir-tual reality, Otolaryngology


INTRODUCCIÓNLa cirugía endoscópica o cirugía demínimo acceso (CMA) tiene como pro-pósito minimizar el trauma y los cos-tos de recuperación del paciente. Sinembargo, no sólo el procedimientoquirúrgico sino el entrenamiento denuevos cirujanos puede ser un pro-blema debido a las habilidades deorientación, triangulación y dexteri-dad que deben ser adquiridas [1].

Hay una larga curva de aprendizajeasociada con las CMA. No existe unsistema de entrenamiento estándar encirugía endoscópica. En principio, elpracticante puede operar dentro deuna estructura de caja con el fin deobtener las habilidades básicas deorientación y dexteridad. Más adelan-te, los procedimientos operativos pue-den ser simulados por medio de órga-nos artificiales que son inexactos ycostosos. Una etapa posterior podríaser la utilización de órganos de cadá-veres. Después de pasar las etapasdescritas, el practicante puede parti-cipar en procedimientos endoscópicossupervisados en pacientes humanos.Básicamente, el proceso consiste enaprender el procedimiento observan-do a un cirujano experto realizar pro-cedimientos supervisados y, enseñara la siguiente generación de practican-tes. Sin embargo, en un marco de tra-bajo como este los datos para una eva-luación objetiva son difíciles de obte-ner, los sistemas de ayuda y guía paracirujanos no son posibles y las patolo-gías extrañas no son accesibles [1].

Existen muchas investigaciones cuyoobjeto es resolver los problemas enun-ciados en el campo de la realidad vir-tual. Varias han tenido resultadosexitosos. De cualquier manera, toda-vía falta mucho por realizar [2] [3].

Por otra parte, los médicos o practi-cantes que se encuentran en locacio-nes geográficamente remotas no tie-nen la misma cantidad de pacientes,patologías y recursos que serían de-seables para obtener un nivel de ex-periencia adecuado. Adicionalmente,estos no cuentan con ayuda de exper-tos en situaciones críticas. Existe, portanto, un problema para la difusióndel conocimiento médico. Una herra-mienta como la propuesta traeríagrandes beneficios. La telemedicina esla entrega de servicios de salud a tra-vés de la distancia, utilizando tecno-logía de telecomunicaciones. Esta in-formación puede incluir informacióndel paciente, imágenes, entrevistas yexámenes, consultas con especialistasmédicos, actividades educacionales enel cuidado de la salud, etc. [4]. En re-sumen, las principales ventajas de latelemedicina están en la descentrali-zación del cuidado del paciente, en laasistencia y el entrenamiento remotoy en el acceso a información médicade carácter educativo y clínico [5].

Existen en la actualidad algunas ini-ciativas interesantes que pretendenbrindar servicios de telemedicina auna comunidad geográficamentegrande y dispersa [6]. Esta propues-ta, que inicia brindando dos serviciosen otorrinolaringología, es una deellas.

NOVEDAD DEL TRABAJOEste proyecto está produciendo enprimer término una arquitectura desoftware que es apropiada para lainternet y que estará en capacidad deejecutar una simulación quirúrgicaotorrinolaringológica. Es cierto quecuando se pretende ejecutar una si-mulación de manera distribuida através de la internet, el desempeño


del sistema se puede ver afectado porlas consideraciones tecnológicas y detiempo real. Sin embargo, la creaciónde una arquitectura eficiente y losdesarrollos en nuevos protocolos deinternet y la internet II [7] puedencontribuir a la solución. Es importan-te aclarar que la creación de nuevosprotocolos de sistemas de red no estádentro del alcance de este trabajo. Acambio, el proyecto está orientadohacia la creación de un sistema efi-ciente que utilice los recursos dispo-nibles. Este sistema, por supuesto,contribuirá a futuros desarrollos.

El proyecto propone además la crea-ción de mecanismos de interacciónhumano-computadora novedosos quevayan más allá de la interfaz gráficade usuario tradicional.

Se propone también un sistema ex-perto de soporte a la decisión basadoen la WEB (WEDS) y un sistema detransmisión de vídeo de manera efi-ciente.

Por otra parte, el sistema está sien-do complementado con un instrumen-to de planeación quirúrgica.

Finalmente, el campo de aplicaciónmédica sugerido para esta aplicaciónno ha sido muy tratado en el mundo;tampoco se ha pensado mucho en suaplicación en Latinoamérica.

SERVICIOS PROPUESTOSPara la implantación inicial de la ar-quitectura se han propuesto los si-guientes servicios:

A. Telesimulación virtual de lacirugía funcional endoscópicade senos paranasales (FESS).

En principio, es necesario entender yrepresentar la anatomía involucradaen la simulación. En esta etapa se

puede presentar una visualizacióninicial interactiva y en tres dimensio-nes (3D) de los órganos involucradosen el procedimiento. Esto facilita a lospracticantes la comprensión espacialy topológica de la anatomía antes deenfrentarse a cualquier procedimien-to. Seguidamente, se puede imple-mentar un prototipo al nivel de ani-mación que permita visualizar losprocedimientos a practicar con todassus etapas. En esta etapa, el serviciode simulación puede permitir detec-tar el tipo de información que debemostrarse y cómo debe ser mostrada.Finalmente se puede brindar una in-teracción completa a través de unasimulación más realista que permitala práctica del procedimiento quirúr-gico. El sistema puede ser comple-mentado además por vídeos de ciru-gías FESS reales.

B. Sistema experto de soporte a ladecisión (WEDS)

Este sistema es un prototipo de unsistema experto que está en capaci-dad de sugerir la necesidad de llevara cabo o no una cirugía FESS otorri-nolaringológica. Un sistema como elpropuesto puede apoyar a un médicoen la toma de una decisión, especial-mente cuando no cuenta con exper-tos a quienes consultar.

DESCRIPCIÓNDE LA ARQUITECTURALa Figura 1 muestra la arquitectu-ra. Actualmente se han detectado sie-te módulos que podrían funcionar demanera distribuida. Estos se explicana continuación:

1. Dispositivos. Este módulo tieneque ver con el hardware que uti-liza el sistema para comunicarsedirectamente con el usuario.


2. Interacción. El propósito de estemódulo es hacer al sistema inde-pendiente del hardware. Este co-munica las entradas de los usua-rios al módulo de servicios. Tam-bién, presenta la interfaz gráficade usuario (GUI) apropiada al ser-vicio. Además, envía la salida delsistema al módulo de dispositivos.

3. Servicios. Este módulo adminis-tra los aspectos de comunicaciónde un servicio enviando los reque-rimientos al módulo de mediacióny parámetros de interfaz gráficaal módulo de interacción.

4. Mediación. Es el módulo que pro-cesa los requerimientos del módu-lo de servicios comunicándose conel módulo de objeto. También li-bera a los módulos de dispositivos,interacción y servicios de cálculosmás complejos.

5. Información. Es el módulo respon-sable de entregar la informaciónrequerida de acuerdo con el ser-vicio en un formato estándar.

6. Objeto. Este módulo tiene que vercon el modelamiento de los órga-nos y las herramientas quirúrgi-cas. Se subdivide a su vez en lossub-módulos de comportamientoy de geometría. El sub-módulo decomportamiento recrea el compor-

tamiento autónomo de los objetosa través de técnicas matemáticas,físicas, de ingeniería o de inteli-gencia artificial. El sub-módulo degeometría tiene que ver con el es-tado de un objeto y su represen-tación geométrica virtual. El es-tado de un objeto se basa en susatributos.

7. Comunicación. Es la plataformadistribuida en la que se ejecuta laaplicación. En este caso la inter-net y alguna tecnología de desa-rrollo distribuida como Corba [8],Enterprise Java Beans [9] oDCOM de Microsoft [10].

Al culminar la construcción de la ar-quitectura, cada módulo en la Figu-ra 1 estará compuesto por uno o va-rios componentes de software. Esto,con el fin de poder reutilizar sus ser-vicios en otras patologías y procedi-mientos en otorrinolaringología y fa-cilitar la escalabilidad en términosde la adición de conocimiento, deusuarios y de servicios. En la Figu-ra, las flechas hacen referencia amódulos que se comunican entre sí.La idea es que los módulos sean in-dependientes del hardware de comu-nicaciones y de los sistemas operati-vos elegidos a través de la utiliza-ción de una de las tecnologías de de-sarrollo distribuidas.

Figura 1. Arquitecturadel sistemapropuesto.

Usuario

Objeto

Comunicación

Comportamiento

Dispositivos

Interacción

Servicios Mediación

Información

Geometría


RESULTADOSHasta la fecha el proyecto ha arroja-do una serie de resultados interesan-tes. Estos, son más que todo prototi-pos de los servicios que prestará laarquitectura. Los desarrollos realiza-dos se enmarcan principalmente enlos módulos de interacción y serviciosde la misma, aunque se han comen-zado también a visualizar aspectos atener en cuenta en los demás módu-los. Además, se está complementan-do el sistema con un instrumento deplaneación quirúrgica. Los resultadosson descritos a continuación.

A. Prototipo de un endoscopiovirtual

Este componente del sistema ha mos-trado el potencial educativo que pue-de tener la interacción con instru-mentos quirúrgicos virtuales antes deutilizar los instrumentos reales. Elprototipo muestra un endoscopio in-teractivo que puede ser manejado alinterior de una sala de cirugía. Estees mostrado en la Figura 2 [11].

B. Trabajos de gradoA través de la realización del proyec-to se ha logrado crecer en la interac-ción con estudiantes de pregrado quehan ido contribuyendo con sus apor-tes al crecimiento de la arquitectura.Un trabajo de grado reciente [12],realizado con anterioridad al inicio dela arquitectura ha evidenciado la po-sibilidad de hacer mejoras importan-tes sobre las interfaces gráficas deusuario tradicionales. En este caso secomplementan las arquitecturas deinterfaces tradicionales orientadas aventanas con la introducción de con-troles transparentes y lentes mágicos[13]. El resultado obtenido por esteestudiante y los trabajos enunciadosen el Congreso Mundial de Medicinay Realidad Virtual [3] inspiran y de-muestran que se puede ir mucho másallá en la interacción con los sistemasde software en general. Es así comoen la actualidad se está iniciando laconstrucción de un modelo de lentesmágicos y un componente de visiónestereoscópica que complementaránla arquitectura. Cabe destacar queademás del módulo de interacción,existen estudiantes que están gene-rando aportes en otros módulos de laarquitectura gracias a la orientacióny coordinación de los directores delproyecto.

C. Prototipos de animación para lacirugía endoscópica FESS

En este desarrollo [14] se sugiere unaforma de presentar el procedimientoquirúrgico de la FESS con sus dife-rentes pasos tal como se muestra enlas Figuras 3a y 3b. Este es el puntode partida para un servicio de telesi-mulación más realista. Además, estaparte del sistema está complementa-da por imágenes reales de los pasos

Figura 2. Prototipo de unendoscopio virtual.


quirúrgicos (ver Figura 3d) y un sis-tema de transmisión de vídeos médi-cos (ver Figura 3c).

D. Sistema de transmisiónde vídeo

Se han logrado desarrollos paratransmisión de vídeos médicos a tra-vés de la internet. Se propone un nue-vo estándar que utiliza una transfor-mada que además de eliminar lasredundancias temporales y espacia-les no divide la imagen en bloques,evitando la aparición de artefactos enla imagen reconstruida [15].

E. Sistema experto de soportea la decisión

Este sistema [16] establece un meca-nismo interactivo a través de la in-ternet. Ha sido concebido para brin-dar ayuda en la toma de decisionesen el contexto quirúrgico de la FESS.La representación de las decisiones

tomadas está basada en el Compen-dio de Indicadores Clínicos de la Aso-ciación Americana de Otorrinolarin-gología – Cirugía de Cabeza y Cuello[17], adoptado por la Sociedad Oto-rrinolaringológica Colombiana [18].

Figura 3. Interfaz gráfica de usuario. (a) Ventana de simulación. (b) Vistaanatómica. (c) Vídeo. (d) Imagen del paso quirúrgico.

F. Interfaz gráfica de usuarioHasta el momento se han considera-do algunos elementos de interfaz grá-fica de usuario como cruciales parael servicio de telesimulación quirúr-gica de la FESS, a saber:

1. La Figura 3a muestra la ventanade simulación quirúrgica que per-mite utilizar directamente el si-mulador.

2. La Figura 3b presenta la vistaanatómica que permite mostrar,especialmente a los nuevos ciru-janos, con mayor claridad el pasoquirúrgico correspondiente.


3. La Figura 3c muestra un vídeo delprocedimiento a seguir.

4. La Figura 3d muestra una ima-gen del paso quirúrgico actual.

dica y puede brindar apoyo en la pla-neación médica y en la educación.

El instrumento fue aplicado duranteun período de seis meses en 32 ocasio-nes. En cada ocasión, éste fue llenadopor la cabeza del equipo quirúrgico.

Para la validación del instrumento seutilizó una escala de 0 (no se cumple)a 5 (se cumple totalmente). Además,se utilizaron los siguientes criterios:

1. El instrumento es efectivo y con-tribuye a los propósitos con que fuecreado. a) Representa el eventoquirúrgico de manera adecuada. b)Es consistente. c) Contribuye a au-mentar las habilidades quirúrgi-cas. d) Ayuda en la prevención decomplicaciones quirúrgicas.

2. Satisfacción del usuario. a) Es fá-cil de utilizar. b) Toma poco tiem-po aprender su utilización.

Los resultados de la aplicación del ins-trumento se muestran en la Tabla 1.

Tabla 1: Aplicación del instrumento de planeación quirúrgica

0 1 2 3 4 5

Efectividad del instrumento

a) 0 0 0 0.25 0.594 0.156

b) 0 0 0.156 0.25 0.406 0.188

c) 0 0 0 0.282 0.5 0.218

d) 0 0.062 0.094 0.188 0.531 0.125

Satisfacción del usuario

a) 0 0 0 0.344 0.218 0.438

b) 0 0 0 0.218 0.438 0.344

Escala de resultados entre 0 y 1

G. Instrumento de planeaciónquirúrgica

Se ha creado una herramienta paradistribuir el conocimiento médico ge-nerado en el proceso de planeaciónquirúrgica y se está creando una basede datos de cirugías a las cuales seles ha aplicado el instrumento. Estoes importante ya que la carencia deinstrumentos de planeación quirúr-gica de uso rutinario conlleva al des-conocimiento de situaciones vitalesrelacionadas con el proceso quirúrgi-co de pacientes.

La herramienta propuesta contribu-ye a una mejor utilización del mode-lo de cirugía virtual y del WEDS.Además, se constituye en un elemen-to importante para la auditoría mé-


CONCLUSIONESDurante el desarrollo del proyecto se hallegado a las siguientes conclusiones:

1. Existe la necesidad de crear mo-delos y métodos que sean capacesde apoyar el entrenamiento depracticantes médicos y de ciruja-nos con poca experiencia. La rea-lidad virtual y las nuevas tecno-logías de telecomunicaciones pue-den contribuir a la creación de losmismos.

2. La inteligencia artificial puede serutilizada para soportar la toma dedecisiones por parte de médicos ypracticantes, sobre todo en aque-llas situaciones de emergencia enque los expertos humanos no es-tán disponibles.

3. Las interfaces gráficas de usua-rio y los mecanismos de comuni-cación humano-computadora tra-dicionales pueden ser mejoradoscon la utilización de conceptos in-novadores que hasta ahora hansido poco empleados.

4. La falta de instrumentos de pla-neación quirúrgica puede condu-cir a una mayor probabilidad defallo en dichos procedimientos.

5. La telemedicina, en general pue-de contribuir a resolver el proble-ma de difusión del conocimientomédico.

6. El sistema presentado en este do-cumento es un sistema en conti-nua evolución y requiere un tra-bajo interdisciplinario para sumejoramiento y crecimiento.

7. La simulación quirúrgica previaa la realización de cirugías se haconstituido recientemente en unaayuda de entrenamiento y adqui-

sición de habilidades para el ci-rujano a cargo y para todo el equi-po quirúrgico.

8. De otro lado, las ayudas de la tec-nología de la información, como esel caso de la internet en el pro-yecto, puede generar un escena-rio en el que se compartan expe-riencias, percepciones y expecta-tivas de las diferentes especiali-dades quirúrgicas.

9. Se puede pensar en modelar unsistema que ofrezca servicios detelemedicina otorrinolaringológi-ca como una serie de módulos quepuedan comunicarse entre sí yfuncionar de manera distribuida.

TRABAJOS FUTUROSEs por supuesto necesario continuardesarrollando la arquitectura en lossiguientes aspectos:

1. El trabajo todavía muestra ani-maciones a manera de prototipo;es conveniente proseguir la inves-tigación para lograr una simula-ción más realista.

2. Los elementos de interfaz gráficade usuario detectados deben serintegrados de una mejor manera.

3. El proceso de validación médicadebe seguir. Además, se debe ela-borar y ejecutar un plan de prue-bas de desempeño.

4. Es necesario continuar con el de-sarrollo y evolución de los compo-nentes que constituyen la arqui-tectura. De esta manera se puedelograr pasar de prototipos, que sibien funcionan y muestran resul-tados interesantes, no brindantodavía la flexibilidad y modula-ridad de los componentes de soft-ware propuestos.


5. Se sugiere identificar nuevos ser-vicios.

6. Se piensa seguir aplicando el instru-mento de planeación quirúrgica.

AGRADECIMIENTOSLos autores expresan sus agradeci-mientos a las siguientes personas:Francisco J. Herrera, Luis E. Garre-ta, Antonio J. Reyes, Rodrigo De LaPeña, Andrés F. Robledo, Andrés F.Prada, Carlos A. Gamboa.

[10] Microsoft. DCOM.http://www.microsoft.com/com/tech/dcom.asp, 2002.

[11] F. J. Herrera. Análisis, diseño e im-plantación del prototipo de un endo-scopio virtual. Cali: Ponti-ficia Uni-versidad Javeriana, 2001.

[12] L. Garreta. Arquitectura orientadaa objetos para el modelamiento defiltros de lentes mágicas como ele-mentos de visualización dentro delas interfaces gráficas de usuarioactuales. Cali: Pontificia Universi-dad Javeriana, 2001.

[13] J. Viega, M. Conway, G. Williams yR. Pausch. 3D Magic Lenses. Uni-versity of Virginia. 2000.

[14] A. A. Navarro, J. A. Vélez y L. E.Múnera. A software architecture forvirtual simulation of endoscopic sur-gery in a WEB based scenario. 10th

Medicine Meets Virtual Reality Con-ference, Newport Beach, Jan. 23-26,2002.

[15] G. Bernabé, J. González y J. Duato.Applying the 3D- wawelet transformto transmit medical video in telemed-icine. En Real Word Medical Appli-cations: Mednet 2002. Brucelas: IOSPress.

[16] J. A. Vélez y C. A. Gamboa. A vir-tual surgery model: fundamentals onelectronic endoscopic otolaringologyWEB based scenario. 6th AmericanTelemedicine Association Meeting,Fort Lauderdale, June 3-6, 2001.

[17] American Academy of Otolaryngol-ogy - Head and Neck Surgery. Clin-ical Indicators Compen-dium. Bul-letin, vol 18 no. 10, octubre 1999.

[18] Sociedad Colombiana de Otorrino-laringología. Acta Sociedad Colom-biana de Otorrinolaringología -SCORL. Indicadores Clínicos.1999.

REFERENCIAS[1] A. A. Navarro. The Implementation

of a Windows 95 based Virtual En-vironments Knee Arthroscopy Train-ing System. Hull: University of Hull,1997.

[2] R. S. Kalawsky. The Science of Vir-tual Reality and Virtual Environ-ments, Wokingham: Addison-Wes-ley, 1994.

[3] J. D. Westwood, H. M. Hoffman, R.A. Robb y D. Stredney. MedicineMeets Virtual Reality 02/10. Wash-ington D.C: IOS Press, 2002.

[4] J. Collins. Telemedicine. http://hhd.csun..edu/sheila/pptproject/jennc/, 2002.

[5] The Telemedicine Project. http://www.cee.hw.ac.uk/ Databases/telemed.html, 2002.

[6] K. Boddy y D. Sotiriou. Hermes De-riverable 9.3. Edimburgh: HermesLibrary. http://www.hermes.ed.ac.uk, 1999.

[7] Internet2 Consortium, Internet2.http:// www.internet2.edu, 2002.

[8] Object Management Group. Corba.http:// www.corba.org, 2002.

[9] Sun Microsystems. Enterprise JavaBeans. http:// java.sun.com/ products/ejb/, 2002.


CURRÍCULOSAndrés. A. Navarro. Realizó estudios de

Ingeniería de Sistemas y Compu-tación en la Pontificia UniversidadJaveriana en Cali. Posteriormen-te hace una Maestría en Compu-tación Gráfica y Ambientes Virtua-les en la Universidad de Hull enInglaterra. Además, tiene título deEspecialista en Redes y Comuni-caciones de la Universidad Icesi enCali. Actualmente trabaja comodocente investigador en la Ponti-ficia Universidad Javeriana enCali Colombia.

Jorge A. Vélez. Médico de la Universi-dad Libre de Cali y Especialista en

Gestión de la Salud de la Univer-sidad Icesi de Cali. Es fundador dela Asociación Internet Salud y Me-dicina Colombia y se desempeñacomo administrador de los servi-cios de salud de Ecopetrol en Cali,Colombia.

Luis. E. Múnera. PhD en InteligenciaArtificial de la Universidad Poli-técnica de Madrid y Docente de laUniversidad Icesi en Cali.

Gregorio Bernabé. Recibe una maestríaen ciencias de la computación en laUniversidad de Murcia donde ac-tualmente es candidato a PhD. Allí,se desempeña como profesor asis-tente.


KeyConcept:Un motor de búsqueda conceptual

Juan Manuel Madrid MolinaDepartamento de Redes y Comunicaciones

Universidad Icesi-I2TCali, Colombia

[email protected]

Susan GauchEECS Department

University of KansasLawrence, KS 66045 (USA)

[email protected]

RESUMENA medida que el número de páginasweb disponible crece, los usuarios ex-perimentan dificultades para hallardocumentos que les sean de interés.Una de las razones subyacentes deeste problema es que la mayoría delos motores de búsqueda encuentrandocumentos basándose solamente enpalabras claves, sin fijarse en los sig-nificados de dichas palabras. Parabrindar al usuario información másútil, se requiere de un sistema queincluya en la búsqueda informaciónacerca del marco conceptual de la con-sulta, además de las palabras claves.Este es el objetivo de KeyConcept, unmotor de búsqueda que recupera do-cumentos usando una combinación deconceptos y palabras claves. Los do-cumentos se clasifican automática-

mente para determinar sus conceptosasociados. Los conceptos relacionadoscon la consulta son introducidos ma-nualmente por el usuario, o determi-nados automáticamente medianteuna pequeña descripción textual de laconsulta. Este artículo describe la ar-quitectura del sistema, el entrena-miento del clasificador, y los resulta-dos de nuestros experimentos de eva-luación de desempeño del sistema. Sedemuestra que KeyConcept incremen-ta en forma significativa la precisiónde las búsquedas mediante el uso dela recuperación conceptual de infor-mación.

PALABRAS CLAVESBúsqueda conceptual, clasificación detexto, ontologías.

Clasificación: A


ABSTRACTAs the number of available Web pa-ges grows, users experience increa-sing difficulty finding documents re-levant to their interests. One of theunderlying reasons for this is thatmost search engines find matchesbased on keywords, regardless oftheir meanings. To provide the userwith more useful information, weneed a system that includes informa-tion about the conceptual frame of thequeries as well as its keywords. Thisis the goal of KeyConcept, a searchengine that retrieves documents ba-sed on a combination of keyword andconceptual matching. Documents are

automatically classified to determi-ne the concepts to which they belong.Query concepts are determined au-tomatically from a small descriptionof the query or explicitly entered bythe user. This paper describes thesystem architecture, the training ofthe classifier, and the results of ourexperiments evaluating system per-formance. KeyConcept is shown tosignificantly improve search resultprecision through its use of concep-tual retrieval.

KEYWORDSConceptual search, text classification,ontologies.


INTRODUCCIÓNLa Web ha experimentado un creci-miento sostenido desde su creación.En marzo de 2002, el motor de bús-queda más grande contenía aproxima-damente 968 millones de páginas in-dexadas en su base de datos [SES 02].Encontrar la información correcta enuna colección de documentos de taltamaño es extremadamente difícil.Una de las razones principales paraobtener resultados insatisfactorios enlas búsquedas es que muchas palabrasposeen múltiples significados [Krove-tz 92]. Por ejemplo, dos personas queefectúan una búsqueda usando la pa-labra clave “jaguar” pueden estar bus-cando cosas completamente diferentes(animales salvajes y automóviles), ysin embargo obtendrán exactamentelos mismos resultados. Esta dificultadse presenta porque la mayoría de losmotores de búsqueda usan un algorit-mo de búsqueda de frases que regre-sa como resultados todos los documen-tos que contengan una ocurrenciaexacta de los términos usados en laconsulta, sin importar su significado.

Para resolver este problema estamosdesarrollando KeyConcept, un motorde búsqueda que, además de las pa-labras claves, toma en cuenta los tó-picos o conceptos relacionados con laconsulta. Los documentos se indexanpor palabras claves y por conceptosque se escogen automáticamente dela ontología Open Directory. En elproceso de recuperación, además delas palabras claves, el motor de bús-queda recibe uno o más identificado-res de concepto que se usan para res-tringir el dominio de la búsqueda. Lostópicos de la consulta pueden ser es-pecificados manualmente por el usua-rio, o se pueden hallar automática-mente pasando una pequeña descrip-

ción de la consulta por un clasifica-dor. Este artículo reporta los resulta-dos de los experimentos que se reali-zaron para evaluar la importanciarelativa dada a la búsqueda por con-ceptos y por palabras claves en el pro-ceso de recuperación.

El resto del artículo comienza con unapresentación de investigación previarelacionada con el tema en la sección2. La arquitectura de KeyConcept sedescribe en la sección 3. La sección 4describe los experimentos de entrena-miento del clasificador y desempeñodel sistema, junto con la discusión delos resultados. Finalmente, se conclu-ye con algunas observaciones e ideaspara trabajo futuro en la sección 5.

INVESTIGACIÓN PREVIARELACIONADA

Clasificación de textoLos algoritmos de clasificación de tex-to organizan la información, asocian-do un documento con los conceptosque más se relacionan con su conte-nido; dichos conceptos se escogen deun conjunto predefinido. Se han de-sarrollado varios métodos para clasi-ficación de texto, cada uno con dife-rentes métodos para confrontar undocumento nuevo con el conjunto dereferencia, tales como representacio-nes vectoriales de los documentos(Support Vector Machines, k-NearestNeighbor, Linear Least-Squares Fit,TF-IDF), uso de probabilidades con-juntas de que las palabras estén enel mismo documento (Naïve Baye-sian), árboles de decisión y redes neu-ronales. Se puede encontrar un resu-men muy completo y una compara-ción de dichos métodos en [Yang 99],[Pazzani 96] y [Ruiz 99].

De acuerdo con [Chekuri 97] y [Mat-suda 99], una de las aplicaciones prin-


cipales de la clasificación de texto esrestringir el dominio de búsqueda. En[Chekuri 97], los usuarios tienen laopción de especificar algunos concep-tos de interés cuando introducen unaconsulta. El sistema busca documen-tos únicamente en los conceptos quese especifiquen. [Matsuda 99] extien-de esta idea clasificando los documen-tos usando, además del contenido,otros atributos tales como tamaño,número de imágenes, presencia o au-sencia de ciertas etiquetas. En estesistema, el usuario tiene la opción deespecificar el tipo de documento queestá buscando (por ejemplo un catá-logo, un FAQ) conjuntamente con laspalabras claves de la búsqueda.

En el proyecto Obiwan [Pretschner99] se emplean ontologías para repre-sentar perfiles de usuario. Las con-sultas se efectúan por medio de unmotor de búsqueda tradicional, y losresultados se clasifican en los concep-tos de la ontología usando los resú-menes de documento que se incluyenen la página de resultados. Luego, elconjunto de resultados es reorganiza-do con base en el cruce de los concep-tos relacionados con cada resumen ylos conceptos con más peso en el per-fil de usuario. A pesar de que estemétodo permitió mejorar el orden delos resultados, no fue capaz de encon-trar más información para los usua-rios debido a que este esquema tra-baja con los resultados de un motorde búsqueda convencional. KeyCon-cept mejora este proceso efectuandodirectamente la recuperación concep-tual desde el índice.

OntologíasUna ontología es un arreglo de con-ceptos que representa una visión delmundo [Chaffee 2000]; dicho arreglo

puede emplearse para estructurarinformación. Las ontologías se pue-den construir especificando las rela-ciones semánticas entre los términosde un diccionario. Un ejemplo de unaontología de este tipo es Sensus[Knight 94], una taxonomía de másde 70.000 nodos. El sistema OntoSeek[Guarino 99] emplea esta ontologíapara recuperar información desdecatálogos de productos.

Las ontologías también se puedenderivar de colecciones jerárquicasde documentos, tales como Yahoo![YHO 02] y el proyecto Open Direc-tory [ODP 02]. [Labrou 99] reportael uso del clasificador TellTale[Pearce 97] para introducir docu-mentos nuevos en la ontologíaYahoo! en forma automática. Estose logra entrenando el clasificadorcon documentos de cada uno de losconceptos de la ontología, y luegoencontrando el concepto que tengala similitud más grande con el do-cumento nuevo. Aún más, una on-tología se puede emplear para per-mitir a los usuarios navegar por laWeb y hacer búsquedas usando unajerarquía de conceptos personaliza-da. El proyecto Obiwan [Chaffee 00,Zhu 99] logra esto permitiendo quecada usuario defina su propia jerar-quía de conceptos, y haciendo luegola equivalencia de esta ontologíapersonal con una ontología de refe-rencia (Lycos en este caso).

Los autores también pueden incluirinformación ontológica en sus docu-mentos. SHOE (Simple HTML Onto-logy Extensions) [Heflin 2000] es unlenguaje diseñado para este propósi-to, que permite la creación de nue-vas ontologías personalizadas y laextensión de ontologías existentes.


Documentos

de entrenamiento

Indizador tradicional

BD conceptos

ARQUITECTURA DEL SISTEMADurante el proceso de indización,KeyConcept incluye en el índice in-formación acerca de los conceptos conlos que se relaciona cada documento.Para lograr esto, se extendió la es-tructura tradicional de archivo inver-tido del índice para incluir las rela-ciones entre conceptos y documentos.El proceso de recuperación utilizaeste índice extendido y soporta con-sultas que empleen sólo palabras cla-ves, sólo conceptos, o una combina-ción de los dos. El usuario puede se-leccionar la importancia relativa decada criterio (cruce por palabras ocruce por conceptos).

IndizaciónEl proceso de indización se componede dos fases: Entrenamiento del cla-sificador e indización de la colección.Durante el entrenamiento del clasi-ficador se reúne y combina un núme-ro fijo de documentos de muestrapara cada concepto, y los super-docu-mentos resultantes son preprocesa-dos e indexados utilizando el algorit-mo tf * idf. Cada concepto queda en-

Figura 1. Funcionamiento del motor de búsqueda conceptual

tonces representado por el centroidedel conjunto de documentos de entre-namiento para dicha categoría. Du-rante la indización de la colección, seindexan los documentos nuevos usan-do el método vector-espacio paracrear un índice tradicional basado enpalabras claves. Luego, se clasifica eldocumento calculando la similitud desu vector con el centroide de cada con-cepto. Los valores de similitud calcu-lados se almacenan entonces en elíndice de conceptos.

RecuperaciónDurante la recuperación, el usuariointroduce una consulta que puedecontener palabras claves, identifica-dores de concepto, o ambos. En estaversión inicial de KeyConcept elusuario introduce también un núme-ro entre 0 y 1 (llamado factor α) queespecifica la importancia relativa delcruce de conceptos y el cruce de pala-bras claves. Si α es 1, solamente setrabaja con cruce de conceptos; si es0, solamente se considera el cruce depalabras. Cuando α es 0.5, el crucede palabras y el de conceptos contri-


buyen por igual. En un futuro, se es-pera que α posea un valor por omi-sión, de tal modo que el usuario notenga que introducirlo; sin embargose permite ajustarlo en esta versióninicial para propósitos de evaluación.Después de recibir los datos del usua-rio, el motor efectúa la búsqueda yalmacena los resultados del cruce depalabras claves y conceptos en acu-muladores separados. El puntaje fi-nal para cada documento se calculamediante la siguiente fórmula:

Puntaje documento = (α x puntajeconceptual) + ((1-α) x puntaje pala-bras claves)

de 378.000 conceptos. Debido al granvolumen de datos que involucra, elentrenamiento del clasificador hubie-ra sido una tarea larga y difícil si sehubiera empleado el conjunto comple-to de conceptos. Adicionalmente, exis-ten diferencias sutiles entre concep-tos que son obvias para un ser hu-mano, pero podrían ser imposibles dedetectar para un algoritmo de clasi-ficación. Por esa razón se eligió em-plear los conceptos de los tres prime-ros niveles de la jerarquía del OpenDirectory. El conjunto inicial de en-trenamiento constó de 2.991 concep-tos y aproximadamente 125.000 do-cumentos.

Experimentos de entrenamiento delclasificadorPara determinar cuántos documen-tos se requerían para “entrenar” cadaconcepto, se diseñaron tres experi-mentos:

DESCRIPCIÓN DE LOSEXPERIMENTOS Y RESULTADOSSe llevaron a cabo dos series de expe-rimentos para evaluar y afinar el mo-tor de búsqueda conceptual. La metade la primera serie de experimentosfue determinar el tamaño de la colec-ción de documentos que sería usadapara entrenar el clasificador; más es-pecíficamente el número de concep-tos y la cantidad de documentos deentrenamiento por concepto. La se-gunda serie de experimentos fue di-señada para determinar el grado decontribución que debería tener el cru-ce de conceptos en el proceso de recu-peración.

Elección del conjuntode datos de entrenamientoSe eligió usar el proyecto Open Di-rectory [ODP 02] como fuente paralos datos de entrenamiento, porqueesta jerarquía está disponible en laWeb en un formato compacto fácil deprocesar; además de que se está con-virtiendo en un estándar de facto paraeste tipo de experimentos. En abrilde 2002, Open Directory poseía más

Experimento 1:Determinación de una cotasuperior para el número dedocumentos

Se deseaba probar la hipótesis de que,después de un cierto número de docu-mentos de entrenamiento por concep-to, la precisión del clasificador no au-menta, y antes puede disminuir. Eneste experimento se entrenó el clasifi-cador usando los conceptos que teníanal menos setenta documentos asocia-dos (633 de los 2.991 conceptos). Dedichos documentos, dos se reservaronpara pruebas y el resto se usó en elentrenamiento. El clasificador arrojalos diez mejores resultados para cadacaso de prueba: esto permite compu-tar la precisión para coincidencia exac-ta (cuando el concepto correcto deldocumento de prueba aparece de pri-


mero en los resultados del clasificador)y la precisión sobre los dos primeros ylos diez primeros (cuando el conceptocorrecto aparece entre los lugares 2 y10 de la lista).

En este experimento se entrenó cua-tro veces el clasificador, iniciando concuarenta documentos por concepto enla primera corrida y agregando diezdocumentos en cada corrida subsi-guiente. El Gráfico 1 muestra que, concuarenta documentos, el clasificadorposee una precisión de coincidenciaexacta del 48.2%. Para cincuenta do-cumentos se alcanza un pico del50.9%. Con sesenta documentos, laprecisión de coincidencia exacta cae al50.2%; sin embargo el resto de los va-lores de precisión todavía experimen-ta un leve incremento. Finalmente, laprecisión de coincidencia exacta cae al34.2% cuando se usan todos los seten-ta documentos. Esto prueba que nues-

Precisión (%)

90

80

70

60

50

Gráfico 1. Determinación de la cota superior del número de documentospor concepto.

tra hipótesis es verdadera, y que lacota superior para el número de docu-mentos de entrenamiento es 60.

Experimento 2:Determinación de una cotainferior para el número dedocumentos

El propósito de este experimento esdeterminar el número mínimo de do-cumentos por concepto necesariospara entrenar el clasificador. Comomuchos conceptos de la jerarquíaOpen Directory tienen menos de se-senta documentos, se podría incre-mentar el número de conceptos a in-cluir en el índice si se puede obteneruna precisión aceptable usando me-nos documentos de entrenamientopor concepto. Se empleó el mismo pro-cedimiento del experimento anterior,pero en esta ocasión se disminuyó elnúmero de documentos de entrena-miento por concepto y se midió el efec-


Precisión (%)

85

80

75

70

to sobre la precisión. Debe notarseque el número de conceptos involu-crados en este experimento es mayor,pues se usaron todos los conceptosque poseían al menos cincuenta do-cumentos de entrenamiento (941 delos 2.991 conceptos).

En este experimento se entrenó elclasificador seis veces, comenzandocon cincuenta documentos por con-cepto y usando diez menos en cadacorrida subsiguiente, a excepción dela última corrida en la que tan sólose emplearon cinco documentos porconcepto. Como se muestra en elGráfico 2, los valores de precisiónpara 50, 40 y 30 documentos casicoinciden. Al usar veinte documen-tos se observa una disminución enla precisión (comenzando con la pre-cisión calculada sobre los cinco pri-meros resultados), y para diez docu-mentos toda la curva de precisión se

Gráfico 2. Determinación de la cota inferior del número de documentospor concepto.

desplaza hacia abajo. Esto permiteconcluir que la cota inferior para elnúmero de documentos de entrena-miento por concepto es treinta. Des-pués de analizar los datos, se encon-tró que usar más de treinta docu-mentos por concepto no incrementala precisión en forma significativa(valor p de la prueba Χ 2 ≈ 1). En con-clusión, se decidió usar treinta do-cumentos por concepto para entre-nar el clasificador en todos los expe-rimentos subsiguientes. Esto permi-tió usar una base de datos de entre-namiento de 46.920 documentos es-cogidos de los 1.564 conceptos quetenían al menos treinta documentosde muestra. Usando treinta docu-mentos de entrenamiento se lograuna precisión del 51% en coinciden-cias exactas, 77.05% de precisión so-bre los cinco primeros resultados y84% sobre los diez primeros.


Experimento 3:Relación entre número deconceptos y precisión(Escalabilidad)

Este experimento intenta determinarsi la precisión del clasificador depen-de o no del número de conceptos en-tre los cuales debe decidir. Tambiénse evalúa la dependencia de la preci-sión con respecto a un conjunto deconceptos en particular. Para lograresto, se entrena el clasificador consubconjuntos diferentes de los 1.564conceptos que poseen treinta docu-mentos de muestra. Se escogen pri-mero cien conceptos al azar, se entre-na el clasificador con ellos, luego seclasifican los casos de prueba y sedetermina el número de coincidenciasexactas. A continuación se escogenotros cien conceptos, el clasificador seentrena con doscientos conceptos (loscien nuevos más los cien anteriores),y se clasifican los doscientos casos deprueba. El proceso se repite hasta que

Gráfico 3. Relación entre número de conceptos y precisión

% exact matches

55

53

51

49

47

45

43

41

todos los conceptos han sido procesa-dos. Luego, se repite el experimentovarias veces, de suerte que los con-ceptos se escojan en un orden diferen-te. Si la precisión del clasificador esindependiente del número de concep-tos, la precisión debería permanecerconstante a medida que se incremen-ta el número de conceptos. Asimismo,si la precisión del clasificador es in-dependiente del conjunto de concep-tos que se empleó en cada corrida, laprecisión de coincidencias exactas nodebe cambiar entre corridas.

Después de entrenar el clasificadorusando la base de datos de entrena-miento del experimento anterior, secrearon diez secuencias aleatorias deconceptos, se corrió el experimento 3para cada una de ellas y por último sepromediaron los resultados. El Gráfi-co 3 muestra los resultados para lasdiez corridas, y el puntaje promedio enuna línea más oscura. El puntaje pro-


medio de precisión se mantiene aproxi-madamente constante (alrededor de46%), demostrando que la precisión delclasificador no sufre a medida que seincrementa el número de conceptos.Adicionalmente, cuando se empleanúnicamente cien conceptos la precisiónfluctúa entre 38% y 51%; sin embargo,cuando se usan al menos seiscientosconceptos, los valores de precisión semantienen entre 45 y 47%, con lo quese concluye que el conjunto de concep-tos escogido no afecta los resultados,siempre y cuando dicho conjunto seagrande. Esto ilustra la independenciaentre el número de conceptos y la pre-cisión del clasificador.

DiscusiónLos resultados de los experimentosmuestran que el uso de treinta docu-mentos de entrenamiento por concep-to permite lograr un buen balanceentre la cantidad de datos de entre-namiento y la precisión del clasifica-dor. Si se emplean más documentospor concepto, menos conceptos cum-plirían con el requerimiento de can-tidad disponible de datos de entrena-miento, haciendo que la clasificaciónsea demasiado general. Por otro lado,si se usan muy pocos documentos porconcepto, cada concepto se vuelvedemasiado específico y no quedaríarepresentado por un número signifi-cativo de documentos; en consecuen-cia, a medida que el número de con-ceptos crece, las diferencias entreellos se vuelven demasiado sutilescomo para que un clasificador auto-mático las pueda detectar.

tos para estudiar si un motor de bús-queda que combine búsqueda concep-tual y de palabras claves se desem-peña mejor que uno basado única-mente en palabras claves. Para estepropósito se construyó un conjunto dedocumentos de prueba consistente en100.000 documentos de la colecciónWT2g [Hawking 99]. El conjunto deprueba incluye los 2.279 documentosde la colección que tienen juicios derelevancia positivos, y 97.721 docu-mentos seleccionados al azar. Debidoa que el título de cada uno de los cin-cuenta tópicos de la colección WT2gse parece a una consulta típica (de dosa tres palabras) [Zien 01], se empleódicha sección de título como las pala-bras claves a usar en cada consulta.Luego se corrieron los párrafos denarración y descripción (cincuentapalabras en promedio) incluidos concada tópico por el clasificador, y seemplearon los identificadores de con-cepto obtenidos como la entrada con-ceptual para cada consulta.

Debe notarse que también se deter-minaron manualmente los identifica-dores de concepto que mejor se corres-pondían con cada tópico. Sin embar-go, la diferencia entre los resultadosobtenidos usando clasificación auto-mática y manual no es significativa(valor p de la prueba Χ 2 ≈ 1).

Experimento 4:Efecto de α en la precisión de labúsqueda

En este experimento se trató de en-contrar un buen valor para α, el fac-tor que balancea las contribucionesde la búsqueda conceptual y la depalabras claves. Se variaron dos fac-tores en el experimento: (1) el factorα, y (2) el número de identificadoresde concepto correspondientes a cada

Experimentos de precisión en larecuperación de informaciónDespués del entrenamiento del cla-sificador, se diseñaron dos experimen-


tópico que se emplean en la consulta.Luego se calculó la precisión sobrediez primeros resultados y veinte pri-meros resultados, contando los resul-tados relevantes que aparecieron en-tre los primeros diez y veinte resul-tados de la consulta, y se promedió elpuntaje de todas las consultas.

La línea de base para este experimen-to es α=0, es decir, solamente se usarecuperación por palabras claves. Enese caso, la precisión es del 42.8% (so-bre los diez primeros resultados) y33.5% (sobre los veinte primeros re-sultados).

Como se muestra en el Gráfico 4, lamejor precisión sobre diez primeros

Gráfico 4. Efecto del factor α en la precisión calculada sobre los diezprimeros resultados

Precisión

0.5

0.45

0.4

resultados (44.4%) se obtiene cuandose emplean los tres mejores concep-tos para cada consulta, con α = 0.2.Los puntajes de precisión caen abrup-tamente para valores de α mayoresque 0.2, queriendo decir que la recu-peración conceptual por sí sola no essuficiente para obtener una buenaprecisión en las búsquedas, y que laspalabras claves son el factor más im-portante en la identificación de do-cumentos relevantes. La precisióntambién cae ligeramente cuando seusan más de tres conceptos por con-sulta, indicando que los conceptosadicionales introducen ruido en labúsqueda, subiendo el puntaje de do-cumentos no relevantes.


Gráfico 5. Efecto del factor α en la precisión calculada sobre los 20primeros resultados

Precisión

0.4

0.35

0.3

0.25

0.2

0.15

0.1

El Gráfico 5 muestra los resultadosdel experimento, considerando la pre-cisión calculada sobre los veinte pri-meros resultados. La precisión tam-bién alcanza un pico (36.5%) paraα=0.2, cuando se usan los tres mejo-res conceptos para cada consulta.

Experimento 5:Comparación de precisión porconsulta

El propósito de este experimento escomparar la precisión que se obtienecon cada uno de los tópicos de laWT2g cuando se ejecuta la búsquedacon α=0 (solamente palabras claves)y α=0.2 (mejor combinación de con-ceptos y palabras claves). En las bús-quedas combinadas se usaron los tresmejores identificadores de conceptopara cada consulta.

Los resultados de este experimentose muestran en el Gráfico 6. De las

cincuenta consultas de la colección,doce experimentaron un incrementode precisión cuando se empleó el cru-ce combinado de conceptos y palabrasclaves, una experimentó una dismi-nución de puntaje, y no hubo varia-ción en 37. A pesar de ser pequeña, ladiferencia entre recuperación de in-formación basada únicamente en pa-labras claves y la basada en concep-tos y palabras claves es significativa(valor p de la prueba Χ 2 ≈ 10-6). Paralos consultas en las que no se encon-traron documentos relevantes nue-vos, el uso de la recuperación combi-nada no tuvo efectos significativos enel ordenamiento de los resultados.

DiscusiónSe encontró que un valor de 0.2 parael factor α incrementa la precisión delas búsquedas propuestas. Esto indi-ca que el cruce de palabras claves es


Gráfico 6. Comparación por consulta de precisión sobre los veinteprimeros resultados

Precisión (%)

100

90

80

70

60

50

mucho más importante que el crucede conceptos, pero la precisión de labúsqueda se puede elevar en formasignificativa si se incluye el cruce con-ceptual. Los conceptos para una con-sulta dada pueden determinarse enforma automática usando un textodescriptivo asociado, y el desempeñoes el mejor cuando se emplean en laconsulta los tres mejores conceptosrelacionados con la misma. El hechode que se necesiten varios conceptosrelacionados con la consulta en lugarde uno solo (el mejor) se desprendedel experimento 2: El concepto correc-to para cierto documento solamenteaparece en el primer lugar el 50% delas veces, pero aparece entre los tresprimeros el 70% de las veces.

Creemos que la razón para el incre-mento más bien modesto de precisiónregistrado en nuestros experimentosestá en las características de las con-

sultas de la colección WT2g. La defi-nición de relevancia para dichas con-sultas es muy restrictiva. Un docu-mento que sea válido tanto por pala-bras claves como por conceptos pue-de ser clasificado como irrelevantepor algún detalle semántico o de con-tenido que puede resultar obvio paraun evaluador humano pero indetec-table para un clasificador automáti-co. Esto ocasiona que el número dedocumentos relevantes por consultasea muy pequeño (40 en promedio) yque muchos documentos que son deltema sean considerados irrelevantes.

CONCLUSIONESY TRABAJO FUTUROEste artículo presentó la idea de unmotor de búsqueda conceptual, quealmacena en su índice informaciónacerca de los conceptos con los que serelaciona cada documento. Cuando se


efectúa una consulta, se usa la infor-mación conceptual, además de laspalabras claves, con el fin de propor-cionar al usuario resultados más re-levantes.

Se mostró que es posible mejorar laprecisión de las búsquedas cuando seemplea información conceptual encombinación con las palabras claves.Se empleó un subconjunto de la je-rarquía Open Directory para cons-truir la base de datos de conceptos, yse determinó que era adecuado usar1.564 conceptos del nivel 3 de la je-rarquía, con treinta documentos deentrenamiento por cada concepto. Enlos experimentos de recuperación seobtuvo una precisión calculada sobrelos veinte primeros resultados del36.5%, que resultó ser un incremen-to significativo con respecto a la bús-queda por palabras claves únicamen-te. Nuestra intención es efectuar ex-perimentos usando juicios de relevan-cia más amplios, para ver si es posi-ble un incremento mayor en precisióny capacidad de recuerdo.

Actualmente, los conceptos relaciona-dos con cada consulta deben ser in-troducidos manualmente o corriendoa través del clasificador un texto cor-to relacionado con la consulta. Lamayoría de los usuarios ven esto comouna tarea pesada y que consumemucho tiempo; de ahí que determi-nar los conceptos de la consulta demanera completamente automáticasería muy beneficioso. En un futurocercano se planea hallar los concep-tos de la consulta usando tecnologíade perfiles de usuario. El motor com-pararía la consulta con un perfil deusuario y extraería de dicho perfil losconceptos que más relacionados es-tén con la consulta. De esta manera,

los usuarios recibirán resultados másrelacionados con sus intereses y acti-vidades actuales.

REFERENCIAS[Chaffee 2000] Jason Chaffee, Susan

Gauch. Personal Ontologies For WebNavigation. En Proceedings of the9th International Conference On In-formation Knowledge Management(CIKM), 2000, pp. 227-234.

[Chekuri 97] Chandra Chekuri, MichaelH. Goldwasser, Prabhakar Ragha-van, Eli Upfal. Web Search UsingAutomatic Classification. En Procee-dings of the 6th International WWWConference. Santa Clara (CA), USA,1997. http://www.scope.gmd.de/info/www6/posters/725/web_search.html

[Guarino 99] N. Guarino, C. Masolo, andG. Vetere. OntoSeek: Content-BasedAccess to the Web. IEEE IntelligentSystems, 14(3), Mayo 1999, pp. 70-80.

[Hawking 99] David Hawking, Ellen Vo-orhees, Nick Craswell, y Peter Bai-ley. Overview of the TREC8 WebTrack. En Eighth Text RetrievalConference (TREC-7), Noviembre1999. http://citeseer.nj.nec.com/arti-cle/hawking99overview.html

[Heflin 2000] Jeff Heflin, James Hendler.Dynamic Ontologies on the Web.En Proceedings of 17th National Con-ference on Artificial Intelli-gence (AAAI), 2000. http://www.cs.umd.edu/projects/plus/SHOE/pubs/aaai2000.pdf

[Knight 94] K. Knight y S.K. Luk. Buil-ding a Large-Scale Knowledge Basefor Machine Translation. En Procee-dings of the 12th National Conferen-ce on Artificial Intelligence (AAAI),1994, volumen 1, pp. 773-778.


[Krovetz 92] Robert Krovetz y Bruce W.Croft. Lexical Ambiguity and Infor-mation Retrieval. ACM Transactio-ns on Information Systems, 10(2),Abril 1992, pp. 115-141.

[Labrou 99] Yannis Labrou, Tim Finin.Yahoo! As An Ontology – UsingYahoo! Categories To Describe Docu-ments. En Proceedings of the 8th In-ternational Conference On Informa-tion Knowledge Management(CIKM), 1999, pp. 180-187.

[Matsuda 99] Katsushi Matsuda, Toshika-zu Fukushima. Task-Oriented WorldWide Web Retrieval By DocumentType Classification. En Proceedingsof the 8th International ConferenceOn Information Knowledge Manage-ment (CIKM), 1999, pp. 109-113.

[ODP 02] Open Directory Project. http://dmoz.org

[Pazzani 96] Michael Pazzani, Jack Mu-ramatsu, Daniel Billsus. Syskill &Webert: Identifying Interesting WebSites. En Proceedings of the 13th Na-tional Conference On Artificial In-telligence, 1996, pp. 54-61.

[Pearce 97] Claudia Pearce, Ethan Miller.The TellTale dynamic hypertext en-vironment: Approaches to scalabili-ty. En Advances in Intelligent Hy-pertext, Lecture Notes in ComputerScience. Springer-Verlag, 1997.

[Pretschner 99] Alexander Pretschner,Susan Gauch. Ontology Based Per-sonalized Search. En Proceedings ofthe 11th IEEE International Confe-rence on Tools with Artificial Inte-

lligence (ICTAI), Noviembre 1999,pp. 391-398.

[Ruiz 99] Miguel Ruiz, Padmini Sriniva-san. Hierarchical Neural NetworksFor Text Categorization. En Procee-dings of the 22nd Annual Internatio-nal ACM SIGIR Conference on Re-search and Development in Informa-tion Retrieval, Agosto 1999, pp. 281-282.

[SES 02] Search Engine Showdown:Size statistics. http://www.searchengineshowdown.com/stats/sizeest.shtml

[Yang 99] Yiming Yang, Xin Liu. A Re-Examination Of Text CategorizationMethods. En Proceedings of the 22nd

Annual International ACM SIGIRConference on Research and Deve-lopment in Information Retrieval,Agosto 1999, pp. 42-49.

[YHO 02] Yahoo! http://www.yahoo.com

[Zhu 99] Xiaolan Zhu, Susan Gauch, LutzGerhard, Nicholas Kral, AlexanderPretschner. Ontology-Based WebSite Mapping For Information Ex-ploration. En Proceedings of the 8th

International Conference On Infor-mation Knowledge Management(CIKM), 1999, pp. 188-194.

[Zien 01] Jason Zien, Jörg Meyer, JohnTomlin, Joy Liu. Web Query Charac-teristics And Their Implications OnSearch Engines. En Proceedings ofthe 10th International WWW Con-ference. Hong Kong, China, 2001.http://www10.org.hk/cdrom/posters/1077.pdf


CURRÍCULOS

Juan Manuel Madrid Molina es inge-niero de sistemas de la Universi-dad Icesi (1995), especialista en ge-rencia de informática con concen-tración en redes y comunicacionesde la misma Universidad (1999) ycandidato a doctor en Ciencias dela Computación de la Universidadde Kansas, con la disertación "As-pectos temporales de perfiles parabúsqueda en la Web". Ha estadovinculado laboralmente con la uni-versidad Icesi desde 1994, y des-empeñó hasta 1999 funciones desoporte técnico a sistemas, diseño,puesta en marcha y administra-ción de la red institucional. En laactualidad es profesor de tiempocompleto del Departamento deRedes y Comunicaciones y direc-

tor del programa de Ingeniería Te-lemática.

Susan Gauch recibió títulos de pregra-do y máster en Ciencias de la Com-putación en Queen's University(Ontario, Canada) y es doctora enCiencias de la Computación de laUniversidad de North Carolina-Chapel Hill (1990). Actualmentetrabaja como profesora-investiga-dora de tiempo completo en el de-partamento de Ciencias de la Com-putación de la Universidad deKansas. Su investigación está en-focada hacia el desarrollo de agen-tes inteligentes para búsqueda yuso de información. Ha publicadouna gran cantidad de artículos so-bre el tema en revistas especiali-zadas y congresos.


RESUMENEn los últimos años se han llevado acabo una gran cantidad de investiga-ciones en el área de arquitectura desoftware, buscando principalmenteuna forma de representación de unsistema que supere la informalidadde las líneas y cajas pero que a la vezsirva de medio de comunicación conlos diferentes interesados en el pro-yecto, es decir, que no sea demasiadocomplejo. El desarrollo de lenguajesde descripción de Arquitecturas da alos ingenieros de sistemas una nue-va herramienta para la acertada re-presentación de la arquitectura de unsistema; sin embargo, los lenguajesdesarrollados actualmente por lo ge-neral son muy complejos o solo seadaptan a un tipo particular de sis-temas.

Representación de la arquitecturade software usando UML

Sandra Victoria Hurtado GilUniversidad Icesi-I2T

[email protected]

En este artículo se presenta una for-ma de representación de la arquitec-tura de software basada en UML,aprovechando las ventajas de estelenguaje de modelamiento e incluyen-do varias estructuras que facilitan larepresentación de amplia variedad desistemas.

PALABRAS CLAVESArquitectura de software, estructurasarquitecturales, Lenguaje Unificadode Modelamiento (UML), Lenguajesde descripción de arquitectura.

Clasificación: B

ABSTRACTA significant amount of research hasbeen conducted in the Software Ar-chitecture field in the last few years.The focus of many of these studies is


to find a representation system ableto go beyond the informality of thetraditional “box-and-line” diagram,but keeping a low complexity level,so it can be used as a communicationtool between all the software projectstakeholders.

Computer systems engineers nowmay use Architecture DescriptionLanguages as a valuable tool for amore accurate representation of thesystem’s architecture. However, mostof these languages are very complexor purpose-specific.

This article presents an UML-basedscheme for software architecture re-presentations. This novel scheme be-nefits from all the advantages ofUML, and includes several structu-res that enable the representation ofan ample variety of systems.

KEYWORDSSoftware architecture, architecturalstructures, unified modeling langua-ge (UML), architecture descriptionlanguages.


INTRODUCCIÓNUno de los desarrollos más importan-tes dentro de la construcción del soft-ware ha sido el desarrollo de la ar-quitectura de software, que permiterepresentar la estructura de un sis-tema a un nivel mayor que el dadopor la programación o incluso el di-seño [Boa95], [SG96].

Para representar adecuadamente laarquitectura de un sistema es nece-sario contar con varios diagramas ovistas [BCK98]. Dada la cantidad decaracterísticas y de elementos quetiene un sistema de software no esposible incluirlos todos en un solodiagrama y que sirva, además, paratodas las personas que participan enel desarrollo. Cada una de estas vis-tas es una estructura de la arquitec-tura del sistema, que muestran unaparte del sistema como un conjuntode componentes, conectores y restric-ciones sobre sus tipos y relaciones.Además, cada estructura puede rela-cionarse con las demás para comple-mentar la visión integral del sistema.

La arquitectura, conformada por di-ferentes visiones del sistema, consti-tuye un modelo de cómo está estruc-turado dicho sistema, sirviendo decomunicación entre las personas in-volucradas en el desarrollo y ayudan-do a realizar diversos análisis queorienten el proceso de toma de deci-siones.

Para que la arquitectura se convier-ta en una herramienta útil dentro deldesarrollo y mantenimiento de lossistemas de software es necesario quese cuente con una manera precisa derepresentarla.

Las herramientas que se han elabo-rado para representar una arquitec-

tura de software son los Lenguajes deDefinición de Arquitecturas o ADL(Architecture Description Language).Sin embargo, los lenguajes desarro-llados hasta el momento presentandiferentes problemas para su utiliza-ción en una empresa, como:

– Requieren una extensa capacita-ción.

– No son amigables para presentarla arquitectura a personas ajenasa la construcción del software.

– No tienen herramientas ni meto-dologías de apoyo.

– Algunos se encuentran especiali-zados solo en un tipo particularde sistemas.

– Sólo tienen en cuenta una solaestructura del sistema.

Las desventajas que se presentan enestos lenguajes pueden ser superadassi se utiliza un lenguaje de modela-miento que sea conocido en la indus-tria y que además esté apoyado porherramientas y metodologías de de-sarrollo, este lenguaje de modela-miento es UML, que se está convir-tiendo en una notación estándar dehecho en las empresas.

UML permite que se represente demanera semi-formal la estructurageneral del sistema, con la ventaja deque este mismo lenguaje puede serusado en todas las etapas de desarro-llo del sistema y su representacióngráfica puede ser usada para comu-nicarse con los usuarios.

En la siguiente sección se describe demanera general el lenguaje de mode-lamiento UML y los mecanismos quepresenta para su extensión. La sec-ción tres presenta una propuesta


para representar las estructuras dearquitectura utilizando UML, y en lasección cuatro se muestran trabajosrelacionados. Por último se plantea-rán las conclusiones de esta propues-ta de investigación y las posibilida-des de trabajos futuros a partir deella.

Cada uno de estos elementos y rela-ciones tiene una representación grá-fica y puede complementarse su in-formación utilizando lo que se conocecomo especificación. La especificaciónde un elemento o relación generalmen-te no es visible en la representacióngráfica, o sólo lo es parcialmente, ycorresponde a los datos o propiedadesadicionales que completan o detallanla semántica del elemento o relación,y por lo tanto del sistema en general.

Los elementos y relaciones se agru-pan en diagramas que representandiferentes aspectos del sistema. Losdiagramas de UML son:

UML

GeneralidadesUML es un lenguaje gráfico de mo-delamiento que usa conceptos deorientación por objetos. Este lengua-je tiene una sintaxis y una semánti-ca bien definidas, sirviendo ademáspara todas las etapas de desarrollo[RMR98], [BRJ99].

En UML se utilizan para el modela-miento de un sistema diferentes ele-mentos y relaciones, que tienen unasemántica y sintaxis definidas. Estoselementos se agrupan en diagramaspreestablecidos que corresponden adiferentes proyecciones del sistema.

Los elementos básicos de UML, aque-llos que representan principalmentelas partes estáticas del sistema, son:

– Clases

– Casos de uso

– Componentes

– Nodos

– Paquetes

Las relaciones que se utilizan paraestablecer conexiones entre los ele-mentos son:

– Dependencia

– Asociación

– Generalización

– Realización

– Diagrama de clases: Presenta lasclases, junto con sus atributos,operaciones, interfaces y relacio-nes. También presenta el agrupa-miento de clases en paquetes y lasrelaciones entre ellos.

– Diagrama de objetos: Muestra ins-tancias de clases (objetos) con va-lores en sus atributos y relaciones.

– Diagrama de casos de uso: Losescenarios de uso del sistema, in-cluyendo los roles de los usuarios.

– Diagramas de interacción: Com-prende los diagramas de secuen-cia y de colaboración. Presenta ob-jetos y relaciones entre ellos des-de el punto de vista dinámico.

– Diagrama de estado: Representalos posibles estados, eventos ytransiciones entre las clases uobjetos.

– Diagrama de componentes: Orga-nización y dependencia entre com-ponentes físicos.

– Diagrama físico (deployment): Ladistribución y comunicación de los


componentes en los dispositivosde hardware.

La gran ventaja de UML es el he-cho de que poco a poco se ha venidoadoptando en diferentes medios em-presariales y académicos como ellenguaje “estándar” para el análi-sis y diseño de los sistemas de soft-ware. Gracias a la posibilidad deextender el UML y a la construcciónde herramientas y metodologías queapoyan este lenguaje se ha conver-tido en el estándar de facto en laactualidad para el modelamiento delos sistemas.

Mecanismos de extensiónUML tiene principalmente tres me-canismos de extensión que permitenconstruir nuevos elementos o modifi-car la semántica de los ya existentes,para hacer más precisa la represen-tación del sistema. Estos mecanismosson:

1. Valores Adicionados (taggedvalues): Mediante estos valores esposible adicionarle nuevas propie-dades o atributos a los elementosdel modelo de UML.

2. Restricciones (constraints): Lasrestricciones permiten adicionarnueva semántica o modificar laexistente.

3. Estereotipos: Los estereotipospermiten crear nuevos elementosen el modelo basados en otros yaexistentes. Cada nuevo estereoti-po puede reunir propiedades (ta-gged values) y restricciones par-ticulares.

A través de estas extensiones es po-sible enriquecer el modelo de UMLpara representar adecuadamente losdiferentes aspectos del sistema.

Por ejemplo, si se desea mostrar unnuevo elemento en el diagrama decomponentes que represente a un sis-tema externo (como una librería, unprograma servidor, etc.) puede crear-se un estereotipo basado en el ele-mento componente. Este estereotipopuede tener una representación grá-fica diferente a la de los componen-tes para que sus elementos sean iden-tificados más fácilmente en el diagra-ma. Además pueden adicionarse alestereotipo otras propiedades que notenga un componente, como el nom-bre del responsable de dicho sistema.

En la Figura 1 se muestra un ejem-plo de un diagrama de componentesque incluye un elemento con el nue-vo estereotipo externo. En el diagra-ma aparecen dos componentes (A yB) y un sistema externo (Ext). En estecaso el estereotipo tiene una repre-sentación gráfica que lo diferencia delos componentes, pero también pue-de tener el mismo icono de los com-ponentes y llevar el nombre del este-reotipo para diferenciarlo.

Figura 1. Diagrama de componen-tes adicionando un ele-mento con el estereotipoexterno

A B

ExtExt


ESTRUCTURASDE ARQUITECTURA EN UMLLa primera fase del proyecto es laidentificación de los componentes queparticipan en la descripción de la ar-quitectura de un sistema, y luego susrelaciones en las diferentes estructu-ras. Para cada componente y conec-tor se determinan los elementos deUML que los representan, con su sin-taxis y semántica. Algunos compo-nentes o estructuras no tendrán unarepresentación directa y en este casose utilizarán los mecanismos de ex-tensión que provee UML, como este-reotipos o restricciones.

Como parte integral de cada estruc-tura se deben incluir restriccionesadicionales que determinan las rela-ciones y los tipos de componentes yconectores que pueden aparecer endicha estructura.

Por último en el proyecto se presen-tan las relaciones existentes entre lasdiferentes estructuras y la manera deverificar dichas relaciones, lo queayudará a la persona que modela laarquitectura del sistema a validar laconsistencia de esta última.

COMPONENTES

1. Casos de uso (componentesconceptuales)

Un caso de uso representa un reque-rimiento funcional del sistema o unproceso del negocio que se implemen-ta en el sistema de software.

Representación:Se usa el mismo elemento Caso deUso de UML

2. ActoresUn actor es una persona, sistema odispositivo que interactúa con el sis-tema, iniciando, recibiendo los resul-tados o participando en alguna de lasacciones de un caso de uso. Por lo ge-neral representa un rol, por ejemplo:jefe de contabilidad, profesor, etc.

Representación:Se usa el elemento Actor de UML.

Nombre

Nombre

3. MódulosUn módulo es una división conceptualdel sistema que puede ser visto comouna agrupación de funciones que ten-gan alguna relación entre ellas y, porlo tanto, puede presentar un serviciocompleto al exterior una vez se hadesarrollado.

Representación:Un modulo se representa con el ele-mento Paquete de UML.

Nom.

4. ClasesUna clase es la representación abs-tracta de un conjunto de objetos oartefactos que debe modelar el siste-ma. Cada clase incluye las caracte-rísticas y el comportamiento de losobjetos que representa. Una clasepuede ser de tipo interfaz (interactúacon el exterior), control (realiza ope-raciones y controla otras clases) uentidad (hace persistentes los datos).


Representación:Es el mismo elemento Clase de UML

7. Herramientas de softwareSistemas o programas que contribu-yen al adecuado funcionamiento delsistema. Por ejemplo, el sistema ope-rativo, un programa navegador de In-ternet, la máquina virtual de java, etc.

Representación:Se crea el estereotipo Herram, basa-do en el elemento componente deUML.5. Unidades de Software

Conjunto de funciones (en programaso procedimientos) que realizan lasacciones del sistema y que se imple-mentan en archivos físicos. Las uni-dades de software tienen asociado untipo (valor adicionado), que puede ser:filtro, procedimental, objetos, reposi-torio de datos activo u otro.

Representación:

Se usa el elemento Componente deUML.

Nom.

6. Sistemas externosUn sistema externo representa unsistema de la organización que inte-ractúa con el sistema que se está de-sarrollando. Por ejemplo, el sistemade contabilidad (si se está desarro-llando el de recursos humanos).

Representación:Se creará un estereotipo para repre-sentar a este componente. El estereo-tipo, llamado Externo, está basado enel elemento componente de UML.

Nom.

<<ext.>>

Nom.

<<herram>>

Nom.

8. ProcesadorEste componente representa un com-putador (procesador y memoria) don-de se localizan programas o datos ydonde, por lo general, se corren di-chos programas. Este procesador pue-de tener roles como servidor, cliente,terminal, etc. Además, puede estable-cerse su ubicación física (ciudad oárea de la organización) para comple-mentar la información de este com-ponente.

Representación:Se usa el elemento Nodo de UML.

Nom.

9. DispositivoEl dispositivo es un componente o ele-mento de hardware que presenta unainteracción con el sistema. Por ejem-plo, un medidor de presión, un ter-minal de computadores o un módem.

Representación:Se crea un estereotipo Dispos basadoen elemento nodo de UML.


EstructurasPara el proyecto de investigación seha desarrollado la forma de represen-tación de ocho estructuras. Para cadauna se identifican los componentes,los conectores y las restricciones quedeben cumplirse. A continuación, amanera de ejemplo, se presentan dosestructuras, la estructura funcionaly la estructura de llamados.

1. Estructura funcionalEsta estructura representa las fun-ciones que ofrece el sistema a losusuarios finales, a otros sistemas odispositivos, es decir, lo que represen-ta el sistema para los que interactúancon él. Puede verse esta estructuracomo la visión conceptual del siste-ma, permitiendo determinar los as-pectos del negocio que se desean im-plementar en el sistema.

Esta es una de las estructuras másimportantes en un sistema, ya queayuda a la captura de los requeri-mientos y se convierte en un mediode comunicación útil con los usuarios,permitiendo ver gráficamente las re-laciones de los usuarios con el siste-ma y los procesos del negocio identi-ficados por ellos mismos.

La estructura funcional correspondeal diagrama de casos de uso de UML,pero pueden adicionarse nuevos tiposde conectores o restricciones, quemuestren relaciones de alto nivel en-tre los casos de uso y/o actores.

A. Componentes:

– Casos de uso

– Actores

B. Conectores:

Generalización (herencia): Indica queun componente hereda el comporta-miento y atributos del otro.

<<dispos>>

Nom.

– Participación: Permite relacio-nar a los actores con los casosde uso, indicando así que se pre-senta algún tipo de interacciónentre el actor y el sistema a tra-vés del caso de uso.

tipo participación

– Inclusión: Representa que lasacciones del caso de uso que re-cibe la relación se adicionan alas acciones del caso de uso quela inicia.

<<include>>

– Inclusión condicionada: Se adi-cionan las acciones del caso deuso que recibe la relación, perosólo cuando se cumple una con-dición dada.

<<condic>>

condición

C. Restricciones:

– Entre dos casos de uso no puedepresentarse simultáneamente larelación inclusión e inclusiónCondicionada, sólo una de ellas.

– Entre dos actores sólo puedeutilizarse el conector generali-zación.


– El conector de participación sólopuede relacionar un actor y uncaso de uso.

– Un componente (caso de uso oactor) no puede ser simultánea-mente hijo y padre de otro com-ponente usando el conector ge-neralización

– El conector generalización nopuede establecerse entre uncaso de uso y un actor

2. Estructura de llamadosEn esta estructura se presentan losservicios que ofrece y los eventos quegenera cada unidad de software, se-ñalando además las relaciones dedependencia que se presentan entreestas unidades por llamar un servi-cio o escuchar un evento de otra uni-dad.

A. Componentes:

– Unidades de software– Sistemas externos

B. Conectores:

– Servicio: Este conector represen-ta los servicios que ofrece una uni-dad de software o sistema exter-no, y que pueden ser utilizados porotros componentes o por el usua-rio final mediante un llamado ex-plícito.

– Si la generación del evento se rea-liza de manera condicional puedeincluirse la condición en la repre-sentación gráfica

Nombre

– Evento: Representa los eventosque dispara una unidad de soft-ware o sistema externo, y quepueden ser escuchados por otroscomponentes.

<<evento>>Nombre

Cond1

<<evento>>Evento 1

– Uso: Este conector permite quese relacionen los componentescon los conectores servicio yevento, que presentan los otroscomponentes, indicando así lainteracción o dependencia entreellos. El tipo del conector indi-ca la forma por la cual se reali-za la interacción. Este tipo pue-de ser pipe, llamado remoto, lla-mado directo, escucha trigger,escucha evento u otro.

C. Restricciones:

– Todo conector uso debe estar re-lacionado con uno y solo un co-nector servicio o evento.

– Todo sistema externo debe te-ner por lo menos un conector,ya sea servicio, evento o uso.

– Si un sistema externo tiene unconector servicio o evento, ésteno puede encontrarse sin rela-ción con un conector uso de otrocomponente.

– Los conectores servicio o even-to pueden relacionarse con múl-tiples conectores uso.

– Un conector uso, que se relacio-ne con un conector servicio sólopuede ser de tipo pipe, llamadoremoto, llamado directo u otro.


– Un conector que se relacionacon un conector evento sólo pue-de ser de tipo escucha trigger,escucha evento u otro.

3. Otras estructurasLas otras estructuras identificadaspara representar la arquitectura deun sistema son:

– Estructura modular: Presentauna división del sistema en mó-dulos más pequeños o subsiste-mas.

– Estructura de uso: Permite mos-trar las relaciones de dependen-cia que se presentan entre loscomponentes del sistema.

– Estructura de clases: Esta estruc-tura es similar al diagrama declases presentado en UML, y re-presenta el modelo lógico de losdatos necesarios en el sistema.

– Estructura de flujo de datos:Modela el intercambio de datose información que relaciona losdiferentes componentes de soft-ware.

– Estructura de sincronización: Co-rresponde a las relaciones de sin-cronización y de concurrencia quese dan entre los componentes, in-dicando las restricciones que sonnecesarias para el correcto fun-cionamiento del sistema.

– Estructura física: Permite mo-delar la distribución de los com-ponentes del sistema en los di-ferentes dispositivos físicos o dehardware de que se dispone.

estructuras, lo que permite que lasdiversas visiones que se tienen delsistema se complementen adecuada-mente.

Relaciones entre estructurasUna parte fundamental de la arqui-tectura de software es la relación en-tre los diferentes componentes de las

Formado por

Compuesto por

SISTEMA

Módulos

Casos deuso

Participa en larealización de

Clases

Unidadesde Software

Está identificada dentro de

Procesador

Ubicado en

<< >>

Ubicado en

Implementa

Implementa

D spos t vos

Interactúa con

Participa en larealización de

Interactúa con

<< >>

Sistemas Externos –Herramientas deSoftware

Figura 2. Relaciones entre los com-ponentes de la arquitectu-ra de software

En la Figura 2 se resumen las prin-cipales relaciones entre los compo-nentes de la arquitectura del siste-ma. Además de estas relaciones, lasestructuras presentan restriccionesentre sí que permiten integrar toda

Dispositivos


la visión del sistema. Ejemplos deestas restricciones son:

– Todo caso de uso debe ser im-plementado en un módulo, esdecir, no pueden encontrarsecasos de uso que no se relacio-nen con algún módulo.

– Toda clase debe participar en larealización de por lo menos uncaso de uso.

– Toda relación establecida entreuna unidad de software y uncaso de uso debe correspondera una relación que exista entreun caso de uso y una clase yentre ésta y una unidad de soft-ware.

– Si una clase se identifica con unmódulo debe participar en larealización de por lo menos uncaso de uso que implemente elmódulo.

– ...

sólo se presenten mensajes de errorcuando se encuentren inconsisten-cias.

Por último es importante resaltar quealgunas relaciones entre las estruc-turas pueden servir de base para laelaboración de otras estructuras odiagramas que no corresponden a laarquitectura del sistema, por lo queno se detallan en este proyecto, peroson importantes para su desarrollo.Por ejemplo, puede elaborarse undiagrama de interacción entre lasunidades de software para mostrar endetalle cómo implementan las accio-nes de un caso de uso, pero esto ha-ría parte del diseño detallado del sis-tema.

TRABAJOS RELACIONADOSA medida que el concepto de arqui-tectura de software evolucionaba, di-ferentes grupos empezaron a desarro-llar lenguajes de descripción de ar-quitecturas u otras formas para re-presentar la arquitectura de un sis-tema. De estos desarrollos puedenresaltarse algunos aspectos impor-tantes y su relación con el presentetrabajo.

Algunos trabajos presentan grafos ogramáticas de grafos para represen-tar una arquitectura [Met96]. Estetipo de representación se asemejamucho al tradicional esquema de ca-jas y flechas con el cual se modela la“arquitectura” del sistema, con laventaja de que le adiciona mayor for-malismo. Sin embargo, esta represen-tación no incluye la semántica de losdiferentes componentes ni la relaciónentre las diversas estructuras.

La mayoría de las investigaciones sehan orientado al desarrollo de lengua-jes de definición de arquitecturas, en-

Esta relación entre las diferentescomponentes de las estructuras nosólo permite que se tenga una visiónintegral del sistema sino que se pue-dan realizar comprobaciones relacio-nadas con la completitud del sistema.Por ejemplo, cuando se modelan lasunidades de software cada una deberelacionarse con una o más clases, ysi hay alguna unidad de software queno se relaciona con ninguna clasepuede significar que ha sido omitidoalgún objeto o artefacto en el modelológico de datos.

Las verificaciones pueden realizarsede forma manual por las personas queelaboran las diferentes estructuras dela arquitectura del sistema, pero tam-bién pueden ser asistidas por herra-mientas automáticas, de manera que


tre los cuales se encuentran Unicon,Rapide, C2, Sadl, Wrigh, y otros[Ves93]. Estos lenguajes presentanventajas para representar sistemasespecíficos o para realizar diferentestipos de análisis. Su desventaja es quepor lo general sólo incluyen una es-tructura y su representación textuales muy compleja, lo que hace difícil suutilización en las organizaciones.

Por último la utilización de UML pararepresentar arquitecturas de soft-ware, presentada en [Kru95] y[JBR99], no adiciona realmente unnuevo nivel de abstracción, pues sebasa en agrupar los elementos másimportantes de los diferentes diagra-mas de UML.

CONCLUSIONES Y TRABAJOSFUTUROSPara poder aprovechar los beneficiosque presenta la arquitectura de soft-ware es importante que se involucrecomo una nueva disciplina dentro deldesarrollo de un sistema en las orga-nizaciones. Este objetivo se logra nosólo con el aprendizaje de los nuevosconceptos, sino también con el cono-cimiento y utilización de herramien-tas que apoyen el desarrollo de la ar-quitectura del sistema.

La propuesta que se ha presentadode representar la arquitectura de unsistema utilizando el lenguaje demodelamiento UML apoya la difusiónde los conceptos de la arquitectura desoftware, ya que facilita su apropia-ción en las empresas por estar basa-

do en un lenguaje de modelamientomuy conocido.

Esta propuesta también presenta laventaja de incluir diferentes estruc-turas de la arquitectura que se rela-cionan entre sí, permitiendo que to-das las personas interesadas en elsistema tengan varias visiones delmismo y puedan analizar los compo-nentes y sus relaciones en cada unade ellas.

Para apoyar esta forma de represen-tación pueden desarrollarse herra-mientas que automaticen en parte elproceso de elaboración, verificación yanálisis de la arquitectura. Por ejem-plo, pueden verificarse las restriccio-nes generales establecidas para cadaestructura o para las relaciones en-tre las estructuras.

Para involucrar los estilos de soft-ware en la representación pueden ela-borarse restricciones para los compo-nentes, conectores y estructuras paraque representen a un estilo de arqui-tectura en particular. También esposible realizar análisis posterioresa la arquitectura del sistema, paradeterminar si pertenece a algún esti-lo de software.

Otro trabajo que se puede desarrollara partir de la forma de representa-ción mostrada en esta propuesta esla construcción de metodologías (omodificación de existentes) que inclu-yan la arquitectura del sistema en elproceso de desarrollo.


REFERENCIAS ture Description Languages with aStandard Design Method. 20th In-ternational Conference on SoftwareEngineering, 1998.

[SDK95] Mary Shaw, Robert DeLine,Daniel V. Klein, Theodore L. Ross,David M. Young y Gregory Zelesnik.Abstractions for Software Architec-ture and Tools to Support Them.IEEE Transactions on Software En-gineering, Vol. 21. No. 4, Abril 1995.

[SG96] Mary Shaw y David Garlan. Soft-ware Architecture Perspectives on anEmerging Discipline. Prentice Hall,1996.

[Ves93] S. Vestal. Acursory Overview andComparison of Four ArchitectureDescription Languages. TecnicalReport, Honeywell Tecnology Cen-ter, Febrero 1993.

[BRJ99] Grady Booch, James Rumbaughe Ivar Jacobson. The Unified Mode-ling Language User Guide. RationalSoftware Corporation. Addison-Wes-ley, 1999.

[BCK98] Len Bass, Paul Clements y RickKazman. Software Architecture inPractice. Sei Series In Software Ar-chitectures. Addison Websley, 1998.

[Boa95] Maarten Boasson. The Artistryof Software Architecture. IEEE Soft-ware, Vol. 12, No. 6, November 1995(pp. 13-16).

[GP95] David Garlan, Dewayne E. Perry.Introduction to the Special Issue onSoftware Architecture. IEEE Tran-sactions on Software Engineering,Vol. 21, No. 4, Abril 1995 (pp. 269-274).

[JBR99] Ivar Jacobson, Grady Booch yJames Rumbaugh. The Unified Soft-ware Development Process. RationalSoftware Corporation. Addison-Wes-ley, 1999.

[Kru95] Philippe Kruchten. The “4+1”View Model of Software Architectu-re. IEEE Software, Vol. 12, No. 6,November 1995 (pp. 42-50).

[Met96] Daniel Le Métayer. Software Ar-quitecture Styles as Graph Gram-mars. Irisa/Inria. 1996.

[RMR98] Jason E. Robbins, Nenad Med-vidovic, David F. Redmiles y DavidS. Rosenblum. Integrating Architec-

CURRILUM

Sandra Victoria Hurtado Gil. Ingenie-ra de Sistemas de la UniversidadIcesi. Realizó la maestría de inge-niería de Sistemas y computaciónen la Universidad de los Andes,con concentración en construcciónde software. Trabajó en el grupode desarrollo de Sistemas de laUniversidad Icesi y actualmentees jefe del Departamento de Siste-mas en esta misma institución.


RESUMENEl presente artículo expone una pro-puesta metodológica que contribuyea resolver el problema que deben en-frentar las organizaciones cuandopretenden definir y construir indica-dores efectivos de gestión para elmonitoreo y control de las accionesestratégicas emprendidas en procu-ra de alcanzar sus objetivos.

La propuesta ha sido estructurada apartir de la aplicación del enfoque desistemas, y de los conceptos de con-trol, presentes en la teoría cibernéti-ca. Dentro del modelo propuesto se

Construcción de indicadoresde gestión bajo el enfoque de sistemas

José Hernando Bahamón L.Universidad Icesi

[email protected]

destaca igualmente el concepto defactores claves de éxito, introducidoinicialmente por el doctor RonaldDaniel en 1960 y popularizado porRockart y su equipo de investigaciónen sistemas de información, en elMassachussets Institute of Technolo-gy (MIT), a partir de 1979.

PALABRAS CLAVES:Indicadores de gestión, aplicación delenfoque de sistemas, factores clavesde éxito.

Clasificación: B


ABSTRACTThis article proposes a methodolo-gy to help organizations define anddevelop effective management indi-cators to monitor and control thestrategies they adopt in pursuit oftheir objectives.

The proposed model has a systemsfocus and is based on control con-cepts from cybernetics theory. Themodel also highlights the key fac-

tors of success, initially introduced byDr. Ronald Daniel in 1960 and popu-larized by Rockart and his IT resear-ch team at the Massachusetts Insti-tute of Technology in 1979.

KEYWORDS:Management Indicators, SystemsFocus Applications, Key Factors ofSuccess


INTRODUCCIÓN ciendo que ellos son instrumentos demonitoreo y observación de un siste-ma, construidos a partir de la evalua-ción y relación de variables del siste-ma. La medición de estas variables ysu posterior comparación con los va-lores metas establecidos permite de-terminar el logro del sistema y su ten-dencia de evolución.

A manera de ejemplo podemos recu-rrir a un conjunto de indicadores muyconocidos como son los instrumentosde medición incluidos en el tablero decontrol de un automóvil (ver Gráfica1); en éste, el tacómetro le indica alconductor las revoluciones por minu-to del motor, y mediante una franjaroja establece el límite de seguridadpara el automóvil. A partir de la lec-tura que el conductor realiza en unmomento específico y de su compara-ción con la franja límite, éste puededeterminar si su conducción pone enriesgo el motor de su auto.

Al aplicar el enfoque de sistemas alas organizaciones, podemos estable-cer que la información que tradicio-nalmente han utilizado para contro-

La aplicación del enfoque de sistemasal proceso de modelamiento de un he-cho o fenómeno del mundo, nos per-mite su elaboración como una cons-trucción mental de partes que inte-ractúan para conformar un “todo”, yque adicionalmente cumplen con lacondición de tener claramente defi-nidos un propósito, unos objetivos yun conjunto de mecanismos de con-trol para asegurar el logro de sus ob-jetivos.

Desde este enfoque, la definición delos mecanismos de control se consti-tuye en un elemento clave de esteproceso de modelamiento. Esta defi-nición supone la identificación de unaserie de variables claves o vitales,para las cuales previamente se haestablecido un conjunto de valoresmeta (o valores a alcanzar); este con-junto de variables constituyen los in-dicadores de gestión del sistema bajocontrol.

Podemos entonces aproximarnos auna definición de los indicadores, di-

01

23

4 5 6 7 8

0

0 0 0 0 0 0 0

0 0 0 0

20

40

6080 100

120140

160

180

2001.000 RPM km2/h

C

H

Gráfica 1. Tablero de control de un automóvil


Sistema

Entrada

Proceso 1

Proceso 2

lar su avance hacia el logro de susobjetivos es en realidad un conjuntode indicadores de gestión (signos vi-tales) de este sistema denominadoorganización.

En suma, podemos afirmar que losindicadores son ante todo informa-ción, utilizada por los mecanismos decontrol para monitorear y ajustar lasacciones que un determinado siste-ma, subsistema, o proceso, empren-de para alcanzar el cumplimiento desu misión, sus objetivos y sus metas.

Naturaleza de los indicadoresLos indicadores pueden ser clasifica-dos de acuerdo con el mecanismo decontrol para el cual obtienen informa-ción del sistema. Así los indicadorespueden ser de eficiencia, si se enfo-can en el control de los recursos o lasentradas del sistema; de eficacia, si

se enfocan en el control de los resul-tados del sistema. En la Gráfica 2 sepresenta una esquematización de losindicadores de acuerdo con su natu-raleza.

Los indicadores de eficiencia sonaquellos que evalúan la relación en-tre los recursos y su grado de apro-vechamiento por parte de los proce-sos o actividades del sistema. Ejem-plo: cumplimiento de la programa-ción establecida, nivel de desperdi-cio, etc.

Los indicadores de eficacia son aque-llos que evalúan la relación entre lasalida del sistema y el valor esperado(meta) del sistema. Ejemplo: indica-dores de calidad; de satisfacción, etc.

Los indicadores de efectividad son elresultado del logro de la eficiencia yde la eficacia.

Gráfica 2. Clasificación de los indicadores


A partir de este concepto de control,se estructura la siguiente propuestacomo un conjunto de pasos para elestablecimiento de los indicadores decontrol (gestión) de un sistema.

A. Contar con objetivos y estrategiasUna condición fundamental para elproceso de formulación y construcciónde mecanismos de control en un sis-tema, es poder contar tanto con obje-tivos claros, precisos, cuantificados,como con el conjunto de las activida-des claves que se emplearán para lo-grar los objetivos propuestos. Sin estadefinición no es posible conocer elpunto de llegada, ni las característi-cas del resultado que se espera.

Se entiende por cuantificar un obje-tivo la acción de asociarle patronesque permitan hacerlos verificables.

OJO GRÁFICA...

Metas

Unidad de Control

Entrada

Gráfica 3. Cibernética: Esquema de control

PROPUESTA DE UN ESQUEMAPARA ESTABLECIMIENTODE LOS INDICADORESDE GESTIÓNDE UN SISTEMAEl esquema propuesto se fundamen-ta en la cibernética, cuyo propósito esel estudio de los problemas de la co-municación y del control dentro de lossistemas complejos, para entender yexplicar el comportamiento de un sis-tema (o realidad) como una realiza-ción dinámica. Para la cibernética, elcontrol se concibe como el proceso porel cual un sistema desarrolla sus pro-pósitos y objetivos, en una constanteadaptación con el entorno en dondese encuentra inserto.

El modelo para el proceso de control,propuesto por la cibernética, estáconstituido por un mecanismo de ob-tención de los valores resultantes delsistema en un momento específico;por un mecanismo de verificación delos valores medidos en relación conlas metas establecidas; y por unaunidad que determina las accionescorrectivas sobre el sistema. En laGráfica 3 se esquematiza el modelopropuesto.

B. Identificar factores críticosde éxito

El segundo paso es la identificaciónde los factores claves de éxito (FCE)del sistema.

El concepto factor clave de éxito apa-reció sugerido en la literatura admi-


nistrativa en los inicios de 1960, enel artículo del doctor Ronald Danieltitulado “Management InformationCrisis”, publicado en la revista Har-vard Business Review. A pesar de laimportancia del concepto, este perma-neció relativamente inexplorado has-ta marzo de 1979 cuando el equipode investigación en sistemas de in-formación, del Massachussets Insti-tute of Technology (MIT), lo retomócomo herramienta aplicable a la de-finición de requerimientos de infor-mación de un sistema de informacióngerencial (Rockart, 1979).

A partir de 1960 se han escrito unaserie de definiciones para precisareste concepto; algunas de estas defi-niciones son:

• “Número limitado de áreas en lascuales, los resultados, si son sa-tisfactorios, aseguran un desem-peño competitivo exitoso para laorganización. En estas áreas lascosas deben ir bien para que elnegocio triunfe o en caso contra-rio, el desempeño no satisfará lasexpectativas. Por lo anterior, sonáreas que requieren cuidadosa y

constante atención de la gerencia”(Rockart, 1979).

• “Los factores claves de éxito sonfactores internos o externos a laempresa que deben ser identifica-dos y reconocidos porque soportano amenazan el logro de los objeti-vos de la empresa e incluso suexistencia. Requieren de atenciónespecial para evitar sorpresas des-agradables o la pérdida de opor-tunidades. Pueden ser internos oexternos, positivos o negativos ensu impacto” (Ferguson, 1982).

Partiendo de nuevo del concepto decontrol planteado por la teoría ciber-nética y esquematizado en la Gráfica4, podemos definir los factores clavesde éxito como: el conjunto de condi-ciones y actividades del sistema, su-ficientes y necesarias para asegurarel logro de los objetivos del sistema,y que por lo tanto deben estar bajocontrol.

A pesar de que las definiciones sobrefactores claves son bastante claras,en la mayoría de los casos las perso-nas tienen problemas para identifi-

Gráfica 4. Visión cibernética de los mecanismos de control

OJO GRÁFICA...

Proceso

• Cantidad

• Calidad


car los factores claves del sistema queestán modelando. Para resolver estadificultad podemos recurrir al enfo-que de sistemas, en particular al con-cepto de recursividad, mediante elcual podemos descomponer el siste-ma en el conjunto de las actividadesprimarias que lo conforman. En laGráfica 5 se esquematiza el conceptode la recursividad aplicado en la des-composición del sistema en sus acti-vidades primarias.

Durante este proceso de descomposi-ción del sistema en sus procesos pri-marios, debemos asegurar que cadauno de los procesos identificados cum-ple con todas las características de unproceso primario, para poder catalo-garlo como tal. Estas característicasson:

• Cuentan con una especificaciónprecisa de la salida esperada (entérminos de cantidad, calidad, omarco de tiempo).

• Poseen “algo” que les es propio ylos diferencia de los demás. Es de-

cir, expresan de manera clara elvalor que agregan a las salidas es-peradas del sistema. Para lograrese algo deben utilizar los recur-sos disponibles, consumir parte delos materiales (energía) de entra-da, y contar con un proceso detransformación claro.

Una vez identificados los procesos pri-marios en los cuales se descompone elsistema, debemos verificar las condi-ciones de suficiencia y necesidad, paradescartar del conjunto de actividadesidentificadas las que no son necesa-rias y adicionalmente establecer sifalta alguna. Cumplido este paso, po-demos afirmar que el proceso de veri-ficación constituye uno de los factoresclaves de éxito del sistema.

OJO GRÁFICA...

Entrada

Propósito/Objetivos

Proceso principal

Gráfica 5. Principio de la recursividad

C. Establecer indicadores para cadafactor crítico de éxito

Una vez identificados los factores cla-ves de éxito, se deben establecer paracada uno de ellos los indicadores queservirán como mecanismo de moni-toreo y control.


Para realizar la definición de cadaindicador debemos partir de la iden-tificación del tipo de control que sedesea realizar sobre el factor clave deéxito, de esta manera se establece lanaturaleza del indicador a construir.Una vez definida la naturaleza delindicador, se procede a identificar lasvariables del sistema que serán eva-luadas periódicamente para calcularel indicador, es decir:

• Cuando el factor clave de éxito serefiere a una condición de entra-da, las variables estarán determi-nadas por los atributos de los ele-mentos de entrada que son nece-sarios controlar, tal como se pre-senta en la siguiente ecuación:

tal como se presenta en la siguien-te ecuación:

Indicadorcondición =

Atributo a medir

Valor esperado

• Cuando el factor clave de éxito serefiere a un proceso primario y lanaturaleza del control más apro-piado es de eficacia, las variablesestarán relacionadas con el cum-plimiento de los resultados espe-rados por parte de dicho proceso,

D. Determinar, para cada indicadorel estado, el umbral y el rango degestión

Los indicadores serán mecanismosútiles de control si pueden ser com-parados con valores de referencia es-tablecidos previamente. Estos valo-res de referencia se definen a partirde los objetivos y las condiciones delsistema que se desea monitorear ycontrolar. Los valores típicos de refe-rencia son:

• Estado: Valor inicial o actual deun indicador..

• Umbral: Es el valor del indicadorque se quiere lograr o mantener.

• Rango de gestión: Es el espaciocomprendido entre los valoresmínimo y máximo aceptables, queel indicador puede tomar.

E. Diseñar la mediciónFinalmente, para el cálculo de cadaindicador es necesario determinarlas fuentes de información, la fre-cuencia de la medición de las distin-tas variables, la forma de tabulación,el análisis y la presentación de la in-formación.

Para facilitar la comprensión de losvalores medidos para un indicador serecomienda la utilización de presen-taciones como la que se observa en laGráfica 6.

Indicador deefectividadproceso X:

:

Valor de un atributode salida

del proceso

Valor esperadodel atributo.

Cantidad de recursoo materia primadesperdiciadaIndicador de

eficienciaproceso X Cantidad de recurso

o materia primautilizada

:

• Cuando el factor clave de éxito serefiere a un proceso primario y lanaturaleza del control más apro-piado es de eficiencia, las varia-bles estarán relacionadas con eluso de los recursos por parte delproceso, como se presenta en lasiguiente ecuación:


OJO GRÁFICA...

Valor

Indicador

A manera de ejemplo se presentauna aplicación del esquemapropuestoEn este ejemplo se muestra la elabo-ración de cada paso del esquema pro-puesto para la definición de indica-dores de gestión de un sistema (su-puesto) de contratación de personalen una organización.

• Contar con objetivos y planesAsumimos la siguiente definición depropósito y objetivo para el sistemade contratación de personal.

Propósito: Lograr una contrataciónefectiva del personal requerido por laorganización para cubrir sus vacantes.

Objetivo: Garantizar que la totalidadde las contrataciones del personalrequerido por la organización cumplecon los perfiles establecidos para loscargos solicitados, y que el 90% dedichos procesos se realizarán dentrodel tiempo establecido.

• Identificar los factores claves ocríticos de éxito

De acuerdo con el esquema propues-to de identificación para los factorescríticos de éxito se encontraron lassiguientes condiciones y los siguien-tes procesos primarios.

Condiciones• Solicitudes de contratación de per-

sonal nuevo, con especificacionescompletas y libres de ambigüedad.

• Hojas de vida completas y con elperfil de los aspirantes completa-mente detallado.

Actividades primarias

Gráfica 6. Despliegue de un indicador

Razón denecesidad

Control de costo ytiempo, entregandosólo candidatos quecumplen el perfil ala siguiente activi-dad.

Garantizar el cum-plimiento del perfilsolicitado.

Actividad

i. Búsqueda ypreselección dehojas de vida.

ii. Evaluación yaseguramientoen el cumpli-miento de lasespecificacio-nes, mediantepruebas y en-trevistas.

iii. V i n c u l a c i ó nefectiva de lapersona selec-cionada.

Control de costo ytiempo en el proce-so final de contrata-ción.


En la tabla anterior se presentan lasactividades primarias y la razón porla cual se consideran necesarias.Igualmente, podemos observar quecada una de estas actividades por sísola no es suficiente para alcanzarel objetivo propuesto, por lo tanto,se requiere la combinación de las ac-tividades i, ii y iii, para alcanzar lasuficiencia que garantice el logro delobjetivo propuesto.

En suma, los factores claves de éxitopara el sistema propuesto son:

a. Control en el cumplimiento deespecificaciones completas paracada solicitud recibida.

b. Control en la especificación com-pleta y detallada del perfil en lashojas de vida recibidas.

c. Preselección eficiente de hojas devida.

d. Evaluación y aseguramiento en elcumplimiento de los perfiles soli-citados por parte de los candida-tos seleccionados.

e. Vinculación efectiva.

• Definir indicadores para cadafactor clave de éxito

Para cada factor clave de éxito se de-fine el tipo de indicador de acuerdocon la naturaleza de control másapropiada. Se proponen los siguien-tes indicadores:

F.C.E a.: Corresponde a una condi-ción, por lo tanto, el indicador se cons-truye a partir de los atributos quecontrola:

F.C.E c.: Para este proceso primarioes conveniente evaluar la eficienciadel proceso, por lo tanto el indicadorpropuesto es:

No. de solicitudesaceptadas, completas ylibres de ambigüedad

Ind a =Total de solicitudes

aceptadas

Hojas de vida seleccionadasque cumplen el perfil, y en

el tiempo estándar delproceso

Total de hojas de vidaseleccionadas

Ind. c=

F.C.E d: Para este proceso primarioes conveniente evaluar la eficacia yla eficiencia del proceso, por lo tantolos indicadores propuestos son:

No. de hojas de vida selec-cionadas finalmente que

cumplen todos los requisitos

No. de hojas de vida selec-cionadas finalmente

Ind 1=

No. de procesos deevaluación y entrevistasrealizados en el tiempo

establecido

No. de procesos deevaluación y entrevista

realizados

Ind 2 =

Costo real del procesoCosto presupuestado

Ind 3 =

• Determinar, para cada indicador,el estado, el umbral y el rango degestión

Para los indicadores propuestos en elpaso anterior, y tomando como refe-rencia el objetivo propuesto, se esta-blecen los siguientes valores de um-bral y rango.


EstadoIndicador actual Mínimo Satisfactorio Máximo

Ind. a 95% 100% 100%

Ind. b 95% 100% 100%

Ind. c 95% 100% 100%

Ind. d1 95% 100% 100%

Ind. d2 85% 90% 95%

Ind. d3 85% 90% 95%

CONCLUSIONESA partir de la aplicación del enfoquede sistemas, y de los conceptos de con-trol de la teoría cibernética, se ha lo-grado articular una propuesta meto-dológica que contribuye a resolver elproblema que deben enfrentar las or-ganizaciones cuando pretenden defi-nir y construir indicadores efectivosde gestión para el monitoreo y con-trol de las acciones estratégicas em-prendidas en procura de alcanzar susobjetivos. En suma, este esquemametodológico facilita, ordena y siste-matiza este proceso de formulación yconstrucción de los indicadores degestión.

BIBLIOGRAFÍA• Jesús Mauricio Beltrán Jaramillo.

Indicadores de gestión. 3 R editores.

• Raúl Espejo, Werner Schuhmann,Markus Schwaninger, Ubaldo Bile-llo. Organizational Transformation

and Learning, A Cybernetic Appro-ach to Management. Jhon Wiley &Sons, 1996.

• Angélica María Carmona O. Visióncibernética de los sistemas de con-trol de gestión. Memos de Investiga-ción No. 240. Universidad de losAndes, 1996.

CURRÍCUM José Hernando Bahamón L. Ingenie-

ro Electrónico de la Universidaddel Cauca, especialista en Admi-nistración de la Universidad Icesiy magíster en Dirección Universi-taria de la Universidad de los An-des. Profesor investigador de laUniversidad Icesi. Vinculado a laUniversidad Icesi desde 1988. Hasido Jefe del Departamento Aca-démico de Sistemas (1988 – 1998),Director del Programa de Ingenie-ría de Sistemas (1998 –2000), y enla actualidad es el Director Acadé-mico de la Universidad.


RESUMEN

Los desarrollos tecnológicos y lassiempre cambiantes realidades de laorganización se han convertido enagentes que han obligado a los dise-ñadores a repensar la estructura dela red. El incremento en el númerode usuarios y en el número de aplica-ciones que utilizan la red incrementóel tráfico a volúmenes nunca antessospechados, se hizo entonces nece-sario concebir su estructura como unaestructura jerárquica y modular, condiferentes requerimientos de capaci-

La evolución en la arquitecturade las redes

Ing. Alvaro Pachón D.Departamento de Redes y Comunicaciones

Universidad Icesi-I2T.

dad y desempeño en cada nivel, y obli-gó a entender su diseño como un pro-ceso. En este artículo nos proponemospresentar la evolución que ha tenidola arquitectura de una red para res-ponder a los frecuentes cambios a losque se ven expuestas las organizacio-nes en las que existen.

PALABRAS CLAVESDiseño de redes, interconectividad,conmutación.

Clasificación: B.


ABSTRAC

The ever-changing reality of organi-zations and the developments in te-chnology have forced designers to re-think the structure of corporate net-works. The increase in the numberof users and applications using thenetwork has produced a very sharotraffic increase. Thus, the networkstructure has been redesigned to in-clude the concepts of hierarchy andmodularity, permitting different ca-

pacity and performance at the diffe-rent levels of such hierarchy. Also, thedesign of a network is now seen as awell defined process. This article por-traits the evolution the network ar-chitecture has experienced, in orderto accomodate to the frequent chan-ges in the organization.

KEYWORDS:Network Architecture, Internetwor-king, Switching.


INICIO DE LAS REDESDE COMUNICACIÓNLas redes de comunicación surgierona partir de la necesidad que teníanlos usuarios de compartir un conjun-to diverso de recursos distribuidos,dichas redes se convirtieron en el ve-hículo que permitió el intercambio deinformación. En el caso de las redeslocales (LANs-Local Area Networks)prevalecieron las llamadas redes dedifusión. Una red de difusión esaquella en la cual todas las estacio-nes comparten el canal de comuni-caciones y cuando una de ellas trans-mite, todas las demás la escuchan.Dos formas básicas de interconexióny de acceso al canal de comunicacio-nes pugnaron por obtener la supre-macía; de un lado estaban las redescon topología en bus, y por otro lasredes que tenían topología en anillo.En las redes con topología en bus elacceso al canal se resolvía por con-tienda, ello daba lugar a frecuentescolisiones entre las estaciones quedeseaban transmitir. En las redesque tenían topología en anillo un“testigo” (token) mediaba el accesoal canal, sólo aquella estación quetenía en su poder el testigo podíaenviar información a través del ca-nal. Razones de orden económico hi-

cieron que las redes con topología enbus y con protocolo de acceso al ca-nal basado en contienda prevalecie-ran. Las redes del tipo Ethernet,como fueron conocidas, reinan des-de entonces en el ambiente de lasredes locales, el hecho de pugnar porel canal, de generar colisiones, tieneun efecto directo sobre el desempe-ño de la red ya que resulta imposi-ble predecir con exactitud el momen-to en el cual una estación de la redpueda transmitir. En esta evoluciónhistórica, las redes Ethernet de me-dio compartido se constituyen en elpunto de partida.

Cabe una pregunta: ¿Cómo se imple-mentaron las redes Ethernet de me-dio compartido? Este tipo de redesutilizaban generalmente cablecoaxial delgado, del tipo RG-58, y co-nectores del tipo BNC. La topologíafísica de la red era en bus y se insta-laba en cada estación una tarjeta dered que tenía una interfaz física quela conectaba al canal. No existía nin-gún tipo de jerarquía, la red era com-pletamente plana y la topología físi-ca (la forma como se interconectabanlas estaciones) coincidía con la topo-logía lógica (la forma como las esta-ciones pugnaban por el uso del canal).Ver Figura 1.

ConectoresBNC

CableCoaxial

Estacionesde Red

Figura 1. Red Ethernet de medio compartido basada en cable coaxial.


Las estaciones de red interconectadascon topología en bus dieron lugar alconcepto de dominio de colisión. Undominio de colisión es el conjunto detodas aquellas estaciones que en unmomento dado pugnan o compitenpor el uso del canal. En la medida queel dominio de colisión sea más gran-de, mayor será el número potencialde colisiones, y por consiguiente, me-nor el desempeño de la red. Como severá un poco más adelante, el incre-mento en el número de usuarios quehacen parte de una red corporativatendrá efectos devastadores sobreeste tipo de redes.

Las redes Ethernet de medio compar-tido fueron muy populares en las or-ganizaciones, sin embargo, muy pron-to las dificultades empezaron a sur-gir; la administración y la solución deproblemas se volvieron prácticamen-te inmanejables. Los conectores deltipo BNC obligaban a cortar física-mente el cable coaxial y cuando, poralguna razón, se desconectaba el seg-mento físico de cable del conector, laconexión en bus desaparecía y la co-municación no era posible, existíanentonces N puntos de falla en la red,tantos como estaciones hubiera.

El siguiente paso en la evolución tuvolugar con la aparición de los sistemasde cableado estructurado. La granmayoría de las dificultades asociadascon la administración en las redesEthernet de medio compartido basa-das en cable coaxial se encontrabanen el nivel físico; el cableado estruc-turado resolvió muchas de estas difi-cultades. El cable coaxial fue cambia-do por cable UTP (Unshielded Twis-ted Pair), lo cual significó un retroce-so en términos del canal, dado que lascaracterísticas de transmisión del

cable coaxial son superiores a las ofre-cidas por el cable UTP. Sin embargo,la diferencia fundamental radicó enla utilización de un concentrador(hub), el cual se constituyó en el nú-cleo de una topología física en estre-lla que permitió centralizar muchasde las tareas de administración. Aho-ra, en lugar de ir de estación en esta-ción tratando de localizar una falla,se visitaba el cuarto de cableado y serevisaba el estado de cada uno de lospuertos del concentrador para encon-trar la fuente de las dificultades.

El cableado estructurado produjo uncambio significativo en la estructurade la red. A partir de este momentolas redes tienen una topología puntoa punto, son redes que físicamentetienen una topología en estrella, sinembargo; y gracias al comportamien-to del concentrador, la topología lógi-ca de la red seguía siendo en bus,cuando una estación “habla” (trans-mite sobre el canal), el concentradorse encarga de repetir aquello que “es-cuchó” a cada uno de los puertos res-tantes, es decir, “cuando alguien ha-bla, todos escuchan” (el principio ope-rativo de las redes de difusión en bus).En conclusión, el gran aporte del ca-bleado estructurado fue el permitirtener una topología física diferente ala topología lógica, las redes se confi-guraban en estrella pero seguíansiendo redes de medio compartido,estaban basadas en cable UTP y noexistía ninguna relación jerárquica,la red era completamente plana (VerFigura 2).

Hasta ahora los fenómenos que he-mos analizado son de carácter emi-nentemente tecnológico, específica-mente en el área del hardware. Sinembargo, es tiempo de echar un vis-


Figura 2. Cableado estructurado. Red Ethernet de medio compartidobasada en cable UTP.

Concentrador

CableUTP

Estaciones de Red

tazo a lo que está ocurriendo en esemismo instante en el software y enla organización.

En las empresas, el número de usua-rios conectados a la red crece día adía. Hasta entonces, la tarjeta de redera un periférico que se cotizaba deforma independiente y opcional porparte del proveedor; a partir de esteinstante, los equipos de procesamien-to de datos tienen incorporada la tar-jeta de red en su configuración están-dar porque se supone que serán uti-lizados como estaciones de red. En elsoftware, se incrementa significativa-mente el número de aplicaciones queoperan en ambiente de red; por otraparte, el tamaño de los bloques deinformación que son transmitidos através de la red también se amplía.

Estamos entonces ante una situaciónen la cual se aumenta el número deusuarios de red, el de aplicaciones dered y el tamaño de los bloques de in-formación que transitan a través deella. El resultado: un incremento ex-ponencial en el tráfico que la red debeadministrar y es aquí donde debemospagar el precio de haber optado poruna tecnología de contienda en el usodel canal. El crecimiento desmesura-

do en el volumen de tráfico generadoen el dominio de colisión produjo uncolapso en las redes, a este colapsose lo denominó la “crisis del ancho debanda”: la demanda de ancho de ban-da de los usuarios y sus aplicacionesempezaba a superar la oferta que eracapaz de presentar la red.

Para enfrentar este desafío se presen-taron dos posibles soluciones: la uti-lización de tecnologías de alta veloci-dad y la segmentación. La primeraimplicaba desarrollar o actualizarmecanismos que permitieran enviaruna mayor tasa de bits por segundoen el canal, aquí también se presen-taron dos posibles soluciones: la pri-mera, romper de una vez por todascon las redes Ethernet y repensar elmecanismo de acceso al medio sur-giendo alternativas como FDDI (Fi-ber Distributed Data Interface), unapropuesta de ANSI (American Natio-nal Standards Institute) para contarcon un anillo en fibra óptica a 100Mbps; la otra tecnología representan-te de esta variante fue 100 VGAn-yLAN en la que también se replan-teaba el mecanismo de acceso al me-dio. El optar por este camino hubierasignificado, en todos los casos, haber


cambiado todas las tarjetas de comu-nicación tanto de las estaciones de redcomo de los equipos de interconecti-vidad, aspecto que desde el punto devista económico y práctico resultabainmanejable. La segunda de las solu-ciones proponía incrementar la tasade transmisión de la Ethernet con-vencional; en lugar de contar con uncanal de capacidad nominal de 10Mbps, se dispondría de un canal de100 Mbps, esta alternativa fue la quefinalmente se impuso y parecía queiba a ser la solución definitiva a la“crisis del ancho de banda” a no serpor un aspecto de trascendental im-portancia: este enfoque de solución seconcentraba en atacar los síntomasdel problema pero no en resolver lascausas del mismo, si bien resultabaposible contar con un canal de mayor

capacidad no se hacía nada respectodel tamaño del dominio de colisión,la fuente del problema. De hecho, lamisma realidad se ha encargado demostrarnos que este enfoque no se haconstituido en solución, los desarro-llos de GigabitEthernet y de 10Giga-bitEthernet así lo demuestran.

La otra posible ruta de solución alproblema de la crisis del ancho debanda estaba en la segmentación.Segmentar una red implica descom-poner un dominio de colisión en dos omás, de tal manera que se disminu-ya el número de estaciones de red quepugnan por el uso del canal. Este en-foque de solución realmente enfren-ta las causas del problema y provocóun replanteamiento en el diseño y enla estructura de la red (Ver Figuras3a y 3b).

A B C D

Figura 3a. Un solo dominio de colisión.

Segmento_1 Segmento_2

Dispositivopara hacer

Segmentación

A B C D

Figura 3b. Dos dominios de colisión.


Surge una pregunta: ¿Cómo se pue-de efectuar una segmentación de lared? Inicialmente, la segmentaciónfue realizada utilizando puentes(bridges) o enrutadores (routers). Sinembargo, aunque la orientación de lasolución era la adecuada, su imple-mentación no lo era. Los puentes ylos enrutadores son dispositivos deinterconectividad, por principio filo-sófico de operación, su tarea funda-mental es la de conectar redes, en-tonces, ¿cómo podrían ser empleadospara producir el efecto contrario?

En estos dispositivos se aprovechabael proceso de filtrado, uno de los pro-cesos básicos que gobiernan su ope-ración para efectuar la segmentación.

Detallemos un poco más en qué con-siste el proceso de filtrado (Ver Figu-ra 4): cuando la estación A desea en-viar información a la estación B, re-sulta claro que tanto la estación ori-gen como la estación destino se en-cuentran en el mismo segmento dered, por lo tanto, el dispositivo de in-terconectividad (el enrutador o elpuente) NO retransmiten la informa-ción hacia el otro segmento. Ello per-mite que C pueda estar simultánea-mente hablándole a D, de esta mane-ra, el tamaño de los dominios de coli-sión se hace más pequeño y en pro-medio cada estación tendrá la posibi-lidad de transmitir una mayor canti-dad de información.

Figura 4. Segmentación utilizando un enrutador/puente.

Enrutador Puente


A B C D

¡Transmisión Simultánea!


Switch

Figura 5. Segmentación utilizando un switch. Red de Medio Dedicado.


A B C

Surgió entonces la necesidad de con-tar con un dispositivo que permitie-ra realizar la segmentación de lasredes: El switch, un dispositivo espe-cializado en realizar conmutación detramas. En esencia, un switch no esotra cosa que un bridge multipuertocon hardware especializado en con-mutación. Cada uno de sus puertosda lugar a un dominio de colisión in-dependiente permitiendo, en el me-jor de los casos, que toda la capaci-dad de canal se asigne a una estaciónde red. El switch cambió sustancial-mente el diseño de la red, permitien-do la evolución desde una red de me-dio compartido hasta una red de me-dio dedicado. (Ver Figura No. 5.)Enla Figura anterior (No. 5), la presen-cia del switch da lugar a dos segmen-tos. En el primero, las estaciones A yB constituyen el primer dominio decolisión, y en el segundo, la estaciónC constituye el segundo dominio decolisión. En este caso, la estación Cno pugna con ninguna otra por el ac-ceso al canal. A esta forma de segmen-tación en la cual no existe pugna porel canal se la denominó microsegmen-tación. Con el advenimiento de lamicrosegmentación, la contienda por

el uso del canal resulta inútil, se hacenecesario efectuar una modificaciónsobre el mecanismo de acceso al ca-nal.

Hasta ahora, las redes tenían unaestructura plana, no existía una je-rarquía. El siguiente paso en la evo-lución estuvo determinado por el es-tablecimiento de una jerarquía en losswitches de la red (Ver Figura 6).

La estructura mostrada en la Figu-ra 6 ha sido denominada de “backbo-ne colapsado”, en ella, vale la penaanotar lo siguiente: los enlaces entrelos switches (principal y secundarios)son generalmente enlaces en fibra óp-tica, los enlaces entre los switches se-cundarios y las estaciones de redson generalmente enlaces en cableUTP. Vemos entonces cómo en la redse produce una mixtura de mediosfísicos; por otra parte, se dice que elbackbone colapsó porque el backbo-ne de la red se encuentra ahora dis-tribuido entre los switches y los en-laces de fibra que los comunican.Igualmente, la capacidad de los en-laces no es uniforme como lo era enla etapa evolutiva previa, ahora re-sulta posible tener enlaces de alta


capacidad entre los switches, o entrelos switches y los servidores (Ether-net a 100 Mbps o Fast Ethernet) yenlaces convencionales (Ethernet a10 Mbps) entre los switches y las es-taciones de red que hacen las vecesde clientes.

Tenemos entonces ahora una red je-rárquica, de medio dedicado, con en-laces de alta capacidad en el backbo-ne. En este punto del proceso evolu-tivo, parece ser que todas las posiblesmejoras que se podían realizar en elnivel de enlace de datos han sido efec-tuadas. Para entender el próximopaso en la evolución de la red necesi-tamos entender el concepto de domi-nio de broadcast. Un dominio debroadcast es el conjunto de aquellasestaciones que “escuchan” un mensa-je de broadcast (un mensaje genera-do por una estación en particularpara todas las estaciones que compo-nen la red). El switch, como disposi-tivo de nivel dos, es incapaz de conte-ner el tráfico de broadcast, este tipode tráfico sólo puede ser limitado porun enrutador, precisamente un dis-positivo de nivel tres.

El broadcast excesivo tiene un efectoindeseado sobre el desempeño de lared, en primer lugar porque la con-gestiona (es tráfico que efectivamen-te viaja a través de los diferentes en-laces) y en segundo lugar porque alestar dirigido hacia todas las estacio-nes debe ser procesado por ellas, loque implica un consumo de recursosde cómputo en cada estación. Muchosprotocolos y servicios de red utilizanel broadcast como estrategia de noti-ficación a las demás estaciones de lared, por esta razón un diseñador dered debería tratar de evitar su exce-siva proliferación.

De la misma manera que en un mo-mento dado se hizo necesario hacermás pequeños los dominios de coli-sión, en este punto del proceso evolu-tivo necesitamos limitar el alcance deldominio de broadcast. Sin embargo,como lo dijimos anteriormente, elswitch es incapaz de contener el trá-fico de broadcast, se hace necesarioentonces ascender un nivel e ir des-de el nivel 2 (nivel de enlace de da-tos) hasta el nivel 3 (nivel de red) pararesolver el problema.

Switch Principalde la Jerarquía

Switches Secundariosde la Jerarquía

Estacionesde Red

Figura 6. Estructura jerárquica de una red.


Para contener o limitar el tráfico debroadcast se han propuesto dos op-ciones: Una, la utilización de redesvirtuales (VLANs), y la otra, exten-der el concepto de conmutación al ni-vel tres y utilizar switches de niveltres. Una red virtual (VLAN, VirtualLAN), como su nombre lo sugiere, esun agrupamiento virtual de nodos enun dominio de broadcast, el adminis-trador de la red, utilizando alguna he-rramienta de software, realiza dichoagrupamiento. La gran ventaja deri-vada de la utilización de las VLANses que permiten contener el tráficode broadcast y efectuar una separa-ción de los flujos de tráfico. Para per-mitir la comunicación entre usuariosque pertenecen a diferentes redes vir-tuales es necesario utilizar una fun-ción de nivel tres, a través de un en-rutador o de un switch de nivel tres.

Ya habíamos hecho referencia a lasdificultades, en cuanto a costo y des-empeño, que ofrece un enrutadorcomo alternativa de segmentación.Sin embargo, para salvar estas difi-cultades se propuso una solución: uti-lizar en el ambiente LAN un disposi-tivo especializado en conmutación,implementado completamente enhardware y especializado en el ma-nejo del protocolo IP, a este dispositi-vo se lo conoce como switch de niveltres. El desarrollo del switch de niveltres permite contar en la red de árealocal con un dispositivo de alto des-empeño capaz de realizar las tareasde un enrutador.

Surge una pregunta: ¿Cuáles son lasconsecuencias que se derivan de es-tos nuevos desarrollos? Para respon-der tendríamos que decir que la es-tructura de las redes evoluciona ha-cia una estructura jerárquica en va-

rios niveles y que esta red utiliza di-ferentes niveles de conmutación (con-mutación de nivel dos y conmutaciónde nivel tres) con diferentes velocida-des de acceso al medio (10 Mbps, 100Mbps y 1000 Mbps).

Cisco propone una estructura para lared constituida por tres niveles: Elnivel de acceso, el nivel de distribu-ción y el nivel núcleo (o “core” de lared). Las responsabilidades de cadanivel son complementarias, el esta-blecer una jerarquía para la red per-mite realizar un diseño modular yfuncionalmente especializado. El ni-vel de acceso es el punto de entrada ala red; en este nivel de la jerarquíase conectan las estaciones del usua-rio, generalmente el acceso se reali-za utilizando un hub o un switch denivel dos. Este nivel corresponde conun área funcional de la organizacióny permite la transferencia de infor-mación entre las personas que hacenparte del grupo de trabajo (work-group). El siguiente nivel dentro dela jerarquía corresponde con el nivelde distribución; este nivel se consti-tuye en el punto de acceso a los dife-rentes grupos de trabajo. Por la na-turaleza de su ubicación, es el sitioen donde se imponen las más fuertesrestricciones de acceso y de seguri-dad, en este nivel encontramos fun-ciones típicas de nivel tres. Finalmen-te, se encuentra el nivel de núcleo(“core”) que corresponde con el back-bone de la red; este nivel se encargade transportar grandes volúmenes dedatos a gran velocidad. Para podercumplir con su objetivo es necesarioque no se impongan grandes restric-ciones ni verificaciones al tráfico quecircula a través de este nivel de lajerarquía (Ver Figura 7).


Figura 7. Estructura jerárquica de una red.

Nivel deacceso

Nivel dedistribución

NivelCore

DispositivosInterconectividad

Cabe aquí un nuevo concepto: “Mul-tilayer Switching” como resultado dela evolución de las tecnologías LANy de interconectividad. Los dispositi-vos multinivel combinan caracterís-ticas del nivel dos (nivel de enlace dedatos) y del nivel tres (nivel de red)en switches híbridos que pueden en-rutar paquetes a velocidades de hard-ware. Un switch básico es un puentemultipuertos, como ya se mencionóestos switches fueron desarrollados

para permitir la microsegmentaciónen redes locales. A medida que la tec-nología evolucionó se le adicionaronfunciones de enrutamiento en hard-ware y la posibilidad de analizaraquella información contenida en lospaquetes que pudiera colaborar en elproceso de envío; de esta forma, losswitches multinivel son dispositivosque examinan la información relacio-nada con los niveles 2 hasta el 7 delmodelo OSI (Ver Figura 8).

Figura 8. Dispositivos de interconectividad en los diferentes niveles de laestructura jerárquica de la red.

Nivel deacceso

Nivel dedistribución

NivelCore

Switch deNivel Dos

Switch deNivel Tres

SwitchMultinivel


Estamos entonces en un estado evo-lutivo en el cual la estructura de lared es jerárquica, el dispositivo deinterconectividad que reina es el swit-ch. Teniendo en cuenta la convergen-cia (un componente que le agregacomplejidad al diseño), las redes dehoy, más que redes de datos, son re-des de información: flujos de informa-ción de datos, de voz y de video sur-can las redes modernas, los disposi-tivos de interconectividad deben es-tar en capacidad de reconocerlos ydarles un tratamiento diferenciado,aspecto este al que llamaremos “cali-dad de servicio”. La red debe estar encapacidad de comprometerse a ofre-cer servicios de diferente tipo, depen-diendo del tipo de información que sequiera transferir a través de ella, losrequerimientos de retraso en la trans-ferencia, de variación del mismo (va-rianza) y de capacidad de transmisióndeben ser reconocidos y entendidospor los diferentes dispositivos queconforman la arquitectura de unared.

Toda esta reflexión nos conduce a pen-sar en la necesidad de contar con unametodología que permita abordar conéxito el proceso de diseño de una red.Existen razones de orden económicoy tecnológico que lo justifican; por unaparte, la red se ha convertido en unrecurso estratégico para la organiza-ción, muchos de sus procesos y apli-caciones corren sobre ella; por lo tan-to, se imponen requerimientos de altodesempeño y de alta disponibilidad.

Por otra parte, según lo hemos veni-do mostrando en este artículo, la es-tructura de la red se ha vuelto jerár-quica, funcionalmente modular, contecnologías de conmutación (swit-ching) de diferente nivel y capacidadde transmisión variable en cada unode sus niveles. La red corporativa haadquirido el compromiso de ofrecerservicios diferenciados a aplicacionesy usuarios que necesitan transferirinformación de carácter multimediaa través de ella.

BIBLIOGRAFÍATop Down Network Design. Oppenheimer,

Priscilla. Cisco Press.

Building Cisco Multilayer Switched Net-works. Cisco Press.

Computer Networks. Tanenbaum, An-drew. Prentice Hall.

CURRICULUM

Alvaro Pachón. Ingeniero de Sistemas-Universidad Icesi. Grado con Ho-nores Magna Cum Laude. Especia-lización Redes y Comunicaciones-Universidad del Valle. Cargos Des-empeñados: Director ProgramaIngeniería Telemática. DirectorEspecialización Gerencia de Infor-mática. Cargo Actual: Jefe Depar-tamento Redes y Comunicaciones.Director Especialización Redes YComunicaciones.