Você está na página 1de 29

Anlisis y Diseo Orientado

a Objetos
Texto Preparado para los Alumnos del CFT Simn Bolvar
Revisado - 2012
Diseo Orientado a Objetos

Introduccin a Orientacin Objetual.


La tecnologa de Objetos data de los aos 60, cuando surge la necesidad de describir y simular fenmenos como sistemas
de comunicacin, redes neurales, sistemas administrativos, etc.
En 1961 Krystin Nygaard con la idea de desarrollar un lenguaje de doble propsito (descripcin de sistema y simulacin
programable), crea SIMULA I. Los usuarios descubrieron que tambin provea de nuevas y poderosas facilidades cuando
era usado para otros propsitos, aparte de la simulacin, tales como el prototipeo y aplicaciones.
En 1967 se cre SIMULA 67, y en l se implementaron por primera vez los conceptos de clase, objeto y herencia, que en
adelante seran elementos centrales en los Lenguajes Orientados A Objetos. SIMULA 67 es una extensin del lenguaje
ALGOL 60 y diseado en 1967 por Ole - Johan Dahl y Krystin Nygaard, de la Universidad de Oslo y del Centro de
Computacin Noruego (Norsk Regasentral). Sin embargo Simula, as como se le conoce actualmente, es un lenguaje de
programacin de propsito general, que no es ampliamente utilizado.
En 1970 se crea el SMALLTALK, ste fue el mayor desarrollo de los lenguajes orientado a objetos. El proyecto de
investigacin se realiz en la Corporacin Xerox, Centro de Investigacin de Palo Alto (PARC - Palo Alto Research
Center) y fue dirigido por Alian Kay. Empez en los 70's y tuvo como meta, ms que el lenguaje de programacin, una
completa interfacez grfica y herramienta de desarrollo integradas.
Xerox PARC fue la pionera en el desarrollo y utilizacin de los componentes estndar de las modernas interfaces grficas,
como ventanas, iconos, mouse, etc.
Smalltalk fue el primer lenguaje orientado a objetos, ya que trat exclusivamente con ellos; los subsecuentes, se ha basado
en los conceptos utilizados por l. Smalltalk fue importante no slo por su lenguaje, sino por las herramientas de
desarrollo disponibles en su ambiente, stas incluyen visualizadores de clases (class browsers) e inspeccionadores de
objetos (object inspectors) .
Un visualizador de clases es una poderosa herramienta, que permite editar el cdigo del programa, en una manera mucho
ms conveniente y estructurada que utilizando editores convencionales. Por la estructura, inherente, bien definida por los
programas orientados a objetos, el visualizador de clases es capaz de mostrar, en forma grfica , el rbol de una clase
dada, permitiendo al usuario "apuntar y disparar" mtodo en particular (proceso) a ser editado. Otras ventajas del
visualizador es que muchas tareas de programacin se realizan slo por menes, por ejemplo la creacin de una nueva
clase modificacin de la estructura del rbol de herencia, modificacin de una estructura de una clase etc. Estas
operaciones son mucho ms complejas cuando se realizan en un ambiente de edicin tradicional.
Herramientas como stas, son una parte integral de la " promesa" de la Tecnologa Orientada a Objetos, ya que puede
simplificar la vida del programador, reduciendo el costo y el tiempo de desarrollo.
En los aos 80 evoluciona el SMALLTALK y se crea ADA, lo que hizo crecer el inters en el Diseo Orientado a Objetos.
En estos lenguajes la abstraccin de los datos tienen gran importancia. Los problemas del mundo real se representan
mediante objetos a los cuales se le agrega operaciones cuando es necesario
La TOO se fundamenta en el proceso de construccin y utilizacin de conocimientos, por lo tanto, objetos y clases son los
pasos ms importantes en la bsqueda de una nueva revolucin que reemplace , esta vez, parte del esfuerzo que implica la
organizacin y utilizacin del conocimiento , del mismo modo que en la primera, las mquinas reemplazaron el esfuerzo
fsico del hombre y de los animales, permitiendo el vertiginoso avance del mundo.
Los "Chips de Software" (Objetos y clases altamente reutilizables) sern el motor de la revolucin que ya se ha iniciado.
Participar en ella garantizar nuestra competitividad en el futuro y solo nos exige todo el esfuerzo de nuestra capacidad
creativa, y de la perseverancia de construir productos de alta calidad. La materia ms importante del software es la
inteligencia.
El Desarrollo de la Estructura del Pensamiento y la Construccin del Conocimiento
Desde muy temprana edad, aproximadamente hasta los siete aos, en los denominados perodos Senso-motriz y
Preparatorio de la inteligencia, en los que se afirma el esquema del objeto permanente, los seres humanos, a partir de la
experiencia de la observacin y captacin de cosas y hechos del mundo que nos rodea, construimos conceptos
"concretos". Estos nos permiten ser consistentes y razonar. Por ejemplo: Fido es un elemento del mundo real que es
conceptualizado como Fido. En l almacenamos sus caractersticas (DATOS), por ejemplo: tiene pelos, cuatro patas, dos
orejas , dos aos de edad, es de color blanco, otros. Junto con los datos tambin almacenamos sus acciones
(COMPORTAMIENTO), es decir, lo que puede o no hacer (ladrar, correr, saltar, comer, etc.). Como consecuencia de
este hecho (almacenamiento de los datos y comportamiento en una sola unidad conceptual), entre las muchas operaciones
de nuestra mente, podemos razonar que Fido no tiene alas, ni plumas, ni puede volar.
A las acciones que, cualquier elemento del mundo real, realiza como reaccin frente a un estmulo las denominaremos
Operaciones. Algunos comportamientos complejos son el resultado de la interaccin o sucesin de varias operaciones, a
stos los denominaremos Procesos. Sin embargo en nuestro enfoque, en la mayora de los casos y de manera genrica
utilizaremos el trmino OPERACION.
Los conceptos se construyen modelando los aspectos y caractersticas de cualquier objeto real, extrayendo los detalles
(datos y comportamiento) necesarios y descartando lo menos til. Este proceso, natural en los seres humanos, compuesto
por diversas operaciones tales como observar, captar, fijar, comparar, conceptualizar y otros es denominado abstraccin.
Prof.: Oscar Nez M.

Diseo Orientado a Objetos


Cuando pensamos en un auto, no visualizamos cada mnimo detalle que lo describa, lo ms probable es que tengamos en
mente slo las principales caractersticas fsicas y, dependiendo de nuestra experiencia, algunos de los subsistemas
importantes como la caja de cambios, o los sistemas de direccin y frenos.

En Tecnologa Orientado a Objetos (TO) a los conceptos se les llama objetos, en consecuencia, los OBJETOS son
MODELOS de entes del mundo real. Los percibimos porque tienen lmites que los esperan de su medio ambiente y de
los dems (IDENTIDAD). Se encuentran en un ESTADO especfico en el mundo.
Un objeto puede ser concreto (material)o abstracto (inmaterial), simple o complejo; pero siempre estar compuesto de
DATOS y OPERACIONES.
Continuando con el desarrollo de la estructura del pensamiento, encontraremos que aproximadamente a partir de los siete
aos, en la denominada etapa de las operaciones concretas, el ser humano aprende a CLASIFICAR (separar y agrupar
objetos de acuerdo a caractersticas y comportamientos comunes) y ORDENAR (establecer criterios de jerarqua que
permitan la organizacin).
La clasificacin es un medio por el cual organizamos el conocimiento.
Clasificar y ordenar es una consecuencia de la capacidad de interiorizar esquemas representativos (MODELOS), los
cuales permiten: por un lado, reconocer si un concepto (OBJETO) tiene o no las caractersticas de dicho esquema; y por
otro, incorporarlo o no en el conjunto de los que comparten ese mismo esquema (CLASE). Posteriormente organizamos
jerrquicamente en clases y superclases, construyendo en forma progresiva las grandes CLASIFICACIONES y las
OPERACIONES DE ORDEN.
Despus de los doce aos, en la etapa de las Operaciones combinatorias de la inteligencia (Pensamiento formal), el
hombre construye SISTEMAS y an TEORIAS como producto del raciocinio de Hiptesis (propuestas de solucin a
interrogantes o problemas), y de la representacin en dimensiones simultneas.
Un Sistema es un conjunto de componentes (conceptos y modelos, y an de otros sistemas) que interactan, en distintos
planos, entre s para alcanzar objetivos especficos. Cada Sistema construido es una manera de solucionar los diferentes
problemas que enfrenta el hombre a lo largo de su existencia, por ejemplo el Lenguaje, uno de los sistemas ms
elaborados, permite satisfacer la necesidad vital de la comunicacin.
En sntesis, construimos CONCEPTOS, MODELOS y SISTEMAS. Esta es la forma en que los seres humanos captamos
el mundo real y operamos en l. La tecnologa de Objetos intenta simular este hecho y sus fundamentos se sostienen en l.
Fundamentos de la Tecnologa de Objetos.
1. Simulacin. Representacin directa de elementos que "maneja" el usuario en el mundo real.
Consiste en recrear el mundo real. No se trata de construir "modelos ideales", sino de representarlo directamente. Por ello,
en este enfoque, primero se identifican las caractersticas de los elementos del mundo real, los que se organizan en las
denominadas ESTRUCTURAS DE DATOS. Luego se captan los comportamientos u operaciones, los cuales se imitan
o simulan mediante pequeos programas (procedimientos) a los que en adelante denominaremos METODOS. Y as como
en la vida real conceptualizamos en una sola unidad (datos y comportamiento), en TO simulamos este hecho colocando en
una especie de "cpsula" las estructuras de datos y los mtodos, a esta unidad denominamos OBJETO.
Tambin se simula la manera en que los entes del mundo real se comunican entre s, envindose seales o "mensajes" a
los que responden con una conducta o comportamiento especfico, de la misma manera se simulan las clasificaciones,
ordenamiento, organizacin, e incluso la herencia de los seres vivos.
En sntesis, se trata de actuar de la misma manera en que los humanos, a los que en informtica, en general, se nos
denomina usuarios, " manejamos" y operamos el mundo real.
2. Encapsulamiento. Utilizacin del concepto de "Caja Negra" a una potencia mucho mayor. Empaquetar datos y
operaciones
en forma conjunta se llama ENCAPSULACION.
La encapsulacin es el resultado (o acto) de ocultar, al usuario, los detalles de la implementacin de un objeto. El objeto
oculta sus datos a otros objetos y slo permite accesar a sus datos va sus propios mtodos mediante mensajes especficos,
es decir, se crea una " Caja Negra" que solo el constructor del objeto conoce. A esto se llama ocultamiento de informacin.
La encapsulacin protege los datos de un objeto de la corrupcin. Si todos los programas pudieran accesar a los datos
(como actualmente sucede con la tecnologa estructurada), fcilmente puede corromperse o perderse. La encapsulacin
protege los datos del objeto del uso arbitrario y no intencionado. As la creacin est protegida y la competencia
garantizada.
La encapsulacin tiene dos beneficios primordiales:
1. Modularidad. El cdigo de un objeto puede ser escrito y se puede mantener independiente del cdigo de otros objetos.
Un objeto se puede mover de sistema en sistema, se puede quitar, modificar y volver a colocar sin alterar el s is tema
general.
2. Esconder la informacin ( Information Hiding ). Un objeto tiene una interfaz con la que otros objetos se pueden
comunicar, pero puede mantener informacin privada para s misma que puede cambiar en cualquier momento, sin afectar
a los objetos que dependen de sta.
3. Reutilizacin. Capacidad de reutilizar cdigo sin alterarlo, programando solo lo adicional o diferente. Base de la
Herencia
Durante la vida de un sistema, las estructuras de datos se mantienen relativamente estables, mientras que las operaciones
sobre dichas estructuras cambian, dependiendo de situaciones. Por ello en el Anlisis y Diseo Orientado a Objetos, se da
nfasis primordial a los DATOS y al COMPORTAMIENTO de los objetos y tipos de objetos (modelos).Los datos, como
son relativamente estables, pueden ser utilizados muchas veces, modificando nicamente aquello que sea necesario para
tal o cual
Prof.: Oscar Nez M.

Diseo Orientado a Objetos


situacin, en la misma forma se procede con los comportamientos. En cambio, en el Anlisis y Diseo Estructurado, se da
nfasis a la descomposicin funcional orientada al proceso, en consecuencia, cualquier modificacin requiere de una
reconstruccin, normalmente, a partir de cero.

Principios Fundamentales.
Los objetos son las cosas fsicas y conceptuales que encontramos en el universo alrededor de nosotros. Hardware,
software, documentos, seres humanos, los conceptos son todos los ejemplos de los objetos.
Un objeto es algo real o abstracto acerca del cual almacenamos datos y mtodos que manipulan dichos datos.
Es una persona, lugar o cosa. Ejemplo: Una manzana. Todos los objetos tienen un estado y un comportamiento. Esto es
muy importante. Para el ejemplo de la manzana, la manzana (hablando de una manzana normal de color rojo) recin
bajada de un rbo l, est completa, es dura y de color rojo. Este es su estado. Uno sabe que si se muerde la manzana va a

sonar un "crunch", y esto se puede interpretar como un comportamiento. Despus de haberla mordido la manzana cambi
de estado. Los objetos pueden tener ms de un comportamiento y ms de un estado.
Una clase es un grupo de objetos con propiedades (atributos) similares, comportamiento comn (operaciones), relaciones
comunes entre objetos, y semntica comn.
Un grupo de objetos con las mismas caractersticas. Una clase contiene:
Una descripcin de las variables internas de los objetos de la clase.
Las operaciones que se pueden aplicar al objeto de la clase.
En este ejemplo vamos a analizar la clase Msica de Colombia es la clase padre de las clases hija Vallenato y Salsa. En
otras palabras las clases Vallenato y Salsa son derivadas de la clase Msica de Colombia. Ellas heredan todas las
propiedades de su padre. Las clases derivadas pueden adicionar, cambiar u ocultar los miembros pblicos de la clase padre
usando las reglas de la herencia. Cuidado... los miembros privados no pueden ser accesados por otras clases.
Clase padre Msica de Colombia
Atributos: Tipo de ritmo, tipo de instrumentos, msicos. Mtodos: bailada, cantada, tomada.
Clase hija Vallenato (hereda las propiedades de la clase padre) Atributos: Tipo de ritmo, tipo de instrumentos,
msicos.
Mtodos: bailada, cantada. El nuevo mtodo incluye el tocar un instrumento tomada.
Clase hija Salsa (hereda las propiedades de las clase padre) Atributos: Tipo de ritmo, tipo de instrumentos, msicos.
Mtodos: Bailada, cantada, tomada.
Prof.: Oscar Nez M. 3
1) Objeto.
2) Clases
Ejemplo.
Diseo Orientado a Objetos
3) Estructura de Objetos.
El modelo orientado a objetos se basa en encapsular cdigo y datos en una nica unidad, llamada objeto. La interfaz entre
un objeto y el resto del sistema se define mediante un conjunto de mensajes.
El motivo de este enfoque puede ilustrarse considerando una base de datos de documentos en la que los documentos se
preparan usando uno entre varios paquetes software con formateador de texto. Para imprimir un documento debe
ejecutarse el formateador correcto en el documento. Bajo un enfoque orientado a objetos, cada documento es un objeto
que contiene el texto de un documento y el cdigo que opera sobre el objeto. Todos los objetos del tipo documento
responden al mensaje Imprimir, pero lo hacen de forma diferente. Cada documento responde ejecutando el cdigo
formateador adecuado. Encapsulando dentro del objeto documento la informacin acerca de cmo imprimirlo, se puede
tener todos los documentos con la misma interfaz externa al us uario (aplicacin).
En general, un objeto tiene asociado:
Un conjunto de atributos que contienen datos acerca del objeto. A su vez, cada valor de un atributo es un objeto.
Un conjunto de mensajes a los que el objeto responde.
Un conjunto (puede ser unitario) de mtodos, que es un procedimiento o trozo de cdigo para implementar la respuesta a
cada mensaje. Un mtodo devuelve un valor (otro objeto) como respuesta al mensaje.
Puesto que la nica interfaz externa de un objeto es el conjunto de mensajes al que responde, es posible modificar la
definicin de mtodos y atributos sin afectar a otros objetos.
Tambin es posible sustituir un atributo por un mtodo que calcule un valor.
Ejemplo:
Un objeto documento puede contener un atributo de tamao que contenga el nmero de bytes de texto en el documento, o
bien un mtodo de tamao que calcule el tamao del documento leyndolo y contando el nmero de bytes.
"La capacidad de modificar la definicin de un objeto, sin afectar a l resto del sistema, est considerada como una de las
mayores ventajas del Modelo de Programacin Orientada a Objetos".
4) Jerarqua de Clases.
Normalmente en la realidad a modelar existen muchos objetos similares. Por similar se quiere decir que tienen una
naturaleza parecida, por lo que son candidatos a poseer atributos, mtodos y responder a mensajes comunes en un
contexto orientado a objetos (VIC).
Para el caso de los objetos similares, sera un trabajo intil definir cada uno de ellos por separado. Por t anto, se agrupan
para que conformen una clase. A cada uno de estos objetos se le llama instancia de clase. Todos los objetos de una clase
comparten una definicin comn, aunque difieran en los valores asignados a los atributos.
Ejemplo:
En un banco, son objetos los clientes, las cuentas y los prstamos. Una clase incluye:
Un atributo con valores en un conjunto cuyo valor es el conjunto de todos los objetos que son instancias de la clase.
Implementacin de un mtodo para el mensaje nuevo, el cual crea una nueva instancia de la clase.
Un esquema orientado a los objetos, normalmente requiere un gran nmero de clases. Sin embargo, a menudo se da el
caso que varias clases son similares. Para permitir la representacin directa de similitudes entre clases, se utiliza una
jerarqua de especializacin, como aquella utilizada por el modelo MER extendido.
Prof.: Oscar Nez M.

Diseo Orientado a Objetos


