Arquitectu

ra de
Software
Diana Patricia Quiroga
Camacho

CORTE 2
Reglas de Juego
• Proyecto Integrador (40%)
• Evaluaciones Parciales (30%)
• Trabajos en clase, estudio de casos y talleres (20%)
• Foros (10%)
ESPECIFICACION DE REQUERIMIENTOS
¿Qué son Requerimientos?

Normalmente, es un tema de la Ingeniería de Software tiene diferentes

significados. De las muchas definiciones que existen para requerimiento, ha
continuación se presenta la definición que aparece en el glosario de la IEEE.

• Una condición o necesidad de un usuario para resolver un problema o

alcanzar un objetivo.
• Una condición o capacidad que debe estar presente en un sistema o
componentes de sistema para satisfacer un contrato, estándar,
especificación u otro documento formal.
• Una representación documentada de una condición o capacidad de lo
explicado en los puntos 1 o 2
ESPECIFICACION DE REQUERIMIENTOS
Características de los Requerimientos: Las características de un
requerimiento son sus propiedades principales:

• Necesario: Si su omisión provoca una deficiencia en el sistema a construir,

y además su capacidad, características físicas o factor de calidad no pueden
ser reemplazados por otras capacidades.
• Conciso: Si es fácil de leer y entender. Su redacción debe ser simple y clara.
• Completo: Si no necesita ampliar detalles en su redacción, es decir, si se
proporciona la información suficiente para su comprensión.
• Consistente: Si no es contradictorio con otro requerimiento.
• No ambiguo: Cuando tiene una sola interpretación. 
• Verificable: Cuando puede ser cuantificado de manera que permita hacer
uso de los siguientes métodos de verificación: inspección, análisis,
demostración o pruebas.
ESPECIFICACION DE REQUERIMIENTOS
Extracción
• Descubrimiento de los
requisitos del sistema
Validación
• Verificar que todos los
requisitos sean consistentes y
completos
Análisis
• Se leen, conceptúan e investigan los
requisitos
• Se intercambian ideas y resaltan los
problemas
• Se dan alternativas y soluciones
• Se fijan reuniones
Especificación
• Documentan los requisitos
• Utilización de técnicas y/o estándares
de documentación
ESPECIFICACION DE REQUERIMIENTOS
• Herramientas:
ESPECIFICACION DE
REQUERIMIENTOS
• REQUERIMIENTOS DE USUARIO: Son declaraciones, en lenguaje
natural y en diagramas, de los servicios que se espera que el
sistema proporcione y de las restricciones bajo las cuales debe
funcionar.

• REQUERIMIENTOS DE SISTEMA: Estos requerimientos establecen

con detalle las funciones, servicios y restricciones operativas del
sistema. El documento de requerimientos del sistema deberá ser
preciso, y definir exactamente lo que se va a realizar.
ESPECIFICACION DE
REQUERIMIENTOS
• REQUERIMIENTOS FUNCIONALES: 
Son declaraciones de los servicios que debe proporcionar el sistema,
de la manera en que éste debe reaccionar a entradas particulares. O
también pueden declarar explícitamente lo que el sistema no debe
hacer. Ejemplos:

• Al aprobar un pedido, la solicitud pasará al siguiente paso del flujo

de trabajo (workflow) de aprobación configurado en el sistema.
• El campo país consistirá en una lista de preselección. El país
asociado a una dirección debe ser previamente registrado en el
sistema
• El sistema controlará el acceso y lo permitirá solamente a usuarios
autorizados. Los usuarios deben ingresar al sistema con un
nombre de usuario y contraseña.
ESPECIFICACION DE
REQUERIMIENTOS
• REQUERIMIENTOS NO FUNCIONALES: 
Son restricciones de los servicios o funciones ofrecidos por el
sistema. Incluyen restricciones de tiempo, sobre el proceso de
desarrollo y estándares. Dentro de estos requerimientos
encontramos todo lo referente a fiabilidad, el tiempo de respuesta y
la capacidad de almacenamiento. Ejemplos

• El promedio de duración de fallas no podrá ser mayor a 15

minutos
• Toda funcionalidad del sistema y transacción de negocio debe
responder al usuario en menos de 5 segundos.
• El tiempo para iniciar o reiniciar el sistema no podrá ser mayor a
5 minutos.
ATRIBUTOS DE CALIDAD
• La calidad de software es todo el conjunto de cualidades que lo caracterizan
determinando su eficiencia y utilidad, satisfaciendo las necesidades tanto
implícitas como explícitas del cliente. La IEEE.Std.610-1990 la define como el
grado con el que un sistema, componente o proceso cumple con los requisitos
especificados y las necesidades o expectativas del cliente o usuario.
[IEEE.Std.610-1990]
ATRIBUTOS DE CALIDAD
ATRIBUTOS DE CALIDAD
• Funcionabilidad: Las funciones son aquellas que satisfacen lo
indicado o implica necesidades.

• Idoneidad: Se enfoca a evaluar si el SW cuenta con un conjunto de

funciones apropiadas para efectuar las tareas que fueron
especificadas en su definición.
• Exactitud: Permite evaluar si el SW presenta resultados o efectos
acordes a las necesidades para las cuales fue creado.
ATRIBUTOS DE CALIDAD
• Funcionabilidad

• Interoperabilidad: Permite evaluar la habilidad del SW de

