Introduccin al modelado

1
Introducción al modelado

• Metodologías, UML y patrones de diseño

Ricardo Borillo Doménech borillo_at_si.uji.es
2
Índice

• Conceptos
• 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

3
Introducción a las metodologías
4
Componentes básicos

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

5
Modelado con UML
6
Qué es UML?

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

7
Qué es UML?

• 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.
• Este 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 (OOSE Object-Oriented
  Sotfware Engineering).

8
UML

• UML es un lenguaje de modelado que sirve para
  visualizar, especificar , construir y
  documentar un sistema software.
• Lenguaje de modelado
• Lenguaje cuyo vocabulario y reglas se centran
  en la representación conceptual y física de un
  sistema (Booch, Jacobson y Rumbaugh).

9
UML para visualizar

• Símbolos con semántica bien definida.
• UML transciende al lenguaje de programación.
• Modelo explícito, que facilita la comunicación.

10
UML para especificar

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

11
UML para construir

• Es posible hacer corresponder con los lenguajes
  de programación (Java, C, B.Datos, etc.).

Ingeniería Directa
ModeloUML
CÓDIGO
Ingeniería Inversa
12
UML para documentar

• UML cubre la documentación de un sistema
• Requisitos
• Arquitectura
• Diseño
• Código fuente
• Planificación
• Pruebas
• Prototipos
• Versiones

13
UML aglutina enfoques OO
Rumbaugh
Jacobson
Booch
Odell
Meyer
Pre- and Post-conditions
Shlaer-Mellor
UML
Object life cycles
Harel
State Charts
Gamma et. al.
Frameworks, patterns,
notes
Embly
Wirfs-Brock
Singleton classes
Responsabilities
Fusion
Operation descriptions,
message numbering
14
Historia de UML
15
Actualizaciones de UML

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

16
UML 2.0

• Arquitectura refinamiento del núcleo del
  estándar para que esté en consonancia con el
  resto de estándares del mercado.
• Personalización mejora de los mecanismos de
  extensibilidad y personalización.
• Componentes mejor soporte para el desarrollo
  basado en componentes (CORBA, EJB, COM).
• Mecanismos generales 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).

17
Modelos y Diagramas

• Un proceso de desarrollo de software debe ofrecer
  un conjunto de modelos que permitan expresar el
  producto desde cada una de las perspectivas de
  interés
• El código fuente del sistema es el modelo más
  detallado del sistema (y además es ejecutable).
  Sin embargo, se requieren otros modelos ...
• Cada modelo es completo desde su punto de vista
  del sistema, sin embargo, existen relaciones de
  trazabilidad entre los diferentes modelos

18
Modelos y Diagramas

• Modelo captura una vista de un sistema del mundo
  real. Es una abstracción de dicho sistema,
  considerando un cierto propósito.
• Diagrama representación gráfica de una colección
  de elementos de modelado, a menudo dibujada como
  un grafo con vértices conectados por arcos.

19
Organización de Modelos
20
Diagramas de UML
21
Mecanismos comunes en UML

• Especificaciones. Es 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 Comunes Clase/Objecto o
  Interfaz/Implementación.
• Extensibilidad. Estereotipos, valores etiquetados
  o restricciones.

22
Mecanismos comunes en UML
23
Casos de Uso
24
Casos de Usos

• Un diagrama de Casos 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).
• Es una herramienta esencial para la captura de
  requerimientos y para la planificación y control
  de un proyecto interactivo.

25
Casos de Usos

• Los casos de Uso Se representa en el diagrama por
  una elipse que denota un requerimiento
  solucionando por el sistema.
• Cada caso de uso de uso es una operación completa
  desarrollada por los actores y por el sistema en
  un diálogo.
• El conjunto de casos de uso representa la
  totalidad de operaciones desarrolladas por el
  sistema.

26
Casos de Usos
27
Casos de Usos

• Actor Es 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.

28
Casos de Usos

• También se puede encontrar tres tipos de
  relaciones, como son
• Comunica (comunicates) Entre un actor y un caso
  de uso, denota la participación del actor en el
  caso de uso determinado.

29
Casos de Usos

• Usa (uses) 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.

30
Casos de Usos

