miércoles, 6 de junio de 2018

Arquitectura de Software




En el ámbito del software cada vez es más común escuchar el término “arquitectura de software”, y encontrar oportunidades de empleo para “arquitectos de software”. Aun así, este concepto tiende a ser malentendido y la falta de comprensión al respecto de sus principios frecuentemente repercute de manera negativa en la construcción de sistemas de software.
El concepto de arquitectura de software se refiere a la estructuración del sistema que, idealmente, se crea en etapas tempranas del desarrollo. Esta estructuración representa un diseño de alto nivel del sistema que tiene dos propósitos primarios: satisfacer los atributos de calidad (desempeño, seguridad, modificabilidad), y servir como guía en el desarrollo. Al igual que en la ingeniería civil, las decisiones críticas relativas al diseño general de un sistema de software complejo deben de hacerse desde un principio. El no crear este diseño desde etapas tempranas del desarrollo puede limitar severamente el que el producto final satisfaga las necesidades de los clientes. Además, el costo de las correcciones relacionadas con problemas en la arquitectura es muy elevado. Es así que la arquitectura de software juega un papel fundamental dentro del desarrollo.
¿Qué es la arquitectura de software?
Antes de elaborar sobre el tema, es conveniente definir el concepto ya que hoy en día el término de arquitectura se usa para referirse a varios aspectos relacionados con las TI. De acuerdo al Software Engineering Institute (SEI), la Arquitectura de Software se refiere a “las estructuras de un sistema, compuestas de elementos con propiedades visibles de forma externa y las relaciones que existen entre ellos.”
El término “elementos” dentro de la definición del SEI es vago a propósito, pues puede referirse a distintas entidades relacionadas con el sistema. Los elementos pueden ser entidades que existen en tiempo de ejecución (objetos, hilos), entidades lógicas que existen en tiempo de desarrollo (clases, componentes) y entidades físicas (nodos, directorios). Por otro lado, las relaciones entre elementos dependen de propiedades visibles (o públicas) de los elementos, quedando ocultos los detalles de implementación. Finalmente, cada conjunto de elementos relacionados de un tipo particular corresponde a una estructura distinta, de ahí que la arquitectura está compuesta por distintas estructuras.
¿Por qué es importante la arquitectura de software?
La arquitectura de software es de especial importancia ya que la manera en que se estructura un sistema tiene un impacto directo sobre la capacidad de este para satisfacer lo que se conoce como los atributos de calidad del sistema. Ejemplos de atributos de calidad son el desempeño, que tiene que ver con el tiempo de respuesta del sistema a las peticiones que se le hacen, la usabilidad, que tiene que ver con qué tan sencillo les resulta a los usuarios realizar operaciones con el sistema, o bien la modificabilidad, que tiene que ver con qué tan simple resulta introducir cambios en el sistema. Los atributos de calidad son parte de los requerimientos (no funcionales) del sistema y son características que deben expresarse de forma cuantitativa. No tiene sentido, por ejemplo, decir que el sistema debe devolver una petición “de manera rápida”, o presentar una página “ligera”, ya que no es posible evaluar objetivamente si el sistema cubre o no esos requerimientos.
La manera en que se estructura un sistema permitirá o impedirá que se satisfagan los atributos de calidad. Por ejemplo, un sistema estructurado de tal manera que una petición deba transitar por muchos componentes antes de que se devuelva una respuesta podría tener un desempeño pobre. Por otro lado, un sistema estructurado de tal manera que los componentes estén altamente acoplados entre ellos limitará severamente la modificabilidad. Curiosamente, la estructuración tiene un impacto mucho menor respecto a los requerimientos funcionales del sistema. Por ejemplo, un sistema difícil de modificar puede satisfacer plenamente los requerimientos funcionales que se le imponen.
Además de los atributos de calidad, la arquitectura de software juega un papel fundamental para guiar el desarrollo. Una de las múltiples estructuras que la componen se enfoca en partir el sistema en componentes que serán desarrollados por individuos o grupos de individuos. La identificación de esta estructura de asignación de trabajo es esencial para apoyar las tareas de planeación del proyecto.
Finalmente, los diseños arquitectónicos que se crean en una organización pueden ser reutilizados para crear sistemas distintos. Esto permite reducir costos y aumentar la calidad, sobre todo si dichos diseños han resultado previamente en sistemas exitosos.
El ciclo de desarrollo de la arquitectura
Dentro de un proyecto de desarrollo, e independientemente de la metodología que se utilice, se puede hablar de “desarrollo de la arquitectura de software”. Este desarrollo, que precede a la construcción del sistema, está dividido en las siguientes etapas: requerimientos, diseño, documentación y evaluación. Cabe señalar que las actividades relacionadas con el desarrollo de la arquitectura de software generalmente forman parte de las actividades definidas dentro de las metodologías de desarrollo.
A continuación, se describen dichas etapas.
Requerimientos. La etapa de requerimientos se enfoca en la captura, documentación y priorización de requerimientos que influencian la arquitectura. Como se mencionó anteriormente, los atributos de calidad juegan un papel preponderante dentro de estos requerimientos, así que esta etapa hace énfasis en ellos. Otros requerimientos, sin embargo, son también relevantes para la arquitectura, estos son los requerimientos funcionales primarios y las restricciones.
Diseño. La etapa de diseño es la etapa central en relación con la arquitectura y probablemente la más compleja. Durante esta etapa se definen las estructuras que componen la arquitectura. La creación de estas estructuras se hace en base a patrones de diseño, tácticas de diseño y elecciones tecnológicas. El diseño que se realiza debe buscar ante todo satisfacer los requerimientos que influencian a la arquitectura, y no simplemente incorporar diversas tecnologías porque están “de moda”.
Documentación. Una vez creado el diseño de la arquitectura, es necesario poder comunicarlo a otros involucrados dentro del desarrollo. La comunicación exitosa del diseño muchas veces depende de que dicho diseño sea documentado de forma apropiada. La documentación de una arquitectura involucra la representación de varias de sus estructuras que son representadas a través de distintas vistas. Una vista generalmente contiene un diagrama, además de información adicional, que apoya en la comprensión de dicho diagrama.
Evaluación. Dado que la arquitectura de software juega un papel crítico en el desarrollo, es conveniente evaluar el diseño una vez que este ha sido documentado con el fin de identificar posibles problemas y riesgos. La ventaja de evaluar el diseño es que es una actividad que se puede realizar de manera temprana (aún antes de codificar), y que el costo de corrección de los defectos identificados a través de la evaluación es mucho menor al costo que tendría el corregir estos defectos una vez que el sistema ha sido construido.
El rol de arquitecto
Las actividades descritas anteriormente requieren de habilidades particulares que son la responsabilidad del arquitecto de software. El arquitecto es un líder técnico que debe conocer los principios relacionados con la arquitectura de software, tener un amplio conocimiento respecto a la tecnología, y tener excelentes habilidades de comunicación escrita y oral.
Desafortunadamente, en la actualidad pocos arquitectos de software que laboran en la industria han recibido una formación teórica respecto al tema. Esto se debe a que no es sino hasta épocas recientes que se han establecido de manera más formal los conceptos relacionados con la arquitectura de software, y que actualmente pocas instituciones ofrecen cursos enfocados en el tema. El desconocimiento de los principios relativos a la arquitectura de software frecuentemente impacta de manera negativa a los proyectos de desarrollo.

Diagrama de Actividades


El Lenguaje Unificado de Modelado tiene varios subconjuntos de diagramas que puede modelar, incluidos los diagramas estructurales, los diagramas de interacción y los diagramas de comportamiento. Los diagramas de actividades son un subconjunto de estos últimos. Junto con los diagramas de casos de uso y de máquinas de estado, se usan para describir las actividades de negocios y la funcionalidad de los sistemas de software. Usarás un conjunto de símbolos especializados —incluidos aquellos para pasos de inicio, finalización, fusión y recepción en el flujo— para crear un diagrama de actividades.
Las partes interesadas tienen muchos asuntos que manejar, por lo que es importante una comunicación clara y breve. Los diagramas de actividades ayudan a que las personas en las áreas de negocios y desarrollo de una organización se integren.


Casos de uso para diagramas de actividades
Los diagramas de actividades tienen una serie de beneficios para toda organización. Prueba usar un diagrama de actividades para:

  • Demostrar la lógica de un algoritmo.
  • Describir los pasos realizados en un caso de uso UML.
  • Ilustrar un proceso de negocios o flujo de trabajo entre los usuarios y el sistema.
  • Simplificar y mejorar cualquier proceso clarificando casos de uso complicados.
  • Modelar elementos de arquitectura de software, tales como método, función y operación.

Componentes de un diagrama de actividades
Para responder a la pregunta, ¿qué es un diagrama de actividades en UML?, deberás comprender primero su composición. Algunos de los componentes más comunes de un diagrama de actividades incluyen:

  • Acciones - un paso en la actividad en la que los usuarios o el software realizan una tarea dada. En Lucidchart, esto se simboliza con un rectángulo redondeado.
  • Nodo de decisión - una rama condicional en el flujo que se representa con un diamante. Incluye una sola entrada y dos o más salidas.
  • Flujos de control - este es otro nombre para los conectores que muestran el flujo entre pasos en el diagrama.
  • Nodo inicial - simboliza el inicio de la actividad. Se representa con un círculo negro. 
  • Nodo terminal - representa el paso final en la actividad. Se modela con un círculo negro con contorno blanco.

Símbolos y notación para diagramas de actividades

Ahora que has visto algunos ejemplos, desglosemos un diagrama de actividades en sus elementos individuales.

  • Estado inicial Un círculo negro es la notación estándar para un estado inicial antes de que transcurra una actividad. Lo puedes usar solo o puedes usar una nota para aclarar aún más el punto inicial.
     
  • Estado final El círculo negro similar a un botón de radio seleccionado es el símbolo UML para el estado final de una actividad. Como se muestra en dos ejemplos anteriores, también se pueden usar notas para explicar un estado final.
     
  • Actividad Los símbolos de actividades son los componentes básicos de un diagrama de actividades y comúnmente tienen una descripción corta de la actividad que representan.
     
  • Flecha Las flechas representan el flujo de dirección del diagrama de flujo. La flecha indica la dirección de las actividades en curso.
     
  • Conjunción Una conjunción combina dos actividades simultáneas en un flujo en el que transcurre solo una actividad a la vez.
     
  • Bifurcación Una bifurcación divide el flujo de una actividad en dos actividades simultáneas.
     
  • Condición El texto de condición se coloca al lado de un marcador de decisión para indicarte bajo qué condición un flujo de actividad debe bifurcarse en esa dirección.
      

  • Decisión Un marcador en forma de diamante es el símbolo estándar para una decisión. Siempre hay al menos dos caminos que salen de una decisión y el texto de condición te permite saber qué opciones se excluyen mutuamente.
     

  • Flujo final El marcador de flujo final muestra el punto final para un proceso en un flujo. La diferencia entre un nodo de flujo final y un nodo de estado final es que este último representa el final de todos los flujos en una actividad.
     
     
  • Nota La figura que se usa para notas.
     




Ejemplos de diagramas de actividades
Empezamos por presentar ejemplos visualmente. Cuando veas el diagrama, fíjate si puedes deducir lo que significa cada parte. La finalidad de tener un enfoque estandarizado es facilitar las cosas, volverlas claras e intuitivas. En esta página se mostrarán varios ejemplos, se repasarán las notaciones y se explicará lo que hace cada parte del diagrama.

Diagrama de actividades de sistema de reservaciones de aerolínea

El primer ejemplo muestra el proceso de una reservación de vuelo. En primer lugar, ingresas las fechas. Una vez que envías tu plan de vuelo deseado, puedes ingresar tu información personal y al mismo tiempo el sistema podría buscar disponibilidad. Luego el flujo del sistema se vuelve a unir en uno y puedes elegir el vuelo específico en las fechas que deseas volar. Este diagrama de actividades te muestra dos rutas diferentes dependiendo de si usas puntos de recompensa. Después de ingresar la información de pago, el sistema realiza dos procesos al mismo tiempo y luego envía un correo electrónico de confirmación.


Diagrama de actividades para un sistema de registro de cursos
El segundo diagrama de actividades muestra un proceso típico de registro de eventos o clases para un cliente. Este diagrama emplea notas para dar más detalles sobre los estados inicial y final. Después de completar el formulario de registro, el cliente lo envía a un bucle de validación que se representa en el flujo como una decisión. Si la información es correcta, el sistema crea una cuenta para el cliente y le permite saber sobre la creación de la misma.



Arquitectura de Software

En el ámbito del software cada vez es más común escuchar el término “arquitectura de software”, y encontrar oportunidades de emple...