Arquitectura Software – Estilo de Código Móvil






AS
Estilo de Código Móvil
 Lisardo Fernández Cordeiro
Sergio Merino Martínez

ETSE   –  3º GII  –  IS II
Universidad de Valencia


Lidiar con conceptos que no se están quietos ni un solo momento resulta de lo más aterrador. Máxime, si las herramientas con las que uno se acerca al campo de batalla se resisten al mimo del reposo sosegado, requerido por todo útil que pretenda serlo.
La explosión evolutiva sufrida por las tecnologías de la información y la comunicación guarda extraño parangón con la explosión de vida natural en tiempos primigenios, cuando la primera combinación acertada de compuestos carbónicos cobró vida y se puso a explorar como loca todas las vías que se abrían por delante.
Esta riqueza de vías expansivas sobre las que se mueve el desarrollo software provoca, a su vez, que el estadio donde alojamos la tecnología actual posea ciertos riesgos derivados de su velocísima integración a nivel mundial y la elevada dependencia de sistemas y herramientas amparadas en una consistencia, en algunos casos, puramente superficial.
Con todo, no viene mal echar un vistazo a tiempos no demasiado remotos, florecientes en el ingenio humano y dados, por tanto, también a abigarrados excesos conceptuales, de los que rescatar lo que Leonardo da Vinci sostenía: la simplicidad es la mayor sofisticación.
Para afrontar, por tanto, el futuro sostenible de los sistemas software, conviene reparar en ese espacio lleno a reventar de bits y dotarlo de simplicidad con armoniosa organización alcanzable, únicamente, mediante la arquitectura entendida como arte, tal y como la definió Auguste Perret.

Introducción o boceto
            Pese a ser incapaces de poner firma al autor de la frase que mejor puede ilustrar la envergadura de lo que este trabajo pretende, no nos resistimos a hacer el mejor uso posible de ella.
“Desarrollar Software de calidad basado en requisitos y caminar sobre el agua son cosas muy fáciles…. si ambos están congelados.”
Absolutamente cierto.
            Los sistemas, desde su misma concepción, no dejan de evolucionar, mutar y reestructurarse. Son entes absolutamente vivos a los que no se puede uno enfrentar con parches sobre un código pobre ajeno a estructura, orden o modelo alguno.
            Precisamente por ello, se deben construir estructuras sólidas, robustas y documentadas que provean de consistencia, flexibilidad, evolución controlada y mantenimiento óptimo con los que satisfacer las necesidades actuales y futuras, evitando la creación de rutas de código ajenas y estructuras perniciosas que desmoronen la estabilidad del conjunto.
            Solo desde una visión general del sistema se puede proporcionar una base de bloques importante donde apoyar el diseño detallado de cada uno, transmitiendo estas ideas básicas a un equipo convencido de su valor para el diseño detallado del conjunto.
            Esta visión global no la proporciona, según los expertos en estos menesteres, la Ingeniería, sino la Arquitectura del Software.
            Es cierto. Incluso existen técnicos que sin terminar de tener claro cómo definir el concepto, lo reconocen a partir de diagramas, flechas, relaciones, etc.
            Pero no temamos. La IEEE define en la norma 1471 lo que, tras muchos años de investigación sobre las mejores prácticas para enfrentarse al desarrollo de sistemas, se entiende por Arquitectura.
“Es el nivel conceptual más alto de un sistema en su ambiente. Su organización a través de sus componentes, las relaciones entre ellos y el entorno y los principios que guían su diseño y evolución.”
            Ya nos lo adelantaba Albert Einstein con una de sus innumerables frases llenas de sabiduría, diciendo algo así como “si no lo puedo dibujar, es que no lo entiendo”. Precisamente en esos dibujos o diagramas es donde se representa el diseño y distribución del software, donde se crean las diferentes vistas de un mismo sistema y su entorno de despliegue.
            Debe ser así, puesto que los riesgos y la complejidad de los sistemas actuales crecen en consonancia con la escala y la distribución de los mismos. De tal manera que la Arquitectura, como testigo menos sobornable de la historia – esta retorcida frase es de Octavio Paz- , deja su impronta en el producto final. Siendo éste el legado transmitido sobre el que se desarrollará la importante labor de mantenimiento y evolución del sistema, sometidos a la mejor o peor suerte marcada por la Arquitectura.
            Así pues, la responsabilidad de estudiar el escenario sobre el que se dibuja el sistema, estableciendo las necesidades a cubrir para satisfacer el plantel de requisitos especificados, con el fin de dotarlo de una especificación coherente con la que enfrentarse a un juego de riesgos reducido es, en último término, de un personaje que va cobrando especial relevancia con el paso de los años: el Arquitecto Software.
           
