Introducción a UML .

Diciembre de 2002

Marcela Varas
Ingeniero Civil informático
Mag. en Cs. de la Computación

Contenidos

1. Conceptos Básicos [0.5 hora]

2. UML: qué es [0.5 hora]
3. UML Parte Estática [1 hora]
4. Diseño de Bases de Datos con UML [1
hora]
5. Caso [1 hora]

1
 1. Conceptos Básicos

•Dimensiones de los Sistemas Software

•Paradigma de la Orientación a Objetos

Conceptos Básicos:
Dimensiones de los Sistemas
Software
Dimensión 1: Tipo de Componente
Interfaz - Lógica de Procesamiento -
Repositorio
Dimensión 2: Tipo de Comportamiento
Estático – Dinámico - Funcional
Dimensión 3: Nivel de Abstracción
Conceptual – Lógico -Físico

2
 Conceptos Básicos:
Paradigma Orientación a Objetos
• Paradigma procedural ( hasta fines de los 70s)
• Tipo de Componente: Lógica de Procesamiento
• Nivel de Abstracción: Físico y Lógico
• Tipo de Comportamiento: Funcional

• Paradigma Bases de Datos (aún vigente)

• Tipo de Componente: Repositorio
• Nivel de Abstracción: alcanza hasta el nivel conceptual
• Tipo de Comportamiento: Estático

Conceptos Básicos:
Paradigma Orientación a Objetos
• Paradigma Orientación a Objetos (desde
principios de los 80s)
• Tipo de Componente: Todos
• Tipo de Comportamiento: Todos
• Nivel de abstracción: Todos

• Ideas Fuerza:
• Encapsulamiento (-> cohesión)
• Reuso
• Bajo Acoplamiento
• Mayor Expresividad y Naturalidad

3
 2. UML

A continuación ...

2. UML: Qué es

•Lo que implica que sea unificado

•Componentes: Vistas y Diagramas
•Ejemplos

4
 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

5
 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)

6
 Diagrama de Clases

Diagrama de Casos de Uso

7
Diagrama de Componentes

Diagrama de Despliegue

8
Vista
UMLDiagramas
Dinámico 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

9
Diagrama de Actividades

Diagrama de Secuencia

10
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)

11
Vista de la Gestión del Modelo

Extensibilidad

12
 3. UML Parte Estática

A continuación ...

3. UML Parte Estática

•Diagrama de Casos de Uso

•Diagrama de Clases

13
 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: Caso de Uso:
• rol que juega un • Operación o tarea
usuario con respecto al específica que se
sistema. realiza tras una orden
de algún agente
• un Actor no
externo, originada por
necesariamente
una petición de un actor
representa a una
o bien desde la
persona en particular,
invocación desde otro
sino más bien la labor
caso de uso
que realiza frente al
sistema.

14
 Diagrama de Casos de Uso:
Elementos
Relaciones
Asociación: Dependencia o Instanciación:
• Es el tipo de relación • Es una forma muy
particular de relación entre
más básica que indica la clases, en la cual una clase
invocación desde un depende de otra, es decir,
actor o caso de uso a se instancia (se crea).
otra operación (caso de
uso).

Diagrama de casos de Uso:

Elementos
Relaciones de Generalización
• extends: Se recomienda
utilizar cuando un caso de
uso es similar a otro (en sus
características).
• uses: Se recomienda utilizar
• Este tipo de relación esta cuando se tiene un conjunto
orientado exclusivamente de características que son
para casos de uso (y no para similares en más de un caso
actores). de uso y no se desea
• Se diferencian por el mantener copiada la
estereotipo <<uses>> (uso) descripción de la
característica.
o (<<extends>>)
(herencia).

15
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

16
 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

17
 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 a • private (-, ): Indica que el