Ejemplo:
En un banco, es de esperarse que los Empleados y los Clientes tengan ciertos atributos comunes como RUC, nombre,
direccin y telfono, sin embargo los Empleados podran tener un atributo exclusivo, como salario, mientras que los
Clientes tendrn atributos como tasa de crdito. Aqu los empleados y clientes pueden ser representados por
especializaciones de una clase Persona. Los atributos y los mtodos especficos para Empleado se asocian a la clase
Empleado, en forma anloga, se acta para los clientes. Los atributos y mtodos comunes para empleados y clientes se
asocian a la clase Persona.
Obs.:

Denotaremos las clases por medio de rectngulos con lnea doble, mientras que las instancias de las mismas u objetos, se
representarn por rectngulos. El semicrculo denota la relacin ES_UN, o ESPECIA LIZACION de, que se utiliza para
construir la jerarqua de clases (VIC).
5) Operaciones.
Una accin que es afectada por, o requerida por un objeto. Las operaciones pueden ser selectoras, constructivas, o
iterativas . Una operacin es contenida en la interfaz del objeto y tiene sus detalles descritos en un mtodo
correspondiente. Las operaciones pueden ser compuestas, es decir, integrada por otras operaciones. Sin embargo no es
alentada, la encapsulacin de operaciones compuestas dentro de la interfaz a un objeto.
6) Mens aje.
Los objetos se comunican unos con otros mediante mensajes. El mensaje es enviado por un objeto emisor y recibido por
un objeto destino o receptor. Un mensaje invoca una o ms operaciones en el objeto receptor.
7) Herencia.
Principio por el cual una clase se puede derivar de otra clase ya existente, heredando las caractersticas del padre.
Relacin entre clases de objetos que permite incluir (re-usar) los atributos y operaciones definidas en otra clase ms
general de la cual se hereda o deriva. Es compartir atributos y operaciones entre clases tomando como base una relacin
jerrquica. En trminos generales se puede definir una clase que despus se ir refinando sucesivamente para producir
subclases. Todas las subclases poseen o heredan, todas y cada una de las propiedades de su superclase y aaden, adems,
sus propiedades exclusivas. No es necesario repetir las propiedades de las superclases en cada subclase.
Ejemplo:
Tengo el objeto fruta, con algunas propiedades inherentes a la fruta. Luego tengo el objeto manzana, que es hijo de fruta y
por lo tanto hereda las propiedades de la fruta, pero puede tener otras propiedades propias de la manzana. Este es un
ejemplo sencillo pero ms o menos ilustra lo que se trata de explicar. El hijo hereda las caractersticas del padre, pero tiene
otras propias y mejora o empeora, algunas caractersticas del pap.
Ejemplo:
Retornando al caso del banco, podemos observar que como atributos para la clase persona se tiene ruc, nombre, direccin
y telfono. A su vez los empleados tienen un sueldo, y los clientes una tasa de crdito.
Prof.: Oscar Nez M.

Diseo Orientado a Objetos


En este caso, un objeto de la clase persona tiene como atributos RUC, Nombre, Direccin y Telfono, un Empleado,
hereda todos los anteriores y agrega el atributo Sueldo, mientras que el Cliente agrega el atributo Tasa Crdito.
Obs.:
1. El tringulo del diagrama denota la relacin COMPUESTO_DE o INTEGRADO_POR, para indicar que los atributos
de una clase pertenecen a las clases que se indican. En algunos formalismos para modelar clases y objetos existe la
cardinalidad, para indicar el nmero de veces que un atributo puede aparecer en una clase.
2. En este caso no se han incluido los mtodos pertenecientes a cada clase ni los mensajes a los que responde cada
mtodo. Esto se ha obviado por quedar fuera del mbito de nuestro inters.
8) Polimorfismo.
Principio en el cual objetos de diferentes clases pueden entender el mismo mensaje pero responder de manera distinta.
Una vez que se tienen bien claros estos conceptos se puede entender mejor la filosofa de objetos. Ahora tratamos de
encapsular los estados de los programas por medio de objetos, que pueden ser accesados solamente por medio de
operaciones definidas dentro de ellos mismos.
Los programas estn compuestos por varios objetos. Cada objeto tiene sus variables internas as como sus mtodos bien
definidos. Un mtodo es el equivalente a un procedimiento.
La misma operacin es resuelta de diferente forma, segn el objeto que recibe el mensaje. Significa que una misma
operacin puede comportarse de modos distintos en distintas clases. La operacin mover, por ejemplo, se puede comportar
de modo distinto en las clases Ventana y Pieza de ajedrez. Una operacin es una accin o una transformacin que se lleva
a cabo o que se aplica a un objeto. Justificar a la derecha, visualizar y mover son ejemplos de operaciones. Una
implementacin especfica de una operacin por parte de una cierta clase es lo que se denomina mtodo. Dado que los
operadores orientados a objetos son polimrficos es posible que haya ms de un mtodo que lo implemente.
En el mundo real una operacin es simplemente, una abstraccin de comportamiento anlogo entre distintas clases de
objetos. Cada objeto "sabe" llevar a cabo sus propias operaciones. Sin embargo, en un lenguaje orientado a objetos es este
el que selecciona automticamente el mtodo correcto para implementar una operacin basndose en el nombre de la
operacin y en la clase del objeto que esta siendo afectado. El usuario de una operacin no necesita ser consciente del
nmero de mtodos que existen para implementar una cierta operacin polimrfica. Se pueden aadir nuevas clases sin
modificar el cdigo existente, siempre y cuando se proporcionen mtodos para todas las operaciones aplicables a las
nuevas clases.
Objeto

9) Identidad.
Los datos estn cuantificados en entidades discretas y distinguibles denominadas objetos (PE. una televisin, una
bicicleta, un rbol). Los objetos pueden ser concretos, como un archivo en un sistema de archivos, o bien conceptuales
como la poltica de planificacin en un sistema operativo con multiprocesos. Cada objeto posee su propia identidad
inherente. En otras palabras: dos objetos sern distintos aun cuando los valores de todos sus atributos (tales como el
nombre y el tamao) sean idnticos.
Prof.: Oscar Nez M.

Diseo Orientado a Objetos


En este modelo no necesitamos detectar los atributos que constituirn el identificador de un objeto. Aqu cada objeto
conserva su identidad independientemente de su estado.
El estado de un objeto est dado por los valores que en un momento tengan sus atributos. En el caso de las otras tcnicas,
habamos identificado un elemento de la realidad en base al valor de algn conjunto de sus atributos, por ejemplo el
nombre de una persona o la patente de un auto. Aqu podemos utilizar el mismo criterio para fines de bsqueda de

informacin, pero a diferencia de los sistemas como los relacinales, aunque modifiquemos el nombre de un objeto
persona, ste seguir siendo el mismo objeto.
10) Clasificacin.
Significa que los objetos con la misma estructura de datos (atributos) y comportamiento (operaciones) se renen para
formar una clase. La seleccin de clases es arbitraria y depende de la aplicacin.
Ejemplo.
Objetos: Bicicleta de montaa, Bicicleta de carreras, Bicicleta de nios. Clase: Bicicleta.
Atributos: Tamao del cuadro, tamao de rueda, material, marca, velocidad Operaciones: mover, reparar, cambiar
velocidad
Objetos: Triangulo, Cuadrado, Octgono. Clase: Polgonos.
Atributos: vrtices, color del borde, color del interior Operaciones: dibujar, borrar, mover
11) Abs traccin.
Consiste en representar las caractersticas esenciales de un objeto, sin preocuparse de las restantes caractersticas (no
esenciales). Una abstraccin se centra en la vista externa de un objeto, de modo que sirva para separar el comportamiento
esencial de un objeto, de su implementacin. Definir una abstraccin significa describir una entidad del mundo real, no
importa lo compleja que pueda ser, y a continuacin utilizar esta descripcin en un programa. Una clase se puede definir
como una descripcin abstracta de un grupo de objetos, cada uno de los cuales se diferencia por su estado especfico y por
la posibilidad de realizar una serie de operaciones.
12) Encapsulamiento.
Mecanismo que permite ocultar los detalles de implementacin de un objeto. Permite empaquetar en una unidad los datos
y las funciones que operan sobre dichos datos.
Consiste en la combinacin de datos e instrucciones en un nuevo tipo de datos denominado clase. Facilita la
descomposicin modular. En la prctica, una clase estar formada por dos partes: Una interfaz mediante la cual se
acceder a la funcionalidad de los objetos y Una representacin de la abstraccin utilizando las facilidades del lenguaje.
Es una buena norma el realizar el acceso a los datos del objeto utilizando los mtodos de la interfaz. Los lenguajes OO
permiten especificar en el objeto elementos que no sern visibles desde el exterior del mismo pero que son necesarios para
su representacin. A esta caracters tica se le conoce con el nombre de Ocultamiento de Informacin.
Acceso
..-
1
Mtodos,1
I- Datos
13) Agregacin.
Composicin de un objeto por otros. Es una relacin ms dbil que la que existe entre el atributo y el objeto al cual
pertenece, y ms fuerte que una asociacin.
14) Concurrencia.
Propiedad que distingue un objeto activo de otro inactivo.
Prof.: Oscar Nez M.

y^ ^ \

Diseo Orientado a Objetos


15) Persistencia.
Es la propiedad de un objeto cuya existencia trasciende el tiempo y/o el espacio (PE. El objeto contina existiendo luego
de que su creador deja de existir; la ubicacin de un objeto se mueve a un espacio de direcciones diferente de aquella
donde fue creada).
16) Visibilidad.
Capacidad de restringir el acceso a atributos y servicios de un objeto. Particularmente importante en el diseo e
implementacin (PE. En C++ existen: pblico, protegido, privado).

Beneficios de la Tecnologa O.O.


Por qu usar el paradigma Orientado a Objeto?
Proximidad de los conceptos de modelado respecto de las entidades del mundo real
Mejora captura y validacin de requisitos
Acerca el "espacio del problema" y el "espacio de la solucin"
Modelado integrado de propiedades estticas y dinmicas del mbito del problema
Facilita construccin, mantenimiento y reutilizacin
Conceptos comunes de modelado durante el anlisis, diseo e implementacin
Facilita la transicin entre distintas fases
Favorece el desarrollo iterativo del sistema
Disipa la barrera entre el "qu" y el "cmo"
"...Los conceptos bsicos de la OO se conocen desde hace dos dcadas, pero su aceptacin todava no est tan extendida
como los beneficios que esta tecnologa puede sugerir".
"...La mayora de los usuarios de la OO no utilizan los conceptos de la OO de forma purista, como inicialmente se
pretenda. Esta prctica ha sido promovida por muchas herramientas y lenguajes que intentan utilizar los conceptos en
diverso s
grados ". Wolfgang Strigel
Beneficios de las tcnicas OO.
Muchos de los beneficios son alcanzados nicamente cuando el Anlisis y Diseo son utilizados con herramientas CASE
OO, basados en repositorios que generan cdigos, entre ellos:
Reus abilidad
Las clases son diseadas de tal manera que ellas puedan ser reutilizadas en muchos sistemas. Para maximizar el reuso las
clases deben ser construidas de manera que puedan ser personalizadas. Un repositorio debera ser cargado con una
coleccin de clases reusables.
Un objetivo permanente de las tcnicas OO, es conseguir reusabilidad masiva en la construccin de software.
Es tabilidad
Las clases diseadas para el reuso repetido, llegan a ser estables de la misma manera que los microprocesadores y otros
chips que son bastante estables. Las aplicaciones sern construidas utilizando chips de software.
El Diseador piensa de Comportamiento de Objeto, no en Niveles de Detalle

El encapsulamiento oculta los detalles y hace fcil el uso de clases complejas. Las clases son semejantes a las cajas
negras. El desarrollador utiliza la caja negra sin mirar su interior. El tiene un entendimiento del comportamiento de la caja
negra y cmo comunicarse con ella.
Cons truccin de Objetos de complejidad Creciente
Los objetos se construyen fuera de los objetos. Una buena manera de fabricar es construir tomando una lista de materiales
de partes y subpartes existentes. Esto posibilita construir componentes de software complejos y los mismos se utilizarn
para construir otros bloques de software ms complejos.
Confiabilidad
EL software construido a partir de una librera de clases estables, es probable que se encuentre libre de errores, respecto a
construir software desde el inicio. Cada mtodo en una clase es en s mismo simple y diseado para ser confiable.
Prof.: Oscar Nez M.

Diseo Orientado a Objetos


Verificacin de Correcciones
El Diseo OO con tcnica formal para la creacin de mtodos, puede generar potencialmente software de alta
confiabilidad. Tcnicas para verificar y garantizar la operacin correcta de una clase, probablemente estn disponibles en
nuevas generaciones de herramientas CASE OO.
Diseo Rpido
Las aplicaciones son creadas tomando componentes pre-existentes. Muchos componentes son construidos de tal forma
que, puedan ser observados, personalizados, para un diseo particular. Los componentes pueden ser vistos, customizados
y enlazados en la pantalla de la herramienta CASE.
Nuevos Mercados de Software
Las compaas de software, deberan proporcionar libreras de clases para reas especficas, fcilmente adaptables a las
necesidades de la organizacin. La era de los paquetes monolticos esta siendo reemplazada por software que incorpora
clases y encapsula paquetes de diferentes vendedores.
Dis eo de Alta Calidad
Los diseos son a menudo de alta calidad, ya que ellos se construyen a partir de componentes que han sido aprobados y
refinados repetidamente.
Integridad
Las estructuras de Datos pueden ser utilizadas solamente con mtodos especficos. Esto es particularmente importante en
sistemas distribuidos y sistemas CLIENTE/SERVIDOR, donde usuarios desconocidos pueden tratar de accesar al sistema.
Facilidad de Programacin
Los programas son construidos utilizando pequeas plazas de software las cuales son generalmente fciles de crear.
Fcil Mantenimiento
Los programas de mantenimiento generalmente cambiarn los mtodos correspondientes a una clase. Cada clase realiza
sus operaciones independientemente de otras clases.
Creatividad
Implementadores hbiles en poderosas herramientas CASE OO laborando sobre estaciones de trabajo, encuentran que
puede generar rpidamente muchas ideas. Las herramientas estimulan la creacin e implementan las invenciones. La
genialidad individual puede ser ms creativa.
Ciclo de Vida Dinmico
Los objetivos de desarrollo de un sistema, a menudo cambian durante la implementacin. Las herramientas CASE OO,
hacen los cambios durante el ciclo de vida rpidamente.
Esto permite a los diseadores de sistemas satisfacer mejor a los usuarios finales, adaptarse a los cambios, refinar los
objetivos y mejorar constantemente el diseo durante la implementacin.
Refinamiento durante la Construccin
Las personas creativas cambian constantemente el diseo de su trabajo mientras se est implementando. Esto conduce a
ms y mejores resultados. Los trabajos creativos objetivos, son una y otra vez refinados,. Las herramientas CASE OO
(Orientado a Objetos) proporcionan a los constructores de software la capacidad para refinar el diseo durante la
implementacin.
Modelamiento ms realstico
El AOO modela la empresa o rea de negocio de una manera ms coherente y minuciosa que los mtodos tradicionales de
anlisis. El anlisis se traslada directamente al diseo e implementacion. En tcnicas convencionales, el entorno del
problema cambia cuando vamos del anlisis al diseo y del diseo a la programacin. Con tcnicas de OO Anlisis,
Diseo e implementacin, utiliza el mismo paradigma y lo refinan sucesivamente.
Mejor Comunicacin entre Profesionales de Informtica y los usuarios finales
Los usuarios finales entienden mejor el paradigma OO. Ellos piensan en trminos de eventos, objetos y polticas de
negocios que describen el comportamiento de los objetos. Las metodologas OO estimulan el mejor entendimiento,
cuando el usuario final y los desarrolladores comparten un modelo comn.
Modelos Inteligentes de la Empresa
Los modelos de la empresa debera escribir las reglas del negocio con las cuales el ejecutivo desearlas administrarla. Esto
debera ser expresado en trminos de eventos y de cmo stos cambian el estado de los objetos del negocio. El diseo de
la aplicacin debera ser derivando automticamente como sea posible, el modelo del negocio.
Especificaciones y Diseos Declarativos
La especificacin y el diseo, construido con la formalidad de las herramientas CASE, deberan ser declarativas tanto
como sea posible, fijando explcitamente lo que es solicitado. Esto permite al diseador pensar en el usuario antes que en
el computador.
Interface Grfica Seductiva al Usuario
Se debera utilizar interfaces grficas para usuarios, tal que sta apunte al icono que relacione al objeto.
Prof.: Oscar Nez M.

Diseo Orientado a Objetos


Independencia de Diseo
Las clases son diseadas independientemente de plataforma de operacin, hardware o software.

