Lenguaje Unificado De Modelado (UML)

En los principios de la computación, los programadores norealizaban análisis muy profundos sobre el problema porresolver. Si acaso,garabateaban algo en una servilleta. Confrecuencia comenzaban a escribir el programa desde elprincipio, y el código necesario se escribía conforme serequería. Aunque anteriormente esto agregaba un aura deaventura y atrevimiento al proceso, en la actualidad esinapropiado en los negocios de alto riesgo. Hoy en día, esnecesario contar con un plan bien analizado. Un cliente tieneque comprender que es lo que hará un equipo dedesarrolladores; además tiene que ser capaz de señalarcambios si no se han captado claramente sus necesidades (o sicambia de opinión durante el proceso). A su vez, eldesarrollo es un esfuerzo orientado a equipos, por lo quecada uno de sus miembros tiene que saber qué lugar toma sutrabajo en la solución final (así como saber cuál es lasolución en general).

Conforme aumenta la complejidad del mundo, los sistemasinformáticos también deberán crecer en complejidad. En ellosse encuentran diversas piezas de hardware y software que secomunican a grandes distancias mediante una red, rnisma queestá vinculada a bases de datos que, a su vez, contienenenormes cantidades de información. Si desea crear sistemasque lo involucren con este nuevo milenio ¿cómo manejara tantacomplejidad? La clave está en organizar el proceso de diseñode tal forma que los analistas, clientes, desarrolladores yotras personas involucradas en el desarrollo del sistema locomprendan y convengan con él. El UML proporciona talorganización. Rumbaugh, Jacobson y Booch (2000) definen alUML como:…un lenguaje de modelado visual que se usa para especificar,visualizar, construir y documentar artefactos de un sistemade software. Captura decisiones y conocimiento sobre lossistemas que se deben construir. Se usa para entender,diseñar, hojear, configurar, mantener, y controlar lainformación sobre tales sistemas. (p. 3).

Como se mencionó anteriormente con este lenguaje se puedelograr a. Visualizar: permite expresar de forma gráfica un sistemade una manerafácil y versátil, para que una persona (distintaal diseñador y/o programador), lo pueda entender.b.Especificar: permite expresar de manera muy explícita yclara, cuáles son las características de un sistema en laetapa previa a su construcción.c. Construir: es posible que a partir de los modelosdiseñados se pueda construir el sistema diseñado previamente.d. Documentar: maravillosamente todos los diagramas junto consus elementos gráficos sirven como documentación del sistemadiseñado, lo que al mismo tiempo son de utilidad para surevisión y evolución del sistema.

Casos de uso

Los casos de uso son una técnica para la especificaciónde requisitos funcionalespropuesta inicialmente en [Jacobson et al. 1993] y queactualmente forma parte de la propuesta de UML [Booch et al.1999]. Un caso de uso es la descripción de una secuencia deinteracciones entre el sistema y uno o más actores en la que seconsidera al sistema como una caja negra y en la que la quelos actores obtienen resultados observables.Los actores son personas u otros sistemas que interactúan conel sistema cuyos requisitos se están describiendo [ScheneideryWinters 1998].Los casos de uso presentan ciertas ventajas sobre ladescripción meramente textual de los requisitos funcionales[Firesmith 1997], ya que facilitan la elicitación derequisitos y son fácilmente comprensibles por los clientes yusuarios. Además, pueden servir de base a las pruebas delsistema y a la documentación para los usuarios [Weidenhaputet al. 1998]. A pesar de ser una técnica ampliamente aceptada,existen múltiples propuestas para su utilización concreta[Cockburn 1997]. En esta metodología se propone lautilización de los casos de uso como técnica tanto deelicitación como de especificación de los requisitos

funcionales del sistema. Para la descripción concreta de loscasos de uso se proponen plantillas, en las que lasinteracciones se numeran siguiendo las propuestas de[Cockburn 1997], [Scheneider y Winters 1998] y [Coleman 1998]

Diagramas de casos de uso

Los casos de uso tienen una representación gráfica en losdenominados diagramas de casos de uso [Booch et al. 1999]. En estosdiagramas, los actores se representan en forma de pequeñosmonigotes y los casos de uso se representan por elipsescontenidas dentro de un rectángulo que representa al sistema.La participación de los actores en los casos de uso se indicapor una flecha entre el actor y el caso de uso que apunta enla dirección en la que fluye la información. Un ejemplo deeste tipo de diagramas puede verse en la figura. Losdiagramas de casos de uso sirven para proporcionar una visiónglobal del conjunto de casos de uso de un sistema así como delos actores y los casos de uso en los que éstos intervienen.

