Trabajando con Interfaces de Múltiples Documentos (MDI)

Cuando trabajamos con aplicaciones Windows existen dos tipos de interfaces o formas de presentar la información en pantalla, éstas son: 

1. Interface de Simple Documento (SDI): Presenta un documento en su propia ventana, cada ventana es independiente. Por ejemplo, usan SDI; el Bloc de Notas, el Paint, el WordPad, Office 2000, etc. 
2. Interface de Múltiples Documentos (MDI): Presenta todos los documentos sobre una ventana principal (formulario padre) sobre la cual se muestra cada documento en su  ventana secundaria (formulario hijo). Por ejemplo, usan MDI: el Visual Studio .NET, SQL Enterprise Manager, Office 97, etc. 

Hasta ahora todas las aplicaciones creadas que tienen más de un formulario han usado Interfaces de Simples Documentos (SDI). 

En esta parte, veremos cómo trabajar en .NET, las Interfaces de Múltiples Documentos (MDI); empezaremos aprendiendo a crear un formulario MDI padre y a crear formularios MDI hijos, después aprenderemos cómo organizar a éstos sobre la ventana principal o padre, y finalmente enseñaremos cómo trabajar con el formulario padre desde el hijo y cómo trabajar con el formulario hijo desde el padre. 

• Creando un formulario MDI padre 

Para crear un formulario MDI Padre que será la ventana principal de la aplicación Windows, sólo hay que configurar la propiedad IsMdiContainer del formulario en True, ya que por defecto esta es False. 

Una vez creado el formulario MDI Padre, el Visual Studio .NET permite agregar todo tipo de controles, pero una buena práctica es sólo tener menús y barras de herramientas para organizar los comandos de la aplicación. 

El formulario MDI Padre creado se muestra en el Diseñador de Formularios Windows con un fondo gris más oscuro que el tradicional fondo gris claro de los formularios Windows, como se aprecia en la siguiente figura: 

• Creando un Formulario MDI Hijo 

Para crear un formulario MDI Hijo que se muestre dentro de la ventana principal de la aplicación Windows, sólo hay que configurar la propiedad MdiParent del formulario hijo asignándole el formulario MDI Padre, tal como se muestra en el siguiente código: 

Nota: La propiedad MdiParent sólo está disponible en tiempo de ejecución, es decir; es obligatorio, realizar la configuración mediante código.
Observación: Si no se configura la propiedad MdiParent del formulario hijo, éste se muestra fuera del formulario MDI Padre.
Advertencia: Si se configura la propiedad MdiParent y se muestra el formulario Hijo con el método ShowDialog se generará una Excepción. 

Todos los formularios configurados con la propiedad MdiParent aparecerán sobre el formulario MDI Padre, tal como se aprecia en la siguiente figura:

Ventana de un formulario MDI Padre conteniendo 3 Hijos

• Organizando Ventanas dentro del MDI 

Para organizar las ventanas hijas dentro de la ventana padre hay que usar el método LayoutMdi() del formulario Padre, el cual tiene como parámetros un valor o enumeración de tipo MdiLayout, tal como se muestra en el siguiente código: 

objPadre.LayoutMdi(valor) 

ó

objPadre.LayoutMdi(MdiLayout.Constante) 

Los valores o constantes de la enumeración MdiLayout y su efecto se muestra en el siguiente cuadro: 

Constante	Valor	Efecto
Cascade	0	Organiza las ventanas hijas en cascada.
TileHorizontal	1	Muestra en mosaico horizontal las ventanas.
TileVertical	2	Muestra en mosaico vertical las ventanas.
ArrangeIcons	3	Alinea en la parte inferior los iconos o ventanas que han sido minimizadas.

Por ejemplo, si queremos organizar las ventanas en forma horizontal, escribir:

ó

Entonces, las ventanas se verán tal como se aprecia en la siguiente figura:

Ventanas hijas organizadas en Mosaico Horizontal.

• Trabajando con el Formulario MDI Padre desde el Hijo

Si desde el formulario MDI hijo se quiere usar alguna característica del padre, se debe trabajar con la propiedad MdiParent del formulario hijo que apunta a la instancia actual del formulario padre. 

Por ejemplo, para mostrar el título del formulario padre como título del formulario hijo, tendríamos que escribir el siguiente código: 

objHijo.Text = objHijo.MdiParent.Text 

ó

Me.Text = Me. Mdi Parent.Text 

Nota: 
En la segunda sintaxis, me representa a la instancia actual del formulario hijo en el cual se escribe el código.

• Trabajando con el Formulario MDI Hijo desde el Padre 

Si desde el formulario MDI padre se quiere usar alguna característica del hijo, hay que realizar dos pasos que son: 

1. Verificar si existen formularios hijos abiertos usando la propiedad Length del objeto MdiChildren que es una propiedad del formulario padre, similar al siguiente código: 

2. Acceder a una propiedad o control del formulario hijo usando el objeto ActiveMdiChild que es una propiedad del formulario padre, similar al siguiente código: 

Propiedad_Hijo = Me.ActiveMdiChild.Propiedad 

Control_Hijo = Me.ActiveMdiChild.Controls(N) 

Advertencia:Si se accede a una propiedad o control del formulario hijo sin existir instancias en el padre (paso 1) se generará una Excepción.

Ejemplo 27

Esta demostración tiene por objetivo enseñar a trabajar con interfaces de múltiples documentos (MDI). Se aprenderá a crear un formulario MDI padre y formularios MDI hijos, se verá como organizar las ventanas hijas dentro del padre y como invocar desde el formulario padre al hijo y viceversa. 

El ejemplo trabaja con dos formularios, uno es el formulario MDI padre y el otro es el formulario base para crear los MDI hijos. El padre tiene un menú principal con dos opciones, una llamada Archivo y otra Ventana; la primera opción permite crear un nuevo hijo, mostrar el mensaje escrito en la ventana hija activa y salir de la aplicación; la segunda opción permite organizar las ventanas hijas dentro del padre. 

Por su parte el formulario hijo permite ingresar un mensaje que se podrá recuperar desde la ventana padre y también visualiza un mensaje guardado en la propiedad Tag del formulario padre. 

Para lo cual debemos realizar los siguientes pasos: 

1. Crear una Aplicación Windows en Visual Basic .NET llamada Ejemplo27. EL IDE a utilizar es Microsoft Visual Studio 2012.

