Rational Unified Process (RUP) y Patrones de Software aplicados a CMMi Technical Solution

Javier Gonzlez Snchez

javiergs@acm.org

CIISA 2008

AGENDA

1.

CMMi Technical Solution

2.

Arquitectura de Software y Patrones

3.

Rational Unified Process (RUP)

4.

Caso y Actividades

5.

Conclusiones y Referencias

javiergs@acm.org

CONTEXTO

CMMi TS

RUP

software architecture

javiergs@acm.org

EXPECTACTIVAS

Qu esperas aprender en este taller ?

developer

engineer

Cul es tu perfil?
4
javiergs@acm.org

manager

miscellaneous / client

CONOCIMIENTO PREVIO

T experiencia con:
S CMMi S Procesos S Arquitectura de software Ingeniera de software S Diseo de componentes S Reuso S Patrones (diseo, arquitectura, cdigo) S Arquitectura Model-drive S Arquitectura Reuse-drive

javiergs@acm.org

LA BATALLA

javiergs@acm.org

PRESENTACIN

Estudios y Certificaciones
S Maestra en Ciencias Computacionales S CMU Certified Instructor Object-Oriented Design S IBM Mastering Object-Oriented Analysis and Design S IBM Mastering Requirements Managements

Experiencia
S Arquitecto de Software / Lder de proyecto / Desarrollador S Consultor S Profesor S Director de programa acadmico

javiergs@acm.org

OBJETIVO

Comprender en toda su extensin el concepto de Solucin Tcnica 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 Diseo de Software

RUP

CMMi TS

ARQ

"CMO" empatar las recomendaciones de CMMi TS y la adopcin de RUP como metodologa de creacin de software. "CMO" integrar en RUP tcnicas especificas de arquitectura de software benficas para la creacin de productos.
8
javiergs@acm.org

CMMi Technical Solution

javiergs@acm.org

DEFINICIN

El rea de proceso de Solucin Tcnica :

S Pertenece a la categora de Ingeniera S Es una de las 14 reas de proceso en nivel 3 S Su propsito es disear, desarrollar e implementar (incluido el proceso de

pruebas) soluciones que satisfagan el conjunto de requerimientos.

S Soluciones, diseos e implementaciones son parte de los productos,

componentes y procesos del rea.

S Productos o componentes

10

javiergs@acm.org

11

javiergs@acm.org

PROBLEMA

S CMMi no es un proceso. S CMMi es un Modelo de Proceso. S 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

RUP

13

javiergs@acm.org

CMMi TS :: SG1

Seleccionar las Soluciones para Productos y Componentes El diseo de la solucin debe considerar la evaluacin de varias alternativas de solucin: arquitectura y modularizacin, desarrollo interno contra productos comerciales, etc. Estas decisiones deben fundamentarse en:
S Requerimientos S Restricciones de diseo S Evolucin a futuro del producto S Productos comerciales disponibles S Cualidades del software

14

javiergs@acm.org

CMMi TS :: SP1.1

Desarrollar alternativas de solucin y criterios de seleccin

S Identificar y analizar diversas soluciones alternas.

S Las alternativas de solucin estarn basadas en arquitecturas

propuestas que cumplan con las caractersticas crticas del producto.

S Las alternativas de solucin caern dentro de mrgenes aceptables de

costos, calendario y desempeo.

15

javiergs@acm.org

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 sern reutilizadas o compradas.

S Establecer y mantener la documentacin de las soluciones, su evaluacin

y razones de seleccin o rechazo.

16

javiergs@acm.org

CMMi TS :: SG2

El diseo del producto o componentes debe incluir informacin para su implementacin y dems fases del ciclo de vida del producto como son la instalacin y mantenimiento. Adems, la documentacin del diseo provee una referencia que soporta el entendimiento del diseo con los agentes relevantes.

17

javiergs@acm.org

CMMi TS :: SP2.1

Desarrollar el diseo del producto o componentes

S Diseo preliminar arquitectnico. Define los elementos estructurales

y de coordinacin 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. de productos.

S Considera el establecimiento de un framework que de soporte a familias S Subpracticas: RUP y aplicacin de patrones

18

javiergs@acm.org

CMMi TS :: SP2.2
Establecer el Paquete Tcnico

Use Case Use Case Diagrams Sequence Diagrams Diagrams

Use Case Use Case Diagrams Use Case Diagrams Diagrams

State State Diagrams Class Diagrams Diagrams

State State Diagrams Object Diagrams Diagrams

Scenario Scenario Diagrams Collaboration Diagrams Diagrams

Modelos

State State Diagrams Component Diagrams Diagrams

Scenario Scenario Diagrams Statechart Diagrams Diagrams

Activity Diagrams

Component Component Diagrams Deployment Diagrams Diagrams

19

javiergs@acm.org

CMMi TS :: SP2.3

