Departamento de Ciencias

de la Computación

Arquitectura de Software
Unidad 1
Arquitecturas de Software Orientadas a Servicio

Docente: Geovanny Cudco

Técnicas y Ponderación de la
Evaluación
Técnica de evaluación 1er Parcial 2do Parcial 3er Parcial
Laboratorios/Informes 4 4 4
Tareas o guías/Pruebas 4 4 4
Proyectos 5 5 5
Evaluación conjunta 7 7 7
TOTAL 20 20 20
Unidad 1: Arquitecturas de Software
Orientadas a Servicio
1.1. Arquitecturas de software 1.3.2. Software as Service
1.1.1. Conceptos. 1.3.3. SOA aplicando software libre.
1.1.2. Arquitecturas 1.3.4. SOA aplicando software propietario.
1.1.3. Modelos y vistas 1.3.5. Restful, SOAP, WSDL aplicando software libre
1.1.4. Evolución 1.3.6. Restful, SOAP, WSDL aplicando software
propietario
1.1.5. Estilos
1.1.6. Modelos
1.2. Aplicación de Patrones de diseño.
1.2.1. Patrones generales.
1.2.2. Patrones de arquitectura.
[Link] Orientadas a Servicios.
1.3.1. Conceptos
¿Qué es la arquitectura
de software?
Aproximaciones textuales
“La arquitectura es un nivel de diseño que hace foco en aspectos "más allá de los algoritmos y
estructuras de datos de la computación; el diseño y especificación de la estructura global del
sistema es un nuevo tipo de problema “

— "An introduction to Software Architecture" de David Garlan y Mary Shaw

“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. “

— Software Engineering Institute (SEI)

Aproximaciones textuales
“El conjunto de estructuras necesarias para razonar sobre el sistema, que comprende elementos de
software, relaciones entre ellos, y las propiedades de ambos. “

— Documenting Software Architectures: Views and Beyond (2nd Edition), Clements et al, AddisonWesley,
2010

“La arquitectura se define como la organización fundamental de un sistema, encarnada en sus

componentes, sus relaciones entre sí y con el entorno, y los principios que rigen su diseño y evolución “

— ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software Intensive
Systems
Aproximaciones textuales

Como podemos observar, existen muchas definiciones sobre que es la arquitectura

de software, lo que hace complicado desde un inicio dar una definición exacta y que
deje conformes a todos, sin embargo, como arquitectos de software estamos
forzados a poder dar una definición, lo que nos deja dos opciones, adoptar una de
las existente o creamos nuestra propia definición basado en las anteriores.
Nuevo concepto: Arquitectura de
software

La arquitectura de software es el diseño

de más alto nivel de la estructura de un
sistema, el cual consiste en un conjunto
de patrones y abstracciones que
proporcionan un marco claro para la
implementación del sistema.
Elementos de la arquitectura de
software
La arquitectura de software se conforma mediante la combinación de varios elementos y conceptos.
Estos elementos fundamentales se combinan para definir la estructura y el diseño del sistema de
software.

Tecnologías y
Componentes Documentación
herramientas

Consideraciones de
Conexiones Requisitos no funcionales evolución y
mantenimiento

Patrones de diseño Estilo arquitectónico

Elementos de la arquitectura de
software
• Son los módulos, servicios o partes del software que
realizan tareas específicas dentro del sistema.
Componentes • Pueden incluir componentes de interfaz de usuario, lógica
de negocio, acceso a bases de datos, servicios web, etc.

• Representan cómo los componentes se comunican y

colaboran entre sí.
Conexiones • Incluye la definición de interfaces, protocolos de
comunicación y flujos de datos.
Elementos de la arquitectura de
software
• Son soluciones probadas y recurrentes para problemas
Patrones de comunes de diseño de software.
diseño • Ayudan a estructurar el software de manera efectiva.

• Es el enfoque de alto nivel que rige la estructura del

sistema.
Estilo
• Ejemplos de estilos arquitectónicos: arquitectura de tres
arquitectónico capas, la arquitectura orientada a servicios, la
arquitectura de microservicios, entre otros.
Elementos de la arquitectura de
software

Requisitos no • Son los atributos de calidad que debe cumplir la

arquitectura del software, como el rendimiento, la
funcionales: escalabilidad, la seguridad y la disponibilidad.

• La elección de las tecnologías específicas, como

Tecnologías y lenguajes de programación, bases de datos, frameworks
herramientas: y herramientas, tiene un impacto significativo en la
arquitectura.
Elementos de la arquitectura de
software
• Es esencial para describir y comunicar la arquitectura a
los miembros del equipo y las partes interesadas.
Documentación:
• Incluye diagramas, descripciones de componentes,
interfaces y decisiones clave de diseño.

Consideraciones • La arquitectura debe ser diseñada pensando en la

de evolución y capacidad de evolucionar y mantener el sistema a lo
mantenimiento largo del tiempo.
▪ La conformación de la arquitectura de software
implica tomar decisiones fundamentales en cada
uno de estos aspectos para definir cómo se
organizará el software y cómo cumplirá con los
requisitos del proyecto.

▪ La arquitectura proporciona una estructura sólida

que guía el desarrollo y garantiza que el sistema
cumpla con sus objetivos de manera eficaz.
¿Qué es un arquitecto
de software?
Arquitecto de Software

❖ Es un profesional altamente
especializado en el diseño y
planificación de sistemas de
software.

❖ Es responsable de definir la
estructura de un software,
asegurando que el sistema cumpla
con ciertos requisitos técnicos.
Arquitecto de Software
Arquitecto de Software
 Seleccionar la tecnología y lenguajes
adecuados para el sistema.
Funciones de un ARQUITECTO

Diseñar la arquitectura del software.

DE SOFTWARE

Planificar y supervisar el desarrollo.

Asegurar que el software tenga todas las

garantías de calidad.

Resuelve problemas técnicos.

Evaluar y optimizar el rendimiento del

sistema
 Seleccionar la tecnología y lenguajes
adecuados para el sistema.
Funciones de un ARQUITECTO
Diseñar la arquitectura del software. Las funciones del
arquitecto de software son
DE SOFTWARE

críticas para el éxito del

Planificar y supervisar el desarrollo.
desarrollo de software, ya
que deben asegurarse de
Asegurar que el software tenga todas las que el sistema cumpla con
garantías de calidad.
los requisitos de la
organización, sea eficiente
Resuelve problemas técnicos. y fácil de usar

Evaluar y optimizar el rendimiento del sistema

Laboratorio 1
Tema: Roles y Responsabilidades en el Desarrollo de Software
Descripción:
En el desarrollo de software, diversos roles y responsabilidades trabajan en conjunto para llevar a cabo
proyectos exitosos. En esta tarea, exploraremos los roles del arquitecto de software, el analista de sistemas,
el project manager y el desarrollador, identificando sus funciones principales y cómo colaboran dentro de un
proyecto.
Instrucciones:
Investigación: Investigue y recopile información sobre los siguientes roles en el desarrollo de software:
• Arquitecto de Software
• Analista de Sistemas
• Project Manager
• Desarrollador
Funciones y Responsabilidades: Para cada uno de los roles mencionados, describa detalladamente:
• Funciones principales que desempeñan.
• Responsabilidades específicas asociadas con su rol.
• Habilidades y conocimientos requeridos para ejercer el rol de manera efectiva.
Colaboración y Comunicación:
Analice cómo estos roles colaboran entre sí dentro de un proyecto de desarrollo de software. ¿Qué tipo
de interacciones son comunes entre ellos? ¿Cómo se comunican y comparten información para lograr
los objetivos del proyecto?

Estudio de Caso:
Busque un estudio de caso o ejemplo de un proyecto de desarrollo de software y analice cómo cada
uno de estos roles contribuyeron al éxito o fracaso del proyecto. ¿Hubo desafíos en la colaboración
entre los roles? ¿Qué lecciones se pueden aprender de este caso?

Informe:
• Escriba un informe que resuma sus hallazgos.
• Incluya una descripción detallada de cada rol, su importancia en el proceso de desarrollo de
software y cómo interactúan entre sí para cumplir los objetivos del proyecto.
• Concluya con reflexiones sobre la importancia de comprender y valorar cada uno de estos roles en
el ámbito de la arquitectura de software.
 Importancia de la
arquitectura de software
 Una sólida arquitectura de
software permite planificar con
detalle el funcionamiento de una
aplicación antes de iniciar con el
proceso de desarrollo, establecer
tiempos, así como determinar los
recursos económicos y humanos
que se necesitarán durante todo
el proceso.
 Una arquitectura bien estructurada permite un desarrollo más rápido y eficiente, evitando
Mayor eficiencia:
la duplicación de esfuerzos y minimizando los errores.
Beneficios
Una arquitectura sólida proporciona una base estable para el software, lo que conduce a
Mayor calidad:
una mayor calidad y confiabilidad del producto final.