2. En la ventana del explorador de soluciones seleccionar el archivo Form1 y en la ventana de propiedades cambiar la propiedad FileName a frmPadre. 

3. En el diseñador de formularios Windows, arrastrar un control MenuStrip y configurar las propiedades, tal como se muestra en el siguiente cuadro: 

Objeto	Propiedad	Valor
Form1	Name	frmPadre
	IsMdiContainer	True
	StartPosition	CenterScreen
	Tag	NET es Orientado a Objetos
	Text	Ventana principal o MDI Padre
MenuStrip1	Name	mnuPrincipal

4. Seleccione el control MenuStrip y en la parte superior donde dice "Escriba Aquí" , escriba directamente los textos del menú y configure sus propiedades, tal como se muestra en el siguiente cuadro:

Objeto	Propiedad	Valor
ToolStripMenuItem1	Name	mnuArchivo
	Text	&Archivo
ToolStripMenuItem11	Name	mnuNuevoHijo
	Text	&NuevoHijo
ToolStripMenuItem12	Name	mnuMensajeHijo
	Text	&Mensaje Hijo
ToolStripMenuItem13	Name	mnuLineal
	Text	-
ToolStripMenuItem14	Name	mnuSalir
	Text	&Salir
ToolStripMenuItem2	Name	mnuVentana
	Text	&Ventana
ToolStripMenuItem21	Name	mnuCascada
	MergeIndex	0
	Text	&Cascada
ToolStripMenuItem22	Name	mnuMHorizontal
	MergeIndex	1
	Text	Mosaico &Horizontal
ToolStripMenuItem23	Name	mnuMVertical
	MergeIndex	2
	Text	Mosaico & Vertical
ToolStripMenuItem24	Name	mnuOIconos
	MergeIndex	3
	Text	&Organizar leonos
ToolStripMenuItem3	Name	mnuListar
	Text	&Listar Ventanas
mnuPrincipal	MdiWindowListItem	mnuListar

Nota: La propiedad MdiWindowListItem del control MenuStrip permite mostrar en forma automática un menú con la lista de todas las ventanas hijas abiertas. Para ello debe seleccionar el ToolStripMenuItem en el que se creará la lista.

5. Añadir un segundo formulario; del menú "Proyecto" elegir "Agregar Windows Forms...", escribir como nombre frmHijo y clic en "Agregar".

6. Seleccionar el formulario frmHijo, arrastrar 1 control Label, 1 TextBox y 1 Button, luego configurar sus propiedades, tal como se muestra en el siguiente cuadro:

Objeto	Propiedad	Valor
Form1	Name	frmHijo
	Size	Width=300, Height=200
	Text	Ventana secundaria o MDI Hijo
Label1	Name	lblMensaje
	AutoSize	True
	Location	X=20, Y=20
	Text	Mensaje:
TextBox1	Name	txtMensaje
	Anchor	Top, Left, Right
	Location	X=84, Y=16
	Size	Width=190, Height=20
	Text	Este es un formulario hijo
Button1	Name	btnMensajePadre
	Anchor	Top, Left, Right
	Cursor	Hand
	Location	X=50, Y=56
	Size	Width= 190, Height=23
	Text	Mostrar Mensaje desde el Padre

7. Regresar al formulario frmPadre y en la ventana explorador de soluciones dar clic en el botón "Ver código". 

8. Crear el procedimiento de evento CrearMostrarHijo, que controle el evento "Click" del menú "mnuNuevoHijo", tal como se muestra en el siguiente código: 

9. Crear el procedimiento de evento VerMensajeHijo, que controle el evento "Click" del menú "mnuMensajeHijo", tal como se muestra en el siguiente código: 

Nota:

Para obtener el mensaje escrito en el cuadro de texto del formulario hijo activo usamos la propiedad Text del Control(1) que es el TextBox del objeto ActiveMdiChild que devuelva el formulario hijo activo.

10. Crear el procedimiento de evento OrganizarVentanas, que controle los eventos "Click" de los menús "mnuCascada", "mnuMHorizontal", "mnuMVertical", "mnuOIconos", tal como se muestra en el siguiente código: 

Nota:Para organizar las ventanas hijas dentro del padre usamos el método LayoutMdi() y el valor lo obtenemos de la propiedad MergeIndex de cada menú que lo hicimos coincidir con los valores de la enumeración MdiLayout.

11. Para finalizar la aplicación, creamos el procedimiento de evento Salir, que controle el evento "Click" del menú "mnuSalir", tal como se muestra en el siguiente código: 

12. Regresar al formulario frmHijo y en la ventana explorador de soluciones dar clic en el botón "Ver código". 

13. Crear el procedimiento de evento VerMensajePadre, que controle el evento "Click" del botón "btnMensajePadre", tal como se muestra en el siguiente código: 

14. Configurar frmPadre como el formulario de inicio. Por defecto lo está.

15. Grabar y ejecutar la aplicación pulsando F5 .

Ventana del formulario MDI frmPadre del Ejemplo 27 

16. Del menú "Archivo" seleccionar "Nuevo Hijo" y se verá la figura: 

17. Abrir dos nuevos formularios hijos, seleccionar del menú "Ventana", las opciones "Mosaico Horizontal", "Cascada", "Mosaico Vertical"  y se verá como las siguientes figuras: 

Mosaico Horizontal

Cascada

Mosaico Vertical

Observación:Vea como en el menú "Lista Ventanas" aparece una lista.

18. Escribir un mensaje en cada una, luego ir seleccionando una a una y eligiendo del menú "Archivo", "Mensaje Hijo".

Observación:

Vea como coge el texto escrito en la ventana hija activa y lo muestra en un cuadro de mensaje desde el formulario padre.

19. Maximize la ventana hija y clic al botón "Mostrar mensaje desde el padre".

Observación:

Vea como coge el texto guardado en la propiedad Tag del formulario padre y lo muestra en el cuadro de texto del formulario hijo activo.

20. Finalize la ejecución de la aplicación, del menú "Archivo" elija "Salir".



Espero haber ayudado en algo. Adjunto el ejemplo en el siguiente enlace:

Ejemplo27 - Descargar

Hasta la próxima oportunidad!

Diagramas de casos de uso - Parte 1 de 2

Regresar al índice

El caso de uso es un poderoso concepto que ayuda a un analista a comprender la forma en que un sistema deberá comportarse. Le ayuda a obtener los requerimientos desde el punto de vista del usuario. Es necesario aprender a visualizar los conceptos del caso de uso que conoció en la hora anterior.