Disear las interfaces del producto y componentes en base a los criterios establecidos

20

javiergs@acm.org

CMMi TS :: SP2.4

Evaluar, en base a criterios establecidos, si los componentes se desarrollarn, comprarn o reutilizarn S La decisin entre desarrollar, comprar o reutilizar comienza en los

primeros diseos y se completa a medida que los diseos se van detallando y refinando.

S Patrones y anti patrones

21

javiergs@acm.org

CMMi TS :: SG3

Implementacin del diseo del producto

S CMMi TS :: SP3.1 implementar (incluye pruebas) S CMMi TS :: SP3.2 Documentar S Hablemos de Trazabilidad

22

javiergs@acm.org

Prctica en Equipo

Cmo?

23

javiergs@acm.org

Arquitecturas, Modelos y Patrones

javiergs@acm.org

Antecedentes

Los cambios son mis amigos

Necesidades requerimientos producto

25

javiergs@acm.org

El modelo LEGO

La creatividad es positiva

componentes
26
javiergs@acm.org

Arquitectura y de software

27

javiergs@acm.org

El arquitecto
Arquitectura de software
S NO IMPLICA DETALLES DE IMPLEMENTACION

Arquitecto
S Obtener Informacin del problema y disear solucin que S satisfaga requerimiento (funcionales, no funcionales)

PERO
S Apoyndose en patrones, modelos y Framework

ADEMAS DE
S Participar activamente en el desarrollo. PERO no es un desarrollador S Generar lineamientos GENERALES a considerarse en la creacin de

FAMILIAS de productos.
28
javiergs@acm.org

Por qu una arquitectura?

construccin de una casa

construccin de la casa del perro

S S S S S

una persona estructura simple proceso simple herramientas simples Conocimiento terico limitado

S S S S

Un equipo Modelado Procesos bien definidos 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

casas vs software

30

javiergs@acm.org

Conceptos

S estilo arquitectnico

Orientada a eventos SOA

S tipo o clase de arquitectura

fsica lgica tecnolgica

31
javiergs@acm.org

Estilos

Arquitectura ?
Columnas:
maya

azteca?

Drico, Jnico, y Corintio

mayor detalle y elaboracin. Satisfacer a los dioses y a uno mismo (simetra y naturaleza):

Pirmides en ngulo perfecto y columnas de piedra

Egipto
Roca, madera en la estructura interna y ventanales emplomados. Fuego, Poder y Belleza grandes y extravagantes, un placer a la vista. azoteas son impresionantes y detalladas

clsico

china

Gtico

32

javiergs@acm.org

Tipos

fsica

Aplicacin o negocio

Datos

Clase o tipo Estilos arquitectnicos arquitectura

componente

patrn

reglas 33
javiergs@acm.org

Cualidades Arquitectnicas
Estticas: Modificabilidad, Portabilidad, Reusabilidad, Integrabilidad, Verificabilidad. Dinmicas: Desempeo, Disponibilidad, Funcionalidad, Usabilidad. Arquitectnicas: Integridad Conceptual, Correctitud, Completitud, Factibilidad econmica
34
javiergs@acm.org

Modelo de Aplicacin

35

javiergs@acm.org

Idioms

S Patrn de bajo nivel S Soluciona problemas especficos de implementacin en un lenguaje de

programacin
S Describe como implementar componentes o relaciones aplicando el

lenguaje Ejemplos:
S Convenciones de nombres S Formato para el cdigo fuente S Manejo de memoria S Etc.
36
javiergs@acm.org

Patrones de Diseo

Patrones de medio nivel, organizan la funcionalidad de subsistemas de manera independiente. Describe esquemas comunes de comunicacin entre componentes para la solucin de problemas generales en un contexto particular. Patrones de Creacin Patrones Estructurales Patrones de Comportamiento

S S S

37

javiergs@acm.org

Gang of Four

38

javiergs@acm.org

De Monitos a Cdigo

39

javiergs@acm.org

Prctica en Equipo

40

javiergs@acm.org

El modelo LEGO

a) Relaciones b) Mini-componentes incluyentes c) Autonoma d) Estndar e) El cambio es mi amigo f) Creatividad

g) Producto predecible
41
javiergs@acm.org

Hablando de Relaciones

a) Ser b) Usar c) Tener

a) Observar b) Encubrir a c) Decorar a d) Soy nico e) Yo construyo a f) Trabajar con

g) Soy parte de
42
javiergs@acm.org

Observer

43

javiergs@acm.org

Facade

44

javiergs@acm.org

Decorator

45

javiergs@acm.org

Builder

46

javiergs@acm.org

Strategy

47

javiergs@acm.org

Composite

48

javiergs@acm.org

Memento

49

javiergs@acm.org

Chain of Responsability

50

javiergs@acm.org

Patrones con Patrones

51

javiergs@acm.org

Patrones de Arquitectura

