Humberto Cervantes

Oportunidades de vinculación academia industria en temas de arquitectura de software

Ivett Sanchez — Tue, 03 Dec 2019 19:26:15 +0000

Oportunidades de vinculación academia industria en temas de arquitectura de software

Evento

REAL

Ivett Sanchez Tue, 12/03/2019 - 13:26

Conferencista(s)

Humberto Cervantes

Oportunidades de vinculación academia industria en temas de arquitectura de software de Software Guru

En esta charla se habla acerca de la deuda técnica y arquitectura

¿Usar o no Blockchain para mi Sistema?

sg — Mon, 03 Sep 2018 01:25:08 +0000

¿Usar o no Blockchain para mi Sistema?

sg Sun, 09/02/2018 - 20:25

Publicado en

SG #57

Arquitectura

Autor

Las cadenas de bloques (blockchain) son un mecanismo de almacenamiento de datos que fue creado para dar soporte a las necesidades que se planteó Bitcoin en el 2009 [1]. Sin embargo, posteriormente se descubrió que éste mecanismo puede tener múltiples aplicaciones que van mucho más allá de las criptomonedas. A partir de este momento las cadenas de bloques cobraron importancia y muchas empresas comenzaron a explorar su uso. El problema es que el uso de una cadena de bloques no siempre es una buena decisión. Gartner sugiere que el 90% de los proyectos empresariales basados en blockchain, lanzados entre 2016 y la primera mitad de 2017, fracasarán en un lapso de 24 meses [2]. Por esta razón, antes de comenzar un proyecto basado en esta tecnología, es necesario tomarse el tiempo de analizar las necesidades del proyecto para determinar si estas pueden ser cubiertas por un sistema de bases de datos tradicional o bien es necesario recurrir a las cadenas de bloques.

En este artículo presentamos una serie de criterios que ayudan a determinar cuándo tiene sentido almacenar datos en un blockchain. Para entender la manera en que se utiliza esta lista de criterios, los aplicamos en un ejemplo sencillo.

Parte 1. Criterios de decisión

A continuación enumeramos un conjunto de criterios, obtenidos a partir de [3] y [4], que son útiles para identificar si un proyecto es candidato a ser desarrollado usando la tecnología de cadena de bloques. Al final de cada criterio se incluye una pregunta que deben ser respondida para guiar en el proceso de toma de decisión. Cabe señalar que si se responde de manera afirmativa a todas las preguntas, entonces es muy probable que el sistema que se desea desarrollar se vea beneficiado por el uso de una cadena de bloques.

Necesidad de una base de datos

El primer paso es tener claras las necesidades de persistencia de datos. Si bien en la actualidad la gran mayoría de proyectos de software requieren una base de datos, esto no significa que tenga que implementarse con una cadena de bloques. Las bases de datos tradicionales han hecho un buen trabajo almacenando datos desde hace décadas, y en los últimos años han evolucionado significativamente para incorporar nuevas capacidades (ej. NoSQL). Así que la pregunta que debemos hacernos en este punto es: ¿En verdad es insuficiente una base de datos tradicional (relacional o no relacional) para cubrir las necesidades del proyecto?

Existencia de múltiples escritores

En muchos sistemas los cambios son realizados de forma centralizada o mediante una entidad que recibe peticiones y verifica si es posible hacer cambios en los datos y, de ser así, los lleva a cabo. En ciertos escenarios, sin embargo, es deseable que existan diversas entidades, o escritores, que sean capaces de modificar los datos de forma independiente. Si el sistema que se busca desarrollar tiene esta necesidad, entonces tal vez tenga sentido usar una cadena de bloques. Por lo anterior, debemos responder a la siguiente pregunta ¿Se pueden identificar múltiples escritores en el sistema a desarrollar?

Confidencialidad

En una base de datos tradicional tenemos la libertad de elegir mediante diferentes métodos a los usuarios que tienen derecho a ingresar a la información contenida en ella, incluso es posible asignar niveles de usuario con la finalidad de regular el acceso a los datos manteniéndolos seguros y confidenciales. Por otro lado, la transparencia de datos es una característica de las cadenas de bloques. Recordemos que una cadena de bloques almacena la información de las diferentes transacciones que se han realizado desde que esta se creó y que, además, existen múltiples réplicas de la misma que son usadas para verificar la validez de una transacción. En otras palabras, los nodos que poseen una réplica tienen acceso a la información ahí almacenada. Por lo anterior, si existen restricciones de confidencialidad que impliquen que la información no pueda estar replicada en varios nodos, es probable que la cadena de bloques no sea la mejor opción. Es necesario entonces responder a la pregunta ¿Los datos pueden ser replicados en varios nodos sin violar las restricciones de confidencialidad?

Rendimiento

Una de las principales limitaciones del almacenamiento en cadenas de bloques es que no pueden almacenar mucha información dentro de un bloque y tampoco son capaces de tolerar una alta demanda de transacciones. En consecuencia, si el proyecto de software requiere de almacenar grandes cantidades de datos además de un alto rendimiento, será necesario buscar alternativas para satisfacer esos requerimientos. Por ejemplo, en el blockchain se podrían guardar únicamente apuntadores a archivos almacenados independientemente. De esta forma se evita guardar mucha información en la cadena y potenciar el rendimiento. Por lo anterior, debemos preguntarnos ¿El sistema a desarrollar maneja una cantidad limitada de información y no requiere alto rendimiento?

Desconfianza

Anteriormente se había mencionado que una cadena de bloques soporta la existencia de múltiples escritores que pueden modificar directamente los datos. Es posible que ante esta situación exista desconfianza entre los escritores; es decir, si un escritor puede modificar entradas que le pertenecen a otro escritor o bien las propias a su conveniencia, existe desconfianza entre ellos. Si en el sistema que queremos desarrollar existe desconfianza entre los múltiples escritores, entonces el uso de una cadena de bloques es recomendable. Por lo anterior, debemos responder a la siguiente pregunta ¿Existe desconfianza entre los múltiples escritores que participan dentro del sistema?

Desintermediación

El problema de una base de datos distribuida con múltiples escritores que desconfían entre sí no es un problema nuevo. De hecho, existe una solución a este problema y son los intermediarios de confianza, es decir colocar un ente que funcione como regulador y validador de las transacciones que se realizan entre usuarios. En este caso es necesario que todos los usuarios del sistema confíen en que el intermediario realiza sus tareas sin preferencia por ningún usuario.

En las cadenas de bloques los nodos que poseen una réplica validan la integridad de la información y rechazan transacciones malintencionadas. Esta característica permite eliminar a los intermediarios de confianza. Por ejemplo, en la red de Bitcoin las transferencias no requieren de una institución bancaria que valide cada una de ellas. Por esta razón, las cadenas de bloques son útiles en proyectos donde se desea eliminar a los intermediarios de confianza o cuando no existe un intermediario que cumpla con los requerimientos del proyecto. En consecuencia, es importante responder a la pregunta ¿Se desea eliminar intermediarios de confianza?

Validadores

Una cadena de bloques como su nombre lo indica, es literalmente una serie de bloques encadenados entre sí; cada bloque contiene un conjunto de transacciones que le indican a todos los nodos de la red cuales son las transacciones válidas que se han realizado hasta el momento así como el orden cronológico en el que se realizaron. No todos los nodos tienen la capacidad de agregar un bloque a la cadena y, en consecuencia, es necesario especificar qué nodos se encargarán de esta tarea. Estos nodos llevan por nombre validadores o mineros y pueden ser elegidos de diferentes formas dependiendo el tipo de cadena de bloques. Por ejemplo en una cadena de bloques privada, los validadores pueden ser un grupo básico de nodos que mantengan la cadena, en contraste con la red de Bitcoin, donde un validador puede ser cualquier nodo con la capacidad computacional para realizar los cálculos requeridos por la red. Debemos entonces responder ¿Es posible identificar quiénes tomarían el papel de validadores en su sistema?

Reglas de validación

Independientemente de quiénes sean los validadores o qué algoritmo utilicen para llegar al consenso, el propietario de una copia de la base de datos debe seguir las reglas establecidas para determinar si una transacción es válida o no. En consecuencia se debe responder a la pregunta ¿Se tienen claras las reglas a seguir para determinar la validez de una transacción?

Dependencia entre transacciones

Hasta el momento sabemos que las cadenas que bloques se asemejan a una base de datos distribuida. En esta base de datos se almacenan bloques que contienen un cierto número de transacciones, cada bloque nuevo que se crea se enlaza al anterior creando una cadena de bloques y permitiendo que las diferentes transacciones que se realizan tengan un orden cronológico entre ellas. Esta característica permite tomar una decisión cuando dos transacciones dependen una de otra, por ejemplo: Suponga que el individuo A desea transferir $50 al individuo B y luego el individuo B los transfiere al individuo C, la transferencia del individuo B al C depende de la transferencia que realizó el individuo A al B, ya que si no se realiza en el orden correcto la transferencia del individuo B al C sería rechazada por falta de fondos, podríamos decir entonces que esta serie de transacciones son dependientes. Las cadenas de bloques soportan dependencia entre transacciones. Debemos entonces preguntarnos ¿El sistema involucra transacciones que sean dependientes?

Inmutabilidad e historia

Una de las principales ventajas que nos proporciona una cadena de bloques es la inmutabilidad de los datos. Gracias a esta característica los nodos pueden confiar en que la información almacenada en ella es confiable y no ha sido modificada a conveniencia de algún nodo en particular. Anteriormente se comentó que existe desconfianza entre los diferentes nodos que conforman la red, pero esto no quiere decir que no exista un ente de confianza. La confianza se traslada a la cadena de bloques y es ella quien indica cuales son las transacciones válidas.

La inmutabilidad de la cadena permite generar la historia de los datos; es decir, debido a que los datos que pertenecen a la cadena de bloques no pueden cambiar, es fácil rastrear la evolución de un dato. De hecho, muchas de las aplicaciones que existen actualmente en el mercado explotan esta característica de las cadenas de bloques (por ejemplo rastrean origen de oro, diamantes, alimentos, etc.). Por lo anterior, podemos hacernos la pregunta siguiente ¿El sistema requiere que los datos sean inmutables?

Parte 2. Ejemplo

Con la intención de mostrar de manera práctica cómo utilizar el cuestionario descrito anteriormente, analizaremos si es pertinente utilizar las cadenas de bloques para implementar un sistema de manejo de inventario de bienes de inversión.