Las clases emplean requerimientos y respuestas de forma. Esto permite que ellos sean utilizados con mltiples sistemas
operativos, DBMS, manejadores de redes, interfaces grficas para usuarios, etc.
Interoperatividad
Software de diferentes vendedores pueden trabajar juntos. Un vendedor puede utilizar clase de otros vendedores. La
interoperatividad de software de diferentes vendedores es uno de los objetivos ms importantes de los estndares de la
OO. Software desarrollados independientemente en lugares separados, deberan ser capaces de trabajar juntos y
presentarse como una unidad simple al usuario.
Computaci n Cliente / S ervidor
En el sistema Cliente / Servidor, las clases en el software cliente deberan enviar sus requerimientos a las clases de
software servidor y recibir respuestas. Una clase servidor puede ser utilizada por muchos clientes. Esto puede accesar al
software nicamente a travs de los mtodos (as los datos se protegen de corrupciones).
Computacin masivamente Distribuida
Redes alrededor del mundo emplearn directorios de software de objetos accesibles. El diseo orientado al objeto, es la
clave para la computacin masivamente distribuda. Las clases en una mquina interactuarn con cualquier otra, sin
necesidad de saber dnde residen. Ellas envan y reciben mensajes en formatos estndares.
Computaci n Paralela
La velocidad de las maquinas., pueden ser ampliamente mejoradas mediante la instalacin de computadoras en paralelo.
Se pueden tener procesamientos simultneos y concurrentes en mltiples chips de procesadores (eventualmente, un chip
puede tener muchos procesadores). Objetos en diferentes procesadores se ejecutarn simultneamente, cada uno de ellos
actuando independientemente.
Alto Nivel de Automatizacin de Bases de datos
Las estructuras en Base de Datos OO, estn ligadas a mtodos que toman acciones automticas. Una Base de Datos OO,
tiene su inteligencia construida en la forma de mtodos, mientras que otras bases de datos no.
Performance de Mquinas
La Bases de Datos Orientada a Objetos han demostrado una mayor performance que las bases de datos relacionales para
ciertas aplicaciones con estructuras de datos ms complejas. Las bases de datos OO, la computacion concurrente y el
diseo OO prometen mayores saltos en la performance de las mquinas LAN'S basadas en sistemas Cliente/Servidor.
Emplearn servidores de Base de Datos concurrentes y orientadas al objeto.
Migracin
Existiendo o no aplicaciones orientadas a objetos, ellos pueden ser preservados convenientemente con una cobertura OO,
comunicndose entre ellos mediante mensajes estndares OO.
Mejores herramientas CAS E
Las herramientas Case utilizarn tcnicas grficas para disear las clases y sus interacciones, y para utilizar objetos
existentes adaptados en nuevas aplicaciones. Las herramientas deberan facilitar el modelamiento en trminos de eventos,
trig gers (iniciadores), estado de los objetos, etc. Las herramientas de los CASE OO generan cdigos tan pronto como una
clase sea definida y permitir al diseador probar y utilizar el mtodo creado. Las herramientas debern ser diseadas para
estimular la mxima creatividad y continuo refinamiento del diseo durante la construccin.
Industriales de Libreras de Clases
Las compaas de software comercializarn libreras para diferentes reas de aplicacin. Las libreras de clases
independientes de las aplicaciones, sern tambin importantes y stas sern proporcionadas como facilidades de
herramientas
CASE (VIC).
Libreras de Clases Corporativas
Las corporaciones, crearn sus propias libreras de clases que reflejen sus estndares internos y requirimientos de
aplicacin. La identificacin TOP-DOWN de los OBJETOS del negocio, es un aspecto importante de la ingeniera de la
Informacin.
Prof.: Oscar Nez M.

Diseo Orientado a Objetos

UML, (Unified Modeling Language).


Seguramente habr observado sistemas de informacin computarizados y no computarizados, y en un porcentaje mnimo
tenemos a los usuarios que estn conforme con los programas desarrollados, o tal vez hemos conversado con usuarios que
han deseado modificar un sistema integrado y dicho cambio le ha producido el desequilibrio de otras unidades del sistema
incorporado, o ha encontrado desarrolladores que sin conocer correctamente los procesos empiezan construyendo
formulario tras formulario y desarrollan la aplicacin, todo esto conlleva a poder analizar las causas que generan este
desequilibrio es el incorrecto anlisis de los procesos para la construccin de software de aplicaciones comerciales.
Para ello el UML, (Unified Modeling Language), Lenguaje Unificado de Modelado esta compuesto por una gama de
diagramas o artefactos, que permiten graficar o tomar una radiografa a los procesos para una interpretacin de los mismos
desde el punto de vista de usuario como de los desarrolladores de Software. UML es un lenguaje que permite modelar,
construir y documentar los elementos que forman un sistema software orientado a objetos. Se ha convertido en el estndar
de facto de la industria, debido a que ha sido impulsado por los autores de los tres mtodos ms usados de orientacin a
objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh. Estos autores fueron contratados por la empresa Rational Software
Co. para crear una notacin unificada en la que basar la construccin de sus herramientas CASE. En el proceso de
creacin de UML han participado, no obstante, otras empresas de gran peso en la industria como Microsoft, HewlettPackard, Oracle o IBM, as como grupos de analistas y desarrolladores.
Esta notacin ha sido ampliamente aceptada debido al prestigio de sus creadores y debido a que incorpora las principales
ventajas de cada uno de los mtodos particulares en los que se basa (principalmente Booch, OMT y OOSE). UML ha
puesto fin a las llamadas "guerras de mtodos" que se han mantenido a lo largo de los 90, en las que los principales
mtodos sacaban nuevas versiones que incorporaban las tcnicas de los dems. Con UML se fusiona la notacin de estas
tcnicas para formar una herramienta compartida entre todos los ingenieros software que trabajan en el desarrollo
orientado a objetos.
Uno de los objetivos principales de la creacin de UML era posibilitar el intercambio de modelos entre las distintas
herramientas CASE orientadas a objetos del mercado. Para ello era necesario definir una notacin y semntica comn. En
la Figura 2 se puede ver cul ha sido la evolucin de UML hasta la creacin de UML 1.3, en el que se basa este

documento. Hay que tener en cuenta que el estndar UML no define un proceso de desarrollo especfico, tan solo se trata
de una notacin.
Desde principios de los 90, los artculos publicados en el Journal of Object Oriented Programming (JOOP) por James
Odell, James Rumbaugh, Grady Booch, Desmond d'Souza, Bertrand Meyer, Steve Cook, John Daniels, Sally
Shlaer y Stephen J. Mellor entre otros, han sido una constante fuente de conocimiento. Publicaciones pioneras como el
Object Oriented Technology, A Manager's Guide de David A. Taylor, en su primera edicin de 1990 y en la segunda
ampliada de 1998, han tenido una gran influencia en como abordar la presentacin didctica. Tambin los libros de Peter
Coad et al, Object Oriented Analysis, Design and Programming, Object Models y Java Modeling Color with UML, han
sido de una ayuda extraordinaria. La obra enciclopdica The Unified Modeling Language: Reference Manual de
Rumbaugh & Jacobson & Booch, es un punto de referencia constante. Sin duda, uno de los autores ms influyentes ha
sido Martin Fowler. Su primer libro Analysis Patterns continua siendo una referencia clave. Posteriormente, la primera
edicin de UML Distilled en 1997 y su ltima edicin ampliada en 2000, se ha convertido en el libro de cabecera de UML.
Otro clsico por la excelencia de su trabajo es Applying UML and Patterns de Craig Larman que en su segunda edicin
aparecida en verano de 2001 se ha superado a si mismo. Tambin recientes y con muy buen material que ha sido
incorporado a la gua, tenemos los libros de Wendy & Michael Boggs, Mastering UML with Rational Rose, de Alistair
Cockburn, Writing Effective Use Cases; de Scott W. Ambler, The Object Primer segunda edicin; y de John Chessman
& John Daniels, UML Components, una de las novedades ms interesantes de 2001.
MAINSTREAM OBJECTS
Combina una sntesis de las principales tcnicas y enfoques OO.
Prof.: Oscar Nez M.

Diseo Orientado a Objetos


Rumbaugh / Coad / Yourdon:
Estructura de Objetos
Ciclo de Vida
Jacobson:
Enfoque Use Case (Casos de Usos; secuencia de transformacin, para capturar requerimientos del sistemas)
R.Wirfs - Brock:
Responsability-Driven model (como estructurara la funcionalidad de un sistema OO.)
La tecnologa orientada a objetos persigue el antiguo principio del divide y vencers. Su objetivo es descomponer la
complejidad en partes ms manejables y comprensibles. No parece que esto sea algo novedoso con respecto a la
tradicional descomposicin funcional de los mtodos estructurados. Sin embargo, la gran diferencia reside en aplicar la
dualidad estructura-funcin en pequeas unidades capaces de comunicarse y reaccionar en base a la aparicin de una serie
de eventos. El esquema dominante de la separacin de estructuras de datos y funciones (bases de datos y programas) est
amenazado pero an se resiste a desaparecer.
Problemas en OO.
Un objeto contiene datos y operaciones que operan sobre los datos, pero ...
Podemos distinguir dos tipos de objetos degenerados:
Un objeto sin datos (que sera lo mismo que una biblioteca de funciones)
Un objeto sin "operaciones", con slo operaciones del tipo crear, recuperar, actualizar y borrar (que se correspondera
con las estructuras de datos tradicionales)
Un sistema construido con objetos degenerados no es un sistema verdaderamente orientado a objetos .
"Las aplicaciones de gestin estn constituidas mayoritariamente por objetos degenerados".
MODELOS UTILIZADOS POR ADOO. Modelo de Estructura de Objetos (OSM).
El OSM es el modelo central. Contiene las clases de objetos requeridas para construir la aplicacin y las relaciones entre
ellas. Se construye a travs de un proceso aditivo durante todo el ciclo de desarrollo del sistema.
Modelo de Procesos de Negocios (BPM).
El BPM describe los procesos que se llevan a cabo en la organizacin. Se lo utiliza para analizar la organizacin y
comprender sus procesos, parte de los cuales (o todos), sern soportados por el sistema a desarrollar.
Modelo de Secuencias de Transacciones (TSM).
El TSM parte de la especificacin de alto nivel del BPM y lo traslada en requerimientos para la aplicacin (el TSM
corresponde conceptualmente con los USE CASE - casos de uso - de Jacobson).
Diagrama de Interaccin de Objetos (OID).
Los OID's muestran las interacciones entre objetos requeridas para proveer al usuario los servicios descritos en el TSM.
Diagramas de Flujo de Actividad (AFD).
Los AFD's son utilizados para analizar y presentar flujos de actividad complejos en los procesos de negocio y en las
secuencias de transacciones (secuencias, iteraciones y decisiones).
Diagrama de ciclo e vida de objetos (OLD).
El OLD es utilizado para describir como un objeto cambia de estados en el tiempo y que eventos producen dichos cambios
de estado.
Modelo global del sistema (SGM).
El SGM es utilizado para dividir el sistema en unidades de diseo manejables. Es una herramienta para manejar la
complejidad de desarrollo de grandes sistemas. Especifica las interfaces entre las unidades de diseo.

Prof.: Oscar Nez M.

Diseo Orientado a Objetos


Modelo Estructural

Modelo de Estructura de

(Esttico)

Objetos (OSM)

Modelo de Comportamiento (Dinmico)

Diagrama de Ciclo de Vida de Objetos (OLD)


Diagrama de Interaccin de Objetos (OID)
Modelo Funcional
Modelo de Procesos de Negocios (BPM)
Modelo de Secuencia de Transacciones (TSM)
Prof.: Oscar Nez M.

Diseo Orientado a Objetos


COMPONENTES DEL OSM. 1.
Clases de Objetos. Objetos Entidad.
Representan algo real o abstracto sobre el cual el sistema necesita almacenar datos. Representa la memoria esencial del
negocio. Los objetos del negocio (business objects) son normalmente objetos entidad. Se representan en el OSM con el
siguiente s mbolo:
Membre Class

Objetos Interface.
Representan los objetos tcnicos requeridos para vincular la aplicacin con el entorno. Representan el vnculo a travs del
cual el sistema recibe o suministra datos e informacin al entorno. Tpicamente incluyen interfaces con el usuario
(pantallas, reportes, etc.) e interfaces con otras aplicaciones. Se representan en el diagrama de estructura de objetos con el
siguiente smbolo:
Interface Nombre Clase

Objetos de Control.
Contienen comportamiento que no pertenece naturalmente ni a Objetos Entidad ni de Interfaz. Son normalmente objetos
transitorios, como ser un controlador de reportes. Se representan en el diagrama de estructura de objetos con el siguiente
smbolo:
Nombre Clase

Clases abstractas y concretas.


Una clase de la cual pueden generarse instancias particulares (objetos), se denominan clase concreta.
Una clase abstracta es aquella que no tiene instancias (objetos) propias. Las clases abstractas son un poderoso mecanismo
conceptual para definir estructuras comunes de atributos, operaciones y restricciones, reutilizadas a travs de la herencia
por mltiples clases concretas.
En el diagrama de estructura de objetos una clase abstracta se representa con un rectngulo punteado.
Prof.: Oscar Nez M.

9
Modelo de Estructura de Objetos (OSM) UML: Diagrama de Clases (Class Diagram)

El OSM es el modelo fundamental que provee un medio uniforme par modelar el sistema desde la captura de
requerimientos en la etapa inicial del anlisis hasta la implementacin, atravesando todo el ciclo de desarrollo del sistema.
Es te modelo identifica:
Las clases de objetos en la aplicacin.
Como las clases de objetos se asocian unas con otras.
Como se comunican los objetos.
Los detalles de cada clase de objetos, incluyendo atributos y operaciones.
Durante el proceso de anlisis y diseo, el OSM es definido en sucesivos niveles incrementales de detalle, hasta que el
nivel necesario para la implementacin es alcanzado.
Todos los dems modelos capturan detalles que alimentan este modelo.
El desarrollo de OSM es un proceso aditivo, diferencindose del enfoque transformacional caracterstico de otros mtodos
como el estructurado, donde los DFD son transformados en diagramas de estructura, con los consiguientes problemas que
esto acarrea.
Diseo Orientado a Objetos
2.
Caractersticas de las Clases de Objetos.
Operaciones.
Una operacin define un servicio ofrecido por un objeto junto con la informacin que debe suministrarse cuando es
invocado (nombre, argumentos de entrada y/o salida). Tambin puede contener una especificacin de mtodo, el cual
especifica una implementacin para la operacin.
Durante la etapa de Anlisis o Diseo Lgico pueden utilizarse tpicamente texto libre o pseudocdigo. Durante el Diseo
Fsico dichas especificaciones son trasladadas a un lenguaje de programacin especfico, como por ejemplo: C++, Java,
Visual Basic, etc.
Algunas operaciones pueden asumirse que existen para cada clase de objetos sin identificarlas formalmente. Estas son
llamadas operaciones implcitas. Las operaciones implcitas ms importantes son: Crear, Destruir, Leer y Actualizar. Una
operacin implcita debe ser formalmente definida cuando sus pre y post condiciones no sean triviales.
La identificacin y especificacin de operaciones es una tarea clave durante el Diseo Lgico.
Atributos.
Son valores de datos asociados a los objetos de una clase a la cual describen. Estn fuertemente asociados con la clase de
objetos que los contienen, de tal forma que no tienen existencia independiente o identidad de objeto. La decisin de
cuando un tem debe considerarse como atributo o como clase vara de sistema en sistema, dependiendo de su semntica
en el dominio del problema, es decir, lo que en un sistema se modela como atributo en otro puede modelarse como una
clase.
Cada atributo identificado debe ser atmico en el sentido de que debe ser tratado como una unidad, es decir, puede ser un
valor simple o un grupo de valores tratados siempre como una unidad (PE. Direccin). Debe notarse que las clases no se
modelan en formas normales. La decisin sobre la estructura de datos a utilizar se difiere hasta el Diseo Fsico.
Los atributos pueden basarse en definiciones de tipos de atributos, lo cual provee una definicin estndar sobre formato,
longitud y dominio de valores para atributos del mismo tipo.
Restricciones.
Las restricciones pueden especificarse sobre los valores que un atributo puede tomar. La implementacin de las
restricciones puede realizarse de diferentes formas:

Reglas de validacin durante los procesos de entrada de datos (user inputs).


Database-level triggers
Lgica de control contenida en una o ms operaciones.
3.
Asociaciones entre Objetos.
a) Relaciones Estticas.
Las relaciones estticas describen como los objetos se asocian unos con otros en la misma forma que en el modelo
Entidad-Relacin. Identifican as mismo dependencias entre objetos, cuando un objeto requiere de la existencia de otro ya
sea de la misma clase o de otra. Las relaciones estticas se establecen usualmente entre objetos de tipo entidad.
Al igual que los atributos, las relaciones modelan informacin sobre un objeto (cosas que un objeto debe conocer sobre s
mismo). Estas son propiedades de un objeto. Los atributos son valores de datos. Las relaciones son valores que se
referencian otros objetos.
Una relacin esttica se representa en el diagrama de estructura de objetos como una lnea slida entre las clases de
objetos , con smbolos de cardinalidad en sus extremos. Las relaciones pueden etiquetarse para identificar el propsito de
la asociacin. El diseador puede optar por:
Un nombre para cada direccin de la relacin.
Un nombre para una direccin de la relacin.
Un solo nombre que representa ambas direcciones de la relacin.
Sin nombre.
Por cuestiones de simplicidad, las relaciones son modeladas como binarias, es decir, solo dos clases de objetos, no
necesariamente distintas, participan en relacin. Es posible que entre el mismo par de clases exista ms de una relacin.
La cardinalidad identifica el nmero mximo y mnimo de instancias de una clase (objetos) que participan en una relacin
dada, en el mismo sentido que lo hacen en el modelo Entidad-Relacin. En el diagrama de estructura de objetos
utilizaremos la notacin de "pata de gallo" para especificar cardinalidades, aunque puede utilizarse otras como ser pares
ordenados, flechas (Bachmann), etc.
Prof.: Oscar Nez M.

10

Diseo Orientado a Objetos


Pueden observarse las siguientes cardinalidades:
Mnimo 0 - Mximo 1
Mnimo 1 - Mximo 1
Nombre Clase

Nombre Clase

a,*

U*

Mnimo 0 - Mximo N Mnimo 1 - Mximo N


b) Herencia.
La herencia es el mecanismo a travs del cual los atributos, operaciones y restricciones definidas para una clase,
denominada superclase, pueden ser heredados (reutilizados) por otra clase denominadas subclases. La herencia utiliza el
principio "es un tipo de Una subclase puede redefinir operaciones heredadas. Adicionalmente, una subclase puede definir
nuevos atributos y operaciones.
Se distingue entre herencia simple y mltiple. La herencia simple se da cuando una subclase hereda de una nica
superclase. En el caso de la herencia mltiple, una subclase puede heredar de varias superclases.
En el OSM, la relacin de herencia se representa de la siguiente manera:
PE.:
c) Agregacin.
La agregacin es un tipo de asociacin fuerte, donde los objetos de una clase se componen de objetos de otra(s) clase (s).
Se diferencia de de las relaciones estticas en la fuerza semntica del vnculo. En una relacin de agregacin un objeto
compone otro. En la relacin esttica existe un vnculo pero no una compo sicin. La agregacin es la aplicacin del
principio " el todo y sus partes
En el OSM, la relacin de agregacin se representa de la siguiente manera:
Prof.: Oscar Nez M.

10

Diseo Orientado a Objetos

