Applying UML and Patterns (Capítulos 11,12,13,14 y 15)ertello/swe/sesion11.pdf · 2014. 7. 17. · Applying UML and Patterns (Capítulos 11,12,13,14 y 15) Giomara LÁRRAGA MALDONADO

Applying UML and Patterns (Capítulos 11,12,13,14y 15)

Giomara LÁRRAGA MALDONADO

CINVESTAV-Tamaulipas

10 de Octubre de 2012

Giomara LÁRRAGA MALDONADO (CINVESTAV) Applying UML and Patterns 10 de Octubre de 2012 1 / 106

Capítulo 11: Contratos de operación

Contenido

1 Capítulo 11: Contratos de operaciónIntroducciónSecciones de un contratoOperación del sistemaPostcondicionesPreguntas frecuentesAplicando UML: Operaciones, Contratos, y OCLContratos de operación en el Proceso Unificado


Capítulo 11: Contratos de operación Introducción

Contenido



Capítulo 11: Contratos de operación Introducción

Introducción

Los contratos de operación utilizan una forma de pre-ypost-condición para describir los cambios detallados a objetos enun modelo de dominio, como resultado de una operación delsistema.

Los contratos de operación pueden ser considerados como partedel Modelo de Casos de Uso, ya que proporcionan un análisisdetallado sobre el efecto de las operaciones del sistemaimplicados en los casos de uso.


Capítulo 11: Contratos de operación Secciones de un contrato

Contenido




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ónpuede ocurrir.Precondiciones: Suposiciones notables sobre el estado delsistema o de los objetos en el modelo de dominio antes de laejecución de la operación.Postcondiciones: El estado de los objetos en el modelo dedominio después de completar la operación.


Capítulo 11: Contratos de operación Operación del sistema

Contenido



Capítulo 11: Contratos de operación Operación del sistema

Operación del sistema

Los contratos de operación se pueden definir para operacionesdel sistema que éste ofrece en su interfaz pública como una cajanegra.


Capítulo 11: Contratos de operación Postcondiciones

Contenido



Capítulo 11: Contratos de operación Postcondiciones

Postcondiciones

Las postcondiciones describen los cambios en el estado de losobjetos en el modelo de dominio. Los cambios de estado en elModelo de Dominio incluyen instancias creadas, las asociacionesformadas o rotas, y atributos cambiados.

Las postcondiciones no son acciones que deben realizarsedurante la operación.

Un contrato es una excelente herramienta de análisis derequisitos u OOA que describe con gran detalle los cambios querequiere una operación del sistema (en términos de los objetos demodelo de dominio) sin tener que describir cómo se van a lograr.


Capítulo 11: Contratos de operación Preguntas frecuentes

Contenido




Preguntas frecuentes

¿Se debe actualizar el modelo de dominio?: En los métodositerativos y evolutivos, todos los artefactos de análisis y diseño seconsideran parciales e imperfectos, y evolucionan en respuesta alos nuevos descubrimientos.

¿Cuándo son útiles los contratos?: Cuando los detalles y lacomplejidad de los cambios de estado necesarios son difíciles odemasiado detallados para capturar en casos de uso. Si losdesarrolladores fácilmente puede entender qué hacer sin ellos,entonces se evita escribirlos.



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 noestá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.Asociaciones creadas y rotas.


Capítulo 11: Contratos de operación Aplicando UML: Operaciones, Contratos, y OCL

Contenido



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 unalgoritmo o solución, sino sólo los cambios de estado o losefectos de la operación.

Los contratos se pueden aplicar a las operaciones en cualquiernivel de granularidad.

El OCL (Object Constraint Language) define un formato oficialpara la especificación de pre y postcondiciones de lasoperaciones, como se demuestra en el siguiente fragmento:

System :: makeNewSale ()pre: post: ...


Capítulo 11: Contratos de operación Contratos de operación en el Proceso Unificado

Contenido



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 muydetallados.Elaboración: Si se decide utilizarlos, son escritos durante la etapade elaboración, ya que ha sido escrita la mayor parte de los casosde uso. Sólo se hacen contratos para las operaciones máscomplejas y sutiles.