Evolución histórica
            Como en la mayoría de circunstancias donde el ser humano interviene tocado por la emoción de la novedad, la Arquitectura Software no nace con el desarrollo de sistemas software. Surge fruto de la necesidad.
Conforme los sistemas crecen, lo hace su complejidad y con ella su exposición a riesgos no contemplados en la visión inicial del mismo sistema. De ahí, disponer de una perspectiva de conjunto, diferenciada del punto de vista ingenieril, donde conceptos de alto nivel expresivo identifiquen agentes, establezcan relaciones y se integren en un determinado entorno, establece estructuras de marcado carácter arquitectónico donde soportar el detalle y desarrollo puro de la Ingeniería.
Llegar hasta este punto es el resultado de una evolución que, por otro lado, sigue extremadamente viva.
Así, las primeras aplicaciones eran monolíticas. Basadas en interfaces gráficos de usuario, con los servicios de presentación, negocio y persistencia ubicados en la misma máquina. Aplicaciones carentes de capacidad de concurrencia y con una alta dependencia del cliente respecto al servidor al estar en la misma máquina.
La Arquitectura cliente-servidor inicial, se basaba en una alta carga de clientes sin existencia de estándares. Se establecían conexiones dedicadas a la Base de Datos general, con protocolos pesados ocupando un ancho de banda angosto y con ejecución remota de SQLs. Necesariamente, estas arquitecturas conllevaban alta administración y tráfico en la red con el consiguiente bajo rendimiento y baja accesibilidad.
Resolver los problemas anteriores dio lugar a arquitecturas cliente-servidor mejoradas, donde ya se vislumbra lógica de negocio en Bases de Datos y una mejora en el rendimiento. Sin embargo, siguen padeciendo baja escalabilidad, portabilidad y flexibilidad.
Precisamente, con el objeto de dotar de mayor flexibilidad y escalabilidad a la arquitectura de los sistemas, nace la arquitectura de tres niveles, donde se puede reutiliza la lógica del negocio para diferentes clientes o sistemas y se independencia la Base de Datos.
Este modelo en niveles se hace fuerte y expande a arquitecturas de n niveles, disminuyendo sensiblemente los costes de administración de clientes, a la par que se incrementa la accesibilidad, la flexibilidad, la escalabilidad, la disponibilidad y la tolerancia a fallos.
A partir de este momento se diversifica enormemente la concepción de estructuras de sistemas, desde un punto de vista arquitectónico.
Así, visiones como la Arquitectura Orientada a Servicios (SOA), diferenciando sistemas batch, portales de servicios integrados, clusters de servidores de aplicaciones, servidores de procesos, aplicaciones legadas, bases de datos, etc, dotan a los sistemas de heterogeneidad, escalabilidad, manejabilidad de procesos eficiente y administración y monitoreo de procesos, servicios e infraestructura con alta disponibilidad y escalabilidad.
Otras como Aspect Oriented Programming, Green computing, Semantic Web, Cloud Computing, etc. marcan el hilo conductor de la evolución imparable en el diseño de arquitecturas fiables, capaces de desenvolverse en el vulnerable entorno de los deseos inacabados.
           