PE.
d) Comunicacin por Mensajes.
Las asociaciones por comunicacin pueden utilizarse para mostrar que objetos de una clase se comunican con objetos de
otra clase o de la misma. Una asociacin por comunicacin corresponde al conjunto de mensajes que son enviados por los
objeto s de una clase a los objetos de otra clase o de la misma. Tpicamente, la asociacin por comunicacin es la nica
asociacin existente entre objetos de los tres diferentes tipos.
En el OSM, la asociacin por comunicacin se representa de la siguiente manera:
Emisor

Riicr-ptor

7
4. Consideraciones: Tcnicas avanzadas de OSM.
Visibilidad Define que objetos puede acceder y utilizar los atributos y operaciones de un objeto dado. Pblico: todos.

Protegido: Slo desde el objeto mismo y operaciones definidas en subclases.


Privado: Slo desde el objeto mismo.
Atributos identificadores. Son atributos o grupos de atributos que identifican unvocamente un objeto de una clase, se
corresponde con el concepto de Clave del modelo E-R.
Atributos Derivados. Son atributos cuyo valor puede obtenerse a partir de los valores de otros atributos.
Relaciones Derivadas. Relaciones transitivas que se derivan de otras relaciones estticas. En el OSM las relaciones
derivadas se representan de la siguiente manera:
Relaciones Ordenadas. Los objetos del extremo "muchos" de una relacin se presentan en forma ordenada. Es
particularmente til para especificar que los objetos componentes de un agregado estn ordenados. Por ordenado,
entendemos que
Prof.: Oscar Nez M.

11

Diseo Orientado a Objetos


los objetos componentes sern accedidos en una secuencia especfica predefinida. En el OSM las relaciones ordenadas se
representan de la siguiente manera:
Atributos y Operaciones de Clase. Definen el comportamiento de la clase misma ms all del comportamiento de sus
instancias. Los atributos de la clase son utilizados para registrar datos comunes a todos los objetos (instancias) de una
misma clase. Las operaciones de clase actan sobre la clase misma como un objeto. El caso tpico son las operaciones
Crear y Destruir.
Modelo de Datos vs Modelo de Objetos
Una BD se desarrolla mediante un Modelo de Datos.
1) Se construye el Modelo de Datos sobre el dominio de la aplicacin.
2) Se transforma del Modelo de Datos en un Diseo de la BD mediante la aplicacin de una serie de transformaciones
estndar (normalizacin).
Un Sistema de Objetos se construye modelando mediante tcnicas diferentes, pues las tcnicas del Modelo de Datos son
bastante limitadas para soportar el Modelo de Objetos.
Consejos prcticos
No comenzar construyendo diagramas de clases; primero, es necesario comprender el problema.
Intentar mantener el Modelo sencillo.
Seleccionar con cuidado los nombres.
No introducir punteros o referencias a otros objetos como atributos.
Intentar evitar asociaciones n-arias.
No intentar establecer el grado de multiplicidad perfecto al principio.
No introducir atributos de enlace dentro de la clase.
Utilizar as ociaciones cualificadas donde sea posible.
Intentar evitar generalizaciones profundamente anidadas.
Intentar asociaciones uno a uno.
No se sorprenda si su modelo requiere una revisin.
Documentar siempre los Modelos de Objetos.
Prof.: Oscar Nez M.

11

Diseo Orientado a Objetos

Modelo de Clases (UML)


Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser
asociativas, de herencia, de uso y de contenimiento.
Un diagrama de clases esta compuesto por los siguientes elementos:
Clase: atributos, mtodos y visibilidad.
Relaciones: Herencia, Composicin, Agregacin, Asociacin y Uso. Elementos:
CLASE
Es la unidad bsica que encapsula toda la informacin de un Objeto (un objeto es una instancia de una clase). A travs de
ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).
En UML, una clase es representada por un rectngulo que posee tres divisiones:
<Nombie Clase :>
<A(ributos>
<0p aciones o Mtodos>

En donde:
o Superior: Contiene el nombre de la Clase
o Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected
o public).
o Inferior: Contiene los mtodos u operaciones, los cuales son la forma como interacta el objeto con su entorno
(dependiendo de la visibilidad: private, protected o public).
Ejemplo:
Una Cuenta Corriente que posee como caracterstica:
o Balance Puede realizar las operaciones de:
o Depositar
o Girar
o y Balance El diseo asociado es:
Cuenta ^balance: nt
*ciepostar(monto : nt): void *grar(monto : int): boolean balanceo : r|t

ATRIBUTOS Y MTODOS:
1. Atributos:
Los atributos o caractersticas de una Clase pueden ser de tres tipos, los que definen el grado de comunicacin y
visibilidad de ellos con el entorno, estos son:
public (+, ^)' Indica que el atributo ser visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos
lados.
private (-, ^Nr/ Indica que el atributo slo ser accesible desde dentro de la clase (slo sus mtodos lo pueden accesar).

protected (#, ^^y. Indica que el atributo no ser accesible desde fuera de la clase, pero si podr ser accesado por
mtodos de la clase adems de las subclases que se deriven (ver herencia).
2. Mtodos:
Prof.: Oscar Nez M.

12

Diseo Orientado a Objetos


Los mtodos u operaciones de una clase son la forma en como sta interacta con su entorno, stos pueden tener las
caractersticas:
public (+, ~): Indica que el mtodo ser visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos
lados.
i: Indica que el mtodo slo ser accesible desde dentro de la clase (slo otros mtodos de la clase lo pueden accesar).
protected (#, v ): Indica que el mtodo no ser accesible desde fuera de la clase, pero si podr ser accesado por mtodos
de la clase adems de mtodos de las subclases que se deriven (ver herencia).
3. Relaciones entre Clases:
Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacionar dos o ms clases (cada uno
con caractersticas y objetivos diferentes).
Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad de las relaciones indica el
grado y nivel de dependencia, se anotan en cada extremo de la relacin y stas pueden ser:
o uno o muchos: 1..* (1..n)
o 0 o muchos: 0..* (0..n)
o nmero fijo: m (m denota el nmero).
HERENCIA (Especializacin/Generalizacin):
Indica que una subclase hereda los mtodos y atributos especificados por una Super Clase, por ende la Subclase adems
de poseer sus propios mtodos y atributos, poseer las caractersticas y atributos visibles de la Super Clase (public y
protected).
Ejemplo:
En la figura se especifica que Auto y Camin heredan de Vehculo, es decir, Auto posee las Caractersticas de Vehculo
(Precio, VelMax, etc) adems posee algo particular que es Descapotable, en cambio Camin tambin hereda las
caractersticas de Vehiculo (Precio, VelMax, etc) pero posee como particularidad propia Acoplado, Tara y Carga.
Cabe destacar que fuera de este entorno, lo nico "visible" es el mtodo Caractersticas aplicable a instancias de Vehculo,
Auto y Camin, pues tiene definicin publica, en cambio atributos como Descapotable no son visibles por ser privado s.

AGREGACIN:
Para modelar objetos complejos, n bastan los tipos de datos bsicos que proveen los lenguajes: enteros, reales y secuencias
de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la
aplicacin, tenemos dos posibilidades:
Por Valor: Es un tipo de relacin esttica, en donde el tiempo de vida del objeto incluido esta condicionado por el
tiempo de vida del que lo incluye. Este tipo de relacin es comunmente llamada Composicin (el Objeto base se contruye
a partir del objeto incluido, es decir, es "parte/todo").

Prof.: Oscar Nez M.

12

Diseo Orientado a Objetos


Por Referencia: Es un tipo de relacin dinmica, en donde el tiempo de vida del objeto incluido es independiente del que
lo incluye. Este tipo de relacin es comnmente llamada Agregacin (el objeto base utiliza al incluido para su
funcionamiento).
Ejemplo:
En donde se destaca que:
Un Almacn posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias).
Cuando se destruye el Objeto Almacn tambin son destruidos los objetos Cuenta asociados, en cambio no son afectados
los objetos Cliente asociados.
La composicin (por Valor) se destaca por un rombo relleno.
La agregacin (por Referencia) se destaca por un rombo transparente.
La flecha en este tipo de relacin indica la navegabilidad del objeto referenciado. Cuando no existe este tipo de
particularidad la flecha se elimina.
ASOCIACIN:
La relacin entre clases conocida como Asociacin, permite asociar objetos que colaboran entre si. Cabe destacar que no
es una relacin fuerte, es decir, el tiempo de vida de un objeto no depende del otro.
Ejemplo:
Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de compra solo puede tener asociado
un
cliente.

DEPENDENCIA O INSTANCIACIN (uso):

---------->
Representa un tipo de relacin muy particular, en la que una clase es instanciada (su instanciacin es dependiente de otro
objeto/clase). Se denota por una flecha punteada.

El uso ms particular de este tipo de relacin es para denotar la dependencia que tiene una clase de otra, como por ejemplo
una aplicacin grafica que instancia una ventana (la creacin del Objeto Ventana esta condicionado a la instanciacin
proveniente desde el objeto Aplicacin):
Aplicacin

.....------>

Ventana

Cabe destacar que el objeto creado (en este caso la Ventana grfica) no se almacena dentro del objeto que lo crea (en este
caso la Aplicacin).
CASOS PARTICULARES:
Clas e Abs tracta:
Empleado

2^
Operario

Gerente

Prof.: Oscar Nez M.

13

Diseo Orientado a Objetos


Una clase abstracta se denota con el nombre de la clase y de los mtodos con letra "itlica". Esto indica que la clase
definida no puede ser instanciada pues posee mtodos abstractos (an no han sido definidos, es decir, sin
implementacin). La nica forma de utilizarla es definiendo subclases, que implementan los mtodos abstractos definidos.
Clas e parametrizada:
KEY, TEM
Diccionario
Definir(key : KEY, item : TEM) Consultar(key : KEY) : TEM

Una clase parametrizada se denota con un subcuadro en el extremo superior de la clase, en donde se especifican los
parmetros que deben ser pasados a la clase para que esta pueda ser instanciada. El ejemplo ms tpico es el caso de un
Diccionario en donde una llave o palabra tiene asociado un significado, pero en este caso las llaves y elementos pueden
ser genricos. La genericidad puede venir dada de un Template (como en el caso de C++) o bien de alguna estructura
predefinida (especializacin a travs de clases).
En el ejemplo no se especificaron los atributos del Diccionario, pues ellos dependern exclusivamente de la
implementacin que se le quiera dar.
Prof.: Oscar Nez M.

13

Diseo Orientado a Objetos

Modelo de Procesos de Negocios (BPM) y Secuencia de Transacciones (TSM) UML: Casos de


Usos (Uses Case)
Los requerimientos para una aplicacin de negocios deben basarse en las actuales actividades del negocio, que la
aplicacin deber soportar.
El Modelo de Procesos de Negocios (BPM) es usado durante el anlisis del negocio (anlisis del sistema actual) y provee
un medio para describir el negocio.
El Modelo de Secuencia de Transacciones (TSM) es usado durante el anlisis de requerimientos del negocio y provee un
medio para describir la funcionalidad requerida de la aplicacin para soportar los procesos de negocios.
El enfoque en los procesos de negocio durante el anlisis del negocio provee el punto de partida para determinar qu se
requiere de la aplicacin. Durante el anlisis de requerimientos decidimos qu parte de los procesos de negocio deben
computarizarse y describimos dichos requerimientos usando una o ms secuencias de transaccin (determinacin de las
fronteras de automatizacin).
Las secuencias de transacciones modelan qu es lo que el usuario requiere de la aplicacin (su contenido funcional);
proveen la navegabilidad desde los requerimientos del usuario a los objetos y operaciones que implementan dicha
funcionalidad; proveen tambin un medio adecuado para comunicarse con el usuario, en un lenguaje y nivel de
abstraccin que l pueda comprender con facilidad.
Como parte del proceso de Diseo Lgico, las secuencias de transacciones son analizadas para identificar como los
objetos y sus operaciones proveen la funcionalidad requerida. Posteriormente, durante el proceso de testeo de la
aplicacin, sirven de base para definir casos de testeos.
Proceso de Negocio (PN).
Un proceso de negocios es una coleccin de actividades que toman uno o ms tipos de entrada y crea una salida de valor
para el cliente.
Un proceso de negocios describe desde el comienzo al fin, la secuencia de eventos requeridos para producir un resultado
de negocio significativo. El cliente puede ser externo o interno a la organizacin.
Los procesos de negocios tpicamente atraviesan los lmites de la organizacin y de sus departamentos internos, evitando
la clsica visin de departamentos estticos (organigrama jerrquico). Por este motivo, cualquier modificacin drstica a
un pro ceso de negocios implica un cambio en la estructura organizacional.
Entradas y/o Eventos
Evento
Proceso de Negocio
Producto
TTT

Salidas Menores
Cmo identificar y definir PN?.
1. Se identifican los productos y/o servicios significativos, de los que es responsable el negocio y se asocia cada uno de
ellos a uno o ms procesos de negocios.

2. Se identifican las entradas y eventos disparadores que inician cada proceso de negocio y se da un nombre a cada PN.
3. Cada PN se describe especificando las actividades de alto nivel que se requieren para producir los productos y/o
servicios.
Secuencia de Transacciones (ST).
El concepto de secuencia de transacciones es muy similar al concepto de "Casos de Uso" (UML), introducido por
Jacobson en su metodologa OOSE y de amplia difusin actualmente.
Una secuencia de transacciones es conceptualmente similar a un proceso de negocios, la diferencia radica en su alcance.
El proceso de negocio se utiliza para comprender y modelar el funcionamiento de la empresa (negocio). Las secuencias de
transacciones se utilizan para modelar los requerimientos funcionales de la aplicacin que soportar determinados
procesos de negocios.
Los procesos de negocio son trasladados en secuencias de transacciones durante el anlisis de requerimientos. El alcance
de una secuencia de transacciones es el mismo de un proceso de negocios o de un subproceso muy significativo. Una
secuencia de transacciones puede implicar ms de un usuario y funcin y puede extenderse en el tiempo, esto es no tener
resolucin inmediata.
Prof.: Oscar Nez M.

14

Diseo Orientado a Objetos


Actores

nombre

Secuencia de Transaccin o Proceso de Negocio.

(^^ombre^^

Evento

C/

Evento

-*Q

CasoUsol

-----

\
Comunicacin entre Actor y ST's.
Borde del Sistema

-
1

Descripcin Textual.
1. Abs tracto. Breve descripcin del proceso de negocios o secuencia de transacciones.
2. Contexto del Negocio. Especifica:
a) el resultado de la ST o PN (productos y/o servicios)
b) el cliente de la ST o PN
c) el valor que gana el cliente con la ST o PN
d) el evento que inicia la ST o PN
e) entradas requeridas por la ST o PN
f) descripcin de alto nivel de la ST o PN
g) requerimientos especiales que controlan la ejecucin de la ST o PN 2) Camino estndar y alternativo.
El camino estndar es una descripcin secuencial de todas las actividades que deben realizarse para alcanzar el resultado.
Par una ST describe las actividades de los actores y que debe hacer la aplicacin en orden de servir dichas actividades.
Para un PN describe las actividades de alto nivel del proceso y quin las realiza
Prof.: Oscar Nez M.

14

El proceso de identificar requerimientos del usuario y secuencias de transacciones puede asistirse con la prototipacin de
interfaces.
Cmo identificar y definir ST?
1. Identificacin a travs de actores.
Identificar los actores que se comunicarn con el sistema, luego para cada actor considerar:
a) Cules son las principales tareas del actor?
b) Qu accesos (lectura o escritura) requiere el actor del sistema?
c) Cundo el actor informar al sistema acerca de cambios fuera del sistema?
d) Cundo el actor ser informado de cambios a travs del sistema?
2. Identificacin a travs de eventos.
Consiste en identificar a qu eventos externos o temporales, debe ser capaz de responder el sistema, para ello:
a) Confeccionar la lista de eventos
b) Asociar una secuencia de transacciones para cada evento identificado
Componentes y Herramientas de Modelado de Procesos de Negocios y Secuencias de Transacciones.
Para modelar y documentar procesos de negocios y secuencias de transacciones se utilizan los mismos diagramas y
documentos, los cuales son:
1) Diagrama de Secuencia de Transacciones (TSD)
Diseo Orientado a Objetos
Los caminos alternativos se describen separadamente pero pertenecen a la misma ST o PN. Describen casos inusuales de
procesamiento y manejos de excepciones o errores. Esta separacin se realiza para facilitar el modelado y lectura de los
caminos estndar.
Para modelar y diagramar los caminos estndar y alternativos, respectivamente, se utilizan los Diagramas de Interaccin
de Objetos (OID) y los Diagramas de Flujo de Actividad (AFD).
3) Actores.

En el BPM representan los profesionales del negocio y sistemas de computacin involucrados en producir un producto o s
ervicio.
En el TSM representan agentes externos que interactan con la aplicacin. Pueden representar usuarios humanos o
interfaces con otros sistemas.
Cada actor es usado para modelar un rol, el cual puede ser desempeado por un usuario individual o grupo de usuarios.
4) Observacin.
Subdivis in de procesos de negocios.
Los PN pueden ser subdivididos en subprocesos. Las dos formas principales para realizar esto son:
Especializacin. Es la especializacin del PN en distintos tipos que producen el mismo resultado pero tienen diferentes
conjuntos de actividades.
Particionamiento. Es el particionamiento del PN a lo largo del eje de tiempo en una secuencia de subprocesos.

Casos de Uso (Use Case)


El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, adems de
la forma, tipo y orden en como los elementos interactuan (operaciones o casos de uso).
Un diagrama de casos de uso consta de los siguientes elementos:
Actor.
Casos de Uso.
Relaciones de Uso, Herencia y Comunicacin. Elementos
ACTOR:
Una definicin previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el
uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular,
sino ms bien la labor que realiza frente al sistema.
Como ejemplo a la definicin anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al
sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.
CASO DE USO:
Es una operacin/tarea especfica que se realiza tras una orden de algn agente externo, sea desde una peticin de un actor
o bien desde la invocacin desde otro caso de uso.
RELACIONES:
As ociacin

>

Es el tipo de relacin ms bsica que indica la invocacin desde un actor o caso de uso a otra operacin (caso de uso).
Dicha relacin se denota con una flecha simple.
Prof.: Oscar Nez M.

15

