XV Congreso Internacional de Informtica en la Educacin

PROPUESTA DE ARQUITECTURA DE SOFTWARE PARA EL

DESARROLLO DE LABORATORIOS VIRTUALES

PROPOSED OF ARCHITECTURE OF SOFTWARE FOR THE DEVELOPMENT
OF VIRTUAL LABORATORIES
Alejandro Merzeau Martnez
1
, Orlay Garca Ducong
2

1 Universidad de las Ciencias Informticas, Cuba,admerzeau@uci.cu,11300
2 Universidad de las Ciencias Informticas, Cuba,odocunge@uci.cu

RESUMEN: Un laboratorio virtual es considerado como una simulacin en computadora de una amplia varie-
dad de situaciones, desde prcticas manipulables hasta visitas guiadas. Los laboratorios virtuales constituyen
una posible extensin de los verdaderos laboratorios. No se considera que el laboratorio virtual vaya a rempl a-
zar a los tradicionales o competir con ellos, sino que constituyen una extensin de los verdaderos, a un costo
asequible. El Centro de Informtica Industrial (CEDIN), de la Universidad de las Ciencias Informticas (UCI),
desarrolla laboratorios virtuales utilizando el motor de render Ogre3D y el frameworkQt. El continuo desarrollo
de software en este centro ha demostrado la importancia de una arquitectura de software funcional y estable,
que permita agilizar los tiempos de desarrollo y aumentar la reutilizacin de componentes. El presente trabajo
tuvo como objetivo definir una propuesta de arquitectura para el desarrollo de laboratorios virtuales. En este se
realiza un anlisis de varios estilos arquitectnicos y patrones de diseo. Se presenta la arquitectura a travs de
las vistas arquitectnicas propuestas por Kruchten. Igualmente, se detallan las restricciones del diseo e impl e-
mentacin que garantizaron la organizacin y estandarizacin del proceso de desarrollo de software. A partir del
mtodo ATAM se efectu la evaluacin a la arquitectura propuesta. Se obtuvo como resultado una arquitectura
funcional basada en componentes y que actualmente se utiliza para el desarrollo de distintos tipos de laborato-
rios virtuales.

Palabras Clave:arquitectura de software, laboratorio virtual, basado en componentes.

ABSTRACT: A virtual lab is considered a computer simulation of a wide variety of situations from manipulative
practices to guided tours.The virtual laboratories constitute a possible extension of the real laboratories. It is not
considered that the virtual laboratory will change to the traditional ones or to compete with them, but rather they
constitute an extension of the real ones, at a reasonable cost. TheIndustrial Computing Center (CEDIN), Univer-
sity of Information Sciences (UCI), develops virtual labs using the Ogre3D rendering engine and the Qt frame-
work.The continuous development of software in this center has shown the importance of software architecture
functional and stable, enabling faster development times and increasing reusability. This study aimed to define
an architectural approach for the development of virtual laboratories. This is an analysis of various architectural
styles and design patterns. We present the architecture through architectural views proposed by Kruchten. It
also details the design and implementation constraints that ensured the organization and standardization of the
software development process. Using the evaluation method ATAM the architecture was put inevalua-
tion.Obtained as a result a component based architecture that is currently used for the development of different
types of virtual laboratories.

KeyWords: software architecture, virtual laboratory, component based.

1. INTRODUCCIN
En la actualidad, el constante desarrollo de las
Tecnologas de la Informacin y las Comunicacio-
nes (TIC) ha permitido intervenir en un sin nmero
de procesos. Con mayor o menor grado las TIC han
logrado cambiar la manera en que estos procesos
ocurren, as como su impacto en la sociedad. Uno
Merzeau, Alejandro.; Garca, Orlay. | PROPUESTA DE ARQUITECTURA DE SOFTWARE PARA EL DESARROLLO DE LABORATORIOS VIRTUALES

XV Congreso Internacional de Informtica en la Educacin