Escenarios, necesidades y objetivos
            Tal y como apuntábamos al principio de este trabajo, la volatilidad de las ideas en un entorno de diseño software se debe transformar en sistemas donde la integración del concepto mismo de cambio, pueda ser un pilar más donde soportarlo.
            La Arquitectura Software se encuentra con la absoluta necesidad de lidiar en y con escenarios evolutivos y cambiantes, donde las únicas referencias estables… o estáticas más bien, son las condiciones de partida del proyecto.
            El gran reto inicial parte del conocimiento profundo de las necesidades a cubrir, manteniendo una visión conceptual alejada de los detalles concretos. De este modo, se pueden diseñar estructuras adecuadas, que soporten el paso de los innumerables modificadores que la pondrán a prueba a lo largo de todo su ciclo de vida.
            A partir de esta visión clara e inicial del proyecto, se establecerán las necesidades a cubrir para el desarrollo completo del sistema.
            Aspectos tan importantes como el estudio de la tecnología disponible que soporte tanto el desarrollo como la implementación del sistema, garantizando su consistencia y capacidad de servicio en el tiempo, se unen a otros aspectos como determinar las herramientas más adecuadas con las que planificar, probar y modelar el diseño arquitectónico adecuadamente.
            El número y tipo de personas que integren el conjunto responsable del desarrollo, su nivel de compromiso tanto con las ideas, el concepto estructural, el detalle y definición de los aspectos más pequeños del proyecto, es un valor añadido difícil de ignorar en la fase inicial.
            Así mismo, el conocimiento profundo de todos los aspectos y puntos de vista sobre el sistema, son responsabilidad directa de la Arquitectura del Software. Conocimientos que sentarán las bases del diseño y constituirán la estrategia, modelo o estilo más adecuado.
            En este punto, se establecen los tiempos y las pautas adecuadas que den sentido a un desarrollo coherente del sistema y los costes asociados a todo el camino a transitar hasta la entrega del proyecto.
            Tanto el escenario en el que se mueve el proyecto como la identificación de todas las necesidades, sirve a la Arquitectura para satisfacer las necesidades actuales, proporcionar estructuras sólidas y robustas, concebir sistemas consistentes dimensionados para proporcionar soportes flexibles, evolutivos y con un mantenimiento debidamente estructurado que garantice un ciclo de vida globalmente estable.
Arquitectura no funcional
            A poco que esté el lector atento a lo que este trabajo intenta transmitir, además de la impresión de saber de lo que se está hablando, habrá reparado en la singularidad característica de la Arquitectura de Software como concepto.
            Nos referimos a que la Arquitectura Software se debe centrar, fundamentalmente, en lo que representa la mayor fuente de riesgo de los proyectos. Esta fuente es, precisamente, el conjunto de requerimientos o requisitos no funcionales.
            Los requisitos no funcionales de cualquier sistema son los que ponen en riesgo la calidad sistémica, la del conjunto.
            De tal modo o manera que se exigen, como principios fundamentales de diseño arquitectónico, sistemas que sean seguros ante amenazan internas y externas, garantizando la inmunidad y confidencialidad de los datos y las estructuras que soportan el sistema. También se exigen sistemas de alto rendimiento, capaces de resolver eficientemente las tareas que tiene encomendadas. Sistemas escalables y flexibles aptos para afrontar el crecimiento y el cambio con garantías estructurales que no mermen los requerimientos de eficiencia ni los degraden. La alta disponibilidad es crítica en la inmensidad de sistemas que ofrecen servicio y soporte a un importante número de usuarios, debiendo mantener inmunidad a ataques de denegación de servicio eficientemente. Crear sistemas extensibles también es un requisito no funcional que la Arquitectura debe afrontar.
El arquitecto
            La personalización de todos los conceptos vistos hasta ahora, la responsabilidad de que se realice un buen trabajo de Arquitectura Software, recae sobre la figura del Arquitecto.
            Colgarse la medallita del trabajo bien hecho no resulta ni fácil ni correspondido en esto del diseño de Arquitectura, puesto que el trabajo asociado a la figura del arquitecto es cualquier cosa menos cómodo y sencillo.
            Como máximo responsable del proyecto, debe liderarlo y para ello debe rodearse de un grupo de personas experimentadas, capaces de definir y validar los conceptos de la arquitectura que vaya elaborando, enmarcados en requerimientos de calidad de servicio consensuados con los expertos del dominio y los usuarios finales.
            Debe ser capaz de involucrar al equipo de trabajo alineando ideas y conceptos aceptados por el conjunto, para tomar decisiones firmes y coherentes con su visión del comportamiento general del sistema.
