1. INTRODUCCION AL UML
(Lenguaje Unificado de Construcción de
Modelos)
.Barrera, Corroppoli, Dans, Ibañez 1
2003

2. UML
• Es una herramienta que nos permitirá
expresarnos en un lenguaje común
• Permite facilitar la comunicación entre las
distintas áreas de una organización
.Barrera, Corroppoli, Dans, Ibañez 2
2003

3. Reseña histórica
El management y los paradigmas
1989: el último cambio de paradigma
Del modelo piramidal al modelo en red
Los tres amigos: Booch, Rumbaugh y Jacobson
Tres objetivos:
1. Modelización orientada a objetos
2. Manejar distintas complejidades
3. Modelizar tanto personas como máquinas
Balance entre expresividad y simplicidad
.Barrera, Corroppoli, Dans, Ibañez 3
2003

4. 11/97
Se inicia el estándar OMG
9/97 Distintas versiones
del UML 1.1 enviado a OMG
1/97
UML de los tres amigos
6/96
Método unificado
10/95 OMT - 2 OOSE
Booch-93
Booch-91 OMT - 1
90-94
Técnicas orientadas
a objetos
Los 80
Los 70 Análisis estructurado Corroppoli, Dans, Ibañez
.Barrera, 4
2003

5. UML
• Las cosas que usa UML (diagramas,
gráficos, textos, etc) se denominan
artefactos
• Los conceptos (personas, viviendas,
créditos, pagos, equipos, etc) se
denominan objetos
• Los objetos se comunican entre si a
través de mensajes
.Barrera, Corroppoli, Dans, Ibañez 5
2003

6. Gerente General
Servicios al
Finanzas Personal Producción Distribución
cliente
Cliente
.Barrera, Corroppoli, Dans, Ibañez 6
2003

7. La organización como un proceso
Cliente
Interactúa con
Proceso
Comprende
Actividades
Ejecuta
Unidad Organizacional
Ubicada en
Localización
.Barrera, Corroppoli, Dans, Ibañez 7
2003

8. Sistemas de Información
• Permiten:
– capturar
– procesar
– almacenar
– distribuir
datos
.Barrera, Corroppoli, Dans, Ibañez 8
2003

9. Un Sistema de Información
• Debería servir para:
Tomar decisiones.
Controlar operaciones.
Analizar problemas.
Crear productos y servicios.
Un S.I. es la respuesta a una necesidad
.Barrera, Corroppoli, Dans, Ibañez 9
2003

10. ¿Qué se pretende con UML?
• Disminuir la complejidad.
• Que el usuario entienda la visualización.
• Acortar el tiempo dedicado al diseño.
• Que la visualización quede documentada.
• Notación uniforme para todos los
integrantes.
.Barrera, Corroppoli, Dans, Ibañez 10
2003

11. Conocimiento de los requerimientos
• Un proyecto no puede ser exitoso sin una
especificación correcta y exhaustiva.
– En esta fase se deben identificar y clasificar
las funciones del Sistema
– Identificar y clasificar los atributos del
sistema y relacionarlos con las funciones.
.Barrera, Corroppoli, Dans, Ibañez 11
2003

12. Artefactos de la fase de Requerimientos
• Panorama general
• Clientes
• Metas
• Funciones del sistema
• Atributos del sistema
• Grupos afectados
• Suposiciones
• Riesgos
• Dependencias
• Casos Típicos
• Modelo Conceptual preliminar
.Barrera, Corroppoli, Dans, Ibañez 12
2003

13. USE CASE: Caso Típico
•El caso típico es una narración o caso de utilización de un
sistema
•Que describe la secuencia de eventos de un actor (o
varios) para completar un proceso.
Sistema
Caso típico
Actor
Actor
.Barrera, Corroppoli, Dans, Ibañez 13
2003

14. Formatos de casos típicos
• Según grado de detalle
– Alto nivel
– Expandido
• Según prioridad para el desarrollo
– Primarios
– Secundarios
– Opcionales
• Según grado de abstracción
– Esencial
– Real
.Barrera, Corroppoli, Dans, Ibañez 14
2003

15. Caso típico de alto nivel: comprar producto
Caso típico: Comprar producto.
Actores: Cliente, Cajero.
Tipo: Primario, Esencial
Descripción: Un Cliente llega a la caja con los artículos
que comprará. El Cajero registra los artí-
culos, cobra y devuelve el cambio. El Clien-
te se va con los artículos.
.Barrera, Corroppoli, Dans, Ibañez 15
2003

16. Actores
• Entidad externa al sistema
• Estimula al sistema con eventos
• O recibe algo del sistema
Cliente
.Barrera, Corroppoli, Dans, Ibañez 16
2003

17. Diagrama del caso típico
Caja
Compra producto
Cajero Cliente
Registra compra
Entrega cambio
.Barrera, Corroppoli, Dans, Ibañez 17
2003

18. Actividad
• Pensar un caso típico de alto nivel
– Expresarlo en forma textual o gráfica según
cada uno prefiera
.Barrera, Corroppoli, Dans, Ibañez 18
2003

19. Actividad
• Pensemos como podríamos expandir el
caso típico Comprar producto con
efectivo
– Hacemos un esquema donde:
• A la izquierda pondremos la acción de los actores
y a la derecha la respuesta del sistema
• Las actividades estarán numeradas
.Barrera, Corroppoli, Dans, Ibañez 19
2003