Facilita la Una arquitectura de software bien diseñada permite la integración de diferentes sistemas
integración: y componentes, lo que facilita la comunicación entre ellos y mejora la interoperabilidad.

A través de la aplicación de patrones de diseño de software, así como la integración en

Sistemas más ecosistemas de integración que permitan probar el software desarrollado se obtendrán
seguros: sistemas más seguros y resilientes contra ataques de seguridad, aparición de
vulnerabilidades, etc.

Si se trata de una arquitectura modular y mediante el uso de patrones, se puede reutilizar

Reutilización:
y amortizar la inversión en el desarrollo para la creación de otros sistemas de software.
CICLO DE DESARROLLO DE LA ARQUITECTURA

• De manera similar a las actividades

técnicas para el desarrollo de
sistemas, podemos hablar de un ciclo
de desarrollo de la arquitectura de
software que engloba actividades
particulares.

• Estas se integran a las actividades

técnicas del desarrollo de sistemas.
 Se enfoca en la captura, documentación y priorización de
Requerimientos de la
requerimientos que influyen sobre la arquitectura y que por lo
arquitectura
habitual, se conocen en ingles como drivers arquitectónicos

Ciclo de vida
Diseño de la arquitectura

Documentación de la
arquitectura

Evaluación de la
arquitectura

Implementación de la
arquitectura
 Drivers
arquitectónicos

2. Drivers de
1. Drivers 3. Drivers de
atributos de
funcionales. restricciones.
calidad.
 Drivers funcionales
▪ Los drivers funcionales son un subconjunto de los requerimientos funcionales.

▪ Proveen información relevante para llevar a cabo la descomposición funcional del

sistema y asignar estas funcionalidades a elementos específicos en la arquitectura.

Estos drivers se eligen considerando:

▪ Su relevancia en la satisfacción de los objetivos del negocio del sistema.

▪ La complejidad técnica que representa su implementación.
▪ El hecho de que representan algún escenario relevante para la arquitectura.
 Drivers de atributos de calidad
Todos los requerimientos de atributos de calidad son drivers de la arquitectura,
independientemente de su prioridad. Sin embargo como el tiempo para realizar el diseño
arquitectónico es acotado, para producir un diseño inicial es preferible considerar nada
más un subconjunto de los requerimientos de atributos de calidad.

Estos requerimientos se eligen por lo habitual considerando estos criterios:

• Su relevancia en la satisfacción de los objetivos del negocio del sistema, es decir, su

importancia para el cliente.
• La complejidad técnica que representa su implementación, esta es su importancia para el
arquitecto.
 Drivers de restricciones
En contraste con los drivers funcionales y de atributos de calidad, los requerimientos de
este tipo no tienen prioridad. Por esta razón, todas las restricciones son drivers de la
arquitectura.
 Fuentes de información para la
extracción de drivers arquitectónicos
▪ Documento de visión y alcance: el documento de visión y alcance contiene información
referente a por qué desarrollar un sistema, y al alcance de este, mediante descripciones
textuales acerca de su contexto, las necesidades que resuelve, la descripción de sus
usuarios, entre otras.
▪ Documento de requerimientos de usuario: Los casos de uso y las historias de usuario son
elementos utilizados para especificar necesidades de los clientes, es decir, para especificar
los servicios que estos pueden realizar por medio del sistema
▪ Documento de especificación de requerimientos: Además del de visión y alcance y del de
requerimientos de usuario, otro documento representativo de la ingeniería de
requerimientos es el de Especificación de Requerimientos (SRS, por sus siglas en inglés).
Contiene elementos para especificar los atributos de calidad, interfaces externas y
restricciones y requerimientos funcionales que, como lo hemos mencionado, representan
información relevante a efecto de identificar los drivers.
 Taller 01
Especificar los Drivers Arquitectónicos del siguiente caso de estudio.

Drivers Funcionales
• Modelos de Casos de Uso (Diagrama – Descripción)
• Elección de casos de uso primarios
Drivers de atributos de calidad
Drivers de restricciones
Casos de Uso Taller 01
CARACTERÍSTICA
ID DESCRIPCIÓN
ASOCIADA
Permite consultar recorridos de los autobuses con base a diversos criterios (tipos de CAR-01; CAR-06
CU-01 boletos, fecha de salida, fecha de regreso, origen, destino, etc)
Permite comprar uno o más boletos (con o sin descuento) una vez que se consultó la ruta CAR-01; CAR-06
CU-02
de los autobuses.
CU-03 Permite cancelar un boleto comprado CAR-04
CU-04 Permite imprimir o reimprimir un boleto comprado. CAR-02
CU-05 Permite darse de alta en el sistema con el fin de realizar la compra e impresión de boletos. CAR-11
Permite ingresar al sistema, una vez que el usuario se ha dado de alta, a efecto de hacer CAR-11
CU-06 consultas, reimprimir boletos o para la parte administrativa.
Permite generar diversos tipos de reportes para análisis de comportamientos y mejoras CQR-05
CU-07
del sistema.
Permite realizar altas, bajas y cambios en las diversas entidades del sistema (rutas, CAR-03
CU-08
autobuses, recorridos, etc)
 Taller 01
Include. se utiliza para mostrar que un caso de uso
siempre incluye el comportamiento de otro caso de
uso como parte de su ejecución normal.
Extend. se utiliza para mostrar que un caso de uso
puede extender el comportamiento de otro caso de
uso bajo ciertas condiciones.
 Taller 01

Casos de Uso primordiales

ID JUSTIFICACIÓN
CU-02 La compra de boletos en la razón principal del sistema.
CU-01 Es necesario disponer de la función de consulta de rutas
(recorridos) para poder comprar los boletos.
Este caso de uso debe soportar el acceso concurrente y
otros atributos de calidad.
Drivers de Atributos de calidad
Taller 01
ID Categoria Escenario Prioridad
EAC-01 Desempeño (A,A)

Ocurre una falla interna del sistema que detiene su operación en un

Disponibilidad del
EAC-02 momento en el que estaba funcionando de manera normal. El sistema (M,A)
sistema
vuelve a operar normalmente en un periodo no mayor a cinco minutos.

Un atacante intercepta la comunicación entre la PC de un usuario y el

sistema mientras tal cliente realiza la compra de un boleteo (CU-02) en un
EAC-03 Seguridad (A,B)
momento normal de operación. El atacante no obtiene ninguna información
en claro (no cifrada)

EAC-04 Usabilidad (M,A)

EAC-05 Facilidad de prueba (B,B)
EAC-06 Modificabilidad (M,B)
 Taller 01
Drivers de restricciones

Tipo de restricción Descripción

Tiempos de entrega y presupuesto establecidos.
Del cliente
Sección del documento de visión y alcance
De la organización de Los ingenieros de los que se dispone están familiarizados
desarrollo con los siguientes frameworks SrpingBoot y React Js
 Requerimientos de la
arquitectura
Se diseñan las estructuras de las que se compone la

Ciclo de vida
arquitectura mediante la toma de decisiones de diseño.

Diseño de la arquitectura

Se seleccionan las tecnologías, frameworks y patrones

de diseño
Documentación de la
arquitectura

Evaluación de la
arquitectura

Implementación de la
arquitectura
 Requerimientos de la
arquitectura

Existen diversos métodos de diseño de

Ciclo de vida Diseño de la arquitectura

arquitectura de software. Uno que provee una
guía para realizar el diseño arquitectural de
forma sistémica es el Diseño Guiado por
Atributos (Attribute Driven Design o ADD)

Documentación de la
arquitectura

Evaluación de la
arquitectura

Implementación de la
arquitectura
Diseño de la Arquitectura
ADD: Este método recibe como entrada una lista de drivers arquitecturales y produce a su salida
una serie de estructuras que conforman al diseño de la arquitectura. Se va aplicando de forma
iterativa.
 Diseño de la Arquitectura
1. Confirmar que se tiene 3. Identificar drivers
2. Elegir un elemento del sistema
información suficiente sobre los arquitectónicos asociados al
a descomponer.
drivers elemento.

4. Definir interfaces para los 5. Instanciar los elementos y 6. Elegir un concepto de diseño
elementos instanciados. asignar responsabilidades. que satisfaga los drivers.

7. Verificar y refinar
requerimientos y transformarlos
8. Repetir los pasos anteriores
en restricciones para los
elementos instanciados.
Diseño de la Arquitectura
1. Confirmar que se tiene información suficiente sobre los drivers
arquitectónicos

• El enfoque en este paso es asegurarse de que se cuenta con los datos suficientes acerca de los distintos
drivers asociados al sistema y que están pinzados

2. Elegir un elemento del sistema a descomponer.

• El elemento puede ser el sistema completo, si es un desarrollo nuevo, o un elemento obtenido de una
iteración anterior Existen diversos criterios de elección, los cuales incluyen el conocimiento que se tiene
acerca de la arquitectura al momento y de los riesgos

