1 Análisis y Diseño Orientado a ObjetosMagíster en Ingeniería de Negocios con TI Universidad de Chile. Profesores: Sebastián Ríos Pablo Román Relator: Ángel Jiménez Fuente: “UML y PATRONES”, Craig Larman, 1Ed y 2 Ed.

2 Introducción La gran mayoría de aplicaciones se construyen para terceras personas. Por lo tanto, se requiere entender qué es lo que ellos necesitan. ¿Es posible saber qué es lo que necesitan los usuarios? ¿Con que grado de exactitud se requiere saber esta información?

3 Introducción (Cont.)

4 Introducción (Cont.) La tarea más compleja es lograr encontrar, comunicar y registrar todo lo que se necesita, de modo que sea claro para el cliente y para el equipo de desarrollo

5

6 ¿Qué son el Análisis y el Diseño?Para crear una aplicación de software hay que describir el problema y las necesidades o requerimientos. El análisis se centra en la investigación del problema, no en la manera de definir una solución. Para desarrollar una aplicación, también es necesario contar con descripciones detalladas y de alto nivel. El diseño implica una solución lógica: cómo el sistema cumple con los requerimientos.

7 ¿Qué son el Análisis y el Diseño Orientado a Objetos (OO)?La esencia del análisis y el diseño OO, consiste en situar el dominio de un problema y su solución lógica dentro de la perspectiva de los objetos (cosas, conceptos o entidades) Análisis: Identificar y describir los objetos en el dominio del problema. Diseño y construcción: Se busca definir los objetos lógicos del software que serán implementados en un lenguaje de programación OO. Análisis Diseño Construcción Investigación del problema Solución lógica Código

8 ¿Qué son el Análisis y el Diseño Orientado a Objetos (OO)?La OO se centra en la representación de objetos Concepto del dominio Representación en el análisis de conceptos Libro Título Imprimir () Public class Libro { public void print(); private string título; } Representación en un Lenguaje de Programación OO

9 El Lenguaje Unificado de Modelamiento (UML)“Se define como un lenguaje que permite especificar, visualizar y construir los artefactos de los sistemas de software”. BJR97 Es un sistema notacional que además incluye el significado de sus notaciones. No es exactamente un estándar pero está muy difundido en la industria del software. Nació en 1994 por iniciativa de Grady Booch y Jim Rumbaugh para combinar sus dos famosos métodos: el de Booch y el OMT (Object Modeling Technique). Después de se les unió Ivar Jacobson, creador del método OOSE (Object-Oriented Software Engineering). En respuesta a la petición de la OMG (Object Management Group) en 1997 propusieron UML.

10 Artefacto Pieza de información utilizada o producida por un proceso de desarrollo de software. Un artefacto puede ser un modelo, una descripción documentada, una componente de aplicaciones, un módulo o un software.

11 El Lenguaje Unificado de Modelamiento (UML)UML es un lenguaje para construir modelos. No guía al desarrollador en la forma de realizar el análisis y diseño OO, ni le indica cuál proceso de desarrollo adoptar. Los metodólogos seguirán definiendo técnicas, modelos y procesos de desarrollo para la creación eficaz de sistemas de software. (Ej. Diseño de aplicaciones E-Business basadas en patrones de procesos de negocio) Ahora todos lo harán en un lenguaje común: UML

12 Clasificación de las Vistas en UMLClasificación estructural. Comportamiento dinámico. Gestión del modelo. La clasificación estructural describe los elementos del sistema y sus relaciones con otros elementos (clases, casos de uso, componentes => vista estática) La segunda describe el comportamiento dinámico en el tiempo: serie de cambios a las fotos del sistema dibujadas a partir de la visión estática => vista dinámica. La gestión del modelo describe la organización de los propios modelos en unidades jerárquicas. El paquete es la unidad jerárquica.

13 Pasos a Seguir en AnálisisAlgunas de las tareas a realizarse en la etapa de análisis son las siguientes: Definir los requerimientos. Definir los casos esenciales de uso. Crear y perfeccionar Casos de uso Crear diagrama de casos de uso. Especificar escenarios. Crear y perfeccionar el modelo conceptual. Definir los diagramas de secuencia de alto nivel del sistema.

14 Relaciones entre Artefactos en la Fase de AnálisisEspecificaciones de requerimientos Informe preliminar de investigación Casos de uso: Todos de alto nivel. Algunos esenciales expandidos Prototipos Diagramas de casos de uso Presupuesto, programa Modelo conceptual preliminar Dependencia respecto a Glosario

15 Definición de RequerimientosBuenas Prácticas de Gestión

16 Contexo Especificaciones de requerimientosInforme preliminar de investigación Casos de uso: Todos de alto nivel. Algunos esenciales expandidos Prototipos Diagramas de casos de uso Presupuesto, programa Modelo conceptual preliminar Dependencia respecto a Glosario

17 Los Requerimientos Son una descripción de las necesidades o deseos de los clientes. La meta principal en esta etapa es identificar y documentar lo que en realidad se necesita, en una forma que pueda fácilmente ser transmitida al cliente y al equipo de desarrollo. Se recomienda aquí definir al menos los siguientes puntos: Panorama general. Metas. Funciones del sistema. Atributos de calidad del sistema

18 Caso de Estudio: el Punto de VentaSupongamos como caso de estudio el sistema de una terminal de punto de venta. Esta terminal es un sistema automatizado con el que se registran las ventas y se realizan los pagos. Por lo general este tipo de sistemas comprenden hardware (un computador y un lector de código barras) y software (el sistema que se ejecuta en la terminal). Suponga que se nos ha contratado para crear este software.

19 Ejemplo: Panorama general Este proyecto tiene por objeto crear un sistema de terminal para el punto de venta que se utilizará en las ventas al menudeo. Metas En términos generales, la meta es una mayor automatización del pago en las cajas registradoras, y dar soporte a servicios más rápidos, más baratos y mejores. Más concretamente, la meta incluye: Pago rápido de los clientes. Análisis rápido y exacto de las ventas. Control automático del inventario.

20 Ejemplo: Funciones del sistemaLas funciones del sistema son lo que éste deberá de hacer. Hay que identificar estas funciones y listarlas en grupos lógicos. Para verificar que X es en verdad una función del sistema, la siguiente frase deberá tener sentido: "El sistema deberá hacer X". Por ejemplo: "el sistema deberá autorizar pagos a crédito". Las funciones pueden clasificarse en tres categorías: evidentes, ocultas y superfluas. Las evidentes deben realizarse, y el usuario debe saber que se han realizado. Las ocultas también deben realizarse, y puede que no sean visibles para el usuario. Muchas de estas funciones se omiten (erróneamente) durante el proceso de obtención de requerimientos. Las superfluas son opcionales, y su inclusión no repercute significativamente en el costo ni en otras funciones.

21 Ejemplo: Atributos del sistemaSon sus características o dimensiones. No son funciones. Ejemplo: facilidad de uso, tolerancia a las fallas, tiempos de respuesta, costos al detalle, plataformas, metáfora de interfaz, etc. Pueden abarcar todas las funciones (p.ej. la plataforma del sistema operativo) o ser específicos de una función o grupo de funciones. Los atributos tienen un posible conjunto de detalles, que tienden a ser valores discretos: P.ej. Tiempo de respuesta = (Psicológicamente correcto) Metáfora de interfaz = (gráfico, colorido, basado en formas) También pueden tener valores fronteras: Tiempo de respuesta = (5 segs. Como máximo)

