FACULTAD DE INGENIERÍA MECÁNICA Y ELÉCTRICA INGENIERÍA DE SOFTWARE Profr. Víctor Castillo. PRÁCTICA No. 2 Prototipos formales de software

Transcripción

1 FACULTAD DE INGENIERÍA MECÁNICA Y ELÉCTRICA INGENIERÍA DE SOFTWARE Profr. Víctor Castillo PRÁCTICA No. 2 Prototipos formales de software ALUMNO: GRUPO: Introducción El desarrollo de un artefacto de software se puede enfrentar a varias situaciones adversas. Por ejemplo, en ocasiones un cliente no puede detallar de manera precisa los requerimientos funcionales de la aplicación que requiere; otras veces, quien desarrolla el software no está seguro de qué tan válido es usar un determinado algoritmo para algún dominio en particular. Para los sistemas que presentan tales características, el paradigma de construcción de prototipos puede dar buenos resultados[]. Un prototipo es un modelo a escala de lo real, pero no tan funcional para que equivalga al producto final [2]. En la fase de análisis, el objetivo del prototipo es derivar y validar los requerimientos esenciales, manteniendo abiertas, al mismo tiempo, las opciones de implementación. Los beneficios que se pueden obtener por el uso de prototipos son: Es la primera vez que el sistema tiene cara. Propicia que salgan a la superficie los asuntos de los procesos del negocio. Hace evidentes asuntos técnicos del proyecto cuando hay tiempo suficiente para hacer algo al respecto. Permite que se exploren ambientes de destino posibles. Por otra parte, el uso de prototipos tiene también algunos inconvenientes: Es posible que dirijan al proyecto hacia el diseño. Pueden prometer características que no se pueden proporcionar. El gerente del sistema puede soltar las riendas a los programadores y se puede codificar sin atender al análisis. Como lo muestra la Figura, el paradigma de construcción de prototipos comienza con el levantamiento de los requisitos; posteriormente, se lleva a cabo un diseño rápido que contempla aspectos de software que serán visibles al cliente, como por ejemplo formatos de entrada y salida; finalmente, el usuario potencial hace una valoración del prototipo y evalúa si este representa la funcionalidad que

2 espera del mismo, con tal valoración, se da un proceso de retroalimentación que es considerado en la construcción de otra posible maqueta. Esta sucesión de prototipos mejorados van dando paulatinamente la definición final de los requisitos. Escuchar al cliente Construir/revisar maqueta El cliente prueba la maqueta Figura. El paradigma de construcción de prototipos. Existen varias propuestas para el desarrollo formal de prototipos, entre ellas se encuentra el prototipo de interfaz [2], el cual sirve para especificar el aspecto, sensación y comportamiento de la parte del sistema que interactúa con el usuario. En la propuesta de Ruble [2], el prototipo de interfaz proviene de lo que denomina modelo de contexto, el cual corresponde al modelo de casos de uso estipulado en la propuesta de Jacobson et al. [3], así mismo, es fundamentado en el modelo de información que es lo que se define como el modelo de clases en la propuesta de Rumbaugh et al. [4]. Básicamente, los productos del prototipo de interfaz son: Disposición del contenido de una interfaz gráfica, así como Rutas de navegación por la interfaz. De esta forma, considerando la Figura 2, la cual representa un ejemplo en el que se desea implementar un sistema para control de facturación en una papelería, y suponiendo que bajo consenso con el cliente, se hayan estipulado dos actores (cliente y vendedor) y tres casos de uso (solicitar artículos, confirmar compra, expedir factura), el modelo de casos de uso quedaría como se muestra en la mencionada figura. 2

