El Enfoque Orientado a Objetos

Introduccin

El desarrollo de sistemas orientados a objeto es nuevo para muchos de nosotros. Ser nuevo en esto supone muchos cambios. Entre ellos est el proceso de planificacin y direccin del proyecto. La mayora de nosotros ha desarrollado proyectos antes. En aquellos proyectos trabajbamos con los usuarios para saber cul era el sistema y cmo era que deban hacerse las cosas. Nosotros disebamos los programas y escribamos las aplicaciones. Entonces, qu tiene de especial la orientacin a objetos?

Uno de los aspectos de la orientacin a objetos es el hecho de que es relativamente nuevo de usar. Debido a esta novedad estamos casi constantemente encontrando barreras de ideas a superar. Este escrito est diseado para exponer uno de los muchos aspectos del desarrollo orientado a objetos, el anlisis y diseo y para ayudarnos a encontrar el sendero en la jungla. El mtodo de anlisis y diseo que vamos a examinar es llamado Enfoque iterativo, toma este nombre porque todo el proceso de desarrollo es logrado a travs de una serie de iteraciones donde cada una abarca el proceso entero para el anlisis a travs de pruebas. Durante cada una de estas iteraciones somos capaces de retroalimentar la informacin de las primeras etapas del proyecto.

Cundo debemos usar un proceso interactivo?

Martin Fowlr, en su libro UML Distilled" (disponible en www.amazon.com), diceDebe utilizar un desarrollo iterativo solo en los casos en que desee obtener xito El no est exagerando. Nadie puede asegurar completamente ninguna fase del ciclo de desarrollo en un simple paso. Estos son simplemente muchos detalles a los que dirigirse en cada etapa de desarrollo. La metodologa puede ser usada tal que no solo permita revisar las etapas anteriores sino que tambin las complemente. La metodologa iterativa es justo eso. Requiere que grandes proyectos sean partidos en pequeas piezas y que cada pieza sea desarrollada mediante un proceso iterativo de anlisis, diseo, implementacin y pruebas.

Por qu hacer iteraciones?

Las iteraciones nos permiten enfocar un subconjunto del proyecto completo de tal forma que lo podemos terminar en detalle. Frecuentemente vamos a descubrir nuevos problemas y requerimientos durante el proceso de creacin de uno de sus subsistemas. Estos nuevos descubrimientos pueden ser fcilmente incorporados en una iteracin posterior sin desechar lo que se ha avanzado hasta entonces.

Este proceso nos permite probar cada subsistema independientemente y asegurar su propia funcionalidad. Esto significa que cuando alcancemos la etapa final del desarrollo - la integracin entre los subsistemas como un todo - podremos concentrarnos en la integracin sabiendo que cada subsistema est ya completamente probado.

Trabajando lo ms temprano posible con los aspectos de alto riesgo para el proyecto, seremos capaces de reducir la influencia de estos riesgos en el cronograma completo del proyecto.

Durante la implementacin de los subsistemas nuevos casos de uso pueden ser descubiertos. Estas situaciones nuevas pueden ser planificadas para la siguiente iteracin.

Qu es el enfoque iterativo?

El enfoque iterativo no es nada nuevo ni revolucionario. Muchos de nosotros hemos creado sistemas por esta va hace mucho tiempo. Martin Fowler clasifica las fases de un proyecto iterativo como Iniciacin, Elaboracin, Construccin y Transicin. Cada una de estas fases constituye un punto diferente en la continuidad del proyecto hasta el final del mismo.

El proyecto comienza con la fase de Iniciacin. Durante esta fase, la que discutiremos con ms detalle ms adelante, vamos a invertir un tiempo explicndonos qu es el proyecto y la mejor idea de cmo hacerlo. Al final de la fase de iniciacin debemos tener una idea bastante acertada del alcance del proyecto. Los detalles no sern obtenidos; pero la visin general del sistema est aqu. En este punto podemos hacer nuestro primer corte del proyecto en piezas. Estas piezas deben estar suficientemente encapsuladas que permitan crearlas independientemente. Cada una de estas piezas satisface un subconjunto de requerimiento del sistema completo.

La mayor ventaja de este mtodo es que puede identificar el riesgo involucrado con el proyecto y tenerlo en cuenta en la direccin del mismo. Esto nos ayuda a evitar, que conociendo todas las cosas que podran ir mal haya que esperar a que empiecen a fallar.

