Análisis y diseño orientado a objetos - inf.utfsm.clliuba/taller/ad_oo1.pdf · ?Uso de UML?Introducción al proceso de desarrollo Fundamentos de Ingeniería de SW 74 UTFSM EX UMBRA

11

Fundamentos de Ingeniería de SW 73UTFSM

EX UMBRA SOLEMIN

Análisis y diseño orientado a objetosContenido

? ¿Qué es análisis?? ¿Qué es diseño?

? Análisis y diseño OO? Uso de UML

? Introducción al proceso de desarrollo


EX UMBRA SOLEMIN

Análisis y diseño orientado a objetosMuestra

? El proverbio “El hábito no hace el monje” se aplica perfectamente a la tecnología de objetos. ? El hecho de conocer un lenguaje orientado a objetos (por ej. Java)

y además tener acceso a una rica biblioteca (como la de Java) esun primer paso necesario pero insuficiente para crear sistemas de objetos.

? Se requiere además analizar y diseñar un sistema desde la perspectiva de objetos.


EX UMBRA SOLEMIN

Análisis y diseño orientado a objetosMuestra

? En conclusión, se ayudará a los ingenieros:? A aplicar los principios y patrones para aprender a desarrollar

mejores diseños. ? A efectuar varias actividades comunes en el análisis y en el diseño. ? A crear elementos útiles en la notación de UML.

? Todo lo anterior será ejemplificado con un caso.


EX UMBRA SOLEMIN

Análisis y diseño orientado a objetos¿Qué son análisis y diseño?

? El análisis se centra en la investigación del problema, no en la manera de definir la solución. ? Por ejemplo, si se necesita un nuevo sistema de biblioteca, ¿Cuáles

procesos de la institución se relacionan con su uso?

? El diseño pone de relieve una solución lógica: cómo el sistema cumple con los requerimientos. ? ¿De qué manera el sistema de la biblioteca capturará y registrará

los prestamos de libros?.

? La esencia de estas actividades consiste en situar el dominio de un problema y su solución lógica dentro de la perspectiva de los objetos.


EX UMBRA SOLEMIN


? Durante el análisis orientado a objetos se procura ante todo identificar y describir los objetos – o conceptos –dentro del dominio del problema.

? Durante el diseño orientado a objetos, se procura definir objetos lógicos del software.

? Finalmente, durante la construcción o programación orientada a objetos, se implementan los componentes de diseño.

Análisis Diseño Construcción

Investigación del problema

Solución Lógica Código


EX UMBRA SOLEMIN


Concepto de Dominio

Representación en el diseño

Representación en programación

Libro

titulo

public class Libro{ public void print();

Private String titulo;}

Análisis Diseño Construcción

22


EX UMBRA SOLEMIN

Análisis y diseño orientado a objetosEjemplo

? Para entender los requerimientos se necesita, en parte, conocer los procesos de dominio y el ambiente externo, o sea los factores externos que participan en los procesos.

? Dichos procesos se pueden expresar en forma de casos de uso, los cuales son una descripción narrativa del proceso de dominio en un formato estructurado de prosa.

Definición de los casos de uso

Definición del Modelo

conceptual

Definición de los Diagramas de colaboración

Definición de los Diagramas de

diseño de clases


EX UMBRA SOLEMIN


? Por ejemplo, en el juego de los dados: ? Caso de uso: Juega un juego? Participantes: Jugador?Descripción: Este caso de uso comienza cuando el jugador

recoge y hace rodar los dados. Si los puntos suman siete, gana ypierde si suman cualquier otro numero.



conceptual



diseño de clases


EX UMBRA SOLEMIN


? Para descomponer el dominio del problema hay que identificar los conceptos, los atributos y las asociaciones del dominio que se juzgan importantes.

? El resultado puede expresarse en un modelo conceptual, el cual se muestra gráficamente en un grupo de diagramas que describen los conceptos (objetos).



conceptual



diseño de clases


EX UMBRA SOLEMIN


? Por ejemplo, una parte del modelo conceptual muestra los conceptos de Jugador, Dados y Juego de dados, sus asociaciones y atributos.

Jugador

nombre

Juego de dados

Dado

valorMostrado

1Juega1

1 Incluye

1 Lanza 2

2



conceptual



diseño de clases


EX UMBRA SOLEMIN


? El modelo conceptual no es una descripción de los componentes de software; representa conceptos en el dominio del problema del mundo real.



conceptual



diseño de clases


EX UMBRA SOLEMIN


? El diseño orientado a objetos tiene por objetivo definir las especificaciones lógicas del software que cumplan con los requisitos funcionales.

? Un paso esencial en esta fase es la asignación de los responsabilidades entre los objetos y mostrar como interactúan a través de mensajes.

? El diagrama de colaboración presenta el flujo de mensajes entre las instancias y la invocación de métodos.



conceptual



diseño de clases

33


EX UMBRA SOLEMIN


? Por ejemplo, la figura muestra gráficamente el paso esencial del juego, enviando mensajes a las instancias de las clases Jugador y Dado.

:Jugador d1:Dadojugar() 1:r1:= lanzar()

d2:Dado2:r2:= lanzar()



conceptual



diseño de clases


EX UMBRA SOLEMIN


? Para definir una clase es preciso contestar varias preguntas: ? ¿Cómo se conectan unos objetos a otros? ? ¿Cuáles son los métodos de una clase?

? Por ejemplo, obtenemos que Jugador requiere de un método jugar, mientras que el Dado requiere de un método lanzar.



conceptual



diseño de clases


EX UMBRA SOLEMIN


? A diferencia del modelo conceptual, el modelo de diseño no muestra gráficamente conceptos del mundo real: describe únicamente los componentes del software.

Jugador

nombre

jugar()

Juego de dados

inicializar()

Dado

valorMostrado

lanzar()

1Juega1

1 Incluye

1 Lanza 2

2



conceptual



diseño de clases


EX UMBRA SOLEMIN

Análisis y diseño orientado a objetosComparación con AD estructurado

? Los proyectos de software son complejos, y la estrategia primaria para superar la complejidad es la descomposición (divide y vencerás): dividir el problema en unidades manejables.

? En el análisis y diseño estructurado, la dimensión de descomposición es fundamentalmente por función o proceso.

? En el análisis y diseño orientado a objetos buscan ante todo descomponer el espacio del problema por objetos.


EX UMBRA SOLEMIN

Análisis y diseño orientado a objetosComparación con AD estructurado

Sistema de la biblioteca

Catálogo Bibliotecario

BibliotecaLibro

Sistema

Registrar Préstamos

Agregar Recursos

Reportar Multas

A/D OODescomposición por objetos o conceptos

A/D estructuradosDescomposición por funciones o procesos


EX UMBRA SOLEMIN

Introducción al proceso de desarrolloDefinición

? Un proceso de desarrollo de software es un método de organizar las actividades relacionadas con la creación, presentación y mantenimiento de los sistemas de software.

? El lenguaje UML estandariza los artefactos y la notación, pero no define un proceso oficial de desarrollo. ? Aumentar las posibilidades de aceptación generalizada de la

notación estándar del modelado, sin la obligación de adaptar el proceso oficial.

? La esencia de un proceso apropiado admite mucha variación y depende de las habilidades del personal, de la naturaleza del problema, de las herramientas y muchos otro factores.

44


EX UMBRA SOLEMIN

Introducción al proceso de desarrolloPasos de macronivel

? En un nivel alto, los pasos principales de la presentación de una aplicación son los siguientes:

? Planificación y elaboración: planificar, definir los requerimientos, construir prototipos, etc.

? Construcción: la creación del sistema.? Aplicación: la transición de la implementación del sistema a

su uso.


EX UMBRA SOLEMIN

Introducción al proceso de desarrolloDesarrollo Iterativo

? Un ciclo de vida iterativo se basa en el agrandamiento y perfeccionamiento secuencial de un sistema a través de múltiples ciclos de desarrollo de análisis, diseño, implementación y pruebas.? Tras una fase preliminar de planificación y especificación, el

desarrollo pasa a la fase de construcción a través de una serie de ciclos de desarrollo.

Planificación y Elaboración Construcción Aplicación

Ciclo de desarrollo 1




EX UMBRA SOLEMIN


? En cada ciclo se aborda un conjunto relativamente pequeño de requerimientos, pasando por el análisis, el diseño, la construcción y las pruebas. ? El sistema va creciendo con cada ciclo que se concluye.

? Entre las ventajas de un ciclo iterativo figuran: ? La complejidad nunca resulta abrumadora.? Se produce retroalimentación en una etapa temprana, porque la

implementación se efectúa rápidamente con una parte pequeña del sistema.


EX UMBRA SOLEMIN


Planificación y Elaboración Construcción Aplicación




Perfeccionar el plan

Sincronización de artefactos

Análisis Diseño Construcción Prueba


EX UMBRA SOLEMIN

Introducción al proceso de desarrolloFijación de un ciclo de desarrollo

? Una estrategia muy útil consiste en limitar el ciclo de desarrollo a un marco temporal, un lapso rígidamente fijo. ? Todo el trabajo ha de concluirse en ese lapso. ? Un período entre dos y cuatro semanas suele ser conveniente.

? Para tener éxito con un programa de duración fija es necesario escoger los requerimientos con mucho cuidado y asignarle la selección al equipo de desarrollo.

Perfeccionar el plan



de 2 semanas a 2 meses


EX UMBRA SOLEMIN

Introducción al proceso de desarrolloCasos de uso y los ciclos de desarrollo iterativos

? Un caso de uso es una descripción narrativa de un proceso de dominio.? Por ejemplo: Obtener libros de una biblioteca. ? Los ciclos iterativos de desarrollo se organizan a partir de los

requerimientos del caso de uso. ? Se asigna un ciclo de desarrollo para implementar uno o más casos

de uso o bien sus versiones simplificadas (si el caso es muy complejo como para ser abordado en un sólo ciclo).

? Los casos de uso deberían clasificarse, y los que ocupen los niveles más altos han de abordarse en los ciclos iniciales de desarrollo.

55


EX UMBRA SOLEMIN

Introducción al proceso de desarrolloFase de planificación y elaboración

? Esta fase incluye la concepción inicial, la investigación de alternativas, la planificación, la especificación de requerimientos y otras actividades:

?Definir un plan preliminar ?Elaborar un informe preliminar de investigación

?Definir los requerimientos ?Registrar los términos en el glosario (constante)?Implementar el prototipo (opcional y aplazable) ?Definir los casos de uso (de alto nivel y esenciales) ?Definir el modelo conceptual preliminar (aplazable)?Definir la arquitectura preliminar del sistema (constante, opcional y

aplazable)?Perfeccionar el plan.


EX UMBRA SOLEMIN


? Entre los artefactos generados en esta fase se pueden mencionar los siguientes: ? Plan: programa, presupuesto, etc.? Informe preliminar de la investigación: motivos, alternativas,

necesidades de la empresa. ? Especificación de los requerimientos: declaración de los

requerimientos. ? Glosario: diccionario (nombres de conceptos, pro ejemplo) y toda

la información afín, como las restricciones y reglas. ? Prototipo: sistema de prototipos cuyo fin es facilitar la comprensión

del problema, los problemas de alto riesgo y los requerimientos.


EX UMBRA SOLEMIN


? Entre los artefactos generados en esta fase se pueden mencionar los siguientes: ? Casos de uso: descripciones narrativas de los procesos de dominio.

? Diagramas de casos de uso: descripción gráfica de todos los casos de uso y sus relaciones.

? Bosquejo del modelo conceptual: modelo conceptual preliminar cuya finalidad es facilitar el conocimiento del vocabulario del dominio, especialmente en su relación con los casos de uso y conlas especificaciones de los requerimientos.


EX UMBRA SOLEMIN


? El orden de la creación de artefactos no es necesariamente lineal como puede sugerir la lista anterior. ? Podemos preparar en paralelo algunos de ellos. Esto se aplica

especialmente al modelo conceptual, al glosario, a los casos de uso y a los diagramas de los casos.

? Los casos de uso son sometidos a un examen y, en cambio, el resto de los artefactos tienen por objeto reflejar la información proveniente de los casos.


EX UMBRA SOLEMIN

Introducción al proceso de desarrolloFase de construcción: ciclos de desarrollo

? La fase de construcción de un proyecto requiere varios ciclos de desarrollo a lo largo de los cuales se extiende el sistema. ? El objetivo final es obtener un sistema funcional que atienda

debidamente los requerimientos.

? En un ciclo individual de desarrollo, los principales pasos se analizan y diseñan, como se señala en la figura siguiente.


EX UMBRA SOLEMIN





Perfeccionamiento del plan



1. Definir casos esenciales de

uso

5. Definir diagramas de

secuencia

2. Perfeccionar el diagrama de

casos

6. Definir los contratos de operaciones

3. Perfeccionar el modelo

conceptual


estado

4. Perfeccionar el glosario

66


EX UMBRA SOLEMIN


? Como en el caso de los artefactos de la fase de requerimientos, algunos artefactos pueden ser creados en paralelo, por ejemplo:

?Modelo conceptual y glosario.? Diagramas de interacción y diagramas de diseño de clases.


EX UMBRA SOLEMIN

Introducción al proceso de desarrolloCuando crear el modelo conceptual

? El modelo conceptual es una representación de conceptos u objetos en el dominio del problema, como Libro y Biblioteca.

? Debe limitarse el esfuerzo aplicado a la creación de un modelo conceptual preliminar en la fase de planificación y elaboración, ya que en los dominios de problemas amplios, el modelo conceptual puede tornarse muy complejo.


EX UMBRA SOLEMIN

Introducción al proceso de desarrolloCuando crear el modelo conceptual

? La estrategia recomendada es generar rápidamente un modelo conceptual que se centre en identificar los conceptos obvios expresados en los requerimientos y posponer hasta más tarde una investigación con detenimiento.

? Otra estrategia es suspender la creación de un modelo conceptual hasta el inicio de los ciclos de desarrollo, lo cual tiene la desventaja de aplazar la complejidad.


EX UMBRA SOLEMIN

Introducción al proceso de desarrolloCuando crear los casos expandidos de uso

? Durante la fase de planificación y elaboración, se aconseja crear todos los casos de uso de alto nivel, pero describir los más importantes en el formato expandido, posponiendo el resto hasta el ciclo de desarrollo en que se estudian.

? Por lo tanto se recomienda estudiar detenidamente, durante la fase de planificación y elaboración sólo los casos de uso más importantes.


EX UMBRA SOLEMIN

Introducción al proceso de desarrolloDefinición de modelos y artefactos

? UML describe modelos de sistema basado en los conceptos de objetos.

? Todos los diagramas de UML pueden ser divididos en dos tipos. ? Un modelo estáticodel sistema describe las propiedades

estructurales del sistema.? Un modelo dinámicodescribe las propiedades del comportamiento

del sistema.


EX UMBRA SOLEMIN

Introducción al proceso de desarrolloModelo del sistema

? El modelo global del sistema esta constituido por:

? Modelo de análisis: el que se relaciona con una investigación de dominio y del ámbito del problema, pero no con la solución.

? Modelo de diseño: el que se relaciona con la solución lógica.

77


EX UMBRA SOLEMIN

Introducción al proceso de desarrolloRelación entre los artefactos

? Sin importar como los artefactos se organicen para construir los modelos, se dan dependencias muy importantes entre ellos. ? Por ejemplo, un diagrama de casos de uso depende de las

definiciones de los casos de uso.

? Si se crea un artefacto que no tenga otros dependientes y si no se usa como entrada de otra cosa, habrá que poner en tela de juicio su valor y el tiempo que se dedicó a su creación.


EX UMBRA SOLEMIN

Introducción al proceso de desarrolloRelación entre los artefactos

Informe preliminar de investigación

Prototipos

Presupuesto, programa de actividades

Especificación de requerimientos

Casos de uso:a)de alto nivel todos

b) algunos esenciales expandidos

Diagramas de casos de uso

Modelo conceptual preliminar

Glosario


EX UMBRA SOLEMIN

Análisis y diseño orientado a objetosResumen

? ¿Qué es análisis?? ¿Qué es diseño?

? Análisis y diseño OO? Uso de UML

? Introducción al proceso de desarrollo


EX UMBRA SOLEMIN

Análisis y diseño orientado a objetosQuiz

? ¿Cuál es la diferencia entre análisis y diseño OO?? ¿Porqué UML tiene tantos diagramas?

? ¿De qué sirve el “divide y vencerás” en OO?? ¿Qué es un proceso de desarrollo?

? ¿Qué pasa dentro de un ciclo de desarrollo?


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónContenido

? Especificación de Requerimientos? Casos de Uso: Descripción de Proceso

? Clasificación de los casos de uso? Inicio de un ciclo de desarrollo


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónEspecificación de requerimientos

? Con esta actividad se quieren lograr los siguientes objetivos: ? Crear los artefactos de la fase de requerimientos, por ejemplo, las

especificaciones de funciones.? Identificar y clasificar las funciones del sistema.? Identificar y crear los atributos del sistema y relacionarlos con las

funciones.

88


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónCaptura de Requerimientos

? Requerimientos son una descripción de necesidades o deseos para un producto.

?El reto consiste en definirlos de manera inequívoca, de modo que se detecten los riesgos y no se presenten sorpresas al momento de entregar el producto.

? Los siguientes tópicos son recomendados a ser desarrollados en esta fase:

? declaración general ? clientes ? objetivos? funciones del sistema ? atributos del sistema


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónEjemplo: Punto de venta

? Declaración general: el propósito de este proyecto es crear un sistema de punto de venta para ser usada en locales de venta.

? Clientes : Placeres Terrenales, Ltda, vendedor multinacional de objetos de relajación

? Objetivos : En general, la meta es hacer más rápido el procedimiento de pago de productos, para apoyar en forma mejor, más rápida y barata los procesos de servicios y negocios. Más específicamente esto incluye? Rápido pago y entrega de comprobante a los compradores

? Rápido y preciso análisis de ventas

? Control del inventario automático


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónFunciones y atributos del sistema

? Funciones del sistema son aquellas que el sistema se supone que tiene que hacer, tales como autorizar el pago con las tarjetas de crédito. ? Estas deben ser identificadas y anotadas en grupos lógicos y

cohesivos.

? Con el objeto de verificar que algún X es de verdad una función del sistema, la siguiente oración deberá tener sentido: ? El sistema deberá hacer <X>.? Por ejemplo: El sistema deberá autorizar los pagos con tarjetas de

