Exposicin

UML es un lenguaje estndar que sirve para escribir los planos del software, puede utilizarse para visualizar, especificar, construir y documentar todos los artefactos que componen un sistema con gran cantidad de software. UML puede usarse para modelar desde sistemas de informacin hasta aplicaciones distribuidas basadas en Web, pasando por sistemas empotrados de tiempo real. UML es solamente un lenguaje por lo que es slo una parte de un mtodo de desarrollo software, es independiente del proceso aunque para que sea optimo debe usarse en un proceso dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental. UML es un lenguaje que nos ayuda a interpretar grandes sistemas mediante grficos o mediante texto obteniendo modelos explcitos que ayudan a la comunicacin durante el desarrollo ya que al ser estndar, los modelos podrn ser interpretados por personas que no participaron en su diseo (e incluso por herramientas) sin ninguna ambigedad.

DIAGRAMAS
De secuencia: representacin temporal de los objetos del sistema y sus interacciones. De colaboracin: son una representacin espacial de los objetos, enlaces e interacciones. De clases: representan la estructura esttica en trminos de clases y relaciones; De actividades: representan el comportamiento de una operacin en trminos de acciones; De Estados: representan el comportamiento de una clase en trminos de estados. De componentes: representan los componentes fsicos de una aplicacin. De despliegue: representan el despliegue de los componentes sobre los dispositivos materiales.

Casos de Uso
Muestra las distintas operaciones que se esperan de una aplicacin o sistema y cmo se relaciona con su entorno (usuario u otras aplicaciones). Permite definir los lmites del sistema y las relaciones entre el sistema y el entorno. Es una herramienta esencial para la captura de requerimientos y para la planificacin y control de un proyecto interactivo. Los casos de Uso se representan en el diagrama por una elipse que denota un requerimiento solucionado por el sistema. Cada caso de uso de uso es una operacin completa desarrollada por los actores y por el sistema en un dilogo. El conjunto de casos de uso representa la totalidad de operaciones desarrolladas por el sistema. Un factor clave al definir casos de uso es que no se especifica cmo se implementan. Los casos de uso especifican un comportamiento deseado, no imponen cmo se llevar a cabo ese comportamiento.

La terminologa empleada en la redaccin de los casos de uso es la empleada por los usuarios en su quehacer cotidiano, de modo que la expresin de las necesidades se facilita en gran medida.

Elementos Bsicos
Actor: Es un usuario del sistema, que necesita o usa alguno de los casos de uso. Un usuario puede jugar ms de un rol. Un solo actor puede actuar en muchos casos de uso; recprocamente, un caso de uso puede tener varios actores. Los actores no necesitan ser humanos pueden ser sistemas externos que necesitan alguna informacin del sistema actual.
y Actor Activo: Los actores Activos inician la interaccin con el sistema. Esto puede ser mostrado colocando una flecha en la asociacin desde el actor apuntando hacia el caso de uso. Actor Pasivo: La interaccin con los actores pasivos es iniciada por el sistema. Esto puede ser mostrado colocando una flecha en la asociacin desde el caso de uso apuntando hacia el actor

Caso de uso: Es una tarea que debe poder llevarse a cabo con el apoyo del sistema que se est desarrollando. Se representan mediante un valo. Cada caso de uso debe detallarse, habitualmente mediante una descripcin textual. Asociaciones: Hay una asociacin entre un actor y un caso de uso si el actor interacta con el sistema para llevar a cabo el caso de uso. Tipos: Include: Se puede incluir una relacin entre dos casos de uso de tipo include si se desea especificar comportamiento comn en dos o ms casos de uso. El actor que realiza el caso de uso base tambin realiza el caso de uso incluido. Extends: Relacin de dependencia entre dos casos de uso que denota que un caso de uso es una especializacin de otro. Un actor que realiza el caso de uso base puede o no realizar sus extensiones. Generalizaciones: En un diagrama de casos de uso tambin pueden mostrarse generalizaciones (relaciones de herencia) para mostrar que diferentes elementos estn relacionados como tipos de otros. Son aplicables a actores o casos de uso, pero para estos ltimos la semntica es muy similar a las relaciones Extends. Las asociaciones no son obligatorias. Si en un diagrama de casos de uso aparece una asociacin entre un actor y un caso, indica que puede que ese actor interacte con el sistema en ese caso de uso. Escenario: Es una interaccin entre el sistema y los actores, que puede ser descrito mediante una secuencia de mensajes. Un caso de uso es una generalizacin de un escenario. Todos los escenarios de un caso de uso deben tener en comn que son intentos de hacer esencialmente lo mismo, en este caso llevarse un libro en prstamo. Los escenarios pueden y deben posteriormente documentarse mediante diagramas de secuencia. Multiplicidad: Muestra la multiplicidad de asociaciones entre actores y casos de uso. Con esto queremos decir cuntas instancias de un actor interacciona con cuantas instancias del caso de uso.

