Introducción a

UML

Marcela Varas
Contenidos
1. UML: qué es
2. UML Parte Estática
3. Taller
 1. UML: Qué es

Lo que implica que sea unificado

Componentes: Vistas y Diagramas
Ejemplos
Unified Modeling Language

 Lenguaje de Modelado Visual de Propósito

general
 Usos:
 Especificar, visualizar, construir y documentar
artefactos de un sistema software.
 Se diseñó de manera de independizarlo del
método de desarrollo, y se intenta que sea
aplicable a todas las etapas del ciclo de vida
del software
UML: “Unificado”
 Cruza los métodos y notaciones anteriores
 Cruza los ciclos de desarrollo
 Cruza los dominios de aplicación
 Cruza las plataformas y lenguajes de
implantación
 Cruza los procesos de desarrollo
 Cruza los conceptos internos
UML: Componentes
 Vista Estática
 Vista de Casos de Uso
 Vista de Interacción
 Diagrama de Secuencia
 Diagrama de Colaboración
 Vista de la Máquina de Estados
 Vista de Actividades
 Vista Física
 Vista de la Gestión del Modelo
 Constructores de Extensibilidad
UML Estático
Vista Diagramas Conceptos Principales

Vista Estática Diagrama de Clase, Asociación,

Clases Generalización
Dependencia, Realización,
Interfase

Vista de Casos de Diagrama de Caso de uso, Actor,

Uso Casos de Uso Asociación, Extensión,
Inclusión, Generalización de
caso de uso
Vista de Diagrama de Componente, Interfaz,
Implementación Componentes Dependencia, Realización

Vista del Diagrama de Nodo, Componente,

despliegue Despliegue Dependencia, Locación
(deployment)
Diagrama de Clases
Diagrama de Casos de Uso
Diagrama de Componentes
Diagrama de Despliegue
UML Dinámico
Vista Diagramas Conceptos
Principales

Vista de Máquina Diagrama de Estado, Evento,

de Estados Estados Transición, Acción
(statechart)
Vista de Diagrama de Estado, Actividad,
actividades Actividades Transición de
compleción,
Juntura (join),
Bifurcación (fork)
 
Vista de Diagrama de Interacción,
Interacción Secuencia Objeto, Mensaje,
Activación
Diagrama de Colaboración,
Colaboración Interacción, Rol de
colaboración,
Mensaje
Diagrama de Estados
Diagrama de Actividades
Diagrama de Secuencia
Diagrama de Colaboración
UML
Gestión del Modelo
Vista Diagramas Conceptos
Principales

Vista de la gestión Diagrama de Paquete,

del modelo Clases Subsistema,
Modelo

Extensibilidad
Vista Diagramas Conceptos
Principales

Todas Todos Restricción, Estereotipo,

Valores tagged
(etiquetados)
Vista de la Gestión del Modelo
Extensibilidad
2. UML Parte Estática

Diagrama de Casos de Uso

Diagrama de Clases
Diagrama de Casos de Uso
 Modela la funcionalidad de un sistema
percibido desde el usuario externo (actor).
 Un caso de uso es una unidad de
funcionalidad coherente expresado como una
transacción entre actores y el sistema.
 Pueden describirse en varios niveles de
detalle.
 Un caso de uso se implementa como una
colaboración en la vista de interacción.
Diagrama de Casos de Uso:
Elementos
Actor:
 rol que juega un Caso de Uso:
usuario con respecto al  Operación o tarea
sistema. específica que se
 un Actor no realiza tras una orden
necesariamente de algún agente
representa a una externo, originada por
persona en particular, una petición de un
sino más bien la labor actor o bien desde la
que realiza frente al invocación desde otro
sistema. caso de uso
Diagrama de Casos de Uso:
Relaciones
Asociación:
Dependencia o Instanciación:
 Es el tipo de relación
 Es una forma muy
