SISTEMAS ORIENTADOS A OBJETOS

Vivimos en un mundo de objetos. Estos objetos existen en la naturaleza, en entidades hechas por el hombre, en los negocios y en los productos que usamos. Pueden ser clasificados, descritos, organizados, combinados, manipulados y creados. Por eso no es sorprendente que se proponga una visión orientada a objetos para la creación de software de computadora, una abstracción que modela el mundo de forma tal que nos ayuda a entenderlo y gobernarlo mejor.

La primera vez que se propuso un enfoque orientado a objetos para el desarrollo de software fue a finales de los años sesenta. Sin embargo, las tecnologías de objetos han necesitado casi veinte años para llegar a ser ampliamente usadas. Durante los años 90, la ingeniería del software orientada a objetos se convirtió en el paradigma de elección para muchos productores de software y para un creciente número de sistemas de información y profesionales de la ingeniería.

Las tecnologías de objetos llevan a reutilizar, y la reutilización (de componente de software) lleva a un desarrollo de software más rápido y a programas de mejor calidad. El software orientado a objetos es más fácil de mantener debido a que su estructura es inherentemente poco acoplada. Esto lleva a menores efectos colaterales cuando se deben hacer cambios. Los sistemas orientados a objetos son más fáciles de adaptar y más fácilmente escalables (pueden crearse grandes sistemas ensamblando subsistemas reutilizables).

Hacia mediados de los 80, los beneficios de la programación orientada a objetos empezaron a obtener reconocimiento, y el diseño de objetos pareció ser un enfoque sensato para la gente que deseaba utilizar el lenguaje de programación orientada a objetos. Un enfoque orientado a objetos para programar ofrece muchos beneficios sobre un enfoque estructurado.

El análisis orientado a objetos y su diseño se enfoca en los objetos. Los objetos tienen ciertos comportamientos y atributos que determinan la manera en que interactúan y funcionan. No se intenta proporcionar un orden para las acciones al momento del diseño debido a que los objetos funcionan basados en la manera en que funcionan otros objetos. La programación orientada a objetos ayuda a los desarrolladores a crear objetos que reflejan escenarios del mundo real.

Las implementaciones orientadas a objetos ocultan datos, lo cual significa que muestran únicamente los comportamientos a los usuarios y ocultan el código subyacente de un objeto. Los comportamientos que el programador expone son únicamente aquellos elementos que el usuario de un objeto puede afectar.

El enfoque orientado a objetos permite que los objetos estén autocontenidos. Los objetos existen por sí mismos, con una funcionalidad para invocar comportamientos de otros objetos. Al utilizar un enfoque orientado a objetos, los desarrolladores pueden crear aplicaciones que reflejan objetos del mundo real, como rectángulos, elipses y triángulos, además de dinero, números de partes y elementos en un inventario.

En un enfoque orientado a objetos, los objetos, por definición, son modulares en su construcción. Esto quiere decir que son entidades completas y, por lo tanto, tienden a ser altamente reutilizables. Las aplicaciones orientadas a objetos se construyen sobre el paradigma de los mensajes o de los eventos en donde los objetos envían mensajes a otros objetos, como el sistema operativo Microsoft® Windows®.

1. El paradigma orientado a objetos

Durante muchos años el término Orientado a Objetos (OO) se usó para referirse a un enfoque de desarrollo de software que usaba uno de los lenguajes orientados a objetos (Ada 95, C++, Eiffel, Smalltalk, etc.). En el libro The Structure of Scientific Revolutions, el historiador Thomas K describía un paradigma como un conjunto de teorías, estándar y métodos que juntos representan un medio de organización del conocimiento: es decir, un medio de visualizar el mundo. En este sentido, la programación orientada a objetos es un nuevo paradigma. La orientación a objetos fuerza a reconsiderar nuestro pensamiento sobre la computación, sobre lo que significa realizar computación y sobre cómo se estructura la información dentro de la computadora.

Jenkins y Glasgow observan que “la mayoría de los programadores trabajan en un lenguaje y utilizan sólo un estilo de programación. Ellos programan en un paradigma forzado por el lenguaje que utilizan. Con frecuencia, no se enfrentan a métodos alternativos de resolución de un problema, y por consiguiente tienen dificultad en ver la ventaja de elegir un estilo más apropiado al problema a manejar”. Bobrow y Stefik sugieren que existen cuatro clases de estilos de programación:

Orientados a procedimientos:Algoritmos.

Orientados a objetos:Clases y Objetos.

Orientados a lógica:Expresado en cálculo de predicados.

Orientados a reglas: Reglas if-then.

