Í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
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.
Modelado con UML
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.
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).
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.
UML cubre la especificación del análisis, diseño e implementación de un sistema software.
UML para construir
Es posible hacer corresponder con los lenguajes de programación (Java, C#, B.Datos, etc.).
ModeloUML
Ingeniería Directa
Ingeniería Inversa
CÓDIGO
UML para documentar
UML cubre la documentación de un sistema:
Requisitos
Arquitectura
Diseño
Código fuente
Planificación
Pruebas
Prototipos
Versiones
UML aglutina enfoques OO
UML
Rumbaugh
Jacobson
Meyer
Harel
Wirfs-Brock
Fusion
Embly
Gamma et. al.
Shlaer-Mellor
Odell
Booch
Pre- and Post-conditions
State Charts
Responsabilities
Operation descriptions,
message numbering
Singleton classes
Frameworks, patterns,
notes
Object life cycles
Historia de UML
(Gp:) Nov 97
(Gp:) UML aprobado por el OMG
(Gp:) 1998
(Gp:) 1999
(Gp:) 2000
(Gp:) UML 1.2
(Gp:) UML 1.3
(Gp:) UML 1.4
(Gp:) 2001
(Gp:) UML 2.0
(Gp:) Revisiones menores
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.
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).
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
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.
(Gp:) Vista de Diseño
(Gp:) Vista de
Procesos
(Gp:) Vista de
Despliegue
(Gp:) Vista de
Implementación
(Gp:) Vista de los
Casos de Uso
Organización de Modelos
Diagramas de UML
(Gp:) Use Case
Diagrams
(Gp:) Use Case
Diagrams
(Gp:) Diagramas de
Casos de Uso
(Gp:) Scenario
Diagrams
(Gp:) Scenario
Diagrams
(Gp:) Diagramas de
Colaboración
(Gp:) State
Diagrams
(Gp:) State
Diagrams
(Gp:) Diagramas de
Componentes
(Gp:) Component
Diagrams
(Gp:) Component
Diagrams
(Gp:) Diagramas de
Distribución
(Gp:) State
Diagrams
(Gp:) State
Diagrams
(Gp:) Diagramas de
Objetos
(Gp:) Scenario
Diagrams
(Gp:) Scenario
Diagrams
(Gp:) Diagramas de
Estados
(Gp:) Use Case
Diagrams
(Gp:) Use Case
Diagrams
(Gp:) Diagramas de
Secuencia
(Gp:) State
Diagrams
(Gp:) State
Diagrams
(Gp:) Diagramas de
Clases
(Gp:) Diagramas de
Actividad
(Gp:) Modelo
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.
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.
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.
Casos de Usos
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.
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.
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.
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.
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.
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 esquema lógico de base de datos.
Modelado de un conjunto de clases de test.
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.
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 < nombre>: tipo = valor { propiedades}
Donde visibilidad es uno de los siguientes:
+ público.
# protegido.
– privado.
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}
Diagrama de clases
(Gp:) Nombre de la clase
(Gp:) Atributos
(Gp:) Métodos
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.
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.
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.
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.
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:
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
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.
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.
Diagrama de clases
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.
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.
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
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.
Diagrama de clases
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.
Diagrama de clases
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.
Diagrama de clases
Diagrama de Interacción
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.
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.
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.
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.
Diagrama de interacción
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.
Diagrama de interacción
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).
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. Esta representado principalmente por los siguientes elementos:
Estado.
Elemento.
Transición.
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.
Diagrama de estados
Partes que componen un estado:
Nombre
Acciones de entrada y de salida.
Transiciones internas.
Subestados.
Eventos diferidos.
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.
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.
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.
Diagrama de estados
Diagrama de estados
Técnicas de modelado:
Modelado de la vida de un objeto. Este tipo de diagramas se asocian directamente a una clase.
Diagrama de Actividades
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.
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
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.
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.
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.
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.
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.
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.
Diagrama de Actividades
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.
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
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
Diagrama de componentes
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.
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
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.
Diagrama de despliegue
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.
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)
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
Análisis
Recopilar,
Clarificar y
Validar los
requerimientos
Diseño
Realizar los
casos de uso
Pruebas
Verificar que se
satisfacen los
casos de uso
< < realiza>>
< < verifica>>
< < defineNecesidades>>
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
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
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
Estructura
Roles QUIÉN?
Actividades CÓMO?
Artefactos QUÈ?
Flujo de Trabajo CUÁNDO?
realiza
responsable de
diseñador
diseño de caso
de uso
diagrama de
secuencia
Roles
Definición del comportamiento y responsabilidades de los participantes
Propietario de una serie de artefactos
Recurso
Rol Actividad Artefacto
Diseñador Diseño de Objetos DC
Analista Definición de CU DCU
Dominio
Diseñador Diseño de CU DS
Funcional
Patricia
Juan
Mónica
Pedro
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
De soporte
Administración del proyecto, Administración del cambio, Ambiente
Dimensión dinámica
Concepción
Elaboración
Construcción
Transición
ciclo
fase
Iter. 1
Iter. 2
Iter. 3
Iter. 4
Iter. 5
Iter. 6
hito 1
hito 2
hito 3
hito 4
Hito: punto en el tiempo en donde se evaluan objetivos
logrados y se pueden tomar decisiones críticas
Desarrollo iterativo
Ciclo de
desarrollo 1
Ciclo de
desarrollo 2
Ciclo de
desarrollo n
Perfeccionar
el plan
Sincronizar
Artefactos
Análisis
Diseño
Construcción
Pruebas
Construcción
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
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
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
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
Valores que fomenta XP
Comunicación
Simplicidad
Retroalimentación
Coraje
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
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
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 user-story
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
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
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
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
Entregas pequeñas
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
Diseño simple
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
Pruebas
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
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
Refactoring
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/
Integración con Visual Studio
Métricas de análisis del código
Refactoring con C# Refactory
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)
Programación en parejas
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
Propiedad colectiva
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
Integración contínua
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
Cliente in situ
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
Estándares de programación
Patrones de diseño software
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
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
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
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
Contexto
Solución
Beneficios
Patrones relacionados
Consecuencias
Fuerza
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
Delegate
Interface
Abstract superclass
Interface + abstract class
Immutable
Proxy
Fundamentales
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
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)
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
Introducción
PIM, PSM y transformaciones en MDA
Reglas d
Página siguiente |