Consideremos una institución académica donde la adquisición de algún bien material (computadoras, escritorios, sillas, etc) involucra la realización de una petición por escrito al Departamento de Administración indicando información personal, el bien solicitado y el costo del mismo; posteriormente la solicitud es enviada al Departamento de Patrimonio en donde se revisa y se autoriza la solicitud para después ser enviada a la Coordinación de Servicios Administrativos en donde es revisada nuevamente y enviada al Departamento de Proveeduría, es aquí donde se realiza la compra del bien y una vez que el bien es recibido se notifica al solicitante para que pueda acudir a retirarlo. En cuanto el bien es retirado por la persona que lo solicitó queda bajo su resguardo y a partir de este momento esta persona es responsable del bien material así como de su buen uso. Un proceso similar se lleva a cabo para dar de baja un bien por pérdida o descompostura. Existe un caso especial en donde un trabajador tiene el resguardo de cierto material y decide transferirlo a otro empleado. Este proceso se considera un traspaso de bienes y es realizado de forma similar al proceso de alta. La institución desea implementar un sistema de manejo de inventario que se ejecute en distintos dispositivos y que gestione de manera eficiente y segura los procesos descritos anteriormente.

A continuación analizaremos cada uno de los puntos mencionados anteriormente en el contexto del problema planteado.

	Pregunta	Respuesta	Justificación
a)	¿Una base de datos tradicional (relacional o no relacional) es insuficiente para cubrir las necesidades del proyecto?	SI	- Existe la necesidad de eliminar intermediarios - Se desea que el sistema sea descentralizado para aumentar la disponibilidad
b)	¿Se pueden identificar múltiples escritores en el sistema a desarrollar?	SI	- Los escritores en el proyecto son el trabajador y proveeduría, ya que los demás serían innecesarios una vez implantada la solución
c)	¿Es posible que los datos se encuentren replicados en diversos nodos?	SI	- No se tienen limitaciones en cuanto al hecho de que la información sea confidencial y no pueda estar replicada en distintos nodos
d)	¿El sistema a desarrollar soporta un manejo de una cantidad limitada de información y no requiere alto rendimiento?	SI	- La cantidad de transacciones no es elevada y el manejo de inventario no requiere en este caso de grandes volúmenes de información
e)	¿Existe desconfianza entre los múltiples escritores que participan dentro del sistema?	SI	- Un trabajador podría, por ejemplo, modificar la base de datos para simular un traspaso sin que este se realice realmente
f)	¿Se desea eliminar intermediarios de confianza?	SI	- Los únicos participantes deberían ser los trabajadores y proveeduría, los demás intermediarios que participan actualmente en el proceso pueden ser eliminados.
g)	¿Es posible identificar quienes tomarían el papel de validadores en su sistema?	SI	- No sería una buena idea forzar a que cada usuario (nodo) que utilice el sistema tenga que ser un validador. La alternativa más viable sería designar a un grupo de nodos encargados de la escritura de la cadena de bloques.
h)	¿Se tienen claras las reglas a seguir para determinar la validez de una transacción?	SI	- Las reglas para que un usuario adquiera y se libere del resguardo de un bien están claras.
i)	¿El sistema involucra transacciones que sean dependientes?	SI	- Por ejemplo, no es posible realizar una transacción de traspaso entre trabajadores si previamente no existe una transacción que involucre la recepción del bien por parte del trabajador que traspasa el bien
j)	¿El sistema requiere que los datos sean inmutables?	SI	- Es necesario conocer las distintas transacciones que han ocurrido a lo largo de la vida útil de un bien

A partir de este análisis, es posible concluir que este sistema sí se vería beneficiado por el uso de una cadena de bloques.

Conclusiones

Las cadenas de bloques son una de las tecnologías que ha cobrado mayor popularidad en los últimos años, sin embargo muchos de los proyectos que utilizan cadenas de bloques son iniciados de manera apresurada y sin detenerse a pensar si es realmente necesario el hacer uso o no de dicha tecnología. Responder a la serie de preguntas que presentamos aquí es un ejercicio que conviene hacer antes de lanzarse en un proyecto que haga uso de una cadena de bloques con el fin de reducir las posibilidades de tomar una mala decisión.

Referencias

S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System”. https://bitcoin.org
P. Christy, “7 Strategies to Gain Value From a Doomed Blockchain Project”. Smarter with Gartner. http://swgu.ru/wp
S. K. Lo, X. Xu, Y. K. Chiam & Q. Lu, “Evaluating suitability of applying blockchain” International Conference on Engineering of Complex Computer Systems (ICECCS), pag. 158-161, IEEE, 2017.
G. Greenspan, “Avoiding the pointless blockchain project”. http://swgu.ru/wq

Bio

El Lic. Carlos Solís realiza la maestría en Ciencias y Tecnologías de la Información en la UAM-Iztapalapa, centrando su investigación en las cadenas de bloques y los retos que estas implican en la ingeniería de software.

La Dra. Elizabeth Pérez Cortés es profesora-investigadora en la UAM-Iztapalapa. Realiza docencia e investigación en Sistemas Distribuidos, en particular en bases de datos distribuidas, sistemas par a par, datos abiertos enlazados y esquemas de incentivos. Ha dirigido diversas tesis de posgrado en los tópicos mencionados y realizado estancias de investigación en Francia, Colombia y Japón.

El Dr. Humberto Cervantes es profesor-investigador en la UAM-Iztapalapa. Además de realizar docencia e investigación dentro de la academia en temas relacionados con arquitectura de software, realiza consultoría y tiene experiencia en la implantación de métodos de arquitectura dentro de la industria. Ha recibido diversos cursos de especialización en el tema de arquitectura de software en el SEI, y está certificado como ATAM Evaluator y Software Architecture Professional por parte del mismo. (www.humbertocervantes.net)

Designing Software Architectures: A Practical Approach

sg — Wed, 12 Oct 2016 08:14:37 +0000

Designing Software Architectures: A Practical Approach

sg Wed, 10/12/2016 - 03:14

Publicado en

SG #52

Arquitectura

Autor

Humberto Cervantes

En esta ocasión tengo el gusto de compartir con ustedes la noticia de la reciente publicación del libro que escribí junto con mi colega Rick Kazman quien es investigador en el Software Engineering Institute (SEI). Nuestro libro lleva por título “Designing Software Architectures - A Practical Approach” (Diseñando Arquitecturas de Software - Un Enfoque Práctico) y fue publicado por la editorial Addison Wesley en la colección “SEI Series in Software Engineering”.

Nuestro libro se enfoca en el método de Diseño Guiado por Atributos (Attribute-Driven Design), o ADD; un método de diseño de arquitecturas originalmente creado por el Software Engineering Institute y del cual hablé en la columna “Diseño de la Arquitectura”, en SG 29. A pesar de que ADD ha existido por más de una década, se ha escrito relativamente poco al respecto y es difícil encontrar ejemplos de cómo llevarlo a cabo. Esta falta de información ha complicado su adopción y enseñanza. Además, la información que se ha publicado acerca de ADD tiende a ser un tanto abstracta y puede ser difícil conectarla con los conceptos, prácticas y tecnologías que los arquitectos usan en sus actividades cotidianas.

Rick y yo hemos guiado a arquitectos de software durante años en la realización del proceso de diseño y, al mismo tiempo, hemos estado aprendiendo de ellos; por ejemplo, que en la práctica los arquitectos consideran la tecnología de forma temprana en el proceso de diseño y esto es algo que no era parte de la versión original de ADD. Por tal razón, el método original parecía “desconectado” de la realidad para la gente de la industria. En este libro presentamos una versión revisada de ADD en la cual hemos tratado de reducir la brecha entre la teoría y la práctica.

Durante varios años, hemos estado también enseñando arquitectura de software y la manera en que se realiza el diseño de la misma. Nos hemos dado cuenta que a la gente que no tiene experiencia le es muy difícil diseñar arquitecturas. Este entendimiento nos empujó a crear una “hoja de ruta” que creemos será útil para guiar en la realización del proceso de diseño. También creamos un juego que es útil para enseñar acerca del diseño de arquitecturas, y que se puede considerar como un complemento al libro (ver “Smart Decisions: Un juego para aprender Arquitectura y Big Data” en SG 49).

Nuestro libro está dirigido a cualquier persona que esté interesada en el diseño de arquitecturas de software. Creemos que será particularmente útil para los practicantes que deben realizar esta tarea, pero que actualmente la realizan de forma ad hoc. Los practicantes con experiencia que ya realizan el diseño siguiendo un método establecido también encontrarán nuevas ideas, por ejemplo, cómo dar seguimiento al proceso de diseño usando un tablero Kanban o cómo analizar el diseño usando cuestionarios basados en tácticas. Por último, la gente que está familiarizada con otros métodos del Software Engineering Institute encontrarán información acerca de la manera de combinar ADD con métodos tales como el taller de atributos de calidad QAW, el método de análisis de compromisos arquitectónicos ATAM (ver SG 31) y el método de análisis de costos beneficios CBAM.

Este libro también será útil para estudiantes y profesores de programas de ciencias de la computación o de ingeniería de software. Creemos que los casos de estudio que describimos ayudarán a entender a través de ejemplos la manera de realizar el proceso de diseño más fácilmente. Como dijo Einstein: “El ejemplo no es otra manera de enseñar, es la única manera de enseñar”.

Esperamos que nuestro libro permita entender que el diseño puede realizarse siguiendo un método y que el hacerlo de esta manera es de gran ayuda para producir mejores sistemas de software.

Su estructura es de la siguiente manera siguiente:

En el capítulo 1 presentamos una introducción breve del concepto de arquitectura de software y del método ADD.
En el capítulo 2 discutimos acerca del diseño de arquitecturas de manera más detallada, junto con las entradas principales al proceso de diseño a las cuales llamamos los drivers de la arquitectura. Además, hablamos de los conceptos de diseño que son ‘bloques de construcción’ a partir de los cuales se construye la arquitectura y que permiten satisfacer estos drivers usando soluciones probadas.
El capítulo 3 presenta el método ADD de forma detallada. Presentamos cada uno de los pasos del método junto con varias técnicas que pueden ser usadas para llevar a cabo estos pasos de manera adecuada.
El capítulo 4 presenta un primer caso de estudio que ilustra el desarrollo de un sistema “desde cero”. Para este caso de estudio, hemos hecho un esfuerzo por mostrar la manera en que la mayoría de los conceptos descritos en el capítulo 3 son usados en el proceso de diseño, así que este caso de estudio tiene una naturaleza más “académica” (aunque se deriva de un sistema del mundo real).
El capítulo 5 presenta un segundo caso de estudio que escribimos junto con arquitectos de software expertos en big data y, por ello, tiene muchos más detalles técnicos que el anterior. Este caso de estudio describe los detalles finos de cómo usar ADD en el diseño de un sistema de big data que involucra diversas tecnologías. Este ejemplo ilustra también lo que consideramos un diseño en un dominio “novedoso”, a diferencia del dominio más tradicional usado en el capítulo 4.
El capítulo 6 es un caso de estudio más corto que describe el uso a ADD para realizar la extensión de un sistema legado, lo cual es una situación común en la práctica. Este ejemplo demuestra que el diseño arquitectural no es algo que se realice una sola vez, al inicio del desarrollo del sistema, sino que más bien es una actividad que puede ser realizada en distintos momentos del proceso de desarrollo.
El capítulo 7 presenta otros métodos de diseño. En nuestra revisión de ADD, adoptamos ideas de otros autores que también han investigado el proceso de diseño y aquí resumimos brevemente sus enfoques como un homenaje a sus propuestas y como una comparativa de ADD a estos métodos.
El capítulo 8 discute acerca del tema del análisis de forma detallada. Aún si el tema principal de este libro es el diseño, el análisis se realiza naturalmente como parte del mismo, así que aquí describimos técnicas de análisis que pueden ser usadas durante el proceso de diseño o después de que una parte del diseño ha sido completada. En particular, describimos el uso de cuestionarios basados en tácticas, los cuales son útiles para entender de forma simple y rápida las decisiones que se realizan durante el proceso de diseño.
El capítulo 9 describe la manera en que el proceso de diseño embona a nivel organizacional. Por ejemplo, es posible realizar cierta cantidad de diseño en los momentos más tempranos del ciclo de vida con el fin de realizar la estimación del proyecto (ver “Arquitectura y Preventa” en SG 46). Mostramos también cómo ADD puede ser usado con distintos enfoques de desarrollo, como por ejemplo, con las metodologías ágiles o con métodos más establecidos como el Team Software Process (TSP).
El capítulo 10 concluye el libro.

Incluímos también dos apéndices. El A presenta un “catálogo de conceptos de diseño” que, como su nombre indica, es un catálogo de distintos tipos de conceptos de diseño que pueden ser usados para un dominio aplicativo particular (ver “Conceptos de Diseño: Patrones, Tácticas y Frameworks” en SG 38). Este catálogo presenta conceptos de diseño que recopilamos de distintas fuentes y refleja la manera en que los arquitectos con experiencia trabajan en el mundo real. En este caso, el catálogo contiene una muestra de conceptos de diseño usados en el caso de estudio presentado en el capítulo 4. El apéndice B provee un conjunto de cuestionarios basados en tácticas para los siete atributos de calidad más comunes, así como un cuestionario adicional para DevOps.

Conclusión

Debo decir que me llena de orgullo el haber escrito un libro para la prestigiosa colección editorial del Software Engineering Institute que, además, es el nuevo material de referencia para el curso “Software Architecture Design and Analysis” que se imparte en el SEI. Espero que sea de mucha utilidad para la comunidad de desarrollo en México y en el resto del mundo.

Quiero aprovechar para agradecer a Pedro Galván y su equipo por la oportunidad que me han dado a lo largo de estos años de escribir esta columna de arquitectura de software. Como se puede apreciar en las distintas referencias que hice a números pasados de la revista, muchos de los temas desarrollados de forma detallada en el libro han sido presentados de forma resumida a lo largo de los años en esta columna.

Para terminar, incluyo una liga en donde se puede adquirir el libro: https://goo.gl/Wd01TL

Bio

Smart Decisions: Un juego para aprender arquitectura y big data

sg — Wed, 23 Dec 2015 03:14:56 +0000

Smart Decisions: Un juego para aprender arquitectura y big data

sg Tue, 12/22/2015 - 21:14

Publicado en

SG #49

Arquitectura

Autor

Humberto Cervantes

En esta ocasión les hablaré de Smart Decisions, un juego que he desarrollado junto con mis colegas Rick Kazman del Software Engineering Institute (SEI) así como Serge Haziyev y Olha Hrytsay de la empresa Softserve. El objetivo del juego es ilustrar la manera en que se realiza el diseño de la arquitectura mediante el método de diseño Attribute Driven Design (ADD). Como parte del juego, se simula el diseño de un sistema de Big Data.

Comenzaremos recordando el método de diseño ADD y después hablaremos acerca de los detalles del juego incluyendo un enlace para descargar los materiales y jugarlo.

Repaso: diseño de arquitectura

La actividad de diseño de la arquitectura (ver SG29) se enfoca en la traducción de drivers, hacia un conjunto de estructuras que conforman la arquitectura. Recordemos que los drivers incluyen requerimientos funcionales primarios, atributos de calidad y restricciones (ver SG28).

Attribute Driven Design

La transformación antes mencionada se puede realizar de manera sistemática usando el método de diseño Attribute Driven Design (ADD). ADD es un método iterativo de diseño de arquitecturas de software. El método consta de siete pasos que se muestran en la figura 1.

Figura 1. Pasos del método de diseño ADD.

Las actividades son las siguientes:

El arquitecto se asegura de que tiene una buena comprensión acerca de los drivers que se usan como entradas al proceso de diseño.
Se elige el subconjunto de drivers que serán tratados en la iteración.
El diseño procede mediante el refinamiento de uno o más elementos que son elegidos en este paso. El refinamiento puede involucrar la descomposición de un elemento en subelementos y sus relaciones, o bien puede involucrar diseño adicional de elementos previamente identificados. Al inicio del proceso de diseño de sistemas ‘greenfield’ (desde cero), el único elemento que puede ser elegido es el sistema mismo, que es concebido como un único elemento. En iteraciones subsecuentes, o en el diseño de cambios a un sistema existente, se eligen uno o más elementos previamente definidos.
Este paso involucra la identificación y selección de conceptos de diseño, que describiremos a continuación, que permitirán satisfacer los drivers elegidos para la iteración
Una vez que los conceptos de diseño han sido elegidos, los elementos que se derivan son identificados y conectados. En este paso es donde nuevas estructuras se crean o estructuras existentes se refinan. Adicionalmente, las responsabilidades de los elementos se establecen y las interfaces expuestas por los elementos se definen.
A pesar de que la documentación formal ocurre después del proceso de diseño, cierta información debe registrarse durante el diseño, cuando aún se encuentra fresca en la mente del arquitecto y hay menos probabilidad de que la olvide. En este paso se registra dicha información que incluye bosquejos de las estructuras creadas en el paso previo junto con decisiones de diseño y su justificación (rationale).
En este paso, el arquitecto realiza un análisis de las decisiones de diseño que fueron realizadas durante la iteración y también del proceso de diseño en su conjunto. Como resultado, se toma la decisión de seguir realizando más iteraciones o de parar el diseño y de proceder a la implementación.

Conceptos de diseño

En el paso 4 del método ADD se eligen conceptos de diseño, que son los “bloques de construcción” del diseño de la arquitectura (ver SG46). Estos bloques son soluciones probadas a problemas recurrentes de diseño y pueden ser de naturaleza conceptual o concreta. Los tipos de conceptos de diseño que se consideran incluyen: arquitecturas de referencia, patrones, tácticas, familias tecnológicas y productos o frameworks.

Una de las dificultades que existen al momento de diseñar una arquitectura de software es la selección de conceptos de diseño. Existen cientos de patrones y tecnologías de dónde escoger y, además, la selección es complicada pues frecuentemente no es sencillo entender la influencia que puede tener un concepto de diseño particular sobre los atributos de calidad del sistema. Por ejemplo, cierta tecnología, ¿impacta o favorece el desempeño?

Como se puede apreciar, el diseño de arquitecturas de software no es una tarea sencilla, sin embargo, el uso de un método como ADD permite realizar esta actividad de manera sistemática lo cual aumenta las posibilidades de obtener un mejor resultado.

Smart Decisions

Dada la importancia de diseñar arquitectura siguiendo un método como ADD, decidimos desarrollar un juego cuyo objetivo es ilustrar conceptos importantes asociados con el diseño de arquitectura. Está diseñado para jugarse tanto por estudiantes como por practicantes que no tengan mucha experiencia en el diseño de arquitecturas. Cabe señalar que el juego no busca sustituir a los cursos de diseño de arquitectura, sino más bien, busca ser un complemento a los mismos.

Algunos de los conceptos principales que son ilustrados en el juego son los siguientes:

El diseño arquitectural se desarrolla de manera iterativa y puede realizarse de manera sistemática usando un método como ADD.
El diseño arquitectural comienza con drivers e involucra realizar decisiones de diseño. Algunas de estas decisiones incluyen elegir conceptos de diseño, lo cual generalmente es complicado, sobre todo para los diseñadores que se enfrentan con una “página en blanco” al iniciar el diseño.
Todo concepto de diseño tiene una influencia sobre los drivers y, más específicamente, sobre los atributos de calidad.
Las decisiones de diseño tienen consecuencias: algunas decisiones son mejores (de ahí que el juego se llame “Smart Decisions”) y algunas no lo son tanto. Por otro lado, las decisiones que se hacen en una iteración pueden tener consecuencias en iteraciones posteriores.
Las decisiones de diseño deben ser registradas y analizadas como parte del proceso de diseño.

Smart Decisions requiere un mínimo de dos jugadores y un máximo de seis. Los jugadores pueden ser individuos o grupos de individuos. Adicionalmente, requiere de un facilitador que explique el contexto y la mecánica del juego. El juego se juega en una serie de rondas que representan distintas iteraciones del proceso de diseño de un sistema nuevo (greenfield).

En la primer iteración, el facilitador describe la manera en que los pasos de ADD se llevan a cabo en el juego. Como parte de la explicación inicial, el facilitador presenta también el contexto del juego, es decir, la descripción de los drivers del sistema que se va a diseñar. Actualmente, Smart Decisions cuenta con un contexto de juego de un sistema de Big Data, sin embargo, está diseñado para ser extensible y que en el futuro se puedan agregar contextos de juego relacionados con otros dominios aplicativos.

Para cada iteración, el juego proporciona la siguiente información, que equivale a lo que se obtendría de los pasos 2 y 3 de ADD:

Objetivo de la iteración.
Drivers a considerar.
Elemento a refinar.
Alternativas de conceptos de diseño a considerar.

A continuación, los jugadores deben elegir conceptos de diseño a partir de las alternativas que se les proponen. Esto representa la actividad que se realiza en el paso 4 de ADD y es la parte medular del juego. Los conceptos de diseño se presentan como un conjunto de cartas y cada una de estas cartas contiene información acerca de un concepto de diseño particular (ver figura 2). La información que se presenta en la carta incluye un nombre, un diagrama (si aplica), una descripción y una lista de drivers así como la influencia del concepto de diseño sobre los mismos. La influencia se mide mediante puntos, que están representados como estrellas. Un punto significa que el concepto de diseño no contribuye mucho a satisfacer el driver mientras que tres puntos significa que el concepto de diseño contribuye en gran medida para satisfacer el driver.

