Uml

Lenguaje de Modelado Unificado (UML)

Ing. Mauricio Paletta, Msc
MAESTRÍA EN TECNOLOGÍA DE LA INFORMACIÓN
TECNOLOGÍA ORIENTADA A OBJETOS

COORDINACIÓN GENERAL DE INVESTIGACIÓN Y POSTGRADO
UNIVERSIDAD NACIONAL EXPERIMENTAL DE GUAYANA

Lenguaje de Modelado Unificado

Antes de UML

Coad / Yourdon:

Jerarquías de composición

Antes de UML

James Rumbaugh – OMT:

Estructura recursiva de composición

Antes de UML

James Rumbaugh – OMT:

Modelo de estado

Antes de UML

Martin / Odell – Ptech:

Metáfora de ingeniería Esquema de concepto
de procesos


Antes de UML

Jacobson – Objectory y OOSE:

Diagrama de Casos de Uso

Antes de UML

Reenskaug - OORASS (Análisis, Síntesis y
Estructuración de Papeles Orientada a
Objetos):

Diagrama de papeles


Métodos Orientados a Objetos

Texel:

Modelo de estados para la clase Ventana

Métodos Orientados a Objetos

BON (Notación de Objetos Mejorada):

Modelo estático Modelo dinámico


Antes de UML

Fusión:

Modelo de
procesos


Antes de UML

HOOD (Diseño OO Jerárquico):

Flujos de
datos


Antes de UML

OOSD (Diseño Estructurado OO):

Un objeto que representa una Tratamiento de excepciones para una
Pila Pila

Antes de UML

Booch:

Diagrama de Clases

Antes de UML

Otros métodos:
• OBA (Análisis de Comportamiento de Objetos) –
Rubin y Goldberg (1992).
• FOA (Análisis Orientado a Marcos) – Andleigh y
Gretzinger (1992).
• Notación Uniforme de Objetos – Page-Jones,
Constantine y Weiss (1990).
• MOSES (Metodología para la Ingeniería de
Sistemas de Software Orientada a Objetos) –
Henderson-Sellers y Edwards (1993).
• Wirfs-Brock (1990).
• JSD y OOJSD – Jackson (1983).

Evolución Histórica Métodos

Lenguaje de y Programación III
Algoritmos Modelado Unificado


Definición:
• Creación de Grady Booch, James Rumbaugh e Ivar Jacobson
(los tres amigos).
• Es un lenguaje (sintaxis y semántica) de modelado y no un
método. La sintaxis nos dice cuáles son los símbolos y cómo
se pueden combinar; la semántica nos da las reglas de
interpretación de cada símbolo según el contexto donde se
use.
• Usado para modelar o describir sistemas de una gran variedad
de tipos (principalmente de software). También usado durante
el desarrollo de un sistema de software, desde la
especificación de requerimientos hasta las pruebas finales.
• Avalado por el grupo de estándares OMG.



Objetivos:
• Modelar sistemas (no únicamente software) usando conceptos
de orientación a objetos.
• Establecer una pareja explícita de elementos tanto a nivel
conceptual como ejecutable.
• Direccionar los temas de cierto tamaño inherentes a los
sistemas complejos y/o críticos.
• Crear un lenguaje de modelado utilizable tanto para los
humanos como para las máquinas.



4 partes:
• Vistas: muestra diferentes aspectos del sistema que se está
modelando. Representa una abstracción que consiste en un
número determinado de diagramas. Permite enlazar el modelo
al proceso escogido para el desarrollo.
• Diagramas: gráficas que describen el contenido de una vista.
Son 9 tipos de diagramas en total.
• Elementos del modelo: son los conceptos usados en los
diagramas, asociados comúnmente a conceptos de la
orientación a objetos (clase, objeto, mensaje). Siempre tiene el
mismo significado y símbolo, sin importar el diagrama.
• Mecanismos generales: proveen comentarios, información u
otros extras a los elementos del modelo.



