Patrones de Arquitectura

1. Arquitectura de Software
Unidad # 2
Msi. Katty Lino C.

2. Temas de la Unidad
Diseño Arquitectónico
• Decisiones de diseño
• Vistas
• Patrones
• Aplicaciones
Pruebas y Mantenimiento
de Software
• Pruebas de desarrollo
• Pruebas de versión
• Pruebas de Usuario
• Mantenimiento de Software
Confiabilidad y Seguridad
• Propiedades de confiabilidad
• Disponibilidad y fiabilidad
• Protección
• Seguridad

3. Objetivos
• Comprender por qué es importante el diseño arquitectónico del
software;
• Conocer las decisiones que deben tomarse sobre la arquitectura de
software durante el proceso de diseño arquitectónico;
• Asimilar la idea de los patrones arquitectónicos, formas bien
reconocidas de organización de las arquitecturas del sistema, que
pueden reutilizarse en los diseños del sistema;
• Identificar los patrones arquitectónicos usados frecuentemente en
diferentes tipos de sistemas de aplicación, incluidos los sistemas de
procesamiento de transacción y los sistemas de procesamiento de
lenguaje

4. Decisiones en el Diseño Arquitectónico
El diseño arquitectónico es un proceso
creativo en el cual se diseña una
organización del sistema que cubrirá
los requerimientos funcionales y no
funcionales de éste.
Las actividades dentro del proceso
dependen del tipo de sistema que se
va a desarrollar, los antecedentes y la
experiencia del arquitecto del sistema,
así como de los requerimientos
específicos del sistema.

5. Arquitectura de Software
La arquitectura del software de
un programa o sistema de
cómputo es la estructura o
estructuras del sistema, lo que
comprende a los componentes
del software, sus propiedades
externas visibles y las relaciones
entre ellos

6. Importancia de la Arquitectura
Las representaciones de la
arquitectura del software permiten la
comunicación entre todas las partes
(participantes) interesadas en el
desarrollo de un sistema basado en
computadora.
La arquitectura resalta las primeras
decisiones que tendrán un efecto
profundo en todo el trabajo de
ingeniería de software siguiente y,
también importante, en el éxito último
del sistema como entidad operacional.
La arquitectura “constituye un modelo
relativamente pequeño y asequible por la vía
intelectual sobre cómo está estructurado el sistema
y la forma en la que sus componentes trabajan
juntos” [Bas03]

7. Vistas Arquitectónicas
Muestran toda la arquitectura del
sistema software que se esté
documentando, pero cada una de
ellas ha de documentarse de
forma diferente y ha de mostrar
aspectos diferentes del sistema
software.

8. Vistas Arquitectónicas

9. Vistas Arquitectónicas
Vista lógica- En esta vista se representa la funcionalidad que el sistema
proporcionara a los usuarios finales. Es decir, se ha de representar lo
que el sistema debe hacer, y las funciones y servicios que ofrece. Para
completar la documentación de esta vista se pueden incluir los
diagramas de clases, de comunicación o de secuencia de UML.
Vista de proceso- Muestran los procesos que hay en el sistema y la
forma en la que se comunican estos procesos; es decir, se representa
desde la perspectiva de un integrador de sistemas, el flujo de trabajo
paso a paso de negocio y operacionales de los componentes que
conforman el sistema. Para completar la documentación de esta vista se
puede incluir el diagrama de actividad de UML.

10. Vistas Arquitectónicas
Una vista de desarrollo, se muestra el sistema desde la perspectiva de un
programador y se ocupa de la gestión del software; o en otras palabras, se va a
mostrar como esta dividido el sistema software en componentes y las dependencias
que hay entre esos componentes. Para completar la documentación de esta vista se
pueden incluir los diagramas de componentes y de paquetes de UML..
Vista física muestra desde la perspectiva de un ingeniero de sistemas todos los
componentes físicos del sistema así como las conexiones físicas entre esos
componentes que conforman la solución (incluyendo los servicios). Para completar
la documentación de esta vista se puede incluir el diagrama de despliegue de UML.