Figura 2. Tarjeta de un concepto de diseño relacionado con Big Data.

Una vez que los jugadores han elegido una carta, calculan un total en base a la influencia del concepto de diseño seleccionado sobre los drivers asociados a la iteración. Después de eso, simulan el paso 5 de ADD tirando dos dados. Respecto al paso 6 de ADD, como parte del juego no se realizan bosquejos del diseño, pero sí se documentan las decisiones de diseño, es decir los conceptos de diseño elegidos.

El paso 7 de ADD es guiado por el facilitador quien describe cuáles eran las opciones más apropiadas a elegir como parte de las iteraciones. Dependiendo de lo elegido, los jugadores reciben puntos adicionales o bien son penalizados. Para cada iteración se calcula un puntaje total que combina los puntos de las cartas elegidas, el resultado de tirar los dados y los bonos o penalizaciones resultantes del análisis. Al final del juego, se suman los puntos recibidos en las distintas iteraciones y se calcula un total. El jugador con el total más alto gana.

Una vez que termina el juego, el facilitador promueve una discusión con los participantes con el fin de intercambiar experiencias y opiniones relativas al juego y al proceso de diseño de arquitecturas en general. Esta discusión es un aspecto fundamental dentro de las sesiones de juego.

Conclusión

Smart Decisions es un juego que busca ilustrar el proceso que se sigue para diseñar arquitecturas de software usando ADD. Actualmente, el juego dispone de contenido enfocado al diseño de un sistema de Big Data, pero en el futuro esperamos disponer de otros contextos de juego. Hemos tenido la oportunidad de realizar sesiones de juego con diversas poblaciones que incluyen arquitectos de software, profesores y también con estudiantes(1). A raíz de estas sesiones, hemos recibido retroalimentación muy positiva acerca del juego.

Por último, cabe señalar que el juego está disponible de forma gratuita en http://www.smartdecisionsgame.com

Los invitamos a que lo descarguen, lo jueguen y nos den su opinión al respecto. Adicionalmente, estamos buscando contribuciones de la comunidad para generar otros contenidos en áreas distintas a Big Data.

Referencias

Cervantes, H., Haziyev, S., Hrytsay, O., Kazman, R. “Smart Decisions: An Architecture Design Game”, http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=436542, SATURN Conference 2015.

Bio

Seguridad y uso de Frameworks

sg — Mon, 25 May 2015 05:17:36 +0000

Seguridad y uso de Frameworks

sg Mon, 05/25/2015 - 00:17

Publicado en

SG #47

Arquitectura

Autor

En esta ocasión resumiré un trabajo que presenté en la conferencia SATURN 2014 de arquitectura de software junto con mis colegas Rick Kazman y Jungwoo Ryoo. Rick Kazman es investigador del Software Engineering Institute y académico en la Universidad de Hawaii. Jungwoo Ryoo es investigador de la Universidad del estado de Pennsylvania y experto en temas de seguridad. Cabe señalar que la conferencia SATURN, organizada por el SEI, está enfocada a los practicantes y que este trabajo fue muy bien recibido por dicha comunidad, por lo que considero que puede ser de interés para los lectores de esta columna.

Enfoque arquitectónico hacia la seguridad

La seguridad del software es una preocupación cada vez más importante para las organizaciones. Sin embargo, pocos arquitectos abordan este atributo de calidad de manera estratégica. Los arquitectos y desarrolladores frecuentemente ponen un énfasis mayor en satisfacer los requerimientos funcionales, y la seguridad usualmente es aplicada como un “parche” durante o después de que la aplicación ha sido desarrollada.

Desarrollar código enfocado a la seguridad es una tarea compleja y, por ello, frecuentemente se recurre a la adopción y uso de frameworks que se enfocan en atender distintas áreas de la seguridad como pueden ser el control de acceso, el cifrado y la validación de entradas entre otras.

Podemos identificar tres enfoques relativos a la adopción de frameworks como parte del diseño de la arquitectura para resolver la seguridad:

No adopción: La seguridad no es considerada dentro del diseño de la arquitectura y solamente se codifican soluciones ad-hoc para tratar aspectos de seguridad.
Adopción parcial: Se introducen frameworks de seguridad después del diseño inicial de la arquitectura.
Adopción completa: La seguridad es considerada dentro del diseño inicial de la arquitectura y parte de las decisiones del diseño incluyen el uso de frameworks enfocados a la seguridad.

Caso de estudio

Con el fin de comprender las consecuencias de los tres enfoques descritos anteriormente, realizamos un estudio sobre tres distintos sistemas empresariales accesibles vía web:

Sistema 1. Un sistema de administración de registros médicos de fuente abierta llamado OpenEMR [1]. Desarrollado en PHP y representa el enfoque de no adopción.
Sistema 2. Un portal web desarrollado usando HTML y JSP. En un principio utilizaba un enfoque de no adopción y posteriormente se decidió agregar una solución comercial para mitigar riesgos de seguridad en el código, aplicando así un enfoque de adopción parcial. Nos referiremos a éste como “Sistema 2 Antes” y “Sistema 2 después”.
Sistema 3. Una aplicación interna programada en Java por una empresa mexicana. Este sistema representa el enfoque de adopción completa. Utiliza Spring security [2] como framework primario de seguridad pero también utiliza el framework ZK [3] en la capa de presentación, que también brinda protección de ataques comunes en esta capa.

Estos sistemas fueron analizados utilizando la herramienta IBM AppScan que analiza alrededor de 33 tipos distintos de vulnerabilidades tales como inyección de SQL, negación de servicio o indexado de directorios. La herramienta genera un reporte de resultados indicando la cantidad de vulnerabilidades identificadas, agrupadas por severidad. El análisis se enfocó únicamente en los aspectos de software, por lo que se deshabilitó hardware de seguridad tal como firewalls.

Adicionalmente se realizó una entrevista a los arquitectos de los distintos sistemas para entender los enfoques de seguridad que siguieron. Estas entrevistas se basaron en la lista de 17 tácticas de seguridad que se muestra en la Figura 1. Para cada una de las tácticas se le preguntó al arquitecto si la había considerado y, en caso afirmativo, qué medidas había tomado al respecto.

Figura 1: Categorización de tácticas de seguridad.

Resultados

La tabla 1 presenta un resumen del resultado del análisis sobre los distintos sistemas.

Como se puede observar de la tabla, los enfoques de adopción parcial y completa tienen los mejores resultados ya que ninguno de estos sistemas exhibió vulnerabilidades de severidad alta. En el caso del sistema 2, llama la atención que al introducir un framework de seguridad se eliminaron por completo las vulnerabilidades de severidad alta, y las medianas se recortaron a la mitad.

Por otro lado podemos apreciar que, a excepción del sistema 3, en los demás casos una parte de las tácticas fueron implementadas mediante programación ad-hoc, y no usando frameworks u otros mecanismos externos. Podemos observar una relación entre el esfuerzo que estimaron los arquitectos para satisfacer aspectos de seguridad y el número de tácticas implementadas de manera ad-hoc.

Como era de esperarse, el enfoque de adopción completa resultó ser el mejor ya que el sistema en que se usó, es decir el sistema 3, no tuvo vulnerabilidades de severidad alta, y el esfuerzo que el arquitecto estimó haber dedicado a atender aspectos de seguridad fue bajo en comparación con los demás sistemas, además de que este fue el sistema en el cual se implementó la mayor cantidad de tácticas.

Consideraciones

La muestra de sistemas que se usó para este estudio es muy pequeña y esto impide llegar a conclusiones definitivas. Sin embargo, y a pesar del tamaño de la muestra, los resultados obtenidos permiten emitir la recomendación siguiente: la seguridad es un atributo de calidad que no se debe dejar “para después” y es conveniente elegir frameworks como parte de las decisiones de diseño de la arquitectura.

El uso de frameworks tiene sentido pues quien desarrolla una aplicación para un dominio particular generalmente no es un especialista en temas de seguridad. Por otro lado, intentar desarrollar código ad-hoc para satisfacer aspectos de seguridad consume recursos valiosos del proyecto que podrían más bien estar enfocados en resolver la problemática de negocio.

Las únicas dificultades asociadas con el uso de frameworks para manejar la seguridad son las posibles curvas de aprendizaje asociada con los frameworks, y la necesidad de mantener actualizados los frameworks para estar al día respecto a las nuevas amenazas que aparecen con el tiempo.

Es conveniente, además, atender la seguridad usando una combinación de software y hardware como, por ejemplo, cortafuegos.

Una recomendación adicional es que al diseñar la arquitectura de un sistema, conviene tomar el catálogo de tácticas mostrado en la figura 1 a manera de checklist para asegurarnos que estamos cubriendo las distintas tácticas de seguridad.

Conclusión

La seguridad es un aspecto de gran importancia en la mayoría de las aplicaciones y es por ello que se le debe dar una consideración primordial como parte del diseño de la arquitectura. El considerar la seguridad desde el principio y usar frameworks para soportarla puede dar excelentes resultados.

Aprovecho este espacio para comentarles que estamos buscando más casos de estudio por lo cual si están interesados en que alguna de sus aplicaciones empresariales forme parte de este estudio no duden en contactarme en hcm@xanum.uam.mx. Los resultados del análisis y los datos de su organización serán confidenciales.

En la http://goo.gl/cZUIi5 pueden encontrar un video de la presentación de este trabajo realizada en SATURN 2014.

En http://goo.gl/plbwrJ pueden encontrar una lista de frameworks de seguridad (en constante evolución).

Referencias

Bass, Clements y Kazman, “Software Architecture in Practice”, 3a Edición, Addison-Wesley Professional, 2012.

Bio

El Dr. Humberto Cervantes es profesor-investigador en la UAM-Iztapalapa y consultor independiente especializado en arquitectura de software. Está certificado como ATAM Evaluator y Software Architecture Professional por parte del Software Engineering Institute.

Arquitectura y Preventa

sg — Tue, 16 Dec 2014 21:45:51 +0000

Arquitectura y Preventa

sg Tue, 12/16/2014 - 15:45

Publicado en

SG #46

Arquitectura

Autor

Humberto Cervantes

En esta ocasión hablaré acerca del uso de técnicas de desarrollo de arquitectura de software como parte de la etapa de preventa de los proyectos de software.

Por preventa me refiero a la etapa que ocurre cuando se hace una propuesta de solución para desarrollar un sistema de software. El cliente típicamente solicita propuestas a varios proveedores, da cierto periodo de tiempo para recibir propuestas (que puede ir de unos cuantos días a algunas semanas), y selecciona una propuesta/proveedor para realizar el proyecto.

