Rup Uml 4diapositivas

Introduccin a la Ingeniera de Software
Conceptos bsicos de Ingeniera de Software
El trmino Ingeniera de Software surge a final de los a os

60 dentro de una conferencia dedicada a la crisis del
software
Ingeniera del Software es un conjunto de m todos,
herramientas y procedimientos para producir software de
gran calidad [R. Pressman]
Dra. Lioubov Dombrovskaia
?
?
El objetivo de la Ingeniera de Software es producir

productos software
Productos software: sistemas de software junto a la
documentacin que describe como instalar y usar el
sistema
Los productos software caen en dos categoras:
?
Productos genricos: Desarrollados por una organizacin para un

mercado abierto (Microsoft Office)
? Productos a medida: Encargados por un cliente (Sistema
Facturacin Energas)
Factores de calidad de Software
Los mtodos describen cmo construir tcnicamente el

software
Mtodos
?
Comprende las actividades de:

?
?
?
?
?
?
?
?
Planificacin y estimacin de proyectos

Anlisis de requisitos
Ingeniera
Ingenier
Diseo
de Software
Codificacin
Prueba
Herramientas
Procedimientos
Mantenimiento
La calidad de software puede ser descrita mediante una

serie de factores:
?
?
Externos: observables por los usuarios del producto

Internos: observables por profesionales de la computaci n
Las herramientas dan soporte automtico o

semiautom tico a los mtodos
Los procedimientos relacionan formalmente los mtodos y
las herramientas
Factores de calidad externos:

?
Correcci n: Capacidad de los productos software de ejecutar

exactamente sus tareas tal cmo estn definidas en su
especificaci n de requerimientos
? Robustez: Capacidad de un sistema software para funcionar en
situaciones anormales
? Modificabilidad: Facilidad de un producto para adaptarse al cambio
de especificaciones
? Reusabilidad: Facilidad para ser reutilizado en todo o en parte para
nuevas aplicaciones
Compatibilidad: Facilidad de los productos software para

combinarse unos con otros
? Eficiencia: Buen uso de los recursos Software y Hardware
disponibles
? Portabilidad: Facilidad para adaptarse a otros entornos software o
hardware
? Verificabilidad: Facilidad para preparar procedimientos de
aceptaci n, en particular datos de prueba, para detectar fallos
durante las fases de validacin y operacin
Ciclo de vida de Software
Ciclo de vida: Sucesin de etapas por las que atraviesa un

producto software a lo largo de su desarrollo y existencia
Existen distintas formas o paradigmas de ciclo de vida:
Integridad: Capacidad de un sistema para proteger sus documentos

(programas, datos) contra accesos y modificaciones no autorizados
? Facilidad de uso: Capacidad de aprender a manejar un sistema
software, operar con el, preparar datos de entrada, interpretar
resultados, etc.
?
Clsico
Clsico con prototipado
? En espiral
? Prototipado puro
? Combinacin de estilos, etc.
?
Factores de calidad internos:

?
Modularidad: Independencia funcional de los componentes del

programa
? Legibilidad: Facilidad de lectura e interpretacin del cdigo del
programa
Ciclo de vida clsico ideal fue propuesto por W. Royce a

principios de los aos 70
?
?
El ciclo de vida clsico real tiene la siguiente forma:
Aplicacin secuencial de una serie de pasos

Cada paso genera entradas y documentacin para el siguiente
Anlisis
Diseo
Codificacin
Pruebas
Unitarias
Anlisis
Diseo
Codificaci n
Integracin
Pruebas de
Integracin
Pruebas de
aceptaci n
A todas las fases

Mantenimiento
Crticas al ciclo de vida clsico:
Proyectos raramente siguen el flujo secuencial

? Dificultad para establecer los requerimientos al principio del
proceso
? Errores detectados tard amente
? Mantenimiento por parcheado
?
Prototipear consiste en construir una versin inicial de un

producto sin implementar completamente la funcionalidad
del sistema
Clases de prototipos:
?
Vertical: desarrolla completamente algunas de las facetas del

producto
? Horizontal: desarrolla parcialmente todas las facetas del producto
? Evolutivo: la versi n final es el producto ya construido
? Desechable: se usa slo para la captacin de requerimientos y
funcionalidad
Corregir segn se presenten los problemas
10
11
12
Especificacin
Utilidad del prototipo

desechable:
Facilita la captacin de los requerimientos del cliente

Reduce el riesgo de parcheado del producto final
? La construcci n del prototipo supone una inversi n adicional
? El cliente ve funcionando una versi n de lo que ser su programa
sin asumir que dicha versi n no es robusta ni completa
?
Construccin
del Prototipo
Ayuda a los analistas a establecer

las necesidades del cliente
? Ayuda a los desarrolladores a
mejorar los productos
Anlisis
Observaciones sobre el prototipeado:
Validacin
Diseo
13
Proceso evolutivo (espiral)

Determinar
objetivos, alternativas y
restricciones
REVISIN
Plan de requerimientos
Plan de ciclo de vida
Plan de
desarrollo
Planificar la siguiente
fase
Integracin y
plan de prueba
Evaluar alternativas e
identificar y resolver
riesgos
Anlisis de
riesgos
Anlisis de
riesgos
Anlisis de
Prototipo
Prototipo operacional
riesgos
3
Prototipo
Anlisis
2
de Protoriesgos tipo 1
Simulaciones, modelos,
Concepto
pruebas comparativas
de
Requerioperacin mientos de Diseo del Diseo
producto detallado
Validacin de software
Cdigo
requerimientos
Prueba de
Diseo de
unidades
Desarrollo, verificar
Prueba de
V&V
producto del siguiente
Prueba de integracin
nivel
aceptacin
Servicio
Sistemas OO tienden a evolucionar en el tiempo

Modelo evolutivo de proceso acoplado es el mejor
paradigma para la Ingeniera del SW OO
?
15
14
fomenta el ensamblaje (reutilizaci n) de componentes
16

?
La Ingeniera de Software es la disciplina tecnolgica

relacionada con la produccin sistem tica y el
mantenimiento de productos software que son
desarrollados y modificados en el tiempo previsto y dentro
de los costos estimados
?
Por producto software se entiende:

?
?
?
?
?
?
?
?
Documentacin de requerimientos
Documentacin de diseo
Cdigo fuente
Planes de pruebas del sistema
Principios de operacin
Instrucciones de instalacin
Procedimientos de mantenimiento
Manuales de usuario
Aunque los computadores han tenido mucho xito, la

experiencia diaria de uso de computadores es asociada
muchas veces con dificultad, pena y otras barreras para la
mayora de la gente... La falta de usabilidad del software y
un diseo pobre de los programas son una vergenza
secreta de la industria.
?
Mitchell Kapor, Software Design Manifesto, 1990
17
Introduccin a Orientacin a Objetos
Quiz
Conceptos
Explique las causas del fenmeno definido en el dibujo
?
?
18
Qu es un objeto?
El mundo est lleno de objetos:
?
en la naturaleza
en entidades hechas por el hombre
? y en los productos que usamos
?
Lo que el usuario pidi
Lo que el analista vio
Como el sistema fue diseado
Como el programador lo escribi
Lo que el usuario realmente quera

Pueden ser clasificados, descritos, organizados,

combinados, creados y manipulados
Es por ello que se utiliza una visin Orientada a Objeto
para la creacin de SW
Como realmente funciona

19
20
Conceptos
Conceptos
Ejemplo del concepto de Orientacin a Objetos

?
?
Un objeto del mundo real: una silla

La silla es un miembro (instancia) de una clase mucho ms grande
de objetos que llamaremos mueble
Un conjunto de atributos genricos

pueden asociarse con cada objeto, en
la clase mueble
?
Por ejemplo, todo mueble tiene un costo,

dimensiones, peso, localizacin y color,
entre otros muchos posibles atributos
? Estos atributos tambin son aplicables a
una mesa o silla, un sof o un armario
?
Mueble
Como silla es miembro de la clase

mueble, silla hereda todos los atributos
definidos para la clase
21
Costo
Dimensiones
Peso
Localizaci n
Color
Comprar
Vender
Pesar
Mover
silla:Mueble
Costo: 30.000
Dim: 100x60x40
Peso: 5
Loc.:A110
Color: burdeo
Comprar
Vender
Pesar
Mover
Conceptos
Principios
Todo objeto de la clase mueble puede manipularse de

varias maneras, comprarse y venderse, modificarse
fsicamente o mover de un lugar a otro
Cada una de estas operaciones (servicios o m todos)
modificar uno o m s atributos del objeto. Por ejemplo, si
el atributo localizacin es un dato compuesto definido
como:
localizacin = edificio + piso + habitacin
?
?
?
En general, los objetos encapsulan datos, operaciones,

otros objetos, constantes y otra informacin relacionada
El encapsulamiento significa que toda la informacin se
encuentra empaquetada en una entidad
?
entonces una operacin denominada movermodificara uno o ms

de los elementos que conforman el atributo
23
22
Los datos pueden ser accesados exclusivamente por las

operaciones definidas en el objeto quedando ocultos para las
operaciones de otros objetos no pertenecientes a la misma clase
(caja negra)
Una definicin de Orientacin a Objetos es de la

siguiente forma:
Orientacin a Objetos = objetos + clasificacin + herencia +
comunicacin
24
Principios
Principios
Un modelo OO de SW computacional debe exhibir

abstracciones de datos y procedimientos que conducen a
una modularidad eficaz
Una clase es un concepto OO que encapsula las

abstracciones de datos y procedimientos que se requieren
para describir el contenido y comportamiento de alguna
entidad del mundo real (y objetos derivados de una clase)
Las abstracciones de datos (atributos) que describen la

clase estn encerradas por una muralla de abstracciones
procedimentales capaces de manipular los datos de alguna
manera (encapsulamiento)
Clase
Operaciones
Atributos:
Atributos
Operaciones:
25
Principios
Jerarqua
?
?
Encapsulamiento posibilita el ocultamiento de informacin

y reduce el impacto asociado a cambios
Como los mtodos manipulan un n mero limitado de
atributos (alta cohesin) y como la comunicacin slo
ocurre a travs de los m todos que encierra la muralla, la
clase tiende a un bajo acoplamiento con otros elementos
del sistema
Todas estas caractersticas conducen a un SW de alta
calidad
27
?
?
26
Clase: coleccin de objetos similares, los cuales heredan

atributos y operaciones disponibles para la manipulacin
de stos
Superclase: coleccin de clases
Subclase: instancia de una clase
Estas definiciones implican la existencia de una jerarqua
de clases, en la cual los atributos y operaciones de la
superclase son heredados por subclases que pueden
aadir atributos privados y mtodos
28
Jerarqua
Atributos
Mueble
Superclase
Los atributos estn asociados a clases y objetos,

describindolos de alguna manera
?
Un atributo puede tomar un valor definido por un dominio

enumerado
?
Subclases de la
clase mueble
Mesa
Silla
Escritorio
Sillesa
Una clase auto tiene atributo color. El domino de valores de color es

{blanco, negro, azul, rojo, amarillo, verde}
En situaciones ms complejas, el dominio puede ser un conjunto

de clases
?
La clase auto tambin tiene un atributo motor que abarca los siguientes
valores de dominio: {valor 32 vlvulas opcin de lujo, valor 24 vlvulas
opcin deportiva, valor 15 opcin econmica}
Estas caractersticas se representan como asociaciones, no atributos
Instancias de Silla
29
Operaciones, mtodos o servicios
Mensajes
Un objeto encapsula datos y algoritmos que procesan

estos datos
Cada operacin proporciona uno de los comportamientos

del objeto
Convencionalmente, algoritmos pueden ser vistos como mdulos
La operacin se ejecuta en respuesta a un estmulo mensaje

?
Un mensaje estimula la ocurrencia de cierto comportamiento en el

objeto receptor, el cual comienza con la ejecuci n de una
operacin
Una operacin dentro de un objeto emisor genera un

mensaje de la forma:
?
?
Cada vez que un objeto recibe un estmulo se inicia un

comportamiento, el cual puede ser simple o complejo, como la
iniciaci n de una cadena de estmulos que pasan entre una
variedad de objetos diferentes
Mensaje es el medio a travs del cual los objetos

interactan
?
Por ejemplo, la operaci n determinar color para el objeto automvil

extraer el color almacenado en el atributo color
31
30
mensaje:[destino, operacin, parmetros]

donde destino define el objeto receptor, operacin se refiere al mtodo
que recibe el mensaje y parmetros proporciona informacin requerida
para el xito de la operacin
32
Mensajes
Mensajes
A
op1
op2
op3
op4
op5
Por ejemplo, si el objeto B requiere el proceso asociado con la

operacin op10 del objeto D, el primero enviar a D un mensaje
que contendra: mensaje: [D, op10,<datos>]
? Como parte de la ejecuci n de op10, el objeto D puede enviar un
mensaje al objeto C de la forma: mensaje: [C, op08,<datos>]
? C encuentra op08, la ejecuta, y entonces enva un valor de retorno
apropiado a D. La operacin op10 completa su ejecuci n y enva
un valor de retorno a D
Valor de retorno
D
Mensaje
op10
op11
op6
op7
op8
op9
Los cuatro objetos A,B,C y D se comunican unos con otros

a travs del paso de mensajes
Valor de retorno
33
Encapsulamiento, herencia y polimorfismo
Sistemas OO poseen tres caractersticas que los hacen

nicos
?
Los detalles de implementacin interna de datos y procedimientos

estn ocultos al mundo exterior
Una subclase Y hereda todos los atributos y operaciones de su

superclase X
?
Encapsulamiento
?
Una de las diferencias claves entre sistemas OO y

sistemas convencionales es la herencia
?
Ocultamiento de la Informacin
?
Las estructuras de datos y las operaciones que las manipulan estn

mezcladas en una entidad sencilla: la clase, lo que facilita la
reutilizacin de componentes
Interfaces simples entre los objetos

?
Un objeto que env a un mensaje no debe preocuparse de los detalles

de estructuras de datos internas del objeto receptor, lo que simplifica la
interaccin y el acoplamiento del sistema tiende a reducirse
35
34
Todas las estructuras de datos y algoritmos originalmente diseados e

implementados para X estn inmediatamente disponibles para Y,
realizndose la reutilizacin en forma directa
Cualquier cambio dentro de una superclase se hereda inmediatamente
por todas las subclases que derivan de ella
En cada nivel de la jerarqua de clases pueden aadirse nuevos

atributos y operaciones a aquellos que han sido heredados de
niveles superiores de la jerarqua
36
X1
Cada vez que se debe crear una nueva clase se tienen

varias opciones:
?
No utilizar la herencia, es decir, disear y construir la clase de la

nada
? Puede rastrear la jerarqua de clase para determinar si una clase
ascendiente contiene la mayora de los atributos y operaciones
requeridas
? Puede reestructurar la jerarqua de clases de tal manera que los
atributos y operaciones requeridas puedan heredarse de la nueva
clase
? Puede sobrescribir las caractersticas de una clase existente e
implementar versiones privadas de atributos u operaciones para l a
nueva clase

?
Para derivar sta clase

llamada X2b en el ejemplo, la
jerarqua debe reestructurarse
car1
car2
car3
car4
car5
+car6
X4
car1
car2
car3
car4
car5
car6
car1
car2
car3
car4
car5
car7
car1
car2
car3
car4
car1
car2
car3
car4
car5
+car6
X2b
+car7
car1
car2
car3
car4
car5
car6
car1
car2
car3
car4
car5
car7
39
A veces la reestructuracin de la jerarqua puede ser difcil,

se usa la anulacin
?
+car8
car1
car2
car3
car4
car8
X4
38
car1
car2
car3
X3
X1
+car4
+car5
+car7
X3
La jerarqua de clases
mostrada permite derivar las
clases X3 y X4 con las
caractersticas (atributos u
operaciones) 1, 2, 3, 4, 5 y
6, y 1, 2, 3, 4, 5 y 7,
respectivamente
Ahora, suponga que se
desea crear una nueva
clase que tenga solamente
caractersticas 1, 2, 3, 4 y 8
X2
X2a
+car4+car5
X2
37
car1
car2
car3
La anulaci n ocurre cuando los atributos u operaciones se heredan

de forma normal, pero despus son modificados segn las
necesidades especficas de la nueva clase
A veces, es tentador heredar algunos atributos y

operaciones de una clase y otros de otra clase, sta accin
es conocida como herencia m ltiple, lo cual complica la
jerarqua de clases y puede crear problemas potenciales
en el control de la configuracin
40
10


?
?
El polimorfismo es una caracterstica que reduce en gran

medida el esfuerzo necesario para extender un sistema
Considere una aplicacin convencional que debe dibujar
cuatro tipos diferentes de grficos:
?
?
?
?
grficos de lneas
grficos de tortas
histogramas
diagramas de Kiviat
Idealmente una vez recogidos los datos para un grfico particular,

ste debe dibujarse a s mismo
En una aplicacin convencional ser necesario desarrollar

mdulos de dibujos para cada tipo de grficos y aadir una
lgica de control semejante a la que sigue:
case of tipo_grafico:
If tipo_grafico = grafico_linea then DibujarLinea (datos);
If tipo_grafico = grafico_torta then DibujarTortaLinea (datos);
If tipo_grafico = grafico_histograma then DibujarHisto (datos);
If tipo_grafico = grafico_kiviat then DibujarKiviat (datos);
end case
41
Introduccin a UML
UML = Unified Modeling Language
Para resolver este problema en un sistema OO, cada uno

de los grficos mencionados se convierte en una subclase
de una clase general llamada grfico
?
Modelado Orientado a Objetos

Modelado de Datos
? Modelado de Componentes
? Modelado de Flujos de Trabajo (Workflows)
?
tipo_grafico.dibujar
Si se debe aadir un nuevo tipo de grfico, slo se debe crear una

subclase con su propia operacin dibujar
UML responde a la necesidad de una notacin estndar

?
Polimorfismopermite que un n mero de operaciones

diferentes tengan el mismo nombre, haciendo que cada
objeto sea ms independiente
UML es un lenguaje de propsito general para el modelado

orientado a objetos, que combina notaciones provenientes
desde:
?
Un objeto puede enviar un mensaje dibujar a cualquier objeto, el

objeto receptor invocar su propia operaci n dibujar para crear el
grfico apropiado:
?
42
43
Diversos mtodos y tcnicas OO eran inconvenientes para el

aprendizaje, aplicaci n, construccin y uso de herramientas, etc.
44
11
Introduccin a UML
Introduccin a UML
Historia
UML incorpora diferentes enfoques
?
?
?
?
Rumbaugh
UML comenz como el Mtodo Unificado, presentado en

la OOPSLA95 por Grady Booch y Jim Rumbaugh
El mismo ao se uni Ivar Jacobson, con lo cual los Tres
Amigos son socios en la compaa Rational Software, que
han desarrollado una herramienta CASE Rational Rose
Noviembre de 1997 UML 1.3 es aprobado por el Object
Managment Group (OMG)
Junio de 2003 UML 2.0 es oficialmente adoptado por
OMG
Booch
Jacobson
Odell
Meyer
Pre- and Post-conditions
Shlaer-Mellor
UML
Object life cycles
Harel
State Charts
Gamma et. al.

Frameworks, patterns,
notes
Embly
Wirfs-Brock
Singleton classes
Fusion
Responsabilities
Operation descriptions,
message numbering
45
Introduccin a UML
Introduccin a UML
Pros y contras
Modelado Visual con UML y Rational Rose
Aspectos Novedosos de UML
Definicin semi-formal del Meta-Modelo semntico asociado

? Incluye estereotipos como mecanismo de extensibilidad.
?
Un componente particular se adapta a las necesidades del contexto
Incluye un lenguaje para expresar restricciones mediante frmulas

bien formadas
46
El objetivo de UML es describir cualquier tipo de sistema

en trminos de diagramas orientados a objetos, o sea, es
crear un modelo
Un modelo es una descripcin completa de un sistema
desde una perspectiva concreta
OCL (Object Constraint Language) desarrollado por IBM
Inconvenientes en UML
?
Definicin del proceso de desarrollo usando UML. UML no es una

metodologa
? Falta integracin con respecto de otras tcnicas tales como
patrones de diseo, interfaces de usuario, documentacin, etc.
47
48
12
Introduccin a UML
Anlisis y diseo orientado a objetos
Modelado Visual con UML y Rational Rose
Muestra
Diagramas de
Secuencia
Diagramas de
Colaboracin
Diagramas de
Casos de Uso
Diagramas
de Clases
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
Diagramas
de Objetos
Modelo del
Sistema
Diagramas de
Estados
El proverbio El hbito no hace el monje se aplica

perfectamente a la tecnologa de objetos
Diagramas de
Componentes
Diagramas de
Actividad
Diagramas de
Distribucin
49
50

Qu son anlisis y diseo?
En conclusin, se ayudar a los ingenieros:
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
?
El anlisis se centra en la investigacin del problema, no

en la manera de definir la solucin
?
Todo lo anterior ser ejemplificado con un caso
El diseo pone de relieve una solucin lgica: cmo el

sistema cumple con los requerimientos
?
51
Por ejemplo, si se necesita un nuevo sistema de biblioteca,

Cules procesos de la instituci n se relacionan con su uso?
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
52
13
?
?
Durante el anlisis orientado a objetos se procura ante

todo identificar y describir los objetos o conceptos
dentro del dominio del problema
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
Anlisis
Libro
ttulo
Concepto de
Dominio
53
Diseo
Construccin
public class Libro
{
public void print();
Private String titulo;
}
Representacin
en el diseo
Representacin en
programacin
54
Ejemplo
Ejemplo
Definici n de los
Casos de Uso
Definici n del
Modelo
del Dominio
Definici n de los
Diagramas de
Interaccin
Definici n de los
Diagramas de
diseo de clases
Definici n 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
Dichos procesos se pueden expresar en forma de casos
de uso
Definici n del
Modelo
del Dominio
Definici n de los
Diagramas de
Interaccin
Definici n de los
Diagramas de
diseo de clases
Por ejemplo, en el juego de los dados:

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
Caso de uso es una descripcin narrativa del proceso de

dominio en un formato estructurado de prosa
55
56
14
Ejemplo
Ejemplo
Definici n de los
Casos de Uso
Definici n del
Modelo
del Dominio
Definici n de los
Diagramas de
Interaccin
Definici n de los
Diagramas de
diseo de clases
Definici n de los
casos de uso
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 del dominio,
el cual muestra grficamente en un grupo de diagramas
que describen los conceptos y objetos
Definici n del
Modelo
del Dominio
Definici n de los
Diagramas de
Interaccin
Definici n de los
Diagramas de
diseo de clases
Por ejemplo, una parte del modelo del dominio muestra los
conceptos de Jugador, Dados y Juego de dados, sus
asociaciones y atributos
Jugador
Dado
1
Lanza
nombre
2
valorMostrado
1
Juega
1
Juego de dados
1 Incluye
57
58
Ejemplo
Ejemplo
Definici n de los
casos de uso
Definici n del
Modelo
del Dominio
Definici n de los
Diagramas de
Interaccin
Definici n de los
Diagramas de
diseo de clases
Definici n de los
casos de uso
El modelo del dominio no es una descripcin de los

componentes de software; representa conceptos en el
dominio del problema del mundo real
59
Definici n del
Modelo
del Dominio
Definici n de los
Diagramas de
Interaccin
Definici n 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 es asignar las 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
60
15
Ejemplo
Ejemplo
Definici n de los
casos de uso
Definici n del
Modelo
conceptual
Por ejemplo, la
figura muestra
grficamente el
paso esencial
del juego,
enviando
mensajes a las
instancias de
las clases
Juego y Dado
Definici n de los
Diagramas de
Interaccin
Definici n de los
Diagramas de
diseo de clases
Definici n de los
casos de uso
?
: Juego de
Dados
d1 : Dado
d2 : Dado
lanzar()
v1:= valor()
?
lanzar()
v2:= valor()
Definici n de los
Diagramas de
diseo de clases
Cmo se conectan unos objetos a otros?

Cules son los mtodos de una clase?
Por ejemplo, obtenemos que Jugador requiere de un

mtodo jugar, mientras que el Dado requiere de un m todo
lanzar
61
Definici n de los
Diagramas de
Interaccin
Para definir una clase es preciso contestar varias

preguntas:
?
jugar()
Definici n del
Modelo
conceptual
Introduccin al proceso de desarrollo
Ejemplo
Definicin
Definici n de los
casos de uso
Definici n del
Modelo
conceptual
Definici n de los
Diagramas de
Interaccin
Definici n de los
Diagramas de
diseo de clases
A diferencia del modelo del dominio, el modelo de diseo

no muestra grficamente conceptos del mundo real:
describe nicamente los componentes del software
62
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
El lenguaje UML estandariza los artefactos y la notacin,
pero no define un proceso oficial de desarrollo
?
Juego de
Dados
d1 : Dado
d2 : Dado
jugar()
Aumentar las posibilidades de aceptacin generalizada de la

notacin estndar del modelado, sin la obligaci n de adaptar el
proceso oficial
? Un proceso apropiado admite mucha variaci n y depende de las
habilidades del personal, de la naturaleza del problema, de las
herramientas y muchos otros factores
Dado
valor_mostrado : Integer
1
valor()
lanzar()
63
64
16
Introduccin al proceso unificado
Pasos de macronivel
Inicio
En un nivel alto, los pasos principales son los siguientes:
Inicio: visi n aproximada, caso de negocio, contexto, estimacin

? Elaboracin: visin refinada, implementaci n iterativa de la
arquitectura principal, soluci n de mayores riesgos, identificacin
de la mayora de requerimientos y contexto, estimaci n realista
? Construccin: implementaci n iterativa de riesgos restantes y
elementos ms simples, preparaci n para instalaci n
? Aplicacin: beta-tests, entrega
Inicio es un paso corto que responde las siguientes

preguntas:
?
Cul es la visin o el negocio de este proyecto?

Factible?
? Comprar o desarrollar?
? Estimacin de magnitud de costos: 10 millones o 100 millones?
? Proceder o abortar?
?
RUP
Inicio
Elaboraci n
Construcci n
Aplicaci n
65
Inicio
Entendiendo los requerimientos
Entre los artefactos que se preparan en esta fase se

cuenta con:
Visin y negocio: objetivos de alto nivel, restricciones, negocio y

resumen
? Modelo de casos de uso: requerimientos funcionales y nofuncionales
? Glosario: Terminologa del dominio
? Planificacin: muy aproximada
66
Requerimientos son capacidades y condiciones que debe

cumplir el sistema y el proyecto
El proceso unificado promueve un enfoque sistemtico de
descubrimiento, documentacin, organizacin y rastreo de
los cambiantes requerimientos del sistema
?
Es difcil estabilizar los requerimientos antes de empezar con el

diseo
? Es ms fcil tratarlos como cambiantes en un proceso iterativo
67
68
17
Entendiendo los requerimientos
Casos de Uso: requerimientos en el contexto
Tipos de requerimientos segn modelo FURPS+:
Funcionales propiedades, capacidades, seguridad

? Facilidad de uso factores humanos, ayuda, documentacin
? Confiabilidad frecuencia de fallas, predictabilidad
? Desempeo tiempo de respuesta, precisin, disponibilidad, uso
de recursos
? Soporte adaptabilidad, mantenci n, configuracin
? Implementacin limitaciones de recursos, lenguajes y
herramientas, hardware
? Interfaz restricciones impuestas por comunicacin con otros
sistemas
? Operacin administraci n del sistema funcionando
Los clientes y usuarios finales tienen metas o necesidades

que el sistema debe cumplir
Existen muchas formas de capturarlos, las ms simples
son las mejores, ya que dan la oportunidad a los usuarios
a revisarlos
Un caso de uso es un mecanismo simple y entendible para
todos los involucrados
?
Informalmente, es una historia de uso del sistema para cumplir con

una meta
69
Casos de Uso: formato breve
Casos de Uso: agregando valor
Ejemplo de un caso de uso en formato breve:

?
Realizar Venta: el cliente llega a la caja con los productos que