5 vistas:
• Vista de Casos de Uso: muestra la funcionalidad del sistema
tal como es percibida por los actores externos.
• Vista lógica: muestra cómo la funcionalidad está diseñada
dentro del sistema, en términos de las estructuras estáticas y el
comportamiento dinámico.
• Vista de componentes: muestra la organización de los
componentes de código para construir el sistema.
• Vista de concurrencia: muestra la concurrencia
(comunicación y sincronización) en el sistema.
• Vista de despliegue: muestra el despliegue o distribución del
sistema en la arquitectura física (computadoras y otros
dispositivos).



9 diagramas:

• Vista de Casos de Uso: o Diagrama de Casos de Uso
o Diagrama de Actividades
• Vista lógica: o Diagrama de Clases
o Diagrama de Objetos
o Diagramas de Estados
• Vista de concurrencia: o Diagrama de Colaboración
o Diagrama de Secuencias
• Vista de componentes: o Diagrama de Componentes
• Vista de despliegue: o Diagrama de Distribución


Extensiones de UML

Valores etiquetados:
• Son propiedades asociadas a elementos de UML en forma de
etiquetas. Existe una serie de etiquetas ya predefinidas en UML
(documentación, ubicación, persistencia, semántica,
responsabilidad, precondición, poscondición, abstracto, etc.).
• Permiten agregar semántica extra a los elementos asociados
(precondiciones y poscondiciones de las operaciones, por
ejemplo). También son usados para agregar información
administrativa sobre el progreso o estado de un proyecto.
• Se representan en los diagramas encerrados entre llaves y
consisten de una etiqueta, un signo de igualdad ´=´ y un valor.
• Ejemplo: { Algoritmo = “QuickSort” }
{ Autor = “Mauricio Paletta” }


Extensiones de UML

Restricciones:
• Reglas que restringen la semántica de uno o más elementos de
UML. También llamadas condiciones semánticas.
• Pueden estar asociadas a clases u objetos y también a las
relaciones entre éstos, a fin de restringir la participación de
estos elementos en la relación.
• Se representan en los diagramas encerrados entre llaves.
• Hay 14 restricciones predefinidas: asociación, local, parámetro,
auto, completa, disjunta, incompleta, sobrelapada, implícita, or
ordenada, voto y difundida.
• El usuario también puede definir sus propias restricciones
(parecido a la forma como se definen valores etiquetados).
Ejemplo: { persona.jefe.sueldo >= persona.asistente.sueldo }


Extensiones de UML

Estereotipos:
• Representa una semántica asociada a un elemento existente. Se
pueden ver como un tipo de especialización del elemento.
• Cuando un estereotipo está asociado a un elemento, se
sobrescribe la semántica definida para ese elemento y éste
puede ser visto como un nuevo elemento basado en otro ya
existente. Es una extensión de la semántica pero no de la
estructura del elemento.
• Por lo general son metaclases (para ser asociados a clases) o
importaciones (para las relaciones de dependencia entre
paquetes).
• Hay mas de 40 estereotipos predefinidos en UML y también es
posible definir estereotipos propios.


Extensiones de UML

Estereotipos:
• Se representan o identifican con un nombre encerrado entre
„<<‟ y „>>‟ que por lo general se coloca delante del
identificador del elemento asociado.
• Tres tipos particulares de estereotipos aplicado a clases son:
Control, Límite y Entidad. Están basados en el concepto
“model-view-controller” donde Entidad es el modelo, Control
es el controlador y Límite es la vista. Esta es la notación
utilizada:

Control Entidad Límite


Extensiones de UML

Estereotipos:
• El estereotipo Límite especializa el uso de una clase para su
presentación y manipulación. Presenta y comunica la
información entre sistemas (hombre-máquina por ejemplo). Por
lo general son ventanas, cajas de diálogos o formas, clases que
representan elementos de comunicación (como TCP/IP).
• El estereotipo Entidad es usado para modelar objetos del
negocio.
• El estereotipo Control es usado para conectar objetos Límite
con sus objetos Entidad y manejar una secuencia de
operaciones dentro del sistema. Estos objetos típicamente
manejan el procesamiento de la información en los objetos
Entidad.


Extensiones de UML

Estereotipos:

Manejador Cursos

Opciones Profesores 1 Maneja

Curso

1..*
1

Agregar Curso Ofrecido Cursos Ofrecidos