Se encarga de describir y documentar la arquitectura valorando las alternativas y tomando en cuenta la calidad sistémica, los riesgos y la relación costo-beneficio.                          
La definición de los elementos, artefactos y relaciones entre todos ellos también es responsabilidad del arquitecto, racionalizando el uso de las tecnologías disponibles, reutilizando frameworks y amparándose en las mejores prácticas sobradamente estudiadas y probadas.
            Mantener la calidad de servicio integrando adecuadamente los requerimientos no funcionales de seguridad, sistemas externos, estableciendo canales de comunicación con ancho de banda adecuado, teniendo en cuenta las expectativas de crecimiento de volumen y modificaciones funcionales, garantizará el éxito del ímprobo trabajo de diseño al que se enfrenta el arquitecto.
Estilos de arquitectura
Traspasando la visión arquitectónica inicial del sistema, se determina el estilo o concepto descriptivo que define la forma de articulación más adecuada:
Flujo de datos: Enfatiza la reutilización y la modificabilidad. Apropiada sobre todo para sistemas que implementan transformaciones de datos en pasos sucesivos. Ejemplares de la misma serían las arquitecturas de tubería-filtros y las de proceso secuencial en lote.
Centrados en datos: Enfatiza la integrabilidad de los datos. Apropiada por lo tanto para sistemas que se fundan en acceso y actualización de datos en estructuras de almacenamiento. Sub-estilos característicos de la familia serían los repositorios, las bases de datos, las arquitecturas basadas en hipertextos y las arquitecturas de pizarra.
De llamada y retorno: La modificabilidad y la escalabilidad son sus principales características. Son los estilos más generalizados en sistemas en gran escala. Miembros de la familia son las arquitecturas de programa principal y subrutina, los sistemas basados en llamadas a procedimientos remotos, los sistemas orientados a objeto y los sistemas jerárquicos en capas.
Heterogéneos: Formas compuestas o indóciles a la clasificación en las categorías habituales. En este apartado podrían agregarse los sistemas de control de procesos industriales, sistemas de transición de estados, arquitecturas específicas de dominios, etc.
Peer – to – peer: También llamada de componentes independientes, enfatiza la modificabilidad por medio de la separación de las diversas partes que intervienen en la computación. Consiste por lo general en procesos independientes o entidades que se comunican a través de mensajes. Cada entidad puede enviar mensajes a otras entidades, pero no controlarlas directamente. Los mensajes pueden ser enviados a componentes nominados o propalados mediante broadcast. Miembros de la familia son los estilos basados en eventos, en mensajes, en servicios y en recursos.
De código móvil: Esta familia de estilos enfatiza la portabilidad. Ejemplos de la misma son los intérpretes, los sistemas basados en reglas y los procesadores de lenguaje de comando. Fuera de las máquinas virtuales y los intérpretes, los otros miembros del conjunto han sido rara vez estudiados desde el punto de vista estilístico. Los sistemas basados en reglas, que a veces se agrupan como miembros de la familia de estilos basados en datos, han sido estudiados por pocos científicos.
Código móvil
Su principal ventaja es que plantea una solución software a un problema causado por el hardware, simulando funcionalidades o capacidades no nativas en el hardware y software en que se implementan.
Dado que se reduce al lenguaje de programación, no siempre es aplicable como estilo.
Su principal función es virtualizar entornos operativos para reducir el vacío entre la máquina que espera la semántica del programa y la disponible físicamente.
Máquinas virtuales
Principalmente es un software capaz de emular una computadora y ejecutar programas como si fuera real. Fue definido a primera instancia como «un duplicado eficiente y aislado de una máquina física», pero actualmente no tienen por qué tener que ver con un hardware existente.
Su característica más destacable posiblemente sea la limitación que es capaz de proporcionar. Dado que es esta propia maquina la que indicara la limitación de los recursos que utilicen los programas ejecutados en ella.
El uso más primario y habitual de utilización de las maquinas virtuales es la de ejecución de un diferente Sistema Operativo, en uno ya arraigado en nuestro computador, con intención de probarlo o necesario para labores académicas o empresariales. Ejemplos hartamente utilizados en la carrera de Grado de Ingeniería Informática en la Universidad de Valencia para el manejo de maquinas virtuales son VirtualBox de Oracle y el VMWare, entre muchos otros existentes.
Son clasificables en dos grandes tipo por sus funcionalidades y su equivalencia con una maquina real:
Maquinas Virtuales de Sistema(System Virtual Machine): También denominadas maquinas virtuales de Harware. Son las más comunes dado que su función es multiplicar en maquinas virtuales (Con diferentes SOs) la maquina física subyacente. Con esa funcionalidad son claras las aplicaciones de estos softwares: Coexistencia de diferentes SOs, simulación de Hardware y consolidación de Servidores.
Maquinas Virtuales de Proceso(Process Virtual Machine): Ocasionalmente llamadas maquinas de aplicación se ejecutan como una aplicación normal en un solo SO y soporta tan solo un proceso. Su función es independizar la ejecución del proceso que corre en el del hardware y del SO anfitrión, ejecutándose por lo tanto de la misma forma en diferentes plataformas. El más claro ejemplo, dado el alto uso del lenguaje JAVA en programación, es la JVM (Java Virtual Machine), aunque nunca desprestigiar al todo poderos Microsoft con el CLR (Common Lenguaje Runtime) para el entorno .net.
            Una desventaja evidente de las maquinas virtuales es la complejidad que añaden a un proceso en tiempo de ejecución, haciendo así que sea algo más lento que si se ejecutara en el SO anfitrión directamente, pero pese a esto la gran flexibilidad que ofrece este entorno compensa generosamente esta deficiencia.
            Una parte muy importante, dado que se basa en ello para funcionar es el intérprete, estos términos -maquinas virtuales e intérpretes- suelen ser tomados como el mismo. Pero estos últimos son programas informáticos capaces de transformar el lenguaje de alto nivel en uno intermedio (bytecodes por ejemplo para la JVM) en vez de al propio lenguaje máquina (Principal diferencia con los compiladores), creando por lo tanto el proceso que se ejecutara dentro de la maquina virtual ya mencionada. Consta de cuatro partes: una máquina de interpretación que lleva a cabo la tarea, una memoria que contiene el seudo-código a interpretar, una representación del estado de control de la máquina de interpretación, y una representación del estado actual del programa que se simula.