interactuar con otros sistemas previamente especificados.
• Seguridad: Se refiere a la habilidad de prevenir el acceso no
autorizado, ya sea accidental o promediado, a los programas y
datos.
• Conformidad: Evalúa si el SW se adhiere a estándares,
convenciones o regulaciones en leyes y prescripciones similares.
ATRIBUTOS DE CALIDAD
• Fiabilidad:
• Madurez: Permite medir la frecuencia de falla por errores en
el SW.
• Recuperación: Se refiere a la capacidad de restablecer el nivel
de operación y recobrar los datos que hayan sido afectados
directamente por una falla, así como al tiempo y el esfuerzo
necesario para lograrlo.
• Tolerancia de fallos: Se refiere a la habilidad de mantener un
nivel específico de funcionamiento en caso de fallas del SW o
de cometer infracciones de su interfaz específica.
ATRIBUTOS DE CALIDAD
• Usabilidad: 
• Comprensión: Se refiere al esfuerzo requerido por los
usuarios para reconocer la estructura lógica del sistema y los
conceptos relativos a la aplicación del SW.
• Facilidad de Aprender: Establece atributos del SW relativos al
esfuerzo que los usuarios deben hacer para aprender a usar
la aplicación.
• Operatividad: Agrupa los conceptos que evalúan la operación
y el control del sistema.
ATRIBUTOS DE CALIDAD
• Eficiencia:
• Comportamiento en el tiempo: Atributos del SW
relativos a los tiempos de respuesta y de
procedimiento de los datos.
• Comportamiento de recursos: Atributos de SW
relativos a la cantidad de recursos usados y la
duración de su uso en la realización de sus
funciones.
ATRIBUTOS DE CALIDAD
• Mantenibilidad:
• Estabilidad: Capacidad del SW de tener un desempeño
normal a pesar de hacerse modificaciones.
• Facilidad de análisis: Relativo al esfuerzo necesario para
diagnosticar las deficiencias o causas de fallas, o para
identificar las partes que deberán ser modificadas.
• Facilidad de cambios: Capacidad del que tiene el SW para que
la modificación pueda ser válida.
• Facilidad de pruebas: Capacidad del que tiene el SW para que
la modificación pueda ser válida.
ATRIBUTOS DE CALIDAD
• Portabilidad: 
• Adaptabilidad: Evalúa la oportunidad para adaptar el SW a
diferentes ambientes sin  necesidad de aplicarle
modificaciones.  
• Facilidad de instalación: Es el esfuerzo necesario para instalar
el SW en un      ambiente determinado.  
• Cumplimiento: Permite evaluar si el SW de adhiere a
estándares o convenciones     relativas a portabilidad.  
• Capacidad de reemplazo: Se refiere a la oportunidad y el
esfuerzo usando en       sustituir el SW por otro producto con
funciones similares.
ATRIBUTOS DE CALIDAD
• Métodos prácticos para aplicar a un
ciclo guiado por arquitecturas.
El Software Engineering Institute (SEI)
viene trabajando desde hace más de
diez años en la definición de métodos
para soportar los ciclos de vida
guiados por la arquitectura. Son
métodos prácticos que se sustentan
en el uso de escenarios.
Un escenario es una instancia
concreta del uso del sistema y se
compone de estimulo, elemento
estimulado, resultado esperado en
base a mediciones y el ambiente en
donde el escenario se produce.
ESCENARIOS DE CALIDAD
• QAW (Quality Attribute Workshop): Método que reúne a los participantes
tempranamente en el ciclo de vida, durante un día, para descubrir
los atributos de calidad orientadores de un sistema intensivo de software.
QAW se centra en el sistema y los participantes y se utiliza antes que se
defina la arquitectura del sistema.
• Para resolver el problema de especificar los atributos de calidad y
vincularlos con cada aspecto del problema en común, se utilizan
los escenarios de atributos de calidad. Partes de la especificación:

• Fuente del estímulo: entidad que lo genera.

• Estímulo: condición que necesita ser considerada cuando llega al sistema.
• Entorno: condiciones dentro de las cuales se presenta el estímulo.
• Artefacto: parte del sistema que recibe el estímulo.
• Respuesta: actividad que ocurre luego de la llegada del estímulo.
• Medida de la Respuesta: criterio para testear el requerimiento.
ESCENARIOS DE CALIDAD
• Ejemplos
ESCENARIOS DE CALIDAD
• Ejemplos
Influencias de Arquitectura
• Para que la arquitectura de software
• Abstracción: Se necesita pensar , codificar, y comunicarse en
términos de grandes bloques.
• Reutilización de Patrones: No uso de desarrollos
excesivamente personalizados , uso de estándares de diseño.
• Reutilización de Componentes particulares: Diseño de sistemas
de larga vida.
• Productividad en el desarrollo.
• Portabilidad, escalabilidad y seguridad
• Lenguaje común para diseñadores, desarrolladores y usuarios.
INFLUENCIAS
• Influencias Arquitecto
Elementos atractivos

Marketing Despliegues continuos

Productos de competencia
Bajos Costos
Administrador Comportamiento
Mantener a la gente apropiado
ocupada
Arquitecto
Usuario Final Seguridad

Confiabilidad

Entregas a tiempo
Cliente
Minimización de cambio
frecuentes.
INFLUENCIAS
• Que hace buena una arquitectura

• Ser un producto de un arquitecto o