crédito.


EX UMBRA SOLEMIN


? En cambio, los atributos del sistema son cualidades no-funcionales del sistema, como por ejemplo, la facilidad de uso, que a menudo se confunden con las funciones del sistema.

? Nótese que facilidad de uso no encaja en la oración de verificac ión: El sistema deberá hacer la facilidad de uso.

? Los atributos no deben formar parte de las especificaciones funcionales del sistema, sino de un documento independiente que especifica sus atributos.


EX UMBRA SOLEMIN


? Las funciones deben ser clasificadas en categorías para poder priorizarlas.

? Las categorías incluyen: ? Funciones Evidentes - Debe realizarse, el usuario esta consciente

que se ha realizado.? Funciones Ocultas - Debe realizar, pero no debe ser visible a los

usuarios.? Funciones Superfluas - Opcionales; su agregación no afecta

significativamente en el costo o en otras funciones.


EX UMBRA SOLEMIN


? Las siguientes funciones básicas del sistemas en la aplicación del punto de venta son una muestra significativa; no pretenden en absoluto ser exhaustivas.

Ref # Función CategoríaR1.1 Registrar la venta en proceso (actual): la lista de los artículos

compradosEvidente

R1.2 Calcular el total de la venta actual, incluyendo impuestos y descuentos Evidente…

R1.5 Registrar las ventas completadas Oculta…

R1.9 Mostrar la descripción y el precio del item Evidente

99


EX UMBRA SOLEMIN


? Sería mejor agrupar funciones en un orden lógico, por ejemplo, todas las funciones de pago.

Ref # Función CategoríaR2.1 Manejar los pagos con efectivo, capturando la cantidad entregada y

entregando el monto de vueltoEvidente

R2.2 Manejar los pagos con las tarjetas de crédito, capturando lainformación de la tarjeta tanto por el lector como manualmente

Evidente

…R2.4 Registrar los pagos con la tarjeta de crédito en el sistema de

contabilidad, para cobrarlos después a los bancos.Oculta


EX UMBRA SOLEMIN


? Los atributos del sistema son características o dimensiones del mismo: no son funciones. ? Por ejemplo, facilidad de uso, tolerancia a fallas, plataformas,

tiempo de respuesta, etc.

? Los atributos tienen un posible conjunto de detalles de atributos, los cuales tienden a ser valores discretos, confusos o simbólicos, por ejemplo:

?Tiempo de respuesta = (psicológicamente correcto) ?Facilidad de Uso =(¿???)


EX UMBRA SOLEMIN


? Algunos atributos del sistema también pueden tener restricciones de frontera del atributo, que son condiciones obligatorias, generalmente dentro de un rango numérico de los valores de un atributo, por ejemplo:

?Tiempo de respuesta = (5 segundos cómo máximo)

Atributo Detalle y limitaciónTiempo de respuesta (restricción de frontera) La descripción y el

precio aparecerán en menos de 5 segundos.Sistema Operativo (detalle) Microsoft Windows 95 y NT


EX UMBRA SOLEMIN


? Atributos del sistema en especificaciones de las funciones relacionan los atributos con las funciones que son afectados por ellos, además de definir el atributo obligatorio u opcional.? Una restricción de frontera suele ser obligatoria, pues de lo

contrario significaría que no era sólida.

Ref# Función Categ. Atributo Detalles yLimitaciones

Categ.

R1.9 Mostrar ladescripción y elprecio del item

Evidente Tiempo de respuesta La descripción y elprecio aparecerán enmenos de 5 segundos.

Requerido


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónCasos de uso: Descripción de procesos

? Objetivos:

? Identificar y escribir casos de uso? Diseñar diagramas de casos de uso.? Contrastar los casos de uso de alto nivel, tanto como expandidos.

? Contrastar los casos de uso esenciales con los reales.


EX UMBRA SOLEMIN


? La técnica de casos de uso se puede aplicar tanto al análisis estructurado, como al análisis orientado a objetos.

? Un caso de uso es un documento narrativo que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema para completar un proceso. ? Los casos de uso son historias o casos de utilización de un sistema. ? No son exactamente los requerimientos ni las especificaciones

funcionales, sino que ejemplifican e incluyen tácitamente los requerimientos en las historias que narran.

1010


EX UMBRA SOLEMIN


? Notación en UML

? El siguiente caso de uso de alto nivel describe clara y concisamente el proceso de comprar artículos en una tienda cuando se emplea una terminal en el punto de venta.

Comprar productos

Caso de uso: Comprar productosActores: Cliente, CajeroTipo: PrimarioDescripción: Un cliente llega a la caja registradora con los artículos que comprará.

El Cajero registra los artículos y cobra el importe. Al terminar laoperación, el Cliente se marcha con los artículos comprados.


EX UMBRA SOLEMIN


? Un caso de uso expandido muestra más detalles que uno de alto nivel? este tipo de casos suelen ser útiles para alcanzar el conocimiento

más profundo de los procesos y de los requerimientos.

Caso de uso: Comprar productos en efectivoActores: Cliente (iniciador), CajeroPropósito: Capturar una venta y su pago en efectivo.Resumen: Un cliente llega a la caja registradora con los artículos que co mprará.

El Cajero registra los artículos y recibe un pago en efectivo. Alterminar la operación, el Cliente se marcha con los artículoscomprados.

Tipo: PrimarioReferenciasCruzadas:

Funciones: R1.1, R1.2, R1.3, R1.7, R2.1


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónEjemplo: Punto de venta Curso Normal de Eventos

Acción de los actores Respuesta del sistema1. Este caso de uso comienza cuando unCliente llega a una caja de TPDV (Terminalde Punto de Ventas) con productos quedesea comprar.2. El Cajero registra la identificación de cadaproducto.Si hay varios productos de una mismacategoría, el Cajero también puede introducirla cantidad.

3. Determina el precio del producto eincorpora a la transacción actual lainformación correspondiente.Se presentan la descripción y el precio delproducto actual.

4. Al terminar de introducir el producto, elCajero indica a TPDV que se concluyo lacaptura del producto.

5. Calcula y presenta el total de la venta.

6. El Cajero indica el total al Cliente.


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónEjemplo: Punto de venta Curso Normal de Eventos

7. El Cliente efectúa el pago en efectivo – el“efectivo ofrecido” – posiblemente mayorque el total de la venta.8. El Cajero registra la cantidad de efectivorecibida.

9. Muestra al cliente la diferencia. Genera unrecibo.

10. El Cajero deposita el efectivo recibido yextrae el cambio de pago.El Cajero le da al Cliente el cambio y elrecibo impreso.

11. Registra la venta concluida.

12. El Cliente se marcha con los artículoscomprados.

Cursos alternativos? Línea 2: introducción del identificador inválido. Indicar error.? Línea 7: el cliente no tenía suficiente dinero. Cancelar la transacción de venta.


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónExplicación del formato expandido

Caso de uso: Nombre del caso de usoActores: Lista de actores (agentes externos), en la cual se indica quien inicia el

caso de uso.Propósito: Intención de caso de usoResumen: Repetición del resumen de alto nivel o alguna síntesis similar.Tipo: 1. Primario, secundario u opcional

2. Esencial o realReferenciasCruzadas:

Casos relacionados de uso y funciones también relacionadas delsistema.


EX UMBRA SOLEMIN


? La sección intermedia, curso normal de eventos, es la parte medular del formato expandido? Se describe en detalles la conversación interactiva entre los ac tores

y el sistema. ? Un aspecto esencial de la sección es que explica la secuencia más

común de los eventos; no incluye situaciones alternativas.

Acción del actor Respuesta del sistemaAcciones numeradas de los actores Descripciones numeradas de las respuestas

del sistema.

1111


EX UMBRA SOLEMIN


? La última sección, curso alternativo de los eventos, describe importantes opciones o excepciones que pueden presentarse en relación con el curso normal. ? Si son complejas, se pueden expandir y convertirlas en otros casos

de uso.

Cursos alternativosAlternativas que pueden ocurrir en el número de línea. Descripción de

excepciones.


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónActores

? El actor es una entidad externa del sistema que de alguna manera participa en la historia del caso de uso. ? Por lo regular estimula el sistema con eventos de entrada o recibe

algo de él. ? Los actores están representados por papel que desempeñan en el

caso: Cliente, Cajero, u otro.

? Notación en UML

Cajero


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónActores

? En un caso de uso hay un actor iniciador que produce la estimulación inicial y, posiblemente, otros actores participantes; tal vez convenga especificar quien es el iniciador. ? Los actores suelen ser los papeles representados por las personas,

pero también puede ser cualquier tipo de sistema externo. ? Algunos tipos de actores: ?Papeles que desempeñan las personas.

?Sistemas de computo.?Aparatos electrónicos o mecánicos.


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónErrores comunes con los casos de uso

? Un error común en la identificación de los casos de uso consiste en representar los pasos, las operaciones o las transacciones individuales como casos. ? Por ejemplo, podemos definir (incorrectamente) un caso

denominado "imprimir recibo", cuando en realidad esta operación no es más que un paso de un proceso más amplio del caso "comprar productos".

? Un caso de uso es una descripción de un proceso de principio a fin relativamente amplia, descripción que suele abarcar muchos pasos o transacciones; normalmente no es un paso o una actividad individual del proceso.


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónIdentificación de casos de uso

? Los siguientes pasos de la identificación de los casos de uso requieren de una lluvia de ideas y revisión exhaustiva de los documentos actuales sobre la especificación de requerimientos. ? Un método de identificación de los casos de uso se basa en

actores.?1. Se identifican los actores relacionados con un sistema o empresa. ?2. Para cada actor se identifican los procesos que inician o en los

cuales participan. ? Otro método de identificación de casos de uso se basa en eventos.?1. Se identifican los eventos externos a los que un sistema ha de

responder. ?2. Se relacionan los eventos con los actores y con los casos de uso.


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónIdentificación de casos de uso

? En la aplicación de punto de venta, algunos actores posiblemente relevantes y los procesos que inician son: ? Cajero ?registra?entrega el efectivo

? Cliente ?compra productos?paga productos

1212


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónCasos de uso, funciones del sistema y trazabilidad

? Las funciones del sistema identificadas durante la especificación previa de requerimientos deben asignarse a los casos de uso.

? Además, debe ser posible verificar, mediante la sección de referencias cruzadas, que todas las funciones hayan sido asignadas.


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónDiagramas de casos de uso

? Un diagrama de casos de uso explica gráficamente un conjunto de casos de uso de un sistema, los actores y la relación entre estos y los casos de uso. ? Diagrama parcial del ejemplo

Cliente

Comprar productos

Cajero


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónClasificación de casos de uso

? Los casos de uso deberían clasificarse en primarios, secundarios y opcionales para asignarles la prioridad de desarrollo. ? Los casos de uso primarios representan los procesos comunes más

importantes, como Comprar productos. ? Los casos secundarios de uso representan procesos menores o

raros; por ejemplo, Solicitud de surtir un nuevo producto. ? Los casos opcionales de uso representan procesos que pueden no

abordarse.


EX UMBRA SOLEMIN


? Los casos esenciales de uso son casos expandidos de que se expresan en una forma teórica que contiene poca tecnología y pocos detalles de implementación; las decisiones de diseño se posponen y se abstraen de la realidad, especialmente en lo concerniente a la interfaz usuaria. ? Retiro de efectivo es un ejemplo de caso de uso esencial.

Acción de los actores Respuesta del sistema1. El cliente se identifica. 2. Presenta opciones.3. ….. 4. …


EX UMBRA SOLEMIN


? En cambio un caso de uso real describe concretamente el proceso a partir de su diseño concreto actual, sujeto a las tecnologías especificas de entrada y salida, etc. ? Cuando se trata de la interfaz usuaria a menudo ofrece

presentaciones de pantalla y explica la interacción con los artefactos.

Acción de los actores Respuesta del sistema1. El cliente introduce su tarjeta. 2. Pide la clave personal (CP).3. Introduce la clave con un tecladonumérico.

4. Muestra menú de opciones.

5. … 6. …


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónSobre la notación

? Al caso de uso se le asigna un nombre que comience con un verbo para subrayar que se trata de un proceso. Por ejemplo, “Comprar productos”, “Introducir pedidos”.

? Comience un caso de uso expandido con la siguiente oración: 1. Este caso de uso comienza cuando <Actor> <inicia un evento>

? De este modo se estimula una identificación clara del actor y del evento iniciadores.

1313


EX UMBRA SOLEMIN


? Un caso de uso puede contener puntos de decisión. ? Por ejemplo, en Comprar productos, el cliente puede optar al pago

en efectivo, a crédito o con cheque al momento de pago.

? Si una de estas trayectorias es un caso significativo y si las otras alternativas son raras, inusuales o excepcionales, el caso típico deberá ser el único acerca del cual se escribe el curso normal de eventos y las opciones han de escribirse en la sección titulada Alternativas.


EX UMBRA SOLEMIN


? Pero en ocasiones el punto de decisión representa opciones cuya probabilidad es relativamente igual y normal; en este caso se utiliza la siguiente estructura notacional:1. En la sección curso normal de eventos, indique las ramas de las

subsecciones.2. Escriba una subsección en cada rama, utilizando otra vez el curso

normal de eventos. Inicie el evento numerando en 1 en cada sección.

3. Si las subsecciones tienen opciones, escríbalas en una sección de alternativas de cada subsección.


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónEjemplo de Punto de Ventas

Puntos de decisión

Sección: principal.Curso normal de eventosAcción de los actores Respuesta del sistema1. Este caso de uso comienza cuando unCliente llega a una caja de TPDV (Terminalde Punto de Ventas) con productos quedesea comprar.2. El Cajero registra la identificación de cadaproducto.Si hay varios productos de una mismacategoría, el Cajero también puede introducirla cantidad.

3. Determina el precio del producto eincorpora a la transacción actual lainformación correspondiente.Se presentan la descripción y el precio delproducto actual.

4. Al terminar de introducir el producto, elCajero indica a TPDV que se concluyó lacaptura del producto.



EX UMBRA SOLEMIN

Fase de planificación y elaboraciónEjemplo de Punto de Ventas

Puntos de decisión6. El cliente escoge el tipo de pagoa. Si paga en efectivo, consúltese la sección

de Pago en efectivo.b. Si paga a crédito, consúltese la sección

Pago con tarjeta de crédito.c. Si paga con cheque, consúltese la

sección Pago con cheque.7. Registra la venta terminada8. Imprime un recibo.

9. El Cajero le entrega al Cliente el reciboimpreso.10. El Cliente se marcha con los artículoscomprados.

Cursos alternativos? Línea 2: introducción del identificador inválido. Indicar error.


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónEjemplo de Punto de VentasPuntos de decisión

Sección: Pago en efectivoCurso normal de eventosAcción del actor Respuesta del sistema1. El Cliente efectúa el pago en efectivo – el“efectivo ofrecido” – posiblemente mayorque el total de la venta.2. El Cajero registra la cantidad de efectivorecibida.

3. Muestra al cliente la diferencia.

4. El Cajero deposita el efectivo recibido yextrae el cambio de pago.El Cajero le da al Cliente el cambio.

Cursos alternativos? Línea 7: el cliente no tenía suficiente dinero. Cancelar la tran sacción de venta.

Sección: Pago con tarjeta de créditoCursos normales y alternativos de la historia de pago con la tarjeta de crédito.

Sección: Pago con chequeCursos normales y alternativos de la historia de pago cheque.


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónPasos de especificación de casos de uso

1. Después de haber listado las funciones del sistema, identifique los actores y los casos de uso.

2. Escriba todos los casos de uso de alto nivel. Clasifíquelos en primarios, secundarios u opcionales.

3. Dibuje un diagrama de caso de uso.4. Escriba en el formato esencial expandido los casos de uso más

importantes, influyentes y riesgosos, a fin de entender y estimar mejor la naturaleza y las dimensiones del problema. Para evitar casos complejos posponga la escritura de la forma esencial expandida de los casos de uso menos importantes hasta los ciclos de desarrollo futuros.

1414


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónPasos de especificación de casos de uso

5. En teoría, los casos reales deberían posponerse hasta una fas e de diseño en el ciclo de desarrollo, porque su creación conlleva muchas decisiones de diseño. Pese a ello, a veces es necesario crear casos reales de uso durante la etapa inicial de los requerimientos en el caso de que las descripciones concretas facilitan notablemente la comprensión; los clientes exigen especificar los procesos de este forma.

6. Clasifique los casos de uso.


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónClasificación y programación de los casos de uso

? Suponiendo que todos los artefactos deseados hayan sido generados (por ejemplo, la especificación de los requerimientos y los casos de uso), el siguiente paso es iniciar la fase de construcción en el ciclo de desarrollo iterativo y comenzar a implementar el sistema.

? En un ciclo de desarrollo iterativo, la tarea de llenar los casos de uso se distribuye entre varios ciclos.


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónResumen

? Especificación de Requerimientos? Casos de Uso: Descripción de Proceso

? Clasificación de los casos de uso? Inicio de un ciclo de desarrollo


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónQuiz

? ¿Qué son los requerimientos?? ¿Qué relación tienen los requerimientos con las funciones y

los atributos del sistema?

? ¿Porqué las funciones se organizan en orden lógico?? ¿Para qué definir la relación entre atributos y funciones?

? ¿Qué es un caso de uso?? ¿Qué representa un diagrama de casos de uso?

? ¿Qué relación tienen los casos de uso con las funciones del sistema?


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónQuiz

? Interprete el siguiente diagrama de casos de uso.

Estudiante

seleccionar cursos a impartir

Profesor

crear lista de cursos

mantener infestudiante

crear catalogo curso

mantener infcurso

Secretario

mantener infprofesor

registrarse en cursos

S. Facturación

<<se comunica con>>

Valida usuario

<<usa>>

<<usa>>


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónContenido

? Dependencia de los artefactos? Técnicas de clasificación de casos de uso

? Formato extendido de los casos de uso? Análisis Orientado a Objetos ?Modelo conceptual? Formas de determinar conceptos

1515


EX UMBRA SOLEMIN


? La estrategia general consiste en escoger primero los casos que influyen profundamente en la arquitectura básica. Las cualidades de un caso de uso así son los siguientes: ? Tener una fuerte repercusión en el diseño arquitectónico; por

