|


 


Metodologías, UML y
patrones de diseño

Ricardo Borillo Doménech

borillo@si.uji.es
 

¢ <onceptos
¢ Lenguajes de modelado: UML
¢ Metologías:
± Metologías clásicas: RUP, Métrica, MSF
± Metologías ágiles: eXtreme Programming
¢ Patrones de diseño de sofware
¢ Arquitecturas dirigidas por modelos (MDA)
¢ Herramientas de modelado
|


 


<
 

¢ RUP. Técnicas y su aplicación a la gestión

de proyectos software orientados a objeto.
¢ XP. Gestión ágil de proyectos y grupos de
desarrollo.
¢ UML. Diagramas, elementos notacionales y
semántica de los modelos generados.
2 
  2
Ã  2

¢ ñl UML modela sistema mediante el uso de objetos

que forman parte de él así como, las relaciones
estáticas o dinámicas que existen entre ellos.
¢ UML puede ser utilizado por cualquier metodología
de análisis y diseño orientada por objetos para
expresar los diseños.
Ã  2

¢ UML es un Lenguaje de Modelado Unificado basado en

una notación gráfica la cual permite: especificar,
construir, visualizar y documentar los objetos de un
sistema programado.
¢ ñste lenguaje es el resultado de la unificación de los
métodos de modelado orientados a objetos de Booch,
Rumbaugh (OMT: Object Modeling Technique) y
Jacobson (OOSñ: Object-Oriented Sotfware
ñngineering).
2

¢ UML es un lenguaje de modelado que sirve para

visualizar, especificar , construir y documentar un
sistema software.
Lenguaje de modelado:
©



 
 
 


 





  

(Booch,
Jacobson y Rumbaugh).
2 





¢ Símbolos con semántica bien definida.

¢ UML transciende al lenguaje de programación.
¢ Modelo explícito, que facilita la comunicación.
2 

 


¢ ñspecificar es equivalente a construir modelos que

cumplan las condiciones de no ambigüedad y
completitud.
¢ UML cubre la especificación del análisis, diseño e
implementación de un sistema software.
2 

 


¢ ñs posible hacer |
   

corresponder
con los 2

lenguajes de <

2
programación
(Java, < , |
 
| 
B.Datos, etc.).
2 





¢ UML cubre la documentación de un sistema:

± Requisitos
± Arquitectura
± Diseño
± <ódigo fuente
± Planificación
± Pruebas
± Prototipos
± Versiones
2 


   
Rumbaugh
Booch Jacobson

Odell
Meyer
Pre- and Post-conditions

Shlaer-Mellor 2
Object life cycles
Harel
State <harts
Gamma et. al.
Frameworks, patterns,
notes
ñmbly Wirfs-Brock
Singleton classes Responsabilities
Fusion
Operation descriptions,
message numbering
~

 2
M
 


M 
M
M

   
M

M 
]
 i

 
"


   2

¢ UML 1.3 es una versión madura de UML a la que se le han

añadido una serie de pequeñas revisiones, las cuales
corrigen o mejoran la especificación base (UML 1.2).
¢ UML 1.4 incorpora ciertas modificaciones sobre el estándar
en base a los comentarios recogidos de los usuarios finales
y de los fabricantes de software compatible con UML.
¢ UML 2.0 promete la puesta a punto del estándar para
poder integrarse con el desarrollo basado en componentes
que demanda el mercado.
2 
¢ "
: refinamiento del núcleo del estándar para que
esté en consonancia con el resto de estándares del mercado.
¢ ˜

 : mejora de los mecanismos de extensibilidad y
personalización.
¢ <



: mejor soporte para el desarrollo basado en
componentes (<ORBA, ñJB, <OM+).
¢ 2




: nuevos mecanimos para el control de
las versiones dentro del modelo, así como el intercambio de los
metadatos del mismo con XMI (XML Metadad Interchange).
2  !



 Un proceso de desarrollo de software debe ofrecer un conjunto
de modelos que permitan expresar el producto desde cada una
de las perspectivas de inters

 ñl c÷digo fuente del sistema es el modelo m s detallado del

sistema (y adem s es ejecutable). Sin embargo, se requieren
otros modelos ...
 <ada modelo es completo desde su punto de vista del sistema,
sin embargo, existen relaciones de trazabilidad entre los
diferentes modelos
2  !




¢ 2 " captura una vista de un sistema del mundo real. ñs una
abstracción de dicho sistema, considerando un cierto propósito.
¢ !


" representación gráfica de una colección de elementos
de modelado, a menudo dibujada como un grafo con vértices
conectados por arcos.


  2 

J

J

   ÷
J






J
 J


 


 
!


  2



  

   
   
   
    


     
   
  

  
  

 

 
  
      

     
     



 
 
!  
"

