Archivo de la categoría: Arquitectura de Sistemas

La ingeniería detrás de Uber (Parte II). The Foundation

La misión de Uber es ser tan fiables como el transporte de agua corriente, en todas partes, para todo el mundo. Para hacer esto posible, creamos y trabajamos con datos complejos. Luego agrupamos muy ordenadamente la plataforma que permite a los conductores poder conseguir que las empresas y los pilotos se desplacen.

Capturas de pantalla que muestran la aplicación piloto de Uber en Nueva York, China e India para la primavera de 2016.

Capturas de pantalla que muestran la aplicación piloto de Uber en Nueva York, China e India para la primavera de 2016.

Si bien queremos que la interfaz de usuario de Uber sea simple, diseñamos sistemas complejos detrás de él para mantenerse, manejamos interacciones difíciles, y servimos grandes cantidades de tráfico de datos. (Principio KISS)

Hemos roto la arquitectura monolítica original en muchas partes a escala con el crecimiento. Con cientos de microservicios que dependen el uno del otro, dibujando un diagrama de cómo funciona Uber en este momento es tremendamente complicado, y todo cambia rápidamente. Lo que se puede cubrir en un artículo de dos partes es la pila que se utilizó para la primavera de 2016.

Desafíos de la Ingeniería de Uber: No hay usuarios gratuitos, Hyper crecimiento

Tenemos los mismos problemas de escala global como algunas de las compañías de software más exitosas, pero 1) estamos a sólo seis años de edad, por lo que no las hemos resuelto todavía, y 2) Nuestro negocio está basado en el mundo físico en tiempo real.

En abril de 2015, 300 ciudades operativas de Uber estaban dispersos por todo el mapa.

En abril de 2015, 300 ciudades operativas de Uber estaban dispersos por todo el mapa.

A diferencia de los servicios freemium, Uber tiene solo los usuarios transaccionales: pilotos, controladores y ahora los comedores y los mensajeros. La gente confía en nuestra tecnología para poder hacer dinero, ir a donde tienen que ir, así que no hay tiempo para hacer una pausa. Damos prioridad a la disponibilidad y escalabilidad.

A medida que nos ampliamos en las carreteras, nuestro servicio debe escalar. La flexibilidad de nuestra pila fomenta la competencia por lo que las mejores ideas pueden ganar. Estas ideas no son necesariamente únicas. Si existe una herramienta fuerte, la usamos hasta que nuestras necesidades exceden sus capacidades. Cuando necesitamos algo más, construimos soluciones internas. La Ingeniería de Uber ha respondido al crecimiento con gran capacidad de adaptación, la creatividad y la disciplina en el último año. Para el 2016, tenemos planes aún más grandes. En el momento en que usted lea esto, mucho habrá cambiado, pero esto es una instantánea de lo que estamos usando ahora. A través de nuestras descripciones, esperamos demostrar nuestra filosofía entorno al uso de herramientas y tecnologías.

El Stack Tecnológico de Uber

En lugar de una torre de restricciones, como la imagen de un árbol. En cuanto a las tecnologías en Uber, se ve una pila común (como un tronco de árbol) con énfasis diferentes para cada equipo o en la oficina de ingeniería (sus ramas). Es todo hecho de la misma materia, pero las herramientas y servicios florecen de manera diferente en diferentes áreas.

botswana_baobab-768x477

En pocas palabras: La plataforma

Este primer artículo se centra en la plataforma de Uber, es decir, todo lo que le da el poder más grande a la organización de la ingeniería de Uber, equipos de plataforma crean y mantienen las cosas que permiten a los ingenieros para posteriormente construir otros programas, funciones, y las aplicaciones que se utilizan.

Infraestructura y almacenamiento

Nuestro negocio se ejecuta en un modelo de nube híbrida, usando una mezcla de proveedores de la nube y múltiples centros de datos activos. Si un centro de datos falla, viajes (y todos los servicios asociados con viajes) conmutación por error a otro. Asignamos ciudades para el centro de datos más cercano geográficamente, pero cada ciudad se copian en un centro de datos diferente en otra ubicación. Esto significa que todos nuestros centros de datos son los viajes en todos los tiempos de funcionamiento; no tenemos noción de un centro de datos como “copia de seguridad”. Para la provisión de esta infraestructura, se utiliza una mezcla de herramientas internas y Terraform.

Las nubes híbridas combinan los modelos de nubes públicas y privadas. Un usuario es propietario de unas partes y comparte otras, aunque de una manera controlada. Las nubes híbridas ofrecen la promesa del escalado, aprovisionada externamente, a demanda, pero añaden la complejidad de determinar cómo distribuir las aplicaciones a través de estos ambientes diferentes. Las empresas pueden sentir cierta atracción por la promesa de una nube híbrida, pero esta opción, al menos inicialmente, estará probablemente reservada a aplicaciones simples sin condicionantes, que no requieran de ninguna sincronización o necesiten bases de datos complejas. Se unen mediante la tecnología, pues permiten enviar datos o aplicaciones entre ellas. Un ejemplo son los sistemas de correo electrónico empresarial.  https://es.wikipedia.org/wiki/Computaci%C3%B3n_en_la_nube

Nuestras necesidades de almacenamiento han cambiado con el crecimiento. Un ejemplo sencillo de Postgres nos llevó a través de nuestra infancia, pero a medida que fue creciendo tan rápidamente, fue necesario aumentar el tiempo de almacenamiento en disco y la disminución de respuesta del sistema disponibles.

Al final del verano de 2014, Proyecto Mezzanine rediseñado el sistema para que coincida con la arquitectura de alto nivel.

Al final del verano de 2014, Proyecto Mezzanine rediseñando el sistema para que coincida con la arquitectura de alto nivel.

Actualmente usamos un modelo sin esquema (construido in-house en la parte superior del stack de MySQL), Riak, y Cassandra. Sin esquema es para el almacenamiento de datos a largo plazo; Riak y Cassandra se reúnen como plataforma de alta disponibilidad, y las demandas de baja latencia. Con el tiempo, las instancias sin esquema reemplazaron instancias individuales de MySQL y Postgres, y Cassandra reemplazó a Riak debido a la velocidad y el rendimiento. Para el almacenamiento y análisis de datos complejos distribuidos, utilizamos un almacén Hadoop. Más allá de estas bases de datos, nuestros ingenieros de Seattle se centran en la construcción de una nueva plataforma de datos en tiempo real.

Utilizamos Redis tanto para el almacenamiento en caché y la puesta en cola. Twemproxy ofrece escalabilidad de la capa de almacenamiento en caché sin sacrificar la tasa de aciertos de caché a través de su algoritmo de hash coherente.

Logging

Nuestros servicios interactúan entre sí y con los dispositivos móviles, y esas interacciones son valiosas para usos internos como la depuración, así como los casos de negocios como precios dinámicos. Para el registro, utilizamos varios clústeres Kafka, y los datos se archivan en Hadoop y/o en un servicio web de almacenamiento de archivos antes de que caduque Kafka. Estos datos también se ingiere en tiempo real por los diversos servicios e indexados en una pila ELK para la búsqueda y visualización (ELK significa Elasticsearch, Logstash, y Kibana).

App Provisioning

