Você está na página 1de 6

FACULTAD DE INGENIERA MECNICA Y ELCTRICA

INGENIERA DE SOFTWARE

Profr. Vctor Castillo

PRCTICA No. 2
Prototipos formales de software
ALUMNO: ________________________________________________ GRUPO: ____

Introduccin
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 aplicacin que requiere; otras veces,
quien desarrolla el software no est seguro de qu tan vlido es usar un
determinado algoritmo para algn dominio en particular. Para los sistemas que
presentan tales caractersticas, el paradigma de construccin de prototipos puede
dar buenos resultados[1].
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 anlisis, el objetivo del prototipo es
derivar y validar los requerimientos esenciales, manteniendo abiertas, al mismo
tiempo, las opciones de implementacin. 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 tcnicos 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 tambin algunos inconvenientes:

Es posible que dirijan al proyecto hacia el diseo.


Pueden prometer caractersticas que no se pueden proporcionar.
El gerente del sistema puede soltar las riendas a
programadores y se puede codificar sin atender al anlisis.

los

Como lo muestra la Figura 1, el paradigma de construccin de prototipos


comienza con el levantamiento de los requisitos; posteriormente, se lleva a cabo
un diseo rpido que contempla aspectos de software que sern visibles al cliente,
como por ejemplo formatos de entrada y salida; finalmente, el usuario potencial
hace una valoracin del prototipo y evala si este representa la funcionalidad que
1

espera del mismo, con tal valoracin, se da un proceso de retroalimentacin que es


considerado en la construccin de otra posible maqueta. Esta sucesin de
prototipos mejorados van dando paulatinamente la definicin final de los
requisitos.

Escuchar al
cliente
Construir/revisar
maqueta

El cliente prueba
la maqueta

Figura 1. El paradigma de construccin 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,
sensacin y comportamiento de la parte del sistema que interacta 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
informacin que es lo que se define como el modelo de clases en la propuesta de
Rumbaugh et al. [4].
Bsicamente, los productos del prototipo de interfaz son:

Disposicin del contenido de una interfaz grfica, as como


Rutas de navegacin 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 facturacin en una papelera, y
suponiendo que bajo consenso con el cliente, se hayan estipulado dos actores
(cliente y vendedor) y tres casos de uso (solicitar artculos, confirmar compra,
expedir factura), el modelo de casos de uso quedara como se muestra en la
mencionada figura.

Figura 2. Modelo de casos de uso para el control de facturacin en una papelera.

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

-vende

-IDCliente : string
-Nombre : string
-Apellido : string
+Crear()
+Eliminar()
+Modificar()
+Listar()

-es atendido

1
-asociada a
1

-pertenece a

-posee

Factura
-IDFactura : string
-IDCliente : string
-IDVendedor : string
-Fecha : string
-Condiciones : byte
+Crear()
+Borrar()
+Modificar()
+Listar()
+Concentrar()
+ncelar()

Vendedor
-IDVend : string
-Nombre : string
-Apellido : string
-Depto : decimal
+Crear()
+Borrar()
+Modificar()
+Listar()

Articulo

-coloca
*
-contiene
-asignado a
*

-IDFactura : string
-Descripcion : string
-Cantidad : int
-Costo : float
+Crear()
+Borrar()
+Actualizar()
+Filtrar()

Figura 3. Modelo de clases para el control de facturacin en una papelera.

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 grfica. Veamos cmo podra 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 semntico, este sentido puede
darnos una idea de que, por ejemplo, con base en la informacin de las clases
Factura y Cliente, podemos generar un encabezado de la factura para la interfaz
grfica -como se ilustra en la Figura 4-, as mismo, como podemos observar en esa
figura, de la asociacin semntica existente entre las clases Factura y Articulo es
posible generar el detalle de la factura.
3

Figura 4. Utilizacin del modelo de clases para el desarrollo de prototipos de interfaz.

Finalmente, y como se estipulaba en prrafos previos, el prototipo de interfaz


sugiere tambin las rutas de navegacin a travs de la interfaz grfica de usuario,
tales rutas son sugeridas tambin por el modelo de clases. Las rutas de
navegacin a travs de la interfaz pueden representarse con diagramas de bloque
que muestren la manera en la que una interfaz grfica permite, en forma lgica y
metdica, desplazarse a travs de ella, tal y como se ilustra en la Figura 5, en la
cual vemos cmo la relacin que existe entre las clases Factura y Articulo permite
guiar la forma en la que se puede acceder a la informacin que representa esta
asociacin a travs de una interfaz grfica de usuario.

Figura 5. Utilizacin del modelo de clases para estipular la ruta de navegacin en una interfaz de usuario.

Observe en la Figura 5 que las rutas de navegacin sugeridas estn estipuladas


con flechas que conectan bloques, estos bloques representan aspectos lgicos de
navegacin y no necesariamente la construccin de una interfaz grfica de
usuario que represente a cada uno de ellos.
Con los productos mostrados en las figuras 4 y 5, la propuesta de Ruble [2]
generara un prototipo completo que tendra que ser evaluado por el cliente
potencial del sistema. A travs de los resultados de esta evaluacin se podra
decidir si los requisitos del sistema han sido estipulados en su totalidad o si se
4

debe realizar otra iteracin que genere un nuevo prototipo. Con tal proceso,
eventualmente se llegara a estipular de forma completa los requerimientos
funcionales del sistema, aspecto fundamental en la utilizacin de un paradigma
de desarrollo de prototipos.

Desarrollo
1.- Considere, para todos los puntos indicados en esta seccin de Desarrollo, el
material obtenido en las clases del curso, el cual sugiere la construccin de un
modelo de casos de uso y un modelo de clases para un sistema de control
bibliotecario.
2.- Tome en cuenta algunas relaciones semnticas existentes en los modelos de
casos de uso y de clases, y genere y construya al menos dos esquemas de interfaz
grfica de usuario como el mostrado en la Figura 4, especifique mediante texto
cules clases relacion y por qu (presentar los esquemas de interfaz en hojas
anexas).
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
3.- Considerando tambin algunas relaciones existentes en el modelo de clases del
citado material, desarrolle al menos dos esquemas de navegacin de interfaz
grfica de usuario como el mostrado en la Figura 5, especifique mediante texto
cules clases relacion y por qu (presentar los esquemas de navegacin en hojas
anexas).
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________

4.- Considera usted que el dominio de aplicacin (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 ms adecuado para usar un paradigma de
construccin de prototipos? _____ Por qu?
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________

Observaciones y/o conclusiones

_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________

Referencias
[1]
[2]
[3]
[4]

R. S. Pressman, Ingeniera del software. Un enfoque prctico, 4a ed. Madrid: Mc.


Graw Hill, 1998.
D. A. Ruble, Anlisis y diseo prctico de sistemas cliente/servidor con GUI, 1a ed.
Mxico: Prentice Hall Hispanoamericana, S.A., 1998.
I. Jacobson, G. Booch, and J. Rumbaugh, El proceso unificado de desarrollo de
software: Adison Wesley, 2000.
J. Rumbaugh, I. Jacobson, and G. Booch, El Lenguaje Unificado de Modelado.
Manual de referencia, 1a ed. Madrid: Addison Wesley, 2000.

Você também pode gostar