3. Identificar drivers arquitectónicos asociados al elemento.

• En esta etapa se elige una parte del con junto inicial de drivers y se relacionan con el elemento elegido
Diseño de la Arquitectura
4. Elegir un concepto de diseño que satisfaga los drivers.

• En este paso se selecciona un concepto general de diseño (ya sea patrones o tácticas) en
relación con el elemento y los drivers elegidos. Este elemento es descompuesto mediante la
aplicación de patrones asociados a tal concepto

5. Instanciar los elementos y asignar responsabilidades.

• En esta fase se crean instancias de elementos derivados de los patrones y se describen sus
responsabilidades

6. Definir interfaces para los elementos instanciados.

• En este paso se Identifican propiedades para los elementos instanciados y, más

específicamente, las interfaces de estos
Diseño de la Arquitectura
7. Verificar y refinar requerimientos y transformarlos en
restricciones para los elementos instanciados

• En este paso se verifica si se han satisfecho los drivers y, en caso necesario, se refinan y se
asocian a los elementos identificados durante la iteración

8. Repetir los pasos anteriores

• Para elementos que requieran un refinamiento mayor hasta cubrir la mayoría de los drivers
Diseño de la Arquitectura
Primera • Estructuración
general del
iteración sistema

Segunda • Integración de
la
funcionalidad
iteración a las capas

Tercera • Desempeño
en capa de
iteración datos
 Diseño de la Arquitectura
En la primera iteración

▪ Paso 2 del add, el arquitecto elige el sistema como elemento a descomponer, dado que se
esta creando un sistema partiendo de cero (del único punto de partida arquitectónico que se
dispone es del diagrama de contexto en el documento de visión y alcance).

▪ Paso 3 Identifica los drivers que va a tratar durante la iteración. Dado que se trata de una
iteración inicial, el enfoque esta en la estructuración general del sistema con el fin de soportar
los distintos drivers y apegarse a las restricciones.

▪ Paso 4 el arquitecto tiene claros los drivers y procede a elegir conceptos de diseño para
descomponer el elemento elegido anteriormente. En este caso, estos conceptos son patrones
de diseño estructurales y de implantación; capas y IV-tercios.
 Diseño de la Arquitectura
En la primera iteración

▪ Ya hecha la elección, en el paso 5 se generan elementos nuevos mediante la instanciación de

los patrones y se les asignan responsabilidades. Esto da como resultado estructuras que en
este caso son tanto físicas como lógicas.

▪ En el paso 6 se definen interfaces para los elementos instanciados. Sin embargo, dado que se
trata de una descomposición estructural de nivel alto, estas no se detallan todavía.
Estructuras resultantes y responsabilidades de los elementos
Al final de esta iteración se revisa si ya se han tomado decisiones de diseño para satisfacer los
drivers de la arquitectura. Se han hecho muchas, pero no suficientemente detalladas, por ello es
necesario realizar iteraciones adicionales
En la segunda iteración

• Se enfoca en identificar la manera en que se soportará la funcionalidad primaria del sistema.

Para ello, toma las capas de este como elementos a descomponer (paso 2 del add)

• Los drivers para esta iteración (elegidos en el paso 3) son los casos de uso primarios, CU-01 y
CU 02.

• Respecto de la elección de los conceptos de diseño (paso 4), se comienza por seleccionar el
patrón Domain Object, que tiene como propósito encapsular funcionalidades distintas del
sistema en bloques autocontenidos llamados objetos de dominio

• Se selecciona también el patrón Data Mapper, que es un tipo particular de Domain Object
con el cual se encapsulan los aspectos de acceso a la base de datos relacional. A efecto de
permitir la realización de pruebas, los objetos de dominio refinan mediante los patrones
Explicit Interface y Encapsulated Implementation para separar claramente la interfaz y la
implementación.
En la segunda iteración

• A continuación se instancian elementos a partir de los patrones (paso 5). El resultado es que
en cada una de las capas se crean componentes enfocados en soportar cada uno de los
casos de uso.

• Una vez identificados los componentes dentro de las capas, se procede a definir interfaces
para ellos (paso 6). Por esta razón se realiza un análisis dinámico de las interacciones entre
los componentes para soportar los flujos asociados a los casos de uso. Para este análisis se
usan diagramas de secuencia de UML, y como resultado se identifican los métodos
asociados a las interfaces de los componentes.

• Al final de esta iteración ya se tiene mas claro cuales serán los componentes necesarios para
soportar la funcionalidad primaria del sistema, y esto sirve de marco de referencia para
identificar aquellos que implementan el resto de la funcionalidad. Sin embargo, no se han
tomado decisiones mas especificas para satisfacer los escenarios de atributos de calidad,
por lo que la iteración siguiente se enfoca en este aspecto.
En la tercera iteración, el arquitecto decide llevar a cabo decisiones de diseño más
detalladas que le permitan satisfacer el escenario de atributo de calidad de desempeño
(EAC-01) que resulto prioritario.

Recordemos este escenario:

“Un usuario selecciona la opción buscar una vez que ha elegido las ciudades de salida y
destino, así como las fechas en la pantalla de consulta (CU-01) en un momento normal
de operación y hay hasta cien usuarios conectados al sistema. Este procesa la petición y
muestro la lista de corridas en un tiempo no mayor a dos segundos”

Donde:
• Momento normal de Operación = 100 usuarios.
• Momento de sobrecarga = 500 usuarios simultáneos.
• Dos segundos incluye únicamente tiempo de procesamiento y no tránsito en red.
En la tercera iteración
• En esta iteración se enfoca en la capa de datos, que será entonces el elemento a
descomponer (paso 2 del add).
• El driver primario seleccionado para esta iteración es el escenario EAC-01 (paso 3 del
add), y respecto de los conceptos de diseño elegidos en el paso 4 del add, estos incluyen
los patrones Lazy Acquisition y Eager Acquisition, así como las tácticas de Mantener
copias múltiples y Manejo de recursos.
Aunque esos patrones y tácticas son los conceptos de diseño elegidos, forman parte de las
opciones de configuración del framework usado en la capa de persistencia, por lo que la
instanciación de estos conceptos (paso 5 del add) requiere solo la configuración del
framework, que en este caso se lleva al cabo mediante un archivo en formato XML propio al
framework.
En la tercera iteración

• Para el paso 6 del add se realiza de nuevo un análisis dinámico que aquí resulta en un
refinamiento de las interfaces identificadas en la iteración anterior.

• Al final de esta iteración, el arquitecto concluye que en el nivel de la capa de datos ha

tomado suficientes decisiones de diseño para satisfacer el atributo de calidad de
desempeño que fue el driver de la iteración. Sin embargo, estas decisiones no son
suficientes para satisfacer el escenario pues el desempeño requiere de otras decisiones
en las demás capas del sistema, las cuales deberán hacerse en iteraciones
subsecuentes.
El siguiente diagrama
de secuencia UML
muestra la manera en
que interactúan los
componentes lógicos
para soportar el flujo
principal del CU-01
 Requerimientos de la
arquitectura
Es necesario darla a conocer a otros interesados en el

Ciclo de vida
sistema, como desarrolladores, responsables de
implantación, lideres de proyecto o el cliente mismo.
Diseño de la arquitectura

La documentación formal involucra la representación

sus estructuras por medio de vistas
Documentación de la
arquitectura

Evaluación de la
arquitectura

Implementación de la
arquitectura
 Otros miembros del equipo de TI o incluso
Fácil de explicar y comprender. algunos stakeholders podrán comprender y
evaluar nuestros diseños.

Ayuda a entender fácilmente el diseño

Sirve como evidencia o recordatorio cuando, después de un largo tiempo,
Razones de cómo y por qué se tomaron volvemos a él para reevaluar alguna decisión
decisiones de diseño. o para explicar por qué se tomaron algunas
otras.

Permite realizar un análisis del diseño para

Nos brinda una visión más amplia de
generar métricas estándar como
nuestros sistemas.
acoplamiento y cohesión.
 No hay una sola manera de documentar tu
arquitectura. Es decir, no existe un estándar
de documentación de arquitectura
universalmente aceptado, debido a que
existen muchas maneras de hacerlo.

Tratar de hacerlo comprensible para el lector

puede tomarte mucho tiempo si la
Inconvenientes arquitectura que quieres documentar es muy
compleja.

Existen muchas vistas posibles y tratar de

documentar todas las potencialmente útiles
requerirá de mucho tiempo y es costoso.
 ¿Cómo se
documenta el
diseño
arquitectural?
 Recordemos que hemos definido la arquitectura de software como un
conjunto de estructuras compuestas por elementos con propiedades y
relaciones entre ellos

Para documentar un diseño arquitectural requerimos poder

representar estas distintas estructuras

Las estructuras del diseño arquitectural se documentan de forma separada a

través de distintas vistas. Cada vista modela una parte del diseño arquitectural
desde distintas perspectivas que pueden ser por ejemplo dinámicas, lógicas o
físicas.
 Describe una o más estructuras de la arquitectura en
