Análisis y diseño orientado a objetos Contenido. Análisis y diseño orientado a objetos Muestra. Análisis y diseño orientado a objetos Muestra

Transcripción

1 Análisis y diseño orientado a objetos Contenido Qué es análisis? Qué es diseño? Análisis y diseño OO Uso de UML Introducción al proceso de desarrollo Análisis y diseño orientado a objetos Muestra 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) es un 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. Fundamentos de Ingeniería de SW 73 Fundamentos de Ingeniería de SW 74 Análisis y diseño orientado a objetos Muestra Análisis y diseño orientado a objetos Qué son análisis y diseño? 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. 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. Fundamentos de Ingeniería de SW 75 Fundamentos de Ingeniería de SW 76 Análisis y diseño orientado a objetos Qué son análisis y diseño? Análisis y diseño orientado a objetos Qué son análisis y diseño? 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 Análisis Diseño Construcción Libro titulo public class Libro { public void print(); Private String titulo; } Concepto de Representación Representación en Dominio en el diseño programación Investigación del problema Solución Lógica Código Fundamentos de Ingeniería de SW 77 Fundamentos de Ingeniería de SW 78

2 Análisis y diseño orientado a objetos Ejemplo Análisis y diseño orientado a objetos Ejemplo casos de uso Definición del Modelo conceptual Diagramas de colaboración Diagramas de diseño de clases casos de uso Definición del Modelo conceptual Diagramas de colaboración Diagramas de diseño de clases 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. 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 y pierde si suman cualquier otro numero. Fundamentos de Ingeniería de SW 79 Fundamentos de Ingeniería de SW 80 Análisis y diseño orientado a objetos Ejemplo Análisis y diseño orientado a objetos Ejemplo casos de uso Definición del Modelo conceptual Diagramas de colaboración Diagramas de diseño de clases casos de uso Definición del Modelo conceptual Diagramas de colaboración Diagramas de diseño de clases 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). Por ejemplo, una parte del modelo conceptual muestra los conceptos de Jugador, Dados y Juego de dados, sus asociaciones y atributos. nombre Jugador Juega Lanza 2 Dado valormostrado 2 Juego de dados Incluye Fundamentos de Ingeniería de SW 8 Fundamentos de Ingeniería de SW 82 Análisis y diseño orientado a objetos Ejemplo Análisis y diseño orientado a objetos Ejemplo casos de uso Definición del Modelo conceptual Diagramas de colaboración Diagramas de diseño de clases casos de uso Definición del Modelo conceptual Diagramas de colaboración Diagramas de diseño de clases El modelo conceptual no es una descripción de los componentes de software; representa conceptos en el dominio del problema del mundo real. 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. Fundamentos de Ingeniería de SW 83 Fundamentos de Ingeniería de SW 84 2

3 Análisis y diseño orientado a objetos Ejemplo Análisis y diseño orientado a objetos Ejemplo casos de uso Definición del Modelo conceptual Diagramas de colaboración Diagramas de diseño de clases casos de uso Definición del Modelo conceptual Diagramas de colaboración Diagramas de diseño de clases Por ejemplo, la figura muestra gráficamente el paso esencial del juego, enviando mensajes a las instancias de las clases Jugador y Dado. jugar() :Jugador :r:= lanzar() 2:r2:= lanzar() d:dado d2:dado 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. Fundamentos de Ingeniería de SW 85 Fundamentos de Ingeniería de SW 86 Análisis y diseño orientado a objetos Ejemplo Análisis y diseño orientado a objetos Comparación con AD estructurado casos de uso Definición del Modelo conceptual A diferencia del modelo conceptual, el modelo de diseño no muestra gráficamente conceptos del mundo real: describe únicamente los componentes del software. nombre jugar() Jugador Diagramas de colaboración Lanza 2 Dado valormostrado lanzar() Diagramas de diseño de clases 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. Juega Juego de dados Incluye 2 inicializar() Fundamentos de Ingeniería de SW 87 Fundamentos de Ingeniería de SW 88 Análisis y diseño orientado a objetos Comparación con AD estructurado Introducción al proceso de desarrollo Definición Sistema de la biblioteca A/D OO Descomposición por objetos o conceptos Catálogo Bibliotecario Libro Biblioteca Registrar Préstamos A/D estructurados Descomposición por funciones o procesos Sistema Agregar Reportar Recursos Multas 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. Fundamentos de Ingeniería de SW 89 Fundamentos de Ingeniería de SW 90 3