Las interacciones concretas entre los actores y el sistema nose muestran en este tipo de diagramas. Relaciones entre casos de uso

A veces conviene establecer relaciones entre distintos casosde uso para simplificar su descripción. Las dos relacionesposibles y sus semánticas según [Booch et al. 1999] son lassiguientes, cuya representación gráfica puede verse en elejemplo de la figura � includes: se dice que un caso de uso A incluye el caso de uso B, cuando B es una parte del caso de uso A, es decir, la secuencia de interacciones de B forma parte de la secuencia de interacciones de A. El caso de uso B se realiza siempre dentro del caso de uso A.Además, siempre que ocurre A ocurre también B, por lo que sedice que B es un caso de uso abstracto [Jacobson et al. 1997,Firesmith 1997].Un caso de uso es abstracto si no puede ser realizado por símismo, por lo que sólo tiene significado cuando se utilizapara describir alguna funcionalidad que es común a otroscasos de uso. Por otra parte, un caso de uso será concreto sipuede ser iniciado por un actor y realizado por sí mismo.Se suele utilizar esta relación cuando se detectansubsecuencias de interacciones comunes a varios casos de uso.Dichas subsecuencias comunes se sacan "factor común"de loscasos de uso que las contienen y se les da forma de casos deuso que son incluidos por los casos de uso de los que se han"extraído". De esta forma se evita repetir las mismassubsecuencias de interacciones una y otra vez en varios casosde uso. � extends: un caso de uso A extiende a otro caso de uso B cuando A es una subsecuencia de interacciones de B que ocurre en una determinada circunstancia. En cierta forma, A completa la funcionalidad de B. El caso de usoA puede realizarse o no cuando se realiza el caso de uso B, según se den las circunstancias. Por otro lado, el caso de uso A puede ser un caso de uso abstracto o concreto, en cuyo caso puede ocurrir sin necesidad de que ocurra el caso de usoB.

Organización de casos de uso