• Extiende (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.

31
Casos de Usos

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

32
Diagrama de Clases
33
Conceptos básicos orientación a objetos

• Clase
• Objeto
• Herencia
• Interfaz
• Polimorfismo de clases
• Clases y atributos estáticos
• Clases y atributos finales
• Clases y métodos abstractos

34
Diagrama de clases

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

35
Diagrama de clases

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

36
Diagrama de clases

• Clase 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.
• En UML la clase está representada por un
  rectángulo con tres divisiones internas, son los
  elementos fundamentales del diagrama.

37
Diagrama de clases

• Atributo Representa una propiedad de una
  entidad. Cada atributo de un objeto tiene un
  valor que pertenece a un dominio de valores
  determinado.
• Las sintaxis de una atributo es
• Visibilidad ltnombregt tipo valor propiedades
  
• Donde visibilidad es uno de los siguientes
• público.
• protegido.
• - privado. 

38
Diagrama de clases

• Operación El conjunto de operaciones que
  describen el comportamiento de los objetos de una
  clase. La sintaxis de una operación en UML es
• Visibilidad nombre (lista de parámetros) tipo
  que retorna propiedades

39
Diagrama de clases
40
Diagrama de clases

• Responsabilidades Contrato u obligación de una
  clase, asignada en el momento del diseño.
• Clase Producto
• Registrar el código de la publicación.
• Mantener estructura del producto plantilla.

41
Diagrama de clases

• Técnicas de modelado
• 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.

42
Diagrama de clases

• Objeto 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.
• Asociación (rol, multiplicidad, calificador)
  representan las relaciones entre instancias de
  clase. Una asociación es una línea que une dos o
  más clases.

43
Diagrama de clases

• Nombre Identifica la asociación entre los
  objetos, caracterizándola.
• Rol Identificado como un nombre a los finales
  de la línea, describe la semántica de la relación
  en el sentido indicado. Cada asociación tiene dos
  roles cada rol es una dirección en la
  asociación. El rol puede estar representado en el
  nombre de la clase.

44
Diagrama de clases

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

45
Diagrama de clases

• Dependencia Es 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.

46
Diagrama de clases
47
Diagrama de clases

• Los tipos de asociaciones entre clases presentes
  en un diagrama estático son
• Asociación binaria.
• Asociación n-aria.
• Composición.
• Generalización.
• Refinamiento.

48
Diagrama de clases

• Asociación Binaria 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.
• Asociación n-aria Es 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.

49
Diagrama de clases
50
Diagrama de clases

• Composición Es una asociación fuerte que
  implica
• Dependencia existencial. El 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.

51
Diagrama de clases

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

52
Diagrama de clases
53
Diagrama de clases

• Agregación Relaciona una clase ya ensamblada con
  una clase componente. Es 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.

54
Diagrama de clases
55
Diagrama de clases

• Generalización 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.

56
Diagrama de clases
57
Diagrama de clases

• Refinamiento Es 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.

58
Diagrama de clases
59
Diagrama de clases

• Técnicas de modelado
• Modelado de dependencias simples.
• Modelado de herencia simple.
• Modelado de relaciones estructurales
  (composiciones y agregaciones).
• Modelado de comentarios.

60
Diagrama de clases
61
Diagrama de Interacción
62
Diagrama de interacción

• Estos 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
  diagramas de secuencia y diagramas de
  colaboración.

63
Diagrama 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. Esta 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.

64
Diagrama de interacción

• Elementos básicos del diagrama de interacción
• Objetos o actores para cada entidad.
• Enlaces entre los objetos.
• Procedimientos a invocar entre los objetos.
• Mensajes entre los objetos.

65
Diagrama de interacción

• Un objeto se representa como una línea vertical
  punteada (línea de vida), con un rectángulo de
  encabezado y con rectángulo a través de la línea
  principal que denotan la activación, es decir, el
  período de tiempo en el cual el objeto se
  encuentra desarrollando alguna operación.
• El rectángulo de encabezado contiene el nombre
  del objeto y el de su clase, en un formato
  nombreObjeto nombreClase. El 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.

66
Diagrama de interacción
67
Diagrama de interacción

• Diagramas de Colaboración
• Es 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.

68
Diagrama de interacción
69
Diagrama de interacción

• Técnicas de modelado
• 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).

70
Diagrama de Estados
71
Diagrama de estados

• Diagrama de Estados
• 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. Esta representado principalmente por los
  siguientes elementos
• Estado.
• Elemento.
• Transición.

72
Diagrama de estados

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

73
Diagrama de estados

• Partes que componen un estado
• Nombre
• Acciones de entrada y de salida.
• Transiciones internas.
• Subestados.
• Eventos diferidos.
  
  
  
  
  

74
Diagrama de estados

• Eventos Es una ocurrencia que puede causar la
  transición de un estado a otro de un objeto.
  Esta, puede ser una
• Condició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.

75
Diagrama de estados

• Transición Es una relación entre estados de un
  fuente a un destino.
• Partes que componen una transición
• Estado de origen.
• Evento de disparo.
• Condición de guarda.
• Acción.
• Estado de destino.