desea comprar. El cajero usa el sistema de caja para grabar cada
producto comprado. El sistema presenta el total y el detalle del
producto actual. El cajero introduce la informacin de pago, que el
sistema valida y graba. El sistema actualiza el inventario. El cliente
recibe una boleta del sistema y despus se retira con los productos
comprados.
71
70
Actor es algo o alguien con comportamiento: persona con

un rol, sistema computacional u organizacin
Escenario es una secuencia especfica de acciones e

interaccin entre actores y sistema en discusin
Caso de uso es un conjunto de escenarios, en el cual

cada escenario es una secuencia de las acciones en el
sistema que lleva a un resultado observable de inters
para un actor particular
Por ejemplo, Cajero
Tambin, un escenario es una instancia de un caso de uso
72
18
Casos de Uso: formato casual
Casos de Uso: agregando valor
?
?
?
?
Caso de uso: Devolver productos

Curso normal de eventos: El cliente se acerca a la caja con
los artculos que desea devolver. El cajero usa el sistema
para almacenar cada uno de los artculos devueltos
Escenarios Alternativos:
?
Si el pago ha sido realizado con la tarjeta de crdito y la

transaccin de reembolso fall, informar al cliente y pagarle en
efectivo
? Si la identificacin del artculo no ha sido encontrada, notificar al
cajero y sugerir la entrada manual del cdigo
?
La actitud clave al momento de trabajar en un caso de uso

es concentrarse en la pregunta Cmo el uso del sistema
provee un valor observable para un usuario, o como
satisface sus necesidades?, ms que pensar en una lista
de funciones como la especificacin de los requerimientos
del sistema
La lista de atributos y funciones del sistema no contribuye
a entender el contesto ms grande del uso del sistema
para lograr ciertas metas
Casos de uso representan la gran mayora de los
requerimientos
73
Casos de Uso: tipos y formatos
Casos de Uso: tipos y formatos
Casos de uso de caja negra son los ms comunes y

recomendados, los cuales no describen el funcionamiento
interno del sistema, sus componentes o diseo
El sistema se describe en trminos de responsabilidades
?
Varios grados de formalidad:

?
Breve resumen de un parrafo,usualmente del escenario principal
Casual formato informal, varios parrafos que cubren diferentes

escenarios
Completo todos los pasos y variaciones son descritos en detalle

con secciones de pre y poscondiciones
O sea, lo que debe hacer el sistema, no como debe hacerlo

Estilo de Caja Negra
No lo es
El sistema almacena la venta.
El sistema escribe la venta

en la base de datos.
74
Ejemplo: el caso de uso Realizar Venta
Ejemplo: el caso de uso Devolver Productos
Varios formatos estn disponibles, se usar el formato de

www.usecases.org
El sistema genera la sentencia

SQL INSERT para la venta.
75
76
19
Casos de Uso: formato completo
?
?
?
Caso de uso: Realizar Venta

Actor Primario: Cajero
Participantes e intereses:
1.
2.
3.
Cajero: preciso y rpido ingreso, pagos sin errores, ya que estos se

deducen de su salario
? Cliente: compra rpida con mnimo esfuerzo, boleta para
eventuales devoluciones
? Compaa: almacenamiento preciso de las transacciones,
satisfaccin del cliente
4.
Precondiciones: Cajero ha sido identificado y autentificado

Poscondiciones: Venta es almacenada, impuesto calculado
correctamente, contabilidad e inventario actualizados
8.
?
?
Escenario principal (flujo bsico):
5.
6.
7.
9.
10.
77
Cliente llega a la caja con productos o servicios que desea comprar.

Cajero empieza una nueva venta.
Cajero ingresa el identificador del artculo.
Sistema almacena la l nea de venta del artculo y presenta la descripcin
y el precio del artculo, y el total actualizado de la compra. El precio es
calculado de acuerdo a un conjunto de reglas de precio.
Cajero repite pasos 3,4 hasta indicar el trmino.
Sistema presenta el total.
Cajero comunica al Cliente el total y solicita su pago.
Cliente paga y sistema maneja el pago.
Sistema almacena la venta terminada y env a la venta y la informacin del
pago al sistema externo de contabilidad y al sistema de inventario
El sistema genera recibo.
Cliente se va con los productos y el recibo.
Extensiones (o flujos alternativos):
3a: identificador invalido

3b: Hay varios artculos del mismo producto (no existe una identificacin
individual del artculo)
1. Cajero puede ingresar el identificador y la cantidad.
3-6a: Cliente solicita al Cajero sacar un artculo de la compra
1. Cajero ingresa el identificador del artculo para su eliminacin.

2. Sistema muestra el total actualizado.
7a: Cliente paga en efectivo.
1. Cajero ingresa el monto de efectivo entregado por el cliente.

2. Sistema presenta el monto de vuelto y abre la caja de dinero.
3. Cajero deposita el efectivo, extrae el vuelto y lo pasa al Cliente.
4. Sistema almacena el pago en efectivo
?
?
79
Interfaz usuaria desplegada en un pantalla de tacto grande. Texto

debe ser visible a 1m de distancia.
Autorizaciones de tarjeta de crdito dentro de 30 seg. 90% de las
veces.
Reglas de precios pueden ser cambiadas para los pasos 3 y 7.
En caso de falla, el sistema debe recuperar su estado.
Frecuencia de ocurrencia: Casi continuo

Aspectos pendientes:
?
7b: Cliente paga con Tarjeta de Crdito
Requerimientos especiales:
?
1. Sistema indica error y rechaza el ingreso.
78
Explorar la recuperacin de las fallas de servicios remotos

(contabilidad, inventario, autorizacin de crdito)
Deben los cajeros retirar su bandeja de dinero cuando terminan
su turno?
80
20
Casos de Uso: explicacin del formato completo
?
?
Actor principal: El actor primario que requiere los servicios

del sistema para cumplir con sus metas
Participantes e intereses:
El sistema opera como un contrato entre los participantes, los

detalles del cual se definen en un caso de uso
El caso de uso captura nicamente los comportamientos
relacionados con la satisfacci n de los intereses de los
participantes
Se incluyen 3 tipos de pasos:

?
?
?
En general, implica la ejecucin de otro caso de uso
Deben satisfacer las necesidades de todos los involucrados
Escenario principal (flujo bsico) describe el tpico camino

de sucesos sin incluir desviaciones poco frecuentes
?
Precondiciones: deben ser siempre ciertas antes de

empezar con el escenario
?
Poscondiciones: condiciones que deben ser ciertas

despus de completado el caso de uso
Interaccin entre actores

Validacin (usualmente por el sistema)
Estados cambiados por el sistema (almacenar o modificar algo)
Los nombres de los actores empiezan con maysculas por

convenci n
81
Extensiones (o flujos alternativos) indican todos los otros

escenarios o desvos, tanto exitosos como fallidos
Puede ser ms complejas y largas que el escenario principal

Se relacionan con el escenario principal por el nmero de l nea en
la cual ocurre una extensin
?
?
2 partes: condicin y respuesta

Se recomienda escribir la condicin como algo detectado por el
sistema o por el actor
La respuesta puede ser en varios pasos, o puede contener pasos
alternativos, lo cual se denota en al numeracin
Requerimientos especiales: requerimientos nofuncionales, atributos de calidad o restricciones

Tecnologa y Variaciones en los datos: describe cmo
deben ser realizadas algunas cosas
?
?
Tpicamente, el uso de ciertos dispositivos de entrada y salida

Por ejemplo:
?
?
Al final de una extensi n, el curso de eventos regresa al escenario

principal, a no ser que se indique otra cosa
83
82
3a: identificador del artculo se ingresa por el lector lser o teclado

7a: informacin de tarjeta de crdito se ingresa por el lector
magntico o teclado
84
21
Identificacin de los Casos de Uso
Cul de los siguientes sera un caso de uso vlido?
?
?
Negociar un contrato con proveedores

Devolver productos
? Ingresar al sistema
?
Todos podran ser casos de uso en los diferentes niveles

dependiendo de los limites del sistema, actores y sus
metas
Cul es el nivel til para anlisis de requerimientos?
Por lo tanto, se deben descubrir las metas en las reuniones con

los usuarios
?
?
Capturar una venta es una meta

Ingresar al sistema es un meta de muy bajo nivel, no agrega valor al
sistema
?
Proceso de negocio elemental es una tarea continua realizada por

una persona en un lugar en respuesta a un evento de negocio, que
agrega un valor medible para el negocio y deja los datos en un
estado consistente
? No tomar esta definicin literalmente
Actores tienen necesidades los cuales deben ser

satisfechas por el sistema
85
Sera otro caso de uso, y una precondicin para el caso Realizar Venta
Prevenir perdidas no es una meta del usuario, adem s escapa de los

limites del sistema
Casos de Uso: otras consideraciones
1.
2.
Escoger limites del sistema: sistema u organizacin

completa? Definir que es lo que quedara fuera de los
limites del sistema
Identificar actores primarios
?
3.
4.
Apartes de los actores obvios, pueden ser administradores, tiempo

(bach), monitores, etc.
Para cada uno de los actores primarios, identificar sus

metas. Revisar que satisfagan la definicin del proceso de
negocio elemental
Definir casos de uso para satisfacer las metas, nombrarlo
de acuerdo a la meta (con un verbo)
?
86
Se recomienda escribir los casos de uso en forma

iterativa, refinando y adaptando los casos de uso en la
medida que los nuevos requerimientos se descubren
Los usuarios finales deben participar en este proceso,
ojal teniendo un usuario en el proyecto a tiempo
completo
Se recomienda escribir los casos de uso, enfocndose en
las metas del usuario y no en la interfaz
Normalmente, es un caso de uso por cada meta. Excepcin: caso

de uso manejar<X>: crear, eliminar, modificar, buscar <X>
87
88
22
Diagrama de Casos de Uso
Casos de Uso y Lista de Funciones
Diagrama de casos
de uso muestra
actores, casos de
uso y relaciones
entre ellos
?
Realizar Venta
Servicio
Autorizacin
Largas listas de funciones no organizan los requerimientos

en un contexto cohesivo, trate de reemplazarlas por casos
de uso
?
Cajero
Es ms importante
concentrarse en
escribir los casos
de uso en vez de
dibujarlos en el
diagrama
Devolver Productos
Sistema Contable
Aunque son ms apropiadas para algunos sistemas, por ejemplo,

servidores de aplicaciones
Una lista de propiedades del sistema de alto nivel puede

ser til (no ms de 2 hojas)
Por ejemplo:
?
Capturar ventas
Autorizar pagos con tarjetas de crdito y dbito
? Definir y aplicar las reglas de precios
?
Manejar Seguridad
Administrador
Manejar Usuarios
89
Casos de Uso y el proceso unificado
Casos de Uso en la etapa de inicio
Casos de uso son artefactos vitales y centrales en el

proceso unificado, el desarrollo es dirigido por casos de
uso
Se recomienda que todo el equipo se rena para definir los

actores, participantes y metas
?
Se definen los casos de uso de acuerdo a las metas, y los ms

interesantes se escriben en el formato breve
? Los casos de uso que representan los complejos procesos clave se
escriben en el formato completo
Requerimientos son almacenados en los casos de uso

primariamente
? Todo el desarrollo es planificado en iteraciones que se encargan de
implementar uno o ms casos de uso
? Casos de uso influyen en la organizaci n de los manuales de
usuario
90
91
La idea es entender en detalle de que se trata el proyecto
92
23
Casos de Uso en la etapa de elaboracin
Casos de Uso en la etapa de construccin
Se realizan varias iteraciones, en las cuales se

implementan los casos de uso m s importantes, ms
riesgosos y que tienen un impacto significativo en la
arquitectura del sistema
El objetivo es retroalimentar la investigacin con lo
descubierto en la programacin para refinar y adaptar los
casos de uso
Tambin, se escriben en detalle la gran mayora de los
casos de uso priorizando por su complejidad
Una vez que los requerimientos ya estn estables

(resultado de elaboracin), se procede a completar el
sistema
Muy pocos casos de uso sern escritos durante la
construccin, aunque pueden haber algunos refinamientos
93
Etapa de Elaboracin
Casos de Uso en la etapa de construccin
Actividades
Una vez que los requerimientos ya estn estables

(resultado de elaboracin), se procede a completar el
sistema
Muy pocos casos de uso sern escritos durante la
construccin, aunque pueden haber algunos refinamientos
94
Elaboracin es una serie de iteraciones iniciales en las

cuales se investigan los requerimientos, se implementa la
arquitectura principal del sistema y se resuelven los
aspectos de alto riesgo (se incluye, tambin, valor para el
negocio)
?
Generalmente, no son ms de 2-4 iteraciones de 2-6 semanas

cada una
? No se crean prototipos desechables, se crea una parte del sistema
final
95
96
24
Etapa de Elaboracin
Etapa de Elaboracin
Actividades
Artefactos
Los requerimientos se organizan por riesgo, cobertura o

criticalidad
Riesgo incluye tanto la complejidad tcnica, como otros factores,

como una estimacin poco precisa de esfuerzo o facilidad de uso
? Cobertura implica que todas las mayores partes del sistema son al
menos tocados en las iteraciones tempranas
? Criticalidad se refiere al valor para el negocio del cliente
?
Modelo del Dominio: visualiza los conceptos del dominio

Modelo de diseo: es un conjunto de diagramas que muestran el
diseo lgico de software
?
Diagramas de clases, de interaccin, de paquetes, etc.
Modelo de Datos: describe el esquema de base de datos y el

mapeo entre el diagrama de clases y base de datos
? Modelo de Testing
? Modelo de Implementacin
? Prototipos de la Interfaz Usuaria
Se planifica una iteracin a la vez
Durante esta fase se preparan los siguientes artefactos:
97
Etapa de Elaboracin
Etapa de Elaboracin
Iteracin 1
Caso de Uso: Realizar Venta
Requerimientos para la primera iteracin
Implementar slo el escenario principal del caso de uso Realizar

Venta, ingreso de artculos y pago en efectivo
? Implementar el caos de uso Inicio como el soporte necesario para
la inicializaci n
? No hay colaboracin con contabilidad, ni con la base de datos de
productos
? No se aplican las reglas de precios
Actor Primario: Cajero

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
99
98
Cliente llega a la caja con productos que desea comprar.

Cajero ingresa el identificador del artculo.
Sistema almacena la l nea de venta del artculo y presenta la descripcin y
el precio del artculo, y el total actualizado de la compra. El precio es
Sistema presenta el total.
Cajero comunica al Cliente el total y solicita su pago.
Cliente paga y el sistema maneja el pago.
Sistema almacena la venta terminada y env a la venta y la informacin del
pago al sistema externo de contabilidad y al sistema de inventario.
El sistema genera recibo.
Cliente se va con los productos y el recibo.
100
25
Etapa de Elaboracin
Diagrama de Secuencia del Sistema

?

3b: Hay varios artculos del mismo producto (no existe una
identificaci n individual del artculo)
1.
Cajero puede ingresar el identificador y la cantidad.

?

101

?
Por ejemplo, cuando un cajero introduce un cdigo universal de

producto de un artculo, est pidiendo al sistema registrar el cdigo
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
?
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 debe seguir el orden indicado en el caso de uso
102
Durante la interaccin un actor genera eventos dirigidos a

un sistema, solicitando alguna operacin a cambio
?
Antes de iniciar el diseo lgico de cmo funcionar una

aplicacin de software es necesario investigar y definir su
comportamiento como una caja negra
El comportamiento del sistema es una descripcin de lo
que hace, sin explicar la manera en que lo hace
Diagrama de secuencia del sistema se hace para el
escenario principal y algunas veces para las extensiones
ms frecuentes o complejas
103
Para elaborar un diagrama de secuencia del sistema que

describa el escenario principal en un caso de uso:
?
Trace una lnea que represente el sistema como una caja negra
Identifique los actores que operan directamente sobre el sistema.
Trace una lnea 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
?
104
26

?
Consideramos ahora el caso de uso Realizar Venta a fin

de identificar los eventos del sistema
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; esto slo lo hace el cajero
? Por tanto, el cliente no es un generador de eventos del sistema,
slo el cajero lo es
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
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
?
105

?
mantiene un carcter abstracto y no se pronuncia respecto a las

decisiones de diseo sobre cul interfaz sirve para capturar el evento
del sistema
En cuanto a expresar las operaciones en el nivel de

propsito, procure alcanzar el nivel m s alto o la meta final
de asignar nombre a la operacin.
Por ejemplo, respecto a la operacin que captura el pago:
: Sistema
: Cajero
crearNuevaVenta()
IntroducirArticulo((ID_articulo, cantidad))
IntroducirImporteOfrecido(monto) deficiente
? IntroducirPago(monto) mejor
? Pagar(monto) quiz mejor an
descripcin, precio
TerminarVenta()
total
Pagar()
vuelto, recibo
106
107

1. Cliente llega a la caja con
productos o servicios que desea
comprar.
2. Cajero empieza una nueva venta.
3. Cajero ingresa el identificador del
artculo.
4. Sistema almacena la lnea de
venta del artculo y presenta la
descripcin y el precio del artculo, y
el total actualizado de la compra.
Cajero repite pasos 3,4 hasta indicar
el trmino.
5. Sistema presenta el total.
6. Cajero comunica al Cliente el total
y solicita su pago.
7. Cliente paga y el sistema maneja
el pago. ...
108
27

Eventos y operaciones del sistema
?
: Sistema
: Cajero
crearNuevaVenta()
TerminarVenta()
Pagar()

1. Cliente llega a la caja con
productos o servicios que desea
comprar.
2. Cajero empieza una nueva venta.
3. Cajero ingresa el identificador del
artculo.
4. Sistema almacena la lnea de
venta del artculo y presenta la
descripcin y el precio del artculo, y
el total actualizado de la compra.
Cajero repite pasos 3,4 hasta indicar
el trmino.
6. Cajero comunica al Cliente el total
y solicita su pago.
7. Cliente paga y el sistema maneja
el pago. ...
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 un evento del sistema
?
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 respuesta (lo mismo sucede con los
mensajes y los m todos)
109
Modelo del dominio
Por ejemplo, cuando un cajero genera un evento introducirArticulo,

causa la ejecuci n de la operaci n introducirArticulo
110
Modelo del Dominio
Visualizando conceptos
?
El modelo del dominio muestra las clases conceptuales

significativas en el dominio del problema, no componentes
del software
?
Directriz bsica: Es mejor exagerar y especificar un modelo

del dominio con muchos conceptos refinados que no
especificarlo cabalmente
?
Tambin, se llama modelo del dominio y modelo de objetos del

dominio
Es frecuente omitir conceptos durante la fase inicial de

identificaci n 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 del dominio
? 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
Modelo del dominio utiliza la notacin de diagrama de

clases en UML y representa
?
Objetos del dominio o clases conceptuales

Asociaciones entre clases conceptuales
? Atributos de las clases conceptuales
?
111
112
28
Modelo del Dominio
Modelo del Dominio
Lista de categoras comunes
La creacin del modelo del dominio a partir de una lista de

categoras se hace preparando una lista de conceptos
idneos a partir de la lista de categoras comunes
Categoras:
?
Caja
Avin
Especificacin de Producto
Descripcin de Vuelo
Tienda, Cesto
Avin
Hambre
Acrofobia
113
Modelo del Dominio
Frases nominales
reglas y polticas
?
?
catlogos
?
?
Recibo, Contrato de Empleo

Bitcora de Mantenimiento
instrumentos y servicios financieros

?
?
Catalogo de Producto
Catalogo de Partes
Registro de finanzas, de trabajo, de contratos, de asuntos legales

?
?
Poltica de Reembolso
Poltica de Cancelaciones
Lnea de Crdito
Existencia
manuales, libros
?
?
Manual de Personal
Manual de Reparaciones
115
Sistema de Autorizacin de Tarjeta

de Crdito
Control de Trafico Areo
organizaciones
?
?
Departamento de Ventas
Objeto Lnea Area
eventos
procesos (a menudo no estn

representados como conceptos,
pero pueden estarlo)
?
?
Venta, Robo, Junta

Vuelo, Accidente, Aterrizaje
Venta de Producto
Reservacin Asiento
Modelo del Dominio

?
?
?
Cajero
Piloto
conceptos de nombres abstractos

?
Ventas Lnea de Producto
contenedores de otras cosas

?
?
papel de personas
?
?
otros sistemas de computo o

electromecnicas externos al
sistema
?
Venta, Pago
Reservacin
lnea o rengln de elemento de

transacciones
?
Tienda
Aeropuerto
transacciones
?
especificaciones, diseo o descripciones de cosas

?
lugares
?
?
objetos fsicos o tangibles

?
114
Otra tcnica muy til (por su simplicidad) consiste en

identificar las frases nominales (sustantivos) en los
descripciones textuales del dominio de un problema y
considerarlas conceptos o atributos idneos
Este m todo 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
116
29
Modelo del Dominio
Modelo del Dominio
Obtencin de conceptos con Frases nominales
Obtencin de conceptos con Frases nominales
?
?

Cliente llega a la caja con productos o servicios que desea comprar.

3. Cajero ingresa el identificador del artculo.
4. Sistema almacena la lnea de venta del artculo y presenta la descripci n
y el precio del artculo, y el total actualizado de la venta. El precio es
6. Cajero comunica al Cliente el total y solicita su pago.
7. Cliente paga y el sistema maneja el pago.
8. Sistema almacena la venta terminada y env a la venta y la informacin del
pago al sistema externo de contabilidad y al sistema de inventario
9. El sistema genera recibo.
10.Cliente se va con los productos y el recibo.
1.
2.

3b: Hay varios artculos del mismo producto (no existe una
identificaci n individual del artculo)
1.
Cajero puede ingresar el identificador y la cantidad.

117
Modelo del Dominio
Modelo del Dominio
Obtencin de conceptos
Obtencin de conceptos
?
?
Algunas de las frases marcadas son conceptos idneos,

algunas pueden ser atributos de conceptos. El consejo es
combinar este m todo con la lista de categoras
Las lista se restringe tambin por los requerimientos
investigados en el momento
Conceptos Identificados:
Caja
Artculo
Tienda
Venta
Pago
Especificaci n de producto
Lnea de Venta
Cajero
Cliente
Gerente
Catlogo de Productos
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?
?
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
?
119
118
El recibo se excluir, porque las devoluciones de productos

no estn incorporados en este momento
120
30
Modelo del Dominio
Modelo del Dominio
Directrices para construir modelos del dominio
Principio del cartgrafo
Aplique los siguientes pasos para construir un modelo del

dominio:
1.
2.
3.
4.
Liste los conceptos idneos usando la lista de categora de

conceptos y la identificaci n de frases nominales relacionadas con
los requerimientos en cuestin
Dibjelos en el modelo del dominio
Incorpore las asociaciones necesarias para registrar las relaciones
entre los conceptos
Agregue los atributos necesarios para cumplir con las necesidades
de la informaci n
La estrategia del cartgrafo se aplica a los mapas y a los

modelos conceptuales:
Utilice los nombres existentes en el dominio
Excluya las caractersticas irrelevantes
? No agregue cosas que no existan
?
121
Modelo del Dominio
Modelo del Dominio
Principio del cartgrafo
Un error frecuente al identificar conceptos
Los cartgrafos se sirven de los nombres del territorio no cambian los

nombres de ciudades en sus mapas. En el caso de un modelo del
dominio ello significa utilizar el vocabulario del dominio cuando se
asignan nombres a los conceptos y a los atributos
Un cartgrafo elimina cosas en el mapa en caso de que no las juzgue
pertinentes para el propsito: por ejemplo, excluir la informaci n sobre
la poblaci n. De modo similar, un modelo del dominio 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 del dominio no debe mostrar las cosas que no se
encuentren en el dominio del problema en cuestin
123
122
Tal vez, el error m s frecuente cuando se crea el modelo

del dominio es el de representar algo como atributo,
cuando debi haber sido un concepto
Una regla prctica de no caer en l:
?
Si en el mundo real no consideramos algn concepto X como

nmero o texto, probablemente X sea un concepto y no un atributo
?
Por ejemplo, en el dominio de reservaciones en lneas areas:

debera el aeropuerto 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
124
31
Modelo del Dominio
Modelo del Dominio
Clases conceptuales de especificacin o descripcin
Modelo del Dominio del ejemplo
Considere lo siguiente:
Una instancia del Articulo representa un artculo fsico en la tienda;

incluso podra tener un nmero de serie. Un Artculo tiene precio,
descripci n e identificador, que no se guardan en ningn otro lado
? Cuando todos los artculos fsicos han sido vendidos, todas las
instancias lgicas del Artculo son borradas
?
?
Las clases conceptuales identificadas se dibujan en el

diagrama
Caja
Alguien podra responder a la pregunta sobre el precio de

este artculo?
Para resolver el problema, se crea una clase conceptual de
Especificacin de Producto
?
?
Articulo
LineaDeVenta
Pago
Cajero
CatalogoProductos
Tienda
Venta
Cliente
Gerente
EspecificacinProducto
No se borra, si el Producto se vende completamente

Evita guardar la informaci n duplicada
125
126
Modelo del Dominio
Modelo del Dominio
Agregacin de las Asociaciones
Agregacin de las Asociaciones: Criterios
?
?
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 del dominio
La asociacin es una relacin entre dos conceptos que
indica alguna conexin significativa entre ellos
En el lenguaje UML se describen como relaciones
estructurales entre los objetos de diferentes tipos
Examine la conveniencia de incluir las siguientes

asociaciones en un modelo del dominio:
?
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
Registra_actual
Caja
Venta
1
1
Asociacin
127
128
32
Modelo del Dominio
Modelo del Dominio
Agregacin de las Asociaciones: Notacin
Lista de Asociaciones Comunes
Una asociacin se representa con una lnea entre los

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

comunes
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
Categor a
Ejemplos
A es una parte fsica de B
Caja-Tienda
Ala-Avion
A es una parte lgica de B
LineaDeVenta-Venta
TramoDeVuelo-RutaDeVuelo
A est fsicamente contenido en B
Caja-Tienda Producto-Estante
Pasajero -Avion
A est lgicamente contenido en B
EspecificacinProducto CatlogoProductos
Vuelo - ProgramaDeVuelo
A es una descripcin de B
EspecificacinProducto Articulo
DescripcionDeVuelo - Vuelo
A es un elemento de lnea en una

transaccin o reporte B
LineaDeVenta -Venta
TrabajoDeManteniemiento-Mantenimiento
Registra_actual
Caja
Venta
1
1
Asociacin
A se conoce/ introduce/ registra/ Venta Caja

Reservacion - ListaDePasajeros
presenta/ captura en B
129
Modelo del Dominio
Modelo del Dominio
A es miembro de B
Cajero Tienda
Piloto Avion
A es una subunidad organizacional de B
Departamento Tienda
Mantenimiento - LineaAerea
A usa o dirige a B
Cajero Caja
Piloto Avion
A se comunica con B
Cliente Cajero
AgenteDeReservaciones - Pasajero
A se relaciona con una transaccin B
Pago Recibo
Pasajero Boleto
Caja Caja
Cuidad Cuidad
A es propiedad de B
Caja Tienda
Avion LineaAerea
Las categoras de alta prioridad que siempre vale la pena

incluir son las siguientes:
?
A es una parte fsica o l gica de B

A est fsicamente o lgicamente contenido en B
? A est registrado en B
?
A es una transaccin relacionada con otra Pago Venta

Reservacion Cancelacion
transaccin B
A est contiguo a B
130
131
Es mucho ms importante identificar conceptos que

asociaciones. El tiempo dedicado a la creacin del modelo
del dominio debera destinarse a identificar los conceptos,
no las asociaciones
132
33
Modelo del Dominio
Modelo del Dominio
Directrices de las asociaciones
Multiplicidad de las asociaciones
Concentrarse en las asociaciones en que el conocimiento

de la relacin ha de preservarse durante algn tiempo
(asociaciones que es necesario conocer)
Muchas asociaciones tienden a confundir el modelo del
dominio en vez de aclararlo. A veces se requiere mucho
tiempo para descubrirlas, y los beneficios son escasos
No incluir las asociaciones redundantes, ni las derivables
La multiplicidad define cuntas instancias de tipo A pueden