un grupo con un Líder definido.
• Estar bien documentada que los
stakeholders entiendan.
• Que pueda ser evaluada con
métricas cuantitativas y cualitativas.
• Implementaciones incrementales
• Contar con requerimientos
funcionales y no funcionales.
INFLUENCIAS
• Reglas Estructurales
• Buena definición de los módulos.
• Cada modulo debe tener bien definida las interfaces.
• No depender de una versión de un producto o herramienta
comercial
• Los módulos de producción de datos deben estar separados de
los módulos que consumen los datos.
• Cada proceso bien documentado de fácil mantenimiento,
incluso en tiempo de ejecución.
• Reducción de tiempo de desarrollo
INFLUENCIAS
• Que hace buena una arquitectura
• Ser un producto de un arquitecto o un grupo con un Líder
definido.
• Estar bien documentada que los stakeholders entiendan.
• Que pueda ser evaluada con métricas cuantitativas y
cualitativas.
• Implementaciones incrementales
• Contar con requerimientos funcionales y no funcionales.
• Requerimientos del cliente
CREACION DE LA
ARQUITECTURA
•
Para definir de la mejor forma de la arquitectura de software
tenemos 4 etapas principales:
• Requerimientos: En esta etapa se recolecta la información y se documentan
los requerimientos que influyen en la arquitectura de la aplicación.
• Diseño: Se define el uso de tecnologías adecuadas para resolver el problema.
También se tienen en cuenta patrones como por ejemplo MVC (Modelo,
Vista, Controlador) o arquitectura de microservicios.
• Documentación: Comunicarlo de manera eficiente y eficaz a todos los
involucrados, es importante crear documentación que sea el marco de
trabajo para todos.
• Evaluación: Se puede hacer incluso sin haber hecho una línea de código y ver
con todos los involucrados si hay algo en el diseño que pueda no funcionar y
reformarlo, esta evaluación se debería hacer posterior teniendo métricas por
ejemplo del rendimiento de la aplicación y saber si un cambio mejora o no
dicho rendimiento.
ESTILOS ARQUITECTONICOS
• Es un conjunto de decisiones de diseño arquitectural que son aplicables en un
contexto de desarrollo específico, restringen las decisiones de diseño de un
sistema a ese contexto y plantean como objetivo ciertas cualidades para el
sistema resultante.
• Sirven para sintetizar estructuras de soluciones.
• Pocos estilos abstractos encapsulan una enorme variedad de
configuraciones concretas.
• Definen los patrones posibles de las aplicaciones.
• Permiten evaluar arquitecturas alternativas con ventajas y desventajas
conocidas ante diferentes conjuntos de requerimientos no funcionales.
ESTILOS
ARQUITECTONICOS
• Beneficios
• Reusó de diseños
• Portabilidad de soluciones
• Comunicación clara y efectiva
• Componentes se pueden pasar de un sistema a otro
• Aplicaciones madurez para solución de problemas nuevos.
• Propiedades
• Un conjunto de componentes que realizan una función requerida por el
sistema
• Un conjunto de componentes que permitan la comunicación,
coordinación y cooperación entre los componentes.
• Restricciones de integración entre los sistemas
• Modelos semánticos que permiten que un diseñador entienda las
propiedades generales
ESTILOS ARQUITECTONICOS
ORIENTADA A OBJETOS: Los componentes de un sistema encapsulan los
datos y las operaciones que se deben realizar para manipular los datos.
La comunicación y la coordinación entre componentes se consiguen a
través del paso de mensaje.
Características
 Los componentes del estilo se basan en principios OO
(encapsulamiento, herencia y polimorfismo).
 En este estilo los componentes son los objetos, o
instancias de tipos de datos abstractos.
 Las interfaces están separadas de las implementaciones.
 La distribución de objetos es transparente
 Los objetos interactúan a través de invocaciones a
procedimientos y funciones.

https://www.youtube.com/watch?v=3Tc0rOQN-xw
ESTILOS ARQUITECTONICOS

• ORIENTADA A OBJETOS
• Ventajas
• Modelado mas natural de los problemas
• Mejor manejo de la complejidad
• Fomenta el reusó, con gran impacto en productividad y confiabilidad
• Facilita el mantenimiento y extensión
• Desventajas
• Los objetos al ser abstracto pueden no coincidir la visión de un
programador a otro.
• El concepto de un programador que realiza un objeto abstracto
podría no coincidir con la visión de otro programador. 
ESTILOS ARQUITECTONICOS

• CENTRADA A DATOS: Se fundamenta en el almacenamiento de datos

al que acceden otros componentes que realizan acciones sobre los
datos.

• Características
• Promueve la capacidad de integración, es decir, que es posible
cambiar componentes existentes y agregar nuevos componentes
• Posible pasar datos entre clientes empleando el mecanismo del
pizarrón.
• Los componentes clientes ejecutan los procesos de manera
independiente.
ESTILOS ARQUITECTONICOS
• CENTRADA A DATOS

• Ventajas
• Posibilita la integración de Agentes
• Adecuado para solución de problemas no deterministas.
• Resumen de estado de conocimiento en cada momento del proceso.

• Desventajas
• Estructura de datos común a todos los agentes
• Problemas de carga a la hora de chequear y vigilar el estado de la
pizarra.
• Alto esfuerzo en desarrollo.
ESTILOS ARQUITECTONICOS
• CENTRADA A DATOS
• Arquitectura en Pizarra: Un agente examina la pizarra, realiza su tarea y escribe
sus conclusiones en la misma pizarra. De esta manera, otro agente puede
trabajar sobre los resultados generados por otro.

• Fuente de conocimiento: Proveen áreas de

conocimiento particulares que aportan
hipótesis de la solución y son las
encargadas de leer y escribir en la pizarra
• Pizarra: estructura de datos central.
Provee de una interfaz que permite a todas
las fuentes de conocimiento leer y escribir
en él
• Control: monitorea los cambios en la
pizarra y decide qué acciones tomará
ESTILOS ARQUITECTONICOS
• ARQUITECTURA CENTRADA A DATOS
• Pizarra: Grafos, Datamining, huellas digitales, redes neuronales, análisis de voz,
iris y rostro

