Uml 2004 para impresion

.Barrera, Corroppoli, Dans, Ibañez

2003

1

INTRODUCCION AL UML

(Lenguaje Unificado de Construcción de

Modelos)


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


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


2003

4 Los 70

Los 80

90-94

10/95

6/96

1/97

9/97

11/97

Análisis estructurado

Técnicas orientadas

a objetos

Booch-91

Booch-93

OMT - 1

OMT - 2 OOSE Método unificado

Distintas versiones

del UML 1.1 enviado a OMG

UML de los tres amigos

Se inicia el estándar OMG


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


2003

6

Gerente General

Finanzas Personal Producción Distribución Servicios al

cliente

Cliente


2003

7

La organización como un proceso

Cliente

Proceso

Actividades

Unidad Organizacional

Localización

Interactúa con

Comprende

Ejecuta

Ubicada en


2003

8

Sistemas de Información

• Permiten:

– capturar

– procesar

– almacenar

– distribuir

datos


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


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.


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.


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


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.

Caso típico

Actor Actor

Sistema


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


2003

15

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.

Caso típico de alto nivel: comprar producto


2003

16

Actores

• Entidad externa al sistema

• Estimula al sistema con eventos

• O recibe algo del sistema

Cliente


2003

17

Cajero Cliente

Compra producto

Registra compra

Entrega cambio

Caja

Diagrama del caso típico


2003

18

Actividad

• Pensar un caso típico de alto nivel

– Expresarlo en forma textual o gráfica según

cada uno prefiera


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


2003

20

Ejemplo de un caso típico expandido:

comprar productos con efectivo

• Caso de uso

• Actores

• Propósito

• Resumen

• Tipo

• Referencias

cruzadas

• Comprar productos en efectivo

• Cliente(iniciador), cajero

• Capturar una venta y su pago en efectivo

• 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

• Funciones: Las veremos más adelante


2003

21

Ejemplo de un caso típico expandido: comprar productos con efectivo (Cont)

Acción del actor

1. Este caso comienza cuando un

Cliente llega a una caja con

productos que desea comprar

2. El Cajero registra el identificador

de cada producto.

Si hay varios productos de una

misma categoría, el Cajero

también puede introducir la

cantidad

Respuesta del sistema

3. Determina el precio del producto e

incorpora a la transacción actual

la información correspondiente.

Se presenta la descripción y el

precio del producto actual.

Curso normal de los eventos


2003

22

Ejemplo de un caso típico expandido: comprar productos con efectivo (Cont)

Acción del actor

4. Al terminar de introducir el

producto, el Cajero indica a la

caja que se concluyó la captura

del producto.

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


5. Calcula y presenta el total de la

venta

9. Muestra al Cliente la

diferencia. Genera un recibo


2003

23

Ejemplo de un caso típico expandido:

comprar productos con efectivo (Cont)

Acción del actor

10. El Cajero deposita el efectivo

recibido y extrae el cambio del

pago

El Cajero da al Cliente el cambio

y el recibo impreso

12. El Cliente se marcha con los

artículos comprados


11. Registra la venta concluida

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


2003

24

Explicación del formato expandido

Caso típico

Actores

Propósito

Resumen

Tipo

Referencias

cruzadas

Nombre del caso típico

Lista de actores, en la cual se indica quién

inicia el caso típico

Intención del caso típico

Repetición del caso típico de alto nivel o alguna

síntesis similar

1. Primario, secundario u opcional

2. Esencial o real

Casos típicos relacionados y funciones

también relacionadas

La primera sección del caso expandido es muy suscinta


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


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


2003

27

Actividad

• Definamos los casos tipicos del Video

Club o Biblioteca

– En formato de alto nivel


2003

28

Requerimientos - Funciones del

Sistema

• Lo que éste debe hacer

• Categorías

– Evidente

– Oculta

– Superflua


2003

29

Funciones del sistema

Ref. Función Categoría

R1.1 Registrar la venta

en proceso

Evidente

R1.2 Descontar del

stock las

cantidades

vendidas

Oculta

R1.3. Sonar un Bip por

time out

Superflua


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


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


2003

32

Atributos del sistema

Atributo Descripción

Tiempo de

respuesta

Cuando se registre un producto vendido, la

descripción y el precio aparecerán en cinco segundos

Metáfora de

interfaz

Ventanas orientadas a la metáfora de una forma y

cuadros de dialogo.

Tolerancia a

fallas

Debe registrar los pagos a crédito autorizados que se

hagan a las cuentas por cobrar en un plazo de 24

horas.


2003

33

Actividad

• Enumeremos atributos que deseamos para

nuestro sistema


2003

34