No existe ningún estilo de programación idóneo para todas las clases de programación. La orientación a objetos se acopla a la simulación de situaciones del mundo real.

2. Orientación a Objetos

La orientación a objetos puede describirse como el conjunto de disciplinas que desarrollan y modelizan software que facilitan la construcción de sistemas complejos a partir de componentes.

El atractivo intuitivo de la orientación a objetos es que proporciona conceptos y herramientas con las cuales se modela y representa el mundo real tan fielmente como sea posible. Estos conceptos y herramientas orientados a objetos son tecnologías que permiten que los problemas del mundo real sean expresados de modo fácil y natural.

Las técnicas orientadas a objetos proporcionan mejoras y metodologías para construir sistemas de software complejos a partir de unidades de software modularizado y reutilizable. Se necesita un nuevo enfoque para construir software en la actualidad. Este nuevo enfoque debe ser capaz de manipular tanto sistemas grandes como pequeños y debe crear sistemas fiables que sean flexibles, mantenibles y capaces de evolucionar para cumplir las necesidades del cambio.

La orientación a objetos trata de cubrir las necesidades de los usuarios finales, así como las propias de los desarrolladores de productos software. Estas tareas se realizan mediante la modelización del mundo real. El soporte fundamental es el modelo objeto.

Un objeto es la instancia de una clase. Una clase es la representación abstracta de un concepto en el mundo real, y proporciona la base a partir de la cual creamos instancias de objetos específicos. Como ejemplo, puede crear una clase que defina a un cliente. Después puede crear una nueva instancia de la clase cliente para tener un objeto utilizable de Cliente. Para poder crear un objeto de la clase cliente, debe crear una nueva instancia basada en esa clase. Por ejemplo:

Private ObjetoCustomer as ClaseCustomer

ObjetoCustomer = New ClaseCustomer()

Cada objeto es un elemento único de la clase en la que se basa. Si una clase es como un molde, entonces un objeto es lo que se crea a partir del molde. La clase es la definición de un elemento; el objeto es el elemento. El molde para una figura de cerámica en particular, es como una clase; la figura es el objeto.

Todos los objetos están compuestos de tres cosas:

Interfaz
La Interfaz es el conjunto de métodos, propiedades, eventos y atributos que se declaran como públicos en su alcance y que pueden invocar los programas escritos para usar nuestro objeto.

Implementación
Al código dentro de los métodos se le llama Implementación. Algunas veces también se le llama comportamiento, ya que este código es el que efectivamente logra que el objeto haga un trabajo útil. Es importante entender que las aplicaciones del cliente pueden utilizar nuestro objeto aunque cambiemos la implementación, siempre que no cambiemos la interfaz. Siempre que se mantengan sin cambio nuestro nombre de método, su lista de parámetro y el tipo de datos de devolución, podremos cambiar la implementación totalmente.

Estado
El estado o los datos de un objeto es lo que lo hace diferente de otros objetos de la misma clase. El estado se describe a través de las variables del Miembro o de la Instancia. Las variables del miembro son aquellas declaradas, de tal manera que están disponibles para todo el código dentro de la clase. Por lo general, las variables del miembro son Privadas en su alcance. Algunas veces, se les conoce como variables de la instancia o como atributos. Observe que las propiedades no son variables del Miembro, ya que son un tipo de método que funciona para recuperar y establecer valores.

¿Qué es una clase?

Una clase es esencialmente un proyecto, a partir del cual puede crear objetos. Una clase define las características de un objeto, incluyendo las propiedades que definen los tipos de datos que ese objeto puede contener y los métodos que describen el comportamiento del objeto. Estas características determinan la manera en que otros objetos pueden acceder y trabajar con los datos que se incluyen en el objeto.

Para definir una clase, se coloca la palabra clave Class antes del nombre de su clase, y después se insertan los miembros de la clase (datos y métodos) entre la definición del nombre de la clase y la instrucción End Class. Si incluye los métodos, entonces el código de cada método también se debe incluir entre la declaración del método y el final del mismo.

Por ejemplo, si desea construir objetos que representen perros, puede definir una clase Perro con ciertos comportamientos, como caminar, ladrar y comer, y propiedades específicas, como altura, peso y color. Una vez que haya definido la clase Perro, puede crear objetos con base en esa clase. Es importante observar que todos los objetos Perro creados con base en la clase perro compartirán los mismos comportamientos, pero tendrán sus propios valores específicos para el mismo conjunto de propiedades.

El siguiente ejemplo representa la definición de la clase Perro. Tome en consideración que ésta no es una sintaxis estricta de VB.NET; simplemente es un ejemplo de la definición de clase.