de los procesos que se ha visto beneficiado con el
avance de las TIC es el docente-educativo, al cual
se le han incorporado nuevas herramientas y mto-
dos que tienen como objetivo lograr una mejor
formacin de los estudiantes.
Los laboratorios virtuales son de estas nuevas tec-
nologas, que como los tradicionales, tienen como
objetivo fundamental poner en prctica los conoci-
mientos obtenidos durante las clases. En estos
entornos virtuales no se necesitan de los materiales
y herramientas reales para la realizacin de las
prcticas, por lo que constituyen una opcin viable
ante la falta de recursos u otros impedimentos exis-
tentes.
En la Universidad de las Ciencias Informticas,
especficamente en el Centro de Informtica Indus-
trial (CEDIN) se encuentra el proyecto Laboratorios
Virtuales, que tiene como objetivo desarrollar apli-
caciones de apoyo a la educacin. Este tiene como
experiencia el desarrollo de tres de estas aplicacio-
nes. Despus de la entrega de estos productos y su
satisfactoria aceptacin por parte del cliente, se
contrataron nuevos productos. Bajo el contexto del
desarrollo previo de los productos entregados y los
contratiempos encontrados en todo el ciclo de de-
sarrollo de software se puede afirmar que; la arqui-
tectura de software existente no cumple con las
necesidades del proyecto para iniciar el desarrollo
de estos nuevos productos. Dentro de los principa-
les problemas se puede mencionar la inexistencia
de una estructura lgica, lo que dificulta el entendi-
miento de esta por parte del equipo de desarrollo.
No hay documentacin asociada a la arquitectura,
lo que obstaculiza el proceso de su aprendizaje
para desarrolladores que no estaban involucrados
con el proyecto. Los elementos en la arquitectura
de software estn altamente acoplados y son de-
pendientes entre s. Esto significa que la realizacin
de nuevos requisitos puede tornase una tarea com-
pleja, an ms si los requisitos no guardan relacin
alguna con los existentes. Es notable la desorgani-
zacin en aspectos como la presentacin de datos
al usuario y el cdigo fuente.
La presencia de estos problemas hace de la arqui-
tectura de software existente una propuesta poco
factible a utilizar. El coste asociado a su actualiza-
cin podra ser alto, teniendo en cuenta el poco
nivel de reutilizacin que se puede obtener.
Adems, se necesita incorporar nuevas caracters-
ticas que mejoren y agilicen el proceso de desarro-
llo y dar la posibilidad de brindar soporte de manera
sencilla.
De aqu surge la siguiente interrogante: Cmo
establecer la comunicacin entre los distintos com-
ponentes de un Laboratorio Virtual, como base para
un desarrollo estandarizado? Con el objetivo princi-
pal de desarrollar una arquitectura basada en com-
ponentes con un alto grado de cohesin y bajo
acoplamiento para el desarrollo de distintos tipos de
laboratorios virtuales.

2. CONTENIDO
El trmino Arquitectura de Software (AS) es abor-
dado por un gran nmero de autores. Aunque todos
aportan sus puntos de vistas en funcin de sus
propsitos, en general existen importantes puntos
de contactos que nos facilita la correcta interpreta-
cin del trmino.
Philippe Kruchten refirindose a la AS expresa:
La arquitectura de software, tiene que ver con el
diseo y la implementacin de estructuras de soft-
ware de alto nivel. Es el resultado de ensamblar un
cierto nmero de elementos arquitectnicos de
forma adecuada para satisfacer la mayor funciona-
lidad y requerimientos de desempeo de un siste-
ma, as como requerimientos no funcionales, como
la confiabilidad, escalabilidad, portabilidad, y dispo-
nibilidad. [1]
La IEEE propone: La Arquitectura del Software es
la organizacin fundamental de un sistema formada
por sus componentes, las relaciones entre ellos y el
contexto en el que se implantarn, y los principios
que orientan su diseo y evolucin. [2]
De forma general se puede constatar que los auto-
res se refieren a la AS como un elemento gua para
desarrollar el software, una aproximacin inicial a la
solucin del problema. Por esta razn la AS consti-
tuye los pilares fundamentales donde se apoyar
todo el proceso de desarrollo de un software.
Disponer de una AS estable, bien estructurada y
tolerante a cambios es necesario pues permite:

Comprensin del sistema por los involucra-
dos.
Organizacin en el desarrollo.
Fomentar la reutilizacin.