Capítulo 12: Requerimientos para diseñar iterativamente

Contenido

2 Capítulo 12: Requerimientos para diseñar iterativamenteIntroducciónHaz lo correcto iterativamente, haz las cosas bienProvocando el cambio temprano¿No todo ese análisis y modelado toman semanas enrealizarse?


Capítulo 12: Requerimientos para diseñar iterativamente Introducción

Contenido



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



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 enaprender a hacer lo correcto, es decir, la comprensión de algunosde los objetivos pendientes de los casos de estudio y las normasy limitaciones relacionadas. Por el contrario, el siguiente trabajode diseño se esfuerza en hacer las cosas bien, es decir, conhabilidad de diseñar una solución para satisfacer los requisitos deesta iteración.


Capítulo 12: Requerimientos para diseñar iterativamente Provocando el cambio temprano

Contenido



Capítulo 12: Requerimientos para diseñar iterativamente Provocando el cambio temprano

Provocando el cambio temprano

Es natural y saludable descubrir y cambiar algunos requisitosdurante el trabajo de diseño e implementación, especialmente enlas primeras iteraciones, de modo que tenemos una meta másestable para las iteraciones posteriores.

En el transcurso de las iteraciones de elaboración tempranas, eldescubrimiento de requisitos se debe estabilizar, por lo que alfinal de la elaboración, quizás el 80 % de los requisitos sondefinidos y refinados como resultado de la retroalimentación, laprogramación temprana y las pruebas, en lugar de laespeculación, como se produce con el método de cascada.


Capítulo 12: Requerimientos para diseñar iterativamente ¿No todo ese análisis y modelado toman semanas en realizarse?

Contenido



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 enrealizarse?

Cuando uno se siente cómodo con sus habilidades de escriturade casos de uso, modelos de dominio,etc. , el tiempo para hacertodo 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 elcomienzo del proyecto. Muchas otras actividades, tales como laprogramación de prueba de concepto, búsqueda de recursos(personas, software, ...), la planificación, la configuración delentorno, etc. , podrían consumir un par de semanas depreparación.


Capítulo 13: Arquitectura lógica y diagramas de paquetes UML

Contenido

3 Capítulo 13: Arquitectura lógica y diagramas de paquetes UMLIntroducción¿Qué es la arquitectura de software?Aplicando UML: Diagramas de paquetesDiseñar en capasEl principio de separación Modelo-Vista¿Cuál es la conexión entre los SSD, operaciones del sistema, ylas capas?


Capítulo 13: Arquitectura lógica y diagramas de paquetes UML Introducción

Contenido




Introducción

El diseño de un sistema típico de OO se basa en varias capas dearquitectura, tales como una capa de interfaz de usuario, unacapa lógica de aplicación, etc. En este capítulo se explora unaarquitectura lógica por capas y notación UML relacionada.



Introducción


Capítulo 13: Arquitectura lógica y diagramas de paquetes UML ¿Qué es la arquitectura de software?

Contenido



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 sobrela organización de un sistema de software, la selección de loselementos estructurales y las interfaces por las que estácompuesto el sistema, junto con su comportamiento tal como seespecifica en las colaboraciones entre esos elementos, lacomposición de estos elementos estructurales y decomportamiento en subsistemas progresivamente más grandes, yel estilo arquitectónico que guía esta organización, estoselementos y sus interfaces, sus colaboraciones y su composición.


Capítulo 13: Arquitectura lógica y diagramas de paquetes UML Aplicando UML: Diagramas de paquetes

Contenido



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 parailustrar la arquitectura lógica de un sistema, las capas, lossubsistemas, paquetes (en el sentido de Java), etc. Una capapuede ser modelada como un paquete UML.

Un diagrama de paquetes UML proporciona una forma de agruparelementos


Capítulo 13: Arquitectura lógica y diagramas de paquetes UML Diseñar en capas

Contenido




Diseñar en capas