Patrones de alto nivel, applicable a la especificacin fundamental del sistema de software Ejemplos:

Distributed Event-driven Frame-based Batch Pipes and filters Repository-centric Blackboard Interpreter Rule-based

Layered MVC IR-centric Subsumption Disposable

52

javiergs@acm.org

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 gestin S Mythical Man Month S Death March Project S Analysis paralysis S Corncob
53
javiergs@acm.org

Prctica en Equipo

54

javiergs@acm.org

RUP: Ingeniera de software orientado a resuso

javiergs@acm.org

RUP

56

javiergs@acm.org

Fundamento Necesidad
requerimientos

Notacin

modelos (diagramas)

Proceso metodologa

Herramientas

Producto
57
javiergs@acm.org

Ciclo de Vida
fases
Iniciacin Elaboracin Construccin Transicin

Flujos de trabajo del proceso

Modelado del negocio Requisitos Anlisis y diseo Implementacin Pruebas Despliegue

Flujos de trabajo de soporte

Gestin del cambio y configuraciones Gestin del proyecto Entorno

Iteraciones preliminares
Fuente: Jacobson et al., 2000

Iter #1

Iter #2

Iter #n

Iter #n+1

Iter #n+2

Iter #m

Iter #m+1

58

javiergs@acm.org

Diagramas

Los diagramas expresan grficamente partes de un modelo desde cierta perspectiva

Use Case Use Case Diagrams Diagramas Diagrams de Casos de Uso State State Diagrams Diagramas Diagrams de Clases

Use Case Use Case Diagrams Diagramas Diagrams de Secuencia Scenario Scenario Diagrams Diagramas Diagrams de Colaboracin Scenario Scenario Diagrams Diagramas Diagrams de Estados
Dinmicos De funcionalidad De Comportamiento

State State Diagrams Diagramas Diagrams de Objetos

Modelo(s)

State State Diagrams Diagramas Diagrams de Componentes

Component Component Diagrams Diagramas Diagrams de

Diagramas de Actividad

Distribucin

Estticos De Estructura De arquitectura

javiergs@acm.org

59

Relacin

Modelo de Casos de Uso

verificado por

especificado por

realizado por distribuido por

Modelo de Prueba

Modelo de Anlisis

Modelo de Diseo Modelo de Despliegue

implementado por

Modelo de Implementacin

60

javiergs@acm.org

Agrupando Modelos
Mode lo de l Ne gocio Mode lo de l Dom inio Mode lo de Cas os de Us o Es t. Din. Mode lo de Anlis is Mode lo de Dis e o Mode lo de Proce s os Mode lo de De s plie gue Mode lo Im ple m e ntacin Es t. Din. Mode lo de Prue ba

Es t. Diagram a de Cas os de Us o Diagram a de Inte raccinSe cue ncia Diagram a de Inte raccinColaboracin Diagram a de Clas e s de Anlis is Diagram a de Obje tos de Anlis is Diagram a de Clas e s de Dis e o Diagram a de Obje tos de Dis e o Diagram a de Es tados Diagram a de Actividade s Diagram a de Com pone nte s Diagram a de De s plie gue

Din.

Es t.

Din.

Es t.

Din.

Es t.

Din.

Es t.

Din.

Es t.

Din.

Es t.

Din.

X X X X X

X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X

X X X

61

javiergs@acm.org

Modelando

S Casos de Uso S Clases S Actividades S Estados S Secuencias S Objetos

Nombre Atributos

Mtodos

S IEEE SRS
62
javiergs@acm.org

OOSE

UML
Construir modelos que representan al sistema Cada modelos es examinado o manipulado por un grupo de stakeholders

Objetos, tipos, clases cambiante informal Problema real complejo sistema sistemtico cdigo modelo

OO-SE

Requerimientos Analisis Diseo - Implementacion -- Pruebas abstracto iteraciones concreto

63

javiergs@acm.org

OOSE

Comportamiento, mensajes Caractersticas, estados

OO-SE
encapsulamiento transicin

objetos

Modelan y codifican

relaciones

generalizacin/especializacin (herencia) asociacin (objetos) dependencia (import)

casos de uso

Generalizacin (herencia) de actores y casos

paquetes cdigo
pruebas automticas

64

javiergs@acm.org

Prctica en Equipo

65

javiergs@acm.org

Casos y Actividad Prctica

javiergs@acm.org

Prctica en Equipo

67

javiergs@acm.org

Conclusiones y Referencias
javiergs@acm.org

AHORRO DE RECURSOS

69

javiergs@acm.org

CALIDAD

70

javiergs@acm.org

RUP es un BUFFET

71

javiergs@acm.org

REFERENCIAS

S S

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 Versin 1.1 SEI, 2002

S S

72
javiergs@acm.org

Javier Gonzlez Snchez javiergs@acm.org / in / javiergs http://javiergs.com/ciisa2008

73