Parte 3

Análisis Orientado a Objetos
Agregación de las Asociaciones: Notación
z Una asociación se representa como una línea entre los

conceptos con el nombre de la asociación.
y Esta es intrínsecamente bidireccional: es un nexo entre objetos.
y Los extremos de una asociación pueden contener una expresión de
multiplicidad que indique la relación numérica entre las instancias o
conceptos, que se llaman papeles.
UTFSM
EXUMBRA
IN
SOLEM Fundamentos de Ingeniería de SW 1

Identificación de asociaciones: lista de asociaciones
comunes
z Comience agregar las asociaciones utilizando la lista de

anexa.
y Categorías comunes que normalmente vale la pena incluir.
Categoría Ejemplos
Caja-TPDV
A es una parte física de B
Ala-Avión
VentasLineaDeProducto-Venta
A es una parte lógica de B
TramoDeVuelo-RutaDeVuelo
TPDV-Tienda Producto-Estante
A está físicamente contenido en B
Pasajero- Avión
DescripcionDeProducto – Catálogo
A está lógicamente contenido en B
Vuelo - ProgramaDeVuelo
UTFSM
EXUMBRA
IN
1
Identificación de asociaciones: lista de asociaciones
comunes
DescripcionDeProducto – Producto
A es una descripción de B
DescripcionDeVuelo - Vuelo
A es un elemento de línea en una VentasLineaDeProducto-Venta
transacción o reporte B TrabajoDeManteniemiento-Mantenimiento
A se conoce/ introduce/ registra/ presenta/ Venta – TPDV
captura en B Reservacion - ListaDePasajeros
Cajero – Tienda
A es miembro de B
Piloto – Avion
Departamento – Tienda
A es una subunidad organizacional de B
Mantenimiento - LineaAerea
Cajero – TPDV
A usa o dirige a B
Piloto – Avion
Cliente – Cajero
A se comunica con B
AgenteDeReservaciones - Pasajero
UTFSM
EXUMBRA
IN

Identificación de las asociaciones: lista de asociaciones
comunes
Pago – Boleta
A se relaciona con una transacción B
Pasajero – Boleto
A es una transacción relacionada con otra Pago – Venta
transacción B Reservacion – Cancelacion
TPDV – TPDV
A está contiguo a B
Cuidad – Cuidad
TPDV – Tienda
A es propiedad de B
Avion – LineaAerea
UTFSM
EXUMBRA
IN
2
Identificación de las asociaciones: lista de asociaciones
comunes
z Las categorías de alta prioridad que siempre vale la pena

incluir son las siguientes:
y A es una parte física o lógica de B
y A está físicamente o lógicamente contenido en B
y A está registrado en B
z Las asociaciones son importantes, pero la falla habitual al
crear los modelos conceptuales es el excesivo tiempo que
se dedica al intento de descubrirlas.
y Es mucho más importante identificar conceptos que asociaciones.
El tiempo consagrado a la creación del modelo conceptual debería
destinarse a identificar los conceptos, no las asociaciones.
UTFSM
EXUMBRA
IN

Directrices de las asociaciones
z Concentrarse en las asociaciones en que el conocimiento

de la relación ha de preservarse durante algún tiempo
(asociaciones que “es necesario conocer”).
z Muchas asociaciones tienden a confundir el modelo
conceptual en vez de aclararlo. A veces se requiere mucho
tiempo para descubrirlas, y los beneficios son escasos.
z No incluir las asociaciones redundantes, ni las derivables.
UTFSM
EXUMBRA
IN
3
Multiplicidad
z La multiplicidad define cuántas instancias de tipo A pueden

asociarse a una instancia del tipo B en determinado
momento.
Tienda Producto
1 Almacena *
Multiplicidad del papel
UTFSM
EXUMBRA
IN

Multiplicidad
z Algunos ejemplos de multiplicidad:
* cero o más, “muchos” 1..40 de uno a 40

1..* uno o más 5 exactamente 5
3,5,8 exactamente 3, 5 u 8
z En UML, el valor de multiplicidad depende del contexto, no

hay soluciones prefabricadas.
y Por ejemplo, asociación Trabaja-Para entre Persona y Compañía
tendrá diferencias en la multiplicidad dependiendo para quien se
esta haciendo el sistema: departamento de impuestos (1..*)o
sindicato de trabajadores (1..1).
UTFSM
EXUMBRA
IN
4
Notación
z Se asigna un nombre a una asociación basándose en el

formato NombreDeTipo-FraseNominal-NombreDeTipo,
y donde la frase nominal genera una secuencia que es legible y
significativa dentro del contexto del modelo.
y Los nombres de las asociaciones comienzan con una mayúscula.
y Una frase nominal (verbo) debe construirse con guiones.
y La dirección de lectura es de izquierda a derecha y de arriba hacia
abajo.
UTFSM
EXUMBRA
IN

Notación
Tienda
1
Contiene
1..*
TPDV Venta Pago
1 Captura 1..* 1 Pagada-por 1
Linea Aerea
1
Emplea
1..*
Persona Vuelo Avión

1 Asignada-a * * Asignado-a 1
1 *
UTFSM Supervisa
EXUMBRA
IN
5
Asociaciones múltiples entre dos conceptos
z Dos conceptos pueden tener varias asociaciones entre

ellos; sucede con frecuencia.
y Por ejemplo, en el dominio de la línea aérea encontramos varias
relaciones entre Vuelo y Aeropuerto.
y Las asociaciones volar-hacia y volar-de son netamente diferentes
que deben mostrarse por separado.
y Adiviértase asimismo que no se garantiza que todos los vuelos
aterricen en un aeropuerto.
* Vuela-de 1
Vuelo Aeropuerto
* Vuela-hacia 0..1
UTFSM
EXUMBRA
IN

Asociaciones y su implementación
z Durante la fase de análisis, una asociación no es una

proposición sobre flujos de datos, variables de instancia, ni
conexiones de objetos en una solución de software; es una
proposición de que una relación es significativa en un
sentido puramente analítico: en el mundo real.
z “Una asociación no necesariamente debe ser

implementada durante la construcción”
UTFSM
EXUMBRA
IN
6
Asociaciones del dominio del punto de venta
z Deberíamos incorporar las asociaciones que indican los

requerimientos (los casos de uso, por ejemplo), las que
conllevan la necesidad de recordar o que de alguna otra
forma nos sugiere nuestra percepción del dominio del
problema.
z Conceptos:
y TPDV, Producto, Tienda, Venta, Pago
y Catalogo De Producto, Especificación De Producto
y Ventas Línea De Productos
y Cajero, Cliente, Gerente
UTFSM
EXUMBRA
IN

z Relaciones inolvidables en la Tienda
TPDV captura Venta Para conocer la venta actual genera un total e

