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.

1. Arquitectura de Software:
Principios y Prácticas
Javier González Sánchez
javiergs@acm.org

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. Objetivo
S 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. Objetivo
S ¿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ónicas
4 javiergs@acm.org

5. Conocimiento Previo
¿Tienes experiencia con?
S CMMi
S Procesos
S Arquitectura de software… Ingeniería de software …
S Diseño de componentes
S Reuso
S Patrones (diseño, arquitectura, código)
S Enfoques: Model-driven, Reuse-driven, Risk-driven, Test-driven
5 javiergs@acm.org

6. Agenda
1. Introducción: Antecedentes, Conceptos, Contexto
2. Arquitecturas, Modelos y Patrones
3. [ Trabajo en Equipo ]
receso
1. [ Trabajo en Equipo ]
2. Enfoques
3. Aplicación en la Práctica (arquitectura + ingeniería)
4. Conclusiones y Referencias
6 javiergs@acm.org

7. Introducción
javiergs@acm.org

8. Antecedentes
javiergs@acm.org

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-2005
9 javiergs@acm.org

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. Antecedentes
S $250 billones de dólares en desarrollo de software en USA
S Costo promedio por proyecto $430,000 a $2,300,000 dólares
S 16% de los proyectos se completan a tiempo y en presupuesto
S Aunque en promedio sólo el 42% de los requerimientos originales son
implementados
S 31% de los proyectos se cancelan por problemas de calidad
S 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. Conceptos
javiergs@acm.org

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. Antecedentes
Los “cambios” son mis amigos …
Necesidades
Requerimientos
Producto
14 javiergs@acm.org

15. El modelo LEGO
La “creatividad” es positiva …
¡Verdaderos
Componentes!
… componentes
15 javiergs@acm.org

16. Arquitectura… y de software…
16 javiergs@acm.org

17. El Arquitecto
Arquitectura de software
S NO IMPLICA DETALLES DE IMPLEMENTACIÓN
Arquitecto
S Obtener información del problema y diseñar la solución que
S satisfaga requerimientos (funcionales, no funcionales)
PERO
Arquitecto
S Apoyándose en patrones, modelos y framework Ingeniero
Obrero
ADEMÁS DE
S Participar activamente en el desarrollo, PERO no es un desarrollador
S Generar lineamientos GENERALES a considerarse en la creación de
FAMILIAS de productos
17 javiergs@acm.org

18. ¿Por qué una arquitectura?
construcción de la casa del perro construcción de una casa
S Una persona
S Estructura simple
S Proceso simple S Un equipo
S Herramientas simples S Modelado
S Procesos bien definidos
S Conocimiento teórico limitado S Herramientas poderosas
A medida que los sistemas crecen los algoritmos y las estructuras de datos dejan de ser el mayor
problema.
18 javiergs@acm.org

19. ¿Por qué una arquitectura?
Programador
=
Inmediato
Ingeniero
=
Corto
Plazo
Arquitecto
=
Largo
Plazo
19 javiergs@acm.org

20. Casas VS Software
20 javiergs@acm.org

21. Conceptos
S Estilo arquitectónico
Orientada a eventos
SOA
S Tipo o clase de arquitectura
Física
Lógica
Tecnológica
21 javiergs@acm.org

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ótico
22 javiergs@acm.org

23. Tipos
Aplicación o
Física Datos
Negocio
Clase o Tipo
Estilos
arquitectónicos
Arquitectura
Componente Patrón
Reglas
23 javiergs@acm.org

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. Modelo de Aplicación
25 javiergs@acm.org

26. Trabajo en Equipo
Componentes
Relaciones
Dependencias
Comportamiento
Cualidades
http://www.youtube.com/embed/zkPXzscJef4
26

27. Contexto: CMMi
javiergs@acm.org

28. Concepto
El área de proceso de Solución Técnica:
S Pertenece a la categoría de Ingeniería
S Es una de las 14 áreas de proceso en nivel 3
S Su propósito es diseñar, desarrollar e implementar (incluido el proceso
de pruebas) soluciones que satisfagan el conjunto de requerimientos
S Soluciones, diseños e implementaciones son parte de los productos,
componentes y procesos del área
S Productos o componentes
28 javiergs@acm.org