asociarse a una instancia del tipo B en determinado
momento
Almacena
Tienda
Algunos ejemplos de multiplicidad:

*
1..*
3,5,8
133
cero o ms, muchos

uno o ms
exactamente 3, 5 u 8
Modelo del Dominio
Multiplicidad de las asociaciones
Asociaciones: Notacin
El valor de multiplicidad depende del contexto, no hay

soluciones prefabricadas
?
Por ejemplo, asociaci n Trabaja-Para entre Persona y Compaa

tendr diferencias en la multiplicidad dependiendo para quien se
esta haciendo el sistema: servicio de impuestos internos (1 *) o
sindicato de trabajadores (1 1)
Trabaja-Para
Persona
1
Compaa
de uno a 40
exactamente 5
134
Se asigna un nombre a una asociacin basndose en el

formato NombreDeTipo-FraseNominal-NombreDeTipo,
?
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
n
Trabaja-Para
Persona
1..40
5
Modelo del Dominio

?
n
Multiplicidad
del rol
Articulo
1
Compaa
1
135
136
34
Modelo del Dominio
Anlisis Orientado a Objetos
Ejemplos
Asociaciones mltiples entre dos conceptos

1
Tienda
1
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
Contiene
Aerolinea
1..n
Caja
Dos conceptos pueden tener varias asociaciones entre

ellos; sucede con frecuencia
Registra_actual
Pagada-por
Venta
Pago
1
Emplea
Vuela-desde
Vuelo
1..n
Persona
n
Supervisa
Asignado-a
Vuelo
1
Aeropuerto
Tiene-asignado
n
Avion
n
Vuela-hacia
1
137
Modelo del Dominio
Modelo del Dominio
Asociaciones y su implementacin
Asociaciones del dominio del punto de venta
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
Una asociacin no necesariamente debe ser implementada

durante la construccin
139
138
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:
?
Caja, Artculo, Tienda, Venta, Pago

Catalogo de Producto, Especificacin de Producto
? Lnea de Venta
? Cajero, Cliente, Gerente
?
140
35
Modelo del Dominio
Modelo del Dominio
Relaciones inolvidables en la Tienda

Caja captura Venta
Para conocer la venta actual generar un

total e imprimir un recibo.
Venta pagada por Pago
Para saber si se pag la venta, relaciona

la cantidad ofrecida con el total de la
venta e imprime un recibo.
CatalogoProductos registra
EspecificacionProducto
Para recuperar la especificacin de

producto con un cdigo universal de
producto
Recorreremos la lista de comprobaci n, basndonos en tipos

anteriormente identificados y teniendo presentes los requerimientos
actuales del caso de uso
Categora
Sistema Punto de Venta
A es una parte fsica de B
no se aplica
A es una parte lgica de B
LineaDeVenta-Venta
A est contenido fsicamente en B
Caja-Tienda
Producto-Tienda
A est contenido lgicamente en B
EspecificacionProducto CatalogoProductos
CatalogoProductos - Tienda
A es una descripcin de B
EspecificacionProducto Articulo
141
142
Es-de
Modelo del Dominio
Descrita-por

Categora
CatalogoProductos
A es un elemento de lnea en una

LineaDeVenta-Venta
transaccin o reporte B
A se comunica con B
A se relaciona con una transaccin B
Cliente Pago
Cajero Pago
A es propiedad de B
Caja Tienda
Contenidas-en
1 n Capturada-en
1
1
Venta
1
Pago
143
1
Articulo 1..n
Almacena
1 1
Contiene
1
1
1
Pagada-por
Iniciada-por
A es una transaccin relacionada con otra Pago Venta

transaccin B
Caja Caja, probablemente no aplicable
n
Describe
n
Tienda
Terminadas
no aplicable
A est contiguo a B
LineaDeVenta
Cajero Caja, Gerente Caja

Gerente Cajero, probablemente no aplicable
Cliente Cajero
A usa o dirige a B
1
Se-usa-por
0..1
A se conoce/ introduce/ registra/ presenta/ Venta (terminada) Tienda

captura en B
Venta (actual) Caja
A es miembro de B
Cajero Tienda
A es una subunidad organizacional de B
1
Especificacin
Producto
Contiene
Sistema Punto de Venta
1
Cliente
1..n
Caja
Iniciada-por
1 1
Gerente
1
Registra-ventas-de
Iniciada-por
1
Cajero
144
36
Modelo del Dominio
Modelo del dominio del punto de venta
Modelo del dominio del punto de 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
Los requerimientos no indican la necesidad de conocer, ni
de registrar lo siguiente:
?
1
Se-usa-por
n
Tienda
Terminadas
Contenidas-en
Adems, es derivable si existe la asociacin Caja Usada-por Cajero
1..n
Caja
1
Pago
145
Cliente
Gerente
Cajero
Modelo del Dominio
Requerimientos
Agregacin de los Atributos
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
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
1
Articulo
1
Pagada-por
Modelo del Dominio
n
Describe
1 n Capturada-en
1
1
Venta
Caja Usada-por Cajero

? Caja Iniciado-por Gerente
? Venta Iniciada-por Cliente
? Tienda Almacena Artculo
? LneaDeVenta Es-de Art culo
Contiene
LineaDeVenta
Venta Iniciada-por Cajero

?
1
Especificacin
Producto
Contiene
CatalogoProductos
147
146
Recuerde que el modelo del dominio 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
Un atributo es un valor lgico de un dato o de un objeto
148
37
Modelo del Dominio
Modelo del Dominio
Incluya los siguientes atributos en el modelo del dominio:

?
Aquellos en que los requerimientos (por ejemplo, casos de uso)

indican o conllevan la necesidad de recordar informaci n
Los tipos ms simples de atributos son los que, en la

prctica, suelen considerarse los tipos primitivos de datos
?
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 secci n de conceptos, es

opcional indicar su tipo
Por lo regular, el tipo de un atributo no debera ser un concepto

complejo del dominio, como Venta o Aeropuerto. Por ejemplo,
podramos poner un atributo Caja-Actual al concepto Cajero, que
no es un tipo simple, pero la forma ms conveniente de expresarlo
es a travs de la asociacin
Caja
Venta
Cajero
fecha
hora
IdCajaActual
nombre
Atributos
Usada-por
1
Cajero
nombre
149
Modelo del Dominio
Modelo del Dominio
Atributos del sistema de punto de venta
?
?
En un modelo del dominio es preferible que los atributos

sean atributos simples o valores puros de datos
Entre los tipos simples de atributos ms frecuentes figuran:
?
?
Booleano, Fecha, Numero, Cadena (Texto), Hora

Direccion, Color, Geometria (punto, Rectangulo, ), Telefono,
RUT, Codigo Universal de Producto (id), codigo postal, tipos
numerados
Es necesario producir una lista de atributos para los

conceptos del dominio de punto de venta. Debe estar
reservada especficamente a los requerimientos a las
simplificaciones en cuestin: Realizar Venta
Por ejemplo, podemos identificar los atributos:
?
Tienda: direcci n, nombre

Venta: fecha, hora
? LineaDeVenta: cantidad
? Pago: monto
? EspecificacionDeProducto: decripcion, precio, id
?
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
150
151
152
38
Modelo del Dominio
Modelo del Dominio
Descrita-por
CatalogoProductos
n
1
Se-usa-por
LineaDeVenta
1
Contiene
descripcin
precio
1
n
id
n
Describe
En consecuencia, una instancia de LineaDeVenta puede estar

asociada a ms de una instancia de cada producto
? La cantidad que introduce el cajero puede quedar registrada como
atributo de LineaDeVenta
cantidad
n
Terminadas
n
Tienda
Contenidas-en
1n
Venta 1 Capturada-en1
fecha
hora
1
Pagada-por
1
Articulo
1
Contiene
1..n
Caja
Es posible que el cajero reciba un grupo de productos

afines (seis paquetes de pauelos desechables) y
introduzca una sola vez el id y la cantidad (seis)
Gerente
1
Usada-por
1
Pago
1
Cajero
Cliente
monto
nombre
153
Modelo del Dominio
Modelo del Dominio
?
?
Descrita-por
Sin embargo, tambin puede ser calculada a partir del

valor real de multiplicidad de la relacin
As, pasa a ser un atributo derivado, el cual puede ser
deducido de otra informacin
?
154
descripcin
precio
id
n Describe 1
Articulo
n
Contenida-en
LineaDeVenta
/ cantidad
n
Terminadas
En UML, un atributo derivado se denota con el smbolo /
Se-usa-por
Tienda
1
CatalogoProductos
Contenidas-en
LineaDeVenta
/cantidad
1
1 n
1
Contiene
1n
1..n
Venta 1 Capturada-en 1
1 Cajero
Caja 1
fecha
Usada-por
nombre
hora
1
Producto
0..1 Registra-venta-de 1..*
Pagada-por
1
Pago
monto
155
156
39
Modelo del Dominio
Modelo de Casos de Uso
Contratos de Operaciones
?
?
Se ha creado un modelo del dominio 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 del dominio capta las abstracciones
esenciales y la informacin indispensable para comprender
el dominio dentro del contexto de los requerimientos
actuales
157
Contratos pueden ser

escritos para las
operaciones del sistema
definidos en el diagrama de
secuencia del sistema
: Sistema
: Cajero
crearNuevaVenta()
TerminarVenta()
Pagar()
158
Contratos de Operaciones: formato
Contrato: introducirArticulo (idArticulo, cantidad)

Referencias: Caso de uso: Realizar Venta
Precondiciones : Venta esta en curso
Poscondiciones:
Contrato: Nombre de la operacin, parmetros

Referencias: (opcional) Casos de uso en las cuales aparece
la operacin
Precondiciones : Suposiciones tiles sobre el estado del
sistema o objetos del modelo del dominio antes de la
ejecucin de la operacin
Poscondiciones: estado de objetos del modelo del dominio
despus de la completacin de la operacin
Se cre una instancia de LineaDeVenta li (creaci n de instancia)

li se asoci con la Venta actual (asociacin formada)
? Se modific el atributo li.cantidad (modificacin de atributos)
? li se asoci con EspecificacinProducto basado en la
correspondencia del id (asociacin formada)
?
159
160
40
?
?
Poscondiciones describen los cambios en el estado de los

objetos del modelo del dominio
Los cambios del estado incluyen:
Creaci n y eliminacin de instancias

Formaci n y eliminacin de asociaciones
? Modificaci n de atributos
?
Los contratos contribuyen a definir el comportamiento de

un sistema; describen el efecto de las operaciones sobre el
los objetos del modelo de dominio
Su desarrollo depende del desarrollo previo del modelo del
dominio, de los diagramas de secuencia de sistema y la
identificacin de sus operaciones
El error m s comn consiste en olvidar incluir la formacin

de asociaciones
?
Sobre todo cuando se crean nuevas instancias, muy

probablemente ser necesario establecer asociaciones a varios
objetos
161
Aplique la siguiente sugerencia para elaborar contratos
Identifique las operaciones del sistema a partir de los diagramas de

secuencia
? Elabore un contrato en cada operacin compleja del sistema
? Complete la seccin de Poscondiciones, describiendo en forma
declarativa los cambios de estado de los objetos en el modelo del
dominio
? Para describir las poscondiciones utilice las siguientes categoras:
?
?
?
Creacin y eliminacin de instancias

Modificacin de atributos
Asociaciones formadas y canceladas
Cuando se formulan contratos, en general se agregarn al

modelo del dominio nuevos conceptos, atributos y
asociaciones
?
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:
En lugar de
163
162
Se cre una instancia LineaDeVenta (mejor)

Crear una instancia LineaDeVenta (peor)
164
41
Entonces, mire el contrato desde la perspectiva de un

escenario y un teln
Una vez que el cajero captur el id y la cantidad del producto, Qu ha

de crearse?
?
Tome una fotografa de escenario antes de la operaci n

? 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 LineaDeVenta)
Una instancia LineaDeVenta debera ser creada

?
Habra que establecer la cantidad de LineaDeVenta

?
Se asign una cantidad a LineaDeVenta.cantidad (modificacin de atributo)
qu asociaciones entre los objetos nuevos y actuales debieron haber

sido formadas o canceladas?
?
Habra que relacionar la nueva instancia de LineaDeVentacon sus Ventas

y con su Producto
?
?
Se cre una instancia LineaDeVenta (creacin de instancia)
qu atributos de los objetos nuevos o actuales deberan ser

modificados?
165
Se asoci una instancia de LineaDeVenta a la Venta (asociacin formada)

Se asoci una instancia LineaDeVenta a la instancia EspecificaciondeProducto ,
basado en la correspondencia del id (asociacin formada)
Contratos de Operaciones para punto de venta
Poscondiciones:
166
Contrato: crearNuevaVenta ()
Precondiciones: ninguna
Poscondiciones:
?
?

Se cre una instancia de Venta v (creaci n de instancia)

v se asoci con Caja (asociacin formada)
? Se inicializaron los atributos de v (modificacin de atributos)
?
167
168
42

Poscondiciones:
Contrato: TerminarVenta ()
Poscondiciones:

Se modific el atributo li.cantidad (modificacin de atributos)
?
?
169
Se modific el atributo v.Terminada a verdadero (modificaci n de

atributos)
Cambios en el modelo del dominio
Contrato: pagar (monto)

Precondiciones : Venta esta terminada
Poscondiciones:
Los contratos sugieren la existencia de un dato que

todava no ha figurado en el modelo del dominio: la
terminacin de la captura de los productos en la venta
?
Se cre una instancia de Pago p (creaci n de instancia)

p se asoci con la Venta actual (asociacin formada)
? Se modific el atributo p.monto (modificacin de atributos)
? p se asoci con Tienda para almacenar ventas completadas
(asociaci n formada)
170
Lo modifica la operacin terminarVenta y la operaci n Pagar lo

toma como precondicin
Una forma de representar esta informacin es a travs de

un atributo Terminada de la Venta, por medio de un valor
booleano
Venta
fecha
hora
Terminada : Boolean
171
172
43
Pasando a diseo
?
?
?
Pasando a diseo
Hasta ahora, las actividades se han centrado en la

investigacin de los requerimientos
A la medida que se descubren nuevos requerimientos, se
actualizan los artefactos correspondientes
En la prctica, los diagramas de interaccin y los
diagramas de clases se desarrollan en paralelo, pero se
van a introducir secuencialmente por claridad
?
?
?
Los diagramas de interaccin reflejan las decisiones de

asignacin de responsabilidades a los objetos de software
Las habilidades de diseo son realmente importantes, ms
que saber como dibujar los diagramas en UML
El conocimiento esencial es:
?
?
Principios de asignaci n de responsabilidades

Patrones de diseo
173
Diagramas de interaccin
Notacin
Notacin
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:
mensaje1()
El punto de partida de las interacciones es el cumplimiento de las

poscondiciones de los contratos de operaci n
1: mensaje2()
2: mensaje3()
Instancia1 : ClaseA
El UML define dos tipos; ambos sirven para expresar

interacciones semejantes o idnticas al mensaje
174
Instancia2 : ClaseB
Los diagramas de secuencia describen las interacciones

en una especie de formato de cerca o muro:
Instancia1 :
ClaseA
mensaje1()
Instancia2 :
ClaseB
mensaje2()
mensaje3()
175
176
44
Ejemplo
Elaboracin de un diagrama
1: Pagar(monto)
2: pagar(monto)
: Caja
3: crear(monto)
: Venta
: Pago
: Cajero
Instancia
Vnculo
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 operaci n, las poscondiciones y la descripcin de casos de uso
Mensaje y
parametros
: Caja
: Cajero
: Venta
: Pago
Pagar(monto)
pagar(monto)
?
crear(monto)
Prepare un diagrama por cada operacin del sistema

durante el ciclo actual de desarrollo
Aplique el GRASP y otros patrones para desarrollar un

buen diseo
177
Relacin entre los artefactos
Notacin
?
?
?
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
UML ha adoptado un m todo simple y uniforme de

distinguir visualmente las instancias de acuerdo a tipo:
?
Venta
Instancia
Instancia con
nombre
: Venta
s1: Venta
El vnculo (o enlace) es una trayectoria de conexin entre

dos instancias, indica la navegacin y visibilidad posibles
entre las instancias
?
179
Una instancia utiliza el mismo smbolo grfico usado para

representar el tipo, pero se subraya el texto
Clase
178
Ms formalmente, el vnculo es una instancia de una asociacin

180
45
Notacin
Notacin
Si vemos dos instancias en una relacin de clienteservidor, una trayectoria de navegacin del cliente al
servidor significa que los mensajes pueden enviarse del
primero al segundo
?
El nmero indica el orden consecutivo de los mensajes en la serie

actual de control
? Los parmetros de un mensaje pueden anotarse dentro de
parntesis despus del nombre del mensaje
As, existe un vnculo o trayectoria de navegacin entre Caja y una

Venta, a lo largo del cual pueden fluir los mensajes; por ejemplo, el
mensaje Pagar
1: Pagar(monto)
Los mensajes entre objetos se representan por medio de

una flecha con nombre situada sobre la lnea del vnculo
El lenguaje UML cuenta con una sintaxis estndar para los

mensajes:
? retorno : mensaje(parametro: tipoParametro ) : tipoRetorno
2: pagar(monto)
: Caja
: Venta
?
Es opcional incluir el tipo de parmetro en cuestin
No obstante, se puede utilizar otra sintaxis como la de Java o la de

Smalltalk.
Se recomienda emplear la sintaxis estndar de UML a fin de que los
diagramas de colaboracin sigan siendo un lenguaje relativamente
independiente
181
Notacin
Notacin
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
4: limpiar()
182
La iteracin se indica posponiendo un asterisco (*) al

nmero de secuencia. Ese s mbolo 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
1*: [i:=1..10] li:=siguienteLineadeProducto ():
LineaDeVenta
mens1()
:Caja
:Venta
: Caja
183
184
46
Notacin
Notacin
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, que indican
la transferencia de los valores iniciales
mens1()
El orden de los mensajes se indica con un n mero de

secuencia, como se aprecia en la figura. El esquema de la
numeracin es:
?
?
El primer mensaje no se enumera. As, mens1() no lleva nmero

El orden y el anidamiento de los mensajes siguientes se indican
con un esquema legal de numeraci n, donde a los mensajes
anidados se les ha antepuesto un nmero.
?
1:crear(cajero)
:Caja
:Venta
La anidacin se denota anteponiendo el nmero del mensaje de

entrada al del mensaje de salida
mens1()
1:crear(cajero)
:Caja
185
:Venta
Notacin
Notacin
?
segundo
primero
1: mens2()
: ClaseA
tercero
: ClaseB
2: mens4()
1.1: mens3()
cuarto
186
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
2.1: mens5()
quinto
mens1()
: ClaseC
1:[nuevaventa] crear()
:Caja
:Venta
2.2: mens6()
: ClaseD
sexto
187
188
47
Notacin
Notacin
Un multiobjeto, o conjunto de instancias, puede dibujarse

como un icono de pila segn se observa en la figura
Un mensaje dirigido a un icono de multiobjeto indica que

se enva al objeto coleccin
?
Multiobjeto
As, en la figura el mensaje tamao est siendo enviado al

multiobjeto LineaDeVenta
mensaje enviado al
objeto coleccin
Ventas : Venta
Un multiobjeto suele implementarse como un grupo de

instancias guardadas en un contenedor u objeto coleccin;
?
por ejemplo, un vector de la STL de C++, un Vector de Java o una

OrderedCollection de Smalltalk
1: s := tamao(): entero
: Venta
Pero no necesariamente se implementa as ; representa tan

slo un conjunto lgico de instancias
En el lenguaje UML, los mensajes dirigidos a un

multiobjeto no se trasmiten a todos los elementos
189
: LineaDeVenta
Notacin
Responsabilidades y mtodos
Los mensajes pueden ser dirigidos a la propia clase y no a

una instancia, con el fin de llamar los mtodos de la clase
?
no subrayada,
por tantouna clase
Fecha
1: d1:=hoy(): Fecha
: Venta
En consecuencia, es importante subrayar los nombres de

las instancias cuando se desea denotar una instancia
?
De lo contrario pueden interpretarse errneamente los mensajes

dirigidos a las instancias y los dirigidos a las clases
Booch y Rumbaugh definen la responsabilidad como un

contrato u obligacin de un tipo o clase
?
Por ejemplo, en Java stos se implementan como mtodos

estticos; en Smalltalk son mtodos de clases
191
190
Las responsabilidades se relacionan con las obligaciones de un

objeto respecto a su comportamiento
Esas responsabilidades pertenecen, esencialmente, a las

dos categoras siguientes: conocer o hacer
Las responsabilidades se asignan a los objetos durante el
diseo orientado a objetos
?
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)
192
48
Responsabilidades de un objeto relacionadas con hacer:
hacer algo en uno mismo

? iniciar una acci n en otros objetos
? controlar y coordinar actividades en otros objetos
?
Responsabilidades de un objeto relacionadas con conocer:

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
stas se implementan usando mtodos que operen solos o en

colaboraci n con otros mtodos y objetos
significa que los objetos

Ventatienen la
responsabilidad de imprimirse
Responsabilidad no es lo mismo que mtodo: los mtodos

se ponen en prctica para cumplir con responsabilidades
1: [en cada] vli:=siguiente()
imprimir()
: Venta
Las responsabilidades relacionadas con conocer a menudo pueden

inferirse del modelo del dominio por los atributos y asociaciones
explicadas en l
: LineaDeVenta
2: imprimir()
vli : LineaDeVenta
193
194
GRASP: Patrones para Asignar 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 m todo
correspondiente imprimir
Ms an, para atender esta responsabilidad hay que

colaborar con los objetos LineaDeVenta, pidindoles que
se impriman
195
En resumen, los diagramas de interaccin muestran las

decisiones referentes a la asignacin de responsabilidades
entre los objetos
Esta asignacin se refleja en los mensajes enviados entre
varias clases de objetos
Los patrones GRASP guan la asignacin de
responsabilidades
196
49
Un sistema orientado a objetos se compone de objetos que

envan mensajes a otros objetos para que lleven a cabo las
operaciones
En los contratos se incluye una conjetura inicial sobre las
poscondiciones de las operaciones introducirArticulo,
terminarVenta y Pagar
Los diagramas de interaccin describen grficamente la
solucin - a partir de los objetos en interaccin - que
satisfacen estas responsabilidades y poscondiciones
La calidad de diseo de la interaccin de los objetos y la

asignacin de responsabilidades presentan gran variacin
?
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
?
197
En los patrones GRASP se codifican algunos de los

principios, que se aplican al preparar los diagramas de
interaccin
198
GRASP es un acrnimo que significa General

Responsibility Asignment Software Patterns (patrones
generales de software para asignar responsabilidades)
El nombre se eligi para indicar la importancia de captar

(grasping) estos principios, si se quiere disear
eficazmente el software orientado a objetos
199
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
Muchos patrones ofrecen orientacin sobre cmo asignar

las responsabilidades a los objetos ante determinada
categora de problemas
200
50
Patrones de Diseo
Patrones de Diseo
En la terminologa de objetos, un patrn es una descripcin

de un problema y su solucin, que recibe un nombre y que
puede emplearse en otros contextos
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?
Los patrones GRASP describen los principios

fundamentales de la asignacin de responsabilidades a
objetos, expresados en forma de la pareja problemasolucin
?
Los patrones codifican buenos principios y sugerencias

relacionados con la asignaci n de responsabilidades
El hecho de asignar nombre a un patrn, a un mtodo o a

un principio ofrece las siguientes ventajas:
?
Apoya el agrupamiento y la incorporacin del concepto a nuestro

sistema cognitivo y a la memoria
? Facilita la comunicaci n
201
Patrones de Diseo
202
Patrones de Diseo
Experto
Patrones GRASP
Experto
? Creador
? Bajo Acoplamiento
? Alta Cohesin
? Controlador
Problema: Cul es el principio fundamental en virtud del

cual se asignan las responsabilidades en el diseo
orientado a objetos?
?
Un modelo de clases 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
?
203
Solucin: asignar una responsabilidad al experto en

informacin - la clase que cuenta con la informacin
necesaria para cumplirla
204
51
Patrones de Diseo
Patrones de Diseo
Experto
Experto
En la aplicacin del punto de venta, alguna clase necesita

conocer el gran total de la venta:
?
?
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 calcular
el total
LineaDeVenta
/cantidad
Descritas -por
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 :
?
Venta conoce el total de la venta

LineaDeVenta conoce el subtotal de la l nea de producto
? EspecificaciondeProducto conoce el precio del producto
?
EspecificaciondeProductos
1..*
Contenidas -en
1
Venta
fecha
hora
205
Patrones de Diseo
Patrones de Diseo
Experto
Experto
?
1: tot:=total()
2: st:=subtotal()
: Venta
3: pr:=precio()
: LineaDeVenta
: EspecificacinProducto
?
Pseudocdigo
public void total()
{ int tot:=0
for each LineaDeVenta, li
tot:= tot + li.subtotal()
return total}
207
206
Experto es un patrn que se usa ms que cualquier otro al

asignar responsabilidades; es un principio b sico que
suele til en el diseo orientado a objetos
Ntese, que el cumplimiento de una responsabilidad
requiere a menudo informacin distribuida en varias clases
de objetos
208
52
Patrones de Diseo
Patrones de Diseo
Experto
Creador
Beneficios
Se conserva el encapsulamiento, ya que los objetos se valen de su

propia informaci n 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
? El comportamiento se distribuye entre las clases que cuentan con
la informacin requerida, alentando con ello definiciones de clases
sencillas y ms cohesivas que son ms fciles de comprender y
de mantener. As, se brinda soporte a una alta cohesi n
El patrn Creador gua la asignacin de responsabilidades

relacionadas con la creacin de objetos, tarea muy
frecuente en los sistemas orientados a objetos
El propsito fundamental de este patrn es encontrar un
creador que debemos conectar con el objeto producido en
cualquier evento
Al escogerlo como creador, se da soporte al bajo
acoplamiento
209
Patrones de Diseo
Patrones de Diseo
Creador
Creador
Problema: Quin debera ser responsable de crear una

nueva instancia de alguna clase?
Solucin: Asignarle a la clase B la responsabilidad de crear

una instancia de clase A en uno de los siguientes casos:
?
La creaci n 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 reutilizacin
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
?
211
210
As, B es un Experto respecto a la creacin de A
B es un creador de los objetos A
Si existe m s de una opcin, prefiera la clase B que

agregue o contenga la clase A
212
53
Patrones de Diseo
Patrones de Diseo
Creador
Creador
Ejemplo
?
En la aplicaci n del punto de venta, quin debera encargarse de

crear una instancia LineaDeVenta?
?
Una Venta contiene (en realidad, agrega) muchos objetos

LineaDeVenta;
?
Desde el punto de vista del patrn Creador, deberamos buscar una

clase que agregue, contenga y realice otras operaciones sobre este
tipo de instancias
LineaDeVenta
cantidad
Descritas -por
EspecificaciondeProducto
por ello, el patrn Creador sugiere que Venta es idnea para

asumir la responsabilidad de crear las instancias LineaDeVenta
1: CrearNuevaVenta()
2: crear()
: Caja
3: crear()
: Venta
: LineaDeVenta
1..*
Contenidas -en
1
Venta
fecha
hora
213
Patrones de Diseo
Patrones de Diseo
Creador
Bajo Acoplamiento
?
?
En ocasiones encontramos un patrn creador buscando la

clase con los datos de inicializacin
ste es en realidad un ejemplo del patrn Experto
?
Los datos de inicializaci n se transmiten durante la creaci n a

travs de algn m todo de inicializacin, como un constructor en
java que cuenta con parmetros
?
?
Problema: 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:
?
?
?
214
215
Los cambios de las clases afines ocasionan cambios locales