más básica que indica
la invocación desde un particular de relación
actor o caso de uso a entre clases, en la cual
otra operación (caso de una clase depende de
uso). otra, es decir, se
instancia (se crea).
Diagrama de casos de Uso:
Relaciones de Generalización
 Este tipo de relación esta
orientado exclusivamente
para casos de uso (y no
para actores).
 Se diferencian por el
estereotipo <<uses>> (uso)
o (<<extends>>) (herencia).
 extends: Se recomienda
utilizar cuando un caso de
uso es similar a otro (en
sus características).
 uses: Se recomienda
utilizar cuando se tiene un
conjunto de
características que son
similares en más de un
caso de uso y no se
desea mantener copiada
la descripción de la
característica.
Diagrama de Casos de Uso: Ejemplo
Máquina Recicladora

El sistema debe :
1. Registrar el número de ítemes ingresados.
2. Imprimir un recibo cuando el usuario lo solicita, que incluye
(a) una descripción de lo depositado, (b) el valor de cada
item y (c) el total
3. El usuario/cliente presiona el botón de comienzo
4. Existe un operador que desea saber lo siguiente: (a) Cuántos
ítemes han sido retornados en el día y (b) al final de cada día,
un resumen de todo lo depositado.
5. El operador debe además poder cambiar información
asociada a ítemes y dar una alarma en el caso de que (a) un
item se atore o (b) no hay más papel.
Máquina Recicladora:
Identificación de Actores
Máquina Recicladora:
Diagrama Completo
Diagrama de Clases
 Modela los conceptos del dominio de la
aplicación.
 Permite visualizar las relaciones entre las
clases que involucran el sistema
 Un diagrama de clases está compuesto por
los siguientes elementos:
 Clases: atributos, operaciones y visibilidad.
 Relaciones: Herencia, Composición, Agregación,
Asociación y Uso.
 Responsabilidades
Diagrama de Clases: Elementos
Clase
 Es la unidad básica
que encapsula toda la
información de un Tipo
de Objeto (un objeto es
una instancia de una
clase).
Diagrama de Clases: Elementos
Atributo
 Los atributos describen  private (-, ): Indica que el