Diseo Orientado a Objetos


Dependencia o Ins tanciacin

.........->
Es una forma muy particular de relacin entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea).
Dicha relacin se denota con una flecha punteada.
Generalizacin
Este tipo de relacin es uno de los ms utilizados, cumple una doble funcin dependiendo de su estereotipo, que puede ser
de Uso (<<uses>>) o de Herencia (<<extends>>).
Este tipo de relacin esta orientado exclusivamente para casos de uso (y no para actores).
Extends
Se recomienda utilizar cuando un caso de uso es similar a otro (caractersticas).
Us es
Se recomienda utilizar cuando se tiene un conjunto de caractersticas que son similares en ms de un caso de uso y no se
desea mantener copiada la descripcin de la caracterstica.
De lo anterior cabe mencionar que tiene el mismo paradigma en diseo y modelamiento de clases, en donde esta la duda
clsica de usar o heredar.
Prof.: Oscar Nez M.

15

Diseo Orientado a Objetos

Modelo de Interaccin de Objetos.


El modelo de interaccin de objetos modela la manera en que colaboran los objetos de un sistema para proveer la
funcionalidad descrita en una secuencia de transacciones. Su utilidad primaria se da durante la etapa de diseo lgico.
La Interaccin de Objetos se produce cuando un objeto enva un mensaje a otro con el objetivo de utilizar o requerir la
funcionalidad de la operacin invocada de parte del receptor del mensaje.
El modelo de interaccin de objetos provee el enlace entre las descripciones de las secuencias de transacciones y las
especificaciones de operaciones elementales a nivel de objetos.
Asisten en la identificacin de clases de objetos y operaciones requeridas, considerando como una determinada
funcionalidad debe distribuirse en operaciones de diferentes clases de objetos (responsabilidades de objetos), y como los
objetos deben colaborar para proveer la funcionalidad descrita en las secuencias de transacciones.
La herramienta de modelado fundamental para el modelo de interaccin de objetos es el diagrama de interaccin de
objetos (OID). Normalmente se usa un OID para cada secuencia de transacciones concentrndose en el camino estndar.
Utilizacin del modelado de interaccin de objetos.
Modelado de procesos de negocios: es una tcnica adicional que puede utilizarse para comprender un proceso de
negocios en particular. Se considera al sistema como una "caja negra" y se lo representa como actor (interfaz de mquina).
Anlisis de requerimientos: no es muy utilizado ya que el propsito de esta etapa es definir requerimientos, no disear.
Diseo lgico: se utiliza un OID para cada secuencia de transacciones definida en el anlisis de requerimientos, para
determinar con claridad que clases, operaciones y responsabilidades se necesitan. Se mira dentro de la caja negra (tal

como se la ve en el modelo de proceso de negocio) y se determina que objetos participan para implementar la
funcionalidad requerida del sistema.
Diagrama de interaccin de objetos (OID) para un proceso de negocios (PN).
Actor 1
Actor 2 Actor 3 Sistem a 1
Evento 1

-H
Evento 5

HHEvento 2

-H
Evento 4
Evento 3

-H
Elementos:
1. Actores en la parte superior del diagrama. Pueden ser humanos o sistemas vistos como cajas negras
2. Una lnea vertical asociada a cada actor
3. Requerimientos o eventos enviados por un actor a otro. Se representan por flechas. Se utiliza una sola flecha para
representar el estmulo y la respuesta implcita.
4. Etiquetas en el margen izquierdo representando links a actividades de un diagrama de flujo de actividades.
1
2

Prof.: Oscar Nez M.

16

Diseo Orientado a Objetos


Diagrama de interaccin de objetos (OID) para una secuencia de transacciones (ST).
| Obj.1 | Obj.2 || Obj.3
Obj.4
Obj.5
Descripcin narrativa de la ST.

-H
K-H
H-H
-H
-H
2
3

Elementos:
1. Barra vertical a la izquierda representa el lmite del sistema.
2. Se acompaa con la descripcin narrativa de la secuencia de transacciones a la izquierda de esta.
3. Una flecha proveniente desde el lmite representa un requerimiento externo generado por un actor. Es conveniente que
los requerimientos/respuestas de este tipo se representen por flechas individuales.
4. Operaciones: se representan por rectngulos alargados sobre los ejes correspondientes a los objetos que las realizan.
Permite visualizar que mensajes dispara una operacin. La longitud de la barra no representa duracin.
5. Actividades: bloques de eventos que siempre ocurren en una determinada secuencia. Dichas actividades que pueden
ocurrir en paralelo, condicional o iterativamente, pueden modelarse con un diagrama de flujo de actividad asociado.
Cas os es peciales .
1. Invocacin de operaciones "in-self". A menudo una operacin de un objeto invoca a otra operacin de la misma clase.
Esto puede representarse de la siguiente forma:

-H

J
2. Mltiples objetos de una misma clase. Se representa la clase ms de una vez.
Prof.: Oscar Nez M.

16

Diseo Orientado a Objetos


3. Secuencias comunes.
Usualmente se dibujan diagramas por separado para las secuencias comunes y su invocacin se representa con una flecha
punteada.

-H
---

Diagrama de Interaccin.
El diagrama de interaccin, representa la forma en como un Cliente (Actor) u Objetos (Clases) se comunican entre si en
peticin a un evento. Esto implica recorrer toda la secuencia de llamadas, de donde se obtienen las responsabilidades
claramente.
Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama Esttico de Clases o el de Casos de Uso (son
diferentes).
Los componentes de un digrama de interaccin son:

Un Objeto o Actor.
Mensaje de un objeto a otro objeto.
Mens aje de un objeto a si mismo.
Elementos
OBJETO/ACTOR:
El rectngulo representa una instancia de un Objeto en particular, y la lnea punteada representa las llamadas a mtodos
del objeto.
MENSAJE A OTRO OBJETO:
Se representa por una flecha entre un objeto y otro, representa la llamada de un mtodo (operacin) de un objeto en
particular.
MENSAJE AL MISMO OBJETO:
No solo llamadas a mtodos de objetos externos pueden realizarse, tambin es posible visualizar llamadas a mtodos
desde el mismo objeto en estudio.
Prof.: Oscar Nez M.

17

Diseo Orientado a Objetos

Diagrama de Flujo de Actividad ( A I D )


Los OID no muestran decisiones, interacciones, o la posibilidad de que partes del procesamiento puedan realizarse en
secuencias aleatorias o concurrentemente. Una manera de describir esto es con descripciones textuales en el margen
izquierdo del OID, o utilizando diagramas de flujo de actividad (AFD). Los AFD son un tipo particular de los clsicos
"flowcharts".
Actividad: es una secuencia de interacciones entre objetos.
El alcance de una actividad queda normalmente definido por el hecho de que una secuencia de interacciones dada es
condicional, iterativa, o puede ocurrir antes o despus de otras secuencias de interacciones.
Simbologa de los AFD.
Actividad.
Flujo entre una actividad y la siguiente. Inicio
Terminacin.
Decisin: divisin del flujo de actividades segn la condicin.
Sincronizacin.

7
Obs ervacin.
Un AFD puede incluir actividades que no estn en un camino estndar pero que aparezcan en un camino alternativo.
Pueden existir actividades sin interacciones asociadas que se utilizan para clarificar la lgica del flujo.
Puede utilizarse un AFD sin OID asociado simplemente para describir la lgica del flujo en un camino
estndar/alternativo.
Generalmente, un OID es utilizado para modelar cada secuencia de transacciones. Es posible ms de un OID por
secuencia de transacciones y se describen a continuacin dos enfoques alternativos.
o Usando AFD para modelar operaciones.
Los AFD pueden ser utilizados en combinacin con los OID. En un AFD cada bloque normalmente representa un grupo
de eventos que ocurren siempre en la misma secuencia. Otra opcin es mostrar un bloque en un AFD para representar
cada posible estmulo externo para una secuencia de transacciones. Tal estmulo externo (u operacin del sistema) puede
ocurrir a menudo en secuencias aleatorias o en secuencias alternativas. Un OID puede desarrollarse para cada uno de tales
bloques u operaciones del sistema.
Sin embargo, se recomienda utilizar un OID simple para toda la secuencia de transacciones siempre que sea posible,
debido a que esto brinda una visin general para todo el proceso requerido.
o OID's, ST's y Escenarios.
Generalmente se desarrolla un solo OID por cada secuencia de transacciones. Este diagrama muestra un caso general
omitiendo caminos alternativos inusuales. No muestra un escenario de ejecucin que pueda ocurrir en una ocasin
especfica. En casos complicados, puede ser til desarrollar OID's alternativos representando los caminos alternativos.
Prof.: Oscar Nez M.

17

Diseo Orientado a Objetos

Modelo de Ciclo de Vida de Desarrollo de Objetos


Conceptos y propsito del modelo de ciclo de vida de objetos.
El modelo de ciclo de vida de objetos se utiliza para describir los aspectos dinmicos de los objetos. Modela lo que ocurre
dentro de los objetos de una clase: estados, cambios de estado, y eventos que producen dichos cambios de estado.
El estado de un objeto de una clase est dado por el conjunto de valores de sus atributos en un instante dado de tiempo.
Durante su ciclo de vida, desde que son creados hasta que son destruidos, los objetos atraviesan por diferentes estados. La
importancia de estudiar el ciclo de vida de los objetos y de sus estados, se debe a que muchos objetos exhiben
comportamiento s estado-dependientes.
Es especialmente importante reconocer comportamientos de objetos que son dependientes del tiempo y del estado previo,
ya que pueden agregar una complejidad considerable a la aplicacin. Ciertas operaciones y/o atributos pueden ser vlidos
slo en ciertos estados. Slo deben modelarse los estados de un objeto que son relevantes al dominio del problema que se
est modelando.