una clase. Pueden ser atributo sólo será accesible
Públicos, Privados o desde dentro de la clase (sólo
sus métodos lo pueden
Protegidos.
acceder).
• public (+, ): Indica que el • protected (#, ): Indica que
atributo será visible tanto el atributo no será accesible
dentro como fuera de la desde fuera de la clase, pero si
clase, es decir, es accesible podrá ser accesado por
desde todos lados. métodos de la clase además de
las subclases que se deriven
(herencia)

18
 Diagrama de Clases:
Elementos
Operaciones (métodos)
• Las operaciones o métodos • private (-, ): Indica que
de una clase describen la el método sólo será accesible
forma en la cual ésta desde dentro de la clase
interactúa con su entorno. (sólo otros métodos de la
Pueden ser Públicas, misma clase lo pueden
Privadas o Protegidas. acceder).
• public (+, ): Indica que el • protected (#, ): Indica
método será visible tanto que el atributo no será
dentro como fuera de la accesible desde fuera de la
clase, es decir, es accesible clase, pero si podrá ser
desde todos lados. 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

19
 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 mismo • Una clase sin subclases
tipo (subclase) es una clase hoja
• Una clase puede tener
cero, una (herencia
simple= o más
superclases (herencia
múltiple)

20
 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

21
 Relaciones entre clases:
Asociación
• Relación estructural • Tiene multiplicidad, que
entre las clases. especifica por cada clase el
• En general es simétrica número de objetos de la clase
opuesta que se relacionan con
• Tiene un nombre, que un solo objeto de dicha clase
la describe (verbo, con a través de la asociación:
1 : uno
dirección de lectura) 0..1 : cero o uno
• Puede tener un rol que 3 : tres
describe el papel *: muchos
1..*: al menos uno
específico que una clase
2,6,7: dos, seis o siete
juega en una 2-4, 10-12 : de dos a cuatro y
asociación. de diez a doce

Relaciones entre clases:

Asociación

22
 Relaciones entre Clases
Agregación y Composición
Permite modelar objetos complejos, en base a relaciones
todo –parte.

• Composición • Agregación
• Relación estática, en donde • Relación dinámica, en
el tiempo de vida del objeto donde el tiempo de vida del
incluido está condicionado objeto incluido es
por el tiempo de vida del independiente del que lo
que lo incluye. incluye.
• El Objeto base se contruye
• El objeto base utiliza al
a partir del objeto incluido,
es decir, es "parte/todo“, incluido para su
como un parámetro pasado funcionamiento, como un
“por valor”. parámetro pasado “por
referencia”.

Relaciones entre Clases:

Agregación y Composición

Agregación Composición
(Por referencia) (Por valor)

23
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

24
4. Diseño de Bases de Datos
con UML

A continuación ...

4. Diseño de Bases de Datos

con UML

•Consideraciones Generales
•Bases de datos OO y Objeto-
Relacionales
•Consideraciones de Diseño
•Patrones

25
 Consideraciones Generales

• Persistencia
• Restricciones y Reglas del Negocio
• Limitaciones de los Productos
Comerciales
• Patrones Reusables

Bases de Datos Orientadas a

Objetos
• No existe un modelo formal
• Primitivas básicas: objeto y literal.
• Objetos y literales pertenecen a un tipo.
• El estado de un objeto está definido por los valores
actuales de sus propiedades: atributos y relaciones
con otros objetos.
• El comportamiento de un objeto está definido por el
conjunto de operaciones que pueden aplicarse o ser
ejecutadas por el objeto
• Una BDOO almacena objetos, posibilitando que sean
compartidos por múltiples usuarios y aplicaciones.

26
 Bases de Datos Orientadas a
Objetos
• Herencia
• Ciclo de vida del objeto
• Listas y punteros : no normalización
• Operaciones
• Diferentes arquitecturas. Aún no hay
estándar.

Bases de Datos Objeto-Relacionales:

Extensiones de Tipos Básicos
• Linking Dinámico de funciones definidas por el
usuario
• Activación cliente-servidor de funciones definidas por
el usuario
• Integración de funciones definidas por el usuario y
aplicaciones middleware
• Funciones seguras
• Callback en funciones
• Métodos de acceso definidos por el usuario
• Tipos de datos de largo arbitrario
• Manejo de almacenamiento abierto

27
Bases de Datos Objeto-Relacionales:
Objetos Complejos
• Constructores de tipos
• Conjunto de
• Registro de
• Referencia
• Funciones definidas por el usuario
• Tipos de datos complejos de largo arbitrario
• Soporte SQL

Bases de Datos Objeto-Relacionales:

Herencia

• Herencia de datos y funciones

• Sobrecarga
• Herencia de tipos, no tablas
• Herencia múltiple

28
Bases de Datos Objeto-Relacionales:
Sistema de Reglas

• Eventos y Acciones son recuperadas

como actualizaciones
• Integración de reglas con herencia y
extensiones de tipos
• Ejecución de reglas semánticas
• Control de ciclos infinitos

Consideraciones de Diseño

• OID
• Persistencia
• Definición del Comportamiento:
• Operaciones: serán métodos persistentes. Se diseñan
dejando abierta la implementación (por restricciones de
los productos comerciales)
• Triggers:Manejador de eventos. Se declaran en UML con
el estereotipo «signal» en el método.
• Procedimientos almacenados: operación que el sistema
no asocia explícitamente con una clase.

29
 Restricciones y Reglas del Negocio:
Identificación
• Identidad de Objeto y Restricción de Unicidad
• Identificación implícita (OID) versus
• Identificación explicita (value based)
• Se declaran con tagged values:
• {OID}
• {alternate OID}
• Propiedades de unicidad y minimalidad

Restricciones y Reglas del

Negocio:
Identificación

30
 Restricciones y Reglas del Negocio:
Dominios
• El dominio de un atributo es el conjunto de valores
que dicho atributo mapea.
• Los dominios se declaran por extensión o intensión.
• Extensión: se declara explícitamente el conjunto de objetos
que pertenecen al dominio
• Intensión: predicado lógico.
• UMNL no especifica un modelo para dominios, sólo
tipos de datos

Restricciones y Reglas del Negocio:

Dominio – Tipos de Datos
• Un tipo de dato es un tipo cuyos valores no
tienen identidad, son sólo valores.
• Se deben utilizar los constructores de tipos de
datos (primitiva, estructura y enumeración)
para definir dominios.

31
 Restricciones y Reglas del Negocio:
Restricciones Complejas
• OCL: Object Constraint Language
• Lenguaje declarativo que se puede utilizar en
clases y operaciones, entre otros.
• No soportado por la herramientas.
• Se declaran utilizando notaciones en los
diagramas.

Restricciones y Reglas del Negocio:

Utilizando Notaciones para Declararlas

32
 Patrones de Diseño

• Los patrones de diseño capturan

soluciones que han sido desarrolladas y
evolucionan en el tiempo. Capturan
soluciones probadas y eficientes en
forma sucinta y fácilmente aplicable.
• Conflicto: inhibición de la creatividad
versus reuso y eficiencia.

Patrones de Diseño

• Patrones Abstractos: describen soluciones

genéricas a problemas genéricos.
• Patrón singleton: Asegura que una clase tenga
sólo una instancia en la base de datos.
• Patrón Composite: Representa una estructura de
árbol hehca de distintos tipos de objetos
relacionados. Se utiliza para representar jerarquías
parte-todo en la base de datos.

33
 Patrón Singleton

Patrones de Diseño
• Patrones de Análisis: Es un modelo de un
problema de un dominio específico.
• Patrón party: modela personas y organizaciones y
la relación de empleo entre ellos.
• Patrón Geographic Location Pattern: Modela redes
de áreas geográficas.
• Patrón Process: modela procesos de manufactura
continuos.
• Patrón Document : modela documentos, su
estructura y usuarios.

34
 Patrón Party

Patrón Document

35
Patrón Land Record

Región

Comuna

Acto

Access Management

36
Gerencia (stewardship)

5. Caso

A continuación ...

37
 5. 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

38
 Otras cosas Interesantes

• Proceso Unificado de Desarrollo

• Modelamiento del negocio con UML
• Desarrollo Basado en Componentes
• Uso de Patrones
• Vistas no Cubiertas
• Herramientas de Apoyo

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

39
 Bibliografía y Referencias
Complementaria
• Rational www.rational.com
• Robert Muller, “Database Design For Smarties: Using
UML for Data Modeling”, Morgan Kaufmann, 1999
• Marcela Varas, “Apuntes de Modelamiento de Datos”,
asignaturas.inf.udec.cl/~moddatos/apuntes
• 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

Introducción a UML
Marcela Varas
Ingeniero Civil informático
Mag. en Cs. de la Computación

40