2 
   2

¢ ñspecificaciones. ñs más que un lenguaje

gráfico (semántica detrás de la notación).
¢ Adornos. Detalles sobre un clase, nivel de
acceso de sus métodos, notas.
¢ Divisiones <omunes: <lase/Objecto o
Interfaz/Implementación.
¢ ñxtensibilidad. ñstereotipos, valores
etiquetados o restricciones.
2 
   2
<
  
<
  

¢ Un diagrama de <asos de Uso muestra la distintas

operaciones que se esperan de una aplicación o
sistema y cómo se relaciona con su entorno (usuario
u otras aplicaciones).

¢ ñs una herramienta esencial para la captura de

requerimientos y para la planificación y control de un
proyecto interactivo.
<
  

¢ Los casos de Uso Se representa en el diagrama por

una elipse que denota un requerimiento
solucionando por el sistema.
¢ <ada caso de uso de uso es una operación
completa desarrollada por los actores y por el
sistema en un diálogo.
¢ ñl conjunto de casos de uso representa la totalidad
de operaciones desarrolladas por el sistema.
<
  
<
  

¢ "
" ñs un usuario del sistema, que necesita o

usa alguno de los casos de uso. Un usuario puede
jugar más de un rol. Un solo actor puede actuar en
muchos casos de uso; recíprocamente, un caso de
uso puede tener varios actores. Los actores no
necesitan ser humanos pueden ser sistemas
externos que necesitan alguna información del
sistema actual.
<
  

¢ También se puede encontrar tres tipos de

relaciones, como son:

± < 
(

) ñntre un actor y un
caso de uso, denota la participación del actor en
el caso de uso determinado.
<
  

¢ 
(
Relación entre dos casos de
uso, denota la inclusión del comportamiento
de un escenario en otro. Se utiliza cuando se
repite un caso de uso en dos o más casos
de uso separados. Frecuentemente no hay
actor asociado con el caso de uso común.
<
  

¢ #$
  %extends): Relación entre dos

casos, denota cuando un caso de uso es
una especialización de otro. Se usa cuando
se describe una variación sobre el normal
comportamiento.
<
  

¢ Técnicas comunes de modelado:

± Modelado del contexto del sistema (utilidad
similar a los DFD).
± Modelado de los requisitos de un sistema.
± Modelado del proceso de test y estrés del
sistema.
!


 <
 
<  
  


&


¢ <lase
¢ Objeto
¢ Herencia
¢ Interfaz
¢ Polimorfismo de clases
¢ <lases y atributos estáticos
¢ <lases y atributos finales
¢ <lases y métodos abstractos
!


 
 

¢ Un diagrama de clases o estructura estática muestra

el conjunto de clases y objeto importantes que
forman parte de un sistema, junto con las relaciones
existentes entre clases y objetos. Muestra de una
manera estática la estructura de información del
sistema y la visibilidad que tiene cada una de las
clases, dada por sus relaciones con los demás en el
modelo.
!


 
 

¢ Usos comunes del diagrama:

± Modelado del vocabulario del sistema.

± Modelado de colaboraciones simples.
± Modelado de un esquema lógico de base de
datos.
± Modelado de un conjunto de clases de test.
!


 
 

¢ <
 " representa un conjunto de entidades que
tienen en común propiedades, operaciones,
relaciones y semántica.
¢ Una clase es un constructor que define la estructura
y comportamiento de una colección de objeto
denominados instancia de la clase.
¢ ñn UML la clase está representada por un
rectángulo con tres divisiones internas, son los
elementos fundamentales del diagrama.
!


 
 

¢ "

" Representa una propiedad de una entidad.

<ada atributo de un objeto tiene un valor que pertenece
a un dominio de valores determinado.
¢ Las sintaxis de una atributo es:
± J  

 
 
 


!
¢ Donde visibilidad es uno de los siguientes:
± + público.
± protegido.
± - privado.
!


 
 

¢  
 " ñl conjunto de operaciones que
describen el comportamiento de los objetos de una
clase. La sintaxis de una operación en UML es:
¢ J  

"  
#

 




 


!
!


 
 

'  



"



2

!


 
 

¢ (  

 " <ontrato u obligación de una
clase, asignada en el momento del diseño.
¢ <lase Producto:
± Registrar el código de la publicación.
± Mantener estructura del producto plantilla.
!


 
 

¢ ) 
   
"
± Modelado del vocabulario de un sistema a partir de
las descripciones funcionales.
± Modelado de la distribución de responsabilidades en
un sistema.
± Modelado de cosas que no son software (hardware,
personas, etc).
± Modelado de tipos primitivos.
!


 
 

¢ &
" es una instancia de una clase. Se

caracteriza por tener una identidad única, un estado
definido por un conjunto de valores de atributos y un
comportamiento representado por sus operaciones y
métodos.