4 Introducción al proceso de desarrollo Pasos 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. Introducción al proceso de desarrollo Desarrollo 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 Ciclo de desarrollo 2 Ciclo de desarrollo 3 Fundamentos de Ingeniería de SW 9 Fundamentos de Ingeniería de SW 92 Introducción al proceso de desarrollo Desarrollo Iterativo Introducción al proceso de desarrollo Desarrollo Iterativo 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. Planificación y Elaboración Construcción Aplicación 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. Ciclo de Ciclo de Ciclo de desarrollo desarrollo 2 desarrollo 3 Perfeccionar Sincronización Análisis Diseño Construcción Prueba el plan de artefactos Fundamentos de Ingeniería de SW 93 Fundamentos de Ingeniería de SW 94 Introducción al proceso de desarrollo Fijación de un ciclo de desarrollo Introducción al proceso de desarrollo Casos de uso y los ciclos de desarrollo iterativos 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 Sincronización de artefactos Análisis Diseño Construcción Prueba 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. de 2 semanas a 2 meses Fundamentos de Ingeniería de SW 95 Fundamentos de Ingeniería de SW 96 4

5 Introducción al proceso de desarrollo 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. Introducción al proceso de desarrollo 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. Fundamentos de Ingeniería de SW 97 Fundamentos de Ingeniería de SW 98 Introducción al proceso de desarrollo Introducción al proceso de desarrollo 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 con las especificaciones de los requerimientos. 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. Fundamentos de Ingeniería de SW 99 Fundamentos de Ingeniería de SW 00 Introducción al proceso de desarrollo Fase de construcción: ciclos de desarrollo Introducción al proceso de desarrollo Fase 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. Ciclo de desarrollo Perfeccionami ento del plan. Definir casos esenciales de uso Ciclo de desarrollo 2 Sincronización de artefactos 2. Perfeccionar el diagrama de casos Ciclo de desarrollo 3 Análisis Diseño Construcción Prueba 3. Perfeccionar el modelo conceptual 4. Perfeccionar el glosario 5. Definir diagramas de secuencia 6. Definir los contratos de operaciones 7. Definir diagramas de estado Fundamentos de Ingeniería de SW 0 Fundamentos de Ingeniería de SW 02 5

6 Introducción al proceso de desarrollo Fase de construcción: ciclos de desarrollo Como en el caso de los artefactos de la fase de requerimientos, algunos artefactos pueden ser creados en paralelo, por ejemplo: Introducción al proceso de desarrollo Cuando crear el modelo conceptual El modelo conceptual es una representación de conceptos u objetos en el dominio del problema, como Libro y Biblioteca. Modelo conceptual y glosario. Diagramas de interacción y diagramas de diseño de clases. 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. Fundamentos de Ingeniería de SW 03 Fundamentos de Ingeniería de SW 04 Introducción al proceso de desarrollo Cuando 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. Introducción al proceso de desarrollo Cuando 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. Fundamentos de Ingeniería de SW 05 Fundamentos de Ingeniería de SW 06 Introducción al proceso de desarrollo Definició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. Introducción al proceso de desarrollo Modelo 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. Fundamentos de Ingeniería de SW 07 Fundamentos de Ingeniería de SW 08 6

7 Introducción al proceso de desarrollo Relación entre los artefactos Introducción al proceso de desarrollo Relació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. 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 Fundamentos de Ingeniería de SW 09 Fundamentos de Ingeniería de SW 0 Análisis y diseño orientado a objetos Resumen Qué es análisis? Qué es diseño? Análisis y diseño OO Uso de UML Introducción al proceso de desarrollo Análisis y diseño orientado a objetos Quiz 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? Fundamentos de Ingeniería de SW Fundamentos de Ingeniería de SW 2 Contenido Especificación de Requerimientos Casos de Uso: Descripción de Proceso Clasificación de los casos de uso Inicio de un ciclo de desarrollo Especificació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. Fundamentos de Ingeniería de SW 3 Fundamentos de Ingeniería de SW 4 7

8 Captura 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 Ejemplo: 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 Fundamentos de Ingeniería de SW 5 Fundamentos de Ingeniería de SW 6 Funciones y atributos del sistema Funciones 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. En cambio, los atributos del sistema son cualidades nofuncionales 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. Fundamentos de Ingeniería de SW 7 Fundamentos de Ingeniería de SW 8 Funciones y atributos del sistema 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. Funciones y atributos del sistema 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ía R. Registrar la venta en proceso (actual): la lista de los artículos Evidente comprados R.2 Calcular el total de la venta actual, incluyendo impuestos y descuentos Evidente R.5 Registrar las ventas completadas Oculta R.9 Mostrar la descripción y el precio del item Evidente Fundamentos de Ingeniería de SW 9 Fundamentos de Ingeniería de SW 20 8

