Introducción al

modelado
Metodologías, UML y
patrones de diseño
Fuente: 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
 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 Ingeniería Directa
corresponder
con los Modelo CÓDIGO
UML
lenguajes de
programación Ingeniería Inversa
(Java, C#,
B.Datos, etc.).
 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
Rumbaugh
Booch Jacobson

Odell
Meyer
Pre- and Post-conditions

Shlaer-Mellor UML
Object life cycles
Harel
State Charts
Gamma et. al.
Frameworks, patterns,
notes
Embly Wirfs-Brock
Singleton classes Responsabilities
Fusion
Operation descriptions,
message numbering
Historia de UML
2001 UML 2.0

2000 UML 1.4

1999 UML 1.3
Revisiones
1998 menores
UML 1.2
Nov ‘97 UML aprobado por el OMG
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).
 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
Vista de Diseño Implementación
Vista de los
Casos de Uso

Vista de Vista de
Procesos Despliegue
Diagramas de UML

State
State
Use Case Diagramas
Diagrams de
Use Case Diagrams State
Use Case Diagramas
Diagrams de Clases State
Diagrams
Use Case Casos Diagramas
Diagrams de
Diagramas
Diagrams de de Uso Diagrams
Diagrams Objetos
Secuencia

Scenario State
Scenario State
Diagramas
Diagrams de Diagramas
Diagrams de
Diagrams Diagrams
Colaboración Modelo Componentes

Scenario Component
Scenario Component
Diagramas
Diagrams de
Diagramas
Diagrams de Diagrams
Diagrams
Estados Diagramas de Distribución
Actividad
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

{orderById}

«utility»
Producto
-Paginas : int
+Insert() IDataManaged
+Update()
+Delete()
#GetNumPaginas() : int

«utility» «utility»
p1 : Producto p2 : Producto
Paginas : int Paginas : int

Definición de un producto gestionado desde base de datos

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

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.
 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
 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.
 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
<<defineNecesidades>>
<<realiza>> <<verifica>>
Análisis Diseño Pruebas
Recopilar,
Clarificar y Realizar los Verificar que se
Validar los casos de uso satisfacen los
requerimientos 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á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ño de caso

diseñador 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

Patricia Diseñador Diseño de Objetos DC

Juan Analista Definición de CU DCU
Dominio
Mónica Diseñador Diseño de CU DS
Pedro Funcional
 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
Dimensión dinámica

fase ciclo

Concepción Elaboración Construcción Transición

hito 1 hito 2 hito 3 hito 4

Iter. 1 Iter. 2 Iter. 3 Iter. 4 Iter. 5 Iter. 6

Hito: punto en el tiempo en donde se evaluan objetivos

logrados y se pueden tomar decisiones críticas
Desarrollo iterativo

Construcción

Ciclo de Ciclo de Ciclo de

desarrollo 1 desarrollo 2 desarrollo n

Perfeccionar Sincronizar
el plan Artefactos

Análisis Diseño Construcción Pruebas

 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
 Encargado de  Entrenador (Coach)
 Responsable del proceso
Pruebas (Tester)  Tiende a estar en un
 Ayuda al cliente con segundo plano a medida
las pruebas que el equipo madura
funcionales
 Se asegura de que
las pruebas
funcionales se
superan
 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

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 • Programación en
parejas
planificación
• Entregas • Propiedad colectiva
pequeñas • Integración contínua
• Metáfora • Semana de 40 horas
• Diseño simple • Cliente in situ
• Pruebas • Estándares de
• Refactoring 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
 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
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 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
Estándares de programación
 Son fundamentales cuando los programadores
cambian de pareja o hacen refactoring del
código de otros
 Se consigue un código con el mismo estilo,
homogéneo, legible
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
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
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
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)
Introducción
 Nueva orientación de las actividades del OMG
 La base de todo son los modelos (ni su
implementación, ni la plataforma)
 Basado en el desarrollo de modelos
independientes de la plataforma (PIM)
 Define un segundo nivel en el que diseñamos
para una plataforma concreta pero de forma
abstracta (PSM)
 Definición de transformaciones de PIM a PSM
 Aunque la plataforma cambie, siempre
mantenemos el PIM
PIM, PSM y transformaciones en
MDA

Modelo independiente de la plataforma

(PIM)

Reglas de transformación

Modelo específico Modelo específico

(PSM) (PSM)
Ejemplos con MOF/XMI

UML Model (PIM) XMI Document (PSM)

<Auto>
Auto
Color : String
<Color> Red </Color>
Door : Integer
XMI <Door> 4 </Door>
Engine : Integer
M <Engine> 2 </Engine>
O X </Auto>
F M
IDL,Auto
Java… (PSM) I
interface XMI DTD, Schema (PSM)
{
Class Auto <!Element Auto
};{public String color; (Color*,
public int Door; Door*,
public int Engine;
} Engine*)>
Herramientas de
apoyo al modelado
Herramientas de apoyo al
modelado
 Herramientas comerciales generales:
 BorlandTogether
 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