Tradicionalmente se piensa que el desarrollo de la arquitectura inicia hasta la operación de un proyecto, sin embargo y como describiré en esta columna, es conveniente iniciar las actividades de desarrollo de arquitectura desde la etapa de preventa con el fin de lograr una propuesta más pertinente tanto para el cliente como para la organización que planea llevar a cabo el proyecto.

Preventa

La preventa se enfoca en establecer por un lado el alcance del proyecto y, por el otro, una estimación del tiempo y costo que llevará la realización del proyecto de desarrollo. La estimación que se genera durante la preventa permite al cliente tomar la decisión de si acepta o no que se realice el proyecto. Aunque en este artículo me estaré refiriendo a la preventa en un contexto de desarrollo de software a la medida, lo que aquí describo puede aplicarse también en otros contextos.

La preventa cubre actividades de la fase de inicio y planeación del ciclo de vida tradicional de la administración de proyecto. Sin embargo, dado que el propósito de la preventa es conseguir la aprobación de la realización del proyecto, muchas veces las actividades que se realizan durante la preventa son menos detalladas que lo que se hace una vez que el proyecto ha iniciado de manera formal. Por ejemplo, durante la preventa es muy probable que no se tenga claridad sobre quiénes serán las personas específicas que ejecutarán el proyecto; simplemente se determina cuántas personas y con qué perfiles se necesitarían para llevar a cabo el proyecto de acuerdo a la solución y tiempos propuestos.

Hay que señalar que durante la preventa se tiene un contexto particular y complicado, en el cual muchas veces se deben considerar:

Información limitada: Generalmente no será sino hasta que se ejecute el proyecto que se levantarán los requerimientos de forma detallada, por lo que al momento de la preventa sólo se cuenta con requerimientos de alto nivel (que aquí llamaremos “características”). La figura 1 muestra un diagrama basado en la pirámide de requerimientos de Leffingwell donde está marcado en rojo el contexto de requerimientos con el que operamos durante la preventa.
Poco tiempo: Muchas veces las propuestas de preventa deben ser desarrolladas en tiempos cortos. Esto es porque generalmente el cliente solicita que se le entregue una cotización rápidamente pero, también, porque la empresa de desarrollo no desea dedicar demasiado esfuerzo en una actividad que muchas veces no se cobra y para la cual no hay garantía que haya un beneficio a largo plazo.

Desarrollo de arquitectura durante la preventa

Uno de los aspectos fundamentales del trabajo que se realiza en la preventa es la estimación. Lograr una estimación adecuada muchas veces requiere de establecer un esbozo de solución, por ejemplo, para dimensionar el hardware que se debe adquirir como parte del proyecto o para conocer el tipo de recursos que deben ser asignados o contratados para la ejecución del mismo.

