2.5 DISEÑO ARQUITECTONICO

Tamaño: px

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

Download "2.5 DISEÑO ARQUITECTONICO"

Ramón Escobar Carrizo
hace 6 años
Vistas:

MODULO II Ingeniería de Software INF - 163 2.

1 MODULO II Ingeniería de Software INF DISEÑO ARQUITECTONICO 18/10/2012 Resumen preparado por Miguel Cotaña 1

2 Architecture Business Cycle - ABC Los requerimientos no determinan del todo la arquitectura, más bien es el resultado de influencias en los ambientes técnicos, sociales y del negocio. Llamaremos a este ciclo de influencias, del ambiente a la arquitectura y de la arquitectura al ambiente como El Ciclo de la Arquitectura de Negocios 2

3 Influencia de los participantes gerente del proyecto Bajo costo Rendimiento del equipo usuario final Funcionalidad Rendimiento Seguridad usabilidad modificabilidad soporte aplicativo arquitecto líder de Corto tiempo en mercado Bajo costo y tiempo cliente mercadeo Bajo costo; ventajas con de entrega, que no cambie productos similares muy a menudo 3

4 4

5 El rol de un arquitecto de edificaciones y un arquitecto de software parece enfrentar los mismos retos Por lo que es claro, que se debe contar, con un conjunto básico de habilidades y conocimientos necesarios y suficientes para ejercer este tipo de roles. 5

6 6

7 7

8 8

9 9

10 Cada escenario plantea retos, condiciones y necesidades diferentes!!! Sale a relucir la siguiente pregunta: Qué herramientas, personas, presupuesto, conocimiento y tiempo necesitamos para cada escenario??? 10

11 11

12 Por supuesto.. Podemos establecer, que todas las consideraciones que se nos ocurran con respecto a definir la ARQUITECTURA DE EDIFICIOS, deberán ser tenidas en cuenta también al momento de definir la ARQUITECTURA DEL SOFTWARE. 12

13 Mansión Winchester Qué tiene que ver esta historia con la ARQUITECTURA DE SOFTWARE? 13

14 En el contexto del desarrollo de software, es similar a la historia.. Cuando un desarrollador es asignado a la tarea de mantener y evolucionar un sistema heredado, cuya arquitectura tiene fallas o no está documentado, elige reconstruir partes o crear sus propias rutas dentro del código 14

15 15

16 16

17 El arquitecto de software es el encargado de establecer a que nivel, con que estrategia, y que herramientas son necesarias para realizar una implementación que satisfaga requisitos funcionales y no funcionales. 17

18 Un buen arquitecto debe estar en capacidad de generar una especificación coherente, para enfrentar un conjunto de riesgos mucho mas reducido, que en el caso de un arquitecto aprendiz. Un arquitecto de edificaciones puede ser bueno sin tener que haber pegado jamás un ladrillo. Pero, no podemos pensar lo mismo de un IS. 18

19 Al igual que ellos, los arquitectos de software usan modelos que representan las especificaciones y necesidades técnicas de los sistemas 19

20 La construcción de estos artefactos, en ambos contextos requiere de herramientas, habilidades y conocimientos, y servirá como guía en el proceso de construcción: De forma global; Como visión completa; Parcialmente; Específicamente; Con alto nivel de detalle. 20

Elementos relacionados con la arquitectura Qué? Por qué?

de la arquitectura Satisface Restringe Requerimientos S/W

sistema Quién? Produce Tecnología Defines Para qué?

21 Elementos relacionados con la arquitectura Qué? Por qué? Arquitectura Cualidades de la Arquitectura Representación de la arquitectura Satisface Restringe Requerimientos S/W Características Del Sistema Atributos de Calidad del sistema Quién? Produce Tecnología Defines Para qué? Arquitecto Analiza Procesos Stakeholders Habilidades Define roles Organización 21

