PROGRAMACION ORIENTADA A OBJETO

1. CONCEPTOS ORIENTADOS A OBJETOS

La programación orientada a objetos difiere de la programación por procedimientos tradicional,

pues examina los objetos que son parte de un sistema. Cada objeto es una representación

en computadora de alguna cosa o evento real. En esta sección se presentan descripciones

generales de los principales conceptos orientados a objetos de las clases, la herencia y

los objetos,. En secciones posteriores de este mismo capítulo se ofrece más información de

otros conceptos de UML.

OBJETOS

Los objetos son personas, lugares o cosas que son relevantes para el sistema bajo análisis. Los

objetos podrían ser clientes, artículos, pedidos, etc. Los objetos también podrían ser pantallas

GUI o áreas de texto en la pantalla.

CLASES

Los objetos se representan y agrupan en clases que son óptimas para reutilizarse y darles

mantenimiento. Una clase define el conjunto de atributos y comportamientos compartidos

por cada objeto de la clase. Por ejemplo, los registros de los estudiantes en la sección de un

curso almacenan información similar para cada estudiante. Se podría decir que los estudiantes

constituyen una clase. Los valores podrían ser diferentes para cada estudiante, pero el tipo

de información es el mismo. Los programadores deben definir las diversas clases en el programa

que escriben. Cuando el programa corre, los objetos se pueden crear a partir de la

clase establecida. El término instanciar se usa cuando un objeto se crea a partir de una clase.

Por ejemplo, un programa podría instanciar a un estudiante llamado Peter Wellington como

un objeto de la clase denominada estudiante.

Lo que hace a la programación orientada a objetos, y por consiguiente al análisis y diseño

orientado a objetos, diferente de la programación clásica, es la técnica de poner todos los

atributos y métodos de un objeto en una estructura independiente, la propia clase. Ésta es

una situación común en el mundo físico. Por ejemplo, un paquete con harina para pastel

empacado es similar a una clase ya que contiene los ingredientes y las instrucciones para

mezclar y hornear el pastel. Un suéter de lana es similar a una clase porque incluye una etiqueta

con instrucciones del cuidado que advierten que se debe lavarlo a mano y ponerlo a

secar extendido.

Cada clase debe tener un nombre que la distinga de todas las demás. Los nombres de

clase normalmente son sustantivos o frases cortas y empiezan con una letra mayúscula. En

la figura 18.1 la clase se llama RentaAuto. En el UML, una clase se representa como un rectángulo.

El rectángulo contiene otras dos características importantes: una lista de atributos y

una serie de métodos. Estos elementos describen una clase, la unidad de análisis que es una

parte principal de lo que llamamos análisis y diseño orientado a objetos.

Un atributo describe alguna propiedad de todos los objetos de la clase. Observe que la

clase RentaAuto posee los atributos tamaño, color, marca y modelo. Todos los automóviles

poseen estos atributos, pero los atributos de cada automóvil tendrán diferentes valores. Por

ejemplo, un automóvil puede ser azul, blanco o de algún otro color. Más adelante demostraremos

que es posible serrnás específico acerca del rango de valores para estas propiedades.

Al especificar atributos, normalmente la primera letra es minúscula.

Un método es una acción que se puede solicitar a cualquier objeto de la clase. Los

métodos son los procesos que una clase sabe cómo realizar. Los métodos también se llaman

operaciones. La clase RentaAuto podría tener los siguientes métodos: inicioRenta(

), entregaAutof ) y servicio( ). Al especificar métodos, normalmente la primera letra

es minúscula.

HERENCIA

Otro concepto importante de los sistemas orientados a objetos es la herencia. Las clases

pueden tener hijos; es decir, una clase se puede crear a partir de otra clase. En el UML, la

clase original —o madre— se conoce como clase base. La clase hija se denomina clase derivada.

Ésta se puede crear de tal manera que herede todos los atributos y comportamientos

de la clase base. Sin embargo, una clase derivada podría tener atributos y comportamientos

adicionales. Por ejemplo, podría haber una clase Vehículo para una compañía de renta

de automóviles que contenga atributos como tamaño, color y marca. Como se muestra en

la figura 18.2, las clases derivadas podrían ser Automóvil o Camioneta.