Las transiciones de estados de un objeto son causadas por la recepcin de un evento interno o externo al sistema. El estado
que asume un objeto luego de recibir un evento depende del estado actual, del evento recibido, y opcionalmente del valor
de una condicin de guarda. Cuando un objeto recibe un evento ejecuta una accin (que corresponde con una operacin)
asociada con un a transicin. Al fin o durante la ejecucin de dicha accin, el objeto produce el cambio de estado. Puede d
arse que el estado final sea el mismo que el inicial.
Utilizacin del modelo de ciclo de vida de objetos.
Siempre que se agrega una nueva clase al OSM es importante examinar si se presentan estados significativos para los
objetos de la misma. Si es asi puede utilizarse el modelo de ciclo de vida en orden de comprender correctamente el ciclo
de vida de dichos objetos. El modelo de ciclo de vida es til en las etapas de anlisis del negocio y de requerimientos, para
obtener una clara comprensin de los objetos claves descubiertas y de los caminos estndar y alternativos involucrados.
Herramientas de modelado. Diagrama de ciclo de vida de objetos.
La herramienta que se utiliza para modelar el ciclo de vida de objetos es el diagrama de ciclo de vida de objetos (OLD).
Un OLD se aplica slo a una clase de objetos.
El OLD representa:
Cmo los objetos son creados.
Cmo los objetos son destruidos.
Cmo los objetos cambian a travs del tiempo.
Qu estados tpicamente asume un objeto.
Qu eventos causan cambios de estado.
Qu acciones realiza un objeto cuando recibe un evento que produce un cambio de estado.
Componentes del OLD.
Punto de entrada. Instante previo a la creacin de un objeto. Punto de salida. Momento en el que deja de existir un objeto.
Estado. Conjunto de valores de los atributos de un objeto en un instante de tiempo.
Transicin o cambio de estado.
IEvento [condicin de guarda! Accin
Prof.: Oscar Nez M.

18

Diseo Orientado a Objetos

Modelo Global del Sistema


Conceptos y propsito del modelo del modelo global del sistema.
El modelo global del sistema posibilita tener una visin general del modelo de estructura de objetos del sistema, asistiendo
en el manejo de la complejidad.
Las principales razones para utilizar un modelo global del sistema son:
Posibilita el particionamiento de una tarea de anlisis o desarrollo. Para grandes sistemas, subsistemas pueden ser
asignados a diferentes equipos o subproyectos.
Puede utilizarse para definir unidades de entrega, PE: unidades funcionales (mdulos) que deban entregarse al usuario en
sucesivas fechas de liberacin, o componentes de producto.
Puede utilizarse para definir unidades distribubles.
Puede utilizarse para validar el diseo de un sistema y asegurar que est bien diseado para soportar el cambio.
Incluye un diagrama (el diagrama de visin general del sistema) que puede utilizarse para producir una visin general de
un modelo del anlisis o de un subsistema, asistiendo con la presentacin de un modelo o subsistema a un nivel de visin
general.
Una caracterstica importante del modelo global es que permite el modelado de interfaces entre subsistemas. Esto se logra
modelando los servicios que un subsistema ofrece para ser utilizados por otro subsistema.
Conceptos
El modelo global implica la subdivisin del espacio de problema en componentes. En un enfoque de desarrollo orientado
a objetos, esto se alcanza agrupando clases de objetos. El modelado orientado a objetos difiere aqu de las tcnicas
estructuradas, en que en estas, los subsistemas usualmente agrupan funciones, no objetos.
Las secuencias de transacciones no necesariamente residen en un nico subsistema. Pueden requerir el soporte de objetos
pertenecientes a ms de un subsistema o componente.
El espacio del problema y sus componentes.
Durante la etapa de anlisis del negocio, el espacio del problema es el dominio del negocio, y podemos optar por dividir
dicho dominio en reas sujetos. Cada rea sujeto contiene clases de objetos semnticamente relacionadas unas a otras,
vinculadas con el mismo sujeto.
Durante el desarrollo, el espacio del problema es el sistema o subsistema que se construye. Esto tambin puede ser
subdividido en submodelos o subsistemas. Los submodelos son utilizados principalmente con propsitos de presentacin.
Los subsistemas son definidos por razones tcnicas como ser: definicin de unidades de distribucin, y definicin de
mdulos, importante para validar y preservar la mantenibilidad del sistema.
Otro uso del particionamiento es la subdivisin arquitectural, la cual es particularmente importante durante el diseo
fsico. Se recomienda la divisin de todo sistema en seis subsistemas arquitecturales:
El componente dominio de problema: es el ms importante y en el cual nos concentramos durante el anlisis de
requerimientos y el diseo lgico.
El componente de Interfaz humana: introducido en el diseo lgico.
El componente de interfaz externa: introducido durante el diseo lgico.
El componente de administracin de datos: introducido durante el diseo fsico.
El componente de administracin de tareas: introducido durante el diseo fsico.
El componente de servicio de utilidades: introducido durante el diseo fsico.
Prof.: Oscar Nez M.

18

Diseo Orientado a Objetos


Definicin del alcance de un subsistema

Bsicamente, las clases de objetos que tienen un alto grado de interdependencia y sirven a un propsito comn, deben
asignarse al mismo subsistema. Usualmente, jerarquas de herencia y agregacin, deben ser asignadas completamente a un
subsistema.
Debe notarse que si existen objetos que son requeridos por diferentes subsistemas, entonces dichos objetos no deben
asignarse a un subsistema.
Servicios
Un subsistema provee sus servicios va una interface, la cual es un conjunto de operaciones que los clientes de un
subsistema pueden utilizar. Son tiles estas operaciones en servicios. Cada servicio agrupa operaciones relacionadas que
tienen un propsito comn.
Los servicios provistos por un subsistema a otro, o a actores, pueden identificarse determinando que comunicaciones son
posibles entre subsistemas, y agrupar estas en servicios. Es conveniente que esto se realice durante ci diseo lgico,
cuando las operaciones han sido definidas.
Los subsistemas pueden vincularse en relaciones cliente-servidor o partner to partner (compaero a compaero). En este
ltimo caso, un subsistema puede ser cliente y servidor a la vez.
Particiones verticales y horizontales
Un sistema puede ser particionado horizontalmente (en capas) o verticalmente. Las particiones verticales son usadas para
subdividir la funcionalidad de la aplicacin, mientras que las particiones horizontales son particularmente tiles para aislar
las aplicaciones de capas de software de menor nivel como ser sistemas operativos, bases de datos o hardware. Este
enfoque por capas (layers) asegura la portabilidad de una aplicacin.
En el siguiente ejemplo el dominio de problema se divide en cuatro particiones verticales. El componente de
administracin de datos es una particin horizontal, la cual existe para aislar a la aplicacin del software de base de datos
utilizada.
Subsistema de
Subsistema de
Subsistema de
Subsistema de
reportes
seminario
registracin
memos
Componente de Administracin de Datos
Prof.: Oscar Nez M.

19

Diseo Orientado a Objetos


Diagrama de Modelo Global del Sistema Componentes del diagrama
Actor: personas que interactan con el subsistema o interfaces con otros subsistemas.

O
Bordes del sistema: se representan con un rectngulo en lnea gruesa. Los actores se dibujan fuera del rectngulo, y los s
ubs is temas dentro.
nombre

Subsistema: se representan con un rectngulo redondeado.


Servicios: se representan como semicrculos dentro del rectngulo correspondiente al subsistema.
Actor usando un servicio: se representa como una flecha que vincula al actor con el servicio que usa. Obs.
Uso de Clases de Objetos para encapsular subsistemas.
Es posible encapsular la funcionalidad de un sistema utilizando object wrapper (envoltura). Esto puede ser muy til para
permitir la utilizacin de un sistema no orientado a objetos desde un sistema orientado a objetos. Esto se realiza
definiendo un objeto interface el cual puede llamarse para invocar las funciones provistas por el sistema encapsulado. Solo
dicho objeto interface necesita conocer el funcionamiento interno del sistema que encapsula.
Tambin es posible utilizar una clase de objetos para encapsular el acceso a un sistema orientado a objetos. Si no se utiliza
esto, todos los mensajes provenientes del exterior del subsistema, deben dirigirse directamente a la clase de objetos
correspondiente dentro del mismo, lo que implica que los actores que necesiten utilizar la funcionalidad del subsistema,
deban conocer la estructura interna del mismo.
Utilizando un objeto interfaz, se oculta la complejidad interna del subsistema y es posible definir una interfaz sencilla para
los clientes externos.
Prof.: Oscar Nez M.

19

Diseo Orientado a Objetos

Ciclo de Desarrollo Orientado a Objetos


En los captulos anteriores se introdujeron los conceptos fundamentales del paradigma de orientacin a objetos, como as
tambin los modelos fundamentales que se utilizarn en la metodologa de OOAD.
Se examinar el proceso de desarrollo orientado a objetos, es decir que actividades deben llevarse a cabo, que tareas deben
realizarse, y que deben producirse en cada etapa.
En esta unidad se realiza una presentacin a nivel general que se desarrolla en detalle en las unidades siguientes.
Fases del ciclo de desarrollo OO.
En este enfoque un ciclo de vida tradicional est compuesto por las siguientes etapas:
1. Definicin del proyecto y planificacin.
Aqu es donde se define el alcance y lmites del proyecto. Se realizan los estudios de factibilidad y se determinan las
relaciones costo/beneficio.
2. Anlisis
Anlisis del Negocio: aqu es donde se modela el negocio o parte del mismo en orden de comprender la naturaleza del
mismo, como se realizan actualmente las actividades, y como los usuarios desean que se realicen en el futuro. Provee una
comprensin preliminar de reas especficas del negocio a ser informatizadas. Esta etapa tambin es conocida como
estudio del sistema actual en otras metodologas.
Anlisis de requerimientos del sistema: aqu es donde se establece con claridad las capacidades requeridas para el
nuevo sistema a ser desarrollado. Estas capacidades son documentadas de modo tal que los desarrolladores tengan una
especificacin clara sobre la que trabajar y para validar los resultados obtenidos.
3. Diseo

Diseo Lgico: aqu es donde los desarrolladores del sistema identifican los componentes de software y hardware
necesarios para satisfacer los requerimientos, como as tambin especifican las relaciones arquitecturales entre dichos
componentes. El diseo lgico debe evitar detalles tcnicos especficos requeridos para mapear el diseo en un entorno de
implementacin especfico.
Diseo Fsico: aqu es donde se toman decisiones tcnicas considerando arquitecturas de hardware especificas, sistemas
de bases de datos, lenguajes de programacin, utilizacin de paquetes de middleware o herramientas Case, etc. Aqu
tambin se toman decisiones con respecto a caractersticas de implementacin como ser arquitectura cliente/servidor,
distribucin de objetos, etc.
4. Construccin
Desarrollo: aqu es donde un diseo fsico es implementado en un lenguaje de programacin, o entorno especifico de
desarrollo.
Prueba: se realizan test del software para validar su correcto funcionamiento y detectar fallas que deban ser depuradas.
Documentacin: desarrollo de: documentacin tcnica sobre la aplicacin, manuales de usuario, manuales de
procedimiento, etc.
5. Aprobacin (Implantacin)
6. Operacin y Mantenimiento
Prof.: Oscar Nez M.

20

Diseo Orientado a Objetos


Uso de los distintos modelos.
A continuacin se resume el uso de los distintos modelos en las diferentes etapas del ciclo de desarrollo: Anlisis del
Negocio
Modelo de Estructura de Objetos: es utilizado para identificar y modelar los objetos del dominio del negocio (objetos
entidad). Preguntas fundamentales son: "Qu objetos necesitamos en orden de realizar los procesos de negocio
identificados?", "Qu deben conocer estos objetos, y que deben ser capaces de realizar?", "Cmo interactan estos
objetos entre s?'.
Modelo de procesos de negocios y secuencias de transacciones: pueden utilizarse para describir los procesos del
negocio en una forma compatible con la descripcin de secuencias de transacciones de la siguiente fase de anlisis de
requerimientos.
Modelo de Ciclo de Vida de Objetos: pueden proveer una mayor comprensin sobre el comportamiento dinmico de
los objetos del negocio, durante su vida. Su utilizacin depender de la complejidad de los objetos del negocio en estudio,
y en algunos casos puede ser Innecesaria su utilizacin.
Anlisis de Requerimientos
Modelo de estructura de Objetos: contiene nicamente objetos entidad, y se agrega mayor detalle al modelo
describiendo relaciones, herencia, agregacin, atributos y restricciones aplicables a las clases de objeto entidad,
identificados.
Secuencias de Transaccin: son utilizadas para describir la funcionalidad esperada del sistema.
Modelo de Ciclo de Vida de Objetos: se utiliza para aquellos objetos con ciclos de vida complejos.
Modelo Global del Sistema: es utilizado para sistemas grandes cuando se necesite particionar en subsistemas.
Diseo Lgico
Secuencias de Transacciones: definidas en la etapa anterior, son examinadas aqu para determinar objetos interfaz y de
control donde es apropiado.
Diagramas de Interaccin de Objetos: se dibuja uno por cada secuencia de transaccin describiendo eventos e
interacciones entre objetos necesarios para soportar la secuencia de transaccin.
Operaciones: son definidas con descripciones informales de su comportamiento.
Diagramas de Ciclo de Vida: son creados y extendidos donde sean necesarios.
Modelo Global: se definen subsistemas y se dibujan diagramas globales donde sea requerido con propsitos
organizacionales, manejo de complejidad, y presentacin.
Diseo Fsico
Durante la etapa de diseo fsico se llevan a cabo las siguientes actividades:
El entorno para el sistema debe ser determinado, y las decisiones tomadas inicialmente deben finalizarse. Esto incluye
determinacin de lenguaje de programacin, sistema operativo, DBMS, S.O. de red, hardware, tipo de interface de
usuario, libreras de clases, frameworks, y patrones de diseo.
La administracin de tareas y distribucin de objetos/funciones debe finalizarse.
La definicin de tipos de atributos debe finalizarse.
Se implementan las relaciones (p.e. en forma de punteros)
Decisiones relativas a implementacin de restricciones debe finalizar, dependiendo del lenguaje de programacin,
DBMS utilizados, etc.
Debe finalizarse la interfaz de usuario.
Deben tomarse decisiones sobre el manejo de persistencia de objetos, involucrando posiblemente un mapeo entre objetos
y DBMS relacionales. Esto puede implicar la implementacin de una "capa de acceso" en el sistema, o bien puede
manejarse con un producto comercial.
Se desarrollan objects wrappers para todos los componentes no orientados a objetos que sern utilizados por la
aplicacin.
Se realiza la codificacin de todas las operaciones que deban realizarse.
El rol de las versiones en un proceso de desarrollo aditivo
El proceso de OOAD descripto aqu es aditivo, esto significa que los resultados de cada fase son utilizados como entrada
para la siguiente fase, donde se realizan actualizaciones y extensiones. Esto contrasta con otros enfoques como el
estructurado que es carcter transformacional, donde los DFD del anlisis son transformados en Diagramas de Estructura
durante el diseo.
Debido a esta naturaleza aditiva del proceso, es tcnicamente innecesario retener versiones de resultados de las primeras
fases del desarrollo. Sin embargo muchas veces por cuestiones contractuales u organizacionales se retienen copias de los
modelos del anlisis de requerimientos. A menudo, este modelo representa un contrato entre los usuarios y los
desarrolladores. El modelo se retiene en orden de proveer un mecanismo para validar que el sistema entregado cumple con
las especificaciones iniciales.

Arquitectura de Seis Componentes


Como se ha mencionado, es til y comn dividir sistemas grandes y complejos en subsistemas para facilitar su desarrollo.
Pero adems es til dividir un sistema de cualquier tamao en subsistemas basados en consideraciones arquitecturales que
son especficamente relevantes durante la fase de diseo fsico de la aplicacin.
Componente Dominio de Problema (PDC)
Componente de Interaccin Humana (HIC)
Componente de Interfaces Externas (EIC)
Componente de Administracin de Datos (DMC)
Componente de Administracin de Tareas (TMC)
Componente de Servicio de Utilidades (USC)

Anlisis del Negocio.


El anlisis del negocio es utilizado para modelar parte o toda la empresa, en orden de comprender la naturaleza del
negocio y como se llevan a cabo sus procesos.
El anlisis del negocio se concentra en dos aspectos:
Modelado de los Objetos que soportan el Negocio (Business Objects)
Modelado de los Procesos del Negocio (Business Processes)
Actividades del Anlisis del Negocio.
Las siguientes actividades son llevadas a cabo durante el anlisis del negocio:
Identificacin de los Objetos del Negocio. Son los objetos ms importantes del tipo entidad. Otros objetos entidad
adicionales son agregados durante el anlisis de requerimientos y durante el diseo lgico.
Modelado del ciclo de vida para cada objeto del negocio que tenga un ciclo de vida complejo relevante al problema a
manejar.
Modelado de los procesos de negocio. Implica la identificacin de los procesos de negocio y la obtencin de una
comprensin de alto nivel de los flujos de trabajo (workflows: secuencias de actividades y eventos) de dichos procesos, y
de los agentes (humanos o mquinas) que interactan para alcanzar un resultado significativo.
Chequeo de consistencia y validacin del modelo producido.
El alcance del anlisis del negocio (dominio del negocio o dominio del problema) normalmente se determina durante la
fase de definicin del proyecto.
1. Modelado de Objetos del Negocio.
El modelado de objetos del negocio es la primera definicin del modelo de estructura de objetos para la aplicacin. El
modelado de objetos puede realizarse en simultneo con el modelado de procesos de negocios. Sin embargo, se
recomienda comenzar modelando los objetos ya que son la escencia de este enfoque.
El modelo de estructura de objetos producido en esta fase ser extendido en fases subsiguientes. Sin embargo, es muy
similar al de la fase de anlisis de requerimientos.
Las principales diferencias residen en:
1. El alcance de los objetos del negocio suele ser mayor, pues puede involucrar objetos de negocio que no son relevante al
sistema computarizado.
2. El modelo de objetos del negocio suele ser menos detallado. Usualmente slo objetos de la realidad son modelados.
Durante el anlisis de requerimientos, objetos menos obvios son identificados (p.e. clases que representan eventos).
3. En el anlisis del negocio, el modelo contiene los objetos del negocio, sus principales atributos y relaciones estticas
relevantes. Durante el anlisis de requerimientos, pueden agregarse objetos entidad, adicionales, con un conjunto de
atributos ms detallado y las operaciones bsicas para los objetos del modelo.
4. La definicin de jerarquas de herencia y estructuras de agregacin se difieren hasta el anlisis de requerimientos.
Pas os en el modelado de objetos de negocio.
1. El modelado de objetos de negocio incluye los siguientes pasos:
2. Determinar objetos del negocio candidatos.
Prof.: Oscar Nez M.

21

Diseo Orientado a Objetos


3. Abstraer los objetos candidatos en clases y definir el propsito de cada clase de objetos.
4. Determinar las relaciones estticas entre los objetos del negocio.
5. Nominar dichas relaciones y asignar cardinalidades.
Qu modelar?
Los objetos pueden ser identificados respondiendo la pregunta "qu cosas (reales o abstractas) considera la empresa y
sobre la que guarda datos?". El nfasis en esta etapa es identificar objetos de la realidad (personas, lugares, cosas o
eventos que estn dentro del dominio.
2. Modelado de Ciclo de Vida de Objetos.
El principal propsito del modelado de ciclo de vida de objetos es asistir en la comprensin de objetos con ciclos de vida
complejos.
Es importante reconocer cualquier comportamiento del objeto que sea dependiente del tiempo y del estado del mismo, ya
que esto agrega complejidad a la aplicacin.
El uso de diagramas de ciclo de vida facilita la comprensin y comunicacin con los usuarios.
Cundo modelar ciclos de vida?
Debe dibujarse diagramas de ciclo de vida solo para objetos que poseen comportamientos dependientes del tiempo y de su
estado interno. Para determinar esto, debe tomarse cada clase de objetos y analizarla por separado. Deben identificarse los
eventos que pueden afectar a un objeto de la clase y determinar si la reaccin a dichos eventos puede variar segn el
estado interno del objeto.
Cmo modelar ciclos de vida de objetos?
El modelado de ciclos de vida incluye los siguientes pasos:
Determinar cuando debe modelarse el ciclo de vida para una clase de objetos, segn lo expuesto anteriormente.
1. Identificar el primer estado del objeto.
2. Identificar que evento lleva a un objeto a su estado inicial (usualmente la creacin del mismo).
3. Identificar los eventos que pueden causar transiciones de estado desde el primer estado, y a que estados puede cambiar
el objeto.

4. Identificar que actividades se llevan acabo durante la transicin de estado.


5. Identificar el estado final del objeto.
Bsicamente el alcance del modelado de ciclo de vida de objetos es el mismo para la actividad de anlisis del negocio
como para el anlisis de requerimientos.
3. Modelado de Procesos de Negocio.
El modelado de procesos de negocio es usado para comprender y documentar las actividades de alto nivel realizadas por
los profesionales del negocio para alcanzar los objetivos del dominio del negocio.
Esta comprensin de alto nivel de cmo trabaja la empresa es necesaria como un paso preliminar para asegurar que las
partes del negocio afectadas por la aplicacin en desarrollo es comprendida antes de que el anlisis de requerimientos sea
llevada a cabo.
Pas os del modelado de Proces os de Negocio.
1. Identificar los procesos de negocio.
2. Subdivisin de los procesos de negocio. Los procesos de negocio pueden subdividirse identificando
especializaciones o particionndolos a lo largo del tiempo en subprocesos.
3. Descripcin de los procesos de negocio. La descripcin de un proceso de negocio implica la descripcin de la
naturaleza del mismo como de las actividades que lo constituyen.
Identificacin de procesos de negocio.
Los procesos de negocio pueden identificarse de dos maneras:
Considerar quin es el cliente, y qu productos o servicios requiere. Verificar que dichos productos/servicios sean de valor
para el cliente. La produccin de dichos productos/servicios implicar uno o ms procesos de negocio.
Considerar que eventos la empresa debe ser capaz de tratar, y que procesos implican el tratamiento de dichos eventos.
Cmo describir procesos de negocio?
Los siguientes mecanismos pueden utilizarse para describir procesos de negocio:
1. Una identificacin del evento inicial y del producto(s) o servicio(s) del proceso de negocios.
Prof.: Oscar Nez M.

22

Diseo Orientado a Objetos


2. Una descripcin textual de las actividades involucradas en el proceso de negocio.
3. Una descripcin de la secuencia de interacciones entre agentes (humanos o mquinas) que es requerida para producir el
producto/servicio requerido. Para esta descripcin pueden utilizarse diagramas de interaccin de objetos.
4. Una descripcin de los cambios de ejecucin de los caminos de ejecucin involucrados en el proceso, mostrando los
puntos en los cuales se inician dichos caminos: alternativos, actividades paralelas, e iteraciones. Para esta se pueden
utilizar diagramas de flujo de actividad (AFD).

Anlisis de Requerimientos.
El proceso de anlisis de requerimientos debe producir una definicin clara de los requerimientos para el nuevo sistema
desde la cual puedan trabajar los desarrolladores y contra la cual puedan validarse los resultados.
Durante el anlisis del negocio se producen un modelo de la forma en que actualmente funciona la empresa. Durante el
anlisis de requerimientos, se modela cmo la empresa operar utilizando el nuevo sistema.
Un objetivo adicional del anlisis de requerimientos es proveer a los profesionales del negocio de la oportunidad de
cambiar la manera en que actualmente funciona la empresa.
El punto de partida del anlisis de requerimientos depende del contexto en el cual una aplicacin es desarrollada. Cuando
el dominio del negocio para la aplicacin es pequeo y bien comprendido, entonces la fase de anlisis del negocio es muy
breve. El anlisis de requerimientos parte de los modelos del anlisis del negocio que contienen muy poco detalle. En este
caso es casi como partir desde cero.
Cuando se ha realizado un anlisis del negocio extenso, entonces los modelos obtenidos constituyen la base sobre la cual,
se contina trabajando realizando los agregados y extensiones pertinentes.
Actividades del Anlisis de Requerimientos.
Durante el anlisis de requerimientos se llevan a cabo las siguientes actividades:
1. Definicin de secuencias de transacciones basadas en los procesos de negocio.
2. Expansin o definicin del modelo de estructura de objetos para objetos entidad.
3. Dibujo de diagramas de ciclo de vida para objetos entidad.
4. Particionamiento del espacio del problema.
El proceso de produccin de la especificacin de requerimientos comprende dos corrientes principales:
El anlisis de la funcionalidad requerida del nuevo sistema. Esto se documenta utilizando secuencias de transaccin.
El anlisis de la estructura de objetos entidad para soportar dicha funcionalidad. Esto es documentado utilizando el
modelo de objetos.
Estas dos actividades pueden realizarse en paralelo, y no existe un criterio estricto sobre que modelo debe desarrollarse
antes.
Para sistemas "intensivos en datos", el modelado de las relaciones de objetos y atributos es particularmente importante.
Para sistemas "algortmicamente intensivos" o en proyectos de "reingeniera de negocios", el modelado de la
funcionalidad, representado por secuencias de transaccin en combinacin con un modelo de objetos, puede ser ms
importante.
a) Definicin de Secuencia de Transacciones.
El modelado de secuencia de transacciones incluye los siguientes pasos:
1. Identificacin de las secuencias de transacciones requeridas.
2. Definicin del contexto del negocio.
3. Descripcin del camino estndar.
4. Descripcin de caminos alternativos. Identificacin de s ecuencias de trans acciones. Identificacin a travs de
actores.
Identificar los actores que se comunicarn con el sistema. Los actores pueden ser personas humanas o interfaces con
otros sistemas.
Para cada actor identificado considerar que es lo que el actor realizar con el sistema, utilizando secuencias de
transacciones para describir esto. Es til considerar:
o Cuales son las principales tareas del actor.
o Qu accesos (lectura o escritura) requiere el actor del sistema.

Prof.: Oscar Nez M.

23

Diseo Orientado a Objetos


