Programación orientada a objetos Semestre 6 Fascículo No. 2

Transcripción

1 Programación orientada a objetos Semestre 6 Fascículo No. 2 Tabla de contenido Requerimientos UML Unified Modeling Language Diagramas de casos de uso (funcional) Procesos Entradas Salidas Actores Herramientas Agentes Resumen Bibliografía recomendada Párrafo nexo Autoevaluación formativa

2 Requerimientos Los requerimientos son descripciones de las necesidades específicas y generales que tiene un cliente con respecto a un producto de software. Indicadores de logro Al finalizar el estudio del presente fascículo, el estudiante: Explica la importancia de la etapa de recolección de requerimientos. Explica qué es y para qué sirve UML. Determina la utilidad de un diagrama de casos de uso dentro del proceso de desarrollo de software. Identifica el papel de los procesos en los diagramas de casos de uso. El principal objetivo de la fase de requerimientos es identificar y documentar lo que en realidad se necesita, en una forma clara y concisa que pueda ser entendida, tanto por el cliente como por la parte desarrolladora. Los requisitos recolectados deben cumplir las expectativas del cliente, deben ser coherentes para el desarrollador y deben estar dentro de sus posibilidades. Un error frecuente es aceptar todo lo que el cliente pide sin tener en cuenta la disponibilidad de tiempo, esfuerzo y la complejidad del problema a solucionar. Es muy común que los desarrolladores se lamenten y quejen de los problemas asociados a los métodos de gestión de requerimientos tradicionales, siendo la mayoría de estos métodos demasiado rígidos.

3 Se ha encontrado que las 3 razones principales por las cuales los proyectos son entregados tarde, por encima del presupuesto y sin terminar o con una funcionalidad menor a la requerida son: Falta de información del usuario. Requerimientos incompletos. Cambios en los requerimientos. Ladillo Los requerimientos deben ser cuantificables y se especifican antes de comenzar con el proceso de desarrollo de software. La gestión de requerimientos tiene como base principal los siguientes tópicos: Metodología de análisis de requerimientos, incluyendo análisis estructurado, análisis estructurado de datos y análisis orientado a objetos. Método para crear el modelo del sistema, como diagrama de clases, diagrama de flujo de datos, diagramas entidad relación, diagramas de estado transición. Método de comunicación, como el desarrollo conjunto de aplicaciones, prototipado de la interfaz de usuario y métodos generales de entrevistas. Las relaciones entre la gestión de requerimientos y los diferentes ciclos de vida incluyendo el prototipado evolutivo y la entrega por etapas, espiral, cascada, y codificar y corregir.

4 La gestión de requerimientos ayuda a que el desarrollo de software tenga un mejor desempeño en términos de tiempo y esfuerzo; por lo tanto, se debe tener en cuenta que la recolección de requerimientos es un paso que tiende a hacerse sin prisa, comparado con las otras actividades del ciclo de desarrollo. Para que la etapa de recolección de requerimientos sea exitosa y realmente ayude al proceso de desarrollo de una aplicación y que muestre lo que el cliente está solicitando, deben existir métodos de recopilación de requerimientos orientados al cliente. Estos métodos implican que el cliente debe estar involucrado directa y constantemente en todos y cada uno de los aspectos que serán desarrollados en las etapas posteriores y que serán plasmados en el documento final de la etapa de recolección y análisis de requerimientos. Observación Cuanto más tiempo se dedique a trabajar en los requerimientos reales se perderá menos tiempo trabajando sobre requerimientos extraños y se podrá entregar antes el software que desea el cliente. Figura 2.1 Sin métodos de recopilación de requerimientos orientados al cliente.

5 Figura 2.2 Con métodos de recopilación de requerimientos orientados al cliente. Ladillo Los requerimientos deben ajustarse a lo que el cliente necesita y no deben reflejar la percepción del ingeniero de software frente al problema planteado por el cliente; es decir, el producto final debe ser lo que quiere el cliente y no el ingeniero. Se debe tener en cuenta que los extremos siempre son malos: a pesar de la importancia de implicar a los clientes en la especificación de requerimientos hay que evitar que los clientes realicen especificación total de requerimientos. Se ha encontrado que la productividad aumenta con la alta participación de los clientes, pero también se ha encontrado que la productividad disminuye cuando los clientes describen la especificación.