76
Diagrama de estados

• Otros elementos
• Subestados. Secuenciales o no, resultan en una
  nueva máquina de estados.
• Estados de historia.
• Estados 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.

77
Diagrama de estados
78
Diagrama de estados

• Técnicas de modelado
• Modelado de la vida de un objeto. Este tipo de
  diagramas se asocian directamente a una clase.

79
Diagrama de Actividades
80
Diagrama de Actividades

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

81
Diagrama de Actividades

• Sirven para representar transiciones internas,
  sin hacer mucho énfasis en transiciones o eventos
  externos.
• Los elementos que conforman el diagrama son
• Acción
• Transición.
• Objetos

82
Diagrama de Actividades

• Estado de Acción 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.

83
Diagrama de Actividades

• Estado de Actividad Estado 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.

84
Diagrama de Actividades

• Casos especiales
• Estado inicial. Representa el punto de entrada
  del diagrama de actividades.
• Estado final. Su existencia depende de si el
  diagrama es cíclico.
• Ítem de decisión. Representado con un rombo,
  permite tomar bifurcaciones condicionales.

85
Diagrama de Actividades

• Casos especiales
• Carriles 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.

86
Diagrama de Actividades

• Transición Es 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.

87
Diagrama de Actividades

• Tipos de transiciones
• 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.

88
Diagrama de Actividades
89
Diagrama de interacción

• Técnicas de modelado
• 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.

90
Diagrama de Componentes
91
Diagrama de componentes

• 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

92
Diagrama de componentes

• 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

93
Diagrama de componentes
94
Diagrama de componentes

• Técnicas de modelado
• 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.

95
Diagrama de Despliegue
96
Diagrama de despliegue

• 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

97
Diagrama de despliegue

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

98
Diagrama de despliegue

• Los nodos se interconectan mediante soportes
  bidireccionales que pueden a su vez
  estereotiparse.
• Esta vista permite determinar las consecuencias
  de la distribución y la asignación de recursos.

99
Diagrama de despliegue
100
Diagrama de despliegue
101
Diagrama de despliegue

• Técnicas de modelado
• Modelado de procesadores y dispositivos.
• Modelado de distribución de componentes.

102
RUP El Proceso Unificado de Rational
103
Proceso Unificado de Rational

• 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)

104
Casos de uso

• 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
• Casos de uso como el hilo conductor que orienta
  las actividades de desarrollo

Casos de Uso
ltltdefineNecesidadesgtgt
ltltverificagtgt
ltltrealizagtgt
Análisis Recopilar, Clarificar y Validar los
requerimientos
Diseño Realizar los casos de uso
Pruebas Verificar que se satisfacen los casos
de uso
105
Arquitectura

• Centrado en la arquitectura
• Concepto 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
• Casos de uso determinan la función del sistema

106
Modelo que implementa

• Iterativo e incremental
• Descomposición de un proyecto grande en
  mini-proyectos
• Cada mini-proyecto es una iteración
• Las iteraciones deben estar controladas
• Cada 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

107
Estructura

• Dinámica
• Ciclo cada ciclo una nueva versión del producto
• Fase Etapas de un ciclo que finalizan en un
  HITO
• Iteración Proceso de ingeniería sobre una
  funcionalidad limitada del sistema
• Estática - Flujos de trabajo
• Artefactos
• Actividades
• Roles

108
Estructura

• Roles QUIÉN?
• Actividades CÓMO?
• Artefactos QUÈ?
• Flujo de Trabajo CUÁNDO?

realiza
responsable de
diseño de caso de uso
diseñador
diagrama de secuencia
109
Roles

• Definición del comportamiento y responsabilidades
  de los participantes
• Propietario de una serie de artefactos

Recurso
Rol Actividad
Artefacto
Patricia Juan Mónica Pedro
Diseñador Diseño de Objetos
DC Analista Definición de CU
DCU Dominio Diseñador Diseño de CU
DS Funcional
110
Actividades

• 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
• Ejemplos de actividades
• Planear una iteración (administrador del
  proyecto)
• Encontrar caso de uso y actores (analista del
  dominio)
• Revisión del diseño (probador)

111
Artefactos

• 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 Clase rol tiene como métodos las
  actividades y como parámetros los artefactos

112
Flujos de trabajo

• Forma de describir significativamente la
  secuenciencias de actividades que producen
  resultados y las interacciones entre cargos
• En términos de UML se puede utilizar diagrama de
  actividades, de secuencia, de colaboración
• En 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

