DSI 3K3 - Diseño Arquitectónico 2021

DSI – 3K3
Unidad 3: Diseño Arquitectónico
Diseño de Sistemas – Curso: 3K3

Docentes: Ing. Marcela F. Cattaneo
Ing. Germán Vélez
Gonzalo Martinez
Diseño Arquitectónico - Concepto de Arquitectura
“La Arquitectura del Software de un sistema de cómputo es la

estructura o las estructuras del sistema que incluyen los
componentes del software, las propiedades visibles externamente
de esos componentes y las relaciones entre ellos”
(L. Bass, P. Clements, R. Kazman, “Software Architecture
in Practice, Addison-Wesley, 2003)
DSI - 3K3 - Diseño Arquitectónico (Unidad 3) 2

Ing. Germán Vélez 1
DSI – 3K3
Diseño Arquitectónico - Concepto de Arquitectura
“La Arquitectura se define como la organización

fundamental de un sistema, incluyendo sus componentes,
las relaciones entre ellos y el entorno, y los principios que
gobiernan su diseño y evolución” (ANSI / IEEE Std 1471 – 2000)
Diseño Arquitectónico - Concepto

● Los sistemas grandes siempre se descomponen en subsistemas
que suministran algún conjunto relacionado de servicios.
● El proceso de diseño inicial para identificar estos subsistemas y

establecer un marco de trabajo para control y comunicación de
los subsistemas se llama Diseño Arquitectónico

DSI – 3K3

● El Diseño Arquitectónico se interesa por entender cómo debe
organizarse un sistema y cómo tiene que diseñarse la estructura
global de ese sistema.
● Es el enlace crucial entre el diseño y la ingeniería de