ejemplo, incorporar muchas clases a la capa del dominio o requerir servicios de persistencia.

? Con relativamente poco esfuerzo obtener información e ideas importantes sobre el diseño.

? Incluir funciones riesgosas, urgentes o complejas. ? Requerir una investigación a fondo o tecnología nueva o riesgosa. ? Representar los procesos primarios de la línea de negocios.? Apoyar directamente el aumento de ingresos o la reducción de

costos.


EX UMBRA SOLEMIN


? Un sistema simple y poco riguroso puede servir para realizar la clasificación: alto-mediano-bajo.

? Otro sistema es asignar un puntaje y sumar (posiblemente con ponderación) para obtener una calificación.

Caso de uso a b c d e f SumaComprar productos 5 3 2 0 5 3 18Y así sucesivamente


EX UMBRA SOLEMIN


? Con base a los criterios expuestos anteriormente, he aquí un ejemplo de clasificación de algunos casos de uso en la aplicación de punto de venta.

Clasificación Caso de uso JustificaciónAlto Comprar productos Corresponde a los criterios de calificación más

altos.Mediano Incorpora usuarios

Registra los productos compradosPaga los productos comprados

Afecta el subdominio de seguridad.Afecta el subdominio de seguridad.Proceso importante, afecta a contabilidad.

Bajo PagarIniciarCerrar

Efecto mínimo en la arquitectura.La definición depende de los otros casos de uso.Efecto mínimo en la arquitectura


EX UMBRA SOLEMIN


? Prácticamente todos los sistemas cuentan con un caso de arranque o inicio. ? Aunque este no ocupe un nivel alto conforme a otros criterios, es

preciso estudiar al menos una versión simplificada de él al comienzo del ciclo de desarrollo para presentar la inicialización supuesta en otros casos.


EX UMBRA SOLEMIN


? A partir de la clasificación, el Caso de uso Comprar productos debería incluirse en el primer ciclo de desarrollo, también puede abordarse una versión simple de Inicio para soportar los otros casos de uso.

? Siempre que se asigne un caso de uso, es necesario estimar si es posible resolverlo íntegramente en el lapso limitado de un ciclo (cuatro semanas, por ejemplo) o si el trabajo ha de ser distribuido en varios ciclos.


EX UMBRA SOLEMIN


? En esta situación, el caso de uso se redefine, como por ejemplo: ? Comprar productos versión 1 (pagos en efectivo, sin

actualizaciones de inventario, …) ? Comprar productos versión 2 (permitir cualquier tipo de pago)? Comprar productos versión 3 (completa, con actualizaciones del

inventario, etc.)

? Las versiones anteriores se distribuyen después a lo largo de una serie de ciclos de desarrollo junto con otros casos de uso.

1616


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónAsignación de casos de uso a ciclos de desarrollo

? Si nos basamos en la clasificación de los casos y de varias versiones de Comprar productos, podríamos asignar algunos ciclos al ciclo de desarrollo:

? Ciclo de desarrollo 1: Comprar productos versión 1, …? Ciclo de desarrollo 2: Comprar productos versión 2, …? Ciclo de desarrollo 3: Comprar productos versión 3, …? Ciclo de desarrollo 4: Registrar productos comprados, …, Pagar los

productos comprados, …


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónVersiones de caso de uso Comprar Productos

? Una vez que se ha decidido simplificar los casos de uso y expresarlo, hay que escribir versiones cada vez más complejas.

? También hay que especificar las simplificaciones, las metas y las suposiciones de cada versión.


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónVersión 1 de Comprar Productos

? Simplificaciones, metas y suposiciones ? Pagos en efectivo exclusivamente ? Sin mantenimiento de inventario? Es una tienda independiente, que no forma parte de ninguna

organización más grande.? Captura manual del código universal de producto (CUP); sin lector

de código de barras.? No se calculan los impuestos.? Sin cupones de descuento.? El cajero no tiene que registrar las ventas; no se controla el

acceso.? No se lleva un registro de los clientes individuales ni de sus hábitos

de compra.


EX UMBRA SOLEMIN


? Simplificaciones, metas y suposiciones ? No se controla la caja de efectivo.? En el recibo aparecen el nombre y la dirección de la tienda, la

fecha y la hora de la venta.? Ni la identificación del cajero, ni la de TPDV aparecen en el recibo.? Las ventas se registran en un documento histórico.


EX UMBRA SOLEMIN


Caso de uso: Comprar productos, versión 1Actores: Cliente (iniciador), CajeroPropósito: Capturar una venta y su pago en efectivo.Resumen: Un Cliente llega a la caja registradora con los artículos que co mprará.

El Cajero registra los artículos y recibe una pago en efectivo. Alterminar la operación, el Cliente se marcha con los artículoscomprados.

Tipo: PrimarioReferenciasCruzadas:

Funciones: R1.1, R1.2, R1.3, R1.7, R2.1


EX UMBRA SOLEMIN


Curso normal de eventos:Acción de los actores Respuesta del sistema1. Este caso de uso comienza cuando unCliente llega a una caja de TPDV conproductos que desea comprar.2. El Cajero registra el código universal deproducto (CUP) en cada producto.Si un producto se repite, el Cajero tambiénpuede introducir la cantidad.

3. Determina el precio del producto eincorpora a la transacción actual lainformación correspondiente.Presenta la descripción y el precio delproducto en cuestión.

4. Al terminar de introducir el producto, elCajero indica a TPDV que se concluyó lacaptura del producto.


6. El Cajero indica el total al Cliente.

1717


EX UMBRA SOLEMIN


7. El Cliente da un pago en efectivo – el“efectivo ofrecido” – posiblemente mayorque el total de la venta.8. El Cajero registra la cantidad de efectivorecibida.

6. Muestra al cliente la diferencia.Genera un recibo.

10. El Cajero deposita el efectivo recibidoy extrae la diferencia.El Cajero le entrega al Cliente el cambio yel recibo impreso.

11. Registra la venta concluida.

12. El Cliente se marcha con los artículoscomprados.

Cursos alternativos? Línea 2: introducción del identificador inválido. Indicar error.? Línea 7: el cliente no tenía suficiente dinero. Cancelar la tran sacción de venta.


EX UMBRA SOLEMIN

Fase de planificación y elaboraciónComprar Productos: versión 2

? Simplificaciones, metas y suposiciones? Las simplificaciones de la versión 1 se aplican también en esta

versión salvo que el pago puede efectuarse en efectivo, con tarjeta de crédito o con cheque. Las dos últimas formas de pago requieren autorización.

Caso de uso: Comprar productos, versión 2Actores: Cliente (iniciador), CajeroPropósito: Capturar una venta y su pago.Resumen: Un Cliente llega a la caja registradora con los artículos que co mprará.

El Cajero registra los artículos y recibe un pago, que puede req ueriruna autorización. Al terminar la operación, el Cliente se marcha conlos artículos comprados.


EX UMBRA SOLEMIN

Análisis Orientado a ObjetosInicio de un ciclo de desarrollo

? Suponga que la fase de planificación y elaboración ha concluido y que los casos de uso han sido identificados, clasificados y programados, por lo menos en los primeros dos ciclos.

? Se presenta, entonces, una transición muy importante: comienza la fase de construcción en la cual se cumplen los ciclos de desarrollo iterativo.


EX UMBRA SOLEMIN

Análisis Orientado a ObjetosInicio de un ciclo de desarrollo

? Las actividades iniciales del ciclo se relacionan con la administración del proyecto. ? En el caso general, viene después (o, más probablemente, ocurre

en paralelo) una sincronización de la documentación a partir delúltimo ciclo con el estado real del código, porque los artefactos de diseño y los códigos difieren invariablemente durante la fase decodificación del último ciclo.

? Entonces empieza la fase de análisis, en la cual se investiga a fondo los problemas del ciclo actual. En esta fase, una de las actividades consiste en desarrollar el modelo conceptual.


EX UMBRA SOLEMIN

Análisis Orientado a ObjetosActividades




1. Definir los casos

esenciales


secuencia


casos


3. Perfeccionar el modelo

conceptual


estado



EX UMBRA SOLEMIN

Análisis Orientado a ObjetosArtefactos

Casos de uso reales

Ventanas y reportes

Diagramas de secuencia del

sistema

Casos de uso:esenciales expandidos

Diagramas de casos de uso

Modelo conceptual

Glosario

dependencia respecto aContratos de operación

Diagramas de estado

Diagramas de interacción

Diagramas de clase de diseño

Diagrama de paquete de arquitectura

Esquema de base de

datos

Métodos

Definiciones de clase y de interfaz

SQL

Casos de prueba

1818


EX UMBRA SOLEMIN

Análisis Orientado a ObjetosConstrucción de un modelo conceptual

? Un modelo conceptual explica (a sus creadores) los conceptos significativos en un dominio del problema, es el artefacto más importante a crear durante el análisis orientado a objetos ? los casos de uso son artefactos importantes pero no son realmente

orientados a objetos


EX UMBRA SOLEMIN

Análisis Orientado a ObjetosConstrucción de un modelo conceptual

? Identificar muchos objetos o conceptos constituye la esencia del análisis orientado a los objetos, y el esfuerzo se compensa con los resultados conseguidos durante la fase de diseño e implementación.

? Una cualidad esencial que debe ofrecer un modelo conceptual es que representa cosas del mundo real, no componentes del software.


EX UMBRA SOLEMIN

Análisis Orientado a ObjetosFundamentos

? Los modelos conceptuales se representan en UML con un grupo de diagramas de estructura estática donde no se define ninguna operación.

? El modelo conceptual puede mostrarnos: ? conceptos? asociaciones entre ellos? atributos de conceptos

? Por ello los artefactos de software, como una ventana o una base de datos, no forman parte del modelo conceptual, salvo que el dominio a modelar se refiera a conceptos de software; por ejemplo, un modelo de interfaces gráficas.


EX UMBRA SOLEMIN


? En términos informales el concepto es una idea, cosa u objeto. En un lenguaje más formal podemos considerarlo a partir de su símbolo, intensión y extensión: ? Símbolo: palabras o imágenes que representan un concepto.? Intensión: la definición de un concepto.? Extensión: el conjunto de ejemplos a que se aplica el concepto.

? Concepto del evento de una transacción de compra? Podemos optar por designarlo con el símbolo Venta. ? La intensión de Venta puede afirmar que “representa el evento de

una transacción de compra y tiene fecha y hora”. ? La extensión de Venta son todos los ejemplos de venta; en otras

palabras, el conjunto de todas las ventas.


EX UMBRA SOLEMIN


? Modelos conceptuales y la descomposición? Los problemas de software a veces son complejos; la

descomposición – divide y vencerás – es una estrategia que suele utilizarse para resolver el problema de complejidad dividiendo el espacio del problema en unidades comprensibles.

? Por tanto, la tarea primordial de análisis consiste en identificar los conceptos en el dominio del problema y documentar los resultados en un modelo conceptual.


EX UMBRA SOLEMIN


? Por ejemplo, en el dominio del problema real en una tienda con un terminal de punto de venta intervienen los conceptos de:? Tienda? TPDV? Venta

? Por tanto, el modelo conceptual debe incluir estos conceptos.

1919


EX UMBRA SOLEMIN

Análisis Orientado a ObjetosEstrategias para identificar los conceptos

? Objetivo: crear un modelo conceptual de objetos representativos del dominio del problema.

? Directrices básicas: ? Es mejor exagerar y especificar un modelo conceptual con muchos

conceptos refinados que no especificarlo cabalmente. ?Es frecuente omitir conceptos durante la fase inicial de identificación y

descubrirlos más tarde cuando se examinen los atributos o asociaciones o durante la fase de diseño. Cuando se detecten, habrá que incorporarlos al modelo conceptual.

? Un concepto no debe ser excluido simplemente porque los requerimientos no indican una necesidad evidente que permita recordar la información acerca de ella (criterio común para diseñar los bases de datos), o porque el concepto carezca de atributos.


EX UMBRA SOLEMIN

Análisis Orientado a ObjetosEstrategias para identificar conceptos: Lista de categorías

? La creación del modelo conceptual a partir de una lista de categorías se comienza preparando una lista de conceptos idóneos a partir de la siguiente lista. Contiene muchas categorías comunes que vale la pena tener en cuenta, sin que importe el orden de importancia.

? Categorías:? objetos físicos o tangibles ?TPDV

?Avión ? especificaciones, diseño o descripciones de cosas?Especificación De Producto?Descripción De Vuelo


EX UMBRA SOLEMIN


? Categorías:? lugares?Tienda ?Aeropuerto

? transacciones?Venta, Pago ?Reservación

? línea o renglón de elemento de transacciones ?Ventas Línea De Producto

? papel de personas ?Cajero ?Piloto

? contenedores de otras cosas?Tienda, Cesto ?Avión


EX UMBRA SOLEMIN


? Categorías:? otros sistemas de computo o electromecánicas externos al sistema?Sistema De Autorización De Tarjeta De Crédito?Control De Trafico Aéreo

? conceptos de nombres abstractos?Hambre ?Acrofobia

? organizaciones?Departamento De Ventas?Objeto Línea Aérea

? eventos?Venta, Robo, Junta ?Vuelo, Accidente, Aterrizaje

? procesos (a menudo no están representados como conceptos, pero pueden estarlo)?Venta De Producto?Reservación Asiento


EX UMBRA SOLEMIN


? Categorías:? reglas y políticas?Política De Reembolso?Política De Cancelaciones

? catálogos?Catalogo De Producto?Catalogo De Partes

? Registro de finanzas, de trabajo, de contratos, de asuntos legales?Recibo, Contrato De Empleo?Bitácora De Mantenimiento

? instrumentos y servicios financieros?Línea De Crédito?Existencia

?manuales, libros?Manual De Personal?Manual De Reparaciones


EX UMBRA SOLEMIN

Análisis Orientado a ObjetosObtención de conceptos a partir de frases nominales

? Otra técnica muy útil (por su simplicidad) consiste en identificar las frases nominales (sustantivos) en las descripciones textuales del dominio de un problema y considerarlas conceptos o atributos idóneos.

? Este método hay que usarlo con prudencia, ya que no es posible encontrar mecánicamente correspondencias entre sustantivo y concepto, y además las palabras del lenguaje natural son ambiguas.

? Pese a ello esta técnica es muy útil cuando se empieza a entender el enfoque de orientación a objetos.

2020


EX UMBRA SOLEMIN


Acción de los actores Respuesta del sistema1. Este caso de uso comienza cuando unCliente llega a una caja de TPDV conproductos que desea comprar.2. El Cajero registra el código universalde producto (CUP) en cada producto .Si un producto se repite, el Cajerotambién puede introducir la cantidad.

3. Determina el precio del producto eincorpora a la transacciónactual lainformación correspondiente.Presenta la descripción y el precio delproducto en cuestión.


EX UMBRA SOLEMIN


? Algunas de las frases marcadas son conceptos idóneos, algunas pueden ser atributos de conceptos. El consejo es combinar este método con la lista de categorías.


EX UMBRA SOLEMIN


? Dependencia de los artefactos? Técnicas de clasificación de casos de uso

? Formato extendido de los casos de uso? Análisis Orientado a Objetos ?Modelo conceptual? Formas de determinar conceptos


EX UMBRA SOLEMIN


? ¿Porqué se clasifican los casos de uso?? ¿Qué es un caso de uso inicio?

? ¿Porqué es necesario simplificar un caso de uso?? ¿Qué significaría que un artefacto no dependa de otros?

? ¿Qué representa el modelo conceptual y cómo se obtiene?


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Contenido

? Identificación de conceptos? Ejemplo

? Principio del cartógrafo

? Asociaciones de conceptos? Identificación de atributos

? Construcción del modelo conceptual


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Ejemplo: Obtención de conceptos

? En el caso de punto de venta, los conceptos identificados son los siguientes:? TPDV, Producto, Tienda, Venta, Pago ? Catalogo De Productos, Especificación De Producto? Ventas Línea De Productos? Cajero, Cliente, Gerente

? ¿Se debe o no incluir el recibo?

2121


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Obtención de conceptos

? El recibo es un registro de venta y de un pago, así como el concepto relativamente prominente en el dominio de ventas: ¿debe entonces, mostrarse en el modelo? ? El recibo es un informe de venta, toda su información proviene de

otra parte. Este es un buen motivo para excluirlo. ? El recibo cumple un papel esencial respecto a las reglas de la

empresa: el portador le confiere el derecho de devolver los productos adquiridos. Esta es la razón para incluirlo en el modelo.

? El recibo se excluirá por el momento, porque las devoluciones de productos no están incorporados en este ciclo de desarrollo.


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Directrices para construir modelos conceptuales

? Aplique los siguientes pasos para construir un modelo conceptual: ? Liste los conceptos idóneos usando la lista de categoría de

conceptos y la identificación de frases nominales relacionadas con los requerimientos en cuestión.

? Dibújelos en el modelo conceptual.? Incorpore las asociaciones necesarias para registrar las relaciones

entre los conceptos.? Agregue los atributos necesarios para cumplir con las necesidades

de la información.


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Directrices: El cartógrafo

? La estrategia del cartógrafo se aplica a los mapas y a los modelos conceptuales:? Utilice los nombres existentes en el dominio.? Excluya las características irrelevantes.? No agregue cosas que no existan.


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Directrices: El cartógrafo

? Los cartógrafos se sirven de los nombres del territorio – no cambian los nombres de ciudades en sus mapas. En el caso de un modelo conceptual ello significa utilizar el vocabulario del dominio cuando se asignan nombres a los conceptos y a los atributos.

? Un cartógrafo elimina cosas en el mapa en caso de que no las juzgue pertinentes para el propósito: por ejemplo, excluir la información sobre la población. De modo similar, un modelo conceptual puede excluir los conceptos que no estén relacionados directamente con los requerimientos.

? Un cartógrafo no muestra cosas en el mapa que no existan. En forma parecida, el modelo conceptual no debe mostrar las cosas que no se encuentren en el dominio del problema en cuestión.


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Un error frecuente al identificar conceptos

? Tal vez, el error más frecuente cuando se crea el modelo conceptual es el de representar algo como atributo, cuando debió haber sido un concepto.

? Una regla práctica de no caer en él: ? Si en el mundo real no consideramos algún concepto X como

número o texto, probablemente X sea un concepto y no un atributo.?Por ejemplo, en el dominio de reservaciones en líneas aéreas:

¿debería el aeropueto de destino ser atributo de vuelo o un concepto aparte? En el mundo real, un aeropuerto de destino no se considera ni número, ni texto, es una cosa que ocupa espacio. Por tanto, Aeropuerto debería ser un concepto.

? En caso de duda, convierta un atributo en un concepto.


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Agregación de las Asociaciones

? Es necesario identificar las asociaciones de los conceptos que se requieren para satisfacer los requerimientos de información de los casos de uso en cuestión y los que contribuyen a entender el modelo conceptual.

? La asociación es una relación entre dos conceptos que indica alguna conexión significativa entre ellos.

? En el lenguaje UML se describen como relaciones estructurales entre los objetos de diferentes tipos.

2222


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Agregación de Asociaciones : Criterios

? Las asociaciones que vale la pena mencionar suelen incluir el conocimiento de una relación que ha de preservarse durante algún tiempo: puede tratarse de milisegundos o años según el contexto.

TPDV Venta actual

1 Registra 1

Asociación


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Agregación de las Asociaciones : Criterios

? Examine la conveniencia de incluir las siguientes asociaciones en un modelo conceptual: ? Las asociaciones en que el conocimiento de la relación ha de ser

preservado durante algún tiempo (asociaciones que deben “conocerse”)

? Las asociaciones provenientes de la lista de asociaciones comunes.?Por ejemplo, las instancias de VentaLineaDeProducto deben ir

asociadas a la instancia Venta, sin esto sería imposible imprimi r un recibo, calcular el total, etc. ?En cambio, no necesitamos una relación entre Gerente y Venta.


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Agregación de las Asociaciones: Notación

? Una asociación se representa como una línea entre los conceptos con el nombre de la asociación. ? Esta es intrínsecamente bidireccional: es un nexo entre objetos. ? Los extremos de una asociación pueden contener una expresión de

multiplicidad que indique la relación numérica entre las instancias o conceptos, que se llaman papeles.


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Identificación de asociaciones: lista de asociaciones comunes

? Comience agregar las asociaciones utilizando la lista de anexa. ? Categorías comunes que normalmente vale la pena incluir.

Categoría Ejemplos

A es una parte física de B Caja-TPDVAla-Avión

A es una parte lógica de B VentasLineaDeProducto -VentaTramoDeVuelo-RutaDeVuelo

A está físicamente contenido en B TPDV-Tienda Producto -EstantePasajero - Avión

A está lógicamente contenido en B DescripcionDeProducto – CatálogoVuelo - ProgramaDeVuelo


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Identificación de asociaciones: lista de asociaciones comunes

A es una descripción de B DescripcionDeProducto – ProductoDescripcionDeVuelo - Vuelo

A es un elemento de línea en unatransacción o reporte B

VentasLineaDeProducto -VentaTrabajoDeManteniemiento-Mantenimiento

A se conoce/ introduce/ registra/ presenta/captura en B

Venta – TPDVReservacion - ListaDePasajeros

A es miembro de B Cajero – TiendaPiloto – Avion

A es una subunidad organizacional de B Departamento – TiendaMantenimiento - LineaAerea

A usa o dirige a B Cajero – TPDVPiloto – Avion

A se comunica con B Cliente – CajeroAgenteDeReservaciones -Pasajero


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Identificación de las asociaciones: lista de asociaciones comunes

A se relaciona con una transacción B Pago – BoletaPasajero – Boleto

A es una transacción relacionada con otratransacción B

Pago – VentaReservacion –Cancelacion

A está contiguo a B TPDV – TPDVCuidad – Cuidad

A es propiedad de B TPDV – TiendaAvion– LineaAerea

2323


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Identificación de las asociaciones: lista de asociaciones comunes

? Las categorías de alta prioridad que siempre vale la pena incluir son las siguientes: ? A es una parte física o lógica de B? A está físicamente o lógicamente contenido en B? A está registrado en B

? Las asociaciones son importantes, pero la falla habitual al crear los modelos conceptuales es el excesivo tiempo que se dedica al intento de descubrirlas. ? Es mucho más importante identificar conceptos que asociaciones.

El tiempo consagrado a la creación del modelo conceptual deberíadestinarse a identificar los conceptos, no las asociaciones.


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Directrices de las asociaciones

? Concentrarse en las asociaciones en que el conocimiento de la relación ha de preservarse durante algún tiempo (asociaciones que “es necesario conocer”).

? Muchas asociaciones tienden a confundir el modelo conceptual en vez de aclararlo. A veces se requiere mucho tiempo para descubrirlas, y los beneficios son escasos.

? No incluir las asociaciones redundantes, ni las derivables.


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Multiplicidad

? La multiplicidad define cuántas instancias de tipo A pueden asociarse a una instancia del tipo B en determinado momento.

Tienda Producto

1 Almacena *

Multiplicidad del papel


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Multiplicidad

? Algunos ejemplos de multiplicidad:

? En UML, el valor de multiplicidad depende del contexto, no hay soluciones prefabricadas. ? Por ejemplo, asociación Trabaja-Para entre Persona y Compañía

tendrá diferencias en la multiplicidad dependiendo para quien seesta haciendo el sistema: departamento de impuestos (1..*)o sindicato de trabajadores (1..1).

* cero o más, “muchos” 1..40 de uno a 401..* uno o más 5 exactamente 53,5,8 exactamente 3, 5 u 8


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Notación

? Se asigna un nombre a una asociación basándose en el formato NombreDeTipo-FraseNominal-NombreDeTipo, ? donde la frase nominal genera una secuencia que es legible y

significativa dentro del contexto del modelo. ? Los nombres de las asociaciones comienzan con una mayúscula. ? Una frase nominal (verbo) debe construirse con guiones. ? La dirección de lectura es de izquierda a derecha y de arriba hacia

abajo.


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Notación

Linea Aerea

Avión1 Asignada-a *

Persona Vuelo* Asignado-a 1

1

Emplea

1..*

1 *

Supervisa

Tienda

Pago1 Captura 1..*

TPDV Venta1 Pagada-por 1

1

Contiene 1..*

2424


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Asociaciones múltiples entre dos conceptos

? Dos conceptos pueden tener varias asociaciones entre ellos; sucede con frecuencia. ? Por ejemplo, en el dominio de la línea aérea encontramos varias

relaciones entre Vuelo y Aeropuerto. ? Las asociaciones volar-hacia y volar-de son netamente diferentes

que deben mostrarse por separado. ? Adiviértase asimismo que no se garantiza que todos los vuelos

aterricen en un aeropuerto.

Vuelo Aeropuerto

* Vuela-hacia 0..1

* Vuela-de 1


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Asociaciones y su implementación

? Durante la fase de análisis, una asociación no es una proposición sobre flujos de datos, variables de instancia, ni conexiones de objetos en una solución de software; es una proposición de que una relación es significativa en un sentido puramente analítico: en el mundo real.

? “Una asociación no necesariamente debe ser implementada durante la construcción”


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Asociaciones del dominio del punto de venta

? Deberíamos incorporar las asociaciones que indican los requerimientos (los casos de uso, por ejemplo), las que conllevan la necesidad de recordar o que de alguna otra forma nos sugiere nuestra percepción del dominio del problema.

? Conceptos:? TPDV, Producto, Tienda, Venta, Pago ? Catalogo De Producto, Especificación De Producto? Ventas Línea De Productos? Cajero, Cliente, Gerente


EX UMBRA SOLEMIN


? Relaciones inolvidables en la Tienda

TPDV captura Venta Para conocer la venta actual genera un total eimprime un recibo.

Venta pagada en efectivo Para saber si se pagó la venta, relaciona lacantidad ofrecida con el total de la venta eimprime un recibo.

CatalogoDeProductos registraEspecificacionDeProducto

Para recuperar la especificación de producto conun código universal de producto


EX UMBRA SOLEMIN


? Recorreremos la lista de comprobación, basándonos en tipos anteriormente identificados y teniendo presentes los requerimientos actuales del caso de uso.

Categoría Sistema TPDVA es una parte física de B no se aplicaA es una parte lógica de B VentasLineaDeProducto-Venta

A está contenido físicamente en B TPDV-TiendaProducto-Tienda

A está contenido lógicamente en BEspecificacionDeProducto –CatalogodeProductosCatalogodeProductos -Tienda

A es una descripción de B EspecificacionDeProducto – ProductoA es un elemento de línea en unatransacción o reporte B VentasLineaDeProducto-Venta


EX UMBRA SOLEMIN


A se conoce/ introduce/ registra/ presenta/captura en B

Venta (terminada) – TiendaVenta (actual) – TPDV

A es miembro de B Cajero – TiendaA es una subunidad organizacional de B no aplicable

A usa o dirige a B

Cajero – TPDVGerente – TPDVGerente – Cajero, probablemente noaplicable

A se comunica con B Cliente – Cajero

A se relaciona con una transacción B Cliente – PagoCajero – Pago

A es una transacción relacionada con otratransacción B Pago – Venta

A está contiguo a B TPDV – TPDV, probablemente no aplicableA es propiedad de B TPDV – Tienda

2525


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Modelo Conceptual del punto de venta

1Pago

1

1

Cliente

11

Gerente

11 Cajero1

1

*

1

1..*

1

10..1

1

Venta

Pagado-porIniciado-por 1..*

TPDV

Iniciado-por

Registra-Ventas-en

1

1

Capturadas-en

1

*

1

*

VentasLineaDeProducto

Contenidas-en

1

*Producto

Registra-Venta-de

1

*

Tienda

1

Capturas-Terminada

Aloja

Almacena

1

1..*

EspecificaciondeProducto

*

1

Descrita-por

Describe

1CatalogoDeProductos

Usado-por

1..*1

Contiene


EX UMBRA SOLEMIN


? El conjunto de asociaciones que se incluye en el modelo se obtuvo de manera bastante mecánica a partir de la lista de comprobación. Pero tal vez hay que ser más restrictivos con las asociaciones.

? Venta Capturada por Cajero ? Los requerimientos no indican la necesidad de conocer, ni de

registrar al cajero actual. Además es derivable si existe la asociación TPDV usado-por Cajero.

? TPDV Usado-por Cajero? Los requerimientos no indican la necesidad de conocer, ni de

registrar al cajero actual.


EX UMBRA SOLEMIN


? TPDV Iniciado-por Gerente? Los requerimientos no indican la necesidad de conocer, ni de

registrar al gerente que inició un TPDV.

? Venta Iniciada por Cliente? Los requerimientos no indican la necesidad de conocer, ni de

registrar al cliente actual.

? Tienda Almacena Producto? Los requerimientos no indican la necesidad de conocer o mantener

la información del inventario.

? Ventas Línea De Producto Registra -venta-de Producto? Los requerimientos no indican la necesidad de mantener la

información del inventario.


EX UMBRA SOLEMIN


1Pago

1

Cliente

Gerente

Cajero

1

*

1

1..*

1 1

Venta

Pagado-por

1..*

TPDV

1

1

Capturadas-en

1

*


Contenidas-en

1

*

Producto

1

*

Tienda

1

Capturas-Terminada

Aloja

1

1..*


*

1

Descrita-por

Describe1

CatalogoDeProductos

Usado-por

1..*1

Contiene


EX UMBRA SOLEMIN


? Nótese que la capacidad de justificar una asociación atendiendo a la necesidad de conocerla depende de los requerimientos; un cambio de ellos – por ejemplo, exigir que la identificación del cajero aparezca en el recibo –altera la necesidad de recordar la relación.

? Enfatice las asociaciones que deben conocerse, pero incorpore también las opcionales que se requieran sólo para la comprensión, con el fin de enriquecer el conocimiento básico del dominio.


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Agregación de los Atributos

? Recuerde que el modelo conceptual es una representación de cosas reales, no de componentes de software. Cualquier afirmación concerniente a los atributos ha de interpretarse dentro del contexto de entidades del mundo real.

? Un atributo es una valor lógico de un dato o de un objeto.

2626


EX UMBRA SOLEMIN


? Incluya los siguientes atributos en el modelo conceptual: ? Aquellos en que los requerimientos (por ejemplo, casos de uso)

indican o conllevan la necesidad de recordar información. ?Por ejemplo, un recibo de ventas normalmente incluye fecha y hora.

En consecuencia, el concepto venta requiere dos atributos: fecha y hora.

? Los atributos se muestran en la segunda sección de conceptos, esopcional indicar su tipo.

Venta

fechaHoraDeInicio: hora

Atributos


EX UMBRA SOLEMIN


? Los tipos más simples de atributos son los que, en la práctica, suelen considerarse los tipos primitivos de datos. ? Por lo regular, el tipo de un atributo no debería ser un concepto

complejo del dominio, como Venta o Aeropuerto. Por ejemplo, podríamos poner un atributo TPDV-Actual al concepto Cajero, que no es un tipo simple, pero la forma más conveniente de expresarlo es a través de la asociación.

1 Usa 1

Cajero

nombreTPDVactual

Cajero

nombre

TPDV

numero


EX UMBRA SOLEMIN


? En un modelo conceptual es preferible que los atributos sean atributos simples o valores puros de datos.

? Entre los tipos comunes de atributos simples más frecuentes figuran: ? Booleano, Fecha, Numero, Cadena (Texto), Hora? Direccion, Color, Geometria (punto, Rectangulo, …), Telefono, RUT,

Codigo Universal de Producto (CUP), codigo postal, tipos numerados

? Una confusión frecuente consiste en modelar como atributo un concepto complejo del dominio. Por lo tanto, relacione conceptos a través de una asociación no con un atributo.


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Atributos del sistema de punto de venta

? Es necesario producir una lista de atributos para los conceptos del dominio de punto de venta. Debería estar reservada específicamente a los requerimientos a las simplificaciones en cuestión: Comprar productos versión 1.

? Para eso habrá que leer los siguientes documentos: ? especificación de requerimientos? casos de uso en cuestión? documentos de simplificaciones, clarificaciones y suposiciones


EX UMBRA SOLEMIN


? Por ejemplo, podemos identificar los atributos:? Tienda: dirección, nombre? Venta: fecha, hora? VentasLineaDeProducto: cantidad? Pago: monto? EspecificacionDeProducto: decripcion, precio, cup


EX UMBRA SOLEMIN


? Es posible que el cajero reciba un grupo de productos afines (seis paquetes de pañuelos desechables) y introduzca una sóla vez el CUP y la cantidad (seis). ? En consecuencia una instancia de VentasLineaDeProducto puede

estar asociada a más de una instancia de cada producto. ? La cantidad que introduce el cajero puede quedar registrada como

atributo de VentasLineaDeProducto.

? Sin embargo, también puede ser calculada a partir del valor real de multiplicidad de la relación; así puede caracterizarse como atributo derivado, el cual puede ser deducido de otra información. ? En UML, un atributo derivado se denota con el símbolo “/”.

2727


EX UMBRA SOLEMIN


0..1 Registra-venta -de 1..*


/cantidad

Producto


EX UMBRA SOLEMIN


1Pago

11

*

1

1..*

1 1Venta

fechahora

Pagado-por

1..*TPDV

1

1

Capturadas-en1

*

VentasLineaDeProductocantidad

Contenidas-en

1

*

Producto

1

*

Tiendadireccion1

Capturas-Terminada

Aloja

1

1..*


*

1

Descrita-por

Describe

1

CatalogoDeProductosdescr ipcionprecioC U P

Usado-por

1..*1

Contiene


EX UMBRA SOLEMIN


? Hemos creado un modelo conceptual relativamente útil del dominio del punto de venta.

? No existe un modelo apropiado para todos los casos y circunstancias, todos ellos no son más que aproximaciones al dominio que queremos entender.

? Un buen modelo conceptual capta las abstracciones esenciales y la información indispensable para comprender el dominio dentro del contexto de los requerimientos actuales.


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Resumen

? Identificación de conceptos? Ejemplo

? Principio del cartógrafo

? Asociaciones de conceptos? Identificación de atributos

? Construcción del modelo conceptual


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Quiz

? ¿Qué es lo que aparece en el modelo conceptual?? ¿Qué es el principio del cartógrafo?

? ¿Qué representa una asociación?? ¿Todas las asociaciones son importantes?

? ¿Qué representa la multiplicidad?? ¿Porqué son tan importantes los nombres en el modelo?


EX UMBRA SOLEMIN


? ¿Cómo se interpreta este diagrama?

OfertaCursos<<entidad>>

Cursos<<entidad>>

1

1..*

0. .*0. .*

prerrequisitos

0..*0. .*

1

1..*

OpcionesCursoProfesor<<entorno>>

AñadirOfertaCurso<<entorno>>

1 11 1

GestorCursosProfesor<<control>>

1..*0. .*

1. .*0. .*

maneja

1

1

1

1

2828


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Contenido

? Comportamiento de los sistemas? Diagrama de secuencia del sistema

? Contratos? Precondiciones? Postcondiciones


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Comportamiento de los Sistemas




1. Definir casos esenciales de

uso


secuencia


casos


3. Perfeccionar el modelo conceptual


estado



EX UMBRA SOLEMIN

Análisis Orientado a Objetos Diagrama de Secuencia del Sistema

? Antes de iniciar el diseño lógico de cómo funcionará una aplicación de software es necesario investigar y definir su comportamiento como una “caja negra”.

? El comportamiento del sistema es una descripción de lo que hace, sin explicar la manera en que lo hace. Una parte de esa descripción es un diagrama de secuencia del sistema.


EX UMBRA SOLEMIN


? Los casos de uso indican cómo los actores interactúan con el sistema de software que es lo que realmente queremos crear.

? Durante la interacción un actor genera eventos dirigidos a un sistema, solicitando alguna operación a cambio. ? Por ejemplo, cuando un cajero introduce un código universal de

producto de un artículo, está pidiendo al sistema TPDV registrar el código.


EX UMBRA SOLEMIN


? El diagrama de secuencia de un sistema es una representación que muestra, en un determinado escenario, los eventos generados por actores externos, su orden y los eventos externos del sistema. ? A todos los sistemas se les trata como caja negra; los diagramas se

centran en los eventos que fluyen de los actores a los sistemas.? En el diagrama el tiempo avanza hacia abajo, y el ordenamiento de

los eventos debería seguir el orden indicado en el caso de uso. ? Los eventos del sistema pueden incluir parámetros.

:Sistema

Sistema como caja negraActor