113
Dimensión dinámica
ciclo
fase
Concepción
Elaboración
Construcción
Transición
hito 1
hito 2
hito 3
hito 4
Iter. 1
Iter. 2
Iter. 3
Iter. 4
Iter. 5
Iter. 6
Hito punto en el tiempo en donde se evaluan
objetivos logrados y se pueden tomar decisiones
críticas
114
Desarrollo iterativo
Construcción
Ciclo de desarrollo 1
Ciclo de desarrollo 2
Ciclo de desarrollo n
Perfeccionar el plan
Sincronizar Artefactos
Análisis
Diseño
Construcción
Pruebas
115
Fase de concepción

• Objetivo definir la razón de ser y el alcance
  del proyecto. Estudio de oportunidad.
• Visión QUÉ PARA QUÉ CUÁNTO
• Actividades
• Especificación de los criterios de éxito del
  proyecto
• Definición de los requerimientos
• Estimación de los recursos necesarios
• Cronograma inicial de fases
• Artefactos
• Documento de definición del proyecto

116
Fase de elaboración

• 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

117
Fase de construcción

• Objetivo desarrollar el sistema a lo largo de
  una serie de iteraciones
• Actividades
• Análisis
• Diseño
• Codificación
• Pruebas (individuales, de integración)

118
XP eXtreme Programming
119
eXtreme Programming

• Es una metodología ágil
• Diseñada para entornos dinámicos
• Pensada para equipos pequeños (hasta 10
  programadores)
• Orientada fuertemente hacia la codificación
• Énfasis en la comunicación informal, verbal

120
Valores que fomenta XP

• Comunicación
• Simplicidad
• Retroalimentación
• Coraje

121
Roles

• Programador (Programmer)
• Responsable de decisiones técnicas
• Responsable de construir el sistema
• Sin distinción entre analistas, diseñadores o
  codificadores
• En XP, los programadores diseñan, programan y
  realizan las pruebas

• Jefe de Proyecto (Manager)
• Organiza y guía las reuniones
• Asegura condiciones adecuadas para el proyecto
• Cliente (Customer)
• Es parte del equipo
• Determina qué construir y cuándo
• Establece las pruebas funcionales

122
Roles

• Entrenador (Coach)
• Responsable del proceso
• Tiende a estar en un segundo plano a medida que
  el equipo madura

• Encargado de Pruebas (Tester)
• Ayuda al cliente con las pruebas funcionales
• Se asegura de que las pruebas funcionales se
  superan
• Rastreador (Tracker)
• Metric Man
• Observa sin molestar
• Conserva datos históricos

123
Captura de requisitos

• Historias del Usuario (User-Stories)
• Establecen 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

124
Planificación

• Planificación por entregas (releases)
• Se priorizan aquellas user-stories que el cliente
  selecciona porque son más importantes para el
  negocio
• Entregas
• Son lo más pequeñas posibles
• Se dividen en iteraciones (iteración 2 o 3
  semanas)
• Están compuestas por historias
• A cada programador se le asigna una tarea de la
  user-story

125
Programación

• La programación de tareas se realiza por parejas
• La pareja diseña, prueba, implementa e integra el
  código de la tarea
• Código dirigido por las pruebas
• Código modular, intentando refactorizar siempre
  que se pueda

126
Modelo de un proyecto
127
Prácticas

• El juego de la planificación
• Entregas pequeñas
• Metáfora
• Diseño simple
• Pruebas
• Refactoring

• Programación en parejas
• Propiedad colectiva
• Integración contínua
• Semana de 40 horas
• Cliente in situ
• Estándares de programación

128
El juego de la planificación

• Decisiones de negocio (cliente)
• Alcance ? Cuándo debe estar listo el producto
  para que sea valioso en producción?
• Prioridad ? Prioriza la incorporación de las
  user-stories
• Composición de entregas ? Qué se necesita para
  que el negocio sea mejor antes de tener el sw?
• Fechas de entrega ? Fechas cuando el software
  funcionando causaría una gran diferencia

129
El juego de la planificación

• Decisiones técnicas (programadores y otros)
• Estimaciones ? Cuánto tiempo tardará en
  implementarse una user-story?
• Consecuencias ? Tener en cuenta las consecuencias
  técnicas de determinadas decisiones de negocio
• Proceso ? Organización del proceso y el equipo
• Planificación detallada ? 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

130
Entregas pequeñas

• Cada entrega es lo más corta posible
• Contenga 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

131
Diseño simple

• Se diseña la cosa más simple que pueda
  funcionar
• Uso de tarjetas CRC
• Diseño 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 número de clases y métodos

132
Pruebas

• Las pruebas unitarias se escriben ANTES 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

133
NUnit