imprime un recibo.
Venta pagada en efectivo Para saber si se pagó la venta, relaciona la
cantidad ofrecida con el total de la venta e
imprime un recibo.
CatalogoDeProductos registra Para recuperar la especificación de producto con
EspecificacionDeProducto un código universal de producto
UTFSM
EXUMBRA
IN
7
z Recorreremos la lista de comprobación, basándonos en

tipos anteriormente identificados y teniendo presentes los
requerimientos actuales del caso de uso.
Categoría Sistema TPDV

A es una parte física de B no se aplica
A es una parte lógica de B VentasLineaDeProducto-Venta
TPDV-Tienda
A está contenido físicamente en B
Producto-Tienda
EspecificacionDeProducto –
A está contenido lógicamente en B CatalogodeProductos
CatalogodeProductos - Tienda
A es una descripción de B EspecificacionDeProducto – Producto
A es un elemento de línea en una
VentasLineaDeProducto-Venta
transacción o reporte B
UTFSM
EXUMBRA
IN

A se conoce/ introduce/ registra/ presenta/ Venta (terminada) – Tienda

captura en B Venta (actual) – TPDV
A es miembro de B Cajero – Tienda
A es una subunidad organizacional de B no aplicable
Cajero – TPDV
Gerente – TPDV
A usa o dirige a B
Gerente – Cajero, probablemente no
aplicable
A se comunica con B Cliente – Cajero
Cliente – Pago
A se relaciona con una transacción B
Cajero – Pago
A es una transacción relacionada con otra
Pago – Venta
transacción B
A está contiguo a B TPDV – TPDV, probablemente no aplicable
A es propiedad de B TPDV – Tienda
UTFSM
EXUMBRA
IN
8
Modelo Conceptual del punto de venta
Descrita-por
Contiene
EspecificaciondeProducto
1
1..* 1
1
CatalogoDeProductos Describe
*
1 *
VentasLineaDeProducto 1 Producto
0..1 Registra-Venta-de
1..* Usado-por
* *
Contenidas-en
Capturas-Terminada Tienda 1
* Almacena
1 1 1
Venta Capturadas-en
Aloja Iniciado-por 1
1 1 1 Gerente
Iniciado-por 1 1..* 1
Pagado-por TPDV 1 1 Cajero
1 Registra-Ventas-en
Pago 1 Cliente
UTFSM
EXUMBRA
IN

z El conjunto de asociaciones que se incluye en el modelo se

obtuvo de manera bastante mecánica a partir de la lista de
comprobación. Pero tal vez hay que ser más restrictivos
con las asociaciones.
z Venta Capturada por Cajero
y Los requerimientos no indican la necesidad de conocer, ni de
registrar al cajero actual. Además es derivable si existe la
asociación TPDV usado-por Cajero.
z TPDV Usado-por Cajero
registrar al cajero actual.
UTFSM
EXUMBRA
IN
9
z TPDV Iniciado-por Gerente

registrar al gerente que inició un TPDV.
z Venta Iniciada por Cliente
registrar al cliente actual.
z Tienda Almacena Producto
y Los requerimientos no indican la necesidad de conocer o mantener
la información del inventario.
z Ventas Línea De Producto Registra-venta-de Producto
y Los requerimientos no indican la necesidad de mantener la
información del inventario.
UTFSM
EXUMBRA
IN

Descrita-por
Contiene EspecificaciondeProducto
1
1..* 1
1
CatalogoDeProductos Describe
*
1 *
VentasLineaDeProducto Producto
1..* Usado-por
*
Contenidas-en
Capturas-Terminada Tienda
*
1 1 1
Venta Capturadas-en
Aloja
1
1 Gerente
1 1..*
Pagado-por TPDV Cajero
1
Pago Cliente
UTFSM
EXUMBRA
IN
10
z Nótese que la capacidad de justificar una asociación

atendiendo a la necesidad de conocerla depende de los
requerimientos; un cambio de ellos – por ejemplo, exigir
que la identificación del cajero aparezca en el recibo –
altera la necesidad de recordar la relación.
z Enfatice las asociaciones que deben conocerse, pero

incorpore también las opcionales que se requieran sólo
para la comprensión, con el fin de enriquecer el
conocimiento básico del dominio.
UTFSM
EXUMBRA
IN

Agregación de los Atributos
z Recuerde que el modelo conceptual es una representación

de cosas reales, no de componentes de software.
Cualquier afirmación concerniente a los atributos ha de
interpretarse dentro del contexto de entidades del mundo
real.
z Un atributo es una valor lógico de un dato o de un objeto.
UTFSM
EXUMBRA
IN
11
z Incluya los siguientes atributos en el modelo conceptual:

y Aquellos en que los requerimientos (por ejemplo, casos de uso)
indican o conllevan la necesidad de recordar información.
x Por ejemplo, un recibo de ventas normalmente incluye fecha y hora.
En consecuencia, el concepto venta requiere dos atributos: fecha y
hora.
y Los atributos se muestran en la segunda sección de conceptos, es
opcional indicar su tipo.
Venta
Atributos
fecha
HoraDeInicio: hora
UTFSM
EXUMBRA
IN

z Los tipos más simples de atributos son los que, en la

práctica, suelen considerarse los tipos primitivos de datos.
y Por lo regular, el tipo de un atributo no debería ser un concepto
complejo del dominio, como Venta o Aeropuerto. Por ejemplo,
podríamos poner un atributo TPDV-Actual al concepto Cajero, que
no es un tipo simple, pero la forma más conveniente de expresarlo
es a través de la asociación.
Cajero Cajero TPDV

1 Usa 1
nombre nombre numero
TPDVactual
UTFSM
EXUMBRA
IN
12
z En un modelo conceptual es preferible que los atributos

sean atributos simples o valores puros de datos.
z Entre los tipos comunes de atributos simples más
frecuentes figuran:
y Booleano, Fecha, Numero, Cadena (Texto), Hora
y Direccion, Color, Geometria (punto, Rectangulo, …), Telefono, RUT,
Codigo Universal de Producto (CUP), codigo postal, tipos
numerados
z Una confusión frecuente consiste en modelar como
atributo un concepto complejo del dominio. Por lo tanto,
relacione conceptos a través de una asociación no con un
atributo.
UTFSM
EXUMBRA
IN

Atributos del sistema de punto de venta
z Es necesario producir una lista de atributos para los

conceptos del dominio de punto de venta. Debería estar
reservada específicamente a los requerimientos a las
simplificaciones en cuestión: Comprar productos versión 1.
z Para eso habrá que leer los siguientes documentos:
y especificación de requerimientos
y casos de uso en cuestión
y documentos de simplificaciones, clarificaciones y suposiciones
UTFSM
EXUMBRA
IN
13
z Por ejemplo, podemos identificar los atributos:

y Tienda: dirección, nombre
y Venta: fecha, hora
y VentasLineaDeProducto: cantidad
y Pago: monto
y EspecificacionDeProducto: decripcion, precio, cup
UTFSM
EXUMBRA
IN

