201205 Arquitectura de Software

3,350 views
3,192 views

Published on

Conforme el tamaño y complejidad del software se incrementa, diseñarlo va más allá de la aplicación sistemática y cuantificable de una metodología para su construcción, operación y mantenimiento. La arquitectura de software como disciplina, se centra en la idea de reducir la complejidad del software
especificando, modelando y administrando dependencias, comportamientos, y cualidades. Este taller presenta una guía para profesionales de la industria de software, bajo un enfoque técnico, práctico y ágil, respecto a:
a) ¿por qué extender el diseño de software a un nivel arquitectónico?
b) ¿cuándo es valioso abordar el diseño de un proyecto desde un enfoque arquitectónico?
c) ¿qué enfoque utilizar (model-driven, reuse-driven ó risk-driven)?
d) ¿cómo iniciar la adopción de un enfoque arquitectónico?
Concluyendo con una discusión cualitativa y cuantitativa del uso de estilos, modelos, patrones y tácticas arquitectónicas.

Published in: Technology
2 Comments
7 Likes
Statistics
Notes
No Downloads
Views
Total views
3,350
On SlideShare
0
From Embeds
0
Number of Embeds
635
Actions
Shares
0
Downloads
0
Comments
2
Likes
7
Embeds 0
No embeds

No notes for slide