Solución:
Una serie de agentes de conocimiento tienen acceso a un
almacén de datos compartidos llamado Pizarra. La Pizarra
proporciona una interfaz para inspeccionar y actualizar su
contenido.
El objeto / módulo de Control activa a los agentes
siguiendo una estrategia. Tras ser activado, un agente
inspecciona la pizarra para ver si puede contribuir a
resolver el problema. Si el agente decide que puede
contribuir, el objeto de control permite a los agentes
poner la solución parcial (o final) en la pizarra.
ESTILOS ARQUITECTONICOS
• CENTRADA A DATOS
• Almacén de Datos: Un Almacén de Datos (Data Warehouse) es una colección
de datos que está formada por Variables (hechos, facts) y Dimensiones
(dimensions). Dimensiones son los elementos para ubicar datos que
participan en el análisis y Variables los valores que se desean analizar.
• Orientado a temas: Los datos en la base de datos están organizados de
manera que todos los elementos de datos relativos al mismo evento u
objeto del mundo real queden unidos entre sí.
• Variante en el tiempo: Los cambios producidos en los datos a lo largo del
tiempo quedan registrados para que los informes que se puedan generar
reflejen esas variaciones.
• No volátil: La información no se modifica ni se elimina, una vez
almacenado un dato, éste se convierte en información de sólo lectura, y
se mantiene para futuras consultas.
• Integrado: La base de datos contiene los datos de todos los sistemas
operacionales de la organización, y dichos datos deben ser consistentes.
ESTILOS
ARQUITECTONICOS
• CENTRADA A DATOS
• Almacén de Datos
ESTILOS ARQUITECTONICOS
• Flujo de Datos: Se aplica cuando los datos de entrada son transformados a
través de una serie de componentes computacionales o manipulativos en los
datos de salida.
• Características
• No se basan en un contador de programa (al menos conceptualmente) en
tanto en cuanto la posibilidad de ejecución de las instrucciones solamente
viene determinada por la disponibilidad de los argumentos de entrada de las
instrucciones
• Cada etapa de procesamiento es un filtro.
• Los datos pasan de un filtro a otro mediante canales.
ESTILOS ARQUITECTONICOS
• Flujo de datos
• Ventajas
• La ejecución fuera de orden se ha convertido en
el paradigma computacional por excelencia desde los años 90. Es una
forma de flujo de datos restringido. Este paradigma introdujo la idea de
ventana de ejecución, que sigue el orden secuencial de la arquitectura de
von Neumann; sin embargo, dentro de la ventana se permite que las
instrucciones sean completadas en el orden de las dependencias de datos.

• Desventajas
• La complejidad lógica de mantener el rastro de las dependencias de datos
de forma dinámica restringe a los procesadores basados en ejecución
fuera de orden a un reducido número de ejecuciones (de 2 a 6) y limita el
tamaño de la ventana de ejecución de 32 a 200 instrucciones, mucho
menor que las utilizadas en las máquinas puras de flujo de datos.
ESTILOS ARQUITECTONICOS
• Flujo de datos
• Tuberías y Filtros: Por los tubos fluyen dato, y son salidas de un filtro y la
entrada de otro. Cada filtro admite uno o varios tubos. Cada filtro es
independiente del resto y no conocen la identidad de los filtros antes y después
de él. No importa la secuencia (paralelismo).
• https://medium.com/@crscardellino/procesando-datos-con-spark-i-configuran
do-apache-spark-y-apache-zeppelin-b8dbda672aa4
• Soluciones :
ESTILOS ARQUITECTONICOS
• Flujo de datos
• Tuberías y Filtros
• Diseño :
• Dividir la tarea en una secuencia de etapas de procesamiento de forma
que la salida de cada etapa sólo dependa de las salidas de sus etapas
adyacentes.
• Definir el formato de los datos que se transmitirán a través de los
canales entre etapas adyacentes (p.ej. ASCII, XML, JSON…).
• Llamadas directas entre filtros.
• Colas con productores/consumidores.
• UNIX pipes
• Middleware (colas de mensajes)
ESTILOS ARQUITECTONICOS
• FLUJO DE DATOS
• Secuencial por Lotes: Los componentes son programas independientes, cada
paso de ejecuta hasta completarse antes que se inicie el paso siguiente.
ESTILOS ARQUITECTONICOS
• Flujo de datos
• Secuencial por Lotes
• Es la estructura típica de un sistema de procesamiento de datos tradicional
por lotes (batch).
• Cada proceso se ejecuta completamente antes de comenzar la ejecución del
siguiente.

Validar Sort Actualizar Reportar

ESTILOS
ARQUITECTONICOS
• Llamada Y Retorno: Esta familia de estilos enfatiza la modificabilidad y la
escalabilidad. Son los estilos más generalizados en sistemas en gran escala.
Miembros de la familia son las arquitecturas de programa principal y subrutina,
los sistemas basados en llamadas a procedimientos remotos, los sistemas
orientados a objeto y los sistemas jerárquicos en capas.

• Características: Los componentes son programas independientes, cada paso de

ejecuta hasta completarse antes que se inicie el paso siguiente.
ESTILOS ARQUITECTONICOS
• Llamada y retorno:

• Ventajas
• Utilizados en grandes sistemas de software.
• La descomposición en módulos disminuye la complejidad.
• Persiguen escalabilidad y modificabilidad.
• Desventajas
• Dependencia y acoplamiento entre módulos.
• La reutilización y el mantenimiento son difíciles
ESTILOS ARQUITECTONICOS
• Llamada y retorno:
• Arquitectura en Capas
• Organización jerárquica, cada capa provee
servicios a su superior y es un cliente para la
inferior.
• Las capas interiores pueden estar ocultas
(restricciones) Ej: protocolos de
comunicación
• Permiten particionar conceptualmente
problemas complejos
• Favorecen la reusabilidad
https://www.youtube.com/watch?v=Wg68_U
g2LSs
ESTILOS ARQUITECTONICOS
• Llamada y retorno:
• Arquitectura en Capas
• En una arquitectura n-layer las capas solamente
interactúan con sus capas adyacentes lo que
permite abstraer funcionalidades de las capas
superiores e inferiores.
• El numero de capas mínimo debe ser de dos.
• Hay varias capas definidas, cada una de ellas realiza
operaciones que se acercan progresivamente al
conjunto de instrucciones de la máquina.
• En la capa externa los componentes sirven a las
operaciones de interfaz del usuario.
• En la capa interna los componentes sirven como
interfaz con el sistema operativo.
• Las capas intermedias proporcionan servicios de
utilería y de SW de aplicaciones
ESTILOS ARQUITECTONICOS
• Codigo Movil: Esta familia de estilos enfatiza la portabilidad. Ejemplos de la
misma son los intérpretes, los sistemas basados en reglas y los procesadores
de lenguaje de comando.
• Arquitectura de Máquinas Virtuales: El estilo comprende básicamente dos
formas o sub-estilos, que se han llamado intérpretes y sistemas basados en
reglas.
• El enfoque de máquina virtual, por otra parte, no incluye alguna funcionalidad
adicional, sino que más bien proporciona una interfaz que es idéntica al
hardware simple que está en la base. A cada proceso se le presenta una copia
(virtual) del computador particular.
ESTILOS ARQUITECTONICOS
• PEER TO PEER:
• Consiste por lo general en procesos independientes o entidades
que se comunican a través de mensajes. Cada entidad puede
enviar mensajes a otras entidades, pero no controlarlas
directamente. Miembros de la familia son los estilos basados en
eventos, en mensajes en servicios y en recursos.
ESTILOS
ARQUITECTONICOS
• PEER TO PEER:
• Arquitectura Basada en Eventos: Una arquitectura basada en eventos consta
de productores de eventos que generan un flujo de eventos, y consumidores de
eventos que escuchan los eventos. Los eventos se entregan casi en tiempo real,
de modo que los consumidores pueden responder inmediatamente a los
eventos cuando se producen. Los productores se desconectan de los
consumidores — un productor no sabe que los consumidores están
escuchando. Los consumidores también se desconectan entre sí, y cada
consumidor ve todos los eventos. 
• https://www.youtube.com/watch?v=i-VmENiPWwA
ESTILOS ARQUITECTONICOS
• PEER TO PEER:
• Arquitectura Orientada a Servicios: Sólo recientemente estas arquitecturas
que los conocedores llaman SOA han recibido tratamiento intensivo en el
campo de exploración de los estilos. Al mismo tiempo se percibe una tendencia
a promoverlas de un sub-estilo propio de las configuraciones distribuidas que
antes eran a un estilo en plenitud.
• https://www.youtube.com/watch?v=7RVzpH6UBRk
PATRONES DE ARQUITECTURA
• Un patrón de arquitectura de software es un esquema genérico probado
para solucionar un problema particular, el cual es recurrente dentro de
un cierto contexto. Este esquema se especifica describiendo los
componentes, con sus responsabilidades y relaciones.

• Objetivos:
• Proporcionar catálogos de elementos reusables en el diseño de
sistemas software.
• Evitar la reiteración en la búsqueda de soluciones a problemas ya
conocidos y solucionados anteriormente.
• Formalizar un vocabulario común entre diseñadores.
• Estandarizar el modo en que se realiza el diseño.
• Facilitar el aprendizaje de las nuevas generaciones de diseñadores
condensando conocimiento ya existente.
PATRONES DE
ARQUITECTURA
• Diferencias Estilos y Patrones:
PATRONES DE
ARQUITECTURA
•
Nivel de Abstracción:
PATRONES DE ARQUITECTURA
• POSA: (Pattern Oriented Software Architecture)
• Su objetivo es presentar y dar el esquema de arquitectura de software
orientada a patrones.
• Explicar cada una de las agrupaciones de patrones, los patrones y su
aplicación.
• Mostrar un lenguaje de patrones que facilitara el diseño de la arquitectura de
software a partir de los diferentes patrones.

Distribuido
Estructura Iterativos Adaptables
s

Capas Broker MVC Microkernel

Presentación – Abstracción
Tuberías y Filtros Reflection
– Control

Pizarra
PATRONES DE ARQUITECTURA
• Estructura
• Capas: El Patrón de arquitectura por capas es una de las
técnicas más comúnes que los arquitectos de software utilizan
para dividir sistemas de software complicados. 
PATRONES DE ARQUITECTURA
• Estructura
• Capas

https://www.youtube.com/watch?v=Dp0MqNFm870
PATRONES DE ARQUITECTURA
• Estructura
• Tuberías y Filtros: Consiste en ir transformando un flujo de datos en un proceso
comprendido por varias fases secuenciales, siendo la entrada de cada una la salida
de la anterior. Esta arquitectura es muy común en el desarrollo de programas para
el intérprete de comandos, ya que se pueden concatenar comandos fácilmente con
tuberías (pipe). También es una arquitectura muy natural en el paradigma de
programación funcional, ya que equivale a la composición de funciones
matemáticas. Ejemplo Acme Estudio
PATRONES DE ARQUITECTURA
• Estructura
• Pizarra: El patrón Blackboard es un modelo  arquitectónico
de software habitualmente utilizado en sistemas expertos,
multiagente y basados en el conocimiento.
https://www.youtube.com/watch?v=mpEh9cikinw
PATRONES DE ARQUITECTURA
• Distribuidos https://www.youtube.com/watch?v=chsR860gbsk
• Broker: El Broker es un patrón de arquitectura que se utiliza para
estructurar sistemas de software distribuidos con componentes
desacoplados que interactúan por invocaciones de servicios
remotos. Esto quiere decir que, si un componente necesita un
servicio de otro que está en otra ubicación que no conoce, el
broker se encarga de proporcionar la conexión.
PATRONES DE ARQUITECTURA
• Distribuidos
• Broker:
• Servidor: Implementan objetos que exponen su funcionalidad a través de
interfaces que consisten en operaciones y atributos. Se pueden clasificar
en dos tipos: Servidores que ofrecen servicios comunes a muchos
dominios de aplicación y Servidores específicos para dominios específicos.

• Cliente: Los clientes son aplicaciones que accesan los servicios de, al
menos, un servidor. La interacción entre clientes y servidores se basa en
un modelo dinámico, lo cual significa que los servidores también pueden
actuar como clientes. Los clientes no necesitan conocer la ubicación de
los servidores que accedan.

• Puentes: Son un componente opcional utilizado para esconder detalles de

implementación cuando dos brokers interoperan.
PATRONES DE ARQUITECTURA
• Distribuidos
• Broker:
• Broker: El Broker es el responsable de la comunicación entre los clientes y
servidores. Cuando un cliente necesita un servicio de un servidor, envía una
petición al broker, que a su vez se la envía al servidor. El servidor realiza la
funcionalidad correspondiente y envía la respuesta (o excepción) de vuelta al
broker, que se la devuelve al cliente.
• Proxies: Podemos distinguir dos tipos de proxies: los proxies del lado del
cliente y los proxies del lado del servidor:
• Proxies del cliente: Se ubican entre el cliente y el broker para esconder
detalles de implementación como el marshalling (empaquetado de
parámetros), la creación y eliminación de bloques de memoria y el
mecanismo de comunicación utilizado para enviar el mensaje.
• Proxies del servidor: Son análogos a los proxies del cliente, con el
añadido de que reciben las solicitudes, las desempaquetan, llaman al
servicio apropiado y hacen el marshalling de la respuesta o excepción.
PATRONES DE ARQUITECTURA
• Iterativos
• MVC: MVC es una propuesta de diseño de software utilizada para
implementar sistemas donde se requiere el uso de interfaces de usuario.
Surge de la necesidad de crear software más robusto con un ciclo de vida
más adecuado, donde se potencie la facilidad de mantenimiento,
reutilización del código y la separación de conceptos
• https://www.youtube.com/watch?v=S-FGoEBjTSA
PATRONES DE ARQUITECTURA
• Iterativos
• MVC
• El Modelo que contiene una representación
de los datos que maneja el sistema, su lógica
de negocio, y sus mecanismos de
persistencia.
• La Vista, o interfaz de usuario, que compone
la información que se envía al cliente y los
mecanismos interacción con éste.
• El Controlador, que actúa como
intermediario entre el Modelo y la Vista,
gestionando el flujo de información entre
ellos y las transformaciones para adaptar los
datos a las necesidades de cada uno.
PATRONES DE
ARQUITECTURA
• Iterativos
• PAC: es un patrón de arquitectura de software
para sistemas interactivos basada en una
jerarquía de agentes cooperantes similar
a Modelo Vista Controlador (MVC).
• Los agentes en PAC se organizan en una
estructura jerárquica para desarrollar
funcionalidades concretas del sistema global,
componiéndose de tres capas de acción que dan
nombre al patrón: Presentación, Abstracción y
Control.
PATRONES DE ARQUITECTURA
• Iterativos
• PAC
• Presentación: comportamiento perceptible
• Abstracción: semántica (Núcleo Funcional)
• Control:
• Vincula una abstracción con una presentación
• Controla el comportamiento de la abstracción y la presentación
• Mantiene un estado local
• Permite implementar diálogo multithread
• Administra las relaciones con otros agentes
PATRONES DE ARQUITECTURA
• Adaptables
• Microkernel
• El patrón de arquitectura Microkernel se aplica a sistemas de software que
deben estar habilitados para adaptarse a requerimientos cambiantes del
sistema. Separa un núcleo de funcionalidad mínima de la funcionalidad
extendida y de partes específicas al cliente. También sirve como un socket
para conectores en estas extensiones y coordinar su colaboración.
• Es complejo, sofisticado pero mas centrado en su que hacer para el SO, toda
acción pasa por el microkernel, lo cual hace a un SO mas seguro que uno SO
con arquitectura kernel monolítico, ya que si el que solicita hacer la acción no
posee los permisos necesarios el microkernel no lo deja hacer nada.
PATRONES DE ARQUITECTURA
• Adaptables
• Microkernel
• Esta arquitectura es ultilizada en el diseño de sistemas operativos y
otros kernels para sistemas específicos Unix, Windows, entre otros.
PATRONES DE ARQUITECTURA
• Adaptables
• Reflection
• Otorga la habilidad a un programa para inspeccionar su estructura
interna y poder modificar a esta misma en tiempo de ejecución y por
tanto su compartimiento.
• La estructura general de una arquitectura reflexiva es muy similar a un
sistema Layer. El meta nivel y el nivel base son dos capas cada una de
las cuales proporcionan su propia interfase.
PATRONES DE ARQUITECTURA
• Adaptables
• Reflection
• https://jarroba.com/reflection-en-java/
 El Método Attribute Driven Design