requerimientos.
te PC
Clien
te
Clien
Web
te
Clien )
Capa ación r We
b
sent ido
(Pre Serv
es
de lic acion
Capa Web de Ap
dor
icios Servi
Serv
de tos
ica de Da
ses
de lóg de Ba
Capa cio dor
Nego Servi
de
Capa ración
inist
Adm dato s
5
de
DSI - 3K3 - Diseño Arquitectónico (Unidad 3)

● Identifica los principales componentes estructurales en un
sistema y la relación entre ellos.
● Mapea los requerimientos esenciales de la fase de análisis hacia

una arquitectura tecnológica. Clien
te PC
te
Clien
Web
nte
Cl ie
Capa ntación) r We
b
se rvido
(Pre Se
iones
de licac
Capa Web de Ap
dor
icios Se rvi
Serv
de tos
gic a de Da
ses
de ló de Ba
Capa cio dor
Nego Se rvi
de
Capa n
ració
inist
Adm datos
de
● Es la asignación de los modelos de requerimientos esenciales

hacia una tecnología específica.

DSI – 3K3
Diseño Arquitectónico
Importancia de documentar la Arquitectura
● Permite la comunicación entre todas las partes (participantes)
interesadas en el desarrollo de un sistema de cómputo.
● Destaca las decisiones iniciales relacionadas con el diseño que
tendrán impacto en todo el trabajo de ingeniería de software
que sigue.
● Constituye un modelo relativamente pequeño e
intelectualmente comprensible de cómo está estructurado el
sistema y cómo trabajan juntos sus componentes.
Diseño Arquitectónico - Decisiones a tomar

1. ¿Existe alguna arquitectura de aplicación genérica que actúe como
plantilla?
2. ¿Cómo se distribuirá el sistema a través de núcleos o procesadores?
3. ¿Qué patrones o estilos arquitectónicos pueden usarse?
4. ¿Cuál es el enfoque fundamental usado para estructurar el sistema?
5. ¿Cómo los componentes estructurales en el sistema se separarán en
subcomponentes?
6. ¿Qué estrategia se usará para controlar la operación de los componentes
en el sistema?
7. Qué organización arquitectónica es mejor para cumplir con los RNF?
8. ¿Cómo se evaluará el diseño arquitectónico?
9. ¿Cómo se documentará la arquitectura del sistema?

DSI – 3K3
Diseño Arquitectónico - Proceso de diseño arquitectónico

● Los sistemas en el mismo dominio de aplicación tienen normalmente
arquitecturas similares, por ej.:
○ Los sistemas embebidos y sistemas diseñados para computadoras
personales tienen por lo general un solo procesador.
○ Los sistemas más grandes suelen ser distribuidos donde el software se

distribuye a través de varias computadoras.
● La arquitectura de un sistema de software puede basarse en un patrón o
estilo arquitectónico particular.
Estilo Arquitectónico
• Es una transformación que se impone al diseño de todo el sistema
• El objetivo es establecer una estructura para todos los componentes del sistema.
Patrón Arquitectónico
• El alcance del patrón es menos amplio y se centra en un aspecto de la arquitectura
más que en el total de ésta.
• Describe la manera en la que el software manejará ciertos aspectos de su
funcionalidad en el nivel de la infraestructura.
• Tiende a abocarse a aspectos específicos del comportamiento en el contexto de la
arquitectura

DSI – 3K3
Proceso de diseño arquitectónico
● Un patrón arquitectónico es una descripción de una organización del
sistema que ha tenido éxito.
● Un patrón arquitectónico cubre las preguntas 4 a 6 anteriores:
○ Debe elegirse la estructura más adecuada para satisfacer los
requerimientos.
○ Descomponer las unidades del sistema estructural separando los

componentes en subcomponentes.
Diseño Arquitectónico - Proceso de diseño arquitectónico

● En el proceso de modelado de control:
Se toman decisiones sobre Se desarrolla un modelo general

cómo se controla la de las relaciones de control sobre
ejecución de componentes las diferentes partes del sistema.
○ Modelos Centralizados:
Modelo llamada-retorno Modelo del administrador
○ Modelos dirigidos por eventos
Modelo de transmisión Modelo dirigido por interrupciones 12


DSI – 3K3
Proceso de diseño arquitectónico
● La salida del proceso de diseño arquitectónico consiste
en un modelo arquitectónico que describe la forma en
que se organiza el sistema como un conjunto de
componentes en comunicación.
● Describe cómo se estructura el sistema en subsistemas y
cómo cada subsistema se estructura en componentes.
Sistema Subsistema Componente
Diseño Arquitectónico - Subsistema

● Subsistema:
○ Es un sistema por sí mismo cuya operación no depende de
los servicios suministrados por otros subsistemas.
○ Los subsistemas se componen de módulos (componentes) y
tienen interfaces definidas que se utilizan para la
comunicación con otros subsistemas.

DSI – 3K3
Diseño Arquitectónico - Elección de la estructura

● La arquitectura del sistema afecta a:
○ La robustez
○ El desempeño
○ La mantenibilidad del sistema
por lo tanto
● El estilo particular y la estructura elegida para una
aplicación pueden depender de los requerimientos
no funcionales del sistema.
Elección de la estructura – Impacto de los RNF

Número reducido de subsistemas para localizar operaciones críticas
Desempeño (Componentes de grano grueso).
Estructura en capas, con alto nivel de validación de la seguridad.

Seguridad
La arquitectura se debe diseñar de tal forma que las operaciones

Protección relacionadas con la protección se localicen en un solo subsistema o
un número reducido de ellos.
La arquitectura debe diseñarse para incluir componentes redundantes

Disponibilidad para poder actualizar los componentes sin detener el sistema
Se debe diseñar utilizando componentes autocontenidos de grano fino que

Mantenibilidad puedan cambiarse con facilidad. Los productores de datos deben estar
separados de los consumidores.

DSI – 3K3
Diseño Arquitectónico - Elección de la estructura

● Puede existir conflicto potencial entre algunas de estas
arquitecturas
○ Por ej. el desempeño se mejora utilizando componentes de grano
grueso y el mantenimiento con componentes de grano fino
Si ambos son requerimientos importantes, se debe encontrar una
solución mediadora.
● No hay una solución perfecta, se busca la forma más apropiada

en base a los requerimientos y a las limitaciones que se nos dan.
Proceso de Diseño Arquitectónico

● Para guiar al arquitecto hacia la definición de la arquitectura de
la aplicación es útil seguir un proceso definido.
● La siguiente figura muestra un proceso de arquitectura iterativo
en tres pasos que puede ser usado para guiar las actividades
durante el diseño:
Determinar los
requerimientos
significativos para la
arquitectura Diseño de la
Arquitectura
Validación

DSI – 3K3

1. Definir requerimientos significativos para la arquitectura:
Involucra la creación de una sentencia o modelo de los
requerimientos que conducirán el diseño de la arquitectura.
2. Diseñar la arquitectura: Implica definir la estructura y
responsabilidades de los componentes que comprenden la
arquitectura.
3. Validación: Implica el “testing” (la prueba) de la arquitectura,
típicamente revisar el diseño contra los requerimientos
existentes y cualquier posible futuro requerimiento conocido.

Determinar requerimientos significativos
Antes que la solución arquitectónica sea diseñada es necesario tener una
buena idea de los requerimientos para la arquitectura de la aplicación, para
ello debemos:
1. Identificar requerimientos significativos.

2. Priorizar los requerimientos significativos para la arquitectura.

DSI – 3K3

● Identificar requerimientos significativos: las principales fuentes para los
requerimientos de arquitectura son:
○ El documento de requerimientos funcionales
○ Otros documentos que capturan diversas necesidades de los stakeholders
(atributos de calidad y requerimientos no funcionales)
Requerimientos
Determinar Requerimientos
Funcionales
Requerimientos de la
de la Arquitectura
Arquitectura
Requerimientos
de los
Stakeholders

● Priorizar los requerimientos de arquitectura:
○ Es muy raro que todos los requerimientos de arquitectura de una
aplicación sean iguales.
○ En la lista de requerimientos hay items que son de prioridad baja o
características del tipo “sería bueno tenerla pero no necesario”.
○ Es importante identificar explícitamente estos casos y clasificar los
requerimientos en función de su prioridad:
⁻ Alta
⁻ Media
⁻ Baja

DSI – 3K3

● Priorizar los requerimientos de arquitectura:
o Prioridad Alta: La aplicación debe soportar este requerimiento. Estos
requerimientos conducen el diseño de la arquitectura.
o Prioridad Media: Este requerimiento necesitará ser soportado en alguna etapa,
pero no necesariamente en las primeras iteraciones.
o Prioridad Baja: Es parte de la lista de deseos de los requerimientos. Las soluciones
que pueden componer estos requerimientos son deseadas pero no conducen el
diseño de la arquitectura.
● La priorización puede provocar conflictos entre los requerimientos.
Ejemplo
Proceso de Diseño Arquitectónico - Diseñar la Arquitectura
● Si bien todas las tareas para realizar la arquitectura son

importantes, lo que realmente importa es la calidad del diseño
de la arquitectura.
● Los buenos arquitectos son resultado de muchos años de

ingeniería de software y experiencia en diseño.

DSI – 3K3

● Entradas y salidas del diseño de la Arquitectura
Requerimientos
de la
Arquitectura
Elegir el Framework
(Patrones
Arquitectónicos)
Distribuir
Componentes
Vistas de la Documento
Arquitectura de
Arquitectura

● Elegir el Framework de la Arquitectura:
○ Ian Gorton, Ian Sommerville y diversos autores comentan que la
mayoría de las aplicaciones se basan en un número pequeño de bien
comprendidas y probadas arquitecturas.
○ Hay una razón para ello Funcionan
○ Un Patrón Arquitectónico se puede considerar como una descripción

abstracta utilizada de buena práctica que se ensayó y se puso a
prueba en diferentes sistemas y entornos.

DSI – 3K3

● Elegir el Framework de la Arquitectura  Patrones arquitectónicos
• En capas
Arquitecturas de Software
• De Repositorio
Patrones • Messaging • Tubería y Filtro
Arquitectónicos • Publishe-Suscribe • Lote-Secuencial
más utilizados • Broker
• Process Cordinator
• Cliente-Servidor
Patrones para • Master-Slave
Arquitecturas • Cliente-Servidor & N-Tier
distribuidas • Peer-to-Peer
• Map Reduce
Arquitecturas de • Genéricos
Dominio Específico • De referencia
• Cliente-Servidor
Arquitecturas de • Espejada
Hardware • Rack
• Farm (granja de servidores)
● Distribuir componentes - Pasos
1. Identificar los componentes principales de la aplicación y cómo se

conectan al marco general de la arquitectura.
2. Identificar la interfaz o los servicios que soporta cada componente.
3. Identificar las responsabilidades del componente.
4. Identificar las dependencias entre componentes.
5. Identificar particiones en la arquitectura que sean candidatas para su
distribución a través de servidores en una red.

DSI – 3K3

● Distribuir componentes - Pautas
o Minimizar dependencias entre componentes.

o Diseñar componentes que encapsulen un conjunto de responsabilidades
altamente cohesivo.
o Aislar dependencias de middleware y cualquier tecnología de
infraestructura en la menor cantidad de componentes.
o Usar la descomposición para estructurar los componentes
jerárquicamente.
o Minimizar las llamadas entre componentes (puede resultar costosos si
los componentes se distribuyen).
Arquitectura de Software - Vistas de la Arquitectura

● La Arquitectura de Software es un artefacto de diseño complejo
por eso, como la mayoría de los artefactos complejos, hay varias
formas de visualizar y comprender una arquitectura.
● El término “Vistas de la Arquitectura” fue introducido por

Philippe Krutchen en 1995 en su publicación: The “4+1” View
Model of Sotware Architecture (IEEE Sotware, Nov. 1995)

DSI – 3K3
Vistas de la Arquitectura
Vistas 4 + 1 - Philippe Krutchen
● La publicación de Krutchen presenta una forma de describir y
comprender la arquitectura basada en las siguientes cuatro
vistas:
o Vista Lógica
o Vista de Procesos
o Vista Física
o Vista de Desarrollo
o Vista Lógica: Describe los elementos significativos arquitectónicamente y
las relaciones entre ellos. Esencialmente captura la estructura de la
aplicación utilizando diagramas de clases o equivalentes.
o Vista de Procesos: Se enfoca en describir la concurrencia y elementos de

comunicación de una arquitectura. El interés principal en esta vista es
decribir los componentes “multi-threaded (multi-hilos)” o replicados y los
mecanismos de comunicación sincrónos y asíncronos utilizados.

DSI – 3K3
o Vista Física (Implementación): Describe cómo se mapean los principales
procesos y componentes en los nodos de hardware. Podría mostrar, por
ej., cómo los servidores Web y de Base de Datos para una aplicación son
distribuidos a través de un número de equipos servidores.
o Vista de Desarrollo: Captura la organización interna de los componentes

de software, típicamente cómo están contenidos en un entorno de
desarrollo o una herramienta de gestión de la configuración. Por ej. la
descripción de un paquete anidado y una jerarquía de clases para una
aplicación Java representaría la vista de Desarrollo de una arquitectura.
● Estas cuatro vistas están unidas por los casos de uso
arquitectónicamente significativos.
● Estos casos de uso básicamente capturan los requerimientos
para la arquitectura, de ahí que estén relacionados con más de
una vista particular.

DSI – 3K3
● Utilizaremos algunos de los diagramas provistos por UML 2.0 para
representar las vistas arquitectónicas más significativas.
○ Diagramas de Casos de Uso
○ Diagramas de Estructura Compuesta
○ Diagrama de Despliegue
○ Se pueden utilizar también diagramas de clases pero sin entrar en detalles
innecesarios a nivel del diseño arquitectónico y diagramas de secuencia para
modelar el comportamiento de los componentes en una arquitectura.
● Vistas de la arquitectura:
○ Vista Arquitectónica de la Funcionalidad: Casos de Uso significativos
para la Arquitectura
Diagrama de Casos de Uso
○ Vista Arquitectónica del Diseño: Subsistemas e Interfaces

Diagrama de Componentes
○ Vista Arquitectónica del Despliegue:

■ Nodos y Componentes principales
■ Niveles de Hardware
Diagrama de Despliegue
Ejemplo 36

DSI – 3K3
Vistas de la Arquitectura - Siemens’ 4 View
Fuente: Hofmeister, Nord, and Soni, “Applied Software Architecture”. Addison-Wesley, Boston, 2000.

● El método Siemens Four-Views (S4V) (Hofmeister et al, 1999;.. Soni et al,
1995), desarrollado en Siemens Corporate Research, considera cuatro
vistas de la arquitectura:
○ Vista conceptual
○ Vista de ejecución
○ Vista de módulo
○ Vista de código
● Las 4 vistas de la arquitectura, separan diferentes intereses de ingeniería

lo que reduce la complejidad de la tarea de diseño de la arquitectura.

DSI – 3K3

Vista Conceptual
● En la vista conceptual, la funcionalidad del producto se asigna a un
conjunto de componentes y conectores interconectados. Los
componentes se ejecutan de forma independiente de sus pares, al igual
que los conectores.
● Las preocupaciones principales de ingeniería en esta vista abordan cómo
el sistema cumple con los requisitos. Los requisitos funcionales son una
preocupación central, que incluye tanto las necesidades actuales como
mejoras futuras.

Vista de Módulo
● Para la vista de módulo, los módulos se organizan en dos estructuras
ortogonales: descomposición y capas.
● La estructura de descomposición capta cómo el sistema se descompone
lógicamente en subsistemas y módulos.
● Un módulo puede ser asignado a una capa, que luego limita sus
dependencias con otros módulos.

DSI – 3K3

Vista de Módulo
● Las principales preocupaciones en esta vista son:
○ Minimizar las dependencias entre módulos
○ Maximizar la reutilización de módulos, y las pruebas de apoyo.
○ Otra preocupación clave es minimizar el impacto de futuros cambios en el

software, la plataforma de software, hardware y software de dominio específico y
estándares.

Vista de Ejecución
● La vista arquitectónica de Ejecución describe la estructura del sistema en términos de
elementos de la plataforma de ejecución (por ejemplo, tareas, procesos del sistema
operativo, hilos de control).
● La tarea de esta vista es asignar la funcionalidad del sistema a estos elementos de la
plataforma, determinar cómo las instancias resultantes en tiempo de ejecución se
comunican, y cómo se asignan los recursos físicos a ellas.
● Otras consideraciones son la ubicación, la migración y replicación de estas instancias
en tiempo de ejecución. Propiedades de ejecución del sistema, el rendimiento, la
seguridad y la replicación se deben abordar aquí.

DSI – 3K3

Vista de Código
● La última vista, la vista arquitectónica de Código, se ocupa de la organización de los
artefactos de software.
● Los componentes fuente (“source”) implementan los elementos de la vista de módulo
y los componentes de despliegue instancian entidades de ejecución de la vista de la
Ejecución.
● Las preocupaciones de ingeniería de esta vista consisten en realizar versiones y
lanzamientos de productos, minimizar el esfuerzo de actualizaciones de productos,
minimizar el tiempo de construcción y dar soporte a la integración y pruebas.

Documentar la Arquitectura de Software
● Razones para documentar la arquitectura de software:
○ Otras personas pueden comprender y evaluar el diseño. Esto incluye
cualquiera de los stakeholders, pero más comúnmente otros miembros del
equipo de diseño.
○ Podemos comprender el diseño cuando retornamos a él después de un
período de tiempo.
○ Otras personas del equipo de proyecto y de la organización de desarrollo
pueden aprender sobre la arquitectura asimilando los conceptos detrás del
diseño.
○ Podemos hacer análisis sobre el diseño, tal vez para valorar su probable
rendimiento

DSI – 3K3

● Por otro lado documentar las arquitecturas, puede ser
problemático porque :
○ No hay una forma de documentación estándar universalmente aceptada.
○ Una arquitectura puede ser compleja y documentarla en una manera
comprensible es tiempo consumido y no de manera trivial.
○ Una arquitectura tiene varias vistas posibles. Documentar todas las
potencialmente útiles es tiempo consumido y costoso.
○ Un diseño de la arquitectura frecuentemente evoluciona a medida que el
sistema se desarrolla incrementalmente y se gana más conocimiento sobre
el dominio de problema.

○ Plantilla para Documentación de la Arquitectura:
■ Nombre del proyecto: XXX
■ 1 Contexto del Proyecto
■ 2 Requerimientos de la Arquitectura
2.1 Descripción general de los objetivos clave.
2.2 Casos de Uso significativos para la arquitectura.
2.3 Requerimientos de Arquitectura de los Stakeholders
2.4 Restricciones
2.5 Requerimientos No Funcionales
2.6 Riesgos

DSI – 3K3

● Plantilla para Documentación de la Arquitectura (continuación):
○ 3 Solución
3.1 Patrones Arquitectónicos relevantes.
3.2 Descripción general de la Arquitectura
3.3 Vistas Estructurales
3.4 Vistas de Comportamiento
3.5 Beneficios de Implementación
○ 4 Análisis de la Arquitectura
4.1 Análisis de escenarios
4.2 Riesgos
Validar la Arquitectura
● Durante el proceso de arquitectura, el objetivo de la fase de
validación es aumentar la confianza del equipo de diseño de
que la arquitectura es apta para su propósito.
● Validar un diseño de arquitectura plantea algunos retos difíciles,

ya que el diseño propuesto es solo eso: un diseño. No puede
ser ejecutado ni probado para asegurarse de que cumple con
sus requisitos.

DSI – 3K3
Validar la Arquitectura
● Hay dos técnicas principales que se pueden aplicar:
○ Prueba manual de la arquitectura usando escenarios de prueba.
○ Construcción de un prototipo simple de la aplicación deseada, de modo
que su capacidad para satisfacer los requisitos pueda evaluarse con
más detalle a través de pruebas de prototipos.
● El objetivo es identificar posibles fallas y debilidades en el diseño para que

puedan mejorarse antes de que comience la implementación.
Patrones arquitectónicos
Arquitectura en Capas (Layered style)
● Las propiedades clave de este patrón son:
 Separación de intereses: La funcionalidad del sistema está
organizada en capas separadas y cada una se apoya sólo en los
servicios ofrecidos por la capa ubicada debajo de ella.
 Soporta desarrollo incremental: A medida que se desarrolla una

capa, las funcionalidades suministradas por la misma quedan a
disposición.
Capa 3
Capa 2
Capa 1
Capa 0

DSI – 3K3

 Cambiable y portátil: En tanto su interfaz no varíe, una capa puede
sustituirse por otra equivalente. Si se cambia la interfaz o se agregan
nuevas funcionalidades a una capa, sólo se ven afectadas las capas
adyacentes.
 Aplica a elementos de código, es parte del tipo de vista de

Módulo (*)
(*) Relación:
Vistas de la
Arquitectura de
Siemens

● Descripción del patrón: Organiza el sistema en capas con
funcionalidad relacionada con cada capa. Una capa da servicios a la
capa de encima (capas de nivel inferior servicios núcleo).
● Cuándo se utiliza?
○ Al construirse nuevas facilidades sobre sistemas existentes.
○ Cuando el desarrollo se distribuye a través de distintos equipos
de trabajo (cada uno responsable de una capa de funcionalidad).
○ Cuando existe un requerimiento de seguridad multinivel.

DSI – 3K3

● Esquemas genéricos
Interfaz de Usuario
Capa de Presentación
Gestión de Interfaz de Usuario

Autenticación y autorización
Capa de Lógica de Negocio
Lógica de Negocio/
Funcionalidad de la aplicación
Capa de Administración
de datos
Soporte del sistema
(SO, base de datos, etc)

● Ejemplos

DSI – 3K3

● Ventajas:
○ Modificabilidad: Permite la sustitución de capas completas en
tanto se conserve la interfaz.
○ Permite aumentar la confiabilidad incluyendo facilidades
redundantes en las capas
○ Portabilidad
○ Reusabilidad
● Desventajas:
○ Difícil hacer separación limpia entre capas.
○ El rendimiento se afecta por los múltiples niveles de
interpretación.

● Ejemplos: Sistema de Biblioteca LIBSYS
Interfaz de Navegador Web
Conexión LIBSYS Gestor formatos y consulta Gestor Impresión
Recuperación de
Búsqueda distribuida Documentos Gestor de derechos Contabilidad
Índice de Biblioteca
Bases de datos de Biblioteca

DB1 DB2 DB3 DB4 DB5
(Permite el acceso electrónico controlado a material con derechos de autor de un

conjunto de bibliotecas universitarias)

DSI – 3K3

● Ejemplo Sistema: Gestión de Tasa Comercio e Industria Municipal
Patrones arquitectónicos - Patrón Messaging

● Esquema
Queue
Client Server
Cliente Cola Servidor

DSI – 3K3

 Comunicaciones asincrónicas: Los clientes envían las peticiones a la
cola, donde los mensajes son almacenados hasta que una aplicación
los remueve. Después que el cliente ha escrito un mensaje en la cola,
continúa trabajando sin esperar que el mensaje sea removido.
 Calidad del Servicio (QoS) Configurable: La cola puede ser
configurada para entrega de alta velocidad (no-confiable) o baja
velocidad (confiable). Las operaciones de la cola se pueden coordinar
con las transacciones de la base de datos.
 Libre de Acoplamiento: No hay “binding” (ligadura/atadura) directo
entre clientes y servidores.

Atributo
de calidad Características
Las colas físicas con el mismo nombre lógico se pueden replicar a través
de diferentes instancias de servidores “messaging”. Cuando una falla,
Disponibilidad los clients envían los mensajes a la réplica de la cola.
Manejo de Si un cliente se está comunicando con una cola que falla, puede
Fallas encontrar una réplica de la cola y colocar el mensaje allí.
“Messaging” es inherentemente libre de acoplamientos y promueve la
alta cambiabilidad ya que clientes y servidores no están directamente
sujetos a través de una interfaz. Cambiar el formato de los mensajes
Cambiabilidad enviados por los clientes pueden causar cambios en las
implementaciones de los servidores. Los formatos de mensajes
autodefinidos pueden ayudar a reducir esta dependencia.

DSI – 3K3

Atributo
La tecnología de cola de mensajes puede entregar miles de mensajes

por segundo. Los mensajes no-confiables son más rápidos que los
Rendimiento
confiables, con la diferencia dependiente de la calidad de tecnología de
mensajería utilizada.
Las colas pueden ser alojadas en los puntos finales de comunicación o
ser replicados a través de clusters de servidores de mensajes alojados
Escalabilidad en un único o en múltiples equipos servidores. Esto lo hace una solución
altamente escalable.

● Ejemplo patrón Messaging
Sistema de Tasas Municipal
Servicio de
Componente
Cola Correo
Notificador
electrónico
Intimación
Escribir correo
electrónico para Consumir correo
contribuyente electrónico
Se debe proceder a notificar a los contribuyentes cuando se les ha generado

una intimación por deuda.

DSI – 3K3
Patrones arquitectónicos: Publishe - Suscribe

● Esquema
Publisher Topic Suscriber
Publicante Tópico Suscriptor
Componentes independientes publican eventos y se suscriben a ellos

 Mensajería Muchos-a-Muchos: Los mensajes publicados son enviados a

todos los suscriptores que se han registrado en un tópico. Muchos
publicantes pueden publicar sobre el mismo tópico y muchos suscriptores
pueden “escuchar” sobre el mismo tópico.
 Calidad del Servicio (QoS) Configurable: Además de los mensajes no-

confiables y confiables, el mecanismo de comunicación puede ser:
o Punto-a-punto: Se envía un mensaje diferente para cada suscriptor en un

tópico.
o Broadcast/multicast: Se envía un mismo mensaje que cada suscriptor

recibe.

DSI – 3K3

 Libre de Acoplamiento: Al igual que “messaging”, no hay ligaduras

(“binding”) entre publicantes y suscriptores. Los publicantes no conocen quién
recibe sus mensajes, y los suscriptores no conocen qué publicante envió el
mensaje.
 Aplica a elementos de ejecución, es parte del tipo de vista de Ejecución (*)
(*) Relación:
Vistas de la
Arquitectura de
Siemens

Atributo
Los tópicos con el mismo nombre lógico pueden ser replicados en
Disponibilidad diferentes instancias de servidores administrados como un cluster.
Cuando uno falla, los publicantes envían los mensajes a las réplicas.
Si un publicante se está comunicando con un tópico alojado en un

Manejo de
servidor que falla, puede encontrar un servidor réplica y enviar el
Fallas
mensaje allí.
Publish-subscribe es inherentemente libre de acoplamiento promueve
la alta cambiabilidad. Nuevos publicantes y suscriptores pueden
agregarse al sistema sin cambiar la arquitectura o la configuración.
Cambiabilidad
Cambios en el formato de los mensajes publicados pueden causar
cambios en las implementaciones de los suscriptores.

DSI – 3K3

Atributo
Publish-subscribe puede entregar miles de mensajes por segundo, con

mensajes no-confiables más rápido que con los confiables. Si el broker
Rendimiento
publish-subscribe soporta multicast/broadcast, entregará múltiples
mensajes en un tiempo más uniforme a cada suscriptor.
Los tópicos pueden estar replicados a través de clusters de servers
alojados en un único o en múltiples equipos servidores. Los clusters de
Escalabilidad servidores pueden escalarse para proveer un muy alto volumen de
entrega de mensajes. También las soluciones multicast/ broadcast se
escalan mejor que sus contrapartes punto-a-punto.

● Ejemplo patrón Publish – Suscribe
Sistema de notificaciones de tarjeta de débito
Consultas
de saldo Servicio de notificaciones
por correo electrónico
Gestión de Tópico
Compras
Servicio de notificaciones
por celular
Gestión de Generación de avisos
Novedades
Publicantes Tópico Suscriptores

DSI – 3K3
Patrones arquitectónicos - Broker

● Esquema:
inPort 1 OutPort 1
Sender-1 Receiver-1
Broker
Sender-2 inPort 2
Receiver-2
OutPort 2
Remitente Broker Receptor

 Arquitectura Hub-and-spoke (Eje-rayo): El broker actúa como un hub de

mensajería (eje) y los Remitentes y Receptores se conectan como rayos (como
en una rueda de bicicleta) . Las conexiones con el broker son a través de
puertos que están asociados con un formato de mensaje específico.
 Realiza ruteo de mensaje: El broker embebe la lógica de procesamiento

para entregar un mensaje recibido en un puerto de entrada en un puerto de
salida. El camino de entrega puede estar en el código o depender de valores
en el mensaje de entrada.
 Realiza transformación del mensaje: La lógica del broker transforma el tipo

de mensaje fuente recibido en el puerto de entrada al tipo de mensaje de
destino requerido en el puerto de salida.

DSI – 3K3

Atributo
Para construir arquitecturas con alta disponiblidad, los brokers deber
Disponibilidad estar replicados. Esto es típicamente soportado utilizando mecanismos
similares al cluster de servidores del “messaging” y “publish-subscribe”
Como los brokers tienen puertos de entrada de tipos definidos, validan

Manejo de y descartan cualquier mensaje enviado en un formato erróneo. Con
Fallas Brokers replicados, los remitentes pueden sobrellevar una falla
dirigiéndose a una réplica del broker en falla.
Los Brokers separan la lógica de transformación y de ruteo del mensaje

desde los remitentes a los receptores. Esto mejora la cambiabilidad ya
Cambiabilidad que cambios en la lógica de ruteo o transformación pueden hacerse sin
afectar a los remitentes o receptores.

Atributo
Los Brokers pueden potencialmente convertirse en cuellos de botella

especialmente si deben manejar grandes volúmenes de mensajes y
Rendimiento
ejecutar lógica de transformaciones complejas. Su rendimiento será
típicamente más bajo que un “messaging” simple con entrega confiable.
Reunir en clusters instancias de Brokers hace posible construir sistemas
Escalabilidad escalables para manejar grandes cargas de peticiones.
Los Brokers se adaptan a aplicaciones en las cuales los componentes intercambian

mensajes que requieren una extensa transformación entre los formatos fuente y
destino.

DSI – 3K3

● Ejemplo patrón Broker:
Sistema de Información Radiológica (RIS)
Puertos Puertos
Sistema de de entrada de salida Generador
reconocimiento
de reportes
interactivo de voz
Almacenamiento
Captura de
RIS
(protocolo
formato texto
imágenes HL7)
Almacenamiento
de imágenes
BD Pacientes (distintos formatos)
Y consultas
Almacenamiento
de sonido
(distintos formatos)
Remitentes Broker Receptores
Patrones arquitectónicos - Process Cordinator

● Esquema
Start process Process result

request Process
Cordinator
Paso 4
Paso 1 Paso 2 Paso 3
Server-1 Server-2 Server-3 Server-4

DSI – 3K3

 Encapsulamiento de Proceso: El coordinador de proceso encapsula la secuencia de
pasos necesaria para completar un proceso de negocio. La secuencia puede ser
arbitrariamente compleja. El coordinador es un único punto de definición para el proceso
de negocio, haciendo fácil su comprensión y modificación. Recibe la petición de inicio del
proceso, llama a los servidores en el orden definido por el proceso y emite los resultados.
 Libre de Acoplamiento: Los componentes servidores son inconcientes de su rol en todo

el proceso de negocio y del orden de los pasos en el proceso. Los servidores simplemente
definen un conjunto de servicios que deben realizar y el coordinador los llama como una
parte necesaria del proceso de negocio.
 Comunicaciones flexibles: Las comunicaciones entre el coordinador y los servidores

pueden ser sincrónicas o asincrónicas. Para comunicaciones sincrónicas el coordinador
espera hasta que los servidores responden. Para las comunicaciones asincrónicas el
coordinador provee un mecanismo de “callback” o “queue/topic” y espera hasta que el
servidor responda utilizando el mecanismo definido.

Atributo
El coordinador es un único punto de falla. De ahí que necesite ser

Disponibilidad replicado para crear una solución con alta disponiblidad.
El manejo de fallas es complejo, puede ocurrir en cualquier etapa de la

coordinación del proceso de negocio. Una falla en los últimos pasos en
Manejo de el proceso puede requerir que los primeros pasos sean deshechos
Fallas usando transacciones de compensación. El manejo de fallas necesita un
diseño cuidadoso para asegurar que los datos mantenidos en los
servidores sigan siendo consistentes.
La cambiabilidad del proceso se favorece porque la definición del
proceso está encapsulada en el Coordinador de Procesos. Los
Cambiabilidad servidores pueden cambiar su implementación sin afectar al
coordinador o a los otros servidores mientras que la definición del
servicio externamente no cambie.

DSI – 3K3

Atributo
Para proporcionar alto rendimiento el coordinador debe poder manejar

múltiples peticiones concurrentes y administrar el estado de cada una a
Rendimiento medida que progresan a través del proceso. También, el rendimiento de
cualquier proceso está limitado por los pasos más lentos (denominados
los servidores lentos en el proceso) .
Escalabilidad El coordinador puede ser replicado para escalar la aplicación.
El patrón Coordinador de Proceso es comúnmente utilizado para implementar

procesos de negocio complejos que deben resolver peticiones de varios
componentes de servidores diferentes

● Ejemplo patrón Process Cordinator
Start process
Sistema Bancario Process result
request
Gestión de
Préstamos
Paso 4
Paso 1 Paso 2 Paso 3
Server Server Server

Evaluación Server
Solicitudes Riesgo
Financiera Liquidaciones
crediticio

DSI – 3K3
Patrones arquitectónicos -
Arquitectura de Repositorio (Modelo Centrado)
● La mayoría de los sistemas con grandes cantidades de
datos se organizan sobre una base de datos o repositorio
compartido.
● Es un modelo adecuado para aplicaciones en que un
componente genere datos y otro los use.
Componente Componente
de software de software
Almacén de datos
Componente Componente
de software de software
Patrones arquitectónicos -
● También se lo conoce como “Modelo Centrado” (model-
centered)
● Describe una arquitectura en la cual componentes
independientes interactúan con un modelo central, en
lugar de interactuar con cada uno de los otros.
● Aplica a elementos de ejecución, es parte del tipo de vista de Ejecución (*)
(*) Relación:
Vistas de la
Arquitectura de
Siemens

DSI – 3K3

● Descripción del patrón: Todos los datos del sistema se gestionan en un
repositorio central, accesible a todos los componentes del sistema.
○ Cuando el sistema maneja grandes volúmenes de información
que deben almacenarse durante mucho tiempo.
○ En sistemas dirigidos por datos, en los que la inclusión de datos
en el repositorio active una acción o herramienta.
○ Ejemplos: Sistemas de comando y control, sistemas de
información administrativa, sistemas CAD, etc.

● Ventajas:
○ Los componentes pueden ser independientes.
○ Los cambios hechos por un componente se pueden propagar a los
demás.
○ Se puede gestionar de manera consistente la totalidad de los datos.
● Desventajas:
○ El repositorio es un punto de falla único; los problemas en el repositorio
afectan a todo el sistema.
○ Puede haber ineficiencias al organizar toda la comunicación a través del
repositorio.
○ Puede ser difícil distribuir el repositorio en varias computadoras.

DSI – 3K3

● Ejemplo: Arquitectura para un IDE (Entorno de Desarrollo Integrado)
Editores Generadores
Editor
UML de código
Java
Traductor Repositorio Editor de

de Diseño del proyecto Programa
Analizador Generador
de Diseño de Reportes
Arquitectura MVC(Modelo-Vista-Controlador)
● Descripción: Separa presentación e interacción de los datos del
sistema. El sistema se estructura en tres componentes lógicos que
interactúan entre sí:
○ Modelo: Maneja los datos del sistema y las operaciones asociadas a esos
datos.
○ Vista: Define y gestiona cómo se presentan los datos al usuario.
○ Controlador: Dirige la interacción del usuario y pasa esas interacciones a

Vista y Modelo.

DSI – 3K3
○ Se usa cuando existen múltiples formas de ver e interactuar con los datos.
○ Cuando se desconocen los requerimientos futuros para la interacción y

presentación.
● Esquema genérico Es un ejemplo de arquitectura de
modelo centrado (repositorio):
• Un componente “modelo”
• Un componente que recibe notificaciones
de actualizaciones del modelo: “vista”
• Un componente que actualiza el modelo:
“controlador”
• Un componente que hace ambas cosas:
DSI - 3K3 - Diseño Arquitectónico (Unidad 3) “vista/controlador” 85
● Ventajas:
○ Permite que los datos cambien independiente-mente de su
representación y viceversa.
○ Soporta en diferentes formas la presentación de los mismos
datos.
○ Los cambios en una representación se muestran en todos ellos.
● Desventajas:
○ Puede implicar código adicional y complejidad en el código
cuando el modelo de datos y las interacciones son simples.

DSI – 3K3
Arquitectura de tubería y filtro (pipe and filter)
● Descripción del patrón: El procesamiento de datos en un sistema se
organiza de forma que cada componente de procesamiento (filtro) sea
discreto y realice un tipo de transformación de datos. Los datos fluyen
(como en una tubería) de un componente a otro para su procesamiento.
○ En aplicaciones de procesamiento de datos (tanto basadas en lotes –
batch- como en transacciones) donde las entradas se procesan en
etapas separadas para generar salidas relacionadas.
(*) Relación:
Vistas de la
Arquitectura de
DSI - 3K3 - Diseño Arquitectónico (Unidad 3) Siemens 87

● Esquema:
● La arquitectura “tubería y filtro” consta de cuatro elementos: tuberías, filtros,

puertos de lectura y puertos de escritura.
● Un filtro lee desde uno o más puertos de entrada, realiza algún procesamiento
y escribe la salida en uno o más puertos de salida.

DSI – 3K3
● Es un modelo de la organización en tiempo de operación de un sistema.

● Las transformaciones funcionales procesan sus entradas y producen salidas.
● Los datos fluyen de uno a otro y se transforman conforme se desplazan a
través de la secuencia.
● Cada paso de procesamiento se implementa como un transformador
● Las transformaciones pueden ejecutarse secuencialmente o en forma paralela.
● El nombre de “tubería y filtro” proviene del sistema Unix original.
● Los sistemas interactivos son difíciles de escribir con el modelo tubería y filtro.

● Ventajas:
○ Fácil de entender y soporta reutilización de transformación
○ El estilo de flujo de trabajo coincide con la estructura de muchos procesos
de negocio.
○ La evolución al agregar transformaciones es directa.
○ Puede implementarse como un sistema secuencial o como uno
concurrente.
● Desventajas:
○ El formato para la transferencia de datos debe acordarse entre las
transformaciones que se comunican.
○ Esto aumenta la carga del sistema y puede significar que sea imposible
reutilizar transformaciones funcionales que usen estructuras de datos
incompatibles. 90

DSI – 3K3
Arquitectura Lote-Secuencial (Batch-Sequential)
● Descripción del patrón:
○ En la arquitectura batch-sequential los datos fluyen de una etapa a otra
y se procesan incrementalmente.
○ A diferencia de la arquitectura “tubería y filtro” cada etapa completa la
totalidad de su procesamiento antes de escribir su salida.
○ Los datos pueden fluir entre etapas en una “corriente” pero más a
menudo son escritos en un archivo en disco.
○ Los componentes de procesamiento son llamados con diferentes
nombres: etapas o pasos. No hay un nombre estándar para los
conectores en entre etapas. Una tarea simple que fluye a través de un
sistema batch-sequential es llamada batch (lote) o job (trabajo).

● Esquema:
● Cada etapa lee su entrada completa y escribe su salida completa de una

vez, no incrementalmente. En consecuencia, cada etapa se ejecuta en
secuencia.
(*) Relación:
Vistas de la
Arquitectura de

DSI – 3K3

● Ventajas:
○ Modificabilidad, dado que cada etapa es independiente de las otras.
○ Son conceptualmente más simples ya que sólo una etapa se está
ejecutando en un momento dado.
○ Pueden tener un mayor rendimiento.
● Desventajas:
○ La salida final de un sistema batch-sequential estará ausente o
plenamente disponible lo cual tendrá un impacto en la usabilidad de un
sistema.
○ Ofrece menos oportunidades para la concurrencia dado que las etapas no
pueden ejecutarse en paralelo a menos que múltiples trabajos (jobs) estén
fluyendo a través del sistema.
Arquitecturas Distribuidas
● Un sistema distribuido es “..una colección de computadoras
independientes que aparecen al usuario como un solo sistema
coherente..” (Tanenbaun y Van Steen -2007)
● Los componentes de un sistema distribuido pueden estar en ejecución en

computadoras con administración independiente y éstas se comunican a
través de una red.

DSI – 3K3
Arquitectura Cliente-Servidor
● Propiedades clave del patrón
En una arquitectura Cliente-Servidor una aplicación se modela como:

○ Un conjunto de servicios que proporcionan los servidores (por ej. un
servidor de impresión, servidores de archivos, etc).
○ Un conjunto de clientes que solicitan los servicios que ofrecen los
servidores.
○ Una red que permite a los clientes acceder a esos servicios. Los clientes
deben saber que los servidores están disponibles pero no conocen la
existencia de otros clientes.
● Propiedades clave del patrón:
○ Los clientes acceden a servicios que proporciona un servidor a través de
llamadas a procedimiento remoto usando un protocolo de solicitud-
respuesta (como el protocolo “http” utilizado en WWW)
○ Un modelo de sistema distribuido muestra cómo los datos y el

procesamiento se distribuyen a lo largo de varios procesadores.
○ Aplica a elementos de ejecución, es parte del tipo de vista de Ejecución (*)
(*) Relación:
Vistas de la
Arquitectura de

DSI – 3K3
● Esquema:
Caso de un servidor conectado con dos clientes. Los clientes pueden iniciar la
comunicación pero no el servidor. El servidor no conoce la identidad de los
clientes hasta que se conectan.
● Esquema:
c3 c4
c2 c12
S1 S4 c11
c1
c10
S3
S2
c5
c9
c6 c7 c8
Proceso Cliente c
Proceso Servidor S

DSI – 3K3
● Arquitectura cliente-servidor y su distribución en el hardware:
c1 s1,s2 c2 c3,c4
cc1 cs1 cc2 cc3
Red
cc4 cs2 cc6

cc5
c5,c6,c7 s3,s4 c8,c9 c10,c11,c12
Computadora Cliente cc Proceso Cliente: c
Computadora Servidor cs Proceso Servidor: s
● Descripción: En una arquitectura cliente-servidor la funcionalidad del
sistema se organiza en servicios, y cada servicio entrega un servicio
independiente. Los clientes son usuarios de dichos servicios y para
utilizarlos ingresan a los servidores.
● Cuando se utiliza:
○ Cuando desde varias ubicaciones se tiene que ingresasr a los
datos en una base de datos compartida.
○ Cuando la carga de un sistema es variable, ya que los servidores
se pueden replicar.

DSI – 3K3
● Ventajas:
○ La principal ventaja es que los servidores se pueden distribuir a
través de una red.
○ La funcionalidad general está disponible para todos los clientes,
asique no necesita implementarse en todos los servicios.
○ Es fácil agregar un nuevo servidor e integrarlo o actualizar los
servidores sin afectar las otras partes del sistema.
○ Aprovecha la disponibilidad de redes cada vez más veloces.
● Desventajas:
○ Cada servicio es un solo punto de falla susceptible a ataques de
rechazo de servicio o fallas del servidor.
○ El rendimiento es impredecible porque depende de la red así
como del sistema.
○ No existe un modelo compartido de datos, lo que complica las
tareas de administración de datos, respaldo y recuperación.

DSI – 3K3
● Ejemplo:
Cliente 1 Cliente 2 Cliente 3 Cliente 4
Internet
Servidor de Servidor Servidor

Catalogo de Video de Imágenes Servidor Web
Catálogo de Almacén de Almacén de Información de

Biblioteca películas Fotos películas y fotos
Sistema multiusuario basado en la Web para una filmoteca que ofrece

un repertorio de películas y fotos.
Patrones arquitectónicos - Arquitecturas Distribuidas

● Master-Slave • Cada nivel (tier) tiene responsabilidades definidas, ej: el
primer nivel maneja la interacción con el usuario, la segunda
● Cliente-Servidor & N-Tier la lógica de negocio, la tercera maneja la persistencia.
● Peer-to-Peer • Los niveles (tiers) generalmente están alojados en un
hardware específico pero un nodo de hardware puede
● Map Reduce albergar varios niveles (tiers)
(Guía de Estudio)

DSI – 3K3
Patrones arquitectónicos - Arquitecturas Distribuidas

Ejemplo:
● Cliente-Servidor & N-Tier
Sistema: Gestión de Tasa Comercio e Industria Municipal
Esquema genérico:
Web Web Web

Client Client Client
Web
Server
Application
Server
Databases
Arquitecturas de Hardware
● Cliente-Servidor
● Espejada
● Rack
● Farm (granja de servidores)
● (Guía de Estudio)

DSI – 3K3
Bibliografía
• Sommerville Ian, “Ingeniería de Software” 9ta. Ed. (2011), Ed. Addison
Wesley.
• Pressman Roger, “ Ingeniería del software – Un enfoque práctico”, séptima
edición (2010), Mc Graw Hill
• Gorton Ian, “Essential Software Architecture” (2006), Springer.
• Fairbanks George, “Just Enough Software Software Architecture”, (2010), Ed.
Marshall & Brainerd.
• Essentials of IBM Rational Requisite Pro V.7.0, Student Manual, Octubre 2006.
• Hofmeister Christine, Kruchten Philippe, Nord Robert L., Obbink Henk, Ran
Alexander, America Pierre – Artículo: “A general model of software
architecture design derived from five industrial approaches” - The Journal of
Systems and Software Volume 80 (2007).


DSI 3K3 - Diseño Arquitectónico 2021

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

DSI 3K3 - Diseño Arquitectónico 2021

Cargado por

Copyright:

Formatos disponibles

DSI – 3K3

Unidad 3: Diseño Arquitectónico

Diseño de Sistemas – Curso: 3K3

Diseño Arquitectónico - Concepto de Arquitectura

“La Arquitectura del Software de un sistema de cómputo es la

DSI - 3K3 - Diseño Arquitectónico (Unidad 3) 2

Docentes: Ing. Marcela F. Cattaneo

Diseño Arquitectónico - Concepto de Arquitectura

“La Arquitectura se define como la organización

DSI - 3K3 - Diseño Arquitectónico (Unidad 3) 3

Diseño Arquitectónico - Concepto

● El proceso de diseño inicial para identificar estos subsistemas y

Docentes: Ing. Marcela F. Cattaneo

Diseño Arquitectónico - Concepto

● Es el enlace crucial entre el diseño y la ingeniería de

DSI - 3K3 - Diseño Arquitectónico (Unidad 3)

Diseño Arquitectónico - Concepto

● Mapea los requerimientos esenciales de la fase de análisis hacia

● Es la asignación de los modelos de requerimientos esenciales

Docentes: Ing. Marcela F. Cattaneo

Diseño Arquitectónico - Decisiones a tomar

Docentes: Ing. Marcela F. Cattaneo

Diseño Arquitectónico - Proceso de diseño arquitectónico

personales tienen por lo general un solo procesador.

○ Los sistemas más grandes suelen ser distribuidos donde el software se

DSI - 3K3 - Diseño Arquitectónico (Unidad 3) 9

Docentes: Ing. Marcela F. Cattaneo

○ Descomponer las unidades del sistema estructural separando los

DSI - 3K3 - Diseño Arquitectónico (Unidad 3) 11

Diseño Arquitectónico - Proceso de diseño arquitectónico

Se toman decisiones sobre Se desarrolla un modelo general

Modelo llamada-retorno Modelo del administrador

○ Modelos dirigidos por eventos

Modelo de transmisión Modelo dirigido por interrupciones 12

Docentes: Ing. Marcela F. Cattaneo

Diseño Arquitectónico - Subsistema

DSI - 3K3 - Diseño Arquitectónico (Unidad 3) 14

Docentes: Ing. Marcela F. Cattaneo

Diseño Arquitectónico - Elección de la estructura

Elección de la estructura – Impacto de los RNF

Estructura en capas, con alto nivel de validación de la seguridad.

La arquitectura se debe diseñar de tal forma que las operaciones

La arquitectura debe diseñarse para incluir componentes redundantes

Se debe diseñar utilizando componentes autocontenidos de grano fino que

Docentes: Ing. Marcela F. Cattaneo

Diseño Arquitectónico - Elección de la estructura

● No hay una solución perfecta, se busca la forma más apropiada

DSI - 3K3 - Diseño Arquitectónico (Unidad 3) 17

Proceso de Diseño Arquitectónico

DSI - 3K3 - Diseño Arquitectónico (Unidad 3) 18

Docentes: Ing. Marcela F. Cattaneo

Proceso de Diseño Arquitectónico

Proceso de Diseño Arquitectónico

1. Identificar requerimientos significativos.

DSI - 3K3 - Diseño Arquitectónico (Unidad 3) 20

Docentes: Ing. Marcela F. Cattaneo

Proceso de Diseño Arquitectónico

DSI - 3K3 - Diseño Arquitectónico (Unidad 3) 21

Proceso de Diseño Arquitectónico

Docentes: Ing. Marcela F. Cattaneo

Proceso de Diseño Arquitectónico

● La priorización puede provocar conflictos entre los requerimientos.

Proceso de Diseño Arquitectónico - Diseñar la Arquitectura

● Si bien todas las tareas para realizar la arquitectura son