Utilizamos contenedores Docker sobre Mesos para hacer funcionar nuestros microservicios con configuraciones consistentes de manera evolutiva, con la ayuda de Aurora para los servicios de larga duración y los trabajos de cron. Uno de nuestros equipos de infraestructura, la plataforma de aplicaciones, produjo una biblioteca de plantillas que se basa en los servicios de imágenes fáciles de enviar y acoplables.

Routing and Service Discovery

Nuestra arquitectura orientada al servicio (SOA) hace que el descubrimiento de servicios de enrutamiento sea crucial para el éxito de Uber. Los servicios deben ser capaces de comunicarse entre sí en nuestra compleja red. Hemos utilizado una combinación de HAProxy y Hyperbahn para resolver este problema. Hyperbahn es parte de una colección de software de código abierto desarrollado en Uber: Ringpop, TChannel, y Hyperbahn todos comparten una misión común para agregar la automatización, la inteligencia, y el rendimiento de una red de servicios.

Los servicios legados utilizan instancias locales HAProxy para encaminar JSON sobre peticiones HTTP a otros servicios, con el servidor front-end web Nginx a los servidores en el extremo posterior. De esta forma bien establecida de la transferencia de datos hace que la solución de problemas sea fácil, que era crucial a lo largo de varias migraciones a sistemas recientemente desarrollados en el último año.

Sin embargo, estamos dando prioridad a la fiabilidad a largo plazo sobre la capacidad de depuración (debuggability). Usando protocolos alternativos para HTTP (como spdy, HTTP/2, y TChannel) junto con los lenguajes de definición de interfaz como Thrift y Protobuf que ayudarán a evolucionar nuestro sistema en términos de velocidad y fiabilidad. Ringpop, una capa de hash coherente, trae la cooperación y la auto-sanación (self-healing) a nivel de aplicación. Hyperbahn permite que los servicios puedan encontrarse y comunicarse con los demás de forma sencilla y fiable, así como los servicios se programan de forma dinámica con Mesos.

En lugar del arcaico pooling para ver si algo ha cambiado, nos estamos moviendo a un patrón de pub-sub (publicación de actualizaciones a los suscriptores). HTTP/2 y spdy permiten más fácilmente este modelo de inserción. Varias características basadas en este “pooling” dentro de la aplicación de Uber verán una tremenda aceleración de mover para empujar usando pub-sub.

Development and Deploy

Phabricator provee una gran cantidad de poder para poder manejar nuestra gran cantidad de operaciones internas, a partir de la revisión de código hasta el proceso de la documentación automatizado. Buscamos a través de nuestro código en OpenGrok. Para proyectos de código abierto de Uber, desarrollamos utilizando GitHub para proyectos de código abierto y para el seguimiento de problemas y revisiones de código.

Los ingenieros de Uber  se esfuerzan por hacer que el desarrollo pueda simular el ambiente de producción lo más cerca posible, por lo que desarrollan principalmente en máquinas virtuales que se ejecutan en un proveedor de la nube o en el portátil de un desarrollador. Construimos nuestro propio sistema de despliegue interno para gestionar las construcciones. Jenkins hace la integración continua. Se combinaron Packer, Vagrant, Boto, y Unison para crear herramientas para la construcción, gestión y desarrollo de las máquinas virtuales. Utilizamos Clusto para la gestión de inventarios en el desarrollo. Puppet gestiona la configuración del sistema.

Trabajamos constantemente para construir y mantener canales de comunicación estables, no sólo para nuestros servicios, sino también para nuestros ingenieros. Para el descubrimiento de información, construimos uBlame (un guiño a git-blame) para realizar un seguimiento de qué equipo es propietario de un determinado servicio, y Whober para buscar nombres, caras, información de contacto, y la estructura organizativa. Utilizamos un sitio de documentación interna que auto construye documentos contactándose con repositorios utilizando Sphinx. Un servicio empresarial de alerta a nuestros ingenieros de guardia para mantener los sistemas en funcionamiento. La mayoría de los desarrolladores ejecutar OS X en sus computadoras portátiles, y Linux la mayoría de nuestros casos de producción se ejecutan con Debian Jessie.

Languages

En los niveles más bajos, los ingenieros de Uber escriben principalmente en Python, Node.js: Go, y Java. Comenzamos con dos lenguas principales: Node.js para el equipo del mercado, y Python para todos los demás. Estas primeras lenguas todavía alimentan la mayoría de los servicios que se ejecutan en Uber hoy.

Adoptamos Go y Java por razones de alto rendimiento. Proporcionamos soporte de primera clase para los lenguajes. Java se aprovecha del ecosistema de código abierto y se integra con las tecnologías externas, como Hadoop y otras herramientas de análisis. Go nos da eficiencia, simplicidad y velocidad de ejecución.

Nosotros sustituimos el viejo código Python mayor dado que el objetivo es romper el código base original en microservicios. Un modelo de programación asíncrona nos da un mejor rendimiento. Utilizamos Tornado con Python, pero el soporte nativo de Go, para la concurrencia es ideal para la mayoría de los nuevos servicios de rendimiento crítico.

Escribimos herramientas en C y C ++ cuando es necesario (como por alta eficiencia, código de alta velocidad a nivel del sistema). Utilizamos software que está escrito en los lenguajes de HAProxy, por ejemplo-, pero en su mayor parte, no  trabajamos en ellos.

Y, por supuesto, los que trabajan en la parte superior de la pila de escritura en las lenguajes más allá de Java, Go, Python, y Node.

Testing

Para asegurarnos de que nuestros servicios pueden manejar las demandas de nuestro entorno de producción, hemos desarrollado dos herramientas internas: Tormenta de granizo y uDestroy. Tormenta de granizo impulsa las pruebas de integración y simula la carga máxima fuera de las horas pico, mientras que uDestroy rompe intencionadamente cosas por lo que podemos mejorar en el manejo de fallos inesperados.

Nuestros empleados utilizan una versión beta de la aplicación para poner a prueba continuamente nuevos desarrollos antes de que lleguen a los usuarios. Hicimos un reportero de comentarios sobre la aplicación de atrapar cualquier error antes de que llegue a los usuarios. Cada vez que se toma una captura de pantalla de las aplicaciones Uber, esta característica nos lleva a presentar una tarea de corrección de errores en Phabricator.

Fin…

No pude traducir el artículo completo por cuestiones de tiempo, pero eso si, traté de centrarme en las cosas importantes (una parte en realidad) y en el stack tecnológico, que creo podrá darnos algunas buenas pautas para que aprendamos como escalar a partir de una arquitectura monolítica.  Estos temas son relevantes para quienes desean formarse como arquitectos de software.  Conocer de tecnología es de hecho una habilidad dura que debiese correr por las venas de quienes deseen formarse en este interesante (y hermoso) mundo.  En la siguiente parte espero poder hablar más acerca de los asuntos relacionados con las app móviles y como interactuar en tiempo real cuando nos enfrentamos al problema geográfico, como distribuir la arquitectura lógica del software en capas que ayuden en parte a ir resolviendo estos problemas.  Espero les sea de utilidad…  Nos vemos!

Fuente: https://eng.uber.com/tech-stack-part-one/

1 comentario

Archivado bajo Arquitectura de Sistemas, Arquitectura de Software, Ingeniería de Software