20. Ejemplo de un caso típico expandido:
comprar productos con efectivo
• Caso de uso • Comprar productos en efectivo
• Actores • Cliente(iniciador), cajero
• Propósito • Capturar una venta y su pago en efectivo
• Resumen • Un cliente llega a la caja registradora con artículos.
El cajero registra los productos y recibe un pago en
efectivo.Al terminar la operación, el Cliente se
marcha con los productos comprados
• Primario y esencial
• Tipo • Funciones: Las veremos más adelante
• Referencias
cruzadas
.Barrera, Corroppoli, Dans, Ibañez 20
2003

21. Ejemplo de un caso típico expandido:
comprar productos con efectivo (Cont)
Curso normal de los eventos
Acción del actor Respuesta del sistema
1. Este caso comienza cuando un
Cliente llega a una caja con
productos que desea comprar
2. El Cajero registra el identificador 3. Determina el precio del producto e
de cada producto. incorpora a la transacción actual
Si hay varios productos de una la información correspondiente.
misma categoría, el Cajero Se presenta la descripción y el
también puede introducir la precio del producto actual.
cantidad
.Barrera, Corroppoli, Dans, Ibañez 21
2003

22. Ejemplo de un caso típico expandido:
comprar productos con efectivo (Cont)
Acción del actor Respuesta del sistema
4. Al terminar de introducir el
producto, el Cajero indica a la
caja que se concluyó la captura 5. Calcula y presenta el total de la
del producto. venta
6. El Cajero le indica el total al
Cliente
7. El Cliente efectúa el pago en
efectivo
8. El Cajero registra la cantidad de
efectivo recibida 9. Muestra al Cliente la
diferencia. Genera un recibo
.Barrera, Corroppoli, Dans, Ibañez 22
2003

23. Ejemplo de un caso típico expandido:
comprar productos con efectivo (Cont)
Acción del actor Respuesta del sistema
10. El Cajero deposita el efectivo
recibido y extrae el cambio del
pago
El Cajero da al Cliente el cambio 11. Registra la venta concluida
y el recibo impreso
12. El Cliente se marcha con los
artículos comprados
Cursos alternos
Línea 2: introducción de identificador inválido. Indicar error
Línea 7: el cliente no tiene suficiente dinero. Cancelar la transacción
de venta
.Barrera, Corroppoli, Dans, Ibañez 23
2003

24. Explicación del formato expandido
La primera sección del caso expandido es muy suscinta
Caso típico Nombre del caso típico
Actores Lista de actores, en la cual se indica quién
inicia el caso típico
Propósito Intención del caso típico
Resumen Repetición del caso típico de alto nivel o alguna
síntesis similar
Tipo 1. Primario, secundario u opcional
2. Esencial o real
Referencias Casos típicos relacionados y funciones
cruzadas también relacionadas
.Barrera, Corroppoli, Dans, Ibañez 24
2003

25. Explicación del formato expandido (Cont.)
• Segunda sección
– Curso normal de los eventos
• Acciones de los actores
– Acciones numeradas de los actores
• Respuestas del sistema
– Descripciones numeradas de las respuestas del sistema
• Tercera Sección
– Curso alterno de los eventos
• Alternativas que pueden ocurrir en el número de línea
– Descripción de excepciones
.Barrera, Corroppoli, Dans, Ibañez 25
2003

26. Identificación de los casos típicos
• Basado en los actores
1. Identificar los actores
2. Para cada actor identificar los procesos
que inicia o en los que participa
 Basado en eventos
1. Identificación de los eventos externos
2. Relacionar los eventos con los actores y con
los casos típicos
.Barrera, Corroppoli, Dans, Ibañez 26
2003

27. Actividad
• Definamos los casos tipicos del Video
Club o Biblioteca
– En formato de alto nivel
.Barrera, Corroppoli, Dans, Ibañez 27
2003

28. Requerimientos - Funciones del
Sistema
• Lo que éste debe hacer
• Categorías
– Evidente
– Oculta
– Superflua
.Barrera, Corroppoli, Dans, Ibañez 28
2003

29. Funciones del sistema
Ref. Función Categoría
R1.1 Registrar la venta Evidente
en proceso
R1.2 Descontar del Oculta
stock las
cantidades
vendidas
R1.3. Sonar un Bip por Superflua
time out
.Barrera, Corroppoli, Dans, Ibañez 29
2003

30. Actividad
• Enumeremos las funciones que le
pedimos al Sistema de Información del
ejemplo
– Tendremos en cuenta la descripción de los
casos típicos
– Incluiremos la categoría
.Barrera, Corroppoli, Dans, Ibañez 30
2003

31. Requerimientos - Atributos del
sistema
• Son sus características
– Por ejemplo:
• Facilidad de uso
• Tiempo de respuesta
• Recuperación de datos frente a
cortes
.Barrera, Corroppoli, Dans, Ibañez 31
2003

32. Atributos del sistema
Atributo Descripción
Tiempo de Cuando se registre un producto vendido, la
respuesta descripción y el precio aparecerán en cinco segundos
Metáfora de Ventanas orientadas a la metáfora de una forma y
interfaz cuadros de dialogo.
Tolerancia a Debe registrar los pagos a crédito autorizados que se
fallas hagan a las cuentas por cobrar en un plazo de 24
horas.
.Barrera, Corroppoli, Dans, Ibañez 32
2003

