Introducción al modelado

Metodologías, UML y patrones de diseño

Ricardo Borillo Doménech borillo@si.uji.es

Í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

Introducción a las metodologías

Gestión ágil de proyectos y grupos de desarrollo. Técnicas y su aplicación a la gestión de proyectos software orientados a objeto. XP.Componentes básicos    RUP. . elementos notacionales y semántica de los modelos generados. Diagramas. UML.

Modelado con UML .

. las relaciones estáticas o dinámicas que existen entre ellos.Qué es UML?   El UML modela sistema mediante el uso de objetos que forman parte de él así como. UML puede ser utilizado por cualquier metodología de análisis y diseño orientada por objetos para expresar los diseños.

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).Qué es UML?   UML es un Lenguaje de Modelado Unificado basado en una notación gráfica la cual permite: especificar. construir.

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

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.

UML para especificar   Especificar es equivalente a construir modelos que cumplan las condiciones de no ambigüedad y completitud. diseño e implementación de un sistema software. UML cubre la especificación del análisis. .

. B.Datos. C#.UML para construir  Es posible hacer Ingeniería Directa corresponder con los Modelo CÓDIGO lenguajes de UML programación Ingeniería Inversa (Java.). etc.

UML para documentar  UML cubre la documentación de un sistema: ± ± ± ± ± ± ± ± Requisitos Arquitectura Diseño Código fuente Planificación Pruebas Prototipos Versiones .

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

0 UML 1.3 Revisiones menores UML 1.4 UML 1.2 .Historia de UML 2001 2000 1999 1998 Nov ¶97 UML aprobado por el OMG UML 2.