términos de los elementos que la conforman.

Definición
Se conforma por: 1) un diagrama en donde se
representan los elementos de la estructura, y 2)
información textual que ayuda comprender este
VISTAS

Vistas lógicas

Tipos Documentar al menos Vistas de comportamiento

Vistas físicas
 Vista Lógica
Describen las estructuras arquitectónicas en términos de
elementos que toman la forma de unidades de
implementación considerando tanto las propiedades como
las relaciones u organización de cada una de estas.

Las propiedades incluyen aspectos como, por ejemplo, su

nombre, las funcionalidades o responsabilidades que le
han sido asignadas, las Interfaces que define o el lenguaje
de programación utilizado para su implementación

Las unidades de implementación que se utilizan

frecuentemente en este upo de vistas incluyen clases,
paquetes, módulos o subsistemas
 Vistas de comportamiento
Describen estructuras cuyos elementos denotan entidades visibles en tiempo
de ejecución, por ejemplo, instancias, procesos, objetos, clientes, servidores o
almacenes de datos

Además del nombre, el tipo y la funcionalidad ofrecidos, las propiedades de los

elementos en este tipo de vistas incluyen información sobre valores específicos
de atributos de calidad que pueden observarse cuando se ejecuta el sistema,
por ejemplo, confiabilidad, desempeño o seguridad
 Vistas físicas

Describen estructuras conformadas por elementos físicos que mantienen

algún tipo de relación con los de las estructuras documentadas en otras vistas.

En esta vista se pueden utilizar elementos de dos categorías de hardware y de

software
 MÉTODOS Y MARCOS CONCEPTUALES
DE DOCUMENTACIÓN DE ARQUITECTURA

Los métodos describen de manera explícita tanto las entradas requeridas como
la secuencia de acciones que comprenden y las salidas generadas, los marcos
conceptuales proveen un conjunto de conceptos que deben considerarse al
documentar la arquitectura.

Ejemplos

• Vistas y mas allá (Views and Beyond)

• 4+1 Vistas (4+1 Views)
• Metodo de diseno centrado en la arquitectura (ACDM)
• Puntos de vista y perspectivas (Viewpoints and Perspectives)
Vistas y mas allá (Views and
Beyond)
• El modelo de documentación de arquitectura de software "Vistas y más allá"
(Views and Beyond), propuesto por Paul Clements y colaboradores, es un enfoque
estructurado para documentar arquitecturas de software que permite captar y
comunicar la complejidad de los sistemas.

• Este modelo sugiere que la arquitectura de un sistema debe ser documentada a

través de múltiples "vistas" para cubrir los diferentes aspectos y satisfacer las
distintas necesidades de los interesados.

• Para apoyar al arquitecto en la tarea de documentar el diseño de la arquitectura.

Vistas y mas allá define un proceso secuencial simple en términos de las etapas.
Vistas y mas allá (Views and
Beyond)
1. Generar una lista de vistas
candidatas.

2. Combinar las vistas.

3. Priorizar las vistas.

Vistas y mas allá (Views and
Beyond)
Generar una lista de vistas candidatas.

• A través de una matriz, que en sus filas incluya el conjunto

de interesados del sistema, y en sus columnas, los
diferentes tipos de vistas, el arquitecto identifica las vistas
relevantes para el diseño en turno.
• De acuerdo con cada vista, el arquitecto debe indicar el
nivel de detalle con que estas requieren ser documentadas.
Vistas y mas allá (Views and
Beyond)
Combinar las vistas.
▪ A efecto de reducir el número de vistas a documentar, el arquitecto lleva a cabo
en esta etapa un análisis acerca de la tabla generada en el paso anterior.

▪ Analizar los casos en los que, por ejemplo, algunas vistas requieren ser
documentadas de forma muy general y que las necesitan muy pocas personas.

▪ Detectar que existen vistas utilizadas para satisfacer los requerimientos de

información de más de un interesado en el sistema, y que la combinación de ellas
en una sola no implica mucha complejidad sino, por el contrario, ayuda a
satisfacer los de todos estos interesados
 Vistas y mas allá (Views and
Beyond)
Views and Beyond sugiere utilizar una plantilla, con siete partes fundamentales:

1. Representación primaria
2. Catálogo de elementos
2.1. Elementos y sus propiedades
2.2. Relaciones y sus propiedades
2.3. Interfaces
2.4. Comportamiento
3. Diagrama de contexto
4. Guía de variabilidad
5. Antecedentes de la arquitectura
5.1. Justificación de tas decisiones de diseño
5.2. Análisis de resultados
5.3. Suposiciones
6. Otra información
Vistas y mas allá (Views and
Beyond)
1. Representación primaria de la vista.

• Es una representación gráfica de la vista en términos de sus principales elementos

y relaciones, así como el texto correspondiente para describir de forma general la
información anterior

2. Catálogo de elementos.

• Esta sección hace las veces de un catálogo que contiene los elementos de la
representación primaria describiéndolos con detalle.
• La información explícita acerca de estos incluye, propiedades, interfaces o
comportamiento.
Vistas y mas allá (Views and
Beyond)
3. Diagrama de contexto.

• Permite ubicar al lector de la documentación sobre cuál parte del sistema es la

que se describe en la vista.

4. Guía de variabilidad.

• Describe los posibles puntos de variación permisibles, si es que existen, de los

elementos y relaciones representados en la vista.
• Ejemplos de estas variaciones incluyen rangos en los valores de las propiedades
de los componentes, o variaciones en los protocolos de comunicación soportados
por ellos.
Vistas y mas allá (Views and
Beyond)
5. Antecedentes de la arquitectura.

• Explica las razones que soportan las decisiones de diseño tomadas por el
arquitecto durante el diseño de elementos y relaciones representadas en la
vista

6. Otra información.

• En esta sección se describe información relevante extra que aplique a la vista.

• Algunos ejemplos de ella: reglas de negocio, información sobre el equipo de
desarrollo o descripción del sistema.
Vistas y mas allá (Views and
Beyond)

Caso de estudio –
Documentación de la
Arquitectura
 4+1 Vistas (4+1 Views)

• Es un marco conceptual para la documentación de arquitectura propuesto

por Philtppe Kruchten (Kruchten, 1995).

• Considera la noción de vista como concepto principal; recomienda de

modo especifico la elaboración cinco vistas: Vista Lógica, Vista de
Desarrollo, Vista de Proceso, Vista Física, (+1) Vista de Escenarios.
 Vista Lógica: funcionalidad del sistema

Vista de Desarrollo: módulos, capas,...

Vistas
unidades de ejecución,
Vista de Proceso:
concurrencia...

Topología de
Vista Física:
infraestructura y desarrollo

(+1) Vista de Escenarios: casos de uso o escenarios

 Plantilla de documentación sugerida

1. Representación primaria
2. Catálogo de elementos
2.1. Elementos y sus propiedades
2.2. Relaciones y sus propiedades
2.3. Interfaces
2.4. Comportamiento
3. Diagramo de contexto
4. Guía de variabilidad
5. Antecedentes de la arquitectura
5.1. Justificación de las decisiones de diseño
5.2. Análisis de resultados
5.3. Suposiciones
6. Otra información
Estudio de caso

La clínica online Diet Fast nace con el

objetivo de que la gente tenga un lugar en la
web dónde poder hacer un seguimiento de
su peso y poder controlar su alimentación,
aunque el objetivo principal es que los
dietistas tengan un sitio común dónde poder
ofrecer sus conocimientos a través de
artículos y poner a disposición de la gente
dietas creadas por ellos.
 Estudio de caso

Las funcionalidades que ofrece este portal web son las siguientes:

❖ Envió de sugerencias para mejorar Diet Fast

❖ Enlace directo a las últimas noticias de salud generadas en el periódico del país
❖ Posibilidad de suscribirse mediante RSS para saber cuáles son las últimas dietas creadas por
nuestros colaboradores
❖ Realizar un seguimiento de su peso en el tiempo de manera gráfica, para ello se dispone de la
posibilidad de actualizarlo diariamente
❖ Calcular el IMC, la energía diaria que necesita y el contenido energético de su menú
❖ Consulta de los artículos que escriben nuestros colaboradores
❖ Consulta de las dietas, así las recomendaciones de alimentos, formas de preparación y
equivalencias entre alimentos
 Estudio de caso

Los requisitos la implementación del portal web: [Link]