EX UMBRA SOLEMIN


? Curso normal de los eventos en el caso Comprar Productos.

: Cajero

:Sistema

1: introducir Producto(CUP, cantidad)

2: terminarVenta ()

3: efectuarPago(monto )

Sistema como caja negra

Evento del sistemaInicia una operación de sistema

Actor

2929


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Eventos y operaciones del sistema

? El evento de un sistema es un hecho externo de entrada que un actor produce en un sistema.

? La operación de un sistema es una acción que éste ejecuta en respuesta a una evento del sistema. ? Por ejemplo, cuando un cajero genera un evento

introducirProducto, causa la ejecución de la operación introducirProducto;

? El nombre del evento y de la operación son idénticos; la distinción reside en que el evento es el estímulo nombrado y la operación es la repuesta (lo mismo sucede con los mensajes y los métodos).


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Registro de las operaciones de un sistema

? Para determinar el conjunto de las operaciones requeridas del sistema se identifican sus eventos. Cuando se utilizan los parámetros, las operaciones son las siguientes: ? EfectuarPago(CUP, Cantidad) ? TerminarVenta()? EfectuarPago(monto)

? ¿Donde deberían registrarse estas operaciones?. En UML se pueden agruparse las operaciones como operaciones de tipo Sistema. Los parámetros son opcionales.

Sistema

terminarVenta ( )introducirProducto ( )efectuarPago( )


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Registro de las operaciones de un sistema

? Observe que la representación del tipo Sistema es muy diferente a lo que se expresó en el modelo conceptual.

? Los elementos de éste representan conceptos del mundo real; en cambio, el tipo Sistema es un concepto artificial. ? Ello se debe a la naturaleza de la información que estamos

representando: mientras el modelo conceptual es la información estática, el tipo Sistema representa el comportamiento de sistema, el cual es la información dinámica.


EX UMBRA SOLEMIN


? Para elaborar un diagrama de secuencia del sistema que describa el curso normal de los eventos en un caso de uso: ? Trace una línea que represente el sistema como una caja negra. ? Identifique los actores que operan directamente sobre el sistema.

Trace una linea para cada uno de ellos. ? A partir del curso normal de los eventos del caso de uso identifique

los eventos (“externos”) del sistema que son generados por los actores. Muéstrelos gráficamente en el diagrama.

? A la izquierda del diagrama puede incluir o no el texto del caso de uso.


EX UMBRA SOLEMIN


? Consideramos ahora el caso de uso Comprar Productos a fin de identificar los eventos del sistema. ? Primero debemos determinar los actores que interactúan

directamente con el sistema de software. ? El cliente interactúa con el cajero, pero no directamente con el

sistema TPDV; esto sólo lo hace el cajero. ? Por tanto, el cliente no es un generador de eventos del sistema,

sólo el cajero lo es.


EX UMBRA SOLEMIN


? Los eventos de un sistema (y sus operaciones asociadas) deben expresarse en el nivel de propósito y no en el nivel el medio físico de entrada o de elementos de la interfaz.

? También mejora la claridad, si el nombre de un evento del sistema comienza con un verbo (agregar, introducir, terminar, efectuar), ya que recalca que los eventos están orientados a comandos. ? Así, “terminarVenta” es preferible a “IntroducirTeclaOprimida”

porque capta mejor el propósito de la operación: mantiene un carácter abstracto y no se pronuncia respecto a las decisiones de diseño sobre cuál interfaz sirve para capturar el evento del sistema.

3030


EX UMBRA SOLEMIN


? En cuanto a expresar las operaciones en el nivel de propósito, procure alcanzar el nivel más alto o la meta final de asignar nombre a la operación. Por ejemplo, respecto a la operación que captura el pago:

? IntroducirImporteOfrecido(monto) – deficiente? IntroducirPago(monto) – mejor? EfectuarPago – quizá mejor aún


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Modelo de análisis

? Los diagramas de la secuencia de un sistema forman parte del modelo de comportamiento del sistema.

? El modelo de análisis se compone de: ?Modelo de casos de uso de análisis (modelo dinámico)?Casos de uso de alto nivel o esenciales ?Diagramas de casos de uso

?Modelo conceptual (modelo estático)?Diagramas de estructura estática para los conceptos de dominio

?Modelo de comportamiento (modelo dinámico)?Diagramas de secuencia del sistema?Contratos para las operaciones de sistema

?Modelo de estado del análisis (modelo dinámico)?Diagramas de estado para conceptos y casos de uso


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Comportamiento de los sistemas: contratos

? Los contratos contribuyen a definir el comportamiento de un sistema; describen el efecto de las operaciones sobre el sistema. ? El lenguaje UML (pero no el Rational Rose) ofrece un soporte para

definir las precondiciones y las poscondiciones de las operaciones.

? Los contratos de operación de sistema se elaboran durante la fase de análisis en un ciclo de desarrollo.

? Su desarrollo depende del desarrollo previo del modelo conceptual, de los diagramas de secuencia de sistema y la identificación de sus operaciones.


EX UMBRA SOLEMIN


1Pago

11

*

1

1..*

1 1Venta

fechahora

Pagado-por

1..*TPDV

1

1

Capturadas-en

1

*


Contenidas-en

1

*Producto

1

*Tienda

direccion

1

Capturas-Terminada

Aloja

1

1..*


*

1

Descrita-por

Describe

1CatalogoDeProductosdescripcionprecioC U P

Usado-por

1..*1

Contiene


EX UMBRA SOLEMIN


? En términos generales, un contrato es un documento que describe lo que una operación se propone lograr.? Suele redactarse en un estilo declarativo, enfatizando lo que

sucederá y no cómo se conseguirá. ? Los contratos suelen expresarse a partir de los cambios de estado

de las precondiciones y de las poscondiciones. ? Puede elaborarse un contrato tanto para un método de una clase,

como para una operación más global del sistema, aunque por ahora nos concentramos en su uso para las operaciones globales del sistema.

? El contrato de operación del sistema describe cambios del estado del sistema total cuando se llama una de sus operaciones.


EX UMBRA SOLEMIN


? El siguiente ejemplo describe un contrato de la operación introducirProducto del sistema:

ContratoNombre: IntroducirProducto (cup:numero, cantidad:entero )Responsabilidades: Capturar (registrar) la venta de un producto y agregarla a la venta. Desplegar

la descripción y el precio del producto.Tipo: SistemaReferencias cruzadas: Funciones del sistema: R1.1, R1.3, R1.6

Casos de uso: Comprar productosNotas: Utilizar el acceso superrápido a la base de datos.Excepciones: Si el CUP no es válido, indicar que se cometió.Salida:Precondiciones: El sistema conoce el CUP.

3131


EX UMBRA SOLEMIN


? No todas las secciones del contrato son necesarias; se recomienda llenar Responsabilidades y Poscondiciones.

Poscondiciones:Si se trata de una nueva venta, se creó una Venta (creación de instancia ).Si se trata de una nueva venta, la nueva Venta fue asociada a un TPDV ( asociaciónformada).Se creó una instancia VentasLineadeProducto (creación de instancia ).Se asoció una instancia de VentasLineadeProducto a la Venta (asociación formada ).Se asignó una cantidad a VentasLineadeProducto.cantidad (modificación de atributo ).Se asoció una instancia VentasLineadeProducto a la instancia EspecificaciondeProducto ,basado en la correspondencia del CUP ( asociación formada ).


EX UMBRA SOLEMIN


ContratoNombre: Nombre de la operación y sus parámetros.Responsabilidades: Descripción informal de las responsabilidades que debe cumplir la operación.Tipo: Nombre del tipo (concepto, clase de software, interfaz).Referencias cruzadas: Números de referencia de las funciones del sistema, casos de uso, etc.Notas: Declaraciones del diseño referentes a la operación. Por ejemplo, si se sabe

que se prefiere un algoritmo particular para manejar la operación, esa secciónes el sitio indicado.

Excepciones: Casos excepcionales.Salida: Sólo dentro del sistema, no incorpore salidas de interfaz de usuario, mensajes

o registros que se envían fuera del sistema.Precondiciones: Suposiciones acerca del estado del sistema antes de ejecutar la operación.Poscondiciones: El estado del sistema después de la operación.


EX UMBRA SOLEMIN


? Aplique la siguiente sugerencia para elaborar contratos.? Identifique las operaciones del sistema a partir de los diagramas de

secuencia. ? Elabore un contrato en cada operación del sistema. ? Comience redactando la sección Responsabilidades; después

describa informalmente el propósito de la operación.? Complete la sección de Postcondiciones, describiendo en forma

declarativa los cambios de estado de los objetos en el modelo conceptual.

? Para describir las postcondiciones utilice las siguientes categorías: ? Creación y eliminación de instancias.? Modificación de atributos. ? Asociaciones formadas y canceladas.


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Poscondiciones

? Después de la sección de Responsabilidades, la parte más importante del contrato son las poscondiciones, que estipulan cómo cambió el sistema tras la operación.

? Las poscondiciones se expresan dentro del modelo conceptual. ? ¿Qué instancias es posible crear? La repuesta es: las provenientes

del modelo conceptual. ? ¿Qué asociaciones es posible formar? La repuesta es: las que están

en el modelo conceptual.


EX UMBRA SOLEMIN


? Cuando se formulan contratos, en general se agregarán al modelo conceptual nuevos conceptos, atributos y asociaciones. ?Mejore el modelo conforme a los nuevos descubrimientos, mientras

reflexiona sobre los contratos de las operaciones.

? Las poscondiciones deberían expresar el estado de un sistema, no las acciones a realizar. ? Expréselas en tiempo pasado para enfatizar que se trata de

declaraciones sobre un cambio pretérito de estado. Por ejemplo: ?Se creó una instancia VentasLineadeProducto (mejor)

? En lugar de ?Crear una instancia VentasLineadeProducto (peor)


EX UMBRA SOLEMIN


? Entonces, mire el contrato desde la perspectiva de un escenario y un telón.? Tome una fotografía de escenario antes de la operación? Corra el telón y aplique la operación del sistema (ruido de fondo

con sonidos).? Corra el telón y tome una segunda fotografía. ? Compare las fotografías de antes y después, y exprese como

poscondiciones los cambios del estado del escenario (se creó la instancia VentasLineadeProducto…).

3232


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Ejemplo

? Poscondiciones:? Si se trata de una nueva venta, se creó una Venta (creación de instancia).? Si se trata de una nueva venta, la nueva Venta fue asociada a un TPDV (asociación

formada).? Se creó una instancia VentasLineadeProducto (creación de instancia ).? Se asoció una instancia de VentasLineadeProducto a la Venta (asociación

formada).

? Se asignó una cantidad a VentasLineadeProducto.cantidad (modificación de atributo).

? Se asoció una instancia VentasLineadeProducto a la instancia EspecificaciondeProducto, basado en la correspondencia del CUP (asociación formada).


EX UMBRA SOLEMIN


? Una vez que el cajero capturó el CUP y la cantidad del producto, ¿Qué ha de crearse?.

? Si se trata de una nueva venta, habría que crear una instancia para una nueva Venta. Una instancia VentasLineadeProducto debería ser creada de modo incondicional. ? Si se trata de una nueva venta, se creó una Venta (creación de

instancia).? Se creó una instancia VentasLineadeProducto (creación de

instancia).


EX UMBRA SOLEMIN


? Una vez que el cajero capturó el CUP y la cantidad del producto, ¿qué atributos de los objetos nuevos o actuales deberían ser modificados?. Habría que establecer la cantidad de VentasLineadeProducto.? Se asignó una cantidad a VentasLineadeProducto.cantidad

(modificación de atributo).


EX UMBRA SOLEMIN


? Una vez que el cajero capturó el CUP y la cantidad del producto, ¿qué asociaciones entre los objetos nuevos y actuales debieron haber sido formadas o canceladas?.

? Habría que relacionar la nueva instancia de VentasLineadeProductocon sus Ventas y con su Producto. Si se trataba de una nueva Venta debió haber sido relacionada con la TPDV dentro del cual es registrada. ? Se asoció una instancia de VentasLineadeProducto a la Venta (asociación

formada).? Si se trata de una nueva venta, la nueva Venta fue asociada a un TPDV

(asociación formada).? Se asoció una instancia VentasLineadeProducto a la instancia

EspecificaciondeProducto , basado en la correspondencia del CUP (asociación formada).


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Precondiciones

? Las precondiciones definen las suposiciones sobre el estado del sistema al iniciarse la operación.

? Hay muchas precondiciones que pueden declararse en una operación, pero la experiencia revela que vale la pena mencionar las siguientes: ? Cosas que son importantes de probar en el software en algún

momento de la ejecución de la operación.? Cosas que serán sometidas a prueba, pero de las cuales depende

el éxito para subrayar la importancia y para hacer notarlas a los otros lectores.


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Contratos

? El problema más común consiste en olvidar incluir la formación de asociaciones. Sobre todo cuando se crean nuevas instancias, muy probablemente será necesario haber establecido las asociaciones a varios objetos.

3333


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Contrato para introducirProducto

ContratoNombre: IntroducirProducto (cup:numero, cantidad:entero )Responsabilidades: Capturar (registrar) la venta de un producto y agregarla a la venta. Desplegar


Casos de uso: Comprar productosNotas: Utilizar el acceso superrápido a la base de datos.Excepciones: Si el CUP no es válido, indicar que se cometió un error.Salida:Precondiciones: El sistema conoce el CUP.Poscondiciones:? Si se trata de una nueva venta, fue creada una Venta.? Si se trata de una nueva venta, la nueva Venta fue asociada a un TPDV.? Se creó una instancia VentasLineadeProducto.? Se asoció una instancia de VentasLineadeProductoa la Venta.? Se asignó una cantidad a VentasLineadeProducto.cantidad.? Se asoció una instancia VentasLineadeProductoa la instancia

EspecificaciondeProducto, basado en la correspondencia del CUP.Fundamentos de Ingeniería de SW 266

UTFSMEX UMBRA SOLEM

IN

Análisis Orientado a Objetos Contrato para terminarVenta

ContratoNombre: terminarVenta()Responsabilidades: Registrar que es el final de la captura de los productos de la venta y desplegar

el total de la venta.Tipo: SistemaReferencias cruzadas: Funciones del sistema: R1.2

Casos de uso: Comprar productosNotas:Excepciones: Si no esta realizándose una venta, indicar que se cometió un error.Salida:Precondiciones:Poscondiciones:Estableció Venta.estaTerminada en verdadero .


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Contrato para efectuarPago

ContratoNombre: efectuarPago(monto: número)Responsabilidades: Registrar el pago, calcular el saldo e imprimir el recibo.Tipo: Sistema.Referencias cruzadas: Funciones del sistema: R2.1

Casos de uso: Comprar productosNotas:Excepciones: Si la venta no está concluida, indicar que se cometió un error.Salida:Precondiciones: La venta esta terminada.Poscondiciones:Se creó una instancia Pago .Se asoció el Pago a una Venta.Se asignó el valor del monto a Pago.MontoOfrecido .Se asoció la Venta a la Tienda para agregarla al registro histórico de las ventas terminadas.


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Contrato para Inicio

ContratoNombre: Inicio()Responsabilidades: Inicializar el sistemaTipo: Sistema.Referencias cruzadas:Notas:Excepciones:Salida:Precondiciones:Poscondiciones:Se creó una instancia Tienda, TPDV, CatalogodeProductosy EspecificacionesdeProducto.Se asoció CatalogodeProductosa EspecificacionesdeProducto .Se asoció Tienda a CatalogodeProductos.Se asoció Tienda a TPDV.Se asoció TPDVa CatalogodeProductos.


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Cambios en el modelo conceptual

? Estos contratos sugieren la existencia de un dato que todavía no ha figurado en el modelo conceptual: la terminación de la captura de los productos en la venta. Lo modifica la operación terminarVenta y la especificación efectuarPago lo toma como precondición.

? Una forma de representar esta información es a través de un atributo estaTerminada de la Venta, por medio de un valor booleano.

Venta

estaTerminada: booleanfechahora


EX UMBRA SOLEMIN

Análisis Orientado a Objetos Resumen

? Comportamiento de los sistemas? Diagrama de secuencia del sistema

? Contratos? Precondiciones? Postcondiciones

3434


EX UMBRA SOLEMIN


? ¿Qué es el comportamiento de un sistema?? ¿Qué representa el diagrama de secuencia del sistema?

? ¿Cuál es la diferencia entre evento y operación?? ¿Porqué se crea el concepto sistema?

? ¿Cuál es el nombre correcto para una operación?? ¿Cuál es la diferencia entre lo estático y lo dinámico?

? ¿Porqué son necesarios los contratos y cuantos son para un caso de uso?

? ¿Cuales son los condiciones para elaborar un contrato?

? ¿Cuales son las partes más importantes del contrato?


EX UMBRA SOLEMIN

Diseño Orientado a Objetos Contenido

? Fase de Diseño ? Artefactos ? Actividades

? Casos Reales de Uso? Diagramas de Interacción


EX UMBRA SOLEMIN

Diseño Orientado a Objetos Fase de Diseño

? En la fase de análisis del desarrollo se da prioridad al conocimiento de los requerimientos, los conceptos y las operaciones relacionadas con el sistema.

? Análisis se caracteriza por centrarse en cuestiones concernientes al qué, mientras que el diseño se concentra en cómo.


EX UMBRA SOLEMIN


? El siguiente grupo mínimo de artefactos sirven para capturar losresultados de una investigación: ? Casos de uso

? ¿Cuáles son los procesos del dominio?

? Modelo Conceptual? ¿Cuáles son los conceptos, los términos?

? Diagramas de la secuencia de un sistema? ¿Cuáles son los eventos y las operaciones del sistema?

? Contratos? ¿Qué hacen las operaciones del sistema?

? Durante el ciclo de desarrollo iterativo es posible pasar a la fase de diseño una vez terminados estos documentos de análisis.


EX UMBRA SOLEMIN


? Durante la fase de diseño se logra una solución lógica que se fundamenta en el paradigma orientado a objetos.

? Su esencia es la elaboración de diagramas de interacción, que muestran gráficamente cómo los objetos se comunicarán entre ellos a fin de cumplir con los requerimientos.

? La definición de los diagramas de interacción nos permite dibujar los diagramas de diseño de clases que resumen la definición de las clases (e interfaces) implementables en el software.


EX UMBRA SOLEMIN

Diseño Orientado a Objetos Actividades

Perfeccionamientodel plan

Sincronización deartefactos


1. Definir los casosreales de uso

4. Definir losdiagramas deinteracción

2. Definir reportes,interfaz de usuario

y storyboards

5. Definir losdiagramas de

clases de diseño

3. Perfeccionar laarquitectura del

sistema

6. Definir elesquema de labase de datos

3535


EX UMBRA SOLEMIN

Diseño Orientado a Objetos Descripción de los casos reales de uso

? Un caso real de uso describe el diseño concreto del caso de uso a partir de una tecnología particular de entrada y salida, así como de su implementación global. ? Por ejemplo, si interviene una interfaz gráfica de usuario, el caso

real de uso incluirá los diagramas de las ventanas en cuestión yuna explicación de la interacción de bajo nivel con los artefactos de la interfaz.

? Tal vez no sea necesario generarlos. Una alternativa podría ser diseñar los storyboards o secuencias de pantallas de la interfaz de usuario y ampliarlos con más detalles durante la implementación.


EX UMBRA SOLEMIN

Diseño Orientado a Objetos Ejemplo: Comprar Productos Versión 1

Caso de uso: Comprar productos, versión 1Actores: Cliente (iniciador), CajeroPropósito: Capturar una venta y su pago en efectivo.Resumen: Un Cliente llega a la caja registradora con los artículos que comprará.

El Cajero registra los artículos y recibe una pago en efectivo. Alterminar la operación, el Cliente se marcha con los artículoscomprados.

Tipo: Primario y realReferenciasCruzadas:

Funciones: R1.1, R1.2, R1.3, R1.7, R2.1

Tienda de Objetos

CUP

Precio

Total

Ofrecido

Cantidad

Desc.

Saldo

IntroducirProducto

TerminarVenta

EfectuarPago

A

B

C

D

E

F

G

H I J


EX UMBRA SOLEMIN

Diseño Orientado a Objetos Ejemplo: Comprar Productos Versión 1

Curso normal de eventos:Acción de los actores Respuesta del sistema1. Este caso de uso comienza cuando unCliente llega a una caja de TPDV conproductos que desea comprar.2. Con cada producto, el Cajero teclea elcódigo universal de producto (CUP) en Ade la Ventana 1. Si un producto se repite, elCajero también puede introducir lacantidad en E. Se oprime botón H despuésde capturar cada producto

3. Agrega la información sobre el productoa la actual transacción de ventas.El precio del producto y la descripción delproducto actual aparecen en el recuadro By F respectivamente de la Ventana 1.

4. Al terminar de capturar los productos, elCajero oprime el botón I para indicarle alTPDV que se concluyó la captura deproductos.

5. Calcula y presenta en el recuadro C eltotal de la venta.

6. …

Tienda de Objetos

CUP

Precio

Total

Ofrecido

Cantidad

Desc.

Saldo

IntroducirProducto

TerminarVenta

EfectuarPago

A

B

C

D

E

F

G

H I J Fundamentos de Ingeniería de SW 280UTFSM

EX UMBRA SOLEMIN

Diseño Orientado a Objetos Diagramas de interacción

? Los diagramas de interacción no se pueden preparar si antes no se generan los siguientes artefactos: ? Un modelo conceptual a partir del cual el diseñador podrá definir

las clases de software correspondientes a los conceptos. Los objetos de las clases participan en las interacciones que se describen gráficamente en los diagramas.

? Contratos de la operación del sistema: a partir de ellos el diseñador identifica las responsabilidades y las poscondiciones que han decumplir los diagramas de interacción.

? Casos de uso reales (o esenciales): a partir de ellos el diseñador recaba la información sobre las tareas que realizan los diagramas de interacción, además de los estipulado en los contratos.


EX UMBRA SOLEMIN


? Un diagrama de interacción explica gráficamente las interacciones existentes entre las instancias (y las clases). ? El punto de partida de las interacciones es el cumplimiento de las

poscondiciones de los contratos de operación.

? El UML define dos tipos de estos diagramas; ambos sirven para expresar interacciones semejantes o idénticas al mensaje.


EX UMBRA SOLEMIN


? Los diagramas de colaboración describen las interacciones entre los objetos en un formato de grafo o red:

? Los diagramas de secuencia describen las interacciones en una especie de formato de cerca o muro:

Instancia1 : ClaseA Instancia2 : ClaseB

1: mensaje2() 2: mensaje3()mensaje1()

Instancia1 :ClaseA

Instancia2 :ClaseB

mensaje2()

mensaje3()

mensaje1()

3636


EX UMBRA SOLEMIN

Diseño Orientado a Objetos Ejemplo de un diagrama de colaboración: efectuarPago

: TPDV : Venta

: Pago

1: efectuarPago (efectivoOfrecido)

2: crear(efectivoOfrecido)

Dirección delmensaje

primermensaje

Primer mensajeinterno

Línea deenlace

Instancia

Parametro

efectuarPago( efectivoOfrecido)


EX UMBRA SOLEMIN

Diseño Orientado a Objetos Preparación de un diagrama de colaboración

? Elabore un diagrama por cada operación del sistema durante el ciclo actual de desarrollo. ? En cada mensaje del sistema, dibuje un diagrama incluyéndolo

como mensaje inicial. ? Si el diagrama se torna complejo (por ejemplo), si no cabe

holgadamente en una hoja de papel carta, divídalo en diagramas más pequeños.

? Diseñe un sistema de objetos interactivos que realicen las tareas, usando como punto de partida las responsabilidades del contrato de operación, las poscondiciones y la descripción de casos de uso.

? Aplique el GRASP y otros patrones para desarrollar un buen diseño


EX UMBRA SOLEMIN

Diseño Orientado a Objetos Relación entre los artefactos

: Cajero

:Sistema

introducir Producto(CUP, cantidad)

terminarVenta ()

efectuarPago(EfectivoOfrecido )

: TPDV

efectuarPago(efectivoOfrecido)

: TPDV

introducirProducto(CUP,cantidad)Contrato IntroducirProducto

Poscondiciones:1. Si se trata de una nueva ventase creo una nueva venta…

Contrato EfectuarPago

Poscondiciones:…

Diagrama de secuencia del sistema Contratos Diagrama de colaboración


EX UMBRA SOLEMIN

Diseño Orientado a Objetos Relación entre los artefactos

? Los casos de uso indican los eventos del sistema que se muestran explícitamente en los diagramas de secuencia.

? En los contratos se describe la mejor conjetura inicial sobre las operaciones del sistema.

? Las operaciones del sistema representan mensajes y éstos originan diagramas que explican gráficamente cómo los objetos interactúan para llevar a cabo las funciones requeridas.


EX UMBRA SOLEMIN

Diseño Orientado a Objetos Notación de los diagramas de interacción

? El UML ha adoptado un método simple y uniforme de distinguirlas visualmente las instancias de acuerdo a tipo: ? Con cada tipo de elemento del UML (clase, actor, ...), una insta ncia utiliza

el mismo símbolo gráfico usado para representar el tipo, pero se subraya el texto.

? El vínculo (o enlace) es una trayectoria de conexión entre dos instancias, indica la forma de navegación y visibilidad que es posible entre las instancias. ? En un lenguaje más formal, el vínculo es una instancia de una asociación.

Venta

Clase Instancia connombre

Instancia

: Venta s1: Venta


EX UMBRA SOLEMIN


? Si vemos dos instancias en una relación de cliente -servidor, una trayectoria de navegación del cliente alservidor significa que los mensajes pueden enviarse del primero al segundo. ? Así, existe un vínculo o trayectoria de navegación entre TPDV y

una Venta, a lo largo del cual pueden fluir los mensajes; por ejemplo, el mensaje agregarPago.

:TPDV :Venta

2: agregarPago(monto: Numero)mens1()

Parámetros

Todos los mensajes fluyen porel mismo vínculo .

3737


EX UMBRA SOLEMIN


? Los mensajes entre objetos pueden representarse por medio de una flecha con un nombre y situada sobre una línea del vínculo.? Se agrega un número de secuencia que indique el orden consecutivo de

los mensajes en la serie actual de control.

? Los parámetros de un mensaje pueden anotarse dentro de paréntesi s después del nombre del mensaje. Es opcional incluir o no el tipo de parámetro en cuestión

? El lenguaje UML cuenta con una sintaxis estándar para los mensajes: ? retorno : mensaje(parametro: tipoParametro) : tipoRetorno

? No obstante, es legal servirse de otra sintaxis como la de Java o la de Smalltalk. Recomendamos emplear la sintaxis estándar de UML a fin de que los diagramas de colaboración sigan siendo un lenguaje relativamente independiente


EX UMBRA SOLEMIN


? Un objeto puede enviarse un mensaje de a sí mismo: esto lo muestra gráficamente un vínculo consigo mismo, donde el mensaje fluye a lo largo del vínculo.

:TPDV

1: limpiar ()

mens1()


EX UMBRA SOLEMIN


? La iteración se indica posponiendo un asterisco (*) al número de secuencia. Ese símbolo significa que, dentro de un ciclo, el mensaje va a ser enviado repetidamente al receptor. También es posible incluir una cláusula de iteración que indique los valores de recurrencia.

:TPDV :Venta

1*: [i :=1..10] li:=siguienteLineadeProducto ( ) :VentasLineadeProductomens1()


EX UMBRA SOLEMIN


? El mensaje de creación independiente del lenguaje es crear, que se muestra en el momento de ser enviado a la instancia que vamos a generar.

? El mensaje crear puede contener parámetros, lo cual indica la transferencia de los valores iniciales.

:TPDV :Venta

1:crear(cajero)mens1()


EX UMBRA SOLEMIN


? El orden de los mensajes se indica con un número de secuencia, como se aprecia en la figura. El esquema de la numeración es:? El primer mensaje no se numera. Así, mens1() no lleva número. ? El orden y el anidamiento de los mensajes siguientes se indican

con un esquema legal de numeración, donde a los mensajes anidados se les ha antepuesto un número. La anidación se denota anteponiendo el número del mensaje de entrada al del mensaje de salida.

:TPDV :Venta

1:crear(cajero)mens1()


EX UMBRA SOLEMIN

Diseño Orientado a Objetos Numeración compleja de secuencias

: ClaseA : ClaseB

: ClaseC

: ClaseD

primero segundo

tercero

cuarto

quinto

sexto

1: mens2()

2: mens4()1.1: mens3()

2.1: mens5()

2.2: mens6()

3838


EX UMBRA SOLEMIN


? Un mensaje condicional se indica posponiendo al número de la secuencia una cláusula condicional entre corchetes, en forma parecida a como se hace con una cláusula de iteración. El mensaje se envía sólo si la cláusula se evalúa como verdadera.

:TPDV :Venta

1:[nueva venta]crear()mens1()


EX UMBRA SOLEMIN


? Un multiobjeto, o conjunto de instancias, puede dibujarse como un icono de pila según se observa en la figura.

? Un multiobjeto suele implementarse como un grupo de instancias guardadas en un contenedor u objeto colección; ? por ejemplo, un vector de la STL de C++, un Vector de Java o una

ColeccionOrdenada (OrderedCollection) de Smalltalk.

? Pero no necesariamente se implementa así; representa tan sólo un conjunto lógico de instancias.

Ventas : Venta

Multiobjeto


EX UMBRA SOLEMIN


? Un mensaje dirigido a un icono de multiobjeto indica que se envía al objeto colección. ? Así, en la figura el mensaje tamaño está siendo enviado a la

instancia VentasLineadeProducto.

? En el lenguaje UML los mensajes dirigidos a un multiobjetono se trasmiten a todos los elementos (como sucedía en las versiones anteriores del UML).

: VentasLineaDeProducto

mensaje enviado alobjeto colección

: Venta

1: s := tamaño(): entero


EX UMBRA SOLEMIN


? Los mensajes pueden ser dirigidos a la propia clase y no a una instancia, con el fin de llamar los métodos de la clase. ? Por ejemplo, en Java éstos se implementan como métodos

estáticos; en Smalltalk son métodos de clases.

? En consecuencia, es importante ser consistente en subrayar los nombres de las instancias cuando se desea denotar una instancia? De lo contrario pueden interpretarse erróneamente los mensajes

dirigidos a las instancias y los dirigidos a las clases.

: Venta Fecha

1: d1 :=hoy(): Fecha

no subrayada,por tanto una clase


EX UMBRA SOLEMIN

Diseño Orientado a Objetos Responsabilidades y métodos

? Booch y Rumbaugh definen la responsabilidad como “un contrato u obligación de un tipo o clase”. ? Las responsabilidades se relacionan con las obligaciones de un

objeto respecto a su comportamiento.

? Esas responsabilidades pertenecen, esencialmente, a las dos categorías siguientes: conocer o hacer

? Las responsabilidades se asignan a los objetos durante el diseño orientado a objetos. ? Por ejemplo, puede declararse que una Venta es responsable de

“imprimirse ella misma” (un hacer) o que “una Venta tiene la obligación de conocer su fecha” (un conocer).


EX UMBRA SOLEMIN


? Entre las responsabilidades de un objeto relacionadas con hacer se encuentran: ? hacer algo en uno mismo ? iniciar una acción en otros objetos? controlar y coordinar actividades en otros objetos

? Entre las responsabilidades de un objeto relacionadas con conocer se encuentran: ? estar enterado de los datos privados encapsulados ? estar enterado de la existencia de objetos conexos ? estar enterado de cosas que se puede derivar o calcular

? Las responsabilidades relacionadas con “conocer” a menudo pueden inferirse del modelo conceptual por los atributos y asociaciones explicadas en él.

3939


EX UMBRA SOLEMIN


? Responsabilidad no es lo mismo que método: los métodos se ponen en práctica para cumplir con las responsabilidades. ? Éstas se implementan usando métodos que operen solos o en

colaboración con otros métodos y objetos.

: Venta

significa que los objetosVenta tienen laresponsabilidad de imprimirse


vli : VentasLineaDeProducto

1: [en cada] vli :=siguiente()

2: imprimir()

imprimir()


EX UMBRA SOLEMIN


? La figura indica que a los objetos Venta se les ha asignado la responsabilidad de imprimirse ellos mismos, la cual se llama con un mensaje imprimir y se cumple con el método correspondiente imprimir.

? Más aún, para atender esta responsabilidad hay que colaborar con los objetos VentasLineadeProducto, pidiéndoles que se impriman.


EX UMBRA SOLEMIN


? En resumen, los diagramas de interacción muestran las decisiones referentes a la asignación de responsabilidades entre los objetos.

? Cuando se preparan, se toman decisiones sobre la asignación que se reflejan en los mensajes que son enviados a varias clases de objetos.

? Los patrones GRASP guían las decisiones sobre la asignación de responsabilidades. Esas decisiones se reflejan después en los diagramas de interacción.


EX UMBRA SOLEMIN

Diseño Orientado a Objetos Resumen

? Fase de Diseño ? Artefactos ? Actividades

? Casos Reales de Uso? Diagramas de Interacción


EX UMBRA SOLEMIN

Diseño Orientado a Objetos Quiz

? ¿Qué artefactos se preparan durante diseño OO? ? ¿Cuál es la diferencia entre análisis y diseño OO?

? ¿Qué es un caso de uso real?? ¿Qué representa un diagrama de interacción?

? ¿Cómo se trasmite el retorno de un mensaje?? ¿Porqué los objetos deben interactuar entre sí?

? ¿Cómo se interpreta el mensaje a multiobjeto? ? ¿Qué es la responsabilidad de una clase?


EX UMBRA SOLEMIN

Patrones de DiseñoContenido

? Patrones GRASP? Experto? Creador? Bajo Acoplamiento? Alta Cohesión? Controlador

4040


EX UMBRA SOLEMIN

Patrones de DiseñoGRASP: Patrones para Asignar Responsabilidades

? Un sistema orientado a objetos se compone de objetos que envían mensajes a otros objetos para que lleven a cabo las operaciones.

? En los contratos se incluye una conjetura inicial sobre las responsabilidades y las poscondiciones de las operaciones inicio, introducirProducto, terminarVenta y efectuarPago.

? Los diagramas de interacción describen gráficamente la solución -a partir de los objetos en interacción- que satisfacen estas responsabilidades y poscondiciones.


EX UMBRA SOLEMIN


? La calidad de diseño de la interacción de los objetos y la asignación de responsabilidades presentan gran variación. ? Las decisiones poco acertadas dan origen a sistemas y

componentes frágiles y difíciles de mantener, entender, reutilizar o extender.

? Una implementación hábil se funda en los principios cardinales que rigen un buen diseño orientado a objetos.

? En los patrones GRASP se codifican algunos de los principios, que se aplican al preparar los diagramas de interacción.


EX UMBRA SOLEMIN


? Los diagramas de interacción son algunos de los artefactos más importantes que se preparan en el análisis y diseño orientados a objetos.

? Es muy importante asignar acertadamente las responsabilidades almomento de elaborar ¡os diagramas de interacción.

? El tiempo y el esfuerzo que se dedican a su elaboración, así com o un examen riguroso de la asignación de responsabilidades, deberían absorber parte considerable de la fase de diseño de un proyecto.

? Los patrones, principios y expresiones especializadas codificados sirven para mejorar la calidad del diseño.


EX UMBRA SOLEMIN


? Los diseñadores expertos en orientación a objetos (y también otros diseñadores de software) van formando un amplio repertorio de principios generales y de expresiones que los guían al crear software.

? Muchos patrones ofrecen orientación sobre cómo asignar las responsabilidades a los objetos ante determinada categoría de problemas.


EX UMBRA SOLEMIN


? En la terminología de objetos, el patrón es una descripción de un problema y su solución, que recibe un nombre y que puede emplearse en otros contextos.

? En teoría, todos los patrones poseen nombres muy sugestivos. El asignar nombre a un patrón, a un método o a un principio ofrece las siguientes ventajas: ? Apoya el agrupamiento y la incorporación del concepto a nuestro sistema

cognitivo y a la memoria. ? Facilita la comunicación.

Nombre del Patrón ExpertoSolución Asignar una responsabilidad a la clase que tiene la

información necesaria para cumplirla.Problema que resuelve ¿Cuál es el principio fundamental en virtud del cual

asignaremos las responsabilidades a los objetos?


EX UMBRA SOLEMIN


? Los patrones GRASP son parejas de problema solución con un nombre, que codifican buenos principios y sugerencias relacionados frecuentemente con la asignación de responsabilidades.