z Es posible que el cajero reciba un grupo de productos

afines (seis paquetes de pañuelos desechables) y
introduzca una sóla vez el CUP y la cantidad (seis).
y En consecuencia una instancia de VentasLineaDeProducto puede
estar asociada a más de una instancia de cada producto.
y La cantidad que introduce el cajero puede quedar registrada como
atributo de VentasLineaDeProducto.
z Sin embargo, también puede ser calculada a partir del
valor real de multiplicidad de la relación; así puede
caracterizarse como atributo derivado, el cual puede ser
deducido de otra información.
y En UML, un atributo derivado se denota con el símbolo “/”.
UTFSM
EXUMBRA
IN
14
VentasLineaDeProducto Producto
/cantidad 0..1 Registra-venta-de 1..*
UTFSM
EXUMBRA
IN

Descrita-por
Contiene
1
1 1..* 1
CatalogoDeProductos
descripcion Describe
precio
* CUP
*
cantidad
1..* Usado-por
*
Contenidas-en Tienda
Capturas-Terminada
direccio
*
1 n
1
Venta 1
fecha Capturadas-en
hora Aloja
1
1
1 1..*
TPDV
Pagado-por
Pago 1
UTFSM
EXUMBRA
IN
15
z Hemos creado un modelo conceptual relativamente útil del

dominio del punto de venta.
z No existe un modelo apropiado para todos los casos y
circunstancias, todos ellos no son más que aproximaciones
al dominio que queremos entender.
z Un buen modelo conceptual capta las abstracciones
esenciales y la información indispensable para comprender
el dominio dentro del contexto de los requerimientos
actuales.
UTFSM
EXUMBRA
IN

Resumen
z Identificación de conceptos
y Ejemplo
z Principio del cartógrafo
z Asociaciones de conceptos
z Identificación de atributos
z Construcción del modelo conceptual
UTFSM
EXUMBRA
IN
16
Quiz
z ¿Qué es lo que aparece en el modelo conceptual?

z ¿Qué es el principio del cartógrafo?
z ¿Qué representa una asociación?
z ¿Todas las asociaciones son importantes?
z ¿Qué representa la multiplicidad?
z ¿Porqué son tan importantes los nombres en el modelo?
UTFSM
EXUMBRA
IN

Quiz
z ¿Cómo se interpreta este diagrama?
<<entorno>>
OpcionesCursoProfesor <<entorno>>
AñadirOfertaCurso
1 1
1
<<control>> 1 <<entidad>>
GestorCursosProfesor OfertaCursos
maneja
0..* 1..*
<<entidad>>
1..* 1
Cursos
0..*
0..*
prerrequisitos
UTFSM
EXUMBRA
IN
17
Contenido
z Comportamiento de los sistemas

z Diagrama de secuencia del sistema
z Contratos
y Precondiciones
y Postcondiciones
UTFSM
EXUMBRA
IN

Comportamiento de los Sistemas
Perfeccionamien Sincronización Análisis Diseño Construcción Prueba

to del plan de artefactos
1. Definir casos 2. Perfeccionar 3. Perfeccionar 4. Perfeccionar

esenciales de el diagrama de el modelo el glosario
uso casos conceptual
5. Definir 6. Definir los 7. Definir

diagramas de contratos de diagramas de
secuencia operaciones estado
UTFSM
EXUMBRA
IN
18
Diagrama de Secuencia del Sistema
z Antes de iniciar el diseño lógico de cómo funcionará una

aplicación de software es necesario investigar y definir su
comportamiento como una “caja negra”.
z El comportamiento del sistema es una descripción de lo

que hace, sin explicar la manera en que lo hace. Una parte
de esa descripción es un diagrama de secuencia del
sistema.
UTFSM
EXUMBRA
IN

z Los casos de uso indican cómo los actores interactúan con

el sistema de software que es lo que realmente queremos
crear.
z Durante la interacción un actor genera eventos dirigidos a

un sistema, solicitando alguna operación a cambio.
y Por ejemplo, cuando un cajero introduce un código universal de
producto de un artículo, está pidiendo al sistema TPDV registrar el
código.
UTFSM
EXUMBRA
IN
19
z El diagrama de secuencia de un sistema es una

representación que muestra, en un determinado escenario,
los eventos generados por actores externos, su orden y los
eventos externos del sistema.
y A todos los sistemas se les trata como caja negra; los diagramas se
centran en los eventos que fluyen de los actores a los sistemas.
y En el diagrama el tiempo avanza hacia abajo, y el ordenamiento de
los eventos debería seguir el orden indicado en el caso de uso.
y Los eventos del sistema pueden incluir parámetros.
Sistema como
Actor caja negra
:Sistema
UTFSM
EXUMBRA
IN

z Curso normal de los eventos en el caso Comprar Productos.
Sistema como
Actor caja negra
:Sistema
: Cajero
1: introducir Producto(CUP, cantidad)
2: terminarVenta()
3: efectuarPago(monto)
Evento del sistema

Inicia una operación de
sistema
UTFSM
EXUMBRA
IN
20
Eventos y operaciones del sistema
z El evento de un sistema es un hecho externo de entrada

que un actor produce en un sistema.
z La operación de un sistema es una acción que éste ejecuta
en respuesta a una evento del sistema.
y Por ejemplo, cuando un cajero genera un evento
introducirProducto, causa la ejecución de la operación
introducirProducto;
z El nombre del evento y de la operación son idénticos; la
distinción reside en que el evento es el estímulo nombrado
y la operación es la repuesta (lo mismo sucede con los
mensajes y los métodos).
UTFSM
EXUMBRA
IN

Registro de las operaciones de un sistema
z Para determinar el conjunto de las operaciones requeridas

del sistema se identifican sus eventos. Cuando se utilizan
los parámetros, las operaciones son las siguientes:
y EfectuarPago(CUP, Cantidad)
Sistema
y TerminarVenta()
y EfectuarPago(monto) terminarVenta( )
introducirProducto ( )
efectuarPago( )
z ¿Donde deberían registrarse estas operaciones?. En UML

se pueden agruparse las operaciones como operaciones de
tipo Sistema. Los parámetros son opcionales.
UTFSM
EXUMBRA
IN
21
Registro de las operaciones de un sistema
z Observe que la representación del tipo Sistema es muy

diferente a lo que se expresó en el modelo conceptual.
z Los elementos de éste representan conceptos del mundo

real; en cambio, el tipo Sistema es un concepto artificial.
y Ello se debe a la naturaleza de la información que estamos
representando: mientras el modelo conceptual es la información
estática, el tipo Sistema representa el comportamiento de sistema,
el cual es la información dinámica.
UTFSM
EXUMBRA
IN

z Para elaborar un diagrama de secuencia del sistema que

