Introducción a UML

. Diciembre de 2002

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

Contenidos
1. 2. 3. 4. Conceptos Básicos [0.5 hora] UML: qué es [0.5 hora] UML Parte Estática [1 hora] 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

Dimensiones de los Sistemas Software
Dimensión 1: Tipo de Componente
Interfaz - Lógica de Procesamiento Repositorio

Conceptos Básicos:

Dimensión 2: Tipo de Comportamiento
Estático – Dinámico - Funcional

Dimensión 3: Nivel de Abstracción
Conceptual – Lógico -Físico

2

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

Conceptos Básicos:

• 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

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

Conceptos Básicos:

• 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

construir y documentar artefactos de un sistema software.Unified Modeling Language • Lenguaje de Modelado Visual de Propósito general • Usos: • Especificar. • Se diseñó de manera de independizarlo del método de desarrollo. visualizar. 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 .

Asociación.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 Vista Estática Diagramas Diagrama de Clases Conceptos Principales Clase. Asociación. Generalización Dependencia. Interfase Caso de uso. Dependencia. Generalización de caso de uso Componente. Extensión. Actor. Dependencia. Componente. Interfaz. Locación 6 . Realización Vista de Casos de Uso Diagrama de Casos de Uso Vista de Implementación Diagrama de Componentes Vista del despliegue (deployment) Diagrama de Despliegue Nodo. Inclusión. Realización.

Diagrama de Clases Diagrama de Casos de Uso 7 .

Diagrama de Componentes Diagrama de Despliegue 8 .

Objeto.Vista UMLDiagramas Dinámico Conceptos Principales Diagrama de Estados (statechart) Diagrama de Actividades Estado. Juntura (join). Mensaje. Acción Estado. Mensaje Vista de Máquina de Estados Vista de actividades Vista de Interacción Diagrama de Secuencia Diagrama de Colaboración Diagrama de Estados 9 . Actividad. Bifurcación (fork) Interacción. Activación Colaboración. Evento. Interacción. Transición. Transición de compleción. Rol de colaboración.

Diagrama de Actividades Diagrama de Secuencia 10 .

Diagrama de Colaboración Vista UML Gestión del Modelo Diagramas Diagrama de Clases Conceptos Principales Paquete. Estereotipo. Valores tagged (etiquetados) Todas Todos 11 . Modelo Vista de la gestión del modelo Extensibilidad Vista Diagramas Conceptos Principales Restricción. Subsistema.

Vista de la Gestión del Modelo Extensibilidad 12 .

3..3.. UML Parte Estática A continuación . UML Parte Estática •Diagrama de Casos de Uso •Diagrama de Clases 13 .

sino más bien la labor que realiza frente al sistema. originada por una petición de un actor o bien desde la invocación desde otro caso de uso 14 .Diagrama de Casos de Uso • Modela la funcionalidad de un sistema percibido desde el usuario externo (actor). • 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 usuario con respecto al sistema. • un Actor no necesariamente representa a una persona en particular. • Un caso de uso es una unidad de funcionalidad coherente expresado como una transacción entre actores y el sistema. Caso de Uso: • Operación o tarea específica que se realiza tras una orden de algún agente externo.

15 .Diagrama de Casos de Uso: Elementos 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). Diagrama de casos de Uso: Elementos Relaciones de Generalización • extends: Se recomienda • Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores). en la cual una clase depende de otra. se instancia (se crea). • Se diferencian por el estereotipo <<uses>> (uso) o (<<extends>>) (herencia). • 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. Dependencia o Instanciación: • Es una forma muy particular de relación entre clases. utilizar cuando un caso de uso es similar a otro (en sus características). es decir.

El usuario/cliente presiona el botón de comienzo 4. Registrar el número de ítemes ingresados. 5.Diagrama de Casos de Uso: Ejemplo Máquina Recicladora El sistema debe : 1. 2. Imprimir un recibo cuando el usuario lo solicita. 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. Máquina Recicladora: Identificación de Actores 16 . (b) el valor de cada item y (c) el total 3. que incluye (a) una descripción de lo depositado. 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.

Agregación. operaciones y visibilidad. • Responsabilidades 17 . • Relaciones: Herencia. Composición.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. Asociación y Uso.

pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (herencia) 18 . ): Indica que el atributo será visible tanto dentro como fuera de la clase. protected (#.• Es la unidad básica que encapsula toda la información de un Tipo de Objeto (un objeto es una instancia de una clase). es decir. Pueden ser Públicos. Diagrama de Clases: Elementos Clase • Los atributos describen a una clase. Privados o Protegidos. ): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden acceder). Diagrama de Clases: Elementos Atributo • • private (-. ): Indica que el atributo no será accesible desde fuera de la clase. • public (+. es accesible desde todos lados.

• Las operaciones o métodos de una clase describen la forma en la cual ésta interactúa con su entorno. ): Indica que el método será visible tanto dentro como fuera de la clase. • Existen tres tipos de relaciones básicas: • Dependencia • Generalización • Asociación 19 . 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. • protected (#. • public (+. Diagrama de Clases: Elementos Operaciones (métodos) • private (-. Pueden ser Públicas. es decir. Privadas o Protegidas. es accesible desde todos lados. ): 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). ): Indica que el atributo no será accesible desde fuera de la clase.

Relaciones entre Clases: Generalización • Relaciona una abstracción general (superclase) con una más concreta del mismo tipo (subclase) • Una clase puede tener cero. una (herencia simple= o más superclases (herencia múltiple) • Una clase sin superclases es una clase raíz • Una clase sin subclases es una clase hoja 20 .Relaciones entre Clases: Dependencia (instanciación o uso) • Un cambio en la clase independiente (Aplicación) puede afectar a la clase dependiente (Ventana) • La interpretación más frecuente es la de uso: una clase usa a otra como argumento de una operación. • El objeto creado no se almacena en el objeto que lo crea.

• Un objeto de una subclase puede sustituir a un objeto de la superclase en cualquier contexto.Polimorfismo • Una generalización da a lugar al polimorfismo entre clases de una jerarquía de generalizaciones. 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: Generalización .

6. • En general es simétrica • Tiene un nombre. seis o siete 2-4...Relaciones entre clases: Asociación • Relación estructural entre las clases. 10-12 : de dos a cuatro y de diez a doce Relaciones entre clases: Asociación 22 .1 : cero o uno 3 : tres *: muchos 1. que 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.*: al menos uno 2. que la describe (verbo. • Tiene multiplicidad.7: dos. con dirección de lectura) • Puede tener un rol que describe el papel específico que una clase juega en una asociación.

es decir. en donde el tiempo de vida del objeto incluido está condicionado por el tiempo de vida del que lo incluye. • • Agregación Relación dinámica. en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. en base a relaciones todo –parte.Relaciones entre Clases Agregación y Composición Permite modelar objetos complejos. • • Composición Relación estática. como un parámetro pasado “por valor”. El Objeto base se contruye a partir del objeto incluido. El objeto base utiliza al incluido para su funcionamiento. es "parte/todo“. • • Relaciones entre Clases: Agregación y Composición Agregación (Por referencia) Composición (Por valor) 23 . como un parámetro pasado “por referencia”.

se realiza identificando un conjunto de clases que colaboran entre sí para llevar a cabo algún comportamiento.Diagrama de Clases: Elementos Responsabilidades La distribución de responsabilidades en un sistema. Luego hay que identificar el conjunto de responsabilidades para cada clase Diagrama de Clases 24 .

4..4. Diseño de Bases de Datos con UML A continuación . Diseño de Bases de Datos con UML •Consideraciones Generales •Bases de datos OO y ObjetoRelacionales •Consideraciones de Diseño •Patrones 25 ..

posibilitando que sean compartidos por múltiples usuarios y aplicaciones. • 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.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. 26 . 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.

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 Orientadas a Objetos • • • • • Herencia Ciclo de vida del objeto Listas y punteros : no normalización Operaciones Diferentes arquitecturas.

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 .

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. 29 .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. • Procedimientos almacenados: operación que el sistema no asocia explícitamente con una clase.

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 .

son sólo valores. • Extensión: se declara explícitamente el conjunto de objetos que pertenecen al dominio • Intensión: predicado lógico. • Los dominios se declaran por extensión o intensión. estructura y enumeración) para definir dominios. • Se deben utilizar los constructores de tipos de datos (primitiva.Restricciones y Reglas del Negocio: Dominios • El dominio de un atributo es el conjunto de valores que dicho atributo mapea. 31 . • 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.

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

33 .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. Se utiliza para representar jerarquías parte-todo en la base de datos. 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.

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

Patrón Party Patrón Document 35 .

Patrón Land Record Región Comuna Acto Access Management 36 .

37 .Gerencia (stewardship) 5... Caso A continuación .

perfil. 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. además. Caso Para el caso descrito. recursos asignados) • Control del proyecto (nivel de avance. El sistema debe entregar: • Plan del proyecto • Avance del proyecto 38 . productos entregados) • Se debe. plazos. filiación ) . responsables. manejar información de los recursos humanos involucrados ( nombre.5.

“The Unified Modeling Language Reference Manual”. 1999 • OMG www. “UML y Patrones”. Ivar Jacobson. 1999 • Craig Larman. Addison Wesley.omg. Grady Booch.org 39 . Prentice Hall.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.

udec.cl/~moddatos/apuntes • Luis Guerrero. “Tutorial de UML”.cl/~psalinas/uml Introducción a UML Marcela Varas Ingeniero Civil informático Mag. www. DCC. 1999 • Marcela Varas. 2000.dcc. DCC. www.uchile. de la Computación 40 .dcc.cl/~luguerre/cc61j • Patricio Salinas. “Apuntes de Modelamiento de Datos”.inf.rational. Universidad de Chile. Universidad de Chile. 2002. en Cs. “Database Design For Smarties: Using UML for Data Modeling”. asignaturas. “Taller de UML”.uchile. Morgan Kaufmann.Bibliografía y Referencias Complementaria • Rational www.com • Robert Muller.