Pregunta: ¿Qué son los patrones GRASP?Respuesta: Los patrones GRASP describen los principios

fundamentales de la asignación de responsabilidades aobjetos, expresados en forma de patrones.

4141


EX UMBRA SOLEMIN


? GRASP es un acrónimo que significa General ResponsibilityA signment Software Patterns (patrones generales de software para asignar responsabilidades).

? El nombre se eligió para indicar la importancia de captar (grasping) estos principios, si se quiere diseñar eficazmente el software orientado a objetos.


EX UMBRA SOLEMIN

Diseño Orientado a ObjetosNotación del UML para los diagramas de clase

? Los diagramas de clase en UML presentan las clases de software en contraste con los conceptos de dominio. La casilla de clase consta de tres secciones, la tercera contiene los métodos de la clase, como se aprecia en la figura.

NombredeClase

atributos

metodos( )

La tercerasección esta

destinada a losmétodos


EX UMBRA SOLEMIN

Patrones de DiseñoExperto

? Problema? ¿Cuál es el principio fundamental en virtud del cual se asignan las

responsabilidades en el diseño orientado a objetos?

? Un modelo de clase puede definir docenas y hasta cientos de clases de software, y una aplicación tal vez requiera el cumplimiento de cientos o miles de responsabilidades.

? Si estas se asignan en forma adecuada, los sistemas tienden a ser más fáciles de entender, mantener y ampliar, y se nos presenta la oportunidad de reutilizar los componentes en futuras aplicaciones.

? Solución? Asignar una responsabilidad al experto en información: la clase que cuenta

con la información necesaria para cumplir la responsabilidad.


EX UMBRA SOLEMIN


? Ejemplo

? En la aplicación del punto de venta, alguna clase necesita conocer el gran total de la venta. Comience asignando las responsabilidades con una definición clara de ellas. A partir de esta recomendación se plantea la pregunta:

?¿Quién es el responsable de conocer el gran total de la venta? ?Desde el punto de vista del patrón Experto, deberíamos buscar la

clase de objetos que posee la información necesaria para calcula r el total.


EX UMBRA SOLEMIN


*

1..*

1

Ventafechahora

EspecificaciondeProductosVentasLineaDeProductocantidad *

Descritas-por

Contenidas-en


EX UMBRA SOLEMIN


? En conclusión, para cumplir con la responsabilidad de conocer y dar el total de la venta, se asignaron tres responsabilidades a las tres clases de objeto así:

Clase ResponsabilidadVenta conoce el total de la ventaVentasLineadeProducto conoce el subtotal de la línea de productoEspecificaciondeProducto conoce el precio del producto

4242


EX UMBRA SOLEMIN


: Venta : VentasLineaDeProducto


1: [en cada] vli :=siguiente()

2: s t :=subtotal()

: EspecificaciondeProductos

3: p:= precio()

t :=total()


EX UMBRA SOLEMIN


? Experto es un patrón que se usa más que cualquier otro al asignar responsabilidades; es un principio básico que suele útil en el diseño orientado a objetos.

? Nótese, que el cumplimiento de una responsabilidad requiere a menudo información distribuida en varias clases de objetos.


EX UMBRA SOLEMIN


? Beneficios? Se conserva el encapsulamiento, ya que los objetos se valen de su

propia información para hacer lo que se les pide. Esto soporta un bajo acoplamiento, lo que favorece al hecho de tener sistemas más robustos y de fácil mantenimiento.

? El comportamiento se distribuye entre las clases que cuentan conla información requerida, alentando con ello definiciones de clase “sencillas” y más cohesivas que son más fáciles de comprender y de mantener. Así se brinda soporte a una alta cohesión.


EX UMBRA SOLEMIN

Patrones de DiseñoCreador

? Problema

? ¿Quién debería ser responsable de crear una nueva instancia de alguna clase? ? La creación de objetos es una de las actividades más frecuentes en

un sistema orientado a objetos. ? En consecuencia, conviene contar con un principio general para

asignar las responsabilidades concernientes a ella. ? El diseño, bien asignado, puede soportar un bajo acoplamiento,

una mayor claridad, el encapsulamiento y la reutilizabilidad.


EX UMBRA SOLEMIN


? El patrón Creador guía la asignación de responsabilidades relacionadas con la creación de objetos, tarea muy frecuente en los sistemas orientados a objetos.

? El propósito fundamental de este patrón es encontrar un creador que debemos conectar con el objeto producido en cualquier evento.

? Al escogerlo como creador, se da soporte al bajo acoplamiento.


EX UMBRA SOLEMIN


? Solución

? Asignarle a la clase B la responsabilidad de crear una instancia de clase A en uno de los siguientes casos: ? B agrega los objetos A.? B contiene los objetos A. ? B registra las instancias de los objetos A o ? B utiliza especialmente los objetos A ? B tiene los datos de inicialización que serán transmitidos a A cuando este

objeto sea creado (así que B es un Experto respecto a la creación de A). B es un creador de los objetos A.

? Si existe más de una opción, prefiera la clase B que agregue o contenga la clase A.

4343


EX UMBRA SOLEMIN


? Ejemplo

? En la aplicación del punto de venta, ¿quién debería encargarse de crear una instancia VentasLineadeProducto?

?Desde el punto de vista del patrón Creador, deberíamos buscar una clase que agregue, contenga y realice otras operaciones sobre este tipo de instancias


EX UMBRA SOLEMIN


*

1..*

1

Venta

fechahora

EspecificaciondeProductosVentasLineaDeProducto

cantidad *

Descritas-por

Contenidas-en


EX UMBRA SOLEMIN


? Una Venta contiene (en realidad, agrega) muchos objetos VentasLineadeProducto; ? por ello, el patrón Creador sugiere que Venta es idónea para

asumir la responsabilidad de crear las instancias VentasLineadeProducto.

? Esta asignación de responsabilidades requiere definir en Venta un método de hacer-LineadeProducto.


EX UMBRA SOLEMIN


: Venta : TPDV


1: [ nueva venta] crear()

2: crear()

introducirProducto(cup, cantidad)

SegúnControlador

SegúnCreador

Según Creador


EX UMBRA SOLEMIN


? En ocasiones encontramos un patrón creador buscando la clase con los datos de inicialización que serán transferidos durante la creación.

? Éste es en realidad un ejemplo del patrón Experto. ? Los datos de inicialización se transmiten durante la creación a

través de algún método de inicialización, como un constructor enjava que cuenta con parámetros.


EX UMBRA SOLEMIN

Patrones de DiseñoBajo Acoplamiento

? Problema? ¿Como dar soporte a una dependencia escasa y a un aumento de

la reutilización?

? El acoplamiento es una medida de la fuerza con que una clase está conectada a otras clases, con que las conoce y con que recurre aellas .? Acoplamiento bajo significa que una clase no depende de muchas

clases.? Acoplamiento altosignifica que una clase recurre a muchas otras

clases. Esto presenta los siguientes problemas:?Los cambios de las clases afines ocasionan cambios locales

?Difíciles de entender cuando están aisladas?Difíciles de reutilizar puesto que dependen de otras clases

4444


EX UMBRA SOLEMIN

Patrones de DiseñoBajo acoplamiento

? Solución? Asignar una responsabilidad para mantener bajo acoplamiento.

? Ejemplo: En el caso del punto de ventas se tienen tres clases Pago, TPDV y Venta y se quiere crear una instancia de Pago y asociarla a Venta. ¿Que clase es la responsable de realizarlo?

? Según el patrón experto la Clase TPDV deberá hacerlo

:TPDV P:Pago

:Venta

EfectuarPago( ) 1:Crea()

2:AgregarPago(p)


EX UMBRA SOLEMIN


? Según el patrón de Bajo Acoplamiento la relación debería ser de la siguiente manera:

? Esta última asociación es mejor dado que Venta realiza la creación del Pago y no TPDV por lo tanto se reduce la dependencia de este último con el resto de las clases.

? El grado de acoplamiento no puede considerarse aisladamente de otros principios como Experto y Alta Cohesión. Sin embargo, es un factor a considerar cuando se intente mejorar el diseño.

:TPDV :Venta

:Pago

EfectuarPago( ) 1:EfectuarPago ()

1.1:Crear()


EX UMBRA SOLEMIN


? En los lenguajes OO como C++ y JAVA las formas comunes de acoplamiento de TipoX a TipoY son las siguientes:

? TipoX posee un atributo (miembro de datos o variable de instancia) que se refiere a una instancia TipoY o al propio TipoY.

? TipoX tiene un método que a toda costa referencia una instancia de TipoYo incluso el propio TipoY. Suele incluirse un parámetro o una variable local de TipoY o bien el objeto devuelto de un mensaje es una instancia de TipoY.

? TipoX es una subclase directa o indirecta del TipoY.

? TipoY es una interfaz y TipoX la implementa.


EX UMBRA SOLEMIN


?Beneficios:

? No se afectan por cambios de otros componentes? Fáciles de entender por separado

? Fáciles de reutilizar


EX UMBRA SOLEMIN

Patrones de DiseñoAlta Cohesión

? Problema? ¿Cómo mantener la complejidad dentro de límites menejables?

? La cohesión es una medida de cuán relacionadas y enfocadas están las responsabilidades de una clase.

? Una alta cohesión caracteriza a las clases con responsabilidades estrechamente relacionadas que no realicen un trabajo enorme.

? Una baja cohesión hace muchas cosas no afines o realiza trabajo excesivo. Esto presenta los siguientes problemas:? Son difíciles de comprender? Difíciles de reutilizar? Difíciles de conservar? Las afectan constantemente los cambios.


EX UMBRA SOLEMIN


? Solución? Asignar una responsabilidad de modo que la cohesión siga siendo

alta

? Ejemplo: En el caso del punto de ventas se tienen tres clases Pago, TPDV y Venta y se quiere crear una instancia de Pago y asociarla a Venta. Según el principio del patrón Creador la clase TPDV debe ser la encargada de realizar el pago.

:TPDV P:Pago

:Venta

EfectuarPago( ) 1:Crea()

2:AgregarPago(p)

4545


EX UMBRA SOLEMIN


? ¿Qué pasa si el sistema tiene 50 operaciones, todas recibidas por la clase TPDV ?? La clase se iría saturando con tareas y terminaría perdiendo la

cohesión

? Un mejor diseño de lo anterior sería:

:TPDV :Venta

:Pago

EfectuarPago( ) 1:EfectuarPago ()

1.1:Crear()


EX UMBRA SOLEMIN


? Este diseño delega a Venta la responsabilidad de crear el pago.

? Este diseño es conveniente ya que da soporte a una alta cohesión y a un bajo acoplamiento.

? En la práctica, el nivel de cohesión no puede ser considerado independiente de los otros patrones y principios (e.g. Patrones “Experto” y “Bajo Acoplamiento”)

? Beneficios:? Mejoran la claridad y facilidad con que se entiende el diseño? Se simplifica el mantenimiento y las mejoras de funcionalidad? A menudo se genera un bajo acoplamiento? Soporta mayor capacidad de reutilización.


EX UMBRA SOLEMIN


? Algunos escenarios:

? Muy baja cohesión:Una clase es la única responsable de muchas cosas en áreas funcionales heterogéneas.

? Baja cohesión: Una clase tiene la responsabilidad exclusiva de una tarea compleja dentro de un área funcional.

? Alta cohesión: Una clase tiene responsabilidades moderadas en un área funcional y colabora con las otras para llevar a cabo las tareas.

? Cohesión moderada:Una clase tiene peso ligero y responsabilidades exclusivas en unas cuántas áreas que están relacionadas lógicamente con el concepto de clase pero no entre ellas.


EX UMBRA SOLEMIN

Patrones de DiseñoControlador

? Problema: ? ¿Quién deber ía encargarse de atender un evento del sistema?

? Un evento del sistema es un evento de alto nivel generado por un actor externo; es un evento de entrada externa. Se asocia a operaciones del sistema: las que emite en respuesta a los eventos del sistema. ? Por ejemplo, cuando un cajero que usa un sistema de terminal en el punto

de venta oprime el botón "Terminar Venta ”, está generando un evento sistémico que indica que “la venta ha terminado”.

? Un Controlador es un objeto de interfaz no destinada al usuario que se encarga de manejar un evento del sistema. Define además el método de su operación.


EX UMBRA SOLEMIN


? Solución

? Asignar la responsabilidad del manejo de un mensaje de los eventosde un sistema a una claseque represente una de las siguientesopciones:

? el “sistema” global ( controlador de fachada).

? la empresa u organización global ( controlador de fachada). ? algo en el mundo real que es activo (por ejemplo, el papel de una

persona) y que pueda participar en la tarea (controlador de tareas). ? un manejador artificial de todos los eventos del sistema de un caso de

uso, generalmente denominados “Manejador<NombreCasodeUso>” (controlador de casos de uso).


EX UMBRA SOLEMIN


? Ejemplo:? En la aplicación del punto de ventase dan varias

operaciones del sistema, comose advierte en la figura.

? ¿Quién debería ser el controlador de eventos sistémicos como introducirProducto yterminarVenta?

Sistema

terminarVenta( )introducirProducto( )efectuarPago( )

: ???

introducirProducto(CUP, cantidad)¿Qué clase debe encargarse de manejar este mensaje de eventos de sistema?

Un controlador

4646


EX UMBRA SOLEMIN


? De acuerdo con el patrón Controlador, disponemos de las siguientes opciones:

representa el “sistema” global TPDV

representa la empresa u organizaci ón global Tienda

representa algo en el mundo real que est á activo (por ejemplo, el papel de una persona) y que puede intervenir en la tarea

Cajero

representa un manejador artificial de todas las operaciones del sistema de un caso de uso.

ManejadordeComprarProductos


EX UMBRA SOLEMIN


? En la decisión de cuál de las cuatro clases es el controlador más apropiado influyen también otros factores como la cohesión y el acoplamiento.

asignación de lasoperaciones del sistemadurante su diseño, medianteel patrón Controlador

operaciones delsistema descubiertasdurante el análisis desu comportamiento

TPDV


Sistema



EX UMBRA SOLEMIN


? Explicación: La mayor parte de los sistemas reciben eventos de entrada externa, los cuales generalmente incluyen una interfaz gráfica para el usuario (IGU) operado por una persona.

? La misma clase controlador debería utilizarse con todos los eventos sistémicos de un caso de uso, de modo que podamos conservar la información referente al estado del caso. ? Esta información será útil - por ejemplo - para identificar los

eventos del sistema fuera de secuencia (entre ellos, una operación efectuarPago antes de terminarVenta). Pueden emplearse varios controladores en los casos de uso.


EX UMBRA SOLEMIN


? Un defecto frecuente al diseñar controladores consiste en asignarles demasiada responsabilidad. Normalmente un controlador debería delegar a otros objetos el trabajo que ha de realizarse mientras coordina la actividad.


EX UMBRA SOLEMIN


? “Manejador artificial de casos de uso” - un controlador para cada caso. ? Adviértase que éste no es un objeto del dominio, es un concepto

artificial, cuyo fin es dar soporte al sistema (una fabricación pura, en términos de los patrones de GRASP).

? Por ejemplo, si la aplicación del punto de venta contiene casos de uso como “Comprar Productos” y “Devolver Productos”, habrá una clase ManejadordeComprarProductos y una clase ManejadordeDevolverProductos .

? Es una alternativa que debe tenerse en cuenta, si el hecho de asignar las responsabilidades en cualquiera de las otras opciones de controlador genera diseños de baja cohesión o alto acoplamiento. Esto ocurre generalmente cuando un controlador empieza a “saturarse” con demasiadas responsabilidades.


EX UMBRA SOLEMIN


? Beneficios

? Mayor potencial de los componentes reutilizables. Garantiza que la empresa o los procesos de dominio sean manejados por la capa de los objetos del dominio y no por la de la interfaz.

? Reflexionar sobre el estado del caso de uso. A veces es necesario asegurarse de que las operaciones del sistema sigan una secuencia legal o poder razonar sobre el estado actual de la actividad y las operaciones en el caso de uso subyacente. ? Por ejemplo, tal vez deba garantizarse que la operaci ón efectuarPago no

ocurra mientras no se concluya la operaci ón terminarVenta . De ser así, esta informaci ón sobre el estado ha de capturarse en alguna parte; el controlador es una buena opción, sobre todo si se emplea a lo largo de todo el caso.

4747


EX UMBRA SOLEMIN


? Un corolario importante del patrón Controlador es que los objetos de la interfaz (por ejemplo, objetos de ventanas, applets) y la capa de presentación no deberían encargarse de manejar los eventos del sistema.


EX UMBRA SOLEMIN


? Nótese que la clase TPDVApplet - parte de la capa de presentaci ón -transmite un mensaje introducirProducto al objeto TPDV.

? No intervino en el proceso de la operación, ni la decisi ón de cómo manejarla, el applet se limitó a delegarla a la capa del dominio.

Tienda de Objetos

CUP

Precio

Total

Ofrecido

Cantidad

Desc.

Saldo

IntroducirProducto

TerminarVenta

EfectuarPago

enIntroducirProducto()

: TPDVApplet

: TPDV : Venta

1: introducirProducto(cup, cantidad)

2: hacerLineadeProducto(cup,cantidad)

Controlador

mensaje de eventosdel sistema

Oprime botón

Cajero

Capa de presentaciónApplet en Java

Capa del Dominio


EX UMBRA SOLEMIN

Patrones de DiseñoResumen

? Patrones GRASP? Experto? Creador? Bajo Acoplamiento? Alta Cohesión? Controlador


EX UMBRA SOLEMIN

Patrones de DiseñoResumen

? ¿Qué define un patrón? ? ¿Porqué se le asigna un nombre?

? ¿Qué significa GRASP?? ¿Existen casos cuando dos o más patrones se aplican

juntos?

? Describa brevemente cada uno de estos patrones: ? Experto? Creador? Controlador? Alta Cohesión ? Bajo Acoplamiento


EX UMBRA SOLEMIN

Diseño de una Solución Contenido

? Aplicación de los patrones GRASP para asignar responsabilidades a las clases.

? Uso de la notación de UML en los diagramas de colaboración para describir gráficamente el diseño de la interacción de objetos.


EX UMBRA SOLEMIN

Diseño de una Solución Introducción