6 Existen 3 tipos de requisitos: Requisitos normales: se declaran objetivos y metas para un producto o sistema durante las reuniones con el cliente. Requisitos esperados: estos requisitos son implícitos al producto o sistema y pueden ser tan fundamentales que el cliente no los declara explícitamente. Requisitos innovadores: estas características van más allá de las expectativas del cliente y suelen ser muy satisfactorias. Actividad 2.1 Elabore un documento con los posibles requerimientos en el desarrollo de un sistema automático que administre parqueaderos. Recuerde que el sistema debe hacer cosas como registrar la entrada y salida de automóviles, generar cuántos automóviles hay parqueados en el momento, cuántos parqueos hubo por día, semana, mes o año, cuánto es el monto obtenido por parqueos diarios, mensuales, semanales o anuales. UML Unified Modeling Language El UML (Lenguaje unificado para la construcción de modelos) se define como un lenguaje que permite especificar, visualizar y construir los artefactos de los sistemas de software. Es un sistema notacional destinado a los sistemas de modelado que utilizan conceptos orientados por objetos.

7 El UML es un estándar de la industria para construir modelos orientados a objetos. Nació en 1994 por iniciativa de Grady Booch y Jim Rumbaugh para combinar sus 2 famosos métodos: el de Booch y OMT (Object Modeling Technique). Más tarde se les unió Ivar Jaconson, creador del método OOSE (Object-oriented Software Engineering). En respuesta a una petición de OMG (Object Management Group) para definir un lenguaje y una notación estándar del lenguaje de construcción de modelos, en 1997 propusieron el UML como candidato. Hay que tener en cuenta que el UML es un lenguaje para construir modelos, no guía al desarrollador en la forma de realizar el análisis y diseño orientado a objetos, ni le indica cuál proceso de desarrollo debe adoptar. UML no es un método de análisis y diseño orientado a objetos, sino una notación general y simple que sirve para utilizarse en métodos de desarrollo de software. El UML tiene un amplio espectro de uso: se puede utilizar para el modelado de negocios, modelados de software en todas las fases de desarrollo y para todos los tipos de sistemas y modelado general de cualquier construcción que tenga un comportamiento dinámico y estático a la vez. Las partes fundamentales de UML son: Vistas: muestran los diferentes aspectos del sistema a modelar. Diagramas: son los grafos que describen el contenido de la vista. Elementos de modelo: conceptos utilizados en los diagramas. Mecanismos generales: proporcionan asociación, dependencia y generalización.

8 Ladillo El UML es un lenguaje que permite especificar sistemas de software mediante símbolos que representan partes del sistema y relaciones entre los mismos. Diagramas de casos de uso (funcional) La recolección de requerimientos es siempre el primer y más importante paso en la actividad de desarrollo de software. Basados en los requerimientos el Ingeniero de Software puede crear un conjunto de escenarios de manera tal que cada uno identifique una parte del uso que se le dará al sistema por desarrollar. Para poder trabajar con Casos de Uso se debe tener al menos un conocimiento parcial de los requerimientos del sistema que se va a desarrollar. El caso es un documento 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 del sistema; no son exactamente los requerimientos, sino que ejemplifican e incluyen tácitamente los requerimientos en las historias que se narran. Para crear un caso de uso, el Ingeniero de Software debe, primero que todo, identificar los diferentes tipos de personas, agentes o dispositivos que usan el sistema o producto. Un actor (personas, agentes o dispositivos) es cualquier cosa que se pueda comunicar o interactuar con el sistema o producto y que sea externo a él.

9 Actividad 2.1 Elabore el diagrama de casos de uso del proceso de entrada a cine. Es importante aclarar que un actor y un usuario no son la misma cosa. Un usuario típico puede desempeñar un cierto número de roles cuando usa el sistema. El actor representa una clase de entidades externas que sólo desempeñan un único papel. Cuando se conoce más sobre el sistema, es posible identificar actores primarios y actores secundarios. Los actores primarios interactúan para lograr el funcionamiento requerido del sistema. Ellos trabajan directa y frecuentemente con el software. Los actores secundarios existen para dar soporte al sistema de manera tal que los primarios puedan realizar su trabajo. El caso de uso describe la forma en la cual un actor interactúa con el sistema. La notación de UML para diagramas de casos de uso se muestra en la figura 2.3