33. Actividad
• Enumeremos atributos que deseamos para
nuestro sistema
.Barrera, Corroppoli, Dans, Ibañez 33
2003

34. Atributos del sistema en las
especificaciones de funciones
Detalles y
Ref. Función Categoría Atributo Categoría
restriccio-nes
R1.1 Mostrar la descripción Evidente Tiempo de 5 segundos obligatorio
y el precio del respuesta como máximo
producto registrado
Metáfora de Pantallas Obligatorio
interfaz basadas en
formas
colorido Opcional
.Barrera, Corroppoli, Dans, Ibañez 34
2003

35. Actividad
• Agregaremos a las funciones ya definidas los
atributos que correspondan
.Barrera, Corroppoli, Dans, Ibañez 35
2003

36. Ámbito de UML
la orientación a objetos
• Los objetos son los conceptos, de los que
hablábamos anteriormente.
Atributos
nombre
Objeto persona edad
empresa
Comportamientos
CambiarEdad
CambiarEmpresa
.Barrera, Corroppoli, Dans, Ibañez 36
2003

37. Noción de Clase e Instancia
• Todos los objetos con las mismas
propiedades (atributos y comportamientos)
se reúnen en una familia
• Esta familia son la clase y los objetos que
incluyen son las instancias
.Barrera, Corroppoli, Dans, Ibañez 37
2003

38. La clase Persona y sus instancias
Instancia de persona nº 1
-nombre = SALAS
-edad=35
Atributos
-empresa=IPV nombre
Instanciación
edad
empresa
Instanciación
Comportamientos
Instancia de persona nº 1 CambiarEdad
-nombre = FUNES
-edad=55
CambiarEmpresa
-empresa=VPI
.Barrera, Corroppoli, Dans, Ibañez 38
2003

39. Mensajes y métodos
• Los objetos no son conjunto de datos pasivos
• Pueden interactuar entre sí
• Se comunican entre sí a través de mensajes
• Cada objeto que recibe un mensaje lo atiende con
un método
• El conjunto de mensajes que cada objeto puede
atender se denomina interfase.
.Barrera, Corroppoli, Dans, Ibañez 39
2003

40. Jerarquía de Clases y herencia
• El mecanismo de la herencia permite definir
nuevas clases a partir de clases existentes
Persona
Nombre
edad
empresa
CambiarEdad
Instancia de persona nº 1
CambiarEmpresa
-nombre = RODRIGUEZ
Instancia -edad=36
Asalariado -empresa=MUNI
-jefe=SANENZ
jefe -función=encargado sección
función
CambiarJefe .Barrera, Corroppoli, Dans, Ibañez 40
CambiarFunción 2003

41. Polimorfismo
• El polimorfismo es una característica de la
OO (orientación a objetos) que permite
redefinir un comportamiento (método)
heredado por una superclase
.Barrera, Corroppoli, Dans, Ibañez 41
2003

42. Glosario o Diccionario de Términos
Es un documento donde se definen términos.
Define aquello que requiere explicación para mejorar
las comunicaciones y evitar los malentendidos.
Se crea al inicio del proyecto y va creciendo durante
toda su vida.
Término Categoría Comentarios
.Barrera, Corroppoli, Dans, Ibañez 42
2003

43. Ejemplos de Glosario
Término Categoría Comentarios
Comprar Productos Caso típico proceso de compra
de un cliente en el local
Iniciar Caja Caso típico Proceso de inicialización
de la caja
Venta.total:Cantidad Atributo Importe total de la venta
.Barrera, Corroppoli, Dans, Ibañez 43
2003

44. Requerimientos - Atributos del
Sistema
• Son sus características
– Por ejemplo:
• Facilidad de uso
• Tiempo de respuesta
• etc
.Barrera, Corroppoli, Dans, Ibañez 44
2003

45. Ejemplo de Atributos
Atributo Descripción
Tiempo de Cuando se registre un producto vendido, la
respuesta descripción y el precio aparecerán en cinco
segundos
Metáfora de Pantallas con el isotipo del IPV, todas con el
interfaz mismo tono de fondo y las casillas distribui-das
de la misma forma.
Tolerancia a Debe registrar los pagos a crédito autorizados
fallas que se hagan a las cuentas por cobrar en un
plazo de 24 horas.
.Barrera, Corroppoli, Dans, Ibañez 45
2003

46. Actividad
• Enumeremos atributos que deseamos para
nuestro nuevo Sistema de Información.
.Barrera, Corroppoli, Dans, Ibañez 46
2003

47. Atributos del sistema en las
especificaciones de funciones
Categoría Detalles y Categoría de
Ref. Función Atributo
de función restriccio-nes atributo
R1.1 Mostrar la descripción Evidente Tiempo de 5 segundos obligatorio
y el precio del producto respuesta como máximo
registrado
Metáfora de Pantallas Obligatorio
interfaz basadas en
formas
colorido opcional
.Barrera, Corroppoli, Dans, Ibañez 47
2003

48. Actividad
• Agregaremos a las funciones ya definidas
los atributos que deseamos.
.Barrera, Corroppoli, Dans, Ibañez 48
2003

49. UML: la Orientación a Objetos
Un objeto es un concepto (personas, cosas, hechos,
ideas, etc)
Nombre
Atributos
Comportamientos
.Barrera, Corroppoli, Dans, Ibañez 49
2003