29. Ingeniería
29 javiergs@acm.org

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 software
30 javiergs@acm.org

31. CMMi TS :: SP1.1
Desarrollar alternativas de solución y criterios de selección
S Identificar y analizar diversas soluciones alternas
S Las alternativas de solución estarán basadas en arquitecturas propuestas
que cumplan con las características críticas del producto
S Las alternativas de solución caerán dentro de márgenes aceptables de
costos, calendario y desempeño
31 javiergs@acm.org

32. CMMi TS :: SP1.2
Seleccionar las soluciones para los componentes del producto que
mejor satisfagan los criterios establecidos
S Establecer los requerimientos asociados al conjunto de soluciones, como
los requerimientos asignados a los componentes asociados con dicho
conjunto de soluciones
S Identificar las soluciones que serán reutilizadas o compradas
S Establecer y mantener la documentación de las soluciones, su evaluación
y razones de selección o rechazo
32 javiergs@acm.org

33. CMMi TS :: SG2
El diseño del producto o componentes debe incluir información para su
implementación y demás fases del ciclo de vida del producto como son
la instalación y mantenimiento. Además, la documentación del diseño
provee una referencia que soporta el entendimiento del diseño con los
agentes relevantes.
33 javiergs@acm.org

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 patrones
34 javiergs@acm.org

35. CMMi TS :: SP2.2
Establecer 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. CMMi TS :: SP2.3
Diseñar las interfaces del producto y componentes en base a los
criterios establecidos.
36 javiergs@acm.org

37. CMMi TS :: SP2.4
Evaluar, en base a criterios establecidos, si los componentes se
desarrollarán, comprarán o reutilizarán
S 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 refinando
S Patrones y anti patrones
37 javiergs@acm.org

38. CMMi TS :: SG3
Implementación del diseño del producto
S CMMi TS :: SP3.1 Implementar (incluye pruebas)
S CMMi TS :: SP3.2 Documentar
S Hablemos de Trazabilidad
38 javiergs@acm.org

39. Arquitecturas,
Modelos y
Patrones
javiergs@acm.org

40. Idioms
S Patrón de bajo nivel
S Soluciona problemas específicos de implementación en un lenguaje de
programación
S Describe cómo implementar componentes o relaciones aplicando el
lenguaje
Ejemplos:
S Convenciones de nombres
S Formato para el código fuente
S Manejo de memoria
S Etc.
40 javiergs@acm.org

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 Comportamiento
41 javiergs@acm.org

42. Gang of Four
42 javiergs@acm.org

43. Ensamble
a) Relaciones
b) Mini-componentes incluyentes
c) Autonomía
d) Estándar
e) El “cambio” es mi amigo
f) Creatividad
g) Producto predecible
43 javiergs@acm.org

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. Observer
45 javiergs@acm.org

46. Facade
46 javiergs@acm.org

47. Decorator
47 javiergs@acm.org

48. Builder
48 javiergs@acm.org

49. Strategy
49 javiergs@acm.org

50. Composite
50 javiergs@acm.org

51. Memento
51 javiergs@acm.org

52. Chain of Responsability
52 javiergs@acm.org

53. Patrones con Patrones
53 javiergs@acm.org

54. Patrones de Arquitectura
Patrones de alto nivel, aplicables a la especificación fundamental del sistema
de software
Ejemplos:
Ÿ Distributed Ÿ Layered
Ÿ Event-driven Ÿ MVC
Ÿ Frame-based Ÿ IR-centric
Ÿ Batch Ÿ Subsumption
Ÿ Pipes and filters Ÿ Disposable
Ÿ Repository-centric Ÿ Publisher-subscriber
Ÿ Blackboard
Ÿ Interpreter
Ÿ Rule-based
54 javiergs@acm.org

