Applying UML and Patterns (Capítulos 11,12,13,14
y 15)
Giomara LÁRRAGA
MALDONADO
C
INVESTAV-Tamaulipas
Capítulo 11: Contratos de operación
Contenido
1
Capítulo 11: Contratos de operación
Introducción
Secciones de un contrato
Operación del sistema
Postcondiciones
Preguntas frecuentes
Aplicando UML: Operaciones, Contratos, y OCL
Contratos de operación en el Proceso Unificado
Capítulo 11: Contratos de operación Introducción
Contenido
1
Capítulo 11: Contratos de operación
Introducción
Secciones de un contrato
Operación del sistema
Postcondiciones
Preguntas frecuentes
Aplicando UML: Operaciones, Contratos, y OCL
Contratos de operación en el Proceso Unificado
Capítulo 11: Contratos de operación Introducción
Introducción
Los contratos de operación utilizan una forma de pre-y
post-condición para describir los cambios detallados a objetos en
un modelo de dominio, como resultado de una operación del
sistema.
Los contratos de operación pueden ser considerados como parte
del Modelo de Casos de Uso, ya que proporcionan un análisis
detallado sobre el efecto de las operaciones del sistema
implicados en los casos de uso.
Capítulo 11: Contratos de operación Secciones de un contrato
Contenido
1
Capítulo 11: Contratos de operación
Introducción
Secciones de un contrato
Operación del sistema
Postcondiciones
Preguntas frecuentes
Aplicando UML: Operaciones, Contratos, y OCL
Contratos de operación en el Proceso Unificado
Capítulo 11: Contratos de operación Secciones de un contrato
Capítulo 11: Contratos de operación Secciones de un contrato
Secciones de un contrato
Descripción de los campos del contrato de operación:
Operación:
Nombre de la operación y parámetros.
Referencias cruzadas:
Casos de uso con los que esta operación
puede ocurrir.
Precondiciones:
Suposiciones notables sobre el estado del
sistema o de los objetos en el modelo de dominio antes de la
ejecución de la operación.
Postcondiciones:
El estado de los objetos en el modelo de
dominio después de completar la operación.
Capítulo 11: Contratos de operación Operación del sistema
Contenido
1
Capítulo 11: Contratos de operación
Introducción
Secciones de un contrato
Operación del sistema
Postcondiciones
Preguntas frecuentes
Aplicando UML: Operaciones, Contratos, y OCL
Contratos de operación en el Proceso Unificado
Capítulo 11: Contratos de operación Operación del sistema
Operación del sistema
Los contratos de operación se pueden definir para operaciones
del sistema que éste ofrece en su interfaz pública como una caja
negra.
Capítulo 11: Contratos de operación Postcondiciones
Contenido
1
Capítulo 11: Contratos de operación
Introducción
Secciones de un contrato
Operación del sistema
Postcondiciones
Preguntas frecuentes
Aplicando UML: Operaciones, Contratos, y OCL
Contratos de operación en el Proceso Unificado
Capítulo 11: Contratos de operación Postcondiciones
Postcondiciones
Las postcondiciones describen los cambios en el estado de los
objetos en el modelo de dominio. Los cambios de estado en el
Modelo de Dominio incluyen instancias creadas, las asociaciones
formadas o rotas, y atributos cambiados.
Las postcondiciones no son acciones que deben realizarse
durante la operación.
Un contrato es una excelente herramienta de análisis de
requisitos u OOA que describe con gran detalle los cambios que
requiere una operación del sistema (en términos de los objetos de
modelo de dominio) sin tener que describir cómo se van a lograr.
Capítulo 11: Contratos de operación Preguntas frecuentes
Contenido
1
Capítulo 11: Contratos de operación
Introducción
Secciones de un contrato
Operación del sistema
Postcondiciones
Preguntas frecuentes
Aplicando UML: Operaciones, Contratos, y OCL
Contratos de operación en el Proceso Unificado
Capítulo 11: Contratos de operación Preguntas frecuentes
Preguntas frecuentes
¿Se debe actualizar el modelo de dominio?:
En los métodos
iterativos y evolutivos, todos los artefactos de análisis y diseño se
consideran parciales e imperfectos, y evolucionan en respuesta a
los nuevos descubrimientos.
¿Cuándo son útiles los contratos?:
Cuando los detalles y la
complejidad de los cambios de estado necesarios son difíciles o
demasiado detallados para capturar en casos de uso. Si los
desarrolladores fácilmente puede entender qué hacer sin ellos,
entonces se evita escribirlos.
Capítulo 11: Contratos de operación Preguntas frecuentes
Preguntas frecuentes
¿Cómo crear y escribir contratos?
1
Identificar las operaciones del sistema a partir de los Diagramas de
Secuencia.
2
Construir un contrato para las operaciones del sistema que son
complejas y posiblemente delicadas en sus resultados, o que no
están claras en los casos de uso.
3
Para describir las postcondiciones, utilice las siguientes categorías:
Creación y eliminación de instancias.
Modificación de atributos.
Capítulo 11: Contratos de operación Aplicando UML: Operaciones, Contratos, y OCL
Contenido
1
Capítulo 11: Contratos de operación
Introducción
Secciones de un contrato
Operación del sistema
Postcondiciones
Preguntas frecuentes
Aplicando UML: Operaciones, Contratos, y OCL
Contratos de operación en el Proceso Unificado
Capítulo 11: Contratos de operación Aplicando UML: Operaciones, Contratos, y OCL
Aplicando UML: Operaciones, Contratos, y OCL
El UML define operaciones semánticas a través de limitaciones,
que se especifican usando precondiciones y postcondiciones.
Una especificación de operación UML, puede no mostrar un
algoritmo o solución, sino sólo los cambios de estado o los
efectos de la operación.
Los contratos se pueden aplicar a las operaciones en cualquier
nivel de granularidad.
El OCL (Object Constraint Language) define un formato oficial
para la especificación de pre y postcondiciones de las
Capítulo 11: Contratos de operación Contratos de operación en el Proceso Unificado
Contenido
1
Capítulo 11: Contratos de operación
Introducción
Secciones de un contrato
Operación del sistema
Postcondiciones
Preguntas frecuentes
Aplicando UML: Operaciones, Contratos, y OCL
Contratos de operación en el Proceso Unificado
Capítulo 11: Contratos de operación Contratos de operación en el Proceso Unificado
Contratos de operación en el Proceso Unificado
Fases:
Inicialización:
No son creados en ésta etapa ya que son muy
detallados.
Elaboración:
Si se decide utilizarlos, son escritos durante la etapa
de elaboración, ya que ha sido escrita la mayor parte de los casos
de uso. Sólo se hacen contratos para las operaciones más
complejas y sutiles.
Capítulo 12: Requerimientos para diseñar iterativamente
Contenido
2
Capítulo 12: Requerimientos para diseñar iterativamente
Introducción
Haz lo correcto iterativamente, haz las cosas bien
Provocando el cambio temprano
¿No todo ese análisis y modelado toman semanas en
realizarse?
Capítulo 12: Requerimientos para diseñar iterativamente Introducción
Contenido
2
Capítulo 12: Requerimientos para diseñar iterativamente
Introducción
Haz lo correcto iterativamente, haz las cosas bien
Provocando el cambio temprano
¿No todo ese análisis y modelado toman semanas en
realizarse?
Capítulo 12: Requerimientos para diseñar iterativamente Introducción
Introducción
En éste capítulo se concluye el trabajo de análisis y se comienza
con la primera iteración de la etapa de elaboración.
Capítulo 12: Requerimientos para diseñar iterativamente Haz lo correcto iterativamente, haz las cosas bien
Contenido
2
Capítulo 12: Requerimientos para diseñar iterativamente
Introducción
Haz lo correcto iterativamente, haz las cosas bien
Provocando el cambio temprano
¿No todo ese análisis y modelado toman semanas en
realizarse?
Capítulo 12: Requerimientos para diseñar iterativamente Haz lo correcto iterativamente, haz las cosas bien
Haz lo correcto iterativamente, haz las cosas bien
Los requisitos y el análisis orientado a objetos se han centrado en
aprender a hacer lo correcto, es decir, la comprensión de algunos
de los objetivos pendientes de los casos de estudio y las normas
y limitaciones relacionadas. Por el contrario, el siguiente trabajo
de diseño se esfuerza en hacer las cosas bien, es decir, con
habilidad de diseñar una solución para satisfacer los requisitos de
esta iteración.
Capítulo 12: Requerimientos para diseñar iterativamente Provocando el cambio temprano
Contenido
2
Capítulo 12: Requerimientos para diseñar iterativamente
Introducción
Haz lo correcto iterativamente, haz las cosas bien
Provocando el cambio temprano
¿No todo ese análisis y modelado toman semanas en
realizarse?
Capítulo 12: Requerimientos para diseñar iterativamente Provocando el cambio temprano
Provocando el cambio temprano
Es natural y saludable descubrir y cambiar algunos requisitos
durante el trabajo de diseño e implementación, especialmente en
las primeras iteraciones, de modo que tenemos una meta más
estable para las iteraciones posteriores.
En el transcurso de las iteraciones de elaboración tempranas, el
descubrimiento de requisitos se debe estabilizar, por lo que al
final de la elaboración, quizás el 80 % de los requisitos son
definidos y refinados como resultado de la retroalimentación, la
programación temprana y las pruebas, en lugar de la
Capítulo 12: Requerimientos para diseñar iterativamente ¿No todo ese análisis y modelado toman semanas en realizarse?
Contenido
2
Capítulo 12: Requerimientos para diseñar iterativamente
Introducción
Haz lo correcto iterativamente, haz las cosas bien
Provocando el cambio temprano
¿No todo ese análisis y modelado toman semanas en
realizarse?
Capítulo 12: Requerimientos para diseñar iterativamente ¿No todo ese análisis y modelado toman semanas en realizarse?
¿No todo ese análisis y modelado toman semanas en
realizarse?
Cuando uno se siente cómodo con sus habilidades de escritura
de casos de uso, modelos de dominio,etc. , el tiempo para hacer
todo el modelado es de sólo unas pocas horas o días.
Eso no significa que sólo unos pocos días han pasado desde el
comienzo del proyecto. Muchas otras actividades, tales como la
programación de prueba de concepto, búsqueda de recursos
(personas, software, ...), la planificación, la configuración del
entorno, etc. , podrían consumir un par de semanas de
preparación.
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML
Contenido
3
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML
Introducción
¿Qué es la arquitectura de software?
Aplicando UML: Diagramas de paquetes
Diseñar en capas
El principio de separación Modelo-Vista
¿Cuál es la conexión entre los SSD, operaciones del sistema, y
las capas?
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML Introducción
Contenido
3
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML
Introducción
¿Qué es la arquitectura de software?
Aplicando UML: Diagramas de paquetes
Diseñar en capas
El principio de separación Modelo-Vista
¿Cuál es la conexión entre los SSD, operaciones del sistema, y
las capas?
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML Introducción
Introducción
El diseño de un sistema típico de OO se basa en varias capas de
arquitectura, tales como una capa de interfaz de usuario, una
capa lógica de aplicación, etc. En este capítulo se explora una
arquitectura lógica por capas y notación UML relacionada.
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML Introducción
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML ¿Qué es la arquitectura de software?
Contenido
3
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML
Introducción
¿Qué es la arquitectura de software?
Aplicando UML: Diagramas de paquetes
Diseñar en capas
El principio de separación Modelo-Vista
¿Cuál es la conexión entre los SSD, operaciones del sistema, y
las capas?
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML ¿Qué es la arquitectura de software?
¿Qué es la arquitectura de software?
Una arquitectura es el conjunto de decisiones significativas sobre
la organización de un sistema de software, la selección de los
elementos estructurales y las interfaces por las que está
compuesto el sistema, junto con su comportamiento tal como se
especifica en las colaboraciones entre esos elementos, la
composición de estos elementos estructurales y de
comportamiento en subsistemas progresivamente más grandes, y
el estilo arquitectónico que guía esta organización, estos
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML Aplicando UML: Diagramas de paquetes
Contenido
3
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML
Introducción
¿Qué es la arquitectura de software?
Aplicando UML: Diagramas de paquetes
Diseñar en capas
El principio de separación Modelo-Vista
¿Cuál es la conexión entre los SSD, operaciones del sistema, y
las capas?
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML Aplicando UML: Diagramas de paquetes
Aplicando UML: Diagramas de paquetes
Los Diagramas de paquetes UML a menudo se utilizan para
ilustrar la arquitectura lógica de un sistema, las capas, los
subsistemas, paquetes (en el sentido de Java), etc. Una capa
puede ser modelada como un paquete UML.
Un diagrama de paquetes UML proporciona una forma de agrupar
elementos
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML Diseñar en capas
Contenido
3
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML
Introducción
¿Qué es la arquitectura de software?
Aplicando UML: Diagramas de paquetes
Diseñar en capas
El principio de separación Modelo-Vista
¿Cuál es la conexión entre los SSD, operaciones del sistema, y
las capas?
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML Diseñar en capas
Diseñar en capas
Las ideas esenciales del uso de capas son simples:
Organizar la estructura lógica a gran escala de un sistema en
capas discretas de responsabilidades distintas, relacionadas, con
una separación clara y coherente de asuntos tal que las ’capas
bajas’ son servicios de bajo nivel y generales, y las capas más
altas son más específicas.
La colaboración y el acoplamiento es de capas más altas a capas
inferiores; el acoplamiento de capa menor a mayor se evita.
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML Diseñar en capas
Diseñar en capas
El uso de capas ayuda a resolver varios problemas:
Muchas partes del sistema están altamente acopladas.
La lógica de la aplicación se entrelaza con la interfaz de usuario.
Los Servicios técnicos generales o la lógica de negocio se
entrelazan con más lógica especifica de la aplicación.
Existe alto acoplamiento en las diferentes áreas de interés.
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML Diseñar en capas
Diseñar en capas
Ventajas de usar capas
Hay una separación de aspectos, una separación de servicios de
alto y bajo nivel, y de los servicios específicos de los servicios
generales. Esto reduce el acoplamiento y dependencias, mejora
la cohesión, aumenta el potencial de reutilización, y la claridad
aumenta.
La complejidad relacionada es encapsulada y descomponible.
Algunas capas pueden ser reemplazadas con nuevas
implementaciones.
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML Diseñar en capas
Diseñar en capas
Capa de dominio vs Capa Lógica de Aplicación; objetos de
dominio
Un sistema de software típico tiene una lógica de interfaz de
usuario y la lógica de la aplicación.
Los
objetos de dominio
representan un cosa en el espacio de
dominio del problema, y tiene lógica de aplicación y de negocio
relacionada.
Diseñar objetos de ésta manera hace que a la capa de lógica de
aplicación se le llame más precisamente la
capa de dominio
de la
arquitectura. La capa que contiene los objetos de dominio para
manejar el trabajo de la lógica de la aplicación.
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML Diseñar en capas
Diseñar en capas
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML Diseñar en capas
Diseñar en capas
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML Diseñar en capas
Diseñar en capas
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML El principio de separación Modelo-Vista
Contenido
3
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML
Introducción
¿Qué es la arquitectura de software?
Aplicando UML: Diagramas de paquetes
Diseñar en capas
El principio de separación Modelo-Vista
¿Cuál es la conexión entre los SSD, operaciones del sistema, y
las capas?
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML El principio de separación Modelo-Vista
El principio de separación Modelo-Vista
Éste principio tiene por lo menos dos partes:
1
No conecte o acople objetos que no son de interfaz de usuario
directamente a los objetos de interfaz de usuario.
2
No ponga lógica de la aplicación en los métodos de los objetos de
interfaz de usuario.
En éste contexto, el modelo es un sinónimo de la capa de dominio
de objetos. La Vista es un sinónimo de objetos de interfaz de
usuario, tales como ventanas, páginas web, applets,e informes.
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML El principio de separación Modelo-Vista
El principio de separación Modelo-Vista
El principio de separación de Modelo-Vista afirma que los objetos
del modelo (dominio) no deben tener un conocimiento directo de
la vista (UI).
Éste es un principio fundamental en el patrón
Modelo-Vista-Controlador (MVC). El modelo es la capa de
dominio, la vista es la capa de interfaz de usuario y los
controladores son los objetos de flujo de trabajo en la capa de
aplicación.
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML El principio de separación Modelo-Vista
El principio de separación Modelo-Vista
La motivación para la Separación Modelo-Vista incluye:
Apoyar las definiciones de modelo coherentes que se centran en
los procesos de dominio, en lugar de en las interfaces de usuario.
Permitir el desarrollo independiente de la capa de modelo y de la
capa de interfaz de usuario.
Minimizar el impacto de los cambios en los requisitos de la interfaz
sobre la capa de dominio.
Permitir a nuevas vistas ser fácilmente conectadas a una capa de
dominio existente, sin afectar a la capa de dominio.
Permitir múltiples vistas simultáneas en el mismo objeto modelo.
Permitir la ejecución de la capa de modelo independiente de la
capa de interfaz de usuario, tal como en un sistema de
procesamiento de mensajes o en modo por lotes.
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML las capas?¿Cuál es la conexión entre los SSD, operaciones del sistema, y
Contenido
3
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML
Introducción
¿Qué es la arquitectura de software?
Aplicando UML: Diagramas de paquetes
Diseñar en capas
El principio de separación Modelo-Vista
¿Cuál es la conexión entre los SSD, operaciones del sistema, y
las capas?
Capítulo 13: Arquitectura lógica y diagramas de paquetes UML las capas?¿Cuál es la conexión entre los SSD, operaciones del sistema, y
¿Cuál es la conexión entre los SSD, operaciones del
sistema, y las capas?
Los mensajes enviados desde la capa de interfaz de usuario a la
capa de dominio serán los mensajes ilustrados en los SSD
Capítulo 14: Diseño de objetos
Contenido
4
Capítulo 14: Diseño de objetos
Introducción
Modelado Ágil y Dibujo UML ligero
Herramientas CASE UML
¿Cuánto tiempo dedicar a dibujar UML antes de codificar?
Diseñando objetos: ¿Qué es el modelado estático y dinámico?
La importancia de la habilidad de diseñar objetos sobre
habilidad de notación UML
Capítulo 14: Diseño de objetos Introducción
Contenido
4
Capítulo 14: Diseño de objetos
Introducción
Modelado Ágil y Dibujo UML ligero
Herramientas CASE UML
¿Cuánto tiempo dedicar a dibujar UML antes de codificar?
Diseñando objetos: ¿Qué es el modelado estático y dinámico?
La importancia de la habilidad de diseñar objetos sobre
habilidad de notación UML
Capítulo 14: Diseño de objetos Introducción
Introducción
¿Cómo diseñan objetos los desarrolladores?
1
Código
2
Dibujar, luego escribir código
3Sólo dibujar
Capítulo 14: Diseño de objetos Modelado Ágil y Dibujo UML ligero
Contenido
4
Capítulo 14: Diseño de objetos
Introducción
Modelado Ágil y Dibujo UML ligero
Herramientas CASE UML
¿Cuánto tiempo dedicar a dibujar UML antes de codificar?
Diseñando objetos: ¿Qué es el modelado estático y dinámico?
La importancia de la habilidad de diseñar objetos sobre
habilidad de notación UML
Capítulo 14: Diseño de objetos Modelado Ágil y Dibujo UML ligero
Modelado Ágil y Dibujo UML ligero
Algunos objetivos de modelado ágil son reducir la sobrecarga de
dibujo y modelado para comprender y comunicar, en lugar de
para documentar.
El modelado ágil también incluye:
Modelar con otros.
Capítulo 14: Diseño de objetos Herramientas CASE UML
Contenido
4
Capítulo 14: Diseño de objetos
Introducción
Modelado Ágil y Dibujo UML ligero
Herramientas CASE UML
¿Cuánto tiempo dedicar a dibujar UML antes de codificar?
Diseñando objetos: ¿Qué es el modelado estático y dinámico?
La importancia de la habilidad de diseñar objetos sobre
habilidad de notación UML
Capítulo 14: Diseño de objetos Herramientas CASE UML
Herramientas CASE UML
Elija una herramienta CASE UML que se integre con algún IDE
popular como Eclipse o Visual Studio.
Elija una herramienta UML que pueda realizar ingeniería inversa
(generar diagramas a partir de código) no sólo diagramas de
clases, sino también diagramas de interacción.
Capítulo 14: Diseño de objetos ¿Cuánto tiempo dedicar a dibujar UML antes de codificar?
Contenido
4
Capítulo 14: Diseño de objetos
Introducción
Modelado Ágil y Dibujo UML ligero
Herramientas CASE UML
¿Cuánto tiempo dedicar a dibujar UML antes de codificar?
Diseñando objetos: ¿Qué es el modelado estático y dinámico?
La importancia de la habilidad de diseñar objetos sobre
habilidad de notación UML
Capítulo 14: Diseño de objetos ¿Cuánto tiempo dedicar a dibujar UML antes de codificar?
¿Cuánto tiempo dedicar a dibujar UML antes de
codificar?
Para una iteración de tres semanas, pasar unas horas o como
mucho un día (con el equipo) cerca del inicio de la iteración ”en
las paredes” (o con una herramienta CASE UML) dibujando UML
para las partes difíciles y creativas del diseño de objetos
detallado. Después deje de dibujar y tome fotos digitales, imprima
las fotos, y continue con la codificación el resto de la iteración.
Pueden ocurrir sesiones de dibujo más cortas a lo largo de la
iteración.
Capítulo 14: Diseño de objetos Diseñando objetos: ¿Qué es el modelado estático y dinámico?
Contenido
4
Capítulo 14: Diseño de objetos
Introducción
Modelado Ágil y Dibujo UML ligero
Herramientas CASE UML
¿Cuánto tiempo dedicar a dibujar UML antes de codificar?
Diseñando objetos: ¿Qué es el modelado estático y dinámico?
La importancia de la habilidad de diseñar objetos sobre
habilidad de notación UML
Capítulo 14: Diseño de objetos Diseñando objetos: ¿Qué es el modelado estático y dinámico?
Diseñando objetos: ¿Qué es el modelado estático y
dinámico?
Capítulo 14: Diseño de objetos de notación UMLLa importancia de la habilidad de diseñar objetos sobre habilidad
Contenido
4
Capítulo 14: Diseño de objetos
Introducción
Modelado Ágil y Dibujo UML ligero
Herramientas CASE UML
¿Cuánto tiempo dedicar a dibujar UML antes de codificar?
Diseñando objetos: ¿Qué es el modelado estático y dinámico?
La importancia de la habilidad de diseñar objetos sobre
habilidad de notación UML
Capítulo 14: Diseño de objetos de notación UMLLa importancia de la habilidad de diseñar objetos sobre habilidad
La importancia de la habilidad de diseñar objetos
sobre habilidad de notación UML
Dibujar UML es un reflejo de la toma de decisiones sobre el
diseño.
Las habilidades de diseño de objetos son lo que importa, no
saber cómo dibujar UML.
El diseño de objetos fundamental requiere el conocimiento de:
Principios de asignación de responsabilidades
Patrones de diseño
Capítulo 14: Diseño de objetos Otra técnica de diseño de obetos: tarjetas CRC
Contenido
4
Capítulo 14: Diseño de objetos
Introducción
Modelado Ágil y Dibujo UML ligero
Herramientas CASE UML
¿Cuánto tiempo dedicar a dibujar UML antes de codificar?
Diseñando objetos: ¿Qué es el modelado estático y dinámico?
La importancia de la habilidad de diseñar objetos sobre
habilidad de notación UML
Capítulo 14: Diseño de objetos Otra técnica de diseño de obetos: tarjetas CRC
Otra técnica de diseño de obetos: tarjetas CRC
Las Tarjetas CRC (Class Responsibility Collaboration) son tarjetas
de papel en las que uno escribe las responsabilidades y
Capítulo 15: Diagramas de interacción UML
Contenido
5
Capítulo 15: Diagramas de interacción UML
Introducción
Diagramas de secuencia y de comunicación
Notación común en los diagramas de interacción UML
Objetos singleton
Notación básica de los diagramas de secuencia
Notación básica de los diagramas de comunicación
Capítulo 15: Diagramas de interacción UML Introducción
Contenido
5
Capítulo 15: Diagramas de interacción UML
Introducción
Diagramas de secuencia y de comunicación
Notación común en los diagramas de interacción UML
Objetos singleton
Notación básica de los diagramas de secuencia
Notación básica de los diagramas de comunicación
Capítulo 15: Diagramas de interacción UML Introducción
Introducción
El UML incluye diagramas de interacción para ilustrar cómo los
objetos interactúan a través de mensajes. Se utilizan para el
modelado de objetos dinámico.
Hay dos tipos comunes:
diagramas de secuencia y diagramas
de comunicación.
Capítulo 15: Diagramas de interacción UML Diagramas de secuencia y de comunicación
Contenido
5
Capítulo 15: Diagramas de interacción UML
Introducción
Diagramas de secuencia y de comunicación
Notación común en los diagramas de interacción UML
Objetos singleton
Notación básica de los diagramas de secuencia
Notación básica de los diagramas de comunicación
Capítulo 15: Diagramas de interacción UML Diagramas de secuencia y de comunicación
Diagramas de secuencia y de comunicación
De los dos tipos, los diagramas de secuencia son los más ricos
en notación.
Los diagramas de secuencia ilustran las interacciones en un tipo
de formato de valla, en el que se añade cada nuevo objeto a la
derecha.
Capítulo 15: Diagramas de interacción UML Diagramas de secuencia y de comunicación
Diagramas de secuencia y de comunicación
Los Diagramas de Comunicación ilustran las interacciones de
objetos en un formato de grafo o red, en el que los objetos se
pueden colocar en cualquier lugar del diagrama.
Capítulo 15: Diagramas de interacción UML Diagramas de secuencia y de comunicación
Diagramas de secuencia y de comunicación
Fortalezas y debilidades del diagrama de secuencia frente al
diagrama de comunicación
Tipo
Fortalezas
Debilidades
Secuencia
Muestra claramente
se-cuencia u
ordenamien-to de los mensajes.
Amplio conjunto de
op-ciones de notación
de-talladas
Obligado a extender a
la derecha al agregar
nuevos objetos;
consu-me espacio horizontal
Comunicación
Se adapta mejor al
es-pacio. Flexibilidad para
añadir nuevos objetos
Es más difícil ver la
se-cuencia de mensajes.
Menos opciones de
no-Capítulo 15: Diagramas de interacción UML Notación común en los diagramas de interacción UML
Contenido
5
Capítulo 15: Diagramas de interacción UML
Introducción
Diagramas de secuencia y de comunicación
Notación común en los diagramas de interacción UML
Objetos singleton
Notación básica de los diagramas de secuencia
Notación básica de los diagramas de comunicación
Capítulo 15: Diagramas de interacción UML Notación común en los diagramas de interacción UML
Notación común en los diagramas de interacción UML
Capítulo 15: Diagramas de interacción UML Notación común en los diagramas de interacción UML
Notación común en los diagramas de interacción UML
Sintaxis básica de expresión de mensajes
Sintaxis
return = message(parameter : parameterType) : returnType
Los paréntesis son generalmente excluidos si no hay parámetros, aunque sigue siendo válido.Los tipos de información pueden ser excluidos si son obvios o sin importancia.
Ejemplos:
initialize(code)
initialize
Capítulo 15: Diagramas de interacción UML Objetos singleton
Contenido
5
Capítulo 15: Diagramas de interacción UML
Introducción
Diagramas de secuencia y de comunicación
Notación común en los diagramas de interacción UML
Objetos singleton
Notación básica de los diagramas de secuencia
Notación básica de los diagramas de comunicación
Capítulo 15: Diagramas de interacción UML Objetos singleton
Objetos singleton
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de secuencia
Contenido
5
Capítulo 15: Diagramas de interacción UML
Introducción
Diagramas de secuencia y de comunicación
Notación común en los diagramas de interacción UML
Objetos singleton
Notación básica de los diagramas de secuencia
Notación básica de los diagramas de comunicación
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de secuencia
Notación básica de los diagramas de secuencia
Las cajas de línea de vida poseen una línea en la parte inferior
llamada línea de vida.
Los mensajes síncronos se ilustran con un mensaje en una flecha
rellena entre las líneas de vida.
Pueden mostrar el foco de control utilizando una barra de
especificación de ejecución. La barra es opcional.
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de secuencia
Notación básica de los diagramas de secuencia
Ilustrando respuestas o valores de retorno
Uso de la sintaxis returnVar mensaje = mensaje (parámetro).
Uso de una línea de mensajes de respuesta (o retorno) en el
extremo de una barra de activación.
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de secuencia
Notación básica de los diagramas de secuencia
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de secuencia
Notación básica de los diagramas de secuencia
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de secuencia
Notación básica de los diagramas de secuencia
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de secuencia
Notación básica de los diagramas de secuencia
Marcos en los diagramas de secuencia UML
Los marcos son regiones o fragmentos de los diagramas. Tienen
un operador o etiqueta (como loop) y un guarda (cláusula
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de secuencia
Notación básica de los diagramas de secuencia
Operador
Significado
alt
Fragmento alternativo para la lógica
condicio-nal de la exclusión mutua expresada por los
guardas.
loop
Fragmento Loop mientras que el guarda es
ver-dadero. También puede escribir loop (n) para
indicar un bucle de n veces. Está en discusión
que la especificación será mejorada para
defi-nir un bucle for, como loop (i, 1, 10).
opt
Fragmento opcional que se ejecuta si el guarda
es verdadero.
para-Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de secuencia
Notación básica de los diagramas de secuencia
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de secuencia
Notación básica de los diagramas de secuencia
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de secuencia
Notación básica de los diagramas de secuencia
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de secuencia
Notación básica de los diagramas de secuencia
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de secuencia
Notación básica de los diagramas de secuencia
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de secuencia
Notación básica de los diagramas de secuencia
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de secuencia
Notación básica de los diagramas de secuencia
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de secuencia
Notación básica de los diagramas de secuencia
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de comunicación
Contenido
5
Capítulo 15: Diagramas de interacción UML
Introducción
Diagramas de secuencia y de comunicación
Notación común en los diagramas de interacción UML
Objetos singleton
Notación básica de los diagramas de secuencia
Notación básica de los diagramas de comunicación
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de comunicación
Notación básica de los diagramas de comunicación
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de comunicación
Notación básica de los diagramas de comunicación
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de comunicación
Notación básica de los diagramas de comunicación
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de comunicación
Notación básica de los diagramas de comunicación
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de comunicación
Notación básica de los diagramas de comunicación
Número de secuencia de mensajes
1
El primer mensaje no está numerado.
2
La secuencia y el anidamiento de los mensajes subsiguientes se
muestra con un esquema de numeración en el que los mensajes
anidados tienen un número añadido a ellos. Usted denota
anidación anteponiendo el número del mensaje entrante en el
número del mensaje saliente.
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de comunicación
Notación básica de los diagramas de comunicación
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de comunicación
Notación básica de los diagramas de comunicación
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de comunicación
Notación básica de los diagramas de comunicación
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de comunicación
Notación básica de los diagramas de comunicación
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de comunicación
Notación básica de los diagramas de comunicación
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de comunicación
Notación básica de los diagramas de comunicación
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de comunicación
Notación básica de los diagramas de comunicación
Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de comunicación
