Este documento presenta una introducción al Rational Unified Process (RUP), patrones de software y su aplicación al área de proceso de Solución Técnica del modelo CMMi. Explica conceptos clave como arquitectura de software, patrones, diagramas UML y las fases del RUP. El objetivo es comprender cómo empatar las recomendaciones de CMMi TS y la adopción de RUP como metodología de desarrollo de software, integrando técnicas de arquitectura de software en RUP.

1. Rational Unified Process (RUP)
y Patrones de Software
aplicados a CMMi
Technical Solution
Javier González Sánchez
javiergs@acm.org
CIISA 2008

2. AGENDA
1. CMMi Technical Solution
2. Arquitectura de Software y Patrones
3. Rational Unified Process (RUP)
7. Caso y Actividades
8. Conclusiones y Referencias
2 javiergs@acm.org

3. CONTEXTO
CMMi RUP
TS
software
architecture
3 javiergs@acm.org

4. EXPECTACTIVAS
¿Qué esperas aprender en este taller ?
miscellaneous / client
developer
engineer
manager
¿Cuál es tu perfil?
4 javiergs@acm.org

5. CONOCIMIENTO PREVIO
Tú experiencia con:
CMMi
Procesos
Arquitectura de software… Ingeniería de software …
Diseño de componentes
Reuso
Patrones (diseño, arquitectura, código)
Arquitectura Model-drive
Arquitectura Reuse-drive
5 javiergs@acm.org

6. LA BATALLA
6 javiergs@acm.org

7. PRESENTACIÓN
Estudios y Certificaciones
Maestría en Ciencias Computacionales
CMU Certified Instructor Object-Oriented Design
IBM Mastering Object-Oriented Analysis and Design
IBM Mastering Requirements Managements
Experiencia
Arquitecto de Software / Líder de proyecto / Desarrollador
Consultor
Profesor
Director de programa académico
7 javiergs@acm.org

8. OBJETIVO
Comprender en toda su extensión el concepto de Solución Técnica desde la
perspectiva del modelo CMMi, así como los factores a considerar para cumplir
con los objetivos de esta área de proceso utilizando el Proceso Unificado de
Desarrollo (RUP) y los Patrones de Arquitectura y Diseño de Software
CMMi
RUP
+ TS + ARQ
=
"CÓMO" empatar las recomendaciones de CMMi TS y la adopción de RUP
como metodología de creación de software.
"CÓMO" integrar en RUP técnicas especificas de arquitectura de software
benéficas para la creación de productos.
8 javiergs@acm.org

9. CMMi
Technical Solution
javiergs@acm.org

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

11. 11 javiergs@acm.org

12. PROBLEMA
CMMi no es un proceso.
CMMi es un Modelo de Proceso.
Las practicas no se presentan en secuencia (aunque algunas veces lo
parece). Se deben realizar las practicas especificas (SP) en el orden que
tenga sentido para el negocio, y algunas veces incluso repetir SP.
12 javiergs@acm.org

13. RUP
13 javiergs@acm.org

14. 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:
Requerimientos
Restricciones de diseño
Evolución a futuro del producto
Productos comerciales disponibles
Cualidades del software
14 javiergs@acm.org

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

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

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

18. CMMi TS :: SP2.1
Desarrollar el diseño del producto o componentes
Diseño preliminar ó arquitectónico. Define los elementos estructurales
y de coordinación del producto o componente.
Considera cualidades deseables
Se debe evaluar el uso de productos comerciales o el reutilizar productos
existentes para los componentes del producto.
Considera el establecimiento de un framework que de soporte a familias
de productos.
Subpracticas: RUP y aplicación de patrones
18 javiergs@acm.org

19. CMMi TS :: SP2.2
Establecer el Paquete Técnico
Component
Modelos Diagrams
19 javiergs@acm.org

20. CMMi TS :: SP2.3
Diseñar las interfaces del producto y componentes en base a los
criterios establecidos
20 javiergs@acm.org

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

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

23. Práctica en Equipo
¿Cómo?
23 javiergs@acm.org

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

25. Antecedentes
Los “cambios” son mis amigos …
Necesidades
requerimientos
producto
25 javiergs@acm.org