UML 1.Actualizaciones de UML    UML 1. . UML 2.3 es una versión madura de UML a la que se le han añadido una serie de pequeñas revisiones.2).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.0 promete la puesta a punto del estándar para poder integrarse con el desarrollo basado en componentes que demanda el mercado. las cuales corrigen o mejoran la especificación base (UML 1.

0     Arquitectura: refinamiento del núcleo del estándar para que esté en consonancia con el resto de estándares del mercado.UML 2. . COM+). Personalización: mejora de los mecanismos de extensibilidad y personalización. Componentes: mejor soporte para el desarrollo basado en componentes (CORBA. Mecanismos generales: nuevos mecanimos para el control de las versiones dentro del modelo. EJB. así como el intercambio de los metadatos del mismo con XMI (XML Metadad Interchange).

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  

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. 

Organización de Modelos

Vista de Diseño Vista de los Casos de Uso Vista de Procesos

Vista de Implementación

Vista de Despliegue

Diagramas de UML Use Case Use Case Diagramas Diagrams de Diagrams Casos de Uso State State Diagramas Diagrams de Diagrams Clases Use Case Use Case Diagramas Diagrams de Diagrams Secuencia Scenario Scenario Diagramas Diagrams de Diagrams Colaboración State State Diagramas Diagrams de Diagrams Objetos State State Diagramas Diagrams de Diagrams Componentes Modelo Scenario Scenario Diagramas Diagrams de Diagrams Estados Component Component Diagrams Diagramas de Diagrams Diagramas de Actividad Distribución .

nivel de acceso de sus métodos.  Divisiones Comunes: Clase/Objecto o Interfaz/Implementación. Detalles sobre un clase. .  Adornos.Mecanismos comunes en UML  Especificaciones. notas. Estereotipos. valores etiquetados o restricciones.  Extensibilidad. Es más que un lenguaje gráfico (semántica detrás de la notación).

Mecanismos comunes en UML .

Casos de Uso .

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.

. 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.Casos de Usos    Los casos de Uso Se representa en el diagrama por una elipse que denota un requerimiento solucionando por el sistema.

Casos de Usos .

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

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

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

denota cuando un caso de uso es una especialización de otro.Casos de Usos  Extiende (extends): Relación entre dos casos. Se usa cuando se describe una variación sobre el normal comportamiento. .

. Modelado del proceso de test y estrés del sistema. Modelado de los requisitos de un sistema.Casos de Usos  Técnicas comunes de modelado: ± ± ± Modelado del contexto del sistema (utilidad similar a los DFD).

Diagrama de Clases

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

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.

Diagrama de clases  Usos comunes del diagrama: ± ± ± ± Modelado del vocabulario del sistema. Modelado de colaboraciones simples. Modelado de un conjunto de clases de test. . Modelado de un esquema lógico de base de datos.

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

. ± . ± # protegido. Las sintaxis de una atributo es: ± Visibilidad <nombre>: tipo = valor { propiedades} Donde visibilidad es uno de los siguientes: ± + público.privado. Cada atributo de un objeto tiene un valor que pertenece a un dominio de valores determinado.Diagrama de clases    Atributo: Representa una propiedad de una entidad.

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

Diagrama de clases Nombre de la clase Atributos Métodos .

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

etc).Diagrama de clases  Técnicas de modelado: ± Modelado del vocabulario de un sistema a partir de las descripciones funcionales. personas. . ± Modelado de la distribución de responsabilidades en un sistema. ± Modelado de tipos primitivos. ± Modelado de cosas que no son software (hardware.

multiplicidad. un estado definido por un conjunto de valores de atributos y un comportamiento representado por sus operaciones y métodos. Asociación (rol.  .Diagrama de clases  Objeto: es una instancia de una clase. Una asociación es una línea que une dos o más clases. calificador): representan las relaciones entre instancias de clase. Se caracteriza por tener una identidad única.

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

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

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.

Diagrama de clases .

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

. no se exige dependencia existencial ni encapsulamiento). Asociación n-aria: Es una asociación entre tres o más clases. Se indica como una línea sólida que une dos clases. Se representa como un diamante del cual salen líneas de asociación a las clases.Diagrama de clases   Asociación Binaria: Representa una relación sencilla entre dos clases. no muy fuerte (es decir.

Diagrama de clases .

es creado al mismo tiempo. Hay una pertenencia fuerte. si es de cardinalidad 1. El elemento dependiente desaparece al destruirse el que lo contiene y. .Diagrama de clases  Composición: Es una asociación fuerte que implica: ± ± Dependencia existencial. Se puede decir que el objeto contenido es parte constitutiva y vital del que lo contiene.

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. esto es.Diagrama de clases ± Los objetivos contenidos no son compartidos.

Diagrama de clases .

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

Diagrama de clases .

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

Diagrama de clases .

. una clase del diseño es un refinamiento de una clase de análisis.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.

Diagrama de clases .

± Modelado de comentarios. ± Modelado de herencia simple. ± Modelado de relaciones estructurales (composiciones y agregaciones).Diagrama de clases  Técnicas de modelado: ± Modelado de dependencias simples. .

Diagrama de clases .

Diagrama de Interacción .

Por lo general.Diagrama de interacción   Estos son modelos que describen como los grupos de objetos que colaboran en algunos ambientes. 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. .

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. Esta descripción es importante porque puede dar detalle a los casos de uso. .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.

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

El envío de mensajes entre objetos se denotan mediante una línea sólida dirigida. es decir. . con un rectángulo de encabezado y con rectángulo a través de la línea principal que denotan la activación. desde el objeto que emite el mensaje hacia el objeto que lo ejecuta.Diagrama de interacción   Un objeto se representa como una línea vertical punteada (línea de vida). El rectángulo de encabezado contiene el nombre del objeto y el de su clase. el período de tiempo en el cual el objeto se encuentra desarrollando alguna operación. en un formato nombreObjeto: nombreClase.

Diagrama de interacción .

Diagrama de interacción  Diagramas de Colaboración: ± Es una forma de representar interacción entre los objetos. es decir. Muestra como varios objetos colaboran en un solo caso de uso. . etc) y ciclos en la ejecución. 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. cuáles temporales. pueden mostrar el contexto de la operación (cuáles objetos son atributos.

Diagrama de interacción .

± Modelado del flujo de control por ordenación temporal (secuencia). ± Implementación de un caso de uso en concreto para cada diagrama. ± Modelado del flujo de control por organización (colaboración).Diagrama de interacción  Técnicas de modelado: ± Modelado dinámico del sistema. .

Diagrama de Estados .

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

tiene cierto estado característico o puede recibir cierto tipo de estímulos.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. .

. Transiciones internas.Diagrama de estados  Partes que componen un estado: ± ± ± ± ± Nombre Acciones de entrada y de salida. Eventos diferidos. Subestados.

. Recepción de una señal de otro objeto en el modelo. Recepción de un mensaje. Esta. Paso de cierto período de tiempo. después de entrar al estado o de cierta hora y fecha particular.Diagrama de estados  Eventos: Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. puede ser una: ± ± ± ± Condición que toma el de verdadero o falso.

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

Estados de historia. Si no existe historia. Subestados concurrentes. resultan en una nueva máquina de estados. Permiten a un conjunto de estados o subestados de un objeto. Estados de historia. . recordar el estado que estaba activo en su última ejecución. Secuenciales o no. se comenzaría por el estado inicial.Diagrama de estados  Otros elementos: ± ± ± ± Subestados.

Diagrama de estados .

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

Diagrama de Actividades .

Generalmente modelan los pasos de un algoritmo y puede dar detalle a un caso de uso. un objeto o un mensaje en un objeto. .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.

Los elementos que conforman el diagrama son: ± ± ± Acción Transición.Diagrama de Actividades   Sirven para representar transiciones internas. Objetos . sin hacer mucho énfasis en transiciones o eventos externos.

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

± Su representación. en cuanto a la notación. .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. es la misma que el de Acción.

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

Hacer explícita la relación con una entidad en concreto. etc). Flujos con objetos. . módulos del sistema.Diagrama de Actividades  Casos especiales: ± ± Carriles o ³Swim Lanes´. Permiten acotar el área a las cuales las actividades están asociadas (departamentos.

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.Diagrama de Actividades  Transición: Es la relación entre dos estados y se encuentran unidos por flechas. .

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

Diagrama de Actividades .

. Uso intensivo de transiciones (simples o paralelas) y de estados de acción. Uso intensivo de estados de actividad.Diagrama de interacción  Técnicas de modelado: ± ± Modelado de un flujo de trabajo o Workflow. Modelado de una operación concreta que resulta muy complicada. swim lanes y bifurcaciones condicionales.

Diagrama de Componentes .

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 .

 Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente utiliza los servicios ofrecidos por otro componente . Pueden ser simples archivos.Diagrama de componentes  Los componentes representan todos los tipos de elementos software que entran en la fabricación de aplicaciones informáticas. librerías. bibliotecas cargadas dinámicamente. etc.

Diagrama de componentes .

Modelado y diseño de un API. Modelado de tablas. Planificación de versiones ejecutables para su implementación con Nant. archivos y documentos. Modelado del código fuente. .Diagrama de componentes  Técnicas de modelado: ± ± ± ± ± Modelado de ejecutables y bibliotecas.

Diagrama de Despliegue .

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 .

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.

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

Diagrama de despliegue .

Diagrama de despliegue

Diagrama de despliegue 

Técnicas de modelado:
± ±

Modelado de procesadores y dispositivos. Modelado de distribución de componentes.

RUP: El Proceso Unificado de Rational

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

Clarificar y Validar los requerimientos Diseño Realizar los casos de uso <<verifica>> Pruebas Verificar que se satisfacen los casos de uso . sistema externo. dispositivo) que interactua con él Casos de uso como el hilo conductor que orienta las actividades de desarrollo Casos de Uso <<defineNecesidades>> <<realiza>> Análisis Recopilar.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.

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 Diferentes vistas del sistema: estructural. etc. funcional. Plataforma en la que va a operar Determina la forma del sistema ± Arquitectura en software    ± ± Arquitectura: determina la forma del sistema Casos de uso: determinan la función del sistema . dinámico.

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 Detección temprana de riesgos Administración adecuada del cambio Mayor grado de reutilización Mayor experiencia para el grupo de desarrollo  Ventajas del enfoque iterativo ± ± ± ± .

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 Artefactos Actividades Roles Estática .Flujos de trabajo    .