En esta hora se tratarán los siguientes temas:

• Representación de un modelo de caso de uso
• Concepción de las relaciones entre casos de uso
• Diagramas de casos de uso en el proceso de análisis
• Aplicación de los modelos de caso de uso
• Vera la idea general del UML

El caso de uso es muy poderoso, pero lo es aún más cuando se visualiza por medio del UML. Esta visualización le permitirá mostrar los casos de uso a los usuarios para que ellos le puedan dar mayor información. Es un hecho que los usuarios con frecuencia saben más de lo que dicen: el caso de uso ayuda a romper el hielo. A su vez, una representación visual le ayuda a combinar los diagramas de casos de uso con otro tipo de diagramas.

Una de las finalidades del proceso de análisis de un sistema es generar una colección de casos de uso. La idea es tener la posibilidad de catalogar y hacer referencia a esta colección, que sirve como el punto de vista de los usuarios acerca del sistema. Cuando llegue el momento de actualizar el sistema, el catálogo de casos de uso funcionará como un fundamento para obtener los requerimientos de la actualización.

Representación de un modelo de caso de uso

Hay un actor que inicia un caso de uso y otro (posiblemente el que inició, pero no necesariamente) que recibirá algo de valor de él. La representación gráfica es directa. Una elipse representa a un caso de uso, una figura agregada representa a un actor. El actor que inicia se encuentra a la izquierda del caso de uso, y el que recibe a la derecha. El nombre del actor aparece justo debajo de él, y el nombre del caso de uso aparece ya sea dentro de la elipse o justo debajo de ella. Una línea asociativa conecta a un actor con el caso de uso, y representa la comunicación entre el actor y el caso de uso. La línea asociativa es sólida, como la que conecta a las clases asociadas.

Uno de los beneficios del análisis del caso de uso es que le muestra los confines entre el sistema y el mundo exterior. Generalmente, los actores están fuera del sistema, mientras que los casos de uso están dentro de él. Utilizará un rectángulo (con el nombre del sistema en algún lugar dentro de él) para representar el confín del sistema. El rectángulo envuelve a los casos de uso del sistema.

Los actores, casos de uso y líneas de interconexión componen un modelo de caso de uso. La figura siguiente le muestra estos símbolos.

En un modelo de caso de uso, una figura agregada representa a un actor; una elipse a un caso de uso y una línea asociativa representa la comunicación entre el actor y el caso de uso.

Una nueva visita a la máquina de gaseosas

Apliquemos los símbolos al ejemplo de la hora anterior. Como recuerda, desarrolló los casos de uso para una máquina de gaseosas. El caso de uso “Comprar gaseosa" se encuentra dentro del sistema junto con “Reabastecer y “Recolectar dinero". Los actores son el Cliente. Representante del proveedor y el Recolector. La siguiente figura le muestra un modelo UML de caso de uso para una máquina de gaseosas.

Un modelo de caso de uso proveniente de la máquina de gaseosas de la hora 6.

Secuencia de pasos en los escenarios

Cada caso de uso es una colección de escenarios y cada escenario es una secuencia de pasos. Como puede ver, tales pasos no aparecen en el diagrama. No se encuentran en notas adjuntas a los casos de uso. Aunque el UML no lo prohíbe, la claridad es clave en la generación de cualquier diagrama y el adjuntar notas a cada caso de uso podría volverlo confuso. ¿Cómo y dónde haría la secuencia de pasos?

El uso de los diagramas de casos de uso será, por lo general, parte de un documento de diseño que el cliente y el equipo de diseño tomarán como referencia. Cada diagrama tendrá su propia página, de igual manera, cada escenario de caso de uso tendrá su propia página, donde se listará en modo de texto a: 

El actor que inicia al caso de uso

Condiciones previas para el caso de uso

Pasos en el escenario

Condiciones posteriores cuando se finaliza el escenario

El actor que se beneficia del caso de uso

También puede enumerar las conjeturas del escenario (por ejemplo, que un cliente a la vez utilizará la máquina de gaseosas) y una breve descripción de una sola frase del escenario.

La hora 6, “Introducción a los casos de uso”, presentó algunos escenarios alternativos del caso de uso “Comprar gaseosa". En su descripción, también podría poner estos escenarios de manera separada (“Sin el producto” y “Cambio incorrecto”), o podría considerarlos como excepciones al primer escenario del caso de uso. La forma exacta de hacerlo sólo le concemirá a usted, su cliente y los usuarios.

Para mostrar los pasos en un escenario, hay otra posibilidad que es utilizar un diagrama de actividades UML sobre el cual hablaremos en la hora 11, Diagramas de actividades".

Concepción de las relaciones entre casos de uso

El ejemplo de la hora 6 también mostró dos formas en que los casos de uso se pueden relacionar entre sí. Una de ellas. la inclusión, le permite volver a utilizar los pasos de un caso de uso dentro de otro. La otra, extensión, le permite crear un caso de uso mediante la adición de pasos a uno existente.

Existen otros dos tipos de relaciones que son generalización y agrupamiento. Como en las clases, la generalización cuenta con un caso de uso que se hereda de otro. El agrupamiento es una manera sencilla de organizar los casos de uso.

• Inclusión

Examinemos los casos de uso “Reabastecer" y “Recolectar dinero" del ejemplo de la hora 6. Ambos se inician mediante la apertura de la máquina, y finalizan con el cierre y sellado de la misma. El caso de uso “Exhibir el interior" se creó para capturar el primer par de pasos; y “Cubrir el interior" para el segundo. Tanto “Reabastecer”, como “Recolectar dinero” incluyen este par de casos de uso.

Para representar a la inclusión utilizará el símbolo que usó para la dependencia entre clases: una línea discontinua con una punta de flecha que conecta las clases apuntando hacia la clase dependiente. Justo sobre la línea, agregará un estereotipo: la palabra “incluir” bordeada por dos pares de paréntesis angulares. La siguiente figura le muestra la relación de «inclusión» en el modelo de caso de uso de la máquina de gaseosas.

Tenga en cuenta que un caso de uso incluido nunca aparecerá solo. Simplemente funciona como parte de un caso de uso que lo incluya.

En la notación de texto que sigue los pasos en la secuencia, indicará los casos de uso incluidos. El primer paso en el caso de uso “Reabastecer” podría ser «incluir» (Exhibir el interior).