22 Detalles y Restricciones de FronteraEjemplo: Atributo Detalles y Restricciones de Frontera Tiempo de respuesta (rest. de frontera) Cuando se registre un producto vendido, la descripción y el precio aparecerán en 5 segs. Metáfora de interfaz (Detalle) Ventanas orientadas a la metáfora de cuadros de diálogo (Detalle) Maximiza una navegación fácil con teclado y no con mouse. Tolerancia a fallas (Rest. de frontera) Debe registrar los pagos a crédito autorizados que se hagan a las cuentas por cobrar en un plazo de 24 hrs., aún cuando se produzcan fallas de energía o del equipo. Plataformas del sistema operativo (Detalle) Microsoft Windows 2000 y NT

23 Funcionalidad y Entorno del Sistema.Casos de Uso Funcionalidad y Entorno del Sistema.

24 Contexto Especificaciones de requerimientosInforme preliminar de investigación Casos de uso: Todos de alto nivel. Algunos esenciales expandidos Prototipos Diagramas de casos de uso Presupuesto, programa Modelo conceptual preliminar Dependencia respecto a Glosario

25 Definición de Casos de UsoLos casos de uso sirven para encontrar y capturar los requerimientos (especialmente los funcionales) Son descripciones narrativas en lenguaje natural de los procesos en un formato estructurado de prosa. Los casos de uso no son propiamente un elemento del análisis y diseño orientado a objetos (pueden ser utilizados en análisis no orientados a objetos). Tienen la gran virtud de mantener la información descrita de forma simple y comprensible por ambas partes Son denominados por un VERBO. Ejemplo: “Comprar producto”.

26 Ejemplo: Jugar BinarioSe tiene un juego de dados llamado “Binario” en que un jugador lanza 2 dados. Si el resultado suma 7 entonces Gana si no Pierde. Jugar Binario: Este caso de uso comienza cuando el jugador recoge y tira 2 dados. Si los puntos suman siete, gana y pierde si suman cualquier otro número.

27 Caso de uso, Ejemplo CortoRecibir pedido en restaurant: Un cliente solicita atención (ya leyó la carta). El garzón llega a la mesa y anota en su PDA el número. El garzón responde consultas sobre el menú. El garzón anota el pedido. El Sistema toma razón del pedido final. Es una prosa descriptiva (en este ejemplo faltó escribir el objetivo)

28 Definición de Actor Actor: Puede ser una Persona (identificada por su rol), otro sistema informático u organización. Ejemplo: Si el software es un video juego, entonces el actor físico seria el niño, joven o adulto que juega el video Juego. Sin embargo, desde el punto de vista del análisis del software el Actor es un Jugador.

29 Metodología: Buscar Actores y sus FuncionesLo primero es reconocer a todos los actores que están involucrados en el sistema. Luego sus funciones básicas, ejemplo PDV: Cajero Registra los productos. Entrega el cambio Cliente Compra productos Paga los productos Gerente Inicia Cierra Administrador del sistema Incorpora nuevos usuarios

30 Definición de EscenarioEscenario: Es una secuencia específica de acciones e interacciones entre los actores y el sistema que se está estudiando. Muchas veces, se les denomina a los escenarios, instancias de casos de uso. Por ejemplo “Comprar producto” suponiendo que no existe el producto. Siempre hay al menos dos escenarios posibles.....

31 Escenarios Básicos Escenario principal (de éxito): El escenario principal, es aquella secuencia de acciones que permite concluir exitosamente con lo que se desea satisfacer en el caso de uso. Escenario de fallo: Es lo que ocurriría en caso de información mal ingresada, tipos de datos incorrectos, fallas en Hardware o Software, entre otras.

32 Ejemplo: Jugar BinarioCaso de uso: Jugar Binario Escenario principal de Éxito: Este caso de uso comienza cuando el jugador recoge y tira 2 dados. Si los puntos suman siete, gana y pierde si suman cualquier otro número. Escenario de fallo: El jugador lanza los dados y al menos un dado no queda en posición totalmente horizontal sobre la superficie de juego, entonces debe tomar ambos dados y lanzarlos En este caso podría definirse que sólo lanzara 1 dado!!!!!

33 Ejemplo 2: PDV Caso de Uso: Gestionar devolucionesEscenario principal de Éxito: Un Cliente llega a una Caja con artículos para devolver. El cajero usa el PDV para registrar cada uno de los artículos devueltos... Escenarios alternativos: Si el cliente pagó con tarjeta de crédito y se rechaza la transacción de reembolso a su cuenta, entonces informar al cliente y pagarle en efectivo. Si el Identificador del articulo no se encuentra en el sistema entonces, notificar al Cajero y sugerir la entrada manual del código de identificación....(que pasa si el código se salio del envase?) Si el sistema detecta fallos con en la comunicación con los sistemas de contabilidad externos

34 Como Detectar Casos de UsoSe debe focalizar la atención en buscar de qué manera el sistema en cuestión logra entregar un resultado observable de valor para el usuario. Tratar de centrarse en la pregunta ¿cómo puedo, utilizando el sistema, proporcionar un valor observable para el usuario, o cumplir sus objetivos?

35 Como Detectar Casos de UsoMuchas veces un caso de uso puede utilizar varias funcionalidades del sistema, ésta es una potencialidad importante que se debe notar Los casos de uso están pensados en los objetivos de los actores y no en las funciones Por tanto las funciones pueden ser ordenadas de manera mas clara tanto para los clientes como para el equipo de desarrollo.

36 Objetivos y Alcances de los Casos de UsoLo típico es no saber si algo es un caso de uso o no. Por lo tanto se tienen distintos niveles de granularidad Desde el nivel más alto, actividades de la empresa Hasta el niveles muy detallados Actividades atómicas es lo que NO se debe usar como CU Ejemplo: “Eliminar el registro de la venta” Mejor: “Procesar la Venta”

37 Casos de Uso y ObjetivosLos usuarios tienen objetivos (son sus necesidades). Por esto lo que se debe tratar de usar es los Casos de uso de Nivel de Usuario Esto nos lleva a encontrar los Objetivos del Usuario Definir un caso de uso para cada uno de estos Objetivos del Usuario Por lo tanto hay un cambio de enfoque: Ya no se pregunta por ¿cuáles son los CU? Se pregunta ¿cuáles son tus objetivos?

38 Ejemplo: La Estrategia de Buscar Objetivos Cada vez mas Generales.Analista: ¿Me podría decir algunos de sus objetivos en el contexto del uso del PDV? Cajero: Iniciar la sesión rápidamente y poder capturar las ventas. A : ¿Cuál es el objetivo más general que persigue usted al iniciar la sesión? C: Intento identificarme en el sistema, de ese modo el sistema puede saber que estoy autorizado para capturar ventas A: Pero, ¿eso para qué? C: Para evitar los robos, la alteración de datos, y para no mostrar información privada de la compañía

39 Objetivos de Sub-FunciónPor ejemplo: Identificarme y ser validado, se ha eliminado, sin embargo son objetivos validos para el usuario Sólo ocasionalmente deben escribirse éstos como casos de uso Típicamente si este objetivo se repite en otros casos de uso. O si varios Actores requieren del mismo. Por lo tanto de acuerdo a esto se puede colocar el caso de uso: Autentificar Usuario