¢ "
 (rol, multiplicidad, calificador):
representan las relaciones entre instancias de clase.
Una asociación es una línea que une dos o más
clases.
!


 
 

¢ ' " Identifica la asociación entre los objetos,

caracterizándola.
¢ (" Identificado como un nombre a los finales de la
línea, describe la semántica de la relación en el sentido
indicado. <ada asociación tiene dos roles; cada rol es
una dirección en la asociación. ñl rol puede estar
representado en el nombre de la clase.
!


 
 

¢ 2

" Describe la cardinalidad de la
relación, es decir, cuanto objetos de esa clase
pueden participar en la relación dada. Tipos:
!


 
 

¢ !   
" ñs una relación donde existen entidades
independientes y otras dependientes, lo que implica que
cambiar el elemento independiente puede requerir
cambios en los dependientes. Se representa con una
línea punteada direccional, indicando el sentido de la
dependencia.
!


 
 
!


 
 

¢ Los tipos de asociaciones entre clases

presentes en un diagrama estático son:
± Asociación binaria.
± Asociación n-aria.
± <omposición.
± Generalización.
± Refinamiento.
!


 
 

¢ "
 *

" Representa una relación
sencilla entre dos clases, no muy fuerte (es decir,
no se exige dependencia existencial ni
encapsulamiento). Se indica como una línea sólida
que une dos clases.
¢ "
 +

" ñs una asociación entre tres o
más clases. Se representa como un diamante del
cual salen líneas de asociación a las clases.
!


 
 
!


 
 

¢ < " ñs una asociación fuerte que

implica:
± Dependencia existencial. ñl elemento
dependiente desaparece al destruirse el que lo
contiene y, si es de cardinalidad 1, es creado al
mismo tiempo.
± Hay una pertenencia fuerte. Se puede decir que
el objeto contenido es parte constitutiva y vital del
que lo contiene.
!


 
 

± Los objetivos contenidos no son compartidos, esto

es, no hacen parte del estado de otro objeto.

¢ Se denota dibujando un rombo del lado de la

clase que contiene a la otra en la relación.
!


 
 
!


 
 

¢ " 
 " Relaciona una clase ya
ensamblada con una clase componente. ñs
también una relación de composición menos
fuerte (no se exige dependencia existencial)
y se denota por un rombo sin rellenar en un
o de los extremos.
!


 
 
!


 
 

¢ , 

 " es un proceso de abstracción en el
cual un conjunto de clases existentes, que tienen
atributos y métodos comunes, es referido por una
clase genérica a un nivel mayor de abstracción. La
relación de generalización denota una relación de
herencia entre clases. Se representa dibujando un
triángulo sin rellenar en el lado de la superclase. La
subclase hereda todos los atributos y mensajes
descritos en la superclase.
!


 
 
!


 
 

¢ ( 

" ñs una relación que
representa la especificación completa de
algo que ya ha sido especificado con cierto
nivel de detalle. Por ejemplo, una clase del
diseño es un refinamiento de una clase de
análisis.
!


 
 
!


 
 

¢ ) 
   
"
± Modelado de dependencias simples.
± Modelado de herencia simple.
± Modelado de relaciones estructurales
(composiciones y agregaciones).
± Modelado de comentarios.
!


 
 
!


 |


!


 



¢ ñstos son modelos que describen como los

grupos de objetos que colaboran en algunos
ambientes. Por lo general, un diagrama de
interacción captura el comportamiento de un
único caso de uso.
¢ Hay dos tipos de diagramas de interacción:



    



 


 
!


 



¢ Un diagrama de secuencia muestra la interacción de

un conjunto de objetos de una aplicación a través
del tiempo. ñsta descripción es importante porque
puede dar detalle a los casos de uso, aclarándolos
al nivel de mensajes de los objetos existentes, como
también muestra el uso de los mensajes de las
clases diseñadas en el contexto de una operación.
!


 



¢ ñlementos básicos del diagrama de

interacción:
± Objetos o actores para cada entidad.
± ñnlaces entre los objetos.
± Procedimientos a invocar entre los objetos.
± Mensajes entre los objetos.
!


 


¢ Un objeto se representa como una línea vertical punteada
( 
 
$ con un rectángulo de encabezado y con
rectángulo a través de la línea principal que denotan la
$ es decir, el período de tiempo en el cual el objeto se
encuentra desarrollando alguna operación.
¢ ñl rectángulo de encabezado contiene el nombre del objeto y el
de su clase, en un formato 

%

 

< 
. ñl
envío de mensajes entre objetos se denotan mediante una
línea sólida dirigida, desde el objeto que emite el mensaje
hacia el objeto que lo ejecuta.
!


 


!


 



¢ !


  <

 "
± ñs una forma de representar interacción entre los objetos,
es decir, las relaciones entre ellos y la secuencia de los
mensajes de las iteraciones que están indicadas por un
número A diferencia de los diagramas de secuencia,
pueden mostrar el contexto de la operación (cuáles objetos
son atributos, cuáles temporales, etc) y ciclos en la
ejecución. Muestra como varios objetos colaboran en un
solo caso de uso.
!


 


!


 



¢ ) 
   
"
± Modelado dinámico del sistema.
± Implementación de un caso de uso en concreto para
cada diagrama.
± Modelado del flujo de control por ordenación temporal
(secuencia).
± Modelado del flujo de control por organización
(colaboración).
!


 #


!


 



¢ !


 #

"
± Muestra el conjunto de estado por los cuales
pasa un objeto durante su vida en una aplicación
junto con los cambios que permiten pasar de un
estado a otro. ñsta representado principalmente
por los siguientes elementos:
¢ ñstado.
¢ ñlemento.
¢ Transición.
!


 



¢ #

" Identifica un período de tiempo del objeto
(no instantáneo) en el cual el objeto esta esperando
alguna operación, tiene cierto estado característico o
puede recibir cierto tipo de estímulos.
!


 



¢ Partes que componen un estado:

± Nombre
± Acciones de entrada y de salida.
± Transiciones internas.
± Subestados.
± ñventos diferidos.
!


 



¢ #
" ñs una ocurrencia que puede causar la

transición de un estado a otro de un objeto. ñsta,
puede ser una:

± <ondición que toma el de verdadero o falso.

± Recepción de una señal de otro objeto en el modelo.
± Recepción de un mensaje.
± Paso de cierto período de tiempo, después de entrar al
estado o de cierta hora y fecha particular.
!


 



¢ )
 " ñs una relación entre estados de un