El modelo de caso de uso en la máquina de gaseosas con la inclusión.

• Extensión

La hora 6 mostró que el caso de uso “Reabastecer” podría ser la base de otro caso de uso: “Reabastecer de acuerdo a las ventas”. En lugar de sólo reabastecer la máquina de gaseosas para que todas las marcas tengan la misma cantidad de latas, el representante podría anotar aquellas que se venden mejor y reabastecer acorde con ello. Por lo que podemos decir que el nuevo caso de uso extiende al original dado que agrega otros pasos a la secuencia del caso de uso original, que se conoce como el caso de uso base.

La extensión sólo se puede realizar en puntos indicados de manera específica dentro de la secuencia del caso de uso base. A estos puntos se les conoce como puntos de extensión. En el caso de uso Reabastecer, los nuevos pasos (anotar las ventas y abastecer de manera acorde) se darían luego que el representante haya abierto la máquina y esté listo para llenar los compartimientos de las marcas de gaseosas.

En este ejemplo, el punto de extensión es “Llenar los compartimientos”.

Como la inclusión, podrá concebir la extensión con una línea de dependencia (línea discontinua con punta una punta de flecha), junto con un estereotipo que muestra “extender” entre paréntesis angulares. Dentro del caso de uso básico, el punto de extensión aparecerá debajo del nombre del caso de uso. La siguiente figura le muestra la relación de extensión para “Reabastecer” y “Reabastecer de acuerdo a las ventas”, junto con la inclusión de relaciones para “Reabastecer” y “Recolectar dinero”. 

Un diagrama de casos de uso que muestra la extensión y la inclusión.

• Generalización

Las clases pueden heredarse entre sí y esto también se aplica a los casos de uso. En la herencia de los casos de uso, el caso de uso secundario hereda las acciones y significado del primario, y además agrega sus propias acciones. Puede aplicar el caso de uso secundario en cualquier lugar donde aplique el primario. En el ejemplo, deberá imaginar un caso de uso “Comprar un vaso de gaseosa” que se hereda de “Comprar gaseosa”. El caso de uso secundario tiene acciones como “agregar hielo” y “mezclar marcas de gaseosas”. Modelará la generalización de casos de uso de la misma forma que lo hace con las clases: con líneas continuas y una punta de flecha en forma de triángulo sin rellenar que apunta hacia el caso de uso primario, como se muestra en la siguiente figura.

Un caso de uso puede heredar el sentido y comportamiento de otro.

La relación de generalización puede establecerse entre actores, así como entre casos de uso. Quizá tenga personificados al representante del proveedor, al recolector y al agente del proveedor. Si cambia el nombre del representante como Reabastecedor, tanto éste como el Recolector serán secundarios del Agente Proveedor, como muestra la siguiente figura.

Como las clases y los casos de uso, los actores pueden estar en una relación de generalización.

• Agrupamiento

En ciertos diagramas de casos de uso, podría tener varios casos de uso que querrá organizar. Esto puede ocurrir cuando un sistema consta de varios subsistemas. Otra posibilidad sería cuando entrevista a los usuarios para obtener los requerimientos de un sistema. Cada requerimiento podría ser representado como un caso de uso por separado. Necesitará alguna forma de ordenar los requerimientos por categorías. 

La forma más directa de organizar sería agrupar en un paquete los casos de uso que se relacionen. Recuerde que un paquete aparece como una carpeta tabular. Los casos de uso agrupados aparecerán dentro de la carpeta.

Espero haber ayudado en algo. Hasta la próxima oportunidad!

Regresar al índice

Introducción a los casos de uso - Parte 2 de 2

Regresar al índice

Casos de uso adicionales

Ya ha examinado a la máquina de gaseosas desde el punto de vista de un usuario: el cliente. Hay otros usuarios que intervienen, como el proveedor que tiene que reabastecer a la máquina, el recolector de dinero (que tal vez sea el mismo que el proveedor) que tiene que recoger el dinero acumulado en la alcancía de la máquina, etcétera. Esto nos indica que debemos crear al menos dos casos de uso: “Reabastecer" y “Recolectar dinero", cuyos detalles surgirán durante las entrevistas con los proveedores y los recolectores.

Veamos el caso de uso de “Reabastecer”. El proveedor inicia este caso de uso dado que algún intervalo (digamos. dos semanas) ha pasado. El representante del proveedor le quita el seguro a la máquina (tal vez mediante una llave y un cerrojo, pero eso entra dentro de la implementación), jala la puerta para abrir la máquina, y llena el compartimiento de cada marca hasta su capacidad. El representante también rellena la reserva de moneda fraccionaria. Luego, cierra el frente de la máquina y vuelve a poner el seguro. La condición previa es el paso del intervalo, el resultado es que el proveedor cuenta con un nuevo conjunto de ventas potenciales.

Para el caso de uso de “Recolectar el dinero", el recolector inicia debido también a que ha pasado cierto tiempo. La persona deberá seguir la misma secuencia que en “Reabastecer" para abrir la máquina. El recolector sacará el dinero de la máquina y seguirá los pasos de “Reabastecer" para cerrar y poner el seguro a la máquina. La condición previa es el paso del intervalo y el resultado es el dinero en las manos del recolector. 

Vea que cuando derivamos un caso de uso, no nos preocuparnos por la forma de implementarlo. En nuestro ejemplo. no nos interesantes en los aspectos internos de la máquina de gaseosas. Tampoco por la forma en que funcione el mecanismo de refrigeración, o por la forma en que la máquina controle la cantidad de dinero que contenga. Tan sólo intentamos ver la forma en que la máquina lucirá para alguien que tenga que utilizarla.

El objetivo es derivar una colección de casos de uso que, finalmente, mostraremos a las personas que diseñen la máquina de gaseosas y a las personas que la construirán. Por añadidura. nuestros casos de uso reflejan lo que los clientes, recolectores y proveedores desean, por lo que el resultado será una máquina que todos esos grupos puedan utilizar con facilidad.

Inclusión de los casos de uso

En los casos de uso “Reabastecer" y “Recolectar dinero”, tal vez distinguió ciertos pasos en común. Ambos empezaban con abrir la máquina, y finalizaban con el cierre de la máquina y su aseguramiento. ¿Podríamos eliminar la duplicación de pasos de un caso de uso al otro?