• Es un método creado por el Software Engineering
Institute para sistematizar la definición de la
arquitectura de software. Utiliza como elementos de
entrada los atributos de calidad, los requerimientos
funcionales y las decisiones de diseño definidos en la
etapa de requerimientos de un proyecto y
priorizados por los stakeholders.
• ADD sigue esencialmente el ciclo “Plan, Do, and
Check”:
• Plan: Los atributos de calidad y las restricciones
de diseño son consideradas para seleccionar qué
tipos de elementos se utilizan en la arquitectura.
• Do: Los elementos son instanciados para
satisfacer los atributos de calidad, así como los
requisitos funcionales.
• Check: El resultado es analizado para determinar
si los requisitos son satisfechos.
 El Método Attribute Driven Design
1. Confirmar que existe suficiente información de requerimientos

• En el primer paso, se confirma que hay suficiente información acerca de los requisitos. En esencia, se
asegura que los stakeholders ​han dado prioridad a los requisitos de acuerdo a los objetivos de negocio y a
la misión.

• El arquitecto, prioriza la lista de requerimientos para determinar en qué elementos del sistema se deben
concentrarse durante el diseño. Los requisitos que no han sido priorizadas deberán ser marcados y
devueltos a para su clasificación.

• Además, se debe determinar si existe suficiente información acerca de los atributos de calidad del
sistema. 

Estímulo fuente
Estímulo
Artefacto
Entorno
Respuesta
Respuesta de medida
El Método Attribute Driven Design
2. Seleccionar un elemento del sistema para descomponer
Se debe elegir qué elemento del sistema será el enfoque de diseño.
• Si es la primera vez que se llega este pasó, el elemento a elegir es el propio
sistema.
• De lo contrario, el sistema ha sido divido en dos o más elementos y los
requerimientos han sido asignados a estos elementos y se debe elegir uno de
estos elementos basándose en estas 4 áreas:

 Conocimiento actual de la arquitectura

 Riesgo y dificultad
 Criterio del negocio
 Criterio organizacional.
El Método Attribute Driven Design
• 3. Identificar los drivers arquitecturales candidatos desde el conjunto de
escenarios de calidad y requerimientos funcionales (Identificar los
Candidatos a Conductores Arquitecturales)
• Se ha elegido un elemento del sistema a descomponerse, y las partes
interesadas han dado prioridad a los requisitos que afecten a ese
elemento.
• Dado que las stakeholders clasificaron los requisitos inicialmente, la
segunda clasificación basada en el impacto arquitectura tiene el efecto de
ordenar parcialmente los requisitos en un grupos.
El Método Attribute Driven Design
Considerar los siguientes posibles valores para el primer elemento del par de prioridad:

• Alto: Si este escenario no es satisfecho, el sistema será considerado como no exitoso.

• Medio: Este escenario es altamente deseado para el sistema; pero si existe una razón muy
buena que justifique por qué no puede ser empleado, el sistema será considerado como
exitoso.
• Bajo: Este escenario no es imperativo, pero sería muy bueno tenerlo en el sistema.

Considera los siguientes posibles valores para el segundo elemento del par de importancia:

• Alto: El equipo de arquitectura no sabe cómo satisfacer el escenario.

• Medio: El equipo de arquitectura sabe cómo satisfacer el escenario, pero es muy
complicado de realizar.
• Bajo: El equipo de arquitectura sabe cómo satisfacer el escenario y lo considera fácil de
realizar.
El Método Attribute Driven Design
4. Elige un concepto de diseño que satisfaga los drivers arquitecturales
Se debe elegir los tipos principales de elementos que aparecerán en la arquitectura y los tipos
de relaciones entre ellos. Restricciones de diseño y los atributos de calidad se utilizan para
determinar los tipos de elementos, relaciones y sus interacciones.
Como arquitecto, debe seguir estos seis sub-pasos:
4.1. Identificar los problemas de diseño que se asocian con los drivers arquitectónicos
candidatos. Por ejemplo, para un requisito de atributo de calidad en cuanto a disponibilidad, las
preocupaciones podría ser la prevención de fallo, detección de fallos, y la recuperación de fallos.
El Método Attribute Driven Design
4. Elige un concepto de diseño que satisfaga los drivers arquitecturales
4.2. Para cada táctica arquitectónica identificar una lista de patrones subordinados.
 El conocimiento, habilidades y experiencia a cerca de los patrones arquitectónicos
previamente descritos.
 El conocimiento previo de tácticas arquitectónicas para lograr los atributos de
calidad.
 Si un driver arquitectónico es de mayor dificultad que un atributo de calidad, quizá se
le deban aplicar múltiples tácticas.
 Otras fuentes tal como libros, artículos, material de conferencias o motores de
búsqueda.
 Los patrones subordinados son aquellas opciones conocidas que pueden conseguir
que una táctica arquitectónica sea satisfecha
El Método Attribute Driven Design
4. Elige un concepto de diseño que satisfaga los drivers arquitecturales
4.3 Seleccionar patrones alternativos que sean más apropiados para satisfacer los
drivers arquitectónicos.
 Realizar esta selección de manera razonable. Decidir cuáles patrones son
apropiados.
 Crear una matriz con los nombres de los patrones en los títulos de las columnas