Public Class Perro

    Dim Altura As Decimal

    Dim Peso As Decimal

    Dim Color As String

    Sub Caminar(ByVal Pasos As Integer)

    End Sub

    Sub Ladrar()

    End Sub

    Sub Comer()

    End Sub

End Class

Vamos con otro ejemplo. El siguiente ejemplo define una nueva clase, Persona, con dos partes de información relevante asociadas: el nombre de la persona, su fecha de nacimiento y un Método que calcula la edad de la persona. A pesar de que la clase Persona se define en el ejemplo, no existe aún el objeto Persona. Deberán ser creados.

Public Class Persona

    Private mstrNombre As String

    Private mdtFechaNacimiento As Date

    Public Function Edad() As Integer

        Return DateDiff(DateInterval.Year, mdtFechaNacimiento, Now())

    End Function

End Class

Una clase es un tipo definido por el usuario en contraposición a un tipo proporcionado por el sistema. Al definir una clase, en realidad crea un nuevo tipo en su aplicación.

Ahora que ya sabéis todo esto, vamos con los elementos (propiedades) más importantes de este modelo. Estas son:

Abstracción.

Encapsulamiento.

Modularidad.

Jerarquía.

Polimorfismo.

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

Abstracción:

La abstracción es uno de los medios más importantes, mediante el cual nos enfrentamos con la complejidad inherente al software. La abstracción es la propiedad que permite representar las características esenciales de un objeto, sin preocuparse de las restantes características (no esenciales). Abstracción es la técnica de quitarle a una idea o a un objeto todos los acompañamientos innecesarios hasta que los deja en una forma esencial y mínima. Una buena abstracción elimina todos los detalles poco importantes y le permite enfocarse y concentrarse en los detalles importantes.

Una abstracción se centra en la vista externa de un objeto, de modo que sirva para separar el comportamiento esencial de un objeto de su implementación. Definir una abstracción significa describir una entidad del mundo real, no importa lo compleja que pueda ser y, a continuación, utilizar esta descripción en un programa.