40 Caso de uso Importante CRUD (Create/Retreive/Update/Delete) CrearRecuperar Actualizar Eliminar Defina estos como un solo caso de uso Gestionar XXX Administrar XXX Ejemplo: Gestionar Usuarios, Administrar Pedidos

41 Guía para trabajar con Casos de UsoFijar los limites del sistema: Quizás se facilita esta tarea buscando qué es lo que queda afuera. Identificar a los Actores: ¿Quién inicia, administra, gestiona, evalúa, opera, ejecuta, ... el sistema? Identificar los Objetivos de los Actores: Listar los actores y buscar los procesos de negocios elementales y agrupaciones CRUD. Escribir los casos de Uso: refinarlos continuamente.

42 Definición II de caso de usoInformalmente, un caso de uso es una colección de escenarios: el de éxito y un conjunto de fallo (o de flujo alternativo) relacionados, que describe a los actores utilizando un sistema para satisfacer un objetivo.

43 Casos de Uso de Caja NegraLa idea fundamental es pensar solo en el QUÉ y no en el CÓMO Se debe especificar las responsabilidades que debe tener el sistema, de este modo logramos encontrar todos las funcionalidades del sistema Jugar Binario

44 Ejemplo: Caso de uso Registrar la VentaEstilo de Caja Negra El sistema registra la venta Que es lo que NO se debe colocar El sistema registra la venta en la Base de Datos O peor.... Se genera una sentencia SQL, Insert...

45 Tipos de Formalidad Dependiendo de la necesidad que se tenga, los casos de uso se escriben en diferentes formatos: Breve: resumen conciso, tratando de que sea un párrafo, por lo general solamente el escenario general de éxito Informal: Formato de párrafo en estilo informal, múltiples párrafos y pueden contener varios escenarios Completo: Se detalla por completo todos los pasos y variaciones.

46 Formatos oficiales “usecases.org” Ahí se encuentran varios formatos disponibles para descargar y utilizar Desde los más simples a los más completos.

47 Plantilla Casos de Uso Caso de uso: Nombre del Caso de UsoActor Principal: Personal Involucrado e intereses: Precondiciones: Garantías de éxito (Poscondiciones): Escenario principal de Éxito (Flujo básico): Extensiones (o Flujos Alternativos) Requisitos especiales: Lista de tecnología y variaciones de datos: Frecuencia:   Temas pendientes:

48 Ejemplo de plantilla estilo completoCaso de uso: Procesar venta Actor Principal: Cajero Personal Involucrado e intereses: Cajero: quiere entradas precisas, rápidas y sin errores de pago, ya que las pérdidas se deducen de su salario Vendedor: quiere que las comisiones de las ventas estén actualizadas Compañía: quiere registrar la transacción con precisión y satisfacer los intereses de los clientes.... Servicio de Impuestos Internos: quiere recopilar los impuestos de cada venta...

49 Precondiciones Es lo que debe cumplirse siempre antes de comenzar cualquier escenario de un caso de uso. Las precondiciones NO SE CHEQUEAN dentro del caso de uso, si no que se ASUMEN verdaderas. Una precondición, por lo general implica que se concluyo exitosamente un escenario dentro de otro caso de uso. No es necesario colocar precondiciones obvias como: “El sistema debe tener electricidad”.

50 Poscondiciones o Garantías de ÉxitoEstablecen qué es lo que debe cumplirse cuando se termina el escenario principal o bien algún escenario. Debe satisfacer las necesidades de todos los involucrados.

51 Escenario principal de éxito“El camino Feliz”  Es la secuencia de acciones que debería cumplirse normalmente si todo sale bien Note que no lleva ninguna bifurcación condicional Todo el manejo de pasos alternativos se dejará para la definición de escenarios El tipo de interacciones que se recogen son Interacción entre actores Validaciones (Normalmente a cargo del sistema) Un cambio de estado realizado por el sistema (Ej. Registrar o modificar algún dato) Sin embargo el primer paso es la ACCIÓN que desencadena el Caso de Uso

52 Extensión o Flujos alternativosIndican todos los posibles escenarios o bifurcaciones condicionales que pueden ocurrir en el sistema Una extensión tiene 2 partes: Una condición Es algo que puede ser detectado por el sistema o un actor El manejo de la condición Este se puede anotar como una secuencia de pasos o solo resumirlo en un paso

53 Extensión o Flujos alternativos Cont..Al final del manejo de la extensión, se vuelve al flujo principal a menos que se indique lo contrario en el manejo. Ej. 1a. Se detecta un usuario no valido 1. El sistema despliega un mensaje de error 2. Se emite una alarma sonora 3. El sistema se bloquea A veces un escenario es muy complejo, en este caso hay que decidir si se anota como un caso de uso aparte. Ej. Por ejemplo en el caso del PDV el pago con tarjeta de crédito

54 Requisitos especialesCuando se tienen requisitos que no son funcionales pero que afectan fuertemente al caso de uso, entonces se recogen en el mismo caso de uso. Por ejemplo: Rendimiento, fiabilidad, facilidad de uso y otras restricciones de diseño (hardware necesario, etc.)

55 Lista de Tecnología y Variaciones de datosMuchas veces hay muchas maneras de hacer algo, el CÓMO. Sin embargo el qué esta dado. Aquí se colocan entonces las restricciones sobre el cómo se debe realizar un paso (Hardware) O diferentes formatos o variables que se pueden recoger dentro de algún paso del escenario.

56 Otra Plantilla de Casos de UsoCaso de uso: Nombre del caso de uso Actores: Lista de actores (agentes externos), en la cual se indica quién inicia el caso de uso Propósito: Intención del caso de uso Resumen: Repetición del caso de uso de alto nivel o alguna síntesis similar. Tipo: Primario, secundario u opcional. Esencial o real. Referencias cruzadas: Casos relacionados de uso y funciones también relacionadas del sistema. Descripción: Explicación del caso de uso.

57 Ejemplo de Caso de Uso de Alto NivelCaso de uso: Comprar productos Actores: Cliente, cajero Tipo: Primario Descripción: Un Cliente llega a la caja registradora con los artículos que va a comprar. El Cajero registra los artículos y cobra el importe. Al terminar la operación, el Cliente se marcha con los productos.

58 Ejemplo de caso de Uso BreveCaso de uso: Comprar productos en efectivo Actores: Cliente (iniciador), Cajero Propósito: Capturar una venta y su pago en efectivo. Resumen: Un Cliente llega a la caja registradora con artículos que desea comprar. El Cajero registra los productos y recibe un pago en efectivo. Al terminar la operación, el Cliente se marcha con los productos comprados. Tipo: Primario y esencial. Referencias cruzadas: Funciones: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1. Descripción: Un Cliente llega a la caja registradora con los artículos que va a comprar. El Cajero registra los artículos y cobra el importe. Al terminar la operación, el Cliente se marcha con los productos.

59 Diagrama de CU básico Jugar Binario

60 Ejemplo: Diagrama de Casos de Uso

61 Más sobre Actores Se pueden definir categorías generales de actores (como cliente en el ejemplo de abajo) y especializarlos (como ClienteComercial) a través de relaciones de generalización.

62 Ejemplo: generalización Actores

63 Organización de casos de usoLos casos de uso pueden organizarse agrupándolos en paquetes. También se pueden especificar relaciones de generalización, inclusión y extensión. Generalización significa que el caso de uso hijo hereda el comportamiento y el significado del caso de uso padre, donde el hijo puede agregar o redefinir el comportamiento del padre. La generalización entre casos de uso se representa como una línea continua con una punta de flecha vacía.