Estos riesgos pueden ser esparcidos por todo el proyecto y continuar tenindolos en cuenta.

Categoras de riesgo

Los riesgos que enfrentamos en el desarrollo del proyecto los podemos dividir en cuatro categoras. Estas categoras son: riesgos de requerimiento, riesgos tecnolgicos, riesgos de habilidades y riesgos polticos. Cualquier proyecto con un alcance relativo tendr algunos riesgos asociados con cada una de estas caractersticas. Ignorar o negar la presencia de estos riesgos significara matar el proyecto. Estos riesgos pueden ser solo superados si no son bien manejados. Manejar los riesgos requiere de conocer cual es el riesgo y tener un plan para lidiar con ellos.

Anlisis Objetos y Diseo Objetos

Anlisis y diseo orientado a objetos (ADOO) es un enfoque de la ingeniera de software que modela un sistema como un grupo de objetos que interactan entre s. Este enfoque representa un dominio en trminos de conceptos compuestos por verbos y sustantivos, clasificados de acuerdo a su dependencia funcional.

En ste mtodo de anlisis y diseo se crea un conjunto de modelos utilizando una notacin acordada como, por ejemplo, el lenguaje nificado de modelado (UML). ADOO aplica tcnicas de modelado de objetos para analizar los requerimientos para un contexto - por ejemplo, un sistema de negocio, un conjunto de mdulos de software - y para disear una solucin para mejorar los procesos involucrados.

No est restringido al diseo de programas de computadora, sino que cubre sistemas enteros de distinto tipo. Las metodologas de anlisis y diseo ms modernas son casos de uso guiados a travs de requerimientos, diseo, implementacin, pruebas, y despliegue.

El lenguaje unificado de modelado se ha vuelto el lenguaje de modelado estndar usado en anlisis y diseo orientado a objetos

Anlisis de la Estructura de Objetos.

El anlisis de la estructura de objetos (AEO) define las categoras de los objetos que percibimos y las formas en que los asociamos.

Objetos y Tipos de Objetos.

En el anlisis se trata de identificar los tipos de objeto ms que los objetos individuales en un sistema. Los tipos de objetos se definen en base a la comprensin del analista de nuestro mundo. Un objeto puede categorizarse de variadas formas.

Representacin para Tipo de Objeto (Persona).

Asociaciones de Objetos.

Es importante modelar la forma como los objetos se asocian entre s. Adems es necesario identificar el significado de la asociacin y la cantidad de objetos con los que un objeto dado puede y debe asociarse (cardinalidad).

Jerarquas de Generalizacin.

Una de las vas de sentido comn por las que el hombre organiza su volumen de conocimiento es el de las jerarquas, de lo ms general a lo ms especfico.

En las jerarquas se habla de subtipo o especializacin de un supertipo o generalizacin. En el caso anterior, persona es el supertipo para Empleado y Estudiante, que son sus subtipos. Por otra parte, Empleado es el supertipo para los subtipos Ejecutivo y Vendedor. Los subtipos (niveles inferiores de la jerarqua) heredan las caractersticas de sus supertipos, adems, cada instancia de un tipo de objeto lo es tambin de sus supertipos.

Jerarquas Compuestas.

Un objeto se denomina complejo si est formado por otros. Las jerarquas Compuestas permiten realizar agregaciones de objetos.

Un objeto del tipo edificio se compone de a lo menos un objeto del tipo piso. A su vez un objeto del tipo piso se compone de a lo menos un objeto del tipo pasillo, podra tener varios (o ninguno) objetos del tipo bao y oficina.

Diagramas de relacin entre los objetos.

Los tipos de objetos estn relacionados con otros tipos de objeto. Por ejemplo, un empleado trabaja en una sucursal, o un cliente realiza un pedido de varios productos.

Un objeto del tipo cliente puede ordenar muchos objetos del tipo pedidos, y un objeto del tipo pedido es ordenado por un y slo un objeto del tipo cliente. Un objeto del tipo producto est en muchos o ningn objeto del tipo pedido, mientras que un objeto del tipo pedido tiene al menos un objeto del tipo producto.

Esquemas de Objetos.

La comprensin de un modelo suele ser ms sencilla si los tipos de objetos y relaciones se presentan mediante un diagrama de relacin entre objetos; los supertipos y subtipos se presentan en un diagrama de jerarquas de generalizacin y las estructuras compuestas en un diagrama compuesto. Sin embargo, para los usuarios ms sofisticados puede ser til presentarlo todo en un mismo diagrama, el que se denomina esquema de objetos.