Por defecto asumimos que una instancia de un actor interacciona con una instancia de un caso de uso. En otros casos podemos etiquetar la multiplicidad de un extremo de la asociacin, una de dos con un nmero para indicar cuantas instancias estn involucradas, o con un rango separado por dos puntos (..). Un asterisco (*) es usado para indicar un nmero arbitrario. La multiplicidad puede abarrotar un diagrama, y a menudo no se muestra, excepto donde es crtico comprenderlo. En el ejemplo de Cajero Automtico solo elegiramos mostrar 1..3 contra el oficial del banco, ya que todos los dems son obvios por el contexto.

Lmites del Sistema: Resulta til dibujar los lmites del sistema cuando se pretende hacer un diagrama de casos de uso para parte del sistema.

Documentacin del caso de uso

Cada caso de uso se documenta por una descripcin del escenario. La descripcin puede ser escrita en modo de texto o en un formato paso a paso. Cada caso de uso puede ser tambin definido por otras propiedades, como las condiciones pre- y post- del escenario --- condiciones que existen antes de que el escenario comience, y condiciones que existen despus de que el escenario se completa. Los Diagramas de Actividad ofrecen una herramienta grfica para modelar el proceso de un Caso de Uso. Cada caso de uso debe ser documentado para explicar en detalle el comportamiento que est especificando. Este documento es conocido por diferentes nombres en diferentes procesos: especificacin de caso de uso, escenario de caso de uso o incluso (confusamente) solo caso de uso. Esta documentacin incluye: Nombre. El nombre del caso de uso al que esto se refiere. Objetivo. Un resumen de lo que realiza este caso de uso por sus actores. Actores. Los actores involucrados en este caso de uso. Pre y Post Condiciones. Flujo Bsico. La secuencia lineal de pasos que describen el comportamiento del caso de uso en el escenario normal. Flujos Alternativos. Unas series de secuencias lineales describiendo cada uno de los comportamientos alternativos al flujo bsico. Requerimientos.

Usos Comunes
1. Para modelar el contexto de un sistema. Modelar el contexto de un sistema implica dibujar una lnea alrededor de todo el sistema y asegurar qu actores queda fuera del sistema e interactan con l. Aqu, se emplearn los diagramas de casos de uso para especificar los actores y significado de sus roles. Para modelar el contexto de un sistema:  Hay que identificar los actores en torno al sistema, considerando qu grupos requieren ayuda del sistema para llevar a cabo sus tareas; qu grupos son necesarios para ejecutar las funciones del sistema; qu grupos interactan con el hardware externo o con otros sistemas software; y qu grupos realizan funciones secundarias de administracin y mantenimiento.  Hay que organizar los actores similares en jerarquas de generalizacin / especializacin.  Hay que proporcionar un estereotipo para cada uno de esos actores, si as se ayuda a entender el sistema.  Hay que introducir esos actores en un diagrama de casos de uso y especificar las vas de comunicacin de cada actor con cada uno de los casos de uso del sistema.

