Uml Presentacion

1

UML

2

Referencias

• Eriksson, Hans-Erik: UML 2 Toolkit, ed. Wiley Publishing, 2004.– Es una referencia completa para UML 2.0.

• Fowleer, M.: UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition by Martin Fowler, 2003

– Es UML 2.0. Bastante completo.

• Pilone, D.: UML 2.0 in a Nutshell, 2005– Es UML 2.0. Bastante completo.

• Bennett, S.: Análisis y diseño orientado a objetos de sistemas usando UML 3ª ed, 2006.

– Es UML 2.0. Incluye patrones de diseño y proceso unificado.

• Rumbaugh, J.; Jacobson, J.; Booch, G.: Unified Modeling Language Reference Manual, The Second Edition, 2004.

– Es una referencia clásica.

• Booch, G.; Rumbaugh, J.; Jacobson, I.: Unified Modeling Language User Guide, Addison-Wesley, 1998. (versión en español: "El Lenguaje Unificado de Modelado", Addison-Wesley, Madrid, 1999).

– Es una referencia clásica.

• Tutorial de Borland (http://bdn.borland.com/article/0,1410,31863,00.html)– Referencia resumida y rápida en la web (es UML 1.x)

3

Introducción, I

• Similitud: – Arquitectos, edificios, planos

– Ing. Inf., programas, diagramas

• UML – Unified Modeling Language. Versión 2.0 (finales 2004)

– Diagramas (ing. inf.)• Usados como esquemas y menos con información rigurosa (“planos de arquitectos”)

• Dos modos: – Ingeniería inversa: a partir de código hacer diagramas

– Ingeniería directa: hacer diagramas y luego implementar

• Dominio– Mundo en el que hay definido un problema

• Modelo:– Abstracción de un problema

– Formado por objetos

4

Introducción, II

• Objetos:

– Interaccionan entre sí enviándose mensajes

– Cosas que saben (atributos) y cosas que pueden hacer

(operaciones)

– Los valores de sus atributos determinan sus estados

• Clases:

– Un “diagrama” para un objeto

– Objetos son instancias de clases

5

Diagramas de casos de uso• Válidos támbién en contextos no Orientados a Objetos (OO)

• Lo que hace el sistema (no cómo lo hace)

• Pueden describirse en lenguaje natural

• Escenario: – Una secuencia de operaciones (lo que ocurre al interaccionar con el sistema)

• Caso de uso (un óvalo): – Resumen de escenarios para un caso particular

• Un actor (persona u objeto) establece una comunicación con un caso de uso, que es una línea recta (si es dirigida, es decir con una flecha, indica quién inicia la interacción)

• Diagrama de casos de uso: – Una colección de actores, casos de uso y sus comunicaciones

– Puede contener fronteras de separación (rectángulos)

• Permiten:– Planificar acciones de debugging

– Hacer análisis de requisitos (las acciones completas de los usuarios)

• Pueden contener precondiciones y postcondiciones

• Un caso de uso suele consistir en una tarea completa– Por ejemplo, es más conveniente 2) que 1) para considerarse como un caso de uso:

1. Añadir un artículo al carro de la compra

2. Comprar un artículo

6

Ejemplo, I

7

Ejemplo, II

8

Ejemplo, III (a)

Emisor Receptor

realizar llamada telefonica

9

Ejemplo, III (b)

• Origen levanta receptor

• Suena tono de llamada

• Origen marca cifra (9)

• Para tono de llamada









• Suena alarma destino

• Suena señal origen

• Destino responde

• Para alarma destino

• Para señal origen

• Conexión

• Destino cuelga

• Origen cuelga

Un escenario para el caso de uso

“realizar una llamada telefónica”:

10

Relaciones

• Relaciones entre dos casos de uso– Generalización

• “Es un caso particular de …”

• Herencia de clases en POO (overriding)

• También se puede tener esta relación entre dos actores

– Inclusión (include)• “Implica hacer también …”

– Extensión (extends)• “Se insertará en …” un determinado punto (llamado “punto de

extensión”) dependiendo de una condición

