Sistemas de Informacin - UML

Unified Modeling Language es el estndar de representacin de diseo orientado a objetos, nacido de las cenizas de OMT, OOSE y Booch. Es la compilacin de un buen nmero de "buenas costumbres" de ingeniera que han tenido xito en el modelado de sistemas grandes y complejos. Breve historia Los lenguajes de modelamiento orientados a objetos aparecieron entre mediados de los 70's y fines de los 80's, debido a dos factores fundamentales: la aparicin de lenguajes orientados a objetos, y la aparicin de aplicaciones cada vez ms complejas. En 1989 haban aproximadamente 10 mtodos orientados a objetos. En 1994 ms de 50. Esta poca fue llamada la "guerra de los mtodos". Entre todos estos mtodos destacaron tres: el de Booch, el OOSE (Object-Oriented Software Engineering) de Jacobson, y el OMT (Object Modeling Technique) de Rumbaugh. Otros mtodos importantes fueron: Fusion, Shlaer-Mellor y Coad-Yourdon. A mediados de los 90's cada autor de los tres mtodos ms reconocidos (Booch, Jacobson y Rumbaugh) empieza a adoptar ideas de los otros 2 mtodos. En 1994 Rumbaugh se une a Booch, y sacan la versin 0.8 de Unified Method, el cual es publicado en 1995. Luego Jacobson se une a Rational, y sacan la versin 0.9 de UML, en junio de 1996. Posteriormente sacan la versin 1.0 en enero de 1997, con la aprobacin de un grupo de empresas llamado OMG (Object Management Group). El lenguaje es abierto a otras empresas, y con nuevas observaciones y recomendaciones sale la versin 1.1 en noviembre de 1997, y la versin 1.2 en junio de 1998. A fines de 1998 sale la actual versin 1.3. Casos de Uso Ningn sistema se encuentra aislado. Cualquier sistema interacta con actores humanos o mecnicos que lo utilizan con algn objetivo. Un caso de uso especifica el comportamiento de un sistema o una parte del mismo, y es una descripcin de un conjunto de secuencias de acciones, donde cada secuencia representa la interaccin de los elementos externos del sistema (sus actores) con el propio sistema. Un caso de uso representa un requerimiento funcional del sistema. Por ejemplo, un caso de uso fundamental en un banco, es el procesamiento de prstamos. Grficamente, los casos de uso se representan mediante elipses.

Los casos de uso se emplean para capturar el comportamiento deseado del sistema en desarrollo, sin tener que especificar cmo se implementa ese comportamiento. Proporcionan un medio para que los desarrolladores, los usuarios finales del sistema y los expertos del dominio lleguen a una comprensin comn del sistema. Adems ayudan a validar la arquitectura y a verificar el sistema mientras evoluciona a lo largo del desarrollo.

Ejemplo: Un juego de dados Se tiene un juego de dados en que un jugador lanza dos dados. Si el total obtenido es siete, el jugador gana, de lo contrario pierde. Caso de uso: Juega un juego. Participantes (actores): Jugador. Descripcin: Este caso de uso comienza cuando el jugador recoge y tira los dados. Si los puntos suman siete, gana y pierde si suman cualquier otro nmero. El diagrama UML correspondiente a este caso de uso sera similar a este:

Cada caso de uso debe tener un nombre que lo distinga de otros casos de uso. Los nombres pueden ser nombres simples o nombres de camino. Estos ltimos constan del nombre del caso de uso, precedido del nombre del paquete en el que se encuentra. Ejemplo:

Un actor representa un conjunto coherente de roles que juegan los usuarios de los casos de uso cuando interactan con stos. Los actores pueden ser personas o sistemas mecnicos. Se pueden definir categoras generales de actores (como cliente en el ejemplo de abajo) y especializarlos (como ClienteComercial) a travs de relaciones de generalizacin. Ejemplo:

Los casos de uso pueden ser versiones especializadas de otros casos de uso, casos de uso incluidos como parte de otros casos de uso, y casos de uso que extienden el comportamiento de otros casos de uso bsicos. Los diagramas de casos de uso se emplean para visualizar el comportamiento del sistema, una parte de el o de una sola clase. De forma que se pueda conocer como responde esa parte del sistema. El diagrama de uso es muy til para definir como debera ser el comportamiento de una parte del sistema, ya que solo especifica como deben comportarse y no como estn implementadas las partes que define. Por ello es un buen sistema de documentar partes del cdigo que deban ser reutilizables por otros desarrolladores. El diagrama tambin puede ser utilizado para que los expertos de dominio se comuniquen con los informticos sin llegar a niveles de complejidad. Un caso de uso especifica un requerimiento funcional, es decir indica esta parte debe hacer esto cuando pase esto. En el diagrama nos encontramos con diferentes figuras que pueden mantener diversas relaciones entre ellas:

Casos de uso: representado por una elipse, cada caso de uso contiene un nombre, que indique su funcionalidad. Los casos de uso pueden tener relaciones con otros casos de uso. Sus relaciones son:
o o o

Include: Representado por una flecha, en el diagrama de ejemplo podemos ver como un caso de uso, el de Crear producto incluye el caso de uso Validar Producto Extends: Una relacin de una caso de Uso A hacia un caso de uso B indica que el caso de uso B implementa la funcionalidad del caso de uso A. Generalization: Es la tpica relacin de herencia.

Actores: se representan por un mueco. Sus relaciones son:

o

Communicates: Comunica un actor con un caso de uso, o con otro actor.