Difciles de entender cuando estn aisladas
Difciles de reutilizar puesto que dependen de otras clases
216
54
Patrones de Diseo
Patrones de Diseo
Bajo acoplamiento
Bajo acoplamiento
?
?
Solucin: Asignar una responsabilidad para mantener bajo

acoplamiento
Ejemplo: En el caso del punto de ventas se tienen tres
clases Pago, Caja y Venta y se quiere crear una instancia
de Pago y asociarla a Venta. Que clase es la responsable
de realizarlo?
?
Segn el patrn de Bajo Acoplamiento la relacin debera

ser de la siguiente manera:
EfectuarPago()
:Caja
1:EfectuarPago()
:Venta
1.1:Crear()
Segn el patrn experto la Clase Caja deber hacerlo

EfectuarPago()
:Caja
:Pago
1:Crear()
P:Pago
2:AgregarPago(p)
Esta ltima solucin es mejor dado que Venta realiza la

creacin del Pago y no Caja, por lo tanto se reduce la
dependencia de este ltimo con el resto de las clases
:Venta
217
Patrones de Diseo
Patrones de Diseo
Bajo acoplamiento
Alta Cohesin
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
Beneficios:
?
No se afectan por cambios de otros componentes

? Fciles de entender por separado
? Fciles de reutilizar
?
?
Problema: Cmo mantener la complejidad dentro de

lmites manejables?
La cohesin es una medida de cun relacionadas y
enfocadas estn las responsabilidades de una clase
?
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:
?
?
?
?
219
218
Son difciles de comprender

Difciles de reutilizar
Difciles de conservar
Las afectan constantemente los cambios
220
55
Patrones de Diseo
Patrones de Diseo
Alta Cohesin
Alta Cohesin
?
?
Solucin: Asignar una responsabilidad de modo que la

cohesin siga siendo alta
Ejemplo: En el caso del punto de ventas se tienen tres
clases Pago, Caja y Venta y se quiere crear una instancia
de Pago y asociarla a Venta. Segn el principio del patrn
Creador la clase Caja debe ser la encargada de realizar el
pago
Qu pasa si el sistema tiene 50 operaciones, todas

recibidas por la clase Caja ?
El diseo, que delega a Venta la responsabilidad de crear

el Pago, es conveniente ya que da soporte a una alta
cohesin y a un bajo acoplamiento
La clase se saturar con tareas y terminar perdiendo la cohesin
EfectuarPago()
EfectuarPago()
:Caja
:Caja
1:EfectuarPago()
:Venta
1:Crear()
P:Pago
2:AgregarPago(p)
1.1:Crear()
:Venta
:Pago
221
Patrones de Diseo
Patrones de Diseo
Alta Cohesin
Alta Cohesin
En la prctica, el nivel de cohesin no puede ser

considerado independiente de los otros patrones y
principios
?
Algunos escenarios:
?
Muy baja cohesi n: Una clase es la nica responsable de muchas

cosas en reas funcionales heterogneas
? Baja cohesi n: Una clase tiene la responsabilidad exclusiva de una
tarea compleja dentro de un rea funcional
? Alta cohesin: Una clase tiene responsabilidades moderadas en un
rea funcional y colabora con las otras para llevar a cabo las tareas
? Cohesi n 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
Por ejemplo, patrones Experto y Bajo Acoplamiento
Beneficios:
?
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 reutilizaci n
?
222
223
224
56
Patrones de Diseo
Patrones de Diseo
Controlador
Controlador
?
?
Problema: Quin debera encargarse de atender un

evento del sistema?
Un evento del sistema es un evento de alto nivel generado
por un actor externo; es un evento de entrada externa que
genera una operacin del sistema en respuesta
?
Solucin: Asignar la responsabilidad del manejo de un

mensaje de los eventos de un sistema a una clase que
represente una de las siguientes opciones:
?
el sistema global (controlador de fachada)

la empresa u organizaci n 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)
?
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
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
225
Patrones de Diseo
Patrones de Diseo
Controlador
Controlador
Ejemplo:
En la aplicaci n del punto de venta se dan varias operaciones del

sistema: crearNuevaVenta, IntroducirArticulo, TerminarVenta
? Quin debera ser el controlador de eventos sistmicos como
introducirArticulo y terminarVenta?
introducirArticulo(id, cantidad)
: ???
Qu clase debe encargarse

de manejar este mensaje de
eventos de sistema?
226
De acuerdo con el patrn Controlador, disponemos de las

siguientes opciones:
?
Sistema global Caja

Empresa u organizacin global Tienda
? Papel de una persona Cajero
? Manejador artificial de todas las operaciones del sistema de un
caso de uso ManejadorRealizarVenta
?
Un controlador
227
228
57
Patrones de Diseo
Patrones de Diseo
Controlador
Controlador
En la decisin de cul de las cuatro clases es el

controlador m s apropiado influyen tambin otros aspectos
como la cohesin y el acoplamiento
Caja
Sistema
terminarVenta( )
introducirArticulo( )
Pagar( )
terminarVenta( )
Pagar( )
operaciones del
sistema descubiertas
durante el anlisis de
su comportamiento
asignacin de las
operaciones del sistema
durante su diseo, mediante
el patrn Controlador
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
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 Pagar
antes de terminarVenta)
229
Patrones de Diseo
Patrones de Diseo
Controlador
Controlador
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
231
230
Manejador artificial de casos de uso - un controlador para

cada caso
?
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 Realizar Venta y Devolver Productos, habr una clase
ManejadorRealizarVenta y una clase ManejadorDevolverProductos
? Esta alternativa debe tenerse en cuenta, si el hecho de asignar las
responsabilidades en cualquiera de las otras opciones de
controlador genera diseos de baja cohesi n o alto acoplamiento.
Esto ocurre generalmente cuando un controlador empieza a
saturarse con demasiadas responsabilidades
232
58
Patrones de Diseo
Patrones de Diseo
Controlador
Controlador
Beneficios
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
?
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
Por ejemplo, tal vez deba garantizarse que la operacin efectuarPago

no ocurra mientras no se concluya la operacin terminarVenta. De ser
as, esta informacin 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
233
Patrones de Diseo
234
Diseo de una Solucin
Controlador
Contenido
Tienda de Objetos
Ntese que la clase

CajaApplet - parte de la
capa de presentacin transmite un mensaje
introducirArticulo al objeto
Caja
No intervino en el proceso
de la operacin, ni la
decisin de cmo
manejarla, el applet se
limit a delegarla a la capa
del dominio
ID
Cantidad
Precio
Desc.
Total
Saldo
?
?
Ofrecido
Oprime botn
Introducir
Producto
Terminar
Venta
Efectuar
Pago
Cajero
Aplicacin de los patrones GRASP para asignar

responsabilidades a las clases
Uso de la notacin de UML en los diagramas de
colaboracin para describir grficamente el diseo de la
interaccin de objetos
enIntroducirProducto()
Capa de presentacin
Applet en Java
: CajaVApplet
mensaje de eventos
del sistema
1: introducirArticulo(id, cantidad)
Controlador
2: hacerLineadeProducto(id,cantidad)
Capa del Dominio
: Caja
: Venta
235
236
59
Introduccin
Diagramas de interaccin y eventos del sistema
En la prctica, los diseadores se percatan de que la

preparacin de los diagramas de interaccin es uno de los
pasos m s lentos
La asignacin de responsabilidades y la elaboracin de los
diagramas de interaccin representan uno de los pasos
ms importantes en la fase de diseo
En la iteracin actual de la aplicacin del punto de venta

estamos considerando dos casos de uso y sus eventos
sistemticos asociados:
?
Realizar Venta: crearNuevaVenta introducirArticulo terminarVenta

pagar
? Inicio: inicio
?
Por cada evento del sistema se construye un diagrama de

colaboracin cuyo mensaje inicial sea el de sus eventos
?
Habr, pues, cinco diagramas de interacci n por lo menos: uno por

cada evento del sistema
237
238
Eligiendo controlador
Diagramas de interaccin para punto de venta
En la eleccin del controlador que se encargue del

mensaje de las operaciones del sistema disponemos de
las siguientes opciones:
introducirArticulo()
1 :???()
: Caja
Representa el "sistema" global - Caja

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 - ManejadorRealizarVenta
?
terminarVenta()
1 :???()
: Caja
Pagar()
1 :???()
: Caja
iniciar()
1 :???()
: Caja
239
240
60
Un controlador de fachada como Caja es adecuado

?
si el sistema ofrece pocas operaciones y si ese controlador no

asume demasiadas responsabilidades (en otras palabras, si
empieza a perder cohesi n)
En cada contrato revisamos los cambios de estado de los

objetos responsables y las poscondiciones asociadas
?
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)
En este caso, Caja ser suficiente porque el sistema tiene
pocas operaciones por ahora
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
Empezamos definiendo claramente la responsabilidad
241
Ntese que, en caso de omitir la preparaci n del contrato, de todos

modos deberamos elaborar los diagramas de interaccin
retornando a los casos de uso y reflexionando sobre lo que
debemos lograr
Recordando el modelo del dominio

Descrita-por
n
LineaDeVenta
1 EspecificacinProducto n
descripcin
precio
n
id
Describe
Articulo
Contenida-en
n
Terminadas
1n
Venta
Pago
monto
Paga
1 fecha
hora
Terminada : Boolean
Contrato: crearNuevaVenta ()
Precondiciones: ninguna
Poscondiciones:
?
Se cre una instancia de Venta v (creaci n de instancia)

? Se inicializaron los atributos de v (modificacin de atributos)
/ cantidad
Contenidas-en
242
Tienda
1
1 Capturada-en 1
1 n
Contiene
1..n
1
Caja
1
Usada-por
1
CatalogoProductos
Se-usa-por
Cajero
nombre
243
244
61
?
?
Se cre una instancia de Venta v (creacin de instancia)

?
Caja es un candidato razonable para crear Venta, adems tendr

referencia a ella durante la ejecucin
Qu objeto debera crear la coleccin de LineaDeVenta?

Poscondiciones:
?

?
1: CrearNuevaVenta()
2: crear()
: Caja
Controlador
y Creador
3: crear()
: Venta
Caja crea Venta

por Creador
: LineaDeVenta
Venta crea multiobjeto

LineaDeVenta por Creador
245
1: IntroducirArticulo(id, cant)
: Caja
Contrato: TerminarVenta ()
Poscondiciones:
4: crearLineaVenta(espec, cant)
6: agregar(li)
: Venta
: LineaDeVenta
2: espec:=buscarEspecif(id)
5: crear(espec, cant)
:
CatalogoProductos
246
li : LineaDeVenta
Se modific el atributo v.Terminada a verdadero (modificaci n de

atributos)
3: espec:=buscar(id)
Multiobjetos, no
una instancia
247
248
62
1: TerminarVenta()
1: tot:=total()
Contrato: pagar (monto)

Precondiciones : Venta esta terminada
Poscondiciones:
2: Terminar()
: Caja
: Venta
2: st:=subtotal()
: Venta
3: pr:=precio()
: LineaDeVenta
Se cre una instancia de Pago p (creaci n de instancia)

p se asoci con la Venta actual (asociacin formada)
? Se modific el atributo p.monto (modificacin de atributos)
? p se asoci con Tienda para almacenar ventas completadas
(asociaci n formada)
Pseudocdigo
public void total()
{ int tot:=0
for each LineaDeVenta, li
tot:= tot + li.subtotal()
return total}
249
1: Pagar(monto)
2: pagar(monto)
: Caja
3: crear(monto)
v : Venta
Para el inicio de sistema, se deben crear lo siguiente:

?
Se crearon las instancias de Tienda, Caja, CatalogoProductos, y

Especificaci nProducto
? CatalogoProductos se asoci con EspecificacionesProductos
? Tienda se asoci con CatalogoProductos
? Tienda se asoci con Caja
? Caja se asoci con CatalogoProductos
: Pago
4: agregar(v)
5: agregar(v)
VentasTerminadas : Venta
: Tienda
250
3: t:=total()
1: vuelto:=calcularVuelto()
2: mnt:=obtenerMonto()
: Venta
: Pago
251
252
63

?
3: cargarEspecifProd()
Los diagramas deben prepararse con el propsito de

cumplir las poscondiciones del contrato
?
1: crear()
2: crear()
: Tienda
6: agregar(ep)
7: crear(cp)
Poscondiciones definidas de antemano son una excelente

conjetura o estimaci n inicial de lo que se pretende alcanzar
? Los contratos son un mero punto de partida para establecer lo que
se har, pero no son una obligacin
5: crear(id, precio, desc)

cp :
CatalogoProductos
ep :
4: crear()
: Caja
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
253
Visibilidad
Algunos de los objetos que interactan a travs de

mensajes en los diagramas de colaboracin provienen del
modelo del dominio
En parte, la eleccin de la asignacin acertada de las

responsabilidades mediante los patrones GRASP se funda
en la informacin contenida en el modelo del dominio
255
254
La visibilidad es la capacidad de un objeto para ver otro o

hacer referencia a l (Para que un objeto A enve un
mensaje a un objeto B, debe ser visible a aqul)
Los diagramas de colaboracin creados para los eventos
del sistema (introducirArticulo, por ejemplo) describen
grficamente los mensajes entre objetos
Para que un objeto emisor enve un mensaje a un objeto
receptor, el emisor tiene que ser visible a ste: debe tener
alguna clase de referencia o apuntador a l
256
64
Visibilidad
Visibilidad
Es preciso asegurarse de que exista la visibilidad