• Colaboración de los usuarios en los contenidos, por lo que la página cambia constantemente.
• Tres tipos de usuarios registrados con diferentes privilegios: Normal, Colaborador, Gestor
• Uso de XML para generar las RSS en las que los usuarios dispondrán en el navegador Mozilla Firefox de un marcador
dinámico con las 4 últimas dietas de Diet Fast.
• Ficheros y aplicación marcados con licencia GPL y copyright del autor
• Los usuarios se deben validar para acceder a su sesión mediante usuario y password
• Los passwords de los usuarios almacenados en la base de datos deben contener al menos 6 datos alfanuméricos, a
excepción de caracteres especiales ( * @ i & % $ # )
• Se crean sesiones de modo que los usuarios no pueden acceder a páginas a las que no tienen permiso debido al tipo
de usuario
• Uso de fckeditor, qué es un editor de texto, para que los colaboradores creen sus artículos y dietas con el formato que
deseen (en los enlaces está la dirección del autor para descargarla).
• Uso de magpierss que es una librería para incluir en páginas web noticias RSS de otras web
• Uso de una base de datos para gestionar la información de la aplicación
Vista Lógica – Diagrama de clases
Vista de desarrollo – Diagrama de componentes
Vista de procesos – Diagrama de actividades
Vista de fisica – Diagrama de despliegue
Vista de escenarios – Diagrama de casos de uso
 Requerimientos de la
arquitectura

Ciclo de vida Diseño de la arquitectura

Documentación de la A efecto de identificar posibles riesgos o problemas es

arquitectura conveniente evaluar el diseño una vez que este ha sido
documentado

Evaluación de la
arquitectura La ventaja de la evaluación es que representa una
actividad que puede realizarse de manera temprana
(aun antes de codificar), y que el costo de corrección de
los defectos identificados por medio de ella es mucho
Implementación de la menor al costo que tendría enmendarlos después de
arquitectura que el sistema ha sido construido
 Requerimientos de la
arquitectura

Ciclo de vida
Diseño de la
arquitectura

Documentación de la
arquitectura

Evaluación de la
arquitectura
Una vez establecida la arquitectura, se construye el
sistema.
Implementación de la
arquitectura
Durante esta etapa es importante evitar que ocurran
desviaciones respecto del diseño definido por el
arquitecto
 Unidad 1: Arquitecturas de Software
Orientadas a Servicio
1.1. Arquitecturas de software 1.3.3. SOA aplicando software libre.
1.1.1. Conceptos. 1.3.4. SOA aplicando software propietario.
1.1.2. Arquitecturas 1.3.5. Restful, SOAP, WSDL aplicando software libre
1.1.3. Modelos y vistas 1.3.6. Restful, SOAP, WSDL aplicando software
propietario
1.1.4. Evolución
1.4. Gobernabilidad de la arquitectura
1.1.5. Estilos
orientada a servicios
1.1.6. Modelos
1.4.1. Conceptos
1.2. Aplicación de Patrones de diseño. 1.4.2. Marco
1.2.1. Patrones generales.
1.2.2. Patrones de arquitectura.
[Link] Orientadas a Servicios.
1.3.1. Conceptos
1.3.2. Software as Service
¿Qué son los
patrones de
diseño?
1.2. Aplicación de Patrones de diseño

En arquitectura de software a menudo

surgen términos como patrones, sin
embargo, existen dos tipos de patrones, los
patrones de diseño y los patrones
arquitectónicos, los cuales no son lo mismo
y no deberían ser confundidos por ninguna
razón.
 1.2. Aplicación de Patrones de diseño

Patrón de diseño

• Es la solución a un problema de diseño, el

cual debe haber comprobado su efectividad
resolviendo problemas similares en el
pasado, también tiene que ser reutilizable,
por lo que se deben poder usar para resolver
problemas parecidos en contextos diferentes.
 1.2. Aplicación de Patrones de diseño

Patrones
Creacionales

Tipos de patrones Patrones

de diseño Estructurales

Patrones de
Comportamiento
1.2. Aplicación de Patrones de diseño

Patrones Creacionales

• Son patrones de diseño relacionados con la

creación o construcción de objetos.

• Estos patrones intentan controlar la forma

en que los objetos son creados,
implementando mecanismos que eviten la
creación directa de objetos.
 1.2. Aplicación de Patrones de diseño
Patrón Factory
Method

Patrón Abstract
Factory

Patrón Singleton
Patrones
Creacionales
Patrón Builder
Tipos de patrones Patrones
de diseño Estructurales
Patrón Prototype
Patrones de
Comportamiento
Patrón Object Pool
1.2. Aplicación de Patrones de diseño

Patrones Estructurales

• Son patrones que tiene que ver con la

forma en que las clases se relacionan con
otras clases.

• Ayudan a dar un mayor orden a nuestras

clases ayudando a crear componentes
más flexibles y extensibles.
 1.2. Aplicación de Patrones de diseño
Patrón Adapter

Patrón Bridge

Patrones
Patrón Composite
Creacionales

Tipos de patrones Patrones

Patrón Decorator
de diseño Estructurales

Patrones de
Patrón Facade
Comportamiento

Patrón Flyweight

Patrón Proxy
1.2. Aplicación de Patrones de diseño

Patrones de Comportamiento

• Son patrones que están relacionados con

procedimientos y con la asignación de
responsabilidad a los objetos.

• Los patrones de comportamiento engloban

también patrones de comunicación entre
ellos
 Patrón Iterator

Patrón Command
Patrones
Patrón Observer
Creacionales
Patrón Template Method
Tipos de patrones Patrones
de diseño Estructurales Patrón Strategy

Patrones de Patrón Chain of Responsability

Comportamiento Patrón Interpreter

Patrón Mediator

Patrón Memento

Patrón Null Object

Patrón State

Patrón Visitor
 1.2. Aplicación de Patrones de diseño

Factory Method
 1.2. Aplicación de Patrones de diseño

Factory Method
▪ También llamado: Método fábrica, Constructor virtual

▪ Es un patrón de diseño creacional que proporciona una

interfaz para crear objetos en una superclase, mientras
permite a las subclases alterar el tipo de objetos que
se crearán.

▪ En lugar de llamar al constructor directamente para crear un

objeto, el patrón Factory Method delega esta tarea a
métodos especializados que pueden ser sobreescritos en las
subclases.
 1.2. Aplicación de Patrones de diseño
Características Proporciona una interfaz para crear un objeto, pero
Interfaz de creación permite a las subclases decidir cuál es la clase concreta
que se va a instanciar.

Separa el código que crea objetos del código que usa esos
Desacoplamiento:
objetos, promoviendo un diseño más flexible y mantenible.

Facilita la adición de nuevas clases de productos sin

Extensibilidad modificar el código existente, solo extendiendo las clases
de fábrica.

Las subclases pueden controlar cómo se crean los objetos y

Control sobre la
pueden agregar lógica adicional durante el proceso de
creación de objetos
creación
1.2. Aplicación de Patrones de diseño
1.2. Aplicación de Patrones de diseño
 1.2. Aplicación de Patrones de diseño

Builder (Constructor)
 1.2. Aplicación de Patrones de diseño

Builder (Constructor)
Definición
• Es un patrón de diseño creacional que nos permite
construir objetos complejos paso a paso.

• El patrón nos permite producir distintos tipos y

representaciones de un objeto empleando el mismo
código de construcción.
 1.2. Aplicación de Patrones de diseño

Builder (Constructor)
Problema
• Imaginemos un objeto complejo que requiere una
inicialización laboriosa, paso a paso, de muchos campos y
objetos anidados.

• Normalmente, este código de inicialización está sepultado

dentro de un monstruoso constructor con una gran cantidad
de parámetros. O, peor aún: disperso por todo el código
cliente.
 1.2. Aplicación de Patrones de diseño

Builder (Constructor)
 1.2. Aplicación de Patrones de diseño

Builder (Constructor)
 1.2. Aplicación de Patrones de diseño

Builder (Constructor)
El patrón Builder sugiere sacar el
código de construcción del objeto de
su propia clase y colocarlo dentro
de objetos independientes
llamados constructores.
 1.2. Aplicación de Patrones de diseño

Builder (Constructor)

Los distintos constructores ejecutan la misma tarea de formas distintas.

 Unidad 1: Arquitecturas de Software
Orientadas a Servicio
1.1. Arquitecturas de software 1.3.3. SOA aplicando software libre.
1.1.1. Conceptos. 1.3.4. SOA aplicando software propietario.
1.1.2. Arquitecturas 1.3.5. Restful, SOAP, WSDL aplicando software libre
1.1.3. Modelos y vistas 1.3.6. Restful, SOAP, WSDL aplicando software
propietario
1.1.4. Evolución
1.4. Gobernabilidad de la arquitectura
1.1.5. Estilos
orientada a servicios
1.1.6. Modelos
1.4.1. Conceptos
1.2. Aplicación de Patrones de diseño. 1.4.2. Marco
1.2.1. Patrones generales.
1.2.2. Patrones de arquitectura.
[Link] Orientadas a Servicios.
1.3.1. Conceptos
1.3.2. Software as Service
 ¿Qué son los
patrones
arquitectónicos?
 A diferencia de los patrones de
diseño, los patrones
arquitectónicos tienen un gran
impacto sobre el componente, lo
que quiere decir que cualquier
cambio que se realice una vez
construido el componente
podría tener un impacto mayor.
“Los patrones de arquitectura ayudan a definir las características básicas y el
comportamiento de una aplicación.”
— Software Architecture Patterns - Mark Richards

“Los patrones arquitectónicos son un método para organizar bloques de funcionalidad para
satisfacer una necesidad. Los patrones se pueden utilizar a nivel de software, sistema o
empresa. Los patrones bien expresados le dicen cómo usarlos, y cuándo. Los patrones se
pueden caracterizar según el tipo de solución a la que se dirigen. “
— MITRE

“Expresa una organización estructural fundamental o esquema para sistemas de software.

Proporciona un conjunto de subsistemas predefinidos, especifica sus responsabilidades e
incluye reglas y pautas para organizar las relaciones entre ellos. “
— TOGAF
Los patrones de diseño son diferentes a los
patrones arquitectónicos.

Tanto los patrones de diseño cómo los patrones

arquitectónicos pueden resultar similares ante un
arquitecto inexperto, pero por ninguna razón
debemos confundirlos, ya son cosas diferentes.
Patrones arquitectónicos
• Data Transfer Object (DTO)
• Data Access Object (DAO)
• Polling
• Webhook
• Load Balance
• Service Registry
• Service Discovery
• API Gateway
• Access token
• Single Sign On (Inicio de sesión único)
• Store and forward
• Circuit Breaker
• Log aggregation
DTO (Data Transfer Object)
Introducción

• Hoy en día vivimos en una época donde prácticamente todas las

aplicaciones tienen necesidad de intercambiar mensajes con
terceros, ya sea componente que integran información con otros
sistemas o servicios que disponibilizamos para que cualquiera pueda
interactuar con nuestro sistema.
• Sea cual sea el caso, tenemos la necesidad de enviar mensajes, dichos
mensajes por lo general tiene un correlación directa con las Entidad de
nuestra aplicación, por lo que es común utilizar dichas entidades cómo
objetos de nuestros servicios.
DTO (Data Transfer Object)
Problemas

• Una de las problemáticas más comunes cuando

desarrollamos aplicaciones, es diseñar la forma en que la
información debe viajar desde una capa de la aplicación a
otra capa, ya que muchas veces por desconocimiento o
pereza, utilizamos las clases de entidades para retornar los
datos, lo que ocasiona que retornemos más datos de los
necesarios, o incluso, tengamos que ir en más de una ocasión
a la capa de servicios para recuperar los datos requeridos.
DTO (Data Transfer Object)

Problemas

• El patrón DTO tiene como finalidad la creación de

objetos planos (POJO) con una serie de atributos que
puedan ser enviados o recuperados del servidor en
una sola invocación, de tal forma que un DTO puede
contener información de múltiples fuentes o tablas y
concentrarlas en una única clase simple.
DTO (Data Transfer Object)
Solución

• Utilizar una Entity o cualquier otro objeto que haya sido creado para
otro propósito diferente que el de ser usado para transmisión de
datos puede tener complicaciones, por lo que el Patrón Data
Transfer Object (DTO) propone que en lugar de usar estas clases,
creemos clases especiales para transmitir los datos, de esta forma,
podemos controlar los datos que enviamos, el nombre, el tipo de
datos, etc, además, si estos necesitan cambiar, no tiene impacto
sobre la capa de servicios o datos, pues solo se utilizan para
transmitir la respuesta.
DTO (Data Transfer Object)
DTO (Data Transfer Object)
Solución

• En este nuevo ejemplo podemos ver que hemos creado un nuevo

objeto llamado CustomerDTO, en el cual podemos agregar
libremente cuanto atributo requiramos, incluso, podemos
asignarle valores de diferentes fuentes de datos.
• Debido a que el DTO es una clase creada únicamente para una
determinad respuesta, es posible modificarla sin mucho
problema, pues no tiene un impacto en la capa de servicios o de
datos, ya que en estas capas se trabaja con las Entidades.
DTO (Data Transfer Object)
¿Qué es un DTO?

• Un DTO (Data Transfer Object) es un objeto

diseñado para transportar datos entre diferentes
capas o componentes de una aplicación. Se utiliza
principalmente para aislar las entidades del
dominio de la lógica de negocio y reducir la
cantidad de datos innecesarios que se transfieren.
DTO (Data Transfer Object)

Reducir la cantidad de datos enviados Al incluir únicamente los campos relevantes para una
Propósito

a través de la red operación específica.

Aislar las entidades del dominio de la Esto evita exponer detalles internos de la base de
exposición directa datos o de la lógica de negocio.

Facilitar la estructuración y Al tener un formato definido y específico para el

manipulación de datos transporte.
DTO (Data Transfer Object)
Característica Entidad DTO
Representa una tabla Transporta datos entre capas
Propósito
en la base de datos. o sistemas.
Manejo interno de
Transferencia de datos en
Uso datos y lógica de
operaciones específicas.
negocio.
Fuertemente acoplada Independiente de la base de
Dependencia de la BD
a la base de datos. datos.
Contiene toda la Incluye solo los datos
Estructura información del necesarios para el caso de
dominio. uso.
DTO (Data Transfer Object)
Evita exponer detalles internos o sensibles de las
Seguridad
entidades.
Ventajas

Separación de Desacopla la lógica de negocio de la lógica de

preocupaciones presentación.

Optimización del Minimiza el tamaño de los datos transferidos al

rendimiento incluir solo los campos necesarios.

Permite estructurar los datos según las

Flexibilidad necesidades específicas de cada cliente o
componente.
DTO (Data Transfer Object)
Cuándo Usar DTOs

Para enviar respuestas controladas y

En APIs RESTful:
específicas al cliente.

Para transferir datos entre diferentes servicios o

En sistemas distribuidos:
microservicios.

Donde los datos necesitan ser procesados o

En proyectos con lógica de
transformados antes de ser mostrados al
presentación compleja
usuario.
¿Cómo diferenciar un patrón
arquitectónico?
▪ Los patrones arquitectónicos son fáciles de reconocer
debido a que tiene un impacto global sobre la
aplicación.

▪ El patrón rige la forma de trabajar o comunicarse con

otros componentes.

▪ Cualquier cambio que se realice sobre ellos tendrá un

impacto directo sobre el componente, e incluso, podría
tener afectaciones con los componentes relacionados.
 ¿QUÉ SON LOS
ESTILOS
ARQUITECTÓNICOS?
 Introducción
• Para comprender que es un estilo arquitectónico, es necesario
regresarnos un poco a la arquitectura tradicional
(construcción), para ellos, un estilo arquitectónico es un
método específico de construcción, caracterizado por las
características que lo hacen notable y se distingue por las
características que hacen que un edificio u otra estructura
sea notable o históricamente identificable.
 En el software aplica
exactamente igual, pues un
estilo arquitectónico
determina las
características que debe
tener un componente que
utilice ese estilo, lo cual hace
que sea fácilmente
reconocible.
“Un estilo arquitectónico define una familia de sistemas en términos de un patrón de organización estructural;
Un vocabulario de componentes y conectores, con restricciones sobre cómo se pueden combinar.”

— M. Shaw and D. Garlan, Software architecture: perspectives on an emerging discipline. Prentice Hall, 1996.

“Un estilo de arquitectura es una asignación de elementos y relaciones entre ellos, junto con un conjunto de
reglas y restricciones sobre la forma de usarlos”

—Clements et al., 2003

“Un estilo arquitectónico es una colección con nombre de decisiones de diseño arquitectónico que son
aplicables en un contexto de desarrollo dado, restringen decisiones de diseño arquitectónico que son
específicas de un sistema particular dentro de ese contexto, y obtienen cualidades beneficiosas en cada uno
sistema resultante.”

—R. N. Taylor, N. Medvidović and E. M. Dashofy, Software architecture: Foundations, Theory and Practice. Wiley,
2009.
Definición

• Un estilo arquitectónico establece un marco de

referencia a partir del cual es posible construir
aplicaciones que comparten un conjunto de
atributos y características mediante el cual es
posible identificarlos y clasificarlos.
Los estilos arquitectónicos son diferentes a los patrones
arquitectónicos.

A pesar de que puedan parecer similares por su nombre,

los patrones arquitectónicos y los estilos arquitectónicos
son diferentes y por ningún motivo deben de confundirse.
 Monolítico

Cliente-Servidor

Peer-to-peer (P2P)

Arquitectura en Capas
Estilos
Microkernel
arquitectónicos
Service Oriented Architecture (SOA)

Microservicios

Event Driven Architecture (EDA)

Representational State Transfer (REST)

Unidad 1: Arquitecturas de Software
Orientadas a Servicio
1.1. Arquitecturas de software 1.3.3. SOA aplicando software libre.
1.1.1. Conceptos. 1.3.4. SOA aplicando software propietario.
1.1.2. Arquitecturas 1.3.5. Restful, SOAP, WSDL aplicando software libre
1.1.3. Modelos y vistas 1.3.6. Restful, SOAP, WSDL aplicando software
propietario
1.1.4. Evolución
1.4. Gobernabilidad de la arquitectura
1.1.5. Estilos
orientada a servicios
1.1.6. Modelos
1.4.1. Conceptos
1.2. Aplicación de Patrones de diseño.
1.4.2. Marco
1.2.1. Patrones generales.
1.2.2. Patrones de arquitectura.
[Link] Orientadas a Servicios.
1.3.1. Conceptos
1.3.2. Software as Service
 1.3. Arquitecturas Orientadas a Servicios

Recordemos la definición de “Estilo arquitectónico”

Un estilo arquitectónico establece un marco de referencia a partir del cual es

posible construir aplicaciones que comparten un conjunto de atributos y
características mediante el cual es posible identificarlos y clasificarlos.

Los estilos arquitectónicos no determinan la tecnología ni los detalles de

implementación
Un error común es creer que los estilos arquitectónicos determinan las
tecnologías a utilizar o que definen de alguna forma como los componentes
deben de ser construidos. En su lugar, solo brindan ciertos lineamentos que
ayudan a clasificar al software por medio de sus características.
1.3. Arquitecturas Orientadas a
Servicios

También conocida como arquitectura orientada a

servicios es un enfoque de desarrollo de software en
el cual los procesos se descomponen en servicios y
después estos se hacen disponibles en red.
 1.3. Arquitecturas Orientadas a
Servicios

Servicio: Es una función bien

definida, autocontenida e
independiente del contexto o
estado de otros servicios.
1.3. Arquitecturas Orientadas a
Servicios

En SOA la funcionalidad deseada se

descompone en unidades (servicios), que
pueden ser distribuidos en diferentes nodos
conectados a través de una red y de igual forma
son combinados para alcanzar un resultado
deseado.
1.3. Arquitecturas Orientadas a
Servicios
 1.3. Arquitecturas Orientadas a
Servicios
Conclusión SOA es un modelo de componentes que interrelaciona las diferentes
unidades funcionales de las aplicaciones, denominadas servicios, a
través de interfaces y contratos bien definidos entre esos servicios.

La interfaz se define de forma neutral, y debería ser independiente de

la plataforma hardware, del sistema operativo y del lenguaje de
programación utilizado.

Los servicios construidos sobre sistemas heterogéneos pueden

interactuar entre ellos de una manera uniforme y universal.
 1.3. Arquitecturas Orientadas a
Servicios

COMPONENTES
1.3. Arquitecturas Orientadas a
Servicios

Consumidores

✓ Puede ser una aplicación, módulo de software u otro

servicio.

✓ Demanda la funcionalidad que el servicio proporciona.

✓ Ejecuta en una interfaz definida.

 1.3. Arquitecturas Orientadas a
Servicios

Servicios

✓ Componente reutilizable de software.

Contrato
Implementación
Interfaz
 1.3. Arquitecturas Orientadas a
Servicios

Contrato
Implementación
Especificación de la
Interfaz
finalidad, Contiene la lógica o el
funcionalidad, forma
Servicios acceso a datos Mecanismo de
de uso y restricciones
exposición del servicio
del servicio
a los usuarios
 1.3. Arquitecturas Orientadas a
Servicios

Repositorio de servicio

✓ Facilita la búsqueda de servicios.

✓ Permite la adquisición de la información necesaria para uso de servicios.

✓ Fuera del tiempo y función del proyecto para el que se crearon

 1.3. Arquitecturas Orientadas a
Servicios

Bus de servicios
✓ Middleware:
✓ Capa de software intermedio entre el cliente y el servidor.
✓ Permite gestionar los mecanismos de comunicación.
 1.3. Arquitecturas Orientadas a
Servicios
SOA y la Integración de Aplicaciones Corporativas
(EAI Enterprise Application Integration):

La Integración de Aplicaciones Empresariales consiste en

coordinar múltiples aplicaciones que han sido
desarrolladas de manera independiente, posiblemente
empleando tecnologías no compatibles.
1.3. Arquitecturas Orientadas a
Servicios
Integración de Aplicaciones Corporativas (EAI)

La EAI persigue el permitir compartir, sin

ninguna restricción, los datos y procesos
entre aplicaciones y fuentes de datos en una
empresa.
 1.3. Arquitecturas Orientadas a
Servicios

• La Integración de Aplicaciones
Corporativas (EAI), es un paso en la
evolución de los middleware
abordando aspectos de integración.

• En arquitecturas de 3-niveles se
facilita la integración de gestores de
recursos diferentes, desarrollando la
lógica de la nueva aplicación en el
middleware.
 1.3. Arquitecturas Orientadas a
Servicios
La funcionalidad resultante puede ser expuesta como un nuevo
servicio, que puede ser integrado por servicios de más alto nivel, y
así sucesivamente.

Por lo tanto Web Services, se considera una tecnología

fundamental para dominar y manejar la complejidad y
heterogeneidad de los Sistemas de Información
Empresariales.
1.3. Arquitecturas Orientadas a
Servicios
1.3. Arquitecturas Orientadas a
Servicios
 1.3. Arquitecturas Orientadas a
Servicios

Servicio Web es una función bien definida, autocontenida y

no depende del contexto o estado de otros servicios.

Ejemplo: API de Google Maps

([Link]
-419)
 1.3. Arquitecturas Orientadas a
Servicios
Servicios
Componente reutilizable de software.

Contrato Implementación Interfaz

Especificación de la
finalidad, Mecanismo de
Contiene la lógica o el
funcionalidad, forma exposición del servicio
acceso a datos
de uso y restricciones a los usuarios
del servicio.
 1.3. Arquitecturas Orientadas a
Servicios

Los Servicios Web son aplicaciones o tecnologías que intercambian datos

entre sí, con el objetivo de ofrecer servicios.

Los proveedores ofrecen sus servicios como procedimientos remotos y los

usuarios solicitan un servicio llamando a estos procedimientos a través de la
Web
1.3. Arquitecturas Orientadas a
Servicios
 1.3. Arquitecturas Orientadas a
Servicios
Tecnologías de Servicios Web

SOAP (Simple Object Access Protocol)

✓ SOAP (Simple Object Access Protocol) es un protocolo basado en XML, que permite la
interacción entre varios dispositivos y que tiene la capacidad de transmitir información
compleja.

✓ Los datos pueden ser transmitidos a través de HTTP, SMTP, etc. SOAP especifica el
formato de los mensajes.
 1. Un proveedor de servicio describe su servicio usando Web Services Description Language (WSDL). Esta
definición es publicada en el directorio de servicios. El directorio puede usar Description, Discovery and

COMUNICACION Integration (UDDI).

2. Un consumidor de servicios emite una o más consultas al directorio para localizar un servicio y
determinar cómo comunicarse con él.

3. Parte del WSDL provisto por el proveedor de servicio es transmitido al Consumidor de servicio. Esto
dice al consumidor de servicio cuales de las solicitudes y respuestas son para el proveedor de servicio.

4. El consumidor de servicio usa WSDL para enviar una solicitud al proveedor.

5. El proveedor de servicio otorga la respuesta esperada al consumidor.

 1.3. Arquitecturas Orientadas a
Servicios
Tecnologías de Servicios Web

SOAP (Simple Object Access Protocol)

✓ El mensaje SOAP está compuesto por un envelope (sobre),

cuya estructura está formada por los siguientes elementos:
header (cabecera) y body (cuerpo)
1.3. Arquitecturas Orientadas a
Servicios
 1.3. Arquitecturas Orientadas a
Servicios
Tecnologías de Servicios Web

WSDL (Lenguaje de Descripción de Servicios Web)

✓ WSDL(Lenguaje de Descripción de Servicios Web), permite que un servicio y un cliente

establezcan un acuerdo en lo que se refiere a los detalles de transporte de mensajes y
su contenido, a través de un documento procesable por dispositivos.

✓ WSDL representa una especie de contrato entre el proveedor y el que solicita.

✓ WSDL especifica la sintaxis y los mecanismos de intercambio de mensajes

1.3. Arquitecturas Orientadas a
Servicios
1.3. Arquitecturas Orientadas a
Servicios
1.3. Arquitecturas Orientadas a
Servicios
 1.3. Arquitecturas Orientadas a
Servicios
Tecnologías de Servicios Web

UDDI (Universal Description, Discovery and Integration). Provee la definición de un

conjunto de servicios, soportando la descripción y descubrimiento de:

1) Negocios, organizaciones y otros proveedores de Servicios Web.