Sí podemos. La forma de hacerlo es tomar cada secuencia de pasos en común y conformar un caso de uso adicional a partir de ellos. Combinemos los pasos necesarios para quitar el seguro” y “abrir la máquina" y llamémoslos “Exhibir el interior" y los pasos “cerrar la máquina” y “asegurarla” en otro caso de uso llamado “Cubrir el interior".

Con estos nuevos casos de uso a la mano, el caso de uso “Reabastecer" iniciaría con el caso de uso “Exhíbir el interior". Luego, el representante del proveedor seguiría los pasos ya indicados, y concluiría con el caso de uso “Cubrir el interior". De forma similar, el caso de uso “Recolectar dinero” iniciaría con “Exhibir el interior”, procedería como se indicó, y finalizaría con el caso de uso “Cubrir el interior".

Como ve, “Reabastecer” y “Recolectar dinero" incluyen los nuevos casos de uso. Por ello, a esta técnica de aprovechamiento de un caso de uso se le conoce como inclusión de un caso de uso.

La inclusión de un caso de uso también se conoce como usar un caso de uso. Creo que el término incluir tiene dos ventajas. La primera, es más clara: los pasos en un caso de uso, incluyen los de otro. La segunda, se evita la confusión potencial de las palabras "usar" y "uso" en un contexto tan estrecho. Así, no tendremos que decir "promover el uso mediante el uso reiteratívo de un caso de uso".

Extensión de los casos de uso

Es posible volver a utilizar un caso de uso de una forma distinta a una inclusión. En ocasiones crearemos un caso de uso agregándole algunos pasos a un caso de uso existente.

Regresemos al caso de uso “Reabastecef”. Antes de colocar nuevas latas de gaseosas en la máquina, suponga que el representante del proveedor nota las marcas que se han vendido bien, así como las que no se han vendido tan bien. En lugar de sólo reabastecer todas las marcas, el representante podría sacar aquellas que no se han vendido bien, y reemplazarlas por latas de las marcas que han probado ser más populares. De esta forma, tendría que indicar al frente de la máquina el nuevo surtido de marcas disponibles.

Si agregamos estos pasos a “Reabastecer”, tendremos un nuevo caso de uso que llamaríamos “Reabastecer de acuerdo a las ventas”. Este nuevo caso de uso es una extensión del original, acción a la que se le conoce como extensión de un caso de uso.

Inicio del análisis de un caso de uso

En nuestro caso, nos hemos involucrado directamente con los casos de uso y nos hemos enfocado en algunos de ellos. En el mundo real, por lo general, seguirá un conjunto de procedimientos cuando empiece un análisis de casos de uso.

Empezará con entrevistas a los clientes (y entrevistas con expertos) que lo lleven a los diagramas iniciales de clases que indicamos en la hora 3. Esto le dará cierta idea del área en la que trabajará y una familiaridad con los términos que utilizará. Posteriormente, contará con un fundamento para hablar con los usuarios.

Entrevistará a los usuarios (preferentemente en grupos) y les pedirá que le indiquen todo lo que ellos harían con el sistema que usted diseñará. Sus respuestas conformarán un conjunto candidato de casos de uso. Luego, es importante describir brevemente cada caso de uso. También tendrá que derivar una lista de todos los actores que iniciarán y se beneficiarán de los casos de uso. Cuenta más información obtenga en esta fase, aumentará su aptitud para hablar con los usuarios en su propio idioma.

Los casos de uso aparecerán en varias fases del proceso de desarrollo. Le ayudarán con el diseño de una interfaz del usuario, coadyuvarán con las opciones de desarrollo de los programadores y establecerán las bases para probar el sistema recién generado.

Para mayor información en el tema del análisis de los casos de uso, va a tener que aplicar el UML, y ello se hará en la siguiente hora.

Resumen

El caso de uso es una estructura para describir la forma en que un sistema lucirá para los usuarios potenciales. Es una colección de escenarios iniciados por una entidad llamada actor (una persona, un componente de hardware, un lapso u otro sistema). Un caso de uso debería dar por resultado algo de valor ya sea para el actor que lo inició o para otro.

Es posible volver a utilizar casos de uso. Una forma (“inclusión”) es utilizar los pasos de un caso de uso como parte de la secuencia de pasos de otro caso de uso. Otra forma (“extensión”) es crear un nuevo caso de uso mediante la adición de pasos a un caso de uso existente.

La entrevista directa con los usuarios es la mejor técnica para derivar casos de uso. Cuando se deriva un caso de uso, es importante destacar las condiciones para iniciar el caso de uso, y los resultados obtenidos como consecuencia del mismo.

Hará las entrevistas a los usuarios después de entrevistar a los clientes y generar una lista de prospectos de clases. Esto le dará un fundamento en la terminología que utilizará para hablar con los usuarios. Es una buena idea entrevistar a un grupo de usuarios. El objetivo es derivar un conjunto candidato de casos de uso y todos los posibles actores.

Preguntas y respuestas

P: En realidad ¿para qué necesito el concepto del caso de uso? ¿Qué no sólo podríamos preguntar a los usuarios lo que deseen ver en el sistema y dejarlo así?

R: En realidad, no. Tenemos que crear una estructura de lo que los usuarios nos digan, y los casos de uso la proporcionan. La estructura se vuelve útil cuando tiene que llevar los resultados de sus entrevistas con los usuarios y comunicarlos a los clientes y desarrolladores.

P: ¿Qué tan difícil es derivar los casos de uso?

R: De acuerdo con mi experiencia, el listado de casos de uso -al menos los de alto nivel- no es muy complejo. Hay ciertas dificultades al profundizar en cada una e intentar lograr que los usuarios listen los pasos de cada escenario. Cuando genere un sistema que reemplace una manera existente de hacer las cosas, los usuarios típicamente ya sabrán los pasos bastante bien y los habrán utilizado con tanta regularidad que se les dificultará estructurarlos. Es una buena idea tener un panel de usuarios, ya que la discusión en grupo por lo general trae consigo ideas que un usuario en particular podría tener problemas para expresar.

Taller

Esta hora se basó en teoría más que en el UML. En este taller, el objetivo será comprender los conceptos teóricos y aplicarlos en diversos contextos. La práctica, que veremos en la siguiente hora, le ayudará a reafirmar los conceptos cuando aprenda a visualizarlos mediante el UML. Las respuestas aparecen en el Apéndice A, “Respuestas a los cuestionarios”.

Cuestionario