• Si un caso de uso depende de varios casos de uso mediante “extends” tendrá un punto de extensión para cada uno

11

Ejemplo (I)

12

Ejemplo (II)

Representación

alternativa para el actor

“Backup System”

13

Diagramas de clases, I

• Clases y sus relaciones en un contexto OO

• Diagramas estáticos – Muestran lo que interacciona pero no lo que ocurre al interaccionar

• Clase: – Rectángulo

– Nombre de clase (en cursiva si es clase abstracta)

– Atributos y métodos

– Visibilidad (vis) para atributos y métodos• público (+); por omisión para métodos

• privado (-); por omisión para atributos

• protegido (#)

– Atributos• [vis]atributo[[multiplicidad orden] : tipo [= valor-inicial]]

– Tipos: Boolean, Integer, Real, String

– Orden: ordered, unordered

• Atributos de clase subrayados

– Operaciones (métodos)• [vis]metodo[([params]) [:tipo]]

• Métodos de clase subrayados

– Implícitamente, se asume que algunos atributos son “claves primarias”

14

Diagramas de clases, II, (a)

• Relaciones entre clases: – Asociación (binaria) (n-aria también posible)

– Agregación (“es parte de …”)

– Generalización (herencia); “es un caso particular de …”.

• En una asociación o agregación:– Nombre de asociación (verbo) dirigido; Rol (nombre) en un

extremo. Ejemplo: Trabajador, UnidadTrabajo, trabajaEn, suTrabajo

• Navegabilidad (petición de información) en una asociación– Unidireccional

– Bidireccional

rol verbo

15

Diagramas de clases, II, (b)

• Agregación

– Se puede considerar un caso particular de

“asociación” en el que la relación tiene el

nombre “contiene”

• Verbos:

– En nombres de asociaciones, “presente”

– En nombres de métodos, “imperativo”

16

Diagramas de clases, III

• Multiplicidad en una asociación o

agregación:

– 0..1; n..m; 0..*; *; 1, 1..*

• Ejemplo de agregación con multiplicidad

(relación ternaria):

n

m

17

Diagramas de clases, IV

• Dependencia. – Otro tipo de relación (“depende de …”)

– Un cambio en la especificación (interfaz pública) de la 2ª puede forzar cambios en la primera clase

• Observación: – Los atributos no deben ser objetos (utilizar asociaciones en tal caso).

– En los diagramas de clases no suelen aparecen (son detalles de implementación y no de diseño):

• Constructores

• Métodos de acceso (“get/set”)

• Métodos de gestión de elementos de una asociación o agregación (por ejemplo, “add/remove”)

– Algunas asociaciones con multiplicidad 1 hacia algunas clases pueden ser claves externas (“foreign keys”) implícitas

• En UML, a diferencia del modelo relacional de BD, no está previsto el uso de “keys” y se recomienda usar OID (“object ids”): números únicos generados automáticamente para cada objeto. A pesar de eso, siempre existe para cada clase un conjunto implícito de “primary and foreign keys”, que permiten hablar de multiplicidades de asociaciones con otras clases.

18

Diagramas de clases, V

• Tipos de asociación:

– Asociación con condiciones

– Asociación cualificada por un atributo

– Asociación cualificada por una clase

Clase Clase{condiciones}

cualificador

Clase Clase

Clase

19

Diagramas de clases, VI• Tipos de asociación (ejemplos):

– Asociación con condiciones. Por ejemplo, la asociación “contiene” de tipo “1 a muchos” entre las clases “CD” y “Canción:

– Asociación cualificada por un atributo:

• A cada par de la asociación se le asigna un valor (tipo primitivo)

• En una asociación “0..1----*”, el cualificador se coloca desplazado a la izquierda (ya que cada objeto de la clase de la derecha tendría asociado uno o ningún valores del cualificador). Ejemplo: “PartidoPolitico”, “Ciudadano”, “códigoDeAfiliado”

– Asociación cualificada por una clase:

• Es otra asociación entre los pares de una asociación y una clase.

• Ejemplo: Clase “Alumno”, “Clase Asignatura”, relación “matriculado-en” de tipo “muchos-a-muchos”; clase “Nota(numero,calificacion)” y asociación “obtiene” de tipo “muchos-a-uno” entre la asociación y “Nota”.

– No equivalente a tener las clases “Alumno”, “Asignatura” y “Nota” y 2 asociaciones (“Alumno-Nota” y “Asignatura-Nota”). Ver siguiente transparencia.

• En una asociación “0..1-------*”, la clase asociación se coloca desplazada a la izquierda.

{ordenado}

20

Asociación cualificada por una clase

Alumno

Nota

Asignatura* **

1obtiene

matriculado-en

Alumno Asignatura

Nota

El diagrama de arriba implica el de abajo pero no lo contrario.

No son equivalentes.

* *

**

21

Diagramas de clases, VII

• Agregación compuesta

– Agregación fuerte pues al desaparecer el todo,

también lo hace la parte

• Interfaz (en cursiva)

– Conjunto de métodos sin definir

Universidad Facultad

1 1..*

Clase

<<interface>>MiInterfaz

métodos

Clase

MiInterfaz

22

Diagramas de clases, VIII

• La relación también se aplica

para clases abstractas

• Son diferentess:

dependencia

herencia

23

Diagramas de clases, IX

Array

T

Array<Coche>

ConjuntoPersonas

<<bind>><Persona>

Clases plantilla:

24

Ejemplo

25

Diagramas de paquetes

• Un paquete puede tener una o varias clases

y uno o varios subpaquetes.

• Se puede usar relación de dependencia entre

paquetes y/o clases

26

Ejemplo

A

B C

D

27

Diagramas de objetos

• Instancias en lugar de clases– Notación [objeto]:Clase

– Los denominados “enlaces” entre objetos provienen de las

“asociaciones” entre clases. Se pueden etiquetar con el mismo

nombre que para el diagrama de clases, aunque se subrayan.

• Diag. clases:

28

Diagramas de objetos, II

subdepartment

subdepartment subdepartment

subdepartment

29

Diagramas de secuencia, I• Diagramas de clases son estáticos. Diagramas de objetos son

dinámicos.

• Diagramas de secuencia y de colaboración son dinámicos

• Diagrama de secuencia: – Un diagrama que describe los mensajes (MÉTODOS) enviados en función

del tiempo en un contexto que puede ser un caso de uso o un escenario

– El tiempo crece verticalmente hacia abajo (objetos/tiempo)

– Notación [objeto]:Clase

• Se puede utilizar una flecha discontinua (al revés) para indicar el valor que devuelve una llamada a un método

• Dos tipos:– Genéricos (pueden tener bucles, condicionales). Corresponden a un caso

de uso.

– Particulares. Corresponden a un escenario. Por ejemplo, si hay una iteración con 5 vueltas, se visualizan 5 mensajes.

• Un diagrama de secuencia es relativo a un conjunto determinado de objetos y métodos en una interacción, aunque esa interacción involucre a más objetos y métodos

30

Diagramas de secuencia, II• Mensaje:

– [guard] *[iteration] sequence_number : return_variable := operation_name (argument_list)

• El único no opcional: operation_name

• sequence_number : orden temporal del mensaje

• Barra de activación: rectángulo simbolizando la duración de ejecución de un método

– Si un diagrama de secuencia sólo tiene mensajes pero no barras de activación, el “sequence_number” simboliza los mensajes que son generados por otros mensajes, aclarando cuál es el flujo de mensajes.

• Se pueden usar los mensajes especiales “create” y “destroy” para, por simplicidad de notación, poner todos los objetos alineados en la parte superior de un diagrama de secuencia.

31

Ejemplo, I

32

Ejemplo, II, (a)

Bucles y condiciones

33

Ejemplo, II, (a)

Bucles y condiciones

• En lugar de “loop” también es válido, por

ejemplo:

– *[For each worker] (un “for” de C++)

– *[No more workers] (un “while” de C++)

• Condiciones:

34

Ejemplo, III

:Receptor :Linea :Receptor

Origen levanta receptor

Suena tono de llamada

Orig. marca 9 cifras (91...)

Para tono de llamada

Suena señal origen

Destino responde

. . .

Suena alarma destino

35

Diagramas de colaboración

• Llamados de comunicación en UML 2.0

• Combinación de uno de objetos y uno de secuencia

– Sin considerar la línea del tiempo

– Grafo dirigido

– Cada mensaje tiene un número (número de secuencia)

• Jerárquicos, según temporalidad de ejecución

• Si son alternativos (uso de “alt”) o concurrentes (usando el operador “par” de interacción), se utiliza una notación del estilo: “3a”, “3b”, “3c”, etc

• Dos tipos: genéricos o particulares

• Expresa las colaboraciones que tiene cada objeto con el resto de objetos

36

Ejemplo, I

1: Origen levanta receptor

2: Origen marca 9 cifras

1.1: Suena tono llamada

2.1: Para tono llamada

2.3: Suena señal origen

2.2: Suena alarma destino

3: Destino responde

:Receptor :Línea :Receptor

37

Ejemplo, II

38

Otros ejemplos (UML 2.0), I

39

Otros ejemplos (UML 2.0), II

con números de secuencia

1

1.1

1.2

1.3

1.4a

1.5a

1.5b

1.6a

1.4b

1.6b

1.7

40

Operadores de interacción

• “Loop” y “Alt” son ejemplos de operadores

de interacción.

• Otros operadores:

– “Par”

• Hilos o tareas concurrentes

– “Ref”

• Referencia a otro diagrama de secuencia

– Más ejemplos: “Break”, “Opt”, “Critical”, ...

41

Mensajes síncronos y asíncronos

• Dos tipos:

– Mensajes síncronos

• El envío de un mensaje supone esperar al valor de

retorno

– Mensajes asíncronos

• A la vez que se procesa el mensaje, se pueden

procesar otros mensajes distintos. Por defecto,

“create” se considera asíncrono

42

Ejemplos

43

Diagramas de estado (a)

• Un diagrama de estado:

– También tienen sentido en un contexto no OO

– Para un contexto OO:

• Tiene sentido para estados de un objeto de una determinada clase

• Interesa hacerlo sólo para algunas clases, como las que tienen un comportamiento más complejo: interfaces de usuario, …

• Transiciones entre estados de acuerdo a EVENTOS

– Transición: “evento/actividad”. La “actividad” es opcional y se ejecutaría tras emitirse el evento.

– En un diagrama de estados los conceptos de “actividad” y “acción” son equivalentes (¡serán conceptos distintos en un diagrama de actividades!).

– Los conceptos de “evento” y de “mensaje” (método) son distintos

44

Diagramas de estado (b)

• Un nodo para estado inicial y varios posibles nodos finales

• Los estados suelen corresponder a expresiones en “gerundio” (“procesando”, “comprobando”, etc)

• Debe contemplar TODOS los casos de uso posibles

• Eventos:

– nombre_evento (lista_argumentos) [condicion]

• Sólo es obligatorio el “nombre_evento” (sin lista de argumentos si no los tiene)

• Tienen lista de argumentos como cualquier objeto de una clase

45

Diagramas de estado (c)

• En un contexto OO, las actividades se

pueden definir mediante:

– variable_retorno:=

objeto.actividad(lista_argumentos)

• “objeto.” se puede omitir si la actividad se realiza en

el mismo objeto

• “variable_retorno” es opcional

46

Diagramas de estado (d)

• Diseño de diagramas de estado: – Clasificar los estados de un sistema y reconocer los posibles cambios en dichos

estados así como cómo se producen (a causa de los eventos)

• Tipos de eventos– Evento de cambio (EC)

• Emitido cuando una condición se verifica.

• Se representa mediante “[condicion]”

– Evento temporal (ET)• Emitido cuando ha transcurrido un cierto tiempo

– Envío de un mensaje (EM), o equivalentemente la ejecución de un método en un contexto OO, es decir la ejecución de una determinada operación

• Puede provenir de un evento externo (como en una interacción con un usuario)

• Implementación de un diagrama de estado– “State Pattern” (Gang of Four)

• Una clase por cada estado. Una clase controlador que tiene un método por cada tipo de evento. Al final del curso, detalles.

47

Diagramas de estado (e)

• Actividades internas de un estado:– Como si correspondieran a eventos internos: entry, exit, help, …

– Sintaxis similar en estos eventos a las transiciones entre estados

– Eventos “entry” y “exit” lanzados después de entrar o salir de un estado

– Evento “help” al entrar en modo de ayuda

– El poner una “actividad” en “entry” es equivalente a ponerlo en el evento que creó la transición entre estados

– Evento especial “do” (actividad ejecutada todo el tiempo de permanencia en el estado)

• Un ejemplo de evento de cambio muy común es el producido a la finalización de la actividad “do”

• Un evento externo de mensaje puede finalizar la acción del “do”, saliendo del estado

48

Diagramas de estado (f)

Nombre del estado

diag. estados interno (subdiagramas de estados; opcional)

entry / actividad

exit / actividad

do / actividad

help / actividad (actividades internas; opcional)

49

Ejemplo, I, a

Banco Internet (validación);

Press tab OR move cursor to

PIN field/Cursor to PIN

Press shift tab OR

move cursor to

SSN field/Cursor to

SSN

50

Ejemplo, I, b

Banco Internet (validación);

Press tab OR move cursor to

PIN field/Cursor to PIN

Press shift tab OR

move cursor to

SSN field/Cursor to

SSN

ET

EC

EC

EM

EMEM

EM

EM

EMEM

EM

51

Ejemplo, II, a

• Suena la alarma del reloj para indicar que ha llegado la hora predeterminada (hora objetivo)

• Se puede poner la alarma (con una hora objetivo)

• Se puede quitar la alarma

• La alarma del reloj suena cuando se cumple:

alarm=on && objetivo<=hora actual <= objetivo+20s

• Si la alarma está sonando, deja de sonar la alarma del reloj y se quita la alarma si se cumple alguna de las siguientes condiciones;

– Se pulsa cualquier botón

– hora actual>=objetivo+20

52

Ejemplo II, b

Alarma activada

entry/reloj-muestra-alarma-activada

Alarma desactivada

Alarma sonando

do/alarma-sigue-sonando

quitar alarma

poner alarma

tocar cualquier tecla

[20 segundos sonando] / desactivar alarma

[llega-hora-objetivo] / sonar alarma

2 eventos de cambio y

3 eventos de mensaje

53

Ejemplo III, a

• Mientras exploran un castillo, A y B descubren lo que parece ser la entrada de un corredor secreto. Mientras A examina la puerta, B retira una vela del candelabro. En ese momento, la puerta gira 180º, llevándose a A consigo.

• B vuelve a colocar la vela en el candelabro. La puerta gira 360º y A vuelve a quedar separado de B.

• B saca de nuevo la vela. La puerta gira 360º, pero esta vez A le impide cerrarse con su cuerpo. B pasa la vela a A. Los dos amigos fuerzan (empujando cada uno en un extremo) a la puerta a retroceder 180º y de nuevo quedan separados, pero ahora B está dentro y A junto al candelabro.

• A pone la vela en el candelabro.

• Cuando la puerta empieza a girar, A saca la vela. La puerta se detiene tras girar 90º.

• A y B penetran en el corredor para explorarlo

54

Ejemplo III, b

• Sacar y meter la vela del candelabro es un interruptor

• Puerta: – Posición inicial con ángulo 180º

– Gira en sentido de las agujas del reloj (ángulo creciente)

– Con la puerta parada, si se toca el interruptor empieza a moverse

– Con la puerta en movimiento: ¿se toca el interruptor?• No: la puerta gira hasta la posición 0º

• Sí: la puerta gira hasta la posición más cercana múltiplo de 90º

55

Puerta 180

Ejemplo III, c

Puerta 0

0-90

Puerta 270

180-270

90-180 Puerta 90270-360

inter

inter

inter

interinter

inter

inter

inter

Para cada estado “x-y”:

- Existe un “do/mueve-puerta”

- Eventos de cambio: [puerta-en-y]forzar

56

Estados compuestos, I

57

Estados compuestos, II

¡Son hilos !. Se dice que son “ortogonales”

58

Estados compuestos, III

59

Diagramas de estado de protocolo, I

• Describen estados y eventos de una comunicación basada en un protocolo.

• Los eventos son siempre del tipo “eventos de mensaje” en los que únicamente se pueden definir precondiciones y postcondiciones (detrás de “/”), pero no actividades.

• A diferencia de un diagrama de estados normal:

– Los estados no tienen una estructura interna

• Por tanto, no se permiten actividades “exit” o “entry”

– Al poder poner postcondiciones en los eventos, se pueden establecer invariantes en los estados, que pueden ser expresables por ejemplo en OCL

60

Diagramas de estado de protocolo, II

Cuenta corriente

Abierto CerradoClose()

reintegro(cant)

[cant <= balance + saldo]

deposito(cant)

61

Diagramas de estado de protocolo, III

Una puerta con cierre automático

62

Diagramas de actividad (a)• Diagramas aplicables también en contextos no OO

– Son diagramas de flujo (los “organigramas” clásicos en programación)

• Actividad: rectángulo con bordes redondeados

• Actividad: una sucesión de acciones y subactividades– Acción: actividad atómica

• Es común crear diagramas de actividad para casos de uso

• Nodo de acción:– Se sale de ellos al finalizar la acción, de modo similar a como se sale de

un estado en un diagrama de estados al finalizar la actividad de “do”

– En un contexto OO: • Un estado de acción puede afectar a varias clases, pero un estado dentro de

diagrama de estados está siempre asociado a una sola clase

• Una actividad puede tener parámetros o valores de retorno: – Se representan como rectángulos adosados al borde (“pins”)

• Las actividades pueden tener “precondiciones” y “postcondiciones” (expresables mediante “[condicion]” en las líneas de transición entre actividades)

63

Diagramas de actividad (b)

• Pueden existir bifurcaciones salientes (forks, branches) y entrantes (joins, merges) para hilos y condicionales, respectivamente.

– Observación: en diagramas de estados también se pueden utilizar estos “pseudoestados”

• Se pueden crear agrupaciones de actividades (particiones)según el “contexto” en los que se realizan. Si cada actividad pertenece a un solo “contexto”, se tienen “calles” (“swinlanes”).

• Haciendo una similitud para los diagramas de estado:

– Los diagramas de actividad serían una especie de diagramas de estados compuestos y relativos a varias clases

64

Ejemplo

swinlanes

EJEMPLO, I

65

Ejemplo, II (a)

¡diagrama de secuencia!

66

Ejemplo, II (b)

Selección

hotel

Selección

días

mensaje

Aviso

banco

[libre() and

inicio!=fin]

[libre() and

inicio=fin]

[!libre()]

inicio++inicio

fin

Aviso

cliente

mas

¡diagrama de actividad!

[mas=si]

[mas=no]

67

Relación entre diagramas de

actividades y de estados• Un diagrama de estados se puede representar como un

diagrama de actividad, considerando los eventos de mensaje como condiciones entre nodos del diagrama de actividad– Pero no al revés, ya que un diagrama de actividades puede

involucrar a varias clases

– Los estados ortogonales corresponderían a “forks” en los diagramas de actividad

• Ejemplo:– Representación como diagrama de actividades del diagrama de

estados de la interfaz de usuario “Geting SSN, Geting PIN, Validating, ...”

• Actividades “Get SSN, Get PIN, Validate” y psedoestados “branch” para las posibles acciones y resultados de operaciones

68

Otro ejemplo

Pide

contraseña

Muestra

mensaje[Pulsó

Cancelar]

Comprueba

contraseña

[Contraseña

escrita]

[No coincide]

Muestra

mensaje

[Contraseña correcta]. . .

Es un diagrama de actividad, que puede ser reformulado

como un diagrama de estados (evento de mensaje: cancelar;

eventos de cambio: contraseña correcta o incorrecta)

69

Entrada y salida de actividades

Ejemplos (incluyen manejo de errores o excepciones):

70

Subactividades

71

Diagrama de despliegue

• Distribución física de trozos de hardware y software

• Diagrama aplicable a un contexto no OO

• Contiene nodos:– Un nodo es algo que contiene un software. Puede ser:

• Hardware (un ordenador o algún hardware conectado al sistema)

• Entorno de ejecución (un software que puede contener otras partes de software; ejemplo: un sistema operativo o un proceso contenedor)

– Los nodos contienen “artifacts” (manifestación física de software, que son normalmente ficheros)

– Los nodos pueden ser compuestos

– Un nodo o un “artifact” pueden contener un conjunto de propiedades (“tagged-values”)

– Algunos nodos se comunican entre ellos (“communication paths”)

72

Ejemplo

73

Diagrama de componentes, I

• Aplicables a contextos OO. Componentes: • Partes independientes (y por lo tanto actualizables)

de un sistema, desde el punto de vista de un usuario

final

– Una componente también puede ser un conjunto de clases

de un diagrama de clases

• Notación:

74

Diagrama de componentes, II

• Una componente puede estar compuesta por otras

componentes

• Una componente se puede conectar con otras componentes

mediante interfaces.

– Se puede utilizar la notación UML del diagrama de

clases (dependencia + implementación-interfaz).

Ejemplo:

75

Ejemplo

76

Ejemplo (diag. componentes)

La componente “Sales Server” tiene

2 puertos (un tipo especial de

subcomponente) para comunicar

con el exterior

77

EjemploUn diag. de despliegue. Aparecen

también componentes. UML 1.x

78

Un ejemplo completo para

todos los diagramas

Un sistema de gestión de cursos impartidos para un conjunto

de clientes. Algunos de esos clientes pueden pertenecer a

empresas.

82

01

1.1

2

3

2.1

3.1

3.23.2.1

3.1.1

88

OCL (Object Constraint Language)

92

@pre=previous

93

Anotación de restricciones

• Opciones:– Mediante anotaciones directas, utilizando la

nomenclatura descrita

– Mediante anotaciones separadas

Persona

nombre

edad

…

{self.edad > 0}

94

Ejemplo

95

Herramientas, I

• Permiten el dibujo de diagramas además de dar:

– Soporte a la correctitud de los diagramas en base a su semántica

– Apoyo para simplificar la comprensión de los diagramas

• Además, incluyen:

– Comprobación de inconsistencias

– Detección de trabajo a realizar y mejoras

– Generación de informes

– Soporte a la reutilización

96

Herramientas, II

• Soporte a la navegación

– Vistas compuestas

– Elaboración de conexiones entre información

relacionada

– Búsqueda

– Visión con diferentes niveles de granularidad

(expansión y contracción de partes de la vista)

– Filtros

– Operaciones sobre componentes de la vista

97

Herramientas, III

• Soporte al trabajo multiusuario

– Bloqueo de información

– Trabajo colaborativo

• Generación de código

– Esqueletos con información estática (clases)

– Integración con lenguajes especiales (SQL, …)

• Ingeniería inversa

– Construcción de un modelo de diseño a partir de código

• Más complejo que la ingeniería directa

98

Herramientas, IV

• Integración con otras herramientas

– Entorno de desarrollo (tendencia a confluir)

– Configuración del sistema y control de versiones

– Herramientas de documentación

– Herramientas de prueba de software

– Herramientas de construcción de interfaces de usuario

– Herramientas de especificación de requerimientos

– Herramientas de gestión de proyectos y soporte al

proceso de diseño y desarrollo

99

Herramientas, V

• Distintos niveles de abstracción

• Intercambio de información

– Especificación OMG de representación de

modelos UML en XMI (XML Metadata

Interchange)

Uml Presentacion

Documents

Transcript of Uml Presentacion