64 Ejemplo:

65 Organización de casos de uso (2)Una relación de inclusión entre dos casos de uso significa que un caso de uso base incorpora explícitamente el comportamiento de otro caso de uso en el lugar especificado en el caso base. Aquí el caso de uso base toma el comportamiento del caso de uso proveedor. Esta relación se usa para evitar describir el mismo flujo de eventos repetidas veces, poniendo el comportamiento común en un caso de uso aparte (que será incluido por un caso base). Una relación de inclusión se representa como una dependencia, usando la palabra include. Para especificar la posición en un flujo de eventos, se usa la palabra include seguido del caso de uso que se quiere incluir

66 Ej. Include Por ejemplo, para describir el flujo de Seguir pedido:Flujo de eventos principal: Obtener y verificar el número de pedido. include (validar usuario). Examinar el estado de cada parte del pedido y preparar un informe para el usuario.

67 Organización de casos de uso (3)Una relación de extensión entre casos de uso significa que un caso de uso base incorpora implícitamente el comportamiento de otro caso de uso en el lugar especificado indirectamente por el caso de uso que extiende al base. Un caso de uso puede extenderse solamente en ciertos puntos, llamados puntos de extensión. La extensión se puede ver como que el caso de uso que extiende, incorpora su comportamiento en el caso de uso base. Se representa como una dependencia con la palabra extend. Los puntos de extensión sólo son etiquetas que pueden aparecer en el flujo del caso de uso base.

68 Ej. Extend Por ejemplo, el flujo de Hacer pedido Urgente podría escribirse así: Flujo de eventos principal: include (Validar usuario). Recoger los ítemes del pedido del usuario. (establecer prioridad). Enviar el pedido para ser procesado. Una relación de extensión se usa para modelar la parte de un caso de uso que el usuario puede ver como comportamiento opcional del sistema. De esta forma se separa el comportamiento opcional del obligatorio. Es decir, un caso de uso base puede, bajo ciertas condiciones, incorporar el comportamiento de otro caso de uso en el lugar especificado.

69 Otro Ejemplo usando PDVPagar Artículos Extend Pago A Crédito Procesar Venta include

70 Ejemplo: Sistema de ventas.Un sistema de ventas debe interactuar con clientes, los cuales efectúan pedidos. Además los clientes pueden hacer un seguimiento de sus propios pedidos. El sistema envía los pedidos y las facturas a los clientes. En algunos casos, según la urgencia de los clientes, se puede adelantar parte del pedido (pedidos parciales).

71 Ejemplo: Sistema de ventas. (Cont.)

72 Ejemplo 2:Validación de tarjetas de crédito

73 Ejemplo 2:Validación de tarjetas de créditoLa figura muestra el contexto de un sistema de validación de tarjetas de crédito. Se puede ver que existen dos categorías de clientes: clientes individuales, clientes corporativos Ojo, hay un error en la notación UML de la figura, cuál es? Estos actores representan los roles que juegan las personas que interactúan con el sistema También hay actores que representan otras instituciones, como Comercio, con el cual el cliente realiza una transacción para comprar un artículo o servicio, y Entidad financiera, que por lo general es una entidad bancaria donde el usuario tiene la tarjeta de crédito.

74 Ejemplo: Conducción de un auto

75 Escenarios: Repaso. Un escenario es una serie de pasos que muestran la interacción entre el Actor y el Sistema al ejecutar un Caso de Uso. Llamado también instancia de un caso de uso. Existen escenarios Básicos y Alternativos: Básico: el caso de uso es utilizado bajo condiciones normales. Alternativo: el caso de uso es ejecutado bajo condiciones “anormales”

76 Ejemplo Caso de uso y su Escenario BásicoCaso de Uso: Acelerar Actor: Conductor Descripción del caso de uso: Este caso de uso permite al Conductor aumentar la velocidad a la que se desplaza el Vehículo. Precondición: El Vehículo debe poseer combustible. 1. El Conductor solicita aumentar la velocidad del Vehículo 2. El Vehículo aumenta la velocidad según lo especificado por el Conductor 3. El Vehículo invoca al caso de uso “Cambiar de marcha” 4. El Vehículo presenta al Conductor la velocidad a la que se encuentra actualmente

77 Ejemplo Escenario BásicoCaso de Uso: Crear Cliente Actor: Administrador 1. El Administrador solicita crear un Cliente 2. El Sistema presenta los elementos necesarios para el ingreso de los datos 3. El Administrador ingresa los datos (RUT, nombres, etc.) y solicita guardar dichos datos 4. El Sistema verifica que estén todos los datos obligatorios 5. El Sistema verifica que el Cliente no exista (por su RUT) 6. El Sistema crea un nuevo Cliente

78 Ejemplo Escenario Alternativo(1)Caso de Uso: Crear Cliente Actor: Administrador Escenario Alternativo: “Faltan datos obligatorios” 1. En el punto 4. de “Crear Cliente” el Sistema verifica que faltan algunos datos obligatorios 2. El Sistema envía un mensaje al Administrador indicando que faltan datos 3. El caso de uso continúa normalmente en el punto 3

79 Ejemplo Escenario Alternativo(2)Caso de Uso: Crear Cliente Actor: Administrador Escenario Alternativo: “Cliente ya existe” 1. En el punto 6. de “Crear Cliente” el Sistema verifica que el Cliente ya existe 2. El Sistema envía un mensaje al Administrador indicando que el Cliente ya existe 3. El caso de uso termina aquí

80 Definición de un modelo conceptualUn modelo conceptual muestra gráficamente, a través de un grupo de diagramas, los conceptos (clases de objetos), los atributos y las asociaciones más importantes del dominio.

81 Diagrama de CU básico Jugar Binario

82 Ejemplo: Juego Binario

83 Fase de Analisis Documento de Requerimientos Casos de UsoDocumento de Casos de Uso Diagramas de casos de Uso Diagrama de Secuencia de Sistema (DSS) Modelo de Dominio (o Modelo Conceptual) Contratos de Operaciones

84 Diagramas de Secuencia de Sistema (DSS)Fuente: “UML y PATRONES”, Craig Larman, 1Ed y 2 Ed.

85 ¿Qué es un DSS? Es un tipo de diagrama propuesto por Craig Larman.Muestra, por un lado, los actores y por otro, el sistema y sus interacciones. Se utiliza UML para los diagramas

86 Objetivos de un DSS Se pretende encontrar todas las interacciones entre los Actores y el Sistema en cuestión A nivel de análisis, la idea es abordar los escenarios esenciales de éxito para poder aclarar varios puntos del sistema: Complejidad Tamaño Coordinaciones, entre otras

87 Estilo de Caja Negra al modelarPara poder cumplir el objetivo anterior y dado que aún no hemos diseñado nada, lo que conviene es utilizar el enfoque de Caja Negra. Nos enfocamos en “qué” hace el sistema y no en “cómo” lo hace.

88 DSS se construyen lentamenteClaramente en la fase de análisis, puede que aun nos falten: Actores Casos de Uso Escenarios Entre otros… por eso debe focalizarse en el escenario principal de cada caso de uso.