l. ¿Cómo se llama a la entidad que inicia un caso de uso?

2. ¿Qué se entiende con “incluir un caso de uso”?

3. ¿Qué se entiende con “extender un caso de uso”?

4. ¿Un caso de uso es lo mismo que un escenario?

Ejercicios

1. En el caso del ejemplo de la máquina de gaseosas, cree otro caso de uso que incluya a los casos de uso “Exhibir el interior” y “Cubrir el interior”.

2. Los casos de uso pueden ayudarle a analizar un negocio y un sistema. Imagine a una gran tienda de equipos de cómputo que venda hardware, periféricos y software. ¿Quiénes serían los actores? ¿Cuáles serían algunos de los principales casos de uso? ¿Cuáles serían algunos de los escenarios dentro de cada caso de uso‘? 

Espero haber ayudado en algo. Hasta la próxima oportunidad!

Regresar al índice

Introducción a los casos de uso - Parte 1 de 2

Regresar al índice

Ahora que ha visto lo correspondiente a las clases y sus relaciones, es el momento de volver nuestra atención a otra área principal del UML: los casos de uso.

En esta hora se tratarán los siguientes temas:

• Qué son los casos de uso
• Importancia de los casos de uso
• Inclusión de los casos de uso
• Extensión de los casos de uso
• Inicio de un análisis de un caso de uso

En las tres horas anteriores hemos visto los diagramas que proporcionan una idea estática de las clases en un sistema. Ahora veremos a los diagramas que establecen una idea dinámica y mostraremos la forma en que el sistema y sus clases cambian con el tiempo. Las ideas estáticas ayudan a que un analista se comunique con un cliente. La idea dinámica, como verá, ayudará al analista a comunicarse con un grupo de desarrolladores, y ayudará a estos últimos a crear programas.

El cliente y el equipo de desarrollo conforman un importante conjunto de integrantes en un sistema. No obstante, una parte de igual importancia no se ha tomado en cuenta: el usuario. Ni la idea estática ni la dinámica mostrarán el comportamiento del sistema desde el punto de vista del usuario. Comprender tal punto de vista es clave para generar sistemas que sean tanto útiles como funcionales; esto es, que cumplan con los requerimientos y que sea fácil (e, incluso, divertido) trabajar con ellos.

El modelado de un sistema desde el punto de vista de un usuario es el trabajo de los casos de uso. En esta hora comprenderá todo lo relacionado con los casos de uso y su función. En la siguiente hora aprenderá a utilizar el diagrama de casos de uso del UML para visualizar un caso de uso.


Qué son los casos de uso

Recientemente adquirí una máquina de fax. Cuando fui a comprarla, en un almacén de venta de equipo para oficinas, encontré una enorme gama de opciones. ¿Cómo hice para decidirme por una en particular? Me pregunté exactamente qué es lo que deseaba hacer con una máquina de fax. ¿Qué características deseaba? ¿Cuáles funciones necesitaba que tuviera? ¿Deseaba utilizar papel común o térmico? ¿Quería generar copias? ¿Conectarlo a mi computadora? ¿Utilizarlo como digitalizador? ¿Tendría que enviar faxes a tal velocidad que necesitaría una función de marcado rápido? ¿Querría utilizar la máquina de fax para diferenciar entre una llamada telefónica y un fax entrante?

Todos seguimos un procedimiento como éste cuando realizamos una compra que no sea impulsiva. Lo que hacemos es seguir un tipo de análisis del caso de uso: nos preguntamos cómo utilizaremos el producto o sistema que queremos comprar, de modo que podamos obtener algo que cumpla con nuestras necesidades. Lo importante es saber cuáles son esos requerimientos.

Este tipo de análisis es particularmente crucial para la fase de análisis del desarrollo de un sistema. La forma en que los usuarios utilicen un sistema le da la pauta para lo que diseñará y creará.

El caso de uso es una estructura que ayuda a los analistas a trabajar con los usuarios para determinar la forma en que se usará un sistema. Con una colección de casos de uso se puede hacer el bosquejo de un sistema en términos de lo que los usuarios intenten hacer con él.

Imagínese al caso de uso como una colección de situaciones respecto al uso de un sistema. Cada escenario describe una secuencia de eventos. Cada secuencia se inicia por una persona, otro sistema, una parte del hardware o por el paso del tiempo. A las entidades que inician secuencias se les conoce como actores. El resultado de la secuencia debe ser algo utilizable ya sea por el actor que la inició, o por otro actor.


Importancia de los casos de uso

Así como el diagrama de clases es un buen medio para estimular a un cliente a que hable respecto a un sistema desde su propio punto de vista, el caso de uso es una excelente herramienta para estimular a que los usuarios potenciales hablen, de un sistema, desde sus propios puntos de vista. No siempre es fácil para los usuarios explicar cómo pretenden utilizar un sistema. Puesto que el desarrollo tradicional de los sistemas era, con frecuencia, algo así como una ciencia oculta, con muy poca información para los usuarios, a aquellos que osaban preguntar se les daba información muy poco explícita o ciertamente confusa respecto a lo que utilizarían.

La idea es involucrar a los usuarios en las etapas iniciales del análisis y diseño del sistema. Esto aumenta la probabilidad de que el sistema sea de mayor provecho para la gente a la que supuestamente ayudará, en lugar de ser un manojo de expresiones de computación incomprensibles e inmanejables por los usuarios finales.


Un ejemplo: la maquina de gaseosas

Suponga que empezará a diseñar una máquina despachadora de gaseosas. Para obtener el punto de vista del interesado, entrevistará a varios usuarios potenciales respecto a la manera en que utilizarán dicha máquina.

Dado que la función principal de una máquina de gaseosas es permitir a un cliente adquirir una lata de gaseosa, probablemente las personas le dirán que se enfrentará a diversos escenarios -un caso de uso, en otras palabras- que podría etiquetar como “Comprar gaseosa”. Examinemos cada posible escenario en este caso de uso. Recuerde que tales escenarios podrían aparecer durante la conversación con los usuarios.

Un caso de uso establece un conjunto de escenarios para realizar algo útil para un actor. En este ejemplo, un caso de uso es “Comprar gaseosa".

El caso de uso "Comprar gaseosa"

El actor, en este caso de uso, es un cliente que desea comprar una lata de gaseosa. El escenario iniciará cuando el cliente inserte dinero, posteriormente realizará una selección; y si todo funciona bien, la máquina contará con, al menos, una lata de la gaseosa elegida, misma que pondrá al alcance del cliente.

