Ingeniería de Software INF - 163

Presentación del tema: "Ingeniería de Software INF - 163"— Transcripción de la presentación:

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

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”

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

4 La arquitectura es un Instrumento cuya función es la de intervenir en favor de la humanidad
Se requieren soluciones para problemas reales, no inventar problemas para poder empatar con nuevas soluciones Glenn Murcutt

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.

6 Y…. es que no es lo mismo construir esto……

7 Que esto!!!

8 Ó esto!!!

9 Qué se necesita para construir ….… algo así ???

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???

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.

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

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…

15 Con el tiempo, las aplicaciones de software se convierten en laberintos…

16 “Programar sin una arquitectura en mente es como explorar un socavón sólo con una linterna; no sabes dónde estás, dónde has estado ni hacia dónde vas”

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.

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.

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

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.

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

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.”

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

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.

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

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;

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

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.

29

30 SON VISTAS DE LOS MODELOS (NO MODELOS COMPLETOS).
1 VISTA DEL MODELO DE CASOS DE USO VISTA DEL MODELO DEL DOMINIO / VISTA DEL DIAGRAMA DE CLASES : IU-1 : Gro : 1: 2: 3: 4 () VISTA DEL MODELO DEL ANÁLISIS 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

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