55. Blackboard
D. Garlan and M. Shaw, “An introduction to software architecture,” Advances in software engineering and knowledge
engineering, vol. 1, pp. 1–40, 1993.
55 javiergs@acm.org

56. Layered
D. Garlan and M. Shaw, “An introduction to software architecture,” Advances in software engineering and knowledge
engineering, vol. 1, pp. 1–40, 1993.
56 javiergs@acm.org

57. Pipes and Filters
D. Garlan and M. Shaw, “An introduction to software architecture,” Advances in software engineering and knowledge
engineering, vol. 1, pp. 1–40, 1993.
57 javiergs@acm.org

58. Antipatrones
Antipatrones aplicados en desarrollo
S Lava Flow
S Spaghetti code
S Poltergeists: muchas clases
S God class: the blob
S Golden Hammer
Aplicados a la arquitectura
S Reinventando la rueda
S Stovepipeline System
S Stovepipeline Enterprise
S Vendor Lock-in
Aplicados a la gestión
S Mythical Man Month
S Death March Project
S Analysis paralysis
S Corncob
58 javiergs@acm.org

59. Trabajo en Equipo
Práctica en Equipo
Es5lo
Arquitectónico
Patrones
de
Diseño
Cualidades
¿Cómo?
59

60. Trabajo en Equipo
¿Cuánto cuesta?
¿Cuánto tiempo?
¿Cuántas LOC?
60 javiergs@acm.org

61. COnstructive COst MOdel
http://sunset.usc.edu/research/COCOMOII/cocomo81_pgm/cocomo81.html
61 javiergs@acm.org

62. La Batalla
DISEÑO VS IMPLEMENTACIóN
COMPONENTES VS LOC
62 javiergs@acm.org

63. Enfoques
javiergs@acm.org

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 rendimiento
64 javiergs@acm.org

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 funcionalidades
65 javiergs@acm.org

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 evaluar
G. H. Fairbanks, Just Enough Software Architecture: A Risk-Driven Approach, 1st ed. Marshall & Brainerd, 2010, p.
376.
66 javiergs@acm.org

67. Trabajo en Equipo
Práctica en Equipo
¿Cuál
es
tu
enfoque?
67

68. Aplicación
en la Práctica
javiergs@acm.org

69. RUP
69 javiergs@acm.org

70. Fundamento
Necesidad
Notación
requerimientos
modelos Proceso
(diagramas) metodología Herramientas
Producto
70 javiergs@acm.org

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., 2000
71 javiergs@acm.org

72. Diagramas
Los 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. 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ón
73 javiergs@acm.org

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 X
74 javiergs@acm.org

75. Modelando
S Casos de Uso
S Clases
S Actividades
Nombre
S Estados Atributos
S Secuencias Métodos
S Objetos
S IEEE SRS
75 javiergs@acm.org

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 modelo
informal
Problema sistema
real
OO-SE
complejo
Requerimientos – Análisis – Diseño - Implementación -- Pruebas
abstracto - iteraciones - concreto
76 javiergs@acm.org

77. OOSE
OO-SE
Comportamiento, mensajes
Características, estados
objetos encapsulamiento transición
Modelan 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áticas
77 javiergs@acm.org

78. Trabajo en Equipo
Práctica en Equipo
78

79. Conclusiones y
Referencias
javiergs@acm.org

80. Resumen
So-ware
Ingeniería
de
Programación
Arquitectura
So-ware
Metodologías
Modelo
Depenciencias
Comportamiento
Cualidades de Software
80 javiergs@acm.org

81. Resumen
Arquitectura
¿Por
qué?
¿Cuándo?
Enfoque
¿Cómo?
Patrones
Model-­‐driven
Reuse-­‐driven
Risk-­‐driven
Es5lo
Modelo
Tác5ca
Cualitativo y Cuantitativo
81 javiergs@acm.org

82. Referencias
S 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 Freeman
S Just Enough Software Architecture, .
Marshall
&
Brainerd, George
Fairbanks
82
javiergs@acm.org

83. Javier González Sánchez
javiergs@acm.org
www.javiergs.com
83