22 Qué es la arquitectura? Clements define: La AS es una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes según se la percibe desde el resto del sistema y las formas en que los componentes interactúan y se coordinan para alcanzar la misión del sistema. La vista arquitectónica es una vista abstracta, aportando el más alto nivel de comprensión y la supresión o diferimiento del detalle inherente a la mayor parte de las abstracciones. 22

23 La arquitectura no es el software operativo. Es una representación que permite que un IS: 1) Analice la efectividad del diseño para cumplir con los requisitos establecidos; 2) Considere opciones arquitectónicas en una etapa en que aún resulta relativamente fácil hacer cambios al diseño: 3) Reduzca los riegos asociados con la construcción del software. 23

24 En el contexto del diseño arquitectónico, un componente de software es algo tan simple como un módulo del programa o una clase orientada a objetos, pero también se extiende para incluir bases de datos y middleware que permita configurar una red de clientes y servidores. 24

25 Qué hace buena a una arquitectura? Ser producto de un arquitecto o un pequeño grupo de arquitectos con un líder definido; Estar bien documentada, con al menos una vista dinámica y una estática, utilizando notación que los stakeholders puedan entender fácilmente; Ser evaluada y analizada con métricas cualitativas y cuantitativas; Presentar como implementación incremental, mostrando primero la mínima funcionalidad y después cómo puede ir creciendo; Ser diseñada por arquitectos que cuentan con los requerimientos funcionales y no funcionales del sistema 25

26 Por qué es importante la arquitectura? Las representaciones de la arquitectura del software permiten la comunicación entre todas las partes interesadas en el desarrollo de un sistema de cómputo; La arquitectura destaca las decisiones iniciales relacionadas con el diseño que tendrán un impacto en todo el trabajo de la IS; 26

27 La arquitectura constituye un modelo relativamente pequeño e intelectualmente comprensible de cómo está estructurado el sistema y cómo trabajan juntos sus componentes. El modelo de diseño y los patrones arquitectónicos que contiene son transferibles. Es decir, los estilos y patrones arquitectónicos se aplican al diseño de otros sistemas 27

28 . Los diagramas a través de los cuales se representa el diseño y distribución del software, pueden mostrar diferentes vistas de un mismo sistema y de las condiciones que existen en el entorno donde se despliega. 28

29 29

30 1 VISTA DEL MODELO DE CASOS DE USO VISTA DEL MODELO DEL DOMINIO / VISTA DEL DIAGRAMA DE CLASES VISTA DEL MODELO DEL ANÁLISIS : IU-1 : 2: 1: 3: G r 4 () o : : : 2: 1: 3: G r 4 () o VISTA DEL MODELO DEL DISEÑO : + VISTAS DEL MODELO DE IMPLEMENTACIÓN Y PRUEBAS SON VISTAS DE LOS MODELOS (NO MODELOS COMPLETOS). SÓLO APARECEN LOS QUE CORRESPONDEN A CASOS DE USOS CRÍTICOS 30

31 Taxonomía de estilos arquitectónicos Estilos de Flujo de Datos Tubería y filtros Estilos Centrados en Datos Arquitecturas de Pizarra o Repositorio Estilos de Llamada y Retorno Model-View-Controller (MVC) Arquitecturas en Capas Arquitecturas Orientadas a Objetos Arquitecturas Basadas en Componentes Estilos Derivados C2 GenVoca REST Estilos de Código Móvil Arquitectura de Máquinas Virtuales Estilos heterogéneos Sistemas de control de procesos Arquitecturas Basadas en Atributos Estilos Peer-to-Peer Arquitecturas Basadas en Eventos Arquitecturas Orientadas a Servicios (SOA) Arquitecturas Basadas en Recursos 31

Documentos relacionados

ARQUITECTURAS DE SOFTWARE

ARQUITECTURAS DE SOFTWARE 1. DEFINICIÓN Una definición reconocida es la de Clements [Cle96a]: La AS es, a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta