Analisis y Diseño Orientado A Objetos

Anlisis y diseo orientado a objetos
? Qu es anlisis?
? Qu es diseo?
? El proverbio El hbito no hace el monje se aplica

perfectamente a la tecnologa de objetos.
Contenido
Muestra
? El hecho de conocer un lenguaje orientado a objetos (por ej. Java)

y adems tener acceso a una rica biblioteca (como la de Java) es
un primer paso necesario pero insuficiente para crear sistemas de
objetos.
? Se requiere adems analizar y disear un sistema desde la
perspectiva de objetos.
? Anlisis y diseo OO
? Uso de UML
? Introduccin al proceso de desarrollo
UTFSM
Fundamentos de Ingeniera de SW
N
I
EXUMBRA
SOLEM
73
UTFSM
N
I
EXUMBRA
SOLEM
74
? En conclusin, se ayudar a los ingenieros:
? El anlisis se centra en la investigacin del problema, no

en la manera de definir la solucin.
Muestra
Qu son anlisis y diseo?
? A aplicar los principios y patrones para aprender a desarrollar

mejores diseos.
? A efectuar varias actividades comunes en el anlisis y en el diseo.
? A crear elementos tiles en la notacin de UML.
? Por ejemplo, si se necesita un nuevo sistema de biblioteca, Cules

procesos de la institucin se relacionan con su uso?
? El diseo pone de relieve una solucin lgica: cmo el

sistema cumple con los requerimientos.
? Todo lo anterior ser ejemplificado con un caso.
? De qu manera el sistema de la biblioteca capturar y registrar

los prestamos de libros?.
? La esencia de estas actividades consiste en situar el

dominio de un problema y su solucin lgica dentro de la
perspectiva de los objetos.
UTFSM
N
I
EXUMBRA
SOLEM
75
UTFSM
N
I
EXUMBRA
SOLEM
? Durante el anlisis orientado a objetos se procura ante

todo identificar y describir los objetos o conceptos
dentro del dominio del problema.
Anlisis
? Durante el diseo orientado a objetos, se procura definir

objetos lgicos del software.
? Finalmente, durante la construccin o programacin
orientada a objetos, se implementan los componentes de
diseo.
Investigacin
del problema
UTFSM
N
I
EXUMBRA
SOLEM
Diseo
Construccin
Solucin Lgica
Cdigo
76
Anlisis
77
Diseo
Libro
titulo
Concepto de
Dominio
UTFSM
N
I
EXUMBRA
SOLEM
Representacin
en el diseo
Construccin
public class Libro
{
public void print();
Private String titulo;
}
Representacin en
programacin
78
Ejemplo
Definicin de los
casos de uso
Definicin del
Modelo
conceptual
Definicin de los
Diagramas de
colaboracin
Ejemplo
Definicin de los
Diagramas de
diseo de clases
Definicin de los
casos de uso
? Para entender los requerimientos se necesita, en parte,

conocer los procesos de dominio y el ambiente externo, o
sea los factores externos que participan en los procesos.
UTFSM
N
I
SOLEM
79
Definicin del
Modelo
conceptual
Definicin de los
Diagramas de
colaboracin
Definicin de los
Diagramas de
diseo de clases
? Caso de uso: Juega un juego

? Participantes: Jugador
? Descripcin:
Este caso de uso comienza cuando el jugador
recoge y hace rodar los dados. Si los puntos suman siete, gana y
pierde si suman cualquier otro numero.
UTFSM
N
I
EXUMBRA
SOLEM
80
Ejemplo
Definicin de los
casos de uso
Definicin de los
Diagramas de
colaboracin
? Por ejemplo, en el juego de los dados:
? Dichos procesos se pueden expresar en forma de casos de

uso, los cuales son una descripcin narrativa del proceso
de dominio en un formato estructurado de prosa.
EXUMBRA
Definicin del
Modelo
conceptual
Ejemplo
Definicin de los
Diagramas de
diseo de clases
Definicin de los
casos de uso
Definicin del
Modelo
conceptual
Definicin de los
Diagramas de
colaboracin
Definicin de los
Diagramas de
diseo de clases
? Por ejemplo, una parte del modelo conceptual muestra los

conceptos de Jugador, Dados y Juego de dados, sus
asociaciones y atributos.
? Para descomponer el dominio del problema hay que

identificar los conceptos, los atributos y las asociaciones
del dominio que se juzgan importantes.
? El resultado puede expresarse en un modelo conceptual, el
cual se muestra grficamente en un grupo de diagramas
que describen los conceptos (objetos).
Jugador
Dado
1
Lanza
nombre
2
valorMostrado
1
Juega
1
Juego de dados
1 Incluye
UTFSM
N
I
EXUMBRA
SOLEM
81
Definicin del
Modelo
conceptual
Definicin de los
Diagramas de
colaboracin
SOLEM
82
Ejemplo
Definicin de los
casos de uso
UTFSM
N
I
EXUMBRA
Ejemplo
Definicin de los
Diagramas de
diseo de clases
Definicin de los
casos de uso
? El modelo conceptual no es una descripcin de los

componentes de software; representa conceptos en el
dominio del problema del mundo real.
Definicin del
Modelo
conceptual
Definicin de los
Diagramas de
colaboracin
Definicin de los
Diagramas de
diseo de clases
? El diseo orientado a objetos tiene por objetivo definir las

especificaciones lgicas del software que cumplan con los
requisitos funcionales.
? Un paso esencial en esta fase es la asignacin de los
responsabilidades entre los objetos y mostrar como
interactan a travs de mensajes.
? El diagrama de colaboracin presenta el flujo de mensajes
entre las instancias y la invocacin de mtodos.
UTFSM
N
I
EXUMBRA
SOLEM
83
UTFSM
N
I
EXUMBRA
SOLEM
84
Ejemplo
Definicin de los
casos de uso
Definicin del
Modelo
conceptual
Definicin de los
Diagramas de
colaboracin
Ejemplo
Definicin de los
Diagramas de
diseo de clases
Definicin de los
casos de uso
? Por ejemplo, la figura muestra grficamente el paso

esencial del juego, enviando mensajes a las instancias de
las clases Jugador y Dado.
jugar()
1:r1:= lanzar()
:Jugador
UTFSM
SOLEM
85
Definicin de los
Diagramas de
colaboracin
UTFSM
N
I
EXUMBRA
Jugador
1
Lanza
Juego de dados
SOLEM
86
? En el anlisis y diseo estructurado, la dimensin de

descomposicin es fundamentalmente por funcin o proceso.
? En el anlisis y diseo orientado a objetos buscan ante todo
descomponer el espacio del problema por objetos.
valorMostrado
Incluye
inicializar()
N
I
EXUMBRA
varias
? Los proyectos de software son complejos, y la estrategia

primaria para superar la complejidad es la descomposicin
(divide y vencers): dividir el problema en unidades
manejables.
Definicin de los
Diagramas de
diseo de clases
lanzar()
1
Juega
1
UTFSM
SOLEM
Dado
jugar()
contestar
Comparacin con AD estructurado
? A diferencia del modelo conceptual, el modelo de diseo

no muestra grficamente conceptos del mundo real:
describe nicamente los componentes del software.
nombre
preciso
Ejemplo
Definicin del
Modelo
conceptual
es
d2:Dado
Definicin de los
casos de uso
clase
Definicin de los
Diagramas de
diseo de clases
? Por ejemplo, obtenemos que Jugador requiere de un

mtodo jugar, mientras que el Dado requiere de un
mtodo lanzar.
N
I
una
Definicin de los
Diagramas de
colaboracin
? Cmo se conectan unos objetos a otros?

? Cules son los mtodos de una clase?
d1:Dado
2:r2:= lanzar()
EXUMBRA
? Para definir
preguntas:
Definicin del
Modelo
conceptual
87
UTFSM
N
I
EXUMBRA
SOLEM
88
Introduccin al proceso de desarrollo
Comparacin con AD estructurado
Definicin
? Un proceso de desarrollo de software es un mtodo de

organizar las actividades relacionadas con la creacin,
presentacin y mantenimiento de los sistemas de software.
Sistema de la
biblioteca
? El lenguaje UML estandariza los artefactos y la notacin,

pero no define un proceso oficial de desarrollo.
A/D OO
Descomposicin por objetos o
conceptos
Catlogo
Bibliotecario
Libro
Biblioteca
UTFSM
N
I
EXUMBRA
SOLEM
? Aumentar las posibilidades de aceptacin generalizada de la

notacin estndar del modelado, sin la obligacin de adaptar el
proceso oficial.
? La esencia de un proceso apropiado admite mucha variacin y
depende de las habilidades del personal, de la naturaleza del
problema, de las herramientas y muchos otro factores.
A/D estructurados
Descomposicin por funciones o
procesos
Sistema
Registrar
Prstamos
Agregar
Recursos
Reportar
Multas
89
UTFSM
N
I
EXUMBRA
SOLEM
90
? En un nivel alto, los pasos principales de la presentacin

de una aplicacin son los siguientes:
? Un ciclo de vida iterativo se basa en el agrandamiento y

perfeccionamiento secuencial de un sistema a travs de
mltiples ciclos de desarrollo de anlisis, diseo,
implementacin y pruebas.
Pasos de macronivel
Desarrollo Iterativo
? Planificacin y elaboracin: planificar, definir los

requerimientos, construir prototipos, etc.
? Tras una fase preliminar de planificacin y especificacin, el

desarrollo pasa a la fase de construccin a travs de una serie de
ciclos de desarrollo.
? Construccin: la creacin del sistema.

? Aplicacin: la transicin de la implementacin del sistema a
su uso.
Planificacin
y Elaboracin
Construccin
Ciclo de
desarrollo 1
UTFSM
N
I
EXUMBRA
SOLEM
91
UTFSM
Ciclo de
desarrollo 3
N
I
EXUMBRA
Ciclo de
desarrollo 2
Aplicacin
SOLEM
92
? En cada ciclo se aborda un conjunto relativamente

pequeo de requerimientos, pasando por el anlisis, el
diseo, la construccin y las pruebas.
Planificacin
y Elaboracin
Construccin
Aplicacin
? El sistema va creciendo con cada ciclo que se concluye.

Ciclo de
desarrollo 1
? Entre las ventajas de un ciclo iterativo figuran:

? La complejidad nunca resulta abrumadora.
? Se produce retroalimentacin en una etapa temprana, porque la
implementacin se efecta rpidamente con una parte pequea del
sistema.
UTFSM
N
I
EXUMBRA
SOLEM
93
Ciclo de
desarrollo 2
Perfeccionar
el plan
UTFSM
N
I
EXUMBRA
SOLEM
Ciclo de
desarrollo 3
Sincronizacin
de artefactos
Anlisis
Diseo
Construccin
Prueba
94
? Una estrategia muy til consiste en limitar el ciclo de

desarrollo a un marco temporal, un lapso rgidamente fijo.
? Un caso de uso es una descripcin narrativa de un proceso

de dominio.
Casos de uso y los ciclos de desarrollo iterativos
Fijacin de un ciclo de desarrollo
? Todo el trabajo ha de concluirse en ese lapso.

? Un perodo entre dos y cuatro semanas suele ser conveniente.
? Por ejemplo: Obtener libros de una biblioteca.

? Los ciclos iterativos de desarrollo se organizan a partir de los
requerimientos del caso de uso.
? Se asigna un ciclo de desarrollo para implementar uno o ms casos
de uso o bien sus versiones simplificadas (si el caso es muy
complejo como para ser abordado en un slo ciclo).
? Para tener xito con un programa de duracin fija es

necesario escoger los requerimientos con mucho cuidado y
asignarle la seleccin al equipo de desarrollo.
Perfeccionar
el plan
Sincronizacin
de artefactos
Anlisis
Diseo
Construccin
? Los casos de uso deberan clasificarse, y los que ocupen

los niveles ms altos han de abordarse en los ciclos
iniciales de desarrollo.
Prueba
de 2 semanas a 2 meses
UTFSM
N
I
EXUMBRA
SOLEM
95
UTFSM
N
I
EXUMBRA
SOLEM
96
? Esta fase incluye la concepcin inicial, la investigacin de

alternativas, la planificacin, la especificacin de
requerimientos y otras actividades:
? Entre los artefactos generados en esta fase se pueden

mencionar los siguientes:
Fase de planificacin y elaboracin
? Plan: programa, presupuesto, etc.

? Informe preliminar de la investigacin: motivos, alternativas,
necesidades de la empresa.
? Especificacin de los requerimientos : declaracin de los
requerimientos.
? Glosario: diccionario (nombres de conceptos, pro ejemplo) y toda
la informacin afn, como las restricciones y reglas.
? Prototipo: sistema de prototipos cuyo fin es facilitar la comprensin
del problema, los problemas de alto riesgo y los requerimientos.
?Definir un plan preliminar

?Elaborar un informe preliminar de investigacin
?Definir los requerimientos
?Registrar los trminos en el glosario (constante)
?Implementar el prototipo (opcional y aplazable)
?Definir los casos de uso (de alto nivel y esenciales)
?Definir el modelo conceptual preliminar (aplazable)
?Definir la arquitectura preliminar del sistema (constante, opcional y
aplazable)
?Perfeccionar el plan.
UTFSM
N
I
EXUMBRA
SOLEM
97
UTFSM
N
I
EXUMBRA
SOLEM
98
? Entre los artefactos generados en esta fase se pueden

mencionar los siguientes:
? El orden de la creacin de artefactos no es necesariamente

lineal como puede sugerir la lista anterior.
? Casos de uso: descripciones narrativas de los procesos de dominio.
? Podemos preparar en paralelo algunos de ellos. Esto se aplica

especialmente al modelo conceptual, al glosario, a los casos de uso
y a los diagramas de los casos.
? Diagramas de casos de uso: descripcin grfica de todos los casos

de uso y sus relaciones.
? Los casos de uso son sometidos a un examen y, en

cambio, el resto de los artefactos tienen por objeto reflejar
la informacin proveniente de los casos.
? Bosquejo del modelo conceptual: modelo conceptual preliminar

cuya finalidad es facilitar el conocimiento del vocabulario del
dominio, especialmente en su relacin con los casos de uso y con
las especificaciones de los requerimientos.
UTFSM
N
I
EXUMBRA
SOLEM
99
UTFSM
N
I
EXUMBRA
SOLEM
Fase de construccin: ciclos de desarrollo
? La fase de construccin de un proyecto requiere varios

ciclos de desarrollo a lo largo de los cuales se extiende el
sistema.
Ciclo de
desarrollo 1
? El objetivo final es obtener un sistema funcional que atienda

debidamente los requerimientos.
Ciclo de
desarrollo 2
Perfeccionami
ento del plan
UTFSM
N
I
SOLEM
101
SOLEM
Anlisis
1. Definir casos
esenciales de
uso
2. Perfeccionar
el diagrama de
casos
3. Perfeccionar
el modelo
conceptual
5. Definir
diagramas de
secuencia
6. Definir los
contratos de
operaciones
7. Definir
diagramas de
estado
UTFSM
N
I
EXUMBRA
Ciclo de
desarrollo 3
Sincronizacin
de artefactos
? En un ciclo individual de desarrollo, los principales pasos se

analizan y disean, como se seala en la figura siguiente.
EXUMBRA
100
Diseo
Construccin
Prueba
4. Perfeccionar
el glosario
102
? Como en el caso de los artefactos de la fase de

requerimientos, algunos artefactos pueden ser creados en
paralelo, por ejemplo:
? El modelo conceptual es una representacin de conceptos

u objetos en el dominio del problema, como Libro y
Biblioteca.
Cuando crear el modelo conceptual
? Modelo conceptual y glosario.

? Diagramas de interaccin y diagramas de diseo de clases.
UTFSM
N
I
EXUMBRA
SOLEM
? Debe limitarse el esfuerzo aplicado a la creacin de un

modelo conceptual preliminar en la fase de planificacin y
elaboracin, ya que en los dominios de problemas amplios,
el modelo conceptual puede tornarse muy complejo.
103
UTFSM
N
I
EXUMBRA
SOLEM
104
? La estrategia recomendada es generar rpidamente un

modelo conceptual que se centre en identificar los
conceptos obvios expresados en los requerimientos y
posponer hasta ms tarde una investigacin con
detenimiento.
? Durante la fase de planificacin y elaboracin, se aconseja

crear todos los casos de uso de alto nivel, pero describir
los ms importantes en el formato expandido, posponiendo
el resto hasta el ciclo de desarrollo en que se estudian.
Cuando crear el modelo conceptual
Cuando crear los casos expandidos de uso
? Por lo tanto se recomienda estudiar detenidamente,

durante la fase de planificacin y elaboracin slo los
casos de uso ms importantes.
? Otra estrategia es suspender la creacin de un modelo

conceptual hasta el inicio de los ciclos de desarrollo, lo cual
tiene la desventaja de aplazar la complejidad.
UTFSM
N
I
EXUMBRA
SOLEM
105
UTFSM
N
I
EXUMBRA
SOLEM
? UML describe modelos de sistema basado en los conceptos

de objetos.
? El modelo global del sistema esta constituido por:
Definicin de modelos y artefactos
Modelo del sistema
? Modelo de anlisis: el que se relaciona con una

investigacin de dominio y del mbito del problema, pero
no con la solucin.
? Todos los diagramas de UML pueden ser divididos en dos

tipos.
? Un modelo esttico del sistema describe las propiedades
estructurales del sistema.
? Un modelo dinmico describe las propiedades del comportamiento
del sistema.
UTFSM
N
I
EXUMBRA
SOLEM
106
107
? Modelo de diseo: el que se relaciona con la solucin

lgica.
UTFSM
N
I
EXUMBRA
SOLEM
108
Relacin entre los artefactos
? Sin importar como los artefactos se organicen para

construir los modelos, se dan dependencias muy
importantes entre ellos.
Informe
preliminar de
investigacin
Especificacin de
requerimientos
Prototipos
Casos de uso:
a)de alto nivel todos
b) algunos esenciales
expandidos
? Por ejemplo, un diagrama de casos de uso depende de las

definiciones de los casos de uso.
? Si se crea un artefacto que no tenga otros dependientes y

si no se usa como entrada de otra cosa, habr que poner
en tela de juicio su valor y el tiempo que se dedic a su
creacin.
Diagramas de casos de
uso
Presupuesto,
programa de
actividades
Modelo conceptual
preliminar
Glosario
UTFSM
N
I
EXUMBRA
SOLEM
109
UTFSM
N
I
EXUMBRA
SOLEM
? Qu es anlisis?
? Qu es diseo?
? Cul es la diferencia entre anlisis y diseo OO?

? Porqu UML tiene tantos diagramas?
? Anlisis y diseo OO
? Uso de UML
? De qu sirve el divide y vencers en OO?

? Qu es un proceso de desarrollo?
? Introduccin al proceso de desarrollo
? Qu pasa dentro de un ciclo de desarrollo?
Resumen
UTFSM
N
I
EXUMBRA
SOLEM
Quiz
111
UTFSM
N
I
EXUMBRA
SOLEM
? Especificacin de Requerimientos
? Casos de Uso: Descripcin de Proceso
? Con esta actividad se quieren lograr los siguientes

objetivos:
Contenido
UTFSM
N
I
SOLEM
112
Especificacin de requerimientos
? Crear los artefactos de la fase de requerimientos, por ejemplo, las

especificaciones de funciones.
? Identificar y clasificar las funciones del sistema.
? Identificar y crear los atributos del sistema y relacionarlos con las
funciones.
? Clasificacin de los casos de uso

? Inicio de un ciclo de desarrollo
EXUMBRA
110
113
UTFSM
N
I
EXUMBRA
SOLEM
114
? Requerimientos son una descripcin de necesidades o

deseos para un producto.
? Declaracin general: el propsito de este proyecto es crear un sistema

de punto de venta para ser usada en locales de venta.
? Clientes : Placeres Terrenales, Ltda, vendedor multinacional de objetos
de relajacin
Captura de Requerimientos
Ejemplo: Punto de venta
?El reto consiste en definirlos de manera inequvoca, de modo que se

detecten los riesgos y no se presenten sorpresas al momento de
entregar el producto.
? Los siguientes tpicos son

desarrollados en esta fase:
?
?
?
?
?
UTFSM
N
I
EXUMBRA
SOLEM
recomendados
? Objetivos : En general, la meta es hacer ms rpido el procedimiento

de pago de productos, para apoyar en forma mejor, ms rpida y
barata los procesos de servicios y negocios. Ms especficamente esto
incluye
ser
declaracin general
clientes
objetivos
funciones del sistema
atributos del sistema
? Rpido pago y entrega de comprobante a los compradores

? Rpido y preciso anlisis de ventas
? Control del inventario automtico
115
UTFSM
N
I
EXUMBRA
SOLEM
116
? Funciones del sistema son aquellas que el sistema se

supone que tiene que hacer, tales como autorizar el pago
con las tarjetas de crdito.
? En cambio, los atributos del sistema son cualidades nofuncionales del sistema, como por ejemplo, la facilidad de
uso, que a menudo se confunden con las funciones del
sistema.
Funciones y atributos del sistema
? Estas deben ser identificadas y anotadas en grupos lgicos y

cohesivos.
? Con el objeto de verificar que algn X es de verdad una

funcin del sistema, la siguiente oracin deber tener
sentido:
? Ntese que facilidad de uso no encaja en la oracin de verificac in:

El sistema deber hacer la facilidad de uso.
? Los atributos no deben formar parte de las especificaciones
funcionales del sistema, sino de un documento independiente que
especifica sus atributos.
? El sistema deber hacer <X>.

? Por ejemplo: El sistema deber autorizar los pagos con tarjetas de
crdito.
UTFSM
N
I
EXUMBRA
SOLEM
117
UTFSM
N
I
EXUMBRA
SOLEM
118
? Las funciones deben ser clasificadas en categoras para

poder priorizarlas.
? Las siguientes funciones bsicas del sistemas en la

aplicacin del punto de venta son una muestra
significativa; no pretenden en absoluto ser exhaustivas.
? Las categoras incluyen:

? Funciones Evidentes - Debe realizarse, el usuario esta consciente
que se ha realizado.
? Funciones Ocultas - Debe realizar, pero no debe ser visible a los
usuarios.
? Funciones Superfluas - Opcionales; su agregacin no afecta
significativamente en el costo o en otras funciones.
Ref #
R1.1
R1.2
R1.5
R1.9
UTFSM
N
I
EXUMBRA
SOLEM
119
Funcin
Registrar la venta en proceso (actual): la lista de los artculos
comprados
Calcular el total de la venta actual, incluyendo impuestos y descuentos
Registrar las ventas completadas
Mostrar la descripcin y el precio del item
UTFSM
N
I
EXUMBRA
SOLEM
Categora
Evidente
Evidente
Oculta
Evidente
120
? Sera mejor agrupar funciones en un orden lgico, por

ejemplo, todas las funciones de pago.
? Los atributos del sistema son caractersticas o dimensiones

del mismo: no son funciones.
? Por ejemplo, facilidad de uso, tolerancia a fallas, plataformas,

tiempo de respuesta, etc.
Ref #
R2.1
R2.2
R2.4
Funcin
Manejar los pagos con efectivo, capturando la cantidad entregada y
entregando el monto de vuelto
Manejar los pagos con las tarjetas de crdito, capturando la
informacin de la tarjeta tanto por el lector como manualmente
Registrar los pagos con la tarjeta de crdito en el sistema de

contabilidad, para cobrarlos despus a los bancos.
UTFSM
N
I
EXUMBRA
SOLEM
Categora
Evidente
? Los atributos tienen un posible conjunto de detalles de

atributos, los cuales tienden a ser valores discretos,
confusos o simblicos, por ejemplo:
Evidente
Oculta
?Tiempo de respuesta = (psicolgicamente correcto)

?Facilidad de Uso =(???)
121
UTFSM
N
I
EXUMBRA
SOLEM
? Atributos del sistema en especificaciones de las funciones

relacionan los atributos con las funciones que son
afectados por ellos, adems de definir el atributo
obligatorio u opcional.
? Algunos atributos del sistema tambin pueden tener

restricciones de frontera del atributo, que son condiciones
obligatorias, generalmente dentro de un rango numrico
de los valores de un atributo, por ejemplo:
? Una restriccin de frontera suele ser obligatoria, pues de lo

contrario significara que no era slida.
?Tiempo de respuesta = (5 segundos cmo mximo)
Sistema Operativo
UTFSM
N
I
EXUMBRA
SOLEM
Detalle y limitacin
(restriccin de frontera) La descripcin y el
precio aparecern en menos de 5 segundos.
(detalle) Microsoft Windows 95 y NT
122
Atributo
Tiempo de respuesta
123
Ref#
R1.9
Funcin
Categ.
Atributo
Mostrar la
descripcin y el
precio del item
Evidente
Tiempo de respuesta
UTFSM
N
I
EXUMBRA
SOLEM
Detalles y
Categ.
Limitaciones
La descripcin y el
Requerido
precio aparecern en
menos de 5 segundos.
124
? Objetivos:
? La tcnica de casos de uso se puede aplicar tanto al

anlisis estructurado, como al anlisis orientado a objetos.
Casos de uso: Descripcin de procesos
? Identificar y escribir casos de uso

? Disear diagramas de casos de uso.
? Contrastar los casos de uso de alto nivel, tanto como expandidos.
? Un caso de uso es un documento narrativo que describe la

secuencia de eventos de un actor (agente externo) que
utiliza un sistema para completar un proceso.
? Contrastar los casos de uso esenciales con los reales.
? Los casos de uso son historias o casos de utilizacin de un sistema.

? No son exactamente los requerimientos ni las especificaciones
funcionales, sino que ejemplifican e incluyen tcitamente los
requerimientos en las historias que narran.
UTFSM
N
I
EXUMBRA
SOLEM
125
UTFSM
N
I
EXUMBRA
SOLEM
126
? Notacin en UML
? Un caso de uso expandido muestra ms detalles que uno

de alto nivel
Comprar productos
? este tipo de casos suelen ser tiles para alcanzar el conocimiento

ms profundo de los procesos y de los requerimientos.
? El siguiente caso de uso de alto nivel describe clara y

concisamente el proceso de comprar artculos en una
tienda cuando se emplea una terminal en el punto de
venta.
Caso de uso:
Actores:
Tipo:
Descripcin:
UTFSM
N
I
EXUMBRA
SOLEM
Caso de uso:
Actores:
Propsito:
Resumen:
Comprar productos
Cliente, Cajero
Primario
Un cliente llega a la caja registradora con los artculos que comprar.
El Cajero registra los artculos y cobra el importe. Al terminar la
operacin, el Cliente se marcha con los artculos comprados.
127
Tipo:
Referencias
Cruzadas:
UTFSM
N
I
EXUMBRA
SOLEM
Comprar productos en efectivo

Cliente (iniciador), Cajero
Capturar una venta y su pago en efectivo.
Un cliente llega a la caja registradora con los artculos que co mprar.
El Cajero registra los artculos y recibe un pago en efectivo. Al
terminar la operacin, el Cliente se marcha con los artculos
comprados.
Primario
Funciones: R1.1, R1.2, R1.3, R1.7, R2.1
Curso Normal de Eventos
Curso Normal de Eventos
Accin de los actores

1. Este caso de uso comienza cuando un
Cliente llega a una caja de TPDV (Terminal
de Punto de Ventas) con productos que
desea comprar.
2. El Cajero registra la identificacin de cada
producto.
Si hay varios productos de una misma
categora, el Cajero tambin puede introducir
la cantidad.
4. Al terminar de introducir el producto, el
Cajero indica a TPDV que se concluyo la
captura del producto.
6. El Cajero indica el total al Cliente.
UTFSM
N
I
EXUMBRA
SOLEM
7. El Cliente efecta el pago en efectivo el

efectivo ofrecido posiblemente mayor
que el total de la venta.
8. El Cajero registra la cantidad de efectivo
recibida.
10. El Cajero deposita el efectivo recibido y
extrae el cambio de pago.
El Cajero le da al Cliente el cambio y el
recibo impreso.
12. El Cliente se marcha con los artculos
comprados.
Respuesta del sistema
3. Determina el precio del producto e

incorpora a la transaccin actual la
informacin correspondiente.
Se presentan la descripcin y el precio del
producto actual.
5. Calcula y presenta el total de la venta.
129
UTFSM
N
I
EXUMBRA
SOLEM
Explicacin del formato expandido
? La seccin intermedia, curso normal de eventos, es la

parte medular del formato expandido
Caso de uso: Nombre del caso de uso

Actores:
Lista de actores (agentes externos), en la cual se indica quien inicia el
caso de uso.
Propsito:
Intencin de caso de uso
Resumen:
Repeticin del resumen de alto nivel o alguna sntesis similar.
Tipo:
1. Primario, secundario u opcional
2. Esencial o real
Referencias Casos relacionados de uso y funciones tambin relacionadas del
Cruzadas:
sistema.
? Se describe en detalles la conversacin interactiva entre los ac tores

y el sistema.
? Un aspecto esencial de la seccin es que explica la secuencia ms
comn de los eventos; no incluye situaciones alternativas.
Accin del actor

Acciones numeradas de los actores
UTFSM
SOLEM
130
N
I
9. Muestra al cliente la diferencia. Genera un

recibo.
11. Registra la venta concluida.
Cursos alternativos
? Lnea 2: introduccin del identificador invlido. Indicar error.
? Lnea 7: el cliente no tena suficiente dinero. Cancelar la transaccin de venta.
EXUMBRA
128
131
UTFSM
N
I
EXUMBRA
SOLEM

Descripciones numeradas de las respuestas
del sistema.
132
10
? La ltima seccin, curso alternativo de los eventos,

describe importantes opciones o excepciones que pueden
presentarse en relacin con el curso normal.
? El actor es una entidad externa del sistema que de alguna

manera participa en la historia del caso de uso.
Actores
? Por lo regular estimula el sistema con eventos de entrada o recibe

algo de l.
? Los actores estn representados por papel que desempean en el
caso: Cliente, Cajero, u otro.
? Si son complejas, se pueden expandir y convertirlas en otros cas os

de uso.
Cursos alternativos
Alternativas que pueden ocurrir en el nmero de lnea. Descripcin de
excepciones.
? Notacin en UML
Cajero
UTFSM
N
I
EXUMBRA
SOLEM
133
UTFSM
N
I
EXUMBRA
SOLEM
? En un caso de uso hay un actor iniciador que produce la

estimulacin inicial y, posiblemente, otros actores
participantes; tal vez convenga especificar quien es el
iniciador.
? Un error comn en la identificacin de los casos de uso

consiste en representar los pasos, las operaciones o las
transacciones individuales como casos.
Actores
Errores comunes con los casos de uso
? Por ejemplo, podemos definir (incorrectamente) un caso

denominado "imprimir recibo", cuando en realidad esta operacin
no es ms que un paso de un proceso ms amplio del caso
"comprar productos".
? Los actores suelen ser los papeles representados por las personas,
pero tambin puede ser cualquier tipo de sistema externo.
? Algunos tipos de actores:
? Un caso de uso es una descripcin de un proceso de

principio a fin relativamente amplia, descripcin que suele
abarcar muchos pasos o transacciones; normalmente no es
un paso o una actividad individual del proceso.
?Papeles que desempean las personas.

?Sistemas de computo.
?Aparatos electrnicos o mecnicos.
UTFSM
N
I
EXUMBRA
SOLEM
134
135
UTFSM
N
I
EXUMBRA
SOLEM
? Los siguientes pasos de la identificacin de los casos de

uso requieren de una lluvia de ideas y revisin exhaustiva
de los documentos actuales sobre la especificacin de
requerimientos.
? En la aplicacin de punto de venta, algunos actores

posiblemente relevantes y los procesos que inician son:
Identificacin de casos de uso
136
Identificacin de casos de uso
? Cajero
?registra
?entrega el efectivo
? Un mtodo de identificacin de los casos de uso se basa en

actores.
? Cliente
?1. Se identifican los actores relacionados con un sistema o empr esa.

?2. Para cada actor se identifican los procesos que inician o en los
cuales participan.
?compra productos
?paga productos
? Otro mtodo de identificacin de casos de uso se basa en eventos .

?1. Se identifican los eventos externos a los que un sistema ha de
responder.
?2. Se relacionan los eventos con los actores y con los casos de uso.
UTFSM
N
I
EXUMBRA
SOLEM
137
UTFSM
N
I
EXUMBRA
SOLEM
138
11
? Las funciones del sistema identificadas durante la

especificacin previa de requerimientos deben asignarse a
los casos de uso.
? Un diagrama de casos de uso explica grficamente un

conjunto de casos de uso de un sistema, los actores y la
relacin entre estos y los casos de uso.
Casos de uso, funciones del sistema y trazabilidad
Diagramas de casos de uso
? Diagrama parcial del ejemplo
? Adems, debe ser posible verificar, mediante la seccin de

referencias cruzadas, que todas las funciones hayan sido
asignadas.
Cajero
Cliente
Comprar productos
UTFSM
N
I
EXUMBRA
SOLEM
139
UTFSM
N
I
EXUMBRA
SOLEM
140
? Los casos de uso deberan clasificarse en primarios,

secundarios y opcionales para asignarles la prioridad de
desarrollo.
? Los casos esenciales de uso son casos expandidos de que

se expresan en una forma terica que contiene poca
tecnologa y pocos detalles de implementacin; las
decisiones de diseo se posponen y se abstraen de la
realidad, especialmente en lo concerniente a la interfaz
usuaria.
Clasificacin de casos de uso
? Los casos de uso primarios representan los procesos comunes ms

importantes, como Comprar productos.
? Los casos secundarios de uso representan procesos menores o
raros; por ejemplo, Solicitud de surtir un nuevo producto.
? Los casos opcionales de uso representan procesos que pueden no
abordarse.
? Retiro de efectivo es un ejemplo de caso de uso esencial.

1. El cliente se identifica.
3. ..
UTFSM
N
I
EXUMBRA
SOLEM
141
UTFSM
N
I
EXUMBRA
SOLEM

2. Presenta opciones.
4.
142
? En cambio un caso de uso real describe concretamente el

proceso a partir de su diseo concreto actual, sujeto a las
tecnologas especificas de entrada y salida, etc.
? Al caso de uso se le asigna un nombre que comience con

un verbo para subrayar que se trata de un proceso. Por
ejemplo, Comprar productos, Introducir pedidos.
Sobre la notacin
? Cuando se trata de la interfaz usuaria a menudo ofrece

presentaciones de pantalla y explica la interaccin con los
artefactos.
? Comience un caso de uso expandido con la siguiente

oracin:
1. Este caso de uso comienza cuando <Actor> <inicia un evento>

1. El cliente introduce su tarjeta.
3. Introduce la clave con un teclado
numrico.
5.
UTFSM
N
I
EXUMBRA
SOLEM

2. Pide la clave personal (CP).
4. Muestra men de opciones.
? De este modo se estimula una identificacin clara del

actor y del evento iniciadores.
6.
143
UTFSM
N
I
EXUMBRA
SOLEM
144
12
? Un caso de uso puede contener puntos de decisin.
? Pero en ocasiones el punto de decisin representa

opciones cuya probabilidad es relativamente igual y
normal; en este caso se utiliza la siguiente estructura
notacional:
Sobre la notacin
Sobre la notacin
? Por ejemplo, en Comprar productos, el cliente puede optar al pago

en efectivo, a crdito o con cheque al momento de pago.
? Si una de estas trayectorias es un caso significativo y si las

otras alternativas son raras, inusuales o excepcionales, el
caso tpico deber ser el nico acerca del cual se escribe el
curso normal de eventos y las opciones han de escribirse
en la seccin titulada Alternativas.
UTFSM
N
I
EXUMBRA
SOLEM
145
1. En la seccin curso normal de eventos, indique las ramas de las

subsecciones .
2. Escriba una subseccin en cada rama, utilizando otra vez el curso
normal de eventos. Inicie el evento numerando en 1 en cada
seccin.
3. Si las subsecciones tienen opciones, escrbalas en una seccin de
alternativas de cada subseccin.
UTFSM
N
I
EXUMBRA
SOLEM
Puntos de decisin
Puntos de decisin
Ejemplo de Punto de Ventas
6. El cliente escoge el tipo de pago

a. Si paga en efectivo, consltese la seccin
de Pago en efectivo.
b. Si paga a crdito, consltese la seccin
Pago con tarjeta de crdito.
c. Si paga con cheque, consltese la
seccin Pago con cheque.
Seccin: principal.
Curso normal de eventos
Cliente llega a una caja de TPDV (Terminal
de Punto de Ventas) con productos que
desea comprar.
2. El Cajero registra la identificacin de cada 3. Determina el precio del producto e
producto.
Si hay varios productos de una misma
categora, el Cajero tambin puede introducir Se presentan la descripcin y el precio del
la cantidad.
producto actual.
4. Al terminar de introducir el producto, el 5. Calcula y presenta el total de la venta.
Cajero indica a TPDV que se concluy la
UTFSM
N
I
EXUMBRA
SOLEM
146
147
7. Registra la venta terminada

8. Imprime un recibo.
9. El Cajero le entrega al Cliente el recibo
impreso.
comprados.
Cursos alternativos
UTFSM
N
I
EXUMBRA
SOLEM
148
Pasos de especificacin de casos de uso
Puntos de decisin
Seccin: Pago en efectivo

Curso normal de eventos
Accin del actor
1. El Cliente efecta el pago en efectivo el
3. Muestra al cliente la diferencia.
recibida.
4. El Cajero deposita el efectivo recibido y
extrae el cambio de pago.
El Cajero le da al Cliente el cambio.
1. Despus de haber listado las funciones del sistema, identifique los

actores y los casos de uso.
2. Escriba todos los casos de uso de alto nivel. Clasifquelos en primarios,
secundarios u opcionales.
3. Dibuje un diagrama de caso de uso.
4. Escriba en el formato esencial expandido los casos de uso ms
importantes, influyentes y riesgosos, a fin de entender y estimar mejor
la naturaleza y las dimensiones del problema. Para evitar casos
complejos posponga la escritura de la forma esencial expandida de los
casos de uso menos importantes hasta los ciclos de desarrollo futuros.
Cursos alternativos
? Lnea 7: el cliente no tena suficiente dinero. Cancelar la tran saccin de venta.
Seccin: Pago con tarjeta de crdito
Cursos normales y alternativos de la historia de pago con la tarjeta de crdito.
Seccin: Pago con cheque
Cursos normales y alternativos de la historia de pago cheque.
UTFSM
N
I
EXUMBRA
SOLEM
149
UTFSM
N
I
EXUMBRA
SOLEM
150
13
5. En teora, los casos reales deberan posponerse hasta una fas e de

diseo en el ciclo de desarrollo, porque su creacin conlleva muchas
decisiones de diseo. Pese a ello, a veces es necesario crear casos
reales de uso durante la etapa inicial de los requerimientos en el caso
de que las descripciones concretas facilitan notablemente la
comprensin; los clientes exigen especificar los procesos de este
forma.
6. Clasifique los casos de uso.
? Suponiendo que todos los artefactos deseados hayan sido

generados (por ejemplo, la especificacin de los
requerimientos y los casos de uso), el siguiente paso es
iniciar la fase de construccin en el ciclo de desarrollo
iterativo y comenzar a implementar el sistema.
Pasos de especificacin de casos de uso
UTFSM
N
I
EXUMBRA
SOLEM
Clasificacin y programacin de los casos de uso
151
? En un ciclo de desarrollo iterativo, la tarea de llenar los

casos de uso se distribuye entre varios ciclos.
UTFSM
N
I
EXUMBRA
SOLEM
152
? Especificacin de Requerimientos
? Casos de Uso: Descripcin de Proceso
? Qu son los requerimientos?

? Qu relacin tienen los requerimientos con las funciones y
los atributos del sistema?
Resumen
Quiz
? Clasificacin de los casos de uso

? Inicio de un ciclo de desarrollo
? Porqu las funciones se organizan en orden lgico?

? Para qu definir la relacin entre atributos y funciones?
? Qu es un caso de uso?
? Qu representa un diagrama de casos de uso?
? Qu relacin tienen los casos de uso con las funciones del
sistema?
UTFSM
N
I
EXUMBRA
SOLEM
153
UTFSM
N
I
EXUMBRA
SOLEM
? Interprete el siguiente diagrama de casos de uso.
? Dependencia de los artefactos

? Tcnicas de clasificacin de casos de uso
Quiz
<<se comunica con>>
Estudiante
Contenido
? Formato extendido de los casos de uso

? Anlisis Orientado a Objetos
seleccionar cursos a impartir
registrarse en cursos
Profesor
? Modelo conceptual
? Formas de determinar conceptos
<<usa>>
crear lista de cursos
154
<<usa>>
Valida usuario
S. Facturacin
mantener infprofesor
mantener infestudiante
mantener infcurso
UTFSM
N
I
EXUMBRA
SOLEM
crear catalogo curso

Fundamentos de Ingeniera
Secretariode SW
155
UTFSM
N
I
EXUMBRA
SOLEM
156
14
? La estrategia general consiste en escoger primero los

casos que influyen profundamente en la arquitectura
bsica. Las cualidades de un caso de uso as son los
siguientes:
? Un sistema simple y poco riguroso puede servir para

realizar la clasificacin: alto-mediano-bajo.
? Otro sistema es asignar un puntaje y sumar (posiblemente
con ponderacin) para obtener una calificacin.
? Tener una fuerte repercusin en el diseo arquitectnico; por

ejemplo, incorporar muchas clases a la capa del dominio o requerir
servicios de persistencia.
? Con relativamente poco esfuerzo obtener informacin e ideas
importantes sobre el diseo.
? Incluir funciones riesgosas, urgentes o complejas.
? Requerir una investigacin a fondo o tecnologa nueva o riesgosa.
? Representar los procesos primarios de la lnea de negocios.
? Apoyar directamente el aumento de ingresos o la reduccin de
costos.
UTFSM
N
I
EXUMBRA
SOLEM
157
Caso de uso
a b
Comprar productos 5 3
Y as sucesivamente
UTFSM
N
I
EXUMBRA
SOLEM
c d
2 0
e
5
f Suma
3
18
158
? Con base a los criterios expuestos anteriormente, he aqu

un ejemplo de clasificacin de algunos casos de uso en la
aplicacin de punto de venta.
? Prcticamente todos los sistemas cuentan con un caso de

arranque o inicio.
Clasificacin
Alto
Caso de uso
Comprar productos
Mediano
Incorpora usuarios
Registra los productos comprados
Paga los productos comprados
Pagar
Iniciar
Cerrar
Bajo
UTFSM
N
I
EXUMBRA
SOLEM
? Aunque este no ocupe un nivel alto conforme a otros criterios, es

preciso estudiar al menos una versin simplificada de l al
comienzo del ciclo de desarrollo para presentar la inicializacin
supuesta en otros casos.
Justificacin
Corresponde a los criterios de calificacin ms
altos.
Afecta el subdominio de seguridad.
Afecta el subdominio de seguridad.
Proceso importante, afecta a contabilidad.
Efecto mnimo en la arquitectura.
La definicin depende de los otros casos de uso.
Efecto mnimo en la arquitectura
159
UTFSM
N
I
EXUMBRA
SOLEM
160
? A partir de la clasificacin, el Caso de uso Comprar

productos debera incluirse en el primer ciclo de desarrollo,
tambin puede abordarse una versin simple de Inicio
para soportar los otros casos de uso.
? En esta situacin, el caso de uso se redefine, como por

ejemplo:
? Comprar productos versin 1 (pagos en efectivo, sin

actualizaciones de inventario, )
? Comprar productos versin 2 (permitir cualquier tipo de pago)
? Comprar productos versin 3 (completa, con actualizaciones del
inventario, etc.)
? Siempre que se asigne un caso de uso, es necesario

estimar si es posible resolverlo ntegramente en el lapso
limitado de un ciclo (cuatro semanas, por ejemplo) o si el
trabajo ha de ser distribuido en varios ciclos.
UTFSM
N
I
EXUMBRA
SOLEM
161
? Las versiones anteriores se distribuyen despus a lo largo

de una serie de ciclos de desarrollo junto con otros casos
de uso.
UTFSM
N
I
EXUMBRA
SOLEM
162
15
? Si nos basamos en la clasificacin de los casos y de varias

versiones de Comprar productos, podramos asignar
algunos ciclos al ciclo de desarrollo:
? Una vez que se ha decidido simplificar los casos de uso y

expresarlo, hay que escribir versiones cada vez ms
complejas.
? Ciclo de desarrollo 1: Comprar productos versin 1,

? Ciclo de desarrollo 4: Registrar productos comprados, , Pagar los
productos comprados,
? Tambin hay que especificar las simplificaciones, las metas

y las suposiciones de cada versin.
Asignacin de casos de uso a ciclos de desarrollo
UTFSM
N
I
EXUMBRA
SOLEM
163
Versiones de caso de uso Comprar Productos
UTFSM
N
I
EXUMBRA
SOLEM
? Simplificaciones, metas y suposiciones
Versin 1 de Comprar Productos
? Pagos en efectivo exclusivamente

? Sin mantenimiento de inventario
? Es una tienda independiente, que no forma parte de ninguna
organizacin ms grande.
? Captura manual del cdigo universal de producto (CUP); sin lector
de cdigo de barras.
? No se calculan los impuestos.
? Sin cupones de descuento.
? El cajero no tiene que registrar las ventas; no se controla el
acceso.
? No se lleva un registro de los clientes individuales ni de sus hbitos
de compra.
UTFSM
N
I
EXUMBRA
SOLEM
165
Tipo:
Referencias
Cruzadas:
UTFSM
N
I
EXUMBRA
SOLEM
? No se controla la caja de efectivo.

? En el recibo aparecen el nombre y la direccin de la tienda, la
fecha y la hora de la venta.
? Ni la identificacin del cajero, ni la de TPDV aparecen en el recibo.
? Las ventas se registran en un documento histrico.
UTFSM
N
I
EXUMBRA
SOLEM
166
Curso normal de eventos:

Cliente llega a una caja de TPDV con
productos que desea comprar.
2. El Cajero registra el cdigo universal de
producto (CUP) en cada producto.
Si un producto se repite, el Cajero tambin
puede introducir la cantidad.
Presenta la descripcin y el precio del
producto en cuestin.
4. Al terminar de introducir el producto, el
5. Calcula y presenta el total de la venta.
Cajero indica a TPDV que se concluy la
6. El Cajero indica el total al Cliente.
Comprar productos, versin 1

Un Cliente llega a la caja registradora con los artculos que co mprar.
El Cajero registra los artculos y recibe una pago en efectivo. Al
comprados.
Primario
Funciones: R1.1, R1.2, R1.3, R1.7, R2.1

Caso de uso:
Actores:
Propsito:
Resumen:
164
167
UTFSM
N
I
EXUMBRA
SOLEM
168
16

7. El Cliente da un pago en efectivo el
recibida.
10. El Cajero deposita el efectivo recibido
y extrae la diferencia.
El Cajero le entrega al Cliente el cambio y
el recibo impreso.
comprados.
Comprar Productos: versin 2

? Las simplificaciones de la versin 1 se aplican tambin en esta
versin salvo que el pago puede efectuarse en efectivo, con tarjeta
de crdito o con cheque. Las dos ltimas formas de pago requieren
autorizacin.
6. Muestra al cliente la diferencia.

Genera un recibo.
11. Registra la venta concluida.
Caso de uso:
Actores:
Propsito:
Resumen:
Cursos alternativos
? Lnea 7: el cliente no tena suficiente dinero. Cancelar la tran saccin de venta.
UTFSM
N
I
EXUMBRA
SOLEM
169

Capturar una venta y su pago.
El Cajero registra los artculos y recibe un pago, que puede req uerir
una autorizacin. Al terminar la operacin, el Cliente se marcha con
los artculos comprados.
UTFSM
N
I
EXUMBRA
SOLEM
170
Anlisis Orientado a Objetos
? Suponga que la fase de planificacin y elaboracin ha

concluido y que los casos de uso han sido identificados,
clasificados y programados, por lo menos en los primeros
dos ciclos.
? Las actividades iniciales del ciclo se relacionan con la

administracin del proyecto.
Inicio de un ciclo de desarrollo
Inicio de un ciclo de desarrollo
? En el caso general, viene despus (o, ms probablemente, ocurre

en paralelo) una sincronizacin de la documentacin a partir del
ltimo ciclo con el estado real del cdigo, porque los artefactos de
diseo y los cdigos difieren invariablemente durante la fase de
codificacin del ltimo ciclo.
? Se presenta, entonces, una transicin muy importante:

comienza la fase de construccin en la cual se cumplen los
ciclos de desarrollo iterativo.
UTFSM
N
I
EXUMBRA
SOLEM
171
Sincronizacin
de artefactos
Anlisis
Diseo
UTFSM
N
I
EXUMBRA
SOLEM
Artefactos
Construccin
Casos de uso:
esenciales
expandidos
Prueba
Diagramas de
casos de uso
1. Definir los
casos
esenciales
2. Perfeccionar
el diagrama de
casos
3. Perfeccionar
el modelo
conceptual
5. Definir
diagramas de
secuencia
6. Definir los
contratos de
operaciones
7. Definir
diagramas de
estado
4. Perfeccionar
el glosario
Glosario
Diagramas de
secuencia del
sistema
Diagramas de
estado
N
I
EXUMBRA
SOLEM
Casos de uso
reales
Ventanas y
reportes
Diagramas de
interaccin
Mtodos
Diagramas de
clase de
diseo
Definicione
s de clase y
de interfaz
Casos de
prueba
Modelo
conceptual
Contratos de
operacin
UTFSM
172
Actividades
Perfeccionamie
nto del plan
? Entonces empieza la fase de anlisis, en la cual se

investiga a fondo los problemas del ciclo actual. En esta
fase, una de las actividades consiste en desarrollar el
modelo conceptual.
173
UTFSM
N
I
EXUMBRA
SOLEM
Diagrama de
paquete de
arquitectura
Esquema de
base de
datos
dependencia respecto a
SQL
174
17
? Un modelo conceptual explica (a sus creadores) los

conceptos significativos en un dominio del problema, es el
artefacto ms importante a crear durante el anlisis
orientado a objetos
? Identificar muchos objetos o conceptos constituye la

esencia del anlisis orientado a los objetos, y el esfuerzo
se compensa con los resultados conseguidos durante la
fase de diseo e implementacin.
Construccin de un modelo conceptual
Construccin de un modelo conceptual
? los casos de uso son artefactos importantes pero no son realment e

orientados a objetos
UTFSM
N
I
EXUMBRA
SOLEM
175
? Una cualidad esencial que debe ofrecer un modelo

conceptual es que representa cosas del mundo real, no
componentes del software.
UTFSM
N
I
EXUMBRA
SOLEM
176
? Los modelos conceptuales se representan en UML con un

grupo de diagramas de estructura esttica donde no se
define ninguna operacin.
? El modelo conceptual puede mostrarnos:
? En trminos informales el concepto es una idea, cosa u

objeto. En un lenguaje ms formal podemos considerarlo a
partir de su smbolo, intensin y extensin:
Fundamentos
Fundamentos
? Smbolo: palabras o imgenes que representan un concepto.

? Intensin: la definicin de un concepto.
? Extensin: el conjunto de ejemplos a que se aplica el concepto.
? conceptos
? asociaciones entre ellos
? atributos de conceptos
? Concepto del evento de una transaccin de compra
? Por ello los artefactos de software, como una ventana o

una base de datos, no forman parte del modelo
conceptual, salvo que el dominio a modelar se refiera a
conceptos de software; por ejemplo, un modelo de
interfaces grficas.
UTFSM
N
I
EXUMBRA
SOLEM
177
? Podemos optar por designarlo con el smbolo Venta.

? La intensin de Venta puede afirmar que representa el evento de
una transaccin de compra y tiene fecha y hora.
? La extensin de Venta son todos los ejemplos de venta; en otras
palabras, el conjunto de todas las ventas.
UTFSM
N
I
EXUMBRA
SOLEM
178
? Modelos conceptuales y la descomposicin
? Por ejemplo, en el dominio del problema real en una tienda

con un terminal de punto de venta intervienen los
conceptos de:
Fundamentos
Fundamentos
? Los problemas de software a veces son complejos; la

descomposicin divide y vencers es una estrategia que suele
utilizarse para resolver el problema de complejidad dividiendo e
l
espacio del problema en unidades comprensibles.
? Tienda
? TPDV
? Venta
? Por tanto, la tarea primordial de anlisis consiste en identificar los

conceptos en el dominio del problema y documentar los resultados
en un modelo conceptual.
UTFSM
N
I
EXUMBRA
SOLEM
179
? Por tanto,
conceptos.
UTFSM
N
I
EXUMBRA
SOLEM
el
modelo
conceptual
debe
incluir
estos
180
18
Estrategias para identificar conceptos: Lista de categoras
Estrategias para identificar los conceptos

? Objetivo: crear un modelo conceptual
representativos del dominio del problema.
? Directrices bsicas:
de
objetos
? La creacin del modelo conceptual a partir de una lista de

categoras se comienza preparando una lista de conceptos
idneos a partir de la siguiente lista. Contiene muchas
categoras comunes que vale la pena tener en cuenta, sin
que importe el orden de importancia.
? Categoras:
? Es mejor exagerar y especificar un modelo conceptual con muchos

conceptos refinados que no especificarlo cabalmente.
?Es frecuente omitir conceptos durante la fase inicial de identificacin y
descubrirlos ms tarde cuando se examinen los atributos o
asociaciones o durante la fase de diseo. Cuando se detecten, habr
que incorporarlos al modelo conceptual.
? objetos fsicos o tangibles

?TPDV
? Un concepto no debe ser excluido simplemente porque los

requerimientos no indican una necesidad evidente que permita
recordar la informacin acerca de ella (criterio comn para disear
los bases de datos), o porque el concepto carezca de atributos.
UTFSM
N
I
EXUMBRA
SOLEM
181
?Avin
? especificaciones, diseo o descripciones de cosas

?Especificacin De Producto
?Descripcin De Vuelo
UTFSM
N
I
EXUMBRA
SOLEM
? Categoras:
? Categoras:
? otros sistemas de computo o electromecnicas externos al sistema
? lugares
?Sistema De Autorizacin De Tarjeta De Crdito

?Control De Trafico Areo
?Tienda
?Aeropuerto
? conceptos de nombres abstractos
? transacciones
?Hambre
?Acrofobia
?Venta, Pago
?Reservacin
? organizaciones
? lnea o rengln de elemento de transacciones
?Departamento De Ventas
?Objeto Lnea Area
?Ventas Lnea De Producto
? papel de personas
? eventos
?Venta, Robo, Junta

?Vuelo, Accidente, Aterrizaje
?Cajero
?Piloto
? procesos (a menudo no estn representados como conceptos, pero

pueden estarlo)
? contenedores de otras cosas

?Tienda, Cesto
?Avin
UTFSM
N
I
EXUMBRA
SOLEM
182
?Venta De Producto
?Reservacin Asiento
183
UTFSM
N
I
EXUMBRA
SOLEM
184
? Categoras:
? Otra tcnica muy til (por su simplicidad) consiste en

identificar las frases nominales (sustantivos) en las
descripciones textuales del dominio de un problema y
considerarlas conceptos o atributos idneos.
Obtencin de conceptos a partir de frases nominales
? reglas y polticas
?Poltica De Reembolso
?Poltica De Cancelaciones
? catlogos
?Catalogo De Producto
?Catalogo De Partes
? Este mtodo hay que usarlo con prudencia, ya que no es

posible encontrar mecnicamente correspondencias entre
sustantivo y concepto, y adems las palabras del lenguaje
natural son ambiguas.
? Pese a ello esta tcnica es muy til cuando se empieza a
entender el enfoque de orientacin a objetos.
? Registro de finanzas, de trabajo, de contratos, de asuntos legales

?Recibo, Contrato De Empleo
?Bitcora De Mantenimiento
? instrumentos y servicios financieros

?Lnea De Crdito
?Existencia
? manuales, libros
?Manual De Personal
?Manual De Reparaciones
UTFSM
N
I
EXUMBRA
SOLEM
185
UTFSM
N
I
EXUMBRA
SOLEM
186
19

Cliente llega a una caja de
TPDV con
2. El Cajero registra el cdigo universal
de producto (CUP) en cada producto .
Si un producto se repite, el
Cajero
tambin puede introducir la cantidad.
UTFSM
N
I
EXUMBRA
SOLEM
? Algunas de las frases marcadas son conceptos idneos,

algunas pueden ser atributos de conceptos. El consejo es
combinar este mtodo con la lista de categoras.

incorpora a la
transaccinactual la
Presenta la descripcin y el precio del
producto en cuestin.
187
UTFSM
N
I
EXUMBRA
SOLEM
? Dependencia de los artefactos

? Tcnicas de clasificacin de casos de uso
? Porqu se clasifican los casos de uso?

? Qu es un caso de uso inicio?
? Formato extendido de los casos de uso

? Anlisis Orientado a Objetos
? Porqu es necesario simplificar un caso de uso?

? Qu significara que un artefacto no dependa de otros?
Resumen
Resumen
? Modelo conceptual
? Formas de determinar conceptos
UTFSM
N
I
EXUMBRA
SOLEM
188
? Qu representa el modelo conceptual y cmo se obtiene?
189
UTFSM
N
I
EXUMBRA
SOLEM
? Identificacin de conceptos
? En el caso de punto de venta, los conceptos identificados

son los siguientes:
Contenido
190
Ejemplo: Obtencin de conceptos
? Ejemplo
? TPDV, Producto, Tienda, Venta, Pago

? Catalogo De Productos, Especificacin De Producto
? Ventas Lnea De Productos
? Cajero, Cliente, Gerente
? Principio del cartgrafo

? Asociaciones de conceptos
? Identificacin de atributos
? Construccin del modelo conceptual
? Se debe o no incluir el recibo?
UTFSM
N
I
EXUMBRA
SOLEM
191
UTFSM
N
I
EXUMBRA
SOLEM
192
20
? El recibo es un registro de venta y de un pago, as como el

concepto relativamente prominente en el dominio de
ventas: debe entonces, mostrarse en el modelo?
? Aplique los siguientes pasos para construir un modelo

conceptual:
Obtencin de conceptos
Directrices para construir modelos conceptuales
? Liste los conceptos idneos usando la lista de categora de

conceptos y la identificacin de frases nominales relacionadas con
los requerimientos en cuestin.
? Dibjelos en el modelo conceptual.
? Incorpore las asociaciones necesarias para registrar las relaciones
entre los conceptos.
? Agregue los atributos necesarios para cumplir con las necesidades
de la informacin.
? El recibo es un informe de venta, toda su informacin proviene de

otra parte. Este es un buen motivo para excluirlo.
? El recibo cumple un papel esencial respecto a las reglas de la
empresa: el portador le confiere el derecho de devolver los
productos adquiridos. Esta es la razn para incluirlo en el modelo.
? El recibo se excluir por el momento, porque las

devoluciones de productos no estn incorporados en este
ciclo de desarrollo.
UTFSM
N
I
EXUMBRA
SOLEM
193
UTFSM
N
I
EXUMBRA
SOLEM
194
? La estrategia del cartgrafo se aplica a los mapas y a los

modelos conceptuales:
? Los cartgrafos se sirven de los nombres del territorio no cambian

los nombres de ciudades en sus mapas. En el caso de un modelo
conceptual ello significa utilizar el vocabulario del dominio cuando se
asignan nombres a los conceptos y a los atributos.
Directrices: El cartgrafo
Directrices: El cartgrafo
? Utilice los nombres existentes en el dominio.

? Excluya las caractersticas irrelevantes.
? No agregue cosas que no existan.
? Un cartgrafo elimina cosas en el mapa en caso de que no las juzgue

pertinentes para el propsito: por ejemplo, excluir la informacin sobre
la poblacin. De modo similar, un modelo conceptual puede excluir los
conceptos que no estn relacionados directamente con los
requerimientos.
? Un cartgrafo no muestra cosas en el mapa que no existan. En forma
parecida, el modelo conceptual no debe mostrar las cosas que no se
encuentren en el dominio del problema en cuestin.
UTFSM
N
I
EXUMBRA
SOLEM
195
UTFSM
N
I
EXUMBRA
SOLEM
196
? Tal vez, el error ms frecuente cuando se crea el modelo

conceptual es el de representar algo como atributo,
cuando debi haber sido un concepto.
? Es necesario identificar las asociaciones de los conceptos

que se requieren para satisfacer los requerimientos de
informacin de los casos de uso en cuestin y los que
contribuyen a entender el modelo conceptual.
Un error frecuente al identificar conceptos
Agregacin de las Asociaciones
? Una regla prctica de no caer en l:
? La asociacin es una relacin entre dos conceptos que

indica alguna conexin significativa entre ellos.
? Si en el mundo real no consideramos algn concepto X como

nmero o texto, probablemente X sea un concepto y no un
atributo.
? En el lenguaje UML se describen como relaciones

estructurales entre los objetos de diferentes tipos.
?Por ejemplo, en el dominio de reservaciones en lneas areas:

debera el aeropueto de destino ser atributo de vuelo o un concepto
aparte? En el mundo real, un aeropuerto de destino no se considera ni
nmero, ni texto, es una cosa que ocupa espacio. Por tanto,
Aeropuerto debera ser un concepto.
? En caso de duda, convierta un atributo en un concepto.

UTFSM
N
I
EXUMBRA
SOLEM
197
UTFSM
N
I
EXUMBRA
SOLEM
198
21
? Las asociaciones que vale la pena mencionar suelen incluir

el conocimiento de una relacin que ha de preservarse
durante algn tiempo: puede tratarse de milisegundos o
aos segn el contexto.
? Examine la conveniencia de incluir

asociaciones en un modelo conceptual:
Agregacin de Asociaciones : Criterios
TPDV
Agregacin de las Asociaciones : Criterios
Registra
siguientes
? Las asociaciones en que el conocimiento de la relacin ha de ser

preservado durante algn tiempo (asociaciones que deben
conocerse)
? Las asociaciones provenientes de la lista de asociaciones comunes.
?Por ejemplo, las instancias de VentaLineaDeProducto deben ir
asociadas a la instancia Venta, sin esto sera imposible imprimi r un
recibo, calcular el total, etc.
?En cambio, no necesitamos una relacin entre Gerente y Venta.
Venta actual
1
las
Asociacin
UTFSM
N
I
EXUMBRA
SOLEM
199
UTFSM
N
I
EXUMBRA
SOLEM
200
? Una asociacin se representa como una lnea entre los

conceptos con el nombre de la asociacin.
? Comience agregar las asociaciones utilizando la lista de

anexa.
Identificacin de asociaciones: lista de asociaciones

comunes
Agregacin de las Asociaciones: Notacin
? Esta es intrnsecamente bidireccional: es un nexo entre objetos.

? Los extremos de una asociacin pueden contener una expresin de
multiplicidad que indique la relacin numrica entre las instancias o
conceptos, que se llaman papeles.
? Categoras comunes que normalmente vale la pena incluir.

Categora
A es una parte fsica de B
A es una parte lgica de B
UTFSM
N
I
EXUMBRA
SOLEM
201
A es un elemento de lnea en una

transaccin o reporte B
A se conoce/ introduce/ registra/ presenta/
captura en B
A es miembro de B
A es una subunidad organizacional de B
A usa o dirige a B
A se comunica con B
UTFSM
N
I
EXUMBRA
SOLEM
contenido en B
UTFSM
N
I
EXUMBRA
SOLEM
202
Identificacin de las asociaciones: lista de asociaciones

comunes
DescripcionDeProducto Producto
DescripcionDeVuelo - Vuelo
VentasLineaDeProducto -Venta
TrabajoDeManteniemiento-Mantenimiento
Venta TPDV
Reservacion - ListaDePasajeros
Cajero Tienda
Piloto Avion
Departamento Tienda
Mantenimiento - LineaAerea
Cajero TPDV
Piloto Avion
Cliente Cajero
AgenteDeReservaciones -Pasajero
contenido en B
A est lgicamente
Identificacin de asociaciones: lista de asociaciones

comunes
A es una descripcin de B
A est fsicamente
Ejemplos
Caja-TPDV
Ala-Avin
TramoDeVuelo -RutaDeVuelo
TPDV-Tienda Producto -Estante
Pasajero - Avin
DescripcionDeProducto Catlogo
Vuelo - ProgramaDeVuelo
Pago Boleta
Pasajero Boleto
A es una transaccin relacionada con otra Pago Venta
transaccin B
Reservacion Cancelacion
TPDV TPDV
A est contiguo a B
Cuidad Cuidad
TPDV Tienda
A es propiedad de B
Avion LineaAerea
A se relaciona con una transaccin B
203
UTFSM
N
I
EXUMBRA
SOLEM
204
22
? Las categoras de alta prioridad que siempre vale la pena

incluir son las siguientes:
? Concentrarse en las asociaciones en que el conocimiento

de la relacin ha de preservarse durante algn tiempo
(asociaciones que es necesario conocer).
Identificacin de las asociaciones: lista de asociaciones

comunes
Directrices de las asociaciones
? A es una parte fsica o lgica de B

? A est fsicamente o lgicamente contenido en B
? A est registrado en B
? 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.
? Las asociaciones son importantes, pero la falla habitual al

crear los modelos conceptuales es el excesivo tiempo que
se dedica al intento de descubrirlas.
? No incluir las asociaciones redundantes, ni las derivables.
? Es mucho ms importante identificar conceptos que asociaciones.

El tiempo consagrado a la creacin del modelo conceptual debera
destinarse a identificar los conceptos, no las asociaciones.
UTFSM
N
I
EXUMBRA
SOLEM
205
UTFSM
N
I
EXUMBRA
SOLEM
? La multiplicidad define cuntas instancias de tipo A pueden

asociarse a una instancia del tipo B en determinado
momento.
? Algunos ejemplos de multiplicidad:
Multiplicidad
Tienda
Multiplicidad
*
cero o ms, muchos
1..* uno o ms
3,5,8 exactamente 3, 5 u 8
Almacena
? Por ejemplo, asociacin Trabaja-Para entre Persona y Compaa

tendr diferencias en la multiplicidad dependiendo para quien se
esta haciendo el sistema: departamento de impuestos (1..*)o
sindicato de trabajadores (1..1).
Multiplicidad del papel
UTFSM
N
I
EXUMBRA
SOLEM
1..40 de uno a 40
5
exactamente 5
? En UML, el valor de multiplicidad depende del contexto, no

hay soluciones prefabricadas.
Producto
1
206
207
UTFSM
N
I
EXUMBRA
SOLEM
208
Notacin
Notacin
? Se asigna un nombre a una asociacin basndose en el

formato NombreDeTipo-FraseNominal-NombreDeTipo,
Tienda
1
? donde la frase nominal genera una secuencia que es legible y

significativa dentro del contexto del modelo.
? Los nombres de las asociaciones comienzan con una mayscula.
? Una frase nominal (verbo) debe construirse con guiones.
? La direccin de lectura es de izquierda a derecha y de arriba hacia
abajo.
Contiene
1..*
TPDV
Captura
Asignada-a
1..*
Venta
Pagada-por
Pago
Linea Aerea
1
Emplea
1..*
Persona
1
UTFSM
N
I
EXUMBRA
SOLEM
209
UTFSMSupervisa
N
I
EXUMBRA
SOLEM
Vuelo
Asignado-a
Avin
210
23
? Dos conceptos pueden tener varias asociaciones entre

ellos; sucede con frecuencia.
? Durante la fase de anlisis, una asociacin no es una

proposicin sobre flujos de datos, variables de instancia, ni
conexiones de objetos en una solucin de software; es una
proposicin de que una relacin es significativa en un
sentido puramente analtico: en el mundo real.
Asociaciones mltiples entre dos conceptos
Asociaciones y su implementacin
? Por ejemplo, en el dominio de la lnea area encontramos varias

relaciones entre Vuelo y Aeropuerto.
? Las asociaciones volar-hacia y volar-de son netamente diferentes
que deben mostrarse por separado.
? Adivirtase asimismo que no se garantiza que todos los vuelos
aterricen en un aeropuerto.
*
Vuela-de
UTFSM
SOLEM
Vuela-hacia
0..1
211
UTFSM
N
I
EXUMBRA
SOLEM
? Deberamos 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 percepcin del dominio del
problema.
? Conceptos:
? Relaciones inolvidables en la Tienda
Asociaciones del dominio del punto de venta
UTFSM
N
I
SOLEM
TPDV captura Venta

Venta pagada en efectivo
CatalogoDeProductos registra
EspecificacionDeProducto
213
UTFSM
N
I
EXUMBRA
SOLEM
A est contenido lgicamente en B

A es una descripcin de B
A es un elemento de lnea en una
transaccin o reporte B
UTFSM
N
I
EXUMBRA
SOLEM
A se conoce/ introduce/ registra/ presenta/

captura en B
A es miembro de B
A es una subunidad organizacional de B
Sistema TPDV
no se aplica
TPDV-Tienda
Producto-Tienda
EspecificacionDeProducto
CatalogodeProductos
CatalogodeProductos -Tienda
EspecificacionDeProducto Producto
A usa o dirige a B
A se comunica con B
A se relaciona con una transaccin B
A es una transaccin relacionada con otra
transaccin B
A est contiguo a B
A es propiedad de B
214
? Recorreremos la lista de comprobacin, basndonos en

tipos anteriormente identificados y teniendo presentes los
requerimientos actuales del caso de uso.
A est contenido fsicamente en B
Para conocer la venta actual genera un total e

imprime un recibo.
Para saber si se pag la venta, relaciona la
cantidad ofrecida con el total de la venta e
imprime un recibo.
Para recuperar la especificacin de producto con
un cdigo universal de producto
Categora
A es una parte fsica de B
A es una parte lgica de B
212
? TPDV, Producto, Tienda, Venta, Pago

? Catalogo De Producto, Especificacin De Producto
? Ventas Lnea De Productos
? Cajero, Cliente, Gerente
EXUMBRA
ser
Aeropuerto
*
N
I
debe
Vuelo
EXUMBRA
? Una asociacin no necesariamente

implementada durante la construccin
215
UTFSM
N
I
EXUMBRA
SOLEM
Venta (terminada) Tienda

Venta (actual) TPDV
Cajero Tienda
no aplicable
Cajero TPDV
Gerente TPDV
Gerente Cajero, probablemente no
aplicable
Cliente Cajero
Cliente Pago
Cajero Pago
Pago Venta
TPDV TPDV, probablemente no aplicable
TPDV Tienda
216
24
Modelo Conceptual del punto de venta
Descrita-por
EspecificaciondeProducto
Contiene
1
1..*
Describe
VentasLineaDeProducto
0..1
1..*
*
Producto
Contenidas-en
Capturas-Terminada
N
I
EXUMBRA
SOLEM
? TPDV Usado-por Cajero

Aloja
1 1
? Los requerimientos no indican la necesidad de conocer, ni de

registrar al cajero actual.
Iniciado-por
Gerente
1
1..* 1
TPDV
1
1
Almacena
Capturadas-en
Iniciado-por
Pagado-por
Pago
UTFSM

registrar al cajero actual. Adems es derivable si existe la
asociacin TPDV usado-por Cajero.
Tienda
? Venta Capturada por Cajero
Registra-Venta-de
Usado-por
Venta
? El conjunto de asociaciones que se incluye en el modelo se

obtuvo de manera bastante mecnica a partir de la lista de
comprobacin. Pero tal vez hay que ser ms restrictivos
con las asociaciones.
1
CatalogoDeProductos
Cajero
Registra-Ventas-en
Cliente
217
UTFSM
N
I
EXUMBRA
SOLEM
218

Descrita-por
? TPDV Iniciado-por Gerente
Contiene
? Venta Iniciada por Cliente
*
Tienda
1
Venta
1
? Ventas Lnea De Producto Registra -venta-de Producto
219
UTFSM
N
I
EXUMBRA
SOLEM
Aloja
Gerente
1..*
TPDV
Pagado-por
Pago
Capturadas-en
1
1
? Los requerimientos no indican la necesidad de mantener la

informacin del inventario.
Usado-por
Contenidas-en
Capturas-Terminada
? Los requerimientos no indican la necesidad de conocer o mantener

la informacin del inventario.
UTFSM
1
Describe
Producto
1..*
? Tienda Almacena Producto
SOLEM

registrar al cliente actual.
N
I
1..*

registrar al gerente que inici un TPDV.
EXUMBRA
1
CatalogoDeProductos
Cajero
Cliente
220
? Ntese que la capacidad de justificar una asociacin

atendiendo a la necesidad de conocerla depende de los
requerimientos; un cambio de ellos por ejemplo, exigir
que la identificacin del cajero aparezca en el recibo
altera la necesidad de recordar la relacin.
? Recuerde que el modelo conceptual es una representacin

de cosas reales, no de componentes de software.
Cualquier afirmacin concerniente a los atributos ha de
interpretarse dentro del contexto de entidades del mundo
real.
? Enfatice las asociaciones que deben conocerse, pero

incorpore tambin las opcionales que se requieran slo
para la comprensin, con el fin de enriquecer el
conocimiento bsico del dominio.
? Un atributo es una valor lgico de un dato o de un objeto.
Agregacin de los Atributos
UTFSM
N
I
EXUMBRA
SOLEM
221
UTFSM
N
I
EXUMBRA
SOLEM
222
25
? Incluya los siguientes atributos en el modelo conceptual:
? Los tipos ms simples de atributos son los que, en la

prctica, suelen considerarse los tipos primitivos de datos.
? Aquellos en que los requerimientos (por ejemplo, casos de uso)

indican o conllevan la necesidad de recordar informacin.
? Por lo regular, el tipo de un atributo no debera ser un concept o

complejo del dominio, como Venta o Aeropuerto. Por ejemplo,
podramos poner un atributo TPDV-Actual al concepto Cajero, que
no es un tipo simple, pero la forma ms conveniente de expresarlo
es a travs de la asociacin.
?Por ejemplo, un recibo de ventas normalmente incluye fecha y hora.

En consecuencia, el concepto venta requiere dos atributos: fecha y
hora.
? Los atributos se muestran en la segunda seccin de conceptos, es

opcional indicar su tipo.
Cajero
Venta
Cajero
Atributos
UTFSM
N
I
EXUMBRA
SOLEM
TPDV
1
nombre
TPDVactual
fecha
HoraDeInicio: hora
223
UTFSM
N
I
EXUMBRA
SOLEM
Usa
nombre
1
numero
224
? En un modelo conceptual es preferible que los atributos

sean atributos simples o valores puros de datos.
? Entre los tipos comunes de atributos simples ms
frecuentes figuran:
? Es necesario producir una lista de atributos para los

conceptos del dominio de punto de venta. Debera estar
reservada especficamente a los requerimientos a las
simplificaciones en cuestin: Comprar productos versin 1.
Atributos del sistema de punto de venta
? Para eso habr que leer los siguientes documentos:
? Booleano, Fecha, Numero, Cadena (Texto), Hora

? Direccion, Color, Geometria (punto, Rectangulo, ), Telefono, RUT,
Codigo Universal de Producto (CUP), codigo postal, tipos
numerados
? especificacin de requerimientos
? casos de uso en cuestin
? documentos de simplificaciones, clarificaciones y suposiciones
? Una confusin frecuente consiste en modelar como

atributo un concepto complejo del dominio. Por lo tanto,
relacione conceptos a travs de una asociacin no con un
atributo.
UTFSM
N
I
EXUMBRA
SOLEM
225
UTFSM
N
I
EXUMBRA
SOLEM
226
? Por ejemplo, podemos identificar los atributos:
? Es posible que el cajero reciba un grupo de productos

afines (seis paquetes de pauelos desechables) y
introduzca una sla vez el CUP y la cantidad (seis).
? Tienda: direccin, nombre

? Venta: fecha, hora
? VentasLineaDeProducto: cantidad
? Pago: monto
? EspecificacionDeProducto: decripcion, precio, cup
? En consecuencia una instancia de VentasLineaDeProducto puede

estar asociada a ms de una instancia de cada producto.
? La cantidad que introduce el cajero puede quedar registrada como
atributo de VentasLineaDeProducto.
? Sin embargo, tambin puede ser calculada a partir del

valor real de multiplicidad de la relacin; as puede
caracterizarse como atributo derivado, el cual puede ser
deducido de otra informacin.
? En UML, un atributo derivado se denota con el smbolo /.
UTFSM
N
I
EXUMBRA
SOLEM
227
UTFSM
N
I
EXUMBRA
SOLEM
228
26

Descrita-por
/cantidad
Producto
cantidad
0..1 Registra-venta -de 1..*
Contiene
1..*
CatalogoDeProductos
descripcion
precio
CUP
Describe
1..*
Producto
Usado-por
*
Tienda
direccio
1 n
1
Contenidas-en
Capturas-Terminada
1
Venta
fecha
hora
Capturadas-en
Aloja
1..*
TPDV
Pagado-por
Pago
UTFSM
N
I
EXUMBRA
SOLEM
229
UTFSM
N
I
EXUMBRA
SOLEM
? Hemos creado un modelo conceptual relativamente til del

dominio del punto de venta.
? No existe un modelo apropiado para todos los casos y
circunstancias, todos ellos no son ms que aproximaciones
al dominio que queremos entender.
? Un buen modelo conceptual capta las abstracciones
esenciales y la informacin indispensable para comprender
el dominio dentro del contexto de los requerimientos
actuales.
? Identificacin de conceptos
UTFSM
N
I
EXUMBRA
SOLEM
230
Resumen
231
? Ejemplo
? Principio del cartgrafo

? Asociaciones de conceptos
? Identificacin de atributos
? Construccin del modelo conceptual
UTFSM
N
I
EXUMBRA
SOLEM
? Qu es lo que aparece en el modelo conceptual?

? Qu es el principio del cartgrafo?
? Cmo se interpreta este diagrama?
Quiz
232
Quiz
? Qu representa una asociacin?

? Todas las asociaciones son importantes?
<<entorno>>
OpcionesCursoProfesor
<<entorno>>
AadirOfertaCurso
? Qu representa la multiplicidad?
? Porqu son tan importantes los nombres en el modelo?
1
1
<<control>>
GestorCursosProfesor
<<entidad>>
OfertaCursos
1
maneja
0..*
1..*
<<entidad>>
1
Cursos
1..*
0..*
0..*
prerrequisitos
UTFSM
N
I
EXUMBRA
SOLEM
233
UTFSM
N
I
EXUMBRA
SOLEM
234
27
Contenido
Comportamiento de los Sistemas
? Comportamiento de los sistemas

? Diagrama de secuencia del sistema
Perfeccionamien
to del plan
? Contratos
Sincronizacin
de artefactos
Anlisis
Diseo
Construccin
Prueba
? Precondiciones
? Postcondiciones
UTFSM
N
I
EXUMBRA
SOLEM
235
1. Definir casos
esenciales de
uso
2. Perfeccionar
el diagrama de
casos
3. Perfeccionar
el modelo
conceptual
5. Definir
diagramas de
secuencia
6. Definir los
contratos de
operaciones
7. Definir
diagramas de
estado
UTFSM
N
I
EXUMBRA
SOLEM
4. Perfeccionar
el glosario
236
? Antes de iniciar el diseo lgico de cmo funcionar una

aplicacin de software es necesario investigar y definir su
comportamiento como una caja negra.
? Los casos de uso indican cmo los actores interactan con

el sistema de software que es lo que realmente queremos
crear.
? El comportamiento del sistema es una descripcin de lo

que hace, sin explicar la manera en que lo hace. Una parte
de esa descripcin es un diagrama de secuencia del
sistema.
? Durante la interaccin un actor genera eventos dirigidos a

un sistema, solicitando alguna operacin a cambio.
Diagrama de Secuencia del Sistema
UTFSM
N
I
EXUMBRA
SOLEM
237
? Por ejemplo, cuando un cajero introduce un cdigo universal de

producto de un artculo, est pidiendo al sistema TPDV registrar el
cdigo.
UTFSM
N
I
EXUMBRA
SOLEM
238
? El diagrama de secuencia de un sistema es una

representacin que muestra, en un determinado escenario,
los eventos generados por actores externos, su orden y los
eventos externos del sistema.
? Curso normal de los eventos en el caso Comprar Productos.
:Sistema
? 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.
? En el diagrama el tiempo avanza hacia abajo, y el ordenamiento de
los eventos debera seguir el orden indicado en el caso de uso.
? Los eventos del sistema pueden incluir parmetros.
: Cajero
1: introducir Producto(CUP, cantidad)
2: terminarVenta ()
3: efectuarPago(monto )
Sistema como
cajanegra
Actor
Evento del sistema

Inicia una operacin de
sistema
:Sistema
UTFSM
N
I
EXUMBRA
SOLEM
Sistema como
cajanegra
Actor
239
UTFSM
N
I
EXUMBRA
SOLEM
240
28
? El evento de un sistema es un hecho externo de entrada

que un actor produce en un sistema.
? La operacin de un sistema es una accin que ste ejecuta
en respuesta a una evento del sistema.
? Para determinar el conjunto de las operaciones requeridas

del sistema se identifican sus eventos. Cuando se utilizan
los parmetros, las operaciones son las siguientes:
Eventos y operaciones del sistema
? Por ejemplo, cuando un

introducirProducto, causa la
introducirProducto;
Registro de las operaciones de un sistema
? EfectuarPago(CUP, Cantidad)
? TerminarVenta()
? EfectuarPago(monto)
cajero genera un evento

ejecucin de la operacin
? El nombre del evento y de la operacin son idnticos; la

distincin reside en que el evento es el estmulo nombrado
y la operacin es la repuesta (lo mismo sucede con los
mensajes y los mtodos).
UTFSM
N
I
EXUMBRA
SOLEM
241
Sistema
terminarVenta ( )
introducirProducto ( )
efectuarPago( )
? Donde deberan registrarse estas operaciones?. En UML

se pueden agruparse las operaciones como operaciones de
tipo Sistema. Los parmetros son opcionales.
UTFSM
N
I
EXUMBRA
SOLEM
242
? Observe que la representacin del tipo Sistema es muy

diferente a lo que se expres en el modelo conceptual.
? Para elaborar un diagrama de secuencia del sistema que

describa el curso normal de los eventos en un caso de uso:
Registro de las operaciones de un sistema
? Trace una lnea que represente el sistema como una caja negra.
? Identifique los actores que operan directamente sobre el sistema.
Trace una linea para cada uno de ellos.
? A partir del curso normal de los eventos del caso de uso identifique
los eventos (externos) del sistema que son generados por los
actores. Mustrelos grficamente en el diagrama.
? A la izquierda del diagrama puede incluir o no el texto del caso de
uso.
? Los elementos de ste representan conceptos del mundo

real; en cambio, el tipo Sistema es un concepto artificial.
? Ello se debe a la naturaleza de la informacin que estamos
representando: mientras el modelo conceptual es la informacin
esttica, el tipo Sistema representa el comportamiento de sistema,
el cual es la informacin dinmica.
UTFSM
N
I
EXUMBRA
SOLEM
243
UTFSM
N
I
EXUMBRA
SOLEM
244
? Consideramos ahora el caso de uso Comprar Productos a

fin de identificar los eventos del sistema.
? Los eventos de un sistema (y sus operaciones asociadas)

deben expresarse en el nivel de propsito y no en el nivel
el medio fsico de entrada o de elementos de la interfaz.
? Primero debemos determinar los actores que interactan

directamente con el sistema de software.
? El cliente interacta con el cajero, pero no directamente con el
sistema TPDV; esto slo lo hace el cajero.
? Por tanto, el cliente no es un generador de eventos del sistema,
slo el cajero lo es.
UTFSM
N
I
EXUMBRA
SOLEM
245
? Tambin 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 estn
orientados a comandos.
? As, terminarVenta es preferible a IntroducirTeclaOprimida
porque capta mejor el propsito de la operacin: mantiene un
carcter abstracto y no se pronuncia respecto a las decisiones de
diseo sobre cul interfaz sirve para capturar el evento del sistema.
UTFSM
N
I
EXUMBRA
SOLEM
246
29
? En cuanto a expresar las operaciones en el nivel de

propsito, procure alcanzar el nivel ms alto o la meta final
de asignar nombre a la operacin. Por ejemplo, respecto a
la operacin que captura el pago:
? Los diagramas de la secuencia de un sistema forman parte

del modelo de comportamiento del sistema.
? El modelo de anlisis se compone de:
Modelo de anlisis
? Modelo de casos de uso de anlisis (modelo dinmico)

?Casos de uso de alto nivel o esenciales
?Diagramas de casos de uso
? IntroducirImporteOfrecido(monto) deficiente
? IntroducirPago(monto) mejor
? EfectuarPago quiz mejor an
? Modelo conceptual (modelo esttico)

?Diagramas de estructura esttica para los conceptos de dominio
? Modelo de comportamiento (modelo dinmico)

?Diagramas de secuencia del sistema
?Contratos para las operaciones de sistema
? Modelo de estado del anlisis (modelo dinmico)

?Diagramas de estado para conceptos y casos de uso
UTFSM
N
I
EXUMBRA
SOLEM
247
UTFSM
N
I
EXUMBRA
SOLEM
Comportamiento de los sistemas: contratos

Descrita-por
? Los contratos contribuyen a definir el comportamiento de

un sistema; describen el efecto de las operaciones sobre el
sistema.
Contiene
? El lenguaje UML (pero no el Rational Rose) ofrece un soporte para

definir las precondiciones y las poscondiciones de las operaciones.
1
CatalogoDeProductos
descripcion
precio
CUP
*
cantidad
? Los contratos de operacin de sistema se elaboran durante

la fase de anlisis en un ciclo de desarrollo.
N
I
SOLEM
249
Aloja
1..*
TPDV
UTFSM
N
I
EXUMBRA
*
Tienda
direcci
on
1
Pagado-por
EXUMBRA
*
Producto
Capturadas-en
Pago
1
Describe
Usado-por
Contenidas-en
Capturas-Terminada
Venta
fecha
hora
1
1..*
1..*
? Su desarrollo depende del desarrollo previo del modelo

conceptual, de los diagramas de secuencia de sistema y la
identificacin de sus operaciones.
UTFSM
248
SOLEM
250
? En trminos generales, un contrato es un documento que

describe lo que una operacin se propone lograr.
? El siguiente ejemplo describe un contrato de la operacin

introducirProducto del sistema:
? Suele redactarse en un estilo declarativo, enfatizando lo que

suceder y no cmo se conseguir.
? Los contratos suelen expresarse a partir de los cambios de estado
de las precondiciones y de las poscondiciones.
? Puede elaborarse un contrato tanto para un mtodo de una clase,
como para una operacin ms global del sistema, aunque por
ahora nos concentramos en su uso para las operaciones globales
del sistema.
? El contrato de operacin del sistema describe cambios del

estado del sistema total cuando se llama una de sus
operaciones.
UTFSM
N
I
EXUMBRA
SOLEM
251
Contrato
IntroducirProducto (cup:numero, cantidad:entero )
Capturar (registrar) la venta de un producto y agregarla a la venta. Desplegar
la descripcin 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 superrpido a la base de datos.
Excepciones:
Si el CUP no es vlido, indicar que se cometi.
Salida:
Precondiciones:
El sistema conoce el CUP.
Nombre:
Responsabilidades:
UTFSM
N
I
EXUMBRA
SOLEM
252
30
Poscondiciones:
Si se trata de una nueva venta, se cre una Venta (creacin de instancia ).
Si se trata de una nueva venta, la nueva
Venta fue asociada a un
TPDV ( asociacin
formada).
Se cre una instancia VentasLineadeProducto (creacin de instancia ).
Se asoci una instancia de VentasLineadeProducto a la Venta (asociacin formada ).
Se asign una cantidad a VentasLineadeProducto.cantidad (modificacin de atributo ).
Se asoci una instancia VentasLineadeProducto a la instancia EspecificaciondeProducto ,
basado en la correspondencia del CUP ( asociacin formada ).
? No todas las secciones del contrato son necesarias; se

recomienda llenar Responsabilidades y Poscondiciones.
UTFSM
N
I
EXUMBRA
SOLEM
Nombre:
Responsabilidades:
Tipo:
Referencias cruzadas:
Notas:
Excepciones:
Salida:
Precondiciones:
Poscondiciones:
253
Contrato
Nombre de la operacin y sus parmetros.
Descripcin informal de las responsabilidades que debe cumplir la operacin.
Nombre del tipo (concepto, clase de software, interfaz).
Nmeros de referencia de las funciones del sistema, casos de uso, etc.
Declaraciones del diseo referentes a la operacin. Por ejemplo, si se sabe
que se prefiere un algoritmo particular para manejar la operacin, esa seccin
es el sitio indicado.
Casos excepcionales.
Slo dentro del sistema, no incorpore salidas de interfaz de usuario, mensajes
o registros que se envan fuera del sistema.
Suposiciones acerca del estado del sistema antes de ejecutar la operacin.
El estado del sistema despus de la operacin.
UTFSM
N
I
EXUMBRA
SOLEM
254
? Aplique la siguiente sugerencia para elaborar contratos.
? Despus de la seccin de Responsabilidades, la parte ms

importante del contrato son las poscondiciones, que
estipulan cmo cambi el sistema tras la operacin.
Poscondiciones
? Identifique las operaciones del sistema a partir de los diagramas de

secuencia.
? Elabore un contrato en cada operacin del sistema.
? Comience redactando la seccin Responsabilidades; despus
describa informalmente el propsito de la operacin.
? Complete la seccin de Postcondiciones , describiendo en forma
declarativa los cambios de estado de los objetos en el modelo
conceptual.
? Para describir las postcondiciones utilice las siguientes categoras:
? Las poscondiciones
conceptual.
UTFSM
N
I
SOLEM
255
expresan
dentro
del
modelo
? Qu instancias es posible crear? La repuesta es: las provenientes

del modelo conceptual.
? Qu asociaciones es posible formar? La repuesta es: las que estn
en el modelo conceptual.
? Creacin y eliminacin de instancias.

? Modificacin de atributos.
? Asociaciones formadas y canceladas.
EXUMBRA
se
UTFSM
N
I
EXUMBRA
SOLEM
256
? Cuando se formulan contratos, en general se agregarn al

modelo conceptual nuevos conceptos, atributos y
asociaciones.
? Entonces, mire el contrato desde la perspectiva de un

escenario y un teln.
Poscondiciones
Poscondiciones
? Tome una fotografa de escenario antes de la operacin

? Corra el teln y aplique la operacin del sistema (ruido de fondo
con sonidos).
? Corra el teln y tome una segunda fotografa.
? Compare las fotografas de antes y despus, y exprese como
poscondiciones los cambios del estado del escenario (se cre la
instancia VentasLineadeProducto).
? Mejore el modelo conforme a los nuevos descubrimientos, mientras

reflexiona sobre los contratos de las operaciones.
? Las poscondiciones deberan expresar el estado de un

sistema, no las acciones a realizar.
? Exprselas en tiempo pasado para enfatizar que se trata de
declaraciones sobre un cambio pretrito de estado. Por ejemplo:
?Se cre una instancia VentasLineadeProducto (mejor)
? En lugar de
?Crear una instancia VentasLineadeProducto (peor)
UTFSM
N
I
EXUMBRA
SOLEM
257
UTFSM
N
I
EXUMBRA
SOLEM
258
31
? Poscondiciones:
? Si se trata de una nueva venta, se cre una Venta (creacin de instancia).
? Si se trata de una nueva venta, la nueva Venta fue asociada a un TPDV (asociacin
formada).
? Se cre una instancia VentasLineadeProducto (creacin de instancia ).
? Se asoci una instancia de VentasLineadeProducto a la Venta asociacin
(
formada).
? Una vez que el cajero captur el CUP y la cantidad del

producto, Qu ha de crearse?.
? Si se trata de una nueva venta, habra que crear una
instancia para una nueva Venta. Una instancia
VentasLineadeProducto debera ser creada de modo
incondicional.
Ejemplo
Ejemplo
? Se asign una cantidad a VentasLineadeProducto.cantidad (modificacin de

atributo).
? Se
asoci
una
instancia
VentasLineadeProducto a
la
instancia
EspecificaciondeProducto, basado en la correspondencia del CUP a( sociacin
formada).
UTFSM
N
I
EXUMBRA
SOLEM
259
? Si se trata de una nueva venta, se cre una Venta (creacin de

instancia).
? Se cre una instancia VentasLineadeProducto (creacin de
instancia).
UTFSM
N
I
EXUMBRA
SOLEM
260
? Una vez que el cajero captur el CUP y la cantidad del

producto, qu atributos de los objetos nuevos o actuales
deberan ser modificados?. Habra que establecer la
cantidad de VentasLineadeProducto.
? 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?.
? Habra 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.
Ejemplo
? Se asign una cantidad

(modificacin de atributo).
Ejemplo
VentasLineadeProducto.cantidad
? Se asoci una instancia de VentasLineadeProducto a la Venta (asociacin

formada).
? Si se trata de una nueva venta, la nueva Venta fue asociada a un TPDV
(asociacin formada).
? Se asoci una instancia VentasLineadeProducto a la instancia
EspecificaciondeProducto , basado en la correspondencia del CUP
UTFSM
N
I
EXUMBRA
SOLEM
261
UTFSM
N
I
EXUMBRA
SOLEM
? Las precondiciones definen las suposiciones sobre el

estado del sistema al iniciarse la operacin.
? El problema ms comn consiste en olvidar incluir la

formacin de asociaciones. Sobre todo cuando se crean
nuevas instancias, muy probablemente ser necesario
haber establecido las asociaciones a varios objetos.
Precondiciones
262
Contratos
? Hay muchas precondiciones que pueden declararse en una

operacin, pero la experiencia revela que vale la pena
mencionar las siguientes:
? Cosas que son importantes de probar en el software en algn
momento de la ejecucin de la operacin.
? Cosas que sern sometidas a prueba, pero de las cuales depende
el xito para subrayar la importancia y para hacer notarlas a los
otros lectores.
UTFSM
N
I
EXUMBRA
SOLEM
263
UTFSM
N
I
EXUMBRA
SOLEM
264
32
Contrato para introducirProducto
Contrato para terminarVenta
Contrato
IntroducirProducto (cup:numero, cantidad:entero )
Tipo:
Sistema
Referencias cruzadas: Funciones del sistema: R1.1, R1.3, R1.6
Notas:
Excepciones:
Si el CUP no es vlido, indicar que se cometi un error.
Salida:
Precondiciones:
Poscondiciones:
? Si se trata de una nueva venta, fue creada unaVenta.
? Si se trata de una nueva venta, la nuevaVenta fue asociada a unTPDV.
? Se cre una instanciaVentasLineadeProducto.
? Se asoci una instancia deVentasLineadeProducto a la Venta.
? Se asign una cantidad aVentasLineadeProducto.cantidad.
VentasLineadeProducto a la instancia
? Se asoci una instancia
, basado en la correspondencia del CUP.
UTFSM
Nombre:
Responsabilidades:
N
I
EXUMBRA
SOLEM
265
Tipo:
Notas:
Excepciones:
Si no esta realizndose una venta, indicar que se cometi un error.
Salida:
Precondiciones:
Poscondiciones:
Estableci Venta.estaTerminada enverdadero .
UTFSM
N
I
EXUMBRA
UTFSM
N
I
SOLEM
266
Contrato
Nombre:
Inicio()
Responsabilidades:
Inicializar el sistema
Tipo:
Sistema.
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.
Contrato
efectuarPago(monto: nmero)
Registrar el pago, calcular el saldo e imprimir el recibo.
Sistema.
Funciones del sistema: R2.1
SOLEM
Contrato para Inicio
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 histrico de las ventas terminadas.
EXUMBRA
Contrato
terminarVenta()
Registrar que es el final de la captura de los productos de la venta y desplegar
el total de la venta.
Sistema
Funciones del sistema: R1.2
Contrato para efectuarPago
Nombre:
Responsabilidades:
Tipo:
Nombre:
Responsabilidades:
267
UTFSM
N
I
EXUMBRA
SOLEM
? Estos contratos sugieren la existencia de un dato que todava no ha

figurado en el modelo conceptual: la terminacin de la captura de los
productos en la venta. Lo modifica la operacin terminarVenta y la
especificacin efectuarPago lo toma como precondicin.
? Comportamiento de los sistemas

? Diagrama de secuencia del sistema
268
Resumen
Cambios en el modelo conceptual
? Contratos
? Precondiciones
? Postcondiciones
? Una forma de representar esta informacin es a travs de un atributo

estaTerminada de la Venta, por medio de un valor booleano.
Venta
estaTerminada: boolean
fecha
hora
UTFSM
N
I
EXUMBRA
SOLEM
269
UTFSM
N
I
EXUMBRA
SOLEM
270
33
Diseo Orientado a Objetos
? Qu es el comportamiento de un sistema?
? Qu representa el diagrama de secuencia del sistema?
? Fase de Diseo
Quiz
Contenido
? Artefactos
? Actividades
? Cul es la diferencia entre evento y operacin?

? Porqu se crea el concepto sistema?
? Casos Reales de Uso

? Diagramas de Interaccin
? Cul es el nombre correcto para una operacin?

? Cul es la diferencia entre lo esttico y lo dinmico?
? Porqu son necesarios los contratos y cuantos son para
un caso de uso?
? Cuales son los condiciones para elaborar un contrato?
? Cuales son las partes ms importantes del contrato?
UTFSM
N
I
EXUMBRA
SOLEM
271
UTFSM
N
I
EXUMBRA
SOLEM
272
? En la fase de anlisis del desarrollo se da prioridad al

conocimiento de los requerimientos, los conceptos y las
operaciones relacionadas con el sistema.
? El siguiente grupo mnimo de artefactos sirven para capturar los

resultados de una investigacin:
Fase de Diseo
Fase de Diseo
? Casos de uso
? Cules son los procesos del dominio?
? Modelo Conceptual
? Anlisis se caracteriza por centrarse en cuestiones

concernientes al qu, mientras que el diseo se concentra
en cmo.
? Cules son los conceptos, los trminos?
? Diagramas de la secuencia de un sistema

? Cules son los eventos y las operaciones del sistema?
? Contratos
? Qu hacen las operaciones del sistema?
? Durante el ciclo de desarrollo iterativo es posible pasar a la fase de

diseo una vez terminados estos documentos de anlisis.
UTFSM
N
I
EXUMBRA
SOLEM
273
UTFSM
N
I
EXUMBRA
SOLEM
274
Fase de Diseo
Actividades
? Durante la fase de diseo se logra una solucin lgica que

se fundamenta en el paradigma orientado a objetos.
? Su esencia es la elaboracin de diagramas de interaccin, que
muestran grficamente cmo los objetos se comunicarn entre
ellos a fin de cumplir con los requerimientos.
? La definicin de los diagramas de interaccin nos permite dibujar
los diagramas de diseo de clases que resumen la definicin de las
clases (e interfaces) implementables en el software.
UTFSM
N
I
EXUMBRA
SOLEM
275
Perfeccionamiento
del plan
UTFSM
N
I
EXUMBRA
SOLEM
Sincronizacin de
artefactos
Anlisis
Diseo
Construccin
1. Definir los casos

reales de uso
2. Definir reportes,
interfaz de usuario
y storyboards
3. Perfeccionar la
arquitecturadel
sistema
4. Definir los
diagramas de
interaccin
5. Definir los
diagramas de
clases de diseo
6. Definir el
esquema de la
base de datos
Prueba
276
34
Descripcin de los casos reales de uso
Ejemplo: Comprar Productos Versin 1

Caso de uso:
Actores:
Propsito:
Resumen:
? Un caso real de uso describe el diseo concreto del caso

de uso a partir de una tecnologa particular de entrada y
salida, as como de su implementacin global.
? Por ejemplo, si interviene una interfaz grfica de usuario, el caso
real de uso incluir los diagramas de las ventanas en cuestin y
una explicacin de la interaccin de bajo nivel con los artefactos de
la interfaz.
Tipo:
Referencias
Cruzadas:
? Tal vez no sea necesario generarlos. Una alternativa podra

ser disear los storyboards o secuencias de pantallas de la
interfaz de usuario y ampliarlos con ms detalles durante
la implementacin.
UTFSM
N
I
EXUMBRA
SOLEM
277
Tienda de Objetos
UTFSM
N
I
EXUMBRA
SOLEM
Cantidad
Precio
Desc.
Total
Saldo
Ofrecido
D
Introducir
Producto
UTFSM
Terminar
Venta
Efectuar
Pago
Fundamentos
H
deI Ingeniera deJSW
SOLEM
278
Diagramas de interaccin
? Los diagramas de interaccin no se pueden preparar si

antes no se generan los siguientes artefactos:
? Un modelo conceptual a partir del cual el diseador podr definir
las clases de software correspondientes a los conceptos. Los
objetos de las clases participan en las interacciones que se
describen grficamente en los diagramas.
? Contratos de la operacin del sistema: a partir de ellos el diseador
identifica las responsabilidades y las poscondiciones que han de
cumplir los diagramas de interaccin.
? Casos de uso reales (o esenciales): a partir de ellos el diseador
recaba la informacin sobre las tareas que realizan los diagramas
de interaccin, adems de los estipulado en los contratos.
Saldo
N
I
EXUMBRA
Curso normal de eventos:

Cliente llega a una caja de TPDV con
2. Con cada producto, el Cajero teclea el
3. Agrega la informacin sobre el producto
cdigo universal de producto (CUP) en A
a la actual transaccin de ventas.
de la Ventana 1. Si un producto se repite, el
El precio del producto y la descripcin del
Cajero tambin puede introducir la
producto actual aparecen en el recuadro B
cantidad en E. Se oprime botn H despus
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 botn I para indicarle al
total de la venta.
TPDV que se concluy la captura de
Tienda de Objetos
productos.
CUP
Cantidad
E
A
6.
Precio
Desc.
Ofrecido
CUP
Ejemplo: Comprar Productos Versin 1
Total

El Cajero registra los artculos y recibe una pago en efectivo. Al
comprados.
Primario y real
Funciones: R1.1, R1.2, R1.3, R1.7, R2.1
D
Introducir
Producto
Fundamentos de Ingeniera deHSW
Terminar
Venta
Efectuar
Pago
279
UTFSM
N
I
EXUMBRA
SOLEM
280
? Un diagrama de interaccin explica grficamente las

interacciones existentes entre las instancias (y las clases).
? Los diagramas de colaboracin describen las interacciones

entre los objetos en un formato de grafo o red:
? El punto de partida de las interacciones es el cumplimiento de las

poscondiciones de los contratos de operacin.
mensaje1()
1: mensaje2()
2: mensaje3()
Instancia1 : ClaseA
Instancia2 : ClaseB
? Los diagramas de secuencia describen las interacciones en

una especie de formato de cerca o muro:
? El UML define dos tipos de estos diagramas; ambos sirven

para expresar interacciones semejantes o idnticas al
mensaje.
Instancia1 :
ClaseA
mensaje1()
Instancia2 :
ClaseB
mensaje2()
mensaje3()
UTFSM
N
I
EXUMBRA
SOLEM
281
UTFSM
N
I
EXUMBRA
SOLEM
282
35
Ejemplo de un diagrama de colaboracin: efectuarPago
Direccin del
mensaje
Preparacin de un diagrama de colaboracin

? Elabore un diagrama por cada operacin del sistema
durante el ciclo actual de desarrollo.
Primer mensaje
interno
efectuarPago( efectivoOfrecido)
? En cada mensaje del sistema, dibuje un diagrama incluyndolo

como mensaje inicial.
? Si el diagrama se torna complejo (por ejemplo), si no cabe
holgadamente en una hoja de papel carta, divdalo en diagramas
ms pequeos.
? Disee un sistema de objetos interactivos que realicen las tareas,
usando como punto de partida las responsabilidades del contrato
de operacin, las poscondiciones y la descripcin de casos de uso.
1: efectuarPago (efectivoOfrecido)
: TPDV
: Venta
Lnea de
enlace
primer
mensaje
Instancia
2: crear(efectivoOfrecido)
Parametro
: Pago
UTFSM
N
I
EXUMBRA
SOLEM
? Aplique el GRASP y otros patrones para desarrollar un

buen diseo
283
: TPDV
terminarVenta ()
efectuarPago(EfectivoOfrecido )
efectuarPago(efectivoOfrecido)
ContratoEfectuarPago
Poscondiciones:
UTFSM
: TPDV
Diagrama de colaboracin
Contratos
N
I
EXUMBRA
SOLEM
284
? Los casos de uso indican los eventos del sistema que se

muestran explcitamente en los diagramas de secuencia.
? En los contratos se describe la mejor conjetura inicial sobre
las operaciones del sistema.
? Las operaciones del sistema representan mensajes y stos
originan diagramas que explican grficamente cmo los
objetos interactan para llevar a cabo las funciones
requeridas.
introducirProducto(CUP,cantidad)
Poscondiciones:
1. Si se trata de una nueva venta
se creo una nueva venta
Diagrama de secuencia del sistema
ContratoIntroducirProducto
:Sistema
SOLEM
: Cajero
UTFSM
N
I
EXUMBRA
285
UTFSM
N
I
EXUMBRA
SOLEM
286
? El UML ha adoptado un mtodo simple y uniforme de distinguirlas

visualmente las instancias de acuerdo a tipo:
? Si vemos dos instancias en una relacin de cliente servidor, una trayectoria de navegacin del cliente al
servidor significa que los mensajes pueden enviarse del
primero al segundo.
Notacin de los diagramas de interaccin
? Con cada tipo de elemento del UML (clase, actor, ...), una insta ncia utiliza
el mismo smbolo grfico usado para representar el tipo, pero se subraya
el texto.
Clase
Venta
Instancia
: Venta
? As, existe un vnculo o trayectoria de navegacin entre TPDV y

una Venta, a lo largo del cual pueden fluir los mensajes; por
ejemplo, el mensaje agregarPago.
Instancia con
nombre
s1: Venta
Parmetros
mens1()
? El vnculo (o enlace) es una trayectoria de conexin entre dos

instancias, indica la forma de navegacin y visibilidad que es posible
entre las instancias.
:TPDV
N
I
EXUMBRA
SOLEM
287
: Venta
Todos los mensajes fluyen por
el mismo vnculo .
? En un lenguaje ms formal, el vnculo es una instancia de una asociacin.

UTFSM
2: agregarPago(monto: Numero)
UTFSM
N
I
EXUMBRA
SOLEM
288
36
? Los mensajes entre objetos pueden representarse por

medio de una flecha con un nombre y situada sobre una
lnea del vnculo.
? Un objeto puede enviarse un mensaje de a s mismo: esto

lo muestra grficamente un vnculo consigo mismo, donde
el mensaje fluye a lo largo del vnculo.
? Se agrega un nmero de secuencia que indique el orden consecutivo de

los mensajes en la serie actual de control.
? Los parmetros de un mensaje pueden anotarse dentro de parntesi s
despus del nombre del mensaje. Es opcional incluir o no el tipo de
parmetro en cuestin
mens1()
:TPDV
? El lenguaje UML cuenta con una sintaxis estndar para los mensajes:
? retorno : mensaje(parametro: tipoParametro) : tipoRetorno
? No obstante, es legal servirse de otra sintaxis como la de Java o la de Smalltalk.

Recomendamos emplear la sintaxis estndar de UML a fin de que los diagramas
de colaboracin sigan siendo un lenguaje relativamente independiente
UTFSM
N
I
EXUMBRA
SOLEM
289
1: limpiar ()
UTFSM
N
I
EXUMBRA
SOLEM
290
? La iteracin se indica posponiendo un asterisco (*) al

nmero de secuencia. Ese smbolo significa que, dentro de
un ciclo, el mensaje va a ser enviado repetidamente al
receptor. Tambin es posible incluir una clusula de
iteracin que indique los valores de recurrencia.
? El mensaje de creacin independiente del lenguaje es

crear, que se muestra en el momento de ser enviado a la
instancia que vamos a generar.
? El mensaje crear puede contener parmetros, lo cual indica

la transferencia de los valores iniciales.
1*: [i :=1..10] li:=siguienteLineadeProducto ( ) :

VentasLineadeProducto
mens1()
mens1()
:TPDV
UTFSM
N
I
EXUMBRA
SOLEM
:TPDV
291
UTFSM
N
I
EXUMBRA
: Venta
SOLEM
Numeracin compleja de secuencias
? El orden de los mensajes se indica con un nmero de

secuencia, como se aprecia en la figura. El esquema de la
numeracin es:
segundo
primero
1: mens2()
tercero
? El primer mensaje no se numera. As, mens1() no lleva nmero.

? El orden y el anidamiento de los mensajes siguientes se indican
con un esquema legal de numeracin, donde a los mensajes
anidados se les ha antepuesto un nmero. La anidacin se denota
anteponiendo el nmero del mensaje de entrada al del mensaje de
salida.
: ClaseA
: ClaseB
2: mens4()
1.1: mens3()
cuarto
2.1: mens5()
quinto
: ClaseC
1:crear(cajero)
:TPDV
2.2: mens6()
:Venta
: ClaseD
UTFSM
N
I
EXUMBRA
SOLEM
292
mens1()
1:crear(cajero)
: Venta
293
UTFSM
N
I
EXUMBRA
SOLEM
sexto
294
37
? Un mensaje condicional se indica posponiendo al nmero

de la secuencia una clusula condicional entre corchetes,
en forma parecida a como se hace con una clusula de
iteracin. El mensaje se enva slo si la clusula se evala
como verdadera.
? Un multiobjeto, o conjunto de instancias, puede dibujarse

como un icono de pila segn se observa en la figura.
mens1()
Multiobjeto
Ventas : Venta
? Un multiobjeto suele implementarse como un grupo de

instancias guardadas en un contenedor u objeto coleccin;
1:[nueva venta]crear()
:TPDV
? por ejemplo, un vector de la STL de C++, un Vector de Java o una

ColeccionOrdenada (OrderedCollection) de Smalltalk.
:Venta
? Pero no necesariamente se implementa as; representa tan

slo un conjunto lgico de instancias.
UTFSM
N
I
EXUMBRA
SOLEM
295
UTFSM
N
I
EXUMBRA
SOLEM
296
? Un mensaje dirigido a un icono de multiobjeto indica que

se enva al objeto coleccin.
? Los mensajes pueden ser dirigidos a la propia clase y no a

una instancia, con el fin de llamar los mtodos de la clase.
? Por ejemplo, en Java stos se implementan como mtodos

estticos; en Smalltalk son mtodos de clases.
? As, en la figura el mensaje tamao est siendo enviado a la

instancia VentasLineadeProducto.
no subrayada,
por tanto una clase
mensaje enviado al
objeto coleccin
1: d1 :=hoy(): Fecha
: Venta
1: s := tamao(): entero
: Venta
? En el lenguaje UML los mensajes dirigidos a un multiobjeto

no se trasmiten a todos los elementos (como suceda en
las versiones anteriores del UML).
UTFSM
N
I
EXUMBRA
SOLEM
297
Fecha
? En consecuencia, es importante ser consistente en

subrayar los nombres de las instancias cuando se desea
denotar una instancia
: VentasLineaDeProducto
? De lo contrario pueden interpretarse errneamente los mensajes

dirigidos a las instancias y los dirigidos a las clases.
UTFSM
N
I
EXUMBRA
SOLEM
298
? Booch y Rumbaugh definen la responsabilidad como un

contrato u obligacin de un tipo o clase.
? Entre las responsabilidades de un objeto relacionadas con

hacer se encuentran:
Responsabilidades y mtodos
? Las responsabilidades se relacionan con las obligaciones de un

objeto respecto a su comportamiento.
? hacer algo en uno mismo

? iniciar una accin en otros objetos
? controlar y coordinar actividades en otros objetos
? Esas responsabilidades pertenecen, esencialmente, a las

dos categoras siguientes: conocer o hacer
? Entre las responsabilidades de un objeto relacionadas con

conocer se encuentran:
? Las responsabilidades se asignan a los objetos durante el

diseo orientado a objetos.
? estar enterado de los datos privados encapsulados

? estar enterado de la existencia de objetos conexos
? estar enterado de cosas que se puede derivar o calcular
? Por ejemplo, puede declararse que una Venta es responsable de

imprimirse ella misma (un hacer) o que una Venta tiene la
obligacin de conocer su fecha (un conocer).
UTFSM
N
I
EXUMBRA
SOLEM
299
? Las responsabilidades relacionadas con conocer a menudo pueden inferirse

del modelo conceptual por los atributos y asociaciones explicadas en l.
UTFSM
N
I
EXUMBRA
SOLEM
300
38
? Responsabilidad no es lo mismo que mtodo: los mtodos

se ponen en prctica para cumplir con las
responsabilidades.
? La figura indica que a los objetos Venta se les ha asignado

la responsabilidad de imprimirse ellos mismos, la cual se
llama con un mensaje imprimir y se cumple con el mtodo
correspondiente imprimir.
? stas se implementan usando mtodos que operen solos o en

colaboracin con otros mtodos y objetos.
? Ms an, para atender esta responsabilidad hay que

colaborar con los objetos VentasLineadeProducto,
pidindoles que se impriman.
significa que los objetos

Venta tienen la
responsabilidad de imprimirse
1: [en cada] vli :=siguiente()
imprimir()
: Venta
2: imprimir()
UTFSM
N
I
EXUMBRA
SOLEM
vli : VentasLineaDeProducto
301
UTFSM
N
I
EXUMBRA
SOLEM
? En resumen, los diagramas de interaccin muestran las

decisiones referentes a la asignacin de responsabilidades
entre los objetos.
? Fase de Diseo
302
Resumen
? Artefactos
? Actividades
? Casos Reales de Uso

? Diagramas de Interaccin
? Cuando se preparan, se toman decisiones sobre la

asignacin que se reflejan en los mensajes que son
enviados a varias clases de objetos.
? Los patrones GRASP guan las decisiones sobre la
asignacin de responsabilidades. Esas decisiones se
reflejan despus en los diagramas de interaccin.
UTFSM
N
I
EXUMBRA
SOLEM
303
UTFSM
N
I
EXUMBRA
SOLEM
Patrones de Diseo
? Qu artefactos se preparan durante diseo OO?

? Cul es la diferencia entre anlisis y diseo OO?
? Patrones GRASP
Quiz
304
Contenido
? Experto
? Creador
? Bajo Acoplamiento
? Alta Cohesin
? Controlador
? Qu es un caso de uso real?

? Qu representa un diagrama de interaccin?
? Cmo se trasmite el retorno de un mensaje?
? Porqu los objetos deben interactuar entre s?
? Cmo se interpreta el mensaje a multiobjeto?
? Qu es la responsabilidad de una clase?
UTFSM
N
I
EXUMBRA
SOLEM
305
UTFSM
N
I
EXUMBRA
SOLEM
306
39
Patrones de Diseo
Patrones de Diseo
? Un sistema orientado a objetos se compone de objetos que

envan mensajes a otros objetos para que lleven a cabo las
operaciones.
? La calidad de diseo de la interaccin de los objetos y la

asignacin de responsabilidades presentan gran variacin.
GRASP: Patrones para Asignar Responsabilidades
? Las decisiones poco acertadas dan origen a sistemas y

componentes frgiles y difciles de mantener, entender, reutilizar o
extender.
? Una implementacin hbil se funda en los principios cardinales que
rigen un buen diseo orientado a objetos.
? En los contratos se incluye una conjetura inicial sobre las

responsabilidades y las poscondiciones de las operaciones
inicio, introducirProducto, terminarVenta y efectuarPago.
? Los diagramas de interaccin describen grficamente la
solucin -a partir de los objetos en interaccin- que
satisfacen estas responsabilidades y poscondiciones.
UTFSM
N
I
EXUMBRA
SOLEM
307
? En los patrones GRASP se codifican algunos de los

principios, que se aplican al preparar los diagramas de
interaccin.
UTFSM
N
I
EXUMBRA
SOLEM
308
Patrones de Diseo
Patrones de Diseo
? Los diagramas de interaccin son algunos de los artefactos

ms importantes que se preparan en el anlisis y diseo
orientados a objetos.
? Los diseadores expertos en orientacin a objetos (y

tambin otros diseadores de software) van formando un
amplio repertorio de principios generales y de expresiones
que los guan al crear software.
? Es muy importante asignar acertadamente las responsabilidades al

momento de elaborar os diagramas de interaccin.
? El tiempo y el esfuerzo que se dedican a su elaboracin, as com o
un examen riguroso de la asignacin de responsabilidades,
deberan absorber parte considerable de la fase de diseo de un
proyecto.
? Los patrones, principios y expresiones especializadas codificados
sirven para mejorar la calidad del diseo.
UTFSM
N
I
EXUMBRA
SOLEM
309
? Muchos patrones ofrecen orientacin sobre cmo asignar

las responsabilidades a los objetos ante determinada
categora de problemas.
UTFSM
N
I
EXUMBRA
SOLEM
310
Patrones de Diseo
Patrones de Diseo
? En la terminologa de objetos, el patrn es una descripcin de un

problema y su solucin, que recibe un nombre y que puede emplearse
en otros contextos.
? Los patrones GRASP son parejas de problema solucin con

un nombre, que codifican buenos principios y sugerencias
relacionados frecuentemente con la asignacin de
responsabilidades.
Nombre del Patrn

Solucin
Problema que resuelve
Experto
Asignar una responsabilidad a la clase que tiene la
informacin necesaria para cumplirla.
Cul es el principio fundamental en virtud del cual
asignaremos las responsabilidades a los objetos?
Pregunta:
Respuesta:
? En teora, todos los patrones poseen nombres muy sugestivos. El

asignar nombre a un patrn, a un mtodo o a un principio ofrece las
siguientes ventajas:
Qu son los patrones GRASP?

Los patrones GRASP describen los principios
fundamentales de la asignacin de responsabilidades a
objetos, expresados en forma de patrones.
? Apoya el agrupamiento y la incorporacin del concepto a nuestro sistema

cognitivo y a la memoria.
? Facilita la comunicacin.
UTFSM
N
I
EXUMBRA
SOLEM
311
UTFSM
N
I
EXUMBRA
SOLEM
312
40
Patrones de Diseo
? GRASP es un acrnimo que significa G eneral Responsibility

A signment S oftware P atterns (patrones generales de
software para asignar responsabilidades).
? Los diagramas de clase en UML presentan las clases de

software en contraste con los conceptos de dominio. La
casilla de clase consta de tres secciones, la tercera
contiene los mtodos de la clase, como se aprecia en la
figura.
Notacin del UML para los diagramas de clase
? El nombre se eligi para indicar la importancia de captar

(grasping) estos principios, si se quiere disear
eficazmente el software orientado a objetos.
La tercera
seccin esta
NombredeClase
atributos
destinada a
mtodos
los
metodos( )
UTFSM
N
I
EXUMBRA
SOLEM
313
Patrones de Diseo
UTFSM
SOLEM
314
Patrones de Diseo
Experto
Experto
? Problema
? Ejemplo
? Cul es el principio fundamental en virtud del cual se asignan

responsabilidades en el diseo orientado a objetos?
las
? En la aplicacin del punto de venta, alguna clase necesita conocer

el gran total de la venta. Comience asignando las responsabilidades
con una definicin clara de ellas. A partir de esta recomendacin se
plantea la pregunta:
? Un modelo de clase puede definir docenas y hasta cientos de clases de

software, y una aplicacin tal vez requiera el cumplimiento de cientos o
miles de responsabilidades.
? Si estas se asignan en forma adecuada, los sistemas tienden a ser ms
fciles de entender, mantener y ampliar, y se nos presenta la oportunidad
de reutilizar los componentes en futuras aplicaciones.
?Quin es el responsable de conocer el gran total de la venta?

?Desde el punto de vista del patrn Experto, deberamos buscar la
clase de objetos que posee la informacin necesaria para calcula r el
total.
? Solucin
? Asignar una responsabilidad al experto en informacin: la clase que cuenta
con la informacin necesaria para cumplir la responsabilidad.
UTFSM
N
I
EXUMBRA
N
I
EXUMBRA
SOLEM
315
Patrones de Diseo
SOLEM
316
Patrones de Diseo
Experto
cantidad
UTFSM
N
I
EXUMBRA
Experto
Descritas-por
? En conclusin, para cumplir con la responsabilidad de

conocer y dar el total de la venta, se asignaron tres
responsabilidades a las tres clases de objeto as:
EspecificaciondeProductos
1..*
Contenidas-en
Clase
Venta
VentasLineadeProducto
1
Venta
fecha
hora
UTFSM
N
I
EXUMBRA
SOLEM
317
UTFSM
N
I
EXUMBRA
SOLEM
Responsabilidad
conoce el total de la venta
conoce el subtotal de la lnea de producto
conoce el precio del producto
318
41
Patrones de Diseo
Patrones de Diseo
Experto
Experto
? Experto es un patrn que se usa ms que cualquier otro al

asignar responsabilidades; es un principio bsico que suele
til en el diseo orientado a objetos.
1: [en cada] vli :=siguiente()
t :=total()
: Venta
2: s t :=subtotal()
? Ntese, que el cumplimiento de una responsabilidad

requiere a menudo informacin distribuida en varias clases
de objetos.
3: p:= precio()
: EspecificaciondeProductos
UTFSM
N
I
EXUMBRA
SOLEM
319
UTFSM
N
I
EXUMBRA
SOLEM
Patrones de Diseo
Patrones de Diseo
? Beneficios
? Problema
Experto
Creador
? Se conserva el encapsulamiento, ya que los objetos se valen de su

propia informacin para hacer lo que se les pide. Esto soporta un
bajo acoplamiento, lo que favorece al hecho de tener sistemas ms
robustos y de fcil mantenimiento.
? Quin debera ser responsable de crear una nueva

instancia de alguna clase?
? La creacin de objetos es una de las actividades ms frecuentes en
un sistema orientado a objetos.
? En consecuencia, conviene contar con un principio general para
asignar las responsabilidades concernientes a ella.
? El diseo, bien asignado, puede soportar un bajo acoplamiento,
una mayor claridad, el encapsulamiento y la reutilizabilidad.
? El comportamiento se distribuye entre las clases que cuentan con

la informacin requerida, alentando con ello definiciones de clase
sencillas y ms cohesivas que son ms fciles de comprender y
de mantener. As se brinda soporte a una alta cohesin.
UTFSM
N
I
EXUMBRA
SOLEM
321
UTFSM
N
I
EXUMBRA
SOLEM
Patrones de Diseo
Patrones de Diseo
? El patrn Creador gua la asignacin de responsabilidades

relacionadas con la creacin de objetos, tarea muy
frecuente en los sistemas orientados a objetos.
? Solucin
Creador
? Asignarle a la clase B la responsabilidad de crear una instancia de

clase A en uno de los siguientes casos:
?
?
?
?
?
? Al escogerlo como creador, se da soporte al bajo

acoplamiento.
UTFSM
N
I
SOLEM
322
Creador
? El propsito fundamental de este patrn es encontrar un

creador que debemos conectar con el objeto producido en
cualquier evento.
EXUMBRA
320
323
B agrega los objetos A.

B contiene los objetos A.
B registra las instancias de los objetos A o
B utiliza especialmente los objetos A
B tiene los datos de inicializacin que sern transmitidos a A cuando este
objeto sea creado (as que B es un Experto respecto a la creacin de A). B
es un creador de los objetos A.
? Si existe ms de una opcin, prefiera la clase B que agregue o

contenga la clase A.
UTFSM
N
I
EXUMBRA
SOLEM
324
42
Patrones de Diseo
Patrones de Diseo
Creador
Creador
? Ejemplo
? En la aplicacin del punto de venta, quin debera encargarse de

crear una instancia VentasLineadeProducto?
Descritas-por
cantidad
EspecificaciondeProductos
*
1..*
Contenidas-en
?Desde el punto de vista del patrn Creador, deberamos buscar una

clase que agregue, contenga y realice otras operaciones sobre este
tipo de instancias
1
Venta
fecha
hora
UTFSM
N
I
EXUMBRA
SOLEM
325
Patrones de Diseo
UTFSM
N
I
EXUMBRA
SOLEM
326
Patrones de Diseo
Creador
Creador
? Una Venta contiene (en realidad, agrega) muchos objetos

VentasLineadeProducto;
Segn
Controlador
? por ello, el patrn Creador sugiere que Venta es idnea para

asumir
la
responsabilidad
de
crear
las
instancias
VentasLineadeProducto.
Segn
Creador
introducirProducto(cup, cantidad)
1: [ nueva venta] crear()

: Venta
: TPDV
? Esta asignacin de responsabilidades requiere definir en

Venta un mtodo de hacer-LineadeProducto.
2: crear()
Segn Creador
UTFSM
N
I
EXUMBRA
SOLEM
327
UTFSM
N
I
EXUMBRA
SOLEM
Patrones de Diseo
Patrones de Diseo
? En ocasiones encontramos un patrn creador buscando la

clase con los datos de inicializacin que sern transferidos
durante la creacin.
? Problema
Creador
328
Bajo Acoplamiento
? Como dar soporte a una dependencia escasa y a un aumento de

la reutilizacin?
? El acoplamiento es una medida de la fuerza con que una clase est
conectada a otras clases, con que las conoce y con que recurre a ellas .
? Acoplamiento bajo significa que una clase no depende de muchas
clases.
? Acoplamiento alto significa que una clase recurre a muchas otras
clases. Esto presenta los siguientes problemas:
? ste es en realidad un ejemplo del patrn Experto.

? Los datos de inicializacin se transmiten durante la creacin a
travs de algn mtodo de inicializacin, como un constructor en
java que cuenta con parmetros.
?Los cambios de las clases afines ocasionan cambios locales

?Difciles de entender cuando estn aisladas
?Difciles de reutilizar puesto que dependen de otras clases
UTFSM
N
I
EXUMBRA
SOLEM
329
UTFSM
N
I
EXUMBRA
SOLEM
330
43
Patrones de Diseo
Patrones de Diseo
? Solucin
? Segn el patrn de Bajo Acoplamiento la relacin debera ser de la

siguiente manera:
Bajo acoplamiento
Bajo acoplamiento
? Asignar una responsabilidad para mantener bajo acoplamiento.
EfectuarPago( )
:TPDV
1:EfectuarPago ()
:Venta
? Ejemplo: En el caso del punto de ventas se tienen tres clases Pago,

TPDV y Venta y se quiere crear una instancia de Pago y asociarla a
Venta. Que clase es la responsable de realizarlo?
1.1:Crear()
:Pago
? Segn el patrn experto la Clase TPDV deber hacerlo

EfectuarPago( )
:TPDV
1:Crea()
P:Pago
2:AgregarPago(p)
UTFSM
N
I
EXUMBRA
SOLEM
? Esta ltima asociacin es mejor dado que Venta realiza la creacin del
Pago y no TPDV por lo tanto se reduce la dependencia de este ltimo
con el resto de las clases.
? El grado de acoplamiento no puede considerarse aisladamente de
otros principios como Experto y Alta Cohesin. Sin embargo, es un
factor a considerar cuando se intente mejorar el diseo.
:Venta
331
UTFSM
N
I
EXUMBRA
SOLEM
Patrones de Diseo
Patrones de Diseo
? En los lenguajes OO como C++ y JAVA las formas

comunes de acoplamiento de TipoX a TipoY son las
siguientes:
?Beneficios:
Bajo acoplamiento
332
Bajo acoplamiento
? No se afectan por cambios de otros componentes

? Fciles de entender por separado
? TipoX posee un atributo (miembro de datos o variable de instancia) que se

refiere a una instancia TipoY o al propio TipoY.
? Fciles de reutilizar
? TipoX tiene un mtodo que a toda costa referencia una instancia de TipoY
o incluso el propio TipoY. Suele incluirse un parmetro o una variable local
de TipoY o bien el objeto devuelto de un mensaje es una instancia de
TipoY.
? TipoX es una subclase directa o indirecta del TipoY.
? TipoY es una interfaz y TipoX la implementa.
UTFSM
N
I
EXUMBRA
SOLEM
333
Patrones de Diseo
UTFSM
SOLEM
Alta Cohesin
? Problema
? Solucin
? Cmo mantener la complejidad dentro de lmites menejables?
? Asignar una responsabilidad de modo que la cohesin siga siendo

alta
? La cohesin es una medida de cun relacionadas y enfocadas estn las

responsabilidades de una clase.
? Ejemplo: En el caso del punto de ventas se tienen tres clases Pago,

TPDV y Venta y se quiere crear una instancia de Pago y asociarla a
Venta. Segn el principio del patrn Creador la clase TPDV debe ser la
encargada de realizar el pago.
? Una alta cohesin caracteriza a las clases con responsabilidades

estrechamente relacionadas que no realicen un trabajo enorme.
? Una baja cohesin hace muchas cosas no afines o realiza trabajo excesivo.
Esto presenta los siguientes problemas:
EfectuarPago( )
? Son difciles de comprender

? Difciles de reutilizar
? Difciles de conservar
? Las afectan constantemente los cambios.
N
I
EXUMBRA
SOLEM
334
Patrones de Diseo
Alta Cohesin
UTFSM
N
I
EXUMBRA
:TPDV
1:Crea()
P:Pago
2:AgregarPago(p)
335
UTFSM
N
I
EXUMBRA
SOLEM
:Venta
336
44
Patrones de Diseo
Patrones de Diseo
? Qu pasa si el sistema tiene 50 operaciones, todas

recibidas por la clase TPDV ?
? Este diseo delega a Venta la responsabilidad de crear el pago.
Alta Cohesin
Alta Cohesin
? Este diseo es conveniente ya que da soporte a una alta cohesin y a

un bajo acoplamiento.
? La clase se ira saturando con tareas y terminara perdiendo la

cohesin
? En la prctica, el nivel de cohesin no puede ser considerado

independiente de los otros patrones y principios (e.g. Patrones
Experto y Bajo Acoplamiento)
? Un mejor diseo de lo anterior sera:

EfectuarPago( )
:TPDV
1:EfectuarPago ()
? Beneficios:
:Venta
?
?
?
?
1.1:Crear()
:Pago
UTFSM
N
I
EXUMBRA
SOLEM
337
Mejoran la claridad y facilidad con que se entiende el diseo

Se simplifica el mantenimiento y las mejoras de funcionalidad
A menudo se genera un bajo acoplamiento
Soporta mayor capacidad de reutilizacin.
UTFSM
N
I
EXUMBRA
SOLEM
Patrones de Diseo
Patrones de Diseo
? Algunos escenarios:
? Problema:
Alta Cohesin
338
Controlador
? Quin deber a encargarse de atender un evento del sistema?

? Muy baja cohesin: Una clase es la nica responsable de muchas cosas en
reas funcionales heterogneas.
? Un evento del sistema es un evento de alto nivel generado por un

actor externo; es un evento de entrada externa. Se asocia a
operaciones del sistema: las que emite en respuesta a los eventos del
sistema.
? Baja cohesin: Una clase tiene la responsabilidad exclusiva de una tarea

compleja dentro de un rea funcional.
? Por ejemplo, cuando un cajero que usa un sistema de terminal en el punto

de venta oprime el botn "Terminar Venta , est generando un evento
sistmico que indica que la venta ha terminado.
? Alta cohesin: Una clase tiene responsabilidades moderadas en un rea

funcional y colabora con las otras para llevar a cabo las tareas.
? Un Controlador es un objeto de interfaz no destinada al usuario que se

encarga de manejar un evento del sistema. Define adems el mtodo
de su operacin.
? Cohesin moderada: Una clase tiene peso ligero y responsabilidades

exclusivas en unas cuntas reas que estn relacionadas lgicamente con
el concepto de clase pero no entre ellas.
UTFSM
N
I
EXUMBRA
SOLEM
339
UTFSM
N
I
EXUMBRA
SOLEM
Patrones de Diseo
Patrones de Diseo
? Solucin
? Ejemplo:
Controlador
Controlador
? En la aplicacin del punto de venta se dan varias

operaciones del sistema, como se advierte en la
figura.
? Asignar la responsabilidad del manejo de un mensaje de los eventos

de un sistema a una clase que represente una de las siguientes
opciones:
? la empresa u organizacin global ( controlador de fachada).

? algo en el mundo real que es activo (por ejemplo, el papel de una
persona) y que pueda participar en la tarea (controlador de tareas).
? un manejador artificial de todos los eventos del sistema de un caso de
uso, generalmente denominados Manejador <NombreCasodeUso>
(controlador de casos de uso).
UTFSM
N
I
SOLEM
Sistema
terminarVenta( )
introducirProducto( )
efectuarPago( )
? Quin debera ser el controlador de eventos

sist micos
como
introducirProducto
y
terminarVenta?
? el sistema global ( controlador de fachada ).
EXUMBRA
340
introducirProducto(CUP, cantidad)
: ???
Qu clase debe encargarse

de manejar este mensaje de
eventos de sistema?
Un controlador
341
UTFSM
N
I
EXUMBRA
SOLEM
342
45
Patrones de Diseo
Patrones de Diseo
? De acuerdo con el patrn Controlador, disponemos de las

siguientes opciones:
? En la decisin de cul de las cuatro clases es el controlador

ms apropiado influyen tambin otros factores como la
cohesin y el acoplamiento.
Controlador
Controlador
representa el sistema global
TPDV
representa la empresa u organizaci n global
Tienda
representa algo en el mundo real que est activo

(por ejemplo, el papel de una persona) y que
puede intervenir en la tarea
Cajero
representa un manejador artificial de todas las

operaciones del sistema de un caso de uso.
ManejadordeComprarP
roductos
Sistema
UTFSM
N
I
EXUMBRA
SOLEM
terminarVenta( )
efectuarPago( )
operaciones del
sistema descubiertas
durante el anlisis de
su comportamiento
343
UTFSM
N
I
EXUMBRA
SOLEM
TPDV
terminarVenta( )
efectuarPago( )
asignacin de las
operaciones del sistema
durante su diseo, mediante
el patrn Controlador
344
Patrones de Diseo
Patrones de Diseo
? Explicacin: La mayor parte de los sistemas reciben

eventos de entrada externa, los cuales generalmente
incluyen una interfaz grfica para el usuario (IGU) operado
por una persona.
? Un defecto frecuente al disear controladores consiste en

asignarles demasiada responsabilidad. Normalmente un
controlador debera delegar a otros objetos el trabajo que
ha de realizarse mientras coordina la actividad.
Controlador
Controlador
? La misma clase controlador debera utilizarse con todos los

eventos sistmicos de un caso de uso, de modo que
podamos conservar la informacin referente al estado del
caso.
? Esta informacin ser til - por ejemplo - para identificar los
eventos del sistema fuera de secuencia (entre ellos, una operacin
efectuarPago antes de terminarVenta). Pueden emplearse varios
controladores en los casos de uso.
UTFSM
N
I
EXUMBRA
SOLEM
345
UTFSM
N
I
EXUMBRA
SOLEM
Patrones de Diseo
Patrones de Diseo
? Manejador artificial de casos de uso - un controlador

para cada caso.
? Beneficios
Controlador
Controlador
? Advirtase que ste no es un objeto del dominio, es un concepto

artificial, cuyo fin es dar soporte al sistema (una fabricacin pura,
en trminos de los patrones de GRASP).
? Por ejemplo, si la aplicacin del punto de venta contiene casos de
uso como Comprar Productos y Devolver Productos , habr una
clase ManejadordeComprarProductos y una clase
ManejadordeDevolverProductos .
? Es una alternativa que debe tenerse en cuenta, si el hecho de
asignar las responsabilidades en cualquiera de las otras opciones
de controlador genera diseos de baja cohesin o alto
acoplamiento. Esto ocurre generalmente cuando un controlador
empieza a saturarse con demasiadas responsabilidades.
UTFSM
N
I
EXUMBRA
SOLEM
346
347
? Mayor potencial de los componentes reutilizables. Garantiza que la

empresa o los procesos de dominio sean manejados por la capa de los
objetos del dominio y no por la de la interfaz.
? Reflexionar sobre el estado del caso de uso. A veces es necesari o
asegurarse de que las operaciones del sistema sigan una secuencia
legal o poder razonar sobre el estado actual de la actividad y las
operaciones en el caso de uso subyacente.
? Por ejemplo, tal vez deba garantizarse que la operaci n efectuarPago no
ocurra mientras no se concluya la operaci n terminarVenta . De ser as,
esta informaci n sobre el estado ha de capturarse en alguna parte; el
controlador es una buena opcin, sobre todo si se emplea a lo largo de
todo el caso.
UTFSM
N
I
EXUMBRA
SOLEM
348
46
Patrones de Diseo
Patrones de Diseo
Controlador
Controlador
? Un corolario importante del patrn Controlador es que los

objetos de la interfaz (por ejemplo, objetos de ventanas,
applets) y la capa de presentacin no deberan encargarse
de manejar los eventos del sistema.
Tienda de Objetos
CUP
Cantidad
Precio
Desc.
Total
Saldo
Ofrecido
Oprime botn
Introducir
Producto
Terminar
Venta
Efectuar
Pago
? Ntese que la clase

TPDVApplet - parte de la
capa de presentaci n transmite un mensaje
introducirProducto al objeto
TPDV.
Cajero
enIntroducirProducto()
Capa de presentacin
Applet en Java
: TPDVApplet
mensaje de eventos
del sistema
1: introducirProducto(cup, cantidad)
? No intervino en el proceso
de la operacin, ni la
decisi n de cmo
manejarla, el applet se
limit a delegarla a la capa
del dominio.
Controlador
2: hacerLineadeProducto(cup,cantidad)
Capa del Dominio
UTFSM
N
I
EXUMBRA
SOLEM
349
UTFSM
N
I
EXUMBRA
SOLEM
: TPDV
: Venta
Patrones de Diseo
Patrones de Diseo
? Patrones GRASP
? Qu define un patrn?
? Porqu se le asigna un nombre?
Resumen
350
Resumen
? Experto
? Creador
? Bajo Acoplamiento
? Alta Cohesin
? Controlador
? Qu significa GRASP?
? Existen casos cuando dos o ms patrones se aplican
juntos?
? Describa brevemente cada uno de estos patrones:
? Experto
? Creador
? Controlador
? Alta Cohesin
? Bajo Acoplamiento
UTFSM
N
I
EXUMBRA
SOLEM
351
UTFSM
N
I
EXUMBRA
SOLEM
352
Diseo de una Solucin
? Aplicacin de los patrones GRASP para asignar

responsabilidades a las clases.
? En la prctica, los diseadores se percatan de que la

preparacin de los diagramas de interaccin es uno de los
pasos ms lentos.
Contenido
Introduccin
? Uso de la notacin de UML en los diagramas de

colaboracin para describir grficamente el diseo de la
interaccin de objetos.
UTFSM
N
I
EXUMBRA
SOLEM
353
? La asignacin de responsabilidades y la elaboracin de los

diagramas de interaccin representan uno de los pasos
ms importantes en la fase de diseo.
UTFSM
N
I
EXUMBRA
SOLEM
354
47
Relacin entre artefactos
Diagramas de interaccin y eventos del sistema

? En la iteracin actual de la aplicacin del punto de venta
estamos considerando dos casos de uso y sus eventos
sistemticos asociados:
ContratoIntroducirProducto
:Sistema
: Cajero
? Comprar
Productos:
efectuarPago
? Inicio: inicio
Poscondiciones:
1. Si se trata de una nueva venta
se creo una nueva venta
: TPDV
introducirProducto
terminarVenta
terminarVenta ()
efectuarPago(EfectivoOfrecido )
? Por cada evento del sistema se construye un diagrama de

colaboracin cuyo mensaje inicial sea el de sus eventos.
efectuarPago(efectivoOfrecido)
ContratoEfectuarPago
Poscondiciones:
Contratos
Diagrama de secuencia del sistema
UTFSM
N
I
EXUMBRA
SOLEM
355
UTFSM
N
I
EXUMBRA
SOLEM
356
Diagramas de interaccin y contratos

? En cada contrato revisamos los cambios de estado de los
objetos responsables y las poscondiciones asociadas.
1 :???()
? Ntese que, en caso de omitir la preparacin del contrato, de todos

modos deberamos elaborar los diagramas de interaccin
retornando a los casos de uso y reflexionando sobre lo que
debemos lograr.
: TPDV
terminarVenta ()
Diagramas de interaccin y eventos del sistema
introducirProducto ()
? Habr, pues, cuatro diagramas de interaccin por lo menos: uno

por cada evento del sistema.
: TPDV
Diagrama de colaboracin
1 :???()
: TPDV
efectuarPago()
? No obstante, los contratos organizan y aslan la