a una clase. Pueden atributo sólo será accesible
desde dentro de la clase
ser Públicos, Privados (sólo sus métodos lo pueden
o Protegidos. acceder).
 public (+, ): Indica  protected (#, ): Indica que
que el atributo será el atributo no será accesible
desde fuera de la clase, pero
visible tanto dentro si podrá ser accesado por
como fuera de la clase, métodos de la clase además
es decir, es accesible de las subclases que se
desde todos lados. deriven (herencia)
Diagrama de Clases: Elementos
Operaciones (métodos)
 Las operaciones o métodos
de una clase describen la
forma en la cual ésta
interactúa con su entorno.
Pueden ser Públicas,
Privadas o Protegidas.
 public (+, ): Indica que el
método será visible tanto
dentro como fuera de la
clase, es decir, es accesible
desde todos lados.
 private (-, ): Indica que el
método sólo será accesible
desde dentro de la clase
(sólo otros métodos de la
misma clase lo pueden
acceder).
 protected (#, ): Indica que
el atributo no será accesible
desde fuera de la clase, pero
si podrá ser accesado por
métodos de la clase además
de las subclases que se
deriven (herencia)
Diagrama de Clases: Elementos
Relaciones entre Clases
 Las clases interrelacionadas modelan un sistema
en su dimensión estática.
 Existen tres tipos de relaciones básicas:
 Dependencia
 Generalización
 Asociación
Relaciones entre Clases:
Dependencia (instanciación o uso)

 Un cambio en la clase  La interpretación más

independiente frecuente es la de uso:
(Aplicación) puede una clase usa a otra
afectar a la clase como argumento de
dependiente (Ventana) una operación.
 El objeto creado no se
almacena en el objeto
que lo crea.
Relaciones entre Clases:
Generalización
 Relaciona una  Una clase sin
abstracción general superclases es una
(superclase) con una clase raíz
más concreta del  Una clase sin
mismo tipo (subclase) subclases es una clase
 Una clase puede tener hoja
cero, una (herencia
simple) o más
superclases (herencia
múltiple)
Relaciones entre Clases:
Generalización - Polimorfismo
 Una generalización da a lugar al polimorfismo
entre clases de una jerarquía de
generalizaciones.
 Un objeto de una subclase puede sustituir a un
objeto de la superclase en cualquier contexto. Lo
inverso no es cierto
 Una operación de la subclase con igual signatura
que una operación de la superclase la anula y
sustituye.
 El polimorfismo es muy útil en la
programación.
Relaciones entre Clases:
Generalización
Relaciones entre clases:
Asociación
 Relación estructural  Tiene multiplicidad, que
entre las clases.
 En general es simétrica
 Tiene un nombre, que
la describe (verbo, con
dirección de lectura)
 Puede tener un rol que
describe el papel
específico que una
clase juega en una
asociación.
especifica por cada clase el
número de objetos de la clase
opuesta que se relacionan con
un solo objeto de dicha clase a
través de la asociación:
1 : uno
0..1 : cero o uno
3 : tres
*: muchos
1..*: al menos uno
2,6,7: dos, seis o siete
2-4, 10-12 : de dos a cuatro y de
diez a doce
Relaciones entre clases:
Asociación
Relaciones entre Clases
Agregación y Composición
Permite modelar objetos complejos, en base a relaciones
todo –parte.
 Composición
 Relación estática, en
donde el tiempo de vida
del objeto incluido está
condicionado por el tiempo
de vida del que lo incluye.
 El Objeto base se contruye
a partir del objeto incluido,
es decir, es "parte/todo“,
como un parámetro
pasado “por valor”.
 Agregación
 Relación dinámica, en
donde el tiempo de vida del
objeto incluido es
independiente del que lo
incluye.
 El objeto base utiliza al
incluido para su
funcionamiento, como un
parámetro pasado “por
referencia”.
Relaciones entre Clases:
Agregación y Composición

Agregación Composición
(Por referencia) (Por valor)
Diagrama de Clases: Elementos
Responsabilidades
La distribución de
responsabilidades en un
sistema, se realiza
identificando un conjunto
de clases que colaboran
entre sí para llevar a cabo
algún comportamiento.
Luego hay que identificar
el conjunto de
responsabilidades para
cada clase
Diagrama de Clases
 3. Caso

Para el caso descrito, desarrolle:

Diagrama de Casos de Uso

Diagrama de Clases
Gestión de Proyectos de
Informática
El sistema debe manejar lo siguiente:
 Unidad organizacional que solicita el proyecto
 Nombre del proyecto
 Organización del proyecto
 Planificación del proyecto (actividades, responsables,
plazos, recursos asignados)
 Control del proyecto (nivel de avance, productos entregados)
 Se debe, además, manejar información de los recursos
humanos involucrados ( nombre, perfil, filiación ) .
El sistema debe entregar:
 Plan del proyecto
 Avance del proyecto
Bibliografía y Referencias:
Fundamental

 James Rumbaugh, Ivar Jacobson, Grady

Booch, “The Unified Modeling Language
Reference Manual”, Addison Wesley, 1999
 Craig Larman, “UML y Patrones”, Prentice
Hall, 1999
 OMG www.omg.org
Bibliografía y Referencias
Complementaria
 Rational www.rational.com
 Robert Muller, “Database Design For Smarties:
Using UML for Data Modeling”, Morgan Kaufmann,
1999
 Luis Guerrero, “Taller de UML”, DCC, Universidad
de Chile, 2002, www.dcc.uchile.cl/~luguerre/cc61j
 Patricio Salinas, “Tutorial de UML”, DCC,
Universidad de Chile, 2000,
www.dcc.uchile.cl/~psalinas/uml