2) Los servicios Web disponibles.

3) Las interfaces técnicas que pueden ser usadas para acceder a los servicios.
1.3. Arquitecturas Orientadas a
Servicios

Los Servicios Web son aplicaciones o tecnologías que intercambian

datos entre sí, con el objetivo de ofrecer servicios.

Los proveedores ofrecen sus servicios como procedimientos remotos

y los usuarios solicitan un servicio llamando a estos procedimientos a
través de la Web
1.3. Arquitecturas Orientadas a
Servicios
 1.3. Arquitecturas Orientadas a
Servicios
Usando XML como un Formato Común de Datos
Para compartir datos entre aplicaciones ejecutándose en diferentes computadoras, los desarrolladores deben
tener un formato común independiente de la arquitectura.

eXtensible Markup Language o XML es un Formato de datos

aceptado universalmente:

✓ Basado en texto
✓ Humanamente leíble
✓ Permite definir una gramática para describir cualquier tipo de
datos
✓ Aplicaciones deben estar de acuerdo en diseño o esquema de los
datos.
 1.3. Arquitecturas Orientadas a
Servicios
Además de XML se requiere un protocolo para enviar y recibir peticiones

Simple Object Access Protocol. Esta especificación

SOAP define:

✓ El formato del mensaje SOAP