50. Atributo y comportamiento
• Atributo: son las características o
cualidades del objeto (también se
denominan propiedades)
• Comportamiento: son las acciones,
aquello que el objeto sabe o puede hacer
.Barrera, Corroppoli, Dans, Ibañez 50
2003

51. Ejemplo de Objeto
Persona
nombre
edad
empresa
Objeto persona
CambiarEdad
CambiarEmpresa
.Barrera, Corroppoli, Dans, Ibañez 51
2003

52. Noción de Clase e Instancia
• Todos los objetos naturalmente se
agrupan en categorías (clases)
• Los objetos que están comprendidos
dentro de las clases se denominan
instancias
Clase
Instancia Instancia Instancia
.Barrera, Corroppoli, Dans, Ibañez 52
2003

53. Actividades:
1. Identifique una clase que agrupe todos estos objetos
2. Agrupe diversos objetos en distintas clases.
.Barrera, Corroppoli, Dans, Ibañez 53
2003

54. Instancias
Persona
Instancia persona nº 1
-nombre = SALAS
nombre -edad=35
edad -empresa=IPV
empresa
Instanciación
CambiarEdad Instancia persona nº 2
-nombre = FUNES
CambiarEmpresa -edad=55
-empresa=VPI
.Barrera, Corroppoli, Dans, Ibañez 54
2003

55. Jerarquía de Clases y herencia
• El mecanismo de la herencia permite definir
nuevas clases a partir de clases existentes
Persona
Nombre
edad
empresa
CambiarEdad
CambiarEmpresa
Instancia de persona nº 1
-nombre = RODRIGUEZ
Asalariado Instancia -edad=36
-empresa=MUNI
jefe -jefe=SANENZ
función -función=encargado sección
CambiarJefe
CambiarFunción .Barrera, Corroppoli, Dans, Ibañez 55
2003

56. Polimorfismo
• El polimorfismo es una característica de la
OO (orientación a objetos) que permite
redefinir un comportamiento (método)
heredado por una superclase
.Barrera, Corroppoli, Dans, Ibañez 56
2003

57. Polimorfismo
El polimorfismo permite usar los mismos términos
del cliente.
Abrir ...
.Barrera, Corroppoli, Dans, Ibañez 57
2003

58. Encapsulamiento e Interfaces
Pantalla
- ¿Cómo funciona?
- ¡A quién le
importa!
Teclado
.Barrera, Corroppoli, Dans, Ibañez 58
2003

59. Modelo Conceptual
• Identifica los objetos.
• Representa cosas del mundo real.
• Es un diagrama estático donde no se define
ninguna operación (proceso).
• Ayuda a esclarecer la terminología.
Es el artefacto más importante en
la etapa del análisis del problema.
.Barrera, Corroppoli, Dans, Ibañez 59
2003

60. Modelo Conceptual
• Nos muestra:
– Clases
– Asociaciones entre esas Clases
– Atributos de dichas Clases
.Barrera, Corroppoli, Dans, Ibañez 60
2003

61. Ejemplo
Línea Aérea
Emplea
Persona Asignada-a Asignado-a
Vuelo Avión
nombre
edad
empresa
.Barrera, Corroppoli, Dans, Ibañez 61
2003

62. Maneras de definir Clases
Venta
Por el Símbolo
Fecha
hora
“Una venta representa
el evento de una Definición intensiva
transacción de compra.
Tiene fecha y hora”
Venta-1
Venta-2 Definición extensiva
Venta-3
Venta-4
.Barrera, Corroppoli, Dans, Ibañez 62
2003

63. La asignación de nombres
• Se puede aplicar la metodología del
cartógrafo:
– Utilizar los nombres existentes en el
territorio.
– Excluir las características irrelevantes.
– No agregar cosas que no existan.
.Barrera, Corroppoli, Dans, Ibañez 63
2003

64. Descomposición del problema
• Ante los problemas complejos
– “divide y vencerás”
• Dividimos el problema en partes
comprensibles
• Conviene llevarla a cabo a partir de las
clases
.Barrera, Corroppoli, Dans, Ibañez 64
2003

65. Descomposición del problema (cont.)
• Una guía para esta fase:
– Identificar varias clases
– Documentar los resultados en un modelo
conceptual
.Barrera, Corroppoli, Dans, Ibañez 65
2003

66. Clases del Caso de la Caja
Local Caja Venta
Agreguemos otras clases que puedan
identificar:
.Barrera, Corroppoli, Dans, Ibañez 66
2003

67. Estrategias para identificar las clases
• A partir de una lista de categorías de
clases
• Identificación de frases nominales
.Barrera, Corroppoli, Dans, Ibañez 67
2003

68. Identificación de frases nominales
Acción del actor Respuesta del sistema
1. Este caso comienza cuando
un Cliente llega a una caja
con productos que desea
comprar
3. Determina el precio del
2. El Cajero registra el producto e incorpora a la
identificador de cada transacción actual la
producto. información
Si hay varios productos de correspondiente.
una misma categoría, el Se presenta la descripción
Cajero también puede y el precio del producto
introducir la cantidad actual.
.Barrera, Corroppoli, Dans, Ibañez 68
2003