La Ingeniería detrás de Uber (PARTE I)

El principio detrás de la compleja ingeniería de Uber se basa en algo que ya he comentado en otras oportunidades en este mismo blog: ¿Cómo escalar a partir de una arquitectura monolítica simple? ¿Cómo romper este esquema de trabajo para formar una arquitectura que soporte grandes cantidades de datos y tráfico y además nos provea de seguridad?.  La respuestas a estas preguntas las abordé en detalle en mi tesis de Magister en la cuál realicé un trabajo de investigación de las que en ese tiempo eran las principales plataformas de redes sociales: Facebook, Twitter, Instagram, Flirck. Y aunque Uber no entra directamente en la categoría de “red social”, usa los principios sociales y por supuestos los de ingeniería del software para hacer que su plataforma tecnológica vaya creciendo de la mano de su modelo de negocios.

La Arquitectura inicial monolítica de Uber

Inicialmente Uber partió en la ciudad de San Francisco, California, teniendo todo su código base y los repositorios diseñados para trabajar en esta parte geográfica del mundo, lo cuál les permitía resolver los problemas de negocio de manera “sencilla”, lo que incluía: conectar a los pasajeros con los transportistas, el sistema de pagos y facturación.  Para cumplir con estos requerimientos era razonable contar con toda esa lógica de negocios en un solo lugar, pero en la medida en que comenzaron a expandirse a otras ciudades y agregar nuevas funcionalidades, esto ya no era tan razonable.

En la medida en que los “domain models” comenzaron a crecer en conjunto con la adición de nuevas características, los componentes se comenzaron a tornar ALTAMENTE ACOPLADOS (recordemos que uno de los principios fundamentales de ingeniería de software es mantener los componentes lo menos acoplados posible), y esto logró que la encapsulación y la separación de intereses se tornara un trabajo difícil.  Por lo tanto la tarea primordial del equipo de ingeniería de Uber era encontrar una forma en que rápidamente se pudieran integrar piezas de código al modelo de negocio; y acá es donde entra la integración continúa.

¿Cómo lograr un buen escalamiento cuando tenemos diseñada nuestra plataforma para un solo repositorio?

El cambio a SOA

Uber decidió seguir el ejemplo de empresas como: Amazon, Twitter, Netflix, SoundCloud y romper el esquema monolítico base para formar una arquitectura orientada a servicios (SOA).  En concreto, SOA puede significar una variedad de cosas distintas (como término, algo que abordé en el artículo Distinguiendo entre SaaS y SOA), sin embargo Uber decidió abordar SOA a partir del uso del patrón de microservicios.  Para no inventar la rueda, voy a recurrir a la genial explicación de Martín Fowler:

Una arquitectura monolítica pone toda su funcionalidad en un único proceso, y la forma en que tiene de escalar (crecer) es agregando múltiples servidores.

Una arquitectura de microservicios pone cada funcionalidad (lo más atómica posible) en un servicio separado, y la forma que tiene de crecer es distribuyendo estos servicios a través de los servidores, replicando de acuerdo a las necesidades del negocio.

Cada servicio puede ser escrito en su propio lenguaje y puede o no tener su propia base de datos.

Esto resuelve varios problemas, pero también aparecen algunos nuevos, los cuales están clasificados en las siguientes áreas:

  1. Obviousness
  2. Safety
  3. Resilience

PD: uso los términos en inglés porque a veces es difícil encontrar una correcta traducción al texto sin que esto vaya en desmedro del contexto.

Obviousness

Con más de 500 servicios, encontrar el servicio adecuado puede tornarse en una ardua tarea.  Toda vez identificado el servicio, la forma en que se utilizará este servicio no es tan obvia, ya que cada microservicio tiene estructurado su propio camino.  Los servicios que ofrecen REST o RPC (donde es posible acceder a su funcionalidad dentro de su propio dominio -lo que se conoce como stateless-), se caracterizan por ofrecer contratos débiles, y en el caso de Uber, los contratos varían mucho entre microservicios.  La adición de un esquema JSON a una API REST puede mejorar la seguridad y el proceso de desarrollo contra el servicio, pero no es trivial de escribir o mantener.  Por último, estas soluciones no ofrecen ninguna garantía con respecto a la tolerancia a fallos o la latencia. No hay manera estándar para manejar los tiempos de espera del lado del cliente y las interrupciones, o garantizar que una interrupción de un servicio no cause interrupciones en cascada. La capacidad de recuperación global del sistema se vería afectada negativamente por estas debilidades. Como un desarrollador escribió,  “convertimos nuestra API monolítica en una API monolítica distribuida”.

Se ha hecho evidente que necesitamos una forma estándar de comunicación que ofrezca la seguridad de tipos, la validación y la tolerancia a fallos. Otros objetivos incluyen:

  • Formas sencillas para proporcionar bibliotecas de cliente
  • Soporte “Cross Language”
  • Tiempos de espera sintonizables con políticas de reintento
  • Desarrollo y Testing Eficiente

En esta etapa de nuestro hiper-crecimiento, los ingenieros de Uber continúan evaluando tecnologías y herramientas para adaptarse a nuestras metas. Una cosa que sí sabemos es que el uso del ya existente Lenguaje de definición de interfaz (IDL) que proporciona una gran cantidad de herramientas pre-construidas desde el primer día es ideal.

Se evaluaron las herramientas existentes y encontramos que Apache Thrift (popularizada por Facebook y Twitter) cumplió con nuestras necesidades. Thrift es un conjunto de bibliotecas y herramientas para la construcción de servicios de lenguajes cruzados altamente escalables. Para lograr esto, los tipos de datos y las interfaces de servicios se definen en un archivo que es agnóstico del lenguaje de programación. A continuación, el código se genera para abstraer el transporte y la codificación de mensajes RPC entre los servicios escritos en todos los lenguajes que usamos (Python, Node, Go, etc.)

Safety

El argumento más convincente para Thrift es su seguridad. Thrift garantiza la seguridad de la unión (binfing) de los servicios al utilizar contratos estrictos. El contrato describe cómo interactuar con ese servicio incluyendo como llamar a los procedimientos de ese servicio, lo que proporcionan entradas y salida de lo que se espera al momento de ejecutarlo.

La adhesión a un estricto contrato significa menos tiempo que se dedica a encontrar la manera de comunicarse con un servicio y hacer frente a la serialización. Además, como microService evoluciona no tenemos que preocuparnos acerca de las interfaces que cambian repentinamente, y somos capaces de desplegar servicios de forma independiente de los consumidores. Esta es una muy buena noticia para los ingenieros de Uber. Estamos en condiciones de pasar a otros proyectos y herramientas desde Thrift resolviendo el problema de la seguridad fuera de la caja.

Resilience

Por último, nos inspiramos en la tolerancia a fallos y las bibliotecas de latencia en otras empresas que se enfrentan a problemas similares, tales como Netflix que usa la biblioteca Hystrix y de Twitter la biblioteca Finagle , para abordar el problema de la resistencia. Con esas bibliotecas en mente, escribimos bibliotecas que aseguran los clientes son capaces de hacer frente a situaciones de fallo con éxito (que se discutirá con más detalle en un próximo post).

¿Hacia dónde se dirige Uber?