fuente a un destino.
¢ Partes que componen una transición:
± ñstado de origen.
± ñvento de disparo.
± <ondición de guarda.
± Acción.
± ñstado de destino.
!


 



¢ 
  
"
± Subestados. Secuenciales o no, resultan en una nueva
máquina de estados.
± ñstados de historia.
± ñstados de historia. Permiten a un conjunto de estados o
subestados de un objeto, recordar el estado que estaba
activo en su última ejecución. Si no existe historia, se
comenzaría por el estado inicial.
± Subestados concurrentes.
!


 


!


 



¢ ) 
   
"
± Modelado de la vida de un objeto. ñste tipo de
diagramas se asocian directamente a una clase.
!


 "

 
!


 "

 

¢ Un diagrama de actividades es un caso especial de

un diagrama de estados en el cual casi todos los
estados son estados de acción (identifican que
acción se ejecuta al esta en él ) y casi todas las
transiciones son enviadas al terminar la acción
ejecutada en el estado anterior.
¢ Generalmente modelan los pasos de un algoritmo y
puede dar detalle a un caso de uso, un objeto o un
mensaje en un objeto.
!


 "

 

¢ Sirven para representar transiciones internas, sin

hacer mucho énfasis en transiciones o eventos
externos.
¢ Los elementos que conforman el diagrama son:
± "
± )
 .
± &

!


 "

 

¢ #

  " " representa un estado
con acción interna, con lo menos una
transición que indica la culminación de la
acción (por medio de un evento implícito).
± Permite modular un paso dentro del algoritmo. Se
representan por un rectángulo con bordes
redondeados.
!


 "

 

¢ #

  "

" ñstado más general
que permite su descomposición en otro
diagrama de actividades interno, de nivel
más bajo.
± Su representación, en cuanto a la notación, es la
misma que el de Acción.
!


 "

 

¢ <
  
 "
± ñstado inicial. Representa el punto de entrada del
diagrama de actividades.
± ñstado final. Su existencia depende de si el
diagrama es cíclico.
± Ítem de decisión. Representado con un rombo,
permite tomar bifurcaciones condicionales.
!


 "

 

¢ <
  
 "
± <arriles o ³Swim Lanes´. Permiten acotar el área a
las cuales las actividades están asociadas
(departamentos, módulos del sistema, etc).
± Flujos con objetos. Hacer explícita la relación con una
entidad en concreto.
!


 "

 

¢ )
 " ñs la relación entre dos estados
y se encuentran unidos por flechas;
indicando que un objeto que está en el
primer estado realizará una acción
especificada y entrará en el segundo estado
cuando un evento implícito ocurra y unas
condiciones especificas sean satisfechas.
!


 "

 

¢ ) 

 "
± Bifurcaciones condicionales. Permiten tomar
distintos caminos dentro del diagrama en función
de una condición o ³guarda´.
± División y unión. Permiten representar el
paralelismo en la ejecución de actividades.
!


 "

 
!


 



¢ ) 
   
"
± Modelado de un flujo de trabajo o Workflow. Uso intensivo de
estados de actividad, swim lanes y bifurcaciones
condicionales.
± Modelado de una operación concreta que resulta muy
complicada. Uso intensivo de transiciones (simples o
paralelas) y de estados de acción.
!


 <

!


 


 Los diagramas de componentes describen los

elementos físicos reemplazables del sistema y
sus relaciones

 Muestran las opciones de realización

incluyendo código fuente, binario y ejecutable
!


 


 Los componentes representan todos los tipos de

elementos software que entran en la fabricación de
aplicaciones informáticas. Pueden ser simples
archivos, librerías, bibliotecas cargadas
dinámicamente, etc.

 Las relaciones de dependencia se utilizan en los

diagramas de componentes para indicar que un
componente utiliza los servicios ofrecidos por otro
componente
!


 

!


 


¢ ) 
   
"
± Modelado de ejecutables y bibliotecas.
± Modelado de tablas, archivos y documentos.
± Modelado y diseño de un API.
± Modelado del código fuente.
± Planificación de versiones ejecutables para su implementación
con Nant.
!


 !  
!


   

 Los diagramas de despliegue muestran la

disposición física de los distintos nodos que
componen un sistema y el reparto de los
componentes sobre dichos nodos
!


   
 La vista de despliegue representa la disposición de las
instancias de componentes de ejecución en instancias de
nodos conectados por enlaces de comunicación.
 Un nodo es un recurso de ejecución tal como
± Dispositivos
± Procesadores
± Memoria

 Los nodos se interconectan mediante soportes bidireccionales

que pueden a su vez estereotiparse.
!


   

¢ Los nodos se interconectan mediante

soportes bidireccionales que pueden a su
vez estereotiparse.
¢ ñsta vista permite determinar las
consecuencias de la distribución y la
asignación de recursos.
!


   
!


   
!


   

¢ ) 
   
