Introducción a UML

Introducción a UML

Fuente: 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áticoVista Diagramas Conceptos Principales

Vista Estática Diagrama de Clases

Clase, Asociación, GeneralizaciónDependencia, Realización, Interfase

Vista de Casos de Uso

Diagrama de Casos de Uso

Caso de uso, Actor, Asociación, Extensión, Inclusión, Generalización de caso de uso

Vista de Implementación

Vista del despliegue (deployment)

Diagrama de Componentes

Componente, Interfaz, Dependencia, Realización

Diagrama de Despliegue

Nodo, Componente, Dependencia, Locación

Diagrama de Clases

Diagrama de Casos de Uso

Diagrama de Componentes

Diagrama de Despliegue

UML DinámicoVista Diagramas Conceptos

Principales

Vista de Máquina

de Estados

Diagrama de

Estados

(statechart)

Estado, Evento,

Transición, Acción

Vista de

actividades

Diagrama de

Actividades

Estado, Actividad,

Transición de

compleción,

Juntura (join),

Bifurcación (fork)

Vista de

Interacción

Diagrama de

Secuencia

Interacción,

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

UMLGestión del Modelo

Vista Diagramas Conceptos Principales

Vista de la gestión

del modelo

Diagrama de

Clases

Paquete,

Subsistema,

Modelo

Vista Diagramas Conceptos Principales

Todas Todos Restricción, Estereotipo,

Valores tagged

(etiquetados)

Extensibilidad

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 usuario con respecto al sistema.

� un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.

Caso de Uso:

� Operación o tarea específica que se realiza tras una orden de algún agente externo, originada por una petición de un actor o bien desde la invocación desde otro caso de uso

Diagrama de Casos de Uso: 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).

Dependencia o Instanciación:

� Es una forma muy

particular de relación entre clases, en la cual

una clase depende de 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: EjemploMá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: ElementosClase

� 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: ElementosAtributo

� Los atributos describen a una clase. Pueden

ser Públicos, Privados o Protegidos.

� public (+, ): Indica que el atributo serávisible tanto dentro

como fuera de la clase, es decir, es accesible

desde todos lados.

� private (-, ): Indica que

el atributo sólo será

accesible desde dentro de

la clase (sólo sus métodos 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: ElementosOperaciones (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: ElementosRelaciones 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

� 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.

Relaciones entre Clases:Dependencia (instanciación o uso)

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

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

� Tiene multiplicidad, 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..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 ClasesAgregación y Composición

� 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”.

Permite modelar objetos complejos, en base a relaciones todo –parte.

Relaciones entre Clases:Agregación y Composición

Agregación(Por referencia)

Composición(Por valor)

Diagrama de Clases: ElementosResponsabilidades

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 ReferenciasComplementaria

� 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