? En la práctica, los diseñadores se percatan de que lapreparación de los diagramas de interacción es uno de los pasos más lentos.

? La asignación de responsabilidades y la elaboración de los diagramas de interacción representan uno de los pasos más importantes en la fase de diseño.

4848


EX UMBRA SOLEMIN

Diseño de una Solución Relación entre artefactos

: Cajero

:Sistema

introducir Producto(CUP, cantidad)

terminarVenta ()

efectuarPago(EfectivoOfrecido )

: TPDV

efectuarPago(efectivoOfrecido)

: TPDV

introducirProducto(CUP,cantidad)Contrato IntroducirProducto

Poscondiciones:1. Si se trata de una nueva ventase creo una nueva venta…

Contrato EfectuarPago

Poscondiciones:…

Diagrama de secuencia del sistema Contratos Diagrama de colaboración


EX UMBRA SOLEMIN

Diseño de una Solución Diagramas de interacción y eventos del sistema

? En la iteración actual de la aplicación del punto de venta estamos considerando dos casos de uso y sus eventos sistemáticos asociados: ? Comprar Productos: introducirProducto terminarVenta

efectuarPago? Inicio: inicio

? Por cada evento del sistema se construye un diagrama de colaboración cuyo mensaje inicial sea el de sus eventos. ? Habrá, pues, cuatro diagramas de interacción por lo menos: uno

por cada evento del sistema.


EX UMBRA SOLEMIN

Diseño de una Solución Diagramas de interacción y eventos del sistema

: TPDV

introducirProducto () 1 :???()

: TPDV

terminarVenta () 1 :???()

: TPDV

efectuarPago() 1 :???()

: TPDV

iniciar() 1 :???()


EX UMBRA SOLEMIN

Diseño de una Solución Diagramas de interacción y contratos

? En cada contrato revisamos los cambios de estado de los objetos responsables y las poscondiciones asociadas.? Nótese que, en caso de omitir la preparación del contrato, de todos

modos deberíamos elaborar los diagramas de interacción retornando a los casos de uso y reflexionando sobre lo que debemos lograr.

? No obstante, los contratos organizan y aíslan la información en un formato funcional, al mismo tiempo que estimulan la investigación en la fase de análisis y no en la de diseño.


EX UMBRA SOLEMIN


? Por ejemplo, en esta operación parcial del sistema introducirProducto, en la figura incluimos un diagrama parcial de colaboración que satisface el cambio de estado de la creación de Venta.

:TPDV :Venta

1:[ nueva venta] crear() introducirProducto(cup, cantidad)


EX UMBRA SOLEMIN


? Los Diagramas deben prepararse con el propósito de cumplir las poscondiciones del contrato. ? Poscondiciones definidas de antemano no son sino una excelente

conjetura o estimación inicial de lo que se pretende alcanzar. ? En los contratos debemos ver un mero punto de partida para

establecer lo que se hará, pero sin sentirnos obligados por ellos.

? Una ventaja del desarrollo iterativo radica en que brinda un soporte espontáneo a la detección de nuevos resultados del análisis y del diseño durante las fases de solución y de construcción

4949


EX UMBRA SOLEMIN

Diseño de una Solución Diagramas de interacción y modelo conceptual

? Algunos de los objetos que interactúan a través de mensajes en los diagramas de colaboración provienen del modelo conceptual.

? En parte, la elección de la asignación acertada de las responsabilidades mediante los patrones GRASP se funda en la información contenida en el modelo conceptual.


EX UMBRA SOLEMIN

1Pago

11

*

1

1..*

1 1Venta

fechahora

Pagado-por

1..*TPDV

1

1

Capturadas-en

1

*


Contenidas-en

1

*Producto

1

*Tienda

direccion

1

Capturas-Terminada

Aloja

1

1..*


*

1

Descrita-por

Describe

1CatalogoDeProductosdescripcionprecioC U P

Usado-por

1..*1

Contiene

Diseño de una Solución Diagramas de interacción y modelo conceptual


EX UMBRA SOLEMIN

Diseño de una Solución Diagrama de colaboración: introducirProducto

ContratoNombre: IntroducirProducto ( cup:numero, cantidad:entero)Responsabilidades: Capturar (registrar) la venta de un producto y agregarla a la venta. Desplegar


Casos de uso: Comprar productosNotas: Utilizar el acceso superrápido a la base de datos.Excepciones: Si el CUP no es válido, indicar que se cometió un error.Salida:Precondiciones: El sistema conoce el CUP.Poscondiciones:? Si se trata de una nueva venta, se creó una Venta (creación de instancia).? Si se trata de una nueva venta, la nueva Venta fue asociada a un TPDV ( asociación

formada ).? Se creó una instancia VentasLineadeProducto (creación de instancia).? Se asoció una instancia de VentasLineadeProducto a la Venta (asociación formada ).? Se asignó una cantidad a VentasLineadeProducto.cantidad (modificación de atributo).? Se asoció una instancia VentasLineadeProducto a la instancia

EspecificaciondeProducto, basado en la correspondencia del CUP ( asociaciónformada ).


EX UMBRA SOLEMIN

Diseño de una Solución Selección de la clase Controlador

? En la elección del controlador que se encargue del mensaje de las operaciones del sistema introducirProducto, disponemos de las siguientes opciones:

? Representa el "sistema" global? TPDV

? Representa la empresa u organización global? Tienda

? Representa algo en el mundo real que está activo (por ejemplo, e l papel de una persona) y que puede intervenir en la tarea? Cajero

? Representa un manejador artificial de todas las operaciones del sistema de un caso de uso.? ManejadordeComprarProductos


EX UMBRA SOLEMIN


? Un controlador de fachada como TPDV es adecuado? si el sistema ofrece pocas operaciones y si ese controlador no

asume demasiadas responsabilidades (en otras palabras, si empieza a perder cohesión).

? Un controlador de papeles o de casos de uso será una decisión acertada? cuando el sistema tiene demasiadas operaciones y queremos

distribuir las responsabilidades para que las clases controlador no se atiborren, ni pierdan su orientación central (o sea, que seancohesivas).

? En este caso, TPDV será suficiente porque el sistema tiene pocas operaciones.


EX UMBRA SOLEMIN


? Es importante darse cuenta que “TPDV” es una instancia de un objeto en el “territorio del software”.

? No es un terminal real de punto de venta, sino una abstracción de software que representa el registro

:TPDV


5050


EX UMBRA SOLEMIN

Diseño de una Solución Presentación visual de la descripción y del precio

? En virtud de un principio del diseño denominado separación de modelo - vista (Controlador), no compete a los objetos del dominio (como TPDV o Venta) comunicarse con la capa de interfaz para el usuario (las ventanas gráficas, por ejemplo).

? Lo único que se requiere en lo tocante a las responsabilidades del despliegue de la información es conocer los datos, como se verá en este caso.


EX UMBRA SOLEMIN

Diseño de una Solución Realización de una nueva venta

? Poscondiciones contractuales establecen lo siguiente:

? Si se trata de una nueva venta, se creó una Venta (creación de instancia).

? Si se trata de una nueva venta, se asoció la nueva Venta a TPDV (asociación formada).

? Además, cuando se crea la Venta, hay que generar una colección vacía para que registre todas las instancias futuras VentasLineadeProducto.


EX UMBRA SOLEMIN

Diseño de una Solución Realización de una nueva venta

: Venta: TPDV


1: [nueva venta ] crear()

2: crear()


SegúnControlador

SegúnCreador

Según Creador


EX UMBRA SOLEMIN

Diseño de una Solución Creación de una instancia VentasLineadeProducto

? Algunas otras poscondiciones contractuales de introducirProducto establecen lo siguiente:

? Se creó una instancia VentasLineadeProducto (creación de instancia).

? Se asocióVentasLineadeProducto a la Venta (asociación formada). ? Se asignó el valor a VentasLineadeProducto.cantidad de cantidad

(modificación de atributo).? Se asoció la instancia VentasLineadeProducto con una

EspecificaciondeProducto a partir de la correspondencia en el CUP (asociación formada).


EX UMBRA SOLEMIN

Diseño de una Solución Obtención de instancia EspecifícaciondeProducto

? Necesitamos asociar la instancia VentasLineadeProducto aEspecificaciondeproducto que concuerde con el CUP que se recibe. Ello significa que se requiere recuperar una EspecificaciondeProducto basada en la correspondencia del CUP.

? Un primer paso de gran utilidad es el siguiente:

Comience asignando las responsabilidades definiéndolas con claridad.


EX UMBRA SOLEMIN

Diseño de una Solución Obtención de instancia EspecifícaciondeProducto

? ¿Quién debería asumir la responsabilidad de conocer una instancia EspecificaciondeProducto basado en que coincida el valor del CUP? ? En la generalidad de los casos, el patrón Experto de GRASP es el

principio que ha de aplicarse en primer lugar.

? ¿Quién está enterado de todo lo concerniente a EspecificaciondeProducto? ? El análisis del modelo conceptual revela que CatalogodeProductos

contiene lógicamente todas las especificaciones de productos y así, de acuerdo con el patrón Experto, CatalogodeProductos es idóneo para asumir esta responsabilidad de consulta.

5151


EX UMBRA SOLEMIN

Diseño de una Solución Visibilidad ante un CatalogodeProductos

? ¿Quién debería enviar el mensaje especificación al CatalogodeProductos para solicitar una EspecificaciondeProducto? ? Es razonable suponer que una instancia TPDV y una de

CatalogodeProductos fueron creadas durante el caso inicial de uso Inicio y que existe una conexión permanente entre el objeto TPDVy el objeto CatalogodeProductos .

? Esta suposición nos permitirá concluir que TPDV puede enviar el mensaje especificación a Catálogo de productos.


EX UMBRA SOLEMIN

Diseño de una Solución Visibilidad ante un CatalogodeProductos

? Ello significa la existencia de otro concepto en el diseño orientado a objetos: el de visibilidad.

? La visibilidad es la capacidad de un objeto para 'ver' o tener una referencia a otro. Para que un objeto envíe a otro un mensaje, debe ser visible al segundo. ? Supondremos que TPDV tiene una conexión o referencia

permanente a CatalogodeProductos; por tanto, es visible para esta instancia y de ahí que pueda enviarle Mensajes como especificación


EX UMBRA SOLEMIN

Diseño de una Solución Recuperación de EspecificaciondeProducto

? En la versión final de una aplicación real al punto de venta, difícilmente todas las EspecificaciondeProducto estarán en la memoria. ? Lo más probable es que se encuentren almacenadas en una base

de datos relacional o de objetos y que sean recuperadas previa solicitud.

? No obstante, para no hacer compleja la exposición pospondremos el estudio de los problemas concernientes a la recuperación partiendo de una base de datos.

? Supondremos que todas las EspecificaciondeProducto se hallan en la memoria. Más tarde se tratará el tema del acceso a la base de datos de objetos persistentes.


EX UMBRA SOLEMIN

Diseño de una Solución Diagrama de colaboración introducirProducto

? El diagrama de colaboración de la figura refleja las decisiones sobre la asignación de responsabilidades y sobre la manera en que los objetos deberían interactuar.

? Observe que se reflexionó detenidamente para llegar a él, con base en los patrones GRASP.

? El diseño de las interacciones de los objetos y la asignación de responsabilidades requieren una seria deliberación.


EX UMBRA SOLEMIN

: Venta: TPDV


SegúnControlador Según

Creador

: EspecificaciondeProductos

: CatalogoDeProductos


6: crear(especif,cant)

4: crear()

7: agregar(vli)

1: [nueva venta ] crear()

5: hacerLineadeProducto(especif,cant)

2: especif :=especificacion(cup)

3: especif :=encontrar(cup)

introducirProducto(cup, cant)

Según Experto

Diseño de una Solución Diagrama de colaboración introducirProducto


EX UMBRA SOLEMIN

Diseño de una Solución Mensajes a multiobjetos

? La interpretación predeterminada de un mensaje enviado a un multiobjeto es que se envía implícitamente a todos los elementos de la colección/contenedor, pero también puede interpretarse como un mensaje dirigido al propio objeto colección.

5252


EX UMBRA SOLEMIN

Diseño de una Solución Mensajes a multiobjetos

? Por ejemplo, en el Diagrama de colaboración introducirProducto:

? El mensaje encontrar (3) enviado al multiobjetoEspecificaciondeProducto se dirige una vez a la estructura de datos colección representada por el multiobjeto.

? El mensaje crear (4) enviado al multiobjetoVentasLineadeProductotiene por objeto generar la estructura de datos colección representada por el multiobjeto; su finalidad no es crear una instancia de la clase VentasLineadeProducto.

? El mensaje agregar (7) enviado al multiobjetoVentasLineadeProducto tiene por objeto incorporar un elemento a la estructura de datos colección representada por el multiobjeto.


EX UMBRA SOLEMIN

Diseño de una Solución Diagrama de colaboración terminarVenta

? Ejercicio:

Desarollar el Diagrama de colaboración para el caso de término de una venta.

ContratoNombre: terminarVenta()Responsabilidades: Registrar que se terminó de capturar los artículos de la venta ypresentar

visualmente el total de la venta.Tipo: SistemaReferencias cruzadas: Funciones del sistema: R1.2.

Casos de uso: Comprar Productos.Notas: Utilizar el acceso superrápido a la base de datos.Excepciones: Si está efectuándose una venta, indicar que se cometió un error.Salida:Precondiciones: El sistema conoce el CUP.Poscondiciones:Se asignó a Venta.estaTerminada el valor verdadero (modificación de atributo).


EX UMBRA SOLEMIN

Diseño de una Solución Cálculo del total de la venta: Solución

: Venta



EspecifPro : EspecificaciondeProductos

Venta - total{tot:= 0para cada VentasLineadeProducto , vli

tot:= tot+vli.subtotal()devolver tot}

SegúnExperto

VentasLineadeProducto - subtotal(){devolver cantidad*EspecifPro.precio()}

Según Experto

1: * [para cada]vli: =siguiente ()

2: s t :=sutotal()tot:=total()

3: pre:=prec()


EX UMBRA SOLEMIN

Diseño de una Solución Diagrama de colaboración: Iniciar

? ¿Cuándo crear el diagrama de colaboración Iniciar? ? La mayoría de los sistemas, si no es que todos, tienen un caso de

uso Iniciar y alguna operación inicial relacionada con el comienzo de la aplicación. Aunque es la primera en ser ejecutada, se ha considerado la conveniencia de posponer la preparación del respectivo diagrama de colaboración hasta después de considerar el resto de las operaciones del sistema.

? Prepare al final el diagrama de colaboración Iniciar.


EX UMBRA SOLEMIN


? El diagrama de colaboración de la operación Iniciardescribe lo que sucede cuando se crea el objeto inicial del dominio del problema y, opcionalmente, lo que sucede si asume el control.

? No incluye ninguna actividad anterior ni subsecuente en la capa de objetos destinada a la interfaz gráfica para el usuario, si es que existe.


EX UMBRA SOLEMIN


? Por tanto la operación Iniciar puede interpretarse así:

? En un diagrama de colaboración, envíe un mensaje crear() para producir el objeto inicial del dominio.

? (opcional) Si el objeto inicial va a asumir el control del proceso, en un segundo diagrama de colaboración envíele un mensaje ejecutar (u otro equivalente).

5353


EX UMBRA SOLEMIN


? ¿Cuál debería ser la clase del objeto inicial del dominio? ? Escoja como objeto inicial del dominio:

? Una clase que represente todo el sistema de información lógico.? Una clase que represente íntegramente el negocio u organización.

? En la selección de estas opciones pueden influir consideracionesreferentes a los patrones Alta Cohesión y Bajo Acoplamiento.

? Todo el Sistema de información lógico: TPDV, SistemaInformacionalmenudeo

? Negocio u organización global: Tienda

? En esta aplicación se escogió la Tienda como objeto inicial.


EX UMBRA SOLEMIN


ContratoNombre: IniciarO.Responsabilidades: Inicializar el sistema.Tipo: SistemaReferencias cruzadas:Notas:Excepciones:Salida:Precondiciones:Poscondiciones:? Se crearon Tienda , TPDV , CatalogodeProductos y EspecificaciondeProducto (creación

de instancia).? Se asoció CatalogodeProductos a EspecificaciondeProducto (asociación formada).? Se asoció Tienda a CatalogodeProductos (asociación formada)? Se asoció Tienda a TPDV (asociación formada).? Se asoció TPDV a CatalogodeProductos (asociación formada).


EX UMBRA SOLEMIN


: Tienda : TPDV

cp : CatalogoDeProductos

: EspecificaciondeProducto

ep : EspecificaciondeProducto

1: crear()2: * crear()

3: cargarEspecifPro()

4: * crear(cup, precio, descripcion)

5: agregar(ep)

6: crear(cp)crear()

Transmite una referencia a Catalogo deProductos de modo que seapermanentemente visible a TPDV

* indica que le mensajeocurre en la sección demanera repetida o iterativa


EX UMBRA SOLEMIN


? Una discrepancia interesante entre el análisis y el diseño se ejemplifica en el hecho de que la Tienda sólo crea unobjeto TPDV.

? Desde el punto de vista analítico, una tienda real puede albergar muchas terminales en el punto de venta. Pero ahora estamos considerando un diseño de software, no lo que ocurre en el mundo real.

? La Tienda y TPDV representada en un diagrama de colaboración no es una tienda real; es un objeto de software.

? En nuestros requerimientos actuales, el objeto de SW Tienda no necesita crear más que una sola instancia del objeto de SWTPDV.


EX UMBRA SOLEMIN

Diseño de una Solución Resumen

? Aplicación de los patrones GRASP para asignar responsabilidades a las clases.

? Uso de la notación de UML en los diagramas de colaboración para describir gráficamente el diseño de la interacción de objetos.


EX UMBRA SOLEMIN

Diseño de una Solución Quiz

? ¿Cuál es la utilidad del contrato para diagramas de interacción?

? ¿Cuál es la utilidad del modelo conceptual para diagramas de interacción?

? ¿Cuando se prepara el contrato para el caso de uso Iniciar?

? ¿En qué ayudan los patrones?? ¿Cual es el orden de aplicación de los patrones vistos?

Documents

Análisis y diseño orientado a objetos - inf.utfsm.clliuba/taller/ad_oo1.pdf · ?Uso de UML?Introducción al proceso de desarrollo Fundamentos de Ingeniería de SW 74 UTFSM EX UMBRA