Definición:
• Describe lo que un nuevo sistema debe hacer o lo que un
sistema existente hace en término de los requerimientos y
funcionalidades.
• Es una estructura que ayuda a los analistas a trabajar con los
usuarios para determinar la forma en que se usará el sistema a
modelar. Es una excelente herramienta para estimular a que
los usuarios potenciales hablen del sistema desde sus propios
puntos de vista.
• El sistema se describe o es visto como una “caja negra” que
provee casos de uso.
• Permiten definir la vista de casos de uso del sistema.



3 elementos básicos:
• Actor: tipo o categoría de usuario. Define los papeles
diferentes que un usuario puede desempeñar. El conjunto de
actores representa a todo aquello que necesita intercambiar
información con el software que se está analizando.
Notación:

Actor



• Caso de uso: secuencia de transacciones que se realizan en un
elemento de interfaz. Constituye una secuencia completa de
mensajes y especifica la secuencia de interacción entre el actor
y el software. Caso de uso  Requerimiento.
Notación:

Caso de Uso
Caso de Uso



• Relaciones: permiten identificar la comunicación entre los
actores , entre los casos de uso y entre actores y casos de uso.
Hay 5 tipos de relación:
o Relación de generalización entre actores: permite organizar
los actores en una descripción abstracta del actor.

El actor Persona es
más genérico que el
Persona Empleado actor Empleado



o Relación de generalización entre casos de uso: identifica
que un caso de uso específico hereda y añade propiedades a
un caso general.

El case de uso
“Comprar en una
Comprar en
una máquina
Comprar un
refresco
máquina” es más
genérico que el caso
de uso “Comprar un
refresco”



o Relación de extensión entre casos de uso (extend): permite
factorizar las variantes sobre la secuencia básica de un caso
de uso en nuevos casos de uso que extienden los flujos
principales.

“Alquilar un vehículo”
Alquilar un Alquilar un extiende (opcionalmente
vehículo chofer
<<extend>> ejecuta) a “Alquilar un
chofer”



o Relación de inclusión entre casos de uso (include): permite
señalar que un caso de uso incorpora el comportamiento de
otro caso de uso como parte de su propio comportamiento.

“Acceder a un sistema”
Acceder a Revisar datos usa (siempre ejecuta) a
un sistema del usuario
<<include>> “Revisar datos del
usuario”



o Relación de asociación entre un actor y un caso de uso:
permite señalar la comunicación existente entre ambos.

Comprar un
refresco

Persona

Hacer reporte
de cierre

Administrador



Ejemplo:
Máquina de Refrescos

Comprar
Comprar
refresco
refresco

Cliente Cliente

Reabastecer

Proveedor <<include>> <<include>>

Exhibir el Cubrir el
interior interior

<<include>> <<include>>

Recolectar
Recolectar
dinero
dinero

Recolector Recolector



Ejemplo:


Diagrama de Actividad

Definición:
• Representan la dinámica del sistema.
• Son diagramas usados para mostrar el flujo de las actividades
del sistema, es decir, muestran el flujo de control entre
actividades del sistema, cuáles actividades se pueden hacer en
paralelo y caminos alternativos del flujo.
• En el análisis, se pueden crear para representar el flujo a
través de los casos de uso o para representar el flujo de un
caso de uso particular.
• En el diseño, se pueden usar para representar el flujo de una
operación particular (algoritmo).
• Contienen actividades, transiciones entre actividades, cajas de
decisión y barras de sincronización.



Elementos:
• Actividad: representa el desempeño de algún comportamiento
en el diagrama de flujo.
• Actividades inicial y final: símbolos especiales usados para
iniciar y finalizar el diagrama de flujo.
• Transición: muestran el paso del flujo de control de una
actividad a otra.
• Cajas de decisión: muestran rutas alternativas del flujo de
control basado en una condición.
• Barras de sincronización: permite representar actividades que
se pueden ejecutar de forma concurrente (una transición de
entrada y varias de salida) o diversos flujos que, una vez
culminados, convergen en un punto (varias transiciones de
entrada y una de salida).


Notación:
Actividad 1
Comienzo

Transición
Actividad 2

Transición Cíclica