Atributos del sistema en las especificaciones de funciones

Ref. Función Categoría Atributo Detalles y

restriccio-nes Categoría

R1.1 Mostrar la descripción

y el precio del

producto registrado

Evidente Tiempo de

respuesta

5 segundos

como máximo

obligatorio

Metáfora de

interfaz

Pantallas

basadas en

formas

colorido

Obligatorio

Opcional


2003

35

Actividad

• Agregaremos a las funciones ya definidas los

atributos que correspondan


2003

36

Ámbito de UML

la orientación a objetos

• Los objetos son los conceptos, de los que hablábamos anteriormente.

Objeto persona

Atributos

nombre

edad

empresa

Comportamientos

CambiarEdad

CambiarEmpresa


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


2003

38

La clase Persona y sus instancias

Atributos

nombre

edad

empresa

Comportamientos

CambiarEdad

CambiarEmpresa

Instancia de persona nº 1

-nombre = SALAS

-edad=35

-empresa=IPV


-nombre = FUNES

-edad=55

-empresa=VPI

Instanciación

Instanciación


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.


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

CambiarEmpresa

Asalariado

jefe

función

CambiarJefe

CambiarFunción

Instancia


-nombre = RODRIGUEZ

-edad=36

-empresa=MUNI

-jefe=SANENZ

-función=encargado secció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


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


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


2003

44

Requerimientos - Atributos del

Sistema

• Son sus características

– Por ejemplo:

• Facilidad de uso

• Tiempo de respuesta

• etc


2003

45

Ejemplo de Atributos

Debe registrar los pagos a crédito autorizados

que se hagan a las cuentas por cobrar en un

plazo de 24 horas.

Tolerancia a

fallas

Pantallas con el isotipo del IPV, todas con el

mismo tono de fondo y las casillas distribui-das

de la misma forma.

Metáfora de

interfaz

Cuando se registre un producto vendido, la

descripción y el precio aparecerán en cinco

segundos

Tiempo de

respuesta

Descripción Atributo


2003

46

Actividad

• Enumeremos atributos que deseamos para

nuestro nuevo Sistema de Información.


2003

47

Atributos del sistema en las

especificaciones de funciones

Obligatorio

opcional

Pantallas

basadas en

formas

colorido

Metáfora de

interfaz

obligatorio 5 segundos

como máximo

Tiempo de

respuesta

Evidente Mostrar la descripción

y el precio del producto

registrado

R1.1

Categoría de

atributo

Detalles y

restriccio-nes Atributo

Categoría

de función Función Ref.


2003

48

Actividad

• Agregaremos a las funciones ya definidas

los atributos que deseamos.


2003

49

UML: la Orientación a Objetos

Un objeto es un concepto (personas, cosas, hechos, ideas, etc)

Nombre

Atributos

Comportamientos


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


2003

51

Ejemplo de Objeto

Objeto persona

Persona

nombre

edad

empresa

CambiarEdad

CambiarEmpresa


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

Instancia Instancia Instancia

Clase


2003

53

Actividades: 1. Identifique una clase que agrupe todos estos objetos

2. Agrupe diversos objetos en distintas clases.


2003

54

Instancias

Instancia persona nº 1

-nombre = SALAS

-edad=35

-empresa=IPV

Instancia persona nº 2

-nombre = FUNES

-edad=55

-empresa=VPI

Instanciación

Persona

nombre

edad

empresa

CambiarEdad

CambiarEmpresa


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

Asalariado

jefe

función

CambiarJefe

CambiarFunción

Instancia


-nombre = RODRIGUEZ

-edad=36

-empresa=MUNI

-jefe=SANENZ

-función=encargado sección


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


2003

57

Polimorfismo El polimorfismo permite usar los mismos términos

del cliente.

Abrir ...


2003

58

Encapsulamiento e Interfaces

- ¿Cómo funciona?

- ¡A quién le

importa!

Pantalla

Teclado


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.


2003

60

Modelo Conceptual

• Nos muestra:

– Clases

– Asociaciones entre esas Clases

– Atributos de dichas Clases


2003

61

Ejemplo

Línea Aérea

Emplea

Vuelo Avión Asignada-a Asignado-a Persona

nombre

edad

empresa


2003

62

Maneras de definir Clases

Venta

Fecha

hora

Por el Símbolo

“Una venta representa

el evento de una

transacción de compra.

Tiene fecha y hora”

Definición intensiva

Definición extensiva Venta-1

Venta-2 Venta-3

Venta-4


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.


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


2003

65

Descomposición del problema (cont.)

• Una guía para esta fase:

– Identificar varias clases

– Documentar los resultados en un modelo

conceptual


