UNIVERSIDAD DE EL SALVADOR FACULTAD DE INGENIERIA Y ARQUITECTURA ESCUELA DE INGENIERIA DE SISTEMAS INFORMATICOS HERRAMIENTAS DE PRODUCTIVIDAD

UML ANALISIS ORIENTADO A OBJETOS

CONCEPTUALIZACION
Actor
Un actor es una entidad externa al sistema que necesita intercambiar informacin con el sistema. La notacin utilizada en UML para representar un actor es una figura humana con el nombre del actor.

Caso de uso

A diferencia las tcnicas de anlisis estructurado, el diagrama de casos de uso no persigue modelar un flujo de datos. Un caso de uso puede definirse como un flujo completo de eventos en el que se especifica la interaccin entre el actor y el sistema o como un negocio trabaja actualmente. La ejecucin de un caso de uso termina cuando el actor genere un evento que requiera un caso de uso nuevo.

Extensin
Una extensin indica que la realizacin del caso de uso que extiende no es obligatoria durante la realizacin del caso de uso que est siendo extendido.

En el ejemplo que se muestra, el caso de uso Crear perfil puede o no ser realizado al ejecutarse el caso de uso Registrar usuario.

Inclusin
Una inclusin indica que un caso de uso se realizar incondicionalmente durante la realizacin del caso de uso que lo referencia.

En el ejemplo que se muestra, el caso de uso Autenticar debe ser realizado para que el caso de uso Mostrar contenido sea realizado correctamente.

Clases
Una clase define las caractersticas de un tipo de objeto. Estas caractersticas toman la forma de atributos y operaciones que ese tipo de objetos realiza. Para representar grficamente una clase en el modelo conceptual se utiliza un rectngulo con el nombre. En el diagrama de clases se representa a travs de un rectngulo divido horizontalmente en tres partes: nombre, atributos y operaciones.

Cdigo Java: class Persona{ String nombre; String apellidos; String dui; }

Clase abstracta
Las clases abstractas incorporan un nivel de abstraccin que permite definir un comportamiento especfico a una clase, sin detallar dicho comportamiento. A diferencia de las interfaces, las clases abstractas pueden tener mtodos implementados. La representacin de las clases abstractas es igual que las clases normales, excepto que el nombre se escribe en cursiva.

Cdigo Java: public abstract class Persona { String nombre; String apellidos; String dui; }

Relaciones
Existen 4 tipos de relaciones: composicin, asociacin, uso y herencia. Todas las relaciones describen ciertos detalles que deben ser tomados en cuenta, para hacer una descripcin correcta del modelo.

Navegabilidad
La navegabilidad se refiere al sentido en el que se puede d ar la relacin. En el ejemplo que se presenta, la relacin entre Persona y Empresa, que podra llamarse Trabaja se da de Persona a Empresa. La navegabilidad de las relaciones ayuda a hacer ms clara la semntica del modelo. Sin la navegabilidad, podramos interpretar que la Empresa trabaja para la Persona, lo que tergiversara el significado (semntica) del modelo.

Cdigo Java: public class Persona { Empresa patrono; } public class Empresa { }

Multiplicidad
La multiplicidad se refiere a la cantidad objetos de una clase puede estar relacionados con otra cantidad de objetos de otra clase. Por defecto las relaciones de asociacin no requieren la especificacin explcita de la multiplicidad cuando esta es de 1. Cuando esta cantidad de objetos no es conocida, se puede indicar un rango estimado. Las multiplicidades ms utilizadas son: a) 0..* b) 1..* c) 0..1 d) * ArgoUML no cuenta con la multiplicidad de tipo *, que significa muchos. Para ello es posible usar 1..* 0..*.