89 Los DSS ayudan a mejorar los CUPara construir un DSS se utiliza la información que está contenida en los Casos de Uso (CU). Muchas veces al estudiar las interacciones entre los actores y el sistema surgen nuevas dudas o ideas para mejorar la propuesta de sistema. De este modo se mejoran cíclicamente los casos de uso y los DSS

90 Una Definición más Formal de DSSUn DSS es un dibujo que muestra los eventos (o mensajes) que generan los actores externos, el orden y los eventos (o mensajes) entre otros sistemas. Los DSS se realizan para un escenario específico! Para cada caso de uso se tendrá un conjunto de DSS. Nota: En un CU podemos ver cómo interactúan los actores externos con el sistema para obtener un resultado de valor observable, por lo tanto es evidente la relación entre esta manera de tomar requerimientos y los DSS.

91 Ejemplo para Jugar BinarioCaso de uso: Jugar Binario Actores: Jugador Escenario principal de Éxito: Este caso de uso comienza cuando el jugador recoge y tira 2 dados. Si los puntos suman siete, gana y pierde si suman cualquier otro número. Escenario de fallo: A. En cualquier momento el sistema falla en este caso, se debe. 1. Permitir reiniciar el juego, (volver al paso 1)

92 DSS para caso de uso “Jugar Binario”Escenario Principal de Éxito. :Sistema Inicio Secuencia :Jugador LanzarDados() resultado

93 Ciclos en los Eventos Muchas veces hay un conjunto de eventos que se desea repetir, hasta que una cierta condición se cumpla Para representar esta situación, se utiliza un rectángulo sobre las acciones a repetir y un paréntesis cuadrado, especificando la condición

94 Ejemplo para Jugar Binario ModificadoCaso de uso: Jugar Binario Actores: Jugador Escenario principal de Éxito: Este caso de uso comienza cuando el jugador recoge y tira 2 dados. El sistema despliega el resultado, Si los puntos suman siete, gana y pierde si suman cualquier otro número. Se repiten los pasos 1 y 2 hasta que el usuario lo desee y si ha ganado Se finaliza el juego Escenario de fallo: A. En cualquier momento el sistema falla en este caso, se debe. 1. Permitir reiniciar el juego, (volver al paso 1)

95 DSS para C.U. modificado “Jugar Binario”Escenario Principal de Éxito. :Sistema :Jugador lanzarDados() resultado *[Suman Siete Y Usuario desea seguir] terminarJuego()

96 EJ2: Ingreso simple a un sistemaCaso de uso: Validar usuarios Actores: Profesor, Alumno, Auxiliares… Escenario principal de Éxito: Este caso de uso comienza cuando un usuario llega a la pagina inicial de U-Cursos Ahí el usuario debe ingresar su Rut, Dv y clave de SID El sistema verifica los datos en SID Entrega una sesión valida Escenario de fallo: 3.A El usuario ingresa su rut, Dv o Clave erroneamente 1. Se genera un mensaje de error 2. Se vuelve al paso 1

97 DSS para CU: Validar Usuario V1.0Escenario: Modelamos el escenario 3a. :U-CURSOS :Usuario ValidarUsuarios(Rut,Dv,Clave) Estado Validación *[Usuario invalido] Aquí falta algo aún .... qué es??

98 DSS para CU: Validar Usuario V1.0.1Escenario: Modelamos el escenario 3a. :U-CURSOS :SID :Usuario ValidarUsuarios(Rut,Dv,Clave) AutentificarUsuarioEnSiID(Rut,Dv,Clave) Estado Validación *[Usuario invalido] Ojo, tambien esta mal colocar un Mensaje que tenga un nombre de muy bajo nivel: Query(Rut,Dv,Clave) Los actores si son sistemas pueden ser modelados como persona, o como caja :SID

99 EJ2: Ingreso Simple a un SistemaCaso de uso: Validar usuarios Version: 1.0.1 Actores: Profesor, Alumno, Auxiliares, SID … (secretarias docentes, director de la escuela, visitantes.. Etc) Escenario principal de Éxito: Este caso de uso comienza cuando un usuario llega a la pagina inicial de U-Cursos Ahí el usuario debe ingresar su Rut, Dv y clave de SID El sistema verifica los datos en SID Entrega una sesión valida Escenario de fallo: 3.A El usuario ingresa su rut, Dv o Clave erroneamente 1. Se genera un mensaje de error 2. Se vuelve al paso 1

100 Eventos y Límites del SistemaEstos diagramas deben representar todos los eventos entre los actores y el sistema. Para esto es muy importante tener claros cuales son los límites del sistema. Usualmente como límite el sistema y el hardware, si es que es el caso. La mala elección del límite puede llevarnos a no considerar algunos eventos o a tomar en cuenta mas de los que son necesarios. Para evitar esto debemos identificar muy bien a los actores externos. Estos son los que interactúan directamente con el sistema enviando eventos a este.

101 ¿Qué hemos aprendido en el ejemplo anterior ??El análisis en es fundamental !!! De este modo descubrimos un actor adicional (SID) y podemos encontrar muchos otros Así podemos representar todos los mensajes entre los distintos tipos de actores que están involucrados El análisis es fundamental !!! 

102 Otro ejemplo de Límites de sistemaCaso de uso: Procesar venta Actor Principal: Cajero Personal Involucrado e intereses: Cajero: quiere entradas precisas, rápidas y sin errores de pago, ya que las perdidas se deducen de su salario Vendedor: quiere que las comisiones de las ventas estén actualizadas Compañía: quiere registrar la transacción con precisión y satisfacer los intereses de los clientes.... Servicio de Impuestos Internos: quiere recopilar los impuestos de cada venta...

103 Ejemplo: Limites de sistema (cont)Escenario principal de Éxito (Flujo básico): 1.El cliente llega a un terminal de PDV con artículos y/o servicios que desea comprar 2.El cajero inicia una nueva venta 3.El cajero introduce el identificador del artículo 4.El sistema registra la línea de la venta y presenta la descripción del articulo, precio y suma parcial. El precio se calcula de acuerdo a un conjunto de reglas de precios nEl cajero repite los pasos 3 y 4 hasta que se indique 5.El sistema presenta el total calculado 6.El cajero le dice al cliente el total de la venta y le pide que le page 7.El cliente paga y el sistema gestiona el pago 8.El sistema registra la venta completa y envía información de la venta y del pago al sistema de contabilidad externo (Para la contabilidad y las comisiones) y al sistema de inventario (Para actualizar el inventario) 9.El sistema imprime el recibo 10.El cliente se va con el recibo y los artículos (si es el caso)

104 DSS de Procesar Venta Escenario principal de Éxito crearNuevaVenta():Sistema :Cajero crearNuevaVenta() Aquí obviamente faltan actores. Trate de corregir este diagrama. No esta mal, pero claramente se debe mejorar el Caso de Uso y mejorar el DSS correspondiente introducirArticulo(ArtID,cantidad) descripción, total *[más articulos] finalizarVenta() total con impuestos realizarPago() Cambio entregado, recibo

105 Como asignar nombres a los eventos y operacionesLos nombres de los eventos (o mensajes) y sus operaciones asociadas, deben estar nombradas de acuerdo con las motivaciones que dan lugar a ellas Por lo general un verbo introducirArticulo, cambiarNombre, realizarPago... Tienen que ver con el mundo de las personas no de las maquinas !!! Trate de no usar!! Nombres que estén relacionados con los medios de entrada físicos (escanear) Nombres de funciones de software (query, consulta, select, update.. Etc) O con la Interfaz de Usuario (ej. CheckBox, TextArea) Sus clientes se lo agradeceran !! Y no compromete el Diseño!!