2003

66

Clases del Caso de la Caja

Local Caja Venta

Agreguemos otras clases que puedan

identificar:


2003

67

Estrategias para identificar las clases

• A partir de una lista de categorías de

clases

• Identificación de frases nominales


2003

68

Identificación de frases nominales

Acción del actor

1. Este caso comienza cuando

un Cliente llega a una caja

con productos que desea

comprar

2. El Cajero registra el

identificador de cada

producto.

Si hay varios productos de

una misma categoría, el

Cajero también puede

introducir la cantidad


3. Determina el precio del

producto e incorpora a la

transacción actual la

información

correspondiente.

Se presenta la descripción

y el precio del producto

actual.


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.


2003

70

Identificando las clases

Vuelo

Destino

Vuelo

Aeropuerto

nombre

¿o...?

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.

En caso de duda, convertir el atributo en clase.


2003

71

Resumiendo

Clase “es una descripción de un conjunto de

objetos que comparten los mismos

atributos, relaciones y comportamientos”


2003

72

En UML las asociaciones son

relaciones entre las clases

Producto Local Almacenado en

1 1


2003

73

Asociaciones

• La asociación es una relación entre dos

clases que indica alguna conexión

significativa e interesante entre ellas

Caja Venta actual Registra

asociación


2003

74

Notación de las asociaciones en UML

Vuelo Avión Asignado-a

* 1

nombre

multiplicidad

navegabilidad


2003

75

Notación de las asociaciones en UML

(Ejemplo)

¿ ? Adjudicatario Asignado-a

* 1

nombre

multiplicidad

navegabilidad


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)


2003

77

Actividad • Caja-Local

• Ala-Avión

• VentasLineadeProducto-Venta

• TramodeVuelo-RutadeVuelo

• Caja-Local, Producto-Estante,

• Pasajero-Avión

• DescripcióndeProducto-Catálogo

• Vuelo-ProgramadeVuelos

• DescripcióndeProducto-Producto

• DescripcióndeVuelo-Vuelo

• VentasLíneadeProducto-Venta

• TrabajodeMantenimiento-Mantenimiento

• Cajero-Local

• Piloto-Avión

• Departamento-Tienda

• Mantenimiento-Línea Aérea

• Cajero-Caja

• Cliente-Cajero

• AgentedeReservaciones-Pasajero

• Pago-Venta

• Pasajero-Boleto

• Reservación-Cancelación

• Caja-Caja

• Ciudad-Ciudad

• Avión-Línea Aérea

• Venta-Caja


2003

78

Multiplicidad

• Define cuantas instancias de una clase pueden asociarse

a tantas instancias de otra clase

*

1...*

1...40

5

2, 5, 7

cero o más; “muchos”

uno o más

de uno a cuarenta

exactamente 5

exactamente dos, cinco o siete


2003

79

Las Relaciones Inolvidables

• Caja Captura Venta

• Venta pagada en efectivo

• ListadeProductos registra EspecificacióndePro-ductos

• Para conocer la venta actual genera un total, e imprime un ticket.

• Para saber si se pagó la venta, relaciona la cantidad ofrecida con el total de la venta e imprime un ticket.

• Para recuperar una EspecificacióndeProducto, mediante un código universal de producto.


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


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


2003

82

Notación de los atributos en UML

Venta

fecha

hora

Aeropuerto

nombre

atributos


2003

83

Aplicación

Armemos un Modelo Conceptual

Tomemos como ejemplo el Video Club

o la Biblioteca


2003

84

Modelo conceptual Ventas

LineadeProductos

cantidad

Venta

Fecha

hora

Pago

monto

Caja

Local

Dirección

nombre

Producto

Registra_venta_de

0..1 1

Contenida en 1..* 1

1

1

1

1

1

1

1..*

* Almacenado_en

Aloja

Capturada-en

Pagada-por


2003

85

Comportamiento de los sistemas -

Diagramas de secuencia

• Muestran gráficamente los eventos que los

actores solicitan al sistema.

Sistema


2003

86

Ejemplo • Se refiere a la secuencia normal de

los eventos en el caso típico comprar productos

Repetir hasta que no

haya mas productos

sistema como

caja negra actor

Sistema Cajero

introducirProducto(CUP, cantidad)

terminarVenta()

efecturaPago(monto) Texto que

aclara: control,

lógica,

iteración,etc Evento del sistema

Inicia una operación del sistema


2003

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.


2003

88

• 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



2003

89

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



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


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


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


2003

93

Diagrama de secuencia del caso típico

comprar productos

Sistema Cajero

introducirProducto(CUP, cantidad)

terminarVenta()

efecturaPago(monto)