9 Funciones y atributos del sistema Sería mejor agrupar funciones en un orden lógico, por ejemplo, todas las funciones de pago. Ref # Función Categoría R2. Manejar los pagos con efectivo, capturando la cantidad entregada y Evidente entregando el monto de vuelto R2.2 Manejar los pagos con las tarjetas de crédito, capturando la Evidente información de la tarjeta tanto por el lector como manualmente R2.4 Registrar los pagos con la tarjeta de crédito en el sistema de Oculta contabilidad, para cobrarlos después a los bancos. Funciones y atributos del sistema 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 =(???) Fundamentos de Ingeniería de SW 2 Fundamentos de Ingeniería de SW 22 Funciones y atributos del sistema 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 Tiempo de respuesta Sistema Operativo Detalle y limitación (restricción de frontera) La descripción y el precio aparecerán en menos de 5 segundos. (detalle) Microsoft Windows 95 y NT Funciones y atributos del sistema 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 y Categ. Limitaciones R.9 Mostrar la descripción y el precio del item Evidente Tiempo de respuesta La descripción y el precio aparecerán en menos de 5 segundos. Requerido Fundamentos de Ingeniería de SW 23 Fundamentos de Ingeniería de SW 24 Casos 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. Casos de uso: Descripción de procesos 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. Fundamentos de Ingeniería de SW 25 Fundamentos de Ingeniería de SW 26 9

10 Casos de uso: Descripción de procesos Notación en UML Comprar productos 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. Caso de uso: Comprar productos Actores: Cliente, Cajero Tipo: Primario Descripció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 la operación, el Cliente se marcha con los artículos comprados. Casos de uso: Descripción de procesos 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 efectivo Actores: Cliente (iniciador), Cajero Propó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. Al terminar la operación, el Cliente se marcha con los artículos comprados. Tipo: Primario Referencias Funciones: R., R.2, R.3, R.7, R2. Cruzadas: Fundamentos de Ingeniería de SW 27 Fundamentos de Ingeniería de SW 28 Ejemplo: Punto de venta Curso Normal de Eventos Acción de los actores. Este caso de uso comienza cuando un Cliente llega a una caja de TPDV (Terminal de Punto de Ventas) con productos que desea comprar. 2. El Cajero registra la identificación de cada producto. Si hay varios productos de una misma categoría, el Cajero también puede introducir la cantidad. 4. Al terminar de introducir el producto, el Cajero indica a TPDV que se concluyo la captura del producto. 6. El Cajero indica el total al Cliente. Respuesta del sistema 3. Determina el precio del producto e incorpora a la transacción actual la información correspondiente. Se presentan la descripción y el precio del producto actual. 5. Calcula y presenta el total de la venta. Ejemplo: Punto de venta Curso Normal de Eventos 7. El Cliente efectúa el pago en efectivo el efectivo ofrecido posiblemente mayor que el total de la venta. 8. El Cajero registra la cantidad de efectivo recibida. 0. El Cajero deposita el efectivo recibido y extrae el cambio de pago. El Cajero le da al Cliente el cambio y el recibo impreso. 2. El Cliente se marcha con los artículos comprados. 9. Muestra al cliente la diferencia. Genera un recibo.. Registra la venta concluida. 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. Fundamentos de Ingeniería de SW 29 Fundamentos de Ingeniería de SW 30 Explicación del formato expandido Explicación del formato expandido Caso de uso: Nombre del caso de uso Actores: Lista de actores (agentes externos), en la cual se indica quien inicia el caso de uso. Propósito: Intención de caso de uso Resumen: Repetición del resumen de alto nivel o alguna síntesis similar. Tipo:. Primario, secundario u opcional 2. Esencial o real Referencias Casos relacionados de uso y funciones también relacionadas del Cruzadas: sistema. 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 Acciones numeradas de los actores Respuesta del sistema Descripciones numeradas de las respuestas del sistema. Fundamentos de Ingeniería de SW 3 Fundamentos de Ingeniería de SW 32 0

11 Explicación del formato expandido Actores 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 alternativos Alternativas que pueden ocurrir en el número de línea. Descripción de excepciones. 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 Fundamentos de Ingeniería de SW 33 Fundamentos de Ingeniería de SW 34 Actores Errores comunes con los casos de uso 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. 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. Fundamentos de Ingeniería de SW 35 Fundamentos de Ingeniería de SW 36 Identificación de casos de uso Identificació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.. 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.. 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. 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 Fundamentos de Ingeniería de SW 37 Fundamentos de Ingeniería de SW 38