106 Ejemplo: ¿Cuál es el Error?Escenario principal de Exito :Sistema :Cajero crearNuevaVenta() Escanear, es un nombre que Esta ligado al hardware con el que se esta pensando realizar esa labor. Se pierde Generalidad Se limita el diseño en una fase que no corresponde IntroducirArticulo, deja ver cual Es la intención del cajero escanearArticulo(ArtID,cantidad) descripción, total *[más articulos] finalizarVenta() total con impuestos realizarPago() Cambio entregado, recibo

107 Observación/Consejo prácticoMuchas veces es muy bueno, colocar el texto del escenario de éxito junto al diagrama para facilitar la lectura.

108 Ejemplo: Escenario principal de Exito crearNuevaVenta():Sistema Escenario principal de Éxito (Flujo básico): 1.El cliente llega a un terminal de PDV con artículos y/o servicios que desea comprar 2.El cajero inicia una nueva vena 3.El cajero introduce el identificador del artículo 4.El sistema registra la línea de la venta y presenta la descripción del articulo, precio y suma parcial. El precio se calcula de acuerdo a un conjunto de reglas de precios nEl cajero repite los pasos 3 y 4 hasta que se indique :Cajero crearNuevaVenta() escanearArticulo(ArtID,cantidad) descripción, total *[más articulos] finalizarVenta() total con impuestos realizarPago() Cambio entregado, recibo

109 Contexto Especificaciones de requerimientosInforme preliminar de investigación Casos de uso: Todos de alto nivel. Algunos esenciales expandidos Prototipos Diagramas de casos de uso Presupuesto, programa Modelo conceptual preliminar Dependencia respecto a Glosario

110 DSS y los Glosarios Por lo general los eventos, operaciones, parámetros y valores de retorno en un DSS son concisos. Por lo que podría requerirse de una explicación más detallada Para esto utilizamos el Glosario Sin embargo, esto debería haber quedado ya definido y explicado en los casos de uso. Si no, podrían agregarse a un Glosario. Sin embargo, piense si será de real utilidad hacer el glosario, pues a veces puede ser trabajo desperdiciado.

111 Modelo del Dominio Fuente: “UML y PATRONES”, Craig Larman, 1Ed y 2 Ed.

112 Contexto Especificaciones de requerimientosInforme preliminar de investigación Casos de uso: Todos de alto nivel. Algunos esenciales expandidos Prototipos Diagramas de casos de uso Presupuesto, programa Modelo conceptual preliminar Dependencia respecto a Glosario

113 ¿Que es el Modelo de Dominio?Este es un modelo muy simple pero importante. Tiene por objetivo mostrar a los modeladores las clases conceptuales significativas en el dominio de un problema. Es el diagrama más importante creado durante el AOO. Ojo, Casos de Uso, corresponden al análisis de requisitos y nos son OO. Sin embargo ponen de relieve el punto de vista de del proceso de dominio

114 Modelo del Dominio Lo que se buscan son las clases de conceptos del mundo real dentro del dominio del problema que es importante tener presente. No muestra componentes de software No muestra clases de software Ni objetos de software Mucho menos Hardware

115 Modelo del Dominio (Cont)Se utiliza notación UML para poder representarlo. Se diagrama como un diagrama de clases, pero sin ninguna operación. Pueden mostar: Clases conceptuales u objetos del dominio Asociaciones entre estas clases conceptuales Atributos de las clases conceptuales

116 Ejemplo: Para las ventas del PDVConcepto u Objeto del dominio LineaDeVenta Articulo Registra-venta-de cantidad 0..1 1 1..* 1..* Contenida-en Almacenado-en 1 1 Venta Tienda Asociaciones 1 Fecha Hora Direccion Nombre 1 1 Pagado-mediante contiene 1 1..* Pago Registro 1 Atributos cantidad Capturada-en

117 Observaciones importanteEl modelo de dominio no es un modelo de componentes de software. Representa cosas del mundo real, por lo que debe evitar componentes u objetos de software.

118 Ejemplo: ¿qué debe evitar?BaseDeDatos Artefacto de Software; no forma parte del modelo de dominio Venta Clase de software; no forma parte del modelo de dominio. Fecha Hora imprimirFecha() imprimirHora() Metodos o funciones

119 Descomposición del DominioExisten varias formas de descomponer el dominio de un problema, para reducir su complejidad. Descomposición funcional, donde el problema se descompone por funciones o procesos Análisis y diseño orientado a objetos, el foco esta en decomponer por COSAS o ENTIDADES, del dominio del problema Por lo tanto, lo más importante es lograr identificar todos los conceptos y documentaros en un diagrama de dominio.

120 Ejemplo: Dominio de VentasPara las ventas de una tienda del mundo real, existen varias clases conceptuales o conceptos Tienda Registro Pago Venta Cajero Articulo..... Etc..

121 Identificando clases conceptualesSe deben identificar las clases conceptuales por escenario de los Casos de Uso Hay varias estrategias para lograrlo: Utilización de listas de Categorías de clases conceptuales Identificación de frases nominales Utilización de patrones de análisis

122 Lista de categoría de clases conceptualesCategoría de clase conceptual Ejemplos Objetos tangibles o físicos Registro, Avión Especificaciones, diseños o descripciones de las cosas EspecificacionDelProducto, DescripcionDelVuela Lugares Tienda, Oficina, Bodega Transacciones Venta, Pago, Reserva Líneas de Transacción LineaDeVenta Roles de la gente Cajero, Piloto, Conductor Contenedores de otras cosas Tienda, Lata, Avión, estante Cosas en un contenedor Articulo, Pasajero, libro Otros sistemas informáticos o eléctricos externos SistemaAutorizacionPagoCredito, SII, ControlDeTraficoAereo Conceptos abstractos Ansia, Acrofobia Organizaciones DepartamentoDeVentas, CompañiaAerea Hechos Venta, Pago, Reunión, vuelo, colisión, aterrizaje Procesos (normalmente no se presentan como conceptos) VentaDeProductos, ReservaDeAsiento Reglas y políticas PoliticaDeReingreso, PoliticaDeCobranza Catálogos CatalogoDeProductos, CatalogoDePiezas Registros de Finanzas, trabajo, contratos, cuestioneslegales LineaDeCrédito, Stock Manuales, documentos, artículos de referencia, libros ListaDeCambiosDePreciosDiarios, ManualeReparaciones

123 Frases nominales La idea fundamental es tratar de identificar, mediante el análisis lingüístico, nombres y frases nominales, en las descripciones textuales de un dominio. Y considerarlas clases conceptuales Frase nominal, es aquella que no tiene verbo Problemas: No se puede realizar una correspondencia mecánica entre estas frases y los nombres de las clases Muchas veces las frases son ambiguas

124 Ejemplo: PDV Escenario principal de Éxito (Flujo básico):1.El cliente llega a un terminal de PDV con artículos y/o servicios que desea comprar 2.El cajero inicia una nueva venta 3.El cajero introduce el identificador del artículo 4.El sistema registra la línea de la venta y presenta la descripción del articulo, precio y suma parcial. El precio se calcula de acuerdo a un conjunto de reglas de precios nEl cajero repite los pasos 3 y 4 hasta que se indique 5.El sistema presenta el total calculado 6.El cajero le dice al cliente el total de la venta y le pide que le page 7.El cliente paga y el sistema gestiona el pago 8.El sistema registra la venta completa y envía información de la venta y del pago al sistema de contabilidad externo (Para la contabilidad y las comisiones) y al sistema de inventario (Para actualizar el inventario) 9.El sistema imprime el recibo 10.El cliente se va con el recibo y los artículos (si es el caso)

