El lenguaje unificado de modelado UML
UML (Unified Modeling Language) es un lenguaje que permite, mediante el uso de
modelos visuales, analizar, describir, especificar y documentar sistemas de
software. Es un estándar para la visualización gráfica de objetos, estados y procesos
dentro de un sistema. Sirve como modelo para un proyecto garantizando una
arquitectura de información estructurada y ayuda a los desarrolladores a representar
el sistema de una manera comprensible para los no especialistas. Se utiliza
principalmente en el desarrollo de software orientado a objetos, ya que permite el
modelado de sistemas analizándolos desde diferentes perspectivas.
Modelar un sistema utilizando diagramas de UML, garantiza contar con documentos
que plasman el trabajo realizado en cada etapa del proyecto.
UML proporciona las herramientas para organizar un diseño sólido y claro, que es
comprendido por los especialistas involucrados en las distintas etapas de la
evolución del proyecto, ya que proporciona un vocabulario común para toda la
cadena de producción, desde quien recaba los requisitos de los usuarios, hasta el
programador responsable del mantenimiento.
Los diagramas de UML
Diagramas y vistas
Vista estática
Vista de interacción
Vista de máquinas de estados
Vista de actividades
Vista física
Vista de gestión de modelo
Revisión del módulo
Lección 1 de 9
Los diagramas de UML
UML está compuesto por diversos elementos gráficos que se combinan para
conformar diagramas cuya finalidad es presentar diversas perspectivas de
un sistema, a las cuales se las conoce como modelos.
UML define varios modelos para la representación de los sistemas que
pueden verse y manipularse mediante un conjunto de diagramas diferentes:
Diagramas de estructura
Diagrama de clases
Diagrama de estructuras compuestas
Diagrama de componentes
Diagrama de despliegue
Diagrama de objetos
Diagrama de paquetes
Diagramas de comportamiento
Diagrama de casos de uso
Diagrama de actividad
Diagramas de interacción
Diagrama de secuencia
Diagrama de comunicación o colaboración
Diagrama de visión global de la interacción
Diagrama de tiempo
Diagrama de máquina de estados
C O NT I NU A R
Lección 2 de 9
Diagramas y vistas
Una vista es un subconjunto de las construcciones de modelado de UML que
representa un aspecto del sistema.
Las vistas se pueden agrupar en áreas conceptuales:
Tabla 1: Agrupación de las vistas según áreas conceptuales
Fuente: Elaboración propia
Vista de casos de uso
La vista de casos de uso captura la funcionalidad de un sistema tal como se
muestra a un usuario exterior. Divide la funcionalidad del sistema en
transacciones significativas para los supuestos usuarios. Los usuarios se
denominan actores y las particiones funcionales se conocen con el nombre
de casos de uso. Para modelar esta vista se utiliza el diagrama de casos de
uso.
Los diagramas de casos de usos permiten representar gráficamente las
acciones de un sistema desde el punto de vista del usuario. Modelan las
funcionalidades del sistema según la percepción de los agentes externos,
denominados actores, que interactúan con él.
Sus componentes son el sistema que se modela (sujeto), las unidades
funcionales completas (casos de uso) y las entidades externas que
interactúan con el sistema (los actores).
Un actor modela un rol, una entidad que interacciona con el sujeto pero que
es externa a él. Los actores se comunican con el sujeto intercambiando
mensajes. Se representan con un ícono estándar (stick man) y es obligatorio
indicar su nombre cerca del símbolo (encima o debajo). Los nombres de los
actores suelen comenzar por mayúscula y pueden usarse símbolos
especiales para representar tipos de actores particulares (por ejemplo,
actores no humanos).
Figura 1: Representaciones de actores
Fuente: Elaboración propia.
Un caso de uso se define como un conjunto de acciones realizadas por el
sistema que dan lugar a un resultado observable. El caso de uso especifica
un comportamiento que el sujeto puede realizar en colaboración con uno o
más actores, pero sin hacer referencia a su estructura interna. Se representa
mediante una elipse con el nombre del caso de uso dentro o debajo de ella.
Figura 2: Ejemplo de caso de uso
Fuente: Elaboración propia
Los casos de uso pueden tener asociaciones y dependencias con otros
clasificadores:
Tabla 2: Asociaciones y dependencias
Fuente: Elaboración propia.
Figura 3: Ejemplo de diagrama
Fuente: Elaboración propia.
Ejemplo práctico:
Se requiere modelar mediante un diagrama de casos de uso el sistema de
gestión de una biblioteca. Los lectores se registran en el sistema y a partir
de ese momento cuentan con una clave de acceso que les permite
autenticarse y acceder a los siguientes servicios:
Ver catálogo de libros
Solicitar un préstamo
Realizar una devolución
Todo usuario debe autenticarse para realizar cualquiera de las citadas
operaciones. Si el lector se retrasa en la devolución de un ejemplar, se le
impone una multa que le impide retirar un nuevo libro durante 5 días.
Para modelar una situación cualquiera mediante un diagrama de casos de
uso, en primer lugar, se deben reconocer los actores (roles) en juego.
En este caso particular el actor a considerar es el Lector.
Una vez identificados los actores en juego, es necesario reconocer los casos
de uso, es decir las funcionalidades que el o los actores tienen a disposición.
En este caso particular el actor dispone de las siguientes funcionalidades:
En este caso particular el actor dispone de las siguientes funcionalidades:
1. Registrarse como socio de la biblioteca.
2. Ver el catálogo de libros.
3. Solicitar un libro en préstamo.
4. Restituir un libro que obtuvo en préstamo.
Estas funcionalidades constituirán los casos de uso fundamentales para el
diagrama a realizar. Es necesario considerar además que para poder acceder
a las funcionalidades b, c, y d, el lector debe haberse autenticado en el
sistema. El proceso de autenticación constituye entonces una nueva
funcionalidad que será diagramada como una relación de inclusión por ser
exigida para acceder a las funcionalidades antes citadas. Como última
consideración, es necesario tener en cuenta la posibilidad de que se aplique
una multa. Según se detalla la multa consiste en la imposibilidad de solicitar
un préstamo si hubo un retardo en la devolución de algún ejemplar. Esto
significa que ante una devolución o ante un préstamo es necesario
comprobar si es el caso de aplicar o no un periodo de multa. Esto será
entonces también una funcionalidad particular a considerar como relación de
inclusión para el préstamo o restitución de ejemplares.
Finalmente, el diagrama de casos de uso obtenido para la situación
planteada será:
Figura 4: Diagrama de casos de uso según el sistema de gestión de una
biblioteca
Gestión de biblioteca – Casos de uso
Fuente: Elaboración propia
C O NT I NU A R
Lección 3 de 9
Vista estática
Modela los conceptos del dominio de la aplicación, sus propiedades internas
y sus relaciones. Se denomina vista estática porque no modela el
comportamiento del sistema dependiente del tiempo. Sus componentes
principales son las clases, que describen conceptos del dominio de la
aplicación o de la solución y sus relaciones. Para modelar esta vista se utiliza
el diagrama de clases.
Una clase es un clasificador que describe un conjunto de objetos que
comparten la misma especificación de características, restricciones y
semántica. La clase describe las propiedades y comportamiento de un grupo
de objetos. Un objeto es una instancia de una clase, una entidad discreta con
identidad, estado y comportamiento que representa una entidad del mundo
real.
Los diagramas de clases describen la vista estática de un sistema en forma
de clases y relaciones entre ellas. Los diagramas de objetos muestran las
instancias de las clases y los enlaces específicos entre esas instancias en un
momento determinado.
Una clase se representa por un rectángulo dividido en compartimentos:
Compartimento del nombre: contiene el nombre de la clase (inicial
en mayúscula) en negrita y centrado.
Compartimento de los atributos: contiene la lista de atributos
(inicial en minúscula) alineado a la izquierda.
Compartimento de las operaciones: contiene la lista de
operaciones (inicial en minúscula) alineado a la izquierda.
Para los atributos y las operaciones se debe definir su visibilidad expresando
si son o no visibles a otros objetos
+ Visibilidad Pública
# Visibilidad Protegida
- Visibilidad Privada
~ Visibilidad de Paquete
Una relación es una conexión semántica entre elementos de un modelo.
Pueden ser de varios tipos:
Asociaciones: representan a las relaciones estáticas entre las clases
describiendo un conjunto de enlaces entre objetos.
Figura 5: Asociación
Fuente: Elaboración propia.
Multiplicidad: indican el número de instancias de una clase vinculadas a una
de las instancias de la otra clase.
Figura 6: Multiplicidad
Fuente: Elaboración propia
Composición y agregación: la composición es un tipo especial de agregación
que denota una fuerte posesión de la Clase Todo, a la Clase Parte. Se grafica
con un rombo diamante relleno contra la clase que representa el todo. La
agregación es una relación en la que la Clase Todo juega un rol más
importante que la Clase Parte, pero las dos clases no son dependientes una
de otra. Se grafica con un rombo diamante vacío contra la Clase Todo.
Figura 7: Composición y agregación
Fuente: Elaboración propia.
Generalización: indica una relación de herencia entre dos clases en donde
una Clase Específica es una versión especializada de la otra, o Clase General.
Figura 8: Generalización
Fuente: Elaboración propia
Los diagramas de objetos están vinculados con los diagramas de clases.
Describen la estructura estática del sistema en un momento particular y son
usados para probar la precisión de los diagramas de clases.
Cada objeto es representado como un rectángulo, que contiene el nombre
del objeto y su clase subrayadas y separadas por dos puntos. Los atributos
se listan en un área inferior y deben tener un valor asignado.
Figura 9: Representación del objeto
Fuente: Elaboración propia
Ejemplo práctico:
Se requiere obtener mediante un diagrama de clases un modelo simplificado
de los diferentes perfiles que conforman una comunidad universitaria. Estos
perfiles pueden ser estudiantes o personal que trabaja en la universidad.
Todos ellos, independientemente de su rol, se identifican mediante nombre,
apellido y D.N.I. Los estudiantes cuentan además con un número de legajo
mientras que el personal tiene asignado un sueldo. El personal de la
Universidad se divide en personal docente y personal administrativo. Los
docentes tienen asignadas las asignaturas que dictan (cada docente dicta
una asignatura) y los administrativos, el edificio donde trabajan. El modelo
debe realizarse utilizando herencia siempre que sea posible.
Para la realización del diagrama de clases solicitado, en primer lugar, es
necesario analizar los perfiles a modelar teniendo en mente el modelo de
generalización-especialización. Es necesario plantear un mecanismo de
herencia donde la clase padre modele el caso más general, y las subclases
modelen los casos más específicos.
Dado el problema puede plantearse como clase base la clase persona cuyos
atributos serán: Apellido (cadena de caracteres), Nombre (cadena de
caracteres) y DNI (entero). Claramente esos atributos corresponden a
información que toda persona, independientemente de su rol en la
organización, posee. Para todos los atributos el especificador de acceso será
protegido que implica visibilidad total para las clases derivadas y visibilidad
privada para cualquier objeto externo. Continuando el árbol de herencia, se
definen las clases derivadas Estudiante y Empleado, con legajo y sueldo
como atributos respectivamente. Los atributos continúan con su visibilidad
protegida a fin de mantener el principio de encapsulamiento y permitir
ulteriores derivaciones de herencia (lo cual favorece la reusabilidad). A su
vez la clase empleado puede derivarse en dos subclases: docente o
administrativo. Según las especificaciones, el empleado administrativo
trabaja en un edificio, lo que se representa mediante el atributo protegido
Edificio (tira de caracteres). El docente a su vez tiene asignada una materia.
Es posible en este caso considerar una agregación, la clase docente contiene
una instancia de la clase Asignatura.
El diagrama de clases que modela la situación planteada es:
Figura 10: Diagrama de clases que modela los distintos perfiles de una
comunidad universitaria
Comunidad universitaria – Diagrama de clases
Fuente: Elaboración propia.
C O NT I NU A R
Lección 4 de 9
Vista de interacción
Se centra en el intercambio de información observable entre elementos que
pueden conectarse. La comunicación se realiza mediante mensajes. Para
modelar esta vista se utilizan los siguientes diagramas:
Diagrama de secuencia: hacen hincapié en la secuencia de
intercambio de mensajes entre objetos.
Diagrama de comunicación o colaboración: se centran en las
interacciones y enlaces entre objetos que colaboran.
Diagrama de visión global de la interacción: es una variante del
diagrama de actividad que muestra el flujo de control de la
interacción a alto nivel.
Diagrama de tiempo: muestra sobre un eje de tiempo los cambios
de estado o condición de una instancia.
Los diagramas de secuencia muestran la interacción entre los objetos
centrándose en la secuencia de mensajes que envían y reciben. Representa
una interacción como un diagrama bidimensional: la dimensión vertical es el
eje de tiempos, la dimensión horizontal muestra la línea de vida de los
objetos implicados en la interacción.
Figura 11: Diagrama de secuencia
Fuente: Elaboración propia.
Ejemplo práctico:
Se requiere construir el modelo UML del sistema de gestión de ventas online
de una librería.
Para poder realizar un pedido, un cliente debe estar registrado como tal.
El proceso de registro exige que el usuario introduzca una serie de datos
personales: nombres, apellidos, dirección, localidad, código postal y país;
datos de su tarjeta de crédito: tipo de tarjeta, número, fecha límite de validez;
y datos sobre sus preferencias de envío: correo normal o expreso. Para
concluir el proceso el usuario deberá elegir un nombre de usuario y una
contraseña como método de autentificación para ingresar al sistema.
Para modelar el proceso de registro de usuario se requiere la confección de
un diagrama de secuencia.
El diagrama de secuencia a construir debe evidenciar el envío de mensajes
entre las instancias participantes. La funcionalidad será iniciada por la
petición de registro por parte de un cliente, por lo cual este participa del
diagrama a crear. El cliente solicita ser registrado ingresando un nombre de
usuario y un correo electrónico. La instancia del sistema debe comprobar
que el usuario en cuestión no exista antes de permitir el nuevo registro. En tal
caso el usuario provee una contraseña y su comprobación (deben ser
idénticas) que deben también ser comprobadas por el sistema. Si todo
resulta satisfactorio será entonces posible que el usuario provea los
restantes datos. Para concluir la operación proveerá sus datos de tarjeta de
crédito. Esta última información no puede ser comprobada localmente, será
necesario acceder a un sistema externo que provea la información sobre la
tarjeta específica. En el diagrama de secuencia esta transacción se modela
incluyendo una instancia del sistema informático de la tarjeta de crédito.
El diagrama de secuencia obtenido según lo expuesto será entonces:
Figura 12: Diagrama de secuencia del sistema de gestión de ventas online
de una librería
Registro de cliente – Diagrama de secuencia
Fuente: Elaboración propia.
C O NT I NU A R
Lección 5 de 9
Vista de máquinas de estados
Modela las posibles historias de vida de un objeto. Cada estado modela un
periodo de tiempo, durante la vida de un objeto, en el que satisface ciertas
condiciones. Si ocurre un evento, se puede desencadenar una transacción
que lleva al objeto a un nuevo estado.
Para modelar esta vista se utilizan los diagramas de estado.
El estado identifica situaciones durante la vida de un objeto. Se representa
con un rectángulo que tiene sus esquinas redondeadas.
Figura 13: Representación de estado
Fuente: Elaboración propia
Una flecha representa una transición, el pasaje entre diferentes estados de
un objeto. Se etiqueta con el evento que lo provoca y con la acción
resultante.
Figura 14: Representación de transición
Fuente: Elaboración propia
El estado inicial y el estado final del proceso se identifican de modo
particular:
Figura 15: Representación de estado inicial y final
Fuente: Elaboración propia
Figura 16: Ejemplo de representación de estados y transiciones
Fuente: Elaboración propia
Ejemplo práctico:
En el apartado anterior se realizó el modelado del registro de un nuevo
usuario para acceder al sistema de gestión de ventas online de una librería.
Este sistema permite que un usuario realice un pedido agregando los
artículos que desea adquirir a su lista de compras (carro). El usuario tiene la
posibilidad de cancelar la operación en cualquier momento o bien, una vez
que ha seleccionado todo aquello que irá a adquirir, confirmarla para que el
pedido le sea enviado. El sistema permite que un pedido confirmado pueda
ser modificado durante un periodo de 90 minutos a partir del momento de su
confirmación. Pasado ese tiempo el cliente pierde la posibilidad de modificar
su compra.
Se desea modelar el comportamiento antes detallado mediante un diagrama
de estados.
Para obtener el modelo requerido es necesario en primer lugar identificar los
posibles estados y las transiciones entre ellos. Según los detalles que se
especificaron, pueden considerarse los siguientes estados:
1. Unestado en que la lista de compras (carro) está vacía, es decir aún no
se ha seleccionado ningún artículo para adquirir.
2. Un estado en que se están agregando, modificando o quitando artículos
de la lista de compras.
3. Unestado en el que la lista se confirma y el pedido queda confirmado,
pero con posibilidad de ser modificado.
4. Un estado en el que se anula la operación y el pedido queda cancelado.
5. Unestado en que el pedido queda confirmado definitivamente y puede
pasar al proceso de envío.
Además de estos estados se debe considerar un estado inicial, que indica el
comienzo de la situación modelada y el o los estados finales (en este caso
dos) que indican como finaliza el proceso. En este caso particular el proceso
puede finalizar con un pedido confirmado y listo para el envío o bien con un
pedido cancelado, de allí que es conveniente considerar dos estados finales
distintos.
El diagrama de estado que modela cuanto expresado es:
Figura 17: Diagrama de estado que modela el sistema de compra y
adquisición de artículos
Pedido de productos – Diagrama de estados
Fuente: Elaboración propia.
C O NT I NU A R
Lección 6 de 9
Vista de actividades
Modela las actividades implicadas en la ejecución de un cálculo. Representa
una acción, un paso en el flujo de trabajo, o la ejecución de una operación,
describiendo grupos secuenciales y/o concurrentes de actividades.
Para modelar esta vista se utilizan los diagramas de actividades.
Un diagrama de actividad ilustra la naturaleza dinámica de un sistema
mediante el modelado del flujo ocurrente de actividad en actividad. Una
actividad representa una operación que ocasiona un cambio en el estado del
sistema. Típicamente, los diagramas de actividad son utilizados para
modelar el flujo de trabajo interno de una operación. Sus elementos
constitutivos son:
Estados de Acción, representan las acciones no interrumpidas de los objetos.
Figura 18: Estado de acción
Fuente: Elaboración propia
Flujo de la Acción, ilustran las relaciones entre los estados de acción.
Fuente: Elaboración propia
Estado Inicial, comienzo de una acción.
Figura 20: Estado inicial
Fuente: Elaboración propia
Estado final, finalización de una acción.
Figura 21: Estado final
Fuente: Elaboración propia
Ramificación, representa una decisión con caminos alternativos. Las salidas
alternativas deben estar etiquetadas con una condición.
Figura 22: Ramificación
Fuente: Elaboración propia
Sincronización, ilustra la ocurrencia de transiciones paralelas.
Figura 23: Sincronización
Fuente: Elaboración propia
Ejemplo práctico:
Continuando con el caso del sistema de gestión de ventas online para una
librería, se requiere ahora modelar el proceso de autenticación de clientes.
Según se explicó todo cliente debe registrarse para poder realizar pedidos.
Cuando lo hace obtiene un nombre de usuario y una contraseña que lo
identifican en el sistema.
Para modelar este proceso, es posible generar un diagrama de actividad en
el que se evidencien las diferentes tareas y el orden en el cual se realizan. El
diagrama obtenido ilustra entonces el flujo de trabajo correspondiente. En
este caso la tarea inicial será el ingreso de las credenciales de acceso
(nombre de usuario y clave); a continuación, estas credenciales deberán
verificarse, existiendo entonces dos posibilidades. Si se ha verificado que son
correctas, el proceso de autenticación acaba permitiendo el ingreso del
usuario y generando un registro completo (log) de dicho ingreso. Si el usuario
no pudo ser reconocido, se solicita nuevamente sus credenciales de acceso.
El diagrama de actividad que modela la situación descripta es:
Figura 24: Diagrama de actividad que modela el sistema de autenticación
de clientes
Autenticación de usuarios – Diagrama de actividad
Fuente: Elaboración propia.
C O NT I NU A R
Lección 7 de 9
Vista física
Las vistas anteriores modelan los conceptos de la aplicación desde un punto
de vista lógico. Las vistas físicas modelan las estructuras de la
implementación de la aplicación por sí misma, su organización en
componentes, y su despliegue en modos de ejecución. Estas vistas
proporcionan una oportunidad de establecer correspondencias entre las
clases y los componentes de implementación y modos.
C O NT I NU A R
Lección 8 de 9
Vista de gestión de modelo
La vista de gestión modela la organización del modelo en sí mismo.
Permite dividir el sistema en unidades más pequeñas llamadas paquetes.
Un modelo abarca un conjunto de paquetes y cada paquete contiene
elementos, tales como clases, máquinas de estados, y casos de uso.
Los paquetes a su vez pueden contener otros paquetes donde uno de ellos
se señala como paquete raíz y contiene indirectamente la descripción de
todo el modelo.
C O NT I NU A R
Lección 9 de 9
Revisión del módulo
Hasta acá aprendimos
Introducción a los modelos y metodologías de desarrollo de Software
–
Un proceso de desarrollo de software es un conjunto coherente de actividades
que se llevan a cabo para la construcción de un producto de software. Este
proceso, en general, define el conjunto de actividades y estrategias a adoptar para
la gestión del ciclo de vida del producto. Un modelo de desarrollo de software es
una representación simplificada de este proceso de desarrollo. Existen diferentes
modelos, algunos estructurados y fuertemente atados a un plan, y otros menos
formales y más flexibles.
El Modelo Orientado a Objetos
–
El modelo orientado a objetos es un enfoque técnico popular para analizar y
diseñar un sistema mediante la aplicación de ese paradigma. Alienta el uso
de modelos visuales durante los ciclos de desarrollo con el objetivo de
garantizar la calidad del producto obtenido. La principal diferencia del modelo
orientado a objetos respecto a otros modelos es que los requisitos se
organizan en torno a objetos que integran comportamientos (procesos) y
estados (datos).
El Proceso Unificado de Desarrollo de Software
–
El proceso unificado de desarrollo de software (RUP) es un modelo de proceso
híbrido que define un conjunto de metodologías adaptables al contexto y a las
necesidades de cada organización. Puede definirse como un marco genérico
utilizable en el desarrollo de una amplia variedad de sistemas, áreas de
aplicación, tipos de organizaciones, niveles de aptitud y tamaños de proyectos.
El lenguaje unificado de modelado UML
–
UML (Unified Modeling Language) es un lenguaje que permite, mediante el uso de
modelos visuales, analizar, describir, especificar y documentar sistemas de
software. Es un estándar para la visualización gráfica de objetos, estados y
procesos dentro de un sistema. Modelar un sistema utilizando diagramas de
UML, garantiza contar con documentos que plasman el trabajo realizado en cada
etapa del proyecto.
C O NT I NU A R