En la mayoría de sistemas, el número de casos de uso es losuficientemente elevado como para que sea oportunoorganizarlos de alguna forma en lugar de tener una lista planapor la que no es fácil navegar. Una posible forma deorganizar los casos de uso es recurrir a los paquetes descritosen la propuesta de UML [Booch et al. 1999]. De esta forma, loscasos de uso pueden organizarse en niveles, facilitando asísu comprensión.Cada paquete contiene a otros paquetes o avarios casos de uso.En el caso de que los casos de uso seagrupen por criterios funcionales, los paquetes que losagrupan pueden estereotiparse como subsistemas [Scheneider yWint tal como puede verse en el ejemplo de la figura .

Diagrama de Actividades

El Diagrama de Actividad es una especialización del Diagrama de Estado, organizado respecto de las acciones y usado para especificar:

Un método Un caso de uso

Un estado de actividad representa una actividad: un paso en el flujo de trabajo o la ejecución de una operación. Un grafo de actividades describe grupos secuenciales y concurrentes de actividades. Los grafos de actividades semuestran en diagramas de actividades. Las actividades se enlazan por transiciones automáticas. Cuando una actividad termina se desencadena el paso a la siguiente actividad. Un diagrama de actividades es provechoso para entender elcomportamiento de alto nivel de la ejecución de un sistema, sin profundizar en los detalles internos de los mensajes. Los parámetros de entrada y salida de una acción se pueden mostrar usando las relaciones de flujo que conectan la acción y un estado de flujo de objeto.

Un proceso de negocio (Workflow)

Un grafo de actividades contiene estados de actividad que representa la ejecución de una secuencia en un procedimiento,o el funcionamiento de una actividad en un flujo de trabajo. En vez de esperar un evento, como en un estado de espera normal, un estado de actividad espera la terminación de su cómputo. Cuando la actividad termina, entonces la ejecución procede al siguiente estado de actividad dentro del diagrama.una transición de terminación es activada en un diagrama de actividades cuando se completa la actividad precedente. Los estados de actividad no tienen transiciones con eventos explícitos, peor pueden ser abortados por transiciones en estados que los incluyen.

Un grafo de actividades puede contener también estados deacción, que son similares a los de actividad pero sonatómicos y no permiten transiciones mientras están activos.Los estados de acción se deben utilizar para las operacionescortas de mantenimiento. Un diagrama de actividades puede contener bifurcaciones, asícomo divisiones de control en hilos concurrentes. los hilosconcurrentes representan actividades que se pueden realizarconcurrentemente por los diversos objetos o personas. Laconcurrencia se representa a partir de la agregación, en lacual cada objeto tiene su propio hilo. Las actividadesconcurrentes se pueden realizar simultáneamente o encualquier orden. Un diagrama de actividades es como unorganigrama tradicional, excepto que permite el control deconcurrencia además del control secuencial.

Notación

Un estado de actividad se representa como una caja con losextremos redondeados que contiene una descripción deactividad. Las transacciones simples de terminación semuestran como flechas. Las ramas se muestran como condicionesde guarda en transiciones o como diamantes con múltiplesflechas de salida etiquetadas. Una división o una unión decontrol se representa con múltiples flechas que entran osalen de la barra gruesa de sincronización. Cuando es necesario incluir eventos externos, la recepción de

un evento se puede mostrar como un disparador en unatransición, o como un símbolo especial que denota la esperade una señal. A menudo es útil organizar las actividades enun modelo según su responsabilidad. Esta clase de asignaciónpuede mostrarse organizando las actividades en regionesdistintas separadas por líneas en el diagrama. Debido a suaspecto, esto es conocido como Calles. Un diagrama de actividades puede mostrar el flujo de objetoscomo valores. Para un valor de salida, se dibuja una flechacon línea discontinua desde la actividad al objeto. Para unvalor de entrada, se dibuja una flecha con línea discontinuadesde el objeto a una actividad.

Diagrama de Actividades

Diagramas de Estado

Muestra el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicación, junto con los cambios que permiten pasar de un estado a otro.Los Diagramas de Estado representan autómatas de estados finitos, desde el p.d.v. de los estados y las transiciones. Son útiles sólo para los objetos con un comportamiento significativo. Cada objeto está en un estado en cierto instante. El estado está caracterizado parcialmente por los valores algunos de los atributos del objeto. El estado en el que se encuentra un objeto determina su comportamiento. Cada objeto sigue el comportamiento descrito en el Diagrama de Estados asociado a su clase. Los Diagramas de Estados y escenarios son complementarios, los Diagramas de Estados son autómatas jerárquicos que permiten expresar concurrencia, sincronización y jerarquías de objetos, son grafos dirigidos y deterministas. La transición entre estados es instantánea yse debe a la ocurrencia de un evento.

Estado

Identifica un periodo de tiempo del objeto (no instantáneo) en el cual el objeto está esperando alguna operación, tiene cierto estado característico o puede recibir cierto tipo de estímulos. Se representa mediante un rectángulo con los bordes redondeados, que puede tener tres compartimientos: unopara el nombre, otro para el valor característico de los atributos del objeto en ese estado y otro para las acciones que se realizan al entrar, salir o estar en un estado (entry,exit o do, respectivamente

Eventos

Es una ocurrencia que puede causar la transición de un estadoa otro de un objeto. Esta ocurrencia puede ser una de varias cosas:

Condición que toma el valor de verdadero o falso Recepción de una señal de otro objeto en el modelo Recepción de un mensaje Paso de cierto período de tiempo, después de entrar al

estado o de cierta hora y fecha particular

El nombre de un evento tiene alcance dentro del paquete en elcual está definido, no es local a la clase que lo nombre.

Envío de mensajes

Además de mostrar y transición de estados por medio de eventos, puede representarse el momento en el cual se envían mensajes a otros objetos. Esto se realiza mediante una línea punteada dirigida al diagrama de estados del objeto receptor del mensaje.

Transición simple

Una transición simple es una relación entre dos estados que indica que un objeto en el primer estado puede entrar al segundo estado y ejecutar ciertas operaciones, cuando un evento ocurre y si ciertas condiciones son satisfechas. Se representa como una línea sólida entre dos estados, que puedevenir acompañada de un texto con el siguiente formato:

event-signature "[" guard-condition] "/" action-expression"^"send-clause

event-signature es la descripción del evento que da lugar la transición, guard-condition son las condiciones adicionales al evento necesarias para que la transición ocurra, action-expression es un mensaje al objeto o a otro objeto que se ejecuta como resultado de la transición y el cambio de estadoy send-clause son acciones adicionales que se ejecutan con elcambio de estado, por ejemplo, el envío de eventos a otros paquetes o clases.

Transición interna

Es una transición que permanece en el mismo estado, en vez deinvolucrar dos estados distintos. Representa un evento que nocausa cambio de estado. Se denota como una cadena adicional en el compartimiento de acciones del estado.

Acciones:

Podemos especificar la solicitud de un servicio a otro objetocomo consecuencia de la transición. Se puede especificar el ejecutar una acción como consecuencia de entrar, salir, estaren un estado, o por la ocurrencia de un evento

Generalización de Estados:

Podemos reducir la complejidad de estos

diagramas usando la generalización de estados. Distinguimos así entre superestado y subestados. Un estado puede contener varios subestados disjuntos. Los subestados heredan las variables de estado y las

transiciones externas. La agregación de estados es la composición de un estado a

partir de varios estados independientes.

La composición es concurrente por lo que el objeto estará en alguno de los estados de cada uno de los subestados concurrentes. La destrucción de un objeto es efectiva cuando el flujo de control del autómata alcanza un estado final no anidado. La llegada a un estado final anidado implica la subida al superestado asociado, no el fin del objeto.

Subestados

Un estado puede descomponerse en subestados, con transicionesentre ellos y conexiones al nivel superior. Las conexiones seven al nivel inferior como estados de inicio o fin, los cuales se suponen conectados a las entradas y salidas del nivel inmediatamente superior.

Transacción Compleja

Una transición compleja relaciona tres o más estados en una transición de múltiples fuentes y/o múltiples destinos. Representa la subdivisión en threads del control del objeto ouna sincronización. Se representa como una línea vertical de la cual salen o entran varias líneas de transición de estado.

Transición a estados anidados

Una transición de hacia un estado complejo (descrito medianteestados anidados) significa la entrada al estado inicial del subdiagrama. Las transiciones que salen del estado complejo se entienden como transiciones desde cada uno de los subestados hacia afuera (a cualquier nivel de profundidad).

Transiciones temporizadas

Las esperas son actividades que tienen asociada ciertaduración.

La actividad de espera se interrumpe cuando el eventoesperado tiene lugar.

Este evento desencadena una transición que permite salirdel estado que alberga la actividad de espera. El flujode control se transmite entonces a otro estado.

Diagrama de Estado

DIAGRAMAS DE SECUENCIA

En un diagrama de secuencia se indicarán los módulos o clasesque forman parte del programa y las llamadas que se hacen encada uno de ellos para realizar una tarea determinada. Serealizan diagramas de secuencia para definir acciones que sepueden realizar en la aplicación en cuestión. Así, en el casode una aplicación para jugar al ajedrez, se podrían realizardiagramas de secuencia para “jugar una partida” o bien paraacciones más específicas como “mover pieza”.El detalle que se muestre en el diagrama de secuencia debeestar en consonancia con lo que se intenta mostrar o bien conla fase de desarrollo en la que esté el proyecto, no es lomismo un diagrama de secuencia que muestre la acción de“mover pieza” a otro que sea “mover caballo”, o bien no es lomismo un diagrama de secuencia “mover pieza” que verifiqueciertos parámetros antes de mover como la viabilidad delmovimiento con respecto a una estrategia marcada a unadiagrama que no muestre este nivel de detalle por estar enuna fase inicial de diseño del sistema. El detalle del

diagrama depende de la fase en la que estemos, lo quepretendamos contar con el diagrama y a quién. En una primerafase de diseño podemos poner clases grandes y ficticias, querepresenten un paquete/librería o, si nuestro programa estácompuesto por varios ejecutables corriendo a la vez, inclusoclases que representen un ejecutable. Si estamos en una faseavanzada, estamos diseñando el programa y queremos dejar bienatados los detalles entre dos programadores, que cada uno vaa programar una de las clases o módulos que participan,entonces debemos posiblemente ir al nivel de clase real decodificación y método, con parámetros y todo, de forma quelos programadores tengan claro que métodos van a implementar,qué deben llamar de la clase o módulo del otro, etc. Inclusosi es un diagrama para presentar al cliente, podemos hacer undiagrama de secuencia en el que sólo salga el actor "jugador"y una única clase "juego ajedrez" que representa nuestroprograma completo, de forma que el cliente vea qué datos y enqué orden los tiene que meter en el programa y vea quésalidas y resultados le va a dar el programa. El siguientepuede ser un diagrama de secuencia del ejemplo del ajedrez aun nivel de diseño muy preliminar.

Aquí ya se ha decidido que se van a desarrollar tres librerías/paquetes/módulos, una para la

interface de usuario, otra para contener el tablero y reglas del ajedrez (movimientos válidos y demás) y otra para el algoritmo de juego del ordenador. En el ejemplo se ha utilizado una clase representando cada uno de los paquetes y se ha representado el caso de uso "mover pieza".