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