describa el curso normal de los eventos en un caso de uso:
y Trace una línea que represente el sistema como una caja negra.
y Identifique los actores que operan directamente sobre el sistema.
Trace una linea para cada uno de ellos.
y A partir del curso normal de los eventos del caso de uso identifique
los eventos (“externos”) del sistema que son generados por los
actores. Muéstrelos gráficamente en el diagrama.
y A la izquierda del diagrama puede incluir o no el texto del caso de
uso.
UTFSM
EXUMBRA
IN
22
z Consideramos ahora el caso de uso Comprar Productos a

fin de identificar los eventos del sistema.
y Primero debemos determinar los actores que interactúan
directamente con el sistema de software.
y El cliente interactúa con el cajero, pero no directamente con el
sistema TPDV; esto sólo lo hace el cajero.
y Por tanto, el cliente no es un generador de eventos del sistema,
sólo el cajero lo es.
UTFSM
EXUMBRA
IN

z Los eventos de un sistema (y sus operaciones asociadas)

deben expresarse en el nivel de propósito y no en el nivel
el medio físico de entrada o de elementos de la interfaz.
z También mejora la claridad, si el nombre de un evento del
sistema comienza con un verbo (agregar, introducir,
terminar, efectuar), ya que recalca que los eventos están
orientados a comandos.
y Así, “terminarVenta” es preferible a “IntroducirTeclaOprimida”
porque capta mejor el propósito de la operación: mantiene un
carácter abstracto y no se pronuncia respecto a las decisiones de
diseño sobre cuál interfaz sirve para capturar el evento del sistema.
UTFSM
EXUMBRA
IN
23
z En cuanto a expresar las operaciones en el nivel de

propósito, procure alcanzar el nivel más alto o la meta final
de asignar nombre a la operación. Por ejemplo, respecto a
la operación que captura el pago:
y IntroducirImporteOfrecido(monto) – deficiente
y IntroducirPago(monto) – mejor
y EfectuarPago – quizá mejor aún
UTFSM
EXUMBRA
IN

Modelo de análisis
z Los diagramas de la secuencia de un sistema forman parte

del modelo de comportamiento del sistema.
z El modelo de análisis se compone de:
y Modelo de casos de uso de análisis (modelo dinámico)
x Casos de uso de alto nivel o esenciales
x Diagramas de casos de uso
y Modelo conceptual (modelo estático)
x Diagramas de estructura estática para los conceptos de dominio
y Modelo de comportamiento (modelo dinámico)
x Diagramas de secuencia del sistema
x Contratos para las operaciones de sistema
y Modelo de estado del análisis (modelo dinámico)
x Diagramas de estado para conceptos y casos de uso
UTFSM
EXUMBRA
IN
24
Comportamiento de los sistemas: contratos
z Los contratos contribuyen a definir el comportamiento de

un sistema; describen el efecto de las operaciones sobre el
sistema.
y El lenguaje UML (pero no el Rational Rose) ofrece un soporte para
definir las precondiciones y las poscondiciones de las operaciones.
z Los contratos de operación de sistema se elaboran durante
la fase de análisis en un ciclo de desarrollo.
z Su desarrollo depende del desarrollo previo del modelo
conceptual, de los diagramas de secuencia de sistema y la
identificación de sus operaciones.
UTFSM
EXUMBRA
IN

Descrita-por
Contiene
1
1 1..* 1
CatalogoDeProductos
descripcion Describe
precio
* CUP *
cantidad
1..* Usado-por
*
Contenidas-en Tienda
Capturas-Terminada direcci
*
1 1 on
Venta 1
fecha Capturadas-en
hora Aloja
1
1
1 1..*
TPDV
Pagado-por
Pago 1
UTFSM
EXUMBRA
IN
25
z En términos generales, un contrato es un documento que

describe lo que una operación se propone lograr.
y Suele redactarse en un estilo declarativo, enfatizando lo que
sucederá y no cómo se conseguirá.
y Los contratos suelen expresarse a partir de los cambios de estado
de las precondiciones y de las poscondiciones.
y Puede elaborarse un contrato tanto para un método de una clase,
como para una operación más global del sistema, aunque por
ahora nos concentramos en su uso para las operaciones globales
del sistema.
z El contrato de operación del sistema describe cambios del
estado del sistema total cuando se llama una de sus
operaciones.
UTFSM
EXUMBRA
IN

z El siguiente ejemplo describe un contrato de la operación

introducirProducto del sistema:
Contrato
Nombre: IntroducirProducto (cup:numero, cantidad:entero)
Responsabilidades: Capturar (registrar) la venta de un producto y agregarla a la venta. Desplegar
la descripción y el precio del producto.
Tipo: Sistema
Referencias cruzadas: Funciones del sistema: R1.1, R1.3, R1.6
Casos de uso: Comprar productos
Notas: Utilizar el acceso superrápido a la base de datos.
Excepciones: Si el CUP no es válido, indicar que se cometió.
Salida:
Precondiciones: El sistema conoce el CUP.
UTFSM
EXUMBRA
IN
26
Poscondiciones:
Si se trata de una nueva venta, se creó una Venta (creación de instancia ).
Si se trata de una nueva venta, la nueva Venta fue asociada a un TPDV ( asociación
formada).
Se creó una instancia VentasLineadeProducto (creación de instancia ).
Se asoció una instancia de VentasLineadeProducto a la Venta (asociación formada ).
Se asignó una cantidad a VentasLineadeProducto.cantidad (modificación de atributo ).
Se asoció una instancia VentasLineadeProducto a la instancia EspecificaciondeProducto ,
basado en la correspondencia del CUP ( asociación formada ).
z No todas las secciones del contrato son necesarias; se

recomienda llenar Responsabilidades y Poscondiciones.
UTFSM
EXUMBRA
IN

Contrato
Nombre: Nombre de la operación y sus parámetros.
Responsabilidades: Descripción informal de las responsabilidades que debe cumplir la operación.
Tipo: Nombre del tipo (concepto, clase de software, interfaz).
Referencias cruzadas: Números de referencia de las funciones del sistema, casos de uso, etc.
Notas: Declaraciones del diseño referentes a la operación. Por ejemplo, si se sabe
que se prefiere un algoritmo particular para manejar la operación, esa sección
es el sitio indicado.
Excepciones: Casos excepcionales.

Salida: Sólo dentro del sistema, no incorpore salidas de interfaz de usuario, mensajes
o registros que se envían fuera del sistema.
Precondiciones: Suposiciones acerca del estado del sistema antes de ejecutar la operación.
Poscondiciones: El estado del sistema después de la operación.
UTFSM
EXUMBRA
IN
27
z Aplique la siguiente sugerencia para elaborar contratos.

y Identifique las operaciones del sistema a partir de los diagramas de
secuencia.
y Elabore un contrato en cada operación del sistema.
y Comience redactando la sección Responsabilidades; después
describa informalmente el propósito de la operación.
y Complete la sección de Postcondiciones, describiendo en forma
declarativa los cambios de estado de los objetos en el modelo
conceptual.
y Para describir las postcondiciones utilice las siguientes categorías:
• Creación y eliminación de instancias.
• Modificación de atributos.
• Asociaciones formadas y canceladas.
UTFSM
EXUMBRA
IN