12 Casos 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. Diagramas 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 Cajero Cliente Comprar productos Fundamentos de Ingeniería de SW 39 Fundamentos de Ingeniería de SW 40 Clasificación de casos de uso Clasificació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. 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 sistema. El cliente se identifica. 2. Presenta opciones Fundamentos de Ingeniería de SW 4 Fundamentos de Ingeniería de SW 42 Clasificación de casos de uso 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 sistema. El cliente introduce su tarjeta. 2. Pide la clave personal (CP). 3. Introduce la clave con un teclado 4. Muestra menú de opciones. numérico Sobre 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:. 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. Fundamentos de Ingeniería de SW 43 Fundamentos de Ingeniería de SW 44 2

13 Sobre la notación Sobre la notación 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. 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:. 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 en cada sección. 3. Si las subsecciones tienen opciones, escríbalas en una sección de alternativas de cada subsección. Fundamentos de Ingeniería de SW 45 Fundamentos de Ingeniería de SW 46 Ejemplo de Punto de Ventas Puntos de decisión Sección: principal. Curso normal de eventos Acción de los actores Respuesta del sistema. Este caso de uso comienza cuando un Cliente llega a una caja de TPDV (Terminal de Punto de Ventas) con productos que desea comprar. 2. El Cajero registra la identificación de cada 3. Determina el precio del producto e producto. incorpora a la transacción actual la Si hay varios productos de una misma información correspondiente. categoría, el Cajero también puede introducir Se presentan la descripción y el precio del la cantidad. producto actual. 4. Al terminar de introducir el producto, el 5. Calcula y presenta el total de la venta. Cajero indica a TPDV que se concluyó la captura del producto. Ejemplo de Punto de Ventas Puntos de decisión 6. El cliente escoge el tipo de pago a. 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 terminada 8. Imprime un recibo. 9. El Cajero le entrega al Cliente el recibo impreso. 0. El Cliente se marcha con los artículos comprados. Cursos alternativos? Línea 2: introducción del identificador inválido. Indicar error. Fundamentos de Ingeniería de SW 47 Fundamentos de Ingeniería de SW 48 Ejemplo de Punto de Ventas Puntos de decisión Sección: Pago en efectivo Curso normal de eventos Acción del actor Respuesta del sistema. El Cliente efectúa el pago en efectivo el efectivo ofrecido posiblemente mayor que el total de la venta. 2. El Cajero registra la cantidad de efectivo 3. Muestra al cliente la diferencia. recibida. 4. El Cajero deposita el efectivo recibido y extrae 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édito Cursos normales y alternativos de la historia de pago con la tarjeta de crédito. Pasos de especificación de casos de uso. 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. Sección: Pago con cheque Cursos normales y alternativos de la historia de pago cheque. Fundamentos de Ingeniería de SW 49 Fundamentos de Ingeniería de SW 50 3

14 Pasos 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. Clasificació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. Fundamentos de Ingeniería de SW 5 Fundamentos de Ingeniería de SW 52 Resumen Especificación de Requerimientos Casos de Uso: Descripción de Proceso Clasificación de los casos de uso Inicio de un ciclo de desarrollo Quiz 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? Fundamentos de Ingeniería de SW 53 Fundamentos de Ingeniería de SW 54 Quiz Interprete el siguiente diagrama de casos de uso. Estudiante <<se comunica con>> registrarse en cursos seleccionar cursos a impartir crear lista de cursos <<usa>> <<usa>> Profesor Contenido Dependencia de los artefactos Técnicas de clasificación de casos de uso Formato extendido de los casos de uso Modelo conceptual Formas de determinar conceptos S. Facturación Valida usuario mantener infprofesor mantener infestudiante mantener infcurso Fundamentos de Ingeniería de SW crear catalogo curso Secretario 55 Fundamentos de Ingeniería de SW 56 4