Actualmente los problemas en el diseo de aplica-
ciones van ms all de los algoritmos y estructuras
de datos de la computacin; el diseo y especifica-
cin de la estructura global del sistema es un nuevo
tipo de problema [3].

2.1 Estilos Arquitectnicos
Los estilos arquitectnicos al igual que su homni-
mo en la arquitectura tradicional representan dife-
rentes tendencias que de alguna manera u otra han
sido reconocidas y utilizada por los especialistas.
Despus de recibir nombres variados tales como:
Merzeau, Alejandro.; Garca, Orlay. | PROPUESTA DE ARQUITECTURA DE SOFTWARE PARA EL DESARROLLO DE LABORATORIOS VIRTUALES

XV Congreso Internacional de Informtica en la Educacin

clases de arquitectura, tipos arquitectnicos,
arquetipos recurrentes, especies, paradigmas
topolgicos entreotras cualificaciones desde hace
ya un tiempo se ha instituido la definicin de esti-
los o alternativamente patrones de arquitectura
aunque esta ltima tiende a confundir con patrones
de diseo.Llamarlas estilos subraya explcitamente
la existencia de una taxonoma de las alternativas
estilsticas; llamarlas patrones, por el contrario,
establece su vinculacin con otros patrones posi-
bles pero de distinta clase: de diseo, de organiza-
cin o proceso, de cdigo, de interfaz de usuario,
de prueba, de anlisis [4].
Los estilos arquitectnicos propuestos para la im-
plementacin de la arquitectura son:

Estilo basado en capas: funciona como una organi-
zacin jerrquica tal que cada capa proporciona
servicios a la capa inmediatamente superior y se
sirve de las prestaciones que le brinda la inmedia-
tamente inferior [5].
Estilo basado en componentes: una arquitectura
basada en componentes describe una aproxima-
cin de ingeniera de software al diseo y desarrollo
de un sistema. Esta arquitectura se enfoca en la
descomposicin del diseo en componentes fun-
cionales o lgicos que expongan interfaces de co-
municacin bien definidas [6].
Se considera que la importancia fundamental de un
estilo radica en proveer al desarrollador, o equipo
de desarrollo, de una forma de identificarse rpida-
mente con el diseo. Esto permite que se puedan
esclarecer algunas dudas respecto al diseo con
solo realizar asociaciones entre este y el estilo ar-
quitectnico propuesto.

2.2 Patrones de Diseo
Cuando se menciona el tema de patrones de dise-
o resulta necesario tomar en cuenta el libro De-
signPatterns: Elements of Reusable ObjectOriented
Software. Este influyente material fue escrito por
Erich Gamma, Richard Helm, Ralph Johnson y
John Vlisides, tambin conocidos como Gang of
Four (GoF). En l se presenta un catlogo de 23
patrones divididos en 3 categoras: creacionales,
estructurales y comportamiento. Los autores pre-
sentan los patrones de diseo a partir de sistemas
reales. Es por esta razn que estos patrones no
son elementos puramente tericos, sino que estn
fundados sobre una fuerte base prctica.
Un patrn de diseo es una descripcin de clases y
objetos que se comunican entre s, adaptados para
resolver un problema general de diseo en un con-
texto particular [7].
Entre los patrones de diseo utilizados se encuen-
tran:
Patrn de diseo Singleton.
Patrn de diseo Adapter.
Patrn de diseo Factory Method.

En la prctica los patrones de diseo son usados
con alguna que otra variacin teniendo en cuenta el
contexto especfico a desarrollar. Incluso muchas
veces estos estn relacionados entre s. Por ejem-
plo: es bastante comn encontrar los patrones
creacionales junto con el patrn Singleton. Y es que
en algunas situaciones conviene tener centralizado
la administracin de determinados tipos de entida-
des para evitar redundancias innecesarias.
El uso de los patrones de diseo no es de carcter
obligatorio y por lo tanto no debe ser forzado. De
hecho, los miembros del mentado GoF destacan
que los patrones no son un destino sino un punto
de partida.

De forma general con el uso de estos patrones se
propone:
Evitar la reiteracin en la bsqueda de
soluciones a problemas ya conocidos y
solucionados anteriormente.
Formalizar un vocabulario comn entre
desarrolladores.
Estandarizar el modo en que se realiza
el diseo.