Claramente a mejorar la escalabilidad organizacional y proveer mayor resistencia y tolerancia a fallos usando la arquitectura de microServicios.  Ellos entienden que hasta este punto la solución no es perfecta y requiere de cambios, desafortunadamente existen pocas herramientas alternativas para Python y Node que son parte del stack de desarrollo de Uber y se requiere de buena inversión de tiempo para construirlas.  Lo interesante, es ver que si es posible migrar un modelo monolítico a uno de mayor escalabilidad como SOA (implementado a través de micro servicios) considerando la evolución de nuestro modelo de negocios, ya lo ha hecho Facebook y Twitter en el pasado, y los chicos de Uber no quisieron quedar fuera.

Lo que se viene en la Parte II:

Ya nos adentraremos completamente en el stack de Uber, hablaremos tanto de su backend como de casi todo su stack tecnológico pasando por la arquitectura lógica y física, plataformas, lenguajes de programación, entre otros.  Créanme que lo que estos chicos realizan a nivel de Frontend y Backend es muy interesante.

Fuentes de información:

  1. https://eng.uber.com/soa/
  2. http://highscalability.com/

2 comentarios

Archivado bajo Arquitectura de Sistemas, Arquitectura de Software, Ingeniería de Software, SOA

¿Estilo arquitectónico en ‘Layers’ o ‘Tiers’?

Al parecer existe una confusión respecto al término aplicación n-capas cuando este se lleva al idioma español. El problema principal es que en inglés se manejan dos conceptos a nivel de arquitectura:

  • Aplicaciones n-Tier
  • Aplicaciones n-Layer

Ambos términos significan “de n capas”; pero existe una gran diferencia respecto al significado de cada uno de ellos. Una arquitectura n-Tier se refiere a la distribución física de las capas, es decir donde corre el código y los procesos. Una arquitectura n-Layer se refiere a la distribución lógica de las capas, es decir, como esta estructurado el código.

En la siguiente figura podemos ver una aplicación n-tier – una aplicación web – que contiene 3 capas, una capa en el cliente, otra en el servidor IIS, y otra en la base de datos; es decir, el navegador, el servidor Web y el servidor de bases de datos corren en diferentes máquinas.

image21

Por otra parte, una arquitectura n-Layer define simplemente como se organiza el código. Normalmente incluye una capa de presentación, una capa de negocios, una capa de acceso a datos, una capa de entidades de negocio y una capa de datos – repositorio de datos. El hecho de que se dividan las capas para organizar el código, no significa que las capas obligatoriamente deban corren en diferentes máquinas o que deben estrictamente correr en una sola máquina o en un único proceso.

La siguiente figura detalla una arquitectura n-Layer básica.

image_thumb[6]

Como podemos ver en la figura, en una arquitectura n-layer las capas solamente interactúan con sus capas adyacentes lo que permite abstraer funcionalidades de las capas superiores e inferiores. Por ejemplo, la capa de presentación no se da cuenta que tipo de base de datos o que repositorio de datos se utiliza por que esta solamente se comunica con la capa de negocios, y el repositorio de datos no se da cuenta en donde se esta utilizando o desplegando la información ya que este interactúa con la capa de acceso a datos.

Fuente: http://icomparable.blogspot.com/2008/10/arquitectura-n-tier-o-arquitectura-n.html

Capas

Las capas son las agrupaciones lógicas de los componentes de software que forman la aplicación o servicio. Ellos ayudan a diferenciar entre los distintos tipos de tareas realizadas por los componentes, lo que hace que sea más fácil crear un diseño que soporta la reutilización de los componentes. Cada capa lógica contiene un número de tipos de componentes discretos agrupados en sub-capas, con cada subcapa realizando un tipo específico de tarea. Al identificar los tipos genéricos de componentes que existen en la mayoría de las soluciones, se puede construir un mapa significativo de una aplicación o servicio, y luego utilizar este mapa como un modelo para su diseño. La división de una aplicación en capas separadas que tienen distintos roles y funciones ayuda a maximizar la mantenibilidad del código, optimizar la forma en que la aplicación funciona cuando se despliega de maneras diferentes, y proporcionar una clara delimitación entre los lugares donde se debe usar determinada tecnología o decisiones de diseño.

Presentación, negocio y servicios de datos

En el nivel más alto y más abstracto, la vista de la arquitectura lógica de un sistema puede ser considerado como un conjunto de servicios de cooperación agrupados en las siguientes capas, como se muestra en la Figura 1.Figura 1 La vista de la arquitectura lógica de un sistema de capas de las secciones el diseño de la aplicación se muestra en la Figura 1 se puede considerar como tres conjuntos básicos de servicios:

Figura 1 La vista de la arquitectura lógica de un sistema de capas

Figura 1 La vista de la arquitectura lógica de un sistema en capas

  • Servicios de presentación . Estos son los servicios orientados al usuario responsables de la gestión de la interacción del usuario con el sistema, y generalmente consisten en componentes situados dentro de la capa de presentación. Constituyen un puente común en la lógica de negocio del núcleo encapsulado en los servicios de negocio (business services).
  • Servicios de negocios (business services) . Estos servicios implementan la funcionalidad básica del sistema, y encapsulan la lógica de negocio relevante. Por lo general, consisten en componentes situados en la capa de negocio, que pueden exponer las interfaces de servicio que otros usuarios pueden utilizar.
  • Los servicios de datos (data services) . Estos servicios proporcionan acceso a los datos que se alojan dentro de los límites del sistema y los datos expuestos por otros sistemas back-end, tal vez accede a través de los servicios. La capa de datos expone los datos a la capa de negocio a través de interfaces genéricas diseñadas para ser convenientes para el uso de servicios de negocio (business services).

Componentes

Cada capa de una aplicación contendrá una serie de componentes que implementan la funcionalidad de esa capa. Estos componentes deben ser cohesivos y débilmente acoplados para simplificar la reutilización y el mantenimiento. La Figura 2 muestra los tipos de componentes que se encuentran comúnmente en cada capa.

Figura 2 Tipos de componentes que se encuentran comúnmente en cada capa

Figura 2 Tipos de componentes que se encuentran comúnmente en cada capa

Componentes de la capa de presentación

Los componentes de la capa de presentación implementan la funcionalidad necesaria para permitir a los usuarios interactuar con la aplicación. Los siguientes tipos de componentes se encuentran comúnmente en la capa de presentación:

  • componentes de la interfaz de usuario (UI) . Estos componentes proporcionan el mecanismo para que los usuarios interactúen con la aplicación. Los datos de formato para su visualización, adquirir y validar los datos introducidos por los usuarios.
  • Componentes de proceso de interfaz de usuario . Para ayudar a sincronizar y organizar las interacciones del usuario, puede ser útil para impulsar el proceso utilizando distintos componentes del proceso de interfaz de usuario. Esto evita que el flujo del proceso y la lógica de gestión de estado de ser codificada en los elementos de interfaz de usuario en sí, y le permite volver a utilizar los mismos patrones básicos de interacción con el usuario en otras interfaces de usuario (básicamente se refiere a separar los componentes de UI de la lógica de implementación de dichos componentes), para mayores referencias consultar el patrón MVP (Model View Presenter).

Componentes de la capa de Negocio

Los componentes empresariales de esta capa implementan la funcionalidad básica del sistema, y ​​encapsulan la lógica de negocio relevante. Los siguientes tipos de componentes se encuentran comúnmente en la capa de negocio:

  • Fachada de aplicaciones (Application façade). Esto es una característica opcional que se puede utilizar para combinar múltiples operaciones empresariales en un solo envió un mensaje a base de operaciones. Esta característica es útil cuando se localice los componentes de la capa de presentación en un nivel físico independiente de los componentes de la capa de negocio, lo que le permite optimizar el uso del método de comunicación que los une.
  • Los componentes empresariales (Business components) . Estos componentes implementan la lógica de negocio de la aplicación. Independientemente de que un proceso de negocio se compone de un solo paso o un flujo de trabajo orquestado, su aplicación es probable que requieren componentes que implementan las reglas de negocio y realizar tareas de oficina.
  • Flujos de trabajo empresariales (Business workflow) . Después de que los componentes de interfaz recogen los datos necesarios del usuario y lo pasa a la capa de negocio, la aplicación puede utilizar esta información para llevar a cabo un proceso de negocio. Muchos procesos de negocio implican varios pasos que se deben realizar en el orden correcto, y pueden interactuar entre sí a través de una orquestación. Los componentes empresariales de flujo de trabajo definen y coordinan las de larga duración, de pasos múltiples procesos de negocio, y se puede implementar utilizando herramientas de gestión de procesos de negocio.
  • Componentes de entidad empresarial (Business entity components) . Las entidades empresariales se utilizan para pasar los datos entre los componentes. Los datos representan entidades del mundo real de negocios, tales como productos o pedidos. Las entidades empresariales que la aplicación utiliza internamente suelen ser estructuras de datos, como DataSets, DataReaders, o Lenguaje de marcado extensible (XML) corrientes, pero también se puede implementar utilizando clases personalizadas orientados a objetos que representan las entidades del mundo real que la aplicación manejará.

Componentes de la capa de datos

Los componentes de la capa de datos facilitan el acceso a los datos que se aloja dentro de los límites del sistema y los datos expuestos por otros sistemas back-end. Los siguientes tipos de componentes se encuentran comúnmente en la capa de datos:

  • Componentes de acceso a datos (Data access components). Estos componentes abstraen la lógica necesaria para acceder a los almacenes de datos subyacentes. Si lo hace, centraliza la funcionalidad de acceso a datos y hace la aplicación más fácil de configurar y mantener.
  • Ayudante de datos y componentes de servicios públicos (Data helper and utility components). La mayoría de las tareas de acceso a datos requieren lógica común que pueda ser extraída y aplicada en distintos componentes de ayuda reutilizables. Esto ayuda a reducir la complejidad de los componentes de acceso a datos y centraliza la lógica, lo que simplifica el mantenimiento. Otras tareas que son comunes en componentes de la capa de datos, y no es específica de un conjunto de componentes, pueden ser implementados como componentes de servicios separados. Ambos componentes de ayuda y utilidad a menudo puede ser reutilizado en otras aplicaciones.
  • Los agentes de servicio (Service agents). Cuando un componente de negocio debe utilizar la funcionalidad proporcionada por un servicio externo, puede que tenga que implementar código para administrar la semántica de la comunicación con ese servicio en particular. Los Agentes del Servicio permiten aislar las idiosincrasias de diversos servicios de llamadas desde la aplicación, y puede proporcionar servicios adicionales, tales como la cartografía básica entre el formato de los datos expuestos por el servicio y el formato que requiere su aplicación.

Componentes transversales

Muchas de las tareas llevadas a cabo por el código de una aplicación se requieren en más de una capa. Los componentes transversales implementan tipos específicos de funcionalidad que se puede acceder a partir de componentes en cualquier capa. Los siguientes son los tipos comunes de componentes transversales:

  • Componentes para la implementación de la seguridad . Estos pueden incluir componentes que realizan la autenticación, autorización y validación.
  • Componentes para la implementación de tareas de gestión operacional . Estos pueden incluir componentes que implementan las políticas de manejo de excepciones, registro, contadores de rendimiento, configuración y localización.
  • Componentes para implementar la comunicación . Estos pueden incluir componentes que se comunican con otros servicios y aplicaciones.

(Continúa en http://apparchguide.codeplex.com/wikipage?title=Chapter%209%20-%20Layers%20and%20Tiers)

Referencias:

http://blogs.msdn.com/b/jmeier/archive/2008/09/06/layers-and-tiers.aspx

http://www.hanselman.com/blog/AReminderOnThreeMultiTierLayerArchitectureDesignBroughtToYouByMyLateNightFrustrations.aspx

http://queens.db.toronto.edu/~papaggel/courses/csc309/docs/lectures/web-architectures.pdf

http://archive.systems.ethz.ch/www.systems.ethz.ch/education/hs11/eai/lectures/Chapter-1-EAI-2011-Layers.pdf

http://morphological.files.wordpress.com/2011/08/5-layer-architecture-draft.pdf

Deja un comentario

Archivado bajo Arquitectura de Sistemas, Arquitectura de Software, Diseño

Análisis de las plataformas de redes sociales actuales para obtener patrones arquitectónicos comunes y rescatar las mejores prácticas

Resumen

La presente investigación aborda la aplicación de técnicas de la Ingeniería de Software, básicamente aquellas relacionadas con Ingeniería de Requerimientos, Patrones de Diseño y Arquitectura, que permitan la creación de un modelo en función del modelo de calidad FURPS+ y patrones arquitectónicos comunes dentro de las plataformas de redes sociales mencionadas a continuación: Facebook, Twitter, Linkedin, Flickr y Myspace. Dicha investigación estará enmarcada dentro del ámbito de los Requerimientos no Funcionales (RNF) de las plataformas anteriormente mencionadas, considerando las posibles relaciones con los requerimientos funcionales (RF).

El análisis y búsqueda de patrones comunes en esta investigación, propondrá buscar la solución (es) temprana (s) a los problemas identificados tales como: persistencia de los datos, problemas asociados al almacenamiento y caching de la información, problemas de seguridad, problemas de escalabilidad de arquitectura, problemas de usabilidad y problemas de desempeño [1]; para crear un modelo en función de FURPS+ que aporte en el diseño arquitectónico de nuevas plataformas relacionadas con los requerimientos no funcionales y sus posibles conexiones con los requerimientos funcionales. Rescatando de esta investigación, las prácticas actuales utilizadas en el diseño de este tipo de plataformas.

Abstract

This investigation focuses on the application of techniques of software engineering, primarily those relating to Requirements Engineering, Design Patterns and Architecture, enabling the creation of a model based on the quality model FURPS + and architectural patterns common in platforms social networks listed below: Facebook, Twitter, Linkedin, Flickr and Myspace. This investigation is framed within the scope of non-functional requirements (NFR) of the platforms mentioned above, considering the possible relationships with the functional requirements (FR).

The analysis and search for patterns in this research, propose to find the solution (s) early (s) to the identified problems such as data persistence, problems associated with storage and caching of information security problems, problems scalable architecture, usability and performance problems [1], to create a model based on FURPS + to provide the architectural design of new platforms related to non-functional requirements and their possible connections with the functional requirements. Recovering from this research, current practices used in the design of such platforms.

Introducción

El auge de las redes sociales [2] y el gran impacto que tienen en el mundo de la Internet nos hace pensar que su popularidad hace que cada vez crezcan más y abarquen contenidos especializados y acorde a las tendencias tecnológicas y capacidades de la nueva Web 2.0.

Las nuevas tecnologías, más allá de aportar la más potente herramienta de comunicación conocida, están configurando una nueva forma de entender y organizar la sociedad, con las posibilidades y los riesgos que ello conlleva. Esta evolución de la tecnología, genera cambios radicales en el comportamiento del usuario tales como: la disminución del uso del teléfono fijo, el contacto más abierto con personas de otras nacionalidades, entre otros; con un sostenido crecimiento que provoca que los mismos usuarios creen, compartan y distribuyan contenido en la web. Este paradigma social, esta conducido por la popularidad surgida de las llamadas redes sociales de la Internet [3], las cuales permiten al usuario construir y compartir sus propios contenidos. Sitios como Flickr [4,5] donde los usuarios pueden compartir fotos, y Facebook [6,7], donde los usuarios intercambian información, videos, intereses, entre otros; son parte de la popularidad y el paradigma social.

De acuerdo a la información proporcionada por Nielsen/NetRatings1, el aumento del tráfico de las redes sociales ha tenido un crecimiento del 47% en el último año, alcanzando el 45% de todos los usuarios activos de la Web [8], estos niveles confluentes de usuarios son posibles gracias a las bajas barreras de entrada (un simple registro) que proporcionan estas comunidades. Muchos de estos servicios que ofrecen las redes sociales están diseñados de forma tan simple como iniciar sesión, ver el contenido y comenzar a subir datos a la plataforma. Esto permite al usuario que no está calificado técnicamente, participar con aquellos usuarios más experimentados.

Los patrones de acceso y recursos ofrecidos por estas plataformas se caracterizan por la variabilidad e imprevisibilidad de las interacciones sociales (p.e. los llamados slashdot effects [9]), además de la naturaleza propia de lectura y escritura a través de mensajes multimedia que ocurre dentro de estos servicios, los cuales generan una significativa cantidad de operaciones de carga con respecto a los tradicionales Web Services [10]. Siguiendo con esta línea, se observa que los servicios de redes sociales presentan una amplia gama de contenido multimedia, desde blogs hasta sitios donde la interacción ocurre con las imágenes y videos, estos factores determinan un cambio radical en el tipo y cantidad de datos que son transferidos.

La combinación de estos tipos de interacción con el usuario y los propios contenidos multimedia introducen nuevos requerimientos tanto de servidores como de infraestructura que agregan nuevas características a las tradicionales aplicaciones basadas en la Web. Si bien, existen varios estudios relacionados con el rendimiento y análisis de los cuellos de botella para aplicaciones web tradicionales [11,1], no se encontraron estudios que profundicen aún más sobre los requerimientos arquitectónicos y patrones comunes existentes en las plataformas de redes sociales.

La principal contribución de esta investigación es:

  • Buscar los lineamientos arquitectónicos y de diseño comunes entre cinco grandes plataformas de redes sociales: Facebook, Flickr, Myspace, Linkedin y Twitter, los cuales se caracterizan por tener diferentes cantidades de contenidos multimedia,
  • considerar para cada una de las redes sociales mencionadas anteriormente, los requerimientos no funcionales, buscando las posibles conexiones que existan con los requerimientos funcionales,
  • encontrar denominadores comunes en los patrones y el diseño de este tipo de plataformas,
  • de forma tal de poder rescatar de todo ello, las buenas prácticas actuales.
Referencias

[1] Q. Zhang, A. Riska, E. Riedel, and E. Smirni, “Bottlenecks and their performance implications in e-commerce systems,” in In Proc. of 9th International Workshop on Web Content Caching and Distribution, Beijing, China, 2004.

[2] Andrew Lipsman. (2007, July) http://www.comscore.com. [Online]. http://www.comscore.com/Press_Events/Press_Releases/2007/07/Social_Networking_Goes_Global

[3] A. C.Weaver and B. B. Morrison, “Social Networking,” IEEE Computer Magazine, pp. 41(2):97-100, 2008.

[4] (2008) Flickr. [Online]. http://www.flickr.com/

[5] N. Van House, “Flickr and public image sharing: distant closeness and photo exhibition,” in Conference on Human Factors in Computing Systems (CHI’07), San Jose, CA, 2007.

[6] Facebook. (2004) [Online]. http://www.facebook.com

[7] Instiuto de Maquina Herramienta. (2009) Manual sobre Facebook: redes sociales para usuario y para empresa. [Online]. http://www.imh.es/dokumentazio-irekia/manuales/manual-facebook-redes-sociales-para-usuario-y-para-empresa

[8] S. Bausch and L. Han, “Social Networking Sites Grow 47 Percent, Year over Year, Reaching 45 Percent of Web Users,” Nielsen/NetRatings Research Report, 2007.

[9] Alexander M Campbell Halavais, “The Slashdot effect : analysis of a large-scale public conversation on the World Wide Web,” University of Washington, Washington, Thesis (Ph. D.) 2001. [Online]. http://en.wikipedia.org/wiki/Slashdot_effect

[10] Francisco Curbera, Matthew Duftler, Rania Khalaf, and William Nagy, “Unraveling the Web Services Web,” IBM T.J.Watson Research Center, Research 2002.

[11] E. Cecchet, A. Chanda, S. Elnikety, J. Marguerite, and W. Zwaenepoel, “Performance comparison of middleware architectures for generating dynamic Web content,” in In Proc. of ACM/IFIP/USENIX International Middleware Conference (Middleware 2003), Rio de Janeiro, Brazil, 2003.

Download full Document (spanish)

Autor: Juan José González F.

Docente medio tiempo Universidad Andrés Bello

Magister en Ingeniería Informática con mención en Ingeniería de Software

jjegonzalezf@gmail.com

2 comentarios

Archivado bajo Arquitectura de Sistemas, Arquitectura de Software, Ingeniería de Software, Magister en Informatica

PSP (Personal Software Process), un enfoque práctico

Desde que me mencionaron Personal Software Process (PSP) supe que algo de interesante había en él. Por lo que como todo buen investigador, decidí comenzar a incursionar para ver que cualidades podía ofrecerme al trabajo del día a día.

Obviamente lo primero, era dar con el material de origen de sus creados, y gracias a la guía de mi profesor de Estimación y Métricas (Magister en Ingeniería Informática, Unab, Chile), pude obtener el material tan anhelado en PDF, obtenido desde el SEI (Software Engineering Institute, http://www.sei.cmu.edu/), el cual se puede descargar desde acá: http://www.sei.cmu.edu/tsp/tools/index.cfm.

El PSP amplia el proceso de mejora a la gente que realiza el trabajo de desarrollo de software, concentrándose en las practicas de trabajo de los ingenieros en una forma individual, enseñando como manejar la calidad desde el principio de un producto. PSP son nuestras propias métricas, que permiten estructurar y ordenar nuestro trabajo del día a día (no solo de desarrollo de software, esto lo voy a explicar mas adelante). El resultado de nuestro trabajo, además puede ser llevado a un trabajo en equipo TSP (Team Process Software), el cual es “comandado” por un sistema de gestión de la configuración y por supuesto, un Jefe de Proyecto quien evalúa los resultados y avances de los miembros del equipo.

En el campo del desarrollo del software son pocas las organizaciones que siguen o cumplen planes de trabajo o
metodologías establecidas para desarrollar software (conozco varias que no siguen este proceso), poniendo en duda su calidad; muchos de estos proyectos llegaron al fracaso porque sobrepasaron los costos estimados y/o sobrepasaron los tiempos de planificación. Muchos de estos sistemas que tenían defectos produjeron en algún momento perdida de vidas humanas. Proyectos de millones de dólares que no han cumplidos sus objetivos y su tiempo de planificación dejaron millones de usuarios insatisfechos, principalmente aquellos que trabajan mediante una aplicación de software. Algunas principales causas para que el proceso de desarrollo de software pueden ser que : el personal de desarrollo no se involucre lo suficiente en el control de calidad del producto, la alta dirección no esta consciente de la verdadera importancia del proyecto a causa de que no se cuentan los recursos necesarios (dinero, tiempo, tecnología), las prácticas establecidas no son las adecuadas, las empresas se centran en cómo pero no tienen claro el qué, (Vamos a desarrollar esta aplicación en Biztalk Server con este Framework porque es el último del mercado y además tenemos que aprovechar las licencias… a quien no le ha pasado), la relación problema/necesidad muchas veces no existe, no se preocupan de analizar si los objetivos del proyecto; tienen cobertura con los objetivos de la empresa, etc etc (Echemosle para adelante no mas, en el camino lo vamos arreglando!).

En la actualidad la tecnología avanza a pasos agigantados, así también existe un avance en las metodologías y herramientas para el desarrollo de software. Una de estas metodologías es el denominado Personal Software Process (PSP) diseñado por Watts S. Humphrey del Software Engineering Institute en la Carnegie Mellon University.

La producción de software, debe convertirse en un proceso industrial, que sea medible, cuantificable, testeable, que sea un proceso disciplinado y aceptado por todos.  El ciclo de vida clásico (Waterfall) que todos conocemos es el cascada, que tiene las siguiente etapas:

· Análisis de Requerimientos

· Diseño

· Programación

· Pruebas

· Implantación

· Mantenimiento

Esta metodología era muy usada, cuando las actividades eran secuenciales, y ayudaba bastante, pero hoy en día, ya no tenemos este tipo de actividades tan secuenciales, tenemos procesos que se orientan mas al cliente y al producto para satisfacer las necesidades del cliente en distintas fases (llamadas iteraciones), en donde en cada iteración, el cliente puede ver un producto tangible y probarlo.  SCRUM es una de estas metodologías.  Actualmente existen diversas metodologías de ingeniería del software que guían a los programadores a dar un mejor seguimiento a sus programas, dentro de las que podemos mencionar: COCOMO I, COCOMO II, PROBE (Proxy Based Estimation), etc etc.  En algún otro POST vamos a hablar mas a fondo de estimación y métricas en el desarrollo de software.

Volviendo a PSP, es una técnica probada para mejorar el funcionamiento y la productividad individuales de los ingenieros. Surge de la necesidad que tienen los  Ingenieros de Software de automatizar sus procesos.

PSP fue diseñado para ayudar a los profesionales del software para que utilicen constantemente practicas sanas de ingeniería del software, enseñándoles a planificar y dar seguimiento a un trabajo, utilizar un proceso bien definido y medido, a establecer metas mesurables y finalmente a  rastrear constantemente  para obtener las metas definidas (quiero hacer un paralelo en esto último mencionando una técnica bastante entretenida llamada GQM -Goal Question Metrics-).

El PSP es una versión pequeña de CMM donde se preocupa solo por un conjunto de las KPAs (Key Process Areas).  La estructura de PSP es como sigue:

Los principios de PSP son:

  1. Cada ingeniero es diferente, para ser mas eficiente, debe planificar su trabajo basándose en su experiencia personal.
  2. Usar procesos bien definidos y cuantificados
  3. Los ingenieros deben asumir la responsabilidad  personal de la calidad de sus productos.
  4. Cuanto antes se detecten y corrijan los errores menos esfuerzo será necesario
  5. Es mas efectivo evitar los defectos que detectarlos y corregirlos.
  6. Trabajar bien es siempre la forma mas rápida y económica de trabajar.

El PSP se caracteriza porque es de uso personal y se aplica a programas pequeños de menos de 10.000 líneas de código. Se centra en la administración del tiempo y en la administración de la calidad a través de la eliminación temprana de defectos.

En la próxima entrega, vamos a hablar un poco acerca de los niveles de PSP, y como 14 KPA’s de PSP son posible mapearlas con 18 KPA’s de CMMi.

Algunas pantallas del software que yo uso para llevar por ejemplo, un proyecto de investigación personal usando los principios de PSP, las adjunto mas abajo:

 

Bueno, será hasta la próxima, espero haber aportado algo en esta primera etapa de PSP.

20 comentarios

Archivado bajo Arquitectura de Sistemas, Arquitectura de Software, Ingeniería de Software, Magister en Informatica

Discussion about the difference between architectural styles and architectural patterns

Pedro Veloso Hernandez (Master in Software Engineering, UPM):

Clearly one of the first differences I see, are given in that while architectural patterns provide a comprehensive solution components, structures and technology, using it as one of their tools “design patterns”, architectural styles provide guided solutions based on a more abstract model, which although has a heuristic is not as specific when detailing which components, technology or under what circumstances these must be grouped. even, I would indicate that a particular architectural pattern, it could be used as a reference or “architectural styles” for its implementation in accordance with the expectations of the problem to be solved.

Juan José González F. (Master candidate in Computer Engineering, UNAB):

Excellent, then we are in tune, as the conclusion that I was getting is:

  • An architectural style organizes the central concept of a system. This concept can be modeled simply using boxes and arrows to describe it.
  • An architectural pattern describes the system at a higher level of granularity, considering their subsystems, modules and relations between them. Unlike before, this should be modeled using a standard notation, for example UML.

Thanks!

Miroslav Pavlovic (Master in Expert Systems and Artificial Intelligence, MBA of IEDE Spain, Member of IEEE-Standard Association):

Pending…

Daniel Campos Domínguez (Master of Science in Computer Science, State University of New York at Buffalo, EEUU):

Juan José:

The SEI Definition:

Architectural pattern: A description of element and relation types together with a set of constraints on how they are used. The term architectural style has also been widely used to describe it

Architectural style: A specialization of element and relation types, together with a set of constraints on how they can be used. See architectural pattern

According to the SEI both terms have been used almost as synonymous …

McGovern, Ambler, Stevens, Linn, Sharan, in A Practical Guide to Enterprise Architecture (The Coad Series):

What’s the difference between an architectural style, an architectural pattern, and a system metaphor?   The answer is not much.  An architectural style (Base et al. 1997) and an architectural pattern (Buschmann et al. 1996) are essentially synonymous.  A system metaphor is similar but more conceptual than an architecture pattern or an architectural style, and it relates more to a real-world concept than to a software engineering concept.  An architectural style and an architectural pattern are similar to a design pattern in that they both describe a solution to a problem in a particular context.  The only difference is the granularity at which they describe the solution.  In a design pattern, the solution is relatively fine grained and is depicted at the level of language classes.  In an architectural pattern, the solution is coarser grained and is described at the level of subsystems or modules and their relationships and collaborations.  Each subsystem or module within an architectural pattern consists of many language classes that are designed using design patterns.

Look at this:

http://www.infoq.com/news/2009/02/Architectural-Styles-Patterns

http://shapingsoftware.com/2009/02/09/architectural-styles/

http://msdn.microsoft.com/en-us/library/ee658117.aspx

There are discrepancies regarding the synonymy of two terms. In my opinion, you should take a stand and, beyond that you take, be able to support it properly.

Juan José González F. (Master candidate in Computer Engineering, UNAB):

Thank you very much for the references and response:

The original conception of the idea that “The concept can be modeled simply using boxes and arrows to describe it.”. vs. the need to model architectural patterns using UML. Is not mine, is a viewpoint rescued from Craig Larman’s book. UML and Patterns. 2nd edition, Madrid, Prentice Hall.

Original reference:

The same goes for the visuals: the styles are described by simple boxes and lines, while the patterns are usually represented in UML [Lar03].

My interpretation makes sense to Larman said, mainly because, seen from an abstract viewpoint and high-level, do not need a formal notation to describe a system to detect the architectural styles or I can simply use flows, or boxes with arrows, or a context diagram with bubbles, etc etc. However, when I go into more specific details of architecture, when they begin to see structures, common forms within the systems and relationships, these are usually represented through a more formal notation (eg UML) as these represented patterns through formal notations, then, I must maintain the standard.

Thanks for everything.

Daniel Campos Domínguez (Master of Science in Computer Science, State University of New York at Buffalo, EEUU):

It is an opinion … the problem is the boxes and lines represent uniquely allowing only two kinds of concepts and semantics of the representation is not conventional.Therefore, is subject to free interpretation by introducing more ambiguity receptor a formal representation from the standpoint of syntactic / semantic.

Daniel

References

[1] Paris Avgeriou (paris@cs.rug.nl), Uwe Zdun(zdun@acm.org), Focus Group Report: Architectural Patterns in Practice, University of Groningen Vienna/University of Economics and BA.

[2] P. Avgeriou and U. Zdun. Architectural patterns revisited – a pattern language. In Proceedings of 10th European Conference on Pattern Languages of Programs (EuroPlop 2005), Irsee, Germany, July 2005

2 comentarios

Archivado bajo Arquitectura de Sistemas, Arquitectura de Software, Ingeniería de Software, Magister en Informatica

Analysis of current social networking platforms for common architectural patterns and rescue best practice.

An approach from the viewpoint of non-functional requirements.

Master, Computer Engineering, Unab.

Santiago, Chile, 2010

Author: Juan José González Faúndez

Abstract:

This investigation focuses on the application of techniques of software engineering, primarily those relating to Requirements Engineering, Design Patterns and Architecture, enabling the creation of a model based on quality models ISO 9126, FURPS + and patterns common architectural platform within the following social networks: Facebook, Twitter, Linkedin, Flickr, Myspace. This investigation is framed within the scope of non-functional requirements (NFR) of the platforms mentioned above, considering the possible relationships with the functional requirements (FR).
The analysis and search for patterns in this research, propose to find the solution (s) to the identified problems such as data persistence, problems associated with storage and caching of information security problems, scalability problems of architecture,problems of data privacy and performance issues [1], to create a model based on FURPS + and ISO 9126 to provide the architectural design of new platforms related to non-functional requirements and their possible connections with the functional requirements. Recovering from this research, current practices used in the design of such platforms.

 

[1] Q. Zhang, A. Riska, E. Riedel, and E. Smirni, “Bottlenecks and their performance implications in e-commerce systems,” in In Proc. of 9th International Workshop on Web Content Caching and Distribution, Beijing, China, 2004.
[4] A. C.Weaver and B. B. Morrison, “Social Networking,” IEEE Computer Magazine, pp. 41(2):97-100, 2008.
[12] E. Cecchet, A. Chanda, S. Elnikety, J. Marguerite, and W. Zwaenepoel, “Performance comparison of middleware architectures for generating dynamic Web content,” in In Proc. of ACM/IFIP/USENIX International Middleware Conference (Middleware 2003), Rio de Janeiro, Brazil, 2003.
[13] Jose Daniel Garcia, Riccardo Lancellotti Claudia Canali, “Impact of Social Networking Services on the Performance and Scalability of Web Server Infrastractures,” University Carlos III of Madrid, 2009.
[14] Todd Hoff. (2010, Sep.) Facebook And Site Failures Caused By Complex, Weakly Interacting, Layered Systems. [Online]. http://highscalability.com/blog/2010/9/30/facebook-and-site-failures-caused-by-complex-weakly-interact.html
[18] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal, Pattern Oriented – Software Architecture. Germany: JOHN WILEY & SONS, 1996.
[22] danah and Nicole Ellison boyd. (2007) Social Network Sites: Definition, History, and Scholarship. Journal of Computer-Mediated Communication. [Online]. http://jcmc.indiana.edu/vol13/issue1/boyd.ellison.html
[27] Jose María Gil. (2009, Sep.) Ebook, La guía definitiva para enteder Twitter. [Online]. http://josemariagil.tv/la-guia-definitiva-para-entender-twitter
[29] Paul Clements, Rick Kazman Len Bass, Software Architecture in practice. USA: Addison-Wesley, 2002.
[30] Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline.: Prentice Hall, 1996.
[31] Mark Klein, Rick Kazman, and Robert Nord, “Attribute-Based Architectural Styles, Technical Report CMU/SEI-99-TR-22,” Software Engineering Institute (SEI), 1999.
[33] Larman Craig, UML y Patrones, Introducción al análisis orientado a objetos.: Prentice Hall.
[34] Ian Sommerville, Ingeniería de Software, 7th ed.: Pearson Addison Wesley, 2005.
[35] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns – Elements of Reusable Object-Oriented Software.: Addison-Wesley Professional, 1995.
[36] M. Shaw and D. Garlan, Software Architecture: Perspectives on an Emerging.: Addison-Wesley, 1996.
[37] Markus Schumacher, Eduardo Fernandez, Duane Hybertson, Frank Buschmann, and Peter Sommerlad, Security Pattern, Integrating Security and System Engineering.: Jhon Wiley & Sons Ltd, 2006.
[39] Hofmeister Christine, Nord Robert, and Soni Dilip, Applied software architecture.: Addison-Wesley Longman Publishing, 2000.
[40] Paris Avgeriou and Uwe Zdun, “Architectural Patterns Revisited – A Pattern Language,” CONCERT division, Fraunhofer IPSI – Department of Information Systems, Vienna University of Economics and BA, Darmstadt, Germany – Vienna, Austria,.
[41] IEEE, “Recommended Practice for Architectural Description of Software Intensive Systems,” IEEE, Technical Report IEEE-std-1471-2000 2000.
[42] Paul Clements et al., Documenting Software Architectures: Views and Beyond.: Addison-Wesley, 2002.
[43] Kruchten Philippe,., 1995, pp. 42-50.

 

Deja un comentario

Archivado bajo Arquitectura de Sistemas, Arquitectura de Software, Ingeniería de Software, Magister en Informatica