Ahora que ya sabis todo esto, vamos con os elementos (propiedades) ms importantes de este modelo. Estas son: Abstraccin. Encapsulamiento. Modularidad. Jerarqua. Polimorfismo.

Como sugiere Booch, si alguno de estos elementos no existe se dice que el modelo no es orientado a objetos.

2.1. Abstraccin:

La abstraccin es uno de los medios ms importantes, mediante el cual nos enfrentamos con la complejidad inherente al software. La abstraccin es la propiedad que permite representar las caractersticas esenciales de un objeto, sin preocuparse de las restantes caractersticas (no esenciales). Abstraccin es la tcnica de quitarle a una idea o a un objeto todos los acompaamientos innecesarios hasta que los deja en una forma esencial y mnima. Una buena abstraccin elimina todos los detalles poco importantes y le permite enfocarse y concentrarse en los detalles importantes.

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.

El elemento clave de la programacin orientada a objetos es la clase. 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. Por ejemplo, una pluma estilogrfica es un objeto que tiene un estado (llena de tinta o vaca) y sobre la cual se pueden realizar algunas operaciones (escribir, poner o quitar la tapa, llenar de tinta si est vaca, etc.).

La idea de escribir programas definiendo una serie de abstracciones no es nueva, pero el uso de clases para gestionar dichas abstracciones en lenguajes de programacin ha facilitado considerablemente su aplicacin.

La abstraccin es un principio de software importante. Una clase bien diseada expone un conjunto mnimo de mtodos cuidadosamente considerados que proporcionan el comportamiento esencial de una clase en una forma fcil de usar. Crear buenas abstracciones de software no es fcil. Encontrar buenas abstracciones generalmente requiere de un entendimiento muy claro del problema y de su contexto, gran claridad de pensamiento y amplia experiencia.

Existe un principio muy importante relacionado con la abstraccin, y esta es, la Dependencia mnima. Las mejores abstracciones de software hacen que las cosas complejas sean simples. Logran esto al ocultar por completo los aspectos no esenciales de una clase. Estos aspectos no esenciales, una vez que han sido debidamente ocultados, no se pueden ver, ni usar, ni depender de ellos. Este principio de dependencia mnima es lo que hace que la abstraccin sea tan importante. El cambio es normal en el desarrollo de software. Lo mejor que puede hacer es minimizar el impacto de un cambio cuando ste sucede. Y cuanto menos dependa de algo, menos se ver afectado cuando cambie.

Los lenguajes orientados a objetos proporcionan la Encapsulacin. La encapsulacin se puede utilizar para aplicar el concepto de Abstraccin.

2.2 Encapsulamiento

El Encapsulamiento o encapsulacin es la propiedad que permite asegurar que el contenido de la informacin de un objeto est oculta al mundo exterior: el objeto A no conoce lo que hace el objeto B, y viceversa. La encapsulacin (tambin se conoce como ocultacin de la informacin), en esencia, es el proceso de ocultar todos los secretos de un objeto que no contribuyen a sus caractersticas esenciales.

La encapsulacin permite la divisin de un programa en mdulos. Estos mdulos se implementan mediante clases, de forma que una clase representa la encapsulacin de una abstraccin. En la

prctica, esto significa que cada clase debe tener dos partes: una interfaz y una implementacin. La interfaz de una clase captura slo su vista externa y la implementacin contiene la representacin de la abstraccin, as como los mecanismos que realizan el comportamiento adecuado.

Encapsulacin es la capacidad de contener y controlar el acceso a un grupo de elementos asociados. Las clases proporcionan una de las formas ms comunes para encapsular elementos. En el siguiente ejemplo, la clase Bank Account? encapsula los mtodos, campos y propiedades que se describen en una cuenta bancaria. Sin una encapsulacin, usted necesitara declarar procedimientos y variables por separado para almacenar y administrar informacin para la cuenta bancaria, y sera difcil trabajar con ms de una cuenta bancaria a la vez. La encapsulacin le permite utilizar los datos y procedimientos en la clase Bank Account como una unidad. Usted puede trabajar con varias cuentas bancarias al mismo tiempo sin confusin, debido a que cada cuenta est representada por una instancia nica de la clase.