y los drivers arquitectónicos listados en el lado izquierdo. Usar la matriz para
analizar las ventajas y desventajas de aplicar cada patrón para cada driver
arquitectónico.
El Método Attribute Driven Design
4. Elige un concepto de diseño que satisfaga los drivers arquitecturales
4.4. Considerar la identificación de patrones que se tenga hasta el momento y
decidir cómo se relacionan con los otros.
La combinación de patrones seleccionados dará como resultado un nuevo
patrón.
a. Decidir cómo son relacionados los tipos de elementos desde varios
patrones.
b. Decidir qué tipos de elementos desde varios patrones son relacionados.
c. Tomar en cuenta la funcionalidad y uso como un indicador para cada
combinación de patrones.
d. Identificar nuevos tipos de elementos que resultan de la combinación de
patrones.
e. Revisar la lista de decisiones de diseño y confirmar que se han hecho todas
las decisiones relevantes.
El Método Attribute Driven Design
4. Elige un concepto de diseño que satisfaga los drivers arquitecturales

4.5. Describir los patrones seleccionados para iniciar la documentación de las

diferentes vistas arquitectónicas.

• No se necesita crear completamente las vistas arquitectónicas documentadas

hasta este punto. Documentar cualquier información que de seguro se
necesitará sobre la arquitectura. Idealmente se deben usar formatos de vistas
para capturar esta información.

• Una de las vistas que se puede crear es la vista funcional de los elementos y
las relaciones entre ellos, que hasta el momento se tienen identificados. Otra
vista que en este punto se puede capturar es un diagrama de secuencia.
El Método Attribute Driven Design
4. Elige un concepto de diseño que satisfaga los drivers arquitecturales
4.5. Describir los patrones seleccionados para iniciar la documentación de
las diferentes vistas arquitectónicas.
El Método Attribute Driven Design
• 4. Elige un concepto de diseño que satisfaga los drivers arquitecturales
4.6 Evaluar y resolver inconsistencias en el diseño conceptual
 En esta parte el arquitecto puede construir modelos para describir el
comportamiento del sistema.
 Las tareas iniciales de la evaluación de inconsistencias son:
a. Evaluar el diseño contra los drivers arquitectónicos. Si es necesario,
usar patrones, experimentos, simulaciones, análisis formal y métodos
de evaluación de arquitecturas.
b. Determinar si hay algún driver arquitectónico que no fue
considerado.
c. Evaluar patrones alternativos o aplicar tácticas adicionales, si el
diseño no satisface los drivers arquitectónicos.
d. Evaluar el diseño del elemento actual contra el diseño de otros
elementos en la arquitectura y resolver cualquier inconsistencia.
El Método Attribute Driven Design
5. Instanciar los elementos arquitectónicos y asignar responsabilidades
• En esta etapa se muestra como los elementos de diseño serán instanciados
para usar los drivers arquitectónicos funcionales.
• Los drivers funcionales son derivados de los requerimientos funcionales
abstractos (por ejemplo las características) o de requerimientos funcionales
concretos (casos de uso o lista de responsabilidades).
• Actividades a seguir en este paso:
• Asignar los requerimientos funcionales del elemento padre a los
elementos hijo.
• Definir responsabilidades de los elementos hijo.
• Descubrir el intercambio necesario de información entre elementos,
creando una relación productor/consumidor.
• Especificar interacciones entre elementos.
• Representar la arquitectura con vistas.
El Método Attribute Driven
Design
6. Definir interfaces para elementos instanciados.
• En este paso se definen los servicios y propiedades requeridas y otorgadas
por los elementos de software en el diseño.
• En este paso se realizan los siguientes tres subpasos:
• Utilizar los requerimientos funcionales que involucran a los elementos
instanciados en el paso 5.
• Observar cualquier operación que es producida por algún elemento y
consumida por otro. Considerar las interfaces desde la perspectiva de
diferentes vistas. Por ejemplo, una vista de componentes permitirá
analizar el flujo de información.
• Registrar lo encontrado en la documentación de interfaz para cada
elemento.
El Método Attribute Driven
Design
6. Definir interfaces para elementos instanciados.

• Algunas de las decisiones de diseño que se hacen en este paso involucrarán

varios puntos como los siguientes:
• Las interfaces externas para el sistema.
• Las interfaces entre particiones de alto nivel del sistema.
• Las interfaces entre aplicaciones dentro de particiones de alto niveldel
sistema.
• Las interfaces para la infraestructura.
El Método Attribute Driven Design
7. Verificar y refinar los requerimientos y aplicar las restricciones a los
elementos instanciados.
En este paso se realizan los siguiente subpasos:
• Verificar que todos los requerimientos funcionales, requerimientos de
atributos de calidad y decisiones de diseño asignadas al elemento padre se
han asignado a uno o más elementos hijo en la descomposición.
• Trasladar cualquier responsabilidad que fue asignada al elemento hijo dentro
de los requerimientos funcionales para los elementos individuales.
• Refinar los requerimientos de atributos de calidad para un elemento
individual hijo tanto como sea necesario. Los escenarios de calidad son
refinados.
• Si un escenario de calidad no es satisfecho con la actual descomposición, se
debe valorar la importancia de dicho escenario para reconsiderar su
descomposición.
• En este paso no se realizan decisiones de diseño.
El Método Attribute Driven
Design
• Repetir del paso 2 al 7 para los siguientes elementos del sistema en que se
desee descomponer.

• Una vez que se han completado los pasos del 1 al 7, se tiene una
descomposición de elementos padre en los elementos hijo. Cada elemento
hijo es una colección de responsabilidades, y tiene una descripción de
interfaz, requerimientos funcionales, requerimientos de atributos de calidad
y decisiones de diseño. Ahora se puede regresar al proceso de
descomposición en el paso 2 donde se selecciona al siguiente elemento a
descomponer.

• El proceso del método ADD termina cuando ya no existen elementos del

sistema a descomponer en el paso 2.