Las ideas esenciales del uso de capas son simples:Organizar la estructura lógica a gran escala de un sistema encapas discretas de responsabilidades distintas, relacionadas, conuna separación clara y coherente de asuntos tal que las ’capasbajas’ son servicios de bajo nivel y generales, y las capas másaltas son más específicas.La colaboración y el acoplamiento es de capas más altas a capasinferiores; el acoplamiento de capa menor a mayor se evita.



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 seentrelazan con más lógica especifica de la aplicación.Existe alto acoplamiento en las diferentes áreas de interés.



Diseñar en capas

Ventajas de usar capasHay una separación de aspectos, una separación de servicios dealto y bajo nivel, y de los servicios específicos de los serviciosgenerales. Esto reduce el acoplamiento y dependencias, mejorala cohesión, aumenta el potencial de reutilización, y la claridadaumenta.

La complejidad relacionada es encapsulada y descomponible.

Algunas capas pueden ser reemplazadas con nuevasimplementaciones.

Las capas inferiores contienen funciones reutilizables.

El desarrollo por equipos es ayudado por la segmentación lógica.



Diseñar en capas

Capa de dominio vs Capa Lógica de Aplicación; objetos dedominio

Un sistema de software típico tiene una lógica de interfaz deusuario y la lógica de la aplicación.Los objetos de dominio representan un cosa en el espacio dedominio del problema, y tiene lógica de aplicación y de negociorelacionada.Diseñar objetos de ésta manera hace que a la capa de lógica deaplicación se le llame más precisamente la capa de dominio de laarquitectura. La capa que contiene los objetos de dominio paramanejar el trabajo de la lógica de la aplicación.



Diseñar en capas

Relación entre la capa de dominio y el modelo de dominio.



Diseñar en capas

Niveles, capas, y Particiones



Diseñar en capas

No mostrar los recursos externos como la capa inferior


Capítulo 13: Arquitectura lógica y diagramas de paquetes UML El principio de separación Modelo-Vista

Contenido




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 dominiode objetos. La Vista es un sinónimo de objetos de interfaz deusuario, tales como ventanas, páginas web, applets,e informes.




El principio de separación de Modelo-Vista afirma que los objetosdel modelo (dominio) no deben tener un conocimiento directo dela vista (UI).

Éste es un principio fundamental en el patrónModelo-Vista-Controlador (MVC). El modelo es la capa dedominio, la vista es la capa de interfaz de usuario y loscontroladores son los objetos de flujo de trabajo en la capa deaplicación.




La motivación para la Separación Modelo-Vista incluye:Apoyar las definiciones de modelo coherentes que se centran enlos procesos de dominio, en lugar de en las interfaces de usuario.Permitir el desarrollo independiente de la capa de modelo y de lacapa de interfaz de usuario.Minimizar el impacto de los cambios en los requisitos de la interfazsobre la capa de dominio.Permitir a nuevas vistas ser fácilmente conectadas a una capa dedominio 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 lacapa de interfaz de usuario, tal como en un sistema deprocesamiento de mensajes o en modo por lotes.Para permitir la fácil portabilidad de la capa de modelo a otroframework de interfaz de usuario.


Capítulo 13: Arquitectura lógica y diagramas de paquetes UML¿Cuál es la conexión entre los SSD, operaciones del sistema, y

las capas?

Contenido



Capítulo 13: Arquitectura lógica y diagramas de paquetes UML¿Cuál es la conexión entre los SSD, operaciones del sistema, y

las capas?

¿Cuál es la conexión entre los SSD, operaciones delsistema, y las capas?

Los mensajes enviados desde la capa de interfaz de usuario a lacapa 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 objetosIntroducciónModelado Ágil y Dibujo UML ligeroHerramientas 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 sobrehabilidad de notación UMLOtra técnica de diseño de obetos: tarjetas CRC


Capítulo 14: Diseño de objetos Introducción

Contenido



Capítulo 14: Diseño de objetos Introducción

Introducción

¿Cómo diseñan objetos los desarrolladores?1 Código2 Dibujar, luego escribir código3 Sólo dibujar


Capítulo 14: Diseño de objetos Modelado Ágil y Dibujo UML ligero

Contenido



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 dedibujo y modelado para comprender y comunicar, en lugar depara documentar.

El modelado ágil también incluye:Modelar con otros.La creación de varios modelos en paralelo.