Cdigo Java: public class Persona { Empresa patrono; } public class Empresa{ List<Persona> empleados; // Persona[] empleados; es otra alternativa }

Cuando en las relaciones binarias, las clases se relacionan con muchos objetos entre ellos, se est indicando una relacin de muchos a muchos, que en POO es perfectamente describible sin requerir una entidad intermedia a menos que esta relacin incorpore nuevos elementos al modelo. En esos casos son necesarias las clases de asociacin.

Cdigo Java:

public class Persona { List<Empresa> patronos; } public class Empresa{ List<Persona> empleados; }

Rol
El rol se puede definir como las responsabilidades que cumple cada uno de los objetos en la relacin. La interpretacin semntica del modelo que se presenta puede ser ledo de la siguiente manera: Una o varias personas trabajan como empleados para una o varias empresas (sus patronos).

En una relacin con otra entidad, la persona puede jugar otro rol. Por ejemplo, si la entidad persona estuviera relacionada con la entidad Libro, teniendo como rol escritor podramos leer esa relacin como: Una o varias personas, escritores, son los autores de uno o varios libros publicados.

Clases de asociacin
Las clases de asociacin son utilizadas cuando en la asociacin entre dos entidades, es necesario incorporar nuevos atributos producto de esa relacin. Se denota con una clase que se une a la lnea de asociacin a travs de una lnea discontinua.

Cdigo Java: public class Persona{ List<Trabajo> trabajos; } public class Empresa{ } public class Trabajo{ Double salario; }

Composicin
La composicin es una forma de incorporar niveles de abstraccin al modelo. Indica que una clase contiene (o est compuesta por) objetos de otras clases.

A diferencia de la agregacin, la composicin indica que la relacin entre los objetos es de tipo parte/todo. En el ejemplo que se muestra, cuando el objeto de la clase Empleado, que incluye dos objetos (uno de la clase Persona y otro de la clase Puesto), ser destruido cuando el objeto que los contiene sea destruido.

Cdigo Java: public class Empleado{ Persona persona = new Persona(); Puesto puesto = new Puesto(); }

Este tipo de relacin sirve para indicar al programador que los objetos incluidos en el objeto que los contiene, sern referenciados por valor. En leguajes como C++, donde el uso de punteros es fundamental, esta especificacin es til. En lenguajes como Java, donde nicamente los tipos primitivos se referencian por valor, este tipo de relaciones se implementan bajo el supuesto que la misma clase inicializar los objetos que componen el objeto base. Sin embargo, en el transcurso de la ejecucin, a menos que los objetos se declarar como tipo final, es posible asignarles un objeto creado fuera de los mtodos de la clase. Por esta razn, este tipo relaciones son poco usadas en el modelado de objetos cuando se programar en Java o se asume que la composicin y la agregacin tienen el mismo significado.

Agregacin
La agregacin es similar a la composicin. Indica que el objeto de una clase, estar compuesto por objetos de otras clases. A diferencia de la composicin, la agregacin indica que los objetos incluidos en el objeto que los contiene son incluidos por referencia.

En este ejemplo, los objetos de Persona y Puesto que se incluyen en un objeto Empleado, existen indistintamente de que el objeto empleado exista.

Cdigo Java: public class Empleado{ Persona persona; Puesto puesto; }

Herencia
La herencia es otra forma de abstraccin. A la clase base se le llama clase padre, a la clase que hereda se llama clase hija. La clase hija heredar todos los atributos y operaciones de la clase padre que no sean privados.

En el ejemplo, la clase Empleado hereda de la clase Persona y la extiende.

Cdigo Java: public class Persona{ } public class Empleado extends Persona{ }

Uso
La relacin de uso indica que una clase hace uso de otra en un momento determinado. En las relaciones de tipo uso se utilizan la figura de una relacin cliente/servidor. Las clases que usan son llamadas clientes y las clases usadas son llamadas servidores.

Cdigo Java: public class Marcador{ } public class Persona{ public void marcar(){ Marcador marcador = new Marcador(); marcador.registrar(this.codigo, new Date()){ ... } } }

Interfaces
Las interfaces son utilizadas para especificar el comportamiento mnimo que deben cumplir todas las clases que la implementen, sin especificar cmo ser implementado dicho comportamiento. Son una especie de plantilla que debe ser detallado por las clases que las implementan. Esto es usado para garantizar la compatibilidad entre clases, sin limitar sus propias caractersticas. Un ejemplo de esto es la interfaz Iterable, que permite que todas las clases que implementan dicha interfaz puedan ser recorridas por una instruccin de tipo foreach.

Cdigo Java: interface Laboral{ verificarAsistencia(); calcularDescuentos(); } public class Empleado extends Persona implements Laboral{ }

Objeto
La representacin grfica para un objeto consiste en un rectngulo con el nombre del objeto. El nombre del objeto es el mismo nombre de la clase antecedido por dos puntos (:) y subrayado.

Diagrama de secuencia
Los diagramas de secuencia son una representacin de los mensajes que intercambian los objetos en el transcurso del tiempo. En ArgoUML, la notacin de los objetos en el diagrama de secuencia vara en cuanto a que no se subraya el nombre del objeto y la lnea de tiempo de vida del objeto no es discontinua.

ArgoUML

ArgoUML es una herramienta grfica para el diseo de software orientado a objetos. Pretende dar soporte al proceso en las fases de anlisis, diseo, programacin y documentacin. Las caractersticas principales de ArgoUML son: Estndares abiertos: XMI (XML Metadata Interchange), SVG (Scalable Vector Graphics), PGML (Precision Graphics Markup Lenguage). 100% independiente de la plataforma, gracias al uso exclusivo de Java para su desarrollo. Open source Caractersticas cognitivas como: reflexin en la accin, diseo oportunista y, comprensin y resolucin de problemas. Para detalles sobre la instalacin y configuracin de ArgoUML consulte la gua rpida en el sitio oficial: http://argouml.tigris.org/.

EL ENTORNO DE ArgoUML

1 2 3

La ventana principal de ArgoUML consta de: 1. Una barra de men 2. Una barra de Herramientas 3. Panel de Herramientas de Diagramas 4. rea de trabajo 5. Opciones y elementos de Diagramas 6. Navegacin de Proyectos y Archivos

Utilizaremos un ejemplo para hacer una descripcin de las funciones ms importantes de ArgoUML.

SISTEMA DE TRANSACCIONES BANCARIAS EN LINEA

DESCRIPCION DEL SISTEMA

Se requiere un sistema que permita a un cliente de una banco realizar transacciones bancarias en lnea. Una vez que el usuario ingrese sus credenciales de acceso, si las credenciales son vlidas, el sistema deber desplegar el contenido principal del sistema. El contenido principal es un men de opciones y un lista de cuentas asociadas al cliente. El cliente podr ver los detalles de la cuenta seleccionndola de la lista de cuentas mostradas en el contenido principal. Como parte de los detalles debe mostrarse una opcin para consultar los movimientos de la cuenta. Para realizar una transaccin el cliente deber seleccionar una de las opciones del men, donde posteriormente debe seleccionar la cuenta con la que desea realizar dicha transaccin. Al realizar una transaccin, el sistema debe validar que la cuenta que est siendo cargada (a la que se le est restando de su saldo) tenga suficiente saldo para poder ser cargada.

CASOS DE USO
Actores
Cliente

Casos de uso
Iniciar sesin Consultar cuenta Iniciar transaccin Consultar movimientos

Diagrama de casos de uso

Antes de iniciar la creacin del Diagrama de casos de uso, iniciaremos con dar el nombre a nuestro modelo. Para ello hacemos clic en nodo Modelo sin ttulo del panel de navegacin de objetos. En la pestaa Propiedades del panel de detalles escribimos el nombre Sistema de transacciones bancarias. Ntese que en el panel de tareas se agrega una tarea pendiente de prioridad media. Al revisar la tarea nos indica que el nombre no es adecuado, puesto que ese nombre se convertir posteriormente en un nombre de paquete.

Al hacer clic en el botn siguiente, nos permitir cambiar el nombre a bancaenlinea. Ahora ya tenemos el nombre del paquete ingresado de forma correcta.

Ntese que ArgoUML nos advertir de cualquier inconsistencia de nuestro modelo a travs de Crticas, que irn apareciendo en el panel de tareas.

Ahora para crear un diagrama de casos de uso, seleccione el directorio raz y con el botn derecho elija la opcin Crear diagrama y luego de clic en Diagrama de casos de uso para crear el diagrama.

Para crear el diagrama de casos de uso, iniciamos agregando el actor identificado.

Al agregar el actor, se puede observar que se activan varias de las pestaas del pan el de detalles. Las pestaas del panel de detalles se activan segn el componente que se seleccione en el diagrama. Revisaremos las pestaas ms importantes que se tienen disponibles para los actores.

La pestaa ms importante de todos los objetos es la de propiedades. En esta pestaa podemos agregar el nombre del actor, en este caso Cliente. La pestaa Documentacin nos permite ir documentando los diagramas. En este ejemplo nicamente agregaremos el autor y la versin del modelo.

ArgoUML trae consigo un generador de cdigo a partir de los modelos. En el desarrollo del ejercicio veremos cmo los diagramas van integrndose de forma consistente, que junto a la funcin de generador de cdigo puede producir una base de implementacin del cdigo del modelo.

Puede observarse que la pestaa de cdigo del actor genera una clase con el mismo nombre. En general, se considera que los actores no deberan ser clases del modelo. Sin embargo, dependiendo del problema esto puede ser necesario. En la opcin Operaciones de la pestaa Propiedades, es posible incorporar operaciones al actor. Esto no necesariamente se convertir en un mtodo de la clase. Es ms, el actor no necesariamente se convertir en una clase del modelo.

ArgoUML adems nos provee de una lista de control de calidad del modelado. La pestaa Lista de control realiza una serie de preguntas que permiten afinar el modelado. Estas preguntas no tienen ningn impacto directo en el modelo en el que se est trabajando, simplemente es una ayuda que nos provee ArgoUML para verificar la validez del modelo.

Ahora podemos agregar un caso de uso al modelo. Seleccionamos la elipse que se encuentra en la barra de objetos del panel de edicin.

De la misma forma que con el actor, varias de las pestaas del panel de detalles se activan al seleccionar el caso de uso recin ingresado. Le damos el nombre al caso de uso: Iniciar sesin. Ntese que tambin los casos de uso pueden ser concebidos como una clase en ArgoUML, por lo que es posible definir operaciones.

En la pestaa de cdigo fuente tambin se encontrar cdigo generado, que supone tambin que se

trata de una clase. Usualmente los casos de uso no se convierten en una clase en el modelo de clases. Generalmente, esto depende del nivel de detalle con el que se aborde el problema, y cuando esto ocurre, es una seal de que es necesaria una iteracin de afinamiento para ahondar ms en los detalles del problema. Ahora es necesario establecer la relacin entre el caso de uso y el actor. Para ello se utiliza el icono de asociacin que se encuentra en la barra de objetos del panel de edicin. Una vez incorporada la asociacin entre el actor y el caso de uso, podemos darle un nombre a la asociacin. En este caso Ingresar credenciales.

En una primera mirada, podramos pensar que los casos de uso identificados son disparados por el usuario, de tal manera que el diagrama de casos de uso quedara como se muestra en el diagrama 1

Diagrama 1

Anlisis
Hemos identificado ya una serie de casos de uso que se requieren en el sistema. Es importante entender la relacin que existe entre los casos de uso y los actores, o entre los casos de uso mismos. Las relaciones entre los actores y los casos de uso resultan relativamente fciles de advertir. Sin embargo, las relaciones entre los casos de uso es algo que requiere de un anlisis ms detallado. Cuando un usuario use (o realice) el caso de uso Iniciar sesin, si el nombre de usuario y clave son correctas, el sistema deber mostrar las opciones del sistema y las cuentas de ese usuario. Si las credenciales no son correctas, el sistema deber mostrar un mensaje de error al usuario. Para que un cliente realice el caso de uso Consultar movimiento, el sistema debera brindar una forma en la que el cliente seleccione la cuenta de la que desea hacer una consulta. Sin embargo, esto solo puede hacerse si ha iniciado la sesin. Con eso podemos asumir que al iniciar la sesin, el sistema mostrar las cuentas bancarias. Algo similar ocurre con las opciones del sistema, por ejemplo realizar un pago. Al realizar una transaccin satisfactoriamente, podramos dar al cliente la posibilidad de regresar a la pantalla principal del sistema, donde se muestra la lista de cuentas relacionadas.

Podemos asumir que por tratarse de un men, las opciones del sistema siempre estarn disponibles para el usuario. Para hacer esto posible, haremos una modificacin en el modelo de comportamiento que tenemos hasta ahora, separando segmentos de los casos de uso que tenemos hasta ahora, para poder reutilizarlos en cualquier momento. Podemos observar que una vez que el cliente haya iniciado sesin, el sistema puede mostrarle las opciones del sistema y las cuentas de las que es dueo. La posibilidad est condicionada a que el inicio de sesin haya sido exitoso, por esta razn estos casos de uso son extensiones del caso de uso Iniciar sesin. Lo mismo hasta que permitir tambin a podemos presumir del caso de uso Consultar movimientos, ya que es el cliente realice el caso de uso Consultar cuenta, el sistema le elegir el caso de uso Consultar movimientos, que permitir regresar la pantalla principal del sistema.

Diagrama 2

ACTIVIDADES
El diagrama de actividades tiene como objetivo ayudarnos a conocer lo que se espera que ocurra al interior de cada uno de los casos de uso. Los diagramas de actividades describen procesos, por lo que en un diagrama puede describirse el comportamiento de uno o ms casos de uso.

Una vez agregado el diagrama, nos aparecer un nodo con el nombre Sin nombre ActivityGraph. Al seleccionarlo se activan las pestaas aplicables en el panel de detalles. En la pestaa nombre agregamos el nombre Ingreso al sistema. Dentro del nodo del diagrama que acabamos de agregar se mostrarn los objetos que vayamos agregando a ese diagrama. Por defecto ArgoUML ingresa un objeto con el nombre bancaenlinea activity 1, que podemos cambiar a bancaenlinea ingreso al sistema. Ahora podemos incorporar los objetos que contendr el diagrama. Como es lgico iniciaremos con el objeto de inicio, posteriormente ingresamos la actividad Ingresar al sistema, posteriormente la actividad Ingresa credenciales y finalmente los nodos de inicio de acuerdo al flujo de eventos que deben ir ocurriendo.

Procesos: Ingreso al sistema

El proceso inicia con el hecho de que el usuario ingresa al sistema. El sistema muestra la pantalla correspondiente para que posteriormente, el usuario ingrese las credenciales de acceso al sistema. Si las credenciales son correctas, el proceso termina. Si no son correctas, el sistema solicita al usuario que repita el ingreso de sus credenciales. En ese punto, el usuario puede intentarlo de nuevo o finalizar el proceso. Puede notarse que esta descripcin de los procesos nos servir para identificar el curso de eventos de los casos de uso involucrados en el proceso. Eso nos servir para construir los casos de uso extendidos del sistema.

Proceso: Consulta de cuentas

Proceso: Transaccin

EJERCICIOS
1. Elabore los casos de uso extendidos del ejemplo desarrollado en esta gua. 2. Realice un anlisis para el sistema descrito a continuacin.

SISTEMA DE PAGOS Se requiere un sistema para el control de los pagos que se realizan en una institucin. El gestor de pagos podr ingresar los datos de pago que incluyen el monto a pagar, el concepto de pago, el nombre del cobrador del documento de pago y la fecha. Los documentos de pago solo pueden ser autorizados por el jefe de la unidad de finanzas de la institucin. Para ello el jefe de finanzas debe contar con una opcin de consulta de los pagos pendientes de autorizacin y tener la capacidad de autorizarlos o denegar su realizacin. El gestor de pagos podr consultar todos aquellos pagos que ya han sido autorizados y tener la capacidad para imprimirlos en forma de cheques. Realice: Diagrama de casos de uso Diagrama de actividades Casos de uso extendidos