Introducción al modelado Metodologías, UML y patrones de diseño Fuente: Ricardo Borillo Doménech
[email protected]
Índice Conceptos Lenguajes de modelado: UML Metologías:
Metologías clásicas: RUP, Métrica, MSF Metologías 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 Componentes básicos RUP. Técnicas y su aplicación a la gestión de proyectos software orientados a objeto. pro yectos y grupos de XP. Gestión ágil de proyectos 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 UML puede puede ser utiliza utilizado do por cualqu cualquier ier 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. 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 visu vi sual aliza izar, r, espe especif cifica icarr , cons constr trui uirr y docu documen menta tar r un sistema software. Lenguaje de modelado: ³Lenguaje cuyo vocabulario y reglas se centran centran en la representación representación conceptual c onceptual 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 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.).
Ingeni Ingenierí ería a Direct Directa a Modelo UML
CÓDIGO
Ingeniería Inversa
UML para documentar
UML cubre la documentación de un sistema: Requisitos ± Arquitectura ± Diseño ± Código fuente ± Planificación ± Pruebas ± Prototipos ± Versiones ±
UML UML ³agl ³aglut utin ina´ a´ enfo enfoqu ques es OO OO Rumbaugh Booch
Jacobson
Odell
Meyer Pre- and Post-cond Post-conditions itions
Shlaer-Mellor Object life cycles
UML Harel
State Charts
Gamma et. al. Frameworks, patterns, notes
Embly Singleton classes
Wirfs-Brock Fusion
Responsabilities
Operation descriptions, message numbering
Historia de UML UML 2.0
2001
UML 1.4
2000 1999
UML 1.3 Revisiones menores
1998
Nov ¶97
UML aprobado por el OMG
UML 1.2
Actualizaciones 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. ersonalización: mejora de los mecanismos de P ersonalización extensibilidad y personalización. omponentes : mejor soporte para el desarrollo basado C omponentes en componentes componentes (CORBA, EJB, COM+). ecanismos generales: nuevos mecanimos para el M ecanismos control de las versiones dentro del modelo, 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 permi rmitan expresar el producto desde cada una de las perspectivas de inter és El código fuente del sistema es el modelo m ás deta detalllado lado del sistema (y además es ejecutable). Sin embargo, se req requiere ieren n otro tros modelo elos ... ... Cada modelo es completo desde su punto de vista del sistema, si sin n embar bargo, go, existen relaci lacion one es de trazabi zabililida dad d entre tre los difere ferent nte es mode odelos los
Modelos y Diagramas
Modelo: captura captura una vista vista de un sistem sistema a del mundo mundo
real. Es una abstracción de dicho sistema, s istema, considerando considerando un cierto propósito.
Diagrama:: representación gráfica de una colección de Diagrama
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 de Diagrams Diagrams Secuencia
Use Case Use Case Diagramas de Diagrams Diagrams Casos de Uso
Scenario Scenario Diagramas de Diagrams Diagrams Colaboración Scenario Scenario Diagramas de Diagrams Diagrams Estados
State State Diagramas de Diagrams Diagrams Clases
Modelo
State State Diagramas de Diagrams Diagrams Objetos
State State Diagramas de Diagrams Diagrams Componentes Component Component Diagrams Diagramas Diagrams de
Diagramas de Actividad
Distribución
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 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 entorn torno o (usu (usua ario rio u otras ras aplica licaci cio ones). s). Es una herramienta esencial para la captura de requerimientos y para la planificación y control de un proy royecto cto int interact ractiivo. vo.
Casos de Usos
Los casos de Uso Se representa en el diagrama por una elipse que denota un requerimiento solu soluci cio onando por el si sist ste ema. ma. 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
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 necesi cesittan algu lguna info inform rma aci ció ón del si sist ste ema actu ctual. Actor :
Casos de Usos
También se puede encontrar tres tipos de relac laciones ones,, como son: on:
(comunicates) Entre un actor y un caso de uso, denota la participación del actor en el caso de uso determinado. Comunica
Casos de Usos
Usa 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 norma normall comp comport ortami amient ento. o.
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 Poli Polimo morf rfis ismo mo de cl clas ases es Clase lasess y atrib ributos tos está stático ticoss Clases ses y atributos finales Clase lasess y mét métodos abstra stract cto os
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:
Modelad lado del vocab cabulari lario o del si sist ste ema. ma. Model odelad ado o de cola colabo bora raci cion ones es si simp mple les. s. Modelado de un esquema lógico de base de datos. Modelado de un conjunto de clases de test.
Diagrama de clases
representa un conjunto de entidades que tienen en común propiedades, operaciones, rela relaci cion ones es y semá semánt ntic ica. a. 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 eleme lement ntos os fund fundam amen enta tale less del del diag diagra rama ma.. Clase:
Diagrama de clases
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: Atributo:
V isibilidad
: propiedades}
tipo
=
valor
Donde visibilidad es uno de los siguientes: + público lico.. # prot prote egido gido.. - priv rivado.
{
Diagrama de clases
ión: El conjunto de operaciones que Operación:
describen el comportamiento de los objetos de una clase. La sintaxis de una operación en UML es:
V isibilidad nombre (lista de parámetros): tipo que retorna { propiedades}
Diagrama de clases
Nombr e
de la clase
Atributos
Métodos
Diagrama de clases
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. abilidades: Responsabil
Diagrama de clases
Técnicas
de modela odelado:
Modelado del vocabulario de un sistema a partir de las descripciones funcionales. Modelado de la distribución de responsabilidades responsabilidades en un sistema. Modelado de cosas que no son software (hardware, personas, etc). Modelado de tipos primitivos.
Diagrama de clases
Obje bjeto: es una instancia de una clase. Se
caracteriza por tener una identidad única, un estado definido por un conjunto de valores de atributos tos y un com comportamie miento represe resen ntado por sus operaci cio ones y mét métodos. (rol, multiplicidad, calificador): representan las relaciones entre instancias de clase. Una asociación es una línea que une dos o más clases. Asociación
Diagrama de clases
Identifica la asociación entre los objetos, objetos, caracteri caracterizánd zándola. ola. 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. e: Nombr e:
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
Dependen dencia: ia: Es una relación donde existen
entidad dades ind independientes tes y otras ras 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: Asocia Asociació ción n bina binaria ria.. Asocia Asociació ción n n-ari n-aria. a. 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. ia: Es una asociación entre tres Asociación n-aria: 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
osición: ión: Composi
que que impl implic ica: a:
Es una asociación fuerte
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 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
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. ión: Agr egación:
Diagrama de clases
Diagrama de clases
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 represen senta dibu ibujan jando un trián iángulo si sin n rellenar nar en el lado de la superclase. La subclase hereda todos los atributos y mensajes descritos en la superclase. ralización: ión: General
Diagrama de clases
Diagrama de clases
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. inamiento: Ref inamie
Diagrama de clases
Diagrama de clases
Técnicas
de modela odelado:
Modelado de dependencias simples. Modelado de herencia simple. Modelado de relaciones estructurales (composiciones y agregaciones). 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 iagramas de secuencia y
diagramas iagramas de colab olabo oració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:
Objet jetos o actores para cada entidad. Enlaces ces entre los objet jetos. Proced cedimie mientos a invocar entre los objet jetos. Mensaje sajess entre los objet jetos.
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 desa desarr rrol olla land ndo o algu alguna na oper operac ació ión. n. El rectángulo de encabezado contiene el nombre del objeto y el de su clase, en un formato nombreObjeto: nombreC lase lase. 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 Diagramas de Colab olabo oración: ió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 con 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 modela odelado:
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 prin princi cipa palm lmen ente te por por los los si sigu guie ient ntes es elem elemen ento tos: s: Estado. Elemento. Transición.
Diagrama de estados
Identifica un período de tiempo del objeto (no instantáneo) en el cual el objeto esta espe sperando algu lguna operaci ción ón,, tiene ci cie erto esta stado característico o puede recibir cierto tipo de estímulos. Estado:
Diagrama de estados
Partes que componen un estado: Nombre Acciones de entrada y de salida. Transiciones internas. Subestados. Eventos diferidos.
Diagrama de estados
Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. Esta, puede ser una: Eventos:
Condición que toma el de verdadero o falso. Recepción de una señal de otro objeto en el modelo. Recep cepci ció ó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
Es una relación entre estados de un fuente a un destino. Partes que componen una transición: ransición: ión: Trans
Estado de origen. Evento de disparo. Condición de guarda. Acción. Estado de destino.
Diagrama de estados
os elem elementos: Otr os
Subestados. Secuenciales o no, resultan en una nueva ueva máqu áquina ina de esta estad dos. Esta Estado doss de hist histor oria ia.. 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. Subest Subestad ados os concur concurren rente tes. s.
Diagrama de estados
Diagrama de estados
Técnicas
de modela odelado:
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 acc cciión ejecu jecuttada en el esta stado 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
Trans ransición.
Obje bjetos
Diagrama de Actividades
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). Estado
de
ión: Acción:
Permite modular un paso dentro del algoritmo. Se representan por un rectángulo con con bord borde es redo redond ndea eado dos. s.
Diagrama de Actividades
Estado más general que permite su descomposición en otro diagrama de actividades interno, de nivel más bajo. Estado
de
Actividad:
Su representación, en cuanto a la notación, es la misma que el de Acción.
Diagrama de Actividades
especiales: iales: 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 bifurcaciones condicionales.
Casos
Diagrama de Actividades
especiales: iales: 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.
Casos
Diagrama de Actividades
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. ransición: ión: Trans
Diagrama de Actividades
Tipos
de trans ransiciones: Bifurcaciones condicionales. 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. actividades.
Diagrama de Actividades
Diagrama de interacción
Técnicas
de modela odelado: Modelado de un flujo de trabajo o Workflow. Uso intensivo de estados de actividad, swim lanes y bifurcaciones condicionales. 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 compone componente ntess represen representan tan todos todos los tipos de elementos software que entran en la fabricación de aplicaciones informáticas. Pueden ser simples archivos, librerías, librerías, bibliotecas bibliotecas cargadas dinámicamente, etc. Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un compone componente nte utiliza utiliza los servicio servicioss ofrecidos por otro component c omponente e
Diagrama de componentes
Diagrama de componentes
Técnicas
de modela odelado: 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 implementación con Nant.
Diagrama de Despliegue
Diagrama de despliegue
Los diagr diagramas amas de de desplieg despliegue ue muestran muestran la 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 com o
Dispositivos Procesadores Memoria
Los nodos se interconectan mediante soportes bidireccionales bidireccionales que pueden a su s u vez estereotiparse.
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 modela odelado: 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 Pr oceso Unific Unificad ado o de de Rat Ration ional al - RUP (junio (junio 1998 1998))
Casos de uso
Dirigido por casos de uso
Se centra en la funcionalidad que el sistema sis tema debe poseer para satisfacer las necesidades de un usuario (persona, sistema externo, dispositivo) que interactua con él Casos de uso como el hilo hil o conductor que orienta las actividades de desarrollo Casos de Uso
efineNecesid ad es>> es>> <>
Análisis Recopilar, Clarificar y Validar los requerimientos
<>
Diseño
Pruebas
Realizar los casos de uso
Verificar que se satisfacen los casos de uso
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áti Estática ca - Flujos Flujos de de traba trabajo jo Artefactos Actividades Roles
Estructura Roles Actividades Artefactos Flujo de Trabajo
QUIÉN? CÓM O? QUÈ? O? CUÁND realiza responsable d e
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
Actividad
Artefacto
Diseñador Analista Analista Dominio Diseñador Funcional
Diseño de Objetos Definición de CU
DC DCU
Diseño de CU
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 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 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
Dimensión dinámica fase
ciclo
Conc Concep epci ción ón Elab Elabor orac ació ión n
hito 1 Iter. 1
ito: H ito:
hito 2 Iter. 2
Construcción
hito 3 Iter. 3 Iter. 4 Iter. 5
Transición
hito 4 Iter. 6
punto en el tiempo en d on ond e se evaluan objetivos lograd os os y se pued en en tomar d ecisiones ecisiones críticas
Desarrollo iterativo onstrucción C onstrucción Ciclo de desarrollo 1
Ciclo de desarrollo 2
Perfeccionar el plan Análisis
Diseño
Ciclo de desarrollo n
Sincronizar Artefactos Construcción
Pruebas
Fase de concepción
Objetivo: definir la razón de ser y el alcance del proyecto. Estudio de oportunidad.
Actividades
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
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
Programmer) rogrammer) Programador ( P
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 ( M Manager) a nager)
Organiza y guí a las reuniones Asegura condiciones adecuadas para el proyecto
Cliente ( C Customer) u stomer)
Es parte del equipo Determina qué construir y cuándo Establece las pruebas funcionales
Roles
Encargado de Pruebas (T ester ester ) Ayuda al cliente con las pruebas funcionales Se asegura de que las pruebas funcionales funcionales se se superan
Rastreador (
racker ) T racker
Coach) ach) Entrenador ( C o
Responsable del proceso Tiende a estar en un segundo plano a medida que el equipo madura
Captura de requisitos
rias Historias
del Usuari Usuario o (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 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 cad cada ro rama ramad dor se le asi na una tare tarea a de
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 n ua
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? Prio riorid ridad Prioriza la incorporaci ón de las userstories Composi osición de entr egas gas ¿Qué se necesita para que el negocio sea mejor antes de tener el sw? Fechas de entr ega Fechas cuando el software funcionando 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 ias Tener en cuenta las consecuencias t écnicas de determinadas decisiones de negocio Pr oceso Organización del proceso y el equipo Planif anif icación detalla llada Dentro de una entrega, qué user-stories se realizan primero. Intentar trasladar los segmentos de desarrollo m ás arriesgados al
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 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 Intentar eliminar complejidad
Código duplicado Refactorización
Se plantea su aplicación después de implementar cada user-story
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
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 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 prioridades Discutir mejoras
Estándares de programación 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 mism o estilo, homogéneo, legible
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, m ás, sin hacer jamás la misma mism a cosa dos veces´ (C hristopher hristopher A Alexander ) ³Son soluciones reutilizables a problemas recurrentes que encontramos durante el ´
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 inmediatamente determinar la solución sin tener que pararse a analizar el problema primero´ Permiten trabajar 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 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
Componentes que constituyen un patrón
Nombre Resumen o esencia de la solución s olución Contexto al que se aplica Razones para utlizar o no el patrón Consideraciones Consideraciones de implementación implementación Consecuencias Consecuencias e implicaciones implicaciones de su uso Ejemplo de uso (Test Case) Patrones relacionados
Proceso de aplicación de patrones Problema
Fuerza Solución Beneficios Patrones
Consecuencias 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 Inte Interfa rface ce + abstrac abstractt class 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 normalmente involucran la determinación de forma dinámica de qué clase instanciar o a qué objeto delegar la responsabilidad´ Estos patrones 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 comportamien comportamiento to
³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)
Introducción Nueva orientación de las actividades del OMG La base de todo son los modelos (ni su implementación, 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
PIM, PSM y transformaciones en MDA Modelo independiente de la plataforma (PIM) Reglas de transformación
Modelo específico (PSM)
Modelo específico (PSM)
Ejemplos con MOF/XMI UML Model (PIM)
XMI Document (PSM)
to olor : trin oor oor : Int Inte e er E n i n e : In In t e e r
XMI
IDL,Auto Java« (PSM) interface {Class Auto }; {public String color; public int Door; public int Engine; }
Red 4 2
XMI DTD, Schema (PSM)
Herramientas de apoyo al modelado
Herramientas de apoyo al modelado
Herramientas Herramientas comerciales generales:
Borland Together IBM Rational Suite
Herramientas Herramientas libres o con versiones básicas gratuitas: Argo UML Poseidon Umbrello Eclipse UML2 Eclipse Omondo
Integración Integración con los IDEs existentes 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