"
± Modelado de procesadores y dispositivos.
± Modelado de distribución de componentes.
(-" # -   
  (



-   
  (




¢ Orígenes
± Modelo original Objectory definido por Ivan
Jacobson (1987)
± Rational Software compra la empresa de
Objectory (1995)
± Surge la primera versión de UML (1997)
± Se publica la primera versión del Proceso
Unificado de Rational - RUP (junio 1998)
<
  

¢ Dirigido por casos de uso

± Se centra en la funcionalidad que el sistema debe poseer para
satisfacer las necesidades de un usuario (persona, sistema
externo, dispositivo) que interactua con él
± <asos de uso como el hilo conductor que orienta las actividades de
desarrollo
<



DD    
DD  DD




 

 

<
  
 

 


 






 







"



¢ <entrado en la arquitectura
± <oncepto similar a la arquitectura de un edificio
¢ Varios planos con diferentes aspectos del edificio
¢ Tener una imagen completa del edificio antes que comience la construcción
± Arquitectura en software
¢ Diferentes vistas del sistema: estructural, funcional, dinámico, etc.
¢ Plataforma en la que va a operar
¢ Determina la forma del sistema
± Arquitectura: determina la forma del sistema
± <asos de uso: determinan la función del sistema
2    

¢ Iterativo e incremental
± Descomposición de un proyecto grande en mini-proyectos
± <ada mini-proyecto es una iteración
± Las iteraciones deben estar controladas
± <ada iteración trata un conjunto de casos de uso
¢ Ventajas del enfoque iterativo
± Detección temprana de riesgos
± Administración adecuada del cambio
± Mayor grado de reutilización
± Mayor experiencia para el grupo de desarrollo
#



Dinámica
¢ <iclo: cada ciclo una nueva versión del producto
¢ Fase: ñtapas de un ciclo que finalizan en un HITO
¢ Iteración: Proceso de ingeniería sobre una funcionalidad
limitada del sistema
ñstática - Flujos de trabajo
¢ Artefactos
¢ Actividades
¢ Roles
#



¢ Roles Ã

¢ Actividades <2%
¢ Artefactos à 
¢ Flujo de Trabajo < %

 

  
 



  


   

  
( 

¢ Definición del comportamiento y responsabilidades

de los participantes
¢ Propietario de una serie de artefactos

 
 
   

   
 
 
<

$  

  !<<

%! 
 
<"
 # 

"

 

¢ Unidad de trabajo que puede ejecutar un individuo en un rol

específico
¢ Tiene un propósito claro y se expresa en términos de actualizar
artefactos
¢ La granularidad de la actividad es generalmente de horas o
pocos días
¢ ñjemplos de actividades
± Planear una iteración (administrador del proyecto)
± ñncontrar caso de uso y actores (analista del dominio)
± Revisión del diseño (probador)
"




¢ Pieza de información producida, modificada y

utilizada en un proceso
¢ Productos tangibles del proyecto
¢ Utilizados por los roles como entrada para la
realización de sus actividades
¢ Resultado de las actividades realizadas por los roles
¢ Metamodelo: <lase rol tiene como métodos las
actividades y como parámetros los artefactos
Æ& 


&

¢ Forma de describir significativamente la secuenciencias

de actividades que producen resultados y las
interacciones entre cargos
¢ ñn términos de UML se puede utilizar: diagrama de
actividades, de secuencia, de colaboración
¢ ñn RUP hay nueve tipos de flujos de trabajo
± De ingeniería
¢ Negocio, Requerimiento, Análisis, Diseño, Pruebas, Liberación
± De soporte
¢ Administración del proyecto, Administración del cambio,
Ambiente
!   


 


<  ! &
 ! <
 ! ' 
 !

0* 0+ 0, 0-

()* ()+ (), ()- (). ()/

~ 
 




 

 
 

 


 

 
 
! 
 




<  

<
 <
 <




* 


+ 




   "  



  





 <
 ! 

Æ
    

¢ Objetivo: definir la razón de ser y el alcance del

proyecto. ñstudio de oportunidad.
± Visión = QUÉ + PARA QUÉ + <UÁNTO
¢ Actividades
± ñspecificación de los criterios de éxito del proyecto
± Definición de los requerimientos
± ñstimación de los recursos necesarios
± <ronograma inicial de fases
¢ Artefactos
± Documento de definición del proyecto
Æ
  



¢ Objetivo: establecer un plan de proyecto y una arquitectura

correcta del sistema
¢ Actividades
± Análisis del dominio del problema
± Definición de la arquitectura básica
± Análisis de riesgos
± Planificación del proyecto
¢ Artefactos
± Modelo del dominio
± Modelo de procesos
± Modelo funcional de alto nivel
± Arquitectura básica
Æ
   


¢ Objetivo: desarrollar el sistema a lo largo de

una serie de iteraciones
¢ Actividades
± Análisis
± Diseño
± <odificación
± Pruebas (individuales, de integración)
Ý-" Ý
  -
 
 Ý
  -
 

¢ ñs una metodolog@a gil

± Diseada para entornos din micos
± Pensada para equipos pequeos (hasta 10
programadores)
± Orientada fuertemente hacia la codificaci÷n

nfasis en la comunicaci÷n informal, verbal
J
   

Ý-

¢ <omunicaci÷n
¢ Simplicidad
¢ Retroalimentaci÷n
¢ <oraje
( 

¢ Programador "˜

 ¢ Jefe de Proyecto
± Responsable de decisiones "2

tcnicas ± Organiza y gu@a las
reuniones
± Responsable de construir el
± Asegura condiciones
sistema
adecuadas para el proyecto
± Sin distinci÷n entre analistas,
diseadores o codificadores
¢ <liente "<


± ñn XP, los programadores
disean, programan y realizan las ± ñs parte del equipo

pruebas ± Determina qu construir y

cu ndo
± ñstablece las pruebas
funcionales
( 

¢ ñncargado de ¢ ñntrenador "<

&
± Responsable del proceso
Pruebas (•

) ± Tiende a estar en un segundo
± Ayuda al cliente con las plano a medida que el equipo
pruebas funcionales madura
± Se asegura de que las
pruebas funcionales se
superan
¢ Rastreador (•'
)
± 2
2
± Observa sin molestar
± <onserva datos
hist÷ricos
<


  


¢ ~

   
 %i

g
± ñstablecen los requisitos del cliente
± Trozos de funcionalidad que aportan valor
± Se les asignan tareas de programaci÷n con un n de
horas de desarrollo
± Las establece el cliente
± Son la base para las pruebas funcionales
-

÷

¢ Planificaci÷n por entregas (


)

¢ Se priorizan aquellas user-stories que el cliente
selecciona porque son m s importantes para el negocio
¢ ñntregas:
± Son lo m s pequeas posibles
± Se dividen en iteraciones (iteraci÷n = 2 o 3 semanas)
± ñst n compuestas por historias
¢ A cada programador se le asigna una tarea de la user-
story
-

÷

¢ La programaci÷n de tareas se realiza por parejas

¢ La pareja disea, prueba, implementa e integra el

c÷digo de la tarea

¢ <÷digo dirigido por las pruebas

¢ <÷digo modular, intentando refactorizar siempre que

se pueda
2     

-



£   £
  ÷
   ÷ 

£ 
 
 £
   
£
   £  ÷ @
£ 
 
  £  

£

£   

£    £
 

  ÷
# &   


÷

¢ Decisiones de negocio (cliente):

± "
 º Ñ<u ndo debe estar listo el producto para que sea
valioso en producci÷n?
± -
 º Prioriza la incorporaci÷n de las user-stories
± <÷ 
 
 º ÑQu se necesita para que el
negocio sea mejor antes de tener el sw?
± Æ .
 
 
º Fechas cuando el software funcionando
causar@a una gran diferencia
# &   


÷

¢ Decisiones tcnicas (programadores y otros):

± #

  º Ñ<u nto tiempo tardar en implementarse una
user-story?
± <   
 º Tener en cuenta las consecuencias tcnicas
de determinadas decisiones de negocio
± -  º Organizaci÷n del proceso y el equipo
± -

÷ 



º Dentro de una entrega, qu
user-stories se realizan primero. Intentar trasladar los segmentos
de desarrollo m s arriesgados al principio, intentando respetar
las prioridades del negocio
#
 
   O


¢ <ada entrega es lo m s corta posible:

± <ontenga requisitos m s valiosos del sistema (b sicos)
± Reducen el riesgo º mayor retroalimentaci÷n desde el
cliente, y m s frecuente
¢ Minimizar el n de user-stories que componen una
entrega º No realizar user-stories a medias
! O 
¢ Se disea la cosa m s simple que pueda funcionar
¢ Uso de tarjetas <R<
¢ Diseo de software correcto, es aquel que:
± Supera todas las pruebas
± No tiene l÷gica duplicada
± Pone de manifiesto las intenciones importantes de los
programadores
± Tiene el m@nimo nmero de clases y mtodos
- 

¢ Las pruebas unitarias se escriben ANTñS que el
c÷digo
¢ Pruebas automatizadas
¢ Permiten el desarrollo de proyectos de forma r pida
y segura
¢ Pruebas unitarias º programadores
¢ Pruebas funcionales º cliente
¢ Resultado º Un programa cada vez m s seguro
' 

¢ Framework para pruebas unitarias

¢ ñscritura de pruebas
¢ ñjecución de pruebas
¢ Hacer un Assert de los resultados
¢ Mostrar los fallos o éxitos
¢ Mantener un código que pase los tests
¢ http://nunit.org/
#&   

' 

Æ
 &   


Ô$
 &   


( 

 

¢ Refactorizaci÷n = Mejora del c÷digo

¢ Intentar eliminar complejidad
¢ <÷digo duplicado º Refactorizaci÷n
¢ Se plantea su aplicaci÷n despus de implementar
cada user-story
< ( 

 

¢ Herramientas integradas con Visual Studio

¢ Simplifican la refactorización del código
¢ Métricas para el análisis del código
¢ http://www.xtreme-simplicity.net/
|

  J
 /

2

 
   
( 

   < ( 


-

÷ 
 &


¢ Toda el c÷digo se escribe en parejas

± Se produce c÷digo de mayor calidad
± ñxtiende el conocimiento

¢ Se realiza el trabajo de 1 persona en casi la mitad

del tiempo y mejor (cuestionable)
- 
  


¢ <ualquiera puede modificar el c÷digo en cualquier

momento º Se evitan cuellos de botella en la
codificaci÷n

¢ Todos asume las responsabilidades sobre el conjunto

del sistema

¢ Todos conocen algo sobre todas las partes y conocen

muy bien aqullas en las que trabajan
|

 
 

¢ ñl código se integra y se prueba después de pocas

horas
¢ ñxiste una ordenador dedicado para la integración
¢ <ada pareja integra su código en dicho ordenador
<
 


¢ <liente real = Aquel que usará el sistema cuando esté

en producción
¢ ñl cliente real debe estar con el equipo de trabajo:
± Responder preguntas
± Resolver disputas
± ñstablecer prioridades
± Discutir mejoras
#
 
   



¢ Son fundamentales cuando los programadores

cambian de pareja o hacen 

 del código de
otros
¢ Se consigue un código con el mismo estilo,
homogéneo, legible
-

    0 
1

!  

¢ ³<ada patrón describe un problema que ocurre una

y otra vez en nuestro ambiente, y luego describe el
núcleo de la solución a ese problema, de tal
manera que puedes usar esa solución un millón de
veces más, sin hacer jamás la misma cosa dos
veces´ (<&
&
"
(
)
¢ ³Son soluciones reutilizables a problemas
recurrentes que encontramos durante el desarrollo
de software´
J

&
       

 

¢ ³Diseñar código orientado a objetos es costoso, y

diseñar código orientado objetos reutilizable aún lo
es más´
¢ ³Los patrones permiten a los programadores
reconocer un problema e inmediatamente
determinar la solución sin tener que pararse a
analizar el problema primero´
¢ Permiten trabajar a un nivel de abstracción mayor
¢ Aumentan la productividad, la reutilización del
código y su consistencia
J

&
       

 

¢ <apturan la experiencia en diseño. Los patrones se

crean a partir de ejemplos prácticos de diseño
¢ Utilizar patrones de diseño es reutilizar la experiencia
adquirida diseñando
¢ ñstudiar los patrones existentes es una manera de
aprender cómo los ³expertos´ diseñan sistemas
¢ Los patrones definen un conjunto de términos que
forman un vocabulario con el que poder hablar de
diseño de software
<
   

 




¢ Nombre
¢ Resumen o esencia de la solución
¢ <ontexto al que se aplica
¢ Razones para utlizar o no el patrón
¢ <onsideraciones de implementación
¢ <onsecuencias e implicaciones de su uso
¢ ñjemplo de uso (Test <ase)
¢ Patrones relacionados
-  

  

 

˜


 


÷

     

˜ 

<

   

 

¢ Fundamentales
¢ De creación
¢ De partición
¢ ñstructurales
¢ De comportamiento
¢ De concurrencia
Æ 


 

¢ Son los patrones más básicos y

fundamentales:
± Muchos del resto de patrones utiliza al menos
uno de ellos
± Son tan básicos que muchas veces no se
mencionan dándolos por supuestos
Æ 


 

¢ Delegate
¢ Interface
¢ Abstract superclass
¢ Interface + abstract class
¢ Immutable
¢ Proxy
! 


¢ Provee de una guía de cómo crear objetos cuando

su creación precisa de la toma de decisiones:
± ³Las decisiones normalmente involucran la determinación
de forma dinámica de qué clase instanciar o a qué objeto
delegar la responsabilidad´
± ñstos patrones nos ayudan a estructurar y encapsular las
decisiones
! 


¢ Factory
¢ Builder
¢ Prototype
¢ Singleton
¢ Object pool
! 



¢ Siguen el paradigma de ³divide y vencerás´

± ³Nos proporcionan la guía de cómo particionar las
clases e interfaces para llegar a un buen diseño´
! 



¢ Filter
¢ <omposite
¢ Read-only interface
#


 

¢ ³Describen las formas más comunes en las

que diferentes tipos de objetos pueden
organizarse para trabajar conjuntamente´
#


 

¢ Adapter
¢ Iterator
¢ Bridge
¢ Façade
¢ Flyweight
¢ Dynamic linkage
¢ Virtual proxy
¢ Decorator
¢ <ache management
! 




¢ ³Patrones utilizados para organizar,

gestionar y combinar comportamiento´
! 




¢ <hain of responsibility
¢ <ommand
¢ Little language
¢ Mediator
¢ Snapshot
¢ Observer
¢ State
¢ Null object
¢ Strategy
¢ Template method
¢ Visitor
!   

¢ Patrones para la coordinación de

operaciones concurrentes y que permiten
solucionar dos problemas principalmente:
± Recursos compartidos
± Secuenciación de operaciones
!   

¢ Single threaded execution

¢ Lock object
¢ Guarded suspension
¢ Balking
¢ Scheduler
¢ Read/Write lock
¢ Producer-consumer
¢ Two-phase termination
¢ Double buffering
¢ Asynchronous processing
¢ Future
"


 
    %2!"g
|


¢ Nueva orientación de las actividades del OMG

¢ La base de todo son los modelos (ni su
implementación, ni la plataforma)
¢ Basado en el desarrollo de modelos
independientes de la plataforma (PIM)
¢ Define un segundo nivel en el que diseñamos para
una plataforma concreta pero de forma abstracta
(PSM)
¢ Definición de transformaciones de PIM a PSM
¢ Aunque la plataforma cambie, siempre
mantenemos el PIM
-|2 -/2


  2!"


     


˜ 


 ÷


   
  
˜  ˜ 
#&   2Æ Ý2|

%1%
2(%3 5%( 2"%3
D4
" t
C l r : tri
D<
4D <
4
r: I t r
5%( D4-D 4
E i : I t r
D&4+D &4
D 4

(1$
 :2"%3 5%('" 0 2"%3
7<


 D
&

89 7
 " 
9 2<
6

 9 6

 &9
8 &634
~ 


 
 
  

~ 


 
 
  


¢ Herramientas comerciales generales:

± Borland Together
± IBM Rational Suite
¢ Herramientas libres o con versiones básicas
gratuitas:
± Argo UML
± Poseidon
± Umbrello
± ñclipse UML2
± ñclipse Omondo
¢ Integración con los IDñs existentes
" 


 
  

¢ Herramientas con soporte de ingeniería inversa

¢ Herramientas de generación en un solo sentido
¢ Herramientas de soporte MDA:
± Together
± AndroMDA
|

  





¢ Formato XMI
¢ Importación y exportación a este formato por parte
de las herramientas
¢ Base para las transformaciones en MDA