Capítulo 14: Diseño de objetos Herramientas CASE UML

Contenido



Capítulo 14: Diseño de objetos Herramientas CASE UML

Herramientas CASE UML

Elija una herramienta CASE UML que se integre con algún IDEpopular 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 declases, 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



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 decodificar?

Para una iteración de tres semanas, pasar unas horas o comomucho un día (con el equipo) cerca del inicio de la iteración ”enlas paredes” (o con una herramienta CASE UML) dibujando UMLpara las partes difíciles y creativas del diseño de objetosdetallado. Después deje de dibujar y tome fotos digitales, imprimalas 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 laiteración.


Capítulo 14: Diseño de objetos Diseñando objetos: ¿Qué es el modelado estático y dinámico?

Contenido



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 ydinámico?

Pase un tiempo significativo haciendo diagramas de interacción(diagramas de secuencia o de comunicación), no sólo diagramasde clase.


Capítulo 14: Diseño de objetosLa importancia de la habilidad de diseñar objetos sobre habilidad

de notación UML

Contenido



Capítulo 14: Diseño de objetosLa importancia de la habilidad de diseñar objetos sobre habilidad

de notación UML

La importancia de la habilidad de diseñar objetossobre habilidad de notación UML

Dibujar UML es un reflejo de la toma de decisiones sobre eldiseño.

Las habilidades de diseño de objetos son lo que importa, nosaber cómo dibujar UML.

El diseño de objetos fundamental requiere el conocimiento de:Principios de asignación de responsabilidadesPatrones de diseño


Capítulo 14: Diseño de objetos Otra técnica de diseño de obetos: tarjetas CRC

Contenido



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 tarjetasde papel en las que uno escribe las responsabilidades ycolaboradores de las clases. Cada tarjeta representa una clase.


Capítulo 15: Diagramas de interacción UML

Contenido

5 Capítulo 15: Diagramas de interacción UMLIntroducciónDiagramas de secuencia y de comunicaciónNotación común en los diagramas de interacción UMLObjetos singletonNotación básica de los diagramas de secuenciaNotación básica de los diagramas de comunicación


Capítulo 15: Diagramas de interacción UML Introducción

Contenido



Capítulo 15: Diagramas de interacción UML Introducción

Introducción

El UML incluye diagramas de interacción para ilustrar cómo losobjetos interactúan a través de mensajes. Se utilizan para elmodelado de objetos dinámico.

Hay dos tipos comunes: diagramas de secuencia y diagramasde comunicación.


Capítulo 15: Diagramas de interacción UML Diagramas de secuencia y de comunicación

Contenido




Diagramas de secuencia y de comunicación

De los dos tipos, los diagramas de secuencia son los más ricosen notación.

Los diagramas de secuencia ilustran las interacciones en un tipode formato de valla, en el que se añade cada nuevo objeto a laderecha.




Los Diagramas de Comunicación ilustran las interacciones deobjetos en un formato de grafo o red, en el que los objetos sepueden colocar en cualquier lugar del diagrama.




Fortalezas y debilidades del diagrama de secuencia frente aldiagrama de comunicación

Tipo Fortalezas DebilidadesSecuencia Muestra claramente se-

cuencia u ordenamien-to de los mensajes.Amplio conjunto de op-ciones de notación de-talladas

Obligado a extender ala derecha al agregarnuevos objetos; consu-me espacio horizontal

Comunicación Se adapta mejor al es-pacio. Flexibilidad paraañadir nuevos objetosen dos dimensiones

Es más difícil ver la se-cuencia de mensajes.Menos opciones de no-tación.


Capítulo 15: Diagramas de interacción UML Notación común en los diagramas de interacción UML

Contenido




Notación común en los diagramas de interacción UML

Ilustrando participantes con cajas de línea de vida:



Notación común en los diagramas de interacción UML

Sintaxis básica de expresión de mensajes

Sintaxisreturn = message(parameter : parameterType) : returnTypeLos 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)initialized = getProductDescription(id)d = getProductDescription(id:ItemID)d = getProductDescription(id:ItemID) : ProductDescription