Por ejemplo, la figura muestra el contexto de un sistema de validacin de tarjetas de crdito, destacando los actores en torno al sistema. Se puede ver que existen Clientes, de los cuales hay dos categoras (Cliente individual y Cliente corporativo). Estos actores representan los roles que juegan las personas que interactan con el sistema. En este contexto, tambin hay actores que representan a otras instituciones tales como Comercio (que es donde los Clientes realizan una transaccin con tarjeta para comprar un artculo o servicio) y Entidad Financiera (que presta servicio como sucursal bancaria para la cuenta de la tarjeta de crdito). En el mundo real estos dos actores probablemente sean sistemas con gran cantidad de software.

2. Para modelar los requisitos de un sistema. El modelado de los requisitos de un sistema implica especificar qu debera hacer el sistema (desde un punto de vista externo), independientemente de cmo se haga, se puede ver qu hay fuera del sistema y cmo reacciona a los elementos externos, pero no se puede ver cmo funciona por dentro. Un requisito es una caracterstica de diseo, una propiedad o un comportamiento de un sistema. Cuando se enuncian los requisitos de un sistema se est estableciendo un contrato entre los elementos externos al sistema y el propio sistema, que establece lo que se espera que haga el sistema. La mayora de las veces no importa cmo lo hace, slo importa que lo haga. Un sistema con un comportamiento correcto llevar a cabo todos sus requisitos de manera fiel, predecible y fiable. Los requisitos se pueden expresar de varias formas, desde texto sin estructurar hasta expresiones en lenguaje formal, y en cualquier otra forma intermedia. La mayora de los requisitos funcionales de un sistema, si no todos, se pueden expresar con casos de uso, y los diagramas de casos de uso de UML son fundamentales para manejar esos requisitos. Para modelar los requisitos de un sistema:  Hay que establecer el contexto del sistema, identificando los actores a su alrededor.  Hay que considerar el comportamiento que cada actor espera del sistema o requiere que ste le proporcione.

 

Hay que nombrar esos comportamientos comunes como casos de uso. Hay que factorizar el comportamiento comn en nuevos casos de uso que puedan ser utilizados por otros; Hay que factorizar el comportamiento variante en otros casos de uso que extiendan los flujos principales. Hay que adornar esos casos de uso con notas que enuncien los requisitos no funcionales; puede que haya que asociar varias de esas notas al sistema global.

La figura extiende la anterior, aunque omite las relaciones entre los actores y los casos de uso, aade casos de uso adicionales que son invisibles para el cliente normal, aunque son comportamientos fundamentales del sistema. Este diagrama es valioso porque ofrece un punto de vista comn para los usuarios finales, los expertos del dominio y los desarrolladores para visualizar, especificar, construir y documentar sus decisiones sobre los requisitos funcionales del sistema. Por ejemplo, Detectar fraude de tarjeta es un comportamiento importante tanto para el Comercio como para la Entidad Financiera. Anlogamente, Informe estado de Cuentas, es otro comportamiento requerido del sistema por varias entidades.

Creacin de Casos de uso

Cmo encontrar un actor?
y

y y

Identifique los usuarios del sistema o Por qu se disea el sistema? o Cules son los actores que el sistema va a beneficiar? o Qu actores van a interactuar directamente con el sistema? (actores primarios) o Qu actores van a supervisar, mantener, recibir informacin del sistema? (actores secundarios) Identifique los roles que juegan esos usuarios desde el punto de vista del sistema Identifique otros sistemas con los cuales exista comunicacin

Cmo encontrar un caso de uso? Identifique las operaciones importantes del sistema a construir Cules son las principales tareas de un actor? Qu informacin tiene el actor que consultar, actualizar, modificar? Cmo? Qu cambios del exterior debe informar el actor al sistema? Qu informacin debe informrsele al actor, con respecto a los cambios del sistema? Cmo encontrar relaciones entre actores y casos de uso? Identifique los casos de uso en los cuales se ve implicado un actor Busque relaciones extends entre casos de uso Qu casos de uso son similares, diferencindose en la forma en la cual hacen algunas operaciones? Qu caso de uso redefine la forma en la cual se realiza una transaccin dentro de otro caso de uso? Busque relaciones uses entre casos de uso Qu casos de uso son usados como transacciones de otros?