Parte del sistema (System boundary): Representado por un cuadro, identifica las diferentes partes del sistema y contiene los casos de uso que la forman.

En este grafico encontramos tres casos de usos Crear producto utiliza Validar producto, y Crear pack productos es una especializacin de Crear productos.

Organizacin de casos de uso Los casos de uso pueden organizarse agrupndolos en paquetes. Tambin se pueden especificar relaciones de generalizacin, inclusin y extensin. Generalizacin significa que el caso de uso hijo hereda el comportamiento y el significado del caso de uso padre, donde el hijo puede agregar o redefinir el comportamiento del padre. La generalizacin entre casos de uso se representa como una lnea continua con una punta de flecha vaca.

Una relacin de inclusin entre dos casos de uso significa que un caso de uso base incorpora explcitamente el comportamiento de otro caso de uso en el lugar especificado en el caso base. Aqu el caso de uso base toma el comportamiento del caso de uso proveedor. Esta relacin se usa para evitar describir el mismo flujo de eventos repetidas veces, poniendo el comportamiento comn en un caso de uso aparte (que ser incluido por un caso base). Una relacin de inclusin se representa como una dependencia, usando la palabra include. Para especificar la posicin en un flujo de eventos, se usa la palabra include seguido del caso de uso que se quiere incluir. Por ejemplo, para describir el flujo de Seguir pedido: Flujo de eventos principal: Obtener y verificar el nmero de pedido. include (validar usuario). Examinar el estado de cada parte del pedido y preparar un informe para el usuario. Una relacin de extensin entre casos de uso significa que un caso de uso base incorpora implcitamente el comportamiento de otro caso de uso en el lugar especificado indirectamente por el caso de uso que extiende al base. Un caso de uso puede extenderse solamente en ciertos puntos, llamados puntos de extensin. La extensin se puede ver como que el caso de uso que extiende, incorpora su comportamiento en el caso de uso base. Se representa como una dependencia con la palabra extend. Los puntos de extensin slo son etiquetas que pueden aparecer en el flujo del caso de uso base. Por ejemplo, el flujo de Hacer pedido podra escribirse as: Flujo de eventos principal: include (Validar usuario). Recoger los temes del pedido del usuario. (establecer prioridad). Enviar el pedido para ser procesado. Una relacin de extensin se usa para modelar la parte de un caso de uso que el usuario puede ver como comportamiento opcional del sistema. De esta forma se separa el comportamiento opcional del obligatorio. Es decir, un caso de uso base puede, bajo ciertas condiciones, incorporar el comportamiento de otro caso de uso en el lugar especificado.

Modelando el comportamiento de un elemento Por lo general, los casos de uso se utilizan para modelar el comportamiento de un elemento, ya sea un sistema completo, un subsistema o una clase. Es importante centrarse en lo que hace el elemento, no en cmo lo hace. Los casos de uso sirven de base para probar cada elemento segn evoluciona durante el desarrollo. Al probar continuamente cada elemento frente a sus casos de uso, se est validando su implementacin a lo largo del desarrollo. Para modelar el comportamiento de un elemento se debe: - Identificar los actores que interactan con el elemento. - Organizar los actores similares en jerarquas, identificando los roles. - Considerar las formas ms importantes que tiene cada actor de interactuar con el elemento. Tambin hay que considerar las formas excepcionales (puntos de extensin). - Organizar estos comportamientos como casos de uso, usando las reglas de inclusin (para factorizar el comportamiento comn) y de extensin (para distinguir el comportamiento excepcional). Ejemplo 1: Sistema de ventas. Un sistema de ventas debe interactuar con clientes, los cuales efectan pedidos. Adems los clientes pueden hacer un seguimiento de sus propios pedidos. El sistema enva los pedidos y las facturas a los clientes. En algunos casos, segn la urgencia de los clientes, se puede adelantar parte del pedido (pedidos parciales).

Como se muestra en la figura anterior, el comportamiento de este sistema se puede modelar usando los casos de uso Hacer pedido, Seguir pedido, Enviar pedido, Facturar cliente. El comportamiento comn puede factorizarse (Validar cliente) y tambin pueden distinguirse sus variantes (Enviar pedido parcial). Cada caso de uso debe incluir una especificacin de su comportamiento.

Modelado del contexto

Se debe modelar la relacin del sistema con los elementos externos, ya que son estos elementos los que forman el contexto del sistema.

Los pasos a seguir son:

Identificar los actores que interactan con el sistema. Organizar a los actores. Especificar sus vas de comunicacin con el sistema.

Modelado de requisitos
La funcin principal, o la mas conocida del diagrama de casos de uso es documentar los requisitos del sistema, o de una parte de el. Los requisitos establecen un contrato entre el sistema y su exterior, definen lo que se espera que realice el sistema, sin definir su funcionamiento interno. Es el paso siguiente al modelado del contexto, no indica relaciones entre autores, tan solo indica cuales deben ser las funcionalidades (requisitos) del sistema. Se incorporan los casos de uso necesarios que no son visibles desde los usuarios del sistema. Para modelar los requisitos es recomendable:

Establecer su contexto, para lo que tambin podemos usar un diagrama de casos de uso. Identificar las necesidades de los elementos del contexto (Actores). Nombrar esas necesidades, y darles forma de caso de uso. Identificar que casos de uso pueden ser especializaciones de otros, o buscar especializaciones comunes para los casos de uso ya encontrados.

Como podemos ver se incluyen nuevos casos de uso que no son visibles por ninguno de los actores del sistema, pero que son necesarios para el correcto funcionamiento. (WWW.programacin.com)