Capítulo 15: Diagramas de interacción UML Objetos singleton

Contenido



Capítulo 15: Diagramas de interacción UML Objetos singleton

Objetos singleton

El patrón singleton provee una única instancia global.


Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de secuencia

Contenido




Notación básica de los diagramas de secuencia

Las cajas de línea de vida poseen una línea en la parte inferiorllamada línea de vida.

Los mensajes síncronos se ilustran con un mensaje en una flecharellena entre las líneas de vida.

Pueden mostrar el foco de control utilizando una barra deespecificación de ejecución. La barra es opcional.




Ilustrando respuestas o valores de retornoUso de la sintaxis returnVar mensaje = mensaje (parámetro).

Uso de una línea de mensajes de respuesta (o retorno) en elextremo de una barra de activación.




Mensajes a uno mismo




Creación de instancias




Destrucción de objetos




Marcos en los diagramas de secuencia UMLLos marcos son regiones o fragmentos de los diagramas. Tienenun operador o etiqueta (como loop) y un guarda (cláusulacondicional)




Operador Significadoalt Fragmento alternativo para la lógica condicio-

nal de la exclusión mutua expresada por losguardas.

loop Fragmento Loop mientras que el guarda es ver-dadero. También puede escribir loop (n) paraindicar un bucle de n veces. Está en discusiónque la especificación será mejorada para defi-nir un bucle for, como loop (i, 1, 10).

opt Fragmento opcional que se ejecuta si el guardaes verdadero.

par Fragmentos paralelos que se ejecutan en para-lelo.

region Región crítica en la que sólo un hilo puede co-rrer.




Mensajes condicionales




Mensajes condicionales mutuamente exclusivos




Iteración sobre una colección. Notación explícita




Iteración sobre una colección. Notación implícita




Marcos anidados




¿Cómo relacionar diagramas de interacción?




Mensajes a clases para invocar métodos estáticos (de clase)




Mensajes polimórficos y casos


Capítulo 15: Diagramas de interacción UML Notación básica de los diagramas de comunicación

Contenido




Notación básica de los diagramas de comunicación

Enlaces




Mensajes




Mensajes a uno mismo




Creación de instancias




Número de secuencia de mensajes1 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 mensajesanidados tienen un número añadido a ellos. Usted denotaanidación anteponiendo el número del mensaje entrante en elnúmero del mensaje saliente.




Numeración compleja




Mensajes condicionales




Rutas condicionales mutuamente excluyentes




Iteraciones




Iteraciones sobre una colección




Invocación de métodos estáticos




Mensajes polimórficos y casos




Mensajes síncronos y asíncronos


1Capítulo 11: Contratos de operaciónIntroducciónSecciones de un contratoOperación del sistemaPostcondicionesPreguntas frecuentesAplicando UML: Operaciones, Contratos, y OCLContratos de operación en el Proceso Unificado

2Capítulo 12: Requerimientos para diseñar iterativamenteIntroducciónHaz lo correcto iterativamente, haz las cosas bienProvocando el cambio temprano¿No todo ese análisis y modelado toman semanas en realizarse?

3Capítulo 13: Arquitectura lógica y diagramas de paquetes UMLIntroducción¿Qué es la arquitectura de software?Aplicando UML: Diagramas de paquetesDiseñar en capasEl principio de separación Modelo-Vista¿Cuál es la conexión entre los SSD, operaciones del sistema, y las capas?

4Capítulo 14: Diseño de objetosIntroducciónModelado Ágil y Dibujo UML ligeroHerramientas 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 UMLOtra técnica de diseño de obetos: tarjetas CRC

5Capítulo 15: Diagramas de interacción UMLIntroducciónDiagramas de secuencia y de comunicaciónNotación común en los diagramas de interacción UMLObjetos singletonNotación básica de los diagramas de secuenciaNotación básica de los diagramas de comunicación

Documents

Applying UML and Patterns (Capítulos 11,12,13,14 y 15)ertello/swe/sesion11.pdf · 2014. 7. 17. · Applying UML and Patterns (Capítulos 11,12,13,14 y 15) Giomara LÁRRAGA MALDONADO