Es en el desarrollo de esta solución preliminar que las técnicas de desarrollo de arquitectura de software pueden aportar beneficios importantes si dichas técnicas son adaptadas para el contexto particular de la preventa. Recordemos que el ciclo de vida de la arquitectura de software consta de 4 etapas que incluyen requerimientos, diseño, documentación y evaluación (ver SG #27). A continuación veremos de qué manera puede ser adaptada cada una de estas etapas para el contexto de la preventa.

Drivers de arquitectura durante la preventa

Recordemos que dentro de los requerimientos de un sistema de software, una parte de ellos es la que influye de manera decisiva sobre la arquitectura. Estos requerimientos son conocidos como drivers de la arquitectura e incluyen requerimientos funcionales primarios, atributos de calidad y restricciones (ver SG #28).

Como mencioné previamente, al momento de realizar la preventa de un proyecto no se cuenta con requerimientos detallados del proyecto, ya que en general estos no serán levantados y especificados sino hasta que el proyecto esté siendo ejecutado. Muchas veces sólo se dispone de características o requerimientos de alto nivel. Con el fin de poder diseñar una solución preliminar con el fin de estimar, es importante que durante la preventa se considere obtener drivers de preventa que incluyen:

Características funcionales. A diferencia de los drivers tradicionales en donde sólo se considera la funcionalidad primaria, en general en la preventa es necesario considerar toda la funcionalidad pues la estimación del proyecto debe considerar todas las características funcionales del mismo.
Características de atributos de calidad. Durante la preventa es complicado hacer un levantamiento detallado de los atributos de calidad, y más particularmente, especificarlos como escenarios. Dos aspectos que se deben cuidar particularmente son, sin embargo, el identificar las categorías de atributos de calidad más relevantes para el proyecto y, por otro lado, un rango preliminar en relación con las métricas asociadas a estos atributos de calidad.
Restricciones. Es necesario identificar desde el inicio las restricciones al diseño de la solución. En particular es importante identificar restricciones que pueden influir en la estimación y que pueden tener que ver con el tipo de tecnología a utilizar, los sistemas con los que interactúa el sistema que se va a desarrollar y el entorno de operación del sistema.

Diseño de arquitectura durante la preventa

Una vez que se tienen identificados los drivers de preventa, es posible proceder al diseño de la solución. Algo que es importante considerar es que durante la fase de preventa, el objetivo principal del diseño de la arquitectura es de establecer una estructura que permita estimar el proyecto. Lo anterior diferencía el diseño de arquitectura que se hace en preventa del diseño de arquitectura que se hace durante la operación de un proyecto (ver SG #29). Generalmente el tiempo con el que se cuenta para diseñar la arquitectura durante la preventa es corto por lo que el nivel de detalle de la solución muchas veces es limitado. Con el fin de lograr la identificación de elementos que permitan realizar la estimación, es recomendable establecer estructuras generales de un punto de vista lógico y de un punto de vista físico. Cabe señalar que esto puede verse como la realización de rondas iniciales de diseño utilizando el método de diseño guiado por atributos o ADD.

Estructuración general del sistema de un punto de vista lógico

La estructuración general del sistema de un punto de vista lógico consiste en identificar, por un lado, el estilo arquitectónico que se usará y, por otro lado, los componentes que deberían soportar el conjunto de características funcionales del sistema. Para lograr esta descomposición, que tiene un enfoque funcional, es recomendable hacer uso de arquitecturas de referencia que definen la estructuración general de sistemas para dominios aplicativos bien establecidos. Un ejemplo de ello es una arquitectura de referencia para aplicaciones web empresariales, ya que establece las capas así como los tipos de componentes de este tipo de arquitectura.

Figura 1. Contexto de preventa.

Otro aspecto que puede ser importante en este punto es la identificación de las tecnologías asociadas con las partes que define la arquitectura de referencia. La identificación de tecnologías puede obedecer a las restricciones y también a los atributos de calidad del sistema.

Estructuración general del sistema de un punto de vista físico

La estructuración general del sistema de un punto de vista físico consiste en mapear los elementos de la estructura lógica hacia elementos físicos, más particularmente, nodos en los cuales se ejecutarán las partes de la aplicación. De esta forma se establece la manera en que será implantada la solución. La identificación del esquema de implantación es fundamental para establecer una estimación de los recursos físicos necesarios para el desarrollo de la solución.

El esquema de implantación de la solución que se elige obedece, en general, a los atributos de calidad del sistema pero también a las restricciones. En general son atributos de calidad relacionados con la disponibilidad y el desempeño los que influirán directamente sobre el esquema de implantación de la solución. Por ejemplo, cuando se tienen requerimientos relacionados con una alta disponibilidad, muchas veces se opta por un esquema de implantación que implica la redundancia.

Documentación de arquitectura durante la preventa

La documentación del diseño de una arquitectura consiste en la representación de las distintas estructuras a través de vistas (ver SG #30). En el contexto de la preventa, en general la documentación que se produce del diseño es información que será usada como parte de la propuesta técnica que se le entrega al cliente, por lo que no es tan conveniente realizar una documentación demasiado técnica (a diferencia de lo que se hace durante la ejecución del proyecto). Muchas veces la documentación se limita a un diagrama usando un lenguaje menos formal, o lo que se conoce como diagrama de “Marketecture”.

Evaluación de arquitectura durante la preventa

Una de las actividades fundamentales del ciclo de desarrollo de la arquitectura es la evaluación del diseño (ver SG #31). Recordemos que el propósito de la evaluación es la identificación de riesgos relacionados con la toma de decisiones relativas al diseño.

Al igual que lo que se realiza como parte del ciclo de desarrollo de la arquitectura, es posible realizar una evaluación del diseño durante la preventa. En una evaluación basada en escenarios tradicional, se toman escenarios y se revisa detalladamente la manera en que el diseño de la arquitectura los soporta. Durante la preventa, el nivel de detalle del diseño del que se dispone no es el mismo. De hecho, muchas veces no se han tomado decisiones finas enfocadas a soportar escenarios concretos dado que no se dispone de ellos. Por lo anterior, la evaluación de la arquitectura durante la preventa no puede ser realizada de la misma manera que lo que se realiza durante la operación del proyecto.

En general, durante la evaluación de arquitectura en preventa, lo que se evalúa son las decisiones primarias tomadas en relación al diseño: la elección del tipo de arquitectura de referencia, las tecnologías o el esquema de implantación. Generalmente la evaluación de arquitectura identifica riesgos asociados no únicamente con el diseño sino también con otros aspectos tales como los requerimientos. Por ejemplo, si al momento de realizar la evaluación se observa que no hay métricas asociadas a los atributos de calidad (como sucede frecuentemente), esto representa un riesgo.

Finalmente, puede ser conveniente que como parte de la evaluación, se revise el plan que se tiene del proyecto para evaluar si la estrategia que se está considerando es adecuada en relación a los riesgos que se han identificado.

Conclusión

La preventa de un proyecto juega un papel crítico en relación a la aceptación de un proyecto de desarrollo. El utilizar métodos adaptados de desarrollo de arquitecturas de software durante esta etapa no sólo es posible sino que es recomendable pues puede permitir que se establezca una solución más adecuada y se realice una mejor estimación.

En la URL siguiente el lector podrá encontrar un video de la presentación que realicé este año en la conferencia SATURN 2014 y de la cual se deriva este artículo: http://goo.gl/5ZC8W4

Bio

Las Interfaces y la Arquitectura

sg — Fri, 19 Sep 2014 21:01:41 +0000

Las Interfaces y la Arquitectura sg Fri, 09/19/2014 - 16:01

Publicado en

SG #45

Arquitectura

Autor

Humberto Cervantes

En esta ocasión hablaré de un tema relacionado con las Interfaces de Programación de Aplicaciones (API) y con las pruebas que juega un papel fundamental dentro de la arquitectura: las interfaces. Las interfaces son los puntos de contacto que establecen un contrato que permite el intercambio de información entre elementos que forman parte de la arquitectura de un sistema de software. Estos elementos pueden ser lógicos (ej. módulos), dinámicos (ej. objetos) o físicos (ej. nodos de hardware). Recordemos que la arquitectura está formada por estructuras compuestas por elementos conectados entre sí (ver SG27), y es en los puntos de conexión donde se encuentran las interfaces.

Durante el diseño de la arquitectura (ver SG29), el arquitecto considera un subconjunto de requerimientos que se denominan drivers para crear las estructuras que conforman a la arquitectura del sistema. Estos requerimientos incluyen requerimientos funcionales primarios, atributos de calidad y restricciones (ver SG28). Al diseñar la arquitectura, el arquitecto identifica elementos que permiten satisfacer los drivers, junto con las interfaces de estos elementos. La identificación y definición de las interfaces se hace, generalmente, mediante un análisis dinámico de la interacción entre los elementos con el fin de soportar un requerimiento particular. La figura 1 muestra un ejemplo de esto.

Figura 1. Estructuración lógica para soportar el caso de uso CU-1 (llave: UML)

El caso de uso CU-1, que es primario, forma parte de los drivers mientras que los demás casos de uso no. Al momento de diseñar la arquitectura, el arquitecto identifica elementos (en este caso capas y componentes) que permiten soportar el driver. Una vez identificados los elementos, se establecen los mensajes que deben intercambiar instancias de los elementos para soportar el driver. En el ejemplo, el componente ServicioCU1 tiene un método procesa() que recibe dos parámetros p1 y p2 y regresa un valor de retorno retA mientras que el componente Persistencia tiene un método almacena() que recibe un parámetro p3 y regresa un valor de retorno retB. En este caso, el método procesa() forma parte de la interfaz del componente ServicioCU1 mientras que almacena() forma parte de la interfaz del componente Persistencia. Cabe señalar que en general una interfaz tiene varios métodos, a diferencia de este ejemplo simple.

El arquitecto no identifica todos los elementos y sus interfaces, solo lo hace para aquellos que soportan los drivers. Sin embargo, estas decisiones establecen un marco de referencia que permite a los desarrolladores identificar los elementos e interfaces para requerimientos que no son drivers. Considerando el ejemplo previo, se deberían identificar componentes para soportar los demás casos de uso así como sus interfaces.

Permiten realizar la integración del sistema

En general un sistema es desarrollado de forma paralela por un equipo de desarrolladores que se encargan de construir partes individuales que posteriormente serán conectadas. Si el contrato entre las partes está bien definido desde el principio, se reducen los problemas relacionados con la integración. Retomando el ejemplo de la figura 1, supongamos que los componentes ServicioCU1 y Persistencia son desarrollados por distintas personas. Si previo al desarrollo de estos componentes se estableció que el componente Persistencia tiene una interfaz con un método retB almacena(p3), el desarrollador de ServicioCU1 tiene claro cómo interactuar con el componente Persistencia y la integración normalmente se hace sin dificultades. De lo contrario, es posible que la integración se retrase por correcciones necesarias para permitir que los componentes puedan interactuar.

Especificaciones para el diseño detallados de los módulos

La interfaz de un componente sirve también como especificación para realizar su diseño detallado y construcción. Consideremos el ejemplo anterior en el cual la interfaz del componente ServicioCU1 tiene un método retA procesa(p1,p2). El desarrollador puede diseñar y codificar el componente de diversas formas, siempre y cuando su diseño e implementación satisfagan el contrato establecido por la interfaz que, en este caso, es que el componente provea el método procesa().

Pruebas unitarias y de integración

Al desarrollar un sistema es necesario probar sus partes de forma individual, esto es lo que se conoce como prueba unitaria. La manera típica de hacerlo es probando el elemento a través de su interfaz, pues se asume que si un componente satisface el contrato que establece la interfaz entonces funciona correctamente. Retomando el ejemplo de la figura 1, si se quiere probar el componente Persistencia , habría que invocar el método almacena() y corroborar si el valor de retorno ret2 es lo que se espera en base al valor del parámetro p3.

Por otro lado, las interfaces permiten realizar prueba unitaria de elementos que dependen de otros al soportar la sustitución de elementos de los que se depende. Por ejemplo, si se quiere probar el componente ServicioCU1 del ejemplo anterior, no es necesario que se disponga del componente Persistencia. Basta con crear una implementación de la interfaz que debe implementar el componente Persistencia y que regrese los valores esperados. Esto es lo que se conoce como un “mock” (sustituto). Cabe señalar que para lograr esto es necesario hacer uso de alguna primitiva del lenguaje que permita especificar interfaces de forma independiente de su implementación.

Finalmente, las pruebas de integración, como su nombre lo indica, se enfocan en probar que los elementos se conectan de forma adecuada y para ello juegan un papel fundamental las interfaces y su correcta definición.

Conexión con sistemas externos

Es cada vez más común que los sistemas de software no sean entidades que trabajan de forma individual. En la actualidad, un sistema de software frecuentemente hace uso de funcionalidades provistas por otros sistemas, o bien proporciona funcionalidades para que sean usadas por otro sistema.

Para permitir la interacción entre sistemas, es necesario establecer interfaces que establezcan un contrato sobre la manera en que se intercambia la información. Es común hoy en día que esas interfaces se describan usando un lenguaje tal como WSDL (Web Services Description Language), si la comunicación entre sistemas se realiza mediante servicios web.

Interfaz de Programación de Aplicaciones (API)

Las interfaces de programación de aplicaciones (API) generalmente están relacionadas con librerías o frameworks (ver SG38). En lenguajes de desarrollo orientado a objetos tales como Java, existe una API asociada con el lenguaje que proporciona una gran cantidad de clases para propósitos diversos, como pueden ser el manejo de estructuras de datos. En este caso, el API se usa creando instancias de las clases que son parte del API, o bien, heredando y extendiendo a las mismas.

A continuación se describen algunos aspectos de importancia que se deben considerar en relación con las interfaces.

Alta cohesión y bajo acoplamiento. Este es el principio fundamental del diseño de interfaces. La alta cohesión se refiere a que cada componente haga una sola cosa, mientras que el bajo acoplamiento busca que al modificar un elemento el cambio no se propague hacia otros elementos. El bajo acoplamiento se logra encapsulando detalles de implementación. Esto significa que la interfaz de un elemento no debe exponer detalles internos del mismo, tales como las estructuras de datos en las cuales se almacena el estado, ya que estos detalles deben poder cambiarse sin necesidad de que esto afecte a los clientes de la interfaz. Por lo anterior, la interfaz de un elemento se debe diseñar de forma cuidadosa para no exponer detalles de implementación, ya que el tener interfaces no garantiza el bajo acoplamiento.

Programación defensiva. Cuando una interfaz es expuesta para que sea usada por un sistema externo o para que se construya un programa haciendo uso de ella, es necesario tomar precauciones adicionales en relación con los valores de entrada de los métodos de la interfaz. Lo anterior es parte de lo que se conoce como “programación defensiva” e implica, entre otras cosas, validar todas las entradas y considerar posibles situaciones inesperadas. En las interfaces internas, es posible relajar un poco este aspecto si se tiene seguridad de que no se recibirán valores que podrían causar problemas.

Aspectos de calidad de servicio. En algunos casos, además de la “firma” de la interfaz que está compuesta por elementos sintácticos (nombre de métodos, tipo de parámetros y valores de retorno), es necesario especificar como parte de la interfaz aspectos relacionados con la calidad de servicio. Un ejemplo de ello sería que la ejecución de un método tiene que completarse en un tiempo establecido.

Conclusión

Las interfaces tanto internas como externas juegan un papel fundamental en el desarrollo de un sistema de software. La definición de las interfaces está intrínsecamente relacionada con el diseño de la arquitectura, y una definición deficiente de las interfaces tiene muchas repercusiones negativas en el desarrollo del sistema. El no definir las interfaces de forma oportuna impacta negativamente en la integración del proyecto y en la realización de pruebas del mismo, lo cual tiene repercusiones en el tiempo de desarrollo y la calidad del sistema.

Por todo lo anterior, es necesario poner especial cuidado de identificar y definir correctamente las interfaces entre los elementos del sistema.

Bio

10 años de arquitectura de software

sg — Mon, 07 Jul 2014 23:51:09 +0000

10 años de arquitectura de software sg Mon, 07/07/2014 - 18:51

Publicado en

SG #44

Arquitectura

Autor

Humberto Cervantes

En el año 2006, Mary Shaw y Paul Clements escribieron un artículo que recapitulaba lo sucedido en los últimos 20 años en relación con la arquitectura de software [1]. En dicho artículo los autores concluyen que, a partir del año 2000, la arquitectura de software entró en una fase de popularización: desde entonces existen gran cantidad de herramientas, servicios, aplicaciones, plataformas, estándares y cursos construidos alrededor de la arquitectura.

Han transcurrido 8 años desde la publicación del artículo y la arquitectura de software continúa cobrando importancia en la industria del desarrollo de software. Para este número especial intentaré resumir un poco de lo que ha sucedido desde la publicación de dicho artículo con el fin de tener un panorama de lo que ha ocurrido en la última década.

A nivel internacional

Para tener una idea de lo que ha sucedido a nivel internacional, conviene echar un vistazo a los temas que se han cubierto en la conferencia SATURN [2] (SEI Architecture Technology User Network) que arrancó en 2005. Esta conferencia especializada en arquitectura está enfocada a los practicantes y cada año reúne a un número creciente de participantes provenientes de empresas y universidades de todo el mundo.

SATURN arrancó como un taller (workshop). En estos primeros años, algunos de los temas que se presentaron de forma recurrente incluyeron experiencias en el uso de métodos del SEI tales como QAW, ADD y ATAM en diversas organizaciones (Ver SG. 28, 29 y 30).

En 2009, SATURN se convierte en una conferencia. Algunos temas que surgen incluyen la alineación de los distintos niveles de arquitecturas (Software, Sistema, Empresarial) y los aspectos relacionados con las competencias, tanto de individuos como de organizaciones.

En el año 2010 aparecen los temas de la relación entre la arquitectura y las metodologías ágiles de desarrollo así como el cómputo en la nube. A partir de ese año, la agilidad ha sido un tema recurrente en la conferencia SATURN.

En 2011 aparecen temas relacionados con la introducción de la ingeniería centrada en arquitectura en la versión 1.3 de CMMI (ver SG 36) y también se habla del arquitecto como agente de cambio (ver SG 33). Otros temas que comienzan a cobrar más auge son las arquitecturas para sistemas de gran escala y casos de éxito como el sistema que se desarrolló para la bolsa de valores de México (ver SG 41).

En 2012 se mantienen temas de agilidad y colaboración. Cobran más auge temas relacionados con el desarrollo de “sistemas de sistemas” y sistemas de escala ultra grande.

En 2013, continúan presentes temas de desarrollo en la nube, móvil y también aparece el tema de sistema de larga vida.

Por último, en 2014 se tocaron temas como DevOps, la evolución de los sistemas, colaboración de equipos y con clientes y crecimiento de los arquitectos.

En México

Advierto que mi perspectiva de lo que considero que ha sucedido a nivel nacional probablemente es un tanto limitada. Como frecuentemente sucede, existe algo de atraso de lo que sucede en México con respecto a lo que sucede en los Estados Unidos y el tema de la arquitectura de software no es la excepción. Creo que el concepto de arquitectura de software ya se ha popularizado hasta cierto punto en nuestro país, sin embargo, me parece que todavía es limitado el número de organizaciones de desarrollo en donde se realizan prácticas bien establecidas de desarrollo de arquitecturas de software. Sigue siendo común encontrar, por ejemplo, requerimientos enfocados en funcionalidad y atributos de calidad no cuantificados.

En México no existe algún tipo de conferencia parecida a SATURN, sin embargo, en foros enfocados a practicantes a los cuales he tenido la oportunidad de asistir no he percibido que se trate el tema de arquitectura de software de manera frecuente, y mi percepción es que hay más énfasis en aspectos de proceso o de tecnologías. Por otro lado, a nivel académico, existen ya algunos cursos que tocan el tema de la arquitectura de software.

Conclusión

La arquitectura de software es una disciplina con cerca de 30 años de antigüedad y que en la última década ha continuado popularizándose. A pesar del tiempo que lleva y de los avances que hay al respecto, considero que todavía es necesario seguir haciendo un esfuerzo con el fin de que las prácticas de desarrollo de arquitecturas se vuelvan algo estándar en las organizaciones de desarrollo de software. En los próximos años la arquitectura de software seguirá siendo relevante, en particular para mejorar la calidad de los sistemas así como atacar de forma exitosa nuevos retos en el desarrollo.

Referencias

[1] Shaw, M., Clements, P. “The Golden Age of Software Architecture”, IEEE Software, Marzo / Abril 2006

[2] http://www.sei.cmu.edu/saturn/

Bio

El Dr. Humberto Cervantes es profesor-investigador en la UAMIztapalapa. Además de realizar docencia e investigación dentro de la academia en temas relacionados con arquitectura de software, realiza consultoría y tiene experiencia en la implantación de métodos de arquitectura dentro de la industria de desarrollo nacional. Ha recibido diversos cursos de especialización en el tema de arquitectura de software en el Software Engineering Institute, y está certificado como ATAM Evaluator y Software Architecture Professional por parte del mismo. www.humbertocervantes.net

Tecnología móvil y arquitectura

lasr21 — Thu, 12 Dec 2013 01:46:08 +0000

Tecnología móvil y arquitectura lasr21 Wed, 12/11/2013 - 19:46

Publicado en

SG #42

Arquitectura

Autor

A diferencia de las computadoras “tradicionales”, los dispositivos móviles tienen características particulares que incluyen:

Duración limitada de la batería.
Posible tamaño pequeño de la pantalla.
Conectividad intermitente.
Posibilidad de que el dispositivo se pierda fácilmente.
Posibilidad de realizar cálculos demandantes.
Variedad de sensores que permiten recolectar información.
Acceso a infraestructura que facilita la instalación y actualización de aplicaciones (mercados de apps).

Los puntos descritos previamente aunados al hecho de que los dispositivos móviles están siempre a la mano, ha dado lugar a distintos tipos de aplicaciones con drivers particulares. Recordemos que en el contexto de arquitectura de software, los drivers, se refieren a los requerimientos que influyen en el diseño de la arquitectura. Estos drivers generalmente incluyen requerimientos funcionales primarios, atributos de calidad y restricciones.

Tipos de aplicaciones

Hoy en día podemos considerar tres categorías de aplicaciones móviles:

La primer categoría son las típicas aplicaciones (apps) que instalamos en dispositivos móviles tales como los teléfonos inteligentes y tabletas a través de un mercado de apps. Esta categoría de aplicación tiene la particularidad de que generalmente se ejecuta de forma aislada en el dispositivo y, si se comunica con recursos externos, simplemente lo hace para acceder a información que no se tiene en el dispositivo.
La segunda categoría se refiere a las aplicaciones donde el dispositivo móvil se vuelve una extensión a los sistemas empresariales. En esta categoría, el dispositivo es parte del sistema y, en cierta forma, podríamos pensarlo como la interfaz de usuario con el mismo. Por las características descritas previamente de los dispositivos móviles, esta interfaz de usuario es distinta al enfoque tradicional con el que se interactúa con los sistemas empresariales que es generalmente a través de un navegador.
La tercera categoría es cuando se utilizan los dispositivos móviles como colectores de información aprovechando todos los sensores que tienen, tales como GPS, acelerómetro, etc. Esta categoría se podría considerar como una extensión de los sistemas empresariales pero con una función muy específica enfocada a la colecta de información.

Drivers arquitectónicos

Existen drivers específicos dependiendo del tipo de aplicación móvil. En el primer tipo de aplicaciones (las apps), el driver principal es una restricción de tiempo de entrega. Estas son aplicaciones de muy corta vida que duran unos pocos días en el “top 10” de los mercados de apps y después desaparecen.

En el segundo tipo de aplicaciones, es decir la extensión de los sistemas empresariales, a nivel funcional generalmente es necesario considerar que los casos de uso del sistema deben poder ser realizados tanto a través de un cliente tradicional (navegador) como de la aplicación móvil. En este tipo de aplicaciones, la conectividad variable es algo que debe tomarse en cuenta y esto puede requerir que se almacenen datos de forma local y que se tenga que lidiar con cuestiones de sincronización de datos. El almacenar datos de forma local requiere, sin embargo, considerar además aspectos relacionados con la seguridad por la información, posiblemente confidencial, que se maneja.

En el tercer tipo de aplicaciones, es decir cuando se usan los dispositivos móviles como sensores que colectan datos, puede haber atributos de calidad relacionados con aspectos tales como la privacidad.

De forma general, todos los tipos de aplicaciones se benefician de la infraestructura de mercados de apps que facilita la instalación y actualización de las mismas.

Arquitectura y aplicaciones móviles

Actualmente el mercado móvil todavía depende mucho de la restricción de tiempos de entrega rápidos y generalmente el desarrollo del primer tipo de aplicaciones descrito previamente no se preocupa tanto por la arquitectura. El considerar realizar diseño de arquitectura podría aportar muchos beneficios al desarrollo de aplicaciones móviles. Se puede pensar por ejemplo en generar líneas de productos y establecer frameworks robustos para el desarrollo, lo cual permitiría generar aplicaciones más rápido y además de mejor calidad. Por otro lado, en las aplicaciones que son extensiones de los sistemas empresariales, la arquitectura juega un papel fundamental para poder cubrir con los drivers que se mencionaron previamente.

Los métodos de desarrollo de arquitectura, tales como QAW, ADD o ATAM, se pueden aplicar sin necesidad de ajustes en el desarrollo de aplicaciones móviles. Lo que posiblemente diferirá al utilizarlos son aspectos tales como los drivers, pues los escenarios que se identifican difieren de los que ocurren en aplicaciones más tradicionales. Un ejemplo de ello podría ser un escenario de seguridad: “Se extravía un dispositivo móvil en el cual se descargó información confidencial y un usuario malintencionado intenta extraerla”. En el contexto de las aplicaciones móviles, se debe pensar en los mismos atributos de calidad que los de las aplicaciones tradicionales pero considerando los aspectos propios de los dispositivos móviles. Un ejemplo de ello es la usabilidad, que en el contexto de las aplicaciones para dispositivos móviles debe considerar, por ejemplo, el tamaño reducido de las pantallas.

Relación con el cómputo en la nube y SOA

Cuando hablamos de tecnologías móviles, difícilmente las podemos disociar del cómputo en la nube y la Arquitectura Orientada a Servicios (SOA). La combinación de tecnología móvil y cómputo en la nube resulta en algo que hoy en día se conoce en inglés como “Mobile Cloud Computing”. Al igual que con los tipos de aplicaciones, dentro de esta intersección de las tecnologías, podemos considerar tres variantes:

Cuando se utiliza el dispositivo móvil como un mecanismo para acceder a los recursos de la nube. Por ejemplo cuando se utiliza el teléfono para acceder a una aplicación tal como Google maps. Esto usualmente corresponde al primer tipo de aplicación del que se habló previamente.
Lograr que un dispositivo móvil pueda asignar tareas a otros dispositivos móviles cercanos como si fueran recursos de la nube. Por ejemplo, si se tiene una tarea muy complicada entonces se puede repartir cálculos a varios dispositivos cercanos.
El “cyber-foraging” y se refiere a descargar parte del trabajo de cálculo del dispositivo móvil a máquinas más poderosas para evitar, por ejemplo, un consumo excesivo de batería. En este enfoque, la nube se ve como una extensión del dispositivo móvil, independientemente de si los cálculos se realizan en la nube en sí o bien en servidores más cercanos.

Respecto a SOA, esta tecnología y el cómputo en la nube tienen mucho en común: el cómputo en la nube puede ser visto como una plataforma de implantación para aplicaciones que se desarrollan bajo el paradigma SOA. Por otro lado, el utilizar servicios es un mecanismo para facilitar la conexión entre los dispositivos móviles y las aplicaciones empresariales.

Investigación

Uno de los problemas en los que se trabaja actualmente en investigación (particularmente en el SEI) es el desarrollo de sistemas que apoyan a personas que están en “el borde” (the edge). El borde es un término que se utiliza para referirse a esa parte de la infraestructura hasta donde llegan las conexiones de red. El proyecto que dirige Grace se llama “Edge-enabled tactical systems” y se enfoca en establecer mecanismos para ayudar a la gente que trabaja con dispositivos móviles más allá del borde. Los usuarios principales en este proyecto de investigación son soldados y personas que son llamadas a ayudar en casos de emergencia (Cruz Roja, organizaciones de ayuda, etc.) o médicos rurales.

De forma general, en la investigación se ha hecho mucho énfasis en aspectos algorítmicos. Un caso es el poder determinar en tiempo de ejecución si cierto cálculo se puede ejecutar en otros recursos distintos al dispositivo mismo. Se observa, sin embargo, que actualmente no se hace mucho énfasis en arquitectura.

Conclusión

Hoy en día el acceso móvil a los sistemas ya no es algo opcional, sino que es algo ubicuo y es necesario pensar en clientes móviles desde que se comienza a diseñar la aplicación. El acceso móvil es la forma como la gente interactúa hoy en día con computación y, por ello, los usuarios tienen expectativas al respecto, como por ejemplo poder realizar las mismas actividades que se hacen en la máquina de la oficina a través de un teléfono inteligente.

Por otro lado, y para recalcar la importancia que está cobrando el desarrollo de aplicaciones para dispositivos móviles, es interesante observar que a nivel de la oferta laboral (en Estados Unidos) cerca de un 70% de las ofertas de trabajo para los egresados de la universidad está exigiendo algún conocimiento de desarrollo en iOS o Android.

La arquitectura de software juega un papel fundamental en el desarrollo de aplicaciones móviles y creemos que el darle un énfasis mayor al que se está dando actualmente podría aportar grandes beneficios.

Hablando con el arquitecto: Luis Carballo

sg — Mon, 23 Sep 2013 02:55:41 +0000

Hablando con el arquitecto: Luis Carballo sg Sun, 09/22/2013 - 21:55

Publicado en

SG #41

Arquitectura

Autor

Humberto Cervantes

En esta ocasión presento en esta columna una entrevista con Luis Carballo, Arquitecto de software de uno de los sistemas más críticos para México. Luis trabaja desde hace 7 años en la Bolsa Mexicana de Valores (BMV) en el área de sistemas en una empresa llamada Bursatec. Él es egresado de la UAM en donde estudió Ingeniería Electrónica y posteriormente realizó una maestría en el ITAM de TI y Administración (luis.carballo@mac.com).

¿Puedes platicarnos un poco acerca del proyecto en el cual estás trabajando?
Es un proyecto de renovación tecnológica del motor central de negociación de la bolsa que inició en el 2009. El sistema sustituye a tres sistemas legados, dos que corrían en Tandem que eran propietarios y un tercero que se le compró a la bolsa española. Se instaló en producción la primera parte, que corresponde al mercado accionario, en Septiembre de 2012 y la segunda parte, que corresponde al mercado de derivados, en Abril de 2013.

¿Puedes hablar un poco acerca de lo que llamamos los “drivers” y en particular los atributos de calidad del sistema?
Uno de los objetivos de reemplazar los antiguos sistemas era de reducir el costo total de propiedad pues el costo de mantenimiento de los sistemas Tandem, escritos en Cobol, era muy alto. Otro objetivo era aumentar el desempeño pues el sistema anterior iba a tener un límite con el cual se iba a topar pronto. La idea era reemplazarlo por uno nuevo que pudiera tener muchas más capacidades sobre todo en rendimiento, en baja latencia, en alta disponibilidad y que fuera mucho más fácil de probar y de integrar continuamente.

De estos drivers que mencionaste, ¿cuál ha resultado el más complejo?
Creo que el más difícil de todos es el de latencia porque toca todo el flujo de código por el cual se va a ejecutar una transacción. La latencia se refiere al tiempo de procesamiento dentro del motor desde que llega un mensaje (por ejemplo una compra de una acción) hasta que el motor responde (ej. aceptada o rechazada o hizo “match” contra otra orden). El promedio de latencia del sistema anterior era 24 milisegundos. El requerimiento original era que fuera menos de un milisegundo pero durante el análisis que se hizo contra otros mercados, se decidió bajar el tiempo para hacerlo más competitivo y que fueran menos de 100 microsegundos, o sea, 240 veces más rápido que el sistema anterior. El rendimiento se refiere a la cantidad de transacciones que se pueden ejecutar en un segundo dado. El sistema anterior tenía una capacidad de procesamiento de transacciones baja y el sistema actual está diseñado para soportar más de 100,000 transacciones por segundo. Al ser un sistema de misión crítica, la alta disponibilidad también es un factor importante y se consideran dos escenarios: en caso de falla de uno de los nodos primarios tiene que hacer “failover” (tolerancia a fallas) a otro en el mismo centro de datos y, el otro es que, en caso de falla del centro de datos primario, se pueda seguir la operación en un centro de datos secundario. Para el primer caso hoy en día tarda entre 5 y 10 segundos hacer la transición de una máquina a otra.

¿Qué tan importante es considerar la arquitectura para un sistema como éste?
Creo que es de los factores de éxito más importantes porque, de haber construido sin tener en mente la latencia, el rendimiento o la alta disponibilidad, hubiera hecho que al final del proyecto fuera prácticamente imposible el tratar de satisfacer esos atributos de calidad. El haber hecho el diseño desde el inicio de tal forma que hubiera foco en la latencia desde el diseño original permitió que el sistema fuera exitoso. Hubo un momento durante las pruebas en el cual la latencia se disparaba poco a poco hasta llegar a segundos y todo por una sola línea de código. Generamos ciertas métricas y guías para evitar usar cosas que sabemos que son dañinas para efectos de latencia. Yo creo que ese tipo de problemas no los hubiéramos encontrado si no nos hubiéramos enfocado constantemente en que los atributos de calidad se cubrieran.

¿Cómo le hicieron para desarrollar esta arquitectura?
Contratamos al SEI para que nos asesorara en el diseño de la arquitectura y utilizamos los métodos que ellos proponen para efectos del diseño del sistema [1][2]. Se hizo un Taller de Atributos de Calidad (QAW), ADD con una modificación, documentación basada en atributos de calidad y ATAM (Architecture Tradeoff Analysis Method) para la evaluación. La modificación de ADD consistió en hacer mini-sesiones de cuestionamiento al diseño generado usando ADD para asegurar que el resultado fuera el esperado.

La gente del SEI nos cuestionaba diciendo “oye, el diseño que llevas hasta ahora a ver qué tan efectivo es para resolver problemas de latencia, desempeño...”. Estas sesiones se hacían constantemente como parte de las iteraciones de diseño. Eran prácticamente dos semanas de diseño y después del diseño una sesión de cuestionamiento. Fueron como diez iteraciones de diseño en las cuales se tomaron las decisiones más importantes. Después de eso se hizo la evaluación de la arquitectura usando ATAM con resultados satisfactorios.

A nivel del diseño, ¿qué retos hubo para satisfacer los atributos de calidad más importantes?
Respecto a la latencia, hay cosas como la elección misma de las estructuras de datos pues unas son más rápidas que otras. Aún si en el diseño de la arquitectura pusimos cuotas sobre la latencia de ciertos componentes, durante la ejecución hubo que probar diferentes soluciones y ver cuál era la mejor opción según el caso. Es un tema de ir buscando, aún durante la construcción, las mejores soluciones posibles para poder satisfacer los atributos de calidad. Se hacían prototipos específicos para lo que se quería en ese momento y se determinaba cual era la mejor solución, que “tradeoffs” había, que restricciones pudiera tener y cuáles no y en base a eso, se tomaban las decisiones finales. Afortunadamente el grupo de arquitectura pasó a ser parte del grupo de desarrollo entonces
ellos asesoraban a todos los demás para que supieran cuáles eran las intenciones sobre ciertos componentes y que se apegaran a los lineamientos establecidos.

Con respecto a la documentación, ¿cómo fue ese aspecto?
La hicimos durante el diseño. Durante la ejecución fuimos documentando toda la arquitectura que era requerida para la evaluación. Usamos algo como vistas pero más enfocadas a los atributos de calidad. Teníamos vistas específicas de cómo se resuelven los atributos de calidad. Hay por ejemplo, una vista específica de componentes para el escenario de alta disponibilidad. Se pueden tener varias vistas pero todas orbitan alrededor de un mismo atributo. Esto facilitó la evaluación, pues en esta se toma un escenario y se describe como está el flujo. De hecho durante el ATAM nos saltamos una de las dos fases, porque ya estaba prácticamente hecho.

¿Qué recomendaciones generales harías a los arquitectos en relación con el desarrollo de sus arquitecturas?
Una es que los requerimientos funcionales tienen algún impacto, además de los atributos de calidad, en las decisiones que se toman de arquitectura. Entonces conviene tener una lista lo más amplia posible de funcionalidades que puedan afectar la arquitectura para que se tomen las mejores decisiones al momento de hacer el diseño. La otra es que aunque haya atributos de calidad que aparentemente no sean relevantes para el negocio, siempre hay que considerarlos al momento del diseño, como por ejemplo la facilidad de prueba (testability).
Durante el diseño, que es un proceso iterativo, cuando se agotan los escenarios prioritarios, los que siguen deben analizarse y ahí es donde aparecen los de modificabilidad, testability y otras, además de escenarios adicionales de alta disponibilidad, de recuperación de fallas. Siempre hay escenarios que no son los más críticos pero que
un día van a suceder y por lo tanto son importantes para analizar y considerar en el diseño.

En el desarrollo en general de sistemas, ¿qué tanta importancia crees que haya que darle a la arquitectura? ¿En todo sistema debe cuidarse?
No, no en todo sistema. En sistemas muy pequeños es muy fácil cambiar el sistema para adecuar ciertos atributos de calidad y la arquitectura emerge naturalmente. Mientras más grande el sistema, más importante es. No sé si hay una regla pero al final es el costo de no hacerlo en un sistema chico es menor que en un sistema grande. Por otro lado, aún en sistemas pequeños, si los drivers son muy exigentes, se deben considerar desde el inicio porque después va a ser más difícil satisfacerlos.

Si tuvieras que volver a hacer ese sistema con el conocimiento que tienes hoy en día, ¿qué harías distinto?
Creo que la documentación es algo que siempre es mejorable. Hay muchas decisiones que tomamos en el camino y que no documentamos de la mejor forma o son decisiones implícitas y es mejor hacerlas explícitas desde el momento en que se toman aunque parezcan básicas porque después se olvida. Otra es hacer casos de prueba específicos para la arquitectura desde el principio.

Referencias

J. McHale, R. Nord, L. Carballo, “Driving Out Technical Risk by Blending Architecture, Process, and Project Discipline”, http://www.sei.cmu.edu/library/abstracts/presentations/mchale-saturn2012.cfm
R. Nord, J. McHale, F. Bachmann, “Combining Architecture-Centric Engineering with the Team Software Process”, http://www.sei.cmu.edu/library/abstracts/reports/10tr031.cfm

Bio

El Dr. Humberto Cervantes es profesor-investigador en la UAM-Iztapalapa. Además de realizar docencia e investigación dentro de la academia en temas relacionados con arquitectura de software, realiza consultoría y tiene experiencia en la implantación de métodos de arquitectura dentro de la industria. Ha recibido diversos cursos de especialización en el tema de arquitectura de software en el Software Engineering Institute, y está certificado como ATAM Evaluator y Software Architecture Professional por parte del mismo. www.humbertocervantes.net