2.3 Laboratorios Virtuales
El trmino Laboratorio Virtual est estrechamente
vinculado al desarrollo de las TIC. Estos son pro-
ducto del continuo avance tecnolgico y el desarro-
llo de alternativas para mejorar la educacin y en-
seanza en los estudiantes. Una posible definicin
de Laboratorio Virtual es:
Sistema computacional que pretende simular el
ambiente de un laboratorio real; en el cual se visua-
lizan instrumentos y fenmenos a travs de imge-
nes y animaciones, con el propsito de tratar de
recrear la realidad, la cotidianeidad y la interactivi-
dad que se logra en un laboratorio tradicional. Estas
impresiones y emociones, aunque sean ajenas al
proceso de fijacin del conocimiento, forman parte
importante de la experiencia adquirida por el estu-
diante y dicha experiencia juega un papel funda-
mental en el desarrollo y el entendimiento del cono-
cimiento.
En la actualidad existe un creciente inters relacio-
nado con el uso de laboratorios virtuales. Sobre
todo asociado al uso de estos para cursos a distan-
cias, o simplemente como apoyo a de los conteni-
Merzeau, Alejandro.; Garca, Orlay. | PROPUESTA DE ARQUITECTURA DE SOFTWARE PARA EL DESARROLLO DE LABORATORIOS VIRTUALES

XV Congreso Internacional de Informtica en la Educacin

dos impartidos en clases.Se puede apreciar la pre-
sencia de una gran cantidad de laboratorios virtua-
les de manera general. Sin embargo muy pocos
presentan contenidos interactivos utilizando imge-
nes 3d, tambin conocida como realidad virtual.
La AS propuesta provee las herramientas para la
creacin de laboratorios virtuales con este tipo de
caractersticas.

2.4 Materiales y Mtodos
Para el desarrollo de la AS se utiliz RationalUni-
fiedProcess (RUP) como metodologa de desarrollo
de software. Apoyndose principalmente en las
vistas arquitectnicas propuestas en esta metodo-
loga, para describir la AS. Para la gestin de inter-
faces de usuario se escogi el Framework de desa-
rrolloQT. Se selecciona Ogre3d como motor grfico,
utilizado para dibujar las escenas 3d de los labora-
torios virtuales. El lenguaje de implementacinse-
leccionado es C++.

2.5 Propuesta de Solucin
Como primicia de implementacin se trat de con-
vertir los procesos ms comunes a todos los labora-
torios virtuales encomponentes. As, es posible
ensamblar un cierto nmero de estos y lograr la
funcionalidad bsica de un laboratorio virtual a la
vez que se reducen los costos de desarrollo.A partir
del estudio realizado sobre los elementos y necesi-
dades ya mencionadas se propone utilizar como
estilos arquitectnicos los basados en capas y en
componentes. La combinacin de estos estilos
permitir un amplio nivel de reutilizacin y facilidad
de desarrollo.


Figura. 1: Organizacin de las capas

En la figura 1, se muestran las diferentes capas de
la arquitectura propuesta. La capa de presentacin
es la encargada de interactuar con el usuario y
manejar los eventos que ocurran en esta. Igualmen-
te, posibilita la incorporacin de componentes de
interfaz de usuario y permite reutilizar elementos
comunes a otros laboratorios. La capa lgica es la
encargada de ejecutar los requerimientos del nego-
cio que son especficos a cada laboratorio virtual.
Le sigue la capa de soporte que contendr los
componentes de soporte a la lgica de la aplicacin
que por sus caractersticas puedan ser utilizados
por ms deun laboratorio virtual. En la figura 1 se
aprecia tambin una capa transversal, Elementos
Comunes. Esta tiene como objetivo proveer un
conjunto de funciones que pueden ser accesibles
desde cualquier capa. Esto simplifica la complejidad
pues evita llamadas innecesarias a las capas adya-
centes. Como parte tambin del estilo arquitectni-
co propuesto, cada capa mantiene comunicacin
solo con su capa adyacente lo que mejora el proce-
so de separacin de las mismas en caso de ser
necesario.