El elemento clave de la programación orientada a objetos es la clase. Una clase se puede definir como una descripción abstracta de un grupo de objetos, cada uno de los cuales se diferencia por su estado específico y por la posibilidad de realizar una serie de operaciones. Por ejemplo, una pluma estilográfica es un objeto que tiene un estado (llena de tinta o vacía) y sobre la cual se pueden realizar algunas operaciones (escribir, poner o quitar la tapa, llenar de tinta si está vacía, 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 programación ha facilitado considerablemente su aplicación.

La abstracción es un principio de software importante. Una clase bien diseñada expone un conjunto mínimo de métodos cuidadosamente considerados que proporcionan el comportamiento esencial de una clase en una forma fácil de usar. Crear buenas abstracciones de software no es fácil. 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 abstracción, y esta es, la Dependencia mínima. 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 mínima es lo que hace que la abstracción 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 Encapsulación. La encapsulación se puede utilizar para aplicar el concepto de Abstracción.

Encapsulamiento

El Encapsulamiento o encapsulación es la propiedad que permite asegurar que el contenido de la información de un objeto está oculta al mundo exterior: el objeto A no conoce lo que hace el objeto B, y viceversa. La encapsulación (también se conoce como ocultación de la información), en esencia, es el proceso de ocultar todos los secretos de un objeto que no contribuyen a sus características esenciales.

La encapsulación permite la división de un programa en módulos. Estos módulos se implementan mediante clases, de forma que una clase representa la encapsulación de una abstracción. En la práctica, esto significa que cada clase debe tener dos partes: una interfaz y una implementación. La interfaz de una clase captura sólo su vista externa y la implementación contiene la representación de la abstracción, así como los mecanismos que realizan el comportamiento adecuado.

Encapsulación es la capacidad de contener y controlar el acceso a un grupo de elementos asociados. Las clases proporcionan una de las formas más comunes para encapsular elementos. En el siguiente ejemplo, la clase BankAccount encapsula los métodos, campos y propiedades que se describen en una cuenta bancaria. Sin una encapsulación, usted necesitaría declarar procedimientos y variables por separado para almacenar y administrar información para la cuenta bancaria, y sería difícil trabajar con más de una cuenta bancaria a la vez. La encapsulación le permite utilizar los datos y procedimientos en la clase BankAccount como una unidad. Usted puede trabajar con varias cuentas bancarias al mismo tiempo sin confusión, debido a que cada cuenta está representada por una instancia única de la clase.

La encapsulación también 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 métodos 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 técnica se le llama ocultamiento de datos. En la clase BankAccount, la información del cliente, como el saldo de la cuenta, se protege de esta forma. Una de las reglas básicas de la encapsulación es que los datos de la clase sólo se pueden modificar o recuperar a través de los procedimientos o métodos Property. Ocultar los detalles de implementación 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 BankAccount enlistadas más adelante, podrían cambiar el tipo de datos del campo AccountBalance sin peligro de dañar la aplicación que depende de que este campo tenga un tipo de dato específico.

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 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.

La modularización consiste en dividir un programa en módulos que se puedan compilar por separado, pero que tienen conexiones con otros módulos. Al igual que la encapsulación, los lenguajes soportan la Modularidad de diversas formas.

La Modularidad es la propiedad de un sistema que permite su descomposición en un conjunto de módulos cohesivos y débilmente acoplados. Por supuesto no todos los módulos son iguales: tomar un programa monolítico y separarlo de forma aleatoria en archivos no es óptimo. Se debe tener en cuenta los conceptos asociados de dependencia, acoplamiento, cohesión, interfaz, encapsulación y abstracción. Una vez identificado lo que es un buen módulo, se puede contemplar la reutilización de un buen módulo como componente.

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. En general, es normal que un mismo módulo sea tanto cliente como servidor. Esto significa, que depende de algunos módulos, mientras que otros módulos dependen de él. Incluso es posible que un par de módulos 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 reutilización.

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

Los módulos correctos a menudo tienen la propiedad de que sus interfaces proporcionan una abstracción de algún elemento conocido de manera intuitiva que puede, no obstante, ser difícil de implementar. Este tipo de módulos se dice que tienen una fuerte cohesión. El módulo realiza un conjunto coherente de cosas, pero dentro de lo posible el desarrollador del cliente está protegido de la información irrelevante relativa a cómo el módulo hace lo que hace.

Resumiendo: Abstracción es cuando un cliente de un módulo no necesita saber más de lo que hay en la interfaz. Encapsulación es cuando un cliente de un módulo no es capaz de saber más de lo que hay en la interfaz.

Si un módulo, de cualquier tamaño y complejidad, es una buena abstracción (tiene fuerte cohesión y débil acoplamiento) puede ser factible reutilizarlo en sistemas posteriores, o sustituirlo en el sistema existente.

Jerarquía

La Jerarquía es una propiedad que permite la ordenación de las abstracciones. Las dos jerarquías más importantes de un sistema complejo son: estructura de clases (jerarquía “es-un” (is-a): generalización/especialización) y estructura de objetos (jerarquía “parte-de” (part-of): agregación).

Las jerarquías de generalización/especialización se conocen como herencia. Básicamente, la herencia define una relación entre clases, en donde una clase comparte la estructura o comportamiento definido en una o más clases (herencia simple y herencia múltiple, respectivamente).

La agregación es el concepto que permite el agrupamiento físico de estructuras relacionadas lógicamente. Así, un camión se compone de ruedas, motor, sistema de transmisión y chasis; en consecuencia, camión es una agregación, y ruedas, motor, transmisión y chasis son agregados de camión.

Polimorfismo

La quinta propiedad significativa de los lenguajes de programación orientados a objetos es el polimorfismo. Es la propiedad que indica, literalmente, la posibilidad de que una entidad tome muchas formas. En términos prácticos, el polimorfismo permite referirse a objetos de clases diferentes mediante el mismo elemento de programa y realizar la misma operación de diferentes formas, según sea el objeto que se referencia en ese momento.

Por ejemplo, cuando se describe la clase mamíferos se puede observar que la operación comer es una operación fundamental en la vida de los mamíferos, de modo que cada tipo de mamífero debe poder realizar la operación o función comer. Por otra parte, una cabra o una vaca que pastan en un campo, un niño que se come un caramelo y un león que devora a otro animal, son diferentes formas que utilizan diferentes mamíferos para realizar la misma función (comer).

El polimorfismo adquiere su máxima expresión en la derivación o extensión de clases, es decir, cuando se obtiene una clase a partir de una clase ya existente, mediante la propiedad de derivación de clases o herencia.

El polimorfismo requiere ligadura tardía o postergada (también llamada dinámica), y esto sólo se puede producir en lenguajes de programación orientados a objetos. Los lenguajes no orientados a objetos soportan ligadura temprana o anterior (también llamada estática), esto significa que el compilador genera una llamada a un nombre específico de función y el enlazador (linker) resuelve la llamada a la dirección absoluta del código que se ha de ejecutar. En POO, el programa no puede determinar la dirección del código hasta el momento de la ejecución. Cuando se envía un mensaje a un objeto, el código que se llama no se determina hasta el momento de la ejecución. El compilador asegura que la función existe y realiza verificación de tipos de los argumentos y del valor de retorno, pero no conoce el código exacto a ejecutar.

y ¿Cuales son los beneficios?

En resumen, la programación orientada a objetos beneficia a los desarrolladores debido a que:

Los programas son fáciles de diseñar debido a que los objetos reflejan elementos del mundo real.

Las aplicaciones son más sencillas para los usuarios debido a que los datos innecesarios están ocultos.

Los objetos son unidades autocontenidas.

La productividad se incrementa debido a que puede reutilizar el código.

Los sistemas son fáciles de mantener y se adaptan a las cambiantes necesidades de negocios.

Es más fácil crear nuevos tipos de objetos a partir de los ya existentes.

Simplifica los datos complejos.

Reduce la complejidad de la transacción.

Confiabilidad.

Robustez.

Capacidad de ampliación.

Otras propiedades:

El modelo objeto ideal no sólo tiene las propiedades anteriormente citadas sino que es conveniente que soporte, además, estas otras propiedades:

Concurrencia (multitarea): el lenguaje soporta la creación de procesos paralelos independientes del sistema operativo. Esta propiedad simplificará la transportabilidad de un sistema de tiempo real de una plataforma a otra.

Persistencia: los objetos deben poder ser persistentes; es decir, los objetos han de poder permanecer después de la ejecución del programa

Genericidad: las clases parametrizadas (mediante plantillas o unidades genéricas) sirven para soportar un alto grado de reutilización. Estos elementos genéricos se diseñan con parámetros formales, que se instanciarán con parámetros reales, para crear instancias de módulos que se compilan y enlazan, y ejecutan posteriormente.

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

3. Taxonomía de lenguajes orientados a objetos

Una taxonomía de lenguajes de programación con propiedades de orientación a objetos fue creada por Wegner. La clasificación incluye los siguientes grupos:

Basado en objetos: Un lenguaje de programación es basado en objetos si su sintaxis y semántica soportan la creación 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 programación es basado en objetos y soporta además la creación de clases, se considera basado en clases. Por ejemplo: Clu.

Orientación a objetos: Un lenguaje de programación orientado a objetos es un lenguaje basado en clases que soporta también herencia. Por ejemplo: Visual Basic .NET, C# .NET, C++, Java, Delphi, Eiffel, Simula.

4. Conceptos de orientación a objetos:

Coad y Yourdon definen el término Orientación a Objetos de la siguiente forma:

Orientación a Objetos = objetos + clasificación + herencia + comunicación

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 están encerradas por una “muralla” de abstracciones procedimentales (llamadas operaciones, métodos o servicios) capaces de manipular los datos de alguna manera. La única forma de alcanzar los atributos (y operar sobre ellos) es ir a través de alguno de los métodos que forman la muralla. Por lo tanto, la clase encapsula datos (dentro de la muralla) y el proceso que manipula los datos (los métodos que componen la muralla). Esto posibilita la ocultación de información y reduce el impacto de efectos colaterales asociados a cambios.

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

Atributos:

Los atributos están asociados a clases y objetos, y describen la clase o el objeto de alguna manera. Las entidades de la vida real están a menudo descritas con palabras que indican características estables. La mayoría de los objetos físicos tienen características tales como forma, peso, color y tipo de material. Las personas tienen características como fecha de nacimiento, padres, nombre y color de los ojos. Una característica puede verse como una relación binaria entre una clase y cierto dominio.

La “relación” binaria implica que un atributo puede tomar un valor definido por un dominio enumerado. En la mayoría de los casos, un dominio es simplemente un conjunto de valores específicos. 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 características (valores del dominio) pueden aumentarse asignando un valor por defecto (característica) a un atributo. Por ejemplo, el atributo color tiene el valor por defecto negro.

Operaciones, métodos y servicios:

Un objeto encapsula datos (representados como una colección de atributos) y los algoritmos que procesan estos datos. Estos algoritmos son llamados operaciones, métodos o servicios y pueden ser vistos como módulos en un sentido convencional.

Cada uno de los métodos encapsulados por un objeto proporciona una representación de uno de los comportamientos del objeto. Por ejemplo, el método DeterminarColor para el objeto Coche extraerá el color almacenado en el atributo color. La consecuencia de la existencia de ese método es que la clase coche ha sido diseñada para recibir un estímulo (mensaje) que requiere el color de una instancia particular de una clase. Cada vez que un objeto recibe un estímulo, éste inicia un cierto comportamiento, que puede ser tan simple como determinar el color del coche o tan complejo como la iniciación de una cadena de estímulos que se pasan entre una variedad e objetos diferentes.

Mensajes:

Los mensajes son el medio a través del cual interactúan los objetos. Un mensaje estimula la ocurrencia de cierto comportamiento en el objeto receptor. El comportamiento se realiza cuando se ejecuta un método.

Una operación dentro de un objeto emisor genera un mensaje de la forma:

destino.operación (parámetros) donde destino define al objeto receptor el cual es estimulado por el mensaje, operación se refiere al método que recibe el mensaje y parámetros proporciona información requerida para el éxito de la operación.

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

IDENTIFICACIÓN DE UN MODELO DE OBJETOS

Hay muchas formas de enfocar un problema utilizando una solución basada en el software. Un enfoque muy utilizado es la visión orientada a objetos. El dominio del problema se caracteriza mediante un conjunto de objetos con atributos y comportamientos específicos. Los objetos son manipulados mediante una colección de funciones (llamadas métodos, operaciones o servicios) y se comunican entre ellos mediante un protocolo de mensajes. Los objetos se clasifican mediante clases y subclases.

La definición de objetos implica la descripción de atributos, comportamientos, operaciones y mensajes. Un objeto encapsula tanto datos como los procesos que se aplican a esos datos. Esta importante característica permite construir clases de objetos e inherentemente construir bibliotecas de objetos y clases reutilizables. El paradigma de orientación a objetos es tan atractivo para tantas organizaciones de desarrollo de software debido a que la reutilización es un atributo importantísimo en la ingeniería del software. Además, los componentes de software derivados mediante el paradigma de objetos muestran características (como la independencia funcional, la ocultación de información, etc.) asociadas con el software de alta calidad.

Los elementos de un modelo de objetos – clases y objetos, atributos, operaciones y mensajes – deben ser identificados en un problema real. A continuación se presentan una serie de directrices informales que servirán de apoyo en la identificación de los elementos de un modelo de objetos.

Identificación de clases y objetos

Si se observa alrededor en una habitación, existen un conjunto de objetos físicos que pueden ser fácilmente identificados, clasificados y definidos (en términos de atributos y operaciones). Pero cuando se “observa” el espacio de un problema en una aplicación de software, los objetos pueden ser más difíciles de identificar.

Se puede empezar a identificar objetos examinando el planteamiento del problema o realizando un “análisis sintáctico gramatical” en la narrativa del sistema que se va a construir. Los objetos se determinan subrayando cada nombre o cláusula nominal e introduciéndola en una tabla simple.

Los sinónimos deben destacarse. Si se requiere del objeto que implemente una solución, entonces éste formará parte del espacio de solución; en caso de que el objeto se necesite solamente para describir una solución, éste forma parte del espacio del problema. Los objetos se manifiestan de alguna de las formas siguientes:

Entidades Externas que producen o consumen información a usar por un sistema computacional. Por ejemplo: otros sistemas, dispositivos, personas.

Cosas que son parte del dominio de información del problema. Por ejemplo: informes, presentaciones, cartas, señales.

Ocurrencias o Sucesos que ocurren dentro del contexto de una operación del sistema. Por ejemplo: una transferencia de propiedad o la terminación de una serie de movimientos en un robot.

Papeles o Roles desempeñados por personas que interactúan con el sistema. Por ejemplo: director, ingeniero, vendedor.

Unidades Organizacionales que son relevantes en una aplicación. Por ejemplo: división, grupo, equipo.

Lugares que establecen el contexto del problema y la función general del sistema. Por ejemplo: planta de producción o muelle de carga.

Estructuras que definen una clase de objetos o, en casos extremos, clases relacionadas de objetos. Por ejemplo: sensores, vehículos de cuatro ruedas o computadoras.

La clasificación mostrada es una de las muchas que se han propuesto en la literatura.También es importante destacar qué no son los objetos. En general, un objeto nunca debe tener un “nombre procedimental imperativo”. Por ejemplo, si los desarrolladores de un software para un sistema gráfico médico definieron un objeto con el nombre inversión de imagen, estarían cometiendo un sutil error. La imagen obtenida por el software pudiera ser, en efecto, un objeto (es un elemento que forma parte del dominio de información), pero la inversión de la imagen es una operación que se aplica a dicho objeto. Inversión debe definirse como una operación del objeto imagen, pero no como un objeto separado que signifique “inversión de imagen”. Como establecen algunos autores, “… el objetivo de la orientación a objetos es encapsular, pero manteniendo separados los datos y las operaciones sobre estos datos”.

Para ilustrar cómo pueden definirse los objetos se presenta la narrativa de procesamiento para el sistema Hogar Seguro:

El software Hogar Seguro le permite al propietario de la casa configurar el sistema de seguridad una vez que este se instala, controla todos los sensores conectados al sistema de seguridad, e interactúa con el propietario a través de un teclado numérico y teclas de función contenidas en el panel de control de Hogar Seguro.

Durante la instalación, el panel de control de Hogar Seguro se usa para “programar” y configurar el sistema. A cada sensor se le asigna un número y tipo, se programa una contraseña maestra para activar y desactivar el sistema, y se introducen números de teléfono a marcar cuando un sensor detecte un suceso.

Cuando se reconoce un suceso de sensor, el software invoca una alarma audible asociada al sistema. Después de un tiempo de espera especificado por el propietario durante las actividades de configuración del sistema, el software marca un número de teléfono de un servicio de control, proporciona información acerca de la localización, e informa de la naturaleza del suceso detectado. El número será remarcado cada 20 segundos hasta obtener una conexión telefónica.

Toda la interacción con Hogar Seguro está gestionada por un subsistema de interacción con el usuario que toma la entrada a partir del teclado numérico y teclas de función, y muestra mensajes y el estado del sistema en la pantalla LCD.

La interacción con el teclado toma la siguiente forma…Extrayendo los nombres pueden proponerse varios objetos potenciales:

La lista anterior debe ser continuada hasta que se hayan considerado todos los nombres de la descripción del proceso. Observe que se ha llamado a cada entrada en la lista un objeto potencial. Se debe considerar cada uno de ellos antes de tomar una decisión final.

Coud y Yourdon sugieren seis características de selección a usar cada vez que un analista considera si incluye o no un objeto potencial en el modelo de análisis:

Información retenida el objeto potencial será de utilidad durante el análisis solamente si la información acerca de él debe recordarse para que el sistema funciones.

Servicios necesarios el objeto potencial debe poseer un conjunto de operaciones identificables que pueden cambiar de alguna manera el valor de sus atributos.

Atributos múltiples durante el análisis de requisitos, se debe centrar la atención en la información principal (un objeto con un solo atributo puede, en efecto, ser útil durante el diseño, pero seguramente será mejor presentado como un atributo de otro objeto durante la actividad de análisis).

Atributos comunes puede definirse un conjunto de atributos para el objeto potencial, los cuales son aplicables a todas las ocurrencias del objeto.

Operaciones comunes puede definirse un conjunto de operaciones para el objeto potencial, las cuales son aplicables a todas las ocurrencias del objeto.

Requisitos esenciales entidades externas que aparecen en el espacio del problema y producen o consumen información esencial para la producción de cualquier solución para el sistema, serán casi siempre definidas como objetos en el modelo de requisitos.

Para ser considerado un objeto válido a incluir en el modelo de requisitos, un objeto potencial debe satisfacer todas (o casi todas) las características anteriores. La decisión de incluir objetos potenciales en el modelo de análisis es algo subjetivo, y una evaluación posterior puede llegar a descartar un objeto o reincluirlo. Sin embargo, el primer paso del Análisis Orientado a Objetos debe ser la definición de objetos, y la consiguiente toma de decisiones (incluso subjetivas).

Teniendo esto en cuenta, se aplicarán las características selectivas a la lista de objetos potenciales de Hogar Seguro:

Debe tenerse en cuenta que: (1) la lista anterior no incluye todo, hay que añadir objetos adicionales para completar el modelo; (2) algunos de los objetos potenciales rechazados serán atributos de los objetos aceptados (por ejemplo, número y tipo son atributos de sensor, y contraseña maestra y número de teléfono pueden convertirse en atributos de sistema); y (3) diferentes descripciones del problema pueden provocar la toma de diferentes decisiones de “aceptación o rechazo” (por ejemplo, si cada propietario tiene su propia contraseña o fue identificado por impresiones de voz, el objeto Propietario cumpliría las características a y b y habría sido aceptado).

Especificación de atributos

Los atributos describen un objeto que ha sido seleccionado para ser incluido en el modelo de análisis. En esencia, son los atributos los que definen al objeto, los que clarifican lo que representa el objeto en el contexto del espacio del problema. Por ejemplo, si se tratara de construir un sistema de estadísticas para jugadores profesionales de béisbol, los atributos del objeto Jugador serían muy diferentes de los atributos del mismo objeto cuando se use dentro del contexto de un sistema de pensiones para jugadores profesionales. En el primero, atributos tales como nombre, posición, promedio de bateo, porcentaje de estancia en el campo de juego, años jugados y partidos jugados pueden ser relevantes. En el segundo caso, algunos de estos atributos serían relevantes pero otros serían reemplazados (o potenciados) por atributos como salario medio, crédito total, opciones elegidas para el plan de pensión, dirección postal, etc.

Para desarrollar un conjunto significativo de atributos para un objeto, el analista puede estudiar de nuevo la narrativa del proceso (o descripción del ámbito del alcance) para el problema y seleccionar aquellos elementos que razonablemente “pertenecen” al objeto. Además, para cada objeto debe responderse el siguiente interrogante: “¿Qué elementos (compuestos y/o simples) definen completamente al objeto en el contexto del problema actual?”

Para ilustrar esto, se considerará el objeto Sistema definido para Hogar Seguro. Anteriormente se indicó que el propietario puede configurar el sistema de seguridad para reflejar la información acerca de los sensores, sobre la respuesta de la alarma, sobre la activación / desactivación, sobre identificación, etc. Usando la notación de la descripción del contenido se podría representar estos elementos de datos compuestos de la siguiente manera:

Información del sensor = tipo de sensor + número de sensor + umbral de alarma.Información de respuesta de la alarma = tiempo de retardo + número de teléfono + tipo de alarma.

Información de activación / desactivación = contraseña maestra + cantidad de intentos permitidos + contraseña temporal.

Información de identificación = ID del sistema + verificación de número de teléfono + estado del sistema.

Definición de operaciones

Las operaciones definen el comportamiento de un objeto y cambian, de alguna manera, los atributos de dicho objeto. Más concretamente, una operación cambia valores de uno o más atributos contenidos en el objeto. Por lo tanto, una operación debe tener “conocimiento” de la naturaleza de los atributos de los objetos y deben ser implementadas de manera tal que le permita manipular las estructuras de datos derivadas de dichos atributos.

Aunque existen muchos tipos diferentes de operaciones, éstas pueden clasificarse en tres grandes categorías: (1) operaciones que manipulan, de alguna manera, datos (por ejemplo: añadiendo, eliminando, reformateando, seleccionando); (2) operaciones que realizan algún cálculo; y (3) operaciones que monitorizan un objeto frente a la ocurrencia de un suceso de control.

En una primera iteración para obtener un conjunto de operaciones para los objetos del modelo de análisis, el analista puede estudiar de nuevo la narrativa del proceso (o descripción del ámbito) del problema y seleccionar aquellas operaciones que razonablemente pertenecen al objeto. Para realizar esto, se estudia de nuevo el análisis gramatical y se aíslan los verbos. Algunos de estos verbos serán operaciones legítimas y pueden conectarse fácilmente a un objeto específico. Por ejemplo, de la narrativa de proceso de Hogar Seguro, puede verse que “al sensor se le asigna un número y un tipo” o que “se programa una contraseña maestra para activar y desactivar el sistema”. Estas dos frases indican varias cosas:

Que una operación de asignación es relevante para el objeto Sensor.

Que una operación de programar se le aplicará al objeto Sistema.

Que activar y desactivar son operaciones aplicables al Sistema como: Estado del sistema = [activado | desactivado]

Tras una investigación más detallada, es probable que haya que dividir la operación programar en varias suboperaciones más específicas requeridas para configurar el sistema. Por ejemplo, programar implica especificar números de teléfonos, configurar características del sistema (por ejemplo, crear la tabla de sensores, introducir las características de las alarmas) e introducir la(s) contraseña(s), aunque por ahora se especificará programar como una operación simple.

Fin de la definición del objeto

La definición de operaciones es el último paso para completar la especificación del objeto. Las operaciones se eligieron a partir de un examen gramatical de la narrativa del proceso del sistema. Las operaciones adicionales pueden determinarse considerando la “historia de la vida” de un objeto y los mensajes que se pasan entre objetos definidos por el sistema.

La historia de la vida genérica de un objeto puede definirse reconociendo que dicho objeto deber ser creado, modificado, manipulado o leído de manera diferente, y posiblemente borrado. Para el objeto Sistema, eso puede expandirse para reflejar actividades conocidas que ocurren durante su vida (en este caso, durante el tiempo que Hogar Seguro se mantiene operativo).

Algunas de las operaciones pueden determinarse a partir de comunicaciones semejantes entre objetos. Por ejemplo, el Suceso sensor enviará un mensaje a Sistema para mostrar en pantalla la localización y número del suceso; el Panel de control enviará un mensaje de reinicialización para actualizar el estado del Sistema (un atributo); la Alarma audible enviará un mensaje de consulta, el Panel de control enviará una mensaje de modificación para cambiar uno o más atributos sin reconfigurar el objeto Sistema por completo; el Suceso sensor enviará un mensaje para llamar al número(s) de teléfono(s) contenido(s) en el objeto. Podrán considerarse otros mensajes para derivar operaciones correspondientes.

La definición del objeto resultante se muestra en la figura siguiente:

Se usará un enfoque similar para cada uno de los objetos definidos para Hogar Seguro.