• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
201205 Arquitectura de Software
 

201205 Arquitectura de Software

on

  • 2,148 views

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

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.

Statistics

Views

Total Views
2,148
Views on SlideShare
1,741
Embed Views
407

Actions

Likes
6
Downloads
0
Comments
2

5 Embeds 407

http://javiergs.com 299
http://businessworldti.wordpress.com 105
http://helen.javiergs.com 1
http://www.linkedin.com 1
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

12 of 2 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    201205 Arquitectura de Software 201205 Arquitectura de Software Presentation Transcript

    • Arquitectura de Software: Principios y Prácticas Javier González Sánchez javiergs@acm.org
    • Expectativas ¿Qué esperas aprender en este taller ? líder de proyecto desarrollador ingeniero otro ¿Cuál es tu perfil?2 javiergs@acm.org
    • 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
    • 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
    • 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
    • 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
    • Introducción javiergs@acm.org
    • Antecedentes javiergs@acm.org
    • 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
    • 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
    • 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
    • Conceptos javiergs@acm.org
    • 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
    • Antecedentes Los “cambios” son mis amigos … Necesidades Requerimientos Producto14 javiergs@acm.org
    • El modelo LEGOLa “creatividad” es positiva … ¡Verdaderos   Componentes!   … componentes15 javiergs@acm.org
    • Arquitectura… y de software…16 javiergs@acm.org
    • 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
    • ¿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
    • ¿Por qué una arquitectura? Programador  =  Inmediato   Ingeniero  =  Corto  Plazo   Arquitecto  =  Largo  Plazo  19 javiergs@acm.org
    • Casas VS Software20 javiergs@acm.org
    • ConceptosS  Estilo arquitectónico Orientada a eventos SOAS  Tipo o clase de arquitectura Física Lógica Tecnológica21 javiergs@acm.org
    • 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
    • Tipos Aplicación o Física Datos Negocio Clase o Tipo Estilos arquitectónicos Arquitectura Componente Patrón Reglas23 javiergs@acm.org
    • 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
    • Modelo de Aplicación25 javiergs@acm.org
    • Trabajo en Equipo Componentes     Relaciones     Dependencias     Comportamiento     Cualidades  http://www.youtube.com/embed/zkPXzscJef426
    • Contexto: CMMi javiergs@acm.org
    • 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
    • Ingeniería29 javiergs@acm.org
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • CMMi TS :: SP2.3Diseñar las interfaces del producto y componentes en base a loscriterios establecidos.36 javiergs@acm.org
    • 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
    • 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
    • Arquitecturas,Modelos yPatrones javiergs@acm.org
    • 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
    • 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
    • Gang of Four42 javiergs@acm.org
    • 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
    • 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
    • Observer45 javiergs@acm.org
    • Facade46 javiergs@acm.org
    • Decorator47 javiergs@acm.org
    • Builder48 javiergs@acm.org
    • Strategy49 javiergs@acm.org
    • Composite50 javiergs@acm.org
    • Memento51 javiergs@acm.org
    • Chain of Responsability52 javiergs@acm.org
    • Patrones con Patrones53 javiergs@acm.org
    • 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
    • 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
    • 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
    • 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
    • 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
    • Trabajo en Equipo Práctica en Equipo Es5lo   Arquitectónico     Patrones   de  Diseño     Cualidades   ¿Cómo?59
    • Trabajo en Equipo¿Cuánto cuesta?¿Cuánto tiempo?¿Cuántas LOC?60 javiergs@acm.org
    • COnstructive COst MOdelhttp://sunset.usc.edu/research/COCOMOII/cocomo81_pgm/cocomo81.html61 javiergs@acm.org
    • La Batalla DISEÑO VS IMPLEMENTACIóN COMPONENTES VS LOC62 javiergs@acm.org
    • Enfoques javiergs@acm.org
    • 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
    • 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
    • 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
    • Trabajo en Equipo Práctica en Equipo ¿Cuál  es  tu   enfoque?  67
    • Aplicaciónen la Práctica javiergs@acm.org
    • RUP69 javiergs@acm.org
    • Fundamento Necesidad Notación requerimientos modelos Proceso (diagramas) metodología Herramientas Producto70 javiergs@acm.org
    • 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
    • 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
    • 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
    • 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
    • ModelandoS  Casos de UsoS  ClasesS  Actividades NombreS  Estados AtributosS  Secuencias MétodosS  ObjetosS  IEEE SRS75 javiergs@acm.org
    • 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
    • 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
    • Trabajo en Equipo Práctica en Equipo78
    • Conclusiones yReferencias javiergs@acm.org
    • Resumen So-ware   Ingeniería  de   Programación   Arquitectura   So-ware   Metodologías   Modelo   Depenciencias   Comportamiento   Cualidades de Software80 javiergs@acm.org
    • 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
    • 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
    • Javier González Sánchez javiergs@acm.org www.javiergs.com83