Estructura     Roles Actividades Artefactos Flujo de Trabajo QUIÉN? CÓMO? QUÈ? CUÁNDO? realiza responsable de diseñador diagrama de secuencia diseño de caso de uso .

Roles   Definición del comportamiento y responsabilidades de los participantes Propietario de una serie de artefactos Recurso Patricia Juan Mónica Pedro Rol Diseñador Analista Dominio Diseñador Funcional Actividad Diseño de Objetos Definición de CU Diseño de CU Artefacto DC DCU DS .

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

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

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 Administración del proyecto, Administración del cambio, Ambiente

±

De soporte 

Dimensión dinámica
fase ciclo

Concepción Elaboración

Construcción

Transición

hito 1
Iter. 1

hito 2
Iter. 2

hito 3
Iter. 3 Iter. 4 Iter. 5

hito 4
Iter. 6

Hito: punto en el tiempo en donde se evaluan objetivos logrados y se pueden tomar decisiones críticas

Desarrollo iterativo Construcción Ciclo de desarrollo 1 Ciclo de desarrollo 2 Ciclo de desarrollo n Perfeccionar el plan Análisis Diseño Sincronizar Artefactos Construcción Pruebas .

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

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 Modelo del dominio Modelo de procesos Modelo funcional de alto nivel Arquitectura básica  Artefactos ± ± ± ± .

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