Poscondiciones
z Después de la sección de Responsabilidades, la parte más

importante del contrato son las poscondiciones, que
estipulan cómo cambió el sistema tras la operación.
z Las poscondiciones se expresan dentro del modelo

conceptual.
y ¿Qué instancias es posible crear? La repuesta es: las provenientes
del modelo conceptual.
y ¿Qué asociaciones es posible formar? La repuesta es: las que están
en el modelo conceptual.
UTFSM
EXUMBRA
IN
28
Poscondiciones
z Cuando se formulan contratos, en general se agregarán al

modelo conceptual nuevos conceptos, atributos y
asociaciones.
y Mejore el modelo conforme a los nuevos descubrimientos, mientras
reflexiona sobre los contratos de las operaciones.
z Las poscondiciones deberían expresar el estado de un
sistema, no las acciones a realizar.
y Expréselas en tiempo pasado para enfatizar que se trata de
declaraciones sobre un cambio pretérito de estado. Por ejemplo:
x Se creó una instancia VentasLineadeProducto (mejor)
y En lugar de
x Crear una instancia VentasLineadeProducto (peor)
UTFSM
EXUMBRA
IN

Poscondiciones
z Entonces, mire el contrato desde la perspectiva de un

escenario y un telón.
y Tome una fotografía de escenario antes de la operación
y Corra el telón y aplique la operación del sistema (ruido de fondo
con sonidos).
y Corra el telón y tome una segunda fotografía.
y Compare las fotografías de antes y después, y exprese como
poscondiciones los cambios del estado del escenario (se creó la
instancia VentasLineadeProducto…).
UTFSM
EXUMBRA
IN
29
Ejemplo
z Poscondiciones:
y Si se trata de una nueva venta, se creó una Venta (creación de instancia).
y Si se trata de una nueva venta, la nueva Venta fue asociada a un TPDV (asociación
formada).
y Se creó una instancia VentasLineadeProducto (creación de instancia).
y Se asoció una instancia de VentasLineadeProducto a la Venta (asociación
formada).
y Se asignó una cantidad a VentasLineadeProducto.cantidad (modificación de
atributo).
y Se asoció una instancia VentasLineadeProducto a la instancia
EspecificaciondeProducto, basado en la correspondencia del CUP (asociación
formada).
UTFSM
EXUMBRA
IN

Ejemplo
z Una vez que el cajero capturó el CUP y la cantidad del

producto, ¿Qué ha de crearse?.
z Si se trata de una nueva venta, habría que crear una
instancia para una nueva Venta. Una instancia
VentasLineadeProducto debería ser creada de modo
incondicional.
y Si se trata de una nueva venta, se creó una Venta (creación de
instancia).
y Se creó una instancia VentasLineadeProducto (creación de
instancia).
UTFSM
EXUMBRA
IN
30
Ejemplo
z Una vez que el cajero capturó el CUP y la cantidad del

producto, ¿qué atributos de los objetos nuevos o actuales
deberían ser modificados?. Habría que establecer la
cantidad de VentasLineadeProducto.
y Se asignó una cantidad a VentasLineadeProducto.cantidad
(modificación de atributo).
UTFSM
EXUMBRA
IN

Ejemplo
z Una vez que el cajero capturó el CUP y la cantidad del producto, ¿qué
asociaciones entre los objetos nuevos y actuales debieron haber sido
formadas o canceladas?.
z Habría que relacionar la nueva instancia de VentasLineadeProducto
con sus Ventas y con su Producto. Si se trataba de una nueva Venta
debió haber sido relacionada con la TPDV dentro del cual es
registrada.
y Se asoció una instancia de VentasLineadeProducto a la Venta (asociación
formada).
y Si se trata de una nueva venta, la nueva Venta fue asociada a un TPDV
(asociación formada).
y Se asoció una instancia VentasLineadeProducto a la instancia
EspecificaciondeProducto, basado en la correspondencia del CUP
(asociación formada).
UTFSM
EXUMBRA
IN
31
Precondiciones
z Las precondiciones definen las suposiciones sobre el

estado del sistema al iniciarse la operación.
z Hay muchas precondiciones que pueden declararse en una

operación, pero la experiencia revela que vale la pena
mencionar las siguientes:
y Cosas que son importantes de probar en el software en algún
momento de la ejecución de la operación.
y Cosas que serán sometidas a prueba, pero de las cuales depende
el éxito para subrayar la importancia y para hacer notarlas a los
otros lectores.
UTFSM
EXUMBRA
IN

Contratos
z El problema más común consiste en olvidar incluir la

formación de asociaciones. Sobre todo cuando se crean
nuevas instancias, muy probablemente será necesario
haber establecido las asociaciones a varios objetos.
UTFSM
EXUMBRA
IN
32
Contrato para introducirProducto
Contrato
Nombre: IntroducirProducto (cup:numero, cantidad:entero)
Responsabilidades: Capturar (registrar) la venta de un producto y agregarla a la venta. Desplegar
la descripción y el precio del producto.
Tipo: Sistema
Referencias cruzadas: Funciones del sistema: R1.1, R1.3, R1.6
Notas: Utilizar el acceso superrápido a la base de datos.
Excepciones: Si el CUP no es válido, indicar que se cometió un error.
Salida:
Precondiciones: El sistema conoce el CUP.
Poscondiciones:
• Si se trata de una nueva venta, fue creada unaVenta.
• Si se trata de una nueva venta, la nuevaVenta fue asociada a un TPDV.
• Se creó una instancia VentasLineadeProducto.
• Se asoció una instancia de VentasLineadeProductoa la Venta.
• Se asignó una cantidad a VentasLineadeProducto.cantidad.
• Se asoció una instancia VentasLineadeProducto a la instancia
EspecificaciondeProducto,
UTFSM
basado en la correspondencia del CUP.
EXUMBRA
IN

Contrato para terminarVenta
Contrato
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: R1.2
Notas:
Excepciones: Si no esta realizándose una venta, indicar que se cometió un error.
Salida:
Precondiciones:
Poscondiciones:
Estableció Venta.estaTerminada en verdadero .
UTFSM
EXUMBRA
IN
33
Contrato para efectuarPago
Contrato
Nombre: efectuarPago(monto: número)
Responsabilidades: Registrar el pago, calcular el saldo e imprimir el recibo.
Tipo: Sistema.
Referencias cruzadas: Funciones del sistema: R2.1
Notas:
Excepciones: Si la venta no está concluida, indicar que se cometió un error.
Salida:
Precondiciones: La venta esta terminada.
Poscondiciones:
Se creó una instancia Pago.
Se asoció el Pago a una Venta.
Se asignó el valor del monto a Pago.MontoOfrecido.
Se asoció la Venta a la Tienda para agregarla al registro histórico de las ventas terminadas.
UTFSM
EXUMBRA
IN