2.6 Estrategia de implementacin
El propio desarrollo basado en componentes pro-
pone una estrategia de implementacin bien defini-
da. Esta estrategia sin dudas representa una gran
ayuda a la hora de construir aplicaciones muy pare-
cidas con elementos claramente reutilizables como
es el caso de los laboratorios virtuales a desarrollar.
Como parte de la estrategia de implementacin se
proponen los siguientes pasos para el desarrollo de
cada componente:
Se selecciona la funcionalidad que por
sus caractersticas puede ser reutilizable
a otros laboratorios virtuales.
Se determina la capa de la aplicacin en
la cual est presente la funcionalidad.
Se implementa el componente teniendo
en cuenta las restricciones de la capa.
Se prueba el componente y sus funcio-
nalidades bsicas como unidad.
Se prueba el componente y sus funcio-
nalidades acopladas a la AS.
Se documenta y se ubica el componente
en el repositorio del proyecto, para su
utilizacin por los desarrolladores.

El componente como unidad bsica deber cumplir
los siguientes trminos:
Ser usado por los desarrolladores de
los laboratorios virtuales sin la interven-
cin de su creador.
Merzeau, Alejandro.; Garca, Orlay. | PROPUESTA DE ARQUITECTURA DE SOFTWARE PARA EL DESARROLLO DE LABORATORIOS VIRTUALES

XV Congreso Internacional de Informtica en la Educacin

Incluye una especificacin de sus de-
pendencias.
Incluye una especificacin de la funcio-
nalidad que ofrece.
Se acopla a la AS de manera rpida y
sin complicaciones.

Se puede apreciar que utilizando esta estrategia de
desarrollo se pueden identificar dos procesos fun-
damentales, la creacin de componentes y la inte-
gracin de los mismos en la AS. El aseguramiento
de un buen repositorio de componentes, agiliza el
desarrollo de varios laboratorios virtuales de forma
paralela. Igualmente, da cumpliendo a las necesi-
dades de uniformidad. Los mayores esfuerzos de
implementacin estn centrados en la lgica de la
aplicacin reduciendo los tiempos totales de desa-
rrollo.
2.7 Vista Arquitectnicas
El objetivo de las vistas de la arquitectura es la
simplificacin o abstraccin de los modelos, de los
cuales se destacan los detalles ms significativos y
se obvian los que no representan un aporte signifi-
cativo a la visin de la solucin del problema.

2.7.1 Vista lgica

Figura. 2: Vista Lgica
En la figura 2 se pueden ver las diferentes capas,
as como las clases que contiene cada una de ellas.
La capa de presentacin contiene los componentes
de la presentacin. Todos estos componentes tie-
nen en comn que heredan de clases del frame-
work QT, que son parte de la interfaz grfica. Ejem-
plo: QWidget y QDialog. Igualmente, en esta capa,
ocurre el proceso de carga del componente dinmi-
co que contiene el ejercicio a travs de la clase
interfaz coreVLab::LevelInterface. La clase
coreVLab::vlMainWindows es la encargada de con-
tener todos los compontes de interfaz grfica as
como controlar la distribucin fsica de estos en la
ventana de la aplicacin.
La capa lgica contiene toda la realizacin de un
ejercicio. Toda esta capa est encapsulada en un
solo componente dinmico. Lo que permite que se
pueda cambiar de lgica en caso de que la prctica
de laboratorio contemple ms de un ejercicio.
La capa de soporte contiene los componentes
dinmicos que sirven de apoyo a la realizacin de
un ejercicio determinado. El control de estos com-
ponentes radica en la capa lgica.
La capa elementos comunes contiene las clases
que pueden ser accesibles desde cualquier punto
de la aplicacin. La clase ComponentCore es la
encarda de la administracin de los componentes
dinmicos que se encuentran en la capa de sopor-
te. Contiene tambin la clase ComponentProvider.
Esta es la interfaz abstracta a todos los componen-
tes dinmicos de la capa de soporte. Igualmente,
cada componente de este tipo tiene otra interfaz
abstracta que expone sus especificaciones. Nece-
sario para que en la capa lgica se conozca las
particularidades de un componente en particular.