La encapsulacin tambin le permite controlar la forma en que se utilizan los datos y los procedimientos. Puede utilizar modificadores de acceso, como Private o Protected, para evitar que los procedimientos externos ejecuten mtodos de clase o lean y modifiquen datos en propiedades y campos. Usted debe declarar los detalles internos de una clase como Private para evitar que sean utilizados fuera de su clase; a esta tcnica se le llama ocultamiento de datos. En la clase Bank Account, la informacin del cliente, como el saldo de la cuenta, se protege de esta forma. Una de las reglas bsicas de la encapsulacin es que los datos de la clase slo se pueden modificar o recuperar a travs de los procedimientos o mtodos Property. Ocultar los detalles de implementacin de sus clases evita que se usen de maneras no deseadas, y le permite modificar esos elementos posteriormente sin riesgo de tener problemas de compatibilidad. Por ejemplo, versiones posteriores de la clase Bank Account enlistadas ms adelante, podran cambiar el tipo de datos del campo Account Balance? sin peligro de daar la aplicacin que depende de que este campo tenga un tipo de dato especfico. Class BankAccount Private AccountNumber As String Private AccountBalance As Decimal Private HoldOnAccount As Boolean = False Public Sub PostInterest() ' Add code to calculate the interest for this account. End Sub

ReadOnly Property Balance() As Decimal Get Return AccountBalance 'Returns the available balance. End Get End Property End Class

Modularidad:

La Modularidad es la propiedad que permite subdividir una aplicacin en partes ms pequeas (llamadas mdulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicacin en s y de las restantes partes.

La modularizacin consiste en dividir un programa en mdulos que se puedan compilar por separado, pero que tienen conexiones con otros mdulos. Al igual que la encapsulacin, los lenguajes soportan la Modularidad de diversas formas.

La Modularidad es la propiedad de un sistema que permite su descomposicin en un conjunto de mdulos cohesivos y dbilmente acoplados. Por supuesto no todos los mdulos son iguales: tomar un programa monoltico y separarlo de forma aleatoria en archivos no es ptimo. Se debe tener en cuenta los conceptos asociados de dependencia, acoplamiento, cohesin, interfaz, encapsulacin y abstraccin. Una vez identificado lo que es un buen mdulo, se puede contemplar la reutilizacin de un buen mdulo como componente.

El Mdulo A depende del Mdulo B si cualquier cambio en el Mdulo B implica que el Mdulo A tambin tenga que ser modificado. A veces se dice que el Mdulo A es un cliente del Mdulo B, o que el Mdulo B acta como servidor del Mdulo A. En general, es normal que un mismo mdulo sea tanto cliente como servidor. Esto significa, que depende de algunos mdulos, mientras que otros mdulos dependen de l. Incluso es posible que un par de mdulos se tengan uno al otro de

cliente; sin embargo, ste es un ejemplo de dependencia circular, que debe evitarse cuando sea posible debido a que impide la reutilizacin.

La dependencia a veces se conoce como acoplamiento. Un sistema con muchas dependencias tiene fuerte acoplamiento. Los buenos sistemas tienen dbil acoplamiento, porque en ese caso los cambios en una parte del sistema son menos probables de propagarse a travs del sistema.

Los mdulos correctos a menudo tienen la propiedad de que sus interfaces proporcionan una abstraccin de algn elemento conocido de manera intuitiva que puede, no obstante, ser difcil de implementar. Este tipo de mdulos se dice que tienen una fuerte cohesin. El mdulo realiza un conjunto coherente de cosas, pero dentro de lo posible el desarrollador del cliente est protegido de la informacin irrelevante relativa a cmo el mdulo hace lo que hace.

Resumiendo: Abstraccin es cuando un cliente de un mdulo no necesita saber ms de lo que hay en la interfaz. Encapsulacin es cuando un cliente de un mdulo no es capaz de saber ms de lo que hay en la interfaz.

Si un mdulo, de cualquier tamao y complejidad, es una buena abstraccin (tiene fuerte cohesin y dbil acoplamiento) puede ser factible reutilizarlo en sistemas posteriores, o sustituirlo en el sistema existente.

2.4 Jerarqua

La Jerarqua es una propiedad que permite la ordenacin de las abstracciones. Las dos jerarquas ms importantes de un sistema complejo son: estructura de clases (jerarqua es-un (is-a): generalizacin/especializacin) y estructura de objetos (jerarqua parte-de (part-of): agregacin).

Las jerarquas de generalizacin/especializacin se conocen como herencia. Bsicamente, la herencia define una relacin entre clases, en donde una clase comparte la estructura o comportamiento definido en una o ms clases (herencia simple y herencia mltiple, respectivamente).

La agregacin es el concepto que permite el agrupamiento fsico de estructuras relacionadas lgicamente. As, un camin se compone de ruedas, motor, sistema de transmisin y chasis; en consecuencia, camin es una agregacin, y ruedas, motor, transmisin y chasis son agregados de camin.

2.5 Polimorfismo

La quinta propiedad significativa de los lenguajes de programacin orientados a objetos es el polimorfismo. Es la propiedad que indica, literalmente, la posibilidad de que una entidad tome muchas formas. En trminos prcticos, el polimorfismo permite referirse a objetos de clases diferentes mediante el mismo elemento de programa y realizar la misma operacin de diferentes formas, segn sea el objeto que se referencia en ese momento.

Por ejemplo, cuando se describe la clase mamferos se puede observar que la operacin comer es una operacin fundamental en la vida de los mamferos, de modo que cada tipo de mamfero debe poder realizar la operacin o funcin comer. Por otra parte, una cabra o una vaca que pastan en un campo, un nio que se come un caramelo y un len que devora a otro animal, son diferentes formas que utilizan diferentes mamferos para realizar la misma funcin (comer).

El polimorfismo adquiere su mxima expresin en la derivacin o extensin de clases, es decir, cuando se obtiene una clase a partir de una clase ya existente, mediante la propiedad de derivacin de clases o herencia.

El polimorfismo requiere ligadura tarda o postergada (tambin llamada dinmica), y esto slo se puede producir en lenguajes de programacin orientados a objetos. Los lenguajes no orientados a objetos soportan ligadura temprana o anterior (tambin llamada esttica), esto significa que el compilador genera una llamada a un nombre especfico de funcin y el enlazador (linker) resuelve la llamada a la direccin absoluta del cdigo que se ha de ejecutar. En POO, el programa no puede determinar la direccin del cdigo hasta el momento de la ejecucin. Cuando se enva un mensaje a un objeto, el cdigo que se llama no se determina hasta el momento de la ejecucin. El compilador asegura que la funcin existe y realiza verificacin de tipos de los argumentos y del valor de retorno, pero no conoce el cdigo exacto a ejecutar.

y Cuales son los beneficios? , buena pregunta eh !!!

En resumen, la programacin orientada a objetos beneficia a los desarrolladores debido a que: Los programas son fciles de disear debido a que los objetos reflejan elementos del mundo real. Las aplicaciones son ms sencillas para los usuarios debido a que los datos innecesarios estn ocultos. Los objetos son unidades autocontenidas. La productividad se incrementa debido a que puede reutilizar el cdigo. Los sistemas son fciles de mantener y se adaptan a las cambiantes necesidades de negocios. Es ms fcil crear nuevos tipos de objetos a partir de los ya existentes. Simplifica los datos complejos. Reduce la complejidad de la transaccin. Confiabilidad. Robustez. Capacidad de ampliacin.

2.6 Otras propiedades:

El modelo objeto ideal no slo tiene las propiedades anteriormente citadas sino que es conveniente que soporte, adems, estas otras propiedades:

o Concurrencia (multitarea): el lenguaje soporta la creacin de procesos paralelos independientes del sistema operativo.

Esta propiedad simplificar la transportabilidad de un sistema de tiempo real de una plataforma a otra.

o Persistencia: los objetos deben poder ser persistentes; es decir, los objetos han de poder permanecer despus de la ejecucin del programa

o Genericidad: las clases parametrizadas (mediante plantillas o unidades genricas) sirven para soportar un alto grado de reutilizacin.

Estos elementos genricos se disean con parmetros formales, que se instanciarn con parmetros reales, para crear instancias de mdulos que se compilan y enlazan, y ejecutan posteriormente.

o Manejo de Excepciones: se deben poder detectar, informar y manejar condiciones excepcionales utilizando construcciones del lenguaje. Esta propiedad aadida al soporte de tolerancia a fallos del software permitir una estrategia de diseo eficiente.

3. Taxonoma de lenguajes orientados a objetos

Una taxonoma de lenguajes de programacin con propiedades de orientacin a objetos fue creada por Wegner. La clasificacin incluye los siguientes grupos: Basado en objetos: Un lenguaje de programacin es basado en objetos si su sintaxis y semntica soportan la creacin de objetos que tienen las propiedades descritas en el punto anterior. Por ejemplo: Ada-83, Clipper 5.2, Visual Basic 4/5/6. Basado en clases: Si un lenguaje de programacin es basado en objetos y soporta adems la creacin de clases, se considera basado en clases. Por ejemplo: Clu. Orientacin a objetos: Un lenguaje de programacin orientado a objetos es un lenguaje basado en clases que soporta tambin herencia. Por ejemplo: Visual Basic .NET, C# .NET, C++, Java, Delphi, Eiffel, Simula.

4. Conceptos de orientacin a objetos:

Coad y Yourdon definen el trmino Orientacin a Objetos de la siguiente forma:

Orientacin a Objetos = objetos + clasificacin + herencia + comunicacin

4.1. Clases y Objetos:

Un modelo Orientado a Objetos de software de computadora debe exhibir abstracciones de datos y procedimientos que conducen a una Modularidad eficaz. Una clase es un concepto Orientado a Objetos que encapsula las abstracciones de datos y procedimientos que se requieren para describir el contenido y comportamiento de alguna entidad del mundo real.

Las abstracciones de datos (atributos) que describen la clase estn encerradas por una muralla de abstracciones procedimentales (llamadas operaciones, mtodos o servicios) capaces de manipular los datos de alguna manera. La nica forma de alcanzar los atributos (y operar sobre ellos) es ir a travs de alguno de los mtodos que forman la muralla. Por lo tanto, la clase encapsula datos (dentro de la muralla) y el proceso que manipula los datos (los mtodos que componen la muralla). Esto posibilita la ocultacin de informacin y reduce el impacto de efectos colaterales asociados a cambios.

Nota: Un objeto encapsula datos (atributos) y los mtodos (operaciones, mtodos o servicios) que manipulan esos datos.

4.2 Atributos:

Los atributos estn asociados a clases y objetos, y describen la clase o el objeto de alguna manera. Las entidades de la vida real estn a menudo descritas con palabras que indican caractersticas estables. La mayora de los objetos fsicos tienen caractersticas tales como forma, peso, color y tipo de material. Las personas tienen caractersticas como fecha de nacimiento, padres, nombre y color de los ojos. Una caracterstica puede verse como una relacin binaria entre una clase y cierto dominio.

La relacin binaria implica que un atributo puede tomar un valor definido por un dominio enumerado. En la mayora de los casos, un dominio es simplemente un conjunto de valores

especficos. Por ejemplo, supongamos que una clase Coche tiene un atributo color. El dominio de valores de color es blanco, negro, plata, gris, azul, rojo, amarillo, verde.

Las caractersticas (valores del dominio) pueden aumentarse asignando un valor por defecto (caracterstica) a un atributo. Por ejemplo, el atributo color tiene el valor por defecto negro.

Nota: Los valores asignados a los atributos de un objeto hacen a ese objeto ser nico.

4.3 Operaciones, mtodos y servicios:

Un objeto encapsula datos (representados como una coleccin de atributos) y los algoritmos que procesan estos datos. Estos algoritmos son llamados operaciones, mtodos o servicios y pueden ser vistos como mdulos en un sentido convencional.

Cada uno de los mtodos encapsulados por un objeto proporciona una representacin de uno de los comportamientos del objeto. Por ejemplo, el mtodo Determinar Color? para el objeto Coche extraer el color almacenado en el atributo color. La consecuencia de la existencia de ese mtodo es que la clase coche ha sido diseada para recibir un estmulo (mensaje) que requiere el color de una instancia particular de una clase. Cada vez que un objeto recibe un estmulo, ste inicia un cierto comportamiento, que puede ser tan simple como determinar el color del coche o tan complejo como la iniciacin de una cadena de estmulos que se pasan entre una variedad e objetos diferentes.

Nota: Siempre que un objeto es estimulado por un mensaje, inicia algn comportamiento ejecutando un mtodo.

4.4 Mensajes:

Los mensajes son el medio a travs del cual interactan los objetos. Un mensaje estimula la ocurrencia de cierto comportamiento en el objeto receptor. El comportamiento se realiza cuando se ejecuta un mtodo.

Una operacin dentro de un objeto emisor genera un mensaje de la forma:

destino.operacin (parmetros)

donde destino define al objeto receptor el cual es estimulado por el mensaje, operacin se refiere al mtodo que recibe el mensaje y parmetros proporciona informacin requerida para el xito de la operacin.

Los mensajes proporcionan una visin interna del comportamiento de objetos individuales, y del sistema Orientado a Objetos como un todo.