69. Aplicación
• Usando la lista de categorías de clases y
análisis de frases nominales,
construyamos una lista de clases de una
aplicación del Video Club o la Biblioteca.
.Barrera, Corroppoli, Dans, Ibañez 69
2003

70. Identificando las clases
A veces confundimos clases y atributos.
Si consideramos algo como atributo (que no es un
número o texto en el mundo real), probablemente éste
sea un objeto y no un atributo.
Vuelo Vuelo Aeropuerto
¿o...?
Destino nombre
En caso de duda, convertir el atributo en clase.
.Barrera, Corroppoli, Dans, Ibañez 70
2003

71. Resumiendo
Clase “es una descripción de un conjunto de
objetos que comparten los mismos
atributos, relaciones y comportamientos”
.Barrera, Corroppoli, Dans, Ibañez 71
2003

72. En UML las asociaciones son
relaciones entre las clases
Producto Almacenado en Local
1 1
.Barrera, Corroppoli, Dans, Ibañez 72
2003

73. Asociaciones
• La asociación es una relación entre dos
clases que indica alguna conexión
significativa e interesante entre ellas
asociación
Registra
Caja Venta actual
.Barrera, Corroppoli, Dans, Ibañez 73
2003

74. Notación de las asociaciones en UML
navegabilidad nombre
Vuelo Asignado-a Avión
* 1
multiplicidad
.Barrera, Corroppoli, Dans, Ibañez 74
2003

75. Notación de las asociaciones en UML
(Ejemplo)
navegabilidad nombre
Asignado-a
¿ ? Adjudicatario
* 1
multiplicidad
.Barrera, Corroppoli, Dans, Ibañez 75
2003

76. Asociaciones prioritarias
1. A es una parte lógica de B (artículo-ley)
2. A es una parte física de B (habitación-casa)
3. A está físicamente contenido en B (producto-
estante)
4. A está lógicamente contenido en B (capítulo-ley)
5. A está registrado en B (ladrón-cárcel)
.Barrera, Corroppoli, Dans, Ibañez 76
2003

77. Actividad
• Cajero-Local • Caja-Local
• Piloto-Avión • Ala-Avión
• Departamento-Tienda • VentasLineadeProducto-Venta
• Mantenimiento-Línea Aérea • TramodeVuelo-RutadeVuelo
• Cajero-Caja
• Caja-Local, Producto-Estante,
• Cliente-Cajero
• AgentedeReservaciones-Pasajero • Pasajero-Avión
• Pago-Venta • DescripcióndeProducto-Catálogo
• Pasajero-Boleto • Vuelo-ProgramadeVuelos
• Reservación-Cancelación • DescripcióndeProducto-Producto
• Caja-Caja
• DescripcióndeVuelo-Vuelo
• Ciudad-Ciudad
• Avión-Línea Aérea • VentasLíneadeProducto-Venta
• Venta-Caja • TrabajodeMantenimiento-Mantenimiento
.Barrera, Corroppoli, Dans, Ibañez 77
2003

78. Multiplicidad
• Define cuantas instancias de una clase pueden asociarse
a tantas instancias de otra clase
* cero o más; “muchos”
1...*
uno o más
1...40 de uno a cuarenta
5 exactamente 5
2, 5, 7 exactamente dos, cinco o siete
.Barrera, Corroppoli, Dans, Ibañez 78
2003

79. Las Relaciones Inolvidables
• Caja Captura Venta • Para conocer la venta actual
genera un total, e imprime un
ticket.
• Venta pagada en • Para saber si se pagó la venta,
efectivo relaciona la cantidad ofrecida con
el total de la venta e imprime un
ticket.
• Para recuperar una
• ListadeProductos EspecificacióndeProducto,
registra mediante un código universal de
EspecificacióndePro- producto.
ductos
.Barrera, Corroppoli, Dans, Ibañez 79
2003

80. Atributos
• Es una característica importante de un
objeto.
• Por ejemplo, un ticket de venta requiere
la fecha y la hora.
• En consecuencia la clase Venta requiere
los atributos fecha y hora
.Barrera, Corroppoli, Dans, Ibañez 80
2003

81. Atributos comunes
•fecha
•número
•texto
•hora
•booleano
•dirección
•color
•geometría
•número de teléfono
•CUIT/CUIL
•código de producto
•código postal
•tipos enumerados
.Barrera, Corroppoli, Dans, Ibañez 81
2003

82. Notación de los atributos en UML
Venta
Aeropuerto
fecha
nombre
hora
atributos
.Barrera, Corroppoli, Dans, Ibañez 82
2003

83. Aplicación
Armemos un Modelo Conceptual
Tomemos como ejemplo el Video Club
o la Biblioteca
.Barrera, Corroppoli, Dans, Ibañez 83
2003

84. Modelo conceptual
Ventas Producto
Registra_venta_de
LineadeProductos
0..1 1
*
cantidad Almacenado_en
1..* 1
Contenida en 1 Local
Venta
Dirección
Fecha nombre
hora 1 1
1 Aloja
Pagada-por 1 1..*
Pago Caja
Capturada-en
monto .Barrera, Corroppoli, Dans, Ibañez 1 84
2003

85. Comportamiento de los sistemas -
Diagramas de secuencia
• Muestran gráficamente los eventos que los
actores solicitan al sistema.
Sistema
.Barrera, Corroppoli, Dans, Ibañez 85
2003