necesaria pues de otro modo no podr darse soporte a la
interaccin de los mensajes
Class Caja
{
private cp CatalogodeProd;
introducirArticulo(id, cant)
Visibilidad de atributos: B es un atributo de A

Visibilidad de parmetros: B es un parmetro de un mtodo de A
? Visibilidad declarada localmente: se declara que B es un objeto
local en un mtodo de A
? Visibilidad global: en alguna forma B es visible globalmente
?
: Caja
2: especif:=especificacion(id)
Cp: CatalogoProductos
Hay cuatro formas comunes de la visibilidad del objeto A al

objeto B:
Caja introducirArticulo (id,cant)

{
especif:= cp.especificacion (id)
}
257
Visibilidad de atributos
Visibilidad de atributos
Existe visibilidad de atributos de A a B cuando B es un

atributo de A
Se trata de una visibilidad relativamente permanente porque

persiste mientras existan A y B
? Es una forma muy comn de visibilidad en los sistemas orientados
a objetos
? Por ejemplo, en una definicin de Caja en una clase de java, esta
instancia puede tener visibilidad de atributo para un
CatalogoProductos por ser un atributo (variable de instancia en
java) de Caja
public class Caja
{
private cp CatalogoProductos;
}
En el diagrama de colaboracin introducirArticulo de la

figura, se necesita una instancia Caja que enve el
mensaje especificacin a una instancia CatalogoProductos
Class Caja
{
private cp CatalogodeProd;
introducirArticulo(id, cant)
: Caja
Cp: CatalogoProductos
259
258
Caja introducirArticulo (id,cant)

{
especif:= cp.especificacion (id)
}
260
65
Visibilidad de parmetros
?
?
Existe visibilidad de parmetros de A a B cuando B se

transmite como un parmetro a un m todo de A
Se trata de una visibilidad relativamente temporal porque
persiste slo dentro del mbito del mtodo
Despus de la visibilidad de atributos, es la segunda forma ms

comn de visibilidad en los sistemas orientados a objetos
? Ejemplo: cuando el mensaje crearLineaVenta se enva a una
instancia Venta, una instancia EspecificacionProducto es
transferida como parmetro. Dentro del mbito del mtodo
crearLineaVenta, la Venta tiene visibilidad de parmetro para
:
CatalogoProductos
li : LineaDeVenta
Multiobjetos, no
una instancia
261
Visibilidad declarada localmente
Con frecuencia la visibilidad de parmetros se transforma

en visibilidad de atributos
As, cuando la Venta crea una nueva instancia LineaDeVenta,

transmite una EspecificacionProducto a su mtodo de inicializacin
? Dentro del mtodo de inicializacin, se asigna el parmetro a un
atributo y con ello se logra la visibilidad de atributos
Existe una visibilidad declarada localmente de A a B,

cuando se declara que B es un objeto local dentro de un
mtodo de A
Se trata de una visibilidad relativamente temporal porque persiste
slo dentro del mbito del mtodo
? Despus de la visibilidad de parmetros, es la tercera forma ms
comn de visibilidad en los sistemas orientados a objetos
Existen dos formas de hacerlo:

?
?
263
262
: LineaDeVenta
?
6: agregar(li)
: Venta
: Caja
Crear una nueva instancia local y asignarla a una variable local

Asignar a una variable local el objeto devuelto proveniente de l a
llamada a un mtodo
264
66
Se produce una variacin de (2) cuando el m todo no

declara de manera explcita una variable, pero existe
implcitamente una como resultado de un objeto devuelto
procedente de la invocacin de un mtodo
Igual que en la visibilidad de parmetros, a menudo la
visibilidad declarada localmente es transformada en
visibilidad de atributo
Un ejemplo de la segunda variacin se encuentra en el
mtodo introducirArticulo de la clase Caja
: Caja
6: agregar(li)
: Venta
: LineaDeVenta
:
CatalogoProductos
li : LineaDeVenta
Multiobjetos, no
una instancia
265
266
Visibilidad global
Presentacin de la visibilidad en el UML
?
?
Existe visibilidad global de A a B cuando B es global para

A
Se trata de una visibilidad relativamente permanente,
porque persiste mientras existan A y B. Es el tipo de
visibilidad menos frecuente en los sistemas orientados a
objetos
La forma m s obvia - aunque menos conveniente - de
alcanzar la visibilidad global consiste en asignar una
instancia a una variable global
Estos elementos decorativos son opcionales y

normalmente no se requieren; son de gran utilidad cuando
hace falta la clarificacin
1: mens()
:A
<<atributo>>
:B
2: mens()
3: mens()
<<parametro>>
<<local>>
:C
:D
4: mens()
<<global>>
267
:E
268
67
Modelo de Diseo
Modelo de Diseo
Diagrama de Clases
Diagrama de Clases
Adems de las asociaciones y de los atributos b sicos, el

diagrama incluye los mtodos de cada clase, la
informacin sobre el tipo de los atributos, su visibilidad y la
navegacin entre objetos
?
El siguiente diagrama de clases contiene una definicin parcial de

software de las clases Caja y Venta
Casilla de tres
secciones
para las
definiciones
de clase
Venta
fecha
hora
Terminada
Caja
fecha
hora
Captura
1
total( )
crearLineaVenta( )
El diagrama de clases de diseo describe grficamente las

especificaciones de las clases de software y de las
interfaces en una aplicacin
Normalmente contiene la siguiente informacin:
?
clases, asociaciones y atributos

interfaces, con sus operaciones y constantes
? mtodos
? informaci n sobre los tipos de los atributos
? navegabilidad
? dependencias
?
Mtodos
Navegabilidad
269
Modelo de Diseo
Modelo de Diseo
Diagrama de Clases
Cmo elaborar un diagrama de clases del diseo
A diferencia del modelo del dominio, un diagrama de este

tipo contiene las definiciones de las entidades del software
en vez de conceptos del mundo real
?
UML no define concretamente un elemento denominado "diagrama

clases del diseo, sino que se sirve de un trmino ms genrico:
diagrama de clases
271
270
Identifique todas las clases que participan en la solucin del

software. Para ello analice los diagramas de interaccin
? Dibjelas en un diagrama de clases
? Duplique los atributos provenientes de los conceptos asociados del
modelo del dominio
? Agregue los nombres de los mtodos analizando los diagramas de
interacci n
? Incorpore la informaci n sobre los tipos a los atributos y a los
mtodos
? Agregue las asociaciones necesarias para dar soporte a la
visibilidad requerida de los atributos
? Agregue flechas de navegabilidad a las asociaciones para indicarla
direcci n de la visibilidad de los atributos
? Agregue las lneas de relaciones de dependencia para indicar la
visibilidad no relacionada con los atributos
272
68
Modelo de Diseo
Modelo de Diseo
Modelo del dominio y diagramas de diseo
Elaboracin del modelo de clases
En el modelo del dominio una Venta no representa una

definicin de software; m s bien una abstraccin de un
concepto del mundo real acerca del cual queremos afirmar
algo
En cambio, los diagramas de clases del diseo expresan para el sistema computarizado - la definicin de clases
como componentes del software. En estos diagramas una
Venta representa una clase de software
?
?
El primer paso en la preparacin de estos diagramas como

parte del modelo de la solucin consiste en identificar las
clases que intervienen en la solucin del software
Podemos encontrarlas con slo examinar todos los
diagramas de interaccin y listar las clases mencionadas.
En las aplicaciones de punto de venta ellas son:
273
Caja CatalogoProductos Tienda Pago

Venta EspecificacionProducto LineaDeVenta
El siguiente paso consiste en dibujar un diagrama de

clases para estas clases e incluir en el modelo del dominio
los atributos ya identificados
Modelo de Diseo
Modelo de Diseo

?
descripcin
precio
id
LineaDeVenta
/ cantidad
?
Tienda
Pago
monto
Venta
fecha
hora
Terminada : Boolean
CatalogoProductos
274
Ntese que los conceptos del modelo del dominio, entre

ellos Cajero, Gerente y Articulo, no aparecen en el diseo.
No es necesario - en el actual ciclo de desarrollo representarlos en el software
Pero en ciclos ulteriores podemos incorporarlos al diseo,
conforme vayamos descubriendo nuevos requerimientos y
casos de uso
Caja
275
276
69
Modelo de Diseo
Modelo de Diseo
Aspectos relativos a los mtodos
En trminos generales, el
conjunto de los mensajes
enviados a la clase X a travs de
los diagramas de colaboracin
indica la mayora de los mtodos
que ha de definir la clase X
Para identificar los mtodos de
las clases se analizan los
diagramas de colaboracin
?
: Caja
Por ejemplo, si el mensaje

crearLineaVenta se env a a una
instancia de la clase Venta,
entonces sta deber definir el
mtodo crearLineaVenta
: Venta
Los siguientes aspectos especiales deben tenerse en

cuenta respecto a los mtodos:
?
Interpretacin del mensaje crear0

Descripcin de los m todos de acceso
? Interpretacin de los mensajes dirigidos a multiobjetos
? Sintaxis dependiente del lenguaje
?
Venta
fecha
hora
Terminada : Boolean
terminar()
calcularVuelto()
total()
CrearLineaVenta()
277
Modelo de Diseo
Modelo de Diseo
Aspectos relativos a los mtodos: crear
Aspectos relativos a los mtodos: acceso
El mensaje crear es la forma independiente del lenguaje

UML con que se indica instanciacin e inicializacin
?
Cuando traducimos el diseo a un lenguaje de programacin

orientado a objetos, hay que expresarle en trminos de sus
expresiones de instanciacin e inicializacin
Los mtodos de acceso son aquellos que recuperan

(mtodo accesor) o establecen (m todo mutador) el valor
de los atributos
?
Se acostumbra omitir los mtodos relacionados con la

creacin y los constructores procedentes del diagrama de
clases del diseo
279
Una estructura comn consiste en contar con un accesor y con un

mutador por cada atributo y declarar privados todos los atributos
(para obligar el encapsulamiento)
Normalmente, estos mtodos no se incluyen en la

descripcin del diagrama de clase por la elevada razn
ruido a valor que generan: para N atributos hay 2N
mtodos sin el menor inters
?
278
Por ejemplo, no se muestra el mtodo precio de

EspecificacionProducto (u obtenerPrecio) aunque est presente,
por ser precio un mtodo accesor simple
280
70
Modelo de Diseo
Modelo de Diseo
Aspectos relativos a los mtodos: multiobjetos
Aspectos relativos a los mtodos: multiobjetos
Un mensaje a un multiobjeto se interpreta como si

estuviera destinado al objeto contenedor/coleccin
Por tanto, el mtodo buscar no forma parte de la clase

EspecificacionProducto , sino m s bien de la definicin de
la clase
?
: CatalogoProductos
El mensajeencontrar()
esta destinado al objeto
contenedor, no auna
EspecificaionProducto
3: especif:=buscar(id)
Es, pues, incorrecto agregar buscar como mtodo a la clase

Las clases contenedor/coleccin son clases predefinidas

de las bibliotecas, y rara vez sirve mostrarlas
explcitamente en el diagrama porque incorporan ruido y
aportan escasa informacin nueva
: EspecificacionProducto
281
Modelo de Diseo
Modelo de Diseo
?
?
Es opcional mostrar el tipo de los atributos, los parmetros

del mtodo y los valores de retorno del m todo
El diagrama de clases orientado al diseo debera
elaborarse teniendo en cuenta la audiencia:
?
Si vamos a crearlo en una herramienta CASE con generacin

autom tica de cdigo se requerirn detalles completos y exhaustivos
Si vamos a crearlo para los diseadores de software, el exceso de
informacin puede influir negativamente en su efectiva comprensin
La siguiente figura muestra el diagrama de clases con la

informacin sobre los tipos
Tienda
name : String
adress : String
AgregarVenta()
CrearNuevaVenta()
IntroducirArticulo()
TerminarVenta()
Pagar()
283
CatalogoProductos
buscarEspecif()
cargarEspecifProd()
descripcin : String
precio : Integer
id : Long
Venta
Caja
282
fecha : Date
hora : Integer
Terminada : Boolean
LineaDeVenta
cantidad : Integer
subtotal()
terminar()
calcularVuelto()
total()
crearLineaVenta()
pagar()
Pago
monto : Integer
284
71
Modelo de Diseo
Modelo de Diseo
Incorporacin de asociaciones y de navegabilidad
Se da el nombre de papel al fin de una asociacin; en los

diagramas de clases orientados al diseo podemos
adornar el papel con una flecha de navegabilidad
La navegabilidad es una propiedad del papel e indica la
posibilidad de navegar unidireccionalmente en una
asociacin, desde los objetos fuente hasta la clase destino
La navegabilidad significa visibilidad; generalmente la
visibilidad de los atributos
La ausencia de la flecha de
nevegabilidad indica que no
existe conexi n de Venta a
Caja
Venta
fecha : Date
hora : Integer
Terminada : Boolean
Caja
Captura
CrearNuevaVenta()
1
TerminarVenta()
Pagar()
La clase Caja
probablemente tenga algn
atributo que apunta a Venta
terminar()
calcularVuelto()
total()
crearLineaVenta()
pagar()
La flecha de navegabilidad
indica que los objetos
Caja estn conectados
unidireccionalmente con
los objetos Venta
285
Modelo de Diseo
Modelo de Diseo
En un diagrama de este tipo, las asociaciones se escogen

con un riguroso criterio que est orientado al software y
que se rija por la necesidad de conocer:
?
Cules asociaciones se requieren para satisfacer con los

diagramas de interaccin la visibilidad y la necesidad de
almacenamiento permanente?
La visibilidad y las asociaciones requeridas entre las clases

se indican con los diagramas de interaccin
Tres situaciones comunes que revelan la necesidad de
definir una asociacin con una flecha de navegabilidad de
AaB
?
A enva un mensaje a B
A crea una instancia B
? A necesita mantener una conexin con B
?
Esto contrasta con las asociaciones en el modelo del

dominio, que pueden justificarse por la intencin de
mejorar la comprensin del dominio del problema
286
287
288
72
Modelo de Diseo
Modelo de Diseo
Por ejemplo, podemos observar que la Tienda probablemente

tenga una conexin permanente con las instancias que genera
? Tambin es razonable que CatalogoProductos necesite una
conexi n permanente con la coleccin de EspecificacionProducto
que genere
Tienda
n
AgregarVenta()
1
3: cargarEspecifProd()
CatalogoProductos
Usa
name : String
adress : String
buscarEspecif()
cargarEspecifProd()
Contenida-en descripcin : String
precio : Integer
1
n id : Long
1
Mira-en
Describe
Aloja
Venta
1..n
Caja
1: crear()
2: crear()
5: crear(id, precio, desc)

cp :
ep :
CatalogoProductos
: Tienda
6: agregar(ep)
7: crear(cp)
CrearNuevaVenta()
1
TerminarVenta()
Pagar()
Terminadas
4: crear()
fecha : Date
hora : Integer
Terminada : Boolean
1
Captura
terminar()
calcularVuelto()
total()
n crearLineaVenta()
pagar()
n
LineaDeVenta
Contiene
1
cantidad : Integer
n
subtotal()
1 Pago
monto : Integer
1 Pagada-por
: Caja
289
Modelo de Diseo
Modelo de Diseo
Agregacin de las relaciones de dependencia
Ntese que ste no es exactamente el mismo conjunto de

asociaciones que el generado para los diagramas de
clases en el modelo de investigacin
El UML incluye una relacin general de dependencia, la

cual indica que un elemento (de cualquier tipo como
clases, casos de uso y otros) conoce la existencia de otro
En cambio, la visibilidad simple de atributos se indica con

una flecha normal de asociacin y con una flecha de
navegabilidad
Por ejemplo, no exista la asociacin Mira -en entre Caja y

CatalogoProductos en el modelo del dominio: en ese momento no
se descubri que fuera una relacin importante ni duradera
? Pero durante la preparacin de los diagramas de colaboracin se
decidi que el objeto de software Caja debera tener una conexin
permanente con un software CatalogoProductos a fin de consultar
291
290
Se denota con una l nea punteada y con flecha
292
73
Modelo de Diseo
Modelo de Diseo
Por ejemplo, el objeto de software Caja recibe un objeto

devuelto del tipo EspecificacionProducto proveniente del
mensaje de especificacin que envi a un
CatalogoProductos
As, Caja tiene una visibilidad de corto plazo localmente
declarada en EspecificacionProducto, y Venta recibe una
EspecificacionProducto como parmetro en el mensaje
crearLineaVenta tiene la visibilidad del parmetro
Estas visibilidades no relacionadas con atributos pueden
denotarse con la lnea punteada y con flecha para indicar
una relacin de dependencia
Tienda
name : String
adress : String
1
CatalogoProductos
Usa
n
AgregarVenta()
1
buscarEspecif()
cargarEspecifProd()
1
Mira-en
Describe
Aloja
Venta
1..n
Caja
fecha : Date
hora : Integer
Terminada : Boolean
1
Captura
CrearNuevaVenta()
1
TerminarVenta()
Pagar()
Terminadas
293
terminar()
calcularVuelto()
total()
n crearLineaVenta()
pagar()
Modelo de Implementacin
Mapeando diseo a cdigo
?
?
295
cantidad : Integer
n
subtotal()
1 Pago
monto : Integer
1 Pagada-por

Proceso unificado define el modelo de implementacin
como el conjunto de cdigo fuente, definiciones de bases
de datos, pginas html/xml/jsp, etc
Diagramas de colaboracin y diagrama de clases de
diseo son los utilizados para generar cdigo
Los resultados obtenidos durante el diseo es un paso
incompleto, en la codificacin y las pruebas se realizarn
una multitud de cambios en donde se descubrirn y
resolvern problemas detallados
n
LineaDeVenta
Contiene
?
precio : Integer
1
n id : Long
294
El desarrollo de Software OO es un proceso iterativo e

incremental
?
Una ventaja de ello es que se pueden introducir los resultados del

ciclo anterior en la etapa siguiente
? As, se genera un proceso de mejora continua
?
Para apoyar el proceso de construccin y modificacin de

los diferentes diagramas es conveniente utilizar una
herramienta CASE
296
74

?
Ciclos Iterativos
de Desarrollo
Para la construccin del programa se requiere escribir

cdigo para:
?
?
Anlisis de
Requerimientos
Anlisis de
Requerimientos
Definir las clases (con sus atributos)

Definir los mtodos
Anlisis de
Requerimientos
?
Diseo
Diseo
Diseo
Implementacin
y Pruebas
Implementacin
y Pruebas
Implementacin
y Pruebas
Los diagramas de clases de diseo describen por lo menos

el nombre de las clases, las superclases, las etiquetas de
los mtodos y los atributos simples de una clase
?
Esta informacin es suficiente para formular una definici n bsica

de clase en un lenguaje Orientado a Objetos
Tiempo
297
El diagrama de clases de diseo facilita el mapeo de las

definiciones b sicas de los atributos y las etiquetas de
los mtodos
Un atributo de referencia es aquel que remite a otro objeto

complejo, no a un tipo primitivo como String por ejemplo
? Estos estn indicados por las asociaciones y la navegabilidad en
un diagrama de clases
n
LineaDeVenta
subtotal()
Public Class LineaDeVenta

{
Public LineaDeVenta(EspecificacionProducto especif, int cantidad);
//derivado del mensaje crear(especif, cant) del diagrama IntroducirArticulo
Private int cantidad;
Public int subtotal();
}
Nombre de papeles para atributos de referencia:

?
cantidad : Integer
Adicin de los atributos de referencia

?
descripcin : String
precio : Integer
id : Long
Describe
298
299
A cada fin o extremo de una asociaci n se le da el nombre de papel

Si el nombre del papel se encuentra en un diagrama de clase
utilcelo como criterio para elegir el nombre del atributo de
referencia durante la generacin del cdigo
300
75
Ejemplo: Definir clase LineadeVenta en JAVA
Un diagrama de colaboracin muestra los mensajes que se

envan en respuesta a una llamada al mtodo
?
descripcin : String
precio : Integer
id : Long
Atributo de
referencia
6: agregar(li)
: Venta
: LineaDeVenta
Nombre del papel usado

en el nombre del atributo
n
LineaDeVenta
cantidad : Integer
Atributo simple
: Caja
1 +EspecifProd
Describe
subtotal()
Considere el siguiente diagrama de colaboracin introducirArticulo
:
CatalogoProductos
Public Class LineaDeVenta

{
Public LineaDeVenta(EspecificacionProducto especif, int cantidad);
Private int cantidad;
Public EspecificacinProducto EspecifProd;
Public int subtotal();
}
li : LineaDeVenta
301
Clases de contenedor/coleccin en cdigo
Considerar el siguiente diagrama de clases para Caja

CatalogoProductos
buscarEspecif()
cargarEspecifProd()
Public Class Caja

{
Private CatalogoProductos catalogo;
Private Venta venta;
Public Caja (CatalogoProductos cp);
A menudo un objeto debe conservar la visibilidad de un

grupo de otros objetos
?
Mira-en
302
Esto se pone de manifiesto generalmente con el valor de la

multiplicidad que presenta un diagrama da clases
Venta
Caja
CrearNuevaVenta()
1
TerminarVenta()
Pagar()
Public void TerminarVenta() {...};

Public void IntroducirArticulo(long idArt, int cant)
{
EspecificacinProducto especif = catalogo.buscarEspecif(idArt);
venta.crearLineaVenta(especif, cant);
};
...
}
fecha : Date
hora : Integer
Terminada : Boolean
1
Captura
1
terminar()
calcularVuelto()
total()
crearLineaVenta()
pagar()
303
En los lenguajes de programacin OO estas relaciones a

menudo se implementan introduciendo un contenedor o
coleccin intermedios
?
La clase de multiplicidad uno define un atributo de referencia que

apunta a una instancia contenedor/coleccin, el cual contiene
instancias de la clase con multiplicidad muchos
304
76
Clases de contenedor/coleccin en cdigo
Manejo de excepciones y errores
Ejemplo: Una Venta ha de conservar la visibilidad de un

grupo de instancias LineadeVenta
Public Class Venta

{
...
Private List lineas_venta = new ArrayList();
Public void crearLineaVenta(especificacinProducto especif, int

cant)
{
lineas_venta.add(new LineaDeVenta(especif, cant));
};
...
: Caja
6: agregar(li)
: Venta
En una aplicacin concreta conviene ocuparse del manejo

de errores en la fase de diseo
Ejemplo: Se pueden comentar los contratos anexndoles
una breve explicacin de las situaciones ordinarias de los
errores y el plan general de la solucin
UML no cuenta con una notacin especial para indicar las
excepciones
: LineaDeVenta
Se indican con la notacin de los diagramas de colaboracin

basados en los mensajes
li : LineaDeVenta
305
Orden de Implementacin
Resumen
Es necesario implementar las clases de la menos acoplada a la ms

acoplada
7
Tienda
name : String
adress : String
n
AgregarVenta()
1
CatalogoProductos
Usa
buscarEspecif()
cargarEspecifProd()
1
Mira-en
1 +EspecifProd
Describe
Venta
fecha : Date
hora : Integer
Terminada : Boolean
1
Captura
CrearNuevaVenta()
1
TerminarVenta()
Pagar()
Terminadas
EspecificacinProducto 2
precio : Integer
1
n id : Long
Aloja
1..n
Caja
terminar()
calcularVuelto()
total()
n crearLineaVenta()
pagar()
n
LineaDeVenta
Contiene
1
306
El proceso de traducir a definiciones de clases los

diagramas del diseo y traducir a mtodos los diagramas
de colaboracin es sencillo
La arquitectura global y las decisiones ms importantes ya
se establecieron totalmente antes de que empiece la fase
de codificacin
?
Aunque se realizan numerosos cambios en el diseo mientras se

codifica
cantidad : Integer
n
subtotal()
1 Pago 1
monto : Integer
1 Pagada-por
307
308
77
Iteracin 2
Iteracin 2
Introduccin
Mltiples Casos de Uso
Se acostumbra utilizar muchas veces un mismo caso de

uso en varios ciclos de desarrollo y ampliarlo despus para
alcanzar la funcionalidad que se requiere
La funcionalidad a complementar consiste en:
Dar soporte a los pagos en efectivo, con tarjeta de crdito y con

cheque
? Actualizar la ventana de la interfaz con el total
Podemos expresar los procesos relacionados con diversas

formas de pago en la aplicacin del punto de venta como
casos de uso independientes y relacionarlos con otros
casos
El lenguaje UML tiene una notacin especial para indicar
las relaciones de los casos de uso
309
Iteracin 2
Iteracin 2
CU1: Realizar Venta

CU2: Realizar Arriendo

1. Cliente llega a la caja con productos o servicios que desea

comprar.
7. Cliente paga y sistema maneja el pago.
310
6a: Cliente paga en efectivo
6b: Cliente paga con Tarjeta de Crdito: Incluir Pagar-a-crdito

6b: Cliente paga con cheque: Incluir Pagar-con-cheque

7a: Cliente paga en efectivo
7b: Cliente paga con Tarjeta de Crdito: Incluir Pagar-a-crdito

7b: Cliente paga con cheque: Incluir Pagar-con-cheque
311
312
78
Iteracin 2
Iteracin 2
CU12: Pagar-a-crdito
Nivel: subfuncin
Escenario principal:
1.
2.
3.
Separe una subfuncin de un caso de uso cuando:

?
?
Cliente ingresa la informaci n de la tarjeta de crdito.

Sistema enva la solicitud de autorizaci n de pago a un servicio de
autorizacin, y solita la aprobaci n de pago.
Prefiera relacin de inclusin entre casos de uso por

sobre otras relaciones
?
Est duplicada en otros casos de uso

El caso de uso es muy complejo y largo, separndolo en partes
mejora su comprensi n
Ms fcil entendimiento
2a: Sistema detecta fallas de comunicacin con el servicio de

autorizacin
1. Sistema indica el error al Cajero.
2. Cajero solicita al Cliente cambiar el medio de pago.
313
Iteracin 2
Iteracin 2
?
?
Supongamos que el caso de uso principal ha sido

implementado completamente, y ya no se puede modificar
Cmo se puede agregar algo, sin modificar el texto
original?
CU15: Pagar con certificado de regalo

Gatillo: Cliente quiere pagar con
Puntos de Extensin: Pago en el cu Realizar Venta.
1. Cliente entrega el certificado de regalo al Cajero.
CU1: Realizar Venta

Puntos de Extensin: Pago, paso 7; Cliente Vip, paso 1.
1. Cliente llega a la caja con productos o servicios que desea
comprar.
314
315
Muchas veces, se utiliza la relacin de extensin para

evitar crear casos de uso complejos
316
79
Iteracin 2
Iteracin 2
Extensin del modelo del dominio
Modificacin del diagrama de casos de uso
Realizar Venta
<<include>>
<<include>> <<include>>
Cajero
Pagar-con-cheque
Pagar-en-Efectivo
Servicio
Autorizacin
Pagar-a-crdito
<<include>>
<<include>>
<<include>>
Igual que en el primer ciclo de desarrollo, podemos

desarrollar poco a poco el modelo del dominio
considerando los casos de uso actuales en el segundo
ciclo
Primero, repasamos la lista de categoras de conceptos y
luego aplicamos la identificacin de frases nominales o
sustantivos a partir de los casos de uso (con la advertencia
de que este segundo m todo exige mucha sensatez y
prudencia)
Sistema Contable
Realizar Prestamo
317
Iteracin 2
Iteracin 2
La siguiente tabla tan slo contiene los conceptos nuevos en el

problema del sistema del punto de venta
Categora
Ejemplos
otros sistemas de cmputo, o

electromecnicos externos a nuestro
sistema
ServicioAutorizacion
Categora
Ejemplos
conceptos sustantivos abstractos
objetos fsicos o tangibles
TarjetadeCredito, Cheque
organizaciones
especificaciones, diseos o descripciones de

cosas
eventos
reglas y polticas
lugares
transacciones
318
catlogos registros de finanzas, de trabajo,

de contratos, de asuntos legales
PagoEfectivo, PagoCredito, PlagoCheque
transacciones con lneas de producto
instrumentos y servicios financieros
papeles de las personas

contenedores de otras cosas
manuales, libros
319
CuentasPorCobrar
320
80
Iteracin 2
CU12: Pagar-a-crdito
Nivel: subfunci n

?
La identificacin de las frases nominales o nombres

sustantivos no puede aplicarse mecnicamente para
descubrir los conceptos pertinentes que incluiremos en un
modelo del dominio
Es necesario recurrir al sentido comn y a las
abstracciones idneas, pues el lenguaje natural es
ambiguo y los conceptos relevantes no siempre se
expresan de un modo explcito o claro en el texto
No obstante, es un procedimiento prctico en la
construccin de modelos conceptuales por su gran
simplicidad
1. Cliente ingresa la informacin de la tarjeta de cr dito.

2. Sistema env a la solicitud de autorizacin de pago a un servicio de
autorizacin, y solicita la aprobaci n de pago.
3. Sistema recibe la aprobacin de pago y seala la aprobacin al cajero
4. Sistema almacena el pago a cr dito, que incluye la aprobacin de pago.
5. Sistema presenta el mecanismo de ingreso de firma.
6. Cajero solicita al Cliente firmar. Cliente firma.

2a: Sistema detecta fallas de comunicaci n con el servicio de autorizacin
3a: Sistema recibe la reprobacin de crdito.
1. Sistema indica la reprobacin al Cajero.
321
322
Iteracin 2
CU13: Pagar-con-cheque
Nivel: subfunci n
1. Cliente escribe el cheque, se lo entrega al Cajero junto con su Cdula de

Identidad.
2. Cajero escribe el nmero de CI al reverso del cheque, lo ingresa, y solicita
la aprobacin de pago.
3. Sistema genera la solicitud de pago con chequey la env a al Servicio
de Aprobacin.
4. Sistema recibe la aprobacin de pago y seala la aprobacin al cajero
4. Sistema almacena el pago con cheque, que incluye la aprobacin de
pago.
En la figura se incluye el modelo del dominio preliminar que se basa en

la identificacin de conceptos mediante la lista de comprobaci n y la
identificaci n de sustantivos
Tienda
Venta
2a: Sistema detecta fallas de comunicaci n con el servicio de autorizacin

3a: Sistema recibe la reprobacin de pago con cheque.
1. Sistema indica la reprobacin al Cajero.
TarjetaCrdito
Caja
CatalogoProductos
Servicio Autorizacin
Cheque
LineaDeVenta
PagoEfectivo
PagoCheque
Pago
PagoCrdito
CuentasPorCobrar
323
324
81
Modelo del Dominio
Modelo del Dominio
Generalizacin
Generalizacin
Los conceptos de PagoEfectivo, PagoTarjeta y

PagoCrdito se parecen mucho
?
En este caso es posible (y til) organizarlos en una jerarqua de tipo

generalizacin - especializacin (o simplemente en una jerarqua
de tipo) en la cual el supertipo Pago represente un concepto ms
general y los subtipos, conceptos ms especializados
PagoEfectivo
PagoCheque
Identificar los supertipos y los subtipos es una labor til en un

modelo del dominio, porque su presencia nos permite entender los
conceptos en trminos ms generales, ms complejos y ms
abstractos
? Favorece la simplificacin de la expresi n, mejora la comprensin y
reduce la informacin redundante
Superclase:
concepto ms
general
Pago
PagoCrdito
Subclase:
concepto ms
especializado
La generalizacin es la actividad consistente en identificar

los aspectos comunes de los conceptos y en definir las
relaciones entre el supertipo (concepto general) y el
subtipo (concepto especializado)
Identifique los supertipos y subtipos del dominio que se

relacionan con la investigacin en curso y descrbalos
grficamente en el modelo del dominio
325
Modelo del Dominio
Modelo del Dominio
Generalizacin
Generalizacin
En el lenguaje UML, la relacin de generalizacin entre los

elementos se indica con una punta de flecha grande y
hueca que seala el elemento ms general partiendo del
ms especializado
?
Puede emplearse un estilo de flechas separadas o de una flecha

compartida
Pago
PagoEfectivo
PagoCheque
Pago
PagoCrdito
PagoEfectivo
PagoCheque
?
?
326
Qu relacin existe entre un supertipo y un subtipo?

La definicin de un supertipo es ms general o amplia que
la de un subtipo
?
Consideremos, por ejemplo, el supertipo Pago y sus subtipos

(PagoEfectivo y otros)
? Supongamos que, segn su definicin, Pago representa la
transaccin de transferir dinero (no necesariamente efectivo) de
una entidad a otra en una compra y que en todos los pagos se
refiere cierta cantidad de dinero
PagoCrdito
327
328
82
Modelo del Dominio
Modelo del Dominio
Generalizacin
Generalizacin
Paga
Pago
monto : Integer
Venta
1
?
PagoEfectivo
PagoCheque
PagoCrdito
Los subtipos y los supertipos estn relacionados por su

pertenencia a un conjunto
Todos los miembros de un conjunto de subtipo pertenecen
al respectivo conjunto de supertipo
?
Un PagoCrdito es una transferencia de dinero que se

realiza a travs de una institucin de crdito y que ha de
ser autorizada
La definicin de Pago abarca la de PagoCrdito y es ms
general que ella
Por ejemplo, todas las instancias del conjunto PagoCrdito tambin

son miembros del conjunto de Pago
Pago
PagoEfectivo
329
PagoCrdito
Modelo del Dominio
Modelo del Dominio
Generalizacin
Generalizacin
Cuando se crea una jerarqua de tipos, en torno a los

supertipos se hacen afirmaciones que se aplican tambin a
los subtipos
?
?
?
As, la figura seala que todos los Pagos tienen un monto y que se
asocian a una Venta
PagoEfectivo
Venta
1
PagoCheque
330
Una subclase potencial debe cumplir con las siguientes

reglas
Regla de 100%:
Paga
Pago
monto : Integer
PagoCheque
El 100% de la definicin del supertipo debera aplicarse tambin al

subtipo. ste ha de conformarse con el supertipo al 100% de sus
atributos y asociaciones
Regla es-un:
?
Todos los miembros de un conjunto de subtipos han de pertenecer

a su conjunto de supertipos
PagoCrdito
331
332
83
Modelo del Dominio
Modelo del Dominio
Cundo definir un subtipo?
?
?
Una particin de tipo es una divisin del tipo en subtipos

disjuntos
La pregunta tambin puede plantearse as : cundo
conviene mostrar una particin de tipos?
?
El subtipo tiene otros atributos ms de inters

El subtipo tiene otras asociaciones ms de inters
? Se opera sobre el concepto del subtipo, se maneja, se reacciona
ante l o se manipula de modo diferente a como se hara con el
supertipo u otros subtipos, todo ello en aspectos que resultan
relevantes
? El concepto de subtipo representa una cosa animada (un robot o un
animal, por ejemplo) que se comporta de manera distinta al
supertipo o a otro subtipo en aspectos que resultan relevantes
?
Por ejemplo, en el dominio del punto de venta, Cliente puede

partirse (o dividirse en subtipos) correctamente en ClienteVarn y
en ClienteMujer Pero es relevante o til incluir esto en nuestro
modelo?
Cliente
ClienteVaron
Se crea un subtipo de un supertipo cuando:
ClienteMujer
333
Modelo del Dominio
Modelo del Dominio
?
?
Conforme a los criterios anteriores, no es obligatorio partir

Cliente en ClienteVarn y ClienteMujer porque no poseen
atributos ni asociaciones adicionales, no se opera sobre
ellos (ni se les trata) en forma diferente y tampoco
muestran un comportamiento distinto que resulte de inters
Los hbitos de compra de los hombres son distintos a los
de las mujeres
Pero tales diferencias no son importantes para los
requerimientos de nuestro caso de uso, lo cual constituye
el criterio que rige nuestra investigacin
335
El subtipo tiene otros atributos ms de inters

?
?
334
Pagos: no aplicable
Biblioteca: Libro , subtipo de Recurso-Prestable, tiene un atributo de
ISBN
El subtipo tiene otras asociaciones y comportamientos ms

de inters
?
Pagos: PagoconCredito, subtipo de Pago, se asocia a

TarjetaCredito y se maneja en forma distinta a otros tipos de pago
en lo tocante a la forma de autorizarse
? Biblioteca: Video, subtipo de Recurso- Prestable, se asocia a
Director
? Biblioteca: Software, subtipo de RecursoPrestable, requiere un
depsito para que se preste
336
84
Modelo del Dominio
Modelo del Dominio
El concepto de subtipo representa un ser animado (un

robot o un animal, por ejemplo) cuyo comportamiento
difiere del de otro supertipo o subtipos en aspectos que
resultan de inters
Pago
monto : Integer
Paga
Venta
Pagos: no aplicable
Biblioteca: no aplicable
? Investigacin de mercado: HumanoVaron, subtipo de Humano, no
se comporta igual que HumanoMujer respecto a los hbitos de
compra
PagoEfectivo
PagoCheque
n
Autoriza
PagoCrdito
n
Se-hace-con
1
TarjetaCrdito
Se-hace-con
1
Cheque
1
Servicio Autorizacin
Autoriza
1
337
Modelo del Dominio
Jerarquas de clases y herencia
Generalizacin
Una clase es una implementacin de un concepto o de un

tipo en software, y en un lenguaje de programacin
orientado a objetos una subclase hereda las definiciones
de atributos y de operaciones de sus superclases, gracias
a la creacin de jerarquas de clases
La herencia es un mecanismo de software que implementa
la conformidad de los subtipos con sus definiciones de
supertipo
Por tanto, la herencia no interviene en la explicacin de un
modelo del dominio, pero s lo hace cuando efectuarnos la
transicin a la fase de diseo
339
338
Modelo del Dominio

?
Transaccin
Autorizacin
Solicitud
Autorizacin
Respuesta
Autorizacin
Respuesta
Cheque
Aprobacin
Cheque
Reprobacin
Cheque
Respuesta
Crdito
Aprobacin
Crdito
Solicitud
Cheque
Solicitud
Crdito
Reprobacin
Crdito
El manejo de autorizaciones es un problema bastante

com n, pero no ser demasiado este nivel de
granularidad?
340
85
Modelo del Dominio
Modelo del Dominio
Generalizacin
Tipos Asociativos
Transaccin
Autorizacin
Los siguientes requerimientos del dominio preparan el

terreno para los tipos asociativos:
?
Respuesta
Autorizacin
Aprobacin
Cheque
Reprobacin
Cheque
Aprobacin
Crdito
Los servicios de autorizacin asignan a las tiendas una

identificaci n comercial que les permite identificarlas durante la
comunicacin
? Una solicitud de autorizacin de pago hecha por una tienda a un
servicio de autorizacin exige incluir la identificacin comercial que
la identifica ante l
? Adems, una tienda tiene una identificaci n comercial para cada
servicio
Solicitud
Autorizacin
Reprobacin
Crdito
Solicitud
Cheque
Solicitud
Crdito
Esta jerarqua ser suficiente para manejar los

requerimientos actuales, ya que no est claro que valor
agregan las clases adicionales
341
Modelo del Dominio
Modelo del Dominio
Tipos Asociativos
Tipos Asociativos
En qu parte del modelo del dominio debera residir el

atributo de identificacin (ID)?
?
Es incorrecto colocar idComercial en la Tienda porque una Tienda

puede tener ms de un valor de idComercial. Lo mismo sucede
cuando lo ponemos en ServicioAutorizacion
Tienda
direccion : Direccion
nombre : Texto
idComercial
Ambas inclusiones de id
Comercial son incorrectas,
Ya que puede haber ms de un
idComercial
direccion
nombre
idComercial
numero Telefnico
343
342
De lo que acabamos de decir extraemos el siguiente

principio de la construccin de modelos:
En un modelo del dominio, si un tipo T puede tener
simultneamente muchos valores para la misma clase de
atributo A, no coloque A en T. Pngalo en otro tipo que
est asociado a T
?
Por ejemplo: Una Persona puede tener muchos nmeros

telefnicos. Ponga el nmero en otro tipo - por ejemplo,
NumeroTelefonico o InformaciondeContacto- y asocie a Persona
muchos de ellos
344
86
Modelo del Dominio
Modelo del Dominio
Tipos Asociativos
Tipos Asociativos
Qu concepto registra formalmente la informacin

referente a los servicios que una compaa ofrece a un
cliente?: un Contrato o una Cuenta
?
Podemos modelar el ContratoServicio como un tipo asociativo

relacionado con la asociacin que existe entre Tienda y
? En el UML, esto se denota con una lnea punteada que de la
asociaci n se dirige al tipo asociativo
Podemos considerar la idComercial como un atributo relacionado

con la asociacin entre la Tienda y el ServicioAutorizacion
Compra
Vende
ContratodeServicio
idComercial
1..*
Tienda
ContratodeServicio
idComercial
direccion
nombre
numero Telefonico
Autoriza-pago-mediante
direccion : Direccion
nombre : Texto
*
Esto desemboca en el concepto de tipo asociativo en que

podemos agregar caractersticas a la asociacin
Tienda
direccion :Direccion
nombre :Texto
1..*
Un modelo mejor,
pero todavia no es
muy util .
Autoriza-pago-mediante
*
1..*
345
Modelo del Dominio
Tipos Asociativos
Agregacin y composicin
Indicaciones de que un tipo asociativo puede ser til en un

modelo del dominio:
?
Un atributo est relacionado con una asociacin

Las instancias del tipo asociativo presentan una dependencia de
toda la vida respecto a la asociacin
? Hay asociaciones de muchos a muchos entre los dos conceptos, y
la informacin se relaciona con la propia asociacin
? Slo existe una instancia del tipo asociativo entre dos objetos que
participan en la asociacin
? La presencia de la asociaci n de muchos a muchos es una
indicacin comn de que un tipo asociativo til se halla en alguna
parte del trasfondo; cuando vea uno, piense en la conveniencia de
utilizar un tipo asociativo
?
347
346
Modelo del Dominio

?
ServiciodeAutorizacion
direccion
nombre
numero Telefonico
?
?
La agregacin es una clase de asociacin con que se

modelan las relaciones de parte - todo entre las cosas
Al todo se le llama generalmente compuesto; en cambio,
las partes no tienen un nombre estndar: suele
designrseles simplemente como parte o componente
?
As, los ensambles fsicos se organizan en relaciones de

agregaci n; por ejemplo, una Mano agrega o conjunta Dedos
Mano
Dedo
1
0..
0..5
348
87
Modelo del Dominio
Modelo del Dominio
Agregacin y composicin: diamante sombreado
Agregacin y composicin: diamante en blanco
La agregacin compuesta, o simplemente composicin,

significa que la multiplicidad en el extremo correspondiente
al compuesto puede ser al mximo una
Indica que nicamente el compuesto posee la parte y que
se encuentra en una jerarqua de partes con estructura de
rbol; es la modalidad m s frecuente de agregacin que
encontrarnos en los modelos
?
La agregacin compartida significa que la multiplicidad en

el extremo del compuesto puede ser ms de una; se
denota con un diamante en blanco
Indica que la parte puede estar en muchas instancias
compuestas
?
La agregacin compartida rara vez existe en agregados fsicos,

pues ms bien la encontramos en conceptos no fsicos
? Por ejemplo, podemos considerar un paquete de UML para agregar
sus elementos
Por ejemplo, un dedo es parte de no ms de una mano y, por lo

mismo, el diamante de agregacin aparece sombreado para indicar
la agregacin compuesta
Curso
Alumno
*
349
Modelo del Dominio
Modelo del Dominio
Cmo identificar una agregacin?
En algunos casos la presencia de la agregacin no es tan

evidente
?
Al agregar: en caso de duda, no incluya el elemento
Estudie la conveniencia de mostrar la agregacin si:

?
La duracin de la parte es dependiente del compuesto

Existe un evidente ensamble fsico o lgico de parte-todo
? Algunas propiedades del compuesto se difunden hacia las partes,
entre ellas su ubicacin
? Las operaciones aplicadas al compuesto se propagan a las partes:
destruccin, movimiento, registro
?
Si excluimos el hecho de que algo sea un ensamblado evidente de

partes, la siguiente indicacin ms til es la dependencia de creareliminar que la parte presenta respecto al todo
351
350
Estudie la conveniencia de mostrar la agregacin si:

?
No es indispensable ni identificar ni mostrar la agregaci n; nada

impide que excluyamos ambas actividades en un modelo del
dominio
? Aclara las restricciones del dominio concernientes a la existencia
elegible de la parte independiente del todo. En la agregacin
compuesta, la parte no puede existir fuera de la duraci n del todo
? Durante la fase de solucin, ello repercute en las dependencias
creareliminar que presentan las clases de software de parte-todo
? Ayuda a identificar al creador (el compuesto) por medio del patrn
Creador de GRASP
? Las operaciones - como copiar o eliminar- que se aplican al todo
deberan propasarse a las partes
? El identificar un todo en relaci n con una parte da soporte al
encapsulamiento
352
88
Modelo del Dominio
Iteracin 2
Diagramas de secuencia del sistema
En el dominio del punto de venta, la instancia

LineaDeVenta es parte de un compuesto Venta
?
Adems de la conformidad con ese patrn, se observa una

dependencia crear-eliminar en la l nea de productos de la Venta: su
duraci n no rebasa la de la Venta
En el segundo ciclo de desarrollo, los diagramas de

secuencia del sistema han de soportar la ramificacin de
los tipos de pago que se producen en ella
Similarmente, la instancia CatalogoProductos es un

agregado de EspecificacionProducto
Venta
LineaDeVenta
1
n
CatalogoProductos
1
n
353
Iteracin 2
Iteracin 2
Inicio comn de Realizar Venta es omitido
: Cajero
: Sistema
: Servicio
Autorizacin
354
Pago con cheque
: Sistema Contable
PagarCrdito(numTarjeta, fecha_exp)
: Sistema
: Cajero
resp:=solicitarAprobar(solicitud)
: Servicio
Autorizacin
PagarCheque(RUT)
RecibirPago(respuesta)
resp:=solicitarAprobar(solicitud)
RecibirVenta(venta)
355
356
89
Iteracin 2
Iteracin 2
Contratos
Contratos
Operacin: PagarCrdito(numTarjeta, fecha_exp)

Precondiciones: Venta en curso, todos los art culos han sido ingresados
Poscondiciones:
Operacin: PagarCheque(RUT )
Precondiciones: Venta en curso, todos los art culos han sido ingresados
Poscondiciones:
Se cre PagoCrdito pc
Se acosi pc con v, Venta actual
Se cre TarjetaCrdito tc, se asignaron los atributos tc.numTarjetay
tc.fecha_exp
Se asoci tc con pc
Se cre SolicitudCrdito sc
Se asoci sc con pc
Se asoci v con Tienda como la venta completada
?
?
?
?
?
Se cre PagoCheque pch

Se acosi pch con v, Venta actual
Se cre CdulaIdentidad ci, se asign el atributo ci.numero
Se asoci ci con pch
Se cre SolicitudCheque sch
Se asoci sch con pch
Se asoci v con Tienda como la venta completada
?
?
?
?
?
357
Diagramas de Estado
Diagramas de Estado
Notacin
Eventos, estados y transiciones
?
?
El lenguaje UML cuenta con una notacin para los

diagramas de estado que describen grficamente los
eventos y los estados de los objetos
Se expondrn las caractersticas ms importantes de la
notacin, pero hay otras que no mencionaremos
Ponemos de relieve la utilizacin de los diagramas de
estado para indicar los eventos del sistema en los casos
de uso, aunque bien podran aplicarse a cualquier tipo
Un evento es un acontecimiento importante o digno de

sealar
Un estado es la condicin de un objeto en un momento

determinado: el tiempo que transcurre entre eventos
359
Por ejemplo, a levantar el auricular telefnico
Por ejemplo: un telfono se encuentra en estado "ocioso" una vez

que el auricular es puesto en su sitio y mientras no lo levantemos
La transicin es una relacin entre dos estados; indica que,

cuando ocurre un evento,el objeto pasa del estado anterior
al siguiente
?
358
Por ejemplo, cuando ocurre el evento "levantar el auricular", el

telfono realiza la transicin del estado ocioso al estado activo
360
90
Diagramas de Estado
Diagramas de Estado
Un diagrama de estado del UML describe visualmente los

estados y eventos m s interesantes de un objeto, as como
su comportamiento ante un evento
?
Estadoinicial
descolgar auricular
Estado
Ocioso
Transicin
Un diagrama de estado presenta el ciclo de vida de un

objeto: los eventos que le ocurren, sus transiciones y los
estados que median entre esos eventos
No es necesario que muestre todos los eventos posibles; si
tiene lugar un evento que no est representado en el
diagrama, se excluye siempre y cuando no sea relevante
en el diagrama de estado
Activo
colgar auricular
Evento
361
Diagramas de Estado
Diagramas de Estado
Diagramas de estado para los casos de uso
Un diagrama de estado puede aplicarse a varios

elementos del UML:
clases de software
tipos (conceptos)
? casos de uso
?
Podemos representar un sistema entero con un tipo,

concepto o conjunto de sistemas en un dominio del
problema que abarque los sistemas distribuidos; de ah la
posibilidad de que cuente con su propio diagrama de
estado
363
362
Una aplicacin til de este tipo de diagramas consiste en

describir la secuencia permitida de los eventos externos
del sistema que reconoce y maneja un sistema dentro del
contexto de un caso de uso
Por ejemplo:
?
En el caso Realizar Venta de la aplicacin del punto de venta, no

est permitido efectuar la operacin PagarCrdito mientras no haya
ocurrido el evento terminarVenta
? En el caso Procesar Documento con un procesador de palabras, no
est permitido efectuar la operacin Guardar en Archivo mientras
no haya ocurrido el evento Archivo-Nuevo o Archivo-Abierto
364
91
Diagramas de Estado
Diagramas de Estado
Diagrama de estado: Comprar Productos
Utilidad de diagramas de estado para casos de uso

?
introducirArticulo
EnEsperadelaVenta
introducirArticulo
IntroduciendoProductos
?
Eventodel sistema
(externo)
terminarVenta
El nmero de eventos de un sistema y su orden correcto

en el caso Realizar Venta tienen (hasta ahora) apariencia
trivial; por eso, no parece obligatorio emplear un diagrama
de estado para sealar la secuencia correcta
Pero en un caso complejo con multitud de eventos de
sistema --cuando se utiliza un procesador de palabras, por
ejemplo- conviene recurrir a un diagrama de estado que
describa el orden legal de los eventos externos
EnEsperadelPago
Pagar
365
366
Diagramas de Estado
Diagramas de Estado
Con un conjunto de diagramas de estado para los casos

de uso, el diseador podr desarrollar metdicamente un
diseo que garantice el orden correcto de eventos del
sistema
A continuacin se enumeran algunas soluciones posibles
del diseo:
En un dominio con muchos eventos del sistema, la

concisin y el rigor al emplear los diagramas de estado de
casos de uso le ayudan al diseador a cerciorarse de que
no omite nada
pruebas condicionales rigurosamente codificadas para los eventos

fuera de orden
? inactivacin de elementos (widgets) en las ventanas activas para
prohibir los eventos ilegales (mtodo recomendable)
? un intrprete de una mquina de estados, el cual ejecute una tabla
de estados que represente un diagrama de estado para los casos
de uso
367
368
92
Iteracin 2
Diagramas de Estado
Diagramas de estado del sistema
Otros diagramas de estado para la aplicacin

introducirArticulo
Punto de Venta
?
introducirArticulo
EnEsperadelaVenta
IntroduciendoProductos
Los controladores (en el sentido de GRASP) son los candidatos

comunes entre las sugerencias anteriores de los tipos que pueden
depender del estado. Por ejemplo, el controlador que hemos usado
hasta ahora en nuestra aplicacin ha sido la clase Caja
terminarVenta
manejarRespuesta
EnEsperadelPago
PagarEfectivo
EnAutorizaciondePago
PagarCr dito
PagarCheque
369
Diagrama de Paquetes
Introduccin
Arquitectura clsica de tres capas
?
?
En el estudio anterior de casos se enfoc en los objetos

del dominio del problema (entre ellos, Venta), porque as
se definen los conceptos y el comportamiento bsicos de
un sistema
Pero un sistema se compone de muchos subsistemas, uno
de los cuales son los objetos del dominio
Un sistema ordinario de informacin ha de conectarse a la
interfaz del usuario y a un mecanismo de almacenamiento
persistente
371
370
Una arquitectura comn de los sistemas de informacin

que abarca una interfaz para el usuario y el
almacenamiento persistente de datos se conoce con el
nombre de arquitectura de tres capas:
?
Presentacin: ventanas, reportes, etc.

Lgica de aplicaciones: tareas y reglas que rigen el proceso
? Almacenamiento: mecanismo de almacenamiento persistente
?
372
93

?
Presentacin
Lgica de
aplicaciones
Almacenamiento
Registrar
Autorizar
Ventas
pagos
Las ventanas envan a la capa intermedia peticiones de trabajo y

ste se comunica con la capa de almacenamiento del extremo
posterior
? Esta arquitectura contrasta con el diseo de dos capas, donde - por
ejemplo - colocamos la l gica de aplicaciones dentro de las
definiciones de ventana, que leen y escriben directamente en una
base de datos; no hay una capa intermedia que separe la lgica
Base de Datos
La cualidad tan especial de la arquitectura de tres capas

consiste en aislar la l gica de la aplicacin y en convertirla
en una capa intermedia bien definida y lgica del software
En la capa de presentacin se realiza relativamente poco
procesamiento de la aplicacin
373
Descomposicin de la capa de lgica
?
?
En un diseo orientado a objetos, la capa de la lgica de

aplicaciones se divide en otras menos densas
La capa de la lgica de aplicaciones est constituida por
las siguientes capas:
Presentacin
Objetos del dominio: clases que representan los conceptos del

dominio; por ejemplo, una venta
? Servicios: los objetos servicio de las funciones como la interaccin
de bases de datos, los reportes, las comunicaciones y la seguridad
Lgica de
aplicaciones
Almacenamiento
375
374
CajaApplet
Pago
Venta
Conceptos
del dominio
Interfaz
BasedeDatos
Generador
Reportes
Servicios
Base de Datos
376
94
Descomposicin de la capa de lgica
Notacin
Entre los motivos por los cuales se recurre a la arquitectura

multicapas se cuentan los siguientes:
Aislamiento de la lgica de aplicaciones en componentes

independientes susceptibles de reutilizarse despus en otros
sistemas
? Distribucin de las capas en varios nodos fsicos de cmputo y en
varios procesos puede mejorar el desempeo, la coordinacin y el
compartir la informacin en un sistema de cliente-servidor
? Asignacin de los diseadores para que construyan determinadas
capas; por ejemplo, un equipo que trabaje exclusivamente en la
capa de presentacin
?
Y as se brinda soporte a los conocimientos especializados en las

habilidades de desarrollo y tambin a la capacidad de realizar
actividades simultneas en equipo
El lenguaje UML ofrece el mecanismo paquete que permite

describir los grupos de elementos o subsistemas
?
Un paquete es un conjunto de cualquier tipo de elementos de un

modelo: clases, casos de uso, diagramas de colaboracin u otros
paquetes (los anidados)
Un sistema puede examinarse ntegramente dentro del

mbito de un slo paquete de alto nivel: el paquete
Sistema
El paquete define un espacio de un nombre anidado, de
modo que los elementos del mismo nombre pueden
duplicarse dentro de varios paquetes
377
Notacin
Arquitectura detallada
Un paquete se muestra grficamente como una carpeta

con etiquetas. Los paquetes subordinados se incluyen en
su interior
El nombre del paquete se encuentra dentro de la etiqueta
si el paquete describe sus elementos; en caso contrario
estar en el centro de la misma carpeta
Presentacin
Dominio
Capa de servicios
de alto nivel
orientada aobjetos
Conceptos de dominio
Elementos
bsicos
Capa de servicios
de bajo nivel
(orientada a objetos
y noorientada a
objetos)
Ventas
Interfaz de base de
datos relacional
Comunicaci n
379
Interfaz de base de
datos OO
Reportes
Esquemas de aplicaciones y
bibliotecas de soporte
Base de Datos
Relacional
378
Base de Datos
OO
380
95
?
?
Las relaciones de dependencia (lnea punteada con flecha)

indican si el paquete tiene el acoplamiento con otro
La ausencia de dependencia del paquete A con el B
significa que los componentes de A no tienen referencias a
ninguna clase, componentes, interfaz, mtodo o servicios
de B
Agrupe los elementos en un paquete aplicando la siguiente

directriz:
?
Agrupe los elementos para ofrecer en un paquete un servicio

comn (o una familia de servicios relacionados), con un nivel
relativamente alto de acoplamiento y colaboraci n
? En cierto nivel de abstracci n, se ver el paquete como muy
cohesivo (tiene responsabilidades estrechamente relacionadas)
? En cambio, habr relativamente bajo acoplamiento y colaboraci n
entre los elementos de los paquetes
381
Algunos Aspectos del Diseo de Sistemas
Estratos y particiones
Visibilidad entre las clases de paquetes
Podemos caracterizar una arquitectura multicapas como

compuesta de estratos (subcapas ) y particiones
?
Elementos bsicos
Ventas
Acceso a los paquetes del dominio: otros paquetes, generalmente

el de presentacin, tienen acceso a la visibilidad de muchas clases
que representan los conceptos del dominio
? Acceso a los paquetes de servicios: otros paquetes, generalmente
los de dominio y de presentaci n, tienen acceso a la visibilidad slo
respecto a una clase o unas cuantas en determinado paquete de
servicios (casi siempre una clase Fachada)
? Acceso a los paquetes de presentacin: ningn otro paquete tendr
acceso directo a la visibilidad de la capa de presentaci n. La
comunicacin es indirecta (mediante el patrn Observador), si es
que existe
Productos
Dominio
Interfaz de base de
datos relacional
Comunicaci n
Interfaz de base de
datos OO
La visibilidad respecto a las clases en varios paquetes

suele conformar el siguiente patrn:
?
Los estratos representan las capas verticales, mientras que las

particiones representan la divisi n horizontal de subsistemas
Dominio
EstratosVerticales
382
Reportes
Patriciones horizontales
383
384
96
Patrones de Diseo
Visibilidad de muchas clases

a partir de otros paquetes
Fachada
Dominio
Venta
fecha : Fecha
hora : Hora
estaTerminada : Booleano
EspecificaciondeProducto
descripcion : Texto
precio : Entero
id : Entero
total( )
crearLineaVenta( )
Pagar( )
Terminar( )
Pago
monto : Entero
CatalogoProductos
especificacion( )
?
Interfaz de BDR
FachadaBD
obtener(id ): Objeto
guardar(Objeto)
Seguridad
Broker
Proxy
Fachada de Seguridad
AgregarUsuario(Usuario)
Usuario
Cmo deberan los componentes coordinarse con las

clases de un paquete de servicios - por ejemplo, el
paquete InterfazdeBasedeDatosRelacional, que ofrece
servicios para realizar transformaciones entre los objetos y
los renglones de las tablas?
Cuando se define una clase con una interfaz com n a un
grupo de componentes o a un conjunto heterogneo de
interfaces, a esa clase le damos el nombre de Fachada
Los elementos heterogneos pueden ser las clases de un
paquete, un conjunto de funciones, un esquema o un
subsistema local o remoto
Visibilidad de una o de unas

cuantas clases en cada paquete
de servicios
385
Patrones de Diseo
Patrones de Diseo
Fachada
Separacin Modelo-Vista
Problema: Se requiere una interfaz com n y unificada para

un conjunto heterogneo de interfaces, un subsistema por
ejemplo. Qu hacer?
Solucin: Definir una clase individual que unifique la
interfaz y le asigne la responsabilidad de colaborar con el
subsistema. El patrn Fachada a menudo sirve para
suministrar una interfaz pblica a un paquete de servicios
?
Por ejemplo, si se dispone de un paquete de

InterfazBasededatosRelacional con muchas clases internas,
podemos definir una clase como FachadaBDque ofrezca la interfaz
pblica comn con los servicios del paquete. Las clases de otros
paquetes envan mensajes nicamente a una instancia de ella y no
se acoplan a otras clases del paquete
387
386
El patrn de Separacin Modelo-Vista establece que los

objetos modelo (dominio) no deberan conocer
directamente los objetos vista (presentacin) ni estar
directamente acoplados a ellos
?
Los mtodos de una clase de modelo no deberan contener

instrucciones que enven mensajes directos a un objeto vista; este
tipo de clase no debera conocer las interfaces del usuario ni
relacionarse con ellas mediante cdigos
? Una clase de modelos no tendr visibilidad directa respecto a una
clase vista. Pero se admite la visibilidad indirecta
388
97
Patrones de Diseo
Patrones de Diseo
Contexto/problema: Conviene desacoplar los objetos

dominio (modelo) y las ventanas (vistas), a fin de brindar
soporte a un mayor reuso de los objetos dominio y reducir
al m nimo el impacto que los cambios de la interfaz tienen
en ellos. Qu hacer?
Solucin: Definir las clases de dominio (modelo) para que
no tengan acoplamiento ni visibilidad directa respecto a las
clases ventana (vista) y para que los datos de la aplicacin
y de la funcionalidad se conserven en las clases de
dominio, no en las de ventana
Capa de Presentacin (vista)

(por ejemplo, CajaApplet )
1: introducirArticulo
(id, cant)
:Caja
Capa del dominio

(modelo)
Bien.
Mensajes de la capa de
vista de la presentacn.
Soporta la separaci n
modelo-vista.
389
Patrones de Diseo
Entre las razones por las cuales se emplea el patrn de

separacin Modelo-Vista, podemos citar las siguientes:
Dar soporte a las definiciones de modelos cohesivos que se

centran en los procesos de dominio ms que en las interfaces de
computadora
? Permitir desarrollar independientemente el modelo y las capas de
interfaz para el usuario
? Reducir al mnimo el impacto que los cambios de requerimientos de
la interfaz tienen en la capa de dominio
? Permitir conectar fcilmente otras vistas a la capa actual de
dominio, sin que esto la afecte
391
:Caja
Mal.
No es conveniente enviar
mensajes ni realizar el
acoplamiento de la capa de
modelo a la capa de vista.
Patrones de Diseo
?
1:presentarMensaje
(mens)
390
Entre las razones por las cuales se emplea el patrn de

separacin Modelo-Vista, podemos citar las siguientes:
?
Permitir vistas simult neas y mltiples del mismo objeto modelo;

por ejemplo, la vista de la estadstica de ventas en un diagrama
tabular
? Permitir ejecutar la capa del modelo independiente de la capa de
interfaz para el usuario; por ejemplo, en un sistema de
procesamiento de mensajes o de modo lotes
? Permitir transportar fcilmente la capa de modelo a otro esquema
de interfaz para el usuario
392
98
Paquetes
Paquetes
Punto de Venta
Punto de Venta
Servicio
autorizacin
Cuentas por
Cobrar
Aprobacin
crdito
Aprobacin
cheque
Pago
cheque
Tarjeta
crdito
Cheque
Producto
Tienda
Venta
Catalogo
Productos
Cajero
Cliente
Gerente
Cdula de
Identidad
Pago
crdito
Caja
LineaDeVentas
Agrupe los elementos en un paquete aplicando la siguiente

directriz:
?
Especificacin
Producto
Pago
efectivo
Solicitud de
aprobacin
Agrupe los elementos para ofrecer en un paquete un servicio

comn (o una familia de servicios relacionados), con un nivel
relativamente alto de acoplamiento y colaboraci n
? En cierto nivel de abstracci n, se ver el paquete como muy
cohesivo (tiene responsabilidades estrechamente relacionadas)
? En cambio, habr relativamente bajo acoplamiento y colaboraci n
entre los elementos de los paquetes
393
Paquetes
Paquetes
Punto de Venta
Punto de Venta: Bsico
Basico
Tienda
Pagos
Ventas
name : String
adress : String 1
Aloja
Caja
1..n
Emplea
Productos
Gerente
1..n
1
Transacciones
Autorizacin
394
395
396
99
Paquetes
Paquetes
Punto de Venta: Ventas
Punto de Venta: Productos
Cajero
Cliente
(from Basico)
nombre
Registra
Usa
1
Caja
(from Basico)
11
Captura
1
CrearNuevaVenta()
TerminarVenta()
Pagar()
1..n
Tienda
name : String
adress : String
Aloja
1
AgregarVenta()
Venta
fecha : Date
hora : Integer
Terminada : Boolean 1
n
1
Almacena
Tienda
(from Basico)
name : String
adress : String
1..n
Es-de
Describe
Contenida-en
1..n
terminar()
calcularVuelto()
total()
crearLineaVenta()
pagar()
n
(from Basico)
Articulo
CatalogoProductos
1
Inicia
1
LineaDeVenta
/ cantidad : Integer
subtotal()
n
n
Describe
1
descripcin : String
precio : Integer
+EspecifProd
id : Long
0..1
LineaDeVenta
(from Ventas)
cantidad : Integer
Terminadas
397
Paquetes
398
Paquetes
Punto de Venta: Pagos
Punto de Venta: Productos
ContratoServicio
IDContrato
Tienda
(from Basico)
Tiene
name : String
adress : String
Pago
monto : Integer
n Servicio Autorizacin
direccin
telefono
nombre
1
Autorizado-por
PagoEfectivo
n
PagoCheque
PagoCrdito
n n
Se-guardan-en
Se-guardan-en
n
Se-hace-con
1
TarjetaCrdito
numTarjeta
fecha_exp
1
1
1
CuentasPorCobrar
Tiene
Cliente
Propiedad-de 1 (from
Ventas)
n
Se-hace-con
1
Articulo
CatalogoProductos
n
1
Almacena
1..n
Es-de
Describe
Tienda
(from Basico)
name : String
adress : String
Contenida-en
Cheque
n
n
Autorizado-por
0..1
1
Describe
descripcin : String
precio : Integer
+EspecifProd
id : Long
Identifica
LineaDeVenta
(from Ventas)
/ cantidad : Integer
1
CedulaIdentidad
RUT
1
399
400
100
Paquetes
Esquemas, Patrones y Persistencia
Punto de Venta: Transacciones Autorizacin

Tienda
Recibe
Envia
(from Basico)
name : String
adress : String
1 Servicio Autorizacin
direccin
telefono
nombre
Envia
n
Aprobacin
Crdito
Reprobacin
Crdito
Transaccin
Autorizacin
Aprobacin
Cheque
Reprobacin
Cheque
Recibe
1
Respuesta
Autorizacin
Solicitud
Cheque
1
1
PagoCheque
1
PagoCrdito
(from Pagos)
(from Pagos)
Definir el concepto de esquema (Framework)

Aplicar patrones para el diseo de un modelo persistente
?
n
n
Solicitud
Autorizacin
1
1
Objetivos:
?
(from Pagos)
?
?
Mtodo de la Plantilla
Instanciacin de Objetos complejos
Uso de Agentes virtuales
Solicitud
Crdito
1
401
Introduccin
Introduccin
?
?
En los sistemas actuales es necesario guardar informacin

en medios de almacenamiento persistente (Bases de
Datos)
Cmo guardar objetos en dichos medios?
Se introducir un esquema de persistencia para enfrentar
esta problemtica
403
402
Objeto persistente: Objeto instanciado en memoria que

debe ser almacenado en un medio no voltil
Objetivo: Disear un esquema que permita disear objetos

que den servicios (mtodos) a otros objetos para ser
almacenados en un medio persistente
por ej., EspecificacionProducto
404
101
Mecanismos de Almacenamiento
Esquema (Framework)
Mecanismos de Almacenamiento ms comunes son:

?
Bases de datos Orientadas a Objeto:

Presentan la ventaja de no necesitar servicios espec ficos de
persistencia
Conjunto cohesivo de clases que prestan servicios a la parte

fundamental e invariable de un sistema lgico
? Contiene clases concretas y abstractas definiendo las interfaces e
interacciones en que participarn
? En general es necesario que el usuario defina subclases adaptando
los servicios definidos en el esquema
? Posee clases abstractas que pueden incluir mtodos abstractos y
concretos
Bases de datos Relacionales:

?
?
?
Son las ms utilizadas hoy en da

No poseen m todos para almacenamiento de objetos
Se requieren de servicios especiales para almacenar objetos en las
tablas
Esquema: subsistema expandible de un conjunto de

servicios afines
405
Esquema de Persistencia (EP)
Esquema de Persistencia (EP)
?
?
?
?
Esquema de persistencia es un conjunto reutilizable de

clases que presentan servicios a los objetos persistentes
Se utiliza para trabajar con bases de datos relacionales,
una API de servicios de datos orientados a registros
(Microsoft ODBC) u otro mecanismo de almacenamiento
No se utiliza en Bases de Datos orientadas a objetos
En general, este esquema debe traducir los objetos a
registros para guardarlos en una base de datos y viceversa
Objetos realizan llamadas

a servicios implementados
en el esquema de
persistencia
Traduce los objetos a

registros y a la inversa
para almacenarlos en
algn medio de
almacenamiento
406
Definici
Definici
n del sistema
Esquema relacional de
persistencia de objetos
Base de
Datos
Relacional
407
408
102
Requerimientos del EP
Ideas a Analizar
Un EP debera ofrecer los siguientes servicios:
Almacenamiento y recuperacin de objetos

? Transacciones del tipo commit y rollback
?
?
commit - completar la transaccin de guardar

rollback - deshacer la transaccin, restaurar el estado anterior
Extendible para otros medios de almacenamiento

Realizar la menor cantidad posible de modificaciones al cdigo
Un agente especializado (broker) de la Base de Datos se encarga

de materializar y desmaterializar
Materializacin y Desmaterializacin
?
Los registros y los objetos deben tener un identificador nico para

relacionarlos fcilmente y evitar duplicados
Intermediario de Base de Datos

?
Debe haber cierto grado de mapeo entre una clase y su

almacenamiento persistente (por ej. tabla de la BD) y entre los
atributos del objeto y los campos (columnas) de un registro
Identidad del Objeto

?
El diseo de un EP debe considerar lo siguiente:

?
Mapeo
?
Es el acto de transformar una representaci n no orientada a

objetos (por ejemplo, registros) a objetos, y al revs
409
Ideas a Analizar
Ideas a Analizar
Cach
?
Para hacer transparente la MLPD se crea una referencia inteligente

llamada agente virtual
El estado de un objeto persistente puede modificarse en una

transaccin, por lo tanto es deseable llevar un registro de los
cambios que sufre para realizar la actualizaci n
Operaciones de transacciones
Bsqueda
Referencias inteligentes
?
La materializacin se lleva a cabo nicamente cuando el objeto

almacenado es necesitado por otro
Estado de la transaccin del Objeto

?
Materializacin lenta por demanda (MLPD)

?
Los Brokers poseen un cach (generalmente en memoria principal)

en donde almacenan los objetos materializados
410
Operaciones commit y rollback

Localizacin y materializacin de los objetos a partir de algunos
criterios
Objetos complejos
?
Son materializaciones de estructuras complejas de objetos
411
412
103
Mapeo
?
?
Cmo mapear un objeto a un archivo o a un esquema de

bases de datos relacional?
El patrn Representacin de objetos como tablas propone
definir una tabla por objeto persistente, en donde sus
atributos equivalgan a una columna de la tabla
?
Cmo identificar a que instancia de objeto corresponden

los registros de la tabla?
?
Es una buena aproximacin para tipos primitivos de datos, pero

para tipos complejos, este mtodo no es tan simple
El patrn Identificador de Objetos (IDO) propone asignar

un IDO a cada registro y objeto (o agente de un objeto)
que los relacione
?
413
Conviene contar con un medio que relacione los registros con los
objetos y que asegure la no duplicidad de estos
En general, es un valor alfanumrico
Intermediario de la base de Datos (Broker)
Toda tabla de la base de datos relacional tiene un IDO

como clave primaria, el que tambin est contenido como
atributo en el objeto
Ejemplo:
Venta
Fecha
IDO
hora
:Venta
fecha=1/1/1997
Ido=xyz123
Quin debera asumir la responsabilidad de materializar y

desmaterializar los objetos a partir de un almacenamiento
persistente, por ej. EspecificacionProducto?
El patrn Experto seala que debera hacerlo la clase de
objeto persistente EspecificacionProducto
No es muy buena solucin:
?
Hora=10:00
seTermina()
:Venta
El IDO puede
definirse en un
objeto Agente
fecha=2/2/1997
Ido=Abc345
414
Existira un muy alto acoplamiento

Se pierde la cohesin pues la responsabilidad est fuera del
dominio del objeto
Clave Primaria
Hora=14:00
415
416
104
Intermediario de la base de Datos (Broker)
Diseo de Intermediarios: Mtodo de la Plantilla
El patrn Intermediario de Base de Datos propone

construir una clase que se encargue de materializar,
desmaterializar y guardar un objeto en un objeto cach
(Clase intermediaria)
Superclase abstracta de
todos los intermediarios de
bases de datos relacionales
?
Intermediariode
EPArchivos
Intermediariode
EPRelacional
Se define una clase plantilla, la cual puede ser utilizada para definir
el esqueleto de un algoritmo
?
Clase concreta encargada de

materializar los objetos
Ventas a partir de una base
de datos relacional
IntermediariodeEP
El patrn utilizado para el diseo de clases intermediarias
Intermediario
IntermediariodeArchivos
Intermediariode
deEspecifProducto
RelacionaldeVentas
EspecifProductos
ArchivodeVentas
Estos mtodos pueden o no estar en una subclase y por general

llaman a otros mtodos
Se sigue el Principio de Hollywood: no nos llame, nosotros

le llamaremos
?
IntermediarioRelacional
con partes variables que se pueden modificar al heredarse a una

subclase
e invariables, que no pueden ser modificadas
Es decir, un mtodo de una subclase ser ejecutado slo si este es

llamado desde la clase en la cual fue definido
417
418
Diseo de Intermediarios: Mtodo de la Plantilla
Materializacin: Patrn mtodo de plantillas
Ejemplo:
metododePlantilla
{..
Mtodo de plantillas: define el

esqueleto de un algoritmo con partes
variables e invariables.
operacionPrimitiva ()
operacionConcreta ()
IntermediariodeEP
Clase Abstracta
MetododePlantilla()
}
Operaciones abstractas primitivas:
-partes variables
La lgica de materializaci n suele requerir que se genere una instancia

de la clase apropiada y que luego se desplacen los datos del registro
hacia los atributos de la nueva instancia
objectWith(anOID) : Object
inCache(anOID) : Object
materializeWith(anOID) : Object
RegistrodeBDR
campo(nombredeArchivo) : Objeto
1
operacionConcreta ()
IntermediarioEPRelacional
-se desplazan (emiten) en la

subclase
Registro-actual-de
Operaciones concretas
-comportamiento por omisi n
currentRecordAsObject() : Object
materializeWith(OID) : Object
selectFirst(query) : Object
IntermediariodeEPdeArchivos
materializeWith(OID) : Object
Una tcnica totalmente

diferente para
materializar a partir de
archivos planos.
Clase Concreta
-si puede ser desplazado en una subclase,

recibe el nombre de m todo de gancho
IntermediarioRelacionaldeEspecific
aciondeProducto
419
IntermediarioRelacionaldeVentas
currentRecordAsObject() : Sale
currentRecordAsObject() : ProdSpec
420
105
Materializacin : Patrn mtodo de plantillas
Materializacin : Patrn mtodo de plantillas
Tener un Intermediario para los mecanismos de

almacenamiento persistente es muy til para desarrollador
?
Puede agregar ms clases para adaptarla a nuevos medio o a los

ya existentes
Clase IntermediariodeEP se comporta como un agente

virtual
?
A travs del mtodo objectWith(anOID) toma el identificador como

parmetro y devuelve el objeto de l
? Posee manejo de Cach
?
Invariable: Mtodos que no pueden ser modificados

Variables: Mtodos que pueden ser adaptados por los
programadores para amoldar el esquema a un tipo especfico de
tecnologa o mtodo
Caractersticas clsicas del diseo de esquemas:

?
Uso de mtodos definidos con anterioridad en superclases

abstractas
? Incorporacin de subclases definidas por el programador
? Definicin de los mtodos de operacin primitiva en las subclases
para completar los mtodos de plantilla heredados
Si el objeto ya ha sido referenciado antes, no ser materializado

nuevamente
El m todo de la plantilla define partes variables e

invariables
421
Cach
Cach
El mecanismo de cach puede ser utilizado para dos

cosas:
?
El patrn Administracin de Cach propone asignar a los

intermediarios la responsabilidad de administrar el cach
?
Mejorar el desempeo
?
Materializar es lento
Soporte de las operaciones de administraci n de transacciones
423
Si se tiene un intermediario diferente para cada tipo de objeto

persistente, cada uno de ellos deber tener su propia cach
Al materializar un objeto este se deja en cach con su

identificador como clave
?
422
El intermediario primero buscar en este antes de materializar un

objeto
424
106
Cach: Administracin de Transacciones
Cach: Tipos
Otra forma de conservar los objetos es en varias cachs,

segn el estado que presenten dentro del contexto de la
transaccin actual
El intermediario conserva hasta 6 tipos diferentes de
cachs lo que permite sentar las bases para realizar las
transacciones sobre la BD
IntermediariodeEP
objectWith(anOID): Object
Cach Limpia y Nueva: Objetos nuevos sin modificaciones

Cach Limpia y Vieja: Objetos viejos que se materializan de una
BD sin modificaciones
? Cach Sucia y Nueva: Objetos nuevos, modificados
? Cach Sucia y Vieja: Objetos viejos que se materializaron de una
BD y que fueron modificados
? Cach Eliminar Nueva: Objetos nuevos a eliminar
? Cach Eliminar Vieja: Objetos viejos que se materializaron a partir
de una base de datos y que deben ser eliminados
?
CachedeObjetos
1
Guarda-objetos-en
Add(OID, Object)
inCache(anOID): Object
Find(OID): Object
materializeWith(anOID): Object
isEmpty(): Boolean
Los 6 tipos de cachs son:
425
Referencias Inteligentes
Referencias Inteligentes: Ejemplo
Materializacin lenta por demanda: materializacin de un

objeto slo ocurre cuando sea absolutamente necesario
?
Se puede implementar a travs de un agente virtual
Este es el encargado de materializar al objeto real por primera vez

cuando se referencia
? Los clientes debern interactuar con el agente en vez de hacerlo
con el objeto real
Ejemplo concreto con LineaDeVentas y EspecificacionProducto

?
?
Agente Virtual (Proxy): representante de un objeto real
Un objeto cliente tiene una referencia al objeto Agente Virtual y no al

sujeto real
El agente virtual implementa la misma interfaz que ese sujeto
El diseo est basado en el supuesto que los agentes conocen el

identificador de objetos de su sujeto real
Cuando la materializacin es requerida, el identificador sirve para localizar
y recuperar el sujeto real
<<Clase>>
LineaDeVenta
cantidad
<<Interfaz>>
IEspecificacionProducto
descripcion ()
precio()
id()
Subtotal()
n
Descrita_por
1
427
426
<<Clase>>
AgenteEspecificacionProducto
ido : IDO
description()
getRealSubject()
materializeSubject ()
price()
id()
<<Clase>>
descripcion
precio
Agente_de
id
n
1
descripcion ()
precio()
id()
428
107
Agente Virtual Generalizado
Agentes Virtuales e intermediarios en BD
La especificacin de todos los agentes puede definirse en

una superclase llamada AgenteVirtual
?
As solo es necesario modificar las instancias especficas para

atender a los diferentes objetos reales que componen el sistema
comportamiento y
atributos generales
de todos los agentes
<<Clase>>
AgenteVirtual
ido : IDO
getRealSubject()
Un agente virtual puede colaborar con un Intermediario de

Bases de Datos a fin de materializar un objeto, utilizando el
identificador de objetos usado por el agente
<<Clase>>
AgenteVirtual
ido : IDO
Agente-de
getRealSubject()
IntermediariodeEP
Materializa-a partir de
1
<<Interfaz>>
InterfazdeAgente
if (realSubject not materialized)

materializeSubject()
1
solicitud()
<<Clase>>
AgenteVirtualConcreto
objectWith()
inCache()
materializeWith ()
return realSubject
<<Clase>>
SujetoReal
solicitud()
solicitud()
429
430
Conexin entre AV e Intermediario de BD
Conexin entre AV e Intermediario de BD
?
?
?
?
//mtodo de plantilla
if(broker not created)
broker:=createBroker()
Return broker
Cmo un AV concreto sabe cul intermediario de BD

habr de utilizar?
Utilizando el patrn Mtodo de Fbrica: La operacin
primitiva se encarga de crear una instancia
<<Clase>>
AgenteVirtual
ido : IDO
El agente es responsable de pedir el representante para la BD

Es conveniente tener una sola instancia de cada intermediario
Cuando se usan agentes virtuales, conviene que toda

referencia a objetos se efecte a travs de objetos agente
y no a travs de referencias directas
?
Todas las definiciones de atributos se refieren a objetos agentes a

interfaces, no a objetos directos
? Todos los parmetros se refieren a objetos agente o a interfaces
431
Mtodo Fabrica
IntermediariodeEPRelacional
intermediario
createBroker()
getBroker()
getRealSubject()
ObjectWith()
realSubject:=
getBroker().objectWith(ido )
<<Clase>>
AgenteEspecificaciondeProducto
createBroker()
description()
price()
upc()
return
ProductSpecificationRelationalBroker.Instance()
432
108
Como representar relaciones en tablas
Patrn Instanciacin de Objetos Complejos
Cmo representar las relaciones de objetos en una tabla

de una base de datos relacional?
?
?
?
Utilizando el patrn Representaci n de objetos como tablas
Segn la relacin entre los objetos se propone:

?
Porque los objetos pueden pertenecer a una jerarqua de

composici n profunda
? Si se quiere materializar un objeto es posible que haya que
materializar tambin decenas de objetos relacionados
? Materializacin de una jerarqua integra de composici n usa el
espacio lenta e ineficientemente
Colocar una clave fornea del IDO en una o en las dos tablas que
representan los objetos en la relacin
Asociaciones uno a muchos:

?
Asociaciones uno a uno

?
Problema:
Para qu implementar Agentes Virtuales e Intermediarios
de BD?
Crear una tabla asociativa que registre los identificadores de cada

objeto en la relacin
Asociaciones muchos a muchos:

?
Crear una tabla asociativa que registre todos los identificadores de

objetos en la relacin
433
434
?
?
Solucin:
Aplazar la materializacin de los objetos, dependiendo de
los patrones de acceso y los requerimientos de
desempeo, hasta que sea necesario
Ejemplo: Materializar la instancia LineaDeVenta

?
Suponer que la informacin se encuentra almacenada en las

siguientes tablas
IDO
Cantidad
IDO
Hay veces en que conviene materializar uno o dos niveles de

profundidad
? Con un intermediario distinto para cada objeto persistente, es
posible decidir, intermediario por intermediario, el grado de
materializacin de los objetos persistentes y sus objetos asociados
vli1
vli2
descripcion
precio
id
p1
pauelos
1.50
111
p2
tempeh
2.25
222
LineaDeVenta
EspecifdeProducto
VLI-IDO
EP-IDO
vli1
P1
vli2
P2
LineaDeVenta-a-EspecifdeProducto
435
436
109
?
?
1: o:=getRealSubject()
Se sabe que el IDO de LineaDeVenta es vli1

Si se ejecuta el siguiente cdigo:
Crear("vli1")
2: t:=subtotal()
: AgenteLineaDeVenta
o : LineaDeVenta
t:=subtotal()
1: [not materialized] materializeSubject()
//Crear el agente
o:=getRealSubject()
AgenteLineaDeVenta unVLI=
N: o:=currentRecordAsObject()
: AgenteLineaDeVenta
1.2: o:=objectWith((ido)
new AgenteLineaDeVenta(vli1),
LineaDeVenta vli:=new LineaDeVenta
vli.cantidad(currentRecord.field("cantidad))
//reiderar el IDO de EspecifDeProducto asociado
SELECT *
from LineaDeVenta-a-EspecifiDeProducto
where VLI -IDO= :ido
EspecifDeProdIDO =currentRecord.field("EP-IDO")
//crear el intermediario a la EspecifDeProducto
IntermediarioEspecifdeProducto intermediario =
new IntermediarioEspecifiDeProducto(EspecifDeProdIDO )
//guardar intermediario en VLI
vli.especifdeProducto=intermediario
return vli
//Causa materializacin de los objetos

Int total = unVLI.subtotal ();
Finalmente, llega
a este mensaje
1.1: b:=getBroker()
437
b : IntermediarioLineaDeVenta
438

2: o:=getRealSubject()
LineaDeVenta referencia a un agente, no a la

EspecificacionProductos real, esta ltima no se
materializar mientras no se le enve el mensaje precio
1: p:=precio()
t:=subtotal()
: LineaDeVenta
: AgenteEspecifDeProducto
3: p:=precio()
o : EspecificacionDeProducto
Finalmente, llega
a este mensaje
1: [not materialized] materializeSubject()

1.1: b:=getBroker()
o:=getRealSubject()
N: o:=currentRecordAsObject()
: AgenteEspecifDeProducto
1.2: o:=objectWith(()ido)
EspecificacionDeProducto ep:=new EspecificacionDeProducto
b : IntermediarioEspecifDeProducto
ep.descripcion=currentRecord.field("descripcion")
ep.precio=currentRecord.field("precio")
ep.id=currentRecord.field("i d")
return ep
439
440
110
Operaciones de Transacciones
Estado de transaccin de los objetos
Cmo se ensucia un objeto?
Limpio y nuevo. Objetos nuevos, sin modificaciones

? Limpio y viejo. Objetos viejos, sin modificaciones
? Sucio y nuevo. Objetos nuevos, sin modificaciones
? Sucio y viejo. Objetos viejos materializados a partir de una base de
datos con modificaciones
? Eliminar nuevo. Objetos nuevos que deben ser eliminados
? Eliminar viejo. Objetos viejos que fueron materializados a parti r de
una base de datos y que deben ser eliminados
El Intermediario de BD conservar cachs especiales para

cada uno de estos estados y garantizar con ello que un
objeto est en la cach apropiada
Un objeto se ensucia al modificar uno de sus atributos a travs de

un mtodo mutador (establecedor)
? Por ejemplo:
? // clase EspecificacinProducto
? void price(float p)
?{
?
price = p;
?
BrokerServer.instance().dirty(this);
?}
Al ServidordeIntermediario (Fachada) se le notificar que un objeto

est sucio
?
?
441
Este encontrar el Intermediario apropiado de la BD para esta clase de

objetos y le notificar que el objeto est sucio
El Intermediario introduce el objeto en una cach sucia. Vieja y sucia si
442
era un objeto materializado
Cmo eliminar?
Es necesario registrar explcitamente el hecho para que se pueda

realizar la modificaci n correspondiente en la BD luego de una
operacin commit
? Por ejemplo:
// clase CatalogodeProductos
void removeProductSpec(ProductSpec p)
{
// eliminar p en la coleccin de ProductSpec
ProductSpec.remove(p);
// notificarle al intermediario que p debe eliminarse
BrokerServer.instance().delete(p);
}
?
Al ServidordeIntermediario se le notificar que un objeto est sucio
443
Operacin commit
Una vez se decide instalar la transaccin, se enva un mensaje
commit a la Fachada ServidordeIntermediario
BrokerServer.instance().commit();
El mtodo ServidordeAgente.commit simplemente dirige un mensaje
commit a cada intermediario.
void BrokerServer.commit()
{
for each broker b
b.commit()
}
444
111
En una transacci n los objetos pueden ser creados, modificados y

eliminados
?
Una vez decidido someter la transacci n a un rollback, se enva un

mensaje rollback a la Fachada ServidordeIntermediario
?
BrokerServer.instance().rollback();
? El mtodo ServidordeAgente.rollback simplemente dirige un
mensaje rollback a cada intermediario
? Las reglas del rollback son las siguientes:
Suponiendo que se encuentren en la cach del estado correspondiente de

la transaccin, el mensaje commit debe cumplir con las siguientes reglas:
?
?
?
?
?
?
Cach Nueva y Limpia - Insertar en BD, Dirigirse a Cach Vieja y Limpia

Cach Vieja y Limpia - Ignorar, no han cambiado
Cach Nueva y Sucia - Insertar en BD, Dirigirse a Cach Vieja y Limpia
Cach Vieja y Sucia - Actualizar en BD, Dirigirse a Cach Vieja y Limpia
Cach Nueva Eliminada - Eliminar en cach
Cach Vieja Eliminada - Eliminar en DB, Eliminar en cach
Operacin rollback
?
?
445
Cach Vieja y Limpia - Ignorar, no han cambiado

El resto de las cachs - Eliminar en la cach
446
Bsqueda de objetos en almacenamiento persistente
Recuperar un registro a partir de un almacenamiento

persistente depende de las herramientas, bibliotecas y del
sistema operativo
Con qu criterio debera recuperarse el objeto raz en una

jerarqua de composicin?
?
Por ejemplo, en Windows se puede utilizar los servicios del DAO

? Dentro del esquema se defini el mtodo
IntermediariodeEPRelacional.SeleccionarPrimero(consulta) para
localizar el primer registro que cumpla con los criterios de la
consulta
?
En general, un Intermediario de BD debe ofrecer dos

patrones b squeda:
?
?
Bsqueda mediante el identificador de objetos

Bsqueda mediante criterios arbitrarios, como las clave primaria del
dominio, por ejemplo, RUT
Los objetos raz no pueden materializarse utilizando Agentes

Virtuales y realizando una bsqueda con sus identificadores de
objeto como clave de consulta
447
Por ejemplo, una instancia Venta y sus instancias asociadas

LineaDeVentas y sus EspecificacionesdeProductos
Las instancias asociadas se materializan utilizando Agentes

Virtuales en base al valor de identificador de objetos del ra z
(Venta), pero cmo se prepara la escena y se introduce en la
memoria esta primera instancia de Venta?
448
112
Diseos Alternos
Este problema indica la necesidad de contar con

capacidad de b squeda orientada al dominio
?
Metadatos e Intermediarios parametrizados

?
Definir Metadatos (datos acerca de datos) respecto al mapeo de

clases y tablas, respecto al mapeo de nombres de atributos y
campos, etc.
? Los metadatos se pueden conservar en un objeto
MetadatosdeAlmacenamientoPersistente
En el ejemplo se podra utilizar la fecha y hora para buscar una

instancia de Venta
IntermediarioRelacionaldeVentas
CurrentRecordasObject():Venta()
VentaconFechayHora(fecha,hora):Venta()
No es necesario generar una jerarqua de intermedios

Por ejemplo, es posible que el IntermediariodeEPRelacional sea una
clase instanciada y parametrizada con metadatos
?
?
selectFirst("date = ",fecha,"and time = ",hora)
returncurrentRecordasObject()
No se requieren subclases de IntermediarioEPRelacional
Metadatos es un enfoque ms flexible y robusto que el de

formacin de subclases
?
Se recomienda en aplicaciones que contengan muchas clases de

objetos persistentes
449
450
Diseos Alternos
Diseos Alternos
Objetos Consulta
A diferencia de las consultas de cadenas simples (por ejemplo

OID=123) es posible crear una clase Consulta cuyas instancias
estn parametrizadas con expresiones booleanas
? Este esquema tiene la ventaja de abstraer de cualquier lenguaje de
manipulacin de datos, por ej. SQL
?
Se puede desconectar un intermediario y conectar otro, sin afectar

a los objetos cliente
?
As, se puede utilizar in Intermedio en-la Memoria durante algn

periodo y luego reemplazarlo por un intermedio relacional o plano
IntermediariodeEP
Intermediario
utilizado en las
pruebas
Cambio de intermediarios y de intermediarios de bases de

datos en la memoria
?
Consiste en crear un Intermediario en-la Memoria que no guarde

objetos en un almacenamiento persistente cuando se enva la
seal de commit
? Es til durante el desarrollo y las pruebas para evitar la complejidad
y desempeo de un intermediario real
451
IntermediariodeEPdeArchivos
IntermediariodeEPenMemoria
452
113
Diseos Alternos
Diseos Alternos
Comparacin entre estados de transaccin y cachs

mltiples
Si se usa una superclase comn ObjetoPersistente, el estado es un

atributo definido en esa clase
? En un Mapa (Dictionary o Hashtable) que conserva el intermediario
Una forma eficiente de recordar el estado de transaccin de un

objeto es colocndolo en una cach de intermediarios, por ej.
ViejaLimpia o ViejaSucia
? Un diseo alterno es donde cada objeto se asocia a un objeto
EstadodeTransacci n que indica si es viejo y limpio, viejo y sucio,
etc.
?
Se recomiendan las siguientes opciones:
Como un atributo del AgenteVirtual

?
Todos los objetos pueden estar en una cach, y el estado de

transaccin del objeto se conoce mediante el objeto asociado de
estado y no mediante su pertenencia a la cach
La clave del Mapa es el objeto, el valor asociado Mapa es el

EstadodeTransaccin del objeto
Este diseo presenta una complicacin: si varios agentes se relacionan
con el mismo objeto real, todos ellos debern permanecer
sincronizados
No conviene agregar directamente el conocimiento de la

persistencia a las definiciones del objeto de dominio
453
Implementacin
Diseos Alternos
Diagrama de Componentes
?
EstadodeTransaccion
?
commit()()
rollback()()
EstadoViejoLimpio
454
Los diagramas de componentes describen los elementos

fsicos y sus realizaciones en el entorno
Muestran las opciones de realizacin
EstadoViejoSucio
commit()()
rollback()()
commit()()
rollback()()
455
456
114
Implementacin
Implementacin
Diagrama de Componentes: mdulos
Los mdulos representan todos los tipos de elementos

fsicos que entran en la fabricacin de aplicaciones
informticas
?
La representacin grfica es la siguiente:

Especificacin
Cuerpo
Genrico
Pueden ser simples archivos, paquetes de Ada, bibliotecas

cargadas dinmicamente, etc.
Cada clase del modelo lgico se realiza en dos

componentes: la especificacin y el cuerpo
?
La especificacin contiene el interfaz de la clase mientras que el

cuerpo contiene la realizacin de la clase
? La especificacin puede ser genrica en el caso de las clases
parametrizables
Package
specification
457
Package
body
Generic
package
458
Implementacin
Implementacin
Diagrama de Componentes: dependencias
En C++ una especificacin corresponde a un archivo con

un sufijo .h y un cuerpo a un archivo con un sufijo .cpp
En Ada la nocin de mdulo existe directamente en el

lenguaje con el nombre del paquete
Las relaciones de dependencia se utilizan en los

diagramas de componentes para indicar que un
componente se refiere a los servicios ofrecidos por otro
componente
NewPackageSpec
NewPackageSpec2
Dependencia entre
dos componentes
459
460
115
Implementacin
Implementacin
La relacin de dependencia puede especializarse con un

estereotipo para precisar la naturaleza de las opciones de
realizacin que entraa la relacin de dependencia
?
Ejemplo de orden de compilacin:

NewPackageBody3
NewPackageBody2
por ej., una <<instanciacin>>, etc.
Las dependencias entre componentes implican

dependencias de compilacin
?
El orden de la compilaci n viene dado por el orden del grafo de

precedencia diseado
NewPackageSpec3
461
NewPackageSpec2
462
Implementacin
Implementacin
Diagrama de Componentes: procesos y tareas
Diagrama de Componentes: procesos y tareas
Las tareas son componentes que poseen su propio flujo de

control (thread)
UML define los estereotipos <<proceso>> y <<flujo>>

donde varios flujos pueden compartir el mismo espacio de
direccionamiento dentro de un proceso
Ejemplo de especificacin y cuerpo de una tarea:
Las tareas pueden estar contenidas en otros componentes
463
NewTaskSpec2
NewTaskBody
464
116
Implementacin
Implementacin
Diagrama de Componentes: programas principales
Diagrama de Componentes: programas principales
Los puntos de entrada de las aplicaciones se especifican

con el siguiente icono:
?
?
NewMainSubprog2
En C++ la funcin libre se llama main()almacenada en un

fichero .cpp
El nombre del programa principal es utilizado a menudo
por el enlazador para dar nombre al programa ejcutable
correspondiente a la aplicacin
465
Implementacin
Implementacin
Diagrama de Componentes: subprogramas
Diagrama de Componentes: subsistemas
?
?
Los subprogramas agrupan los procedimientos y funciones

que no pertenecen a ninguna clase
Existen dos representaciones grficas:
Especificacin Subprograma
Realizacin del subprograma
466
Los distintos componentes pueden agruparse en paquetes

segn un criterio lgico y con vistas a simplificar la
implementacin
Son paquetes estereotipados en <<subsistemas>> para
incorporar la nocin de biblioteca de compilacin y de
gestin de configuracin
<<subsistema>>
NewPackage4
467
468
117
Implementacin
Implementacin
Los subsistemas organizan la vista de realizacin de un

sistema
?
Ejemplo de un subsistema que depende de un

componente:
Cada subsistema puede contener componentes y otros

subsistemas
Espec. Subprograma
Subsistema
La descomposicin en subsistemas NO es una

descomposicin funcional
?
NewPackage2
NewPackage6
La relacin entre paquetes y clases en el nivel l gico es el que

existe entre subsistemas y mdulos en el nivel fsico
Los subsistemas poseen una parte pblica y una parte

privada
?
Por defecto, los mdulos de los subsistemas son visibles desde el

exterior
469
Implementacin
Implementacin
Diagrama de Componentes: integracin
Ejemplo de un componente que depende de un

subsistema:
?
Subsistema
Programa Principal
NewPackage2
?
NewPackage6
471
470
Cada subsistema de materializa por un directorio que

contiene archivos correspondientes a los distintos
componentes del subsistema
El subsistema contendr adems los archivos necesarios
para la compilacin, documentacin y prueba de
componentes
La integracin con los sistemas de compilacin permite
asociar la nocin de biblioteca de programas a la de
subsistema
472
118
Implementacin
Implementacin
Diagrama de Despliegue
Los diagramas de despliegue muestran la disposicin

fsica de los distintos nodos que entran en la composicin
de un sistema y el reparto de los programas ejecutables
sobre estos nodos
?
?
Todo sistema se describe mediante uno o ms diagramas

de despliegue
Los estereotipos permiten precisar la naturaleza del
equipo:
?
Dispositivos
Procesadores
? Memoria
?
Nodo
Los nodos se interconectan mediante soportes

bidireccionales (en principio) que pueden a su vez
estereotiparse
473
Implementacin
Patrones GRASP
Introduccin
Ejemplo de conexin entre nodos:
<<Procesador>
Nodo
?
?
<<dispositivo>>
nodo2
<<<<TCP/IP>>>>
conexin1
GRASP: Patrones generales de software para asignar

responsabilidades
Hemos estudiado la aplicacin de los cinco patrones
GRASP:
?
Experto, Creador, Alta Cohesin, Bajo Acoplamiento, Controlador
Los ltimos cuatro patrones GRASP son:

?
conexin7
<<RDSI>>
474
Polimorfismo, Fabricacin Pura, Indireccin, No Hables con

Extraos
dispositivo
En Rational Rose podemos distinguir

entre el dispositivo por estereotipado y
el dispositivo con su propio smbolo
475
476
119
Patrones GRASP
Patrones GRASP
Polimorfismo
Polimorfismo
El polimorfismo significa asignar el mismo nombre a

servicios en varios objetos , cuando los servicios se
parecen o estn relacionados entre ellos
Solucin: Cuando por el tipo varan las alternativas o
comportamientos afines, las responsabilidades del
comportamiento se asignarn - mediante operaciones
polimrficas - a los tipos en que el comportamiento
presenta variantes
?
Problema: Cmo manejar las alternativas basadas en el

tipo? De qu manera crear componentes de software
conectables?
?
Alternativas basadas en el tipo La variacin condicional es un tema

esencial en la programacin. Si se disea un programa mediante la
lgica condicional if-then-else o case, habr que modificar la l gica
del case cuando surga una variante
?
Corolario: no realizar pruebas con el tipo de un objeto ni utilizar

lgica condicional para plantear diversas alternativas basadas en el
tipo
Este procedimiento dificulta extender un programa con otras variantes,

porque los cambios tienden a requerirse en varios lugares donde exista
la lgica condicional
Componentes de software conectables. Viendo los componentes

en las relaciones cliente - servidor, cmo podemos remplazar un
componente servidor sin afectar al cliente?
477
Patrones GRASP
Patrones GRASP
Polimorfismo
Polimorfismo
Ejemplo: En la aplicacin del punto de venta, quin debera

encargarse de autorizar las diversas clases de pagos?
?
El comportamiento de autorizacin vara con el tipo de pago - en efectivo,

con tarjeta de crdito o con cheque; por eso, conforme al polimorfismo
deberamos asignar esa responsabilidad a cada tipo de pago,
implementado con una operacin polimrfica autorizar
Pago
monto
PagoconCheque
PagoconTarjeta
PagoenEfectivo
montoOfrecido
autorizar( )
autorizar( )
autorizar( )
479
El uso del patrn Polimorfismo est acorde al espritu del

patrn Experto
?
?
Segn el polimorfismo cada
tipo de pago debe
autorizarse a si mismo
478
En vez de operar externamente sobre un pago para autorizarlo, el

pago se autoriza a s mismo; esto constituye la esencia de la
orientacin a objetos
Si podemos caracterizar Experto como el patrn

fundamental tctico, Polimorfismo ser el m s importante
patrn estratgico en el diseo orientado a objetos
480
120
Patrones GRASP
Patrones GRASP
Polimorfismo
Fabricacin Pura
El uso del patrn Polimorfismo est acorde al espritu del

patrn Experto
?
En vez de operar externamente sobre un pago para autorizarlo, el

pago se autoriza a s mismo; esto constituye la esencia de la
orientacin a objetos
Si podemos caracterizar Experto como el patrn

fundamental tctico, Polimorfismo ser el m s importante
patrn estratgico en el diseo orientado a objetos
?
Solucin: Asignar un conjunto altamente cohesivo de

responsabilidades a una clase artificial que no representa
nada en el dominio del problema: una cosa inventada para
dar soporte a una alta cohesin, un bajo acoplamiento y
reutilizacin
?
?
Es un principio fundamental en que se fundan las estrategias

globales, o planes de ataque, al disear cmo organizar un sistema
para que se encargue del trabajo
Esa clase es una fabricacin de la imaginaci n

Finalmente, una fabricacin pura exige algo, y esto lo hacemos
cuando estamos desesperados
Beneficios: Es fcil agregar las futuras extensiones que

requieren las variaciones imprevistas
481
Patrones GRASP
Patrones GRASP
Fabricacin Pura
Fabricacin Pura
Problema: A quin asignar la responsabilidad cuando uno

est desesperado y no quiere violar los patrones Alta
Cohesin y Bajo Acoplamiento?
?
Los diseos orientados a objetos se caracterizan por implementar

como clases de software las representaciones de conceptos en el
dominio de un problema del mundo real; por ejemplo, una clase
Venta y Cliente
? Pese a ello, se dan muchas situaciones donde el asignar
responsabilidades exclusivamente a las clases del dominio origina
problemas de mala cohesi n o acoplamiento o bien por un escaso
potencial de reutilizacin
Ejemplo Supongamos, por ejemplo, que se necesita

soporte para guardar las instancias Venta en una base de
datos relacional
?
En virtud del patrn Experto, en cierto modo se justifica asignar

esta responsabilidad a la clase Venta
? Pero no sera una buena idea por lo siguiente:
?
483
482
La tarea requiere un nmero relativamente amplio de operaciones de

soporte orientadas a la base de datos, ninguna de las cuales se
relaciona con el concepto de vender
La clase Venta ha de ser acoplada a la interfaz de la base de datos
relacional; de ah que mejore su acoplamiento
Guardar los objetos en una base de datos relacional es una tareamuy
general en que debemos brindar soporte a muchas clases
484
121
Patrones GRASP
Patrones GRASP
Fabricacin Pura
Fabricacin Pura
En conclusin, aunque en virtud del patrn Experto Venta

es un candidato lgico para guardarse a s misma en una
base de datos, da origen a un diseo de baja cohesin,
alto acoplamiento y bajo potencial de reutilizacin
?
Una soluci n razonable consiste en crear una clase nueva que se

encargue tan slo de guardar los objetos en algn tipo de
almacenamiento persistente: una base de datos relacional
Segn la Fabricacin Pura
Explicacin: Para disear una Fabricacin Pura debe

buscarse ante todo un gran potencial de reutilizacin,
asegurndose para ello de que sus responsabilidades
sean pequeas y cohesivas
Una fabricacin pura suele partirse atendiendo a su funcionalidad
y, por lo mismo, es una especie de objeto de funcin central
? Generalmente se considera que la fabricaci n es parte de la capa
de servicios orientada a objetos de alto nivel en una arquitectura
AgentedeAlmacenenamientoPersistente
guardar( )
485
Patrones GRASP
Patrones GRASP
Fabricacin Pura
Indireccin
Problemas:
?
Puede perderse el espritu de los buenos diseos orientados a

objetos que se centran en los posibles objetos y no en las
funciones
Las clases de Fabricacin Pura casi siempre se dividen atendiendo a
su funcionalidad; dicho con otras palabras, se confeccionan clas es
destinadas a conjuntos de funciones
Si se abusa de ello, la creacin de clases de Fabricacin Pura,

originar un diseo centrado en procesos o funciones que se
implementa en un lenguaje orientado a objetos
Solucin: Se asigna la responsabilidad a un objeto

intermedio para que medie entre otros componentes o
servicios, y stos no terminen directamente acoplados. El
intermediario crea una indireccin entre el resto de los
componentes o servicios
Problema: A quin se asignarn las responsabilidades a
fin de evitar el acoplamiento directo?
?
487
486
De qu, manera se desacoplarn los objetos de modo que se

obtenga un Bajo Acoplamiento y se conserve un alto potencial de
reutilizacin?
488
122
Patrones GRASP
Patrones GRASP
Indireccin
No hables con extraos
?
?
Ejemplo: AgentedeAlmacenamientoPersistente
El ejemplo de Fabricacin Pura para desacoplar la Venta y
los servicios de la base de datos relacional introduciendo la
clase AgentedeAlmacenamientoPersistente es tambin un
ejemplo de asignar responsabilidades para apoyar la
Indireccin
El AgentedeAlmacenamientoPersistente sirve de
intermediario entre la Venta y la base de datos
Solucin: Se asigna la responsabilidad a un objeto directo

del cliente para que colabore con un objeto indirecto, de
modo que el cliente no necesite saber nada del objeto
indirecto
En un mtodo los mensajes s lo deberan ser enviados a
los siguientes objetos:
?
El objeto this (o self)

Un parmetro del mtodo
? Un atributo de self
? Un elemento de una coleccin que sea atributo de self
? Un objeto creado en el interior del mtodo
?
489
Patrones GRASP
Patrones GRASP
Con esto se busca no acoplar un cliente al conocimiento

de objetos indirectos, ni a las representaciones internas de
objetos directos
Los objetos directos son "conocidos" del cliente, los
objetos indirectos son extraos", y un cliente debera tener
slo conocidos, no extraos
Cumplir con las restricciones anteriores significa que los
objetos directos pueden requerir nuevas operaciones que
acten como intermediarios, a fin de que el cliente pueda
evitar hablar con extraos
491
490
Problema: A quin asignar las responsabilidades para

evitar conocer la estructura de los objetos indirectos?
?
Si un objeto conoce las conexiones internas y las estructuras de

otros, entonces presentar alto acoplamiento
? Si un objeto cliente tiene que usar un servicio u obtener informaci n
a partir de un objeto indirecto, cmo podr hacerlo sin acoplarse
al conocimiento de la estructura interna de su servidor directo o de
los objetos indirectos?
492
123
Patrones GRASP
Patrones GRASP
Ejemplo: En una aplicacin del punto de venta, suponga
Una forma de devolver el monto del pago es:
una instancia Caja posee un atributo referente a una Venta, la cual

cuenta con un atributo referente a un Pago
? Las instancias Caja soportan la operacin montodePago, que
devuelve el actual monto ofrecido como pago
? Las instancias Venta soportan la operacin pago, la cual devuelve
la instancia Pago asociada a la Venta
Caja
Captura
terminarVenta( )
introducirArticulo( ) 1
Pagar( )
montodePago( )
Venta
fecha : Fecha
hora : Hora
estaTerminada :
montodePago()
Caja ::MontodePago()
{ pag: e_venta->pago()
1 total( )
crearLineaVenta( )
efectuarPago ( )
Terminar( )
pagar( )
Pagado -por
Esta solucin constituye una violacin del principio No Hables con

Extraos, porque la instancia Caja enva un mensaje a un objeto
indirecto: el Pago no es uno de los cinco candidatos conocidos
493
Patrones GRASP
Patrones GRASP
La solucin, como lo indica el patrn, consiste en agregar

la responsabilidad al objeto directo - la Venta, en este caso
- para que devuelva a Caja el monto del pago
?
Por tanto, se agrega una operaci n montodePago, de modo que la

instancia Caja no tenga que hablar con un extra o
montodePago()
1: imp :=montodePago()
Venta
: Caja
Caja ::MontodePago()
{
pag: e_venta->MontodePago()
}
: Venta
2: imp :=montoOfrecido( () : Flotante)
pag :Pago
montoOfrecido ()
: Venta
2: imp:=montoOfrecido () : Flotante
//viola "No hables con

extraos"
return pag->montoOfrecido();
}
Pago
monto : Entero
Booleano
1: pag:=pago(): Pago
: Caja
fecha : Fecha
hora : Hora
Terminada :
Booleano
total( )
crearLineaVenta( )
Pagar( )
Terminar( )
montodepago( )
494
Explicacin: No Hables con Extraos se refiere a no

obtener una visibilidad temporal frente a objetos indirectos,
que son de conocimiento de otros objetos pero no del
cliente
La desventaja de conseguir visibilidad ante extraos es la
siguiente: la solucin se acopla entonces a la estructura
interna de otros objetos
?
Ello origina un alto acoplamiento, que hace el diseo menos

robusto y ms propenso a requerir un cambio si se alteran las
relaciones estructurales indirectas
pag : Pago
495
496
124
Patrones GRASP
Proceso de Desarrollo
Quiz
Objetivos
Explique, qu patrones han sido aplicados en el desarrollo del

siguiente diagrama de colaboracin:
?
?
2: cid:=obtenerID()
1: autorizar()
pc :
PagoCrdito
: Caja
4: cid:=obtenerID(ct)
: Tienda
3: tc_tipo:=tipo()
6: resp:=Solicitar(pc, tc, cid)
:
TarjetaCrdito
?
5: sa:=buscar(tc)
Seguir un proceso de desarrollo iterativo, incremental y

orientado a los casos de uso
Organizar el trabajo a partir de los ciclos de desarrollo
Programar un ciclo de desarrollo dentro de un plazo
perentorio (o time-box)
Organizar el desarrollo en equipos paralelos a lo largo de
las lneas arquitectnicas
Expresar requerimientos tcnicos no evidentes como
casos de desarrollo de sistemas y calendarizarlos
: Servicio
Autorizacin
: ContratoServicio
497
Desafos
Desafos
El proceso del desarrollo de software es un tema muy

extenso
?
?
?
no slo abarca los pasos esenciales de un proyecto, sino tambin

su direccin y muchsimas cuestiones afines
Por qu molestarnos?
La respuesta salta a la vista: el desarrollo de software es
un negocio riesgoso
?
En 1995 un estudio revel que 31% de los proyectos no se

concluyen, 53% de ellos rebasa casi en 200% el costo estimado
? Compaas estadounidenses y dependencias gubernamentales
invirtieron 81 millones de dlares en proyectos de software que
fueron cancelados
? Simplemente no se estn obteniendo los resultados deseados
499
498
Se requiere tiempo y, por tanto, dinero para seguir un

proceso de desarrollo y realizar el anlisis y el diseo
orientados a objetos. Por qu molestarnos? Por qu no
iniciar de inmediato la programacin?
He aqu algunas razones:
?
Como indican las estadsticas anteriores, los proyectos de software

son una actividad riesgosa; de ah que el motivo primordial sea
aminorar el riesgo, esto es, aumentar la probabilidad de crear un
sistema eficiente. Y una estrategia para conseguirlo consiste en
examinar rigurosamente los requerimientos y elaborar un diseo
formal
? Conviene crear un proceso que puedan reproducir los individuos, y
sobre todo los equipos. No es sustentable el desarrollo que se
funda en heroicos esfuerzos individuales
500
125
Desafios
Directrices de un proceso eficiente
He aqu algunas razones:
Es ms barato y fcil efectuar cambios durante las actividades de

anlisis y diseo que en la fase de construccin: el software es
"ms duro" de lo que pensamos
? Podemos atenuar y manejar la abrumadora complejidad con slo
modelar los sistemas y hacer abstracciones para detectar los
detalles esenciales; as se evita una excesiva complejidad
? Conviene crear sistemas robustos, susceptibles de mantenimiento
y capaces de soportar una mayor reutilizaci n del software. Por lo
regular, estas metas no se cumplen sin un riguroso examen y
diseo efectuados antes de la programaci n
Los siguientes principios forman parte de un proceso

recomendable de desarrollo:
?
desarrollo iterativo e incremental

desarrollo orientado a los casos de uso
? desarrollo que comienza por definir la arquitectura (centrado en la
arquitectura)
?
501
Desventajas de un ciclo de vida en cascada
Un ciclo de vida iterativo
La caracterstica distintiva de un ciclo de desarrollo en

cascada es que contiene un solo paso de anlisis, diseo y
construccin;
?
en un nico paso se realiza todo el anlisis, luego todo el diseo,

luego la codificacin y finalmente todas las pruebas
He aqu algunas de sus deficiencias:

?
carga frontal de gran complejidad: excesiva complejidad

retraso de la retroalimentaci n
? congelamiento temprano de las especificaciones, mientras cambia
el ambiente de negocios
502
En contraste con el ciclo de vida en cascada, el ciclo

iterativo se funda en el perfeccionamiento gradual de un
sistema a travs de m ltiples ciclos de anlisis, diseo y
construccin
En cada ciclo se trata un conjunto relativamente pequeo
de requerimientos y el sistema crece incrementalmente
conforme van concluyndose los ciclos
503
504
126
Aporta los siguientes beneficios:
La complejidad nunca resulta abrumadora porque en un ciclo slo

se abordan unidades cuya complejidad es manejable
Se genera retroalimentaci n en las fases iniciales, porque la

implementaci n ocurre rpidamente en un pequeo subconjunto
del sistema
Se evitan as la parlisis del anlisis y la parlisis del diseo
Como este proceso admite demostraciones en las primeras fases,

el cliente y los directivos tendern a pensar que el sistema casi
est terminado: el conocido problema de funciona la interfaz para
el usuario = sistema terminado
? Se requiere de un manejo riguroso de las expectativas y una
comunicacin frecuente y clara por parte del equipo de desarrollo,
si se quiere atenuar esta reaccin, desgraciadamente inevitable
Esta retroalimentacin le suministra informacin al anlisis de ciclos

subsecuentes, pudiendo adem s mejorarlo
Llega a los diseadores a trav s de los resultados de su fase de
implementacin y pruebas o a trav s de la comunidad que usa una
versin ya liberada del sistema
Una de las principales desventajas del desarrollo iterativo e

incrementar son las expectativas del cliente y de los
directivos
505
Desarrollo orientado a los casos de uso
Desarrollo orientado a los casos de uso
El proceso de desarrollo debera evidenciar el influjo de los

casos de uso y organizarse en torno a ellos
?
su nmero, su complejidad, los servicios de soporte que requieren, et c.
Los programas se organizan a partir de ciclos iterativos, los

cuales se basan en la realizacin de los casos de uso
?
?
A partir de los casos de uso se escogen los requerimientos

que deberan cumplirse en un ciclo iterativo particular
?
En las estimaciones influyen directa e indirectamente los casos:

?
507
506
Por ejemplo, en la iteracin 1 nos ocuparemos del caso A, en la

iteracin 2 nos ocuparemos de una versin simplificada del caso B
y en la iteraci n 3 nos ocuparemos del resto del caso B e
ntegramente de los casos C y D
Las actividades de un ciclo de desarrollo procuran ante

todo llevar a cabo el caso o casos que se consideran en el
ciclo
Los conceptos y las clases de software pueden
identificarse atendiendo a los casos de uso
Se escriben casos de prueba para validar los que se llevan
a cabo
508
127
nfasis inicial en la arquitectura
Por arquitectura entendemos la estructura de alto nivel de

los subsistemas y de los componentes, as como de sus
interfaces, conexiones e interacciones
?
tiene subsistemas sustentados en arquitectura de capas

ofrece bajo acoplamiento entre subsistemas es fcil de entender
? es robusta, flexible y se incremento de modo adecuado
? tiene muchos componentes reutilizables
? se orienta a los casos de uso ms importantes y riesgosos
? consta de interfaces bien definidas con el sistema y con los
subsistemas
?
La arquitectura se compone de un conjunto de esquemas,

subsistemas, clases, asignaciones de responsabilidades y
colaboraciones entre objetos que cumplen con las funciones del
sistema
Un proceso eficaz estimula la generacin temprana de una

arquitectura global del sistema: est centrado en la
arquitectura
?
Ello significa que en los primeros ciclos se ponen de relieve la

investigaci n y el desarrollo de esquemas arquitectnicos bien
diseados; al mismo tiempo se tiene una visin global de una
arquitectura cohesiva a lo largo del proyecto
Una arquitectura bien diseada rene las siguientes

cualidades ideales:
509
Ciclos de desarrollo
?
?
Durante el desarrollo temprano, deber darse prioridad a

las capas y a los subsistemas con mayor riesgo e
incertidumbre
Pueden conformar la capa del dominio o alguna de las
capas de servicios de alto nivel
No obstante, la importancia especial que se concede a la
arquitectura significa que desde un principio se atender a
la mayora de las capas y de los subsistemas
511
?
?
?
510
La fase de elaboracin se centra en una investigacin del

problema y en el anlisis de los requerimientos
La fase de construccin de un ciclo de desarrollo requiere
implementar el diseo en software y en hardware
La fase de pruebas se incluye como paso final dentro de
un ciclo de desarrollo, tambin se recomienda como una
actividad constante en la fase de construccin
?
No todas las pruebas mencionadas en la figura son adecuadas en

los ciclos de desarrollo
? Por ejemplo, las pruebas de integraci n del sistema entero pueden
efectuarse con menor frecuencia en cada uno
512
128
Con una duracin menor de la necesaria ser difcil

realizar un conjunto significativo de requerimientos y
actividades; con una duracin mayor se correr el riesgo
de una excesiva complejidad y de insuficiente
retroalimentacin inicial
?
Algunos factores que pueden hacer que un ciclo se

prolongue hasta durar dos meses:
?
Introducci n de tecnologa o de m todos nuevos

Inaccesibilidad a los expertos en el dominio del tema
? Importante nmero de procesos distribuidos o concurrentes o
trabajo de comunicacin
? Personal novato (en la tecnologa de objetos, en el dominio del
problema o en el desarrollo iterativo)
? Equipos de desarrollo en paralelo
? Equipos de desarrollo fsicamente distribuidos que trabajan en
paralelos
?
Un ciclo de desarrollo debera durar entre dos semanas y dos

meses
En igualdad de circunstancias, se aconseja optar por un

ciclo de dos a cuatro semanas
?
Tener un equipo en otro piso del mismo edificio produce casi el mismo
impacto que si estuviera en un sitio geogrficamente distante
Equipos numerosos
513
Tres factores ajustables en un proyecto son el tiempo, el

mbito o alcance y el trabajo
En un plazo fijo el tiempo queda congelado, por lo cual slo

podemos ajustar el alcance y el trabajo
? Nueve mujeres no pueden hacer un nio en un mes";
generalmente un problema no mejora sino que se agrava, cuando a
un proyecto en crisis se le incorpora ms personal
?
Equipo de la capa del dominio (o equipo del subsistema del

dominio)
? Equipo de interfaz para el usuario
? Equipo de internacionalizaci n
? Equipo de la capa de servicios de alto nivel (equipo de persistencia,
equipo de presentaci n de reportes, etctera)
El equipo de desarrollo habr de decidir cules requerimientos

cumplir en el plazo; son ellos los que deben presentar los
resultados
?
515
Un proyecto extenso suele dividirse en actividades de

desarrollo en paralelo, donde varios equipos trabajan de
modo simultneo
Una forma de organizar los equipos en lneas
arquitectnicas es hacerlo por capas y subsistemas
?
Por tanto, el mbito o alcance constituyen el factor decisivo

que ajustamos para cumplir con las restricciones del plazo
?
514
Estos equipos pueden trabajar en ciclos de desarrollo en

paralelo; todos concluirn un ciclo en la misma fecha
516
129
Dependencias del desarrollo en paralelo
Dependencias del desarrollo en paralelo
Cuando varios equipos trabajan en un proyecto, se dan

dependencias entre ellos, a saber:
La interfaz del usuario se basa en la capa de dominio

La capa de dominio se basa en las de servicios, como la
persistencia
? El equipo de pruebas (si existe) necesita que algo haya sido
terminado y sea lo bastante estable para poder probarlo
Talones: las llamadas a servicios incompletos se implementan

como talones de hacer nada o hacer lo mnimo posible. Al irse
realizando los servicios, se reemplazan los talones
? Ciclos escalonados de desarrollo: Algunos equipos operan sobre
un ciclo que se relaciona con el trabajo terminado de un ciclo
anterior de otro equipo
En esta situacin el problema radica en que un equipo

quiere utilizar el resultado proveniente de otro, aunque no
est terminado
Entre las estrategias para manejar estas dependencias,

figuran las siguientes:
517
Al equipo de la interfaz del usuario le resulta muy cmodo aprovechar

los resultados de un ciclo anterior de desarrollo efectuado por un
equipo de la capa del dominio
518
Programacin del desarrollo de capas arquitectnicas
Programacin del desarrollo de capas arquitectnicas
Las capas normales de un sistema son el dominio, el

acceso a la base de datos (persistencia), los servicios de
alto nivel y la interfaz del usuario
?
No existe una regla infalible sobre las capas donde hay que
centrarse al iniciar el desarrollo, pero s hay algunas cuestiones a
considerar:
?
Casi siempre una interfaz atractiva le procurar satisfaccin al cliente,

aun cuando no sea muy funcional
?
De ah la conveniencia de comenzar el proyecto con una interfaz atractiva

para el usuario
La desventaja consiste en que los clientes, al verla, creen que el sistema
est casi concluido, cuando en realidad apenas si acabamos de iniciarlo
519
En un ciclo de desarrollo, si un equipo est desarrollando

la capa del dominio y de los servicios, aconsejamos
comenzar con la del dominio
Incorpore el soporte de persistencia (base de datos) al
inicio del desarrollo, pero no inmediatamente
?
Si abordamos prematuramente esta tarea, tal vez ya no prestemos

mucha atencin a una capa de dominio bien diseada
? Cuando se desarrollan los servicios de persistencia, se genera un
esquema mnimo de base de datos y tambin el marco necesario
de persistencia para continuar la iteracin actual junto con la
realizacin de los procesos de dominio, se mejorarn de modo
incrementar los servicios de persistencia a lo largo de varios ciclos
de desarrollo
520
130

Rup Uml 4diapositivas

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Rup Uml 4diapositivas

Uploaded by

Copyright:

Available Formats

Introduccin a la Ingeniera de Software

Introduccin a la Ingeniera de Software

Conceptos bsicos de Ingeniera de Software

Conceptos bsicos de Ingeniera de Software

El trmino Ingeniera de Software surge a final de los a os

Dra. Lioubov Dombrovskaia

El objetivo de la Ingeniera de Software es producir

Productos genricos: Desarrollados por una organizacin para un

Dra. Lioubov Dombrovskaia

Introduccin a la Ingeniera de Software

Introduccin a la Ingeniera de Software

Conceptos bsicos de Ingeniera de Software

Factores de calidad de Software

Los mtodos describen cmo construir tcnicamente el

Comprende las actividades de:

Planificacin y estimacin de proyectos

La calidad de software puede ser descrita mediante una

Externos: observables por los usuarios del producto

Las herramientas dan soporte automtico o

Dra. Lioubov Dombrovskaia

Introduccin a la Ingeniera de Software

Introduccin a la Ingeniera de Software

Factores de calidad de Software

Factores de calidad de Software

Factores de calidad externos:

Dra. Lioubov Dombrovskaia

Factores de calidad externos:

Correcci n: Capacidad de los productos software de ejecutar

Compatibilidad: Facilidad de los productos software para

Dra. Lioubov Dombrovskaia

Introduccin a la Ingeniera de Software

Introduccin a la Ingeniera de Software

Factores de calidad de Software

Ciclo de vida de Software

Factores de calidad externos:

Ciclo de vida: Sucesin de etapas por las que atraviesa un

Existen distintas formas o paradigmas de ciclo de vida:

Integridad: Capacidad de un sistema para proteger sus documentos

Factores de calidad internos:

Modularidad: Independencia funcional de los componentes del

Dra. Lioubov Dombrovskaia

Dra. Lioubov Dombrovskaia

Introduccin a la Ingeniera de Software

Introduccin a la Ingeniera de Software

Ciclo de vida de Software

Ciclo de vida de Software

Ciclo de vida clsico ideal fue propuesto por W. Royce a

El ciclo de vida clsico real tiene la siguiente forma:

Aplicacin secuencial de una serie de pasos

A todas las fases

Dra. Lioubov Dombrovskaia

Introduccin a la Ingeniera de Software

Introduccin a la Ingeniera de Software

Ciclo de vida de Software

Ciclo de vida de Software

Crticas al ciclo de vida clsico:

Proyectos raramente siguen el flujo secuencial

Prototipear consiste en construir una versin inicial de un

Vertical: desarrolla completamente algunas de las facetas del

Corregir segn se presenten los problemas

Dra. Lioubov Dombrovskaia

Dra. Lioubov Dombrovskaia

Introduccin a la Ingeniera de Software

Introduccin a la Ingeniera de Software