Contrato para Inicio
Contrato
Nombre: Inicio()
Responsabilidades: Inicializar el sistema
Tipo: Sistema.
Referencias cruzadas:
Notas:
Excepciones:
Salida:
Precondiciones:
Poscondiciones:
Se creó una instanciaTienda, TPDV, CatalogodeProductosy EspecificacionesdeProducto.
Se asoció CatalogodeProductosa EspecificacionesdeProducto.
Se asoció Tienda a CatalogodeProductos.
Se asoció Tienda a TPDV.
Se asoció TPDV a CatalogodeProductos.
UTFSM
EXUMBRA
IN
34
Cambios en el modelo conceptual
z Estos contratos sugieren la existencia de un dato que todavía no ha

figurado en el modelo conceptual: la terminación de la captura de los
productos en la venta. Lo modifica la operación terminarVenta y la
especificación efectuarPago lo toma como precondición.
z Una forma de representar esta información es a través de un atributo

estaTerminada de la Venta, por medio de un valor booleano.
Venta
estaTerminada:boolean
fecha
hora
UTFSM
EXUMBRA
IN

Resumen
z Comportamiento de los sistemas

z Diagrama de secuencia del sistema
z Contratos
y Precondiciones
y Postcondiciones
UTFSM
EXUMBRA
IN
35
Quiz
z ¿Qué es el comportamiento de un sistema?

z ¿Qué representa el diagrama de secuencia del sistema?
z ¿Cuál es la diferencia entre evento y operación?
z ¿Porqué se crea el concepto sistema?
z ¿Cuál es el nombre correcto para una operación?
z ¿Cuál es la diferencia entre lo estático y lo dinámico?
z ¿Porqué son necesarios los contratos y cuantos son para
un caso de uso?
z ¿Cuales son los condiciones para elaborar un contrato?
z ¿Cuales son las partes más importantes del contrato?
UTFSM
EXUMBRA
IN
Diseño Orientado a Objetos

Contenido
z Fase de Diseño
y Artefactos
y Actividades
z Casos Reales de Uso
z Diagramas de Interacción
UTFSM
EXUMBRA
IN
36
Fase de Diseño
z En la fase de análisis del desarrollo se da prioridad al

conocimiento de los requerimientos, los conceptos y las
operaciones relacionadas con el sistema.
z Análisis se caracteriza por centrarse en cuestiones

concernientes al qué, mientras que el diseño se concentra
en cómo.
UTFSM
EXUMBRA
IN

Fase de Diseño
z El siguiente grupo mínimo de artefactos sirven para capturar los

resultados de una investigación:
y Casos de uso
x ¿Cuáles son los procesos del dominio?
y Modelo Conceptual
x ¿Cuáles son los conceptos, los términos?
y Diagramas de la secuencia de un sistema
x ¿Cuáles son los eventos y las operaciones del sistema?
y Contratos
x ¿Qué hacen las operaciones del sistema?
z Durante el ciclo de desarrollo iterativo es posible pasar a la fase de

diseño una vez terminados estos documentos de análisis.
UTFSM
EXUMBRA
IN
37
Fase de Diseño
z Durante la fase de diseño se logra una solución lógica que

se fundamenta en el paradigma orientado a objetos.
y Su esencia es la elaboración de diagramas de interacción, que

muestran gráficamente cómo los objetos se comunicarán entre
ellos a fin de cumplir con los requerimientos.
y La definición de los diagramas de interacción nos permite dibujar
los diagramas de diseño de clases que resumen la definición de las
clases (e interfaces) implementables en el software.
UTFSM
EXUMBRA
IN

Actividades
Perfeccionamiento Sincronización de Análisis Diseño Construcción Prueba

del plan artefactos
1. Definir los casos 2. Definir reportes, 3. Perfeccionar la

reales de uso interfaz de usuario arquitectura del
y storyboards sistema
4. Definir los 5. Definir los 6. Definir el

diagramas de diagramas de esquema de la
interacción clases de diseño base de datos
UTFSM
EXUMBRA
IN
38
Descripción de los casos reales de uso
z Un caso real de uso describe el diseño concreto del caso

de uso a partir de una tecnología particular de entrada y
salida, así como de su implementación global.
y Por ejemplo, si interviene una interfaz gráfica de usuario, el caso
real de uso incluirá los diagramas de las ventanas en cuestión y
una explicación de la interacción de bajo nivel con los artefactos de
la interfaz.
z Tal vez no sea necesario generarlos. Una alternativa podría
ser diseñar los storyboards o secuencias de pantallas de la
interfaz de usuario y ampliarlos con más detalles durante
la implementación.
UTFSM
EXUMBRA
IN

Ejemplo: Comprar Productos Versión 1
Caso de uso: Comprar productos, versión 1

Actores: Cliente (iniciador), Cajero
Propósito: Capturar una venta y su pago en efectivo.
Resumen: Un Cliente llega a la caja registradora con los artículos que comprará.
El Cajero registra los artículos y recibe una pago en efectivo. Al
terminar la operación, el Cliente se marcha con los artículos
comprados.
Tipo: Primario y real
Referencias Funciones: R1.1, R1.2, R1.3, R1.7, R2.1
Cruzadas:
Tienda de Objetos
CUP
A Cantidad E
Precio Desc. F
B
Total Saldo
C G
Ofrecido
D
Introducir Terminar Efectuar
Producto Venta Pago
UTFSM
EXUMBRA
IN
SOLEM H
Fundamentos deI Ingeniería de SW
J 78
39
Ejemplo: Comprar Productos Versión 1
Curso normal de eventos:
Acción de los actores Respuesta del sistema
1. Este caso de uso comienza cuando un
Cliente llega a una caja de TPDV con
productos que desea comprar.
2. Con cada producto, el Cajero teclea el 3. Agrega la información sobre el producto
código universal de producto (CUP) en A a la actual transacción de ventas.
de la Ventana 1. Si un producto se repite, el El precio del producto y la descripción del
Cajero también puede introducir la producto actual aparecen en el recuadro B
cantidad en E. Se oprime botón H después y F respectivamente de la Ventana 1.
de capturar cada producto
4. Al terminar de capturar los productos, el 5. Calcula y presenta en el recuadro C el
Cajero oprime el botón I para indicarle al total de la venta.
TPDV que se concluyó la captura de Tienda de Objetos
productos. E
CUP A Cantidad
6. … F
Precio B Desc.
Total C Saldo G
Ofrecido D
Introducir Terminar Efectuar

UTFSM Producto Venta Pago
EXUMBRA
IN
SOLEM Fundamentos de Ingeniería de H
SW I J 79

Diagramas de interacción
z Los diagramas de interacción no se pueden preparar si