✓ Como deben ser codificados los datos
✓ Como enviar los mensajes
✓ Como manejar las respuesta a estos mensajes
 1.3. Arquitecturas Orientadas a
Servicios
Usando el protocolo SOAP y XML como el formato común de los mensajes
queda un pregunta:

¿Como saber los mensajes que un cliente envía hacia un Servicio Web y la respuesta
que recibirá?

Mediante un documento Web Services Description Language (WSDL) un servicio Web

puede conocer los mensajes que un cliente puede enviar y la respuesta que recibirá.
 1.3. Arquitecturas Orientadas a
Servicios
Service Endpoints

Un host pone disponible un servicio web por medio de un endpoint a donde los clientes pueden realizar
peticiones y consiste en 3 piezas:

1. La dirección del servicio. Depende del protocolo. Por ejemplo HTTP: [Link]

2. El binding soportado por el servicio. Describe como el cliente se puede conectar al servicio y el formato
de los datos esperados:

a. Protocolo de transporte. HTTP, HTTPS, TCP, Named-Pipes (shared folders) y Message Queues (e-
mail).
b. Formato de codificación de mensajes. XML, TEXT, BINARIO, JSON.
c. Requerimientos de seguridad. SSL, username/password, etc.
d. La confiabilidad de los comunicaciones con el servicio. Las redes pueden fallar, por lo que el servicio
debe asegurar la integridad de las conversaciones.
 1.3. Arquitecturas Orientadas a
