Entornos para el desarrollo de grandes aplicaciones de gestión de

Entornos para el desarrollo de grandes aplicaciones de
gestión de redes
Virgilio Gilart Iglesias1 y Alfonso Capella D’alton1
1
Departamento de Tecnología Informática y Computación, Universidad de Alicante
AP. 99, 03080, Alicante, España
{vgilart, acapella}@dtic.ua.es
http://www.ua.es/i2rc
Resumen. Como consecuencia de la globalización de la economía y la
evolución de los sistemas logísticos y de telecomunicaciones, han surgido
nuevos modelos de negocio para los que las arquitecturas tradicionales no
ofrecen una solución adecuada. La apertura de mercados a nivel mundial y la
dispersión de las propias empresas precisan de arquitecturas de aplicación
distribuidas, segmentadas en múltiples niveles y con amplias capacidades de
interconexión e interoperabilidad. En este contexto, surgen plataformas
empresariales, como J2EE y .NET, que satisfacen los requerimientos de los
nuevos modelos de negocio emergentes. Dichas plataformas introducen una
complejidad tecnológica que hace necesaria la adopción de un entorno de
trabajo, metodológico y sistemático, sostenido por una infraestructura
adecuada. En este artículo proponemos un modelo de trabajo junto con las
tecnologías y herramientas más adecuadas que dé soporte a la creación y
mantenimiento de grandes aplicaciones y servicios capaces de cubrir estas
necesidades al tiempo que aprovechan el verdadero potencial que ofrece
Internet.
Introducción
Internet se ha convertido en un medio que ha cambiado la forma de comprender los
negocios empresariales [1]. Las organizaciones encuentran en este entorno nuevos
modelos de competencia —relaciones entre empresas, formas de captar clientes e
introducción en nuevos mercados— que, por su elevado coste, estaban reservados
únicamente a las grandes corporaciones. Todas estas transformaciones llevan
asociadas la aparición de nuevos requerimientos, no contemplados por los modelos de
software tradicionales, y que, por lo tanto, obligan a adoptar nuevas estrategias para
adaptar los procesos de negocio y sistemas software — reingeniería de procesos.
Para la mayoría de las organizaciones la resistencia a los cambios suele ser elevada
e incluso a veces traumática [1]. Esto se debe principalmente al esfuerzo que requiere
abandonar la cultura empresarial creada, a la complejidad de integración de los
sistemas heredados que contienen información de vital importancia para la
organización, a la modificación de las infraestructuras establecidas y a la creación de
procesos de aprendizaje y formación de sus empleados. Sin embargo, a pesar de estas
dificultades, la aparición de nuevas empresas que se adaptan con rapidez a estas
tecnologías fuerza al resto a evolucionar hacia estos entornos [1].
Las arquitecturas tradicionales no proporcionan una solución global a las
necesidades planteadas por los nuevos modelos de negocio puesto que muchos de los
requerimientos que plantean no formaban parte de su diseño: estándares que faciliten
la integración entre aplicaciones y diferentes dispositivos [3,4], escalabilidad que
permita que las aplicaciones crezcan a la vez que crece el negocio [2,4], flexibilidad
frente a las nuevas tecnologías y sistemas de computación ubicua [3,4], seguridad en
entornos no fiables y proclives a ataques [7], portabilidad a diferentes sistemas [4].
Para llenar este hueco aparece una nueva generación de plataformas software basadas
en componentes sobre arquitecturas distribuidas (n-niveles), que ofrecen una
solución completa que permite abordar los nuevos modelos de negocio y que
aprovechan el entorno tecnológico que propone Internet [1].
Ante los nuevos modelos de desarrollo y enfoques empresariales surge la
necesidad de reemplazar muchas de las prácticas de gestión de proyectos
convencionales y requerimientos técnicos por nuevos enfoques. Éstos deben
combinar técnicas de éxito, procedentes de experiencias anteriores, con avances
tecnológicos en la ingeniería del software [5]. Al igual que las aplicaciones creadas
para los nuevos modelos empresariales, las infraestructuras sobre las que se sustenta
el desarrollo de dichas aplicaciones deben ser flexibles y escalables para adaptarse a
los cambios derivados de los nuevos modelos.
Las nuevas plataformas de desarrollo software establecen una serie de roles y
filosofías de trabajo derivadas de su arquitectura de n-niveles que permiten la
realización de proyectos de manera horizontal [6]. Cada rol tiene un cometido
específico que en ciertas etapas del ciclo de vida del software podrán desempeñar de
forma paralela mientras que, en otras, deberán hacerlo en cascada. El trabajo en grupo
para este tipo de modelos resulta imprescindible y la sincronización de las tareas
específicas de cada rol, determinante [4].
En este artículo se propone un marco de trabajo que dé cobertura a la creación y
mantenimiento de aplicaciones para los nuevos modelos empresariales basados en
componentes distribuidos.
Modelo de Entornos
Hemos definido el entorno de trabajo para el desarrollo de un producto software
como el conjunto de circunstancias y estados en los que se puede encontrar dicho
producto a lo largo de su ciclo de vida. Tras este análisis, basado en la experiencia de
los componentes del Grupo de Redes – perteneciente a la unidad singular de
investigación redes de computadores e informática industrial del Departamento de
Tecnología y Computación de la Universidad de Alicante –, hemos definido un
modelo del entorno de trabajo que nos proporciona una serie de elementos lógicos,
relacionados con el estado del software en un determinado momento y asociado a un
conjunto de funciones y roles, con el que abordar los proyectos realizados con las
plataformas empresariales mencionadas anteriormente.
Figura 1. Modelo de entonos.
En la figura 1 se muestra los elementos que componen el modelo y la interacción
que existe entre ellos. A continuación se explica cada elemento y sus principales
funciones dentro del marco propuesto.
El repositorio software
El elemento, posiblemente, más importante de nuestro modelo es el Repositorio
Software. Podemos definir un repositorio como un almacén, común a un grupo de
trabajo, de elementos software necesario para el desarrollo de aplicaciones y la
gestión de proyectos. El repositorio software se compone de dos partes bien
diferenciadas.
- Herramienta de control de versiones
- Servidor de archivos distribuidos
Con la herramienta de control de versiones tenemos ciertas ventajas para
desarrollar aplicaciones:
- Control de versiones del software
- Facilita el trabajo en grupo
- Comparación entre versiones
- Facilita los desarrollos de versiones en paralelo
Con el servidor de archivo conseguimos tener centralizados todos los documentos
de especial interés para el desarrollo de aplicaciones y nos facilita la localización del
software necesario para el desarrollo.
La justificación principal de estos dos elementos se basa en el grado de cambio que
tendrán los archivos almacenados en ambos y que se define a continuación.
Repositorio Software
Servicio de
control de
versiones
Sistema de
archivos
distribuidos
Figura 2. Elementos del Repositorio Software.
Sistema de archivos distribuido
El sistema de archivos distribuido nos proporciona la infraestructura necesaria para el
almacenamiento de documentos tecnológicos y software que no van a sufrir
modificaciones por parte del grupo de trabajo.
La documentación almacenada está relacionada con la tecnología que se ha ido
utilizando en el desarrollo de proyectos. Existen periodos de autoformación en los
cuales se debe buscar información de interes en la red – Internet. En este proceso se
debería considerar si la información encontrada puede ser de utilidad para el grupo y
para uno mismo. Es una forma de tenerla localizada y compartirla con el resto del
equipo.
Por otra parte se encuentran las aplicaciones software utilizadas dentro del grupo y
de los entornos de trabajo. Utilizar un sistema de archivos distribuidos permite una
fácil localización de las herramientas con los cuales se debe trabajar y por lo tanto
una mejora de la productividad.
Con esta filosofía se pretende evitar los costes de tiempo que supone: la descarga
de software de terceros por múltiples usuarios, pérdida de documentación de interés,
perdida de software almacenados en diversos dispositivos…
Control de versiones
Por otra parte existe una serie de archivos – código fuente, documentación, políticas
de trabajo – que son susceptibles de a ser modificadas en algún momento.
Normalmente estos archivos han sido generados por el equipo y por lo tanto
pueden evolucionar y ser mejorados. Estos archivos deben ser compartidos por el
conjunto del grupo en función del rol al que pertenezcan. Para ello existen una serie
de herramientas de control de versiones imprescindibles a la hora de montar cualquier
entorno de desarrollo de medio o alto nivel. En el desarrollo de aplicaciones las
herramientas de control de versiones son de gran utilidad para conocer el estado del
código fuente en cada momento, proporcionándonos las siguientes ventajas:
centralización del código fuente y documentación relacionada con los proyectos,
controlar la versión o estado del software que se está desarrollando, regresar a
versiones anteriores en caso de errores, facilitar el trabajo en paralelo entre diferentes
versiones, control completo de la evolución del software, proporcionar mecanismos
para la automatización de tareas de paso de entornos – políticas de etiquetado,
facilitar el conocimiento del autor de cada versión y las modificaciones realizadas.
Los entornos
Podemos definir un entorno, dentro de nuestro marco de trabajo, como la
infraestructura necesaria para acometer las tareas específicas requeridas por el
producto software, en función del estado en el que se encuentra.
En nuestro modelo un producto software sufre una evolución de manera que, en un
momento dado, puede encontrase en uno de los siguientes estados:
-
Desarrollo
Integración
Demostración
Preproducción
Producción
- Estabilidad
+ Estabilidad
Cada estado define un nivel de estabilidad del software, y la secuencia de estados
representa la evolución del producto software desde su fase más temprana – toma de
requerimientos – hasta su puesta en funcionamiento – deployment o despliegue en
producción.
Figura 3. Evolución del producto a través de los distintos entornos del modelo.
Estos cinco estados nos definirán los entornos de trabajo que vamos a describir para
el desarrollo de nuestras aplicaciones, y cada entorno se centrará en un subconjunto
específico de las tareas de creación y mantenimiento de la aplicación.
El entorno de desarrollo.
El entorno de desarrollo conlleva el abanico más amplio de tareas, que abarca desde
el comienzo del ciclo de vida del software – toma de requerimientos – hasta la
obtención de una versión minimamente estable de la aplicación, o de un subconjunto
de la misma – módulos.
En este entorno se llevan acabo las siguientes tareas:
•
Toma de requerimientos: Una vez hemos concretado las necesidades del
cliente y hemos establecido varias reuniones con este fin, es aconsejable
documentarlo, de manera que todo el equipo pueda tener una visión global
del proyecto – requerimientos funcionales. Este documento se podrá ir
completando en posteriores entrevistas puesto que nunca quedan resueltas
desde un principio las necesidades funcionales del sistema. En esta fase
suele ser necesario usar herramientas de documentación y toma de
requerimientos.
•
Análisis de arquitectura y Diseño técnico: Estas son dos de las tareas más
importantes del desarrollo software y que pueden determinar el éxito o
fracaso de un proyecto. Se deben realizar las siguientes funciones: acuerdo
inequívoco de los requerimientos especificados, elección de la tecnología
que pueda abarcar las necesidades del proyecto con una adecuada
arquitectura y el diseño de los componentes, localización de las fases más
criticas, aportando soluciones de contención ante posibles problemas que
pudieran aparecer. Además necesitaremos una serie de herramientas que nos
permitan realizar estas funciones de forma productiva.
•
Implementación: Indica el comienzo de la implementación con la tecnología
adecuada elegida en la fase de análisis. Si se ha realizado un buen análisis y
modelado técnico se reduce considerablemente la complejidad de la
implementación.
•
Pruebas de unidad y módulos: Estas pruebas se deben realizar sobre los
módulos y componentes que cada desarrollador vaya finalizando. Se realizan
en un entorno local para comprobar su correcto funcionamiento y poder
integrarlas para obtener el producto final.
De las anteriores tareas podemos deducir las necesidades tanto software como
hardware del entorno de desarrollo, teniendo en cuenta la política de trabajo en
equipo que decidamos seguir.
Desarrollo en paralelo
Los nuevos modelos de desarrollo producen un entorno idóneo para el trabajo en
grupo. La división en roles dentro de estos modelos permite que se trabaje a dos
niveles: en cascada con roles de diferentes niveles – arquitectos, diseñadores técnicos,
desarrolladores, equipo de calidad –; en paralelo dentro del mismo ámbito de
funciones – diseñadores de interfaces, programadores de lógica –.
Se debe distribuir el proceso, responsabilizándose cada uno de un subconjunto de
la de módulos de la aplicación. De esta manera, se puede lograr un paralelismo
temporal en el desarrollo – cada grupo trabaja sus módulos en paralelo, de forma
simultánea –, que minimice el tiempo de desarrollo, siempre que existan suficientes
recursos humanos y tecnológicos.
Las dependencias entre módulos pueden reducir el paralelismo temporal en la
medida en que un grupo debe esperar a que se completen otros módulos para finalizar
las tareas. Un buen diseño – que minimiza las dependencias entre módulos – y una
buena planificación temporal – que configura el orden y prioridades óptimos para el
desarrollo – evitarán en gran medida estos “tiempos muertos”.
Política de trabajo
El desarrollo de aplicaciones empresarial es, como ya hemos mencionado, complejo y
requiere de un elevado número de servicios y sistemas heredados para su realización.
En función de cómo distribuyamos los servicios necesarios para el desarrollo y las
pruebas podemos encontrarnos diferentes problemáticas.
Servicios compartidos
En este esquema de trabajo, los distintos equipos de desarrollo comparten los
recursos y servicios necesarios para desarrollar las aplicaciones – bases de datos,
servicios de directorios, servidores Web y de aplicaciones. De esta forma, en los
equipos locales, únicamente tendremos las herramientas necesarias orientadas al
desarrollo y no a las pruebas – mejoramos el rendimiento local. En el mundo real
surge un problema con este enfoque. Cuando existen varios desarrolladores que
quieren realizar las pruebas básicas de sus módulos pueden realizar cambios sobre los
datos o las configuraciones de los servicios compartidos o sobrescribir versiones y
generar problemas colaterales que no existían y que pueden disminuir la
productividad temporal del proyecto.
Servicios en el entorno local
Cada miembro del equipo de desarrollo tiene localizado en su equipo local las
herramientas y servicios necesarios para desarrollar y realizar las pruebas sobre los
módulos. El problema que puede surgir con este enfoque es de rendimiento debido a
la saturación. En función de la tecnología utilizada y del equipo disponible podemos
tener una perdida de rendimiento que se traduzca en una disminución de la
productividad.
Enfoque mixto
Es una solución de compromiso entre las políticas mencionadas anteriormente en
función criterios asociados al recurso o servicio que se quiere utilizar:
• Estimación de la probabilidad de interferencias. Cuanto menor sea, mejor se
adaptará el recurso al enfoque centralizado.
• Coste económico del recurso. Cuanto menor sea, más factible es que se instale en
el entorno local.
• Coste temporal de la instalación/configuración del recurso. A medida que
aumenta el tiempo necesario para instalar y configurar el servicio o la aplicación y
aumenta el número de equipos locales el coste temporal se multiplica. En este caso
es propicio optar por un enfoque centralizado.
El entorno de integración
En el entorno de integración se lleva a cabo las siguientes tareas:
•
•
Integración de los distintos módulos que componen la aplicación
Pruebas de integración
En el proceso de integración tiene especial importancia el sistema de control de
versiones. Debemos obtener los fuentes etiquetados con la versión estable que
deseamos integrar. Cuando los fuentes son obtenidos se compilan y se genera la
aplicación con todos los módulos integrados.
Llegados a este punto, debemos poner en funcionamiento la aplicación para
someterla a las pruebas de integración. Desplegamos la aplicación basándonos en los
documentos generados durante el proyecto. Una vez integrada y activada la
aplicación, llevaremos a cabo la secuencia de pruebas. El objetivo de estas pruebas es
comprobar el funcionamiento de la aplicación como un todo. En ellas, se trata de
probar las funcionalidades que debe cumplir el producto, aunque también debe ser
probadas las anteriores funcionalidades para evitar que los cambios introducidos
alteren inadvertidamente el comportamiento de las mismas.
Si la aplicación satisface las pruebas de integración, entonces está lista para su
paso al entorno de preproducción – para realizar las pruebas de calidad – y al entorno
de demostración – para permitir el acceso al cliente.
En el caso en el que se produzca un error en estas pruebas debemos generar una
incidencia – se debe crear una política de gestión de incidencias – y emitirla al
encargado del módulo en el cual se produjo.
El entorno de preproducción
En el entorno de preproducción se lleva a cabo las pruebas finales de la aplicación
antes de su paso final al entorno de producción, donde se pondrá en funcionamiento
en un escenario real.
Para ello, en primer lugar se transfiere la aplicación una vez ha sido validada en el
entorno de integración – a ser posible de una forma automatizada. El equipo de
calidad, someterá la aplicación a un conjunto exhaustivo de pruebas, de diversos
tipos:
• Funcionales y estructurales
• De rendimiento
• De tolerancia a fallos
• De seguridad
Si estas pruebas, conocidas como de aceptación, resultan satisfactorias, entonces la
aplicación está ya lista para su paso al entorno de producción.
Si alguna de las pruebas falla debemos seguir el protocolo creado para la gestión
de incidencias.
El entorno de producción
El entorno de producción contiene en todo momento la versión activa de la
aplicación. Los usuarios finales tienen acceso a la aplicación implantada en este
entorno, de modo que resulta indispensable planificar y adoptar las medidas de
seguridad oportunas, en consonancia con la importancia de la información que
maneja el sistema.
Por otra parte, este entorno también contiene los datos reales, información que es
preciso salvaguardar frente a posibles pérdidas mediante la aplicación sistemática de
una política de copias de seguridad. También debemos proteger los datos frente a
exposición o usos fraudulentos de los mismos, restringiendo su acceso
exclusivamente al personal de confianza que administra el sistema.
La aplicación se despliega en el entorno de producción procedente de la versión
existente en el entorno de preproducción. La subida debería producirse de forma
automática para evitar, en la medida de lo posible, la introducción de errores.
El entorno de demostración
Este entorno tiene dos funciones: posibilitar al cliente el acceso a la aplicación que se
está desarrollando y mostrar los productos existentes con el fin de atraer a posibles
clientes.
La aplicación se transferirá desde el entorno de integración con un proceso similar
a la subida a preproducción.
Pasos entre entornos
Este proceso es uno de los puntos más importantes en el ciclo de vida del software.
Debe contar con una serie de procedimientos y protocolos que se cumplan siempre
que se produzca un cambio de entorno.
Es un proceso crítico que se debe ser mejorado con la experiencia.
Vamos a dividir los pasos de entornos en tareas más pequeñas para describir todo el
proceso.
Desarrollo a Integración
Este es el proceso menos crítico de los que se deben llevar a cabo. En este paso
participan los siguientes elementos:
•
•
•
•
Desarrolladores
Documentos de despliegue
Sistemas de control de versiones
Responsable del paso de entorno.
Los desarrolladores son los responsables de subir los módulos al sistema de
control de versiones y etiquetarlos correctamente conforme a las políticas que se
hayan definido.
Los documentos de despliegue son muy necesarios puesto que ayudan a tener un
control de qué archivos han sido modificados en la versión del proyecto. Si bien
puede parecer redundante, puesto que si se ha etiquetado correctamente se tendría
localizado, es una buena solución como medida de seguridad que nos evite tener
imprevistos.
El sistema de control de versiones es necesario puesto que el entorno de
integración obtendrá de ahí los archivos que hayan sido modificados.
Tener un responsable para esta tarea se hace indispensable para canalizar, a través
de una única persona, el proceso de obtención de los archivos modificados. Este rol
debe ser asumido por uno de los componentes del proyecto.
El proceso es sencillo y consta de los siguientes pasos:
•
•
•
•
Los desarrolladores deben subir sus módulos correspondientes al sistema de
control de versiones.
Estos deben ser etiquetados siguiendo la política de etiquetado de la
organización.
Una vez que se hayan subido todos los módulos el responsable de la
integración deberá obtener dichos archivos, seleccionándolos por la etiqueta
correspondiente, y actualizarlos en el entorno de integración.
Una vez actualizados los archivos en el entorno de integración se procederá
a compilar el proyecto y a instalarlo, siguiendo el documento de despliegue.
Integración a Preproducción
Una vez que el proyecto ha sido validado mediante las pruebas de integración, se
etiqueta el proyecto para pasarlo a preproducción.
En este paso no se utilizará el sistema de control de versiones. El contenido del
entorno de integración se subirá a preproducción. Al igual que en el caso anterior
habrá un responsable encargado de desplegar el proyecto en el entorno de
preproducción utilizando el documento de despliegue.
Dicho documento indica que módulos se deben subir y cual es la localización
correspondiente a cada módulo.
Preproducción a Producción
Este paso es el más crítico de todos. La tarea a realizar es idéntica al paso anterior. Si
ha habido algún problema de subida de entorno – por ejemplo, olvidarse subir
archivos – debe producirse en el entorno anterior y se debe quedar resuelto antes de
llegar a este punto.
Caso de estudio: marco de trabajo para el Grupo de Redes
Repositorio software
Como mencionamos anteriormente, el repositorio software presta dos servicios: el
sistema de control de versiones y el sistema de archivos distribuidos.
Control de versiones mediante CVS
Como herramienta de control de versiones, utilizamos el sistema CVS [8] –
Concurrent Versions System, o Sistema de Versiones Concurrentes. Se trata de una
aplicaión de software libre ampliamente difundido. En nuestro caso utilizamos el
esquema cliente/servidor de manera que todas las versiones de archivos fuente y
configuración para cada proyecto se encuentran centralizadas en un servidor. Para un
uso más ágil y cómodo del mismo, empleamos clientes con interfaces gráficos de
usuario, como WinCVS – para Windows – o Cervisia – disponible para Linux.
Por otra parte, en el caso de que necesitemos trabajar con servidores CVS a través
de redes inseguras, el sistema admite el empleo de protocolos de transporte seguros
(SSL), que cifran la información.
A la hora de gestionar los archivos de un proyecto mediante CVS, creamos un
módulo por cada proyecto: un módulo CVS es un elemento jerárquico, similar a un
directorio, que contiene un conjunto de versiones de archivos.
De esta manera, podemos gestionar los permisos de los usuarios CVS
restringiendo el acceso a los módulos en función del proyecto asignado y su rol.
A fin de organizar los distintos archivos del proyecto, crearemos una estructura de
directorios dentro del módulo correspondiente, donde situaremos cada archivo en
función de su categoría:
• Requerimientos
• Diseño
• Implementación
• Despliegue
• Documentación
Debido a que la información contenida en el repositorio es sumamente importante
y crítica para nuestro negocio, debemos nombrar un administrador del mismo. El
administrador velará por la integridad y coherencia del repositorio, y otorgará a cada
usuario/grupo permisos para acceder a los módulos que esté desarrollando. Por
supuesto, es imprescindible salvaguardar la información del repositorio mediante una
política de copias de seguridad con una frecuencia suficiente: En nuestro caso,
optamos por realizar una copia diaria, de forma automatizada, en las horas nocturnas
cuando no hay actividad y los desarrolladores ya han incorporado los archivos
correspondientes al trabajo diario.
Política de etiquetado
Una correcta utilización de un sistema de control de versiones requiere definir una
política de etiquetado. De esta manera podremos realizar seguimientos y localizar
versiones concretas del proyecto. Constituye la clave para el paso de aplicaciones
entre distintos entornos. Dicha política se traduce en una nomenclatura específica
para las etiquetas.
Tabla 1. Política de etiquetado.
Entorno
Sintaxis de la etiqueta
Desarrollo
DR_NombreProyecto_VersiónProyecto
Integración
IR_NombreProyecto_VersiónProyecto
Preproducción
PR_NombreProyecto_VersiónProyecto
Producción
FR_NombreProyecto_VersiónProyecto
Significado del prefijo
Development Release
Integration Release
Preproduction Release
Final Release
Sistema de archivos distribuido: SMB
Para compartir archivos comunes, que no precisan de control de versiones – tales
como instaladores, documentación externa, etc. – ofrecemos, dentro del repositorio
software, un servicio de archivos en red de tipo SMB [9]. Este servicio resulta muy
cómodo y práctico pues permite trabajar con los directorios compartidos como si se
tratase de unidades locales a la máquina cliente y ofrece una alta compatibilidad entre
sistemas Linux y Windows.
Ambos servicios se encuentran instalados sobre servidores Linux en nuestro
entorno de trabajo.
Entorno de desarrollo
En nuestro entorno de desarrollo, seguimos una política de trabajo local, donde cada
desarrollador posee su propia máquina, en la cuál instala todos los servicios y
herramientas requeridos para llevar a cabo sus actividades de manera que sea
completamente autosuficiente.
No obstante, en determinadas situaciones habilitaremos servidores externos para
prestar servicios comunes a todos los usuarios de un entorno. Es el caso del servicio
de directorio Active Directory [10]. Dicho servicio es compartido entre todos los
usuarios en los entornos de desarrollo e integración – política mixta.
Figura 4. Esquema de nuestro entorno de desarrollo.
De forma estándar, configuramos las máquinas de desarrollo con el siguiente
software:
Tabla 2. Configuración estándar de software para las máquinas de desarrollo.
Sistema operativo
Windows XP ó 2003
Suite ofimática
MS-Office
Cliente de correo electrónico y agenda
MS-Office Outlook
Servidor de directorio
OpenLDAP y Active Directory
Servidor de B.D.
MySQL y SQL Server
Servidor Web
Apache Tomcat
Servidor de aplicaciones
JBoss
Herramienta de modelado software
ArgoUML / Poseidon for UML
Herramienta de modelado de datos
DBDesigner
IDE (entorno integrado de desarrollo)
Eclipse + plugins
Herramienta de generación automática
Ant
Compilador
J2EE SDK
Intérprete/Máquina virtual
J2EE Runtime Environment/Java Virtual Machine
Generación de archivos históricos (logs)
Log4Java
Cliente de directorio
Softerra LDAP Browser / Administrador de
Active Directory
Cliente de B.D. (administración)
MySQL Administrator
Cliente de B.D. (navegador)
MySQL Browser
Cliente Web
Microsoft Internet Explorer / Netscape Navigator
Cliente CVS
WinCVS
Editor XML
Cooktop
Para permitir un funcionamiento ágil del sistema, teniendo en cuenta la carga que
suponen los anteriores servicios y aplicaciones, utilizaremos configuraciones
hardware de características equivalentes o superiores a las siguientes:
Tabla 3. Configuración hardware mínima para las máquinas de desarrollo.
Procesador
Memoria RAM
Disco
Interfaz de red
Pentium III o Athlon XP
512 MB
40 GB
Ethernet 100 Mbps
Entorno de integración
En este entorno obtendremos los archivos – correspondientes a la versión que
queremos compilar – del CVS. Debemos contar con las herramientas necesarias para
obtener de una forma sencilla los archivos, para compilarlos y para ejecutar la
aplicación. Para las pruebas de integración será necesario poner en funcionamiento la
aplicación, por tanto serán necesarios los servidores de base de datos, de directorio,
Web y de aplicaciones, así como la máquina virtual de Java. Además, necesitaremos
un cliente CVS para obtener del repositorio la versión correspondiente de los archivos
fuente que componen la aplicación.
Figura 5. Esquema del entorno de integración.
En cuanto al conjunto de datos utilizado para las pruebas, se trata de datos ficticios
para evitar problemas con la información sensible.
Tabla 4. Configuración software para el entorno de integración.
Sistema Operativo
Cliente CVS
Servidor de aplicaciones
Servidor Web
Servidor de directorio
Servidor de B.D.
Compilador
Intérprete/Máquina virtual
Herramienta para generación automática
Generación de archivos históricos (logs)
Linux
Servicia
JBoss
Apache Tomcat
OpenLDAP y Active Directory
MySQL
J2EE SDK
J2EE Runtime Environment
Ant
Log4Java
Tabla 5. Configuración hardware mínima para el entorno de integración.
Procesador
Memoria RAM
Disco
Interfaz de red
Pentium III o Athlon XP
512 MB
40 GB
Ethernet 100 Mbps
Entorno de preproducción.
En este entorno se llevan a cabo las pruebas de aceptación del producto, las últimas
realizadas antes de pasar la aplicación al entorno de producción. Por este motivo, el
entorno de preproducción debe contener la infraestructura necesaria para ejecutar la
aplicación. Para ello será necesario el servidor de aplicaciones, servidor Web, de base
de datos y de directorio. La carga de datos en este entorno debe ser similar a la de
producción para poder realizar pruebas de rendimiento reales.
Figura 6. Esquema del entorno de preproducción.
Tabla 4. Configuración software para el entorno de preproducción.
Sistema Operativo
Cliente CVS
Servidor de aplicaciones
Servidor Web
Servidor de directorio
Servidor de B.D.
Compilador
Intérprete/Máquina virtual
Herramienta para generación automática
Generación de archivos históricos (logs)
Windows
WinCVS
JBoss
Apache Tomcat
Active Directory
MySQL
J2EE SDK
J2EE Runtime Environment
Ant
Log4Java
Tabla 5. Configuración hardware para el entorno de integración.
Procesador
Memoria RAM
Disco
Interfaz de red
Xeon
1 GB
140 GB
Ethernet 1 Gbps / 100 Mbps
Entorno de producción.
En nuestro entorno de producción utilizamos una configuración hardware/software
idéntica a la de preproducción, garantizando en la medida de lo posible un
comportamiento similar de la aplicación en ambos entornos.
Por otra parte, en este entorno los usuarios finales tienen acceso a la aplicación,
por tanto adoptamos las medidas de seguridad oportunas para evitar ataques o usos
ilegítimos del sistema.
Figura 7. Esquema del entorno de producción.
Tabla 4. Configuración software para el entorno de preproducción.
Sistema Operativo
Cliente CVS
Servidor de aplicaciones
Servidor Web
Servidor de directorio
Servidor de B.D.
Compilador
Intérprete/Máquina virtual
Herramienta para generación automática
Generación de archivos históricos (logs)
Windows
WinCVS
JBoss
Apache Tomcat
Active Directory
MySQL
J2EE SDK
J2EE Runtime Environment
Ant
Log4Java
Tabla 5. Configuración hardware para nuestro entorno de integración – servidores Proliant.
Procesador
Memoria RAM
Disco
Interfaz de red
Xeon
1 GB
140 GB
Ethernet 1 Gbps / 100 Mbps
Conclusiones
Los nuevos modelos empresariales requieren aplicaciones dotadas de las siguientes
características:
• Seguridad.
• Robustez y fiabilidad.
• Tolerancia a fallos.
• Escalabilidad.
• Flexibilidad.
• Interoperabilidad.
• Mantenimiento y gestión.
Con el objetivo de soportar estas características, que suponen una complejidad
tecnológica considerable, surgen plataformas como J2EE y .NET, que ofrecen las
infraestructuras básicas necesarias para crear tales aplicaciones.
Para que dicha construcción tenga lugar de forma ordenada y rigurosa, encajando
las piezas adecuadas en los lugares clave, necesitamos ayudarnos de una serie de
guías de diseño. Entre estas se encuentran los patrones de diseño, que ofrecen
soluciones a problemas basados en la experiencia de terceros.
Por último, como productores de aplicaciones, deseamos que éstas se construyan al
ritmo adecuado, aprovechando al máximo los recursos humanos y tecnológicos
disponibles, optimizando los costes y la calidad del producto. Para lograr estos
objetivos, necesitamos un modelo de trabajo bien definido que soporte las diversas
fases del proceso software y contemple las herramientas y tecnologías utilizadas en
dicho proceso. Este modelo debe evolucionar para incorporar la experiencia obtenida
en cada nuevo desarrollo. Se trata, en definitiva, de un concepto análogo al de los
patrones de diseño de aplicaciones, pero orientado a las políticas y metodologías de
trabajo.
En este artículo hemos propuesto un modelo de trabajo genérico que ofrece
soporte a la creación y mantenimiento de aplicaciones utilizando plataformas
empresariales. Para simplificar nuestro modelo, lo hemos dividido en entornos
asociados a las fases del ciclo de vida del software, estableciendo políticas de paso de
la aplicación entre los entornos. Esta división permite adaptar cada entorno a las
necesidades específicas de la aplicación en cada estado concreto de su ciclo de vida,
sin perder por ello la visión global del proyecto.
Finalmente, hemos aplicado el modelo genérico a un caso práctico, especificando
el modelo concreto que utilizamos para desarrollar proyectos en el Grupo de Redes,
utilizando la plataforma J2EE.
Referencias
1.
P. Harmon, M. Rosen y M. Guttman. Developing E-business Systems and Architectures: A
Manager’s Guide. Ed: Morgan Kaufmann Publishers, 2001.
2. J.L. Weaver, K. Mukhar y J. Crume. Begining j2EE 1.4: From novice to professional. Ed:
Apress, 2004.
3. U. Hansmann, L.Merk, M.S. Nicklous y T. Stober. Pervasive Computing, second edition.
Springer, 2003
4. Sing, I, Stearns, B, Jonson, M: Design Enterprise Applications with J2EE Plantaform,
Second Edition. Ed: Addison-Wesley, 2002
5. Royce, W.: Software project management. Ed.Addison-Wesley, 1999.
6. Bodoff, S., Green, D., Haase, K., Jendrock, E., Pawlan, M., Stearns, B.: The J2EE tutorial.
Ed. Addison-Wesley, 2002.
7. Gong, L.: Inside Java 2 paltform security. Ed. Addison-Wesley, 1999.
8. http://www.cvshome.org
9. Eckstein, R., Collier-Brown, D., Kelly, P.: Using Samba. Ed. O’Reilly, 1999.
10. Allen, R.: Active Directory Cookbook for Windows Server 2003 and Windows 2000. Ed.
O’Reilly, 2003.