Está en la página 1de 31

PATRONES ARQUITECTONICOS

¿Qué es un Patrón?
• Un patrón es un modelo que podemos seguir para
realizar algo. Los patrones surgen de la experiencia
de seres humanos de tratar de lograr ciertos
objetivos.

• Los patrones capturan la experiencia existente y


probada para promover buenas prácticas.
Patrones
• Patrones Arquitectónicos
• Describen prácticas para definir la arquitectura del
sistema.

• Patrones de Diseño
• Describen soluciones a problemas mucho más
específicos en el diseño.
Patrones Arquitectónicos
• Los patrones arquitectónicos determinan:
• La organización estructural del sistema.
• ¿Cómo será el diseño de la solución?
• La selección de elementos estructurales.
• ¿Cuáles serán los componentes?
• El comportamiento de los componentes.
• ¿Cuál será la función de cada componente?
• Las interfaces entre ellos.
• ¿Cómo se van a comunicar esos componentes?
Patrones Arquitectónicos
• Algunos patrones arquitectónicos son los
siguientes:

• Patrón de Arquitectura basada en Capas.

• Patrón MVC.
Patrón de Arquitectura basada en Capas
• Descompone una aplicación en
un conjunto de capas Cliente
independientes y ordenadas
jerárquicamente.
Capa N

• Cada capa:
• Usa lo servicios de la capa Capa N-1
inmediatamente inferior.

Capa 1
• Ofrece servicios a la capa
inmediatamente superior.
Patrón de Arquitectura basada en Capas
• Ventajas:
• Reutilización de una capa en varias aplicaciones.
• Permite la estandarización.

• Desventajas:
• Si el número de capas es muy alto, puede ser una solución
ineficiente.

• Trabajo innecesario de paso de argumentos entre niveles.

• Si hay pocas capas el sistema será poco organizado. Si hay


excesivas capas el sistema será muy complejo e ineficiente.
Patrón de Arquitectura basada en Capas
• La metodología presentada por
Larman presupone una Cliente
estructura de tres capas:

• Capa de Presentación. Capa de


Presentación

• Capa del Dominio de la


Aplicación. Capa del Dominio de
la Aplicación

• Capa del Repositorio.


Capa del Repositorio
Patrón de Arquitectura basada en Capas

• Capa de Presentación: Cliente


• Encargada de presentar la
información. (Formato de Capa de
reportes, gráficos, etc.) Presentación

• Interfaces de usuario. Capa del Dominio de


la Aplicación

• Interactuar con las capas


inferiores del sistema. Capa del Repositorio
Patrón de Arquitectura basada en Capas

• Capa del Dominio de la Aplicación: Cliente


• Implementa las funciones solicitadas
por los clientes a través de a interfaz
de presentación. (Ej: Validar Cliente) Capa de
Presentación
• Reúne todos los componentes del
software que apoyan los procesos de
negocio que llevan a cabo los Capa del Dominio de
usuarios. la Aplicación

• También se conoce como la capa de


la Lógica de la aplicación.
Capa del Repositorio
Patrón de Arquitectura basada en Capas

• Capa del Repositorio: Cliente


• Gestiona todos los elementos de
información. (Archivos, XML,
BD). Capa de
Presentación

• Reúne todos los componentes de


software que se encargan del Capa del Dominio de
manejo de datos persistentes. la Aplicación

• También conocida como capa de Capa del Repositorio


gestión de recursos.
Patrón de Arquitectura basada en Capas
• Tipos de diseños basados en la arquitectura en
capas:

• Diseño top-down de capas.

• Diseño bottom-up de capas.


Patrón de Arquitectura basada en Capas
• Diseño top-down de
capas: Cliente
• Se define la funcionalidad
del sistema desde el punto
de vista del cliente. Capa de
Presentación

• Se propaga por capas según


las necesidades Capa del Dominio de
identificadas en las capas la Aplicación
anteriores.
Capa del Repositorio
Patrón de Arquitectura basada en Capas
• Diseño top-down de capas:
• Ventaja:
• Al inicio del proyecto se tienen claras las funcionalidades y se dirige el
desarrollo sobre ellas.

• Desventaja:
• Sólo es posible aplicarlos a sistemas desarrollados desde cero.
Patrón de Arquitectura basada en Capas
• Diseño bottom-up de capas:
• Consecuencia de la necesidad
de integrar de sistemas. Cliente

• Es necesario evaluar recursos Capa de


existentes. Presentación

• Encapsular la funcionalidad Capa del Dominio de


existente.
la Aplicación