Actividad 3 Si Actividad 4
Decisión
No
Rutas
concurrentes

Actividad 5 Actividad 6
Estado

Rutas
convergentes
Esto es un
comentario
Fin



Ejemplo:


Diagrama de Clases

Definición:
• Describe la vista estática de un sistema en términos de sus
clases y las relaciones entre ellas.
• Sirve de base para otros diagramas que muestran otros
aspectos del sistema (como el de estados de los objetos y el de
colaboración entre objetos que se muestran en los diagramas
dinámicos).
• Para su definición, es necesario que las clases hayan sido
identificadas y descritas; luego se pueden asociar con otras
clases usando relaciones específicas.


Diagrama de Clases

Relaciones:
• Asociación: conexión semántica entre clases que indica que
existe una conexión entre objetos de esas clases.
• Generalización: relación entre un elemento mas general y otro
mas específico (herencia). El elemento mas específico puede
contener información adicional.
• Dependencia: relación entre un elemento independiente y otro
dependiente. Un cambio en el elemento independiente afecta
al elemento dependiente.
• Refinamiento: relación entre dos descripciones del mismo tipo
pero en niveles diferentes de abstracción.


Diagrama de Clases

Asociaciones:
• Normal: es la asociación más común y se dibuja como una
línea sólida que une las dos clases. Tiene un nombre
(comúnmente un verbo) que etiqueta el enlace. Es posible
agregar una flecha al final de la asociación, que indica que la
asociación sólo se puede usar en la dirección de la flecha. Si
no tiene la flecha se asume que la asociación es válida para
ambos sentidos. También se puede indicar la multiplicidad
válida en la asociación.

Usa Propietario
Empleado Computadora Persona Carro
1..* 0..*


Diagrama de Clases

Asociaciones:
• Recursiva: representa la conexión de una clase consigo
misma. Los objetos conectados semánticamente son de la
misma clase. Las asociaciones en general pueden tener roles
conectados a cada clase involucrada en la asociación e indican
el papel que juega la clase en términos de la asociación. Es
una técnica útil para especificar el contexto de una clase y sus
objetos.
0..* esposo
Nodo Persona

0..* esposa

Conecta Se casa con


Diagrama de Clases

Asociaciones:
• Cualificada: son usadas en asociaciones de “uno a muchos” o
“muchos a muchos”. El cualificador indica cómo distinguir
entre el conjunto de objetos de los muchos al final de la
asociación; puede verse como un tipo de clave que permite
separar todos los objetos en la asociación. Reducen la
multiplicidad en el modelo de “uno a muchos” a “uno a uno”.

Canvas 0..* Figura
id figura

número de Localiza *
Recepcionista Reservación
confirmación


Diagrama de Clases

Asociaciones:
• Disyuntiva (or): representa una restricción entre dos o más
asociaciones. Indica que los objetos de una clase pueden
participar en a lo sumo una de las asociaciones a la vez. Las
asociaciones en general también pueden contener restricciones
para indicar que la asociación debe seguir cierta regla para su
cumplimiento.
Compañía de Póliza de {Or} Póliza de
1 0..* 0..*
Seguros Seguros Seguros

0..* 0..* {Ordenado}
{Or}

1..* 1..* 1..*
Persona Compañía Cliente


Diagrama de Clases

Asociaciones:
• Ternaria: representa la asociación de tres clases. Se representa
mediante un diamante. Los calificadores y la agregación no
están permitidos en este tipo de asociación. Se puede evitar
con la definición de asociaciones simples.

Compañía de 1 0..* Póliza de 0..*
Seguros Seguros

0..*
Cláusula

0..*
1..*
Persona


Diagrama de Clases

Asociaciones:
• Agregación: es un caso especial de asociación que indica que
la relación entre las clases es del tipo “parte de”. Se representa
mediante un diamante. Cuando la asociación de composición
es obligatoria, el diamante está relleno.

Texto
*

Naval * Barco de Guerra Ventana * Botón
Contiene

*
Menú


Diagrama de Clases

Generalización:
• Permite representar herencias. Relación “es un” o “caso
particular de”.

Vehículo

Carro Bote

Carro Carro de Velero Bote a Carguero
Camión
Deportivo Pasajeros motor