Conclusión
            Pese a que la Arquitectura de Software ha recorrido un camino importante y el reconocimiento de su necesidad es generalizado en todo el mundo profesional dedicado al desarrollo de tecnologías de información y comunicación, todavía queda mucho por andar.
            Lejos de parecer un entorno libre y creativo al disfrutar de la ventaja circunstancial que proporciona la carencia de un criterio unificado con el que afrontar la definición de sistemas software, los dilemas de idoneidad, coherencia, seguridad, consistencia, fiabilidad, mantenibilidad, etc. no quedan ni resueltos ni garantizados, provocando el serio escenario que la Ingeniería Informática encuentra al no ejercer como tal en el mismo plano que el resto de Ingenierías.
            Deficiencias alentadas por desarrollos paralelos de conceptos descoordinados o antagónicos como los diferentes modelos y metodologías de desarrollo, la falta de un modelo que abarque todo el ciclo de vida de extremo a extremo, la enorme proliferación de estilos aportan más confusión que enriquecimiento al conjunto. Todo un cúmulo de circunstancias que no permiten la maduración de herramientas y lenguajes para el modelado puramente arquitectónico.
            Por su parte, el estilo de código móvil, nace para dotar de universalidad al trabajo ímprobo de diseño y desarrollo, desmarcándolo de su agónica dependencia de la evolución hardware, a la par que permite investigación sobre entornos con características ajenas al físicamente disponible y proporciona la congruencia necesaria en sistemas completos al hacerlos  encajables sobre entornos diferentes.
Bibliografía y webferencias
.. Arquitecturas Software – Juan José Moreno Navarro – UPM
.. Estilos y Patrones de Arquitectura – Carlos Reynoso y Nicolás Kicillof – UBA
.. Introducción a la Arquitectura de Software – Carlos Reynoso – UBA
.. Fundamentos de definición de Arquitectura de Software – Mauricio Naranjo – Lucasian Labs
.. Máquinas Virtuales (virtualización de hardware) – Sofía Ramos Ortíz
.. Estilos Arquitectónicos – Carlos E. Cuesta – URJC

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *