Diseño y

Arquitectura de
Software
Introducción a la Arquitectura de
Software
 El buen juicio es usualmente el resultado de la experiencia.
Y la experiencia es frecuentemente el resultado del mal juicio. Pero
para aprender de la experiencia de otros, requiere de aquellos que
tienen la experiencia para compartir el conocimiento con los que los
siguen.

Barry Lepatner.
¿Qué es la Arquitectura de Software?

• La Arquitectura de Software de un sistema es un conjunto de

estructuras necesarias para la lógica del sistema, las que comprenden
los elementos de software, relaciones entre ellos y las propiedades
de ambos.
Arquitectura como conjunto de herramientas
de software
• Existen tres categorías de estructuras arquitectónicas, que juegan un
rol importante en el diseño, documentación y análisis :
• Diseño por Módulos – Sistema de Partición de Estructuras.
• Estructuras dinámicas, lo que significa que se enfocan en el modo en cómo
los elementos interactúan entre ellos.
• Un tercer tipo describe el mapeo desde las estructuras de software a los
sistemas organizacionales, desarrollando, instalando y ejecutando las
mismas.
Arquitectura es Abstracción

• La Arquitectura comprende a los elementos y las relaciones entre

ellos.
• La arquitectura tienen como competencia además las partes de las
relaciones y su interacción a nivel más abstracto o superior.
• Si hacemos la comparativa entre lo público y lo privado.
Cada Sistema de Software tiene una
Arquitectura de Software
• Puesto que cada sistema puede comprender elementos y sus
relaciones entre sí, las que producen cierta lógica. Basados en este
entender, un sistema vendría a ser por sí mismo un elemento más.
• Pensar que cada sistema posee Arquitectura, no es lo mismo que
indicar que exista conocimiento de la misma.
• Para el supuesto que toda la gente que diseñó y programó dicho
sistema ya no se encuentre en la empresa, la documentación se haya
extraviado (o tal vez nunca haya existido), y todo lo que nos quede
sea el código binario en ejecución.
• Esto no quiere decir que la Arquitectura también se haya perdido,
aquí se muestra la diferencia entre la Arquitectura de un sistema y su
Representación.
Arquitectura incluye Comportamiento

• El comportamiento de cada elemento, es parte de la arquitectura, en

la medida en que dicho comportamiento tenga que ver con el
propósito final del sistema.
• Existe parte de la Arquitectura de un Sistema que puede no estar
documentada, sin embargo aquella que sirva de influencia para el
comportamiento de un sistema tal vez completo, o que tenga
relación con la aceptación del mismo, debería ser documentada, y
formar parte de la Arquitectura de Software.
Vistas y Estructuras

• Una Vista es una representación de un conjunto coherente de

elementos de arquitectura, el cual es escrito y leído por los
stakeholders. Esta vista entonces consiste en la representación de un
conjunto de elementos y las relaciones entre ellos.
• La estructura es el conjunto de elementos mismos, existentes en
software o hardware.

• En resumen, una vista es la representación de una estructura.

• Así que los Arquitectos de Software diseñan las estructuras, y

documentan las vistas de estas estructuras.
 Tres tipos de Estructuras

• Estructuras Modulares:
• ¿Cuál es la responsabilidad funcional principal asignada a cada módulo?
• ¿Qué otro elemento de software es permitido de utilizar por el módulo?
• ¿Qué otro software realmente se utiliza o depende del módulo?
• Qué módulos están enlazados por generalización o especialización?
• Estructuras Componentes-Conectores
• ¿Cuáles son los componentes más importantes y extensos y cómo interactúan en tiempo de ejecución?
• ¿Cuál es el ratio de intercambio de datos más extenso?
• ¿Qué partes del sistema están replicadas?
• ¿Cómo fluye la información en el sistema?
• ¿Qué partes del sistema podría correr en paralelo?
• ¿La estructura del Sistema cambia en tiempo de ejecución?
• Estructuras de Asignación
• ¿Qué procesador ejecuta cada parte del software?
• ¿En qué estructura de directorios se almacenan las fuentes en cada una de las etapas?
• ¿Cuál es la asignación de cada elemento de software a los equipos de desarrollo?
Estructuras Modulares

• Estructura de Descomposición
• Las unidades son módulos relacionados con otros mediante el conector «es-
submódulo-de», mostrando estas relaciones de forma recursiva hasta que se
presenten unidades lo suficientemente fáciles de comprender.
• Estructura de Usos
• Las unidades pueden ser módulos o incluso clases, estas se relacionan mediante
una unión de USO, forma especializada de dependencia.
• Estructura de Capas
• Los módulos son llamados capas, tratados como «máquinas virtuales» que
proveen un conjunto cohesivo de servicios.
• Estructura de Clases
• O de Generalización, las estructuras son llamadas clases, prima la relación de
herencia o instancia de.
• Modelo de Datos
• Describe la estructura de información estática en términos de entidades y
relaciones.
Estructuras de Componente-Conector

• Estructura de Servicio
• Las unidades son los servicios que interoperan entre ellos mediante
mecanismos de coordinación como puede ser SOA.
• Estructura Concurrente
• Este componente-conector, permite al Arquitecto poder identificar
oportunidades para hacer uso del paralelismo.
• Las unidades vienen a ser los componentes y los conectores vendrían a ser
los mecanismos de comunicación.
• La estructura concurrente es utilizada en la fase inicial del proceso de diseño
para identificar los requerimientos a gestionar y la problemática con la
ejecución concurrente.
Estructuras de Asignación

• Estructura de Despliegue
• Muestra cómo el software es asociado al hardware que lo procesará, así
como a las estructuras de comunicación.
• La relación vendría a tomarse como «asignado a».
• Estructura de Implementación
• Esta estructura muestra cómo los elementos de software son mapeados en
una estructura de ficheros en los procesos de desarrollo, integración y
configuración.
• Estructura de Asignación de Trabajo
• Esta estructura se encarga de la asignación de responsabilidades para la
implementación e integración de los módulos a los equipos que se harán
cargo.
Patrones de Arquitectura

• En algunos casos, los elementos son compuestos de forma tal que

puedan resolver un problema en particular.
• Dichas composiciones han sido encontradas útiles sobre el tiempo y
sobre muchos dominios diferentes, así que han sido diseminadas y
documentadas.
• Estas composiciones de elementos son llamados Patrones de
Arquitectura.
• Un Patrón de Arquitectura delimita los tipos de elementos y sus
formas de interacción usados para resolver problemas.
Patrones de Arquitectura

• Patrón Estratificado (M)

• Se utiliza cuando la relación de uso entre un elemento de software es
estrictamente unidireccional, entonces emerge un sistema de capas.
• Una capa es un conjunto coherente de elementos con funcionalidad relacionada.
• Patrón de datos compartidos (C&C)
• Compromete componentes que crean, almacenan y acceden a datos persistentes.
• Patrón Cliente Servidor
• Los componentes son Clientes y Servidores y los conectores son protocolos y
mensajes.
• Patrón Multi-tier (A)
• Este patrón describe cómo distribuir y asignar los componentes de un sistema en
distintos subconjuntos de hardware y software.
• Plataforma y Competencia Central
• Patrón que se basa en el Sistema de Asignación de Trabajo
•Construir Software no es sólo escribir
código!
•El ENTREGABLE DE DISEÑO es la entrada
de la fase de DESARROLLO.
Arquitectura de Software

• Es la definición de cómo los componentes de

software de un sistema está organizados y
ensamblados. Cómo ellos se comunican. Y las
restricciones que gobiernan el sistema entero.
 cómo los componentes de software de un
sistema está organizados y ensamblados

Patrón de
Arquitectura

Mensajes & APIs

Arquitectura de Software

Cómo se comunican.

Limitaciones de todo el sistema

Atributos de calidad
Patrones de Arquitectura

• Los Patrones de Arquitectura definen la granularidad de los

componentes.

• Granularidad = Cuán pequeño o grande debería ser un componente.

• Conocer el Patrón de Arquitectura, nos ayudará a tomar buenas

decisiones en la fase de desarrollo.

• DESICIÓN IMPORTANTE: PATRÓN DE DISEÑO.

Cuál es la diferencia entre un Patrón de
Arquitectura y un Patrón de Diseño?

Patrón de Arquitectura
Patrón de Diseño
• Alto Nivel, Alcance
• Alcance de bajo
universal.
nivel.
• Cómo se organizan y
• Cómo son
ensamblan los
CONSTRUIDOS los
componentes.
componentes.
Patrón Estratificado

• Conocido como Patrón N-tier .

• Monolítico.
• Separación de actividades.
• Las capas como compoenntes
Patrón de Microservicios

• Tipo de Patrón basado en

servicios.
• NO es SOA
• Posee unidades
desplegables,
independientes.
Patrón MicroKernel

• O también Patrón Plug-In

• Componentes:
• Core (como un kernel)
• Plug-ins
Patrón SOA

• Sistemas empresariales
mayores.
• Integra diferentes
componentes Heterogéneos