o Cundo el actor informar al sistema acerca de cambios fuera del sistema. o Cundo el actor ser informado de
cambios a travs del sistema. Identificacin a travs de eventos.
Consiste en identificar a que eventos externos o temporales debe ser capaz de responder el sistema. Para ello se siguen los
siguientes pasos:
Confeccionar la lista de eventos. Cada evento externo al cual el sistema debe responder, es listado, incluyendo eventos
temporales.
Asociar una secuencia de transacciones para cada evento identificado. Inicialmente se asocia una secuencia de
transaccin por cada evento. Puede haber ms de una respuesta para un evento. En tal caso se requiere una secuencia de
transacciones para cada respuesta.
Relacin entre actores y eventos externos.
El enfoque de particionamiento por eventos describe eventos del negocio los cuales se originan a menudo fuera de la
compaa. El generador de dichos eventos, a menudo no se comunica en forma directa con el sistema, sino que lo hace a
travs de un actor que hace de agente o intermediario. Por lo tanto, el actor que inicia una secuencia de transacciones lo
hace en resp uesta a un evento, no es l quin lo origina. Sin embargo, hay casos, como los cajeros automticos, en los
cuales el actor es quin origina el evento.
Uso de diagramas de secuencias de transacciones.
Los actores y secuencias de transacciones identificados pueden documentarse utilizando diagramas de secuencias de
transacciones. Estos diagramas muestran el actor que inicia la interaccin con el sistema.
Alcance de una s ecuencia de trans acciones .
Una secuencia de transacciones debe cubrir una secuencia de eventos lgica y cohesiva. Es posible que dicho flujo de
eventos s extienda en el tiempo por varios das.
Para decidir el alcance de una secuencia de transacciones pueden seguirse los siguientes criterios:
1. La secuencia de transacciones debe tener el alcance tan grande como sea posible manejarla (en orden de asegurarnos de
que la secuencia de procesamiento completa es manejada satisfactoriamente). El proceso de negocios completo es el
alcance por defecto para la secuencia de transacciones.
2. Cuando se necesite subdividir la secuencia de transacciones para poder tener unidades razonables para manejar,
debemos elegir unidades que el usuario acepte y perciba como realizando un objetivo de inters desde el punto de vista del
negocio. Estas unidades pueden corresponderse con las opciones mayores del men de la aplicacin o comandos del
sistema.
El alcance de una secuencia de transacciones debe realizar una tarea la cual el profesional del negocio la reconozca como
una unidad cohesiva. Esto difiere de la perspectiva funcional donde las acciones son empaquetadas en comandos del
sistema u opciones de men pero sin referenciar la secuencia en la que deben utilizarse dichas opciones.
Una secuencia de transacciones describe acciones en la secuencia en que se usan, sin especificar si estas acciones deben
empaquetarse en una nica funcin del sistema o en varias.
Des cripcin de Caminos Es tndar y Alternativos .
Los caminos estndar y alternativos son descritos utilizando las descripciones textuales explicadas en el captulo dedicado
al modelado de procesos de negocios y secuencias de transacciones.
En la secuencia de transacciones se describe que es lo que el sistema debe hacer, como interactuar con los actores, y cual
e s el contexto del negocio para dicha interaccin. La secuencia de transacciones muestra como se logra esto. Esto es
descrito en el modelo de estructura de objetos donde se especifican operaciones elementales a nivel de objeto.
Los caminos alternativos son descritos separadamente por un nmero de razones. Una razn es que esto permite que se lea
el camino estndar sin distracciones por los detalles de casos inusuales o manejo de errores. Otra razn es que la
separacin del camino estndar de los alternativos ayuda al desarrollador a concentrarse en los tratamientos principales del
procesamiento normal de las transacciones.
Ejemplos de funcionalidad que puede ser descrita como caminos alternativos son:
Partes opcionales de la secuencia de transacciones.
Curs os alternativos de eventos que rara vez ocurren.
Sub-cursos separados que solo se ejecutan en ciertos casos.
Manejo de errores.
Identificacin y definicin de s ecuencias comunes.
Secuencias que son comunes a varias secuencias de transacciones pueden ser identificadas y descritas como secuencias de
transacciones separadas. Tanto las secuencias de transacciones y las secuencias comunes se pueden utilizar para describir
caminos estndar como alternativos.
Prof.: Oscar Nez M.

23

Diseo Orientado a Objetos


A menudo las secuencias comunes se asocian con jerarquas de herencia, tanto de clases de objetos como de actores. A
menudo las secuencias de transacciones individuales describen la lgica que se aplica a las subclases de objetos mientras
que la secuencia comn describe la lgica que se aplica al nivel de superclase y por lo tanto es comn a todas las
subclases.
Jerarquas de actores.
Los actores representan roles de usuarios. En casos donde diferentes tipos de actores comparten capacidades comunes,
puede ser til definir jerarquas de actores. (p.e., un administrador y un usuario normal de l sistema pueden tener ciertas
capacidades comunes las que pueden modelarse utilizando una superclase de actor). Cada actor hereda de la superclase
actor.
Las jerarquas de actores son necesarias cuando se encuentra lgica comn en dos secuencias de transacciones distintas
que se comunican con dos actores diferentes. Cuando se separa esta lgica comn en una secuencia comn, sta necesita
comunicarse con los dos diferentes actores. Dichos actores juegan un rol idntico con respecto a la secuencia comn. En
este caso es conveniente definir una superclase actor desde la que los dos actores originales heredan y con quienes la
secuencia comn se comunica.
Modelando interfaces de usuario e interfaces externas.

En los puntos donde los actores inician o se comunican son secuencias de transacciones, existe a menudo intercambio de
datos. El actor suministra datos al sistema, o el sistema brinda datos al actor.
Es importante identificar que datos son pasados. Estos datos pueden ser descritos utilizando clases de objetos interface
(que se corresponde con pantallas, ventanas, reportes). Es necesario identificar clase de objetos interfaces cuyos datos son
suministrados a los actores o recibidos desde ellos.
El proceso de definicin de interfaces puede asistirse con el modelado de prototipos. Sin embargo, debe aclararse que el
modelado final de los objetos interfaces debe posponerse hasta la etapa de diseo lgico.
b) Expandiendo el Modelo de Estructura de Objetos.
El principal objetivo del modelado de estructura de objetos en esta fase es producir un modelo completo de objetos
entidad. Dependiendo en cuan detallado fue el anlisis del negocio, puede que solo sea necesario expandir y refinar el
modelo de estructura de objetos.
Pasos en el modelado de estructura de objetos para el anlisis de requerimientos.
1. Determinar los objetos entidad candidatos y agregarlos al modelo.
2. Agregar relaciones estticas entre objetos entidad.
3. Completar la definicin bsica para cada objeto entidad:
Definiendo el conjunto bsico de atributos.
Definiendo atributos de identificacin.
Definiendo restricciones.
Identificando operaciones donde se requieran.
4. Agregar estructuras de herencia para los objetos entidad.
5. Agregar estructuras de agregacin para los objetos entidad.
6. Refinar las relaciones estticas tomando en cuenta las estructuras de herencia y agregacin.
c) Definicin de ciclos de vida de Objetos.
Cada vez que se agrega una nueva clase al modelo de estructura de objetos, debe examinarse si no es necesario dibujar un
diagrama de ciclo de vida para dicha clase.
d) Uso de Diagramas de Modelo Global.
Los diagramas de modelado global tienen dos usos durante el anlisis de requerimientos, ambos vinculados con el manejo
de la complejidad:
Particionamiento del espacio del problema para sistemas muy grandes.
Representacin de requerimientos del sistema a un nivel general (como el diagrama de contexto).
Prof.: Oscar Nez M.

24

Diseo Orientado a Objetos

Diseo Lgico.
El propsito del diseo lgico es producir un modelo de diseo completo para el sistema, relativamente libre de
restricciones detalladas de implementacin.
Relaciones entre el diseo lgico y el fsico.
El objetivo del diseo lgico es producir un diseo que requiera pequeos cambios durante el diseo fsico para ser
implementado. El objetivo de esto es obtener un modelo de implementacin "portable" a diferentes escenarios de
implementaci n (estilos de interfaces, lenguajes, dbms, sistemas operativos, hardware, etc.).
Sin embargo, se recomienda que antes de empezar el diseo lgico se tomen ciertas decisiones estratgicas incluyendo:
Sistemas de computacin a utilizar.
Bases de datos.
Interface de usuario.
Lenguaje de programacin.
Librera de clases a utilizar.
Trabajos planeados para ejecutar en modo batch.
Criterios de performance.
Estrategias con respecto al manejo de errores, administracin de memoria (garbage collection).
Requerimientos de distribucin esperados.
Actividades realizadas durante el diseo lgico.
Las siguientes actividades se llevan a cabo durante el diseo lgico:
Identificacin de objetos interface y de control.
Identificacin de operaciones.
Uso de diagramas de interaccin de objetos para validar el diseo.
Refinado del modelo de estructura de objetos.
Refinado del modelo de ciclo de vida de objetos.
Definicin de subsistemas.
Muchas actividades del diseo lgico toman las secuencias de transacciones como punto de partida. El anlisis de las
secuencias de transacciones es utilizado para identificar que objetos de interfaz y de control deben agregarse al modelo de
objetos. Dibujando diagramas de interaccin de objetos individuales para cada secuencia de transacciones se asiste en la
identificacin de operaciones de las clases de objetos.
Identificacin de Objetos de Interface y de Control.
Cmo identificar objetos interfaz.
Los objetos interfaz pueden identificarse siguiendo los siguientes pasos:
1. Asignar un objeto interfaz central por cada combinacin secuencia de transaccin / actor / dispositivo. P.E. un
supervisor de bodega puede utilizar una interface GUI (Graphical User Interface, interface grfica de usuario) de pantalla
para controlar movimientos de stock y una impresora para imprimir detalles de movimientos. Para estas actividades se
pueden identificar dos objetos interfaz.
2. Para una interfaz GUI, asignar un objeto interfaz por ventana. Los objetos interface se comunican con el objeto
interface central identificado en el punto anterior. No es conveniente identificar objetos interfaz para cada componente
individual de la ventana (botones, listas, etc.), ya que esto es manejado normalmente por los constructores de interfaces
(p.e. Visual Basic).
3. Para otro tipo de dispositivos, puede ser til identificar un objeto interface central, el cual maneja el tipo particular de
salida, y definir objetos interfaz adicionales para variantes especficas. P.E. puede definirse un objeto interfaz central para

manejar los requerimientos de impresin, con objetos interfaz asociados para tipos individuales de impresoras (de matriz
de puntos, de inyeccin o lser, etc.)
4. Objetos interfaz pueden modelar protocolos de comunicacin por capas como el modelo ISO. Un objeto interfaz se
define por cada capa, el cual se comunica solo con objetos de la capa superior e inferior inmediata.
Prof.: Oscar Nez M.

25

Diseo Orientado a Objetos


5. La agregacin puede utilizarse con los objetos interfaz. P.E. algunos dispositivos son mejor considerados como
compuestos. Un ejemplo es un cajero automtico compuesto de una lectora de tarjeta magntica, una pantalla, un
dispensador de dinero, y una impresora.
6. Puede definirse herencia para objetos interfaz. Esto puede ser til en casos donde un actor tiene un conjunto de
capacidades que es un superconjunto de capacidades de otro actor.
7. Una vez que los objetos interfaces han sido definidos, los objetos interface centrales pueden revisarse para detectar
similitudes, en cuyo caso pueden combinarse.
Una vez que los objetos interfaces han sido identificados, es necesario considerar que atributos y operaciones los objetos
requieren. El tipo de comportamiento asignado a los objetos interface son los que:
Requieren informacin desde el exterior del sistema.
Presentan informacin al exterior del sistema.
Cambia si el comportamiento del usuario cambia.
Es dependiente del tipo de dispositivo.
A menudo existen objetos interfaz con ciclos de vida complejos en orden de manejar ingresos de datos alternativos, o
diferentes secuencias de navegacin. En tales casos es conveniente utilizar diagramas de ciclo de vida.
Los detalles de cmo la interface de usuario debe aparecer se finaliza durante el diseo lgico usando un constructor GUI
y objetos interfaz en combinacin.
Como identificar objetos de control.
Los objetos de control contienen comportamiento que no pertenece naturalmente ni a objetos entidad ni a objetos interfaz.
Son por lo tanto identificados luego que estos dos tipos de objetos.
Los objetos de control son generalmente temporales y su duracin se extiende solo durante la secuencia de transacciones.
La lgica contenida en un objeto de control puede ser lgica de control de sistema, requerida si se est desarrollando un
sistema de computacin. Tambin puede ser lgica de la aplicacin. A menudo es til utilizar objetos de control para
encapsular la lgica de control de secuencias de transacciones.
Los objetos de control pueden identificarse inicialmente asignando un objeto de control por cada secuencia de transaccin.
Luego que se ha asignado el comportamiento a los objetos entidad e interfaz, puede darse que todo el comportamiento
haya sido satisfactoriamente asignado, sin dejar requerimientos para el objeto de control. Pero si existe comportamiento
que no pertenece naturalmente ni a los objetos entidad ni de interfaz, este debe permanecer en el objeto de control.
El tipo de comportamiento que puede ser asignado a un objeto de control puede ser:
Comportamiento que no cambia si el vecindario del objeto cambia.
Comportamiento que no cambia sustancialmente si el comportamiento de los objetos entidad vara.
Comportamiento que afecta a ms de un objeto entidad.
Lgica dependiente del estado.
Lgica de control para una secuencia de transacciones.
Los objetos de control se vinculan con los actores a travs de objetos interfaz. Los objeto s de control a menudo actan
como un conjunto de buffers entre los objetos entidad y los de control.
Los objetos de control que son demasiado complejos y de baja cohesin funcional deben dividirse. En contraposicin si
existen varios objetos de control que tienen alta cohesin funcional entre ellos, deben combinarse.
Los objetos de control pueden tener asociados atributos, que normalmente son privados. La decisin de cuando considerar
algunos objetos que contienen clculos requeridos en el dominio del problema (p.e. clculos de impuestos, ndices, etc.)
como objetos de control o entidad puede ser arbitraria. Como regla se puede tomar, que aquellos objetos que tienen
atributos y deben ser persistentes, deben considerarse del tipo entidad. Los que no contienen atributos y son temporales, se
consideran como de control.
Debe tenerse la precaucin de no utilizar objetos de control para separar funciones de datos, ya que esto va en contra del
principio de encapsulamiento de la orientacin a objetos.
Asociaciones posibles entre los distintos tipos de objetos.
Usualmente solo los siguientes tipos de asociaciones pueden existir entre objetos de diferentes tipos:
Objeto
Objeto Receptor del mensaje
Emisor del mensaje
Entidad
Interface
Control
Entidad
CO - RE - HE - AG
CO
CO
Interface
CO RE
CO - RE - HE - AG
CO
Control
CO RE
CO
CO - HE - AG
Prof.: Oscar Nez M.

25

Diseo Orientado a Objetos


Referencias:
CO: comunicacin por mensajes (enlace dinmico)
RE: relacin esttica
HE: herencia
AG: agregacin
Las letras en azul indican asociaciones que pueden ocurrir pero que rara vez se dan. Normalmente los actores se
comunican con objetos interface, no con objetos entidad ni de control.
Las relaciones estticas normalmente slo son modeladas para objetos entidad. Para los objetos interface y de control
usualmente solo son relevantes las asociaciones por comunicacin.
Las relaciones de herencia y de agregacin solo se dan entre las clases de objetos del mismo tipo.
Identificando y definiendo Operaciones.

Una operacin es un proceso que se puede requerir como una unidad a un objeto. Una misma operacin puede estar
disponible para objetos de diferentes clases.
Una misma operacin define un servicio que es ofrecido. Esta definicin incluye una descripcin de la semntica de la
operacin, y una descripcin de la sintaxis (como debe ser invocado el servicio). La semntica central de una operacin
debe ser siempre la misma independientemente de la clase de objeto que la implemente. La sintaxis indica la informacin
que debe suministrarse en orden de invocar la operacin, esto es el nombre y sus parmetros de entrada/salida.
Un mtodo es una implementacin de una operacin para una clase especfica, y puede variar para cada clase.
Notacin de punto.
Tanto para especificar atributos como operaciones durante el diseo lgico puede utilizarse la "notacin de punto".
Objeto.atributo u Objeto.operacin
Ejemplo:
DocumentoAutor Especifica el atributo autor del objeto documento
Auto.Conductor.Nombre Especifica el nombre de la persona que conduce el auto. Aqu Conductor identifica la relacin
entre las clases Auto y Persona.
Cmo identificar operaciones.
Existen tres posibles maneras de identificar operaciones:
1. Considerando el rol y responsabilidades de cada clase de objetos, usando los enfoques basados en el anlisis de las
secuencias de transacciones o en el enfoque de "lista de compras".
2. Identificando las interacciones de objetos requeridas para soportar cada secuencia de transacciones, con la asistencia de
los diagramas de interaccin de objetos.
3. Analizando los ciclos de vida de objetos y determinando las operaciones que ellos implican.
Los tres enfoques son valiosos y pueden ser utilizados en combinacin. Cualquiera sea el enfoque utilizado, los puntos
clave a considerar son:
Cmo puede una funcionalidad dividirse entre operaciones?
Qu clase de objeto es responsable de una determinada operacin?
1. Considerando roles y responsabilidades para cada clase de objetos
Acorde con Wirfs-Brock, cada clase de objetos debe tener un rol o funcin simple y coherente claramente definido. En
soporte de dicho rol, un objeto toma ciertas responsabilidades y comportamiento que es lgico que otros objetos esperen
de l. Las operaciones que un objeto tiene le permiten cumplir con sus responsabilidades.
Las responsabilidades y por lo tanto las operaciones, son identificadas analizando los requerimientos del sistema
representados en las secuencias de transacciones.
Habiendo identificado los primeros objetos entidad, interface, y control, podemos ahora considerar cada secuencia de
transacciones en orden de identificar que operaciones deben asignarse a cada clase de objetos.
Para realizar esto es conveniente utilizar un diagrama de estructura de objetos que contenga las clases relevantes a la
secuencia de transacciones que se analiza.
Prof.: Oscar Nez M.

26

Diseo Orientado a Objetos


