UML

Contextualización

y Conceptualización
Es el lenguaje de modelado de sistemas de software más
conocido y utilizado en la actualidad; está respaldado por el
OMG (Object Management Group).
En la actualidad, UML ("Unified Modeling Language"),
Lenguaje de Modelado Unificado, es considerado como
el lenguaje de notación estándar en el análisis y diseño
de sistemas de información, mediante UML es posible
establecer los requerimientos y las estructuras
necesarias, que sirve como insumo previo al proceso de
escribir código.
El Lenguaje de Modelamiento Unificado (UML - Unified
Modeling Language) es un lenguaje gráfico para visualizar,
especificar y documentar cada una de las partes que
comprende el desarrollo de software.

UML entrega una forma de

modelar cosas conceptuales como
lo son procesos de negocio y
funciones de sistema, además de
cosas concretas como lo son
escribir clases en un lenguaje
determinado, esquemas de base de
datos y componentes de software
reusables.
Se utiliza cuando se quiere documentar un
proceso de desarrollo de software, con el
objetivo de que si alguna de las personas
involucradas en el proyecto abandonan el
mismo, no perder la continuidad del proceso
o si se requiere hacer modificaciones es
mucho más fácil si se encuentra
documentado
El lenguaje unificado de diagrama o notación
(UML) sirve para especificar, visualizar y
documentar esquemas de sistemas de software
orientado a objetos.

UML no es un método de desarrollo, lo que

significa que no sirve para determinar qué hacer
en primer lugar o cómo diseñar el sistema, sino
que simplemente le ayuda a visualizar el diseño
y a hacerlo más entendible para otros.
Los casos de uso son una técnica para especificar el
comportamiento de un sistema: Un caso de uso es una
secuencia de interacciones entre un sistema y alguien o algo
que usa alguno de sus servicios

Un diagrama de casos de uso es una forma simple de

presentar una visión general de los requisitos de un sistema

En ingeniería del software, un caso de uso es una técnica

para la especificación de requisitos potenciales para un nuevo
sistema o una actualización de software
Es importante resaltar que los diagramas de casos de
uso no están pensados para representar el diseño y
no puede describir los elementos internos de un
sistema.
Los diagramas de casos de uso sirven para facilitar la
comunicación con los futuros usuarios del sistema, y
con el cliente, y resultan especialmente útiles para
determinar las características necesarias que tendrá el
sistema. En otras palabras, los diagramas de
casos de uso describen qué es lo que debe
hacer el sistema, pero no cómo.
Un diagrama de casos de uso consta de los
siguientes elementos:
Se representa por un muñeco, puede
ser un usuario, una máquina, un
sistema externo, con el cual interactúa
el sistema que se modela

Los actores resuelven la pregunta de quién y que interactúa

con el sistema, puede ser una persona, una máquina, una base
de datos, un sistema de información etc... Los actores
representan papeles denominados (ROLES) que interpretan
personas, periféricos u otros sistemas cuando el sistema está
en uso.
 Identificar a los actores es el primer paso para
usar la técnica de casos de uso. Por ejemplo,
en un sistema de pedidos, sin conocer
prácticamente ningún detalle sobre cómo
funcionará, podemos decir que:

El grupo de usuarios El grupo de usuarios

que ingrese pedidos que haga otras Todo grupo de usuarios que
al sistema será un operaciones con los reciba ciertos informes del
actor pedidos, como por sistema, como por ejemplo
ejemplo autorizarlos, estadísticas de ventas, será un
cancelarlos y modificar actor
sus plazos de entrega,
será un actor.
Se representa gráficamente
como una elipse, debe contener
un nombre el cual debe describir
o indicar claramente la función
del mismo, estos pueden tener
relaciones con otros casos de
uso.
Un caso de uso es una
secuencia de
interacciones entre un
sistema y alguien o algo
que usa alguno de sus
servicios
 Relaciones……
Asociación
Es el tipo de relación más básica que indica la invocación desde
un actor o caso de uso a otra operación (caso de uso). Dicha
relación se denota con una flecha simple.

Dependencia o Instanciación
Es una forma muy particular de relación entre clases, en la cual
una clase depende de otra, es decir, se instancia (se crea).
Dicha relación se denota con una flecha punteada.
 Relaciones……
<<include>> que especifica una situación en la que un caso
de uso tiene lugar dentro de otro caso de uso

Utilice una relación Incluir para evitar describir el mismo flujo de

eventos repetidas veces, colocando u comportamiento común en un
caso de uso aparte. Un ejemplo de esto tiene la ejecución de Caso
de uso <Card Identification> para ejecutar como parte de un caso de
uso <Withdraw - Retirar>
 Relaciones……
<<extends>> que especifica que en ciertas situaciones, o en
algún punto (llamado punto de extensión) un caso de uso será
extendido por otro.

Un caso de uso se extiende a menudo expresa flujos alternativos.

 Se usa cuando se tiene un caso de uso que es similar a otro, pero
que hace un poco mas.
Relaciones……
Generalización que especifica que un caso de uso hereda las
características del «super» caso de uso, y puede volver a especificar
algunas o todas ellas de una forma muy similar a las herencias entre
clases.
 Ejemplo: Máquina Recicladora

Sistema que controla una máquina de reciclamiento de botellas, tarros y

jabas.
El sistema debe controlar y/o aceptar:

 Registrar el número de ítems ingresados.

 Imprimir un recibo cuando el usuario lo solicita:
Describe lo depositado
El valor de cada item
Total
 El usuario/cliente presiona el botón de comienzo
 Existe un operador que desea saber lo siguiente:
Cuantos ítems han sido retornados en el día.
Al final de cada día el operador solicita un
resumen de todo lo depositado en el día.
 El operador debe además poder cambiar:
Información asociada a ítems.
Dar una alarma en el caso de que:
Item se atora.
No hay más papel.
 Como una primera aproximación
identificamos a los actores que
interactúan con el sistema:

Luego, tenemos que un Cliente puede Depositar Ítems :

Un Operador puede cambiar la información de un Ítem
o bien puede Imprimir un informe
Otro aspecto es la impresión de comprobantes, que puede ser realizada
después de depositar algún ítem por un cliente o bien puede ser realizada
a petición de un operador.
Obtener el Modelo Conceptual de un Sistema de Información sencillo para el
Manejo de una biblioteca, por lo que debes realizar el caso de uso y el diagrama de
clases del siguiente ejercicio:

Hay un modulo denominado Gestionar Socios, Los cuales: Pueden ser ingresados,
Modificados y eliminados del Sistema. Un Socio esta caracterizado por: Id socio, nombre,
dirección y en cada momento se puede saber el número de libros que tiene un socio prestados.

Hay un modulo denominado Gestionar Libros, Los cuales: Pueden ser ingresados,
Modificados y eliminados del Sistema. Un Libro esta caracterizado por: Id Libro, Titulo, autor,
disponibilidad, Localización en la biblioteca, Sigantura.

Hay un modulo denominado Gestionar Prestamos, Los libros solo son prestados a los
socios, un préstamo estará caracterizado por: id socio, fecha préstamo, se lleva el control de
los socios que tengan mas de 10 libros prestados, indicando el sistema que son socios
deudores.

Requisitos,
 El usuario Biblioteca: Solo puede consultar los libros del sistema
 El usuario Socio: Puede: Consultar Libros, insertar socio, modificar socio y eliminar socio
 El Bibliotecólogo: Puede Consultar Libros, Consultar Socios, Insertar préstamo, modificar
préstamo, eliminar préstamo, consultar préstamo, Gestionar Libro (Insertar, modificar y
eliminar)
 Puede Consultar Libros del Sistema
Realizar Prestamos

Socio
Puede Gestionar Libros en el Sistema
Puede Gestionar Prestamos en el
Sistema

ibliotecólogo Puede Consultar Libros del Sistema

Realizar Prestamos
Comprobar si un libro esta disponible o no
Comprobar si un socio es no fiable por tener
hasta 10m libros prestados

suario Biblioteca
 Cine Chicharronsin
Se desea informatizar una empresa encargada de proyectar películas de
cine. Para ello, los espectadores podrán reservar las entradas desde una
serie de terminales dedicadas para este fin, y consultar la posición de las
diferentes localidades que vayan quedando libres para una determinada
sesión de cine.
Para comprar el ticket de cine, el espectador irá a la taquilla, y el taquillero
realizará la venta de la localidad, para ello podrá consultar también las
posiciones de las diferentes localidades que vayan quedando libres. Por otro
lado tenemos también al responsable de administración. Este puede realizar
consultas estadísticas referentes a las películas más solicitadas. Tanto la
venta de tickets, como la consulta de localidades libres, como las reservas, o
las consultas estadísticas, se realizarán accediendo a una base de datos de
películas en cartelera, tickets vendidos y salas disponibles.
El resultado de las estadísticas se calcularán utilizando un programa de hoja
de cálculo que permita la realización de diagramas.
 Ventas LA tumbaLocas SAS
Una empresa encargada de vender productos, desea de informatizarla, y
para ello desea que el sistema realice las siguientes funciones:
El sistema ha de permitir que los Vendedores introduzcan los productos que
venden, junto con sus precios en el sistema. Esta información se empleará
para construir listados estadísticos, para que el Director pueda consultarla.
Cada mes, se generará un listado especial con agrupaciones de ventas por
meses. El sistema, además, ha de permitir al Jefe de Recursos Humanos,
dar de alta y borrar a los diferentes vendedores que se añadan o dejen la
empresa. En cualquier momento, también tendrá la opción de consultarla.
Para la realización de estas tres funcionalidades, se dispondrá de un sistema
gestor de base de datos, encargado de traducir las peticiones del Jefe de
recursos Humanos. El Director, también podrá consultar en todo momento
toda la información referente al personal de la empresa.
 TAXIS LOCOS SAS
La empresa de Radiotaxis “Tan rápido como se pueda” ha solicitado el desarrollo de un sistema computacional
que le apoye en sus procesos claves. El resultado de las reuniones con los diferentes usuarios arroja
como resultado los siguientes requerimientos:

Hay tres tipos de usuarios: Administrativos, Choferes, y el Gerente.

Los Administrativos de la empresa de Radiotaxis podrán:
1.- Ingresar nuevos clientes
2.- Ingresar reservas de viajes indicando el cliente, el chofer solicitado, la dirección de origen, de destino
y la hora de salida. Se ha solicitado que si al ingresar una reserva, el cliente en cuestión no existe
en el sistema se pueda ingresarlo directamente. También ha solicitado que el sistema brinde la
opción de confirmar inmediatamente la reserva que se está ingresando.
3.- Confirmar o Cancelar las reservas ya ingresadas.
Los Choferes de la empresa de Radiotaxis podrán consultar las reservas que tienen asignadas para el día de
la fecha.
El gerente podrá realizar todas las operaciones que pueden realizar los Administrativos y los choferes.
Además podrán Ingresar nuevos choferes al sistema y liquidar las comisiones de los choferes
mensualmente.

Los Representantes de la empresa aclararon que era deseable que el sistema avise a los Administrativos
cuando se acerca el momento de realizar un viaje, en función de las reservas, con 30 minutos de
anticipación para poder realizar la confirmación del viaje con el cliente.