Introducción a la Orientación a objetos

La orientación a objetos es una técnica de modelado de sistemas, que pueden ser o no

computacionales.
Mediante la orientación a objetos se obtiene una representación del problema en cuestión,
representación cercana a como ocurre en el mundo real. Es decir, estamos rodeados de objetos,
alumno, profesor, escuela, estos objetos a su vez interactúan entre ellos para obtener servicios
unos de otros. En la orientación a objetos se tienen también objetos similares a los de la realidad
que también reciben y solicitan servicios unos de otros. Los objetos que se incluyen en el modelo
dependen del problema que se está modelando, de su alcance, es decir, del “dominio del
problema”.
Doug Rosenberg define el dominio del problema como “el área que abarcan las cosas y
conceptos del mundo real relacionados con el problema que el sistema que se está diseñando
resolverá.” [Rosenberg, 1999]
En teoría, las principales ventajas de los modelos orientados a objetos son:
 “El entendimiento del sistema es más fácil dado que la diferencia semántica entre el
sistema y la realidad es reducida.”
 “Las modificaciones al modelo tienden a ser locales ya que frecuentemente afectan a una
sola entidad, que está representada por un objeto.” [Jacobson, 1992]

Objetos
De manera informal, un objeto representa una entidad ya sea física, conceptual o software. Los
objetos son cosas que tienen información, por ejemplo un auto en particular tiene placa, modelo,
marca, tiene comportamiento, por ejemplo, avanza, retrocede. Los autos son similares entre sí y
pueden agruparse, pertenecen a la clase Autos.

Entidad física: trasbordador

Entidad conceptual: orden de compra

Entidad de software: archivo

Un objeto puede representar algo concreto del dominio del problema como una computadora, un
profesor o un trasbordador espacial. También puede representar un concepto como un proceso
químico, una orden de compra, la historia crediticia, o la tasa de interés.
En los sistemas orientados a objetos, los objetos también pueden representar estructuras de
software tales como listas ligadas, árboles binarios o archivos. Estos objetos no existen en el
mundo real, es decir, no pertenecen al dominio del problema. Pero son creados para facilitar la
implementación.
Formalmente, “un objeto es un concepto que representa una entidad individual, identificable, ya
sea real o abstracta, con un rol bien definido en el dominio del problema” [Smith and Jockey
referenciados por Booch 91], “un objeto tiene límites definidos y tiene: estado, comportamiento
e identidad”
El estado de un objeto es una de las posibles condiciones en las que un objeto puede existir,
normalmente cambia en el tiempo, es implementado por un conjunto de propiedades (atributos),
los valores de éstos, y las relaciones que el objeto puede tener con otros objetos. Por ejemplo
un vuelo puede tener los estados: vacío, abordando o en vuelo.
El comportamiento de un objeto define como actúa y reacciona un objeto, define cómo reacciona
a solicitudes de otros objetos. Es modelado por el conjunto de mensajes a los que puede
responder (operaciones que puede desempeñar). Por ejemplo en una simulación de un juego de
béisbol hay un lanzador y una pelota. El lanzador no “lanza” la pelota, el comportamiento lanzar
del lanzador le pide a la pelota que se mueva. La pelota sabe cómo moverse (con un poco de
ayuda como la velocidad). Movimiento es una propiedad de la bola no del lanzador.
Cada objeto tiene una identidad única, incluso cuando se encuentra en el mismo estado que otro
objeto. [Object- Oriented Modeling and Design, James Rumbaugh, et al., Prentice Hall, 1991, p
22]

Profra. Ho enseña física Profra. Ho enseña física Profr. Ho enseña física

Clases
Según Booch (1994), “una clase es un conjunto de objetos que comparten una estructura y un
comportamiento común. Un objeto es una instancia de una clase”.
Jacobson describe a una clase como “una definición, una plantilla o molde para habilitar la
creación de nuevos objetos y”…” describe la estructura interna de estos objetos. Objetos de la
misma clase tienen la misma definición tanto para sus operaciones como para su estructura de
información “.
Entonces, una clase es una descripción de un grupo de objetos que comparten propiedades
comunes (atributos), comportamiento común (operaciones) y asociaciones con otros objetos.
Por ejemplo, mi auto estacionado frente al edificio es una instancia de la clase auto. La
descripción genérica de “Auto” representa la clase de la cual se crean las instancias. El auto tiene
una estructura: placa, número de motor, marca, modelo; tiene un comportamiento: avanzar,
retroceder, estacionarse. Tiene asociaciones con otros objetos como el Dueño.
Otro ejemplo, la computadora en la cual esté usted trabajando es una instancia de la clase que
describe a todas las computadoras personales, que podría llamarse “Computadora Personal”,
tiene una estructura de información que incluye su marca, velocidad, espacio en disco, memoria,
etc. Tiene comportamientos como encenderse, permanecer en espera, apagarse, bloquearse,
aumentar la memoria, segmentar el disco duro, etc. Tiene asociaciones de agregación con otros
objetos como el ratón o la impresora.

Diferencia entre objeto y clase

Una clase es una definición abstracta de un objeto. La clase define la estructura y el
comportamiento de cada objeto de la clase. Sirve como una plantilla para crear objetos. Los
objetos pueden agruparse en clases.
Por ejemplo, en la siguiente imagen tenemos 4 objetos. ¿Cuántas clases puede distinguir?
Dependiendo del problema del dominio se eligen las clases que convienen. Todas las siguientes
son posibles clases para los objetos anteriores: Animales, Animales Salvajes, Animales
Domésticos, Animales de Granja, Mamíferos, Felinos, Aparatos Electrónicos, Equipo de Cómputo,
Aparatos Domésticos, etc.
Lineamientos para encontrar clases
Identificar adecuadamente las clases de un sistema y asignarles las responsabilidades de forma
correcta es lo más importante de un proyecto de software y de él dependerá su éxito, su
reusabilidad, claridad y mantenibilidad.
Las clases se encuentran en los documentos del proyecto, requerimientos, casos de uso,
entrevistas con el cliente, experiencia en proyectos similares, etc.
De estas fuentes se obtienen los sustantivos relevantes. Después se van eliminando elementos
de la lista siguiendo las siguientes reglas:
Eliminar duplicados
Eliminar sinónimos
Eliminar irrelevantes, ya sea fuera del contexto o sin significado para la aplicación en cuestión.
Eliminar términos vagos
Eliminar los que representan acciones (operaciones)
Eliminar los que representan características (atributos)
Eliminar nombres propios
Eliminar objetos (instancias de las clases)
Eliminar actores o entidades externas
Los términos elegidos deben sustantivos o frases sustantivas que sean pronunciables en
singular.
Es importante mencionar que este es un proceso iterativo y que la primera lista no será la
definitiva, debe regresarse a analizar el enunciado del problema y los documentos que se tengan
a fin de buscar nuevas clases y repetir el ciclo de selección.
Por otro lado, no se debe ser exhaustivo ya que NUNCA se tendrá la lista perfecta y continuar
más de lo debido en esta actividad lleva a lo que se conoce como “análisis parálisis”, unas dos
horas al máximo debe ser suficiente para tener una buena lista que en subsecuentes fases irá
mejorando.
En UML las clases se representan en alguna de las dos siguientes notaciones:
Clase
atributos
operaciones

Clase
Principales propiedades de los objetos
Según Booch (1994), sin las siguientes propiedades el modelo no es orientado a objetos.
Abstracción
La abstracción es la propiedad que permite representar las características esenciales de un
objeto, aquellas relevantes sólo en el dominio del problema excluyendo las no esenciales.
Una abstracción se centra en la vista externa de un objeto, enfocándose en su comportamiento
en vez de en su implementación.
Encapsulamiento
“Toda la información de un objeto está almacenada dentro del mismo objeto y sólo puede ser
manipulada cuando al objeto se le ordena que lleve a cabo alguna operación. El comportamiento
y la información están encapsulados en el objeto. La única forma de realizar operaciones en el
objeto es realizar operaciones en él. Los objetos, entonces soportan el concepto de ocultamiento
de la información, esto es, ocultan su estructura interna de su alrededor. Cada una de las
operaciones del objeto tiene como propósito algún comportamiento del mismo. No se necesita
saber cómo está implementada alguna operación o cómo se representa la información, sólo
necesitamos conocer las operaciones que tiene como interfaz para comunicarnos con él.”
[Jacobson, 1992]
Modularidad [Reyes Paredes, 2006]

Es la propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas
módulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicación
en sí y de las restantes partes (bajo acoplamiento).

El Módulo A depende del Módulo B si cualquier cambio en el Módulo B implica que el Módulo A
también tenga que ser modificado. A veces se dice que el Módulo A es un cliente del Módulo B, o
que el Módulo B actúa como servidor del Módulo A.

La dependencia a veces se conoce como acoplamiento. Un sistema con muchas dependencias

tiene alto acoplamiento. Los buenos sistemas tienen bajo acoplamiento, porque en ese caso los
cambios en una parte del sistema son menos probables de propagarse a través del sistema.

Ejemplos de módulos son clases, operaciones de las clases o paquetes de clases.

Generalización y Herencia

Técnica para permitir a las clases usar los métodos y los datos de una clase padre. Puede tener
muchos niveles. A la clase padre se le conoce también como superclase o clase base, a la clase
hijo se le llama también clase derivada o subclase.
La clase derivada tiene exactamente los mismos atributos y operaciones que la clase base
además de mantener las mismas asociaciones con otras clases que tiene la superclase. Se puede
decir que las subclases son especializaciones de su(s) padre(s).
Facilita el control de cambios y la reutilización.
Polimorfismo
Según Booch (1994), el polimorfismo se define como “Un concepto en la teoría de tipos, acorde
con el cual un nombre (como la declaración de una variable) puede denotar objetos de diferentes
clases que están relacionadas por una superclase común; entonces, cualquier objeto denotado
por este nombre es capaz de responder a un conjunto común de operaciones en diferentes
formas”.
Esto en otras palabras indica que quien solicita un servicio o invoca una operación no necesita
saber la clase a la que pertenece la instancia a quien se lo solicita. Un ejemplo de
implementación de polimorfismo ocurre si tenemos una clase padre llamada Figura a la que le
declaramos una operación llamada calculaArea, Figura tiene dos subclases, Circulo y Rectángulo,
ambas heredan la operación calculaArea, obviamente su implementación es distinta. En alguna
parte del código puede encontrarse la invocación x.calculaArea( ), donde no importa de que tipo
es x, el compilador no lo sabe, no es sino hasta el momento de ejecución que se hará el ligado
dinámico con la implementación correspondiente y se ejecutará el código que corresponda al
tipo.

Otros ejemplos de polimorfismo ocurren cuando un método puede ofrecer diferentes

implementaciones en función de los argumentos que recibe, recibir diferentes números de
parámetros para realizar una misma operación, y realizar diferentes acciones dependiendo del
nivel de abstracción en que sea llamado.

Persistencia
Es la habilidad de un objeto de existir más allá de la terminación del programa que lo creó.
Permite el almacenamiento de datos en términos de objetos, por ejemplo los archivos son
objetos.
Ventajas de la utilizar una metodología orientada a objetos
Los modelos más cercanos al mundo real, por lo que el diseño es más fácil y más rápido.
Los programas y modelos son más fáciles de entender y mantener, más adaptables a
requerimientos cambiantes.
Facilitan reutilización aumentando la productividad
Cambios en los requerimientos no implican cambios masivos en el sistema en desarrollo ya que
los objetos son unidades autocontenidas.
Las aplicaciones son más sencillas para los usuarios debido a que los datos innecesarios están
ocultos.
Es más fácil crear nuevos tipos de objetos a partir de los ya existentes.
Aumentan la confiabilidad.
Son diseños robustos.

Conclusiones
Un sistema debe desarrollarse de forma que abarque la teoría de objetos.
Estos objetos se conocen como objetos del dominio
En conjunto, los objetos constituyen lo que se conoce como modelo del negocio o del dominio
Si el modelo se crea correctamente, el sistema es fácil de mantener.

“The most single important ability in object- oriented analysis and design is to skillfully assign
responsibilities to software components”
“… a close second in terms of importance is finding suitable objects or abstractions”
* Craig Larman - autor of Applying UML & Patterns
Booch, Grady, 1994. Objected-Oriented Analysis And Design With Applications, 2nd Ed., Menlo
Park, CA: Addison-Wesley.
Jacobson, Ivar. et al. 1992. Object Oriented Software Engineering: a Use Case Driven Approach.
Addison Wesley Publishing Company.
Reyes Paredes, Arbis Percy. Conceptos y principios orientado a objetos. Consultado 18 de mayo
de 2006. Tomado de:
http://www.elguille.info/colabora/NET2005/Percynet_Conceptosyprincipiosorientadoaobjetos.htm