3 Figura 2. Modelo de casos de uso para el control de facturación en una papelería. Del modelo de casos de uso mostrado en la Figura 2, es posible que esbocemos el modelo de clases para ese sistema, el cual es mostrado en la Figura 3. Cliente -IDCliente : string -Nombre : string -Apellido : string +Eliminar() +Modificar() +Listar() -pertenece a -posee -vende -es atendido -asociada a Vendedor -IDVend : string -Nombre : string -Apellido : string -Depto : decimal +Borrar() +Modificar() +Listar() Factura -IDFactura : string -IDCliente : string -IDVendedor : string -Fecha : string -Condiciones : byte +Borrar() +Modificar() +Listar() +Concentrar() +ncelar() -coloca -asignado a -contiene Articulo -IDFactura : string -Descripcion : string -Cantidad : int -Costo : float +Borrar() +Actualizar() +Filtrar() Figura 3. Modelo de clases para el control de facturación en una papelería. Considerando el modelo de casos de uso y el de clases descritos previamente, el prototipo de interfaz de Ruble [2] sugiere que a partir de las relaciones de clases estipuladas en el modelo correspondiente, es posible determinar la forma en la que se organiza el contenido de una interfaz gráfica. Veamos cómo podría tomarse en cuenta el modelo mostrado en la Figura 3 para construir un prototipo de interfaz: primero, se asocian los contenidos de las clases existentes en el modelo de clase de acuerdo con un sentido estrictamente semántico, este sentido puede darnos una idea de que, por ejemplo, con base en la información de las clases Factura y Cliente, podemos generar un encabezado de la factura para la interfaz gráfica -como se ilustra en la Figura 4-, así mismo, como podemos observar en esa figura, de la asociación semántica existente entre las clases Factura y Articulo es posible generar el detalle de la factura. 3

4 Figura 4. Utilización del modelo de clases para el desarrollo de prototipos de interfaz. Finalmente, y como se estipulaba en párrafos previos, el prototipo de interfaz sugiere también las rutas de navegación a través de la interfaz gráfica de usuario, tales rutas son sugeridas también por el modelo de clases. Las rutas de navegación a través de la interfaz pueden representarse con diagramas de bloque que muestren la manera en la que una interfaz gráfica permite, en forma lógica y metódica, desplazarse a través de ella, tal y como se ilustra en la Figura 5, en la cual vemos cómo la relación que existe entre las clases Factura y Articulo permite guiar la forma en la que se puede acceder a la información que representa esta asociación a través de una interfaz gráfica de usuario. Figura 5. Utilización del modelo de clases para estipular la ruta de navegación en una interfaz de usuario. Observe en la Figura 5 que las rutas de navegación sugeridas están estipuladas con flechas que conectan bloques, estos bloques representan aspectos lógicos de navegación y no necesariamente la construcción de una interfaz gráfica de usuario que represente a cada uno de ellos. Con los productos mostrados en las figuras 4 y 5, la propuesta de Ruble [2] generaría un prototipo completo que tendría que ser evaluado por el cliente potencial del sistema. A través de los resultados de esta evaluación se podría decidir si los requisitos del sistema han sido estipulados en su totalidad o si se 4

5 debe realizar otra iteración que genere un nuevo prototipo. Con tal proceso, eventualmente se llegaría a estipular de forma completa los requerimientos funcionales del sistema, aspecto fundamental en la utilización de un paradigma de desarrollo de prototipos. Desarrollo.- Considere, para todos los puntos indicados en esta sección de Desarrollo, el material obtenido en las clases del curso, el cual sugiere la construcción de un modelo de casos de uso y un modelo de clases para un sistema de control bibliotecario. 2.- Tome en cuenta algunas relaciones semánticas existentes en los modelos de casos de uso y de clases, y genere y construya al menos dos esquemas de interfaz gráfica de usuario como el mostrado en la Figura 4, especifique mediante texto cuáles clases relacionó y por qué (presentar los esquemas de interfaz en hojas anexas). 3.- Considerando también algunas relaciones existentes en el modelo de clases del citado material, desarrolle al menos dos esquemas de navegación de interfaz gráfica de usuario como el mostrado en la Figura 5, especifique mediante texto cuáles clases relacionó y por qué (presentar los esquemas de navegación en hojas anexas). 5

6 4.- Considera usted que el dominio de aplicación (el sistema bibliotecario de la biblioteca del campus universitario) para el cual fueron construidos los modelos de casos de uso y de clases sea el más adecuado para usar un paradigma de construcción de prototipos? Por qué? Observaciones y/o conclusiones Referencias [] R. S. Pressman, Ingeniería del software. Un enfoque práctico, 4a ed. Madrid: Mc. Graw Hill, 998. [2] D. A. Ruble, Análisis y diseño práctico de sistemas cliente/servidor con GUI, a ed. México: Prentice Hall Hispanoamericana, S.A., 998. [3] I. Jacobson, G. Booch, and J. Rumbaugh, El proceso unificado de desarrollo de software: Adison Wesley, [4] J. Rumbaugh, I. Jacobson, and G. Booch, El Lenguaje Unificado de Modelado. Manual de referencia, a ed. Madrid: Addison Wesley,