2.7.2 Vista de Implementacin
La vista de implementacin nos proporciona una
perspectiva general de los componentes ms im-
portantes para la arquitectura as como sus interfa-
ces.

Merzeau, Alejandro.; Garca, Orlay. | PROPUESTA DE ARQUITECTURA DE SOFTWARE PARA EL DESARROLLO DE LABORATORIOS VIRTUALES

XV Congreso Internacional de Informtica en la Educacin


Figura. 3: Vista de Implementacin

2.8 Discusin general de la Arquitectura
La AS propuesta favorece atributos de calidad co-
mo:
Configurabilidad: La incorporacin a la arquitectura
de un componente de configuracin permitir apro-
vechar al mximo las posibilidades del hardwaree-
xistente.
Modificabilidad: Los componentes al ser tratados
como elementos independientes se pueden actuali-
zar sin influir en otros elementos de la arquitectura.

Mantenibilidad: La arquitectura propuesta tiene bien
definida cada una de sus capas, y la lgica a seguir
para dar solucin a un problema determinado.

Existen temas importantes que se deben tener en
cuenta respecto al diseo propuesto. Estos son:

Alto acoplamiento al frameworkQt. Re-
sulta muy difcil pensar en la arquitectu-
ra propuesta sin el uso del frameworkQt.
La mayora de los componentes estn
realizados sobre esta base. Adems que
la garanta de ser un sistema portable
pertenece completamente al frame-
workQt.
No existe un mecanismo para adicionar
funcionalidades que no est controlado
por los desarrolladores. Por ejemplo: no
se puede aadir una nueva funcionali-
dad a un ejercicio determinado, a no ser
que el ejercicio sea actualizado por el
desarrollador y luego se remplace por la
versin anterior a este.
Gran parte de los componentes en la
arquitectura son componentes dinmi-
cos. Esto provoca la existencia de un
tiempo asociado a la carga y el chequeo
de estos. Esto ocurre cuando la aplica-
cin ya est iniciada y aunque no afecta
el rendimiento de forma drstica, debe
ser un elemento a analizar para poste-
riores iteraciones.

2.9 Evaluacin de la Arquitectura
Para la evaluacin de la arquitectura propuesta se
utilizar el modelo de calidad ISO/IEC 9126 adap-
tado para AS en conjunto con el mtodo ATAM y la
tcnica de evaluacin basada en escenarios.
ATAM es un mtodo para identificar riesgos. Este
debe ser ejecutado tempranamente en el ciclo de
desarrollo del software, con bajos costes y de ma-
nera rpida, dependiendo en gran medida del nivel
de especificacin de la arquitectura desde su inicio.
Debido a esto no es posible predecir exactamente
cmo ser el comportamiento de un atributo de
calidad, pero si se podr identificar los posibles
riesgos asociados a beneficiar o descartar un atri-
buto de calidad u otro [8].
Los escenarios a evaluar son los siguientes:
Escenario 1: La integridad de los ficheros media
est asegurada.
Escenario 2: Al ocurrir un error en la aplicacin es
reportado por el sistema de log.
Escenario 3: El sistema es capaz de volver al ltimo
estado estable de la aplicacin despus de ocurrir
un error.
Escenario 4: El sistema debe permitir, despus de
desplegado, adicionar nuevos ejercicios sin muchas
complicaciones.
Escenario 5: Mantenimiento de algn componente.
Escenario 6: El sistema puede ser portado en va-
rios sistemas operativos.

2.9.1 Resultados de la Evaluacin.
Basada en la informacin recolectada y haciendo
uso del mtodo ATAM se pudo identificar 2 riesgos
en los escenarios 1 y 3. Los riegos encontrados,
despus de analizados, demuestran que la arqui-
tectura puede presentar problemas en caso de que
estos escenarios ocurran, pero en correspondencia
Merzeau, Alejandro.; Garca, Orlay. | PROPUESTA DE ARQUITECTURA DE SOFTWARE PARA EL DESARROLLO DE LABORATORIOS VIRTUALES

XV Congreso Internacional de Informtica en la Educacin