86. • Se refiere a la secuencia normal de
Ejemplo los eventos en el caso típico comprar
productos
sistema como
caja negra
actor
Cajero Sistema
Repetir hasta que no
haya mas productos
introducirProducto(CUP, cantidad)
terminarVenta()
Texto que
efecturaPago(monto)
aclara: control,
lógica,
Evento del sistema
iteración,etc .Barrera, Corroppoli, Dans, Ibañez 86
Inicia una operación
2003 del sistema

87. Diagrama de Secuencia Inicial
• Durante la interacción un actor genera eventos
dirigidos a un sistema, solicitando alguna operación
a cambio
• Su creación depende de la formulación previa de los
casos típicos.
• Es una descripción de lo que hace, sin explicar cómo
lo hace.
• Consideramos al sistema como una caja negra.
.Barrera, Corroppoli, Dans, Ibañez 87
2003

88. Diagrama de Secuencia Inicial
• Los eventos del sistema pueden incluir
parámetros.
• Los parámetros son los datos que acompañan la
solicitud del actor.
• En la aplicación de la caja del supermercado el
actor “Cajero” inicia los siguientes eventos:
– introducirProducto
– terminarVenta
– efectuarPago
.Barrera, Corroppoli, Dans, Ibañez 88
2003

89. Diagrama de Secuencia Inicial
• El tiempo avanza hacia abajo
• El ordenamiento de los eventos debería
seguir el orden indicado en el caso típico.
• De no ser así deberá reverse el caso típico.
.Barrera, Corroppoli, Dans, Ibañez 89
2003

90. Eventos y operaciones
• El evento de un sistema:
– Es un hecho externo de entrada que un actor produce en un
sistema.
– Como respuesta se originará una operación del sistema
• La operación de un sistema
– Es una acción que este ejecuta en respuesta a un evento del
sistema
• El nombre del evento y la operación del sistema son
idénticos
– La diferencia es que uno es el estímulo y el otro la respuesta
.Barrera, Corroppoli, Dans, Ibañez 90
2003

91. Cómo elaborar un diagrama de
secuencia
Para describir la secuencia de eventos de un caso típico:
• Trace una línea que represente al sistema como una caja
negra
• Identifique a los actores que operan directamente sobre el
sistema. Trace una línea para cada uno de ellos
• A partir del caso típico identifique los eventos externos al
sistema que son generados por los actores. Muéstrelos
gráficamente en le diagrama.
• A la izquierda del diagrama puede incluir o no el texto del
caso típico
.Barrera, Corroppoli, Dans, Ibañez 91
2003

92. Asignación de nombres a los eventos
• Deberían reflejar el propósito
• Mejora la claridad si comienza con un
verbo (agregar..., introducir...,
terminar..., efectuar...)
.Barrera, Corroppoli, Dans, Ibañez 92
2003

93. Diagrama de secuencia del caso típico
comprar productos
Cajero Sistema
Repetir hasta que no introducirProducto(CUP, cantidad)
haya mas productos
terminarVenta()
efecturaPago(monto)
.Barrera, Corroppoli, Dans, Ibañez 93
2003

94. Actividad
• Confeccionar los diagramas de secuencia
para los casos típicos primarios del Video
Club o la Biblioteca.
.Barrera, Corroppoli, Dans, Ibañez 94
2003

95. Contratos
• Es un documento que describe lo que una
operación de sistema se propone hacer.
• Se escribe en forma declarativa, qué
sucederá y no cómo se conseguirá.
.Barrera, Corroppoli, Dans, Ibañez 95
2003

96. Contratos
Caso Típico: Comprar Productos - Curso Normal de los Eventos
1 Este caso típico comienza...
Cajero Sistema
IntroducirProducto (cup, cantidad)
terminarVenta ( )
efectuarPago (monto)
Sistema
terminarVenta()
introducirProducto()
efectuarPago()
Operación: IntroducirProducto. Se trata de una nueva venta, por lo tanto después
de esta operación fue creada una Venta...
.Barrera, Corroppoli, Dans, Ibañez 96
2003

97. Secciones del Contrato
Nombre: Nombre de la operación y parámetros.
Responsabilidades: Descripción informal de las
responsabilidades que debe cumplir la operación.
Caso: Nombre del Caso Típico
Referencias: Nº de referencia de las funciones del
sistema, casos típicos, etc.
Notas: notas de diseño, algoritmos, e información
afín.
Excepciones: Casos excepcionales.
.Barrera, Corroppoli, Dans, Ibañez 97
2003

98. Secciones del Contrato (cont.)
Salida: Aquello que se espera recibir del sistema
(objetivo del contrato).
Precondiciones: Suposiciones acerca del estado del
sistema antes de ejecutar la operación.
Poscondiciones: El estado del sistema después de la
operación.
.Barrera, Corroppoli, Dans, Ibañez 98
2003

99. Notas
• Declaraciones de diseño referentes a la
operación.
Ejemplo: la explicación de un algoritmo
para manejar la operación (fórmula para
calcular la cuota de un préstamo).
.Barrera, Corroppoli, Dans, Ibañez 99
2003

100. Precondiciones
• Definen la suposición sobre el estado del sistema al
iniciarse la operación.
• Para describir las precondiciones tener en cuenta lo
siguiente:
• Cosas que son importantes probar en el software
en algún momento de la ejecución de la
operación.
• Cosas de las cuales depende el éxito de la
operación.
.Barrera, Corroppoli, Dans, Ibañez 100
2003