• Adaptar la salida de la
aplicación a las necesidades Capa del Repositorio
del cliente.
Patrón de Arquitectura basada en Capas
• Diseño bottom-up de capas:
• Ventaja:
• Los componentes por lo general son poco acoplados y pueden ser
reutilizados.

• Desventaja:
• Viene impuesto por necesidades existentes.
Patrón MVC
• Modelo, Vista, Controlador (MVC, Model – View –
Control)
Es un patrón de arquitectura de software que busca agrupar
los componentes de la aplicación en tres niveles lógicos.

<<Controlador>>
Nombre de la clase

<<Modelo>> <<Vista>>
Nombre de la clase Nombre de la clase
Patrón MVC
• Modelo:
• El modelo es la representación específica de la información
con la cual el sistema opera.

• Los objetos del modelo guardan información sobre el estado


interno del sistema a corto y largo plazo.

• Se encarga de la lógica de datos y de asegurar la integridad de


estos. Ej: Validar que no se compre un número negativo de
unidades.

• Permite derivar nuevos datos. Ej: Calcular si hoy es el


cumpleaños del usuario o los totales, impuestos en un carrito
de la compra.
Patrón MVC
• Vista:
• La Vista está formada por el conjunto de objetos que
manejan la presentación visual de los datos
representados por el Modelo.

• Genera una representación visual del Modelo y muestra


los datos al usuario.

• Interactúa con el Modelo a través de una referencia al


propio Modelo.
Patrón MVC
• Controlador:
• Este responde a eventos, usualmente acciones del
usuario e invoca cambios en el Modelo y probablemente
en la Vista.
Patrón MVC
• Ejemplo: (Contexto)
• En el Modelo de Requisitos se obtuvo el siguiente Diagrama de
Casos de Uso del Sistema:
Sistema

Agregar Estudiante

Administrador

Ver Estudiantes
Patrón MVC
• Igualmente en el Modelo de Requisitos se obtuvo el siguiente
Modelo de Objetos del Dominio:
Patrón MVC
• En el Modelo de Análisis se identificaron los siguientes objetos:

Controlador
Agregar
Estudiante
AgregarEstudiante

VentanaPrincipal

Escuela

VerEstudiantes
Controlador
Ver
Patrón MVC
• Finalmente, en el Modelo de Diseño se aplica el patrón Modelo –
Vista – Controlador de la siguiente manera:

View Control Model

Administrador
Patrón MVC
View Control Model

Escuela
VentanaPrincipal -codigo
ControladorPrincipal
-nombreEscuela
+getCodigo()
+setCodigo() escuela
+getNombreEscuela()
+setNombreEscuela()
controlVer +getEstudiantes()
ventVer
+setEstudiantes()
ControladorVer estudiantes
VerEstudiantes +agregarEstudiante() *
Estudiante
+buscarEstudiantes() -nombre
ventAgregar controlAgregar
-apellido
-cedula
AgregarEstudiante ControladorAgregar -sexo
+getNombre()
+setNombre()
+agregarEstudiante()
+getApellido()
+setApellido()
+getCedula()
+setCedula()
+getSexo()
+setSexo()
+getEscuela()
+setEscuela()
Microservicios
Arquitectura de Software

• Para mostrar la Arquitectura del Software se


utilizarán Diagramas de Componentes,
Componentes de la Arquitectura si es MVC y
Diagramas de Despliegue.
• Se utilizará un Diagrama de Componentes para
mostrar los componentes ejecutables (*.exe, *.dll,
etc.) y de base de datos, o los componentes de
cada capa si es el caso.
Símbolos del Diagrama de Componentes
Símbolo Significado
Nombre del Componente
Componente: Ejecutable
en un dispositivo de
Nombre de la Interface hardware.
Interface: Colección de
operaciones ofrecida por
el componente.
Dependencia: Relación de
dependencia entre
componentes.
Se utilizará un Diagrama de Despliegue para mostrar los nodos
(dispositivos de hardware) en los que se ejecutarán los componentes.

Símbolos del Diagrama de Despliegue


Símbolo Significado
Dispositivo Dispositivo de hardware
del
Hardware (Servidor, PC, etc.)
Comunicación: Relación
entre nodos que implica
comunicación directa.
Se deberán indicar los componentes que se ejecutan en cada nodo,
utilizando una tabla como la siguiente:
 

Tabla de Despliegue de Componentes

Dispositivo de hardware Componentes

Nombre del Dispositivo de hardware Nombre Componente 1


Nombre Componente 2
Gracias!

También podría gustarte