La herencia reduce el trabajo de la programación usando fácilmente objetos comunes.

El programador sólo necesita declarar que la clase Automóvil hereda de la clase Vehículo y

después proporcionar cualesquier detalles adicionales sobre nuevos atributos 0 comportamientos

que sean únicos para un automóvil. Todos los atributos y comportamientos de la

clase Vehículo son automática e implícitamente parte de la clase Automóvil y no requieren

ninguna programación adicional. Esto le permite al analista definir una sola vez pero usar

muchas veces y es similar a los datos que están en la tercera forma normal, definidos una sola

vez en una tabla de la base de datos (como se analizó en el capítulo 13).

En la figura 18.2, los atributos son precedidos por signos de resta y los métodos por signos

de suma. Explicaremos esto con mayor detalle más adelante en este capítulo, pero por

ahora tome nota de que los signos de resta significan que estos atributos son privados (no

compartidos con otras clases] y estos métodos son públicos (podrían ser invocados por otras

clases].

La reutilización de código de programa ha sido parte del desarrollo de sistemas y lenguajes

de programación estructurados (como COBOL] durante muchos años y ha habido

subprogramas que encapsulan datos. Sin embargo, la herencia es una característica que sólo

se encuentra en los sistemas orientados a objetos.

2. Dominio del problema

Las tarjetas CRC se pueden crear en forma interactiva con un puñado de analistas que

pueden trabajar en conjunto para identificar la clase en el dominio del problema que tenga

el negocio. Una sugerencia es encontrar todos los sustantivos y verbos en un enunciado

del problema que se ha creado para entender el problema. Normalmente los sustantivos

indican las clases en el sistema y las responsabilidades pueden identificarse mediante los

verbos.

Con su grupo de analistas, realice sesiones de lluvia de ideas para identificar todas las

clases. Siga el formato estándar de la lluvia de ideas, consistente en no criticar las respuestas

de los participantes, sino en estimular tantas respuestas como sea posible. Una vez que se

han identificado todas las clases, los analistas pueden reunirías, eliminar las ilógicas y escribir

cada una en su propia tarjeta. Asigne una clase a cada persona del grupo, quien la "poseerá"

durante la sesión de CRC.

A continuación, el grupo crea escenarios, que en realidad son repasos estructurados de

las funciones del sistema, tomando la funcionalidad deseada del documento de requerimientos

previamente creado. Primero se deben considerar los métodos de sistemas típicos.

Las excepciones, tales como la recuperación de errores, se deberán analizar después de que

se hayan cubierto los métodos rutinarios.

Conforme el grupo decide qué clase es responsable de una función particular, el analista

que posee la clase para la sesión toma esa tarjeta y declara: "Necesito cumplir mi responsabilidad".

Cuando una tarjeta se sostiene en el aire, se considera un objeto y puede realizar

acciones. Entonces el grupo procede a refinar la responsabilidad en tareas más y más pequeñas,

si es posible. Si es conveniente, el objeto puede cumplir estas tareas, o el grupo puede

decidir que se pueden cumplir interactuando con otras cosas. Si no existen otras clases apropiadas,

será necesario que el grupo las genere.

Las cuatro tarjetas CRC descritas en la figura 18.3 muestran cuatro clases para ofertas

de cursos. Observe que en una clase denominada Curso, el analista de sistemas se refiere

a cuatro colaboradores: el departamento, el libro de texto, la tarea del curso y el examen

del curso. A continuación estos colaboradores se describen como clases en las otras tarjetas

CRC.

Posteriormente, las responsabilidades mencionadas se convertirán en lo que en UML se

denomina métodos. Los enunciados del pensamiento del objeto parecen elementales, pero

tienen un tono informal para animar a los grupos de analistas a describir tantos enunciados

como sea posible durante una sesión de CRC. Como se muestra en el ejemplo, todo el diálogo

durante una sesión de CRC se lleva a cabo en primera persona, para que incluso el libro

de texto hable: "Conozco mi ISBN". "Conozco a mi autor". En consecuencia, estos

enunciados se pueden usar para describir los atributos en UML. Estos atributos se pueden

llamar por sus nombres de variables, como edición y editor.

3. Clases

...