Además de la secuencia, hay otros aspectos del escenario anterior que merecen cierta consideración. ¿Qué condiciones llevaron al cliente a iniciar el escenario en el caso de uso “Comprar gaseosa"? La sed es la más obvia. ¿Qué se obtiene como resultado de tal escenario? Nuevamente, lo obvio es que el cliente tenga una gaseosa en su poder.

¿Lo que he descrito es la única posibilidad de “Comprar gaseosa”? Habría otras cuestiones que saltarían a la vista; por ejemplo, es posible que la máquina no tenga la gaseosa que desee el cliente; también es posible que el cliente no tenga el importe exacto de la gaseosa. ¿Cómo diseñaría a la máquina de gaseosas para controlar tales escenarios?

Veamos el caso en que la máquina se haya quedado sin gaseosa, otra secuencia de pasos en el caso de uso “Comprar gaseosa”. Imagínelo como una ruta alternativa dentro del caso de uso. El cliente inicia el caso de uso al insertar dinero en la máquina y posteriormente hace una selección. La máquina no cuenta con ninguna lata de la gaseosa seleccionada, por lo que mostrará un mensaje al cliente que indicará que no tiene de esa marca. Lo ideal sería que el mensaje le pida al cliente que haga otra selección. La máquina también debería dar la opción de devolver el dinero al cliente. En este punto, el cliente selecciona otra marca que la maquina entregará (siempre y cuando cuente con provisiones de esta marca), o devolverá el dinero. La condición previa es un cliente sediento y el resultado es una lata de gaseosa o la devolución del dinero.

Claro que el escenario de quedarse sin gaseosa sería posible: el mensaje "No hay de esta marca" podría aparecer en cuanto las provisiones de la máquina se acabaran y permanecer a la vista hasta que la máquina sea reabastecida. En tal caso, el usuario podría no insertar el dinero en primera instancia. El cliente para el que usted diseñará la máquina podría preferir el primer escenario: si el cliente ya insertó dinero, la tendencia podría ser hacer otra selección en lugar de pedir a la máquina que lo devuelva.

Analicemos ahora el escenario de la cantidad de dinero incorrecta. Nuevamente, el usuario inicia el caso de uso en la forma usual y posteriormente hace una selección. Asumamos que la máquina tiene provisión de la marca elegida. En la máquina hay una reserva de moneda fraccionaria y devuelve la diferencia al despachar la gaseosa. Si la máquina no cuenta con una reserva de moneda fraccionaria, devolverá el dinero y mostrará un mensaje que pida al usuario el importe exacto. La condición previa es la ya indicada. El resultado será una lata de gaseosa junto con el cambio, o la devolución del dinero originalmente depositado.

Otra posibilidad es que tan pronto como se agote la moneda fraccionaria, aparezca un mensaje que informe a los clientes que se requiere el importe exacto. El mensaje permanecería a la vista hasta que la máquina sea reabastecida con moneda fraccionaria.

Espero haber ayudado en algo. Hasta la próxima oportunidad!

Regresar al índice

Agregación, composición, interfaces y realización - Parte 2 de 2

Regresar al índice

Interfaces y realizaciones

Una vez que haya creado varias clases, tal vez se dé cuenta que no pertenecen a una clase principal, pero en su comportamiento debe incluir algunas de las mismas operaciones con las mismas firmas de la primera clase. Podría codificar las operaciones en una de las clases y reutilizarlas en otras. Una segunda posibilidad es que desarrolle una serie de operaciones para las clases en un sistema, y reutilizarlas para las clases de otro sistema.

De cualquier manera, deseará contar con algún medio para capturar el conjunto reutilizable de operaciones. La interfaz es la estructura del UML que le permite hacerlo. Una interfaz es un conjunto de operaciones que específica cierto aspecto de la funcionalidad de una clase, y es un conjunto de operaciones que una clase presenta a otras.

Con un ejemplo podríamos aclarar lo anterior. El teclado que usted utiliza para comunicarse con su equipo es una interfaz reutilizable. Su operación basada en la opresión de teclas ha provenido de la máquina de escribir. La disposición de las teclas es casi la misma que en una máquina de escribir, pero el punto principal es que la operación por opresión de teclas ha sido cedida de un sistema a otro. Otras operaciones (Mayús, Bloq Mayús y Tab) también se integraron a partir de la máquina de escribir.

Por supuesto, el teclado de una computadora incluye diversas operaciones que no encontrará en una máquina de escribir: Control, Alt, RePág, AvPág y otras. Así pues, la interfaz puede establecer un subconjunto de las operaciones de una clase y no necesariamente todas ellas.

Puede modelar una interfaz del mismo modo en que modelaría una clase, con un símbolo rectangular. La diferencia será que, como un conjunto de operaciones, una interfaz no tiene atributos. Recordará que puede omitir los atributos de la representación de una clase. ¿Entonces cómo distinguiría entre una interfaz y una clase que no muestra sus atributos? Una forma es utilizar la estructura “estereotipo” y especificar la palabra «interfaz» sobre el nombre de la interfaz en el rectángulo. Otra es colocar la letra “I” al principio del nombre de una interfaz.

En cierto sentido, es como si el teclado de la computadora garantizará que esta parte de su funcionalidad “haría las veces” del teclado de una máquina de escribir. Bajo este esquema, la relación entre una clase y una interfaz se conoce como realización. Esta relación está modelada como una línea discontinua con una punta de flecha en forma de triángulo sin rellenar que adjunte y apunte a la interfaz. La siguiente figura le muestra cómo se lleva a cabo esto.

Una interfaz es un conjunto de operaciones que realiza una clase. Esta última se relaciona con una interfaz mediante la realización, misma que se indica por una línea discontinua con una punta de flecha en forma de triángulo sin rellenar que apunte  la interfaz.

Otra forma (emitida) de representar una clase y su interfaz es con un pequeño círculo que se conecte mediante una línea a la clase, como se ve en la siguiente figura.

La forma omitida de representar una clase que realice una interfaz.

Una clase puede realizar más de una interfaz, y una interfaz puede ser realizada por más de una clase.

Visibilidad