26. El modelo LEGO
La “creatividad” es positiva …
… componentes
26 javiergs@acm.org

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

28. El arquitecto
Arquitectura de software
NO IMPLICA DETALLES DE IMPLEMENTACION
Arquitecto
Obtener Información del problema y diseñar solución que
satisfaga requerimiento (funcionales, no funcionales)
PERO
Apoyándose en patrones, modelos y Framework
ADEMAS DE
Participar activamente en el desarrollo. PERO no es un desarrollador
Generar lineamientos GENERALES a considerarse en la creación de
FAMILIAS de productos.
28 javiergs@acm.org

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

30. casas vs software
30 javiergs@acm.org

31. Conceptos
estilo arquitectónico
Orientada a eventos
SOA
tipo o clase de arquitectura
física
lógica
tecnológica
31 javiergs@acm.org

32. 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 son impresionantes y detalladas
naturaleza): Roca,
madera en la estructura interna y
clásico ventanales emplomados.
Fuego, Poder y Belleza
china
Gótico
32 javiergs@acm.org

33. Tipos
Aplicación o
física Datos
negocio
Clase o tipo
Estilos
arquitectónicos
arquitectura
componente patrón
reglas
33 javiergs@acm.org

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

35. Modelo de Aplicación
35 javiergs@acm.org

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

37. 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.
Patrones de Creación
Patrones Estructurales
Patrones de Comportamiento
37 javiergs@acm.org

38. Gang of Four
38 javiergs@acm.org

39. De Monitos a Código
39 javiergs@acm.org

40. Práctica en Equipo
40 javiergs@acm.org

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

42. 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 …
42 javiergs@acm.org

43. Observer
43 javiergs@acm.org

44. Facade
44 javiergs@acm.org

45. Decorator
45 javiergs@acm.org

46. Builder
46 javiergs@acm.org

47. Strategy
47 javiergs@acm.org

48. Composite
48 javiergs@acm.org

49. Memento
49 javiergs@acm.org

50. Chain of Responsability
50 javiergs@acm.org

51. Patrones con Patrones
51 javiergs@acm.org

52. Patrones de Arquitectura
Patrones de alto nivel, applicable 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
Blackboard
Interpreter
Rule-based
52 javiergs@acm.org

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

54. Práctica en Equipo
54 javiergs@acm.org

55. RUP:
Ingeniería de
software
orientado a
resuso
javiergs@acm.org

56. RUP
56 javiergs@acm.org

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

58. Ciclo de Vida
fases
Fuente: Jacobson et al., 2000
58 javiergs@acm.org

59. Diagramas
Los diagramas expresan gráficamente partes de un modelo desde cierta perspectiva
Diagramas de
Componentes
Modelo(s)
Estáticos
Dinámicos
De Estructura
De funcionalidad
De arquitectura
De Comportamiento
59 javiergs@acm.org

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

61. Agrupando Modelos
61 javiergs@acm.org

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

63. OOSE
UML
Cada modelos es examinado o
Construir modelos que representan al manipulado por un grupo de stakeholders
sistema
Objetos, tipos, clases
código
cambiante sistemático modelo
informal
Problema sistema
real
OO-SE
complejo
Requerimientos – Analisis – Diseño - Implementacion -- Pruebas
abstracto - iteraciones - concreto
63 javiergs@acm.org

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

65. Práctica en Equipo
65 javiergs@acm.org

66. Casos y
Actividad
Práctica
javiergs@acm.org

67. Práctica en Equipo
67 javiergs@acm.org

68. Conclusiones y
Referencias
javiergs@acm.org

69. AHORRO DE RECURSOS
69 javiergs@acm.org

70. CALIDAD
70 javiergs@acm.org

71. RUP es un BUFFET
71 javiergs@acm.org

72. REFERENCIAS
Software Architecture in Practice, Len Bass, Adisson Wesley 2003.
Software Reuse: Architecture, Process and Organization for
Business Success, Ivar Jacobson, ACM Press
Design Patterns, Head First, Eric Freeman & Elisabeth Freeman
CMMI Versión 1.1 SEI, 2002
72
javiergs@acm.org

73. Javier González Sánchez
javiergs@acm.org
/ in / javiergs
http://javiergs.com/ciisa2008
73