11. Vistas Arquitectónicas
Vista de Escenarios: Representada por los casos de uso software y va a tener la
función de unir y relacionar las otras 4 vistas, esto quiere decir que desde un
caso de uso podemos ver como se van ligando las otras 4 vistas, con lo que
tendremos una trazabilidad de componentes, clases, equipos, paquetes, etc.,
para realizar cada caso de uso. Para completar la documentación de esta vista se
pueden incluir el diagramas de casos de uso de UML.

12. Patrones Arquitectónicos

13. Cliente Servidor
La arquitectura funciona sobre un modelo de
solicitud-respuesta. El cliente envía la
solicitud al servidor para obtener información
y el servidor responde.
Cada sitio web que se navega, ya sea un blog de
Wordpress, una aplicación web como Facebook
o Twitter, se basa en la arquitectura cliente-
servidor.

14. Model-View-Controller (MVC)
La arquitectura MVC es un patrón arquitectónico de software en el que la
lógica de la aplicación se divide en tres componentes sobre la base de la
funcionalidad. Estos componentes se llaman:
Models o Modelos:
representan cómo se
almacenan los datos en
la base de datos.
Views o Vistas: los
componentes que son
visibles para el usuario,
como una interfaz de
usuario.
Controllers o
Controladores: los
componentes que actúan
como una interfaz entre
los modelos y las vistas.
La arquitectura MVC se utiliza no solo para aplicaciones de escritorio, sino también para aplicaciones
móviles y web.

15. Model-View-Controller (MVC)

16. Modelo En capas
Este patrón se puede usar para estructurar programas
que se pueden descomponer en grupos de subtareas,
cada uno de los cuales se encuentra en un nivel
particular de abstracción. Cada capa proporciona
servicios a la siguiente capa superior.
Las capas más comunes son:
Capa de
presentación
Capa de lógica de
negocio
Capa de acceso a
datos

17. Modelo En capas
Capa de
presentación:
La que ve el usuario (también se la
denomina «capa de usuario»), presenta el
sistema al usuario, le comunica la
información y captura la información del
usuario en un mínimo de proceso
También es conocida como interfaz gráfica
y debe tener la característica de ser
«amigable» (entendible y fácil de usar)
para el usuario.
Esta capa se comunica únicamente con la
capa de negocio.
Capa de
negocio:
Es donde residen los programas que se
ejecutan, se reciben las peticiones del
usuario y se envían las respuestas tras el
proceso.
Se denomina capa de negocio (e incluso
de lógica del negocio) porque es aquí
donde se establecen todas las reglas que
deben cumplirse.
Esta capa se comunica con la capa de
presentación, para recibir las solicitudes y
presentar los resultados, y con la capa de
datos, para solicitar al gestor de base de
datos almacenar o recuperar datos de él..
Capa de
datos:
Es donde residen los datos y es la
encargada de acceder a los mismos.
Está formada por uno o más gestores de
bases de datos que realizan todo el
almacenamiento de datos, reciben
solicitudes de almacenamiento o
recuperación de información desde la capa
de negocio.

18. Arquitectura Monolítica
Las aplicaciones monolíticas se ajustan mejor cuando
los requisitos son simples y se espera que la
aplicación maneje una cantidad limitada de tráfico.
Por ejemplo, una aplicación de cálculo de impuestos
internos para una organización.
Casos de uso en los que la empresa está segura de
que no habrá un crecimiento exponencial en la base
de usuarios y el tráfico a lo largo del tiempo.

19. Arquitecturas MicroServicios
La arquitectura de microservicios se ajusta mejor para casos de uso
complejos y para aplicaciones que esperan que el tráfico aumente
exponencialmente en el futuro, como una aplicación de red social
o una plataforma de streaming.
Una aplicación de red social típica tiene varios componentes, como
mensajería, chat en tiempo real, transmisión de video en vivo, carga
de imágenes, me gusta, compartir, etc. En este caso, es mejor
desarrollar cada componente por separado,