con el tipo de aplicacin a desarrollar, los usuarios
que la utilizarn y la prioridad de estos escenarios
se decide registrar y posponer el tratamiento de
estos riesgos para una segunda iteracin de la ar-
quitectura.
Partiendo de la idea que la evaluacin solo propor-
ciona el potencial de arquitectura para alcanzar los
atributos de calidad requeridos, se realiz una
prueba de la arquitectura con los desarrolladores
del proyecto Laboratorios Virtuales. Como objetivo
principal de esta prueba se consider:
Probar la funcionalidad del diseo pro-
puesto.
Encontrar errores y funcionamientos no
adecuados en la arquitectura.
Dar a conocer al equipo de desarrollo la
arquitectura candidata a utilizar para la
creacin de laboratorios virtuales.
Las pruebas realizadas arrojaron la presencia de
errores en varios componentes de la arquitectura.
Tambin se constat que la familiarizacin con la
arquitectura y su estructura general puede ser
compleja. Se demostr que la arquitectura es com-
pletamente funcional y capaz de adaptarse aunque
no se encuentre completamente terminada.

3. CONCLUSIONES
El diseo de la arquitectura de software es una de
las etapas fundamentales en el proceso de desarro-
llo de software. En esta etapa son importantes los
conocimientos y la experiencia adquirida por los
arquitectos para obtener una buena solucin. Al
finalizar este trabajo, se arriban a las siguientes
conclusiones:

La arquitectura propuesta con un enfo-
que multiplataforma y basado en tecno-
logas libres representa una gua para el
desarrollo de los laboratorios virtuales
en el CEDIN.
La combinacin de los estilos y patrones
de diseo utilizados permite alcanzar al-
tos niveles de reutilizacin y mantenibili-
dad.
Las pruebas realizadas, mediante el
mtodo ATAM, arrojaron la presencia de
riesgos en la arquitectura los cuales fue-
ron registrados.

4. REFERENCIAS BIBLIOGRFICAS
1. Kruchten, Philippe. The 4+1 View Model of
Software Architecture. 1995.
2. IEEE Computer Society. 1471-2000 - Rec-
ommended Practice for Architectural Description for
Software-Intensive Systems. 2000.
3. An introduction to software architecture.
Garlan, David and Shaw, Mary. 1994, Technical
report (Carnegie Mellon University. School of Com-
puterScience).
4. Reynoso, Carlos. Carlos Reynoso Investiga-
cin, Publicaciones y Cursos de Antropologa,
Ciencia Cognitiva y Complejidad. [Online] 2004.
carlosreynoso.com.ar/arquitectura-de-software/.
5.A field guide to Boxology: Preliminary clas-
sification of architectural styles for software
systems. Shaw, Mary and Clements, Paul. 1997.
Proceedings of the 21st International Computer
Software and Applications Conference.
6. Szyperski, Clemens Alden. Component
software: Beyond Object-Oriented programming.
s.l.: Addison-Wesley, 2002.
7.Gamma, Erich; Helm, Richard ; Johnson,
Ralph; Vlissides, John.Design Patterns: Elements
of reusable object-oriented software. s.l. : Addison-
Wesley, 1995.
8. Rick Kazman, Mark Klein, Paul Clements.
Evaluating software architectures: methods and
case studies. s.l. : Addison-Wesley, 2002. ISBN
9780201704822.

5. SNTESISCURRICULARES DE LOS AU-
TORES
Alejandro David Merzeau Martnez.
Calle 306 % 3ra y 3ra A # 309 Santa Fe, Playa,
Habana, Cdigo postal
11300.admerzeau@uci.cu.Graduado en
Ingeniera en Ciencias Informticas en la UCI.
Entre las principales lneas de investigacin que
desarrolla se encuentran:Visualizacin y
Realidad Virtual, Motores Grficos y Fsicos para entornos
multiplataforma, Shaders y Programacin para GPUs e Ingeniera
de Sistemas. Arquitecturas de Software.Trabaja actualmente en el
CEDIN perteneciente a la UCI donde se desempea como
desarrollador y arquitecto del proyecto Laboratorios Virtuales.
Participo con una ponencia en el evento informtica 2011 con el
trabajo:Interaccin 3d Basada en cmaras sobre superficie
acutica. Memorias del Evento XIV Convencin y
FeriaInternacionalInformtica2011.