125 Patrones de Análisis Son modelos de Dominio parciales y que han sido desarrollados por expertos. Hay varios libros publicados: Analysis Patterns Data Model Patterns

126 Clases conceptuales candidatasDespués de aplicar alguno de los métodos anteriores, es posible generar una lista con clases conceptuales candidatas Para el dominio de Ventas Registro Articulo Tienda Venta Pago CatalogoDeProductos EspecificacionDelProducto LineaDeVenta Cajero Cliente Encargado

127 Un detalle importante Y que paso con el recibo??, no esta en el modelo! Un recibo es un informe de venta, y toda la información que contiene esta contenida en otras fuentes. Por lo tanto al incluirlo estaríamos duplicando información Sin embargo, el recibo le da al portador la facultad de poder devolver los artículos, por lo tanto, al momento de modelar el caso de uso “Gestionar Devoluciones” lo colocaremos justificadamente

128 Como Nombrar y Modelar mejorEstrategia del Cartógrafo Haga el modelo del dominio con el espíritu de trabajo de los cartógrafos Utilice los nombres existentes en el Territorio (dominio) Excluya las características irrelevantes. (El cartógrafo no coloca la población o la topografía.... No coloque conceptos que no son relevantes) No añada cosas que no están ahí

129 Típico Error Es cuando representamos algo como un atributo cuando en verdad debería ser un concepto Para evitar esto hay una sencilla regla Si hay una clase conceptual X, que no se considera Numero o Texto, entonces probablemente es una clase conceptual y no un atributo

130 Ejemplo MAL BIEN Venta Tienda Venta Tienda NumeroTelefonico En el mundo real una tienda no es considerado ni un texto ni un número Vuelo Destino Vuelo Destino nombre En el mundo real un Aeropuerto de Destino no es considerado ni texto ni número En caso de duda, considérelo un concepto separado, pues los atributos no deberían abundar en el diagrama de conceptos

131 Clases conceptuales similares.En algunas ocasiones nos encontramos con 2 clases conceptuales que desempeñan la misma función pero con nombre distinto. Por ejemplo: En este caso lo que normalmente se hace es utilizar el nombre del sistema. En este caso se considera, al sistema, mas bien como una entidad abstracta que registra, lee, etc. Registro TPDV 1 1 registra registra 1..* 1..* Venta Venta Fecha Hora Fecha Hora

132 Modelos del mundo IrrealAlgunos dominios de sistemas, poseen dominios muy abstractos. Que tienen muy poca analogía con dominios naturales o de negocios. Por ejemplo algunos sistemas de telecomunicaciones poseen como clases conceptuales Mensaje, Conexión, Puerto, Dialogo, Ruta, Protocolo, entre otros

133 Clases conceptuales de Especificación o descripciónSuponga lo siguiente: Una instancia de un Articulo representa una instancia física dentro de la tienda, y por lo mismo cada articulo podría tener un numero de serie Un Articulo tiene un precio, descripción e identificador del articulo que no se recogen en otro sitio. Todos en la tienda sufren de amnesia Cada vez que se vende un articulo físico real, se elimina una instancia de Articulo

134 Clases conceptuales de Especificación o descripción (cont)Entonces bajo estos supuestos si el Articulo fuera lápiz de pasta. Y la tienda vende todos los lápices de pasta. No queda ningún “Lapiz de pasta” en la memoria del Computador ¿cuánto cuestan los lapices de pasta?......nadie puede responder!!! El precio estaba en las instancias del lapiz de pasta. Por lo tanto se requieren Clases que Describan o Especifiquen a otras clases conceptuales.

135 Ejemplo: Clases de EspecificaciónEspecificacionDeProducto Articulo Descripcion Precio numeroSerie articuloID Descripcion Precio articuloID 1 Describe * Articulo numeroSerie

136 Cuando agregar clases conceptuales de EspecificaciónSe necesita de la descripción o especificación de un articulo o producto independiente de la existencia de un articulo en particular La eliminación de instancias de las cosas que se describen (Articulo) dan como resultado una perdida de información que necesita mantenerse. Desee reducir información redundante o duplicada.

137 Ejemplo: Peor Mejor Vuelo Aeropuerto Vuelo DescripcionDelVueloFecha Numero hora vuela-a nombre Peor 1 * Vuelo DescripcionDelVuelo Fecha hora Descrito-por numero Mejor 1 * * Describe-vuelos-a 1 Aeropuerto nombre

138 Asociaciones y NotaciónUna Asociación es una relación entre tipos (o más concretamente, son instancias de estos tipos) Se representan por una línea, puede tener dirección y cardinalidad Vuelo DescripcionDelVuelo Fecha hora Descrito-por > numero 1 * * Describe-vuelos-a 1 Aeropuerto nombre

139 ¿cuándo colocar una relación?Considere las siguientes: Asociaciones de las que es necesario conservar el conocimiento de la relación durante algun tiempo. Por ejemplo, la asociación entre LineaDeVenta y Venta es necesaria, sin ella no se podría reconstruir la venta. Asociaciones derivadas de la ListaDeAsociaciones

140 Lista de Asociaciones ComunesCategoría Ejemplos A es una parte física de B Cajón – Registro, Ala – avión A es parte lógica de B LineaDeVenta – Venta, RutaVuelo - Vuelo A esta contenido físicamente en B Registro – Tienda , Artículo – Estantería A esta contenido lógicamente en B DescripciónDelArticulo – Catálogo A es una descripción de B DescripcionDeArticulo – Articulo A es una línea de transacción o un informe de B TrabajoMantenimiento - RegistroDeMantenimiento A se conoce/registra/recoge/informa/captura en B Venta - RegistroVenta, Reserva - ListaDePasajeros A es miembro de B Cajero – Tienda, Articulos - Bodega A es sub-unidad organizativa de B Departamento – Tienda, Mantenimiento – CODELCO A utiliza o gestiona B Cajero – RegistroVenta, Piloto – Avión A se comunica con B Cliente – Cajero , AgenteDeReservas – Pasajero A esta relacionado con una transacción B Cliente – Pago, Pasajero – Pasaje A es una transacción relacionada con otra transacción B Pago – Venta, Reserva – Cancelación A está al lado de B Ciudad – Ciudad A es propiedad de B RegistroDeVenta – Tienda, Avión - CompañiaAerea A es un evento relacionado con B Venta – Cliente, Venta – Tienda

141 Asociaciones de alta prioridadSon asociaciones que es invariantemente útiles incluirlas en el modelo del dominio. A es una parte lógica o física de B A esta contenida física o lógicamente en B A se registra en B

142 Guia para las asociacionesCentrese en las asociaciones para las que se necesita conservar el conocimiento de la relación durante algún tiempo Es más importante identificar clases conceptuales que asociaciones Demasiadas asociaciones tienden a confundir un modelo de dominio Evite mostrar relaciones redundante o derivadas