101. Poscondiciones
• Indican cómo cambió el sistema después de
una operación.
• Mejora la claridad si se redacta en pretérito
( fue creada....).
• Describe los cambios necesarios para que el
sistema funcione sin necesidad de describir
cómo se logran.
• Nos concentramos en el qué debe suceder,
no la manera de conseguirlo.
.Barrera, Corroppoli, Dans, Ibañez 101
2003

102. Poscondiciones
• Para describir las poscondiciones utilizar las
siguientes categorías:
• Creación y eliminación de las instancias.
• Modificación de los atributos.
• Asociaciones formadas y canceladas.
.Barrera, Corroppoli, Dans, Ibañez 102
2003

103. Contratos para el caso típico comprar productos
Contrato para IntroducirProductos
• Nombre: IntroducirProducto (CUP,
cantidad).
• Responsabilidades: Introducir (registrar) la venta de un
producto y agregarlo a la venta. Desplegar
la descripción del producto y su precio.
• Tipo: Sistema.
• Referencias cruzadas: Funciones del sistema R.1.1,R1.3, R1.9
Caso típico Compara productos.
• Notas: Utilice el acceso super rápido a la base de
datos.
• Excepciones: Si el CUP no es válido, indique que se
cometió un error.
• Salida:
• Precondiciones: .Barrera, Corroppoli, Dans, Ibañez CUP.
El sistema conoce el 103
2003

104. Contratos para el caso típico comprar productos
Contrato para IntroducirProductos (Cont.)
• Poscondiciones:
– Si se trata de una nueva venta, una Venta fue creada (creación
de instancia).
– Si se trata de una nueva venta, la nueva Venta fue asociada a la
Caja (asociación formada).
– Se creó una instancia VentaLineadeProducto a la Venta
(creación de instancia).
– Se asoció VentasLineadeProducto a la Venta (asociación
formada).
– Se estableció VentasLineadeProducto.cantidad con el valor
cantidad (modificación de atributo).
– La instancia VentasLineadeProducto fue asociada a una
EspecificaciondeProducto, basado esto en la correspondencia
del CUP (asociación formada)
.Barrera, Corroppoli, Dans, Ibañez 104
2003

105. Contratos para el caso típico comprar productos
Contrato para TerminarVenta
• Nombre: TerminarVenta
• Responsabilidades: Registrar que es el final de la captura
de los productos de la venta y desplegar
el total de la venta.
• Tipo: Sistema.
• Referencias cruzadas: Funciones del sistema R.1.2
Caso típico Compra productos.
• Notas: Si no se está realizando una venta indicar
que se cometió un error.
• Excepciones: Si el CUP no es válido, indique que se
cometió un error.
• Salida:
• Precondiciones: El sistema conoce el CUP.
.Barrera, Corroppoli, Dans, Ibañez 105
2003

106. Contratos para el caso típico comprar productos
Contrato para TerminarVenta (Cont.)
• Poscondiciones:
– Estableció Venta.EstaTerminada como verdadero
(modificación de atributo)
.Barrera, Corroppoli, Dans, Ibañez 106
2003

107. Contratos para el caso típico comprar productos
Contrato para EfectuarPago
• Nombre: EfectuarPago (monto)
• Responsabilidades: Registrar el pago, calcular el saldo e
imprimir el recibo.
• Tipo: Sistema.
• Referencias cruzadas: Funciones del sistema R.2.1
Caso típico Compra productos.
• Notas:
• Excepciones: Si la venta no está concluida, indique que
se cometió un error.
• Salida: Ticket
• Precondiciones:
.Barrera, Corroppoli, Dans, Ibañez 107
2003

108. Contratos para el caso típico comprar productos
Contrato para EfectuarPago (Cont.)
• Poscondiciones:
– Se creó un Pago (creación de instancia).
– Se asignó a Pago.MontoOfrecido el valor de monto
(modificación de atributo).
– Se asoció el Pago a la Venta (asociación formada).
– Se asoció la Venta a la Caja para agregarla al registro histórico
de las ventas terminadas (asociación formada)
.Barrera, Corroppoli, Dans, Ibañez 108
2003

109. Cómo preparar un contrato
• Identificar las operaciones del sistema a partir de
los diagramas de secuencias.
• Elaborar un contrato en cada operación del
sistema.
• Comenzar redactando la sección
responsabilidades, describiendo el propósito de la
operación.
.Barrera, Corroppoli, Dans, Ibañez 109
2003

110. Cómo preparar un contrato (cont.)
• Completar la sección poscondiciones
describiendo los cambios de estado de los
objetos en el modelo conceptual.
• Para describir las poscondiciones utilizar las
siguientes categorías.
• Creación y eliminación de las instancias.
• Modificación de los atributos.
• Asociaciones formadas y canceladas.
.Barrera, Corroppoli, Dans, Ibañez 110
2003

111. Actividad
• Confeccionar los principales items de las
operaciones del sistema referentes a los
diagramas de secuencia del video.
.Barrera, Corroppoli, Dans, Ibañez 111
2003