• Framework para pruebas unitarias
• Escritura de pruebas
• Ejecució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/

134
Ejemplo de un test en NUnit
135
Fallo en ejecución de los tests
136
Éxito en ejecución de los tests
137
Refactoring

• Refactorización Mejora del código
• Intentar eliminar complejidad
• Código duplicado ? Refactorización
• Se plantea su aplicación después de implementar
  cada user-story

138
C Refactoring

• 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/

139
Integración con Visual Studio
140
Métricas de análisis del código
141
Refactoring con C Refactory
142
Programación en parejas

• Toda el código se escribe en parejas
• Se produce código de mayor calidad
• Extiende el conocimiento
• Se realiza el trabajo de 1 persona en casi la
  mitad del tiempo y mejor (cuestionable)

143
Propiedad colectiva

• Cualquiera 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 aquéllas en las que trabajan

144
Integración contínua

• El código se integra y se prueba después de pocas
  horas
• Existe una ordenador dedicado para la integración
• Cada pareja integra su código en dicho ordenador

145
Cliente in situ

• Cliente real Aquel que usará el sistema cuando
  esté en producción
• El cliente real debe estar con el equipo de
  trabajo
• Responder preguntas
• Resolver disputas
• Establecer prioridades
• Discutir mejoras

146
Estándares de programación

• Son fundamentales cuando los programadores
  cambian de pareja o hacen refactoring del código
  de otros
• Se consigue un código con el mismo estilo,
  homogéneo, legible

147
Patrones de diseño software
148
Definición

• Cada 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 (Christopher Alexander)
• Son soluciones reutilizables a problemas
  recurrentes que encontramos durante el desarrollo
  de software

149
Ventajas que ofrece el uso de patrones

• 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

150
Ventajas que ofrece el uso de patrones

• Capturan 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
• Estudiar 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

151
Componentes que constituyen un patrón

• Nombre
• Resumen o esencia de la solución
• Contexto al que se aplica
• Razones para utlizar o no el patrón
• Consideraciones de implementación
• Consecuencias e implicaciones de su uso
• Ejemplo de uso (Test Case)
• Patrones relacionados

152
Proceso de aplicación de patrones
Problema
Contexto
Fuerza
Solución
Beneficios
Consecuencias
Patrones relacionados
153
Clasificación de los patrones

• Fundamentales
• De creación
• De partición
• Estructurales
• De comportamiento
• De concurrencia

154
Fundamentales

• 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

155
Fundamentales

• Delegate
• Interface
• Abstract superclass
• Interface abstract class
• Immutable
• Proxy

156
De creación

• 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
• Estos patrones nos ayudan a estructurar y
  encapsular las decisiones

157
De creación

• Factory
• Builder
• Prototype
• Singleton
• Object pool

158
De partición

• 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

159
De partición

• Filter
• Composite
• Read-only interface

160
Estructurales

• Describen las formas más comunes en las que
  diferentes tipos de objetos pueden organizarse
  para trabajar conjuntamente

161
Estructurales

• Adapter
• Iterator
• Bridge
• Façade
• Flyweight
• Dynamic linkage
• Virtual proxy
• Decorator
• Cache management

162
De comportamiento

• Patrones utilizados para organizar, gestionar y
  combinar comportamiento

163
De comportamiento

• Chain of responsibility
• Command
• Little language
• Mediator
• Snapshot
• Observer
• State
• Null object
• Strategy
• Template method
• Visitor

164
De concurrencia

• Patrones para la coordinación de operaciones
  concurrentes y que permiten solucionar dos
  problemas principalmente
• Recursos compartidos
• Secuenciación de operaciones

165
De concurrencia

• Single threaded execution
• Lock object
• Guarded suspension
• Balking
• Scheduler
• Read/Write lock
• Producer-consumer
• Two-phase termination
• Double buffering
• Asynchronous processing
• Future

166
Arquitecturas dirigidas por modelos (MDA)
167
Introducción

• 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

168
PIM, PSM y transformaciones en MDA
Reglas de transformación
169
Ejemplos con MOF/XMI
170
Herramientas de apoyo al modelado
171
Herramientas de apoyo al modelado

• Herramientas comerciales generales
• Borland Together
• IBM Rational Suite
• Herramientas libres o con versiones básicas
  gratuitas
• Argo UML
• Poseidon
• Umbrello
• Eclipse UML2
• Eclipse Omondo
• Integración con los IDEs existentes

172
Ayuda a la generación de código

• Herramientas con soporte de ingeniería inversa
• Herramientas de generación en un solo sentido
• Herramientas de soporte MDA
• Together
• AndroMDA

173
Intercambio de metadatos

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