15 Clasificación y programación de los casos de uso 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. Clasificación y programación de los casos de uso 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 Suma Comprar productos Y así sucesivamente Fundamentos de Ingeniería de SW 57 Fundamentos de Ingeniería de SW 58 Clasificación y programación de los casos de uso 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ón Alto Comprar productos Corresponde a los criterios de calificación más altos. Mediano Bajo Incorpora usuarios Registra los productos comprados Paga los productos comprados Pagar Iniciar Cerrar Afecta el subdominio de seguridad. Afecta el subdominio de seguridad. Proceso importante, afecta a contabilidad. Efecto mínimo en la arquitectura. La definición depende de los otros casos de uso. Efecto mínimo en la arquitectura Clasificación y programación de los casos de uso 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. Fundamentos de Ingeniería de SW 59 Fundamentos de Ingeniería de SW 60 Clasificación y programación de los casos de uso 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. Clasificación y programación de los casos de uso En esta situación, el caso de uso se redefine, como por ejemplo: Comprar productos versión (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. Fundamentos de Ingeniería de SW 6 Fundamentos de Ingeniería de SW 62 5

16 Asignació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: Versiones 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. Ciclo de desarrollo : Comprar productos versión, 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, También hay que especificar las simplificaciones, las metas y las suposiciones de cada versión. Fundamentos de Ingeniería de SW 63 Fundamentos de Ingeniería de SW 64 Versión de Comprar Productos Versión 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. 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. Fundamentos de Ingeniería de SW 65 Fundamentos de Ingeniería de SW 66 Versión de Comprar Productos Versión de Comprar Productos Caso de uso: Comprar productos, versión Actores: Cliente (iniciador), Cajero Propó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. Al terminar la operación, el Cliente se marcha con los artículos comprados. Tipo: Primario Referencias Funciones: R., R.2, R.3, R.7, R2. Cruzadas: Acción de los actores. Este caso de uso comienza cuando un Cliente llega a una caja de TPDV con productos que desea comprar. 2. El Cajero registra el código universal de producto (CUP) en cada producto. Si un producto se repite, el Cajero también puede introducir la cantidad. 4. Al terminar de introducir el producto, el Cajero indica a TPDV que se concluyó la captura del producto. 6. El Cajero indica el total al Cliente. Curso normal de eventos: Respuesta del sistema 3. Determina el precio del producto e incorpora a la transacción actual la información correspondiente. Presenta la descripción y el precio del producto en cuestión. 5. Calcula y presenta el total de la venta. Fundamentos de Ingeniería de SW 67 Fundamentos de Ingeniería de SW 68 6

17 Versión de Comprar Productos Comprar Productos: versión 2 7. El Cliente da un pago en efectivo el efectivo ofrecido posiblemente mayor que el total de la venta. 8. El Cajero registra la cantidad de efectivo recibida. 0. El Cajero deposita el efectivo recibido y extrae la diferencia. El Cajero le entrega al Cliente el cambio y el recibo impreso. 2. El Cliente se marcha con los artículos comprados. 6. Muestra al cliente la diferencia. Genera un recibo.. Registra la venta concluida. 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. Simplificaciones, metas y suposiciones Las simplificaciones de la versión 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 2 Actores: Cliente (iniciador), Cajero Propó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 uerir una autorización. Al terminar la operación, el Cliente se marchacon los artículos comprados. Fundamentos de Ingeniería de SW 69 Fundamentos de Ingeniería de SW 70 Inicio 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. Inicio 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 de codificació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. Fundamentos de Ingeniería de SW 7 Fundamentos de Ingeniería de SW 72 Actividades Artefactos Perfeccionamie nto del plan Sincronización de artefactos Análisis Diseño Construcción Prueba Casos de uso: esenciales expandidos Diagramas de casos de uso Casos de uso reales Diagramas de interacción Ventanas y reportes Métodos Casos de prueba. Definir los casos esenciales 5. Definir diagramas de secuencia 2. Perfeccionar el diagrama de casos 6. Definir los contratos de operaciones 3. Perfeccionar el modelo conceptual 7. Definir diagramas de estado 4. Perfeccionar el glosario Modelo conceptual Glosario Diagramas de secuencia del sistema Contratos de operación Diagramas de clase de diseño Diagrama de paquete de arquitectura Definicione s de clase y de interfaz dependencia respecto a Fundamentos de Ingeniería de SW 73 Diagramas de estado Esquema de SQL base de datos Fundamentos de Ingeniería de SW 74 7

18 Construcción de un modelo conceptual Construcció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 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. Fundamentos de Ingeniería de SW 75 Fundamentos de Ingeniería de SW 76 Fundamentos Fundamentos 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. 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. Fundamentos de Ingeniería de SW 77 Fundamentos de Ingeniería de SW 78 Fundamentos Fundamentos 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. 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. Fundamentos de Ingeniería de SW 79 Fundamentos de Ingeniería de SW 80 8