112. Conclusión de la fase de análisis
Artefactos del análisis Preguntas que se contestan
Casos típicos ¿Cuáles son los procesos de la aplicación?
Modelo conceptual ¿Cuáles son los conceptos los términos?
¿Cuáles son los eventos y las operaciones del
Diagramas de secuencia
sistema?
Contratos ¿Qué hacen las operaciones del sistema?
.Barrera, Corroppoli, Dans, Ibañez 112
2003

113. Modelo Conceptual
Diagramas de
Casos Típicos casos típicos
Diagramas
Modelo
de clase
Conceptual
Glosario
Diagramas Diagramas
de estado de interacción
.Barrera, Corroppoli, Dans, Ibañez 113
2003

114. Mensajes y métodos
• Los objetos no son conjuntos de datos pasivos
• Pueden interactuar entre sí
• Se comunican a través de mensajes
• Cada objeto que recibe un mensaje lo atiende con un
método (comportamiento)
• El conjunto de mensajes que cada objeto puede
atender se denomina interface.
.Barrera, Corroppoli, Dans, Ibañez 114
2003

115. Actividades del Sistema
Diagramas de Actividad:
- Diagrama de secuencia:
basado en el tiempo
formato en progresión vertical
- Diagrama de colaboración:
basado en el espacio
formato en red
.Barrera, Corroppoli, Dans, Ibañez 115
2003

116. Diagrama de colaboración
1. Hacer un diagrama por cada operación
2. Si es muy complejo, subdividir en más simples
3. Empezar desde las responsabilidades
4. Tener en cuenta las postcondiciones
5. Considerar la descripción del caso típico
.Barrera, Corroppoli, Dans, Ibañez 116
2003

117. Diagrama de colaboración
teclea
1:notificar(teclea)
GUI
6:respuesta
S. Operativo
3:actualizar(teclea)
Monitor
2:actualizar(teclea)
5:mostrar(teclea) CPU
4:notificar(teclea)
Tarjeta Video
.Barrera, Corroppoli, Dans, Ibañez 117
2003

118. Diagrama de colaboración
Sintaxis de los mensajes:
Retorno : mensaje(parámetro : tipoParámetro) : tipoRetorno
Mensajes a sí mismo ( o a “esto”):
Mens1()
Objeto
1:actualizar()
Iteración:
Se agrega un asterisco (*) al número de secuencia
.Barrera, Corroppoli, Dans, Ibañez 118
2003

119. Diagrama de colaboración
Mensajes condicionales:
mens1() 1a: [prueba mens2()
Objeto1 Objeto2
1b: [no prueba mens4() 1a.1: mens3()
1b.1: mens5()
Objeto4 Objeto3
.Barrera, Corroppoli, Dans, Ibañez 119
2003

120. Diagrama de colaboración
Multiobjetos (conjunto de instancias):
mens1() 1a: mens2()
Objeto1 Objeto2
El mensaje dirigido a un multiobjeto no se
transmite a todos los elementos
.Barrera, Corroppoli, Dans, Ibañez 120
2003

121. Diagrama de colaboración
IntroducirProducto
1:[nueva venta] crear()
introducirProducto(cup, cant) 3:hacerLineadeProducto(especif,cant) :Venta
:Caja
1:1 crear()
2:especif:=especificacion(cup) 3:1 crear(especif,cant)
Vli:Ventas-
:CatalogodeProductos LineadeProducto
2:1especif:=encontrar(cup) 3.2 agregar(vli)
:Especificación- :VentasLinea-
deProducto Corroppoli, Dans, Ibañez
.Barrera, deProducto 121
2003

122. Venta Caja
fecha
hora
terminarVenta()
estaTerminada
seTermina() introducirProduc
to()
hacerLineadeProduc
to() efectuarPago()
efectuarPago()
Total()
.Barrera, Corroppoli, Dans, Ibañez 122
2003

123. Diagrama de secuencia
Objeto 1 Objeto 2 Objeto 3
Mensaje asincrónico
Activación
Mensaje sincrónico
Mensaje sin respuesta
“crear” “temporario”
Objeto 4
Mensaje simple
“destruir”
X
.Barrera, Corroppoli, Dans, Ibañez 123
2003

124. Diagrama de Estado
El diagrama de estado del UML describe los eventos y
estados más relevantes de un objeto, así como su
comportamiento ante cada evento.
Evento: es un acontecimiento u ocurrencia notable,
que desencadena un cambio de estado.
Estado: es la condición de un objeto en un momento
determinado, o el tiempo que transcurre entre dos
eventos.
Transición: es una relación entre dos estados. Cuando
ocurre un evento, el objeto pasa de un estado al
siguiente.
.Barrera, Corroppoli, Dans, Ibañez 124
2003

125. Diagrama de Estado
Nombre
Iniciar Terminar
Variables de estado
Actividades
* Casos típicos (procesos)
* Sistemas
* Ventanas
Posibles diagramas * Coordinadores de aplicaciones
* Controladores
* Transacciones
* Dispositivos
* Mutadores
.Barrera, Corroppoli, Dans, Ibañez 125
2003

126. Diagramas de Clases (I)
Cliente Mozo Mesa
Cocinero Adicio- Cocina
nista
Menú Vajilla Salón
.Barrera, Corroppoli, Dans, Ibañez 126
2003

127. Diagramas de Clases (II)
Cliente Mozo Mesa Vajilla
Cocina
Cocinero
Menú Adicionista
Salón
.Barrera, Corroppoli, Dans, Ibañez 127
2003