Diseño: Arquitectura de Software. IF 7100 Ingeniería del Software

Tamaño: px

Comenzar la demostración a partir de la página:

Download "Diseño: Arquitectura de Software. IF 7100 Ingeniería del Software"

Ana Vargas Valverde
hace 6 años
Vistas:

1 Diseño: Arquitectura de Software IF 7100 Ingeniería del Software 1

2 Qué es arquitectura de software? Es la definición de una solución estructurada que cumpla todos los requerimientos técnicos y operacionales, mientras optimiza atributos de calidad comunes como rendimiento, seguridad, mantenibilidad, entre otros. 2

3 Qué es arquitectura de software? En Software Architecture in Practice, Bass, Clements y Kazman definen arquitectura de la siguiente manera: La arquitectura de software de un programa o sistema computacional es la estructura o estructuras del sistema que abarca(n) los elementos de software, las propiedades externamente visibles de esos elementos y las relaciones entre ellos. 3

4 Puntos a tener en mente Cómo va el usuario a utilizar la aplicación? Como se va a implementar la aplicación en producción y como será esto administrado? Cuales son los atributos requeridos por la aplicación? (rendimiento, seguridad, concurrencia, internacionalización, configuración) 4

5 Puntos a tener en mente Cómo se puede diseñar la aplicación para que sea mantenible y flexible con el paso del tiempo? Cuales son las tendencias a nivel de arquitectura que pueden afectar la aplicación actualmente o una vez que ha sido implantada?. 5

6 Puntos a tener en mente Cuáles son las partes fundamentales de la arquitectura que representan el riesgo más grande si se hacen mal? Cuáles son las partes de la arquitectura que tienen más probabilidad de cambiar? Cuáles son los principales supuestos y como van a ser probados? 6

7 Puntos a tener en mente Qué condiciones pueden llevar a que se tenga que refactorizar el diseño realizado? Porqué es esta la mejor opción de arquitectura? Qué medidas estamos tomando para mitigar los riesgos? 7

8 Principios claves de arquitectura Cree para el cambio, no para que dure: Considere como la aplicación puede cambiar a través del tiempo y cree la flexibilidad necesario para soportar esto. Modele para analizar y mitigar el riesgo: Use herramientas de diseño, sistemas de modelado c o m o U M L q u e l o a y u d e n a c a p t u r a r requerimientos de diseño y analizar su impacto 8

9 Principios claves de arquitectura Use modelos y visualizaciones como herramientas de comunicación y colaboración: esto para garantizar que el diseño como tal, las decisiones que se tomaron sobre este y los cambios que se le realizan sean conocidos por todos los involucrados. Identifique las decisiones claves de ingeniería: conozca siempre cuales son las áreas donde más comúnmente se comenten errores y tome decisiones informadas en ellas. 9

10 Puntos que se deben definir 1. Tipo de aplicación 2. Estrategia de implantación. 3. Tecnologías 4. Atributos de calidad 5. Preocupaciones transversales. 6. Estilo de arquitectura 10

11 Tipo de aplicación Aplicaciones para dispositivos móviles. Aplicaciones de cliente enriquecido para PC. Aplicaciones para internet con interfaces gráficas ricas. Aplicaciones de servicio diseñadas para dar soporte a componentes vagamente acoplados. 11

12 Tipo de aplicación Aplicaciones web diseñadas para correr en el servidor en escenarios completamente conectados. Aplicaciones en la nube. Otros 12

13 Estrategia de implantación Variedad de los ambientes donde se va a implementar. Limitaciones de esos ambientes: separación física de componentes a través de diferentes servidores, protocolos de red, firewalls, configuraciones de ruteo, etc. 13

14 Tecnologías Depende del tipo de aplicación, forma de implementación y estilo de arquitectura. Otros factores que influyen son: políticas organizacionales, limitaciones de infraestructura, habilidades de los colaboradores, licenciamiento, etc. Se debe hacer una comparación de tecnologías tomando en cuenta estos factores. 14

15 Atributos de calidad Identifique los atributos de calidad críticos del sistema. Identifique los requerimientos de donde nacen estos atributos. Defina si se miden por tiempo de ejecución o por una inspección. Defina los criterios de aceptación para estos atributos. 15

16 Preocupaciones Transversales Logs Autenticación y autorización. Manejo de excepciones. Formas de comunicación entre capas. Manejo de caché: que y donde. 16

17 Estilo de arquitectura También se llama patrón de arquitectura. Provee un framework abstracto para una serie de sistemas. Principalmente define el vocabulario de los componentes y de los conectores entre ellos. Los estilos se pueden combinar para cubrir las necesidades del negocio. 17

18 Estilo de arquitectura Estilo Cliente/Servidor Arquitectura basada en componentes Diseño dirigido por el dominio Descripción Segrega el sistema en dos aplicaciones, donde el cliente hace solicitudes al servidor. En muchos casos, el servidor es una base de datos con la lógica de la aplicación representada como procedimientos almacenados. Descompone el diseño de la aplicación en componentes lógicos o funcionales reutilizables que exponen interfaces de comunicación bien definidas. Un estilo orientado a objetos que se enfoca en modelar el dominio del negocio y en definir objetos basado en entidades dentro del dominio del 18 negocio.

19 Estilo de arquitectura Estilo Arquitectura en capas (layer) Bus de mensajes N-Capas / 3-Capas (tier) Descripción Particiona las preocupaciones de la aplicación en grupos apilados (layer). Prescribe el use de un sistema de software que recibe y envía mensajes usando uno o más canales de comunicación, de forma que la aplicación puede interactuar sin conocer detalles específicos el uno del otro. Segrega funcionalidad en segmentos separados, de manera semejante a la arquitectura en capas, pero con cada componente (tier) estando ubicado, físicamente, en diferentes 19 computadoras.

20 Estilo de arquitectura Estilo Orientado a objetos Arquitectura orientada a servicios (Service-Oriented Architecture, SOA) Descripción Un paradigma de diseño basado en la división de responsabilidades para una aplicación o sistema en objetos individuales, reutilizables y auto suficientes; cada uno contiene los datos y el comportamiento relevante para el objeto. Se refiere a aplicaciones que exponen y consumen funcionalidad como servicios usando contratos y mensajes. 20

21 Proceso de diseño de arquitectura 21

22 Proceso de diseño de arquitectura 1. Identificar los objetivos de la arquitectura: para ayudar a identificar cuando se ha finalizado el diseño de esta. 2. Escenarios clave: Para enfocar el diseño a lo que realmente importa y evaluar que las arquitecturas candidatas cumplan con esos escenarios. 22

23 Proceso de diseño de arquitectura 3. Resumen de la aplicación: se define el tipo de aplicación, la estrategia de implementación y las tecnologías. 4. Problemas claves: Identificar los atributos de calidad y las preocupaciones transversales. 23

24 Proceso de diseño de arquitectura 5. Soluciones candidatas: Se define el estilo de arquitectura y se hace una propuesta de arquitectura que mejore el resultado de la anterior iteración de acuerdo a todos los puntos definidos en los pasos anteriores. 24

25 El mejor arquitecto no es el que conoce todas las tecnologías, sino el que sabe como aplicar la tecnología para solucionar problemas. 25

Documentos relacionados

20488 Desarrollo de Microsoft SharePoint Server 2013 Core Solutions

20488Be 20488 Desarrollo de Microsoft SharePoint Server 2013 Core Solutions Fabricante: Microsoft Grupo: Desarrollo Subgrupo: Microsoft Sharepoint 2013 Formación: Presencial Horas: 25 Introducción En este