20. Pruebas y Mantenimiento de
Software

21. Proceso de pruebas
• Demostrar al desarrollador y
al cliente que el software
cumple con los
requerimientos
1
• Encontrar situaciones donde el
comportamiento del software
sea incorrecto, indeseable o no
esté de acuerdo con su
especificación
2

22. Validación o verificación de Software
• “Validación: ¿construimos el producto correcto?”.
• “Verificación: ¿construimos bien el producto?”.
La finalidad de la
verificación es comprobar
que el software cumpla con
su funcionalidad y con los
requerimientos no
funcionales establecidos.
La meta de la validación es
garantizar que el software
cumpla con las expectativas
del cliente.

23. Etapas de pruebas
Pruebas de
desarrollo,
El sistema se
pone a prueba
durante el
proceso para
descubrir errores
(bugs) y defectos
Versiones de
prueba
Un equipo prueba
por separado
experimenta una
versión completa
del sistema, antes
de presentarlo a
los usuarios.
Pruebas de
usuario
Los usuarios
reales o
potenciales de un
sistema prueban
el sistema en su
propio entorno.

24. Pruebas de Desarrollo
Pruebas de unidad,
Se ponen a prueba
unidades de programa o
clases de objetos
individuales. Las
pruebas de unidad
deben enfocarse en
comprobar la
funcionalidad de objetos
o métodos.
Pruebas del componente,
Muchas unidades
individuales se integran
para crear componentes
compuestos. La prueba
de componentes debe
enfocarse en probar
interfaces del
componente.
Pruebas del sistema
Algunos o todos los
componentes en un
sistema se integran y el
sistema se prueba como
un todo. Las pruebas del
sistema deben enfocarse
en poner a prueba las
interacciones de los
componentes.

25. Pruebas de Versión
Son el proceso de poner a prueba una versión particular de un sistema que se
pretende usar fuera del equipo de desarrollo.
Un equipo independiente que
no intervino en el desarrollo
del sistema debe ser el
responsable de las pruebas
de versión.
Las pruebas del sistema por parte del equipo
de desarrollo deben enfocarse en el
descubrimiento de bugs en el sistema (pruebas
de defecto). El objetivo de las pruebas de
versión es comprobar que el sistema cumpla
con los requerimientos y sea suficientemente
bueno para uso externo (pruebas de
validación)

26. Pruebas de Usuario
Las pruebas de usuario o del cliente son una etapa en el proceso
de pruebas donde los usuarios o clientes proporcionan entrada
y asesoría sobre las pruebas del sistema.
• Los usuarios del
software trabajan con
el equipo de diseño
para probar el
software en el sitio del
desarrollador.
Pruebas alfa
• Una versión del software se
pone a disposición de los
usuarios, para permitirles
experimentar y descubrir
problemas que encuentran con
los desarrolladores del sistema.
Pruebas beta • Los clientes prueban un
sistema para decidir si está
o no listo para ser aceptado
por los desarrolladores del
sistema y desplegado en el
entorno del cliente.
Pruebas de
aceptación,

27. Mantenimiento del Software
El mantenimiento del software es el
proceso general de cambiar un
sistema después de que éste se
entregó.
Tipos
de
Mantenimiento
Reparaciones de
Fallas
Adaptación
Ambiental
Adición de
Funcionalidad

28. Tipos de Mantenimiento
Reparaciones
de fallas
Los errores de codificación por
lo general son relativamente
baratos de corregir; los errores
de diseño son más costosos,
ya que quizás impliquen la
reescritura de muchos
componentes del programa.
Los errores de requerimientos
son los más costosos de
reparar debido a que podría
ser necesario un tenso
rediseño del sistema.
Adaptación
ambiental
Este tipo de mantenimiento se
requiere cuando algún aspecto
del entorno del sistema, como
el hardware, la plataforma
operativa del sistema u otro
soporte, cambia el software. El
sistema de aplicación tiene
que modificarse para lidiar
con dichos cambios
ambientales.
Adición de
funcionalidad
Este tipo de mantenimiento es
necesario cuando varían los
requerimientos del sistema,
en respuesta a un cambio
organizacional o empresarial.
La escala de los cambios
requeridos en el software
suele ser mucho mayor que en
los otros tipos de
mantenimiento.