El concepto de visibilidad está muy relacionado con las interfaces y la realización. La visibilidad se aplica a atributos u operaciones, y establece la proporción en que otras clases podrán utilizar los atributos y operaciones de una clase dada (o en operaciones de una interfaz). Existen tres niveles de visibilidad: Nivel público, en el cual la funcionalidad se extiende a otras clases. En el nivel protegido la funcionalidad se otorga sólo a las clases que se heredan de la clase original. En el nivel privado sólo la clase original puede utilizar el atributo u operación. En una televisión, modificarVolumem() y cambiarCanal() son operaciones públicas, en tanto que dibujarlmagenEnPantalla() es privada. En un automóvil, acelerar() y frenar() son operaciones públicas, pero actualizarKilometrajeo o actualizarMillaje() es protegida.

La realización, como podría imaginar, implica que el nivel público se aplique a cualquier operación en una interfaz. La protección de operaciones mediante cualquiera de los otros niveles tal vez no tendría sentido, dado que una interfaz se orienta a ser realizada por diversas clases.

Para indicar el nivel público, anteceda el atributo u operación con un signo de suma (+), para revelar un nivel protegido, antecédalo con un símbolo de número (#), y para indicar el nivel privado, antecédalo con un guión (-). La siguiente figura muestra los atributos y operaciones públicos, protegidos y privados tanto en una televisión como en un automóvil.

Los atributos y operaciones públicos y privados, tanto de una televisión como de un automóvil.

Ámbito

El ámbito es otro concepto referente a los atributos y operaciones, y la forma en que se relacionan dentro de un sistema. Hay dos tipos de ámbitos, el de instancia y el de archivador. En el primero cada instancia cuenta con su propio valor en un atributo u operación. En un ámbito de archivado, sólo habrá un valor del atributo u operación en todas las instancias de la clase. Un atributo u operación con el ámbito de archivador, aparece con su nombre subrayado. Este tipo de ámbito se utiliza con frecuencia cuando un grupo específico de instancias (ningunas otras) tienen que compartir los valores exactos de un atributo privado. El ámbito de instancia es, por mucho, el tipo más común de ámbito.

Resumen

Para completar sus nociones de clases y la forma en que se conectan, es necesario comprender algunas relaciones adicionales. Una agregación establece una asociación para conformar un todo: una clase “todo” se genera de clases que la componen. Un componente en una agregación puede ser parte de más de un todo. Una composición es una conformación muy íntimamente ligada con la agregación en el sentido de que un componente de una composición puede ser parte solamente de un todo. La representación del UML de las agregaciones es similar a la representación de las composiciones. La línea de asociación que une la parte con un todo tiene un rombo. En una agregación, el rombo no está relleno, en tanto que en una composición si lo está.

Un diagrama de contexto enfoca la atención en una clase específica dentro de un sistema. Un diagrama de contexto de composición es como un mapa detallado de un mapa mayor. Muestra un diagrama de clases anidado dentro de un gran símbolo rectangular de clase. Un diagrama de contexto de sistema muestra la forma en que el diagrama de clases compuestas se relaciona con otros objetos del sistema. 

Una realización es una asociación entre una clase y una interfaz. una colección de operaciones que cierta cantidad de clases podrá utilizar. Una interfaz se representa como una clase sin atributos. Para distinguida de una clase cuyos atributos hayan sido omitidos del diagrama, el estereotipo «interfaz» aparecerá por encima del nombre de la interfaz. Otra posibilidad es la de anteceder el nombre de la interfaz con una “I" mayúscula. La realización se representa en el UML mediante una línea discontinua con una punta de flecha en forma de triángulo sin rellenar que conecta a la clase con la interfaz. Otra forma para representar una realización es con una línea continua que conecte a una clase con un pequeño círculo, para que el círculo se interprete como la interfaz.

En términos de visibilidad, todas las operaciones en una interfaz son públicas, de modo que cualquier clase podrá utilizarlas. Los otros dos niveles de visibilidad son protegido (la funcionalidad se extiende a las clases secundarias de aquella que contiene los atributos y operaciones) y privado (atributos y operaciones que se pueden utilizar sólo dentro de la clase que los contiene). Un signo de suma (+) denota a la visibilidad pública, el símbolo de número (#) la protegida y el guión (-) la privada.

El ámbito es otro aspecto de los atributos y operaciones. En un ámbito de instancia, cada objeto de una clase cuenta con su propio valor en un atributo u operación. En un ámbito de archivador, sólo hay un valor para un atributo u operación en particular a través de un conjunto de objetos de una clase. Los objetos que no estén en este conjunto no podrán acceder al valor contenido en el ámbito de archivador.

Preguntas y respuestas

P: ¿Se considera transitiva a la agregación? Es decir, si la clase 3 es un componente de la clase 2, y la clase 2 es un componente de la clase 1, ¿la clase 3 será un componente de la clase 1?

R: Así es. la agregación es transitiva. En nuestro ejemplo, los botones y la bola del ratón son parte del ratón, a la vez que son parte de la computadora.

P: ¿La palabra “interfaz” implica “interfaz de usuario” o GUI? 

R: No. Es algo más genérico. Una interfaz es tan sólo un conjunto de operaciones que una clase presenta a las demás clases. De hecho, una de estas operaciones podría ser (aunque no necesariamente) la del usuario.

Taller

El cuestionario y los ejercicios verificarán y fortalecerán su conocimiento respecto al tema de las agregaciones, composiciones, contextos e interfaces. Las respuestas las podrá ver en el Apéndice A, “Respuestas a los cuestionarios”.

Cuestionario

l. ¿Cuál es la diferencia entre una agregación y una composición?

2. ¿Qué es la realización?

3. Mencione los tres niveles de visibilidad y describa lo que significa cada uno de ellos.

Ejercicios

1. Cree un diagrama de contexto de composición de una revista. Tome en cuenta la tabla de contenido, la editorial, los artículos y las columnas. Luego, cree un diagrama de contexto del sistema que muestre a la revista junto con el suscriptor y el comprador en el puesto de revistas.

2. En la actualidad, el tipo más popular de GUl es la interfaz WIMP (ventanas, iconos, menús y puntero, por sus siglas en inglés). Dibuje un diagrama de clases de la interfaz WIMP, y haga uso de todo el conocimiento adecuado del UML que ha adquirido hasta ahora. Además de las clases indicadas en las siglas, incluya los elementos relacionados como las barras de desplazamiento y el cursor, así como cualquiera de las otras clases necesarias.

Espero haber ayudado en algo. Hasta la próxima oportunidad!

Regresar al índice