10 Caso de uso Agente Figura 2.3 Notación UML para diagramas de casos de uso. Ejemplo El siguiente caso de uso describe clara y concisamente el proceso de comprar artículos en una tienda cuando se emplea un computador en el punto de venta. Caso de uso Actores Descripción Comprar productos Cliente, cajero Un cliente llega a la caja registradora con los artículos que comprará. El cajero registra los artículos y cobra el valor. Al terminar la operación, el cliente se marcha con los productos.

11 Curso normal de los eventos Acción del actor 1. Este caso de uso comienza cuando un Cliente llega a una caja registradora con productos que desea comprar. 2. El cajero registra el identificador 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 en el computador que se concluyó la captura del producto. 6. El cajero le indica el total al cliente. 7. El cliente efectúa un pago en efectivo (posiblemente mayor que el total de la venta) 8. El cajero registra la cantidad de efectivo recibida. 10. El cajero deposita el efectivo recibido y extrae el cambio del pago. El cajero da al cliente el cambio y el recibo impreso. 12. El cliente se marcha con los artículos comprados. 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. 9. Muestra al cliente la diferencia. Genera un recibo. 11. Registra la venta concluida.

12 Diagrama de casos de uso Compra productos Cajero Registra los datos Cliente Entrega el cambio de los productos comprados Figura 2.4 Diagrama de Casos de Uso de ejemplo El diagrama de casos de uso explica gráficamente un conjunto de casos de uso de un sistema, los actores y la relación entre éstos y los casos de uso. El diagrama tiene por objeto ofrecer una clase de diagrama contextual que nos permite conocer rápidamente los actores externos de un sistema y las formas básicas en que lo utilizan.

13 Ladillo El diagrama de casos de uso tiene por objeto ofrecer una clase de diagrama contextual que nos permite conocer rápidamente los actores externos de un sistema y las formas básicas en que lo utilizan. Procesos Cada uno de los casos de uso de un diagrama es, en realidad, un proceso en el cual intervienen los siguientes componentes: entradas, salidas, herramientas y agentes. Entradas Las entradas de un proceso son la información necesaria para que el proceso pueda ser llevado a cabo. Salidas Las salidas de un proceso son el resultado esperado una vez éste finalice exitosamente. Herramientas En esta parte de la definición de procesos, se enumeran las herramientas necesarias para poder manipular las entradas y poder llevar a cabo el proceso.

14 Agentes Son las diferentes entidades que intervienen en el desarrollo del proceso. Los agentes son los encargados de manipular las entradas con las herramientas para generar las salidas. Se ha definido una gráfica para poder mostrar la definición de un proceso en la cual intervienen cada una de las partes de un proceso; dicha gráfica es mostrada en la figura 2.5. Entradas Agentes Herramientas Salidas Figura 2.5 Definición gráfica de un proceso

15 Resumen La fase de requerimientos es parte vital en el proceso de desarrollo de software debido a que en esta etapa se establecen, de común acuerdo con el cliente, las características y los alcances que tendrá el software. Para ayudar a hacer la elaboración de diagramas y estándares entendibles para cualquier diseñador de software que reflejen las características recolectadas en el proceso de requerimientos y en cada una de las etapas subsecuentes de desarrollo, se utiliza UML como lenguaje de modelado. El diagrama que se usa en el proceso de recolección de requerimientos de software y que refleja los resultados de esa primera etapa de desarrollo es el Diagrama de Casos de Uso. Dicho diagrama muestra los actores y su relación con los procesos internos de la aplicación. Bibliografía recomendada PRESSMAN R., Ingeniería de Software un enfoque práctico. McGraw Hill, cuarta edición LARMAN C., UML y Patrones Introducción al Análisis y Diseño Orientado a Objetos. Pearson, primera edición, McCONNELL S., Desarrollo y Gestión de Proyectos Informáticos. Primera edición, 1996.

16 Nexo En el siguiente fascículo se mostrarán los aspectos básicos del lenguaje de programación Java el cual será utilizado en el desarrollo del curso para aplicar los conceptos de programación orientada por objetos en aplicaciones reales. También se mostrarán sus características, ventajas y documentación.

17 Autoevaluación formativa 1. Defina el diagrama de casos de uso para el proceso de matriculación en su Facultad. 2. Defina el diagrama de procesos para el proceso de amarrarse un zapato. 3. Establezca el diagrama de casos de uso de alquiler de una película.