XP: eXtreme Programming .

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

Valores que fomenta XP     Comunicación Simplicidad Retroalimentación Coraje .

los programadores ± Es parte del equipo diseñan.Roles  Programador ± ± ± ± (Programmer)  Jefe de Proyecto (Manager) Responsable de decisiones ± Organiza y guía las técnicas reuniones Responsable de construir el ± Asegura condiciones sistema adecuadas para el proyecto Sin distinción entre analistas. diseñadores o codificadores  Cliente (Customer) En XP. programan y realizan las ± Determina qué construir y pruebas cuándo ± Establece las pruebas funcionales .

Roles  Encargado de Pruebas (Tester) ± ±  Entrenador ± ± (Coach) Ayuda al cliente con las pruebas funcionales Se asegura de que las pruebas funcionales se superan Metric Man Observa sin molestar Conserva datos históricos Responsable del proceso Tiende a estar en un segundo plano a medida que el equipo madura  Rastreador (Tracker) ± ± ± .

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 .

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

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

Modelo de un proyecto .

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 .

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 .

Intentar trasladar los segmentos de desarrollo más arriesgados al principio. intentando respetar las prioridades del negocio .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.

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 .

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 .

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 .

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

Ejemplo de un test en NUnit .

Fallo en ejecución de los tests .

Éxito en ejecución de los tests .

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 .

xtreme-simplicity.net/ .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.

Integración con Visual Studio .

Métricas de análisis del código .

Refactoring con C# Refactory .

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

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   .

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   .

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  .

homogéneo.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. legible  .

Patrones de diseño software .

de tal manera que puedes usar esa solución un millón de veces más.Definición   ³Cada patrón describe un problema que ocurre una y otra vez en nuestro ambiente. sin hacer jamás la misma cosa dos veces´ (Christopher Alexander) ³Son soluciones reutilizables a problemas recurrentes que encontramos durante el desarrollo de software´ . y luego describe el núcleo de la solución a ese problema.

Ventajas que ofrece el uso de patrones     ³Diseñar código orientado a objetos es costoso. la reutilización del código y su consistencia . 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.

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 .Ventajas que ofrece el uso de patrones     Capturan la experiencia en diseño.

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 .

Proceso de aplicación de patrones Problema Fuerza Solución Beneficios Consecuencias Patrones relacionados .

Clasificación de los patrones       Fundamentales De creación De partición Estructurales De comportamiento De concurrencia .

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 .

Fundamentales       Delegate Interface Abstract superclass Interface + abstract class Immutable Proxy .

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 .

De creación      Factory Builder Prototype Singleton Object pool .

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

De partición    Filter Composite Read-only interface .

Estructurales  ³Describen las formas más comunes en las que diferentes tipos de objetos pueden organizarse para trabajar conjuntamente´ .

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

De comportamiento  ³Patrones utilizados para organizar. gestionar y combinar comportamiento´ .

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

De concurrencia  Patrones para la coordinación de operaciones concurrentes y que permiten solucionar dos problemas principalmente: ± ± Recursos compartidos Secuenciación de operaciones .

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

Arquitecturas dirigidas por modelos (MDA) .

siempre mantenemos el PIM . 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.Introducción       Nueva orientación de las actividades del OMG La base de todo son los modelos (ni su implementación.

PSM y transformaciones en MDA Modelo independiente de la plataforma (PIM) Reglas de transformación Modelo específico (PSM) Modelo específico (PSM) .PIM.

public int Engine. Schema (PSM) <!Element Auto (Color*. } XMI DTD. Java« (PSM) interface Auto { Class Auto }. Engine*)> . Door*. {public String color.Ejemplos con MOF/XMI UML Model (PIM) A ut C l r : tri r: I t r E i : I t r XMI Document (PSM) <Auto> XMI <Color> Red </Color> <Door> 4 </Door> <Engine> 2 </Engine> </Auto> IDL. public int Door.

Herramientas de apoyo al modelado .

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 .

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 .

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