antes no se generan los siguientes artefactos:
y Un modelo conceptual a partir del cual el diseñador podrá definir
las clases de software correspondientes a los conceptos. Los
objetos de las clases participan en las interacciones que se
describen gráficamente en los diagramas.
y Contratos de la operación del sistema: a partir de ellos el diseñador
identifica las responsabilidades y las poscondiciones que han de
cumplir los diagramas de interacción.
y Casos de uso reales (o esenciales): a partir de ellos el diseñador
recaba la información sobre las tareas que realizan los diagramas
de interacción, además de los estipulado en los contratos.
UTFSM
EXUMBRA
IN
40
z Un diagrama de interacción explica gráficamente las

interacciones existentes entre las instancias (y las clases).
y El punto de partida de las interacciones es el cumplimiento de las
poscondiciones de los contratos de operación.
z El UML define dos tipos de estos diagramas; ambos sirven

para expresar interacciones semejantes o idénticas al
mensaje.
UTFSM
EXUMBRA
IN

z Los diagramas de colaboración describen las interacciones

entre los objetos en un formato de grafo o red:
mensaje1() 1: mensaje2() 2: mensaje3()
Instancia1 : ClaseA Instancia2 : ClaseB
z Los diagramas de secuencia describen las interacciones en

una especie de formato de cerca o muro:
Instancia1 : Instancia2 :
ClaseA ClaseB
mensaje1() mensaje2()
mensaje3()
UTFSM
EXUMBRA
IN
41
Ejemplo de un diagrama de colaboración: efectuarPago
Dirección del Primer mensaje

mensaje
interno
efectuarPago( efectivoOfrecido) 1: efectuarPago (efectivoOfrecido)
: TPDV : Venta
Línea de
primer enlace
mensaje
Instancia 2: crear (efectivoOfrecido)
Parametro
: Pago
UTFSM
EXUMBRA
IN

Preparación de un diagrama de colaboración
z Elabore un diagrama por cada operación del sistema

durante el ciclo actual de desarrollo.
y En cada mensaje del sistema, dibuje un diagrama incluyéndolo
como mensaje inicial.
y Si el diagrama se torna complejo (por ejemplo), si no cabe
holgadamente en una hoja de papel carta, divídalo en diagramas
más pequeños.
y Diseñe un sistema de objetos interactivos que realicen las tareas,
usando como punto de partida las responsabilidades del contrato
de operación, las poscondiciones y la descripción de casos de uso.
z Aplique el GRASP y otros patrones para desarrollar un
buen diseño
UTFSM
EXUMBRA
IN
42
Relación entre los artefactos
Contrato IntroducirProducto introducirProducto(CUP,cantidad)

Poscondiciones:
:Sistema 1. Si se trata de una nueva venta
se creo una nueva venta…
: Cajero : TPDV
introducir Producto(CUP,cantidad)
terminarVenta()
efectuarPago(EfectivoOfrecido) efectuarPago(efectivoOfrecido)
Contrato EfectuarPago
Poscondiciones:
… : TPDV
Diagrama de secuencia del sistema Contratos Diagrama de colaboración
UTFSM
EXUMBRA
IN

Relación entre los artefactos
z Los casos de uso indican los eventos del sistema que se

muestran explícitamente en los diagramas de secuencia.
z En los contratos se describe la mejor conjetura inicial sobre
las operaciones del sistema.
z Las operaciones del sistema representan mensajes y éstos
originan diagramas que explican gráficamente cómo los
objetos interactúan para llevar a cabo las funciones
requeridas.
UTFSM
EXUMBRA
IN
43
Notación de los diagramas de interacción
z El UML ha adoptado un método simple y uniforme de distinguirlas

visualmente las instancias de acuerdo a tipo:
y Con cada tipo de elemento del UML (clase, actor, ...), una instancia utiliza
el mismo símbolo gráfico usado para representar el tipo, pero se subraya
el texto.
Clase Instancia Instancia con

nombre
Venta : Venta s1: Venta
z El vínculo (o enlace) es una trayectoria de conexión entre dos

instancias, indica la forma de navegación y visibilidad que es posible
entre las instancias.
y En un lenguaje más formal, el vínculo es una instancia de una asociación.
UTFSM
EXUMBRA
IN

z Si vemos dos instancias en una relación de cliente-

servidor, una trayectoria de navegación del cliente al
servidor significa que los mensajes pueden enviarse del
primero al segundo.
y Así, existe un vínculo o trayectoria de navegación entre TPDV y
una Venta, a lo largo del cual pueden fluir los mensajes; por
ejemplo, el mensaje agregarPago.
Parámetros
mens1() 2: agregarPago(monto: Numero)

:TPDV :Venta
Todos los mensajes fluyen por

el mismo vínculo .
UTFSM
EXUMBRA
IN
44
z Los mensajes entre objetos pueden representarse por

medio de una flecha con un nombre y situada sobre una
línea del vínculo.
y Se agrega un número de secuencia que indique el orden consecutivo de
los mensajes en la serie actual de control.
y Los parámetros de un mensaje pueden anotarse dentro de paréntesis
después del nombre del mensaje. Es opcional incluir o no el tipo de
parámetro en cuestión
y El lenguaje UML cuenta con una sintaxis estándar para los mensajes:
y retorno : mensaje(parametro: tipoParametro) : tipoRetorno
x No obstante, es legal servirse de otra sintaxis como la de Java o la de Smalltalk.
Recomendamos emplear la sintaxis estándar de UML a fin de que los diagramas
de colaboración sigan siendo un lenguaje relativamente independiente
UTFSM
EXUMBRA
IN

z Un objeto puede enviarse un mensaje de a sí mismo: esto

lo muestra gráficamente un vínculo consigo mismo, donde
el mensaje fluye a lo largo del vínculo.
mens1()
:TPDV
1: limpiar ()
UTFSM
EXUMBRA
IN
45
z La iteración se indica posponiendo un asterisco (*) al

número de secuencia. Ese símbolo significa que, dentro de
un ciclo, el mensaje va a ser enviado repetidamente al
receptor. También es posible incluir una cláusula de
iteración que indique los valores de recurrencia.
1*: [i:=1..10] li:=siguienteLineadeProducto():

mens1() VentasLineadeProducto
:TPDV :Venta
UTFSM
EXUMBRA
IN

z El mensaje de creación independiente del lenguaje es

crear, que se muestra en el momento de ser enviado a la
instancia que vamos a generar.
z El mensaje crear puede contener parámetros, lo cual indica
la transferencia de los valores iniciales.
mens1() 1:crear(cajero)
:TPDV :Venta
UTFSM
EXUMBRA
IN
46
z El orden de los mensajes se indica con un número de

secuencia, como se aprecia en la figura. El esquema de la
numeración es:
y El primer mensaje no se numera. Así, mens1() no lleva número.
y El orden y el anidamiento de los mensajes siguientes se indican
con un esquema legal de numeración, donde a los mensajes
anidados se les ha antepuesto un número. La anidación se denota
anteponiendo el número del mensaje de entrada al del mensaje de
salida.
mens1() 1:crear(cajero)
:TPDV :Venta
UTFSM
EXUMBRA
IN