143 Roles de las AsociacionesPor lo genear se respeta el formato: NombreTipo – FraseVerbal – NombreTipo Se leen tipicamente de derecha a izquierda Pueden tener direccionalidad CompañiaAerea 1 Emplea 1..* Persona Asignado-a Vuelo * 1 Avion 1 * < Asignado-a 1 * Supervisa

144 Multiples Asociaciones entre 2 TiposAveces pueden existir mas de una relación entre 2 clases conceptuales. Cuando es necesario anotarlas. Cuando la naturaleza de las relaciones sea distinta Cuando valga la pena hacer la distinción * Vuela-a 1 Vuelo Aeropuerto Vuela-desde 1 *

145 Asociaciones e ImplementaciónLas asociaciones en el modelo de dominio son solo semanticas no es una declaración del flujo de los datos, conecciones entre objetos o instancias de clases. Solo es una declaración de que aquella relación es importante en el mundo real. Sin embargo, muchas de ellas seran implementadas posteriormente.

146 Los Atributos Los atributos, son datos relevantes que es importante tener presentes con respecto a una clase conceptual Estos deberían ser simples o de tipo de datos Boolean, Fechas, Horas, Números, Textos Ejemplos: Dirección, Color, Teléfono, UPC (Universal Product Code)

147 ¿Qué sucede con los atributos en el código?La restricción de que los datos sean simples, no implica que los atributos en C++ o Java, solo deban ser de datos primitivos o simples. Es más, durante la fase de diseño, muchas de las Asociaciones del modelo del dominio, se implementarán como atributos que referencian a otros objetos de software complejos.

148 No a las Llaves ForaneasOjo, este es un modelo del dominio, se están registrando en el modelo las clases conceptuales Por lo tanto no debe NUNCA relacionar una clase via un atributo de otra clase conceptual Nuevamente….Esto no es una Base de Datos!!!!

149 Modelado de CantidadesLas cantidades numéricas en general no son solo números, si no que también tienen asociadas una unidad Velocidad, Precio, Cantidad de Material Por lo tanto muchas veces es bueno modelar algunas de estas cantidades como Clase Conceptual no como un atributo.

150 Ejemplo Pago Pago Cantidad Unidad Pago Pago Esta situación no es muyBuena debido a que el pago Tiene asociada una unidad Cantidad: Numero Pago Cantidad Unidad Tiene-Cantidad Tiene-en Cantidad: Numero nombre * 1 * 1 Pago El campo cantidad ahora hace referencia a un Dato de tipo Cantidad por lo tanto conceptualmente esta mejor. Cantidad: Cantidad Pago Esta es una variación, usando una Especialización de Cantidad. Cantidad: Dinero

151

152 Contratos de Operaciones

153 Introducción Los contratos de operaciones sirven para ayudar a completar y detallar los casos de uso Para lo cual se describe el comportamiento detallado del sistema en función de los cambios de estado de los objetos del modelo de Dominio después de la ejecución de una operación

154 ¿Como se generan los contratos?Se genera un contrato por cada operación del sistema (como caja negra) Se utiliza el los DSS y en base a estos, para cada uno de los mensajes se debe generar una ficha que se denomina contrato.

155 Ej: DSS de Pocesar VentaEscenario principal de Exito :Sistema :Cajero crearNuevaVenta() Los eventos de entrada al sistema, invocan operaciones del sistema. El evento del sistema crearNuevaVenta invoca una operación de sistema denominada crearNuevaVenta y asi suscesivamente. introducirArticulo(ArtID,cantidad) descripción, total *[más articulos] finalizarVenta() El conjunto completo de operaciones del sistema de todos los Casos de Uso define la interfaz Publica del sistema total con impuestos realizarPago() Cambio entregado, recibo

156 Secciones del ContratoOperación: Nombre de la operación y parámetros Referencias Cruzadas: (Opcional) Algún caso de uso que pueda hacer uso de esta operación Precondiciones: Suposiciones relevantes sobre el estado del sistema o de los objetos del Modelo de Dominio, antes de la ejecución de la Operación. Estas condiciones no se comprobaran en la lógica de esta operación, se asumen ciertas, y son supociciones no triviales que deben notarse que se han realizado Postcondiciones: El estado de los objetos del Modelo de Dominio después que se completa la operación. (escriba las postcondiciones en pasado)

157 El escenario y el telón Suponga que el Sistema y sus clases conceptuales se presentan en un escenario Al levantarse el telón usted le toma una foto Luego el telón se baja….. Y se aplica la operación al sistema!!!! Al levantar el telón saca otra foto…. Compare las fotos y exprese como postcondiciones las diferencias que existen en las fotografias. 

158 Postcondiciones Las post condiciones deben hacer claros los siguientes cambios de estado en los objetos del dominio: Creación de instancias Creación o Disolución de asociaciones Cambio en los atributos Recordar que “se quiere reflejar el estado de los objetos del modelo de dominio al termino de la ejecución de una operación!!!”

159 Relación con entre postcondiciones y Modelo de DominioQue relaciones pueden crearse o destruirse? Que instancias pueden de objetos pueden crearse o destruirse? “Las que usted especifico en el Modelo de Dominio, trate de ser consistente”

160 Ejemplo de PostcondcionesOperación: crearLineaDeVenta ………….. Postcondiciones: Se creo una instancia de LineaDeVenta ldv ldv se asocio con la venta actual (nueva asoc) ldv.cantidad paso a ser cantidad (modif. De atrib) ldv se asoció con una EspecificaciónDelProducto, en base a la coincidencia del articuloID (nueva asoc).

161 Ventaja de las postcondicionesNuevamente nos enfocamos en que hace el sistema en vez de en como lo realizará, que es lo que nos importa en esta fase. Además, este análisis soporta el poder llegar al detalle fino. Especificando cual debe ser el resultado de la operación.

162 Actualizaciones al Modelo de DominioAl generar los contratos de Operaciones usualmente puede descubrir nuevas cosas: Registrar nuevas clases conceptuales Atributos o asociaciones Por lo tanto no se limite a la definición inicial del Modelo de Dominio, realice las modificaciones que sean necesarias

163 ¿Cuándo son útiles los Casos de Uso?Se supone que debería ser suficiente solo con los casos de uso Sin embargo, algunas veces las complejidad de algunas operaciones añadirNuevaReserva(), en un sistema de vuelo Por lo tanto puede generar el Contrato para aportar mayor claridad al equipo de desarrollo sobre esta operación

164 ¿Cuándo no son útiles los contratos?Dejan de ser útiles si se hacen contratos para todas las operaciones del sistema Esto implica que el modelo de casos de uso (el documento de CU) es DEFICIENTE y por lo tanto el esfuerzo debería estar centrado en los Casos de Uso A veces puede en lugar de aclarar el modelo de casos de uso lo complica más con información que no aporta valor

165 Guia para la construcción de ContratosIdentifique las operaciones del sistema utilizando el DSS Construya contratos para las operaciones complejas o que no están claras en los casos de uso Para describir las postcondiciones utilice las siguientes categorías Creación y eliminación de instancias Modificación de Atributos Formación y rotura de asociaciones

166 Ejemplo de contrato para el PDVOperación: realizarPago(cantidad: Dinero) Referencias Cruzadas: CU Procesar Venta Precondiciones: Hay una venta en curso Porstondiciones: Se creo una instancia de pago p (creacion de instancias) P.cantidadEntregada paso a ser cantidad (modificación de atributos) P se asoció con la Venta actual (formación de asociaciones) La venta actual se asoció con la Tienda (formación de asociaciones)