informacin en un formato funcional, al mismo tiempo que
estimulan la investigacin en la fase de anlisis y no en la
de diseo.
1 :???()
: TPDV
iniciar()
1 :???()
: TPDV
UTFSM
N
I
EXUMBRA
SOLEM
357
UTFSM
N
I
EXUMBRA
SOLEM
? Por ejemplo, en esta operacin parcial del sistema

introducirProducto, en la figura incluimos un diagrama
parcial de colaboracin que satisface el cambio de estado
de la creacin de Venta.
? Los Diagramas deben prepararse con el propsito de

cumplir las poscondiciones del contrato.
UTFSM
N
I
EXUMBRA
SOLEM
? Poscondiciones definidas de antemano no son sino una excelente

conjetura o estimacin inicial de lo que se pretende alcanzar.
? En los contratos debemos ver un mero punto de partida para
establecer lo que se har, pero sin sentirnos obligados por ellos.
1:[ nueva venta] crear()

:TPDV
358
? Una ventaja del desarrollo iterativo radica en que brinda

un soporte espontneo a la deteccin de nuevos
resultados del anlisis y del diseo durante las fases de
solucin y de construccin
: Venta
359
UTFSM
N
I
EXUMBRA
SOLEM
360
48
Diagramas de interaccin y modelo conceptual
Diagramas de interaccin y modelo conceptual
Descrita-por
? Algunos de los objetos que interactan a travs de

mensajes en los diagramas de colaboracin provienen del
modelo conceptual.
*
cantidad
? En parte, la eleccin de la asignacin acertada de las

responsabilidades mediante los patrones GRASP se funda
en la informacin contenida en el modelo conceptual.
SOLEM
361
Tipo:
N
I
EXUMBRA
SOLEM
N
I
SOLEM
362
Seleccin de la clase Controlador
Contrato
IntroducirProducto ( cup:numero, cantidad:entero)
Sistema
Funciones del sistema: R1.1, R1.3, R1.6
Si el CUP no es vlido, indicar que se cometi un error.
Notas:
Excepciones:
Salida:
Precondiciones:
Poscondiciones:
? Si se trata de una nueva venta, se cre unaVenta (creacin de instancia).
? Si se trata de una nueva venta, la nueva Venta fue asociada a un TPDV ( asociacin
formada ).
? Se cre una instancia VentasLineadeProducto (creacin de instancia).
? Se asoci una instancia deVentasLineadeProducto a la Venta (asociacin formada ).
? Se asign una cantidad a VentasLineadeProducto.cantidad (modificacin de atributo).
? Se asoci una instancia
VentasLineadeProducto a la instancia
EspecificaciondeProducto, basado en la correspondencia del CUP (
asociacin
formada
UTFSM ).
1..*
TPDV
Diagrama de colaboracin: introducirProducto

Nombre:
Responsabilidades:
Aloja
UTFSM
EXUMBRA
*
Tienda
direcci
on
Pagado-por
N
I
*
Producto
Capturadas-en
EXUMBRA
1
Describe
Usado-por
Contenidas-en
Capturas-Terminada
Pago
1
1..*
1..*
Venta
fecha
hora
UTFSM
Contiene
1
CatalogoDeProductos
descripcion
precio
CUP
? En la eleccin del controlador que se encargue del mensaje de las

operaciones del sistema introducirProducto, disponemos de las
siguientes opciones:
? Representa el "sistema" global
? TPDV
? Representa la empresa u organizacin global

? Tienda
? Representa algo en el mundo real que est activo (por ejemplo, e l papel
de una persona) y que puede intervenir en la tarea
? Cajero
? Representa un manejador artificial de todas las operaciones del sistema de

un caso de uso.
? ManejadordeComprarProductos
363
UTFSM
N
I
EXUMBRA
SOLEM
? Un controlador de fachada como TPDV es adecuado
? Es importante darse cuenta que TPDV es una instancia

de un objeto en el territorio del software.
364
? si el sistema ofrece pocas operaciones y si ese controlador no

asume demasiadas responsabilidades (en otras palabras, si
empieza a perder cohesin).
? No es un terminal real de punto de venta, sino una abstraccin de

software que representa el registro
? Un controlador de papeles o de casos de uso ser una

decisin acertada
? cuando el sistema tiene demasiadas operaciones y queremos
distribuir las responsabilidades para que las clases controlador no
se atiborren, ni pierdan su orientacin central (o sea, que sean
cohesivas).
:TPDV
? En este caso, TPDV ser suficiente porque el sistema tiene

pocas operaciones.
UTFSM
N
I
EXUMBRA
SOLEM
365
UTFSM
N
I
EXUMBRA
SOLEM
366
49
? En virtud de un principio del diseo denominado

separacin de modelo - vista (Controlador), no compete a
los objetos del dominio (como TPDV o Venta) comunicarse
con la capa de interfaz para el usuario (las ventanas
grficas, por ejemplo).
? Poscondiciones contractuales establecen lo siguiente:
Presentacin visual de la descripcin y del precio
Realizacin de una nueva venta
? Si se trata de una nueva venta, se cre una Venta (creacin de

instancia).
? Si se trata de una nueva venta, se asoci la nueva Venta a TPDV
? Adems, cuando se crea la Venta, hay que generar una coleccin
vaca para que registre todas las instancias futuras
VentasLineadeProducto.
? Lo nico que se requiere en lo tocante a las

responsabilidades del despliegue de la informacin es
conocer los datos, como se ver en este caso.
UTFSM
N
I
EXUMBRA
SOLEM
367
UTFSM
N
I
EXUMBRA
SOLEM
368
Realizacin de una nueva venta
Creacin de una instancia VentasLineadeProducto

? Algunas
otras
poscondiciones
contractuales
introducirProducto establecen lo siguiente:
Segn
Controlador
Segn
Creador
? Se cre una instancia VentasLineadeProducto (creacin de

instancia).
? Se asoci VentasLineadeProducto a la Venta (asociacin formada).
? Se asign el valor a VentasLineadeProducto.cantidad de cantidad
(modificacin de atributo).
? Se asoci la instancia VentasLineadeProducto con una
EspecificaciondeProducto a partir de la correspondencia en el CUP
1: [nueva venta ] crear()

: Venta
: TPDV
2: crear()
Segn Creador
UTFSM
N
I
EXUMBRA
SOLEM
de
369
UTFSM
N
I
EXUMBRA
SOLEM
370
? Necesitamos asociar la instancia VentasLineadeProducto a

Especificaciondeproducto que concuerde con el CUP que se
recibe. Ello significa que se requiere recuperar una
EspecificaciondeProducto basada en la correspondencia del
CUP.
? Quin debera asumir la responsabilidad de conocer una

instancia EspecificaciondeProducto basado en que coincida
el valor del CUP?
? Un primer paso de gran utilidad es el siguiente:
? Quin est enterado de

EspecificaciondeProducto ?
Obtencin de instancia EspecifcaciondeProducto
Obtencin de instancia EspecifcaciondeProducto
? En la generalidad de los casos, el patrn Experto de GRASP es el

principio que ha de aplicarse en primer lugar.
UTFSM
N
I
SOLEM
371
lo
concerniente
? El anlisis del modelo conceptual revela que CatalogodeProductos

contiene lgicamente todas las especificaciones de productos y as,
de acuerdo con el patrn Experto, CatalogodeProductos es idneo
para asumir esta responsabilidad de consulta.
Comience asignando las responsabilidades definindolas con

claridad.
EXUMBRA
todo
UTFSM
N
I
EXUMBRA
SOLEM
372
50
? Quin debera enviar el mensaje especificacin al

CatalogodeProductos
para
solicitar
una
EspecificaciondeProducto ?
? Ello significa la existencia de otro concepto en el diseo

orientado a objetos: el de visibilidad.
? Es razonable suponer que una instancia TPDV y una de

CatalogodeProductos fueron creadas durante el caso inicial de uso
Inicio y que existe una conexin permanente entre el objeto TPDV
y el objeto CatalogodeProductos .
? La visibilidad es la capacidad de un objeto para 'ver' o

tener una referencia a otro. Para que un objeto enve a
otro un mensaje, debe ser visible al segundo.
Visibilidad ante un CatalogodeProductos
Visibilidad ante un CatalogodeProductos
? Supondremos que TPDV tiene una conexin o referencia

permanente a CatalogodeProductos ; por tanto, es visible para esta
instancia y de ah que pueda enviarle Mensajes como especificacin
? Esta suposicin nos permitir concluir que TPDV puede

enviar el mensaje especificacin a Catlogo de productos.
UTFSM
N
I
EXUMBRA
SOLEM
373
UTFSM
N
I
EXUMBRA
SOLEM
374
? En la versin final de una aplicacin real al punto de venta,

difcilmente todas las EspecificaciondeProducto estarn en
la memoria.
? El diagrama de colaboracin de la figura refleja las

decisiones sobre la asignacin de responsabilidades y
sobre la manera en que los objetos deberan interactuar.
Recuperacin de EspecificaciondeProducto
Diagrama de colaboracin introducirProducto
? Lo ms probable es que se encuentren almacenadas en una base

de datos relacional o de objetos y que sean recuperadas previa
solicitud.
? No obstante, para no hacer compleja la exposicin pospondremos
el estudio de los problemas concernientes a la recuperacin
partiendo de una base de datos.
? Observe que se reflexion detenidamente para llegar a l,

con base en los patrones GRASP.
? El diseo de las interacciones de los objetos y la asignacin
de responsabilidades requieren una seria deliberacin.
? Supondremos que todas las EspecificaciondeProducto se

hallan en la memoria. Ms tarde se tratar el tema del
acceso a la base de datos de objetos persistentes.
UTFSM
N
I
EXUMBRA
SOLEM
375
: Venta
1: [nueva venta ] crear()
4: crear()
2: especif :=especificacion(cup)
376
? La interpretacin predeterminada de un mensaje enviado a

un multiobjeto es que se enva implcitamente a todos los
elementos de la coleccin/contenedor, pero tambin puede
interpretarse como un mensaje dirigido al propio objeto
coleccin.
5: hacerLineadeProducto(especif,cant)
: TPDV
Mensajes a multiobjetos
Segn
Creador
introducirProducto(cup, cant)
SOLEM
Diagrama de colaboracin introducirProducto

Segn
Controlador
UTFSM
N
I
EXUMBRA
6: crear(especif,cant)
Segn Experto
7: agregar(vli)
: CatalogoDeProductos
3: especif :=encontrar(cup)
: EspecificaciondeProductos
UTFSM
N
I
EXUMBRA
SOLEM
377
UTFSM
N
I
EXUMBRA
SOLEM
378
51
? Por ejemplo, en el Diagrama de colaboracin

introducirProducto :
? Ejercicio:
Mensajes a multiobjetos
Diagrama de colaboracin terminarVenta
Desarollar el Diagrama de colaboracin para el caso de

trmino de una venta.
? El mensaje encontrar (3) enviado al multiobjeto

EspecificaciondeProducto se dirige una vez a la estructura de datos
coleccin representada por el multiobjeto.
? El mensaje crear (4) enviado al multiobjeto VentasLineadeProducto
tiene por objeto generar la estructura de datos coleccin
representada por el multiobjeto; su finalidad no es crear una
instancia de la clase VentasLineadeProducto.
? El mensaje agregar (7) enviado al multiobjeto
VentasLineadeProducto tiene por objeto incorporar un elemento a
la estructura de datos coleccin representada por el multiobjeto.
UTFSM
N
I
EXUMBRA
SOLEM
379
Tipo:
Contrato
terminarVenta()
Registrar que se termin de capturar los artculos de la venta ypresentar
visualmente el total de la venta.
Sistema
Funciones del sistema: R1.2.
Casos de uso: Comprar Productos.
Utilizar el accesosuperrpido a la base de datos.
Si est efectundose una venta, indicar que se cometi un error.
Notas:
Excepciones:
Salida:
Precondiciones:
Poscondiciones:
Se asign a Venta.estaTerminada el valor verdadero(modificacin de atributo).
UTFSM
N
I
EXUMBRA
SOLEM
380
Clculo del total de la venta: Solucin
Venta - total
{
tot:= 0
para cada VentasLineadeProducto , vli
tot:= tot+vli.subtotal()
devolver tot
}
Nombre:
Responsabilidades:
Diagrama de colaboracin: Iniciar

? Cundo crear el diagrama de colaboracin Iniciar?
? La mayora de los sistemas, si no es que todos, tienen un caso de
uso Iniciar y alguna operacin inicial relacionada con el comienzo
de la aplicacin. Aunque es la primera en ser ejecutada, se ha
considerado la conveniencia de posponer la preparacin del
respectivo diagrama de colaboracin hasta despus de considerar
el resto de las operaciones del sistema.
1: * [para cada]vli: =siguiente ()

tot:=total()
2: s t :=sutotal()
: Venta
Segn
Experto
? Prepare al final el diagrama de colaboracin Iniciar.
Segn Experto
3: pre:=prec()
VentasLineadeProducto - subtotal()
{
devolver cantidad*EspecifPro.precio()
}
UTFSM
N
I
EXUMBRA
SOLEM
EspecifPro : EspecificaciondeProductos
381
UTFSM
N
I
EXUMBRA
SOLEM
? El diagrama de colaboracin de la operacin Iniciar

describe lo que sucede cuando se crea el objeto inicial del
dominio del problema y, opcionalmente, lo que sucede si
asume el control.
? Por tanto la operacin Iniciar puede interpretarse as:
? En un diagrama de colaboracin, enve un mensaje crear() para

producir el objeto inicial del dominio.
? (opcional) Si el objeto inicial va a asumir el control del proceso,
en un segundo diagrama de colaboracin envele un mensaje
ejecutar (u otro equivalente).
? No incluye ninguna actividad anterior ni subsecuente en

la capa de objetos destinada a la interfaz grfica para el
usuario, si es que existe.
UTFSM
N
I
EXUMBRA
SOLEM
382
383
UTFSM
N
I
EXUMBRA
SOLEM
384
52
? Cul debera ser la clase del objeto inicial del dominio?

? Escoja como objeto inicial del dominio:
Contrato
Nombre:
IniciarO.
Responsabilidades:
Inicializar el sistema.
Tipo:
Sistema
Notas:
Excepciones:
Salida:
Precondiciones:
Poscondiciones:
? Se crearon Tienda , TPDV , CatalogodeProductos y EspecificaciondeProducto (creacin
de instancia).
? Se asoci CatalogodeProductos a EspecificaciondeProducto (asociacin formada).
? Se asoci Tienda a CatalogodeProductos (asociacin formada)
? Se asoci Tienda a TPDV (asociacin formada).
? Se asoci TPDV a CatalogodeProductos (asociacin formada).
? Una clase que represente todo el sistema de informacin lgico.

? Una clase que represente ntegramente el negocio u organizacin.
? En la seleccin de estas opciones pueden influir consideraciones

referentes a los patrones Alta Cohesin y Bajo Acoplamiento.
? Todo
el
Sistema
de
informacin
SistemaInformacionalmenudeo
? Negocio u organizacin global: Tienda
lgico:
TPDV,
? En esta aplicacin se escogi la Tienda como objeto

inicial.
UTFSM
N
I
EXUMBRA
SOLEM
385
6: crear(cp)
SOLEM
? Una discrepancia interesante entre el anlisis y el diseo

se ejemplifica en el hecho de que la Tienda slo crea un
objeto TPDV .
Transmite una referencia a Catalogo de

Productos de modo que sea
permanentemente visible a TPDV
: TPDV
? Desde el punto de vista analtico, una tienda real puede albergar

muchas terminales en el punto de venta. Pero ahora estamos
considerando un diseo de software, no lo que ocurre en el mundo
real.
? La Tienda y TPDV representada en un diagrama de colaboracin no
es una tienda real; es un objeto de software.
? En nuestros requerimientos actuales, el objeto de SW Tienda no
necesita crear ms que una sola instancia del objeto de SWTPDV.
3: cargarEspecifPro()
1: crear()
2: * crear()
: EspecificaciondeProducto
cp : CatalogoDeProductos
UTFSM
N
I
EXUMBRA
SOLEM
386
: Tienda
* indica que le mensaje

ocurre en la seccin de
manera repetida o iterativa
crear()
UTFSM
N
I
EXUMBRA
5: agregar(ep)
ep : EspecificaciondeProducto
4: * crear(cup, precio, descripcion)
387
UTFSM
N
I
EXUMBRA
SOLEM
388
? Aplicacin de los patrones GRASP para asignar

responsabilidades a las clases.
? Cul es la utilidad del contrato para diagramas de

interaccin?
? Cul es la utilidad del modelo conceptual para diagramas
de interaccin?
? Cuando se prepara el contrato para el caso de uso
Iniciar?
Resumen
Quiz
? Uso de la notacin de UML en los diagramas de

colaboracin para describir grficamente el diseo de la
interaccin de objetos.
? En qu ayudan los patrones?

? Cual es el orden de aplicacin de los patrones vistos?
UTFSM
N
I
EXUMBRA
SOLEM
389
UTFSM
N
I
EXUMBRA
SOLEM
390
53

Analisis y Diseño Orientado A Objetos

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Analisis y Diseño Orientado A Objetos

Enviado por

Direitos autorais:

Formatos disponíveis

Anlisis y diseo orientado a objetos

Anlisis y diseo orientado a objetos

? El proverbio El hbito no hace el monje se aplica

? El hecho de conocer un lenguaje orientado a objetos (por ej. Java)

Anlisis y diseo orientado a objetos

Anlisis y diseo orientado a objetos

? En conclusin, se ayudar a los ingenieros:

? El anlisis se centra en la investigacin del problema, no

Qu son anlisis y diseo?

? A aplicar los principios y patrones para aprender a desarrollar

? Por ejemplo, si se necesita un nuevo sistema de biblioteca, Cules

? El diseo pone de relieve una solucin lgica: cmo el

? Todo lo anterior ser ejemplificado con un caso.

? De qu manera el sistema de la biblioteca capturar y registrar

? La esencia de estas actividades consiste en situar el

Anlisis y diseo orientado a objetos

Qu son anlisis y diseo?

? Durante el anlisis orientado a objetos se procura ante

? Durante el diseo orientado a objetos, se procura definir

Anlisis y diseo orientado a objetos

Qu son anlisis y diseo?

Anlisis y diseo orientado a objetos

Anlisis y diseo orientado a objetos

? Para entender los requerimientos se necesita, en parte,

Anlisis y diseo orientado a objetos

? Caso de uso: Juega un juego

Anlisis y diseo orientado a objetos

? Por ejemplo, en el juego de los dados:

? Dichos procesos se pueden expresar en forma de casos de

? Por ejemplo, una parte del modelo conceptual muestra los

? Para descomponer el dominio del problema hay que

Anlisis y diseo orientado a objetos

Anlisis y diseo orientado a objetos

? El modelo conceptual no es una descripcin de los

? El diseo orientado a objetos tiene por objetivo definir las

Anlisis y diseo orientado a objetos

Anlisis y diseo orientado a objetos

? Por ejemplo, la figura muestra grficamente el paso

? En el anlisis y diseo estructurado, la dimensin de

? Los proyectos de software son complejos, y la estrategia

Comparacin con AD estructurado

? A diferencia del modelo conceptual, el modelo de diseo

Anlisis y diseo orientado a objetos

Anlisis y diseo orientado a objetos

? Por ejemplo, obtenemos que Jugador requiere de un

? Cmo se conectan unos objetos a otros?

Anlisis y diseo orientado a objetos

Introduccin al proceso de desarrollo

Comparacin con AD estructurado

? Un proceso de desarrollo de software es un mtodo de

? El lenguaje UML estandariza los artefactos y la notacin,

? Aumentar las posibilidades de aceptacin generalizada de la

Introduccin al proceso de desarrollo

Introduccin al proceso de desarrollo

? En un nivel alto, los pasos principales de la presentacin

? Un ciclo de vida iterativo se basa en el agrandamiento y

? Planificacin y elaboracin: planificar, definir los

? Tras una fase preliminar de planificacin y especificacin, el

? Construccin: la creacin del sistema.

Introduccin al proceso de desarrollo

Introduccin al proceso de desarrollo

? En cada ciclo se aborda un conjunto relativamente

? El sistema va creciendo con cada ciclo que se concluye.