Diagrama de Clases

Dependencia:
• Es una conexión semántica entre dos elementos del modelo,
uno independiente y otro dependiente. Por ejemplo, cuando
una clase toma el objeto de otra clase como parámetro; una
clase hace uso del objeto global de otra clase; la relación de
amistad entre clases permitida por algunos lenguajes (C++);
etc. Se utiliza una línea no continua con una flecha que indica
la dirección de la dependencia.

<<friend>>
Clase A Clase B


Diagrama de Clases

Refinamiento:
• Relaciones entre dos descripciones del mismo tipo pero en
niveles de abstracción diferentes. Por ejemplo, entre un tipo y
una clase; entre una clase en tiempo de análisis y la misma
clase en tiempo de diseño; etc. Se utiliza una línea no continua
con una flecha cerrada dirigida al elemento de más alto nivel
de abstracción.

Clase Clase
(análisis) (diseño)


Diagrama de Clases

Multiplicidades:
1 Está casado con 1
Esposo Esposa
uno a uno

1 Enseña *
Maestro Estudiante uno a muchos

1 Atiende 1..*
Cajero Cliente uno a uno o más

0..1
Casa Chimenea uno a ninguno o uno

1 Toma 12..18
Estudiante Crédito uno a 12 hasta 18

3
Triciclo Rueda uno a 3

1 Contiene 12,24
Cartón de huevos Huevo uno a 12 ó 24


Diagrama de Clases

Otros tipos de clases:
• Parametrizada: permiten generalizar la definición de una clase
o definir grupos de clases para que, mediante los parámetros,
se puedan crear luego las clases reales. Es como una clase que
aún no ha sido completamente especificada. En el entorno de
programación se conocen como “Templates”. (C++ lo
soporta).

Clase
Parametrizada


Diagrama de Clases

• De utilidad: son agrupaciones de variables globales y
funciones que se conjugan en una clase representados como
atributos y métodos respectivamente. No son clases en
realidad pero son útiles en aquellos lenguajes de programación
no completamente orientados a objetos (como C++),
para darle una connotación más formal de orientación a
objetos y no dejar elementos dispersos que queden fuera de
algún objeto .

Clase de Utilidad


Diagrama de Clases

• Metaclases y clases instanciadas: Las metaclases son clases
cuyas instancias no son objetos sino otras clases, es decir, es
una clase para crear clases. Son útiles en sistemas donde se
requiere la creación de clases de forma dinámica (por ejemplo
en Smalltalk). Las clases instanciadas son instancias de
metaclases. La relación de instanciación se hace mediante una
dependencia.

Metaclase Clase Instanciada


Diagrama de Clases

Paquetes:
• Es un mecanismo de agrupamiento para organizar elementos
del modelo en grupos semánticamente relacionados. Pueden
importar elementos de otros paquetes. Los paquetes se pueden
relacionar por generalización y dependencia.


Diagrama de Clases

Interfaces:
• Un paquete, componente o clase que tiene una interfaz
conectada a él, se dice que implementa o soporta la interfaz
específica dado que soporta el comportamiento definido en
esa interfaz. Se pueden ver como contratos de colaboración
entre los diferentes elementos del modelo. Una interfaz sólo se
describe como operaciones abstractas. Se representan
mediante pequeños círculos asociado (línea sólida) al
elemento del modelo (uno a uno). Una clase que usa la
interfaz se conecta mediante una relación de dependencia.

Clase A Clase B

Una interfaz


Diagrama de Clases

Ejemplo:


Diagrama de Objetos

Definición y notación:
• El diagrama de objetos representa la asociación y relaciones
entre objetos. Sigue la misma notación que el diagrama de
clases a diferencia de que en lugar de identificar una clase,
identifica una instancia particular u objeto.
• El identificador de un objeto puede ir acompañado del
identificador de la clase asociada y un separador entre ambos
nombres. Por lo general se subraya el identificador de los
objetos.
• Se pueden usar para ejemplificar un diagrama de clases con
instancias explícitas. También se pueden usar como parte de
los diagramas de colaboración en el modelo dinámico.


Diagrama de Objetos

Ejemplo:


Diagrama de Estados

Definición:
• Representa el comportamiento del sistema en el tiempo.
• Por lo general se hace un diagrama de estados por clase.
• El comportamiento es modelado en términos del estado en el
cual se encuentra un objeto.
• Se indican qué acciones se ejecutan en cada estado y cuál es el
nuevo estado al que se llega luego de un determinado evento.
• Los estados representan condiciones que son válidas en el
objeto en un momento dado; los eventos representan la causa
que origina el cambio desde un estado a otro.


Diagrama de Estados

Notación:

Estado inicial

Estado final

Estado

Transición con el
Condicional mismo estado

Estado1 Transición / Evento Estado2


Diagrama de Estados

Ejemplo:

Cerrar Abrir

Abrir

Cerrada Abierta

Cerrar


Diagrama de Componentes

Definición:
• Permite modelar la estructura del software, incluyendo
dependencias entre componentes en código fuente,
componentes en código binario y componentes ejecutables.
• Establece relaciones de dependencia entre componentes y/o
paquetes de componentes.
• Un componente es un grupo de clases que trabajan
estrechamente. Se pueden clasificar según los su existencia
en: tiempo de compilación; tiempo de enlace; tiempo de
ejecución y en varios de esos momentos.
• Una dependencia indica que un elemento del modelo (fuente)
depende de otro (objeto), de manera que un cambio en el
elemento objeto puede significar cambiar el elemento fuente.



Tipos de componentes:
• Componentes para trabajar en el producto: también llamados
componentes fuente, son típicamente archivos de código
fuente usados para implementar una o más clases (archivos de
base de datos, código fuente, recursos gráficos, etc.).
• Componentes de distribución: también llamados componentes
binarios, conforman el fundamento de los sistemas ejecutables
y son típicamente archivos de código objeto que se generan a
partir de los componentes anteriores (ejecutables, DLL,
controles ActiveX, etc.).
• Componentes de ejecución: son los creados como resultado de
un sistema en ejecución (archivos temporales, índices de
búsqueda, etc.).



Ejemplo:


Diagrama de Colaboración

Definición:
• Muestra la interacción entre objetos organizada alrededor de
los objetos.
• Contiene:
o Objetos dibujados como rectángulos. Tres maneras de
identificación: el nombre del objeto, el nombre del objeto y
su clase o sólo el nombre de la clase (objeto anónimo).
o Enlaces entre objetos mediante líneas que conectan dichos
objetos.
o Mensajes que se muestran con un texto descriptivo y una
flecha que indica el sentido de la ejecución desde el cliente
hacia el que suple el evento.


Diagrama de Colaboración

Ejemplo:


Diagrama de Secuencias

Definición:
• Muestra la interacción entre objetos estructurada u ordenada
en una secuencia de eventos en el tiempo.
• Representan el comportamiento del sistema de una forma
amplia.
• Se lee de izquierda a derecha y de arriba abajo.
• Por lo general están relacionados con la realización de los
casos de uso. Pueden haber varios diagramas de secuencia por
caso de uso.
• Pueden ser excesivamente grandes si están involucradas
muchas clases u objetos en la interacción, en comparación con
los diagramas de colaboración.



Notación:
Objetos

Objeto1 Objeto2
: Actor
Mensaje
recurrente

Mensaje

Activación

Retorno

Línea de vida
del objeto



Ejemplo:


Diagrama de Distribución

Definición:
• Modela la distribución en tiempo de ejecución de los elementos
de procesamiento y componentes de software, procesos y
objetos asociados.
• Tiene que ver con la arquitectura física del sistema: ¿dónde
están localizados físicamente los programas que implementan
las clases y objetos?, ¿en cuáles computadoras se ejecutan estos
procesos?, ¿cómo se conectan las diferentes computadoras que
requiere el sistema para funcionar?.
• Se modelan los nodos (objetos físicos o dispositivos) y la
comunicación entre ellos. Cada nodo puede contener instancias
de componentes.



Notación:

Procesador Dispositivo

Conexión



Ejemplo:


Uml

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Uml

Similar a Uml (20)

Más de karlalopezbello

Más de karlalopezbello (20)

Uml