Alternativamente, las responsabilidades pueden identificarse utilizando el enfoque llamado de "lista de compra". Usando
este enfoque, el analista identifica operaciones considerando cada clase de objetos de una en vez y considerando "de qu
es responsable este objeto, y qu deseo realizar con estos datos?".
Cuando una clase de objetos es claramente responsable de un comportamiento en particular requerido por una secuencia
de transacciones, la operacin debe asignarse a dicha clase. Cuando no existe una clara responsabilidad perteneciente a
una clase en particular se puede hacer lo siguiente:
- Asignar la responsabilidad a la clase que ms se adecue
- Distribuir la responsabilidad en ms de una clase
- Introducir un objeto de control y asignar la operacin al objeto de control
Cul es la mejor opcin depende del contexto y del juicio del diseador. La asignacin correcta de operaciones es un
factor clave en un sistema bien diseado y mantenible.
2. Interaccin de objetos requerida para soportar cada secuencia de transacciones
Las interacciones de objetos requeridas para soportar una secuencia de transacciones puede modelarse usando diagramas
de interaccin de objetos. Normalmente se utiliza un diagrama de interaccin de objetos por cada secuencia de transaccin
o por cada camino (estndar o alternativo) de la secuencia de transaccin.
El punto de entrada para el desarrollo de un diagrama de interaccin de objetos se extrae del diagrama de estructura de
objetos. Esto debe incluir todos los objetos entidad relevantes para la secuencia de transacciones y los objetos interfaz y de
control que se asignan a la secuencia de transaccin.
El primer paso es considerar que interaccin de objetos se requiere para describir la funcionalidad de la secuencia de
transaccin. Estas interacciones de objetos son llamadas eventos.
Una secuencia de transacciones es iniciada por un evento. Un evento puede ser externo o temporal. Los eventos externos
son generados por actores. Los eventos temporales son disparados cuando se alcanza un instante de tiempo determinado
(fecha, hora, proceso peridico).
Si para identificar las secuencias de transacciones se utiliza el enfoque de particionamiento por eventos, entonces los
eventos de negocio ya se tienen disponibles. Si el generador del evento de negocio interacta directamente con el sistema
(como en un cajero automtico), entonces este evento, su generador, y el objeto que recibe inicialmente el evento, pueden
introducirse en el diagrama de interaccin. Si el generador del evento de negocio no interacta directamente con el
sistema, entonces el evento que inicia la secuencia de transacciones es el evento en el cual un actor interno a la empresa
reacciona al evento de negocio iniciando una interaccin con el sistema.
Siguiendo el evento inicial, eventos internos son agregados al diagrama de interaccin de objetos para representar la
comunicacin entre objetos que se requiere para soportar la secuencia de transacciones. Un evento interno es un mensaje
por un objeto a otro invocando la ejecucin de una operacin.
Otros eventos pueden ser enviados o recibidos desde los actores que interactan con la secuencia de transacciones.
3. Analizando ciclos de vida de objetos
Los diagramas de ciclo de vida deben revisarse para identificar operaciones. Cada evento mostrado en un diagrama de
ciclo de vida causa la invocacin de una operacin en el objeto que recibe el evento. La revisin de los diagramas de ciclo

de vida no revelan todas las operaciones, ya que en estos diagramas normalmente solo se modelan los eventos que
producen cambios de estado.
Especificacin de la semntica y sintaxis de las operaciones.
Debe definirse la semntica de cada operacin identificada. El nombre, la sintaxis, y la semntica deben proveer toda la
informacin que un usuario de la operacin necesito para decidir cuando utilizarla o no.
La especificacin de la semntica puede expresarse en forma de texto, tablas de decisin, pseudocdigo, etc. Deben
especificarse las precondiciones y postcondiciones de las operaciones como parte de la definicin.
Tambin debe especificarse la sintaxis de la operacin, los argumentos de entrada/salida requeridos. Puede definirse el
tipo y dominio de cada argumento, como as tambin si es opcional o mandatario.
Operaciones de clase.
Una operacin puede ser definida como operacin de clase. Una operacin de clase es una operacin que es invocada por
la clase misma no por las instancias. Tales operaciones pueden por ejemplo retornar informacin estadstica sobre los
objetos instanciados de dicha clase (promedios, totales, etc.). Un objeto particular puede ser creado durante el diseo
fsico si el lenguaje utilizado no soporta operaciones de clase.
Herencia de operaciones.
Operaciones concretas, abstractas y templados.
Prof.: Oscar Nez M.

27

Diseo Orientado a Objetos


En cualquier clase concreta, las operaciones definidas deben siempre tener una implementacin. Sin embargo, en las
clases abstractas (de las cuales no se generan instancias) la implementacin de una operacin no es obligatoria, ya que las
mismas pueden ser implementadas en las subclases.
Los siguientes tipos de operacin pueden especificarse para clases abstractas:
Operacin abstracta: no tiene un mtodo de implementacin, solo se definen la sintaxis y semntica de la operacin.
Operacin templado: es una operacin concreta que se implementa en trminos de una o ms operaciones abstractas.
Operacin concreta: es aquella para la que se especifica completamente su implementacin. Redefiniendo
operaciones heredadas.
Cuando una clase de objetos hereda una operacin concreta de una superclase y la utiliza sin modificarla, no debe
agregarse ninguna definicin para la operacin en la subclase.
Normalmente solo debera necesitarse especificaciones adicionales en la subclase en los siguientes casos:
Adicin de una implementacin para una operacin abstracta.
Extensin de una operacin para agregar comportamientos especficos de la subclase.
Redefinicin de los tipos de argumentos y dominio de los mismos.
Optimizacin del cdigo de la operacin.
Redefiniendo el Modelo de Estructura de Objetos.
Adicin y remocin de clases de objetos.
Las clases de objetos descubiertas durante el anlisis de requerimientos son llevadas al diseo lgico y, objetos de control
e interfaz adicionales son agregados.
En aplicaciones complejas puede necesitarse cambiar el nivel de abstraccin en que las clases de objetos son vistas. Por
ejemplo, desde el punto de vista del anlisis de requerimientos, puede ser claro que un nmero de objetos similares son
requeridos y que cada uno debe ser descrito como una subclase de una superclase. Desde el punto de vista del diseo
lgico, puede determinarse que solo es necesaria la superclase en el diseo final.
Identificacin de atributo.
Durante el diseo lgico, los atributos para cada clase de objetos deben ser completamente identificados. Se especifican
las restricciones de acceso determinado atributos pblicos, protegidos, y privados. Tambin aqu se determinan atributos
derivados.
Definicin de persistencia de atributos.
Los objetos entidad son usualmente persistentes mientras que los de interface o de control no. Deben identificarse objetos
entidad que no son persistentes, y los de interface y de control que si lo son.
Subsistemas.
Subsistemas pueden haber sido definidos en etapas previas o pueden definirse durante el diseo lgico. En el caso en que
hayan sido definidos con anterioridad, igualmente es conveniente revisarlos en esta etapa luego de que las clases han sido
convenientemente definidas, para verificar que los subsistemas definidos en verdad representan unidades coherentes.
Durante el diseo lgico las principales razones para definir subsistemas son:
Para definir unidades de entrega, unidades funcionales que se entregarn al usuario en diferentes momentos.
Para definir unidades de distribucin.
Para definir mdulos que garanticen la robustez del diseo del sistema.
Con propsitos de validacin, para chequear la calidad del diseo del sistema.
Con propsitos de presentacin.
Prof.: Oscar Nez M.

27

Diseo Orientado a Objetos

Diseo Fsico.
El propsito del diseo fsico es agregar los detalles tcnicos dependientes de la plataforma, requeridos para construir el
sistema a partir del diseo lgico.
Las principales actividades del diseo fsico son:
1. Establecimiento de la arquitectura del sistema.
2. Implementacin de las clases del dominio del problema del sistema.
3. Construccin de la interface de usuario.
4. Diseo e implementacin del componente de administracin de datos.
5. Diseo de la integracin con sistemas existentes (legacy systems)
Arquitectura del sistema.
La arquitectura del sistema es la organizacin general del sistema en componentes (o subsistemas).

Como se ha mencionado, es til y comn dividir sistemas grandes y complejos en susbsistemas para facilitar su desarrollo.
Pero adems es til dividir un sistema de cualquier tamao en subsistemas basados en consideraciones arquitecturales que
son especficamente relevantes durante la fase de diseo fsico de la aplicacin.
Un sistema puede particionarse vertical y horizontalmente (en capas). Las particiones verticales son utilizadas para
subdividir la funcionalidad de la funcionalidad. En tanto que las particiones horizontales son utilizadas particularmente
para aislar dependencias del sistema operativo, bases de datos, o hardware. La subdivisin en capas horizontales asiste en
el salvaguardo de la portabilidad del sistema.
Las particiones verticales deben estar dbilmente acopladas y trabajar en configuracin cliente/servidor o peer-to-peer. Las
capas horizontales estn en una relacin cliente-servidor, donde las capas ms bajas (servidores) suministran servicios a
las capas superiores (clientes).
La arquitectura del sistema puede diagramarse utilizando diagramas de visin general (diagrama global del sistema). Estos
diagramas muestran subsistemas y los servicios que se proveen mutuamente.
El presente enfoque de desarrollo orientado a objetos recomienda la siguiente arquitectura de seis componentes:
Componente Dominio de Problema (PDC)
Representa la parte del sistema que corresponde con el dominio del problema (mundo real). Consiste de todos los objetos
entidad y de control identificados durante las fases previas.
Componente de Interaccin Humana (HIC)
Consiste de todos los objetos requeridos para la implementacin de la interface de usuario. Se corresponde con los objetos
intefaz con usuarios humanos identificados durante las fases previas.
Componente de Interfaces Externas (EIC)
Consiste de todos los objetos intefaz con usuarios no humanos, como ser sistemas externos, dispositivos, impresoras,
etc.
Componente de Administracin de Datos (DMC)
Provee la infraestructura para el almacenamiento y recuperacin de los objetos persistentes en algn medio de
almacenamiento.
Componente de Administracin de Tareas (TMC)
Se encarga de administrar concurrencia cuando es necesaria. La utilizacin de este componente es muy rara en sistemas
administrativos, siendo de utilidad solo en algunos sistemas en tiempo real.
Componente de Servicio de Utilidades (USC)
Prof.: Oscar Nez M.

28

Diseo Orientado a Objetos


Provee servicios de utilidad general que pueden ser requeridos por todos los dems componentes.
Componente Dominio del Problema (PDC).
Este componente representa la parte del mundo real (dominio del problema) del sistema. Esta componente no debe ser
afectado por dependencias del hardware, sistema operativo, sistema de interfaz, o de base de datos.
Este componente comprende todas las clases de objetos entidad y control, definidas durante las fases previas, pudindose
extender con clases especficas de la implementacin.
El diseo fsico implica la implementacin de las clases y la especificacin formal de las operaciones. Para esto es
conveniente trabajar con lenguajes orientados a objetos que soportan todas las caractersticas y permiten una traslacin
directa de las clases a las construcciones del lenguaje.
Los principales puntos a considerar durante la implementacin de las clases del dominio del problema son:
Eleccin de tipos y estructuras de datos.
Implementacin de relaciones.
Implementacin de ciclos de vida.
Implementacin de restricciones.
Implementacin de atributos y relaciones derivadas.
Manejo de errores.
Componente de Administracin de Datos (DMC).
Las clases del componente de administracin de datos proveen la infraestructura para el almacenamiento y recuperacin
de objetos en un sistema de manejo de datos (DBMS o sistema de archivos). La separacin de estas clases en un
componente especfico permite aislar al sistema de la dependencia de un sistema de manejo de datos especfico.
La implementacin en bases de datos puede contemplar diferentes tecnologas, sin embargo, las ms importantes son las
relacionales (RDBMS) y las orientadas a objetos (ODBMS).
Los RDBMS no permiten almacenar en forma directa objetos lo cual obliga a realizar una capa de traslacin, sin embargo,
actualmente para aplicaciones con grandes volmenes de datos son los ms maduros y robustos. Por otro lado la
tecnologa de ODBMS si bien se integra mejor a un sistema orientado a objetos, todava se encuentra en evolucin y es
considerada por algunos, inmadura para soportar aplicaciones crticas.
Los principales pasos en la construccin del componente de administracin de datos son:
1. Mapeo de clases persistentes en las estructuras de datos del sistema de administracin de datos (p.e. tablas de un
RDBMS).
2. Diseo de las clases de objeto para manejar las transformaciones y para interfacear con el DBMS.
3. Diseo detallado de la interaccin de objetos necesaria para soportar el almacenamiento y recuperacin de objetos
persistentes.
Prof.: Oscar Nez M.

28

Diseo Orientado a Objetos


Arquitectura del dominio de administracin de datos.
Diseo de base de datos relacional.

Para cada objeto persistente debe identificarse un identificador unvoco (Object ID; Clave Primaria). La aplicacin misma
es responsable de la generacin y administracin de este Object ID. Para la generacin de este Object ID pueden utilizarse
atributos de identificacin definidos durante el diseo lgico.
Los atributos compuestos deben separarse en sus componentes atmicos.
Las relaciones estticas entre clases pueden realizarse a travs de la implementacin de claves forneas. En general, se
tiene tres alternativas para el mapeo de relaciones:
1. Cualquier relacin (cualquiera sea su cardinalidad) puede siempre mapearse como una tabla separada en la cual cada
fila contiene un par de Object ID y se corresponde con una instancia de la relacin.
2. Relaciones uno-a-muchos o uno-a-uno, pueden mapearse incluyendo claves forneas en una de las tablas relacionadas.
3. Para relaciones uno-a-uno existe una tercera alternativa que consiste en combinar las tablas relacionadas en una sola.
Para el mapeo de agregaciones, se aplican las mismas reglas que para las relaciones estticas, ya que en realidad son un
caso particular de las mismas.
Para el mapeo de jerarquas de herencia existen tres alternativas:
1. Cada clase de la jerarqua es mapeada a una tabla separada. Todas comparten un mismo Object ID, y tienen una
columna para cada atributo propio de la clase.
2. Cada clase no abstracta en la jerarqua es mapeada a una tabla separada que contiene una columna adicional para cada
atributo heredado.
3. Todas las clases en la jerarqua son mapeadas a una nica tabla agregndose columnas para todos los atributos de la
jerarqua.

Prof.: Oscar Nez M.

29

Diseo Orientado a Objetos


FASE DE PRUEBAS
Verificacin y validacin a lo largo del ciclo de vida
Las pruebas comienzan a nivel de mdulo y trabajan hacia fuera. La prueba y la depuracin son actividades diferentes
pero la depuracin se incluye en la prueba.
La verificacin son el conjunto de actividades que aseguran que el software implementa correctamente una funcin
especfica. La validacin se refiere a un conjunto diferente de actividades que aseguran que el software construido se
ajusta a los requisitos del cliente.
Organizacin para las pruebas del software
El responsable del software es el responsable de las pruebas de las unidades del programa. Algunas veces, tambin se
encarga de las pruebas de integracin. Un grupo independiente de prueba se encarga de probar el sistema cuando ya est
probado por sus creadores. Esta ltima fase de pruebas est supervisada por el creador del software que corregir los
errores encontrados por el grupo independiente.
Una estrategia de prueba del software
Las pruebas se asemejan a una espiral, que comienza con las pruebas de cada unidad y terminan con las de integracin de
todo el sistema. Despus estn las pruebas de validacin y por ltimo las del sistema.
Pruebas de unidad: Se prueban las unidades funcionales a nivel de cdigo (nivel de implementacin). Para las pruebas
de unidad se utilizan tcnicas de caja blanca.
Pruebas de integracin: Se prueba la interconexin entre las diferentes unidades (nivel de diseo). Para las pruebas de
integracin se utilizan tcnicas de caja negra y algunas de caja blanca.
Pruebas de validacin: Se prueba si el sistema cumple los requisitos del cliente (nivel de anlisis). Para las pruebas de
validacin se utilizan tcnicas de caja negra.
Pruebas de sistema: Se prueba el sistema en su totalidad.
TCNICAS Y MTODOS DE PRUEBA. PRUEBAS ORIENTADAS A OBJETOS
Durante el anlisis es posible que se cometan errores en el diseo de las clases, por lo que hay que tener mucho cuidado.
Si el error no est en el anlisis, se pasa al diseo. Si no se encuentra en el diseo, habr que buscar en la codificacin, con
un considerable aumento en el esfuerzo de correccin.
Exactitud de los modelos de AOO y DOO: Aunque el Anlisis y el Diseo no son cdigo, se puede probar su exactitud
semntica; que debe reflejar un modelo del problema del mundo real a resolver.
Cons is tencia de los modelos de AOO y DOO: Se debe de comprobar que haya consistencia entre las clases, para ello se
utilizan los modelos clase-responsabilidad-colaboracin (CRC) y diagrama objeto-relacin. Se debe comprobar que
cuando a una clase se le solicita un servicio, sta debe servirlo adecuadamente. Tambin se debe comprobar que el reparto
de responsabilid ades es adecuado.
TIPOS DE PRUEBAS
Pruebas de unidad en OO: La unidad bsica en OO es la clase u objeto encapsulado, por lo que se debe comprobar
todos.
Pruebas de integracin en OO: Aunque no suele ser posible probar la integracin de los diferentes componentes de una
clase uno por uno, se puede probar mediante hilos (se prueban las clases que interacciona con un determinado suceso o
entrada al sistema) o basarse en el uso (primero se prueban las clases que requieren a menos clases que las sirvan y luego
las dems). As sucesivamente hasta completar todo el sistema.
Pruebas de validacin en OO: Se utilizan los casos de uso. Se utilizan pruebas de caja negra.
DISEO DE CASOS DE PRUEBA EN OO
Debido al encapsulamiento y a la herencia, sacar una instantnea de los atributos de los objetos es muy difcil. Se suelen
utilizar pruebas de caja negra.
Se deben disear pruebas que busquen errores, en la integracin (resultados inesperados, uso incorrecto de
mensajes/operaciones e invocaciones incorrectas) se buscan errores en los objetos clientes.
Tambin hay pruebas que buscan el error en lo que el usuario hace y eso causa el error del sistema, esas pruebas se llaman
pruebas basadas en el escenario. Estas pruebas sirven para validar.
Se pueden hacer pruebas al azar, pruebas de particin en estados, o pruebas del dinamismo del sistema utilizando los
diagramas de transicin de estados.
Prof.: Oscar Nez M.

29

Você também pode gostar