Numeración compleja de secuencias
primero segundo
1: mens2()
tercero
: ClaseA : ClaseB
2: mens4()
1.1: mens3()
cuarto
2.1: mens5()
quinto
: ClaseC
2.2: mens6()
sexto
: ClaseD
UTFSM
EXUMBRA
IN
47
z Un mensaje condicional se indica posponiendo al número

de la secuencia una cláusula condicional entre corchetes,
en forma parecida a como se hace con una cláusula de
iteración. El mensaje se envía sólo si la cláusula se evalúa
como verdadera.
mens1() 1:[nueva venta] crear()

:TPDV :Venta
UTFSM
EXUMBRA
IN

z Un multiobjeto, o conjunto de instancias, puede dibujarse

como un icono de pila según se observa en la figura.
Multiobjeto
Ventas : Venta
z Un multiobjeto suele implementarse como un grupo de

instancias guardadas en un contenedor u objeto colección;
y por ejemplo, un vector de la STL de C++, un Vector de Java o una
ColeccionOrdenada (OrderedCollection) de Smalltalk.
z Pero no necesariamente se implementa así; representa tan
sólo un conjunto lógico de instancias.
UTFSM
EXUMBRA
IN
48
z Un mensaje dirigido a un icono de multiobjeto indica que

se envía al objeto colección.
y Así, en la figura el mensaje tamaño está siendo enviado a la
instancia VentasLineadeProducto.
mensaje enviado al
objeto colección
1: s := tamaño(): entero
: Venta : VentasLineaDeProducto
z En el lenguaje UML los mensajes dirigidos a un multiobjeto

no se trasmiten a todos los elementos (como sucedía en
las versiones anteriores del UML).
UTFSM
EXUMBRA
IN

z Los mensajes pueden ser dirigidos a la propia clase y no a

una instancia, con el fin de llamar los métodos de la clase.
y Por ejemplo, en Java éstos se implementan como métodos
estáticos; en Smalltalk son métodos de clases.
no subrayada,
por tanto una clase
1: d1:=hoy(): Fecha
: Venta Fecha
z En consecuencia, es importante ser consistente en

subrayar los nombres de las instancias cuando se desea
denotar una instancia
y De lo contrario pueden interpretarse erróneamente los mensajes
dirigidos a las instancias y los dirigidos a las clases.
UTFSM
EXUMBRA
IN
49
Responsabilidades y métodos
z Booch y Rumbaugh definen la responsabilidad como “un

contrato u obligación de un tipo o clase”.
y Las responsabilidades se relacionan con las obligaciones de un
objeto respecto a su comportamiento.
z Esas responsabilidades pertenecen, esencialmente, a las
dos categorías siguientes: conocer o hacer
z Las responsabilidades se asignan a los objetos durante el
diseño orientado a objetos.
y Por ejemplo, puede declararse que una Venta es responsable de
“imprimirse ella misma” (un hacer) o que “una Venta tiene la
obligación de conocer su fecha” (un conocer).
UTFSM
EXUMBRA
IN

Responsabilidades y métodos
z Entre las responsabilidades de un objeto relacionadas con

hacer se encuentran:
y hacer algo en uno mismo
y iniciar una acción en otros objetos
y controlar y coordinar actividades en otros objetos
z Entre las responsabilidades de un objeto relacionadas con
conocer se encuentran:
y estar enterado de los datos privados encapsulados
y estar enterado de la existencia de objetos conexos
y estar enterado de cosas que se puede derivar o calcular
x Las responsabilidades relacionadas con “conocer” a menudo pueden inferirse
del modelo conceptual por los atributos y asociaciones explicadas en él.
UTFSM
EXUMBRA
IN
50

Parte 3

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Parte 3

Cargado por

Copyright:

Formatos disponibles

Análisis Orientado a Objetos

Agregación de las Asociaciones: Notación

z Una asociación se representa como una línea entre los

Análisis Orientado a Objetos

z Comience agregar las asociaciones utilizando la lista de

Análisis Orientado a Objetos

z Las categorías de alta prioridad que siempre vale la pena

Análisis Orientado a Objetos

z Concentrarse en las asociaciones en que el conocimiento

z La multiplicidad define cuántas instancias de tipo A pueden

Multiplicidad del papel

Análisis Orientado a Objetos

z Algunos ejemplos de multiplicidad:

* cero o más, “muchos” 1..40 de uno a 40

z En UML, el valor de multiplicidad depende del contexto, no

z Se asigna un nombre a una asociación basándose en el

Análisis Orientado a Objetos

Persona Vuelo Avión

z Dos conceptos pueden tener varias asociaciones entre

Análisis Orientado a Objetos

z Durante la fase de análisis, una asociación no es una

z “Una asociación no necesariamente debe ser

z Deberíamos incorporar las asociaciones que indican los

Análisis Orientado a Objetos

z Relaciones inolvidables en la Tienda

TPDV captura Venta Para conocer la venta actual genera un total e

z Recorreremos la lista de comprobación, basándonos en

Categoría Sistema TPDV

Análisis Orientado a Objetos

A se conoce/ introduce/ registra/ presenta/ Venta (terminada) – Tienda

Análisis Orientado a Objetos

z El conjunto de asociaciones que se incluye en el modelo se

z TPDV Iniciado-por Gerente

Análisis Orientado a Objetos

z Nótese que la capacidad de justificar una asociación

z Enfatice las asociaciones que deben conocerse, pero

Análisis Orientado a Objetos

z Recuerde que el modelo conceptual es una representación

z Un atributo es una valor lógico de un dato o de un objeto.

z Incluya los siguientes atributos en el modelo conceptual:

Análisis Orientado a Objetos

z Los tipos más simples de atributos son los que, en la

Cajero Cajero TPDV

z En un modelo conceptual es preferible que los atributos

Análisis Orientado a Objetos

z Es necesario producir una lista de atributos para los

z Por ejemplo, podemos identificar los atributos:

Análisis Orientado a Objetos

z Es posible que el cajero reciba un grupo de productos

/cantidad 0..1 Registra-venta-de 1..*

Análisis Orientado a Objetos

z Hemos creado un modelo conceptual relativamente útil del

Análisis Orientado a Objetos

z ¿Qué es lo que aparece en el modelo conceptual?

Análisis Orientado a Objetos

z ¿Cómo se interpreta este diagrama?

z Comportamiento de los sistemas

Análisis Orientado a Objetos

Perfeccionamien Sincronización Análisis Diseño Construcción Prueba

1. Definir casos 2. Perfeccionar 3. Perfeccionar 4. Perfeccionar

5. Definir 6. Definir los 7. Definir

z Antes de iniciar el diseño lógico de cómo funcionará una