201205 Arquitectura de Software

  1. 1. Arquitectura de Software: Principios y Prácticas Javier González Sánchez javiergs@acm.org
  2. 2. Expectativas ¿Qué esperas aprender en este taller ? líder de proyecto desarrollador ingeniero otro ¿Cuál es tu perfil?2 javiergs@acm.org
  3. 3. ObjetivoS  Complejidad  del  so-ware    S  Ingeniería:  aplicación  sistemá5ca  y  cuan5ficable  de  una  metodología   para  su  construcción,  operación  y  mantenimiento  S  Arquitectura:  reducir  la  complejidad  del  so-ware  especificando,   modelando  y  administrando  dependencias,  comportamientos  y   cualidades  S  Una  guía  bajo  un  enfoque  técnico,  prác5co  y  ágil  3 javiergs@acm.org
  4. 4. ObjetivoS  ¿por  qué  extender  el  diseño  de  so-ware  a  un  nivel  arquitectónico?  S  ¿cuándo  es  valioso  abordar  el  diseño  de  un  proyecto  desde  un  enfoque   arquitectónico?  S  ¿qué  enfoque  u5lizar  (model-­‐driven,  reuse-­‐driven  o  risk-­‐driven)?  S  ¿cómo  iniciar  la  adopción  de  un  enfoque  arquitectónico?  S  Concluyendo  con  una  discusión  cualita9va  y  cuan9ta9va  del  uso  de   es5los,  modelos,  patrones  y  tác5cas  arquitectónicas4 javiergs@acm.org
  5. 5. Conocimiento Previo¿Tienes experiencia con?S  CMMiS  ProcesosS  Arquitectura de software… Ingeniería de software …S  Diseño de componentesS  ReusoS  Patrones (diseño, arquitectura, código)S  Enfoques: Model-driven, Reuse-driven, Risk-driven, Test-driven5 javiergs@acm.org
  6. 6. Agenda1.  Introducción: Antecedentes, Conceptos, Contexto2.  Arquitecturas, Modelos y Patrones3.  [ Trabajo en Equipo ] receso1.  [ Trabajo en Equipo ]2.  Enfoques3.  Aplicación en la Práctica (arquitectura + ingeniería)4.  Conclusiones y Referencias6 javiergs@acm.org
  7. 7. Introducción javiergs@acm.org
  8. 8. Antecedentes javiergs@acm.org
  9. 9. Antecedentes “Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves” * Fuerza  Bruta  * ACM Queue A Conversation with Alan Kay Vol. 2, No. 9 – Dec/Jan 2004-20059 javiergs@acm.org
  10. 10. Antecedentes Ensamblar   So-ware  J. Greenfield and K. Short, “Software factories: assembling applications with patterns, models, frameworks and tools,”presented at the Companion of the 18th annual ACM SIGPLAN conference on Object-oriented programming, systems,languages, and applications, 2003, pp. 16–27.10 javiergs@acm.org
  11. 11. AntecedentesS  $250 billones de dólares en desarrollo de software en USAS  Costo promedio por proyecto $430,000 a $2,300,000 dólaresS  16% de los proyectos se completan a tiempo y en presupuestoS  Aunque en promedio sólo el 42% de los requerimientos originales son implementadosS  31% de los proyectos se cancelan por problemas de calidadS  53% de los proyectos cuestan más de lo planeado, excediendo el presupuesto original en promedio en 189%J. Greenfield and K. Short, “Software factories: assembling applications with patterns, models, frameworks and tools,”presented at the Companion of the 18th annual ACM SIGPLAN conference on Object-oriented programming, systems,languages, and applications, 2003, pp. 16–27.11 javiergs@acm.org
  12. 12. Conceptos javiergs@acm.org
  13. 13. Resumen “Divide y Vencerás” Arquitectura: reducir la complejidad del software especificando, modelando y administrando componentes, dependencias, comportamientos, y cualidades “La calidad del producto es proporcional a la calidad de las partes que lo componen” “El todo es más que la suma de sus partes”13 javiergs@acm.org
  14. 14. Antecedentes Los “cambios” son mis amigos … Necesidades Requerimientos Producto14 javiergs@acm.org
  15. 15. El modelo LEGOLa “creatividad” es positiva … ¡Verdaderos   Componentes!   … componentes15 javiergs@acm.org
  16. 16. Arquitectura… y de software…16 javiergs@acm.org
  17. 17. El ArquitectoArquitectura de softwareS  NO IMPLICA DETALLES DE IMPLEMENTACIÓNArquitectoS  Obtener información del problema y diseñar la solución queS  satisfaga requerimientos (funcionales, no funcionales)PERO Arquitecto  S  Apoyándose en patrones, modelos y framework Ingeniero   Obrero  ADEMÁS DES  Participar activamente en el desarrollo, PERO no es un desarrolladorS  Generar lineamientos GENERALES a considerarse en la creación de FAMILIAS de productos17 javiergs@acm.org
  18. 18. ¿Por qué una arquitectura? construcción de la casa del perro construcción de una casaS  Una personaS  Estructura simpleS  Proceso simple S  Un equipoS  Herramientas simples S  Modelado S  Procesos bien definidosS  Conocimiento teórico limitado S  Herramientas poderosasA medida que los sistemas crecen los algoritmos y las estructuras de datos dejan de ser el mayorproblema.18 javiergs@acm.org
  19. 19. ¿Por qué una arquitectura? Programador  =  Inmediato   Ingeniero  =  Corto  Plazo   Arquitecto  =  Largo  Plazo  19 javiergs@acm.org
  20. 20. Casas VS Software20 javiergs@acm.org
  21. 21. ConceptosS  Estilo arquitectónico Orientada a eventos SOAS  Tipo o clase de arquitectura Física Lógica Tecnológica21 javiergs@acm.org
  22. 22. Estilos ¿Arquitectura? Columnas: ¿maya ó azteca? Dórico, Pirámides en ángulo Jónico, perfecto y columnas de piedra y Corintio Egipto mayor detalle y elaboración. Satisfacer a los dioses y a grandes y extravagantes, un placer a la vista. uno mismo (simetría y Azoteas impresionantes y detalladas naturaleza): Roca, madera en la estructura interna y clásico ventanales emplomados. Fuego, Poder y Belleza china Gótico22 javiergs@acm.org
  23. 23. Tipos Aplicación o Física Datos Negocio Clase o Tipo Estilos arquitectónicos Arquitectura Componente Patrón Reglas23 javiergs@acm.org
  24. 24. Cualidades Arquitectónicas Estáticas: Modificabilidad, Portabilidad, Reusabilidad, Integrabilidad, Verificabilidad. Dinámicas: Desempeño, Disponibilidad, Funcionalidad, Usabilidad. Arquitectónicas: Integridad Conceptual, Correctitud, Completitud, Factibilidad Económica.24 javiergs@acm.org
  25. 25. Modelo de Aplicación25 javiergs@acm.org
  26. 26. Trabajo en Equipo Componentes     Relaciones     Dependencias     Comportamiento     Cualidades  http://www.youtube.com/embed/zkPXzscJef426
  27. 27. Contexto: CMMi javiergs@acm.org
  28. 28. ConceptoEl área de proceso de Solución Técnica:S  Pertenece a la categoría de IngenieríaS  Es una de las 14 áreas de proceso en nivel 3S  Su propósito es diseñar, desarrollar e implementar (incluido el proceso de pruebas) soluciones que satisfagan el conjunto de requerimientosS  Soluciones, diseños e implementaciones son parte de los productos, componentes y procesos del áreaS  Productos o componentes28 javiergs@acm.org
  29. 29. Ingeniería29 javiergs@acm.org
  30. 30. CMMi TS :: SG1 Seleccionar las Soluciones para Productos y Componentes El diseño de la solución debe considerar la evaluación de varias alternativas de solución: arquitectura y modularización, desarrollo interno contra productos comerciales, etc. Estas decisiones deben fundamentarse en: S  Requerimientos S  Restricciones de diseño S  Evolución a futuro del producto S  Productos comerciales disponibles S  Cualidades del software30 javiergs@acm.org
  31. 31. CMMi TS :: SP1.1Desarrollar alternativas de solución y criterios de selecciónS  Identificar y analizar diversas soluciones alternasS  Las alternativas de solución estarán basadas en arquitecturas propuestas que cumplan con las características críticas del productoS  Las alternativas de solución caerán dentro de márgenes aceptables de costos, calendario y desempeño31 javiergs@acm.org
  32. 32. CMMi TS :: SP1.2Seleccionar las soluciones para los componentes del producto quemejor satisfagan los criterios establecidosS  Establecer los requerimientos asociados al conjunto de soluciones, como los requerimientos asignados a los componentes asociados con dicho conjunto de solucionesS  Identificar las soluciones que serán reutilizadas o compradasS  Establecer y mantener la documentación de las soluciones, su evaluación y razones de selección o rechazo32 javiergs@acm.org
  33. 33. CMMi TS :: SG2El diseño del producto o componentes debe incluir información para suimplementación y demás fases del ciclo de vida del producto como sonla instalación y mantenimiento. Además, la documentación del diseñoprovee una referencia que soporta el entendimiento del diseño con losagentes relevantes.33 javiergs@acm.org
  34. 34. CMMi TS :: SP2.1 Desarrollar el diseño del producto o componentes S  Diseño preliminar o arquitectónico. Define los elementos estructurales y de coordinación del producto o componente S  Considera cualidades deseables S  Se debe evaluar el uso de productos comerciales o el reutilizar productos existentes para los componentes del producto S  Considera el establecimiento de un framework que de soporte a familias de productos S  Subprácticas: RUP y aplicación de patrones34 javiergs@acm.org
  35. 35. CMMi TS :: SP2.2Establecer el Paquete Técnico State State Diagrams Class Diagrams State Use Case Use Case Diagrams State Diagrams Use Case Diagrams Use Case Object Diagrams Sequence Diagrams Diagrams Use Case Diagrams Diagrams Diagrams Diagrams Scenario State Scenario State Diagrams Diagrams Collaboration Component Diagrams Diagrams Modelos Diagrams Diagrams Component Scenario Component Diagrams Scenario Diagrams Deployment Diagrams Statechart Diagrams Activity Diagrams Diagrams Diagrams 35 javiergs@acm.org
  36. 36. CMMi TS :: SP2.3Diseñar las interfaces del producto y componentes en base a loscriterios establecidos.36 javiergs@acm.org
  37. 37. CMMi TS :: SP2.4Evaluar, en base a criterios establecidos, si los componentes sedesarrollarán, comprarán o reutilizaránS  La decisión entre desarrollar, comprar o reutilizar comienza en los primeros diseños y se completa a medida que los diseños se van detallando y refinandoS  Patrones y anti patrones37 javiergs@acm.org
  38. 38. CMMi TS :: SG3Implementación del diseño del productoS  CMMi TS :: SP3.1 Implementar (incluye pruebas)S  CMMi TS :: SP3.2 DocumentarS  Hablemos de Trazabilidad  38 javiergs@acm.org
  39. 39. Arquitecturas,Modelos yPatrones javiergs@acm.org
  40. 40. IdiomsS  Patrón de bajo nivelS  Soluciona problemas específicos de implementación en un lenguaje de programaciónS  Describe cómo implementar componentes o relaciones aplicando el lenguajeEjemplos:S  Convenciones de nombresS  Formato para el código fuenteS  Manejo de memoriaS  Etc.40 javiergs@acm.org
  41. 41. Patrones de Diseño Patrones de medio nivel, organizan la funcionalidad de subsistemas de manera independiente. Describe esquemas comunes de comunicación entre componentes para la solución de problemas generales en un contexto particular. S  Patrones de Creación S  Patrones Estructurales S  Patrones de Comportamiento41 javiergs@acm.org
  42. 42. Gang of Four42 javiergs@acm.org
  43. 43. Ensamble a)  Relaciones b)  Mini-componentes incluyentes c)  Autonomía d)  Estándar e)  El “cambio” es mi amigo f)  Creatividad g)  Producto predecible43 javiergs@acm.org
  44. 44. Hablando de Relaciones a)  Ser a)  Observar b)  Usar b)  Encubrir a… c)  Tener c)  Decorar a… d)  Soy único e)  Yo construyo a… f)  Trabajar con … g)  Soy parte de …44 javiergs@acm.org
  45. 45. Observer45 javiergs@acm.org
  46. 46. Facade46 javiergs@acm.org
  47. 47. Decorator47 javiergs@acm.org
  48. 48. Builder48 javiergs@acm.org
  49. 49. Strategy49 javiergs@acm.org
  50. 50. Composite50 javiergs@acm.org
  51. 51. Memento51 javiergs@acm.org
  52. 52. Chain of Responsability52 javiergs@acm.org
  53. 53. Patrones con Patrones53 javiergs@acm.org
  54. 54. Patrones de ArquitecturaPatrones de alto nivel, aplicables a la especificación fundamental del sistemade softwareEjemplos:Ÿ  Distributed Ÿ  LayeredŸ  Event-driven Ÿ  MVCŸ  Frame-based Ÿ  IR-centricŸ  Batch Ÿ  SubsumptionŸ  Pipes and filters Ÿ  DisposableŸ  Repository-centric Ÿ  Publisher-subscriberŸ  BlackboardŸ  InterpreterŸ  Rule-based54 javiergs@acm.org
  55. 55. BlackboardD. Garlan and M. Shaw, “An introduction to software architecture,” Advances in software engineering and knowledgeengineering, vol. 1, pp. 1–40, 1993.55 javiergs@acm.org
  56. 56. LayeredD. Garlan and M. Shaw, “An introduction to software architecture,” Advances in software engineering and knowledgeengineering, vol. 1, pp. 1–40, 1993.56 javiergs@acm.org
  57. 57. Pipes and FiltersD. Garlan and M. Shaw, “An introduction to software architecture,” Advances in software engineering and knowledgeengineering, vol. 1, pp. 1–40, 1993.57 javiergs@acm.org
  58. 58. AntipatronesAntipatrones aplicados en desarrolloS  Lava FlowS  Spaghetti codeS  Poltergeists: muchas clasesS  God class: the blobS  Golden HammerAplicados a la arquitecturaS  Reinventando la ruedaS  Stovepipeline SystemS  Stovepipeline EnterpriseS  Vendor Lock-inAplicados a la gestiónS  Mythical Man MonthS  Death March ProjectS  Analysis paralysisS  Corncob58 javiergs@acm.org
  59. 59. Trabajo en Equipo Práctica en Equipo Es5lo   Arquitectónico     Patrones   de  Diseño     Cualidades   ¿Cómo?59
  60. 60. Trabajo en Equipo¿Cuánto cuesta?¿Cuánto tiempo?¿Cuántas LOC?60 javiergs@acm.org
  61. 61. COnstructive COst MOdelhttp://sunset.usc.edu/research/COCOMOII/cocomo81_pgm/cocomo81.html61 javiergs@acm.org
  62. 62. La Batalla DISEÑO VS IMPLEMENTACIóN COMPONENTES VS LOC62 javiergs@acm.org
  63. 63. Enfoques javiergs@acm.org
  64. 64. Model-Driven S  Definir la funcionalidad del sistema como un modelo independiente de la plataforma S  Propuesto y patrocinado por el Object Management Group S  Separar el diseño de la arquitectura y de las tecnologías de construcción S  Facilitar que el diseño y la arquitectura puedan ser alterados independientemente S  El diseño alberga los requerimientos funcionales (ej. casos de uso) S  La arquitectura proporciona la infraestructura a través de la cual se hacen efectivos los requerimientos no funcionales como la escalabilidad, fiabilidad y rendimiento64 javiergs@acm.org
  65. 65. Reuse-Driven S  Enfoque orientado al negocio S  Efectividad en términos de costo y tiempo S  Generar familias de producto y líneas de producción S  Identificar un área de dominio para la compañía. El dominio se separa en componentes y sistemas S  Utiliza Model-driven por cada componente o sistema identificado en el dominio S  Modelar componentes NO funcionalidades65 javiergs@acm.org
  66. 66. Risk-Driven S  Identificar la cantidad exacta de modelado requerido S  Identificar las partes de mayor riesgo en el proyecto y aplicar técnicas arquitectónicas y de diseño para mitigar esos riesgos S  Identificar, solucionar y evaluarG. H. Fairbanks, Just Enough Software Architecture: A Risk-Driven Approach, 1st ed. Marshall & Brainerd, 2010, p.376.66 javiergs@acm.org
  67. 67. Trabajo en Equipo Práctica en Equipo ¿Cuál  es  tu   enfoque?  67
  68. 68. Aplicaciónen la Práctica javiergs@acm.org
  69. 69. RUP69 javiergs@acm.org
  70. 70. Fundamento Necesidad Notación requerimientos modelos Proceso (diagramas) metodología Herramientas Producto70 javiergs@acm.org
  71. 71. Ciclo de Vida Flujos de trabajo fases del proceso Iniciación Elaboración Construcción Transición Modelado del negocio Requisitos Análisis y diseño Implementación Pruebas Despliegue Flujos de trabajo de soporte Gestión del cambio y configuraciones Gestión del proyecto Entorno Iteraciones Iter Iter Iter Iter Iter Iter Iter preliminares #1 #2 #n #n+1 #n+2 #m #m+1 Fuente: Jacobson et al., 200071 javiergs@acm.org
  72. 72. DiagramasLos diagramas expresan gráficamente partes de un modelo desde cierta perspectiva State State Diagrams de Use Case Diagramas Diagrams Use Case Diagrams de Clases State Use Case Diagramas Diagrams State Use Case Diagrams de Diagramas Diagrams de Diagramas Casos de Uso Diagrams Diagrams Objetos Secuencia Scenario State Scenario Diagrams de State Diagrams de Diagramas Diagrams Diagramas Diagrams Colaboración Componentes Modelo(s) Scenario Component Scenario Diagrams de Component Diagrams Diagramas de Diagramas Diagrams Diagrams Estados Distribución Diagramas de Actividad Estáticos Dinámicos De Estructura De funcionalidad De arquitectura De Comportamiento 72 javiergs@acm.org
  73. 73. Relación Modelo de Casos de Uso verificado por especificado por realizado por Modelo de distribuido por Prueba Modelo de Análisis Modelo de implementado por Diseño Modelo de Despliegue Modelo de Implementación73 javiergs@acm.org
  74. 74. Agrupando Modelos Mode lo de l Mode lo de l Mode lo de Mode lo de Mode lo de Mode lo de Mode lo de Mode lo Mode lo de Ne gocio Dom inio Cas os de Anális is Dis e ño Proce s os De s plie gue Im ple m e n- Prue ba Us o tación Es t. Din. Es t. Din. Es t. Din. Es t. Din. Es t. Din. Es t. Din. Es t. Din. Es t. Din. Es t. Din. Diagram a de Cas os de Us o X X X Diagram a de Inte racción- X X X X X X X X Se cue ncia Diagram a de Inte racción- X X X X X X X X Colaboración Diagram a de Clas e s de X Anális is Diagram a de Obje tos de X Anális is Diagram a de Clas e s de X X Dis e ño Diagram a de Obje tos de X X Dis e ño Diagram a de Es tados X X X X X X Diagram a de Actividade s X X X X X Diagram a de Com pone nte s X Diagram a de De s plie gue X74 javiergs@acm.org
  75. 75. ModelandoS  Casos de UsoS  ClasesS  Actividades NombreS  Estados AtributosS  Secuencias MétodosS  ObjetosS  IEEE SRS75 javiergs@acm.org
  76. 76. OOSE UML Cada modelo es examinado o manipulado Construir modelos que representan al por un grupo de stakeholders sistema Objetos, tipos, clases código cambiante Sistemático modeloinformal Problema sistema real OO-SEcomplejo Requerimientos – Análisis – Diseño - Implementación -- Pruebas abstracto - iteraciones - concreto76 javiergs@acm.org
  77. 77. OOSE OO-SE Comportamiento, mensajes Características, estados objetos encapsulamiento transiciónModelan y codifican casos generalización/especialización (herencia) de uso relaciones asociación (objetos) dependencia (import) Generalización (herencia) de actores y casos paquetes código pruebas automáticas77 javiergs@acm.org
  78. 78. Trabajo en Equipo Práctica en Equipo78
  79. 79. Conclusiones yReferencias javiergs@acm.org
  80. 80. Resumen So-ware   Ingeniería  de   Programación   Arquitectura   So-ware   Metodologías   Modelo   Depenciencias   Comportamiento   Cualidades de Software80 javiergs@acm.org
  81. 81. Resumen Arquitectura   ¿Por  qué?   ¿Cuándo?   Enfoque   ¿Cómo?   Patrones  Model-­‐driven   Reuse-­‐driven   Risk-­‐driven   Es5lo   Modelo   Tác5ca   Cualitativo y Cuantitativo81 javiergs@acm.org
  82. 82. ReferenciasS  Software Architecture in Practice, Len Bass, Adisson Wesley 2003.S  Software Reuse: Architecture, Process and Organization for Business Success, Ivar Jacobson, ACM Press.S  Design Patterns, Head First, Eric Freeman & Elisabeth FreemanS  Just Enough Software Architecture, .  Marshall  &  Brainerd, George Fairbanks 82 javiergs@acm.org
  83. 83. Javier González Sánchez javiergs@acm.org www.javiergs.com83

×