Repetir hasta que no

haya mas productos


2003

94

Actividad

• Confeccionar los diagramas de secuencia

para los casos típicos primarios del Video

Club o la Biblioteca.


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


2003

96

Contratos Caso Típico: Comprar Productos - Curso Normal de los Eventos

1 Este caso típico comienza...

Sistema terminarVenta()

introducirProducto()

efectuarPago()

IntroducirProducto (cup, cantidad)

terminarVenta ( )

efectuarPago (monto)

Cajero Sistema

Operación: IntroducirProducto. Se trata de una nueva venta, por lo tanto después

de esta operación fue creada una Venta...


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.


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.


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


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.


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.


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.


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: El sistema conoce el CUP.


2003

104


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)


2003

105


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.


2003

106


Contrato para TerminarVenta (Cont.)

• Poscondiciones:

– Estableció Venta.EstaTerminada como verdadero

(modificación de atributo)


2003

107


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:


2003

108


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)


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.


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.


2003

111

Actividad

• Confeccionar los principales items de las

operaciones del sistema referentes a los

diagramas de secuencia del video.


2003

112

Conclusión de la fase de análisis

¿Qué hacen las operaciones del sistema? Contratos

¿Cuáles son los eventos y las operaciones del

sistema? Diagramas de secuencia

¿Cuáles son los conceptos los términos? Modelo conceptual

¿Cuáles son los procesos de la aplicación? Casos típicos

Preguntas que se contestan Artefactos del análisis


2003

113

Modelo Conceptual

Casos Típicos Diagramas de

casos típicos

Diagramas

de clase

Glosario

Diagramas

de interacción

Diagramas

de estado

Modelo

Conceptual


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.


2003

115

Actividades del Sistema

Diagramas de Actividad:

- Diagrama de secuencia:

- Diagrama de colaboración:

basado en el tiempo

formato en progresión vertical

basado en el espacio

formato en red


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


2003

117


GUI

S. Operativo

CPU

Tarjeta Video

Monitor

teclea

1:notificar(teclea)

2:actualizar(teclea)

3:actualizar(teclea)

4:notificar(teclea)

5:mostrar(teclea)

6:respuesta


2003

118


Sintaxis de los mensajes:

Retorno : mensaje(parámetro : tipoParámetro) : tipoRetorno

Mensajes a sí mismo ( o a “esto”):

Objeto

Mens1()

1:actualizar()

Iteración:

Se agrega un asterisco (*) al número de secuencia


2003

119


Mensajes condicionales:

Objeto1 Objeto2

Objeto4 Objeto3

mens1() 1a: [prueba mens2()

1b: [no prueba mens4() 1a.1: mens3()

1b.1: mens5()


2003

120


Multiobjetos (conjunto de instancias):

Objeto1

mens1() 1a: mens2()

Objeto2

El mensaje dirigido a un multiobjeto no se

transmite a todos los elementos


2003

121


IntroducirProducto

introducirProducto(cup, cant)

:Caja

2:especif:=especificacion(cup)

:CatalogodeProductos

2:1especif:=encontrar(cup)

:Especificación-

deProducto

3:hacerLineadeProducto(especif,cant)

:VentasLinea-

deProducto

:Venta

Vli:Ventas-

LineadeProducto

1:[nueva venta] crear()

1:1 crear()

3.2 agregar(vli)

3:1 crear(especif,cant)


2003

122

Caja

terminarVenta()

introducirProduc

to()

efectuarPago()

Venta

fecha

hora

estaTerminada

seTermina()

hacerLineadeProducto()

efectuarPago()

Total()


2003

123

Diagrama de secuencia

Objeto 1 Objeto 2 Objeto 3

“temporario”

Objeto 4

X

Mensaje asincrónico

Mensaje sincrónico

Mensaje sin respuesta

“crear”

Mensaje simple

“destruir”

Activación


2003

124

Diagrama de Estado

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.

El diagrama de estado del UML describe los eventos y

estados más relevantes de un objeto, así como su

comportamiento ante cada evento.


2003

125

Diagrama de Estado

Nombre

Variables de estado

Actividades

Iniciar Terminar

Posibles diagramas

* Casos típicos (procesos) * Sistemas * Ventanas * Coordinadores de aplicaciones * Controladores * Transacciones * Dispositivos * Mutadores


2003

126

Diagramas de Clases (I)

Cliente Mozo Mesa

Cocinero Adicio-

nista Cocina

Menú Vajilla Salón


2003

127

Diagramas de Clases (II)

Cliente Mozo Mesa

Cocinero

Adicionista

Cocina

Menú

Vajilla

Salón

Documents

Uml 2004 para impresion