29. Confiabilidad y Seguridad

30. Razones por los que la Confiabilidad de los
sistemas es importante
Las fallas del sistema afectan a un gran número de individuos
Los usuarios rechazan a menudo los sistemas que son poco fiables, carecen de
protecciones o son inseguros
Los costos por las fallas del sistema suelen ser enormes
Los sistemas no confiables pueden causar pérdida de información

31. Propiedades de confiabilidad
Es el grado de confianza
que un usuario tiene que
el sistema ejecutará
como se espera, y que el
sistema no “fallará” en
su uso normal

32. Propiedades de confiabilidad
•Es la probabilidad de que
en un momento dado
éste funcionará, ejecutará
y ofrecerá servicios útiles
a los usuarios.
Disponibilidad
•Es la probabilidad,
durante un tiempo
determinado, de que el
sistema brindará
correctamente servicios
como espera el usuario.
Fiabilidad •Es un juicio de cuán
probable es que el
sistema causará daños a
las personas o su
ambiente.
Protección
•Es un juicio de cuán
probable es que el
sistema pueda resistir
intrusiones accidentales o
deliberadas
Seguridad

33. Disponibilidad y fiabilidad
Disponibilidad
La probabilidad de que
un sistema, en un
momento en el tiempo,
sea operativo y brinde
los servicios solicitados.
Fiabilidad
Es la probabilidad de
operación libre de falla
durante cierto tiempo,
en un entorno dado,
para un propósito
específico .

34. Disponibilidad y fiabilidad
La disponibilidad y la fiabilidad están vinculadas, pues las fallas del sistema pueden colapsar al
sistema. No obstante, la disponibilidad no sólo depende del número de caídas del sistema, sino
también del tiempo necesario para reparar los componentes que causaron la falla.
Por ello, si el sistema A falla una
vez al año y el sistema B falla una
vez al mes, entonces a todas
luces A es más fiable que B.
Sin embargo, suponga que
el sistema A tarda tres días
en reiniciarse después de
una falla, mientras que el
sistema B tarda sólo 10
minutos en reiniciar.
La disponibilidad del
sistema B durante el año
(120 minutos de tiempo
muerto) es mucho mejor
que la del sistema A (4,320
minutos de tiempo muerto)

35. Protección
Los sistemas críticos para la
protección son aquellos en los que
resulta esencial que la operación
del sistema sea segura en todo
momento; esto es, el sistema
nunca debe dañar a las personas o
a su entorno, incluso cuando falle

36. Seguridad
La seguridad es un atributo del sistema que refleja la habilidad de éste para
protegerse a sí mismo de ataques externos, que podrían ser accidentales o
deliberados.
Estos ataques externos son posibles
puesto que la mayoría de las
computadoras de propósito general
ahora están en red y, en consecuencia,
son accesibles a personas externas.
Ejemplos de ataques pueden ser la
instalación de virus y caballos de
Troya, el uso sin autorización de
servicios del sistema o la
modificación no aprobada de un
sistema o de sus datos.

37. Tipos de amenazas
Amenazas a la
confidencialidad del
sistema y sus datos
Pueden difundir
información a
individuos o
programas que no
están autorizados
a tener acceso a
dicha información.
Amenazas a la
integridad del sistema
y sus datos
Tales amenazas
pueden dañar o
corromper el
software o sus
datos.
Amenazas a la
disponibilidad del
sistema y sus datos
Dichas amenazas
pueden restringir
el acceso al
software o sus
datos a usuarios
autorizados

38. Controles que se deben implementar para
mejorar la seguridad del sistema
Evitar la
vulnerabilidad
Detectar y
neutralizar
ataques
Limitar la
exposición y
recuperación