FIG.1: Modelo de Mc Call.
Para facilitar tanto la Revisión del Producto como la Transición de este se aconseja el uso de la arquitectura de software que mejor se adapte a las características funcionales y de comunicación, entre las unidades que la componen, de un problema a resolver. Esto significa que nuestro software debe ser fácil de entender. Una de las formas más comunes es dividir la complejidad del problema en módulos o paquetes independientes donde las tareas que realiza cada uno de ellos no dependa, en forma exagerada, de otros (bajo acoplamiento). Además las responsabilidades asociadas a cada módulo deben estar dentro de un dominio acotado y único, es decir, que estos sean altamente cohesivos.
Existen muchas formas de organizar el código coherentemente, en la literatura podemos encontrar arquitecturas de una, dos hasta n capas y nuestra elección dependerá del tipo de problema y la complejidad con la que se deba trabajar, además de considerar el tipo de comunicación entre los componentes o módulos involucrados dentro del sistema.
La arquitectura del software se define como un conjunto de patrones abstractos (ejemplos) que permiten dirigir y coordinar grandes sistemas de software. A través de una arquitectura se pueden desarrollar los conceptos y los planes de descomposición del software en unidades denominadas módulos. También se puede definir en forma ordenada la interacción y dependencia de cada módulo involucrado en la resolución del problema, también se definen las interfaces de uso y de comunicación con sistemas externos. Además, con una arquitectura clara, se pueden definir características de diseño innovadoras, operaciones sobre el negocio, lógica y flujos de alto nivel.
"La arquitectura del software es un mapa incompleto del sistema. La arquitectura del software describe los componentes del grano grueso (describe generalmente el cómputo) del sistema. Los conectores entre estos componentes describen la comunicación, que son explícitos y representados de una manera relativamente detallada. En la fase de la puesta en marcha, los componentes gruesos se refinan en "componentes reales", e.g, las clases y los objetos. En el campo orientado al objeto, los conectores se ponen en ejecución generalmente como interfaces." (Wikipedia)
Existen muchos tipos de arquitecturas, entre las más conocidas están:
- Cliente/Servidor
- Computación distribuida
- Sistemas Peer-to-peer
- Blackboard
- Invocación implícita
- Sistemas Monolíticos
- Modelo de tres capas (Three-tier model)
- Estructurado
- Arquitectura orientada al servicio
- etc.
En el DISC se adoptado una organización arquitectónica de tres capas, ya que es una arquitectura que funciona bastante bien en problemas de mediana complejidad y permite ser el referente inicial en la concepción o primeras etapas (fase de inicio) del desarrollo de un sistema de software.
FIG.2: Arquitectura de Tres Capas.
En la figura 2 se muestra en forma general el modelo de tres capas donde cada capa representa lo siguiente:CAPA PRESENTACIÓN: Son todos las clases especializadas en la construcción de la parte gráfica e interfaz hacia el usuario. La presentación puede ser desde una pantalla en modo caracter (consola) hasta aplicaciones visuales tanto a nivel de cliente gordo como de interfaces web. En la actualidad existen herramientas que facilitan la construcción de este tipo de interfaces. En Java existe awt, swing, jsp (servlet) y herramientas más completas como tapestry. En el mundo microsoft es posible encontrar estas facilidades con las tecnologías .NET. También es importante descatar herramientas emergentes como lazlo y ajax para el desarrollo de la capa de presentación.
Se debe siempre tener en cuenta que la capa de presentación permite visualizar los datos entregados por la capa lógica, es decir, la presentación no debería procesar datos. La ventaja de trabajar de esta forma se traduce en aplicaciones que no dependen de la interfaz a la hora de realizar cambios. Por ejemplo, hace un tiempo el grupo de tecnologías emergentes realizó una aplicación para mostrar las notas de los alumnos en cliente similar a los cajeros automáticos, el cual fue desarrollado en Java con el paquete gráfico swing. Nuestra interfaz de presentación solo utilizaba los datos enviados por la capa de presentación a través de estructuras de datos simples tales como listas o iteradores. al cabo de un tiempo se pidio que la misma aplicación corriera en Web para eso se creo una interfaz gráfica para dichos propósitos en jsp, el resultado final fue que solo se construyó la parte gráfica ya que todo lo demás (reglas de negocio y base de datos) se encontraba ya listo y desacoplado para ser re-utilizado. Al final del proyecto esto significó un ahorro sustancial en dinero y en recursos (además de un buen asado extra). En la figura 3, se observa dos tipos de presentaciónes diferentes (cliente gordo y Web), cada una de las presentaciones solicita un listado de notas a través del método entregarListadoNotas(rut:Rut):List el cual es pedido al controlador de la capa lógica, este responde a la petición con un conjunto de notas contenidos en una estructura de datos de tipo List (lista). Los datos son mostrados dependiendo de la interfaz que lo solicitó.
FIG.3: La capa de presentación pide a la capa lógica una acción (1), el resultado de esta acción es procesada y graficada por la capa de presentación.
CAPA LÓGICA: Esta capa controla el negocio, o por lo menos así lo habla la mayoría de la gente, y significa que aquí están todos los objetos que participan en el dominio del problema que se desea implementar, estos objetos saben que hacer cuando un alumno pide una nota en el caso de un problema en el dominio de una casa de estudios, de cuanta harina falta si mi dominio es una panadería, cuales son los clientes que no pagan una cuota en el caso de una empresa comercial, etc. Ejemplos hay muchos, lo importante es tener en cuenta que esta es la parte medular del desarrollo del software donde programo mis clases en Java, C#, Python, etc. Estas clases implementadas sobre el dominio del problema serán la base para dar vida a los objetos que contestarán a nuestras peticiones. Para el desarrollo existen una infinidad de técnicas, nosotros utilizamos un proceso iterativo e incremental para construir nuestras aplicaciones coorporativas y que nos han dados buenos resultados. Estamos en un proceso de maduración y con el tiempo ha sido mejorada.
Se debe tener en cuenta que la capa lógica debe considerar dos tipos de objetos que la implementan:
- Objetos Lógicos: Objetos de software que representan objetos del dominio del problema.
- Objetos de Servicio: Son objetos de propósito general y subsistemas que proporcionan servicios técnicos, tal como una interfaz para base de datos o bitácoras de errores. Son objetos no relacionados directamente con el problema pero prestan servicio de soporte a los objetos lógicos. Estos servicios por lo general son independientes de la aplicación y reusables en otros sistemas. Los objetos de servicio se pueden visualizar como intermediarios entre las distintas capas. Y tipo de objeto de servicio se denomina controlador y permite la comunicación entre capas.
CAPA PERSISTENCIA: Es un mecanismo que permite el almacenamiento a través del tiempo de los datos (persistente). Al igual que la capa de presentación es posible encontrar Framework que facilitan el trabajo de persistencia de la capa lógica, es decir, que los objetos logicos no tienen que saber como son almacenados ya que todo el trabajo de conversión y almacenaje de los datos son delegados a la capa de persistencia. Incluso existen aplicaciones que permiten hacer consultas, al igual que SQL, entre objetos. Entre las aplicaciones utilizadas por nuestra unidad se encuentra Persistencia4 (Desarrollado en el DISC), IBATIS, e Hibernate estos framework son desarrollados actualmente para Java. En el caso de .NET también se puede utilizar IBATIS y una versión adaptada de Hibernate llamada NHibernate.
Este breve post tiene objetivo mostrar la importancia del trabajo organizado en grupos de desarrollo de software, ya que el uso de estas técnicas permitirá el mejor manejo los de recursos involucrados en el proyecto, ya que la complejidad puede ser manejada mejor con el desarrollo de componentes más atómicos y especializados lo que permite una mejor distribución del trabajo y predicción del tiempo dedicado para cada una de las tareas.
El próximo post relacionado con este tema será uso de persistencia en .NET a través del Framework NHibernate.
Espero que les sirva y estoy atento a sus comentarios.
Juan Bekios.
Referencias:
- Wikipedia: http://216.239.39.104/translate_c?hl=en&langpair=en%7Ces&u=http://en.wikipedia.org/wiki/Software_architecture%23Architecture_examples -
- Apuntes de Ingeniería de Software, DISC, UCN.
- Repositorio de Papers. UCN.
Colaboradores:
- Luis Lobos Flores, Académico, DISC, UCN.
- Manuel Estay Meyer. Ingeniero de Software, Dirección de Informática, UCN.
Comentarios