Diseo de Sistemas

Unidad 1: Introduccin a la Orientacin a Objetos

Contenidos
Objetivos de la Unidad 1........................................................................................... 2
Recursos adicionales................................................................................................. 2
Breve historia de los mtodos de anlisis y diseo Orientados a Objetos ................... 2
Beneficios de las tcnicas Orientadas a Objetos ........................................................ 4
Conceptos fundamentales de la Orientacin a Objetos............................................... 5
Tres enfoques de organizacin para comprender el mundo .................................... 5
Pero qu es un sistema orientado a objetos?......................................................... 5
Concepto de Objeto............................................................................................... 5
Concepto de Mensaje ............................................................................................ 6
Concepto de Colaboracin .................................................................................... 6
Concepto de Responsabilidad................................................................................ 7
Concepto de Clase................................................................................................. 7
Principios fundamentales .......................................................................................... 7
Abstraccin........................................................................................................... 7
Encapsulamiento................................................................................................... 8
Herencia................................................................................................................ 8
Polimorfismo ........................................................................................................ 8
Gua para la fase exploratoria inicial de objetos........................................................ 8
Identificando Clases.............................................................................................. 8
Identificando Responsabilidades ........................................................................... 9
Identificando Colaboraciones ................................................................................ 9
Estereotipos bsicos de Objetos........................................................................... 10
Como identificar operaciones de objetos ............................................................. 11

A.U.S. Gustavo Torossi

Pgina 1 de 12

Diseo de Sistemas

Objetivos de la Unidad 1
En esta unidad plantearemos los principios y caractersticas fundamentales del
paradigma Orientado a Objetos.
Veremos una sntesis histrica de la evolucin de mtodos y herramientas del
paradigma orientado a objetos desde su nacimiento hasta nuestros das.
Al finalizar la unidad el alumno conocer:
- Como evolucionaron histricamente las metodologas orientadas a objetos.
- Cuales son los conceptos y principios fundamentales sobre los que se asienta el
paradigma.
- Como funciona y cuales son los elementos esenciales de un sistema orientado a
objetos.
- Una introduccin al proceso de exploracin y bsqueda de objetos.

Recursos adicionales
Bibliografa.

Breve historia de los mtodos de anlisis y diseo Orientados a Objetos

En el desarrollo de la informtica la aplicacin de metodologas en general procedi con
una aplicacin inicial de las nuevas ideas en el mbito de la programacin,
trasladndose ms tarde su inters hacia el diseo, y finalmente llevado al anlisis.
Reflejando esto quizs, el inters en la orientacin a objetos tambin comenz,
histricamente en el mbito de la programacin. Recin en los aos 80 emergieron los
mtodos de diseo orientados al objeto y los mtodos orientados al objeto del anlisis
emergieron durante los aos 90.
A finales de los aos 70, principio de los 80, aparece el primer lenguaje puro orientado a
objetos denominado Smalltalk creado por Alan Kay y un grupo de visionarios en los
laboratorios de Xerox. Puede considerarse a Smalltalk tambin como el primer ambiente
GUI, sentando las bases para el desarrollo de las interfaces grficas que luego fueran
adoptadas masivamente.
Hasta este perodo no se haba hablado especficamente sobre anlisis o diseo
orientados a objetos. A finales de los aos 80 Grady Booch public un documento sobre
cmo disear para el lenguaje Ada al que le dio el ttulo proftico de Diseo Orientado
al Objeto. Sin embargo este primer mtodo no era realmente orientado a objetos y
Booch posteriormente ampli sus ideas a un mtodo de diseo genuino orientado al
objeto en el ao 1991 en su libro con el mismo ttulo, revisado en 1993.
El primer libro con el ttulo Anlisis Orientado al Objeto fue escrito por Shlaer y Mellor
en 1988. Al igual que el paper original de Booch, este no present un mtodo genuino
orientado al objeto, sino que se concentraba enteramente en la exposicin de modelos
extendidos del modelado entidad-relacin, basado fundamentalmente en datos sin
prestar mayor atencin a los aspectos del comportamiento de objetos. Shlaer y Mellor
A.U.S. Gustavo Torossi

Pgina 2 de 12

Diseo de Sistemas

publicaron un segundo volumen en 1992 que estableci que el comportamiento fuera

modelado usando diagramas de estados y transiciones. Mientras tanto, Peter Coad haba
incorporado ideas del comportamiento en un mtodo simple orientado al objeto (Coad y
Yourdon, 1990; 1991). El mtodo de Coad fue bastante popular debido a su
simplicidad. Estos mtodos fueron seguidos por una explosin de inters en la
publicacin de mtodos de anlisis y diseo orientados a objeto, muchos de los cuales
fueron de muy dudosa utilidad.
Aparte de estos mtodos mencionados, entre los ms significativos estaban OMT
(Rumbaugh y otros., 1991), Martin-Odell (1992), OOSE (Jacobson y otros., 1992) y
RDD (Wirfs-Brock y otros., 1990). OMT era otro mtodo data-driven arraigado en
diseo de base de datos. Posteriormente fue extendido al mtodo OMT2.
En paralelo con la aparicin de estos mtodos extendidos a partir del modelado entidad
relacin y data-driven, Wirfs-Brock y sus colegas desarrollaron un conjunto de tcnicas
de diseo basadas en las responsabilidad (responsability-driven-design RDD), a partir
de la experiencia obtenida con sus trabajos en Smalltalk, no basadas en las bases de
datos como los anteriores mtodos. Las contribuciones ms importantes de RDD fue la
idea del uso de las tarjetas CRC para el diseo y finalmente la introduccin de la idea de
estereotipos. Las tarjetas CRC representan clases, sus responsabilidades, y sus
colaboraciones con otros objetos, como punto principal de entrada para el diseo. Esta
idea fue originada por Ken Beck y Cunningham.
Ivar Jacobson desarroll la metodologa Objectory de la cual se deriva OOSE, en sus
trabajos en empresas de telecomunicaciones en Suecia. La principal contribucin de
estos mtodos fue la introduccin del concepto de Casos de Uso como punto de partida
para el anlisis. Los anteriores mtodos partan de modelos de objetos directamente.
Esta contribucin fue tan significativa y ampliamente aceptada, que posteriormente la
mayora de los mtodos incorporaron la utilizacin de casos de uso o variantes de los
mismos para realizar la captura y especificacin de requisitos.
Durante el curso se estudiar en detalle el modelo de casos de uso.
Otro mtodo destacado es OBA (Object Behaviour Analisys) originado por Goldberg y
Rubin para sus trabajos con Smalltalk en ParcPlace, aunque nunca fue publicado un
libro extensivo sobre este mtodo. Muchos otros mtodos fueron publicados entre los
que podemos nombrar MOSES Henderson-Sellers and Edwards, 1994), SOMA
(Graham, 1995).
Jim Rumbaugh y Grady Booch, trabajando juntos en Rational, decidieron unir sus
notaciones dando lugar a lo que se conoce como el Lenguaje Unificado de Modelado
(UML). Posteriormente se incorpor al equipo Ivar Jacobson, quin aport sus
conceptos desarrollados en Objectory del cual lo mas significativo fue el modelo de
Casos de Uso. Posteriormente UML fue remitido a la OMG para su homolgacin como
un lenguaje estndar de modelado.
En la unidad 2 del curso se estudia detalladamente los modelos de UML.
Sin embargo UML no es una metodologa completa sino un lenguaje de modelado que
puede ser utilizado con diferentes metodologas o procesos de desarrollo.
Tambin en Rational se desarroll un proceso de desarrollo de software que si bien no
fue homologado como un estndar, hoy da se ha convertido casi en un estndar de facto
y es conocido como RUP (Rational Unified Process) o simplemente UP (Proceso
A.U.S. Gustavo Torossi

Pgina 3 de 12

Diseo de Sistemas

Unificado). Al igual que UML, debe su nombre de unificado a que en este proceso se
han fusionado los principales conceptos, tcnicas, y herramientas, y las mejores
prcticas de distintos procesos de desarrollo que evolucionaron anteriormente.
En la unidad 3 del curso estudiaremos este proceso de desarrollo.
A fines de la dcada de los 90, como reaccin a las metodologas clsicas, criticadas
por burocrticas y pesadas, un grupo de metodlogos estableci una nueva filosofa
para el desarrollo de software dando origen a lo que se conocen como Mtodos giles
de los cuales quiz el ms emblemtico es conocido como Programacin Extrema (XP).
Estudiaremos estos mtodos en la unidad 4.

Beneficios de las tcnicas Orientadas a Objetos

Los mtodos Orientados a Objetos se desarrollaron fundamentalmente para solucionar o
perfeccionar el tratamiento de problemas que no pudieron ser solucionados
exitosamente con otras metodologas anteriores como los clsicos mtodos
estructurados. Entre algunos de los objetivos y beneficios ms importantes y conocidos
que se busca con la orientacin a objetos podemos mencionar:

Reusabilidad del software: si bien este es un objetivo ya afrontado por el diseo

estructurado, con la aplicacin de los conceptos de orientacin a objetos se
pretende avanzar un paso ms.

Mayor flexibilidad para realizar mantenimiento y modificaciones del software:

otra cuestin ya afrontada por el diseo estructurado, pero que las
construcciones orientadas a objetos pueden permitir mejorar.

Disminucin del gap semntico proveyendo una representacin consistente en

todo el ciclo de vida: la aplicacin de conceptos como el de clase y objeto,
permiten simplificar la representacin de las abstracciones hechas del dominio
del problema, y por ende contribuye a facilitar la solucin de problemas.

Mejor interaccin entre el usuario - analista - diseador: la aplicacin de

conceptos como el de clase y objeto permiten representar en forma directa sin
costura conceptos del dominio de problema en el espacio de la solucin,
facilitando esto la comunicacin entre todos los implicados en la escena del
desarrollo de software.

Ms apropiado para abordar problemas ms complejos: por los motivos antes

expuestos, la aplicacin de los principios de la orientacin a objetos a permitido
afrontar problemas ms desafiantes de una forma ms eficiente. Tal es el caso
del desarrollo de las interfaces grficas, cuyo desarrollo aplicando el viejo
paradigma procedural hubiera sido sumamente ineficiente y complejo.

A.U.S. Gustavo Torossi

Pgina 4 de 12

Diseo de Sistemas

Conceptos fundamentales de la Orientacin a Objetos

Tres enfoques de organizacin para comprender el mundo
Peter Coad en su libro menciona tres principios que utiliza el ser humano para lidiar con
la complejidad desde muy temprana edad. Estos son:
Diferenciacin de la experiencia en Objetos y Atributos
Distincin entre el todo y sus partes
Formacin y distincin de clases de objetos.
Estos principios son utilizados por el paradigma orientado a objetos precisamente para
facilitar la solucin de problemas y la creacin de modelos.
Pero qu es un sistema orientado a objetos?
En pocas palabras, podemos decir que un sistema orientado a objetos es un sistema
donde sus elementos son entidades a las que denominaremos objetos que interactan
entre s por medio del envo y recepcin de mensajes, todo esto con el fin de cumplir
un objetivo claro y definido para el sistema. Cada uno de estos objetos no funciona en
forma aislada sino que colabora con otros objetos del sistema conversando con los
mismos por medio de mensajes, y cada objeto realiza tareas o cumple un rol
especfico en el sistema acorde a la responsabilidad que tenga asignada.
De este simple enunciado podemos extraer los conceptos fundamentales de la
orientacin a objetos:
Objeto
Mensaje
Colaboracin
Responsabilidad
Analizaremos cada uno de estos elementos
Concepto de Objeto
Definicin 1: Un objeto es algo real o abstracto acerca del cual almacenamos datos y
mtodos que manipulan dichos datos (Martn/Odell)
Definicin 2: Encapsulado de datos, operaciones que tratan dichos datos, y que observa
un estado interno, que posee identidad (se distingue por su existencia misma y no por
sus atributos).
Cada objeto es una instancia de la clase a la que pertenece. Vemos ms adelante el
concepto de Clase.
Qu cosa puede ser considerada un objeto? Muchas. Los objetos representan conceptos
que pertenecen al dominio de problema o al dominio de la solucin.
Un objeto puede representar
- algo fsico: un avin, un libro, una persona
- algo abstracto: una cuenta bancaria, un nmero, una fecha
- algo del dominio del problema: un factura, un cliente
- algo del dominio de la solucin: un formulario, una pgina web.
A.U.S. Gustavo Torossi

Pgina 5 de 12

Diseo de Sistemas

Un error comn es pensar que los objetos son simplemente abstracciones de datos como
las entidades de un modelo entidad-relacin, olvidando que un aspecto esencial de los
objetos es su comportamiento, o sea las operaciones que sabe realizar.
Concepto de Mensaje
Los mensajes son el mecanismo por medio del cual se comunican los objetos para poder
interactuar y colaborar unos con otros.
El envo de mensajes implica que hay un objeto emisor y un objeto receptor del
mensaje. El emisor del mensaje debe conocer al receptor para poder enviarle dicho
mensaje. Esto implica lo que denominaremos una relacin de conocimiento. La
recepcin de un mensaje dispara una o ms operaciones en el objeto receptor.
Se puede enviar mensajes a un objeto con diferentes propsitos:
Para indagar el valor de alguno de sus atributos:
por ej. unaCuenta.obtenerSaldo();
Para asignar un valor a alguno de sus atributos:
por ej: unaCuenta.asignarSaldo(1000);
Para solicitar la realizacin de una operacin:
por ej. unaCuenta.depositar(unValor);
Por otra parte los mensajes pueden ser:
Sincrnicos: cuando el objeto emisor queda al aguardo de una respuesta por parte del
receptor para poder continuar con sus acciones.
Asincrnicos: cuando el objeto emisor luego de emitir el mensaje contina sus acciones
sin aguardar ninguna respuesta.
De tiempo lmite: cuando el objeto emisor queda al aguardo de una respuesta por parte
del receptor para poder continuar con sus acciones, pero solo un tiempo prefijado. Si
luego de dicho perodo de tiempo (time-out) no se tiene respuesta, el objeto emisor
contina con sus acciones.

Concepto de Colaboracin
Una colaboracin se produce cuando dos o ms objetos interactan entre si para realizar
una tarea. Ya que un solo objeto no puede realizar todas las tareas del sistema, estas
deben distribuirse entre los distintos objetos que componen el sistema, y al igual que los
empleados de una empresa deben colaborar unos con otros para poder cumplir con las
tareas asignadas, los objetos deben colaborar entre s para cumplir los propsitos del
sistema. Esta interaccin se lleva a cabo a travs del envo de mensajes. Cuando un
objeto no sabe como realizar una tarea por estar fuera del alcance de su
responsabilidad, delega en otro objeto la realizacin de la misma, solicitando esto por
medio del envo de un mensaje.

A.U.S. Gustavo Torossi

Pgina 6 de 12

Diseo de Sistemas

Concepto de Responsabilidad
Todo objeto tiene definido un rol dentro del sistema tal como lo tiene un empleado en
una organizacin. Se entiende por responsabilidad que cosas conoce el objeto y que
cosas sabe hacer. O sea podemos hablar de responsabilidad de saber y de hacer.
Determinar correctamente la responsabilidad de un objeto es uno de los aspectos
cruciales para abordar a un correcto diseo.
Concepto de Clase
Otro concepto fundamental de la orientacin a objetos es el concepto de clase.
Podemos ver a este concepto desde dos ngulos.
Por una parte, conceptualmente una clase es un grupo de objetos con propiedades
(atributos) similares, comportamiento comn (operaciones), relaciones comunes entre
objetos, y semntica comn (J.Raumbaugh). En este sentido una clase es un poderoso
mecanismo conceptual para agrupar objetos similares en conceptos finitos.
Por otra parte, una clase es una matriz, un molde que se utiliza para crear objetos del
mismo tipo. Esto es fundamentalmente vlido en el caso de los lenguajes orientados a
objetos basados en clases, tal el caso de Smalltalk y Java.

Principios fundamentales
El paradigma de orientacin a objetos especifica cuatro principios fundamentales que
deben observar los lenguajes y ambientes de software para poder ser consideraros
realmente orientados a objetos:
Abstraccin
La abstraccin es un principio segn el cual la mente se enfoca en los aspectos
importantes de un problema y descarta los irrelevantes, para poder tratar con la
complejidad del mismo. La abstraccin es el principio fundamental para poder construir
modelos, y es el mecanismo principal del cerebro para poder trabajar con problemas
complejos.
El principio de abstraccin no es propio de la orientacin a objetos, por el contrario es
un principio esencial a la actividad de desarrollo de software en tanto actividad de
construccin de modelos, independiente del paradigma que se siga. Sin embargo en el
paradigma orientado a objetos la abstraccin toma un carcter especial, diferente a la
forma en que se desarrollan las abstracciones en los enfoques tradicionales. En estos
ltimos, la realidad es modelada como un conjunto de datos que caracterizan a las
entidades que participan en el problema (archivos o tablas), y abstracciones de
comportamiento (programas) que actan sobre dichas abstracciones de datos. En tanto
en la orientacin a objetos tanto datos como comportamiento son abstrados y
encapsulados en una misma unidad denominada objeto.

A.U.S. Gustavo Torossi

Pgina 7 de 12

Diseo de Sistemas

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. El
objeto as solo es conocido y manipulado por la interfase que presenta al medio
ambiente en el cual existe.
Herencia
Es una relacin entre clases de objetos que permite incluir (rehusar) los atributos y
operaciones definidas en otra clase ms general de la cual se hereda o deriva.
Polimorfismo
Polimorfismo es el principio por el cual una misma operacin es resuelta de diferente
forma segn el objeto que recibe el mensaje.
Ms precisamente, polimorfismo es la habilidad de los objetos pertenecientes a
diferentes clases de responder a llamadas a mtodos de mismo nombre, cada uno acorde
a un comportamiento especfico de la clase a la que pertenecen.
Por esto, el programador no necesita conocer el tipo exacto del objeto por anticipado, ya
que el mismo es resuelto en tiempo de ejecucin (esto se llama binding dinmico).

Gua para la fase exploratoria inicial de objetos

Uno de los desafos ms importantes que enfrenta el desarrollador de un sistema
orientado a objetos es precisamente encontrar las clases y objetos correctos para
solucionar el problema. Si bien los principios bsicos del paradigma son sencillos,
encontrar los objetos correctos para nuestro sistema no es una tarea trivial, y de ella
depende en gran medida el xito o fracaso de nuestro sistema.
Veremos en este apartado algunas guas y sugerencias para encontrar objetos para un
sistema:
Identificando Clases
Algunos de los mtodos habituales para descubrir clases de objetos se basan en:
- El conocimiento general del dominio de problema que el desarrollador posea.
- Sistemas anteriores similares en que haya participado el desarrollador, o a cuya
informacin pueda tener acceso.
- Modelos de empresa que puedan analizarse, y que estn en relacin con el
dominio bajo estudio.
- Sesiones de tarjetas CRC. Esta es una tcnica muy comn de modelado de
objetos introducida por Ken Beck y Cunningham, y utilizada por muchos
mtodos como RDD de Wirfs-Brock.
- Glosarios de trminos.
- Anlisis gramatical de enunciados del dominio del problema.
La identificacin de clases comienza con la lectura y comprensin de la especificacin
de requerimientos (caso de uso, historia de usuario), y con la exploracin del dominio
del problema.
A.U.S. Gustavo Torossi

Pgina 8 de 12

Diseo de Sistemas

Se establece una lista de clases candidatas basndose en los sustantivos que se

encuentran. Luego se aplica las siguientes guas a la lista de clases candidatas:
- Modelar objetos fsicos (un cliente, un libro, etc.)
- Modelar entidades conceptuales (una fecha, un evento, etc.)
- Utilizar un trmino simple para cada objeto
- Controlar si los sustantivos calificados por adjetivos difieren de los sustantivos
solos.
- Modelar categoras de objetos (posibles superclases)
Luego de identificar clases, pueden identificarse clases abstractas candidatas agrupando
clases con atributos comunes.
Cada clase identificada puede registrarse con una tarjeta CRC (class-responsabilitycolaboration).
Identificando Responsabilidades
Para las clases identificadas deben determinarse sus responsabilidades. Responsabilidad
es el conocimiento que mantiene un objeto y las acciones que puede realizar.
Responsabilidades candidatas son:
- Verbos extrados de la especificacin de requerimientos.
- Responsabilidades extradas del propsito de las clases.
- Responsabilidades extradas de un recorrido (walk-through) a travs del sistema.
Luego las responsabilidades identificadas deben asignarse a la clase a la cual
pertenecen. Esto puede hacerse siguiendo las siguientes guas:
- Mantener el comportamiento relacionado a cierta informacin en la misma clase.
Si un objeto mantiene determinada informacin, las operaciones que se realizan
sobre dicha informacin deben agregarse a la misma clase.
- Mantener la informacin acerca de una misma cosa en una misma clase o clases
muy relacionadas.
- Distribuir responsabilidades compuestas entre clases relacionadas.
Ms adelante estudiaremos los patrones GRASP que precisamente nos ayudan en la
asignacin de responsabilidades a las clases.
Para encontrar responsabilidades adicionales tres tipos de relaciones son importantes
para examinar:
- relaciones es un tipo de para identificar relaciones compartidas por subclases
- relaciones es anlogo a para identificar superclases y sus responsabilidad
omitidas.
- Relaciones es parte de para identificar responsabilidades que el todo debe
tener con respecto a sus partes.
Las responsabilidades
correspondientes.

identificadas

deben

agregarse

las

tarjetas

CRC

Identificando Colaboraciones
Las clases pueden cumplir sus responsabilidades realizando las operaciones por si solas
o colaborando con otras clases.
A.U.S. Gustavo Torossi

Pgina 9 de 12

Diseo de Sistemas

Para encontrar colaboraciones, realizar las siguientes preguntas por cada clase:
- Es la clase capaz de cumplir sus responsabilidades por si mismo? Si no, de
que otra clase necesita colaboracin?
- Qu otra clase necesita utilizar las responsabilidades de esta clase?
Las clases que no participan en ninguna colaboracin son sospechosas y normalmente
se descartan.
Las colaboraciones identificadas pueden agregarse en las tarjetas CRC.

Estereotipos bsicos de Objetos

Los estereotipos son categoras de clases de objetos que definen aspectos comunes a
grupos de clases de objetos. Si bien pueden existir innumerables estereotipos, Ivar
Jacobson en Objectory propuso la utilizacin de tres estereotipos bsicos que engloban
conceptualmente la generalidad de las clases de objetos que podemos encontrar en una
aplicacin. Estos estereotipos son interfaz o frontera (boundary), entidad (entity), y
control.
Objetos interfaz

Interfaz

Estas clases representan las interfaces del sistema con los usuarios y con otros sistemas
con los que interacta. Deberan contener la menor cantidad de Lgica del Negocio y
limitarse a la lgica correspondiente al dilogo con los actores. Estas clases de objetos
se corresponden con la Vista y el Controlador del patrn MVC.
En los puntos donde los actores inician o se comunican con los casos de uso, 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 descriptos
utilizando clases de objetos interfase (que se corresponde con pantallas, ventanas,
reportes, etc.). Es necesario identificar clases de objetos interfaces cuyos datos son
suministrados a los actores o recibidos desde ellos.
Como heurstica general se crear:
Durante el anlisis, se crear una clase interfaz por cada vnculo caso de uso- actordispositivo. Esta clase representa la interfase principal del vnculo del actor con el
dispositivo. Por ejemplo un supervisor de almacn puede utilizar una interfase GUI para
controlar movimientos de stock y una impresora para imprimir detalles de movimientos.
Para estas actividades se pueden identificar dos objetos interfaz.
La identificacin y diseo de los componentes de esta interfaz, que tambin son objetos
interfaz (ej. botones, cajas de texto, etc.), se difiere hasta el diseo detallado de la
aplicacin.
Tambin, siguiendo el patrn MVC, se puede asignar una clase interfaz (view) para
cada entidad (model) que participa.

A.U.S. Gustavo Torossi

Pgina 10 de 12

Diseo de Sistemas

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.
Se sugiere la siguiente nomenclatura para nominar estas clases: UINombreClase
Objetos Entidad

Estas clases se corresponden con el Modelo del patrn MVC. Estos objetos representan
generalmente la memoria. Encapsulan datos sobre entidades y conceptos del negocio
que deben recordarse, y las reglas del negocio que se aplican a los mismos (ej. Alumno,
Cuenta, Libro, etc.).
En virtud de esto, estas clases requieren de mecanismos de persistencia para almacenar
los datos en algn sistema de almacenamiento, tpicamente mecanismos de mapeo
objeto-relacional para almacenar en bases de datos relacionales.
En la realizacin de los prcticos, se asumir una simplificacin, para lo cual el alumno
se limitar a crear estas clases y simular con constantes los datos que requiriera para
demostrar el programa funcionando.
La nomenclatura utilizada para nominar estas clases ser: ENNombreClase

Objetos de control

Estas clases tienen la funcin primaria de coordinacin del flujo de eventos entre
objetos. No debe confundirse estas clases con la clase Controlador del patrn MVC.
A estas clases tambin se asignan responsabilidades que no son inherentes a alguna
clase entidad o interfaz en particular.
Los objetos de control se vinculan con los actores a travs de objetos interfaz. Los
objetos de control a menudo actan como un conjunto de buffers entre los objetos
entidad y los 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, y se corre el riesgo de caer en un enfoque procedural clsico.
Como lineamiento general, cuando se disee una realizacin de caso de uso, se asigna
una clase de control como coordinadora primaria del flujo de eventos de dicha
realizacin. Esto no es estrictamente necesario, pero es una prctica recomendable.
La nomenclatura utilizada para identificar estas clases ser: CTNombreClase

Como identificar operaciones de objetos

Existen tres posibles maneras de identificar operaciones:
A.U.S. Gustavo Torossi

Pgina 11 de 12

Diseo de Sistemas

- A partir de anlisis de las responsabilidades de cada clase de objetos.

- Identificando las interacciones de objetos requeridas para soportar cada
realizacin de caso de uso.
- Analizando los ciclos de vida de objetos y determinando las operaciones que
ellos implican.

A.U.S. Gustavo Torossi

Pgina 12 de 12