Servicios
Service Endpoints

3. El contrato implementado por el servicio. Es una

interface anotada con el atributo

✓ [ServiceContract]. Describe las operaciones

implementadas por el servicio marcadas con el
atributo

✓ [OperationContract]. El servicio debe describir la

estructura de los datos compuestos y como deben
ser serializados.
1.3. Arquitecturas Orientadas a
Servicios

SERVICIOS WEB
REST
1.3. Arquitecturas Orientadas a
Servicios

¿Por qué otro estilo REST?

¿Problemas con SOAP?
 1.3. Arquitecturas Orientadas a
Servicios
SOAP ofrece Junto con los datos, muchos metadatos también necesitan ser transferidos en cada
petición y respuesta.
una
excelente Esta información extra es necesaria para conocer las capacidades del Servicios Web
a consumir.
manera de
trasferir Este intercambio, hace que la carga en la comunicación sea pesada aun para
pequeños datos.
datos entre
aplicaciones, Además, los clientes necesitan crear un proxy para empaquetar y desempaquetar
los mensajes SOAP usando WSDL para hacer posible la comunicación.
pero:
El problema con este proxy es que si el servicio es actualizado, pero el cliente no, el
consumo del servicio Web no funcionará correctamente.
 1.3. Arquitecturas Orientadas a
Servicios
Qué es REST?

✓ REST (Representational State Transfer) es un estilo de

arquitectura de software para sistemas distribuidos en la
Web.

✓ Se refiere a una interfaz, que consiste en una red de

recursos Web relacionada por links y operaciones como
GET, DELETE (transiciones de estado).

✓ El término fue introducido en la tesis doctoral de Roy

Rielding en 2000, quien es uno de los principales autores
de la especificación HTTP.
1.3. Arquitecturas Orientadas a
Servicios
Qué es REST?
REST no es un estándar, es un estilo de arquitectura y el
término se refiere estrictamente a una colección de principios
para el diseño de arquitecturas de red.

Estos principios resumen cómo los recursos son definidos y

diseccionados.

Frecuentemente se utiliza para describir a cualquier interfaz

que transmite datos específicos de un dominio sobre HTTP sin
una capa adicional como la hace SOAP.
 1.3. Arquitecturas Orientadas a
Servicios
Qué es REST?

Aunque REST no es un estándar, esta basado en estándares:

✓ HTTP - Hypertext Transfer Protocol

✓ URL - Uniform Resource Locator
✓ Representación de recursos: XML/HTML/JSON
✓ Tipos de contenido MIME: text/xml, text/html, text/json
 1.3. Arquitecturas Orientadas a
Servicios
Qué es REST?

✓ Intenta usar todas las características de la Web para el intercambio de mensajes entre computadoras
distribuidas.
✓ Las URIs identifican los recursos, los cuales son objetos conceptuales. La representación de tales
objetos se distribuye por medio de mensajes a través de la Web.
 1.3. Arquitecturas Orientadas a
Servicios
Qué es REST?
Elementos participantes en REST

Debido a que la Web evidentemente es un ejemplo clave de diseño

basado en REST; consiste del protocolo HTTP con una interfaz uniforme
para acceso a los recursos, el cuál consiste de:
 1.3. Arquitecturas Orientadas a
Servicios
Qué es REST?
URIs

Un identificador de recursos uniforme o URI —del inglés Uniform Resource Identifier— es una cadena de
caracteres que identifica los recursos de una red de forma unívoca. Las “cosas” identificadas por URIs
son “recursos”. Aunque es más apropiado decir que los Recursos son identificados mediante URIs.
 1.3. Arquitecturas Orientadas a
Servicios
Qué es REST?
Verbos HTTP

✓ Los verbos más importantes en HTTP son PUT, GET, POST, DELETE.

✓ Suelen ser comparados con las operaciones asociadas a la tecnología de base de datos: CRUD:
CREATE, READ, UPDATE, DELETE.

✓ Otras analogías pueden también ser hechas como con el concepto de copiar-y-pegar (Copy&Paste).
 1.3. Arquitecturas Orientadas a
Servicios
Qué es REST?
Verbos HTTP
 1.3. Arquitecturas Orientadas a
Servicios
Qué es REST?
Verbos HTTP

Cuando utilizamos REST, HTTP no tiene estado. Cada mensaje contiene toda la información
necesaria para comprender la petición.

Como resultado, ni el cliente ni el servidor necesita mantener ningún estado en la

comunicación.
 1.3. Arquitecturas Orientadas a
Servicios
Qué es REST?
Códigos de estado

✓ HTTP especifica un conjunto de códigos de estado para cada llamada.

✓ Es decir, al solicitar un recurso mediante un URI, el servidor regresará un código de estado

de la respuesta, por ejemplo: Éxito, Error o No encontrado.
1.3. Arquitecturas Orientadas a
Servicios
Qué es REST?
 1.3. Arquitecturas Orientadas a
Servicios
REST vs los servicios Web estudiados
anteriormente

Popularmente se generaliza el concepto de servicio Web con el de servicio Web basado en SOAP. Como
hemos visto en apartados anteriores, es posible diseñar servicios Web basados en REST, es decir
tomando REST como estilo de diseño.

Por tanto, REST no es una alternativa a los servicios Web, más bien, un servicio Web puede ser
implementado mediante SOAP o basado en el estilo REST.
 1.3. Arquitecturas Orientadas a
Servicios
¿Cómo diseñar un Servicio Web basado en REST?

1. Identificar todas las entidades conceptuales que se desean exponer como servicio.

2. Crear una URL para cada recurso. Los recursos deberían ser nombres, no verbos
(acciones).

Por ejemplo no utilizar esto:

[Link]
Como podemos observar, getEntity es un verbo.
Mejor utilizar el estilo REST, un nombre: [Link]
 1.3. Arquitecturas Orientadas a
Servicios
¿Cómo diseñar un Servicio Web basado en REST?

3. Categorizar los recursos de acuerdo con si los clientes pueden obtener un representación
del recurso o si pueden modificarlo. Para el primero, debemos hacer los recursos
accesibles utilizando un HTTP GET. Para el último, debemos hacer los recursos accesibles
mediante HTTP POST, PUT y/o DELETE.

4. Todos los recursos accesibles mediante GET deben devolver la representación del
recurso.

5. Para los servicios que requieran un POST o un PUT es aconsejable también proporcionar
un esquema para especificar el formato de la respuesta.
 1.3. Arquitecturas Orientadas a
Servicios
¿Cómo diseñar un Servicio Web basado en REST?